From tgen at netphreax.net  Sat Mar  1 12:57:53 2008
From: tgen at netphreax.net (Thomas E. Spanjaard)
Date: Sat, 1 Mar 2008 12:57:53 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: [Fwd: Project Support Open Source: $50 donation to support you      project]
In-Reply-To: <2468.192.168.0.242.1204346451.squirrel@www.shiningsilence.com>
Message-ID: <47C9C1B7.50203@netphreax.net>

Justin C. Sherrill wrote:
The "donation" happens after you place an "acknowledgement" on an open
source project's web page.  I'm putting those words in scare quotes
because I think it's a "payment" for an "advertisement".  The supplied
link has nothing to do with DragonFly, to say the least.

<a href="http://www.2insure4less.com /" title="We support FOSS software
projects.">Online Insurance Quotes</a>
To think our souls are only worth $50...
--
        Thomas E. Spanjaard
        tgen at netphreax.net
Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00000.pgp
Type: application/octet-stream
Size: 186 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080301/0d61e240/attachment.obj>

From c.turner at 199technologies.org  Sat Mar  1 17:52:31 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Sat, 1 Mar 2008 17:52:31 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Misc. ACPI / suspend
Message-ID: <47CA073B.6020106@199technologies.org>

Wondering if anyone more well versed in the ACPI implementation could
comment on the applicability of:
http://lkml.org/lkml/2007/4/6/69

w/r/t the current state of the art in Dfly

(or BSD's in general)

Cheers!

- Chris




From elekktretterr at exemail.com.au  Sun Mar  2 00:41:25 2008
From: elekktretterr at exemail.com.au (Petr Janda)
Date: Sun, 2 Mar 2008 00:41:25 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: CARP question
Message-ID: <200803021934.21669.elekktretterr@exemail.com.au>

So Ive setup CARP on 2 DF-based mailservers. Installation went fine. Box 1 has 
adskew of 0 therefore it is the MASTER. Box 2 has adskew of 254, therefore is 
BACKUP.  If i down the carp0 interface on Box 1, then Box 2 carp interface 
gets promoted to MASTER. Then I up the carp interface on Box 1, logically Box 
2 should become BACKUP again as Box 1 becomes MASTER due to adskew set to 0.

However it doesnt happen. When carp0 interface on Box 1 is upped it becomes a 
BACKUP, not a MASTER even though according to adskew it should be MASTER.

What is the desired behaviour?

Cheers
Petr




From qhwt+dfly at les.ath.cx  Sun Mar  2 02:50:14 2008
From: qhwt+dfly at les.ath.cx (YONETANI Tomokazu)
Date: Sun, 2 Mar 2008 02:50:14 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: panic: assertion: hammer_btree_cmp(cursor->left_bound,	&cursor->node->ondisk->elms[0].leaf.base) <= 0 in btree_split_leaf
In-Reply-To: <200802232204.m1NM4cxd046264@apollo.backplane.com>
Message-ID: <20080302104554.GA22813@les.ath.cx>

Hi.
While trying to find a procedure to reliably reproduce the panic
I reported last time, I caught a different panic (uploaded at
 ~y0netan1/crash/9/ on my leaf account).  I wrote the following shell
script (make sure to edit variables DISKS and MOUNTPT before using this
script or it may trash your system):
  #!/bin/sh -ex
  DISKS="/dev/ad0s1f"
  MOUNTPT=/mnt/HAMMER

  cd /
  newfs_hammer -L TEST $DISKS
  for i in `seq 1 100`; do
	  mount_hammer $DISKS $MOUNTPT
	  /bin/rm -rf $MOUNTPT/??
	  (set +x; for x in `seq 1 10000`; do echo -n > $MOUNTPT/$x; done)
	  umount $MOUNTPT
  done

And the panic is triggered by rm command.
I'll try to see if it's possible to reproduce the last one without
unmounting then mounting the HAMMER fs.

Cheers.




From dillon at apollo.backplane.com  Sun Mar  2 13:25:33 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Sun, 2 Mar 2008 13:25:33 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: panic: assertion: hammer_btree_cmp(cursor->left_bound,	&cursor->node->ondisk->elms[0].leaf.base) <= 0 in btree_split_leaf
In-Reply-To: <200802232204.m1NM4cxd046264@apollo.backplane.com>
Message-ID: <200803022119.m22LJRCY037076@apollo.backplane.com>


:Hi.
:While trying to find a procedure to reliably reproduce the panic
:I reported last time, I caught a different panic (uploaded at
: ~y0netan1/crash/9/ on my leaf account).  I wrote the following shell
:script (make sure to edit variables DISKS and MOUNTPT before using this
:script or it may trash your system):

(from the core)

panic: assertion: node->lock.refs == 0 && node->ondisk == NULL in hammer_flush_buffer_nodes

    Yah, I've seen this failure.  Add a sync or two before the umount and
    tell me if it still occurs.  It's either a node reference leak somewhere
    or it is a race between bufdaemon and umount.  The assertions are really
    strict there precisely to catch those sorts of cases.

    Also note that the code to deal with a full HAMMMER filesystem has not
    been written yet (The failure you are reporting is unrelated to a full
    HAMMER filesystem, though, just mentioning it).

						-Matt





From dillon at apollo.backplane.com  Sun Mar  2 13:29:03 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Sun, 2 Mar 2008 13:29:03 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Misc. ACPI / suspend
In-Reply-To: <47CA073B.6020106@199technologies.org>
Message-ID: <200803022126.m22LQbfI037188@apollo.backplane.com>


:Wondering if anyone more well versed in the ACPI implementation could
:comment on the applicability of:
:
:http://lkml.org/lkml/2007/4/6/69
:
:w/r/t the current state of the art in Dfly
:
:(or BSD's in general)
:
:Cheers!
:
:- Chris

    I really have no idea re: this.  Suspension in general is not well
    supported by any of the BSDs.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From dillon at apollo.backplane.com  Sun Mar  2 13:34:05 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Sun, 2 Mar 2008 13:34:05 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: [Fwd: Project Support Open Source: $50 donation to support you      project]
In-Reply-To: <2468.192.168.0.242.1204346451.squirrel@www.shiningsilence.com>
Message-ID: <200803022131.m22LVOe9037250@apollo.backplane.com>

:..
:source project's web page.  I'm putting those words in scare quotes
:because I think it's a "payment" for an "advertisement".  The supplied
:link has nothing to do with DragonFly, to say the least.
:
:I don't think this is a good idea, obviously, and replied to that effect. 
:However, I wanted to put this on a DragonFly list, in part to show this
:strange thing, and in part because I'm not comfortable making
:administrative decisions on behalf of the Project without being open as
:possible about it.

    It doesn't really cry out to me either.

						-Matt





From wbh at conducive.org  Sun Mar  2 20:36:32 2008
From: wbh at conducive.org (Bill Hacker)
Date: Mon, 03 Mar 2008 04:36:32 +0000
Subject: Misc. ACPI / suspend
In-Reply-To: <47CA073B.6020106@199technologies.org>
Message-ID: <47cb8050$0$855$415eb37d@crater_reader.dragonflybsd.org>

Matthew Dillon wrote:
:Wondering if anyone more well versed in the ACPI implementation could
:comment on the applicability of:
:
:http://lkml.org/lkml/2007/4/6/69
:
:w/r/t the current state of the art in Dfly
:
:(or BSD's in general)
:
:Cheers!
:
:- Chris
    I really have no idea re: this.  Suspension in general is not well
    supported by any of the BSDs.
					-Matt
					Matthew Dillon 
					<dillon at backplane.com>


. . and there seems to be a bit of a 'Catch 22' there in any case.

If the BIOS can alter 'stuff' out of site of the OS it is parking, what 
does the existence of such a 'feature' do to a(ny) security model?

Seems to at least beg creating the option of setting a flag to 
specifically *prevent* suspend-to-disk/hibernation (and/or force a 
reboot on wake-up).

Just because one is paranoid....  etc

Bill





From matthias at dragonflybsd.org  Tue Mar  4 02:30:52 2008
From: matthias at dragonflybsd.org (Matthias Schmidt)
Date: Tue, 4 Mar 2008 02:30:52 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
Message-ID: <20080304102335.GI9833@staatsfeind.org>

Hi,

Google just announced its Summer of Code for 2008:

	http://code.google.com/soc/2008/

I think this would be a great opportunity for DragonFly to participate
as a mentoring organisation.  We could attract new developers and could
get code/work done.  Looking at the SoC results of the other BSDs most
of their projects were a success.  Of course, not all, but a reasonable
percentage.  See [1] and [2].

It is some extra work for us, but IMO the benefits outweigh the extra
work.  And yes, I would volunteer as a mentor.  What do others
(developers) think?  Any more volunteers? :)

Some project ideas that come into my mind.  More ideas are listed in the
wiki:  http://wiki.dragonflybsd.org/index.cgi/ProjectsPage

 * Fix all remaining bugs in dma(8) and implement all missing features
 * Add a driver for newer Intel Wireless cards (I think sephe@ would
   love that :)
 * Bring our ACPI stuff in shape.  Maybe suspend2disk ...

 * [Add your own thoughts here]

Cheers,

	Matthias

PS: I don't want to create a bikeshed here whether you like the SoC or
not :)

[1] http://code.google.com/soc/2007/freebsd/about.html
[2] http://code.google.com/soc/2007/netbsd/about.html




From corecode at fs.ei.tum.de  Tue Mar  4 04:46:14 2008
From: corecode at fs.ei.tum.de (Simon 'corecode' Schubert)
Date: Tue, 4 Mar 2008 04:46:14 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47CD4386.1000704@fs.ei.tum.de>

Matthias Schmidt wrote:
>  * [Add your own thoughts here]

MP lock removal for network stack

and for the system  (first profile, find hot spots, fix hot spots, repeat)

cheers
  simon




From c.turner at 199technologies.org  Tue Mar  4 06:02:20 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Tue, 4 Mar 2008 06:02:20 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47CD551E.1040604@199technologies.org>

Matthias Schmidt wrote:
Some project ideas that come into my mind.  More ideas are listed in the
wiki:  http://wiki.dragonflybsd.org/index.cgi/ProjectsPage
+1 acpi
+1 interrupt routing
+1 SMP / giant removal
+1 pf synchup with openbsd
though there are several others on the page that are good..

need to dig up my wiki login and place appropriately..

also: thinking the ZFS port should be removed from the page - makes 
sense to everyone else? (e.g. fragments effort w/r/t hammer)





From tgen at netphreax.net  Tue Mar  4 06:54:31 2008
From: tgen at netphreax.net (Thomas E. Spanjaard)
Date: Tue, 4 Mar 2008 06:54:31 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47CD615F.8010209@netphreax.net>

Matthias Schmidt wrote:
Google just announced its Summer of Code for 2008:

 * [Add your own thoughts here]
x86-64 port :).
--
        Thomas E. Spanjaard
        tgen at netphreax.net
Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00001.pgp
Type: application/octet-stream
Size: 186 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080304/0d921000/attachment.obj>

From rdivacky at FreeBSD.org  Tue Mar  4 07:07:03 2008
From: rdivacky at FreeBSD.org (Roman Divacky)
Date: Tue, 4 Mar 2008 07:07:03 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <20080304150255.GA8831@freebsd.org>

On Tue, Mar 04, 2008 at 02:49:03PM +0000, Thomas E. Spanjaard wrote:
> Matthias Schmidt wrote:
> >Google just announced its Summer of Code for 2008:
> >
> > * [Add your own thoughts here]
> 
> x86-64 port :).

all those ideas are great and needed etc. but keep in
mind that the projects should be doable by students
who might see dfly for the very first time.

don't overestimate whats possible and select projects
that look realistic

Roman Divacky (former SoC student)




From justin at shiningsilence.com  Tue Mar  4 08:32:56 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Tue, 4 Mar 2008 08:32:56 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <60322.65.106.147.226.1204648095.squirrel@www.shiningsilence.com>

On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
> Hi,
>
> Google just announced its Summer of Code for 2008:
>
> 	http://code.google.com/soc/2008/
>
> I think this would be a great opportunity for DragonFly to participate
> as a mentoring organisation.  We could attract new developers and could
> get code/work done.  Looking at the SoC results of the other BSDs most
> of their projects were a success.  Of course, not all, but a reasonable
> percentage.  See [1] and [2].

We've applied in previous years - Jeff Hsu did one year, and I put
together the application last year.  The hardest thing to find was
students (and they are the thing that helps SoC applications a lot, I
think).

Any student volunteers?  We have mentors.





From rluciani at gmail.com  Tue Mar  4 09:38:29 2008
From: rluciani at gmail.com (Robert Luciani)
Date: Tue, 04 Mar 2008 18:38:29 +0100
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47cd8915$0$854$415eb37d@crater_reader.dragonflybsd.org>

Justin C. Sherrill wrote:
> On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
>> Hi,
>>
>> Google just announced its Summer of Code for 2008:
>>
>> 	http://code.google.com/soc/2008/
>>
>> I think this would be a great opportunity for DragonFly to participate
>> as a mentoring organisation.  We could attract new developers and could
>> get code/work done.  Looking at the SoC results of the other BSDs most
>> of their projects were a success.  Of course, not all, but a reasonable
>> percentage.  See [1] and [2].
> 
> We've applied in previous years - Jeff Hsu did one year, and I put
> together the application last year.  The hardest thing to find was
> students (and they are the thing that helps SoC applications a lot, I
> think).
> 
> Any student volunteers?  We have mentors.
> 

bingo

-- 
Robert Luciani
Chalmers University of Technology, SWE
Department of Computer Science and Engineering
http://www.rluciani.com/public.key




From sdavtaker at gmail.com  Tue Mar  4 09:31:08 2008
From: sdavtaker at gmail.com (=?UTF-8?Q?Sd=C3=A4vtaker?=)
Date: Tue, 4 Mar 2008 09:31:08 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <c37d69f60803040926k206218a3kb8496d0cd18148bd@mail.gmail.com>

If you mentor, i will apply for coder :-)
Still in last year of university. :-)
Sdav

On Tue, Mar 4, 2008 at 1:28 PM, Justin C. Sherrill
<justin at shiningsilence.com> wrote:
> On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
>  > Hi,
>  >
>  > Google just announced its Summer of Code for 2008:
>  >
>  >       http://code.google.com/soc/2008/
>  >
>  > I think this would be a great opportunity for DragonFly to participate
>  > as a mentoring organisation.  We could attract new developers and could
>  > get code/work done.  Looking at the SoC results of the other BSDs most
>  > of their projects were a success.  Of course, not all, but a reasonable
>  > percentage.  See [1] and [2].
>
>  We've applied in previous years - Jeff Hsu did one year, and I put
>  together the application last year.  The hardest thing to find was
>  students (and they are the thing that helps SoC applications a lot, I
>  think).
>
>  Any student volunteers?  We have mentors.
>
>



-- 
Sd?vtaker prays to Rikku goddess for a good treasure.



From rluciani at gmail.com  Tue Mar  4 09:44:02 2008
From: rluciani at gmail.com (Robert Luciani)
Date: Tue, 04 Mar 2008 18:44:02 +0100
Subject: google soc "DragonFly"
Message-ID: <47cd8a63$0$855$415eb37d@crater_reader.dragonflybsd.org>

On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
> > Hi,
> >
> > Google just announced its Summer of Code for 2008:
> >
> > 	http://code.google.com/soc/2008/
> >
> > I think this would be a great opportunity for DragonFly to participate
> > as a mentoring organisation.  We could attract new developers and could
> > get code/work done.  Looking at the SoC results of the other BSDs most
> > of their projects were a success.  Of course, not all, but a reasonable
> > percentage.  See [1] and [2].

We've applied in previous years - Jeff Hsu did one year, and I put
together the application last year.  The hardest thing to find was
students (and they are the thing that helps SoC applications a lot, I
think).

Any student volunteers?  We have mentors.


-- 
Robert Luciani
Chalmers University of Technology, SWE
Department of Computer Science and Engineering
http://www.rluciani.com/public.key




From rluciani at gmail.com  Tue Mar  4 10:04:14 2008
From: rluciani at gmail.com (Robert Luciani)
Date: Tue, 04 Mar 2008 19:04:14 +0100
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47cd8f1f$0$856$415eb37d@crater_reader.dragonflybsd.org>

Robert Luciani wrote:
> Justin C. Sherrill wrote:
>> On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
>>> Hi,
>>>
>>> Google just announced its Summer of Code for 2008:
>>>
>>> 	http://code.google.com/soc/2008/
>>>
>>> I think this would be a great opportunity for DragonFly to participate
>>> as a mentoring organisation.  We could attract new developers and could
>>> get code/work done.  Looking at the SoC results of the other BSDs most
>>> of their projects were a success.  Of course, not all, but a reasonable
>>> percentage.  See [1] and [2].
>> We've applied in previous years - Jeff Hsu did one year, and I put
>> together the application last year.  The hardest thing to find was
>> students (and they are the thing that helps SoC applications a lot, I
>> think).
>>
>> Any student volunteers?  We have mentors.
>>
> 
> bingo
> 
My girlfriend Danwei noted that she would also like partake in the SoC.
She's studying IT here at Chalmers and will join the mailing list shortly.
-- 
Robert Luciani
Chalmers University of Technology, SWE
Department of Computer Science and Engineering
http://www.rluciani.com/public.key




From dillon at apollo.backplane.com  Tue Mar  4 13:08:30 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Tue, 4 Mar 2008 13:08:30 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Going to have to roll 1.12.1
Message-ID: <200803042104.m24L43g1065278@apollo.backplane.com>

    Due to a critical bug in sendmail that can cause it to seg-fault I will
    be rolling 1.12.1 as soon as I get verification that the current
    fix deals with it.

						-Matt





From sdavtaker at gmail.com  Tue Mar  4 17:40:43 2008
From: sdavtaker at gmail.com (=?UTF-8?B?U2TDpHZ0YWtlcg==?=)
Date: Tue, 4 Mar 2008 17:40:43 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: [Fwd: Project Support Open Source: $50 donation to support you  project]
In-Reply-To: <2468.192.168.0.242.1204346451.squirrel@www.shiningsilence.com>
Message-ID: <47CDF8D1.9070100@gmail.com>

50 bucks?
Come on...
You can get a meal a lot more expensive than that just going to a free 
HP conference about linux and you only have to rent your soul 3-5 hours ;-)
Sdav

Matthew Dillon escribi?:
:..
:source project's web page.  I'm putting those words in scare quotes
:because I think it's a "payment" for an "advertisement".  The supplied
:link has nothing to do with DragonFly, to say the least.
:
:I don't think this is a good idea, obviously, and replied to that effect. 
:However, I wanted to put this on a DragonFly list, in part to show this
:strange thing, and in part because I'm not comfortable making
:administrative decisions on behalf of the Project without being open as
:possible about it.

    It doesn't really cry out to me either.

						-Matt

  






From sdavtaker at gmail.com  Tue Mar  4 17:56:35 2008
From: sdavtaker at gmail.com (=?UTF-8?B?U2TDpHZ0YWtlcg==?=)
Date: Tue, 4 Mar 2008 17:56:35 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47CDFCCE.1010106@gmail.com>

A cute idea for for GSOC would be to finish the installer.
We were talking about this in my local BUG, we trying to find out how to 
help on that from here.
There is a few missing features in the CD.

   * FDISK, you need to create the slides from another OS before
     install DFBSD, i think port FDisk from FBSD or any *BSD will solve it.
   * Add to the make release a way to add some custom applications to
     the released liveCD (suppose you want to add nmap or ssh or
     something just to use as test disk in some enviroment).
   * Make the installer a little more customizable, and maybe w/ a GUI
     (I like a lot the console approach, but GUI installer will be a
     popularity move, DFBSD w/X makes a Desktop machine work, actually
     im using it that way and really like it).
I think those projects can be done in a SOC by students (like me) with a 
little guide.
Im a lot more interested in things network related and kernel, but i 
dont mind to work on those things, they need to be done some day.
What u think?
Sdav

Robert Luciani escribi?:
Robert Luciani wrote:
  
Justin C. Sherrill wrote:
    
On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
      
Hi,

Google just announced its Summer of Code for 2008:

	http://code.google.com/soc/2008/

I think this would be a great opportunity for DragonFly to participate
as a mentoring organisation.  We could attract new developers and could
get code/work done.  Looking at the SoC results of the other BSDs most
of their projects were a success.  Of course, not all, but a reasonable
percentage.  See [1] and [2].
        
We've applied in previous years - Jeff Hsu did one year, and I put
together the application last year.  The hardest thing to find was
students (and they are the thing that helps SoC applications a lot, I
think).
Any student volunteers?  We have mentors.

      
bingo

    
My girlfriend Danwei noted that she would also like partake in the SoC.
She's studying IT here at Chalmers and will join the mailing list shortly.
  






From c.turner at 199technologies.org  Tue Mar  4 18:30:53 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Tue, 4 Mar 2008 18:30:53 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47CE04C9.1010902@199technologies.org>

Justin C. Sherrill wrote:
together the application last year.  The hardest thing to find was
students (and they are the thing that helps SoC applications a lot, I
think).
umm.. if google wants to send me back to school, I'll sign up - hows 
that for a fair trade :?






From wbh at conducive.org  Tue Mar  4 23:52:13 2008
From: wbh at conducive.org (Bill Hacker)
Date: Wed, 05 Mar 2008 07:52:13 +0000
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47ce512e$0$855$415eb37d@crater_reader.dragonflybsd.org>

Sd?vtaker wrote:
A cute idea for for GSOC would be to finish the installer.
We were talking about this in my local BUG, we trying to find out how to 
help on that from here.
There is a few missing features in the CD.

   * FDISK, you need to create the slides from another OS before
     install DFBSD, i think port FDisk from FBSD or any *BSD will solve it.
I'd rather see that 'reversed' - i.e. - build a more capable fdisk in 
DFLY with hope that it might be seen worth importing into Free/Net/Open, 
or *at least* be able to do a more flexible job than those now do.

And disklabels as well. Hand in glove.

Here's why:

- At the moment, working with Free, Open, DFLY, and OpenSolaris on the 
same HDD requires a bit of acrobatics.

- There seems to now be greater divergence between/among the *BSD's as 
to being able to read each other's disklabels, mount and use each 
other's 'flavor' of FFS/UFS (not to mention Apple's implementation of 
UFS) than there is among the vast multitude of Linux ext2/3 denizens.

Even to the point where use of a *Linux* fs is the more universal way 
for being able to share mounts among the *BSD's. Think detached drives. 
And no - FAT is not all that practical for several reasons.

- DFLY currently has the most fine-grain ability to create slices and 
partitions. But the others cannot all (any?) read those.

'progress' w/r any of the *BSD's direction as to changes, improvements 
(or not) in their once-common-ancestry fs & disklabels need not be 
sacrificed.

I'm not holding out wish or hope for all players agreeing to return to 
'one sacred way'. Nor 'one new universal fs'. Neither is gonna happen.

But a 'legacy compatible' or least-common-denominator mode would do fine 
- most especially for portable / SAN devices.

So - how about a 'flexible' DFLY fdisk to go along with a 'flexible' 
disklabel that could adapt to whatever it found / was told to create?

JM2CW - but that *might* be a good place to get a cross-*BSD team together.

*snip* (other good stuff)

Bill Hacker




From matthias at dragonflybsd.org  Wed Mar  5 01:02:43 2008
From: matthias at dragonflybsd.org (Matthias Schmidt)
Date: Wed, 5 Mar 2008 01:02:43 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <20080305085747.GJ9833@staatsfeind.org>

Hi,

* Justin C. Sherrill wrote:
> 
> We've applied in previous years - Jeff Hsu did one year, and I put
> together the application last year.  The hardest thing to find was
> students (and they are the thing that helps SoC applications a lot, I
> think).

This is good to know, so we could coordinate that if we have enough
mentors and projects?!?  I put together a small text in the wiki:

http://wiki.dragonflybsd.org/index.cgi/GoogleSoC2008

Feel free to add project or missing stuff.  I'm sure I missed a lot of
things :)

> Any student volunteers?  We have mentors.

According to the discussion we could have some students, who would be a
mentor (besides me)?

Regards

	Matthias





From sdavtaker at gmail.com  Wed Mar  5 06:28:37 2008
From: sdavtaker at gmail.com (=?UTF-8?Q?Sd=C3=A4vtaker?=)
Date: Wed, 5 Mar 2008 06:28:37 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <c37d69f60803050624kd86d3d0w3b44a02d0e5a5391@mail.gmail.com>

<quote>
Write a driver (from scratch) for Intel 3945 wireless device
Mentor: Sepherosa Ziehau
</quote>

Yes yes yes, i want to :-)
Someone else planning to mentor in drivers coding?
Sdav

On Wed, Mar 5, 2008 at 5:57 AM, Matthias Schmidt
<matthias at dragonflybsd.org> wrote:
> Hi,
>
>
>  * Justin C. Sherrill wrote:
>  >
>  > We've applied in previous years - Jeff Hsu did one year, and I put
>  > together the application last year.  The hardest thing to find was
>  > students (and they are the thing that helps SoC applications a lot, I
>  > think).
>
>  This is good to know, so we could coordinate that if we have enough
>  mentors and projects?!?  I put together a small text in the wiki:
>
>  http://wiki.dragonflybsd.org/index.cgi/GoogleSoC2008
>
>  Feel free to add project or missing stuff.  I'm sure I missed a lot of
>  things :)
>
>
>  > Any student volunteers?  We have mentors.
>
>  According to the discussion we could have some students, who would be a
>  mentor (besides me)?
>
>  Regards
>
>         Matthias
>
>



-- 
Sd?vtaker prays to Rikku goddess for a good treasure.



From rluciani at gmail.com  Wed Mar  5 10:56:42 2008
From: rluciani at gmail.com (Robert Luciani)
Date: Wed, 05 Mar 2008 19:56:42 +0100
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47ceecea$0$847$415eb37d@crater_reader.dragonflybsd.org>

Sd?vtaker wrote:
> <quote>
> Write a driver (from scratch) for Intel 3945 wireless device
> Mentor: Sepherosa Ziehau
> </quote>
> 
> Yes yes yes, i want to :-)
> Someone else planning to mentor in drivers coding?
> Sdav
> 
> On Wed, Mar 5, 2008 at 5:57 AM, Matthias Schmidt
> <matthias at dragonflybsd.org> wrote:
>> Hi,
>>
>>
>>  * Justin C. Sherrill wrote:
>>  >
>>  > We've applied in previous years - Jeff Hsu did one year, and I put
>>  > together the application last year.  The hardest thing to find was
>>  > students (and they are the thing that helps SoC applications a lot, I
>>  > think).
>>
>>  This is good to know, so we could coordinate that if we have enough
>>  mentors and projects?!?  I put together a small text in the wiki:
>>
>>  http://wiki.dragonflybsd.org/index.cgi/GoogleSoC2008
>>
>>  Feel free to add project or missing stuff.  I'm sure I missed a lot of
>>  things :)
>>
>>
>>  > Any student volunteers?  We have mentors.
>>
>>  According to the discussion we could have some students, who would be a
>>  mentor (besides me)?
>>
>>  Regards
>>
>>         Matthias
>>
>>
> 
> 
>

IF someone starts to write a 3945 Intel driver,
please keep the newer 4965 in mind too.

-- 
Robert Luciani
Chalmers University of Technology, SWE
Department of Computer Science and Engineering
http://www.rluciani.com/public.key




From joerg at britannica.bec.de  Wed Mar  5 12:01:05 2008
From: joerg at britannica.bec.de (Joerg Sonnenberger)
Date: Wed, 5 Mar 2008 12:01:05 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <20080305195711.GA9981@britannica.bec.de>

On Wed, Mar 05, 2008 at 07:56:42PM +0100, Robert Luciani wrote:
> IF someone starts to write a 3945 Intel driver,
> please keep the newer 4965 in mind too.

NetBSD's wpi works quite well. The hardware is quite different from
4945.

Joerg




From sepherosa at gmail.com  Wed Mar  5 17:48:50 2008
From: sepherosa at gmail.com (Sepherosa Ziehau)
Date: Wed, 5 Mar 2008 17:48:50 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <ea7b9c170803051744u22b09484ofc994f034f11df3b@mail.gmail.com>

On Thu, Mar 6, 2008 at 2:56 AM, Robert Luciani <rluciani at gmail.com> wrote:
>  IF someone starts to write a 3945 Intel driver,

"IF" you know that trying to fix any wired bugs in certain drivers
(e.g. ipw, ral) will require you to read through all of the vendor's
linux code (yes, even including register values and position), i.e.
there is not much difference between writing one from scratch and
porting+fixing_bugs, then you probably will not put "IF" at the start
of your sentence.
If what I said sounded too harsh to you, then I was sorry.

>  please keep the newer 4965 in mind too.

Will do, once generic 11n support is brought in from freebsd.

Best Regards,
sephe

-- 
Live Free or Die




From saw at online.de  Thu Mar  6 05:34:14 2008
From: saw at online.de (Sascha Wildner)
Date: Thu, 06 Mar 2008 14:34:14 +0100
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
Message-ID: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>

Hi all,

this is probably as good a moment as any to come out of the forest with 
this. The patch at

http://leaf.dragonflybsd.org/~swildner/nrelease_gui.diff

adds some code to nrelease/ to build a LiveCD with xorg and so on 
(currently, only the xorg metapackages and fluxbox are added). In order 
to build one, you need a local dir with the pkgsrc binary packages (see 
below).

The following commands should then do the trick:

cd /usr/src
make buildworld
make buildkernel
cd nrelease
patch -p 0 </path/to/the/patch
make PKGSRC_PKG_PATH=/path/to/packages/dir/All realquick gui
The resulting ISO will be in /usr/release/dfly-gui.iso then. It will not 
boot into xorg automatically (although this is easily possible), so you 
need to login as root and do startx.

As of now, this all is kind of basic, more a proof of concept than 
anything else. As our release framework installs packages via chroot, 
the current setup just copies _all_ packages to the chroot before 
installing (kind of a hack).

That said, I'm now primarily interested in opinions/ideas/... about the 
direction this should take. Which packages would we like to see on the 
CD? Should it be a generic setup with the "most common things" 
installed, so a system can be quickly setup by the installer (which will 
cpdup /usr/pkg). Or should it be a more specialized set of tools? Or 
even as many packages as possible (Live DVD?). Etc., etc.

Before continuing on it, I'm really interested in people's input so 
don't hold anything back, please. :)

Sascha

--
http://yoyodyne.ath.cx



From rluciani at gmail.com  Thu Mar  6 06:42:03 2008
From: rluciani at gmail.com (Robert Luciani)
Date: Thu, 06 Mar 2008 15:42:03 +0100
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <47d002bc$0$847$415eb37d@crater_reader.dragonflybsd.org>

Sascha Wildner wrote:
> Hi all,
> 
> this is probably as good a moment as any to come out of the forest with
> this. The patch at
> 
> http://leaf.dragonflybsd.org/~swildner/nrelease_gui.diff
> 
> adds some code to nrelease/ to build a LiveCD with xorg and so on
> (currently, only the xorg metapackages and fluxbox are added). In order
> to build one, you need a local dir with the pkgsrc binary packages (see
> below).
> 
> The following commands should then do the trick:
> 
> cd /usr/src
> make buildworld
> make buildkernel
> cd nrelease
> patch -p 0 </path/to/the/patch
> make PKGSRC_PKG_PATH=/path/to/packages/dir/All realquick gui
> 
> The resulting ISO will be in /usr/release/dfly-gui.iso then. It will not
> boot into xorg automatically (although this is easily possible), so you
> need to login as root and do startx.
> 
> As of now, this all is kind of basic, more a proof of concept than
> anything else. As our release framework installs packages via chroot,
> the current setup just copies _all_ packages to the chroot before
> installing (kind of a hack).
> 
> That said, I'm now primarily interested in opinions/ideas/... about the
> direction this should take. Which packages would we like to see on the
> CD? Should it be a generic setup with the "most common things"
> installed, so a system can be quickly setup by the installer (which will
> cpdup /usr/pkg). Or should it be a more specialized set of tools? Or
> even as many packages as possible (Live DVD?). Etc., etc.
> 
> Before continuing on it, I'm really interested in people's input so
> don't hold anything back, please. :)
> 
> Sascha
> 

I think the main point of such a live-cd would be to test
dragonfly-specific features such as vkernels and more. Mplayer and
OpenOffic work the same on all platforms, so they might not be super
important, while irssi, firefox, networking tools, vim, a few more
shells/terminals might make it easier to for people to quickly gauge if
they can reproduce their current productivity and also what is new.

And if the point of a livecd is to test that kind of stuff, then it
would be nice for it to have a kernel that supports as much as possible
like ALTQ, and drivers.

Also if it has lots and lots of programs (thinking multimedia, java,
etc..) it might be hard to keep the future x64 and x86 live-cds on par.
Gentoo had this problem many years ago and it was very bothersome.

-- 
Robert Luciani
Chalmers University of Technology, SWE
Department of Computer Science and Engineering
http://www.rluciani.com/public.key




From matthias at dragonflybsd.org  Thu Mar  6 07:12:43 2008
From: matthias at dragonflybsd.org (Matthias Schmidt)
Date: Thu, 6 Mar 2008 07:12:43 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <20080306150757.GN9833@staatsfeind.org>

* Sascha Wildner wrote:
> Hi all,
> 
> this is probably as good a moment as any to come out of the forest with this. 
> The patch at
> 
> http://leaf.dragonflybsd.org/~swildner/nrelease_gui.diff
> 
> adds some code to nrelease/ to build a LiveCD with xorg and so on (currently, 
> only the xorg metapackages and fluxbox are added). In order to build one, you 
> need a local dir with the pkgsrc binary packages (see below).

Great work Sascha.

I agree with Robert on most of his stated points.
It would be nice to see some DragonFly specific features on the CD
(although I'm not sure if that will work for all features).  A little
environment where most Unix users feel at home (fluxbox, xfce, firefox,
thunderbird, gvim) should be enough.

Big applications like OO.org, java etc won't work because they are not
available as pkgsrc packages neither is it possible to compile them on
DragonFly.  At least to my knowledge.

Regards

	Matthias




From dillon at apollo.backplane.com  Thu Mar  6 09:31:52 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Thu, 6 Mar 2008 09:31:52 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <200803061728.m26HSR3O091809@apollo.backplane.com>


:Hi all,
:
:this is probably as good a moment as any to come out of the forest with 
:this. The patch at
:
:http://leaf.dragonflybsd.org/~swildner/nrelease_gui.diff
:
:adds some code to nrelease/ to build a LiveCD with xorg and so on 
:(currently, only the xorg metapackages and fluxbox are added). In order 
:to build one, you need a local dir with the pkgsrc binary packages (see 
:below).
:
:The following commands should then do the trick:

    It looks reasonable, though the package copy has to be tightened
    up a bit I think.

:...
:installed, so a system can be quickly setup by the installer (which will 
:cpdup /usr/pkg). Or should it be a more specialized set of tools? Or 
:even as many packages as possible (Live DVD?). Etc., etc.
:
:Before continuing on it, I'm really interested in people's input so 
:don't hold anything back, please. :)
:
:Sascha

    I think this is an excellent time to work up a DVD build and to
    add various 'flavor' extras.  So, e.g.:

	make installer gui gui_extras release dvd

    (All 'dvd' would do is generate a dvd compatible image for burning to
    dvd instead of cd).  I did a quick perusal of what I have on my
    workstation:

    * X
    * Firefox
    * Linux emulation
    * Open Office (linux version)
    * fvwm2
    * xpdf
    * freetype2

    I'd also suggest some image editing tools like gimp, and maybe the KDE
    gui suite.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From justin at shiningsilence.com  Thu Mar  6 09:42:44 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Thu, 6 Mar 2008 09:42:44 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <55427.65.106.147.226.1204825168.squirrel@www.shiningsilence.com>

On Thu, March 6, 2008 8:34 am, Sascha Wildner wrote:

> That said, I'm now primarily interested in opinions/ideas/... about the
> direction this should take. Which packages would we like to see on the
> CD? Should it be a generic setup with the "most common things"
> installed, so a system can be quickly setup by the installer (which will
> cpdup /usr/pkg). Or should it be a more specialized set of tools? Or
> even as many packages as possible (Live DVD?). Etc., etc.

What Robert said is good - whatever's needed to enable DragonFly-specific
features.  Along with that would be some sort of documentation (a README? 
A HTML file on whatever desktop we provide) that points people at the
different DragonFly tools, so they know what to try and how to try it.

There's going to be some percentage of people who try DragonFly who don't
know about vkernels, for instance, but there's our chance to educate them.
 I'm probably volunteering myself, aren't I?





From sdavtaker at gmail.com  Thu Mar  6 09:50:09 2008
From: sdavtaker at gmail.com (=?UTF-8?Q?Sd=C3=A4vtaker?=)
Date: Thu, 6 Mar 2008 09:50:09 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <c37d69f60803060947t110750c0sd6b542ea505d188d@mail.gmail.com>

Cool Sascha :-)
I just posted about this 1 or 2 days ago in the SOC project ideas thread.
Want to mentor this one? ;-)
Damian

On Thu, Mar 6, 2008 at 2:28 PM, Matthew Dillon
<dillon at apollo.backplane.com> wrote:
>
>  :Hi all,
>
> :
>  :this is probably as good a moment as any to come out of the forest with
>  :this. The patch at
>  :
>  :http://leaf.dragonflybsd.org/~swildner/nrelease_gui.diff
>  :
>  :adds some code to nrelease/ to build a LiveCD with xorg and so on
>  :(currently, only the xorg metapackages and fluxbox are added). In order
>  :to build one, you need a local dir with the pkgsrc binary packages (see
>  :below).
>  :
>  :The following commands should then do the trick:
>
>     It looks reasonable, though the package copy has to be tightened
>     up a bit I think.
>
>  :...
>  :installed, so a system can be quickly setup by the installer (which will
>
> :cpdup /usr/pkg). Or should it be a more specialized set of tools? Or
>  :even as many packages as possible (Live DVD?). Etc., etc.
>  :
>  :Before continuing on it, I'm really interested in people's input so
>  :don't hold anything back, please. :)
>  :
>  :Sascha
>
>     I think this is an excellent time to work up a DVD build and to
>     add various 'flavor' extras.  So, e.g.:
>
>         make installer gui gui_extras release dvd
>
>     (All 'dvd' would do is generate a dvd compatible image for burning to
>     dvd instead of cd).  I did a quick perusal of what I have on my
>     workstation:
>
>     * X
>     * Firefox
>     * Linux emulation
>     * Open Office (linux version)
>     * fvwm2
>     * xpdf
>     * freetype2
>
>     I'd also suggest some image editing tools like gimp, and maybe the KDE
>     gui suite.
>
>                                         -Matt
>                                         Matthew Dillon
>                                         <dillon at backplane.com>
>



-- 
Sd?vtaker prays to Rikku goddess for a good treasure.



From saw at online.de  Thu Mar  6 11:54:01 2008
From: saw at online.de (Sascha Wildner)
Date: Thu, 06 Mar 2008 20:54:01 +0100
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <47d04ba2$0$856$415eb37d@crater_reader.dragonflybsd.org>

Matthew Dillon wrote:
    It looks reasonable, though the package copy has to be tightened
    up a bit I think.
It looks as if it would work with mount_null'ing the chroot's 
/tmp/packages. I'll have a better patch ready tomorrow.

Sascha

--
http://yoyodyne.ath.cx



From c.turner at 199technologies.org  Thu Mar  6 19:11:44 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Thu, 6 Mar 2008 19:11:44 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Misc. ACPI / suspend
In-Reply-To: <47CA073B.6020106@199technologies.org>
Message-ID: <47D0B079.3060905@199technologies.org>

Chris Turner wrote:
Wondering if anyone more well versed in the ACPI implementation could
comment on the applicability of:
http://lkml.org/lkml/2007/4/6/69

Doing a little digging, it seems like

. /platform/pc32/i386/i686_mem.c

*might* have the necessary infrastructure to remap the MTRR's per the 
thread referenced,

but:

. /platform/pc32/acpica5/acpi_wakeup.c

doesn't seem to be using this infrastructure..

I'm no where near reaching an understanding of this yet,
but I'm wondering 3 things:
1) does anyone have ACPI (instead of APM)
   sleep / suspend / wakeup working on Dfly ?
2) If so, what machines are being used ?
3) Same question for other BSDs - my understanding is NetBSD is most
   'advanced' w/r/t power managment - but I'm not 100% on this ...
would looove to have a sleeping / resuming / scaling laptop running some 
BSD flavor.. am willing to work towards that end, esp. w/r/t Dfly -
trying to chart a course to figguring this out.

Thanks all,

- Chris




From c.turner at 199technologies.org  Thu Mar  6 19:12:33 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Thu, 6 Mar 2008 19:12:33 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: PCI Bios / Interrupt remapping / etc
Message-ID: <47D0B211.6000002@199technologies.org>

Doing a bit of digging here for my long-standing CBB+SIO interupt and 
buffer problem -

one machine I've tested against was an OpenBSD machine, which didn't
always work to handle the cardbus sio card on a PCI cardbus adapter
-

tuning up some of the device flags in:

http://www.openbsd.org/cgi-bin/man.cgi?query=pcibios&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=html

seems to have alleviated the problem for that os..

I'm just only starting to get up to speed on how DF handles these types 
of things (namely initial PIC / interrupt layout at boot time device 
enumeration), but am wondering if anyone familiar with this area of the 
code has any comments / advice w/r/t the capabilities of the DF bios 
drivers
and the various quirks / fixup mentioned in the link above..

looking to possibly investigate fixing up some of these issues over time.

Thanks

- Chris







From pavalos at theshell.com  Fri Mar  7 01:14:55 2008
From: pavalos at theshell.com (Peter Avalos)
Date: Fri, 7 Mar 2008 01:14:55 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: cam locking
Message-ID: <20080307091024.GC1652@ylem.theshell.com>

So I've been working on locking up cam using lockmgr locks, and here's
what I have so far:

http://www.theshell.com/~pavalos/wip/cam-lock.patch

Most of the work is obtained from FreeBSD.  I've only been running this
on my SCSI machine for a day, but because the patch is so large, I wanted
to make it available for people to review if they have some spare time.

Thanks,
Peter
Attachment:
pgp00002.pgp
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00002.pgp
Type: application/octet-stream
Size: 197 bytes
Desc: "Description: PGP signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080307/9a17ecd8/attachment.obj>

From jspringe at uos.de  Fri Mar  7 03:25:17 2008
From: jspringe at uos.de (Jost Tobias Springenberg)
Date: Fri, 7 Mar 2008 12:25:17 +0100
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <20080307122517.72c9e2b1.jspringe@uos.de>

On Tue, 4 Mar 2008 11:28:15 -0500 (EST)
"Justin C. Sherrill" <justin at shiningsilence.com> wrote:

> On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
> > Hi,
> >
> > Google just announced its Summer of Code for 2008:
> >
> > 	http://code.google.com/soc/2008/
> >
> > I think this would be a great opportunity for DragonFly to participate
> > as a mentoring organisation.  We could attract new developers and could
> > get code/work done.  Looking at the SoC results of the other BSDs most
> > of their projects were a success.  Of course, not all, but a reasonable
> > percentage.  See [1] and [2].
> 
> We've applied in previous years - Jeff Hsu did one year, and I put
> together the application last year.  The hardest thing to find was
> students (and they are the thing that helps SoC applications a lot, I
> think).
> 
> Any student volunteers?  We have mentors.
> 

I read this mailing list for quite a while now and thought about contributing stuff
to DFfly several times, so yes why not take this opportunity if it's there.

-- 
Jost Tobias Springenberg <jspringe at uos.de>




From tgen at netphreax.net  Fri Mar  7 05:17:27 2008
From: tgen at netphreax.net (Thomas E. Spanjaard)
Date: Fri, 7 Mar 2008 05:17:27 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: PCI Bios / Interrupt remapping / etc
In-Reply-To: <47D0B211.6000002@199technologies.org>
Message-ID: <47D13FB4.5080306@netphreax.net>

Chris Turner wrote:
Doing a bit of digging here for my long-standing CBB+SIO interupt and 
buffer problem -

one machine I've tested against was an OpenBSD machine, which didn't
always work to handle the cardbus sio card on a PCI cardbus adapter
-

tuning up some of the device flags in:

http://www.openbsd.org/cgi-bin/man.cgi?query=pcibios&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=html 

seems to have alleviated the problem for that os..

I'm just only starting to get up to speed on how DF handles these types 
of things (namely initial PIC / interrupt layout at boot time device 
enumeration), but am wondering if anyone familiar with this area of the 
code has any comments / advice w/r/t the capabilities of the DF bios 
drivers
and the various quirks / fixup mentioned in the link above..

looking to possibly investigate fixing up some of these issues over time.
Our code that handles issues like this (in cases where you're not using 
APICs, just PICs and PIRs) lives in bus/pci/i386/. Not that running 
without APIC support is all that common on modern machines anymore...
--
        Thomas E. Spanjaard
        tgen at netphreax.net
Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00003.pgp
Type: application/octet-stream
Size: 186 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080307/61366b5c/attachment.obj>

From tgen at netphreax.net  Fri Mar  7 05:16:51 2008
From: tgen at netphreax.net (Thomas E. Spanjaard)
Date: Fri, 7 Mar 2008 05:16:51 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Misc. ACPI / suspend
In-Reply-To: <47CA073B.6020106@199technologies.org>
Message-ID: <47D13F07.9080308@netphreax.net>

Chris Turner wrote:
1) does anyone have ACPI (instead of APM)
   sleep / suspend / wakeup working on Dfly ?
2) If so, what machines are being used ?
3) Same question for other BSDs - my understanding is NetBSD is most
   'advanced' w/r/t power managment - but I'm not 100% on this ...
would looove to have a sleeping / resuming / scaling laptop running some 
BSD flavor.. am willing to work towards that end, esp. w/r/t Dfly -
trying to chart a course to figguring this out.
I have ACPI S3 suspend working like a charm on my IBM ThinkPad R40 
(Pentium M "Banias" 1.3GHz, speedstepping works just fine), running 
NetBSD 3.99.21.
--
        Thomas E. Spanjaard
        tgen at netphreax.net
Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00004.pgp
Type: application/octet-stream
Size: 186 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080307/de3e5104/attachment.obj>

From civilizd at gmail.com  Fri Mar  7 09:06:41 2008
From: civilizd at gmail.com (Vita "CiV" Cizek)
Date: Fri, 7 Mar 2008 09:06:41 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <98d564710803070853q1c73d795m6e6c5cc5049fa099@mail.gmail.com>

>  Any student volunteers?  We have mentors.
>
I am interested too, especially in some kernel-related work.




From justin at shiningsilence.com  Sat Mar  8 12:07:51 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Sat, 8 Mar 2008 12:07:51 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google SoC 2008 - mentors mentors mentors
Message-ID: <51558.192.168.0.252.1205006403.squirrel@www.shiningsilence.com>

If you are willing to mentor for the Google 2008 Summer of Code, please
speak up.  Right now we have: (from our wiki page)

Matthias
Sephe
TGEN
corecode

Part of the application process includes naming people as mentors (student
applications come later), so I want to get as complete a list as possible.

The application is due on the 12th, so if you want to mentor, now's the
time to say so.

Google's SoC FAQ is here: http://code.google.com/soc/2008/faqs.html

Our wiki page is here: http://wiki.dragonflybsd.org/index.cgi/GoogleSoC2008

- much credit to Matthias and others for getting that set up.





From saw at online.de  Sat Mar  8 14:26:07 2008
From: saw at online.de (Sascha Wildner)
Date: Sat, 08 Mar 2008 23:26:07 +0100
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <47d31245$0$848$415eb37d@crater_reader.dragonflybsd.org>

Sascha Wildner wrote:
Hi all,

this is probably as good a moment as any to come out of the forest with 
this. The patch at

http://leaf.dragonflybsd.org/~swildner/nrelease_gui.diff
Ok, I have committed the stuff as an example.

I'm not sure if my free time permits to work on a full-blown live CD 
with X11 and other good things (I already feel my interest wandering off 
in other directions) so if anyone wants to pick up the ball, go ahead. :)

Sascha

--
http://yoyodyne.ath.cx



From qhwt+dfly at les.ath.cx  Tue Mar 11 22:21:31 2008
From: qhwt+dfly at les.ath.cx (YONETANI Tomokazu)
Date: Tue, 11 Mar 2008 22:21:31 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Misc. ACPI / suspend
In-Reply-To: <47CA073B.6020106@199technologies.org>
Message-ID: <20080312051219.GA56091@les.ath.cx>

On Thu, Mar 06, 2008 at 10:03:21PM -0500, Chris Turner wrote:
> 1) does anyone have ACPI (instead of APM)
>    sleep / suspend / wakeup working on Dfly ?
> 2) If so, what machines are being used ?

Dynabook SS3500 (http://www.tlt.co.jp/pc/catalog/ss/02110735/index_j.htm).
It's old and can get very hot(thus frequently turns on the cooling fan)
even when it's running Windows.  I haven't turned it on for about several
months though.

Cheers.




From c.turner at 199technologies.org  Wed Mar 12 04:37:22 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Wed, 12 Mar 2008 04:37:22 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Misc. ACPI / suspend
In-Reply-To: <47CA073B.6020106@199technologies.org>
Message-ID: <47D7BEE3.6010907@199technologies.org>

YONETANI Tomokazu wrote:
On Thu, Mar 06, 2008 at 10:03:21PM -0500, Chris Turner wrote:
1) does anyone have ACPI (instead of APM)
   sleep / suspend / wakeup working on Dfly ?
Cheers.
ditto..

Suppose this should go to docs@ - in any case..

Thinking about setting up a wiki page on the issue so we
can discuss / track what 'good' hardware / drivers / implementations / 
etc are 'out there' - anyone have any suggestions on where this should
go?

http://wiki.dragonflybsd.org/index.cgi/acpi-overview.html

Remains from the handbook conversion - but I'm hesitant to 'over wikify'
this ..



From c.turner at 199technologies.org  Wed Mar 12 15:36:52 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Wed, 12 Mar 2008 15:36:52 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: devel/cscope
Message-ID: <47D85A08.8040103@199technologies.org>

why oh why did I take so long to try this out !!!

just sharing my eureka moment with the list..

- Chris




From dudu at dudu.ro  Wed Mar 12 15:50:14 2008
From: dudu at dudu.ro (Vlad GALU)
Date: Wed, 12 Mar 2008 15:50:14 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: devel/cscope
In-Reply-To: <47D85A08.8040103@199technologies.org>
Message-ID: <ad79ad6b0803121547r2bf67ffep9e40badaac6490f8@mail.gmail.com>

On 3/13/08, Chris Turner <c.turner at 199technologies.org> wrote:
> why oh why did I take so long to try this out !!!
>
>  just sharing my eureka moment with the list..


    Works nice with vim, too!

>
>
>  - Chris
>


-- 
Mahnahmahnah!




From justin at shiningsilence.com  Sun Mar 16 21:06:13 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Sun, 16 Mar 2008 21:06:13 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: binary packages for 1.12 coming in
Message-ID: <1372.192.168.0.252.1205726088.squirrel@www.shiningsilence.com>

The binary build for 1.12 is taking quite a while.  I've started copying
in newly built packages to
pkgbox.dragonflybsd.org/packages/DragonFly-1.12/i386/ - this should be
getting copied out to mirrors over the next while.

There are currently 1283 packages built, which leaves a whole lot to go;
I'll copy new packages in as they complete.





From hasso at estpak.ee  Wed Mar 19 04:31:08 2008
From: hasso at estpak.ee (Hasso Tepper)
Date: Wed, 19 Mar 2008 04:31:08 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Some questions regarding ACPI
Message-ID: <200803191322.46366.hasso@estpak.ee>

I'm working on bringing in some laptop (and especially thinkpad) specific 
ACPI code from FreeBSD into DragonFly. I never touched ACPI stuff before 
and haven't followed it much either, so I have some questions.

* FreeBSD uses ACPI_SERIAL_* heavily. What's the locking situation in 
  DragonFly and why?

* As far as I can see, PCI integration is commented out in DragonFly. 
  What's the state of it and why?

* platform/pc32/acpica5/acpi_toshiba.c - why is it there? I don't think 
  that this is something pc32 specific in it and it should work in pc64 
  laptops as well. Any objections to move it into 
  dev/acpica5/acpi_toshiba/ ?

What's the current status of ACPI in general? AFAICS our acpica is quite 
old - what needs to be done to bring in newer one?


-- 
Hasso




From qhwt+dfly at les.ath.cx  Wed Mar 19 09:24:50 2008
From: qhwt+dfly at les.ath.cx (YONETANI Tomokazu)
Date: Wed, 19 Mar 2008 09:24:50 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Some questions regarding ACPI
In-Reply-To: <200803191322.46366.hasso@estpak.ee>
Message-ID: <20080319161703.GA51509@les.ath.cx>

On Wed, Mar 19, 2008 at 01:22:46PM +0200, Hasso Tepper wrote:
> I'm working on bringing in some laptop (and especially thinkpad) specific 
> ACPI code from FreeBSD into DragonFly. I never touched ACPI stuff before 
> and haven't followed it much either, so I have some questions.

So you want to port some of ACPI support drivers, or to do a fresh port
of ACPI driver from FreeBSD?

> * FreeBSD uses ACPI_SERIAL_* heavily. What's the locking situation in 
>   DragonFly and why?

The current ACPI driver in DragonFly is based on that of FreeBSD as of
end of June, 2004, plus some fixes brought in later (and ACPICA part
has been updated twice since then).  That was before they introduced
the MPSAFE changes into ACPI code, and we use critical section
(crit_{enter,exit}) in most places (and lockmgr lock in a few place).

> * As far as I can see, PCI integration is commented out in DragonFly. 
>   What's the state of it and why?

When we replaced the implementation taken from FreeBSD 4.x with that
brought from FreeBSD 5.x, which added the PCI part, many people
experienced problems until they turned off ACPI completely, or add "pci"
to "debug.acpi.disabled" loader variable.  AFAIK the PCI part in the ACPI
driver almost hasn't been adjusted to work with our version of PCI code.

> * platform/pc32/acpica5/acpi_toshiba.c - why is it there? I don't think 
>   that this is something pc32 specific in it and it should work in pc64 
>   laptops as well. Any objections to move it into 
>   dev/acpica5/acpi_toshiba/ ?

In FreeBSD it used to be sitting at i386/acpica/acpi_toshiba.c and was
later moved into acpi_support.  That change hasn't hit our tree (in fact,
we have no acpi support drivers other than that).  It seems that FreeBSD
has them in dev/acpi_support now, and we for some reason have that
directory in our CVS repository (but containing no files in it).

> What's the current status of ACPI in general? AFAICS our acpica is quite 
> old - what needs to be done to bring in newer one?

Actually, it's not very important to keep just ACPICA latest, but
if you bring the ACPI driver from FreeBSD you need to bring ACPICA code
that matches their version, and it IS important.  And it generally requires
you much work to just update ACPICA part anyway because of how they
change things on every release.

Cheers.




From hasso at estpak.ee  Wed Mar 19 12:29:52 2008
From: hasso at estpak.ee (Hasso Tepper)
Date: Wed, 19 Mar 2008 12:29:52 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Some questions regarding ACPI
In-Reply-To: <200803191322.46366.hasso@estpak.ee>
Message-ID: <200803192115.35396.hasso@estpak.ee>

YONETANI Tomokazu wrote:
> On Wed, Mar 19, 2008 at 01:22:46PM +0200, Hasso Tepper wrote:
> > I'm working on bringing in some laptop (and especially thinkpad)
> > specific ACPI code from FreeBSD into DragonFly. I never touched ACPI
> > stuff before and haven't followed it much either, so I have some
> > questions.
>
> So you want to port some of ACPI support drivers, or to do a fresh port
> of ACPI driver from FreeBSD?

I'm only interested in support drivers and the reason is pure practical - 
newer thinkpads handle less and less hotkeys etc in hardware and require 
support form OS. acpi_ibm and acpi_video are examples of such modules 
which would help a lot of these newer thinkpad users.

acpi_ibm is almost ready to commit (renamed to acpi_thinkpad though).

> > * FreeBSD uses ACPI_SERIAL_* heavily. What's the locking situation in
> >   DragonFly and why?
>
> The current ACPI driver in DragonFly is based on that of FreeBSD as of
> end of June, 2004, plus some fixes brought in later (and ACPICA part
> has been updated twice since then).  That was before they introduced
> the MPSAFE changes into ACPI code, and we use critical section
> (crit_{enter,exit}) in most places (and lockmgr lock in a few place).

Mkay. Will look at more closely.

> > * As far as I can see, PCI integration is commented out in DragonFly.
> >   What's the state of it and why?
>
> When we replaced the implementation taken from FreeBSD 4.x with that
> brought from FreeBSD 5.x, which added the PCI part, many people
> experienced problems until they turned off ACPI completely, or add
> "pci" to "debug.acpi.disabled" loader variable.  AFAIK the PCI part in
> the ACPI driver almost hasn't been adjusted to work with our version of
> PCI code.

I'm afraid that it's beyond my skills, but while looking at acpi_video I 
discovered that it's hard to handle correctly without PCI support.

> > * platform/pc32/acpica5/acpi_toshiba.c - why is it there? I don't
> > think that this is something pc32 specific in it and it should work
> > in pc64 laptops as well. Any objections to move it into
> >   dev/acpica5/acpi_toshiba/ ?
>
> In FreeBSD it used to be sitting at i386/acpica/acpi_toshiba.c and was
> later moved into acpi_support.  That change hasn't hit our tree (in
> fact, we have no acpi support drivers other than that).  It seems that
> FreeBSD has them in dev/acpi_support now, and we for some reason have
> that directory in our CVS repository (but containing no files in it).

I don't see it ;). Makes sense though. So, any objections if I move 
acpi_toshiba into sys/dev/acpi_support and add new acpi_thinkpad there as 
well? 

> > What's the current status of ACPI in general? AFAICS our acpica is
> > quite old - what needs to be done to bring in newer one?
>
> Actually, it's not very important to keep just ACPICA latest, but
> if you bring the ACPI driver from FreeBSD you need to bring ACPICA code
> that matches their version, and it IS important.  And it generally
> requires you much work to just update ACPICA part anyway because of how
> they change things on every release.

Someone else has to do it :).

Thanks for info.


-- 
Hasso




From dillon at apollo.backplane.com  Wed Mar 19 14:01:13 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Wed, 19 Mar 2008 14:01:13 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: panic: assertion: hammer_btree_cmp(cursor->left_bound,	&cursor->node->ondisk->elms[0].leaf.base) <= 0 in btree_split_leaf
In-Reply-To: <200802232204.m1NM4cxd046264@apollo.backplane.com>
Message-ID: <200803192054.m2JKsjwn045137@apollo.backplane.com>


:Hi.
:While trying to find a procedure to reliably reproduce the panic
:I reported last time, I caught a different panic (uploaded at
: ~y0netan1/crash/9/ on my leaf account).  I wrote the following shell
:script (make sure to edit variables DISKS and MOUNTPT before using this
:script or it may trash your system):
:  #!/bin/sh -ex
:  DISKS="/dev/ad0s1f"
:  MOUNTPT=/mnt/HAMMER
:
:  cd /
:  newfs_hammer -L TEST $DISKS
:  for i in `seq 1 100`; do
:..
:And the panic is triggered by rm command.
:I'll try to see if it's possible to reproduce the last one without
:unmounting then mounting the HAMMER fs.
:
:Cheers.

    I believe I have fixed this panic.  hammer_make_separator() had a bug
    in it.

    There is still an issue with the node ref count on umount.

    Please continue to life-test the code.  The reblocking code
    (hammer reblock /mnt) should work now, as should the pruning code
    (e.g. hammer prune /mnt everything).

    The filesystem full case is still not handled and will cause bad things
    to happen.  The undo code isn't finished yet either but it is getting
    there (it's writing stuff out but not setting the sequence number and
    not trying to recover-on-mount yet).

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From qhwt+dfly at les.ath.cx  Wed Mar 19 19:45:40 2008
From: qhwt+dfly at les.ath.cx (YONETANI Tomokazu)
Date: Wed, 19 Mar 2008 19:45:40 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Some questions regarding ACPI
In-Reply-To: <200803191322.46366.hasso@estpak.ee>
Message-ID: <20080320023828.GA53648@les.ath.cx>

On Wed, Mar 19, 2008 at 09:15:35PM +0200, Hasso Tepper wrote:
> YONETANI Tomokazu wrote:
> > On Wed, Mar 19, 2008 at 01:22:46PM +0200, Hasso Tepper wrote:
> > > I'm working on bringing in some laptop (and especially thinkpad)
> > > specific ACPI code from FreeBSD into DragonFly. I never touched ACPI
> > > stuff before and haven't followed it much either, so I have some
> > > questions.
> >
> > So you want to port some of ACPI support drivers, or to do a fresh port
> > of ACPI driver from FreeBSD?
> 
> I'm only interested in support drivers and the reason is pure practical - 
> newer thinkpads handle less and less hotkeys etc in hardware and require 
> support form OS. acpi_ibm and acpi_video are examples of such modules 
> which would help a lot of these newer thinkpad users.
> 
> acpi_ibm is almost ready to commit (renamed to acpi_thinkpad though).

Ah, that's a good news!  My only concern is that ISTR someone mentioned
me that his colleague was thinking about porting ACPI driver itself,
so if you're not the person you may want to collaborate with him/her
so as not to waste the effort or time...

			:

> > In FreeBSD it used to be sitting at i386/acpica/acpi_toshiba.c and was
> > later moved into acpi_support.  That change hasn't hit our tree (in
> > fact, we have no acpi support drivers other than that).  It seems that
> > FreeBSD has them in dev/acpi_support now, and we for some reason have
> > that directory in our CVS repository (but containing no files in it).
> 
> I don't see it ;). Makes sense though. So, any objections if I move 
> acpi_toshiba into sys/dev/acpi_support and add new acpi_thinkpad there as 
> well? 

Sorry, I checked the CVS repository and it doesn't exist actually :)
I don't have any objection to moving it there.

Cheers.




From hasso at estpak.ee  Thu Mar 20 00:14:05 2008
From: hasso at estpak.ee (Hasso Tepper)
Date: Thu, 20 Mar 2008 00:14:05 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Some questions regarding ACPI
In-Reply-To: <200803191322.46366.hasso@estpak.ee>
Message-ID: <200803200904.50875.hasso@estpak.ee>

YONETANI Tomokazu wrote:
> On Wed, Mar 19, 2008 at 09:15:35PM +0200, Hasso Tepper wrote:
> > acpi_ibm is almost ready to commit (renamed to acpi_thinkpad though).
>
> Ah, that's a good news!  My only concern is that ISTR someone mentioned
> me that his colleague was thinking about porting ACPI driver itself,
> so if you're not the person you may want to collaborate with him/her
> so as not to waste the effort or time...

Current state in my repo is attached. It should work on 1.12 as well as it 
doesn't depend yet on moving stuff around.

add-acpi-if-m.patch adds some new stuff to the ACPI code to access 
embedded controllers and match ACPI devices by ID. Not sure how, where 
and whether at all these should be documented.

add-acpi-thinkpad.patch is the driver itself. Note that some stuff doesn't 
work yet on newer thinkpads, I plan to work on it later.

There is still some things to do though. I have to decide what to do with 
led(4) part and with locking. There is also one fatal issue - laptop 
locks up hardly (no panic) while unloading module. Any idea regarding 
this is welcome. And of course test results :).


-- 
Hasso
# HG changeset patch
# User Hasso Tepper <hasso at estpak.ee>
# Date 1205919290 -7200
# Branch HEAD
# Node ID 5a6e2705cc95a340abf973ae5df73ef34e070b79
# Parent  cd529e2e7f849034d5d5a0973cb98af50db0e797
imported patch adding-acpi-if-m.patch

diff --git a/sys/conf/files b/sys/conf/files
--- a/sys/conf/files
+++ b/sys/conf/files
@@ -1387,6 +1387,7 @@ emulation/dragonfly12/dfbsd12_stat.c	non
 ${OSACPI_MI_DIR}/acpi_cmbat.c		optional acpi
 ${OSACPI_MI_DIR}/acpi_cpu.c		optional acpi
 ${OSACPI_MI_DIR}/acpi_ec.c		optional acpi
+${OSACPI_MI_DIR}/acpi_if.m		optional acpi
 ${OSACPI_MI_DIR}/acpi_isab.c		optional acpi isa
 ${OSACPI_MI_DIR}/acpi_lid.c		optional acpi
 ${OSACPI_MI_DIR}/acpi_package.c		optional acpi
diff --git a/sys/conf/kmod.mk b/sys/conf/kmod.mk
--- a/sys/conf/kmod.mk
+++ b/sys/conf/kmod.mk
@@ -275,7 +275,7 @@ MFILES?= kern/bus_if.m kern/device_if.m 
     bus/pccard/card_if.m bus/pccard/power_if.m bus/pci/pci_if.m \
     bus/pci/pcib_if.m \
     bus/ppbus/ppbus_if.m bus/smbus/smbus_if.m bus/usb/usb_if.m \
-    dev/disk/nata/ata_if.m \
+    dev/acpica5/acpi_if.m dev/disk/nata/ata_if.m \
     dev/sound/pcm/ac97_if.m dev/sound/pcm/channel_if.m \
     dev/sound/pcm/feeder_if.m dev/sound/pcm/mixer_if.m \
     libiconv/iconv_converter_if.m dev/agp/agp_if.m opencrypto/crypto_if.m
diff --git a/sys/dev/acpica5/Makefile b/sys/dev/acpica5/Makefile
--- a/sys/dev/acpica5/Makefile
+++ b/sys/dev/acpica5/Makefile
@@ -69,12 +69,14 @@ SRCS+=  acpi_package.c
 # SRCS+=	acpi_pci.c acpi_pcib.c acpi_pcib_acpi.c acpi_pcib_pci.c
 # SRCS+=	acpi_pci_link.c
 SRCS+=  acpi_powerres.c acpi_resource.c acpi_thermal.c
-SRCS+=  acpi_timer.c
+SRCS+=  acpi_timer.c acpi_if.c
 SRCS+=  OsdDebug.c
 SRCS+=  OsdHardware.c OsdInterface.c OsdInterrupt.c OsdMemory.c OsdSchedule.c
 SRCS+=  OsdStream.c OsdSynch.c OsdTable.c OsdEnvironment.c
 SRCS+=  opt_acpi.h opt_bus.h opt_ddb.h
-SRCS+=  device_if.h bus_if.h pci_if.h pcib_if.h isa_if.h
+SRCS+=  device_if.h bus_if.h pci_if.h pcib_if.h isa_if.h acpi_if.h
+MFILES = kern/device_if.m kern/bus_if.m bus/pci/pci_if.m bus/pci/pcib_if.m
+MFILES+= bus/isa/isa_if.m dev/acpica5/acpi_if.m
 
 # Debugging support
 DBSRC=	dbcmds.c dbdisply.c dbexec.c dbfileio.c dbhistry.c
diff --git a/sys/dev/acpica5/acpi.c b/sys/dev/acpica5/acpi.c
--- a/sys/dev/acpica5/acpi.c
+++ b/sys/dev/acpica5/acpi.c
@@ -135,6 +135,7 @@ static int	acpi_release_resource(device_
 			int rid, struct resource *r);
 static uint32_t	acpi_isa_get_logicalid(device_t dev);
 static int	acpi_isa_get_compatid(device_t dev, uint32_t *cids, int count);
+static char	*acpi_device_id_probe(device_t bus, device_t dev, char **ids);
 static int	acpi_isa_pnp_probe(device_t bus, device_t child,
 			struct isa_pnp_id *ids);
 static void	acpi_probe_children(device_t bus);
@@ -189,6 +190,9 @@ static device_method_t acpi_methods[] = 
     DEVMETHOD(bus_deactivate_resource,	bus_generic_deactivate_resource),
     DEVMETHOD(bus_setup_intr,		bus_generic_setup_intr),
     DEVMETHOD(bus_teardown_intr,	bus_generic_teardown_intr),
+
+    /* ACPI bus */
+    DEVMETHOD(acpi_id_probe,		acpi_device_id_probe),
 
     /* ISA emulation */
     DEVMETHOD(isa_pnp_probe,		acpi_isa_pnp_probe),
@@ -1121,6 +1125,24 @@ out:
 	AcpiOsFree(buf.Pointer);
     ACPI_UNLOCK;
     return_VALUE (valid);
+}
+
+static char *
+acpi_device_id_probe(device_t bus, device_t dev, char **ids) 
+{
+    ACPI_HANDLE h;
+    int i;
+
+    h = acpi_get_handle(dev);
+    if (ids == NULL || h == NULL || acpi_get_type(dev) != ACPI_TYPE_DEVICE)
+	return (NULL);
+
+    /* Try to match one of the array of IDs with a HID or CID. */
+    for (i = 0; ids[i] != NULL; i++) {
+	if (acpi_MatchHid(h, ids[i]))
+	    return (ids[i]);
+    }
+    return (NULL);
 }
 
 static int
diff --git a/sys/dev/acpica5/acpi_ec.c b/sys/dev/acpica5/acpi_ec.c
--- a/sys/dev/acpica5/acpi_ec.c
+++ b/sys/dev/acpica5/acpi_ec.c
@@ -327,11 +327,19 @@ static ACPI_STATUS	EcWrite(struct acpi_e
 				UINT8 *Data);
 static int		acpi_ec_probe(device_t dev);
 static int		acpi_ec_attach(device_t dev);
+static int		acpi_ec_read_method(device_t dev, u_int addr,
+				ACPI_INTEGER *val, int width);
+static int		acpi_ec_write_method(device_t dev, u_int addr,
+				ACPI_INTEGER val, int width);
 
 static device_method_t acpi_ec_methods[] = {
     /* Device interface */
     DEVMETHOD(device_probe,	acpi_ec_probe),
     DEVMETHOD(device_attach,	acpi_ec_attach),
+
+    /* Embedded controller interface */
+    DEVMETHOD(acpi_ec_read,     acpi_ec_read_method),
+    DEVMETHOD(acpi_ec_write,    acpi_ec_write_method),
 
     {0, 0}
 };
@@ -620,6 +628,33 @@ error:
 			     sc->ec_data_res);
     /* mtx_destroy(&sc->ec_mtx); */
     return (ENXIO);
+}
+
+/* Methods to allow other devices (e.g., smbat) to read/write EC space. */
+static int
+acpi_ec_read_method(device_t dev, u_int addr, ACPI_INTEGER *val, int width)
+{
+    struct acpi_ec_softc *sc;
+    ACPI_STATUS status;
+
+    sc = device_get_softc(dev);
+    status = EcSpaceHandler(ACPI_READ, addr, width * 8, val, sc, NULL);
+    if (ACPI_FAILURE(status))
+        return (ENXIO);
+    return (0);
+}
+
+static int
+acpi_ec_write_method(device_t dev, u_int addr, ACPI_INTEGER val, int width)
+{
+    struct acpi_ec_softc *sc;
+    ACPI_STATUS status;
+
+    sc = device_get_softc(dev);
+    status = EcSpaceHandler(ACPI_WRITE, addr, width * 8, &val, sc, NULL);
+    if (ACPI_FAILURE(status))
+        return (ENXIO);
+    return (0);
 }
 
 static void
diff --git a/sys/dev/acpica5/acpi_if.m b/sys/dev/acpica5/acpi_if.m
new file mode 100644
--- /dev/null
+++ b/sys/dev/acpica5/acpi_if.m
@@ -0,0 +1,92 @@
+#-
+# Copyright (c) 2004 Nate Lawson
+# All rights reserved.
+#
+# Redistribution and use in source and binary forms, with or without
+# modification, are permitted provided that the following conditions
+# are met:
+# 1. Redistributions of source code must retain the above copyright
+#    notice, this list of conditions and the following disclaimer.
+# 2. Redistributions in binary form must reproduce the above copyright
+#    notice, this list of conditions and the following disclaimer in the
+#    documentation and/or other materials provided with the distribution.
+#
+# THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
+# ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+# ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
+# FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+# DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+# OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+# HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+# LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+# OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+# SUCH DAMAGE.
+#
+# $DragonFly$
+#
+
+#include <sys/bus.h>
+#include <sys/types.h>
+#include "acpi.h"
+
+INTERFACE acpi;
+
+#
+# Default implementation for acpi_id_probe().
+#
+CODE {
+	static char *
+	acpi_generic_id_probe(device_t bus, device_t dev, char **ids)
+	{
+		return (NULL);
+	}
+};
+
+#
+# Check a device for a match in a list of ID strings.  The strings can be
+# EISA PNP IDs or ACPI _HID/_CID values.
+#
+# device_t bus:  parent bus for the device
+#
+# device_t dev:  device being considered
+#
+# char **ids:  array of ID strings to consider
+#
+# Returns:  ID string matched or NULL if no match
+#
+METHOD char * id_probe {
+	device_t	bus;
+	device_t	dev;
+	char		**ids;
+} DEFAULT acpi_generic_id_probe;
+
+#
+# Read embedded controller (EC) address space
+#
+# device_t dev:  EC device
+# u_int addr:  Address to read from in EC space
+# ACPI_INTEGER *val:  Location to store read value
+# int width:  Size of area to read in bytes
+#
+METHOD int ec_read {
+	device_t	dev;
+	u_int		addr;
+	ACPI_INTEGER	*val;
+	int		width;
+};
+
+#
+# Write embedded controller (EC) address space
+#
+# device_t dev:  EC device
+# u_int addr:  Address to write to in EC space
+# ACPI_INTEGER val:  Value to write
+# int width:  Size of value to write in bytes
+#
+METHOD int ec_write {
+	device_t	dev;
+	u_int		addr;
+	ACPI_INTEGER	val;
+	int		width;
+};
diff --git a/sys/dev/acpica5/acpivar.h b/sys/dev/acpica5/acpivar.h
--- a/sys/dev/acpica5/acpivar.h
+++ b/sys/dev/acpica5/acpivar.h
@@ -29,6 +29,7 @@
  * $DragonFly: src/sys/dev/acpica5/acpivar.h,v 1.12 2007/10/23 03:04:48 y0netan1 Exp $
  */
 
+#include "acpi_if.h"
 #include "bus_if.h"
 #include <sys/eventhandler.h>
 #include <sys/sysctl.h>
# HG changeset patch
# User Hasso Tepper <hasso at estpak.ee>
# Date 1205995474 -7200
# Branch HEAD
# Node ID c5db8d4a7c6b25a8576a8d42c5029aaf0e23bfb6
# Parent  5a6e2705cc95a340abf973ae5df73ef34e070b79
[mq]: adding-acpi-thinkpad.patch

diff --git a/sys/dev/acpica5/Makefile b/sys/dev/acpica5/Makefile
--- a/sys/dev/acpica5/Makefile
+++ b/sys/dev/acpica5/Makefile
@@ -117,7 +117,7 @@ acpi_wakecode.h: acpi_wakecode.S
 	${MAKE} -f ${SYSDIR}/${OSACPI_MD_DIR}/Makefile \
 		MAKESRCPATH=${SYSDIR}/${OSACPI_MD_DIR}
 
-SUBDIR=	acpi_toshiba
+SUBDIR=	acpi_toshiba acpi_thinkpad
 all: ${PROG} ${SUBDIR}
 
 # *.o file for each patched *.c file is created under the same directory,
diff --git a/sys/dev/acpica5/acpi_thinkpad/Makefile b/sys/dev/acpica5/acpi_thinkpad/Makefile
new file mode 100644
--- /dev/null
+++ b/sys/dev/acpica5/acpi_thinkpad/Makefile
@@ -0,0 +1,9 @@
+# $DragonFly$
+
+SYSDIR?=${.CURDIR}/../../..
+
+KMOD=		acpi_thinkpad
+CFLAGS+=	-I${.OBJDIR}/.. -I${.CURDIR}/..
+SRCS=		acpi_thinkpad.c opt_acpi.h device_if.h bus_if.h
+
+.include <bsd.kmod.mk>
diff --git a/sys/dev/acpica5/acpi_thinkpad/acpi_thinkpad.c b/sys/dev/acpica5/acpi_thinkpad/acpi_thinkpad.c
new file mode 100644
--- /dev/null
+++ b/sys/dev/acpica5/acpi_thinkpad/acpi_thinkpad.c
@@ -0,0 +1,1046 @@
+/*
+ * Copyright (c) 2004 Takanori Watanabe
+ * Copyright (c) 2005 Markus Brueffer <markus at FreeBSD.org>
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *    notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *    notice, this list of conditions and the following disclaimer in the
+ *    documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+ */
+
+/*
+ * Driver for extra ACPI-controlled gadgets found on IBM and Lenovo ThinkPad
+ * laptops. Inspired by the ibm-acpi and tpb projects which implement these
+ * features on Linux.
+ *
+ *   acpi-ibm: <http://ibm-acpi.sourceforge.net/>
+ *        tpb: <http://www.nongnu.org/tpb/>
+ */
+
+#include "opt_acpi.h"
+#include <sys/param.h>
+#include <sys/kernel.h>
+#include <sys/bus.h>
+#include <machine/cpufunc.h>
+#include <sys/module.h>
+/* #include <dev/led/led.h> */
+#include <sys/sensors.h>
+#include <sys/sysctl.h>
+#include <machine/clock.h>
+
+#include "acpi.h"
+#include "acpivar.h"
+#include "acpi_if.h"
+
+#define _COMPONENT	ACPI_OEM
+ACPI_MODULE_NAME("THINKPAD")
+
+/* Internal methods */
+#define ACPI_THINKPAD_METHOD_EVENTS		1
+#define ACPI_THINKPAD_METHOD_EVENTMASK		2
+#define ACPI_THINKPAD_METHOD_HOTKEY		3
+#define ACPI_THINKPAD_METHOD_BRIGHTNESS		4
+#define ACPI_THINKPAD_METHOD_VOLUME		5
+#define ACPI_THINKPAD_METHOD_MUTE		6
+#define ACPI_THINKPAD_METHOD_THINKLIGHT		7
+#define ACPI_THINKPAD_METHOD_BLUETOOTH		8
+#define ACPI_THINKPAD_METHOD_WLAN		9
+#define ACPI_THINKPAD_METHOD_FANSPEED		10
+#define ACPI_THINKPAD_METHOD_FANLEVEL		11
+#define ACPI_THINKPAD_METHOD_FANSTATUS		12
+#define ACPI_THINKPAD_METHOD_THERMAL		13
+
+/* Hotkeys/Buttons */
+#define THINKPAD_RTC_HOTKEY1			0x64
+#define   THINKPAD_RTC_MASK_HOME		(1 << 0)
+#define   THINKPAD_RTC_MASK_SEARCH		(1 << 1)
+#define   THINKPAD_RTC_MASK_MAIL		(1 << 2)
+#define   THINKPAD_RTC_MASK_WLAN		(1 << 5)
+#define THINKPAD_RTC_HOTKEY2			0x65
+#define   THINKPAD_RTC_MASK_THINKPAD		(1 << 3)
+#define   THINKPAD_RTC_MASK_ZOOM		(1 << 5)
+#define   THINKPAD_RTC_MASK_VIDEO		(1 << 6)
+#define   THINKPAD_RTC_MASK_HIBERNATE		(1 << 7)
+#define THINKPAD_RTC_THINKLIGHT			0x66
+#define   THINKPAD_RTC_MASK_THINKLIGHT		(1 << 4)
+#define THINKPAD_RTC_SCREENEXPAND		0x67
+#define   THINKPAD_RTC_MASK_SCREENEXPAND	(1 << 5)
+#define THINKPAD_RTC_BRIGHTNESS			0x6c
+#define   THINKPAD_RTC_MASK_BRIGHTNESS		(1 << 5)
+#define THINKPAD_RTC_VOLUME			0x6e
+#define   THINKPAD_RTC_MASK_VOLUME		(1 << 7)
+
+/* Embedded Controller registers */
+#define THINKPAD_EC_BRIGHTNESS			0x31
+#define   THINKPAD_EC_MASK_BRI			0x7
+#define THINKPAD_EC_VOLUME			0x30
+#define   THINKPAD_EC_MASK_VOL			0xf
+#define   THINKPAD_EC_MASK_MUTE			(1 << 6)
+#define THINKPAD_EC_FANSTATUS			0x2F
+#define   THINKPAD_EC_MASK_FANLEVEL		0x3f
+#define   THINKPAD_EC_MASK_FANDISENGAGED	(1 << 6)
+#define   THINKPAD_EC_MASK_FANSTATUS		(1 << 7)
+#define THINKPAD_EC_FANSPEED			0x84
+
+/* CMOS Commands */
+#define THINKPAD_CMOS_VOLUME_DOWN		0
+#define THINKPAD_CMOS_VOLUME_UP			1
+#define THINKPAD_CMOS_VOLUME_MUTE		2
+#define THINKPAD_CMOS_BRIGHTNESS_UP		4
+#define THINKPAD_CMOS_BRIGHTNESS_DOWN		5
+
+/* ACPI methods */
+#define THINKPAD_NAME_KEYLIGHT			"KBLT"
+#define THINKPAD_NAME_WLAN_BT_GET		"GBDC"
+#define THINKPAD_NAME_WLAN_BT_SET		"SBDC"
+#define   THINKPAD_NAME_MASK_BT			(1 << 1)
+#define   THINKPAD_NAME_MASK_WLAN		(1 << 2)
+#define THINKPAD_NAME_THERMAL_GET		"TMP7"
+#define THINKPAD_NAME_THERMAL_UPDT		"UPDT"
+
+#define THINKPAD_NAME_EVENTS_STATUS_GET		"DHKC"
+#define THINKPAD_NAME_EVENTS_MASK_GET		"DHKN"
+#define THINKPAD_NAME_EVENTS_STATUS_SET		"MHKC"
+#define THINKPAD_NAME_EVENTS_MASK_SET		"MHKM"
+#define THINKPAD_NAME_EVENTS_GET		"MHKP"
+#define THINKPAD_NAME_EVENTS_AVAILMASK		"MHKA"
+
+#define ABS(x) (((x) < 0)? -(x) : (x))
+
+struct acpi_thinkpad_softc {
+	device_t	dev;
+	ACPI_HANDLE	handle;
+
+	/* Embedded controller */
+	device_t	ec_dev;
+	ACPI_HANDLE	ec_handle;
+
+	/* CMOS */
+	ACPI_HANDLE	cmos_handle;
+
+	/* Fan status */
+	ACPI_HANDLE	fan_handle;
+	int		fan_levels;
+
+	/* Keylight commands and states */
+	ACPI_HANDLE	light_handle;
+	int		light_cmd_on;
+	int		light_cmd_off;
+	int		light_val;
+	int		light_get_supported;
+	int		light_set_supported;
+
+	/* led(4) interface */
+	struct cdev	*led_dev;
+	int		led_busy;
+	int		led_state;
+
+	int		wlan_bt_flags;
+	int		thermal_updt_supported;
+
+	unsigned int	events_availmask;
+	unsigned int	events_initialmask;
+	int		events_mask_supported;
+	int		events_enable;
+
+	/* sensors(9) related */
+	struct ksensordev sensordev;
+	struct ksensor sensors[9];	/* XXX: 8 thermal + fan */
+
+	struct sysctl_ctx_list	*sysctl_ctx;
+	struct sysctl_oid	*sysctl_tree;
+};
+
+static struct {
+	char	*name;
+	int	method;
+	char	*description;
+	int	access;
+} acpi_thinkpad_sysctls[] = {
+	{
+		.name		= "events",
+		.method		= ACPI_THINKPAD_METHOD_EVENTS,
+		.description	= "ACPI events enable",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "eventmask",
+		.method		= ACPI_THINKPAD_METHOD_EVENTMASK,
+		.description	= "ACPI eventmask",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "hotkey",
+		.method		= ACPI_THINKPAD_METHOD_HOTKEY,
+		.description	= "Key Status",
+		.access		= CTLTYPE_INT | CTLFLAG_RD
+	},
+	{
+		.name		= "lcd_brightness",
+		.method		= ACPI_THINKPAD_METHOD_BRIGHTNESS,
+		.description	= "LCD Brightness",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "volume",
+		.method		= ACPI_THINKPAD_METHOD_VOLUME,
+		.description	= "Volume",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "mute",
+		.method		= ACPI_THINKPAD_METHOD_MUTE,
+		.description	= "Mute",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "thinklight",
+		.method		= ACPI_THINKPAD_METHOD_THINKLIGHT,
+		.description	= "Thinklight enable",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "bluetooth",
+		.method		= ACPI_THINKPAD_METHOD_BLUETOOTH,
+		.description	= "Bluetooth enable",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "wlan",
+		.method		= ACPI_THINKPAD_METHOD_WLAN,
+		.description	= "WLAN enable",
+		.access		= CTLTYPE_INT | CTLFLAG_RD
+	},
+	{
+		.name		= "fan_level",
+		.method		= ACPI_THINKPAD_METHOD_FANLEVEL,
+		.description	= "Fan level",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "fan",
+		.method		= ACPI_THINKPAD_METHOD_FANSTATUS,
+		.description	= "Fan enable",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+
+	{ NULL, 0, NULL, 0 }
+};
+
+/* ACPI_SERIAL_DECL(thinkpad, "ACPI THINKPAD extras"); */
+static int	acpi_thinkpad_probe(device_t dev);
+static int	acpi_thinkpad_attach(device_t dev);
+static int	acpi_thinkpad_detach(device_t dev);
+
+#if 0 /* not yet */
+static void	thinkpad_led(void *softc, int onoff);
+static void	thinkpad_led_task(struct acpi_thinkpad_softc *sc,
+		int pending __unused);
+#endif
+
+static int	acpi_thinkpad_sysctl(SYSCTL_HANDLER_ARGS);
+static int	acpi_thinkpad_sysctl_init(struct acpi_thinkpad_softc *sc,
+		int method);
+static int	acpi_thinkpad_sysctl_get(struct acpi_thinkpad_softc *sc,
+		int method);
+static int	acpi_thinkpad_sysctl_set(struct acpi_thinkpad_softc *sc,
+		int method, int val);
+
+static int	acpi_thinkpad_eventmask_set(struct acpi_thinkpad_softc *sc,
+		int val);
+static void	acpi_thinkpad_notify(ACPI_HANDLE h, UINT32 notify,
+		void *context);
+static void	acpi_thinkpad_refresh(void *);
+
+static device_method_t acpi_thinkpad_methods[] = {
+	/* Device interface */
+	DEVMETHOD(device_probe, acpi_thinkpad_probe),
+	DEVMETHOD(device_attach, acpi_thinkpad_attach),
+	DEVMETHOD(device_detach, acpi_thinkpad_detach),
+	{0, 0}
+};
+
+static driver_t	acpi_thinkpad_driver = {
+	"acpi_thinkpad",
+	acpi_thinkpad_methods,
+	sizeof(struct acpi_thinkpad_softc),
+};
+
+static devclass_t acpi_thinkpad_devclass;
+
+DRIVER_MODULE(acpi_thinkpad, acpi, acpi_thinkpad_driver,
+    acpi_thinkpad_devclass, 0, 0);
+MODULE_DEPEND(acpi_thinkpad, acpi, 1, 1, 1);
+static char    *thinkpad_ids[] = {"IBM0068", NULL};
+
+#if 0 /* not yet */
+static void
+thinkpad_led(void *softc, int onoff)
+{
+	struct acpi_thinkpad_softc* sc = (struct acpi_thinkpad_softc*) softc;
+
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+
+	if (sc->led_busy)
+		return;
+
+	sc->led_busy = 1;
+	sc->led_state = onoff;
+
+	AcpiOsExecute(OSL_NOTIFY_HANDLER, (void *)thinkpad_led_task, sc);
+}
+
+static void
+thinkpad_led_task(struct acpi_thinkpad_softc *sc, int pending __unused)
+{
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+
+	/* ACPI_SERIAL_BEGIN(thinkpad); */
+	acpi_thinkpad_sysctl_set(sc, ACPI_THINKPAD_METHOD_THINKLIGHT, sc->led_state);
+	/* ACPI_SERIAL_END(thinkpad); */
+
+	sc->led_busy = 0;
+}
+#endif
+
+static int
+acpi_thinkpad_probe(device_t dev)
+{
+	if (acpi_disabled("thinkpad") ||
+	    ACPI_ID_PROBE(device_get_parent(dev), dev, thinkpad_ids) == NULL ||
+	    device_get_unit(dev) != 0) 
+		return (ENXIO);
+
+	device_set_desc(dev, "IBM/Lenovo ThinkPad ACPI Extras");
+	return (0);
+}
+
+static int
+acpi_thinkpad_attach(device_t dev)
+{
+	struct acpi_thinkpad_softc	*sc;
+	struct acpi_softc	*acpi_sc;
+	devclass_t		ec_devclass;
+	int			i;
+
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t) __func__);
+
+	sc = device_get_softc(dev);
+	sc->dev = dev;
+	sc->handle = acpi_get_handle(dev);
+
+	acpi_sc = acpi_device_get_parent_softc(dev);
+
+	/* Look for the first embedded controller */
+        if (!(ec_devclass = devclass_find ("acpi_ec"))) {
+		if (bootverbose)
+			device_printf(dev, "Couldn't find acpi_ec devclass\n");
+		return (EINVAL);
+	}
+        if (!(sc->ec_dev = devclass_get_device(ec_devclass, 0))) {
+		if (bootverbose)
+			device_printf(dev, "Couldn't find acpi_ec device\n");
+		return (EINVAL);
+	}
+	sc->ec_handle = acpi_get_handle(sc->ec_dev);
+
+	/* ACPI_SERIAL_BEGIN(thinkpad); */
+
+#if 0
+	/* Get the sysctl tree */
+	sc->sysctl_ctx = device_get_sysctl_ctx(dev);
+	sc->sysctl_tree = device_get_sysctl_tree(dev);
+#endif
+	sysctl_ctx_init(sc->sysctl_ctx);
+	sc->sysctl_tree = SYSCTL_ADD_NODE(sc->sysctl_ctx,
+	    SYSCTL_CHILDREN(acpi_sc->acpi_sysctl_tree), OID_AUTO,
+	    "thinkpad", CTLFLAG_RD, 0, "");
+
+	/* Look for event mask and hook up the nodes */
+	sc->events_mask_supported = ACPI_SUCCESS(acpi_GetInteger(sc->handle,
+	    THINKPAD_NAME_EVENTS_MASK_GET, &sc->events_initialmask));
+
+	if (sc->events_mask_supported) {
+		SYSCTL_ADD_INT(sc->sysctl_ctx,
+		    SYSCTL_CHILDREN(sc->sysctl_tree), OID_AUTO,
+		    "initialmask", CTLFLAG_RD,
+		    &sc->events_initialmask, 0, "Initial eventmask");
+
+		/* The availmask is the bitmask of supported events */
+		if (ACPI_FAILURE(acpi_GetInteger(sc->handle,
+		    THINKPAD_NAME_EVENTS_AVAILMASK, &sc->events_availmask)))
+			sc->events_availmask = 0xffffffff;
+
+		SYSCTL_ADD_INT(sc->sysctl_ctx,
+		    SYSCTL_CHILDREN(sc->sysctl_tree), OID_AUTO,
+		    "availmask", CTLFLAG_RD,
+		    &sc->events_availmask, 0, "Mask of supported events");
+	}
+
+	/* Hook up proc nodes */
+	for (i = 0; acpi_thinkpad_sysctls[i].name != NULL; i++) {
+		if (!acpi_thinkpad_sysctl_init(sc,
+		    acpi_thinkpad_sysctls[i].method))
+			continue;
+
+		SYSCTL_ADD_PROC(sc->sysctl_ctx,
+		    SYSCTL_CHILDREN(sc->sysctl_tree), OID_AUTO,
+		    acpi_thinkpad_sysctls[i].name,
+		    acpi_thinkpad_sysctls[i].access,
+		    sc, i, acpi_thinkpad_sysctl, "I",
+		    acpi_thinkpad_sysctls[i].description);
+	}
+
+	/* ACPI_SERIAL_END(thinkpad); */
+
+	/* Handle notifies */
+	AcpiInstallNotifyHandler(sc->handle, ACPI_DEVICE_NOTIFY,
+	    acpi_thinkpad_notify, dev);
+
+#if 0
+	/* Hook up light to led(4) */
+	if (sc->light_set_supported)
+		sc->led_dev = led_create_state(thinkpad_led, sc, "thinklight",
+		    sc->light_val);
+#endif
+	/* Attach sensors(9). */
+	if (sensor_task_register(sc, acpi_thinkpad_refresh, 5)) {
+		device_printf(sc->dev, "unable to register update task\n");
+		return 1;
+	}
+
+	strlcpy(sc->sensordev.xname, device_get_nameunit(sc->dev),
+	    sizeof(sc->sensordev.xname));
+
+	/* XXX: Temp sensors */
+	for (i = 0; i < 8; ++i) {
+		sc->sensors[i].type = SENSOR_TEMP;
+		sensor_attach(&sc->sensordev, &sc->sensors[i]);
+	}
+	
+	/* Fan RPM sensor */
+	sc->sensors[8].type = SENSOR_FANRPM;
+	sensor_attach(&sc->sensordev, &sc->sensors[8]);
+
+	sensordev_install(&sc->sensordev);
+
+	return (0);
+}
+
+static int
+acpi_thinkpad_detach(device_t dev)
+{
+	int i;
+
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t) __func__);
+
+	struct acpi_thinkpad_softc *sc = device_get_softc(dev);
+
+	/* Disable events and restore eventmask */
+	/* ACPI_SERIAL_BEGIN(thinkpad); */
+	acpi_thinkpad_sysctl_set(sc, ACPI_THINKPAD_METHOD_EVENTS, 0);
+	acpi_thinkpad_sysctl_set(sc, ACPI_THINKPAD_METHOD_EVENTMASK,
+	    sc->events_initialmask);
+	/* ACPI_SERIAL_END(thinkpad); */
+
+	AcpiRemoveNotifyHandler(sc->handle, ACPI_DEVICE_NOTIFY,
+	    acpi_thinkpad_notify);
+
+	sysctl_ctx_free(sc->sysctl_ctx);
+
+#if 0
+	if (sc->led_dev != NULL)
+		led_destroy(sc->led_dev);
+#endif
+	sensordev_deinstall(&sc->sensordev);
+	for (i = 0; i < 9; i++)
+		sensor_detach(&sc->sensordev, &sc->sensors[i]);
+	sensor_task_unregister(sc);
+
+	return (0);
+}
+
+static int
+acpi_thinkpad_eventmask_set(struct acpi_thinkpad_softc *sc, int val)
+{
+	int i;
+	ACPI_OBJECT		arg[2];
+	ACPI_OBJECT_LIST	args;
+	ACPI_STATUS		status;
+
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+	/* ACPI_SERIAL_ASSERT(thinkpad); */
+
+	args.Count = 2;
+	args.Pointer = arg;
+	arg[0].Type = ACPI_TYPE_INTEGER;
+	arg[1].Type = ACPI_TYPE_INTEGER;
+
+	for (i = 0; i < 32; ++i) {
+		arg[0].Integer.Value = i+1;
+		arg[1].Integer.Value = (((1 << i) & val) != 0);
+		status = AcpiEvaluateObject(sc->handle,
+		    THINKPAD_NAME_EVENTS_MASK_SET, &args, NULL);
+
+		if (ACPI_FAILURE(status))
+			return (status);
+	}
+
+	return (0);
+}
+
+static int
+acpi_thinkpad_sysctl(SYSCTL_HANDLER_ARGS)
+{
+	struct acpi_thinkpad_softc	*sc;
+	int			arg;
+	int			error = 0;
+	int			function;
+	int			method;
+	
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+
+	sc = (struct acpi_thinkpad_softc *)oidp->oid_arg1;
+	function = oidp->oid_arg2;
+	method = acpi_thinkpad_sysctls[function].method;
+
+	/* ACPI_SERIAL_BEGIN(thinkpad); */
+	arg = acpi_thinkpad_sysctl_get(sc, method);
+	error = sysctl_handle_int(oidp, &arg, 0, req);
+
+	/* Sanity check */
+	if (error != 0 || req->newptr == NULL)
+		goto out;
+
+	/* Update */
+	error = acpi_thinkpad_sysctl_set(sc, method, arg);
+
+out:
+	/* ACPI_SERIAL_END(thinkpad); */
+	return (error);
+}
+
+static int
+acpi_thinkpad_sysctl_get(struct acpi_thinkpad_softc *sc, int method)
+{
+	ACPI_INTEGER	val_ec;
+	int 		val = 0, key;
+
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+	/* ACPI_SERIAL_ASSERT(thinkpad); */
+
+	switch (method) {
+	case ACPI_THINKPAD_METHOD_EVENTS:
+		acpi_GetInteger(sc->handle, THINKPAD_NAME_EVENTS_STATUS_GET,
+		    &val);
+		break;
+
+	case ACPI_THINKPAD_METHOD_EVENTMASK:
+		if (sc->events_mask_supported)
+			acpi_GetInteger(sc->handle,
+			    THINKPAD_NAME_EVENTS_MASK_GET, &val);
+		break;
+
+	case ACPI_THINKPAD_METHOD_HOTKEY:
+		/*
+		 * Construct the hotkey as a bitmask as illustrated below.
+		 * Note that whenever a key was pressed, the respecting bit
+		 * toggles and nothing else changes.
+		 * +--+--+-+-+-+-+-+-+-+-+-+-+
+		 * |11|10|9|8|7|6|5|4|3|2|1|0|
+		 * +--+--+-+-+-+-+-+-+-+-+-+-+
+		 *   |  | | | | | | | | | | |
+		 *   |  | | | | | | | | | | +- Home Button
+		 *   |  | | | | | | | | | +--- Search Button
+		 *   |  | | | | | | | | +----- Mail Button
+		 *   |  | | | | | | | +------- Thinkpad Button
+		 *   |  | | | | | | +--------- Zoom (Fn + Space)
+		 *   |  | | | | | +----------- WLAN Button
+		 *   |  | | | | +------------- Video Button
+		 *   |  | | | +--------------- Hibernate Button
+		 *   |  | | +----------------- Thinklight Button
+		 *   |  | +------------------- Screen expand (Fn + F8)
+		 *   |  +--------------------- Brightness
+		 *   +------------------------ Volume/Mute
+		 */
+		key = rtcin(THINKPAD_RTC_HOTKEY1);
+		val = (THINKPAD_RTC_MASK_HOME | THINKPAD_RTC_MASK_SEARCH |
+		    THINKPAD_RTC_MASK_MAIL | THINKPAD_RTC_MASK_WLAN) & key;
+		key = rtcin(THINKPAD_RTC_HOTKEY2);
+		val |= (THINKPAD_RTC_MASK_THINKPAD | THINKPAD_RTC_MASK_VIDEO |
+		    THINKPAD_RTC_MASK_HIBERNATE) & key;
+		val |= (THINKPAD_RTC_MASK_ZOOM & key) >> 1;
+		key = rtcin(THINKPAD_RTC_THINKLIGHT);
+		val |= (THINKPAD_RTC_MASK_THINKLIGHT & key) << 4;
+		key = rtcin(THINKPAD_RTC_SCREENEXPAND);
+		val |= (THINKPAD_RTC_MASK_THINKLIGHT & key) << 4;
+		key = rtcin(THINKPAD_RTC_BRIGHTNESS);
+		val |= (THINKPAD_RTC_MASK_BRIGHTNESS & key) << 5;
+		key = rtcin(THINKPAD_RTC_VOLUME);
+		val |= (THINKPAD_RTC_MASK_VOLUME & key) << 4;
+		break;
+
+	case ACPI_THINKPAD_METHOD_BRIGHTNESS:
+		ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_BRIGHTNESS, &val_ec, 1);
+		val = val_ec & THINKPAD_EC_MASK_BRI;
+		break;
+
+	case ACPI_THINKPAD_METHOD_VOLUME:
+		ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_VOLUME, &val_ec, 1);
+		val = val_ec & THINKPAD_EC_MASK_VOL;
+		break;
+
+	case ACPI_THINKPAD_METHOD_MUTE:
+		val = ((val_ec & THINKPAD_EC_MASK_MUTE) ==
+		    THINKPAD_EC_MASK_MUTE);
+		break;
+
+	case ACPI_THINKPAD_METHOD_THINKLIGHT:
+		if (sc->light_get_supported)
+			acpi_GetInteger(sc->ec_handle, THINKPAD_NAME_KEYLIGHT,
+			    &val);
+		else
+			val = sc->light_val;
+		break;
+
+	case ACPI_THINKPAD_METHOD_BLUETOOTH:
+		acpi_GetInteger(sc->handle, THINKPAD_NAME_WLAN_BT_GET, &val);
+		sc->wlan_bt_flags = val;
+		val = ((val & THINKPAD_NAME_MASK_BT) != 0);
+		break;
+
+	case ACPI_THINKPAD_METHOD_WLAN:
+		acpi_GetInteger(sc->handle, THINKPAD_NAME_WLAN_BT_GET, &val);
+		sc->wlan_bt_flags = val;
+		val = ((val & THINKPAD_NAME_MASK_WLAN) != 0);
+		break;
+
+	case ACPI_THINKPAD_METHOD_FANSPEED:
+		if (sc->fan_handle) {
+			if (ACPI_FAILURE(acpi_GetInteger(sc->fan_handle,
+			    NULL, &val)))
+				val = -1;
+		}
+		else {
+			ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_FANSPEED,
+			    &val_ec, 2);
+			val = val_ec;
+		}
+		break;
+
+	case ACPI_THINKPAD_METHOD_FANLEVEL:
+		/*
+		 * The THINKPAD_EC_FANSTATUS register works as follows:
+		 * Bit 0-5 indicate the level at which the fan operates. Only
+		 *       values between 0 and 7 have an effect. Everything
+		 *       above 7 is treated the same as level 7
+		 * Bit 6 overrides the fan speed limit if set to 1
+		 * Bit 7 indicates at which mode the fan operates:
+		 *       manual (0) or automatic (1)
+		 */
+		if (!sc->fan_handle) {
+			ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_FANSTATUS,
+			    &val_ec, 1);
+			val = val_ec & THINKPAD_EC_MASK_FANLEVEL;
+		}
+		break;
+
+	case ACPI_THINKPAD_METHOD_FANSTATUS:
+		if (!sc->fan_handle) {
+			ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_FANSTATUS,
+			    &val_ec, 1);
+			val = (val_ec & THINKPAD_EC_MASK_FANSTATUS) ==
+			    THINKPAD_EC_MASK_FANSTATUS;
+		}
+		else
+			val = -1;
+		break;
+	}
+
+	return (val);
+}
+
+static int
+acpi_thinkpad_sysctl_set(struct acpi_thinkpad_softc *sc, int method, int arg)
+{
+	int			val, step, i;
+	ACPI_INTEGER		val_ec;
+	ACPI_OBJECT		Arg;
+	ACPI_OBJECT_LIST	Args;
+	ACPI_STATUS		status;
+
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+	/* ACPI_SERIAL_ASSERT(thinkpad); */
+
+	switch (method) {
+	case ACPI_THINKPAD_METHOD_EVENTS:
+		if (arg < 0 || arg > 1)
+			return (EINVAL);
+
+		status = acpi_SetInteger(sc->handle,
+		    THINKPAD_NAME_EVENTS_STATUS_SET, arg);
+		if (ACPI_FAILURE(status))
+			return (status);
+		if (sc->events_mask_supported)
+			return acpi_thinkpad_eventmask_set(sc,
+			    sc->events_availmask);
+		break;
+
+	case ACPI_THINKPAD_METHOD_EVENTMASK:
+		if (sc->events_mask_supported)
+			return acpi_thinkpad_eventmask_set(sc, arg);
+		break;
+
+	case ACPI_THINKPAD_METHOD_BRIGHTNESS:
+		if (arg < 0 || arg > 7)
+			return (EINVAL);
+
+		if (sc->cmos_handle) {
+			/* Read the current brightness */
+			status = ACPI_EC_READ(sc->ec_dev,
+			    THINKPAD_EC_BRIGHTNESS, &val_ec, 1);
+			if (ACPI_FAILURE(status))
+				return (status);
+			val = val_ec & THINKPAD_EC_MASK_BRI;
+
+			Args.Count = 1;
+			Args.Pointer = &Arg;
+			Arg.Type = ACPI_TYPE_INTEGER;
+			Arg.Integer.Value = (arg > val) ?
+			    THINKPAD_CMOS_BRIGHTNESS_UP :
+			    THINKPAD_CMOS_BRIGHTNESS_DOWN;
+
+			step = (arg > val) ? 1 : -1;
+			for (i = val; i != arg; i += step) {
+				status = AcpiEvaluateObject(sc->cmos_handle,
+				    NULL, &Args, NULL);
+				if (ACPI_FAILURE(status))
+					break;
+			}
+		}
+		return ACPI_EC_WRITE(sc->ec_dev, THINKPAD_EC_BRIGHTNESS,
+		    arg, 1);
+		break;
+
+	case ACPI_THINKPAD_METHOD_VOLUME:
+		if (arg < 0 || arg > 14)
+			return (EINVAL);
+
+		status = ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_VOLUME,
+		    &val_ec, 1);
+		if (ACPI_FAILURE(status))
+			return (status);
+
+		if (sc->cmos_handle) {
+			val = val_ec & THINKPAD_EC_MASK_VOL;
+
+			Args.Count = 1;
+			Args.Pointer = &Arg;
+			Arg.Type = ACPI_TYPE_INTEGER;
+			Arg.Integer.Value = (arg > val) ?
+			    THINKPAD_CMOS_VOLUME_UP : THINKPAD_CMOS_VOLUME_DOWN;
+
+			step = (arg > val) ? 1 : -1;
+			for (i = val; i != arg; i += step) {
+				status = AcpiEvaluateObject(sc->cmos_handle,
+				    NULL, &Args, NULL);
+				if (ACPI_FAILURE(status))
+					break;
+			}
+		}
+		return ACPI_EC_WRITE(sc->ec_dev, THINKPAD_EC_VOLUME, arg +
+		    (val_ec & (~THINKPAD_EC_MASK_VOL)), 1);
+		break;
+
+	case ACPI_THINKPAD_METHOD_MUTE:
+		if (arg < 0 || arg > 1)
+			return (EINVAL);
+
+		status = ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_VOLUME,
+		    &val_ec, 1);
+		if (ACPI_FAILURE(status))
+			return (status);
+
+		if (sc->cmos_handle) {
+			val = val_ec & THINKPAD_EC_MASK_VOL;
+
+			Args.Count = 1;
+			Args.Pointer = &Arg;
+			Arg.Type = ACPI_TYPE_INTEGER;
+			Arg.Integer.Value = THINKPAD_CMOS_VOLUME_MUTE;
+
+			status = AcpiEvaluateObject(sc->cmos_handle, NULL,
+			    &Args, NULL);
+			if (ACPI_FAILURE(status))
+				break;
+		}
+		return ACPI_EC_WRITE(sc->ec_dev, THINKPAD_EC_VOLUME, (arg==1) ?
+		   val_ec | THINKPAD_EC_MASK_MUTE :
+		   val_ec & (~THINKPAD_EC_MASK_MUTE), 1);
+		break;
+
+	case ACPI_THINKPAD_METHOD_THINKLIGHT:
+		if (arg < 0 || arg > 1)
+			return (EINVAL);
+
+		if (sc->light_set_supported) {
+			Args.Count = 1;
+			Args.Pointer = &Arg;
+			Arg.Type = ACPI_TYPE_INTEGER;
+			Arg.Integer.Value = arg ?
+			    sc->light_cmd_on : sc->light_cmd_off;
+
+			status = AcpiEvaluateObject(sc->light_handle, NULL,
+			    &Args, NULL);
+			if (ACPI_SUCCESS(status))
+				sc->light_val = arg;
+			return (status);
+		}
+		break;
+
+	case ACPI_THINKPAD_METHOD_BLUETOOTH:
+		if (arg < 0 || arg > 1)
+			return (EINVAL);
+
+		val = (arg == 1) ? sc->wlan_bt_flags |
+		    THINKPAD_NAME_MASK_BT :
+		    sc->wlan_bt_flags & (~THINKPAD_NAME_MASK_BT);
+		return acpi_SetInteger(sc->handle, THINKPAD_NAME_WLAN_BT_SET,
+		    val);
+		break;
+
+	case ACPI_THINKPAD_METHOD_FANLEVEL:
+		if (arg < 0 || arg > 7)
+			return (EINVAL);
+
+		if (!sc->fan_handle) {
+			/* Read the current fanstatus */
+			ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_FANSTATUS,
+			    &val_ec, 1);
+			val = val_ec & (~THINKPAD_EC_MASK_FANLEVEL);
+
+			return ACPI_EC_WRITE(sc->ec_dev, THINKPAD_EC_FANSTATUS,
+			    val | arg, 1);
+		}
+		break;
+
+	case ACPI_THINKPAD_METHOD_FANSTATUS:
+		if (arg < 0 || arg > 1)
+			return (EINVAL);
+
+		if (!sc->fan_handle) {
+			/* Read the current fanstatus */
+			ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_FANSTATUS,
+			    &val_ec, 1);
+
+			return ACPI_EC_WRITE(sc->ec_dev, THINKPAD_EC_FANSTATUS,
+			    (arg == 1) ? (val_ec | THINKPAD_EC_MASK_FANSTATUS) :
+			    (val_ec & (~THINKPAD_EC_MASK_FANSTATUS)), 1);
+		}
+		break;
+	}
+
+	return (0);
+}
+
+static int
+acpi_thinkpad_sysctl_init(struct acpi_thinkpad_softc *sc, int method)
+{
+	int 			dummy;
+	ACPI_OBJECT_TYPE 	cmos_t;
+	ACPI_HANDLE		ledb_handle;
+
+	switch (method) {
+	case ACPI_THINKPAD_METHOD_EVENTS:
+		/* Events are disabled by default */
+		return (TRUE);
+
+	case ACPI_THINKPAD_METHOD_EVENTMASK:
+		return (sc->events_mask_supported);
+
+	case ACPI_THINKPAD_METHOD_HOTKEY:
+	case ACPI_THINKPAD_METHOD_BRIGHTNESS:
+	case ACPI_THINKPAD_METHOD_VOLUME:
+	case ACPI_THINKPAD_METHOD_MUTE:
+		/* EC is required here, which was already checked before */
+		return (TRUE);
+
+	case ACPI_THINKPAD_METHOD_THINKLIGHT:
+		sc->cmos_handle = NULL;
+		sc->light_get_supported = ACPI_SUCCESS(acpi_GetInteger(
+		    sc->ec_handle, THINKPAD_NAME_KEYLIGHT, &sc->light_val));
+
+		if ((ACPI_SUCCESS(AcpiGetHandle(sc->handle, "\\UCMS",
+		    &sc->light_handle)) ||
+		    ACPI_SUCCESS(AcpiGetHandle(sc->handle, "\\CMOS",
+		    &sc->light_handle)) ||
+		    ACPI_SUCCESS(AcpiGetHandle(sc->handle, "\\CMS",
+		    &sc->light_handle))) &&
+		    ACPI_SUCCESS(AcpiGetType(sc->light_handle, &cmos_t)) &&
+		    cmos_t == ACPI_TYPE_METHOD) {
+			sc->light_cmd_on = 0x0c;
+			sc->light_cmd_off = 0x0d;
+			sc->cmos_handle = sc->light_handle;
+		}
+		else if (ACPI_SUCCESS(AcpiGetHandle(sc->handle, "\\LGHT",
+		    &sc->light_handle))) {
+			sc->light_cmd_on = 1;
+			sc->light_cmd_off = 0;
+		}
+		else
+			sc->light_handle = NULL;
+
+		sc->light_set_supported = (sc->light_handle &&
+		    ACPI_FAILURE(AcpiGetHandle(sc->ec_handle, "LEDB",
+		    &ledb_handle)));
+
+		if (sc->light_get_supported)
+			return (TRUE);
+
+		if (sc->light_set_supported) {
+			sc->light_val = 0;
+			return (TRUE);
+		}
+
+		return (FALSE);
+
+	case ACPI_THINKPAD_METHOD_BLUETOOTH:
+	case ACPI_THINKPAD_METHOD_WLAN:
+		if (ACPI_SUCCESS(acpi_GetInteger(sc->handle,
+		    THINKPAD_NAME_WLAN_BT_GET, &dummy)))
+			return (TRUE);
+		return (FALSE);
+
+	case ACPI_THINKPAD_METHOD_FANSPEED:
+		/* 
+		 * Some models report the fan speed in levels from 0-7
+		 * Newer models report it contiguously
+		 */
+		sc->fan_levels = (ACPI_SUCCESS(AcpiGetHandle(sc->handle, "GFAN",
+		    &sc->fan_handle)) ||
+		    ACPI_SUCCESS(AcpiGetHandle(sc->handle, "\\FSPD",
+		    &sc->fan_handle)));
+		return (TRUE);
+
+	case ACPI_THINKPAD_METHOD_FANLEVEL:
+	case ACPI_THINKPAD_METHOD_FANSTATUS:
+		/* 
+		 * Fan status is only supported on those models,
+		 * which report fan RPM contiguously, not in levels
+		 */
+		if (sc->fan_levels)
+			return (FALSE);
+		return (TRUE);
+
+	case ACPI_THINKPAD_METHOD_THERMAL:
+		if (ACPI_SUCCESS(acpi_GetInteger(sc->ec_handle,
+		    THINKPAD_NAME_THERMAL_GET, &dummy))) {
+			sc->thermal_updt_supported =
+			    ACPI_SUCCESS(acpi_GetInteger(sc->ec_handle,
+			    THINKPAD_NAME_THERMAL_UPDT, &dummy));
+			return (TRUE);
+		}
+		return (FALSE);
+	}
+	return (FALSE);
+}
+
+static void
+acpi_thinkpad_notify(ACPI_HANDLE h, UINT32 notify, void *context)
+{
+	int		event, arg, type;
+	device_t	dev = context;
+	struct acpi_thinkpad_softc *sc = device_get_softc(dev);
+
+	ACPI_FUNCTION_TRACE_U32((char *)(uintptr_t)__func__, notify);
+
+	if (notify != 0x80)
+		device_printf(dev, "Unknown notify\n");
+
+	for (;;) {
+		acpi_GetInteger(acpi_get_handle(dev), THINKPAD_NAME_EVENTS_GET,
+		    &event);
+
+		if (event == 0)
+			break;
+
+		type = (event >> 12) & 0xf;
+		arg = event & 0xfff;
+		switch (type) {
+		case 1:
+			if (!(sc->events_availmask & (1 << (arg - 1)))) {
+				device_printf(dev, "Unknown key %d\n", arg);
+				break;
+			}
+
+			/* Notify devd(8) */
+			device_printf(dev, "THINKPAD event: %u\n",
+			    (arg & 0xff));
+			acpi_UserNotify("THINKPAD", h, (arg & 0xff));
+			break;
+		default:
+			break;
+		}
+	}
+}
+
+static void
+acpi_thinkpad_refresh(void *arg)
+{
+	struct acpi_thinkpad_softc *sc = (struct acpi_thinkpad_softc *)arg;
+	char temp_cmd[] = "TMP0";
+	int data, i;
+	ACPI_INTEGER speed;
+
+	for (i = 0; i < 8; i++) {
+		temp_cmd[3] = '0' + i;
+		
+                /*
+                 * The TMPx methods seem to return +/- 128 or 0
+                 * when the respecting sensor is not available
+                 */
+		sc->sensors[i].flags &= ~SENSOR_FINVALID;
+                if (ACPI_FAILURE(acpi_GetInteger(sc->ec_handle, temp_cmd,
+                    &data)) || ABS(data) == 128 || data == 0) {
+			sc->sensors[i].flags |= SENSOR_FINVALID;
+                        data = 0;
+		}
+                else if (sc->thermal_updt_supported) {
+                        /* XXX: Temperature is reported in tenth of Kelvin */
+                        data = (data - 2732 + 5) / 10;
+		}
+		sc->sensors[i].value = data * 1000000 + 273150000;
+        }
+	
+	sc->sensors[8].flags &= ~SENSOR_FINVALID;
+	if (sc->fan_handle) {
+		if (ACPI_FAILURE(acpi_GetInteger(sc->fan_handle,
+		    NULL, &data)))
+			sc->sensors[8].flags |= SENSOR_FINVALID;
+                        data = -1;
+        }
+        else {
+                ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_FANSPEED, &speed, 2);
+                data = speed;
+        }
+
+	sc->sensors[8].value = data;
+}
diff --git a/sys/platform/pc32/conf/files b/sys/platform/pc32/conf/files
--- a/sys/platform/pc32/conf/files
+++ b/sys/platform/pc32/conf/files
@@ -72,6 +72,7 @@ dev/serial/dgb/dgm.c			optional	dgm
 ${OSACPI_MD_DIR}/acpi_machdep.c		optional        acpi
 ${OSACPI_MD_DIR}/acpi_wakeup.c		optional        acpi
 ${OSACPI_MD_DIR}/acpi_toshiba.c		optional        acpi_toshiba acpi
+${ACPICA_DIR}/acpi_thinkpad/acpi_thinkpad.c optional	acpi_thinkpad acpi
 acpi.h					optional	acpi		\
 	dependency	"$S/${ACPICA_DIR}/include/acpi.h"		\
 	compile-with	"cp $S/${ACPICA_DIR}/include/acpi.h ${.OBJDIR}/"	\



From hasso at estpak.ee  Thu Mar 20 03:49:13 2008
From: hasso at estpak.ee (Hasso Tepper)
Date: Thu, 20 Mar 2008 03:49:13 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Some questions regarding ACPI
In-Reply-To: <200803191322.46366.hasso@estpak.ee>
Message-ID: <200803201237.28823.hasso@estpak.ee>

Hasso Tepper wrote:
> There is also one fatal issue -laptop locks up hardly (no panic) while 
> unloading module. Any idea regarding this is welcome.

Nevermind, solved.


-- 
Hasso




From dillon at apollo.backplane.com  Fri Mar 21 19:24:01 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Fri, 21 Mar 2008 19:24:01 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: panic: assertion: hammer_btree_cmp(cursor->left_bound,	&cursor->node->ondisk->elms[0].leaf.base) <= 0 in btree_split_leaf
In-Reply-To: <200802232204.m1NM4cxd046264@apollo.backplane.com>
Message-ID: <200803220212.m2M2CiAY014435@apollo.backplane.com>

:While trying to find a procedure to reliably reproduce the panic
:I reported last time, I caught a different panic (uploaded at
: ~y0netan1/crash/9/ on my leaf account).  I wrote the following shell
:script (make sure to edit variables DISKS and MOUNTPT before using this
:script or it may trash your system):

    Ok, I believe I have fixed the left_bound assertion.  I also believe
    I have fixed the node ref count assertion on umount.

    There is currently one unfixed assertion related to the I/O
    path... sometimes the bp is being improperly disassociated from the
    related HAMMER structure.

    The full-filesystem case is still not being handled so don't test that :-)

					    -Matt





From c.turner at 199technologies.org  Sun Mar 23 09:48:29 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Sun, 23 Mar 2008 09:48:29 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
Message-ID: <47E6870C.4080709@199technologies.org>

I'm finally getting around to doing 1.12 upgrades, and have setup a 
separate machine to do my bulk package builds / upgrades etc,
so as not to disrupt my 'dev server' while things are being
built / tested

However, this seems kind of wasteful - the only purpose of this machine
is to build packages against a specific release..
And since building packages for a particular release generally requires 
only the userland, appropriate headers and correct 'uname' output - so:

it seems like if spoofing uname is configured inside a jail,
the next (or previous..) release can be installed into a jail and
used for building / testing packages without the overhead of a VM or 
maintaining a separate physical host

I did a quick scan of the tree to see what this would take, and, high 
level, it seems like only the following changes would need to be made:

- update struct jail to add a 'osrelease' string
  (implies bumping 'jail api' to 2?)
- update jail(8) to actually pass this information along
- update sys_uname to test ucred for jailed processes, and
  use the struct jail osrelease if appropriate
- similarly update sysctl kern.osrelease to support jail spoofing
  (if possible - didn't get this far in the research yet)
  could be less of a problem for builds, as I think most things use
 uname(1) ... but good to keep the environment consistent I suppose..
I'm still a bit confused as to how 'osrelease' is defined - everything
I'm finding is showing up as extern char[] .. perhaps this is something 
in the build I'm not familiar with?

also,

is the so-called 'stupid hackery' in sys_uname needed still?

Before I start any coding, does this:

- sound like something useful
- sound like the right approach
Thinking this could have wider useful implications e.g. for pkgbox
& so on -  for example setting up automated bulks w/various combinations 
of pkgsrc and releases, etc.

Cheers,

- Chris





From corecode at fs.ei.tum.de  Sun Mar 23 10:06:38 2008
From: corecode at fs.ei.tum.de (Simon 'corecode' Schubert)
Date: Sun, 23 Mar 2008 10:06:38 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <47E68C74.3080808@fs.ei.tum.de>

Chris Turner wrote:
I did a quick scan of the tree to see what this would take, and, high 
level, it seems like only the following changes would need to be made:
brave investigation.  but you could also simply set UNAME_r :)

sweatshorts % uname -r
1.13.0-DEVELOPMENT
sweatshorts % UNAME_r=1.12-RELEASE uname -r
1.12-RELEASE
I think that's good enough :D

cheers
  simon
--
Serve - BSD     +++  RENT this banner advert  +++    ASCII Ribbon   /"\
Work - Mac      +++  space for low ????????? NOW!1  +++      Campaign     \ /
Party Enjoy Relax   |   http://dragonflybsd.org      Against  HTML   \
Dude 2c 2 the max   !   http://golden-apple.biz       Mail + News   / \




From c.turner at 199technologies.org  Sun Mar 23 10:50:13 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Sun, 23 Mar 2008 10:50:13 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <47E69656.8080605@199technologies.org>

Simon 'corecode' Schubert wrote:
brave investigation.  but you could also simply set UNAME_r :)
Doh! Thanks for the tip!

they should change the phrase from RTFM to 'Carefully RTFM' :)

well.. scratch that change then. 1 less patch to write.

- Chris





From c.turner at 199technologies.org  Sun Mar 23 11:15:52 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Sun, 23 Mar 2008 11:15:52 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <47E69C7C.8010109@199technologies.org>

Chris Turner wrote:
Simon 'corecode' Schubert wrote:
brave investigation.  but you could also simply set UNAME_r :)

for the record - if anyone's interested - adding a line e.g.:

ALL_ENV+= UNAME_r=1.12-RELEASE

to mk.conf looks like it -might- work ..

(unless wants to chime in & verify)





From joerg at britannica.bec.de  Sun Mar 23 11:46:53 2008
From: joerg at britannica.bec.de (Joerg Sonnenberger)
Date: Sun, 23 Mar 2008 11:46:53 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <20080323181428.GA2099@britannica.bec.de>

On Sun, Mar 23, 2008 at 01:41:42PM -0400, Chris Turner wrote:
> they should change the phrase from RTFM to 'Carefully RTFM' :)

RTFMAI -- Read The Fine Manual Again, Idiot.

Joerg




From dillon at apollo.backplane.com  Sun Mar 23 20:05:36 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Sun, 23 Mar 2008 20:05:36 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
Message-ID: <200803240257.m2O2voNH038355@apollo.backplane.com>

    Here's an update on the HAMMER work!

    Current status:

    * Passes all standard filesystem stress tests and buildworld will
      run with a HAMMER /usr/obj.  Large histories are able to accumulate
      without effecting performance.

    * Pruning and reblocking code is in and partially tested, but now needs
      more stringent testing.

    * Full historical access appears to be working but needs testing.
      Note that a sync is still needed to flush dirty cached data prior
      to acquiring a timestamp for the 'snapshot' to be set in stone.
      (dirty data cached in-memory has no historical tags and must be
      committed to physical disk before it can be accessed historically).


    Current bugs:

    * There is one known bug in the standard operations code paths
      that results in an assertion in HAMMER's I/O subsystem.

    * There are probably bugs in the reblocking and/or pruning code.  More
      likely in the reblocking code.


    There are two big-ticket and several little-ticket items left.  HAMMER
    will officially go Alpha when the big-ticket items are done, and beta
    when we get a few of the little-ticket items done.

    Big ticket items left:

    * UNDO (crash recovery) code.  Currently it writes out undo records but
      they are not yet sequenced, buffer writes are not yet ordered, and
      there is no mount-time recovery code yet.

      This is the last item needed before HAMMER can go operational.

    * Filesystem full handling.  Currently no space is reserved for dirty
      cached data so it is possible to create/write files and for HAMMER
      to not have sufficient space left on-disk to flush it.


    Little ticket items:

    * Automated reblocking (currently these functions are manually
      initialized via the hammer utility).

    * I/O clustering and preliminary BMAP op when writing out large files.

    * CRC checking (CRC fields are reserved but not entirely generated yet
      and not yet checked at all).

    * Disaster Recovery filesystem scan.

    * Boot support.

    I expect all of these items and more to be handled by the 2.0 release
    in July.

			    Additional HAMMER capabilities
				(no timeline yet)

    * Adding, removing, and resizing a HAMMER filesystem's backing store.

			Ultimate Goals and working towards them
				(no timeline yet)

    Our ultimate goal with HAMMER and DragonFly in general is to support
    fully cache coherent replication in a multi-machine environment.  This
    involves several steps and networking protocols.

    * Replication of synchronization streams based on the UNDO log.  If
      resynchronizing to a target which is too old a B-Tree scan will
      likely be required.

    * Cache coherency protocols for machine-machine coherency for both
      replicated and remote-HAMMER access.

    I have no time frame for these items yet.  It will depend on how quickly
    HAMMER moves to Alpha and Beta status.  I will say, however, now
    that HAMMER's on-disk format has solidified, that I have a very precise
    understanding of the protocols that will be needed to accomplish fully
    cache coherent remote access for both replicated and non-replicated
    (remote mount style) access.

    And, as you know, fully coherent filesystem access across machines is
    going to be the basis for DragonFly's clustering across said machines.

    In summary, things are progressing very well.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From justin at shiningsilence.com  Sun Mar 23 20:10:13 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Sun, 23 Mar 2008 20:10:13 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <53758.192.168.0.252.1206327873.squirrel@www.shiningsilence.com>

On Sun, March 23, 2008 12:36 pm, Chris Turner wrote:

> it seems like if spoofing uname is configured inside a jail,
> the next (or previous..) release can be installed into a jail and
> used for building / testing packages without the overhead of a VM or
> maintaining a separate physical host

If you don't need a jail to spoof uname, as others posted, you can
installworld into a chroot and build everything you want there using
Joerg's spiffy pbulk.  That's what I'm doing on pkgbox now; I can hand you
my somewhat terse notes if you want.  It would be relatively easy to set
up the configuration you're talking about.





From sepherosa at gmail.com  Sun Mar 23 20:18:20 2008
From: sepherosa at gmail.com (Sepherosa Ziehau)
Date: Sun, 23 Mar 2008 20:18:20 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <ea7b9c170803232012n2f27f893tf1d756d7c9770419@mail.gmail.com>

On Mon, Mar 24, 2008 at 2:14 AM, Joerg Sonnenberger
<joerg at britannica.bec.de> wrote:
> On Sun, Mar 23, 2008 at 01:41:42PM -0400, Chris Turner wrote:
>  > they should change the phrase from RTFM to 'Carefully RTFM' :)
>
>  RTFMAI -- Read The Fine Manual Again, Idiot.

http://leaf.dragonflybsd.org/~sephe/rtfm.jpg

:D

>
>  Joerg
>



-- 
Live Free or Die




From justin at shiningsilence.com  Sun Mar 23 20:38:30 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Sun, 23 Mar 2008 20:38:30 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: GSoC 2008 - mentors signup
Message-ID: <53885.192.168.0.252.1206329503.squirrel@www.shiningsilence.com>

If you are planning to be a mentor for a Summer of Code project, please
sign up here for the mentors mailing list:

http://groups.google.com/group/google-summer-of-code-mentors-list

If you've already signed up, your subscription should be set up tomorrow.





From justin at shiningsilence.com  Sun Mar 23 21:12:01 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Sun, 23 Mar 2008 21:12:01 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: GSoC 2008 - mentors signup
In-Reply-To: <53885.192.168.0.252.1206329503.squirrel@www.shiningsilence.com>
Message-ID: <54025.192.168.0.252.1206331572.squirrel@www.shiningsilence.com>

Also!

If you are a potential mentor and you have not done so yet:

http://code.google.com/soc/mentor_step1.html

Get yourself registered as a mentor for the Summer of Code project.  Once
you are in there, check off DragonFly in the "My Profile" section.

You will need a Google Account if you don't have one:

http://www.google.com/accounts

This will add you to the list of mentors in the Google Summer of Code web
application, so you can review/be attached to projects.

A guide is available if you want more information:

http://groups.google.com/group/google-summer-of-code-announce/web/guide-to-the-gsoc-web-app-for-mentors-and-organization-administrators






From c.turner at 199technologies.org  Mon Mar 24 04:29:28 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Mon, 24 Mar 2008 04:29:28 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <47E78ECE.4070307@199technologies.org>

Justin C. Sherrill wrote:
If you don't need a jail to spoof uname, as others posted, you can
installworld into a chroot and build everything you want there using
Joerg's spiffy pbulk.  That's what I'm doing on pkgbox now; I can hand you
my somewhat terse notes if you want.  It would be relatively easy to set
up the configuration you're talking about.
cheers - I guess I thought incorrectly that something 'special' was 
needed to get the uname to change .. have been using the legacy bulks in 
chroots / jails (for 'same os' builds) as I haven't quite migrated to 
pbulk yet ..

thanks for the help offer - I'll ask if I run into trouble.




From dillon at apollo.backplane.com  Mon Mar 24 08:28:49 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Mon, 24 Mar 2008 08:28:49 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <200803241500.m2OF0CG8043760@apollo.backplane.com>


:http://leaf.dragonflybsd.org/~sephe/rtfm.jpg
:
::D

    Ho!

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From elekktretterr at exemail.com.au  Mon Mar 24 09:10:15 2008
From: elekktretterr at exemail.com.au (Petr Janda)
Date: Mon, 24 Mar 2008 09:10:15 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
In-Reply-To: <200803240257.m2O2voNH038355@apollo.backplane.com>
Message-ID: <200803250138.49775.elekktretterr@exemail.com.au>


>
>     And, as you know, fully coherent filesystem access across machines is
>     going to be the basis for DragonFly's clustering across said machines.
>
>     In summary, things are progressing very well.
>


Hi Matt,
That's good to know things are going so well. Got a question. If memory serves 
me right, initially there was also going to be a thing called ANVIL, I can't 
remember what it was supposed to do and whether its still in your design. 
Could you elaborate a little?

Thanks,
Petr




From dillon at apollo.backplane.com  Mon Mar 24 14:12:11 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Mon, 24 Mar 2008 14:12:11 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
In-Reply-To: <200803240257.m2O2voNH038355@apollo.backplane.com>
Message-ID: <200803242100.m2OL0nWV046868@apollo.backplane.com>


:Hi Matt,
:That's good to know things are going so well. Got a question. If memory serves 
:me right, initially there was also going to be a thing called ANVIL, I can't 
:remember what it was supposed to do and whether its still in your design. 
:Could you elaborate a little?
:
:Thanks,
:Petr

    It's not really in the HAMMER design any more, primarily because HAMMER's
    volume model seems to work fine as-is.  Ultimately something like ANVIL
    (a block storage manager) would prove beneficial to the project but it
    would be treated as a separate project.  HAMMER's redundancy model is
    going to be baesd around replication and clustering.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From tgen at netphreax.net  Mon Mar 24 18:31:37 2008
From: tgen at netphreax.net (Thomas E. Spanjaard)
Date: Mon, 24 Mar 2008 18:31:37 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
In-Reply-To: <200803240257.m2O2voNH038355@apollo.backplane.com>
Message-ID: <47E85337.2070407@netphreax.net>

Matthew Dillon wrote:
    * Full historical access appears to be working but needs testing.
      Note that a sync is still needed to flush dirty cached data prior
      to acquiring a timestamp for the 'snapshot' to be set in stone.
      (dirty data cached in-memory has no historical tags and must be
      committed to physical disk before it can be accessed historically).
Wouldn't making timestamp queries (at least from userland) enforce a 
sync on the volume in question be useful here?
--
        Thomas E. Spanjaard
        tgen at netphreax.net
Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00005.pgp
Type: application/octet-stream
Size: 186 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080324/3077333f/attachment.obj>

From dillon at apollo.backplane.com  Mon Mar 24 20:10:12 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Mon, 24 Mar 2008 20:10:12 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
In-Reply-To: <200803240257.m2O2voNH038355@apollo.backplane.com>
Message-ID: <200803250302.m2P32qLP050160@apollo.backplane.com>


:Wouldn't making timestamp queries (at least from userland) enforce a 
:sync on the volume in question be useful here?
:-- 
:         Thomas E. Spanjaard
:         tgen at netphreax.net

    Making the 'hammer now' command do a sync() is a good idea.  I will
    make that change right now so it doesn't get lost.

    Here's a general overview of the issues involved with having historical
    access to the filesystem:

				----------------

    Recording the timestamps in the in-memory cache, for a finer-grained
    snapshot capability, is doable but has its own issues.  Here's an
    illustration:

    open()  create file
    write() append 4K	(file size now 4K)
    write() append 4K	(file size now 8K)
    write() append 4K	(file size now 12K)
    write() append 4K	(file size now 16K)

    Now NONE of this has gone to disk yet, it's entirely in the in-memory
    cache.  The inode is in the in-memory cache.  The data is stored in
    the buffer cache.  Even the directory entry for the file that we
    just created is still in the in-memory cache (HAMMER caches the raw
    records it intends to commit later on).

    If I wanted to be able to acquire a timestamp between each write and
    'see' a snapshot of the file as of any point in the above sequence,
    then every write would also have to allocate a copy of the inode
    (because it changes size on each write).

    The data has the same problem though with a slightly different example.
    Lets say each write() was a seek-write, overwriting the previous data.
    Now with every write() I would have to allocate a copy of the data
    being overwritten.  This is complicated by the fact that the buffer
    cache has no clue about 'historical' accesses, so I would not be able
    to use the buffer cache to cache the data.

    There's also another problem and that is with the efficiency of the
    topology on-disk.  Even if I maintained all the copies of the inode
    and all the copies of the data in-memory, I would still have to sync
    all those copies to disk in order for things to remain historically
    coherent (whether it be in-cache or on-disk).  This would result in
    hundreds or even thousands of copies of the inode on-disk, not to
    mention potentially many copies of the data.

    I just don't want to do that right now, at least not as a default.  A
    lot of performance would be lost.  Hence a sync() is needed if
    you want to create a demark which you can accurately snapshot.

				-------------

    Here's a quick synopsis of how the cache would operate in a clustered
    filesystem:

    In order to properly integrate with in-memory caches, a wider cache
    coherency infrastructure is needed between machines such that
    modifications made on one machine proactively invalidate those
    protions of the cache(s) on other machines.  At the same time, any
    'dirty' cache data, for example when a file is created or written to,
    must lock the cache space in question on all other machines.
    The cache space in this case is not just the file data, but also the
    related namespaces (for creations, deletions, and renames).  Attempts
    to access locked spaces from other machines in the cluster would have
    to force a flush to the filesystem backing store and lower the cache
    states for the effected information on the original machine from dirty
    to shared-read-only.

    It will be easiest to integrate the cache coherency information into
    the buffer cache and namecache themselves.  Once a machine has dirtied
    an in-memory cache element... for example part of the namespace when
    creating a file or chunks of data written within a file, that machine
    must have a free hand to make further modifications to the cache spaces
    involved without further interaction with other machines.

				-------------

    Now, if you think of those two major elements you can see that they
    actually fit together quite well.  If I were to attempt to maintain
    transactional coherency on a per-system-call basis then the cache
    granularity between machines would have to be much, much smaller then
    our current in-memory caching elements provide.  That would become
    a really nasty coding problem.  So I don't even want to begin to
    complate transactional coherency at a finer-grain then sync() or
    fsync() until long after we actually have clustering working.

						-Matt





From elekktretterr at exemail.com.au  Mon Mar 24 21:56:58 2008
From: elekktretterr at exemail.com.au (Petr Janda)
Date: Mon, 24 Mar 2008 21:56:58 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
In-Reply-To: <200803240257.m2O2voNH038355@apollo.backplane.com>
Message-ID: <200803251516.16407.elekktretterr@exemail.com.au>

So is it needed to run hammer now in order to "create" a snapshot? What would 
I do in situation like this: got a hammer filesystem and couple of the files 
change on day to day basis. Then a week later I needed to access one of the 
files, in exactly the state they were 7 days ago.

Cheers,
Petr




From dillon at apollo.backplane.com  Mon Mar 24 22:34:15 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Mon, 24 Mar 2008 22:34:15 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
In-Reply-To: <200803240257.m2O2voNH038355@apollo.backplane.com>
Message-ID: <200803250526.m2P5QZ5X051081@apollo.backplane.com>


:So is it needed to run hammer now in order to "create" a snapshot? What would 
:I do in situation like this: got a hammer filesystem and couple of the files 
:change on day to day basis. Then a week later I needed to access one of the 
:files, in exactly the state they were 7 days ago.
:
:Cheers,
:Petr

    No, you do not have to run 'hammer now' to create a snapshot.  The
    kernel syncs all filesystems every 30 seconds, so if you do nothing
    at all you get a snapshot granularity of 30 seconds.

    Where you would use 'hammer now' is if you wanted the most current
    snapshot possible for the purpose of, say, backing up your filesystem
    to another machine.  You might do something like this:

	set timestamp = `hammer now`
	cpdup /mountpoint/@@$timestamp targethost:/somepath

    But if you didn't care about that you could just go back far enough
    that you get a stable historical view... e.g. go back 1 minute and you
    would have a stable view into your filesystem.

	set timestamp = `hammer stamp 60s`		<------ doesn't sync
	cpdup /mountpoint/@@$timestamp targethost:/somepath


    Ultimately the idea of managing filesystems this way is to still do
    regular backups from your production machine to your backup machine
    (ultimately by way of replication), with both running HAMMER, but only
    retain a limited amount of history on the production box.  You might
    desire to retain only one week's worth of history on the production box,
    retain one month's history on your local backup box, and retain a very
    granular one year's worth of history on your remote backup box.

    Come to think of it, I should add some more directives to the
    'hammer prune' command to make that easier to specify.

    Until I implement a live replication 'feed' the minimum granularity on
    the backup box will be how often you do your backups (e.g. once a day),
    and you can prune it into more granular forms from that starting point.
    Once we have a live replication feed the backup box will have the same
    30-second granularity that the production machine has.

    A major bullet point for this style of management is that the retention
    policy on the various boxes can be different even though they are
    all slaved off the same production filesystem.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From justin at shiningsilence.com  Tue Mar 25 05:58:49 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Tue, 25 Mar 2008 05:58:49 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: SoC - student signups
Message-ID: <58180.65.106.147.226.1206449676.squirrel@www.shiningsilence.com>

Here's a quick link roundup:

Are you a student?  Put in your application for a Google Summer of Code here:

http://code.google.com/soc/2008/student_signup.html

Student guide:
http://groups.google.com/group/google-summer-of-code-announce/web/guide-to-the-gsoc-web-app-for-student-applicants

Are you a mentor?  (That means hasso, hsu, sephe, matthias, TGEN, and
corecode right now)

Student proposals will show up on the mentor page, linked below.  You will
get to rate them, and take the one(s) that you want to mentor.

Mentor page:
http://code.google.com/soc/2008/mentor_home.html
Mentor guide:
http://groups.google.com/group/google-summer-of-code-announce/web/guide-to-the-gsoc-web-app-for-mentors-and-organization-administrators

If you are a mentor and are communicating with potential students, send
them the URLs above for student signup and the student guide; work with
them if they ask for advice on what to say in the application.  They can
resubmit up to 20 times if they want to correct it.

Deadline is March 31st.






From noah.yan at gmail.com  Thu Mar 27 20:17:48 2008
From: noah.yan at gmail.com (Yonghong Yan)
Date: Thu, 27 Mar 2008 20:17:48 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: About DFBSD.64
In-Reply-To: <47EB0B5B.5020802@gmail.com>
Message-ID: <59521b110803272015y1cc8cc39uc93f154ed36e0505@mail.gmail.com>

thanks for your interest.

I owe to everybody for any update or work in the past four months. so
many things happen in my work and my family (they are all good:) and
keep me extremely busy. But i am not leaving and will be back on this
soon.

the latest sources are in http://repo.or.cz/w/dragonfly/port-amd64.git
, I did have a compiled kernel long time before, but I have to break
it to work on the pmap. you can pick up from there. TGEN will help you
a lot, also keep me posted too, if you like.

Noah

On Wed, Mar 26, 2008 at 9:50 PM, Sdavtaker <sdavtaker at gmail.com> wrote:
> Hello,
>  Im applying to GSoC to work in the x64 version of DFBSD with TGEN, i
>  found some work already done in the repository and some mails in the
>  archive from you.
>  I was wondering if you already had a working compiled kernel in AMD64
>  machine and what was not working yet to continue that work.
>  Thanks for any info.
>  Sdav
>




From dillon at apollo.backplane.com  Sat Mar 29 13:27:43 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Sat, 29 Mar 2008 13:27:43 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 29-Mar-2008
Message-ID: <200803292022.m2TKMLGe004942@apollo.backplane.com>

    Good progress continues to be made.  HAMMER survived acting as my
    LAN backup machine (in full historical mode) for almost a week before
    it hit an assertion.  I've fixed that issue and believe that the core
    filesystem implementation code is now 'very stable'.

    Note that the recent commit will result in many more 'hammer_lock_ex:'
    messages on the console then you may have previously observed.  This is
    due to the way object id's are allocated in the face of parallel 
    modifications to the filesystem, resulting in too much locality of
    reference in the B-Tree.  I do intend to improve it.

    I am still working on the two major items needed before HAMMER can be
    declared operational, those being the filesystem full handling and the
    undo/recovery-on-mount code.  These are the last 'hard' bits left in
    the design.

    With exception to filling up the filesystem, which *will* create a mess,
    and noting that no crash recovery code exists yet (so you have to newfs
    it if you crash), I'd appreciate it if interested parties could test
    the other functions of the filesystem, in particular the pruning and
    reblocking functions (man hammer), and the historical access functions.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From dillon at apollo.backplane.com  Sun Mar 30 15:11:03 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Sun, 30 Mar 2008 15:11:03 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Need ideas on how to solve an st_ino/st_dev test issue for HAMMER.
Message-ID: <200803302207.m2UM7BCp016402@apollo.backplane.com>

    Here's the problem, given historical access softlinks as shown below:

test30# ls -lda cra*
drwxr-xr-x  1 root  wheel  Mar 29 13:04 crater
lrwxr-xr-x  1 root  wheel  Mar 29 18:57 crater.20080329 -> crater@@0x47eef383
lrwxr-xr-x  1 root  wheel  Mar 30 01:24 crater.20080330 -> crater@@0x47ef4e29
-rw-r--r--  2 root  wheel  Mar 30 01:24 crater.log

    The problem is that if I do this:

    diff -r crater.20080329/var/log crater.20080330/var/log

    Diff just returns without actually diffing anything.  The reason is
    because diff checks st_ino and st_dev and believes the directories/files
    to be identical because they match.

    I considered munging the inode number for historical accesses, but
    that would seriously break NFS exports which try to access historical
    files and directories.  Right now NFS *is* able to distinguish between
    the two because NFS handles are 128-bit-wide entities, so I can encode
    the as-of transaction id as part of the filehandle.  But userland
    programs only have access to a 64-bit-wide inode so userland still
    believes the files to be identical.

    st_dev is only 32 bits, carefully munging it is an option if we
    could figure out a way to do it, but I'd rather not.

    I am considering using st_gen but then we'd have to patch third
    party software to test st_gen along with everything else.  This may
    be the only workable solution, though, and only a few programs would
    need to be patched.  st_gen is only 32 bits but it would solve the
    problem as we would be able to use all 32 bits.

    If anyone has any bright ideas, including 'leave it alone', I'm all
    ears.

						-Matt





From justin at shiningsilence.com  Mon Mar 31 10:40:42 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Mon, 31 Mar 2008 10:40:42 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: SoC student applications due by 5PM PDT tomorrow
In-Reply-To: <1942.192.168.0.242.1206930479.squirrel@www.shiningsilence.com>
Message-ID: <11892.67.108.184.175.1206984967.squirrel@www.shiningsilence.com>

On Sun, March 30, 2008 10:27 pm, Justin C. Sherrill wrote:
> SoC students:
>
> If you have an application to submit for DragonFly/Summer of Code, please
> do so by 17:00 Pacific time on the 31st - that's tomorrow, at least for
> me.

The deadline for student proposals has been extended to April 7th; all
other dates move forward one week to acommodate.

This is a good time to update existing applications or submit new ones. 
Talk to your (potential) mentors if you are curious.






From nthery at gmail.com  Mon Mar 31 11:29:49 2008
From: nthery at gmail.com (Nicolas Thery)
Date: Mon, 31 Mar 2008 11:29:49 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
Message-ID: <64fc43b0803311126na7d0b27obaa9d35bac6d32ee@mail.gmail.com>

Hello,

Now that the release is over, I'll try to get rid of zones and migrate
allocations to objcache.

Here is a 1st patch that migrate struct proc.  I'll commit it in a
couple of days if nobody objects.

I'm also implementing a way to monitor objcache statistics.  So far,
I've hacked sth similar to
sysctl vm.zone: stats are returned in one giant string, one line per
cache.  That's simple but ugly and hard to read because there are
quite a few stats per cache.

So I'm thinking about implementing a small tool, ocstat, that extracts
stats from sysctl the way ps(1) does (thru libkvm iirc) and formats it
in various ways.  What do you think?

Cheers,
Nicolas

Index: src2/sys/kern/kern_exit.c
===================================================================
--- src2.orig/sys/kern/kern_exit.c	2008-03-31 08:05:59.139796000 +0200
+++ src2/sys/kern/kern_exit.c	2008-03-31 10:31:39.000000000 +0200
@@ -834,7 +834,7 @@ loop:
 			}

 			vm_waitproc(p);
-			zfree(proc_zone, p);
+			objcache_put(proc_cache, p);
 			nprocs--;
 			return (0);
 		}
Index: src2/sys/kern/kern_proc.c
===================================================================
--- src2.orig/sys/kern/kern_proc.c	2008-03-31 08:05:59.139918000 +0200
+++ src2/sys/kern/kern_proc.c	2008-03-31 10:31:39.000000000 +0200
@@ -84,7 +84,7 @@ u_long pgrphash;
 struct proclist allproc;
 struct proclist zombproc;
 struct spinlock allproc_spin;
-vm_zone_t proc_zone;
+struct objcache* proc_cache;
 vm_zone_t lwp_zone;
 vm_zone_t thread_zone;

@@ -131,7 +131,7 @@ procinit(void)
 	spin_init(&allproc_spin);
 	pidhashtbl = hashinit(maxproc / 4, M_PROC, &pidhash);
 	pgrphashtbl = hashinit(maxproc / 4, M_PROC, &pgrphash);
-	proc_zone = zinit("PROC", sizeof (struct proc), 0, 0, 5);
+	proc_cache = objcache_create_simple(M_PROC, sizeof(struct proc));
 	lwp_zone = zinit("LWP", sizeof (struct lwp), 0, 0, 5);
 	thread_zone = zinit("THREAD", sizeof (struct thread), 0, 0, 5);
 	uihashinit();
Index: src2/sys/sys/proc.h
===================================================================
--- src2.orig/sys/sys/proc.h	2008-03-31 08:05:59.140325000 +0200
+++ src2/sys/sys/proc.h	2008-03-31 10:31:39.000000000 +0200
@@ -473,7 +473,7 @@ struct proc *zpfind (pid_t);	/* Find zom
 struct vm_zone;
 struct globaldata;
 struct lwp_params;
-extern struct vm_zone *proc_zone;
+extern struct objcache *proc_cache;
 extern struct vm_zone *lwp_zone;

 int	enterpgrp (struct proc *p, pid_t pgid, int mksess);
Index: src2/sys/kern/kern_fork.c
===================================================================
--- src2.orig/sys/kern/kern_fork.c	2008-03-31 08:05:59.140042000 +0200
+++ src2/sys/kern/kern_fork.c	2008-03-31 10:31:39.000000000 +0200
@@ -332,7 +332,7 @@ fork1(struct lwp *lp1, int flags, struct
 	}

 	/* Allocate new proc. */
-	p2 = zalloc(proc_zone);
+	p2 = objcache_get(proc_cache, M_WAITOK);
 	bzero(p2, sizeof(*p2));

 	/*




From hsu at dragonflybsd.org  Mon Mar 31 11:44:34 2008
From: hsu at dragonflybsd.org (Jeffrey Hsu)
Date: Mon, 31 Mar 2008 11:44:34 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <64fc43b0803311126na7d0b27obaa9d35bac6d32ee@mail.gmail.com>
Message-ID: <200803311841.m2VIfQAI007579@nlpi001.prodigy.net>

The object cache is not a general-purpose memory allocator.  It's a cache of
pre-initialized objects.  Are the significant portions of the proc structure
that can be restored to initialized state on object puts?  If not, it's best
to just use a general-purpose memory allocator.

								Jeffrey




From corecode at fs.ei.tum.de  Mon Mar 31 12:07:02 2008
From: corecode at fs.ei.tum.de (Simon 'corecode' Schubert)
Date: Mon, 31 Mar 2008 12:07:02 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <200803311841.m2VIfQAI007579@nlpi001.prodigy.net>
Message-ID: <47F1357B.1070302@fs.ei.tum.de>

Jeffrey Hsu wrote:
> The object cache is not a general-purpose memory allocator.  It's a cache of
> pre-initialized objects.  Are the significant portions of the proc structure
> that can be restored to initialized state on object puts?  If not, it's best
> to just use a general-purpose memory allocator.

Why?  What's the loss if we use the object cache to allocate struct procs?

cheers
  simon

Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00006.pgp
Type: application/octet-stream
Size: 252 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080331/a4a24314/attachment.obj>

From nthery at gmail.com  Mon Mar 31 12:17:03 2008
From: nthery at gmail.com (Nicolas Thery)
Date: Mon, 31 Mar 2008 12:17:03 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <nthery@gmail.com>
Message-ID: <64fc43b0803311214u7da6bbb8xaf971de1a80e7258@mail.gmail.com>

2008/3/31, Jeffrey Hsu <hsu at dragonflybsd.org>:
> The object cache is not a general-purpose memory allocator.  It's a cache of
>  pre-initialized objects.  Are the significant portions of the proc structure
>  that can be restored to initialized state on object puts?  If not, it's best
>  to just use a general-purpose memory allocator.

Well, I haven't checked this yet.  I planned to do this in a second
step after getting rid of zones.

I thought that even without  the pre-initialization part, objcache has
the advantage
of pre-allocating set of objects (as zones) and is additionally
mp-safe (contrary to zones and, granted, as malloc()).   The latter
may be interesting as we talk of improving MP support.

Cheers,
Nicolas




From dillon at apollo.backplane.com  Mon Mar 31 12:23:40 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Mon, 31 Mar 2008 12:23:40 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <200803311841.m2VIfQAI007579@nlpi001.prodigy.net>
Message-ID: <200803311921.m2VJLITB027669@apollo.backplane.com>

    I both agree and disagree with Jeff.  I think the only *disadvantage*
    to using objcache for struct proc is that objcache must cache a minimum
    number of free structures to be efficient so the overall kernel memory
    use would be a bit greater verses uses kmalloc().  But I agree with Jeff
    in that objcache's biggest advantage is that you can keep structural state
    intact and struct proc might not be a good candidate (yet).

    What I suggest is that you convert struct proc from zone to kmalloc
    first, and then look into a possible objcache adaptation.  kmalloc
    is not slow.. it's a very fast allocator.  Objcache is probably a tad
    faster but not by much.  Where objcache really wins is in not having
    to completey reinitialize the allocated structures.

    Over the years I've removed (I think) all the dependancies on requiring
    the proc structure to be in stable memory so I believe it can be moved to
    kmalloc/objcache now without any major pain.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From corecode at fs.ei.tum.de  Mon Mar 31 12:37:40 2008
From: corecode at fs.ei.tum.de (Simon 'corecode' Schubert)
Date: Mon, 31 Mar 2008 12:37:40 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: SoC student applications due by 5PM PDT tomorrow
In-Reply-To: <1942.192.168.0.242.1206930479.squirrel@www.shiningsilence.com>
Message-ID: <47F13CDA.6010703@fs.ei.tum.de>

Justin C. Sherrill wrote:
> On Sun, March 30, 2008 10:27 pm, Justin C. Sherrill wrote:
>> SoC students:
>>
>> If you have an application to submit for DragonFly/Summer of Code, please
>> do so by 17:00 Pacific time on the 31st - that's tomorrow, at least for
>> me.
> The deadline for student proposals has been extended to April 7th; all
> other dates move forward one week to acommodate.

This is very good.

Some more ideas for eager students (we want to keep the ratio, right?):

Enhance the FreeBSD/DragonFly sound infrastructure to support surround
sound/multichannel output.

Update sound drivers to support S/PDIF output.

Make the sound infrastructure OSSv4 compatible (there was a SoC at
FreeBSD last year or so)


of course only if it doesn't exist already :)

cheers
  simon


Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00007.pgp
Type: application/octet-stream
Size: 252 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080331/6da61cff/attachment.obj>

From corecode at fs.ei.tum.de  Mon Mar 31 12:41:30 2008
From: corecode at fs.ei.tum.de (Simon 'corecode' Schubert)
Date: Mon, 31 Mar 2008 12:41:30 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <200803311841.m2VIfQAI007579@nlpi001.prodigy.net>
Message-ID: <47F13DE4.10205@fs.ei.tum.de>

Matthew Dillon wrote:
>     What I suggest is that you convert struct proc from zone to kmalloc
>     first, and then look into a possible objcache adaptation.  kmalloc
>     is not slow.. it's a very fast allocator.  Objcache is probably a tad
>     faster but not by much.  Where objcache really wins is in not having
>     to completey reinitialize the allocated structures.

Could we please not move to kmalloc, but instead try to move all fast
path allocations to objcache?  I don't like the idea of allocating
everything with kmalloc.  Caching struct procs is not a bad thing itself.

cheers
  simon


Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00008.pgp
Type: application/octet-stream
Size: 252 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080331/ac328c08/attachment.obj>

From hsu at FreeBSD.org  Mon Mar 31 12:59:05 2008
From: hsu at FreeBSD.org (Jeffrey Hsu)
Date: Mon, 31 Mar 2008 12:59:05 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <47F1357B.1070302@fs.ei.tum.de>
Message-ID: <200803311920.m2VJK5Ln018015@nlpi015.prodigy.net>

The object cache sits on top of a general-purpose memory allocator such
as kmalloc or zalloc and provides pre-initialized object caching functionality.
If you're not going to use the object caching functionality, you can just
call the underlying memory allocator directly.

							Jeffrey




From dillon at apollo.backplane.com  Mon Mar 31 16:17:19 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Mon, 31 Mar 2008 16:17:19 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <200803311841.m2VIfQAI007579@nlpi001.prodigy.net>
Message-ID: <200803312311.m2VNBumd029866@apollo.backplane.com>

:Could we please not move to kmalloc, but instead try to move all fast
:path allocations to objcache?  I don't like the idea of allocating
:everything with kmalloc.  Caching struct procs is not a bad thing itself.=
:
:
:cheers
:  simon

    I will state for the record that I'm fine with either objcache or
    kmalloc.  I agree with Jeff that using objcache for struct proc
    probably isn't necessary but I also agree that it would not hurt either,
    and if the intent is to optimize the initialization of the proc
    structure in the future then moving to objcache now would save us
    from having to do it later.

    So whichever method Nicolas wants to use is fine with me.

						-Matt




From hsu at dragonflybsd.org  Mon Mar 31 19:22:47 2008
From: hsu at dragonflybsd.org (Jeffrey Hsu)
Date: Mon, 31 Mar 2008 19:22:47 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <64fc43b0803311214u7da6bbb8xaf971de1a80e7258@mail.gmail.com>
Message-ID: <200804010218.m312IVUq003624@nlpi043.prodigy.net>

  >> Are there significant portions of the proc structure
  >> that can be restored to initialized state on object puts?

  > I planned to do this in a second step after getting rid of zones.

I'll all in favor of making more use of caching pre-initialized objects, so
if this is your objective, then please go ahead.  It's just that I'd convert
over to the object cache in one step.

  > I thought that even without  the pre-initialization part, objcache has
  > the advantage of pre-allocating set of objects (as zones) and is additionally
  > mp-safe (contrary to zones and, granted, as malloc()).

Well, the zone allocator is MP-safe.  It's not hard to lock up the places that
manipulate the linked-list of free items. Look for uses of the zlock field.

								Jeffrey




From tgen at netphreax.net  Sat Mar  1 12:57:53 2008
From: tgen at netphreax.net (Thomas E. Spanjaard)
Date: Sat, 1 Mar 2008 12:57:53 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: [Fwd: Project Support Open Source: $50 donation to support you      project]
In-Reply-To: <2468.192.168.0.242.1204346451.squirrel@www.shiningsilence.com>
Message-ID: <47C9C1B7.50203@netphreax.net>

Justin C. Sherrill wrote:
The "donation" happens after you place an "acknowledgement" on an open
source project's web page.  I'm putting those words in scare quotes
because I think it's a "payment" for an "advertisement".  The supplied
link has nothing to do with DragonFly, to say the least.

<a href="http://www.2insure4less.com /" title="We support FOSS software
projects.">Online Insurance Quotes</a>
To think our souls are only worth $50...
--
        Thomas E. Spanjaard
        tgen at netphreax.net
Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00000.pgp
Type: application/octet-stream
Size: 186 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080301/0d61e240/attachment-0001.obj>

From c.turner at 199technologies.org  Sat Mar  1 17:52:31 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Sat, 1 Mar 2008 17:52:31 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Misc. ACPI / suspend
Message-ID: <47CA073B.6020106@199technologies.org>

Wondering if anyone more well versed in the ACPI implementation could
comment on the applicability of:
http://lkml.org/lkml/2007/4/6/69

w/r/t the current state of the art in Dfly

(or BSD's in general)

Cheers!

- Chris




From elekktretterr at exemail.com.au  Sun Mar  2 00:41:25 2008
From: elekktretterr at exemail.com.au (Petr Janda)
Date: Sun, 2 Mar 2008 00:41:25 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: CARP question
Message-ID: <200803021934.21669.elekktretterr@exemail.com.au>

So Ive setup CARP on 2 DF-based mailservers. Installation went fine. Box 1 has 
adskew of 0 therefore it is the MASTER. Box 2 has adskew of 254, therefore is 
BACKUP.  If i down the carp0 interface on Box 1, then Box 2 carp interface 
gets promoted to MASTER. Then I up the carp interface on Box 1, logically Box 
2 should become BACKUP again as Box 1 becomes MASTER due to adskew set to 0.

However it doesnt happen. When carp0 interface on Box 1 is upped it becomes a 
BACKUP, not a MASTER even though according to adskew it should be MASTER.

What is the desired behaviour?

Cheers
Petr




From qhwt+dfly at les.ath.cx  Sun Mar  2 02:50:14 2008
From: qhwt+dfly at les.ath.cx (YONETANI Tomokazu)
Date: Sun, 2 Mar 2008 02:50:14 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: panic: assertion: hammer_btree_cmp(cursor->left_bound,	&cursor->node->ondisk->elms[0].leaf.base) <= 0 in btree_split_leaf
In-Reply-To: <200802232204.m1NM4cxd046264@apollo.backplane.com>
Message-ID: <20080302104554.GA22813@les.ath.cx>

Hi.
While trying to find a procedure to reliably reproduce the panic
I reported last time, I caught a different panic (uploaded at
 ~y0netan1/crash/9/ on my leaf account).  I wrote the following shell
script (make sure to edit variables DISKS and MOUNTPT before using this
script or it may trash your system):
  #!/bin/sh -ex
  DISKS="/dev/ad0s1f"
  MOUNTPT=/mnt/HAMMER

  cd /
  newfs_hammer -L TEST $DISKS
  for i in `seq 1 100`; do
	  mount_hammer $DISKS $MOUNTPT
	  /bin/rm -rf $MOUNTPT/??
	  (set +x; for x in `seq 1 10000`; do echo -n > $MOUNTPT/$x; done)
	  umount $MOUNTPT
  done

And the panic is triggered by rm command.
I'll try to see if it's possible to reproduce the last one without
unmounting then mounting the HAMMER fs.

Cheers.




From dillon at apollo.backplane.com  Sun Mar  2 13:25:33 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Sun, 2 Mar 2008 13:25:33 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: panic: assertion: hammer_btree_cmp(cursor->left_bound,	&cursor->node->ondisk->elms[0].leaf.base) <= 0 in btree_split_leaf
In-Reply-To: <200802232204.m1NM4cxd046264@apollo.backplane.com>
Message-ID: <200803022119.m22LJRCY037076@apollo.backplane.com>


:Hi.
:While trying to find a procedure to reliably reproduce the panic
:I reported last time, I caught a different panic (uploaded at
: ~y0netan1/crash/9/ on my leaf account).  I wrote the following shell
:script (make sure to edit variables DISKS and MOUNTPT before using this
:script or it may trash your system):

(from the core)

panic: assertion: node->lock.refs == 0 && node->ondisk == NULL in hammer_flush_buffer_nodes

    Yah, I've seen this failure.  Add a sync or two before the umount and
    tell me if it still occurs.  It's either a node reference leak somewhere
    or it is a race between bufdaemon and umount.  The assertions are really
    strict there precisely to catch those sorts of cases.

    Also note that the code to deal with a full HAMMMER filesystem has not
    been written yet (The failure you are reporting is unrelated to a full
    HAMMER filesystem, though, just mentioning it).

						-Matt





From dillon at apollo.backplane.com  Sun Mar  2 13:29:03 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Sun, 2 Mar 2008 13:29:03 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Misc. ACPI / suspend
In-Reply-To: <47CA073B.6020106@199technologies.org>
Message-ID: <200803022126.m22LQbfI037188@apollo.backplane.com>


:Wondering if anyone more well versed in the ACPI implementation could
:comment on the applicability of:
:
:http://lkml.org/lkml/2007/4/6/69
:
:w/r/t the current state of the art in Dfly
:
:(or BSD's in general)
:
:Cheers!
:
:- Chris

    I really have no idea re: this.  Suspension in general is not well
    supported by any of the BSDs.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From dillon at apollo.backplane.com  Sun Mar  2 13:34:05 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Sun, 2 Mar 2008 13:34:05 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: [Fwd: Project Support Open Source: $50 donation to support you      project]
In-Reply-To: <2468.192.168.0.242.1204346451.squirrel@www.shiningsilence.com>
Message-ID: <200803022131.m22LVOe9037250@apollo.backplane.com>

:..
:source project's web page.  I'm putting those words in scare quotes
:because I think it's a "payment" for an "advertisement".  The supplied
:link has nothing to do with DragonFly, to say the least.
:
:I don't think this is a good idea, obviously, and replied to that effect. 
:However, I wanted to put this on a DragonFly list, in part to show this
:strange thing, and in part because I'm not comfortable making
:administrative decisions on behalf of the Project without being open as
:possible about it.

    It doesn't really cry out to me either.

						-Matt





From wbh at conducive.org  Sun Mar  2 20:36:32 2008
From: wbh at conducive.org (Bill Hacker)
Date: Mon, 03 Mar 2008 04:36:32 +0000
Subject: Misc. ACPI / suspend
In-Reply-To: <47CA073B.6020106@199technologies.org>
Message-ID: <47cb8050$0$855$415eb37d@crater_reader.dragonflybsd.org>

Matthew Dillon wrote:
:Wondering if anyone more well versed in the ACPI implementation could
:comment on the applicability of:
:
:http://lkml.org/lkml/2007/4/6/69
:
:w/r/t the current state of the art in Dfly
:
:(or BSD's in general)
:
:Cheers!
:
:- Chris
    I really have no idea re: this.  Suspension in general is not well
    supported by any of the BSDs.
					-Matt
					Matthew Dillon 
					<dillon at backplane.com>


. . and there seems to be a bit of a 'Catch 22' there in any case.

If the BIOS can alter 'stuff' out of site of the OS it is parking, what 
does the existence of such a 'feature' do to a(ny) security model?

Seems to at least beg creating the option of setting a flag to 
specifically *prevent* suspend-to-disk/hibernation (and/or force a 
reboot on wake-up).

Just because one is paranoid....  etc

Bill





From matthias at dragonflybsd.org  Tue Mar  4 02:30:52 2008
From: matthias at dragonflybsd.org (Matthias Schmidt)
Date: Tue, 4 Mar 2008 02:30:52 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
Message-ID: <20080304102335.GI9833@staatsfeind.org>

Hi,

Google just announced its Summer of Code for 2008:

	http://code.google.com/soc/2008/

I think this would be a great opportunity for DragonFly to participate
as a mentoring organisation.  We could attract new developers and could
get code/work done.  Looking at the SoC results of the other BSDs most
of their projects were a success.  Of course, not all, but a reasonable
percentage.  See [1] and [2].

It is some extra work for us, but IMO the benefits outweigh the extra
work.  And yes, I would volunteer as a mentor.  What do others
(developers) think?  Any more volunteers? :)

Some project ideas that come into my mind.  More ideas are listed in the
wiki:  http://wiki.dragonflybsd.org/index.cgi/ProjectsPage

 * Fix all remaining bugs in dma(8) and implement all missing features
 * Add a driver for newer Intel Wireless cards (I think sephe@ would
   love that :)
 * Bring our ACPI stuff in shape.  Maybe suspend2disk ...

 * [Add your own thoughts here]

Cheers,

	Matthias

PS: I don't want to create a bikeshed here whether you like the SoC or
not :)

[1] http://code.google.com/soc/2007/freebsd/about.html
[2] http://code.google.com/soc/2007/netbsd/about.html




From corecode at fs.ei.tum.de  Tue Mar  4 04:46:14 2008
From: corecode at fs.ei.tum.de (Simon 'corecode' Schubert)
Date: Tue, 4 Mar 2008 04:46:14 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47CD4386.1000704@fs.ei.tum.de>

Matthias Schmidt wrote:
>  * [Add your own thoughts here]

MP lock removal for network stack

and for the system  (first profile, find hot spots, fix hot spots, repeat)

cheers
  simon




From c.turner at 199technologies.org  Tue Mar  4 06:02:20 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Tue, 4 Mar 2008 06:02:20 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47CD551E.1040604@199technologies.org>

Matthias Schmidt wrote:
Some project ideas that come into my mind.  More ideas are listed in the
wiki:  http://wiki.dragonflybsd.org/index.cgi/ProjectsPage
+1 acpi
+1 interrupt routing
+1 SMP / giant removal
+1 pf synchup with openbsd
though there are several others on the page that are good..

need to dig up my wiki login and place appropriately..

also: thinking the ZFS port should be removed from the page - makes 
sense to everyone else? (e.g. fragments effort w/r/t hammer)





From tgen at netphreax.net  Tue Mar  4 06:54:31 2008
From: tgen at netphreax.net (Thomas E. Spanjaard)
Date: Tue, 4 Mar 2008 06:54:31 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47CD615F.8010209@netphreax.net>

Matthias Schmidt wrote:
Google just announced its Summer of Code for 2008:

 * [Add your own thoughts here]
x86-64 port :).
--
        Thomas E. Spanjaard
        tgen at netphreax.net
Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00001.pgp
Type: application/octet-stream
Size: 186 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080304/0d921000/attachment-0001.obj>

From rdivacky at FreeBSD.org  Tue Mar  4 07:07:03 2008
From: rdivacky at FreeBSD.org (Roman Divacky)
Date: Tue, 4 Mar 2008 07:07:03 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <20080304150255.GA8831@freebsd.org>

On Tue, Mar 04, 2008 at 02:49:03PM +0000, Thomas E. Spanjaard wrote:
> Matthias Schmidt wrote:
> >Google just announced its Summer of Code for 2008:
> >
> > * [Add your own thoughts here]
> 
> x86-64 port :).

all those ideas are great and needed etc. but keep in
mind that the projects should be doable by students
who might see dfly for the very first time.

don't overestimate whats possible and select projects
that look realistic

Roman Divacky (former SoC student)




From justin at shiningsilence.com  Tue Mar  4 08:32:56 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Tue, 4 Mar 2008 08:32:56 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <60322.65.106.147.226.1204648095.squirrel@www.shiningsilence.com>

On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
> Hi,
>
> Google just announced its Summer of Code for 2008:
>
> 	http://code.google.com/soc/2008/
>
> I think this would be a great opportunity for DragonFly to participate
> as a mentoring organisation.  We could attract new developers and could
> get code/work done.  Looking at the SoC results of the other BSDs most
> of their projects were a success.  Of course, not all, but a reasonable
> percentage.  See [1] and [2].

We've applied in previous years - Jeff Hsu did one year, and I put
together the application last year.  The hardest thing to find was
students (and they are the thing that helps SoC applications a lot, I
think).

Any student volunteers?  We have mentors.





From rluciani at gmail.com  Tue Mar  4 09:38:29 2008
From: rluciani at gmail.com (Robert Luciani)
Date: Tue, 04 Mar 2008 18:38:29 +0100
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47cd8915$0$854$415eb37d@crater_reader.dragonflybsd.org>

Justin C. Sherrill wrote:
> On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
>> Hi,
>>
>> Google just announced its Summer of Code for 2008:
>>
>> 	http://code.google.com/soc/2008/
>>
>> I think this would be a great opportunity for DragonFly to participate
>> as a mentoring organisation.  We could attract new developers and could
>> get code/work done.  Looking at the SoC results of the other BSDs most
>> of their projects were a success.  Of course, not all, but a reasonable
>> percentage.  See [1] and [2].
> 
> We've applied in previous years - Jeff Hsu did one year, and I put
> together the application last year.  The hardest thing to find was
> students (and they are the thing that helps SoC applications a lot, I
> think).
> 
> Any student volunteers?  We have mentors.
> 

bingo

-- 
Robert Luciani
Chalmers University of Technology, SWE
Department of Computer Science and Engineering
http://www.rluciani.com/public.key




From sdavtaker at gmail.com  Tue Mar  4 09:31:08 2008
From: sdavtaker at gmail.com (=?UTF-8?Q?Sd=C3=A4vtaker?=)
Date: Tue, 4 Mar 2008 09:31:08 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <c37d69f60803040926k206218a3kb8496d0cd18148bd@mail.gmail.com>

If you mentor, i will apply for coder :-)
Still in last year of university. :-)
Sdav

On Tue, Mar 4, 2008 at 1:28 PM, Justin C. Sherrill
<justin at shiningsilence.com> wrote:
> On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
>  > Hi,
>  >
>  > Google just announced its Summer of Code for 2008:
>  >
>  >       http://code.google.com/soc/2008/
>  >
>  > I think this would be a great opportunity for DragonFly to participate
>  > as a mentoring organisation.  We could attract new developers and could
>  > get code/work done.  Looking at the SoC results of the other BSDs most
>  > of their projects were a success.  Of course, not all, but a reasonable
>  > percentage.  See [1] and [2].
>
>  We've applied in previous years - Jeff Hsu did one year, and I put
>  together the application last year.  The hardest thing to find was
>  students (and they are the thing that helps SoC applications a lot, I
>  think).
>
>  Any student volunteers?  We have mentors.
>
>



-- 
Sd?vtaker prays to Rikku goddess for a good treasure.



From rluciani at gmail.com  Tue Mar  4 09:44:02 2008
From: rluciani at gmail.com (Robert Luciani)
Date: Tue, 04 Mar 2008 18:44:02 +0100
Subject: google soc "DragonFly"
Message-ID: <47cd8a63$0$855$415eb37d@crater_reader.dragonflybsd.org>

On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
> > Hi,
> >
> > Google just announced its Summer of Code for 2008:
> >
> > 	http://code.google.com/soc/2008/
> >
> > I think this would be a great opportunity for DragonFly to participate
> > as a mentoring organisation.  We could attract new developers and could
> > get code/work done.  Looking at the SoC results of the other BSDs most
> > of their projects were a success.  Of course, not all, but a reasonable
> > percentage.  See [1] and [2].

We've applied in previous years - Jeff Hsu did one year, and I put
together the application last year.  The hardest thing to find was
students (and they are the thing that helps SoC applications a lot, I
think).

Any student volunteers?  We have mentors.


-- 
Robert Luciani
Chalmers University of Technology, SWE
Department of Computer Science and Engineering
http://www.rluciani.com/public.key




From rluciani at gmail.com  Tue Mar  4 10:04:14 2008
From: rluciani at gmail.com (Robert Luciani)
Date: Tue, 04 Mar 2008 19:04:14 +0100
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47cd8f1f$0$856$415eb37d@crater_reader.dragonflybsd.org>

Robert Luciani wrote:
> Justin C. Sherrill wrote:
>> On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
>>> Hi,
>>>
>>> Google just announced its Summer of Code for 2008:
>>>
>>> 	http://code.google.com/soc/2008/
>>>
>>> I think this would be a great opportunity for DragonFly to participate
>>> as a mentoring organisation.  We could attract new developers and could
>>> get code/work done.  Looking at the SoC results of the other BSDs most
>>> of their projects were a success.  Of course, not all, but a reasonable
>>> percentage.  See [1] and [2].
>> We've applied in previous years - Jeff Hsu did one year, and I put
>> together the application last year.  The hardest thing to find was
>> students (and they are the thing that helps SoC applications a lot, I
>> think).
>>
>> Any student volunteers?  We have mentors.
>>
> 
> bingo
> 
My girlfriend Danwei noted that she would also like partake in the SoC.
She's studying IT here at Chalmers and will join the mailing list shortly.
-- 
Robert Luciani
Chalmers University of Technology, SWE
Department of Computer Science and Engineering
http://www.rluciani.com/public.key




From dillon at apollo.backplane.com  Tue Mar  4 13:08:30 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Tue, 4 Mar 2008 13:08:30 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Going to have to roll 1.12.1
Message-ID: <200803042104.m24L43g1065278@apollo.backplane.com>

    Due to a critical bug in sendmail that can cause it to seg-fault I will
    be rolling 1.12.1 as soon as I get verification that the current
    fix deals with it.

						-Matt





From sdavtaker at gmail.com  Tue Mar  4 17:40:43 2008
From: sdavtaker at gmail.com (=?UTF-8?B?U2TDpHZ0YWtlcg==?=)
Date: Tue, 4 Mar 2008 17:40:43 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: [Fwd: Project Support Open Source: $50 donation to support you  project]
In-Reply-To: <2468.192.168.0.242.1204346451.squirrel@www.shiningsilence.com>
Message-ID: <47CDF8D1.9070100@gmail.com>

50 bucks?
Come on...
You can get a meal a lot more expensive than that just going to a free 
HP conference about linux and you only have to rent your soul 3-5 hours ;-)
Sdav

Matthew Dillon escribi?:
:..
:source project's web page.  I'm putting those words in scare quotes
:because I think it's a "payment" for an "advertisement".  The supplied
:link has nothing to do with DragonFly, to say the least.
:
:I don't think this is a good idea, obviously, and replied to that effect. 
:However, I wanted to put this on a DragonFly list, in part to show this
:strange thing, and in part because I'm not comfortable making
:administrative decisions on behalf of the Project without being open as
:possible about it.

    It doesn't really cry out to me either.

						-Matt

  






From sdavtaker at gmail.com  Tue Mar  4 17:56:35 2008
From: sdavtaker at gmail.com (=?UTF-8?B?U2TDpHZ0YWtlcg==?=)
Date: Tue, 4 Mar 2008 17:56:35 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47CDFCCE.1010106@gmail.com>

A cute idea for for GSOC would be to finish the installer.
We were talking about this in my local BUG, we trying to find out how to 
help on that from here.
There is a few missing features in the CD.

   * FDISK, you need to create the slides from another OS before
     install DFBSD, i think port FDisk from FBSD or any *BSD will solve it.
   * Add to the make release a way to add some custom applications to
     the released liveCD (suppose you want to add nmap or ssh or
     something just to use as test disk in some enviroment).
   * Make the installer a little more customizable, and maybe w/ a GUI
     (I like a lot the console approach, but GUI installer will be a
     popularity move, DFBSD w/X makes a Desktop machine work, actually
     im using it that way and really like it).
I think those projects can be done in a SOC by students (like me) with a 
little guide.
Im a lot more interested in things network related and kernel, but i 
dont mind to work on those things, they need to be done some day.
What u think?
Sdav

Robert Luciani escribi?:
Robert Luciani wrote:
  
Justin C. Sherrill wrote:
    
On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
      
Hi,

Google just announced its Summer of Code for 2008:

	http://code.google.com/soc/2008/

I think this would be a great opportunity for DragonFly to participate
as a mentoring organisation.  We could attract new developers and could
get code/work done.  Looking at the SoC results of the other BSDs most
of their projects were a success.  Of course, not all, but a reasonable
percentage.  See [1] and [2].
        
We've applied in previous years - Jeff Hsu did one year, and I put
together the application last year.  The hardest thing to find was
students (and they are the thing that helps SoC applications a lot, I
think).
Any student volunteers?  We have mentors.

      
bingo

    
My girlfriend Danwei noted that she would also like partake in the SoC.
She's studying IT here at Chalmers and will join the mailing list shortly.
  






From c.turner at 199technologies.org  Tue Mar  4 18:30:53 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Tue, 4 Mar 2008 18:30:53 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47CE04C9.1010902@199technologies.org>

Justin C. Sherrill wrote:
together the application last year.  The hardest thing to find was
students (and they are the thing that helps SoC applications a lot, I
think).
umm.. if google wants to send me back to school, I'll sign up - hows 
that for a fair trade :?






From wbh at conducive.org  Tue Mar  4 23:52:13 2008
From: wbh at conducive.org (Bill Hacker)
Date: Wed, 05 Mar 2008 07:52:13 +0000
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47ce512e$0$855$415eb37d@crater_reader.dragonflybsd.org>

Sd?vtaker wrote:
A cute idea for for GSOC would be to finish the installer.
We were talking about this in my local BUG, we trying to find out how to 
help on that from here.
There is a few missing features in the CD.

   * FDISK, you need to create the slides from another OS before
     install DFBSD, i think port FDisk from FBSD or any *BSD will solve it.
I'd rather see that 'reversed' - i.e. - build a more capable fdisk in 
DFLY with hope that it might be seen worth importing into Free/Net/Open, 
or *at least* be able to do a more flexible job than those now do.

And disklabels as well. Hand in glove.

Here's why:

- At the moment, working with Free, Open, DFLY, and OpenSolaris on the 
same HDD requires a bit of acrobatics.

- There seems to now be greater divergence between/among the *BSD's as 
to being able to read each other's disklabels, mount and use each 
other's 'flavor' of FFS/UFS (not to mention Apple's implementation of 
UFS) than there is among the vast multitude of Linux ext2/3 denizens.

Even to the point where use of a *Linux* fs is the more universal way 
for being able to share mounts among the *BSD's. Think detached drives. 
And no - FAT is not all that practical for several reasons.

- DFLY currently has the most fine-grain ability to create slices and 
partitions. But the others cannot all (any?) read those.

'progress' w/r any of the *BSD's direction as to changes, improvements 
(or not) in their once-common-ancestry fs & disklabels need not be 
sacrificed.

I'm not holding out wish or hope for all players agreeing to return to 
'one sacred way'. Nor 'one new universal fs'. Neither is gonna happen.

But a 'legacy compatible' or least-common-denominator mode would do fine 
- most especially for portable / SAN devices.

So - how about a 'flexible' DFLY fdisk to go along with a 'flexible' 
disklabel that could adapt to whatever it found / was told to create?

JM2CW - but that *might* be a good place to get a cross-*BSD team together.

*snip* (other good stuff)

Bill Hacker




From matthias at dragonflybsd.org  Wed Mar  5 01:02:43 2008
From: matthias at dragonflybsd.org (Matthias Schmidt)
Date: Wed, 5 Mar 2008 01:02:43 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <20080305085747.GJ9833@staatsfeind.org>

Hi,

* Justin C. Sherrill wrote:
> 
> We've applied in previous years - Jeff Hsu did one year, and I put
> together the application last year.  The hardest thing to find was
> students (and they are the thing that helps SoC applications a lot, I
> think).

This is good to know, so we could coordinate that if we have enough
mentors and projects?!?  I put together a small text in the wiki:

http://wiki.dragonflybsd.org/index.cgi/GoogleSoC2008

Feel free to add project or missing stuff.  I'm sure I missed a lot of
things :)

> Any student volunteers?  We have mentors.

According to the discussion we could have some students, who would be a
mentor (besides me)?

Regards

	Matthias





From sdavtaker at gmail.com  Wed Mar  5 06:28:37 2008
From: sdavtaker at gmail.com (=?UTF-8?Q?Sd=C3=A4vtaker?=)
Date: Wed, 5 Mar 2008 06:28:37 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <c37d69f60803050624kd86d3d0w3b44a02d0e5a5391@mail.gmail.com>

<quote>
Write a driver (from scratch) for Intel 3945 wireless device
Mentor: Sepherosa Ziehau
</quote>

Yes yes yes, i want to :-)
Someone else planning to mentor in drivers coding?
Sdav

On Wed, Mar 5, 2008 at 5:57 AM, Matthias Schmidt
<matthias at dragonflybsd.org> wrote:
> Hi,
>
>
>  * Justin C. Sherrill wrote:
>  >
>  > We've applied in previous years - Jeff Hsu did one year, and I put
>  > together the application last year.  The hardest thing to find was
>  > students (and they are the thing that helps SoC applications a lot, I
>  > think).
>
>  This is good to know, so we could coordinate that if we have enough
>  mentors and projects?!?  I put together a small text in the wiki:
>
>  http://wiki.dragonflybsd.org/index.cgi/GoogleSoC2008
>
>  Feel free to add project or missing stuff.  I'm sure I missed a lot of
>  things :)
>
>
>  > Any student volunteers?  We have mentors.
>
>  According to the discussion we could have some students, who would be a
>  mentor (besides me)?
>
>  Regards
>
>         Matthias
>
>



-- 
Sd?vtaker prays to Rikku goddess for a good treasure.



From rluciani at gmail.com  Wed Mar  5 10:56:42 2008
From: rluciani at gmail.com (Robert Luciani)
Date: Wed, 05 Mar 2008 19:56:42 +0100
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47ceecea$0$847$415eb37d@crater_reader.dragonflybsd.org>

Sd?vtaker wrote:
> <quote>
> Write a driver (from scratch) for Intel 3945 wireless device
> Mentor: Sepherosa Ziehau
> </quote>
> 
> Yes yes yes, i want to :-)
> Someone else planning to mentor in drivers coding?
> Sdav
> 
> On Wed, Mar 5, 2008 at 5:57 AM, Matthias Schmidt
> <matthias at dragonflybsd.org> wrote:
>> Hi,
>>
>>
>>  * Justin C. Sherrill wrote:
>>  >
>>  > We've applied in previous years - Jeff Hsu did one year, and I put
>>  > together the application last year.  The hardest thing to find was
>>  > students (and they are the thing that helps SoC applications a lot, I
>>  > think).
>>
>>  This is good to know, so we could coordinate that if we have enough
>>  mentors and projects?!?  I put together a small text in the wiki:
>>
>>  http://wiki.dragonflybsd.org/index.cgi/GoogleSoC2008
>>
>>  Feel free to add project or missing stuff.  I'm sure I missed a lot of
>>  things :)
>>
>>
>>  > Any student volunteers?  We have mentors.
>>
>>  According to the discussion we could have some students, who would be a
>>  mentor (besides me)?
>>
>>  Regards
>>
>>         Matthias
>>
>>
> 
> 
>

IF someone starts to write a 3945 Intel driver,
please keep the newer 4965 in mind too.

-- 
Robert Luciani
Chalmers University of Technology, SWE
Department of Computer Science and Engineering
http://www.rluciani.com/public.key




From joerg at britannica.bec.de  Wed Mar  5 12:01:05 2008
From: joerg at britannica.bec.de (Joerg Sonnenberger)
Date: Wed, 5 Mar 2008 12:01:05 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <20080305195711.GA9981@britannica.bec.de>

On Wed, Mar 05, 2008 at 07:56:42PM +0100, Robert Luciani wrote:
> IF someone starts to write a 3945 Intel driver,
> please keep the newer 4965 in mind too.

NetBSD's wpi works quite well. The hardware is quite different from
4945.

Joerg




From sepherosa at gmail.com  Wed Mar  5 17:48:50 2008
From: sepherosa at gmail.com (Sepherosa Ziehau)
Date: Wed, 5 Mar 2008 17:48:50 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <ea7b9c170803051744u22b09484ofc994f034f11df3b@mail.gmail.com>

On Thu, Mar 6, 2008 at 2:56 AM, Robert Luciani <rluciani at gmail.com> wrote:
>  IF someone starts to write a 3945 Intel driver,

"IF" you know that trying to fix any wired bugs in certain drivers
(e.g. ipw, ral) will require you to read through all of the vendor's
linux code (yes, even including register values and position), i.e.
there is not much difference between writing one from scratch and
porting+fixing_bugs, then you probably will not put "IF" at the start
of your sentence.
If what I said sounded too harsh to you, then I was sorry.

>  please keep the newer 4965 in mind too.

Will do, once generic 11n support is brought in from freebsd.

Best Regards,
sephe

-- 
Live Free or Die




From saw at online.de  Thu Mar  6 05:34:14 2008
From: saw at online.de (Sascha Wildner)
Date: Thu, 06 Mar 2008 14:34:14 +0100
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
Message-ID: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>

Hi all,

this is probably as good a moment as any to come out of the forest with 
this. The patch at

http://leaf.dragonflybsd.org/~swildner/nrelease_gui.diff

adds some code to nrelease/ to build a LiveCD with xorg and so on 
(currently, only the xorg metapackages and fluxbox are added). In order 
to build one, you need a local dir with the pkgsrc binary packages (see 
below).

The following commands should then do the trick:

cd /usr/src
make buildworld
make buildkernel
cd nrelease
patch -p 0 </path/to/the/patch
make PKGSRC_PKG_PATH=/path/to/packages/dir/All realquick gui
The resulting ISO will be in /usr/release/dfly-gui.iso then. It will not 
boot into xorg automatically (although this is easily possible), so you 
need to login as root and do startx.

As of now, this all is kind of basic, more a proof of concept than 
anything else. As our release framework installs packages via chroot, 
the current setup just copies _all_ packages to the chroot before 
installing (kind of a hack).

That said, I'm now primarily interested in opinions/ideas/... about the 
direction this should take. Which packages would we like to see on the 
CD? Should it be a generic setup with the "most common things" 
installed, so a system can be quickly setup by the installer (which will 
cpdup /usr/pkg). Or should it be a more specialized set of tools? Or 
even as many packages as possible (Live DVD?). Etc., etc.

Before continuing on it, I'm really interested in people's input so 
don't hold anything back, please. :)

Sascha

--
http://yoyodyne.ath.cx



From rluciani at gmail.com  Thu Mar  6 06:42:03 2008
From: rluciani at gmail.com (Robert Luciani)
Date: Thu, 06 Mar 2008 15:42:03 +0100
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <47d002bc$0$847$415eb37d@crater_reader.dragonflybsd.org>

Sascha Wildner wrote:
> Hi all,
> 
> this is probably as good a moment as any to come out of the forest with
> this. The patch at
> 
> http://leaf.dragonflybsd.org/~swildner/nrelease_gui.diff
> 
> adds some code to nrelease/ to build a LiveCD with xorg and so on
> (currently, only the xorg metapackages and fluxbox are added). In order
> to build one, you need a local dir with the pkgsrc binary packages (see
> below).
> 
> The following commands should then do the trick:
> 
> cd /usr/src
> make buildworld
> make buildkernel
> cd nrelease
> patch -p 0 </path/to/the/patch
> make PKGSRC_PKG_PATH=/path/to/packages/dir/All realquick gui
> 
> The resulting ISO will be in /usr/release/dfly-gui.iso then. It will not
> boot into xorg automatically (although this is easily possible), so you
> need to login as root and do startx.
> 
> As of now, this all is kind of basic, more a proof of concept than
> anything else. As our release framework installs packages via chroot,
> the current setup just copies _all_ packages to the chroot before
> installing (kind of a hack).
> 
> That said, I'm now primarily interested in opinions/ideas/... about the
> direction this should take. Which packages would we like to see on the
> CD? Should it be a generic setup with the "most common things"
> installed, so a system can be quickly setup by the installer (which will
> cpdup /usr/pkg). Or should it be a more specialized set of tools? Or
> even as many packages as possible (Live DVD?). Etc., etc.
> 
> Before continuing on it, I'm really interested in people's input so
> don't hold anything back, please. :)
> 
> Sascha
> 

I think the main point of such a live-cd would be to test
dragonfly-specific features such as vkernels and more. Mplayer and
OpenOffic work the same on all platforms, so they might not be super
important, while irssi, firefox, networking tools, vim, a few more
shells/terminals might make it easier to for people to quickly gauge if
they can reproduce their current productivity and also what is new.

And if the point of a livecd is to test that kind of stuff, then it
would be nice for it to have a kernel that supports as much as possible
like ALTQ, and drivers.

Also if it has lots and lots of programs (thinking multimedia, java,
etc..) it might be hard to keep the future x64 and x86 live-cds on par.
Gentoo had this problem many years ago and it was very bothersome.

-- 
Robert Luciani
Chalmers University of Technology, SWE
Department of Computer Science and Engineering
http://www.rluciani.com/public.key




From matthias at dragonflybsd.org  Thu Mar  6 07:12:43 2008
From: matthias at dragonflybsd.org (Matthias Schmidt)
Date: Thu, 6 Mar 2008 07:12:43 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <20080306150757.GN9833@staatsfeind.org>

* Sascha Wildner wrote:
> Hi all,
> 
> this is probably as good a moment as any to come out of the forest with this. 
> The patch at
> 
> http://leaf.dragonflybsd.org/~swildner/nrelease_gui.diff
> 
> adds some code to nrelease/ to build a LiveCD with xorg and so on (currently, 
> only the xorg metapackages and fluxbox are added). In order to build one, you 
> need a local dir with the pkgsrc binary packages (see below).

Great work Sascha.

I agree with Robert on most of his stated points.
It would be nice to see some DragonFly specific features on the CD
(although I'm not sure if that will work for all features).  A little
environment where most Unix users feel at home (fluxbox, xfce, firefox,
thunderbird, gvim) should be enough.

Big applications like OO.org, java etc won't work because they are not
available as pkgsrc packages neither is it possible to compile them on
DragonFly.  At least to my knowledge.

Regards

	Matthias




From dillon at apollo.backplane.com  Thu Mar  6 09:31:52 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Thu, 6 Mar 2008 09:31:52 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <200803061728.m26HSR3O091809@apollo.backplane.com>


:Hi all,
:
:this is probably as good a moment as any to come out of the forest with 
:this. The patch at
:
:http://leaf.dragonflybsd.org/~swildner/nrelease_gui.diff
:
:adds some code to nrelease/ to build a LiveCD with xorg and so on 
:(currently, only the xorg metapackages and fluxbox are added). In order 
:to build one, you need a local dir with the pkgsrc binary packages (see 
:below).
:
:The following commands should then do the trick:

    It looks reasonable, though the package copy has to be tightened
    up a bit I think.

:...
:installed, so a system can be quickly setup by the installer (which will 
:cpdup /usr/pkg). Or should it be a more specialized set of tools? Or 
:even as many packages as possible (Live DVD?). Etc., etc.
:
:Before continuing on it, I'm really interested in people's input so 
:don't hold anything back, please. :)
:
:Sascha

    I think this is an excellent time to work up a DVD build and to
    add various 'flavor' extras.  So, e.g.:

	make installer gui gui_extras release dvd

    (All 'dvd' would do is generate a dvd compatible image for burning to
    dvd instead of cd).  I did a quick perusal of what I have on my
    workstation:

    * X
    * Firefox
    * Linux emulation
    * Open Office (linux version)
    * fvwm2
    * xpdf
    * freetype2

    I'd also suggest some image editing tools like gimp, and maybe the KDE
    gui suite.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From justin at shiningsilence.com  Thu Mar  6 09:42:44 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Thu, 6 Mar 2008 09:42:44 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <55427.65.106.147.226.1204825168.squirrel@www.shiningsilence.com>

On Thu, March 6, 2008 8:34 am, Sascha Wildner wrote:

> That said, I'm now primarily interested in opinions/ideas/... about the
> direction this should take. Which packages would we like to see on the
> CD? Should it be a generic setup with the "most common things"
> installed, so a system can be quickly setup by the installer (which will
> cpdup /usr/pkg). Or should it be a more specialized set of tools? Or
> even as many packages as possible (Live DVD?). Etc., etc.

What Robert said is good - whatever's needed to enable DragonFly-specific
features.  Along with that would be some sort of documentation (a README? 
A HTML file on whatever desktop we provide) that points people at the
different DragonFly tools, so they know what to try and how to try it.

There's going to be some percentage of people who try DragonFly who don't
know about vkernels, for instance, but there's our chance to educate them.
 I'm probably volunteering myself, aren't I?





From sdavtaker at gmail.com  Thu Mar  6 09:50:09 2008
From: sdavtaker at gmail.com (=?UTF-8?Q?Sd=C3=A4vtaker?=)
Date: Thu, 6 Mar 2008 09:50:09 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <c37d69f60803060947t110750c0sd6b542ea505d188d@mail.gmail.com>

Cool Sascha :-)
I just posted about this 1 or 2 days ago in the SOC project ideas thread.
Want to mentor this one? ;-)
Damian

On Thu, Mar 6, 2008 at 2:28 PM, Matthew Dillon
<dillon at apollo.backplane.com> wrote:
>
>  :Hi all,
>
> :
>  :this is probably as good a moment as any to come out of the forest with
>  :this. The patch at
>  :
>  :http://leaf.dragonflybsd.org/~swildner/nrelease_gui.diff
>  :
>  :adds some code to nrelease/ to build a LiveCD with xorg and so on
>  :(currently, only the xorg metapackages and fluxbox are added). In order
>  :to build one, you need a local dir with the pkgsrc binary packages (see
>  :below).
>  :
>  :The following commands should then do the trick:
>
>     It looks reasonable, though the package copy has to be tightened
>     up a bit I think.
>
>  :...
>  :installed, so a system can be quickly setup by the installer (which will
>
> :cpdup /usr/pkg). Or should it be a more specialized set of tools? Or
>  :even as many packages as possible (Live DVD?). Etc., etc.
>  :
>  :Before continuing on it, I'm really interested in people's input so
>  :don't hold anything back, please. :)
>  :
>  :Sascha
>
>     I think this is an excellent time to work up a DVD build and to
>     add various 'flavor' extras.  So, e.g.:
>
>         make installer gui gui_extras release dvd
>
>     (All 'dvd' would do is generate a dvd compatible image for burning to
>     dvd instead of cd).  I did a quick perusal of what I have on my
>     workstation:
>
>     * X
>     * Firefox
>     * Linux emulation
>     * Open Office (linux version)
>     * fvwm2
>     * xpdf
>     * freetype2
>
>     I'd also suggest some image editing tools like gimp, and maybe the KDE
>     gui suite.
>
>                                         -Matt
>                                         Matthew Dillon
>                                         <dillon at backplane.com>
>



-- 
Sd?vtaker prays to Rikku goddess for a good treasure.



From saw at online.de  Thu Mar  6 11:54:01 2008
From: saw at online.de (Sascha Wildner)
Date: Thu, 06 Mar 2008 20:54:01 +0100
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <47d04ba2$0$856$415eb37d@crater_reader.dragonflybsd.org>

Matthew Dillon wrote:
    It looks reasonable, though the package copy has to be tightened
    up a bit I think.
It looks as if it would work with mount_null'ing the chroot's 
/tmp/packages. I'll have a better patch ready tomorrow.

Sascha

--
http://yoyodyne.ath.cx



From c.turner at 199technologies.org  Thu Mar  6 19:11:44 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Thu, 6 Mar 2008 19:11:44 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Misc. ACPI / suspend
In-Reply-To: <47CA073B.6020106@199technologies.org>
Message-ID: <47D0B079.3060905@199technologies.org>

Chris Turner wrote:
Wondering if anyone more well versed in the ACPI implementation could
comment on the applicability of:
http://lkml.org/lkml/2007/4/6/69

Doing a little digging, it seems like

. /platform/pc32/i386/i686_mem.c

*might* have the necessary infrastructure to remap the MTRR's per the 
thread referenced,

but:

. /platform/pc32/acpica5/acpi_wakeup.c

doesn't seem to be using this infrastructure..

I'm no where near reaching an understanding of this yet,
but I'm wondering 3 things:
1) does anyone have ACPI (instead of APM)
   sleep / suspend / wakeup working on Dfly ?
2) If so, what machines are being used ?
3) Same question for other BSDs - my understanding is NetBSD is most
   'advanced' w/r/t power managment - but I'm not 100% on this ...
would looove to have a sleeping / resuming / scaling laptop running some 
BSD flavor.. am willing to work towards that end, esp. w/r/t Dfly -
trying to chart a course to figguring this out.

Thanks all,

- Chris




From c.turner at 199technologies.org  Thu Mar  6 19:12:33 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Thu, 6 Mar 2008 19:12:33 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: PCI Bios / Interrupt remapping / etc
Message-ID: <47D0B211.6000002@199technologies.org>

Doing a bit of digging here for my long-standing CBB+SIO interupt and 
buffer problem -

one machine I've tested against was an OpenBSD machine, which didn't
always work to handle the cardbus sio card on a PCI cardbus adapter
-

tuning up some of the device flags in:

http://www.openbsd.org/cgi-bin/man.cgi?query=pcibios&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=html

seems to have alleviated the problem for that os..

I'm just only starting to get up to speed on how DF handles these types 
of things (namely initial PIC / interrupt layout at boot time device 
enumeration), but am wondering if anyone familiar with this area of the 
code has any comments / advice w/r/t the capabilities of the DF bios 
drivers
and the various quirks / fixup mentioned in the link above..

looking to possibly investigate fixing up some of these issues over time.

Thanks

- Chris







From pavalos at theshell.com  Fri Mar  7 01:14:55 2008
From: pavalos at theshell.com (Peter Avalos)
Date: Fri, 7 Mar 2008 01:14:55 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: cam locking
Message-ID: <20080307091024.GC1652@ylem.theshell.com>

So I've been working on locking up cam using lockmgr locks, and here's
what I have so far:

http://www.theshell.com/~pavalos/wip/cam-lock.patch

Most of the work is obtained from FreeBSD.  I've only been running this
on my SCSI machine for a day, but because the patch is so large, I wanted
to make it available for people to review if they have some spare time.

Thanks,
Peter
Attachment:
pgp00002.pgp
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00002.pgp
Type: application/octet-stream
Size: 197 bytes
Desc: "Description: PGP signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080307/9a17ecd8/attachment-0001.obj>

From jspringe at uos.de  Fri Mar  7 03:25:17 2008
From: jspringe at uos.de (Jost Tobias Springenberg)
Date: Fri, 7 Mar 2008 12:25:17 +0100
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <20080307122517.72c9e2b1.jspringe@uos.de>

On Tue, 4 Mar 2008 11:28:15 -0500 (EST)
"Justin C. Sherrill" <justin at shiningsilence.com> wrote:

> On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
> > Hi,
> >
> > Google just announced its Summer of Code for 2008:
> >
> > 	http://code.google.com/soc/2008/
> >
> > I think this would be a great opportunity for DragonFly to participate
> > as a mentoring organisation.  We could attract new developers and could
> > get code/work done.  Looking at the SoC results of the other BSDs most
> > of their projects were a success.  Of course, not all, but a reasonable
> > percentage.  See [1] and [2].
> 
> We've applied in previous years - Jeff Hsu did one year, and I put
> together the application last year.  The hardest thing to find was
> students (and they are the thing that helps SoC applications a lot, I
> think).
> 
> Any student volunteers?  We have mentors.
> 

I read this mailing list for quite a while now and thought about contributing stuff
to DFfly several times, so yes why not take this opportunity if it's there.

-- 
Jost Tobias Springenberg <jspringe at uos.de>




From tgen at netphreax.net  Fri Mar  7 05:17:27 2008
From: tgen at netphreax.net (Thomas E. Spanjaard)
Date: Fri, 7 Mar 2008 05:17:27 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: PCI Bios / Interrupt remapping / etc
In-Reply-To: <47D0B211.6000002@199technologies.org>
Message-ID: <47D13FB4.5080306@netphreax.net>

Chris Turner wrote:
Doing a bit of digging here for my long-standing CBB+SIO interupt and 
buffer problem -

one machine I've tested against was an OpenBSD machine, which didn't
always work to handle the cardbus sio card on a PCI cardbus adapter
-

tuning up some of the device flags in:

http://www.openbsd.org/cgi-bin/man.cgi?query=pcibios&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=html 

seems to have alleviated the problem for that os..

I'm just only starting to get up to speed on how DF handles these types 
of things (namely initial PIC / interrupt layout at boot time device 
enumeration), but am wondering if anyone familiar with this area of the 
code has any comments / advice w/r/t the capabilities of the DF bios 
drivers
and the various quirks / fixup mentioned in the link above..

looking to possibly investigate fixing up some of these issues over time.
Our code that handles issues like this (in cases where you're not using 
APICs, just PICs and PIRs) lives in bus/pci/i386/. Not that running 
without APIC support is all that common on modern machines anymore...
--
        Thomas E. Spanjaard
        tgen at netphreax.net
Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00003.pgp
Type: application/octet-stream
Size: 186 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080307/61366b5c/attachment-0001.obj>

From tgen at netphreax.net  Fri Mar  7 05:16:51 2008
From: tgen at netphreax.net (Thomas E. Spanjaard)
Date: Fri, 7 Mar 2008 05:16:51 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Misc. ACPI / suspend
In-Reply-To: <47CA073B.6020106@199technologies.org>
Message-ID: <47D13F07.9080308@netphreax.net>

Chris Turner wrote:
1) does anyone have ACPI (instead of APM)
   sleep / suspend / wakeup working on Dfly ?
2) If so, what machines are being used ?
3) Same question for other BSDs - my understanding is NetBSD is most
   'advanced' w/r/t power managment - but I'm not 100% on this ...
would looove to have a sleeping / resuming / scaling laptop running some 
BSD flavor.. am willing to work towards that end, esp. w/r/t Dfly -
trying to chart a course to figguring this out.
I have ACPI S3 suspend working like a charm on my IBM ThinkPad R40 
(Pentium M "Banias" 1.3GHz, speedstepping works just fine), running 
NetBSD 3.99.21.
--
        Thomas E. Spanjaard
        tgen at netphreax.net
Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00004.pgp
Type: application/octet-stream
Size: 186 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080307/de3e5104/attachment-0001.obj>

From civilizd at gmail.com  Fri Mar  7 09:06:41 2008
From: civilizd at gmail.com (Vita "CiV" Cizek)
Date: Fri, 7 Mar 2008 09:06:41 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <98d564710803070853q1c73d795m6e6c5cc5049fa099@mail.gmail.com>

>  Any student volunteers?  We have mentors.
>
I am interested too, especially in some kernel-related work.




From justin at shiningsilence.com  Sat Mar  8 12:07:51 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Sat, 8 Mar 2008 12:07:51 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google SoC 2008 - mentors mentors mentors
Message-ID: <51558.192.168.0.252.1205006403.squirrel@www.shiningsilence.com>

If you are willing to mentor for the Google 2008 Summer of Code, please
speak up.  Right now we have: (from our wiki page)

Matthias
Sephe
TGEN
corecode

Part of the application process includes naming people as mentors (student
applications come later), so I want to get as complete a list as possible.

The application is due on the 12th, so if you want to mentor, now's the
time to say so.

Google's SoC FAQ is here: http://code.google.com/soc/2008/faqs.html

Our wiki page is here: http://wiki.dragonflybsd.org/index.cgi/GoogleSoC2008

- much credit to Matthias and others for getting that set up.





From saw at online.de  Sat Mar  8 14:26:07 2008
From: saw at online.de (Sascha Wildner)
Date: Sat, 08 Mar 2008 23:26:07 +0100
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <47d31245$0$848$415eb37d@crater_reader.dragonflybsd.org>

Sascha Wildner wrote:
Hi all,

this is probably as good a moment as any to come out of the forest with 
this. The patch at

http://leaf.dragonflybsd.org/~swildner/nrelease_gui.diff
Ok, I have committed the stuff as an example.

I'm not sure if my free time permits to work on a full-blown live CD 
with X11 and other good things (I already feel my interest wandering off 
in other directions) so if anyone wants to pick up the ball, go ahead. :)

Sascha

--
http://yoyodyne.ath.cx



From qhwt+dfly at les.ath.cx  Tue Mar 11 22:21:31 2008
From: qhwt+dfly at les.ath.cx (YONETANI Tomokazu)
Date: Tue, 11 Mar 2008 22:21:31 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Misc. ACPI / suspend
In-Reply-To: <47CA073B.6020106@199technologies.org>
Message-ID: <20080312051219.GA56091@les.ath.cx>

On Thu, Mar 06, 2008 at 10:03:21PM -0500, Chris Turner wrote:
> 1) does anyone have ACPI (instead of APM)
>    sleep / suspend / wakeup working on Dfly ?
> 2) If so, what machines are being used ?

Dynabook SS3500 (http://www.tlt.co.jp/pc/catalog/ss/02110735/index_j.htm).
It's old and can get very hot(thus frequently turns on the cooling fan)
even when it's running Windows.  I haven't turned it on for about several
months though.

Cheers.




From c.turner at 199technologies.org  Wed Mar 12 04:37:22 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Wed, 12 Mar 2008 04:37:22 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Misc. ACPI / suspend
In-Reply-To: <47CA073B.6020106@199technologies.org>
Message-ID: <47D7BEE3.6010907@199technologies.org>

YONETANI Tomokazu wrote:
On Thu, Mar 06, 2008 at 10:03:21PM -0500, Chris Turner wrote:
1) does anyone have ACPI (instead of APM)
   sleep / suspend / wakeup working on Dfly ?
Cheers.
ditto..

Suppose this should go to docs@ - in any case..

Thinking about setting up a wiki page on the issue so we
can discuss / track what 'good' hardware / drivers / implementations / 
etc are 'out there' - anyone have any suggestions on where this should
go?

http://wiki.dragonflybsd.org/index.cgi/acpi-overview.html

Remains from the handbook conversion - but I'm hesitant to 'over wikify'
this ..



From c.turner at 199technologies.org  Wed Mar 12 15:36:52 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Wed, 12 Mar 2008 15:36:52 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: devel/cscope
Message-ID: <47D85A08.8040103@199technologies.org>

why oh why did I take so long to try this out !!!

just sharing my eureka moment with the list..

- Chris




From dudu at dudu.ro  Wed Mar 12 15:50:14 2008
From: dudu at dudu.ro (Vlad GALU)
Date: Wed, 12 Mar 2008 15:50:14 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: devel/cscope
In-Reply-To: <47D85A08.8040103@199technologies.org>
Message-ID: <ad79ad6b0803121547r2bf67ffep9e40badaac6490f8@mail.gmail.com>

On 3/13/08, Chris Turner <c.turner at 199technologies.org> wrote:
> why oh why did I take so long to try this out !!!
>
>  just sharing my eureka moment with the list..


    Works nice with vim, too!

>
>
>  - Chris
>


-- 
Mahnahmahnah!




From justin at shiningsilence.com  Sun Mar 16 21:06:13 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Sun, 16 Mar 2008 21:06:13 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: binary packages for 1.12 coming in
Message-ID: <1372.192.168.0.252.1205726088.squirrel@www.shiningsilence.com>

The binary build for 1.12 is taking quite a while.  I've started copying
in newly built packages to
pkgbox.dragonflybsd.org/packages/DragonFly-1.12/i386/ - this should be
getting copied out to mirrors over the next while.

There are currently 1283 packages built, which leaves a whole lot to go;
I'll copy new packages in as they complete.





From hasso at estpak.ee  Wed Mar 19 04:31:08 2008
From: hasso at estpak.ee (Hasso Tepper)
Date: Wed, 19 Mar 2008 04:31:08 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Some questions regarding ACPI
Message-ID: <200803191322.46366.hasso@estpak.ee>

I'm working on bringing in some laptop (and especially thinkpad) specific 
ACPI code from FreeBSD into DragonFly. I never touched ACPI stuff before 
and haven't followed it much either, so I have some questions.

* FreeBSD uses ACPI_SERIAL_* heavily. What's the locking situation in 
  DragonFly and why?

* As far as I can see, PCI integration is commented out in DragonFly. 
  What's the state of it and why?

* platform/pc32/acpica5/acpi_toshiba.c - why is it there? I don't think 
  that this is something pc32 specific in it and it should work in pc64 
  laptops as well. Any objections to move it into 
  dev/acpica5/acpi_toshiba/ ?

What's the current status of ACPI in general? AFAICS our acpica is quite 
old - what needs to be done to bring in newer one?


-- 
Hasso




From qhwt+dfly at les.ath.cx  Wed Mar 19 09:24:50 2008
From: qhwt+dfly at les.ath.cx (YONETANI Tomokazu)
Date: Wed, 19 Mar 2008 09:24:50 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Some questions regarding ACPI
In-Reply-To: <200803191322.46366.hasso@estpak.ee>
Message-ID: <20080319161703.GA51509@les.ath.cx>

On Wed, Mar 19, 2008 at 01:22:46PM +0200, Hasso Tepper wrote:
> I'm working on bringing in some laptop (and especially thinkpad) specific 
> ACPI code from FreeBSD into DragonFly. I never touched ACPI stuff before 
> and haven't followed it much either, so I have some questions.

So you want to port some of ACPI support drivers, or to do a fresh port
of ACPI driver from FreeBSD?

> * FreeBSD uses ACPI_SERIAL_* heavily. What's the locking situation in 
>   DragonFly and why?

The current ACPI driver in DragonFly is based on that of FreeBSD as of
end of June, 2004, plus some fixes brought in later (and ACPICA part
has been updated twice since then).  That was before they introduced
the MPSAFE changes into ACPI code, and we use critical section
(crit_{enter,exit}) in most places (and lockmgr lock in a few place).

> * As far as I can see, PCI integration is commented out in DragonFly. 
>   What's the state of it and why?

When we replaced the implementation taken from FreeBSD 4.x with that
brought from FreeBSD 5.x, which added the PCI part, many people
experienced problems until they turned off ACPI completely, or add "pci"
to "debug.acpi.disabled" loader variable.  AFAIK the PCI part in the ACPI
driver almost hasn't been adjusted to work with our version of PCI code.

> * platform/pc32/acpica5/acpi_toshiba.c - why is it there? I don't think 
>   that this is something pc32 specific in it and it should work in pc64 
>   laptops as well. Any objections to move it into 
>   dev/acpica5/acpi_toshiba/ ?

In FreeBSD it used to be sitting at i386/acpica/acpi_toshiba.c and was
later moved into acpi_support.  That change hasn't hit our tree (in fact,
we have no acpi support drivers other than that).  It seems that FreeBSD
has them in dev/acpi_support now, and we for some reason have that
directory in our CVS repository (but containing no files in it).

> What's the current status of ACPI in general? AFAICS our acpica is quite 
> old - what needs to be done to bring in newer one?

Actually, it's not very important to keep just ACPICA latest, but
if you bring the ACPI driver from FreeBSD you need to bring ACPICA code
that matches their version, and it IS important.  And it generally requires
you much work to just update ACPICA part anyway because of how they
change things on every release.

Cheers.




From hasso at estpak.ee  Wed Mar 19 12:29:52 2008
From: hasso at estpak.ee (Hasso Tepper)
Date: Wed, 19 Mar 2008 12:29:52 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Some questions regarding ACPI
In-Reply-To: <200803191322.46366.hasso@estpak.ee>
Message-ID: <200803192115.35396.hasso@estpak.ee>

YONETANI Tomokazu wrote:
> On Wed, Mar 19, 2008 at 01:22:46PM +0200, Hasso Tepper wrote:
> > I'm working on bringing in some laptop (and especially thinkpad)
> > specific ACPI code from FreeBSD into DragonFly. I never touched ACPI
> > stuff before and haven't followed it much either, so I have some
> > questions.
>
> So you want to port some of ACPI support drivers, or to do a fresh port
> of ACPI driver from FreeBSD?

I'm only interested in support drivers and the reason is pure practical - 
newer thinkpads handle less and less hotkeys etc in hardware and require 
support form OS. acpi_ibm and acpi_video are examples of such modules 
which would help a lot of these newer thinkpad users.

acpi_ibm is almost ready to commit (renamed to acpi_thinkpad though).

> > * FreeBSD uses ACPI_SERIAL_* heavily. What's the locking situation in
> >   DragonFly and why?
>
> The current ACPI driver in DragonFly is based on that of FreeBSD as of
> end of June, 2004, plus some fixes brought in later (and ACPICA part
> has been updated twice since then).  That was before they introduced
> the MPSAFE changes into ACPI code, and we use critical section
> (crit_{enter,exit}) in most places (and lockmgr lock in a few place).

Mkay. Will look at more closely.

> > * As far as I can see, PCI integration is commented out in DragonFly.
> >   What's the state of it and why?
>
> When we replaced the implementation taken from FreeBSD 4.x with that
> brought from FreeBSD 5.x, which added the PCI part, many people
> experienced problems until they turned off ACPI completely, or add
> "pci" to "debug.acpi.disabled" loader variable.  AFAIK the PCI part in
> the ACPI driver almost hasn't been adjusted to work with our version of
> PCI code.

I'm afraid that it's beyond my skills, but while looking at acpi_video I 
discovered that it's hard to handle correctly without PCI support.

> > * platform/pc32/acpica5/acpi_toshiba.c - why is it there? I don't
> > think that this is something pc32 specific in it and it should work
> > in pc64 laptops as well. Any objections to move it into
> >   dev/acpica5/acpi_toshiba/ ?
>
> In FreeBSD it used to be sitting at i386/acpica/acpi_toshiba.c and was
> later moved into acpi_support.  That change hasn't hit our tree (in
> fact, we have no acpi support drivers other than that).  It seems that
> FreeBSD has them in dev/acpi_support now, and we for some reason have
> that directory in our CVS repository (but containing no files in it).

I don't see it ;). Makes sense though. So, any objections if I move 
acpi_toshiba into sys/dev/acpi_support and add new acpi_thinkpad there as 
well? 

> > What's the current status of ACPI in general? AFAICS our acpica is
> > quite old - what needs to be done to bring in newer one?
>
> Actually, it's not very important to keep just ACPICA latest, but
> if you bring the ACPI driver from FreeBSD you need to bring ACPICA code
> that matches their version, and it IS important.  And it generally
> requires you much work to just update ACPICA part anyway because of how
> they change things on every release.

Someone else has to do it :).

Thanks for info.


-- 
Hasso




From dillon at apollo.backplane.com  Wed Mar 19 14:01:13 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Wed, 19 Mar 2008 14:01:13 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: panic: assertion: hammer_btree_cmp(cursor->left_bound,	&cursor->node->ondisk->elms[0].leaf.base) <= 0 in btree_split_leaf
In-Reply-To: <200802232204.m1NM4cxd046264@apollo.backplane.com>
Message-ID: <200803192054.m2JKsjwn045137@apollo.backplane.com>


:Hi.
:While trying to find a procedure to reliably reproduce the panic
:I reported last time, I caught a different panic (uploaded at
: ~y0netan1/crash/9/ on my leaf account).  I wrote the following shell
:script (make sure to edit variables DISKS and MOUNTPT before using this
:script or it may trash your system):
:  #!/bin/sh -ex
:  DISKS="/dev/ad0s1f"
:  MOUNTPT=/mnt/HAMMER
:
:  cd /
:  newfs_hammer -L TEST $DISKS
:  for i in `seq 1 100`; do
:..
:And the panic is triggered by rm command.
:I'll try to see if it's possible to reproduce the last one without
:unmounting then mounting the HAMMER fs.
:
:Cheers.

    I believe I have fixed this panic.  hammer_make_separator() had a bug
    in it.

    There is still an issue with the node ref count on umount.

    Please continue to life-test the code.  The reblocking code
    (hammer reblock /mnt) should work now, as should the pruning code
    (e.g. hammer prune /mnt everything).

    The filesystem full case is still not handled and will cause bad things
    to happen.  The undo code isn't finished yet either but it is getting
    there (it's writing stuff out but not setting the sequence number and
    not trying to recover-on-mount yet).

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From qhwt+dfly at les.ath.cx  Wed Mar 19 19:45:40 2008
From: qhwt+dfly at les.ath.cx (YONETANI Tomokazu)
Date: Wed, 19 Mar 2008 19:45:40 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Some questions regarding ACPI
In-Reply-To: <200803191322.46366.hasso@estpak.ee>
Message-ID: <20080320023828.GA53648@les.ath.cx>

On Wed, Mar 19, 2008 at 09:15:35PM +0200, Hasso Tepper wrote:
> YONETANI Tomokazu wrote:
> > On Wed, Mar 19, 2008 at 01:22:46PM +0200, Hasso Tepper wrote:
> > > I'm working on bringing in some laptop (and especially thinkpad)
> > > specific ACPI code from FreeBSD into DragonFly. I never touched ACPI
> > > stuff before and haven't followed it much either, so I have some
> > > questions.
> >
> > So you want to port some of ACPI support drivers, or to do a fresh port
> > of ACPI driver from FreeBSD?
> 
> I'm only interested in support drivers and the reason is pure practical - 
> newer thinkpads handle less and less hotkeys etc in hardware and require 
> support form OS. acpi_ibm and acpi_video are examples of such modules 
> which would help a lot of these newer thinkpad users.
> 
> acpi_ibm is almost ready to commit (renamed to acpi_thinkpad though).

Ah, that's a good news!  My only concern is that ISTR someone mentioned
me that his colleague was thinking about porting ACPI driver itself,
so if you're not the person you may want to collaborate with him/her
so as not to waste the effort or time...

			:

> > In FreeBSD it used to be sitting at i386/acpica/acpi_toshiba.c and was
> > later moved into acpi_support.  That change hasn't hit our tree (in
> > fact, we have no acpi support drivers other than that).  It seems that
> > FreeBSD has them in dev/acpi_support now, and we for some reason have
> > that directory in our CVS repository (but containing no files in it).
> 
> I don't see it ;). Makes sense though. So, any objections if I move 
> acpi_toshiba into sys/dev/acpi_support and add new acpi_thinkpad there as 
> well? 

Sorry, I checked the CVS repository and it doesn't exist actually :)
I don't have any objection to moving it there.

Cheers.




From hasso at estpak.ee  Thu Mar 20 00:14:05 2008
From: hasso at estpak.ee (Hasso Tepper)
Date: Thu, 20 Mar 2008 00:14:05 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Some questions regarding ACPI
In-Reply-To: <200803191322.46366.hasso@estpak.ee>
Message-ID: <200803200904.50875.hasso@estpak.ee>

YONETANI Tomokazu wrote:
> On Wed, Mar 19, 2008 at 09:15:35PM +0200, Hasso Tepper wrote:
> > acpi_ibm is almost ready to commit (renamed to acpi_thinkpad though).
>
> Ah, that's a good news!  My only concern is that ISTR someone mentioned
> me that his colleague was thinking about porting ACPI driver itself,
> so if you're not the person you may want to collaborate with him/her
> so as not to waste the effort or time...

Current state in my repo is attached. It should work on 1.12 as well as it 
doesn't depend yet on moving stuff around.

add-acpi-if-m.patch adds some new stuff to the ACPI code to access 
embedded controllers and match ACPI devices by ID. Not sure how, where 
and whether at all these should be documented.

add-acpi-thinkpad.patch is the driver itself. Note that some stuff doesn't 
work yet on newer thinkpads, I plan to work on it later.

There is still some things to do though. I have to decide what to do with 
led(4) part and with locking. There is also one fatal issue - laptop 
locks up hardly (no panic) while unloading module. Any idea regarding 
this is welcome. And of course test results :).


-- 
Hasso
# HG changeset patch
# User Hasso Tepper <hasso at estpak.ee>
# Date 1205919290 -7200
# Branch HEAD
# Node ID 5a6e2705cc95a340abf973ae5df73ef34e070b79
# Parent  cd529e2e7f849034d5d5a0973cb98af50db0e797
imported patch adding-acpi-if-m.patch

diff --git a/sys/conf/files b/sys/conf/files
--- a/sys/conf/files
+++ b/sys/conf/files
@@ -1387,6 +1387,7 @@ emulation/dragonfly12/dfbsd12_stat.c	non
 ${OSACPI_MI_DIR}/acpi_cmbat.c		optional acpi
 ${OSACPI_MI_DIR}/acpi_cpu.c		optional acpi
 ${OSACPI_MI_DIR}/acpi_ec.c		optional acpi
+${OSACPI_MI_DIR}/acpi_if.m		optional acpi
 ${OSACPI_MI_DIR}/acpi_isab.c		optional acpi isa
 ${OSACPI_MI_DIR}/acpi_lid.c		optional acpi
 ${OSACPI_MI_DIR}/acpi_package.c		optional acpi
diff --git a/sys/conf/kmod.mk b/sys/conf/kmod.mk
--- a/sys/conf/kmod.mk
+++ b/sys/conf/kmod.mk
@@ -275,7 +275,7 @@ MFILES?= kern/bus_if.m kern/device_if.m 
     bus/pccard/card_if.m bus/pccard/power_if.m bus/pci/pci_if.m \
     bus/pci/pcib_if.m \
     bus/ppbus/ppbus_if.m bus/smbus/smbus_if.m bus/usb/usb_if.m \
-    dev/disk/nata/ata_if.m \
+    dev/acpica5/acpi_if.m dev/disk/nata/ata_if.m \
     dev/sound/pcm/ac97_if.m dev/sound/pcm/channel_if.m \
     dev/sound/pcm/feeder_if.m dev/sound/pcm/mixer_if.m \
     libiconv/iconv_converter_if.m dev/agp/agp_if.m opencrypto/crypto_if.m
diff --git a/sys/dev/acpica5/Makefile b/sys/dev/acpica5/Makefile
--- a/sys/dev/acpica5/Makefile
+++ b/sys/dev/acpica5/Makefile
@@ -69,12 +69,14 @@ SRCS+=  acpi_package.c
 # SRCS+=	acpi_pci.c acpi_pcib.c acpi_pcib_acpi.c acpi_pcib_pci.c
 # SRCS+=	acpi_pci_link.c
 SRCS+=  acpi_powerres.c acpi_resource.c acpi_thermal.c
-SRCS+=  acpi_timer.c
+SRCS+=  acpi_timer.c acpi_if.c
 SRCS+=  OsdDebug.c
 SRCS+=  OsdHardware.c OsdInterface.c OsdInterrupt.c OsdMemory.c OsdSchedule.c
 SRCS+=  OsdStream.c OsdSynch.c OsdTable.c OsdEnvironment.c
 SRCS+=  opt_acpi.h opt_bus.h opt_ddb.h
-SRCS+=  device_if.h bus_if.h pci_if.h pcib_if.h isa_if.h
+SRCS+=  device_if.h bus_if.h pci_if.h pcib_if.h isa_if.h acpi_if.h
+MFILES = kern/device_if.m kern/bus_if.m bus/pci/pci_if.m bus/pci/pcib_if.m
+MFILES+= bus/isa/isa_if.m dev/acpica5/acpi_if.m
 
 # Debugging support
 DBSRC=	dbcmds.c dbdisply.c dbexec.c dbfileio.c dbhistry.c
diff --git a/sys/dev/acpica5/acpi.c b/sys/dev/acpica5/acpi.c
--- a/sys/dev/acpica5/acpi.c
+++ b/sys/dev/acpica5/acpi.c
@@ -135,6 +135,7 @@ static int	acpi_release_resource(device_
 			int rid, struct resource *r);
 static uint32_t	acpi_isa_get_logicalid(device_t dev);
 static int	acpi_isa_get_compatid(device_t dev, uint32_t *cids, int count);
+static char	*acpi_device_id_probe(device_t bus, device_t dev, char **ids);
 static int	acpi_isa_pnp_probe(device_t bus, device_t child,
 			struct isa_pnp_id *ids);
 static void	acpi_probe_children(device_t bus);
@@ -189,6 +190,9 @@ static device_method_t acpi_methods[] = 
     DEVMETHOD(bus_deactivate_resource,	bus_generic_deactivate_resource),
     DEVMETHOD(bus_setup_intr,		bus_generic_setup_intr),
     DEVMETHOD(bus_teardown_intr,	bus_generic_teardown_intr),
+
+    /* ACPI bus */
+    DEVMETHOD(acpi_id_probe,		acpi_device_id_probe),
 
     /* ISA emulation */
     DEVMETHOD(isa_pnp_probe,		acpi_isa_pnp_probe),
@@ -1121,6 +1125,24 @@ out:
 	AcpiOsFree(buf.Pointer);
     ACPI_UNLOCK;
     return_VALUE (valid);
+}
+
+static char *
+acpi_device_id_probe(device_t bus, device_t dev, char **ids) 
+{
+    ACPI_HANDLE h;
+    int i;
+
+    h = acpi_get_handle(dev);
+    if (ids == NULL || h == NULL || acpi_get_type(dev) != ACPI_TYPE_DEVICE)
+	return (NULL);
+
+    /* Try to match one of the array of IDs with a HID or CID. */
+    for (i = 0; ids[i] != NULL; i++) {
+	if (acpi_MatchHid(h, ids[i]))
+	    return (ids[i]);
+    }
+    return (NULL);
 }
 
 static int
diff --git a/sys/dev/acpica5/acpi_ec.c b/sys/dev/acpica5/acpi_ec.c
--- a/sys/dev/acpica5/acpi_ec.c
+++ b/sys/dev/acpica5/acpi_ec.c
@@ -327,11 +327,19 @@ static ACPI_STATUS	EcWrite(struct acpi_e
 				UINT8 *Data);
 static int		acpi_ec_probe(device_t dev);
 static int		acpi_ec_attach(device_t dev);
+static int		acpi_ec_read_method(device_t dev, u_int addr,
+				ACPI_INTEGER *val, int width);
+static int		acpi_ec_write_method(device_t dev, u_int addr,
+				ACPI_INTEGER val, int width);
 
 static device_method_t acpi_ec_methods[] = {
     /* Device interface */
     DEVMETHOD(device_probe,	acpi_ec_probe),
     DEVMETHOD(device_attach,	acpi_ec_attach),
+
+    /* Embedded controller interface */
+    DEVMETHOD(acpi_ec_read,     acpi_ec_read_method),
+    DEVMETHOD(acpi_ec_write,    acpi_ec_write_method),
 
     {0, 0}
 };
@@ -620,6 +628,33 @@ error:
 			     sc->ec_data_res);
     /* mtx_destroy(&sc->ec_mtx); */
     return (ENXIO);
+}
+
+/* Methods to allow other devices (e.g., smbat) to read/write EC space. */
+static int
+acpi_ec_read_method(device_t dev, u_int addr, ACPI_INTEGER *val, int width)
+{
+    struct acpi_ec_softc *sc;
+    ACPI_STATUS status;
+
+    sc = device_get_softc(dev);
+    status = EcSpaceHandler(ACPI_READ, addr, width * 8, val, sc, NULL);
+    if (ACPI_FAILURE(status))
+        return (ENXIO);
+    return (0);
+}
+
+static int
+acpi_ec_write_method(device_t dev, u_int addr, ACPI_INTEGER val, int width)
+{
+    struct acpi_ec_softc *sc;
+    ACPI_STATUS status;
+
+    sc = device_get_softc(dev);
+    status = EcSpaceHandler(ACPI_WRITE, addr, width * 8, &val, sc, NULL);
+    if (ACPI_FAILURE(status))
+        return (ENXIO);
+    return (0);
 }
 
 static void
diff --git a/sys/dev/acpica5/acpi_if.m b/sys/dev/acpica5/acpi_if.m
new file mode 100644
--- /dev/null
+++ b/sys/dev/acpica5/acpi_if.m
@@ -0,0 +1,92 @@
+#-
+# Copyright (c) 2004 Nate Lawson
+# All rights reserved.
+#
+# Redistribution and use in source and binary forms, with or without
+# modification, are permitted provided that the following conditions
+# are met:
+# 1. Redistributions of source code must retain the above copyright
+#    notice, this list of conditions and the following disclaimer.
+# 2. Redistributions in binary form must reproduce the above copyright
+#    notice, this list of conditions and the following disclaimer in the
+#    documentation and/or other materials provided with the distribution.
+#
+# THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
+# ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+# ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
+# FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+# DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+# OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+# HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+# LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+# OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+# SUCH DAMAGE.
+#
+# $DragonFly$
+#
+
+#include <sys/bus.h>
+#include <sys/types.h>
+#include "acpi.h"
+
+INTERFACE acpi;
+
+#
+# Default implementation for acpi_id_probe().
+#
+CODE {
+	static char *
+	acpi_generic_id_probe(device_t bus, device_t dev, char **ids)
+	{
+		return (NULL);
+	}
+};
+
+#
+# Check a device for a match in a list of ID strings.  The strings can be
+# EISA PNP IDs or ACPI _HID/_CID values.
+#
+# device_t bus:  parent bus for the device
+#
+# device_t dev:  device being considered
+#
+# char **ids:  array of ID strings to consider
+#
+# Returns:  ID string matched or NULL if no match
+#
+METHOD char * id_probe {
+	device_t	bus;
+	device_t	dev;
+	char		**ids;
+} DEFAULT acpi_generic_id_probe;
+
+#
+# Read embedded controller (EC) address space
+#
+# device_t dev:  EC device
+# u_int addr:  Address to read from in EC space
+# ACPI_INTEGER *val:  Location to store read value
+# int width:  Size of area to read in bytes
+#
+METHOD int ec_read {
+	device_t	dev;
+	u_int		addr;
+	ACPI_INTEGER	*val;
+	int		width;
+};
+
+#
+# Write embedded controller (EC) address space
+#
+# device_t dev:  EC device
+# u_int addr:  Address to write to in EC space
+# ACPI_INTEGER val:  Value to write
+# int width:  Size of value to write in bytes
+#
+METHOD int ec_write {
+	device_t	dev;
+	u_int		addr;
+	ACPI_INTEGER	val;
+	int		width;
+};
diff --git a/sys/dev/acpica5/acpivar.h b/sys/dev/acpica5/acpivar.h
--- a/sys/dev/acpica5/acpivar.h
+++ b/sys/dev/acpica5/acpivar.h
@@ -29,6 +29,7 @@
  * $DragonFly: src/sys/dev/acpica5/acpivar.h,v 1.12 2007/10/23 03:04:48 y0netan1 Exp $
  */
 
+#include "acpi_if.h"
 #include "bus_if.h"
 #include <sys/eventhandler.h>
 #include <sys/sysctl.h>
# HG changeset patch
# User Hasso Tepper <hasso at estpak.ee>
# Date 1205995474 -7200
# Branch HEAD
# Node ID c5db8d4a7c6b25a8576a8d42c5029aaf0e23bfb6
# Parent  5a6e2705cc95a340abf973ae5df73ef34e070b79
[mq]: adding-acpi-thinkpad.patch

diff --git a/sys/dev/acpica5/Makefile b/sys/dev/acpica5/Makefile
--- a/sys/dev/acpica5/Makefile
+++ b/sys/dev/acpica5/Makefile
@@ -117,7 +117,7 @@ acpi_wakecode.h: acpi_wakecode.S
 	${MAKE} -f ${SYSDIR}/${OSACPI_MD_DIR}/Makefile \
 		MAKESRCPATH=${SYSDIR}/${OSACPI_MD_DIR}
 
-SUBDIR=	acpi_toshiba
+SUBDIR=	acpi_toshiba acpi_thinkpad
 all: ${PROG} ${SUBDIR}
 
 # *.o file for each patched *.c file is created under the same directory,
diff --git a/sys/dev/acpica5/acpi_thinkpad/Makefile b/sys/dev/acpica5/acpi_thinkpad/Makefile
new file mode 100644
--- /dev/null
+++ b/sys/dev/acpica5/acpi_thinkpad/Makefile
@@ -0,0 +1,9 @@
+# $DragonFly$
+
+SYSDIR?=${.CURDIR}/../../..
+
+KMOD=		acpi_thinkpad
+CFLAGS+=	-I${.OBJDIR}/.. -I${.CURDIR}/..
+SRCS=		acpi_thinkpad.c opt_acpi.h device_if.h bus_if.h
+
+.include <bsd.kmod.mk>
diff --git a/sys/dev/acpica5/acpi_thinkpad/acpi_thinkpad.c b/sys/dev/acpica5/acpi_thinkpad/acpi_thinkpad.c
new file mode 100644
--- /dev/null
+++ b/sys/dev/acpica5/acpi_thinkpad/acpi_thinkpad.c
@@ -0,0 +1,1046 @@
+/*
+ * Copyright (c) 2004 Takanori Watanabe
+ * Copyright (c) 2005 Markus Brueffer <markus at FreeBSD.org>
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *    notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *    notice, this list of conditions and the following disclaimer in the
+ *    documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+ */
+
+/*
+ * Driver for extra ACPI-controlled gadgets found on IBM and Lenovo ThinkPad
+ * laptops. Inspired by the ibm-acpi and tpb projects which implement these
+ * features on Linux.
+ *
+ *   acpi-ibm: <http://ibm-acpi.sourceforge.net/>
+ *        tpb: <http://www.nongnu.org/tpb/>
+ */
+
+#include "opt_acpi.h"
+#include <sys/param.h>
+#include <sys/kernel.h>
+#include <sys/bus.h>
+#include <machine/cpufunc.h>
+#include <sys/module.h>
+/* #include <dev/led/led.h> */
+#include <sys/sensors.h>
+#include <sys/sysctl.h>
+#include <machine/clock.h>
+
+#include "acpi.h"
+#include "acpivar.h"
+#include "acpi_if.h"
+
+#define _COMPONENT	ACPI_OEM
+ACPI_MODULE_NAME("THINKPAD")
+
+/* Internal methods */
+#define ACPI_THINKPAD_METHOD_EVENTS		1
+#define ACPI_THINKPAD_METHOD_EVENTMASK		2
+#define ACPI_THINKPAD_METHOD_HOTKEY		3
+#define ACPI_THINKPAD_METHOD_BRIGHTNESS		4
+#define ACPI_THINKPAD_METHOD_VOLUME		5
+#define ACPI_THINKPAD_METHOD_MUTE		6
+#define ACPI_THINKPAD_METHOD_THINKLIGHT		7
+#define ACPI_THINKPAD_METHOD_BLUETOOTH		8
+#define ACPI_THINKPAD_METHOD_WLAN		9
+#define ACPI_THINKPAD_METHOD_FANSPEED		10
+#define ACPI_THINKPAD_METHOD_FANLEVEL		11
+#define ACPI_THINKPAD_METHOD_FANSTATUS		12
+#define ACPI_THINKPAD_METHOD_THERMAL		13
+
+/* Hotkeys/Buttons */
+#define THINKPAD_RTC_HOTKEY1			0x64
+#define   THINKPAD_RTC_MASK_HOME		(1 << 0)
+#define   THINKPAD_RTC_MASK_SEARCH		(1 << 1)
+#define   THINKPAD_RTC_MASK_MAIL		(1 << 2)
+#define   THINKPAD_RTC_MASK_WLAN		(1 << 5)
+#define THINKPAD_RTC_HOTKEY2			0x65
+#define   THINKPAD_RTC_MASK_THINKPAD		(1 << 3)
+#define   THINKPAD_RTC_MASK_ZOOM		(1 << 5)
+#define   THINKPAD_RTC_MASK_VIDEO		(1 << 6)
+#define   THINKPAD_RTC_MASK_HIBERNATE		(1 << 7)
+#define THINKPAD_RTC_THINKLIGHT			0x66
+#define   THINKPAD_RTC_MASK_THINKLIGHT		(1 << 4)
+#define THINKPAD_RTC_SCREENEXPAND		0x67
+#define   THINKPAD_RTC_MASK_SCREENEXPAND	(1 << 5)
+#define THINKPAD_RTC_BRIGHTNESS			0x6c
+#define   THINKPAD_RTC_MASK_BRIGHTNESS		(1 << 5)
+#define THINKPAD_RTC_VOLUME			0x6e
+#define   THINKPAD_RTC_MASK_VOLUME		(1 << 7)
+
+/* Embedded Controller registers */
+#define THINKPAD_EC_BRIGHTNESS			0x31
+#define   THINKPAD_EC_MASK_BRI			0x7
+#define THINKPAD_EC_VOLUME			0x30
+#define   THINKPAD_EC_MASK_VOL			0xf
+#define   THINKPAD_EC_MASK_MUTE			(1 << 6)
+#define THINKPAD_EC_FANSTATUS			0x2F
+#define   THINKPAD_EC_MASK_FANLEVEL		0x3f
+#define   THINKPAD_EC_MASK_FANDISENGAGED	(1 << 6)
+#define   THINKPAD_EC_MASK_FANSTATUS		(1 << 7)
+#define THINKPAD_EC_FANSPEED			0x84
+
+/* CMOS Commands */
+#define THINKPAD_CMOS_VOLUME_DOWN		0
+#define THINKPAD_CMOS_VOLUME_UP			1
+#define THINKPAD_CMOS_VOLUME_MUTE		2
+#define THINKPAD_CMOS_BRIGHTNESS_UP		4
+#define THINKPAD_CMOS_BRIGHTNESS_DOWN		5
+
+/* ACPI methods */
+#define THINKPAD_NAME_KEYLIGHT			"KBLT"
+#define THINKPAD_NAME_WLAN_BT_GET		"GBDC"
+#define THINKPAD_NAME_WLAN_BT_SET		"SBDC"
+#define   THINKPAD_NAME_MASK_BT			(1 << 1)
+#define   THINKPAD_NAME_MASK_WLAN		(1 << 2)
+#define THINKPAD_NAME_THERMAL_GET		"TMP7"
+#define THINKPAD_NAME_THERMAL_UPDT		"UPDT"
+
+#define THINKPAD_NAME_EVENTS_STATUS_GET		"DHKC"
+#define THINKPAD_NAME_EVENTS_MASK_GET		"DHKN"
+#define THINKPAD_NAME_EVENTS_STATUS_SET		"MHKC"
+#define THINKPAD_NAME_EVENTS_MASK_SET		"MHKM"
+#define THINKPAD_NAME_EVENTS_GET		"MHKP"
+#define THINKPAD_NAME_EVENTS_AVAILMASK		"MHKA"
+
+#define ABS(x) (((x) < 0)? -(x) : (x))
+
+struct acpi_thinkpad_softc {
+	device_t	dev;
+	ACPI_HANDLE	handle;
+
+	/* Embedded controller */
+	device_t	ec_dev;
+	ACPI_HANDLE	ec_handle;
+
+	/* CMOS */
+	ACPI_HANDLE	cmos_handle;
+
+	/* Fan status */
+	ACPI_HANDLE	fan_handle;
+	int		fan_levels;
+
+	/* Keylight commands and states */
+	ACPI_HANDLE	light_handle;
+	int		light_cmd_on;
+	int		light_cmd_off;
+	int		light_val;
+	int		light_get_supported;
+	int		light_set_supported;
+
+	/* led(4) interface */
+	struct cdev	*led_dev;
+	int		led_busy;
+	int		led_state;
+
+	int		wlan_bt_flags;
+	int		thermal_updt_supported;
+
+	unsigned int	events_availmask;
+	unsigned int	events_initialmask;
+	int		events_mask_supported;
+	int		events_enable;
+
+	/* sensors(9) related */
+	struct ksensordev sensordev;
+	struct ksensor sensors[9];	/* XXX: 8 thermal + fan */
+
+	struct sysctl_ctx_list	*sysctl_ctx;
+	struct sysctl_oid	*sysctl_tree;
+};
+
+static struct {
+	char	*name;
+	int	method;
+	char	*description;
+	int	access;
+} acpi_thinkpad_sysctls[] = {
+	{
+		.name		= "events",
+		.method		= ACPI_THINKPAD_METHOD_EVENTS,
+		.description	= "ACPI events enable",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "eventmask",
+		.method		= ACPI_THINKPAD_METHOD_EVENTMASK,
+		.description	= "ACPI eventmask",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "hotkey",
+		.method		= ACPI_THINKPAD_METHOD_HOTKEY,
+		.description	= "Key Status",
+		.access		= CTLTYPE_INT | CTLFLAG_RD
+	},
+	{
+		.name		= "lcd_brightness",
+		.method		= ACPI_THINKPAD_METHOD_BRIGHTNESS,
+		.description	= "LCD Brightness",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "volume",
+		.method		= ACPI_THINKPAD_METHOD_VOLUME,
+		.description	= "Volume",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "mute",
+		.method		= ACPI_THINKPAD_METHOD_MUTE,
+		.description	= "Mute",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "thinklight",
+		.method		= ACPI_THINKPAD_METHOD_THINKLIGHT,
+		.description	= "Thinklight enable",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "bluetooth",
+		.method		= ACPI_THINKPAD_METHOD_BLUETOOTH,
+		.description	= "Bluetooth enable",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "wlan",
+		.method		= ACPI_THINKPAD_METHOD_WLAN,
+		.description	= "WLAN enable",
+		.access		= CTLTYPE_INT | CTLFLAG_RD
+	},
+	{
+		.name		= "fan_level",
+		.method		= ACPI_THINKPAD_METHOD_FANLEVEL,
+		.description	= "Fan level",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "fan",
+		.method		= ACPI_THINKPAD_METHOD_FANSTATUS,
+		.description	= "Fan enable",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+
+	{ NULL, 0, NULL, 0 }
+};
+
+/* ACPI_SERIAL_DECL(thinkpad, "ACPI THINKPAD extras"); */
+static int	acpi_thinkpad_probe(device_t dev);
+static int	acpi_thinkpad_attach(device_t dev);
+static int	acpi_thinkpad_detach(device_t dev);
+
+#if 0 /* not yet */
+static void	thinkpad_led(void *softc, int onoff);
+static void	thinkpad_led_task(struct acpi_thinkpad_softc *sc,
+		int pending __unused);
+#endif
+
+static int	acpi_thinkpad_sysctl(SYSCTL_HANDLER_ARGS);
+static int	acpi_thinkpad_sysctl_init(struct acpi_thinkpad_softc *sc,
+		int method);
+static int	acpi_thinkpad_sysctl_get(struct acpi_thinkpad_softc *sc,
+		int method);
+static int	acpi_thinkpad_sysctl_set(struct acpi_thinkpad_softc *sc,
+		int method, int val);
+
+static int	acpi_thinkpad_eventmask_set(struct acpi_thinkpad_softc *sc,
+		int val);
+static void	acpi_thinkpad_notify(ACPI_HANDLE h, UINT32 notify,
+		void *context);
+static void	acpi_thinkpad_refresh(void *);
+
+static device_method_t acpi_thinkpad_methods[] = {
+	/* Device interface */
+	DEVMETHOD(device_probe, acpi_thinkpad_probe),
+	DEVMETHOD(device_attach, acpi_thinkpad_attach),
+	DEVMETHOD(device_detach, acpi_thinkpad_detach),
+	{0, 0}
+};
+
+static driver_t	acpi_thinkpad_driver = {
+	"acpi_thinkpad",
+	acpi_thinkpad_methods,
+	sizeof(struct acpi_thinkpad_softc),
+};
+
+static devclass_t acpi_thinkpad_devclass;
+
+DRIVER_MODULE(acpi_thinkpad, acpi, acpi_thinkpad_driver,
+    acpi_thinkpad_devclass, 0, 0);
+MODULE_DEPEND(acpi_thinkpad, acpi, 1, 1, 1);
+static char    *thinkpad_ids[] = {"IBM0068", NULL};
+
+#if 0 /* not yet */
+static void
+thinkpad_led(void *softc, int onoff)
+{
+	struct acpi_thinkpad_softc* sc = (struct acpi_thinkpad_softc*) softc;
+
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+
+	if (sc->led_busy)
+		return;
+
+	sc->led_busy = 1;
+	sc->led_state = onoff;
+
+	AcpiOsExecute(OSL_NOTIFY_HANDLER, (void *)thinkpad_led_task, sc);
+}
+
+static void
+thinkpad_led_task(struct acpi_thinkpad_softc *sc, int pending __unused)
+{
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+
+	/* ACPI_SERIAL_BEGIN(thinkpad); */
+	acpi_thinkpad_sysctl_set(sc, ACPI_THINKPAD_METHOD_THINKLIGHT, sc->led_state);
+	/* ACPI_SERIAL_END(thinkpad); */
+
+	sc->led_busy = 0;
+}
+#endif
+
+static int
+acpi_thinkpad_probe(device_t dev)
+{
+	if (acpi_disabled("thinkpad") ||
+	    ACPI_ID_PROBE(device_get_parent(dev), dev, thinkpad_ids) == NULL ||
+	    device_get_unit(dev) != 0) 
+		return (ENXIO);
+
+	device_set_desc(dev, "IBM/Lenovo ThinkPad ACPI Extras");
+	return (0);
+}
+
+static int
+acpi_thinkpad_attach(device_t dev)
+{
+	struct acpi_thinkpad_softc	*sc;
+	struct acpi_softc	*acpi_sc;
+	devclass_t		ec_devclass;
+	int			i;
+
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t) __func__);
+
+	sc = device_get_softc(dev);
+	sc->dev = dev;
+	sc->handle = acpi_get_handle(dev);
+
+	acpi_sc = acpi_device_get_parent_softc(dev);
+
+	/* Look for the first embedded controller */
+        if (!(ec_devclass = devclass_find ("acpi_ec"))) {
+		if (bootverbose)
+			device_printf(dev, "Couldn't find acpi_ec devclass\n");
+		return (EINVAL);
+	}
+        if (!(sc->ec_dev = devclass_get_device(ec_devclass, 0))) {
+		if (bootverbose)
+			device_printf(dev, "Couldn't find acpi_ec device\n");
+		return (EINVAL);
+	}
+	sc->ec_handle = acpi_get_handle(sc->ec_dev);
+
+	/* ACPI_SERIAL_BEGIN(thinkpad); */
+
+#if 0
+	/* Get the sysctl tree */
+	sc->sysctl_ctx = device_get_sysctl_ctx(dev);
+	sc->sysctl_tree = device_get_sysctl_tree(dev);
+#endif
+	sysctl_ctx_init(sc->sysctl_ctx);
+	sc->sysctl_tree = SYSCTL_ADD_NODE(sc->sysctl_ctx,
+	    SYSCTL_CHILDREN(acpi_sc->acpi_sysctl_tree), OID_AUTO,
+	    "thinkpad", CTLFLAG_RD, 0, "");
+
+	/* Look for event mask and hook up the nodes */
+	sc->events_mask_supported = ACPI_SUCCESS(acpi_GetInteger(sc->handle,
+	    THINKPAD_NAME_EVENTS_MASK_GET, &sc->events_initialmask));
+
+	if (sc->events_mask_supported) {
+		SYSCTL_ADD_INT(sc->sysctl_ctx,
+		    SYSCTL_CHILDREN(sc->sysctl_tree), OID_AUTO,
+		    "initialmask", CTLFLAG_RD,
+		    &sc->events_initialmask, 0, "Initial eventmask");
+
+		/* The availmask is the bitmask of supported events */
+		if (ACPI_FAILURE(acpi_GetInteger(sc->handle,
+		    THINKPAD_NAME_EVENTS_AVAILMASK, &sc->events_availmask)))
+			sc->events_availmask = 0xffffffff;
+
+		SYSCTL_ADD_INT(sc->sysctl_ctx,
+		    SYSCTL_CHILDREN(sc->sysctl_tree), OID_AUTO,
+		    "availmask", CTLFLAG_RD,
+		    &sc->events_availmask, 0, "Mask of supported events");
+	}
+
+	/* Hook up proc nodes */
+	for (i = 0; acpi_thinkpad_sysctls[i].name != NULL; i++) {
+		if (!acpi_thinkpad_sysctl_init(sc,
+		    acpi_thinkpad_sysctls[i].method))
+			continue;
+
+		SYSCTL_ADD_PROC(sc->sysctl_ctx,
+		    SYSCTL_CHILDREN(sc->sysctl_tree), OID_AUTO,
+		    acpi_thinkpad_sysctls[i].name,
+		    acpi_thinkpad_sysctls[i].access,
+		    sc, i, acpi_thinkpad_sysctl, "I",
+		    acpi_thinkpad_sysctls[i].description);
+	}
+
+	/* ACPI_SERIAL_END(thinkpad); */
+
+	/* Handle notifies */
+	AcpiInstallNotifyHandler(sc->handle, ACPI_DEVICE_NOTIFY,
+	    acpi_thinkpad_notify, dev);
+
+#if 0
+	/* Hook up light to led(4) */
+	if (sc->light_set_supported)
+		sc->led_dev = led_create_state(thinkpad_led, sc, "thinklight",
+		    sc->light_val);
+#endif
+	/* Attach sensors(9). */
+	if (sensor_task_register(sc, acpi_thinkpad_refresh, 5)) {
+		device_printf(sc->dev, "unable to register update task\n");
+		return 1;
+	}
+
+	strlcpy(sc->sensordev.xname, device_get_nameunit(sc->dev),
+	    sizeof(sc->sensordev.xname));
+
+	/* XXX: Temp sensors */
+	for (i = 0; i < 8; ++i) {
+		sc->sensors[i].type = SENSOR_TEMP;
+		sensor_attach(&sc->sensordev, &sc->sensors[i]);
+	}
+	
+	/* Fan RPM sensor */
+	sc->sensors[8].type = SENSOR_FANRPM;
+	sensor_attach(&sc->sensordev, &sc->sensors[8]);
+
+	sensordev_install(&sc->sensordev);
+
+	return (0);
+}
+
+static int
+acpi_thinkpad_detach(device_t dev)
+{
+	int i;
+
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t) __func__);
+
+	struct acpi_thinkpad_softc *sc = device_get_softc(dev);
+
+	/* Disable events and restore eventmask */
+	/* ACPI_SERIAL_BEGIN(thinkpad); */
+	acpi_thinkpad_sysctl_set(sc, ACPI_THINKPAD_METHOD_EVENTS, 0);
+	acpi_thinkpad_sysctl_set(sc, ACPI_THINKPAD_METHOD_EVENTMASK,
+	    sc->events_initialmask);
+	/* ACPI_SERIAL_END(thinkpad); */
+
+	AcpiRemoveNotifyHandler(sc->handle, ACPI_DEVICE_NOTIFY,
+	    acpi_thinkpad_notify);
+
+	sysctl_ctx_free(sc->sysctl_ctx);
+
+#if 0
+	if (sc->led_dev != NULL)
+		led_destroy(sc->led_dev);
+#endif
+	sensordev_deinstall(&sc->sensordev);
+	for (i = 0; i < 9; i++)
+		sensor_detach(&sc->sensordev, &sc->sensors[i]);
+	sensor_task_unregister(sc);
+
+	return (0);
+}
+
+static int
+acpi_thinkpad_eventmask_set(struct acpi_thinkpad_softc *sc, int val)
+{
+	int i;
+	ACPI_OBJECT		arg[2];
+	ACPI_OBJECT_LIST	args;
+	ACPI_STATUS		status;
+
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+	/* ACPI_SERIAL_ASSERT(thinkpad); */
+
+	args.Count = 2;
+	args.Pointer = arg;
+	arg[0].Type = ACPI_TYPE_INTEGER;
+	arg[1].Type = ACPI_TYPE_INTEGER;
+
+	for (i = 0; i < 32; ++i) {
+		arg[0].Integer.Value = i+1;
+		arg[1].Integer.Value = (((1 << i) & val) != 0);
+		status = AcpiEvaluateObject(sc->handle,
+		    THINKPAD_NAME_EVENTS_MASK_SET, &args, NULL);
+
+		if (ACPI_FAILURE(status))
+			return (status);
+	}
+
+	return (0);
+}
+
+static int
+acpi_thinkpad_sysctl(SYSCTL_HANDLER_ARGS)
+{
+	struct acpi_thinkpad_softc	*sc;
+	int			arg;
+	int			error = 0;
+	int			function;
+	int			method;
+	
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+
+	sc = (struct acpi_thinkpad_softc *)oidp->oid_arg1;
+	function = oidp->oid_arg2;
+	method = acpi_thinkpad_sysctls[function].method;
+
+	/* ACPI_SERIAL_BEGIN(thinkpad); */
+	arg = acpi_thinkpad_sysctl_get(sc, method);
+	error = sysctl_handle_int(oidp, &arg, 0, req);
+
+	/* Sanity check */
+	if (error != 0 || req->newptr == NULL)
+		goto out;
+
+	/* Update */
+	error = acpi_thinkpad_sysctl_set(sc, method, arg);
+
+out:
+	/* ACPI_SERIAL_END(thinkpad); */
+	return (error);
+}
+
+static int
+acpi_thinkpad_sysctl_get(struct acpi_thinkpad_softc *sc, int method)
+{
+	ACPI_INTEGER	val_ec;
+	int 		val = 0, key;
+
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+	/* ACPI_SERIAL_ASSERT(thinkpad); */
+
+	switch (method) {
+	case ACPI_THINKPAD_METHOD_EVENTS:
+		acpi_GetInteger(sc->handle, THINKPAD_NAME_EVENTS_STATUS_GET,
+		    &val);
+		break;
+
+	case ACPI_THINKPAD_METHOD_EVENTMASK:
+		if (sc->events_mask_supported)
+			acpi_GetInteger(sc->handle,
+			    THINKPAD_NAME_EVENTS_MASK_GET, &val);
+		break;
+
+	case ACPI_THINKPAD_METHOD_HOTKEY:
+		/*
+		 * Construct the hotkey as a bitmask as illustrated below.
+		 * Note that whenever a key was pressed, the respecting bit
+		 * toggles and nothing else changes.
+		 * +--+--+-+-+-+-+-+-+-+-+-+-+
+		 * |11|10|9|8|7|6|5|4|3|2|1|0|
+		 * +--+--+-+-+-+-+-+-+-+-+-+-+
+		 *   |  | | | | | | | | | | |
+		 *   |  | | | | | | | | | | +- Home Button
+		 *   |  | | | | | | | | | +--- Search Button
+		 *   |  | | | | | | | | +----- Mail Button
+		 *   |  | | | | | | | +------- Thinkpad Button
+		 *   |  | | | | | | +--------- Zoom (Fn + Space)
+		 *   |  | | | | | +----------- WLAN Button
+		 *   |  | | | | +------------- Video Button
+		 *   |  | | | +--------------- Hibernate Button
+		 *   |  | | +----------------- Thinklight Button
+		 *   |  | +------------------- Screen expand (Fn + F8)
+		 *   |  +--------------------- Brightness
+		 *   +------------------------ Volume/Mute
+		 */
+		key = rtcin(THINKPAD_RTC_HOTKEY1);
+		val = (THINKPAD_RTC_MASK_HOME | THINKPAD_RTC_MASK_SEARCH |
+		    THINKPAD_RTC_MASK_MAIL | THINKPAD_RTC_MASK_WLAN) & key;
+		key = rtcin(THINKPAD_RTC_HOTKEY2);
+		val |= (THINKPAD_RTC_MASK_THINKPAD | THINKPAD_RTC_MASK_VIDEO |
+		    THINKPAD_RTC_MASK_HIBERNATE) & key;
+		val |= (THINKPAD_RTC_MASK_ZOOM & key) >> 1;
+		key = rtcin(THINKPAD_RTC_THINKLIGHT);
+		val |= (THINKPAD_RTC_MASK_THINKLIGHT & key) << 4;
+		key = rtcin(THINKPAD_RTC_SCREENEXPAND);
+		val |= (THINKPAD_RTC_MASK_THINKLIGHT & key) << 4;
+		key = rtcin(THINKPAD_RTC_BRIGHTNESS);
+		val |= (THINKPAD_RTC_MASK_BRIGHTNESS & key) << 5;
+		key = rtcin(THINKPAD_RTC_VOLUME);
+		val |= (THINKPAD_RTC_MASK_VOLUME & key) << 4;
+		break;
+
+	case ACPI_THINKPAD_METHOD_BRIGHTNESS:
+		ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_BRIGHTNESS, &val_ec, 1);
+		val = val_ec & THINKPAD_EC_MASK_BRI;
+		break;
+
+	case ACPI_THINKPAD_METHOD_VOLUME:
+		ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_VOLUME, &val_ec, 1);
+		val = val_ec & THINKPAD_EC_MASK_VOL;
+		break;
+
+	case ACPI_THINKPAD_METHOD_MUTE:
+		val = ((val_ec & THINKPAD_EC_MASK_MUTE) ==
+		    THINKPAD_EC_MASK_MUTE);
+		break;
+
+	case ACPI_THINKPAD_METHOD_THINKLIGHT:
+		if (sc->light_get_supported)
+			acpi_GetInteger(sc->ec_handle, THINKPAD_NAME_KEYLIGHT,
+			    &val);
+		else
+			val = sc->light_val;
+		break;
+
+	case ACPI_THINKPAD_METHOD_BLUETOOTH:
+		acpi_GetInteger(sc->handle, THINKPAD_NAME_WLAN_BT_GET, &val);
+		sc->wlan_bt_flags = val;
+		val = ((val & THINKPAD_NAME_MASK_BT) != 0);
+		break;
+
+	case ACPI_THINKPAD_METHOD_WLAN:
+		acpi_GetInteger(sc->handle, THINKPAD_NAME_WLAN_BT_GET, &val);
+		sc->wlan_bt_flags = val;
+		val = ((val & THINKPAD_NAME_MASK_WLAN) != 0);
+		break;
+
+	case ACPI_THINKPAD_METHOD_FANSPEED:
+		if (sc->fan_handle) {
+			if (ACPI_FAILURE(acpi_GetInteger(sc->fan_handle,
+			    NULL, &val)))
+				val = -1;
+		}
+		else {
+			ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_FANSPEED,
+			    &val_ec, 2);
+			val = val_ec;
+		}
+		break;
+
+	case ACPI_THINKPAD_METHOD_FANLEVEL:
+		/*
+		 * The THINKPAD_EC_FANSTATUS register works as follows:
+		 * Bit 0-5 indicate the level at which the fan operates. Only
+		 *       values between 0 and 7 have an effect. Everything
+		 *       above 7 is treated the same as level 7
+		 * Bit 6 overrides the fan speed limit if set to 1
+		 * Bit 7 indicates at which mode the fan operates:
+		 *       manual (0) or automatic (1)
+		 */
+		if (!sc->fan_handle) {
+			ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_FANSTATUS,
+			    &val_ec, 1);
+			val = val_ec & THINKPAD_EC_MASK_FANLEVEL;
+		}
+		break;
+
+	case ACPI_THINKPAD_METHOD_FANSTATUS:
+		if (!sc->fan_handle) {
+			ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_FANSTATUS,
+			    &val_ec, 1);
+			val = (val_ec & THINKPAD_EC_MASK_FANSTATUS) ==
+			    THINKPAD_EC_MASK_FANSTATUS;
+		}
+		else
+			val = -1;
+		break;
+	}
+
+	return (val);
+}
+
+static int
+acpi_thinkpad_sysctl_set(struct acpi_thinkpad_softc *sc, int method, int arg)
+{
+	int			val, step, i;
+	ACPI_INTEGER		val_ec;
+	ACPI_OBJECT		Arg;
+	ACPI_OBJECT_LIST	Args;
+	ACPI_STATUS		status;
+
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+	/* ACPI_SERIAL_ASSERT(thinkpad); */
+
+	switch (method) {
+	case ACPI_THINKPAD_METHOD_EVENTS:
+		if (arg < 0 || arg > 1)
+			return (EINVAL);
+
+		status = acpi_SetInteger(sc->handle,
+		    THINKPAD_NAME_EVENTS_STATUS_SET, arg);
+		if (ACPI_FAILURE(status))
+			return (status);
+		if (sc->events_mask_supported)
+			return acpi_thinkpad_eventmask_set(sc,
+			    sc->events_availmask);
+		break;
+
+	case ACPI_THINKPAD_METHOD_EVENTMASK:
+		if (sc->events_mask_supported)
+			return acpi_thinkpad_eventmask_set(sc, arg);
+		break;
+
+	case ACPI_THINKPAD_METHOD_BRIGHTNESS:
+		if (arg < 0 || arg > 7)
+			return (EINVAL);
+
+		if (sc->cmos_handle) {
+			/* Read the current brightness */
+			status = ACPI_EC_READ(sc->ec_dev,
+			    THINKPAD_EC_BRIGHTNESS, &val_ec, 1);
+			if (ACPI_FAILURE(status))
+				return (status);
+			val = val_ec & THINKPAD_EC_MASK_BRI;
+
+			Args.Count = 1;
+			Args.Pointer = &Arg;
+			Arg.Type = ACPI_TYPE_INTEGER;
+			Arg.Integer.Value = (arg > val) ?
+			    THINKPAD_CMOS_BRIGHTNESS_UP :
+			    THINKPAD_CMOS_BRIGHTNESS_DOWN;
+
+			step = (arg > val) ? 1 : -1;
+			for (i = val; i != arg; i += step) {
+				status = AcpiEvaluateObject(sc->cmos_handle,
+				    NULL, &Args, NULL);
+				if (ACPI_FAILURE(status))
+					break;
+			}
+		}
+		return ACPI_EC_WRITE(sc->ec_dev, THINKPAD_EC_BRIGHTNESS,
+		    arg, 1);
+		break;
+
+	case ACPI_THINKPAD_METHOD_VOLUME:
+		if (arg < 0 || arg > 14)
+			return (EINVAL);
+
+		status = ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_VOLUME,
+		    &val_ec, 1);
+		if (ACPI_FAILURE(status))
+			return (status);
+
+		if (sc->cmos_handle) {
+			val = val_ec & THINKPAD_EC_MASK_VOL;
+
+			Args.Count = 1;
+			Args.Pointer = &Arg;
+			Arg.Type = ACPI_TYPE_INTEGER;
+			Arg.Integer.Value = (arg > val) ?
+			    THINKPAD_CMOS_VOLUME_UP : THINKPAD_CMOS_VOLUME_DOWN;
+
+			step = (arg > val) ? 1 : -1;
+			for (i = val; i != arg; i += step) {
+				status = AcpiEvaluateObject(sc->cmos_handle,
+				    NULL, &Args, NULL);
+				if (ACPI_FAILURE(status))
+					break;
+			}
+		}
+		return ACPI_EC_WRITE(sc->ec_dev, THINKPAD_EC_VOLUME, arg +
+		    (val_ec & (~THINKPAD_EC_MASK_VOL)), 1);
+		break;
+
+	case ACPI_THINKPAD_METHOD_MUTE:
+		if (arg < 0 || arg > 1)
+			return (EINVAL);
+
+		status = ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_VOLUME,
+		    &val_ec, 1);
+		if (ACPI_FAILURE(status))
+			return (status);
+
+		if (sc->cmos_handle) {
+			val = val_ec & THINKPAD_EC_MASK_VOL;
+
+			Args.Count = 1;
+			Args.Pointer = &Arg;
+			Arg.Type = ACPI_TYPE_INTEGER;
+			Arg.Integer.Value = THINKPAD_CMOS_VOLUME_MUTE;
+
+			status = AcpiEvaluateObject(sc->cmos_handle, NULL,
+			    &Args, NULL);
+			if (ACPI_FAILURE(status))
+				break;
+		}
+		return ACPI_EC_WRITE(sc->ec_dev, THINKPAD_EC_VOLUME, (arg==1) ?
+		   val_ec | THINKPAD_EC_MASK_MUTE :
+		   val_ec & (~THINKPAD_EC_MASK_MUTE), 1);
+		break;
+
+	case ACPI_THINKPAD_METHOD_THINKLIGHT:
+		if (arg < 0 || arg > 1)
+			return (EINVAL);
+
+		if (sc->light_set_supported) {
+			Args.Count = 1;
+			Args.Pointer = &Arg;
+			Arg.Type = ACPI_TYPE_INTEGER;
+			Arg.Integer.Value = arg ?
+			    sc->light_cmd_on : sc->light_cmd_off;
+
+			status = AcpiEvaluateObject(sc->light_handle, NULL,
+			    &Args, NULL);
+			if (ACPI_SUCCESS(status))
+				sc->light_val = arg;
+			return (status);
+		}
+		break;
+
+	case ACPI_THINKPAD_METHOD_BLUETOOTH:
+		if (arg < 0 || arg > 1)
+			return (EINVAL);
+
+		val = (arg == 1) ? sc->wlan_bt_flags |
+		    THINKPAD_NAME_MASK_BT :
+		    sc->wlan_bt_flags & (~THINKPAD_NAME_MASK_BT);
+		return acpi_SetInteger(sc->handle, THINKPAD_NAME_WLAN_BT_SET,
+		    val);
+		break;
+
+	case ACPI_THINKPAD_METHOD_FANLEVEL:
+		if (arg < 0 || arg > 7)
+			return (EINVAL);
+
+		if (!sc->fan_handle) {
+			/* Read the current fanstatus */
+			ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_FANSTATUS,
+			    &val_ec, 1);
+			val = val_ec & (~THINKPAD_EC_MASK_FANLEVEL);
+
+			return ACPI_EC_WRITE(sc->ec_dev, THINKPAD_EC_FANSTATUS,
+			    val | arg, 1);
+		}
+		break;
+
+	case ACPI_THINKPAD_METHOD_FANSTATUS:
+		if (arg < 0 || arg > 1)
+			return (EINVAL);
+
+		if (!sc->fan_handle) {
+			/* Read the current fanstatus */
+			ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_FANSTATUS,
+			    &val_ec, 1);
+
+			return ACPI_EC_WRITE(sc->ec_dev, THINKPAD_EC_FANSTATUS,
+			    (arg == 1) ? (val_ec | THINKPAD_EC_MASK_FANSTATUS) :
+			    (val_ec & (~THINKPAD_EC_MASK_FANSTATUS)), 1);
+		}
+		break;
+	}
+
+	return (0);
+}
+
+static int
+acpi_thinkpad_sysctl_init(struct acpi_thinkpad_softc *sc, int method)
+{
+	int 			dummy;
+	ACPI_OBJECT_TYPE 	cmos_t;
+	ACPI_HANDLE		ledb_handle;
+
+	switch (method) {
+	case ACPI_THINKPAD_METHOD_EVENTS:
+		/* Events are disabled by default */
+		return (TRUE);
+
+	case ACPI_THINKPAD_METHOD_EVENTMASK:
+		return (sc->events_mask_supported);
+
+	case ACPI_THINKPAD_METHOD_HOTKEY:
+	case ACPI_THINKPAD_METHOD_BRIGHTNESS:
+	case ACPI_THINKPAD_METHOD_VOLUME:
+	case ACPI_THINKPAD_METHOD_MUTE:
+		/* EC is required here, which was already checked before */
+		return (TRUE);
+
+	case ACPI_THINKPAD_METHOD_THINKLIGHT:
+		sc->cmos_handle = NULL;
+		sc->light_get_supported = ACPI_SUCCESS(acpi_GetInteger(
+		    sc->ec_handle, THINKPAD_NAME_KEYLIGHT, &sc->light_val));
+
+		if ((ACPI_SUCCESS(AcpiGetHandle(sc->handle, "\\UCMS",
+		    &sc->light_handle)) ||
+		    ACPI_SUCCESS(AcpiGetHandle(sc->handle, "\\CMOS",
+		    &sc->light_handle)) ||
+		    ACPI_SUCCESS(AcpiGetHandle(sc->handle, "\\CMS",
+		    &sc->light_handle))) &&
+		    ACPI_SUCCESS(AcpiGetType(sc->light_handle, &cmos_t)) &&
+		    cmos_t == ACPI_TYPE_METHOD) {
+			sc->light_cmd_on = 0x0c;
+			sc->light_cmd_off = 0x0d;
+			sc->cmos_handle = sc->light_handle;
+		}
+		else if (ACPI_SUCCESS(AcpiGetHandle(sc->handle, "\\LGHT",
+		    &sc->light_handle))) {
+			sc->light_cmd_on = 1;
+			sc->light_cmd_off = 0;
+		}
+		else
+			sc->light_handle = NULL;
+
+		sc->light_set_supported = (sc->light_handle &&
+		    ACPI_FAILURE(AcpiGetHandle(sc->ec_handle, "LEDB",
+		    &ledb_handle)));
+
+		if (sc->light_get_supported)
+			return (TRUE);
+
+		if (sc->light_set_supported) {
+			sc->light_val = 0;
+			return (TRUE);
+		}
+
+		return (FALSE);
+
+	case ACPI_THINKPAD_METHOD_BLUETOOTH:
+	case ACPI_THINKPAD_METHOD_WLAN:
+		if (ACPI_SUCCESS(acpi_GetInteger(sc->handle,
+		    THINKPAD_NAME_WLAN_BT_GET, &dummy)))
+			return (TRUE);
+		return (FALSE);
+
+	case ACPI_THINKPAD_METHOD_FANSPEED:
+		/* 
+		 * Some models report the fan speed in levels from 0-7
+		 * Newer models report it contiguously
+		 */
+		sc->fan_levels = (ACPI_SUCCESS(AcpiGetHandle(sc->handle, "GFAN",
+		    &sc->fan_handle)) ||
+		    ACPI_SUCCESS(AcpiGetHandle(sc->handle, "\\FSPD",
+		    &sc->fan_handle)));
+		return (TRUE);
+
+	case ACPI_THINKPAD_METHOD_FANLEVEL:
+	case ACPI_THINKPAD_METHOD_FANSTATUS:
+		/* 
+		 * Fan status is only supported on those models,
+		 * which report fan RPM contiguously, not in levels
+		 */
+		if (sc->fan_levels)
+			return (FALSE);
+		return (TRUE);
+
+	case ACPI_THINKPAD_METHOD_THERMAL:
+		if (ACPI_SUCCESS(acpi_GetInteger(sc->ec_handle,
+		    THINKPAD_NAME_THERMAL_GET, &dummy))) {
+			sc->thermal_updt_supported =
+			    ACPI_SUCCESS(acpi_GetInteger(sc->ec_handle,
+			    THINKPAD_NAME_THERMAL_UPDT, &dummy));
+			return (TRUE);
+		}
+		return (FALSE);
+	}
+	return (FALSE);
+}
+
+static void
+acpi_thinkpad_notify(ACPI_HANDLE h, UINT32 notify, void *context)
+{
+	int		event, arg, type;
+	device_t	dev = context;
+	struct acpi_thinkpad_softc *sc = device_get_softc(dev);
+
+	ACPI_FUNCTION_TRACE_U32((char *)(uintptr_t)__func__, notify);
+
+	if (notify != 0x80)
+		device_printf(dev, "Unknown notify\n");
+
+	for (;;) {
+		acpi_GetInteger(acpi_get_handle(dev), THINKPAD_NAME_EVENTS_GET,
+		    &event);
+
+		if (event == 0)
+			break;
+
+		type = (event >> 12) & 0xf;
+		arg = event & 0xfff;
+		switch (type) {
+		case 1:
+			if (!(sc->events_availmask & (1 << (arg - 1)))) {
+				device_printf(dev, "Unknown key %d\n", arg);
+				break;
+			}
+
+			/* Notify devd(8) */
+			device_printf(dev, "THINKPAD event: %u\n",
+			    (arg & 0xff));
+			acpi_UserNotify("THINKPAD", h, (arg & 0xff));
+			break;
+		default:
+			break;
+		}
+	}
+}
+
+static void
+acpi_thinkpad_refresh(void *arg)
+{
+	struct acpi_thinkpad_softc *sc = (struct acpi_thinkpad_softc *)arg;
+	char temp_cmd[] = "TMP0";
+	int data, i;
+	ACPI_INTEGER speed;
+
+	for (i = 0; i < 8; i++) {
+		temp_cmd[3] = '0' + i;
+		
+                /*
+                 * The TMPx methods seem to return +/- 128 or 0
+                 * when the respecting sensor is not available
+                 */
+		sc->sensors[i].flags &= ~SENSOR_FINVALID;
+                if (ACPI_FAILURE(acpi_GetInteger(sc->ec_handle, temp_cmd,
+                    &data)) || ABS(data) == 128 || data == 0) {
+			sc->sensors[i].flags |= SENSOR_FINVALID;
+                        data = 0;
+		}
+                else if (sc->thermal_updt_supported) {
+                        /* XXX: Temperature is reported in tenth of Kelvin */
+                        data = (data - 2732 + 5) / 10;
+		}
+		sc->sensors[i].value = data * 1000000 + 273150000;
+        }
+	
+	sc->sensors[8].flags &= ~SENSOR_FINVALID;
+	if (sc->fan_handle) {
+		if (ACPI_FAILURE(acpi_GetInteger(sc->fan_handle,
+		    NULL, &data)))
+			sc->sensors[8].flags |= SENSOR_FINVALID;
+                        data = -1;
+        }
+        else {
+                ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_FANSPEED, &speed, 2);
+                data = speed;
+        }
+
+	sc->sensors[8].value = data;
+}
diff --git a/sys/platform/pc32/conf/files b/sys/platform/pc32/conf/files
--- a/sys/platform/pc32/conf/files
+++ b/sys/platform/pc32/conf/files
@@ -72,6 +72,7 @@ dev/serial/dgb/dgm.c			optional	dgm
 ${OSACPI_MD_DIR}/acpi_machdep.c		optional        acpi
 ${OSACPI_MD_DIR}/acpi_wakeup.c		optional        acpi
 ${OSACPI_MD_DIR}/acpi_toshiba.c		optional        acpi_toshiba acpi
+${ACPICA_DIR}/acpi_thinkpad/acpi_thinkpad.c optional	acpi_thinkpad acpi
 acpi.h					optional	acpi		\
 	dependency	"$S/${ACPICA_DIR}/include/acpi.h"		\
 	compile-with	"cp $S/${ACPICA_DIR}/include/acpi.h ${.OBJDIR}/"	\



From hasso at estpak.ee  Thu Mar 20 03:49:13 2008
From: hasso at estpak.ee (Hasso Tepper)
Date: Thu, 20 Mar 2008 03:49:13 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Some questions regarding ACPI
In-Reply-To: <200803191322.46366.hasso@estpak.ee>
Message-ID: <200803201237.28823.hasso@estpak.ee>

Hasso Tepper wrote:
> There is also one fatal issue -laptop locks up hardly (no panic) while 
> unloading module. Any idea regarding this is welcome.

Nevermind, solved.


-- 
Hasso




From dillon at apollo.backplane.com  Fri Mar 21 19:24:01 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Fri, 21 Mar 2008 19:24:01 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: panic: assertion: hammer_btree_cmp(cursor->left_bound,	&cursor->node->ondisk->elms[0].leaf.base) <= 0 in btree_split_leaf
In-Reply-To: <200802232204.m1NM4cxd046264@apollo.backplane.com>
Message-ID: <200803220212.m2M2CiAY014435@apollo.backplane.com>

:While trying to find a procedure to reliably reproduce the panic
:I reported last time, I caught a different panic (uploaded at
: ~y0netan1/crash/9/ on my leaf account).  I wrote the following shell
:script (make sure to edit variables DISKS and MOUNTPT before using this
:script or it may trash your system):

    Ok, I believe I have fixed the left_bound assertion.  I also believe
    I have fixed the node ref count assertion on umount.

    There is currently one unfixed assertion related to the I/O
    path... sometimes the bp is being improperly disassociated from the
    related HAMMER structure.

    The full-filesystem case is still not being handled so don't test that :-)

					    -Matt





From c.turner at 199technologies.org  Sun Mar 23 09:48:29 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Sun, 23 Mar 2008 09:48:29 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
Message-ID: <47E6870C.4080709@199technologies.org>

I'm finally getting around to doing 1.12 upgrades, and have setup a 
separate machine to do my bulk package builds / upgrades etc,
so as not to disrupt my 'dev server' while things are being
built / tested

However, this seems kind of wasteful - the only purpose of this machine
is to build packages against a specific release..
And since building packages for a particular release generally requires 
only the userland, appropriate headers and correct 'uname' output - so:

it seems like if spoofing uname is configured inside a jail,
the next (or previous..) release can be installed into a jail and
used for building / testing packages without the overhead of a VM or 
maintaining a separate physical host

I did a quick scan of the tree to see what this would take, and, high 
level, it seems like only the following changes would need to be made:

- update struct jail to add a 'osrelease' string
  (implies bumping 'jail api' to 2?)
- update jail(8) to actually pass this information along
- update sys_uname to test ucred for jailed processes, and
  use the struct jail osrelease if appropriate
- similarly update sysctl kern.osrelease to support jail spoofing
  (if possible - didn't get this far in the research yet)
  could be less of a problem for builds, as I think most things use
 uname(1) ... but good to keep the environment consistent I suppose..
I'm still a bit confused as to how 'osrelease' is defined - everything
I'm finding is showing up as extern char[] .. perhaps this is something 
in the build I'm not familiar with?

also,

is the so-called 'stupid hackery' in sys_uname needed still?

Before I start any coding, does this:

- sound like something useful
- sound like the right approach
Thinking this could have wider useful implications e.g. for pkgbox
& so on -  for example setting up automated bulks w/various combinations 
of pkgsrc and releases, etc.

Cheers,

- Chris





From corecode at fs.ei.tum.de  Sun Mar 23 10:06:38 2008
From: corecode at fs.ei.tum.de (Simon 'corecode' Schubert)
Date: Sun, 23 Mar 2008 10:06:38 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <47E68C74.3080808@fs.ei.tum.de>

Chris Turner wrote:
I did a quick scan of the tree to see what this would take, and, high 
level, it seems like only the following changes would need to be made:
brave investigation.  but you could also simply set UNAME_r :)

sweatshorts % uname -r
1.13.0-DEVELOPMENT
sweatshorts % UNAME_r=1.12-RELEASE uname -r
1.12-RELEASE
I think that's good enough :D

cheers
  simon
--
Serve - BSD     +++  RENT this banner advert  +++    ASCII Ribbon   /"\
Work - Mac      +++  space for low ????????? NOW!1  +++      Campaign     \ /
Party Enjoy Relax   |   http://dragonflybsd.org      Against  HTML   \
Dude 2c 2 the max   !   http://golden-apple.biz       Mail + News   / \




From c.turner at 199technologies.org  Sun Mar 23 10:50:13 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Sun, 23 Mar 2008 10:50:13 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <47E69656.8080605@199technologies.org>

Simon 'corecode' Schubert wrote:
brave investigation.  but you could also simply set UNAME_r :)
Doh! Thanks for the tip!

they should change the phrase from RTFM to 'Carefully RTFM' :)

well.. scratch that change then. 1 less patch to write.

- Chris





From c.turner at 199technologies.org  Sun Mar 23 11:15:52 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Sun, 23 Mar 2008 11:15:52 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <47E69C7C.8010109@199technologies.org>

Chris Turner wrote:
Simon 'corecode' Schubert wrote:
brave investigation.  but you could also simply set UNAME_r :)

for the record - if anyone's interested - adding a line e.g.:

ALL_ENV+= UNAME_r=1.12-RELEASE

to mk.conf looks like it -might- work ..

(unless wants to chime in & verify)





From joerg at britannica.bec.de  Sun Mar 23 11:46:53 2008
From: joerg at britannica.bec.de (Joerg Sonnenberger)
Date: Sun, 23 Mar 2008 11:46:53 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <20080323181428.GA2099@britannica.bec.de>

On Sun, Mar 23, 2008 at 01:41:42PM -0400, Chris Turner wrote:
> they should change the phrase from RTFM to 'Carefully RTFM' :)

RTFMAI -- Read The Fine Manual Again, Idiot.

Joerg




From dillon at apollo.backplane.com  Sun Mar 23 20:05:36 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Sun, 23 Mar 2008 20:05:36 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
Message-ID: <200803240257.m2O2voNH038355@apollo.backplane.com>

    Here's an update on the HAMMER work!

    Current status:

    * Passes all standard filesystem stress tests and buildworld will
      run with a HAMMER /usr/obj.  Large histories are able to accumulate
      without effecting performance.

    * Pruning and reblocking code is in and partially tested, but now needs
      more stringent testing.

    * Full historical access appears to be working but needs testing.
      Note that a sync is still needed to flush dirty cached data prior
      to acquiring a timestamp for the 'snapshot' to be set in stone.
      (dirty data cached in-memory has no historical tags and must be
      committed to physical disk before it can be accessed historically).


    Current bugs:

    * There is one known bug in the standard operations code paths
      that results in an assertion in HAMMER's I/O subsystem.

    * There are probably bugs in the reblocking and/or pruning code.  More
      likely in the reblocking code.


    There are two big-ticket and several little-ticket items left.  HAMMER
    will officially go Alpha when the big-ticket items are done, and beta
    when we get a few of the little-ticket items done.

    Big ticket items left:

    * UNDO (crash recovery) code.  Currently it writes out undo records but
      they are not yet sequenced, buffer writes are not yet ordered, and
      there is no mount-time recovery code yet.

      This is the last item needed before HAMMER can go operational.

    * Filesystem full handling.  Currently no space is reserved for dirty
      cached data so it is possible to create/write files and for HAMMER
      to not have sufficient space left on-disk to flush it.


    Little ticket items:

    * Automated reblocking (currently these functions are manually
      initialized via the hammer utility).

    * I/O clustering and preliminary BMAP op when writing out large files.

    * CRC checking (CRC fields are reserved but not entirely generated yet
      and not yet checked at all).

    * Disaster Recovery filesystem scan.

    * Boot support.

    I expect all of these items and more to be handled by the 2.0 release
    in July.

			    Additional HAMMER capabilities
				(no timeline yet)

    * Adding, removing, and resizing a HAMMER filesystem's backing store.

			Ultimate Goals and working towards them
				(no timeline yet)

    Our ultimate goal with HAMMER and DragonFly in general is to support
    fully cache coherent replication in a multi-machine environment.  This
    involves several steps and networking protocols.

    * Replication of synchronization streams based on the UNDO log.  If
      resynchronizing to a target which is too old a B-Tree scan will
      likely be required.

    * Cache coherency protocols for machine-machine coherency for both
      replicated and remote-HAMMER access.

    I have no time frame for these items yet.  It will depend on how quickly
    HAMMER moves to Alpha and Beta status.  I will say, however, now
    that HAMMER's on-disk format has solidified, that I have a very precise
    understanding of the protocols that will be needed to accomplish fully
    cache coherent remote access for both replicated and non-replicated
    (remote mount style) access.

    And, as you know, fully coherent filesystem access across machines is
    going to be the basis for DragonFly's clustering across said machines.

    In summary, things are progressing very well.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From justin at shiningsilence.com  Sun Mar 23 20:10:13 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Sun, 23 Mar 2008 20:10:13 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <53758.192.168.0.252.1206327873.squirrel@www.shiningsilence.com>

On Sun, March 23, 2008 12:36 pm, Chris Turner wrote:

> it seems like if spoofing uname is configured inside a jail,
> the next (or previous..) release can be installed into a jail and
> used for building / testing packages without the overhead of a VM or
> maintaining a separate physical host

If you don't need a jail to spoof uname, as others posted, you can
installworld into a chroot and build everything you want there using
Joerg's spiffy pbulk.  That's what I'm doing on pkgbox now; I can hand you
my somewhat terse notes if you want.  It would be relatively easy to set
up the configuration you're talking about.





From sepherosa at gmail.com  Sun Mar 23 20:18:20 2008
From: sepherosa at gmail.com (Sepherosa Ziehau)
Date: Sun, 23 Mar 2008 20:18:20 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <ea7b9c170803232012n2f27f893tf1d756d7c9770419@mail.gmail.com>

On Mon, Mar 24, 2008 at 2:14 AM, Joerg Sonnenberger
<joerg at britannica.bec.de> wrote:
> On Sun, Mar 23, 2008 at 01:41:42PM -0400, Chris Turner wrote:
>  > they should change the phrase from RTFM to 'Carefully RTFM' :)
>
>  RTFMAI -- Read The Fine Manual Again, Idiot.

http://leaf.dragonflybsd.org/~sephe/rtfm.jpg

:D

>
>  Joerg
>



-- 
Live Free or Die




From justin at shiningsilence.com  Sun Mar 23 20:38:30 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Sun, 23 Mar 2008 20:38:30 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: GSoC 2008 - mentors signup
Message-ID: <53885.192.168.0.252.1206329503.squirrel@www.shiningsilence.com>

If you are planning to be a mentor for a Summer of Code project, please
sign up here for the mentors mailing list:

http://groups.google.com/group/google-summer-of-code-mentors-list

If you've already signed up, your subscription should be set up tomorrow.





From justin at shiningsilence.com  Sun Mar 23 21:12:01 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Sun, 23 Mar 2008 21:12:01 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: GSoC 2008 - mentors signup
In-Reply-To: <53885.192.168.0.252.1206329503.squirrel@www.shiningsilence.com>
Message-ID: <54025.192.168.0.252.1206331572.squirrel@www.shiningsilence.com>

Also!

If you are a potential mentor and you have not done so yet:

http://code.google.com/soc/mentor_step1.html

Get yourself registered as a mentor for the Summer of Code project.  Once
you are in there, check off DragonFly in the "My Profile" section.

You will need a Google Account if you don't have one:

http://www.google.com/accounts

This will add you to the list of mentors in the Google Summer of Code web
application, so you can review/be attached to projects.

A guide is available if you want more information:

http://groups.google.com/group/google-summer-of-code-announce/web/guide-to-the-gsoc-web-app-for-mentors-and-organization-administrators






From c.turner at 199technologies.org  Mon Mar 24 04:29:28 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Mon, 24 Mar 2008 04:29:28 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <47E78ECE.4070307@199technologies.org>

Justin C. Sherrill wrote:
If you don't need a jail to spoof uname, as others posted, you can
installworld into a chroot and build everything you want there using
Joerg's spiffy pbulk.  That's what I'm doing on pkgbox now; I can hand you
my somewhat terse notes if you want.  It would be relatively easy to set
up the configuration you're talking about.
cheers - I guess I thought incorrectly that something 'special' was 
needed to get the uname to change .. have been using the legacy bulks in 
chroots / jails (for 'same os' builds) as I haven't quite migrated to 
pbulk yet ..

thanks for the help offer - I'll ask if I run into trouble.




From dillon at apollo.backplane.com  Mon Mar 24 08:28:49 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Mon, 24 Mar 2008 08:28:49 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <200803241500.m2OF0CG8043760@apollo.backplane.com>


:http://leaf.dragonflybsd.org/~sephe/rtfm.jpg
:
::D

    Ho!

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From elekktretterr at exemail.com.au  Mon Mar 24 09:10:15 2008
From: elekktretterr at exemail.com.au (Petr Janda)
Date: Mon, 24 Mar 2008 09:10:15 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
In-Reply-To: <200803240257.m2O2voNH038355@apollo.backplane.com>
Message-ID: <200803250138.49775.elekktretterr@exemail.com.au>


>
>     And, as you know, fully coherent filesystem access across machines is
>     going to be the basis for DragonFly's clustering across said machines.
>
>     In summary, things are progressing very well.
>


Hi Matt,
That's good to know things are going so well. Got a question. If memory serves 
me right, initially there was also going to be a thing called ANVIL, I can't 
remember what it was supposed to do and whether its still in your design. 
Could you elaborate a little?

Thanks,
Petr




From dillon at apollo.backplane.com  Mon Mar 24 14:12:11 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Mon, 24 Mar 2008 14:12:11 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
In-Reply-To: <200803240257.m2O2voNH038355@apollo.backplane.com>
Message-ID: <200803242100.m2OL0nWV046868@apollo.backplane.com>


:Hi Matt,
:That's good to know things are going so well. Got a question. If memory serves 
:me right, initially there was also going to be a thing called ANVIL, I can't 
:remember what it was supposed to do and whether its still in your design. 
:Could you elaborate a little?
:
:Thanks,
:Petr

    It's not really in the HAMMER design any more, primarily because HAMMER's
    volume model seems to work fine as-is.  Ultimately something like ANVIL
    (a block storage manager) would prove beneficial to the project but it
    would be treated as a separate project.  HAMMER's redundancy model is
    going to be baesd around replication and clustering.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From tgen at netphreax.net  Mon Mar 24 18:31:37 2008
From: tgen at netphreax.net (Thomas E. Spanjaard)
Date: Mon, 24 Mar 2008 18:31:37 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
In-Reply-To: <200803240257.m2O2voNH038355@apollo.backplane.com>
Message-ID: <47E85337.2070407@netphreax.net>

Matthew Dillon wrote:
    * Full historical access appears to be working but needs testing.
      Note that a sync is still needed to flush dirty cached data prior
      to acquiring a timestamp for the 'snapshot' to be set in stone.
      (dirty data cached in-memory has no historical tags and must be
      committed to physical disk before it can be accessed historically).
Wouldn't making timestamp queries (at least from userland) enforce a 
sync on the volume in question be useful here?
--
        Thomas E. Spanjaard
        tgen at netphreax.net
Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00005.pgp
Type: application/octet-stream
Size: 186 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080324/3077333f/attachment-0001.obj>

From dillon at apollo.backplane.com  Mon Mar 24 20:10:12 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Mon, 24 Mar 2008 20:10:12 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
In-Reply-To: <200803240257.m2O2voNH038355@apollo.backplane.com>
Message-ID: <200803250302.m2P32qLP050160@apollo.backplane.com>


:Wouldn't making timestamp queries (at least from userland) enforce a 
:sync on the volume in question be useful here?
:-- 
:         Thomas E. Spanjaard
:         tgen at netphreax.net

    Making the 'hammer now' command do a sync() is a good idea.  I will
    make that change right now so it doesn't get lost.

    Here's a general overview of the issues involved with having historical
    access to the filesystem:

				----------------

    Recording the timestamps in the in-memory cache, for a finer-grained
    snapshot capability, is doable but has its own issues.  Here's an
    illustration:

    open()  create file
    write() append 4K	(file size now 4K)
    write() append 4K	(file size now 8K)
    write() append 4K	(file size now 12K)
    write() append 4K	(file size now 16K)

    Now NONE of this has gone to disk yet, it's entirely in the in-memory
    cache.  The inode is in the in-memory cache.  The data is stored in
    the buffer cache.  Even the directory entry for the file that we
    just created is still in the in-memory cache (HAMMER caches the raw
    records it intends to commit later on).

    If I wanted to be able to acquire a timestamp between each write and
    'see' a snapshot of the file as of any point in the above sequence,
    then every write would also have to allocate a copy of the inode
    (because it changes size on each write).

    The data has the same problem though with a slightly different example.
    Lets say each write() was a seek-write, overwriting the previous data.
    Now with every write() I would have to allocate a copy of the data
    being overwritten.  This is complicated by the fact that the buffer
    cache has no clue about 'historical' accesses, so I would not be able
    to use the buffer cache to cache the data.

    There's also another problem and that is with the efficiency of the
    topology on-disk.  Even if I maintained all the copies of the inode
    and all the copies of the data in-memory, I would still have to sync
    all those copies to disk in order for things to remain historically
    coherent (whether it be in-cache or on-disk).  This would result in
    hundreds or even thousands of copies of the inode on-disk, not to
    mention potentially many copies of the data.

    I just don't want to do that right now, at least not as a default.  A
    lot of performance would be lost.  Hence a sync() is needed if
    you want to create a demark which you can accurately snapshot.

				-------------

    Here's a quick synopsis of how the cache would operate in a clustered
    filesystem:

    In order to properly integrate with in-memory caches, a wider cache
    coherency infrastructure is needed between machines such that
    modifications made on one machine proactively invalidate those
    protions of the cache(s) on other machines.  At the same time, any
    'dirty' cache data, for example when a file is created or written to,
    must lock the cache space in question on all other machines.
    The cache space in this case is not just the file data, but also the
    related namespaces (for creations, deletions, and renames).  Attempts
    to access locked spaces from other machines in the cluster would have
    to force a flush to the filesystem backing store and lower the cache
    states for the effected information on the original machine from dirty
    to shared-read-only.

    It will be easiest to integrate the cache coherency information into
    the buffer cache and namecache themselves.  Once a machine has dirtied
    an in-memory cache element... for example part of the namespace when
    creating a file or chunks of data written within a file, that machine
    must have a free hand to make further modifications to the cache spaces
    involved without further interaction with other machines.

				-------------

    Now, if you think of those two major elements you can see that they
    actually fit together quite well.  If I were to attempt to maintain
    transactional coherency on a per-system-call basis then the cache
    granularity between machines would have to be much, much smaller then
    our current in-memory caching elements provide.  That would become
    a really nasty coding problem.  So I don't even want to begin to
    complate transactional coherency at a finer-grain then sync() or
    fsync() until long after we actually have clustering working.

						-Matt





From elekktretterr at exemail.com.au  Mon Mar 24 21:56:58 2008
From: elekktretterr at exemail.com.au (Petr Janda)
Date: Mon, 24 Mar 2008 21:56:58 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
In-Reply-To: <200803240257.m2O2voNH038355@apollo.backplane.com>
Message-ID: <200803251516.16407.elekktretterr@exemail.com.au>

So is it needed to run hammer now in order to "create" a snapshot? What would 
I do in situation like this: got a hammer filesystem and couple of the files 
change on day to day basis. Then a week later I needed to access one of the 
files, in exactly the state they were 7 days ago.

Cheers,
Petr




From dillon at apollo.backplane.com  Mon Mar 24 22:34:15 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Mon, 24 Mar 2008 22:34:15 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
In-Reply-To: <200803240257.m2O2voNH038355@apollo.backplane.com>
Message-ID: <200803250526.m2P5QZ5X051081@apollo.backplane.com>


:So is it needed to run hammer now in order to "create" a snapshot? What would 
:I do in situation like this: got a hammer filesystem and couple of the files 
:change on day to day basis. Then a week later I needed to access one of the 
:files, in exactly the state they were 7 days ago.
:
:Cheers,
:Petr

    No, you do not have to run 'hammer now' to create a snapshot.  The
    kernel syncs all filesystems every 30 seconds, so if you do nothing
    at all you get a snapshot granularity of 30 seconds.

    Where you would use 'hammer now' is if you wanted the most current
    snapshot possible for the purpose of, say, backing up your filesystem
    to another machine.  You might do something like this:

	set timestamp = `hammer now`
	cpdup /mountpoint/@@$timestamp targethost:/somepath

    But if you didn't care about that you could just go back far enough
    that you get a stable historical view... e.g. go back 1 minute and you
    would have a stable view into your filesystem.

	set timestamp = `hammer stamp 60s`		<------ doesn't sync
	cpdup /mountpoint/@@$timestamp targethost:/somepath


    Ultimately the idea of managing filesystems this way is to still do
    regular backups from your production machine to your backup machine
    (ultimately by way of replication), with both running HAMMER, but only
    retain a limited amount of history on the production box.  You might
    desire to retain only one week's worth of history on the production box,
    retain one month's history on your local backup box, and retain a very
    granular one year's worth of history on your remote backup box.

    Come to think of it, I should add some more directives to the
    'hammer prune' command to make that easier to specify.

    Until I implement a live replication 'feed' the minimum granularity on
    the backup box will be how often you do your backups (e.g. once a day),
    and you can prune it into more granular forms from that starting point.
    Once we have a live replication feed the backup box will have the same
    30-second granularity that the production machine has.

    A major bullet point for this style of management is that the retention
    policy on the various boxes can be different even though they are
    all slaved off the same production filesystem.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From justin at shiningsilence.com  Tue Mar 25 05:58:49 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Tue, 25 Mar 2008 05:58:49 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: SoC - student signups
Message-ID: <58180.65.106.147.226.1206449676.squirrel@www.shiningsilence.com>

Here's a quick link roundup:

Are you a student?  Put in your application for a Google Summer of Code here:

http://code.google.com/soc/2008/student_signup.html

Student guide:
http://groups.google.com/group/google-summer-of-code-announce/web/guide-to-the-gsoc-web-app-for-student-applicants

Are you a mentor?  (That means hasso, hsu, sephe, matthias, TGEN, and
corecode right now)

Student proposals will show up on the mentor page, linked below.  You will
get to rate them, and take the one(s) that you want to mentor.

Mentor page:
http://code.google.com/soc/2008/mentor_home.html
Mentor guide:
http://groups.google.com/group/google-summer-of-code-announce/web/guide-to-the-gsoc-web-app-for-mentors-and-organization-administrators

If you are a mentor and are communicating with potential students, send
them the URLs above for student signup and the student guide; work with
them if they ask for advice on what to say in the application.  They can
resubmit up to 20 times if they want to correct it.

Deadline is March 31st.






From noah.yan at gmail.com  Thu Mar 27 20:17:48 2008
From: noah.yan at gmail.com (Yonghong Yan)
Date: Thu, 27 Mar 2008 20:17:48 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: About DFBSD.64
In-Reply-To: <47EB0B5B.5020802@gmail.com>
Message-ID: <59521b110803272015y1cc8cc39uc93f154ed36e0505@mail.gmail.com>

thanks for your interest.

I owe to everybody for any update or work in the past four months. so
many things happen in my work and my family (they are all good:) and
keep me extremely busy. But i am not leaving and will be back on this
soon.

the latest sources are in http://repo.or.cz/w/dragonfly/port-amd64.git
, I did have a compiled kernel long time before, but I have to break
it to work on the pmap. you can pick up from there. TGEN will help you
a lot, also keep me posted too, if you like.

Noah

On Wed, Mar 26, 2008 at 9:50 PM, Sdavtaker <sdavtaker at gmail.com> wrote:
> Hello,
>  Im applying to GSoC to work in the x64 version of DFBSD with TGEN, i
>  found some work already done in the repository and some mails in the
>  archive from you.
>  I was wondering if you already had a working compiled kernel in AMD64
>  machine and what was not working yet to continue that work.
>  Thanks for any info.
>  Sdav
>




From dillon at apollo.backplane.com  Sat Mar 29 13:27:43 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Sat, 29 Mar 2008 13:27:43 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 29-Mar-2008
Message-ID: <200803292022.m2TKMLGe004942@apollo.backplane.com>

    Good progress continues to be made.  HAMMER survived acting as my
    LAN backup machine (in full historical mode) for almost a week before
    it hit an assertion.  I've fixed that issue and believe that the core
    filesystem implementation code is now 'very stable'.

    Note that the recent commit will result in many more 'hammer_lock_ex:'
    messages on the console then you may have previously observed.  This is
    due to the way object id's are allocated in the face of parallel 
    modifications to the filesystem, resulting in too much locality of
    reference in the B-Tree.  I do intend to improve it.

    I am still working on the two major items needed before HAMMER can be
    declared operational, those being the filesystem full handling and the
    undo/recovery-on-mount code.  These are the last 'hard' bits left in
    the design.

    With exception to filling up the filesystem, which *will* create a mess,
    and noting that no crash recovery code exists yet (so you have to newfs
    it if you crash), I'd appreciate it if interested parties could test
    the other functions of the filesystem, in particular the pruning and
    reblocking functions (man hammer), and the historical access functions.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From dillon at apollo.backplane.com  Sun Mar 30 15:11:03 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Sun, 30 Mar 2008 15:11:03 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Need ideas on how to solve an st_ino/st_dev test issue for HAMMER.
Message-ID: <200803302207.m2UM7BCp016402@apollo.backplane.com>

    Here's the problem, given historical access softlinks as shown below:

test30# ls -lda cra*
drwxr-xr-x  1 root  wheel  Mar 29 13:04 crater
lrwxr-xr-x  1 root  wheel  Mar 29 18:57 crater.20080329 -> crater@@0x47eef383
lrwxr-xr-x  1 root  wheel  Mar 30 01:24 crater.20080330 -> crater@@0x47ef4e29
-rw-r--r--  2 root  wheel  Mar 30 01:24 crater.log

    The problem is that if I do this:

    diff -r crater.20080329/var/log crater.20080330/var/log

    Diff just returns without actually diffing anything.  The reason is
    because diff checks st_ino and st_dev and believes the directories/files
    to be identical because they match.

    I considered munging the inode number for historical accesses, but
    that would seriously break NFS exports which try to access historical
    files and directories.  Right now NFS *is* able to distinguish between
    the two because NFS handles are 128-bit-wide entities, so I can encode
    the as-of transaction id as part of the filehandle.  But userland
    programs only have access to a 64-bit-wide inode so userland still
    believes the files to be identical.

    st_dev is only 32 bits, carefully munging it is an option if we
    could figure out a way to do it, but I'd rather not.

    I am considering using st_gen but then we'd have to patch third
    party software to test st_gen along with everything else.  This may
    be the only workable solution, though, and only a few programs would
    need to be patched.  st_gen is only 32 bits but it would solve the
    problem as we would be able to use all 32 bits.

    If anyone has any bright ideas, including 'leave it alone', I'm all
    ears.

						-Matt





From justin at shiningsilence.com  Mon Mar 31 10:40:42 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Mon, 31 Mar 2008 10:40:42 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: SoC student applications due by 5PM PDT tomorrow
In-Reply-To: <1942.192.168.0.242.1206930479.squirrel@www.shiningsilence.com>
Message-ID: <11892.67.108.184.175.1206984967.squirrel@www.shiningsilence.com>

On Sun, March 30, 2008 10:27 pm, Justin C. Sherrill wrote:
> SoC students:
>
> If you have an application to submit for DragonFly/Summer of Code, please
> do so by 17:00 Pacific time on the 31st - that's tomorrow, at least for
> me.

The deadline for student proposals has been extended to April 7th; all
other dates move forward one week to acommodate.

This is a good time to update existing applications or submit new ones. 
Talk to your (potential) mentors if you are curious.






From nthery at gmail.com  Mon Mar 31 11:29:49 2008
From: nthery at gmail.com (Nicolas Thery)
Date: Mon, 31 Mar 2008 11:29:49 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
Message-ID: <64fc43b0803311126na7d0b27obaa9d35bac6d32ee@mail.gmail.com>

Hello,

Now that the release is over, I'll try to get rid of zones and migrate
allocations to objcache.

Here is a 1st patch that migrate struct proc.  I'll commit it in a
couple of days if nobody objects.

I'm also implementing a way to monitor objcache statistics.  So far,
I've hacked sth similar to
sysctl vm.zone: stats are returned in one giant string, one line per
cache.  That's simple but ugly and hard to read because there are
quite a few stats per cache.

So I'm thinking about implementing a small tool, ocstat, that extracts
stats from sysctl the way ps(1) does (thru libkvm iirc) and formats it
in various ways.  What do you think?

Cheers,
Nicolas

Index: src2/sys/kern/kern_exit.c
===================================================================
--- src2.orig/sys/kern/kern_exit.c	2008-03-31 08:05:59.139796000 +0200
+++ src2/sys/kern/kern_exit.c	2008-03-31 10:31:39.000000000 +0200
@@ -834,7 +834,7 @@ loop:
 			}

 			vm_waitproc(p);
-			zfree(proc_zone, p);
+			objcache_put(proc_cache, p);
 			nprocs--;
 			return (0);
 		}
Index: src2/sys/kern/kern_proc.c
===================================================================
--- src2.orig/sys/kern/kern_proc.c	2008-03-31 08:05:59.139918000 +0200
+++ src2/sys/kern/kern_proc.c	2008-03-31 10:31:39.000000000 +0200
@@ -84,7 +84,7 @@ u_long pgrphash;
 struct proclist allproc;
 struct proclist zombproc;
 struct spinlock allproc_spin;
-vm_zone_t proc_zone;
+struct objcache* proc_cache;
 vm_zone_t lwp_zone;
 vm_zone_t thread_zone;

@@ -131,7 +131,7 @@ procinit(void)
 	spin_init(&allproc_spin);
 	pidhashtbl = hashinit(maxproc / 4, M_PROC, &pidhash);
 	pgrphashtbl = hashinit(maxproc / 4, M_PROC, &pgrphash);
-	proc_zone = zinit("PROC", sizeof (struct proc), 0, 0, 5);
+	proc_cache = objcache_create_simple(M_PROC, sizeof(struct proc));
 	lwp_zone = zinit("LWP", sizeof (struct lwp), 0, 0, 5);
 	thread_zone = zinit("THREAD", sizeof (struct thread), 0, 0, 5);
 	uihashinit();
Index: src2/sys/sys/proc.h
===================================================================
--- src2.orig/sys/sys/proc.h	2008-03-31 08:05:59.140325000 +0200
+++ src2/sys/sys/proc.h	2008-03-31 10:31:39.000000000 +0200
@@ -473,7 +473,7 @@ struct proc *zpfind (pid_t);	/* Find zom
 struct vm_zone;
 struct globaldata;
 struct lwp_params;
-extern struct vm_zone *proc_zone;
+extern struct objcache *proc_cache;
 extern struct vm_zone *lwp_zone;

 int	enterpgrp (struct proc *p, pid_t pgid, int mksess);
Index: src2/sys/kern/kern_fork.c
===================================================================
--- src2.orig/sys/kern/kern_fork.c	2008-03-31 08:05:59.140042000 +0200
+++ src2/sys/kern/kern_fork.c	2008-03-31 10:31:39.000000000 +0200
@@ -332,7 +332,7 @@ fork1(struct lwp *lp1, int flags, struct
 	}

 	/* Allocate new proc. */
-	p2 = zalloc(proc_zone);
+	p2 = objcache_get(proc_cache, M_WAITOK);
 	bzero(p2, sizeof(*p2));

 	/*




From hsu at dragonflybsd.org  Mon Mar 31 11:44:34 2008
From: hsu at dragonflybsd.org (Jeffrey Hsu)
Date: Mon, 31 Mar 2008 11:44:34 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <64fc43b0803311126na7d0b27obaa9d35bac6d32ee@mail.gmail.com>
Message-ID: <200803311841.m2VIfQAI007579@nlpi001.prodigy.net>

The object cache is not a general-purpose memory allocator.  It's a cache of
pre-initialized objects.  Are the significant portions of the proc structure
that can be restored to initialized state on object puts?  If not, it's best
to just use a general-purpose memory allocator.

								Jeffrey




From corecode at fs.ei.tum.de  Mon Mar 31 12:07:02 2008
From: corecode at fs.ei.tum.de (Simon 'corecode' Schubert)
Date: Mon, 31 Mar 2008 12:07:02 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <200803311841.m2VIfQAI007579@nlpi001.prodigy.net>
Message-ID: <47F1357B.1070302@fs.ei.tum.de>

Jeffrey Hsu wrote:
> The object cache is not a general-purpose memory allocator.  It's a cache of
> pre-initialized objects.  Are the significant portions of the proc structure
> that can be restored to initialized state on object puts?  If not, it's best
> to just use a general-purpose memory allocator.

Why?  What's the loss if we use the object cache to allocate struct procs?

cheers
  simon

Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00006.pgp
Type: application/octet-stream
Size: 252 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080331/a4a24314/attachment-0001.obj>

From nthery at gmail.com  Mon Mar 31 12:17:03 2008
From: nthery at gmail.com (Nicolas Thery)
Date: Mon, 31 Mar 2008 12:17:03 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <nthery@gmail.com>
Message-ID: <64fc43b0803311214u7da6bbb8xaf971de1a80e7258@mail.gmail.com>

2008/3/31, Jeffrey Hsu <hsu at dragonflybsd.org>:
> The object cache is not a general-purpose memory allocator.  It's a cache of
>  pre-initialized objects.  Are the significant portions of the proc structure
>  that can be restored to initialized state on object puts?  If not, it's best
>  to just use a general-purpose memory allocator.

Well, I haven't checked this yet.  I planned to do this in a second
step after getting rid of zones.

I thought that even without  the pre-initialization part, objcache has
the advantage
of pre-allocating set of objects (as zones) and is additionally
mp-safe (contrary to zones and, granted, as malloc()).   The latter
may be interesting as we talk of improving MP support.

Cheers,
Nicolas




From dillon at apollo.backplane.com  Mon Mar 31 12:23:40 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Mon, 31 Mar 2008 12:23:40 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <200803311841.m2VIfQAI007579@nlpi001.prodigy.net>
Message-ID: <200803311921.m2VJLITB027669@apollo.backplane.com>

    I both agree and disagree with Jeff.  I think the only *disadvantage*
    to using objcache for struct proc is that objcache must cache a minimum
    number of free structures to be efficient so the overall kernel memory
    use would be a bit greater verses uses kmalloc().  But I agree with Jeff
    in that objcache's biggest advantage is that you can keep structural state
    intact and struct proc might not be a good candidate (yet).

    What I suggest is that you convert struct proc from zone to kmalloc
    first, and then look into a possible objcache adaptation.  kmalloc
    is not slow.. it's a very fast allocator.  Objcache is probably a tad
    faster but not by much.  Where objcache really wins is in not having
    to completey reinitialize the allocated structures.

    Over the years I've removed (I think) all the dependancies on requiring
    the proc structure to be in stable memory so I believe it can be moved to
    kmalloc/objcache now without any major pain.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From corecode at fs.ei.tum.de  Mon Mar 31 12:37:40 2008
From: corecode at fs.ei.tum.de (Simon 'corecode' Schubert)
Date: Mon, 31 Mar 2008 12:37:40 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: SoC student applications due by 5PM PDT tomorrow
In-Reply-To: <1942.192.168.0.242.1206930479.squirrel@www.shiningsilence.com>
Message-ID: <47F13CDA.6010703@fs.ei.tum.de>

Justin C. Sherrill wrote:
> On Sun, March 30, 2008 10:27 pm, Justin C. Sherrill wrote:
>> SoC students:
>>
>> If you have an application to submit for DragonFly/Summer of Code, please
>> do so by 17:00 Pacific time on the 31st - that's tomorrow, at least for
>> me.
> The deadline for student proposals has been extended to April 7th; all
> other dates move forward one week to acommodate.

This is very good.

Some more ideas for eager students (we want to keep the ratio, right?):

Enhance the FreeBSD/DragonFly sound infrastructure to support surround
sound/multichannel output.

Update sound drivers to support S/PDIF output.

Make the sound infrastructure OSSv4 compatible (there was a SoC at
FreeBSD last year or so)


of course only if it doesn't exist already :)

cheers
  simon


Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00007.pgp
Type: application/octet-stream
Size: 252 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080331/6da61cff/attachment-0001.obj>

From corecode at fs.ei.tum.de  Mon Mar 31 12:41:30 2008
From: corecode at fs.ei.tum.de (Simon 'corecode' Schubert)
Date: Mon, 31 Mar 2008 12:41:30 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <200803311841.m2VIfQAI007579@nlpi001.prodigy.net>
Message-ID: <47F13DE4.10205@fs.ei.tum.de>

Matthew Dillon wrote:
>     What I suggest is that you convert struct proc from zone to kmalloc
>     first, and then look into a possible objcache adaptation.  kmalloc
>     is not slow.. it's a very fast allocator.  Objcache is probably a tad
>     faster but not by much.  Where objcache really wins is in not having
>     to completey reinitialize the allocated structures.

Could we please not move to kmalloc, but instead try to move all fast
path allocations to objcache?  I don't like the idea of allocating
everything with kmalloc.  Caching struct procs is not a bad thing itself.

cheers
  simon


Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00008.pgp
Type: application/octet-stream
Size: 252 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080331/ac328c08/attachment-0001.obj>

From hsu at FreeBSD.org  Mon Mar 31 12:59:05 2008
From: hsu at FreeBSD.org (Jeffrey Hsu)
Date: Mon, 31 Mar 2008 12:59:05 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <47F1357B.1070302@fs.ei.tum.de>
Message-ID: <200803311920.m2VJK5Ln018015@nlpi015.prodigy.net>

The object cache sits on top of a general-purpose memory allocator such
as kmalloc or zalloc and provides pre-initialized object caching functionality.
If you're not going to use the object caching functionality, you can just
call the underlying memory allocator directly.

							Jeffrey




From dillon at apollo.backplane.com  Mon Mar 31 16:17:19 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Mon, 31 Mar 2008 16:17:19 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <200803311841.m2VIfQAI007579@nlpi001.prodigy.net>
Message-ID: <200803312311.m2VNBumd029866@apollo.backplane.com>

:Could we please not move to kmalloc, but instead try to move all fast
:path allocations to objcache?  I don't like the idea of allocating
:everything with kmalloc.  Caching struct procs is not a bad thing itself.=
:
:
:cheers
:  simon

    I will state for the record that I'm fine with either objcache or
    kmalloc.  I agree with Jeff that using objcache for struct proc
    probably isn't necessary but I also agree that it would not hurt either,
    and if the intent is to optimize the initialization of the proc
    structure in the future then moving to objcache now would save us
    from having to do it later.

    So whichever method Nicolas wants to use is fine with me.

						-Matt




From hsu at dragonflybsd.org  Mon Mar 31 19:22:47 2008
From: hsu at dragonflybsd.org (Jeffrey Hsu)
Date: Mon, 31 Mar 2008 19:22:47 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <64fc43b0803311214u7da6bbb8xaf971de1a80e7258@mail.gmail.com>
Message-ID: <200804010218.m312IVUq003624@nlpi043.prodigy.net>

  >> Are there significant portions of the proc structure
  >> that can be restored to initialized state on object puts?

  > I planned to do this in a second step after getting rid of zones.

I'll all in favor of making more use of caching pre-initialized objects, so
if this is your objective, then please go ahead.  It's just that I'd convert
over to the object cache in one step.

  > I thought that even without  the pre-initialization part, objcache has
  > the advantage of pre-allocating set of objects (as zones) and is additionally
  > mp-safe (contrary to zones and, granted, as malloc()).

Well, the zone allocator is MP-safe.  It's not hard to lock up the places that
manipulate the linked-list of free items. Look for uses of the zlock field.

								Jeffrey




From tgen at netphreax.net  Sat Mar  1 12:57:53 2008
From: tgen at netphreax.net (Thomas E. Spanjaard)
Date: Sat, 1 Mar 2008 12:57:53 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: [Fwd: Project Support Open Source: $50 donation to support you      project]
In-Reply-To: <2468.192.168.0.242.1204346451.squirrel@www.shiningsilence.com>
Message-ID: <47C9C1B7.50203@netphreax.net>

Justin C. Sherrill wrote:
The "donation" happens after you place an "acknowledgement" on an open
source project's web page.  I'm putting those words in scare quotes
because I think it's a "payment" for an "advertisement".  The supplied
link has nothing to do with DragonFly, to say the least.

<a href="http://www.2insure4less.com /" title="We support FOSS software
projects.">Online Insurance Quotes</a>
To think our souls are only worth $50...
--
        Thomas E. Spanjaard
        tgen at netphreax.net
Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00000.pgp
Type: application/octet-stream
Size: 186 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080301/0d61e240/attachment-0002.obj>

From c.turner at 199technologies.org  Sat Mar  1 17:52:31 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Sat, 1 Mar 2008 17:52:31 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Misc. ACPI / suspend
Message-ID: <47CA073B.6020106@199technologies.org>

Wondering if anyone more well versed in the ACPI implementation could
comment on the applicability of:
http://lkml.org/lkml/2007/4/6/69

w/r/t the current state of the art in Dfly

(or BSD's in general)

Cheers!

- Chris




From elekktretterr at exemail.com.au  Sun Mar  2 00:41:25 2008
From: elekktretterr at exemail.com.au (Petr Janda)
Date: Sun, 2 Mar 2008 00:41:25 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: CARP question
Message-ID: <200803021934.21669.elekktretterr@exemail.com.au>

So Ive setup CARP on 2 DF-based mailservers. Installation went fine. Box 1 has 
adskew of 0 therefore it is the MASTER. Box 2 has adskew of 254, therefore is 
BACKUP.  If i down the carp0 interface on Box 1, then Box 2 carp interface 
gets promoted to MASTER. Then I up the carp interface on Box 1, logically Box 
2 should become BACKUP again as Box 1 becomes MASTER due to adskew set to 0.

However it doesnt happen. When carp0 interface on Box 1 is upped it becomes a 
BACKUP, not a MASTER even though according to adskew it should be MASTER.

What is the desired behaviour?

Cheers
Petr




From qhwt+dfly at les.ath.cx  Sun Mar  2 02:50:14 2008
From: qhwt+dfly at les.ath.cx (YONETANI Tomokazu)
Date: Sun, 2 Mar 2008 02:50:14 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: panic: assertion: hammer_btree_cmp(cursor->left_bound,	&cursor->node->ondisk->elms[0].leaf.base) <= 0 in btree_split_leaf
In-Reply-To: <200802232204.m1NM4cxd046264@apollo.backplane.com>
Message-ID: <20080302104554.GA22813@les.ath.cx>

Hi.
While trying to find a procedure to reliably reproduce the panic
I reported last time, I caught a different panic (uploaded at
 ~y0netan1/crash/9/ on my leaf account).  I wrote the following shell
script (make sure to edit variables DISKS and MOUNTPT before using this
script or it may trash your system):
  #!/bin/sh -ex
  DISKS="/dev/ad0s1f"
  MOUNTPT=/mnt/HAMMER

  cd /
  newfs_hammer -L TEST $DISKS
  for i in `seq 1 100`; do
	  mount_hammer $DISKS $MOUNTPT
	  /bin/rm -rf $MOUNTPT/??
	  (set +x; for x in `seq 1 10000`; do echo -n > $MOUNTPT/$x; done)
	  umount $MOUNTPT
  done

And the panic is triggered by rm command.
I'll try to see if it's possible to reproduce the last one without
unmounting then mounting the HAMMER fs.

Cheers.




From dillon at apollo.backplane.com  Sun Mar  2 13:25:33 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Sun, 2 Mar 2008 13:25:33 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: panic: assertion: hammer_btree_cmp(cursor->left_bound,	&cursor->node->ondisk->elms[0].leaf.base) <= 0 in btree_split_leaf
In-Reply-To: <200802232204.m1NM4cxd046264@apollo.backplane.com>
Message-ID: <200803022119.m22LJRCY037076@apollo.backplane.com>


:Hi.
:While trying to find a procedure to reliably reproduce the panic
:I reported last time, I caught a different panic (uploaded at
: ~y0netan1/crash/9/ on my leaf account).  I wrote the following shell
:script (make sure to edit variables DISKS and MOUNTPT before using this
:script or it may trash your system):

(from the core)

panic: assertion: node->lock.refs == 0 && node->ondisk == NULL in hammer_flush_buffer_nodes

    Yah, I've seen this failure.  Add a sync or two before the umount and
    tell me if it still occurs.  It's either a node reference leak somewhere
    or it is a race between bufdaemon and umount.  The assertions are really
    strict there precisely to catch those sorts of cases.

    Also note that the code to deal with a full HAMMMER filesystem has not
    been written yet (The failure you are reporting is unrelated to a full
    HAMMER filesystem, though, just mentioning it).

						-Matt





From dillon at apollo.backplane.com  Sun Mar  2 13:29:03 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Sun, 2 Mar 2008 13:29:03 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Misc. ACPI / suspend
In-Reply-To: <47CA073B.6020106@199technologies.org>
Message-ID: <200803022126.m22LQbfI037188@apollo.backplane.com>


:Wondering if anyone more well versed in the ACPI implementation could
:comment on the applicability of:
:
:http://lkml.org/lkml/2007/4/6/69
:
:w/r/t the current state of the art in Dfly
:
:(or BSD's in general)
:
:Cheers!
:
:- Chris

    I really have no idea re: this.  Suspension in general is not well
    supported by any of the BSDs.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From dillon at apollo.backplane.com  Sun Mar  2 13:34:05 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Sun, 2 Mar 2008 13:34:05 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: [Fwd: Project Support Open Source: $50 donation to support you      project]
In-Reply-To: <2468.192.168.0.242.1204346451.squirrel@www.shiningsilence.com>
Message-ID: <200803022131.m22LVOe9037250@apollo.backplane.com>

:..
:source project's web page.  I'm putting those words in scare quotes
:because I think it's a "payment" for an "advertisement".  The supplied
:link has nothing to do with DragonFly, to say the least.
:
:I don't think this is a good idea, obviously, and replied to that effect. 
:However, I wanted to put this on a DragonFly list, in part to show this
:strange thing, and in part because I'm not comfortable making
:administrative decisions on behalf of the Project without being open as
:possible about it.

    It doesn't really cry out to me either.

						-Matt





From wbh at conducive.org  Sun Mar  2 20:36:32 2008
From: wbh at conducive.org (Bill Hacker)
Date: Mon, 03 Mar 2008 04:36:32 +0000
Subject: Misc. ACPI / suspend
In-Reply-To: <47CA073B.6020106@199technologies.org>
Message-ID: <47cb8050$0$855$415eb37d@crater_reader.dragonflybsd.org>

Matthew Dillon wrote:
:Wondering if anyone more well versed in the ACPI implementation could
:comment on the applicability of:
:
:http://lkml.org/lkml/2007/4/6/69
:
:w/r/t the current state of the art in Dfly
:
:(or BSD's in general)
:
:Cheers!
:
:- Chris
    I really have no idea re: this.  Suspension in general is not well
    supported by any of the BSDs.
					-Matt
					Matthew Dillon 
					<dillon at backplane.com>


. . and there seems to be a bit of a 'Catch 22' there in any case.

If the BIOS can alter 'stuff' out of site of the OS it is parking, what 
does the existence of such a 'feature' do to a(ny) security model?

Seems to at least beg creating the option of setting a flag to 
specifically *prevent* suspend-to-disk/hibernation (and/or force a 
reboot on wake-up).

Just because one is paranoid....  etc

Bill





From matthias at dragonflybsd.org  Tue Mar  4 02:30:52 2008
From: matthias at dragonflybsd.org (Matthias Schmidt)
Date: Tue, 4 Mar 2008 02:30:52 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
Message-ID: <20080304102335.GI9833@staatsfeind.org>

Hi,

Google just announced its Summer of Code for 2008:

	http://code.google.com/soc/2008/

I think this would be a great opportunity for DragonFly to participate
as a mentoring organisation.  We could attract new developers and could
get code/work done.  Looking at the SoC results of the other BSDs most
of their projects were a success.  Of course, not all, but a reasonable
percentage.  See [1] and [2].

It is some extra work for us, but IMO the benefits outweigh the extra
work.  And yes, I would volunteer as a mentor.  What do others
(developers) think?  Any more volunteers? :)

Some project ideas that come into my mind.  More ideas are listed in the
wiki:  http://wiki.dragonflybsd.org/index.cgi/ProjectsPage

 * Fix all remaining bugs in dma(8) and implement all missing features
 * Add a driver for newer Intel Wireless cards (I think sephe@ would
   love that :)
 * Bring our ACPI stuff in shape.  Maybe suspend2disk ...

 * [Add your own thoughts here]

Cheers,

	Matthias

PS: I don't want to create a bikeshed here whether you like the SoC or
not :)

[1] http://code.google.com/soc/2007/freebsd/about.html
[2] http://code.google.com/soc/2007/netbsd/about.html




From corecode at fs.ei.tum.de  Tue Mar  4 04:46:14 2008
From: corecode at fs.ei.tum.de (Simon 'corecode' Schubert)
Date: Tue, 4 Mar 2008 04:46:14 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47CD4386.1000704@fs.ei.tum.de>

Matthias Schmidt wrote:
>  * [Add your own thoughts here]

MP lock removal for network stack

and for the system  (first profile, find hot spots, fix hot spots, repeat)

cheers
  simon




From c.turner at 199technologies.org  Tue Mar  4 06:02:20 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Tue, 4 Mar 2008 06:02:20 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47CD551E.1040604@199technologies.org>

Matthias Schmidt wrote:
Some project ideas that come into my mind.  More ideas are listed in the
wiki:  http://wiki.dragonflybsd.org/index.cgi/ProjectsPage
+1 acpi
+1 interrupt routing
+1 SMP / giant removal
+1 pf synchup with openbsd
though there are several others on the page that are good..

need to dig up my wiki login and place appropriately..

also: thinking the ZFS port should be removed from the page - makes 
sense to everyone else? (e.g. fragments effort w/r/t hammer)





From tgen at netphreax.net  Tue Mar  4 06:54:31 2008
From: tgen at netphreax.net (Thomas E. Spanjaard)
Date: Tue, 4 Mar 2008 06:54:31 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47CD615F.8010209@netphreax.net>

Matthias Schmidt wrote:
Google just announced its Summer of Code for 2008:

 * [Add your own thoughts here]
x86-64 port :).
--
        Thomas E. Spanjaard
        tgen at netphreax.net
Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00001.pgp
Type: application/octet-stream
Size: 186 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080304/0d921000/attachment-0002.obj>

From rdivacky at FreeBSD.org  Tue Mar  4 07:07:03 2008
From: rdivacky at FreeBSD.org (Roman Divacky)
Date: Tue, 4 Mar 2008 07:07:03 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <20080304150255.GA8831@freebsd.org>

On Tue, Mar 04, 2008 at 02:49:03PM +0000, Thomas E. Spanjaard wrote:
> Matthias Schmidt wrote:
> >Google just announced its Summer of Code for 2008:
> >
> > * [Add your own thoughts here]
> 
> x86-64 port :).

all those ideas are great and needed etc. but keep in
mind that the projects should be doable by students
who might see dfly for the very first time.

don't overestimate whats possible and select projects
that look realistic

Roman Divacky (former SoC student)




From justin at shiningsilence.com  Tue Mar  4 08:32:56 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Tue, 4 Mar 2008 08:32:56 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <60322.65.106.147.226.1204648095.squirrel@www.shiningsilence.com>

On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
> Hi,
>
> Google just announced its Summer of Code for 2008:
>
> 	http://code.google.com/soc/2008/
>
> I think this would be a great opportunity for DragonFly to participate
> as a mentoring organisation.  We could attract new developers and could
> get code/work done.  Looking at the SoC results of the other BSDs most
> of their projects were a success.  Of course, not all, but a reasonable
> percentage.  See [1] and [2].

We've applied in previous years - Jeff Hsu did one year, and I put
together the application last year.  The hardest thing to find was
students (and they are the thing that helps SoC applications a lot, I
think).

Any student volunteers?  We have mentors.





From rluciani at gmail.com  Tue Mar  4 09:38:29 2008
From: rluciani at gmail.com (Robert Luciani)
Date: Tue, 04 Mar 2008 18:38:29 +0100
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47cd8915$0$854$415eb37d@crater_reader.dragonflybsd.org>

Justin C. Sherrill wrote:
> On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
>> Hi,
>>
>> Google just announced its Summer of Code for 2008:
>>
>> 	http://code.google.com/soc/2008/
>>
>> I think this would be a great opportunity for DragonFly to participate
>> as a mentoring organisation.  We could attract new developers and could
>> get code/work done.  Looking at the SoC results of the other BSDs most
>> of their projects were a success.  Of course, not all, but a reasonable
>> percentage.  See [1] and [2].
> 
> We've applied in previous years - Jeff Hsu did one year, and I put
> together the application last year.  The hardest thing to find was
> students (and they are the thing that helps SoC applications a lot, I
> think).
> 
> Any student volunteers?  We have mentors.
> 

bingo

-- 
Robert Luciani
Chalmers University of Technology, SWE
Department of Computer Science and Engineering
http://www.rluciani.com/public.key




From sdavtaker at gmail.com  Tue Mar  4 09:31:08 2008
From: sdavtaker at gmail.com (=?UTF-8?Q?Sd=C3=A4vtaker?=)
Date: Tue, 4 Mar 2008 09:31:08 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <c37d69f60803040926k206218a3kb8496d0cd18148bd@mail.gmail.com>

If you mentor, i will apply for coder :-)
Still in last year of university. :-)
Sdav

On Tue, Mar 4, 2008 at 1:28 PM, Justin C. Sherrill
<justin at shiningsilence.com> wrote:
> On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
>  > Hi,
>  >
>  > Google just announced its Summer of Code for 2008:
>  >
>  >       http://code.google.com/soc/2008/
>  >
>  > I think this would be a great opportunity for DragonFly to participate
>  > as a mentoring organisation.  We could attract new developers and could
>  > get code/work done.  Looking at the SoC results of the other BSDs most
>  > of their projects were a success.  Of course, not all, but a reasonable
>  > percentage.  See [1] and [2].
>
>  We've applied in previous years - Jeff Hsu did one year, and I put
>  together the application last year.  The hardest thing to find was
>  students (and they are the thing that helps SoC applications a lot, I
>  think).
>
>  Any student volunteers?  We have mentors.
>
>



-- 
Sd?vtaker prays to Rikku goddess for a good treasure.



From rluciani at gmail.com  Tue Mar  4 09:44:02 2008
From: rluciani at gmail.com (Robert Luciani)
Date: Tue, 04 Mar 2008 18:44:02 +0100
Subject: google soc "DragonFly"
Message-ID: <47cd8a63$0$855$415eb37d@crater_reader.dragonflybsd.org>

On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
> > Hi,
> >
> > Google just announced its Summer of Code for 2008:
> >
> > 	http://code.google.com/soc/2008/
> >
> > I think this would be a great opportunity for DragonFly to participate
> > as a mentoring organisation.  We could attract new developers and could
> > get code/work done.  Looking at the SoC results of the other BSDs most
> > of their projects were a success.  Of course, not all, but a reasonable
> > percentage.  See [1] and [2].

We've applied in previous years - Jeff Hsu did one year, and I put
together the application last year.  The hardest thing to find was
students (and they are the thing that helps SoC applications a lot, I
think).

Any student volunteers?  We have mentors.


-- 
Robert Luciani
Chalmers University of Technology, SWE
Department of Computer Science and Engineering
http://www.rluciani.com/public.key




From rluciani at gmail.com  Tue Mar  4 10:04:14 2008
From: rluciani at gmail.com (Robert Luciani)
Date: Tue, 04 Mar 2008 19:04:14 +0100
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47cd8f1f$0$856$415eb37d@crater_reader.dragonflybsd.org>

Robert Luciani wrote:
> Justin C. Sherrill wrote:
>> On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
>>> Hi,
>>>
>>> Google just announced its Summer of Code for 2008:
>>>
>>> 	http://code.google.com/soc/2008/
>>>
>>> I think this would be a great opportunity for DragonFly to participate
>>> as a mentoring organisation.  We could attract new developers and could
>>> get code/work done.  Looking at the SoC results of the other BSDs most
>>> of their projects were a success.  Of course, not all, but a reasonable
>>> percentage.  See [1] and [2].
>> We've applied in previous years - Jeff Hsu did one year, and I put
>> together the application last year.  The hardest thing to find was
>> students (and they are the thing that helps SoC applications a lot, I
>> think).
>>
>> Any student volunteers?  We have mentors.
>>
> 
> bingo
> 
My girlfriend Danwei noted that she would also like partake in the SoC.
She's studying IT here at Chalmers and will join the mailing list shortly.
-- 
Robert Luciani
Chalmers University of Technology, SWE
Department of Computer Science and Engineering
http://www.rluciani.com/public.key




From dillon at apollo.backplane.com  Tue Mar  4 13:08:30 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Tue, 4 Mar 2008 13:08:30 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Going to have to roll 1.12.1
Message-ID: <200803042104.m24L43g1065278@apollo.backplane.com>

    Due to a critical bug in sendmail that can cause it to seg-fault I will
    be rolling 1.12.1 as soon as I get verification that the current
    fix deals with it.

						-Matt





From sdavtaker at gmail.com  Tue Mar  4 17:40:43 2008
From: sdavtaker at gmail.com (=?UTF-8?B?U2TDpHZ0YWtlcg==?=)
Date: Tue, 4 Mar 2008 17:40:43 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: [Fwd: Project Support Open Source: $50 donation to support you  project]
In-Reply-To: <2468.192.168.0.242.1204346451.squirrel@www.shiningsilence.com>
Message-ID: <47CDF8D1.9070100@gmail.com>

50 bucks?
Come on...
You can get a meal a lot more expensive than that just going to a free 
HP conference about linux and you only have to rent your soul 3-5 hours ;-)
Sdav

Matthew Dillon escribi?:
:..
:source project's web page.  I'm putting those words in scare quotes
:because I think it's a "payment" for an "advertisement".  The supplied
:link has nothing to do with DragonFly, to say the least.
:
:I don't think this is a good idea, obviously, and replied to that effect. 
:However, I wanted to put this on a DragonFly list, in part to show this
:strange thing, and in part because I'm not comfortable making
:administrative decisions on behalf of the Project without being open as
:possible about it.

    It doesn't really cry out to me either.

						-Matt

  






From sdavtaker at gmail.com  Tue Mar  4 17:56:35 2008
From: sdavtaker at gmail.com (=?UTF-8?B?U2TDpHZ0YWtlcg==?=)
Date: Tue, 4 Mar 2008 17:56:35 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47CDFCCE.1010106@gmail.com>

A cute idea for for GSOC would be to finish the installer.
We were talking about this in my local BUG, we trying to find out how to 
help on that from here.
There is a few missing features in the CD.

   * FDISK, you need to create the slides from another OS before
     install DFBSD, i think port FDisk from FBSD or any *BSD will solve it.
   * Add to the make release a way to add some custom applications to
     the released liveCD (suppose you want to add nmap or ssh or
     something just to use as test disk in some enviroment).
   * Make the installer a little more customizable, and maybe w/ a GUI
     (I like a lot the console approach, but GUI installer will be a
     popularity move, DFBSD w/X makes a Desktop machine work, actually
     im using it that way and really like it).
I think those projects can be done in a SOC by students (like me) with a 
little guide.
Im a lot more interested in things network related and kernel, but i 
dont mind to work on those things, they need to be done some day.
What u think?
Sdav

Robert Luciani escribi?:
Robert Luciani wrote:
  
Justin C. Sherrill wrote:
    
On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
      
Hi,

Google just announced its Summer of Code for 2008:

	http://code.google.com/soc/2008/

I think this would be a great opportunity for DragonFly to participate
as a mentoring organisation.  We could attract new developers and could
get code/work done.  Looking at the SoC results of the other BSDs most
of their projects were a success.  Of course, not all, but a reasonable
percentage.  See [1] and [2].
        
We've applied in previous years - Jeff Hsu did one year, and I put
together the application last year.  The hardest thing to find was
students (and they are the thing that helps SoC applications a lot, I
think).
Any student volunteers?  We have mentors.

      
bingo

    
My girlfriend Danwei noted that she would also like partake in the SoC.
She's studying IT here at Chalmers and will join the mailing list shortly.
  






From c.turner at 199technologies.org  Tue Mar  4 18:30:53 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Tue, 4 Mar 2008 18:30:53 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47CE04C9.1010902@199technologies.org>

Justin C. Sherrill wrote:
together the application last year.  The hardest thing to find was
students (and they are the thing that helps SoC applications a lot, I
think).
umm.. if google wants to send me back to school, I'll sign up - hows 
that for a fair trade :?






From wbh at conducive.org  Tue Mar  4 23:52:13 2008
From: wbh at conducive.org (Bill Hacker)
Date: Wed, 05 Mar 2008 07:52:13 +0000
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47ce512e$0$855$415eb37d@crater_reader.dragonflybsd.org>

Sd?vtaker wrote:
A cute idea for for GSOC would be to finish the installer.
We were talking about this in my local BUG, we trying to find out how to 
help on that from here.
There is a few missing features in the CD.

   * FDISK, you need to create the slides from another OS before
     install DFBSD, i think port FDisk from FBSD or any *BSD will solve it.
I'd rather see that 'reversed' - i.e. - build a more capable fdisk in 
DFLY with hope that it might be seen worth importing into Free/Net/Open, 
or *at least* be able to do a more flexible job than those now do.

And disklabels as well. Hand in glove.

Here's why:

- At the moment, working with Free, Open, DFLY, and OpenSolaris on the 
same HDD requires a bit of acrobatics.

- There seems to now be greater divergence between/among the *BSD's as 
to being able to read each other's disklabels, mount and use each 
other's 'flavor' of FFS/UFS (not to mention Apple's implementation of 
UFS) than there is among the vast multitude of Linux ext2/3 denizens.

Even to the point where use of a *Linux* fs is the more universal way 
for being able to share mounts among the *BSD's. Think detached drives. 
And no - FAT is not all that practical for several reasons.

- DFLY currently has the most fine-grain ability to create slices and 
partitions. But the others cannot all (any?) read those.

'progress' w/r any of the *BSD's direction as to changes, improvements 
(or not) in their once-common-ancestry fs & disklabels need not be 
sacrificed.

I'm not holding out wish or hope for all players agreeing to return to 
'one sacred way'. Nor 'one new universal fs'. Neither is gonna happen.

But a 'legacy compatible' or least-common-denominator mode would do fine 
- most especially for portable / SAN devices.

So - how about a 'flexible' DFLY fdisk to go along with a 'flexible' 
disklabel that could adapt to whatever it found / was told to create?

JM2CW - but that *might* be a good place to get a cross-*BSD team together.

*snip* (other good stuff)

Bill Hacker




From matthias at dragonflybsd.org  Wed Mar  5 01:02:43 2008
From: matthias at dragonflybsd.org (Matthias Schmidt)
Date: Wed, 5 Mar 2008 01:02:43 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <20080305085747.GJ9833@staatsfeind.org>

Hi,

* Justin C. Sherrill wrote:
> 
> We've applied in previous years - Jeff Hsu did one year, and I put
> together the application last year.  The hardest thing to find was
> students (and they are the thing that helps SoC applications a lot, I
> think).

This is good to know, so we could coordinate that if we have enough
mentors and projects?!?  I put together a small text in the wiki:

http://wiki.dragonflybsd.org/index.cgi/GoogleSoC2008

Feel free to add project or missing stuff.  I'm sure I missed a lot of
things :)

> Any student volunteers?  We have mentors.

According to the discussion we could have some students, who would be a
mentor (besides me)?

Regards

	Matthias





From sdavtaker at gmail.com  Wed Mar  5 06:28:37 2008
From: sdavtaker at gmail.com (=?UTF-8?Q?Sd=C3=A4vtaker?=)
Date: Wed, 5 Mar 2008 06:28:37 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <c37d69f60803050624kd86d3d0w3b44a02d0e5a5391@mail.gmail.com>

<quote>
Write a driver (from scratch) for Intel 3945 wireless device
Mentor: Sepherosa Ziehau
</quote>

Yes yes yes, i want to :-)
Someone else planning to mentor in drivers coding?
Sdav

On Wed, Mar 5, 2008 at 5:57 AM, Matthias Schmidt
<matthias at dragonflybsd.org> wrote:
> Hi,
>
>
>  * Justin C. Sherrill wrote:
>  >
>  > We've applied in previous years - Jeff Hsu did one year, and I put
>  > together the application last year.  The hardest thing to find was
>  > students (and they are the thing that helps SoC applications a lot, I
>  > think).
>
>  This is good to know, so we could coordinate that if we have enough
>  mentors and projects?!?  I put together a small text in the wiki:
>
>  http://wiki.dragonflybsd.org/index.cgi/GoogleSoC2008
>
>  Feel free to add project or missing stuff.  I'm sure I missed a lot of
>  things :)
>
>
>  > Any student volunteers?  We have mentors.
>
>  According to the discussion we could have some students, who would be a
>  mentor (besides me)?
>
>  Regards
>
>         Matthias
>
>



-- 
Sd?vtaker prays to Rikku goddess for a good treasure.



From rluciani at gmail.com  Wed Mar  5 10:56:42 2008
From: rluciani at gmail.com (Robert Luciani)
Date: Wed, 05 Mar 2008 19:56:42 +0100
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47ceecea$0$847$415eb37d@crater_reader.dragonflybsd.org>

Sd?vtaker wrote:
> <quote>
> Write a driver (from scratch) for Intel 3945 wireless device
> Mentor: Sepherosa Ziehau
> </quote>
> 
> Yes yes yes, i want to :-)
> Someone else planning to mentor in drivers coding?
> Sdav
> 
> On Wed, Mar 5, 2008 at 5:57 AM, Matthias Schmidt
> <matthias at dragonflybsd.org> wrote:
>> Hi,
>>
>>
>>  * Justin C. Sherrill wrote:
>>  >
>>  > We've applied in previous years - Jeff Hsu did one year, and I put
>>  > together the application last year.  The hardest thing to find was
>>  > students (and they are the thing that helps SoC applications a lot, I
>>  > think).
>>
>>  This is good to know, so we could coordinate that if we have enough
>>  mentors and projects?!?  I put together a small text in the wiki:
>>
>>  http://wiki.dragonflybsd.org/index.cgi/GoogleSoC2008
>>
>>  Feel free to add project or missing stuff.  I'm sure I missed a lot of
>>  things :)
>>
>>
>>  > Any student volunteers?  We have mentors.
>>
>>  According to the discussion we could have some students, who would be a
>>  mentor (besides me)?
>>
>>  Regards
>>
>>         Matthias
>>
>>
> 
> 
>

IF someone starts to write a 3945 Intel driver,
please keep the newer 4965 in mind too.

-- 
Robert Luciani
Chalmers University of Technology, SWE
Department of Computer Science and Engineering
http://www.rluciani.com/public.key




From joerg at britannica.bec.de  Wed Mar  5 12:01:05 2008
From: joerg at britannica.bec.de (Joerg Sonnenberger)
Date: Wed, 5 Mar 2008 12:01:05 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <20080305195711.GA9981@britannica.bec.de>

On Wed, Mar 05, 2008 at 07:56:42PM +0100, Robert Luciani wrote:
> IF someone starts to write a 3945 Intel driver,
> please keep the newer 4965 in mind too.

NetBSD's wpi works quite well. The hardware is quite different from
4945.

Joerg




From sepherosa at gmail.com  Wed Mar  5 17:48:50 2008
From: sepherosa at gmail.com (Sepherosa Ziehau)
Date: Wed, 5 Mar 2008 17:48:50 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <ea7b9c170803051744u22b09484ofc994f034f11df3b@mail.gmail.com>

On Thu, Mar 6, 2008 at 2:56 AM, Robert Luciani <rluciani at gmail.com> wrote:
>  IF someone starts to write a 3945 Intel driver,

"IF" you know that trying to fix any wired bugs in certain drivers
(e.g. ipw, ral) will require you to read through all of the vendor's
linux code (yes, even including register values and position), i.e.
there is not much difference between writing one from scratch and
porting+fixing_bugs, then you probably will not put "IF" at the start
of your sentence.
If what I said sounded too harsh to you, then I was sorry.

>  please keep the newer 4965 in mind too.

Will do, once generic 11n support is brought in from freebsd.

Best Regards,
sephe

-- 
Live Free or Die




From saw at online.de  Thu Mar  6 05:34:14 2008
From: saw at online.de (Sascha Wildner)
Date: Thu, 06 Mar 2008 14:34:14 +0100
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
Message-ID: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>

Hi all,

this is probably as good a moment as any to come out of the forest with 
this. The patch at

http://leaf.dragonflybsd.org/~swildner/nrelease_gui.diff

adds some code to nrelease/ to build a LiveCD with xorg and so on 
(currently, only the xorg metapackages and fluxbox are added). In order 
to build one, you need a local dir with the pkgsrc binary packages (see 
below).

The following commands should then do the trick:

cd /usr/src
make buildworld
make buildkernel
cd nrelease
patch -p 0 </path/to/the/patch
make PKGSRC_PKG_PATH=/path/to/packages/dir/All realquick gui
The resulting ISO will be in /usr/release/dfly-gui.iso then. It will not 
boot into xorg automatically (although this is easily possible), so you 
need to login as root and do startx.

As of now, this all is kind of basic, more a proof of concept than 
anything else. As our release framework installs packages via chroot, 
the current setup just copies _all_ packages to the chroot before 
installing (kind of a hack).

That said, I'm now primarily interested in opinions/ideas/... about the 
direction this should take. Which packages would we like to see on the 
CD? Should it be a generic setup with the "most common things" 
installed, so a system can be quickly setup by the installer (which will 
cpdup /usr/pkg). Or should it be a more specialized set of tools? Or 
even as many packages as possible (Live DVD?). Etc., etc.

Before continuing on it, I'm really interested in people's input so 
don't hold anything back, please. :)

Sascha

--
http://yoyodyne.ath.cx



From rluciani at gmail.com  Thu Mar  6 06:42:03 2008
From: rluciani at gmail.com (Robert Luciani)
Date: Thu, 06 Mar 2008 15:42:03 +0100
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <47d002bc$0$847$415eb37d@crater_reader.dragonflybsd.org>

Sascha Wildner wrote:
> Hi all,
> 
> this is probably as good a moment as any to come out of the forest with
> this. The patch at
> 
> http://leaf.dragonflybsd.org/~swildner/nrelease_gui.diff
> 
> adds some code to nrelease/ to build a LiveCD with xorg and so on
> (currently, only the xorg metapackages and fluxbox are added). In order
> to build one, you need a local dir with the pkgsrc binary packages (see
> below).
> 
> The following commands should then do the trick:
> 
> cd /usr/src
> make buildworld
> make buildkernel
> cd nrelease
> patch -p 0 </path/to/the/patch
> make PKGSRC_PKG_PATH=/path/to/packages/dir/All realquick gui
> 
> The resulting ISO will be in /usr/release/dfly-gui.iso then. It will not
> boot into xorg automatically (although this is easily possible), so you
> need to login as root and do startx.
> 
> As of now, this all is kind of basic, more a proof of concept than
> anything else. As our release framework installs packages via chroot,
> the current setup just copies _all_ packages to the chroot before
> installing (kind of a hack).
> 
> That said, I'm now primarily interested in opinions/ideas/... about the
> direction this should take. Which packages would we like to see on the
> CD? Should it be a generic setup with the "most common things"
> installed, so a system can be quickly setup by the installer (which will
> cpdup /usr/pkg). Or should it be a more specialized set of tools? Or
> even as many packages as possible (Live DVD?). Etc., etc.
> 
> Before continuing on it, I'm really interested in people's input so
> don't hold anything back, please. :)
> 
> Sascha
> 

I think the main point of such a live-cd would be to test
dragonfly-specific features such as vkernels and more. Mplayer and
OpenOffic work the same on all platforms, so they might not be super
important, while irssi, firefox, networking tools, vim, a few more
shells/terminals might make it easier to for people to quickly gauge if
they can reproduce their current productivity and also what is new.

And if the point of a livecd is to test that kind of stuff, then it
would be nice for it to have a kernel that supports as much as possible
like ALTQ, and drivers.

Also if it has lots and lots of programs (thinking multimedia, java,
etc..) it might be hard to keep the future x64 and x86 live-cds on par.
Gentoo had this problem many years ago and it was very bothersome.

-- 
Robert Luciani
Chalmers University of Technology, SWE
Department of Computer Science and Engineering
http://www.rluciani.com/public.key




From matthias at dragonflybsd.org  Thu Mar  6 07:12:43 2008
From: matthias at dragonflybsd.org (Matthias Schmidt)
Date: Thu, 6 Mar 2008 07:12:43 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <20080306150757.GN9833@staatsfeind.org>

* Sascha Wildner wrote:
> Hi all,
> 
> this is probably as good a moment as any to come out of the forest with this. 
> The patch at
> 
> http://leaf.dragonflybsd.org/~swildner/nrelease_gui.diff
> 
> adds some code to nrelease/ to build a LiveCD with xorg and so on (currently, 
> only the xorg metapackages and fluxbox are added). In order to build one, you 
> need a local dir with the pkgsrc binary packages (see below).

Great work Sascha.

I agree with Robert on most of his stated points.
It would be nice to see some DragonFly specific features on the CD
(although I'm not sure if that will work for all features).  A little
environment where most Unix users feel at home (fluxbox, xfce, firefox,
thunderbird, gvim) should be enough.

Big applications like OO.org, java etc won't work because they are not
available as pkgsrc packages neither is it possible to compile them on
DragonFly.  At least to my knowledge.

Regards

	Matthias




From dillon at apollo.backplane.com  Thu Mar  6 09:31:52 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Thu, 6 Mar 2008 09:31:52 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <200803061728.m26HSR3O091809@apollo.backplane.com>


:Hi all,
:
:this is probably as good a moment as any to come out of the forest with 
:this. The patch at
:
:http://leaf.dragonflybsd.org/~swildner/nrelease_gui.diff
:
:adds some code to nrelease/ to build a LiveCD with xorg and so on 
:(currently, only the xorg metapackages and fluxbox are added). In order 
:to build one, you need a local dir with the pkgsrc binary packages (see 
:below).
:
:The following commands should then do the trick:

    It looks reasonable, though the package copy has to be tightened
    up a bit I think.

:...
:installed, so a system can be quickly setup by the installer (which will 
:cpdup /usr/pkg). Or should it be a more specialized set of tools? Or 
:even as many packages as possible (Live DVD?). Etc., etc.
:
:Before continuing on it, I'm really interested in people's input so 
:don't hold anything back, please. :)
:
:Sascha

    I think this is an excellent time to work up a DVD build and to
    add various 'flavor' extras.  So, e.g.:

	make installer gui gui_extras release dvd

    (All 'dvd' would do is generate a dvd compatible image for burning to
    dvd instead of cd).  I did a quick perusal of what I have on my
    workstation:

    * X
    * Firefox
    * Linux emulation
    * Open Office (linux version)
    * fvwm2
    * xpdf
    * freetype2

    I'd also suggest some image editing tools like gimp, and maybe the KDE
    gui suite.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From justin at shiningsilence.com  Thu Mar  6 09:42:44 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Thu, 6 Mar 2008 09:42:44 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <55427.65.106.147.226.1204825168.squirrel@www.shiningsilence.com>

On Thu, March 6, 2008 8:34 am, Sascha Wildner wrote:

> That said, I'm now primarily interested in opinions/ideas/... about the
> direction this should take. Which packages would we like to see on the
> CD? Should it be a generic setup with the "most common things"
> installed, so a system can be quickly setup by the installer (which will
> cpdup /usr/pkg). Or should it be a more specialized set of tools? Or
> even as many packages as possible (Live DVD?). Etc., etc.

What Robert said is good - whatever's needed to enable DragonFly-specific
features.  Along with that would be some sort of documentation (a README? 
A HTML file on whatever desktop we provide) that points people at the
different DragonFly tools, so they know what to try and how to try it.

There's going to be some percentage of people who try DragonFly who don't
know about vkernels, for instance, but there's our chance to educate them.
 I'm probably volunteering myself, aren't I?





From sdavtaker at gmail.com  Thu Mar  6 09:50:09 2008
From: sdavtaker at gmail.com (=?UTF-8?Q?Sd=C3=A4vtaker?=)
Date: Thu, 6 Mar 2008 09:50:09 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <c37d69f60803060947t110750c0sd6b542ea505d188d@mail.gmail.com>

Cool Sascha :-)
I just posted about this 1 or 2 days ago in the SOC project ideas thread.
Want to mentor this one? ;-)
Damian

On Thu, Mar 6, 2008 at 2:28 PM, Matthew Dillon
<dillon at apollo.backplane.com> wrote:
>
>  :Hi all,
>
> :
>  :this is probably as good a moment as any to come out of the forest with
>  :this. The patch at
>  :
>  :http://leaf.dragonflybsd.org/~swildner/nrelease_gui.diff
>  :
>  :adds some code to nrelease/ to build a LiveCD with xorg and so on
>  :(currently, only the xorg metapackages and fluxbox are added). In order
>  :to build one, you need a local dir with the pkgsrc binary packages (see
>  :below).
>  :
>  :The following commands should then do the trick:
>
>     It looks reasonable, though the package copy has to be tightened
>     up a bit I think.
>
>  :...
>  :installed, so a system can be quickly setup by the installer (which will
>
> :cpdup /usr/pkg). Or should it be a more specialized set of tools? Or
>  :even as many packages as possible (Live DVD?). Etc., etc.
>  :
>  :Before continuing on it, I'm really interested in people's input so
>  :don't hold anything back, please. :)
>  :
>  :Sascha
>
>     I think this is an excellent time to work up a DVD build and to
>     add various 'flavor' extras.  So, e.g.:
>
>         make installer gui gui_extras release dvd
>
>     (All 'dvd' would do is generate a dvd compatible image for burning to
>     dvd instead of cd).  I did a quick perusal of what I have on my
>     workstation:
>
>     * X
>     * Firefox
>     * Linux emulation
>     * Open Office (linux version)
>     * fvwm2
>     * xpdf
>     * freetype2
>
>     I'd also suggest some image editing tools like gimp, and maybe the KDE
>     gui suite.
>
>                                         -Matt
>                                         Matthew Dillon
>                                         <dillon at backplane.com>
>



-- 
Sd?vtaker prays to Rikku goddess for a good treasure.



From saw at online.de  Thu Mar  6 11:54:01 2008
From: saw at online.de (Sascha Wildner)
Date: Thu, 06 Mar 2008 20:54:01 +0100
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <47d04ba2$0$856$415eb37d@crater_reader.dragonflybsd.org>

Matthew Dillon wrote:
    It looks reasonable, though the package copy has to be tightened
    up a bit I think.
It looks as if it would work with mount_null'ing the chroot's 
/tmp/packages. I'll have a better patch ready tomorrow.

Sascha

--
http://yoyodyne.ath.cx



From c.turner at 199technologies.org  Thu Mar  6 19:11:44 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Thu, 6 Mar 2008 19:11:44 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Misc. ACPI / suspend
In-Reply-To: <47CA073B.6020106@199technologies.org>
Message-ID: <47D0B079.3060905@199technologies.org>

Chris Turner wrote:
Wondering if anyone more well versed in the ACPI implementation could
comment on the applicability of:
http://lkml.org/lkml/2007/4/6/69

Doing a little digging, it seems like

. /platform/pc32/i386/i686_mem.c

*might* have the necessary infrastructure to remap the MTRR's per the 
thread referenced,

but:

. /platform/pc32/acpica5/acpi_wakeup.c

doesn't seem to be using this infrastructure..

I'm no where near reaching an understanding of this yet,
but I'm wondering 3 things:
1) does anyone have ACPI (instead of APM)
   sleep / suspend / wakeup working on Dfly ?
2) If so, what machines are being used ?
3) Same question for other BSDs - my understanding is NetBSD is most
   'advanced' w/r/t power managment - but I'm not 100% on this ...
would looove to have a sleeping / resuming / scaling laptop running some 
BSD flavor.. am willing to work towards that end, esp. w/r/t Dfly -
trying to chart a course to figguring this out.

Thanks all,

- Chris




From c.turner at 199technologies.org  Thu Mar  6 19:12:33 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Thu, 6 Mar 2008 19:12:33 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: PCI Bios / Interrupt remapping / etc
Message-ID: <47D0B211.6000002@199technologies.org>

Doing a bit of digging here for my long-standing CBB+SIO interupt and 
buffer problem -

one machine I've tested against was an OpenBSD machine, which didn't
always work to handle the cardbus sio card on a PCI cardbus adapter
-

tuning up some of the device flags in:

http://www.openbsd.org/cgi-bin/man.cgi?query=pcibios&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=html

seems to have alleviated the problem for that os..

I'm just only starting to get up to speed on how DF handles these types 
of things (namely initial PIC / interrupt layout at boot time device 
enumeration), but am wondering if anyone familiar with this area of the 
code has any comments / advice w/r/t the capabilities of the DF bios 
drivers
and the various quirks / fixup mentioned in the link above..

looking to possibly investigate fixing up some of these issues over time.

Thanks

- Chris







From pavalos at theshell.com  Fri Mar  7 01:14:55 2008
From: pavalos at theshell.com (Peter Avalos)
Date: Fri, 7 Mar 2008 01:14:55 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: cam locking
Message-ID: <20080307091024.GC1652@ylem.theshell.com>

So I've been working on locking up cam using lockmgr locks, and here's
what I have so far:

http://www.theshell.com/~pavalos/wip/cam-lock.patch

Most of the work is obtained from FreeBSD.  I've only been running this
on my SCSI machine for a day, but because the patch is so large, I wanted
to make it available for people to review if they have some spare time.

Thanks,
Peter
Attachment:
pgp00002.pgp
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00002.pgp
Type: application/octet-stream
Size: 197 bytes
Desc: "Description: PGP signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080307/9a17ecd8/attachment-0002.obj>

From jspringe at uos.de  Fri Mar  7 03:25:17 2008
From: jspringe at uos.de (Jost Tobias Springenberg)
Date: Fri, 7 Mar 2008 12:25:17 +0100
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <20080307122517.72c9e2b1.jspringe@uos.de>

On Tue, 4 Mar 2008 11:28:15 -0500 (EST)
"Justin C. Sherrill" <justin at shiningsilence.com> wrote:

> On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
> > Hi,
> >
> > Google just announced its Summer of Code for 2008:
> >
> > 	http://code.google.com/soc/2008/
> >
> > I think this would be a great opportunity for DragonFly to participate
> > as a mentoring organisation.  We could attract new developers and could
> > get code/work done.  Looking at the SoC results of the other BSDs most
> > of their projects were a success.  Of course, not all, but a reasonable
> > percentage.  See [1] and [2].
> 
> We've applied in previous years - Jeff Hsu did one year, and I put
> together the application last year.  The hardest thing to find was
> students (and they are the thing that helps SoC applications a lot, I
> think).
> 
> Any student volunteers?  We have mentors.
> 

I read this mailing list for quite a while now and thought about contributing stuff
to DFfly several times, so yes why not take this opportunity if it's there.

-- 
Jost Tobias Springenberg <jspringe at uos.de>




From tgen at netphreax.net  Fri Mar  7 05:17:27 2008
From: tgen at netphreax.net (Thomas E. Spanjaard)
Date: Fri, 7 Mar 2008 05:17:27 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: PCI Bios / Interrupt remapping / etc
In-Reply-To: <47D0B211.6000002@199technologies.org>
Message-ID: <47D13FB4.5080306@netphreax.net>

Chris Turner wrote:
Doing a bit of digging here for my long-standing CBB+SIO interupt and 
buffer problem -

one machine I've tested against was an OpenBSD machine, which didn't
always work to handle the cardbus sio card on a PCI cardbus adapter
-

tuning up some of the device flags in:

http://www.openbsd.org/cgi-bin/man.cgi?query=pcibios&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=html 

seems to have alleviated the problem for that os..

I'm just only starting to get up to speed on how DF handles these types 
of things (namely initial PIC / interrupt layout at boot time device 
enumeration), but am wondering if anyone familiar with this area of the 
code has any comments / advice w/r/t the capabilities of the DF bios 
drivers
and the various quirks / fixup mentioned in the link above..

looking to possibly investigate fixing up some of these issues over time.
Our code that handles issues like this (in cases where you're not using 
APICs, just PICs and PIRs) lives in bus/pci/i386/. Not that running 
without APIC support is all that common on modern machines anymore...
--
        Thomas E. Spanjaard
        tgen at netphreax.net
Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00003.pgp
Type: application/octet-stream
Size: 186 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080307/61366b5c/attachment-0002.obj>

From tgen at netphreax.net  Fri Mar  7 05:16:51 2008
From: tgen at netphreax.net (Thomas E. Spanjaard)
Date: Fri, 7 Mar 2008 05:16:51 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Misc. ACPI / suspend
In-Reply-To: <47CA073B.6020106@199technologies.org>
Message-ID: <47D13F07.9080308@netphreax.net>

Chris Turner wrote:
1) does anyone have ACPI (instead of APM)
   sleep / suspend / wakeup working on Dfly ?
2) If so, what machines are being used ?
3) Same question for other BSDs - my understanding is NetBSD is most
   'advanced' w/r/t power managment - but I'm not 100% on this ...
would looove to have a sleeping / resuming / scaling laptop running some 
BSD flavor.. am willing to work towards that end, esp. w/r/t Dfly -
trying to chart a course to figguring this out.
I have ACPI S3 suspend working like a charm on my IBM ThinkPad R40 
(Pentium M "Banias" 1.3GHz, speedstepping works just fine), running 
NetBSD 3.99.21.
--
        Thomas E. Spanjaard
        tgen at netphreax.net
Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00004.pgp
Type: application/octet-stream
Size: 186 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080307/de3e5104/attachment-0002.obj>

From civilizd at gmail.com  Fri Mar  7 09:06:41 2008
From: civilizd at gmail.com (Vita "CiV" Cizek)
Date: Fri, 7 Mar 2008 09:06:41 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <98d564710803070853q1c73d795m6e6c5cc5049fa099@mail.gmail.com>

>  Any student volunteers?  We have mentors.
>
I am interested too, especially in some kernel-related work.




From justin at shiningsilence.com  Sat Mar  8 12:07:51 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Sat, 8 Mar 2008 12:07:51 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google SoC 2008 - mentors mentors mentors
Message-ID: <51558.192.168.0.252.1205006403.squirrel@www.shiningsilence.com>

If you are willing to mentor for the Google 2008 Summer of Code, please
speak up.  Right now we have: (from our wiki page)

Matthias
Sephe
TGEN
corecode

Part of the application process includes naming people as mentors (student
applications come later), so I want to get as complete a list as possible.

The application is due on the 12th, so if you want to mentor, now's the
time to say so.

Google's SoC FAQ is here: http://code.google.com/soc/2008/faqs.html

Our wiki page is here: http://wiki.dragonflybsd.org/index.cgi/GoogleSoC2008

- much credit to Matthias and others for getting that set up.





From saw at online.de  Sat Mar  8 14:26:07 2008
From: saw at online.de (Sascha Wildner)
Date: Sat, 08 Mar 2008 23:26:07 +0100
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <47d31245$0$848$415eb37d@crater_reader.dragonflybsd.org>

Sascha Wildner wrote:
Hi all,

this is probably as good a moment as any to come out of the forest with 
this. The patch at

http://leaf.dragonflybsd.org/~swildner/nrelease_gui.diff
Ok, I have committed the stuff as an example.

I'm not sure if my free time permits to work on a full-blown live CD 
with X11 and other good things (I already feel my interest wandering off 
in other directions) so if anyone wants to pick up the ball, go ahead. :)

Sascha

--
http://yoyodyne.ath.cx



From qhwt+dfly at les.ath.cx  Tue Mar 11 22:21:31 2008
From: qhwt+dfly at les.ath.cx (YONETANI Tomokazu)
Date: Tue, 11 Mar 2008 22:21:31 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Misc. ACPI / suspend
In-Reply-To: <47CA073B.6020106@199technologies.org>
Message-ID: <20080312051219.GA56091@les.ath.cx>

On Thu, Mar 06, 2008 at 10:03:21PM -0500, Chris Turner wrote:
> 1) does anyone have ACPI (instead of APM)
>    sleep / suspend / wakeup working on Dfly ?
> 2) If so, what machines are being used ?

Dynabook SS3500 (http://www.tlt.co.jp/pc/catalog/ss/02110735/index_j.htm).
It's old and can get very hot(thus frequently turns on the cooling fan)
even when it's running Windows.  I haven't turned it on for about several
months though.

Cheers.




From c.turner at 199technologies.org  Wed Mar 12 04:37:22 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Wed, 12 Mar 2008 04:37:22 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Misc. ACPI / suspend
In-Reply-To: <47CA073B.6020106@199technologies.org>
Message-ID: <47D7BEE3.6010907@199technologies.org>

YONETANI Tomokazu wrote:
On Thu, Mar 06, 2008 at 10:03:21PM -0500, Chris Turner wrote:
1) does anyone have ACPI (instead of APM)
   sleep / suspend / wakeup working on Dfly ?
Cheers.
ditto..

Suppose this should go to docs@ - in any case..

Thinking about setting up a wiki page on the issue so we
can discuss / track what 'good' hardware / drivers / implementations / 
etc are 'out there' - anyone have any suggestions on where this should
go?

http://wiki.dragonflybsd.org/index.cgi/acpi-overview.html

Remains from the handbook conversion - but I'm hesitant to 'over wikify'
this ..



From c.turner at 199technologies.org  Wed Mar 12 15:36:52 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Wed, 12 Mar 2008 15:36:52 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: devel/cscope
Message-ID: <47D85A08.8040103@199technologies.org>

why oh why did I take so long to try this out !!!

just sharing my eureka moment with the list..

- Chris




From dudu at dudu.ro  Wed Mar 12 15:50:14 2008
From: dudu at dudu.ro (Vlad GALU)
Date: Wed, 12 Mar 2008 15:50:14 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: devel/cscope
In-Reply-To: <47D85A08.8040103@199technologies.org>
Message-ID: <ad79ad6b0803121547r2bf67ffep9e40badaac6490f8@mail.gmail.com>

On 3/13/08, Chris Turner <c.turner at 199technologies.org> wrote:
> why oh why did I take so long to try this out !!!
>
>  just sharing my eureka moment with the list..


    Works nice with vim, too!

>
>
>  - Chris
>


-- 
Mahnahmahnah!




From justin at shiningsilence.com  Sun Mar 16 21:06:13 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Sun, 16 Mar 2008 21:06:13 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: binary packages for 1.12 coming in
Message-ID: <1372.192.168.0.252.1205726088.squirrel@www.shiningsilence.com>

The binary build for 1.12 is taking quite a while.  I've started copying
in newly built packages to
pkgbox.dragonflybsd.org/packages/DragonFly-1.12/i386/ - this should be
getting copied out to mirrors over the next while.

There are currently 1283 packages built, which leaves a whole lot to go;
I'll copy new packages in as they complete.





From hasso at estpak.ee  Wed Mar 19 04:31:08 2008
From: hasso at estpak.ee (Hasso Tepper)
Date: Wed, 19 Mar 2008 04:31:08 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Some questions regarding ACPI
Message-ID: <200803191322.46366.hasso@estpak.ee>

I'm working on bringing in some laptop (and especially thinkpad) specific 
ACPI code from FreeBSD into DragonFly. I never touched ACPI stuff before 
and haven't followed it much either, so I have some questions.

* FreeBSD uses ACPI_SERIAL_* heavily. What's the locking situation in 
  DragonFly and why?

* As far as I can see, PCI integration is commented out in DragonFly. 
  What's the state of it and why?

* platform/pc32/acpica5/acpi_toshiba.c - why is it there? I don't think 
  that this is something pc32 specific in it and it should work in pc64 
  laptops as well. Any objections to move it into 
  dev/acpica5/acpi_toshiba/ ?

What's the current status of ACPI in general? AFAICS our acpica is quite 
old - what needs to be done to bring in newer one?


-- 
Hasso




From qhwt+dfly at les.ath.cx  Wed Mar 19 09:24:50 2008
From: qhwt+dfly at les.ath.cx (YONETANI Tomokazu)
Date: Wed, 19 Mar 2008 09:24:50 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Some questions regarding ACPI
In-Reply-To: <200803191322.46366.hasso@estpak.ee>
Message-ID: <20080319161703.GA51509@les.ath.cx>

On Wed, Mar 19, 2008 at 01:22:46PM +0200, Hasso Tepper wrote:
> I'm working on bringing in some laptop (and especially thinkpad) specific 
> ACPI code from FreeBSD into DragonFly. I never touched ACPI stuff before 
> and haven't followed it much either, so I have some questions.

So you want to port some of ACPI support drivers, or to do a fresh port
of ACPI driver from FreeBSD?

> * FreeBSD uses ACPI_SERIAL_* heavily. What's the locking situation in 
>   DragonFly and why?

The current ACPI driver in DragonFly is based on that of FreeBSD as of
end of June, 2004, plus some fixes brought in later (and ACPICA part
has been updated twice since then).  That was before they introduced
the MPSAFE changes into ACPI code, and we use critical section
(crit_{enter,exit}) in most places (and lockmgr lock in a few place).

> * As far as I can see, PCI integration is commented out in DragonFly. 
>   What's the state of it and why?

When we replaced the implementation taken from FreeBSD 4.x with that
brought from FreeBSD 5.x, which added the PCI part, many people
experienced problems until they turned off ACPI completely, or add "pci"
to "debug.acpi.disabled" loader variable.  AFAIK the PCI part in the ACPI
driver almost hasn't been adjusted to work with our version of PCI code.

> * platform/pc32/acpica5/acpi_toshiba.c - why is it there? I don't think 
>   that this is something pc32 specific in it and it should work in pc64 
>   laptops as well. Any objections to move it into 
>   dev/acpica5/acpi_toshiba/ ?

In FreeBSD it used to be sitting at i386/acpica/acpi_toshiba.c and was
later moved into acpi_support.  That change hasn't hit our tree (in fact,
we have no acpi support drivers other than that).  It seems that FreeBSD
has them in dev/acpi_support now, and we for some reason have that
directory in our CVS repository (but containing no files in it).

> What's the current status of ACPI in general? AFAICS our acpica is quite 
> old - what needs to be done to bring in newer one?

Actually, it's not very important to keep just ACPICA latest, but
if you bring the ACPI driver from FreeBSD you need to bring ACPICA code
that matches their version, and it IS important.  And it generally requires
you much work to just update ACPICA part anyway because of how they
change things on every release.

Cheers.




From hasso at estpak.ee  Wed Mar 19 12:29:52 2008
From: hasso at estpak.ee (Hasso Tepper)
Date: Wed, 19 Mar 2008 12:29:52 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Some questions regarding ACPI
In-Reply-To: <200803191322.46366.hasso@estpak.ee>
Message-ID: <200803192115.35396.hasso@estpak.ee>

YONETANI Tomokazu wrote:
> On Wed, Mar 19, 2008 at 01:22:46PM +0200, Hasso Tepper wrote:
> > I'm working on bringing in some laptop (and especially thinkpad)
> > specific ACPI code from FreeBSD into DragonFly. I never touched ACPI
> > stuff before and haven't followed it much either, so I have some
> > questions.
>
> So you want to port some of ACPI support drivers, or to do a fresh port
> of ACPI driver from FreeBSD?

I'm only interested in support drivers and the reason is pure practical - 
newer thinkpads handle less and less hotkeys etc in hardware and require 
support form OS. acpi_ibm and acpi_video are examples of such modules 
which would help a lot of these newer thinkpad users.

acpi_ibm is almost ready to commit (renamed to acpi_thinkpad though).

> > * FreeBSD uses ACPI_SERIAL_* heavily. What's the locking situation in
> >   DragonFly and why?
>
> The current ACPI driver in DragonFly is based on that of FreeBSD as of
> end of June, 2004, plus some fixes brought in later (and ACPICA part
> has been updated twice since then).  That was before they introduced
> the MPSAFE changes into ACPI code, and we use critical section
> (crit_{enter,exit}) in most places (and lockmgr lock in a few place).

Mkay. Will look at more closely.

> > * As far as I can see, PCI integration is commented out in DragonFly.
> >   What's the state of it and why?
>
> When we replaced the implementation taken from FreeBSD 4.x with that
> brought from FreeBSD 5.x, which added the PCI part, many people
> experienced problems until they turned off ACPI completely, or add
> "pci" to "debug.acpi.disabled" loader variable.  AFAIK the PCI part in
> the ACPI driver almost hasn't been adjusted to work with our version of
> PCI code.

I'm afraid that it's beyond my skills, but while looking at acpi_video I 
discovered that it's hard to handle correctly without PCI support.

> > * platform/pc32/acpica5/acpi_toshiba.c - why is it there? I don't
> > think that this is something pc32 specific in it and it should work
> > in pc64 laptops as well. Any objections to move it into
> >   dev/acpica5/acpi_toshiba/ ?
>
> In FreeBSD it used to be sitting at i386/acpica/acpi_toshiba.c and was
> later moved into acpi_support.  That change hasn't hit our tree (in
> fact, we have no acpi support drivers other than that).  It seems that
> FreeBSD has them in dev/acpi_support now, and we for some reason have
> that directory in our CVS repository (but containing no files in it).

I don't see it ;). Makes sense though. So, any objections if I move 
acpi_toshiba into sys/dev/acpi_support and add new acpi_thinkpad there as 
well? 

> > What's the current status of ACPI in general? AFAICS our acpica is
> > quite old - what needs to be done to bring in newer one?
>
> Actually, it's not very important to keep just ACPICA latest, but
> if you bring the ACPI driver from FreeBSD you need to bring ACPICA code
> that matches their version, and it IS important.  And it generally
> requires you much work to just update ACPICA part anyway because of how
> they change things on every release.

Someone else has to do it :).

Thanks for info.


-- 
Hasso




From dillon at apollo.backplane.com  Wed Mar 19 14:01:13 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Wed, 19 Mar 2008 14:01:13 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: panic: assertion: hammer_btree_cmp(cursor->left_bound,	&cursor->node->ondisk->elms[0].leaf.base) <= 0 in btree_split_leaf
In-Reply-To: <200802232204.m1NM4cxd046264@apollo.backplane.com>
Message-ID: <200803192054.m2JKsjwn045137@apollo.backplane.com>


:Hi.
:While trying to find a procedure to reliably reproduce the panic
:I reported last time, I caught a different panic (uploaded at
: ~y0netan1/crash/9/ on my leaf account).  I wrote the following shell
:script (make sure to edit variables DISKS and MOUNTPT before using this
:script or it may trash your system):
:  #!/bin/sh -ex
:  DISKS="/dev/ad0s1f"
:  MOUNTPT=/mnt/HAMMER
:
:  cd /
:  newfs_hammer -L TEST $DISKS
:  for i in `seq 1 100`; do
:..
:And the panic is triggered by rm command.
:I'll try to see if it's possible to reproduce the last one without
:unmounting then mounting the HAMMER fs.
:
:Cheers.

    I believe I have fixed this panic.  hammer_make_separator() had a bug
    in it.

    There is still an issue with the node ref count on umount.

    Please continue to life-test the code.  The reblocking code
    (hammer reblock /mnt) should work now, as should the pruning code
    (e.g. hammer prune /mnt everything).

    The filesystem full case is still not handled and will cause bad things
    to happen.  The undo code isn't finished yet either but it is getting
    there (it's writing stuff out but not setting the sequence number and
    not trying to recover-on-mount yet).

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From qhwt+dfly at les.ath.cx  Wed Mar 19 19:45:40 2008
From: qhwt+dfly at les.ath.cx (YONETANI Tomokazu)
Date: Wed, 19 Mar 2008 19:45:40 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Some questions regarding ACPI
In-Reply-To: <200803191322.46366.hasso@estpak.ee>
Message-ID: <20080320023828.GA53648@les.ath.cx>

On Wed, Mar 19, 2008 at 09:15:35PM +0200, Hasso Tepper wrote:
> YONETANI Tomokazu wrote:
> > On Wed, Mar 19, 2008 at 01:22:46PM +0200, Hasso Tepper wrote:
> > > I'm working on bringing in some laptop (and especially thinkpad)
> > > specific ACPI code from FreeBSD into DragonFly. I never touched ACPI
> > > stuff before and haven't followed it much either, so I have some
> > > questions.
> >
> > So you want to port some of ACPI support drivers, or to do a fresh port
> > of ACPI driver from FreeBSD?
> 
> I'm only interested in support drivers and the reason is pure practical - 
> newer thinkpads handle less and less hotkeys etc in hardware and require 
> support form OS. acpi_ibm and acpi_video are examples of such modules 
> which would help a lot of these newer thinkpad users.
> 
> acpi_ibm is almost ready to commit (renamed to acpi_thinkpad though).

Ah, that's a good news!  My only concern is that ISTR someone mentioned
me that his colleague was thinking about porting ACPI driver itself,
so if you're not the person you may want to collaborate with him/her
so as not to waste the effort or time...

			:

> > In FreeBSD it used to be sitting at i386/acpica/acpi_toshiba.c and was
> > later moved into acpi_support.  That change hasn't hit our tree (in
> > fact, we have no acpi support drivers other than that).  It seems that
> > FreeBSD has them in dev/acpi_support now, and we for some reason have
> > that directory in our CVS repository (but containing no files in it).
> 
> I don't see it ;). Makes sense though. So, any objections if I move 
> acpi_toshiba into sys/dev/acpi_support and add new acpi_thinkpad there as 
> well? 

Sorry, I checked the CVS repository and it doesn't exist actually :)
I don't have any objection to moving it there.

Cheers.




From hasso at estpak.ee  Thu Mar 20 00:14:05 2008
From: hasso at estpak.ee (Hasso Tepper)
Date: Thu, 20 Mar 2008 00:14:05 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Some questions regarding ACPI
In-Reply-To: <200803191322.46366.hasso@estpak.ee>
Message-ID: <200803200904.50875.hasso@estpak.ee>

YONETANI Tomokazu wrote:
> On Wed, Mar 19, 2008 at 09:15:35PM +0200, Hasso Tepper wrote:
> > acpi_ibm is almost ready to commit (renamed to acpi_thinkpad though).
>
> Ah, that's a good news!  My only concern is that ISTR someone mentioned
> me that his colleague was thinking about porting ACPI driver itself,
> so if you're not the person you may want to collaborate with him/her
> so as not to waste the effort or time...

Current state in my repo is attached. It should work on 1.12 as well as it 
doesn't depend yet on moving stuff around.

add-acpi-if-m.patch adds some new stuff to the ACPI code to access 
embedded controllers and match ACPI devices by ID. Not sure how, where 
and whether at all these should be documented.

add-acpi-thinkpad.patch is the driver itself. Note that some stuff doesn't 
work yet on newer thinkpads, I plan to work on it later.

There is still some things to do though. I have to decide what to do with 
led(4) part and with locking. There is also one fatal issue - laptop 
locks up hardly (no panic) while unloading module. Any idea regarding 
this is welcome. And of course test results :).


-- 
Hasso
# HG changeset patch
# User Hasso Tepper <hasso at estpak.ee>
# Date 1205919290 -7200
# Branch HEAD
# Node ID 5a6e2705cc95a340abf973ae5df73ef34e070b79
# Parent  cd529e2e7f849034d5d5a0973cb98af50db0e797
imported patch adding-acpi-if-m.patch

diff --git a/sys/conf/files b/sys/conf/files
--- a/sys/conf/files
+++ b/sys/conf/files
@@ -1387,6 +1387,7 @@ emulation/dragonfly12/dfbsd12_stat.c	non
 ${OSACPI_MI_DIR}/acpi_cmbat.c		optional acpi
 ${OSACPI_MI_DIR}/acpi_cpu.c		optional acpi
 ${OSACPI_MI_DIR}/acpi_ec.c		optional acpi
+${OSACPI_MI_DIR}/acpi_if.m		optional acpi
 ${OSACPI_MI_DIR}/acpi_isab.c		optional acpi isa
 ${OSACPI_MI_DIR}/acpi_lid.c		optional acpi
 ${OSACPI_MI_DIR}/acpi_package.c		optional acpi
diff --git a/sys/conf/kmod.mk b/sys/conf/kmod.mk
--- a/sys/conf/kmod.mk
+++ b/sys/conf/kmod.mk
@@ -275,7 +275,7 @@ MFILES?= kern/bus_if.m kern/device_if.m 
     bus/pccard/card_if.m bus/pccard/power_if.m bus/pci/pci_if.m \
     bus/pci/pcib_if.m \
     bus/ppbus/ppbus_if.m bus/smbus/smbus_if.m bus/usb/usb_if.m \
-    dev/disk/nata/ata_if.m \
+    dev/acpica5/acpi_if.m dev/disk/nata/ata_if.m \
     dev/sound/pcm/ac97_if.m dev/sound/pcm/channel_if.m \
     dev/sound/pcm/feeder_if.m dev/sound/pcm/mixer_if.m \
     libiconv/iconv_converter_if.m dev/agp/agp_if.m opencrypto/crypto_if.m
diff --git a/sys/dev/acpica5/Makefile b/sys/dev/acpica5/Makefile
--- a/sys/dev/acpica5/Makefile
+++ b/sys/dev/acpica5/Makefile
@@ -69,12 +69,14 @@ SRCS+=  acpi_package.c
 # SRCS+=	acpi_pci.c acpi_pcib.c acpi_pcib_acpi.c acpi_pcib_pci.c
 # SRCS+=	acpi_pci_link.c
 SRCS+=  acpi_powerres.c acpi_resource.c acpi_thermal.c
-SRCS+=  acpi_timer.c
+SRCS+=  acpi_timer.c acpi_if.c
 SRCS+=  OsdDebug.c
 SRCS+=  OsdHardware.c OsdInterface.c OsdInterrupt.c OsdMemory.c OsdSchedule.c
 SRCS+=  OsdStream.c OsdSynch.c OsdTable.c OsdEnvironment.c
 SRCS+=  opt_acpi.h opt_bus.h opt_ddb.h
-SRCS+=  device_if.h bus_if.h pci_if.h pcib_if.h isa_if.h
+SRCS+=  device_if.h bus_if.h pci_if.h pcib_if.h isa_if.h acpi_if.h
+MFILES = kern/device_if.m kern/bus_if.m bus/pci/pci_if.m bus/pci/pcib_if.m
+MFILES+= bus/isa/isa_if.m dev/acpica5/acpi_if.m
 
 # Debugging support
 DBSRC=	dbcmds.c dbdisply.c dbexec.c dbfileio.c dbhistry.c
diff --git a/sys/dev/acpica5/acpi.c b/sys/dev/acpica5/acpi.c
--- a/sys/dev/acpica5/acpi.c
+++ b/sys/dev/acpica5/acpi.c
@@ -135,6 +135,7 @@ static int	acpi_release_resource(device_
 			int rid, struct resource *r);
 static uint32_t	acpi_isa_get_logicalid(device_t dev);
 static int	acpi_isa_get_compatid(device_t dev, uint32_t *cids, int count);
+static char	*acpi_device_id_probe(device_t bus, device_t dev, char **ids);
 static int	acpi_isa_pnp_probe(device_t bus, device_t child,
 			struct isa_pnp_id *ids);
 static void	acpi_probe_children(device_t bus);
@@ -189,6 +190,9 @@ static device_method_t acpi_methods[] = 
     DEVMETHOD(bus_deactivate_resource,	bus_generic_deactivate_resource),
     DEVMETHOD(bus_setup_intr,		bus_generic_setup_intr),
     DEVMETHOD(bus_teardown_intr,	bus_generic_teardown_intr),
+
+    /* ACPI bus */
+    DEVMETHOD(acpi_id_probe,		acpi_device_id_probe),
 
     /* ISA emulation */
     DEVMETHOD(isa_pnp_probe,		acpi_isa_pnp_probe),
@@ -1121,6 +1125,24 @@ out:
 	AcpiOsFree(buf.Pointer);
     ACPI_UNLOCK;
     return_VALUE (valid);
+}
+
+static char *
+acpi_device_id_probe(device_t bus, device_t dev, char **ids) 
+{
+    ACPI_HANDLE h;
+    int i;
+
+    h = acpi_get_handle(dev);
+    if (ids == NULL || h == NULL || acpi_get_type(dev) != ACPI_TYPE_DEVICE)
+	return (NULL);
+
+    /* Try to match one of the array of IDs with a HID or CID. */
+    for (i = 0; ids[i] != NULL; i++) {
+	if (acpi_MatchHid(h, ids[i]))
+	    return (ids[i]);
+    }
+    return (NULL);
 }
 
 static int
diff --git a/sys/dev/acpica5/acpi_ec.c b/sys/dev/acpica5/acpi_ec.c
--- a/sys/dev/acpica5/acpi_ec.c
+++ b/sys/dev/acpica5/acpi_ec.c
@@ -327,11 +327,19 @@ static ACPI_STATUS	EcWrite(struct acpi_e
 				UINT8 *Data);
 static int		acpi_ec_probe(device_t dev);
 static int		acpi_ec_attach(device_t dev);
+static int		acpi_ec_read_method(device_t dev, u_int addr,
+				ACPI_INTEGER *val, int width);
+static int		acpi_ec_write_method(device_t dev, u_int addr,
+				ACPI_INTEGER val, int width);
 
 static device_method_t acpi_ec_methods[] = {
     /* Device interface */
     DEVMETHOD(device_probe,	acpi_ec_probe),
     DEVMETHOD(device_attach,	acpi_ec_attach),
+
+    /* Embedded controller interface */
+    DEVMETHOD(acpi_ec_read,     acpi_ec_read_method),
+    DEVMETHOD(acpi_ec_write,    acpi_ec_write_method),
 
     {0, 0}
 };
@@ -620,6 +628,33 @@ error:
 			     sc->ec_data_res);
     /* mtx_destroy(&sc->ec_mtx); */
     return (ENXIO);
+}
+
+/* Methods to allow other devices (e.g., smbat) to read/write EC space. */
+static int
+acpi_ec_read_method(device_t dev, u_int addr, ACPI_INTEGER *val, int width)
+{
+    struct acpi_ec_softc *sc;
+    ACPI_STATUS status;
+
+    sc = device_get_softc(dev);
+    status = EcSpaceHandler(ACPI_READ, addr, width * 8, val, sc, NULL);
+    if (ACPI_FAILURE(status))
+        return (ENXIO);
+    return (0);
+}
+
+static int
+acpi_ec_write_method(device_t dev, u_int addr, ACPI_INTEGER val, int width)
+{
+    struct acpi_ec_softc *sc;
+    ACPI_STATUS status;
+
+    sc = device_get_softc(dev);
+    status = EcSpaceHandler(ACPI_WRITE, addr, width * 8, &val, sc, NULL);
+    if (ACPI_FAILURE(status))
+        return (ENXIO);
+    return (0);
 }
 
 static void
diff --git a/sys/dev/acpica5/acpi_if.m b/sys/dev/acpica5/acpi_if.m
new file mode 100644
--- /dev/null
+++ b/sys/dev/acpica5/acpi_if.m
@@ -0,0 +1,92 @@
+#-
+# Copyright (c) 2004 Nate Lawson
+# All rights reserved.
+#
+# Redistribution and use in source and binary forms, with or without
+# modification, are permitted provided that the following conditions
+# are met:
+# 1. Redistributions of source code must retain the above copyright
+#    notice, this list of conditions and the following disclaimer.
+# 2. Redistributions in binary form must reproduce the above copyright
+#    notice, this list of conditions and the following disclaimer in the
+#    documentation and/or other materials provided with the distribution.
+#
+# THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
+# ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+# ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
+# FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+# DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+# OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+# HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+# LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+# OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+# SUCH DAMAGE.
+#
+# $DragonFly$
+#
+
+#include <sys/bus.h>
+#include <sys/types.h>
+#include "acpi.h"
+
+INTERFACE acpi;
+
+#
+# Default implementation for acpi_id_probe().
+#
+CODE {
+	static char *
+	acpi_generic_id_probe(device_t bus, device_t dev, char **ids)
+	{
+		return (NULL);
+	}
+};
+
+#
+# Check a device for a match in a list of ID strings.  The strings can be
+# EISA PNP IDs or ACPI _HID/_CID values.
+#
+# device_t bus:  parent bus for the device
+#
+# device_t dev:  device being considered
+#
+# char **ids:  array of ID strings to consider
+#
+# Returns:  ID string matched or NULL if no match
+#
+METHOD char * id_probe {
+	device_t	bus;
+	device_t	dev;
+	char		**ids;
+} DEFAULT acpi_generic_id_probe;
+
+#
+# Read embedded controller (EC) address space
+#
+# device_t dev:  EC device
+# u_int addr:  Address to read from in EC space
+# ACPI_INTEGER *val:  Location to store read value
+# int width:  Size of area to read in bytes
+#
+METHOD int ec_read {
+	device_t	dev;
+	u_int		addr;
+	ACPI_INTEGER	*val;
+	int		width;
+};
+
+#
+# Write embedded controller (EC) address space
+#
+# device_t dev:  EC device
+# u_int addr:  Address to write to in EC space
+# ACPI_INTEGER val:  Value to write
+# int width:  Size of value to write in bytes
+#
+METHOD int ec_write {
+	device_t	dev;
+	u_int		addr;
+	ACPI_INTEGER	val;
+	int		width;
+};
diff --git a/sys/dev/acpica5/acpivar.h b/sys/dev/acpica5/acpivar.h
--- a/sys/dev/acpica5/acpivar.h
+++ b/sys/dev/acpica5/acpivar.h
@@ -29,6 +29,7 @@
  * $DragonFly: src/sys/dev/acpica5/acpivar.h,v 1.12 2007/10/23 03:04:48 y0netan1 Exp $
  */
 
+#include "acpi_if.h"
 #include "bus_if.h"
 #include <sys/eventhandler.h>
 #include <sys/sysctl.h>
# HG changeset patch
# User Hasso Tepper <hasso at estpak.ee>
# Date 1205995474 -7200
# Branch HEAD
# Node ID c5db8d4a7c6b25a8576a8d42c5029aaf0e23bfb6
# Parent  5a6e2705cc95a340abf973ae5df73ef34e070b79
[mq]: adding-acpi-thinkpad.patch

diff --git a/sys/dev/acpica5/Makefile b/sys/dev/acpica5/Makefile
--- a/sys/dev/acpica5/Makefile
+++ b/sys/dev/acpica5/Makefile
@@ -117,7 +117,7 @@ acpi_wakecode.h: acpi_wakecode.S
 	${MAKE} -f ${SYSDIR}/${OSACPI_MD_DIR}/Makefile \
 		MAKESRCPATH=${SYSDIR}/${OSACPI_MD_DIR}
 
-SUBDIR=	acpi_toshiba
+SUBDIR=	acpi_toshiba acpi_thinkpad
 all: ${PROG} ${SUBDIR}
 
 # *.o file for each patched *.c file is created under the same directory,
diff --git a/sys/dev/acpica5/acpi_thinkpad/Makefile b/sys/dev/acpica5/acpi_thinkpad/Makefile
new file mode 100644
--- /dev/null
+++ b/sys/dev/acpica5/acpi_thinkpad/Makefile
@@ -0,0 +1,9 @@
+# $DragonFly$
+
+SYSDIR?=${.CURDIR}/../../..
+
+KMOD=		acpi_thinkpad
+CFLAGS+=	-I${.OBJDIR}/.. -I${.CURDIR}/..
+SRCS=		acpi_thinkpad.c opt_acpi.h device_if.h bus_if.h
+
+.include <bsd.kmod.mk>
diff --git a/sys/dev/acpica5/acpi_thinkpad/acpi_thinkpad.c b/sys/dev/acpica5/acpi_thinkpad/acpi_thinkpad.c
new file mode 100644
--- /dev/null
+++ b/sys/dev/acpica5/acpi_thinkpad/acpi_thinkpad.c
@@ -0,0 +1,1046 @@
+/*
+ * Copyright (c) 2004 Takanori Watanabe
+ * Copyright (c) 2005 Markus Brueffer <markus at FreeBSD.org>
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *    notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *    notice, this list of conditions and the following disclaimer in the
+ *    documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+ */
+
+/*
+ * Driver for extra ACPI-controlled gadgets found on IBM and Lenovo ThinkPad
+ * laptops. Inspired by the ibm-acpi and tpb projects which implement these
+ * features on Linux.
+ *
+ *   acpi-ibm: <http://ibm-acpi.sourceforge.net/>
+ *        tpb: <http://www.nongnu.org/tpb/>
+ */
+
+#include "opt_acpi.h"
+#include <sys/param.h>
+#include <sys/kernel.h>
+#include <sys/bus.h>
+#include <machine/cpufunc.h>
+#include <sys/module.h>
+/* #include <dev/led/led.h> */
+#include <sys/sensors.h>
+#include <sys/sysctl.h>
+#include <machine/clock.h>
+
+#include "acpi.h"
+#include "acpivar.h"
+#include "acpi_if.h"
+
+#define _COMPONENT	ACPI_OEM
+ACPI_MODULE_NAME("THINKPAD")
+
+/* Internal methods */
+#define ACPI_THINKPAD_METHOD_EVENTS		1
+#define ACPI_THINKPAD_METHOD_EVENTMASK		2
+#define ACPI_THINKPAD_METHOD_HOTKEY		3
+#define ACPI_THINKPAD_METHOD_BRIGHTNESS		4
+#define ACPI_THINKPAD_METHOD_VOLUME		5
+#define ACPI_THINKPAD_METHOD_MUTE		6
+#define ACPI_THINKPAD_METHOD_THINKLIGHT		7
+#define ACPI_THINKPAD_METHOD_BLUETOOTH		8
+#define ACPI_THINKPAD_METHOD_WLAN		9
+#define ACPI_THINKPAD_METHOD_FANSPEED		10
+#define ACPI_THINKPAD_METHOD_FANLEVEL		11
+#define ACPI_THINKPAD_METHOD_FANSTATUS		12
+#define ACPI_THINKPAD_METHOD_THERMAL		13
+
+/* Hotkeys/Buttons */
+#define THINKPAD_RTC_HOTKEY1			0x64
+#define   THINKPAD_RTC_MASK_HOME		(1 << 0)
+#define   THINKPAD_RTC_MASK_SEARCH		(1 << 1)
+#define   THINKPAD_RTC_MASK_MAIL		(1 << 2)
+#define   THINKPAD_RTC_MASK_WLAN		(1 << 5)
+#define THINKPAD_RTC_HOTKEY2			0x65
+#define   THINKPAD_RTC_MASK_THINKPAD		(1 << 3)
+#define   THINKPAD_RTC_MASK_ZOOM		(1 << 5)
+#define   THINKPAD_RTC_MASK_VIDEO		(1 << 6)
+#define   THINKPAD_RTC_MASK_HIBERNATE		(1 << 7)
+#define THINKPAD_RTC_THINKLIGHT			0x66
+#define   THINKPAD_RTC_MASK_THINKLIGHT		(1 << 4)
+#define THINKPAD_RTC_SCREENEXPAND		0x67
+#define   THINKPAD_RTC_MASK_SCREENEXPAND	(1 << 5)
+#define THINKPAD_RTC_BRIGHTNESS			0x6c
+#define   THINKPAD_RTC_MASK_BRIGHTNESS		(1 << 5)
+#define THINKPAD_RTC_VOLUME			0x6e
+#define   THINKPAD_RTC_MASK_VOLUME		(1 << 7)
+
+/* Embedded Controller registers */
+#define THINKPAD_EC_BRIGHTNESS			0x31
+#define   THINKPAD_EC_MASK_BRI			0x7
+#define THINKPAD_EC_VOLUME			0x30
+#define   THINKPAD_EC_MASK_VOL			0xf
+#define   THINKPAD_EC_MASK_MUTE			(1 << 6)
+#define THINKPAD_EC_FANSTATUS			0x2F
+#define   THINKPAD_EC_MASK_FANLEVEL		0x3f
+#define   THINKPAD_EC_MASK_FANDISENGAGED	(1 << 6)
+#define   THINKPAD_EC_MASK_FANSTATUS		(1 << 7)
+#define THINKPAD_EC_FANSPEED			0x84
+
+/* CMOS Commands */
+#define THINKPAD_CMOS_VOLUME_DOWN		0
+#define THINKPAD_CMOS_VOLUME_UP			1
+#define THINKPAD_CMOS_VOLUME_MUTE		2
+#define THINKPAD_CMOS_BRIGHTNESS_UP		4
+#define THINKPAD_CMOS_BRIGHTNESS_DOWN		5
+
+/* ACPI methods */
+#define THINKPAD_NAME_KEYLIGHT			"KBLT"
+#define THINKPAD_NAME_WLAN_BT_GET		"GBDC"
+#define THINKPAD_NAME_WLAN_BT_SET		"SBDC"
+#define   THINKPAD_NAME_MASK_BT			(1 << 1)
+#define   THINKPAD_NAME_MASK_WLAN		(1 << 2)
+#define THINKPAD_NAME_THERMAL_GET		"TMP7"
+#define THINKPAD_NAME_THERMAL_UPDT		"UPDT"
+
+#define THINKPAD_NAME_EVENTS_STATUS_GET		"DHKC"
+#define THINKPAD_NAME_EVENTS_MASK_GET		"DHKN"
+#define THINKPAD_NAME_EVENTS_STATUS_SET		"MHKC"
+#define THINKPAD_NAME_EVENTS_MASK_SET		"MHKM"
+#define THINKPAD_NAME_EVENTS_GET		"MHKP"
+#define THINKPAD_NAME_EVENTS_AVAILMASK		"MHKA"
+
+#define ABS(x) (((x) < 0)? -(x) : (x))
+
+struct acpi_thinkpad_softc {
+	device_t	dev;
+	ACPI_HANDLE	handle;
+
+	/* Embedded controller */
+	device_t	ec_dev;
+	ACPI_HANDLE	ec_handle;
+
+	/* CMOS */
+	ACPI_HANDLE	cmos_handle;
+
+	/* Fan status */
+	ACPI_HANDLE	fan_handle;
+	int		fan_levels;
+
+	/* Keylight commands and states */
+	ACPI_HANDLE	light_handle;
+	int		light_cmd_on;
+	int		light_cmd_off;
+	int		light_val;
+	int		light_get_supported;
+	int		light_set_supported;
+
+	/* led(4) interface */
+	struct cdev	*led_dev;
+	int		led_busy;
+	int		led_state;
+
+	int		wlan_bt_flags;
+	int		thermal_updt_supported;
+
+	unsigned int	events_availmask;
+	unsigned int	events_initialmask;
+	int		events_mask_supported;
+	int		events_enable;
+
+	/* sensors(9) related */
+	struct ksensordev sensordev;
+	struct ksensor sensors[9];	/* XXX: 8 thermal + fan */
+
+	struct sysctl_ctx_list	*sysctl_ctx;
+	struct sysctl_oid	*sysctl_tree;
+};
+
+static struct {
+	char	*name;
+	int	method;
+	char	*description;
+	int	access;
+} acpi_thinkpad_sysctls[] = {
+	{
+		.name		= "events",
+		.method		= ACPI_THINKPAD_METHOD_EVENTS,
+		.description	= "ACPI events enable",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "eventmask",
+		.method		= ACPI_THINKPAD_METHOD_EVENTMASK,
+		.description	= "ACPI eventmask",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "hotkey",
+		.method		= ACPI_THINKPAD_METHOD_HOTKEY,
+		.description	= "Key Status",
+		.access		= CTLTYPE_INT | CTLFLAG_RD
+	},
+	{
+		.name		= "lcd_brightness",
+		.method		= ACPI_THINKPAD_METHOD_BRIGHTNESS,
+		.description	= "LCD Brightness",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "volume",
+		.method		= ACPI_THINKPAD_METHOD_VOLUME,
+		.description	= "Volume",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "mute",
+		.method		= ACPI_THINKPAD_METHOD_MUTE,
+		.description	= "Mute",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "thinklight",
+		.method		= ACPI_THINKPAD_METHOD_THINKLIGHT,
+		.description	= "Thinklight enable",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "bluetooth",
+		.method		= ACPI_THINKPAD_METHOD_BLUETOOTH,
+		.description	= "Bluetooth enable",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "wlan",
+		.method		= ACPI_THINKPAD_METHOD_WLAN,
+		.description	= "WLAN enable",
+		.access		= CTLTYPE_INT | CTLFLAG_RD
+	},
+	{
+		.name		= "fan_level",
+		.method		= ACPI_THINKPAD_METHOD_FANLEVEL,
+		.description	= "Fan level",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "fan",
+		.method		= ACPI_THINKPAD_METHOD_FANSTATUS,
+		.description	= "Fan enable",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+
+	{ NULL, 0, NULL, 0 }
+};
+
+/* ACPI_SERIAL_DECL(thinkpad, "ACPI THINKPAD extras"); */
+static int	acpi_thinkpad_probe(device_t dev);
+static int	acpi_thinkpad_attach(device_t dev);
+static int	acpi_thinkpad_detach(device_t dev);
+
+#if 0 /* not yet */
+static void	thinkpad_led(void *softc, int onoff);
+static void	thinkpad_led_task(struct acpi_thinkpad_softc *sc,
+		int pending __unused);
+#endif
+
+static int	acpi_thinkpad_sysctl(SYSCTL_HANDLER_ARGS);
+static int	acpi_thinkpad_sysctl_init(struct acpi_thinkpad_softc *sc,
+		int method);
+static int	acpi_thinkpad_sysctl_get(struct acpi_thinkpad_softc *sc,
+		int method);
+static int	acpi_thinkpad_sysctl_set(struct acpi_thinkpad_softc *sc,
+		int method, int val);
+
+static int	acpi_thinkpad_eventmask_set(struct acpi_thinkpad_softc *sc,
+		int val);
+static void	acpi_thinkpad_notify(ACPI_HANDLE h, UINT32 notify,
+		void *context);
+static void	acpi_thinkpad_refresh(void *);
+
+static device_method_t acpi_thinkpad_methods[] = {
+	/* Device interface */
+	DEVMETHOD(device_probe, acpi_thinkpad_probe),
+	DEVMETHOD(device_attach, acpi_thinkpad_attach),
+	DEVMETHOD(device_detach, acpi_thinkpad_detach),
+	{0, 0}
+};
+
+static driver_t	acpi_thinkpad_driver = {
+	"acpi_thinkpad",
+	acpi_thinkpad_methods,
+	sizeof(struct acpi_thinkpad_softc),
+};
+
+static devclass_t acpi_thinkpad_devclass;
+
+DRIVER_MODULE(acpi_thinkpad, acpi, acpi_thinkpad_driver,
+    acpi_thinkpad_devclass, 0, 0);
+MODULE_DEPEND(acpi_thinkpad, acpi, 1, 1, 1);
+static char    *thinkpad_ids[] = {"IBM0068", NULL};
+
+#if 0 /* not yet */
+static void
+thinkpad_led(void *softc, int onoff)
+{
+	struct acpi_thinkpad_softc* sc = (struct acpi_thinkpad_softc*) softc;
+
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+
+	if (sc->led_busy)
+		return;
+
+	sc->led_busy = 1;
+	sc->led_state = onoff;
+
+	AcpiOsExecute(OSL_NOTIFY_HANDLER, (void *)thinkpad_led_task, sc);
+}
+
+static void
+thinkpad_led_task(struct acpi_thinkpad_softc *sc, int pending __unused)
+{
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+
+	/* ACPI_SERIAL_BEGIN(thinkpad); */
+	acpi_thinkpad_sysctl_set(sc, ACPI_THINKPAD_METHOD_THINKLIGHT, sc->led_state);
+	/* ACPI_SERIAL_END(thinkpad); */
+
+	sc->led_busy = 0;
+}
+#endif
+
+static int
+acpi_thinkpad_probe(device_t dev)
+{
+	if (acpi_disabled("thinkpad") ||
+	    ACPI_ID_PROBE(device_get_parent(dev), dev, thinkpad_ids) == NULL ||
+	    device_get_unit(dev) != 0) 
+		return (ENXIO);
+
+	device_set_desc(dev, "IBM/Lenovo ThinkPad ACPI Extras");
+	return (0);
+}
+
+static int
+acpi_thinkpad_attach(device_t dev)
+{
+	struct acpi_thinkpad_softc	*sc;
+	struct acpi_softc	*acpi_sc;
+	devclass_t		ec_devclass;
+	int			i;
+
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t) __func__);
+
+	sc = device_get_softc(dev);
+	sc->dev = dev;
+	sc->handle = acpi_get_handle(dev);
+
+	acpi_sc = acpi_device_get_parent_softc(dev);
+
+	/* Look for the first embedded controller */
+        if (!(ec_devclass = devclass_find ("acpi_ec"))) {
+		if (bootverbose)
+			device_printf(dev, "Couldn't find acpi_ec devclass\n");
+		return (EINVAL);
+	}
+        if (!(sc->ec_dev = devclass_get_device(ec_devclass, 0))) {
+		if (bootverbose)
+			device_printf(dev, "Couldn't find acpi_ec device\n");
+		return (EINVAL);
+	}
+	sc->ec_handle = acpi_get_handle(sc->ec_dev);
+
+	/* ACPI_SERIAL_BEGIN(thinkpad); */
+
+#if 0
+	/* Get the sysctl tree */
+	sc->sysctl_ctx = device_get_sysctl_ctx(dev);
+	sc->sysctl_tree = device_get_sysctl_tree(dev);
+#endif
+	sysctl_ctx_init(sc->sysctl_ctx);
+	sc->sysctl_tree = SYSCTL_ADD_NODE(sc->sysctl_ctx,
+	    SYSCTL_CHILDREN(acpi_sc->acpi_sysctl_tree), OID_AUTO,
+	    "thinkpad", CTLFLAG_RD, 0, "");
+
+	/* Look for event mask and hook up the nodes */
+	sc->events_mask_supported = ACPI_SUCCESS(acpi_GetInteger(sc->handle,
+	    THINKPAD_NAME_EVENTS_MASK_GET, &sc->events_initialmask));
+
+	if (sc->events_mask_supported) {
+		SYSCTL_ADD_INT(sc->sysctl_ctx,
+		    SYSCTL_CHILDREN(sc->sysctl_tree), OID_AUTO,
+		    "initialmask", CTLFLAG_RD,
+		    &sc->events_initialmask, 0, "Initial eventmask");
+
+		/* The availmask is the bitmask of supported events */
+		if (ACPI_FAILURE(acpi_GetInteger(sc->handle,
+		    THINKPAD_NAME_EVENTS_AVAILMASK, &sc->events_availmask)))
+			sc->events_availmask = 0xffffffff;
+
+		SYSCTL_ADD_INT(sc->sysctl_ctx,
+		    SYSCTL_CHILDREN(sc->sysctl_tree), OID_AUTO,
+		    "availmask", CTLFLAG_RD,
+		    &sc->events_availmask, 0, "Mask of supported events");
+	}
+
+	/* Hook up proc nodes */
+	for (i = 0; acpi_thinkpad_sysctls[i].name != NULL; i++) {
+		if (!acpi_thinkpad_sysctl_init(sc,
+		    acpi_thinkpad_sysctls[i].method))
+			continue;
+
+		SYSCTL_ADD_PROC(sc->sysctl_ctx,
+		    SYSCTL_CHILDREN(sc->sysctl_tree), OID_AUTO,
+		    acpi_thinkpad_sysctls[i].name,
+		    acpi_thinkpad_sysctls[i].access,
+		    sc, i, acpi_thinkpad_sysctl, "I",
+		    acpi_thinkpad_sysctls[i].description);
+	}
+
+	/* ACPI_SERIAL_END(thinkpad); */
+
+	/* Handle notifies */
+	AcpiInstallNotifyHandler(sc->handle, ACPI_DEVICE_NOTIFY,
+	    acpi_thinkpad_notify, dev);
+
+#if 0
+	/* Hook up light to led(4) */
+	if (sc->light_set_supported)
+		sc->led_dev = led_create_state(thinkpad_led, sc, "thinklight",
+		    sc->light_val);
+#endif
+	/* Attach sensors(9). */
+	if (sensor_task_register(sc, acpi_thinkpad_refresh, 5)) {
+		device_printf(sc->dev, "unable to register update task\n");
+		return 1;
+	}
+
+	strlcpy(sc->sensordev.xname, device_get_nameunit(sc->dev),
+	    sizeof(sc->sensordev.xname));
+
+	/* XXX: Temp sensors */
+	for (i = 0; i < 8; ++i) {
+		sc->sensors[i].type = SENSOR_TEMP;
+		sensor_attach(&sc->sensordev, &sc->sensors[i]);
+	}
+	
+	/* Fan RPM sensor */
+	sc->sensors[8].type = SENSOR_FANRPM;
+	sensor_attach(&sc->sensordev, &sc->sensors[8]);
+
+	sensordev_install(&sc->sensordev);
+
+	return (0);
+}
+
+static int
+acpi_thinkpad_detach(device_t dev)
+{
+	int i;
+
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t) __func__);
+
+	struct acpi_thinkpad_softc *sc = device_get_softc(dev);
+
+	/* Disable events and restore eventmask */
+	/* ACPI_SERIAL_BEGIN(thinkpad); */
+	acpi_thinkpad_sysctl_set(sc, ACPI_THINKPAD_METHOD_EVENTS, 0);
+	acpi_thinkpad_sysctl_set(sc, ACPI_THINKPAD_METHOD_EVENTMASK,
+	    sc->events_initialmask);
+	/* ACPI_SERIAL_END(thinkpad); */
+
+	AcpiRemoveNotifyHandler(sc->handle, ACPI_DEVICE_NOTIFY,
+	    acpi_thinkpad_notify);
+
+	sysctl_ctx_free(sc->sysctl_ctx);
+
+#if 0
+	if (sc->led_dev != NULL)
+		led_destroy(sc->led_dev);
+#endif
+	sensordev_deinstall(&sc->sensordev);
+	for (i = 0; i < 9; i++)
+		sensor_detach(&sc->sensordev, &sc->sensors[i]);
+	sensor_task_unregister(sc);
+
+	return (0);
+}
+
+static int
+acpi_thinkpad_eventmask_set(struct acpi_thinkpad_softc *sc, int val)
+{
+	int i;
+	ACPI_OBJECT		arg[2];
+	ACPI_OBJECT_LIST	args;
+	ACPI_STATUS		status;
+
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+	/* ACPI_SERIAL_ASSERT(thinkpad); */
+
+	args.Count = 2;
+	args.Pointer = arg;
+	arg[0].Type = ACPI_TYPE_INTEGER;
+	arg[1].Type = ACPI_TYPE_INTEGER;
+
+	for (i = 0; i < 32; ++i) {
+		arg[0].Integer.Value = i+1;
+		arg[1].Integer.Value = (((1 << i) & val) != 0);
+		status = AcpiEvaluateObject(sc->handle,
+		    THINKPAD_NAME_EVENTS_MASK_SET, &args, NULL);
+
+		if (ACPI_FAILURE(status))
+			return (status);
+	}
+
+	return (0);
+}
+
+static int
+acpi_thinkpad_sysctl(SYSCTL_HANDLER_ARGS)
+{
+	struct acpi_thinkpad_softc	*sc;
+	int			arg;
+	int			error = 0;
+	int			function;
+	int			method;
+	
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+
+	sc = (struct acpi_thinkpad_softc *)oidp->oid_arg1;
+	function = oidp->oid_arg2;
+	method = acpi_thinkpad_sysctls[function].method;
+
+	/* ACPI_SERIAL_BEGIN(thinkpad); */
+	arg = acpi_thinkpad_sysctl_get(sc, method);
+	error = sysctl_handle_int(oidp, &arg, 0, req);
+
+	/* Sanity check */
+	if (error != 0 || req->newptr == NULL)
+		goto out;
+
+	/* Update */
+	error = acpi_thinkpad_sysctl_set(sc, method, arg);
+
+out:
+	/* ACPI_SERIAL_END(thinkpad); */
+	return (error);
+}
+
+static int
+acpi_thinkpad_sysctl_get(struct acpi_thinkpad_softc *sc, int method)
+{
+	ACPI_INTEGER	val_ec;
+	int 		val = 0, key;
+
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+	/* ACPI_SERIAL_ASSERT(thinkpad); */
+
+	switch (method) {
+	case ACPI_THINKPAD_METHOD_EVENTS:
+		acpi_GetInteger(sc->handle, THINKPAD_NAME_EVENTS_STATUS_GET,
+		    &val);
+		break;
+
+	case ACPI_THINKPAD_METHOD_EVENTMASK:
+		if (sc->events_mask_supported)
+			acpi_GetInteger(sc->handle,
+			    THINKPAD_NAME_EVENTS_MASK_GET, &val);
+		break;
+
+	case ACPI_THINKPAD_METHOD_HOTKEY:
+		/*
+		 * Construct the hotkey as a bitmask as illustrated below.
+		 * Note that whenever a key was pressed, the respecting bit
+		 * toggles and nothing else changes.
+		 * +--+--+-+-+-+-+-+-+-+-+-+-+
+		 * |11|10|9|8|7|6|5|4|3|2|1|0|
+		 * +--+--+-+-+-+-+-+-+-+-+-+-+
+		 *   |  | | | | | | | | | | |
+		 *   |  | | | | | | | | | | +- Home Button
+		 *   |  | | | | | | | | | +--- Search Button
+		 *   |  | | | | | | | | +----- Mail Button
+		 *   |  | | | | | | | +------- Thinkpad Button
+		 *   |  | | | | | | +--------- Zoom (Fn + Space)
+		 *   |  | | | | | +----------- WLAN Button
+		 *   |  | | | | +------------- Video Button
+		 *   |  | | | +--------------- Hibernate Button
+		 *   |  | | +----------------- Thinklight Button
+		 *   |  | +------------------- Screen expand (Fn + F8)
+		 *   |  +--------------------- Brightness
+		 *   +------------------------ Volume/Mute
+		 */
+		key = rtcin(THINKPAD_RTC_HOTKEY1);
+		val = (THINKPAD_RTC_MASK_HOME | THINKPAD_RTC_MASK_SEARCH |
+		    THINKPAD_RTC_MASK_MAIL | THINKPAD_RTC_MASK_WLAN) & key;
+		key = rtcin(THINKPAD_RTC_HOTKEY2);
+		val |= (THINKPAD_RTC_MASK_THINKPAD | THINKPAD_RTC_MASK_VIDEO |
+		    THINKPAD_RTC_MASK_HIBERNATE) & key;
+		val |= (THINKPAD_RTC_MASK_ZOOM & key) >> 1;
+		key = rtcin(THINKPAD_RTC_THINKLIGHT);
+		val |= (THINKPAD_RTC_MASK_THINKLIGHT & key) << 4;
+		key = rtcin(THINKPAD_RTC_SCREENEXPAND);
+		val |= (THINKPAD_RTC_MASK_THINKLIGHT & key) << 4;
+		key = rtcin(THINKPAD_RTC_BRIGHTNESS);
+		val |= (THINKPAD_RTC_MASK_BRIGHTNESS & key) << 5;
+		key = rtcin(THINKPAD_RTC_VOLUME);
+		val |= (THINKPAD_RTC_MASK_VOLUME & key) << 4;
+		break;
+
+	case ACPI_THINKPAD_METHOD_BRIGHTNESS:
+		ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_BRIGHTNESS, &val_ec, 1);
+		val = val_ec & THINKPAD_EC_MASK_BRI;
+		break;
+
+	case ACPI_THINKPAD_METHOD_VOLUME:
+		ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_VOLUME, &val_ec, 1);
+		val = val_ec & THINKPAD_EC_MASK_VOL;
+		break;
+
+	case ACPI_THINKPAD_METHOD_MUTE:
+		val = ((val_ec & THINKPAD_EC_MASK_MUTE) ==
+		    THINKPAD_EC_MASK_MUTE);
+		break;
+
+	case ACPI_THINKPAD_METHOD_THINKLIGHT:
+		if (sc->light_get_supported)
+			acpi_GetInteger(sc->ec_handle, THINKPAD_NAME_KEYLIGHT,
+			    &val);
+		else
+			val = sc->light_val;
+		break;
+
+	case ACPI_THINKPAD_METHOD_BLUETOOTH:
+		acpi_GetInteger(sc->handle, THINKPAD_NAME_WLAN_BT_GET, &val);
+		sc->wlan_bt_flags = val;
+		val = ((val & THINKPAD_NAME_MASK_BT) != 0);
+		break;
+
+	case ACPI_THINKPAD_METHOD_WLAN:
+		acpi_GetInteger(sc->handle, THINKPAD_NAME_WLAN_BT_GET, &val);
+		sc->wlan_bt_flags = val;
+		val = ((val & THINKPAD_NAME_MASK_WLAN) != 0);
+		break;
+
+	case ACPI_THINKPAD_METHOD_FANSPEED:
+		if (sc->fan_handle) {
+			if (ACPI_FAILURE(acpi_GetInteger(sc->fan_handle,
+			    NULL, &val)))
+				val = -1;
+		}
+		else {
+			ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_FANSPEED,
+			    &val_ec, 2);
+			val = val_ec;
+		}
+		break;
+
+	case ACPI_THINKPAD_METHOD_FANLEVEL:
+		/*
+		 * The THINKPAD_EC_FANSTATUS register works as follows:
+		 * Bit 0-5 indicate the level at which the fan operates. Only
+		 *       values between 0 and 7 have an effect. Everything
+		 *       above 7 is treated the same as level 7
+		 * Bit 6 overrides the fan speed limit if set to 1
+		 * Bit 7 indicates at which mode the fan operates:
+		 *       manual (0) or automatic (1)
+		 */
+		if (!sc->fan_handle) {
+			ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_FANSTATUS,
+			    &val_ec, 1);
+			val = val_ec & THINKPAD_EC_MASK_FANLEVEL;
+		}
+		break;
+
+	case ACPI_THINKPAD_METHOD_FANSTATUS:
+		if (!sc->fan_handle) {
+			ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_FANSTATUS,
+			    &val_ec, 1);
+			val = (val_ec & THINKPAD_EC_MASK_FANSTATUS) ==
+			    THINKPAD_EC_MASK_FANSTATUS;
+		}
+		else
+			val = -1;
+		break;
+	}
+
+	return (val);
+}
+
+static int
+acpi_thinkpad_sysctl_set(struct acpi_thinkpad_softc *sc, int method, int arg)
+{
+	int			val, step, i;
+	ACPI_INTEGER		val_ec;
+	ACPI_OBJECT		Arg;
+	ACPI_OBJECT_LIST	Args;
+	ACPI_STATUS		status;
+
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+	/* ACPI_SERIAL_ASSERT(thinkpad); */
+
+	switch (method) {
+	case ACPI_THINKPAD_METHOD_EVENTS:
+		if (arg < 0 || arg > 1)
+			return (EINVAL);
+
+		status = acpi_SetInteger(sc->handle,
+		    THINKPAD_NAME_EVENTS_STATUS_SET, arg);
+		if (ACPI_FAILURE(status))
+			return (status);
+		if (sc->events_mask_supported)
+			return acpi_thinkpad_eventmask_set(sc,
+			    sc->events_availmask);
+		break;
+
+	case ACPI_THINKPAD_METHOD_EVENTMASK:
+		if (sc->events_mask_supported)
+			return acpi_thinkpad_eventmask_set(sc, arg);
+		break;
+
+	case ACPI_THINKPAD_METHOD_BRIGHTNESS:
+		if (arg < 0 || arg > 7)
+			return (EINVAL);
+
+		if (sc->cmos_handle) {
+			/* Read the current brightness */
+			status = ACPI_EC_READ(sc->ec_dev,
+			    THINKPAD_EC_BRIGHTNESS, &val_ec, 1);
+			if (ACPI_FAILURE(status))
+				return (status);
+			val = val_ec & THINKPAD_EC_MASK_BRI;
+
+			Args.Count = 1;
+			Args.Pointer = &Arg;
+			Arg.Type = ACPI_TYPE_INTEGER;
+			Arg.Integer.Value = (arg > val) ?
+			    THINKPAD_CMOS_BRIGHTNESS_UP :
+			    THINKPAD_CMOS_BRIGHTNESS_DOWN;
+
+			step = (arg > val) ? 1 : -1;
+			for (i = val; i != arg; i += step) {
+				status = AcpiEvaluateObject(sc->cmos_handle,
+				    NULL, &Args, NULL);
+				if (ACPI_FAILURE(status))
+					break;
+			}
+		}
+		return ACPI_EC_WRITE(sc->ec_dev, THINKPAD_EC_BRIGHTNESS,
+		    arg, 1);
+		break;
+
+	case ACPI_THINKPAD_METHOD_VOLUME:
+		if (arg < 0 || arg > 14)
+			return (EINVAL);
+
+		status = ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_VOLUME,
+		    &val_ec, 1);
+		if (ACPI_FAILURE(status))
+			return (status);
+
+		if (sc->cmos_handle) {
+			val = val_ec & THINKPAD_EC_MASK_VOL;
+
+			Args.Count = 1;
+			Args.Pointer = &Arg;
+			Arg.Type = ACPI_TYPE_INTEGER;
+			Arg.Integer.Value = (arg > val) ?
+			    THINKPAD_CMOS_VOLUME_UP : THINKPAD_CMOS_VOLUME_DOWN;
+
+			step = (arg > val) ? 1 : -1;
+			for (i = val; i != arg; i += step) {
+				status = AcpiEvaluateObject(sc->cmos_handle,
+				    NULL, &Args, NULL);
+				if (ACPI_FAILURE(status))
+					break;
+			}
+		}
+		return ACPI_EC_WRITE(sc->ec_dev, THINKPAD_EC_VOLUME, arg +
+		    (val_ec & (~THINKPAD_EC_MASK_VOL)), 1);
+		break;
+
+	case ACPI_THINKPAD_METHOD_MUTE:
+		if (arg < 0 || arg > 1)
+			return (EINVAL);
+
+		status = ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_VOLUME,
+		    &val_ec, 1);
+		if (ACPI_FAILURE(status))
+			return (status);
+
+		if (sc->cmos_handle) {
+			val = val_ec & THINKPAD_EC_MASK_VOL;
+
+			Args.Count = 1;
+			Args.Pointer = &Arg;
+			Arg.Type = ACPI_TYPE_INTEGER;
+			Arg.Integer.Value = THINKPAD_CMOS_VOLUME_MUTE;
+
+			status = AcpiEvaluateObject(sc->cmos_handle, NULL,
+			    &Args, NULL);
+			if (ACPI_FAILURE(status))
+				break;
+		}
+		return ACPI_EC_WRITE(sc->ec_dev, THINKPAD_EC_VOLUME, (arg==1) ?
+		   val_ec | THINKPAD_EC_MASK_MUTE :
+		   val_ec & (~THINKPAD_EC_MASK_MUTE), 1);
+		break;
+
+	case ACPI_THINKPAD_METHOD_THINKLIGHT:
+		if (arg < 0 || arg > 1)
+			return (EINVAL);
+
+		if (sc->light_set_supported) {
+			Args.Count = 1;
+			Args.Pointer = &Arg;
+			Arg.Type = ACPI_TYPE_INTEGER;
+			Arg.Integer.Value = arg ?
+			    sc->light_cmd_on : sc->light_cmd_off;
+
+			status = AcpiEvaluateObject(sc->light_handle, NULL,
+			    &Args, NULL);
+			if (ACPI_SUCCESS(status))
+				sc->light_val = arg;
+			return (status);
+		}
+		break;
+
+	case ACPI_THINKPAD_METHOD_BLUETOOTH:
+		if (arg < 0 || arg > 1)
+			return (EINVAL);
+
+		val = (arg == 1) ? sc->wlan_bt_flags |
+		    THINKPAD_NAME_MASK_BT :
+		    sc->wlan_bt_flags & (~THINKPAD_NAME_MASK_BT);
+		return acpi_SetInteger(sc->handle, THINKPAD_NAME_WLAN_BT_SET,
+		    val);
+		break;
+
+	case ACPI_THINKPAD_METHOD_FANLEVEL:
+		if (arg < 0 || arg > 7)
+			return (EINVAL);
+
+		if (!sc->fan_handle) {
+			/* Read the current fanstatus */
+			ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_FANSTATUS,
+			    &val_ec, 1);
+			val = val_ec & (~THINKPAD_EC_MASK_FANLEVEL);
+
+			return ACPI_EC_WRITE(sc->ec_dev, THINKPAD_EC_FANSTATUS,
+			    val | arg, 1);
+		}
+		break;
+
+	case ACPI_THINKPAD_METHOD_FANSTATUS:
+		if (arg < 0 || arg > 1)
+			return (EINVAL);
+
+		if (!sc->fan_handle) {
+			/* Read the current fanstatus */
+			ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_FANSTATUS,
+			    &val_ec, 1);
+
+			return ACPI_EC_WRITE(sc->ec_dev, THINKPAD_EC_FANSTATUS,
+			    (arg == 1) ? (val_ec | THINKPAD_EC_MASK_FANSTATUS) :
+			    (val_ec & (~THINKPAD_EC_MASK_FANSTATUS)), 1);
+		}
+		break;
+	}
+
+	return (0);
+}
+
+static int
+acpi_thinkpad_sysctl_init(struct acpi_thinkpad_softc *sc, int method)
+{
+	int 			dummy;
+	ACPI_OBJECT_TYPE 	cmos_t;
+	ACPI_HANDLE		ledb_handle;
+
+	switch (method) {
+	case ACPI_THINKPAD_METHOD_EVENTS:
+		/* Events are disabled by default */
+		return (TRUE);
+
+	case ACPI_THINKPAD_METHOD_EVENTMASK:
+		return (sc->events_mask_supported);
+
+	case ACPI_THINKPAD_METHOD_HOTKEY:
+	case ACPI_THINKPAD_METHOD_BRIGHTNESS:
+	case ACPI_THINKPAD_METHOD_VOLUME:
+	case ACPI_THINKPAD_METHOD_MUTE:
+		/* EC is required here, which was already checked before */
+		return (TRUE);
+
+	case ACPI_THINKPAD_METHOD_THINKLIGHT:
+		sc->cmos_handle = NULL;
+		sc->light_get_supported = ACPI_SUCCESS(acpi_GetInteger(
+		    sc->ec_handle, THINKPAD_NAME_KEYLIGHT, &sc->light_val));
+
+		if ((ACPI_SUCCESS(AcpiGetHandle(sc->handle, "\\UCMS",
+		    &sc->light_handle)) ||
+		    ACPI_SUCCESS(AcpiGetHandle(sc->handle, "\\CMOS",
+		    &sc->light_handle)) ||
+		    ACPI_SUCCESS(AcpiGetHandle(sc->handle, "\\CMS",
+		    &sc->light_handle))) &&
+		    ACPI_SUCCESS(AcpiGetType(sc->light_handle, &cmos_t)) &&
+		    cmos_t == ACPI_TYPE_METHOD) {
+			sc->light_cmd_on = 0x0c;
+			sc->light_cmd_off = 0x0d;
+			sc->cmos_handle = sc->light_handle;
+		}
+		else if (ACPI_SUCCESS(AcpiGetHandle(sc->handle, "\\LGHT",
+		    &sc->light_handle))) {
+			sc->light_cmd_on = 1;
+			sc->light_cmd_off = 0;
+		}
+		else
+			sc->light_handle = NULL;
+
+		sc->light_set_supported = (sc->light_handle &&
+		    ACPI_FAILURE(AcpiGetHandle(sc->ec_handle, "LEDB",
+		    &ledb_handle)));
+
+		if (sc->light_get_supported)
+			return (TRUE);
+
+		if (sc->light_set_supported) {
+			sc->light_val = 0;
+			return (TRUE);
+		}
+
+		return (FALSE);
+
+	case ACPI_THINKPAD_METHOD_BLUETOOTH:
+	case ACPI_THINKPAD_METHOD_WLAN:
+		if (ACPI_SUCCESS(acpi_GetInteger(sc->handle,
+		    THINKPAD_NAME_WLAN_BT_GET, &dummy)))
+			return (TRUE);
+		return (FALSE);
+
+	case ACPI_THINKPAD_METHOD_FANSPEED:
+		/* 
+		 * Some models report the fan speed in levels from 0-7
+		 * Newer models report it contiguously
+		 */
+		sc->fan_levels = (ACPI_SUCCESS(AcpiGetHandle(sc->handle, "GFAN",
+		    &sc->fan_handle)) ||
+		    ACPI_SUCCESS(AcpiGetHandle(sc->handle, "\\FSPD",
+		    &sc->fan_handle)));
+		return (TRUE);
+
+	case ACPI_THINKPAD_METHOD_FANLEVEL:
+	case ACPI_THINKPAD_METHOD_FANSTATUS:
+		/* 
+		 * Fan status is only supported on those models,
+		 * which report fan RPM contiguously, not in levels
+		 */
+		if (sc->fan_levels)
+			return (FALSE);
+		return (TRUE);
+
+	case ACPI_THINKPAD_METHOD_THERMAL:
+		if (ACPI_SUCCESS(acpi_GetInteger(sc->ec_handle,
+		    THINKPAD_NAME_THERMAL_GET, &dummy))) {
+			sc->thermal_updt_supported =
+			    ACPI_SUCCESS(acpi_GetInteger(sc->ec_handle,
+			    THINKPAD_NAME_THERMAL_UPDT, &dummy));
+			return (TRUE);
+		}
+		return (FALSE);
+	}
+	return (FALSE);
+}
+
+static void
+acpi_thinkpad_notify(ACPI_HANDLE h, UINT32 notify, void *context)
+{
+	int		event, arg, type;
+	device_t	dev = context;
+	struct acpi_thinkpad_softc *sc = device_get_softc(dev);
+
+	ACPI_FUNCTION_TRACE_U32((char *)(uintptr_t)__func__, notify);
+
+	if (notify != 0x80)
+		device_printf(dev, "Unknown notify\n");
+
+	for (;;) {
+		acpi_GetInteger(acpi_get_handle(dev), THINKPAD_NAME_EVENTS_GET,
+		    &event);
+
+		if (event == 0)
+			break;
+
+		type = (event >> 12) & 0xf;
+		arg = event & 0xfff;
+		switch (type) {
+		case 1:
+			if (!(sc->events_availmask & (1 << (arg - 1)))) {
+				device_printf(dev, "Unknown key %d\n", arg);
+				break;
+			}
+
+			/* Notify devd(8) */
+			device_printf(dev, "THINKPAD event: %u\n",
+			    (arg & 0xff));
+			acpi_UserNotify("THINKPAD", h, (arg & 0xff));
+			break;
+		default:
+			break;
+		}
+	}
+}
+
+static void
+acpi_thinkpad_refresh(void *arg)
+{
+	struct acpi_thinkpad_softc *sc = (struct acpi_thinkpad_softc *)arg;
+	char temp_cmd[] = "TMP0";
+	int data, i;
+	ACPI_INTEGER speed;
+
+	for (i = 0; i < 8; i++) {
+		temp_cmd[3] = '0' + i;
+		
+                /*
+                 * The TMPx methods seem to return +/- 128 or 0
+                 * when the respecting sensor is not available
+                 */
+		sc->sensors[i].flags &= ~SENSOR_FINVALID;
+                if (ACPI_FAILURE(acpi_GetInteger(sc->ec_handle, temp_cmd,
+                    &data)) || ABS(data) == 128 || data == 0) {
+			sc->sensors[i].flags |= SENSOR_FINVALID;
+                        data = 0;
+		}
+                else if (sc->thermal_updt_supported) {
+                        /* XXX: Temperature is reported in tenth of Kelvin */
+                        data = (data - 2732 + 5) / 10;
+		}
+		sc->sensors[i].value = data * 1000000 + 273150000;
+        }
+	
+	sc->sensors[8].flags &= ~SENSOR_FINVALID;
+	if (sc->fan_handle) {
+		if (ACPI_FAILURE(acpi_GetInteger(sc->fan_handle,
+		    NULL, &data)))
+			sc->sensors[8].flags |= SENSOR_FINVALID;
+                        data = -1;
+        }
+        else {
+                ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_FANSPEED, &speed, 2);
+                data = speed;
+        }
+
+	sc->sensors[8].value = data;
+}
diff --git a/sys/platform/pc32/conf/files b/sys/platform/pc32/conf/files
--- a/sys/platform/pc32/conf/files
+++ b/sys/platform/pc32/conf/files
@@ -72,6 +72,7 @@ dev/serial/dgb/dgm.c			optional	dgm
 ${OSACPI_MD_DIR}/acpi_machdep.c		optional        acpi
 ${OSACPI_MD_DIR}/acpi_wakeup.c		optional        acpi
 ${OSACPI_MD_DIR}/acpi_toshiba.c		optional        acpi_toshiba acpi
+${ACPICA_DIR}/acpi_thinkpad/acpi_thinkpad.c optional	acpi_thinkpad acpi
 acpi.h					optional	acpi		\
 	dependency	"$S/${ACPICA_DIR}/include/acpi.h"		\
 	compile-with	"cp $S/${ACPICA_DIR}/include/acpi.h ${.OBJDIR}/"	\



From hasso at estpak.ee  Thu Mar 20 03:49:13 2008
From: hasso at estpak.ee (Hasso Tepper)
Date: Thu, 20 Mar 2008 03:49:13 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Some questions regarding ACPI
In-Reply-To: <200803191322.46366.hasso@estpak.ee>
Message-ID: <200803201237.28823.hasso@estpak.ee>

Hasso Tepper wrote:
> There is also one fatal issue -laptop locks up hardly (no panic) while 
> unloading module. Any idea regarding this is welcome.

Nevermind, solved.


-- 
Hasso




From dillon at apollo.backplane.com  Fri Mar 21 19:24:01 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Fri, 21 Mar 2008 19:24:01 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: panic: assertion: hammer_btree_cmp(cursor->left_bound,	&cursor->node->ondisk->elms[0].leaf.base) <= 0 in btree_split_leaf
In-Reply-To: <200802232204.m1NM4cxd046264@apollo.backplane.com>
Message-ID: <200803220212.m2M2CiAY014435@apollo.backplane.com>

:While trying to find a procedure to reliably reproduce the panic
:I reported last time, I caught a different panic (uploaded at
: ~y0netan1/crash/9/ on my leaf account).  I wrote the following shell
:script (make sure to edit variables DISKS and MOUNTPT before using this
:script or it may trash your system):

    Ok, I believe I have fixed the left_bound assertion.  I also believe
    I have fixed the node ref count assertion on umount.

    There is currently one unfixed assertion related to the I/O
    path... sometimes the bp is being improperly disassociated from the
    related HAMMER structure.

    The full-filesystem case is still not being handled so don't test that :-)

					    -Matt





From c.turner at 199technologies.org  Sun Mar 23 09:48:29 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Sun, 23 Mar 2008 09:48:29 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
Message-ID: <47E6870C.4080709@199technologies.org>

I'm finally getting around to doing 1.12 upgrades, and have setup a 
separate machine to do my bulk package builds / upgrades etc,
so as not to disrupt my 'dev server' while things are being
built / tested

However, this seems kind of wasteful - the only purpose of this machine
is to build packages against a specific release..
And since building packages for a particular release generally requires 
only the userland, appropriate headers and correct 'uname' output - so:

it seems like if spoofing uname is configured inside a jail,
the next (or previous..) release can be installed into a jail and
used for building / testing packages without the overhead of a VM or 
maintaining a separate physical host

I did a quick scan of the tree to see what this would take, and, high 
level, it seems like only the following changes would need to be made:

- update struct jail to add a 'osrelease' string
  (implies bumping 'jail api' to 2?)
- update jail(8) to actually pass this information along
- update sys_uname to test ucred for jailed processes, and
  use the struct jail osrelease if appropriate
- similarly update sysctl kern.osrelease to support jail spoofing
  (if possible - didn't get this far in the research yet)
  could be less of a problem for builds, as I think most things use
 uname(1) ... but good to keep the environment consistent I suppose..
I'm still a bit confused as to how 'osrelease' is defined - everything
I'm finding is showing up as extern char[] .. perhaps this is something 
in the build I'm not familiar with?

also,

is the so-called 'stupid hackery' in sys_uname needed still?

Before I start any coding, does this:

- sound like something useful
- sound like the right approach
Thinking this could have wider useful implications e.g. for pkgbox
& so on -  for example setting up automated bulks w/various combinations 
of pkgsrc and releases, etc.

Cheers,

- Chris





From corecode at fs.ei.tum.de  Sun Mar 23 10:06:38 2008
From: corecode at fs.ei.tum.de (Simon 'corecode' Schubert)
Date: Sun, 23 Mar 2008 10:06:38 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <47E68C74.3080808@fs.ei.tum.de>

Chris Turner wrote:
I did a quick scan of the tree to see what this would take, and, high 
level, it seems like only the following changes would need to be made:
brave investigation.  but you could also simply set UNAME_r :)

sweatshorts % uname -r
1.13.0-DEVELOPMENT
sweatshorts % UNAME_r=1.12-RELEASE uname -r
1.12-RELEASE
I think that's good enough :D

cheers
  simon
--
Serve - BSD     +++  RENT this banner advert  +++    ASCII Ribbon   /"\
Work - Mac      +++  space for low ????????? NOW!1  +++      Campaign     \ /
Party Enjoy Relax   |   http://dragonflybsd.org      Against  HTML   \
Dude 2c 2 the max   !   http://golden-apple.biz       Mail + News   / \




From c.turner at 199technologies.org  Sun Mar 23 10:50:13 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Sun, 23 Mar 2008 10:50:13 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <47E69656.8080605@199technologies.org>

Simon 'corecode' Schubert wrote:
brave investigation.  but you could also simply set UNAME_r :)
Doh! Thanks for the tip!

they should change the phrase from RTFM to 'Carefully RTFM' :)

well.. scratch that change then. 1 less patch to write.

- Chris





From c.turner at 199technologies.org  Sun Mar 23 11:15:52 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Sun, 23 Mar 2008 11:15:52 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <47E69C7C.8010109@199technologies.org>

Chris Turner wrote:
Simon 'corecode' Schubert wrote:
brave investigation.  but you could also simply set UNAME_r :)

for the record - if anyone's interested - adding a line e.g.:

ALL_ENV+= UNAME_r=1.12-RELEASE

to mk.conf looks like it -might- work ..

(unless wants to chime in & verify)





From joerg at britannica.bec.de  Sun Mar 23 11:46:53 2008
From: joerg at britannica.bec.de (Joerg Sonnenberger)
Date: Sun, 23 Mar 2008 11:46:53 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <20080323181428.GA2099@britannica.bec.de>

On Sun, Mar 23, 2008 at 01:41:42PM -0400, Chris Turner wrote:
> they should change the phrase from RTFM to 'Carefully RTFM' :)

RTFMAI -- Read The Fine Manual Again, Idiot.

Joerg




From dillon at apollo.backplane.com  Sun Mar 23 20:05:36 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Sun, 23 Mar 2008 20:05:36 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
Message-ID: <200803240257.m2O2voNH038355@apollo.backplane.com>

    Here's an update on the HAMMER work!

    Current status:

    * Passes all standard filesystem stress tests and buildworld will
      run with a HAMMER /usr/obj.  Large histories are able to accumulate
      without effecting performance.

    * Pruning and reblocking code is in and partially tested, but now needs
      more stringent testing.

    * Full historical access appears to be working but needs testing.
      Note that a sync is still needed to flush dirty cached data prior
      to acquiring a timestamp for the 'snapshot' to be set in stone.
      (dirty data cached in-memory has no historical tags and must be
      committed to physical disk before it can be accessed historically).


    Current bugs:

    * There is one known bug in the standard operations code paths
      that results in an assertion in HAMMER's I/O subsystem.

    * There are probably bugs in the reblocking and/or pruning code.  More
      likely in the reblocking code.


    There are two big-ticket and several little-ticket items left.  HAMMER
    will officially go Alpha when the big-ticket items are done, and beta
    when we get a few of the little-ticket items done.

    Big ticket items left:

    * UNDO (crash recovery) code.  Currently it writes out undo records but
      they are not yet sequenced, buffer writes are not yet ordered, and
      there is no mount-time recovery code yet.

      This is the last item needed before HAMMER can go operational.

    * Filesystem full handling.  Currently no space is reserved for dirty
      cached data so it is possible to create/write files and for HAMMER
      to not have sufficient space left on-disk to flush it.


    Little ticket items:

    * Automated reblocking (currently these functions are manually
      initialized via the hammer utility).

    * I/O clustering and preliminary BMAP op when writing out large files.

    * CRC checking (CRC fields are reserved but not entirely generated yet
      and not yet checked at all).

    * Disaster Recovery filesystem scan.

    * Boot support.

    I expect all of these items and more to be handled by the 2.0 release
    in July.

			    Additional HAMMER capabilities
				(no timeline yet)

    * Adding, removing, and resizing a HAMMER filesystem's backing store.

			Ultimate Goals and working towards them
				(no timeline yet)

    Our ultimate goal with HAMMER and DragonFly in general is to support
    fully cache coherent replication in a multi-machine environment.  This
    involves several steps and networking protocols.

    * Replication of synchronization streams based on the UNDO log.  If
      resynchronizing to a target which is too old a B-Tree scan will
      likely be required.

    * Cache coherency protocols for machine-machine coherency for both
      replicated and remote-HAMMER access.

    I have no time frame for these items yet.  It will depend on how quickly
    HAMMER moves to Alpha and Beta status.  I will say, however, now
    that HAMMER's on-disk format has solidified, that I have a very precise
    understanding of the protocols that will be needed to accomplish fully
    cache coherent remote access for both replicated and non-replicated
    (remote mount style) access.

    And, as you know, fully coherent filesystem access across machines is
    going to be the basis for DragonFly's clustering across said machines.

    In summary, things are progressing very well.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From justin at shiningsilence.com  Sun Mar 23 20:10:13 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Sun, 23 Mar 2008 20:10:13 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <53758.192.168.0.252.1206327873.squirrel@www.shiningsilence.com>

On Sun, March 23, 2008 12:36 pm, Chris Turner wrote:

> it seems like if spoofing uname is configured inside a jail,
> the next (or previous..) release can be installed into a jail and
> used for building / testing packages without the overhead of a VM or
> maintaining a separate physical host

If you don't need a jail to spoof uname, as others posted, you can
installworld into a chroot and build everything you want there using
Joerg's spiffy pbulk.  That's what I'm doing on pkgbox now; I can hand you
my somewhat terse notes if you want.  It would be relatively easy to set
up the configuration you're talking about.





From sepherosa at gmail.com  Sun Mar 23 20:18:20 2008
From: sepherosa at gmail.com (Sepherosa Ziehau)
Date: Sun, 23 Mar 2008 20:18:20 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <ea7b9c170803232012n2f27f893tf1d756d7c9770419@mail.gmail.com>

On Mon, Mar 24, 2008 at 2:14 AM, Joerg Sonnenberger
<joerg at britannica.bec.de> wrote:
> On Sun, Mar 23, 2008 at 01:41:42PM -0400, Chris Turner wrote:
>  > they should change the phrase from RTFM to 'Carefully RTFM' :)
>
>  RTFMAI -- Read The Fine Manual Again, Idiot.

http://leaf.dragonflybsd.org/~sephe/rtfm.jpg

:D

>
>  Joerg
>



-- 
Live Free or Die




From justin at shiningsilence.com  Sun Mar 23 20:38:30 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Sun, 23 Mar 2008 20:38:30 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: GSoC 2008 - mentors signup
Message-ID: <53885.192.168.0.252.1206329503.squirrel@www.shiningsilence.com>

If you are planning to be a mentor for a Summer of Code project, please
sign up here for the mentors mailing list:

http://groups.google.com/group/google-summer-of-code-mentors-list

If you've already signed up, your subscription should be set up tomorrow.





From justin at shiningsilence.com  Sun Mar 23 21:12:01 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Sun, 23 Mar 2008 21:12:01 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: GSoC 2008 - mentors signup
In-Reply-To: <53885.192.168.0.252.1206329503.squirrel@www.shiningsilence.com>
Message-ID: <54025.192.168.0.252.1206331572.squirrel@www.shiningsilence.com>

Also!

If you are a potential mentor and you have not done so yet:

http://code.google.com/soc/mentor_step1.html

Get yourself registered as a mentor for the Summer of Code project.  Once
you are in there, check off DragonFly in the "My Profile" section.

You will need a Google Account if you don't have one:

http://www.google.com/accounts

This will add you to the list of mentors in the Google Summer of Code web
application, so you can review/be attached to projects.

A guide is available if you want more information:

http://groups.google.com/group/google-summer-of-code-announce/web/guide-to-the-gsoc-web-app-for-mentors-and-organization-administrators






From c.turner at 199technologies.org  Mon Mar 24 04:29:28 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Mon, 24 Mar 2008 04:29:28 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <47E78ECE.4070307@199technologies.org>

Justin C. Sherrill wrote:
If you don't need a jail to spoof uname, as others posted, you can
installworld into a chroot and build everything you want there using
Joerg's spiffy pbulk.  That's what I'm doing on pkgbox now; I can hand you
my somewhat terse notes if you want.  It would be relatively easy to set
up the configuration you're talking about.
cheers - I guess I thought incorrectly that something 'special' was 
needed to get the uname to change .. have been using the legacy bulks in 
chroots / jails (for 'same os' builds) as I haven't quite migrated to 
pbulk yet ..

thanks for the help offer - I'll ask if I run into trouble.




From dillon at apollo.backplane.com  Mon Mar 24 08:28:49 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Mon, 24 Mar 2008 08:28:49 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <200803241500.m2OF0CG8043760@apollo.backplane.com>


:http://leaf.dragonflybsd.org/~sephe/rtfm.jpg
:
::D

    Ho!

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From elekktretterr at exemail.com.au  Mon Mar 24 09:10:15 2008
From: elekktretterr at exemail.com.au (Petr Janda)
Date: Mon, 24 Mar 2008 09:10:15 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
In-Reply-To: <200803240257.m2O2voNH038355@apollo.backplane.com>
Message-ID: <200803250138.49775.elekktretterr@exemail.com.au>


>
>     And, as you know, fully coherent filesystem access across machines is
>     going to be the basis for DragonFly's clustering across said machines.
>
>     In summary, things are progressing very well.
>


Hi Matt,
That's good to know things are going so well. Got a question. If memory serves 
me right, initially there was also going to be a thing called ANVIL, I can't 
remember what it was supposed to do and whether its still in your design. 
Could you elaborate a little?

Thanks,
Petr




From dillon at apollo.backplane.com  Mon Mar 24 14:12:11 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Mon, 24 Mar 2008 14:12:11 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
In-Reply-To: <200803240257.m2O2voNH038355@apollo.backplane.com>
Message-ID: <200803242100.m2OL0nWV046868@apollo.backplane.com>


:Hi Matt,
:That's good to know things are going so well. Got a question. If memory serves 
:me right, initially there was also going to be a thing called ANVIL, I can't 
:remember what it was supposed to do and whether its still in your design. 
:Could you elaborate a little?
:
:Thanks,
:Petr

    It's not really in the HAMMER design any more, primarily because HAMMER's
    volume model seems to work fine as-is.  Ultimately something like ANVIL
    (a block storage manager) would prove beneficial to the project but it
    would be treated as a separate project.  HAMMER's redundancy model is
    going to be baesd around replication and clustering.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From tgen at netphreax.net  Mon Mar 24 18:31:37 2008
From: tgen at netphreax.net (Thomas E. Spanjaard)
Date: Mon, 24 Mar 2008 18:31:37 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
In-Reply-To: <200803240257.m2O2voNH038355@apollo.backplane.com>
Message-ID: <47E85337.2070407@netphreax.net>

Matthew Dillon wrote:
    * Full historical access appears to be working but needs testing.
      Note that a sync is still needed to flush dirty cached data prior
      to acquiring a timestamp for the 'snapshot' to be set in stone.
      (dirty data cached in-memory has no historical tags and must be
      committed to physical disk before it can be accessed historically).
Wouldn't making timestamp queries (at least from userland) enforce a 
sync on the volume in question be useful here?
--
        Thomas E. Spanjaard
        tgen at netphreax.net
Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00005.pgp
Type: application/octet-stream
Size: 186 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080324/3077333f/attachment-0002.obj>

From dillon at apollo.backplane.com  Mon Mar 24 20:10:12 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Mon, 24 Mar 2008 20:10:12 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
In-Reply-To: <200803240257.m2O2voNH038355@apollo.backplane.com>
Message-ID: <200803250302.m2P32qLP050160@apollo.backplane.com>


:Wouldn't making timestamp queries (at least from userland) enforce a 
:sync on the volume in question be useful here?
:-- 
:         Thomas E. Spanjaard
:         tgen at netphreax.net

    Making the 'hammer now' command do a sync() is a good idea.  I will
    make that change right now so it doesn't get lost.

    Here's a general overview of the issues involved with having historical
    access to the filesystem:

				----------------

    Recording the timestamps in the in-memory cache, for a finer-grained
    snapshot capability, is doable but has its own issues.  Here's an
    illustration:

    open()  create file
    write() append 4K	(file size now 4K)
    write() append 4K	(file size now 8K)
    write() append 4K	(file size now 12K)
    write() append 4K	(file size now 16K)

    Now NONE of this has gone to disk yet, it's entirely in the in-memory
    cache.  The inode is in the in-memory cache.  The data is stored in
    the buffer cache.  Even the directory entry for the file that we
    just created is still in the in-memory cache (HAMMER caches the raw
    records it intends to commit later on).

    If I wanted to be able to acquire a timestamp between each write and
    'see' a snapshot of the file as of any point in the above sequence,
    then every write would also have to allocate a copy of the inode
    (because it changes size on each write).

    The data has the same problem though with a slightly different example.
    Lets say each write() was a seek-write, overwriting the previous data.
    Now with every write() I would have to allocate a copy of the data
    being overwritten.  This is complicated by the fact that the buffer
    cache has no clue about 'historical' accesses, so I would not be able
    to use the buffer cache to cache the data.

    There's also another problem and that is with the efficiency of the
    topology on-disk.  Even if I maintained all the copies of the inode
    and all the copies of the data in-memory, I would still have to sync
    all those copies to disk in order for things to remain historically
    coherent (whether it be in-cache or on-disk).  This would result in
    hundreds or even thousands of copies of the inode on-disk, not to
    mention potentially many copies of the data.

    I just don't want to do that right now, at least not as a default.  A
    lot of performance would be lost.  Hence a sync() is needed if
    you want to create a demark which you can accurately snapshot.

				-------------

    Here's a quick synopsis of how the cache would operate in a clustered
    filesystem:

    In order to properly integrate with in-memory caches, a wider cache
    coherency infrastructure is needed between machines such that
    modifications made on one machine proactively invalidate those
    protions of the cache(s) on other machines.  At the same time, any
    'dirty' cache data, for example when a file is created or written to,
    must lock the cache space in question on all other machines.
    The cache space in this case is not just the file data, but also the
    related namespaces (for creations, deletions, and renames).  Attempts
    to access locked spaces from other machines in the cluster would have
    to force a flush to the filesystem backing store and lower the cache
    states for the effected information on the original machine from dirty
    to shared-read-only.

    It will be easiest to integrate the cache coherency information into
    the buffer cache and namecache themselves.  Once a machine has dirtied
    an in-memory cache element... for example part of the namespace when
    creating a file or chunks of data written within a file, that machine
    must have a free hand to make further modifications to the cache spaces
    involved without further interaction with other machines.

				-------------

    Now, if you think of those two major elements you can see that they
    actually fit together quite well.  If I were to attempt to maintain
    transactional coherency on a per-system-call basis then the cache
    granularity between machines would have to be much, much smaller then
    our current in-memory caching elements provide.  That would become
    a really nasty coding problem.  So I don't even want to begin to
    complate transactional coherency at a finer-grain then sync() or
    fsync() until long after we actually have clustering working.

						-Matt





From elekktretterr at exemail.com.au  Mon Mar 24 21:56:58 2008
From: elekktretterr at exemail.com.au (Petr Janda)
Date: Mon, 24 Mar 2008 21:56:58 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
In-Reply-To: <200803240257.m2O2voNH038355@apollo.backplane.com>
Message-ID: <200803251516.16407.elekktretterr@exemail.com.au>

So is it needed to run hammer now in order to "create" a snapshot? What would 
I do in situation like this: got a hammer filesystem and couple of the files 
change on day to day basis. Then a week later I needed to access one of the 
files, in exactly the state they were 7 days ago.

Cheers,
Petr




From dillon at apollo.backplane.com  Mon Mar 24 22:34:15 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Mon, 24 Mar 2008 22:34:15 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
In-Reply-To: <200803240257.m2O2voNH038355@apollo.backplane.com>
Message-ID: <200803250526.m2P5QZ5X051081@apollo.backplane.com>


:So is it needed to run hammer now in order to "create" a snapshot? What would 
:I do in situation like this: got a hammer filesystem and couple of the files 
:change on day to day basis. Then a week later I needed to access one of the 
:files, in exactly the state they were 7 days ago.
:
:Cheers,
:Petr

    No, you do not have to run 'hammer now' to create a snapshot.  The
    kernel syncs all filesystems every 30 seconds, so if you do nothing
    at all you get a snapshot granularity of 30 seconds.

    Where you would use 'hammer now' is if you wanted the most current
    snapshot possible for the purpose of, say, backing up your filesystem
    to another machine.  You might do something like this:

	set timestamp = `hammer now`
	cpdup /mountpoint/@@$timestamp targethost:/somepath

    But if you didn't care about that you could just go back far enough
    that you get a stable historical view... e.g. go back 1 minute and you
    would have a stable view into your filesystem.

	set timestamp = `hammer stamp 60s`		<------ doesn't sync
	cpdup /mountpoint/@@$timestamp targethost:/somepath


    Ultimately the idea of managing filesystems this way is to still do
    regular backups from your production machine to your backup machine
    (ultimately by way of replication), with both running HAMMER, but only
    retain a limited amount of history on the production box.  You might
    desire to retain only one week's worth of history on the production box,
    retain one month's history on your local backup box, and retain a very
    granular one year's worth of history on your remote backup box.

    Come to think of it, I should add some more directives to the
    'hammer prune' command to make that easier to specify.

    Until I implement a live replication 'feed' the minimum granularity on
    the backup box will be how often you do your backups (e.g. once a day),
    and you can prune it into more granular forms from that starting point.
    Once we have a live replication feed the backup box will have the same
    30-second granularity that the production machine has.

    A major bullet point for this style of management is that the retention
    policy on the various boxes can be different even though they are
    all slaved off the same production filesystem.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From justin at shiningsilence.com  Tue Mar 25 05:58:49 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Tue, 25 Mar 2008 05:58:49 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: SoC - student signups
Message-ID: <58180.65.106.147.226.1206449676.squirrel@www.shiningsilence.com>

Here's a quick link roundup:

Are you a student?  Put in your application for a Google Summer of Code here:

http://code.google.com/soc/2008/student_signup.html

Student guide:
http://groups.google.com/group/google-summer-of-code-announce/web/guide-to-the-gsoc-web-app-for-student-applicants

Are you a mentor?  (That means hasso, hsu, sephe, matthias, TGEN, and
corecode right now)

Student proposals will show up on the mentor page, linked below.  You will
get to rate them, and take the one(s) that you want to mentor.

Mentor page:
http://code.google.com/soc/2008/mentor_home.html
Mentor guide:
http://groups.google.com/group/google-summer-of-code-announce/web/guide-to-the-gsoc-web-app-for-mentors-and-organization-administrators

If you are a mentor and are communicating with potential students, send
them the URLs above for student signup and the student guide; work with
them if they ask for advice on what to say in the application.  They can
resubmit up to 20 times if they want to correct it.

Deadline is March 31st.






From noah.yan at gmail.com  Thu Mar 27 20:17:48 2008
From: noah.yan at gmail.com (Yonghong Yan)
Date: Thu, 27 Mar 2008 20:17:48 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: About DFBSD.64
In-Reply-To: <47EB0B5B.5020802@gmail.com>
Message-ID: <59521b110803272015y1cc8cc39uc93f154ed36e0505@mail.gmail.com>

thanks for your interest.

I owe to everybody for any update or work in the past four months. so
many things happen in my work and my family (they are all good:) and
keep me extremely busy. But i am not leaving and will be back on this
soon.

the latest sources are in http://repo.or.cz/w/dragonfly/port-amd64.git
, I did have a compiled kernel long time before, but I have to break
it to work on the pmap. you can pick up from there. TGEN will help you
a lot, also keep me posted too, if you like.

Noah

On Wed, Mar 26, 2008 at 9:50 PM, Sdavtaker <sdavtaker at gmail.com> wrote:
> Hello,
>  Im applying to GSoC to work in the x64 version of DFBSD with TGEN, i
>  found some work already done in the repository and some mails in the
>  archive from you.
>  I was wondering if you already had a working compiled kernel in AMD64
>  machine and what was not working yet to continue that work.
>  Thanks for any info.
>  Sdav
>




From dillon at apollo.backplane.com  Sat Mar 29 13:27:43 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Sat, 29 Mar 2008 13:27:43 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 29-Mar-2008
Message-ID: <200803292022.m2TKMLGe004942@apollo.backplane.com>

    Good progress continues to be made.  HAMMER survived acting as my
    LAN backup machine (in full historical mode) for almost a week before
    it hit an assertion.  I've fixed that issue and believe that the core
    filesystem implementation code is now 'very stable'.

    Note that the recent commit will result in many more 'hammer_lock_ex:'
    messages on the console then you may have previously observed.  This is
    due to the way object id's are allocated in the face of parallel 
    modifications to the filesystem, resulting in too much locality of
    reference in the B-Tree.  I do intend to improve it.

    I am still working on the two major items needed before HAMMER can be
    declared operational, those being the filesystem full handling and the
    undo/recovery-on-mount code.  These are the last 'hard' bits left in
    the design.

    With exception to filling up the filesystem, which *will* create a mess,
    and noting that no crash recovery code exists yet (so you have to newfs
    it if you crash), I'd appreciate it if interested parties could test
    the other functions of the filesystem, in particular the pruning and
    reblocking functions (man hammer), and the historical access functions.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From dillon at apollo.backplane.com  Sun Mar 30 15:11:03 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Sun, 30 Mar 2008 15:11:03 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Need ideas on how to solve an st_ino/st_dev test issue for HAMMER.
Message-ID: <200803302207.m2UM7BCp016402@apollo.backplane.com>

    Here's the problem, given historical access softlinks as shown below:

test30# ls -lda cra*
drwxr-xr-x  1 root  wheel  Mar 29 13:04 crater
lrwxr-xr-x  1 root  wheel  Mar 29 18:57 crater.20080329 -> crater@@0x47eef383
lrwxr-xr-x  1 root  wheel  Mar 30 01:24 crater.20080330 -> crater@@0x47ef4e29
-rw-r--r--  2 root  wheel  Mar 30 01:24 crater.log

    The problem is that if I do this:

    diff -r crater.20080329/var/log crater.20080330/var/log

    Diff just returns without actually diffing anything.  The reason is
    because diff checks st_ino and st_dev and believes the directories/files
    to be identical because they match.

    I considered munging the inode number for historical accesses, but
    that would seriously break NFS exports which try to access historical
    files and directories.  Right now NFS *is* able to distinguish between
    the two because NFS handles are 128-bit-wide entities, so I can encode
    the as-of transaction id as part of the filehandle.  But userland
    programs only have access to a 64-bit-wide inode so userland still
    believes the files to be identical.

    st_dev is only 32 bits, carefully munging it is an option if we
    could figure out a way to do it, but I'd rather not.

    I am considering using st_gen but then we'd have to patch third
    party software to test st_gen along with everything else.  This may
    be the only workable solution, though, and only a few programs would
    need to be patched.  st_gen is only 32 bits but it would solve the
    problem as we would be able to use all 32 bits.

    If anyone has any bright ideas, including 'leave it alone', I'm all
    ears.

						-Matt





From justin at shiningsilence.com  Mon Mar 31 10:40:42 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Mon, 31 Mar 2008 10:40:42 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: SoC student applications due by 5PM PDT tomorrow
In-Reply-To: <1942.192.168.0.242.1206930479.squirrel@www.shiningsilence.com>
Message-ID: <11892.67.108.184.175.1206984967.squirrel@www.shiningsilence.com>

On Sun, March 30, 2008 10:27 pm, Justin C. Sherrill wrote:
> SoC students:
>
> If you have an application to submit for DragonFly/Summer of Code, please
> do so by 17:00 Pacific time on the 31st - that's tomorrow, at least for
> me.

The deadline for student proposals has been extended to April 7th; all
other dates move forward one week to acommodate.

This is a good time to update existing applications or submit new ones. 
Talk to your (potential) mentors if you are curious.






From nthery at gmail.com  Mon Mar 31 11:29:49 2008
From: nthery at gmail.com (Nicolas Thery)
Date: Mon, 31 Mar 2008 11:29:49 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
Message-ID: <64fc43b0803311126na7d0b27obaa9d35bac6d32ee@mail.gmail.com>

Hello,

Now that the release is over, I'll try to get rid of zones and migrate
allocations to objcache.

Here is a 1st patch that migrate struct proc.  I'll commit it in a
couple of days if nobody objects.

I'm also implementing a way to monitor objcache statistics.  So far,
I've hacked sth similar to
sysctl vm.zone: stats are returned in one giant string, one line per
cache.  That's simple but ugly and hard to read because there are
quite a few stats per cache.

So I'm thinking about implementing a small tool, ocstat, that extracts
stats from sysctl the way ps(1) does (thru libkvm iirc) and formats it
in various ways.  What do you think?

Cheers,
Nicolas

Index: src2/sys/kern/kern_exit.c
===================================================================
--- src2.orig/sys/kern/kern_exit.c	2008-03-31 08:05:59.139796000 +0200
+++ src2/sys/kern/kern_exit.c	2008-03-31 10:31:39.000000000 +0200
@@ -834,7 +834,7 @@ loop:
 			}

 			vm_waitproc(p);
-			zfree(proc_zone, p);
+			objcache_put(proc_cache, p);
 			nprocs--;
 			return (0);
 		}
Index: src2/sys/kern/kern_proc.c
===================================================================
--- src2.orig/sys/kern/kern_proc.c	2008-03-31 08:05:59.139918000 +0200
+++ src2/sys/kern/kern_proc.c	2008-03-31 10:31:39.000000000 +0200
@@ -84,7 +84,7 @@ u_long pgrphash;
 struct proclist allproc;
 struct proclist zombproc;
 struct spinlock allproc_spin;
-vm_zone_t proc_zone;
+struct objcache* proc_cache;
 vm_zone_t lwp_zone;
 vm_zone_t thread_zone;

@@ -131,7 +131,7 @@ procinit(void)
 	spin_init(&allproc_spin);
 	pidhashtbl = hashinit(maxproc / 4, M_PROC, &pidhash);
 	pgrphashtbl = hashinit(maxproc / 4, M_PROC, &pgrphash);
-	proc_zone = zinit("PROC", sizeof (struct proc), 0, 0, 5);
+	proc_cache = objcache_create_simple(M_PROC, sizeof(struct proc));
 	lwp_zone = zinit("LWP", sizeof (struct lwp), 0, 0, 5);
 	thread_zone = zinit("THREAD", sizeof (struct thread), 0, 0, 5);
 	uihashinit();
Index: src2/sys/sys/proc.h
===================================================================
--- src2.orig/sys/sys/proc.h	2008-03-31 08:05:59.140325000 +0200
+++ src2/sys/sys/proc.h	2008-03-31 10:31:39.000000000 +0200
@@ -473,7 +473,7 @@ struct proc *zpfind (pid_t);	/* Find zom
 struct vm_zone;
 struct globaldata;
 struct lwp_params;
-extern struct vm_zone *proc_zone;
+extern struct objcache *proc_cache;
 extern struct vm_zone *lwp_zone;

 int	enterpgrp (struct proc *p, pid_t pgid, int mksess);
Index: src2/sys/kern/kern_fork.c
===================================================================
--- src2.orig/sys/kern/kern_fork.c	2008-03-31 08:05:59.140042000 +0200
+++ src2/sys/kern/kern_fork.c	2008-03-31 10:31:39.000000000 +0200
@@ -332,7 +332,7 @@ fork1(struct lwp *lp1, int flags, struct
 	}

 	/* Allocate new proc. */
-	p2 = zalloc(proc_zone);
+	p2 = objcache_get(proc_cache, M_WAITOK);
 	bzero(p2, sizeof(*p2));

 	/*




From hsu at dragonflybsd.org  Mon Mar 31 11:44:34 2008
From: hsu at dragonflybsd.org (Jeffrey Hsu)
Date: Mon, 31 Mar 2008 11:44:34 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <64fc43b0803311126na7d0b27obaa9d35bac6d32ee@mail.gmail.com>
Message-ID: <200803311841.m2VIfQAI007579@nlpi001.prodigy.net>

The object cache is not a general-purpose memory allocator.  It's a cache of
pre-initialized objects.  Are the significant portions of the proc structure
that can be restored to initialized state on object puts?  If not, it's best
to just use a general-purpose memory allocator.

								Jeffrey




From corecode at fs.ei.tum.de  Mon Mar 31 12:07:02 2008
From: corecode at fs.ei.tum.de (Simon 'corecode' Schubert)
Date: Mon, 31 Mar 2008 12:07:02 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <200803311841.m2VIfQAI007579@nlpi001.prodigy.net>
Message-ID: <47F1357B.1070302@fs.ei.tum.de>

Jeffrey Hsu wrote:
> The object cache is not a general-purpose memory allocator.  It's a cache of
> pre-initialized objects.  Are the significant portions of the proc structure
> that can be restored to initialized state on object puts?  If not, it's best
> to just use a general-purpose memory allocator.

Why?  What's the loss if we use the object cache to allocate struct procs?

cheers
  simon

Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00006.pgp
Type: application/octet-stream
Size: 252 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080331/a4a24314/attachment-0002.obj>

From nthery at gmail.com  Mon Mar 31 12:17:03 2008
From: nthery at gmail.com (Nicolas Thery)
Date: Mon, 31 Mar 2008 12:17:03 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <nthery@gmail.com>
Message-ID: <64fc43b0803311214u7da6bbb8xaf971de1a80e7258@mail.gmail.com>

2008/3/31, Jeffrey Hsu <hsu at dragonflybsd.org>:
> The object cache is not a general-purpose memory allocator.  It's a cache of
>  pre-initialized objects.  Are the significant portions of the proc structure
>  that can be restored to initialized state on object puts?  If not, it's best
>  to just use a general-purpose memory allocator.

Well, I haven't checked this yet.  I planned to do this in a second
step after getting rid of zones.

I thought that even without  the pre-initialization part, objcache has
the advantage
of pre-allocating set of objects (as zones) and is additionally
mp-safe (contrary to zones and, granted, as malloc()).   The latter
may be interesting as we talk of improving MP support.

Cheers,
Nicolas




From dillon at apollo.backplane.com  Mon Mar 31 12:23:40 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Mon, 31 Mar 2008 12:23:40 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <200803311841.m2VIfQAI007579@nlpi001.prodigy.net>
Message-ID: <200803311921.m2VJLITB027669@apollo.backplane.com>

    I both agree and disagree with Jeff.  I think the only *disadvantage*
    to using objcache for struct proc is that objcache must cache a minimum
    number of free structures to be efficient so the overall kernel memory
    use would be a bit greater verses uses kmalloc().  But I agree with Jeff
    in that objcache's biggest advantage is that you can keep structural state
    intact and struct proc might not be a good candidate (yet).

    What I suggest is that you convert struct proc from zone to kmalloc
    first, and then look into a possible objcache adaptation.  kmalloc
    is not slow.. it's a very fast allocator.  Objcache is probably a tad
    faster but not by much.  Where objcache really wins is in not having
    to completey reinitialize the allocated structures.

    Over the years I've removed (I think) all the dependancies on requiring
    the proc structure to be in stable memory so I believe it can be moved to
    kmalloc/objcache now without any major pain.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From corecode at fs.ei.tum.de  Mon Mar 31 12:37:40 2008
From: corecode at fs.ei.tum.de (Simon 'corecode' Schubert)
Date: Mon, 31 Mar 2008 12:37:40 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: SoC student applications due by 5PM PDT tomorrow
In-Reply-To: <1942.192.168.0.242.1206930479.squirrel@www.shiningsilence.com>
Message-ID: <47F13CDA.6010703@fs.ei.tum.de>

Justin C. Sherrill wrote:
> On Sun, March 30, 2008 10:27 pm, Justin C. Sherrill wrote:
>> SoC students:
>>
>> If you have an application to submit for DragonFly/Summer of Code, please
>> do so by 17:00 Pacific time on the 31st - that's tomorrow, at least for
>> me.
> The deadline for student proposals has been extended to April 7th; all
> other dates move forward one week to acommodate.

This is very good.

Some more ideas for eager students (we want to keep the ratio, right?):

Enhance the FreeBSD/DragonFly sound infrastructure to support surround
sound/multichannel output.

Update sound drivers to support S/PDIF output.

Make the sound infrastructure OSSv4 compatible (there was a SoC at
FreeBSD last year or so)


of course only if it doesn't exist already :)

cheers
  simon


Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00007.pgp
Type: application/octet-stream
Size: 252 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080331/6da61cff/attachment-0002.obj>

From corecode at fs.ei.tum.de  Mon Mar 31 12:41:30 2008
From: corecode at fs.ei.tum.de (Simon 'corecode' Schubert)
Date: Mon, 31 Mar 2008 12:41:30 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <200803311841.m2VIfQAI007579@nlpi001.prodigy.net>
Message-ID: <47F13DE4.10205@fs.ei.tum.de>

Matthew Dillon wrote:
>     What I suggest is that you convert struct proc from zone to kmalloc
>     first, and then look into a possible objcache adaptation.  kmalloc
>     is not slow.. it's a very fast allocator.  Objcache is probably a tad
>     faster but not by much.  Where objcache really wins is in not having
>     to completey reinitialize the allocated structures.

Could we please not move to kmalloc, but instead try to move all fast
path allocations to objcache?  I don't like the idea of allocating
everything with kmalloc.  Caching struct procs is not a bad thing itself.

cheers
  simon


Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00008.pgp
Type: application/octet-stream
Size: 252 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080331/ac328c08/attachment-0002.obj>

From hsu at FreeBSD.org  Mon Mar 31 12:59:05 2008
From: hsu at FreeBSD.org (Jeffrey Hsu)
Date: Mon, 31 Mar 2008 12:59:05 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <47F1357B.1070302@fs.ei.tum.de>
Message-ID: <200803311920.m2VJK5Ln018015@nlpi015.prodigy.net>

The object cache sits on top of a general-purpose memory allocator such
as kmalloc or zalloc and provides pre-initialized object caching functionality.
If you're not going to use the object caching functionality, you can just
call the underlying memory allocator directly.

							Jeffrey




From dillon at apollo.backplane.com  Mon Mar 31 16:17:19 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Mon, 31 Mar 2008 16:17:19 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <200803311841.m2VIfQAI007579@nlpi001.prodigy.net>
Message-ID: <200803312311.m2VNBumd029866@apollo.backplane.com>

:Could we please not move to kmalloc, but instead try to move all fast
:path allocations to objcache?  I don't like the idea of allocating
:everything with kmalloc.  Caching struct procs is not a bad thing itself.=
:
:
:cheers
:  simon

    I will state for the record that I'm fine with either objcache or
    kmalloc.  I agree with Jeff that using objcache for struct proc
    probably isn't necessary but I also agree that it would not hurt either,
    and if the intent is to optimize the initialization of the proc
    structure in the future then moving to objcache now would save us
    from having to do it later.

    So whichever method Nicolas wants to use is fine with me.

						-Matt




From hsu at dragonflybsd.org  Mon Mar 31 19:22:47 2008
From: hsu at dragonflybsd.org (Jeffrey Hsu)
Date: Mon, 31 Mar 2008 19:22:47 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <64fc43b0803311214u7da6bbb8xaf971de1a80e7258@mail.gmail.com>
Message-ID: <200804010218.m312IVUq003624@nlpi043.prodigy.net>

  >> Are there significant portions of the proc structure
  >> that can be restored to initialized state on object puts?

  > I planned to do this in a second step after getting rid of zones.

I'll all in favor of making more use of caching pre-initialized objects, so
if this is your objective, then please go ahead.  It's just that I'd convert
over to the object cache in one step.

  > I thought that even without  the pre-initialization part, objcache has
  > the advantage of pre-allocating set of objects (as zones) and is additionally
  > mp-safe (contrary to zones and, granted, as malloc()).

Well, the zone allocator is MP-safe.  It's not hard to lock up the places that
manipulate the linked-list of free items. Look for uses of the zlock field.

								Jeffrey




From tgen at netphreax.net  Sat Mar  1 12:57:53 2008
From: tgen at netphreax.net (Thomas E. Spanjaard)
Date: Sat, 1 Mar 2008 12:57:53 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: [Fwd: Project Support Open Source: $50 donation to support you      project]
In-Reply-To: <2468.192.168.0.242.1204346451.squirrel@www.shiningsilence.com>
Message-ID: <47C9C1B7.50203@netphreax.net>

Justin C. Sherrill wrote:
The "donation" happens after you place an "acknowledgement" on an open
source project's web page.  I'm putting those words in scare quotes
because I think it's a "payment" for an "advertisement".  The supplied
link has nothing to do with DragonFly, to say the least.

<a href="http://www.2insure4less.com /" title="We support FOSS software
projects.">Online Insurance Quotes</a>
To think our souls are only worth $50...
--
        Thomas E. Spanjaard
        tgen at netphreax.net
Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00000.pgp
Type: application/octet-stream
Size: 186 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080301/0d61e240/attachment-0003.obj>

From c.turner at 199technologies.org  Sat Mar  1 17:52:31 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Sat, 1 Mar 2008 17:52:31 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Misc. ACPI / suspend
Message-ID: <47CA073B.6020106@199technologies.org>

Wondering if anyone more well versed in the ACPI implementation could
comment on the applicability of:
http://lkml.org/lkml/2007/4/6/69

w/r/t the current state of the art in Dfly

(or BSD's in general)

Cheers!

- Chris




From elekktretterr at exemail.com.au  Sun Mar  2 00:41:25 2008
From: elekktretterr at exemail.com.au (Petr Janda)
Date: Sun, 2 Mar 2008 00:41:25 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: CARP question
Message-ID: <200803021934.21669.elekktretterr@exemail.com.au>

So Ive setup CARP on 2 DF-based mailservers. Installation went fine. Box 1 has 
adskew of 0 therefore it is the MASTER. Box 2 has adskew of 254, therefore is 
BACKUP.  If i down the carp0 interface on Box 1, then Box 2 carp interface 
gets promoted to MASTER. Then I up the carp interface on Box 1, logically Box 
2 should become BACKUP again as Box 1 becomes MASTER due to adskew set to 0.

However it doesnt happen. When carp0 interface on Box 1 is upped it becomes a 
BACKUP, not a MASTER even though according to adskew it should be MASTER.

What is the desired behaviour?

Cheers
Petr




From qhwt+dfly at les.ath.cx  Sun Mar  2 02:50:14 2008
From: qhwt+dfly at les.ath.cx (YONETANI Tomokazu)
Date: Sun, 2 Mar 2008 02:50:14 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: panic: assertion: hammer_btree_cmp(cursor->left_bound,	&cursor->node->ondisk->elms[0].leaf.base) <= 0 in btree_split_leaf
In-Reply-To: <200802232204.m1NM4cxd046264@apollo.backplane.com>
Message-ID: <20080302104554.GA22813@les.ath.cx>

Hi.
While trying to find a procedure to reliably reproduce the panic
I reported last time, I caught a different panic (uploaded at
 ~y0netan1/crash/9/ on my leaf account).  I wrote the following shell
script (make sure to edit variables DISKS and MOUNTPT before using this
script or it may trash your system):
  #!/bin/sh -ex
  DISKS="/dev/ad0s1f"
  MOUNTPT=/mnt/HAMMER

  cd /
  newfs_hammer -L TEST $DISKS
  for i in `seq 1 100`; do
	  mount_hammer $DISKS $MOUNTPT
	  /bin/rm -rf $MOUNTPT/??
	  (set +x; for x in `seq 1 10000`; do echo -n > $MOUNTPT/$x; done)
	  umount $MOUNTPT
  done

And the panic is triggered by rm command.
I'll try to see if it's possible to reproduce the last one without
unmounting then mounting the HAMMER fs.

Cheers.




From dillon at apollo.backplane.com  Sun Mar  2 13:25:33 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Sun, 2 Mar 2008 13:25:33 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: panic: assertion: hammer_btree_cmp(cursor->left_bound,	&cursor->node->ondisk->elms[0].leaf.base) <= 0 in btree_split_leaf
In-Reply-To: <200802232204.m1NM4cxd046264@apollo.backplane.com>
Message-ID: <200803022119.m22LJRCY037076@apollo.backplane.com>


:Hi.
:While trying to find a procedure to reliably reproduce the panic
:I reported last time, I caught a different panic (uploaded at
: ~y0netan1/crash/9/ on my leaf account).  I wrote the following shell
:script (make sure to edit variables DISKS and MOUNTPT before using this
:script or it may trash your system):

(from the core)

panic: assertion: node->lock.refs == 0 && node->ondisk == NULL in hammer_flush_buffer_nodes

    Yah, I've seen this failure.  Add a sync or two before the umount and
    tell me if it still occurs.  It's either a node reference leak somewhere
    or it is a race between bufdaemon and umount.  The assertions are really
    strict there precisely to catch those sorts of cases.

    Also note that the code to deal with a full HAMMMER filesystem has not
    been written yet (The failure you are reporting is unrelated to a full
    HAMMER filesystem, though, just mentioning it).

						-Matt





From dillon at apollo.backplane.com  Sun Mar  2 13:29:03 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Sun, 2 Mar 2008 13:29:03 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Misc. ACPI / suspend
In-Reply-To: <47CA073B.6020106@199technologies.org>
Message-ID: <200803022126.m22LQbfI037188@apollo.backplane.com>


:Wondering if anyone more well versed in the ACPI implementation could
:comment on the applicability of:
:
:http://lkml.org/lkml/2007/4/6/69
:
:w/r/t the current state of the art in Dfly
:
:(or BSD's in general)
:
:Cheers!
:
:- Chris

    I really have no idea re: this.  Suspension in general is not well
    supported by any of the BSDs.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From dillon at apollo.backplane.com  Sun Mar  2 13:34:05 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Sun, 2 Mar 2008 13:34:05 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: [Fwd: Project Support Open Source: $50 donation to support you      project]
In-Reply-To: <2468.192.168.0.242.1204346451.squirrel@www.shiningsilence.com>
Message-ID: <200803022131.m22LVOe9037250@apollo.backplane.com>

:..
:source project's web page.  I'm putting those words in scare quotes
:because I think it's a "payment" for an "advertisement".  The supplied
:link has nothing to do with DragonFly, to say the least.
:
:I don't think this is a good idea, obviously, and replied to that effect. 
:However, I wanted to put this on a DragonFly list, in part to show this
:strange thing, and in part because I'm not comfortable making
:administrative decisions on behalf of the Project without being open as
:possible about it.

    It doesn't really cry out to me either.

						-Matt





From wbh at conducive.org  Sun Mar  2 20:36:32 2008
From: wbh at conducive.org (Bill Hacker)
Date: Mon, 03 Mar 2008 04:36:32 +0000
Subject: Misc. ACPI / suspend
In-Reply-To: <47CA073B.6020106@199technologies.org>
Message-ID: <47cb8050$0$855$415eb37d@crater_reader.dragonflybsd.org>

Matthew Dillon wrote:
:Wondering if anyone more well versed in the ACPI implementation could
:comment on the applicability of:
:
:http://lkml.org/lkml/2007/4/6/69
:
:w/r/t the current state of the art in Dfly
:
:(or BSD's in general)
:
:Cheers!
:
:- Chris
    I really have no idea re: this.  Suspension in general is not well
    supported by any of the BSDs.
					-Matt
					Matthew Dillon 
					<dillon at backplane.com>


. . and there seems to be a bit of a 'Catch 22' there in any case.

If the BIOS can alter 'stuff' out of site of the OS it is parking, what 
does the existence of such a 'feature' do to a(ny) security model?

Seems to at least beg creating the option of setting a flag to 
specifically *prevent* suspend-to-disk/hibernation (and/or force a 
reboot on wake-up).

Just because one is paranoid....  etc

Bill





From matthias at dragonflybsd.org  Tue Mar  4 02:30:52 2008
From: matthias at dragonflybsd.org (Matthias Schmidt)
Date: Tue, 4 Mar 2008 02:30:52 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
Message-ID: <20080304102335.GI9833@staatsfeind.org>

Hi,

Google just announced its Summer of Code for 2008:

	http://code.google.com/soc/2008/

I think this would be a great opportunity for DragonFly to participate
as a mentoring organisation.  We could attract new developers and could
get code/work done.  Looking at the SoC results of the other BSDs most
of their projects were a success.  Of course, not all, but a reasonable
percentage.  See [1] and [2].

It is some extra work for us, but IMO the benefits outweigh the extra
work.  And yes, I would volunteer as a mentor.  What do others
(developers) think?  Any more volunteers? :)

Some project ideas that come into my mind.  More ideas are listed in the
wiki:  http://wiki.dragonflybsd.org/index.cgi/ProjectsPage

 * Fix all remaining bugs in dma(8) and implement all missing features
 * Add a driver for newer Intel Wireless cards (I think sephe@ would
   love that :)
 * Bring our ACPI stuff in shape.  Maybe suspend2disk ...

 * [Add your own thoughts here]

Cheers,

	Matthias

PS: I don't want to create a bikeshed here whether you like the SoC or
not :)

[1] http://code.google.com/soc/2007/freebsd/about.html
[2] http://code.google.com/soc/2007/netbsd/about.html




From corecode at fs.ei.tum.de  Tue Mar  4 04:46:14 2008
From: corecode at fs.ei.tum.de (Simon 'corecode' Schubert)
Date: Tue, 4 Mar 2008 04:46:14 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47CD4386.1000704@fs.ei.tum.de>

Matthias Schmidt wrote:
>  * [Add your own thoughts here]

MP lock removal for network stack

and for the system  (first profile, find hot spots, fix hot spots, repeat)

cheers
  simon




From c.turner at 199technologies.org  Tue Mar  4 06:02:20 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Tue, 4 Mar 2008 06:02:20 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47CD551E.1040604@199technologies.org>

Matthias Schmidt wrote:
Some project ideas that come into my mind.  More ideas are listed in the
wiki:  http://wiki.dragonflybsd.org/index.cgi/ProjectsPage
+1 acpi
+1 interrupt routing
+1 SMP / giant removal
+1 pf synchup with openbsd
though there are several others on the page that are good..

need to dig up my wiki login and place appropriately..

also: thinking the ZFS port should be removed from the page - makes 
sense to everyone else? (e.g. fragments effort w/r/t hammer)





From tgen at netphreax.net  Tue Mar  4 06:54:31 2008
From: tgen at netphreax.net (Thomas E. Spanjaard)
Date: Tue, 4 Mar 2008 06:54:31 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47CD615F.8010209@netphreax.net>

Matthias Schmidt wrote:
Google just announced its Summer of Code for 2008:

 * [Add your own thoughts here]
x86-64 port :).
--
        Thomas E. Spanjaard
        tgen at netphreax.net
Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00001.pgp
Type: application/octet-stream
Size: 186 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080304/0d921000/attachment-0003.obj>

From rdivacky at FreeBSD.org  Tue Mar  4 07:07:03 2008
From: rdivacky at FreeBSD.org (Roman Divacky)
Date: Tue, 4 Mar 2008 07:07:03 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <20080304150255.GA8831@freebsd.org>

On Tue, Mar 04, 2008 at 02:49:03PM +0000, Thomas E. Spanjaard wrote:
> Matthias Schmidt wrote:
> >Google just announced its Summer of Code for 2008:
> >
> > * [Add your own thoughts here]
> 
> x86-64 port :).

all those ideas are great and needed etc. but keep in
mind that the projects should be doable by students
who might see dfly for the very first time.

don't overestimate whats possible and select projects
that look realistic

Roman Divacky (former SoC student)




From justin at shiningsilence.com  Tue Mar  4 08:32:56 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Tue, 4 Mar 2008 08:32:56 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <60322.65.106.147.226.1204648095.squirrel@www.shiningsilence.com>

On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
> Hi,
>
> Google just announced its Summer of Code for 2008:
>
> 	http://code.google.com/soc/2008/
>
> I think this would be a great opportunity for DragonFly to participate
> as a mentoring organisation.  We could attract new developers and could
> get code/work done.  Looking at the SoC results of the other BSDs most
> of their projects were a success.  Of course, not all, but a reasonable
> percentage.  See [1] and [2].

We've applied in previous years - Jeff Hsu did one year, and I put
together the application last year.  The hardest thing to find was
students (and they are the thing that helps SoC applications a lot, I
think).

Any student volunteers?  We have mentors.





From rluciani at gmail.com  Tue Mar  4 09:38:29 2008
From: rluciani at gmail.com (Robert Luciani)
Date: Tue, 04 Mar 2008 18:38:29 +0100
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47cd8915$0$854$415eb37d@crater_reader.dragonflybsd.org>

Justin C. Sherrill wrote:
> On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
>> Hi,
>>
>> Google just announced its Summer of Code for 2008:
>>
>> 	http://code.google.com/soc/2008/
>>
>> I think this would be a great opportunity for DragonFly to participate
>> as a mentoring organisation.  We could attract new developers and could
>> get code/work done.  Looking at the SoC results of the other BSDs most
>> of their projects were a success.  Of course, not all, but a reasonable
>> percentage.  See [1] and [2].
> 
> We've applied in previous years - Jeff Hsu did one year, and I put
> together the application last year.  The hardest thing to find was
> students (and they are the thing that helps SoC applications a lot, I
> think).
> 
> Any student volunteers?  We have mentors.
> 

bingo

-- 
Robert Luciani
Chalmers University of Technology, SWE
Department of Computer Science and Engineering
http://www.rluciani.com/public.key




From sdavtaker at gmail.com  Tue Mar  4 09:31:08 2008
From: sdavtaker at gmail.com (=?UTF-8?Q?Sd=C3=A4vtaker?=)
Date: Tue, 4 Mar 2008 09:31:08 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <c37d69f60803040926k206218a3kb8496d0cd18148bd@mail.gmail.com>

If you mentor, i will apply for coder :-)
Still in last year of university. :-)
Sdav

On Tue, Mar 4, 2008 at 1:28 PM, Justin C. Sherrill
<justin at shiningsilence.com> wrote:
> On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
>  > Hi,
>  >
>  > Google just announced its Summer of Code for 2008:
>  >
>  >       http://code.google.com/soc/2008/
>  >
>  > I think this would be a great opportunity for DragonFly to participate
>  > as a mentoring organisation.  We could attract new developers and could
>  > get code/work done.  Looking at the SoC results of the other BSDs most
>  > of their projects were a success.  Of course, not all, but a reasonable
>  > percentage.  See [1] and [2].
>
>  We've applied in previous years - Jeff Hsu did one year, and I put
>  together the application last year.  The hardest thing to find was
>  students (and they are the thing that helps SoC applications a lot, I
>  think).
>
>  Any student volunteers?  We have mentors.
>
>



-- 
Sd?vtaker prays to Rikku goddess for a good treasure.



From rluciani at gmail.com  Tue Mar  4 09:44:02 2008
From: rluciani at gmail.com (Robert Luciani)
Date: Tue, 04 Mar 2008 18:44:02 +0100
Subject: google soc "DragonFly"
Message-ID: <47cd8a63$0$855$415eb37d@crater_reader.dragonflybsd.org>

On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
> > Hi,
> >
> > Google just announced its Summer of Code for 2008:
> >
> > 	http://code.google.com/soc/2008/
> >
> > I think this would be a great opportunity for DragonFly to participate
> > as a mentoring organisation.  We could attract new developers and could
> > get code/work done.  Looking at the SoC results of the other BSDs most
> > of their projects were a success.  Of course, not all, but a reasonable
> > percentage.  See [1] and [2].

We've applied in previous years - Jeff Hsu did one year, and I put
together the application last year.  The hardest thing to find was
students (and they are the thing that helps SoC applications a lot, I
think).

Any student volunteers?  We have mentors.


-- 
Robert Luciani
Chalmers University of Technology, SWE
Department of Computer Science and Engineering
http://www.rluciani.com/public.key




From rluciani at gmail.com  Tue Mar  4 10:04:14 2008
From: rluciani at gmail.com (Robert Luciani)
Date: Tue, 04 Mar 2008 19:04:14 +0100
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47cd8f1f$0$856$415eb37d@crater_reader.dragonflybsd.org>

Robert Luciani wrote:
> Justin C. Sherrill wrote:
>> On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
>>> Hi,
>>>
>>> Google just announced its Summer of Code for 2008:
>>>
>>> 	http://code.google.com/soc/2008/
>>>
>>> I think this would be a great opportunity for DragonFly to participate
>>> as a mentoring organisation.  We could attract new developers and could
>>> get code/work done.  Looking at the SoC results of the other BSDs most
>>> of their projects were a success.  Of course, not all, but a reasonable
>>> percentage.  See [1] and [2].
>> We've applied in previous years - Jeff Hsu did one year, and I put
>> together the application last year.  The hardest thing to find was
>> students (and they are the thing that helps SoC applications a lot, I
>> think).
>>
>> Any student volunteers?  We have mentors.
>>
> 
> bingo
> 
My girlfriend Danwei noted that she would also like partake in the SoC.
She's studying IT here at Chalmers and will join the mailing list shortly.
-- 
Robert Luciani
Chalmers University of Technology, SWE
Department of Computer Science and Engineering
http://www.rluciani.com/public.key




From dillon at apollo.backplane.com  Tue Mar  4 13:08:30 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Tue, 4 Mar 2008 13:08:30 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Going to have to roll 1.12.1
Message-ID: <200803042104.m24L43g1065278@apollo.backplane.com>

    Due to a critical bug in sendmail that can cause it to seg-fault I will
    be rolling 1.12.1 as soon as I get verification that the current
    fix deals with it.

						-Matt





From sdavtaker at gmail.com  Tue Mar  4 17:40:43 2008
From: sdavtaker at gmail.com (=?UTF-8?B?U2TDpHZ0YWtlcg==?=)
Date: Tue, 4 Mar 2008 17:40:43 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: [Fwd: Project Support Open Source: $50 donation to support you  project]
In-Reply-To: <2468.192.168.0.242.1204346451.squirrel@www.shiningsilence.com>
Message-ID: <47CDF8D1.9070100@gmail.com>

50 bucks?
Come on...
You can get a meal a lot more expensive than that just going to a free 
HP conference about linux and you only have to rent your soul 3-5 hours ;-)
Sdav

Matthew Dillon escribi?:
:..
:source project's web page.  I'm putting those words in scare quotes
:because I think it's a "payment" for an "advertisement".  The supplied
:link has nothing to do with DragonFly, to say the least.
:
:I don't think this is a good idea, obviously, and replied to that effect. 
:However, I wanted to put this on a DragonFly list, in part to show this
:strange thing, and in part because I'm not comfortable making
:administrative decisions on behalf of the Project without being open as
:possible about it.

    It doesn't really cry out to me either.

						-Matt

  






From sdavtaker at gmail.com  Tue Mar  4 17:56:35 2008
From: sdavtaker at gmail.com (=?UTF-8?B?U2TDpHZ0YWtlcg==?=)
Date: Tue, 4 Mar 2008 17:56:35 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47CDFCCE.1010106@gmail.com>

A cute idea for for GSOC would be to finish the installer.
We were talking about this in my local BUG, we trying to find out how to 
help on that from here.
There is a few missing features in the CD.

   * FDISK, you need to create the slides from another OS before
     install DFBSD, i think port FDisk from FBSD or any *BSD will solve it.
   * Add to the make release a way to add some custom applications to
     the released liveCD (suppose you want to add nmap or ssh or
     something just to use as test disk in some enviroment).
   * Make the installer a little more customizable, and maybe w/ a GUI
     (I like a lot the console approach, but GUI installer will be a
     popularity move, DFBSD w/X makes a Desktop machine work, actually
     im using it that way and really like it).
I think those projects can be done in a SOC by students (like me) with a 
little guide.
Im a lot more interested in things network related and kernel, but i 
dont mind to work on those things, they need to be done some day.
What u think?
Sdav

Robert Luciani escribi?:
Robert Luciani wrote:
  
Justin C. Sherrill wrote:
    
On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
      
Hi,

Google just announced its Summer of Code for 2008:

	http://code.google.com/soc/2008/

I think this would be a great opportunity for DragonFly to participate
as a mentoring organisation.  We could attract new developers and could
get code/work done.  Looking at the SoC results of the other BSDs most
of their projects were a success.  Of course, not all, but a reasonable
percentage.  See [1] and [2].
        
We've applied in previous years - Jeff Hsu did one year, and I put
together the application last year.  The hardest thing to find was
students (and they are the thing that helps SoC applications a lot, I
think).
Any student volunteers?  We have mentors.

      
bingo

    
My girlfriend Danwei noted that she would also like partake in the SoC.
She's studying IT here at Chalmers and will join the mailing list shortly.
  






From c.turner at 199technologies.org  Tue Mar  4 18:30:53 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Tue, 4 Mar 2008 18:30:53 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47CE04C9.1010902@199technologies.org>

Justin C. Sherrill wrote:
together the application last year.  The hardest thing to find was
students (and they are the thing that helps SoC applications a lot, I
think).
umm.. if google wants to send me back to school, I'll sign up - hows 
that for a fair trade :?






From wbh at conducive.org  Tue Mar  4 23:52:13 2008
From: wbh at conducive.org (Bill Hacker)
Date: Wed, 05 Mar 2008 07:52:13 +0000
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47ce512e$0$855$415eb37d@crater_reader.dragonflybsd.org>

Sd?vtaker wrote:
A cute idea for for GSOC would be to finish the installer.
We were talking about this in my local BUG, we trying to find out how to 
help on that from here.
There is a few missing features in the CD.

   * FDISK, you need to create the slides from another OS before
     install DFBSD, i think port FDisk from FBSD or any *BSD will solve it.
I'd rather see that 'reversed' - i.e. - build a more capable fdisk in 
DFLY with hope that it might be seen worth importing into Free/Net/Open, 
or *at least* be able to do a more flexible job than those now do.

And disklabels as well. Hand in glove.

Here's why:

- At the moment, working with Free, Open, DFLY, and OpenSolaris on the 
same HDD requires a bit of acrobatics.

- There seems to now be greater divergence between/among the *BSD's as 
to being able to read each other's disklabels, mount and use each 
other's 'flavor' of FFS/UFS (not to mention Apple's implementation of 
UFS) than there is among the vast multitude of Linux ext2/3 denizens.

Even to the point where use of a *Linux* fs is the more universal way 
for being able to share mounts among the *BSD's. Think detached drives. 
And no - FAT is not all that practical for several reasons.

- DFLY currently has the most fine-grain ability to create slices and 
partitions. But the others cannot all (any?) read those.

'progress' w/r any of the *BSD's direction as to changes, improvements 
(or not) in their once-common-ancestry fs & disklabels need not be 
sacrificed.

I'm not holding out wish or hope for all players agreeing to return to 
'one sacred way'. Nor 'one new universal fs'. Neither is gonna happen.

But a 'legacy compatible' or least-common-denominator mode would do fine 
- most especially for portable / SAN devices.

So - how about a 'flexible' DFLY fdisk to go along with a 'flexible' 
disklabel that could adapt to whatever it found / was told to create?

JM2CW - but that *might* be a good place to get a cross-*BSD team together.

*snip* (other good stuff)

Bill Hacker




From matthias at dragonflybsd.org  Wed Mar  5 01:02:43 2008
From: matthias at dragonflybsd.org (Matthias Schmidt)
Date: Wed, 5 Mar 2008 01:02:43 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <20080305085747.GJ9833@staatsfeind.org>

Hi,

* Justin C. Sherrill wrote:
> 
> We've applied in previous years - Jeff Hsu did one year, and I put
> together the application last year.  The hardest thing to find was
> students (and they are the thing that helps SoC applications a lot, I
> think).

This is good to know, so we could coordinate that if we have enough
mentors and projects?!?  I put together a small text in the wiki:

http://wiki.dragonflybsd.org/index.cgi/GoogleSoC2008

Feel free to add project or missing stuff.  I'm sure I missed a lot of
things :)

> Any student volunteers?  We have mentors.

According to the discussion we could have some students, who would be a
mentor (besides me)?

Regards

	Matthias





From sdavtaker at gmail.com  Wed Mar  5 06:28:37 2008
From: sdavtaker at gmail.com (=?UTF-8?Q?Sd=C3=A4vtaker?=)
Date: Wed, 5 Mar 2008 06:28:37 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <c37d69f60803050624kd86d3d0w3b44a02d0e5a5391@mail.gmail.com>

<quote>
Write a driver (from scratch) for Intel 3945 wireless device
Mentor: Sepherosa Ziehau
</quote>

Yes yes yes, i want to :-)
Someone else planning to mentor in drivers coding?
Sdav

On Wed, Mar 5, 2008 at 5:57 AM, Matthias Schmidt
<matthias at dragonflybsd.org> wrote:
> Hi,
>
>
>  * Justin C. Sherrill wrote:
>  >
>  > We've applied in previous years - Jeff Hsu did one year, and I put
>  > together the application last year.  The hardest thing to find was
>  > students (and they are the thing that helps SoC applications a lot, I
>  > think).
>
>  This is good to know, so we could coordinate that if we have enough
>  mentors and projects?!?  I put together a small text in the wiki:
>
>  http://wiki.dragonflybsd.org/index.cgi/GoogleSoC2008
>
>  Feel free to add project or missing stuff.  I'm sure I missed a lot of
>  things :)
>
>
>  > Any student volunteers?  We have mentors.
>
>  According to the discussion we could have some students, who would be a
>  mentor (besides me)?
>
>  Regards
>
>         Matthias
>
>



-- 
Sd?vtaker prays to Rikku goddess for a good treasure.



From rluciani at gmail.com  Wed Mar  5 10:56:42 2008
From: rluciani at gmail.com (Robert Luciani)
Date: Wed, 05 Mar 2008 19:56:42 +0100
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47ceecea$0$847$415eb37d@crater_reader.dragonflybsd.org>

Sd?vtaker wrote:
> <quote>
> Write a driver (from scratch) for Intel 3945 wireless device
> Mentor: Sepherosa Ziehau
> </quote>
> 
> Yes yes yes, i want to :-)
> Someone else planning to mentor in drivers coding?
> Sdav
> 
> On Wed, Mar 5, 2008 at 5:57 AM, Matthias Schmidt
> <matthias at dragonflybsd.org> wrote:
>> Hi,
>>
>>
>>  * Justin C. Sherrill wrote:
>>  >
>>  > We've applied in previous years - Jeff Hsu did one year, and I put
>>  > together the application last year.  The hardest thing to find was
>>  > students (and they are the thing that helps SoC applications a lot, I
>>  > think).
>>
>>  This is good to know, so we could coordinate that if we have enough
>>  mentors and projects?!?  I put together a small text in the wiki:
>>
>>  http://wiki.dragonflybsd.org/index.cgi/GoogleSoC2008
>>
>>  Feel free to add project or missing stuff.  I'm sure I missed a lot of
>>  things :)
>>
>>
>>  > Any student volunteers?  We have mentors.
>>
>>  According to the discussion we could have some students, who would be a
>>  mentor (besides me)?
>>
>>  Regards
>>
>>         Matthias
>>
>>
> 
> 
>

IF someone starts to write a 3945 Intel driver,
please keep the newer 4965 in mind too.

-- 
Robert Luciani
Chalmers University of Technology, SWE
Department of Computer Science and Engineering
http://www.rluciani.com/public.key




From joerg at britannica.bec.de  Wed Mar  5 12:01:05 2008
From: joerg at britannica.bec.de (Joerg Sonnenberger)
Date: Wed, 5 Mar 2008 12:01:05 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <20080305195711.GA9981@britannica.bec.de>

On Wed, Mar 05, 2008 at 07:56:42PM +0100, Robert Luciani wrote:
> IF someone starts to write a 3945 Intel driver,
> please keep the newer 4965 in mind too.

NetBSD's wpi works quite well. The hardware is quite different from
4945.

Joerg




From sepherosa at gmail.com  Wed Mar  5 17:48:50 2008
From: sepherosa at gmail.com (Sepherosa Ziehau)
Date: Wed, 5 Mar 2008 17:48:50 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <ea7b9c170803051744u22b09484ofc994f034f11df3b@mail.gmail.com>

On Thu, Mar 6, 2008 at 2:56 AM, Robert Luciani <rluciani at gmail.com> wrote:
>  IF someone starts to write a 3945 Intel driver,

"IF" you know that trying to fix any wired bugs in certain drivers
(e.g. ipw, ral) will require you to read through all of the vendor's
linux code (yes, even including register values and position), i.e.
there is not much difference between writing one from scratch and
porting+fixing_bugs, then you probably will not put "IF" at the start
of your sentence.
If what I said sounded too harsh to you, then I was sorry.

>  please keep the newer 4965 in mind too.

Will do, once generic 11n support is brought in from freebsd.

Best Regards,
sephe

-- 
Live Free or Die




From saw at online.de  Thu Mar  6 05:34:14 2008
From: saw at online.de (Sascha Wildner)
Date: Thu, 06 Mar 2008 14:34:14 +0100
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
Message-ID: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>

Hi all,

this is probably as good a moment as any to come out of the forest with 
this. The patch at

http://leaf.dragonflybsd.org/~swildner/nrelease_gui.diff

adds some code to nrelease/ to build a LiveCD with xorg and so on 
(currently, only the xorg metapackages and fluxbox are added). In order 
to build one, you need a local dir with the pkgsrc binary packages (see 
below).

The following commands should then do the trick:

cd /usr/src
make buildworld
make buildkernel
cd nrelease
patch -p 0 </path/to/the/patch
make PKGSRC_PKG_PATH=/path/to/packages/dir/All realquick gui
The resulting ISO will be in /usr/release/dfly-gui.iso then. It will not 
boot into xorg automatically (although this is easily possible), so you 
need to login as root and do startx.

As of now, this all is kind of basic, more a proof of concept than 
anything else. As our release framework installs packages via chroot, 
the current setup just copies _all_ packages to the chroot before 
installing (kind of a hack).

That said, I'm now primarily interested in opinions/ideas/... about the 
direction this should take. Which packages would we like to see on the 
CD? Should it be a generic setup with the "most common things" 
installed, so a system can be quickly setup by the installer (which will 
cpdup /usr/pkg). Or should it be a more specialized set of tools? Or 
even as many packages as possible (Live DVD?). Etc., etc.

Before continuing on it, I'm really interested in people's input so 
don't hold anything back, please. :)

Sascha

--
http://yoyodyne.ath.cx



From rluciani at gmail.com  Thu Mar  6 06:42:03 2008
From: rluciani at gmail.com (Robert Luciani)
Date: Thu, 06 Mar 2008 15:42:03 +0100
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <47d002bc$0$847$415eb37d@crater_reader.dragonflybsd.org>

Sascha Wildner wrote:
> Hi all,
> 
> this is probably as good a moment as any to come out of the forest with
> this. The patch at
> 
> http://leaf.dragonflybsd.org/~swildner/nrelease_gui.diff
> 
> adds some code to nrelease/ to build a LiveCD with xorg and so on
> (currently, only the xorg metapackages and fluxbox are added). In order
> to build one, you need a local dir with the pkgsrc binary packages (see
> below).
> 
> The following commands should then do the trick:
> 
> cd /usr/src
> make buildworld
> make buildkernel
> cd nrelease
> patch -p 0 </path/to/the/patch
> make PKGSRC_PKG_PATH=/path/to/packages/dir/All realquick gui
> 
> The resulting ISO will be in /usr/release/dfly-gui.iso then. It will not
> boot into xorg automatically (although this is easily possible), so you
> need to login as root and do startx.
> 
> As of now, this all is kind of basic, more a proof of concept than
> anything else. As our release framework installs packages via chroot,
> the current setup just copies _all_ packages to the chroot before
> installing (kind of a hack).
> 
> That said, I'm now primarily interested in opinions/ideas/... about the
> direction this should take. Which packages would we like to see on the
> CD? Should it be a generic setup with the "most common things"
> installed, so a system can be quickly setup by the installer (which will
> cpdup /usr/pkg). Or should it be a more specialized set of tools? Or
> even as many packages as possible (Live DVD?). Etc., etc.
> 
> Before continuing on it, I'm really interested in people's input so
> don't hold anything back, please. :)
> 
> Sascha
> 

I think the main point of such a live-cd would be to test
dragonfly-specific features such as vkernels and more. Mplayer and
OpenOffic work the same on all platforms, so they might not be super
important, while irssi, firefox, networking tools, vim, a few more
shells/terminals might make it easier to for people to quickly gauge if
they can reproduce their current productivity and also what is new.

And if the point of a livecd is to test that kind of stuff, then it
would be nice for it to have a kernel that supports as much as possible
like ALTQ, and drivers.

Also if it has lots and lots of programs (thinking multimedia, java,
etc..) it might be hard to keep the future x64 and x86 live-cds on par.
Gentoo had this problem many years ago and it was very bothersome.

-- 
Robert Luciani
Chalmers University of Technology, SWE
Department of Computer Science and Engineering
http://www.rluciani.com/public.key




From matthias at dragonflybsd.org  Thu Mar  6 07:12:43 2008
From: matthias at dragonflybsd.org (Matthias Schmidt)
Date: Thu, 6 Mar 2008 07:12:43 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <20080306150757.GN9833@staatsfeind.org>

* Sascha Wildner wrote:
> Hi all,
> 
> this is probably as good a moment as any to come out of the forest with this. 
> The patch at
> 
> http://leaf.dragonflybsd.org/~swildner/nrelease_gui.diff
> 
> adds some code to nrelease/ to build a LiveCD with xorg and so on (currently, 
> only the xorg metapackages and fluxbox are added). In order to build one, you 
> need a local dir with the pkgsrc binary packages (see below).

Great work Sascha.

I agree with Robert on most of his stated points.
It would be nice to see some DragonFly specific features on the CD
(although I'm not sure if that will work for all features).  A little
environment where most Unix users feel at home (fluxbox, xfce, firefox,
thunderbird, gvim) should be enough.

Big applications like OO.org, java etc won't work because they are not
available as pkgsrc packages neither is it possible to compile them on
DragonFly.  At least to my knowledge.

Regards

	Matthias




From dillon at apollo.backplane.com  Thu Mar  6 09:31:52 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Thu, 6 Mar 2008 09:31:52 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <200803061728.m26HSR3O091809@apollo.backplane.com>


:Hi all,
:
:this is probably as good a moment as any to come out of the forest with 
:this. The patch at
:
:http://leaf.dragonflybsd.org/~swildner/nrelease_gui.diff
:
:adds some code to nrelease/ to build a LiveCD with xorg and so on 
:(currently, only the xorg metapackages and fluxbox are added). In order 
:to build one, you need a local dir with the pkgsrc binary packages (see 
:below).
:
:The following commands should then do the trick:

    It looks reasonable, though the package copy has to be tightened
    up a bit I think.

:...
:installed, so a system can be quickly setup by the installer (which will 
:cpdup /usr/pkg). Or should it be a more specialized set of tools? Or 
:even as many packages as possible (Live DVD?). Etc., etc.
:
:Before continuing on it, I'm really interested in people's input so 
:don't hold anything back, please. :)
:
:Sascha

    I think this is an excellent time to work up a DVD build and to
    add various 'flavor' extras.  So, e.g.:

	make installer gui gui_extras release dvd

    (All 'dvd' would do is generate a dvd compatible image for burning to
    dvd instead of cd).  I did a quick perusal of what I have on my
    workstation:

    * X
    * Firefox
    * Linux emulation
    * Open Office (linux version)
    * fvwm2
    * xpdf
    * freetype2

    I'd also suggest some image editing tools like gimp, and maybe the KDE
    gui suite.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From justin at shiningsilence.com  Thu Mar  6 09:42:44 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Thu, 6 Mar 2008 09:42:44 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <55427.65.106.147.226.1204825168.squirrel@www.shiningsilence.com>

On Thu, March 6, 2008 8:34 am, Sascha Wildner wrote:

> That said, I'm now primarily interested in opinions/ideas/... about the
> direction this should take. Which packages would we like to see on the
> CD? Should it be a generic setup with the "most common things"
> installed, so a system can be quickly setup by the installer (which will
> cpdup /usr/pkg). Or should it be a more specialized set of tools? Or
> even as many packages as possible (Live DVD?). Etc., etc.

What Robert said is good - whatever's needed to enable DragonFly-specific
features.  Along with that would be some sort of documentation (a README? 
A HTML file on whatever desktop we provide) that points people at the
different DragonFly tools, so they know what to try and how to try it.

There's going to be some percentage of people who try DragonFly who don't
know about vkernels, for instance, but there's our chance to educate them.
 I'm probably volunteering myself, aren't I?





From sdavtaker at gmail.com  Thu Mar  6 09:50:09 2008
From: sdavtaker at gmail.com (=?UTF-8?Q?Sd=C3=A4vtaker?=)
Date: Thu, 6 Mar 2008 09:50:09 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <c37d69f60803060947t110750c0sd6b542ea505d188d@mail.gmail.com>

Cool Sascha :-)
I just posted about this 1 or 2 days ago in the SOC project ideas thread.
Want to mentor this one? ;-)
Damian

On Thu, Mar 6, 2008 at 2:28 PM, Matthew Dillon
<dillon at apollo.backplane.com> wrote:
>
>  :Hi all,
>
> :
>  :this is probably as good a moment as any to come out of the forest with
>  :this. The patch at
>  :
>  :http://leaf.dragonflybsd.org/~swildner/nrelease_gui.diff
>  :
>  :adds some code to nrelease/ to build a LiveCD with xorg and so on
>  :(currently, only the xorg metapackages and fluxbox are added). In order
>  :to build one, you need a local dir with the pkgsrc binary packages (see
>  :below).
>  :
>  :The following commands should then do the trick:
>
>     It looks reasonable, though the package copy has to be tightened
>     up a bit I think.
>
>  :...
>  :installed, so a system can be quickly setup by the installer (which will
>
> :cpdup /usr/pkg). Or should it be a more specialized set of tools? Or
>  :even as many packages as possible (Live DVD?). Etc., etc.
>  :
>  :Before continuing on it, I'm really interested in people's input so
>  :don't hold anything back, please. :)
>  :
>  :Sascha
>
>     I think this is an excellent time to work up a DVD build and to
>     add various 'flavor' extras.  So, e.g.:
>
>         make installer gui gui_extras release dvd
>
>     (All 'dvd' would do is generate a dvd compatible image for burning to
>     dvd instead of cd).  I did a quick perusal of what I have on my
>     workstation:
>
>     * X
>     * Firefox
>     * Linux emulation
>     * Open Office (linux version)
>     * fvwm2
>     * xpdf
>     * freetype2
>
>     I'd also suggest some image editing tools like gimp, and maybe the KDE
>     gui suite.
>
>                                         -Matt
>                                         Matthew Dillon
>                                         <dillon at backplane.com>
>



-- 
Sd?vtaker prays to Rikku goddess for a good treasure.



From saw at online.de  Thu Mar  6 11:54:01 2008
From: saw at online.de (Sascha Wildner)
Date: Thu, 06 Mar 2008 20:54:01 +0100
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <47d04ba2$0$856$415eb37d@crater_reader.dragonflybsd.org>

Matthew Dillon wrote:
    It looks reasonable, though the package copy has to be tightened
    up a bit I think.
It looks as if it would work with mount_null'ing the chroot's 
/tmp/packages. I'll have a better patch ready tomorrow.

Sascha

--
http://yoyodyne.ath.cx



From c.turner at 199technologies.org  Thu Mar  6 19:11:44 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Thu, 6 Mar 2008 19:11:44 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Misc. ACPI / suspend
In-Reply-To: <47CA073B.6020106@199technologies.org>
Message-ID: <47D0B079.3060905@199technologies.org>

Chris Turner wrote:
Wondering if anyone more well versed in the ACPI implementation could
comment on the applicability of:
http://lkml.org/lkml/2007/4/6/69

Doing a little digging, it seems like

. /platform/pc32/i386/i686_mem.c

*might* have the necessary infrastructure to remap the MTRR's per the 
thread referenced,

but:

. /platform/pc32/acpica5/acpi_wakeup.c

doesn't seem to be using this infrastructure..

I'm no where near reaching an understanding of this yet,
but I'm wondering 3 things:
1) does anyone have ACPI (instead of APM)
   sleep / suspend / wakeup working on Dfly ?
2) If so, what machines are being used ?
3) Same question for other BSDs - my understanding is NetBSD is most
   'advanced' w/r/t power managment - but I'm not 100% on this ...
would looove to have a sleeping / resuming / scaling laptop running some 
BSD flavor.. am willing to work towards that end, esp. w/r/t Dfly -
trying to chart a course to figguring this out.

Thanks all,

- Chris




From c.turner at 199technologies.org  Thu Mar  6 19:12:33 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Thu, 6 Mar 2008 19:12:33 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: PCI Bios / Interrupt remapping / etc
Message-ID: <47D0B211.6000002@199technologies.org>

Doing a bit of digging here for my long-standing CBB+SIO interupt and 
buffer problem -

one machine I've tested against was an OpenBSD machine, which didn't
always work to handle the cardbus sio card on a PCI cardbus adapter
-

tuning up some of the device flags in:

http://www.openbsd.org/cgi-bin/man.cgi?query=pcibios&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=html

seems to have alleviated the problem for that os..

I'm just only starting to get up to speed on how DF handles these types 
of things (namely initial PIC / interrupt layout at boot time device 
enumeration), but am wondering if anyone familiar with this area of the 
code has any comments / advice w/r/t the capabilities of the DF bios 
drivers
and the various quirks / fixup mentioned in the link above..

looking to possibly investigate fixing up some of these issues over time.

Thanks

- Chris







From pavalos at theshell.com  Fri Mar  7 01:14:55 2008
From: pavalos at theshell.com (Peter Avalos)
Date: Fri, 7 Mar 2008 01:14:55 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: cam locking
Message-ID: <20080307091024.GC1652@ylem.theshell.com>

So I've been working on locking up cam using lockmgr locks, and here's
what I have so far:

http://www.theshell.com/~pavalos/wip/cam-lock.patch

Most of the work is obtained from FreeBSD.  I've only been running this
on my SCSI machine for a day, but because the patch is so large, I wanted
to make it available for people to review if they have some spare time.

Thanks,
Peter
Attachment:
pgp00002.pgp
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00002.pgp
Type: application/octet-stream
Size: 197 bytes
Desc: "Description: PGP signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080307/9a17ecd8/attachment-0003.obj>

From jspringe at uos.de  Fri Mar  7 03:25:17 2008
From: jspringe at uos.de (Jost Tobias Springenberg)
Date: Fri, 7 Mar 2008 12:25:17 +0100
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <20080307122517.72c9e2b1.jspringe@uos.de>

On Tue, 4 Mar 2008 11:28:15 -0500 (EST)
"Justin C. Sherrill" <justin at shiningsilence.com> wrote:

> On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
> > Hi,
> >
> > Google just announced its Summer of Code for 2008:
> >
> > 	http://code.google.com/soc/2008/
> >
> > I think this would be a great opportunity for DragonFly to participate
> > as a mentoring organisation.  We could attract new developers and could
> > get code/work done.  Looking at the SoC results of the other BSDs most
> > of their projects were a success.  Of course, not all, but a reasonable
> > percentage.  See [1] and [2].
> 
> We've applied in previous years - Jeff Hsu did one year, and I put
> together the application last year.  The hardest thing to find was
> students (and they are the thing that helps SoC applications a lot, I
> think).
> 
> Any student volunteers?  We have mentors.
> 

I read this mailing list for quite a while now and thought about contributing stuff
to DFfly several times, so yes why not take this opportunity if it's there.

-- 
Jost Tobias Springenberg <jspringe at uos.de>




From tgen at netphreax.net  Fri Mar  7 05:17:27 2008
From: tgen at netphreax.net (Thomas E. Spanjaard)
Date: Fri, 7 Mar 2008 05:17:27 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: PCI Bios / Interrupt remapping / etc
In-Reply-To: <47D0B211.6000002@199technologies.org>
Message-ID: <47D13FB4.5080306@netphreax.net>

Chris Turner wrote:
Doing a bit of digging here for my long-standing CBB+SIO interupt and 
buffer problem -

one machine I've tested against was an OpenBSD machine, which didn't
always work to handle the cardbus sio card on a PCI cardbus adapter
-

tuning up some of the device flags in:

http://www.openbsd.org/cgi-bin/man.cgi?query=pcibios&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=html 

seems to have alleviated the problem for that os..

I'm just only starting to get up to speed on how DF handles these types 
of things (namely initial PIC / interrupt layout at boot time device 
enumeration), but am wondering if anyone familiar with this area of the 
code has any comments / advice w/r/t the capabilities of the DF bios 
drivers
and the various quirks / fixup mentioned in the link above..

looking to possibly investigate fixing up some of these issues over time.
Our code that handles issues like this (in cases where you're not using 
APICs, just PICs and PIRs) lives in bus/pci/i386/. Not that running 
without APIC support is all that common on modern machines anymore...
--
        Thomas E. Spanjaard
        tgen at netphreax.net
Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00003.pgp
Type: application/octet-stream
Size: 186 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080307/61366b5c/attachment-0003.obj>

From tgen at netphreax.net  Fri Mar  7 05:16:51 2008
From: tgen at netphreax.net (Thomas E. Spanjaard)
Date: Fri, 7 Mar 2008 05:16:51 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Misc. ACPI / suspend
In-Reply-To: <47CA073B.6020106@199technologies.org>
Message-ID: <47D13F07.9080308@netphreax.net>

Chris Turner wrote:
1) does anyone have ACPI (instead of APM)
   sleep / suspend / wakeup working on Dfly ?
2) If so, what machines are being used ?
3) Same question for other BSDs - my understanding is NetBSD is most
   'advanced' w/r/t power managment - but I'm not 100% on this ...
would looove to have a sleeping / resuming / scaling laptop running some 
BSD flavor.. am willing to work towards that end, esp. w/r/t Dfly -
trying to chart a course to figguring this out.
I have ACPI S3 suspend working like a charm on my IBM ThinkPad R40 
(Pentium M "Banias" 1.3GHz, speedstepping works just fine), running 
NetBSD 3.99.21.
--
        Thomas E. Spanjaard
        tgen at netphreax.net
Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00004.pgp
Type: application/octet-stream
Size: 186 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080307/de3e5104/attachment-0003.obj>

From civilizd at gmail.com  Fri Mar  7 09:06:41 2008
From: civilizd at gmail.com (Vita "CiV" Cizek)
Date: Fri, 7 Mar 2008 09:06:41 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <98d564710803070853q1c73d795m6e6c5cc5049fa099@mail.gmail.com>

>  Any student volunteers?  We have mentors.
>
I am interested too, especially in some kernel-related work.




From justin at shiningsilence.com  Sat Mar  8 12:07:51 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Sat, 8 Mar 2008 12:07:51 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google SoC 2008 - mentors mentors mentors
Message-ID: <51558.192.168.0.252.1205006403.squirrel@www.shiningsilence.com>

If you are willing to mentor for the Google 2008 Summer of Code, please
speak up.  Right now we have: (from our wiki page)

Matthias
Sephe
TGEN
corecode

Part of the application process includes naming people as mentors (student
applications come later), so I want to get as complete a list as possible.

The application is due on the 12th, so if you want to mentor, now's the
time to say so.

Google's SoC FAQ is here: http://code.google.com/soc/2008/faqs.html

Our wiki page is here: http://wiki.dragonflybsd.org/index.cgi/GoogleSoC2008

- much credit to Matthias and others for getting that set up.





From saw at online.de  Sat Mar  8 14:26:07 2008
From: saw at online.de (Sascha Wildner)
Date: Sat, 08 Mar 2008 23:26:07 +0100
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <47d31245$0$848$415eb37d@crater_reader.dragonflybsd.org>

Sascha Wildner wrote:
Hi all,

this is probably as good a moment as any to come out of the forest with 
this. The patch at

http://leaf.dragonflybsd.org/~swildner/nrelease_gui.diff
Ok, I have committed the stuff as an example.

I'm not sure if my free time permits to work on a full-blown live CD 
with X11 and other good things (I already feel my interest wandering off 
in other directions) so if anyone wants to pick up the ball, go ahead. :)

Sascha

--
http://yoyodyne.ath.cx



From qhwt+dfly at les.ath.cx  Tue Mar 11 22:21:31 2008
From: qhwt+dfly at les.ath.cx (YONETANI Tomokazu)
Date: Tue, 11 Mar 2008 22:21:31 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Misc. ACPI / suspend
In-Reply-To: <47CA073B.6020106@199technologies.org>
Message-ID: <20080312051219.GA56091@les.ath.cx>

On Thu, Mar 06, 2008 at 10:03:21PM -0500, Chris Turner wrote:
> 1) does anyone have ACPI (instead of APM)
>    sleep / suspend / wakeup working on Dfly ?
> 2) If so, what machines are being used ?

Dynabook SS3500 (http://www.tlt.co.jp/pc/catalog/ss/02110735/index_j.htm).
It's old and can get very hot(thus frequently turns on the cooling fan)
even when it's running Windows.  I haven't turned it on for about several
months though.

Cheers.




From c.turner at 199technologies.org  Wed Mar 12 04:37:22 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Wed, 12 Mar 2008 04:37:22 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Misc. ACPI / suspend
In-Reply-To: <47CA073B.6020106@199technologies.org>
Message-ID: <47D7BEE3.6010907@199technologies.org>

YONETANI Tomokazu wrote:
On Thu, Mar 06, 2008 at 10:03:21PM -0500, Chris Turner wrote:
1) does anyone have ACPI (instead of APM)
   sleep / suspend / wakeup working on Dfly ?
Cheers.
ditto..

Suppose this should go to docs@ - in any case..

Thinking about setting up a wiki page on the issue so we
can discuss / track what 'good' hardware / drivers / implementations / 
etc are 'out there' - anyone have any suggestions on where this should
go?

http://wiki.dragonflybsd.org/index.cgi/acpi-overview.html

Remains from the handbook conversion - but I'm hesitant to 'over wikify'
this ..



From c.turner at 199technologies.org  Wed Mar 12 15:36:52 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Wed, 12 Mar 2008 15:36:52 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: devel/cscope
Message-ID: <47D85A08.8040103@199technologies.org>

why oh why did I take so long to try this out !!!

just sharing my eureka moment with the list..

- Chris




From dudu at dudu.ro  Wed Mar 12 15:50:14 2008
From: dudu at dudu.ro (Vlad GALU)
Date: Wed, 12 Mar 2008 15:50:14 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: devel/cscope
In-Reply-To: <47D85A08.8040103@199technologies.org>
Message-ID: <ad79ad6b0803121547r2bf67ffep9e40badaac6490f8@mail.gmail.com>

On 3/13/08, Chris Turner <c.turner at 199technologies.org> wrote:
> why oh why did I take so long to try this out !!!
>
>  just sharing my eureka moment with the list..


    Works nice with vim, too!

>
>
>  - Chris
>


-- 
Mahnahmahnah!




From justin at shiningsilence.com  Sun Mar 16 21:06:13 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Sun, 16 Mar 2008 21:06:13 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: binary packages for 1.12 coming in
Message-ID: <1372.192.168.0.252.1205726088.squirrel@www.shiningsilence.com>

The binary build for 1.12 is taking quite a while.  I've started copying
in newly built packages to
pkgbox.dragonflybsd.org/packages/DragonFly-1.12/i386/ - this should be
getting copied out to mirrors over the next while.

There are currently 1283 packages built, which leaves a whole lot to go;
I'll copy new packages in as they complete.





From hasso at estpak.ee  Wed Mar 19 04:31:08 2008
From: hasso at estpak.ee (Hasso Tepper)
Date: Wed, 19 Mar 2008 04:31:08 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Some questions regarding ACPI
Message-ID: <200803191322.46366.hasso@estpak.ee>

I'm working on bringing in some laptop (and especially thinkpad) specific 
ACPI code from FreeBSD into DragonFly. I never touched ACPI stuff before 
and haven't followed it much either, so I have some questions.

* FreeBSD uses ACPI_SERIAL_* heavily. What's the locking situation in 
  DragonFly and why?

* As far as I can see, PCI integration is commented out in DragonFly. 
  What's the state of it and why?

* platform/pc32/acpica5/acpi_toshiba.c - why is it there? I don't think 
  that this is something pc32 specific in it and it should work in pc64 
  laptops as well. Any objections to move it into 
  dev/acpica5/acpi_toshiba/ ?

What's the current status of ACPI in general? AFAICS our acpica is quite 
old - what needs to be done to bring in newer one?


-- 
Hasso




From qhwt+dfly at les.ath.cx  Wed Mar 19 09:24:50 2008
From: qhwt+dfly at les.ath.cx (YONETANI Tomokazu)
Date: Wed, 19 Mar 2008 09:24:50 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Some questions regarding ACPI
In-Reply-To: <200803191322.46366.hasso@estpak.ee>
Message-ID: <20080319161703.GA51509@les.ath.cx>

On Wed, Mar 19, 2008 at 01:22:46PM +0200, Hasso Tepper wrote:
> I'm working on bringing in some laptop (and especially thinkpad) specific 
> ACPI code from FreeBSD into DragonFly. I never touched ACPI stuff before 
> and haven't followed it much either, so I have some questions.

So you want to port some of ACPI support drivers, or to do a fresh port
of ACPI driver from FreeBSD?

> * FreeBSD uses ACPI_SERIAL_* heavily. What's the locking situation in 
>   DragonFly and why?

The current ACPI driver in DragonFly is based on that of FreeBSD as of
end of June, 2004, plus some fixes brought in later (and ACPICA part
has been updated twice since then).  That was before they introduced
the MPSAFE changes into ACPI code, and we use critical section
(crit_{enter,exit}) in most places (and lockmgr lock in a few place).

> * As far as I can see, PCI integration is commented out in DragonFly. 
>   What's the state of it and why?

When we replaced the implementation taken from FreeBSD 4.x with that
brought from FreeBSD 5.x, which added the PCI part, many people
experienced problems until they turned off ACPI completely, or add "pci"
to "debug.acpi.disabled" loader variable.  AFAIK the PCI part in the ACPI
driver almost hasn't been adjusted to work with our version of PCI code.

> * platform/pc32/acpica5/acpi_toshiba.c - why is it there? I don't think 
>   that this is something pc32 specific in it and it should work in pc64 
>   laptops as well. Any objections to move it into 
>   dev/acpica5/acpi_toshiba/ ?

In FreeBSD it used to be sitting at i386/acpica/acpi_toshiba.c and was
later moved into acpi_support.  That change hasn't hit our tree (in fact,
we have no acpi support drivers other than that).  It seems that FreeBSD
has them in dev/acpi_support now, and we for some reason have that
directory in our CVS repository (but containing no files in it).

> What's the current status of ACPI in general? AFAICS our acpica is quite 
> old - what needs to be done to bring in newer one?

Actually, it's not very important to keep just ACPICA latest, but
if you bring the ACPI driver from FreeBSD you need to bring ACPICA code
that matches their version, and it IS important.  And it generally requires
you much work to just update ACPICA part anyway because of how they
change things on every release.

Cheers.




From hasso at estpak.ee  Wed Mar 19 12:29:52 2008
From: hasso at estpak.ee (Hasso Tepper)
Date: Wed, 19 Mar 2008 12:29:52 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Some questions regarding ACPI
In-Reply-To: <200803191322.46366.hasso@estpak.ee>
Message-ID: <200803192115.35396.hasso@estpak.ee>

YONETANI Tomokazu wrote:
> On Wed, Mar 19, 2008 at 01:22:46PM +0200, Hasso Tepper wrote:
> > I'm working on bringing in some laptop (and especially thinkpad)
> > specific ACPI code from FreeBSD into DragonFly. I never touched ACPI
> > stuff before and haven't followed it much either, so I have some
> > questions.
>
> So you want to port some of ACPI support drivers, or to do a fresh port
> of ACPI driver from FreeBSD?

I'm only interested in support drivers and the reason is pure practical - 
newer thinkpads handle less and less hotkeys etc in hardware and require 
support form OS. acpi_ibm and acpi_video are examples of such modules 
which would help a lot of these newer thinkpad users.

acpi_ibm is almost ready to commit (renamed to acpi_thinkpad though).

> > * FreeBSD uses ACPI_SERIAL_* heavily. What's the locking situation in
> >   DragonFly and why?
>
> The current ACPI driver in DragonFly is based on that of FreeBSD as of
> end of June, 2004, plus some fixes brought in later (and ACPICA part
> has been updated twice since then).  That was before they introduced
> the MPSAFE changes into ACPI code, and we use critical section
> (crit_{enter,exit}) in most places (and lockmgr lock in a few place).

Mkay. Will look at more closely.

> > * As far as I can see, PCI integration is commented out in DragonFly.
> >   What's the state of it and why?
>
> When we replaced the implementation taken from FreeBSD 4.x with that
> brought from FreeBSD 5.x, which added the PCI part, many people
> experienced problems until they turned off ACPI completely, or add
> "pci" to "debug.acpi.disabled" loader variable.  AFAIK the PCI part in
> the ACPI driver almost hasn't been adjusted to work with our version of
> PCI code.

I'm afraid that it's beyond my skills, but while looking at acpi_video I 
discovered that it's hard to handle correctly without PCI support.

> > * platform/pc32/acpica5/acpi_toshiba.c - why is it there? I don't
> > think that this is something pc32 specific in it and it should work
> > in pc64 laptops as well. Any objections to move it into
> >   dev/acpica5/acpi_toshiba/ ?
>
> In FreeBSD it used to be sitting at i386/acpica/acpi_toshiba.c and was
> later moved into acpi_support.  That change hasn't hit our tree (in
> fact, we have no acpi support drivers other than that).  It seems that
> FreeBSD has them in dev/acpi_support now, and we for some reason have
> that directory in our CVS repository (but containing no files in it).

I don't see it ;). Makes sense though. So, any objections if I move 
acpi_toshiba into sys/dev/acpi_support and add new acpi_thinkpad there as 
well? 

> > What's the current status of ACPI in general? AFAICS our acpica is
> > quite old - what needs to be done to bring in newer one?
>
> Actually, it's not very important to keep just ACPICA latest, but
> if you bring the ACPI driver from FreeBSD you need to bring ACPICA code
> that matches their version, and it IS important.  And it generally
> requires you much work to just update ACPICA part anyway because of how
> they change things on every release.

Someone else has to do it :).

Thanks for info.


-- 
Hasso




From dillon at apollo.backplane.com  Wed Mar 19 14:01:13 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Wed, 19 Mar 2008 14:01:13 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: panic: assertion: hammer_btree_cmp(cursor->left_bound,	&cursor->node->ondisk->elms[0].leaf.base) <= 0 in btree_split_leaf
In-Reply-To: <200802232204.m1NM4cxd046264@apollo.backplane.com>
Message-ID: <200803192054.m2JKsjwn045137@apollo.backplane.com>


:Hi.
:While trying to find a procedure to reliably reproduce the panic
:I reported last time, I caught a different panic (uploaded at
: ~y0netan1/crash/9/ on my leaf account).  I wrote the following shell
:script (make sure to edit variables DISKS and MOUNTPT before using this
:script or it may trash your system):
:  #!/bin/sh -ex
:  DISKS="/dev/ad0s1f"
:  MOUNTPT=/mnt/HAMMER
:
:  cd /
:  newfs_hammer -L TEST $DISKS
:  for i in `seq 1 100`; do
:..
:And the panic is triggered by rm command.
:I'll try to see if it's possible to reproduce the last one without
:unmounting then mounting the HAMMER fs.
:
:Cheers.

    I believe I have fixed this panic.  hammer_make_separator() had a bug
    in it.

    There is still an issue with the node ref count on umount.

    Please continue to life-test the code.  The reblocking code
    (hammer reblock /mnt) should work now, as should the pruning code
    (e.g. hammer prune /mnt everything).

    The filesystem full case is still not handled and will cause bad things
    to happen.  The undo code isn't finished yet either but it is getting
    there (it's writing stuff out but not setting the sequence number and
    not trying to recover-on-mount yet).

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From qhwt+dfly at les.ath.cx  Wed Mar 19 19:45:40 2008
From: qhwt+dfly at les.ath.cx (YONETANI Tomokazu)
Date: Wed, 19 Mar 2008 19:45:40 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Some questions regarding ACPI
In-Reply-To: <200803191322.46366.hasso@estpak.ee>
Message-ID: <20080320023828.GA53648@les.ath.cx>

On Wed, Mar 19, 2008 at 09:15:35PM +0200, Hasso Tepper wrote:
> YONETANI Tomokazu wrote:
> > On Wed, Mar 19, 2008 at 01:22:46PM +0200, Hasso Tepper wrote:
> > > I'm working on bringing in some laptop (and especially thinkpad)
> > > specific ACPI code from FreeBSD into DragonFly. I never touched ACPI
> > > stuff before and haven't followed it much either, so I have some
> > > questions.
> >
> > So you want to port some of ACPI support drivers, or to do a fresh port
> > of ACPI driver from FreeBSD?
> 
> I'm only interested in support drivers and the reason is pure practical - 
> newer thinkpads handle less and less hotkeys etc in hardware and require 
> support form OS. acpi_ibm and acpi_video are examples of such modules 
> which would help a lot of these newer thinkpad users.
> 
> acpi_ibm is almost ready to commit (renamed to acpi_thinkpad though).

Ah, that's a good news!  My only concern is that ISTR someone mentioned
me that his colleague was thinking about porting ACPI driver itself,
so if you're not the person you may want to collaborate with him/her
so as not to waste the effort or time...

			:

> > In FreeBSD it used to be sitting at i386/acpica/acpi_toshiba.c and was
> > later moved into acpi_support.  That change hasn't hit our tree (in
> > fact, we have no acpi support drivers other than that).  It seems that
> > FreeBSD has them in dev/acpi_support now, and we for some reason have
> > that directory in our CVS repository (but containing no files in it).
> 
> I don't see it ;). Makes sense though. So, any objections if I move 
> acpi_toshiba into sys/dev/acpi_support and add new acpi_thinkpad there as 
> well? 

Sorry, I checked the CVS repository and it doesn't exist actually :)
I don't have any objection to moving it there.

Cheers.




From hasso at estpak.ee  Thu Mar 20 00:14:05 2008
From: hasso at estpak.ee (Hasso Tepper)
Date: Thu, 20 Mar 2008 00:14:05 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Some questions regarding ACPI
In-Reply-To: <200803191322.46366.hasso@estpak.ee>
Message-ID: <200803200904.50875.hasso@estpak.ee>

YONETANI Tomokazu wrote:
> On Wed, Mar 19, 2008 at 09:15:35PM +0200, Hasso Tepper wrote:
> > acpi_ibm is almost ready to commit (renamed to acpi_thinkpad though).
>
> Ah, that's a good news!  My only concern is that ISTR someone mentioned
> me that his colleague was thinking about porting ACPI driver itself,
> so if you're not the person you may want to collaborate with him/her
> so as not to waste the effort or time...

Current state in my repo is attached. It should work on 1.12 as well as it 
doesn't depend yet on moving stuff around.

add-acpi-if-m.patch adds some new stuff to the ACPI code to access 
embedded controllers and match ACPI devices by ID. Not sure how, where 
and whether at all these should be documented.

add-acpi-thinkpad.patch is the driver itself. Note that some stuff doesn't 
work yet on newer thinkpads, I plan to work on it later.

There is still some things to do though. I have to decide what to do with 
led(4) part and with locking. There is also one fatal issue - laptop 
locks up hardly (no panic) while unloading module. Any idea regarding 
this is welcome. And of course test results :).


-- 
Hasso
# HG changeset patch
# User Hasso Tepper <hasso at estpak.ee>
# Date 1205919290 -7200
# Branch HEAD
# Node ID 5a6e2705cc95a340abf973ae5df73ef34e070b79
# Parent  cd529e2e7f849034d5d5a0973cb98af50db0e797
imported patch adding-acpi-if-m.patch

diff --git a/sys/conf/files b/sys/conf/files
--- a/sys/conf/files
+++ b/sys/conf/files
@@ -1387,6 +1387,7 @@ emulation/dragonfly12/dfbsd12_stat.c	non
 ${OSACPI_MI_DIR}/acpi_cmbat.c		optional acpi
 ${OSACPI_MI_DIR}/acpi_cpu.c		optional acpi
 ${OSACPI_MI_DIR}/acpi_ec.c		optional acpi
+${OSACPI_MI_DIR}/acpi_if.m		optional acpi
 ${OSACPI_MI_DIR}/acpi_isab.c		optional acpi isa
 ${OSACPI_MI_DIR}/acpi_lid.c		optional acpi
 ${OSACPI_MI_DIR}/acpi_package.c		optional acpi
diff --git a/sys/conf/kmod.mk b/sys/conf/kmod.mk
--- a/sys/conf/kmod.mk
+++ b/sys/conf/kmod.mk
@@ -275,7 +275,7 @@ MFILES?= kern/bus_if.m kern/device_if.m 
     bus/pccard/card_if.m bus/pccard/power_if.m bus/pci/pci_if.m \
     bus/pci/pcib_if.m \
     bus/ppbus/ppbus_if.m bus/smbus/smbus_if.m bus/usb/usb_if.m \
-    dev/disk/nata/ata_if.m \
+    dev/acpica5/acpi_if.m dev/disk/nata/ata_if.m \
     dev/sound/pcm/ac97_if.m dev/sound/pcm/channel_if.m \
     dev/sound/pcm/feeder_if.m dev/sound/pcm/mixer_if.m \
     libiconv/iconv_converter_if.m dev/agp/agp_if.m opencrypto/crypto_if.m
diff --git a/sys/dev/acpica5/Makefile b/sys/dev/acpica5/Makefile
--- a/sys/dev/acpica5/Makefile
+++ b/sys/dev/acpica5/Makefile
@@ -69,12 +69,14 @@ SRCS+=  acpi_package.c
 # SRCS+=	acpi_pci.c acpi_pcib.c acpi_pcib_acpi.c acpi_pcib_pci.c
 # SRCS+=	acpi_pci_link.c
 SRCS+=  acpi_powerres.c acpi_resource.c acpi_thermal.c
-SRCS+=  acpi_timer.c
+SRCS+=  acpi_timer.c acpi_if.c
 SRCS+=  OsdDebug.c
 SRCS+=  OsdHardware.c OsdInterface.c OsdInterrupt.c OsdMemory.c OsdSchedule.c
 SRCS+=  OsdStream.c OsdSynch.c OsdTable.c OsdEnvironment.c
 SRCS+=  opt_acpi.h opt_bus.h opt_ddb.h
-SRCS+=  device_if.h bus_if.h pci_if.h pcib_if.h isa_if.h
+SRCS+=  device_if.h bus_if.h pci_if.h pcib_if.h isa_if.h acpi_if.h
+MFILES = kern/device_if.m kern/bus_if.m bus/pci/pci_if.m bus/pci/pcib_if.m
+MFILES+= bus/isa/isa_if.m dev/acpica5/acpi_if.m
 
 # Debugging support
 DBSRC=	dbcmds.c dbdisply.c dbexec.c dbfileio.c dbhistry.c
diff --git a/sys/dev/acpica5/acpi.c b/sys/dev/acpica5/acpi.c
--- a/sys/dev/acpica5/acpi.c
+++ b/sys/dev/acpica5/acpi.c
@@ -135,6 +135,7 @@ static int	acpi_release_resource(device_
 			int rid, struct resource *r);
 static uint32_t	acpi_isa_get_logicalid(device_t dev);
 static int	acpi_isa_get_compatid(device_t dev, uint32_t *cids, int count);
+static char	*acpi_device_id_probe(device_t bus, device_t dev, char **ids);
 static int	acpi_isa_pnp_probe(device_t bus, device_t child,
 			struct isa_pnp_id *ids);
 static void	acpi_probe_children(device_t bus);
@@ -189,6 +190,9 @@ static device_method_t acpi_methods[] = 
     DEVMETHOD(bus_deactivate_resource,	bus_generic_deactivate_resource),
     DEVMETHOD(bus_setup_intr,		bus_generic_setup_intr),
     DEVMETHOD(bus_teardown_intr,	bus_generic_teardown_intr),
+
+    /* ACPI bus */
+    DEVMETHOD(acpi_id_probe,		acpi_device_id_probe),
 
     /* ISA emulation */
     DEVMETHOD(isa_pnp_probe,		acpi_isa_pnp_probe),
@@ -1121,6 +1125,24 @@ out:
 	AcpiOsFree(buf.Pointer);
     ACPI_UNLOCK;
     return_VALUE (valid);
+}
+
+static char *
+acpi_device_id_probe(device_t bus, device_t dev, char **ids) 
+{
+    ACPI_HANDLE h;
+    int i;
+
+    h = acpi_get_handle(dev);
+    if (ids == NULL || h == NULL || acpi_get_type(dev) != ACPI_TYPE_DEVICE)
+	return (NULL);
+
+    /* Try to match one of the array of IDs with a HID or CID. */
+    for (i = 0; ids[i] != NULL; i++) {
+	if (acpi_MatchHid(h, ids[i]))
+	    return (ids[i]);
+    }
+    return (NULL);
 }
 
 static int
diff --git a/sys/dev/acpica5/acpi_ec.c b/sys/dev/acpica5/acpi_ec.c
--- a/sys/dev/acpica5/acpi_ec.c
+++ b/sys/dev/acpica5/acpi_ec.c
@@ -327,11 +327,19 @@ static ACPI_STATUS	EcWrite(struct acpi_e
 				UINT8 *Data);
 static int		acpi_ec_probe(device_t dev);
 static int		acpi_ec_attach(device_t dev);
+static int		acpi_ec_read_method(device_t dev, u_int addr,
+				ACPI_INTEGER *val, int width);
+static int		acpi_ec_write_method(device_t dev, u_int addr,
+				ACPI_INTEGER val, int width);
 
 static device_method_t acpi_ec_methods[] = {
     /* Device interface */
     DEVMETHOD(device_probe,	acpi_ec_probe),
     DEVMETHOD(device_attach,	acpi_ec_attach),
+
+    /* Embedded controller interface */
+    DEVMETHOD(acpi_ec_read,     acpi_ec_read_method),
+    DEVMETHOD(acpi_ec_write,    acpi_ec_write_method),
 
     {0, 0}
 };
@@ -620,6 +628,33 @@ error:
 			     sc->ec_data_res);
     /* mtx_destroy(&sc->ec_mtx); */
     return (ENXIO);
+}
+
+/* Methods to allow other devices (e.g., smbat) to read/write EC space. */
+static int
+acpi_ec_read_method(device_t dev, u_int addr, ACPI_INTEGER *val, int width)
+{
+    struct acpi_ec_softc *sc;
+    ACPI_STATUS status;
+
+    sc = device_get_softc(dev);
+    status = EcSpaceHandler(ACPI_READ, addr, width * 8, val, sc, NULL);
+    if (ACPI_FAILURE(status))
+        return (ENXIO);
+    return (0);
+}
+
+static int
+acpi_ec_write_method(device_t dev, u_int addr, ACPI_INTEGER val, int width)
+{
+    struct acpi_ec_softc *sc;
+    ACPI_STATUS status;
+
+    sc = device_get_softc(dev);
+    status = EcSpaceHandler(ACPI_WRITE, addr, width * 8, &val, sc, NULL);
+    if (ACPI_FAILURE(status))
+        return (ENXIO);
+    return (0);
 }
 
 static void
diff --git a/sys/dev/acpica5/acpi_if.m b/sys/dev/acpica5/acpi_if.m
new file mode 100644
--- /dev/null
+++ b/sys/dev/acpica5/acpi_if.m
@@ -0,0 +1,92 @@
+#-
+# Copyright (c) 2004 Nate Lawson
+# All rights reserved.
+#
+# Redistribution and use in source and binary forms, with or without
+# modification, are permitted provided that the following conditions
+# are met:
+# 1. Redistributions of source code must retain the above copyright
+#    notice, this list of conditions and the following disclaimer.
+# 2. Redistributions in binary form must reproduce the above copyright
+#    notice, this list of conditions and the following disclaimer in the
+#    documentation and/or other materials provided with the distribution.
+#
+# THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
+# ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+# ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
+# FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+# DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+# OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+# HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+# LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+# OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+# SUCH DAMAGE.
+#
+# $DragonFly$
+#
+
+#include <sys/bus.h>
+#include <sys/types.h>
+#include "acpi.h"
+
+INTERFACE acpi;
+
+#
+# Default implementation for acpi_id_probe().
+#
+CODE {
+	static char *
+	acpi_generic_id_probe(device_t bus, device_t dev, char **ids)
+	{
+		return (NULL);
+	}
+};
+
+#
+# Check a device for a match in a list of ID strings.  The strings can be
+# EISA PNP IDs or ACPI _HID/_CID values.
+#
+# device_t bus:  parent bus for the device
+#
+# device_t dev:  device being considered
+#
+# char **ids:  array of ID strings to consider
+#
+# Returns:  ID string matched or NULL if no match
+#
+METHOD char * id_probe {
+	device_t	bus;
+	device_t	dev;
+	char		**ids;
+} DEFAULT acpi_generic_id_probe;
+
+#
+# Read embedded controller (EC) address space
+#
+# device_t dev:  EC device
+# u_int addr:  Address to read from in EC space
+# ACPI_INTEGER *val:  Location to store read value
+# int width:  Size of area to read in bytes
+#
+METHOD int ec_read {
+	device_t	dev;
+	u_int		addr;
+	ACPI_INTEGER	*val;
+	int		width;
+};
+
+#
+# Write embedded controller (EC) address space
+#
+# device_t dev:  EC device
+# u_int addr:  Address to write to in EC space
+# ACPI_INTEGER val:  Value to write
+# int width:  Size of value to write in bytes
+#
+METHOD int ec_write {
+	device_t	dev;
+	u_int		addr;
+	ACPI_INTEGER	val;
+	int		width;
+};
diff --git a/sys/dev/acpica5/acpivar.h b/sys/dev/acpica5/acpivar.h
--- a/sys/dev/acpica5/acpivar.h
+++ b/sys/dev/acpica5/acpivar.h
@@ -29,6 +29,7 @@
  * $DragonFly: src/sys/dev/acpica5/acpivar.h,v 1.12 2007/10/23 03:04:48 y0netan1 Exp $
  */
 
+#include "acpi_if.h"
 #include "bus_if.h"
 #include <sys/eventhandler.h>
 #include <sys/sysctl.h>
# HG changeset patch
# User Hasso Tepper <hasso at estpak.ee>
# Date 1205995474 -7200
# Branch HEAD
# Node ID c5db8d4a7c6b25a8576a8d42c5029aaf0e23bfb6
# Parent  5a6e2705cc95a340abf973ae5df73ef34e070b79
[mq]: adding-acpi-thinkpad.patch

diff --git a/sys/dev/acpica5/Makefile b/sys/dev/acpica5/Makefile
--- a/sys/dev/acpica5/Makefile
+++ b/sys/dev/acpica5/Makefile
@@ -117,7 +117,7 @@ acpi_wakecode.h: acpi_wakecode.S
 	${MAKE} -f ${SYSDIR}/${OSACPI_MD_DIR}/Makefile \
 		MAKESRCPATH=${SYSDIR}/${OSACPI_MD_DIR}
 
-SUBDIR=	acpi_toshiba
+SUBDIR=	acpi_toshiba acpi_thinkpad
 all: ${PROG} ${SUBDIR}
 
 # *.o file for each patched *.c file is created under the same directory,
diff --git a/sys/dev/acpica5/acpi_thinkpad/Makefile b/sys/dev/acpica5/acpi_thinkpad/Makefile
new file mode 100644
--- /dev/null
+++ b/sys/dev/acpica5/acpi_thinkpad/Makefile
@@ -0,0 +1,9 @@
+# $DragonFly$
+
+SYSDIR?=${.CURDIR}/../../..
+
+KMOD=		acpi_thinkpad
+CFLAGS+=	-I${.OBJDIR}/.. -I${.CURDIR}/..
+SRCS=		acpi_thinkpad.c opt_acpi.h device_if.h bus_if.h
+
+.include <bsd.kmod.mk>
diff --git a/sys/dev/acpica5/acpi_thinkpad/acpi_thinkpad.c b/sys/dev/acpica5/acpi_thinkpad/acpi_thinkpad.c
new file mode 100644
--- /dev/null
+++ b/sys/dev/acpica5/acpi_thinkpad/acpi_thinkpad.c
@@ -0,0 +1,1046 @@
+/*
+ * Copyright (c) 2004 Takanori Watanabe
+ * Copyright (c) 2005 Markus Brueffer <markus at FreeBSD.org>
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *    notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *    notice, this list of conditions and the following disclaimer in the
+ *    documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+ */
+
+/*
+ * Driver for extra ACPI-controlled gadgets found on IBM and Lenovo ThinkPad
+ * laptops. Inspired by the ibm-acpi and tpb projects which implement these
+ * features on Linux.
+ *
+ *   acpi-ibm: <http://ibm-acpi.sourceforge.net/>
+ *        tpb: <http://www.nongnu.org/tpb/>
+ */
+
+#include "opt_acpi.h"
+#include <sys/param.h>
+#include <sys/kernel.h>
+#include <sys/bus.h>
+#include <machine/cpufunc.h>
+#include <sys/module.h>
+/* #include <dev/led/led.h> */
+#include <sys/sensors.h>
+#include <sys/sysctl.h>
+#include <machine/clock.h>
+
+#include "acpi.h"
+#include "acpivar.h"
+#include "acpi_if.h"
+
+#define _COMPONENT	ACPI_OEM
+ACPI_MODULE_NAME("THINKPAD")
+
+/* Internal methods */
+#define ACPI_THINKPAD_METHOD_EVENTS		1
+#define ACPI_THINKPAD_METHOD_EVENTMASK		2
+#define ACPI_THINKPAD_METHOD_HOTKEY		3
+#define ACPI_THINKPAD_METHOD_BRIGHTNESS		4
+#define ACPI_THINKPAD_METHOD_VOLUME		5
+#define ACPI_THINKPAD_METHOD_MUTE		6
+#define ACPI_THINKPAD_METHOD_THINKLIGHT		7
+#define ACPI_THINKPAD_METHOD_BLUETOOTH		8
+#define ACPI_THINKPAD_METHOD_WLAN		9
+#define ACPI_THINKPAD_METHOD_FANSPEED		10
+#define ACPI_THINKPAD_METHOD_FANLEVEL		11
+#define ACPI_THINKPAD_METHOD_FANSTATUS		12
+#define ACPI_THINKPAD_METHOD_THERMAL		13
+
+/* Hotkeys/Buttons */
+#define THINKPAD_RTC_HOTKEY1			0x64
+#define   THINKPAD_RTC_MASK_HOME		(1 << 0)
+#define   THINKPAD_RTC_MASK_SEARCH		(1 << 1)
+#define   THINKPAD_RTC_MASK_MAIL		(1 << 2)
+#define   THINKPAD_RTC_MASK_WLAN		(1 << 5)
+#define THINKPAD_RTC_HOTKEY2			0x65
+#define   THINKPAD_RTC_MASK_THINKPAD		(1 << 3)
+#define   THINKPAD_RTC_MASK_ZOOM		(1 << 5)
+#define   THINKPAD_RTC_MASK_VIDEO		(1 << 6)
+#define   THINKPAD_RTC_MASK_HIBERNATE		(1 << 7)
+#define THINKPAD_RTC_THINKLIGHT			0x66
+#define   THINKPAD_RTC_MASK_THINKLIGHT		(1 << 4)
+#define THINKPAD_RTC_SCREENEXPAND		0x67
+#define   THINKPAD_RTC_MASK_SCREENEXPAND	(1 << 5)
+#define THINKPAD_RTC_BRIGHTNESS			0x6c
+#define   THINKPAD_RTC_MASK_BRIGHTNESS		(1 << 5)
+#define THINKPAD_RTC_VOLUME			0x6e
+#define   THINKPAD_RTC_MASK_VOLUME		(1 << 7)
+
+/* Embedded Controller registers */
+#define THINKPAD_EC_BRIGHTNESS			0x31
+#define   THINKPAD_EC_MASK_BRI			0x7
+#define THINKPAD_EC_VOLUME			0x30
+#define   THINKPAD_EC_MASK_VOL			0xf
+#define   THINKPAD_EC_MASK_MUTE			(1 << 6)
+#define THINKPAD_EC_FANSTATUS			0x2F
+#define   THINKPAD_EC_MASK_FANLEVEL		0x3f
+#define   THINKPAD_EC_MASK_FANDISENGAGED	(1 << 6)
+#define   THINKPAD_EC_MASK_FANSTATUS		(1 << 7)
+#define THINKPAD_EC_FANSPEED			0x84
+
+/* CMOS Commands */
+#define THINKPAD_CMOS_VOLUME_DOWN		0
+#define THINKPAD_CMOS_VOLUME_UP			1
+#define THINKPAD_CMOS_VOLUME_MUTE		2
+#define THINKPAD_CMOS_BRIGHTNESS_UP		4
+#define THINKPAD_CMOS_BRIGHTNESS_DOWN		5
+
+/* ACPI methods */
+#define THINKPAD_NAME_KEYLIGHT			"KBLT"
+#define THINKPAD_NAME_WLAN_BT_GET		"GBDC"
+#define THINKPAD_NAME_WLAN_BT_SET		"SBDC"
+#define   THINKPAD_NAME_MASK_BT			(1 << 1)
+#define   THINKPAD_NAME_MASK_WLAN		(1 << 2)
+#define THINKPAD_NAME_THERMAL_GET		"TMP7"
+#define THINKPAD_NAME_THERMAL_UPDT		"UPDT"
+
+#define THINKPAD_NAME_EVENTS_STATUS_GET		"DHKC"
+#define THINKPAD_NAME_EVENTS_MASK_GET		"DHKN"
+#define THINKPAD_NAME_EVENTS_STATUS_SET		"MHKC"
+#define THINKPAD_NAME_EVENTS_MASK_SET		"MHKM"
+#define THINKPAD_NAME_EVENTS_GET		"MHKP"
+#define THINKPAD_NAME_EVENTS_AVAILMASK		"MHKA"
+
+#define ABS(x) (((x) < 0)? -(x) : (x))
+
+struct acpi_thinkpad_softc {
+	device_t	dev;
+	ACPI_HANDLE	handle;
+
+	/* Embedded controller */
+	device_t	ec_dev;
+	ACPI_HANDLE	ec_handle;
+
+	/* CMOS */
+	ACPI_HANDLE	cmos_handle;
+
+	/* Fan status */
+	ACPI_HANDLE	fan_handle;
+	int		fan_levels;
+
+	/* Keylight commands and states */
+	ACPI_HANDLE	light_handle;
+	int		light_cmd_on;
+	int		light_cmd_off;
+	int		light_val;
+	int		light_get_supported;
+	int		light_set_supported;
+
+	/* led(4) interface */
+	struct cdev	*led_dev;
+	int		led_busy;
+	int		led_state;
+
+	int		wlan_bt_flags;
+	int		thermal_updt_supported;
+
+	unsigned int	events_availmask;
+	unsigned int	events_initialmask;
+	int		events_mask_supported;
+	int		events_enable;
+
+	/* sensors(9) related */
+	struct ksensordev sensordev;
+	struct ksensor sensors[9];	/* XXX: 8 thermal + fan */
+
+	struct sysctl_ctx_list	*sysctl_ctx;
+	struct sysctl_oid	*sysctl_tree;
+};
+
+static struct {
+	char	*name;
+	int	method;
+	char	*description;
+	int	access;
+} acpi_thinkpad_sysctls[] = {
+	{
+		.name		= "events",
+		.method		= ACPI_THINKPAD_METHOD_EVENTS,
+		.description	= "ACPI events enable",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "eventmask",
+		.method		= ACPI_THINKPAD_METHOD_EVENTMASK,
+		.description	= "ACPI eventmask",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "hotkey",
+		.method		= ACPI_THINKPAD_METHOD_HOTKEY,
+		.description	= "Key Status",
+		.access		= CTLTYPE_INT | CTLFLAG_RD
+	},
+	{
+		.name		= "lcd_brightness",
+		.method		= ACPI_THINKPAD_METHOD_BRIGHTNESS,
+		.description	= "LCD Brightness",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "volume",
+		.method		= ACPI_THINKPAD_METHOD_VOLUME,
+		.description	= "Volume",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "mute",
+		.method		= ACPI_THINKPAD_METHOD_MUTE,
+		.description	= "Mute",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "thinklight",
+		.method		= ACPI_THINKPAD_METHOD_THINKLIGHT,
+		.description	= "Thinklight enable",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "bluetooth",
+		.method		= ACPI_THINKPAD_METHOD_BLUETOOTH,
+		.description	= "Bluetooth enable",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "wlan",
+		.method		= ACPI_THINKPAD_METHOD_WLAN,
+		.description	= "WLAN enable",
+		.access		= CTLTYPE_INT | CTLFLAG_RD
+	},
+	{
+		.name		= "fan_level",
+		.method		= ACPI_THINKPAD_METHOD_FANLEVEL,
+		.description	= "Fan level",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "fan",
+		.method		= ACPI_THINKPAD_METHOD_FANSTATUS,
+		.description	= "Fan enable",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+
+	{ NULL, 0, NULL, 0 }
+};
+
+/* ACPI_SERIAL_DECL(thinkpad, "ACPI THINKPAD extras"); */
+static int	acpi_thinkpad_probe(device_t dev);
+static int	acpi_thinkpad_attach(device_t dev);
+static int	acpi_thinkpad_detach(device_t dev);
+
+#if 0 /* not yet */
+static void	thinkpad_led(void *softc, int onoff);
+static void	thinkpad_led_task(struct acpi_thinkpad_softc *sc,
+		int pending __unused);
+#endif
+
+static int	acpi_thinkpad_sysctl(SYSCTL_HANDLER_ARGS);
+static int	acpi_thinkpad_sysctl_init(struct acpi_thinkpad_softc *sc,
+		int method);
+static int	acpi_thinkpad_sysctl_get(struct acpi_thinkpad_softc *sc,
+		int method);
+static int	acpi_thinkpad_sysctl_set(struct acpi_thinkpad_softc *sc,
+		int method, int val);
+
+static int	acpi_thinkpad_eventmask_set(struct acpi_thinkpad_softc *sc,
+		int val);
+static void	acpi_thinkpad_notify(ACPI_HANDLE h, UINT32 notify,
+		void *context);
+static void	acpi_thinkpad_refresh(void *);
+
+static device_method_t acpi_thinkpad_methods[] = {
+	/* Device interface */
+	DEVMETHOD(device_probe, acpi_thinkpad_probe),
+	DEVMETHOD(device_attach, acpi_thinkpad_attach),
+	DEVMETHOD(device_detach, acpi_thinkpad_detach),
+	{0, 0}
+};
+
+static driver_t	acpi_thinkpad_driver = {
+	"acpi_thinkpad",
+	acpi_thinkpad_methods,
+	sizeof(struct acpi_thinkpad_softc),
+};
+
+static devclass_t acpi_thinkpad_devclass;
+
+DRIVER_MODULE(acpi_thinkpad, acpi, acpi_thinkpad_driver,
+    acpi_thinkpad_devclass, 0, 0);
+MODULE_DEPEND(acpi_thinkpad, acpi, 1, 1, 1);
+static char    *thinkpad_ids[] = {"IBM0068", NULL};
+
+#if 0 /* not yet */
+static void
+thinkpad_led(void *softc, int onoff)
+{
+	struct acpi_thinkpad_softc* sc = (struct acpi_thinkpad_softc*) softc;
+
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+
+	if (sc->led_busy)
+		return;
+
+	sc->led_busy = 1;
+	sc->led_state = onoff;
+
+	AcpiOsExecute(OSL_NOTIFY_HANDLER, (void *)thinkpad_led_task, sc);
+}
+
+static void
+thinkpad_led_task(struct acpi_thinkpad_softc *sc, int pending __unused)
+{
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+
+	/* ACPI_SERIAL_BEGIN(thinkpad); */
+	acpi_thinkpad_sysctl_set(sc, ACPI_THINKPAD_METHOD_THINKLIGHT, sc->led_state);
+	/* ACPI_SERIAL_END(thinkpad); */
+
+	sc->led_busy = 0;
+}
+#endif
+
+static int
+acpi_thinkpad_probe(device_t dev)
+{
+	if (acpi_disabled("thinkpad") ||
+	    ACPI_ID_PROBE(device_get_parent(dev), dev, thinkpad_ids) == NULL ||
+	    device_get_unit(dev) != 0) 
+		return (ENXIO);
+
+	device_set_desc(dev, "IBM/Lenovo ThinkPad ACPI Extras");
+	return (0);
+}
+
+static int
+acpi_thinkpad_attach(device_t dev)
+{
+	struct acpi_thinkpad_softc	*sc;
+	struct acpi_softc	*acpi_sc;
+	devclass_t		ec_devclass;
+	int			i;
+
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t) __func__);
+
+	sc = device_get_softc(dev);
+	sc->dev = dev;
+	sc->handle = acpi_get_handle(dev);
+
+	acpi_sc = acpi_device_get_parent_softc(dev);
+
+	/* Look for the first embedded controller */
+        if (!(ec_devclass = devclass_find ("acpi_ec"))) {
+		if (bootverbose)
+			device_printf(dev, "Couldn't find acpi_ec devclass\n");
+		return (EINVAL);
+	}
+        if (!(sc->ec_dev = devclass_get_device(ec_devclass, 0))) {
+		if (bootverbose)
+			device_printf(dev, "Couldn't find acpi_ec device\n");
+		return (EINVAL);
+	}
+	sc->ec_handle = acpi_get_handle(sc->ec_dev);
+
+	/* ACPI_SERIAL_BEGIN(thinkpad); */
+
+#if 0
+	/* Get the sysctl tree */
+	sc->sysctl_ctx = device_get_sysctl_ctx(dev);
+	sc->sysctl_tree = device_get_sysctl_tree(dev);
+#endif
+	sysctl_ctx_init(sc->sysctl_ctx);
+	sc->sysctl_tree = SYSCTL_ADD_NODE(sc->sysctl_ctx,
+	    SYSCTL_CHILDREN(acpi_sc->acpi_sysctl_tree), OID_AUTO,
+	    "thinkpad", CTLFLAG_RD, 0, "");
+
+	/* Look for event mask and hook up the nodes */
+	sc->events_mask_supported = ACPI_SUCCESS(acpi_GetInteger(sc->handle,
+	    THINKPAD_NAME_EVENTS_MASK_GET, &sc->events_initialmask));
+
+	if (sc->events_mask_supported) {
+		SYSCTL_ADD_INT(sc->sysctl_ctx,
+		    SYSCTL_CHILDREN(sc->sysctl_tree), OID_AUTO,
+		    "initialmask", CTLFLAG_RD,
+		    &sc->events_initialmask, 0, "Initial eventmask");
+
+		/* The availmask is the bitmask of supported events */
+		if (ACPI_FAILURE(acpi_GetInteger(sc->handle,
+		    THINKPAD_NAME_EVENTS_AVAILMASK, &sc->events_availmask)))
+			sc->events_availmask = 0xffffffff;
+
+		SYSCTL_ADD_INT(sc->sysctl_ctx,
+		    SYSCTL_CHILDREN(sc->sysctl_tree), OID_AUTO,
+		    "availmask", CTLFLAG_RD,
+		    &sc->events_availmask, 0, "Mask of supported events");
+	}
+
+	/* Hook up proc nodes */
+	for (i = 0; acpi_thinkpad_sysctls[i].name != NULL; i++) {
+		if (!acpi_thinkpad_sysctl_init(sc,
+		    acpi_thinkpad_sysctls[i].method))
+			continue;
+
+		SYSCTL_ADD_PROC(sc->sysctl_ctx,
+		    SYSCTL_CHILDREN(sc->sysctl_tree), OID_AUTO,
+		    acpi_thinkpad_sysctls[i].name,
+		    acpi_thinkpad_sysctls[i].access,
+		    sc, i, acpi_thinkpad_sysctl, "I",
+		    acpi_thinkpad_sysctls[i].description);
+	}
+
+	/* ACPI_SERIAL_END(thinkpad); */
+
+	/* Handle notifies */
+	AcpiInstallNotifyHandler(sc->handle, ACPI_DEVICE_NOTIFY,
+	    acpi_thinkpad_notify, dev);
+
+#if 0
+	/* Hook up light to led(4) */
+	if (sc->light_set_supported)
+		sc->led_dev = led_create_state(thinkpad_led, sc, "thinklight",
+		    sc->light_val);
+#endif
+	/* Attach sensors(9). */
+	if (sensor_task_register(sc, acpi_thinkpad_refresh, 5)) {
+		device_printf(sc->dev, "unable to register update task\n");
+		return 1;
+	}
+
+	strlcpy(sc->sensordev.xname, device_get_nameunit(sc->dev),
+	    sizeof(sc->sensordev.xname));
+
+	/* XXX: Temp sensors */
+	for (i = 0; i < 8; ++i) {
+		sc->sensors[i].type = SENSOR_TEMP;
+		sensor_attach(&sc->sensordev, &sc->sensors[i]);
+	}
+	
+	/* Fan RPM sensor */
+	sc->sensors[8].type = SENSOR_FANRPM;
+	sensor_attach(&sc->sensordev, &sc->sensors[8]);
+
+	sensordev_install(&sc->sensordev);
+
+	return (0);
+}
+
+static int
+acpi_thinkpad_detach(device_t dev)
+{
+	int i;
+
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t) __func__);
+
+	struct acpi_thinkpad_softc *sc = device_get_softc(dev);
+
+	/* Disable events and restore eventmask */
+	/* ACPI_SERIAL_BEGIN(thinkpad); */
+	acpi_thinkpad_sysctl_set(sc, ACPI_THINKPAD_METHOD_EVENTS, 0);
+	acpi_thinkpad_sysctl_set(sc, ACPI_THINKPAD_METHOD_EVENTMASK,
+	    sc->events_initialmask);
+	/* ACPI_SERIAL_END(thinkpad); */
+
+	AcpiRemoveNotifyHandler(sc->handle, ACPI_DEVICE_NOTIFY,
+	    acpi_thinkpad_notify);
+
+	sysctl_ctx_free(sc->sysctl_ctx);
+
+#if 0
+	if (sc->led_dev != NULL)
+		led_destroy(sc->led_dev);
+#endif
+	sensordev_deinstall(&sc->sensordev);
+	for (i = 0; i < 9; i++)
+		sensor_detach(&sc->sensordev, &sc->sensors[i]);
+	sensor_task_unregister(sc);
+
+	return (0);
+}
+
+static int
+acpi_thinkpad_eventmask_set(struct acpi_thinkpad_softc *sc, int val)
+{
+	int i;
+	ACPI_OBJECT		arg[2];
+	ACPI_OBJECT_LIST	args;
+	ACPI_STATUS		status;
+
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+	/* ACPI_SERIAL_ASSERT(thinkpad); */
+
+	args.Count = 2;
+	args.Pointer = arg;
+	arg[0].Type = ACPI_TYPE_INTEGER;
+	arg[1].Type = ACPI_TYPE_INTEGER;
+
+	for (i = 0; i < 32; ++i) {
+		arg[0].Integer.Value = i+1;
+		arg[1].Integer.Value = (((1 << i) & val) != 0);
+		status = AcpiEvaluateObject(sc->handle,
+		    THINKPAD_NAME_EVENTS_MASK_SET, &args, NULL);
+
+		if (ACPI_FAILURE(status))
+			return (status);
+	}
+
+	return (0);
+}
+
+static int
+acpi_thinkpad_sysctl(SYSCTL_HANDLER_ARGS)
+{
+	struct acpi_thinkpad_softc	*sc;
+	int			arg;
+	int			error = 0;
+	int			function;
+	int			method;
+	
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+
+	sc = (struct acpi_thinkpad_softc *)oidp->oid_arg1;
+	function = oidp->oid_arg2;
+	method = acpi_thinkpad_sysctls[function].method;
+
+	/* ACPI_SERIAL_BEGIN(thinkpad); */
+	arg = acpi_thinkpad_sysctl_get(sc, method);
+	error = sysctl_handle_int(oidp, &arg, 0, req);
+
+	/* Sanity check */
+	if (error != 0 || req->newptr == NULL)
+		goto out;
+
+	/* Update */
+	error = acpi_thinkpad_sysctl_set(sc, method, arg);
+
+out:
+	/* ACPI_SERIAL_END(thinkpad); */
+	return (error);
+}
+
+static int
+acpi_thinkpad_sysctl_get(struct acpi_thinkpad_softc *sc, int method)
+{
+	ACPI_INTEGER	val_ec;
+	int 		val = 0, key;
+
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+	/* ACPI_SERIAL_ASSERT(thinkpad); */
+
+	switch (method) {
+	case ACPI_THINKPAD_METHOD_EVENTS:
+		acpi_GetInteger(sc->handle, THINKPAD_NAME_EVENTS_STATUS_GET,
+		    &val);
+		break;
+
+	case ACPI_THINKPAD_METHOD_EVENTMASK:
+		if (sc->events_mask_supported)
+			acpi_GetInteger(sc->handle,
+			    THINKPAD_NAME_EVENTS_MASK_GET, &val);
+		break;
+
+	case ACPI_THINKPAD_METHOD_HOTKEY:
+		/*
+		 * Construct the hotkey as a bitmask as illustrated below.
+		 * Note that whenever a key was pressed, the respecting bit
+		 * toggles and nothing else changes.
+		 * +--+--+-+-+-+-+-+-+-+-+-+-+
+		 * |11|10|9|8|7|6|5|4|3|2|1|0|
+		 * +--+--+-+-+-+-+-+-+-+-+-+-+
+		 *   |  | | | | | | | | | | |
+		 *   |  | | | | | | | | | | +- Home Button
+		 *   |  | | | | | | | | | +--- Search Button
+		 *   |  | | | | | | | | +----- Mail Button
+		 *   |  | | | | | | | +------- Thinkpad Button
+		 *   |  | | | | | | +--------- Zoom (Fn + Space)
+		 *   |  | | | | | +----------- WLAN Button
+		 *   |  | | | | +------------- Video Button
+		 *   |  | | | +--------------- Hibernate Button
+		 *   |  | | +----------------- Thinklight Button
+		 *   |  | +------------------- Screen expand (Fn + F8)
+		 *   |  +--------------------- Brightness
+		 *   +------------------------ Volume/Mute
+		 */
+		key = rtcin(THINKPAD_RTC_HOTKEY1);
+		val = (THINKPAD_RTC_MASK_HOME | THINKPAD_RTC_MASK_SEARCH |
+		    THINKPAD_RTC_MASK_MAIL | THINKPAD_RTC_MASK_WLAN) & key;
+		key = rtcin(THINKPAD_RTC_HOTKEY2);
+		val |= (THINKPAD_RTC_MASK_THINKPAD | THINKPAD_RTC_MASK_VIDEO |
+		    THINKPAD_RTC_MASK_HIBERNATE) & key;
+		val |= (THINKPAD_RTC_MASK_ZOOM & key) >> 1;
+		key = rtcin(THINKPAD_RTC_THINKLIGHT);
+		val |= (THINKPAD_RTC_MASK_THINKLIGHT & key) << 4;
+		key = rtcin(THINKPAD_RTC_SCREENEXPAND);
+		val |= (THINKPAD_RTC_MASK_THINKLIGHT & key) << 4;
+		key = rtcin(THINKPAD_RTC_BRIGHTNESS);
+		val |= (THINKPAD_RTC_MASK_BRIGHTNESS & key) << 5;
+		key = rtcin(THINKPAD_RTC_VOLUME);
+		val |= (THINKPAD_RTC_MASK_VOLUME & key) << 4;
+		break;
+
+	case ACPI_THINKPAD_METHOD_BRIGHTNESS:
+		ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_BRIGHTNESS, &val_ec, 1);
+		val = val_ec & THINKPAD_EC_MASK_BRI;
+		break;
+
+	case ACPI_THINKPAD_METHOD_VOLUME:
+		ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_VOLUME, &val_ec, 1);
+		val = val_ec & THINKPAD_EC_MASK_VOL;
+		break;
+
+	case ACPI_THINKPAD_METHOD_MUTE:
+		val = ((val_ec & THINKPAD_EC_MASK_MUTE) ==
+		    THINKPAD_EC_MASK_MUTE);
+		break;
+
+	case ACPI_THINKPAD_METHOD_THINKLIGHT:
+		if (sc->light_get_supported)
+			acpi_GetInteger(sc->ec_handle, THINKPAD_NAME_KEYLIGHT,
+			    &val);
+		else
+			val = sc->light_val;
+		break;
+
+	case ACPI_THINKPAD_METHOD_BLUETOOTH:
+		acpi_GetInteger(sc->handle, THINKPAD_NAME_WLAN_BT_GET, &val);
+		sc->wlan_bt_flags = val;
+		val = ((val & THINKPAD_NAME_MASK_BT) != 0);
+		break;
+
+	case ACPI_THINKPAD_METHOD_WLAN:
+		acpi_GetInteger(sc->handle, THINKPAD_NAME_WLAN_BT_GET, &val);
+		sc->wlan_bt_flags = val;
+		val = ((val & THINKPAD_NAME_MASK_WLAN) != 0);
+		break;
+
+	case ACPI_THINKPAD_METHOD_FANSPEED:
+		if (sc->fan_handle) {
+			if (ACPI_FAILURE(acpi_GetInteger(sc->fan_handle,
+			    NULL, &val)))
+				val = -1;
+		}
+		else {
+			ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_FANSPEED,
+			    &val_ec, 2);
+			val = val_ec;
+		}
+		break;
+
+	case ACPI_THINKPAD_METHOD_FANLEVEL:
+		/*
+		 * The THINKPAD_EC_FANSTATUS register works as follows:
+		 * Bit 0-5 indicate the level at which the fan operates. Only
+		 *       values between 0 and 7 have an effect. Everything
+		 *       above 7 is treated the same as level 7
+		 * Bit 6 overrides the fan speed limit if set to 1
+		 * Bit 7 indicates at which mode the fan operates:
+		 *       manual (0) or automatic (1)
+		 */
+		if (!sc->fan_handle) {
+			ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_FANSTATUS,
+			    &val_ec, 1);
+			val = val_ec & THINKPAD_EC_MASK_FANLEVEL;
+		}
+		break;
+
+	case ACPI_THINKPAD_METHOD_FANSTATUS:
+		if (!sc->fan_handle) {
+			ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_FANSTATUS,
+			    &val_ec, 1);
+			val = (val_ec & THINKPAD_EC_MASK_FANSTATUS) ==
+			    THINKPAD_EC_MASK_FANSTATUS;
+		}
+		else
+			val = -1;
+		break;
+	}
+
+	return (val);
+}
+
+static int
+acpi_thinkpad_sysctl_set(struct acpi_thinkpad_softc *sc, int method, int arg)
+{
+	int			val, step, i;
+	ACPI_INTEGER		val_ec;
+	ACPI_OBJECT		Arg;
+	ACPI_OBJECT_LIST	Args;
+	ACPI_STATUS		status;
+
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+	/* ACPI_SERIAL_ASSERT(thinkpad); */
+
+	switch (method) {
+	case ACPI_THINKPAD_METHOD_EVENTS:
+		if (arg < 0 || arg > 1)
+			return (EINVAL);
+
+		status = acpi_SetInteger(sc->handle,
+		    THINKPAD_NAME_EVENTS_STATUS_SET, arg);
+		if (ACPI_FAILURE(status))
+			return (status);
+		if (sc->events_mask_supported)
+			return acpi_thinkpad_eventmask_set(sc,
+			    sc->events_availmask);
+		break;
+
+	case ACPI_THINKPAD_METHOD_EVENTMASK:
+		if (sc->events_mask_supported)
+			return acpi_thinkpad_eventmask_set(sc, arg);
+		break;
+
+	case ACPI_THINKPAD_METHOD_BRIGHTNESS:
+		if (arg < 0 || arg > 7)
+			return (EINVAL);
+
+		if (sc->cmos_handle) {
+			/* Read the current brightness */
+			status = ACPI_EC_READ(sc->ec_dev,
+			    THINKPAD_EC_BRIGHTNESS, &val_ec, 1);
+			if (ACPI_FAILURE(status))
+				return (status);
+			val = val_ec & THINKPAD_EC_MASK_BRI;
+
+			Args.Count = 1;
+			Args.Pointer = &Arg;
+			Arg.Type = ACPI_TYPE_INTEGER;
+			Arg.Integer.Value = (arg > val) ?
+			    THINKPAD_CMOS_BRIGHTNESS_UP :
+			    THINKPAD_CMOS_BRIGHTNESS_DOWN;
+
+			step = (arg > val) ? 1 : -1;
+			for (i = val; i != arg; i += step) {
+				status = AcpiEvaluateObject(sc->cmos_handle,
+				    NULL, &Args, NULL);
+				if (ACPI_FAILURE(status))
+					break;
+			}
+		}
+		return ACPI_EC_WRITE(sc->ec_dev, THINKPAD_EC_BRIGHTNESS,
+		    arg, 1);
+		break;
+
+	case ACPI_THINKPAD_METHOD_VOLUME:
+		if (arg < 0 || arg > 14)
+			return (EINVAL);
+
+		status = ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_VOLUME,
+		    &val_ec, 1);
+		if (ACPI_FAILURE(status))
+			return (status);
+
+		if (sc->cmos_handle) {
+			val = val_ec & THINKPAD_EC_MASK_VOL;
+
+			Args.Count = 1;
+			Args.Pointer = &Arg;
+			Arg.Type = ACPI_TYPE_INTEGER;
+			Arg.Integer.Value = (arg > val) ?
+			    THINKPAD_CMOS_VOLUME_UP : THINKPAD_CMOS_VOLUME_DOWN;
+
+			step = (arg > val) ? 1 : -1;
+			for (i = val; i != arg; i += step) {
+				status = AcpiEvaluateObject(sc->cmos_handle,
+				    NULL, &Args, NULL);
+				if (ACPI_FAILURE(status))
+					break;
+			}
+		}
+		return ACPI_EC_WRITE(sc->ec_dev, THINKPAD_EC_VOLUME, arg +
+		    (val_ec & (~THINKPAD_EC_MASK_VOL)), 1);
+		break;
+
+	case ACPI_THINKPAD_METHOD_MUTE:
+		if (arg < 0 || arg > 1)
+			return (EINVAL);
+
+		status = ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_VOLUME,
+		    &val_ec, 1);
+		if (ACPI_FAILURE(status))
+			return (status);
+
+		if (sc->cmos_handle) {
+			val = val_ec & THINKPAD_EC_MASK_VOL;
+
+			Args.Count = 1;
+			Args.Pointer = &Arg;
+			Arg.Type = ACPI_TYPE_INTEGER;
+			Arg.Integer.Value = THINKPAD_CMOS_VOLUME_MUTE;
+
+			status = AcpiEvaluateObject(sc->cmos_handle, NULL,
+			    &Args, NULL);
+			if (ACPI_FAILURE(status))
+				break;
+		}
+		return ACPI_EC_WRITE(sc->ec_dev, THINKPAD_EC_VOLUME, (arg==1) ?
+		   val_ec | THINKPAD_EC_MASK_MUTE :
+		   val_ec & (~THINKPAD_EC_MASK_MUTE), 1);
+		break;
+
+	case ACPI_THINKPAD_METHOD_THINKLIGHT:
+		if (arg < 0 || arg > 1)
+			return (EINVAL);
+
+		if (sc->light_set_supported) {
+			Args.Count = 1;
+			Args.Pointer = &Arg;
+			Arg.Type = ACPI_TYPE_INTEGER;
+			Arg.Integer.Value = arg ?
+			    sc->light_cmd_on : sc->light_cmd_off;
+
+			status = AcpiEvaluateObject(sc->light_handle, NULL,
+			    &Args, NULL);
+			if (ACPI_SUCCESS(status))
+				sc->light_val = arg;
+			return (status);
+		}
+		break;
+
+	case ACPI_THINKPAD_METHOD_BLUETOOTH:
+		if (arg < 0 || arg > 1)
+			return (EINVAL);
+
+		val = (arg == 1) ? sc->wlan_bt_flags |
+		    THINKPAD_NAME_MASK_BT :
+		    sc->wlan_bt_flags & (~THINKPAD_NAME_MASK_BT);
+		return acpi_SetInteger(sc->handle, THINKPAD_NAME_WLAN_BT_SET,
+		    val);
+		break;
+
+	case ACPI_THINKPAD_METHOD_FANLEVEL:
+		if (arg < 0 || arg > 7)
+			return (EINVAL);
+
+		if (!sc->fan_handle) {
+			/* Read the current fanstatus */
+			ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_FANSTATUS,
+			    &val_ec, 1);
+			val = val_ec & (~THINKPAD_EC_MASK_FANLEVEL);
+
+			return ACPI_EC_WRITE(sc->ec_dev, THINKPAD_EC_FANSTATUS,
+			    val | arg, 1);
+		}
+		break;
+
+	case ACPI_THINKPAD_METHOD_FANSTATUS:
+		if (arg < 0 || arg > 1)
+			return (EINVAL);
+
+		if (!sc->fan_handle) {
+			/* Read the current fanstatus */
+			ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_FANSTATUS,
+			    &val_ec, 1);
+
+			return ACPI_EC_WRITE(sc->ec_dev, THINKPAD_EC_FANSTATUS,
+			    (arg == 1) ? (val_ec | THINKPAD_EC_MASK_FANSTATUS) :
+			    (val_ec & (~THINKPAD_EC_MASK_FANSTATUS)), 1);
+		}
+		break;
+	}
+
+	return (0);
+}
+
+static int
+acpi_thinkpad_sysctl_init(struct acpi_thinkpad_softc *sc, int method)
+{
+	int 			dummy;
+	ACPI_OBJECT_TYPE 	cmos_t;
+	ACPI_HANDLE		ledb_handle;
+
+	switch (method) {
+	case ACPI_THINKPAD_METHOD_EVENTS:
+		/* Events are disabled by default */
+		return (TRUE);
+
+	case ACPI_THINKPAD_METHOD_EVENTMASK:
+		return (sc->events_mask_supported);
+
+	case ACPI_THINKPAD_METHOD_HOTKEY:
+	case ACPI_THINKPAD_METHOD_BRIGHTNESS:
+	case ACPI_THINKPAD_METHOD_VOLUME:
+	case ACPI_THINKPAD_METHOD_MUTE:
+		/* EC is required here, which was already checked before */
+		return (TRUE);
+
+	case ACPI_THINKPAD_METHOD_THINKLIGHT:
+		sc->cmos_handle = NULL;
+		sc->light_get_supported = ACPI_SUCCESS(acpi_GetInteger(
+		    sc->ec_handle, THINKPAD_NAME_KEYLIGHT, &sc->light_val));
+
+		if ((ACPI_SUCCESS(AcpiGetHandle(sc->handle, "\\UCMS",
+		    &sc->light_handle)) ||
+		    ACPI_SUCCESS(AcpiGetHandle(sc->handle, "\\CMOS",
+		    &sc->light_handle)) ||
+		    ACPI_SUCCESS(AcpiGetHandle(sc->handle, "\\CMS",
+		    &sc->light_handle))) &&
+		    ACPI_SUCCESS(AcpiGetType(sc->light_handle, &cmos_t)) &&
+		    cmos_t == ACPI_TYPE_METHOD) {
+			sc->light_cmd_on = 0x0c;
+			sc->light_cmd_off = 0x0d;
+			sc->cmos_handle = sc->light_handle;
+		}
+		else if (ACPI_SUCCESS(AcpiGetHandle(sc->handle, "\\LGHT",
+		    &sc->light_handle))) {
+			sc->light_cmd_on = 1;
+			sc->light_cmd_off = 0;
+		}
+		else
+			sc->light_handle = NULL;
+
+		sc->light_set_supported = (sc->light_handle &&
+		    ACPI_FAILURE(AcpiGetHandle(sc->ec_handle, "LEDB",
+		    &ledb_handle)));
+
+		if (sc->light_get_supported)
+			return (TRUE);
+
+		if (sc->light_set_supported) {
+			sc->light_val = 0;
+			return (TRUE);
+		}
+
+		return (FALSE);
+
+	case ACPI_THINKPAD_METHOD_BLUETOOTH:
+	case ACPI_THINKPAD_METHOD_WLAN:
+		if (ACPI_SUCCESS(acpi_GetInteger(sc->handle,
+		    THINKPAD_NAME_WLAN_BT_GET, &dummy)))
+			return (TRUE);
+		return (FALSE);
+
+	case ACPI_THINKPAD_METHOD_FANSPEED:
+		/* 
+		 * Some models report the fan speed in levels from 0-7
+		 * Newer models report it contiguously
+		 */
+		sc->fan_levels = (ACPI_SUCCESS(AcpiGetHandle(sc->handle, "GFAN",
+		    &sc->fan_handle)) ||
+		    ACPI_SUCCESS(AcpiGetHandle(sc->handle, "\\FSPD",
+		    &sc->fan_handle)));
+		return (TRUE);
+
+	case ACPI_THINKPAD_METHOD_FANLEVEL:
+	case ACPI_THINKPAD_METHOD_FANSTATUS:
+		/* 
+		 * Fan status is only supported on those models,
+		 * which report fan RPM contiguously, not in levels
+		 */
+		if (sc->fan_levels)
+			return (FALSE);
+		return (TRUE);
+
+	case ACPI_THINKPAD_METHOD_THERMAL:
+		if (ACPI_SUCCESS(acpi_GetInteger(sc->ec_handle,
+		    THINKPAD_NAME_THERMAL_GET, &dummy))) {
+			sc->thermal_updt_supported =
+			    ACPI_SUCCESS(acpi_GetInteger(sc->ec_handle,
+			    THINKPAD_NAME_THERMAL_UPDT, &dummy));
+			return (TRUE);
+		}
+		return (FALSE);
+	}
+	return (FALSE);
+}
+
+static void
+acpi_thinkpad_notify(ACPI_HANDLE h, UINT32 notify, void *context)
+{
+	int		event, arg, type;
+	device_t	dev = context;
+	struct acpi_thinkpad_softc *sc = device_get_softc(dev);
+
+	ACPI_FUNCTION_TRACE_U32((char *)(uintptr_t)__func__, notify);
+
+	if (notify != 0x80)
+		device_printf(dev, "Unknown notify\n");
+
+	for (;;) {
+		acpi_GetInteger(acpi_get_handle(dev), THINKPAD_NAME_EVENTS_GET,
+		    &event);
+
+		if (event == 0)
+			break;
+
+		type = (event >> 12) & 0xf;
+		arg = event & 0xfff;
+		switch (type) {
+		case 1:
+			if (!(sc->events_availmask & (1 << (arg - 1)))) {
+				device_printf(dev, "Unknown key %d\n", arg);
+				break;
+			}
+
+			/* Notify devd(8) */
+			device_printf(dev, "THINKPAD event: %u\n",
+			    (arg & 0xff));
+			acpi_UserNotify("THINKPAD", h, (arg & 0xff));
+			break;
+		default:
+			break;
+		}
+	}
+}
+
+static void
+acpi_thinkpad_refresh(void *arg)
+{
+	struct acpi_thinkpad_softc *sc = (struct acpi_thinkpad_softc *)arg;
+	char temp_cmd[] = "TMP0";
+	int data, i;
+	ACPI_INTEGER speed;
+
+	for (i = 0; i < 8; i++) {
+		temp_cmd[3] = '0' + i;
+		
+                /*
+                 * The TMPx methods seem to return +/- 128 or 0
+                 * when the respecting sensor is not available
+                 */
+		sc->sensors[i].flags &= ~SENSOR_FINVALID;
+                if (ACPI_FAILURE(acpi_GetInteger(sc->ec_handle, temp_cmd,
+                    &data)) || ABS(data) == 128 || data == 0) {
+			sc->sensors[i].flags |= SENSOR_FINVALID;
+                        data = 0;
+		}
+                else if (sc->thermal_updt_supported) {
+                        /* XXX: Temperature is reported in tenth of Kelvin */
+                        data = (data - 2732 + 5) / 10;
+		}
+		sc->sensors[i].value = data * 1000000 + 273150000;
+        }
+	
+	sc->sensors[8].flags &= ~SENSOR_FINVALID;
+	if (sc->fan_handle) {
+		if (ACPI_FAILURE(acpi_GetInteger(sc->fan_handle,
+		    NULL, &data)))
+			sc->sensors[8].flags |= SENSOR_FINVALID;
+                        data = -1;
+        }
+        else {
+                ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_FANSPEED, &speed, 2);
+                data = speed;
+        }
+
+	sc->sensors[8].value = data;
+}
diff --git a/sys/platform/pc32/conf/files b/sys/platform/pc32/conf/files
--- a/sys/platform/pc32/conf/files
+++ b/sys/platform/pc32/conf/files
@@ -72,6 +72,7 @@ dev/serial/dgb/dgm.c			optional	dgm
 ${OSACPI_MD_DIR}/acpi_machdep.c		optional        acpi
 ${OSACPI_MD_DIR}/acpi_wakeup.c		optional        acpi
 ${OSACPI_MD_DIR}/acpi_toshiba.c		optional        acpi_toshiba acpi
+${ACPICA_DIR}/acpi_thinkpad/acpi_thinkpad.c optional	acpi_thinkpad acpi
 acpi.h					optional	acpi		\
 	dependency	"$S/${ACPICA_DIR}/include/acpi.h"		\
 	compile-with	"cp $S/${ACPICA_DIR}/include/acpi.h ${.OBJDIR}/"	\



From hasso at estpak.ee  Thu Mar 20 03:49:13 2008
From: hasso at estpak.ee (Hasso Tepper)
Date: Thu, 20 Mar 2008 03:49:13 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Some questions regarding ACPI
In-Reply-To: <200803191322.46366.hasso@estpak.ee>
Message-ID: <200803201237.28823.hasso@estpak.ee>

Hasso Tepper wrote:
> There is also one fatal issue -laptop locks up hardly (no panic) while 
> unloading module. Any idea regarding this is welcome.

Nevermind, solved.


-- 
Hasso




From dillon at apollo.backplane.com  Fri Mar 21 19:24:01 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Fri, 21 Mar 2008 19:24:01 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: panic: assertion: hammer_btree_cmp(cursor->left_bound,	&cursor->node->ondisk->elms[0].leaf.base) <= 0 in btree_split_leaf
In-Reply-To: <200802232204.m1NM4cxd046264@apollo.backplane.com>
Message-ID: <200803220212.m2M2CiAY014435@apollo.backplane.com>

:While trying to find a procedure to reliably reproduce the panic
:I reported last time, I caught a different panic (uploaded at
: ~y0netan1/crash/9/ on my leaf account).  I wrote the following shell
:script (make sure to edit variables DISKS and MOUNTPT before using this
:script or it may trash your system):

    Ok, I believe I have fixed the left_bound assertion.  I also believe
    I have fixed the node ref count assertion on umount.

    There is currently one unfixed assertion related to the I/O
    path... sometimes the bp is being improperly disassociated from the
    related HAMMER structure.

    The full-filesystem case is still not being handled so don't test that :-)

					    -Matt





From c.turner at 199technologies.org  Sun Mar 23 09:48:29 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Sun, 23 Mar 2008 09:48:29 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
Message-ID: <47E6870C.4080709@199technologies.org>

I'm finally getting around to doing 1.12 upgrades, and have setup a 
separate machine to do my bulk package builds / upgrades etc,
so as not to disrupt my 'dev server' while things are being
built / tested

However, this seems kind of wasteful - the only purpose of this machine
is to build packages against a specific release..
And since building packages for a particular release generally requires 
only the userland, appropriate headers and correct 'uname' output - so:

it seems like if spoofing uname is configured inside a jail,
the next (or previous..) release can be installed into a jail and
used for building / testing packages without the overhead of a VM or 
maintaining a separate physical host

I did a quick scan of the tree to see what this would take, and, high 
level, it seems like only the following changes would need to be made:

- update struct jail to add a 'osrelease' string
  (implies bumping 'jail api' to 2?)
- update jail(8) to actually pass this information along
- update sys_uname to test ucred for jailed processes, and
  use the struct jail osrelease if appropriate
- similarly update sysctl kern.osrelease to support jail spoofing
  (if possible - didn't get this far in the research yet)
  could be less of a problem for builds, as I think most things use
 uname(1) ... but good to keep the environment consistent I suppose..
I'm still a bit confused as to how 'osrelease' is defined - everything
I'm finding is showing up as extern char[] .. perhaps this is something 
in the build I'm not familiar with?

also,

is the so-called 'stupid hackery' in sys_uname needed still?

Before I start any coding, does this:

- sound like something useful
- sound like the right approach
Thinking this could have wider useful implications e.g. for pkgbox
& so on -  for example setting up automated bulks w/various combinations 
of pkgsrc and releases, etc.

Cheers,

- Chris





From corecode at fs.ei.tum.de  Sun Mar 23 10:06:38 2008
From: corecode at fs.ei.tum.de (Simon 'corecode' Schubert)
Date: Sun, 23 Mar 2008 10:06:38 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <47E68C74.3080808@fs.ei.tum.de>

Chris Turner wrote:
I did a quick scan of the tree to see what this would take, and, high 
level, it seems like only the following changes would need to be made:
brave investigation.  but you could also simply set UNAME_r :)

sweatshorts % uname -r
1.13.0-DEVELOPMENT
sweatshorts % UNAME_r=1.12-RELEASE uname -r
1.12-RELEASE
I think that's good enough :D

cheers
  simon
--
Serve - BSD     +++  RENT this banner advert  +++    ASCII Ribbon   /"\
Work - Mac      +++  space for low ????????? NOW!1  +++      Campaign     \ /
Party Enjoy Relax   |   http://dragonflybsd.org      Against  HTML   \
Dude 2c 2 the max   !   http://golden-apple.biz       Mail + News   / \




From c.turner at 199technologies.org  Sun Mar 23 10:50:13 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Sun, 23 Mar 2008 10:50:13 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <47E69656.8080605@199technologies.org>

Simon 'corecode' Schubert wrote:
brave investigation.  but you could also simply set UNAME_r :)
Doh! Thanks for the tip!

they should change the phrase from RTFM to 'Carefully RTFM' :)

well.. scratch that change then. 1 less patch to write.

- Chris





From c.turner at 199technologies.org  Sun Mar 23 11:15:52 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Sun, 23 Mar 2008 11:15:52 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <47E69C7C.8010109@199technologies.org>

Chris Turner wrote:
Simon 'corecode' Schubert wrote:
brave investigation.  but you could also simply set UNAME_r :)

for the record - if anyone's interested - adding a line e.g.:

ALL_ENV+= UNAME_r=1.12-RELEASE

to mk.conf looks like it -might- work ..

(unless wants to chime in & verify)





From joerg at britannica.bec.de  Sun Mar 23 11:46:53 2008
From: joerg at britannica.bec.de (Joerg Sonnenberger)
Date: Sun, 23 Mar 2008 11:46:53 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <20080323181428.GA2099@britannica.bec.de>

On Sun, Mar 23, 2008 at 01:41:42PM -0400, Chris Turner wrote:
> they should change the phrase from RTFM to 'Carefully RTFM' :)

RTFMAI -- Read The Fine Manual Again, Idiot.

Joerg




From dillon at apollo.backplane.com  Sun Mar 23 20:05:36 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Sun, 23 Mar 2008 20:05:36 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
Message-ID: <200803240257.m2O2voNH038355@apollo.backplane.com>

    Here's an update on the HAMMER work!

    Current status:

    * Passes all standard filesystem stress tests and buildworld will
      run with a HAMMER /usr/obj.  Large histories are able to accumulate
      without effecting performance.

    * Pruning and reblocking code is in and partially tested, but now needs
      more stringent testing.

    * Full historical access appears to be working but needs testing.
      Note that a sync is still needed to flush dirty cached data prior
      to acquiring a timestamp for the 'snapshot' to be set in stone.
      (dirty data cached in-memory has no historical tags and must be
      committed to physical disk before it can be accessed historically).


    Current bugs:

    * There is one known bug in the standard operations code paths
      that results in an assertion in HAMMER's I/O subsystem.

    * There are probably bugs in the reblocking and/or pruning code.  More
      likely in the reblocking code.


    There are two big-ticket and several little-ticket items left.  HAMMER
    will officially go Alpha when the big-ticket items are done, and beta
    when we get a few of the little-ticket items done.

    Big ticket items left:

    * UNDO (crash recovery) code.  Currently it writes out undo records but
      they are not yet sequenced, buffer writes are not yet ordered, and
      there is no mount-time recovery code yet.

      This is the last item needed before HAMMER can go operational.

    * Filesystem full handling.  Currently no space is reserved for dirty
      cached data so it is possible to create/write files and for HAMMER
      to not have sufficient space left on-disk to flush it.


    Little ticket items:

    * Automated reblocking (currently these functions are manually
      initialized via the hammer utility).

    * I/O clustering and preliminary BMAP op when writing out large files.

    * CRC checking (CRC fields are reserved but not entirely generated yet
      and not yet checked at all).

    * Disaster Recovery filesystem scan.

    * Boot support.

    I expect all of these items and more to be handled by the 2.0 release
    in July.

			    Additional HAMMER capabilities
				(no timeline yet)

    * Adding, removing, and resizing a HAMMER filesystem's backing store.

			Ultimate Goals and working towards them
				(no timeline yet)

    Our ultimate goal with HAMMER and DragonFly in general is to support
    fully cache coherent replication in a multi-machine environment.  This
    involves several steps and networking protocols.

    * Replication of synchronization streams based on the UNDO log.  If
      resynchronizing to a target which is too old a B-Tree scan will
      likely be required.

    * Cache coherency protocols for machine-machine coherency for both
      replicated and remote-HAMMER access.

    I have no time frame for these items yet.  It will depend on how quickly
    HAMMER moves to Alpha and Beta status.  I will say, however, now
    that HAMMER's on-disk format has solidified, that I have a very precise
    understanding of the protocols that will be needed to accomplish fully
    cache coherent remote access for both replicated and non-replicated
    (remote mount style) access.

    And, as you know, fully coherent filesystem access across machines is
    going to be the basis for DragonFly's clustering across said machines.

    In summary, things are progressing very well.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From justin at shiningsilence.com  Sun Mar 23 20:10:13 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Sun, 23 Mar 2008 20:10:13 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <53758.192.168.0.252.1206327873.squirrel@www.shiningsilence.com>

On Sun, March 23, 2008 12:36 pm, Chris Turner wrote:

> it seems like if spoofing uname is configured inside a jail,
> the next (or previous..) release can be installed into a jail and
> used for building / testing packages without the overhead of a VM or
> maintaining a separate physical host

If you don't need a jail to spoof uname, as others posted, you can
installworld into a chroot and build everything you want there using
Joerg's spiffy pbulk.  That's what I'm doing on pkgbox now; I can hand you
my somewhat terse notes if you want.  It would be relatively easy to set
up the configuration you're talking about.





From sepherosa at gmail.com  Sun Mar 23 20:18:20 2008
From: sepherosa at gmail.com (Sepherosa Ziehau)
Date: Sun, 23 Mar 2008 20:18:20 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <ea7b9c170803232012n2f27f893tf1d756d7c9770419@mail.gmail.com>

On Mon, Mar 24, 2008 at 2:14 AM, Joerg Sonnenberger
<joerg at britannica.bec.de> wrote:
> On Sun, Mar 23, 2008 at 01:41:42PM -0400, Chris Turner wrote:
>  > they should change the phrase from RTFM to 'Carefully RTFM' :)
>
>  RTFMAI -- Read The Fine Manual Again, Idiot.

http://leaf.dragonflybsd.org/~sephe/rtfm.jpg

:D

>
>  Joerg
>



-- 
Live Free or Die




From justin at shiningsilence.com  Sun Mar 23 20:38:30 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Sun, 23 Mar 2008 20:38:30 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: GSoC 2008 - mentors signup
Message-ID: <53885.192.168.0.252.1206329503.squirrel@www.shiningsilence.com>

If you are planning to be a mentor for a Summer of Code project, please
sign up here for the mentors mailing list:

http://groups.google.com/group/google-summer-of-code-mentors-list

If you've already signed up, your subscription should be set up tomorrow.





From justin at shiningsilence.com  Sun Mar 23 21:12:01 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Sun, 23 Mar 2008 21:12:01 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: GSoC 2008 - mentors signup
In-Reply-To: <53885.192.168.0.252.1206329503.squirrel@www.shiningsilence.com>
Message-ID: <54025.192.168.0.252.1206331572.squirrel@www.shiningsilence.com>

Also!

If you are a potential mentor and you have not done so yet:

http://code.google.com/soc/mentor_step1.html

Get yourself registered as a mentor for the Summer of Code project.  Once
you are in there, check off DragonFly in the "My Profile" section.

You will need a Google Account if you don't have one:

http://www.google.com/accounts

This will add you to the list of mentors in the Google Summer of Code web
application, so you can review/be attached to projects.

A guide is available if you want more information:

http://groups.google.com/group/google-summer-of-code-announce/web/guide-to-the-gsoc-web-app-for-mentors-and-organization-administrators






From c.turner at 199technologies.org  Mon Mar 24 04:29:28 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Mon, 24 Mar 2008 04:29:28 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <47E78ECE.4070307@199technologies.org>

Justin C. Sherrill wrote:
If you don't need a jail to spoof uname, as others posted, you can
installworld into a chroot and build everything you want there using
Joerg's spiffy pbulk.  That's what I'm doing on pkgbox now; I can hand you
my somewhat terse notes if you want.  It would be relatively easy to set
up the configuration you're talking about.
cheers - I guess I thought incorrectly that something 'special' was 
needed to get the uname to change .. have been using the legacy bulks in 
chroots / jails (for 'same os' builds) as I haven't quite migrated to 
pbulk yet ..

thanks for the help offer - I'll ask if I run into trouble.




From dillon at apollo.backplane.com  Mon Mar 24 08:28:49 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Mon, 24 Mar 2008 08:28:49 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <200803241500.m2OF0CG8043760@apollo.backplane.com>


:http://leaf.dragonflybsd.org/~sephe/rtfm.jpg
:
::D

    Ho!

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From elekktretterr at exemail.com.au  Mon Mar 24 09:10:15 2008
From: elekktretterr at exemail.com.au (Petr Janda)
Date: Mon, 24 Mar 2008 09:10:15 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
In-Reply-To: <200803240257.m2O2voNH038355@apollo.backplane.com>
Message-ID: <200803250138.49775.elekktretterr@exemail.com.au>


>
>     And, as you know, fully coherent filesystem access across machines is
>     going to be the basis for DragonFly's clustering across said machines.
>
>     In summary, things are progressing very well.
>


Hi Matt,
That's good to know things are going so well. Got a question. If memory serves 
me right, initially there was also going to be a thing called ANVIL, I can't 
remember what it was supposed to do and whether its still in your design. 
Could you elaborate a little?

Thanks,
Petr




From dillon at apollo.backplane.com  Mon Mar 24 14:12:11 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Mon, 24 Mar 2008 14:12:11 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
In-Reply-To: <200803240257.m2O2voNH038355@apollo.backplane.com>
Message-ID: <200803242100.m2OL0nWV046868@apollo.backplane.com>


:Hi Matt,
:That's good to know things are going so well. Got a question. If memory serves 
:me right, initially there was also going to be a thing called ANVIL, I can't 
:remember what it was supposed to do and whether its still in your design. 
:Could you elaborate a little?
:
:Thanks,
:Petr

    It's not really in the HAMMER design any more, primarily because HAMMER's
    volume model seems to work fine as-is.  Ultimately something like ANVIL
    (a block storage manager) would prove beneficial to the project but it
    would be treated as a separate project.  HAMMER's redundancy model is
    going to be baesd around replication and clustering.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From tgen at netphreax.net  Mon Mar 24 18:31:37 2008
From: tgen at netphreax.net (Thomas E. Spanjaard)
Date: Mon, 24 Mar 2008 18:31:37 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
In-Reply-To: <200803240257.m2O2voNH038355@apollo.backplane.com>
Message-ID: <47E85337.2070407@netphreax.net>

Matthew Dillon wrote:
    * Full historical access appears to be working but needs testing.
      Note that a sync is still needed to flush dirty cached data prior
      to acquiring a timestamp for the 'snapshot' to be set in stone.
      (dirty data cached in-memory has no historical tags and must be
      committed to physical disk before it can be accessed historically).
Wouldn't making timestamp queries (at least from userland) enforce a 
sync on the volume in question be useful here?
--
        Thomas E. Spanjaard
        tgen at netphreax.net
Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00005.pgp
Type: application/octet-stream
Size: 186 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080324/3077333f/attachment-0003.obj>

From dillon at apollo.backplane.com  Mon Mar 24 20:10:12 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Mon, 24 Mar 2008 20:10:12 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
In-Reply-To: <200803240257.m2O2voNH038355@apollo.backplane.com>
Message-ID: <200803250302.m2P32qLP050160@apollo.backplane.com>


:Wouldn't making timestamp queries (at least from userland) enforce a 
:sync on the volume in question be useful here?
:-- 
:         Thomas E. Spanjaard
:         tgen at netphreax.net

    Making the 'hammer now' command do a sync() is a good idea.  I will
    make that change right now so it doesn't get lost.

    Here's a general overview of the issues involved with having historical
    access to the filesystem:

				----------------

    Recording the timestamps in the in-memory cache, for a finer-grained
    snapshot capability, is doable but has its own issues.  Here's an
    illustration:

    open()  create file
    write() append 4K	(file size now 4K)
    write() append 4K	(file size now 8K)
    write() append 4K	(file size now 12K)
    write() append 4K	(file size now 16K)

    Now NONE of this has gone to disk yet, it's entirely in the in-memory
    cache.  The inode is in the in-memory cache.  The data is stored in
    the buffer cache.  Even the directory entry for the file that we
    just created is still in the in-memory cache (HAMMER caches the raw
    records it intends to commit later on).

    If I wanted to be able to acquire a timestamp between each write and
    'see' a snapshot of the file as of any point in the above sequence,
    then every write would also have to allocate a copy of the inode
    (because it changes size on each write).

    The data has the same problem though with a slightly different example.
    Lets say each write() was a seek-write, overwriting the previous data.
    Now with every write() I would have to allocate a copy of the data
    being overwritten.  This is complicated by the fact that the buffer
    cache has no clue about 'historical' accesses, so I would not be able
    to use the buffer cache to cache the data.

    There's also another problem and that is with the efficiency of the
    topology on-disk.  Even if I maintained all the copies of the inode
    and all the copies of the data in-memory, I would still have to sync
    all those copies to disk in order for things to remain historically
    coherent (whether it be in-cache or on-disk).  This would result in
    hundreds or even thousands of copies of the inode on-disk, not to
    mention potentially many copies of the data.

    I just don't want to do that right now, at least not as a default.  A
    lot of performance would be lost.  Hence a sync() is needed if
    you want to create a demark which you can accurately snapshot.

				-------------

    Here's a quick synopsis of how the cache would operate in a clustered
    filesystem:

    In order to properly integrate with in-memory caches, a wider cache
    coherency infrastructure is needed between machines such that
    modifications made on one machine proactively invalidate those
    protions of the cache(s) on other machines.  At the same time, any
    'dirty' cache data, for example when a file is created or written to,
    must lock the cache space in question on all other machines.
    The cache space in this case is not just the file data, but also the
    related namespaces (for creations, deletions, and renames).  Attempts
    to access locked spaces from other machines in the cluster would have
    to force a flush to the filesystem backing store and lower the cache
    states for the effected information on the original machine from dirty
    to shared-read-only.

    It will be easiest to integrate the cache coherency information into
    the buffer cache and namecache themselves.  Once a machine has dirtied
    an in-memory cache element... for example part of the namespace when
    creating a file or chunks of data written within a file, that machine
    must have a free hand to make further modifications to the cache spaces
    involved without further interaction with other machines.

				-------------

    Now, if you think of those two major elements you can see that they
    actually fit together quite well.  If I were to attempt to maintain
    transactional coherency on a per-system-call basis then the cache
    granularity between machines would have to be much, much smaller then
    our current in-memory caching elements provide.  That would become
    a really nasty coding problem.  So I don't even want to begin to
    complate transactional coherency at a finer-grain then sync() or
    fsync() until long after we actually have clustering working.

						-Matt





From elekktretterr at exemail.com.au  Mon Mar 24 21:56:58 2008
From: elekktretterr at exemail.com.au (Petr Janda)
Date: Mon, 24 Mar 2008 21:56:58 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
In-Reply-To: <200803240257.m2O2voNH038355@apollo.backplane.com>
Message-ID: <200803251516.16407.elekktretterr@exemail.com.au>

So is it needed to run hammer now in order to "create" a snapshot? What would 
I do in situation like this: got a hammer filesystem and couple of the files 
change on day to day basis. Then a week later I needed to access one of the 
files, in exactly the state they were 7 days ago.

Cheers,
Petr




From dillon at apollo.backplane.com  Mon Mar 24 22:34:15 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Mon, 24 Mar 2008 22:34:15 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
In-Reply-To: <200803240257.m2O2voNH038355@apollo.backplane.com>
Message-ID: <200803250526.m2P5QZ5X051081@apollo.backplane.com>


:So is it needed to run hammer now in order to "create" a snapshot? What would 
:I do in situation like this: got a hammer filesystem and couple of the files 
:change on day to day basis. Then a week later I needed to access one of the 
:files, in exactly the state they were 7 days ago.
:
:Cheers,
:Petr

    No, you do not have to run 'hammer now' to create a snapshot.  The
    kernel syncs all filesystems every 30 seconds, so if you do nothing
    at all you get a snapshot granularity of 30 seconds.

    Where you would use 'hammer now' is if you wanted the most current
    snapshot possible for the purpose of, say, backing up your filesystem
    to another machine.  You might do something like this:

	set timestamp = `hammer now`
	cpdup /mountpoint/@@$timestamp targethost:/somepath

    But if you didn't care about that you could just go back far enough
    that you get a stable historical view... e.g. go back 1 minute and you
    would have a stable view into your filesystem.

	set timestamp = `hammer stamp 60s`		<------ doesn't sync
	cpdup /mountpoint/@@$timestamp targethost:/somepath


    Ultimately the idea of managing filesystems this way is to still do
    regular backups from your production machine to your backup machine
    (ultimately by way of replication), with both running HAMMER, but only
    retain a limited amount of history on the production box.  You might
    desire to retain only one week's worth of history on the production box,
    retain one month's history on your local backup box, and retain a very
    granular one year's worth of history on your remote backup box.

    Come to think of it, I should add some more directives to the
    'hammer prune' command to make that easier to specify.

    Until I implement a live replication 'feed' the minimum granularity on
    the backup box will be how often you do your backups (e.g. once a day),
    and you can prune it into more granular forms from that starting point.
    Once we have a live replication feed the backup box will have the same
    30-second granularity that the production machine has.

    A major bullet point for this style of management is that the retention
    policy on the various boxes can be different even though they are
    all slaved off the same production filesystem.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From justin at shiningsilence.com  Tue Mar 25 05:58:49 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Tue, 25 Mar 2008 05:58:49 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: SoC - student signups
Message-ID: <58180.65.106.147.226.1206449676.squirrel@www.shiningsilence.com>

Here's a quick link roundup:

Are you a student?  Put in your application for a Google Summer of Code here:

http://code.google.com/soc/2008/student_signup.html

Student guide:
http://groups.google.com/group/google-summer-of-code-announce/web/guide-to-the-gsoc-web-app-for-student-applicants

Are you a mentor?  (That means hasso, hsu, sephe, matthias, TGEN, and
corecode right now)

Student proposals will show up on the mentor page, linked below.  You will
get to rate them, and take the one(s) that you want to mentor.

Mentor page:
http://code.google.com/soc/2008/mentor_home.html
Mentor guide:
http://groups.google.com/group/google-summer-of-code-announce/web/guide-to-the-gsoc-web-app-for-mentors-and-organization-administrators

If you are a mentor and are communicating with potential students, send
them the URLs above for student signup and the student guide; work with
them if they ask for advice on what to say in the application.  They can
resubmit up to 20 times if they want to correct it.

Deadline is March 31st.






From noah.yan at gmail.com  Thu Mar 27 20:17:48 2008
From: noah.yan at gmail.com (Yonghong Yan)
Date: Thu, 27 Mar 2008 20:17:48 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: About DFBSD.64
In-Reply-To: <47EB0B5B.5020802@gmail.com>
Message-ID: <59521b110803272015y1cc8cc39uc93f154ed36e0505@mail.gmail.com>

thanks for your interest.

I owe to everybody for any update or work in the past four months. so
many things happen in my work and my family (they are all good:) and
keep me extremely busy. But i am not leaving and will be back on this
soon.

the latest sources are in http://repo.or.cz/w/dragonfly/port-amd64.git
, I did have a compiled kernel long time before, but I have to break
it to work on the pmap. you can pick up from there. TGEN will help you
a lot, also keep me posted too, if you like.

Noah

On Wed, Mar 26, 2008 at 9:50 PM, Sdavtaker <sdavtaker at gmail.com> wrote:
> Hello,
>  Im applying to GSoC to work in the x64 version of DFBSD with TGEN, i
>  found some work already done in the repository and some mails in the
>  archive from you.
>  I was wondering if you already had a working compiled kernel in AMD64
>  machine and what was not working yet to continue that work.
>  Thanks for any info.
>  Sdav
>




From dillon at apollo.backplane.com  Sat Mar 29 13:27:43 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Sat, 29 Mar 2008 13:27:43 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 29-Mar-2008
Message-ID: <200803292022.m2TKMLGe004942@apollo.backplane.com>

    Good progress continues to be made.  HAMMER survived acting as my
    LAN backup machine (in full historical mode) for almost a week before
    it hit an assertion.  I've fixed that issue and believe that the core
    filesystem implementation code is now 'very stable'.

    Note that the recent commit will result in many more 'hammer_lock_ex:'
    messages on the console then you may have previously observed.  This is
    due to the way object id's are allocated in the face of parallel 
    modifications to the filesystem, resulting in too much locality of
    reference in the B-Tree.  I do intend to improve it.

    I am still working on the two major items needed before HAMMER can be
    declared operational, those being the filesystem full handling and the
    undo/recovery-on-mount code.  These are the last 'hard' bits left in
    the design.

    With exception to filling up the filesystem, which *will* create a mess,
    and noting that no crash recovery code exists yet (so you have to newfs
    it if you crash), I'd appreciate it if interested parties could test
    the other functions of the filesystem, in particular the pruning and
    reblocking functions (man hammer), and the historical access functions.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From dillon at apollo.backplane.com  Sun Mar 30 15:11:03 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Sun, 30 Mar 2008 15:11:03 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Need ideas on how to solve an st_ino/st_dev test issue for HAMMER.
Message-ID: <200803302207.m2UM7BCp016402@apollo.backplane.com>

    Here's the problem, given historical access softlinks as shown below:

test30# ls -lda cra*
drwxr-xr-x  1 root  wheel  Mar 29 13:04 crater
lrwxr-xr-x  1 root  wheel  Mar 29 18:57 crater.20080329 -> crater@@0x47eef383
lrwxr-xr-x  1 root  wheel  Mar 30 01:24 crater.20080330 -> crater@@0x47ef4e29
-rw-r--r--  2 root  wheel  Mar 30 01:24 crater.log

    The problem is that if I do this:

    diff -r crater.20080329/var/log crater.20080330/var/log

    Diff just returns without actually diffing anything.  The reason is
    because diff checks st_ino and st_dev and believes the directories/files
    to be identical because they match.

    I considered munging the inode number for historical accesses, but
    that would seriously break NFS exports which try to access historical
    files and directories.  Right now NFS *is* able to distinguish between
    the two because NFS handles are 128-bit-wide entities, so I can encode
    the as-of transaction id as part of the filehandle.  But userland
    programs only have access to a 64-bit-wide inode so userland still
    believes the files to be identical.

    st_dev is only 32 bits, carefully munging it is an option if we
    could figure out a way to do it, but I'd rather not.

    I am considering using st_gen but then we'd have to patch third
    party software to test st_gen along with everything else.  This may
    be the only workable solution, though, and only a few programs would
    need to be patched.  st_gen is only 32 bits but it would solve the
    problem as we would be able to use all 32 bits.

    If anyone has any bright ideas, including 'leave it alone', I'm all
    ears.

						-Matt





From justin at shiningsilence.com  Mon Mar 31 10:40:42 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Mon, 31 Mar 2008 10:40:42 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: SoC student applications due by 5PM PDT tomorrow
In-Reply-To: <1942.192.168.0.242.1206930479.squirrel@www.shiningsilence.com>
Message-ID: <11892.67.108.184.175.1206984967.squirrel@www.shiningsilence.com>

On Sun, March 30, 2008 10:27 pm, Justin C. Sherrill wrote:
> SoC students:
>
> If you have an application to submit for DragonFly/Summer of Code, please
> do so by 17:00 Pacific time on the 31st - that's tomorrow, at least for
> me.

The deadline for student proposals has been extended to April 7th; all
other dates move forward one week to acommodate.

This is a good time to update existing applications or submit new ones. 
Talk to your (potential) mentors if you are curious.






From nthery at gmail.com  Mon Mar 31 11:29:49 2008
From: nthery at gmail.com (Nicolas Thery)
Date: Mon, 31 Mar 2008 11:29:49 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
Message-ID: <64fc43b0803311126na7d0b27obaa9d35bac6d32ee@mail.gmail.com>

Hello,

Now that the release is over, I'll try to get rid of zones and migrate
allocations to objcache.

Here is a 1st patch that migrate struct proc.  I'll commit it in a
couple of days if nobody objects.

I'm also implementing a way to monitor objcache statistics.  So far,
I've hacked sth similar to
sysctl vm.zone: stats are returned in one giant string, one line per
cache.  That's simple but ugly and hard to read because there are
quite a few stats per cache.

So I'm thinking about implementing a small tool, ocstat, that extracts
stats from sysctl the way ps(1) does (thru libkvm iirc) and formats it
in various ways.  What do you think?

Cheers,
Nicolas

Index: src2/sys/kern/kern_exit.c
===================================================================
--- src2.orig/sys/kern/kern_exit.c	2008-03-31 08:05:59.139796000 +0200
+++ src2/sys/kern/kern_exit.c	2008-03-31 10:31:39.000000000 +0200
@@ -834,7 +834,7 @@ loop:
 			}

 			vm_waitproc(p);
-			zfree(proc_zone, p);
+			objcache_put(proc_cache, p);
 			nprocs--;
 			return (0);
 		}
Index: src2/sys/kern/kern_proc.c
===================================================================
--- src2.orig/sys/kern/kern_proc.c	2008-03-31 08:05:59.139918000 +0200
+++ src2/sys/kern/kern_proc.c	2008-03-31 10:31:39.000000000 +0200
@@ -84,7 +84,7 @@ u_long pgrphash;
 struct proclist allproc;
 struct proclist zombproc;
 struct spinlock allproc_spin;
-vm_zone_t proc_zone;
+struct objcache* proc_cache;
 vm_zone_t lwp_zone;
 vm_zone_t thread_zone;

@@ -131,7 +131,7 @@ procinit(void)
 	spin_init(&allproc_spin);
 	pidhashtbl = hashinit(maxproc / 4, M_PROC, &pidhash);
 	pgrphashtbl = hashinit(maxproc / 4, M_PROC, &pgrphash);
-	proc_zone = zinit("PROC", sizeof (struct proc), 0, 0, 5);
+	proc_cache = objcache_create_simple(M_PROC, sizeof(struct proc));
 	lwp_zone = zinit("LWP", sizeof (struct lwp), 0, 0, 5);
 	thread_zone = zinit("THREAD", sizeof (struct thread), 0, 0, 5);
 	uihashinit();
Index: src2/sys/sys/proc.h
===================================================================
--- src2.orig/sys/sys/proc.h	2008-03-31 08:05:59.140325000 +0200
+++ src2/sys/sys/proc.h	2008-03-31 10:31:39.000000000 +0200
@@ -473,7 +473,7 @@ struct proc *zpfind (pid_t);	/* Find zom
 struct vm_zone;
 struct globaldata;
 struct lwp_params;
-extern struct vm_zone *proc_zone;
+extern struct objcache *proc_cache;
 extern struct vm_zone *lwp_zone;

 int	enterpgrp (struct proc *p, pid_t pgid, int mksess);
Index: src2/sys/kern/kern_fork.c
===================================================================
--- src2.orig/sys/kern/kern_fork.c	2008-03-31 08:05:59.140042000 +0200
+++ src2/sys/kern/kern_fork.c	2008-03-31 10:31:39.000000000 +0200
@@ -332,7 +332,7 @@ fork1(struct lwp *lp1, int flags, struct
 	}

 	/* Allocate new proc. */
-	p2 = zalloc(proc_zone);
+	p2 = objcache_get(proc_cache, M_WAITOK);
 	bzero(p2, sizeof(*p2));

 	/*




From hsu at dragonflybsd.org  Mon Mar 31 11:44:34 2008
From: hsu at dragonflybsd.org (Jeffrey Hsu)
Date: Mon, 31 Mar 2008 11:44:34 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <64fc43b0803311126na7d0b27obaa9d35bac6d32ee@mail.gmail.com>
Message-ID: <200803311841.m2VIfQAI007579@nlpi001.prodigy.net>

The object cache is not a general-purpose memory allocator.  It's a cache of
pre-initialized objects.  Are the significant portions of the proc structure
that can be restored to initialized state on object puts?  If not, it's best
to just use a general-purpose memory allocator.

								Jeffrey




From corecode at fs.ei.tum.de  Mon Mar 31 12:07:02 2008
From: corecode at fs.ei.tum.de (Simon 'corecode' Schubert)
Date: Mon, 31 Mar 2008 12:07:02 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <200803311841.m2VIfQAI007579@nlpi001.prodigy.net>
Message-ID: <47F1357B.1070302@fs.ei.tum.de>

Jeffrey Hsu wrote:
> The object cache is not a general-purpose memory allocator.  It's a cache of
> pre-initialized objects.  Are the significant portions of the proc structure
> that can be restored to initialized state on object puts?  If not, it's best
> to just use a general-purpose memory allocator.

Why?  What's the loss if we use the object cache to allocate struct procs?

cheers
  simon

Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00006.pgp
Type: application/octet-stream
Size: 252 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080331/a4a24314/attachment-0003.obj>

From nthery at gmail.com  Mon Mar 31 12:17:03 2008
From: nthery at gmail.com (Nicolas Thery)
Date: Mon, 31 Mar 2008 12:17:03 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <nthery@gmail.com>
Message-ID: <64fc43b0803311214u7da6bbb8xaf971de1a80e7258@mail.gmail.com>

2008/3/31, Jeffrey Hsu <hsu at dragonflybsd.org>:
> The object cache is not a general-purpose memory allocator.  It's a cache of
>  pre-initialized objects.  Are the significant portions of the proc structure
>  that can be restored to initialized state on object puts?  If not, it's best
>  to just use a general-purpose memory allocator.

Well, I haven't checked this yet.  I planned to do this in a second
step after getting rid of zones.

I thought that even without  the pre-initialization part, objcache has
the advantage
of pre-allocating set of objects (as zones) and is additionally
mp-safe (contrary to zones and, granted, as malloc()).   The latter
may be interesting as we talk of improving MP support.

Cheers,
Nicolas




From dillon at apollo.backplane.com  Mon Mar 31 12:23:40 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Mon, 31 Mar 2008 12:23:40 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <200803311841.m2VIfQAI007579@nlpi001.prodigy.net>
Message-ID: <200803311921.m2VJLITB027669@apollo.backplane.com>

    I both agree and disagree with Jeff.  I think the only *disadvantage*
    to using objcache for struct proc is that objcache must cache a minimum
    number of free structures to be efficient so the overall kernel memory
    use would be a bit greater verses uses kmalloc().  But I agree with Jeff
    in that objcache's biggest advantage is that you can keep structural state
    intact and struct proc might not be a good candidate (yet).

    What I suggest is that you convert struct proc from zone to kmalloc
    first, and then look into a possible objcache adaptation.  kmalloc
    is not slow.. it's a very fast allocator.  Objcache is probably a tad
    faster but not by much.  Where objcache really wins is in not having
    to completey reinitialize the allocated structures.

    Over the years I've removed (I think) all the dependancies on requiring
    the proc structure to be in stable memory so I believe it can be moved to
    kmalloc/objcache now without any major pain.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From corecode at fs.ei.tum.de  Mon Mar 31 12:37:40 2008
From: corecode at fs.ei.tum.de (Simon 'corecode' Schubert)
Date: Mon, 31 Mar 2008 12:37:40 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: SoC student applications due by 5PM PDT tomorrow
In-Reply-To: <1942.192.168.0.242.1206930479.squirrel@www.shiningsilence.com>
Message-ID: <47F13CDA.6010703@fs.ei.tum.de>

Justin C. Sherrill wrote:
> On Sun, March 30, 2008 10:27 pm, Justin C. Sherrill wrote:
>> SoC students:
>>
>> If you have an application to submit for DragonFly/Summer of Code, please
>> do so by 17:00 Pacific time on the 31st - that's tomorrow, at least for
>> me.
> The deadline for student proposals has been extended to April 7th; all
> other dates move forward one week to acommodate.

This is very good.

Some more ideas for eager students (we want to keep the ratio, right?):

Enhance the FreeBSD/DragonFly sound infrastructure to support surround
sound/multichannel output.

Update sound drivers to support S/PDIF output.

Make the sound infrastructure OSSv4 compatible (there was a SoC at
FreeBSD last year or so)


of course only if it doesn't exist already :)

cheers
  simon


Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00007.pgp
Type: application/octet-stream
Size: 252 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080331/6da61cff/attachment-0003.obj>

From corecode at fs.ei.tum.de  Mon Mar 31 12:41:30 2008
From: corecode at fs.ei.tum.de (Simon 'corecode' Schubert)
Date: Mon, 31 Mar 2008 12:41:30 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <200803311841.m2VIfQAI007579@nlpi001.prodigy.net>
Message-ID: <47F13DE4.10205@fs.ei.tum.de>

Matthew Dillon wrote:
>     What I suggest is that you convert struct proc from zone to kmalloc
>     first, and then look into a possible objcache adaptation.  kmalloc
>     is not slow.. it's a very fast allocator.  Objcache is probably a tad
>     faster but not by much.  Where objcache really wins is in not having
>     to completey reinitialize the allocated structures.

Could we please not move to kmalloc, but instead try to move all fast
path allocations to objcache?  I don't like the idea of allocating
everything with kmalloc.  Caching struct procs is not a bad thing itself.

cheers
  simon


Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00008.pgp
Type: application/octet-stream
Size: 252 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080331/ac328c08/attachment-0003.obj>

From hsu at FreeBSD.org  Mon Mar 31 12:59:05 2008
From: hsu at FreeBSD.org (Jeffrey Hsu)
Date: Mon, 31 Mar 2008 12:59:05 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <47F1357B.1070302@fs.ei.tum.de>
Message-ID: <200803311920.m2VJK5Ln018015@nlpi015.prodigy.net>

The object cache sits on top of a general-purpose memory allocator such
as kmalloc or zalloc and provides pre-initialized object caching functionality.
If you're not going to use the object caching functionality, you can just
call the underlying memory allocator directly.

							Jeffrey




From dillon at apollo.backplane.com  Mon Mar 31 16:17:19 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Mon, 31 Mar 2008 16:17:19 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <200803311841.m2VIfQAI007579@nlpi001.prodigy.net>
Message-ID: <200803312311.m2VNBumd029866@apollo.backplane.com>

:Could we please not move to kmalloc, but instead try to move all fast
:path allocations to objcache?  I don't like the idea of allocating
:everything with kmalloc.  Caching struct procs is not a bad thing itself.=
:
:
:cheers
:  simon

    I will state for the record that I'm fine with either objcache or
    kmalloc.  I agree with Jeff that using objcache for struct proc
    probably isn't necessary but I also agree that it would not hurt either,
    and if the intent is to optimize the initialization of the proc
    structure in the future then moving to objcache now would save us
    from having to do it later.

    So whichever method Nicolas wants to use is fine with me.

						-Matt




From hsu at dragonflybsd.org  Mon Mar 31 19:22:47 2008
From: hsu at dragonflybsd.org (Jeffrey Hsu)
Date: Mon, 31 Mar 2008 19:22:47 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <64fc43b0803311214u7da6bbb8xaf971de1a80e7258@mail.gmail.com>
Message-ID: <200804010218.m312IVUq003624@nlpi043.prodigy.net>

  >> Are there significant portions of the proc structure
  >> that can be restored to initialized state on object puts?

  > I planned to do this in a second step after getting rid of zones.

I'll all in favor of making more use of caching pre-initialized objects, so
if this is your objective, then please go ahead.  It's just that I'd convert
over to the object cache in one step.

  > I thought that even without  the pre-initialization part, objcache has
  > the advantage of pre-allocating set of objects (as zones) and is additionally
  > mp-safe (contrary to zones and, granted, as malloc()).

Well, the zone allocator is MP-safe.  It's not hard to lock up the places that
manipulate the linked-list of free items. Look for uses of the zlock field.

								Jeffrey




From tgen at netphreax.net  Sat Mar  1 12:57:53 2008
From: tgen at netphreax.net (Thomas E. Spanjaard)
Date: Sat, 1 Mar 2008 12:57:53 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: [Fwd: Project Support Open Source: $50 donation to support you      project]
In-Reply-To: <2468.192.168.0.242.1204346451.squirrel@www.shiningsilence.com>
Message-ID: <47C9C1B7.50203@netphreax.net>

Justin C. Sherrill wrote:
The "donation" happens after you place an "acknowledgement" on an open
source project's web page.  I'm putting those words in scare quotes
because I think it's a "payment" for an "advertisement".  The supplied
link has nothing to do with DragonFly, to say the least.

<a href="http://www.2insure4less.com /" title="We support FOSS software
projects.">Online Insurance Quotes</a>
To think our souls are only worth $50...
--
        Thomas E. Spanjaard
        tgen at netphreax.net
Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00000.pgp
Type: application/octet-stream
Size: 186 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080301/0d61e240/attachment-0004.obj>

From c.turner at 199technologies.org  Sat Mar  1 17:52:31 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Sat, 1 Mar 2008 17:52:31 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Misc. ACPI / suspend
Message-ID: <47CA073B.6020106@199technologies.org>

Wondering if anyone more well versed in the ACPI implementation could
comment on the applicability of:
http://lkml.org/lkml/2007/4/6/69

w/r/t the current state of the art in Dfly

(or BSD's in general)

Cheers!

- Chris




From elekktretterr at exemail.com.au  Sun Mar  2 00:41:25 2008
From: elekktretterr at exemail.com.au (Petr Janda)
Date: Sun, 2 Mar 2008 00:41:25 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: CARP question
Message-ID: <200803021934.21669.elekktretterr@exemail.com.au>

So Ive setup CARP on 2 DF-based mailservers. Installation went fine. Box 1 has 
adskew of 0 therefore it is the MASTER. Box 2 has adskew of 254, therefore is 
BACKUP.  If i down the carp0 interface on Box 1, then Box 2 carp interface 
gets promoted to MASTER. Then I up the carp interface on Box 1, logically Box 
2 should become BACKUP again as Box 1 becomes MASTER due to adskew set to 0.

However it doesnt happen. When carp0 interface on Box 1 is upped it becomes a 
BACKUP, not a MASTER even though according to adskew it should be MASTER.

What is the desired behaviour?

Cheers
Petr




From qhwt+dfly at les.ath.cx  Sun Mar  2 02:50:14 2008
From: qhwt+dfly at les.ath.cx (YONETANI Tomokazu)
Date: Sun, 2 Mar 2008 02:50:14 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: panic: assertion: hammer_btree_cmp(cursor->left_bound,	&cursor->node->ondisk->elms[0].leaf.base) <= 0 in btree_split_leaf
In-Reply-To: <200802232204.m1NM4cxd046264@apollo.backplane.com>
Message-ID: <20080302104554.GA22813@les.ath.cx>

Hi.
While trying to find a procedure to reliably reproduce the panic
I reported last time, I caught a different panic (uploaded at
 ~y0netan1/crash/9/ on my leaf account).  I wrote the following shell
script (make sure to edit variables DISKS and MOUNTPT before using this
script or it may trash your system):
  #!/bin/sh -ex
  DISKS="/dev/ad0s1f"
  MOUNTPT=/mnt/HAMMER

  cd /
  newfs_hammer -L TEST $DISKS
  for i in `seq 1 100`; do
	  mount_hammer $DISKS $MOUNTPT
	  /bin/rm -rf $MOUNTPT/??
	  (set +x; for x in `seq 1 10000`; do echo -n > $MOUNTPT/$x; done)
	  umount $MOUNTPT
  done

And the panic is triggered by rm command.
I'll try to see if it's possible to reproduce the last one without
unmounting then mounting the HAMMER fs.

Cheers.




From dillon at apollo.backplane.com  Sun Mar  2 13:25:33 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Sun, 2 Mar 2008 13:25:33 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: panic: assertion: hammer_btree_cmp(cursor->left_bound,	&cursor->node->ondisk->elms[0].leaf.base) <= 0 in btree_split_leaf
In-Reply-To: <200802232204.m1NM4cxd046264@apollo.backplane.com>
Message-ID: <200803022119.m22LJRCY037076@apollo.backplane.com>


:Hi.
:While trying to find a procedure to reliably reproduce the panic
:I reported last time, I caught a different panic (uploaded at
: ~y0netan1/crash/9/ on my leaf account).  I wrote the following shell
:script (make sure to edit variables DISKS and MOUNTPT before using this
:script or it may trash your system):

(from the core)

panic: assertion: node->lock.refs == 0 && node->ondisk == NULL in hammer_flush_buffer_nodes

    Yah, I've seen this failure.  Add a sync or two before the umount and
    tell me if it still occurs.  It's either a node reference leak somewhere
    or it is a race between bufdaemon and umount.  The assertions are really
    strict there precisely to catch those sorts of cases.

    Also note that the code to deal with a full HAMMMER filesystem has not
    been written yet (The failure you are reporting is unrelated to a full
    HAMMER filesystem, though, just mentioning it).

						-Matt





From dillon at apollo.backplane.com  Sun Mar  2 13:29:03 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Sun, 2 Mar 2008 13:29:03 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Misc. ACPI / suspend
In-Reply-To: <47CA073B.6020106@199technologies.org>
Message-ID: <200803022126.m22LQbfI037188@apollo.backplane.com>


:Wondering if anyone more well versed in the ACPI implementation could
:comment on the applicability of:
:
:http://lkml.org/lkml/2007/4/6/69
:
:w/r/t the current state of the art in Dfly
:
:(or BSD's in general)
:
:Cheers!
:
:- Chris

    I really have no idea re: this.  Suspension in general is not well
    supported by any of the BSDs.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From dillon at apollo.backplane.com  Sun Mar  2 13:34:05 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Sun, 2 Mar 2008 13:34:05 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: [Fwd: Project Support Open Source: $50 donation to support you      project]
In-Reply-To: <2468.192.168.0.242.1204346451.squirrel@www.shiningsilence.com>
Message-ID: <200803022131.m22LVOe9037250@apollo.backplane.com>

:..
:source project's web page.  I'm putting those words in scare quotes
:because I think it's a "payment" for an "advertisement".  The supplied
:link has nothing to do with DragonFly, to say the least.
:
:I don't think this is a good idea, obviously, and replied to that effect. 
:However, I wanted to put this on a DragonFly list, in part to show this
:strange thing, and in part because I'm not comfortable making
:administrative decisions on behalf of the Project without being open as
:possible about it.

    It doesn't really cry out to me either.

						-Matt





From wbh at conducive.org  Sun Mar  2 20:36:32 2008
From: wbh at conducive.org (Bill Hacker)
Date: Mon, 03 Mar 2008 04:36:32 +0000
Subject: Misc. ACPI / suspend
In-Reply-To: <47CA073B.6020106@199technologies.org>
Message-ID: <47cb8050$0$855$415eb37d@crater_reader.dragonflybsd.org>

Matthew Dillon wrote:
:Wondering if anyone more well versed in the ACPI implementation could
:comment on the applicability of:
:
:http://lkml.org/lkml/2007/4/6/69
:
:w/r/t the current state of the art in Dfly
:
:(or BSD's in general)
:
:Cheers!
:
:- Chris
    I really have no idea re: this.  Suspension in general is not well
    supported by any of the BSDs.
					-Matt
					Matthew Dillon 
					<dillon at backplane.com>


. . and there seems to be a bit of a 'Catch 22' there in any case.

If the BIOS can alter 'stuff' out of site of the OS it is parking, what 
does the existence of such a 'feature' do to a(ny) security model?

Seems to at least beg creating the option of setting a flag to 
specifically *prevent* suspend-to-disk/hibernation (and/or force a 
reboot on wake-up).

Just because one is paranoid....  etc

Bill





From matthias at dragonflybsd.org  Tue Mar  4 02:30:52 2008
From: matthias at dragonflybsd.org (Matthias Schmidt)
Date: Tue, 4 Mar 2008 02:30:52 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
Message-ID: <20080304102335.GI9833@staatsfeind.org>

Hi,

Google just announced its Summer of Code for 2008:

	http://code.google.com/soc/2008/

I think this would be a great opportunity for DragonFly to participate
as a mentoring organisation.  We could attract new developers and could
get code/work done.  Looking at the SoC results of the other BSDs most
of their projects were a success.  Of course, not all, but a reasonable
percentage.  See [1] and [2].

It is some extra work for us, but IMO the benefits outweigh the extra
work.  And yes, I would volunteer as a mentor.  What do others
(developers) think?  Any more volunteers? :)

Some project ideas that come into my mind.  More ideas are listed in the
wiki:  http://wiki.dragonflybsd.org/index.cgi/ProjectsPage

 * Fix all remaining bugs in dma(8) and implement all missing features
 * Add a driver for newer Intel Wireless cards (I think sephe@ would
   love that :)
 * Bring our ACPI stuff in shape.  Maybe suspend2disk ...

 * [Add your own thoughts here]

Cheers,

	Matthias

PS: I don't want to create a bikeshed here whether you like the SoC or
not :)

[1] http://code.google.com/soc/2007/freebsd/about.html
[2] http://code.google.com/soc/2007/netbsd/about.html




From corecode at fs.ei.tum.de  Tue Mar  4 04:46:14 2008
From: corecode at fs.ei.tum.de (Simon 'corecode' Schubert)
Date: Tue, 4 Mar 2008 04:46:14 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47CD4386.1000704@fs.ei.tum.de>

Matthias Schmidt wrote:
>  * [Add your own thoughts here]

MP lock removal for network stack

and for the system  (first profile, find hot spots, fix hot spots, repeat)

cheers
  simon




From c.turner at 199technologies.org  Tue Mar  4 06:02:20 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Tue, 4 Mar 2008 06:02:20 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47CD551E.1040604@199technologies.org>

Matthias Schmidt wrote:
Some project ideas that come into my mind.  More ideas are listed in the
wiki:  http://wiki.dragonflybsd.org/index.cgi/ProjectsPage
+1 acpi
+1 interrupt routing
+1 SMP / giant removal
+1 pf synchup with openbsd
though there are several others on the page that are good..

need to dig up my wiki login and place appropriately..

also: thinking the ZFS port should be removed from the page - makes 
sense to everyone else? (e.g. fragments effort w/r/t hammer)





From tgen at netphreax.net  Tue Mar  4 06:54:31 2008
From: tgen at netphreax.net (Thomas E. Spanjaard)
Date: Tue, 4 Mar 2008 06:54:31 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47CD615F.8010209@netphreax.net>

Matthias Schmidt wrote:
Google just announced its Summer of Code for 2008:

 * [Add your own thoughts here]
x86-64 port :).
--
        Thomas E. Spanjaard
        tgen at netphreax.net
Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00001.pgp
Type: application/octet-stream
Size: 186 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080304/0d921000/attachment-0004.obj>

From rdivacky at FreeBSD.org  Tue Mar  4 07:07:03 2008
From: rdivacky at FreeBSD.org (Roman Divacky)
Date: Tue, 4 Mar 2008 07:07:03 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <20080304150255.GA8831@freebsd.org>

On Tue, Mar 04, 2008 at 02:49:03PM +0000, Thomas E. Spanjaard wrote:
> Matthias Schmidt wrote:
> >Google just announced its Summer of Code for 2008:
> >
> > * [Add your own thoughts here]
> 
> x86-64 port :).

all those ideas are great and needed etc. but keep in
mind that the projects should be doable by students
who might see dfly for the very first time.

don't overestimate whats possible and select projects
that look realistic

Roman Divacky (former SoC student)




From justin at shiningsilence.com  Tue Mar  4 08:32:56 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Tue, 4 Mar 2008 08:32:56 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <60322.65.106.147.226.1204648095.squirrel@www.shiningsilence.com>

On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
> Hi,
>
> Google just announced its Summer of Code for 2008:
>
> 	http://code.google.com/soc/2008/
>
> I think this would be a great opportunity for DragonFly to participate
> as a mentoring organisation.  We could attract new developers and could
> get code/work done.  Looking at the SoC results of the other BSDs most
> of their projects were a success.  Of course, not all, but a reasonable
> percentage.  See [1] and [2].

We've applied in previous years - Jeff Hsu did one year, and I put
together the application last year.  The hardest thing to find was
students (and they are the thing that helps SoC applications a lot, I
think).

Any student volunteers?  We have mentors.





From rluciani at gmail.com  Tue Mar  4 09:38:29 2008
From: rluciani at gmail.com (Robert Luciani)
Date: Tue, 04 Mar 2008 18:38:29 +0100
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47cd8915$0$854$415eb37d@crater_reader.dragonflybsd.org>

Justin C. Sherrill wrote:
> On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
>> Hi,
>>
>> Google just announced its Summer of Code for 2008:
>>
>> 	http://code.google.com/soc/2008/
>>
>> I think this would be a great opportunity for DragonFly to participate
>> as a mentoring organisation.  We could attract new developers and could
>> get code/work done.  Looking at the SoC results of the other BSDs most
>> of their projects were a success.  Of course, not all, but a reasonable
>> percentage.  See [1] and [2].
> 
> We've applied in previous years - Jeff Hsu did one year, and I put
> together the application last year.  The hardest thing to find was
> students (and they are the thing that helps SoC applications a lot, I
> think).
> 
> Any student volunteers?  We have mentors.
> 

bingo

-- 
Robert Luciani
Chalmers University of Technology, SWE
Department of Computer Science and Engineering
http://www.rluciani.com/public.key




From sdavtaker at gmail.com  Tue Mar  4 09:31:08 2008
From: sdavtaker at gmail.com (=?UTF-8?Q?Sd=C3=A4vtaker?=)
Date: Tue, 4 Mar 2008 09:31:08 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <c37d69f60803040926k206218a3kb8496d0cd18148bd@mail.gmail.com>

If you mentor, i will apply for coder :-)
Still in last year of university. :-)
Sdav

On Tue, Mar 4, 2008 at 1:28 PM, Justin C. Sherrill
<justin at shiningsilence.com> wrote:
> On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
>  > Hi,
>  >
>  > Google just announced its Summer of Code for 2008:
>  >
>  >       http://code.google.com/soc/2008/
>  >
>  > I think this would be a great opportunity for DragonFly to participate
>  > as a mentoring organisation.  We could attract new developers and could
>  > get code/work done.  Looking at the SoC results of the other BSDs most
>  > of their projects were a success.  Of course, not all, but a reasonable
>  > percentage.  See [1] and [2].
>
>  We've applied in previous years - Jeff Hsu did one year, and I put
>  together the application last year.  The hardest thing to find was
>  students (and they are the thing that helps SoC applications a lot, I
>  think).
>
>  Any student volunteers?  We have mentors.
>
>



-- 
Sd?vtaker prays to Rikku goddess for a good treasure.



From rluciani at gmail.com  Tue Mar  4 09:44:02 2008
From: rluciani at gmail.com (Robert Luciani)
Date: Tue, 04 Mar 2008 18:44:02 +0100
Subject: google soc "DragonFly"
Message-ID: <47cd8a63$0$855$415eb37d@crater_reader.dragonflybsd.org>

On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
> > Hi,
> >
> > Google just announced its Summer of Code for 2008:
> >
> > 	http://code.google.com/soc/2008/
> >
> > I think this would be a great opportunity for DragonFly to participate
> > as a mentoring organisation.  We could attract new developers and could
> > get code/work done.  Looking at the SoC results of the other BSDs most
> > of their projects were a success.  Of course, not all, but a reasonable
> > percentage.  See [1] and [2].

We've applied in previous years - Jeff Hsu did one year, and I put
together the application last year.  The hardest thing to find was
students (and they are the thing that helps SoC applications a lot, I
think).

Any student volunteers?  We have mentors.


-- 
Robert Luciani
Chalmers University of Technology, SWE
Department of Computer Science and Engineering
http://www.rluciani.com/public.key




From rluciani at gmail.com  Tue Mar  4 10:04:14 2008
From: rluciani at gmail.com (Robert Luciani)
Date: Tue, 04 Mar 2008 19:04:14 +0100
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47cd8f1f$0$856$415eb37d@crater_reader.dragonflybsd.org>

Robert Luciani wrote:
> Justin C. Sherrill wrote:
>> On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
>>> Hi,
>>>
>>> Google just announced its Summer of Code for 2008:
>>>
>>> 	http://code.google.com/soc/2008/
>>>
>>> I think this would be a great opportunity for DragonFly to participate
>>> as a mentoring organisation.  We could attract new developers and could
>>> get code/work done.  Looking at the SoC results of the other BSDs most
>>> of their projects were a success.  Of course, not all, but a reasonable
>>> percentage.  See [1] and [2].
>> We've applied in previous years - Jeff Hsu did one year, and I put
>> together the application last year.  The hardest thing to find was
>> students (and they are the thing that helps SoC applications a lot, I
>> think).
>>
>> Any student volunteers?  We have mentors.
>>
> 
> bingo
> 
My girlfriend Danwei noted that she would also like partake in the SoC.
She's studying IT here at Chalmers and will join the mailing list shortly.
-- 
Robert Luciani
Chalmers University of Technology, SWE
Department of Computer Science and Engineering
http://www.rluciani.com/public.key




From dillon at apollo.backplane.com  Tue Mar  4 13:08:30 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Tue, 4 Mar 2008 13:08:30 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Going to have to roll 1.12.1
Message-ID: <200803042104.m24L43g1065278@apollo.backplane.com>

    Due to a critical bug in sendmail that can cause it to seg-fault I will
    be rolling 1.12.1 as soon as I get verification that the current
    fix deals with it.

						-Matt





From sdavtaker at gmail.com  Tue Mar  4 17:40:43 2008
From: sdavtaker at gmail.com (=?UTF-8?B?U2TDpHZ0YWtlcg==?=)
Date: Tue, 4 Mar 2008 17:40:43 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: [Fwd: Project Support Open Source: $50 donation to support you  project]
In-Reply-To: <2468.192.168.0.242.1204346451.squirrel@www.shiningsilence.com>
Message-ID: <47CDF8D1.9070100@gmail.com>

50 bucks?
Come on...
You can get a meal a lot more expensive than that just going to a free 
HP conference about linux and you only have to rent your soul 3-5 hours ;-)
Sdav

Matthew Dillon escribi?:
:..
:source project's web page.  I'm putting those words in scare quotes
:because I think it's a "payment" for an "advertisement".  The supplied
:link has nothing to do with DragonFly, to say the least.
:
:I don't think this is a good idea, obviously, and replied to that effect. 
:However, I wanted to put this on a DragonFly list, in part to show this
:strange thing, and in part because I'm not comfortable making
:administrative decisions on behalf of the Project without being open as
:possible about it.

    It doesn't really cry out to me either.

						-Matt

  






From sdavtaker at gmail.com  Tue Mar  4 17:56:35 2008
From: sdavtaker at gmail.com (=?UTF-8?B?U2TDpHZ0YWtlcg==?=)
Date: Tue, 4 Mar 2008 17:56:35 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47CDFCCE.1010106@gmail.com>

A cute idea for for GSOC would be to finish the installer.
We were talking about this in my local BUG, we trying to find out how to 
help on that from here.
There is a few missing features in the CD.

   * FDISK, you need to create the slides from another OS before
     install DFBSD, i think port FDisk from FBSD or any *BSD will solve it.
   * Add to the make release a way to add some custom applications to
     the released liveCD (suppose you want to add nmap or ssh or
     something just to use as test disk in some enviroment).
   * Make the installer a little more customizable, and maybe w/ a GUI
     (I like a lot the console approach, but GUI installer will be a
     popularity move, DFBSD w/X makes a Desktop machine work, actually
     im using it that way and really like it).
I think those projects can be done in a SOC by students (like me) with a 
little guide.
Im a lot more interested in things network related and kernel, but i 
dont mind to work on those things, they need to be done some day.
What u think?
Sdav

Robert Luciani escribi?:
Robert Luciani wrote:
  
Justin C. Sherrill wrote:
    
On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
      
Hi,

Google just announced its Summer of Code for 2008:

	http://code.google.com/soc/2008/

I think this would be a great opportunity for DragonFly to participate
as a mentoring organisation.  We could attract new developers and could
get code/work done.  Looking at the SoC results of the other BSDs most
of their projects were a success.  Of course, not all, but a reasonable
percentage.  See [1] and [2].
        
We've applied in previous years - Jeff Hsu did one year, and I put
together the application last year.  The hardest thing to find was
students (and they are the thing that helps SoC applications a lot, I
think).
Any student volunteers?  We have mentors.

      
bingo

    
My girlfriend Danwei noted that she would also like partake in the SoC.
She's studying IT here at Chalmers and will join the mailing list shortly.
  






From c.turner at 199technologies.org  Tue Mar  4 18:30:53 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Tue, 4 Mar 2008 18:30:53 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47CE04C9.1010902@199technologies.org>

Justin C. Sherrill wrote:
together the application last year.  The hardest thing to find was
students (and they are the thing that helps SoC applications a lot, I
think).
umm.. if google wants to send me back to school, I'll sign up - hows 
that for a fair trade :?






From wbh at conducive.org  Tue Mar  4 23:52:13 2008
From: wbh at conducive.org (Bill Hacker)
Date: Wed, 05 Mar 2008 07:52:13 +0000
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47ce512e$0$855$415eb37d@crater_reader.dragonflybsd.org>

Sd?vtaker wrote:
A cute idea for for GSOC would be to finish the installer.
We were talking about this in my local BUG, we trying to find out how to 
help on that from here.
There is a few missing features in the CD.

   * FDISK, you need to create the slides from another OS before
     install DFBSD, i think port FDisk from FBSD or any *BSD will solve it.
I'd rather see that 'reversed' - i.e. - build a more capable fdisk in 
DFLY with hope that it might be seen worth importing into Free/Net/Open, 
or *at least* be able to do a more flexible job than those now do.

And disklabels as well. Hand in glove.

Here's why:

- At the moment, working with Free, Open, DFLY, and OpenSolaris on the 
same HDD requires a bit of acrobatics.

- There seems to now be greater divergence between/among the *BSD's as 
to being able to read each other's disklabels, mount and use each 
other's 'flavor' of FFS/UFS (not to mention Apple's implementation of 
UFS) than there is among the vast multitude of Linux ext2/3 denizens.

Even to the point where use of a *Linux* fs is the more universal way 
for being able to share mounts among the *BSD's. Think detached drives. 
And no - FAT is not all that practical for several reasons.

- DFLY currently has the most fine-grain ability to create slices and 
partitions. But the others cannot all (any?) read those.

'progress' w/r any of the *BSD's direction as to changes, improvements 
(or not) in their once-common-ancestry fs & disklabels need not be 
sacrificed.

I'm not holding out wish or hope for all players agreeing to return to 
'one sacred way'. Nor 'one new universal fs'. Neither is gonna happen.

But a 'legacy compatible' or least-common-denominator mode would do fine 
- most especially for portable / SAN devices.

So - how about a 'flexible' DFLY fdisk to go along with a 'flexible' 
disklabel that could adapt to whatever it found / was told to create?

JM2CW - but that *might* be a good place to get a cross-*BSD team together.

*snip* (other good stuff)

Bill Hacker




From matthias at dragonflybsd.org  Wed Mar  5 01:02:43 2008
From: matthias at dragonflybsd.org (Matthias Schmidt)
Date: Wed, 5 Mar 2008 01:02:43 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <20080305085747.GJ9833@staatsfeind.org>

Hi,

* Justin C. Sherrill wrote:
> 
> We've applied in previous years - Jeff Hsu did one year, and I put
> together the application last year.  The hardest thing to find was
> students (and they are the thing that helps SoC applications a lot, I
> think).

This is good to know, so we could coordinate that if we have enough
mentors and projects?!?  I put together a small text in the wiki:

http://wiki.dragonflybsd.org/index.cgi/GoogleSoC2008

Feel free to add project or missing stuff.  I'm sure I missed a lot of
things :)

> Any student volunteers?  We have mentors.

According to the discussion we could have some students, who would be a
mentor (besides me)?

Regards

	Matthias





From sdavtaker at gmail.com  Wed Mar  5 06:28:37 2008
From: sdavtaker at gmail.com (=?UTF-8?Q?Sd=C3=A4vtaker?=)
Date: Wed, 5 Mar 2008 06:28:37 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <c37d69f60803050624kd86d3d0w3b44a02d0e5a5391@mail.gmail.com>

<quote>
Write a driver (from scratch) for Intel 3945 wireless device
Mentor: Sepherosa Ziehau
</quote>

Yes yes yes, i want to :-)
Someone else planning to mentor in drivers coding?
Sdav

On Wed, Mar 5, 2008 at 5:57 AM, Matthias Schmidt
<matthias at dragonflybsd.org> wrote:
> Hi,
>
>
>  * Justin C. Sherrill wrote:
>  >
>  > We've applied in previous years - Jeff Hsu did one year, and I put
>  > together the application last year.  The hardest thing to find was
>  > students (and they are the thing that helps SoC applications a lot, I
>  > think).
>
>  This is good to know, so we could coordinate that if we have enough
>  mentors and projects?!?  I put together a small text in the wiki:
>
>  http://wiki.dragonflybsd.org/index.cgi/GoogleSoC2008
>
>  Feel free to add project or missing stuff.  I'm sure I missed a lot of
>  things :)
>
>
>  > Any student volunteers?  We have mentors.
>
>  According to the discussion we could have some students, who would be a
>  mentor (besides me)?
>
>  Regards
>
>         Matthias
>
>



-- 
Sd?vtaker prays to Rikku goddess for a good treasure.



From rluciani at gmail.com  Wed Mar  5 10:56:42 2008
From: rluciani at gmail.com (Robert Luciani)
Date: Wed, 05 Mar 2008 19:56:42 +0100
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47ceecea$0$847$415eb37d@crater_reader.dragonflybsd.org>

Sd?vtaker wrote:
> <quote>
> Write a driver (from scratch) for Intel 3945 wireless device
> Mentor: Sepherosa Ziehau
> </quote>
> 
> Yes yes yes, i want to :-)
> Someone else planning to mentor in drivers coding?
> Sdav
> 
> On Wed, Mar 5, 2008 at 5:57 AM, Matthias Schmidt
> <matthias at dragonflybsd.org> wrote:
>> Hi,
>>
>>
>>  * Justin C. Sherrill wrote:
>>  >
>>  > We've applied in previous years - Jeff Hsu did one year, and I put
>>  > together the application last year.  The hardest thing to find was
>>  > students (and they are the thing that helps SoC applications a lot, I
>>  > think).
>>
>>  This is good to know, so we could coordinate that if we have enough
>>  mentors and projects?!?  I put together a small text in the wiki:
>>
>>  http://wiki.dragonflybsd.org/index.cgi/GoogleSoC2008
>>
>>  Feel free to add project or missing stuff.  I'm sure I missed a lot of
>>  things :)
>>
>>
>>  > Any student volunteers?  We have mentors.
>>
>>  According to the discussion we could have some students, who would be a
>>  mentor (besides me)?
>>
>>  Regards
>>
>>         Matthias
>>
>>
> 
> 
>

IF someone starts to write a 3945 Intel driver,
please keep the newer 4965 in mind too.

-- 
Robert Luciani
Chalmers University of Technology, SWE
Department of Computer Science and Engineering
http://www.rluciani.com/public.key




From joerg at britannica.bec.de  Wed Mar  5 12:01:05 2008
From: joerg at britannica.bec.de (Joerg Sonnenberger)
Date: Wed, 5 Mar 2008 12:01:05 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <20080305195711.GA9981@britannica.bec.de>

On Wed, Mar 05, 2008 at 07:56:42PM +0100, Robert Luciani wrote:
> IF someone starts to write a 3945 Intel driver,
> please keep the newer 4965 in mind too.

NetBSD's wpi works quite well. The hardware is quite different from
4945.

Joerg




From sepherosa at gmail.com  Wed Mar  5 17:48:50 2008
From: sepherosa at gmail.com (Sepherosa Ziehau)
Date: Wed, 5 Mar 2008 17:48:50 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <ea7b9c170803051744u22b09484ofc994f034f11df3b@mail.gmail.com>

On Thu, Mar 6, 2008 at 2:56 AM, Robert Luciani <rluciani at gmail.com> wrote:
>  IF someone starts to write a 3945 Intel driver,

"IF" you know that trying to fix any wired bugs in certain drivers
(e.g. ipw, ral) will require you to read through all of the vendor's
linux code (yes, even including register values and position), i.e.
there is not much difference between writing one from scratch and
porting+fixing_bugs, then you probably will not put "IF" at the start
of your sentence.
If what I said sounded too harsh to you, then I was sorry.

>  please keep the newer 4965 in mind too.

Will do, once generic 11n support is brought in from freebsd.

Best Regards,
sephe

-- 
Live Free or Die




From saw at online.de  Thu Mar  6 05:34:14 2008
From: saw at online.de (Sascha Wildner)
Date: Thu, 06 Mar 2008 14:34:14 +0100
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
Message-ID: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>

Hi all,

this is probably as good a moment as any to come out of the forest with 
this. The patch at

http://leaf.dragonflybsd.org/~swildner/nrelease_gui.diff

adds some code to nrelease/ to build a LiveCD with xorg and so on 
(currently, only the xorg metapackages and fluxbox are added). In order 
to build one, you need a local dir with the pkgsrc binary packages (see 
below).

The following commands should then do the trick:

cd /usr/src
make buildworld
make buildkernel
cd nrelease
patch -p 0 </path/to/the/patch
make PKGSRC_PKG_PATH=/path/to/packages/dir/All realquick gui
The resulting ISO will be in /usr/release/dfly-gui.iso then. It will not 
boot into xorg automatically (although this is easily possible), so you 
need to login as root and do startx.

As of now, this all is kind of basic, more a proof of concept than 
anything else. As our release framework installs packages via chroot, 
the current setup just copies _all_ packages to the chroot before 
installing (kind of a hack).

That said, I'm now primarily interested in opinions/ideas/... about the 
direction this should take. Which packages would we like to see on the 
CD? Should it be a generic setup with the "most common things" 
installed, so a system can be quickly setup by the installer (which will 
cpdup /usr/pkg). Or should it be a more specialized set of tools? Or 
even as many packages as possible (Live DVD?). Etc., etc.

Before continuing on it, I'm really interested in people's input so 
don't hold anything back, please. :)

Sascha

--
http://yoyodyne.ath.cx



From rluciani at gmail.com  Thu Mar  6 06:42:03 2008
From: rluciani at gmail.com (Robert Luciani)
Date: Thu, 06 Mar 2008 15:42:03 +0100
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <47d002bc$0$847$415eb37d@crater_reader.dragonflybsd.org>

Sascha Wildner wrote:
> Hi all,
> 
> this is probably as good a moment as any to come out of the forest with
> this. The patch at
> 
> http://leaf.dragonflybsd.org/~swildner/nrelease_gui.diff
> 
> adds some code to nrelease/ to build a LiveCD with xorg and so on
> (currently, only the xorg metapackages and fluxbox are added). In order
> to build one, you need a local dir with the pkgsrc binary packages (see
> below).
> 
> The following commands should then do the trick:
> 
> cd /usr/src
> make buildworld
> make buildkernel
> cd nrelease
> patch -p 0 </path/to/the/patch
> make PKGSRC_PKG_PATH=/path/to/packages/dir/All realquick gui
> 
> The resulting ISO will be in /usr/release/dfly-gui.iso then. It will not
> boot into xorg automatically (although this is easily possible), so you
> need to login as root and do startx.
> 
> As of now, this all is kind of basic, more a proof of concept than
> anything else. As our release framework installs packages via chroot,
> the current setup just copies _all_ packages to the chroot before
> installing (kind of a hack).
> 
> That said, I'm now primarily interested in opinions/ideas/... about the
> direction this should take. Which packages would we like to see on the
> CD? Should it be a generic setup with the "most common things"
> installed, so a system can be quickly setup by the installer (which will
> cpdup /usr/pkg). Or should it be a more specialized set of tools? Or
> even as many packages as possible (Live DVD?). Etc., etc.
> 
> Before continuing on it, I'm really interested in people's input so
> don't hold anything back, please. :)
> 
> Sascha
> 

I think the main point of such a live-cd would be to test
dragonfly-specific features such as vkernels and more. Mplayer and
OpenOffic work the same on all platforms, so they might not be super
important, while irssi, firefox, networking tools, vim, a few more
shells/terminals might make it easier to for people to quickly gauge if
they can reproduce their current productivity and also what is new.

And if the point of a livecd is to test that kind of stuff, then it
would be nice for it to have a kernel that supports as much as possible
like ALTQ, and drivers.

Also if it has lots and lots of programs (thinking multimedia, java,
etc..) it might be hard to keep the future x64 and x86 live-cds on par.
Gentoo had this problem many years ago and it was very bothersome.

-- 
Robert Luciani
Chalmers University of Technology, SWE
Department of Computer Science and Engineering
http://www.rluciani.com/public.key




From matthias at dragonflybsd.org  Thu Mar  6 07:12:43 2008
From: matthias at dragonflybsd.org (Matthias Schmidt)
Date: Thu, 6 Mar 2008 07:12:43 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <20080306150757.GN9833@staatsfeind.org>

* Sascha Wildner wrote:
> Hi all,
> 
> this is probably as good a moment as any to come out of the forest with this. 
> The patch at
> 
> http://leaf.dragonflybsd.org/~swildner/nrelease_gui.diff
> 
> adds some code to nrelease/ to build a LiveCD with xorg and so on (currently, 
> only the xorg metapackages and fluxbox are added). In order to build one, you 
> need a local dir with the pkgsrc binary packages (see below).

Great work Sascha.

I agree with Robert on most of his stated points.
It would be nice to see some DragonFly specific features on the CD
(although I'm not sure if that will work for all features).  A little
environment where most Unix users feel at home (fluxbox, xfce, firefox,
thunderbird, gvim) should be enough.

Big applications like OO.org, java etc won't work because they are not
available as pkgsrc packages neither is it possible to compile them on
DragonFly.  At least to my knowledge.

Regards

	Matthias




From dillon at apollo.backplane.com  Thu Mar  6 09:31:52 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Thu, 6 Mar 2008 09:31:52 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <200803061728.m26HSR3O091809@apollo.backplane.com>


:Hi all,
:
:this is probably as good a moment as any to come out of the forest with 
:this. The patch at
:
:http://leaf.dragonflybsd.org/~swildner/nrelease_gui.diff
:
:adds some code to nrelease/ to build a LiveCD with xorg and so on 
:(currently, only the xorg metapackages and fluxbox are added). In order 
:to build one, you need a local dir with the pkgsrc binary packages (see 
:below).
:
:The following commands should then do the trick:

    It looks reasonable, though the package copy has to be tightened
    up a bit I think.

:...
:installed, so a system can be quickly setup by the installer (which will 
:cpdup /usr/pkg). Or should it be a more specialized set of tools? Or 
:even as many packages as possible (Live DVD?). Etc., etc.
:
:Before continuing on it, I'm really interested in people's input so 
:don't hold anything back, please. :)
:
:Sascha

    I think this is an excellent time to work up a DVD build and to
    add various 'flavor' extras.  So, e.g.:

	make installer gui gui_extras release dvd

    (All 'dvd' would do is generate a dvd compatible image for burning to
    dvd instead of cd).  I did a quick perusal of what I have on my
    workstation:

    * X
    * Firefox
    * Linux emulation
    * Open Office (linux version)
    * fvwm2
    * xpdf
    * freetype2

    I'd also suggest some image editing tools like gimp, and maybe the KDE
    gui suite.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From justin at shiningsilence.com  Thu Mar  6 09:42:44 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Thu, 6 Mar 2008 09:42:44 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <55427.65.106.147.226.1204825168.squirrel@www.shiningsilence.com>

On Thu, March 6, 2008 8:34 am, Sascha Wildner wrote:

> That said, I'm now primarily interested in opinions/ideas/... about the
> direction this should take. Which packages would we like to see on the
> CD? Should it be a generic setup with the "most common things"
> installed, so a system can be quickly setup by the installer (which will
> cpdup /usr/pkg). Or should it be a more specialized set of tools? Or
> even as many packages as possible (Live DVD?). Etc., etc.

What Robert said is good - whatever's needed to enable DragonFly-specific
features.  Along with that would be some sort of documentation (a README? 
A HTML file on whatever desktop we provide) that points people at the
different DragonFly tools, so they know what to try and how to try it.

There's going to be some percentage of people who try DragonFly who don't
know about vkernels, for instance, but there's our chance to educate them.
 I'm probably volunteering myself, aren't I?





From sdavtaker at gmail.com  Thu Mar  6 09:50:09 2008
From: sdavtaker at gmail.com (=?UTF-8?Q?Sd=C3=A4vtaker?=)
Date: Thu, 6 Mar 2008 09:50:09 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <c37d69f60803060947t110750c0sd6b542ea505d188d@mail.gmail.com>

Cool Sascha :-)
I just posted about this 1 or 2 days ago in the SOC project ideas thread.
Want to mentor this one? ;-)
Damian

On Thu, Mar 6, 2008 at 2:28 PM, Matthew Dillon
<dillon at apollo.backplane.com> wrote:
>
>  :Hi all,
>
> :
>  :this is probably as good a moment as any to come out of the forest with
>  :this. The patch at
>  :
>  :http://leaf.dragonflybsd.org/~swildner/nrelease_gui.diff
>  :
>  :adds some code to nrelease/ to build a LiveCD with xorg and so on
>  :(currently, only the xorg metapackages and fluxbox are added). In order
>  :to build one, you need a local dir with the pkgsrc binary packages (see
>  :below).
>  :
>  :The following commands should then do the trick:
>
>     It looks reasonable, though the package copy has to be tightened
>     up a bit I think.
>
>  :...
>  :installed, so a system can be quickly setup by the installer (which will
>
> :cpdup /usr/pkg). Or should it be a more specialized set of tools? Or
>  :even as many packages as possible (Live DVD?). Etc., etc.
>  :
>  :Before continuing on it, I'm really interested in people's input so
>  :don't hold anything back, please. :)
>  :
>  :Sascha
>
>     I think this is an excellent time to work up a DVD build and to
>     add various 'flavor' extras.  So, e.g.:
>
>         make installer gui gui_extras release dvd
>
>     (All 'dvd' would do is generate a dvd compatible image for burning to
>     dvd instead of cd).  I did a quick perusal of what I have on my
>     workstation:
>
>     * X
>     * Firefox
>     * Linux emulation
>     * Open Office (linux version)
>     * fvwm2
>     * xpdf
>     * freetype2
>
>     I'd also suggest some image editing tools like gimp, and maybe the KDE
>     gui suite.
>
>                                         -Matt
>                                         Matthew Dillon
>                                         <dillon at backplane.com>
>



-- 
Sd?vtaker prays to Rikku goddess for a good treasure.



From saw at online.de  Thu Mar  6 11:54:01 2008
From: saw at online.de (Sascha Wildner)
Date: Thu, 06 Mar 2008 20:54:01 +0100
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <47d04ba2$0$856$415eb37d@crater_reader.dragonflybsd.org>

Matthew Dillon wrote:
    It looks reasonable, though the package copy has to be tightened
    up a bit I think.
It looks as if it would work with mount_null'ing the chroot's 
/tmp/packages. I'll have a better patch ready tomorrow.

Sascha

--
http://yoyodyne.ath.cx



From c.turner at 199technologies.org  Thu Mar  6 19:11:44 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Thu, 6 Mar 2008 19:11:44 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Misc. ACPI / suspend
In-Reply-To: <47CA073B.6020106@199technologies.org>
Message-ID: <47D0B079.3060905@199technologies.org>

Chris Turner wrote:
Wondering if anyone more well versed in the ACPI implementation could
comment on the applicability of:
http://lkml.org/lkml/2007/4/6/69

Doing a little digging, it seems like

. /platform/pc32/i386/i686_mem.c

*might* have the necessary infrastructure to remap the MTRR's per the 
thread referenced,

but:

. /platform/pc32/acpica5/acpi_wakeup.c

doesn't seem to be using this infrastructure..

I'm no where near reaching an understanding of this yet,
but I'm wondering 3 things:
1) does anyone have ACPI (instead of APM)
   sleep / suspend / wakeup working on Dfly ?
2) If so, what machines are being used ?
3) Same question for other BSDs - my understanding is NetBSD is most
   'advanced' w/r/t power managment - but I'm not 100% on this ...
would looove to have a sleeping / resuming / scaling laptop running some 
BSD flavor.. am willing to work towards that end, esp. w/r/t Dfly -
trying to chart a course to figguring this out.

Thanks all,

- Chris




From c.turner at 199technologies.org  Thu Mar  6 19:12:33 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Thu, 6 Mar 2008 19:12:33 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: PCI Bios / Interrupt remapping / etc
Message-ID: <47D0B211.6000002@199technologies.org>

Doing a bit of digging here for my long-standing CBB+SIO interupt and 
buffer problem -

one machine I've tested against was an OpenBSD machine, which didn't
always work to handle the cardbus sio card on a PCI cardbus adapter
-

tuning up some of the device flags in:

http://www.openbsd.org/cgi-bin/man.cgi?query=pcibios&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=html

seems to have alleviated the problem for that os..

I'm just only starting to get up to speed on how DF handles these types 
of things (namely initial PIC / interrupt layout at boot time device 
enumeration), but am wondering if anyone familiar with this area of the 
code has any comments / advice w/r/t the capabilities of the DF bios 
drivers
and the various quirks / fixup mentioned in the link above..

looking to possibly investigate fixing up some of these issues over time.

Thanks

- Chris







From pavalos at theshell.com  Fri Mar  7 01:14:55 2008
From: pavalos at theshell.com (Peter Avalos)
Date: Fri, 7 Mar 2008 01:14:55 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: cam locking
Message-ID: <20080307091024.GC1652@ylem.theshell.com>

So I've been working on locking up cam using lockmgr locks, and here's
what I have so far:

http://www.theshell.com/~pavalos/wip/cam-lock.patch

Most of the work is obtained from FreeBSD.  I've only been running this
on my SCSI machine for a day, but because the patch is so large, I wanted
to make it available for people to review if they have some spare time.

Thanks,
Peter
Attachment:
pgp00002.pgp
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00002.pgp
Type: application/octet-stream
Size: 197 bytes
Desc: "Description: PGP signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080307/9a17ecd8/attachment-0004.obj>

From jspringe at uos.de  Fri Mar  7 03:25:17 2008
From: jspringe at uos.de (Jost Tobias Springenberg)
Date: Fri, 7 Mar 2008 12:25:17 +0100
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <20080307122517.72c9e2b1.jspringe@uos.de>

On Tue, 4 Mar 2008 11:28:15 -0500 (EST)
"Justin C. Sherrill" <justin at shiningsilence.com> wrote:

> On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
> > Hi,
> >
> > Google just announced its Summer of Code for 2008:
> >
> > 	http://code.google.com/soc/2008/
> >
> > I think this would be a great opportunity for DragonFly to participate
> > as a mentoring organisation.  We could attract new developers and could
> > get code/work done.  Looking at the SoC results of the other BSDs most
> > of their projects were a success.  Of course, not all, but a reasonable
> > percentage.  See [1] and [2].
> 
> We've applied in previous years - Jeff Hsu did one year, and I put
> together the application last year.  The hardest thing to find was
> students (and they are the thing that helps SoC applications a lot, I
> think).
> 
> Any student volunteers?  We have mentors.
> 

I read this mailing list for quite a while now and thought about contributing stuff
to DFfly several times, so yes why not take this opportunity if it's there.

-- 
Jost Tobias Springenberg <jspringe at uos.de>




From tgen at netphreax.net  Fri Mar  7 05:17:27 2008
From: tgen at netphreax.net (Thomas E. Spanjaard)
Date: Fri, 7 Mar 2008 05:17:27 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: PCI Bios / Interrupt remapping / etc
In-Reply-To: <47D0B211.6000002@199technologies.org>
Message-ID: <47D13FB4.5080306@netphreax.net>

Chris Turner wrote:
Doing a bit of digging here for my long-standing CBB+SIO interupt and 
buffer problem -

one machine I've tested against was an OpenBSD machine, which didn't
always work to handle the cardbus sio card on a PCI cardbus adapter
-

tuning up some of the device flags in:

http://www.openbsd.org/cgi-bin/man.cgi?query=pcibios&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=html 

seems to have alleviated the problem for that os..

I'm just only starting to get up to speed on how DF handles these types 
of things (namely initial PIC / interrupt layout at boot time device 
enumeration), but am wondering if anyone familiar with this area of the 
code has any comments / advice w/r/t the capabilities of the DF bios 
drivers
and the various quirks / fixup mentioned in the link above..

looking to possibly investigate fixing up some of these issues over time.
Our code that handles issues like this (in cases where you're not using 
APICs, just PICs and PIRs) lives in bus/pci/i386/. Not that running 
without APIC support is all that common on modern machines anymore...
--
        Thomas E. Spanjaard
        tgen at netphreax.net
Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00003.pgp
Type: application/octet-stream
Size: 186 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080307/61366b5c/attachment-0004.obj>

From tgen at netphreax.net  Fri Mar  7 05:16:51 2008
From: tgen at netphreax.net (Thomas E. Spanjaard)
Date: Fri, 7 Mar 2008 05:16:51 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Misc. ACPI / suspend
In-Reply-To: <47CA073B.6020106@199technologies.org>
Message-ID: <47D13F07.9080308@netphreax.net>

Chris Turner wrote:
1) does anyone have ACPI (instead of APM)
   sleep / suspend / wakeup working on Dfly ?
2) If so, what machines are being used ?
3) Same question for other BSDs - my understanding is NetBSD is most
   'advanced' w/r/t power managment - but I'm not 100% on this ...
would looove to have a sleeping / resuming / scaling laptop running some 
BSD flavor.. am willing to work towards that end, esp. w/r/t Dfly -
trying to chart a course to figguring this out.
I have ACPI S3 suspend working like a charm on my IBM ThinkPad R40 
(Pentium M "Banias" 1.3GHz, speedstepping works just fine), running 
NetBSD 3.99.21.
--
        Thomas E. Spanjaard
        tgen at netphreax.net
Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00004.pgp
Type: application/octet-stream
Size: 186 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080307/de3e5104/attachment-0004.obj>

From civilizd at gmail.com  Fri Mar  7 09:06:41 2008
From: civilizd at gmail.com (Vita "CiV" Cizek)
Date: Fri, 7 Mar 2008 09:06:41 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <98d564710803070853q1c73d795m6e6c5cc5049fa099@mail.gmail.com>

>  Any student volunteers?  We have mentors.
>
I am interested too, especially in some kernel-related work.




From justin at shiningsilence.com  Sat Mar  8 12:07:51 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Sat, 8 Mar 2008 12:07:51 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google SoC 2008 - mentors mentors mentors
Message-ID: <51558.192.168.0.252.1205006403.squirrel@www.shiningsilence.com>

If you are willing to mentor for the Google 2008 Summer of Code, please
speak up.  Right now we have: (from our wiki page)

Matthias
Sephe
TGEN
corecode

Part of the application process includes naming people as mentors (student
applications come later), so I want to get as complete a list as possible.

The application is due on the 12th, so if you want to mentor, now's the
time to say so.

Google's SoC FAQ is here: http://code.google.com/soc/2008/faqs.html

Our wiki page is here: http://wiki.dragonflybsd.org/index.cgi/GoogleSoC2008

- much credit to Matthias and others for getting that set up.





From saw at online.de  Sat Mar  8 14:26:07 2008
From: saw at online.de (Sascha Wildner)
Date: Sat, 08 Mar 2008 23:26:07 +0100
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <47d31245$0$848$415eb37d@crater_reader.dragonflybsd.org>

Sascha Wildner wrote:
Hi all,

this is probably as good a moment as any to come out of the forest with 
this. The patch at

http://leaf.dragonflybsd.org/~swildner/nrelease_gui.diff
Ok, I have committed the stuff as an example.

I'm not sure if my free time permits to work on a full-blown live CD 
with X11 and other good things (I already feel my interest wandering off 
in other directions) so if anyone wants to pick up the ball, go ahead. :)

Sascha

--
http://yoyodyne.ath.cx



From qhwt+dfly at les.ath.cx  Tue Mar 11 22:21:31 2008
From: qhwt+dfly at les.ath.cx (YONETANI Tomokazu)
Date: Tue, 11 Mar 2008 22:21:31 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Misc. ACPI / suspend
In-Reply-To: <47CA073B.6020106@199technologies.org>
Message-ID: <20080312051219.GA56091@les.ath.cx>

On Thu, Mar 06, 2008 at 10:03:21PM -0500, Chris Turner wrote:
> 1) does anyone have ACPI (instead of APM)
>    sleep / suspend / wakeup working on Dfly ?
> 2) If so, what machines are being used ?

Dynabook SS3500 (http://www.tlt.co.jp/pc/catalog/ss/02110735/index_j.htm).
It's old and can get very hot(thus frequently turns on the cooling fan)
even when it's running Windows.  I haven't turned it on for about several
months though.

Cheers.




From c.turner at 199technologies.org  Wed Mar 12 04:37:22 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Wed, 12 Mar 2008 04:37:22 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Misc. ACPI / suspend
In-Reply-To: <47CA073B.6020106@199technologies.org>
Message-ID: <47D7BEE3.6010907@199technologies.org>

YONETANI Tomokazu wrote:
On Thu, Mar 06, 2008 at 10:03:21PM -0500, Chris Turner wrote:
1) does anyone have ACPI (instead of APM)
   sleep / suspend / wakeup working on Dfly ?
Cheers.
ditto..

Suppose this should go to docs@ - in any case..

Thinking about setting up a wiki page on the issue so we
can discuss / track what 'good' hardware / drivers / implementations / 
etc are 'out there' - anyone have any suggestions on where this should
go?

http://wiki.dragonflybsd.org/index.cgi/acpi-overview.html

Remains from the handbook conversion - but I'm hesitant to 'over wikify'
this ..



From c.turner at 199technologies.org  Wed Mar 12 15:36:52 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Wed, 12 Mar 2008 15:36:52 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: devel/cscope
Message-ID: <47D85A08.8040103@199technologies.org>

why oh why did I take so long to try this out !!!

just sharing my eureka moment with the list..

- Chris




From dudu at dudu.ro  Wed Mar 12 15:50:14 2008
From: dudu at dudu.ro (Vlad GALU)
Date: Wed, 12 Mar 2008 15:50:14 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: devel/cscope
In-Reply-To: <47D85A08.8040103@199technologies.org>
Message-ID: <ad79ad6b0803121547r2bf67ffep9e40badaac6490f8@mail.gmail.com>

On 3/13/08, Chris Turner <c.turner at 199technologies.org> wrote:
> why oh why did I take so long to try this out !!!
>
>  just sharing my eureka moment with the list..


    Works nice with vim, too!

>
>
>  - Chris
>


-- 
Mahnahmahnah!




From justin at shiningsilence.com  Sun Mar 16 21:06:13 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Sun, 16 Mar 2008 21:06:13 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: binary packages for 1.12 coming in
Message-ID: <1372.192.168.0.252.1205726088.squirrel@www.shiningsilence.com>

The binary build for 1.12 is taking quite a while.  I've started copying
in newly built packages to
pkgbox.dragonflybsd.org/packages/DragonFly-1.12/i386/ - this should be
getting copied out to mirrors over the next while.

There are currently 1283 packages built, which leaves a whole lot to go;
I'll copy new packages in as they complete.





From hasso at estpak.ee  Wed Mar 19 04:31:08 2008
From: hasso at estpak.ee (Hasso Tepper)
Date: Wed, 19 Mar 2008 04:31:08 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Some questions regarding ACPI
Message-ID: <200803191322.46366.hasso@estpak.ee>

I'm working on bringing in some laptop (and especially thinkpad) specific 
ACPI code from FreeBSD into DragonFly. I never touched ACPI stuff before 
and haven't followed it much either, so I have some questions.

* FreeBSD uses ACPI_SERIAL_* heavily. What's the locking situation in 
  DragonFly and why?

* As far as I can see, PCI integration is commented out in DragonFly. 
  What's the state of it and why?

* platform/pc32/acpica5/acpi_toshiba.c - why is it there? I don't think 
  that this is something pc32 specific in it and it should work in pc64 
  laptops as well. Any objections to move it into 
  dev/acpica5/acpi_toshiba/ ?

What's the current status of ACPI in general? AFAICS our acpica is quite 
old - what needs to be done to bring in newer one?


-- 
Hasso




From qhwt+dfly at les.ath.cx  Wed Mar 19 09:24:50 2008
From: qhwt+dfly at les.ath.cx (YONETANI Tomokazu)
Date: Wed, 19 Mar 2008 09:24:50 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Some questions regarding ACPI
In-Reply-To: <200803191322.46366.hasso@estpak.ee>
Message-ID: <20080319161703.GA51509@les.ath.cx>

On Wed, Mar 19, 2008 at 01:22:46PM +0200, Hasso Tepper wrote:
> I'm working on bringing in some laptop (and especially thinkpad) specific 
> ACPI code from FreeBSD into DragonFly. I never touched ACPI stuff before 
> and haven't followed it much either, so I have some questions.

So you want to port some of ACPI support drivers, or to do a fresh port
of ACPI driver from FreeBSD?

> * FreeBSD uses ACPI_SERIAL_* heavily. What's the locking situation in 
>   DragonFly and why?

The current ACPI driver in DragonFly is based on that of FreeBSD as of
end of June, 2004, plus some fixes brought in later (and ACPICA part
has been updated twice since then).  That was before they introduced
the MPSAFE changes into ACPI code, and we use critical section
(crit_{enter,exit}) in most places (and lockmgr lock in a few place).

> * As far as I can see, PCI integration is commented out in DragonFly. 
>   What's the state of it and why?

When we replaced the implementation taken from FreeBSD 4.x with that
brought from FreeBSD 5.x, which added the PCI part, many people
experienced problems until they turned off ACPI completely, or add "pci"
to "debug.acpi.disabled" loader variable.  AFAIK the PCI part in the ACPI
driver almost hasn't been adjusted to work with our version of PCI code.

> * platform/pc32/acpica5/acpi_toshiba.c - why is it there? I don't think 
>   that this is something pc32 specific in it and it should work in pc64 
>   laptops as well. Any objections to move it into 
>   dev/acpica5/acpi_toshiba/ ?

In FreeBSD it used to be sitting at i386/acpica/acpi_toshiba.c and was
later moved into acpi_support.  That change hasn't hit our tree (in fact,
we have no acpi support drivers other than that).  It seems that FreeBSD
has them in dev/acpi_support now, and we for some reason have that
directory in our CVS repository (but containing no files in it).

> What's the current status of ACPI in general? AFAICS our acpica is quite 
> old - what needs to be done to bring in newer one?

Actually, it's not very important to keep just ACPICA latest, but
if you bring the ACPI driver from FreeBSD you need to bring ACPICA code
that matches their version, and it IS important.  And it generally requires
you much work to just update ACPICA part anyway because of how they
change things on every release.

Cheers.




From hasso at estpak.ee  Wed Mar 19 12:29:52 2008
From: hasso at estpak.ee (Hasso Tepper)
Date: Wed, 19 Mar 2008 12:29:52 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Some questions regarding ACPI
In-Reply-To: <200803191322.46366.hasso@estpak.ee>
Message-ID: <200803192115.35396.hasso@estpak.ee>

YONETANI Tomokazu wrote:
> On Wed, Mar 19, 2008 at 01:22:46PM +0200, Hasso Tepper wrote:
> > I'm working on bringing in some laptop (and especially thinkpad)
> > specific ACPI code from FreeBSD into DragonFly. I never touched ACPI
> > stuff before and haven't followed it much either, so I have some
> > questions.
>
> So you want to port some of ACPI support drivers, or to do a fresh port
> of ACPI driver from FreeBSD?

I'm only interested in support drivers and the reason is pure practical - 
newer thinkpads handle less and less hotkeys etc in hardware and require 
support form OS. acpi_ibm and acpi_video are examples of such modules 
which would help a lot of these newer thinkpad users.

acpi_ibm is almost ready to commit (renamed to acpi_thinkpad though).

> > * FreeBSD uses ACPI_SERIAL_* heavily. What's the locking situation in
> >   DragonFly and why?
>
> The current ACPI driver in DragonFly is based on that of FreeBSD as of
> end of June, 2004, plus some fixes brought in later (and ACPICA part
> has been updated twice since then).  That was before they introduced
> the MPSAFE changes into ACPI code, and we use critical section
> (crit_{enter,exit}) in most places (and lockmgr lock in a few place).

Mkay. Will look at more closely.

> > * As far as I can see, PCI integration is commented out in DragonFly.
> >   What's the state of it and why?
>
> When we replaced the implementation taken from FreeBSD 4.x with that
> brought from FreeBSD 5.x, which added the PCI part, many people
> experienced problems until they turned off ACPI completely, or add
> "pci" to "debug.acpi.disabled" loader variable.  AFAIK the PCI part in
> the ACPI driver almost hasn't been adjusted to work with our version of
> PCI code.

I'm afraid that it's beyond my skills, but while looking at acpi_video I 
discovered that it's hard to handle correctly without PCI support.

> > * platform/pc32/acpica5/acpi_toshiba.c - why is it there? I don't
> > think that this is something pc32 specific in it and it should work
> > in pc64 laptops as well. Any objections to move it into
> >   dev/acpica5/acpi_toshiba/ ?
>
> In FreeBSD it used to be sitting at i386/acpica/acpi_toshiba.c and was
> later moved into acpi_support.  That change hasn't hit our tree (in
> fact, we have no acpi support drivers other than that).  It seems that
> FreeBSD has them in dev/acpi_support now, and we for some reason have
> that directory in our CVS repository (but containing no files in it).

I don't see it ;). Makes sense though. So, any objections if I move 
acpi_toshiba into sys/dev/acpi_support and add new acpi_thinkpad there as 
well? 

> > What's the current status of ACPI in general? AFAICS our acpica is
> > quite old - what needs to be done to bring in newer one?
>
> Actually, it's not very important to keep just ACPICA latest, but
> if you bring the ACPI driver from FreeBSD you need to bring ACPICA code
> that matches their version, and it IS important.  And it generally
> requires you much work to just update ACPICA part anyway because of how
> they change things on every release.

Someone else has to do it :).

Thanks for info.


-- 
Hasso




From dillon at apollo.backplane.com  Wed Mar 19 14:01:13 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Wed, 19 Mar 2008 14:01:13 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: panic: assertion: hammer_btree_cmp(cursor->left_bound,	&cursor->node->ondisk->elms[0].leaf.base) <= 0 in btree_split_leaf
In-Reply-To: <200802232204.m1NM4cxd046264@apollo.backplane.com>
Message-ID: <200803192054.m2JKsjwn045137@apollo.backplane.com>


:Hi.
:While trying to find a procedure to reliably reproduce the panic
:I reported last time, I caught a different panic (uploaded at
: ~y0netan1/crash/9/ on my leaf account).  I wrote the following shell
:script (make sure to edit variables DISKS and MOUNTPT before using this
:script or it may trash your system):
:  #!/bin/sh -ex
:  DISKS="/dev/ad0s1f"
:  MOUNTPT=/mnt/HAMMER
:
:  cd /
:  newfs_hammer -L TEST $DISKS
:  for i in `seq 1 100`; do
:..
:And the panic is triggered by rm command.
:I'll try to see if it's possible to reproduce the last one without
:unmounting then mounting the HAMMER fs.
:
:Cheers.

    I believe I have fixed this panic.  hammer_make_separator() had a bug
    in it.

    There is still an issue with the node ref count on umount.

    Please continue to life-test the code.  The reblocking code
    (hammer reblock /mnt) should work now, as should the pruning code
    (e.g. hammer prune /mnt everything).

    The filesystem full case is still not handled and will cause bad things
    to happen.  The undo code isn't finished yet either but it is getting
    there (it's writing stuff out but not setting the sequence number and
    not trying to recover-on-mount yet).

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From qhwt+dfly at les.ath.cx  Wed Mar 19 19:45:40 2008
From: qhwt+dfly at les.ath.cx (YONETANI Tomokazu)
Date: Wed, 19 Mar 2008 19:45:40 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Some questions regarding ACPI
In-Reply-To: <200803191322.46366.hasso@estpak.ee>
Message-ID: <20080320023828.GA53648@les.ath.cx>

On Wed, Mar 19, 2008 at 09:15:35PM +0200, Hasso Tepper wrote:
> YONETANI Tomokazu wrote:
> > On Wed, Mar 19, 2008 at 01:22:46PM +0200, Hasso Tepper wrote:
> > > I'm working on bringing in some laptop (and especially thinkpad)
> > > specific ACPI code from FreeBSD into DragonFly. I never touched ACPI
> > > stuff before and haven't followed it much either, so I have some
> > > questions.
> >
> > So you want to port some of ACPI support drivers, or to do a fresh port
> > of ACPI driver from FreeBSD?
> 
> I'm only interested in support drivers and the reason is pure practical - 
> newer thinkpads handle less and less hotkeys etc in hardware and require 
> support form OS. acpi_ibm and acpi_video are examples of such modules 
> which would help a lot of these newer thinkpad users.
> 
> acpi_ibm is almost ready to commit (renamed to acpi_thinkpad though).

Ah, that's a good news!  My only concern is that ISTR someone mentioned
me that his colleague was thinking about porting ACPI driver itself,
so if you're not the person you may want to collaborate with him/her
so as not to waste the effort or time...

			:

> > In FreeBSD it used to be sitting at i386/acpica/acpi_toshiba.c and was
> > later moved into acpi_support.  That change hasn't hit our tree (in
> > fact, we have no acpi support drivers other than that).  It seems that
> > FreeBSD has them in dev/acpi_support now, and we for some reason have
> > that directory in our CVS repository (but containing no files in it).
> 
> I don't see it ;). Makes sense though. So, any objections if I move 
> acpi_toshiba into sys/dev/acpi_support and add new acpi_thinkpad there as 
> well? 

Sorry, I checked the CVS repository and it doesn't exist actually :)
I don't have any objection to moving it there.

Cheers.




From hasso at estpak.ee  Thu Mar 20 00:14:05 2008
From: hasso at estpak.ee (Hasso Tepper)
Date: Thu, 20 Mar 2008 00:14:05 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Some questions regarding ACPI
In-Reply-To: <200803191322.46366.hasso@estpak.ee>
Message-ID: <200803200904.50875.hasso@estpak.ee>

YONETANI Tomokazu wrote:
> On Wed, Mar 19, 2008 at 09:15:35PM +0200, Hasso Tepper wrote:
> > acpi_ibm is almost ready to commit (renamed to acpi_thinkpad though).
>
> Ah, that's a good news!  My only concern is that ISTR someone mentioned
> me that his colleague was thinking about porting ACPI driver itself,
> so if you're not the person you may want to collaborate with him/her
> so as not to waste the effort or time...

Current state in my repo is attached. It should work on 1.12 as well as it 
doesn't depend yet on moving stuff around.

add-acpi-if-m.patch adds some new stuff to the ACPI code to access 
embedded controllers and match ACPI devices by ID. Not sure how, where 
and whether at all these should be documented.

add-acpi-thinkpad.patch is the driver itself. Note that some stuff doesn't 
work yet on newer thinkpads, I plan to work on it later.

There is still some things to do though. I have to decide what to do with 
led(4) part and with locking. There is also one fatal issue - laptop 
locks up hardly (no panic) while unloading module. Any idea regarding 
this is welcome. And of course test results :).


-- 
Hasso
# HG changeset patch
# User Hasso Tepper <hasso at estpak.ee>
# Date 1205919290 -7200
# Branch HEAD
# Node ID 5a6e2705cc95a340abf973ae5df73ef34e070b79
# Parent  cd529e2e7f849034d5d5a0973cb98af50db0e797
imported patch adding-acpi-if-m.patch

diff --git a/sys/conf/files b/sys/conf/files
--- a/sys/conf/files
+++ b/sys/conf/files
@@ -1387,6 +1387,7 @@ emulation/dragonfly12/dfbsd12_stat.c	non
 ${OSACPI_MI_DIR}/acpi_cmbat.c		optional acpi
 ${OSACPI_MI_DIR}/acpi_cpu.c		optional acpi
 ${OSACPI_MI_DIR}/acpi_ec.c		optional acpi
+${OSACPI_MI_DIR}/acpi_if.m		optional acpi
 ${OSACPI_MI_DIR}/acpi_isab.c		optional acpi isa
 ${OSACPI_MI_DIR}/acpi_lid.c		optional acpi
 ${OSACPI_MI_DIR}/acpi_package.c		optional acpi
diff --git a/sys/conf/kmod.mk b/sys/conf/kmod.mk
--- a/sys/conf/kmod.mk
+++ b/sys/conf/kmod.mk
@@ -275,7 +275,7 @@ MFILES?= kern/bus_if.m kern/device_if.m 
     bus/pccard/card_if.m bus/pccard/power_if.m bus/pci/pci_if.m \
     bus/pci/pcib_if.m \
     bus/ppbus/ppbus_if.m bus/smbus/smbus_if.m bus/usb/usb_if.m \
-    dev/disk/nata/ata_if.m \
+    dev/acpica5/acpi_if.m dev/disk/nata/ata_if.m \
     dev/sound/pcm/ac97_if.m dev/sound/pcm/channel_if.m \
     dev/sound/pcm/feeder_if.m dev/sound/pcm/mixer_if.m \
     libiconv/iconv_converter_if.m dev/agp/agp_if.m opencrypto/crypto_if.m
diff --git a/sys/dev/acpica5/Makefile b/sys/dev/acpica5/Makefile
--- a/sys/dev/acpica5/Makefile
+++ b/sys/dev/acpica5/Makefile
@@ -69,12 +69,14 @@ SRCS+=  acpi_package.c
 # SRCS+=	acpi_pci.c acpi_pcib.c acpi_pcib_acpi.c acpi_pcib_pci.c
 # SRCS+=	acpi_pci_link.c
 SRCS+=  acpi_powerres.c acpi_resource.c acpi_thermal.c
-SRCS+=  acpi_timer.c
+SRCS+=  acpi_timer.c acpi_if.c
 SRCS+=  OsdDebug.c
 SRCS+=  OsdHardware.c OsdInterface.c OsdInterrupt.c OsdMemory.c OsdSchedule.c
 SRCS+=  OsdStream.c OsdSynch.c OsdTable.c OsdEnvironment.c
 SRCS+=  opt_acpi.h opt_bus.h opt_ddb.h
-SRCS+=  device_if.h bus_if.h pci_if.h pcib_if.h isa_if.h
+SRCS+=  device_if.h bus_if.h pci_if.h pcib_if.h isa_if.h acpi_if.h
+MFILES = kern/device_if.m kern/bus_if.m bus/pci/pci_if.m bus/pci/pcib_if.m
+MFILES+= bus/isa/isa_if.m dev/acpica5/acpi_if.m
 
 # Debugging support
 DBSRC=	dbcmds.c dbdisply.c dbexec.c dbfileio.c dbhistry.c
diff --git a/sys/dev/acpica5/acpi.c b/sys/dev/acpica5/acpi.c
--- a/sys/dev/acpica5/acpi.c
+++ b/sys/dev/acpica5/acpi.c
@@ -135,6 +135,7 @@ static int	acpi_release_resource(device_
 			int rid, struct resource *r);
 static uint32_t	acpi_isa_get_logicalid(device_t dev);
 static int	acpi_isa_get_compatid(device_t dev, uint32_t *cids, int count);
+static char	*acpi_device_id_probe(device_t bus, device_t dev, char **ids);
 static int	acpi_isa_pnp_probe(device_t bus, device_t child,
 			struct isa_pnp_id *ids);
 static void	acpi_probe_children(device_t bus);
@@ -189,6 +190,9 @@ static device_method_t acpi_methods[] = 
     DEVMETHOD(bus_deactivate_resource,	bus_generic_deactivate_resource),
     DEVMETHOD(bus_setup_intr,		bus_generic_setup_intr),
     DEVMETHOD(bus_teardown_intr,	bus_generic_teardown_intr),
+
+    /* ACPI bus */
+    DEVMETHOD(acpi_id_probe,		acpi_device_id_probe),
 
     /* ISA emulation */
     DEVMETHOD(isa_pnp_probe,		acpi_isa_pnp_probe),
@@ -1121,6 +1125,24 @@ out:
 	AcpiOsFree(buf.Pointer);
     ACPI_UNLOCK;
     return_VALUE (valid);
+}
+
+static char *
+acpi_device_id_probe(device_t bus, device_t dev, char **ids) 
+{
+    ACPI_HANDLE h;
+    int i;
+
+    h = acpi_get_handle(dev);
+    if (ids == NULL || h == NULL || acpi_get_type(dev) != ACPI_TYPE_DEVICE)
+	return (NULL);
+
+    /* Try to match one of the array of IDs with a HID or CID. */
+    for (i = 0; ids[i] != NULL; i++) {
+	if (acpi_MatchHid(h, ids[i]))
+	    return (ids[i]);
+    }
+    return (NULL);
 }
 
 static int
diff --git a/sys/dev/acpica5/acpi_ec.c b/sys/dev/acpica5/acpi_ec.c
--- a/sys/dev/acpica5/acpi_ec.c
+++ b/sys/dev/acpica5/acpi_ec.c
@@ -327,11 +327,19 @@ static ACPI_STATUS	EcWrite(struct acpi_e
 				UINT8 *Data);
 static int		acpi_ec_probe(device_t dev);
 static int		acpi_ec_attach(device_t dev);
+static int		acpi_ec_read_method(device_t dev, u_int addr,
+				ACPI_INTEGER *val, int width);
+static int		acpi_ec_write_method(device_t dev, u_int addr,
+				ACPI_INTEGER val, int width);
 
 static device_method_t acpi_ec_methods[] = {
     /* Device interface */
     DEVMETHOD(device_probe,	acpi_ec_probe),
     DEVMETHOD(device_attach,	acpi_ec_attach),
+
+    /* Embedded controller interface */
+    DEVMETHOD(acpi_ec_read,     acpi_ec_read_method),
+    DEVMETHOD(acpi_ec_write,    acpi_ec_write_method),
 
     {0, 0}
 };
@@ -620,6 +628,33 @@ error:
 			     sc->ec_data_res);
     /* mtx_destroy(&sc->ec_mtx); */
     return (ENXIO);
+}
+
+/* Methods to allow other devices (e.g., smbat) to read/write EC space. */
+static int
+acpi_ec_read_method(device_t dev, u_int addr, ACPI_INTEGER *val, int width)
+{
+    struct acpi_ec_softc *sc;
+    ACPI_STATUS status;
+
+    sc = device_get_softc(dev);
+    status = EcSpaceHandler(ACPI_READ, addr, width * 8, val, sc, NULL);
+    if (ACPI_FAILURE(status))
+        return (ENXIO);
+    return (0);
+}
+
+static int
+acpi_ec_write_method(device_t dev, u_int addr, ACPI_INTEGER val, int width)
+{
+    struct acpi_ec_softc *sc;
+    ACPI_STATUS status;
+
+    sc = device_get_softc(dev);
+    status = EcSpaceHandler(ACPI_WRITE, addr, width * 8, &val, sc, NULL);
+    if (ACPI_FAILURE(status))
+        return (ENXIO);
+    return (0);
 }
 
 static void
diff --git a/sys/dev/acpica5/acpi_if.m b/sys/dev/acpica5/acpi_if.m
new file mode 100644
--- /dev/null
+++ b/sys/dev/acpica5/acpi_if.m
@@ -0,0 +1,92 @@
+#-
+# Copyright (c) 2004 Nate Lawson
+# All rights reserved.
+#
+# Redistribution and use in source and binary forms, with or without
+# modification, are permitted provided that the following conditions
+# are met:
+# 1. Redistributions of source code must retain the above copyright
+#    notice, this list of conditions and the following disclaimer.
+# 2. Redistributions in binary form must reproduce the above copyright
+#    notice, this list of conditions and the following disclaimer in the
+#    documentation and/or other materials provided with the distribution.
+#
+# THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
+# ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+# ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
+# FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+# DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+# OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+# HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+# LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+# OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+# SUCH DAMAGE.
+#
+# $DragonFly$
+#
+
+#include <sys/bus.h>
+#include <sys/types.h>
+#include "acpi.h"
+
+INTERFACE acpi;
+
+#
+# Default implementation for acpi_id_probe().
+#
+CODE {
+	static char *
+	acpi_generic_id_probe(device_t bus, device_t dev, char **ids)
+	{
+		return (NULL);
+	}
+};
+
+#
+# Check a device for a match in a list of ID strings.  The strings can be
+# EISA PNP IDs or ACPI _HID/_CID values.
+#
+# device_t bus:  parent bus for the device
+#
+# device_t dev:  device being considered
+#
+# char **ids:  array of ID strings to consider
+#
+# Returns:  ID string matched or NULL if no match
+#
+METHOD char * id_probe {
+	device_t	bus;
+	device_t	dev;
+	char		**ids;
+} DEFAULT acpi_generic_id_probe;
+
+#
+# Read embedded controller (EC) address space
+#
+# device_t dev:  EC device
+# u_int addr:  Address to read from in EC space
+# ACPI_INTEGER *val:  Location to store read value
+# int width:  Size of area to read in bytes
+#
+METHOD int ec_read {
+	device_t	dev;
+	u_int		addr;
+	ACPI_INTEGER	*val;
+	int		width;
+};
+
+#
+# Write embedded controller (EC) address space
+#
+# device_t dev:  EC device
+# u_int addr:  Address to write to in EC space
+# ACPI_INTEGER val:  Value to write
+# int width:  Size of value to write in bytes
+#
+METHOD int ec_write {
+	device_t	dev;
+	u_int		addr;
+	ACPI_INTEGER	val;
+	int		width;
+};
diff --git a/sys/dev/acpica5/acpivar.h b/sys/dev/acpica5/acpivar.h
--- a/sys/dev/acpica5/acpivar.h
+++ b/sys/dev/acpica5/acpivar.h
@@ -29,6 +29,7 @@
  * $DragonFly: src/sys/dev/acpica5/acpivar.h,v 1.12 2007/10/23 03:04:48 y0netan1 Exp $
  */
 
+#include "acpi_if.h"
 #include "bus_if.h"
 #include <sys/eventhandler.h>
 #include <sys/sysctl.h>
# HG changeset patch
# User Hasso Tepper <hasso at estpak.ee>
# Date 1205995474 -7200
# Branch HEAD
# Node ID c5db8d4a7c6b25a8576a8d42c5029aaf0e23bfb6
# Parent  5a6e2705cc95a340abf973ae5df73ef34e070b79
[mq]: adding-acpi-thinkpad.patch

diff --git a/sys/dev/acpica5/Makefile b/sys/dev/acpica5/Makefile
--- a/sys/dev/acpica5/Makefile
+++ b/sys/dev/acpica5/Makefile
@@ -117,7 +117,7 @@ acpi_wakecode.h: acpi_wakecode.S
 	${MAKE} -f ${SYSDIR}/${OSACPI_MD_DIR}/Makefile \
 		MAKESRCPATH=${SYSDIR}/${OSACPI_MD_DIR}
 
-SUBDIR=	acpi_toshiba
+SUBDIR=	acpi_toshiba acpi_thinkpad
 all: ${PROG} ${SUBDIR}
 
 # *.o file for each patched *.c file is created under the same directory,
diff --git a/sys/dev/acpica5/acpi_thinkpad/Makefile b/sys/dev/acpica5/acpi_thinkpad/Makefile
new file mode 100644
--- /dev/null
+++ b/sys/dev/acpica5/acpi_thinkpad/Makefile
@@ -0,0 +1,9 @@
+# $DragonFly$
+
+SYSDIR?=${.CURDIR}/../../..
+
+KMOD=		acpi_thinkpad
+CFLAGS+=	-I${.OBJDIR}/.. -I${.CURDIR}/..
+SRCS=		acpi_thinkpad.c opt_acpi.h device_if.h bus_if.h
+
+.include <bsd.kmod.mk>
diff --git a/sys/dev/acpica5/acpi_thinkpad/acpi_thinkpad.c b/sys/dev/acpica5/acpi_thinkpad/acpi_thinkpad.c
new file mode 100644
--- /dev/null
+++ b/sys/dev/acpica5/acpi_thinkpad/acpi_thinkpad.c
@@ -0,0 +1,1046 @@
+/*
+ * Copyright (c) 2004 Takanori Watanabe
+ * Copyright (c) 2005 Markus Brueffer <markus at FreeBSD.org>
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *    notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *    notice, this list of conditions and the following disclaimer in the
+ *    documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+ */
+
+/*
+ * Driver for extra ACPI-controlled gadgets found on IBM and Lenovo ThinkPad
+ * laptops. Inspired by the ibm-acpi and tpb projects which implement these
+ * features on Linux.
+ *
+ *   acpi-ibm: <http://ibm-acpi.sourceforge.net/>
+ *        tpb: <http://www.nongnu.org/tpb/>
+ */
+
+#include "opt_acpi.h"
+#include <sys/param.h>
+#include <sys/kernel.h>
+#include <sys/bus.h>
+#include <machine/cpufunc.h>
+#include <sys/module.h>
+/* #include <dev/led/led.h> */
+#include <sys/sensors.h>
+#include <sys/sysctl.h>
+#include <machine/clock.h>
+
+#include "acpi.h"
+#include "acpivar.h"
+#include "acpi_if.h"
+
+#define _COMPONENT	ACPI_OEM
+ACPI_MODULE_NAME("THINKPAD")
+
+/* Internal methods */
+#define ACPI_THINKPAD_METHOD_EVENTS		1
+#define ACPI_THINKPAD_METHOD_EVENTMASK		2
+#define ACPI_THINKPAD_METHOD_HOTKEY		3
+#define ACPI_THINKPAD_METHOD_BRIGHTNESS		4
+#define ACPI_THINKPAD_METHOD_VOLUME		5
+#define ACPI_THINKPAD_METHOD_MUTE		6
+#define ACPI_THINKPAD_METHOD_THINKLIGHT		7
+#define ACPI_THINKPAD_METHOD_BLUETOOTH		8
+#define ACPI_THINKPAD_METHOD_WLAN		9
+#define ACPI_THINKPAD_METHOD_FANSPEED		10
+#define ACPI_THINKPAD_METHOD_FANLEVEL		11
+#define ACPI_THINKPAD_METHOD_FANSTATUS		12
+#define ACPI_THINKPAD_METHOD_THERMAL		13
+
+/* Hotkeys/Buttons */
+#define THINKPAD_RTC_HOTKEY1			0x64
+#define   THINKPAD_RTC_MASK_HOME		(1 << 0)
+#define   THINKPAD_RTC_MASK_SEARCH		(1 << 1)
+#define   THINKPAD_RTC_MASK_MAIL		(1 << 2)
+#define   THINKPAD_RTC_MASK_WLAN		(1 << 5)
+#define THINKPAD_RTC_HOTKEY2			0x65
+#define   THINKPAD_RTC_MASK_THINKPAD		(1 << 3)
+#define   THINKPAD_RTC_MASK_ZOOM		(1 << 5)
+#define   THINKPAD_RTC_MASK_VIDEO		(1 << 6)
+#define   THINKPAD_RTC_MASK_HIBERNATE		(1 << 7)
+#define THINKPAD_RTC_THINKLIGHT			0x66
+#define   THINKPAD_RTC_MASK_THINKLIGHT		(1 << 4)
+#define THINKPAD_RTC_SCREENEXPAND		0x67
+#define   THINKPAD_RTC_MASK_SCREENEXPAND	(1 << 5)
+#define THINKPAD_RTC_BRIGHTNESS			0x6c
+#define   THINKPAD_RTC_MASK_BRIGHTNESS		(1 << 5)
+#define THINKPAD_RTC_VOLUME			0x6e
+#define   THINKPAD_RTC_MASK_VOLUME		(1 << 7)
+
+/* Embedded Controller registers */
+#define THINKPAD_EC_BRIGHTNESS			0x31
+#define   THINKPAD_EC_MASK_BRI			0x7
+#define THINKPAD_EC_VOLUME			0x30
+#define   THINKPAD_EC_MASK_VOL			0xf
+#define   THINKPAD_EC_MASK_MUTE			(1 << 6)
+#define THINKPAD_EC_FANSTATUS			0x2F
+#define   THINKPAD_EC_MASK_FANLEVEL		0x3f
+#define   THINKPAD_EC_MASK_FANDISENGAGED	(1 << 6)
+#define   THINKPAD_EC_MASK_FANSTATUS		(1 << 7)
+#define THINKPAD_EC_FANSPEED			0x84
+
+/* CMOS Commands */
+#define THINKPAD_CMOS_VOLUME_DOWN		0
+#define THINKPAD_CMOS_VOLUME_UP			1
+#define THINKPAD_CMOS_VOLUME_MUTE		2
+#define THINKPAD_CMOS_BRIGHTNESS_UP		4
+#define THINKPAD_CMOS_BRIGHTNESS_DOWN		5
+
+/* ACPI methods */
+#define THINKPAD_NAME_KEYLIGHT			"KBLT"
+#define THINKPAD_NAME_WLAN_BT_GET		"GBDC"
+#define THINKPAD_NAME_WLAN_BT_SET		"SBDC"
+#define   THINKPAD_NAME_MASK_BT			(1 << 1)
+#define   THINKPAD_NAME_MASK_WLAN		(1 << 2)
+#define THINKPAD_NAME_THERMAL_GET		"TMP7"
+#define THINKPAD_NAME_THERMAL_UPDT		"UPDT"
+
+#define THINKPAD_NAME_EVENTS_STATUS_GET		"DHKC"
+#define THINKPAD_NAME_EVENTS_MASK_GET		"DHKN"
+#define THINKPAD_NAME_EVENTS_STATUS_SET		"MHKC"
+#define THINKPAD_NAME_EVENTS_MASK_SET		"MHKM"
+#define THINKPAD_NAME_EVENTS_GET		"MHKP"
+#define THINKPAD_NAME_EVENTS_AVAILMASK		"MHKA"
+
+#define ABS(x) (((x) < 0)? -(x) : (x))
+
+struct acpi_thinkpad_softc {
+	device_t	dev;
+	ACPI_HANDLE	handle;
+
+	/* Embedded controller */
+	device_t	ec_dev;
+	ACPI_HANDLE	ec_handle;
+
+	/* CMOS */
+	ACPI_HANDLE	cmos_handle;
+
+	/* Fan status */
+	ACPI_HANDLE	fan_handle;
+	int		fan_levels;
+
+	/* Keylight commands and states */
+	ACPI_HANDLE	light_handle;
+	int		light_cmd_on;
+	int		light_cmd_off;
+	int		light_val;
+	int		light_get_supported;
+	int		light_set_supported;
+
+	/* led(4) interface */
+	struct cdev	*led_dev;
+	int		led_busy;
+	int		led_state;
+
+	int		wlan_bt_flags;
+	int		thermal_updt_supported;
+
+	unsigned int	events_availmask;
+	unsigned int	events_initialmask;
+	int		events_mask_supported;
+	int		events_enable;
+
+	/* sensors(9) related */
+	struct ksensordev sensordev;
+	struct ksensor sensors[9];	/* XXX: 8 thermal + fan */
+
+	struct sysctl_ctx_list	*sysctl_ctx;
+	struct sysctl_oid	*sysctl_tree;
+};
+
+static struct {
+	char	*name;
+	int	method;
+	char	*description;
+	int	access;
+} acpi_thinkpad_sysctls[] = {
+	{
+		.name		= "events",
+		.method		= ACPI_THINKPAD_METHOD_EVENTS,
+		.description	= "ACPI events enable",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "eventmask",
+		.method		= ACPI_THINKPAD_METHOD_EVENTMASK,
+		.description	= "ACPI eventmask",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "hotkey",
+		.method		= ACPI_THINKPAD_METHOD_HOTKEY,
+		.description	= "Key Status",
+		.access		= CTLTYPE_INT | CTLFLAG_RD
+	},
+	{
+		.name		= "lcd_brightness",
+		.method		= ACPI_THINKPAD_METHOD_BRIGHTNESS,
+		.description	= "LCD Brightness",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "volume",
+		.method		= ACPI_THINKPAD_METHOD_VOLUME,
+		.description	= "Volume",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "mute",
+		.method		= ACPI_THINKPAD_METHOD_MUTE,
+		.description	= "Mute",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "thinklight",
+		.method		= ACPI_THINKPAD_METHOD_THINKLIGHT,
+		.description	= "Thinklight enable",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "bluetooth",
+		.method		= ACPI_THINKPAD_METHOD_BLUETOOTH,
+		.description	= "Bluetooth enable",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "wlan",
+		.method		= ACPI_THINKPAD_METHOD_WLAN,
+		.description	= "WLAN enable",
+		.access		= CTLTYPE_INT | CTLFLAG_RD
+	},
+	{
+		.name		= "fan_level",
+		.method		= ACPI_THINKPAD_METHOD_FANLEVEL,
+		.description	= "Fan level",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "fan",
+		.method		= ACPI_THINKPAD_METHOD_FANSTATUS,
+		.description	= "Fan enable",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+
+	{ NULL, 0, NULL, 0 }
+};
+
+/* ACPI_SERIAL_DECL(thinkpad, "ACPI THINKPAD extras"); */
+static int	acpi_thinkpad_probe(device_t dev);
+static int	acpi_thinkpad_attach(device_t dev);
+static int	acpi_thinkpad_detach(device_t dev);
+
+#if 0 /* not yet */
+static void	thinkpad_led(void *softc, int onoff);
+static void	thinkpad_led_task(struct acpi_thinkpad_softc *sc,
+		int pending __unused);
+#endif
+
+static int	acpi_thinkpad_sysctl(SYSCTL_HANDLER_ARGS);
+static int	acpi_thinkpad_sysctl_init(struct acpi_thinkpad_softc *sc,
+		int method);
+static int	acpi_thinkpad_sysctl_get(struct acpi_thinkpad_softc *sc,
+		int method);
+static int	acpi_thinkpad_sysctl_set(struct acpi_thinkpad_softc *sc,
+		int method, int val);
+
+static int	acpi_thinkpad_eventmask_set(struct acpi_thinkpad_softc *sc,
+		int val);
+static void	acpi_thinkpad_notify(ACPI_HANDLE h, UINT32 notify,
+		void *context);
+static void	acpi_thinkpad_refresh(void *);
+
+static device_method_t acpi_thinkpad_methods[] = {
+	/* Device interface */
+	DEVMETHOD(device_probe, acpi_thinkpad_probe),
+	DEVMETHOD(device_attach, acpi_thinkpad_attach),
+	DEVMETHOD(device_detach, acpi_thinkpad_detach),
+	{0, 0}
+};
+
+static driver_t	acpi_thinkpad_driver = {
+	"acpi_thinkpad",
+	acpi_thinkpad_methods,
+	sizeof(struct acpi_thinkpad_softc),
+};
+
+static devclass_t acpi_thinkpad_devclass;
+
+DRIVER_MODULE(acpi_thinkpad, acpi, acpi_thinkpad_driver,
+    acpi_thinkpad_devclass, 0, 0);
+MODULE_DEPEND(acpi_thinkpad, acpi, 1, 1, 1);
+static char    *thinkpad_ids[] = {"IBM0068", NULL};
+
+#if 0 /* not yet */
+static void
+thinkpad_led(void *softc, int onoff)
+{
+	struct acpi_thinkpad_softc* sc = (struct acpi_thinkpad_softc*) softc;
+
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+
+	if (sc->led_busy)
+		return;
+
+	sc->led_busy = 1;
+	sc->led_state = onoff;
+
+	AcpiOsExecute(OSL_NOTIFY_HANDLER, (void *)thinkpad_led_task, sc);
+}
+
+static void
+thinkpad_led_task(struct acpi_thinkpad_softc *sc, int pending __unused)
+{
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+
+	/* ACPI_SERIAL_BEGIN(thinkpad); */
+	acpi_thinkpad_sysctl_set(sc, ACPI_THINKPAD_METHOD_THINKLIGHT, sc->led_state);
+	/* ACPI_SERIAL_END(thinkpad); */
+
+	sc->led_busy = 0;
+}
+#endif
+
+static int
+acpi_thinkpad_probe(device_t dev)
+{
+	if (acpi_disabled("thinkpad") ||
+	    ACPI_ID_PROBE(device_get_parent(dev), dev, thinkpad_ids) == NULL ||
+	    device_get_unit(dev) != 0) 
+		return (ENXIO);
+
+	device_set_desc(dev, "IBM/Lenovo ThinkPad ACPI Extras");
+	return (0);
+}
+
+static int
+acpi_thinkpad_attach(device_t dev)
+{
+	struct acpi_thinkpad_softc	*sc;
+	struct acpi_softc	*acpi_sc;
+	devclass_t		ec_devclass;
+	int			i;
+
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t) __func__);
+
+	sc = device_get_softc(dev);
+	sc->dev = dev;
+	sc->handle = acpi_get_handle(dev);
+
+	acpi_sc = acpi_device_get_parent_softc(dev);
+
+	/* Look for the first embedded controller */
+        if (!(ec_devclass = devclass_find ("acpi_ec"))) {
+		if (bootverbose)
+			device_printf(dev, "Couldn't find acpi_ec devclass\n");
+		return (EINVAL);
+	}
+        if (!(sc->ec_dev = devclass_get_device(ec_devclass, 0))) {
+		if (bootverbose)
+			device_printf(dev, "Couldn't find acpi_ec device\n");
+		return (EINVAL);
+	}
+	sc->ec_handle = acpi_get_handle(sc->ec_dev);
+
+	/* ACPI_SERIAL_BEGIN(thinkpad); */
+
+#if 0
+	/* Get the sysctl tree */
+	sc->sysctl_ctx = device_get_sysctl_ctx(dev);
+	sc->sysctl_tree = device_get_sysctl_tree(dev);
+#endif
+	sysctl_ctx_init(sc->sysctl_ctx);
+	sc->sysctl_tree = SYSCTL_ADD_NODE(sc->sysctl_ctx,
+	    SYSCTL_CHILDREN(acpi_sc->acpi_sysctl_tree), OID_AUTO,
+	    "thinkpad", CTLFLAG_RD, 0, "");
+
+	/* Look for event mask and hook up the nodes */
+	sc->events_mask_supported = ACPI_SUCCESS(acpi_GetInteger(sc->handle,
+	    THINKPAD_NAME_EVENTS_MASK_GET, &sc->events_initialmask));
+
+	if (sc->events_mask_supported) {
+		SYSCTL_ADD_INT(sc->sysctl_ctx,
+		    SYSCTL_CHILDREN(sc->sysctl_tree), OID_AUTO,
+		    "initialmask", CTLFLAG_RD,
+		    &sc->events_initialmask, 0, "Initial eventmask");
+
+		/* The availmask is the bitmask of supported events */
+		if (ACPI_FAILURE(acpi_GetInteger(sc->handle,
+		    THINKPAD_NAME_EVENTS_AVAILMASK, &sc->events_availmask)))
+			sc->events_availmask = 0xffffffff;
+
+		SYSCTL_ADD_INT(sc->sysctl_ctx,
+		    SYSCTL_CHILDREN(sc->sysctl_tree), OID_AUTO,
+		    "availmask", CTLFLAG_RD,
+		    &sc->events_availmask, 0, "Mask of supported events");
+	}
+
+	/* Hook up proc nodes */
+	for (i = 0; acpi_thinkpad_sysctls[i].name != NULL; i++) {
+		if (!acpi_thinkpad_sysctl_init(sc,
+		    acpi_thinkpad_sysctls[i].method))
+			continue;
+
+		SYSCTL_ADD_PROC(sc->sysctl_ctx,
+		    SYSCTL_CHILDREN(sc->sysctl_tree), OID_AUTO,
+		    acpi_thinkpad_sysctls[i].name,
+		    acpi_thinkpad_sysctls[i].access,
+		    sc, i, acpi_thinkpad_sysctl, "I",
+		    acpi_thinkpad_sysctls[i].description);
+	}
+
+	/* ACPI_SERIAL_END(thinkpad); */
+
+	/* Handle notifies */
+	AcpiInstallNotifyHandler(sc->handle, ACPI_DEVICE_NOTIFY,
+	    acpi_thinkpad_notify, dev);
+
+#if 0
+	/* Hook up light to led(4) */
+	if (sc->light_set_supported)
+		sc->led_dev = led_create_state(thinkpad_led, sc, "thinklight",
+		    sc->light_val);
+#endif
+	/* Attach sensors(9). */
+	if (sensor_task_register(sc, acpi_thinkpad_refresh, 5)) {
+		device_printf(sc->dev, "unable to register update task\n");
+		return 1;
+	}
+
+	strlcpy(sc->sensordev.xname, device_get_nameunit(sc->dev),
+	    sizeof(sc->sensordev.xname));
+
+	/* XXX: Temp sensors */
+	for (i = 0; i < 8; ++i) {
+		sc->sensors[i].type = SENSOR_TEMP;
+		sensor_attach(&sc->sensordev, &sc->sensors[i]);
+	}
+	
+	/* Fan RPM sensor */
+	sc->sensors[8].type = SENSOR_FANRPM;
+	sensor_attach(&sc->sensordev, &sc->sensors[8]);
+
+	sensordev_install(&sc->sensordev);
+
+	return (0);
+}
+
+static int
+acpi_thinkpad_detach(device_t dev)
+{
+	int i;
+
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t) __func__);
+
+	struct acpi_thinkpad_softc *sc = device_get_softc(dev);
+
+	/* Disable events and restore eventmask */
+	/* ACPI_SERIAL_BEGIN(thinkpad); */
+	acpi_thinkpad_sysctl_set(sc, ACPI_THINKPAD_METHOD_EVENTS, 0);
+	acpi_thinkpad_sysctl_set(sc, ACPI_THINKPAD_METHOD_EVENTMASK,
+	    sc->events_initialmask);
+	/* ACPI_SERIAL_END(thinkpad); */
+
+	AcpiRemoveNotifyHandler(sc->handle, ACPI_DEVICE_NOTIFY,
+	    acpi_thinkpad_notify);
+
+	sysctl_ctx_free(sc->sysctl_ctx);
+
+#if 0
+	if (sc->led_dev != NULL)
+		led_destroy(sc->led_dev);
+#endif
+	sensordev_deinstall(&sc->sensordev);
+	for (i = 0; i < 9; i++)
+		sensor_detach(&sc->sensordev, &sc->sensors[i]);
+	sensor_task_unregister(sc);
+
+	return (0);
+}
+
+static int
+acpi_thinkpad_eventmask_set(struct acpi_thinkpad_softc *sc, int val)
+{
+	int i;
+	ACPI_OBJECT		arg[2];
+	ACPI_OBJECT_LIST	args;
+	ACPI_STATUS		status;
+
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+	/* ACPI_SERIAL_ASSERT(thinkpad); */
+
+	args.Count = 2;
+	args.Pointer = arg;
+	arg[0].Type = ACPI_TYPE_INTEGER;
+	arg[1].Type = ACPI_TYPE_INTEGER;
+
+	for (i = 0; i < 32; ++i) {
+		arg[0].Integer.Value = i+1;
+		arg[1].Integer.Value = (((1 << i) & val) != 0);
+		status = AcpiEvaluateObject(sc->handle,
+		    THINKPAD_NAME_EVENTS_MASK_SET, &args, NULL);
+
+		if (ACPI_FAILURE(status))
+			return (status);
+	}
+
+	return (0);
+}
+
+static int
+acpi_thinkpad_sysctl(SYSCTL_HANDLER_ARGS)
+{
+	struct acpi_thinkpad_softc	*sc;
+	int			arg;
+	int			error = 0;
+	int			function;
+	int			method;
+	
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+
+	sc = (struct acpi_thinkpad_softc *)oidp->oid_arg1;
+	function = oidp->oid_arg2;
+	method = acpi_thinkpad_sysctls[function].method;
+
+	/* ACPI_SERIAL_BEGIN(thinkpad); */
+	arg = acpi_thinkpad_sysctl_get(sc, method);
+	error = sysctl_handle_int(oidp, &arg, 0, req);
+
+	/* Sanity check */
+	if (error != 0 || req->newptr == NULL)
+		goto out;
+
+	/* Update */
+	error = acpi_thinkpad_sysctl_set(sc, method, arg);
+
+out:
+	/* ACPI_SERIAL_END(thinkpad); */
+	return (error);
+}
+
+static int
+acpi_thinkpad_sysctl_get(struct acpi_thinkpad_softc *sc, int method)
+{
+	ACPI_INTEGER	val_ec;
+	int 		val = 0, key;
+
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+	/* ACPI_SERIAL_ASSERT(thinkpad); */
+
+	switch (method) {
+	case ACPI_THINKPAD_METHOD_EVENTS:
+		acpi_GetInteger(sc->handle, THINKPAD_NAME_EVENTS_STATUS_GET,
+		    &val);
+		break;
+
+	case ACPI_THINKPAD_METHOD_EVENTMASK:
+		if (sc->events_mask_supported)
+			acpi_GetInteger(sc->handle,
+			    THINKPAD_NAME_EVENTS_MASK_GET, &val);
+		break;
+
+	case ACPI_THINKPAD_METHOD_HOTKEY:
+		/*
+		 * Construct the hotkey as a bitmask as illustrated below.
+		 * Note that whenever a key was pressed, the respecting bit
+		 * toggles and nothing else changes.
+		 * +--+--+-+-+-+-+-+-+-+-+-+-+
+		 * |11|10|9|8|7|6|5|4|3|2|1|0|
+		 * +--+--+-+-+-+-+-+-+-+-+-+-+
+		 *   |  | | | | | | | | | | |
+		 *   |  | | | | | | | | | | +- Home Button
+		 *   |  | | | | | | | | | +--- Search Button
+		 *   |  | | | | | | | | +----- Mail Button
+		 *   |  | | | | | | | +------- Thinkpad Button
+		 *   |  | | | | | | +--------- Zoom (Fn + Space)
+		 *   |  | | | | | +----------- WLAN Button
+		 *   |  | | | | +------------- Video Button
+		 *   |  | | | +--------------- Hibernate Button
+		 *   |  | | +----------------- Thinklight Button
+		 *   |  | +------------------- Screen expand (Fn + F8)
+		 *   |  +--------------------- Brightness
+		 *   +------------------------ Volume/Mute
+		 */
+		key = rtcin(THINKPAD_RTC_HOTKEY1);
+		val = (THINKPAD_RTC_MASK_HOME | THINKPAD_RTC_MASK_SEARCH |
+		    THINKPAD_RTC_MASK_MAIL | THINKPAD_RTC_MASK_WLAN) & key;
+		key = rtcin(THINKPAD_RTC_HOTKEY2);
+		val |= (THINKPAD_RTC_MASK_THINKPAD | THINKPAD_RTC_MASK_VIDEO |
+		    THINKPAD_RTC_MASK_HIBERNATE) & key;
+		val |= (THINKPAD_RTC_MASK_ZOOM & key) >> 1;
+		key = rtcin(THINKPAD_RTC_THINKLIGHT);
+		val |= (THINKPAD_RTC_MASK_THINKLIGHT & key) << 4;
+		key = rtcin(THINKPAD_RTC_SCREENEXPAND);
+		val |= (THINKPAD_RTC_MASK_THINKLIGHT & key) << 4;
+		key = rtcin(THINKPAD_RTC_BRIGHTNESS);
+		val |= (THINKPAD_RTC_MASK_BRIGHTNESS & key) << 5;
+		key = rtcin(THINKPAD_RTC_VOLUME);
+		val |= (THINKPAD_RTC_MASK_VOLUME & key) << 4;
+		break;
+
+	case ACPI_THINKPAD_METHOD_BRIGHTNESS:
+		ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_BRIGHTNESS, &val_ec, 1);
+		val = val_ec & THINKPAD_EC_MASK_BRI;
+		break;
+
+	case ACPI_THINKPAD_METHOD_VOLUME:
+		ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_VOLUME, &val_ec, 1);
+		val = val_ec & THINKPAD_EC_MASK_VOL;
+		break;
+
+	case ACPI_THINKPAD_METHOD_MUTE:
+		val = ((val_ec & THINKPAD_EC_MASK_MUTE) ==
+		    THINKPAD_EC_MASK_MUTE);
+		break;
+
+	case ACPI_THINKPAD_METHOD_THINKLIGHT:
+		if (sc->light_get_supported)
+			acpi_GetInteger(sc->ec_handle, THINKPAD_NAME_KEYLIGHT,
+			    &val);
+		else
+			val = sc->light_val;
+		break;
+
+	case ACPI_THINKPAD_METHOD_BLUETOOTH:
+		acpi_GetInteger(sc->handle, THINKPAD_NAME_WLAN_BT_GET, &val);
+		sc->wlan_bt_flags = val;
+		val = ((val & THINKPAD_NAME_MASK_BT) != 0);
+		break;
+
+	case ACPI_THINKPAD_METHOD_WLAN:
+		acpi_GetInteger(sc->handle, THINKPAD_NAME_WLAN_BT_GET, &val);
+		sc->wlan_bt_flags = val;
+		val = ((val & THINKPAD_NAME_MASK_WLAN) != 0);
+		break;
+
+	case ACPI_THINKPAD_METHOD_FANSPEED:
+		if (sc->fan_handle) {
+			if (ACPI_FAILURE(acpi_GetInteger(sc->fan_handle,
+			    NULL, &val)))
+				val = -1;
+		}
+		else {
+			ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_FANSPEED,
+			    &val_ec, 2);
+			val = val_ec;
+		}
+		break;
+
+	case ACPI_THINKPAD_METHOD_FANLEVEL:
+		/*
+		 * The THINKPAD_EC_FANSTATUS register works as follows:
+		 * Bit 0-5 indicate the level at which the fan operates. Only
+		 *       values between 0 and 7 have an effect. Everything
+		 *       above 7 is treated the same as level 7
+		 * Bit 6 overrides the fan speed limit if set to 1
+		 * Bit 7 indicates at which mode the fan operates:
+		 *       manual (0) or automatic (1)
+		 */
+		if (!sc->fan_handle) {
+			ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_FANSTATUS,
+			    &val_ec, 1);
+			val = val_ec & THINKPAD_EC_MASK_FANLEVEL;
+		}
+		break;
+
+	case ACPI_THINKPAD_METHOD_FANSTATUS:
+		if (!sc->fan_handle) {
+			ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_FANSTATUS,
+			    &val_ec, 1);
+			val = (val_ec & THINKPAD_EC_MASK_FANSTATUS) ==
+			    THINKPAD_EC_MASK_FANSTATUS;
+		}
+		else
+			val = -1;
+		break;
+	}
+
+	return (val);
+}
+
+static int
+acpi_thinkpad_sysctl_set(struct acpi_thinkpad_softc *sc, int method, int arg)
+{
+	int			val, step, i;
+	ACPI_INTEGER		val_ec;
+	ACPI_OBJECT		Arg;
+	ACPI_OBJECT_LIST	Args;
+	ACPI_STATUS		status;
+
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+	/* ACPI_SERIAL_ASSERT(thinkpad); */
+
+	switch (method) {
+	case ACPI_THINKPAD_METHOD_EVENTS:
+		if (arg < 0 || arg > 1)
+			return (EINVAL);
+
+		status = acpi_SetInteger(sc->handle,
+		    THINKPAD_NAME_EVENTS_STATUS_SET, arg);
+		if (ACPI_FAILURE(status))
+			return (status);
+		if (sc->events_mask_supported)
+			return acpi_thinkpad_eventmask_set(sc,
+			    sc->events_availmask);
+		break;
+
+	case ACPI_THINKPAD_METHOD_EVENTMASK:
+		if (sc->events_mask_supported)
+			return acpi_thinkpad_eventmask_set(sc, arg);
+		break;
+
+	case ACPI_THINKPAD_METHOD_BRIGHTNESS:
+		if (arg < 0 || arg > 7)
+			return (EINVAL);
+
+		if (sc->cmos_handle) {
+			/* Read the current brightness */
+			status = ACPI_EC_READ(sc->ec_dev,
+			    THINKPAD_EC_BRIGHTNESS, &val_ec, 1);
+			if (ACPI_FAILURE(status))
+				return (status);
+			val = val_ec & THINKPAD_EC_MASK_BRI;
+
+			Args.Count = 1;
+			Args.Pointer = &Arg;
+			Arg.Type = ACPI_TYPE_INTEGER;
+			Arg.Integer.Value = (arg > val) ?
+			    THINKPAD_CMOS_BRIGHTNESS_UP :
+			    THINKPAD_CMOS_BRIGHTNESS_DOWN;
+
+			step = (arg > val) ? 1 : -1;
+			for (i = val; i != arg; i += step) {
+				status = AcpiEvaluateObject(sc->cmos_handle,
+				    NULL, &Args, NULL);
+				if (ACPI_FAILURE(status))
+					break;
+			}
+		}
+		return ACPI_EC_WRITE(sc->ec_dev, THINKPAD_EC_BRIGHTNESS,
+		    arg, 1);
+		break;
+
+	case ACPI_THINKPAD_METHOD_VOLUME:
+		if (arg < 0 || arg > 14)
+			return (EINVAL);
+
+		status = ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_VOLUME,
+		    &val_ec, 1);
+		if (ACPI_FAILURE(status))
+			return (status);
+
+		if (sc->cmos_handle) {
+			val = val_ec & THINKPAD_EC_MASK_VOL;
+
+			Args.Count = 1;
+			Args.Pointer = &Arg;
+			Arg.Type = ACPI_TYPE_INTEGER;
+			Arg.Integer.Value = (arg > val) ?
+			    THINKPAD_CMOS_VOLUME_UP : THINKPAD_CMOS_VOLUME_DOWN;
+
+			step = (arg > val) ? 1 : -1;
+			for (i = val; i != arg; i += step) {
+				status = AcpiEvaluateObject(sc->cmos_handle,
+				    NULL, &Args, NULL);
+				if (ACPI_FAILURE(status))
+					break;
+			}
+		}
+		return ACPI_EC_WRITE(sc->ec_dev, THINKPAD_EC_VOLUME, arg +
+		    (val_ec & (~THINKPAD_EC_MASK_VOL)), 1);
+		break;
+
+	case ACPI_THINKPAD_METHOD_MUTE:
+		if (arg < 0 || arg > 1)
+			return (EINVAL);
+
+		status = ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_VOLUME,
+		    &val_ec, 1);
+		if (ACPI_FAILURE(status))
+			return (status);
+
+		if (sc->cmos_handle) {
+			val = val_ec & THINKPAD_EC_MASK_VOL;
+
+			Args.Count = 1;
+			Args.Pointer = &Arg;
+			Arg.Type = ACPI_TYPE_INTEGER;
+			Arg.Integer.Value = THINKPAD_CMOS_VOLUME_MUTE;
+
+			status = AcpiEvaluateObject(sc->cmos_handle, NULL,
+			    &Args, NULL);
+			if (ACPI_FAILURE(status))
+				break;
+		}
+		return ACPI_EC_WRITE(sc->ec_dev, THINKPAD_EC_VOLUME, (arg==1) ?
+		   val_ec | THINKPAD_EC_MASK_MUTE :
+		   val_ec & (~THINKPAD_EC_MASK_MUTE), 1);
+		break;
+
+	case ACPI_THINKPAD_METHOD_THINKLIGHT:
+		if (arg < 0 || arg > 1)
+			return (EINVAL);
+
+		if (sc->light_set_supported) {
+			Args.Count = 1;
+			Args.Pointer = &Arg;
+			Arg.Type = ACPI_TYPE_INTEGER;
+			Arg.Integer.Value = arg ?
+			    sc->light_cmd_on : sc->light_cmd_off;
+
+			status = AcpiEvaluateObject(sc->light_handle, NULL,
+			    &Args, NULL);
+			if (ACPI_SUCCESS(status))
+				sc->light_val = arg;
+			return (status);
+		}
+		break;
+
+	case ACPI_THINKPAD_METHOD_BLUETOOTH:
+		if (arg < 0 || arg > 1)
+			return (EINVAL);
+
+		val = (arg == 1) ? sc->wlan_bt_flags |
+		    THINKPAD_NAME_MASK_BT :
+		    sc->wlan_bt_flags & (~THINKPAD_NAME_MASK_BT);
+		return acpi_SetInteger(sc->handle, THINKPAD_NAME_WLAN_BT_SET,
+		    val);
+		break;
+
+	case ACPI_THINKPAD_METHOD_FANLEVEL:
+		if (arg < 0 || arg > 7)
+			return (EINVAL);
+
+		if (!sc->fan_handle) {
+			/* Read the current fanstatus */
+			ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_FANSTATUS,
+			    &val_ec, 1);
+			val = val_ec & (~THINKPAD_EC_MASK_FANLEVEL);
+
+			return ACPI_EC_WRITE(sc->ec_dev, THINKPAD_EC_FANSTATUS,
+			    val | arg, 1);
+		}
+		break;
+
+	case ACPI_THINKPAD_METHOD_FANSTATUS:
+		if (arg < 0 || arg > 1)
+			return (EINVAL);
+
+		if (!sc->fan_handle) {
+			/* Read the current fanstatus */
+			ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_FANSTATUS,
+			    &val_ec, 1);
+
+			return ACPI_EC_WRITE(sc->ec_dev, THINKPAD_EC_FANSTATUS,
+			    (arg == 1) ? (val_ec | THINKPAD_EC_MASK_FANSTATUS) :
+			    (val_ec & (~THINKPAD_EC_MASK_FANSTATUS)), 1);
+		}
+		break;
+	}
+
+	return (0);
+}
+
+static int
+acpi_thinkpad_sysctl_init(struct acpi_thinkpad_softc *sc, int method)
+{
+	int 			dummy;
+	ACPI_OBJECT_TYPE 	cmos_t;
+	ACPI_HANDLE		ledb_handle;
+
+	switch (method) {
+	case ACPI_THINKPAD_METHOD_EVENTS:
+		/* Events are disabled by default */
+		return (TRUE);
+
+	case ACPI_THINKPAD_METHOD_EVENTMASK:
+		return (sc->events_mask_supported);
+
+	case ACPI_THINKPAD_METHOD_HOTKEY:
+	case ACPI_THINKPAD_METHOD_BRIGHTNESS:
+	case ACPI_THINKPAD_METHOD_VOLUME:
+	case ACPI_THINKPAD_METHOD_MUTE:
+		/* EC is required here, which was already checked before */
+		return (TRUE);
+
+	case ACPI_THINKPAD_METHOD_THINKLIGHT:
+		sc->cmos_handle = NULL;
+		sc->light_get_supported = ACPI_SUCCESS(acpi_GetInteger(
+		    sc->ec_handle, THINKPAD_NAME_KEYLIGHT, &sc->light_val));
+
+		if ((ACPI_SUCCESS(AcpiGetHandle(sc->handle, "\\UCMS",
+		    &sc->light_handle)) ||
+		    ACPI_SUCCESS(AcpiGetHandle(sc->handle, "\\CMOS",
+		    &sc->light_handle)) ||
+		    ACPI_SUCCESS(AcpiGetHandle(sc->handle, "\\CMS",
+		    &sc->light_handle))) &&
+		    ACPI_SUCCESS(AcpiGetType(sc->light_handle, &cmos_t)) &&
+		    cmos_t == ACPI_TYPE_METHOD) {
+			sc->light_cmd_on = 0x0c;
+			sc->light_cmd_off = 0x0d;
+			sc->cmos_handle = sc->light_handle;
+		}
+		else if (ACPI_SUCCESS(AcpiGetHandle(sc->handle, "\\LGHT",
+		    &sc->light_handle))) {
+			sc->light_cmd_on = 1;
+			sc->light_cmd_off = 0;
+		}
+		else
+			sc->light_handle = NULL;
+
+		sc->light_set_supported = (sc->light_handle &&
+		    ACPI_FAILURE(AcpiGetHandle(sc->ec_handle, "LEDB",
+		    &ledb_handle)));
+
+		if (sc->light_get_supported)
+			return (TRUE);
+
+		if (sc->light_set_supported) {
+			sc->light_val = 0;
+			return (TRUE);
+		}
+
+		return (FALSE);
+
+	case ACPI_THINKPAD_METHOD_BLUETOOTH:
+	case ACPI_THINKPAD_METHOD_WLAN:
+		if (ACPI_SUCCESS(acpi_GetInteger(sc->handle,
+		    THINKPAD_NAME_WLAN_BT_GET, &dummy)))
+			return (TRUE);
+		return (FALSE);
+
+	case ACPI_THINKPAD_METHOD_FANSPEED:
+		/* 
+		 * Some models report the fan speed in levels from 0-7
+		 * Newer models report it contiguously
+		 */
+		sc->fan_levels = (ACPI_SUCCESS(AcpiGetHandle(sc->handle, "GFAN",
+		    &sc->fan_handle)) ||
+		    ACPI_SUCCESS(AcpiGetHandle(sc->handle, "\\FSPD",
+		    &sc->fan_handle)));
+		return (TRUE);
+
+	case ACPI_THINKPAD_METHOD_FANLEVEL:
+	case ACPI_THINKPAD_METHOD_FANSTATUS:
+		/* 
+		 * Fan status is only supported on those models,
+		 * which report fan RPM contiguously, not in levels
+		 */
+		if (sc->fan_levels)
+			return (FALSE);
+		return (TRUE);
+
+	case ACPI_THINKPAD_METHOD_THERMAL:
+		if (ACPI_SUCCESS(acpi_GetInteger(sc->ec_handle,
+		    THINKPAD_NAME_THERMAL_GET, &dummy))) {
+			sc->thermal_updt_supported =
+			    ACPI_SUCCESS(acpi_GetInteger(sc->ec_handle,
+			    THINKPAD_NAME_THERMAL_UPDT, &dummy));
+			return (TRUE);
+		}
+		return (FALSE);
+	}
+	return (FALSE);
+}
+
+static void
+acpi_thinkpad_notify(ACPI_HANDLE h, UINT32 notify, void *context)
+{
+	int		event, arg, type;
+	device_t	dev = context;
+	struct acpi_thinkpad_softc *sc = device_get_softc(dev);
+
+	ACPI_FUNCTION_TRACE_U32((char *)(uintptr_t)__func__, notify);
+
+	if (notify != 0x80)
+		device_printf(dev, "Unknown notify\n");
+
+	for (;;) {
+		acpi_GetInteger(acpi_get_handle(dev), THINKPAD_NAME_EVENTS_GET,
+		    &event);
+
+		if (event == 0)
+			break;
+
+		type = (event >> 12) & 0xf;
+		arg = event & 0xfff;
+		switch (type) {
+		case 1:
+			if (!(sc->events_availmask & (1 << (arg - 1)))) {
+				device_printf(dev, "Unknown key %d\n", arg);
+				break;
+			}
+
+			/* Notify devd(8) */
+			device_printf(dev, "THINKPAD event: %u\n",
+			    (arg & 0xff));
+			acpi_UserNotify("THINKPAD", h, (arg & 0xff));
+			break;
+		default:
+			break;
+		}
+	}
+}
+
+static void
+acpi_thinkpad_refresh(void *arg)
+{
+	struct acpi_thinkpad_softc *sc = (struct acpi_thinkpad_softc *)arg;
+	char temp_cmd[] = "TMP0";
+	int data, i;
+	ACPI_INTEGER speed;
+
+	for (i = 0; i < 8; i++) {
+		temp_cmd[3] = '0' + i;
+		
+                /*
+                 * The TMPx methods seem to return +/- 128 or 0
+                 * when the respecting sensor is not available
+                 */
+		sc->sensors[i].flags &= ~SENSOR_FINVALID;
+                if (ACPI_FAILURE(acpi_GetInteger(sc->ec_handle, temp_cmd,
+                    &data)) || ABS(data) == 128 || data == 0) {
+			sc->sensors[i].flags |= SENSOR_FINVALID;
+                        data = 0;
+		}
+                else if (sc->thermal_updt_supported) {
+                        /* XXX: Temperature is reported in tenth of Kelvin */
+                        data = (data - 2732 + 5) / 10;
+		}
+		sc->sensors[i].value = data * 1000000 + 273150000;
+        }
+	
+	sc->sensors[8].flags &= ~SENSOR_FINVALID;
+	if (sc->fan_handle) {
+		if (ACPI_FAILURE(acpi_GetInteger(sc->fan_handle,
+		    NULL, &data)))
+			sc->sensors[8].flags |= SENSOR_FINVALID;
+                        data = -1;
+        }
+        else {
+                ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_FANSPEED, &speed, 2);
+                data = speed;
+        }
+
+	sc->sensors[8].value = data;
+}
diff --git a/sys/platform/pc32/conf/files b/sys/platform/pc32/conf/files
--- a/sys/platform/pc32/conf/files
+++ b/sys/platform/pc32/conf/files
@@ -72,6 +72,7 @@ dev/serial/dgb/dgm.c			optional	dgm
 ${OSACPI_MD_DIR}/acpi_machdep.c		optional        acpi
 ${OSACPI_MD_DIR}/acpi_wakeup.c		optional        acpi
 ${OSACPI_MD_DIR}/acpi_toshiba.c		optional        acpi_toshiba acpi
+${ACPICA_DIR}/acpi_thinkpad/acpi_thinkpad.c optional	acpi_thinkpad acpi
 acpi.h					optional	acpi		\
 	dependency	"$S/${ACPICA_DIR}/include/acpi.h"		\
 	compile-with	"cp $S/${ACPICA_DIR}/include/acpi.h ${.OBJDIR}/"	\



From hasso at estpak.ee  Thu Mar 20 03:49:13 2008
From: hasso at estpak.ee (Hasso Tepper)
Date: Thu, 20 Mar 2008 03:49:13 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Some questions regarding ACPI
In-Reply-To: <200803191322.46366.hasso@estpak.ee>
Message-ID: <200803201237.28823.hasso@estpak.ee>

Hasso Tepper wrote:
> There is also one fatal issue -laptop locks up hardly (no panic) while 
> unloading module. Any idea regarding this is welcome.

Nevermind, solved.


-- 
Hasso




From dillon at apollo.backplane.com  Fri Mar 21 19:24:01 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Fri, 21 Mar 2008 19:24:01 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: panic: assertion: hammer_btree_cmp(cursor->left_bound,	&cursor->node->ondisk->elms[0].leaf.base) <= 0 in btree_split_leaf
In-Reply-To: <200802232204.m1NM4cxd046264@apollo.backplane.com>
Message-ID: <200803220212.m2M2CiAY014435@apollo.backplane.com>

:While trying to find a procedure to reliably reproduce the panic
:I reported last time, I caught a different panic (uploaded at
: ~y0netan1/crash/9/ on my leaf account).  I wrote the following shell
:script (make sure to edit variables DISKS and MOUNTPT before using this
:script or it may trash your system):

    Ok, I believe I have fixed the left_bound assertion.  I also believe
    I have fixed the node ref count assertion on umount.

    There is currently one unfixed assertion related to the I/O
    path... sometimes the bp is being improperly disassociated from the
    related HAMMER structure.

    The full-filesystem case is still not being handled so don't test that :-)

					    -Matt





From c.turner at 199technologies.org  Sun Mar 23 09:48:29 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Sun, 23 Mar 2008 09:48:29 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
Message-ID: <47E6870C.4080709@199technologies.org>

I'm finally getting around to doing 1.12 upgrades, and have setup a 
separate machine to do my bulk package builds / upgrades etc,
so as not to disrupt my 'dev server' while things are being
built / tested

However, this seems kind of wasteful - the only purpose of this machine
is to build packages against a specific release..
And since building packages for a particular release generally requires 
only the userland, appropriate headers and correct 'uname' output - so:

it seems like if spoofing uname is configured inside a jail,
the next (or previous..) release can be installed into a jail and
used for building / testing packages without the overhead of a VM or 
maintaining a separate physical host

I did a quick scan of the tree to see what this would take, and, high 
level, it seems like only the following changes would need to be made:

- update struct jail to add a 'osrelease' string
  (implies bumping 'jail api' to 2?)
- update jail(8) to actually pass this information along
- update sys_uname to test ucred for jailed processes, and
  use the struct jail osrelease if appropriate
- similarly update sysctl kern.osrelease to support jail spoofing
  (if possible - didn't get this far in the research yet)
  could be less of a problem for builds, as I think most things use
 uname(1) ... but good to keep the environment consistent I suppose..
I'm still a bit confused as to how 'osrelease' is defined - everything
I'm finding is showing up as extern char[] .. perhaps this is something 
in the build I'm not familiar with?

also,

is the so-called 'stupid hackery' in sys_uname needed still?

Before I start any coding, does this:

- sound like something useful
- sound like the right approach
Thinking this could have wider useful implications e.g. for pkgbox
& so on -  for example setting up automated bulks w/various combinations 
of pkgsrc and releases, etc.

Cheers,

- Chris





From corecode at fs.ei.tum.de  Sun Mar 23 10:06:38 2008
From: corecode at fs.ei.tum.de (Simon 'corecode' Schubert)
Date: Sun, 23 Mar 2008 10:06:38 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <47E68C74.3080808@fs.ei.tum.de>

Chris Turner wrote:
I did a quick scan of the tree to see what this would take, and, high 
level, it seems like only the following changes would need to be made:
brave investigation.  but you could also simply set UNAME_r :)

sweatshorts % uname -r
1.13.0-DEVELOPMENT
sweatshorts % UNAME_r=1.12-RELEASE uname -r
1.12-RELEASE
I think that's good enough :D

cheers
  simon
--
Serve - BSD     +++  RENT this banner advert  +++    ASCII Ribbon   /"\
Work - Mac      +++  space for low ????????? NOW!1  +++      Campaign     \ /
Party Enjoy Relax   |   http://dragonflybsd.org      Against  HTML   \
Dude 2c 2 the max   !   http://golden-apple.biz       Mail + News   / \




From c.turner at 199technologies.org  Sun Mar 23 10:50:13 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Sun, 23 Mar 2008 10:50:13 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <47E69656.8080605@199technologies.org>

Simon 'corecode' Schubert wrote:
brave investigation.  but you could also simply set UNAME_r :)
Doh! Thanks for the tip!

they should change the phrase from RTFM to 'Carefully RTFM' :)

well.. scratch that change then. 1 less patch to write.

- Chris





From c.turner at 199technologies.org  Sun Mar 23 11:15:52 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Sun, 23 Mar 2008 11:15:52 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <47E69C7C.8010109@199technologies.org>

Chris Turner wrote:
Simon 'corecode' Schubert wrote:
brave investigation.  but you could also simply set UNAME_r :)

for the record - if anyone's interested - adding a line e.g.:

ALL_ENV+= UNAME_r=1.12-RELEASE

to mk.conf looks like it -might- work ..

(unless wants to chime in & verify)





From joerg at britannica.bec.de  Sun Mar 23 11:46:53 2008
From: joerg at britannica.bec.de (Joerg Sonnenberger)
Date: Sun, 23 Mar 2008 11:46:53 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <20080323181428.GA2099@britannica.bec.de>

On Sun, Mar 23, 2008 at 01:41:42PM -0400, Chris Turner wrote:
> they should change the phrase from RTFM to 'Carefully RTFM' :)

RTFMAI -- Read The Fine Manual Again, Idiot.

Joerg




From dillon at apollo.backplane.com  Sun Mar 23 20:05:36 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Sun, 23 Mar 2008 20:05:36 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
Message-ID: <200803240257.m2O2voNH038355@apollo.backplane.com>

    Here's an update on the HAMMER work!

    Current status:

    * Passes all standard filesystem stress tests and buildworld will
      run with a HAMMER /usr/obj.  Large histories are able to accumulate
      without effecting performance.

    * Pruning and reblocking code is in and partially tested, but now needs
      more stringent testing.

    * Full historical access appears to be working but needs testing.
      Note that a sync is still needed to flush dirty cached data prior
      to acquiring a timestamp for the 'snapshot' to be set in stone.
      (dirty data cached in-memory has no historical tags and must be
      committed to physical disk before it can be accessed historically).


    Current bugs:

    * There is one known bug in the standard operations code paths
      that results in an assertion in HAMMER's I/O subsystem.

    * There are probably bugs in the reblocking and/or pruning code.  More
      likely in the reblocking code.


    There are two big-ticket and several little-ticket items left.  HAMMER
    will officially go Alpha when the big-ticket items are done, and beta
    when we get a few of the little-ticket items done.

    Big ticket items left:

    * UNDO (crash recovery) code.  Currently it writes out undo records but
      they are not yet sequenced, buffer writes are not yet ordered, and
      there is no mount-time recovery code yet.

      This is the last item needed before HAMMER can go operational.

    * Filesystem full handling.  Currently no space is reserved for dirty
      cached data so it is possible to create/write files and for HAMMER
      to not have sufficient space left on-disk to flush it.


    Little ticket items:

    * Automated reblocking (currently these functions are manually
      initialized via the hammer utility).

    * I/O clustering and preliminary BMAP op when writing out large files.

    * CRC checking (CRC fields are reserved but not entirely generated yet
      and not yet checked at all).

    * Disaster Recovery filesystem scan.

    * Boot support.

    I expect all of these items and more to be handled by the 2.0 release
    in July.

			    Additional HAMMER capabilities
				(no timeline yet)

    * Adding, removing, and resizing a HAMMER filesystem's backing store.

			Ultimate Goals and working towards them
				(no timeline yet)

    Our ultimate goal with HAMMER and DragonFly in general is to support
    fully cache coherent replication in a multi-machine environment.  This
    involves several steps and networking protocols.

    * Replication of synchronization streams based on the UNDO log.  If
      resynchronizing to a target which is too old a B-Tree scan will
      likely be required.

    * Cache coherency protocols for machine-machine coherency for both
      replicated and remote-HAMMER access.

    I have no time frame for these items yet.  It will depend on how quickly
    HAMMER moves to Alpha and Beta status.  I will say, however, now
    that HAMMER's on-disk format has solidified, that I have a very precise
    understanding of the protocols that will be needed to accomplish fully
    cache coherent remote access for both replicated and non-replicated
    (remote mount style) access.

    And, as you know, fully coherent filesystem access across machines is
    going to be the basis for DragonFly's clustering across said machines.

    In summary, things are progressing very well.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From justin at shiningsilence.com  Sun Mar 23 20:10:13 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Sun, 23 Mar 2008 20:10:13 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <53758.192.168.0.252.1206327873.squirrel@www.shiningsilence.com>

On Sun, March 23, 2008 12:36 pm, Chris Turner wrote:

> it seems like if spoofing uname is configured inside a jail,
> the next (or previous..) release can be installed into a jail and
> used for building / testing packages without the overhead of a VM or
> maintaining a separate physical host

If you don't need a jail to spoof uname, as others posted, you can
installworld into a chroot and build everything you want there using
Joerg's spiffy pbulk.  That's what I'm doing on pkgbox now; I can hand you
my somewhat terse notes if you want.  It would be relatively easy to set
up the configuration you're talking about.





From sepherosa at gmail.com  Sun Mar 23 20:18:20 2008
From: sepherosa at gmail.com (Sepherosa Ziehau)
Date: Sun, 23 Mar 2008 20:18:20 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <ea7b9c170803232012n2f27f893tf1d756d7c9770419@mail.gmail.com>

On Mon, Mar 24, 2008 at 2:14 AM, Joerg Sonnenberger
<joerg at britannica.bec.de> wrote:
> On Sun, Mar 23, 2008 at 01:41:42PM -0400, Chris Turner wrote:
>  > they should change the phrase from RTFM to 'Carefully RTFM' :)
>
>  RTFMAI -- Read The Fine Manual Again, Idiot.

http://leaf.dragonflybsd.org/~sephe/rtfm.jpg

:D

>
>  Joerg
>



-- 
Live Free or Die




From justin at shiningsilence.com  Sun Mar 23 20:38:30 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Sun, 23 Mar 2008 20:38:30 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: GSoC 2008 - mentors signup
Message-ID: <53885.192.168.0.252.1206329503.squirrel@www.shiningsilence.com>

If you are planning to be a mentor for a Summer of Code project, please
sign up here for the mentors mailing list:

http://groups.google.com/group/google-summer-of-code-mentors-list

If you've already signed up, your subscription should be set up tomorrow.





From justin at shiningsilence.com  Sun Mar 23 21:12:01 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Sun, 23 Mar 2008 21:12:01 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: GSoC 2008 - mentors signup
In-Reply-To: <53885.192.168.0.252.1206329503.squirrel@www.shiningsilence.com>
Message-ID: <54025.192.168.0.252.1206331572.squirrel@www.shiningsilence.com>

Also!

If you are a potential mentor and you have not done so yet:

http://code.google.com/soc/mentor_step1.html

Get yourself registered as a mentor for the Summer of Code project.  Once
you are in there, check off DragonFly in the "My Profile" section.

You will need a Google Account if you don't have one:

http://www.google.com/accounts

This will add you to the list of mentors in the Google Summer of Code web
application, so you can review/be attached to projects.

A guide is available if you want more information:

http://groups.google.com/group/google-summer-of-code-announce/web/guide-to-the-gsoc-web-app-for-mentors-and-organization-administrators






From c.turner at 199technologies.org  Mon Mar 24 04:29:28 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Mon, 24 Mar 2008 04:29:28 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <47E78ECE.4070307@199technologies.org>

Justin C. Sherrill wrote:
If you don't need a jail to spoof uname, as others posted, you can
installworld into a chroot and build everything you want there using
Joerg's spiffy pbulk.  That's what I'm doing on pkgbox now; I can hand you
my somewhat terse notes if you want.  It would be relatively easy to set
up the configuration you're talking about.
cheers - I guess I thought incorrectly that something 'special' was 
needed to get the uname to change .. have been using the legacy bulks in 
chroots / jails (for 'same os' builds) as I haven't quite migrated to 
pbulk yet ..

thanks for the help offer - I'll ask if I run into trouble.




From dillon at apollo.backplane.com  Mon Mar 24 08:28:49 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Mon, 24 Mar 2008 08:28:49 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <200803241500.m2OF0CG8043760@apollo.backplane.com>


:http://leaf.dragonflybsd.org/~sephe/rtfm.jpg
:
::D

    Ho!

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From elekktretterr at exemail.com.au  Mon Mar 24 09:10:15 2008
From: elekktretterr at exemail.com.au (Petr Janda)
Date: Mon, 24 Mar 2008 09:10:15 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
In-Reply-To: <200803240257.m2O2voNH038355@apollo.backplane.com>
Message-ID: <200803250138.49775.elekktretterr@exemail.com.au>


>
>     And, as you know, fully coherent filesystem access across machines is
>     going to be the basis for DragonFly's clustering across said machines.
>
>     In summary, things are progressing very well.
>


Hi Matt,
That's good to know things are going so well. Got a question. If memory serves 
me right, initially there was also going to be a thing called ANVIL, I can't 
remember what it was supposed to do and whether its still in your design. 
Could you elaborate a little?

Thanks,
Petr




From dillon at apollo.backplane.com  Mon Mar 24 14:12:11 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Mon, 24 Mar 2008 14:12:11 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
In-Reply-To: <200803240257.m2O2voNH038355@apollo.backplane.com>
Message-ID: <200803242100.m2OL0nWV046868@apollo.backplane.com>


:Hi Matt,
:That's good to know things are going so well. Got a question. If memory serves 
:me right, initially there was also going to be a thing called ANVIL, I can't 
:remember what it was supposed to do and whether its still in your design. 
:Could you elaborate a little?
:
:Thanks,
:Petr

    It's not really in the HAMMER design any more, primarily because HAMMER's
    volume model seems to work fine as-is.  Ultimately something like ANVIL
    (a block storage manager) would prove beneficial to the project but it
    would be treated as a separate project.  HAMMER's redundancy model is
    going to be baesd around replication and clustering.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From tgen at netphreax.net  Mon Mar 24 18:31:37 2008
From: tgen at netphreax.net (Thomas E. Spanjaard)
Date: Mon, 24 Mar 2008 18:31:37 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
In-Reply-To: <200803240257.m2O2voNH038355@apollo.backplane.com>
Message-ID: <47E85337.2070407@netphreax.net>

Matthew Dillon wrote:
    * Full historical access appears to be working but needs testing.
      Note that a sync is still needed to flush dirty cached data prior
      to acquiring a timestamp for the 'snapshot' to be set in stone.
      (dirty data cached in-memory has no historical tags and must be
      committed to physical disk before it can be accessed historically).
Wouldn't making timestamp queries (at least from userland) enforce a 
sync on the volume in question be useful here?
--
        Thomas E. Spanjaard
        tgen at netphreax.net
Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00005.pgp
Type: application/octet-stream
Size: 186 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080324/3077333f/attachment-0004.obj>

From dillon at apollo.backplane.com  Mon Mar 24 20:10:12 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Mon, 24 Mar 2008 20:10:12 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
In-Reply-To: <200803240257.m2O2voNH038355@apollo.backplane.com>
Message-ID: <200803250302.m2P32qLP050160@apollo.backplane.com>


:Wouldn't making timestamp queries (at least from userland) enforce a 
:sync on the volume in question be useful here?
:-- 
:         Thomas E. Spanjaard
:         tgen at netphreax.net

    Making the 'hammer now' command do a sync() is a good idea.  I will
    make that change right now so it doesn't get lost.

    Here's a general overview of the issues involved with having historical
    access to the filesystem:

				----------------

    Recording the timestamps in the in-memory cache, for a finer-grained
    snapshot capability, is doable but has its own issues.  Here's an
    illustration:

    open()  create file
    write() append 4K	(file size now 4K)
    write() append 4K	(file size now 8K)
    write() append 4K	(file size now 12K)
    write() append 4K	(file size now 16K)

    Now NONE of this has gone to disk yet, it's entirely in the in-memory
    cache.  The inode is in the in-memory cache.  The data is stored in
    the buffer cache.  Even the directory entry for the file that we
    just created is still in the in-memory cache (HAMMER caches the raw
    records it intends to commit later on).

    If I wanted to be able to acquire a timestamp between each write and
    'see' a snapshot of the file as of any point in the above sequence,
    then every write would also have to allocate a copy of the inode
    (because it changes size on each write).

    The data has the same problem though with a slightly different example.
    Lets say each write() was a seek-write, overwriting the previous data.
    Now with every write() I would have to allocate a copy of the data
    being overwritten.  This is complicated by the fact that the buffer
    cache has no clue about 'historical' accesses, so I would not be able
    to use the buffer cache to cache the data.

    There's also another problem and that is with the efficiency of the
    topology on-disk.  Even if I maintained all the copies of the inode
    and all the copies of the data in-memory, I would still have to sync
    all those copies to disk in order for things to remain historically
    coherent (whether it be in-cache or on-disk).  This would result in
    hundreds or even thousands of copies of the inode on-disk, not to
    mention potentially many copies of the data.

    I just don't want to do that right now, at least not as a default.  A
    lot of performance would be lost.  Hence a sync() is needed if
    you want to create a demark which you can accurately snapshot.

				-------------

    Here's a quick synopsis of how the cache would operate in a clustered
    filesystem:

    In order to properly integrate with in-memory caches, a wider cache
    coherency infrastructure is needed between machines such that
    modifications made on one machine proactively invalidate those
    protions of the cache(s) on other machines.  At the same time, any
    'dirty' cache data, for example when a file is created or written to,
    must lock the cache space in question on all other machines.
    The cache space in this case is not just the file data, but also the
    related namespaces (for creations, deletions, and renames).  Attempts
    to access locked spaces from other machines in the cluster would have
    to force a flush to the filesystem backing store and lower the cache
    states for the effected information on the original machine from dirty
    to shared-read-only.

    It will be easiest to integrate the cache coherency information into
    the buffer cache and namecache themselves.  Once a machine has dirtied
    an in-memory cache element... for example part of the namespace when
    creating a file or chunks of data written within a file, that machine
    must have a free hand to make further modifications to the cache spaces
    involved without further interaction with other machines.

				-------------

    Now, if you think of those two major elements you can see that they
    actually fit together quite well.  If I were to attempt to maintain
    transactional coherency on a per-system-call basis then the cache
    granularity between machines would have to be much, much smaller then
    our current in-memory caching elements provide.  That would become
    a really nasty coding problem.  So I don't even want to begin to
    complate transactional coherency at a finer-grain then sync() or
    fsync() until long after we actually have clustering working.

						-Matt





From elekktretterr at exemail.com.au  Mon Mar 24 21:56:58 2008
From: elekktretterr at exemail.com.au (Petr Janda)
Date: Mon, 24 Mar 2008 21:56:58 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
In-Reply-To: <200803240257.m2O2voNH038355@apollo.backplane.com>
Message-ID: <200803251516.16407.elekktretterr@exemail.com.au>

So is it needed to run hammer now in order to "create" a snapshot? What would 
I do in situation like this: got a hammer filesystem and couple of the files 
change on day to day basis. Then a week later I needed to access one of the 
files, in exactly the state they were 7 days ago.

Cheers,
Petr




From dillon at apollo.backplane.com  Mon Mar 24 22:34:15 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Mon, 24 Mar 2008 22:34:15 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
In-Reply-To: <200803240257.m2O2voNH038355@apollo.backplane.com>
Message-ID: <200803250526.m2P5QZ5X051081@apollo.backplane.com>


:So is it needed to run hammer now in order to "create" a snapshot? What would 
:I do in situation like this: got a hammer filesystem and couple of the files 
:change on day to day basis. Then a week later I needed to access one of the 
:files, in exactly the state they were 7 days ago.
:
:Cheers,
:Petr

    No, you do not have to run 'hammer now' to create a snapshot.  The
    kernel syncs all filesystems every 30 seconds, so if you do nothing
    at all you get a snapshot granularity of 30 seconds.

    Where you would use 'hammer now' is if you wanted the most current
    snapshot possible for the purpose of, say, backing up your filesystem
    to another machine.  You might do something like this:

	set timestamp = `hammer now`
	cpdup /mountpoint/@@$timestamp targethost:/somepath

    But if you didn't care about that you could just go back far enough
    that you get a stable historical view... e.g. go back 1 minute and you
    would have a stable view into your filesystem.

	set timestamp = `hammer stamp 60s`		<------ doesn't sync
	cpdup /mountpoint/@@$timestamp targethost:/somepath


    Ultimately the idea of managing filesystems this way is to still do
    regular backups from your production machine to your backup machine
    (ultimately by way of replication), with both running HAMMER, but only
    retain a limited amount of history on the production box.  You might
    desire to retain only one week's worth of history on the production box,
    retain one month's history on your local backup box, and retain a very
    granular one year's worth of history on your remote backup box.

    Come to think of it, I should add some more directives to the
    'hammer prune' command to make that easier to specify.

    Until I implement a live replication 'feed' the minimum granularity on
    the backup box will be how often you do your backups (e.g. once a day),
    and you can prune it into more granular forms from that starting point.
    Once we have a live replication feed the backup box will have the same
    30-second granularity that the production machine has.

    A major bullet point for this style of management is that the retention
    policy on the various boxes can be different even though they are
    all slaved off the same production filesystem.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From justin at shiningsilence.com  Tue Mar 25 05:58:49 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Tue, 25 Mar 2008 05:58:49 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: SoC - student signups
Message-ID: <58180.65.106.147.226.1206449676.squirrel@www.shiningsilence.com>

Here's a quick link roundup:

Are you a student?  Put in your application for a Google Summer of Code here:

http://code.google.com/soc/2008/student_signup.html

Student guide:
http://groups.google.com/group/google-summer-of-code-announce/web/guide-to-the-gsoc-web-app-for-student-applicants

Are you a mentor?  (That means hasso, hsu, sephe, matthias, TGEN, and
corecode right now)

Student proposals will show up on the mentor page, linked below.  You will
get to rate them, and take the one(s) that you want to mentor.

Mentor page:
http://code.google.com/soc/2008/mentor_home.html
Mentor guide:
http://groups.google.com/group/google-summer-of-code-announce/web/guide-to-the-gsoc-web-app-for-mentors-and-organization-administrators

If you are a mentor and are communicating with potential students, send
them the URLs above for student signup and the student guide; work with
them if they ask for advice on what to say in the application.  They can
resubmit up to 20 times if they want to correct it.

Deadline is March 31st.






From noah.yan at gmail.com  Thu Mar 27 20:17:48 2008
From: noah.yan at gmail.com (Yonghong Yan)
Date: Thu, 27 Mar 2008 20:17:48 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: About DFBSD.64
In-Reply-To: <47EB0B5B.5020802@gmail.com>
Message-ID: <59521b110803272015y1cc8cc39uc93f154ed36e0505@mail.gmail.com>

thanks for your interest.

I owe to everybody for any update or work in the past four months. so
many things happen in my work and my family (they are all good:) and
keep me extremely busy. But i am not leaving and will be back on this
soon.

the latest sources are in http://repo.or.cz/w/dragonfly/port-amd64.git
, I did have a compiled kernel long time before, but I have to break
it to work on the pmap. you can pick up from there. TGEN will help you
a lot, also keep me posted too, if you like.

Noah

On Wed, Mar 26, 2008 at 9:50 PM, Sdavtaker <sdavtaker at gmail.com> wrote:
> Hello,
>  Im applying to GSoC to work in the x64 version of DFBSD with TGEN, i
>  found some work already done in the repository and some mails in the
>  archive from you.
>  I was wondering if you already had a working compiled kernel in AMD64
>  machine and what was not working yet to continue that work.
>  Thanks for any info.
>  Sdav
>




From dillon at apollo.backplane.com  Sat Mar 29 13:27:43 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Sat, 29 Mar 2008 13:27:43 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 29-Mar-2008
Message-ID: <200803292022.m2TKMLGe004942@apollo.backplane.com>

    Good progress continues to be made.  HAMMER survived acting as my
    LAN backup machine (in full historical mode) for almost a week before
    it hit an assertion.  I've fixed that issue and believe that the core
    filesystem implementation code is now 'very stable'.

    Note that the recent commit will result in many more 'hammer_lock_ex:'
    messages on the console then you may have previously observed.  This is
    due to the way object id's are allocated in the face of parallel 
    modifications to the filesystem, resulting in too much locality of
    reference in the B-Tree.  I do intend to improve it.

    I am still working on the two major items needed before HAMMER can be
    declared operational, those being the filesystem full handling and the
    undo/recovery-on-mount code.  These are the last 'hard' bits left in
    the design.

    With exception to filling up the filesystem, which *will* create a mess,
    and noting that no crash recovery code exists yet (so you have to newfs
    it if you crash), I'd appreciate it if interested parties could test
    the other functions of the filesystem, in particular the pruning and
    reblocking functions (man hammer), and the historical access functions.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From dillon at apollo.backplane.com  Sun Mar 30 15:11:03 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Sun, 30 Mar 2008 15:11:03 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Need ideas on how to solve an st_ino/st_dev test issue for HAMMER.
Message-ID: <200803302207.m2UM7BCp016402@apollo.backplane.com>

    Here's the problem, given historical access softlinks as shown below:

test30# ls -lda cra*
drwxr-xr-x  1 root  wheel  Mar 29 13:04 crater
lrwxr-xr-x  1 root  wheel  Mar 29 18:57 crater.20080329 -> crater@@0x47eef383
lrwxr-xr-x  1 root  wheel  Mar 30 01:24 crater.20080330 -> crater@@0x47ef4e29
-rw-r--r--  2 root  wheel  Mar 30 01:24 crater.log

    The problem is that if I do this:

    diff -r crater.20080329/var/log crater.20080330/var/log

    Diff just returns without actually diffing anything.  The reason is
    because diff checks st_ino and st_dev and believes the directories/files
    to be identical because they match.

    I considered munging the inode number for historical accesses, but
    that would seriously break NFS exports which try to access historical
    files and directories.  Right now NFS *is* able to distinguish between
    the two because NFS handles are 128-bit-wide entities, so I can encode
    the as-of transaction id as part of the filehandle.  But userland
    programs only have access to a 64-bit-wide inode so userland still
    believes the files to be identical.

    st_dev is only 32 bits, carefully munging it is an option if we
    could figure out a way to do it, but I'd rather not.

    I am considering using st_gen but then we'd have to patch third
    party software to test st_gen along with everything else.  This may
    be the only workable solution, though, and only a few programs would
    need to be patched.  st_gen is only 32 bits but it would solve the
    problem as we would be able to use all 32 bits.

    If anyone has any bright ideas, including 'leave it alone', I'm all
    ears.

						-Matt





From justin at shiningsilence.com  Mon Mar 31 10:40:42 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Mon, 31 Mar 2008 10:40:42 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: SoC student applications due by 5PM PDT tomorrow
In-Reply-To: <1942.192.168.0.242.1206930479.squirrel@www.shiningsilence.com>
Message-ID: <11892.67.108.184.175.1206984967.squirrel@www.shiningsilence.com>

On Sun, March 30, 2008 10:27 pm, Justin C. Sherrill wrote:
> SoC students:
>
> If you have an application to submit for DragonFly/Summer of Code, please
> do so by 17:00 Pacific time on the 31st - that's tomorrow, at least for
> me.

The deadline for student proposals has been extended to April 7th; all
other dates move forward one week to acommodate.

This is a good time to update existing applications or submit new ones. 
Talk to your (potential) mentors if you are curious.






From nthery at gmail.com  Mon Mar 31 11:29:49 2008
From: nthery at gmail.com (Nicolas Thery)
Date: Mon, 31 Mar 2008 11:29:49 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
Message-ID: <64fc43b0803311126na7d0b27obaa9d35bac6d32ee@mail.gmail.com>

Hello,

Now that the release is over, I'll try to get rid of zones and migrate
allocations to objcache.

Here is a 1st patch that migrate struct proc.  I'll commit it in a
couple of days if nobody objects.

I'm also implementing a way to monitor objcache statistics.  So far,
I've hacked sth similar to
sysctl vm.zone: stats are returned in one giant string, one line per
cache.  That's simple but ugly and hard to read because there are
quite a few stats per cache.

So I'm thinking about implementing a small tool, ocstat, that extracts
stats from sysctl the way ps(1) does (thru libkvm iirc) and formats it
in various ways.  What do you think?

Cheers,
Nicolas

Index: src2/sys/kern/kern_exit.c
===================================================================
--- src2.orig/sys/kern/kern_exit.c	2008-03-31 08:05:59.139796000 +0200
+++ src2/sys/kern/kern_exit.c	2008-03-31 10:31:39.000000000 +0200
@@ -834,7 +834,7 @@ loop:
 			}

 			vm_waitproc(p);
-			zfree(proc_zone, p);
+			objcache_put(proc_cache, p);
 			nprocs--;
 			return (0);
 		}
Index: src2/sys/kern/kern_proc.c
===================================================================
--- src2.orig/sys/kern/kern_proc.c	2008-03-31 08:05:59.139918000 +0200
+++ src2/sys/kern/kern_proc.c	2008-03-31 10:31:39.000000000 +0200
@@ -84,7 +84,7 @@ u_long pgrphash;
 struct proclist allproc;
 struct proclist zombproc;
 struct spinlock allproc_spin;
-vm_zone_t proc_zone;
+struct objcache* proc_cache;
 vm_zone_t lwp_zone;
 vm_zone_t thread_zone;

@@ -131,7 +131,7 @@ procinit(void)
 	spin_init(&allproc_spin);
 	pidhashtbl = hashinit(maxproc / 4, M_PROC, &pidhash);
 	pgrphashtbl = hashinit(maxproc / 4, M_PROC, &pgrphash);
-	proc_zone = zinit("PROC", sizeof (struct proc), 0, 0, 5);
+	proc_cache = objcache_create_simple(M_PROC, sizeof(struct proc));
 	lwp_zone = zinit("LWP", sizeof (struct lwp), 0, 0, 5);
 	thread_zone = zinit("THREAD", sizeof (struct thread), 0, 0, 5);
 	uihashinit();
Index: src2/sys/sys/proc.h
===================================================================
--- src2.orig/sys/sys/proc.h	2008-03-31 08:05:59.140325000 +0200
+++ src2/sys/sys/proc.h	2008-03-31 10:31:39.000000000 +0200
@@ -473,7 +473,7 @@ struct proc *zpfind (pid_t);	/* Find zom
 struct vm_zone;
 struct globaldata;
 struct lwp_params;
-extern struct vm_zone *proc_zone;
+extern struct objcache *proc_cache;
 extern struct vm_zone *lwp_zone;

 int	enterpgrp (struct proc *p, pid_t pgid, int mksess);
Index: src2/sys/kern/kern_fork.c
===================================================================
--- src2.orig/sys/kern/kern_fork.c	2008-03-31 08:05:59.140042000 +0200
+++ src2/sys/kern/kern_fork.c	2008-03-31 10:31:39.000000000 +0200
@@ -332,7 +332,7 @@ fork1(struct lwp *lp1, int flags, struct
 	}

 	/* Allocate new proc. */
-	p2 = zalloc(proc_zone);
+	p2 = objcache_get(proc_cache, M_WAITOK);
 	bzero(p2, sizeof(*p2));

 	/*




From hsu at dragonflybsd.org  Mon Mar 31 11:44:34 2008
From: hsu at dragonflybsd.org (Jeffrey Hsu)
Date: Mon, 31 Mar 2008 11:44:34 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <64fc43b0803311126na7d0b27obaa9d35bac6d32ee@mail.gmail.com>
Message-ID: <200803311841.m2VIfQAI007579@nlpi001.prodigy.net>

The object cache is not a general-purpose memory allocator.  It's a cache of
pre-initialized objects.  Are the significant portions of the proc structure
that can be restored to initialized state on object puts?  If not, it's best
to just use a general-purpose memory allocator.

								Jeffrey




From corecode at fs.ei.tum.de  Mon Mar 31 12:07:02 2008
From: corecode at fs.ei.tum.de (Simon 'corecode' Schubert)
Date: Mon, 31 Mar 2008 12:07:02 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <200803311841.m2VIfQAI007579@nlpi001.prodigy.net>
Message-ID: <47F1357B.1070302@fs.ei.tum.de>

Jeffrey Hsu wrote:
> The object cache is not a general-purpose memory allocator.  It's a cache of
> pre-initialized objects.  Are the significant portions of the proc structure
> that can be restored to initialized state on object puts?  If not, it's best
> to just use a general-purpose memory allocator.

Why?  What's the loss if we use the object cache to allocate struct procs?

cheers
  simon

Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00006.pgp
Type: application/octet-stream
Size: 252 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080331/a4a24314/attachment-0004.obj>

From nthery at gmail.com  Mon Mar 31 12:17:03 2008
From: nthery at gmail.com (Nicolas Thery)
Date: Mon, 31 Mar 2008 12:17:03 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <nthery@gmail.com>
Message-ID: <64fc43b0803311214u7da6bbb8xaf971de1a80e7258@mail.gmail.com>

2008/3/31, Jeffrey Hsu <hsu at dragonflybsd.org>:
> The object cache is not a general-purpose memory allocator.  It's a cache of
>  pre-initialized objects.  Are the significant portions of the proc structure
>  that can be restored to initialized state on object puts?  If not, it's best
>  to just use a general-purpose memory allocator.

Well, I haven't checked this yet.  I planned to do this in a second
step after getting rid of zones.

I thought that even without  the pre-initialization part, objcache has
the advantage
of pre-allocating set of objects (as zones) and is additionally
mp-safe (contrary to zones and, granted, as malloc()).   The latter
may be interesting as we talk of improving MP support.

Cheers,
Nicolas




From dillon at apollo.backplane.com  Mon Mar 31 12:23:40 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Mon, 31 Mar 2008 12:23:40 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <200803311841.m2VIfQAI007579@nlpi001.prodigy.net>
Message-ID: <200803311921.m2VJLITB027669@apollo.backplane.com>

    I both agree and disagree with Jeff.  I think the only *disadvantage*
    to using objcache for struct proc is that objcache must cache a minimum
    number of free structures to be efficient so the overall kernel memory
    use would be a bit greater verses uses kmalloc().  But I agree with Jeff
    in that objcache's biggest advantage is that you can keep structural state
    intact and struct proc might not be a good candidate (yet).

    What I suggest is that you convert struct proc from zone to kmalloc
    first, and then look into a possible objcache adaptation.  kmalloc
    is not slow.. it's a very fast allocator.  Objcache is probably a tad
    faster but not by much.  Where objcache really wins is in not having
    to completey reinitialize the allocated structures.

    Over the years I've removed (I think) all the dependancies on requiring
    the proc structure to be in stable memory so I believe it can be moved to
    kmalloc/objcache now without any major pain.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From corecode at fs.ei.tum.de  Mon Mar 31 12:37:40 2008
From: corecode at fs.ei.tum.de (Simon 'corecode' Schubert)
Date: Mon, 31 Mar 2008 12:37:40 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: SoC student applications due by 5PM PDT tomorrow
In-Reply-To: <1942.192.168.0.242.1206930479.squirrel@www.shiningsilence.com>
Message-ID: <47F13CDA.6010703@fs.ei.tum.de>

Justin C. Sherrill wrote:
> On Sun, March 30, 2008 10:27 pm, Justin C. Sherrill wrote:
>> SoC students:
>>
>> If you have an application to submit for DragonFly/Summer of Code, please
>> do so by 17:00 Pacific time on the 31st - that's tomorrow, at least for
>> me.
> The deadline for student proposals has been extended to April 7th; all
> other dates move forward one week to acommodate.

This is very good.

Some more ideas for eager students (we want to keep the ratio, right?):

Enhance the FreeBSD/DragonFly sound infrastructure to support surround
sound/multichannel output.

Update sound drivers to support S/PDIF output.

Make the sound infrastructure OSSv4 compatible (there was a SoC at
FreeBSD last year or so)


of course only if it doesn't exist already :)

cheers
  simon


Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00007.pgp
Type: application/octet-stream
Size: 252 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080331/6da61cff/attachment-0004.obj>

From corecode at fs.ei.tum.de  Mon Mar 31 12:41:30 2008
From: corecode at fs.ei.tum.de (Simon 'corecode' Schubert)
Date: Mon, 31 Mar 2008 12:41:30 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <200803311841.m2VIfQAI007579@nlpi001.prodigy.net>
Message-ID: <47F13DE4.10205@fs.ei.tum.de>

Matthew Dillon wrote:
>     What I suggest is that you convert struct proc from zone to kmalloc
>     first, and then look into a possible objcache adaptation.  kmalloc
>     is not slow.. it's a very fast allocator.  Objcache is probably a tad
>     faster but not by much.  Where objcache really wins is in not having
>     to completey reinitialize the allocated structures.

Could we please not move to kmalloc, but instead try to move all fast
path allocations to objcache?  I don't like the idea of allocating
everything with kmalloc.  Caching struct procs is not a bad thing itself.

cheers
  simon


Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00008.pgp
Type: application/octet-stream
Size: 252 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080331/ac328c08/attachment-0004.obj>

From hsu at FreeBSD.org  Mon Mar 31 12:59:05 2008
From: hsu at FreeBSD.org (Jeffrey Hsu)
Date: Mon, 31 Mar 2008 12:59:05 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <47F1357B.1070302@fs.ei.tum.de>
Message-ID: <200803311920.m2VJK5Ln018015@nlpi015.prodigy.net>

The object cache sits on top of a general-purpose memory allocator such
as kmalloc or zalloc and provides pre-initialized object caching functionality.
If you're not going to use the object caching functionality, you can just
call the underlying memory allocator directly.

							Jeffrey




From dillon at apollo.backplane.com  Mon Mar 31 16:17:19 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Mon, 31 Mar 2008 16:17:19 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <200803311841.m2VIfQAI007579@nlpi001.prodigy.net>
Message-ID: <200803312311.m2VNBumd029866@apollo.backplane.com>

:Could we please not move to kmalloc, but instead try to move all fast
:path allocations to objcache?  I don't like the idea of allocating
:everything with kmalloc.  Caching struct procs is not a bad thing itself.=
:
:
:cheers
:  simon

    I will state for the record that I'm fine with either objcache or
    kmalloc.  I agree with Jeff that using objcache for struct proc
    probably isn't necessary but I also agree that it would not hurt either,
    and if the intent is to optimize the initialization of the proc
    structure in the future then moving to objcache now would save us
    from having to do it later.

    So whichever method Nicolas wants to use is fine with me.

						-Matt




From hsu at dragonflybsd.org  Mon Mar 31 19:22:47 2008
From: hsu at dragonflybsd.org (Jeffrey Hsu)
Date: Mon, 31 Mar 2008 19:22:47 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <64fc43b0803311214u7da6bbb8xaf971de1a80e7258@mail.gmail.com>
Message-ID: <200804010218.m312IVUq003624@nlpi043.prodigy.net>

  >> Are there significant portions of the proc structure
  >> that can be restored to initialized state on object puts?

  > I planned to do this in a second step after getting rid of zones.

I'll all in favor of making more use of caching pre-initialized objects, so
if this is your objective, then please go ahead.  It's just that I'd convert
over to the object cache in one step.

  > I thought that even without  the pre-initialization part, objcache has
  > the advantage of pre-allocating set of objects (as zones) and is additionally
  > mp-safe (contrary to zones and, granted, as malloc()).

Well, the zone allocator is MP-safe.  It's not hard to lock up the places that
manipulate the linked-list of free items. Look for uses of the zlock field.

								Jeffrey




From tgen at netphreax.net  Sat Mar  1 12:57:53 2008
From: tgen at netphreax.net (Thomas E. Spanjaard)
Date: Sat, 1 Mar 2008 12:57:53 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: [Fwd: Project Support Open Source: $50 donation to support you      project]
In-Reply-To: <2468.192.168.0.242.1204346451.squirrel@www.shiningsilence.com>
Message-ID: <47C9C1B7.50203@netphreax.net>

Justin C. Sherrill wrote:
The "donation" happens after you place an "acknowledgement" on an open
source project's web page.  I'm putting those words in scare quotes
because I think it's a "payment" for an "advertisement".  The supplied
link has nothing to do with DragonFly, to say the least.

<a href="http://www.2insure4less.com /" title="We support FOSS software
projects.">Online Insurance Quotes</a>
To think our souls are only worth $50...
--
        Thomas E. Spanjaard
        tgen at netphreax.net
Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00000.pgp
Type: application/octet-stream
Size: 186 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080301/0d61e240/attachment-0005.obj>

From c.turner at 199technologies.org  Sat Mar  1 17:52:31 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Sat, 1 Mar 2008 17:52:31 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Misc. ACPI / suspend
Message-ID: <47CA073B.6020106@199technologies.org>

Wondering if anyone more well versed in the ACPI implementation could
comment on the applicability of:
http://lkml.org/lkml/2007/4/6/69

w/r/t the current state of the art in Dfly

(or BSD's in general)

Cheers!

- Chris




From elekktretterr at exemail.com.au  Sun Mar  2 00:41:25 2008
From: elekktretterr at exemail.com.au (Petr Janda)
Date: Sun, 2 Mar 2008 00:41:25 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: CARP question
Message-ID: <200803021934.21669.elekktretterr@exemail.com.au>

So Ive setup CARP on 2 DF-based mailservers. Installation went fine. Box 1 has 
adskew of 0 therefore it is the MASTER. Box 2 has adskew of 254, therefore is 
BACKUP.  If i down the carp0 interface on Box 1, then Box 2 carp interface 
gets promoted to MASTER. Then I up the carp interface on Box 1, logically Box 
2 should become BACKUP again as Box 1 becomes MASTER due to adskew set to 0.

However it doesnt happen. When carp0 interface on Box 1 is upped it becomes a 
BACKUP, not a MASTER even though according to adskew it should be MASTER.

What is the desired behaviour?

Cheers
Petr




From qhwt+dfly at les.ath.cx  Sun Mar  2 02:50:14 2008
From: qhwt+dfly at les.ath.cx (YONETANI Tomokazu)
Date: Sun, 2 Mar 2008 02:50:14 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: panic: assertion: hammer_btree_cmp(cursor->left_bound,	&cursor->node->ondisk->elms[0].leaf.base) <= 0 in btree_split_leaf
In-Reply-To: <200802232204.m1NM4cxd046264@apollo.backplane.com>
Message-ID: <20080302104554.GA22813@les.ath.cx>

Hi.
While trying to find a procedure to reliably reproduce the panic
I reported last time, I caught a different panic (uploaded at
 ~y0netan1/crash/9/ on my leaf account).  I wrote the following shell
script (make sure to edit variables DISKS and MOUNTPT before using this
script or it may trash your system):
  #!/bin/sh -ex
  DISKS="/dev/ad0s1f"
  MOUNTPT=/mnt/HAMMER

  cd /
  newfs_hammer -L TEST $DISKS
  for i in `seq 1 100`; do
	  mount_hammer $DISKS $MOUNTPT
	  /bin/rm -rf $MOUNTPT/??
	  (set +x; for x in `seq 1 10000`; do echo -n > $MOUNTPT/$x; done)
	  umount $MOUNTPT
  done

And the panic is triggered by rm command.
I'll try to see if it's possible to reproduce the last one without
unmounting then mounting the HAMMER fs.

Cheers.




From dillon at apollo.backplane.com  Sun Mar  2 13:25:33 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Sun, 2 Mar 2008 13:25:33 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: panic: assertion: hammer_btree_cmp(cursor->left_bound,	&cursor->node->ondisk->elms[0].leaf.base) <= 0 in btree_split_leaf
In-Reply-To: <200802232204.m1NM4cxd046264@apollo.backplane.com>
Message-ID: <200803022119.m22LJRCY037076@apollo.backplane.com>


:Hi.
:While trying to find a procedure to reliably reproduce the panic
:I reported last time, I caught a different panic (uploaded at
: ~y0netan1/crash/9/ on my leaf account).  I wrote the following shell
:script (make sure to edit variables DISKS and MOUNTPT before using this
:script or it may trash your system):

(from the core)

panic: assertion: node->lock.refs == 0 && node->ondisk == NULL in hammer_flush_buffer_nodes

    Yah, I've seen this failure.  Add a sync or two before the umount and
    tell me if it still occurs.  It's either a node reference leak somewhere
    or it is a race between bufdaemon and umount.  The assertions are really
    strict there precisely to catch those sorts of cases.

    Also note that the code to deal with a full HAMMMER filesystem has not
    been written yet (The failure you are reporting is unrelated to a full
    HAMMER filesystem, though, just mentioning it).

						-Matt





From dillon at apollo.backplane.com  Sun Mar  2 13:29:03 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Sun, 2 Mar 2008 13:29:03 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Misc. ACPI / suspend
In-Reply-To: <47CA073B.6020106@199technologies.org>
Message-ID: <200803022126.m22LQbfI037188@apollo.backplane.com>


:Wondering if anyone more well versed in the ACPI implementation could
:comment on the applicability of:
:
:http://lkml.org/lkml/2007/4/6/69
:
:w/r/t the current state of the art in Dfly
:
:(or BSD's in general)
:
:Cheers!
:
:- Chris

    I really have no idea re: this.  Suspension in general is not well
    supported by any of the BSDs.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From dillon at apollo.backplane.com  Sun Mar  2 13:34:05 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Sun, 2 Mar 2008 13:34:05 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: [Fwd: Project Support Open Source: $50 donation to support you      project]
In-Reply-To: <2468.192.168.0.242.1204346451.squirrel@www.shiningsilence.com>
Message-ID: <200803022131.m22LVOe9037250@apollo.backplane.com>

:..
:source project's web page.  I'm putting those words in scare quotes
:because I think it's a "payment" for an "advertisement".  The supplied
:link has nothing to do with DragonFly, to say the least.
:
:I don't think this is a good idea, obviously, and replied to that effect. 
:However, I wanted to put this on a DragonFly list, in part to show this
:strange thing, and in part because I'm not comfortable making
:administrative decisions on behalf of the Project without being open as
:possible about it.

    It doesn't really cry out to me either.

						-Matt





From wbh at conducive.org  Sun Mar  2 20:36:32 2008
From: wbh at conducive.org (Bill Hacker)
Date: Mon, 03 Mar 2008 04:36:32 +0000
Subject: Misc. ACPI / suspend
In-Reply-To: <47CA073B.6020106@199technologies.org>
Message-ID: <47cb8050$0$855$415eb37d@crater_reader.dragonflybsd.org>

Matthew Dillon wrote:
:Wondering if anyone more well versed in the ACPI implementation could
:comment on the applicability of:
:
:http://lkml.org/lkml/2007/4/6/69
:
:w/r/t the current state of the art in Dfly
:
:(or BSD's in general)
:
:Cheers!
:
:- Chris
    I really have no idea re: this.  Suspension in general is not well
    supported by any of the BSDs.
					-Matt
					Matthew Dillon 
					<dillon at backplane.com>


. . and there seems to be a bit of a 'Catch 22' there in any case.

If the BIOS can alter 'stuff' out of site of the OS it is parking, what 
does the existence of such a 'feature' do to a(ny) security model?

Seems to at least beg creating the option of setting a flag to 
specifically *prevent* suspend-to-disk/hibernation (and/or force a 
reboot on wake-up).

Just because one is paranoid....  etc

Bill





From matthias at dragonflybsd.org  Tue Mar  4 02:30:52 2008
From: matthias at dragonflybsd.org (Matthias Schmidt)
Date: Tue, 4 Mar 2008 02:30:52 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
Message-ID: <20080304102335.GI9833@staatsfeind.org>

Hi,

Google just announced its Summer of Code for 2008:

	http://code.google.com/soc/2008/

I think this would be a great opportunity for DragonFly to participate
as a mentoring organisation.  We could attract new developers and could
get code/work done.  Looking at the SoC results of the other BSDs most
of their projects were a success.  Of course, not all, but a reasonable
percentage.  See [1] and [2].

It is some extra work for us, but IMO the benefits outweigh the extra
work.  And yes, I would volunteer as a mentor.  What do others
(developers) think?  Any more volunteers? :)

Some project ideas that come into my mind.  More ideas are listed in the
wiki:  http://wiki.dragonflybsd.org/index.cgi/ProjectsPage

 * Fix all remaining bugs in dma(8) and implement all missing features
 * Add a driver for newer Intel Wireless cards (I think sephe@ would
   love that :)
 * Bring our ACPI stuff in shape.  Maybe suspend2disk ...

 * [Add your own thoughts here]

Cheers,

	Matthias

PS: I don't want to create a bikeshed here whether you like the SoC or
not :)

[1] http://code.google.com/soc/2007/freebsd/about.html
[2] http://code.google.com/soc/2007/netbsd/about.html




From corecode at fs.ei.tum.de  Tue Mar  4 04:46:14 2008
From: corecode at fs.ei.tum.de (Simon 'corecode' Schubert)
Date: Tue, 4 Mar 2008 04:46:14 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47CD4386.1000704@fs.ei.tum.de>

Matthias Schmidt wrote:
>  * [Add your own thoughts here]

MP lock removal for network stack

and for the system  (first profile, find hot spots, fix hot spots, repeat)

cheers
  simon




From c.turner at 199technologies.org  Tue Mar  4 06:02:20 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Tue, 4 Mar 2008 06:02:20 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47CD551E.1040604@199technologies.org>

Matthias Schmidt wrote:
Some project ideas that come into my mind.  More ideas are listed in the
wiki:  http://wiki.dragonflybsd.org/index.cgi/ProjectsPage
+1 acpi
+1 interrupt routing
+1 SMP / giant removal
+1 pf synchup with openbsd
though there are several others on the page that are good..

need to dig up my wiki login and place appropriately..

also: thinking the ZFS port should be removed from the page - makes 
sense to everyone else? (e.g. fragments effort w/r/t hammer)





From tgen at netphreax.net  Tue Mar  4 06:54:31 2008
From: tgen at netphreax.net (Thomas E. Spanjaard)
Date: Tue, 4 Mar 2008 06:54:31 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47CD615F.8010209@netphreax.net>

Matthias Schmidt wrote:
Google just announced its Summer of Code for 2008:

 * [Add your own thoughts here]
x86-64 port :).
--
        Thomas E. Spanjaard
        tgen at netphreax.net
Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00001.pgp
Type: application/octet-stream
Size: 186 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080304/0d921000/attachment-0005.obj>

From rdivacky at FreeBSD.org  Tue Mar  4 07:07:03 2008
From: rdivacky at FreeBSD.org (Roman Divacky)
Date: Tue, 4 Mar 2008 07:07:03 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <20080304150255.GA8831@freebsd.org>

On Tue, Mar 04, 2008 at 02:49:03PM +0000, Thomas E. Spanjaard wrote:
> Matthias Schmidt wrote:
> >Google just announced its Summer of Code for 2008:
> >
> > * [Add your own thoughts here]
> 
> x86-64 port :).

all those ideas are great and needed etc. but keep in
mind that the projects should be doable by students
who might see dfly for the very first time.

don't overestimate whats possible and select projects
that look realistic

Roman Divacky (former SoC student)




From justin at shiningsilence.com  Tue Mar  4 08:32:56 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Tue, 4 Mar 2008 08:32:56 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <60322.65.106.147.226.1204648095.squirrel@www.shiningsilence.com>

On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
> Hi,
>
> Google just announced its Summer of Code for 2008:
>
> 	http://code.google.com/soc/2008/
>
> I think this would be a great opportunity for DragonFly to participate
> as a mentoring organisation.  We could attract new developers and could
> get code/work done.  Looking at the SoC results of the other BSDs most
> of their projects were a success.  Of course, not all, but a reasonable
> percentage.  See [1] and [2].

We've applied in previous years - Jeff Hsu did one year, and I put
together the application last year.  The hardest thing to find was
students (and they are the thing that helps SoC applications a lot, I
think).

Any student volunteers?  We have mentors.





From rluciani at gmail.com  Tue Mar  4 09:38:29 2008
From: rluciani at gmail.com (Robert Luciani)
Date: Tue, 04 Mar 2008 18:38:29 +0100
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47cd8915$0$854$415eb37d@crater_reader.dragonflybsd.org>

Justin C. Sherrill wrote:
> On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
>> Hi,
>>
>> Google just announced its Summer of Code for 2008:
>>
>> 	http://code.google.com/soc/2008/
>>
>> I think this would be a great opportunity for DragonFly to participate
>> as a mentoring organisation.  We could attract new developers and could
>> get code/work done.  Looking at the SoC results of the other BSDs most
>> of their projects were a success.  Of course, not all, but a reasonable
>> percentage.  See [1] and [2].
> 
> We've applied in previous years - Jeff Hsu did one year, and I put
> together the application last year.  The hardest thing to find was
> students (and they are the thing that helps SoC applications a lot, I
> think).
> 
> Any student volunteers?  We have mentors.
> 

bingo

-- 
Robert Luciani
Chalmers University of Technology, SWE
Department of Computer Science and Engineering
http://www.rluciani.com/public.key




From sdavtaker at gmail.com  Tue Mar  4 09:31:08 2008
From: sdavtaker at gmail.com (=?UTF-8?Q?Sd=C3=A4vtaker?=)
Date: Tue, 4 Mar 2008 09:31:08 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <c37d69f60803040926k206218a3kb8496d0cd18148bd@mail.gmail.com>

If you mentor, i will apply for coder :-)
Still in last year of university. :-)
Sdav

On Tue, Mar 4, 2008 at 1:28 PM, Justin C. Sherrill
<justin at shiningsilence.com> wrote:
> On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
>  > Hi,
>  >
>  > Google just announced its Summer of Code for 2008:
>  >
>  >       http://code.google.com/soc/2008/
>  >
>  > I think this would be a great opportunity for DragonFly to participate
>  > as a mentoring organisation.  We could attract new developers and could
>  > get code/work done.  Looking at the SoC results of the other BSDs most
>  > of their projects were a success.  Of course, not all, but a reasonable
>  > percentage.  See [1] and [2].
>
>  We've applied in previous years - Jeff Hsu did one year, and I put
>  together the application last year.  The hardest thing to find was
>  students (and they are the thing that helps SoC applications a lot, I
>  think).
>
>  Any student volunteers?  We have mentors.
>
>



-- 
Sd?vtaker prays to Rikku goddess for a good treasure.



From rluciani at gmail.com  Tue Mar  4 09:44:02 2008
From: rluciani at gmail.com (Robert Luciani)
Date: Tue, 04 Mar 2008 18:44:02 +0100
Subject: google soc "DragonFly"
Message-ID: <47cd8a63$0$855$415eb37d@crater_reader.dragonflybsd.org>

On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
> > Hi,
> >
> > Google just announced its Summer of Code for 2008:
> >
> > 	http://code.google.com/soc/2008/
> >
> > I think this would be a great opportunity for DragonFly to participate
> > as a mentoring organisation.  We could attract new developers and could
> > get code/work done.  Looking at the SoC results of the other BSDs most
> > of their projects were a success.  Of course, not all, but a reasonable
> > percentage.  See [1] and [2].

We've applied in previous years - Jeff Hsu did one year, and I put
together the application last year.  The hardest thing to find was
students (and they are the thing that helps SoC applications a lot, I
think).

Any student volunteers?  We have mentors.


-- 
Robert Luciani
Chalmers University of Technology, SWE
Department of Computer Science and Engineering
http://www.rluciani.com/public.key




From rluciani at gmail.com  Tue Mar  4 10:04:14 2008
From: rluciani at gmail.com (Robert Luciani)
Date: Tue, 04 Mar 2008 19:04:14 +0100
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47cd8f1f$0$856$415eb37d@crater_reader.dragonflybsd.org>

Robert Luciani wrote:
> Justin C. Sherrill wrote:
>> On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
>>> Hi,
>>>
>>> Google just announced its Summer of Code for 2008:
>>>
>>> 	http://code.google.com/soc/2008/
>>>
>>> I think this would be a great opportunity for DragonFly to participate
>>> as a mentoring organisation.  We could attract new developers and could
>>> get code/work done.  Looking at the SoC results of the other BSDs most
>>> of their projects were a success.  Of course, not all, but a reasonable
>>> percentage.  See [1] and [2].
>> We've applied in previous years - Jeff Hsu did one year, and I put
>> together the application last year.  The hardest thing to find was
>> students (and they are the thing that helps SoC applications a lot, I
>> think).
>>
>> Any student volunteers?  We have mentors.
>>
> 
> bingo
> 
My girlfriend Danwei noted that she would also like partake in the SoC.
She's studying IT here at Chalmers and will join the mailing list shortly.
-- 
Robert Luciani
Chalmers University of Technology, SWE
Department of Computer Science and Engineering
http://www.rluciani.com/public.key




From dillon at apollo.backplane.com  Tue Mar  4 13:08:30 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Tue, 4 Mar 2008 13:08:30 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Going to have to roll 1.12.1
Message-ID: <200803042104.m24L43g1065278@apollo.backplane.com>

    Due to a critical bug in sendmail that can cause it to seg-fault I will
    be rolling 1.12.1 as soon as I get verification that the current
    fix deals with it.

						-Matt





From sdavtaker at gmail.com  Tue Mar  4 17:40:43 2008
From: sdavtaker at gmail.com (=?UTF-8?B?U2TDpHZ0YWtlcg==?=)
Date: Tue, 4 Mar 2008 17:40:43 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: [Fwd: Project Support Open Source: $50 donation to support you  project]
In-Reply-To: <2468.192.168.0.242.1204346451.squirrel@www.shiningsilence.com>
Message-ID: <47CDF8D1.9070100@gmail.com>

50 bucks?
Come on...
You can get a meal a lot more expensive than that just going to a free 
HP conference about linux and you only have to rent your soul 3-5 hours ;-)
Sdav

Matthew Dillon escribi?:
:..
:source project's web page.  I'm putting those words in scare quotes
:because I think it's a "payment" for an "advertisement".  The supplied
:link has nothing to do with DragonFly, to say the least.
:
:I don't think this is a good idea, obviously, and replied to that effect. 
:However, I wanted to put this on a DragonFly list, in part to show this
:strange thing, and in part because I'm not comfortable making
:administrative decisions on behalf of the Project without being open as
:possible about it.

    It doesn't really cry out to me either.

						-Matt

  






From sdavtaker at gmail.com  Tue Mar  4 17:56:35 2008
From: sdavtaker at gmail.com (=?UTF-8?B?U2TDpHZ0YWtlcg==?=)
Date: Tue, 4 Mar 2008 17:56:35 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47CDFCCE.1010106@gmail.com>

A cute idea for for GSOC would be to finish the installer.
We were talking about this in my local BUG, we trying to find out how to 
help on that from here.
There is a few missing features in the CD.

   * FDISK, you need to create the slides from another OS before
     install DFBSD, i think port FDisk from FBSD or any *BSD will solve it.
   * Add to the make release a way to add some custom applications to
     the released liveCD (suppose you want to add nmap or ssh or
     something just to use as test disk in some enviroment).
   * Make the installer a little more customizable, and maybe w/ a GUI
     (I like a lot the console approach, but GUI installer will be a
     popularity move, DFBSD w/X makes a Desktop machine work, actually
     im using it that way and really like it).
I think those projects can be done in a SOC by students (like me) with a 
little guide.
Im a lot more interested in things network related and kernel, but i 
dont mind to work on those things, they need to be done some day.
What u think?
Sdav

Robert Luciani escribi?:
Robert Luciani wrote:
  
Justin C. Sherrill wrote:
    
On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
      
Hi,

Google just announced its Summer of Code for 2008:

	http://code.google.com/soc/2008/

I think this would be a great opportunity for DragonFly to participate
as a mentoring organisation.  We could attract new developers and could
get code/work done.  Looking at the SoC results of the other BSDs most
of their projects were a success.  Of course, not all, but a reasonable
percentage.  See [1] and [2].
        
We've applied in previous years - Jeff Hsu did one year, and I put
together the application last year.  The hardest thing to find was
students (and they are the thing that helps SoC applications a lot, I
think).
Any student volunteers?  We have mentors.

      
bingo

    
My girlfriend Danwei noted that she would also like partake in the SoC.
She's studying IT here at Chalmers and will join the mailing list shortly.
  






From c.turner at 199technologies.org  Tue Mar  4 18:30:53 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Tue, 4 Mar 2008 18:30:53 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47CE04C9.1010902@199technologies.org>

Justin C. Sherrill wrote:
together the application last year.  The hardest thing to find was
students (and they are the thing that helps SoC applications a lot, I
think).
umm.. if google wants to send me back to school, I'll sign up - hows 
that for a fair trade :?






From wbh at conducive.org  Tue Mar  4 23:52:13 2008
From: wbh at conducive.org (Bill Hacker)
Date: Wed, 05 Mar 2008 07:52:13 +0000
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47ce512e$0$855$415eb37d@crater_reader.dragonflybsd.org>

Sd?vtaker wrote:
A cute idea for for GSOC would be to finish the installer.
We were talking about this in my local BUG, we trying to find out how to 
help on that from here.
There is a few missing features in the CD.

   * FDISK, you need to create the slides from another OS before
     install DFBSD, i think port FDisk from FBSD or any *BSD will solve it.
I'd rather see that 'reversed' - i.e. - build a more capable fdisk in 
DFLY with hope that it might be seen worth importing into Free/Net/Open, 
or *at least* be able to do a more flexible job than those now do.

And disklabels as well. Hand in glove.

Here's why:

- At the moment, working with Free, Open, DFLY, and OpenSolaris on the 
same HDD requires a bit of acrobatics.

- There seems to now be greater divergence between/among the *BSD's as 
to being able to read each other's disklabels, mount and use each 
other's 'flavor' of FFS/UFS (not to mention Apple's implementation of 
UFS) than there is among the vast multitude of Linux ext2/3 denizens.

Even to the point where use of a *Linux* fs is the more universal way 
for being able to share mounts among the *BSD's. Think detached drives. 
And no - FAT is not all that practical for several reasons.

- DFLY currently has the most fine-grain ability to create slices and 
partitions. But the others cannot all (any?) read those.

'progress' w/r any of the *BSD's direction as to changes, improvements 
(or not) in their once-common-ancestry fs & disklabels need not be 
sacrificed.

I'm not holding out wish or hope for all players agreeing to return to 
'one sacred way'. Nor 'one new universal fs'. Neither is gonna happen.

But a 'legacy compatible' or least-common-denominator mode would do fine 
- most especially for portable / SAN devices.

So - how about a 'flexible' DFLY fdisk to go along with a 'flexible' 
disklabel that could adapt to whatever it found / was told to create?

JM2CW - but that *might* be a good place to get a cross-*BSD team together.

*snip* (other good stuff)

Bill Hacker




From matthias at dragonflybsd.org  Wed Mar  5 01:02:43 2008
From: matthias at dragonflybsd.org (Matthias Schmidt)
Date: Wed, 5 Mar 2008 01:02:43 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <20080305085747.GJ9833@staatsfeind.org>

Hi,

* Justin C. Sherrill wrote:
> 
> We've applied in previous years - Jeff Hsu did one year, and I put
> together the application last year.  The hardest thing to find was
> students (and they are the thing that helps SoC applications a lot, I
> think).

This is good to know, so we could coordinate that if we have enough
mentors and projects?!?  I put together a small text in the wiki:

http://wiki.dragonflybsd.org/index.cgi/GoogleSoC2008

Feel free to add project or missing stuff.  I'm sure I missed a lot of
things :)

> Any student volunteers?  We have mentors.

According to the discussion we could have some students, who would be a
mentor (besides me)?

Regards

	Matthias





From sdavtaker at gmail.com  Wed Mar  5 06:28:37 2008
From: sdavtaker at gmail.com (=?UTF-8?Q?Sd=C3=A4vtaker?=)
Date: Wed, 5 Mar 2008 06:28:37 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <c37d69f60803050624kd86d3d0w3b44a02d0e5a5391@mail.gmail.com>

<quote>
Write a driver (from scratch) for Intel 3945 wireless device
Mentor: Sepherosa Ziehau
</quote>

Yes yes yes, i want to :-)
Someone else planning to mentor in drivers coding?
Sdav

On Wed, Mar 5, 2008 at 5:57 AM, Matthias Schmidt
<matthias at dragonflybsd.org> wrote:
> Hi,
>
>
>  * Justin C. Sherrill wrote:
>  >
>  > We've applied in previous years - Jeff Hsu did one year, and I put
>  > together the application last year.  The hardest thing to find was
>  > students (and they are the thing that helps SoC applications a lot, I
>  > think).
>
>  This is good to know, so we could coordinate that if we have enough
>  mentors and projects?!?  I put together a small text in the wiki:
>
>  http://wiki.dragonflybsd.org/index.cgi/GoogleSoC2008
>
>  Feel free to add project or missing stuff.  I'm sure I missed a lot of
>  things :)
>
>
>  > Any student volunteers?  We have mentors.
>
>  According to the discussion we could have some students, who would be a
>  mentor (besides me)?
>
>  Regards
>
>         Matthias
>
>



-- 
Sd?vtaker prays to Rikku goddess for a good treasure.



From rluciani at gmail.com  Wed Mar  5 10:56:42 2008
From: rluciani at gmail.com (Robert Luciani)
Date: Wed, 05 Mar 2008 19:56:42 +0100
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47ceecea$0$847$415eb37d@crater_reader.dragonflybsd.org>

Sd?vtaker wrote:
> <quote>
> Write a driver (from scratch) for Intel 3945 wireless device
> Mentor: Sepherosa Ziehau
> </quote>
> 
> Yes yes yes, i want to :-)
> Someone else planning to mentor in drivers coding?
> Sdav
> 
> On Wed, Mar 5, 2008 at 5:57 AM, Matthias Schmidt
> <matthias at dragonflybsd.org> wrote:
>> Hi,
>>
>>
>>  * Justin C. Sherrill wrote:
>>  >
>>  > We've applied in previous years - Jeff Hsu did one year, and I put
>>  > together the application last year.  The hardest thing to find was
>>  > students (and they are the thing that helps SoC applications a lot, I
>>  > think).
>>
>>  This is good to know, so we could coordinate that if we have enough
>>  mentors and projects?!?  I put together a small text in the wiki:
>>
>>  http://wiki.dragonflybsd.org/index.cgi/GoogleSoC2008
>>
>>  Feel free to add project or missing stuff.  I'm sure I missed a lot of
>>  things :)
>>
>>
>>  > Any student volunteers?  We have mentors.
>>
>>  According to the discussion we could have some students, who would be a
>>  mentor (besides me)?
>>
>>  Regards
>>
>>         Matthias
>>
>>
> 
> 
>

IF someone starts to write a 3945 Intel driver,
please keep the newer 4965 in mind too.

-- 
Robert Luciani
Chalmers University of Technology, SWE
Department of Computer Science and Engineering
http://www.rluciani.com/public.key




From joerg at britannica.bec.de  Wed Mar  5 12:01:05 2008
From: joerg at britannica.bec.de (Joerg Sonnenberger)
Date: Wed, 5 Mar 2008 12:01:05 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <20080305195711.GA9981@britannica.bec.de>

On Wed, Mar 05, 2008 at 07:56:42PM +0100, Robert Luciani wrote:
> IF someone starts to write a 3945 Intel driver,
> please keep the newer 4965 in mind too.

NetBSD's wpi works quite well. The hardware is quite different from
4945.

Joerg




From sepherosa at gmail.com  Wed Mar  5 17:48:50 2008
From: sepherosa at gmail.com (Sepherosa Ziehau)
Date: Wed, 5 Mar 2008 17:48:50 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <ea7b9c170803051744u22b09484ofc994f034f11df3b@mail.gmail.com>

On Thu, Mar 6, 2008 at 2:56 AM, Robert Luciani <rluciani at gmail.com> wrote:
>  IF someone starts to write a 3945 Intel driver,

"IF" you know that trying to fix any wired bugs in certain drivers
(e.g. ipw, ral) will require you to read through all of the vendor's
linux code (yes, even including register values and position), i.e.
there is not much difference between writing one from scratch and
porting+fixing_bugs, then you probably will not put "IF" at the start
of your sentence.
If what I said sounded too harsh to you, then I was sorry.

>  please keep the newer 4965 in mind too.

Will do, once generic 11n support is brought in from freebsd.

Best Regards,
sephe

-- 
Live Free or Die




From saw at online.de  Thu Mar  6 05:34:14 2008
From: saw at online.de (Sascha Wildner)
Date: Thu, 06 Mar 2008 14:34:14 +0100
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
Message-ID: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>

Hi all,

this is probably as good a moment as any to come out of the forest with 
this. The patch at

http://leaf.dragonflybsd.org/~swildner/nrelease_gui.diff

adds some code to nrelease/ to build a LiveCD with xorg and so on 
(currently, only the xorg metapackages and fluxbox are added). In order 
to build one, you need a local dir with the pkgsrc binary packages (see 
below).

The following commands should then do the trick:

cd /usr/src
make buildworld
make buildkernel
cd nrelease
patch -p 0 </path/to/the/patch
make PKGSRC_PKG_PATH=/path/to/packages/dir/All realquick gui
The resulting ISO will be in /usr/release/dfly-gui.iso then. It will not 
boot into xorg automatically (although this is easily possible), so you 
need to login as root and do startx.

As of now, this all is kind of basic, more a proof of concept than 
anything else. As our release framework installs packages via chroot, 
the current setup just copies _all_ packages to the chroot before 
installing (kind of a hack).

That said, I'm now primarily interested in opinions/ideas/... about the 
direction this should take. Which packages would we like to see on the 
CD? Should it be a generic setup with the "most common things" 
installed, so a system can be quickly setup by the installer (which will 
cpdup /usr/pkg). Or should it be a more specialized set of tools? Or 
even as many packages as possible (Live DVD?). Etc., etc.

Before continuing on it, I'm really interested in people's input so 
don't hold anything back, please. :)

Sascha

--
http://yoyodyne.ath.cx



From rluciani at gmail.com  Thu Mar  6 06:42:03 2008
From: rluciani at gmail.com (Robert Luciani)
Date: Thu, 06 Mar 2008 15:42:03 +0100
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <47d002bc$0$847$415eb37d@crater_reader.dragonflybsd.org>

Sascha Wildner wrote:
> Hi all,
> 
> this is probably as good a moment as any to come out of the forest with
> this. The patch at
> 
> http://leaf.dragonflybsd.org/~swildner/nrelease_gui.diff
> 
> adds some code to nrelease/ to build a LiveCD with xorg and so on
> (currently, only the xorg metapackages and fluxbox are added). In order
> to build one, you need a local dir with the pkgsrc binary packages (see
> below).
> 
> The following commands should then do the trick:
> 
> cd /usr/src
> make buildworld
> make buildkernel
> cd nrelease
> patch -p 0 </path/to/the/patch
> make PKGSRC_PKG_PATH=/path/to/packages/dir/All realquick gui
> 
> The resulting ISO will be in /usr/release/dfly-gui.iso then. It will not
> boot into xorg automatically (although this is easily possible), so you
> need to login as root and do startx.
> 
> As of now, this all is kind of basic, more a proof of concept than
> anything else. As our release framework installs packages via chroot,
> the current setup just copies _all_ packages to the chroot before
> installing (kind of a hack).
> 
> That said, I'm now primarily interested in opinions/ideas/... about the
> direction this should take. Which packages would we like to see on the
> CD? Should it be a generic setup with the "most common things"
> installed, so a system can be quickly setup by the installer (which will
> cpdup /usr/pkg). Or should it be a more specialized set of tools? Or
> even as many packages as possible (Live DVD?). Etc., etc.
> 
> Before continuing on it, I'm really interested in people's input so
> don't hold anything back, please. :)
> 
> Sascha
> 

I think the main point of such a live-cd would be to test
dragonfly-specific features such as vkernels and more. Mplayer and
OpenOffic work the same on all platforms, so they might not be super
important, while irssi, firefox, networking tools, vim, a few more
shells/terminals might make it easier to for people to quickly gauge if
they can reproduce their current productivity and also what is new.

And if the point of a livecd is to test that kind of stuff, then it
would be nice for it to have a kernel that supports as much as possible
like ALTQ, and drivers.

Also if it has lots and lots of programs (thinking multimedia, java,
etc..) it might be hard to keep the future x64 and x86 live-cds on par.
Gentoo had this problem many years ago and it was very bothersome.

-- 
Robert Luciani
Chalmers University of Technology, SWE
Department of Computer Science and Engineering
http://www.rluciani.com/public.key




From matthias at dragonflybsd.org  Thu Mar  6 07:12:43 2008
From: matthias at dragonflybsd.org (Matthias Schmidt)
Date: Thu, 6 Mar 2008 07:12:43 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <20080306150757.GN9833@staatsfeind.org>

* Sascha Wildner wrote:
> Hi all,
> 
> this is probably as good a moment as any to come out of the forest with this. 
> The patch at
> 
> http://leaf.dragonflybsd.org/~swildner/nrelease_gui.diff
> 
> adds some code to nrelease/ to build a LiveCD with xorg and so on (currently, 
> only the xorg metapackages and fluxbox are added). In order to build one, you 
> need a local dir with the pkgsrc binary packages (see below).

Great work Sascha.

I agree with Robert on most of his stated points.
It would be nice to see some DragonFly specific features on the CD
(although I'm not sure if that will work for all features).  A little
environment where most Unix users feel at home (fluxbox, xfce, firefox,
thunderbird, gvim) should be enough.

Big applications like OO.org, java etc won't work because they are not
available as pkgsrc packages neither is it possible to compile them on
DragonFly.  At least to my knowledge.

Regards

	Matthias




From dillon at apollo.backplane.com  Thu Mar  6 09:31:52 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Thu, 6 Mar 2008 09:31:52 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <200803061728.m26HSR3O091809@apollo.backplane.com>


:Hi all,
:
:this is probably as good a moment as any to come out of the forest with 
:this. The patch at
:
:http://leaf.dragonflybsd.org/~swildner/nrelease_gui.diff
:
:adds some code to nrelease/ to build a LiveCD with xorg and so on 
:(currently, only the xorg metapackages and fluxbox are added). In order 
:to build one, you need a local dir with the pkgsrc binary packages (see 
:below).
:
:The following commands should then do the trick:

    It looks reasonable, though the package copy has to be tightened
    up a bit I think.

:...
:installed, so a system can be quickly setup by the installer (which will 
:cpdup /usr/pkg). Or should it be a more specialized set of tools? Or 
:even as many packages as possible (Live DVD?). Etc., etc.
:
:Before continuing on it, I'm really interested in people's input so 
:don't hold anything back, please. :)
:
:Sascha

    I think this is an excellent time to work up a DVD build and to
    add various 'flavor' extras.  So, e.g.:

	make installer gui gui_extras release dvd

    (All 'dvd' would do is generate a dvd compatible image for burning to
    dvd instead of cd).  I did a quick perusal of what I have on my
    workstation:

    * X
    * Firefox
    * Linux emulation
    * Open Office (linux version)
    * fvwm2
    * xpdf
    * freetype2

    I'd also suggest some image editing tools like gimp, and maybe the KDE
    gui suite.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From justin at shiningsilence.com  Thu Mar  6 09:42:44 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Thu, 6 Mar 2008 09:42:44 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <55427.65.106.147.226.1204825168.squirrel@www.shiningsilence.com>

On Thu, March 6, 2008 8:34 am, Sascha Wildner wrote:

> That said, I'm now primarily interested in opinions/ideas/... about the
> direction this should take. Which packages would we like to see on the
> CD? Should it be a generic setup with the "most common things"
> installed, so a system can be quickly setup by the installer (which will
> cpdup /usr/pkg). Or should it be a more specialized set of tools? Or
> even as many packages as possible (Live DVD?). Etc., etc.

What Robert said is good - whatever's needed to enable DragonFly-specific
features.  Along with that would be some sort of documentation (a README? 
A HTML file on whatever desktop we provide) that points people at the
different DragonFly tools, so they know what to try and how to try it.

There's going to be some percentage of people who try DragonFly who don't
know about vkernels, for instance, but there's our chance to educate them.
 I'm probably volunteering myself, aren't I?





From sdavtaker at gmail.com  Thu Mar  6 09:50:09 2008
From: sdavtaker at gmail.com (=?UTF-8?Q?Sd=C3=A4vtaker?=)
Date: Thu, 6 Mar 2008 09:50:09 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <c37d69f60803060947t110750c0sd6b542ea505d188d@mail.gmail.com>

Cool Sascha :-)
I just posted about this 1 or 2 days ago in the SOC project ideas thread.
Want to mentor this one? ;-)
Damian

On Thu, Mar 6, 2008 at 2:28 PM, Matthew Dillon
<dillon at apollo.backplane.com> wrote:
>
>  :Hi all,
>
> :
>  :this is probably as good a moment as any to come out of the forest with
>  :this. The patch at
>  :
>  :http://leaf.dragonflybsd.org/~swildner/nrelease_gui.diff
>  :
>  :adds some code to nrelease/ to build a LiveCD with xorg and so on
>  :(currently, only the xorg metapackages and fluxbox are added). In order
>  :to build one, you need a local dir with the pkgsrc binary packages (see
>  :below).
>  :
>  :The following commands should then do the trick:
>
>     It looks reasonable, though the package copy has to be tightened
>     up a bit I think.
>
>  :...
>  :installed, so a system can be quickly setup by the installer (which will
>
> :cpdup /usr/pkg). Or should it be a more specialized set of tools? Or
>  :even as many packages as possible (Live DVD?). Etc., etc.
>  :
>  :Before continuing on it, I'm really interested in people's input so
>  :don't hold anything back, please. :)
>  :
>  :Sascha
>
>     I think this is an excellent time to work up a DVD build and to
>     add various 'flavor' extras.  So, e.g.:
>
>         make installer gui gui_extras release dvd
>
>     (All 'dvd' would do is generate a dvd compatible image for burning to
>     dvd instead of cd).  I did a quick perusal of what I have on my
>     workstation:
>
>     * X
>     * Firefox
>     * Linux emulation
>     * Open Office (linux version)
>     * fvwm2
>     * xpdf
>     * freetype2
>
>     I'd also suggest some image editing tools like gimp, and maybe the KDE
>     gui suite.
>
>                                         -Matt
>                                         Matthew Dillon
>                                         <dillon at backplane.com>
>



-- 
Sd?vtaker prays to Rikku goddess for a good treasure.



From saw at online.de  Thu Mar  6 11:54:01 2008
From: saw at online.de (Sascha Wildner)
Date: Thu, 06 Mar 2008 20:54:01 +0100
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <47d04ba2$0$856$415eb37d@crater_reader.dragonflybsd.org>

Matthew Dillon wrote:
    It looks reasonable, though the package copy has to be tightened
    up a bit I think.
It looks as if it would work with mount_null'ing the chroot's 
/tmp/packages. I'll have a better patch ready tomorrow.

Sascha

--
http://yoyodyne.ath.cx



From c.turner at 199technologies.org  Thu Mar  6 19:11:44 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Thu, 6 Mar 2008 19:11:44 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Misc. ACPI / suspend
In-Reply-To: <47CA073B.6020106@199technologies.org>
Message-ID: <47D0B079.3060905@199technologies.org>

Chris Turner wrote:
Wondering if anyone more well versed in the ACPI implementation could
comment on the applicability of:
http://lkml.org/lkml/2007/4/6/69

Doing a little digging, it seems like

. /platform/pc32/i386/i686_mem.c

*might* have the necessary infrastructure to remap the MTRR's per the 
thread referenced,

but:

. /platform/pc32/acpica5/acpi_wakeup.c

doesn't seem to be using this infrastructure..

I'm no where near reaching an understanding of this yet,
but I'm wondering 3 things:
1) does anyone have ACPI (instead of APM)
   sleep / suspend / wakeup working on Dfly ?
2) If so, what machines are being used ?
3) Same question for other BSDs - my understanding is NetBSD is most
   'advanced' w/r/t power managment - but I'm not 100% on this ...
would looove to have a sleeping / resuming / scaling laptop running some 
BSD flavor.. am willing to work towards that end, esp. w/r/t Dfly -
trying to chart a course to figguring this out.

Thanks all,

- Chris




From c.turner at 199technologies.org  Thu Mar  6 19:12:33 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Thu, 6 Mar 2008 19:12:33 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: PCI Bios / Interrupt remapping / etc
Message-ID: <47D0B211.6000002@199technologies.org>

Doing a bit of digging here for my long-standing CBB+SIO interupt and 
buffer problem -

one machine I've tested against was an OpenBSD machine, which didn't
always work to handle the cardbus sio card on a PCI cardbus adapter
-

tuning up some of the device flags in:

http://www.openbsd.org/cgi-bin/man.cgi?query=pcibios&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=html

seems to have alleviated the problem for that os..

I'm just only starting to get up to speed on how DF handles these types 
of things (namely initial PIC / interrupt layout at boot time device 
enumeration), but am wondering if anyone familiar with this area of the 
code has any comments / advice w/r/t the capabilities of the DF bios 
drivers
and the various quirks / fixup mentioned in the link above..

looking to possibly investigate fixing up some of these issues over time.

Thanks

- Chris







From pavalos at theshell.com  Fri Mar  7 01:14:55 2008
From: pavalos at theshell.com (Peter Avalos)
Date: Fri, 7 Mar 2008 01:14:55 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: cam locking
Message-ID: <20080307091024.GC1652@ylem.theshell.com>

So I've been working on locking up cam using lockmgr locks, and here's
what I have so far:

http://www.theshell.com/~pavalos/wip/cam-lock.patch

Most of the work is obtained from FreeBSD.  I've only been running this
on my SCSI machine for a day, but because the patch is so large, I wanted
to make it available for people to review if they have some spare time.

Thanks,
Peter
Attachment:
pgp00002.pgp
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00002.pgp
Type: application/octet-stream
Size: 197 bytes
Desc: "Description: PGP signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080307/9a17ecd8/attachment-0005.obj>

From jspringe at uos.de  Fri Mar  7 03:25:17 2008
From: jspringe at uos.de (Jost Tobias Springenberg)
Date: Fri, 7 Mar 2008 12:25:17 +0100
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <20080307122517.72c9e2b1.jspringe@uos.de>

On Tue, 4 Mar 2008 11:28:15 -0500 (EST)
"Justin C. Sherrill" <justin at shiningsilence.com> wrote:

> On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
> > Hi,
> >
> > Google just announced its Summer of Code for 2008:
> >
> > 	http://code.google.com/soc/2008/
> >
> > I think this would be a great opportunity for DragonFly to participate
> > as a mentoring organisation.  We could attract new developers and could
> > get code/work done.  Looking at the SoC results of the other BSDs most
> > of their projects were a success.  Of course, not all, but a reasonable
> > percentage.  See [1] and [2].
> 
> We've applied in previous years - Jeff Hsu did one year, and I put
> together the application last year.  The hardest thing to find was
> students (and they are the thing that helps SoC applications a lot, I
> think).
> 
> Any student volunteers?  We have mentors.
> 

I read this mailing list for quite a while now and thought about contributing stuff
to DFfly several times, so yes why not take this opportunity if it's there.

-- 
Jost Tobias Springenberg <jspringe at uos.de>




From tgen at netphreax.net  Fri Mar  7 05:17:27 2008
From: tgen at netphreax.net (Thomas E. Spanjaard)
Date: Fri, 7 Mar 2008 05:17:27 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: PCI Bios / Interrupt remapping / etc
In-Reply-To: <47D0B211.6000002@199technologies.org>
Message-ID: <47D13FB4.5080306@netphreax.net>

Chris Turner wrote:
Doing a bit of digging here for my long-standing CBB+SIO interupt and 
buffer problem -

one machine I've tested against was an OpenBSD machine, which didn't
always work to handle the cardbus sio card on a PCI cardbus adapter
-

tuning up some of the device flags in:

http://www.openbsd.org/cgi-bin/man.cgi?query=pcibios&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=html 

seems to have alleviated the problem for that os..

I'm just only starting to get up to speed on how DF handles these types 
of things (namely initial PIC / interrupt layout at boot time device 
enumeration), but am wondering if anyone familiar with this area of the 
code has any comments / advice w/r/t the capabilities of the DF bios 
drivers
and the various quirks / fixup mentioned in the link above..

looking to possibly investigate fixing up some of these issues over time.
Our code that handles issues like this (in cases where you're not using 
APICs, just PICs and PIRs) lives in bus/pci/i386/. Not that running 
without APIC support is all that common on modern machines anymore...
--
        Thomas E. Spanjaard
        tgen at netphreax.net
Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00003.pgp
Type: application/octet-stream
Size: 186 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080307/61366b5c/attachment-0005.obj>

From tgen at netphreax.net  Fri Mar  7 05:16:51 2008
From: tgen at netphreax.net (Thomas E. Spanjaard)
Date: Fri, 7 Mar 2008 05:16:51 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Misc. ACPI / suspend
In-Reply-To: <47CA073B.6020106@199technologies.org>
Message-ID: <47D13F07.9080308@netphreax.net>

Chris Turner wrote:
1) does anyone have ACPI (instead of APM)
   sleep / suspend / wakeup working on Dfly ?
2) If so, what machines are being used ?
3) Same question for other BSDs - my understanding is NetBSD is most
   'advanced' w/r/t power managment - but I'm not 100% on this ...
would looove to have a sleeping / resuming / scaling laptop running some 
BSD flavor.. am willing to work towards that end, esp. w/r/t Dfly -
trying to chart a course to figguring this out.
I have ACPI S3 suspend working like a charm on my IBM ThinkPad R40 
(Pentium M "Banias" 1.3GHz, speedstepping works just fine), running 
NetBSD 3.99.21.
--
        Thomas E. Spanjaard
        tgen at netphreax.net
Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00004.pgp
Type: application/octet-stream
Size: 186 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080307/de3e5104/attachment-0005.obj>

From civilizd at gmail.com  Fri Mar  7 09:06:41 2008
From: civilizd at gmail.com (Vita "CiV" Cizek)
Date: Fri, 7 Mar 2008 09:06:41 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <98d564710803070853q1c73d795m6e6c5cc5049fa099@mail.gmail.com>

>  Any student volunteers?  We have mentors.
>
I am interested too, especially in some kernel-related work.




From justin at shiningsilence.com  Sat Mar  8 12:07:51 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Sat, 8 Mar 2008 12:07:51 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google SoC 2008 - mentors mentors mentors
Message-ID: <51558.192.168.0.252.1205006403.squirrel@www.shiningsilence.com>

If you are willing to mentor for the Google 2008 Summer of Code, please
speak up.  Right now we have: (from our wiki page)

Matthias
Sephe
TGEN
corecode

Part of the application process includes naming people as mentors (student
applications come later), so I want to get as complete a list as possible.

The application is due on the 12th, so if you want to mentor, now's the
time to say so.

Google's SoC FAQ is here: http://code.google.com/soc/2008/faqs.html

Our wiki page is here: http://wiki.dragonflybsd.org/index.cgi/GoogleSoC2008

- much credit to Matthias and others for getting that set up.





From saw at online.de  Sat Mar  8 14:26:07 2008
From: saw at online.de (Sascha Wildner)
Date: Sat, 08 Mar 2008 23:26:07 +0100
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <47d31245$0$848$415eb37d@crater_reader.dragonflybsd.org>

Sascha Wildner wrote:
Hi all,

this is probably as good a moment as any to come out of the forest with 
this. The patch at

http://leaf.dragonflybsd.org/~swildner/nrelease_gui.diff
Ok, I have committed the stuff as an example.

I'm not sure if my free time permits to work on a full-blown live CD 
with X11 and other good things (I already feel my interest wandering off 
in other directions) so if anyone wants to pick up the ball, go ahead. :)

Sascha

--
http://yoyodyne.ath.cx



From qhwt+dfly at les.ath.cx  Tue Mar 11 22:21:31 2008
From: qhwt+dfly at les.ath.cx (YONETANI Tomokazu)
Date: Tue, 11 Mar 2008 22:21:31 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Misc. ACPI / suspend
In-Reply-To: <47CA073B.6020106@199technologies.org>
Message-ID: <20080312051219.GA56091@les.ath.cx>

On Thu, Mar 06, 2008 at 10:03:21PM -0500, Chris Turner wrote:
> 1) does anyone have ACPI (instead of APM)
>    sleep / suspend / wakeup working on Dfly ?
> 2) If so, what machines are being used ?

Dynabook SS3500 (http://www.tlt.co.jp/pc/catalog/ss/02110735/index_j.htm).
It's old and can get very hot(thus frequently turns on the cooling fan)
even when it's running Windows.  I haven't turned it on for about several
months though.

Cheers.




From c.turner at 199technologies.org  Wed Mar 12 04:37:22 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Wed, 12 Mar 2008 04:37:22 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Misc. ACPI / suspend
In-Reply-To: <47CA073B.6020106@199technologies.org>
Message-ID: <47D7BEE3.6010907@199technologies.org>

YONETANI Tomokazu wrote:
On Thu, Mar 06, 2008 at 10:03:21PM -0500, Chris Turner wrote:
1) does anyone have ACPI (instead of APM)
   sleep / suspend / wakeup working on Dfly ?
Cheers.
ditto..

Suppose this should go to docs@ - in any case..

Thinking about setting up a wiki page on the issue so we
can discuss / track what 'good' hardware / drivers / implementations / 
etc are 'out there' - anyone have any suggestions on where this should
go?

http://wiki.dragonflybsd.org/index.cgi/acpi-overview.html

Remains from the handbook conversion - but I'm hesitant to 'over wikify'
this ..



From c.turner at 199technologies.org  Wed Mar 12 15:36:52 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Wed, 12 Mar 2008 15:36:52 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: devel/cscope
Message-ID: <47D85A08.8040103@199technologies.org>

why oh why did I take so long to try this out !!!

just sharing my eureka moment with the list..

- Chris




From dudu at dudu.ro  Wed Mar 12 15:50:14 2008
From: dudu at dudu.ro (Vlad GALU)
Date: Wed, 12 Mar 2008 15:50:14 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: devel/cscope
In-Reply-To: <47D85A08.8040103@199technologies.org>
Message-ID: <ad79ad6b0803121547r2bf67ffep9e40badaac6490f8@mail.gmail.com>

On 3/13/08, Chris Turner <c.turner at 199technologies.org> wrote:
> why oh why did I take so long to try this out !!!
>
>  just sharing my eureka moment with the list..


    Works nice with vim, too!

>
>
>  - Chris
>


-- 
Mahnahmahnah!




From justin at shiningsilence.com  Sun Mar 16 21:06:13 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Sun, 16 Mar 2008 21:06:13 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: binary packages for 1.12 coming in
Message-ID: <1372.192.168.0.252.1205726088.squirrel@www.shiningsilence.com>

The binary build for 1.12 is taking quite a while.  I've started copying
in newly built packages to
pkgbox.dragonflybsd.org/packages/DragonFly-1.12/i386/ - this should be
getting copied out to mirrors over the next while.

There are currently 1283 packages built, which leaves a whole lot to go;
I'll copy new packages in as they complete.





From hasso at estpak.ee  Wed Mar 19 04:31:08 2008
From: hasso at estpak.ee (Hasso Tepper)
Date: Wed, 19 Mar 2008 04:31:08 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Some questions regarding ACPI
Message-ID: <200803191322.46366.hasso@estpak.ee>

I'm working on bringing in some laptop (and especially thinkpad) specific 
ACPI code from FreeBSD into DragonFly. I never touched ACPI stuff before 
and haven't followed it much either, so I have some questions.

* FreeBSD uses ACPI_SERIAL_* heavily. What's the locking situation in 
  DragonFly and why?

* As far as I can see, PCI integration is commented out in DragonFly. 
  What's the state of it and why?

* platform/pc32/acpica5/acpi_toshiba.c - why is it there? I don't think 
  that this is something pc32 specific in it and it should work in pc64 
  laptops as well. Any objections to move it into 
  dev/acpica5/acpi_toshiba/ ?

What's the current status of ACPI in general? AFAICS our acpica is quite 
old - what needs to be done to bring in newer one?


-- 
Hasso




From qhwt+dfly at les.ath.cx  Wed Mar 19 09:24:50 2008
From: qhwt+dfly at les.ath.cx (YONETANI Tomokazu)
Date: Wed, 19 Mar 2008 09:24:50 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Some questions regarding ACPI
In-Reply-To: <200803191322.46366.hasso@estpak.ee>
Message-ID: <20080319161703.GA51509@les.ath.cx>

On Wed, Mar 19, 2008 at 01:22:46PM +0200, Hasso Tepper wrote:
> I'm working on bringing in some laptop (and especially thinkpad) specific 
> ACPI code from FreeBSD into DragonFly. I never touched ACPI stuff before 
> and haven't followed it much either, so I have some questions.

So you want to port some of ACPI support drivers, or to do a fresh port
of ACPI driver from FreeBSD?

> * FreeBSD uses ACPI_SERIAL_* heavily. What's the locking situation in 
>   DragonFly and why?

The current ACPI driver in DragonFly is based on that of FreeBSD as of
end of June, 2004, plus some fixes brought in later (and ACPICA part
has been updated twice since then).  That was before they introduced
the MPSAFE changes into ACPI code, and we use critical section
(crit_{enter,exit}) in most places (and lockmgr lock in a few place).

> * As far as I can see, PCI integration is commented out in DragonFly. 
>   What's the state of it and why?

When we replaced the implementation taken from FreeBSD 4.x with that
brought from FreeBSD 5.x, which added the PCI part, many people
experienced problems until they turned off ACPI completely, or add "pci"
to "debug.acpi.disabled" loader variable.  AFAIK the PCI part in the ACPI
driver almost hasn't been adjusted to work with our version of PCI code.

> * platform/pc32/acpica5/acpi_toshiba.c - why is it there? I don't think 
>   that this is something pc32 specific in it and it should work in pc64 
>   laptops as well. Any objections to move it into 
>   dev/acpica5/acpi_toshiba/ ?

In FreeBSD it used to be sitting at i386/acpica/acpi_toshiba.c and was
later moved into acpi_support.  That change hasn't hit our tree (in fact,
we have no acpi support drivers other than that).  It seems that FreeBSD
has them in dev/acpi_support now, and we for some reason have that
directory in our CVS repository (but containing no files in it).

> What's the current status of ACPI in general? AFAICS our acpica is quite 
> old - what needs to be done to bring in newer one?

Actually, it's not very important to keep just ACPICA latest, but
if you bring the ACPI driver from FreeBSD you need to bring ACPICA code
that matches their version, and it IS important.  And it generally requires
you much work to just update ACPICA part anyway because of how they
change things on every release.

Cheers.




From hasso at estpak.ee  Wed Mar 19 12:29:52 2008
From: hasso at estpak.ee (Hasso Tepper)
Date: Wed, 19 Mar 2008 12:29:52 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Some questions regarding ACPI
In-Reply-To: <200803191322.46366.hasso@estpak.ee>
Message-ID: <200803192115.35396.hasso@estpak.ee>

YONETANI Tomokazu wrote:
> On Wed, Mar 19, 2008 at 01:22:46PM +0200, Hasso Tepper wrote:
> > I'm working on bringing in some laptop (and especially thinkpad)
> > specific ACPI code from FreeBSD into DragonFly. I never touched ACPI
> > stuff before and haven't followed it much either, so I have some
> > questions.
>
> So you want to port some of ACPI support drivers, or to do a fresh port
> of ACPI driver from FreeBSD?

I'm only interested in support drivers and the reason is pure practical - 
newer thinkpads handle less and less hotkeys etc in hardware and require 
support form OS. acpi_ibm and acpi_video are examples of such modules 
which would help a lot of these newer thinkpad users.

acpi_ibm is almost ready to commit (renamed to acpi_thinkpad though).

> > * FreeBSD uses ACPI_SERIAL_* heavily. What's the locking situation in
> >   DragonFly and why?
>
> The current ACPI driver in DragonFly is based on that of FreeBSD as of
> end of June, 2004, plus some fixes brought in later (and ACPICA part
> has been updated twice since then).  That was before they introduced
> the MPSAFE changes into ACPI code, and we use critical section
> (crit_{enter,exit}) in most places (and lockmgr lock in a few place).

Mkay. Will look at more closely.

> > * As far as I can see, PCI integration is commented out in DragonFly.
> >   What's the state of it and why?
>
> When we replaced the implementation taken from FreeBSD 4.x with that
> brought from FreeBSD 5.x, which added the PCI part, many people
> experienced problems until they turned off ACPI completely, or add
> "pci" to "debug.acpi.disabled" loader variable.  AFAIK the PCI part in
> the ACPI driver almost hasn't been adjusted to work with our version of
> PCI code.

I'm afraid that it's beyond my skills, but while looking at acpi_video I 
discovered that it's hard to handle correctly without PCI support.

> > * platform/pc32/acpica5/acpi_toshiba.c - why is it there? I don't
> > think that this is something pc32 specific in it and it should work
> > in pc64 laptops as well. Any objections to move it into
> >   dev/acpica5/acpi_toshiba/ ?
>
> In FreeBSD it used to be sitting at i386/acpica/acpi_toshiba.c and was
> later moved into acpi_support.  That change hasn't hit our tree (in
> fact, we have no acpi support drivers other than that).  It seems that
> FreeBSD has them in dev/acpi_support now, and we for some reason have
> that directory in our CVS repository (but containing no files in it).

I don't see it ;). Makes sense though. So, any objections if I move 
acpi_toshiba into sys/dev/acpi_support and add new acpi_thinkpad there as 
well? 

> > What's the current status of ACPI in general? AFAICS our acpica is
> > quite old - what needs to be done to bring in newer one?
>
> Actually, it's not very important to keep just ACPICA latest, but
> if you bring the ACPI driver from FreeBSD you need to bring ACPICA code
> that matches their version, and it IS important.  And it generally
> requires you much work to just update ACPICA part anyway because of how
> they change things on every release.

Someone else has to do it :).

Thanks for info.


-- 
Hasso




From dillon at apollo.backplane.com  Wed Mar 19 14:01:13 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Wed, 19 Mar 2008 14:01:13 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: panic: assertion: hammer_btree_cmp(cursor->left_bound,	&cursor->node->ondisk->elms[0].leaf.base) <= 0 in btree_split_leaf
In-Reply-To: <200802232204.m1NM4cxd046264@apollo.backplane.com>
Message-ID: <200803192054.m2JKsjwn045137@apollo.backplane.com>


:Hi.
:While trying to find a procedure to reliably reproduce the panic
:I reported last time, I caught a different panic (uploaded at
: ~y0netan1/crash/9/ on my leaf account).  I wrote the following shell
:script (make sure to edit variables DISKS and MOUNTPT before using this
:script or it may trash your system):
:  #!/bin/sh -ex
:  DISKS="/dev/ad0s1f"
:  MOUNTPT=/mnt/HAMMER
:
:  cd /
:  newfs_hammer -L TEST $DISKS
:  for i in `seq 1 100`; do
:..
:And the panic is triggered by rm command.
:I'll try to see if it's possible to reproduce the last one without
:unmounting then mounting the HAMMER fs.
:
:Cheers.

    I believe I have fixed this panic.  hammer_make_separator() had a bug
    in it.

    There is still an issue with the node ref count on umount.

    Please continue to life-test the code.  The reblocking code
    (hammer reblock /mnt) should work now, as should the pruning code
    (e.g. hammer prune /mnt everything).

    The filesystem full case is still not handled and will cause bad things
    to happen.  The undo code isn't finished yet either but it is getting
    there (it's writing stuff out but not setting the sequence number and
    not trying to recover-on-mount yet).

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From qhwt+dfly at les.ath.cx  Wed Mar 19 19:45:40 2008
From: qhwt+dfly at les.ath.cx (YONETANI Tomokazu)
Date: Wed, 19 Mar 2008 19:45:40 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Some questions regarding ACPI
In-Reply-To: <200803191322.46366.hasso@estpak.ee>
Message-ID: <20080320023828.GA53648@les.ath.cx>

On Wed, Mar 19, 2008 at 09:15:35PM +0200, Hasso Tepper wrote:
> YONETANI Tomokazu wrote:
> > On Wed, Mar 19, 2008 at 01:22:46PM +0200, Hasso Tepper wrote:
> > > I'm working on bringing in some laptop (and especially thinkpad)
> > > specific ACPI code from FreeBSD into DragonFly. I never touched ACPI
> > > stuff before and haven't followed it much either, so I have some
> > > questions.
> >
> > So you want to port some of ACPI support drivers, or to do a fresh port
> > of ACPI driver from FreeBSD?
> 
> I'm only interested in support drivers and the reason is pure practical - 
> newer thinkpads handle less and less hotkeys etc in hardware and require 
> support form OS. acpi_ibm and acpi_video are examples of such modules 
> which would help a lot of these newer thinkpad users.
> 
> acpi_ibm is almost ready to commit (renamed to acpi_thinkpad though).

Ah, that's a good news!  My only concern is that ISTR someone mentioned
me that his colleague was thinking about porting ACPI driver itself,
so if you're not the person you may want to collaborate with him/her
so as not to waste the effort or time...

			:

> > In FreeBSD it used to be sitting at i386/acpica/acpi_toshiba.c and was
> > later moved into acpi_support.  That change hasn't hit our tree (in
> > fact, we have no acpi support drivers other than that).  It seems that
> > FreeBSD has them in dev/acpi_support now, and we for some reason have
> > that directory in our CVS repository (but containing no files in it).
> 
> I don't see it ;). Makes sense though. So, any objections if I move 
> acpi_toshiba into sys/dev/acpi_support and add new acpi_thinkpad there as 
> well? 

Sorry, I checked the CVS repository and it doesn't exist actually :)
I don't have any objection to moving it there.

Cheers.




From hasso at estpak.ee  Thu Mar 20 00:14:05 2008
From: hasso at estpak.ee (Hasso Tepper)
Date: Thu, 20 Mar 2008 00:14:05 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Some questions regarding ACPI
In-Reply-To: <200803191322.46366.hasso@estpak.ee>
Message-ID: <200803200904.50875.hasso@estpak.ee>

YONETANI Tomokazu wrote:
> On Wed, Mar 19, 2008 at 09:15:35PM +0200, Hasso Tepper wrote:
> > acpi_ibm is almost ready to commit (renamed to acpi_thinkpad though).
>
> Ah, that's a good news!  My only concern is that ISTR someone mentioned
> me that his colleague was thinking about porting ACPI driver itself,
> so if you're not the person you may want to collaborate with him/her
> so as not to waste the effort or time...

Current state in my repo is attached. It should work on 1.12 as well as it 
doesn't depend yet on moving stuff around.

add-acpi-if-m.patch adds some new stuff to the ACPI code to access 
embedded controllers and match ACPI devices by ID. Not sure how, where 
and whether at all these should be documented.

add-acpi-thinkpad.patch is the driver itself. Note that some stuff doesn't 
work yet on newer thinkpads, I plan to work on it later.

There is still some things to do though. I have to decide what to do with 
led(4) part and with locking. There is also one fatal issue - laptop 
locks up hardly (no panic) while unloading module. Any idea regarding 
this is welcome. And of course test results :).


-- 
Hasso
# HG changeset patch
# User Hasso Tepper <hasso at estpak.ee>
# Date 1205919290 -7200
# Branch HEAD
# Node ID 5a6e2705cc95a340abf973ae5df73ef34e070b79
# Parent  cd529e2e7f849034d5d5a0973cb98af50db0e797
imported patch adding-acpi-if-m.patch

diff --git a/sys/conf/files b/sys/conf/files
--- a/sys/conf/files
+++ b/sys/conf/files
@@ -1387,6 +1387,7 @@ emulation/dragonfly12/dfbsd12_stat.c	non
 ${OSACPI_MI_DIR}/acpi_cmbat.c		optional acpi
 ${OSACPI_MI_DIR}/acpi_cpu.c		optional acpi
 ${OSACPI_MI_DIR}/acpi_ec.c		optional acpi
+${OSACPI_MI_DIR}/acpi_if.m		optional acpi
 ${OSACPI_MI_DIR}/acpi_isab.c		optional acpi isa
 ${OSACPI_MI_DIR}/acpi_lid.c		optional acpi
 ${OSACPI_MI_DIR}/acpi_package.c		optional acpi
diff --git a/sys/conf/kmod.mk b/sys/conf/kmod.mk
--- a/sys/conf/kmod.mk
+++ b/sys/conf/kmod.mk
@@ -275,7 +275,7 @@ MFILES?= kern/bus_if.m kern/device_if.m 
     bus/pccard/card_if.m bus/pccard/power_if.m bus/pci/pci_if.m \
     bus/pci/pcib_if.m \
     bus/ppbus/ppbus_if.m bus/smbus/smbus_if.m bus/usb/usb_if.m \
-    dev/disk/nata/ata_if.m \
+    dev/acpica5/acpi_if.m dev/disk/nata/ata_if.m \
     dev/sound/pcm/ac97_if.m dev/sound/pcm/channel_if.m \
     dev/sound/pcm/feeder_if.m dev/sound/pcm/mixer_if.m \
     libiconv/iconv_converter_if.m dev/agp/agp_if.m opencrypto/crypto_if.m
diff --git a/sys/dev/acpica5/Makefile b/sys/dev/acpica5/Makefile
--- a/sys/dev/acpica5/Makefile
+++ b/sys/dev/acpica5/Makefile
@@ -69,12 +69,14 @@ SRCS+=  acpi_package.c
 # SRCS+=	acpi_pci.c acpi_pcib.c acpi_pcib_acpi.c acpi_pcib_pci.c
 # SRCS+=	acpi_pci_link.c
 SRCS+=  acpi_powerres.c acpi_resource.c acpi_thermal.c
-SRCS+=  acpi_timer.c
+SRCS+=  acpi_timer.c acpi_if.c
 SRCS+=  OsdDebug.c
 SRCS+=  OsdHardware.c OsdInterface.c OsdInterrupt.c OsdMemory.c OsdSchedule.c
 SRCS+=  OsdStream.c OsdSynch.c OsdTable.c OsdEnvironment.c
 SRCS+=  opt_acpi.h opt_bus.h opt_ddb.h
-SRCS+=  device_if.h bus_if.h pci_if.h pcib_if.h isa_if.h
+SRCS+=  device_if.h bus_if.h pci_if.h pcib_if.h isa_if.h acpi_if.h
+MFILES = kern/device_if.m kern/bus_if.m bus/pci/pci_if.m bus/pci/pcib_if.m
+MFILES+= bus/isa/isa_if.m dev/acpica5/acpi_if.m
 
 # Debugging support
 DBSRC=	dbcmds.c dbdisply.c dbexec.c dbfileio.c dbhistry.c
diff --git a/sys/dev/acpica5/acpi.c b/sys/dev/acpica5/acpi.c
--- a/sys/dev/acpica5/acpi.c
+++ b/sys/dev/acpica5/acpi.c
@@ -135,6 +135,7 @@ static int	acpi_release_resource(device_
 			int rid, struct resource *r);
 static uint32_t	acpi_isa_get_logicalid(device_t dev);
 static int	acpi_isa_get_compatid(device_t dev, uint32_t *cids, int count);
+static char	*acpi_device_id_probe(device_t bus, device_t dev, char **ids);
 static int	acpi_isa_pnp_probe(device_t bus, device_t child,
 			struct isa_pnp_id *ids);
 static void	acpi_probe_children(device_t bus);
@@ -189,6 +190,9 @@ static device_method_t acpi_methods[] = 
     DEVMETHOD(bus_deactivate_resource,	bus_generic_deactivate_resource),
     DEVMETHOD(bus_setup_intr,		bus_generic_setup_intr),
     DEVMETHOD(bus_teardown_intr,	bus_generic_teardown_intr),
+
+    /* ACPI bus */
+    DEVMETHOD(acpi_id_probe,		acpi_device_id_probe),
 
     /* ISA emulation */
     DEVMETHOD(isa_pnp_probe,		acpi_isa_pnp_probe),
@@ -1121,6 +1125,24 @@ out:
 	AcpiOsFree(buf.Pointer);
     ACPI_UNLOCK;
     return_VALUE (valid);
+}
+
+static char *
+acpi_device_id_probe(device_t bus, device_t dev, char **ids) 
+{
+    ACPI_HANDLE h;
+    int i;
+
+    h = acpi_get_handle(dev);
+    if (ids == NULL || h == NULL || acpi_get_type(dev) != ACPI_TYPE_DEVICE)
+	return (NULL);
+
+    /* Try to match one of the array of IDs with a HID or CID. */
+    for (i = 0; ids[i] != NULL; i++) {
+	if (acpi_MatchHid(h, ids[i]))
+	    return (ids[i]);
+    }
+    return (NULL);
 }
 
 static int
diff --git a/sys/dev/acpica5/acpi_ec.c b/sys/dev/acpica5/acpi_ec.c
--- a/sys/dev/acpica5/acpi_ec.c
+++ b/sys/dev/acpica5/acpi_ec.c
@@ -327,11 +327,19 @@ static ACPI_STATUS	EcWrite(struct acpi_e
 				UINT8 *Data);
 static int		acpi_ec_probe(device_t dev);
 static int		acpi_ec_attach(device_t dev);
+static int		acpi_ec_read_method(device_t dev, u_int addr,
+				ACPI_INTEGER *val, int width);
+static int		acpi_ec_write_method(device_t dev, u_int addr,
+				ACPI_INTEGER val, int width);
 
 static device_method_t acpi_ec_methods[] = {
     /* Device interface */
     DEVMETHOD(device_probe,	acpi_ec_probe),
     DEVMETHOD(device_attach,	acpi_ec_attach),
+
+    /* Embedded controller interface */
+    DEVMETHOD(acpi_ec_read,     acpi_ec_read_method),
+    DEVMETHOD(acpi_ec_write,    acpi_ec_write_method),
 
     {0, 0}
 };
@@ -620,6 +628,33 @@ error:
 			     sc->ec_data_res);
     /* mtx_destroy(&sc->ec_mtx); */
     return (ENXIO);
+}
+
+/* Methods to allow other devices (e.g., smbat) to read/write EC space. */
+static int
+acpi_ec_read_method(device_t dev, u_int addr, ACPI_INTEGER *val, int width)
+{
+    struct acpi_ec_softc *sc;
+    ACPI_STATUS status;
+
+    sc = device_get_softc(dev);
+    status = EcSpaceHandler(ACPI_READ, addr, width * 8, val, sc, NULL);
+    if (ACPI_FAILURE(status))
+        return (ENXIO);
+    return (0);
+}
+
+static int
+acpi_ec_write_method(device_t dev, u_int addr, ACPI_INTEGER val, int width)
+{
+    struct acpi_ec_softc *sc;
+    ACPI_STATUS status;
+
+    sc = device_get_softc(dev);
+    status = EcSpaceHandler(ACPI_WRITE, addr, width * 8, &val, sc, NULL);
+    if (ACPI_FAILURE(status))
+        return (ENXIO);
+    return (0);
 }
 
 static void
diff --git a/sys/dev/acpica5/acpi_if.m b/sys/dev/acpica5/acpi_if.m
new file mode 100644
--- /dev/null
+++ b/sys/dev/acpica5/acpi_if.m
@@ -0,0 +1,92 @@
+#-
+# Copyright (c) 2004 Nate Lawson
+# All rights reserved.
+#
+# Redistribution and use in source and binary forms, with or without
+# modification, are permitted provided that the following conditions
+# are met:
+# 1. Redistributions of source code must retain the above copyright
+#    notice, this list of conditions and the following disclaimer.
+# 2. Redistributions in binary form must reproduce the above copyright
+#    notice, this list of conditions and the following disclaimer in the
+#    documentation and/or other materials provided with the distribution.
+#
+# THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
+# ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+# ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
+# FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+# DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+# OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+# HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+# LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+# OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+# SUCH DAMAGE.
+#
+# $DragonFly$
+#
+
+#include <sys/bus.h>
+#include <sys/types.h>
+#include "acpi.h"
+
+INTERFACE acpi;
+
+#
+# Default implementation for acpi_id_probe().
+#
+CODE {
+	static char *
+	acpi_generic_id_probe(device_t bus, device_t dev, char **ids)
+	{
+		return (NULL);
+	}
+};
+
+#
+# Check a device for a match in a list of ID strings.  The strings can be
+# EISA PNP IDs or ACPI _HID/_CID values.
+#
+# device_t bus:  parent bus for the device
+#
+# device_t dev:  device being considered
+#
+# char **ids:  array of ID strings to consider
+#
+# Returns:  ID string matched or NULL if no match
+#
+METHOD char * id_probe {
+	device_t	bus;
+	device_t	dev;
+	char		**ids;
+} DEFAULT acpi_generic_id_probe;
+
+#
+# Read embedded controller (EC) address space
+#
+# device_t dev:  EC device
+# u_int addr:  Address to read from in EC space
+# ACPI_INTEGER *val:  Location to store read value
+# int width:  Size of area to read in bytes
+#
+METHOD int ec_read {
+	device_t	dev;
+	u_int		addr;
+	ACPI_INTEGER	*val;
+	int		width;
+};
+
+#
+# Write embedded controller (EC) address space
+#
+# device_t dev:  EC device
+# u_int addr:  Address to write to in EC space
+# ACPI_INTEGER val:  Value to write
+# int width:  Size of value to write in bytes
+#
+METHOD int ec_write {
+	device_t	dev;
+	u_int		addr;
+	ACPI_INTEGER	val;
+	int		width;
+};
diff --git a/sys/dev/acpica5/acpivar.h b/sys/dev/acpica5/acpivar.h
--- a/sys/dev/acpica5/acpivar.h
+++ b/sys/dev/acpica5/acpivar.h
@@ -29,6 +29,7 @@
  * $DragonFly: src/sys/dev/acpica5/acpivar.h,v 1.12 2007/10/23 03:04:48 y0netan1 Exp $
  */
 
+#include "acpi_if.h"
 #include "bus_if.h"
 #include <sys/eventhandler.h>
 #include <sys/sysctl.h>
# HG changeset patch
# User Hasso Tepper <hasso at estpak.ee>
# Date 1205995474 -7200
# Branch HEAD
# Node ID c5db8d4a7c6b25a8576a8d42c5029aaf0e23bfb6
# Parent  5a6e2705cc95a340abf973ae5df73ef34e070b79
[mq]: adding-acpi-thinkpad.patch

diff --git a/sys/dev/acpica5/Makefile b/sys/dev/acpica5/Makefile
--- a/sys/dev/acpica5/Makefile
+++ b/sys/dev/acpica5/Makefile
@@ -117,7 +117,7 @@ acpi_wakecode.h: acpi_wakecode.S
 	${MAKE} -f ${SYSDIR}/${OSACPI_MD_DIR}/Makefile \
 		MAKESRCPATH=${SYSDIR}/${OSACPI_MD_DIR}
 
-SUBDIR=	acpi_toshiba
+SUBDIR=	acpi_toshiba acpi_thinkpad
 all: ${PROG} ${SUBDIR}
 
 # *.o file for each patched *.c file is created under the same directory,
diff --git a/sys/dev/acpica5/acpi_thinkpad/Makefile b/sys/dev/acpica5/acpi_thinkpad/Makefile
new file mode 100644
--- /dev/null
+++ b/sys/dev/acpica5/acpi_thinkpad/Makefile
@@ -0,0 +1,9 @@
+# $DragonFly$
+
+SYSDIR?=${.CURDIR}/../../..
+
+KMOD=		acpi_thinkpad
+CFLAGS+=	-I${.OBJDIR}/.. -I${.CURDIR}/..
+SRCS=		acpi_thinkpad.c opt_acpi.h device_if.h bus_if.h
+
+.include <bsd.kmod.mk>
diff --git a/sys/dev/acpica5/acpi_thinkpad/acpi_thinkpad.c b/sys/dev/acpica5/acpi_thinkpad/acpi_thinkpad.c
new file mode 100644
--- /dev/null
+++ b/sys/dev/acpica5/acpi_thinkpad/acpi_thinkpad.c
@@ -0,0 +1,1046 @@
+/*
+ * Copyright (c) 2004 Takanori Watanabe
+ * Copyright (c) 2005 Markus Brueffer <markus at FreeBSD.org>
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *    notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *    notice, this list of conditions and the following disclaimer in the
+ *    documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+ */
+
+/*
+ * Driver for extra ACPI-controlled gadgets found on IBM and Lenovo ThinkPad
+ * laptops. Inspired by the ibm-acpi and tpb projects which implement these
+ * features on Linux.
+ *
+ *   acpi-ibm: <http://ibm-acpi.sourceforge.net/>
+ *        tpb: <http://www.nongnu.org/tpb/>
+ */
+
+#include "opt_acpi.h"
+#include <sys/param.h>
+#include <sys/kernel.h>
+#include <sys/bus.h>
+#include <machine/cpufunc.h>
+#include <sys/module.h>
+/* #include <dev/led/led.h> */
+#include <sys/sensors.h>
+#include <sys/sysctl.h>
+#include <machine/clock.h>
+
+#include "acpi.h"
+#include "acpivar.h"
+#include "acpi_if.h"
+
+#define _COMPONENT	ACPI_OEM
+ACPI_MODULE_NAME("THINKPAD")
+
+/* Internal methods */
+#define ACPI_THINKPAD_METHOD_EVENTS		1
+#define ACPI_THINKPAD_METHOD_EVENTMASK		2
+#define ACPI_THINKPAD_METHOD_HOTKEY		3
+#define ACPI_THINKPAD_METHOD_BRIGHTNESS		4
+#define ACPI_THINKPAD_METHOD_VOLUME		5
+#define ACPI_THINKPAD_METHOD_MUTE		6
+#define ACPI_THINKPAD_METHOD_THINKLIGHT		7
+#define ACPI_THINKPAD_METHOD_BLUETOOTH		8
+#define ACPI_THINKPAD_METHOD_WLAN		9
+#define ACPI_THINKPAD_METHOD_FANSPEED		10
+#define ACPI_THINKPAD_METHOD_FANLEVEL		11
+#define ACPI_THINKPAD_METHOD_FANSTATUS		12
+#define ACPI_THINKPAD_METHOD_THERMAL		13
+
+/* Hotkeys/Buttons */
+#define THINKPAD_RTC_HOTKEY1			0x64
+#define   THINKPAD_RTC_MASK_HOME		(1 << 0)
+#define   THINKPAD_RTC_MASK_SEARCH		(1 << 1)
+#define   THINKPAD_RTC_MASK_MAIL		(1 << 2)
+#define   THINKPAD_RTC_MASK_WLAN		(1 << 5)
+#define THINKPAD_RTC_HOTKEY2			0x65
+#define   THINKPAD_RTC_MASK_THINKPAD		(1 << 3)
+#define   THINKPAD_RTC_MASK_ZOOM		(1 << 5)
+#define   THINKPAD_RTC_MASK_VIDEO		(1 << 6)
+#define   THINKPAD_RTC_MASK_HIBERNATE		(1 << 7)
+#define THINKPAD_RTC_THINKLIGHT			0x66
+#define   THINKPAD_RTC_MASK_THINKLIGHT		(1 << 4)
+#define THINKPAD_RTC_SCREENEXPAND		0x67
+#define   THINKPAD_RTC_MASK_SCREENEXPAND	(1 << 5)
+#define THINKPAD_RTC_BRIGHTNESS			0x6c
+#define   THINKPAD_RTC_MASK_BRIGHTNESS		(1 << 5)
+#define THINKPAD_RTC_VOLUME			0x6e
+#define   THINKPAD_RTC_MASK_VOLUME		(1 << 7)
+
+/* Embedded Controller registers */
+#define THINKPAD_EC_BRIGHTNESS			0x31
+#define   THINKPAD_EC_MASK_BRI			0x7
+#define THINKPAD_EC_VOLUME			0x30
+#define   THINKPAD_EC_MASK_VOL			0xf
+#define   THINKPAD_EC_MASK_MUTE			(1 << 6)
+#define THINKPAD_EC_FANSTATUS			0x2F
+#define   THINKPAD_EC_MASK_FANLEVEL		0x3f
+#define   THINKPAD_EC_MASK_FANDISENGAGED	(1 << 6)
+#define   THINKPAD_EC_MASK_FANSTATUS		(1 << 7)
+#define THINKPAD_EC_FANSPEED			0x84
+
+/* CMOS Commands */
+#define THINKPAD_CMOS_VOLUME_DOWN		0
+#define THINKPAD_CMOS_VOLUME_UP			1
+#define THINKPAD_CMOS_VOLUME_MUTE		2
+#define THINKPAD_CMOS_BRIGHTNESS_UP		4
+#define THINKPAD_CMOS_BRIGHTNESS_DOWN		5
+
+/* ACPI methods */
+#define THINKPAD_NAME_KEYLIGHT			"KBLT"
+#define THINKPAD_NAME_WLAN_BT_GET		"GBDC"
+#define THINKPAD_NAME_WLAN_BT_SET		"SBDC"
+#define   THINKPAD_NAME_MASK_BT			(1 << 1)
+#define   THINKPAD_NAME_MASK_WLAN		(1 << 2)
+#define THINKPAD_NAME_THERMAL_GET		"TMP7"
+#define THINKPAD_NAME_THERMAL_UPDT		"UPDT"
+
+#define THINKPAD_NAME_EVENTS_STATUS_GET		"DHKC"
+#define THINKPAD_NAME_EVENTS_MASK_GET		"DHKN"
+#define THINKPAD_NAME_EVENTS_STATUS_SET		"MHKC"
+#define THINKPAD_NAME_EVENTS_MASK_SET		"MHKM"
+#define THINKPAD_NAME_EVENTS_GET		"MHKP"
+#define THINKPAD_NAME_EVENTS_AVAILMASK		"MHKA"
+
+#define ABS(x) (((x) < 0)? -(x) : (x))
+
+struct acpi_thinkpad_softc {
+	device_t	dev;
+	ACPI_HANDLE	handle;
+
+	/* Embedded controller */
+	device_t	ec_dev;
+	ACPI_HANDLE	ec_handle;
+
+	/* CMOS */
+	ACPI_HANDLE	cmos_handle;
+
+	/* Fan status */
+	ACPI_HANDLE	fan_handle;
+	int		fan_levels;
+
+	/* Keylight commands and states */
+	ACPI_HANDLE	light_handle;
+	int		light_cmd_on;
+	int		light_cmd_off;
+	int		light_val;
+	int		light_get_supported;
+	int		light_set_supported;
+
+	/* led(4) interface */
+	struct cdev	*led_dev;
+	int		led_busy;
+	int		led_state;
+
+	int		wlan_bt_flags;
+	int		thermal_updt_supported;
+
+	unsigned int	events_availmask;
+	unsigned int	events_initialmask;
+	int		events_mask_supported;
+	int		events_enable;
+
+	/* sensors(9) related */
+	struct ksensordev sensordev;
+	struct ksensor sensors[9];	/* XXX: 8 thermal + fan */
+
+	struct sysctl_ctx_list	*sysctl_ctx;
+	struct sysctl_oid	*sysctl_tree;
+};
+
+static struct {
+	char	*name;
+	int	method;
+	char	*description;
+	int	access;
+} acpi_thinkpad_sysctls[] = {
+	{
+		.name		= "events",
+		.method		= ACPI_THINKPAD_METHOD_EVENTS,
+		.description	= "ACPI events enable",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "eventmask",
+		.method		= ACPI_THINKPAD_METHOD_EVENTMASK,
+		.description	= "ACPI eventmask",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "hotkey",
+		.method		= ACPI_THINKPAD_METHOD_HOTKEY,
+		.description	= "Key Status",
+		.access		= CTLTYPE_INT | CTLFLAG_RD
+	},
+	{
+		.name		= "lcd_brightness",
+		.method		= ACPI_THINKPAD_METHOD_BRIGHTNESS,
+		.description	= "LCD Brightness",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "volume",
+		.method		= ACPI_THINKPAD_METHOD_VOLUME,
+		.description	= "Volume",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "mute",
+		.method		= ACPI_THINKPAD_METHOD_MUTE,
+		.description	= "Mute",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "thinklight",
+		.method		= ACPI_THINKPAD_METHOD_THINKLIGHT,
+		.description	= "Thinklight enable",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "bluetooth",
+		.method		= ACPI_THINKPAD_METHOD_BLUETOOTH,
+		.description	= "Bluetooth enable",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "wlan",
+		.method		= ACPI_THINKPAD_METHOD_WLAN,
+		.description	= "WLAN enable",
+		.access		= CTLTYPE_INT | CTLFLAG_RD
+	},
+	{
+		.name		= "fan_level",
+		.method		= ACPI_THINKPAD_METHOD_FANLEVEL,
+		.description	= "Fan level",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "fan",
+		.method		= ACPI_THINKPAD_METHOD_FANSTATUS,
+		.description	= "Fan enable",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+
+	{ NULL, 0, NULL, 0 }
+};
+
+/* ACPI_SERIAL_DECL(thinkpad, "ACPI THINKPAD extras"); */
+static int	acpi_thinkpad_probe(device_t dev);
+static int	acpi_thinkpad_attach(device_t dev);
+static int	acpi_thinkpad_detach(device_t dev);
+
+#if 0 /* not yet */
+static void	thinkpad_led(void *softc, int onoff);
+static void	thinkpad_led_task(struct acpi_thinkpad_softc *sc,
+		int pending __unused);
+#endif
+
+static int	acpi_thinkpad_sysctl(SYSCTL_HANDLER_ARGS);
+static int	acpi_thinkpad_sysctl_init(struct acpi_thinkpad_softc *sc,
+		int method);
+static int	acpi_thinkpad_sysctl_get(struct acpi_thinkpad_softc *sc,
+		int method);
+static int	acpi_thinkpad_sysctl_set(struct acpi_thinkpad_softc *sc,
+		int method, int val);
+
+static int	acpi_thinkpad_eventmask_set(struct acpi_thinkpad_softc *sc,
+		int val);
+static void	acpi_thinkpad_notify(ACPI_HANDLE h, UINT32 notify,
+		void *context);
+static void	acpi_thinkpad_refresh(void *);
+
+static device_method_t acpi_thinkpad_methods[] = {
+	/* Device interface */
+	DEVMETHOD(device_probe, acpi_thinkpad_probe),
+	DEVMETHOD(device_attach, acpi_thinkpad_attach),
+	DEVMETHOD(device_detach, acpi_thinkpad_detach),
+	{0, 0}
+};
+
+static driver_t	acpi_thinkpad_driver = {
+	"acpi_thinkpad",
+	acpi_thinkpad_methods,
+	sizeof(struct acpi_thinkpad_softc),
+};
+
+static devclass_t acpi_thinkpad_devclass;
+
+DRIVER_MODULE(acpi_thinkpad, acpi, acpi_thinkpad_driver,
+    acpi_thinkpad_devclass, 0, 0);
+MODULE_DEPEND(acpi_thinkpad, acpi, 1, 1, 1);
+static char    *thinkpad_ids[] = {"IBM0068", NULL};
+
+#if 0 /* not yet */
+static void
+thinkpad_led(void *softc, int onoff)
+{
+	struct acpi_thinkpad_softc* sc = (struct acpi_thinkpad_softc*) softc;
+
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+
+	if (sc->led_busy)
+		return;
+
+	sc->led_busy = 1;
+	sc->led_state = onoff;
+
+	AcpiOsExecute(OSL_NOTIFY_HANDLER, (void *)thinkpad_led_task, sc);
+}
+
+static void
+thinkpad_led_task(struct acpi_thinkpad_softc *sc, int pending __unused)
+{
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+
+	/* ACPI_SERIAL_BEGIN(thinkpad); */
+	acpi_thinkpad_sysctl_set(sc, ACPI_THINKPAD_METHOD_THINKLIGHT, sc->led_state);
+	/* ACPI_SERIAL_END(thinkpad); */
+
+	sc->led_busy = 0;
+}
+#endif
+
+static int
+acpi_thinkpad_probe(device_t dev)
+{
+	if (acpi_disabled("thinkpad") ||
+	    ACPI_ID_PROBE(device_get_parent(dev), dev, thinkpad_ids) == NULL ||
+	    device_get_unit(dev) != 0) 
+		return (ENXIO);
+
+	device_set_desc(dev, "IBM/Lenovo ThinkPad ACPI Extras");
+	return (0);
+}
+
+static int
+acpi_thinkpad_attach(device_t dev)
+{
+	struct acpi_thinkpad_softc	*sc;
+	struct acpi_softc	*acpi_sc;
+	devclass_t		ec_devclass;
+	int			i;
+
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t) __func__);
+
+	sc = device_get_softc(dev);
+	sc->dev = dev;
+	sc->handle = acpi_get_handle(dev);
+
+	acpi_sc = acpi_device_get_parent_softc(dev);
+
+	/* Look for the first embedded controller */
+        if (!(ec_devclass = devclass_find ("acpi_ec"))) {
+		if (bootverbose)
+			device_printf(dev, "Couldn't find acpi_ec devclass\n");
+		return (EINVAL);
+	}
+        if (!(sc->ec_dev = devclass_get_device(ec_devclass, 0))) {
+		if (bootverbose)
+			device_printf(dev, "Couldn't find acpi_ec device\n");
+		return (EINVAL);
+	}
+	sc->ec_handle = acpi_get_handle(sc->ec_dev);
+
+	/* ACPI_SERIAL_BEGIN(thinkpad); */
+
+#if 0
+	/* Get the sysctl tree */
+	sc->sysctl_ctx = device_get_sysctl_ctx(dev);
+	sc->sysctl_tree = device_get_sysctl_tree(dev);
+#endif
+	sysctl_ctx_init(sc->sysctl_ctx);
+	sc->sysctl_tree = SYSCTL_ADD_NODE(sc->sysctl_ctx,
+	    SYSCTL_CHILDREN(acpi_sc->acpi_sysctl_tree), OID_AUTO,
+	    "thinkpad", CTLFLAG_RD, 0, "");
+
+	/* Look for event mask and hook up the nodes */
+	sc->events_mask_supported = ACPI_SUCCESS(acpi_GetInteger(sc->handle,
+	    THINKPAD_NAME_EVENTS_MASK_GET, &sc->events_initialmask));
+
+	if (sc->events_mask_supported) {
+		SYSCTL_ADD_INT(sc->sysctl_ctx,
+		    SYSCTL_CHILDREN(sc->sysctl_tree), OID_AUTO,
+		    "initialmask", CTLFLAG_RD,
+		    &sc->events_initialmask, 0, "Initial eventmask");
+
+		/* The availmask is the bitmask of supported events */
+		if (ACPI_FAILURE(acpi_GetInteger(sc->handle,
+		    THINKPAD_NAME_EVENTS_AVAILMASK, &sc->events_availmask)))
+			sc->events_availmask = 0xffffffff;
+
+		SYSCTL_ADD_INT(sc->sysctl_ctx,
+		    SYSCTL_CHILDREN(sc->sysctl_tree), OID_AUTO,
+		    "availmask", CTLFLAG_RD,
+		    &sc->events_availmask, 0, "Mask of supported events");
+	}
+
+	/* Hook up proc nodes */
+	for (i = 0; acpi_thinkpad_sysctls[i].name != NULL; i++) {
+		if (!acpi_thinkpad_sysctl_init(sc,
+		    acpi_thinkpad_sysctls[i].method))
+			continue;
+
+		SYSCTL_ADD_PROC(sc->sysctl_ctx,
+		    SYSCTL_CHILDREN(sc->sysctl_tree), OID_AUTO,
+		    acpi_thinkpad_sysctls[i].name,
+		    acpi_thinkpad_sysctls[i].access,
+		    sc, i, acpi_thinkpad_sysctl, "I",
+		    acpi_thinkpad_sysctls[i].description);
+	}
+
+	/* ACPI_SERIAL_END(thinkpad); */
+
+	/* Handle notifies */
+	AcpiInstallNotifyHandler(sc->handle, ACPI_DEVICE_NOTIFY,
+	    acpi_thinkpad_notify, dev);
+
+#if 0
+	/* Hook up light to led(4) */
+	if (sc->light_set_supported)
+		sc->led_dev = led_create_state(thinkpad_led, sc, "thinklight",
+		    sc->light_val);
+#endif
+	/* Attach sensors(9). */
+	if (sensor_task_register(sc, acpi_thinkpad_refresh, 5)) {
+		device_printf(sc->dev, "unable to register update task\n");
+		return 1;
+	}
+
+	strlcpy(sc->sensordev.xname, device_get_nameunit(sc->dev),
+	    sizeof(sc->sensordev.xname));
+
+	/* XXX: Temp sensors */
+	for (i = 0; i < 8; ++i) {
+		sc->sensors[i].type = SENSOR_TEMP;
+		sensor_attach(&sc->sensordev, &sc->sensors[i]);
+	}
+	
+	/* Fan RPM sensor */
+	sc->sensors[8].type = SENSOR_FANRPM;
+	sensor_attach(&sc->sensordev, &sc->sensors[8]);
+
+	sensordev_install(&sc->sensordev);
+
+	return (0);
+}
+
+static int
+acpi_thinkpad_detach(device_t dev)
+{
+	int i;
+
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t) __func__);
+
+	struct acpi_thinkpad_softc *sc = device_get_softc(dev);
+
+	/* Disable events and restore eventmask */
+	/* ACPI_SERIAL_BEGIN(thinkpad); */
+	acpi_thinkpad_sysctl_set(sc, ACPI_THINKPAD_METHOD_EVENTS, 0);
+	acpi_thinkpad_sysctl_set(sc, ACPI_THINKPAD_METHOD_EVENTMASK,
+	    sc->events_initialmask);
+	/* ACPI_SERIAL_END(thinkpad); */
+
+	AcpiRemoveNotifyHandler(sc->handle, ACPI_DEVICE_NOTIFY,
+	    acpi_thinkpad_notify);
+
+	sysctl_ctx_free(sc->sysctl_ctx);
+
+#if 0
+	if (sc->led_dev != NULL)
+		led_destroy(sc->led_dev);
+#endif
+	sensordev_deinstall(&sc->sensordev);
+	for (i = 0; i < 9; i++)
+		sensor_detach(&sc->sensordev, &sc->sensors[i]);
+	sensor_task_unregister(sc);
+
+	return (0);
+}
+
+static int
+acpi_thinkpad_eventmask_set(struct acpi_thinkpad_softc *sc, int val)
+{
+	int i;
+	ACPI_OBJECT		arg[2];
+	ACPI_OBJECT_LIST	args;
+	ACPI_STATUS		status;
+
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+	/* ACPI_SERIAL_ASSERT(thinkpad); */
+
+	args.Count = 2;
+	args.Pointer = arg;
+	arg[0].Type = ACPI_TYPE_INTEGER;
+	arg[1].Type = ACPI_TYPE_INTEGER;
+
+	for (i = 0; i < 32; ++i) {
+		arg[0].Integer.Value = i+1;
+		arg[1].Integer.Value = (((1 << i) & val) != 0);
+		status = AcpiEvaluateObject(sc->handle,
+		    THINKPAD_NAME_EVENTS_MASK_SET, &args, NULL);
+
+		if (ACPI_FAILURE(status))
+			return (status);
+	}
+
+	return (0);
+}
+
+static int
+acpi_thinkpad_sysctl(SYSCTL_HANDLER_ARGS)
+{
+	struct acpi_thinkpad_softc	*sc;
+	int			arg;
+	int			error = 0;
+	int			function;
+	int			method;
+	
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+
+	sc = (struct acpi_thinkpad_softc *)oidp->oid_arg1;
+	function = oidp->oid_arg2;
+	method = acpi_thinkpad_sysctls[function].method;
+
+	/* ACPI_SERIAL_BEGIN(thinkpad); */
+	arg = acpi_thinkpad_sysctl_get(sc, method);
+	error = sysctl_handle_int(oidp, &arg, 0, req);
+
+	/* Sanity check */
+	if (error != 0 || req->newptr == NULL)
+		goto out;
+
+	/* Update */
+	error = acpi_thinkpad_sysctl_set(sc, method, arg);
+
+out:
+	/* ACPI_SERIAL_END(thinkpad); */
+	return (error);
+}
+
+static int
+acpi_thinkpad_sysctl_get(struct acpi_thinkpad_softc *sc, int method)
+{
+	ACPI_INTEGER	val_ec;
+	int 		val = 0, key;
+
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+	/* ACPI_SERIAL_ASSERT(thinkpad); */
+
+	switch (method) {
+	case ACPI_THINKPAD_METHOD_EVENTS:
+		acpi_GetInteger(sc->handle, THINKPAD_NAME_EVENTS_STATUS_GET,
+		    &val);
+		break;
+
+	case ACPI_THINKPAD_METHOD_EVENTMASK:
+		if (sc->events_mask_supported)
+			acpi_GetInteger(sc->handle,
+			    THINKPAD_NAME_EVENTS_MASK_GET, &val);
+		break;
+
+	case ACPI_THINKPAD_METHOD_HOTKEY:
+		/*
+		 * Construct the hotkey as a bitmask as illustrated below.
+		 * Note that whenever a key was pressed, the respecting bit
+		 * toggles and nothing else changes.
+		 * +--+--+-+-+-+-+-+-+-+-+-+-+
+		 * |11|10|9|8|7|6|5|4|3|2|1|0|
+		 * +--+--+-+-+-+-+-+-+-+-+-+-+
+		 *   |  | | | | | | | | | | |
+		 *   |  | | | | | | | | | | +- Home Button
+		 *   |  | | | | | | | | | +--- Search Button
+		 *   |  | | | | | | | | +----- Mail Button
+		 *   |  | | | | | | | +------- Thinkpad Button
+		 *   |  | | | | | | +--------- Zoom (Fn + Space)
+		 *   |  | | | | | +----------- WLAN Button
+		 *   |  | | | | +------------- Video Button
+		 *   |  | | | +--------------- Hibernate Button
+		 *   |  | | +----------------- Thinklight Button
+		 *   |  | +------------------- Screen expand (Fn + F8)
+		 *   |  +--------------------- Brightness
+		 *   +------------------------ Volume/Mute
+		 */
+		key = rtcin(THINKPAD_RTC_HOTKEY1);
+		val = (THINKPAD_RTC_MASK_HOME | THINKPAD_RTC_MASK_SEARCH |
+		    THINKPAD_RTC_MASK_MAIL | THINKPAD_RTC_MASK_WLAN) & key;
+		key = rtcin(THINKPAD_RTC_HOTKEY2);
+		val |= (THINKPAD_RTC_MASK_THINKPAD | THINKPAD_RTC_MASK_VIDEO |
+		    THINKPAD_RTC_MASK_HIBERNATE) & key;
+		val |= (THINKPAD_RTC_MASK_ZOOM & key) >> 1;
+		key = rtcin(THINKPAD_RTC_THINKLIGHT);
+		val |= (THINKPAD_RTC_MASK_THINKLIGHT & key) << 4;
+		key = rtcin(THINKPAD_RTC_SCREENEXPAND);
+		val |= (THINKPAD_RTC_MASK_THINKLIGHT & key) << 4;
+		key = rtcin(THINKPAD_RTC_BRIGHTNESS);
+		val |= (THINKPAD_RTC_MASK_BRIGHTNESS & key) << 5;
+		key = rtcin(THINKPAD_RTC_VOLUME);
+		val |= (THINKPAD_RTC_MASK_VOLUME & key) << 4;
+		break;
+
+	case ACPI_THINKPAD_METHOD_BRIGHTNESS:
+		ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_BRIGHTNESS, &val_ec, 1);
+		val = val_ec & THINKPAD_EC_MASK_BRI;
+		break;
+
+	case ACPI_THINKPAD_METHOD_VOLUME:
+		ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_VOLUME, &val_ec, 1);
+		val = val_ec & THINKPAD_EC_MASK_VOL;
+		break;
+
+	case ACPI_THINKPAD_METHOD_MUTE:
+		val = ((val_ec & THINKPAD_EC_MASK_MUTE) ==
+		    THINKPAD_EC_MASK_MUTE);
+		break;
+
+	case ACPI_THINKPAD_METHOD_THINKLIGHT:
+		if (sc->light_get_supported)
+			acpi_GetInteger(sc->ec_handle, THINKPAD_NAME_KEYLIGHT,
+			    &val);
+		else
+			val = sc->light_val;
+		break;
+
+	case ACPI_THINKPAD_METHOD_BLUETOOTH:
+		acpi_GetInteger(sc->handle, THINKPAD_NAME_WLAN_BT_GET, &val);
+		sc->wlan_bt_flags = val;
+		val = ((val & THINKPAD_NAME_MASK_BT) != 0);
+		break;
+
+	case ACPI_THINKPAD_METHOD_WLAN:
+		acpi_GetInteger(sc->handle, THINKPAD_NAME_WLAN_BT_GET, &val);
+		sc->wlan_bt_flags = val;
+		val = ((val & THINKPAD_NAME_MASK_WLAN) != 0);
+		break;
+
+	case ACPI_THINKPAD_METHOD_FANSPEED:
+		if (sc->fan_handle) {
+			if (ACPI_FAILURE(acpi_GetInteger(sc->fan_handle,
+			    NULL, &val)))
+				val = -1;
+		}
+		else {
+			ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_FANSPEED,
+			    &val_ec, 2);
+			val = val_ec;
+		}
+		break;
+
+	case ACPI_THINKPAD_METHOD_FANLEVEL:
+		/*
+		 * The THINKPAD_EC_FANSTATUS register works as follows:
+		 * Bit 0-5 indicate the level at which the fan operates. Only
+		 *       values between 0 and 7 have an effect. Everything
+		 *       above 7 is treated the same as level 7
+		 * Bit 6 overrides the fan speed limit if set to 1
+		 * Bit 7 indicates at which mode the fan operates:
+		 *       manual (0) or automatic (1)
+		 */
+		if (!sc->fan_handle) {
+			ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_FANSTATUS,
+			    &val_ec, 1);
+			val = val_ec & THINKPAD_EC_MASK_FANLEVEL;
+		}
+		break;
+
+	case ACPI_THINKPAD_METHOD_FANSTATUS:
+		if (!sc->fan_handle) {
+			ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_FANSTATUS,
+			    &val_ec, 1);
+			val = (val_ec & THINKPAD_EC_MASK_FANSTATUS) ==
+			    THINKPAD_EC_MASK_FANSTATUS;
+		}
+		else
+			val = -1;
+		break;
+	}
+
+	return (val);
+}
+
+static int
+acpi_thinkpad_sysctl_set(struct acpi_thinkpad_softc *sc, int method, int arg)
+{
+	int			val, step, i;
+	ACPI_INTEGER		val_ec;
+	ACPI_OBJECT		Arg;
+	ACPI_OBJECT_LIST	Args;
+	ACPI_STATUS		status;
+
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+	/* ACPI_SERIAL_ASSERT(thinkpad); */
+
+	switch (method) {
+	case ACPI_THINKPAD_METHOD_EVENTS:
+		if (arg < 0 || arg > 1)
+			return (EINVAL);
+
+		status = acpi_SetInteger(sc->handle,
+		    THINKPAD_NAME_EVENTS_STATUS_SET, arg);
+		if (ACPI_FAILURE(status))
+			return (status);
+		if (sc->events_mask_supported)
+			return acpi_thinkpad_eventmask_set(sc,
+			    sc->events_availmask);
+		break;
+
+	case ACPI_THINKPAD_METHOD_EVENTMASK:
+		if (sc->events_mask_supported)
+			return acpi_thinkpad_eventmask_set(sc, arg);
+		break;
+
+	case ACPI_THINKPAD_METHOD_BRIGHTNESS:
+		if (arg < 0 || arg > 7)
+			return (EINVAL);
+
+		if (sc->cmos_handle) {
+			/* Read the current brightness */
+			status = ACPI_EC_READ(sc->ec_dev,
+			    THINKPAD_EC_BRIGHTNESS, &val_ec, 1);
+			if (ACPI_FAILURE(status))
+				return (status);
+			val = val_ec & THINKPAD_EC_MASK_BRI;
+
+			Args.Count = 1;
+			Args.Pointer = &Arg;
+			Arg.Type = ACPI_TYPE_INTEGER;
+			Arg.Integer.Value = (arg > val) ?
+			    THINKPAD_CMOS_BRIGHTNESS_UP :
+			    THINKPAD_CMOS_BRIGHTNESS_DOWN;
+
+			step = (arg > val) ? 1 : -1;
+			for (i = val; i != arg; i += step) {
+				status = AcpiEvaluateObject(sc->cmos_handle,
+				    NULL, &Args, NULL);
+				if (ACPI_FAILURE(status))
+					break;
+			}
+		}
+		return ACPI_EC_WRITE(sc->ec_dev, THINKPAD_EC_BRIGHTNESS,
+		    arg, 1);
+		break;
+
+	case ACPI_THINKPAD_METHOD_VOLUME:
+		if (arg < 0 || arg > 14)
+			return (EINVAL);
+
+		status = ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_VOLUME,
+		    &val_ec, 1);
+		if (ACPI_FAILURE(status))
+			return (status);
+
+		if (sc->cmos_handle) {
+			val = val_ec & THINKPAD_EC_MASK_VOL;
+
+			Args.Count = 1;
+			Args.Pointer = &Arg;
+			Arg.Type = ACPI_TYPE_INTEGER;
+			Arg.Integer.Value = (arg > val) ?
+			    THINKPAD_CMOS_VOLUME_UP : THINKPAD_CMOS_VOLUME_DOWN;
+
+			step = (arg > val) ? 1 : -1;
+			for (i = val; i != arg; i += step) {
+				status = AcpiEvaluateObject(sc->cmos_handle,
+				    NULL, &Args, NULL);
+				if (ACPI_FAILURE(status))
+					break;
+			}
+		}
+		return ACPI_EC_WRITE(sc->ec_dev, THINKPAD_EC_VOLUME, arg +
+		    (val_ec & (~THINKPAD_EC_MASK_VOL)), 1);
+		break;
+
+	case ACPI_THINKPAD_METHOD_MUTE:
+		if (arg < 0 || arg > 1)
+			return (EINVAL);
+
+		status = ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_VOLUME,
+		    &val_ec, 1);
+		if (ACPI_FAILURE(status))
+			return (status);
+
+		if (sc->cmos_handle) {
+			val = val_ec & THINKPAD_EC_MASK_VOL;
+
+			Args.Count = 1;
+			Args.Pointer = &Arg;
+			Arg.Type = ACPI_TYPE_INTEGER;
+			Arg.Integer.Value = THINKPAD_CMOS_VOLUME_MUTE;
+
+			status = AcpiEvaluateObject(sc->cmos_handle, NULL,
+			    &Args, NULL);
+			if (ACPI_FAILURE(status))
+				break;
+		}
+		return ACPI_EC_WRITE(sc->ec_dev, THINKPAD_EC_VOLUME, (arg==1) ?
+		   val_ec | THINKPAD_EC_MASK_MUTE :
+		   val_ec & (~THINKPAD_EC_MASK_MUTE), 1);
+		break;
+
+	case ACPI_THINKPAD_METHOD_THINKLIGHT:
+		if (arg < 0 || arg > 1)
+			return (EINVAL);
+
+		if (sc->light_set_supported) {
+			Args.Count = 1;
+			Args.Pointer = &Arg;
+			Arg.Type = ACPI_TYPE_INTEGER;
+			Arg.Integer.Value = arg ?
+			    sc->light_cmd_on : sc->light_cmd_off;
+
+			status = AcpiEvaluateObject(sc->light_handle, NULL,
+			    &Args, NULL);
+			if (ACPI_SUCCESS(status))
+				sc->light_val = arg;
+			return (status);
+		}
+		break;
+
+	case ACPI_THINKPAD_METHOD_BLUETOOTH:
+		if (arg < 0 || arg > 1)
+			return (EINVAL);
+
+		val = (arg == 1) ? sc->wlan_bt_flags |
+		    THINKPAD_NAME_MASK_BT :
+		    sc->wlan_bt_flags & (~THINKPAD_NAME_MASK_BT);
+		return acpi_SetInteger(sc->handle, THINKPAD_NAME_WLAN_BT_SET,
+		    val);
+		break;
+
+	case ACPI_THINKPAD_METHOD_FANLEVEL:
+		if (arg < 0 || arg > 7)
+			return (EINVAL);
+
+		if (!sc->fan_handle) {
+			/* Read the current fanstatus */
+			ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_FANSTATUS,
+			    &val_ec, 1);
+			val = val_ec & (~THINKPAD_EC_MASK_FANLEVEL);
+
+			return ACPI_EC_WRITE(sc->ec_dev, THINKPAD_EC_FANSTATUS,
+			    val | arg, 1);
+		}
+		break;
+
+	case ACPI_THINKPAD_METHOD_FANSTATUS:
+		if (arg < 0 || arg > 1)
+			return (EINVAL);
+
+		if (!sc->fan_handle) {
+			/* Read the current fanstatus */
+			ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_FANSTATUS,
+			    &val_ec, 1);
+
+			return ACPI_EC_WRITE(sc->ec_dev, THINKPAD_EC_FANSTATUS,
+			    (arg == 1) ? (val_ec | THINKPAD_EC_MASK_FANSTATUS) :
+			    (val_ec & (~THINKPAD_EC_MASK_FANSTATUS)), 1);
+		}
+		break;
+	}
+
+	return (0);
+}
+
+static int
+acpi_thinkpad_sysctl_init(struct acpi_thinkpad_softc *sc, int method)
+{
+	int 			dummy;
+	ACPI_OBJECT_TYPE 	cmos_t;
+	ACPI_HANDLE		ledb_handle;
+
+	switch (method) {
+	case ACPI_THINKPAD_METHOD_EVENTS:
+		/* Events are disabled by default */
+		return (TRUE);
+
+	case ACPI_THINKPAD_METHOD_EVENTMASK:
+		return (sc->events_mask_supported);
+
+	case ACPI_THINKPAD_METHOD_HOTKEY:
+	case ACPI_THINKPAD_METHOD_BRIGHTNESS:
+	case ACPI_THINKPAD_METHOD_VOLUME:
+	case ACPI_THINKPAD_METHOD_MUTE:
+		/* EC is required here, which was already checked before */
+		return (TRUE);
+
+	case ACPI_THINKPAD_METHOD_THINKLIGHT:
+		sc->cmos_handle = NULL;
+		sc->light_get_supported = ACPI_SUCCESS(acpi_GetInteger(
+		    sc->ec_handle, THINKPAD_NAME_KEYLIGHT, &sc->light_val));
+
+		if ((ACPI_SUCCESS(AcpiGetHandle(sc->handle, "\\UCMS",
+		    &sc->light_handle)) ||
+		    ACPI_SUCCESS(AcpiGetHandle(sc->handle, "\\CMOS",
+		    &sc->light_handle)) ||
+		    ACPI_SUCCESS(AcpiGetHandle(sc->handle, "\\CMS",
+		    &sc->light_handle))) &&
+		    ACPI_SUCCESS(AcpiGetType(sc->light_handle, &cmos_t)) &&
+		    cmos_t == ACPI_TYPE_METHOD) {
+			sc->light_cmd_on = 0x0c;
+			sc->light_cmd_off = 0x0d;
+			sc->cmos_handle = sc->light_handle;
+		}
+		else if (ACPI_SUCCESS(AcpiGetHandle(sc->handle, "\\LGHT",
+		    &sc->light_handle))) {
+			sc->light_cmd_on = 1;
+			sc->light_cmd_off = 0;
+		}
+		else
+			sc->light_handle = NULL;
+
+		sc->light_set_supported = (sc->light_handle &&
+		    ACPI_FAILURE(AcpiGetHandle(sc->ec_handle, "LEDB",
+		    &ledb_handle)));
+
+		if (sc->light_get_supported)
+			return (TRUE);
+
+		if (sc->light_set_supported) {
+			sc->light_val = 0;
+			return (TRUE);
+		}
+
+		return (FALSE);
+
+	case ACPI_THINKPAD_METHOD_BLUETOOTH:
+	case ACPI_THINKPAD_METHOD_WLAN:
+		if (ACPI_SUCCESS(acpi_GetInteger(sc->handle,
+		    THINKPAD_NAME_WLAN_BT_GET, &dummy)))
+			return (TRUE);
+		return (FALSE);
+
+	case ACPI_THINKPAD_METHOD_FANSPEED:
+		/* 
+		 * Some models report the fan speed in levels from 0-7
+		 * Newer models report it contiguously
+		 */
+		sc->fan_levels = (ACPI_SUCCESS(AcpiGetHandle(sc->handle, "GFAN",
+		    &sc->fan_handle)) ||
+		    ACPI_SUCCESS(AcpiGetHandle(sc->handle, "\\FSPD",
+		    &sc->fan_handle)));
+		return (TRUE);
+
+	case ACPI_THINKPAD_METHOD_FANLEVEL:
+	case ACPI_THINKPAD_METHOD_FANSTATUS:
+		/* 
+		 * Fan status is only supported on those models,
+		 * which report fan RPM contiguously, not in levels
+		 */
+		if (sc->fan_levels)
+			return (FALSE);
+		return (TRUE);
+
+	case ACPI_THINKPAD_METHOD_THERMAL:
+		if (ACPI_SUCCESS(acpi_GetInteger(sc->ec_handle,
+		    THINKPAD_NAME_THERMAL_GET, &dummy))) {
+			sc->thermal_updt_supported =
+			    ACPI_SUCCESS(acpi_GetInteger(sc->ec_handle,
+			    THINKPAD_NAME_THERMAL_UPDT, &dummy));
+			return (TRUE);
+		}
+		return (FALSE);
+	}
+	return (FALSE);
+}
+
+static void
+acpi_thinkpad_notify(ACPI_HANDLE h, UINT32 notify, void *context)
+{
+	int		event, arg, type;
+	device_t	dev = context;
+	struct acpi_thinkpad_softc *sc = device_get_softc(dev);
+
+	ACPI_FUNCTION_TRACE_U32((char *)(uintptr_t)__func__, notify);
+
+	if (notify != 0x80)
+		device_printf(dev, "Unknown notify\n");
+
+	for (;;) {
+		acpi_GetInteger(acpi_get_handle(dev), THINKPAD_NAME_EVENTS_GET,
+		    &event);
+
+		if (event == 0)
+			break;
+
+		type = (event >> 12) & 0xf;
+		arg = event & 0xfff;
+		switch (type) {
+		case 1:
+			if (!(sc->events_availmask & (1 << (arg - 1)))) {
+				device_printf(dev, "Unknown key %d\n", arg);
+				break;
+			}
+
+			/* Notify devd(8) */
+			device_printf(dev, "THINKPAD event: %u\n",
+			    (arg & 0xff));
+			acpi_UserNotify("THINKPAD", h, (arg & 0xff));
+			break;
+		default:
+			break;
+		}
+	}
+}
+
+static void
+acpi_thinkpad_refresh(void *arg)
+{
+	struct acpi_thinkpad_softc *sc = (struct acpi_thinkpad_softc *)arg;
+	char temp_cmd[] = "TMP0";
+	int data, i;
+	ACPI_INTEGER speed;
+
+	for (i = 0; i < 8; i++) {
+		temp_cmd[3] = '0' + i;
+		
+                /*
+                 * The TMPx methods seem to return +/- 128 or 0
+                 * when the respecting sensor is not available
+                 */
+		sc->sensors[i].flags &= ~SENSOR_FINVALID;
+                if (ACPI_FAILURE(acpi_GetInteger(sc->ec_handle, temp_cmd,
+                    &data)) || ABS(data) == 128 || data == 0) {
+			sc->sensors[i].flags |= SENSOR_FINVALID;
+                        data = 0;
+		}
+                else if (sc->thermal_updt_supported) {
+                        /* XXX: Temperature is reported in tenth of Kelvin */
+                        data = (data - 2732 + 5) / 10;
+		}
+		sc->sensors[i].value = data * 1000000 + 273150000;
+        }
+	
+	sc->sensors[8].flags &= ~SENSOR_FINVALID;
+	if (sc->fan_handle) {
+		if (ACPI_FAILURE(acpi_GetInteger(sc->fan_handle,
+		    NULL, &data)))
+			sc->sensors[8].flags |= SENSOR_FINVALID;
+                        data = -1;
+        }
+        else {
+                ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_FANSPEED, &speed, 2);
+                data = speed;
+        }
+
+	sc->sensors[8].value = data;
+}
diff --git a/sys/platform/pc32/conf/files b/sys/platform/pc32/conf/files
--- a/sys/platform/pc32/conf/files
+++ b/sys/platform/pc32/conf/files
@@ -72,6 +72,7 @@ dev/serial/dgb/dgm.c			optional	dgm
 ${OSACPI_MD_DIR}/acpi_machdep.c		optional        acpi
 ${OSACPI_MD_DIR}/acpi_wakeup.c		optional        acpi
 ${OSACPI_MD_DIR}/acpi_toshiba.c		optional        acpi_toshiba acpi
+${ACPICA_DIR}/acpi_thinkpad/acpi_thinkpad.c optional	acpi_thinkpad acpi
 acpi.h					optional	acpi		\
 	dependency	"$S/${ACPICA_DIR}/include/acpi.h"		\
 	compile-with	"cp $S/${ACPICA_DIR}/include/acpi.h ${.OBJDIR}/"	\



From hasso at estpak.ee  Thu Mar 20 03:49:13 2008
From: hasso at estpak.ee (Hasso Tepper)
Date: Thu, 20 Mar 2008 03:49:13 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Some questions regarding ACPI
In-Reply-To: <200803191322.46366.hasso@estpak.ee>
Message-ID: <200803201237.28823.hasso@estpak.ee>

Hasso Tepper wrote:
> There is also one fatal issue -laptop locks up hardly (no panic) while 
> unloading module. Any idea regarding this is welcome.

Nevermind, solved.


-- 
Hasso




From dillon at apollo.backplane.com  Fri Mar 21 19:24:01 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Fri, 21 Mar 2008 19:24:01 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: panic: assertion: hammer_btree_cmp(cursor->left_bound,	&cursor->node->ondisk->elms[0].leaf.base) <= 0 in btree_split_leaf
In-Reply-To: <200802232204.m1NM4cxd046264@apollo.backplane.com>
Message-ID: <200803220212.m2M2CiAY014435@apollo.backplane.com>

:While trying to find a procedure to reliably reproduce the panic
:I reported last time, I caught a different panic (uploaded at
: ~y0netan1/crash/9/ on my leaf account).  I wrote the following shell
:script (make sure to edit variables DISKS and MOUNTPT before using this
:script or it may trash your system):

    Ok, I believe I have fixed the left_bound assertion.  I also believe
    I have fixed the node ref count assertion on umount.

    There is currently one unfixed assertion related to the I/O
    path... sometimes the bp is being improperly disassociated from the
    related HAMMER structure.

    The full-filesystem case is still not being handled so don't test that :-)

					    -Matt





From c.turner at 199technologies.org  Sun Mar 23 09:48:29 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Sun, 23 Mar 2008 09:48:29 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
Message-ID: <47E6870C.4080709@199technologies.org>

I'm finally getting around to doing 1.12 upgrades, and have setup a 
separate machine to do my bulk package builds / upgrades etc,
so as not to disrupt my 'dev server' while things are being
built / tested

However, this seems kind of wasteful - the only purpose of this machine
is to build packages against a specific release..
And since building packages for a particular release generally requires 
only the userland, appropriate headers and correct 'uname' output - so:

it seems like if spoofing uname is configured inside a jail,
the next (or previous..) release can be installed into a jail and
used for building / testing packages without the overhead of a VM or 
maintaining a separate physical host

I did a quick scan of the tree to see what this would take, and, high 
level, it seems like only the following changes would need to be made:

- update struct jail to add a 'osrelease' string
  (implies bumping 'jail api' to 2?)
- update jail(8) to actually pass this information along
- update sys_uname to test ucred for jailed processes, and
  use the struct jail osrelease if appropriate
- similarly update sysctl kern.osrelease to support jail spoofing
  (if possible - didn't get this far in the research yet)
  could be less of a problem for builds, as I think most things use
 uname(1) ... but good to keep the environment consistent I suppose..
I'm still a bit confused as to how 'osrelease' is defined - everything
I'm finding is showing up as extern char[] .. perhaps this is something 
in the build I'm not familiar with?

also,

is the so-called 'stupid hackery' in sys_uname needed still?

Before I start any coding, does this:

- sound like something useful
- sound like the right approach
Thinking this could have wider useful implications e.g. for pkgbox
& so on -  for example setting up automated bulks w/various combinations 
of pkgsrc and releases, etc.

Cheers,

- Chris





From corecode at fs.ei.tum.de  Sun Mar 23 10:06:38 2008
From: corecode at fs.ei.tum.de (Simon 'corecode' Schubert)
Date: Sun, 23 Mar 2008 10:06:38 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <47E68C74.3080808@fs.ei.tum.de>

Chris Turner wrote:
I did a quick scan of the tree to see what this would take, and, high 
level, it seems like only the following changes would need to be made:
brave investigation.  but you could also simply set UNAME_r :)

sweatshorts % uname -r
1.13.0-DEVELOPMENT
sweatshorts % UNAME_r=1.12-RELEASE uname -r
1.12-RELEASE
I think that's good enough :D

cheers
  simon
--
Serve - BSD     +++  RENT this banner advert  +++    ASCII Ribbon   /"\
Work - Mac      +++  space for low ????????? NOW!1  +++      Campaign     \ /
Party Enjoy Relax   |   http://dragonflybsd.org      Against  HTML   \
Dude 2c 2 the max   !   http://golden-apple.biz       Mail + News   / \




From c.turner at 199technologies.org  Sun Mar 23 10:50:13 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Sun, 23 Mar 2008 10:50:13 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <47E69656.8080605@199technologies.org>

Simon 'corecode' Schubert wrote:
brave investigation.  but you could also simply set UNAME_r :)
Doh! Thanks for the tip!

they should change the phrase from RTFM to 'Carefully RTFM' :)

well.. scratch that change then. 1 less patch to write.

- Chris





From c.turner at 199technologies.org  Sun Mar 23 11:15:52 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Sun, 23 Mar 2008 11:15:52 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <47E69C7C.8010109@199technologies.org>

Chris Turner wrote:
Simon 'corecode' Schubert wrote:
brave investigation.  but you could also simply set UNAME_r :)

for the record - if anyone's interested - adding a line e.g.:

ALL_ENV+= UNAME_r=1.12-RELEASE

to mk.conf looks like it -might- work ..

(unless wants to chime in & verify)





From joerg at britannica.bec.de  Sun Mar 23 11:46:53 2008
From: joerg at britannica.bec.de (Joerg Sonnenberger)
Date: Sun, 23 Mar 2008 11:46:53 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <20080323181428.GA2099@britannica.bec.de>

On Sun, Mar 23, 2008 at 01:41:42PM -0400, Chris Turner wrote:
> they should change the phrase from RTFM to 'Carefully RTFM' :)

RTFMAI -- Read The Fine Manual Again, Idiot.

Joerg




From dillon at apollo.backplane.com  Sun Mar 23 20:05:36 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Sun, 23 Mar 2008 20:05:36 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
Message-ID: <200803240257.m2O2voNH038355@apollo.backplane.com>

    Here's an update on the HAMMER work!

    Current status:

    * Passes all standard filesystem stress tests and buildworld will
      run with a HAMMER /usr/obj.  Large histories are able to accumulate
      without effecting performance.

    * Pruning and reblocking code is in and partially tested, but now needs
      more stringent testing.

    * Full historical access appears to be working but needs testing.
      Note that a sync is still needed to flush dirty cached data prior
      to acquiring a timestamp for the 'snapshot' to be set in stone.
      (dirty data cached in-memory has no historical tags and must be
      committed to physical disk before it can be accessed historically).


    Current bugs:

    * There is one known bug in the standard operations code paths
      that results in an assertion in HAMMER's I/O subsystem.

    * There are probably bugs in the reblocking and/or pruning code.  More
      likely in the reblocking code.


    There are two big-ticket and several little-ticket items left.  HAMMER
    will officially go Alpha when the big-ticket items are done, and beta
    when we get a few of the little-ticket items done.

    Big ticket items left:

    * UNDO (crash recovery) code.  Currently it writes out undo records but
      they are not yet sequenced, buffer writes are not yet ordered, and
      there is no mount-time recovery code yet.

      This is the last item needed before HAMMER can go operational.

    * Filesystem full handling.  Currently no space is reserved for dirty
      cached data so it is possible to create/write files and for HAMMER
      to not have sufficient space left on-disk to flush it.


    Little ticket items:

    * Automated reblocking (currently these functions are manually
      initialized via the hammer utility).

    * I/O clustering and preliminary BMAP op when writing out large files.

    * CRC checking (CRC fields are reserved but not entirely generated yet
      and not yet checked at all).

    * Disaster Recovery filesystem scan.

    * Boot support.

    I expect all of these items and more to be handled by the 2.0 release
    in July.

			    Additional HAMMER capabilities
				(no timeline yet)

    * Adding, removing, and resizing a HAMMER filesystem's backing store.

			Ultimate Goals and working towards them
				(no timeline yet)

    Our ultimate goal with HAMMER and DragonFly in general is to support
    fully cache coherent replication in a multi-machine environment.  This
    involves several steps and networking protocols.

    * Replication of synchronization streams based on the UNDO log.  If
      resynchronizing to a target which is too old a B-Tree scan will
      likely be required.

    * Cache coherency protocols for machine-machine coherency for both
      replicated and remote-HAMMER access.

    I have no time frame for these items yet.  It will depend on how quickly
    HAMMER moves to Alpha and Beta status.  I will say, however, now
    that HAMMER's on-disk format has solidified, that I have a very precise
    understanding of the protocols that will be needed to accomplish fully
    cache coherent remote access for both replicated and non-replicated
    (remote mount style) access.

    And, as you know, fully coherent filesystem access across machines is
    going to be the basis for DragonFly's clustering across said machines.

    In summary, things are progressing very well.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From justin at shiningsilence.com  Sun Mar 23 20:10:13 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Sun, 23 Mar 2008 20:10:13 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <53758.192.168.0.252.1206327873.squirrel@www.shiningsilence.com>

On Sun, March 23, 2008 12:36 pm, Chris Turner wrote:

> it seems like if spoofing uname is configured inside a jail,
> the next (or previous..) release can be installed into a jail and
> used for building / testing packages without the overhead of a VM or
> maintaining a separate physical host

If you don't need a jail to spoof uname, as others posted, you can
installworld into a chroot and build everything you want there using
Joerg's spiffy pbulk.  That's what I'm doing on pkgbox now; I can hand you
my somewhat terse notes if you want.  It would be relatively easy to set
up the configuration you're talking about.





From sepherosa at gmail.com  Sun Mar 23 20:18:20 2008
From: sepherosa at gmail.com (Sepherosa Ziehau)
Date: Sun, 23 Mar 2008 20:18:20 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <ea7b9c170803232012n2f27f893tf1d756d7c9770419@mail.gmail.com>

On Mon, Mar 24, 2008 at 2:14 AM, Joerg Sonnenberger
<joerg at britannica.bec.de> wrote:
> On Sun, Mar 23, 2008 at 01:41:42PM -0400, Chris Turner wrote:
>  > they should change the phrase from RTFM to 'Carefully RTFM' :)
>
>  RTFMAI -- Read The Fine Manual Again, Idiot.

http://leaf.dragonflybsd.org/~sephe/rtfm.jpg

:D

>
>  Joerg
>



-- 
Live Free or Die




From justin at shiningsilence.com  Sun Mar 23 20:38:30 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Sun, 23 Mar 2008 20:38:30 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: GSoC 2008 - mentors signup
Message-ID: <53885.192.168.0.252.1206329503.squirrel@www.shiningsilence.com>

If you are planning to be a mentor for a Summer of Code project, please
sign up here for the mentors mailing list:

http://groups.google.com/group/google-summer-of-code-mentors-list

If you've already signed up, your subscription should be set up tomorrow.





From justin at shiningsilence.com  Sun Mar 23 21:12:01 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Sun, 23 Mar 2008 21:12:01 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: GSoC 2008 - mentors signup
In-Reply-To: <53885.192.168.0.252.1206329503.squirrel@www.shiningsilence.com>
Message-ID: <54025.192.168.0.252.1206331572.squirrel@www.shiningsilence.com>

Also!

If you are a potential mentor and you have not done so yet:

http://code.google.com/soc/mentor_step1.html

Get yourself registered as a mentor for the Summer of Code project.  Once
you are in there, check off DragonFly in the "My Profile" section.

You will need a Google Account if you don't have one:

http://www.google.com/accounts

This will add you to the list of mentors in the Google Summer of Code web
application, so you can review/be attached to projects.

A guide is available if you want more information:

http://groups.google.com/group/google-summer-of-code-announce/web/guide-to-the-gsoc-web-app-for-mentors-and-organization-administrators






From c.turner at 199technologies.org  Mon Mar 24 04:29:28 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Mon, 24 Mar 2008 04:29:28 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <47E78ECE.4070307@199technologies.org>

Justin C. Sherrill wrote:
If you don't need a jail to spoof uname, as others posted, you can
installworld into a chroot and build everything you want there using
Joerg's spiffy pbulk.  That's what I'm doing on pkgbox now; I can hand you
my somewhat terse notes if you want.  It would be relatively easy to set
up the configuration you're talking about.
cheers - I guess I thought incorrectly that something 'special' was 
needed to get the uname to change .. have been using the legacy bulks in 
chroots / jails (for 'same os' builds) as I haven't quite migrated to 
pbulk yet ..

thanks for the help offer - I'll ask if I run into trouble.




From dillon at apollo.backplane.com  Mon Mar 24 08:28:49 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Mon, 24 Mar 2008 08:28:49 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <200803241500.m2OF0CG8043760@apollo.backplane.com>


:http://leaf.dragonflybsd.org/~sephe/rtfm.jpg
:
::D

    Ho!

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From elekktretterr at exemail.com.au  Mon Mar 24 09:10:15 2008
From: elekktretterr at exemail.com.au (Petr Janda)
Date: Mon, 24 Mar 2008 09:10:15 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
In-Reply-To: <200803240257.m2O2voNH038355@apollo.backplane.com>
Message-ID: <200803250138.49775.elekktretterr@exemail.com.au>


>
>     And, as you know, fully coherent filesystem access across machines is
>     going to be the basis for DragonFly's clustering across said machines.
>
>     In summary, things are progressing very well.
>


Hi Matt,
That's good to know things are going so well. Got a question. If memory serves 
me right, initially there was also going to be a thing called ANVIL, I can't 
remember what it was supposed to do and whether its still in your design. 
Could you elaborate a little?

Thanks,
Petr




From dillon at apollo.backplane.com  Mon Mar 24 14:12:11 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Mon, 24 Mar 2008 14:12:11 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
In-Reply-To: <200803240257.m2O2voNH038355@apollo.backplane.com>
Message-ID: <200803242100.m2OL0nWV046868@apollo.backplane.com>


:Hi Matt,
:That's good to know things are going so well. Got a question. If memory serves 
:me right, initially there was also going to be a thing called ANVIL, I can't 
:remember what it was supposed to do and whether its still in your design. 
:Could you elaborate a little?
:
:Thanks,
:Petr

    It's not really in the HAMMER design any more, primarily because HAMMER's
    volume model seems to work fine as-is.  Ultimately something like ANVIL
    (a block storage manager) would prove beneficial to the project but it
    would be treated as a separate project.  HAMMER's redundancy model is
    going to be baesd around replication and clustering.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From tgen at netphreax.net  Mon Mar 24 18:31:37 2008
From: tgen at netphreax.net (Thomas E. Spanjaard)
Date: Mon, 24 Mar 2008 18:31:37 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
In-Reply-To: <200803240257.m2O2voNH038355@apollo.backplane.com>
Message-ID: <47E85337.2070407@netphreax.net>

Matthew Dillon wrote:
    * Full historical access appears to be working but needs testing.
      Note that a sync is still needed to flush dirty cached data prior
      to acquiring a timestamp for the 'snapshot' to be set in stone.
      (dirty data cached in-memory has no historical tags and must be
      committed to physical disk before it can be accessed historically).
Wouldn't making timestamp queries (at least from userland) enforce a 
sync on the volume in question be useful here?
--
        Thomas E. Spanjaard
        tgen at netphreax.net
Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00005.pgp
Type: application/octet-stream
Size: 186 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080324/3077333f/attachment-0005.obj>

From dillon at apollo.backplane.com  Mon Mar 24 20:10:12 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Mon, 24 Mar 2008 20:10:12 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
In-Reply-To: <200803240257.m2O2voNH038355@apollo.backplane.com>
Message-ID: <200803250302.m2P32qLP050160@apollo.backplane.com>


:Wouldn't making timestamp queries (at least from userland) enforce a 
:sync on the volume in question be useful here?
:-- 
:         Thomas E. Spanjaard
:         tgen at netphreax.net

    Making the 'hammer now' command do a sync() is a good idea.  I will
    make that change right now so it doesn't get lost.

    Here's a general overview of the issues involved with having historical
    access to the filesystem:

				----------------

    Recording the timestamps in the in-memory cache, for a finer-grained
    snapshot capability, is doable but has its own issues.  Here's an
    illustration:

    open()  create file
    write() append 4K	(file size now 4K)
    write() append 4K	(file size now 8K)
    write() append 4K	(file size now 12K)
    write() append 4K	(file size now 16K)

    Now NONE of this has gone to disk yet, it's entirely in the in-memory
    cache.  The inode is in the in-memory cache.  The data is stored in
    the buffer cache.  Even the directory entry for the file that we
    just created is still in the in-memory cache (HAMMER caches the raw
    records it intends to commit later on).

    If I wanted to be able to acquire a timestamp between each write and
    'see' a snapshot of the file as of any point in the above sequence,
    then every write would also have to allocate a copy of the inode
    (because it changes size on each write).

    The data has the same problem though with a slightly different example.
    Lets say each write() was a seek-write, overwriting the previous data.
    Now with every write() I would have to allocate a copy of the data
    being overwritten.  This is complicated by the fact that the buffer
    cache has no clue about 'historical' accesses, so I would not be able
    to use the buffer cache to cache the data.

    There's also another problem and that is with the efficiency of the
    topology on-disk.  Even if I maintained all the copies of the inode
    and all the copies of the data in-memory, I would still have to sync
    all those copies to disk in order for things to remain historically
    coherent (whether it be in-cache or on-disk).  This would result in
    hundreds or even thousands of copies of the inode on-disk, not to
    mention potentially many copies of the data.

    I just don't want to do that right now, at least not as a default.  A
    lot of performance would be lost.  Hence a sync() is needed if
    you want to create a demark which you can accurately snapshot.

				-------------

    Here's a quick synopsis of how the cache would operate in a clustered
    filesystem:

    In order to properly integrate with in-memory caches, a wider cache
    coherency infrastructure is needed between machines such that
    modifications made on one machine proactively invalidate those
    protions of the cache(s) on other machines.  At the same time, any
    'dirty' cache data, for example when a file is created or written to,
    must lock the cache space in question on all other machines.
    The cache space in this case is not just the file data, but also the
    related namespaces (for creations, deletions, and renames).  Attempts
    to access locked spaces from other machines in the cluster would have
    to force a flush to the filesystem backing store and lower the cache
    states for the effected information on the original machine from dirty
    to shared-read-only.

    It will be easiest to integrate the cache coherency information into
    the buffer cache and namecache themselves.  Once a machine has dirtied
    an in-memory cache element... for example part of the namespace when
    creating a file or chunks of data written within a file, that machine
    must have a free hand to make further modifications to the cache spaces
    involved without further interaction with other machines.

				-------------

    Now, if you think of those two major elements you can see that they
    actually fit together quite well.  If I were to attempt to maintain
    transactional coherency on a per-system-call basis then the cache
    granularity between machines would have to be much, much smaller then
    our current in-memory caching elements provide.  That would become
    a really nasty coding problem.  So I don't even want to begin to
    complate transactional coherency at a finer-grain then sync() or
    fsync() until long after we actually have clustering working.

						-Matt





From elekktretterr at exemail.com.au  Mon Mar 24 21:56:58 2008
From: elekktretterr at exemail.com.au (Petr Janda)
Date: Mon, 24 Mar 2008 21:56:58 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
In-Reply-To: <200803240257.m2O2voNH038355@apollo.backplane.com>
Message-ID: <200803251516.16407.elekktretterr@exemail.com.au>

So is it needed to run hammer now in order to "create" a snapshot? What would 
I do in situation like this: got a hammer filesystem and couple of the files 
change on day to day basis. Then a week later I needed to access one of the 
files, in exactly the state they were 7 days ago.

Cheers,
Petr




From dillon at apollo.backplane.com  Mon Mar 24 22:34:15 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Mon, 24 Mar 2008 22:34:15 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
In-Reply-To: <200803240257.m2O2voNH038355@apollo.backplane.com>
Message-ID: <200803250526.m2P5QZ5X051081@apollo.backplane.com>


:So is it needed to run hammer now in order to "create" a snapshot? What would 
:I do in situation like this: got a hammer filesystem and couple of the files 
:change on day to day basis. Then a week later I needed to access one of the 
:files, in exactly the state they were 7 days ago.
:
:Cheers,
:Petr

    No, you do not have to run 'hammer now' to create a snapshot.  The
    kernel syncs all filesystems every 30 seconds, so if you do nothing
    at all you get a snapshot granularity of 30 seconds.

    Where you would use 'hammer now' is if you wanted the most current
    snapshot possible for the purpose of, say, backing up your filesystem
    to another machine.  You might do something like this:

	set timestamp = `hammer now`
	cpdup /mountpoint/@@$timestamp targethost:/somepath

    But if you didn't care about that you could just go back far enough
    that you get a stable historical view... e.g. go back 1 minute and you
    would have a stable view into your filesystem.

	set timestamp = `hammer stamp 60s`		<------ doesn't sync
	cpdup /mountpoint/@@$timestamp targethost:/somepath


    Ultimately the idea of managing filesystems this way is to still do
    regular backups from your production machine to your backup machine
    (ultimately by way of replication), with both running HAMMER, but only
    retain a limited amount of history on the production box.  You might
    desire to retain only one week's worth of history on the production box,
    retain one month's history on your local backup box, and retain a very
    granular one year's worth of history on your remote backup box.

    Come to think of it, I should add some more directives to the
    'hammer prune' command to make that easier to specify.

    Until I implement a live replication 'feed' the minimum granularity on
    the backup box will be how often you do your backups (e.g. once a day),
    and you can prune it into more granular forms from that starting point.
    Once we have a live replication feed the backup box will have the same
    30-second granularity that the production machine has.

    A major bullet point for this style of management is that the retention
    policy on the various boxes can be different even though they are
    all slaved off the same production filesystem.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From justin at shiningsilence.com  Tue Mar 25 05:58:49 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Tue, 25 Mar 2008 05:58:49 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: SoC - student signups
Message-ID: <58180.65.106.147.226.1206449676.squirrel@www.shiningsilence.com>

Here's a quick link roundup:

Are you a student?  Put in your application for a Google Summer of Code here:

http://code.google.com/soc/2008/student_signup.html

Student guide:
http://groups.google.com/group/google-summer-of-code-announce/web/guide-to-the-gsoc-web-app-for-student-applicants

Are you a mentor?  (That means hasso, hsu, sephe, matthias, TGEN, and
corecode right now)

Student proposals will show up on the mentor page, linked below.  You will
get to rate them, and take the one(s) that you want to mentor.

Mentor page:
http://code.google.com/soc/2008/mentor_home.html
Mentor guide:
http://groups.google.com/group/google-summer-of-code-announce/web/guide-to-the-gsoc-web-app-for-mentors-and-organization-administrators

If you are a mentor and are communicating with potential students, send
them the URLs above for student signup and the student guide; work with
them if they ask for advice on what to say in the application.  They can
resubmit up to 20 times if they want to correct it.

Deadline is March 31st.






From noah.yan at gmail.com  Thu Mar 27 20:17:48 2008
From: noah.yan at gmail.com (Yonghong Yan)
Date: Thu, 27 Mar 2008 20:17:48 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: About DFBSD.64
In-Reply-To: <47EB0B5B.5020802@gmail.com>
Message-ID: <59521b110803272015y1cc8cc39uc93f154ed36e0505@mail.gmail.com>

thanks for your interest.

I owe to everybody for any update or work in the past four months. so
many things happen in my work and my family (they are all good:) and
keep me extremely busy. But i am not leaving and will be back on this
soon.

the latest sources are in http://repo.or.cz/w/dragonfly/port-amd64.git
, I did have a compiled kernel long time before, but I have to break
it to work on the pmap. you can pick up from there. TGEN will help you
a lot, also keep me posted too, if you like.

Noah

On Wed, Mar 26, 2008 at 9:50 PM, Sdavtaker <sdavtaker at gmail.com> wrote:
> Hello,
>  Im applying to GSoC to work in the x64 version of DFBSD with TGEN, i
>  found some work already done in the repository and some mails in the
>  archive from you.
>  I was wondering if you already had a working compiled kernel in AMD64
>  machine and what was not working yet to continue that work.
>  Thanks for any info.
>  Sdav
>




From dillon at apollo.backplane.com  Sat Mar 29 13:27:43 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Sat, 29 Mar 2008 13:27:43 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 29-Mar-2008
Message-ID: <200803292022.m2TKMLGe004942@apollo.backplane.com>

    Good progress continues to be made.  HAMMER survived acting as my
    LAN backup machine (in full historical mode) for almost a week before
    it hit an assertion.  I've fixed that issue and believe that the core
    filesystem implementation code is now 'very stable'.

    Note that the recent commit will result in many more 'hammer_lock_ex:'
    messages on the console then you may have previously observed.  This is
    due to the way object id's are allocated in the face of parallel 
    modifications to the filesystem, resulting in too much locality of
    reference in the B-Tree.  I do intend to improve it.

    I am still working on the two major items needed before HAMMER can be
    declared operational, those being the filesystem full handling and the
    undo/recovery-on-mount code.  These are the last 'hard' bits left in
    the design.

    With exception to filling up the filesystem, which *will* create a mess,
    and noting that no crash recovery code exists yet (so you have to newfs
    it if you crash), I'd appreciate it if interested parties could test
    the other functions of the filesystem, in particular the pruning and
    reblocking functions (man hammer), and the historical access functions.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From dillon at apollo.backplane.com  Sun Mar 30 15:11:03 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Sun, 30 Mar 2008 15:11:03 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Need ideas on how to solve an st_ino/st_dev test issue for HAMMER.
Message-ID: <200803302207.m2UM7BCp016402@apollo.backplane.com>

    Here's the problem, given historical access softlinks as shown below:

test30# ls -lda cra*
drwxr-xr-x  1 root  wheel  Mar 29 13:04 crater
lrwxr-xr-x  1 root  wheel  Mar 29 18:57 crater.20080329 -> crater@@0x47eef383
lrwxr-xr-x  1 root  wheel  Mar 30 01:24 crater.20080330 -> crater@@0x47ef4e29
-rw-r--r--  2 root  wheel  Mar 30 01:24 crater.log

    The problem is that if I do this:

    diff -r crater.20080329/var/log crater.20080330/var/log

    Diff just returns without actually diffing anything.  The reason is
    because diff checks st_ino and st_dev and believes the directories/files
    to be identical because they match.

    I considered munging the inode number for historical accesses, but
    that would seriously break NFS exports which try to access historical
    files and directories.  Right now NFS *is* able to distinguish between
    the two because NFS handles are 128-bit-wide entities, so I can encode
    the as-of transaction id as part of the filehandle.  But userland
    programs only have access to a 64-bit-wide inode so userland still
    believes the files to be identical.

    st_dev is only 32 bits, carefully munging it is an option if we
    could figure out a way to do it, but I'd rather not.

    I am considering using st_gen but then we'd have to patch third
    party software to test st_gen along with everything else.  This may
    be the only workable solution, though, and only a few programs would
    need to be patched.  st_gen is only 32 bits but it would solve the
    problem as we would be able to use all 32 bits.

    If anyone has any bright ideas, including 'leave it alone', I'm all
    ears.

						-Matt





From justin at shiningsilence.com  Mon Mar 31 10:40:42 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Mon, 31 Mar 2008 10:40:42 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: SoC student applications due by 5PM PDT tomorrow
In-Reply-To: <1942.192.168.0.242.1206930479.squirrel@www.shiningsilence.com>
Message-ID: <11892.67.108.184.175.1206984967.squirrel@www.shiningsilence.com>

On Sun, March 30, 2008 10:27 pm, Justin C. Sherrill wrote:
> SoC students:
>
> If you have an application to submit for DragonFly/Summer of Code, please
> do so by 17:00 Pacific time on the 31st - that's tomorrow, at least for
> me.

The deadline for student proposals has been extended to April 7th; all
other dates move forward one week to acommodate.

This is a good time to update existing applications or submit new ones. 
Talk to your (potential) mentors if you are curious.






From nthery at gmail.com  Mon Mar 31 11:29:49 2008
From: nthery at gmail.com (Nicolas Thery)
Date: Mon, 31 Mar 2008 11:29:49 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
Message-ID: <64fc43b0803311126na7d0b27obaa9d35bac6d32ee@mail.gmail.com>

Hello,

Now that the release is over, I'll try to get rid of zones and migrate
allocations to objcache.

Here is a 1st patch that migrate struct proc.  I'll commit it in a
couple of days if nobody objects.

I'm also implementing a way to monitor objcache statistics.  So far,
I've hacked sth similar to
sysctl vm.zone: stats are returned in one giant string, one line per
cache.  That's simple but ugly and hard to read because there are
quite a few stats per cache.

So I'm thinking about implementing a small tool, ocstat, that extracts
stats from sysctl the way ps(1) does (thru libkvm iirc) and formats it
in various ways.  What do you think?

Cheers,
Nicolas

Index: src2/sys/kern/kern_exit.c
===================================================================
--- src2.orig/sys/kern/kern_exit.c	2008-03-31 08:05:59.139796000 +0200
+++ src2/sys/kern/kern_exit.c	2008-03-31 10:31:39.000000000 +0200
@@ -834,7 +834,7 @@ loop:
 			}

 			vm_waitproc(p);
-			zfree(proc_zone, p);
+			objcache_put(proc_cache, p);
 			nprocs--;
 			return (0);
 		}
Index: src2/sys/kern/kern_proc.c
===================================================================
--- src2.orig/sys/kern/kern_proc.c	2008-03-31 08:05:59.139918000 +0200
+++ src2/sys/kern/kern_proc.c	2008-03-31 10:31:39.000000000 +0200
@@ -84,7 +84,7 @@ u_long pgrphash;
 struct proclist allproc;
 struct proclist zombproc;
 struct spinlock allproc_spin;
-vm_zone_t proc_zone;
+struct objcache* proc_cache;
 vm_zone_t lwp_zone;
 vm_zone_t thread_zone;

@@ -131,7 +131,7 @@ procinit(void)
 	spin_init(&allproc_spin);
 	pidhashtbl = hashinit(maxproc / 4, M_PROC, &pidhash);
 	pgrphashtbl = hashinit(maxproc / 4, M_PROC, &pgrphash);
-	proc_zone = zinit("PROC", sizeof (struct proc), 0, 0, 5);
+	proc_cache = objcache_create_simple(M_PROC, sizeof(struct proc));
 	lwp_zone = zinit("LWP", sizeof (struct lwp), 0, 0, 5);
 	thread_zone = zinit("THREAD", sizeof (struct thread), 0, 0, 5);
 	uihashinit();
Index: src2/sys/sys/proc.h
===================================================================
--- src2.orig/sys/sys/proc.h	2008-03-31 08:05:59.140325000 +0200
+++ src2/sys/sys/proc.h	2008-03-31 10:31:39.000000000 +0200
@@ -473,7 +473,7 @@ struct proc *zpfind (pid_t);	/* Find zom
 struct vm_zone;
 struct globaldata;
 struct lwp_params;
-extern struct vm_zone *proc_zone;
+extern struct objcache *proc_cache;
 extern struct vm_zone *lwp_zone;

 int	enterpgrp (struct proc *p, pid_t pgid, int mksess);
Index: src2/sys/kern/kern_fork.c
===================================================================
--- src2.orig/sys/kern/kern_fork.c	2008-03-31 08:05:59.140042000 +0200
+++ src2/sys/kern/kern_fork.c	2008-03-31 10:31:39.000000000 +0200
@@ -332,7 +332,7 @@ fork1(struct lwp *lp1, int flags, struct
 	}

 	/* Allocate new proc. */
-	p2 = zalloc(proc_zone);
+	p2 = objcache_get(proc_cache, M_WAITOK);
 	bzero(p2, sizeof(*p2));

 	/*




From hsu at dragonflybsd.org  Mon Mar 31 11:44:34 2008
From: hsu at dragonflybsd.org (Jeffrey Hsu)
Date: Mon, 31 Mar 2008 11:44:34 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <64fc43b0803311126na7d0b27obaa9d35bac6d32ee@mail.gmail.com>
Message-ID: <200803311841.m2VIfQAI007579@nlpi001.prodigy.net>

The object cache is not a general-purpose memory allocator.  It's a cache of
pre-initialized objects.  Are the significant portions of the proc structure
that can be restored to initialized state on object puts?  If not, it's best
to just use a general-purpose memory allocator.

								Jeffrey




From corecode at fs.ei.tum.de  Mon Mar 31 12:07:02 2008
From: corecode at fs.ei.tum.de (Simon 'corecode' Schubert)
Date: Mon, 31 Mar 2008 12:07:02 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <200803311841.m2VIfQAI007579@nlpi001.prodigy.net>
Message-ID: <47F1357B.1070302@fs.ei.tum.de>

Jeffrey Hsu wrote:
> The object cache is not a general-purpose memory allocator.  It's a cache of
> pre-initialized objects.  Are the significant portions of the proc structure
> that can be restored to initialized state on object puts?  If not, it's best
> to just use a general-purpose memory allocator.

Why?  What's the loss if we use the object cache to allocate struct procs?

cheers
  simon

Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00006.pgp
Type: application/octet-stream
Size: 252 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080331/a4a24314/attachment-0005.obj>

From nthery at gmail.com  Mon Mar 31 12:17:03 2008
From: nthery at gmail.com (Nicolas Thery)
Date: Mon, 31 Mar 2008 12:17:03 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <nthery@gmail.com>
Message-ID: <64fc43b0803311214u7da6bbb8xaf971de1a80e7258@mail.gmail.com>

2008/3/31, Jeffrey Hsu <hsu at dragonflybsd.org>:
> The object cache is not a general-purpose memory allocator.  It's a cache of
>  pre-initialized objects.  Are the significant portions of the proc structure
>  that can be restored to initialized state on object puts?  If not, it's best
>  to just use a general-purpose memory allocator.

Well, I haven't checked this yet.  I planned to do this in a second
step after getting rid of zones.

I thought that even without  the pre-initialization part, objcache has
the advantage
of pre-allocating set of objects (as zones) and is additionally
mp-safe (contrary to zones and, granted, as malloc()).   The latter
may be interesting as we talk of improving MP support.

Cheers,
Nicolas




From dillon at apollo.backplane.com  Mon Mar 31 12:23:40 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Mon, 31 Mar 2008 12:23:40 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <200803311841.m2VIfQAI007579@nlpi001.prodigy.net>
Message-ID: <200803311921.m2VJLITB027669@apollo.backplane.com>

    I both agree and disagree with Jeff.  I think the only *disadvantage*
    to using objcache for struct proc is that objcache must cache a minimum
    number of free structures to be efficient so the overall kernel memory
    use would be a bit greater verses uses kmalloc().  But I agree with Jeff
    in that objcache's biggest advantage is that you can keep structural state
    intact and struct proc might not be a good candidate (yet).

    What I suggest is that you convert struct proc from zone to kmalloc
    first, and then look into a possible objcache adaptation.  kmalloc
    is not slow.. it's a very fast allocator.  Objcache is probably a tad
    faster but not by much.  Where objcache really wins is in not having
    to completey reinitialize the allocated structures.

    Over the years I've removed (I think) all the dependancies on requiring
    the proc structure to be in stable memory so I believe it can be moved to
    kmalloc/objcache now without any major pain.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From corecode at fs.ei.tum.de  Mon Mar 31 12:37:40 2008
From: corecode at fs.ei.tum.de (Simon 'corecode' Schubert)
Date: Mon, 31 Mar 2008 12:37:40 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: SoC student applications due by 5PM PDT tomorrow
In-Reply-To: <1942.192.168.0.242.1206930479.squirrel@www.shiningsilence.com>
Message-ID: <47F13CDA.6010703@fs.ei.tum.de>

Justin C. Sherrill wrote:
> On Sun, March 30, 2008 10:27 pm, Justin C. Sherrill wrote:
>> SoC students:
>>
>> If you have an application to submit for DragonFly/Summer of Code, please
>> do so by 17:00 Pacific time on the 31st - that's tomorrow, at least for
>> me.
> The deadline for student proposals has been extended to April 7th; all
> other dates move forward one week to acommodate.

This is very good.

Some more ideas for eager students (we want to keep the ratio, right?):

Enhance the FreeBSD/DragonFly sound infrastructure to support surround
sound/multichannel output.

Update sound drivers to support S/PDIF output.

Make the sound infrastructure OSSv4 compatible (there was a SoC at
FreeBSD last year or so)


of course only if it doesn't exist already :)

cheers
  simon


Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00007.pgp
Type: application/octet-stream
Size: 252 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080331/6da61cff/attachment-0005.obj>

From corecode at fs.ei.tum.de  Mon Mar 31 12:41:30 2008
From: corecode at fs.ei.tum.de (Simon 'corecode' Schubert)
Date: Mon, 31 Mar 2008 12:41:30 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <200803311841.m2VIfQAI007579@nlpi001.prodigy.net>
Message-ID: <47F13DE4.10205@fs.ei.tum.de>

Matthew Dillon wrote:
>     What I suggest is that you convert struct proc from zone to kmalloc
>     first, and then look into a possible objcache adaptation.  kmalloc
>     is not slow.. it's a very fast allocator.  Objcache is probably a tad
>     faster but not by much.  Where objcache really wins is in not having
>     to completey reinitialize the allocated structures.

Could we please not move to kmalloc, but instead try to move all fast
path allocations to objcache?  I don't like the idea of allocating
everything with kmalloc.  Caching struct procs is not a bad thing itself.

cheers
  simon


Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00008.pgp
Type: application/octet-stream
Size: 252 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080331/ac328c08/attachment-0005.obj>

From hsu at FreeBSD.org  Mon Mar 31 12:59:05 2008
From: hsu at FreeBSD.org (Jeffrey Hsu)
Date: Mon, 31 Mar 2008 12:59:05 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <47F1357B.1070302@fs.ei.tum.de>
Message-ID: <200803311920.m2VJK5Ln018015@nlpi015.prodigy.net>

The object cache sits on top of a general-purpose memory allocator such
as kmalloc or zalloc and provides pre-initialized object caching functionality.
If you're not going to use the object caching functionality, you can just
call the underlying memory allocator directly.

							Jeffrey




From dillon at apollo.backplane.com  Mon Mar 31 16:17:19 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Mon, 31 Mar 2008 16:17:19 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <200803311841.m2VIfQAI007579@nlpi001.prodigy.net>
Message-ID: <200803312311.m2VNBumd029866@apollo.backplane.com>

:Could we please not move to kmalloc, but instead try to move all fast
:path allocations to objcache?  I don't like the idea of allocating
:everything with kmalloc.  Caching struct procs is not a bad thing itself.=
:
:
:cheers
:  simon

    I will state for the record that I'm fine with either objcache or
    kmalloc.  I agree with Jeff that using objcache for struct proc
    probably isn't necessary but I also agree that it would not hurt either,
    and if the intent is to optimize the initialization of the proc
    structure in the future then moving to objcache now would save us
    from having to do it later.

    So whichever method Nicolas wants to use is fine with me.

						-Matt




From hsu at dragonflybsd.org  Mon Mar 31 19:22:47 2008
From: hsu at dragonflybsd.org (Jeffrey Hsu)
Date: Mon, 31 Mar 2008 19:22:47 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <64fc43b0803311214u7da6bbb8xaf971de1a80e7258@mail.gmail.com>
Message-ID: <200804010218.m312IVUq003624@nlpi043.prodigy.net>

  >> Are there significant portions of the proc structure
  >> that can be restored to initialized state on object puts?

  > I planned to do this in a second step after getting rid of zones.

I'll all in favor of making more use of caching pre-initialized objects, so
if this is your objective, then please go ahead.  It's just that I'd convert
over to the object cache in one step.

  > I thought that even without  the pre-initialization part, objcache has
  > the advantage of pre-allocating set of objects (as zones) and is additionally
  > mp-safe (contrary to zones and, granted, as malloc()).

Well, the zone allocator is MP-safe.  It's not hard to lock up the places that
manipulate the linked-list of free items. Look for uses of the zlock field.

								Jeffrey




From tgen at netphreax.net  Sat Mar  1 12:57:53 2008
From: tgen at netphreax.net (Thomas E. Spanjaard)
Date: Sat, 1 Mar 2008 12:57:53 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: [Fwd: Project Support Open Source: $50 donation to support you      project]
In-Reply-To: <2468.192.168.0.242.1204346451.squirrel@www.shiningsilence.com>
Message-ID: <47C9C1B7.50203@netphreax.net>

Justin C. Sherrill wrote:
The "donation" happens after you place an "acknowledgement" on an open
source project's web page.  I'm putting those words in scare quotes
because I think it's a "payment" for an "advertisement".  The supplied
link has nothing to do with DragonFly, to say the least.

<a href="http://www.2insure4less.com /" title="We support FOSS software
projects.">Online Insurance Quotes</a>
To think our souls are only worth $50...
--
        Thomas E. Spanjaard
        tgen at netphreax.net
Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00000.pgp
Type: application/octet-stream
Size: 186 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080301/0d61e240/attachment-0006.obj>

From c.turner at 199technologies.org  Sat Mar  1 17:52:31 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Sat, 1 Mar 2008 17:52:31 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Misc. ACPI / suspend
Message-ID: <47CA073B.6020106@199technologies.org>

Wondering if anyone more well versed in the ACPI implementation could
comment on the applicability of:
http://lkml.org/lkml/2007/4/6/69

w/r/t the current state of the art in Dfly

(or BSD's in general)

Cheers!

- Chris




From elekktretterr at exemail.com.au  Sun Mar  2 00:41:25 2008
From: elekktretterr at exemail.com.au (Petr Janda)
Date: Sun, 2 Mar 2008 00:41:25 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: CARP question
Message-ID: <200803021934.21669.elekktretterr@exemail.com.au>

So Ive setup CARP on 2 DF-based mailservers. Installation went fine. Box 1 has 
adskew of 0 therefore it is the MASTER. Box 2 has adskew of 254, therefore is 
BACKUP.  If i down the carp0 interface on Box 1, then Box 2 carp interface 
gets promoted to MASTER. Then I up the carp interface on Box 1, logically Box 
2 should become BACKUP again as Box 1 becomes MASTER due to adskew set to 0.

However it doesnt happen. When carp0 interface on Box 1 is upped it becomes a 
BACKUP, not a MASTER even though according to adskew it should be MASTER.

What is the desired behaviour?

Cheers
Petr




From qhwt+dfly at les.ath.cx  Sun Mar  2 02:50:14 2008
From: qhwt+dfly at les.ath.cx (YONETANI Tomokazu)
Date: Sun, 2 Mar 2008 02:50:14 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: panic: assertion: hammer_btree_cmp(cursor->left_bound,	&cursor->node->ondisk->elms[0].leaf.base) <= 0 in btree_split_leaf
In-Reply-To: <200802232204.m1NM4cxd046264@apollo.backplane.com>
Message-ID: <20080302104554.GA22813@les.ath.cx>

Hi.
While trying to find a procedure to reliably reproduce the panic
I reported last time, I caught a different panic (uploaded at
 ~y0netan1/crash/9/ on my leaf account).  I wrote the following shell
script (make sure to edit variables DISKS and MOUNTPT before using this
script or it may trash your system):
  #!/bin/sh -ex
  DISKS="/dev/ad0s1f"
  MOUNTPT=/mnt/HAMMER

  cd /
  newfs_hammer -L TEST $DISKS
  for i in `seq 1 100`; do
	  mount_hammer $DISKS $MOUNTPT
	  /bin/rm -rf $MOUNTPT/??
	  (set +x; for x in `seq 1 10000`; do echo -n > $MOUNTPT/$x; done)
	  umount $MOUNTPT
  done

And the panic is triggered by rm command.
I'll try to see if it's possible to reproduce the last one without
unmounting then mounting the HAMMER fs.

Cheers.




From dillon at apollo.backplane.com  Sun Mar  2 13:25:33 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Sun, 2 Mar 2008 13:25:33 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: panic: assertion: hammer_btree_cmp(cursor->left_bound,	&cursor->node->ondisk->elms[0].leaf.base) <= 0 in btree_split_leaf
In-Reply-To: <200802232204.m1NM4cxd046264@apollo.backplane.com>
Message-ID: <200803022119.m22LJRCY037076@apollo.backplane.com>


:Hi.
:While trying to find a procedure to reliably reproduce the panic
:I reported last time, I caught a different panic (uploaded at
: ~y0netan1/crash/9/ on my leaf account).  I wrote the following shell
:script (make sure to edit variables DISKS and MOUNTPT before using this
:script or it may trash your system):

(from the core)

panic: assertion: node->lock.refs == 0 && node->ondisk == NULL in hammer_flush_buffer_nodes

    Yah, I've seen this failure.  Add a sync or two before the umount and
    tell me if it still occurs.  It's either a node reference leak somewhere
    or it is a race between bufdaemon and umount.  The assertions are really
    strict there precisely to catch those sorts of cases.

    Also note that the code to deal with a full HAMMMER filesystem has not
    been written yet (The failure you are reporting is unrelated to a full
    HAMMER filesystem, though, just mentioning it).

						-Matt





From dillon at apollo.backplane.com  Sun Mar  2 13:29:03 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Sun, 2 Mar 2008 13:29:03 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Misc. ACPI / suspend
In-Reply-To: <47CA073B.6020106@199technologies.org>
Message-ID: <200803022126.m22LQbfI037188@apollo.backplane.com>


:Wondering if anyone more well versed in the ACPI implementation could
:comment on the applicability of:
:
:http://lkml.org/lkml/2007/4/6/69
:
:w/r/t the current state of the art in Dfly
:
:(or BSD's in general)
:
:Cheers!
:
:- Chris

    I really have no idea re: this.  Suspension in general is not well
    supported by any of the BSDs.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From dillon at apollo.backplane.com  Sun Mar  2 13:34:05 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Sun, 2 Mar 2008 13:34:05 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: [Fwd: Project Support Open Source: $50 donation to support you      project]
In-Reply-To: <2468.192.168.0.242.1204346451.squirrel@www.shiningsilence.com>
Message-ID: <200803022131.m22LVOe9037250@apollo.backplane.com>

:..
:source project's web page.  I'm putting those words in scare quotes
:because I think it's a "payment" for an "advertisement".  The supplied
:link has nothing to do with DragonFly, to say the least.
:
:I don't think this is a good idea, obviously, and replied to that effect. 
:However, I wanted to put this on a DragonFly list, in part to show this
:strange thing, and in part because I'm not comfortable making
:administrative decisions on behalf of the Project without being open as
:possible about it.

    It doesn't really cry out to me either.

						-Matt





From wbh at conducive.org  Sun Mar  2 20:36:32 2008
From: wbh at conducive.org (Bill Hacker)
Date: Mon, 03 Mar 2008 04:36:32 +0000
Subject: Misc. ACPI / suspend
In-Reply-To: <47CA073B.6020106@199technologies.org>
Message-ID: <47cb8050$0$855$415eb37d@crater_reader.dragonflybsd.org>

Matthew Dillon wrote:
:Wondering if anyone more well versed in the ACPI implementation could
:comment on the applicability of:
:
:http://lkml.org/lkml/2007/4/6/69
:
:w/r/t the current state of the art in Dfly
:
:(or BSD's in general)
:
:Cheers!
:
:- Chris
    I really have no idea re: this.  Suspension in general is not well
    supported by any of the BSDs.
					-Matt
					Matthew Dillon 
					<dillon at backplane.com>


. . and there seems to be a bit of a 'Catch 22' there in any case.

If the BIOS can alter 'stuff' out of site of the OS it is parking, what 
does the existence of such a 'feature' do to a(ny) security model?

Seems to at least beg creating the option of setting a flag to 
specifically *prevent* suspend-to-disk/hibernation (and/or force a 
reboot on wake-up).

Just because one is paranoid....  etc

Bill





From matthias at dragonflybsd.org  Tue Mar  4 02:30:52 2008
From: matthias at dragonflybsd.org (Matthias Schmidt)
Date: Tue, 4 Mar 2008 02:30:52 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
Message-ID: <20080304102335.GI9833@staatsfeind.org>

Hi,

Google just announced its Summer of Code for 2008:

	http://code.google.com/soc/2008/

I think this would be a great opportunity for DragonFly to participate
as a mentoring organisation.  We could attract new developers and could
get code/work done.  Looking at the SoC results of the other BSDs most
of their projects were a success.  Of course, not all, but a reasonable
percentage.  See [1] and [2].

It is some extra work for us, but IMO the benefits outweigh the extra
work.  And yes, I would volunteer as a mentor.  What do others
(developers) think?  Any more volunteers? :)

Some project ideas that come into my mind.  More ideas are listed in the
wiki:  http://wiki.dragonflybsd.org/index.cgi/ProjectsPage

 * Fix all remaining bugs in dma(8) and implement all missing features
 * Add a driver for newer Intel Wireless cards (I think sephe@ would
   love that :)
 * Bring our ACPI stuff in shape.  Maybe suspend2disk ...

 * [Add your own thoughts here]

Cheers,

	Matthias

PS: I don't want to create a bikeshed here whether you like the SoC or
not :)

[1] http://code.google.com/soc/2007/freebsd/about.html
[2] http://code.google.com/soc/2007/netbsd/about.html




From corecode at fs.ei.tum.de  Tue Mar  4 04:46:14 2008
From: corecode at fs.ei.tum.de (Simon 'corecode' Schubert)
Date: Tue, 4 Mar 2008 04:46:14 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47CD4386.1000704@fs.ei.tum.de>

Matthias Schmidt wrote:
>  * [Add your own thoughts here]

MP lock removal for network stack

and for the system  (first profile, find hot spots, fix hot spots, repeat)

cheers
  simon




From c.turner at 199technologies.org  Tue Mar  4 06:02:20 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Tue, 4 Mar 2008 06:02:20 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47CD551E.1040604@199technologies.org>

Matthias Schmidt wrote:
Some project ideas that come into my mind.  More ideas are listed in the
wiki:  http://wiki.dragonflybsd.org/index.cgi/ProjectsPage
+1 acpi
+1 interrupt routing
+1 SMP / giant removal
+1 pf synchup with openbsd
though there are several others on the page that are good..

need to dig up my wiki login and place appropriately..

also: thinking the ZFS port should be removed from the page - makes 
sense to everyone else? (e.g. fragments effort w/r/t hammer)





From tgen at netphreax.net  Tue Mar  4 06:54:31 2008
From: tgen at netphreax.net (Thomas E. Spanjaard)
Date: Tue, 4 Mar 2008 06:54:31 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47CD615F.8010209@netphreax.net>

Matthias Schmidt wrote:
Google just announced its Summer of Code for 2008:

 * [Add your own thoughts here]
x86-64 port :).
--
        Thomas E. Spanjaard
        tgen at netphreax.net
Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00001.pgp
Type: application/octet-stream
Size: 186 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080304/0d921000/attachment-0006.obj>

From rdivacky at FreeBSD.org  Tue Mar  4 07:07:03 2008
From: rdivacky at FreeBSD.org (Roman Divacky)
Date: Tue, 4 Mar 2008 07:07:03 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <20080304150255.GA8831@freebsd.org>

On Tue, Mar 04, 2008 at 02:49:03PM +0000, Thomas E. Spanjaard wrote:
> Matthias Schmidt wrote:
> >Google just announced its Summer of Code for 2008:
> >
> > * [Add your own thoughts here]
> 
> x86-64 port :).

all those ideas are great and needed etc. but keep in
mind that the projects should be doable by students
who might see dfly for the very first time.

don't overestimate whats possible and select projects
that look realistic

Roman Divacky (former SoC student)




From justin at shiningsilence.com  Tue Mar  4 08:32:56 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Tue, 4 Mar 2008 08:32:56 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <60322.65.106.147.226.1204648095.squirrel@www.shiningsilence.com>

On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
> Hi,
>
> Google just announced its Summer of Code for 2008:
>
> 	http://code.google.com/soc/2008/
>
> I think this would be a great opportunity for DragonFly to participate
> as a mentoring organisation.  We could attract new developers and could
> get code/work done.  Looking at the SoC results of the other BSDs most
> of their projects were a success.  Of course, not all, but a reasonable
> percentage.  See [1] and [2].

We've applied in previous years - Jeff Hsu did one year, and I put
together the application last year.  The hardest thing to find was
students (and they are the thing that helps SoC applications a lot, I
think).

Any student volunteers?  We have mentors.





From rluciani at gmail.com  Tue Mar  4 09:38:29 2008
From: rluciani at gmail.com (Robert Luciani)
Date: Tue, 04 Mar 2008 18:38:29 +0100
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47cd8915$0$854$415eb37d@crater_reader.dragonflybsd.org>

Justin C. Sherrill wrote:
> On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
>> Hi,
>>
>> Google just announced its Summer of Code for 2008:
>>
>> 	http://code.google.com/soc/2008/
>>
>> I think this would be a great opportunity for DragonFly to participate
>> as a mentoring organisation.  We could attract new developers and could
>> get code/work done.  Looking at the SoC results of the other BSDs most
>> of their projects were a success.  Of course, not all, but a reasonable
>> percentage.  See [1] and [2].
> 
> We've applied in previous years - Jeff Hsu did one year, and I put
> together the application last year.  The hardest thing to find was
> students (and they are the thing that helps SoC applications a lot, I
> think).
> 
> Any student volunteers?  We have mentors.
> 

bingo

-- 
Robert Luciani
Chalmers University of Technology, SWE
Department of Computer Science and Engineering
http://www.rluciani.com/public.key




From sdavtaker at gmail.com  Tue Mar  4 09:31:08 2008
From: sdavtaker at gmail.com (=?UTF-8?Q?Sd=C3=A4vtaker?=)
Date: Tue, 4 Mar 2008 09:31:08 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <c37d69f60803040926k206218a3kb8496d0cd18148bd@mail.gmail.com>

If you mentor, i will apply for coder :-)
Still in last year of university. :-)
Sdav

On Tue, Mar 4, 2008 at 1:28 PM, Justin C. Sherrill
<justin at shiningsilence.com> wrote:
> On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
>  > Hi,
>  >
>  > Google just announced its Summer of Code for 2008:
>  >
>  >       http://code.google.com/soc/2008/
>  >
>  > I think this would be a great opportunity for DragonFly to participate
>  > as a mentoring organisation.  We could attract new developers and could
>  > get code/work done.  Looking at the SoC results of the other BSDs most
>  > of their projects were a success.  Of course, not all, but a reasonable
>  > percentage.  See [1] and [2].
>
>  We've applied in previous years - Jeff Hsu did one year, and I put
>  together the application last year.  The hardest thing to find was
>  students (and they are the thing that helps SoC applications a lot, I
>  think).
>
>  Any student volunteers?  We have mentors.
>
>



-- 
Sd?vtaker prays to Rikku goddess for a good treasure.



From rluciani at gmail.com  Tue Mar  4 09:44:02 2008
From: rluciani at gmail.com (Robert Luciani)
Date: Tue, 04 Mar 2008 18:44:02 +0100
Subject: google soc "DragonFly"
Message-ID: <47cd8a63$0$855$415eb37d@crater_reader.dragonflybsd.org>

On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
> > Hi,
> >
> > Google just announced its Summer of Code for 2008:
> >
> > 	http://code.google.com/soc/2008/
> >
> > I think this would be a great opportunity for DragonFly to participate
> > as a mentoring organisation.  We could attract new developers and could
> > get code/work done.  Looking at the SoC results of the other BSDs most
> > of their projects were a success.  Of course, not all, but a reasonable
> > percentage.  See [1] and [2].

We've applied in previous years - Jeff Hsu did one year, and I put
together the application last year.  The hardest thing to find was
students (and they are the thing that helps SoC applications a lot, I
think).

Any student volunteers?  We have mentors.


-- 
Robert Luciani
Chalmers University of Technology, SWE
Department of Computer Science and Engineering
http://www.rluciani.com/public.key




From rluciani at gmail.com  Tue Mar  4 10:04:14 2008
From: rluciani at gmail.com (Robert Luciani)
Date: Tue, 04 Mar 2008 19:04:14 +0100
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47cd8f1f$0$856$415eb37d@crater_reader.dragonflybsd.org>

Robert Luciani wrote:
> Justin C. Sherrill wrote:
>> On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
>>> Hi,
>>>
>>> Google just announced its Summer of Code for 2008:
>>>
>>> 	http://code.google.com/soc/2008/
>>>
>>> I think this would be a great opportunity for DragonFly to participate
>>> as a mentoring organisation.  We could attract new developers and could
>>> get code/work done.  Looking at the SoC results of the other BSDs most
>>> of their projects were a success.  Of course, not all, but a reasonable
>>> percentage.  See [1] and [2].
>> We've applied in previous years - Jeff Hsu did one year, and I put
>> together the application last year.  The hardest thing to find was
>> students (and they are the thing that helps SoC applications a lot, I
>> think).
>>
>> Any student volunteers?  We have mentors.
>>
> 
> bingo
> 
My girlfriend Danwei noted that she would also like partake in the SoC.
She's studying IT here at Chalmers and will join the mailing list shortly.
-- 
Robert Luciani
Chalmers University of Technology, SWE
Department of Computer Science and Engineering
http://www.rluciani.com/public.key




From dillon at apollo.backplane.com  Tue Mar  4 13:08:30 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Tue, 4 Mar 2008 13:08:30 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Going to have to roll 1.12.1
Message-ID: <200803042104.m24L43g1065278@apollo.backplane.com>

    Due to a critical bug in sendmail that can cause it to seg-fault I will
    be rolling 1.12.1 as soon as I get verification that the current
    fix deals with it.

						-Matt





From sdavtaker at gmail.com  Tue Mar  4 17:40:43 2008
From: sdavtaker at gmail.com (=?UTF-8?B?U2TDpHZ0YWtlcg==?=)
Date: Tue, 4 Mar 2008 17:40:43 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: [Fwd: Project Support Open Source: $50 donation to support you  project]
In-Reply-To: <2468.192.168.0.242.1204346451.squirrel@www.shiningsilence.com>
Message-ID: <47CDF8D1.9070100@gmail.com>

50 bucks?
Come on...
You can get a meal a lot more expensive than that just going to a free 
HP conference about linux and you only have to rent your soul 3-5 hours ;-)
Sdav

Matthew Dillon escribi?:
:..
:source project's web page.  I'm putting those words in scare quotes
:because I think it's a "payment" for an "advertisement".  The supplied
:link has nothing to do with DragonFly, to say the least.
:
:I don't think this is a good idea, obviously, and replied to that effect. 
:However, I wanted to put this on a DragonFly list, in part to show this
:strange thing, and in part because I'm not comfortable making
:administrative decisions on behalf of the Project without being open as
:possible about it.

    It doesn't really cry out to me either.

						-Matt

  






From sdavtaker at gmail.com  Tue Mar  4 17:56:35 2008
From: sdavtaker at gmail.com (=?UTF-8?B?U2TDpHZ0YWtlcg==?=)
Date: Tue, 4 Mar 2008 17:56:35 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47CDFCCE.1010106@gmail.com>

A cute idea for for GSOC would be to finish the installer.
We were talking about this in my local BUG, we trying to find out how to 
help on that from here.
There is a few missing features in the CD.

   * FDISK, you need to create the slides from another OS before
     install DFBSD, i think port FDisk from FBSD or any *BSD will solve it.
   * Add to the make release a way to add some custom applications to
     the released liveCD (suppose you want to add nmap or ssh or
     something just to use as test disk in some enviroment).
   * Make the installer a little more customizable, and maybe w/ a GUI
     (I like a lot the console approach, but GUI installer will be a
     popularity move, DFBSD w/X makes a Desktop machine work, actually
     im using it that way and really like it).
I think those projects can be done in a SOC by students (like me) with a 
little guide.
Im a lot more interested in things network related and kernel, but i 
dont mind to work on those things, they need to be done some day.
What u think?
Sdav

Robert Luciani escribi?:
Robert Luciani wrote:
  
Justin C. Sherrill wrote:
    
On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
      
Hi,

Google just announced its Summer of Code for 2008:

	http://code.google.com/soc/2008/

I think this would be a great opportunity for DragonFly to participate
as a mentoring organisation.  We could attract new developers and could
get code/work done.  Looking at the SoC results of the other BSDs most
of their projects were a success.  Of course, not all, but a reasonable
percentage.  See [1] and [2].
        
We've applied in previous years - Jeff Hsu did one year, and I put
together the application last year.  The hardest thing to find was
students (and they are the thing that helps SoC applications a lot, I
think).
Any student volunteers?  We have mentors.

      
bingo

    
My girlfriend Danwei noted that she would also like partake in the SoC.
She's studying IT here at Chalmers and will join the mailing list shortly.
  






From c.turner at 199technologies.org  Tue Mar  4 18:30:53 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Tue, 4 Mar 2008 18:30:53 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47CE04C9.1010902@199technologies.org>

Justin C. Sherrill wrote:
together the application last year.  The hardest thing to find was
students (and they are the thing that helps SoC applications a lot, I
think).
umm.. if google wants to send me back to school, I'll sign up - hows 
that for a fair trade :?






From wbh at conducive.org  Tue Mar  4 23:52:13 2008
From: wbh at conducive.org (Bill Hacker)
Date: Wed, 05 Mar 2008 07:52:13 +0000
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47ce512e$0$855$415eb37d@crater_reader.dragonflybsd.org>

Sd?vtaker wrote:
A cute idea for for GSOC would be to finish the installer.
We were talking about this in my local BUG, we trying to find out how to 
help on that from here.
There is a few missing features in the CD.

   * FDISK, you need to create the slides from another OS before
     install DFBSD, i think port FDisk from FBSD or any *BSD will solve it.
I'd rather see that 'reversed' - i.e. - build a more capable fdisk in 
DFLY with hope that it might be seen worth importing into Free/Net/Open, 
or *at least* be able to do a more flexible job than those now do.

And disklabels as well. Hand in glove.

Here's why:

- At the moment, working with Free, Open, DFLY, and OpenSolaris on the 
same HDD requires a bit of acrobatics.

- There seems to now be greater divergence between/among the *BSD's as 
to being able to read each other's disklabels, mount and use each 
other's 'flavor' of FFS/UFS (not to mention Apple's implementation of 
UFS) than there is among the vast multitude of Linux ext2/3 denizens.

Even to the point where use of a *Linux* fs is the more universal way 
for being able to share mounts among the *BSD's. Think detached drives. 
And no - FAT is not all that practical for several reasons.

- DFLY currently has the most fine-grain ability to create slices and 
partitions. But the others cannot all (any?) read those.

'progress' w/r any of the *BSD's direction as to changes, improvements 
(or not) in their once-common-ancestry fs & disklabels need not be 
sacrificed.

I'm not holding out wish or hope for all players agreeing to return to 
'one sacred way'. Nor 'one new universal fs'. Neither is gonna happen.

But a 'legacy compatible' or least-common-denominator mode would do fine 
- most especially for portable / SAN devices.

So - how about a 'flexible' DFLY fdisk to go along with a 'flexible' 
disklabel that could adapt to whatever it found / was told to create?

JM2CW - but that *might* be a good place to get a cross-*BSD team together.

*snip* (other good stuff)

Bill Hacker




From matthias at dragonflybsd.org  Wed Mar  5 01:02:43 2008
From: matthias at dragonflybsd.org (Matthias Schmidt)
Date: Wed, 5 Mar 2008 01:02:43 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <20080305085747.GJ9833@staatsfeind.org>

Hi,

* Justin C. Sherrill wrote:
> 
> We've applied in previous years - Jeff Hsu did one year, and I put
> together the application last year.  The hardest thing to find was
> students (and they are the thing that helps SoC applications a lot, I
> think).

This is good to know, so we could coordinate that if we have enough
mentors and projects?!?  I put together a small text in the wiki:

http://wiki.dragonflybsd.org/index.cgi/GoogleSoC2008

Feel free to add project or missing stuff.  I'm sure I missed a lot of
things :)

> Any student volunteers?  We have mentors.

According to the discussion we could have some students, who would be a
mentor (besides me)?

Regards

	Matthias





From sdavtaker at gmail.com  Wed Mar  5 06:28:37 2008
From: sdavtaker at gmail.com (=?UTF-8?Q?Sd=C3=A4vtaker?=)
Date: Wed, 5 Mar 2008 06:28:37 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <c37d69f60803050624kd86d3d0w3b44a02d0e5a5391@mail.gmail.com>

<quote>
Write a driver (from scratch) for Intel 3945 wireless device
Mentor: Sepherosa Ziehau
</quote>

Yes yes yes, i want to :-)
Someone else planning to mentor in drivers coding?
Sdav

On Wed, Mar 5, 2008 at 5:57 AM, Matthias Schmidt
<matthias at dragonflybsd.org> wrote:
> Hi,
>
>
>  * Justin C. Sherrill wrote:
>  >
>  > We've applied in previous years - Jeff Hsu did one year, and I put
>  > together the application last year.  The hardest thing to find was
>  > students (and they are the thing that helps SoC applications a lot, I
>  > think).
>
>  This is good to know, so we could coordinate that if we have enough
>  mentors and projects?!?  I put together a small text in the wiki:
>
>  http://wiki.dragonflybsd.org/index.cgi/GoogleSoC2008
>
>  Feel free to add project or missing stuff.  I'm sure I missed a lot of
>  things :)
>
>
>  > Any student volunteers?  We have mentors.
>
>  According to the discussion we could have some students, who would be a
>  mentor (besides me)?
>
>  Regards
>
>         Matthias
>
>



-- 
Sd?vtaker prays to Rikku goddess for a good treasure.



From rluciani at gmail.com  Wed Mar  5 10:56:42 2008
From: rluciani at gmail.com (Robert Luciani)
Date: Wed, 05 Mar 2008 19:56:42 +0100
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47ceecea$0$847$415eb37d@crater_reader.dragonflybsd.org>

Sd?vtaker wrote:
> <quote>
> Write a driver (from scratch) for Intel 3945 wireless device
> Mentor: Sepherosa Ziehau
> </quote>
> 
> Yes yes yes, i want to :-)
> Someone else planning to mentor in drivers coding?
> Sdav
> 
> On Wed, Mar 5, 2008 at 5:57 AM, Matthias Schmidt
> <matthias at dragonflybsd.org> wrote:
>> Hi,
>>
>>
>>  * Justin C. Sherrill wrote:
>>  >
>>  > We've applied in previous years - Jeff Hsu did one year, and I put
>>  > together the application last year.  The hardest thing to find was
>>  > students (and they are the thing that helps SoC applications a lot, I
>>  > think).
>>
>>  This is good to know, so we could coordinate that if we have enough
>>  mentors and projects?!?  I put together a small text in the wiki:
>>
>>  http://wiki.dragonflybsd.org/index.cgi/GoogleSoC2008
>>
>>  Feel free to add project or missing stuff.  I'm sure I missed a lot of
>>  things :)
>>
>>
>>  > Any student volunteers?  We have mentors.
>>
>>  According to the discussion we could have some students, who would be a
>>  mentor (besides me)?
>>
>>  Regards
>>
>>         Matthias
>>
>>
> 
> 
>

IF someone starts to write a 3945 Intel driver,
please keep the newer 4965 in mind too.

-- 
Robert Luciani
Chalmers University of Technology, SWE
Department of Computer Science and Engineering
http://www.rluciani.com/public.key




From joerg at britannica.bec.de  Wed Mar  5 12:01:05 2008
From: joerg at britannica.bec.de (Joerg Sonnenberger)
Date: Wed, 5 Mar 2008 12:01:05 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <20080305195711.GA9981@britannica.bec.de>

On Wed, Mar 05, 2008 at 07:56:42PM +0100, Robert Luciani wrote:
> IF someone starts to write a 3945 Intel driver,
> please keep the newer 4965 in mind too.

NetBSD's wpi works quite well. The hardware is quite different from
4945.

Joerg




From sepherosa at gmail.com  Wed Mar  5 17:48:50 2008
From: sepherosa at gmail.com (Sepherosa Ziehau)
Date: Wed, 5 Mar 2008 17:48:50 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <ea7b9c170803051744u22b09484ofc994f034f11df3b@mail.gmail.com>

On Thu, Mar 6, 2008 at 2:56 AM, Robert Luciani <rluciani at gmail.com> wrote:
>  IF someone starts to write a 3945 Intel driver,

"IF" you know that trying to fix any wired bugs in certain drivers
(e.g. ipw, ral) will require you to read through all of the vendor's
linux code (yes, even including register values and position), i.e.
there is not much difference between writing one from scratch and
porting+fixing_bugs, then you probably will not put "IF" at the start
of your sentence.
If what I said sounded too harsh to you, then I was sorry.

>  please keep the newer 4965 in mind too.

Will do, once generic 11n support is brought in from freebsd.

Best Regards,
sephe

-- 
Live Free or Die




From saw at online.de  Thu Mar  6 05:34:14 2008
From: saw at online.de (Sascha Wildner)
Date: Thu, 06 Mar 2008 14:34:14 +0100
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
Message-ID: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>

Hi all,

this is probably as good a moment as any to come out of the forest with 
this. The patch at

http://leaf.dragonflybsd.org/~swildner/nrelease_gui.diff

adds some code to nrelease/ to build a LiveCD with xorg and so on 
(currently, only the xorg metapackages and fluxbox are added). In order 
to build one, you need a local dir with the pkgsrc binary packages (see 
below).

The following commands should then do the trick:

cd /usr/src
make buildworld
make buildkernel
cd nrelease
patch -p 0 </path/to/the/patch
make PKGSRC_PKG_PATH=/path/to/packages/dir/All realquick gui
The resulting ISO will be in /usr/release/dfly-gui.iso then. It will not 
boot into xorg automatically (although this is easily possible), so you 
need to login as root and do startx.

As of now, this all is kind of basic, more a proof of concept than 
anything else. As our release framework installs packages via chroot, 
the current setup just copies _all_ packages to the chroot before 
installing (kind of a hack).

That said, I'm now primarily interested in opinions/ideas/... about the 
direction this should take. Which packages would we like to see on the 
CD? Should it be a generic setup with the "most common things" 
installed, so a system can be quickly setup by the installer (which will 
cpdup /usr/pkg). Or should it be a more specialized set of tools? Or 
even as many packages as possible (Live DVD?). Etc., etc.

Before continuing on it, I'm really interested in people's input so 
don't hold anything back, please. :)

Sascha

--
http://yoyodyne.ath.cx



From rluciani at gmail.com  Thu Mar  6 06:42:03 2008
From: rluciani at gmail.com (Robert Luciani)
Date: Thu, 06 Mar 2008 15:42:03 +0100
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <47d002bc$0$847$415eb37d@crater_reader.dragonflybsd.org>

Sascha Wildner wrote:
> Hi all,
> 
> this is probably as good a moment as any to come out of the forest with
> this. The patch at
> 
> http://leaf.dragonflybsd.org/~swildner/nrelease_gui.diff
> 
> adds some code to nrelease/ to build a LiveCD with xorg and so on
> (currently, only the xorg metapackages and fluxbox are added). In order
> to build one, you need a local dir with the pkgsrc binary packages (see
> below).
> 
> The following commands should then do the trick:
> 
> cd /usr/src
> make buildworld
> make buildkernel
> cd nrelease
> patch -p 0 </path/to/the/patch
> make PKGSRC_PKG_PATH=/path/to/packages/dir/All realquick gui
> 
> The resulting ISO will be in /usr/release/dfly-gui.iso then. It will not
> boot into xorg automatically (although this is easily possible), so you
> need to login as root and do startx.
> 
> As of now, this all is kind of basic, more a proof of concept than
> anything else. As our release framework installs packages via chroot,
> the current setup just copies _all_ packages to the chroot before
> installing (kind of a hack).
> 
> That said, I'm now primarily interested in opinions/ideas/... about the
> direction this should take. Which packages would we like to see on the
> CD? Should it be a generic setup with the "most common things"
> installed, so a system can be quickly setup by the installer (which will
> cpdup /usr/pkg). Or should it be a more specialized set of tools? Or
> even as many packages as possible (Live DVD?). Etc., etc.
> 
> Before continuing on it, I'm really interested in people's input so
> don't hold anything back, please. :)
> 
> Sascha
> 

I think the main point of such a live-cd would be to test
dragonfly-specific features such as vkernels and more. Mplayer and
OpenOffic work the same on all platforms, so they might not be super
important, while irssi, firefox, networking tools, vim, a few more
shells/terminals might make it easier to for people to quickly gauge if
they can reproduce their current productivity and also what is new.

And if the point of a livecd is to test that kind of stuff, then it
would be nice for it to have a kernel that supports as much as possible
like ALTQ, and drivers.

Also if it has lots and lots of programs (thinking multimedia, java,
etc..) it might be hard to keep the future x64 and x86 live-cds on par.
Gentoo had this problem many years ago and it was very bothersome.

-- 
Robert Luciani
Chalmers University of Technology, SWE
Department of Computer Science and Engineering
http://www.rluciani.com/public.key




From matthias at dragonflybsd.org  Thu Mar  6 07:12:43 2008
From: matthias at dragonflybsd.org (Matthias Schmidt)
Date: Thu, 6 Mar 2008 07:12:43 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <20080306150757.GN9833@staatsfeind.org>

* Sascha Wildner wrote:
> Hi all,
> 
> this is probably as good a moment as any to come out of the forest with this. 
> The patch at
> 
> http://leaf.dragonflybsd.org/~swildner/nrelease_gui.diff
> 
> adds some code to nrelease/ to build a LiveCD with xorg and so on (currently, 
> only the xorg metapackages and fluxbox are added). In order to build one, you 
> need a local dir with the pkgsrc binary packages (see below).

Great work Sascha.

I agree with Robert on most of his stated points.
It would be nice to see some DragonFly specific features on the CD
(although I'm not sure if that will work for all features).  A little
environment where most Unix users feel at home (fluxbox, xfce, firefox,
thunderbird, gvim) should be enough.

Big applications like OO.org, java etc won't work because they are not
available as pkgsrc packages neither is it possible to compile them on
DragonFly.  At least to my knowledge.

Regards

	Matthias




From dillon at apollo.backplane.com  Thu Mar  6 09:31:52 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Thu, 6 Mar 2008 09:31:52 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <200803061728.m26HSR3O091809@apollo.backplane.com>


:Hi all,
:
:this is probably as good a moment as any to come out of the forest with 
:this. The patch at
:
:http://leaf.dragonflybsd.org/~swildner/nrelease_gui.diff
:
:adds some code to nrelease/ to build a LiveCD with xorg and so on 
:(currently, only the xorg metapackages and fluxbox are added). In order 
:to build one, you need a local dir with the pkgsrc binary packages (see 
:below).
:
:The following commands should then do the trick:

    It looks reasonable, though the package copy has to be tightened
    up a bit I think.

:...
:installed, so a system can be quickly setup by the installer (which will 
:cpdup /usr/pkg). Or should it be a more specialized set of tools? Or 
:even as many packages as possible (Live DVD?). Etc., etc.
:
:Before continuing on it, I'm really interested in people's input so 
:don't hold anything back, please. :)
:
:Sascha

    I think this is an excellent time to work up a DVD build and to
    add various 'flavor' extras.  So, e.g.:

	make installer gui gui_extras release dvd

    (All 'dvd' would do is generate a dvd compatible image for burning to
    dvd instead of cd).  I did a quick perusal of what I have on my
    workstation:

    * X
    * Firefox
    * Linux emulation
    * Open Office (linux version)
    * fvwm2
    * xpdf
    * freetype2

    I'd also suggest some image editing tools like gimp, and maybe the KDE
    gui suite.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From justin at shiningsilence.com  Thu Mar  6 09:42:44 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Thu, 6 Mar 2008 09:42:44 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <55427.65.106.147.226.1204825168.squirrel@www.shiningsilence.com>

On Thu, March 6, 2008 8:34 am, Sascha Wildner wrote:

> That said, I'm now primarily interested in opinions/ideas/... about the
> direction this should take. Which packages would we like to see on the
> CD? Should it be a generic setup with the "most common things"
> installed, so a system can be quickly setup by the installer (which will
> cpdup /usr/pkg). Or should it be a more specialized set of tools? Or
> even as many packages as possible (Live DVD?). Etc., etc.

What Robert said is good - whatever's needed to enable DragonFly-specific
features.  Along with that would be some sort of documentation (a README? 
A HTML file on whatever desktop we provide) that points people at the
different DragonFly tools, so they know what to try and how to try it.

There's going to be some percentage of people who try DragonFly who don't
know about vkernels, for instance, but there's our chance to educate them.
 I'm probably volunteering myself, aren't I?





From sdavtaker at gmail.com  Thu Mar  6 09:50:09 2008
From: sdavtaker at gmail.com (=?UTF-8?Q?Sd=C3=A4vtaker?=)
Date: Thu, 6 Mar 2008 09:50:09 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <c37d69f60803060947t110750c0sd6b542ea505d188d@mail.gmail.com>

Cool Sascha :-)
I just posted about this 1 or 2 days ago in the SOC project ideas thread.
Want to mentor this one? ;-)
Damian

On Thu, Mar 6, 2008 at 2:28 PM, Matthew Dillon
<dillon at apollo.backplane.com> wrote:
>
>  :Hi all,
>
> :
>  :this is probably as good a moment as any to come out of the forest with
>  :this. The patch at
>  :
>  :http://leaf.dragonflybsd.org/~swildner/nrelease_gui.diff
>  :
>  :adds some code to nrelease/ to build a LiveCD with xorg and so on
>  :(currently, only the xorg metapackages and fluxbox are added). In order
>  :to build one, you need a local dir with the pkgsrc binary packages (see
>  :below).
>  :
>  :The following commands should then do the trick:
>
>     It looks reasonable, though the package copy has to be tightened
>     up a bit I think.
>
>  :...
>  :installed, so a system can be quickly setup by the installer (which will
>
> :cpdup /usr/pkg). Or should it be a more specialized set of tools? Or
>  :even as many packages as possible (Live DVD?). Etc., etc.
>  :
>  :Before continuing on it, I'm really interested in people's input so
>  :don't hold anything back, please. :)
>  :
>  :Sascha
>
>     I think this is an excellent time to work up a DVD build and to
>     add various 'flavor' extras.  So, e.g.:
>
>         make installer gui gui_extras release dvd
>
>     (All 'dvd' would do is generate a dvd compatible image for burning to
>     dvd instead of cd).  I did a quick perusal of what I have on my
>     workstation:
>
>     * X
>     * Firefox
>     * Linux emulation
>     * Open Office (linux version)
>     * fvwm2
>     * xpdf
>     * freetype2
>
>     I'd also suggest some image editing tools like gimp, and maybe the KDE
>     gui suite.
>
>                                         -Matt
>                                         Matthew Dillon
>                                         <dillon at backplane.com>
>



-- 
Sd?vtaker prays to Rikku goddess for a good treasure.



From saw at online.de  Thu Mar  6 11:54:01 2008
From: saw at online.de (Sascha Wildner)
Date: Thu, 06 Mar 2008 20:54:01 +0100
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <47d04ba2$0$856$415eb37d@crater_reader.dragonflybsd.org>

Matthew Dillon wrote:
    It looks reasonable, though the package copy has to be tightened
    up a bit I think.
It looks as if it would work with mount_null'ing the chroot's 
/tmp/packages. I'll have a better patch ready tomorrow.

Sascha

--
http://yoyodyne.ath.cx



From c.turner at 199technologies.org  Thu Mar  6 19:11:44 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Thu, 6 Mar 2008 19:11:44 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Misc. ACPI / suspend
In-Reply-To: <47CA073B.6020106@199technologies.org>
Message-ID: <47D0B079.3060905@199technologies.org>

Chris Turner wrote:
Wondering if anyone more well versed in the ACPI implementation could
comment on the applicability of:
http://lkml.org/lkml/2007/4/6/69

Doing a little digging, it seems like

. /platform/pc32/i386/i686_mem.c

*might* have the necessary infrastructure to remap the MTRR's per the 
thread referenced,

but:

. /platform/pc32/acpica5/acpi_wakeup.c

doesn't seem to be using this infrastructure..

I'm no where near reaching an understanding of this yet,
but I'm wondering 3 things:
1) does anyone have ACPI (instead of APM)
   sleep / suspend / wakeup working on Dfly ?
2) If so, what machines are being used ?
3) Same question for other BSDs - my understanding is NetBSD is most
   'advanced' w/r/t power managment - but I'm not 100% on this ...
would looove to have a sleeping / resuming / scaling laptop running some 
BSD flavor.. am willing to work towards that end, esp. w/r/t Dfly -
trying to chart a course to figguring this out.

Thanks all,

- Chris




From c.turner at 199technologies.org  Thu Mar  6 19:12:33 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Thu, 6 Mar 2008 19:12:33 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: PCI Bios / Interrupt remapping / etc
Message-ID: <47D0B211.6000002@199technologies.org>

Doing a bit of digging here for my long-standing CBB+SIO interupt and 
buffer problem -

one machine I've tested against was an OpenBSD machine, which didn't
always work to handle the cardbus sio card on a PCI cardbus adapter
-

tuning up some of the device flags in:

http://www.openbsd.org/cgi-bin/man.cgi?query=pcibios&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=html

seems to have alleviated the problem for that os..

I'm just only starting to get up to speed on how DF handles these types 
of things (namely initial PIC / interrupt layout at boot time device 
enumeration), but am wondering if anyone familiar with this area of the 
code has any comments / advice w/r/t the capabilities of the DF bios 
drivers
and the various quirks / fixup mentioned in the link above..

looking to possibly investigate fixing up some of these issues over time.

Thanks

- Chris







From pavalos at theshell.com  Fri Mar  7 01:14:55 2008
From: pavalos at theshell.com (Peter Avalos)
Date: Fri, 7 Mar 2008 01:14:55 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: cam locking
Message-ID: <20080307091024.GC1652@ylem.theshell.com>

So I've been working on locking up cam using lockmgr locks, and here's
what I have so far:

http://www.theshell.com/~pavalos/wip/cam-lock.patch

Most of the work is obtained from FreeBSD.  I've only been running this
on my SCSI machine for a day, but because the patch is so large, I wanted
to make it available for people to review if they have some spare time.

Thanks,
Peter
Attachment:
pgp00002.pgp
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00002.pgp
Type: application/octet-stream
Size: 197 bytes
Desc: "Description: PGP signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080307/9a17ecd8/attachment-0006.obj>

From jspringe at uos.de  Fri Mar  7 03:25:17 2008
From: jspringe at uos.de (Jost Tobias Springenberg)
Date: Fri, 7 Mar 2008 12:25:17 +0100
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <20080307122517.72c9e2b1.jspringe@uos.de>

On Tue, 4 Mar 2008 11:28:15 -0500 (EST)
"Justin C. Sherrill" <justin at shiningsilence.com> wrote:

> On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
> > Hi,
> >
> > Google just announced its Summer of Code for 2008:
> >
> > 	http://code.google.com/soc/2008/
> >
> > I think this would be a great opportunity for DragonFly to participate
> > as a mentoring organisation.  We could attract new developers and could
> > get code/work done.  Looking at the SoC results of the other BSDs most
> > of their projects were a success.  Of course, not all, but a reasonable
> > percentage.  See [1] and [2].
> 
> We've applied in previous years - Jeff Hsu did one year, and I put
> together the application last year.  The hardest thing to find was
> students (and they are the thing that helps SoC applications a lot, I
> think).
> 
> Any student volunteers?  We have mentors.
> 

I read this mailing list for quite a while now and thought about contributing stuff
to DFfly several times, so yes why not take this opportunity if it's there.

-- 
Jost Tobias Springenberg <jspringe at uos.de>




From tgen at netphreax.net  Fri Mar  7 05:17:27 2008
From: tgen at netphreax.net (Thomas E. Spanjaard)
Date: Fri, 7 Mar 2008 05:17:27 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: PCI Bios / Interrupt remapping / etc
In-Reply-To: <47D0B211.6000002@199technologies.org>
Message-ID: <47D13FB4.5080306@netphreax.net>

Chris Turner wrote:
Doing a bit of digging here for my long-standing CBB+SIO interupt and 
buffer problem -

one machine I've tested against was an OpenBSD machine, which didn't
always work to handle the cardbus sio card on a PCI cardbus adapter
-

tuning up some of the device flags in:

http://www.openbsd.org/cgi-bin/man.cgi?query=pcibios&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=html 

seems to have alleviated the problem for that os..

I'm just only starting to get up to speed on how DF handles these types 
of things (namely initial PIC / interrupt layout at boot time device 
enumeration), but am wondering if anyone familiar with this area of the 
code has any comments / advice w/r/t the capabilities of the DF bios 
drivers
and the various quirks / fixup mentioned in the link above..

looking to possibly investigate fixing up some of these issues over time.
Our code that handles issues like this (in cases where you're not using 
APICs, just PICs and PIRs) lives in bus/pci/i386/. Not that running 
without APIC support is all that common on modern machines anymore...
--
        Thomas E. Spanjaard
        tgen at netphreax.net
Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00003.pgp
Type: application/octet-stream
Size: 186 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080307/61366b5c/attachment-0006.obj>

From tgen at netphreax.net  Fri Mar  7 05:16:51 2008
From: tgen at netphreax.net (Thomas E. Spanjaard)
Date: Fri, 7 Mar 2008 05:16:51 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Misc. ACPI / suspend
In-Reply-To: <47CA073B.6020106@199technologies.org>
Message-ID: <47D13F07.9080308@netphreax.net>

Chris Turner wrote:
1) does anyone have ACPI (instead of APM)
   sleep / suspend / wakeup working on Dfly ?
2) If so, what machines are being used ?
3) Same question for other BSDs - my understanding is NetBSD is most
   'advanced' w/r/t power managment - but I'm not 100% on this ...
would looove to have a sleeping / resuming / scaling laptop running some 
BSD flavor.. am willing to work towards that end, esp. w/r/t Dfly -
trying to chart a course to figguring this out.
I have ACPI S3 suspend working like a charm on my IBM ThinkPad R40 
(Pentium M "Banias" 1.3GHz, speedstepping works just fine), running 
NetBSD 3.99.21.
--
        Thomas E. Spanjaard
        tgen at netphreax.net
Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00004.pgp
Type: application/octet-stream
Size: 186 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080307/de3e5104/attachment-0006.obj>

From civilizd at gmail.com  Fri Mar  7 09:06:41 2008
From: civilizd at gmail.com (Vita "CiV" Cizek)
Date: Fri, 7 Mar 2008 09:06:41 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <98d564710803070853q1c73d795m6e6c5cc5049fa099@mail.gmail.com>

>  Any student volunteers?  We have mentors.
>
I am interested too, especially in some kernel-related work.




From justin at shiningsilence.com  Sat Mar  8 12:07:51 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Sat, 8 Mar 2008 12:07:51 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google SoC 2008 - mentors mentors mentors
Message-ID: <51558.192.168.0.252.1205006403.squirrel@www.shiningsilence.com>

If you are willing to mentor for the Google 2008 Summer of Code, please
speak up.  Right now we have: (from our wiki page)

Matthias
Sephe
TGEN
corecode

Part of the application process includes naming people as mentors (student
applications come later), so I want to get as complete a list as possible.

The application is due on the 12th, so if you want to mentor, now's the
time to say so.

Google's SoC FAQ is here: http://code.google.com/soc/2008/faqs.html

Our wiki page is here: http://wiki.dragonflybsd.org/index.cgi/GoogleSoC2008

- much credit to Matthias and others for getting that set up.





From saw at online.de  Sat Mar  8 14:26:07 2008
From: saw at online.de (Sascha Wildner)
Date: Sat, 08 Mar 2008 23:26:07 +0100
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <47d31245$0$848$415eb37d@crater_reader.dragonflybsd.org>

Sascha Wildner wrote:
Hi all,

this is probably as good a moment as any to come out of the forest with 
this. The patch at

http://leaf.dragonflybsd.org/~swildner/nrelease_gui.diff
Ok, I have committed the stuff as an example.

I'm not sure if my free time permits to work on a full-blown live CD 
with X11 and other good things (I already feel my interest wandering off 
in other directions) so if anyone wants to pick up the ball, go ahead. :)

Sascha

--
http://yoyodyne.ath.cx



From qhwt+dfly at les.ath.cx  Tue Mar 11 22:21:31 2008
From: qhwt+dfly at les.ath.cx (YONETANI Tomokazu)
Date: Tue, 11 Mar 2008 22:21:31 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Misc. ACPI / suspend
In-Reply-To: <47CA073B.6020106@199technologies.org>
Message-ID: <20080312051219.GA56091@les.ath.cx>

On Thu, Mar 06, 2008 at 10:03:21PM -0500, Chris Turner wrote:
> 1) does anyone have ACPI (instead of APM)
>    sleep / suspend / wakeup working on Dfly ?
> 2) If so, what machines are being used ?

Dynabook SS3500 (http://www.tlt.co.jp/pc/catalog/ss/02110735/index_j.htm).
It's old and can get very hot(thus frequently turns on the cooling fan)
even when it's running Windows.  I haven't turned it on for about several
months though.

Cheers.




From c.turner at 199technologies.org  Wed Mar 12 04:37:22 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Wed, 12 Mar 2008 04:37:22 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Misc. ACPI / suspend
In-Reply-To: <47CA073B.6020106@199technologies.org>
Message-ID: <47D7BEE3.6010907@199technologies.org>

YONETANI Tomokazu wrote:
On Thu, Mar 06, 2008 at 10:03:21PM -0500, Chris Turner wrote:
1) does anyone have ACPI (instead of APM)
   sleep / suspend / wakeup working on Dfly ?
Cheers.
ditto..

Suppose this should go to docs@ - in any case..

Thinking about setting up a wiki page on the issue so we
can discuss / track what 'good' hardware / drivers / implementations / 
etc are 'out there' - anyone have any suggestions on where this should
go?

http://wiki.dragonflybsd.org/index.cgi/acpi-overview.html

Remains from the handbook conversion - but I'm hesitant to 'over wikify'
this ..



From c.turner at 199technologies.org  Wed Mar 12 15:36:52 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Wed, 12 Mar 2008 15:36:52 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: devel/cscope
Message-ID: <47D85A08.8040103@199technologies.org>

why oh why did I take so long to try this out !!!

just sharing my eureka moment with the list..

- Chris




From dudu at dudu.ro  Wed Mar 12 15:50:14 2008
From: dudu at dudu.ro (Vlad GALU)
Date: Wed, 12 Mar 2008 15:50:14 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: devel/cscope
In-Reply-To: <47D85A08.8040103@199technologies.org>
Message-ID: <ad79ad6b0803121547r2bf67ffep9e40badaac6490f8@mail.gmail.com>

On 3/13/08, Chris Turner <c.turner at 199technologies.org> wrote:
> why oh why did I take so long to try this out !!!
>
>  just sharing my eureka moment with the list..


    Works nice with vim, too!

>
>
>  - Chris
>


-- 
Mahnahmahnah!




From justin at shiningsilence.com  Sun Mar 16 21:06:13 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Sun, 16 Mar 2008 21:06:13 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: binary packages for 1.12 coming in
Message-ID: <1372.192.168.0.252.1205726088.squirrel@www.shiningsilence.com>

The binary build for 1.12 is taking quite a while.  I've started copying
in newly built packages to
pkgbox.dragonflybsd.org/packages/DragonFly-1.12/i386/ - this should be
getting copied out to mirrors over the next while.

There are currently 1283 packages built, which leaves a whole lot to go;
I'll copy new packages in as they complete.





From hasso at estpak.ee  Wed Mar 19 04:31:08 2008
From: hasso at estpak.ee (Hasso Tepper)
Date: Wed, 19 Mar 2008 04:31:08 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Some questions regarding ACPI
Message-ID: <200803191322.46366.hasso@estpak.ee>

I'm working on bringing in some laptop (and especially thinkpad) specific 
ACPI code from FreeBSD into DragonFly. I never touched ACPI stuff before 
and haven't followed it much either, so I have some questions.

* FreeBSD uses ACPI_SERIAL_* heavily. What's the locking situation in 
  DragonFly and why?

* As far as I can see, PCI integration is commented out in DragonFly. 
  What's the state of it and why?

* platform/pc32/acpica5/acpi_toshiba.c - why is it there? I don't think 
  that this is something pc32 specific in it and it should work in pc64 
  laptops as well. Any objections to move it into 
  dev/acpica5/acpi_toshiba/ ?

What's the current status of ACPI in general? AFAICS our acpica is quite 
old - what needs to be done to bring in newer one?


-- 
Hasso




From qhwt+dfly at les.ath.cx  Wed Mar 19 09:24:50 2008
From: qhwt+dfly at les.ath.cx (YONETANI Tomokazu)
Date: Wed, 19 Mar 2008 09:24:50 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Some questions regarding ACPI
In-Reply-To: <200803191322.46366.hasso@estpak.ee>
Message-ID: <20080319161703.GA51509@les.ath.cx>

On Wed, Mar 19, 2008 at 01:22:46PM +0200, Hasso Tepper wrote:
> I'm working on bringing in some laptop (and especially thinkpad) specific 
> ACPI code from FreeBSD into DragonFly. I never touched ACPI stuff before 
> and haven't followed it much either, so I have some questions.

So you want to port some of ACPI support drivers, or to do a fresh port
of ACPI driver from FreeBSD?

> * FreeBSD uses ACPI_SERIAL_* heavily. What's the locking situation in 
>   DragonFly and why?

The current ACPI driver in DragonFly is based on that of FreeBSD as of
end of June, 2004, plus some fixes brought in later (and ACPICA part
has been updated twice since then).  That was before they introduced
the MPSAFE changes into ACPI code, and we use critical section
(crit_{enter,exit}) in most places (and lockmgr lock in a few place).

> * As far as I can see, PCI integration is commented out in DragonFly. 
>   What's the state of it and why?

When we replaced the implementation taken from FreeBSD 4.x with that
brought from FreeBSD 5.x, which added the PCI part, many people
experienced problems until they turned off ACPI completely, or add "pci"
to "debug.acpi.disabled" loader variable.  AFAIK the PCI part in the ACPI
driver almost hasn't been adjusted to work with our version of PCI code.

> * platform/pc32/acpica5/acpi_toshiba.c - why is it there? I don't think 
>   that this is something pc32 specific in it and it should work in pc64 
>   laptops as well. Any objections to move it into 
>   dev/acpica5/acpi_toshiba/ ?

In FreeBSD it used to be sitting at i386/acpica/acpi_toshiba.c and was
later moved into acpi_support.  That change hasn't hit our tree (in fact,
we have no acpi support drivers other than that).  It seems that FreeBSD
has them in dev/acpi_support now, and we for some reason have that
directory in our CVS repository (but containing no files in it).

> What's the current status of ACPI in general? AFAICS our acpica is quite 
> old - what needs to be done to bring in newer one?

Actually, it's not very important to keep just ACPICA latest, but
if you bring the ACPI driver from FreeBSD you need to bring ACPICA code
that matches their version, and it IS important.  And it generally requires
you much work to just update ACPICA part anyway because of how they
change things on every release.

Cheers.




From hasso at estpak.ee  Wed Mar 19 12:29:52 2008
From: hasso at estpak.ee (Hasso Tepper)
Date: Wed, 19 Mar 2008 12:29:52 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Some questions regarding ACPI
In-Reply-To: <200803191322.46366.hasso@estpak.ee>
Message-ID: <200803192115.35396.hasso@estpak.ee>

YONETANI Tomokazu wrote:
> On Wed, Mar 19, 2008 at 01:22:46PM +0200, Hasso Tepper wrote:
> > I'm working on bringing in some laptop (and especially thinkpad)
> > specific ACPI code from FreeBSD into DragonFly. I never touched ACPI
> > stuff before and haven't followed it much either, so I have some
> > questions.
>
> So you want to port some of ACPI support drivers, or to do a fresh port
> of ACPI driver from FreeBSD?

I'm only interested in support drivers and the reason is pure practical - 
newer thinkpads handle less and less hotkeys etc in hardware and require 
support form OS. acpi_ibm and acpi_video are examples of such modules 
which would help a lot of these newer thinkpad users.

acpi_ibm is almost ready to commit (renamed to acpi_thinkpad though).

> > * FreeBSD uses ACPI_SERIAL_* heavily. What's the locking situation in
> >   DragonFly and why?
>
> The current ACPI driver in DragonFly is based on that of FreeBSD as of
> end of June, 2004, plus some fixes brought in later (and ACPICA part
> has been updated twice since then).  That was before they introduced
> the MPSAFE changes into ACPI code, and we use critical section
> (crit_{enter,exit}) in most places (and lockmgr lock in a few place).

Mkay. Will look at more closely.

> > * As far as I can see, PCI integration is commented out in DragonFly.
> >   What's the state of it and why?
>
> When we replaced the implementation taken from FreeBSD 4.x with that
> brought from FreeBSD 5.x, which added the PCI part, many people
> experienced problems until they turned off ACPI completely, or add
> "pci" to "debug.acpi.disabled" loader variable.  AFAIK the PCI part in
> the ACPI driver almost hasn't been adjusted to work with our version of
> PCI code.

I'm afraid that it's beyond my skills, but while looking at acpi_video I 
discovered that it's hard to handle correctly without PCI support.

> > * platform/pc32/acpica5/acpi_toshiba.c - why is it there? I don't
> > think that this is something pc32 specific in it and it should work
> > in pc64 laptops as well. Any objections to move it into
> >   dev/acpica5/acpi_toshiba/ ?
>
> In FreeBSD it used to be sitting at i386/acpica/acpi_toshiba.c and was
> later moved into acpi_support.  That change hasn't hit our tree (in
> fact, we have no acpi support drivers other than that).  It seems that
> FreeBSD has them in dev/acpi_support now, and we for some reason have
> that directory in our CVS repository (but containing no files in it).

I don't see it ;). Makes sense though. So, any objections if I move 
acpi_toshiba into sys/dev/acpi_support and add new acpi_thinkpad there as 
well? 

> > What's the current status of ACPI in general? AFAICS our acpica is
> > quite old - what needs to be done to bring in newer one?
>
> Actually, it's not very important to keep just ACPICA latest, but
> if you bring the ACPI driver from FreeBSD you need to bring ACPICA code
> that matches their version, and it IS important.  And it generally
> requires you much work to just update ACPICA part anyway because of how
> they change things on every release.

Someone else has to do it :).

Thanks for info.


-- 
Hasso




From dillon at apollo.backplane.com  Wed Mar 19 14:01:13 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Wed, 19 Mar 2008 14:01:13 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: panic: assertion: hammer_btree_cmp(cursor->left_bound,	&cursor->node->ondisk->elms[0].leaf.base) <= 0 in btree_split_leaf
In-Reply-To: <200802232204.m1NM4cxd046264@apollo.backplane.com>
Message-ID: <200803192054.m2JKsjwn045137@apollo.backplane.com>


:Hi.
:While trying to find a procedure to reliably reproduce the panic
:I reported last time, I caught a different panic (uploaded at
: ~y0netan1/crash/9/ on my leaf account).  I wrote the following shell
:script (make sure to edit variables DISKS and MOUNTPT before using this
:script or it may trash your system):
:  #!/bin/sh -ex
:  DISKS="/dev/ad0s1f"
:  MOUNTPT=/mnt/HAMMER
:
:  cd /
:  newfs_hammer -L TEST $DISKS
:  for i in `seq 1 100`; do
:..
:And the panic is triggered by rm command.
:I'll try to see if it's possible to reproduce the last one without
:unmounting then mounting the HAMMER fs.
:
:Cheers.

    I believe I have fixed this panic.  hammer_make_separator() had a bug
    in it.

    There is still an issue with the node ref count on umount.

    Please continue to life-test the code.  The reblocking code
    (hammer reblock /mnt) should work now, as should the pruning code
    (e.g. hammer prune /mnt everything).

    The filesystem full case is still not handled and will cause bad things
    to happen.  The undo code isn't finished yet either but it is getting
    there (it's writing stuff out but not setting the sequence number and
    not trying to recover-on-mount yet).

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From qhwt+dfly at les.ath.cx  Wed Mar 19 19:45:40 2008
From: qhwt+dfly at les.ath.cx (YONETANI Tomokazu)
Date: Wed, 19 Mar 2008 19:45:40 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Some questions regarding ACPI
In-Reply-To: <200803191322.46366.hasso@estpak.ee>
Message-ID: <20080320023828.GA53648@les.ath.cx>

On Wed, Mar 19, 2008 at 09:15:35PM +0200, Hasso Tepper wrote:
> YONETANI Tomokazu wrote:
> > On Wed, Mar 19, 2008 at 01:22:46PM +0200, Hasso Tepper wrote:
> > > I'm working on bringing in some laptop (and especially thinkpad)
> > > specific ACPI code from FreeBSD into DragonFly. I never touched ACPI
> > > stuff before and haven't followed it much either, so I have some
> > > questions.
> >
> > So you want to port some of ACPI support drivers, or to do a fresh port
> > of ACPI driver from FreeBSD?
> 
> I'm only interested in support drivers and the reason is pure practical - 
> newer thinkpads handle less and less hotkeys etc in hardware and require 
> support form OS. acpi_ibm and acpi_video are examples of such modules 
> which would help a lot of these newer thinkpad users.
> 
> acpi_ibm is almost ready to commit (renamed to acpi_thinkpad though).

Ah, that's a good news!  My only concern is that ISTR someone mentioned
me that his colleague was thinking about porting ACPI driver itself,
so if you're not the person you may want to collaborate with him/her
so as not to waste the effort or time...

			:

> > In FreeBSD it used to be sitting at i386/acpica/acpi_toshiba.c and was
> > later moved into acpi_support.  That change hasn't hit our tree (in
> > fact, we have no acpi support drivers other than that).  It seems that
> > FreeBSD has them in dev/acpi_support now, and we for some reason have
> > that directory in our CVS repository (but containing no files in it).
> 
> I don't see it ;). Makes sense though. So, any objections if I move 
> acpi_toshiba into sys/dev/acpi_support and add new acpi_thinkpad there as 
> well? 

Sorry, I checked the CVS repository and it doesn't exist actually :)
I don't have any objection to moving it there.

Cheers.




From hasso at estpak.ee  Thu Mar 20 00:14:05 2008
From: hasso at estpak.ee (Hasso Tepper)
Date: Thu, 20 Mar 2008 00:14:05 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Some questions regarding ACPI
In-Reply-To: <200803191322.46366.hasso@estpak.ee>
Message-ID: <200803200904.50875.hasso@estpak.ee>

YONETANI Tomokazu wrote:
> On Wed, Mar 19, 2008 at 09:15:35PM +0200, Hasso Tepper wrote:
> > acpi_ibm is almost ready to commit (renamed to acpi_thinkpad though).
>
> Ah, that's a good news!  My only concern is that ISTR someone mentioned
> me that his colleague was thinking about porting ACPI driver itself,
> so if you're not the person you may want to collaborate with him/her
> so as not to waste the effort or time...

Current state in my repo is attached. It should work on 1.12 as well as it 
doesn't depend yet on moving stuff around.

add-acpi-if-m.patch adds some new stuff to the ACPI code to access 
embedded controllers and match ACPI devices by ID. Not sure how, where 
and whether at all these should be documented.

add-acpi-thinkpad.patch is the driver itself. Note that some stuff doesn't 
work yet on newer thinkpads, I plan to work on it later.

There is still some things to do though. I have to decide what to do with 
led(4) part and with locking. There is also one fatal issue - laptop 
locks up hardly (no panic) while unloading module. Any idea regarding 
this is welcome. And of course test results :).


-- 
Hasso
# HG changeset patch
# User Hasso Tepper <hasso at estpak.ee>
# Date 1205919290 -7200
# Branch HEAD
# Node ID 5a6e2705cc95a340abf973ae5df73ef34e070b79
# Parent  cd529e2e7f849034d5d5a0973cb98af50db0e797
imported patch adding-acpi-if-m.patch

diff --git a/sys/conf/files b/sys/conf/files
--- a/sys/conf/files
+++ b/sys/conf/files
@@ -1387,6 +1387,7 @@ emulation/dragonfly12/dfbsd12_stat.c	non
 ${OSACPI_MI_DIR}/acpi_cmbat.c		optional acpi
 ${OSACPI_MI_DIR}/acpi_cpu.c		optional acpi
 ${OSACPI_MI_DIR}/acpi_ec.c		optional acpi
+${OSACPI_MI_DIR}/acpi_if.m		optional acpi
 ${OSACPI_MI_DIR}/acpi_isab.c		optional acpi isa
 ${OSACPI_MI_DIR}/acpi_lid.c		optional acpi
 ${OSACPI_MI_DIR}/acpi_package.c		optional acpi
diff --git a/sys/conf/kmod.mk b/sys/conf/kmod.mk
--- a/sys/conf/kmod.mk
+++ b/sys/conf/kmod.mk
@@ -275,7 +275,7 @@ MFILES?= kern/bus_if.m kern/device_if.m 
     bus/pccard/card_if.m bus/pccard/power_if.m bus/pci/pci_if.m \
     bus/pci/pcib_if.m \
     bus/ppbus/ppbus_if.m bus/smbus/smbus_if.m bus/usb/usb_if.m \
-    dev/disk/nata/ata_if.m \
+    dev/acpica5/acpi_if.m dev/disk/nata/ata_if.m \
     dev/sound/pcm/ac97_if.m dev/sound/pcm/channel_if.m \
     dev/sound/pcm/feeder_if.m dev/sound/pcm/mixer_if.m \
     libiconv/iconv_converter_if.m dev/agp/agp_if.m opencrypto/crypto_if.m
diff --git a/sys/dev/acpica5/Makefile b/sys/dev/acpica5/Makefile
--- a/sys/dev/acpica5/Makefile
+++ b/sys/dev/acpica5/Makefile
@@ -69,12 +69,14 @@ SRCS+=  acpi_package.c
 # SRCS+=	acpi_pci.c acpi_pcib.c acpi_pcib_acpi.c acpi_pcib_pci.c
 # SRCS+=	acpi_pci_link.c
 SRCS+=  acpi_powerres.c acpi_resource.c acpi_thermal.c
-SRCS+=  acpi_timer.c
+SRCS+=  acpi_timer.c acpi_if.c
 SRCS+=  OsdDebug.c
 SRCS+=  OsdHardware.c OsdInterface.c OsdInterrupt.c OsdMemory.c OsdSchedule.c
 SRCS+=  OsdStream.c OsdSynch.c OsdTable.c OsdEnvironment.c
 SRCS+=  opt_acpi.h opt_bus.h opt_ddb.h
-SRCS+=  device_if.h bus_if.h pci_if.h pcib_if.h isa_if.h
+SRCS+=  device_if.h bus_if.h pci_if.h pcib_if.h isa_if.h acpi_if.h
+MFILES = kern/device_if.m kern/bus_if.m bus/pci/pci_if.m bus/pci/pcib_if.m
+MFILES+= bus/isa/isa_if.m dev/acpica5/acpi_if.m
 
 # Debugging support
 DBSRC=	dbcmds.c dbdisply.c dbexec.c dbfileio.c dbhistry.c
diff --git a/sys/dev/acpica5/acpi.c b/sys/dev/acpica5/acpi.c
--- a/sys/dev/acpica5/acpi.c
+++ b/sys/dev/acpica5/acpi.c
@@ -135,6 +135,7 @@ static int	acpi_release_resource(device_
 			int rid, struct resource *r);
 static uint32_t	acpi_isa_get_logicalid(device_t dev);
 static int	acpi_isa_get_compatid(device_t dev, uint32_t *cids, int count);
+static char	*acpi_device_id_probe(device_t bus, device_t dev, char **ids);
 static int	acpi_isa_pnp_probe(device_t bus, device_t child,
 			struct isa_pnp_id *ids);
 static void	acpi_probe_children(device_t bus);
@@ -189,6 +190,9 @@ static device_method_t acpi_methods[] = 
     DEVMETHOD(bus_deactivate_resource,	bus_generic_deactivate_resource),
     DEVMETHOD(bus_setup_intr,		bus_generic_setup_intr),
     DEVMETHOD(bus_teardown_intr,	bus_generic_teardown_intr),
+
+    /* ACPI bus */
+    DEVMETHOD(acpi_id_probe,		acpi_device_id_probe),
 
     /* ISA emulation */
     DEVMETHOD(isa_pnp_probe,		acpi_isa_pnp_probe),
@@ -1121,6 +1125,24 @@ out:
 	AcpiOsFree(buf.Pointer);
     ACPI_UNLOCK;
     return_VALUE (valid);
+}
+
+static char *
+acpi_device_id_probe(device_t bus, device_t dev, char **ids) 
+{
+    ACPI_HANDLE h;
+    int i;
+
+    h = acpi_get_handle(dev);
+    if (ids == NULL || h == NULL || acpi_get_type(dev) != ACPI_TYPE_DEVICE)
+	return (NULL);
+
+    /* Try to match one of the array of IDs with a HID or CID. */
+    for (i = 0; ids[i] != NULL; i++) {
+	if (acpi_MatchHid(h, ids[i]))
+	    return (ids[i]);
+    }
+    return (NULL);
 }
 
 static int
diff --git a/sys/dev/acpica5/acpi_ec.c b/sys/dev/acpica5/acpi_ec.c
--- a/sys/dev/acpica5/acpi_ec.c
+++ b/sys/dev/acpica5/acpi_ec.c
@@ -327,11 +327,19 @@ static ACPI_STATUS	EcWrite(struct acpi_e
 				UINT8 *Data);
 static int		acpi_ec_probe(device_t dev);
 static int		acpi_ec_attach(device_t dev);
+static int		acpi_ec_read_method(device_t dev, u_int addr,
+				ACPI_INTEGER *val, int width);
+static int		acpi_ec_write_method(device_t dev, u_int addr,
+				ACPI_INTEGER val, int width);
 
 static device_method_t acpi_ec_methods[] = {
     /* Device interface */
     DEVMETHOD(device_probe,	acpi_ec_probe),
     DEVMETHOD(device_attach,	acpi_ec_attach),
+
+    /* Embedded controller interface */
+    DEVMETHOD(acpi_ec_read,     acpi_ec_read_method),
+    DEVMETHOD(acpi_ec_write,    acpi_ec_write_method),
 
     {0, 0}
 };
@@ -620,6 +628,33 @@ error:
 			     sc->ec_data_res);
     /* mtx_destroy(&sc->ec_mtx); */
     return (ENXIO);
+}
+
+/* Methods to allow other devices (e.g., smbat) to read/write EC space. */
+static int
+acpi_ec_read_method(device_t dev, u_int addr, ACPI_INTEGER *val, int width)
+{
+    struct acpi_ec_softc *sc;
+    ACPI_STATUS status;
+
+    sc = device_get_softc(dev);
+    status = EcSpaceHandler(ACPI_READ, addr, width * 8, val, sc, NULL);
+    if (ACPI_FAILURE(status))
+        return (ENXIO);
+    return (0);
+}
+
+static int
+acpi_ec_write_method(device_t dev, u_int addr, ACPI_INTEGER val, int width)
+{
+    struct acpi_ec_softc *sc;
+    ACPI_STATUS status;
+
+    sc = device_get_softc(dev);
+    status = EcSpaceHandler(ACPI_WRITE, addr, width * 8, &val, sc, NULL);
+    if (ACPI_FAILURE(status))
+        return (ENXIO);
+    return (0);
 }
 
 static void
diff --git a/sys/dev/acpica5/acpi_if.m b/sys/dev/acpica5/acpi_if.m
new file mode 100644
--- /dev/null
+++ b/sys/dev/acpica5/acpi_if.m
@@ -0,0 +1,92 @@
+#-
+# Copyright (c) 2004 Nate Lawson
+# All rights reserved.
+#
+# Redistribution and use in source and binary forms, with or without
+# modification, are permitted provided that the following conditions
+# are met:
+# 1. Redistributions of source code must retain the above copyright
+#    notice, this list of conditions and the following disclaimer.
+# 2. Redistributions in binary form must reproduce the above copyright
+#    notice, this list of conditions and the following disclaimer in the
+#    documentation and/or other materials provided with the distribution.
+#
+# THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
+# ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+# ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
+# FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+# DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+# OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+# HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+# LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+# OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+# SUCH DAMAGE.
+#
+# $DragonFly$
+#
+
+#include <sys/bus.h>
+#include <sys/types.h>
+#include "acpi.h"
+
+INTERFACE acpi;
+
+#
+# Default implementation for acpi_id_probe().
+#
+CODE {
+	static char *
+	acpi_generic_id_probe(device_t bus, device_t dev, char **ids)
+	{
+		return (NULL);
+	}
+};
+
+#
+# Check a device for a match in a list of ID strings.  The strings can be
+# EISA PNP IDs or ACPI _HID/_CID values.
+#
+# device_t bus:  parent bus for the device
+#
+# device_t dev:  device being considered
+#
+# char **ids:  array of ID strings to consider
+#
+# Returns:  ID string matched or NULL if no match
+#
+METHOD char * id_probe {
+	device_t	bus;
+	device_t	dev;
+	char		**ids;
+} DEFAULT acpi_generic_id_probe;
+
+#
+# Read embedded controller (EC) address space
+#
+# device_t dev:  EC device
+# u_int addr:  Address to read from in EC space
+# ACPI_INTEGER *val:  Location to store read value
+# int width:  Size of area to read in bytes
+#
+METHOD int ec_read {
+	device_t	dev;
+	u_int		addr;
+	ACPI_INTEGER	*val;
+	int		width;
+};
+
+#
+# Write embedded controller (EC) address space
+#
+# device_t dev:  EC device
+# u_int addr:  Address to write to in EC space
+# ACPI_INTEGER val:  Value to write
+# int width:  Size of value to write in bytes
+#
+METHOD int ec_write {
+	device_t	dev;
+	u_int		addr;
+	ACPI_INTEGER	val;
+	int		width;
+};
diff --git a/sys/dev/acpica5/acpivar.h b/sys/dev/acpica5/acpivar.h
--- a/sys/dev/acpica5/acpivar.h
+++ b/sys/dev/acpica5/acpivar.h
@@ -29,6 +29,7 @@
  * $DragonFly: src/sys/dev/acpica5/acpivar.h,v 1.12 2007/10/23 03:04:48 y0netan1 Exp $
  */
 
+#include "acpi_if.h"
 #include "bus_if.h"
 #include <sys/eventhandler.h>
 #include <sys/sysctl.h>
# HG changeset patch
# User Hasso Tepper <hasso at estpak.ee>
# Date 1205995474 -7200
# Branch HEAD
# Node ID c5db8d4a7c6b25a8576a8d42c5029aaf0e23bfb6
# Parent  5a6e2705cc95a340abf973ae5df73ef34e070b79
[mq]: adding-acpi-thinkpad.patch

diff --git a/sys/dev/acpica5/Makefile b/sys/dev/acpica5/Makefile
--- a/sys/dev/acpica5/Makefile
+++ b/sys/dev/acpica5/Makefile
@@ -117,7 +117,7 @@ acpi_wakecode.h: acpi_wakecode.S
 	${MAKE} -f ${SYSDIR}/${OSACPI_MD_DIR}/Makefile \
 		MAKESRCPATH=${SYSDIR}/${OSACPI_MD_DIR}
 
-SUBDIR=	acpi_toshiba
+SUBDIR=	acpi_toshiba acpi_thinkpad
 all: ${PROG} ${SUBDIR}
 
 # *.o file for each patched *.c file is created under the same directory,
diff --git a/sys/dev/acpica5/acpi_thinkpad/Makefile b/sys/dev/acpica5/acpi_thinkpad/Makefile
new file mode 100644
--- /dev/null
+++ b/sys/dev/acpica5/acpi_thinkpad/Makefile
@@ -0,0 +1,9 @@
+# $DragonFly$
+
+SYSDIR?=${.CURDIR}/../../..
+
+KMOD=		acpi_thinkpad
+CFLAGS+=	-I${.OBJDIR}/.. -I${.CURDIR}/..
+SRCS=		acpi_thinkpad.c opt_acpi.h device_if.h bus_if.h
+
+.include <bsd.kmod.mk>
diff --git a/sys/dev/acpica5/acpi_thinkpad/acpi_thinkpad.c b/sys/dev/acpica5/acpi_thinkpad/acpi_thinkpad.c
new file mode 100644
--- /dev/null
+++ b/sys/dev/acpica5/acpi_thinkpad/acpi_thinkpad.c
@@ -0,0 +1,1046 @@
+/*
+ * Copyright (c) 2004 Takanori Watanabe
+ * Copyright (c) 2005 Markus Brueffer <markus at FreeBSD.org>
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *    notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *    notice, this list of conditions and the following disclaimer in the
+ *    documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+ */
+
+/*
+ * Driver for extra ACPI-controlled gadgets found on IBM and Lenovo ThinkPad
+ * laptops. Inspired by the ibm-acpi and tpb projects which implement these
+ * features on Linux.
+ *
+ *   acpi-ibm: <http://ibm-acpi.sourceforge.net/>
+ *        tpb: <http://www.nongnu.org/tpb/>
+ */
+
+#include "opt_acpi.h"
+#include <sys/param.h>
+#include <sys/kernel.h>
+#include <sys/bus.h>
+#include <machine/cpufunc.h>
+#include <sys/module.h>
+/* #include <dev/led/led.h> */
+#include <sys/sensors.h>
+#include <sys/sysctl.h>
+#include <machine/clock.h>
+
+#include "acpi.h"
+#include "acpivar.h"
+#include "acpi_if.h"
+
+#define _COMPONENT	ACPI_OEM
+ACPI_MODULE_NAME("THINKPAD")
+
+/* Internal methods */
+#define ACPI_THINKPAD_METHOD_EVENTS		1
+#define ACPI_THINKPAD_METHOD_EVENTMASK		2
+#define ACPI_THINKPAD_METHOD_HOTKEY		3
+#define ACPI_THINKPAD_METHOD_BRIGHTNESS		4
+#define ACPI_THINKPAD_METHOD_VOLUME		5
+#define ACPI_THINKPAD_METHOD_MUTE		6
+#define ACPI_THINKPAD_METHOD_THINKLIGHT		7
+#define ACPI_THINKPAD_METHOD_BLUETOOTH		8
+#define ACPI_THINKPAD_METHOD_WLAN		9
+#define ACPI_THINKPAD_METHOD_FANSPEED		10
+#define ACPI_THINKPAD_METHOD_FANLEVEL		11
+#define ACPI_THINKPAD_METHOD_FANSTATUS		12
+#define ACPI_THINKPAD_METHOD_THERMAL		13
+
+/* Hotkeys/Buttons */
+#define THINKPAD_RTC_HOTKEY1			0x64
+#define   THINKPAD_RTC_MASK_HOME		(1 << 0)
+#define   THINKPAD_RTC_MASK_SEARCH		(1 << 1)
+#define   THINKPAD_RTC_MASK_MAIL		(1 << 2)
+#define   THINKPAD_RTC_MASK_WLAN		(1 << 5)
+#define THINKPAD_RTC_HOTKEY2			0x65
+#define   THINKPAD_RTC_MASK_THINKPAD		(1 << 3)
+#define   THINKPAD_RTC_MASK_ZOOM		(1 << 5)
+#define   THINKPAD_RTC_MASK_VIDEO		(1 << 6)
+#define   THINKPAD_RTC_MASK_HIBERNATE		(1 << 7)
+#define THINKPAD_RTC_THINKLIGHT			0x66
+#define   THINKPAD_RTC_MASK_THINKLIGHT		(1 << 4)
+#define THINKPAD_RTC_SCREENEXPAND		0x67
+#define   THINKPAD_RTC_MASK_SCREENEXPAND	(1 << 5)
+#define THINKPAD_RTC_BRIGHTNESS			0x6c
+#define   THINKPAD_RTC_MASK_BRIGHTNESS		(1 << 5)
+#define THINKPAD_RTC_VOLUME			0x6e
+#define   THINKPAD_RTC_MASK_VOLUME		(1 << 7)
+
+/* Embedded Controller registers */
+#define THINKPAD_EC_BRIGHTNESS			0x31
+#define   THINKPAD_EC_MASK_BRI			0x7
+#define THINKPAD_EC_VOLUME			0x30
+#define   THINKPAD_EC_MASK_VOL			0xf
+#define   THINKPAD_EC_MASK_MUTE			(1 << 6)
+#define THINKPAD_EC_FANSTATUS			0x2F
+#define   THINKPAD_EC_MASK_FANLEVEL		0x3f
+#define   THINKPAD_EC_MASK_FANDISENGAGED	(1 << 6)
+#define   THINKPAD_EC_MASK_FANSTATUS		(1 << 7)
+#define THINKPAD_EC_FANSPEED			0x84
+
+/* CMOS Commands */
+#define THINKPAD_CMOS_VOLUME_DOWN		0
+#define THINKPAD_CMOS_VOLUME_UP			1
+#define THINKPAD_CMOS_VOLUME_MUTE		2
+#define THINKPAD_CMOS_BRIGHTNESS_UP		4
+#define THINKPAD_CMOS_BRIGHTNESS_DOWN		5
+
+/* ACPI methods */
+#define THINKPAD_NAME_KEYLIGHT			"KBLT"
+#define THINKPAD_NAME_WLAN_BT_GET		"GBDC"
+#define THINKPAD_NAME_WLAN_BT_SET		"SBDC"
+#define   THINKPAD_NAME_MASK_BT			(1 << 1)
+#define   THINKPAD_NAME_MASK_WLAN		(1 << 2)
+#define THINKPAD_NAME_THERMAL_GET		"TMP7"
+#define THINKPAD_NAME_THERMAL_UPDT		"UPDT"
+
+#define THINKPAD_NAME_EVENTS_STATUS_GET		"DHKC"
+#define THINKPAD_NAME_EVENTS_MASK_GET		"DHKN"
+#define THINKPAD_NAME_EVENTS_STATUS_SET		"MHKC"
+#define THINKPAD_NAME_EVENTS_MASK_SET		"MHKM"
+#define THINKPAD_NAME_EVENTS_GET		"MHKP"
+#define THINKPAD_NAME_EVENTS_AVAILMASK		"MHKA"
+
+#define ABS(x) (((x) < 0)? -(x) : (x))
+
+struct acpi_thinkpad_softc {
+	device_t	dev;
+	ACPI_HANDLE	handle;
+
+	/* Embedded controller */
+	device_t	ec_dev;
+	ACPI_HANDLE	ec_handle;
+
+	/* CMOS */
+	ACPI_HANDLE	cmos_handle;
+
+	/* Fan status */
+	ACPI_HANDLE	fan_handle;
+	int		fan_levels;
+
+	/* Keylight commands and states */
+	ACPI_HANDLE	light_handle;
+	int		light_cmd_on;
+	int		light_cmd_off;
+	int		light_val;
+	int		light_get_supported;
+	int		light_set_supported;
+
+	/* led(4) interface */
+	struct cdev	*led_dev;
+	int		led_busy;
+	int		led_state;
+
+	int		wlan_bt_flags;
+	int		thermal_updt_supported;
+
+	unsigned int	events_availmask;
+	unsigned int	events_initialmask;
+	int		events_mask_supported;
+	int		events_enable;
+
+	/* sensors(9) related */
+	struct ksensordev sensordev;
+	struct ksensor sensors[9];	/* XXX: 8 thermal + fan */
+
+	struct sysctl_ctx_list	*sysctl_ctx;
+	struct sysctl_oid	*sysctl_tree;
+};
+
+static struct {
+	char	*name;
+	int	method;
+	char	*description;
+	int	access;
+} acpi_thinkpad_sysctls[] = {
+	{
+		.name		= "events",
+		.method		= ACPI_THINKPAD_METHOD_EVENTS,
+		.description	= "ACPI events enable",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "eventmask",
+		.method		= ACPI_THINKPAD_METHOD_EVENTMASK,
+		.description	= "ACPI eventmask",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "hotkey",
+		.method		= ACPI_THINKPAD_METHOD_HOTKEY,
+		.description	= "Key Status",
+		.access		= CTLTYPE_INT | CTLFLAG_RD
+	},
+	{
+		.name		= "lcd_brightness",
+		.method		= ACPI_THINKPAD_METHOD_BRIGHTNESS,
+		.description	= "LCD Brightness",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "volume",
+		.method		= ACPI_THINKPAD_METHOD_VOLUME,
+		.description	= "Volume",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "mute",
+		.method		= ACPI_THINKPAD_METHOD_MUTE,
+		.description	= "Mute",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "thinklight",
+		.method		= ACPI_THINKPAD_METHOD_THINKLIGHT,
+		.description	= "Thinklight enable",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "bluetooth",
+		.method		= ACPI_THINKPAD_METHOD_BLUETOOTH,
+		.description	= "Bluetooth enable",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "wlan",
+		.method		= ACPI_THINKPAD_METHOD_WLAN,
+		.description	= "WLAN enable",
+		.access		= CTLTYPE_INT | CTLFLAG_RD
+	},
+	{
+		.name		= "fan_level",
+		.method		= ACPI_THINKPAD_METHOD_FANLEVEL,
+		.description	= "Fan level",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "fan",
+		.method		= ACPI_THINKPAD_METHOD_FANSTATUS,
+		.description	= "Fan enable",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+
+	{ NULL, 0, NULL, 0 }
+};
+
+/* ACPI_SERIAL_DECL(thinkpad, "ACPI THINKPAD extras"); */
+static int	acpi_thinkpad_probe(device_t dev);
+static int	acpi_thinkpad_attach(device_t dev);
+static int	acpi_thinkpad_detach(device_t dev);
+
+#if 0 /* not yet */
+static void	thinkpad_led(void *softc, int onoff);
+static void	thinkpad_led_task(struct acpi_thinkpad_softc *sc,
+		int pending __unused);
+#endif
+
+static int	acpi_thinkpad_sysctl(SYSCTL_HANDLER_ARGS);
+static int	acpi_thinkpad_sysctl_init(struct acpi_thinkpad_softc *sc,
+		int method);
+static int	acpi_thinkpad_sysctl_get(struct acpi_thinkpad_softc *sc,
+		int method);
+static int	acpi_thinkpad_sysctl_set(struct acpi_thinkpad_softc *sc,
+		int method, int val);
+
+static int	acpi_thinkpad_eventmask_set(struct acpi_thinkpad_softc *sc,
+		int val);
+static void	acpi_thinkpad_notify(ACPI_HANDLE h, UINT32 notify,
+		void *context);
+static void	acpi_thinkpad_refresh(void *);
+
+static device_method_t acpi_thinkpad_methods[] = {
+	/* Device interface */
+	DEVMETHOD(device_probe, acpi_thinkpad_probe),
+	DEVMETHOD(device_attach, acpi_thinkpad_attach),
+	DEVMETHOD(device_detach, acpi_thinkpad_detach),
+	{0, 0}
+};
+
+static driver_t	acpi_thinkpad_driver = {
+	"acpi_thinkpad",
+	acpi_thinkpad_methods,
+	sizeof(struct acpi_thinkpad_softc),
+};
+
+static devclass_t acpi_thinkpad_devclass;
+
+DRIVER_MODULE(acpi_thinkpad, acpi, acpi_thinkpad_driver,
+    acpi_thinkpad_devclass, 0, 0);
+MODULE_DEPEND(acpi_thinkpad, acpi, 1, 1, 1);
+static char    *thinkpad_ids[] = {"IBM0068", NULL};
+
+#if 0 /* not yet */
+static void
+thinkpad_led(void *softc, int onoff)
+{
+	struct acpi_thinkpad_softc* sc = (struct acpi_thinkpad_softc*) softc;
+
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+
+	if (sc->led_busy)
+		return;
+
+	sc->led_busy = 1;
+	sc->led_state = onoff;
+
+	AcpiOsExecute(OSL_NOTIFY_HANDLER, (void *)thinkpad_led_task, sc);
+}
+
+static void
+thinkpad_led_task(struct acpi_thinkpad_softc *sc, int pending __unused)
+{
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+
+	/* ACPI_SERIAL_BEGIN(thinkpad); */
+	acpi_thinkpad_sysctl_set(sc, ACPI_THINKPAD_METHOD_THINKLIGHT, sc->led_state);
+	/* ACPI_SERIAL_END(thinkpad); */
+
+	sc->led_busy = 0;
+}
+#endif
+
+static int
+acpi_thinkpad_probe(device_t dev)
+{
+	if (acpi_disabled("thinkpad") ||
+	    ACPI_ID_PROBE(device_get_parent(dev), dev, thinkpad_ids) == NULL ||
+	    device_get_unit(dev) != 0) 
+		return (ENXIO);
+
+	device_set_desc(dev, "IBM/Lenovo ThinkPad ACPI Extras");
+	return (0);
+}
+
+static int
+acpi_thinkpad_attach(device_t dev)
+{
+	struct acpi_thinkpad_softc	*sc;
+	struct acpi_softc	*acpi_sc;
+	devclass_t		ec_devclass;
+	int			i;
+
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t) __func__);
+
+	sc = device_get_softc(dev);
+	sc->dev = dev;
+	sc->handle = acpi_get_handle(dev);
+
+	acpi_sc = acpi_device_get_parent_softc(dev);
+
+	/* Look for the first embedded controller */
+        if (!(ec_devclass = devclass_find ("acpi_ec"))) {
+		if (bootverbose)
+			device_printf(dev, "Couldn't find acpi_ec devclass\n");
+		return (EINVAL);
+	}
+        if (!(sc->ec_dev = devclass_get_device(ec_devclass, 0))) {
+		if (bootverbose)
+			device_printf(dev, "Couldn't find acpi_ec device\n");
+		return (EINVAL);
+	}
+	sc->ec_handle = acpi_get_handle(sc->ec_dev);
+
+	/* ACPI_SERIAL_BEGIN(thinkpad); */
+
+#if 0
+	/* Get the sysctl tree */
+	sc->sysctl_ctx = device_get_sysctl_ctx(dev);
+	sc->sysctl_tree = device_get_sysctl_tree(dev);
+#endif
+	sysctl_ctx_init(sc->sysctl_ctx);
+	sc->sysctl_tree = SYSCTL_ADD_NODE(sc->sysctl_ctx,
+	    SYSCTL_CHILDREN(acpi_sc->acpi_sysctl_tree), OID_AUTO,
+	    "thinkpad", CTLFLAG_RD, 0, "");
+
+	/* Look for event mask and hook up the nodes */
+	sc->events_mask_supported = ACPI_SUCCESS(acpi_GetInteger(sc->handle,
+	    THINKPAD_NAME_EVENTS_MASK_GET, &sc->events_initialmask));
+
+	if (sc->events_mask_supported) {
+		SYSCTL_ADD_INT(sc->sysctl_ctx,
+		    SYSCTL_CHILDREN(sc->sysctl_tree), OID_AUTO,
+		    "initialmask", CTLFLAG_RD,
+		    &sc->events_initialmask, 0, "Initial eventmask");
+
+		/* The availmask is the bitmask of supported events */
+		if (ACPI_FAILURE(acpi_GetInteger(sc->handle,
+		    THINKPAD_NAME_EVENTS_AVAILMASK, &sc->events_availmask)))
+			sc->events_availmask = 0xffffffff;
+
+		SYSCTL_ADD_INT(sc->sysctl_ctx,
+		    SYSCTL_CHILDREN(sc->sysctl_tree), OID_AUTO,
+		    "availmask", CTLFLAG_RD,
+		    &sc->events_availmask, 0, "Mask of supported events");
+	}
+
+	/* Hook up proc nodes */
+	for (i = 0; acpi_thinkpad_sysctls[i].name != NULL; i++) {
+		if (!acpi_thinkpad_sysctl_init(sc,
+		    acpi_thinkpad_sysctls[i].method))
+			continue;
+
+		SYSCTL_ADD_PROC(sc->sysctl_ctx,
+		    SYSCTL_CHILDREN(sc->sysctl_tree), OID_AUTO,
+		    acpi_thinkpad_sysctls[i].name,
+		    acpi_thinkpad_sysctls[i].access,
+		    sc, i, acpi_thinkpad_sysctl, "I",
+		    acpi_thinkpad_sysctls[i].description);
+	}
+
+	/* ACPI_SERIAL_END(thinkpad); */
+
+	/* Handle notifies */
+	AcpiInstallNotifyHandler(sc->handle, ACPI_DEVICE_NOTIFY,
+	    acpi_thinkpad_notify, dev);
+
+#if 0
+	/* Hook up light to led(4) */
+	if (sc->light_set_supported)
+		sc->led_dev = led_create_state(thinkpad_led, sc, "thinklight",
+		    sc->light_val);
+#endif
+	/* Attach sensors(9). */
+	if (sensor_task_register(sc, acpi_thinkpad_refresh, 5)) {
+		device_printf(sc->dev, "unable to register update task\n");
+		return 1;
+	}
+
+	strlcpy(sc->sensordev.xname, device_get_nameunit(sc->dev),
+	    sizeof(sc->sensordev.xname));
+
+	/* XXX: Temp sensors */
+	for (i = 0; i < 8; ++i) {
+		sc->sensors[i].type = SENSOR_TEMP;
+		sensor_attach(&sc->sensordev, &sc->sensors[i]);
+	}
+	
+	/* Fan RPM sensor */
+	sc->sensors[8].type = SENSOR_FANRPM;
+	sensor_attach(&sc->sensordev, &sc->sensors[8]);
+
+	sensordev_install(&sc->sensordev);
+
+	return (0);
+}
+
+static int
+acpi_thinkpad_detach(device_t dev)
+{
+	int i;
+
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t) __func__);
+
+	struct acpi_thinkpad_softc *sc = device_get_softc(dev);
+
+	/* Disable events and restore eventmask */
+	/* ACPI_SERIAL_BEGIN(thinkpad); */
+	acpi_thinkpad_sysctl_set(sc, ACPI_THINKPAD_METHOD_EVENTS, 0);
+	acpi_thinkpad_sysctl_set(sc, ACPI_THINKPAD_METHOD_EVENTMASK,
+	    sc->events_initialmask);
+	/* ACPI_SERIAL_END(thinkpad); */
+
+	AcpiRemoveNotifyHandler(sc->handle, ACPI_DEVICE_NOTIFY,
+	    acpi_thinkpad_notify);
+
+	sysctl_ctx_free(sc->sysctl_ctx);
+
+#if 0
+	if (sc->led_dev != NULL)
+		led_destroy(sc->led_dev);
+#endif
+	sensordev_deinstall(&sc->sensordev);
+	for (i = 0; i < 9; i++)
+		sensor_detach(&sc->sensordev, &sc->sensors[i]);
+	sensor_task_unregister(sc);
+
+	return (0);
+}
+
+static int
+acpi_thinkpad_eventmask_set(struct acpi_thinkpad_softc *sc, int val)
+{
+	int i;
+	ACPI_OBJECT		arg[2];
+	ACPI_OBJECT_LIST	args;
+	ACPI_STATUS		status;
+
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+	/* ACPI_SERIAL_ASSERT(thinkpad); */
+
+	args.Count = 2;
+	args.Pointer = arg;
+	arg[0].Type = ACPI_TYPE_INTEGER;
+	arg[1].Type = ACPI_TYPE_INTEGER;
+
+	for (i = 0; i < 32; ++i) {
+		arg[0].Integer.Value = i+1;
+		arg[1].Integer.Value = (((1 << i) & val) != 0);
+		status = AcpiEvaluateObject(sc->handle,
+		    THINKPAD_NAME_EVENTS_MASK_SET, &args, NULL);
+
+		if (ACPI_FAILURE(status))
+			return (status);
+	}
+
+	return (0);
+}
+
+static int
+acpi_thinkpad_sysctl(SYSCTL_HANDLER_ARGS)
+{
+	struct acpi_thinkpad_softc	*sc;
+	int			arg;
+	int			error = 0;
+	int			function;
+	int			method;
+	
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+
+	sc = (struct acpi_thinkpad_softc *)oidp->oid_arg1;
+	function = oidp->oid_arg2;
+	method = acpi_thinkpad_sysctls[function].method;
+
+	/* ACPI_SERIAL_BEGIN(thinkpad); */
+	arg = acpi_thinkpad_sysctl_get(sc, method);
+	error = sysctl_handle_int(oidp, &arg, 0, req);
+
+	/* Sanity check */
+	if (error != 0 || req->newptr == NULL)
+		goto out;
+
+	/* Update */
+	error = acpi_thinkpad_sysctl_set(sc, method, arg);
+
+out:
+	/* ACPI_SERIAL_END(thinkpad); */
+	return (error);
+}
+
+static int
+acpi_thinkpad_sysctl_get(struct acpi_thinkpad_softc *sc, int method)
+{
+	ACPI_INTEGER	val_ec;
+	int 		val = 0, key;
+
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+	/* ACPI_SERIAL_ASSERT(thinkpad); */
+
+	switch (method) {
+	case ACPI_THINKPAD_METHOD_EVENTS:
+		acpi_GetInteger(sc->handle, THINKPAD_NAME_EVENTS_STATUS_GET,
+		    &val);
+		break;
+
+	case ACPI_THINKPAD_METHOD_EVENTMASK:
+		if (sc->events_mask_supported)
+			acpi_GetInteger(sc->handle,
+			    THINKPAD_NAME_EVENTS_MASK_GET, &val);
+		break;
+
+	case ACPI_THINKPAD_METHOD_HOTKEY:
+		/*
+		 * Construct the hotkey as a bitmask as illustrated below.
+		 * Note that whenever a key was pressed, the respecting bit
+		 * toggles and nothing else changes.
+		 * +--+--+-+-+-+-+-+-+-+-+-+-+
+		 * |11|10|9|8|7|6|5|4|3|2|1|0|
+		 * +--+--+-+-+-+-+-+-+-+-+-+-+
+		 *   |  | | | | | | | | | | |
+		 *   |  | | | | | | | | | | +- Home Button
+		 *   |  | | | | | | | | | +--- Search Button
+		 *   |  | | | | | | | | +----- Mail Button
+		 *   |  | | | | | | | +------- Thinkpad Button
+		 *   |  | | | | | | +--------- Zoom (Fn + Space)
+		 *   |  | | | | | +----------- WLAN Button
+		 *   |  | | | | +------------- Video Button
+		 *   |  | | | +--------------- Hibernate Button
+		 *   |  | | +----------------- Thinklight Button
+		 *   |  | +------------------- Screen expand (Fn + F8)
+		 *   |  +--------------------- Brightness
+		 *   +------------------------ Volume/Mute
+		 */
+		key = rtcin(THINKPAD_RTC_HOTKEY1);
+		val = (THINKPAD_RTC_MASK_HOME | THINKPAD_RTC_MASK_SEARCH |
+		    THINKPAD_RTC_MASK_MAIL | THINKPAD_RTC_MASK_WLAN) & key;
+		key = rtcin(THINKPAD_RTC_HOTKEY2);
+		val |= (THINKPAD_RTC_MASK_THINKPAD | THINKPAD_RTC_MASK_VIDEO |
+		    THINKPAD_RTC_MASK_HIBERNATE) & key;
+		val |= (THINKPAD_RTC_MASK_ZOOM & key) >> 1;
+		key = rtcin(THINKPAD_RTC_THINKLIGHT);
+		val |= (THINKPAD_RTC_MASK_THINKLIGHT & key) << 4;
+		key = rtcin(THINKPAD_RTC_SCREENEXPAND);
+		val |= (THINKPAD_RTC_MASK_THINKLIGHT & key) << 4;
+		key = rtcin(THINKPAD_RTC_BRIGHTNESS);
+		val |= (THINKPAD_RTC_MASK_BRIGHTNESS & key) << 5;
+		key = rtcin(THINKPAD_RTC_VOLUME);
+		val |= (THINKPAD_RTC_MASK_VOLUME & key) << 4;
+		break;
+
+	case ACPI_THINKPAD_METHOD_BRIGHTNESS:
+		ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_BRIGHTNESS, &val_ec, 1);
+		val = val_ec & THINKPAD_EC_MASK_BRI;
+		break;
+
+	case ACPI_THINKPAD_METHOD_VOLUME:
+		ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_VOLUME, &val_ec, 1);
+		val = val_ec & THINKPAD_EC_MASK_VOL;
+		break;
+
+	case ACPI_THINKPAD_METHOD_MUTE:
+		val = ((val_ec & THINKPAD_EC_MASK_MUTE) ==
+		    THINKPAD_EC_MASK_MUTE);
+		break;
+
+	case ACPI_THINKPAD_METHOD_THINKLIGHT:
+		if (sc->light_get_supported)
+			acpi_GetInteger(sc->ec_handle, THINKPAD_NAME_KEYLIGHT,
+			    &val);
+		else
+			val = sc->light_val;
+		break;
+
+	case ACPI_THINKPAD_METHOD_BLUETOOTH:
+		acpi_GetInteger(sc->handle, THINKPAD_NAME_WLAN_BT_GET, &val);
+		sc->wlan_bt_flags = val;
+		val = ((val & THINKPAD_NAME_MASK_BT) != 0);
+		break;
+
+	case ACPI_THINKPAD_METHOD_WLAN:
+		acpi_GetInteger(sc->handle, THINKPAD_NAME_WLAN_BT_GET, &val);
+		sc->wlan_bt_flags = val;
+		val = ((val & THINKPAD_NAME_MASK_WLAN) != 0);
+		break;
+
+	case ACPI_THINKPAD_METHOD_FANSPEED:
+		if (sc->fan_handle) {
+			if (ACPI_FAILURE(acpi_GetInteger(sc->fan_handle,
+			    NULL, &val)))
+				val = -1;
+		}
+		else {
+			ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_FANSPEED,
+			    &val_ec, 2);
+			val = val_ec;
+		}
+		break;
+
+	case ACPI_THINKPAD_METHOD_FANLEVEL:
+		/*
+		 * The THINKPAD_EC_FANSTATUS register works as follows:
+		 * Bit 0-5 indicate the level at which the fan operates. Only
+		 *       values between 0 and 7 have an effect. Everything
+		 *       above 7 is treated the same as level 7
+		 * Bit 6 overrides the fan speed limit if set to 1
+		 * Bit 7 indicates at which mode the fan operates:
+		 *       manual (0) or automatic (1)
+		 */
+		if (!sc->fan_handle) {
+			ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_FANSTATUS,
+			    &val_ec, 1);
+			val = val_ec & THINKPAD_EC_MASK_FANLEVEL;
+		}
+		break;
+
+	case ACPI_THINKPAD_METHOD_FANSTATUS:
+		if (!sc->fan_handle) {
+			ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_FANSTATUS,
+			    &val_ec, 1);
+			val = (val_ec & THINKPAD_EC_MASK_FANSTATUS) ==
+			    THINKPAD_EC_MASK_FANSTATUS;
+		}
+		else
+			val = -1;
+		break;
+	}
+
+	return (val);
+}
+
+static int
+acpi_thinkpad_sysctl_set(struct acpi_thinkpad_softc *sc, int method, int arg)
+{
+	int			val, step, i;
+	ACPI_INTEGER		val_ec;
+	ACPI_OBJECT		Arg;
+	ACPI_OBJECT_LIST	Args;
+	ACPI_STATUS		status;
+
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+	/* ACPI_SERIAL_ASSERT(thinkpad); */
+
+	switch (method) {
+	case ACPI_THINKPAD_METHOD_EVENTS:
+		if (arg < 0 || arg > 1)
+			return (EINVAL);
+
+		status = acpi_SetInteger(sc->handle,
+		    THINKPAD_NAME_EVENTS_STATUS_SET, arg);
+		if (ACPI_FAILURE(status))
+			return (status);
+		if (sc->events_mask_supported)
+			return acpi_thinkpad_eventmask_set(sc,
+			    sc->events_availmask);
+		break;
+
+	case ACPI_THINKPAD_METHOD_EVENTMASK:
+		if (sc->events_mask_supported)
+			return acpi_thinkpad_eventmask_set(sc, arg);
+		break;
+
+	case ACPI_THINKPAD_METHOD_BRIGHTNESS:
+		if (arg < 0 || arg > 7)
+			return (EINVAL);
+
+		if (sc->cmos_handle) {
+			/* Read the current brightness */
+			status = ACPI_EC_READ(sc->ec_dev,
+			    THINKPAD_EC_BRIGHTNESS, &val_ec, 1);
+			if (ACPI_FAILURE(status))
+				return (status);
+			val = val_ec & THINKPAD_EC_MASK_BRI;
+
+			Args.Count = 1;
+			Args.Pointer = &Arg;
+			Arg.Type = ACPI_TYPE_INTEGER;
+			Arg.Integer.Value = (arg > val) ?
+			    THINKPAD_CMOS_BRIGHTNESS_UP :
+			    THINKPAD_CMOS_BRIGHTNESS_DOWN;
+
+			step = (arg > val) ? 1 : -1;
+			for (i = val; i != arg; i += step) {
+				status = AcpiEvaluateObject(sc->cmos_handle,
+				    NULL, &Args, NULL);
+				if (ACPI_FAILURE(status))
+					break;
+			}
+		}
+		return ACPI_EC_WRITE(sc->ec_dev, THINKPAD_EC_BRIGHTNESS,
+		    arg, 1);
+		break;
+
+	case ACPI_THINKPAD_METHOD_VOLUME:
+		if (arg < 0 || arg > 14)
+			return (EINVAL);
+
+		status = ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_VOLUME,
+		    &val_ec, 1);
+		if (ACPI_FAILURE(status))
+			return (status);
+
+		if (sc->cmos_handle) {
+			val = val_ec & THINKPAD_EC_MASK_VOL;
+
+			Args.Count = 1;
+			Args.Pointer = &Arg;
+			Arg.Type = ACPI_TYPE_INTEGER;
+			Arg.Integer.Value = (arg > val) ?
+			    THINKPAD_CMOS_VOLUME_UP : THINKPAD_CMOS_VOLUME_DOWN;
+
+			step = (arg > val) ? 1 : -1;
+			for (i = val; i != arg; i += step) {
+				status = AcpiEvaluateObject(sc->cmos_handle,
+				    NULL, &Args, NULL);
+				if (ACPI_FAILURE(status))
+					break;
+			}
+		}
+		return ACPI_EC_WRITE(sc->ec_dev, THINKPAD_EC_VOLUME, arg +
+		    (val_ec & (~THINKPAD_EC_MASK_VOL)), 1);
+		break;
+
+	case ACPI_THINKPAD_METHOD_MUTE:
+		if (arg < 0 || arg > 1)
+			return (EINVAL);
+
+		status = ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_VOLUME,
+		    &val_ec, 1);
+		if (ACPI_FAILURE(status))
+			return (status);
+
+		if (sc->cmos_handle) {
+			val = val_ec & THINKPAD_EC_MASK_VOL;
+
+			Args.Count = 1;
+			Args.Pointer = &Arg;
+			Arg.Type = ACPI_TYPE_INTEGER;
+			Arg.Integer.Value = THINKPAD_CMOS_VOLUME_MUTE;
+
+			status = AcpiEvaluateObject(sc->cmos_handle, NULL,
+			    &Args, NULL);
+			if (ACPI_FAILURE(status))
+				break;
+		}
+		return ACPI_EC_WRITE(sc->ec_dev, THINKPAD_EC_VOLUME, (arg==1) ?
+		   val_ec | THINKPAD_EC_MASK_MUTE :
+		   val_ec & (~THINKPAD_EC_MASK_MUTE), 1);
+		break;
+
+	case ACPI_THINKPAD_METHOD_THINKLIGHT:
+		if (arg < 0 || arg > 1)
+			return (EINVAL);
+
+		if (sc->light_set_supported) {
+			Args.Count = 1;
+			Args.Pointer = &Arg;
+			Arg.Type = ACPI_TYPE_INTEGER;
+			Arg.Integer.Value = arg ?
+			    sc->light_cmd_on : sc->light_cmd_off;
+
+			status = AcpiEvaluateObject(sc->light_handle, NULL,
+			    &Args, NULL);
+			if (ACPI_SUCCESS(status))
+				sc->light_val = arg;
+			return (status);
+		}
+		break;
+
+	case ACPI_THINKPAD_METHOD_BLUETOOTH:
+		if (arg < 0 || arg > 1)
+			return (EINVAL);
+
+		val = (arg == 1) ? sc->wlan_bt_flags |
+		    THINKPAD_NAME_MASK_BT :
+		    sc->wlan_bt_flags & (~THINKPAD_NAME_MASK_BT);
+		return acpi_SetInteger(sc->handle, THINKPAD_NAME_WLAN_BT_SET,
+		    val);
+		break;
+
+	case ACPI_THINKPAD_METHOD_FANLEVEL:
+		if (arg < 0 || arg > 7)
+			return (EINVAL);
+
+		if (!sc->fan_handle) {
+			/* Read the current fanstatus */
+			ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_FANSTATUS,
+			    &val_ec, 1);
+			val = val_ec & (~THINKPAD_EC_MASK_FANLEVEL);
+
+			return ACPI_EC_WRITE(sc->ec_dev, THINKPAD_EC_FANSTATUS,
+			    val | arg, 1);
+		}
+		break;
+
+	case ACPI_THINKPAD_METHOD_FANSTATUS:
+		if (arg < 0 || arg > 1)
+			return (EINVAL);
+
+		if (!sc->fan_handle) {
+			/* Read the current fanstatus */
+			ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_FANSTATUS,
+			    &val_ec, 1);
+
+			return ACPI_EC_WRITE(sc->ec_dev, THINKPAD_EC_FANSTATUS,
+			    (arg == 1) ? (val_ec | THINKPAD_EC_MASK_FANSTATUS) :
+			    (val_ec & (~THINKPAD_EC_MASK_FANSTATUS)), 1);
+		}
+		break;
+	}
+
+	return (0);
+}
+
+static int
+acpi_thinkpad_sysctl_init(struct acpi_thinkpad_softc *sc, int method)
+{
+	int 			dummy;
+	ACPI_OBJECT_TYPE 	cmos_t;
+	ACPI_HANDLE		ledb_handle;
+
+	switch (method) {
+	case ACPI_THINKPAD_METHOD_EVENTS:
+		/* Events are disabled by default */
+		return (TRUE);
+
+	case ACPI_THINKPAD_METHOD_EVENTMASK:
+		return (sc->events_mask_supported);
+
+	case ACPI_THINKPAD_METHOD_HOTKEY:
+	case ACPI_THINKPAD_METHOD_BRIGHTNESS:
+	case ACPI_THINKPAD_METHOD_VOLUME:
+	case ACPI_THINKPAD_METHOD_MUTE:
+		/* EC is required here, which was already checked before */
+		return (TRUE);
+
+	case ACPI_THINKPAD_METHOD_THINKLIGHT:
+		sc->cmos_handle = NULL;
+		sc->light_get_supported = ACPI_SUCCESS(acpi_GetInteger(
+		    sc->ec_handle, THINKPAD_NAME_KEYLIGHT, &sc->light_val));
+
+		if ((ACPI_SUCCESS(AcpiGetHandle(sc->handle, "\\UCMS",
+		    &sc->light_handle)) ||
+		    ACPI_SUCCESS(AcpiGetHandle(sc->handle, "\\CMOS",
+		    &sc->light_handle)) ||
+		    ACPI_SUCCESS(AcpiGetHandle(sc->handle, "\\CMS",
+		    &sc->light_handle))) &&
+		    ACPI_SUCCESS(AcpiGetType(sc->light_handle, &cmos_t)) &&
+		    cmos_t == ACPI_TYPE_METHOD) {
+			sc->light_cmd_on = 0x0c;
+			sc->light_cmd_off = 0x0d;
+			sc->cmos_handle = sc->light_handle;
+		}
+		else if (ACPI_SUCCESS(AcpiGetHandle(sc->handle, "\\LGHT",
+		    &sc->light_handle))) {
+			sc->light_cmd_on = 1;
+			sc->light_cmd_off = 0;
+		}
+		else
+			sc->light_handle = NULL;
+
+		sc->light_set_supported = (sc->light_handle &&
+		    ACPI_FAILURE(AcpiGetHandle(sc->ec_handle, "LEDB",
+		    &ledb_handle)));
+
+		if (sc->light_get_supported)
+			return (TRUE);
+
+		if (sc->light_set_supported) {
+			sc->light_val = 0;
+			return (TRUE);
+		}
+
+		return (FALSE);
+
+	case ACPI_THINKPAD_METHOD_BLUETOOTH:
+	case ACPI_THINKPAD_METHOD_WLAN:
+		if (ACPI_SUCCESS(acpi_GetInteger(sc->handle,
+		    THINKPAD_NAME_WLAN_BT_GET, &dummy)))
+			return (TRUE);
+		return (FALSE);
+
+	case ACPI_THINKPAD_METHOD_FANSPEED:
+		/* 
+		 * Some models report the fan speed in levels from 0-7
+		 * Newer models report it contiguously
+		 */
+		sc->fan_levels = (ACPI_SUCCESS(AcpiGetHandle(sc->handle, "GFAN",
+		    &sc->fan_handle)) ||
+		    ACPI_SUCCESS(AcpiGetHandle(sc->handle, "\\FSPD",
+		    &sc->fan_handle)));
+		return (TRUE);
+
+	case ACPI_THINKPAD_METHOD_FANLEVEL:
+	case ACPI_THINKPAD_METHOD_FANSTATUS:
+		/* 
+		 * Fan status is only supported on those models,
+		 * which report fan RPM contiguously, not in levels
+		 */
+		if (sc->fan_levels)
+			return (FALSE);
+		return (TRUE);
+
+	case ACPI_THINKPAD_METHOD_THERMAL:
+		if (ACPI_SUCCESS(acpi_GetInteger(sc->ec_handle,
+		    THINKPAD_NAME_THERMAL_GET, &dummy))) {
+			sc->thermal_updt_supported =
+			    ACPI_SUCCESS(acpi_GetInteger(sc->ec_handle,
+			    THINKPAD_NAME_THERMAL_UPDT, &dummy));
+			return (TRUE);
+		}
+		return (FALSE);
+	}
+	return (FALSE);
+}
+
+static void
+acpi_thinkpad_notify(ACPI_HANDLE h, UINT32 notify, void *context)
+{
+	int		event, arg, type;
+	device_t	dev = context;
+	struct acpi_thinkpad_softc *sc = device_get_softc(dev);
+
+	ACPI_FUNCTION_TRACE_U32((char *)(uintptr_t)__func__, notify);
+
+	if (notify != 0x80)
+		device_printf(dev, "Unknown notify\n");
+
+	for (;;) {
+		acpi_GetInteger(acpi_get_handle(dev), THINKPAD_NAME_EVENTS_GET,
+		    &event);
+
+		if (event == 0)
+			break;
+
+		type = (event >> 12) & 0xf;
+		arg = event & 0xfff;
+		switch (type) {
+		case 1:
+			if (!(sc->events_availmask & (1 << (arg - 1)))) {
+				device_printf(dev, "Unknown key %d\n", arg);
+				break;
+			}
+
+			/* Notify devd(8) */
+			device_printf(dev, "THINKPAD event: %u\n",
+			    (arg & 0xff));
+			acpi_UserNotify("THINKPAD", h, (arg & 0xff));
+			break;
+		default:
+			break;
+		}
+	}
+}
+
+static void
+acpi_thinkpad_refresh(void *arg)
+{
+	struct acpi_thinkpad_softc *sc = (struct acpi_thinkpad_softc *)arg;
+	char temp_cmd[] = "TMP0";
+	int data, i;
+	ACPI_INTEGER speed;
+
+	for (i = 0; i < 8; i++) {
+		temp_cmd[3] = '0' + i;
+		
+                /*
+                 * The TMPx methods seem to return +/- 128 or 0
+                 * when the respecting sensor is not available
+                 */
+		sc->sensors[i].flags &= ~SENSOR_FINVALID;
+                if (ACPI_FAILURE(acpi_GetInteger(sc->ec_handle, temp_cmd,
+                    &data)) || ABS(data) == 128 || data == 0) {
+			sc->sensors[i].flags |= SENSOR_FINVALID;
+                        data = 0;
+		}
+                else if (sc->thermal_updt_supported) {
+                        /* XXX: Temperature is reported in tenth of Kelvin */
+                        data = (data - 2732 + 5) / 10;
+		}
+		sc->sensors[i].value = data * 1000000 + 273150000;
+        }
+	
+	sc->sensors[8].flags &= ~SENSOR_FINVALID;
+	if (sc->fan_handle) {
+		if (ACPI_FAILURE(acpi_GetInteger(sc->fan_handle,
+		    NULL, &data)))
+			sc->sensors[8].flags |= SENSOR_FINVALID;
+                        data = -1;
+        }
+        else {
+                ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_FANSPEED, &speed, 2);
+                data = speed;
+        }
+
+	sc->sensors[8].value = data;
+}
diff --git a/sys/platform/pc32/conf/files b/sys/platform/pc32/conf/files
--- a/sys/platform/pc32/conf/files
+++ b/sys/platform/pc32/conf/files
@@ -72,6 +72,7 @@ dev/serial/dgb/dgm.c			optional	dgm
 ${OSACPI_MD_DIR}/acpi_machdep.c		optional        acpi
 ${OSACPI_MD_DIR}/acpi_wakeup.c		optional        acpi
 ${OSACPI_MD_DIR}/acpi_toshiba.c		optional        acpi_toshiba acpi
+${ACPICA_DIR}/acpi_thinkpad/acpi_thinkpad.c optional	acpi_thinkpad acpi
 acpi.h					optional	acpi		\
 	dependency	"$S/${ACPICA_DIR}/include/acpi.h"		\
 	compile-with	"cp $S/${ACPICA_DIR}/include/acpi.h ${.OBJDIR}/"	\



From hasso at estpak.ee  Thu Mar 20 03:49:13 2008
From: hasso at estpak.ee (Hasso Tepper)
Date: Thu, 20 Mar 2008 03:49:13 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Some questions regarding ACPI
In-Reply-To: <200803191322.46366.hasso@estpak.ee>
Message-ID: <200803201237.28823.hasso@estpak.ee>

Hasso Tepper wrote:
> There is also one fatal issue -laptop locks up hardly (no panic) while 
> unloading module. Any idea regarding this is welcome.

Nevermind, solved.


-- 
Hasso




From dillon at apollo.backplane.com  Fri Mar 21 19:24:01 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Fri, 21 Mar 2008 19:24:01 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: panic: assertion: hammer_btree_cmp(cursor->left_bound,	&cursor->node->ondisk->elms[0].leaf.base) <= 0 in btree_split_leaf
In-Reply-To: <200802232204.m1NM4cxd046264@apollo.backplane.com>
Message-ID: <200803220212.m2M2CiAY014435@apollo.backplane.com>

:While trying to find a procedure to reliably reproduce the panic
:I reported last time, I caught a different panic (uploaded at
: ~y0netan1/crash/9/ on my leaf account).  I wrote the following shell
:script (make sure to edit variables DISKS and MOUNTPT before using this
:script or it may trash your system):

    Ok, I believe I have fixed the left_bound assertion.  I also believe
    I have fixed the node ref count assertion on umount.

    There is currently one unfixed assertion related to the I/O
    path... sometimes the bp is being improperly disassociated from the
    related HAMMER structure.

    The full-filesystem case is still not being handled so don't test that :-)

					    -Matt





From c.turner at 199technologies.org  Sun Mar 23 09:48:29 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Sun, 23 Mar 2008 09:48:29 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
Message-ID: <47E6870C.4080709@199technologies.org>

I'm finally getting around to doing 1.12 upgrades, and have setup a 
separate machine to do my bulk package builds / upgrades etc,
so as not to disrupt my 'dev server' while things are being
built / tested

However, this seems kind of wasteful - the only purpose of this machine
is to build packages against a specific release..
And since building packages for a particular release generally requires 
only the userland, appropriate headers and correct 'uname' output - so:

it seems like if spoofing uname is configured inside a jail,
the next (or previous..) release can be installed into a jail and
used for building / testing packages without the overhead of a VM or 
maintaining a separate physical host

I did a quick scan of the tree to see what this would take, and, high 
level, it seems like only the following changes would need to be made:

- update struct jail to add a 'osrelease' string
  (implies bumping 'jail api' to 2?)
- update jail(8) to actually pass this information along
- update sys_uname to test ucred for jailed processes, and
  use the struct jail osrelease if appropriate
- similarly update sysctl kern.osrelease to support jail spoofing
  (if possible - didn't get this far in the research yet)
  could be less of a problem for builds, as I think most things use
 uname(1) ... but good to keep the environment consistent I suppose..
I'm still a bit confused as to how 'osrelease' is defined - everything
I'm finding is showing up as extern char[] .. perhaps this is something 
in the build I'm not familiar with?

also,

is the so-called 'stupid hackery' in sys_uname needed still?

Before I start any coding, does this:

- sound like something useful
- sound like the right approach
Thinking this could have wider useful implications e.g. for pkgbox
& so on -  for example setting up automated bulks w/various combinations 
of pkgsrc and releases, etc.

Cheers,

- Chris





From corecode at fs.ei.tum.de  Sun Mar 23 10:06:38 2008
From: corecode at fs.ei.tum.de (Simon 'corecode' Schubert)
Date: Sun, 23 Mar 2008 10:06:38 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <47E68C74.3080808@fs.ei.tum.de>

Chris Turner wrote:
I did a quick scan of the tree to see what this would take, and, high 
level, it seems like only the following changes would need to be made:
brave investigation.  but you could also simply set UNAME_r :)

sweatshorts % uname -r
1.13.0-DEVELOPMENT
sweatshorts % UNAME_r=1.12-RELEASE uname -r
1.12-RELEASE
I think that's good enough :D

cheers
  simon
--
Serve - BSD     +++  RENT this banner advert  +++    ASCII Ribbon   /"\
Work - Mac      +++  space for low ????????? NOW!1  +++      Campaign     \ /
Party Enjoy Relax   |   http://dragonflybsd.org      Against  HTML   \
Dude 2c 2 the max   !   http://golden-apple.biz       Mail + News   / \




From c.turner at 199technologies.org  Sun Mar 23 10:50:13 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Sun, 23 Mar 2008 10:50:13 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <47E69656.8080605@199technologies.org>

Simon 'corecode' Schubert wrote:
brave investigation.  but you could also simply set UNAME_r :)
Doh! Thanks for the tip!

they should change the phrase from RTFM to 'Carefully RTFM' :)

well.. scratch that change then. 1 less patch to write.

- Chris





From c.turner at 199technologies.org  Sun Mar 23 11:15:52 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Sun, 23 Mar 2008 11:15:52 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <47E69C7C.8010109@199technologies.org>

Chris Turner wrote:
Simon 'corecode' Schubert wrote:
brave investigation.  but you could also simply set UNAME_r :)

for the record - if anyone's interested - adding a line e.g.:

ALL_ENV+= UNAME_r=1.12-RELEASE

to mk.conf looks like it -might- work ..

(unless wants to chime in & verify)





From joerg at britannica.bec.de  Sun Mar 23 11:46:53 2008
From: joerg at britannica.bec.de (Joerg Sonnenberger)
Date: Sun, 23 Mar 2008 11:46:53 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <20080323181428.GA2099@britannica.bec.de>

On Sun, Mar 23, 2008 at 01:41:42PM -0400, Chris Turner wrote:
> they should change the phrase from RTFM to 'Carefully RTFM' :)

RTFMAI -- Read The Fine Manual Again, Idiot.

Joerg




From dillon at apollo.backplane.com  Sun Mar 23 20:05:36 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Sun, 23 Mar 2008 20:05:36 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
Message-ID: <200803240257.m2O2voNH038355@apollo.backplane.com>

    Here's an update on the HAMMER work!

    Current status:

    * Passes all standard filesystem stress tests and buildworld will
      run with a HAMMER /usr/obj.  Large histories are able to accumulate
      without effecting performance.

    * Pruning and reblocking code is in and partially tested, but now needs
      more stringent testing.

    * Full historical access appears to be working but needs testing.
      Note that a sync is still needed to flush dirty cached data prior
      to acquiring a timestamp for the 'snapshot' to be set in stone.
      (dirty data cached in-memory has no historical tags and must be
      committed to physical disk before it can be accessed historically).


    Current bugs:

    * There is one known bug in the standard operations code paths
      that results in an assertion in HAMMER's I/O subsystem.

    * There are probably bugs in the reblocking and/or pruning code.  More
      likely in the reblocking code.


    There are two big-ticket and several little-ticket items left.  HAMMER
    will officially go Alpha when the big-ticket items are done, and beta
    when we get a few of the little-ticket items done.

    Big ticket items left:

    * UNDO (crash recovery) code.  Currently it writes out undo records but
      they are not yet sequenced, buffer writes are not yet ordered, and
      there is no mount-time recovery code yet.

      This is the last item needed before HAMMER can go operational.

    * Filesystem full handling.  Currently no space is reserved for dirty
      cached data so it is possible to create/write files and for HAMMER
      to not have sufficient space left on-disk to flush it.


    Little ticket items:

    * Automated reblocking (currently these functions are manually
      initialized via the hammer utility).

    * I/O clustering and preliminary BMAP op when writing out large files.

    * CRC checking (CRC fields are reserved but not entirely generated yet
      and not yet checked at all).

    * Disaster Recovery filesystem scan.

    * Boot support.

    I expect all of these items and more to be handled by the 2.0 release
    in July.

			    Additional HAMMER capabilities
				(no timeline yet)

    * Adding, removing, and resizing a HAMMER filesystem's backing store.

			Ultimate Goals and working towards them
				(no timeline yet)

    Our ultimate goal with HAMMER and DragonFly in general is to support
    fully cache coherent replication in a multi-machine environment.  This
    involves several steps and networking protocols.

    * Replication of synchronization streams based on the UNDO log.  If
      resynchronizing to a target which is too old a B-Tree scan will
      likely be required.

    * Cache coherency protocols for machine-machine coherency for both
      replicated and remote-HAMMER access.

    I have no time frame for these items yet.  It will depend on how quickly
    HAMMER moves to Alpha and Beta status.  I will say, however, now
    that HAMMER's on-disk format has solidified, that I have a very precise
    understanding of the protocols that will be needed to accomplish fully
    cache coherent remote access for both replicated and non-replicated
    (remote mount style) access.

    And, as you know, fully coherent filesystem access across machines is
    going to be the basis for DragonFly's clustering across said machines.

    In summary, things are progressing very well.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From justin at shiningsilence.com  Sun Mar 23 20:10:13 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Sun, 23 Mar 2008 20:10:13 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <53758.192.168.0.252.1206327873.squirrel@www.shiningsilence.com>

On Sun, March 23, 2008 12:36 pm, Chris Turner wrote:

> it seems like if spoofing uname is configured inside a jail,
> the next (or previous..) release can be installed into a jail and
> used for building / testing packages without the overhead of a VM or
> maintaining a separate physical host

If you don't need a jail to spoof uname, as others posted, you can
installworld into a chroot and build everything you want there using
Joerg's spiffy pbulk.  That's what I'm doing on pkgbox now; I can hand you
my somewhat terse notes if you want.  It would be relatively easy to set
up the configuration you're talking about.





From sepherosa at gmail.com  Sun Mar 23 20:18:20 2008
From: sepherosa at gmail.com (Sepherosa Ziehau)
Date: Sun, 23 Mar 2008 20:18:20 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <ea7b9c170803232012n2f27f893tf1d756d7c9770419@mail.gmail.com>

On Mon, Mar 24, 2008 at 2:14 AM, Joerg Sonnenberger
<joerg at britannica.bec.de> wrote:
> On Sun, Mar 23, 2008 at 01:41:42PM -0400, Chris Turner wrote:
>  > they should change the phrase from RTFM to 'Carefully RTFM' :)
>
>  RTFMAI -- Read The Fine Manual Again, Idiot.

http://leaf.dragonflybsd.org/~sephe/rtfm.jpg

:D

>
>  Joerg
>



-- 
Live Free or Die




From justin at shiningsilence.com  Sun Mar 23 20:38:30 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Sun, 23 Mar 2008 20:38:30 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: GSoC 2008 - mentors signup
Message-ID: <53885.192.168.0.252.1206329503.squirrel@www.shiningsilence.com>

If you are planning to be a mentor for a Summer of Code project, please
sign up here for the mentors mailing list:

http://groups.google.com/group/google-summer-of-code-mentors-list

If you've already signed up, your subscription should be set up tomorrow.





From justin at shiningsilence.com  Sun Mar 23 21:12:01 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Sun, 23 Mar 2008 21:12:01 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: GSoC 2008 - mentors signup
In-Reply-To: <53885.192.168.0.252.1206329503.squirrel@www.shiningsilence.com>
Message-ID: <54025.192.168.0.252.1206331572.squirrel@www.shiningsilence.com>

Also!

If you are a potential mentor and you have not done so yet:

http://code.google.com/soc/mentor_step1.html

Get yourself registered as a mentor for the Summer of Code project.  Once
you are in there, check off DragonFly in the "My Profile" section.

You will need a Google Account if you don't have one:

http://www.google.com/accounts

This will add you to the list of mentors in the Google Summer of Code web
application, so you can review/be attached to projects.

A guide is available if you want more information:

http://groups.google.com/group/google-summer-of-code-announce/web/guide-to-the-gsoc-web-app-for-mentors-and-organization-administrators






From c.turner at 199technologies.org  Mon Mar 24 04:29:28 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Mon, 24 Mar 2008 04:29:28 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <47E78ECE.4070307@199technologies.org>

Justin C. Sherrill wrote:
If you don't need a jail to spoof uname, as others posted, you can
installworld into a chroot and build everything you want there using
Joerg's spiffy pbulk.  That's what I'm doing on pkgbox now; I can hand you
my somewhat terse notes if you want.  It would be relatively easy to set
up the configuration you're talking about.
cheers - I guess I thought incorrectly that something 'special' was 
needed to get the uname to change .. have been using the legacy bulks in 
chroots / jails (for 'same os' builds) as I haven't quite migrated to 
pbulk yet ..

thanks for the help offer - I'll ask if I run into trouble.




From dillon at apollo.backplane.com  Mon Mar 24 08:28:49 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Mon, 24 Mar 2008 08:28:49 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <200803241500.m2OF0CG8043760@apollo.backplane.com>


:http://leaf.dragonflybsd.org/~sephe/rtfm.jpg
:
::D

    Ho!

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From elekktretterr at exemail.com.au  Mon Mar 24 09:10:15 2008
From: elekktretterr at exemail.com.au (Petr Janda)
Date: Mon, 24 Mar 2008 09:10:15 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
In-Reply-To: <200803240257.m2O2voNH038355@apollo.backplane.com>
Message-ID: <200803250138.49775.elekktretterr@exemail.com.au>


>
>     And, as you know, fully coherent filesystem access across machines is
>     going to be the basis for DragonFly's clustering across said machines.
>
>     In summary, things are progressing very well.
>


Hi Matt,
That's good to know things are going so well. Got a question. If memory serves 
me right, initially there was also going to be a thing called ANVIL, I can't 
remember what it was supposed to do and whether its still in your design. 
Could you elaborate a little?

Thanks,
Petr




From dillon at apollo.backplane.com  Mon Mar 24 14:12:11 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Mon, 24 Mar 2008 14:12:11 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
In-Reply-To: <200803240257.m2O2voNH038355@apollo.backplane.com>
Message-ID: <200803242100.m2OL0nWV046868@apollo.backplane.com>


:Hi Matt,
:That's good to know things are going so well. Got a question. If memory serves 
:me right, initially there was also going to be a thing called ANVIL, I can't 
:remember what it was supposed to do and whether its still in your design. 
:Could you elaborate a little?
:
:Thanks,
:Petr

    It's not really in the HAMMER design any more, primarily because HAMMER's
    volume model seems to work fine as-is.  Ultimately something like ANVIL
    (a block storage manager) would prove beneficial to the project but it
    would be treated as a separate project.  HAMMER's redundancy model is
    going to be baesd around replication and clustering.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From tgen at netphreax.net  Mon Mar 24 18:31:37 2008
From: tgen at netphreax.net (Thomas E. Spanjaard)
Date: Mon, 24 Mar 2008 18:31:37 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
In-Reply-To: <200803240257.m2O2voNH038355@apollo.backplane.com>
Message-ID: <47E85337.2070407@netphreax.net>

Matthew Dillon wrote:
    * Full historical access appears to be working but needs testing.
      Note that a sync is still needed to flush dirty cached data prior
      to acquiring a timestamp for the 'snapshot' to be set in stone.
      (dirty data cached in-memory has no historical tags and must be
      committed to physical disk before it can be accessed historically).
Wouldn't making timestamp queries (at least from userland) enforce a 
sync on the volume in question be useful here?
--
        Thomas E. Spanjaard
        tgen at netphreax.net
Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00005.pgp
Type: application/octet-stream
Size: 186 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080324/3077333f/attachment-0006.obj>

From dillon at apollo.backplane.com  Mon Mar 24 20:10:12 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Mon, 24 Mar 2008 20:10:12 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
In-Reply-To: <200803240257.m2O2voNH038355@apollo.backplane.com>
Message-ID: <200803250302.m2P32qLP050160@apollo.backplane.com>


:Wouldn't making timestamp queries (at least from userland) enforce a 
:sync on the volume in question be useful here?
:-- 
:         Thomas E. Spanjaard
:         tgen at netphreax.net

    Making the 'hammer now' command do a sync() is a good idea.  I will
    make that change right now so it doesn't get lost.

    Here's a general overview of the issues involved with having historical
    access to the filesystem:

				----------------

    Recording the timestamps in the in-memory cache, for a finer-grained
    snapshot capability, is doable but has its own issues.  Here's an
    illustration:

    open()  create file
    write() append 4K	(file size now 4K)
    write() append 4K	(file size now 8K)
    write() append 4K	(file size now 12K)
    write() append 4K	(file size now 16K)

    Now NONE of this has gone to disk yet, it's entirely in the in-memory
    cache.  The inode is in the in-memory cache.  The data is stored in
    the buffer cache.  Even the directory entry for the file that we
    just created is still in the in-memory cache (HAMMER caches the raw
    records it intends to commit later on).

    If I wanted to be able to acquire a timestamp between each write and
    'see' a snapshot of the file as of any point in the above sequence,
    then every write would also have to allocate a copy of the inode
    (because it changes size on each write).

    The data has the same problem though with a slightly different example.
    Lets say each write() was a seek-write, overwriting the previous data.
    Now with every write() I would have to allocate a copy of the data
    being overwritten.  This is complicated by the fact that the buffer
    cache has no clue about 'historical' accesses, so I would not be able
    to use the buffer cache to cache the data.

    There's also another problem and that is with the efficiency of the
    topology on-disk.  Even if I maintained all the copies of the inode
    and all the copies of the data in-memory, I would still have to sync
    all those copies to disk in order for things to remain historically
    coherent (whether it be in-cache or on-disk).  This would result in
    hundreds or even thousands of copies of the inode on-disk, not to
    mention potentially many copies of the data.

    I just don't want to do that right now, at least not as a default.  A
    lot of performance would be lost.  Hence a sync() is needed if
    you want to create a demark which you can accurately snapshot.

				-------------

    Here's a quick synopsis of how the cache would operate in a clustered
    filesystem:

    In order to properly integrate with in-memory caches, a wider cache
    coherency infrastructure is needed between machines such that
    modifications made on one machine proactively invalidate those
    protions of the cache(s) on other machines.  At the same time, any
    'dirty' cache data, for example when a file is created or written to,
    must lock the cache space in question on all other machines.
    The cache space in this case is not just the file data, but also the
    related namespaces (for creations, deletions, and renames).  Attempts
    to access locked spaces from other machines in the cluster would have
    to force a flush to the filesystem backing store and lower the cache
    states for the effected information on the original machine from dirty
    to shared-read-only.

    It will be easiest to integrate the cache coherency information into
    the buffer cache and namecache themselves.  Once a machine has dirtied
    an in-memory cache element... for example part of the namespace when
    creating a file or chunks of data written within a file, that machine
    must have a free hand to make further modifications to the cache spaces
    involved without further interaction with other machines.

				-------------

    Now, if you think of those two major elements you can see that they
    actually fit together quite well.  If I were to attempt to maintain
    transactional coherency on a per-system-call basis then the cache
    granularity between machines would have to be much, much smaller then
    our current in-memory caching elements provide.  That would become
    a really nasty coding problem.  So I don't even want to begin to
    complate transactional coherency at a finer-grain then sync() or
    fsync() until long after we actually have clustering working.

						-Matt





From elekktretterr at exemail.com.au  Mon Mar 24 21:56:58 2008
From: elekktretterr at exemail.com.au (Petr Janda)
Date: Mon, 24 Mar 2008 21:56:58 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
In-Reply-To: <200803240257.m2O2voNH038355@apollo.backplane.com>
Message-ID: <200803251516.16407.elekktretterr@exemail.com.au>

So is it needed to run hammer now in order to "create" a snapshot? What would 
I do in situation like this: got a hammer filesystem and couple of the files 
change on day to day basis. Then a week later I needed to access one of the 
files, in exactly the state they were 7 days ago.

Cheers,
Petr




From dillon at apollo.backplane.com  Mon Mar 24 22:34:15 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Mon, 24 Mar 2008 22:34:15 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
In-Reply-To: <200803240257.m2O2voNH038355@apollo.backplane.com>
Message-ID: <200803250526.m2P5QZ5X051081@apollo.backplane.com>


:So is it needed to run hammer now in order to "create" a snapshot? What would 
:I do in situation like this: got a hammer filesystem and couple of the files 
:change on day to day basis. Then a week later I needed to access one of the 
:files, in exactly the state they were 7 days ago.
:
:Cheers,
:Petr

    No, you do not have to run 'hammer now' to create a snapshot.  The
    kernel syncs all filesystems every 30 seconds, so if you do nothing
    at all you get a snapshot granularity of 30 seconds.

    Where you would use 'hammer now' is if you wanted the most current
    snapshot possible for the purpose of, say, backing up your filesystem
    to another machine.  You might do something like this:

	set timestamp = `hammer now`
	cpdup /mountpoint/@@$timestamp targethost:/somepath

    But if you didn't care about that you could just go back far enough
    that you get a stable historical view... e.g. go back 1 minute and you
    would have a stable view into your filesystem.

	set timestamp = `hammer stamp 60s`		<------ doesn't sync
	cpdup /mountpoint/@@$timestamp targethost:/somepath


    Ultimately the idea of managing filesystems this way is to still do
    regular backups from your production machine to your backup machine
    (ultimately by way of replication), with both running HAMMER, but only
    retain a limited amount of history on the production box.  You might
    desire to retain only one week's worth of history on the production box,
    retain one month's history on your local backup box, and retain a very
    granular one year's worth of history on your remote backup box.

    Come to think of it, I should add some more directives to the
    'hammer prune' command to make that easier to specify.

    Until I implement a live replication 'feed' the minimum granularity on
    the backup box will be how often you do your backups (e.g. once a day),
    and you can prune it into more granular forms from that starting point.
    Once we have a live replication feed the backup box will have the same
    30-second granularity that the production machine has.

    A major bullet point for this style of management is that the retention
    policy on the various boxes can be different even though they are
    all slaved off the same production filesystem.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From justin at shiningsilence.com  Tue Mar 25 05:58:49 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Tue, 25 Mar 2008 05:58:49 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: SoC - student signups
Message-ID: <58180.65.106.147.226.1206449676.squirrel@www.shiningsilence.com>

Here's a quick link roundup:

Are you a student?  Put in your application for a Google Summer of Code here:

http://code.google.com/soc/2008/student_signup.html

Student guide:
http://groups.google.com/group/google-summer-of-code-announce/web/guide-to-the-gsoc-web-app-for-student-applicants

Are you a mentor?  (That means hasso, hsu, sephe, matthias, TGEN, and
corecode right now)

Student proposals will show up on the mentor page, linked below.  You will
get to rate them, and take the one(s) that you want to mentor.

Mentor page:
http://code.google.com/soc/2008/mentor_home.html
Mentor guide:
http://groups.google.com/group/google-summer-of-code-announce/web/guide-to-the-gsoc-web-app-for-mentors-and-organization-administrators

If you are a mentor and are communicating with potential students, send
them the URLs above for student signup and the student guide; work with
them if they ask for advice on what to say in the application.  They can
resubmit up to 20 times if they want to correct it.

Deadline is March 31st.






From noah.yan at gmail.com  Thu Mar 27 20:17:48 2008
From: noah.yan at gmail.com (Yonghong Yan)
Date: Thu, 27 Mar 2008 20:17:48 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: About DFBSD.64
In-Reply-To: <47EB0B5B.5020802@gmail.com>
Message-ID: <59521b110803272015y1cc8cc39uc93f154ed36e0505@mail.gmail.com>

thanks for your interest.

I owe to everybody for any update or work in the past four months. so
many things happen in my work and my family (they are all good:) and
keep me extremely busy. But i am not leaving and will be back on this
soon.

the latest sources are in http://repo.or.cz/w/dragonfly/port-amd64.git
, I did have a compiled kernel long time before, but I have to break
it to work on the pmap. you can pick up from there. TGEN will help you
a lot, also keep me posted too, if you like.

Noah

On Wed, Mar 26, 2008 at 9:50 PM, Sdavtaker <sdavtaker at gmail.com> wrote:
> Hello,
>  Im applying to GSoC to work in the x64 version of DFBSD with TGEN, i
>  found some work already done in the repository and some mails in the
>  archive from you.
>  I was wondering if you already had a working compiled kernel in AMD64
>  machine and what was not working yet to continue that work.
>  Thanks for any info.
>  Sdav
>




From dillon at apollo.backplane.com  Sat Mar 29 13:27:43 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Sat, 29 Mar 2008 13:27:43 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 29-Mar-2008
Message-ID: <200803292022.m2TKMLGe004942@apollo.backplane.com>

    Good progress continues to be made.  HAMMER survived acting as my
    LAN backup machine (in full historical mode) for almost a week before
    it hit an assertion.  I've fixed that issue and believe that the core
    filesystem implementation code is now 'very stable'.

    Note that the recent commit will result in many more 'hammer_lock_ex:'
    messages on the console then you may have previously observed.  This is
    due to the way object id's are allocated in the face of parallel 
    modifications to the filesystem, resulting in too much locality of
    reference in the B-Tree.  I do intend to improve it.

    I am still working on the two major items needed before HAMMER can be
    declared operational, those being the filesystem full handling and the
    undo/recovery-on-mount code.  These are the last 'hard' bits left in
    the design.

    With exception to filling up the filesystem, which *will* create a mess,
    and noting that no crash recovery code exists yet (so you have to newfs
    it if you crash), I'd appreciate it if interested parties could test
    the other functions of the filesystem, in particular the pruning and
    reblocking functions (man hammer), and the historical access functions.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From dillon at apollo.backplane.com  Sun Mar 30 15:11:03 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Sun, 30 Mar 2008 15:11:03 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Need ideas on how to solve an st_ino/st_dev test issue for HAMMER.
Message-ID: <200803302207.m2UM7BCp016402@apollo.backplane.com>

    Here's the problem, given historical access softlinks as shown below:

test30# ls -lda cra*
drwxr-xr-x  1 root  wheel  Mar 29 13:04 crater
lrwxr-xr-x  1 root  wheel  Mar 29 18:57 crater.20080329 -> crater@@0x47eef383
lrwxr-xr-x  1 root  wheel  Mar 30 01:24 crater.20080330 -> crater@@0x47ef4e29
-rw-r--r--  2 root  wheel  Mar 30 01:24 crater.log

    The problem is that if I do this:

    diff -r crater.20080329/var/log crater.20080330/var/log

    Diff just returns without actually diffing anything.  The reason is
    because diff checks st_ino and st_dev and believes the directories/files
    to be identical because they match.

    I considered munging the inode number for historical accesses, but
    that would seriously break NFS exports which try to access historical
    files and directories.  Right now NFS *is* able to distinguish between
    the two because NFS handles are 128-bit-wide entities, so I can encode
    the as-of transaction id as part of the filehandle.  But userland
    programs only have access to a 64-bit-wide inode so userland still
    believes the files to be identical.

    st_dev is only 32 bits, carefully munging it is an option if we
    could figure out a way to do it, but I'd rather not.

    I am considering using st_gen but then we'd have to patch third
    party software to test st_gen along with everything else.  This may
    be the only workable solution, though, and only a few programs would
    need to be patched.  st_gen is only 32 bits but it would solve the
    problem as we would be able to use all 32 bits.

    If anyone has any bright ideas, including 'leave it alone', I'm all
    ears.

						-Matt





From justin at shiningsilence.com  Mon Mar 31 10:40:42 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Mon, 31 Mar 2008 10:40:42 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: SoC student applications due by 5PM PDT tomorrow
In-Reply-To: <1942.192.168.0.242.1206930479.squirrel@www.shiningsilence.com>
Message-ID: <11892.67.108.184.175.1206984967.squirrel@www.shiningsilence.com>

On Sun, March 30, 2008 10:27 pm, Justin C. Sherrill wrote:
> SoC students:
>
> If you have an application to submit for DragonFly/Summer of Code, please
> do so by 17:00 Pacific time on the 31st - that's tomorrow, at least for
> me.

The deadline for student proposals has been extended to April 7th; all
other dates move forward one week to acommodate.

This is a good time to update existing applications or submit new ones. 
Talk to your (potential) mentors if you are curious.






From nthery at gmail.com  Mon Mar 31 11:29:49 2008
From: nthery at gmail.com (Nicolas Thery)
Date: Mon, 31 Mar 2008 11:29:49 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
Message-ID: <64fc43b0803311126na7d0b27obaa9d35bac6d32ee@mail.gmail.com>

Hello,

Now that the release is over, I'll try to get rid of zones and migrate
allocations to objcache.

Here is a 1st patch that migrate struct proc.  I'll commit it in a
couple of days if nobody objects.

I'm also implementing a way to monitor objcache statistics.  So far,
I've hacked sth similar to
sysctl vm.zone: stats are returned in one giant string, one line per
cache.  That's simple but ugly and hard to read because there are
quite a few stats per cache.

So I'm thinking about implementing a small tool, ocstat, that extracts
stats from sysctl the way ps(1) does (thru libkvm iirc) and formats it
in various ways.  What do you think?

Cheers,
Nicolas

Index: src2/sys/kern/kern_exit.c
===================================================================
--- src2.orig/sys/kern/kern_exit.c	2008-03-31 08:05:59.139796000 +0200
+++ src2/sys/kern/kern_exit.c	2008-03-31 10:31:39.000000000 +0200
@@ -834,7 +834,7 @@ loop:
 			}

 			vm_waitproc(p);
-			zfree(proc_zone, p);
+			objcache_put(proc_cache, p);
 			nprocs--;
 			return (0);
 		}
Index: src2/sys/kern/kern_proc.c
===================================================================
--- src2.orig/sys/kern/kern_proc.c	2008-03-31 08:05:59.139918000 +0200
+++ src2/sys/kern/kern_proc.c	2008-03-31 10:31:39.000000000 +0200
@@ -84,7 +84,7 @@ u_long pgrphash;
 struct proclist allproc;
 struct proclist zombproc;
 struct spinlock allproc_spin;
-vm_zone_t proc_zone;
+struct objcache* proc_cache;
 vm_zone_t lwp_zone;
 vm_zone_t thread_zone;

@@ -131,7 +131,7 @@ procinit(void)
 	spin_init(&allproc_spin);
 	pidhashtbl = hashinit(maxproc / 4, M_PROC, &pidhash);
 	pgrphashtbl = hashinit(maxproc / 4, M_PROC, &pgrphash);
-	proc_zone = zinit("PROC", sizeof (struct proc), 0, 0, 5);
+	proc_cache = objcache_create_simple(M_PROC, sizeof(struct proc));
 	lwp_zone = zinit("LWP", sizeof (struct lwp), 0, 0, 5);
 	thread_zone = zinit("THREAD", sizeof (struct thread), 0, 0, 5);
 	uihashinit();
Index: src2/sys/sys/proc.h
===================================================================
--- src2.orig/sys/sys/proc.h	2008-03-31 08:05:59.140325000 +0200
+++ src2/sys/sys/proc.h	2008-03-31 10:31:39.000000000 +0200
@@ -473,7 +473,7 @@ struct proc *zpfind (pid_t);	/* Find zom
 struct vm_zone;
 struct globaldata;
 struct lwp_params;
-extern struct vm_zone *proc_zone;
+extern struct objcache *proc_cache;
 extern struct vm_zone *lwp_zone;

 int	enterpgrp (struct proc *p, pid_t pgid, int mksess);
Index: src2/sys/kern/kern_fork.c
===================================================================
--- src2.orig/sys/kern/kern_fork.c	2008-03-31 08:05:59.140042000 +0200
+++ src2/sys/kern/kern_fork.c	2008-03-31 10:31:39.000000000 +0200
@@ -332,7 +332,7 @@ fork1(struct lwp *lp1, int flags, struct
 	}

 	/* Allocate new proc. */
-	p2 = zalloc(proc_zone);
+	p2 = objcache_get(proc_cache, M_WAITOK);
 	bzero(p2, sizeof(*p2));

 	/*




From hsu at dragonflybsd.org  Mon Mar 31 11:44:34 2008
From: hsu at dragonflybsd.org (Jeffrey Hsu)
Date: Mon, 31 Mar 2008 11:44:34 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <64fc43b0803311126na7d0b27obaa9d35bac6d32ee@mail.gmail.com>
Message-ID: <200803311841.m2VIfQAI007579@nlpi001.prodigy.net>

The object cache is not a general-purpose memory allocator.  It's a cache of
pre-initialized objects.  Are the significant portions of the proc structure
that can be restored to initialized state on object puts?  If not, it's best
to just use a general-purpose memory allocator.

								Jeffrey




From corecode at fs.ei.tum.de  Mon Mar 31 12:07:02 2008
From: corecode at fs.ei.tum.de (Simon 'corecode' Schubert)
Date: Mon, 31 Mar 2008 12:07:02 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <200803311841.m2VIfQAI007579@nlpi001.prodigy.net>
Message-ID: <47F1357B.1070302@fs.ei.tum.de>

Jeffrey Hsu wrote:
> The object cache is not a general-purpose memory allocator.  It's a cache of
> pre-initialized objects.  Are the significant portions of the proc structure
> that can be restored to initialized state on object puts?  If not, it's best
> to just use a general-purpose memory allocator.

Why?  What's the loss if we use the object cache to allocate struct procs?

cheers
  simon

Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00006.pgp
Type: application/octet-stream
Size: 252 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080331/a4a24314/attachment-0006.obj>

From nthery at gmail.com  Mon Mar 31 12:17:03 2008
From: nthery at gmail.com (Nicolas Thery)
Date: Mon, 31 Mar 2008 12:17:03 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <nthery@gmail.com>
Message-ID: <64fc43b0803311214u7da6bbb8xaf971de1a80e7258@mail.gmail.com>

2008/3/31, Jeffrey Hsu <hsu at dragonflybsd.org>:
> The object cache is not a general-purpose memory allocator.  It's a cache of
>  pre-initialized objects.  Are the significant portions of the proc structure
>  that can be restored to initialized state on object puts?  If not, it's best
>  to just use a general-purpose memory allocator.

Well, I haven't checked this yet.  I planned to do this in a second
step after getting rid of zones.

I thought that even without  the pre-initialization part, objcache has
the advantage
of pre-allocating set of objects (as zones) and is additionally
mp-safe (contrary to zones and, granted, as malloc()).   The latter
may be interesting as we talk of improving MP support.

Cheers,
Nicolas




From dillon at apollo.backplane.com  Mon Mar 31 12:23:40 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Mon, 31 Mar 2008 12:23:40 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <200803311841.m2VIfQAI007579@nlpi001.prodigy.net>
Message-ID: <200803311921.m2VJLITB027669@apollo.backplane.com>

    I both agree and disagree with Jeff.  I think the only *disadvantage*
    to using objcache for struct proc is that objcache must cache a minimum
    number of free structures to be efficient so the overall kernel memory
    use would be a bit greater verses uses kmalloc().  But I agree with Jeff
    in that objcache's biggest advantage is that you can keep structural state
    intact and struct proc might not be a good candidate (yet).

    What I suggest is that you convert struct proc from zone to kmalloc
    first, and then look into a possible objcache adaptation.  kmalloc
    is not slow.. it's a very fast allocator.  Objcache is probably a tad
    faster but not by much.  Where objcache really wins is in not having
    to completey reinitialize the allocated structures.

    Over the years I've removed (I think) all the dependancies on requiring
    the proc structure to be in stable memory so I believe it can be moved to
    kmalloc/objcache now without any major pain.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From corecode at fs.ei.tum.de  Mon Mar 31 12:37:40 2008
From: corecode at fs.ei.tum.de (Simon 'corecode' Schubert)
Date: Mon, 31 Mar 2008 12:37:40 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: SoC student applications due by 5PM PDT tomorrow
In-Reply-To: <1942.192.168.0.242.1206930479.squirrel@www.shiningsilence.com>
Message-ID: <47F13CDA.6010703@fs.ei.tum.de>

Justin C. Sherrill wrote:
> On Sun, March 30, 2008 10:27 pm, Justin C. Sherrill wrote:
>> SoC students:
>>
>> If you have an application to submit for DragonFly/Summer of Code, please
>> do so by 17:00 Pacific time on the 31st - that's tomorrow, at least for
>> me.
> The deadline for student proposals has been extended to April 7th; all
> other dates move forward one week to acommodate.

This is very good.

Some more ideas for eager students (we want to keep the ratio, right?):

Enhance the FreeBSD/DragonFly sound infrastructure to support surround
sound/multichannel output.

Update sound drivers to support S/PDIF output.

Make the sound infrastructure OSSv4 compatible (there was a SoC at
FreeBSD last year or so)


of course only if it doesn't exist already :)

cheers
  simon


Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00007.pgp
Type: application/octet-stream
Size: 252 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080331/6da61cff/attachment-0006.obj>

From corecode at fs.ei.tum.de  Mon Mar 31 12:41:30 2008
From: corecode at fs.ei.tum.de (Simon 'corecode' Schubert)
Date: Mon, 31 Mar 2008 12:41:30 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <200803311841.m2VIfQAI007579@nlpi001.prodigy.net>
Message-ID: <47F13DE4.10205@fs.ei.tum.de>

Matthew Dillon wrote:
>     What I suggest is that you convert struct proc from zone to kmalloc
>     first, and then look into a possible objcache adaptation.  kmalloc
>     is not slow.. it's a very fast allocator.  Objcache is probably a tad
>     faster but not by much.  Where objcache really wins is in not having
>     to completey reinitialize the allocated structures.

Could we please not move to kmalloc, but instead try to move all fast
path allocations to objcache?  I don't like the idea of allocating
everything with kmalloc.  Caching struct procs is not a bad thing itself.

cheers
  simon


Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00008.pgp
Type: application/octet-stream
Size: 252 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080331/ac328c08/attachment-0006.obj>

From hsu at FreeBSD.org  Mon Mar 31 12:59:05 2008
From: hsu at FreeBSD.org (Jeffrey Hsu)
Date: Mon, 31 Mar 2008 12:59:05 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <47F1357B.1070302@fs.ei.tum.de>
Message-ID: <200803311920.m2VJK5Ln018015@nlpi015.prodigy.net>

The object cache sits on top of a general-purpose memory allocator such
as kmalloc or zalloc and provides pre-initialized object caching functionality.
If you're not going to use the object caching functionality, you can just
call the underlying memory allocator directly.

							Jeffrey




From dillon at apollo.backplane.com  Mon Mar 31 16:17:19 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Mon, 31 Mar 2008 16:17:19 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <200803311841.m2VIfQAI007579@nlpi001.prodigy.net>
Message-ID: <200803312311.m2VNBumd029866@apollo.backplane.com>

:Could we please not move to kmalloc, but instead try to move all fast
:path allocations to objcache?  I don't like the idea of allocating
:everything with kmalloc.  Caching struct procs is not a bad thing itself.=
:
:
:cheers
:  simon

    I will state for the record that I'm fine with either objcache or
    kmalloc.  I agree with Jeff that using objcache for struct proc
    probably isn't necessary but I also agree that it would not hurt either,
    and if the intent is to optimize the initialization of the proc
    structure in the future then moving to objcache now would save us
    from having to do it later.

    So whichever method Nicolas wants to use is fine with me.

						-Matt




From hsu at dragonflybsd.org  Mon Mar 31 19:22:47 2008
From: hsu at dragonflybsd.org (Jeffrey Hsu)
Date: Mon, 31 Mar 2008 19:22:47 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <64fc43b0803311214u7da6bbb8xaf971de1a80e7258@mail.gmail.com>
Message-ID: <200804010218.m312IVUq003624@nlpi043.prodigy.net>

  >> Are there significant portions of the proc structure
  >> that can be restored to initialized state on object puts?

  > I planned to do this in a second step after getting rid of zones.

I'll all in favor of making more use of caching pre-initialized objects, so
if this is your objective, then please go ahead.  It's just that I'd convert
over to the object cache in one step.

  > I thought that even without  the pre-initialization part, objcache has
  > the advantage of pre-allocating set of objects (as zones) and is additionally
  > mp-safe (contrary to zones and, granted, as malloc()).

Well, the zone allocator is MP-safe.  It's not hard to lock up the places that
manipulate the linked-list of free items. Look for uses of the zlock field.

								Jeffrey




From tgen at netphreax.net  Sat Mar  1 12:57:53 2008
From: tgen at netphreax.net (Thomas E. Spanjaard)
Date: Sat, 1 Mar 2008 12:57:53 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: [Fwd: Project Support Open Source: $50 donation to support you      project]
In-Reply-To: <2468.192.168.0.242.1204346451.squirrel@www.shiningsilence.com>
Message-ID: <47C9C1B7.50203@netphreax.net>

Justin C. Sherrill wrote:
The "donation" happens after you place an "acknowledgement" on an open
source project's web page.  I'm putting those words in scare quotes
because I think it's a "payment" for an "advertisement".  The supplied
link has nothing to do with DragonFly, to say the least.

<a href="http://www.2insure4less.com /" title="We support FOSS software
projects.">Online Insurance Quotes</a>
To think our souls are only worth $50...
--
        Thomas E. Spanjaard
        tgen at netphreax.net
Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00000.pgp
Type: application/octet-stream
Size: 186 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080301/0d61e240/attachment-0007.obj>

From c.turner at 199technologies.org  Sat Mar  1 17:52:31 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Sat, 1 Mar 2008 17:52:31 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Misc. ACPI / suspend
Message-ID: <47CA073B.6020106@199technologies.org>

Wondering if anyone more well versed in the ACPI implementation could
comment on the applicability of:
http://lkml.org/lkml/2007/4/6/69

w/r/t the current state of the art in Dfly

(or BSD's in general)

Cheers!

- Chris




From elekktretterr at exemail.com.au  Sun Mar  2 00:41:25 2008
From: elekktretterr at exemail.com.au (Petr Janda)
Date: Sun, 2 Mar 2008 00:41:25 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: CARP question
Message-ID: <200803021934.21669.elekktretterr@exemail.com.au>

So Ive setup CARP on 2 DF-based mailservers. Installation went fine. Box 1 has 
adskew of 0 therefore it is the MASTER. Box 2 has adskew of 254, therefore is 
BACKUP.  If i down the carp0 interface on Box 1, then Box 2 carp interface 
gets promoted to MASTER. Then I up the carp interface on Box 1, logically Box 
2 should become BACKUP again as Box 1 becomes MASTER due to adskew set to 0.

However it doesnt happen. When carp0 interface on Box 1 is upped it becomes a 
BACKUP, not a MASTER even though according to adskew it should be MASTER.

What is the desired behaviour?

Cheers
Petr




From qhwt+dfly at les.ath.cx  Sun Mar  2 02:50:14 2008
From: qhwt+dfly at les.ath.cx (YONETANI Tomokazu)
Date: Sun, 2 Mar 2008 02:50:14 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: panic: assertion: hammer_btree_cmp(cursor->left_bound,	&cursor->node->ondisk->elms[0].leaf.base) <= 0 in btree_split_leaf
In-Reply-To: <200802232204.m1NM4cxd046264@apollo.backplane.com>
Message-ID: <20080302104554.GA22813@les.ath.cx>

Hi.
While trying to find a procedure to reliably reproduce the panic
I reported last time, I caught a different panic (uploaded at
 ~y0netan1/crash/9/ on my leaf account).  I wrote the following shell
script (make sure to edit variables DISKS and MOUNTPT before using this
script or it may trash your system):
  #!/bin/sh -ex
  DISKS="/dev/ad0s1f"
  MOUNTPT=/mnt/HAMMER

  cd /
  newfs_hammer -L TEST $DISKS
  for i in `seq 1 100`; do
	  mount_hammer $DISKS $MOUNTPT
	  /bin/rm -rf $MOUNTPT/??
	  (set +x; for x in `seq 1 10000`; do echo -n > $MOUNTPT/$x; done)
	  umount $MOUNTPT
  done

And the panic is triggered by rm command.
I'll try to see if it's possible to reproduce the last one without
unmounting then mounting the HAMMER fs.

Cheers.




From dillon at apollo.backplane.com  Sun Mar  2 13:25:33 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Sun, 2 Mar 2008 13:25:33 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: panic: assertion: hammer_btree_cmp(cursor->left_bound,	&cursor->node->ondisk->elms[0].leaf.base) <= 0 in btree_split_leaf
In-Reply-To: <200802232204.m1NM4cxd046264@apollo.backplane.com>
Message-ID: <200803022119.m22LJRCY037076@apollo.backplane.com>


:Hi.
:While trying to find a procedure to reliably reproduce the panic
:I reported last time, I caught a different panic (uploaded at
: ~y0netan1/crash/9/ on my leaf account).  I wrote the following shell
:script (make sure to edit variables DISKS and MOUNTPT before using this
:script or it may trash your system):

(from the core)

panic: assertion: node->lock.refs == 0 && node->ondisk == NULL in hammer_flush_buffer_nodes

    Yah, I've seen this failure.  Add a sync or two before the umount and
    tell me if it still occurs.  It's either a node reference leak somewhere
    or it is a race between bufdaemon and umount.  The assertions are really
    strict there precisely to catch those sorts of cases.

    Also note that the code to deal with a full HAMMMER filesystem has not
    been written yet (The failure you are reporting is unrelated to a full
    HAMMER filesystem, though, just mentioning it).

						-Matt





From dillon at apollo.backplane.com  Sun Mar  2 13:29:03 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Sun, 2 Mar 2008 13:29:03 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Misc. ACPI / suspend
In-Reply-To: <47CA073B.6020106@199technologies.org>
Message-ID: <200803022126.m22LQbfI037188@apollo.backplane.com>


:Wondering if anyone more well versed in the ACPI implementation could
:comment on the applicability of:
:
:http://lkml.org/lkml/2007/4/6/69
:
:w/r/t the current state of the art in Dfly
:
:(or BSD's in general)
:
:Cheers!
:
:- Chris

    I really have no idea re: this.  Suspension in general is not well
    supported by any of the BSDs.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From dillon at apollo.backplane.com  Sun Mar  2 13:34:05 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Sun, 2 Mar 2008 13:34:05 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: [Fwd: Project Support Open Source: $50 donation to support you      project]
In-Reply-To: <2468.192.168.0.242.1204346451.squirrel@www.shiningsilence.com>
Message-ID: <200803022131.m22LVOe9037250@apollo.backplane.com>

:..
:source project's web page.  I'm putting those words in scare quotes
:because I think it's a "payment" for an "advertisement".  The supplied
:link has nothing to do with DragonFly, to say the least.
:
:I don't think this is a good idea, obviously, and replied to that effect. 
:However, I wanted to put this on a DragonFly list, in part to show this
:strange thing, and in part because I'm not comfortable making
:administrative decisions on behalf of the Project without being open as
:possible about it.

    It doesn't really cry out to me either.

						-Matt





From wbh at conducive.org  Sun Mar  2 20:36:32 2008
From: wbh at conducive.org (Bill Hacker)
Date: Mon, 03 Mar 2008 04:36:32 +0000
Subject: Misc. ACPI / suspend
In-Reply-To: <47CA073B.6020106@199technologies.org>
Message-ID: <47cb8050$0$855$415eb37d@crater_reader.dragonflybsd.org>

Matthew Dillon wrote:
:Wondering if anyone more well versed in the ACPI implementation could
:comment on the applicability of:
:
:http://lkml.org/lkml/2007/4/6/69
:
:w/r/t the current state of the art in Dfly
:
:(or BSD's in general)
:
:Cheers!
:
:- Chris
    I really have no idea re: this.  Suspension in general is not well
    supported by any of the BSDs.
					-Matt
					Matthew Dillon 
					<dillon at backplane.com>


. . and there seems to be a bit of a 'Catch 22' there in any case.

If the BIOS can alter 'stuff' out of site of the OS it is parking, what 
does the existence of such a 'feature' do to a(ny) security model?

Seems to at least beg creating the option of setting a flag to 
specifically *prevent* suspend-to-disk/hibernation (and/or force a 
reboot on wake-up).

Just because one is paranoid....  etc

Bill





From matthias at dragonflybsd.org  Tue Mar  4 02:30:52 2008
From: matthias at dragonflybsd.org (Matthias Schmidt)
Date: Tue, 4 Mar 2008 02:30:52 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
Message-ID: <20080304102335.GI9833@staatsfeind.org>

Hi,

Google just announced its Summer of Code for 2008:

	http://code.google.com/soc/2008/

I think this would be a great opportunity for DragonFly to participate
as a mentoring organisation.  We could attract new developers and could
get code/work done.  Looking at the SoC results of the other BSDs most
of their projects were a success.  Of course, not all, but a reasonable
percentage.  See [1] and [2].

It is some extra work for us, but IMO the benefits outweigh the extra
work.  And yes, I would volunteer as a mentor.  What do others
(developers) think?  Any more volunteers? :)

Some project ideas that come into my mind.  More ideas are listed in the
wiki:  http://wiki.dragonflybsd.org/index.cgi/ProjectsPage

 * Fix all remaining bugs in dma(8) and implement all missing features
 * Add a driver for newer Intel Wireless cards (I think sephe@ would
   love that :)
 * Bring our ACPI stuff in shape.  Maybe suspend2disk ...

 * [Add your own thoughts here]

Cheers,

	Matthias

PS: I don't want to create a bikeshed here whether you like the SoC or
not :)

[1] http://code.google.com/soc/2007/freebsd/about.html
[2] http://code.google.com/soc/2007/netbsd/about.html




From corecode at fs.ei.tum.de  Tue Mar  4 04:46:14 2008
From: corecode at fs.ei.tum.de (Simon 'corecode' Schubert)
Date: Tue, 4 Mar 2008 04:46:14 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47CD4386.1000704@fs.ei.tum.de>

Matthias Schmidt wrote:
>  * [Add your own thoughts here]

MP lock removal for network stack

and for the system  (first profile, find hot spots, fix hot spots, repeat)

cheers
  simon




From c.turner at 199technologies.org  Tue Mar  4 06:02:20 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Tue, 4 Mar 2008 06:02:20 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47CD551E.1040604@199technologies.org>

Matthias Schmidt wrote:
Some project ideas that come into my mind.  More ideas are listed in the
wiki:  http://wiki.dragonflybsd.org/index.cgi/ProjectsPage
+1 acpi
+1 interrupt routing
+1 SMP / giant removal
+1 pf synchup with openbsd
though there are several others on the page that are good..

need to dig up my wiki login and place appropriately..

also: thinking the ZFS port should be removed from the page - makes 
sense to everyone else? (e.g. fragments effort w/r/t hammer)





From tgen at netphreax.net  Tue Mar  4 06:54:31 2008
From: tgen at netphreax.net (Thomas E. Spanjaard)
Date: Tue, 4 Mar 2008 06:54:31 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47CD615F.8010209@netphreax.net>

Matthias Schmidt wrote:
Google just announced its Summer of Code for 2008:

 * [Add your own thoughts here]
x86-64 port :).
--
        Thomas E. Spanjaard
        tgen at netphreax.net
Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00001.pgp
Type: application/octet-stream
Size: 186 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080304/0d921000/attachment-0007.obj>

From rdivacky at FreeBSD.org  Tue Mar  4 07:07:03 2008
From: rdivacky at FreeBSD.org (Roman Divacky)
Date: Tue, 4 Mar 2008 07:07:03 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <20080304150255.GA8831@freebsd.org>

On Tue, Mar 04, 2008 at 02:49:03PM +0000, Thomas E. Spanjaard wrote:
> Matthias Schmidt wrote:
> >Google just announced its Summer of Code for 2008:
> >
> > * [Add your own thoughts here]
> 
> x86-64 port :).

all those ideas are great and needed etc. but keep in
mind that the projects should be doable by students
who might see dfly for the very first time.

don't overestimate whats possible and select projects
that look realistic

Roman Divacky (former SoC student)




From justin at shiningsilence.com  Tue Mar  4 08:32:56 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Tue, 4 Mar 2008 08:32:56 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <60322.65.106.147.226.1204648095.squirrel@www.shiningsilence.com>

On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
> Hi,
>
> Google just announced its Summer of Code for 2008:
>
> 	http://code.google.com/soc/2008/
>
> I think this would be a great opportunity for DragonFly to participate
> as a mentoring organisation.  We could attract new developers and could
> get code/work done.  Looking at the SoC results of the other BSDs most
> of their projects were a success.  Of course, not all, but a reasonable
> percentage.  See [1] and [2].

We've applied in previous years - Jeff Hsu did one year, and I put
together the application last year.  The hardest thing to find was
students (and they are the thing that helps SoC applications a lot, I
think).

Any student volunteers?  We have mentors.





From rluciani at gmail.com  Tue Mar  4 09:38:29 2008
From: rluciani at gmail.com (Robert Luciani)
Date: Tue, 04 Mar 2008 18:38:29 +0100
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47cd8915$0$854$415eb37d@crater_reader.dragonflybsd.org>

Justin C. Sherrill wrote:
> On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
>> Hi,
>>
>> Google just announced its Summer of Code for 2008:
>>
>> 	http://code.google.com/soc/2008/
>>
>> I think this would be a great opportunity for DragonFly to participate
>> as a mentoring organisation.  We could attract new developers and could
>> get code/work done.  Looking at the SoC results of the other BSDs most
>> of their projects were a success.  Of course, not all, but a reasonable
>> percentage.  See [1] and [2].
> 
> We've applied in previous years - Jeff Hsu did one year, and I put
> together the application last year.  The hardest thing to find was
> students (and they are the thing that helps SoC applications a lot, I
> think).
> 
> Any student volunteers?  We have mentors.
> 

bingo

-- 
Robert Luciani
Chalmers University of Technology, SWE
Department of Computer Science and Engineering
http://www.rluciani.com/public.key




From sdavtaker at gmail.com  Tue Mar  4 09:31:08 2008
From: sdavtaker at gmail.com (=?UTF-8?Q?Sd=C3=A4vtaker?=)
Date: Tue, 4 Mar 2008 09:31:08 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <c37d69f60803040926k206218a3kb8496d0cd18148bd@mail.gmail.com>

If you mentor, i will apply for coder :-)
Still in last year of university. :-)
Sdav

On Tue, Mar 4, 2008 at 1:28 PM, Justin C. Sherrill
<justin at shiningsilence.com> wrote:
> On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
>  > Hi,
>  >
>  > Google just announced its Summer of Code for 2008:
>  >
>  >       http://code.google.com/soc/2008/
>  >
>  > I think this would be a great opportunity for DragonFly to participate
>  > as a mentoring organisation.  We could attract new developers and could
>  > get code/work done.  Looking at the SoC results of the other BSDs most
>  > of their projects were a success.  Of course, not all, but a reasonable
>  > percentage.  See [1] and [2].
>
>  We've applied in previous years - Jeff Hsu did one year, and I put
>  together the application last year.  The hardest thing to find was
>  students (and they are the thing that helps SoC applications a lot, I
>  think).
>
>  Any student volunteers?  We have mentors.
>
>



-- 
Sd?vtaker prays to Rikku goddess for a good treasure.



From rluciani at gmail.com  Tue Mar  4 09:44:02 2008
From: rluciani at gmail.com (Robert Luciani)
Date: Tue, 04 Mar 2008 18:44:02 +0100
Subject: google soc "DragonFly"
Message-ID: <47cd8a63$0$855$415eb37d@crater_reader.dragonflybsd.org>

On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
> > Hi,
> >
> > Google just announced its Summer of Code for 2008:
> >
> > 	http://code.google.com/soc/2008/
> >
> > I think this would be a great opportunity for DragonFly to participate
> > as a mentoring organisation.  We could attract new developers and could
> > get code/work done.  Looking at the SoC results of the other BSDs most
> > of their projects were a success.  Of course, not all, but a reasonable
> > percentage.  See [1] and [2].

We've applied in previous years - Jeff Hsu did one year, and I put
together the application last year.  The hardest thing to find was
students (and they are the thing that helps SoC applications a lot, I
think).

Any student volunteers?  We have mentors.


-- 
Robert Luciani
Chalmers University of Technology, SWE
Department of Computer Science and Engineering
http://www.rluciani.com/public.key




From rluciani at gmail.com  Tue Mar  4 10:04:14 2008
From: rluciani at gmail.com (Robert Luciani)
Date: Tue, 04 Mar 2008 19:04:14 +0100
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47cd8f1f$0$856$415eb37d@crater_reader.dragonflybsd.org>

Robert Luciani wrote:
> Justin C. Sherrill wrote:
>> On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
>>> Hi,
>>>
>>> Google just announced its Summer of Code for 2008:
>>>
>>> 	http://code.google.com/soc/2008/
>>>
>>> I think this would be a great opportunity for DragonFly to participate
>>> as a mentoring organisation.  We could attract new developers and could
>>> get code/work done.  Looking at the SoC results of the other BSDs most
>>> of their projects were a success.  Of course, not all, but a reasonable
>>> percentage.  See [1] and [2].
>> We've applied in previous years - Jeff Hsu did one year, and I put
>> together the application last year.  The hardest thing to find was
>> students (and they are the thing that helps SoC applications a lot, I
>> think).
>>
>> Any student volunteers?  We have mentors.
>>
> 
> bingo
> 
My girlfriend Danwei noted that she would also like partake in the SoC.
She's studying IT here at Chalmers and will join the mailing list shortly.
-- 
Robert Luciani
Chalmers University of Technology, SWE
Department of Computer Science and Engineering
http://www.rluciani.com/public.key




From dillon at apollo.backplane.com  Tue Mar  4 13:08:30 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Tue, 4 Mar 2008 13:08:30 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Going to have to roll 1.12.1
Message-ID: <200803042104.m24L43g1065278@apollo.backplane.com>

    Due to a critical bug in sendmail that can cause it to seg-fault I will
    be rolling 1.12.1 as soon as I get verification that the current
    fix deals with it.

						-Matt





From sdavtaker at gmail.com  Tue Mar  4 17:40:43 2008
From: sdavtaker at gmail.com (=?UTF-8?B?U2TDpHZ0YWtlcg==?=)
Date: Tue, 4 Mar 2008 17:40:43 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: [Fwd: Project Support Open Source: $50 donation to support you  project]
In-Reply-To: <2468.192.168.0.242.1204346451.squirrel@www.shiningsilence.com>
Message-ID: <47CDF8D1.9070100@gmail.com>

50 bucks?
Come on...
You can get a meal a lot more expensive than that just going to a free 
HP conference about linux and you only have to rent your soul 3-5 hours ;-)
Sdav

Matthew Dillon escribi?:
:..
:source project's web page.  I'm putting those words in scare quotes
:because I think it's a "payment" for an "advertisement".  The supplied
:link has nothing to do with DragonFly, to say the least.
:
:I don't think this is a good idea, obviously, and replied to that effect. 
:However, I wanted to put this on a DragonFly list, in part to show this
:strange thing, and in part because I'm not comfortable making
:administrative decisions on behalf of the Project without being open as
:possible about it.

    It doesn't really cry out to me either.

						-Matt

  






From sdavtaker at gmail.com  Tue Mar  4 17:56:35 2008
From: sdavtaker at gmail.com (=?UTF-8?B?U2TDpHZ0YWtlcg==?=)
Date: Tue, 4 Mar 2008 17:56:35 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47CDFCCE.1010106@gmail.com>

A cute idea for for GSOC would be to finish the installer.
We were talking about this in my local BUG, we trying to find out how to 
help on that from here.
There is a few missing features in the CD.

   * FDISK, you need to create the slides from another OS before
     install DFBSD, i think port FDisk from FBSD or any *BSD will solve it.
   * Add to the make release a way to add some custom applications to
     the released liveCD (suppose you want to add nmap or ssh or
     something just to use as test disk in some enviroment).
   * Make the installer a little more customizable, and maybe w/ a GUI
     (I like a lot the console approach, but GUI installer will be a
     popularity move, DFBSD w/X makes a Desktop machine work, actually
     im using it that way and really like it).
I think those projects can be done in a SOC by students (like me) with a 
little guide.
Im a lot more interested in things network related and kernel, but i 
dont mind to work on those things, they need to be done some day.
What u think?
Sdav

Robert Luciani escribi?:
Robert Luciani wrote:
  
Justin C. Sherrill wrote:
    
On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
      
Hi,

Google just announced its Summer of Code for 2008:

	http://code.google.com/soc/2008/

I think this would be a great opportunity for DragonFly to participate
as a mentoring organisation.  We could attract new developers and could
get code/work done.  Looking at the SoC results of the other BSDs most
of their projects were a success.  Of course, not all, but a reasonable
percentage.  See [1] and [2].
        
We've applied in previous years - Jeff Hsu did one year, and I put
together the application last year.  The hardest thing to find was
students (and they are the thing that helps SoC applications a lot, I
think).
Any student volunteers?  We have mentors.

      
bingo

    
My girlfriend Danwei noted that she would also like partake in the SoC.
She's studying IT here at Chalmers and will join the mailing list shortly.
  






From c.turner at 199technologies.org  Tue Mar  4 18:30:53 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Tue, 4 Mar 2008 18:30:53 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47CE04C9.1010902@199technologies.org>

Justin C. Sherrill wrote:
together the application last year.  The hardest thing to find was
students (and they are the thing that helps SoC applications a lot, I
think).
umm.. if google wants to send me back to school, I'll sign up - hows 
that for a fair trade :?






From wbh at conducive.org  Tue Mar  4 23:52:13 2008
From: wbh at conducive.org (Bill Hacker)
Date: Wed, 05 Mar 2008 07:52:13 +0000
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47ce512e$0$855$415eb37d@crater_reader.dragonflybsd.org>

Sd?vtaker wrote:
A cute idea for for GSOC would be to finish the installer.
We were talking about this in my local BUG, we trying to find out how to 
help on that from here.
There is a few missing features in the CD.

   * FDISK, you need to create the slides from another OS before
     install DFBSD, i think port FDisk from FBSD or any *BSD will solve it.
I'd rather see that 'reversed' - i.e. - build a more capable fdisk in 
DFLY with hope that it might be seen worth importing into Free/Net/Open, 
or *at least* be able to do a more flexible job than those now do.

And disklabels as well. Hand in glove.

Here's why:

- At the moment, working with Free, Open, DFLY, and OpenSolaris on the 
same HDD requires a bit of acrobatics.

- There seems to now be greater divergence between/among the *BSD's as 
to being able to read each other's disklabels, mount and use each 
other's 'flavor' of FFS/UFS (not to mention Apple's implementation of 
UFS) than there is among the vast multitude of Linux ext2/3 denizens.

Even to the point where use of a *Linux* fs is the more universal way 
for being able to share mounts among the *BSD's. Think detached drives. 
And no - FAT is not all that practical for several reasons.

- DFLY currently has the most fine-grain ability to create slices and 
partitions. But the others cannot all (any?) read those.

'progress' w/r any of the *BSD's direction as to changes, improvements 
(or not) in their once-common-ancestry fs & disklabels need not be 
sacrificed.

I'm not holding out wish or hope for all players agreeing to return to 
'one sacred way'. Nor 'one new universal fs'. Neither is gonna happen.

But a 'legacy compatible' or least-common-denominator mode would do fine 
- most especially for portable / SAN devices.

So - how about a 'flexible' DFLY fdisk to go along with a 'flexible' 
disklabel that could adapt to whatever it found / was told to create?

JM2CW - but that *might* be a good place to get a cross-*BSD team together.

*snip* (other good stuff)

Bill Hacker




From matthias at dragonflybsd.org  Wed Mar  5 01:02:43 2008
From: matthias at dragonflybsd.org (Matthias Schmidt)
Date: Wed, 5 Mar 2008 01:02:43 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <20080305085747.GJ9833@staatsfeind.org>

Hi,

* Justin C. Sherrill wrote:
> 
> We've applied in previous years - Jeff Hsu did one year, and I put
> together the application last year.  The hardest thing to find was
> students (and they are the thing that helps SoC applications a lot, I
> think).

This is good to know, so we could coordinate that if we have enough
mentors and projects?!?  I put together a small text in the wiki:

http://wiki.dragonflybsd.org/index.cgi/GoogleSoC2008

Feel free to add project or missing stuff.  I'm sure I missed a lot of
things :)

> Any student volunteers?  We have mentors.

According to the discussion we could have some students, who would be a
mentor (besides me)?

Regards

	Matthias





From sdavtaker at gmail.com  Wed Mar  5 06:28:37 2008
From: sdavtaker at gmail.com (=?UTF-8?Q?Sd=C3=A4vtaker?=)
Date: Wed, 5 Mar 2008 06:28:37 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <c37d69f60803050624kd86d3d0w3b44a02d0e5a5391@mail.gmail.com>

<quote>
Write a driver (from scratch) for Intel 3945 wireless device
Mentor: Sepherosa Ziehau
</quote>

Yes yes yes, i want to :-)
Someone else planning to mentor in drivers coding?
Sdav

On Wed, Mar 5, 2008 at 5:57 AM, Matthias Schmidt
<matthias at dragonflybsd.org> wrote:
> Hi,
>
>
>  * Justin C. Sherrill wrote:
>  >
>  > We've applied in previous years - Jeff Hsu did one year, and I put
>  > together the application last year.  The hardest thing to find was
>  > students (and they are the thing that helps SoC applications a lot, I
>  > think).
>
>  This is good to know, so we could coordinate that if we have enough
>  mentors and projects?!?  I put together a small text in the wiki:
>
>  http://wiki.dragonflybsd.org/index.cgi/GoogleSoC2008
>
>  Feel free to add project or missing stuff.  I'm sure I missed a lot of
>  things :)
>
>
>  > Any student volunteers?  We have mentors.
>
>  According to the discussion we could have some students, who would be a
>  mentor (besides me)?
>
>  Regards
>
>         Matthias
>
>



-- 
Sd?vtaker prays to Rikku goddess for a good treasure.



From rluciani at gmail.com  Wed Mar  5 10:56:42 2008
From: rluciani at gmail.com (Robert Luciani)
Date: Wed, 05 Mar 2008 19:56:42 +0100
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47ceecea$0$847$415eb37d@crater_reader.dragonflybsd.org>

Sd?vtaker wrote:
> <quote>
> Write a driver (from scratch) for Intel 3945 wireless device
> Mentor: Sepherosa Ziehau
> </quote>
> 
> Yes yes yes, i want to :-)
> Someone else planning to mentor in drivers coding?
> Sdav
> 
> On Wed, Mar 5, 2008 at 5:57 AM, Matthias Schmidt
> <matthias at dragonflybsd.org> wrote:
>> Hi,
>>
>>
>>  * Justin C. Sherrill wrote:
>>  >
>>  > We've applied in previous years - Jeff Hsu did one year, and I put
>>  > together the application last year.  The hardest thing to find was
>>  > students (and they are the thing that helps SoC applications a lot, I
>>  > think).
>>
>>  This is good to know, so we could coordinate that if we have enough
>>  mentors and projects?!?  I put together a small text in the wiki:
>>
>>  http://wiki.dragonflybsd.org/index.cgi/GoogleSoC2008
>>
>>  Feel free to add project or missing stuff.  I'm sure I missed a lot of
>>  things :)
>>
>>
>>  > Any student volunteers?  We have mentors.
>>
>>  According to the discussion we could have some students, who would be a
>>  mentor (besides me)?
>>
>>  Regards
>>
>>         Matthias
>>
>>
> 
> 
>

IF someone starts to write a 3945 Intel driver,
please keep the newer 4965 in mind too.

-- 
Robert Luciani
Chalmers University of Technology, SWE
Department of Computer Science and Engineering
http://www.rluciani.com/public.key




From joerg at britannica.bec.de  Wed Mar  5 12:01:05 2008
From: joerg at britannica.bec.de (Joerg Sonnenberger)
Date: Wed, 5 Mar 2008 12:01:05 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <20080305195711.GA9981@britannica.bec.de>

On Wed, Mar 05, 2008 at 07:56:42PM +0100, Robert Luciani wrote:
> IF someone starts to write a 3945 Intel driver,
> please keep the newer 4965 in mind too.

NetBSD's wpi works quite well. The hardware is quite different from
4945.

Joerg




From sepherosa at gmail.com  Wed Mar  5 17:48:50 2008
From: sepherosa at gmail.com (Sepherosa Ziehau)
Date: Wed, 5 Mar 2008 17:48:50 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <ea7b9c170803051744u22b09484ofc994f034f11df3b@mail.gmail.com>

On Thu, Mar 6, 2008 at 2:56 AM, Robert Luciani <rluciani at gmail.com> wrote:
>  IF someone starts to write a 3945 Intel driver,

"IF" you know that trying to fix any wired bugs in certain drivers
(e.g. ipw, ral) will require you to read through all of the vendor's
linux code (yes, even including register values and position), i.e.
there is not much difference between writing one from scratch and
porting+fixing_bugs, then you probably will not put "IF" at the start
of your sentence.
If what I said sounded too harsh to you, then I was sorry.

>  please keep the newer 4965 in mind too.

Will do, once generic 11n support is brought in from freebsd.

Best Regards,
sephe

-- 
Live Free or Die




From saw at online.de  Thu Mar  6 05:34:14 2008
From: saw at online.de (Sascha Wildner)
Date: Thu, 06 Mar 2008 14:34:14 +0100
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
Message-ID: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>

Hi all,

this is probably as good a moment as any to come out of the forest with 
this. The patch at

http://leaf.dragonflybsd.org/~swildner/nrelease_gui.diff

adds some code to nrelease/ to build a LiveCD with xorg and so on 
(currently, only the xorg metapackages and fluxbox are added). In order 
to build one, you need a local dir with the pkgsrc binary packages (see 
below).

The following commands should then do the trick:

cd /usr/src
make buildworld
make buildkernel
cd nrelease
patch -p 0 </path/to/the/patch
make PKGSRC_PKG_PATH=/path/to/packages/dir/All realquick gui
The resulting ISO will be in /usr/release/dfly-gui.iso then. It will not 
boot into xorg automatically (although this is easily possible), so you 
need to login as root and do startx.

As of now, this all is kind of basic, more a proof of concept than 
anything else. As our release framework installs packages via chroot, 
the current setup just copies _all_ packages to the chroot before 
installing (kind of a hack).

That said, I'm now primarily interested in opinions/ideas/... about the 
direction this should take. Which packages would we like to see on the 
CD? Should it be a generic setup with the "most common things" 
installed, so a system can be quickly setup by the installer (which will 
cpdup /usr/pkg). Or should it be a more specialized set of tools? Or 
even as many packages as possible (Live DVD?). Etc., etc.

Before continuing on it, I'm really interested in people's input so 
don't hold anything back, please. :)

Sascha

--
http://yoyodyne.ath.cx



From rluciani at gmail.com  Thu Mar  6 06:42:03 2008
From: rluciani at gmail.com (Robert Luciani)
Date: Thu, 06 Mar 2008 15:42:03 +0100
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <47d002bc$0$847$415eb37d@crater_reader.dragonflybsd.org>

Sascha Wildner wrote:
> Hi all,
> 
> this is probably as good a moment as any to come out of the forest with
> this. The patch at
> 
> http://leaf.dragonflybsd.org/~swildner/nrelease_gui.diff
> 
> adds some code to nrelease/ to build a LiveCD with xorg and so on
> (currently, only the xorg metapackages and fluxbox are added). In order
> to build one, you need a local dir with the pkgsrc binary packages (see
> below).
> 
> The following commands should then do the trick:
> 
> cd /usr/src
> make buildworld
> make buildkernel
> cd nrelease
> patch -p 0 </path/to/the/patch
> make PKGSRC_PKG_PATH=/path/to/packages/dir/All realquick gui
> 
> The resulting ISO will be in /usr/release/dfly-gui.iso then. It will not
> boot into xorg automatically (although this is easily possible), so you
> need to login as root and do startx.
> 
> As of now, this all is kind of basic, more a proof of concept than
> anything else. As our release framework installs packages via chroot,
> the current setup just copies _all_ packages to the chroot before
> installing (kind of a hack).
> 
> That said, I'm now primarily interested in opinions/ideas/... about the
> direction this should take. Which packages would we like to see on the
> CD? Should it be a generic setup with the "most common things"
> installed, so a system can be quickly setup by the installer (which will
> cpdup /usr/pkg). Or should it be a more specialized set of tools? Or
> even as many packages as possible (Live DVD?). Etc., etc.
> 
> Before continuing on it, I'm really interested in people's input so
> don't hold anything back, please. :)
> 
> Sascha
> 

I think the main point of such a live-cd would be to test
dragonfly-specific features such as vkernels and more. Mplayer and
OpenOffic work the same on all platforms, so they might not be super
important, while irssi, firefox, networking tools, vim, a few more
shells/terminals might make it easier to for people to quickly gauge if
they can reproduce their current productivity and also what is new.

And if the point of a livecd is to test that kind of stuff, then it
would be nice for it to have a kernel that supports as much as possible
like ALTQ, and drivers.

Also if it has lots and lots of programs (thinking multimedia, java,
etc..) it might be hard to keep the future x64 and x86 live-cds on par.
Gentoo had this problem many years ago and it was very bothersome.

-- 
Robert Luciani
Chalmers University of Technology, SWE
Department of Computer Science and Engineering
http://www.rluciani.com/public.key




From matthias at dragonflybsd.org  Thu Mar  6 07:12:43 2008
From: matthias at dragonflybsd.org (Matthias Schmidt)
Date: Thu, 6 Mar 2008 07:12:43 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <20080306150757.GN9833@staatsfeind.org>

* Sascha Wildner wrote:
> Hi all,
> 
> this is probably as good a moment as any to come out of the forest with this. 
> The patch at
> 
> http://leaf.dragonflybsd.org/~swildner/nrelease_gui.diff
> 
> adds some code to nrelease/ to build a LiveCD with xorg and so on (currently, 
> only the xorg metapackages and fluxbox are added). In order to build one, you 
> need a local dir with the pkgsrc binary packages (see below).

Great work Sascha.

I agree with Robert on most of his stated points.
It would be nice to see some DragonFly specific features on the CD
(although I'm not sure if that will work for all features).  A little
environment where most Unix users feel at home (fluxbox, xfce, firefox,
thunderbird, gvim) should be enough.

Big applications like OO.org, java etc won't work because they are not
available as pkgsrc packages neither is it possible to compile them on
DragonFly.  At least to my knowledge.

Regards

	Matthias




From dillon at apollo.backplane.com  Thu Mar  6 09:31:52 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Thu, 6 Mar 2008 09:31:52 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <200803061728.m26HSR3O091809@apollo.backplane.com>


:Hi all,
:
:this is probably as good a moment as any to come out of the forest with 
:this. The patch at
:
:http://leaf.dragonflybsd.org/~swildner/nrelease_gui.diff
:
:adds some code to nrelease/ to build a LiveCD with xorg and so on 
:(currently, only the xorg metapackages and fluxbox are added). In order 
:to build one, you need a local dir with the pkgsrc binary packages (see 
:below).
:
:The following commands should then do the trick:

    It looks reasonable, though the package copy has to be tightened
    up a bit I think.

:...
:installed, so a system can be quickly setup by the installer (which will 
:cpdup /usr/pkg). Or should it be a more specialized set of tools? Or 
:even as many packages as possible (Live DVD?). Etc., etc.
:
:Before continuing on it, I'm really interested in people's input so 
:don't hold anything back, please. :)
:
:Sascha

    I think this is an excellent time to work up a DVD build and to
    add various 'flavor' extras.  So, e.g.:

	make installer gui gui_extras release dvd

    (All 'dvd' would do is generate a dvd compatible image for burning to
    dvd instead of cd).  I did a quick perusal of what I have on my
    workstation:

    * X
    * Firefox
    * Linux emulation
    * Open Office (linux version)
    * fvwm2
    * xpdf
    * freetype2

    I'd also suggest some image editing tools like gimp, and maybe the KDE
    gui suite.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From justin at shiningsilence.com  Thu Mar  6 09:42:44 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Thu, 6 Mar 2008 09:42:44 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <55427.65.106.147.226.1204825168.squirrel@www.shiningsilence.com>

On Thu, March 6, 2008 8:34 am, Sascha Wildner wrote:

> That said, I'm now primarily interested in opinions/ideas/... about the
> direction this should take. Which packages would we like to see on the
> CD? Should it be a generic setup with the "most common things"
> installed, so a system can be quickly setup by the installer (which will
> cpdup /usr/pkg). Or should it be a more specialized set of tools? Or
> even as many packages as possible (Live DVD?). Etc., etc.

What Robert said is good - whatever's needed to enable DragonFly-specific
features.  Along with that would be some sort of documentation (a README? 
A HTML file on whatever desktop we provide) that points people at the
different DragonFly tools, so they know what to try and how to try it.

There's going to be some percentage of people who try DragonFly who don't
know about vkernels, for instance, but there's our chance to educate them.
 I'm probably volunteering myself, aren't I?





From sdavtaker at gmail.com  Thu Mar  6 09:50:09 2008
From: sdavtaker at gmail.com (=?UTF-8?Q?Sd=C3=A4vtaker?=)
Date: Thu, 6 Mar 2008 09:50:09 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <c37d69f60803060947t110750c0sd6b542ea505d188d@mail.gmail.com>

Cool Sascha :-)
I just posted about this 1 or 2 days ago in the SOC project ideas thread.
Want to mentor this one? ;-)
Damian

On Thu, Mar 6, 2008 at 2:28 PM, Matthew Dillon
<dillon at apollo.backplane.com> wrote:
>
>  :Hi all,
>
> :
>  :this is probably as good a moment as any to come out of the forest with
>  :this. The patch at
>  :
>  :http://leaf.dragonflybsd.org/~swildner/nrelease_gui.diff
>  :
>  :adds some code to nrelease/ to build a LiveCD with xorg and so on
>  :(currently, only the xorg metapackages and fluxbox are added). In order
>  :to build one, you need a local dir with the pkgsrc binary packages (see
>  :below).
>  :
>  :The following commands should then do the trick:
>
>     It looks reasonable, though the package copy has to be tightened
>     up a bit I think.
>
>  :...
>  :installed, so a system can be quickly setup by the installer (which will
>
> :cpdup /usr/pkg). Or should it be a more specialized set of tools? Or
>  :even as many packages as possible (Live DVD?). Etc., etc.
>  :
>  :Before continuing on it, I'm really interested in people's input so
>  :don't hold anything back, please. :)
>  :
>  :Sascha
>
>     I think this is an excellent time to work up a DVD build and to
>     add various 'flavor' extras.  So, e.g.:
>
>         make installer gui gui_extras release dvd
>
>     (All 'dvd' would do is generate a dvd compatible image for burning to
>     dvd instead of cd).  I did a quick perusal of what I have on my
>     workstation:
>
>     * X
>     * Firefox
>     * Linux emulation
>     * Open Office (linux version)
>     * fvwm2
>     * xpdf
>     * freetype2
>
>     I'd also suggest some image editing tools like gimp, and maybe the KDE
>     gui suite.
>
>                                         -Matt
>                                         Matthew Dillon
>                                         <dillon at backplane.com>
>



-- 
Sd?vtaker prays to Rikku goddess for a good treasure.



From saw at online.de  Thu Mar  6 11:54:01 2008
From: saw at online.de (Sascha Wildner)
Date: Thu, 06 Mar 2008 20:54:01 +0100
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <47d04ba2$0$856$415eb37d@crater_reader.dragonflybsd.org>

Matthew Dillon wrote:
    It looks reasonable, though the package copy has to be tightened
    up a bit I think.
It looks as if it would work with mount_null'ing the chroot's 
/tmp/packages. I'll have a better patch ready tomorrow.

Sascha

--
http://yoyodyne.ath.cx



From c.turner at 199technologies.org  Thu Mar  6 19:11:44 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Thu, 6 Mar 2008 19:11:44 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Misc. ACPI / suspend
In-Reply-To: <47CA073B.6020106@199technologies.org>
Message-ID: <47D0B079.3060905@199technologies.org>

Chris Turner wrote:
Wondering if anyone more well versed in the ACPI implementation could
comment on the applicability of:
http://lkml.org/lkml/2007/4/6/69

Doing a little digging, it seems like

. /platform/pc32/i386/i686_mem.c

*might* have the necessary infrastructure to remap the MTRR's per the 
thread referenced,

but:

. /platform/pc32/acpica5/acpi_wakeup.c

doesn't seem to be using this infrastructure..

I'm no where near reaching an understanding of this yet,
but I'm wondering 3 things:
1) does anyone have ACPI (instead of APM)
   sleep / suspend / wakeup working on Dfly ?
2) If so, what machines are being used ?
3) Same question for other BSDs - my understanding is NetBSD is most
   'advanced' w/r/t power managment - but I'm not 100% on this ...
would looove to have a sleeping / resuming / scaling laptop running some 
BSD flavor.. am willing to work towards that end, esp. w/r/t Dfly -
trying to chart a course to figguring this out.

Thanks all,

- Chris




From c.turner at 199technologies.org  Thu Mar  6 19:12:33 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Thu, 6 Mar 2008 19:12:33 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: PCI Bios / Interrupt remapping / etc
Message-ID: <47D0B211.6000002@199technologies.org>

Doing a bit of digging here for my long-standing CBB+SIO interupt and 
buffer problem -

one machine I've tested against was an OpenBSD machine, which didn't
always work to handle the cardbus sio card on a PCI cardbus adapter
-

tuning up some of the device flags in:

http://www.openbsd.org/cgi-bin/man.cgi?query=pcibios&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=html

seems to have alleviated the problem for that os..

I'm just only starting to get up to speed on how DF handles these types 
of things (namely initial PIC / interrupt layout at boot time device 
enumeration), but am wondering if anyone familiar with this area of the 
code has any comments / advice w/r/t the capabilities of the DF bios 
drivers
and the various quirks / fixup mentioned in the link above..

looking to possibly investigate fixing up some of these issues over time.

Thanks

- Chris







From pavalos at theshell.com  Fri Mar  7 01:14:55 2008
From: pavalos at theshell.com (Peter Avalos)
Date: Fri, 7 Mar 2008 01:14:55 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: cam locking
Message-ID: <20080307091024.GC1652@ylem.theshell.com>

So I've been working on locking up cam using lockmgr locks, and here's
what I have so far:

http://www.theshell.com/~pavalos/wip/cam-lock.patch

Most of the work is obtained from FreeBSD.  I've only been running this
on my SCSI machine for a day, but because the patch is so large, I wanted
to make it available for people to review if they have some spare time.

Thanks,
Peter
Attachment:
pgp00002.pgp
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00002.pgp
Type: application/octet-stream
Size: 197 bytes
Desc: "Description: PGP signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080307/9a17ecd8/attachment-0007.obj>

From jspringe at uos.de  Fri Mar  7 03:25:17 2008
From: jspringe at uos.de (Jost Tobias Springenberg)
Date: Fri, 7 Mar 2008 12:25:17 +0100
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <20080307122517.72c9e2b1.jspringe@uos.de>

On Tue, 4 Mar 2008 11:28:15 -0500 (EST)
"Justin C. Sherrill" <justin at shiningsilence.com> wrote:

> On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
> > Hi,
> >
> > Google just announced its Summer of Code for 2008:
> >
> > 	http://code.google.com/soc/2008/
> >
> > I think this would be a great opportunity for DragonFly to participate
> > as a mentoring organisation.  We could attract new developers and could
> > get code/work done.  Looking at the SoC results of the other BSDs most
> > of their projects were a success.  Of course, not all, but a reasonable
> > percentage.  See [1] and [2].
> 
> We've applied in previous years - Jeff Hsu did one year, and I put
> together the application last year.  The hardest thing to find was
> students (and they are the thing that helps SoC applications a lot, I
> think).
> 
> Any student volunteers?  We have mentors.
> 

I read this mailing list for quite a while now and thought about contributing stuff
to DFfly several times, so yes why not take this opportunity if it's there.

-- 
Jost Tobias Springenberg <jspringe at uos.de>




From tgen at netphreax.net  Fri Mar  7 05:17:27 2008
From: tgen at netphreax.net (Thomas E. Spanjaard)
Date: Fri, 7 Mar 2008 05:17:27 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: PCI Bios / Interrupt remapping / etc
In-Reply-To: <47D0B211.6000002@199technologies.org>
Message-ID: <47D13FB4.5080306@netphreax.net>

Chris Turner wrote:
Doing a bit of digging here for my long-standing CBB+SIO interupt and 
buffer problem -

one machine I've tested against was an OpenBSD machine, which didn't
always work to handle the cardbus sio card on a PCI cardbus adapter
-

tuning up some of the device flags in:

http://www.openbsd.org/cgi-bin/man.cgi?query=pcibios&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=html 

seems to have alleviated the problem for that os..

I'm just only starting to get up to speed on how DF handles these types 
of things (namely initial PIC / interrupt layout at boot time device 
enumeration), but am wondering if anyone familiar with this area of the 
code has any comments / advice w/r/t the capabilities of the DF bios 
drivers
and the various quirks / fixup mentioned in the link above..

looking to possibly investigate fixing up some of these issues over time.
Our code that handles issues like this (in cases where you're not using 
APICs, just PICs and PIRs) lives in bus/pci/i386/. Not that running 
without APIC support is all that common on modern machines anymore...
--
        Thomas E. Spanjaard
        tgen at netphreax.net
Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00003.pgp
Type: application/octet-stream
Size: 186 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080307/61366b5c/attachment-0007.obj>

From tgen at netphreax.net  Fri Mar  7 05:16:51 2008
From: tgen at netphreax.net (Thomas E. Spanjaard)
Date: Fri, 7 Mar 2008 05:16:51 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Misc. ACPI / suspend
In-Reply-To: <47CA073B.6020106@199technologies.org>
Message-ID: <47D13F07.9080308@netphreax.net>

Chris Turner wrote:
1) does anyone have ACPI (instead of APM)
   sleep / suspend / wakeup working on Dfly ?
2) If so, what machines are being used ?
3) Same question for other BSDs - my understanding is NetBSD is most
   'advanced' w/r/t power managment - but I'm not 100% on this ...
would looove to have a sleeping / resuming / scaling laptop running some 
BSD flavor.. am willing to work towards that end, esp. w/r/t Dfly -
trying to chart a course to figguring this out.
I have ACPI S3 suspend working like a charm on my IBM ThinkPad R40 
(Pentium M "Banias" 1.3GHz, speedstepping works just fine), running 
NetBSD 3.99.21.
--
        Thomas E. Spanjaard
        tgen at netphreax.net
Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00004.pgp
Type: application/octet-stream
Size: 186 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080307/de3e5104/attachment-0007.obj>

From civilizd at gmail.com  Fri Mar  7 09:06:41 2008
From: civilizd at gmail.com (Vita "CiV" Cizek)
Date: Fri, 7 Mar 2008 09:06:41 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <98d564710803070853q1c73d795m6e6c5cc5049fa099@mail.gmail.com>

>  Any student volunteers?  We have mentors.
>
I am interested too, especially in some kernel-related work.




From justin at shiningsilence.com  Sat Mar  8 12:07:51 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Sat, 8 Mar 2008 12:07:51 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google SoC 2008 - mentors mentors mentors
Message-ID: <51558.192.168.0.252.1205006403.squirrel@www.shiningsilence.com>

If you are willing to mentor for the Google 2008 Summer of Code, please
speak up.  Right now we have: (from our wiki page)

Matthias
Sephe
TGEN
corecode

Part of the application process includes naming people as mentors (student
applications come later), so I want to get as complete a list as possible.

The application is due on the 12th, so if you want to mentor, now's the
time to say so.

Google's SoC FAQ is here: http://code.google.com/soc/2008/faqs.html

Our wiki page is here: http://wiki.dragonflybsd.org/index.cgi/GoogleSoC2008

- much credit to Matthias and others for getting that set up.





From saw at online.de  Sat Mar  8 14:26:07 2008
From: saw at online.de (Sascha Wildner)
Date: Sat, 08 Mar 2008 23:26:07 +0100
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <47d31245$0$848$415eb37d@crater_reader.dragonflybsd.org>

Sascha Wildner wrote:
Hi all,

this is probably as good a moment as any to come out of the forest with 
this. The patch at

http://leaf.dragonflybsd.org/~swildner/nrelease_gui.diff
Ok, I have committed the stuff as an example.

I'm not sure if my free time permits to work on a full-blown live CD 
with X11 and other good things (I already feel my interest wandering off 
in other directions) so if anyone wants to pick up the ball, go ahead. :)

Sascha

--
http://yoyodyne.ath.cx



From qhwt+dfly at les.ath.cx  Tue Mar 11 22:21:31 2008
From: qhwt+dfly at les.ath.cx (YONETANI Tomokazu)
Date: Tue, 11 Mar 2008 22:21:31 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Misc. ACPI / suspend
In-Reply-To: <47CA073B.6020106@199technologies.org>
Message-ID: <20080312051219.GA56091@les.ath.cx>

On Thu, Mar 06, 2008 at 10:03:21PM -0500, Chris Turner wrote:
> 1) does anyone have ACPI (instead of APM)
>    sleep / suspend / wakeup working on Dfly ?
> 2) If so, what machines are being used ?

Dynabook SS3500 (http://www.tlt.co.jp/pc/catalog/ss/02110735/index_j.htm).
It's old and can get very hot(thus frequently turns on the cooling fan)
even when it's running Windows.  I haven't turned it on for about several
months though.

Cheers.




From c.turner at 199technologies.org  Wed Mar 12 04:37:22 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Wed, 12 Mar 2008 04:37:22 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Misc. ACPI / suspend
In-Reply-To: <47CA073B.6020106@199technologies.org>
Message-ID: <47D7BEE3.6010907@199technologies.org>

YONETANI Tomokazu wrote:
On Thu, Mar 06, 2008 at 10:03:21PM -0500, Chris Turner wrote:
1) does anyone have ACPI (instead of APM)
   sleep / suspend / wakeup working on Dfly ?
Cheers.
ditto..

Suppose this should go to docs@ - in any case..

Thinking about setting up a wiki page on the issue so we
can discuss / track what 'good' hardware / drivers / implementations / 
etc are 'out there' - anyone have any suggestions on where this should
go?

http://wiki.dragonflybsd.org/index.cgi/acpi-overview.html

Remains from the handbook conversion - but I'm hesitant to 'over wikify'
this ..



From c.turner at 199technologies.org  Wed Mar 12 15:36:52 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Wed, 12 Mar 2008 15:36:52 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: devel/cscope
Message-ID: <47D85A08.8040103@199technologies.org>

why oh why did I take so long to try this out !!!

just sharing my eureka moment with the list..

- Chris




From dudu at dudu.ro  Wed Mar 12 15:50:14 2008
From: dudu at dudu.ro (Vlad GALU)
Date: Wed, 12 Mar 2008 15:50:14 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: devel/cscope
In-Reply-To: <47D85A08.8040103@199technologies.org>
Message-ID: <ad79ad6b0803121547r2bf67ffep9e40badaac6490f8@mail.gmail.com>

On 3/13/08, Chris Turner <c.turner at 199technologies.org> wrote:
> why oh why did I take so long to try this out !!!
>
>  just sharing my eureka moment with the list..


    Works nice with vim, too!

>
>
>  - Chris
>


-- 
Mahnahmahnah!




From justin at shiningsilence.com  Sun Mar 16 21:06:13 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Sun, 16 Mar 2008 21:06:13 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: binary packages for 1.12 coming in
Message-ID: <1372.192.168.0.252.1205726088.squirrel@www.shiningsilence.com>

The binary build for 1.12 is taking quite a while.  I've started copying
in newly built packages to
pkgbox.dragonflybsd.org/packages/DragonFly-1.12/i386/ - this should be
getting copied out to mirrors over the next while.

There are currently 1283 packages built, which leaves a whole lot to go;
I'll copy new packages in as they complete.





From hasso at estpak.ee  Wed Mar 19 04:31:08 2008
From: hasso at estpak.ee (Hasso Tepper)
Date: Wed, 19 Mar 2008 04:31:08 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Some questions regarding ACPI
Message-ID: <200803191322.46366.hasso@estpak.ee>

I'm working on bringing in some laptop (and especially thinkpad) specific 
ACPI code from FreeBSD into DragonFly. I never touched ACPI stuff before 
and haven't followed it much either, so I have some questions.

* FreeBSD uses ACPI_SERIAL_* heavily. What's the locking situation in 
  DragonFly and why?

* As far as I can see, PCI integration is commented out in DragonFly. 
  What's the state of it and why?

* platform/pc32/acpica5/acpi_toshiba.c - why is it there? I don't think 
  that this is something pc32 specific in it and it should work in pc64 
  laptops as well. Any objections to move it into 
  dev/acpica5/acpi_toshiba/ ?

What's the current status of ACPI in general? AFAICS our acpica is quite 
old - what needs to be done to bring in newer one?


-- 
Hasso




From qhwt+dfly at les.ath.cx  Wed Mar 19 09:24:50 2008
From: qhwt+dfly at les.ath.cx (YONETANI Tomokazu)
Date: Wed, 19 Mar 2008 09:24:50 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Some questions regarding ACPI
In-Reply-To: <200803191322.46366.hasso@estpak.ee>
Message-ID: <20080319161703.GA51509@les.ath.cx>

On Wed, Mar 19, 2008 at 01:22:46PM +0200, Hasso Tepper wrote:
> I'm working on bringing in some laptop (and especially thinkpad) specific 
> ACPI code from FreeBSD into DragonFly. I never touched ACPI stuff before 
> and haven't followed it much either, so I have some questions.

So you want to port some of ACPI support drivers, or to do a fresh port
of ACPI driver from FreeBSD?

> * FreeBSD uses ACPI_SERIAL_* heavily. What's the locking situation in 
>   DragonFly and why?

The current ACPI driver in DragonFly is based on that of FreeBSD as of
end of June, 2004, plus some fixes brought in later (and ACPICA part
has been updated twice since then).  That was before they introduced
the MPSAFE changes into ACPI code, and we use critical section
(crit_{enter,exit}) in most places (and lockmgr lock in a few place).

> * As far as I can see, PCI integration is commented out in DragonFly. 
>   What's the state of it and why?

When we replaced the implementation taken from FreeBSD 4.x with that
brought from FreeBSD 5.x, which added the PCI part, many people
experienced problems until they turned off ACPI completely, or add "pci"
to "debug.acpi.disabled" loader variable.  AFAIK the PCI part in the ACPI
driver almost hasn't been adjusted to work with our version of PCI code.

> * platform/pc32/acpica5/acpi_toshiba.c - why is it there? I don't think 
>   that this is something pc32 specific in it and it should work in pc64 
>   laptops as well. Any objections to move it into 
>   dev/acpica5/acpi_toshiba/ ?

In FreeBSD it used to be sitting at i386/acpica/acpi_toshiba.c and was
later moved into acpi_support.  That change hasn't hit our tree (in fact,
we have no acpi support drivers other than that).  It seems that FreeBSD
has them in dev/acpi_support now, and we for some reason have that
directory in our CVS repository (but containing no files in it).

> What's the current status of ACPI in general? AFAICS our acpica is quite 
> old - what needs to be done to bring in newer one?

Actually, it's not very important to keep just ACPICA latest, but
if you bring the ACPI driver from FreeBSD you need to bring ACPICA code
that matches their version, and it IS important.  And it generally requires
you much work to just update ACPICA part anyway because of how they
change things on every release.

Cheers.




From hasso at estpak.ee  Wed Mar 19 12:29:52 2008
From: hasso at estpak.ee (Hasso Tepper)
Date: Wed, 19 Mar 2008 12:29:52 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Some questions regarding ACPI
In-Reply-To: <200803191322.46366.hasso@estpak.ee>
Message-ID: <200803192115.35396.hasso@estpak.ee>

YONETANI Tomokazu wrote:
> On Wed, Mar 19, 2008 at 01:22:46PM +0200, Hasso Tepper wrote:
> > I'm working on bringing in some laptop (and especially thinkpad)
> > specific ACPI code from FreeBSD into DragonFly. I never touched ACPI
> > stuff before and haven't followed it much either, so I have some
> > questions.
>
> So you want to port some of ACPI support drivers, or to do a fresh port
> of ACPI driver from FreeBSD?

I'm only interested in support drivers and the reason is pure practical - 
newer thinkpads handle less and less hotkeys etc in hardware and require 
support form OS. acpi_ibm and acpi_video are examples of such modules 
which would help a lot of these newer thinkpad users.

acpi_ibm is almost ready to commit (renamed to acpi_thinkpad though).

> > * FreeBSD uses ACPI_SERIAL_* heavily. What's the locking situation in
> >   DragonFly and why?
>
> The current ACPI driver in DragonFly is based on that of FreeBSD as of
> end of June, 2004, plus some fixes brought in later (and ACPICA part
> has been updated twice since then).  That was before they introduced
> the MPSAFE changes into ACPI code, and we use critical section
> (crit_{enter,exit}) in most places (and lockmgr lock in a few place).

Mkay. Will look at more closely.

> > * As far as I can see, PCI integration is commented out in DragonFly.
> >   What's the state of it and why?
>
> When we replaced the implementation taken from FreeBSD 4.x with that
> brought from FreeBSD 5.x, which added the PCI part, many people
> experienced problems until they turned off ACPI completely, or add
> "pci" to "debug.acpi.disabled" loader variable.  AFAIK the PCI part in
> the ACPI driver almost hasn't been adjusted to work with our version of
> PCI code.

I'm afraid that it's beyond my skills, but while looking at acpi_video I 
discovered that it's hard to handle correctly without PCI support.

> > * platform/pc32/acpica5/acpi_toshiba.c - why is it there? I don't
> > think that this is something pc32 specific in it and it should work
> > in pc64 laptops as well. Any objections to move it into
> >   dev/acpica5/acpi_toshiba/ ?
>
> In FreeBSD it used to be sitting at i386/acpica/acpi_toshiba.c and was
> later moved into acpi_support.  That change hasn't hit our tree (in
> fact, we have no acpi support drivers other than that).  It seems that
> FreeBSD has them in dev/acpi_support now, and we for some reason have
> that directory in our CVS repository (but containing no files in it).

I don't see it ;). Makes sense though. So, any objections if I move 
acpi_toshiba into sys/dev/acpi_support and add new acpi_thinkpad there as 
well? 

> > What's the current status of ACPI in general? AFAICS our acpica is
> > quite old - what needs to be done to bring in newer one?
>
> Actually, it's not very important to keep just ACPICA latest, but
> if you bring the ACPI driver from FreeBSD you need to bring ACPICA code
> that matches their version, and it IS important.  And it generally
> requires you much work to just update ACPICA part anyway because of how
> they change things on every release.

Someone else has to do it :).

Thanks for info.


-- 
Hasso




From dillon at apollo.backplane.com  Wed Mar 19 14:01:13 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Wed, 19 Mar 2008 14:01:13 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: panic: assertion: hammer_btree_cmp(cursor->left_bound,	&cursor->node->ondisk->elms[0].leaf.base) <= 0 in btree_split_leaf
In-Reply-To: <200802232204.m1NM4cxd046264@apollo.backplane.com>
Message-ID: <200803192054.m2JKsjwn045137@apollo.backplane.com>


:Hi.
:While trying to find a procedure to reliably reproduce the panic
:I reported last time, I caught a different panic (uploaded at
: ~y0netan1/crash/9/ on my leaf account).  I wrote the following shell
:script (make sure to edit variables DISKS and MOUNTPT before using this
:script or it may trash your system):
:  #!/bin/sh -ex
:  DISKS="/dev/ad0s1f"
:  MOUNTPT=/mnt/HAMMER
:
:  cd /
:  newfs_hammer -L TEST $DISKS
:  for i in `seq 1 100`; do
:..
:And the panic is triggered by rm command.
:I'll try to see if it's possible to reproduce the last one without
:unmounting then mounting the HAMMER fs.
:
:Cheers.

    I believe I have fixed this panic.  hammer_make_separator() had a bug
    in it.

    There is still an issue with the node ref count on umount.

    Please continue to life-test the code.  The reblocking code
    (hammer reblock /mnt) should work now, as should the pruning code
    (e.g. hammer prune /mnt everything).

    The filesystem full case is still not handled and will cause bad things
    to happen.  The undo code isn't finished yet either but it is getting
    there (it's writing stuff out but not setting the sequence number and
    not trying to recover-on-mount yet).

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From qhwt+dfly at les.ath.cx  Wed Mar 19 19:45:40 2008
From: qhwt+dfly at les.ath.cx (YONETANI Tomokazu)
Date: Wed, 19 Mar 2008 19:45:40 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Some questions regarding ACPI
In-Reply-To: <200803191322.46366.hasso@estpak.ee>
Message-ID: <20080320023828.GA53648@les.ath.cx>

On Wed, Mar 19, 2008 at 09:15:35PM +0200, Hasso Tepper wrote:
> YONETANI Tomokazu wrote:
> > On Wed, Mar 19, 2008 at 01:22:46PM +0200, Hasso Tepper wrote:
> > > I'm working on bringing in some laptop (and especially thinkpad)
> > > specific ACPI code from FreeBSD into DragonFly. I never touched ACPI
> > > stuff before and haven't followed it much either, so I have some
> > > questions.
> >
> > So you want to port some of ACPI support drivers, or to do a fresh port
> > of ACPI driver from FreeBSD?
> 
> I'm only interested in support drivers and the reason is pure practical - 
> newer thinkpads handle less and less hotkeys etc in hardware and require 
> support form OS. acpi_ibm and acpi_video are examples of such modules 
> which would help a lot of these newer thinkpad users.
> 
> acpi_ibm is almost ready to commit (renamed to acpi_thinkpad though).

Ah, that's a good news!  My only concern is that ISTR someone mentioned
me that his colleague was thinking about porting ACPI driver itself,
so if you're not the person you may want to collaborate with him/her
so as not to waste the effort or time...

			:

> > In FreeBSD it used to be sitting at i386/acpica/acpi_toshiba.c and was
> > later moved into acpi_support.  That change hasn't hit our tree (in
> > fact, we have no acpi support drivers other than that).  It seems that
> > FreeBSD has them in dev/acpi_support now, and we for some reason have
> > that directory in our CVS repository (but containing no files in it).
> 
> I don't see it ;). Makes sense though. So, any objections if I move 
> acpi_toshiba into sys/dev/acpi_support and add new acpi_thinkpad there as 
> well? 

Sorry, I checked the CVS repository and it doesn't exist actually :)
I don't have any objection to moving it there.

Cheers.




From hasso at estpak.ee  Thu Mar 20 00:14:05 2008
From: hasso at estpak.ee (Hasso Tepper)
Date: Thu, 20 Mar 2008 00:14:05 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Some questions regarding ACPI
In-Reply-To: <200803191322.46366.hasso@estpak.ee>
Message-ID: <200803200904.50875.hasso@estpak.ee>

YONETANI Tomokazu wrote:
> On Wed, Mar 19, 2008 at 09:15:35PM +0200, Hasso Tepper wrote:
> > acpi_ibm is almost ready to commit (renamed to acpi_thinkpad though).
>
> Ah, that's a good news!  My only concern is that ISTR someone mentioned
> me that his colleague was thinking about porting ACPI driver itself,
> so if you're not the person you may want to collaborate with him/her
> so as not to waste the effort or time...

Current state in my repo is attached. It should work on 1.12 as well as it 
doesn't depend yet on moving stuff around.

add-acpi-if-m.patch adds some new stuff to the ACPI code to access 
embedded controllers and match ACPI devices by ID. Not sure how, where 
and whether at all these should be documented.

add-acpi-thinkpad.patch is the driver itself. Note that some stuff doesn't 
work yet on newer thinkpads, I plan to work on it later.

There is still some things to do though. I have to decide what to do with 
led(4) part and with locking. There is also one fatal issue - laptop 
locks up hardly (no panic) while unloading module. Any idea regarding 
this is welcome. And of course test results :).


-- 
Hasso
# HG changeset patch
# User Hasso Tepper <hasso at estpak.ee>
# Date 1205919290 -7200
# Branch HEAD
# Node ID 5a6e2705cc95a340abf973ae5df73ef34e070b79
# Parent  cd529e2e7f849034d5d5a0973cb98af50db0e797
imported patch adding-acpi-if-m.patch

diff --git a/sys/conf/files b/sys/conf/files
--- a/sys/conf/files
+++ b/sys/conf/files
@@ -1387,6 +1387,7 @@ emulation/dragonfly12/dfbsd12_stat.c	non
 ${OSACPI_MI_DIR}/acpi_cmbat.c		optional acpi
 ${OSACPI_MI_DIR}/acpi_cpu.c		optional acpi
 ${OSACPI_MI_DIR}/acpi_ec.c		optional acpi
+${OSACPI_MI_DIR}/acpi_if.m		optional acpi
 ${OSACPI_MI_DIR}/acpi_isab.c		optional acpi isa
 ${OSACPI_MI_DIR}/acpi_lid.c		optional acpi
 ${OSACPI_MI_DIR}/acpi_package.c		optional acpi
diff --git a/sys/conf/kmod.mk b/sys/conf/kmod.mk
--- a/sys/conf/kmod.mk
+++ b/sys/conf/kmod.mk
@@ -275,7 +275,7 @@ MFILES?= kern/bus_if.m kern/device_if.m 
     bus/pccard/card_if.m bus/pccard/power_if.m bus/pci/pci_if.m \
     bus/pci/pcib_if.m \
     bus/ppbus/ppbus_if.m bus/smbus/smbus_if.m bus/usb/usb_if.m \
-    dev/disk/nata/ata_if.m \
+    dev/acpica5/acpi_if.m dev/disk/nata/ata_if.m \
     dev/sound/pcm/ac97_if.m dev/sound/pcm/channel_if.m \
     dev/sound/pcm/feeder_if.m dev/sound/pcm/mixer_if.m \
     libiconv/iconv_converter_if.m dev/agp/agp_if.m opencrypto/crypto_if.m
diff --git a/sys/dev/acpica5/Makefile b/sys/dev/acpica5/Makefile
--- a/sys/dev/acpica5/Makefile
+++ b/sys/dev/acpica5/Makefile
@@ -69,12 +69,14 @@ SRCS+=  acpi_package.c
 # SRCS+=	acpi_pci.c acpi_pcib.c acpi_pcib_acpi.c acpi_pcib_pci.c
 # SRCS+=	acpi_pci_link.c
 SRCS+=  acpi_powerres.c acpi_resource.c acpi_thermal.c
-SRCS+=  acpi_timer.c
+SRCS+=  acpi_timer.c acpi_if.c
 SRCS+=  OsdDebug.c
 SRCS+=  OsdHardware.c OsdInterface.c OsdInterrupt.c OsdMemory.c OsdSchedule.c
 SRCS+=  OsdStream.c OsdSynch.c OsdTable.c OsdEnvironment.c
 SRCS+=  opt_acpi.h opt_bus.h opt_ddb.h
-SRCS+=  device_if.h bus_if.h pci_if.h pcib_if.h isa_if.h
+SRCS+=  device_if.h bus_if.h pci_if.h pcib_if.h isa_if.h acpi_if.h
+MFILES = kern/device_if.m kern/bus_if.m bus/pci/pci_if.m bus/pci/pcib_if.m
+MFILES+= bus/isa/isa_if.m dev/acpica5/acpi_if.m
 
 # Debugging support
 DBSRC=	dbcmds.c dbdisply.c dbexec.c dbfileio.c dbhistry.c
diff --git a/sys/dev/acpica5/acpi.c b/sys/dev/acpica5/acpi.c
--- a/sys/dev/acpica5/acpi.c
+++ b/sys/dev/acpica5/acpi.c
@@ -135,6 +135,7 @@ static int	acpi_release_resource(device_
 			int rid, struct resource *r);
 static uint32_t	acpi_isa_get_logicalid(device_t dev);
 static int	acpi_isa_get_compatid(device_t dev, uint32_t *cids, int count);
+static char	*acpi_device_id_probe(device_t bus, device_t dev, char **ids);
 static int	acpi_isa_pnp_probe(device_t bus, device_t child,
 			struct isa_pnp_id *ids);
 static void	acpi_probe_children(device_t bus);
@@ -189,6 +190,9 @@ static device_method_t acpi_methods[] = 
     DEVMETHOD(bus_deactivate_resource,	bus_generic_deactivate_resource),
     DEVMETHOD(bus_setup_intr,		bus_generic_setup_intr),
     DEVMETHOD(bus_teardown_intr,	bus_generic_teardown_intr),
+
+    /* ACPI bus */
+    DEVMETHOD(acpi_id_probe,		acpi_device_id_probe),
 
     /* ISA emulation */
     DEVMETHOD(isa_pnp_probe,		acpi_isa_pnp_probe),
@@ -1121,6 +1125,24 @@ out:
 	AcpiOsFree(buf.Pointer);
     ACPI_UNLOCK;
     return_VALUE (valid);
+}
+
+static char *
+acpi_device_id_probe(device_t bus, device_t dev, char **ids) 
+{
+    ACPI_HANDLE h;
+    int i;
+
+    h = acpi_get_handle(dev);
+    if (ids == NULL || h == NULL || acpi_get_type(dev) != ACPI_TYPE_DEVICE)
+	return (NULL);
+
+    /* Try to match one of the array of IDs with a HID or CID. */
+    for (i = 0; ids[i] != NULL; i++) {
+	if (acpi_MatchHid(h, ids[i]))
+	    return (ids[i]);
+    }
+    return (NULL);
 }
 
 static int
diff --git a/sys/dev/acpica5/acpi_ec.c b/sys/dev/acpica5/acpi_ec.c
--- a/sys/dev/acpica5/acpi_ec.c
+++ b/sys/dev/acpica5/acpi_ec.c
@@ -327,11 +327,19 @@ static ACPI_STATUS	EcWrite(struct acpi_e
 				UINT8 *Data);
 static int		acpi_ec_probe(device_t dev);
 static int		acpi_ec_attach(device_t dev);
+static int		acpi_ec_read_method(device_t dev, u_int addr,
+				ACPI_INTEGER *val, int width);
+static int		acpi_ec_write_method(device_t dev, u_int addr,
+				ACPI_INTEGER val, int width);
 
 static device_method_t acpi_ec_methods[] = {
     /* Device interface */
     DEVMETHOD(device_probe,	acpi_ec_probe),
     DEVMETHOD(device_attach,	acpi_ec_attach),
+
+    /* Embedded controller interface */
+    DEVMETHOD(acpi_ec_read,     acpi_ec_read_method),
+    DEVMETHOD(acpi_ec_write,    acpi_ec_write_method),
 
     {0, 0}
 };
@@ -620,6 +628,33 @@ error:
 			     sc->ec_data_res);
     /* mtx_destroy(&sc->ec_mtx); */
     return (ENXIO);
+}
+
+/* Methods to allow other devices (e.g., smbat) to read/write EC space. */
+static int
+acpi_ec_read_method(device_t dev, u_int addr, ACPI_INTEGER *val, int width)
+{
+    struct acpi_ec_softc *sc;
+    ACPI_STATUS status;
+
+    sc = device_get_softc(dev);
+    status = EcSpaceHandler(ACPI_READ, addr, width * 8, val, sc, NULL);
+    if (ACPI_FAILURE(status))
+        return (ENXIO);
+    return (0);
+}
+
+static int
+acpi_ec_write_method(device_t dev, u_int addr, ACPI_INTEGER val, int width)
+{
+    struct acpi_ec_softc *sc;
+    ACPI_STATUS status;
+
+    sc = device_get_softc(dev);
+    status = EcSpaceHandler(ACPI_WRITE, addr, width * 8, &val, sc, NULL);
+    if (ACPI_FAILURE(status))
+        return (ENXIO);
+    return (0);
 }
 
 static void
diff --git a/sys/dev/acpica5/acpi_if.m b/sys/dev/acpica5/acpi_if.m
new file mode 100644
--- /dev/null
+++ b/sys/dev/acpica5/acpi_if.m
@@ -0,0 +1,92 @@
+#-
+# Copyright (c) 2004 Nate Lawson
+# All rights reserved.
+#
+# Redistribution and use in source and binary forms, with or without
+# modification, are permitted provided that the following conditions
+# are met:
+# 1. Redistributions of source code must retain the above copyright
+#    notice, this list of conditions and the following disclaimer.
+# 2. Redistributions in binary form must reproduce the above copyright
+#    notice, this list of conditions and the following disclaimer in the
+#    documentation and/or other materials provided with the distribution.
+#
+# THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
+# ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+# ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
+# FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+# DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+# OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+# HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+# LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+# OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+# SUCH DAMAGE.
+#
+# $DragonFly$
+#
+
+#include <sys/bus.h>
+#include <sys/types.h>
+#include "acpi.h"
+
+INTERFACE acpi;
+
+#
+# Default implementation for acpi_id_probe().
+#
+CODE {
+	static char *
+	acpi_generic_id_probe(device_t bus, device_t dev, char **ids)
+	{
+		return (NULL);
+	}
+};
+
+#
+# Check a device for a match in a list of ID strings.  The strings can be
+# EISA PNP IDs or ACPI _HID/_CID values.
+#
+# device_t bus:  parent bus for the device
+#
+# device_t dev:  device being considered
+#
+# char **ids:  array of ID strings to consider
+#
+# Returns:  ID string matched or NULL if no match
+#
+METHOD char * id_probe {
+	device_t	bus;
+	device_t	dev;
+	char		**ids;
+} DEFAULT acpi_generic_id_probe;
+
+#
+# Read embedded controller (EC) address space
+#
+# device_t dev:  EC device
+# u_int addr:  Address to read from in EC space
+# ACPI_INTEGER *val:  Location to store read value
+# int width:  Size of area to read in bytes
+#
+METHOD int ec_read {
+	device_t	dev;
+	u_int		addr;
+	ACPI_INTEGER	*val;
+	int		width;
+};
+
+#
+# Write embedded controller (EC) address space
+#
+# device_t dev:  EC device
+# u_int addr:  Address to write to in EC space
+# ACPI_INTEGER val:  Value to write
+# int width:  Size of value to write in bytes
+#
+METHOD int ec_write {
+	device_t	dev;
+	u_int		addr;
+	ACPI_INTEGER	val;
+	int		width;
+};
diff --git a/sys/dev/acpica5/acpivar.h b/sys/dev/acpica5/acpivar.h
--- a/sys/dev/acpica5/acpivar.h
+++ b/sys/dev/acpica5/acpivar.h
@@ -29,6 +29,7 @@
  * $DragonFly: src/sys/dev/acpica5/acpivar.h,v 1.12 2007/10/23 03:04:48 y0netan1 Exp $
  */
 
+#include "acpi_if.h"
 #include "bus_if.h"
 #include <sys/eventhandler.h>
 #include <sys/sysctl.h>
# HG changeset patch
# User Hasso Tepper <hasso at estpak.ee>
# Date 1205995474 -7200
# Branch HEAD
# Node ID c5db8d4a7c6b25a8576a8d42c5029aaf0e23bfb6
# Parent  5a6e2705cc95a340abf973ae5df73ef34e070b79
[mq]: adding-acpi-thinkpad.patch

diff --git a/sys/dev/acpica5/Makefile b/sys/dev/acpica5/Makefile
--- a/sys/dev/acpica5/Makefile
+++ b/sys/dev/acpica5/Makefile
@@ -117,7 +117,7 @@ acpi_wakecode.h: acpi_wakecode.S
 	${MAKE} -f ${SYSDIR}/${OSACPI_MD_DIR}/Makefile \
 		MAKESRCPATH=${SYSDIR}/${OSACPI_MD_DIR}
 
-SUBDIR=	acpi_toshiba
+SUBDIR=	acpi_toshiba acpi_thinkpad
 all: ${PROG} ${SUBDIR}
 
 # *.o file for each patched *.c file is created under the same directory,
diff --git a/sys/dev/acpica5/acpi_thinkpad/Makefile b/sys/dev/acpica5/acpi_thinkpad/Makefile
new file mode 100644
--- /dev/null
+++ b/sys/dev/acpica5/acpi_thinkpad/Makefile
@@ -0,0 +1,9 @@
+# $DragonFly$
+
+SYSDIR?=${.CURDIR}/../../..
+
+KMOD=		acpi_thinkpad
+CFLAGS+=	-I${.OBJDIR}/.. -I${.CURDIR}/..
+SRCS=		acpi_thinkpad.c opt_acpi.h device_if.h bus_if.h
+
+.include <bsd.kmod.mk>
diff --git a/sys/dev/acpica5/acpi_thinkpad/acpi_thinkpad.c b/sys/dev/acpica5/acpi_thinkpad/acpi_thinkpad.c
new file mode 100644
--- /dev/null
+++ b/sys/dev/acpica5/acpi_thinkpad/acpi_thinkpad.c
@@ -0,0 +1,1046 @@
+/*
+ * Copyright (c) 2004 Takanori Watanabe
+ * Copyright (c) 2005 Markus Brueffer <markus at FreeBSD.org>
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *    notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *    notice, this list of conditions and the following disclaimer in the
+ *    documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+ */
+
+/*
+ * Driver for extra ACPI-controlled gadgets found on IBM and Lenovo ThinkPad
+ * laptops. Inspired by the ibm-acpi and tpb projects which implement these
+ * features on Linux.
+ *
+ *   acpi-ibm: <http://ibm-acpi.sourceforge.net/>
+ *        tpb: <http://www.nongnu.org/tpb/>
+ */
+
+#include "opt_acpi.h"
+#include <sys/param.h>
+#include <sys/kernel.h>
+#include <sys/bus.h>
+#include <machine/cpufunc.h>
+#include <sys/module.h>
+/* #include <dev/led/led.h> */
+#include <sys/sensors.h>
+#include <sys/sysctl.h>
+#include <machine/clock.h>
+
+#include "acpi.h"
+#include "acpivar.h"
+#include "acpi_if.h"
+
+#define _COMPONENT	ACPI_OEM
+ACPI_MODULE_NAME("THINKPAD")
+
+/* Internal methods */
+#define ACPI_THINKPAD_METHOD_EVENTS		1
+#define ACPI_THINKPAD_METHOD_EVENTMASK		2
+#define ACPI_THINKPAD_METHOD_HOTKEY		3
+#define ACPI_THINKPAD_METHOD_BRIGHTNESS		4
+#define ACPI_THINKPAD_METHOD_VOLUME		5
+#define ACPI_THINKPAD_METHOD_MUTE		6
+#define ACPI_THINKPAD_METHOD_THINKLIGHT		7
+#define ACPI_THINKPAD_METHOD_BLUETOOTH		8
+#define ACPI_THINKPAD_METHOD_WLAN		9
+#define ACPI_THINKPAD_METHOD_FANSPEED		10
+#define ACPI_THINKPAD_METHOD_FANLEVEL		11
+#define ACPI_THINKPAD_METHOD_FANSTATUS		12
+#define ACPI_THINKPAD_METHOD_THERMAL		13
+
+/* Hotkeys/Buttons */
+#define THINKPAD_RTC_HOTKEY1			0x64
+#define   THINKPAD_RTC_MASK_HOME		(1 << 0)
+#define   THINKPAD_RTC_MASK_SEARCH		(1 << 1)
+#define   THINKPAD_RTC_MASK_MAIL		(1 << 2)
+#define   THINKPAD_RTC_MASK_WLAN		(1 << 5)
+#define THINKPAD_RTC_HOTKEY2			0x65
+#define   THINKPAD_RTC_MASK_THINKPAD		(1 << 3)
+#define   THINKPAD_RTC_MASK_ZOOM		(1 << 5)
+#define   THINKPAD_RTC_MASK_VIDEO		(1 << 6)
+#define   THINKPAD_RTC_MASK_HIBERNATE		(1 << 7)
+#define THINKPAD_RTC_THINKLIGHT			0x66
+#define   THINKPAD_RTC_MASK_THINKLIGHT		(1 << 4)
+#define THINKPAD_RTC_SCREENEXPAND		0x67
+#define   THINKPAD_RTC_MASK_SCREENEXPAND	(1 << 5)
+#define THINKPAD_RTC_BRIGHTNESS			0x6c
+#define   THINKPAD_RTC_MASK_BRIGHTNESS		(1 << 5)
+#define THINKPAD_RTC_VOLUME			0x6e
+#define   THINKPAD_RTC_MASK_VOLUME		(1 << 7)
+
+/* Embedded Controller registers */
+#define THINKPAD_EC_BRIGHTNESS			0x31
+#define   THINKPAD_EC_MASK_BRI			0x7
+#define THINKPAD_EC_VOLUME			0x30
+#define   THINKPAD_EC_MASK_VOL			0xf
+#define   THINKPAD_EC_MASK_MUTE			(1 << 6)
+#define THINKPAD_EC_FANSTATUS			0x2F
+#define   THINKPAD_EC_MASK_FANLEVEL		0x3f
+#define   THINKPAD_EC_MASK_FANDISENGAGED	(1 << 6)
+#define   THINKPAD_EC_MASK_FANSTATUS		(1 << 7)
+#define THINKPAD_EC_FANSPEED			0x84
+
+/* CMOS Commands */
+#define THINKPAD_CMOS_VOLUME_DOWN		0
+#define THINKPAD_CMOS_VOLUME_UP			1
+#define THINKPAD_CMOS_VOLUME_MUTE		2
+#define THINKPAD_CMOS_BRIGHTNESS_UP		4
+#define THINKPAD_CMOS_BRIGHTNESS_DOWN		5
+
+/* ACPI methods */
+#define THINKPAD_NAME_KEYLIGHT			"KBLT"
+#define THINKPAD_NAME_WLAN_BT_GET		"GBDC"
+#define THINKPAD_NAME_WLAN_BT_SET		"SBDC"
+#define   THINKPAD_NAME_MASK_BT			(1 << 1)
+#define   THINKPAD_NAME_MASK_WLAN		(1 << 2)
+#define THINKPAD_NAME_THERMAL_GET		"TMP7"
+#define THINKPAD_NAME_THERMAL_UPDT		"UPDT"
+
+#define THINKPAD_NAME_EVENTS_STATUS_GET		"DHKC"
+#define THINKPAD_NAME_EVENTS_MASK_GET		"DHKN"
+#define THINKPAD_NAME_EVENTS_STATUS_SET		"MHKC"
+#define THINKPAD_NAME_EVENTS_MASK_SET		"MHKM"
+#define THINKPAD_NAME_EVENTS_GET		"MHKP"
+#define THINKPAD_NAME_EVENTS_AVAILMASK		"MHKA"
+
+#define ABS(x) (((x) < 0)? -(x) : (x))
+
+struct acpi_thinkpad_softc {
+	device_t	dev;
+	ACPI_HANDLE	handle;
+
+	/* Embedded controller */
+	device_t	ec_dev;
+	ACPI_HANDLE	ec_handle;
+
+	/* CMOS */
+	ACPI_HANDLE	cmos_handle;
+
+	/* Fan status */
+	ACPI_HANDLE	fan_handle;
+	int		fan_levels;
+
+	/* Keylight commands and states */
+	ACPI_HANDLE	light_handle;
+	int		light_cmd_on;
+	int		light_cmd_off;
+	int		light_val;
+	int		light_get_supported;
+	int		light_set_supported;
+
+	/* led(4) interface */
+	struct cdev	*led_dev;
+	int		led_busy;
+	int		led_state;
+
+	int		wlan_bt_flags;
+	int		thermal_updt_supported;
+
+	unsigned int	events_availmask;
+	unsigned int	events_initialmask;
+	int		events_mask_supported;
+	int		events_enable;
+
+	/* sensors(9) related */
+	struct ksensordev sensordev;
+	struct ksensor sensors[9];	/* XXX: 8 thermal + fan */
+
+	struct sysctl_ctx_list	*sysctl_ctx;
+	struct sysctl_oid	*sysctl_tree;
+};
+
+static struct {
+	char	*name;
+	int	method;
+	char	*description;
+	int	access;
+} acpi_thinkpad_sysctls[] = {
+	{
+		.name		= "events",
+		.method		= ACPI_THINKPAD_METHOD_EVENTS,
+		.description	= "ACPI events enable",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "eventmask",
+		.method		= ACPI_THINKPAD_METHOD_EVENTMASK,
+		.description	= "ACPI eventmask",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "hotkey",
+		.method		= ACPI_THINKPAD_METHOD_HOTKEY,
+		.description	= "Key Status",
+		.access		= CTLTYPE_INT | CTLFLAG_RD
+	},
+	{
+		.name		= "lcd_brightness",
+		.method		= ACPI_THINKPAD_METHOD_BRIGHTNESS,
+		.description	= "LCD Brightness",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "volume",
+		.method		= ACPI_THINKPAD_METHOD_VOLUME,
+		.description	= "Volume",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "mute",
+		.method		= ACPI_THINKPAD_METHOD_MUTE,
+		.description	= "Mute",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "thinklight",
+		.method		= ACPI_THINKPAD_METHOD_THINKLIGHT,
+		.description	= "Thinklight enable",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "bluetooth",
+		.method		= ACPI_THINKPAD_METHOD_BLUETOOTH,
+		.description	= "Bluetooth enable",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "wlan",
+		.method		= ACPI_THINKPAD_METHOD_WLAN,
+		.description	= "WLAN enable",
+		.access		= CTLTYPE_INT | CTLFLAG_RD
+	},
+	{
+		.name		= "fan_level",
+		.method		= ACPI_THINKPAD_METHOD_FANLEVEL,
+		.description	= "Fan level",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "fan",
+		.method		= ACPI_THINKPAD_METHOD_FANSTATUS,
+		.description	= "Fan enable",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+
+	{ NULL, 0, NULL, 0 }
+};
+
+/* ACPI_SERIAL_DECL(thinkpad, "ACPI THINKPAD extras"); */
+static int	acpi_thinkpad_probe(device_t dev);
+static int	acpi_thinkpad_attach(device_t dev);
+static int	acpi_thinkpad_detach(device_t dev);
+
+#if 0 /* not yet */
+static void	thinkpad_led(void *softc, int onoff);
+static void	thinkpad_led_task(struct acpi_thinkpad_softc *sc,
+		int pending __unused);
+#endif
+
+static int	acpi_thinkpad_sysctl(SYSCTL_HANDLER_ARGS);
+static int	acpi_thinkpad_sysctl_init(struct acpi_thinkpad_softc *sc,
+		int method);
+static int	acpi_thinkpad_sysctl_get(struct acpi_thinkpad_softc *sc,
+		int method);
+static int	acpi_thinkpad_sysctl_set(struct acpi_thinkpad_softc *sc,
+		int method, int val);
+
+static int	acpi_thinkpad_eventmask_set(struct acpi_thinkpad_softc *sc,
+		int val);
+static void	acpi_thinkpad_notify(ACPI_HANDLE h, UINT32 notify,
+		void *context);
+static void	acpi_thinkpad_refresh(void *);
+
+static device_method_t acpi_thinkpad_methods[] = {
+	/* Device interface */
+	DEVMETHOD(device_probe, acpi_thinkpad_probe),
+	DEVMETHOD(device_attach, acpi_thinkpad_attach),
+	DEVMETHOD(device_detach, acpi_thinkpad_detach),
+	{0, 0}
+};
+
+static driver_t	acpi_thinkpad_driver = {
+	"acpi_thinkpad",
+	acpi_thinkpad_methods,
+	sizeof(struct acpi_thinkpad_softc),
+};
+
+static devclass_t acpi_thinkpad_devclass;
+
+DRIVER_MODULE(acpi_thinkpad, acpi, acpi_thinkpad_driver,
+    acpi_thinkpad_devclass, 0, 0);
+MODULE_DEPEND(acpi_thinkpad, acpi, 1, 1, 1);
+static char    *thinkpad_ids[] = {"IBM0068", NULL};
+
+#if 0 /* not yet */
+static void
+thinkpad_led(void *softc, int onoff)
+{
+	struct acpi_thinkpad_softc* sc = (struct acpi_thinkpad_softc*) softc;
+
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+
+	if (sc->led_busy)
+		return;
+
+	sc->led_busy = 1;
+	sc->led_state = onoff;
+
+	AcpiOsExecute(OSL_NOTIFY_HANDLER, (void *)thinkpad_led_task, sc);
+}
+
+static void
+thinkpad_led_task(struct acpi_thinkpad_softc *sc, int pending __unused)
+{
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+
+	/* ACPI_SERIAL_BEGIN(thinkpad); */
+	acpi_thinkpad_sysctl_set(sc, ACPI_THINKPAD_METHOD_THINKLIGHT, sc->led_state);
+	/* ACPI_SERIAL_END(thinkpad); */
+
+	sc->led_busy = 0;
+}
+#endif
+
+static int
+acpi_thinkpad_probe(device_t dev)
+{
+	if (acpi_disabled("thinkpad") ||
+	    ACPI_ID_PROBE(device_get_parent(dev), dev, thinkpad_ids) == NULL ||
+	    device_get_unit(dev) != 0) 
+		return (ENXIO);
+
+	device_set_desc(dev, "IBM/Lenovo ThinkPad ACPI Extras");
+	return (0);
+}
+
+static int
+acpi_thinkpad_attach(device_t dev)
+{
+	struct acpi_thinkpad_softc	*sc;
+	struct acpi_softc	*acpi_sc;
+	devclass_t		ec_devclass;
+	int			i;
+
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t) __func__);
+
+	sc = device_get_softc(dev);
+	sc->dev = dev;
+	sc->handle = acpi_get_handle(dev);
+
+	acpi_sc = acpi_device_get_parent_softc(dev);
+
+	/* Look for the first embedded controller */
+        if (!(ec_devclass = devclass_find ("acpi_ec"))) {
+		if (bootverbose)
+			device_printf(dev, "Couldn't find acpi_ec devclass\n");
+		return (EINVAL);
+	}
+        if (!(sc->ec_dev = devclass_get_device(ec_devclass, 0))) {
+		if (bootverbose)
+			device_printf(dev, "Couldn't find acpi_ec device\n");
+		return (EINVAL);
+	}
+	sc->ec_handle = acpi_get_handle(sc->ec_dev);
+
+	/* ACPI_SERIAL_BEGIN(thinkpad); */
+
+#if 0
+	/* Get the sysctl tree */
+	sc->sysctl_ctx = device_get_sysctl_ctx(dev);
+	sc->sysctl_tree = device_get_sysctl_tree(dev);
+#endif
+	sysctl_ctx_init(sc->sysctl_ctx);
+	sc->sysctl_tree = SYSCTL_ADD_NODE(sc->sysctl_ctx,
+	    SYSCTL_CHILDREN(acpi_sc->acpi_sysctl_tree), OID_AUTO,
+	    "thinkpad", CTLFLAG_RD, 0, "");
+
+	/* Look for event mask and hook up the nodes */
+	sc->events_mask_supported = ACPI_SUCCESS(acpi_GetInteger(sc->handle,
+	    THINKPAD_NAME_EVENTS_MASK_GET, &sc->events_initialmask));
+
+	if (sc->events_mask_supported) {
+		SYSCTL_ADD_INT(sc->sysctl_ctx,
+		    SYSCTL_CHILDREN(sc->sysctl_tree), OID_AUTO,
+		    "initialmask", CTLFLAG_RD,
+		    &sc->events_initialmask, 0, "Initial eventmask");
+
+		/* The availmask is the bitmask of supported events */
+		if (ACPI_FAILURE(acpi_GetInteger(sc->handle,
+		    THINKPAD_NAME_EVENTS_AVAILMASK, &sc->events_availmask)))
+			sc->events_availmask = 0xffffffff;
+
+		SYSCTL_ADD_INT(sc->sysctl_ctx,
+		    SYSCTL_CHILDREN(sc->sysctl_tree), OID_AUTO,
+		    "availmask", CTLFLAG_RD,
+		    &sc->events_availmask, 0, "Mask of supported events");
+	}
+
+	/* Hook up proc nodes */
+	for (i = 0; acpi_thinkpad_sysctls[i].name != NULL; i++) {
+		if (!acpi_thinkpad_sysctl_init(sc,
+		    acpi_thinkpad_sysctls[i].method))
+			continue;
+
+		SYSCTL_ADD_PROC(sc->sysctl_ctx,
+		    SYSCTL_CHILDREN(sc->sysctl_tree), OID_AUTO,
+		    acpi_thinkpad_sysctls[i].name,
+		    acpi_thinkpad_sysctls[i].access,
+		    sc, i, acpi_thinkpad_sysctl, "I",
+		    acpi_thinkpad_sysctls[i].description);
+	}
+
+	/* ACPI_SERIAL_END(thinkpad); */
+
+	/* Handle notifies */
+	AcpiInstallNotifyHandler(sc->handle, ACPI_DEVICE_NOTIFY,
+	    acpi_thinkpad_notify, dev);
+
+#if 0
+	/* Hook up light to led(4) */
+	if (sc->light_set_supported)
+		sc->led_dev = led_create_state(thinkpad_led, sc, "thinklight",
+		    sc->light_val);
+#endif
+	/* Attach sensors(9). */
+	if (sensor_task_register(sc, acpi_thinkpad_refresh, 5)) {
+		device_printf(sc->dev, "unable to register update task\n");
+		return 1;
+	}
+
+	strlcpy(sc->sensordev.xname, device_get_nameunit(sc->dev),
+	    sizeof(sc->sensordev.xname));
+
+	/* XXX: Temp sensors */
+	for (i = 0; i < 8; ++i) {
+		sc->sensors[i].type = SENSOR_TEMP;
+		sensor_attach(&sc->sensordev, &sc->sensors[i]);
+	}
+	
+	/* Fan RPM sensor */
+	sc->sensors[8].type = SENSOR_FANRPM;
+	sensor_attach(&sc->sensordev, &sc->sensors[8]);
+
+	sensordev_install(&sc->sensordev);
+
+	return (0);
+}
+
+static int
+acpi_thinkpad_detach(device_t dev)
+{
+	int i;
+
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t) __func__);
+
+	struct acpi_thinkpad_softc *sc = device_get_softc(dev);
+
+	/* Disable events and restore eventmask */
+	/* ACPI_SERIAL_BEGIN(thinkpad); */
+	acpi_thinkpad_sysctl_set(sc, ACPI_THINKPAD_METHOD_EVENTS, 0);
+	acpi_thinkpad_sysctl_set(sc, ACPI_THINKPAD_METHOD_EVENTMASK,
+	    sc->events_initialmask);
+	/* ACPI_SERIAL_END(thinkpad); */
+
+	AcpiRemoveNotifyHandler(sc->handle, ACPI_DEVICE_NOTIFY,
+	    acpi_thinkpad_notify);
+
+	sysctl_ctx_free(sc->sysctl_ctx);
+
+#if 0
+	if (sc->led_dev != NULL)
+		led_destroy(sc->led_dev);
+#endif
+	sensordev_deinstall(&sc->sensordev);
+	for (i = 0; i < 9; i++)
+		sensor_detach(&sc->sensordev, &sc->sensors[i]);
+	sensor_task_unregister(sc);
+
+	return (0);
+}
+
+static int
+acpi_thinkpad_eventmask_set(struct acpi_thinkpad_softc *sc, int val)
+{
+	int i;
+	ACPI_OBJECT		arg[2];
+	ACPI_OBJECT_LIST	args;
+	ACPI_STATUS		status;
+
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+	/* ACPI_SERIAL_ASSERT(thinkpad); */
+
+	args.Count = 2;
+	args.Pointer = arg;
+	arg[0].Type = ACPI_TYPE_INTEGER;
+	arg[1].Type = ACPI_TYPE_INTEGER;
+
+	for (i = 0; i < 32; ++i) {
+		arg[0].Integer.Value = i+1;
+		arg[1].Integer.Value = (((1 << i) & val) != 0);
+		status = AcpiEvaluateObject(sc->handle,
+		    THINKPAD_NAME_EVENTS_MASK_SET, &args, NULL);
+
+		if (ACPI_FAILURE(status))
+			return (status);
+	}
+
+	return (0);
+}
+
+static int
+acpi_thinkpad_sysctl(SYSCTL_HANDLER_ARGS)
+{
+	struct acpi_thinkpad_softc	*sc;
+	int			arg;
+	int			error = 0;
+	int			function;
+	int			method;
+	
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+
+	sc = (struct acpi_thinkpad_softc *)oidp->oid_arg1;
+	function = oidp->oid_arg2;
+	method = acpi_thinkpad_sysctls[function].method;
+
+	/* ACPI_SERIAL_BEGIN(thinkpad); */
+	arg = acpi_thinkpad_sysctl_get(sc, method);
+	error = sysctl_handle_int(oidp, &arg, 0, req);
+
+	/* Sanity check */
+	if (error != 0 || req->newptr == NULL)
+		goto out;
+
+	/* Update */
+	error = acpi_thinkpad_sysctl_set(sc, method, arg);
+
+out:
+	/* ACPI_SERIAL_END(thinkpad); */
+	return (error);
+}
+
+static int
+acpi_thinkpad_sysctl_get(struct acpi_thinkpad_softc *sc, int method)
+{
+	ACPI_INTEGER	val_ec;
+	int 		val = 0, key;
+
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+	/* ACPI_SERIAL_ASSERT(thinkpad); */
+
+	switch (method) {
+	case ACPI_THINKPAD_METHOD_EVENTS:
+		acpi_GetInteger(sc->handle, THINKPAD_NAME_EVENTS_STATUS_GET,
+		    &val);
+		break;
+
+	case ACPI_THINKPAD_METHOD_EVENTMASK:
+		if (sc->events_mask_supported)
+			acpi_GetInteger(sc->handle,
+			    THINKPAD_NAME_EVENTS_MASK_GET, &val);
+		break;
+
+	case ACPI_THINKPAD_METHOD_HOTKEY:
+		/*
+		 * Construct the hotkey as a bitmask as illustrated below.
+		 * Note that whenever a key was pressed, the respecting bit
+		 * toggles and nothing else changes.
+		 * +--+--+-+-+-+-+-+-+-+-+-+-+
+		 * |11|10|9|8|7|6|5|4|3|2|1|0|
+		 * +--+--+-+-+-+-+-+-+-+-+-+-+
+		 *   |  | | | | | | | | | | |
+		 *   |  | | | | | | | | | | +- Home Button
+		 *   |  | | | | | | | | | +--- Search Button
+		 *   |  | | | | | | | | +----- Mail Button
+		 *   |  | | | | | | | +------- Thinkpad Button
+		 *   |  | | | | | | +--------- Zoom (Fn + Space)
+		 *   |  | | | | | +----------- WLAN Button
+		 *   |  | | | | +------------- Video Button
+		 *   |  | | | +--------------- Hibernate Button
+		 *   |  | | +----------------- Thinklight Button
+		 *   |  | +------------------- Screen expand (Fn + F8)
+		 *   |  +--------------------- Brightness
+		 *   +------------------------ Volume/Mute
+		 */
+		key = rtcin(THINKPAD_RTC_HOTKEY1);
+		val = (THINKPAD_RTC_MASK_HOME | THINKPAD_RTC_MASK_SEARCH |
+		    THINKPAD_RTC_MASK_MAIL | THINKPAD_RTC_MASK_WLAN) & key;
+		key = rtcin(THINKPAD_RTC_HOTKEY2);
+		val |= (THINKPAD_RTC_MASK_THINKPAD | THINKPAD_RTC_MASK_VIDEO |
+		    THINKPAD_RTC_MASK_HIBERNATE) & key;
+		val |= (THINKPAD_RTC_MASK_ZOOM & key) >> 1;
+		key = rtcin(THINKPAD_RTC_THINKLIGHT);
+		val |= (THINKPAD_RTC_MASK_THINKLIGHT & key) << 4;
+		key = rtcin(THINKPAD_RTC_SCREENEXPAND);
+		val |= (THINKPAD_RTC_MASK_THINKLIGHT & key) << 4;
+		key = rtcin(THINKPAD_RTC_BRIGHTNESS);
+		val |= (THINKPAD_RTC_MASK_BRIGHTNESS & key) << 5;
+		key = rtcin(THINKPAD_RTC_VOLUME);
+		val |= (THINKPAD_RTC_MASK_VOLUME & key) << 4;
+		break;
+
+	case ACPI_THINKPAD_METHOD_BRIGHTNESS:
+		ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_BRIGHTNESS, &val_ec, 1);
+		val = val_ec & THINKPAD_EC_MASK_BRI;
+		break;
+
+	case ACPI_THINKPAD_METHOD_VOLUME:
+		ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_VOLUME, &val_ec, 1);
+		val = val_ec & THINKPAD_EC_MASK_VOL;
+		break;
+
+	case ACPI_THINKPAD_METHOD_MUTE:
+		val = ((val_ec & THINKPAD_EC_MASK_MUTE) ==
+		    THINKPAD_EC_MASK_MUTE);
+		break;
+
+	case ACPI_THINKPAD_METHOD_THINKLIGHT:
+		if (sc->light_get_supported)
+			acpi_GetInteger(sc->ec_handle, THINKPAD_NAME_KEYLIGHT,
+			    &val);
+		else
+			val = sc->light_val;
+		break;
+
+	case ACPI_THINKPAD_METHOD_BLUETOOTH:
+		acpi_GetInteger(sc->handle, THINKPAD_NAME_WLAN_BT_GET, &val);
+		sc->wlan_bt_flags = val;
+		val = ((val & THINKPAD_NAME_MASK_BT) != 0);
+		break;
+
+	case ACPI_THINKPAD_METHOD_WLAN:
+		acpi_GetInteger(sc->handle, THINKPAD_NAME_WLAN_BT_GET, &val);
+		sc->wlan_bt_flags = val;
+		val = ((val & THINKPAD_NAME_MASK_WLAN) != 0);
+		break;
+
+	case ACPI_THINKPAD_METHOD_FANSPEED:
+		if (sc->fan_handle) {
+			if (ACPI_FAILURE(acpi_GetInteger(sc->fan_handle,
+			    NULL, &val)))
+				val = -1;
+		}
+		else {
+			ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_FANSPEED,
+			    &val_ec, 2);
+			val = val_ec;
+		}
+		break;
+
+	case ACPI_THINKPAD_METHOD_FANLEVEL:
+		/*
+		 * The THINKPAD_EC_FANSTATUS register works as follows:
+		 * Bit 0-5 indicate the level at which the fan operates. Only
+		 *       values between 0 and 7 have an effect. Everything
+		 *       above 7 is treated the same as level 7
+		 * Bit 6 overrides the fan speed limit if set to 1
+		 * Bit 7 indicates at which mode the fan operates:
+		 *       manual (0) or automatic (1)
+		 */
+		if (!sc->fan_handle) {
+			ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_FANSTATUS,
+			    &val_ec, 1);
+			val = val_ec & THINKPAD_EC_MASK_FANLEVEL;
+		}
+		break;
+
+	case ACPI_THINKPAD_METHOD_FANSTATUS:
+		if (!sc->fan_handle) {
+			ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_FANSTATUS,
+			    &val_ec, 1);
+			val = (val_ec & THINKPAD_EC_MASK_FANSTATUS) ==
+			    THINKPAD_EC_MASK_FANSTATUS;
+		}
+		else
+			val = -1;
+		break;
+	}
+
+	return (val);
+}
+
+static int
+acpi_thinkpad_sysctl_set(struct acpi_thinkpad_softc *sc, int method, int arg)
+{
+	int			val, step, i;
+	ACPI_INTEGER		val_ec;
+	ACPI_OBJECT		Arg;
+	ACPI_OBJECT_LIST	Args;
+	ACPI_STATUS		status;
+
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+	/* ACPI_SERIAL_ASSERT(thinkpad); */
+
+	switch (method) {
+	case ACPI_THINKPAD_METHOD_EVENTS:
+		if (arg < 0 || arg > 1)
+			return (EINVAL);
+
+		status = acpi_SetInteger(sc->handle,
+		    THINKPAD_NAME_EVENTS_STATUS_SET, arg);
+		if (ACPI_FAILURE(status))
+			return (status);
+		if (sc->events_mask_supported)
+			return acpi_thinkpad_eventmask_set(sc,
+			    sc->events_availmask);
+		break;
+
+	case ACPI_THINKPAD_METHOD_EVENTMASK:
+		if (sc->events_mask_supported)
+			return acpi_thinkpad_eventmask_set(sc, arg);
+		break;
+
+	case ACPI_THINKPAD_METHOD_BRIGHTNESS:
+		if (arg < 0 || arg > 7)
+			return (EINVAL);
+
+		if (sc->cmos_handle) {
+			/* Read the current brightness */
+			status = ACPI_EC_READ(sc->ec_dev,
+			    THINKPAD_EC_BRIGHTNESS, &val_ec, 1);
+			if (ACPI_FAILURE(status))
+				return (status);
+			val = val_ec & THINKPAD_EC_MASK_BRI;
+
+			Args.Count = 1;
+			Args.Pointer = &Arg;
+			Arg.Type = ACPI_TYPE_INTEGER;
+			Arg.Integer.Value = (arg > val) ?
+			    THINKPAD_CMOS_BRIGHTNESS_UP :
+			    THINKPAD_CMOS_BRIGHTNESS_DOWN;
+
+			step = (arg > val) ? 1 : -1;
+			for (i = val; i != arg; i += step) {
+				status = AcpiEvaluateObject(sc->cmos_handle,
+				    NULL, &Args, NULL);
+				if (ACPI_FAILURE(status))
+					break;
+			}
+		}
+		return ACPI_EC_WRITE(sc->ec_dev, THINKPAD_EC_BRIGHTNESS,
+		    arg, 1);
+		break;
+
+	case ACPI_THINKPAD_METHOD_VOLUME:
+		if (arg < 0 || arg > 14)
+			return (EINVAL);
+
+		status = ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_VOLUME,
+		    &val_ec, 1);
+		if (ACPI_FAILURE(status))
+			return (status);
+
+		if (sc->cmos_handle) {
+			val = val_ec & THINKPAD_EC_MASK_VOL;
+
+			Args.Count = 1;
+			Args.Pointer = &Arg;
+			Arg.Type = ACPI_TYPE_INTEGER;
+			Arg.Integer.Value = (arg > val) ?
+			    THINKPAD_CMOS_VOLUME_UP : THINKPAD_CMOS_VOLUME_DOWN;
+
+			step = (arg > val) ? 1 : -1;
+			for (i = val; i != arg; i += step) {
+				status = AcpiEvaluateObject(sc->cmos_handle,
+				    NULL, &Args, NULL);
+				if (ACPI_FAILURE(status))
+					break;
+			}
+		}
+		return ACPI_EC_WRITE(sc->ec_dev, THINKPAD_EC_VOLUME, arg +
+		    (val_ec & (~THINKPAD_EC_MASK_VOL)), 1);
+		break;
+
+	case ACPI_THINKPAD_METHOD_MUTE:
+		if (arg < 0 || arg > 1)
+			return (EINVAL);
+
+		status = ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_VOLUME,
+		    &val_ec, 1);
+		if (ACPI_FAILURE(status))
+			return (status);
+
+		if (sc->cmos_handle) {
+			val = val_ec & THINKPAD_EC_MASK_VOL;
+
+			Args.Count = 1;
+			Args.Pointer = &Arg;
+			Arg.Type = ACPI_TYPE_INTEGER;
+			Arg.Integer.Value = THINKPAD_CMOS_VOLUME_MUTE;
+
+			status = AcpiEvaluateObject(sc->cmos_handle, NULL,
+			    &Args, NULL);
+			if (ACPI_FAILURE(status))
+				break;
+		}
+		return ACPI_EC_WRITE(sc->ec_dev, THINKPAD_EC_VOLUME, (arg==1) ?
+		   val_ec | THINKPAD_EC_MASK_MUTE :
+		   val_ec & (~THINKPAD_EC_MASK_MUTE), 1);
+		break;
+
+	case ACPI_THINKPAD_METHOD_THINKLIGHT:
+		if (arg < 0 || arg > 1)
+			return (EINVAL);
+
+		if (sc->light_set_supported) {
+			Args.Count = 1;
+			Args.Pointer = &Arg;
+			Arg.Type = ACPI_TYPE_INTEGER;
+			Arg.Integer.Value = arg ?
+			    sc->light_cmd_on : sc->light_cmd_off;
+
+			status = AcpiEvaluateObject(sc->light_handle, NULL,
+			    &Args, NULL);
+			if (ACPI_SUCCESS(status))
+				sc->light_val = arg;
+			return (status);
+		}
+		break;
+
+	case ACPI_THINKPAD_METHOD_BLUETOOTH:
+		if (arg < 0 || arg > 1)
+			return (EINVAL);
+
+		val = (arg == 1) ? sc->wlan_bt_flags |
+		    THINKPAD_NAME_MASK_BT :
+		    sc->wlan_bt_flags & (~THINKPAD_NAME_MASK_BT);
+		return acpi_SetInteger(sc->handle, THINKPAD_NAME_WLAN_BT_SET,
+		    val);
+		break;
+
+	case ACPI_THINKPAD_METHOD_FANLEVEL:
+		if (arg < 0 || arg > 7)
+			return (EINVAL);
+
+		if (!sc->fan_handle) {
+			/* Read the current fanstatus */
+			ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_FANSTATUS,
+			    &val_ec, 1);
+			val = val_ec & (~THINKPAD_EC_MASK_FANLEVEL);
+
+			return ACPI_EC_WRITE(sc->ec_dev, THINKPAD_EC_FANSTATUS,
+			    val | arg, 1);
+		}
+		break;
+
+	case ACPI_THINKPAD_METHOD_FANSTATUS:
+		if (arg < 0 || arg > 1)
+			return (EINVAL);
+
+		if (!sc->fan_handle) {
+			/* Read the current fanstatus */
+			ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_FANSTATUS,
+			    &val_ec, 1);
+
+			return ACPI_EC_WRITE(sc->ec_dev, THINKPAD_EC_FANSTATUS,
+			    (arg == 1) ? (val_ec | THINKPAD_EC_MASK_FANSTATUS) :
+			    (val_ec & (~THINKPAD_EC_MASK_FANSTATUS)), 1);
+		}
+		break;
+	}
+
+	return (0);
+}
+
+static int
+acpi_thinkpad_sysctl_init(struct acpi_thinkpad_softc *sc, int method)
+{
+	int 			dummy;
+	ACPI_OBJECT_TYPE 	cmos_t;
+	ACPI_HANDLE		ledb_handle;
+
+	switch (method) {
+	case ACPI_THINKPAD_METHOD_EVENTS:
+		/* Events are disabled by default */
+		return (TRUE);
+
+	case ACPI_THINKPAD_METHOD_EVENTMASK:
+		return (sc->events_mask_supported);
+
+	case ACPI_THINKPAD_METHOD_HOTKEY:
+	case ACPI_THINKPAD_METHOD_BRIGHTNESS:
+	case ACPI_THINKPAD_METHOD_VOLUME:
+	case ACPI_THINKPAD_METHOD_MUTE:
+		/* EC is required here, which was already checked before */
+		return (TRUE);
+
+	case ACPI_THINKPAD_METHOD_THINKLIGHT:
+		sc->cmos_handle = NULL;
+		sc->light_get_supported = ACPI_SUCCESS(acpi_GetInteger(
+		    sc->ec_handle, THINKPAD_NAME_KEYLIGHT, &sc->light_val));
+
+		if ((ACPI_SUCCESS(AcpiGetHandle(sc->handle, "\\UCMS",
+		    &sc->light_handle)) ||
+		    ACPI_SUCCESS(AcpiGetHandle(sc->handle, "\\CMOS",
+		    &sc->light_handle)) ||
+		    ACPI_SUCCESS(AcpiGetHandle(sc->handle, "\\CMS",
+		    &sc->light_handle))) &&
+		    ACPI_SUCCESS(AcpiGetType(sc->light_handle, &cmos_t)) &&
+		    cmos_t == ACPI_TYPE_METHOD) {
+			sc->light_cmd_on = 0x0c;
+			sc->light_cmd_off = 0x0d;
+			sc->cmos_handle = sc->light_handle;
+		}
+		else if (ACPI_SUCCESS(AcpiGetHandle(sc->handle, "\\LGHT",
+		    &sc->light_handle))) {
+			sc->light_cmd_on = 1;
+			sc->light_cmd_off = 0;
+		}
+		else
+			sc->light_handle = NULL;
+
+		sc->light_set_supported = (sc->light_handle &&
+		    ACPI_FAILURE(AcpiGetHandle(sc->ec_handle, "LEDB",
+		    &ledb_handle)));
+
+		if (sc->light_get_supported)
+			return (TRUE);
+
+		if (sc->light_set_supported) {
+			sc->light_val = 0;
+			return (TRUE);
+		}
+
+		return (FALSE);
+
+	case ACPI_THINKPAD_METHOD_BLUETOOTH:
+	case ACPI_THINKPAD_METHOD_WLAN:
+		if (ACPI_SUCCESS(acpi_GetInteger(sc->handle,
+		    THINKPAD_NAME_WLAN_BT_GET, &dummy)))
+			return (TRUE);
+		return (FALSE);
+
+	case ACPI_THINKPAD_METHOD_FANSPEED:
+		/* 
+		 * Some models report the fan speed in levels from 0-7
+		 * Newer models report it contiguously
+		 */
+		sc->fan_levels = (ACPI_SUCCESS(AcpiGetHandle(sc->handle, "GFAN",
+		    &sc->fan_handle)) ||
+		    ACPI_SUCCESS(AcpiGetHandle(sc->handle, "\\FSPD",
+		    &sc->fan_handle)));
+		return (TRUE);
+
+	case ACPI_THINKPAD_METHOD_FANLEVEL:
+	case ACPI_THINKPAD_METHOD_FANSTATUS:
+		/* 
+		 * Fan status is only supported on those models,
+		 * which report fan RPM contiguously, not in levels
+		 */
+		if (sc->fan_levels)
+			return (FALSE);
+		return (TRUE);
+
+	case ACPI_THINKPAD_METHOD_THERMAL:
+		if (ACPI_SUCCESS(acpi_GetInteger(sc->ec_handle,
+		    THINKPAD_NAME_THERMAL_GET, &dummy))) {
+			sc->thermal_updt_supported =
+			    ACPI_SUCCESS(acpi_GetInteger(sc->ec_handle,
+			    THINKPAD_NAME_THERMAL_UPDT, &dummy));
+			return (TRUE);
+		}
+		return (FALSE);
+	}
+	return (FALSE);
+}
+
+static void
+acpi_thinkpad_notify(ACPI_HANDLE h, UINT32 notify, void *context)
+{
+	int		event, arg, type;
+	device_t	dev = context;
+	struct acpi_thinkpad_softc *sc = device_get_softc(dev);
+
+	ACPI_FUNCTION_TRACE_U32((char *)(uintptr_t)__func__, notify);
+
+	if (notify != 0x80)
+		device_printf(dev, "Unknown notify\n");
+
+	for (;;) {
+		acpi_GetInteger(acpi_get_handle(dev), THINKPAD_NAME_EVENTS_GET,
+		    &event);
+
+		if (event == 0)
+			break;
+
+		type = (event >> 12) & 0xf;
+		arg = event & 0xfff;
+		switch (type) {
+		case 1:
+			if (!(sc->events_availmask & (1 << (arg - 1)))) {
+				device_printf(dev, "Unknown key %d\n", arg);
+				break;
+			}
+
+			/* Notify devd(8) */
+			device_printf(dev, "THINKPAD event: %u\n",
+			    (arg & 0xff));
+			acpi_UserNotify("THINKPAD", h, (arg & 0xff));
+			break;
+		default:
+			break;
+		}
+	}
+}
+
+static void
+acpi_thinkpad_refresh(void *arg)
+{
+	struct acpi_thinkpad_softc *sc = (struct acpi_thinkpad_softc *)arg;
+	char temp_cmd[] = "TMP0";
+	int data, i;
+	ACPI_INTEGER speed;
+
+	for (i = 0; i < 8; i++) {
+		temp_cmd[3] = '0' + i;
+		
+                /*
+                 * The TMPx methods seem to return +/- 128 or 0
+                 * when the respecting sensor is not available
+                 */
+		sc->sensors[i].flags &= ~SENSOR_FINVALID;
+                if (ACPI_FAILURE(acpi_GetInteger(sc->ec_handle, temp_cmd,
+                    &data)) || ABS(data) == 128 || data == 0) {
+			sc->sensors[i].flags |= SENSOR_FINVALID;
+                        data = 0;
+		}
+                else if (sc->thermal_updt_supported) {
+                        /* XXX: Temperature is reported in tenth of Kelvin */
+                        data = (data - 2732 + 5) / 10;
+		}
+		sc->sensors[i].value = data * 1000000 + 273150000;
+        }
+	
+	sc->sensors[8].flags &= ~SENSOR_FINVALID;
+	if (sc->fan_handle) {
+		if (ACPI_FAILURE(acpi_GetInteger(sc->fan_handle,
+		    NULL, &data)))
+			sc->sensors[8].flags |= SENSOR_FINVALID;
+                        data = -1;
+        }
+        else {
+                ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_FANSPEED, &speed, 2);
+                data = speed;
+        }
+
+	sc->sensors[8].value = data;
+}
diff --git a/sys/platform/pc32/conf/files b/sys/platform/pc32/conf/files
--- a/sys/platform/pc32/conf/files
+++ b/sys/platform/pc32/conf/files
@@ -72,6 +72,7 @@ dev/serial/dgb/dgm.c			optional	dgm
 ${OSACPI_MD_DIR}/acpi_machdep.c		optional        acpi
 ${OSACPI_MD_DIR}/acpi_wakeup.c		optional        acpi
 ${OSACPI_MD_DIR}/acpi_toshiba.c		optional        acpi_toshiba acpi
+${ACPICA_DIR}/acpi_thinkpad/acpi_thinkpad.c optional	acpi_thinkpad acpi
 acpi.h					optional	acpi		\
 	dependency	"$S/${ACPICA_DIR}/include/acpi.h"		\
 	compile-with	"cp $S/${ACPICA_DIR}/include/acpi.h ${.OBJDIR}/"	\



From hasso at estpak.ee  Thu Mar 20 03:49:13 2008
From: hasso at estpak.ee (Hasso Tepper)
Date: Thu, 20 Mar 2008 03:49:13 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Some questions regarding ACPI
In-Reply-To: <200803191322.46366.hasso@estpak.ee>
Message-ID: <200803201237.28823.hasso@estpak.ee>

Hasso Tepper wrote:
> There is also one fatal issue -laptop locks up hardly (no panic) while 
> unloading module. Any idea regarding this is welcome.

Nevermind, solved.


-- 
Hasso




From dillon at apollo.backplane.com  Fri Mar 21 19:24:01 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Fri, 21 Mar 2008 19:24:01 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: panic: assertion: hammer_btree_cmp(cursor->left_bound,	&cursor->node->ondisk->elms[0].leaf.base) <= 0 in btree_split_leaf
In-Reply-To: <200802232204.m1NM4cxd046264@apollo.backplane.com>
Message-ID: <200803220212.m2M2CiAY014435@apollo.backplane.com>

:While trying to find a procedure to reliably reproduce the panic
:I reported last time, I caught a different panic (uploaded at
: ~y0netan1/crash/9/ on my leaf account).  I wrote the following shell
:script (make sure to edit variables DISKS and MOUNTPT before using this
:script or it may trash your system):

    Ok, I believe I have fixed the left_bound assertion.  I also believe
    I have fixed the node ref count assertion on umount.

    There is currently one unfixed assertion related to the I/O
    path... sometimes the bp is being improperly disassociated from the
    related HAMMER structure.

    The full-filesystem case is still not being handled so don't test that :-)

					    -Matt





From c.turner at 199technologies.org  Sun Mar 23 09:48:29 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Sun, 23 Mar 2008 09:48:29 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
Message-ID: <47E6870C.4080709@199technologies.org>

I'm finally getting around to doing 1.12 upgrades, and have setup a 
separate machine to do my bulk package builds / upgrades etc,
so as not to disrupt my 'dev server' while things are being
built / tested

However, this seems kind of wasteful - the only purpose of this machine
is to build packages against a specific release..
And since building packages for a particular release generally requires 
only the userland, appropriate headers and correct 'uname' output - so:

it seems like if spoofing uname is configured inside a jail,
the next (or previous..) release can be installed into a jail and
used for building / testing packages without the overhead of a VM or 
maintaining a separate physical host

I did a quick scan of the tree to see what this would take, and, high 
level, it seems like only the following changes would need to be made:

- update struct jail to add a 'osrelease' string
  (implies bumping 'jail api' to 2?)
- update jail(8) to actually pass this information along
- update sys_uname to test ucred for jailed processes, and
  use the struct jail osrelease if appropriate
- similarly update sysctl kern.osrelease to support jail spoofing
  (if possible - didn't get this far in the research yet)
  could be less of a problem for builds, as I think most things use
 uname(1) ... but good to keep the environment consistent I suppose..
I'm still a bit confused as to how 'osrelease' is defined - everything
I'm finding is showing up as extern char[] .. perhaps this is something 
in the build I'm not familiar with?

also,

is the so-called 'stupid hackery' in sys_uname needed still?

Before I start any coding, does this:

- sound like something useful
- sound like the right approach
Thinking this could have wider useful implications e.g. for pkgbox
& so on -  for example setting up automated bulks w/various combinations 
of pkgsrc and releases, etc.

Cheers,

- Chris





From corecode at fs.ei.tum.de  Sun Mar 23 10:06:38 2008
From: corecode at fs.ei.tum.de (Simon 'corecode' Schubert)
Date: Sun, 23 Mar 2008 10:06:38 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <47E68C74.3080808@fs.ei.tum.de>

Chris Turner wrote:
I did a quick scan of the tree to see what this would take, and, high 
level, it seems like only the following changes would need to be made:
brave investigation.  but you could also simply set UNAME_r :)

sweatshorts % uname -r
1.13.0-DEVELOPMENT
sweatshorts % UNAME_r=1.12-RELEASE uname -r
1.12-RELEASE
I think that's good enough :D

cheers
  simon
--
Serve - BSD     +++  RENT this banner advert  +++    ASCII Ribbon   /"\
Work - Mac      +++  space for low ????????? NOW!1  +++      Campaign     \ /
Party Enjoy Relax   |   http://dragonflybsd.org      Against  HTML   \
Dude 2c 2 the max   !   http://golden-apple.biz       Mail + News   / \




From c.turner at 199technologies.org  Sun Mar 23 10:50:13 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Sun, 23 Mar 2008 10:50:13 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <47E69656.8080605@199technologies.org>

Simon 'corecode' Schubert wrote:
brave investigation.  but you could also simply set UNAME_r :)
Doh! Thanks for the tip!

they should change the phrase from RTFM to 'Carefully RTFM' :)

well.. scratch that change then. 1 less patch to write.

- Chris





From c.turner at 199technologies.org  Sun Mar 23 11:15:52 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Sun, 23 Mar 2008 11:15:52 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <47E69C7C.8010109@199technologies.org>

Chris Turner wrote:
Simon 'corecode' Schubert wrote:
brave investigation.  but you could also simply set UNAME_r :)

for the record - if anyone's interested - adding a line e.g.:

ALL_ENV+= UNAME_r=1.12-RELEASE

to mk.conf looks like it -might- work ..

(unless wants to chime in & verify)





From joerg at britannica.bec.de  Sun Mar 23 11:46:53 2008
From: joerg at britannica.bec.de (Joerg Sonnenberger)
Date: Sun, 23 Mar 2008 11:46:53 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <20080323181428.GA2099@britannica.bec.de>

On Sun, Mar 23, 2008 at 01:41:42PM -0400, Chris Turner wrote:
> they should change the phrase from RTFM to 'Carefully RTFM' :)

RTFMAI -- Read The Fine Manual Again, Idiot.

Joerg




From dillon at apollo.backplane.com  Sun Mar 23 20:05:36 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Sun, 23 Mar 2008 20:05:36 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
Message-ID: <200803240257.m2O2voNH038355@apollo.backplane.com>

    Here's an update on the HAMMER work!

    Current status:

    * Passes all standard filesystem stress tests and buildworld will
      run with a HAMMER /usr/obj.  Large histories are able to accumulate
      without effecting performance.

    * Pruning and reblocking code is in and partially tested, but now needs
      more stringent testing.

    * Full historical access appears to be working but needs testing.
      Note that a sync is still needed to flush dirty cached data prior
      to acquiring a timestamp for the 'snapshot' to be set in stone.
      (dirty data cached in-memory has no historical tags and must be
      committed to physical disk before it can be accessed historically).


    Current bugs:

    * There is one known bug in the standard operations code paths
      that results in an assertion in HAMMER's I/O subsystem.

    * There are probably bugs in the reblocking and/or pruning code.  More
      likely in the reblocking code.


    There are two big-ticket and several little-ticket items left.  HAMMER
    will officially go Alpha when the big-ticket items are done, and beta
    when we get a few of the little-ticket items done.

    Big ticket items left:

    * UNDO (crash recovery) code.  Currently it writes out undo records but
      they are not yet sequenced, buffer writes are not yet ordered, and
      there is no mount-time recovery code yet.

      This is the last item needed before HAMMER can go operational.

    * Filesystem full handling.  Currently no space is reserved for dirty
      cached data so it is possible to create/write files and for HAMMER
      to not have sufficient space left on-disk to flush it.


    Little ticket items:

    * Automated reblocking (currently these functions are manually
      initialized via the hammer utility).

    * I/O clustering and preliminary BMAP op when writing out large files.

    * CRC checking (CRC fields are reserved but not entirely generated yet
      and not yet checked at all).

    * Disaster Recovery filesystem scan.

    * Boot support.

    I expect all of these items and more to be handled by the 2.0 release
    in July.

			    Additional HAMMER capabilities
				(no timeline yet)

    * Adding, removing, and resizing a HAMMER filesystem's backing store.

			Ultimate Goals and working towards them
				(no timeline yet)

    Our ultimate goal with HAMMER and DragonFly in general is to support
    fully cache coherent replication in a multi-machine environment.  This
    involves several steps and networking protocols.

    * Replication of synchronization streams based on the UNDO log.  If
      resynchronizing to a target which is too old a B-Tree scan will
      likely be required.

    * Cache coherency protocols for machine-machine coherency for both
      replicated and remote-HAMMER access.

    I have no time frame for these items yet.  It will depend on how quickly
    HAMMER moves to Alpha and Beta status.  I will say, however, now
    that HAMMER's on-disk format has solidified, that I have a very precise
    understanding of the protocols that will be needed to accomplish fully
    cache coherent remote access for both replicated and non-replicated
    (remote mount style) access.

    And, as you know, fully coherent filesystem access across machines is
    going to be the basis for DragonFly's clustering across said machines.

    In summary, things are progressing very well.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From justin at shiningsilence.com  Sun Mar 23 20:10:13 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Sun, 23 Mar 2008 20:10:13 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <53758.192.168.0.252.1206327873.squirrel@www.shiningsilence.com>

On Sun, March 23, 2008 12:36 pm, Chris Turner wrote:

> it seems like if spoofing uname is configured inside a jail,
> the next (or previous..) release can be installed into a jail and
> used for building / testing packages without the overhead of a VM or
> maintaining a separate physical host

If you don't need a jail to spoof uname, as others posted, you can
installworld into a chroot and build everything you want there using
Joerg's spiffy pbulk.  That's what I'm doing on pkgbox now; I can hand you
my somewhat terse notes if you want.  It would be relatively easy to set
up the configuration you're talking about.





From sepherosa at gmail.com  Sun Mar 23 20:18:20 2008
From: sepherosa at gmail.com (Sepherosa Ziehau)
Date: Sun, 23 Mar 2008 20:18:20 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <ea7b9c170803232012n2f27f893tf1d756d7c9770419@mail.gmail.com>

On Mon, Mar 24, 2008 at 2:14 AM, Joerg Sonnenberger
<joerg at britannica.bec.de> wrote:
> On Sun, Mar 23, 2008 at 01:41:42PM -0400, Chris Turner wrote:
>  > they should change the phrase from RTFM to 'Carefully RTFM' :)
>
>  RTFMAI -- Read The Fine Manual Again, Idiot.

http://leaf.dragonflybsd.org/~sephe/rtfm.jpg

:D

>
>  Joerg
>



-- 
Live Free or Die




From justin at shiningsilence.com  Sun Mar 23 20:38:30 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Sun, 23 Mar 2008 20:38:30 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: GSoC 2008 - mentors signup
Message-ID: <53885.192.168.0.252.1206329503.squirrel@www.shiningsilence.com>

If you are planning to be a mentor for a Summer of Code project, please
sign up here for the mentors mailing list:

http://groups.google.com/group/google-summer-of-code-mentors-list

If you've already signed up, your subscription should be set up tomorrow.





From justin at shiningsilence.com  Sun Mar 23 21:12:01 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Sun, 23 Mar 2008 21:12:01 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: GSoC 2008 - mentors signup
In-Reply-To: <53885.192.168.0.252.1206329503.squirrel@www.shiningsilence.com>
Message-ID: <54025.192.168.0.252.1206331572.squirrel@www.shiningsilence.com>

Also!

If you are a potential mentor and you have not done so yet:

http://code.google.com/soc/mentor_step1.html

Get yourself registered as a mentor for the Summer of Code project.  Once
you are in there, check off DragonFly in the "My Profile" section.

You will need a Google Account if you don't have one:

http://www.google.com/accounts

This will add you to the list of mentors in the Google Summer of Code web
application, so you can review/be attached to projects.

A guide is available if you want more information:

http://groups.google.com/group/google-summer-of-code-announce/web/guide-to-the-gsoc-web-app-for-mentors-and-organization-administrators






From c.turner at 199technologies.org  Mon Mar 24 04:29:28 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Mon, 24 Mar 2008 04:29:28 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <47E78ECE.4070307@199technologies.org>

Justin C. Sherrill wrote:
If you don't need a jail to spoof uname, as others posted, you can
installworld into a chroot and build everything you want there using
Joerg's spiffy pbulk.  That's what I'm doing on pkgbox now; I can hand you
my somewhat terse notes if you want.  It would be relatively easy to set
up the configuration you're talking about.
cheers - I guess I thought incorrectly that something 'special' was 
needed to get the uname to change .. have been using the legacy bulks in 
chroots / jails (for 'same os' builds) as I haven't quite migrated to 
pbulk yet ..

thanks for the help offer - I'll ask if I run into trouble.




From dillon at apollo.backplane.com  Mon Mar 24 08:28:49 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Mon, 24 Mar 2008 08:28:49 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <200803241500.m2OF0CG8043760@apollo.backplane.com>


:http://leaf.dragonflybsd.org/~sephe/rtfm.jpg
:
::D

    Ho!

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From elekktretterr at exemail.com.au  Mon Mar 24 09:10:15 2008
From: elekktretterr at exemail.com.au (Petr Janda)
Date: Mon, 24 Mar 2008 09:10:15 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
In-Reply-To: <200803240257.m2O2voNH038355@apollo.backplane.com>
Message-ID: <200803250138.49775.elekktretterr@exemail.com.au>


>
>     And, as you know, fully coherent filesystem access across machines is
>     going to be the basis for DragonFly's clustering across said machines.
>
>     In summary, things are progressing very well.
>


Hi Matt,
That's good to know things are going so well. Got a question. If memory serves 
me right, initially there was also going to be a thing called ANVIL, I can't 
remember what it was supposed to do and whether its still in your design. 
Could you elaborate a little?

Thanks,
Petr




From dillon at apollo.backplane.com  Mon Mar 24 14:12:11 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Mon, 24 Mar 2008 14:12:11 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
In-Reply-To: <200803240257.m2O2voNH038355@apollo.backplane.com>
Message-ID: <200803242100.m2OL0nWV046868@apollo.backplane.com>


:Hi Matt,
:That's good to know things are going so well. Got a question. If memory serves 
:me right, initially there was also going to be a thing called ANVIL, I can't 
:remember what it was supposed to do and whether its still in your design. 
:Could you elaborate a little?
:
:Thanks,
:Petr

    It's not really in the HAMMER design any more, primarily because HAMMER's
    volume model seems to work fine as-is.  Ultimately something like ANVIL
    (a block storage manager) would prove beneficial to the project but it
    would be treated as a separate project.  HAMMER's redundancy model is
    going to be baesd around replication and clustering.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From tgen at netphreax.net  Mon Mar 24 18:31:37 2008
From: tgen at netphreax.net (Thomas E. Spanjaard)
Date: Mon, 24 Mar 2008 18:31:37 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
In-Reply-To: <200803240257.m2O2voNH038355@apollo.backplane.com>
Message-ID: <47E85337.2070407@netphreax.net>

Matthew Dillon wrote:
    * Full historical access appears to be working but needs testing.
      Note that a sync is still needed to flush dirty cached data prior
      to acquiring a timestamp for the 'snapshot' to be set in stone.
      (dirty data cached in-memory has no historical tags and must be
      committed to physical disk before it can be accessed historically).
Wouldn't making timestamp queries (at least from userland) enforce a 
sync on the volume in question be useful here?
--
        Thomas E. Spanjaard
        tgen at netphreax.net
Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00005.pgp
Type: application/octet-stream
Size: 186 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080324/3077333f/attachment-0007.obj>

From dillon at apollo.backplane.com  Mon Mar 24 20:10:12 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Mon, 24 Mar 2008 20:10:12 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
In-Reply-To: <200803240257.m2O2voNH038355@apollo.backplane.com>
Message-ID: <200803250302.m2P32qLP050160@apollo.backplane.com>


:Wouldn't making timestamp queries (at least from userland) enforce a 
:sync on the volume in question be useful here?
:-- 
:         Thomas E. Spanjaard
:         tgen at netphreax.net

    Making the 'hammer now' command do a sync() is a good idea.  I will
    make that change right now so it doesn't get lost.

    Here's a general overview of the issues involved with having historical
    access to the filesystem:

				----------------

    Recording the timestamps in the in-memory cache, for a finer-grained
    snapshot capability, is doable but has its own issues.  Here's an
    illustration:

    open()  create file
    write() append 4K	(file size now 4K)
    write() append 4K	(file size now 8K)
    write() append 4K	(file size now 12K)
    write() append 4K	(file size now 16K)

    Now NONE of this has gone to disk yet, it's entirely in the in-memory
    cache.  The inode is in the in-memory cache.  The data is stored in
    the buffer cache.  Even the directory entry for the file that we
    just created is still in the in-memory cache (HAMMER caches the raw
    records it intends to commit later on).

    If I wanted to be able to acquire a timestamp between each write and
    'see' a snapshot of the file as of any point in the above sequence,
    then every write would also have to allocate a copy of the inode
    (because it changes size on each write).

    The data has the same problem though with a slightly different example.
    Lets say each write() was a seek-write, overwriting the previous data.
    Now with every write() I would have to allocate a copy of the data
    being overwritten.  This is complicated by the fact that the buffer
    cache has no clue about 'historical' accesses, so I would not be able
    to use the buffer cache to cache the data.

    There's also another problem and that is with the efficiency of the
    topology on-disk.  Even if I maintained all the copies of the inode
    and all the copies of the data in-memory, I would still have to sync
    all those copies to disk in order for things to remain historically
    coherent (whether it be in-cache or on-disk).  This would result in
    hundreds or even thousands of copies of the inode on-disk, not to
    mention potentially many copies of the data.

    I just don't want to do that right now, at least not as a default.  A
    lot of performance would be lost.  Hence a sync() is needed if
    you want to create a demark which you can accurately snapshot.

				-------------

    Here's a quick synopsis of how the cache would operate in a clustered
    filesystem:

    In order to properly integrate with in-memory caches, a wider cache
    coherency infrastructure is needed between machines such that
    modifications made on one machine proactively invalidate those
    protions of the cache(s) on other machines.  At the same time, any
    'dirty' cache data, for example when a file is created or written to,
    must lock the cache space in question on all other machines.
    The cache space in this case is not just the file data, but also the
    related namespaces (for creations, deletions, and renames).  Attempts
    to access locked spaces from other machines in the cluster would have
    to force a flush to the filesystem backing store and lower the cache
    states for the effected information on the original machine from dirty
    to shared-read-only.

    It will be easiest to integrate the cache coherency information into
    the buffer cache and namecache themselves.  Once a machine has dirtied
    an in-memory cache element... for example part of the namespace when
    creating a file or chunks of data written within a file, that machine
    must have a free hand to make further modifications to the cache spaces
    involved without further interaction with other machines.

				-------------

    Now, if you think of those two major elements you can see that they
    actually fit together quite well.  If I were to attempt to maintain
    transactional coherency on a per-system-call basis then the cache
    granularity between machines would have to be much, much smaller then
    our current in-memory caching elements provide.  That would become
    a really nasty coding problem.  So I don't even want to begin to
    complate transactional coherency at a finer-grain then sync() or
    fsync() until long after we actually have clustering working.

						-Matt





From elekktretterr at exemail.com.au  Mon Mar 24 21:56:58 2008
From: elekktretterr at exemail.com.au (Petr Janda)
Date: Mon, 24 Mar 2008 21:56:58 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
In-Reply-To: <200803240257.m2O2voNH038355@apollo.backplane.com>
Message-ID: <200803251516.16407.elekktretterr@exemail.com.au>

So is it needed to run hammer now in order to "create" a snapshot? What would 
I do in situation like this: got a hammer filesystem and couple of the files 
change on day to day basis. Then a week later I needed to access one of the 
files, in exactly the state they were 7 days ago.

Cheers,
Petr




From dillon at apollo.backplane.com  Mon Mar 24 22:34:15 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Mon, 24 Mar 2008 22:34:15 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
In-Reply-To: <200803240257.m2O2voNH038355@apollo.backplane.com>
Message-ID: <200803250526.m2P5QZ5X051081@apollo.backplane.com>


:So is it needed to run hammer now in order to "create" a snapshot? What would 
:I do in situation like this: got a hammer filesystem and couple of the files 
:change on day to day basis. Then a week later I needed to access one of the 
:files, in exactly the state they were 7 days ago.
:
:Cheers,
:Petr

    No, you do not have to run 'hammer now' to create a snapshot.  The
    kernel syncs all filesystems every 30 seconds, so if you do nothing
    at all you get a snapshot granularity of 30 seconds.

    Where you would use 'hammer now' is if you wanted the most current
    snapshot possible for the purpose of, say, backing up your filesystem
    to another machine.  You might do something like this:

	set timestamp = `hammer now`
	cpdup /mountpoint/@@$timestamp targethost:/somepath

    But if you didn't care about that you could just go back far enough
    that you get a stable historical view... e.g. go back 1 minute and you
    would have a stable view into your filesystem.

	set timestamp = `hammer stamp 60s`		<------ doesn't sync
	cpdup /mountpoint/@@$timestamp targethost:/somepath


    Ultimately the idea of managing filesystems this way is to still do
    regular backups from your production machine to your backup machine
    (ultimately by way of replication), with both running HAMMER, but only
    retain a limited amount of history on the production box.  You might
    desire to retain only one week's worth of history on the production box,
    retain one month's history on your local backup box, and retain a very
    granular one year's worth of history on your remote backup box.

    Come to think of it, I should add some more directives to the
    'hammer prune' command to make that easier to specify.

    Until I implement a live replication 'feed' the minimum granularity on
    the backup box will be how often you do your backups (e.g. once a day),
    and you can prune it into more granular forms from that starting point.
    Once we have a live replication feed the backup box will have the same
    30-second granularity that the production machine has.

    A major bullet point for this style of management is that the retention
    policy on the various boxes can be different even though they are
    all slaved off the same production filesystem.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From justin at shiningsilence.com  Tue Mar 25 05:58:49 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Tue, 25 Mar 2008 05:58:49 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: SoC - student signups
Message-ID: <58180.65.106.147.226.1206449676.squirrel@www.shiningsilence.com>

Here's a quick link roundup:

Are you a student?  Put in your application for a Google Summer of Code here:

http://code.google.com/soc/2008/student_signup.html

Student guide:
http://groups.google.com/group/google-summer-of-code-announce/web/guide-to-the-gsoc-web-app-for-student-applicants

Are you a mentor?  (That means hasso, hsu, sephe, matthias, TGEN, and
corecode right now)

Student proposals will show up on the mentor page, linked below.  You will
get to rate them, and take the one(s) that you want to mentor.

Mentor page:
http://code.google.com/soc/2008/mentor_home.html
Mentor guide:
http://groups.google.com/group/google-summer-of-code-announce/web/guide-to-the-gsoc-web-app-for-mentors-and-organization-administrators

If you are a mentor and are communicating with potential students, send
them the URLs above for student signup and the student guide; work with
them if they ask for advice on what to say in the application.  They can
resubmit up to 20 times if they want to correct it.

Deadline is March 31st.






From noah.yan at gmail.com  Thu Mar 27 20:17:48 2008
From: noah.yan at gmail.com (Yonghong Yan)
Date: Thu, 27 Mar 2008 20:17:48 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: About DFBSD.64
In-Reply-To: <47EB0B5B.5020802@gmail.com>
Message-ID: <59521b110803272015y1cc8cc39uc93f154ed36e0505@mail.gmail.com>

thanks for your interest.

I owe to everybody for any update or work in the past four months. so
many things happen in my work and my family (they are all good:) and
keep me extremely busy. But i am not leaving and will be back on this
soon.

the latest sources are in http://repo.or.cz/w/dragonfly/port-amd64.git
, I did have a compiled kernel long time before, but I have to break
it to work on the pmap. you can pick up from there. TGEN will help you
a lot, also keep me posted too, if you like.

Noah

On Wed, Mar 26, 2008 at 9:50 PM, Sdavtaker <sdavtaker at gmail.com> wrote:
> Hello,
>  Im applying to GSoC to work in the x64 version of DFBSD with TGEN, i
>  found some work already done in the repository and some mails in the
>  archive from you.
>  I was wondering if you already had a working compiled kernel in AMD64
>  machine and what was not working yet to continue that work.
>  Thanks for any info.
>  Sdav
>




From dillon at apollo.backplane.com  Sat Mar 29 13:27:43 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Sat, 29 Mar 2008 13:27:43 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 29-Mar-2008
Message-ID: <200803292022.m2TKMLGe004942@apollo.backplane.com>

    Good progress continues to be made.  HAMMER survived acting as my
    LAN backup machine (in full historical mode) for almost a week before
    it hit an assertion.  I've fixed that issue and believe that the core
    filesystem implementation code is now 'very stable'.

    Note that the recent commit will result in many more 'hammer_lock_ex:'
    messages on the console then you may have previously observed.  This is
    due to the way object id's are allocated in the face of parallel 
    modifications to the filesystem, resulting in too much locality of
    reference in the B-Tree.  I do intend to improve it.

    I am still working on the two major items needed before HAMMER can be
    declared operational, those being the filesystem full handling and the
    undo/recovery-on-mount code.  These are the last 'hard' bits left in
    the design.

    With exception to filling up the filesystem, which *will* create a mess,
    and noting that no crash recovery code exists yet (so you have to newfs
    it if you crash), I'd appreciate it if interested parties could test
    the other functions of the filesystem, in particular the pruning and
    reblocking functions (man hammer), and the historical access functions.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From dillon at apollo.backplane.com  Sun Mar 30 15:11:03 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Sun, 30 Mar 2008 15:11:03 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Need ideas on how to solve an st_ino/st_dev test issue for HAMMER.
Message-ID: <200803302207.m2UM7BCp016402@apollo.backplane.com>

    Here's the problem, given historical access softlinks as shown below:

test30# ls -lda cra*
drwxr-xr-x  1 root  wheel  Mar 29 13:04 crater
lrwxr-xr-x  1 root  wheel  Mar 29 18:57 crater.20080329 -> crater@@0x47eef383
lrwxr-xr-x  1 root  wheel  Mar 30 01:24 crater.20080330 -> crater@@0x47ef4e29
-rw-r--r--  2 root  wheel  Mar 30 01:24 crater.log

    The problem is that if I do this:

    diff -r crater.20080329/var/log crater.20080330/var/log

    Diff just returns without actually diffing anything.  The reason is
    because diff checks st_ino and st_dev and believes the directories/files
    to be identical because they match.

    I considered munging the inode number for historical accesses, but
    that would seriously break NFS exports which try to access historical
    files and directories.  Right now NFS *is* able to distinguish between
    the two because NFS handles are 128-bit-wide entities, so I can encode
    the as-of transaction id as part of the filehandle.  But userland
    programs only have access to a 64-bit-wide inode so userland still
    believes the files to be identical.

    st_dev is only 32 bits, carefully munging it is an option if we
    could figure out a way to do it, but I'd rather not.

    I am considering using st_gen but then we'd have to patch third
    party software to test st_gen along with everything else.  This may
    be the only workable solution, though, and only a few programs would
    need to be patched.  st_gen is only 32 bits but it would solve the
    problem as we would be able to use all 32 bits.

    If anyone has any bright ideas, including 'leave it alone', I'm all
    ears.

						-Matt





From justin at shiningsilence.com  Mon Mar 31 10:40:42 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Mon, 31 Mar 2008 10:40:42 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: SoC student applications due by 5PM PDT tomorrow
In-Reply-To: <1942.192.168.0.242.1206930479.squirrel@www.shiningsilence.com>
Message-ID: <11892.67.108.184.175.1206984967.squirrel@www.shiningsilence.com>

On Sun, March 30, 2008 10:27 pm, Justin C. Sherrill wrote:
> SoC students:
>
> If you have an application to submit for DragonFly/Summer of Code, please
> do so by 17:00 Pacific time on the 31st - that's tomorrow, at least for
> me.

The deadline for student proposals has been extended to April 7th; all
other dates move forward one week to acommodate.

This is a good time to update existing applications or submit new ones. 
Talk to your (potential) mentors if you are curious.






From nthery at gmail.com  Mon Mar 31 11:29:49 2008
From: nthery at gmail.com (Nicolas Thery)
Date: Mon, 31 Mar 2008 11:29:49 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
Message-ID: <64fc43b0803311126na7d0b27obaa9d35bac6d32ee@mail.gmail.com>

Hello,

Now that the release is over, I'll try to get rid of zones and migrate
allocations to objcache.

Here is a 1st patch that migrate struct proc.  I'll commit it in a
couple of days if nobody objects.

I'm also implementing a way to monitor objcache statistics.  So far,
I've hacked sth similar to
sysctl vm.zone: stats are returned in one giant string, one line per
cache.  That's simple but ugly and hard to read because there are
quite a few stats per cache.

So I'm thinking about implementing a small tool, ocstat, that extracts
stats from sysctl the way ps(1) does (thru libkvm iirc) and formats it
in various ways.  What do you think?

Cheers,
Nicolas

Index: src2/sys/kern/kern_exit.c
===================================================================
--- src2.orig/sys/kern/kern_exit.c	2008-03-31 08:05:59.139796000 +0200
+++ src2/sys/kern/kern_exit.c	2008-03-31 10:31:39.000000000 +0200
@@ -834,7 +834,7 @@ loop:
 			}

 			vm_waitproc(p);
-			zfree(proc_zone, p);
+			objcache_put(proc_cache, p);
 			nprocs--;
 			return (0);
 		}
Index: src2/sys/kern/kern_proc.c
===================================================================
--- src2.orig/sys/kern/kern_proc.c	2008-03-31 08:05:59.139918000 +0200
+++ src2/sys/kern/kern_proc.c	2008-03-31 10:31:39.000000000 +0200
@@ -84,7 +84,7 @@ u_long pgrphash;
 struct proclist allproc;
 struct proclist zombproc;
 struct spinlock allproc_spin;
-vm_zone_t proc_zone;
+struct objcache* proc_cache;
 vm_zone_t lwp_zone;
 vm_zone_t thread_zone;

@@ -131,7 +131,7 @@ procinit(void)
 	spin_init(&allproc_spin);
 	pidhashtbl = hashinit(maxproc / 4, M_PROC, &pidhash);
 	pgrphashtbl = hashinit(maxproc / 4, M_PROC, &pgrphash);
-	proc_zone = zinit("PROC", sizeof (struct proc), 0, 0, 5);
+	proc_cache = objcache_create_simple(M_PROC, sizeof(struct proc));
 	lwp_zone = zinit("LWP", sizeof (struct lwp), 0, 0, 5);
 	thread_zone = zinit("THREAD", sizeof (struct thread), 0, 0, 5);
 	uihashinit();
Index: src2/sys/sys/proc.h
===================================================================
--- src2.orig/sys/sys/proc.h	2008-03-31 08:05:59.140325000 +0200
+++ src2/sys/sys/proc.h	2008-03-31 10:31:39.000000000 +0200
@@ -473,7 +473,7 @@ struct proc *zpfind (pid_t);	/* Find zom
 struct vm_zone;
 struct globaldata;
 struct lwp_params;
-extern struct vm_zone *proc_zone;
+extern struct objcache *proc_cache;
 extern struct vm_zone *lwp_zone;

 int	enterpgrp (struct proc *p, pid_t pgid, int mksess);
Index: src2/sys/kern/kern_fork.c
===================================================================
--- src2.orig/sys/kern/kern_fork.c	2008-03-31 08:05:59.140042000 +0200
+++ src2/sys/kern/kern_fork.c	2008-03-31 10:31:39.000000000 +0200
@@ -332,7 +332,7 @@ fork1(struct lwp *lp1, int flags, struct
 	}

 	/* Allocate new proc. */
-	p2 = zalloc(proc_zone);
+	p2 = objcache_get(proc_cache, M_WAITOK);
 	bzero(p2, sizeof(*p2));

 	/*




From hsu at dragonflybsd.org  Mon Mar 31 11:44:34 2008
From: hsu at dragonflybsd.org (Jeffrey Hsu)
Date: Mon, 31 Mar 2008 11:44:34 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <64fc43b0803311126na7d0b27obaa9d35bac6d32ee@mail.gmail.com>
Message-ID: <200803311841.m2VIfQAI007579@nlpi001.prodigy.net>

The object cache is not a general-purpose memory allocator.  It's a cache of
pre-initialized objects.  Are the significant portions of the proc structure
that can be restored to initialized state on object puts?  If not, it's best
to just use a general-purpose memory allocator.

								Jeffrey




From corecode at fs.ei.tum.de  Mon Mar 31 12:07:02 2008
From: corecode at fs.ei.tum.de (Simon 'corecode' Schubert)
Date: Mon, 31 Mar 2008 12:07:02 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <200803311841.m2VIfQAI007579@nlpi001.prodigy.net>
Message-ID: <47F1357B.1070302@fs.ei.tum.de>

Jeffrey Hsu wrote:
> The object cache is not a general-purpose memory allocator.  It's a cache of
> pre-initialized objects.  Are the significant portions of the proc structure
> that can be restored to initialized state on object puts?  If not, it's best
> to just use a general-purpose memory allocator.

Why?  What's the loss if we use the object cache to allocate struct procs?

cheers
  simon

Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00006.pgp
Type: application/octet-stream
Size: 252 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080331/a4a24314/attachment-0007.obj>

From nthery at gmail.com  Mon Mar 31 12:17:03 2008
From: nthery at gmail.com (Nicolas Thery)
Date: Mon, 31 Mar 2008 12:17:03 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <nthery@gmail.com>
Message-ID: <64fc43b0803311214u7da6bbb8xaf971de1a80e7258@mail.gmail.com>

2008/3/31, Jeffrey Hsu <hsu at dragonflybsd.org>:
> The object cache is not a general-purpose memory allocator.  It's a cache of
>  pre-initialized objects.  Are the significant portions of the proc structure
>  that can be restored to initialized state on object puts?  If not, it's best
>  to just use a general-purpose memory allocator.

Well, I haven't checked this yet.  I planned to do this in a second
step after getting rid of zones.

I thought that even without  the pre-initialization part, objcache has
the advantage
of pre-allocating set of objects (as zones) and is additionally
mp-safe (contrary to zones and, granted, as malloc()).   The latter
may be interesting as we talk of improving MP support.

Cheers,
Nicolas




From dillon at apollo.backplane.com  Mon Mar 31 12:23:40 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Mon, 31 Mar 2008 12:23:40 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <200803311841.m2VIfQAI007579@nlpi001.prodigy.net>
Message-ID: <200803311921.m2VJLITB027669@apollo.backplane.com>

    I both agree and disagree with Jeff.  I think the only *disadvantage*
    to using objcache for struct proc is that objcache must cache a minimum
    number of free structures to be efficient so the overall kernel memory
    use would be a bit greater verses uses kmalloc().  But I agree with Jeff
    in that objcache's biggest advantage is that you can keep structural state
    intact and struct proc might not be a good candidate (yet).

    What I suggest is that you convert struct proc from zone to kmalloc
    first, and then look into a possible objcache adaptation.  kmalloc
    is not slow.. it's a very fast allocator.  Objcache is probably a tad
    faster but not by much.  Where objcache really wins is in not having
    to completey reinitialize the allocated structures.

    Over the years I've removed (I think) all the dependancies on requiring
    the proc structure to be in stable memory so I believe it can be moved to
    kmalloc/objcache now without any major pain.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From corecode at fs.ei.tum.de  Mon Mar 31 12:37:40 2008
From: corecode at fs.ei.tum.de (Simon 'corecode' Schubert)
Date: Mon, 31 Mar 2008 12:37:40 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: SoC student applications due by 5PM PDT tomorrow
In-Reply-To: <1942.192.168.0.242.1206930479.squirrel@www.shiningsilence.com>
Message-ID: <47F13CDA.6010703@fs.ei.tum.de>

Justin C. Sherrill wrote:
> On Sun, March 30, 2008 10:27 pm, Justin C. Sherrill wrote:
>> SoC students:
>>
>> If you have an application to submit for DragonFly/Summer of Code, please
>> do so by 17:00 Pacific time on the 31st - that's tomorrow, at least for
>> me.
> The deadline for student proposals has been extended to April 7th; all
> other dates move forward one week to acommodate.

This is very good.

Some more ideas for eager students (we want to keep the ratio, right?):

Enhance the FreeBSD/DragonFly sound infrastructure to support surround
sound/multichannel output.

Update sound drivers to support S/PDIF output.

Make the sound infrastructure OSSv4 compatible (there was a SoC at
FreeBSD last year or so)


of course only if it doesn't exist already :)

cheers
  simon


Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00007.pgp
Type: application/octet-stream
Size: 252 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080331/6da61cff/attachment-0007.obj>

From corecode at fs.ei.tum.de  Mon Mar 31 12:41:30 2008
From: corecode at fs.ei.tum.de (Simon 'corecode' Schubert)
Date: Mon, 31 Mar 2008 12:41:30 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <200803311841.m2VIfQAI007579@nlpi001.prodigy.net>
Message-ID: <47F13DE4.10205@fs.ei.tum.de>

Matthew Dillon wrote:
>     What I suggest is that you convert struct proc from zone to kmalloc
>     first, and then look into a possible objcache adaptation.  kmalloc
>     is not slow.. it's a very fast allocator.  Objcache is probably a tad
>     faster but not by much.  Where objcache really wins is in not having
>     to completey reinitialize the allocated structures.

Could we please not move to kmalloc, but instead try to move all fast
path allocations to objcache?  I don't like the idea of allocating
everything with kmalloc.  Caching struct procs is not a bad thing itself.

cheers
  simon


Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00008.pgp
Type: application/octet-stream
Size: 252 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080331/ac328c08/attachment-0007.obj>

From hsu at FreeBSD.org  Mon Mar 31 12:59:05 2008
From: hsu at FreeBSD.org (Jeffrey Hsu)
Date: Mon, 31 Mar 2008 12:59:05 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <47F1357B.1070302@fs.ei.tum.de>
Message-ID: <200803311920.m2VJK5Ln018015@nlpi015.prodigy.net>

The object cache sits on top of a general-purpose memory allocator such
as kmalloc or zalloc and provides pre-initialized object caching functionality.
If you're not going to use the object caching functionality, you can just
call the underlying memory allocator directly.

							Jeffrey




From dillon at apollo.backplane.com  Mon Mar 31 16:17:19 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Mon, 31 Mar 2008 16:17:19 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <200803311841.m2VIfQAI007579@nlpi001.prodigy.net>
Message-ID: <200803312311.m2VNBumd029866@apollo.backplane.com>

:Could we please not move to kmalloc, but instead try to move all fast
:path allocations to objcache?  I don't like the idea of allocating
:everything with kmalloc.  Caching struct procs is not a bad thing itself.=
:
:
:cheers
:  simon

    I will state for the record that I'm fine with either objcache or
    kmalloc.  I agree with Jeff that using objcache for struct proc
    probably isn't necessary but I also agree that it would not hurt either,
    and if the intent is to optimize the initialization of the proc
    structure in the future then moving to objcache now would save us
    from having to do it later.

    So whichever method Nicolas wants to use is fine with me.

						-Matt




From hsu at dragonflybsd.org  Mon Mar 31 19:22:47 2008
From: hsu at dragonflybsd.org (Jeffrey Hsu)
Date: Mon, 31 Mar 2008 19:22:47 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <64fc43b0803311214u7da6bbb8xaf971de1a80e7258@mail.gmail.com>
Message-ID: <200804010218.m312IVUq003624@nlpi043.prodigy.net>

  >> Are there significant portions of the proc structure
  >> that can be restored to initialized state on object puts?

  > I planned to do this in a second step after getting rid of zones.

I'll all in favor of making more use of caching pre-initialized objects, so
if this is your objective, then please go ahead.  It's just that I'd convert
over to the object cache in one step.

  > I thought that even without  the pre-initialization part, objcache has
  > the advantage of pre-allocating set of objects (as zones) and is additionally
  > mp-safe (contrary to zones and, granted, as malloc()).

Well, the zone allocator is MP-safe.  It's not hard to lock up the places that
manipulate the linked-list of free items. Look for uses of the zlock field.

								Jeffrey




From tgen at netphreax.net  Sat Mar  1 12:57:53 2008
From: tgen at netphreax.net (Thomas E. Spanjaard)
Date: Sat, 1 Mar 2008 12:57:53 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: [Fwd: Project Support Open Source: $50 donation to support you      project]
In-Reply-To: <2468.192.168.0.242.1204346451.squirrel@www.shiningsilence.com>
Message-ID: <47C9C1B7.50203@netphreax.net>

Justin C. Sherrill wrote:
The "donation" happens after you place an "acknowledgement" on an open
source project's web page.  I'm putting those words in scare quotes
because I think it's a "payment" for an "advertisement".  The supplied
link has nothing to do with DragonFly, to say the least.

<a href="http://www.2insure4less.com /" title="We support FOSS software
projects.">Online Insurance Quotes</a>
To think our souls are only worth $50...
--
        Thomas E. Spanjaard
        tgen at netphreax.net
Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00000.pgp
Type: application/octet-stream
Size: 186 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080301/0d61e240/attachment-0008.obj>

From c.turner at 199technologies.org  Sat Mar  1 17:52:31 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Sat, 1 Mar 2008 17:52:31 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Misc. ACPI / suspend
Message-ID: <47CA073B.6020106@199technologies.org>

Wondering if anyone more well versed in the ACPI implementation could
comment on the applicability of:
http://lkml.org/lkml/2007/4/6/69

w/r/t the current state of the art in Dfly

(or BSD's in general)

Cheers!

- Chris




From elekktretterr at exemail.com.au  Sun Mar  2 00:41:25 2008
From: elekktretterr at exemail.com.au (Petr Janda)
Date: Sun, 2 Mar 2008 00:41:25 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: CARP question
Message-ID: <200803021934.21669.elekktretterr@exemail.com.au>

So Ive setup CARP on 2 DF-based mailservers. Installation went fine. Box 1 has 
adskew of 0 therefore it is the MASTER. Box 2 has adskew of 254, therefore is 
BACKUP.  If i down the carp0 interface on Box 1, then Box 2 carp interface 
gets promoted to MASTER. Then I up the carp interface on Box 1, logically Box 
2 should become BACKUP again as Box 1 becomes MASTER due to adskew set to 0.

However it doesnt happen. When carp0 interface on Box 1 is upped it becomes a 
BACKUP, not a MASTER even though according to adskew it should be MASTER.

What is the desired behaviour?

Cheers
Petr




From qhwt+dfly at les.ath.cx  Sun Mar  2 02:50:14 2008
From: qhwt+dfly at les.ath.cx (YONETANI Tomokazu)
Date: Sun, 2 Mar 2008 02:50:14 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: panic: assertion: hammer_btree_cmp(cursor->left_bound,	&cursor->node->ondisk->elms[0].leaf.base) <= 0 in btree_split_leaf
In-Reply-To: <200802232204.m1NM4cxd046264@apollo.backplane.com>
Message-ID: <20080302104554.GA22813@les.ath.cx>

Hi.
While trying to find a procedure to reliably reproduce the panic
I reported last time, I caught a different panic (uploaded at
 ~y0netan1/crash/9/ on my leaf account).  I wrote the following shell
script (make sure to edit variables DISKS and MOUNTPT before using this
script or it may trash your system):
  #!/bin/sh -ex
  DISKS="/dev/ad0s1f"
  MOUNTPT=/mnt/HAMMER

  cd /
  newfs_hammer -L TEST $DISKS
  for i in `seq 1 100`; do
	  mount_hammer $DISKS $MOUNTPT
	  /bin/rm -rf $MOUNTPT/??
	  (set +x; for x in `seq 1 10000`; do echo -n > $MOUNTPT/$x; done)
	  umount $MOUNTPT
  done

And the panic is triggered by rm command.
I'll try to see if it's possible to reproduce the last one without
unmounting then mounting the HAMMER fs.

Cheers.




From dillon at apollo.backplane.com  Sun Mar  2 13:25:33 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Sun, 2 Mar 2008 13:25:33 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: panic: assertion: hammer_btree_cmp(cursor->left_bound,	&cursor->node->ondisk->elms[0].leaf.base) <= 0 in btree_split_leaf
In-Reply-To: <200802232204.m1NM4cxd046264@apollo.backplane.com>
Message-ID: <200803022119.m22LJRCY037076@apollo.backplane.com>


:Hi.
:While trying to find a procedure to reliably reproduce the panic
:I reported last time, I caught a different panic (uploaded at
: ~y0netan1/crash/9/ on my leaf account).  I wrote the following shell
:script (make sure to edit variables DISKS and MOUNTPT before using this
:script or it may trash your system):

(from the core)

panic: assertion: node->lock.refs == 0 && node->ondisk == NULL in hammer_flush_buffer_nodes

    Yah, I've seen this failure.  Add a sync or two before the umount and
    tell me if it still occurs.  It's either a node reference leak somewhere
    or it is a race between bufdaemon and umount.  The assertions are really
    strict there precisely to catch those sorts of cases.

    Also note that the code to deal with a full HAMMMER filesystem has not
    been written yet (The failure you are reporting is unrelated to a full
    HAMMER filesystem, though, just mentioning it).

						-Matt





From dillon at apollo.backplane.com  Sun Mar  2 13:29:03 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Sun, 2 Mar 2008 13:29:03 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Misc. ACPI / suspend
In-Reply-To: <47CA073B.6020106@199technologies.org>
Message-ID: <200803022126.m22LQbfI037188@apollo.backplane.com>


:Wondering if anyone more well versed in the ACPI implementation could
:comment on the applicability of:
:
:http://lkml.org/lkml/2007/4/6/69
:
:w/r/t the current state of the art in Dfly
:
:(or BSD's in general)
:
:Cheers!
:
:- Chris

    I really have no idea re: this.  Suspension in general is not well
    supported by any of the BSDs.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From dillon at apollo.backplane.com  Sun Mar  2 13:34:05 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Sun, 2 Mar 2008 13:34:05 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: [Fwd: Project Support Open Source: $50 donation to support you      project]
In-Reply-To: <2468.192.168.0.242.1204346451.squirrel@www.shiningsilence.com>
Message-ID: <200803022131.m22LVOe9037250@apollo.backplane.com>

:..
:source project's web page.  I'm putting those words in scare quotes
:because I think it's a "payment" for an "advertisement".  The supplied
:link has nothing to do with DragonFly, to say the least.
:
:I don't think this is a good idea, obviously, and replied to that effect. 
:However, I wanted to put this on a DragonFly list, in part to show this
:strange thing, and in part because I'm not comfortable making
:administrative decisions on behalf of the Project without being open as
:possible about it.

    It doesn't really cry out to me either.

						-Matt





From wbh at conducive.org  Sun Mar  2 20:36:32 2008
From: wbh at conducive.org (Bill Hacker)
Date: Mon, 03 Mar 2008 04:36:32 +0000
Subject: Misc. ACPI / suspend
In-Reply-To: <47CA073B.6020106@199technologies.org>
Message-ID: <47cb8050$0$855$415eb37d@crater_reader.dragonflybsd.org>

Matthew Dillon wrote:
:Wondering if anyone more well versed in the ACPI implementation could
:comment on the applicability of:
:
:http://lkml.org/lkml/2007/4/6/69
:
:w/r/t the current state of the art in Dfly
:
:(or BSD's in general)
:
:Cheers!
:
:- Chris
    I really have no idea re: this.  Suspension in general is not well
    supported by any of the BSDs.
					-Matt
					Matthew Dillon 
					<dillon at backplane.com>


. . and there seems to be a bit of a 'Catch 22' there in any case.

If the BIOS can alter 'stuff' out of site of the OS it is parking, what 
does the existence of such a 'feature' do to a(ny) security model?

Seems to at least beg creating the option of setting a flag to 
specifically *prevent* suspend-to-disk/hibernation (and/or force a 
reboot on wake-up).

Just because one is paranoid....  etc

Bill





From matthias at dragonflybsd.org  Tue Mar  4 02:30:52 2008
From: matthias at dragonflybsd.org (Matthias Schmidt)
Date: Tue, 4 Mar 2008 02:30:52 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
Message-ID: <20080304102335.GI9833@staatsfeind.org>

Hi,

Google just announced its Summer of Code for 2008:

	http://code.google.com/soc/2008/

I think this would be a great opportunity for DragonFly to participate
as a mentoring organisation.  We could attract new developers and could
get code/work done.  Looking at the SoC results of the other BSDs most
of their projects were a success.  Of course, not all, but a reasonable
percentage.  See [1] and [2].

It is some extra work for us, but IMO the benefits outweigh the extra
work.  And yes, I would volunteer as a mentor.  What do others
(developers) think?  Any more volunteers? :)

Some project ideas that come into my mind.  More ideas are listed in the
wiki:  http://wiki.dragonflybsd.org/index.cgi/ProjectsPage

 * Fix all remaining bugs in dma(8) and implement all missing features
 * Add a driver for newer Intel Wireless cards (I think sephe@ would
   love that :)
 * Bring our ACPI stuff in shape.  Maybe suspend2disk ...

 * [Add your own thoughts here]

Cheers,

	Matthias

PS: I don't want to create a bikeshed here whether you like the SoC or
not :)

[1] http://code.google.com/soc/2007/freebsd/about.html
[2] http://code.google.com/soc/2007/netbsd/about.html




From corecode at fs.ei.tum.de  Tue Mar  4 04:46:14 2008
From: corecode at fs.ei.tum.de (Simon 'corecode' Schubert)
Date: Tue, 4 Mar 2008 04:46:14 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47CD4386.1000704@fs.ei.tum.de>

Matthias Schmidt wrote:
>  * [Add your own thoughts here]

MP lock removal for network stack

and for the system  (first profile, find hot spots, fix hot spots, repeat)

cheers
  simon




From c.turner at 199technologies.org  Tue Mar  4 06:02:20 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Tue, 4 Mar 2008 06:02:20 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47CD551E.1040604@199technologies.org>

Matthias Schmidt wrote:
Some project ideas that come into my mind.  More ideas are listed in the
wiki:  http://wiki.dragonflybsd.org/index.cgi/ProjectsPage
+1 acpi
+1 interrupt routing
+1 SMP / giant removal
+1 pf synchup with openbsd
though there are several others on the page that are good..

need to dig up my wiki login and place appropriately..

also: thinking the ZFS port should be removed from the page - makes 
sense to everyone else? (e.g. fragments effort w/r/t hammer)





From tgen at netphreax.net  Tue Mar  4 06:54:31 2008
From: tgen at netphreax.net (Thomas E. Spanjaard)
Date: Tue, 4 Mar 2008 06:54:31 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47CD615F.8010209@netphreax.net>

Matthias Schmidt wrote:
Google just announced its Summer of Code for 2008:

 * [Add your own thoughts here]
x86-64 port :).
--
        Thomas E. Spanjaard
        tgen at netphreax.net
Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00001.pgp
Type: application/octet-stream
Size: 186 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080304/0d921000/attachment-0008.obj>

From rdivacky at FreeBSD.org  Tue Mar  4 07:07:03 2008
From: rdivacky at FreeBSD.org (Roman Divacky)
Date: Tue, 4 Mar 2008 07:07:03 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <20080304150255.GA8831@freebsd.org>

On Tue, Mar 04, 2008 at 02:49:03PM +0000, Thomas E. Spanjaard wrote:
> Matthias Schmidt wrote:
> >Google just announced its Summer of Code for 2008:
> >
> > * [Add your own thoughts here]
> 
> x86-64 port :).

all those ideas are great and needed etc. but keep in
mind that the projects should be doable by students
who might see dfly for the very first time.

don't overestimate whats possible and select projects
that look realistic

Roman Divacky (former SoC student)




From justin at shiningsilence.com  Tue Mar  4 08:32:56 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Tue, 4 Mar 2008 08:32:56 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <60322.65.106.147.226.1204648095.squirrel@www.shiningsilence.com>

On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
> Hi,
>
> Google just announced its Summer of Code for 2008:
>
> 	http://code.google.com/soc/2008/
>
> I think this would be a great opportunity for DragonFly to participate
> as a mentoring organisation.  We could attract new developers and could
> get code/work done.  Looking at the SoC results of the other BSDs most
> of their projects were a success.  Of course, not all, but a reasonable
> percentage.  See [1] and [2].

We've applied in previous years - Jeff Hsu did one year, and I put
together the application last year.  The hardest thing to find was
students (and they are the thing that helps SoC applications a lot, I
think).

Any student volunteers?  We have mentors.





From rluciani at gmail.com  Tue Mar  4 09:38:29 2008
From: rluciani at gmail.com (Robert Luciani)
Date: Tue, 04 Mar 2008 18:38:29 +0100
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47cd8915$0$854$415eb37d@crater_reader.dragonflybsd.org>

Justin C. Sherrill wrote:
> On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
>> Hi,
>>
>> Google just announced its Summer of Code for 2008:
>>
>> 	http://code.google.com/soc/2008/
>>
>> I think this would be a great opportunity for DragonFly to participate
>> as a mentoring organisation.  We could attract new developers and could
>> get code/work done.  Looking at the SoC results of the other BSDs most
>> of their projects were a success.  Of course, not all, but a reasonable
>> percentage.  See [1] and [2].
> 
> We've applied in previous years - Jeff Hsu did one year, and I put
> together the application last year.  The hardest thing to find was
> students (and they are the thing that helps SoC applications a lot, I
> think).
> 
> Any student volunteers?  We have mentors.
> 

bingo

-- 
Robert Luciani
Chalmers University of Technology, SWE
Department of Computer Science and Engineering
http://www.rluciani.com/public.key




From sdavtaker at gmail.com  Tue Mar  4 09:31:08 2008
From: sdavtaker at gmail.com (=?UTF-8?Q?Sd=C3=A4vtaker?=)
Date: Tue, 4 Mar 2008 09:31:08 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <c37d69f60803040926k206218a3kb8496d0cd18148bd@mail.gmail.com>

If you mentor, i will apply for coder :-)
Still in last year of university. :-)
Sdav

On Tue, Mar 4, 2008 at 1:28 PM, Justin C. Sherrill
<justin at shiningsilence.com> wrote:
> On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
>  > Hi,
>  >
>  > Google just announced its Summer of Code for 2008:
>  >
>  >       http://code.google.com/soc/2008/
>  >
>  > I think this would be a great opportunity for DragonFly to participate
>  > as a mentoring organisation.  We could attract new developers and could
>  > get code/work done.  Looking at the SoC results of the other BSDs most
>  > of their projects were a success.  Of course, not all, but a reasonable
>  > percentage.  See [1] and [2].
>
>  We've applied in previous years - Jeff Hsu did one year, and I put
>  together the application last year.  The hardest thing to find was
>  students (and they are the thing that helps SoC applications a lot, I
>  think).
>
>  Any student volunteers?  We have mentors.
>
>



-- 
Sd?vtaker prays to Rikku goddess for a good treasure.



From rluciani at gmail.com  Tue Mar  4 09:44:02 2008
From: rluciani at gmail.com (Robert Luciani)
Date: Tue, 04 Mar 2008 18:44:02 +0100
Subject: google soc "DragonFly"
Message-ID: <47cd8a63$0$855$415eb37d@crater_reader.dragonflybsd.org>

On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
> > Hi,
> >
> > Google just announced its Summer of Code for 2008:
> >
> > 	http://code.google.com/soc/2008/
> >
> > I think this would be a great opportunity for DragonFly to participate
> > as a mentoring organisation.  We could attract new developers and could
> > get code/work done.  Looking at the SoC results of the other BSDs most
> > of their projects were a success.  Of course, not all, but a reasonable
> > percentage.  See [1] and [2].

We've applied in previous years - Jeff Hsu did one year, and I put
together the application last year.  The hardest thing to find was
students (and they are the thing that helps SoC applications a lot, I
think).

Any student volunteers?  We have mentors.


-- 
Robert Luciani
Chalmers University of Technology, SWE
Department of Computer Science and Engineering
http://www.rluciani.com/public.key




From rluciani at gmail.com  Tue Mar  4 10:04:14 2008
From: rluciani at gmail.com (Robert Luciani)
Date: Tue, 04 Mar 2008 19:04:14 +0100
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47cd8f1f$0$856$415eb37d@crater_reader.dragonflybsd.org>

Robert Luciani wrote:
> Justin C. Sherrill wrote:
>> On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
>>> Hi,
>>>
>>> Google just announced its Summer of Code for 2008:
>>>
>>> 	http://code.google.com/soc/2008/
>>>
>>> I think this would be a great opportunity for DragonFly to participate
>>> as a mentoring organisation.  We could attract new developers and could
>>> get code/work done.  Looking at the SoC results of the other BSDs most
>>> of their projects were a success.  Of course, not all, but a reasonable
>>> percentage.  See [1] and [2].
>> We've applied in previous years - Jeff Hsu did one year, and I put
>> together the application last year.  The hardest thing to find was
>> students (and they are the thing that helps SoC applications a lot, I
>> think).
>>
>> Any student volunteers?  We have mentors.
>>
> 
> bingo
> 
My girlfriend Danwei noted that she would also like partake in the SoC.
She's studying IT here at Chalmers and will join the mailing list shortly.
-- 
Robert Luciani
Chalmers University of Technology, SWE
Department of Computer Science and Engineering
http://www.rluciani.com/public.key




From dillon at apollo.backplane.com  Tue Mar  4 13:08:30 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Tue, 4 Mar 2008 13:08:30 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Going to have to roll 1.12.1
Message-ID: <200803042104.m24L43g1065278@apollo.backplane.com>

    Due to a critical bug in sendmail that can cause it to seg-fault I will
    be rolling 1.12.1 as soon as I get verification that the current
    fix deals with it.

						-Matt





From sdavtaker at gmail.com  Tue Mar  4 17:40:43 2008
From: sdavtaker at gmail.com (=?UTF-8?B?U2TDpHZ0YWtlcg==?=)
Date: Tue, 4 Mar 2008 17:40:43 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: [Fwd: Project Support Open Source: $50 donation to support you  project]
In-Reply-To: <2468.192.168.0.242.1204346451.squirrel@www.shiningsilence.com>
Message-ID: <47CDF8D1.9070100@gmail.com>

50 bucks?
Come on...
You can get a meal a lot more expensive than that just going to a free 
HP conference about linux and you only have to rent your soul 3-5 hours ;-)
Sdav

Matthew Dillon escribi?:
:..
:source project's web page.  I'm putting those words in scare quotes
:because I think it's a "payment" for an "advertisement".  The supplied
:link has nothing to do with DragonFly, to say the least.
:
:I don't think this is a good idea, obviously, and replied to that effect. 
:However, I wanted to put this on a DragonFly list, in part to show this
:strange thing, and in part because I'm not comfortable making
:administrative decisions on behalf of the Project without being open as
:possible about it.

    It doesn't really cry out to me either.

						-Matt

  






From sdavtaker at gmail.com  Tue Mar  4 17:56:35 2008
From: sdavtaker at gmail.com (=?UTF-8?B?U2TDpHZ0YWtlcg==?=)
Date: Tue, 4 Mar 2008 17:56:35 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47CDFCCE.1010106@gmail.com>

A cute idea for for GSOC would be to finish the installer.
We were talking about this in my local BUG, we trying to find out how to 
help on that from here.
There is a few missing features in the CD.

   * FDISK, you need to create the slides from another OS before
     install DFBSD, i think port FDisk from FBSD or any *BSD will solve it.
   * Add to the make release a way to add some custom applications to
     the released liveCD (suppose you want to add nmap or ssh or
     something just to use as test disk in some enviroment).
   * Make the installer a little more customizable, and maybe w/ a GUI
     (I like a lot the console approach, but GUI installer will be a
     popularity move, DFBSD w/X makes a Desktop machine work, actually
     im using it that way and really like it).
I think those projects can be done in a SOC by students (like me) with a 
little guide.
Im a lot more interested in things network related and kernel, but i 
dont mind to work on those things, they need to be done some day.
What u think?
Sdav

Robert Luciani escribi?:
Robert Luciani wrote:
  
Justin C. Sherrill wrote:
    
On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
      
Hi,

Google just announced its Summer of Code for 2008:

	http://code.google.com/soc/2008/

I think this would be a great opportunity for DragonFly to participate
as a mentoring organisation.  We could attract new developers and could
get code/work done.  Looking at the SoC results of the other BSDs most
of their projects were a success.  Of course, not all, but a reasonable
percentage.  See [1] and [2].
        
We've applied in previous years - Jeff Hsu did one year, and I put
together the application last year.  The hardest thing to find was
students (and they are the thing that helps SoC applications a lot, I
think).
Any student volunteers?  We have mentors.

      
bingo

    
My girlfriend Danwei noted that she would also like partake in the SoC.
She's studying IT here at Chalmers and will join the mailing list shortly.
  






From c.turner at 199technologies.org  Tue Mar  4 18:30:53 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Tue, 4 Mar 2008 18:30:53 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47CE04C9.1010902@199technologies.org>

Justin C. Sherrill wrote:
together the application last year.  The hardest thing to find was
students (and they are the thing that helps SoC applications a lot, I
think).
umm.. if google wants to send me back to school, I'll sign up - hows 
that for a fair trade :?






From wbh at conducive.org  Tue Mar  4 23:52:13 2008
From: wbh at conducive.org (Bill Hacker)
Date: Wed, 05 Mar 2008 07:52:13 +0000
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47ce512e$0$855$415eb37d@crater_reader.dragonflybsd.org>

Sd?vtaker wrote:
A cute idea for for GSOC would be to finish the installer.
We were talking about this in my local BUG, we trying to find out how to 
help on that from here.
There is a few missing features in the CD.

   * FDISK, you need to create the slides from another OS before
     install DFBSD, i think port FDisk from FBSD or any *BSD will solve it.
I'd rather see that 'reversed' - i.e. - build a more capable fdisk in 
DFLY with hope that it might be seen worth importing into Free/Net/Open, 
or *at least* be able to do a more flexible job than those now do.

And disklabels as well. Hand in glove.

Here's why:

- At the moment, working with Free, Open, DFLY, and OpenSolaris on the 
same HDD requires a bit of acrobatics.

- There seems to now be greater divergence between/among the *BSD's as 
to being able to read each other's disklabels, mount and use each 
other's 'flavor' of FFS/UFS (not to mention Apple's implementation of 
UFS) than there is among the vast multitude of Linux ext2/3 denizens.

Even to the point where use of a *Linux* fs is the more universal way 
for being able to share mounts among the *BSD's. Think detached drives. 
And no - FAT is not all that practical for several reasons.

- DFLY currently has the most fine-grain ability to create slices and 
partitions. But the others cannot all (any?) read those.

'progress' w/r any of the *BSD's direction as to changes, improvements 
(or not) in their once-common-ancestry fs & disklabels need not be 
sacrificed.

I'm not holding out wish or hope for all players agreeing to return to 
'one sacred way'. Nor 'one new universal fs'. Neither is gonna happen.

But a 'legacy compatible' or least-common-denominator mode would do fine 
- most especially for portable / SAN devices.

So - how about a 'flexible' DFLY fdisk to go along with a 'flexible' 
disklabel that could adapt to whatever it found / was told to create?

JM2CW - but that *might* be a good place to get a cross-*BSD team together.

*snip* (other good stuff)

Bill Hacker




From matthias at dragonflybsd.org  Wed Mar  5 01:02:43 2008
From: matthias at dragonflybsd.org (Matthias Schmidt)
Date: Wed, 5 Mar 2008 01:02:43 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <20080305085747.GJ9833@staatsfeind.org>

Hi,

* Justin C. Sherrill wrote:
> 
> We've applied in previous years - Jeff Hsu did one year, and I put
> together the application last year.  The hardest thing to find was
> students (and they are the thing that helps SoC applications a lot, I
> think).

This is good to know, so we could coordinate that if we have enough
mentors and projects?!?  I put together a small text in the wiki:

http://wiki.dragonflybsd.org/index.cgi/GoogleSoC2008

Feel free to add project or missing stuff.  I'm sure I missed a lot of
things :)

> Any student volunteers?  We have mentors.

According to the discussion we could have some students, who would be a
mentor (besides me)?

Regards

	Matthias





From sdavtaker at gmail.com  Wed Mar  5 06:28:37 2008
From: sdavtaker at gmail.com (=?UTF-8?Q?Sd=C3=A4vtaker?=)
Date: Wed, 5 Mar 2008 06:28:37 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <c37d69f60803050624kd86d3d0w3b44a02d0e5a5391@mail.gmail.com>

<quote>
Write a driver (from scratch) for Intel 3945 wireless device
Mentor: Sepherosa Ziehau
</quote>

Yes yes yes, i want to :-)
Someone else planning to mentor in drivers coding?
Sdav

On Wed, Mar 5, 2008 at 5:57 AM, Matthias Schmidt
<matthias at dragonflybsd.org> wrote:
> Hi,
>
>
>  * Justin C. Sherrill wrote:
>  >
>  > We've applied in previous years - Jeff Hsu did one year, and I put
>  > together the application last year.  The hardest thing to find was
>  > students (and they are the thing that helps SoC applications a lot, I
>  > think).
>
>  This is good to know, so we could coordinate that if we have enough
>  mentors and projects?!?  I put together a small text in the wiki:
>
>  http://wiki.dragonflybsd.org/index.cgi/GoogleSoC2008
>
>  Feel free to add project or missing stuff.  I'm sure I missed a lot of
>  things :)
>
>
>  > Any student volunteers?  We have mentors.
>
>  According to the discussion we could have some students, who would be a
>  mentor (besides me)?
>
>  Regards
>
>         Matthias
>
>



-- 
Sd?vtaker prays to Rikku goddess for a good treasure.



From rluciani at gmail.com  Wed Mar  5 10:56:42 2008
From: rluciani at gmail.com (Robert Luciani)
Date: Wed, 05 Mar 2008 19:56:42 +0100
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47ceecea$0$847$415eb37d@crater_reader.dragonflybsd.org>

Sd?vtaker wrote:
> <quote>
> Write a driver (from scratch) for Intel 3945 wireless device
> Mentor: Sepherosa Ziehau
> </quote>
> 
> Yes yes yes, i want to :-)
> Someone else planning to mentor in drivers coding?
> Sdav
> 
> On Wed, Mar 5, 2008 at 5:57 AM, Matthias Schmidt
> <matthias at dragonflybsd.org> wrote:
>> Hi,
>>
>>
>>  * Justin C. Sherrill wrote:
>>  >
>>  > We've applied in previous years - Jeff Hsu did one year, and I put
>>  > together the application last year.  The hardest thing to find was
>>  > students (and they are the thing that helps SoC applications a lot, I
>>  > think).
>>
>>  This is good to know, so we could coordinate that if we have enough
>>  mentors and projects?!?  I put together a small text in the wiki:
>>
>>  http://wiki.dragonflybsd.org/index.cgi/GoogleSoC2008
>>
>>  Feel free to add project or missing stuff.  I'm sure I missed a lot of
>>  things :)
>>
>>
>>  > Any student volunteers?  We have mentors.
>>
>>  According to the discussion we could have some students, who would be a
>>  mentor (besides me)?
>>
>>  Regards
>>
>>         Matthias
>>
>>
> 
> 
>

IF someone starts to write a 3945 Intel driver,
please keep the newer 4965 in mind too.

-- 
Robert Luciani
Chalmers University of Technology, SWE
Department of Computer Science and Engineering
http://www.rluciani.com/public.key




From joerg at britannica.bec.de  Wed Mar  5 12:01:05 2008
From: joerg at britannica.bec.de (Joerg Sonnenberger)
Date: Wed, 5 Mar 2008 12:01:05 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <20080305195711.GA9981@britannica.bec.de>

On Wed, Mar 05, 2008 at 07:56:42PM +0100, Robert Luciani wrote:
> IF someone starts to write a 3945 Intel driver,
> please keep the newer 4965 in mind too.

NetBSD's wpi works quite well. The hardware is quite different from
4945.

Joerg




From sepherosa at gmail.com  Wed Mar  5 17:48:50 2008
From: sepherosa at gmail.com (Sepherosa Ziehau)
Date: Wed, 5 Mar 2008 17:48:50 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <ea7b9c170803051744u22b09484ofc994f034f11df3b@mail.gmail.com>

On Thu, Mar 6, 2008 at 2:56 AM, Robert Luciani <rluciani at gmail.com> wrote:
>  IF someone starts to write a 3945 Intel driver,

"IF" you know that trying to fix any wired bugs in certain drivers
(e.g. ipw, ral) will require you to read through all of the vendor's
linux code (yes, even including register values and position), i.e.
there is not much difference between writing one from scratch and
porting+fixing_bugs, then you probably will not put "IF" at the start
of your sentence.
If what I said sounded too harsh to you, then I was sorry.

>  please keep the newer 4965 in mind too.

Will do, once generic 11n support is brought in from freebsd.

Best Regards,
sephe

-- 
Live Free or Die




From saw at online.de  Thu Mar  6 05:34:14 2008
From: saw at online.de (Sascha Wildner)
Date: Thu, 06 Mar 2008 14:34:14 +0100
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
Message-ID: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>

Hi all,

this is probably as good a moment as any to come out of the forest with 
this. The patch at

http://leaf.dragonflybsd.org/~swildner/nrelease_gui.diff

adds some code to nrelease/ to build a LiveCD with xorg and so on 
(currently, only the xorg metapackages and fluxbox are added). In order 
to build one, you need a local dir with the pkgsrc binary packages (see 
below).

The following commands should then do the trick:

cd /usr/src
make buildworld
make buildkernel
cd nrelease
patch -p 0 </path/to/the/patch
make PKGSRC_PKG_PATH=/path/to/packages/dir/All realquick gui
The resulting ISO will be in /usr/release/dfly-gui.iso then. It will not 
boot into xorg automatically (although this is easily possible), so you 
need to login as root and do startx.

As of now, this all is kind of basic, more a proof of concept than 
anything else. As our release framework installs packages via chroot, 
the current setup just copies _all_ packages to the chroot before 
installing (kind of a hack).

That said, I'm now primarily interested in opinions/ideas/... about the 
direction this should take. Which packages would we like to see on the 
CD? Should it be a generic setup with the "most common things" 
installed, so a system can be quickly setup by the installer (which will 
cpdup /usr/pkg). Or should it be a more specialized set of tools? Or 
even as many packages as possible (Live DVD?). Etc., etc.

Before continuing on it, I'm really interested in people's input so 
don't hold anything back, please. :)

Sascha

--
http://yoyodyne.ath.cx



From rluciani at gmail.com  Thu Mar  6 06:42:03 2008
From: rluciani at gmail.com (Robert Luciani)
Date: Thu, 06 Mar 2008 15:42:03 +0100
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <47d002bc$0$847$415eb37d@crater_reader.dragonflybsd.org>

Sascha Wildner wrote:
> Hi all,
> 
> this is probably as good a moment as any to come out of the forest with
> this. The patch at
> 
> http://leaf.dragonflybsd.org/~swildner/nrelease_gui.diff
> 
> adds some code to nrelease/ to build a LiveCD with xorg and so on
> (currently, only the xorg metapackages and fluxbox are added). In order
> to build one, you need a local dir with the pkgsrc binary packages (see
> below).
> 
> The following commands should then do the trick:
> 
> cd /usr/src
> make buildworld
> make buildkernel
> cd nrelease
> patch -p 0 </path/to/the/patch
> make PKGSRC_PKG_PATH=/path/to/packages/dir/All realquick gui
> 
> The resulting ISO will be in /usr/release/dfly-gui.iso then. It will not
> boot into xorg automatically (although this is easily possible), so you
> need to login as root and do startx.
> 
> As of now, this all is kind of basic, more a proof of concept than
> anything else. As our release framework installs packages via chroot,
> the current setup just copies _all_ packages to the chroot before
> installing (kind of a hack).
> 
> That said, I'm now primarily interested in opinions/ideas/... about the
> direction this should take. Which packages would we like to see on the
> CD? Should it be a generic setup with the "most common things"
> installed, so a system can be quickly setup by the installer (which will
> cpdup /usr/pkg). Or should it be a more specialized set of tools? Or
> even as many packages as possible (Live DVD?). Etc., etc.
> 
> Before continuing on it, I'm really interested in people's input so
> don't hold anything back, please. :)
> 
> Sascha
> 

I think the main point of such a live-cd would be to test
dragonfly-specific features such as vkernels and more. Mplayer and
OpenOffic work the same on all platforms, so they might not be super
important, while irssi, firefox, networking tools, vim, a few more
shells/terminals might make it easier to for people to quickly gauge if
they can reproduce their current productivity and also what is new.

And if the point of a livecd is to test that kind of stuff, then it
would be nice for it to have a kernel that supports as much as possible
like ALTQ, and drivers.

Also if it has lots and lots of programs (thinking multimedia, java,
etc..) it might be hard to keep the future x64 and x86 live-cds on par.
Gentoo had this problem many years ago and it was very bothersome.

-- 
Robert Luciani
Chalmers University of Technology, SWE
Department of Computer Science and Engineering
http://www.rluciani.com/public.key




From matthias at dragonflybsd.org  Thu Mar  6 07:12:43 2008
From: matthias at dragonflybsd.org (Matthias Schmidt)
Date: Thu, 6 Mar 2008 07:12:43 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <20080306150757.GN9833@staatsfeind.org>

* Sascha Wildner wrote:
> Hi all,
> 
> this is probably as good a moment as any to come out of the forest with this. 
> The patch at
> 
> http://leaf.dragonflybsd.org/~swildner/nrelease_gui.diff
> 
> adds some code to nrelease/ to build a LiveCD with xorg and so on (currently, 
> only the xorg metapackages and fluxbox are added). In order to build one, you 
> need a local dir with the pkgsrc binary packages (see below).

Great work Sascha.

I agree with Robert on most of his stated points.
It would be nice to see some DragonFly specific features on the CD
(although I'm not sure if that will work for all features).  A little
environment where most Unix users feel at home (fluxbox, xfce, firefox,
thunderbird, gvim) should be enough.

Big applications like OO.org, java etc won't work because they are not
available as pkgsrc packages neither is it possible to compile them on
DragonFly.  At least to my knowledge.

Regards

	Matthias




From dillon at apollo.backplane.com  Thu Mar  6 09:31:52 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Thu, 6 Mar 2008 09:31:52 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <200803061728.m26HSR3O091809@apollo.backplane.com>


:Hi all,
:
:this is probably as good a moment as any to come out of the forest with 
:this. The patch at
:
:http://leaf.dragonflybsd.org/~swildner/nrelease_gui.diff
:
:adds some code to nrelease/ to build a LiveCD with xorg and so on 
:(currently, only the xorg metapackages and fluxbox are added). In order 
:to build one, you need a local dir with the pkgsrc binary packages (see 
:below).
:
:The following commands should then do the trick:

    It looks reasonable, though the package copy has to be tightened
    up a bit I think.

:...
:installed, so a system can be quickly setup by the installer (which will 
:cpdup /usr/pkg). Or should it be a more specialized set of tools? Or 
:even as many packages as possible (Live DVD?). Etc., etc.
:
:Before continuing on it, I'm really interested in people's input so 
:don't hold anything back, please. :)
:
:Sascha

    I think this is an excellent time to work up a DVD build and to
    add various 'flavor' extras.  So, e.g.:

	make installer gui gui_extras release dvd

    (All 'dvd' would do is generate a dvd compatible image for burning to
    dvd instead of cd).  I did a quick perusal of what I have on my
    workstation:

    * X
    * Firefox
    * Linux emulation
    * Open Office (linux version)
    * fvwm2
    * xpdf
    * freetype2

    I'd also suggest some image editing tools like gimp, and maybe the KDE
    gui suite.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From justin at shiningsilence.com  Thu Mar  6 09:42:44 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Thu, 6 Mar 2008 09:42:44 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <55427.65.106.147.226.1204825168.squirrel@www.shiningsilence.com>

On Thu, March 6, 2008 8:34 am, Sascha Wildner wrote:

> That said, I'm now primarily interested in opinions/ideas/... about the
> direction this should take. Which packages would we like to see on the
> CD? Should it be a generic setup with the "most common things"
> installed, so a system can be quickly setup by the installer (which will
> cpdup /usr/pkg). Or should it be a more specialized set of tools? Or
> even as many packages as possible (Live DVD?). Etc., etc.

What Robert said is good - whatever's needed to enable DragonFly-specific
features.  Along with that would be some sort of documentation (a README? 
A HTML file on whatever desktop we provide) that points people at the
different DragonFly tools, so they know what to try and how to try it.

There's going to be some percentage of people who try DragonFly who don't
know about vkernels, for instance, but there's our chance to educate them.
 I'm probably volunteering myself, aren't I?





From sdavtaker at gmail.com  Thu Mar  6 09:50:09 2008
From: sdavtaker at gmail.com (=?UTF-8?Q?Sd=C3=A4vtaker?=)
Date: Thu, 6 Mar 2008 09:50:09 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <c37d69f60803060947t110750c0sd6b542ea505d188d@mail.gmail.com>

Cool Sascha :-)
I just posted about this 1 or 2 days ago in the SOC project ideas thread.
Want to mentor this one? ;-)
Damian

On Thu, Mar 6, 2008 at 2:28 PM, Matthew Dillon
<dillon at apollo.backplane.com> wrote:
>
>  :Hi all,
>
> :
>  :this is probably as good a moment as any to come out of the forest with
>  :this. The patch at
>  :
>  :http://leaf.dragonflybsd.org/~swildner/nrelease_gui.diff
>  :
>  :adds some code to nrelease/ to build a LiveCD with xorg and so on
>  :(currently, only the xorg metapackages and fluxbox are added). In order
>  :to build one, you need a local dir with the pkgsrc binary packages (see
>  :below).
>  :
>  :The following commands should then do the trick:
>
>     It looks reasonable, though the package copy has to be tightened
>     up a bit I think.
>
>  :...
>  :installed, so a system can be quickly setup by the installer (which will
>
> :cpdup /usr/pkg). Or should it be a more specialized set of tools? Or
>  :even as many packages as possible (Live DVD?). Etc., etc.
>  :
>  :Before continuing on it, I'm really interested in people's input so
>  :don't hold anything back, please. :)
>  :
>  :Sascha
>
>     I think this is an excellent time to work up a DVD build and to
>     add various 'flavor' extras.  So, e.g.:
>
>         make installer gui gui_extras release dvd
>
>     (All 'dvd' would do is generate a dvd compatible image for burning to
>     dvd instead of cd).  I did a quick perusal of what I have on my
>     workstation:
>
>     * X
>     * Firefox
>     * Linux emulation
>     * Open Office (linux version)
>     * fvwm2
>     * xpdf
>     * freetype2
>
>     I'd also suggest some image editing tools like gimp, and maybe the KDE
>     gui suite.
>
>                                         -Matt
>                                         Matthew Dillon
>                                         <dillon at backplane.com>
>



-- 
Sd?vtaker prays to Rikku goddess for a good treasure.



From saw at online.de  Thu Mar  6 11:54:01 2008
From: saw at online.de (Sascha Wildner)
Date: Thu, 06 Mar 2008 20:54:01 +0100
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <47d04ba2$0$856$415eb37d@crater_reader.dragonflybsd.org>

Matthew Dillon wrote:
    It looks reasonable, though the package copy has to be tightened
    up a bit I think.
It looks as if it would work with mount_null'ing the chroot's 
/tmp/packages. I'll have a better patch ready tomorrow.

Sascha

--
http://yoyodyne.ath.cx



From c.turner at 199technologies.org  Thu Mar  6 19:11:44 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Thu, 6 Mar 2008 19:11:44 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Misc. ACPI / suspend
In-Reply-To: <47CA073B.6020106@199technologies.org>
Message-ID: <47D0B079.3060905@199technologies.org>

Chris Turner wrote:
Wondering if anyone more well versed in the ACPI implementation could
comment on the applicability of:
http://lkml.org/lkml/2007/4/6/69

Doing a little digging, it seems like

. /platform/pc32/i386/i686_mem.c

*might* have the necessary infrastructure to remap the MTRR's per the 
thread referenced,

but:

. /platform/pc32/acpica5/acpi_wakeup.c

doesn't seem to be using this infrastructure..

I'm no where near reaching an understanding of this yet,
but I'm wondering 3 things:
1) does anyone have ACPI (instead of APM)
   sleep / suspend / wakeup working on Dfly ?
2) If so, what machines are being used ?
3) Same question for other BSDs - my understanding is NetBSD is most
   'advanced' w/r/t power managment - but I'm not 100% on this ...
would looove to have a sleeping / resuming / scaling laptop running some 
BSD flavor.. am willing to work towards that end, esp. w/r/t Dfly -
trying to chart a course to figguring this out.

Thanks all,

- Chris




From c.turner at 199technologies.org  Thu Mar  6 19:12:33 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Thu, 6 Mar 2008 19:12:33 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: PCI Bios / Interrupt remapping / etc
Message-ID: <47D0B211.6000002@199technologies.org>

Doing a bit of digging here for my long-standing CBB+SIO interupt and 
buffer problem -

one machine I've tested against was an OpenBSD machine, which didn't
always work to handle the cardbus sio card on a PCI cardbus adapter
-

tuning up some of the device flags in:

http://www.openbsd.org/cgi-bin/man.cgi?query=pcibios&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=html

seems to have alleviated the problem for that os..

I'm just only starting to get up to speed on how DF handles these types 
of things (namely initial PIC / interrupt layout at boot time device 
enumeration), but am wondering if anyone familiar with this area of the 
code has any comments / advice w/r/t the capabilities of the DF bios 
drivers
and the various quirks / fixup mentioned in the link above..

looking to possibly investigate fixing up some of these issues over time.

Thanks

- Chris







From pavalos at theshell.com  Fri Mar  7 01:14:55 2008
From: pavalos at theshell.com (Peter Avalos)
Date: Fri, 7 Mar 2008 01:14:55 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: cam locking
Message-ID: <20080307091024.GC1652@ylem.theshell.com>

So I've been working on locking up cam using lockmgr locks, and here's
what I have so far:

http://www.theshell.com/~pavalos/wip/cam-lock.patch

Most of the work is obtained from FreeBSD.  I've only been running this
on my SCSI machine for a day, but because the patch is so large, I wanted
to make it available for people to review if they have some spare time.

Thanks,
Peter
Attachment:
pgp00002.pgp
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00002.pgp
Type: application/octet-stream
Size: 197 bytes
Desc: "Description: PGP signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080307/9a17ecd8/attachment-0008.obj>

From jspringe at uos.de  Fri Mar  7 03:25:17 2008
From: jspringe at uos.de (Jost Tobias Springenberg)
Date: Fri, 7 Mar 2008 12:25:17 +0100
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <20080307122517.72c9e2b1.jspringe@uos.de>

On Tue, 4 Mar 2008 11:28:15 -0500 (EST)
"Justin C. Sherrill" <justin at shiningsilence.com> wrote:

> On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
> > Hi,
> >
> > Google just announced its Summer of Code for 2008:
> >
> > 	http://code.google.com/soc/2008/
> >
> > I think this would be a great opportunity for DragonFly to participate
> > as a mentoring organisation.  We could attract new developers and could
> > get code/work done.  Looking at the SoC results of the other BSDs most
> > of their projects were a success.  Of course, not all, but a reasonable
> > percentage.  See [1] and [2].
> 
> We've applied in previous years - Jeff Hsu did one year, and I put
> together the application last year.  The hardest thing to find was
> students (and they are the thing that helps SoC applications a lot, I
> think).
> 
> Any student volunteers?  We have mentors.
> 

I read this mailing list for quite a while now and thought about contributing stuff
to DFfly several times, so yes why not take this opportunity if it's there.

-- 
Jost Tobias Springenberg <jspringe at uos.de>




From tgen at netphreax.net  Fri Mar  7 05:17:27 2008
From: tgen at netphreax.net (Thomas E. Spanjaard)
Date: Fri, 7 Mar 2008 05:17:27 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: PCI Bios / Interrupt remapping / etc
In-Reply-To: <47D0B211.6000002@199technologies.org>
Message-ID: <47D13FB4.5080306@netphreax.net>

Chris Turner wrote:
Doing a bit of digging here for my long-standing CBB+SIO interupt and 
buffer problem -

one machine I've tested against was an OpenBSD machine, which didn't
always work to handle the cardbus sio card on a PCI cardbus adapter
-

tuning up some of the device flags in:

http://www.openbsd.org/cgi-bin/man.cgi?query=pcibios&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=html 

seems to have alleviated the problem for that os..

I'm just only starting to get up to speed on how DF handles these types 
of things (namely initial PIC / interrupt layout at boot time device 
enumeration), but am wondering if anyone familiar with this area of the 
code has any comments / advice w/r/t the capabilities of the DF bios 
drivers
and the various quirks / fixup mentioned in the link above..

looking to possibly investigate fixing up some of these issues over time.
Our code that handles issues like this (in cases where you're not using 
APICs, just PICs and PIRs) lives in bus/pci/i386/. Not that running 
without APIC support is all that common on modern machines anymore...
--
        Thomas E. Spanjaard
        tgen at netphreax.net
Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00003.pgp
Type: application/octet-stream
Size: 186 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080307/61366b5c/attachment-0008.obj>

From tgen at netphreax.net  Fri Mar  7 05:16:51 2008
From: tgen at netphreax.net (Thomas E. Spanjaard)
Date: Fri, 7 Mar 2008 05:16:51 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Misc. ACPI / suspend
In-Reply-To: <47CA073B.6020106@199technologies.org>
Message-ID: <47D13F07.9080308@netphreax.net>

Chris Turner wrote:
1) does anyone have ACPI (instead of APM)
   sleep / suspend / wakeup working on Dfly ?
2) If so, what machines are being used ?
3) Same question for other BSDs - my understanding is NetBSD is most
   'advanced' w/r/t power managment - but I'm not 100% on this ...
would looove to have a sleeping / resuming / scaling laptop running some 
BSD flavor.. am willing to work towards that end, esp. w/r/t Dfly -
trying to chart a course to figguring this out.
I have ACPI S3 suspend working like a charm on my IBM ThinkPad R40 
(Pentium M "Banias" 1.3GHz, speedstepping works just fine), running 
NetBSD 3.99.21.
--
        Thomas E. Spanjaard
        tgen at netphreax.net
Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00004.pgp
Type: application/octet-stream
Size: 186 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080307/de3e5104/attachment-0008.obj>

From civilizd at gmail.com  Fri Mar  7 09:06:41 2008
From: civilizd at gmail.com (Vita "CiV" Cizek)
Date: Fri, 7 Mar 2008 09:06:41 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <98d564710803070853q1c73d795m6e6c5cc5049fa099@mail.gmail.com>

>  Any student volunteers?  We have mentors.
>
I am interested too, especially in some kernel-related work.




From justin at shiningsilence.com  Sat Mar  8 12:07:51 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Sat, 8 Mar 2008 12:07:51 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google SoC 2008 - mentors mentors mentors
Message-ID: <51558.192.168.0.252.1205006403.squirrel@www.shiningsilence.com>

If you are willing to mentor for the Google 2008 Summer of Code, please
speak up.  Right now we have: (from our wiki page)

Matthias
Sephe
TGEN
corecode

Part of the application process includes naming people as mentors (student
applications come later), so I want to get as complete a list as possible.

The application is due on the 12th, so if you want to mentor, now's the
time to say so.

Google's SoC FAQ is here: http://code.google.com/soc/2008/faqs.html

Our wiki page is here: http://wiki.dragonflybsd.org/index.cgi/GoogleSoC2008

- much credit to Matthias and others for getting that set up.





From saw at online.de  Sat Mar  8 14:26:07 2008
From: saw at online.de (Sascha Wildner)
Date: Sat, 08 Mar 2008 23:26:07 +0100
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <47d31245$0$848$415eb37d@crater_reader.dragonflybsd.org>

Sascha Wildner wrote:
Hi all,

this is probably as good a moment as any to come out of the forest with 
this. The patch at

http://leaf.dragonflybsd.org/~swildner/nrelease_gui.diff
Ok, I have committed the stuff as an example.

I'm not sure if my free time permits to work on a full-blown live CD 
with X11 and other good things (I already feel my interest wandering off 
in other directions) so if anyone wants to pick up the ball, go ahead. :)

Sascha

--
http://yoyodyne.ath.cx



From qhwt+dfly at les.ath.cx  Tue Mar 11 22:21:31 2008
From: qhwt+dfly at les.ath.cx (YONETANI Tomokazu)
Date: Tue, 11 Mar 2008 22:21:31 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Misc. ACPI / suspend
In-Reply-To: <47CA073B.6020106@199technologies.org>
Message-ID: <20080312051219.GA56091@les.ath.cx>

On Thu, Mar 06, 2008 at 10:03:21PM -0500, Chris Turner wrote:
> 1) does anyone have ACPI (instead of APM)
>    sleep / suspend / wakeup working on Dfly ?
> 2) If so, what machines are being used ?

Dynabook SS3500 (http://www.tlt.co.jp/pc/catalog/ss/02110735/index_j.htm).
It's old and can get very hot(thus frequently turns on the cooling fan)
even when it's running Windows.  I haven't turned it on for about several
months though.

Cheers.




From c.turner at 199technologies.org  Wed Mar 12 04:37:22 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Wed, 12 Mar 2008 04:37:22 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Misc. ACPI / suspend
In-Reply-To: <47CA073B.6020106@199technologies.org>
Message-ID: <47D7BEE3.6010907@199technologies.org>

YONETANI Tomokazu wrote:
On Thu, Mar 06, 2008 at 10:03:21PM -0500, Chris Turner wrote:
1) does anyone have ACPI (instead of APM)
   sleep / suspend / wakeup working on Dfly ?
Cheers.
ditto..

Suppose this should go to docs@ - in any case..

Thinking about setting up a wiki page on the issue so we
can discuss / track what 'good' hardware / drivers / implementations / 
etc are 'out there' - anyone have any suggestions on where this should
go?

http://wiki.dragonflybsd.org/index.cgi/acpi-overview.html

Remains from the handbook conversion - but I'm hesitant to 'over wikify'
this ..



From c.turner at 199technologies.org  Wed Mar 12 15:36:52 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Wed, 12 Mar 2008 15:36:52 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: devel/cscope
Message-ID: <47D85A08.8040103@199technologies.org>

why oh why did I take so long to try this out !!!

just sharing my eureka moment with the list..

- Chris




From dudu at dudu.ro  Wed Mar 12 15:50:14 2008
From: dudu at dudu.ro (Vlad GALU)
Date: Wed, 12 Mar 2008 15:50:14 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: devel/cscope
In-Reply-To: <47D85A08.8040103@199technologies.org>
Message-ID: <ad79ad6b0803121547r2bf67ffep9e40badaac6490f8@mail.gmail.com>

On 3/13/08, Chris Turner <c.turner at 199technologies.org> wrote:
> why oh why did I take so long to try this out !!!
>
>  just sharing my eureka moment with the list..


    Works nice with vim, too!

>
>
>  - Chris
>


-- 
Mahnahmahnah!




From justin at shiningsilence.com  Sun Mar 16 21:06:13 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Sun, 16 Mar 2008 21:06:13 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: binary packages for 1.12 coming in
Message-ID: <1372.192.168.0.252.1205726088.squirrel@www.shiningsilence.com>

The binary build for 1.12 is taking quite a while.  I've started copying
in newly built packages to
pkgbox.dragonflybsd.org/packages/DragonFly-1.12/i386/ - this should be
getting copied out to mirrors over the next while.

There are currently 1283 packages built, which leaves a whole lot to go;
I'll copy new packages in as they complete.





From hasso at estpak.ee  Wed Mar 19 04:31:08 2008
From: hasso at estpak.ee (Hasso Tepper)
Date: Wed, 19 Mar 2008 04:31:08 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Some questions regarding ACPI
Message-ID: <200803191322.46366.hasso@estpak.ee>

I'm working on bringing in some laptop (and especially thinkpad) specific 
ACPI code from FreeBSD into DragonFly. I never touched ACPI stuff before 
and haven't followed it much either, so I have some questions.

* FreeBSD uses ACPI_SERIAL_* heavily. What's the locking situation in 
  DragonFly and why?

* As far as I can see, PCI integration is commented out in DragonFly. 
  What's the state of it and why?

* platform/pc32/acpica5/acpi_toshiba.c - why is it there? I don't think 
  that this is something pc32 specific in it and it should work in pc64 
  laptops as well. Any objections to move it into 
  dev/acpica5/acpi_toshiba/ ?

What's the current status of ACPI in general? AFAICS our acpica is quite 
old - what needs to be done to bring in newer one?


-- 
Hasso




From qhwt+dfly at les.ath.cx  Wed Mar 19 09:24:50 2008
From: qhwt+dfly at les.ath.cx (YONETANI Tomokazu)
Date: Wed, 19 Mar 2008 09:24:50 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Some questions regarding ACPI
In-Reply-To: <200803191322.46366.hasso@estpak.ee>
Message-ID: <20080319161703.GA51509@les.ath.cx>

On Wed, Mar 19, 2008 at 01:22:46PM +0200, Hasso Tepper wrote:
> I'm working on bringing in some laptop (and especially thinkpad) specific 
> ACPI code from FreeBSD into DragonFly. I never touched ACPI stuff before 
> and haven't followed it much either, so I have some questions.

So you want to port some of ACPI support drivers, or to do a fresh port
of ACPI driver from FreeBSD?

> * FreeBSD uses ACPI_SERIAL_* heavily. What's the locking situation in 
>   DragonFly and why?

The current ACPI driver in DragonFly is based on that of FreeBSD as of
end of June, 2004, plus some fixes brought in later (and ACPICA part
has been updated twice since then).  That was before they introduced
the MPSAFE changes into ACPI code, and we use critical section
(crit_{enter,exit}) in most places (and lockmgr lock in a few place).

> * As far as I can see, PCI integration is commented out in DragonFly. 
>   What's the state of it and why?

When we replaced the implementation taken from FreeBSD 4.x with that
brought from FreeBSD 5.x, which added the PCI part, many people
experienced problems until they turned off ACPI completely, or add "pci"
to "debug.acpi.disabled" loader variable.  AFAIK the PCI part in the ACPI
driver almost hasn't been adjusted to work with our version of PCI code.

> * platform/pc32/acpica5/acpi_toshiba.c - why is it there? I don't think 
>   that this is something pc32 specific in it and it should work in pc64 
>   laptops as well. Any objections to move it into 
>   dev/acpica5/acpi_toshiba/ ?

In FreeBSD it used to be sitting at i386/acpica/acpi_toshiba.c and was
later moved into acpi_support.  That change hasn't hit our tree (in fact,
we have no acpi support drivers other than that).  It seems that FreeBSD
has them in dev/acpi_support now, and we for some reason have that
directory in our CVS repository (but containing no files in it).

> What's the current status of ACPI in general? AFAICS our acpica is quite 
> old - what needs to be done to bring in newer one?

Actually, it's not very important to keep just ACPICA latest, but
if you bring the ACPI driver from FreeBSD you need to bring ACPICA code
that matches their version, and it IS important.  And it generally requires
you much work to just update ACPICA part anyway because of how they
change things on every release.

Cheers.




From hasso at estpak.ee  Wed Mar 19 12:29:52 2008
From: hasso at estpak.ee (Hasso Tepper)
Date: Wed, 19 Mar 2008 12:29:52 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Some questions regarding ACPI
In-Reply-To: <200803191322.46366.hasso@estpak.ee>
Message-ID: <200803192115.35396.hasso@estpak.ee>

YONETANI Tomokazu wrote:
> On Wed, Mar 19, 2008 at 01:22:46PM +0200, Hasso Tepper wrote:
> > I'm working on bringing in some laptop (and especially thinkpad)
> > specific ACPI code from FreeBSD into DragonFly. I never touched ACPI
> > stuff before and haven't followed it much either, so I have some
> > questions.
>
> So you want to port some of ACPI support drivers, or to do a fresh port
> of ACPI driver from FreeBSD?

I'm only interested in support drivers and the reason is pure practical - 
newer thinkpads handle less and less hotkeys etc in hardware and require 
support form OS. acpi_ibm and acpi_video are examples of such modules 
which would help a lot of these newer thinkpad users.

acpi_ibm is almost ready to commit (renamed to acpi_thinkpad though).

> > * FreeBSD uses ACPI_SERIAL_* heavily. What's the locking situation in
> >   DragonFly and why?
>
> The current ACPI driver in DragonFly is based on that of FreeBSD as of
> end of June, 2004, plus some fixes brought in later (and ACPICA part
> has been updated twice since then).  That was before they introduced
> the MPSAFE changes into ACPI code, and we use critical section
> (crit_{enter,exit}) in most places (and lockmgr lock in a few place).

Mkay. Will look at more closely.

> > * As far as I can see, PCI integration is commented out in DragonFly.
> >   What's the state of it and why?
>
> When we replaced the implementation taken from FreeBSD 4.x with that
> brought from FreeBSD 5.x, which added the PCI part, many people
> experienced problems until they turned off ACPI completely, or add
> "pci" to "debug.acpi.disabled" loader variable.  AFAIK the PCI part in
> the ACPI driver almost hasn't been adjusted to work with our version of
> PCI code.

I'm afraid that it's beyond my skills, but while looking at acpi_video I 
discovered that it's hard to handle correctly without PCI support.

> > * platform/pc32/acpica5/acpi_toshiba.c - why is it there? I don't
> > think that this is something pc32 specific in it and it should work
> > in pc64 laptops as well. Any objections to move it into
> >   dev/acpica5/acpi_toshiba/ ?
>
> In FreeBSD it used to be sitting at i386/acpica/acpi_toshiba.c and was
> later moved into acpi_support.  That change hasn't hit our tree (in
> fact, we have no acpi support drivers other than that).  It seems that
> FreeBSD has them in dev/acpi_support now, and we for some reason have
> that directory in our CVS repository (but containing no files in it).

I don't see it ;). Makes sense though. So, any objections if I move 
acpi_toshiba into sys/dev/acpi_support and add new acpi_thinkpad there as 
well? 

> > What's the current status of ACPI in general? AFAICS our acpica is
> > quite old - what needs to be done to bring in newer one?
>
> Actually, it's not very important to keep just ACPICA latest, but
> if you bring the ACPI driver from FreeBSD you need to bring ACPICA code
> that matches their version, and it IS important.  And it generally
> requires you much work to just update ACPICA part anyway because of how
> they change things on every release.

Someone else has to do it :).

Thanks for info.


-- 
Hasso




From dillon at apollo.backplane.com  Wed Mar 19 14:01:13 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Wed, 19 Mar 2008 14:01:13 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: panic: assertion: hammer_btree_cmp(cursor->left_bound,	&cursor->node->ondisk->elms[0].leaf.base) <= 0 in btree_split_leaf
In-Reply-To: <200802232204.m1NM4cxd046264@apollo.backplane.com>
Message-ID: <200803192054.m2JKsjwn045137@apollo.backplane.com>


:Hi.
:While trying to find a procedure to reliably reproduce the panic
:I reported last time, I caught a different panic (uploaded at
: ~y0netan1/crash/9/ on my leaf account).  I wrote the following shell
:script (make sure to edit variables DISKS and MOUNTPT before using this
:script or it may trash your system):
:  #!/bin/sh -ex
:  DISKS="/dev/ad0s1f"
:  MOUNTPT=/mnt/HAMMER
:
:  cd /
:  newfs_hammer -L TEST $DISKS
:  for i in `seq 1 100`; do
:..
:And the panic is triggered by rm command.
:I'll try to see if it's possible to reproduce the last one without
:unmounting then mounting the HAMMER fs.
:
:Cheers.

    I believe I have fixed this panic.  hammer_make_separator() had a bug
    in it.

    There is still an issue with the node ref count on umount.

    Please continue to life-test the code.  The reblocking code
    (hammer reblock /mnt) should work now, as should the pruning code
    (e.g. hammer prune /mnt everything).

    The filesystem full case is still not handled and will cause bad things
    to happen.  The undo code isn't finished yet either but it is getting
    there (it's writing stuff out but not setting the sequence number and
    not trying to recover-on-mount yet).

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From qhwt+dfly at les.ath.cx  Wed Mar 19 19:45:40 2008
From: qhwt+dfly at les.ath.cx (YONETANI Tomokazu)
Date: Wed, 19 Mar 2008 19:45:40 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Some questions regarding ACPI
In-Reply-To: <200803191322.46366.hasso@estpak.ee>
Message-ID: <20080320023828.GA53648@les.ath.cx>

On Wed, Mar 19, 2008 at 09:15:35PM +0200, Hasso Tepper wrote:
> YONETANI Tomokazu wrote:
> > On Wed, Mar 19, 2008 at 01:22:46PM +0200, Hasso Tepper wrote:
> > > I'm working on bringing in some laptop (and especially thinkpad)
> > > specific ACPI code from FreeBSD into DragonFly. I never touched ACPI
> > > stuff before and haven't followed it much either, so I have some
> > > questions.
> >
> > So you want to port some of ACPI support drivers, or to do a fresh port
> > of ACPI driver from FreeBSD?
> 
> I'm only interested in support drivers and the reason is pure practical - 
> newer thinkpads handle less and less hotkeys etc in hardware and require 
> support form OS. acpi_ibm and acpi_video are examples of such modules 
> which would help a lot of these newer thinkpad users.
> 
> acpi_ibm is almost ready to commit (renamed to acpi_thinkpad though).

Ah, that's a good news!  My only concern is that ISTR someone mentioned
me that his colleague was thinking about porting ACPI driver itself,
so if you're not the person you may want to collaborate with him/her
so as not to waste the effort or time...

			:

> > In FreeBSD it used to be sitting at i386/acpica/acpi_toshiba.c and was
> > later moved into acpi_support.  That change hasn't hit our tree (in
> > fact, we have no acpi support drivers other than that).  It seems that
> > FreeBSD has them in dev/acpi_support now, and we for some reason have
> > that directory in our CVS repository (but containing no files in it).
> 
> I don't see it ;). Makes sense though. So, any objections if I move 
> acpi_toshiba into sys/dev/acpi_support and add new acpi_thinkpad there as 
> well? 

Sorry, I checked the CVS repository and it doesn't exist actually :)
I don't have any objection to moving it there.

Cheers.




From hasso at estpak.ee  Thu Mar 20 00:14:05 2008
From: hasso at estpak.ee (Hasso Tepper)
Date: Thu, 20 Mar 2008 00:14:05 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Some questions regarding ACPI
In-Reply-To: <200803191322.46366.hasso@estpak.ee>
Message-ID: <200803200904.50875.hasso@estpak.ee>

YONETANI Tomokazu wrote:
> On Wed, Mar 19, 2008 at 09:15:35PM +0200, Hasso Tepper wrote:
> > acpi_ibm is almost ready to commit (renamed to acpi_thinkpad though).
>
> Ah, that's a good news!  My only concern is that ISTR someone mentioned
> me that his colleague was thinking about porting ACPI driver itself,
> so if you're not the person you may want to collaborate with him/her
> so as not to waste the effort or time...

Current state in my repo is attached. It should work on 1.12 as well as it 
doesn't depend yet on moving stuff around.

add-acpi-if-m.patch adds some new stuff to the ACPI code to access 
embedded controllers and match ACPI devices by ID. Not sure how, where 
and whether at all these should be documented.

add-acpi-thinkpad.patch is the driver itself. Note that some stuff doesn't 
work yet on newer thinkpads, I plan to work on it later.

There is still some things to do though. I have to decide what to do with 
led(4) part and with locking. There is also one fatal issue - laptop 
locks up hardly (no panic) while unloading module. Any idea regarding 
this is welcome. And of course test results :).


-- 
Hasso
# HG changeset patch
# User Hasso Tepper <hasso at estpak.ee>
# Date 1205919290 -7200
# Branch HEAD
# Node ID 5a6e2705cc95a340abf973ae5df73ef34e070b79
# Parent  cd529e2e7f849034d5d5a0973cb98af50db0e797
imported patch adding-acpi-if-m.patch

diff --git a/sys/conf/files b/sys/conf/files
--- a/sys/conf/files
+++ b/sys/conf/files
@@ -1387,6 +1387,7 @@ emulation/dragonfly12/dfbsd12_stat.c	non
 ${OSACPI_MI_DIR}/acpi_cmbat.c		optional acpi
 ${OSACPI_MI_DIR}/acpi_cpu.c		optional acpi
 ${OSACPI_MI_DIR}/acpi_ec.c		optional acpi
+${OSACPI_MI_DIR}/acpi_if.m		optional acpi
 ${OSACPI_MI_DIR}/acpi_isab.c		optional acpi isa
 ${OSACPI_MI_DIR}/acpi_lid.c		optional acpi
 ${OSACPI_MI_DIR}/acpi_package.c		optional acpi
diff --git a/sys/conf/kmod.mk b/sys/conf/kmod.mk
--- a/sys/conf/kmod.mk
+++ b/sys/conf/kmod.mk
@@ -275,7 +275,7 @@ MFILES?= kern/bus_if.m kern/device_if.m 
     bus/pccard/card_if.m bus/pccard/power_if.m bus/pci/pci_if.m \
     bus/pci/pcib_if.m \
     bus/ppbus/ppbus_if.m bus/smbus/smbus_if.m bus/usb/usb_if.m \
-    dev/disk/nata/ata_if.m \
+    dev/acpica5/acpi_if.m dev/disk/nata/ata_if.m \
     dev/sound/pcm/ac97_if.m dev/sound/pcm/channel_if.m \
     dev/sound/pcm/feeder_if.m dev/sound/pcm/mixer_if.m \
     libiconv/iconv_converter_if.m dev/agp/agp_if.m opencrypto/crypto_if.m
diff --git a/sys/dev/acpica5/Makefile b/sys/dev/acpica5/Makefile
--- a/sys/dev/acpica5/Makefile
+++ b/sys/dev/acpica5/Makefile
@@ -69,12 +69,14 @@ SRCS+=  acpi_package.c
 # SRCS+=	acpi_pci.c acpi_pcib.c acpi_pcib_acpi.c acpi_pcib_pci.c
 # SRCS+=	acpi_pci_link.c
 SRCS+=  acpi_powerres.c acpi_resource.c acpi_thermal.c
-SRCS+=  acpi_timer.c
+SRCS+=  acpi_timer.c acpi_if.c
 SRCS+=  OsdDebug.c
 SRCS+=  OsdHardware.c OsdInterface.c OsdInterrupt.c OsdMemory.c OsdSchedule.c
 SRCS+=  OsdStream.c OsdSynch.c OsdTable.c OsdEnvironment.c
 SRCS+=  opt_acpi.h opt_bus.h opt_ddb.h
-SRCS+=  device_if.h bus_if.h pci_if.h pcib_if.h isa_if.h
+SRCS+=  device_if.h bus_if.h pci_if.h pcib_if.h isa_if.h acpi_if.h
+MFILES = kern/device_if.m kern/bus_if.m bus/pci/pci_if.m bus/pci/pcib_if.m
+MFILES+= bus/isa/isa_if.m dev/acpica5/acpi_if.m
 
 # Debugging support
 DBSRC=	dbcmds.c dbdisply.c dbexec.c dbfileio.c dbhistry.c
diff --git a/sys/dev/acpica5/acpi.c b/sys/dev/acpica5/acpi.c
--- a/sys/dev/acpica5/acpi.c
+++ b/sys/dev/acpica5/acpi.c
@@ -135,6 +135,7 @@ static int	acpi_release_resource(device_
 			int rid, struct resource *r);
 static uint32_t	acpi_isa_get_logicalid(device_t dev);
 static int	acpi_isa_get_compatid(device_t dev, uint32_t *cids, int count);
+static char	*acpi_device_id_probe(device_t bus, device_t dev, char **ids);
 static int	acpi_isa_pnp_probe(device_t bus, device_t child,
 			struct isa_pnp_id *ids);
 static void	acpi_probe_children(device_t bus);
@@ -189,6 +190,9 @@ static device_method_t acpi_methods[] = 
     DEVMETHOD(bus_deactivate_resource,	bus_generic_deactivate_resource),
     DEVMETHOD(bus_setup_intr,		bus_generic_setup_intr),
     DEVMETHOD(bus_teardown_intr,	bus_generic_teardown_intr),
+
+    /* ACPI bus */
+    DEVMETHOD(acpi_id_probe,		acpi_device_id_probe),
 
     /* ISA emulation */
     DEVMETHOD(isa_pnp_probe,		acpi_isa_pnp_probe),
@@ -1121,6 +1125,24 @@ out:
 	AcpiOsFree(buf.Pointer);
     ACPI_UNLOCK;
     return_VALUE (valid);
+}
+
+static char *
+acpi_device_id_probe(device_t bus, device_t dev, char **ids) 
+{
+    ACPI_HANDLE h;
+    int i;
+
+    h = acpi_get_handle(dev);
+    if (ids == NULL || h == NULL || acpi_get_type(dev) != ACPI_TYPE_DEVICE)
+	return (NULL);
+
+    /* Try to match one of the array of IDs with a HID or CID. */
+    for (i = 0; ids[i] != NULL; i++) {
+	if (acpi_MatchHid(h, ids[i]))
+	    return (ids[i]);
+    }
+    return (NULL);
 }
 
 static int
diff --git a/sys/dev/acpica5/acpi_ec.c b/sys/dev/acpica5/acpi_ec.c
--- a/sys/dev/acpica5/acpi_ec.c
+++ b/sys/dev/acpica5/acpi_ec.c
@@ -327,11 +327,19 @@ static ACPI_STATUS	EcWrite(struct acpi_e
 				UINT8 *Data);
 static int		acpi_ec_probe(device_t dev);
 static int		acpi_ec_attach(device_t dev);
+static int		acpi_ec_read_method(device_t dev, u_int addr,
+				ACPI_INTEGER *val, int width);
+static int		acpi_ec_write_method(device_t dev, u_int addr,
+				ACPI_INTEGER val, int width);
 
 static device_method_t acpi_ec_methods[] = {
     /* Device interface */
     DEVMETHOD(device_probe,	acpi_ec_probe),
     DEVMETHOD(device_attach,	acpi_ec_attach),
+
+    /* Embedded controller interface */
+    DEVMETHOD(acpi_ec_read,     acpi_ec_read_method),
+    DEVMETHOD(acpi_ec_write,    acpi_ec_write_method),
 
     {0, 0}
 };
@@ -620,6 +628,33 @@ error:
 			     sc->ec_data_res);
     /* mtx_destroy(&sc->ec_mtx); */
     return (ENXIO);
+}
+
+/* Methods to allow other devices (e.g., smbat) to read/write EC space. */
+static int
+acpi_ec_read_method(device_t dev, u_int addr, ACPI_INTEGER *val, int width)
+{
+    struct acpi_ec_softc *sc;
+    ACPI_STATUS status;
+
+    sc = device_get_softc(dev);
+    status = EcSpaceHandler(ACPI_READ, addr, width * 8, val, sc, NULL);
+    if (ACPI_FAILURE(status))
+        return (ENXIO);
+    return (0);
+}
+
+static int
+acpi_ec_write_method(device_t dev, u_int addr, ACPI_INTEGER val, int width)
+{
+    struct acpi_ec_softc *sc;
+    ACPI_STATUS status;
+
+    sc = device_get_softc(dev);
+    status = EcSpaceHandler(ACPI_WRITE, addr, width * 8, &val, sc, NULL);
+    if (ACPI_FAILURE(status))
+        return (ENXIO);
+    return (0);
 }
 
 static void
diff --git a/sys/dev/acpica5/acpi_if.m b/sys/dev/acpica5/acpi_if.m
new file mode 100644
--- /dev/null
+++ b/sys/dev/acpica5/acpi_if.m
@@ -0,0 +1,92 @@
+#-
+# Copyright (c) 2004 Nate Lawson
+# All rights reserved.
+#
+# Redistribution and use in source and binary forms, with or without
+# modification, are permitted provided that the following conditions
+# are met:
+# 1. Redistributions of source code must retain the above copyright
+#    notice, this list of conditions and the following disclaimer.
+# 2. Redistributions in binary form must reproduce the above copyright
+#    notice, this list of conditions and the following disclaimer in the
+#    documentation and/or other materials provided with the distribution.
+#
+# THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
+# ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+# ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
+# FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+# DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+# OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+# HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+# LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+# OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+# SUCH DAMAGE.
+#
+# $DragonFly$
+#
+
+#include <sys/bus.h>
+#include <sys/types.h>
+#include "acpi.h"
+
+INTERFACE acpi;
+
+#
+# Default implementation for acpi_id_probe().
+#
+CODE {
+	static char *
+	acpi_generic_id_probe(device_t bus, device_t dev, char **ids)
+	{
+		return (NULL);
+	}
+};
+
+#
+# Check a device for a match in a list of ID strings.  The strings can be
+# EISA PNP IDs or ACPI _HID/_CID values.
+#
+# device_t bus:  parent bus for the device
+#
+# device_t dev:  device being considered
+#
+# char **ids:  array of ID strings to consider
+#
+# Returns:  ID string matched or NULL if no match
+#
+METHOD char * id_probe {
+	device_t	bus;
+	device_t	dev;
+	char		**ids;
+} DEFAULT acpi_generic_id_probe;
+
+#
+# Read embedded controller (EC) address space
+#
+# device_t dev:  EC device
+# u_int addr:  Address to read from in EC space
+# ACPI_INTEGER *val:  Location to store read value
+# int width:  Size of area to read in bytes
+#
+METHOD int ec_read {
+	device_t	dev;
+	u_int		addr;
+	ACPI_INTEGER	*val;
+	int		width;
+};
+
+#
+# Write embedded controller (EC) address space
+#
+# device_t dev:  EC device
+# u_int addr:  Address to write to in EC space
+# ACPI_INTEGER val:  Value to write
+# int width:  Size of value to write in bytes
+#
+METHOD int ec_write {
+	device_t	dev;
+	u_int		addr;
+	ACPI_INTEGER	val;
+	int		width;
+};
diff --git a/sys/dev/acpica5/acpivar.h b/sys/dev/acpica5/acpivar.h
--- a/sys/dev/acpica5/acpivar.h
+++ b/sys/dev/acpica5/acpivar.h
@@ -29,6 +29,7 @@
  * $DragonFly: src/sys/dev/acpica5/acpivar.h,v 1.12 2007/10/23 03:04:48 y0netan1 Exp $
  */
 
+#include "acpi_if.h"
 #include "bus_if.h"
 #include <sys/eventhandler.h>
 #include <sys/sysctl.h>
# HG changeset patch
# User Hasso Tepper <hasso at estpak.ee>
# Date 1205995474 -7200
# Branch HEAD
# Node ID c5db8d4a7c6b25a8576a8d42c5029aaf0e23bfb6
# Parent  5a6e2705cc95a340abf973ae5df73ef34e070b79
[mq]: adding-acpi-thinkpad.patch

diff --git a/sys/dev/acpica5/Makefile b/sys/dev/acpica5/Makefile
--- a/sys/dev/acpica5/Makefile
+++ b/sys/dev/acpica5/Makefile
@@ -117,7 +117,7 @@ acpi_wakecode.h: acpi_wakecode.S
 	${MAKE} -f ${SYSDIR}/${OSACPI_MD_DIR}/Makefile \
 		MAKESRCPATH=${SYSDIR}/${OSACPI_MD_DIR}
 
-SUBDIR=	acpi_toshiba
+SUBDIR=	acpi_toshiba acpi_thinkpad
 all: ${PROG} ${SUBDIR}
 
 # *.o file for each patched *.c file is created under the same directory,
diff --git a/sys/dev/acpica5/acpi_thinkpad/Makefile b/sys/dev/acpica5/acpi_thinkpad/Makefile
new file mode 100644
--- /dev/null
+++ b/sys/dev/acpica5/acpi_thinkpad/Makefile
@@ -0,0 +1,9 @@
+# $DragonFly$
+
+SYSDIR?=${.CURDIR}/../../..
+
+KMOD=		acpi_thinkpad
+CFLAGS+=	-I${.OBJDIR}/.. -I${.CURDIR}/..
+SRCS=		acpi_thinkpad.c opt_acpi.h device_if.h bus_if.h
+
+.include <bsd.kmod.mk>
diff --git a/sys/dev/acpica5/acpi_thinkpad/acpi_thinkpad.c b/sys/dev/acpica5/acpi_thinkpad/acpi_thinkpad.c
new file mode 100644
--- /dev/null
+++ b/sys/dev/acpica5/acpi_thinkpad/acpi_thinkpad.c
@@ -0,0 +1,1046 @@
+/*
+ * Copyright (c) 2004 Takanori Watanabe
+ * Copyright (c) 2005 Markus Brueffer <markus at FreeBSD.org>
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *    notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *    notice, this list of conditions and the following disclaimer in the
+ *    documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+ */
+
+/*
+ * Driver for extra ACPI-controlled gadgets found on IBM and Lenovo ThinkPad
+ * laptops. Inspired by the ibm-acpi and tpb projects which implement these
+ * features on Linux.
+ *
+ *   acpi-ibm: <http://ibm-acpi.sourceforge.net/>
+ *        tpb: <http://www.nongnu.org/tpb/>
+ */
+
+#include "opt_acpi.h"
+#include <sys/param.h>
+#include <sys/kernel.h>
+#include <sys/bus.h>
+#include <machine/cpufunc.h>
+#include <sys/module.h>
+/* #include <dev/led/led.h> */
+#include <sys/sensors.h>
+#include <sys/sysctl.h>
+#include <machine/clock.h>
+
+#include "acpi.h"
+#include "acpivar.h"
+#include "acpi_if.h"
+
+#define _COMPONENT	ACPI_OEM
+ACPI_MODULE_NAME("THINKPAD")
+
+/* Internal methods */
+#define ACPI_THINKPAD_METHOD_EVENTS		1
+#define ACPI_THINKPAD_METHOD_EVENTMASK		2
+#define ACPI_THINKPAD_METHOD_HOTKEY		3
+#define ACPI_THINKPAD_METHOD_BRIGHTNESS		4
+#define ACPI_THINKPAD_METHOD_VOLUME		5
+#define ACPI_THINKPAD_METHOD_MUTE		6
+#define ACPI_THINKPAD_METHOD_THINKLIGHT		7
+#define ACPI_THINKPAD_METHOD_BLUETOOTH		8
+#define ACPI_THINKPAD_METHOD_WLAN		9
+#define ACPI_THINKPAD_METHOD_FANSPEED		10
+#define ACPI_THINKPAD_METHOD_FANLEVEL		11
+#define ACPI_THINKPAD_METHOD_FANSTATUS		12
+#define ACPI_THINKPAD_METHOD_THERMAL		13
+
+/* Hotkeys/Buttons */
+#define THINKPAD_RTC_HOTKEY1			0x64
+#define   THINKPAD_RTC_MASK_HOME		(1 << 0)
+#define   THINKPAD_RTC_MASK_SEARCH		(1 << 1)
+#define   THINKPAD_RTC_MASK_MAIL		(1 << 2)
+#define   THINKPAD_RTC_MASK_WLAN		(1 << 5)
+#define THINKPAD_RTC_HOTKEY2			0x65
+#define   THINKPAD_RTC_MASK_THINKPAD		(1 << 3)
+#define   THINKPAD_RTC_MASK_ZOOM		(1 << 5)
+#define   THINKPAD_RTC_MASK_VIDEO		(1 << 6)
+#define   THINKPAD_RTC_MASK_HIBERNATE		(1 << 7)
+#define THINKPAD_RTC_THINKLIGHT			0x66
+#define   THINKPAD_RTC_MASK_THINKLIGHT		(1 << 4)
+#define THINKPAD_RTC_SCREENEXPAND		0x67
+#define   THINKPAD_RTC_MASK_SCREENEXPAND	(1 << 5)
+#define THINKPAD_RTC_BRIGHTNESS			0x6c
+#define   THINKPAD_RTC_MASK_BRIGHTNESS		(1 << 5)
+#define THINKPAD_RTC_VOLUME			0x6e
+#define   THINKPAD_RTC_MASK_VOLUME		(1 << 7)
+
+/* Embedded Controller registers */
+#define THINKPAD_EC_BRIGHTNESS			0x31
+#define   THINKPAD_EC_MASK_BRI			0x7
+#define THINKPAD_EC_VOLUME			0x30
+#define   THINKPAD_EC_MASK_VOL			0xf
+#define   THINKPAD_EC_MASK_MUTE			(1 << 6)
+#define THINKPAD_EC_FANSTATUS			0x2F
+#define   THINKPAD_EC_MASK_FANLEVEL		0x3f
+#define   THINKPAD_EC_MASK_FANDISENGAGED	(1 << 6)
+#define   THINKPAD_EC_MASK_FANSTATUS		(1 << 7)
+#define THINKPAD_EC_FANSPEED			0x84
+
+/* CMOS Commands */
+#define THINKPAD_CMOS_VOLUME_DOWN		0
+#define THINKPAD_CMOS_VOLUME_UP			1
+#define THINKPAD_CMOS_VOLUME_MUTE		2
+#define THINKPAD_CMOS_BRIGHTNESS_UP		4
+#define THINKPAD_CMOS_BRIGHTNESS_DOWN		5
+
+/* ACPI methods */
+#define THINKPAD_NAME_KEYLIGHT			"KBLT"
+#define THINKPAD_NAME_WLAN_BT_GET		"GBDC"
+#define THINKPAD_NAME_WLAN_BT_SET		"SBDC"
+#define   THINKPAD_NAME_MASK_BT			(1 << 1)
+#define   THINKPAD_NAME_MASK_WLAN		(1 << 2)
+#define THINKPAD_NAME_THERMAL_GET		"TMP7"
+#define THINKPAD_NAME_THERMAL_UPDT		"UPDT"
+
+#define THINKPAD_NAME_EVENTS_STATUS_GET		"DHKC"
+#define THINKPAD_NAME_EVENTS_MASK_GET		"DHKN"
+#define THINKPAD_NAME_EVENTS_STATUS_SET		"MHKC"
+#define THINKPAD_NAME_EVENTS_MASK_SET		"MHKM"
+#define THINKPAD_NAME_EVENTS_GET		"MHKP"
+#define THINKPAD_NAME_EVENTS_AVAILMASK		"MHKA"
+
+#define ABS(x) (((x) < 0)? -(x) : (x))
+
+struct acpi_thinkpad_softc {
+	device_t	dev;
+	ACPI_HANDLE	handle;
+
+	/* Embedded controller */
+	device_t	ec_dev;
+	ACPI_HANDLE	ec_handle;
+
+	/* CMOS */
+	ACPI_HANDLE	cmos_handle;
+
+	/* Fan status */
+	ACPI_HANDLE	fan_handle;
+	int		fan_levels;
+
+	/* Keylight commands and states */
+	ACPI_HANDLE	light_handle;
+	int		light_cmd_on;
+	int		light_cmd_off;
+	int		light_val;
+	int		light_get_supported;
+	int		light_set_supported;
+
+	/* led(4) interface */
+	struct cdev	*led_dev;
+	int		led_busy;
+	int		led_state;
+
+	int		wlan_bt_flags;
+	int		thermal_updt_supported;
+
+	unsigned int	events_availmask;
+	unsigned int	events_initialmask;
+	int		events_mask_supported;
+	int		events_enable;
+
+	/* sensors(9) related */
+	struct ksensordev sensordev;
+	struct ksensor sensors[9];	/* XXX: 8 thermal + fan */
+
+	struct sysctl_ctx_list	*sysctl_ctx;
+	struct sysctl_oid	*sysctl_tree;
+};
+
+static struct {
+	char	*name;
+	int	method;
+	char	*description;
+	int	access;
+} acpi_thinkpad_sysctls[] = {
+	{
+		.name		= "events",
+		.method		= ACPI_THINKPAD_METHOD_EVENTS,
+		.description	= "ACPI events enable",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "eventmask",
+		.method		= ACPI_THINKPAD_METHOD_EVENTMASK,
+		.description	= "ACPI eventmask",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "hotkey",
+		.method		= ACPI_THINKPAD_METHOD_HOTKEY,
+		.description	= "Key Status",
+		.access		= CTLTYPE_INT | CTLFLAG_RD
+	},
+	{
+		.name		= "lcd_brightness",
+		.method		= ACPI_THINKPAD_METHOD_BRIGHTNESS,
+		.description	= "LCD Brightness",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "volume",
+		.method		= ACPI_THINKPAD_METHOD_VOLUME,
+		.description	= "Volume",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "mute",
+		.method		= ACPI_THINKPAD_METHOD_MUTE,
+		.description	= "Mute",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "thinklight",
+		.method		= ACPI_THINKPAD_METHOD_THINKLIGHT,
+		.description	= "Thinklight enable",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "bluetooth",
+		.method		= ACPI_THINKPAD_METHOD_BLUETOOTH,
+		.description	= "Bluetooth enable",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "wlan",
+		.method		= ACPI_THINKPAD_METHOD_WLAN,
+		.description	= "WLAN enable",
+		.access		= CTLTYPE_INT | CTLFLAG_RD
+	},
+	{
+		.name		= "fan_level",
+		.method		= ACPI_THINKPAD_METHOD_FANLEVEL,
+		.description	= "Fan level",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "fan",
+		.method		= ACPI_THINKPAD_METHOD_FANSTATUS,
+		.description	= "Fan enable",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+
+	{ NULL, 0, NULL, 0 }
+};
+
+/* ACPI_SERIAL_DECL(thinkpad, "ACPI THINKPAD extras"); */
+static int	acpi_thinkpad_probe(device_t dev);
+static int	acpi_thinkpad_attach(device_t dev);
+static int	acpi_thinkpad_detach(device_t dev);
+
+#if 0 /* not yet */
+static void	thinkpad_led(void *softc, int onoff);
+static void	thinkpad_led_task(struct acpi_thinkpad_softc *sc,
+		int pending __unused);
+#endif
+
+static int	acpi_thinkpad_sysctl(SYSCTL_HANDLER_ARGS);
+static int	acpi_thinkpad_sysctl_init(struct acpi_thinkpad_softc *sc,
+		int method);
+static int	acpi_thinkpad_sysctl_get(struct acpi_thinkpad_softc *sc,
+		int method);
+static int	acpi_thinkpad_sysctl_set(struct acpi_thinkpad_softc *sc,
+		int method, int val);
+
+static int	acpi_thinkpad_eventmask_set(struct acpi_thinkpad_softc *sc,
+		int val);
+static void	acpi_thinkpad_notify(ACPI_HANDLE h, UINT32 notify,
+		void *context);
+static void	acpi_thinkpad_refresh(void *);
+
+static device_method_t acpi_thinkpad_methods[] = {
+	/* Device interface */
+	DEVMETHOD(device_probe, acpi_thinkpad_probe),
+	DEVMETHOD(device_attach, acpi_thinkpad_attach),
+	DEVMETHOD(device_detach, acpi_thinkpad_detach),
+	{0, 0}
+};
+
+static driver_t	acpi_thinkpad_driver = {
+	"acpi_thinkpad",
+	acpi_thinkpad_methods,
+	sizeof(struct acpi_thinkpad_softc),
+};
+
+static devclass_t acpi_thinkpad_devclass;
+
+DRIVER_MODULE(acpi_thinkpad, acpi, acpi_thinkpad_driver,
+    acpi_thinkpad_devclass, 0, 0);
+MODULE_DEPEND(acpi_thinkpad, acpi, 1, 1, 1);
+static char    *thinkpad_ids[] = {"IBM0068", NULL};
+
+#if 0 /* not yet */
+static void
+thinkpad_led(void *softc, int onoff)
+{
+	struct acpi_thinkpad_softc* sc = (struct acpi_thinkpad_softc*) softc;
+
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+
+	if (sc->led_busy)
+		return;
+
+	sc->led_busy = 1;
+	sc->led_state = onoff;
+
+	AcpiOsExecute(OSL_NOTIFY_HANDLER, (void *)thinkpad_led_task, sc);
+}
+
+static void
+thinkpad_led_task(struct acpi_thinkpad_softc *sc, int pending __unused)
+{
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+
+	/* ACPI_SERIAL_BEGIN(thinkpad); */
+	acpi_thinkpad_sysctl_set(sc, ACPI_THINKPAD_METHOD_THINKLIGHT, sc->led_state);
+	/* ACPI_SERIAL_END(thinkpad); */
+
+	sc->led_busy = 0;
+}
+#endif
+
+static int
+acpi_thinkpad_probe(device_t dev)
+{
+	if (acpi_disabled("thinkpad") ||
+	    ACPI_ID_PROBE(device_get_parent(dev), dev, thinkpad_ids) == NULL ||
+	    device_get_unit(dev) != 0) 
+		return (ENXIO);
+
+	device_set_desc(dev, "IBM/Lenovo ThinkPad ACPI Extras");
+	return (0);
+}
+
+static int
+acpi_thinkpad_attach(device_t dev)
+{
+	struct acpi_thinkpad_softc	*sc;
+	struct acpi_softc	*acpi_sc;
+	devclass_t		ec_devclass;
+	int			i;
+
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t) __func__);
+
+	sc = device_get_softc(dev);
+	sc->dev = dev;
+	sc->handle = acpi_get_handle(dev);
+
+	acpi_sc = acpi_device_get_parent_softc(dev);
+
+	/* Look for the first embedded controller */
+        if (!(ec_devclass = devclass_find ("acpi_ec"))) {
+		if (bootverbose)
+			device_printf(dev, "Couldn't find acpi_ec devclass\n");
+		return (EINVAL);
+	}
+        if (!(sc->ec_dev = devclass_get_device(ec_devclass, 0))) {
+		if (bootverbose)
+			device_printf(dev, "Couldn't find acpi_ec device\n");
+		return (EINVAL);
+	}
+	sc->ec_handle = acpi_get_handle(sc->ec_dev);
+
+	/* ACPI_SERIAL_BEGIN(thinkpad); */
+
+#if 0
+	/* Get the sysctl tree */
+	sc->sysctl_ctx = device_get_sysctl_ctx(dev);
+	sc->sysctl_tree = device_get_sysctl_tree(dev);
+#endif
+	sysctl_ctx_init(sc->sysctl_ctx);
+	sc->sysctl_tree = SYSCTL_ADD_NODE(sc->sysctl_ctx,
+	    SYSCTL_CHILDREN(acpi_sc->acpi_sysctl_tree), OID_AUTO,
+	    "thinkpad", CTLFLAG_RD, 0, "");
+
+	/* Look for event mask and hook up the nodes */
+	sc->events_mask_supported = ACPI_SUCCESS(acpi_GetInteger(sc->handle,
+	    THINKPAD_NAME_EVENTS_MASK_GET, &sc->events_initialmask));
+
+	if (sc->events_mask_supported) {
+		SYSCTL_ADD_INT(sc->sysctl_ctx,
+		    SYSCTL_CHILDREN(sc->sysctl_tree), OID_AUTO,
+		    "initialmask", CTLFLAG_RD,
+		    &sc->events_initialmask, 0, "Initial eventmask");
+
+		/* The availmask is the bitmask of supported events */
+		if (ACPI_FAILURE(acpi_GetInteger(sc->handle,
+		    THINKPAD_NAME_EVENTS_AVAILMASK, &sc->events_availmask)))
+			sc->events_availmask = 0xffffffff;
+
+		SYSCTL_ADD_INT(sc->sysctl_ctx,
+		    SYSCTL_CHILDREN(sc->sysctl_tree), OID_AUTO,
+		    "availmask", CTLFLAG_RD,
+		    &sc->events_availmask, 0, "Mask of supported events");
+	}
+
+	/* Hook up proc nodes */
+	for (i = 0; acpi_thinkpad_sysctls[i].name != NULL; i++) {
+		if (!acpi_thinkpad_sysctl_init(sc,
+		    acpi_thinkpad_sysctls[i].method))
+			continue;
+
+		SYSCTL_ADD_PROC(sc->sysctl_ctx,
+		    SYSCTL_CHILDREN(sc->sysctl_tree), OID_AUTO,
+		    acpi_thinkpad_sysctls[i].name,
+		    acpi_thinkpad_sysctls[i].access,
+		    sc, i, acpi_thinkpad_sysctl, "I",
+		    acpi_thinkpad_sysctls[i].description);
+	}
+
+	/* ACPI_SERIAL_END(thinkpad); */
+
+	/* Handle notifies */
+	AcpiInstallNotifyHandler(sc->handle, ACPI_DEVICE_NOTIFY,
+	    acpi_thinkpad_notify, dev);
+
+#if 0
+	/* Hook up light to led(4) */
+	if (sc->light_set_supported)
+		sc->led_dev = led_create_state(thinkpad_led, sc, "thinklight",
+		    sc->light_val);
+#endif
+	/* Attach sensors(9). */
+	if (sensor_task_register(sc, acpi_thinkpad_refresh, 5)) {
+		device_printf(sc->dev, "unable to register update task\n");
+		return 1;
+	}
+
+	strlcpy(sc->sensordev.xname, device_get_nameunit(sc->dev),
+	    sizeof(sc->sensordev.xname));
+
+	/* XXX: Temp sensors */
+	for (i = 0; i < 8; ++i) {
+		sc->sensors[i].type = SENSOR_TEMP;
+		sensor_attach(&sc->sensordev, &sc->sensors[i]);
+	}
+	
+	/* Fan RPM sensor */
+	sc->sensors[8].type = SENSOR_FANRPM;
+	sensor_attach(&sc->sensordev, &sc->sensors[8]);
+
+	sensordev_install(&sc->sensordev);
+
+	return (0);
+}
+
+static int
+acpi_thinkpad_detach(device_t dev)
+{
+	int i;
+
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t) __func__);
+
+	struct acpi_thinkpad_softc *sc = device_get_softc(dev);
+
+	/* Disable events and restore eventmask */
+	/* ACPI_SERIAL_BEGIN(thinkpad); */
+	acpi_thinkpad_sysctl_set(sc, ACPI_THINKPAD_METHOD_EVENTS, 0);
+	acpi_thinkpad_sysctl_set(sc, ACPI_THINKPAD_METHOD_EVENTMASK,
+	    sc->events_initialmask);
+	/* ACPI_SERIAL_END(thinkpad); */
+
+	AcpiRemoveNotifyHandler(sc->handle, ACPI_DEVICE_NOTIFY,
+	    acpi_thinkpad_notify);
+
+	sysctl_ctx_free(sc->sysctl_ctx);
+
+#if 0
+	if (sc->led_dev != NULL)
+		led_destroy(sc->led_dev);
+#endif
+	sensordev_deinstall(&sc->sensordev);
+	for (i = 0; i < 9; i++)
+		sensor_detach(&sc->sensordev, &sc->sensors[i]);
+	sensor_task_unregister(sc);
+
+	return (0);
+}
+
+static int
+acpi_thinkpad_eventmask_set(struct acpi_thinkpad_softc *sc, int val)
+{
+	int i;
+	ACPI_OBJECT		arg[2];
+	ACPI_OBJECT_LIST	args;
+	ACPI_STATUS		status;
+
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+	/* ACPI_SERIAL_ASSERT(thinkpad); */
+
+	args.Count = 2;
+	args.Pointer = arg;
+	arg[0].Type = ACPI_TYPE_INTEGER;
+	arg[1].Type = ACPI_TYPE_INTEGER;
+
+	for (i = 0; i < 32; ++i) {
+		arg[0].Integer.Value = i+1;
+		arg[1].Integer.Value = (((1 << i) & val) != 0);
+		status = AcpiEvaluateObject(sc->handle,
+		    THINKPAD_NAME_EVENTS_MASK_SET, &args, NULL);
+
+		if (ACPI_FAILURE(status))
+			return (status);
+	}
+
+	return (0);
+}
+
+static int
+acpi_thinkpad_sysctl(SYSCTL_HANDLER_ARGS)
+{
+	struct acpi_thinkpad_softc	*sc;
+	int			arg;
+	int			error = 0;
+	int			function;
+	int			method;
+	
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+
+	sc = (struct acpi_thinkpad_softc *)oidp->oid_arg1;
+	function = oidp->oid_arg2;
+	method = acpi_thinkpad_sysctls[function].method;
+
+	/* ACPI_SERIAL_BEGIN(thinkpad); */
+	arg = acpi_thinkpad_sysctl_get(sc, method);
+	error = sysctl_handle_int(oidp, &arg, 0, req);
+
+	/* Sanity check */
+	if (error != 0 || req->newptr == NULL)
+		goto out;
+
+	/* Update */
+	error = acpi_thinkpad_sysctl_set(sc, method, arg);
+
+out:
+	/* ACPI_SERIAL_END(thinkpad); */
+	return (error);
+}
+
+static int
+acpi_thinkpad_sysctl_get(struct acpi_thinkpad_softc *sc, int method)
+{
+	ACPI_INTEGER	val_ec;
+	int 		val = 0, key;
+
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+	/* ACPI_SERIAL_ASSERT(thinkpad); */
+
+	switch (method) {
+	case ACPI_THINKPAD_METHOD_EVENTS:
+		acpi_GetInteger(sc->handle, THINKPAD_NAME_EVENTS_STATUS_GET,
+		    &val);
+		break;
+
+	case ACPI_THINKPAD_METHOD_EVENTMASK:
+		if (sc->events_mask_supported)
+			acpi_GetInteger(sc->handle,
+			    THINKPAD_NAME_EVENTS_MASK_GET, &val);
+		break;
+
+	case ACPI_THINKPAD_METHOD_HOTKEY:
+		/*
+		 * Construct the hotkey as a bitmask as illustrated below.
+		 * Note that whenever a key was pressed, the respecting bit
+		 * toggles and nothing else changes.
+		 * +--+--+-+-+-+-+-+-+-+-+-+-+
+		 * |11|10|9|8|7|6|5|4|3|2|1|0|
+		 * +--+--+-+-+-+-+-+-+-+-+-+-+
+		 *   |  | | | | | | | | | | |
+		 *   |  | | | | | | | | | | +- Home Button
+		 *   |  | | | | | | | | | +--- Search Button
+		 *   |  | | | | | | | | +----- Mail Button
+		 *   |  | | | | | | | +------- Thinkpad Button
+		 *   |  | | | | | | +--------- Zoom (Fn + Space)
+		 *   |  | | | | | +----------- WLAN Button
+		 *   |  | | | | +------------- Video Button
+		 *   |  | | | +--------------- Hibernate Button
+		 *   |  | | +----------------- Thinklight Button
+		 *   |  | +------------------- Screen expand (Fn + F8)
+		 *   |  +--------------------- Brightness
+		 *   +------------------------ Volume/Mute
+		 */
+		key = rtcin(THINKPAD_RTC_HOTKEY1);
+		val = (THINKPAD_RTC_MASK_HOME | THINKPAD_RTC_MASK_SEARCH |
+		    THINKPAD_RTC_MASK_MAIL | THINKPAD_RTC_MASK_WLAN) & key;
+		key = rtcin(THINKPAD_RTC_HOTKEY2);
+		val |= (THINKPAD_RTC_MASK_THINKPAD | THINKPAD_RTC_MASK_VIDEO |
+		    THINKPAD_RTC_MASK_HIBERNATE) & key;
+		val |= (THINKPAD_RTC_MASK_ZOOM & key) >> 1;
+		key = rtcin(THINKPAD_RTC_THINKLIGHT);
+		val |= (THINKPAD_RTC_MASK_THINKLIGHT & key) << 4;
+		key = rtcin(THINKPAD_RTC_SCREENEXPAND);
+		val |= (THINKPAD_RTC_MASK_THINKLIGHT & key) << 4;
+		key = rtcin(THINKPAD_RTC_BRIGHTNESS);
+		val |= (THINKPAD_RTC_MASK_BRIGHTNESS & key) << 5;
+		key = rtcin(THINKPAD_RTC_VOLUME);
+		val |= (THINKPAD_RTC_MASK_VOLUME & key) << 4;
+		break;
+
+	case ACPI_THINKPAD_METHOD_BRIGHTNESS:
+		ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_BRIGHTNESS, &val_ec, 1);
+		val = val_ec & THINKPAD_EC_MASK_BRI;
+		break;
+
+	case ACPI_THINKPAD_METHOD_VOLUME:
+		ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_VOLUME, &val_ec, 1);
+		val = val_ec & THINKPAD_EC_MASK_VOL;
+		break;
+
+	case ACPI_THINKPAD_METHOD_MUTE:
+		val = ((val_ec & THINKPAD_EC_MASK_MUTE) ==
+		    THINKPAD_EC_MASK_MUTE);
+		break;
+
+	case ACPI_THINKPAD_METHOD_THINKLIGHT:
+		if (sc->light_get_supported)
+			acpi_GetInteger(sc->ec_handle, THINKPAD_NAME_KEYLIGHT,
+			    &val);
+		else
+			val = sc->light_val;
+		break;
+
+	case ACPI_THINKPAD_METHOD_BLUETOOTH:
+		acpi_GetInteger(sc->handle, THINKPAD_NAME_WLAN_BT_GET, &val);
+		sc->wlan_bt_flags = val;
+		val = ((val & THINKPAD_NAME_MASK_BT) != 0);
+		break;
+
+	case ACPI_THINKPAD_METHOD_WLAN:
+		acpi_GetInteger(sc->handle, THINKPAD_NAME_WLAN_BT_GET, &val);
+		sc->wlan_bt_flags = val;
+		val = ((val & THINKPAD_NAME_MASK_WLAN) != 0);
+		break;
+
+	case ACPI_THINKPAD_METHOD_FANSPEED:
+		if (sc->fan_handle) {
+			if (ACPI_FAILURE(acpi_GetInteger(sc->fan_handle,
+			    NULL, &val)))
+				val = -1;
+		}
+		else {
+			ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_FANSPEED,
+			    &val_ec, 2);
+			val = val_ec;
+		}
+		break;
+
+	case ACPI_THINKPAD_METHOD_FANLEVEL:
+		/*
+		 * The THINKPAD_EC_FANSTATUS register works as follows:
+		 * Bit 0-5 indicate the level at which the fan operates. Only
+		 *       values between 0 and 7 have an effect. Everything
+		 *       above 7 is treated the same as level 7
+		 * Bit 6 overrides the fan speed limit if set to 1
+		 * Bit 7 indicates at which mode the fan operates:
+		 *       manual (0) or automatic (1)
+		 */
+		if (!sc->fan_handle) {
+			ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_FANSTATUS,
+			    &val_ec, 1);
+			val = val_ec & THINKPAD_EC_MASK_FANLEVEL;
+		}
+		break;
+
+	case ACPI_THINKPAD_METHOD_FANSTATUS:
+		if (!sc->fan_handle) {
+			ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_FANSTATUS,
+			    &val_ec, 1);
+			val = (val_ec & THINKPAD_EC_MASK_FANSTATUS) ==
+			    THINKPAD_EC_MASK_FANSTATUS;
+		}
+		else
+			val = -1;
+		break;
+	}
+
+	return (val);
+}
+
+static int
+acpi_thinkpad_sysctl_set(struct acpi_thinkpad_softc *sc, int method, int arg)
+{
+	int			val, step, i;
+	ACPI_INTEGER		val_ec;
+	ACPI_OBJECT		Arg;
+	ACPI_OBJECT_LIST	Args;
+	ACPI_STATUS		status;
+
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+	/* ACPI_SERIAL_ASSERT(thinkpad); */
+
+	switch (method) {
+	case ACPI_THINKPAD_METHOD_EVENTS:
+		if (arg < 0 || arg > 1)
+			return (EINVAL);
+
+		status = acpi_SetInteger(sc->handle,
+		    THINKPAD_NAME_EVENTS_STATUS_SET, arg);
+		if (ACPI_FAILURE(status))
+			return (status);
+		if (sc->events_mask_supported)
+			return acpi_thinkpad_eventmask_set(sc,
+			    sc->events_availmask);
+		break;
+
+	case ACPI_THINKPAD_METHOD_EVENTMASK:
+		if (sc->events_mask_supported)
+			return acpi_thinkpad_eventmask_set(sc, arg);
+		break;
+
+	case ACPI_THINKPAD_METHOD_BRIGHTNESS:
+		if (arg < 0 || arg > 7)
+			return (EINVAL);
+
+		if (sc->cmos_handle) {
+			/* Read the current brightness */
+			status = ACPI_EC_READ(sc->ec_dev,
+			    THINKPAD_EC_BRIGHTNESS, &val_ec, 1);
+			if (ACPI_FAILURE(status))
+				return (status);
+			val = val_ec & THINKPAD_EC_MASK_BRI;
+
+			Args.Count = 1;
+			Args.Pointer = &Arg;
+			Arg.Type = ACPI_TYPE_INTEGER;
+			Arg.Integer.Value = (arg > val) ?
+			    THINKPAD_CMOS_BRIGHTNESS_UP :
+			    THINKPAD_CMOS_BRIGHTNESS_DOWN;
+
+			step = (arg > val) ? 1 : -1;
+			for (i = val; i != arg; i += step) {
+				status = AcpiEvaluateObject(sc->cmos_handle,
+				    NULL, &Args, NULL);
+				if (ACPI_FAILURE(status))
+					break;
+			}
+		}
+		return ACPI_EC_WRITE(sc->ec_dev, THINKPAD_EC_BRIGHTNESS,
+		    arg, 1);
+		break;
+
+	case ACPI_THINKPAD_METHOD_VOLUME:
+		if (arg < 0 || arg > 14)
+			return (EINVAL);
+
+		status = ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_VOLUME,
+		    &val_ec, 1);
+		if (ACPI_FAILURE(status))
+			return (status);
+
+		if (sc->cmos_handle) {
+			val = val_ec & THINKPAD_EC_MASK_VOL;
+
+			Args.Count = 1;
+			Args.Pointer = &Arg;
+			Arg.Type = ACPI_TYPE_INTEGER;
+			Arg.Integer.Value = (arg > val) ?
+			    THINKPAD_CMOS_VOLUME_UP : THINKPAD_CMOS_VOLUME_DOWN;
+
+			step = (arg > val) ? 1 : -1;
+			for (i = val; i != arg; i += step) {
+				status = AcpiEvaluateObject(sc->cmos_handle,
+				    NULL, &Args, NULL);
+				if (ACPI_FAILURE(status))
+					break;
+			}
+		}
+		return ACPI_EC_WRITE(sc->ec_dev, THINKPAD_EC_VOLUME, arg +
+		    (val_ec & (~THINKPAD_EC_MASK_VOL)), 1);
+		break;
+
+	case ACPI_THINKPAD_METHOD_MUTE:
+		if (arg < 0 || arg > 1)
+			return (EINVAL);
+
+		status = ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_VOLUME,
+		    &val_ec, 1);
+		if (ACPI_FAILURE(status))
+			return (status);
+
+		if (sc->cmos_handle) {
+			val = val_ec & THINKPAD_EC_MASK_VOL;
+
+			Args.Count = 1;
+			Args.Pointer = &Arg;
+			Arg.Type = ACPI_TYPE_INTEGER;
+			Arg.Integer.Value = THINKPAD_CMOS_VOLUME_MUTE;
+
+			status = AcpiEvaluateObject(sc->cmos_handle, NULL,
+			    &Args, NULL);
+			if (ACPI_FAILURE(status))
+				break;
+		}
+		return ACPI_EC_WRITE(sc->ec_dev, THINKPAD_EC_VOLUME, (arg==1) ?
+		   val_ec | THINKPAD_EC_MASK_MUTE :
+		   val_ec & (~THINKPAD_EC_MASK_MUTE), 1);
+		break;
+
+	case ACPI_THINKPAD_METHOD_THINKLIGHT:
+		if (arg < 0 || arg > 1)
+			return (EINVAL);
+
+		if (sc->light_set_supported) {
+			Args.Count = 1;
+			Args.Pointer = &Arg;
+			Arg.Type = ACPI_TYPE_INTEGER;
+			Arg.Integer.Value = arg ?
+			    sc->light_cmd_on : sc->light_cmd_off;
+
+			status = AcpiEvaluateObject(sc->light_handle, NULL,
+			    &Args, NULL);
+			if (ACPI_SUCCESS(status))
+				sc->light_val = arg;
+			return (status);
+		}
+		break;
+
+	case ACPI_THINKPAD_METHOD_BLUETOOTH:
+		if (arg < 0 || arg > 1)
+			return (EINVAL);
+
+		val = (arg == 1) ? sc->wlan_bt_flags |
+		    THINKPAD_NAME_MASK_BT :
+		    sc->wlan_bt_flags & (~THINKPAD_NAME_MASK_BT);
+		return acpi_SetInteger(sc->handle, THINKPAD_NAME_WLAN_BT_SET,
+		    val);
+		break;
+
+	case ACPI_THINKPAD_METHOD_FANLEVEL:
+		if (arg < 0 || arg > 7)
+			return (EINVAL);
+
+		if (!sc->fan_handle) {
+			/* Read the current fanstatus */
+			ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_FANSTATUS,
+			    &val_ec, 1);
+			val = val_ec & (~THINKPAD_EC_MASK_FANLEVEL);
+
+			return ACPI_EC_WRITE(sc->ec_dev, THINKPAD_EC_FANSTATUS,
+			    val | arg, 1);
+		}
+		break;
+
+	case ACPI_THINKPAD_METHOD_FANSTATUS:
+		if (arg < 0 || arg > 1)
+			return (EINVAL);
+
+		if (!sc->fan_handle) {
+			/* Read the current fanstatus */
+			ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_FANSTATUS,
+			    &val_ec, 1);
+
+			return ACPI_EC_WRITE(sc->ec_dev, THINKPAD_EC_FANSTATUS,
+			    (arg == 1) ? (val_ec | THINKPAD_EC_MASK_FANSTATUS) :
+			    (val_ec & (~THINKPAD_EC_MASK_FANSTATUS)), 1);
+		}
+		break;
+	}
+
+	return (0);
+}
+
+static int
+acpi_thinkpad_sysctl_init(struct acpi_thinkpad_softc *sc, int method)
+{
+	int 			dummy;
+	ACPI_OBJECT_TYPE 	cmos_t;
+	ACPI_HANDLE		ledb_handle;
+
+	switch (method) {
+	case ACPI_THINKPAD_METHOD_EVENTS:
+		/* Events are disabled by default */
+		return (TRUE);
+
+	case ACPI_THINKPAD_METHOD_EVENTMASK:
+		return (sc->events_mask_supported);
+
+	case ACPI_THINKPAD_METHOD_HOTKEY:
+	case ACPI_THINKPAD_METHOD_BRIGHTNESS:
+	case ACPI_THINKPAD_METHOD_VOLUME:
+	case ACPI_THINKPAD_METHOD_MUTE:
+		/* EC is required here, which was already checked before */
+		return (TRUE);
+
+	case ACPI_THINKPAD_METHOD_THINKLIGHT:
+		sc->cmos_handle = NULL;
+		sc->light_get_supported = ACPI_SUCCESS(acpi_GetInteger(
+		    sc->ec_handle, THINKPAD_NAME_KEYLIGHT, &sc->light_val));
+
+		if ((ACPI_SUCCESS(AcpiGetHandle(sc->handle, "\\UCMS",
+		    &sc->light_handle)) ||
+		    ACPI_SUCCESS(AcpiGetHandle(sc->handle, "\\CMOS",
+		    &sc->light_handle)) ||
+		    ACPI_SUCCESS(AcpiGetHandle(sc->handle, "\\CMS",
+		    &sc->light_handle))) &&
+		    ACPI_SUCCESS(AcpiGetType(sc->light_handle, &cmos_t)) &&
+		    cmos_t == ACPI_TYPE_METHOD) {
+			sc->light_cmd_on = 0x0c;
+			sc->light_cmd_off = 0x0d;
+			sc->cmos_handle = sc->light_handle;
+		}
+		else if (ACPI_SUCCESS(AcpiGetHandle(sc->handle, "\\LGHT",
+		    &sc->light_handle))) {
+			sc->light_cmd_on = 1;
+			sc->light_cmd_off = 0;
+		}
+		else
+			sc->light_handle = NULL;
+
+		sc->light_set_supported = (sc->light_handle &&
+		    ACPI_FAILURE(AcpiGetHandle(sc->ec_handle, "LEDB",
+		    &ledb_handle)));
+
+		if (sc->light_get_supported)
+			return (TRUE);
+
+		if (sc->light_set_supported) {
+			sc->light_val = 0;
+			return (TRUE);
+		}
+
+		return (FALSE);
+
+	case ACPI_THINKPAD_METHOD_BLUETOOTH:
+	case ACPI_THINKPAD_METHOD_WLAN:
+		if (ACPI_SUCCESS(acpi_GetInteger(sc->handle,
+		    THINKPAD_NAME_WLAN_BT_GET, &dummy)))
+			return (TRUE);
+		return (FALSE);
+
+	case ACPI_THINKPAD_METHOD_FANSPEED:
+		/* 
+		 * Some models report the fan speed in levels from 0-7
+		 * Newer models report it contiguously
+		 */
+		sc->fan_levels = (ACPI_SUCCESS(AcpiGetHandle(sc->handle, "GFAN",
+		    &sc->fan_handle)) ||
+		    ACPI_SUCCESS(AcpiGetHandle(sc->handle, "\\FSPD",
+		    &sc->fan_handle)));
+		return (TRUE);
+
+	case ACPI_THINKPAD_METHOD_FANLEVEL:
+	case ACPI_THINKPAD_METHOD_FANSTATUS:
+		/* 
+		 * Fan status is only supported on those models,
+		 * which report fan RPM contiguously, not in levels
+		 */
+		if (sc->fan_levels)
+			return (FALSE);
+		return (TRUE);
+
+	case ACPI_THINKPAD_METHOD_THERMAL:
+		if (ACPI_SUCCESS(acpi_GetInteger(sc->ec_handle,
+		    THINKPAD_NAME_THERMAL_GET, &dummy))) {
+			sc->thermal_updt_supported =
+			    ACPI_SUCCESS(acpi_GetInteger(sc->ec_handle,
+			    THINKPAD_NAME_THERMAL_UPDT, &dummy));
+			return (TRUE);
+		}
+		return (FALSE);
+	}
+	return (FALSE);
+}
+
+static void
+acpi_thinkpad_notify(ACPI_HANDLE h, UINT32 notify, void *context)
+{
+	int		event, arg, type;
+	device_t	dev = context;
+	struct acpi_thinkpad_softc *sc = device_get_softc(dev);
+
+	ACPI_FUNCTION_TRACE_U32((char *)(uintptr_t)__func__, notify);
+
+	if (notify != 0x80)
+		device_printf(dev, "Unknown notify\n");
+
+	for (;;) {
+		acpi_GetInteger(acpi_get_handle(dev), THINKPAD_NAME_EVENTS_GET,
+		    &event);
+
+		if (event == 0)
+			break;
+
+		type = (event >> 12) & 0xf;
+		arg = event & 0xfff;
+		switch (type) {
+		case 1:
+			if (!(sc->events_availmask & (1 << (arg - 1)))) {
+				device_printf(dev, "Unknown key %d\n", arg);
+				break;
+			}
+
+			/* Notify devd(8) */
+			device_printf(dev, "THINKPAD event: %u\n",
+			    (arg & 0xff));
+			acpi_UserNotify("THINKPAD", h, (arg & 0xff));
+			break;
+		default:
+			break;
+		}
+	}
+}
+
+static void
+acpi_thinkpad_refresh(void *arg)
+{
+	struct acpi_thinkpad_softc *sc = (struct acpi_thinkpad_softc *)arg;
+	char temp_cmd[] = "TMP0";
+	int data, i;
+	ACPI_INTEGER speed;
+
+	for (i = 0; i < 8; i++) {
+		temp_cmd[3] = '0' + i;
+		
+                /*
+                 * The TMPx methods seem to return +/- 128 or 0
+                 * when the respecting sensor is not available
+                 */
+		sc->sensors[i].flags &= ~SENSOR_FINVALID;
+                if (ACPI_FAILURE(acpi_GetInteger(sc->ec_handle, temp_cmd,
+                    &data)) || ABS(data) == 128 || data == 0) {
+			sc->sensors[i].flags |= SENSOR_FINVALID;
+                        data = 0;
+		}
+                else if (sc->thermal_updt_supported) {
+                        /* XXX: Temperature is reported in tenth of Kelvin */
+                        data = (data - 2732 + 5) / 10;
+		}
+		sc->sensors[i].value = data * 1000000 + 273150000;
+        }
+	
+	sc->sensors[8].flags &= ~SENSOR_FINVALID;
+	if (sc->fan_handle) {
+		if (ACPI_FAILURE(acpi_GetInteger(sc->fan_handle,
+		    NULL, &data)))
+			sc->sensors[8].flags |= SENSOR_FINVALID;
+                        data = -1;
+        }
+        else {
+                ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_FANSPEED, &speed, 2);
+                data = speed;
+        }
+
+	sc->sensors[8].value = data;
+}
diff --git a/sys/platform/pc32/conf/files b/sys/platform/pc32/conf/files
--- a/sys/platform/pc32/conf/files
+++ b/sys/platform/pc32/conf/files
@@ -72,6 +72,7 @@ dev/serial/dgb/dgm.c			optional	dgm
 ${OSACPI_MD_DIR}/acpi_machdep.c		optional        acpi
 ${OSACPI_MD_DIR}/acpi_wakeup.c		optional        acpi
 ${OSACPI_MD_DIR}/acpi_toshiba.c		optional        acpi_toshiba acpi
+${ACPICA_DIR}/acpi_thinkpad/acpi_thinkpad.c optional	acpi_thinkpad acpi
 acpi.h					optional	acpi		\
 	dependency	"$S/${ACPICA_DIR}/include/acpi.h"		\
 	compile-with	"cp $S/${ACPICA_DIR}/include/acpi.h ${.OBJDIR}/"	\



From hasso at estpak.ee  Thu Mar 20 03:49:13 2008
From: hasso at estpak.ee (Hasso Tepper)
Date: Thu, 20 Mar 2008 03:49:13 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Some questions regarding ACPI
In-Reply-To: <200803191322.46366.hasso@estpak.ee>
Message-ID: <200803201237.28823.hasso@estpak.ee>

Hasso Tepper wrote:
> There is also one fatal issue -laptop locks up hardly (no panic) while 
> unloading module. Any idea regarding this is welcome.

Nevermind, solved.


-- 
Hasso




From dillon at apollo.backplane.com  Fri Mar 21 19:24:01 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Fri, 21 Mar 2008 19:24:01 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: panic: assertion: hammer_btree_cmp(cursor->left_bound,	&cursor->node->ondisk->elms[0].leaf.base) <= 0 in btree_split_leaf
In-Reply-To: <200802232204.m1NM4cxd046264@apollo.backplane.com>
Message-ID: <200803220212.m2M2CiAY014435@apollo.backplane.com>

:While trying to find a procedure to reliably reproduce the panic
:I reported last time, I caught a different panic (uploaded at
: ~y0netan1/crash/9/ on my leaf account).  I wrote the following shell
:script (make sure to edit variables DISKS and MOUNTPT before using this
:script or it may trash your system):

    Ok, I believe I have fixed the left_bound assertion.  I also believe
    I have fixed the node ref count assertion on umount.

    There is currently one unfixed assertion related to the I/O
    path... sometimes the bp is being improperly disassociated from the
    related HAMMER structure.

    The full-filesystem case is still not being handled so don't test that :-)

					    -Matt





From c.turner at 199technologies.org  Sun Mar 23 09:48:29 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Sun, 23 Mar 2008 09:48:29 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
Message-ID: <47E6870C.4080709@199technologies.org>

I'm finally getting around to doing 1.12 upgrades, and have setup a 
separate machine to do my bulk package builds / upgrades etc,
so as not to disrupt my 'dev server' while things are being
built / tested

However, this seems kind of wasteful - the only purpose of this machine
is to build packages against a specific release..
And since building packages for a particular release generally requires 
only the userland, appropriate headers and correct 'uname' output - so:

it seems like if spoofing uname is configured inside a jail,
the next (or previous..) release can be installed into a jail and
used for building / testing packages without the overhead of a VM or 
maintaining a separate physical host

I did a quick scan of the tree to see what this would take, and, high 
level, it seems like only the following changes would need to be made:

- update struct jail to add a 'osrelease' string
  (implies bumping 'jail api' to 2?)
- update jail(8) to actually pass this information along
- update sys_uname to test ucred for jailed processes, and
  use the struct jail osrelease if appropriate
- similarly update sysctl kern.osrelease to support jail spoofing
  (if possible - didn't get this far in the research yet)
  could be less of a problem for builds, as I think most things use
 uname(1) ... but good to keep the environment consistent I suppose..
I'm still a bit confused as to how 'osrelease' is defined - everything
I'm finding is showing up as extern char[] .. perhaps this is something 
in the build I'm not familiar with?

also,

is the so-called 'stupid hackery' in sys_uname needed still?

Before I start any coding, does this:

- sound like something useful
- sound like the right approach
Thinking this could have wider useful implications e.g. for pkgbox
& so on -  for example setting up automated bulks w/various combinations 
of pkgsrc and releases, etc.

Cheers,

- Chris





From corecode at fs.ei.tum.de  Sun Mar 23 10:06:38 2008
From: corecode at fs.ei.tum.de (Simon 'corecode' Schubert)
Date: Sun, 23 Mar 2008 10:06:38 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <47E68C74.3080808@fs.ei.tum.de>

Chris Turner wrote:
I did a quick scan of the tree to see what this would take, and, high 
level, it seems like only the following changes would need to be made:
brave investigation.  but you could also simply set UNAME_r :)

sweatshorts % uname -r
1.13.0-DEVELOPMENT
sweatshorts % UNAME_r=1.12-RELEASE uname -r
1.12-RELEASE
I think that's good enough :D

cheers
  simon
--
Serve - BSD     +++  RENT this banner advert  +++    ASCII Ribbon   /"\
Work - Mac      +++  space for low ????????? NOW!1  +++      Campaign     \ /
Party Enjoy Relax   |   http://dragonflybsd.org      Against  HTML   \
Dude 2c 2 the max   !   http://golden-apple.biz       Mail + News   / \




From c.turner at 199technologies.org  Sun Mar 23 10:50:13 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Sun, 23 Mar 2008 10:50:13 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <47E69656.8080605@199technologies.org>

Simon 'corecode' Schubert wrote:
brave investigation.  but you could also simply set UNAME_r :)
Doh! Thanks for the tip!

they should change the phrase from RTFM to 'Carefully RTFM' :)

well.. scratch that change then. 1 less patch to write.

- Chris





From c.turner at 199technologies.org  Sun Mar 23 11:15:52 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Sun, 23 Mar 2008 11:15:52 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <47E69C7C.8010109@199technologies.org>

Chris Turner wrote:
Simon 'corecode' Schubert wrote:
brave investigation.  but you could also simply set UNAME_r :)

for the record - if anyone's interested - adding a line e.g.:

ALL_ENV+= UNAME_r=1.12-RELEASE

to mk.conf looks like it -might- work ..

(unless wants to chime in & verify)





From joerg at britannica.bec.de  Sun Mar 23 11:46:53 2008
From: joerg at britannica.bec.de (Joerg Sonnenberger)
Date: Sun, 23 Mar 2008 11:46:53 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <20080323181428.GA2099@britannica.bec.de>

On Sun, Mar 23, 2008 at 01:41:42PM -0400, Chris Turner wrote:
> they should change the phrase from RTFM to 'Carefully RTFM' :)

RTFMAI -- Read The Fine Manual Again, Idiot.

Joerg




From dillon at apollo.backplane.com  Sun Mar 23 20:05:36 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Sun, 23 Mar 2008 20:05:36 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
Message-ID: <200803240257.m2O2voNH038355@apollo.backplane.com>

    Here's an update on the HAMMER work!

    Current status:

    * Passes all standard filesystem stress tests and buildworld will
      run with a HAMMER /usr/obj.  Large histories are able to accumulate
      without effecting performance.

    * Pruning and reblocking code is in and partially tested, but now needs
      more stringent testing.

    * Full historical access appears to be working but needs testing.
      Note that a sync is still needed to flush dirty cached data prior
      to acquiring a timestamp for the 'snapshot' to be set in stone.
      (dirty data cached in-memory has no historical tags and must be
      committed to physical disk before it can be accessed historically).


    Current bugs:

    * There is one known bug in the standard operations code paths
      that results in an assertion in HAMMER's I/O subsystem.

    * There are probably bugs in the reblocking and/or pruning code.  More
      likely in the reblocking code.


    There are two big-ticket and several little-ticket items left.  HAMMER
    will officially go Alpha when the big-ticket items are done, and beta
    when we get a few of the little-ticket items done.

    Big ticket items left:

    * UNDO (crash recovery) code.  Currently it writes out undo records but
      they are not yet sequenced, buffer writes are not yet ordered, and
      there is no mount-time recovery code yet.

      This is the last item needed before HAMMER can go operational.

    * Filesystem full handling.  Currently no space is reserved for dirty
      cached data so it is possible to create/write files and for HAMMER
      to not have sufficient space left on-disk to flush it.


    Little ticket items:

    * Automated reblocking (currently these functions are manually
      initialized via the hammer utility).

    * I/O clustering and preliminary BMAP op when writing out large files.

    * CRC checking (CRC fields are reserved but not entirely generated yet
      and not yet checked at all).

    * Disaster Recovery filesystem scan.

    * Boot support.

    I expect all of these items and more to be handled by the 2.0 release
    in July.

			    Additional HAMMER capabilities
				(no timeline yet)

    * Adding, removing, and resizing a HAMMER filesystem's backing store.

			Ultimate Goals and working towards them
				(no timeline yet)

    Our ultimate goal with HAMMER and DragonFly in general is to support
    fully cache coherent replication in a multi-machine environment.  This
    involves several steps and networking protocols.

    * Replication of synchronization streams based on the UNDO log.  If
      resynchronizing to a target which is too old a B-Tree scan will
      likely be required.

    * Cache coherency protocols for machine-machine coherency for both
      replicated and remote-HAMMER access.

    I have no time frame for these items yet.  It will depend on how quickly
    HAMMER moves to Alpha and Beta status.  I will say, however, now
    that HAMMER's on-disk format has solidified, that I have a very precise
    understanding of the protocols that will be needed to accomplish fully
    cache coherent remote access for both replicated and non-replicated
    (remote mount style) access.

    And, as you know, fully coherent filesystem access across machines is
    going to be the basis for DragonFly's clustering across said machines.

    In summary, things are progressing very well.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From justin at shiningsilence.com  Sun Mar 23 20:10:13 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Sun, 23 Mar 2008 20:10:13 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <53758.192.168.0.252.1206327873.squirrel@www.shiningsilence.com>

On Sun, March 23, 2008 12:36 pm, Chris Turner wrote:

> it seems like if spoofing uname is configured inside a jail,
> the next (or previous..) release can be installed into a jail and
> used for building / testing packages without the overhead of a VM or
> maintaining a separate physical host

If you don't need a jail to spoof uname, as others posted, you can
installworld into a chroot and build everything you want there using
Joerg's spiffy pbulk.  That's what I'm doing on pkgbox now; I can hand you
my somewhat terse notes if you want.  It would be relatively easy to set
up the configuration you're talking about.





From sepherosa at gmail.com  Sun Mar 23 20:18:20 2008
From: sepherosa at gmail.com (Sepherosa Ziehau)
Date: Sun, 23 Mar 2008 20:18:20 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <ea7b9c170803232012n2f27f893tf1d756d7c9770419@mail.gmail.com>

On Mon, Mar 24, 2008 at 2:14 AM, Joerg Sonnenberger
<joerg at britannica.bec.de> wrote:
> On Sun, Mar 23, 2008 at 01:41:42PM -0400, Chris Turner wrote:
>  > they should change the phrase from RTFM to 'Carefully RTFM' :)
>
>  RTFMAI -- Read The Fine Manual Again, Idiot.

http://leaf.dragonflybsd.org/~sephe/rtfm.jpg

:D

>
>  Joerg
>



-- 
Live Free or Die




From justin at shiningsilence.com  Sun Mar 23 20:38:30 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Sun, 23 Mar 2008 20:38:30 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: GSoC 2008 - mentors signup
Message-ID: <53885.192.168.0.252.1206329503.squirrel@www.shiningsilence.com>

If you are planning to be a mentor for a Summer of Code project, please
sign up here for the mentors mailing list:

http://groups.google.com/group/google-summer-of-code-mentors-list

If you've already signed up, your subscription should be set up tomorrow.





From justin at shiningsilence.com  Sun Mar 23 21:12:01 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Sun, 23 Mar 2008 21:12:01 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: GSoC 2008 - mentors signup
In-Reply-To: <53885.192.168.0.252.1206329503.squirrel@www.shiningsilence.com>
Message-ID: <54025.192.168.0.252.1206331572.squirrel@www.shiningsilence.com>

Also!

If you are a potential mentor and you have not done so yet:

http://code.google.com/soc/mentor_step1.html

Get yourself registered as a mentor for the Summer of Code project.  Once
you are in there, check off DragonFly in the "My Profile" section.

You will need a Google Account if you don't have one:

http://www.google.com/accounts

This will add you to the list of mentors in the Google Summer of Code web
application, so you can review/be attached to projects.

A guide is available if you want more information:

http://groups.google.com/group/google-summer-of-code-announce/web/guide-to-the-gsoc-web-app-for-mentors-and-organization-administrators






From c.turner at 199technologies.org  Mon Mar 24 04:29:28 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Mon, 24 Mar 2008 04:29:28 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <47E78ECE.4070307@199technologies.org>

Justin C. Sherrill wrote:
If you don't need a jail to spoof uname, as others posted, you can
installworld into a chroot and build everything you want there using
Joerg's spiffy pbulk.  That's what I'm doing on pkgbox now; I can hand you
my somewhat terse notes if you want.  It would be relatively easy to set
up the configuration you're talking about.
cheers - I guess I thought incorrectly that something 'special' was 
needed to get the uname to change .. have been using the legacy bulks in 
chroots / jails (for 'same os' builds) as I haven't quite migrated to 
pbulk yet ..

thanks for the help offer - I'll ask if I run into trouble.




From dillon at apollo.backplane.com  Mon Mar 24 08:28:49 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Mon, 24 Mar 2008 08:28:49 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <200803241500.m2OF0CG8043760@apollo.backplane.com>


:http://leaf.dragonflybsd.org/~sephe/rtfm.jpg
:
::D

    Ho!

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From elekktretterr at exemail.com.au  Mon Mar 24 09:10:15 2008
From: elekktretterr at exemail.com.au (Petr Janda)
Date: Mon, 24 Mar 2008 09:10:15 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
In-Reply-To: <200803240257.m2O2voNH038355@apollo.backplane.com>
Message-ID: <200803250138.49775.elekktretterr@exemail.com.au>


>
>     And, as you know, fully coherent filesystem access across machines is
>     going to be the basis for DragonFly's clustering across said machines.
>
>     In summary, things are progressing very well.
>


Hi Matt,
That's good to know things are going so well. Got a question. If memory serves 
me right, initially there was also going to be a thing called ANVIL, I can't 
remember what it was supposed to do and whether its still in your design. 
Could you elaborate a little?

Thanks,
Petr




From dillon at apollo.backplane.com  Mon Mar 24 14:12:11 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Mon, 24 Mar 2008 14:12:11 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
In-Reply-To: <200803240257.m2O2voNH038355@apollo.backplane.com>
Message-ID: <200803242100.m2OL0nWV046868@apollo.backplane.com>


:Hi Matt,
:That's good to know things are going so well. Got a question. If memory serves 
:me right, initially there was also going to be a thing called ANVIL, I can't 
:remember what it was supposed to do and whether its still in your design. 
:Could you elaborate a little?
:
:Thanks,
:Petr

    It's not really in the HAMMER design any more, primarily because HAMMER's
    volume model seems to work fine as-is.  Ultimately something like ANVIL
    (a block storage manager) would prove beneficial to the project but it
    would be treated as a separate project.  HAMMER's redundancy model is
    going to be baesd around replication and clustering.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From tgen at netphreax.net  Mon Mar 24 18:31:37 2008
From: tgen at netphreax.net (Thomas E. Spanjaard)
Date: Mon, 24 Mar 2008 18:31:37 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
In-Reply-To: <200803240257.m2O2voNH038355@apollo.backplane.com>
Message-ID: <47E85337.2070407@netphreax.net>

Matthew Dillon wrote:
    * Full historical access appears to be working but needs testing.
      Note that a sync is still needed to flush dirty cached data prior
      to acquiring a timestamp for the 'snapshot' to be set in stone.
      (dirty data cached in-memory has no historical tags and must be
      committed to physical disk before it can be accessed historically).
Wouldn't making timestamp queries (at least from userland) enforce a 
sync on the volume in question be useful here?
--
        Thomas E. Spanjaard
        tgen at netphreax.net
Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00005.pgp
Type: application/octet-stream
Size: 186 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080324/3077333f/attachment-0008.obj>

From dillon at apollo.backplane.com  Mon Mar 24 20:10:12 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Mon, 24 Mar 2008 20:10:12 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
In-Reply-To: <200803240257.m2O2voNH038355@apollo.backplane.com>
Message-ID: <200803250302.m2P32qLP050160@apollo.backplane.com>


:Wouldn't making timestamp queries (at least from userland) enforce a 
:sync on the volume in question be useful here?
:-- 
:         Thomas E. Spanjaard
:         tgen at netphreax.net

    Making the 'hammer now' command do a sync() is a good idea.  I will
    make that change right now so it doesn't get lost.

    Here's a general overview of the issues involved with having historical
    access to the filesystem:

				----------------

    Recording the timestamps in the in-memory cache, for a finer-grained
    snapshot capability, is doable but has its own issues.  Here's an
    illustration:

    open()  create file
    write() append 4K	(file size now 4K)
    write() append 4K	(file size now 8K)
    write() append 4K	(file size now 12K)
    write() append 4K	(file size now 16K)

    Now NONE of this has gone to disk yet, it's entirely in the in-memory
    cache.  The inode is in the in-memory cache.  The data is stored in
    the buffer cache.  Even the directory entry for the file that we
    just created is still in the in-memory cache (HAMMER caches the raw
    records it intends to commit later on).

    If I wanted to be able to acquire a timestamp between each write and
    'see' a snapshot of the file as of any point in the above sequence,
    then every write would also have to allocate a copy of the inode
    (because it changes size on each write).

    The data has the same problem though with a slightly different example.
    Lets say each write() was a seek-write, overwriting the previous data.
    Now with every write() I would have to allocate a copy of the data
    being overwritten.  This is complicated by the fact that the buffer
    cache has no clue about 'historical' accesses, so I would not be able
    to use the buffer cache to cache the data.

    There's also another problem and that is with the efficiency of the
    topology on-disk.  Even if I maintained all the copies of the inode
    and all the copies of the data in-memory, I would still have to sync
    all those copies to disk in order for things to remain historically
    coherent (whether it be in-cache or on-disk).  This would result in
    hundreds or even thousands of copies of the inode on-disk, not to
    mention potentially many copies of the data.

    I just don't want to do that right now, at least not as a default.  A
    lot of performance would be lost.  Hence a sync() is needed if
    you want to create a demark which you can accurately snapshot.

				-------------

    Here's a quick synopsis of how the cache would operate in a clustered
    filesystem:

    In order to properly integrate with in-memory caches, a wider cache
    coherency infrastructure is needed between machines such that
    modifications made on one machine proactively invalidate those
    protions of the cache(s) on other machines.  At the same time, any
    'dirty' cache data, for example when a file is created or written to,
    must lock the cache space in question on all other machines.
    The cache space in this case is not just the file data, but also the
    related namespaces (for creations, deletions, and renames).  Attempts
    to access locked spaces from other machines in the cluster would have
    to force a flush to the filesystem backing store and lower the cache
    states for the effected information on the original machine from dirty
    to shared-read-only.

    It will be easiest to integrate the cache coherency information into
    the buffer cache and namecache themselves.  Once a machine has dirtied
    an in-memory cache element... for example part of the namespace when
    creating a file or chunks of data written within a file, that machine
    must have a free hand to make further modifications to the cache spaces
    involved without further interaction with other machines.

				-------------

    Now, if you think of those two major elements you can see that they
    actually fit together quite well.  If I were to attempt to maintain
    transactional coherency on a per-system-call basis then the cache
    granularity between machines would have to be much, much smaller then
    our current in-memory caching elements provide.  That would become
    a really nasty coding problem.  So I don't even want to begin to
    complate transactional coherency at a finer-grain then sync() or
    fsync() until long after we actually have clustering working.

						-Matt





From elekktretterr at exemail.com.au  Mon Mar 24 21:56:58 2008
From: elekktretterr at exemail.com.au (Petr Janda)
Date: Mon, 24 Mar 2008 21:56:58 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
In-Reply-To: <200803240257.m2O2voNH038355@apollo.backplane.com>
Message-ID: <200803251516.16407.elekktretterr@exemail.com.au>

So is it needed to run hammer now in order to "create" a snapshot? What would 
I do in situation like this: got a hammer filesystem and couple of the files 
change on day to day basis. Then a week later I needed to access one of the 
files, in exactly the state they were 7 days ago.

Cheers,
Petr




From dillon at apollo.backplane.com  Mon Mar 24 22:34:15 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Mon, 24 Mar 2008 22:34:15 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
In-Reply-To: <200803240257.m2O2voNH038355@apollo.backplane.com>
Message-ID: <200803250526.m2P5QZ5X051081@apollo.backplane.com>


:So is it needed to run hammer now in order to "create" a snapshot? What would 
:I do in situation like this: got a hammer filesystem and couple of the files 
:change on day to day basis. Then a week later I needed to access one of the 
:files, in exactly the state they were 7 days ago.
:
:Cheers,
:Petr

    No, you do not have to run 'hammer now' to create a snapshot.  The
    kernel syncs all filesystems every 30 seconds, so if you do nothing
    at all you get a snapshot granularity of 30 seconds.

    Where you would use 'hammer now' is if you wanted the most current
    snapshot possible for the purpose of, say, backing up your filesystem
    to another machine.  You might do something like this:

	set timestamp = `hammer now`
	cpdup /mountpoint/@@$timestamp targethost:/somepath

    But if you didn't care about that you could just go back far enough
    that you get a stable historical view... e.g. go back 1 minute and you
    would have a stable view into your filesystem.

	set timestamp = `hammer stamp 60s`		<------ doesn't sync
	cpdup /mountpoint/@@$timestamp targethost:/somepath


    Ultimately the idea of managing filesystems this way is to still do
    regular backups from your production machine to your backup machine
    (ultimately by way of replication), with both running HAMMER, but only
    retain a limited amount of history on the production box.  You might
    desire to retain only one week's worth of history on the production box,
    retain one month's history on your local backup box, and retain a very
    granular one year's worth of history on your remote backup box.

    Come to think of it, I should add some more directives to the
    'hammer prune' command to make that easier to specify.

    Until I implement a live replication 'feed' the minimum granularity on
    the backup box will be how often you do your backups (e.g. once a day),
    and you can prune it into more granular forms from that starting point.
    Once we have a live replication feed the backup box will have the same
    30-second granularity that the production machine has.

    A major bullet point for this style of management is that the retention
    policy on the various boxes can be different even though they are
    all slaved off the same production filesystem.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From justin at shiningsilence.com  Tue Mar 25 05:58:49 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Tue, 25 Mar 2008 05:58:49 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: SoC - student signups
Message-ID: <58180.65.106.147.226.1206449676.squirrel@www.shiningsilence.com>

Here's a quick link roundup:

Are you a student?  Put in your application for a Google Summer of Code here:

http://code.google.com/soc/2008/student_signup.html

Student guide:
http://groups.google.com/group/google-summer-of-code-announce/web/guide-to-the-gsoc-web-app-for-student-applicants

Are you a mentor?  (That means hasso, hsu, sephe, matthias, TGEN, and
corecode right now)

Student proposals will show up on the mentor page, linked below.  You will
get to rate them, and take the one(s) that you want to mentor.

Mentor page:
http://code.google.com/soc/2008/mentor_home.html
Mentor guide:
http://groups.google.com/group/google-summer-of-code-announce/web/guide-to-the-gsoc-web-app-for-mentors-and-organization-administrators

If you are a mentor and are communicating with potential students, send
them the URLs above for student signup and the student guide; work with
them if they ask for advice on what to say in the application.  They can
resubmit up to 20 times if they want to correct it.

Deadline is March 31st.






From noah.yan at gmail.com  Thu Mar 27 20:17:48 2008
From: noah.yan at gmail.com (Yonghong Yan)
Date: Thu, 27 Mar 2008 20:17:48 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: About DFBSD.64
In-Reply-To: <47EB0B5B.5020802@gmail.com>
Message-ID: <59521b110803272015y1cc8cc39uc93f154ed36e0505@mail.gmail.com>

thanks for your interest.

I owe to everybody for any update or work in the past four months. so
many things happen in my work and my family (they are all good:) and
keep me extremely busy. But i am not leaving and will be back on this
soon.

the latest sources are in http://repo.or.cz/w/dragonfly/port-amd64.git
, I did have a compiled kernel long time before, but I have to break
it to work on the pmap. you can pick up from there. TGEN will help you
a lot, also keep me posted too, if you like.

Noah

On Wed, Mar 26, 2008 at 9:50 PM, Sdavtaker <sdavtaker at gmail.com> wrote:
> Hello,
>  Im applying to GSoC to work in the x64 version of DFBSD with TGEN, i
>  found some work already done in the repository and some mails in the
>  archive from you.
>  I was wondering if you already had a working compiled kernel in AMD64
>  machine and what was not working yet to continue that work.
>  Thanks for any info.
>  Sdav
>




From dillon at apollo.backplane.com  Sat Mar 29 13:27:43 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Sat, 29 Mar 2008 13:27:43 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 29-Mar-2008
Message-ID: <200803292022.m2TKMLGe004942@apollo.backplane.com>

    Good progress continues to be made.  HAMMER survived acting as my
    LAN backup machine (in full historical mode) for almost a week before
    it hit an assertion.  I've fixed that issue and believe that the core
    filesystem implementation code is now 'very stable'.

    Note that the recent commit will result in many more 'hammer_lock_ex:'
    messages on the console then you may have previously observed.  This is
    due to the way object id's are allocated in the face of parallel 
    modifications to the filesystem, resulting in too much locality of
    reference in the B-Tree.  I do intend to improve it.

    I am still working on the two major items needed before HAMMER can be
    declared operational, those being the filesystem full handling and the
    undo/recovery-on-mount code.  These are the last 'hard' bits left in
    the design.

    With exception to filling up the filesystem, which *will* create a mess,
    and noting that no crash recovery code exists yet (so you have to newfs
    it if you crash), I'd appreciate it if interested parties could test
    the other functions of the filesystem, in particular the pruning and
    reblocking functions (man hammer), and the historical access functions.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From dillon at apollo.backplane.com  Sun Mar 30 15:11:03 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Sun, 30 Mar 2008 15:11:03 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Need ideas on how to solve an st_ino/st_dev test issue for HAMMER.
Message-ID: <200803302207.m2UM7BCp016402@apollo.backplane.com>

    Here's the problem, given historical access softlinks as shown below:

test30# ls -lda cra*
drwxr-xr-x  1 root  wheel  Mar 29 13:04 crater
lrwxr-xr-x  1 root  wheel  Mar 29 18:57 crater.20080329 -> crater@@0x47eef383
lrwxr-xr-x  1 root  wheel  Mar 30 01:24 crater.20080330 -> crater@@0x47ef4e29
-rw-r--r--  2 root  wheel  Mar 30 01:24 crater.log

    The problem is that if I do this:

    diff -r crater.20080329/var/log crater.20080330/var/log

    Diff just returns without actually diffing anything.  The reason is
    because diff checks st_ino and st_dev and believes the directories/files
    to be identical because they match.

    I considered munging the inode number for historical accesses, but
    that would seriously break NFS exports which try to access historical
    files and directories.  Right now NFS *is* able to distinguish between
    the two because NFS handles are 128-bit-wide entities, so I can encode
    the as-of transaction id as part of the filehandle.  But userland
    programs only have access to a 64-bit-wide inode so userland still
    believes the files to be identical.

    st_dev is only 32 bits, carefully munging it is an option if we
    could figure out a way to do it, but I'd rather not.

    I am considering using st_gen but then we'd have to patch third
    party software to test st_gen along with everything else.  This may
    be the only workable solution, though, and only a few programs would
    need to be patched.  st_gen is only 32 bits but it would solve the
    problem as we would be able to use all 32 bits.

    If anyone has any bright ideas, including 'leave it alone', I'm all
    ears.

						-Matt





From justin at shiningsilence.com  Mon Mar 31 10:40:42 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Mon, 31 Mar 2008 10:40:42 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: SoC student applications due by 5PM PDT tomorrow
In-Reply-To: <1942.192.168.0.242.1206930479.squirrel@www.shiningsilence.com>
Message-ID: <11892.67.108.184.175.1206984967.squirrel@www.shiningsilence.com>

On Sun, March 30, 2008 10:27 pm, Justin C. Sherrill wrote:
> SoC students:
>
> If you have an application to submit for DragonFly/Summer of Code, please
> do so by 17:00 Pacific time on the 31st - that's tomorrow, at least for
> me.

The deadline for student proposals has been extended to April 7th; all
other dates move forward one week to acommodate.

This is a good time to update existing applications or submit new ones. 
Talk to your (potential) mentors if you are curious.






From nthery at gmail.com  Mon Mar 31 11:29:49 2008
From: nthery at gmail.com (Nicolas Thery)
Date: Mon, 31 Mar 2008 11:29:49 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
Message-ID: <64fc43b0803311126na7d0b27obaa9d35bac6d32ee@mail.gmail.com>

Hello,

Now that the release is over, I'll try to get rid of zones and migrate
allocations to objcache.

Here is a 1st patch that migrate struct proc.  I'll commit it in a
couple of days if nobody objects.

I'm also implementing a way to monitor objcache statistics.  So far,
I've hacked sth similar to
sysctl vm.zone: stats are returned in one giant string, one line per
cache.  That's simple but ugly and hard to read because there are
quite a few stats per cache.

So I'm thinking about implementing a small tool, ocstat, that extracts
stats from sysctl the way ps(1) does (thru libkvm iirc) and formats it
in various ways.  What do you think?

Cheers,
Nicolas

Index: src2/sys/kern/kern_exit.c
===================================================================
--- src2.orig/sys/kern/kern_exit.c	2008-03-31 08:05:59.139796000 +0200
+++ src2/sys/kern/kern_exit.c	2008-03-31 10:31:39.000000000 +0200
@@ -834,7 +834,7 @@ loop:
 			}

 			vm_waitproc(p);
-			zfree(proc_zone, p);
+			objcache_put(proc_cache, p);
 			nprocs--;
 			return (0);
 		}
Index: src2/sys/kern/kern_proc.c
===================================================================
--- src2.orig/sys/kern/kern_proc.c	2008-03-31 08:05:59.139918000 +0200
+++ src2/sys/kern/kern_proc.c	2008-03-31 10:31:39.000000000 +0200
@@ -84,7 +84,7 @@ u_long pgrphash;
 struct proclist allproc;
 struct proclist zombproc;
 struct spinlock allproc_spin;
-vm_zone_t proc_zone;
+struct objcache* proc_cache;
 vm_zone_t lwp_zone;
 vm_zone_t thread_zone;

@@ -131,7 +131,7 @@ procinit(void)
 	spin_init(&allproc_spin);
 	pidhashtbl = hashinit(maxproc / 4, M_PROC, &pidhash);
 	pgrphashtbl = hashinit(maxproc / 4, M_PROC, &pgrphash);
-	proc_zone = zinit("PROC", sizeof (struct proc), 0, 0, 5);
+	proc_cache = objcache_create_simple(M_PROC, sizeof(struct proc));
 	lwp_zone = zinit("LWP", sizeof (struct lwp), 0, 0, 5);
 	thread_zone = zinit("THREAD", sizeof (struct thread), 0, 0, 5);
 	uihashinit();
Index: src2/sys/sys/proc.h
===================================================================
--- src2.orig/sys/sys/proc.h	2008-03-31 08:05:59.140325000 +0200
+++ src2/sys/sys/proc.h	2008-03-31 10:31:39.000000000 +0200
@@ -473,7 +473,7 @@ struct proc *zpfind (pid_t);	/* Find zom
 struct vm_zone;
 struct globaldata;
 struct lwp_params;
-extern struct vm_zone *proc_zone;
+extern struct objcache *proc_cache;
 extern struct vm_zone *lwp_zone;

 int	enterpgrp (struct proc *p, pid_t pgid, int mksess);
Index: src2/sys/kern/kern_fork.c
===================================================================
--- src2.orig/sys/kern/kern_fork.c	2008-03-31 08:05:59.140042000 +0200
+++ src2/sys/kern/kern_fork.c	2008-03-31 10:31:39.000000000 +0200
@@ -332,7 +332,7 @@ fork1(struct lwp *lp1, int flags, struct
 	}

 	/* Allocate new proc. */
-	p2 = zalloc(proc_zone);
+	p2 = objcache_get(proc_cache, M_WAITOK);
 	bzero(p2, sizeof(*p2));

 	/*




From hsu at dragonflybsd.org  Mon Mar 31 11:44:34 2008
From: hsu at dragonflybsd.org (Jeffrey Hsu)
Date: Mon, 31 Mar 2008 11:44:34 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <64fc43b0803311126na7d0b27obaa9d35bac6d32ee@mail.gmail.com>
Message-ID: <200803311841.m2VIfQAI007579@nlpi001.prodigy.net>

The object cache is not a general-purpose memory allocator.  It's a cache of
pre-initialized objects.  Are the significant portions of the proc structure
that can be restored to initialized state on object puts?  If not, it's best
to just use a general-purpose memory allocator.

								Jeffrey




From corecode at fs.ei.tum.de  Mon Mar 31 12:07:02 2008
From: corecode at fs.ei.tum.de (Simon 'corecode' Schubert)
Date: Mon, 31 Mar 2008 12:07:02 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <200803311841.m2VIfQAI007579@nlpi001.prodigy.net>
Message-ID: <47F1357B.1070302@fs.ei.tum.de>

Jeffrey Hsu wrote:
> The object cache is not a general-purpose memory allocator.  It's a cache of
> pre-initialized objects.  Are the significant portions of the proc structure
> that can be restored to initialized state on object puts?  If not, it's best
> to just use a general-purpose memory allocator.

Why?  What's the loss if we use the object cache to allocate struct procs?

cheers
  simon

Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00006.pgp
Type: application/octet-stream
Size: 252 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080331/a4a24314/attachment-0008.obj>

From nthery at gmail.com  Mon Mar 31 12:17:03 2008
From: nthery at gmail.com (Nicolas Thery)
Date: Mon, 31 Mar 2008 12:17:03 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <nthery@gmail.com>
Message-ID: <64fc43b0803311214u7da6bbb8xaf971de1a80e7258@mail.gmail.com>

2008/3/31, Jeffrey Hsu <hsu at dragonflybsd.org>:
> The object cache is not a general-purpose memory allocator.  It's a cache of
>  pre-initialized objects.  Are the significant portions of the proc structure
>  that can be restored to initialized state on object puts?  If not, it's best
>  to just use a general-purpose memory allocator.

Well, I haven't checked this yet.  I planned to do this in a second
step after getting rid of zones.

I thought that even without  the pre-initialization part, objcache has
the advantage
of pre-allocating set of objects (as zones) and is additionally
mp-safe (contrary to zones and, granted, as malloc()).   The latter
may be interesting as we talk of improving MP support.

Cheers,
Nicolas




From dillon at apollo.backplane.com  Mon Mar 31 12:23:40 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Mon, 31 Mar 2008 12:23:40 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <200803311841.m2VIfQAI007579@nlpi001.prodigy.net>
Message-ID: <200803311921.m2VJLITB027669@apollo.backplane.com>

    I both agree and disagree with Jeff.  I think the only *disadvantage*
    to using objcache for struct proc is that objcache must cache a minimum
    number of free structures to be efficient so the overall kernel memory
    use would be a bit greater verses uses kmalloc().  But I agree with Jeff
    in that objcache's biggest advantage is that you can keep structural state
    intact and struct proc might not be a good candidate (yet).

    What I suggest is that you convert struct proc from zone to kmalloc
    first, and then look into a possible objcache adaptation.  kmalloc
    is not slow.. it's a very fast allocator.  Objcache is probably a tad
    faster but not by much.  Where objcache really wins is in not having
    to completey reinitialize the allocated structures.

    Over the years I've removed (I think) all the dependancies on requiring
    the proc structure to be in stable memory so I believe it can be moved to
    kmalloc/objcache now without any major pain.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From corecode at fs.ei.tum.de  Mon Mar 31 12:37:40 2008
From: corecode at fs.ei.tum.de (Simon 'corecode' Schubert)
Date: Mon, 31 Mar 2008 12:37:40 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: SoC student applications due by 5PM PDT tomorrow
In-Reply-To: <1942.192.168.0.242.1206930479.squirrel@www.shiningsilence.com>
Message-ID: <47F13CDA.6010703@fs.ei.tum.de>

Justin C. Sherrill wrote:
> On Sun, March 30, 2008 10:27 pm, Justin C. Sherrill wrote:
>> SoC students:
>>
>> If you have an application to submit for DragonFly/Summer of Code, please
>> do so by 17:00 Pacific time on the 31st - that's tomorrow, at least for
>> me.
> The deadline for student proposals has been extended to April 7th; all
> other dates move forward one week to acommodate.

This is very good.

Some more ideas for eager students (we want to keep the ratio, right?):

Enhance the FreeBSD/DragonFly sound infrastructure to support surround
sound/multichannel output.

Update sound drivers to support S/PDIF output.

Make the sound infrastructure OSSv4 compatible (there was a SoC at
FreeBSD last year or so)


of course only if it doesn't exist already :)

cheers
  simon


Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00007.pgp
Type: application/octet-stream
Size: 252 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080331/6da61cff/attachment-0008.obj>

From corecode at fs.ei.tum.de  Mon Mar 31 12:41:30 2008
From: corecode at fs.ei.tum.de (Simon 'corecode' Schubert)
Date: Mon, 31 Mar 2008 12:41:30 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <200803311841.m2VIfQAI007579@nlpi001.prodigy.net>
Message-ID: <47F13DE4.10205@fs.ei.tum.de>

Matthew Dillon wrote:
>     What I suggest is that you convert struct proc from zone to kmalloc
>     first, and then look into a possible objcache adaptation.  kmalloc
>     is not slow.. it's a very fast allocator.  Objcache is probably a tad
>     faster but not by much.  Where objcache really wins is in not having
>     to completey reinitialize the allocated structures.

Could we please not move to kmalloc, but instead try to move all fast
path allocations to objcache?  I don't like the idea of allocating
everything with kmalloc.  Caching struct procs is not a bad thing itself.

cheers
  simon


Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00008.pgp
Type: application/octet-stream
Size: 252 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080331/ac328c08/attachment-0008.obj>

From hsu at FreeBSD.org  Mon Mar 31 12:59:05 2008
From: hsu at FreeBSD.org (Jeffrey Hsu)
Date: Mon, 31 Mar 2008 12:59:05 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <47F1357B.1070302@fs.ei.tum.de>
Message-ID: <200803311920.m2VJK5Ln018015@nlpi015.prodigy.net>

The object cache sits on top of a general-purpose memory allocator such
as kmalloc or zalloc and provides pre-initialized object caching functionality.
If you're not going to use the object caching functionality, you can just
call the underlying memory allocator directly.

							Jeffrey




From dillon at apollo.backplane.com  Mon Mar 31 16:17:19 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Mon, 31 Mar 2008 16:17:19 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <200803311841.m2VIfQAI007579@nlpi001.prodigy.net>
Message-ID: <200803312311.m2VNBumd029866@apollo.backplane.com>

:Could we please not move to kmalloc, but instead try to move all fast
:path allocations to objcache?  I don't like the idea of allocating
:everything with kmalloc.  Caching struct procs is not a bad thing itself.=
:
:
:cheers
:  simon

    I will state for the record that I'm fine with either objcache or
    kmalloc.  I agree with Jeff that using objcache for struct proc
    probably isn't necessary but I also agree that it would not hurt either,
    and if the intent is to optimize the initialization of the proc
    structure in the future then moving to objcache now would save us
    from having to do it later.

    So whichever method Nicolas wants to use is fine with me.

						-Matt




From hsu at dragonflybsd.org  Mon Mar 31 19:22:47 2008
From: hsu at dragonflybsd.org (Jeffrey Hsu)
Date: Mon, 31 Mar 2008 19:22:47 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <64fc43b0803311214u7da6bbb8xaf971de1a80e7258@mail.gmail.com>
Message-ID: <200804010218.m312IVUq003624@nlpi043.prodigy.net>

  >> Are there significant portions of the proc structure
  >> that can be restored to initialized state on object puts?

  > I planned to do this in a second step after getting rid of zones.

I'll all in favor of making more use of caching pre-initialized objects, so
if this is your objective, then please go ahead.  It's just that I'd convert
over to the object cache in one step.

  > I thought that even without  the pre-initialization part, objcache has
  > the advantage of pre-allocating set of objects (as zones) and is additionally
  > mp-safe (contrary to zones and, granted, as malloc()).

Well, the zone allocator is MP-safe.  It's not hard to lock up the places that
manipulate the linked-list of free items. Look for uses of the zlock field.

								Jeffrey




From tgen at netphreax.net  Sat Mar  1 12:57:53 2008
From: tgen at netphreax.net (Thomas E. Spanjaard)
Date: Sat, 1 Mar 2008 12:57:53 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: [Fwd: Project Support Open Source: $50 donation to support you      project]
In-Reply-To: <2468.192.168.0.242.1204346451.squirrel@www.shiningsilence.com>
Message-ID: <47C9C1B7.50203@netphreax.net>

Justin C. Sherrill wrote:
The "donation" happens after you place an "acknowledgement" on an open
source project's web page.  I'm putting those words in scare quotes
because I think it's a "payment" for an "advertisement".  The supplied
link has nothing to do with DragonFly, to say the least.

<a href="http://www.2insure4less.com /" title="We support FOSS software
projects.">Online Insurance Quotes</a>
To think our souls are only worth $50...
--
        Thomas E. Spanjaard
        tgen at netphreax.net
Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00000.pgp
Type: application/octet-stream
Size: 186 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080301/0d61e240/attachment-0009.obj>

From c.turner at 199technologies.org  Sat Mar  1 17:52:31 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Sat, 1 Mar 2008 17:52:31 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Misc. ACPI / suspend
Message-ID: <47CA073B.6020106@199technologies.org>

Wondering if anyone more well versed in the ACPI implementation could
comment on the applicability of:
http://lkml.org/lkml/2007/4/6/69

w/r/t the current state of the art in Dfly

(or BSD's in general)

Cheers!

- Chris




From elekktretterr at exemail.com.au  Sun Mar  2 00:41:25 2008
From: elekktretterr at exemail.com.au (Petr Janda)
Date: Sun, 2 Mar 2008 00:41:25 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: CARP question
Message-ID: <200803021934.21669.elekktretterr@exemail.com.au>

So Ive setup CARP on 2 DF-based mailservers. Installation went fine. Box 1 has 
adskew of 0 therefore it is the MASTER. Box 2 has adskew of 254, therefore is 
BACKUP.  If i down the carp0 interface on Box 1, then Box 2 carp interface 
gets promoted to MASTER. Then I up the carp interface on Box 1, logically Box 
2 should become BACKUP again as Box 1 becomes MASTER due to adskew set to 0.

However it doesnt happen. When carp0 interface on Box 1 is upped it becomes a 
BACKUP, not a MASTER even though according to adskew it should be MASTER.

What is the desired behaviour?

Cheers
Petr




From qhwt+dfly at les.ath.cx  Sun Mar  2 02:50:14 2008
From: qhwt+dfly at les.ath.cx (YONETANI Tomokazu)
Date: Sun, 2 Mar 2008 02:50:14 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: panic: assertion: hammer_btree_cmp(cursor->left_bound,	&cursor->node->ondisk->elms[0].leaf.base) <= 0 in btree_split_leaf
In-Reply-To: <200802232204.m1NM4cxd046264@apollo.backplane.com>
Message-ID: <20080302104554.GA22813@les.ath.cx>

Hi.
While trying to find a procedure to reliably reproduce the panic
I reported last time, I caught a different panic (uploaded at
 ~y0netan1/crash/9/ on my leaf account).  I wrote the following shell
script (make sure to edit variables DISKS and MOUNTPT before using this
script or it may trash your system):
  #!/bin/sh -ex
  DISKS="/dev/ad0s1f"
  MOUNTPT=/mnt/HAMMER

  cd /
  newfs_hammer -L TEST $DISKS
  for i in `seq 1 100`; do
	  mount_hammer $DISKS $MOUNTPT
	  /bin/rm -rf $MOUNTPT/??
	  (set +x; for x in `seq 1 10000`; do echo -n > $MOUNTPT/$x; done)
	  umount $MOUNTPT
  done

And the panic is triggered by rm command.
I'll try to see if it's possible to reproduce the last one without
unmounting then mounting the HAMMER fs.

Cheers.




From dillon at apollo.backplane.com  Sun Mar  2 13:25:33 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Sun, 2 Mar 2008 13:25:33 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: panic: assertion: hammer_btree_cmp(cursor->left_bound,	&cursor->node->ondisk->elms[0].leaf.base) <= 0 in btree_split_leaf
In-Reply-To: <200802232204.m1NM4cxd046264@apollo.backplane.com>
Message-ID: <200803022119.m22LJRCY037076@apollo.backplane.com>


:Hi.
:While trying to find a procedure to reliably reproduce the panic
:I reported last time, I caught a different panic (uploaded at
: ~y0netan1/crash/9/ on my leaf account).  I wrote the following shell
:script (make sure to edit variables DISKS and MOUNTPT before using this
:script or it may trash your system):

(from the core)

panic: assertion: node->lock.refs == 0 && node->ondisk == NULL in hammer_flush_buffer_nodes

    Yah, I've seen this failure.  Add a sync or two before the umount and
    tell me if it still occurs.  It's either a node reference leak somewhere
    or it is a race between bufdaemon and umount.  The assertions are really
    strict there precisely to catch those sorts of cases.

    Also note that the code to deal with a full HAMMMER filesystem has not
    been written yet (The failure you are reporting is unrelated to a full
    HAMMER filesystem, though, just mentioning it).

						-Matt





From dillon at apollo.backplane.com  Sun Mar  2 13:29:03 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Sun, 2 Mar 2008 13:29:03 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Misc. ACPI / suspend
In-Reply-To: <47CA073B.6020106@199technologies.org>
Message-ID: <200803022126.m22LQbfI037188@apollo.backplane.com>


:Wondering if anyone more well versed in the ACPI implementation could
:comment on the applicability of:
:
:http://lkml.org/lkml/2007/4/6/69
:
:w/r/t the current state of the art in Dfly
:
:(or BSD's in general)
:
:Cheers!
:
:- Chris

    I really have no idea re: this.  Suspension in general is not well
    supported by any of the BSDs.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From dillon at apollo.backplane.com  Sun Mar  2 13:34:05 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Sun, 2 Mar 2008 13:34:05 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: [Fwd: Project Support Open Source: $50 donation to support you      project]
In-Reply-To: <2468.192.168.0.242.1204346451.squirrel@www.shiningsilence.com>
Message-ID: <200803022131.m22LVOe9037250@apollo.backplane.com>

:..
:source project's web page.  I'm putting those words in scare quotes
:because I think it's a "payment" for an "advertisement".  The supplied
:link has nothing to do with DragonFly, to say the least.
:
:I don't think this is a good idea, obviously, and replied to that effect. 
:However, I wanted to put this on a DragonFly list, in part to show this
:strange thing, and in part because I'm not comfortable making
:administrative decisions on behalf of the Project without being open as
:possible about it.

    It doesn't really cry out to me either.

						-Matt





From wbh at conducive.org  Sun Mar  2 20:36:32 2008
From: wbh at conducive.org (Bill Hacker)
Date: Mon, 03 Mar 2008 04:36:32 +0000
Subject: Misc. ACPI / suspend
In-Reply-To: <47CA073B.6020106@199technologies.org>
Message-ID: <47cb8050$0$855$415eb37d@crater_reader.dragonflybsd.org>

Matthew Dillon wrote:
:Wondering if anyone more well versed in the ACPI implementation could
:comment on the applicability of:
:
:http://lkml.org/lkml/2007/4/6/69
:
:w/r/t the current state of the art in Dfly
:
:(or BSD's in general)
:
:Cheers!
:
:- Chris
    I really have no idea re: this.  Suspension in general is not well
    supported by any of the BSDs.
					-Matt
					Matthew Dillon 
					<dillon at backplane.com>


. . and there seems to be a bit of a 'Catch 22' there in any case.

If the BIOS can alter 'stuff' out of site of the OS it is parking, what 
does the existence of such a 'feature' do to a(ny) security model?

Seems to at least beg creating the option of setting a flag to 
specifically *prevent* suspend-to-disk/hibernation (and/or force a 
reboot on wake-up).

Just because one is paranoid....  etc

Bill





From matthias at dragonflybsd.org  Tue Mar  4 02:30:52 2008
From: matthias at dragonflybsd.org (Matthias Schmidt)
Date: Tue, 4 Mar 2008 02:30:52 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
Message-ID: <20080304102335.GI9833@staatsfeind.org>

Hi,

Google just announced its Summer of Code for 2008:

	http://code.google.com/soc/2008/

I think this would be a great opportunity for DragonFly to participate
as a mentoring organisation.  We could attract new developers and could
get code/work done.  Looking at the SoC results of the other BSDs most
of their projects were a success.  Of course, not all, but a reasonable
percentage.  See [1] and [2].

It is some extra work for us, but IMO the benefits outweigh the extra
work.  And yes, I would volunteer as a mentor.  What do others
(developers) think?  Any more volunteers? :)

Some project ideas that come into my mind.  More ideas are listed in the
wiki:  http://wiki.dragonflybsd.org/index.cgi/ProjectsPage

 * Fix all remaining bugs in dma(8) and implement all missing features
 * Add a driver for newer Intel Wireless cards (I think sephe@ would
   love that :)
 * Bring our ACPI stuff in shape.  Maybe suspend2disk ...

 * [Add your own thoughts here]

Cheers,

	Matthias

PS: I don't want to create a bikeshed here whether you like the SoC or
not :)

[1] http://code.google.com/soc/2007/freebsd/about.html
[2] http://code.google.com/soc/2007/netbsd/about.html




From corecode at fs.ei.tum.de  Tue Mar  4 04:46:14 2008
From: corecode at fs.ei.tum.de (Simon 'corecode' Schubert)
Date: Tue, 4 Mar 2008 04:46:14 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47CD4386.1000704@fs.ei.tum.de>

Matthias Schmidt wrote:
>  * [Add your own thoughts here]

MP lock removal for network stack

and for the system  (first profile, find hot spots, fix hot spots, repeat)

cheers
  simon




From c.turner at 199technologies.org  Tue Mar  4 06:02:20 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Tue, 4 Mar 2008 06:02:20 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47CD551E.1040604@199technologies.org>

Matthias Schmidt wrote:
Some project ideas that come into my mind.  More ideas are listed in the
wiki:  http://wiki.dragonflybsd.org/index.cgi/ProjectsPage
+1 acpi
+1 interrupt routing
+1 SMP / giant removal
+1 pf synchup with openbsd
though there are several others on the page that are good..

need to dig up my wiki login and place appropriately..

also: thinking the ZFS port should be removed from the page - makes 
sense to everyone else? (e.g. fragments effort w/r/t hammer)





From tgen at netphreax.net  Tue Mar  4 06:54:31 2008
From: tgen at netphreax.net (Thomas E. Spanjaard)
Date: Tue, 4 Mar 2008 06:54:31 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47CD615F.8010209@netphreax.net>

Matthias Schmidt wrote:
Google just announced its Summer of Code for 2008:

 * [Add your own thoughts here]
x86-64 port :).
--
        Thomas E. Spanjaard
        tgen at netphreax.net
Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00001.pgp
Type: application/octet-stream
Size: 186 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080304/0d921000/attachment-0009.obj>

From rdivacky at FreeBSD.org  Tue Mar  4 07:07:03 2008
From: rdivacky at FreeBSD.org (Roman Divacky)
Date: Tue, 4 Mar 2008 07:07:03 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <20080304150255.GA8831@freebsd.org>

On Tue, Mar 04, 2008 at 02:49:03PM +0000, Thomas E. Spanjaard wrote:
> Matthias Schmidt wrote:
> >Google just announced its Summer of Code for 2008:
> >
> > * [Add your own thoughts here]
> 
> x86-64 port :).

all those ideas are great and needed etc. but keep in
mind that the projects should be doable by students
who might see dfly for the very first time.

don't overestimate whats possible and select projects
that look realistic

Roman Divacky (former SoC student)




From justin at shiningsilence.com  Tue Mar  4 08:32:56 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Tue, 4 Mar 2008 08:32:56 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <60322.65.106.147.226.1204648095.squirrel@www.shiningsilence.com>

On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
> Hi,
>
> Google just announced its Summer of Code for 2008:
>
> 	http://code.google.com/soc/2008/
>
> I think this would be a great opportunity for DragonFly to participate
> as a mentoring organisation.  We could attract new developers and could
> get code/work done.  Looking at the SoC results of the other BSDs most
> of their projects were a success.  Of course, not all, but a reasonable
> percentage.  See [1] and [2].

We've applied in previous years - Jeff Hsu did one year, and I put
together the application last year.  The hardest thing to find was
students (and they are the thing that helps SoC applications a lot, I
think).

Any student volunteers?  We have mentors.





From rluciani at gmail.com  Tue Mar  4 09:38:29 2008
From: rluciani at gmail.com (Robert Luciani)
Date: Tue, 04 Mar 2008 18:38:29 +0100
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47cd8915$0$854$415eb37d@crater_reader.dragonflybsd.org>

Justin C. Sherrill wrote:
> On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
>> Hi,
>>
>> Google just announced its Summer of Code for 2008:
>>
>> 	http://code.google.com/soc/2008/
>>
>> I think this would be a great opportunity for DragonFly to participate
>> as a mentoring organisation.  We could attract new developers and could
>> get code/work done.  Looking at the SoC results of the other BSDs most
>> of their projects were a success.  Of course, not all, but a reasonable
>> percentage.  See [1] and [2].
> 
> We've applied in previous years - Jeff Hsu did one year, and I put
> together the application last year.  The hardest thing to find was
> students (and they are the thing that helps SoC applications a lot, I
> think).
> 
> Any student volunteers?  We have mentors.
> 

bingo

-- 
Robert Luciani
Chalmers University of Technology, SWE
Department of Computer Science and Engineering
http://www.rluciani.com/public.key




From sdavtaker at gmail.com  Tue Mar  4 09:31:08 2008
From: sdavtaker at gmail.com (=?UTF-8?Q?Sd=C3=A4vtaker?=)
Date: Tue, 4 Mar 2008 09:31:08 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <c37d69f60803040926k206218a3kb8496d0cd18148bd@mail.gmail.com>

If you mentor, i will apply for coder :-)
Still in last year of university. :-)
Sdav

On Tue, Mar 4, 2008 at 1:28 PM, Justin C. Sherrill
<justin at shiningsilence.com> wrote:
> On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
>  > Hi,
>  >
>  > Google just announced its Summer of Code for 2008:
>  >
>  >       http://code.google.com/soc/2008/
>  >
>  > I think this would be a great opportunity for DragonFly to participate
>  > as a mentoring organisation.  We could attract new developers and could
>  > get code/work done.  Looking at the SoC results of the other BSDs most
>  > of their projects were a success.  Of course, not all, but a reasonable
>  > percentage.  See [1] and [2].
>
>  We've applied in previous years - Jeff Hsu did one year, and I put
>  together the application last year.  The hardest thing to find was
>  students (and they are the thing that helps SoC applications a lot, I
>  think).
>
>  Any student volunteers?  We have mentors.
>
>



-- 
Sd?vtaker prays to Rikku goddess for a good treasure.



From rluciani at gmail.com  Tue Mar  4 09:44:02 2008
From: rluciani at gmail.com (Robert Luciani)
Date: Tue, 04 Mar 2008 18:44:02 +0100
Subject: google soc "DragonFly"
Message-ID: <47cd8a63$0$855$415eb37d@crater_reader.dragonflybsd.org>

On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
> > Hi,
> >
> > Google just announced its Summer of Code for 2008:
> >
> > 	http://code.google.com/soc/2008/
> >
> > I think this would be a great opportunity for DragonFly to participate
> > as a mentoring organisation.  We could attract new developers and could
> > get code/work done.  Looking at the SoC results of the other BSDs most
> > of their projects were a success.  Of course, not all, but a reasonable
> > percentage.  See [1] and [2].

We've applied in previous years - Jeff Hsu did one year, and I put
together the application last year.  The hardest thing to find was
students (and they are the thing that helps SoC applications a lot, I
think).

Any student volunteers?  We have mentors.


-- 
Robert Luciani
Chalmers University of Technology, SWE
Department of Computer Science and Engineering
http://www.rluciani.com/public.key




From rluciani at gmail.com  Tue Mar  4 10:04:14 2008
From: rluciani at gmail.com (Robert Luciani)
Date: Tue, 04 Mar 2008 19:04:14 +0100
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47cd8f1f$0$856$415eb37d@crater_reader.dragonflybsd.org>

Robert Luciani wrote:
> Justin C. Sherrill wrote:
>> On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
>>> Hi,
>>>
>>> Google just announced its Summer of Code for 2008:
>>>
>>> 	http://code.google.com/soc/2008/
>>>
>>> I think this would be a great opportunity for DragonFly to participate
>>> as a mentoring organisation.  We could attract new developers and could
>>> get code/work done.  Looking at the SoC results of the other BSDs most
>>> of their projects were a success.  Of course, not all, but a reasonable
>>> percentage.  See [1] and [2].
>> We've applied in previous years - Jeff Hsu did one year, and I put
>> together the application last year.  The hardest thing to find was
>> students (and they are the thing that helps SoC applications a lot, I
>> think).
>>
>> Any student volunteers?  We have mentors.
>>
> 
> bingo
> 
My girlfriend Danwei noted that she would also like partake in the SoC.
She's studying IT here at Chalmers and will join the mailing list shortly.
-- 
Robert Luciani
Chalmers University of Technology, SWE
Department of Computer Science and Engineering
http://www.rluciani.com/public.key




From dillon at apollo.backplane.com  Tue Mar  4 13:08:30 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Tue, 4 Mar 2008 13:08:30 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Going to have to roll 1.12.1
Message-ID: <200803042104.m24L43g1065278@apollo.backplane.com>

    Due to a critical bug in sendmail that can cause it to seg-fault I will
    be rolling 1.12.1 as soon as I get verification that the current
    fix deals with it.

						-Matt





From sdavtaker at gmail.com  Tue Mar  4 17:40:43 2008
From: sdavtaker at gmail.com (=?UTF-8?B?U2TDpHZ0YWtlcg==?=)
Date: Tue, 4 Mar 2008 17:40:43 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: [Fwd: Project Support Open Source: $50 donation to support you  project]
In-Reply-To: <2468.192.168.0.242.1204346451.squirrel@www.shiningsilence.com>
Message-ID: <47CDF8D1.9070100@gmail.com>

50 bucks?
Come on...
You can get a meal a lot more expensive than that just going to a free 
HP conference about linux and you only have to rent your soul 3-5 hours ;-)
Sdav

Matthew Dillon escribi?:
:..
:source project's web page.  I'm putting those words in scare quotes
:because I think it's a "payment" for an "advertisement".  The supplied
:link has nothing to do with DragonFly, to say the least.
:
:I don't think this is a good idea, obviously, and replied to that effect. 
:However, I wanted to put this on a DragonFly list, in part to show this
:strange thing, and in part because I'm not comfortable making
:administrative decisions on behalf of the Project without being open as
:possible about it.

    It doesn't really cry out to me either.

						-Matt

  






From sdavtaker at gmail.com  Tue Mar  4 17:56:35 2008
From: sdavtaker at gmail.com (=?UTF-8?B?U2TDpHZ0YWtlcg==?=)
Date: Tue, 4 Mar 2008 17:56:35 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47CDFCCE.1010106@gmail.com>

A cute idea for for GSOC would be to finish the installer.
We were talking about this in my local BUG, we trying to find out how to 
help on that from here.
There is a few missing features in the CD.

   * FDISK, you need to create the slides from another OS before
     install DFBSD, i think port FDisk from FBSD or any *BSD will solve it.
   * Add to the make release a way to add some custom applications to
     the released liveCD (suppose you want to add nmap or ssh or
     something just to use as test disk in some enviroment).
   * Make the installer a little more customizable, and maybe w/ a GUI
     (I like a lot the console approach, but GUI installer will be a
     popularity move, DFBSD w/X makes a Desktop machine work, actually
     im using it that way and really like it).
I think those projects can be done in a SOC by students (like me) with a 
little guide.
Im a lot more interested in things network related and kernel, but i 
dont mind to work on those things, they need to be done some day.
What u think?
Sdav

Robert Luciani escribi?:
Robert Luciani wrote:
  
Justin C. Sherrill wrote:
    
On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
      
Hi,

Google just announced its Summer of Code for 2008:

	http://code.google.com/soc/2008/

I think this would be a great opportunity for DragonFly to participate
as a mentoring organisation.  We could attract new developers and could
get code/work done.  Looking at the SoC results of the other BSDs most
of their projects were a success.  Of course, not all, but a reasonable
percentage.  See [1] and [2].
        
We've applied in previous years - Jeff Hsu did one year, and I put
together the application last year.  The hardest thing to find was
students (and they are the thing that helps SoC applications a lot, I
think).
Any student volunteers?  We have mentors.

      
bingo

    
My girlfriend Danwei noted that she would also like partake in the SoC.
She's studying IT here at Chalmers and will join the mailing list shortly.
  






From c.turner at 199technologies.org  Tue Mar  4 18:30:53 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Tue, 4 Mar 2008 18:30:53 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47CE04C9.1010902@199technologies.org>

Justin C. Sherrill wrote:
together the application last year.  The hardest thing to find was
students (and they are the thing that helps SoC applications a lot, I
think).
umm.. if google wants to send me back to school, I'll sign up - hows 
that for a fair trade :?






From wbh at conducive.org  Tue Mar  4 23:52:13 2008
From: wbh at conducive.org (Bill Hacker)
Date: Wed, 05 Mar 2008 07:52:13 +0000
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47ce512e$0$855$415eb37d@crater_reader.dragonflybsd.org>

Sd?vtaker wrote:
A cute idea for for GSOC would be to finish the installer.
We were talking about this in my local BUG, we trying to find out how to 
help on that from here.
There is a few missing features in the CD.

   * FDISK, you need to create the slides from another OS before
     install DFBSD, i think port FDisk from FBSD or any *BSD will solve it.
I'd rather see that 'reversed' - i.e. - build a more capable fdisk in 
DFLY with hope that it might be seen worth importing into Free/Net/Open, 
or *at least* be able to do a more flexible job than those now do.

And disklabels as well. Hand in glove.

Here's why:

- At the moment, working with Free, Open, DFLY, and OpenSolaris on the 
same HDD requires a bit of acrobatics.

- There seems to now be greater divergence between/among the *BSD's as 
to being able to read each other's disklabels, mount and use each 
other's 'flavor' of FFS/UFS (not to mention Apple's implementation of 
UFS) than there is among the vast multitude of Linux ext2/3 denizens.

Even to the point where use of a *Linux* fs is the more universal way 
for being able to share mounts among the *BSD's. Think detached drives. 
And no - FAT is not all that practical for several reasons.

- DFLY currently has the most fine-grain ability to create slices and 
partitions. But the others cannot all (any?) read those.

'progress' w/r any of the *BSD's direction as to changes, improvements 
(or not) in their once-common-ancestry fs & disklabels need not be 
sacrificed.

I'm not holding out wish or hope for all players agreeing to return to 
'one sacred way'. Nor 'one new universal fs'. Neither is gonna happen.

But a 'legacy compatible' or least-common-denominator mode would do fine 
- most especially for portable / SAN devices.

So - how about a 'flexible' DFLY fdisk to go along with a 'flexible' 
disklabel that could adapt to whatever it found / was told to create?

JM2CW - but that *might* be a good place to get a cross-*BSD team together.

*snip* (other good stuff)

Bill Hacker




From matthias at dragonflybsd.org  Wed Mar  5 01:02:43 2008
From: matthias at dragonflybsd.org (Matthias Schmidt)
Date: Wed, 5 Mar 2008 01:02:43 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <20080305085747.GJ9833@staatsfeind.org>

Hi,

* Justin C. Sherrill wrote:
> 
> We've applied in previous years - Jeff Hsu did one year, and I put
> together the application last year.  The hardest thing to find was
> students (and they are the thing that helps SoC applications a lot, I
> think).

This is good to know, so we could coordinate that if we have enough
mentors and projects?!?  I put together a small text in the wiki:

http://wiki.dragonflybsd.org/index.cgi/GoogleSoC2008

Feel free to add project or missing stuff.  I'm sure I missed a lot of
things :)

> Any student volunteers?  We have mentors.

According to the discussion we could have some students, who would be a
mentor (besides me)?

Regards

	Matthias





From sdavtaker at gmail.com  Wed Mar  5 06:28:37 2008
From: sdavtaker at gmail.com (=?UTF-8?Q?Sd=C3=A4vtaker?=)
Date: Wed, 5 Mar 2008 06:28:37 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <c37d69f60803050624kd86d3d0w3b44a02d0e5a5391@mail.gmail.com>

<quote>
Write a driver (from scratch) for Intel 3945 wireless device
Mentor: Sepherosa Ziehau
</quote>

Yes yes yes, i want to :-)
Someone else planning to mentor in drivers coding?
Sdav

On Wed, Mar 5, 2008 at 5:57 AM, Matthias Schmidt
<matthias at dragonflybsd.org> wrote:
> Hi,
>
>
>  * Justin C. Sherrill wrote:
>  >
>  > We've applied in previous years - Jeff Hsu did one year, and I put
>  > together the application last year.  The hardest thing to find was
>  > students (and they are the thing that helps SoC applications a lot, I
>  > think).
>
>  This is good to know, so we could coordinate that if we have enough
>  mentors and projects?!?  I put together a small text in the wiki:
>
>  http://wiki.dragonflybsd.org/index.cgi/GoogleSoC2008
>
>  Feel free to add project or missing stuff.  I'm sure I missed a lot of
>  things :)
>
>
>  > Any student volunteers?  We have mentors.
>
>  According to the discussion we could have some students, who would be a
>  mentor (besides me)?
>
>  Regards
>
>         Matthias
>
>



-- 
Sd?vtaker prays to Rikku goddess for a good treasure.



From rluciani at gmail.com  Wed Mar  5 10:56:42 2008
From: rluciani at gmail.com (Robert Luciani)
Date: Wed, 05 Mar 2008 19:56:42 +0100
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47ceecea$0$847$415eb37d@crater_reader.dragonflybsd.org>

Sd?vtaker wrote:
> <quote>
> Write a driver (from scratch) for Intel 3945 wireless device
> Mentor: Sepherosa Ziehau
> </quote>
> 
> Yes yes yes, i want to :-)
> Someone else planning to mentor in drivers coding?
> Sdav
> 
> On Wed, Mar 5, 2008 at 5:57 AM, Matthias Schmidt
> <matthias at dragonflybsd.org> wrote:
>> Hi,
>>
>>
>>  * Justin C. Sherrill wrote:
>>  >
>>  > We've applied in previous years - Jeff Hsu did one year, and I put
>>  > together the application last year.  The hardest thing to find was
>>  > students (and they are the thing that helps SoC applications a lot, I
>>  > think).
>>
>>  This is good to know, so we could coordinate that if we have enough
>>  mentors and projects?!?  I put together a small text in the wiki:
>>
>>  http://wiki.dragonflybsd.org/index.cgi/GoogleSoC2008
>>
>>  Feel free to add project or missing stuff.  I'm sure I missed a lot of
>>  things :)
>>
>>
>>  > Any student volunteers?  We have mentors.
>>
>>  According to the discussion we could have some students, who would be a
>>  mentor (besides me)?
>>
>>  Regards
>>
>>         Matthias
>>
>>
> 
> 
>

IF someone starts to write a 3945 Intel driver,
please keep the newer 4965 in mind too.

-- 
Robert Luciani
Chalmers University of Technology, SWE
Department of Computer Science and Engineering
http://www.rluciani.com/public.key




From joerg at britannica.bec.de  Wed Mar  5 12:01:05 2008
From: joerg at britannica.bec.de (Joerg Sonnenberger)
Date: Wed, 5 Mar 2008 12:01:05 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <20080305195711.GA9981@britannica.bec.de>

On Wed, Mar 05, 2008 at 07:56:42PM +0100, Robert Luciani wrote:
> IF someone starts to write a 3945 Intel driver,
> please keep the newer 4965 in mind too.

NetBSD's wpi works quite well. The hardware is quite different from
4945.

Joerg




From sepherosa at gmail.com  Wed Mar  5 17:48:50 2008
From: sepherosa at gmail.com (Sepherosa Ziehau)
Date: Wed, 5 Mar 2008 17:48:50 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <ea7b9c170803051744u22b09484ofc994f034f11df3b@mail.gmail.com>

On Thu, Mar 6, 2008 at 2:56 AM, Robert Luciani <rluciani at gmail.com> wrote:
>  IF someone starts to write a 3945 Intel driver,

"IF" you know that trying to fix any wired bugs in certain drivers
(e.g. ipw, ral) will require you to read through all of the vendor's
linux code (yes, even including register values and position), i.e.
there is not much difference between writing one from scratch and
porting+fixing_bugs, then you probably will not put "IF" at the start
of your sentence.
If what I said sounded too harsh to you, then I was sorry.

>  please keep the newer 4965 in mind too.

Will do, once generic 11n support is brought in from freebsd.

Best Regards,
sephe

-- 
Live Free or Die




From saw at online.de  Thu Mar  6 05:34:14 2008
From: saw at online.de (Sascha Wildner)
Date: Thu, 06 Mar 2008 14:34:14 +0100
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
Message-ID: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>

Hi all,

this is probably as good a moment as any to come out of the forest with 
this. The patch at

http://leaf.dragonflybsd.org/~swildner/nrelease_gui.diff

adds some code to nrelease/ to build a LiveCD with xorg and so on 
(currently, only the xorg metapackages and fluxbox are added). In order 
to build one, you need a local dir with the pkgsrc binary packages (see 
below).

The following commands should then do the trick:

cd /usr/src
make buildworld
make buildkernel
cd nrelease
patch -p 0 </path/to/the/patch
make PKGSRC_PKG_PATH=/path/to/packages/dir/All realquick gui
The resulting ISO will be in /usr/release/dfly-gui.iso then. It will not 
boot into xorg automatically (although this is easily possible), so you 
need to login as root and do startx.

As of now, this all is kind of basic, more a proof of concept than 
anything else. As our release framework installs packages via chroot, 
the current setup just copies _all_ packages to the chroot before 
installing (kind of a hack).

That said, I'm now primarily interested in opinions/ideas/... about the 
direction this should take. Which packages would we like to see on the 
CD? Should it be a generic setup with the "most common things" 
installed, so a system can be quickly setup by the installer (which will 
cpdup /usr/pkg). Or should it be a more specialized set of tools? Or 
even as many packages as possible (Live DVD?). Etc., etc.

Before continuing on it, I'm really interested in people's input so 
don't hold anything back, please. :)

Sascha

--
http://yoyodyne.ath.cx



From rluciani at gmail.com  Thu Mar  6 06:42:03 2008
From: rluciani at gmail.com (Robert Luciani)
Date: Thu, 06 Mar 2008 15:42:03 +0100
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <47d002bc$0$847$415eb37d@crater_reader.dragonflybsd.org>

Sascha Wildner wrote:
> Hi all,
> 
> this is probably as good a moment as any to come out of the forest with
> this. The patch at
> 
> http://leaf.dragonflybsd.org/~swildner/nrelease_gui.diff
> 
> adds some code to nrelease/ to build a LiveCD with xorg and so on
> (currently, only the xorg metapackages and fluxbox are added). In order
> to build one, you need a local dir with the pkgsrc binary packages (see
> below).
> 
> The following commands should then do the trick:
> 
> cd /usr/src
> make buildworld
> make buildkernel
> cd nrelease
> patch -p 0 </path/to/the/patch
> make PKGSRC_PKG_PATH=/path/to/packages/dir/All realquick gui
> 
> The resulting ISO will be in /usr/release/dfly-gui.iso then. It will not
> boot into xorg automatically (although this is easily possible), so you
> need to login as root and do startx.
> 
> As of now, this all is kind of basic, more a proof of concept than
> anything else. As our release framework installs packages via chroot,
> the current setup just copies _all_ packages to the chroot before
> installing (kind of a hack).
> 
> That said, I'm now primarily interested in opinions/ideas/... about the
> direction this should take. Which packages would we like to see on the
> CD? Should it be a generic setup with the "most common things"
> installed, so a system can be quickly setup by the installer (which will
> cpdup /usr/pkg). Or should it be a more specialized set of tools? Or
> even as many packages as possible (Live DVD?). Etc., etc.
> 
> Before continuing on it, I'm really interested in people's input so
> don't hold anything back, please. :)
> 
> Sascha
> 

I think the main point of such a live-cd would be to test
dragonfly-specific features such as vkernels and more. Mplayer and
OpenOffic work the same on all platforms, so they might not be super
important, while irssi, firefox, networking tools, vim, a few more
shells/terminals might make it easier to for people to quickly gauge if
they can reproduce their current productivity and also what is new.

And if the point of a livecd is to test that kind of stuff, then it
would be nice for it to have a kernel that supports as much as possible
like ALTQ, and drivers.

Also if it has lots and lots of programs (thinking multimedia, java,
etc..) it might be hard to keep the future x64 and x86 live-cds on par.
Gentoo had this problem many years ago and it was very bothersome.

-- 
Robert Luciani
Chalmers University of Technology, SWE
Department of Computer Science and Engineering
http://www.rluciani.com/public.key




From matthias at dragonflybsd.org  Thu Mar  6 07:12:43 2008
From: matthias at dragonflybsd.org (Matthias Schmidt)
Date: Thu, 6 Mar 2008 07:12:43 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <20080306150757.GN9833@staatsfeind.org>

* Sascha Wildner wrote:
> Hi all,
> 
> this is probably as good a moment as any to come out of the forest with this. 
> The patch at
> 
> http://leaf.dragonflybsd.org/~swildner/nrelease_gui.diff
> 
> adds some code to nrelease/ to build a LiveCD with xorg and so on (currently, 
> only the xorg metapackages and fluxbox are added). In order to build one, you 
> need a local dir with the pkgsrc binary packages (see below).

Great work Sascha.

I agree with Robert on most of his stated points.
It would be nice to see some DragonFly specific features on the CD
(although I'm not sure if that will work for all features).  A little
environment where most Unix users feel at home (fluxbox, xfce, firefox,
thunderbird, gvim) should be enough.

Big applications like OO.org, java etc won't work because they are not
available as pkgsrc packages neither is it possible to compile them on
DragonFly.  At least to my knowledge.

Regards

	Matthias




From dillon at apollo.backplane.com  Thu Mar  6 09:31:52 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Thu, 6 Mar 2008 09:31:52 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <200803061728.m26HSR3O091809@apollo.backplane.com>


:Hi all,
:
:this is probably as good a moment as any to come out of the forest with 
:this. The patch at
:
:http://leaf.dragonflybsd.org/~swildner/nrelease_gui.diff
:
:adds some code to nrelease/ to build a LiveCD with xorg and so on 
:(currently, only the xorg metapackages and fluxbox are added). In order 
:to build one, you need a local dir with the pkgsrc binary packages (see 
:below).
:
:The following commands should then do the trick:

    It looks reasonable, though the package copy has to be tightened
    up a bit I think.

:...
:installed, so a system can be quickly setup by the installer (which will 
:cpdup /usr/pkg). Or should it be a more specialized set of tools? Or 
:even as many packages as possible (Live DVD?). Etc., etc.
:
:Before continuing on it, I'm really interested in people's input so 
:don't hold anything back, please. :)
:
:Sascha

    I think this is an excellent time to work up a DVD build and to
    add various 'flavor' extras.  So, e.g.:

	make installer gui gui_extras release dvd

    (All 'dvd' would do is generate a dvd compatible image for burning to
    dvd instead of cd).  I did a quick perusal of what I have on my
    workstation:

    * X
    * Firefox
    * Linux emulation
    * Open Office (linux version)
    * fvwm2
    * xpdf
    * freetype2

    I'd also suggest some image editing tools like gimp, and maybe the KDE
    gui suite.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From justin at shiningsilence.com  Thu Mar  6 09:42:44 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Thu, 6 Mar 2008 09:42:44 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <55427.65.106.147.226.1204825168.squirrel@www.shiningsilence.com>

On Thu, March 6, 2008 8:34 am, Sascha Wildner wrote:

> That said, I'm now primarily interested in opinions/ideas/... about the
> direction this should take. Which packages would we like to see on the
> CD? Should it be a generic setup with the "most common things"
> installed, so a system can be quickly setup by the installer (which will
> cpdup /usr/pkg). Or should it be a more specialized set of tools? Or
> even as many packages as possible (Live DVD?). Etc., etc.

What Robert said is good - whatever's needed to enable DragonFly-specific
features.  Along with that would be some sort of documentation (a README? 
A HTML file on whatever desktop we provide) that points people at the
different DragonFly tools, so they know what to try and how to try it.

There's going to be some percentage of people who try DragonFly who don't
know about vkernels, for instance, but there's our chance to educate them.
 I'm probably volunteering myself, aren't I?





From sdavtaker at gmail.com  Thu Mar  6 09:50:09 2008
From: sdavtaker at gmail.com (=?UTF-8?Q?Sd=C3=A4vtaker?=)
Date: Thu, 6 Mar 2008 09:50:09 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <c37d69f60803060947t110750c0sd6b542ea505d188d@mail.gmail.com>

Cool Sascha :-)
I just posted about this 1 or 2 days ago in the SOC project ideas thread.
Want to mentor this one? ;-)
Damian

On Thu, Mar 6, 2008 at 2:28 PM, Matthew Dillon
<dillon at apollo.backplane.com> wrote:
>
>  :Hi all,
>
> :
>  :this is probably as good a moment as any to come out of the forest with
>  :this. The patch at
>  :
>  :http://leaf.dragonflybsd.org/~swildner/nrelease_gui.diff
>  :
>  :adds some code to nrelease/ to build a LiveCD with xorg and so on
>  :(currently, only the xorg metapackages and fluxbox are added). In order
>  :to build one, you need a local dir with the pkgsrc binary packages (see
>  :below).
>  :
>  :The following commands should then do the trick:
>
>     It looks reasonable, though the package copy has to be tightened
>     up a bit I think.
>
>  :...
>  :installed, so a system can be quickly setup by the installer (which will
>
> :cpdup /usr/pkg). Or should it be a more specialized set of tools? Or
>  :even as many packages as possible (Live DVD?). Etc., etc.
>  :
>  :Before continuing on it, I'm really interested in people's input so
>  :don't hold anything back, please. :)
>  :
>  :Sascha
>
>     I think this is an excellent time to work up a DVD build and to
>     add various 'flavor' extras.  So, e.g.:
>
>         make installer gui gui_extras release dvd
>
>     (All 'dvd' would do is generate a dvd compatible image for burning to
>     dvd instead of cd).  I did a quick perusal of what I have on my
>     workstation:
>
>     * X
>     * Firefox
>     * Linux emulation
>     * Open Office (linux version)
>     * fvwm2
>     * xpdf
>     * freetype2
>
>     I'd also suggest some image editing tools like gimp, and maybe the KDE
>     gui suite.
>
>                                         -Matt
>                                         Matthew Dillon
>                                         <dillon at backplane.com>
>



-- 
Sd?vtaker prays to Rikku goddess for a good treasure.



From saw at online.de  Thu Mar  6 11:54:01 2008
From: saw at online.de (Sascha Wildner)
Date: Thu, 06 Mar 2008 20:54:01 +0100
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <47d04ba2$0$856$415eb37d@crater_reader.dragonflybsd.org>

Matthew Dillon wrote:
    It looks reasonable, though the package copy has to be tightened
    up a bit I think.
It looks as if it would work with mount_null'ing the chroot's 
/tmp/packages. I'll have a better patch ready tomorrow.

Sascha

--
http://yoyodyne.ath.cx



From c.turner at 199technologies.org  Thu Mar  6 19:11:44 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Thu, 6 Mar 2008 19:11:44 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Misc. ACPI / suspend
In-Reply-To: <47CA073B.6020106@199technologies.org>
Message-ID: <47D0B079.3060905@199technologies.org>

Chris Turner wrote:
Wondering if anyone more well versed in the ACPI implementation could
comment on the applicability of:
http://lkml.org/lkml/2007/4/6/69

Doing a little digging, it seems like

. /platform/pc32/i386/i686_mem.c

*might* have the necessary infrastructure to remap the MTRR's per the 
thread referenced,

but:

. /platform/pc32/acpica5/acpi_wakeup.c

doesn't seem to be using this infrastructure..

I'm no where near reaching an understanding of this yet,
but I'm wondering 3 things:
1) does anyone have ACPI (instead of APM)
   sleep / suspend / wakeup working on Dfly ?
2) If so, what machines are being used ?
3) Same question for other BSDs - my understanding is NetBSD is most
   'advanced' w/r/t power managment - but I'm not 100% on this ...
would looove to have a sleeping / resuming / scaling laptop running some 
BSD flavor.. am willing to work towards that end, esp. w/r/t Dfly -
trying to chart a course to figguring this out.

Thanks all,

- Chris




From c.turner at 199technologies.org  Thu Mar  6 19:12:33 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Thu, 6 Mar 2008 19:12:33 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: PCI Bios / Interrupt remapping / etc
Message-ID: <47D0B211.6000002@199technologies.org>

Doing a bit of digging here for my long-standing CBB+SIO interupt and 
buffer problem -

one machine I've tested against was an OpenBSD machine, which didn't
always work to handle the cardbus sio card on a PCI cardbus adapter
-

tuning up some of the device flags in:

http://www.openbsd.org/cgi-bin/man.cgi?query=pcibios&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=html

seems to have alleviated the problem for that os..

I'm just only starting to get up to speed on how DF handles these types 
of things (namely initial PIC / interrupt layout at boot time device 
enumeration), but am wondering if anyone familiar with this area of the 
code has any comments / advice w/r/t the capabilities of the DF bios 
drivers
and the various quirks / fixup mentioned in the link above..

looking to possibly investigate fixing up some of these issues over time.

Thanks

- Chris







From pavalos at theshell.com  Fri Mar  7 01:14:55 2008
From: pavalos at theshell.com (Peter Avalos)
Date: Fri, 7 Mar 2008 01:14:55 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: cam locking
Message-ID: <20080307091024.GC1652@ylem.theshell.com>

So I've been working on locking up cam using lockmgr locks, and here's
what I have so far:

http://www.theshell.com/~pavalos/wip/cam-lock.patch

Most of the work is obtained from FreeBSD.  I've only been running this
on my SCSI machine for a day, but because the patch is so large, I wanted
to make it available for people to review if they have some spare time.

Thanks,
Peter
Attachment:
pgp00002.pgp
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00002.pgp
Type: application/octet-stream
Size: 197 bytes
Desc: "Description: PGP signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080307/9a17ecd8/attachment-0009.obj>

From jspringe at uos.de  Fri Mar  7 03:25:17 2008
From: jspringe at uos.de (Jost Tobias Springenberg)
Date: Fri, 7 Mar 2008 12:25:17 +0100
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <20080307122517.72c9e2b1.jspringe@uos.de>

On Tue, 4 Mar 2008 11:28:15 -0500 (EST)
"Justin C. Sherrill" <justin at shiningsilence.com> wrote:

> On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
> > Hi,
> >
> > Google just announced its Summer of Code for 2008:
> >
> > 	http://code.google.com/soc/2008/
> >
> > I think this would be a great opportunity for DragonFly to participate
> > as a mentoring organisation.  We could attract new developers and could
> > get code/work done.  Looking at the SoC results of the other BSDs most
> > of their projects were a success.  Of course, not all, but a reasonable
> > percentage.  See [1] and [2].
> 
> We've applied in previous years - Jeff Hsu did one year, and I put
> together the application last year.  The hardest thing to find was
> students (and they are the thing that helps SoC applications a lot, I
> think).
> 
> Any student volunteers?  We have mentors.
> 

I read this mailing list for quite a while now and thought about contributing stuff
to DFfly several times, so yes why not take this opportunity if it's there.

-- 
Jost Tobias Springenberg <jspringe at uos.de>




From tgen at netphreax.net  Fri Mar  7 05:17:27 2008
From: tgen at netphreax.net (Thomas E. Spanjaard)
Date: Fri, 7 Mar 2008 05:17:27 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: PCI Bios / Interrupt remapping / etc
In-Reply-To: <47D0B211.6000002@199technologies.org>
Message-ID: <47D13FB4.5080306@netphreax.net>

Chris Turner wrote:
Doing a bit of digging here for my long-standing CBB+SIO interupt and 
buffer problem -

one machine I've tested against was an OpenBSD machine, which didn't
always work to handle the cardbus sio card on a PCI cardbus adapter
-

tuning up some of the device flags in:

http://www.openbsd.org/cgi-bin/man.cgi?query=pcibios&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=html 

seems to have alleviated the problem for that os..

I'm just only starting to get up to speed on how DF handles these types 
of things (namely initial PIC / interrupt layout at boot time device 
enumeration), but am wondering if anyone familiar with this area of the 
code has any comments / advice w/r/t the capabilities of the DF bios 
drivers
and the various quirks / fixup mentioned in the link above..

looking to possibly investigate fixing up some of these issues over time.
Our code that handles issues like this (in cases where you're not using 
APICs, just PICs and PIRs) lives in bus/pci/i386/. Not that running 
without APIC support is all that common on modern machines anymore...
--
        Thomas E. Spanjaard
        tgen at netphreax.net
Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00003.pgp
Type: application/octet-stream
Size: 186 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080307/61366b5c/attachment-0009.obj>

From tgen at netphreax.net  Fri Mar  7 05:16:51 2008
From: tgen at netphreax.net (Thomas E. Spanjaard)
Date: Fri, 7 Mar 2008 05:16:51 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Misc. ACPI / suspend
In-Reply-To: <47CA073B.6020106@199technologies.org>
Message-ID: <47D13F07.9080308@netphreax.net>

Chris Turner wrote:
1) does anyone have ACPI (instead of APM)
   sleep / suspend / wakeup working on Dfly ?
2) If so, what machines are being used ?
3) Same question for other BSDs - my understanding is NetBSD is most
   'advanced' w/r/t power managment - but I'm not 100% on this ...
would looove to have a sleeping / resuming / scaling laptop running some 
BSD flavor.. am willing to work towards that end, esp. w/r/t Dfly -
trying to chart a course to figguring this out.
I have ACPI S3 suspend working like a charm on my IBM ThinkPad R40 
(Pentium M "Banias" 1.3GHz, speedstepping works just fine), running 
NetBSD 3.99.21.
--
        Thomas E. Spanjaard
        tgen at netphreax.net
Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00004.pgp
Type: application/octet-stream
Size: 186 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080307/de3e5104/attachment-0009.obj>

From civilizd at gmail.com  Fri Mar  7 09:06:41 2008
From: civilizd at gmail.com (Vita "CiV" Cizek)
Date: Fri, 7 Mar 2008 09:06:41 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <98d564710803070853q1c73d795m6e6c5cc5049fa099@mail.gmail.com>

>  Any student volunteers?  We have mentors.
>
I am interested too, especially in some kernel-related work.




From justin at shiningsilence.com  Sat Mar  8 12:07:51 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Sat, 8 Mar 2008 12:07:51 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google SoC 2008 - mentors mentors mentors
Message-ID: <51558.192.168.0.252.1205006403.squirrel@www.shiningsilence.com>

If you are willing to mentor for the Google 2008 Summer of Code, please
speak up.  Right now we have: (from our wiki page)

Matthias
Sephe
TGEN
corecode

Part of the application process includes naming people as mentors (student
applications come later), so I want to get as complete a list as possible.

The application is due on the 12th, so if you want to mentor, now's the
time to say so.

Google's SoC FAQ is here: http://code.google.com/soc/2008/faqs.html

Our wiki page is here: http://wiki.dragonflybsd.org/index.cgi/GoogleSoC2008

- much credit to Matthias and others for getting that set up.





From saw at online.de  Sat Mar  8 14:26:07 2008
From: saw at online.de (Sascha Wildner)
Date: Sat, 08 Mar 2008 23:26:07 +0100
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <47d31245$0$848$415eb37d@crater_reader.dragonflybsd.org>

Sascha Wildner wrote:
Hi all,

this is probably as good a moment as any to come out of the forest with 
this. The patch at

http://leaf.dragonflybsd.org/~swildner/nrelease_gui.diff
Ok, I have committed the stuff as an example.

I'm not sure if my free time permits to work on a full-blown live CD 
with X11 and other good things (I already feel my interest wandering off 
in other directions) so if anyone wants to pick up the ball, go ahead. :)

Sascha

--
http://yoyodyne.ath.cx



From qhwt+dfly at les.ath.cx  Tue Mar 11 22:21:31 2008
From: qhwt+dfly at les.ath.cx (YONETANI Tomokazu)
Date: Tue, 11 Mar 2008 22:21:31 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Misc. ACPI / suspend
In-Reply-To: <47CA073B.6020106@199technologies.org>
Message-ID: <20080312051219.GA56091@les.ath.cx>

On Thu, Mar 06, 2008 at 10:03:21PM -0500, Chris Turner wrote:
> 1) does anyone have ACPI (instead of APM)
>    sleep / suspend / wakeup working on Dfly ?
> 2) If so, what machines are being used ?

Dynabook SS3500 (http://www.tlt.co.jp/pc/catalog/ss/02110735/index_j.htm).
It's old and can get very hot(thus frequently turns on the cooling fan)
even when it's running Windows.  I haven't turned it on for about several
months though.

Cheers.




From c.turner at 199technologies.org  Wed Mar 12 04:37:22 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Wed, 12 Mar 2008 04:37:22 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Misc. ACPI / suspend
In-Reply-To: <47CA073B.6020106@199technologies.org>
Message-ID: <47D7BEE3.6010907@199technologies.org>

YONETANI Tomokazu wrote:
On Thu, Mar 06, 2008 at 10:03:21PM -0500, Chris Turner wrote:
1) does anyone have ACPI (instead of APM)
   sleep / suspend / wakeup working on Dfly ?
Cheers.
ditto..

Suppose this should go to docs@ - in any case..

Thinking about setting up a wiki page on the issue so we
can discuss / track what 'good' hardware / drivers / implementations / 
etc are 'out there' - anyone have any suggestions on where this should
go?

http://wiki.dragonflybsd.org/index.cgi/acpi-overview.html

Remains from the handbook conversion - but I'm hesitant to 'over wikify'
this ..



From c.turner at 199technologies.org  Wed Mar 12 15:36:52 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Wed, 12 Mar 2008 15:36:52 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: devel/cscope
Message-ID: <47D85A08.8040103@199technologies.org>

why oh why did I take so long to try this out !!!

just sharing my eureka moment with the list..

- Chris




From dudu at dudu.ro  Wed Mar 12 15:50:14 2008
From: dudu at dudu.ro (Vlad GALU)
Date: Wed, 12 Mar 2008 15:50:14 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: devel/cscope
In-Reply-To: <47D85A08.8040103@199technologies.org>
Message-ID: <ad79ad6b0803121547r2bf67ffep9e40badaac6490f8@mail.gmail.com>

On 3/13/08, Chris Turner <c.turner at 199technologies.org> wrote:
> why oh why did I take so long to try this out !!!
>
>  just sharing my eureka moment with the list..


    Works nice with vim, too!

>
>
>  - Chris
>


-- 
Mahnahmahnah!




From justin at shiningsilence.com  Sun Mar 16 21:06:13 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Sun, 16 Mar 2008 21:06:13 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: binary packages for 1.12 coming in
Message-ID: <1372.192.168.0.252.1205726088.squirrel@www.shiningsilence.com>

The binary build for 1.12 is taking quite a while.  I've started copying
in newly built packages to
pkgbox.dragonflybsd.org/packages/DragonFly-1.12/i386/ - this should be
getting copied out to mirrors over the next while.

There are currently 1283 packages built, which leaves a whole lot to go;
I'll copy new packages in as they complete.





From hasso at estpak.ee  Wed Mar 19 04:31:08 2008
From: hasso at estpak.ee (Hasso Tepper)
Date: Wed, 19 Mar 2008 04:31:08 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Some questions regarding ACPI
Message-ID: <200803191322.46366.hasso@estpak.ee>

I'm working on bringing in some laptop (and especially thinkpad) specific 
ACPI code from FreeBSD into DragonFly. I never touched ACPI stuff before 
and haven't followed it much either, so I have some questions.

* FreeBSD uses ACPI_SERIAL_* heavily. What's the locking situation in 
  DragonFly and why?

* As far as I can see, PCI integration is commented out in DragonFly. 
  What's the state of it and why?

* platform/pc32/acpica5/acpi_toshiba.c - why is it there? I don't think 
  that this is something pc32 specific in it and it should work in pc64 
  laptops as well. Any objections to move it into 
  dev/acpica5/acpi_toshiba/ ?

What's the current status of ACPI in general? AFAICS our acpica is quite 
old - what needs to be done to bring in newer one?


-- 
Hasso




From qhwt+dfly at les.ath.cx  Wed Mar 19 09:24:50 2008
From: qhwt+dfly at les.ath.cx (YONETANI Tomokazu)
Date: Wed, 19 Mar 2008 09:24:50 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Some questions regarding ACPI
In-Reply-To: <200803191322.46366.hasso@estpak.ee>
Message-ID: <20080319161703.GA51509@les.ath.cx>

On Wed, Mar 19, 2008 at 01:22:46PM +0200, Hasso Tepper wrote:
> I'm working on bringing in some laptop (and especially thinkpad) specific 
> ACPI code from FreeBSD into DragonFly. I never touched ACPI stuff before 
> and haven't followed it much either, so I have some questions.

So you want to port some of ACPI support drivers, or to do a fresh port
of ACPI driver from FreeBSD?

> * FreeBSD uses ACPI_SERIAL_* heavily. What's the locking situation in 
>   DragonFly and why?

The current ACPI driver in DragonFly is based on that of FreeBSD as of
end of June, 2004, plus some fixes brought in later (and ACPICA part
has been updated twice since then).  That was before they introduced
the MPSAFE changes into ACPI code, and we use critical section
(crit_{enter,exit}) in most places (and lockmgr lock in a few place).

> * As far as I can see, PCI integration is commented out in DragonFly. 
>   What's the state of it and why?

When we replaced the implementation taken from FreeBSD 4.x with that
brought from FreeBSD 5.x, which added the PCI part, many people
experienced problems until they turned off ACPI completely, or add "pci"
to "debug.acpi.disabled" loader variable.  AFAIK the PCI part in the ACPI
driver almost hasn't been adjusted to work with our version of PCI code.

> * platform/pc32/acpica5/acpi_toshiba.c - why is it there? I don't think 
>   that this is something pc32 specific in it and it should work in pc64 
>   laptops as well. Any objections to move it into 
>   dev/acpica5/acpi_toshiba/ ?

In FreeBSD it used to be sitting at i386/acpica/acpi_toshiba.c and was
later moved into acpi_support.  That change hasn't hit our tree (in fact,
we have no acpi support drivers other than that).  It seems that FreeBSD
has them in dev/acpi_support now, and we for some reason have that
directory in our CVS repository (but containing no files in it).

> What's the current status of ACPI in general? AFAICS our acpica is quite 
> old - what needs to be done to bring in newer one?

Actually, it's not very important to keep just ACPICA latest, but
if you bring the ACPI driver from FreeBSD you need to bring ACPICA code
that matches their version, and it IS important.  And it generally requires
you much work to just update ACPICA part anyway because of how they
change things on every release.

Cheers.




From hasso at estpak.ee  Wed Mar 19 12:29:52 2008
From: hasso at estpak.ee (Hasso Tepper)
Date: Wed, 19 Mar 2008 12:29:52 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Some questions regarding ACPI
In-Reply-To: <200803191322.46366.hasso@estpak.ee>
Message-ID: <200803192115.35396.hasso@estpak.ee>

YONETANI Tomokazu wrote:
> On Wed, Mar 19, 2008 at 01:22:46PM +0200, Hasso Tepper wrote:
> > I'm working on bringing in some laptop (and especially thinkpad)
> > specific ACPI code from FreeBSD into DragonFly. I never touched ACPI
> > stuff before and haven't followed it much either, so I have some
> > questions.
>
> So you want to port some of ACPI support drivers, or to do a fresh port
> of ACPI driver from FreeBSD?

I'm only interested in support drivers and the reason is pure practical - 
newer thinkpads handle less and less hotkeys etc in hardware and require 
support form OS. acpi_ibm and acpi_video are examples of such modules 
which would help a lot of these newer thinkpad users.

acpi_ibm is almost ready to commit (renamed to acpi_thinkpad though).

> > * FreeBSD uses ACPI_SERIAL_* heavily. What's the locking situation in
> >   DragonFly and why?
>
> The current ACPI driver in DragonFly is based on that of FreeBSD as of
> end of June, 2004, plus some fixes brought in later (and ACPICA part
> has been updated twice since then).  That was before they introduced
> the MPSAFE changes into ACPI code, and we use critical section
> (crit_{enter,exit}) in most places (and lockmgr lock in a few place).

Mkay. Will look at more closely.

> > * As far as I can see, PCI integration is commented out in DragonFly.
> >   What's the state of it and why?
>
> When we replaced the implementation taken from FreeBSD 4.x with that
> brought from FreeBSD 5.x, which added the PCI part, many people
> experienced problems until they turned off ACPI completely, or add
> "pci" to "debug.acpi.disabled" loader variable.  AFAIK the PCI part in
> the ACPI driver almost hasn't been adjusted to work with our version of
> PCI code.

I'm afraid that it's beyond my skills, but while looking at acpi_video I 
discovered that it's hard to handle correctly without PCI support.

> > * platform/pc32/acpica5/acpi_toshiba.c - why is it there? I don't
> > think that this is something pc32 specific in it and it should work
> > in pc64 laptops as well. Any objections to move it into
> >   dev/acpica5/acpi_toshiba/ ?
>
> In FreeBSD it used to be sitting at i386/acpica/acpi_toshiba.c and was
> later moved into acpi_support.  That change hasn't hit our tree (in
> fact, we have no acpi support drivers other than that).  It seems that
> FreeBSD has them in dev/acpi_support now, and we for some reason have
> that directory in our CVS repository (but containing no files in it).

I don't see it ;). Makes sense though. So, any objections if I move 
acpi_toshiba into sys/dev/acpi_support and add new acpi_thinkpad there as 
well? 

> > What's the current status of ACPI in general? AFAICS our acpica is
> > quite old - what needs to be done to bring in newer one?
>
> Actually, it's not very important to keep just ACPICA latest, but
> if you bring the ACPI driver from FreeBSD you need to bring ACPICA code
> that matches their version, and it IS important.  And it generally
> requires you much work to just update ACPICA part anyway because of how
> they change things on every release.

Someone else has to do it :).

Thanks for info.


-- 
Hasso




From dillon at apollo.backplane.com  Wed Mar 19 14:01:13 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Wed, 19 Mar 2008 14:01:13 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: panic: assertion: hammer_btree_cmp(cursor->left_bound,	&cursor->node->ondisk->elms[0].leaf.base) <= 0 in btree_split_leaf
In-Reply-To: <200802232204.m1NM4cxd046264@apollo.backplane.com>
Message-ID: <200803192054.m2JKsjwn045137@apollo.backplane.com>


:Hi.
:While trying to find a procedure to reliably reproduce the panic
:I reported last time, I caught a different panic (uploaded at
: ~y0netan1/crash/9/ on my leaf account).  I wrote the following shell
:script (make sure to edit variables DISKS and MOUNTPT before using this
:script or it may trash your system):
:  #!/bin/sh -ex
:  DISKS="/dev/ad0s1f"
:  MOUNTPT=/mnt/HAMMER
:
:  cd /
:  newfs_hammer -L TEST $DISKS
:  for i in `seq 1 100`; do
:..
:And the panic is triggered by rm command.
:I'll try to see if it's possible to reproduce the last one without
:unmounting then mounting the HAMMER fs.
:
:Cheers.

    I believe I have fixed this panic.  hammer_make_separator() had a bug
    in it.

    There is still an issue with the node ref count on umount.

    Please continue to life-test the code.  The reblocking code
    (hammer reblock /mnt) should work now, as should the pruning code
    (e.g. hammer prune /mnt everything).

    The filesystem full case is still not handled and will cause bad things
    to happen.  The undo code isn't finished yet either but it is getting
    there (it's writing stuff out but not setting the sequence number and
    not trying to recover-on-mount yet).

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From qhwt+dfly at les.ath.cx  Wed Mar 19 19:45:40 2008
From: qhwt+dfly at les.ath.cx (YONETANI Tomokazu)
Date: Wed, 19 Mar 2008 19:45:40 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Some questions regarding ACPI
In-Reply-To: <200803191322.46366.hasso@estpak.ee>
Message-ID: <20080320023828.GA53648@les.ath.cx>

On Wed, Mar 19, 2008 at 09:15:35PM +0200, Hasso Tepper wrote:
> YONETANI Tomokazu wrote:
> > On Wed, Mar 19, 2008 at 01:22:46PM +0200, Hasso Tepper wrote:
> > > I'm working on bringing in some laptop (and especially thinkpad)
> > > specific ACPI code from FreeBSD into DragonFly. I never touched ACPI
> > > stuff before and haven't followed it much either, so I have some
> > > questions.
> >
> > So you want to port some of ACPI support drivers, or to do a fresh port
> > of ACPI driver from FreeBSD?
> 
> I'm only interested in support drivers and the reason is pure practical - 
> newer thinkpads handle less and less hotkeys etc in hardware and require 
> support form OS. acpi_ibm and acpi_video are examples of such modules 
> which would help a lot of these newer thinkpad users.
> 
> acpi_ibm is almost ready to commit (renamed to acpi_thinkpad though).

Ah, that's a good news!  My only concern is that ISTR someone mentioned
me that his colleague was thinking about porting ACPI driver itself,
so if you're not the person you may want to collaborate with him/her
so as not to waste the effort or time...

			:

> > In FreeBSD it used to be sitting at i386/acpica/acpi_toshiba.c and was
> > later moved into acpi_support.  That change hasn't hit our tree (in
> > fact, we have no acpi support drivers other than that).  It seems that
> > FreeBSD has them in dev/acpi_support now, and we for some reason have
> > that directory in our CVS repository (but containing no files in it).
> 
> I don't see it ;). Makes sense though. So, any objections if I move 
> acpi_toshiba into sys/dev/acpi_support and add new acpi_thinkpad there as 
> well? 

Sorry, I checked the CVS repository and it doesn't exist actually :)
I don't have any objection to moving it there.

Cheers.




From hasso at estpak.ee  Thu Mar 20 00:14:05 2008
From: hasso at estpak.ee (Hasso Tepper)
Date: Thu, 20 Mar 2008 00:14:05 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Some questions regarding ACPI
In-Reply-To: <200803191322.46366.hasso@estpak.ee>
Message-ID: <200803200904.50875.hasso@estpak.ee>

YONETANI Tomokazu wrote:
> On Wed, Mar 19, 2008 at 09:15:35PM +0200, Hasso Tepper wrote:
> > acpi_ibm is almost ready to commit (renamed to acpi_thinkpad though).
>
> Ah, that's a good news!  My only concern is that ISTR someone mentioned
> me that his colleague was thinking about porting ACPI driver itself,
> so if you're not the person you may want to collaborate with him/her
> so as not to waste the effort or time...

Current state in my repo is attached. It should work on 1.12 as well as it 
doesn't depend yet on moving stuff around.

add-acpi-if-m.patch adds some new stuff to the ACPI code to access 
embedded controllers and match ACPI devices by ID. Not sure how, where 
and whether at all these should be documented.

add-acpi-thinkpad.patch is the driver itself. Note that some stuff doesn't 
work yet on newer thinkpads, I plan to work on it later.

There is still some things to do though. I have to decide what to do with 
led(4) part and with locking. There is also one fatal issue - laptop 
locks up hardly (no panic) while unloading module. Any idea regarding 
this is welcome. And of course test results :).


-- 
Hasso
# HG changeset patch
# User Hasso Tepper <hasso at estpak.ee>
# Date 1205919290 -7200
# Branch HEAD
# Node ID 5a6e2705cc95a340abf973ae5df73ef34e070b79
# Parent  cd529e2e7f849034d5d5a0973cb98af50db0e797
imported patch adding-acpi-if-m.patch

diff --git a/sys/conf/files b/sys/conf/files
--- a/sys/conf/files
+++ b/sys/conf/files
@@ -1387,6 +1387,7 @@ emulation/dragonfly12/dfbsd12_stat.c	non
 ${OSACPI_MI_DIR}/acpi_cmbat.c		optional acpi
 ${OSACPI_MI_DIR}/acpi_cpu.c		optional acpi
 ${OSACPI_MI_DIR}/acpi_ec.c		optional acpi
+${OSACPI_MI_DIR}/acpi_if.m		optional acpi
 ${OSACPI_MI_DIR}/acpi_isab.c		optional acpi isa
 ${OSACPI_MI_DIR}/acpi_lid.c		optional acpi
 ${OSACPI_MI_DIR}/acpi_package.c		optional acpi
diff --git a/sys/conf/kmod.mk b/sys/conf/kmod.mk
--- a/sys/conf/kmod.mk
+++ b/sys/conf/kmod.mk
@@ -275,7 +275,7 @@ MFILES?= kern/bus_if.m kern/device_if.m 
     bus/pccard/card_if.m bus/pccard/power_if.m bus/pci/pci_if.m \
     bus/pci/pcib_if.m \
     bus/ppbus/ppbus_if.m bus/smbus/smbus_if.m bus/usb/usb_if.m \
-    dev/disk/nata/ata_if.m \
+    dev/acpica5/acpi_if.m dev/disk/nata/ata_if.m \
     dev/sound/pcm/ac97_if.m dev/sound/pcm/channel_if.m \
     dev/sound/pcm/feeder_if.m dev/sound/pcm/mixer_if.m \
     libiconv/iconv_converter_if.m dev/agp/agp_if.m opencrypto/crypto_if.m
diff --git a/sys/dev/acpica5/Makefile b/sys/dev/acpica5/Makefile
--- a/sys/dev/acpica5/Makefile
+++ b/sys/dev/acpica5/Makefile
@@ -69,12 +69,14 @@ SRCS+=  acpi_package.c
 # SRCS+=	acpi_pci.c acpi_pcib.c acpi_pcib_acpi.c acpi_pcib_pci.c
 # SRCS+=	acpi_pci_link.c
 SRCS+=  acpi_powerres.c acpi_resource.c acpi_thermal.c
-SRCS+=  acpi_timer.c
+SRCS+=  acpi_timer.c acpi_if.c
 SRCS+=  OsdDebug.c
 SRCS+=  OsdHardware.c OsdInterface.c OsdInterrupt.c OsdMemory.c OsdSchedule.c
 SRCS+=  OsdStream.c OsdSynch.c OsdTable.c OsdEnvironment.c
 SRCS+=  opt_acpi.h opt_bus.h opt_ddb.h
-SRCS+=  device_if.h bus_if.h pci_if.h pcib_if.h isa_if.h
+SRCS+=  device_if.h bus_if.h pci_if.h pcib_if.h isa_if.h acpi_if.h
+MFILES = kern/device_if.m kern/bus_if.m bus/pci/pci_if.m bus/pci/pcib_if.m
+MFILES+= bus/isa/isa_if.m dev/acpica5/acpi_if.m
 
 # Debugging support
 DBSRC=	dbcmds.c dbdisply.c dbexec.c dbfileio.c dbhistry.c
diff --git a/sys/dev/acpica5/acpi.c b/sys/dev/acpica5/acpi.c
--- a/sys/dev/acpica5/acpi.c
+++ b/sys/dev/acpica5/acpi.c
@@ -135,6 +135,7 @@ static int	acpi_release_resource(device_
 			int rid, struct resource *r);
 static uint32_t	acpi_isa_get_logicalid(device_t dev);
 static int	acpi_isa_get_compatid(device_t dev, uint32_t *cids, int count);
+static char	*acpi_device_id_probe(device_t bus, device_t dev, char **ids);
 static int	acpi_isa_pnp_probe(device_t bus, device_t child,
 			struct isa_pnp_id *ids);
 static void	acpi_probe_children(device_t bus);
@@ -189,6 +190,9 @@ static device_method_t acpi_methods[] = 
     DEVMETHOD(bus_deactivate_resource,	bus_generic_deactivate_resource),
     DEVMETHOD(bus_setup_intr,		bus_generic_setup_intr),
     DEVMETHOD(bus_teardown_intr,	bus_generic_teardown_intr),
+
+    /* ACPI bus */
+    DEVMETHOD(acpi_id_probe,		acpi_device_id_probe),
 
     /* ISA emulation */
     DEVMETHOD(isa_pnp_probe,		acpi_isa_pnp_probe),
@@ -1121,6 +1125,24 @@ out:
 	AcpiOsFree(buf.Pointer);
     ACPI_UNLOCK;
     return_VALUE (valid);
+}
+
+static char *
+acpi_device_id_probe(device_t bus, device_t dev, char **ids) 
+{
+    ACPI_HANDLE h;
+    int i;
+
+    h = acpi_get_handle(dev);
+    if (ids == NULL || h == NULL || acpi_get_type(dev) != ACPI_TYPE_DEVICE)
+	return (NULL);
+
+    /* Try to match one of the array of IDs with a HID or CID. */
+    for (i = 0; ids[i] != NULL; i++) {
+	if (acpi_MatchHid(h, ids[i]))
+	    return (ids[i]);
+    }
+    return (NULL);
 }
 
 static int
diff --git a/sys/dev/acpica5/acpi_ec.c b/sys/dev/acpica5/acpi_ec.c
--- a/sys/dev/acpica5/acpi_ec.c
+++ b/sys/dev/acpica5/acpi_ec.c
@@ -327,11 +327,19 @@ static ACPI_STATUS	EcWrite(struct acpi_e
 				UINT8 *Data);
 static int		acpi_ec_probe(device_t dev);
 static int		acpi_ec_attach(device_t dev);
+static int		acpi_ec_read_method(device_t dev, u_int addr,
+				ACPI_INTEGER *val, int width);
+static int		acpi_ec_write_method(device_t dev, u_int addr,
+				ACPI_INTEGER val, int width);
 
 static device_method_t acpi_ec_methods[] = {
     /* Device interface */
     DEVMETHOD(device_probe,	acpi_ec_probe),
     DEVMETHOD(device_attach,	acpi_ec_attach),
+
+    /* Embedded controller interface */
+    DEVMETHOD(acpi_ec_read,     acpi_ec_read_method),
+    DEVMETHOD(acpi_ec_write,    acpi_ec_write_method),
 
     {0, 0}
 };
@@ -620,6 +628,33 @@ error:
 			     sc->ec_data_res);
     /* mtx_destroy(&sc->ec_mtx); */
     return (ENXIO);
+}
+
+/* Methods to allow other devices (e.g., smbat) to read/write EC space. */
+static int
+acpi_ec_read_method(device_t dev, u_int addr, ACPI_INTEGER *val, int width)
+{
+    struct acpi_ec_softc *sc;
+    ACPI_STATUS status;
+
+    sc = device_get_softc(dev);
+    status = EcSpaceHandler(ACPI_READ, addr, width * 8, val, sc, NULL);
+    if (ACPI_FAILURE(status))
+        return (ENXIO);
+    return (0);
+}
+
+static int
+acpi_ec_write_method(device_t dev, u_int addr, ACPI_INTEGER val, int width)
+{
+    struct acpi_ec_softc *sc;
+    ACPI_STATUS status;
+
+    sc = device_get_softc(dev);
+    status = EcSpaceHandler(ACPI_WRITE, addr, width * 8, &val, sc, NULL);
+    if (ACPI_FAILURE(status))
+        return (ENXIO);
+    return (0);
 }
 
 static void
diff --git a/sys/dev/acpica5/acpi_if.m b/sys/dev/acpica5/acpi_if.m
new file mode 100644
--- /dev/null
+++ b/sys/dev/acpica5/acpi_if.m
@@ -0,0 +1,92 @@
+#-
+# Copyright (c) 2004 Nate Lawson
+# All rights reserved.
+#
+# Redistribution and use in source and binary forms, with or without
+# modification, are permitted provided that the following conditions
+# are met:
+# 1. Redistributions of source code must retain the above copyright
+#    notice, this list of conditions and the following disclaimer.
+# 2. Redistributions in binary form must reproduce the above copyright
+#    notice, this list of conditions and the following disclaimer in the
+#    documentation and/or other materials provided with the distribution.
+#
+# THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
+# ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+# ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
+# FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+# DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+# OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+# HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+# LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+# OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+# SUCH DAMAGE.
+#
+# $DragonFly$
+#
+
+#include <sys/bus.h>
+#include <sys/types.h>
+#include "acpi.h"
+
+INTERFACE acpi;
+
+#
+# Default implementation for acpi_id_probe().
+#
+CODE {
+	static char *
+	acpi_generic_id_probe(device_t bus, device_t dev, char **ids)
+	{
+		return (NULL);
+	}
+};
+
+#
+# Check a device for a match in a list of ID strings.  The strings can be
+# EISA PNP IDs or ACPI _HID/_CID values.
+#
+# device_t bus:  parent bus for the device
+#
+# device_t dev:  device being considered
+#
+# char **ids:  array of ID strings to consider
+#
+# Returns:  ID string matched or NULL if no match
+#
+METHOD char * id_probe {
+	device_t	bus;
+	device_t	dev;
+	char		**ids;
+} DEFAULT acpi_generic_id_probe;
+
+#
+# Read embedded controller (EC) address space
+#
+# device_t dev:  EC device
+# u_int addr:  Address to read from in EC space
+# ACPI_INTEGER *val:  Location to store read value
+# int width:  Size of area to read in bytes
+#
+METHOD int ec_read {
+	device_t	dev;
+	u_int		addr;
+	ACPI_INTEGER	*val;
+	int		width;
+};
+
+#
+# Write embedded controller (EC) address space
+#
+# device_t dev:  EC device
+# u_int addr:  Address to write to in EC space
+# ACPI_INTEGER val:  Value to write
+# int width:  Size of value to write in bytes
+#
+METHOD int ec_write {
+	device_t	dev;
+	u_int		addr;
+	ACPI_INTEGER	val;
+	int		width;
+};
diff --git a/sys/dev/acpica5/acpivar.h b/sys/dev/acpica5/acpivar.h
--- a/sys/dev/acpica5/acpivar.h
+++ b/sys/dev/acpica5/acpivar.h
@@ -29,6 +29,7 @@
  * $DragonFly: src/sys/dev/acpica5/acpivar.h,v 1.12 2007/10/23 03:04:48 y0netan1 Exp $
  */
 
+#include "acpi_if.h"
 #include "bus_if.h"
 #include <sys/eventhandler.h>
 #include <sys/sysctl.h>
# HG changeset patch
# User Hasso Tepper <hasso at estpak.ee>
# Date 1205995474 -7200
# Branch HEAD
# Node ID c5db8d4a7c6b25a8576a8d42c5029aaf0e23bfb6
# Parent  5a6e2705cc95a340abf973ae5df73ef34e070b79
[mq]: adding-acpi-thinkpad.patch

diff --git a/sys/dev/acpica5/Makefile b/sys/dev/acpica5/Makefile
--- a/sys/dev/acpica5/Makefile
+++ b/sys/dev/acpica5/Makefile
@@ -117,7 +117,7 @@ acpi_wakecode.h: acpi_wakecode.S
 	${MAKE} -f ${SYSDIR}/${OSACPI_MD_DIR}/Makefile \
 		MAKESRCPATH=${SYSDIR}/${OSACPI_MD_DIR}
 
-SUBDIR=	acpi_toshiba
+SUBDIR=	acpi_toshiba acpi_thinkpad
 all: ${PROG} ${SUBDIR}
 
 # *.o file for each patched *.c file is created under the same directory,
diff --git a/sys/dev/acpica5/acpi_thinkpad/Makefile b/sys/dev/acpica5/acpi_thinkpad/Makefile
new file mode 100644
--- /dev/null
+++ b/sys/dev/acpica5/acpi_thinkpad/Makefile
@@ -0,0 +1,9 @@
+# $DragonFly$
+
+SYSDIR?=${.CURDIR}/../../..
+
+KMOD=		acpi_thinkpad
+CFLAGS+=	-I${.OBJDIR}/.. -I${.CURDIR}/..
+SRCS=		acpi_thinkpad.c opt_acpi.h device_if.h bus_if.h
+
+.include <bsd.kmod.mk>
diff --git a/sys/dev/acpica5/acpi_thinkpad/acpi_thinkpad.c b/sys/dev/acpica5/acpi_thinkpad/acpi_thinkpad.c
new file mode 100644
--- /dev/null
+++ b/sys/dev/acpica5/acpi_thinkpad/acpi_thinkpad.c
@@ -0,0 +1,1046 @@
+/*
+ * Copyright (c) 2004 Takanori Watanabe
+ * Copyright (c) 2005 Markus Brueffer <markus at FreeBSD.org>
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *    notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *    notice, this list of conditions and the following disclaimer in the
+ *    documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+ */
+
+/*
+ * Driver for extra ACPI-controlled gadgets found on IBM and Lenovo ThinkPad
+ * laptops. Inspired by the ibm-acpi and tpb projects which implement these
+ * features on Linux.
+ *
+ *   acpi-ibm: <http://ibm-acpi.sourceforge.net/>
+ *        tpb: <http://www.nongnu.org/tpb/>
+ */
+
+#include "opt_acpi.h"
+#include <sys/param.h>
+#include <sys/kernel.h>
+#include <sys/bus.h>
+#include <machine/cpufunc.h>
+#include <sys/module.h>
+/* #include <dev/led/led.h> */
+#include <sys/sensors.h>
+#include <sys/sysctl.h>
+#include <machine/clock.h>
+
+#include "acpi.h"
+#include "acpivar.h"
+#include "acpi_if.h"
+
+#define _COMPONENT	ACPI_OEM
+ACPI_MODULE_NAME("THINKPAD")
+
+/* Internal methods */
+#define ACPI_THINKPAD_METHOD_EVENTS		1
+#define ACPI_THINKPAD_METHOD_EVENTMASK		2
+#define ACPI_THINKPAD_METHOD_HOTKEY		3
+#define ACPI_THINKPAD_METHOD_BRIGHTNESS		4
+#define ACPI_THINKPAD_METHOD_VOLUME		5
+#define ACPI_THINKPAD_METHOD_MUTE		6
+#define ACPI_THINKPAD_METHOD_THINKLIGHT		7
+#define ACPI_THINKPAD_METHOD_BLUETOOTH		8
+#define ACPI_THINKPAD_METHOD_WLAN		9
+#define ACPI_THINKPAD_METHOD_FANSPEED		10
+#define ACPI_THINKPAD_METHOD_FANLEVEL		11
+#define ACPI_THINKPAD_METHOD_FANSTATUS		12
+#define ACPI_THINKPAD_METHOD_THERMAL		13
+
+/* Hotkeys/Buttons */
+#define THINKPAD_RTC_HOTKEY1			0x64
+#define   THINKPAD_RTC_MASK_HOME		(1 << 0)
+#define   THINKPAD_RTC_MASK_SEARCH		(1 << 1)
+#define   THINKPAD_RTC_MASK_MAIL		(1 << 2)
+#define   THINKPAD_RTC_MASK_WLAN		(1 << 5)
+#define THINKPAD_RTC_HOTKEY2			0x65
+#define   THINKPAD_RTC_MASK_THINKPAD		(1 << 3)
+#define   THINKPAD_RTC_MASK_ZOOM		(1 << 5)
+#define   THINKPAD_RTC_MASK_VIDEO		(1 << 6)
+#define   THINKPAD_RTC_MASK_HIBERNATE		(1 << 7)
+#define THINKPAD_RTC_THINKLIGHT			0x66
+#define   THINKPAD_RTC_MASK_THINKLIGHT		(1 << 4)
+#define THINKPAD_RTC_SCREENEXPAND		0x67
+#define   THINKPAD_RTC_MASK_SCREENEXPAND	(1 << 5)
+#define THINKPAD_RTC_BRIGHTNESS			0x6c
+#define   THINKPAD_RTC_MASK_BRIGHTNESS		(1 << 5)
+#define THINKPAD_RTC_VOLUME			0x6e
+#define   THINKPAD_RTC_MASK_VOLUME		(1 << 7)
+
+/* Embedded Controller registers */
+#define THINKPAD_EC_BRIGHTNESS			0x31
+#define   THINKPAD_EC_MASK_BRI			0x7
+#define THINKPAD_EC_VOLUME			0x30
+#define   THINKPAD_EC_MASK_VOL			0xf
+#define   THINKPAD_EC_MASK_MUTE			(1 << 6)
+#define THINKPAD_EC_FANSTATUS			0x2F
+#define   THINKPAD_EC_MASK_FANLEVEL		0x3f
+#define   THINKPAD_EC_MASK_FANDISENGAGED	(1 << 6)
+#define   THINKPAD_EC_MASK_FANSTATUS		(1 << 7)
+#define THINKPAD_EC_FANSPEED			0x84
+
+/* CMOS Commands */
+#define THINKPAD_CMOS_VOLUME_DOWN		0
+#define THINKPAD_CMOS_VOLUME_UP			1
+#define THINKPAD_CMOS_VOLUME_MUTE		2
+#define THINKPAD_CMOS_BRIGHTNESS_UP		4
+#define THINKPAD_CMOS_BRIGHTNESS_DOWN		5
+
+/* ACPI methods */
+#define THINKPAD_NAME_KEYLIGHT			"KBLT"
+#define THINKPAD_NAME_WLAN_BT_GET		"GBDC"
+#define THINKPAD_NAME_WLAN_BT_SET		"SBDC"
+#define   THINKPAD_NAME_MASK_BT			(1 << 1)
+#define   THINKPAD_NAME_MASK_WLAN		(1 << 2)
+#define THINKPAD_NAME_THERMAL_GET		"TMP7"
+#define THINKPAD_NAME_THERMAL_UPDT		"UPDT"
+
+#define THINKPAD_NAME_EVENTS_STATUS_GET		"DHKC"
+#define THINKPAD_NAME_EVENTS_MASK_GET		"DHKN"
+#define THINKPAD_NAME_EVENTS_STATUS_SET		"MHKC"
+#define THINKPAD_NAME_EVENTS_MASK_SET		"MHKM"
+#define THINKPAD_NAME_EVENTS_GET		"MHKP"
+#define THINKPAD_NAME_EVENTS_AVAILMASK		"MHKA"
+
+#define ABS(x) (((x) < 0)? -(x) : (x))
+
+struct acpi_thinkpad_softc {
+	device_t	dev;
+	ACPI_HANDLE	handle;
+
+	/* Embedded controller */
+	device_t	ec_dev;
+	ACPI_HANDLE	ec_handle;
+
+	/* CMOS */
+	ACPI_HANDLE	cmos_handle;
+
+	/* Fan status */
+	ACPI_HANDLE	fan_handle;
+	int		fan_levels;
+
+	/* Keylight commands and states */
+	ACPI_HANDLE	light_handle;
+	int		light_cmd_on;
+	int		light_cmd_off;
+	int		light_val;
+	int		light_get_supported;
+	int		light_set_supported;
+
+	/* led(4) interface */
+	struct cdev	*led_dev;
+	int		led_busy;
+	int		led_state;
+
+	int		wlan_bt_flags;
+	int		thermal_updt_supported;
+
+	unsigned int	events_availmask;
+	unsigned int	events_initialmask;
+	int		events_mask_supported;
+	int		events_enable;
+
+	/* sensors(9) related */
+	struct ksensordev sensordev;
+	struct ksensor sensors[9];	/* XXX: 8 thermal + fan */
+
+	struct sysctl_ctx_list	*sysctl_ctx;
+	struct sysctl_oid	*sysctl_tree;
+};
+
+static struct {
+	char	*name;
+	int	method;
+	char	*description;
+	int	access;
+} acpi_thinkpad_sysctls[] = {
+	{
+		.name		= "events",
+		.method		= ACPI_THINKPAD_METHOD_EVENTS,
+		.description	= "ACPI events enable",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "eventmask",
+		.method		= ACPI_THINKPAD_METHOD_EVENTMASK,
+		.description	= "ACPI eventmask",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "hotkey",
+		.method		= ACPI_THINKPAD_METHOD_HOTKEY,
+		.description	= "Key Status",
+		.access		= CTLTYPE_INT | CTLFLAG_RD
+	},
+	{
+		.name		= "lcd_brightness",
+		.method		= ACPI_THINKPAD_METHOD_BRIGHTNESS,
+		.description	= "LCD Brightness",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "volume",
+		.method		= ACPI_THINKPAD_METHOD_VOLUME,
+		.description	= "Volume",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "mute",
+		.method		= ACPI_THINKPAD_METHOD_MUTE,
+		.description	= "Mute",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "thinklight",
+		.method		= ACPI_THINKPAD_METHOD_THINKLIGHT,
+		.description	= "Thinklight enable",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "bluetooth",
+		.method		= ACPI_THINKPAD_METHOD_BLUETOOTH,
+		.description	= "Bluetooth enable",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "wlan",
+		.method		= ACPI_THINKPAD_METHOD_WLAN,
+		.description	= "WLAN enable",
+		.access		= CTLTYPE_INT | CTLFLAG_RD
+	},
+	{
+		.name		= "fan_level",
+		.method		= ACPI_THINKPAD_METHOD_FANLEVEL,
+		.description	= "Fan level",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "fan",
+		.method		= ACPI_THINKPAD_METHOD_FANSTATUS,
+		.description	= "Fan enable",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+
+	{ NULL, 0, NULL, 0 }
+};
+
+/* ACPI_SERIAL_DECL(thinkpad, "ACPI THINKPAD extras"); */
+static int	acpi_thinkpad_probe(device_t dev);
+static int	acpi_thinkpad_attach(device_t dev);
+static int	acpi_thinkpad_detach(device_t dev);
+
+#if 0 /* not yet */
+static void	thinkpad_led(void *softc, int onoff);
+static void	thinkpad_led_task(struct acpi_thinkpad_softc *sc,
+		int pending __unused);
+#endif
+
+static int	acpi_thinkpad_sysctl(SYSCTL_HANDLER_ARGS);
+static int	acpi_thinkpad_sysctl_init(struct acpi_thinkpad_softc *sc,
+		int method);
+static int	acpi_thinkpad_sysctl_get(struct acpi_thinkpad_softc *sc,
+		int method);
+static int	acpi_thinkpad_sysctl_set(struct acpi_thinkpad_softc *sc,
+		int method, int val);
+
+static int	acpi_thinkpad_eventmask_set(struct acpi_thinkpad_softc *sc,
+		int val);
+static void	acpi_thinkpad_notify(ACPI_HANDLE h, UINT32 notify,
+		void *context);
+static void	acpi_thinkpad_refresh(void *);
+
+static device_method_t acpi_thinkpad_methods[] = {
+	/* Device interface */
+	DEVMETHOD(device_probe, acpi_thinkpad_probe),
+	DEVMETHOD(device_attach, acpi_thinkpad_attach),
+	DEVMETHOD(device_detach, acpi_thinkpad_detach),
+	{0, 0}
+};
+
+static driver_t	acpi_thinkpad_driver = {
+	"acpi_thinkpad",
+	acpi_thinkpad_methods,
+	sizeof(struct acpi_thinkpad_softc),
+};
+
+static devclass_t acpi_thinkpad_devclass;
+
+DRIVER_MODULE(acpi_thinkpad, acpi, acpi_thinkpad_driver,
+    acpi_thinkpad_devclass, 0, 0);
+MODULE_DEPEND(acpi_thinkpad, acpi, 1, 1, 1);
+static char    *thinkpad_ids[] = {"IBM0068", NULL};
+
+#if 0 /* not yet */
+static void
+thinkpad_led(void *softc, int onoff)
+{
+	struct acpi_thinkpad_softc* sc = (struct acpi_thinkpad_softc*) softc;
+
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+
+	if (sc->led_busy)
+		return;
+
+	sc->led_busy = 1;
+	sc->led_state = onoff;
+
+	AcpiOsExecute(OSL_NOTIFY_HANDLER, (void *)thinkpad_led_task, sc);
+}
+
+static void
+thinkpad_led_task(struct acpi_thinkpad_softc *sc, int pending __unused)
+{
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+
+	/* ACPI_SERIAL_BEGIN(thinkpad); */
+	acpi_thinkpad_sysctl_set(sc, ACPI_THINKPAD_METHOD_THINKLIGHT, sc->led_state);
+	/* ACPI_SERIAL_END(thinkpad); */
+
+	sc->led_busy = 0;
+}
+#endif
+
+static int
+acpi_thinkpad_probe(device_t dev)
+{
+	if (acpi_disabled("thinkpad") ||
+	    ACPI_ID_PROBE(device_get_parent(dev), dev, thinkpad_ids) == NULL ||
+	    device_get_unit(dev) != 0) 
+		return (ENXIO);
+
+	device_set_desc(dev, "IBM/Lenovo ThinkPad ACPI Extras");
+	return (0);
+}
+
+static int
+acpi_thinkpad_attach(device_t dev)
+{
+	struct acpi_thinkpad_softc	*sc;
+	struct acpi_softc	*acpi_sc;
+	devclass_t		ec_devclass;
+	int			i;
+
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t) __func__);
+
+	sc = device_get_softc(dev);
+	sc->dev = dev;
+	sc->handle = acpi_get_handle(dev);
+
+	acpi_sc = acpi_device_get_parent_softc(dev);
+
+	/* Look for the first embedded controller */
+        if (!(ec_devclass = devclass_find ("acpi_ec"))) {
+		if (bootverbose)
+			device_printf(dev, "Couldn't find acpi_ec devclass\n");
+		return (EINVAL);
+	}
+        if (!(sc->ec_dev = devclass_get_device(ec_devclass, 0))) {
+		if (bootverbose)
+			device_printf(dev, "Couldn't find acpi_ec device\n");
+		return (EINVAL);
+	}
+	sc->ec_handle = acpi_get_handle(sc->ec_dev);
+
+	/* ACPI_SERIAL_BEGIN(thinkpad); */
+
+#if 0
+	/* Get the sysctl tree */
+	sc->sysctl_ctx = device_get_sysctl_ctx(dev);
+	sc->sysctl_tree = device_get_sysctl_tree(dev);
+#endif
+	sysctl_ctx_init(sc->sysctl_ctx);
+	sc->sysctl_tree = SYSCTL_ADD_NODE(sc->sysctl_ctx,
+	    SYSCTL_CHILDREN(acpi_sc->acpi_sysctl_tree), OID_AUTO,
+	    "thinkpad", CTLFLAG_RD, 0, "");
+
+	/* Look for event mask and hook up the nodes */
+	sc->events_mask_supported = ACPI_SUCCESS(acpi_GetInteger(sc->handle,
+	    THINKPAD_NAME_EVENTS_MASK_GET, &sc->events_initialmask));
+
+	if (sc->events_mask_supported) {
+		SYSCTL_ADD_INT(sc->sysctl_ctx,
+		    SYSCTL_CHILDREN(sc->sysctl_tree), OID_AUTO,
+		    "initialmask", CTLFLAG_RD,
+		    &sc->events_initialmask, 0, "Initial eventmask");
+
+		/* The availmask is the bitmask of supported events */
+		if (ACPI_FAILURE(acpi_GetInteger(sc->handle,
+		    THINKPAD_NAME_EVENTS_AVAILMASK, &sc->events_availmask)))
+			sc->events_availmask = 0xffffffff;
+
+		SYSCTL_ADD_INT(sc->sysctl_ctx,
+		    SYSCTL_CHILDREN(sc->sysctl_tree), OID_AUTO,
+		    "availmask", CTLFLAG_RD,
+		    &sc->events_availmask, 0, "Mask of supported events");
+	}
+
+	/* Hook up proc nodes */
+	for (i = 0; acpi_thinkpad_sysctls[i].name != NULL; i++) {
+		if (!acpi_thinkpad_sysctl_init(sc,
+		    acpi_thinkpad_sysctls[i].method))
+			continue;
+
+		SYSCTL_ADD_PROC(sc->sysctl_ctx,
+		    SYSCTL_CHILDREN(sc->sysctl_tree), OID_AUTO,
+		    acpi_thinkpad_sysctls[i].name,
+		    acpi_thinkpad_sysctls[i].access,
+		    sc, i, acpi_thinkpad_sysctl, "I",
+		    acpi_thinkpad_sysctls[i].description);
+	}
+
+	/* ACPI_SERIAL_END(thinkpad); */
+
+	/* Handle notifies */
+	AcpiInstallNotifyHandler(sc->handle, ACPI_DEVICE_NOTIFY,
+	    acpi_thinkpad_notify, dev);
+
+#if 0
+	/* Hook up light to led(4) */
+	if (sc->light_set_supported)
+		sc->led_dev = led_create_state(thinkpad_led, sc, "thinklight",
+		    sc->light_val);
+#endif
+	/* Attach sensors(9). */
+	if (sensor_task_register(sc, acpi_thinkpad_refresh, 5)) {
+		device_printf(sc->dev, "unable to register update task\n");
+		return 1;
+	}
+
+	strlcpy(sc->sensordev.xname, device_get_nameunit(sc->dev),
+	    sizeof(sc->sensordev.xname));
+
+	/* XXX: Temp sensors */
+	for (i = 0; i < 8; ++i) {
+		sc->sensors[i].type = SENSOR_TEMP;
+		sensor_attach(&sc->sensordev, &sc->sensors[i]);
+	}
+	
+	/* Fan RPM sensor */
+	sc->sensors[8].type = SENSOR_FANRPM;
+	sensor_attach(&sc->sensordev, &sc->sensors[8]);
+
+	sensordev_install(&sc->sensordev);
+
+	return (0);
+}
+
+static int
+acpi_thinkpad_detach(device_t dev)
+{
+	int i;
+
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t) __func__);
+
+	struct acpi_thinkpad_softc *sc = device_get_softc(dev);
+
+	/* Disable events and restore eventmask */
+	/* ACPI_SERIAL_BEGIN(thinkpad); */
+	acpi_thinkpad_sysctl_set(sc, ACPI_THINKPAD_METHOD_EVENTS, 0);
+	acpi_thinkpad_sysctl_set(sc, ACPI_THINKPAD_METHOD_EVENTMASK,
+	    sc->events_initialmask);
+	/* ACPI_SERIAL_END(thinkpad); */
+
+	AcpiRemoveNotifyHandler(sc->handle, ACPI_DEVICE_NOTIFY,
+	    acpi_thinkpad_notify);
+
+	sysctl_ctx_free(sc->sysctl_ctx);
+
+#if 0
+	if (sc->led_dev != NULL)
+		led_destroy(sc->led_dev);
+#endif
+	sensordev_deinstall(&sc->sensordev);
+	for (i = 0; i < 9; i++)
+		sensor_detach(&sc->sensordev, &sc->sensors[i]);
+	sensor_task_unregister(sc);
+
+	return (0);
+}
+
+static int
+acpi_thinkpad_eventmask_set(struct acpi_thinkpad_softc *sc, int val)
+{
+	int i;
+	ACPI_OBJECT		arg[2];
+	ACPI_OBJECT_LIST	args;
+	ACPI_STATUS		status;
+
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+	/* ACPI_SERIAL_ASSERT(thinkpad); */
+
+	args.Count = 2;
+	args.Pointer = arg;
+	arg[0].Type = ACPI_TYPE_INTEGER;
+	arg[1].Type = ACPI_TYPE_INTEGER;
+
+	for (i = 0; i < 32; ++i) {
+		arg[0].Integer.Value = i+1;
+		arg[1].Integer.Value = (((1 << i) & val) != 0);
+		status = AcpiEvaluateObject(sc->handle,
+		    THINKPAD_NAME_EVENTS_MASK_SET, &args, NULL);
+
+		if (ACPI_FAILURE(status))
+			return (status);
+	}
+
+	return (0);
+}
+
+static int
+acpi_thinkpad_sysctl(SYSCTL_HANDLER_ARGS)
+{
+	struct acpi_thinkpad_softc	*sc;
+	int			arg;
+	int			error = 0;
+	int			function;
+	int			method;
+	
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+
+	sc = (struct acpi_thinkpad_softc *)oidp->oid_arg1;
+	function = oidp->oid_arg2;
+	method = acpi_thinkpad_sysctls[function].method;
+
+	/* ACPI_SERIAL_BEGIN(thinkpad); */
+	arg = acpi_thinkpad_sysctl_get(sc, method);
+	error = sysctl_handle_int(oidp, &arg, 0, req);
+
+	/* Sanity check */
+	if (error != 0 || req->newptr == NULL)
+		goto out;
+
+	/* Update */
+	error = acpi_thinkpad_sysctl_set(sc, method, arg);
+
+out:
+	/* ACPI_SERIAL_END(thinkpad); */
+	return (error);
+}
+
+static int
+acpi_thinkpad_sysctl_get(struct acpi_thinkpad_softc *sc, int method)
+{
+	ACPI_INTEGER	val_ec;
+	int 		val = 0, key;
+
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+	/* ACPI_SERIAL_ASSERT(thinkpad); */
+
+	switch (method) {
+	case ACPI_THINKPAD_METHOD_EVENTS:
+		acpi_GetInteger(sc->handle, THINKPAD_NAME_EVENTS_STATUS_GET,
+		    &val);
+		break;
+
+	case ACPI_THINKPAD_METHOD_EVENTMASK:
+		if (sc->events_mask_supported)
+			acpi_GetInteger(sc->handle,
+			    THINKPAD_NAME_EVENTS_MASK_GET, &val);
+		break;
+
+	case ACPI_THINKPAD_METHOD_HOTKEY:
+		/*
+		 * Construct the hotkey as a bitmask as illustrated below.
+		 * Note that whenever a key was pressed, the respecting bit
+		 * toggles and nothing else changes.
+		 * +--+--+-+-+-+-+-+-+-+-+-+-+
+		 * |11|10|9|8|7|6|5|4|3|2|1|0|
+		 * +--+--+-+-+-+-+-+-+-+-+-+-+
+		 *   |  | | | | | | | | | | |
+		 *   |  | | | | | | | | | | +- Home Button
+		 *   |  | | | | | | | | | +--- Search Button
+		 *   |  | | | | | | | | +----- Mail Button
+		 *   |  | | | | | | | +------- Thinkpad Button
+		 *   |  | | | | | | +--------- Zoom (Fn + Space)
+		 *   |  | | | | | +----------- WLAN Button
+		 *   |  | | | | +------------- Video Button
+		 *   |  | | | +--------------- Hibernate Button
+		 *   |  | | +----------------- Thinklight Button
+		 *   |  | +------------------- Screen expand (Fn + F8)
+		 *   |  +--------------------- Brightness
+		 *   +------------------------ Volume/Mute
+		 */
+		key = rtcin(THINKPAD_RTC_HOTKEY1);
+		val = (THINKPAD_RTC_MASK_HOME | THINKPAD_RTC_MASK_SEARCH |
+		    THINKPAD_RTC_MASK_MAIL | THINKPAD_RTC_MASK_WLAN) & key;
+		key = rtcin(THINKPAD_RTC_HOTKEY2);
+		val |= (THINKPAD_RTC_MASK_THINKPAD | THINKPAD_RTC_MASK_VIDEO |
+		    THINKPAD_RTC_MASK_HIBERNATE) & key;
+		val |= (THINKPAD_RTC_MASK_ZOOM & key) >> 1;
+		key = rtcin(THINKPAD_RTC_THINKLIGHT);
+		val |= (THINKPAD_RTC_MASK_THINKLIGHT & key) << 4;
+		key = rtcin(THINKPAD_RTC_SCREENEXPAND);
+		val |= (THINKPAD_RTC_MASK_THINKLIGHT & key) << 4;
+		key = rtcin(THINKPAD_RTC_BRIGHTNESS);
+		val |= (THINKPAD_RTC_MASK_BRIGHTNESS & key) << 5;
+		key = rtcin(THINKPAD_RTC_VOLUME);
+		val |= (THINKPAD_RTC_MASK_VOLUME & key) << 4;
+		break;
+
+	case ACPI_THINKPAD_METHOD_BRIGHTNESS:
+		ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_BRIGHTNESS, &val_ec, 1);
+		val = val_ec & THINKPAD_EC_MASK_BRI;
+		break;
+
+	case ACPI_THINKPAD_METHOD_VOLUME:
+		ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_VOLUME, &val_ec, 1);
+		val = val_ec & THINKPAD_EC_MASK_VOL;
+		break;
+
+	case ACPI_THINKPAD_METHOD_MUTE:
+		val = ((val_ec & THINKPAD_EC_MASK_MUTE) ==
+		    THINKPAD_EC_MASK_MUTE);
+		break;
+
+	case ACPI_THINKPAD_METHOD_THINKLIGHT:
+		if (sc->light_get_supported)
+			acpi_GetInteger(sc->ec_handle, THINKPAD_NAME_KEYLIGHT,
+			    &val);
+		else
+			val = sc->light_val;
+		break;
+
+	case ACPI_THINKPAD_METHOD_BLUETOOTH:
+		acpi_GetInteger(sc->handle, THINKPAD_NAME_WLAN_BT_GET, &val);
+		sc->wlan_bt_flags = val;
+		val = ((val & THINKPAD_NAME_MASK_BT) != 0);
+		break;
+
+	case ACPI_THINKPAD_METHOD_WLAN:
+		acpi_GetInteger(sc->handle, THINKPAD_NAME_WLAN_BT_GET, &val);
+		sc->wlan_bt_flags = val;
+		val = ((val & THINKPAD_NAME_MASK_WLAN) != 0);
+		break;
+
+	case ACPI_THINKPAD_METHOD_FANSPEED:
+		if (sc->fan_handle) {
+			if (ACPI_FAILURE(acpi_GetInteger(sc->fan_handle,
+			    NULL, &val)))
+				val = -1;
+		}
+		else {
+			ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_FANSPEED,
+			    &val_ec, 2);
+			val = val_ec;
+		}
+		break;
+
+	case ACPI_THINKPAD_METHOD_FANLEVEL:
+		/*
+		 * The THINKPAD_EC_FANSTATUS register works as follows:
+		 * Bit 0-5 indicate the level at which the fan operates. Only
+		 *       values between 0 and 7 have an effect. Everything
+		 *       above 7 is treated the same as level 7
+		 * Bit 6 overrides the fan speed limit if set to 1
+		 * Bit 7 indicates at which mode the fan operates:
+		 *       manual (0) or automatic (1)
+		 */
+		if (!sc->fan_handle) {
+			ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_FANSTATUS,
+			    &val_ec, 1);
+			val = val_ec & THINKPAD_EC_MASK_FANLEVEL;
+		}
+		break;
+
+	case ACPI_THINKPAD_METHOD_FANSTATUS:
+		if (!sc->fan_handle) {
+			ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_FANSTATUS,
+			    &val_ec, 1);
+			val = (val_ec & THINKPAD_EC_MASK_FANSTATUS) ==
+			    THINKPAD_EC_MASK_FANSTATUS;
+		}
+		else
+			val = -1;
+		break;
+	}
+
+	return (val);
+}
+
+static int
+acpi_thinkpad_sysctl_set(struct acpi_thinkpad_softc *sc, int method, int arg)
+{
+	int			val, step, i;
+	ACPI_INTEGER		val_ec;
+	ACPI_OBJECT		Arg;
+	ACPI_OBJECT_LIST	Args;
+	ACPI_STATUS		status;
+
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+	/* ACPI_SERIAL_ASSERT(thinkpad); */
+
+	switch (method) {
+	case ACPI_THINKPAD_METHOD_EVENTS:
+		if (arg < 0 || arg > 1)
+			return (EINVAL);
+
+		status = acpi_SetInteger(sc->handle,
+		    THINKPAD_NAME_EVENTS_STATUS_SET, arg);
+		if (ACPI_FAILURE(status))
+			return (status);
+		if (sc->events_mask_supported)
+			return acpi_thinkpad_eventmask_set(sc,
+			    sc->events_availmask);
+		break;
+
+	case ACPI_THINKPAD_METHOD_EVENTMASK:
+		if (sc->events_mask_supported)
+			return acpi_thinkpad_eventmask_set(sc, arg);
+		break;
+
+	case ACPI_THINKPAD_METHOD_BRIGHTNESS:
+		if (arg < 0 || arg > 7)
+			return (EINVAL);
+
+		if (sc->cmos_handle) {
+			/* Read the current brightness */
+			status = ACPI_EC_READ(sc->ec_dev,
+			    THINKPAD_EC_BRIGHTNESS, &val_ec, 1);
+			if (ACPI_FAILURE(status))
+				return (status);
+			val = val_ec & THINKPAD_EC_MASK_BRI;
+
+			Args.Count = 1;
+			Args.Pointer = &Arg;
+			Arg.Type = ACPI_TYPE_INTEGER;
+			Arg.Integer.Value = (arg > val) ?
+			    THINKPAD_CMOS_BRIGHTNESS_UP :
+			    THINKPAD_CMOS_BRIGHTNESS_DOWN;
+
+			step = (arg > val) ? 1 : -1;
+			for (i = val; i != arg; i += step) {
+				status = AcpiEvaluateObject(sc->cmos_handle,
+				    NULL, &Args, NULL);
+				if (ACPI_FAILURE(status))
+					break;
+			}
+		}
+		return ACPI_EC_WRITE(sc->ec_dev, THINKPAD_EC_BRIGHTNESS,
+		    arg, 1);
+		break;
+
+	case ACPI_THINKPAD_METHOD_VOLUME:
+		if (arg < 0 || arg > 14)
+			return (EINVAL);
+
+		status = ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_VOLUME,
+		    &val_ec, 1);
+		if (ACPI_FAILURE(status))
+			return (status);
+
+		if (sc->cmos_handle) {
+			val = val_ec & THINKPAD_EC_MASK_VOL;
+
+			Args.Count = 1;
+			Args.Pointer = &Arg;
+			Arg.Type = ACPI_TYPE_INTEGER;
+			Arg.Integer.Value = (arg > val) ?
+			    THINKPAD_CMOS_VOLUME_UP : THINKPAD_CMOS_VOLUME_DOWN;
+
+			step = (arg > val) ? 1 : -1;
+			for (i = val; i != arg; i += step) {
+				status = AcpiEvaluateObject(sc->cmos_handle,
+				    NULL, &Args, NULL);
+				if (ACPI_FAILURE(status))
+					break;
+			}
+		}
+		return ACPI_EC_WRITE(sc->ec_dev, THINKPAD_EC_VOLUME, arg +
+		    (val_ec & (~THINKPAD_EC_MASK_VOL)), 1);
+		break;
+
+	case ACPI_THINKPAD_METHOD_MUTE:
+		if (arg < 0 || arg > 1)
+			return (EINVAL);
+
+		status = ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_VOLUME,
+		    &val_ec, 1);
+		if (ACPI_FAILURE(status))
+			return (status);
+
+		if (sc->cmos_handle) {
+			val = val_ec & THINKPAD_EC_MASK_VOL;
+
+			Args.Count = 1;
+			Args.Pointer = &Arg;
+			Arg.Type = ACPI_TYPE_INTEGER;
+			Arg.Integer.Value = THINKPAD_CMOS_VOLUME_MUTE;
+
+			status = AcpiEvaluateObject(sc->cmos_handle, NULL,
+			    &Args, NULL);
+			if (ACPI_FAILURE(status))
+				break;
+		}
+		return ACPI_EC_WRITE(sc->ec_dev, THINKPAD_EC_VOLUME, (arg==1) ?
+		   val_ec | THINKPAD_EC_MASK_MUTE :
+		   val_ec & (~THINKPAD_EC_MASK_MUTE), 1);
+		break;
+
+	case ACPI_THINKPAD_METHOD_THINKLIGHT:
+		if (arg < 0 || arg > 1)
+			return (EINVAL);
+
+		if (sc->light_set_supported) {
+			Args.Count = 1;
+			Args.Pointer = &Arg;
+			Arg.Type = ACPI_TYPE_INTEGER;
+			Arg.Integer.Value = arg ?
+			    sc->light_cmd_on : sc->light_cmd_off;
+
+			status = AcpiEvaluateObject(sc->light_handle, NULL,
+			    &Args, NULL);
+			if (ACPI_SUCCESS(status))
+				sc->light_val = arg;
+			return (status);
+		}
+		break;
+
+	case ACPI_THINKPAD_METHOD_BLUETOOTH:
+		if (arg < 0 || arg > 1)
+			return (EINVAL);
+
+		val = (arg == 1) ? sc->wlan_bt_flags |
+		    THINKPAD_NAME_MASK_BT :
+		    sc->wlan_bt_flags & (~THINKPAD_NAME_MASK_BT);
+		return acpi_SetInteger(sc->handle, THINKPAD_NAME_WLAN_BT_SET,
+		    val);
+		break;
+
+	case ACPI_THINKPAD_METHOD_FANLEVEL:
+		if (arg < 0 || arg > 7)
+			return (EINVAL);
+
+		if (!sc->fan_handle) {
+			/* Read the current fanstatus */
+			ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_FANSTATUS,
+			    &val_ec, 1);
+			val = val_ec & (~THINKPAD_EC_MASK_FANLEVEL);
+
+			return ACPI_EC_WRITE(sc->ec_dev, THINKPAD_EC_FANSTATUS,
+			    val | arg, 1);
+		}
+		break;
+
+	case ACPI_THINKPAD_METHOD_FANSTATUS:
+		if (arg < 0 || arg > 1)
+			return (EINVAL);
+
+		if (!sc->fan_handle) {
+			/* Read the current fanstatus */
+			ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_FANSTATUS,
+			    &val_ec, 1);
+
+			return ACPI_EC_WRITE(sc->ec_dev, THINKPAD_EC_FANSTATUS,
+			    (arg == 1) ? (val_ec | THINKPAD_EC_MASK_FANSTATUS) :
+			    (val_ec & (~THINKPAD_EC_MASK_FANSTATUS)), 1);
+		}
+		break;
+	}
+
+	return (0);
+}
+
+static int
+acpi_thinkpad_sysctl_init(struct acpi_thinkpad_softc *sc, int method)
+{
+	int 			dummy;
+	ACPI_OBJECT_TYPE 	cmos_t;
+	ACPI_HANDLE		ledb_handle;
+
+	switch (method) {
+	case ACPI_THINKPAD_METHOD_EVENTS:
+		/* Events are disabled by default */
+		return (TRUE);
+
+	case ACPI_THINKPAD_METHOD_EVENTMASK:
+		return (sc->events_mask_supported);
+
+	case ACPI_THINKPAD_METHOD_HOTKEY:
+	case ACPI_THINKPAD_METHOD_BRIGHTNESS:
+	case ACPI_THINKPAD_METHOD_VOLUME:
+	case ACPI_THINKPAD_METHOD_MUTE:
+		/* EC is required here, which was already checked before */
+		return (TRUE);
+
+	case ACPI_THINKPAD_METHOD_THINKLIGHT:
+		sc->cmos_handle = NULL;
+		sc->light_get_supported = ACPI_SUCCESS(acpi_GetInteger(
+		    sc->ec_handle, THINKPAD_NAME_KEYLIGHT, &sc->light_val));
+
+		if ((ACPI_SUCCESS(AcpiGetHandle(sc->handle, "\\UCMS",
+		    &sc->light_handle)) ||
+		    ACPI_SUCCESS(AcpiGetHandle(sc->handle, "\\CMOS",
+		    &sc->light_handle)) ||
+		    ACPI_SUCCESS(AcpiGetHandle(sc->handle, "\\CMS",
+		    &sc->light_handle))) &&
+		    ACPI_SUCCESS(AcpiGetType(sc->light_handle, &cmos_t)) &&
+		    cmos_t == ACPI_TYPE_METHOD) {
+			sc->light_cmd_on = 0x0c;
+			sc->light_cmd_off = 0x0d;
+			sc->cmos_handle = sc->light_handle;
+		}
+		else if (ACPI_SUCCESS(AcpiGetHandle(sc->handle, "\\LGHT",
+		    &sc->light_handle))) {
+			sc->light_cmd_on = 1;
+			sc->light_cmd_off = 0;
+		}
+		else
+			sc->light_handle = NULL;
+
+		sc->light_set_supported = (sc->light_handle &&
+		    ACPI_FAILURE(AcpiGetHandle(sc->ec_handle, "LEDB",
+		    &ledb_handle)));
+
+		if (sc->light_get_supported)
+			return (TRUE);
+
+		if (sc->light_set_supported) {
+			sc->light_val = 0;
+			return (TRUE);
+		}
+
+		return (FALSE);
+
+	case ACPI_THINKPAD_METHOD_BLUETOOTH:
+	case ACPI_THINKPAD_METHOD_WLAN:
+		if (ACPI_SUCCESS(acpi_GetInteger(sc->handle,
+		    THINKPAD_NAME_WLAN_BT_GET, &dummy)))
+			return (TRUE);
+		return (FALSE);
+
+	case ACPI_THINKPAD_METHOD_FANSPEED:
+		/* 
+		 * Some models report the fan speed in levels from 0-7
+		 * Newer models report it contiguously
+		 */
+		sc->fan_levels = (ACPI_SUCCESS(AcpiGetHandle(sc->handle, "GFAN",
+		    &sc->fan_handle)) ||
+		    ACPI_SUCCESS(AcpiGetHandle(sc->handle, "\\FSPD",
+		    &sc->fan_handle)));
+		return (TRUE);
+
+	case ACPI_THINKPAD_METHOD_FANLEVEL:
+	case ACPI_THINKPAD_METHOD_FANSTATUS:
+		/* 
+		 * Fan status is only supported on those models,
+		 * which report fan RPM contiguously, not in levels
+		 */
+		if (sc->fan_levels)
+			return (FALSE);
+		return (TRUE);
+
+	case ACPI_THINKPAD_METHOD_THERMAL:
+		if (ACPI_SUCCESS(acpi_GetInteger(sc->ec_handle,
+		    THINKPAD_NAME_THERMAL_GET, &dummy))) {
+			sc->thermal_updt_supported =
+			    ACPI_SUCCESS(acpi_GetInteger(sc->ec_handle,
+			    THINKPAD_NAME_THERMAL_UPDT, &dummy));
+			return (TRUE);
+		}
+		return (FALSE);
+	}
+	return (FALSE);
+}
+
+static void
+acpi_thinkpad_notify(ACPI_HANDLE h, UINT32 notify, void *context)
+{
+	int		event, arg, type;
+	device_t	dev = context;
+	struct acpi_thinkpad_softc *sc = device_get_softc(dev);
+
+	ACPI_FUNCTION_TRACE_U32((char *)(uintptr_t)__func__, notify);
+
+	if (notify != 0x80)
+		device_printf(dev, "Unknown notify\n");
+
+	for (;;) {
+		acpi_GetInteger(acpi_get_handle(dev), THINKPAD_NAME_EVENTS_GET,
+		    &event);
+
+		if (event == 0)
+			break;
+
+		type = (event >> 12) & 0xf;
+		arg = event & 0xfff;
+		switch (type) {
+		case 1:
+			if (!(sc->events_availmask & (1 << (arg - 1)))) {
+				device_printf(dev, "Unknown key %d\n", arg);
+				break;
+			}
+
+			/* Notify devd(8) */
+			device_printf(dev, "THINKPAD event: %u\n",
+			    (arg & 0xff));
+			acpi_UserNotify("THINKPAD", h, (arg & 0xff));
+			break;
+		default:
+			break;
+		}
+	}
+}
+
+static void
+acpi_thinkpad_refresh(void *arg)
+{
+	struct acpi_thinkpad_softc *sc = (struct acpi_thinkpad_softc *)arg;
+	char temp_cmd[] = "TMP0";
+	int data, i;
+	ACPI_INTEGER speed;
+
+	for (i = 0; i < 8; i++) {
+		temp_cmd[3] = '0' + i;
+		
+                /*
+                 * The TMPx methods seem to return +/- 128 or 0
+                 * when the respecting sensor is not available
+                 */
+		sc->sensors[i].flags &= ~SENSOR_FINVALID;
+                if (ACPI_FAILURE(acpi_GetInteger(sc->ec_handle, temp_cmd,
+                    &data)) || ABS(data) == 128 || data == 0) {
+			sc->sensors[i].flags |= SENSOR_FINVALID;
+                        data = 0;
+		}
+                else if (sc->thermal_updt_supported) {
+                        /* XXX: Temperature is reported in tenth of Kelvin */
+                        data = (data - 2732 + 5) / 10;
+		}
+		sc->sensors[i].value = data * 1000000 + 273150000;
+        }
+	
+	sc->sensors[8].flags &= ~SENSOR_FINVALID;
+	if (sc->fan_handle) {
+		if (ACPI_FAILURE(acpi_GetInteger(sc->fan_handle,
+		    NULL, &data)))
+			sc->sensors[8].flags |= SENSOR_FINVALID;
+                        data = -1;
+        }
+        else {
+                ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_FANSPEED, &speed, 2);
+                data = speed;
+        }
+
+	sc->sensors[8].value = data;
+}
diff --git a/sys/platform/pc32/conf/files b/sys/platform/pc32/conf/files
--- a/sys/platform/pc32/conf/files
+++ b/sys/platform/pc32/conf/files
@@ -72,6 +72,7 @@ dev/serial/dgb/dgm.c			optional	dgm
 ${OSACPI_MD_DIR}/acpi_machdep.c		optional        acpi
 ${OSACPI_MD_DIR}/acpi_wakeup.c		optional        acpi
 ${OSACPI_MD_DIR}/acpi_toshiba.c		optional        acpi_toshiba acpi
+${ACPICA_DIR}/acpi_thinkpad/acpi_thinkpad.c optional	acpi_thinkpad acpi
 acpi.h					optional	acpi		\
 	dependency	"$S/${ACPICA_DIR}/include/acpi.h"		\
 	compile-with	"cp $S/${ACPICA_DIR}/include/acpi.h ${.OBJDIR}/"	\



From hasso at estpak.ee  Thu Mar 20 03:49:13 2008
From: hasso at estpak.ee (Hasso Tepper)
Date: Thu, 20 Mar 2008 03:49:13 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Some questions regarding ACPI
In-Reply-To: <200803191322.46366.hasso@estpak.ee>
Message-ID: <200803201237.28823.hasso@estpak.ee>

Hasso Tepper wrote:
> There is also one fatal issue -laptop locks up hardly (no panic) while 
> unloading module. Any idea regarding this is welcome.

Nevermind, solved.


-- 
Hasso




From dillon at apollo.backplane.com  Fri Mar 21 19:24:01 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Fri, 21 Mar 2008 19:24:01 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: panic: assertion: hammer_btree_cmp(cursor->left_bound,	&cursor->node->ondisk->elms[0].leaf.base) <= 0 in btree_split_leaf
In-Reply-To: <200802232204.m1NM4cxd046264@apollo.backplane.com>
Message-ID: <200803220212.m2M2CiAY014435@apollo.backplane.com>

:While trying to find a procedure to reliably reproduce the panic
:I reported last time, I caught a different panic (uploaded at
: ~y0netan1/crash/9/ on my leaf account).  I wrote the following shell
:script (make sure to edit variables DISKS and MOUNTPT before using this
:script or it may trash your system):

    Ok, I believe I have fixed the left_bound assertion.  I also believe
    I have fixed the node ref count assertion on umount.

    There is currently one unfixed assertion related to the I/O
    path... sometimes the bp is being improperly disassociated from the
    related HAMMER structure.

    The full-filesystem case is still not being handled so don't test that :-)

					    -Matt





From c.turner at 199technologies.org  Sun Mar 23 09:48:29 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Sun, 23 Mar 2008 09:48:29 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
Message-ID: <47E6870C.4080709@199technologies.org>

I'm finally getting around to doing 1.12 upgrades, and have setup a 
separate machine to do my bulk package builds / upgrades etc,
so as not to disrupt my 'dev server' while things are being
built / tested

However, this seems kind of wasteful - the only purpose of this machine
is to build packages against a specific release..
And since building packages for a particular release generally requires 
only the userland, appropriate headers and correct 'uname' output - so:

it seems like if spoofing uname is configured inside a jail,
the next (or previous..) release can be installed into a jail and
used for building / testing packages without the overhead of a VM or 
maintaining a separate physical host

I did a quick scan of the tree to see what this would take, and, high 
level, it seems like only the following changes would need to be made:

- update struct jail to add a 'osrelease' string
  (implies bumping 'jail api' to 2?)
- update jail(8) to actually pass this information along
- update sys_uname to test ucred for jailed processes, and
  use the struct jail osrelease if appropriate
- similarly update sysctl kern.osrelease to support jail spoofing
  (if possible - didn't get this far in the research yet)
  could be less of a problem for builds, as I think most things use
 uname(1) ... but good to keep the environment consistent I suppose..
I'm still a bit confused as to how 'osrelease' is defined - everything
I'm finding is showing up as extern char[] .. perhaps this is something 
in the build I'm not familiar with?

also,

is the so-called 'stupid hackery' in sys_uname needed still?

Before I start any coding, does this:

- sound like something useful
- sound like the right approach
Thinking this could have wider useful implications e.g. for pkgbox
& so on -  for example setting up automated bulks w/various combinations 
of pkgsrc and releases, etc.

Cheers,

- Chris





From corecode at fs.ei.tum.de  Sun Mar 23 10:06:38 2008
From: corecode at fs.ei.tum.de (Simon 'corecode' Schubert)
Date: Sun, 23 Mar 2008 10:06:38 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <47E68C74.3080808@fs.ei.tum.de>

Chris Turner wrote:
I did a quick scan of the tree to see what this would take, and, high 
level, it seems like only the following changes would need to be made:
brave investigation.  but you could also simply set UNAME_r :)

sweatshorts % uname -r
1.13.0-DEVELOPMENT
sweatshorts % UNAME_r=1.12-RELEASE uname -r
1.12-RELEASE
I think that's good enough :D

cheers
  simon
--
Serve - BSD     +++  RENT this banner advert  +++    ASCII Ribbon   /"\
Work - Mac      +++  space for low ????????? NOW!1  +++      Campaign     \ /
Party Enjoy Relax   |   http://dragonflybsd.org      Against  HTML   \
Dude 2c 2 the max   !   http://golden-apple.biz       Mail + News   / \




From c.turner at 199technologies.org  Sun Mar 23 10:50:13 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Sun, 23 Mar 2008 10:50:13 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <47E69656.8080605@199technologies.org>

Simon 'corecode' Schubert wrote:
brave investigation.  but you could also simply set UNAME_r :)
Doh! Thanks for the tip!

they should change the phrase from RTFM to 'Carefully RTFM' :)

well.. scratch that change then. 1 less patch to write.

- Chris





From c.turner at 199technologies.org  Sun Mar 23 11:15:52 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Sun, 23 Mar 2008 11:15:52 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <47E69C7C.8010109@199technologies.org>

Chris Turner wrote:
Simon 'corecode' Schubert wrote:
brave investigation.  but you could also simply set UNAME_r :)

for the record - if anyone's interested - adding a line e.g.:

ALL_ENV+= UNAME_r=1.12-RELEASE

to mk.conf looks like it -might- work ..

(unless wants to chime in & verify)





From joerg at britannica.bec.de  Sun Mar 23 11:46:53 2008
From: joerg at britannica.bec.de (Joerg Sonnenberger)
Date: Sun, 23 Mar 2008 11:46:53 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <20080323181428.GA2099@britannica.bec.de>

On Sun, Mar 23, 2008 at 01:41:42PM -0400, Chris Turner wrote:
> they should change the phrase from RTFM to 'Carefully RTFM' :)

RTFMAI -- Read The Fine Manual Again, Idiot.

Joerg




From dillon at apollo.backplane.com  Sun Mar 23 20:05:36 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Sun, 23 Mar 2008 20:05:36 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
Message-ID: <200803240257.m2O2voNH038355@apollo.backplane.com>

    Here's an update on the HAMMER work!

    Current status:

    * Passes all standard filesystem stress tests and buildworld will
      run with a HAMMER /usr/obj.  Large histories are able to accumulate
      without effecting performance.

    * Pruning and reblocking code is in and partially tested, but now needs
      more stringent testing.

    * Full historical access appears to be working but needs testing.
      Note that a sync is still needed to flush dirty cached data prior
      to acquiring a timestamp for the 'snapshot' to be set in stone.
      (dirty data cached in-memory has no historical tags and must be
      committed to physical disk before it can be accessed historically).


    Current bugs:

    * There is one known bug in the standard operations code paths
      that results in an assertion in HAMMER's I/O subsystem.

    * There are probably bugs in the reblocking and/or pruning code.  More
      likely in the reblocking code.


    There are two big-ticket and several little-ticket items left.  HAMMER
    will officially go Alpha when the big-ticket items are done, and beta
    when we get a few of the little-ticket items done.

    Big ticket items left:

    * UNDO (crash recovery) code.  Currently it writes out undo records but
      they are not yet sequenced, buffer writes are not yet ordered, and
      there is no mount-time recovery code yet.

      This is the last item needed before HAMMER can go operational.

    * Filesystem full handling.  Currently no space is reserved for dirty
      cached data so it is possible to create/write files and for HAMMER
      to not have sufficient space left on-disk to flush it.


    Little ticket items:

    * Automated reblocking (currently these functions are manually
      initialized via the hammer utility).

    * I/O clustering and preliminary BMAP op when writing out large files.

    * CRC checking (CRC fields are reserved but not entirely generated yet
      and not yet checked at all).

    * Disaster Recovery filesystem scan.

    * Boot support.

    I expect all of these items and more to be handled by the 2.0 release
    in July.

			    Additional HAMMER capabilities
				(no timeline yet)

    * Adding, removing, and resizing a HAMMER filesystem's backing store.

			Ultimate Goals and working towards them
				(no timeline yet)

    Our ultimate goal with HAMMER and DragonFly in general is to support
    fully cache coherent replication in a multi-machine environment.  This
    involves several steps and networking protocols.

    * Replication of synchronization streams based on the UNDO log.  If
      resynchronizing to a target which is too old a B-Tree scan will
      likely be required.

    * Cache coherency protocols for machine-machine coherency for both
      replicated and remote-HAMMER access.

    I have no time frame for these items yet.  It will depend on how quickly
    HAMMER moves to Alpha and Beta status.  I will say, however, now
    that HAMMER's on-disk format has solidified, that I have a very precise
    understanding of the protocols that will be needed to accomplish fully
    cache coherent remote access for both replicated and non-replicated
    (remote mount style) access.

    And, as you know, fully coherent filesystem access across machines is
    going to be the basis for DragonFly's clustering across said machines.

    In summary, things are progressing very well.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From justin at shiningsilence.com  Sun Mar 23 20:10:13 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Sun, 23 Mar 2008 20:10:13 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <53758.192.168.0.252.1206327873.squirrel@www.shiningsilence.com>

On Sun, March 23, 2008 12:36 pm, Chris Turner wrote:

> it seems like if spoofing uname is configured inside a jail,
> the next (or previous..) release can be installed into a jail and
> used for building / testing packages without the overhead of a VM or
> maintaining a separate physical host

If you don't need a jail to spoof uname, as others posted, you can
installworld into a chroot and build everything you want there using
Joerg's spiffy pbulk.  That's what I'm doing on pkgbox now; I can hand you
my somewhat terse notes if you want.  It would be relatively easy to set
up the configuration you're talking about.





From sepherosa at gmail.com  Sun Mar 23 20:18:20 2008
From: sepherosa at gmail.com (Sepherosa Ziehau)
Date: Sun, 23 Mar 2008 20:18:20 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <ea7b9c170803232012n2f27f893tf1d756d7c9770419@mail.gmail.com>

On Mon, Mar 24, 2008 at 2:14 AM, Joerg Sonnenberger
<joerg at britannica.bec.de> wrote:
> On Sun, Mar 23, 2008 at 01:41:42PM -0400, Chris Turner wrote:
>  > they should change the phrase from RTFM to 'Carefully RTFM' :)
>
>  RTFMAI -- Read The Fine Manual Again, Idiot.

http://leaf.dragonflybsd.org/~sephe/rtfm.jpg

:D

>
>  Joerg
>



-- 
Live Free or Die




From justin at shiningsilence.com  Sun Mar 23 20:38:30 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Sun, 23 Mar 2008 20:38:30 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: GSoC 2008 - mentors signup
Message-ID: <53885.192.168.0.252.1206329503.squirrel@www.shiningsilence.com>

If you are planning to be a mentor for a Summer of Code project, please
sign up here for the mentors mailing list:

http://groups.google.com/group/google-summer-of-code-mentors-list

If you've already signed up, your subscription should be set up tomorrow.





From justin at shiningsilence.com  Sun Mar 23 21:12:01 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Sun, 23 Mar 2008 21:12:01 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: GSoC 2008 - mentors signup
In-Reply-To: <53885.192.168.0.252.1206329503.squirrel@www.shiningsilence.com>
Message-ID: <54025.192.168.0.252.1206331572.squirrel@www.shiningsilence.com>

Also!

If you are a potential mentor and you have not done so yet:

http://code.google.com/soc/mentor_step1.html

Get yourself registered as a mentor for the Summer of Code project.  Once
you are in there, check off DragonFly in the "My Profile" section.

You will need a Google Account if you don't have one:

http://www.google.com/accounts

This will add you to the list of mentors in the Google Summer of Code web
application, so you can review/be attached to projects.

A guide is available if you want more information:

http://groups.google.com/group/google-summer-of-code-announce/web/guide-to-the-gsoc-web-app-for-mentors-and-organization-administrators






From c.turner at 199technologies.org  Mon Mar 24 04:29:28 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Mon, 24 Mar 2008 04:29:28 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <47E78ECE.4070307@199technologies.org>

Justin C. Sherrill wrote:
If you don't need a jail to spoof uname, as others posted, you can
installworld into a chroot and build everything you want there using
Joerg's spiffy pbulk.  That's what I'm doing on pkgbox now; I can hand you
my somewhat terse notes if you want.  It would be relatively easy to set
up the configuration you're talking about.
cheers - I guess I thought incorrectly that something 'special' was 
needed to get the uname to change .. have been using the legacy bulks in 
chroots / jails (for 'same os' builds) as I haven't quite migrated to 
pbulk yet ..

thanks for the help offer - I'll ask if I run into trouble.




From dillon at apollo.backplane.com  Mon Mar 24 08:28:49 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Mon, 24 Mar 2008 08:28:49 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <200803241500.m2OF0CG8043760@apollo.backplane.com>


:http://leaf.dragonflybsd.org/~sephe/rtfm.jpg
:
::D

    Ho!

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From elekktretterr at exemail.com.au  Mon Mar 24 09:10:15 2008
From: elekktretterr at exemail.com.au (Petr Janda)
Date: Mon, 24 Mar 2008 09:10:15 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
In-Reply-To: <200803240257.m2O2voNH038355@apollo.backplane.com>
Message-ID: <200803250138.49775.elekktretterr@exemail.com.au>


>
>     And, as you know, fully coherent filesystem access across machines is
>     going to be the basis for DragonFly's clustering across said machines.
>
>     In summary, things are progressing very well.
>


Hi Matt,
That's good to know things are going so well. Got a question. If memory serves 
me right, initially there was also going to be a thing called ANVIL, I can't 
remember what it was supposed to do and whether its still in your design. 
Could you elaborate a little?

Thanks,
Petr




From dillon at apollo.backplane.com  Mon Mar 24 14:12:11 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Mon, 24 Mar 2008 14:12:11 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
In-Reply-To: <200803240257.m2O2voNH038355@apollo.backplane.com>
Message-ID: <200803242100.m2OL0nWV046868@apollo.backplane.com>


:Hi Matt,
:That's good to know things are going so well. Got a question. If memory serves 
:me right, initially there was also going to be a thing called ANVIL, I can't 
:remember what it was supposed to do and whether its still in your design. 
:Could you elaborate a little?
:
:Thanks,
:Petr

    It's not really in the HAMMER design any more, primarily because HAMMER's
    volume model seems to work fine as-is.  Ultimately something like ANVIL
    (a block storage manager) would prove beneficial to the project but it
    would be treated as a separate project.  HAMMER's redundancy model is
    going to be baesd around replication and clustering.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From tgen at netphreax.net  Mon Mar 24 18:31:37 2008
From: tgen at netphreax.net (Thomas E. Spanjaard)
Date: Mon, 24 Mar 2008 18:31:37 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
In-Reply-To: <200803240257.m2O2voNH038355@apollo.backplane.com>
Message-ID: <47E85337.2070407@netphreax.net>

Matthew Dillon wrote:
    * Full historical access appears to be working but needs testing.
      Note that a sync is still needed to flush dirty cached data prior
      to acquiring a timestamp for the 'snapshot' to be set in stone.
      (dirty data cached in-memory has no historical tags and must be
      committed to physical disk before it can be accessed historically).
Wouldn't making timestamp queries (at least from userland) enforce a 
sync on the volume in question be useful here?
--
        Thomas E. Spanjaard
        tgen at netphreax.net
Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00005.pgp
Type: application/octet-stream
Size: 186 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080324/3077333f/attachment-0009.obj>

From dillon at apollo.backplane.com  Mon Mar 24 20:10:12 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Mon, 24 Mar 2008 20:10:12 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
In-Reply-To: <200803240257.m2O2voNH038355@apollo.backplane.com>
Message-ID: <200803250302.m2P32qLP050160@apollo.backplane.com>


:Wouldn't making timestamp queries (at least from userland) enforce a 
:sync on the volume in question be useful here?
:-- 
:         Thomas E. Spanjaard
:         tgen at netphreax.net

    Making the 'hammer now' command do a sync() is a good idea.  I will
    make that change right now so it doesn't get lost.

    Here's a general overview of the issues involved with having historical
    access to the filesystem:

				----------------

    Recording the timestamps in the in-memory cache, for a finer-grained
    snapshot capability, is doable but has its own issues.  Here's an
    illustration:

    open()  create file
    write() append 4K	(file size now 4K)
    write() append 4K	(file size now 8K)
    write() append 4K	(file size now 12K)
    write() append 4K	(file size now 16K)

    Now NONE of this has gone to disk yet, it's entirely in the in-memory
    cache.  The inode is in the in-memory cache.  The data is stored in
    the buffer cache.  Even the directory entry for the file that we
    just created is still in the in-memory cache (HAMMER caches the raw
    records it intends to commit later on).

    If I wanted to be able to acquire a timestamp between each write and
    'see' a snapshot of the file as of any point in the above sequence,
    then every write would also have to allocate a copy of the inode
    (because it changes size on each write).

    The data has the same problem though with a slightly different example.
    Lets say each write() was a seek-write, overwriting the previous data.
    Now with every write() I would have to allocate a copy of the data
    being overwritten.  This is complicated by the fact that the buffer
    cache has no clue about 'historical' accesses, so I would not be able
    to use the buffer cache to cache the data.

    There's also another problem and that is with the efficiency of the
    topology on-disk.  Even if I maintained all the copies of the inode
    and all the copies of the data in-memory, I would still have to sync
    all those copies to disk in order for things to remain historically
    coherent (whether it be in-cache or on-disk).  This would result in
    hundreds or even thousands of copies of the inode on-disk, not to
    mention potentially many copies of the data.

    I just don't want to do that right now, at least not as a default.  A
    lot of performance would be lost.  Hence a sync() is needed if
    you want to create a demark which you can accurately snapshot.

				-------------

    Here's a quick synopsis of how the cache would operate in a clustered
    filesystem:

    In order to properly integrate with in-memory caches, a wider cache
    coherency infrastructure is needed between machines such that
    modifications made on one machine proactively invalidate those
    protions of the cache(s) on other machines.  At the same time, any
    'dirty' cache data, for example when a file is created or written to,
    must lock the cache space in question on all other machines.
    The cache space in this case is not just the file data, but also the
    related namespaces (for creations, deletions, and renames).  Attempts
    to access locked spaces from other machines in the cluster would have
    to force a flush to the filesystem backing store and lower the cache
    states for the effected information on the original machine from dirty
    to shared-read-only.

    It will be easiest to integrate the cache coherency information into
    the buffer cache and namecache themselves.  Once a machine has dirtied
    an in-memory cache element... for example part of the namespace when
    creating a file or chunks of data written within a file, that machine
    must have a free hand to make further modifications to the cache spaces
    involved without further interaction with other machines.

				-------------

    Now, if you think of those two major elements you can see that they
    actually fit together quite well.  If I were to attempt to maintain
    transactional coherency on a per-system-call basis then the cache
    granularity between machines would have to be much, much smaller then
    our current in-memory caching elements provide.  That would become
    a really nasty coding problem.  So I don't even want to begin to
    complate transactional coherency at a finer-grain then sync() or
    fsync() until long after we actually have clustering working.

						-Matt





From elekktretterr at exemail.com.au  Mon Mar 24 21:56:58 2008
From: elekktretterr at exemail.com.au (Petr Janda)
Date: Mon, 24 Mar 2008 21:56:58 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
In-Reply-To: <200803240257.m2O2voNH038355@apollo.backplane.com>
Message-ID: <200803251516.16407.elekktretterr@exemail.com.au>

So is it needed to run hammer now in order to "create" a snapshot? What would 
I do in situation like this: got a hammer filesystem and couple of the files 
change on day to day basis. Then a week later I needed to access one of the 
files, in exactly the state they were 7 days ago.

Cheers,
Petr




From dillon at apollo.backplane.com  Mon Mar 24 22:34:15 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Mon, 24 Mar 2008 22:34:15 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
In-Reply-To: <200803240257.m2O2voNH038355@apollo.backplane.com>
Message-ID: <200803250526.m2P5QZ5X051081@apollo.backplane.com>


:So is it needed to run hammer now in order to "create" a snapshot? What would 
:I do in situation like this: got a hammer filesystem and couple of the files 
:change on day to day basis. Then a week later I needed to access one of the 
:files, in exactly the state they were 7 days ago.
:
:Cheers,
:Petr

    No, you do not have to run 'hammer now' to create a snapshot.  The
    kernel syncs all filesystems every 30 seconds, so if you do nothing
    at all you get a snapshot granularity of 30 seconds.

    Where you would use 'hammer now' is if you wanted the most current
    snapshot possible for the purpose of, say, backing up your filesystem
    to another machine.  You might do something like this:

	set timestamp = `hammer now`
	cpdup /mountpoint/@@$timestamp targethost:/somepath

    But if you didn't care about that you could just go back far enough
    that you get a stable historical view... e.g. go back 1 minute and you
    would have a stable view into your filesystem.

	set timestamp = `hammer stamp 60s`		<------ doesn't sync
	cpdup /mountpoint/@@$timestamp targethost:/somepath


    Ultimately the idea of managing filesystems this way is to still do
    regular backups from your production machine to your backup machine
    (ultimately by way of replication), with both running HAMMER, but only
    retain a limited amount of history on the production box.  You might
    desire to retain only one week's worth of history on the production box,
    retain one month's history on your local backup box, and retain a very
    granular one year's worth of history on your remote backup box.

    Come to think of it, I should add some more directives to the
    'hammer prune' command to make that easier to specify.

    Until I implement a live replication 'feed' the minimum granularity on
    the backup box will be how often you do your backups (e.g. once a day),
    and you can prune it into more granular forms from that starting point.
    Once we have a live replication feed the backup box will have the same
    30-second granularity that the production machine has.

    A major bullet point for this style of management is that the retention
    policy on the various boxes can be different even though they are
    all slaved off the same production filesystem.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From justin at shiningsilence.com  Tue Mar 25 05:58:49 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Tue, 25 Mar 2008 05:58:49 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: SoC - student signups
Message-ID: <58180.65.106.147.226.1206449676.squirrel@www.shiningsilence.com>

Here's a quick link roundup:

Are you a student?  Put in your application for a Google Summer of Code here:

http://code.google.com/soc/2008/student_signup.html

Student guide:
http://groups.google.com/group/google-summer-of-code-announce/web/guide-to-the-gsoc-web-app-for-student-applicants

Are you a mentor?  (That means hasso, hsu, sephe, matthias, TGEN, and
corecode right now)

Student proposals will show up on the mentor page, linked below.  You will
get to rate them, and take the one(s) that you want to mentor.

Mentor page:
http://code.google.com/soc/2008/mentor_home.html
Mentor guide:
http://groups.google.com/group/google-summer-of-code-announce/web/guide-to-the-gsoc-web-app-for-mentors-and-organization-administrators

If you are a mentor and are communicating with potential students, send
them the URLs above for student signup and the student guide; work with
them if they ask for advice on what to say in the application.  They can
resubmit up to 20 times if they want to correct it.

Deadline is March 31st.






From noah.yan at gmail.com  Thu Mar 27 20:17:48 2008
From: noah.yan at gmail.com (Yonghong Yan)
Date: Thu, 27 Mar 2008 20:17:48 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: About DFBSD.64
In-Reply-To: <47EB0B5B.5020802@gmail.com>
Message-ID: <59521b110803272015y1cc8cc39uc93f154ed36e0505@mail.gmail.com>

thanks for your interest.

I owe to everybody for any update or work in the past four months. so
many things happen in my work and my family (they are all good:) and
keep me extremely busy. But i am not leaving and will be back on this
soon.

the latest sources are in http://repo.or.cz/w/dragonfly/port-amd64.git
, I did have a compiled kernel long time before, but I have to break
it to work on the pmap. you can pick up from there. TGEN will help you
a lot, also keep me posted too, if you like.

Noah

On Wed, Mar 26, 2008 at 9:50 PM, Sdavtaker <sdavtaker at gmail.com> wrote:
> Hello,
>  Im applying to GSoC to work in the x64 version of DFBSD with TGEN, i
>  found some work already done in the repository and some mails in the
>  archive from you.
>  I was wondering if you already had a working compiled kernel in AMD64
>  machine and what was not working yet to continue that work.
>  Thanks for any info.
>  Sdav
>




From dillon at apollo.backplane.com  Sat Mar 29 13:27:43 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Sat, 29 Mar 2008 13:27:43 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 29-Mar-2008
Message-ID: <200803292022.m2TKMLGe004942@apollo.backplane.com>

    Good progress continues to be made.  HAMMER survived acting as my
    LAN backup machine (in full historical mode) for almost a week before
    it hit an assertion.  I've fixed that issue and believe that the core
    filesystem implementation code is now 'very stable'.

    Note that the recent commit will result in many more 'hammer_lock_ex:'
    messages on the console then you may have previously observed.  This is
    due to the way object id's are allocated in the face of parallel 
    modifications to the filesystem, resulting in too much locality of
    reference in the B-Tree.  I do intend to improve it.

    I am still working on the two major items needed before HAMMER can be
    declared operational, those being the filesystem full handling and the
    undo/recovery-on-mount code.  These are the last 'hard' bits left in
    the design.

    With exception to filling up the filesystem, which *will* create a mess,
    and noting that no crash recovery code exists yet (so you have to newfs
    it if you crash), I'd appreciate it if interested parties could test
    the other functions of the filesystem, in particular the pruning and
    reblocking functions (man hammer), and the historical access functions.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From dillon at apollo.backplane.com  Sun Mar 30 15:11:03 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Sun, 30 Mar 2008 15:11:03 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Need ideas on how to solve an st_ino/st_dev test issue for HAMMER.
Message-ID: <200803302207.m2UM7BCp016402@apollo.backplane.com>

    Here's the problem, given historical access softlinks as shown below:

test30# ls -lda cra*
drwxr-xr-x  1 root  wheel  Mar 29 13:04 crater
lrwxr-xr-x  1 root  wheel  Mar 29 18:57 crater.20080329 -> crater@@0x47eef383
lrwxr-xr-x  1 root  wheel  Mar 30 01:24 crater.20080330 -> crater@@0x47ef4e29
-rw-r--r--  2 root  wheel  Mar 30 01:24 crater.log

    The problem is that if I do this:

    diff -r crater.20080329/var/log crater.20080330/var/log

    Diff just returns without actually diffing anything.  The reason is
    because diff checks st_ino and st_dev and believes the directories/files
    to be identical because they match.

    I considered munging the inode number for historical accesses, but
    that would seriously break NFS exports which try to access historical
    files and directories.  Right now NFS *is* able to distinguish between
    the two because NFS handles are 128-bit-wide entities, so I can encode
    the as-of transaction id as part of the filehandle.  But userland
    programs only have access to a 64-bit-wide inode so userland still
    believes the files to be identical.

    st_dev is only 32 bits, carefully munging it is an option if we
    could figure out a way to do it, but I'd rather not.

    I am considering using st_gen but then we'd have to patch third
    party software to test st_gen along with everything else.  This may
    be the only workable solution, though, and only a few programs would
    need to be patched.  st_gen is only 32 bits but it would solve the
    problem as we would be able to use all 32 bits.

    If anyone has any bright ideas, including 'leave it alone', I'm all
    ears.

						-Matt





From justin at shiningsilence.com  Mon Mar 31 10:40:42 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Mon, 31 Mar 2008 10:40:42 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: SoC student applications due by 5PM PDT tomorrow
In-Reply-To: <1942.192.168.0.242.1206930479.squirrel@www.shiningsilence.com>
Message-ID: <11892.67.108.184.175.1206984967.squirrel@www.shiningsilence.com>

On Sun, March 30, 2008 10:27 pm, Justin C. Sherrill wrote:
> SoC students:
>
> If you have an application to submit for DragonFly/Summer of Code, please
> do so by 17:00 Pacific time on the 31st - that's tomorrow, at least for
> me.

The deadline for student proposals has been extended to April 7th; all
other dates move forward one week to acommodate.

This is a good time to update existing applications or submit new ones. 
Talk to your (potential) mentors if you are curious.






From nthery at gmail.com  Mon Mar 31 11:29:49 2008
From: nthery at gmail.com (Nicolas Thery)
Date: Mon, 31 Mar 2008 11:29:49 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
Message-ID: <64fc43b0803311126na7d0b27obaa9d35bac6d32ee@mail.gmail.com>

Hello,

Now that the release is over, I'll try to get rid of zones and migrate
allocations to objcache.

Here is a 1st patch that migrate struct proc.  I'll commit it in a
couple of days if nobody objects.

I'm also implementing a way to monitor objcache statistics.  So far,
I've hacked sth similar to
sysctl vm.zone: stats are returned in one giant string, one line per
cache.  That's simple but ugly and hard to read because there are
quite a few stats per cache.

So I'm thinking about implementing a small tool, ocstat, that extracts
stats from sysctl the way ps(1) does (thru libkvm iirc) and formats it
in various ways.  What do you think?

Cheers,
Nicolas

Index: src2/sys/kern/kern_exit.c
===================================================================
--- src2.orig/sys/kern/kern_exit.c	2008-03-31 08:05:59.139796000 +0200
+++ src2/sys/kern/kern_exit.c	2008-03-31 10:31:39.000000000 +0200
@@ -834,7 +834,7 @@ loop:
 			}

 			vm_waitproc(p);
-			zfree(proc_zone, p);
+			objcache_put(proc_cache, p);
 			nprocs--;
 			return (0);
 		}
Index: src2/sys/kern/kern_proc.c
===================================================================
--- src2.orig/sys/kern/kern_proc.c	2008-03-31 08:05:59.139918000 +0200
+++ src2/sys/kern/kern_proc.c	2008-03-31 10:31:39.000000000 +0200
@@ -84,7 +84,7 @@ u_long pgrphash;
 struct proclist allproc;
 struct proclist zombproc;
 struct spinlock allproc_spin;
-vm_zone_t proc_zone;
+struct objcache* proc_cache;
 vm_zone_t lwp_zone;
 vm_zone_t thread_zone;

@@ -131,7 +131,7 @@ procinit(void)
 	spin_init(&allproc_spin);
 	pidhashtbl = hashinit(maxproc / 4, M_PROC, &pidhash);
 	pgrphashtbl = hashinit(maxproc / 4, M_PROC, &pgrphash);
-	proc_zone = zinit("PROC", sizeof (struct proc), 0, 0, 5);
+	proc_cache = objcache_create_simple(M_PROC, sizeof(struct proc));
 	lwp_zone = zinit("LWP", sizeof (struct lwp), 0, 0, 5);
 	thread_zone = zinit("THREAD", sizeof (struct thread), 0, 0, 5);
 	uihashinit();
Index: src2/sys/sys/proc.h
===================================================================
--- src2.orig/sys/sys/proc.h	2008-03-31 08:05:59.140325000 +0200
+++ src2/sys/sys/proc.h	2008-03-31 10:31:39.000000000 +0200
@@ -473,7 +473,7 @@ struct proc *zpfind (pid_t);	/* Find zom
 struct vm_zone;
 struct globaldata;
 struct lwp_params;
-extern struct vm_zone *proc_zone;
+extern struct objcache *proc_cache;
 extern struct vm_zone *lwp_zone;

 int	enterpgrp (struct proc *p, pid_t pgid, int mksess);
Index: src2/sys/kern/kern_fork.c
===================================================================
--- src2.orig/sys/kern/kern_fork.c	2008-03-31 08:05:59.140042000 +0200
+++ src2/sys/kern/kern_fork.c	2008-03-31 10:31:39.000000000 +0200
@@ -332,7 +332,7 @@ fork1(struct lwp *lp1, int flags, struct
 	}

 	/* Allocate new proc. */
-	p2 = zalloc(proc_zone);
+	p2 = objcache_get(proc_cache, M_WAITOK);
 	bzero(p2, sizeof(*p2));

 	/*




From hsu at dragonflybsd.org  Mon Mar 31 11:44:34 2008
From: hsu at dragonflybsd.org (Jeffrey Hsu)
Date: Mon, 31 Mar 2008 11:44:34 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <64fc43b0803311126na7d0b27obaa9d35bac6d32ee@mail.gmail.com>
Message-ID: <200803311841.m2VIfQAI007579@nlpi001.prodigy.net>

The object cache is not a general-purpose memory allocator.  It's a cache of
pre-initialized objects.  Are the significant portions of the proc structure
that can be restored to initialized state on object puts?  If not, it's best
to just use a general-purpose memory allocator.

								Jeffrey




From corecode at fs.ei.tum.de  Mon Mar 31 12:07:02 2008
From: corecode at fs.ei.tum.de (Simon 'corecode' Schubert)
Date: Mon, 31 Mar 2008 12:07:02 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <200803311841.m2VIfQAI007579@nlpi001.prodigy.net>
Message-ID: <47F1357B.1070302@fs.ei.tum.de>

Jeffrey Hsu wrote:
> The object cache is not a general-purpose memory allocator.  It's a cache of
> pre-initialized objects.  Are the significant portions of the proc structure
> that can be restored to initialized state on object puts?  If not, it's best
> to just use a general-purpose memory allocator.

Why?  What's the loss if we use the object cache to allocate struct procs?

cheers
  simon

Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00006.pgp
Type: application/octet-stream
Size: 252 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080331/a4a24314/attachment-0009.obj>

From nthery at gmail.com  Mon Mar 31 12:17:03 2008
From: nthery at gmail.com (Nicolas Thery)
Date: Mon, 31 Mar 2008 12:17:03 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <nthery@gmail.com>
Message-ID: <64fc43b0803311214u7da6bbb8xaf971de1a80e7258@mail.gmail.com>

2008/3/31, Jeffrey Hsu <hsu at dragonflybsd.org>:
> The object cache is not a general-purpose memory allocator.  It's a cache of
>  pre-initialized objects.  Are the significant portions of the proc structure
>  that can be restored to initialized state on object puts?  If not, it's best
>  to just use a general-purpose memory allocator.

Well, I haven't checked this yet.  I planned to do this in a second
step after getting rid of zones.

I thought that even without  the pre-initialization part, objcache has
the advantage
of pre-allocating set of objects (as zones) and is additionally
mp-safe (contrary to zones and, granted, as malloc()).   The latter
may be interesting as we talk of improving MP support.

Cheers,
Nicolas




From dillon at apollo.backplane.com  Mon Mar 31 12:23:40 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Mon, 31 Mar 2008 12:23:40 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <200803311841.m2VIfQAI007579@nlpi001.prodigy.net>
Message-ID: <200803311921.m2VJLITB027669@apollo.backplane.com>

    I both agree and disagree with Jeff.  I think the only *disadvantage*
    to using objcache for struct proc is that objcache must cache a minimum
    number of free structures to be efficient so the overall kernel memory
    use would be a bit greater verses uses kmalloc().  But I agree with Jeff
    in that objcache's biggest advantage is that you can keep structural state
    intact and struct proc might not be a good candidate (yet).

    What I suggest is that you convert struct proc from zone to kmalloc
    first, and then look into a possible objcache adaptation.  kmalloc
    is not slow.. it's a very fast allocator.  Objcache is probably a tad
    faster but not by much.  Where objcache really wins is in not having
    to completey reinitialize the allocated structures.

    Over the years I've removed (I think) all the dependancies on requiring
    the proc structure to be in stable memory so I believe it can be moved to
    kmalloc/objcache now without any major pain.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From corecode at fs.ei.tum.de  Mon Mar 31 12:37:40 2008
From: corecode at fs.ei.tum.de (Simon 'corecode' Schubert)
Date: Mon, 31 Mar 2008 12:37:40 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: SoC student applications due by 5PM PDT tomorrow
In-Reply-To: <1942.192.168.0.242.1206930479.squirrel@www.shiningsilence.com>
Message-ID: <47F13CDA.6010703@fs.ei.tum.de>

Justin C. Sherrill wrote:
> On Sun, March 30, 2008 10:27 pm, Justin C. Sherrill wrote:
>> SoC students:
>>
>> If you have an application to submit for DragonFly/Summer of Code, please
>> do so by 17:00 Pacific time on the 31st - that's tomorrow, at least for
>> me.
> The deadline for student proposals has been extended to April 7th; all
> other dates move forward one week to acommodate.

This is very good.

Some more ideas for eager students (we want to keep the ratio, right?):

Enhance the FreeBSD/DragonFly sound infrastructure to support surround
sound/multichannel output.

Update sound drivers to support S/PDIF output.

Make the sound infrastructure OSSv4 compatible (there was a SoC at
FreeBSD last year or so)


of course only if it doesn't exist already :)

cheers
  simon


Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00007.pgp
Type: application/octet-stream
Size: 252 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080331/6da61cff/attachment-0009.obj>

From corecode at fs.ei.tum.de  Mon Mar 31 12:41:30 2008
From: corecode at fs.ei.tum.de (Simon 'corecode' Schubert)
Date: Mon, 31 Mar 2008 12:41:30 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <200803311841.m2VIfQAI007579@nlpi001.prodigy.net>
Message-ID: <47F13DE4.10205@fs.ei.tum.de>

Matthew Dillon wrote:
>     What I suggest is that you convert struct proc from zone to kmalloc
>     first, and then look into a possible objcache adaptation.  kmalloc
>     is not slow.. it's a very fast allocator.  Objcache is probably a tad
>     faster but not by much.  Where objcache really wins is in not having
>     to completey reinitialize the allocated structures.

Could we please not move to kmalloc, but instead try to move all fast
path allocations to objcache?  I don't like the idea of allocating
everything with kmalloc.  Caching struct procs is not a bad thing itself.

cheers
  simon


Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00008.pgp
Type: application/octet-stream
Size: 252 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080331/ac328c08/attachment-0009.obj>

From hsu at FreeBSD.org  Mon Mar 31 12:59:05 2008
From: hsu at FreeBSD.org (Jeffrey Hsu)
Date: Mon, 31 Mar 2008 12:59:05 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <47F1357B.1070302@fs.ei.tum.de>
Message-ID: <200803311920.m2VJK5Ln018015@nlpi015.prodigy.net>

The object cache sits on top of a general-purpose memory allocator such
as kmalloc or zalloc and provides pre-initialized object caching functionality.
If you're not going to use the object caching functionality, you can just
call the underlying memory allocator directly.

							Jeffrey




From dillon at apollo.backplane.com  Mon Mar 31 16:17:19 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Mon, 31 Mar 2008 16:17:19 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <200803311841.m2VIfQAI007579@nlpi001.prodigy.net>
Message-ID: <200803312311.m2VNBumd029866@apollo.backplane.com>

:Could we please not move to kmalloc, but instead try to move all fast
:path allocations to objcache?  I don't like the idea of allocating
:everything with kmalloc.  Caching struct procs is not a bad thing itself.=
:
:
:cheers
:  simon

    I will state for the record that I'm fine with either objcache or
    kmalloc.  I agree with Jeff that using objcache for struct proc
    probably isn't necessary but I also agree that it would not hurt either,
    and if the intent is to optimize the initialization of the proc
    structure in the future then moving to objcache now would save us
    from having to do it later.

    So whichever method Nicolas wants to use is fine with me.

						-Matt




From hsu at dragonflybsd.org  Mon Mar 31 19:22:47 2008
From: hsu at dragonflybsd.org (Jeffrey Hsu)
Date: Mon, 31 Mar 2008 19:22:47 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <64fc43b0803311214u7da6bbb8xaf971de1a80e7258@mail.gmail.com>
Message-ID: <200804010218.m312IVUq003624@nlpi043.prodigy.net>

  >> Are there significant portions of the proc structure
  >> that can be restored to initialized state on object puts?

  > I planned to do this in a second step after getting rid of zones.

I'll all in favor of making more use of caching pre-initialized objects, so
if this is your objective, then please go ahead.  It's just that I'd convert
over to the object cache in one step.

  > I thought that even without  the pre-initialization part, objcache has
  > the advantage of pre-allocating set of objects (as zones) and is additionally
  > mp-safe (contrary to zones and, granted, as malloc()).

Well, the zone allocator is MP-safe.  It's not hard to lock up the places that
manipulate the linked-list of free items. Look for uses of the zlock field.

								Jeffrey




From tgen at netphreax.net  Sat Mar  1 12:57:53 2008
From: tgen at netphreax.net (Thomas E. Spanjaard)
Date: Sat, 1 Mar 2008 12:57:53 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: [Fwd: Project Support Open Source: $50 donation to support you      project]
In-Reply-To: <2468.192.168.0.242.1204346451.squirrel@www.shiningsilence.com>
Message-ID: <47C9C1B7.50203@netphreax.net>

Justin C. Sherrill wrote:
The "donation" happens after you place an "acknowledgement" on an open
source project's web page.  I'm putting those words in scare quotes
because I think it's a "payment" for an "advertisement".  The supplied
link has nothing to do with DragonFly, to say the least.

<a href="http://www.2insure4less.com /" title="We support FOSS software
projects.">Online Insurance Quotes</a>
To think our souls are only worth $50...
--
        Thomas E. Spanjaard
        tgen at netphreax.net
Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00000.pgp
Type: application/octet-stream
Size: 186 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080301/0d61e240/attachment-0010.obj>

From c.turner at 199technologies.org  Sat Mar  1 17:52:31 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Sat, 1 Mar 2008 17:52:31 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Misc. ACPI / suspend
Message-ID: <47CA073B.6020106@199technologies.org>

Wondering if anyone more well versed in the ACPI implementation could
comment on the applicability of:
http://lkml.org/lkml/2007/4/6/69

w/r/t the current state of the art in Dfly

(or BSD's in general)

Cheers!

- Chris




From elekktretterr at exemail.com.au  Sun Mar  2 00:41:25 2008
From: elekktretterr at exemail.com.au (Petr Janda)
Date: Sun, 2 Mar 2008 00:41:25 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: CARP question
Message-ID: <200803021934.21669.elekktretterr@exemail.com.au>

So Ive setup CARP on 2 DF-based mailservers. Installation went fine. Box 1 has 
adskew of 0 therefore it is the MASTER. Box 2 has adskew of 254, therefore is 
BACKUP.  If i down the carp0 interface on Box 1, then Box 2 carp interface 
gets promoted to MASTER. Then I up the carp interface on Box 1, logically Box 
2 should become BACKUP again as Box 1 becomes MASTER due to adskew set to 0.

However it doesnt happen. When carp0 interface on Box 1 is upped it becomes a 
BACKUP, not a MASTER even though according to adskew it should be MASTER.

What is the desired behaviour?

Cheers
Petr




From qhwt+dfly at les.ath.cx  Sun Mar  2 02:50:14 2008
From: qhwt+dfly at les.ath.cx (YONETANI Tomokazu)
Date: Sun, 2 Mar 2008 02:50:14 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: panic: assertion: hammer_btree_cmp(cursor->left_bound,	&cursor->node->ondisk->elms[0].leaf.base) <= 0 in btree_split_leaf
In-Reply-To: <200802232204.m1NM4cxd046264@apollo.backplane.com>
Message-ID: <20080302104554.GA22813@les.ath.cx>

Hi.
While trying to find a procedure to reliably reproduce the panic
I reported last time, I caught a different panic (uploaded at
 ~y0netan1/crash/9/ on my leaf account).  I wrote the following shell
script (make sure to edit variables DISKS and MOUNTPT before using this
script or it may trash your system):
  #!/bin/sh -ex
  DISKS="/dev/ad0s1f"
  MOUNTPT=/mnt/HAMMER

  cd /
  newfs_hammer -L TEST $DISKS
  for i in `seq 1 100`; do
	  mount_hammer $DISKS $MOUNTPT
	  /bin/rm -rf $MOUNTPT/??
	  (set +x; for x in `seq 1 10000`; do echo -n > $MOUNTPT/$x; done)
	  umount $MOUNTPT
  done

And the panic is triggered by rm command.
I'll try to see if it's possible to reproduce the last one without
unmounting then mounting the HAMMER fs.

Cheers.




From dillon at apollo.backplane.com  Sun Mar  2 13:25:33 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Sun, 2 Mar 2008 13:25:33 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: panic: assertion: hammer_btree_cmp(cursor->left_bound,	&cursor->node->ondisk->elms[0].leaf.base) <= 0 in btree_split_leaf
In-Reply-To: <200802232204.m1NM4cxd046264@apollo.backplane.com>
Message-ID: <200803022119.m22LJRCY037076@apollo.backplane.com>


:Hi.
:While trying to find a procedure to reliably reproduce the panic
:I reported last time, I caught a different panic (uploaded at
: ~y0netan1/crash/9/ on my leaf account).  I wrote the following shell
:script (make sure to edit variables DISKS and MOUNTPT before using this
:script or it may trash your system):

(from the core)

panic: assertion: node->lock.refs == 0 && node->ondisk == NULL in hammer_flush_buffer_nodes

    Yah, I've seen this failure.  Add a sync or two before the umount and
    tell me if it still occurs.  It's either a node reference leak somewhere
    or it is a race between bufdaemon and umount.  The assertions are really
    strict there precisely to catch those sorts of cases.

    Also note that the code to deal with a full HAMMMER filesystem has not
    been written yet (The failure you are reporting is unrelated to a full
    HAMMER filesystem, though, just mentioning it).

						-Matt





From dillon at apollo.backplane.com  Sun Mar  2 13:29:03 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Sun, 2 Mar 2008 13:29:03 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Misc. ACPI / suspend
In-Reply-To: <47CA073B.6020106@199technologies.org>
Message-ID: <200803022126.m22LQbfI037188@apollo.backplane.com>


:Wondering if anyone more well versed in the ACPI implementation could
:comment on the applicability of:
:
:http://lkml.org/lkml/2007/4/6/69
:
:w/r/t the current state of the art in Dfly
:
:(or BSD's in general)
:
:Cheers!
:
:- Chris

    I really have no idea re: this.  Suspension in general is not well
    supported by any of the BSDs.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From dillon at apollo.backplane.com  Sun Mar  2 13:34:05 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Sun, 2 Mar 2008 13:34:05 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: [Fwd: Project Support Open Source: $50 donation to support you      project]
In-Reply-To: <2468.192.168.0.242.1204346451.squirrel@www.shiningsilence.com>
Message-ID: <200803022131.m22LVOe9037250@apollo.backplane.com>

:..
:source project's web page.  I'm putting those words in scare quotes
:because I think it's a "payment" for an "advertisement".  The supplied
:link has nothing to do with DragonFly, to say the least.
:
:I don't think this is a good idea, obviously, and replied to that effect. 
:However, I wanted to put this on a DragonFly list, in part to show this
:strange thing, and in part because I'm not comfortable making
:administrative decisions on behalf of the Project without being open as
:possible about it.

    It doesn't really cry out to me either.

						-Matt





From wbh at conducive.org  Sun Mar  2 20:36:32 2008
From: wbh at conducive.org (Bill Hacker)
Date: Mon, 03 Mar 2008 04:36:32 +0000
Subject: Misc. ACPI / suspend
In-Reply-To: <47CA073B.6020106@199technologies.org>
Message-ID: <47cb8050$0$855$415eb37d@crater_reader.dragonflybsd.org>

Matthew Dillon wrote:
:Wondering if anyone more well versed in the ACPI implementation could
:comment on the applicability of:
:
:http://lkml.org/lkml/2007/4/6/69
:
:w/r/t the current state of the art in Dfly
:
:(or BSD's in general)
:
:Cheers!
:
:- Chris
    I really have no idea re: this.  Suspension in general is not well
    supported by any of the BSDs.
					-Matt
					Matthew Dillon 
					<dillon at backplane.com>


. . and there seems to be a bit of a 'Catch 22' there in any case.

If the BIOS can alter 'stuff' out of site of the OS it is parking, what 
does the existence of such a 'feature' do to a(ny) security model?

Seems to at least beg creating the option of setting a flag to 
specifically *prevent* suspend-to-disk/hibernation (and/or force a 
reboot on wake-up).

Just because one is paranoid....  etc

Bill





From matthias at dragonflybsd.org  Tue Mar  4 02:30:52 2008
From: matthias at dragonflybsd.org (Matthias Schmidt)
Date: Tue, 4 Mar 2008 02:30:52 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
Message-ID: <20080304102335.GI9833@staatsfeind.org>

Hi,

Google just announced its Summer of Code for 2008:

	http://code.google.com/soc/2008/

I think this would be a great opportunity for DragonFly to participate
as a mentoring organisation.  We could attract new developers and could
get code/work done.  Looking at the SoC results of the other BSDs most
of their projects were a success.  Of course, not all, but a reasonable
percentage.  See [1] and [2].

It is some extra work for us, but IMO the benefits outweigh the extra
work.  And yes, I would volunteer as a mentor.  What do others
(developers) think?  Any more volunteers? :)

Some project ideas that come into my mind.  More ideas are listed in the
wiki:  http://wiki.dragonflybsd.org/index.cgi/ProjectsPage

 * Fix all remaining bugs in dma(8) and implement all missing features
 * Add a driver for newer Intel Wireless cards (I think sephe@ would
   love that :)
 * Bring our ACPI stuff in shape.  Maybe suspend2disk ...

 * [Add your own thoughts here]

Cheers,

	Matthias

PS: I don't want to create a bikeshed here whether you like the SoC or
not :)

[1] http://code.google.com/soc/2007/freebsd/about.html
[2] http://code.google.com/soc/2007/netbsd/about.html




From corecode at fs.ei.tum.de  Tue Mar  4 04:46:14 2008
From: corecode at fs.ei.tum.de (Simon 'corecode' Schubert)
Date: Tue, 4 Mar 2008 04:46:14 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47CD4386.1000704@fs.ei.tum.de>

Matthias Schmidt wrote:
>  * [Add your own thoughts here]

MP lock removal for network stack

and for the system  (first profile, find hot spots, fix hot spots, repeat)

cheers
  simon




From c.turner at 199technologies.org  Tue Mar  4 06:02:20 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Tue, 4 Mar 2008 06:02:20 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47CD551E.1040604@199technologies.org>

Matthias Schmidt wrote:
Some project ideas that come into my mind.  More ideas are listed in the
wiki:  http://wiki.dragonflybsd.org/index.cgi/ProjectsPage
+1 acpi
+1 interrupt routing
+1 SMP / giant removal
+1 pf synchup with openbsd
though there are several others on the page that are good..

need to dig up my wiki login and place appropriately..

also: thinking the ZFS port should be removed from the page - makes 
sense to everyone else? (e.g. fragments effort w/r/t hammer)





From tgen at netphreax.net  Tue Mar  4 06:54:31 2008
From: tgen at netphreax.net (Thomas E. Spanjaard)
Date: Tue, 4 Mar 2008 06:54:31 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47CD615F.8010209@netphreax.net>

Matthias Schmidt wrote:
Google just announced its Summer of Code for 2008:

 * [Add your own thoughts here]
x86-64 port :).
--
        Thomas E. Spanjaard
        tgen at netphreax.net
Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00001.pgp
Type: application/octet-stream
Size: 186 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080304/0d921000/attachment-0010.obj>

From rdivacky at FreeBSD.org  Tue Mar  4 07:07:03 2008
From: rdivacky at FreeBSD.org (Roman Divacky)
Date: Tue, 4 Mar 2008 07:07:03 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <20080304150255.GA8831@freebsd.org>

On Tue, Mar 04, 2008 at 02:49:03PM +0000, Thomas E. Spanjaard wrote:
> Matthias Schmidt wrote:
> >Google just announced its Summer of Code for 2008:
> >
> > * [Add your own thoughts here]
> 
> x86-64 port :).

all those ideas are great and needed etc. but keep in
mind that the projects should be doable by students
who might see dfly for the very first time.

don't overestimate whats possible and select projects
that look realistic

Roman Divacky (former SoC student)




From justin at shiningsilence.com  Tue Mar  4 08:32:56 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Tue, 4 Mar 2008 08:32:56 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <60322.65.106.147.226.1204648095.squirrel@www.shiningsilence.com>

On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
> Hi,
>
> Google just announced its Summer of Code for 2008:
>
> 	http://code.google.com/soc/2008/
>
> I think this would be a great opportunity for DragonFly to participate
> as a mentoring organisation.  We could attract new developers and could
> get code/work done.  Looking at the SoC results of the other BSDs most
> of their projects were a success.  Of course, not all, but a reasonable
> percentage.  See [1] and [2].

We've applied in previous years - Jeff Hsu did one year, and I put
together the application last year.  The hardest thing to find was
students (and they are the thing that helps SoC applications a lot, I
think).

Any student volunteers?  We have mentors.





From rluciani at gmail.com  Tue Mar  4 09:38:29 2008
From: rluciani at gmail.com (Robert Luciani)
Date: Tue, 04 Mar 2008 18:38:29 +0100
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47cd8915$0$854$415eb37d@crater_reader.dragonflybsd.org>

Justin C. Sherrill wrote:
> On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
>> Hi,
>>
>> Google just announced its Summer of Code for 2008:
>>
>> 	http://code.google.com/soc/2008/
>>
>> I think this would be a great opportunity for DragonFly to participate
>> as a mentoring organisation.  We could attract new developers and could
>> get code/work done.  Looking at the SoC results of the other BSDs most
>> of their projects were a success.  Of course, not all, but a reasonable
>> percentage.  See [1] and [2].
> 
> We've applied in previous years - Jeff Hsu did one year, and I put
> together the application last year.  The hardest thing to find was
> students (and they are the thing that helps SoC applications a lot, I
> think).
> 
> Any student volunteers?  We have mentors.
> 

bingo

-- 
Robert Luciani
Chalmers University of Technology, SWE
Department of Computer Science and Engineering
http://www.rluciani.com/public.key




From sdavtaker at gmail.com  Tue Mar  4 09:31:08 2008
From: sdavtaker at gmail.com (=?UTF-8?Q?Sd=C3=A4vtaker?=)
Date: Tue, 4 Mar 2008 09:31:08 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <c37d69f60803040926k206218a3kb8496d0cd18148bd@mail.gmail.com>

If you mentor, i will apply for coder :-)
Still in last year of university. :-)
Sdav

On Tue, Mar 4, 2008 at 1:28 PM, Justin C. Sherrill
<justin at shiningsilence.com> wrote:
> On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
>  > Hi,
>  >
>  > Google just announced its Summer of Code for 2008:
>  >
>  >       http://code.google.com/soc/2008/
>  >
>  > I think this would be a great opportunity for DragonFly to participate
>  > as a mentoring organisation.  We could attract new developers and could
>  > get code/work done.  Looking at the SoC results of the other BSDs most
>  > of their projects were a success.  Of course, not all, but a reasonable
>  > percentage.  See [1] and [2].
>
>  We've applied in previous years - Jeff Hsu did one year, and I put
>  together the application last year.  The hardest thing to find was
>  students (and they are the thing that helps SoC applications a lot, I
>  think).
>
>  Any student volunteers?  We have mentors.
>
>



-- 
Sd?vtaker prays to Rikku goddess for a good treasure.



From rluciani at gmail.com  Tue Mar  4 09:44:02 2008
From: rluciani at gmail.com (Robert Luciani)
Date: Tue, 04 Mar 2008 18:44:02 +0100
Subject: google soc "DragonFly"
Message-ID: <47cd8a63$0$855$415eb37d@crater_reader.dragonflybsd.org>

On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
> > Hi,
> >
> > Google just announced its Summer of Code for 2008:
> >
> > 	http://code.google.com/soc/2008/
> >
> > I think this would be a great opportunity for DragonFly to participate
> > as a mentoring organisation.  We could attract new developers and could
> > get code/work done.  Looking at the SoC results of the other BSDs most
> > of their projects were a success.  Of course, not all, but a reasonable
> > percentage.  See [1] and [2].

We've applied in previous years - Jeff Hsu did one year, and I put
together the application last year.  The hardest thing to find was
students (and they are the thing that helps SoC applications a lot, I
think).

Any student volunteers?  We have mentors.


-- 
Robert Luciani
Chalmers University of Technology, SWE
Department of Computer Science and Engineering
http://www.rluciani.com/public.key




From rluciani at gmail.com  Tue Mar  4 10:04:14 2008
From: rluciani at gmail.com (Robert Luciani)
Date: Tue, 04 Mar 2008 19:04:14 +0100
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47cd8f1f$0$856$415eb37d@crater_reader.dragonflybsd.org>

Robert Luciani wrote:
> Justin C. Sherrill wrote:
>> On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
>>> Hi,
>>>
>>> Google just announced its Summer of Code for 2008:
>>>
>>> 	http://code.google.com/soc/2008/
>>>
>>> I think this would be a great opportunity for DragonFly to participate
>>> as a mentoring organisation.  We could attract new developers and could
>>> get code/work done.  Looking at the SoC results of the other BSDs most
>>> of their projects were a success.  Of course, not all, but a reasonable
>>> percentage.  See [1] and [2].
>> We've applied in previous years - Jeff Hsu did one year, and I put
>> together the application last year.  The hardest thing to find was
>> students (and they are the thing that helps SoC applications a lot, I
>> think).
>>
>> Any student volunteers?  We have mentors.
>>
> 
> bingo
> 
My girlfriend Danwei noted that she would also like partake in the SoC.
She's studying IT here at Chalmers and will join the mailing list shortly.
-- 
Robert Luciani
Chalmers University of Technology, SWE
Department of Computer Science and Engineering
http://www.rluciani.com/public.key




From dillon at apollo.backplane.com  Tue Mar  4 13:08:30 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Tue, 4 Mar 2008 13:08:30 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Going to have to roll 1.12.1
Message-ID: <200803042104.m24L43g1065278@apollo.backplane.com>

    Due to a critical bug in sendmail that can cause it to seg-fault I will
    be rolling 1.12.1 as soon as I get verification that the current
    fix deals with it.

						-Matt





From sdavtaker at gmail.com  Tue Mar  4 17:40:43 2008
From: sdavtaker at gmail.com (=?UTF-8?B?U2TDpHZ0YWtlcg==?=)
Date: Tue, 4 Mar 2008 17:40:43 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: [Fwd: Project Support Open Source: $50 donation to support you  project]
In-Reply-To: <2468.192.168.0.242.1204346451.squirrel@www.shiningsilence.com>
Message-ID: <47CDF8D1.9070100@gmail.com>

50 bucks?
Come on...
You can get a meal a lot more expensive than that just going to a free 
HP conference about linux and you only have to rent your soul 3-5 hours ;-)
Sdav

Matthew Dillon escribi?:
:..
:source project's web page.  I'm putting those words in scare quotes
:because I think it's a "payment" for an "advertisement".  The supplied
:link has nothing to do with DragonFly, to say the least.
:
:I don't think this is a good idea, obviously, and replied to that effect. 
:However, I wanted to put this on a DragonFly list, in part to show this
:strange thing, and in part because I'm not comfortable making
:administrative decisions on behalf of the Project without being open as
:possible about it.

    It doesn't really cry out to me either.

						-Matt

  






From sdavtaker at gmail.com  Tue Mar  4 17:56:35 2008
From: sdavtaker at gmail.com (=?UTF-8?B?U2TDpHZ0YWtlcg==?=)
Date: Tue, 4 Mar 2008 17:56:35 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47CDFCCE.1010106@gmail.com>

A cute idea for for GSOC would be to finish the installer.
We were talking about this in my local BUG, we trying to find out how to 
help on that from here.
There is a few missing features in the CD.

   * FDISK, you need to create the slides from another OS before
     install DFBSD, i think port FDisk from FBSD or any *BSD will solve it.
   * Add to the make release a way to add some custom applications to
     the released liveCD (suppose you want to add nmap or ssh or
     something just to use as test disk in some enviroment).
   * Make the installer a little more customizable, and maybe w/ a GUI
     (I like a lot the console approach, but GUI installer will be a
     popularity move, DFBSD w/X makes a Desktop machine work, actually
     im using it that way and really like it).
I think those projects can be done in a SOC by students (like me) with a 
little guide.
Im a lot more interested in things network related and kernel, but i 
dont mind to work on those things, they need to be done some day.
What u think?
Sdav

Robert Luciani escribi?:
Robert Luciani wrote:
  
Justin C. Sherrill wrote:
    
On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
      
Hi,

Google just announced its Summer of Code for 2008:

	http://code.google.com/soc/2008/

I think this would be a great opportunity for DragonFly to participate
as a mentoring organisation.  We could attract new developers and could
get code/work done.  Looking at the SoC results of the other BSDs most
of their projects were a success.  Of course, not all, but a reasonable
percentage.  See [1] and [2].
        
We've applied in previous years - Jeff Hsu did one year, and I put
together the application last year.  The hardest thing to find was
students (and they are the thing that helps SoC applications a lot, I
think).
Any student volunteers?  We have mentors.

      
bingo

    
My girlfriend Danwei noted that she would also like partake in the SoC.
She's studying IT here at Chalmers and will join the mailing list shortly.
  






From c.turner at 199technologies.org  Tue Mar  4 18:30:53 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Tue, 4 Mar 2008 18:30:53 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47CE04C9.1010902@199technologies.org>

Justin C. Sherrill wrote:
together the application last year.  The hardest thing to find was
students (and they are the thing that helps SoC applications a lot, I
think).
umm.. if google wants to send me back to school, I'll sign up - hows 
that for a fair trade :?






From wbh at conducive.org  Tue Mar  4 23:52:13 2008
From: wbh at conducive.org (Bill Hacker)
Date: Wed, 05 Mar 2008 07:52:13 +0000
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47ce512e$0$855$415eb37d@crater_reader.dragonflybsd.org>

Sd?vtaker wrote:
A cute idea for for GSOC would be to finish the installer.
We were talking about this in my local BUG, we trying to find out how to 
help on that from here.
There is a few missing features in the CD.

   * FDISK, you need to create the slides from another OS before
     install DFBSD, i think port FDisk from FBSD or any *BSD will solve it.
I'd rather see that 'reversed' - i.e. - build a more capable fdisk in 
DFLY with hope that it might be seen worth importing into Free/Net/Open, 
or *at least* be able to do a more flexible job than those now do.

And disklabels as well. Hand in glove.

Here's why:

- At the moment, working with Free, Open, DFLY, and OpenSolaris on the 
same HDD requires a bit of acrobatics.

- There seems to now be greater divergence between/among the *BSD's as 
to being able to read each other's disklabels, mount and use each 
other's 'flavor' of FFS/UFS (not to mention Apple's implementation of 
UFS) than there is among the vast multitude of Linux ext2/3 denizens.

Even to the point where use of a *Linux* fs is the more universal way 
for being able to share mounts among the *BSD's. Think detached drives. 
And no - FAT is not all that practical for several reasons.

- DFLY currently has the most fine-grain ability to create slices and 
partitions. But the others cannot all (any?) read those.

'progress' w/r any of the *BSD's direction as to changes, improvements 
(or not) in their once-common-ancestry fs & disklabels need not be 
sacrificed.

I'm not holding out wish or hope for all players agreeing to return to 
'one sacred way'. Nor 'one new universal fs'. Neither is gonna happen.

But a 'legacy compatible' or least-common-denominator mode would do fine 
- most especially for portable / SAN devices.

So - how about a 'flexible' DFLY fdisk to go along with a 'flexible' 
disklabel that could adapt to whatever it found / was told to create?

JM2CW - but that *might* be a good place to get a cross-*BSD team together.

*snip* (other good stuff)

Bill Hacker




From matthias at dragonflybsd.org  Wed Mar  5 01:02:43 2008
From: matthias at dragonflybsd.org (Matthias Schmidt)
Date: Wed, 5 Mar 2008 01:02:43 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <20080305085747.GJ9833@staatsfeind.org>

Hi,

* Justin C. Sherrill wrote:
> 
> We've applied in previous years - Jeff Hsu did one year, and I put
> together the application last year.  The hardest thing to find was
> students (and they are the thing that helps SoC applications a lot, I
> think).

This is good to know, so we could coordinate that if we have enough
mentors and projects?!?  I put together a small text in the wiki:

http://wiki.dragonflybsd.org/index.cgi/GoogleSoC2008

Feel free to add project or missing stuff.  I'm sure I missed a lot of
things :)

> Any student volunteers?  We have mentors.

According to the discussion we could have some students, who would be a
mentor (besides me)?

Regards

	Matthias





From sdavtaker at gmail.com  Wed Mar  5 06:28:37 2008
From: sdavtaker at gmail.com (=?UTF-8?Q?Sd=C3=A4vtaker?=)
Date: Wed, 5 Mar 2008 06:28:37 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <c37d69f60803050624kd86d3d0w3b44a02d0e5a5391@mail.gmail.com>

<quote>
Write a driver (from scratch) for Intel 3945 wireless device
Mentor: Sepherosa Ziehau
</quote>

Yes yes yes, i want to :-)
Someone else planning to mentor in drivers coding?
Sdav

On Wed, Mar 5, 2008 at 5:57 AM, Matthias Schmidt
<matthias at dragonflybsd.org> wrote:
> Hi,
>
>
>  * Justin C. Sherrill wrote:
>  >
>  > We've applied in previous years - Jeff Hsu did one year, and I put
>  > together the application last year.  The hardest thing to find was
>  > students (and they are the thing that helps SoC applications a lot, I
>  > think).
>
>  This is good to know, so we could coordinate that if we have enough
>  mentors and projects?!?  I put together a small text in the wiki:
>
>  http://wiki.dragonflybsd.org/index.cgi/GoogleSoC2008
>
>  Feel free to add project or missing stuff.  I'm sure I missed a lot of
>  things :)
>
>
>  > Any student volunteers?  We have mentors.
>
>  According to the discussion we could have some students, who would be a
>  mentor (besides me)?
>
>  Regards
>
>         Matthias
>
>



-- 
Sd?vtaker prays to Rikku goddess for a good treasure.



From rluciani at gmail.com  Wed Mar  5 10:56:42 2008
From: rluciani at gmail.com (Robert Luciani)
Date: Wed, 05 Mar 2008 19:56:42 +0100
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47ceecea$0$847$415eb37d@crater_reader.dragonflybsd.org>

Sd?vtaker wrote:
> <quote>
> Write a driver (from scratch) for Intel 3945 wireless device
> Mentor: Sepherosa Ziehau
> </quote>
> 
> Yes yes yes, i want to :-)
> Someone else planning to mentor in drivers coding?
> Sdav
> 
> On Wed, Mar 5, 2008 at 5:57 AM, Matthias Schmidt
> <matthias at dragonflybsd.org> wrote:
>> Hi,
>>
>>
>>  * Justin C. Sherrill wrote:
>>  >
>>  > We've applied in previous years - Jeff Hsu did one year, and I put
>>  > together the application last year.  The hardest thing to find was
>>  > students (and they are the thing that helps SoC applications a lot, I
>>  > think).
>>
>>  This is good to know, so we could coordinate that if we have enough
>>  mentors and projects?!?  I put together a small text in the wiki:
>>
>>  http://wiki.dragonflybsd.org/index.cgi/GoogleSoC2008
>>
>>  Feel free to add project or missing stuff.  I'm sure I missed a lot of
>>  things :)
>>
>>
>>  > Any student volunteers?  We have mentors.
>>
>>  According to the discussion we could have some students, who would be a
>>  mentor (besides me)?
>>
>>  Regards
>>
>>         Matthias
>>
>>
> 
> 
>

IF someone starts to write a 3945 Intel driver,
please keep the newer 4965 in mind too.

-- 
Robert Luciani
Chalmers University of Technology, SWE
Department of Computer Science and Engineering
http://www.rluciani.com/public.key




From joerg at britannica.bec.de  Wed Mar  5 12:01:05 2008
From: joerg at britannica.bec.de (Joerg Sonnenberger)
Date: Wed, 5 Mar 2008 12:01:05 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <20080305195711.GA9981@britannica.bec.de>

On Wed, Mar 05, 2008 at 07:56:42PM +0100, Robert Luciani wrote:
> IF someone starts to write a 3945 Intel driver,
> please keep the newer 4965 in mind too.

NetBSD's wpi works quite well. The hardware is quite different from
4945.

Joerg




From sepherosa at gmail.com  Wed Mar  5 17:48:50 2008
From: sepherosa at gmail.com (Sepherosa Ziehau)
Date: Wed, 5 Mar 2008 17:48:50 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <ea7b9c170803051744u22b09484ofc994f034f11df3b@mail.gmail.com>

On Thu, Mar 6, 2008 at 2:56 AM, Robert Luciani <rluciani at gmail.com> wrote:
>  IF someone starts to write a 3945 Intel driver,

"IF" you know that trying to fix any wired bugs in certain drivers
(e.g. ipw, ral) will require you to read through all of the vendor's
linux code (yes, even including register values and position), i.e.
there is not much difference between writing one from scratch and
porting+fixing_bugs, then you probably will not put "IF" at the start
of your sentence.
If what I said sounded too harsh to you, then I was sorry.

>  please keep the newer 4965 in mind too.

Will do, once generic 11n support is brought in from freebsd.

Best Regards,
sephe

-- 
Live Free or Die




From saw at online.de  Thu Mar  6 05:34:14 2008
From: saw at online.de (Sascha Wildner)
Date: Thu, 06 Mar 2008 14:34:14 +0100
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
Message-ID: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>

Hi all,

this is probably as good a moment as any to come out of the forest with 
this. The patch at

http://leaf.dragonflybsd.org/~swildner/nrelease_gui.diff

adds some code to nrelease/ to build a LiveCD with xorg and so on 
(currently, only the xorg metapackages and fluxbox are added). In order 
to build one, you need a local dir with the pkgsrc binary packages (see 
below).

The following commands should then do the trick:

cd /usr/src
make buildworld
make buildkernel
cd nrelease
patch -p 0 </path/to/the/patch
make PKGSRC_PKG_PATH=/path/to/packages/dir/All realquick gui
The resulting ISO will be in /usr/release/dfly-gui.iso then. It will not 
boot into xorg automatically (although this is easily possible), so you 
need to login as root and do startx.

As of now, this all is kind of basic, more a proof of concept than 
anything else. As our release framework installs packages via chroot, 
the current setup just copies _all_ packages to the chroot before 
installing (kind of a hack).

That said, I'm now primarily interested in opinions/ideas/... about the 
direction this should take. Which packages would we like to see on the 
CD? Should it be a generic setup with the "most common things" 
installed, so a system can be quickly setup by the installer (which will 
cpdup /usr/pkg). Or should it be a more specialized set of tools? Or 
even as many packages as possible (Live DVD?). Etc., etc.

Before continuing on it, I'm really interested in people's input so 
don't hold anything back, please. :)

Sascha

--
http://yoyodyne.ath.cx



From rluciani at gmail.com  Thu Mar  6 06:42:03 2008
From: rluciani at gmail.com (Robert Luciani)
Date: Thu, 06 Mar 2008 15:42:03 +0100
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <47d002bc$0$847$415eb37d@crater_reader.dragonflybsd.org>

Sascha Wildner wrote:
> Hi all,
> 
> this is probably as good a moment as any to come out of the forest with
> this. The patch at
> 
> http://leaf.dragonflybsd.org/~swildner/nrelease_gui.diff
> 
> adds some code to nrelease/ to build a LiveCD with xorg and so on
> (currently, only the xorg metapackages and fluxbox are added). In order
> to build one, you need a local dir with the pkgsrc binary packages (see
> below).
> 
> The following commands should then do the trick:
> 
> cd /usr/src
> make buildworld
> make buildkernel
> cd nrelease
> patch -p 0 </path/to/the/patch
> make PKGSRC_PKG_PATH=/path/to/packages/dir/All realquick gui
> 
> The resulting ISO will be in /usr/release/dfly-gui.iso then. It will not
> boot into xorg automatically (although this is easily possible), so you
> need to login as root and do startx.
> 
> As of now, this all is kind of basic, more a proof of concept than
> anything else. As our release framework installs packages via chroot,
> the current setup just copies _all_ packages to the chroot before
> installing (kind of a hack).
> 
> That said, I'm now primarily interested in opinions/ideas/... about the
> direction this should take. Which packages would we like to see on the
> CD? Should it be a generic setup with the "most common things"
> installed, so a system can be quickly setup by the installer (which will
> cpdup /usr/pkg). Or should it be a more specialized set of tools? Or
> even as many packages as possible (Live DVD?). Etc., etc.
> 
> Before continuing on it, I'm really interested in people's input so
> don't hold anything back, please. :)
> 
> Sascha
> 

I think the main point of such a live-cd would be to test
dragonfly-specific features such as vkernels and more. Mplayer and
OpenOffic work the same on all platforms, so they might not be super
important, while irssi, firefox, networking tools, vim, a few more
shells/terminals might make it easier to for people to quickly gauge if
they can reproduce their current productivity and also what is new.

And if the point of a livecd is to test that kind of stuff, then it
would be nice for it to have a kernel that supports as much as possible
like ALTQ, and drivers.

Also if it has lots and lots of programs (thinking multimedia, java,
etc..) it might be hard to keep the future x64 and x86 live-cds on par.
Gentoo had this problem many years ago and it was very bothersome.

-- 
Robert Luciani
Chalmers University of Technology, SWE
Department of Computer Science and Engineering
http://www.rluciani.com/public.key




From matthias at dragonflybsd.org  Thu Mar  6 07:12:43 2008
From: matthias at dragonflybsd.org (Matthias Schmidt)
Date: Thu, 6 Mar 2008 07:12:43 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <20080306150757.GN9833@staatsfeind.org>

* Sascha Wildner wrote:
> Hi all,
> 
> this is probably as good a moment as any to come out of the forest with this. 
> The patch at
> 
> http://leaf.dragonflybsd.org/~swildner/nrelease_gui.diff
> 
> adds some code to nrelease/ to build a LiveCD with xorg and so on (currently, 
> only the xorg metapackages and fluxbox are added). In order to build one, you 
> need a local dir with the pkgsrc binary packages (see below).

Great work Sascha.

I agree with Robert on most of his stated points.
It would be nice to see some DragonFly specific features on the CD
(although I'm not sure if that will work for all features).  A little
environment where most Unix users feel at home (fluxbox, xfce, firefox,
thunderbird, gvim) should be enough.

Big applications like OO.org, java etc won't work because they are not
available as pkgsrc packages neither is it possible to compile them on
DragonFly.  At least to my knowledge.

Regards

	Matthias




From dillon at apollo.backplane.com  Thu Mar  6 09:31:52 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Thu, 6 Mar 2008 09:31:52 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <200803061728.m26HSR3O091809@apollo.backplane.com>


:Hi all,
:
:this is probably as good a moment as any to come out of the forest with 
:this. The patch at
:
:http://leaf.dragonflybsd.org/~swildner/nrelease_gui.diff
:
:adds some code to nrelease/ to build a LiveCD with xorg and so on 
:(currently, only the xorg metapackages and fluxbox are added). In order 
:to build one, you need a local dir with the pkgsrc binary packages (see 
:below).
:
:The following commands should then do the trick:

    It looks reasonable, though the package copy has to be tightened
    up a bit I think.

:...
:installed, so a system can be quickly setup by the installer (which will 
:cpdup /usr/pkg). Or should it be a more specialized set of tools? Or 
:even as many packages as possible (Live DVD?). Etc., etc.
:
:Before continuing on it, I'm really interested in people's input so 
:don't hold anything back, please. :)
:
:Sascha

    I think this is an excellent time to work up a DVD build and to
    add various 'flavor' extras.  So, e.g.:

	make installer gui gui_extras release dvd

    (All 'dvd' would do is generate a dvd compatible image for burning to
    dvd instead of cd).  I did a quick perusal of what I have on my
    workstation:

    * X
    * Firefox
    * Linux emulation
    * Open Office (linux version)
    * fvwm2
    * xpdf
    * freetype2

    I'd also suggest some image editing tools like gimp, and maybe the KDE
    gui suite.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From justin at shiningsilence.com  Thu Mar  6 09:42:44 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Thu, 6 Mar 2008 09:42:44 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <55427.65.106.147.226.1204825168.squirrel@www.shiningsilence.com>

On Thu, March 6, 2008 8:34 am, Sascha Wildner wrote:

> That said, I'm now primarily interested in opinions/ideas/... about the
> direction this should take. Which packages would we like to see on the
> CD? Should it be a generic setup with the "most common things"
> installed, so a system can be quickly setup by the installer (which will
> cpdup /usr/pkg). Or should it be a more specialized set of tools? Or
> even as many packages as possible (Live DVD?). Etc., etc.

What Robert said is good - whatever's needed to enable DragonFly-specific
features.  Along with that would be some sort of documentation (a README? 
A HTML file on whatever desktop we provide) that points people at the
different DragonFly tools, so they know what to try and how to try it.

There's going to be some percentage of people who try DragonFly who don't
know about vkernels, for instance, but there's our chance to educate them.
 I'm probably volunteering myself, aren't I?





From sdavtaker at gmail.com  Thu Mar  6 09:50:09 2008
From: sdavtaker at gmail.com (=?UTF-8?Q?Sd=C3=A4vtaker?=)
Date: Thu, 6 Mar 2008 09:50:09 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <c37d69f60803060947t110750c0sd6b542ea505d188d@mail.gmail.com>

Cool Sascha :-)
I just posted about this 1 or 2 days ago in the SOC project ideas thread.
Want to mentor this one? ;-)
Damian

On Thu, Mar 6, 2008 at 2:28 PM, Matthew Dillon
<dillon at apollo.backplane.com> wrote:
>
>  :Hi all,
>
> :
>  :this is probably as good a moment as any to come out of the forest with
>  :this. The patch at
>  :
>  :http://leaf.dragonflybsd.org/~swildner/nrelease_gui.diff
>  :
>  :adds some code to nrelease/ to build a LiveCD with xorg and so on
>  :(currently, only the xorg metapackages and fluxbox are added). In order
>  :to build one, you need a local dir with the pkgsrc binary packages (see
>  :below).
>  :
>  :The following commands should then do the trick:
>
>     It looks reasonable, though the package copy has to be tightened
>     up a bit I think.
>
>  :...
>  :installed, so a system can be quickly setup by the installer (which will
>
> :cpdup /usr/pkg). Or should it be a more specialized set of tools? Or
>  :even as many packages as possible (Live DVD?). Etc., etc.
>  :
>  :Before continuing on it, I'm really interested in people's input so
>  :don't hold anything back, please. :)
>  :
>  :Sascha
>
>     I think this is an excellent time to work up a DVD build and to
>     add various 'flavor' extras.  So, e.g.:
>
>         make installer gui gui_extras release dvd
>
>     (All 'dvd' would do is generate a dvd compatible image for burning to
>     dvd instead of cd).  I did a quick perusal of what I have on my
>     workstation:
>
>     * X
>     * Firefox
>     * Linux emulation
>     * Open Office (linux version)
>     * fvwm2
>     * xpdf
>     * freetype2
>
>     I'd also suggest some image editing tools like gimp, and maybe the KDE
>     gui suite.
>
>                                         -Matt
>                                         Matthew Dillon
>                                         <dillon at backplane.com>
>



-- 
Sd?vtaker prays to Rikku goddess for a good treasure.



From saw at online.de  Thu Mar  6 11:54:01 2008
From: saw at online.de (Sascha Wildner)
Date: Thu, 06 Mar 2008 20:54:01 +0100
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <47d04ba2$0$856$415eb37d@crater_reader.dragonflybsd.org>

Matthew Dillon wrote:
    It looks reasonable, though the package copy has to be tightened
    up a bit I think.
It looks as if it would work with mount_null'ing the chroot's 
/tmp/packages. I'll have a better patch ready tomorrow.

Sascha

--
http://yoyodyne.ath.cx



From c.turner at 199technologies.org  Thu Mar  6 19:11:44 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Thu, 6 Mar 2008 19:11:44 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Misc. ACPI / suspend
In-Reply-To: <47CA073B.6020106@199technologies.org>
Message-ID: <47D0B079.3060905@199technologies.org>

Chris Turner wrote:
Wondering if anyone more well versed in the ACPI implementation could
comment on the applicability of:
http://lkml.org/lkml/2007/4/6/69

Doing a little digging, it seems like

. /platform/pc32/i386/i686_mem.c

*might* have the necessary infrastructure to remap the MTRR's per the 
thread referenced,

but:

. /platform/pc32/acpica5/acpi_wakeup.c

doesn't seem to be using this infrastructure..

I'm no where near reaching an understanding of this yet,
but I'm wondering 3 things:
1) does anyone have ACPI (instead of APM)
   sleep / suspend / wakeup working on Dfly ?
2) If so, what machines are being used ?
3) Same question for other BSDs - my understanding is NetBSD is most
   'advanced' w/r/t power managment - but I'm not 100% on this ...
would looove to have a sleeping / resuming / scaling laptop running some 
BSD flavor.. am willing to work towards that end, esp. w/r/t Dfly -
trying to chart a course to figguring this out.

Thanks all,

- Chris




From c.turner at 199technologies.org  Thu Mar  6 19:12:33 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Thu, 6 Mar 2008 19:12:33 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: PCI Bios / Interrupt remapping / etc
Message-ID: <47D0B211.6000002@199technologies.org>

Doing a bit of digging here for my long-standing CBB+SIO interupt and 
buffer problem -

one machine I've tested against was an OpenBSD machine, which didn't
always work to handle the cardbus sio card on a PCI cardbus adapter
-

tuning up some of the device flags in:

http://www.openbsd.org/cgi-bin/man.cgi?query=pcibios&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=html

seems to have alleviated the problem for that os..

I'm just only starting to get up to speed on how DF handles these types 
of things (namely initial PIC / interrupt layout at boot time device 
enumeration), but am wondering if anyone familiar with this area of the 
code has any comments / advice w/r/t the capabilities of the DF bios 
drivers
and the various quirks / fixup mentioned in the link above..

looking to possibly investigate fixing up some of these issues over time.

Thanks

- Chris







From pavalos at theshell.com  Fri Mar  7 01:14:55 2008
From: pavalos at theshell.com (Peter Avalos)
Date: Fri, 7 Mar 2008 01:14:55 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: cam locking
Message-ID: <20080307091024.GC1652@ylem.theshell.com>

So I've been working on locking up cam using lockmgr locks, and here's
what I have so far:

http://www.theshell.com/~pavalos/wip/cam-lock.patch

Most of the work is obtained from FreeBSD.  I've only been running this
on my SCSI machine for a day, but because the patch is so large, I wanted
to make it available for people to review if they have some spare time.

Thanks,
Peter
Attachment:
pgp00002.pgp
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00002.pgp
Type: application/octet-stream
Size: 197 bytes
Desc: "Description: PGP signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080307/9a17ecd8/attachment-0010.obj>

From jspringe at uos.de  Fri Mar  7 03:25:17 2008
From: jspringe at uos.de (Jost Tobias Springenberg)
Date: Fri, 7 Mar 2008 12:25:17 +0100
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <20080307122517.72c9e2b1.jspringe@uos.de>

On Tue, 4 Mar 2008 11:28:15 -0500 (EST)
"Justin C. Sherrill" <justin at shiningsilence.com> wrote:

> On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
> > Hi,
> >
> > Google just announced its Summer of Code for 2008:
> >
> > 	http://code.google.com/soc/2008/
> >
> > I think this would be a great opportunity for DragonFly to participate
> > as a mentoring organisation.  We could attract new developers and could
> > get code/work done.  Looking at the SoC results of the other BSDs most
> > of their projects were a success.  Of course, not all, but a reasonable
> > percentage.  See [1] and [2].
> 
> We've applied in previous years - Jeff Hsu did one year, and I put
> together the application last year.  The hardest thing to find was
> students (and they are the thing that helps SoC applications a lot, I
> think).
> 
> Any student volunteers?  We have mentors.
> 

I read this mailing list for quite a while now and thought about contributing stuff
to DFfly several times, so yes why not take this opportunity if it's there.

-- 
Jost Tobias Springenberg <jspringe at uos.de>




From tgen at netphreax.net  Fri Mar  7 05:17:27 2008
From: tgen at netphreax.net (Thomas E. Spanjaard)
Date: Fri, 7 Mar 2008 05:17:27 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: PCI Bios / Interrupt remapping / etc
In-Reply-To: <47D0B211.6000002@199technologies.org>
Message-ID: <47D13FB4.5080306@netphreax.net>

Chris Turner wrote:
Doing a bit of digging here for my long-standing CBB+SIO interupt and 
buffer problem -

one machine I've tested against was an OpenBSD machine, which didn't
always work to handle the cardbus sio card on a PCI cardbus adapter
-

tuning up some of the device flags in:

http://www.openbsd.org/cgi-bin/man.cgi?query=pcibios&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=html 

seems to have alleviated the problem for that os..

I'm just only starting to get up to speed on how DF handles these types 
of things (namely initial PIC / interrupt layout at boot time device 
enumeration), but am wondering if anyone familiar with this area of the 
code has any comments / advice w/r/t the capabilities of the DF bios 
drivers
and the various quirks / fixup mentioned in the link above..

looking to possibly investigate fixing up some of these issues over time.
Our code that handles issues like this (in cases where you're not using 
APICs, just PICs and PIRs) lives in bus/pci/i386/. Not that running 
without APIC support is all that common on modern machines anymore...
--
        Thomas E. Spanjaard
        tgen at netphreax.net
Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00003.pgp
Type: application/octet-stream
Size: 186 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080307/61366b5c/attachment-0010.obj>

From tgen at netphreax.net  Fri Mar  7 05:16:51 2008
From: tgen at netphreax.net (Thomas E. Spanjaard)
Date: Fri, 7 Mar 2008 05:16:51 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Misc. ACPI / suspend
In-Reply-To: <47CA073B.6020106@199technologies.org>
Message-ID: <47D13F07.9080308@netphreax.net>

Chris Turner wrote:
1) does anyone have ACPI (instead of APM)
   sleep / suspend / wakeup working on Dfly ?
2) If so, what machines are being used ?
3) Same question for other BSDs - my understanding is NetBSD is most
   'advanced' w/r/t power managment - but I'm not 100% on this ...
would looove to have a sleeping / resuming / scaling laptop running some 
BSD flavor.. am willing to work towards that end, esp. w/r/t Dfly -
trying to chart a course to figguring this out.
I have ACPI S3 suspend working like a charm on my IBM ThinkPad R40 
(Pentium M "Banias" 1.3GHz, speedstepping works just fine), running 
NetBSD 3.99.21.
--
        Thomas E. Spanjaard
        tgen at netphreax.net
Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00004.pgp
Type: application/octet-stream
Size: 186 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080307/de3e5104/attachment-0010.obj>

From civilizd at gmail.com  Fri Mar  7 09:06:41 2008
From: civilizd at gmail.com (Vita "CiV" Cizek)
Date: Fri, 7 Mar 2008 09:06:41 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <98d564710803070853q1c73d795m6e6c5cc5049fa099@mail.gmail.com>

>  Any student volunteers?  We have mentors.
>
I am interested too, especially in some kernel-related work.




From justin at shiningsilence.com  Sat Mar  8 12:07:51 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Sat, 8 Mar 2008 12:07:51 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google SoC 2008 - mentors mentors mentors
Message-ID: <51558.192.168.0.252.1205006403.squirrel@www.shiningsilence.com>

If you are willing to mentor for the Google 2008 Summer of Code, please
speak up.  Right now we have: (from our wiki page)

Matthias
Sephe
TGEN
corecode

Part of the application process includes naming people as mentors (student
applications come later), so I want to get as complete a list as possible.

The application is due on the 12th, so if you want to mentor, now's the
time to say so.

Google's SoC FAQ is here: http://code.google.com/soc/2008/faqs.html

Our wiki page is here: http://wiki.dragonflybsd.org/index.cgi/GoogleSoC2008

- much credit to Matthias and others for getting that set up.





From saw at online.de  Sat Mar  8 14:26:07 2008
From: saw at online.de (Sascha Wildner)
Date: Sat, 08 Mar 2008 23:26:07 +0100
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <47d31245$0$848$415eb37d@crater_reader.dragonflybsd.org>

Sascha Wildner wrote:
Hi all,

this is probably as good a moment as any to come out of the forest with 
this. The patch at

http://leaf.dragonflybsd.org/~swildner/nrelease_gui.diff
Ok, I have committed the stuff as an example.

I'm not sure if my free time permits to work on a full-blown live CD 
with X11 and other good things (I already feel my interest wandering off 
in other directions) so if anyone wants to pick up the ball, go ahead. :)

Sascha

--
http://yoyodyne.ath.cx



From qhwt+dfly at les.ath.cx  Tue Mar 11 22:21:31 2008
From: qhwt+dfly at les.ath.cx (YONETANI Tomokazu)
Date: Tue, 11 Mar 2008 22:21:31 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Misc. ACPI / suspend
In-Reply-To: <47CA073B.6020106@199technologies.org>
Message-ID: <20080312051219.GA56091@les.ath.cx>

On Thu, Mar 06, 2008 at 10:03:21PM -0500, Chris Turner wrote:
> 1) does anyone have ACPI (instead of APM)
>    sleep / suspend / wakeup working on Dfly ?
> 2) If so, what machines are being used ?

Dynabook SS3500 (http://www.tlt.co.jp/pc/catalog/ss/02110735/index_j.htm).
It's old and can get very hot(thus frequently turns on the cooling fan)
even when it's running Windows.  I haven't turned it on for about several
months though.

Cheers.




From c.turner at 199technologies.org  Wed Mar 12 04:37:22 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Wed, 12 Mar 2008 04:37:22 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Misc. ACPI / suspend
In-Reply-To: <47CA073B.6020106@199technologies.org>
Message-ID: <47D7BEE3.6010907@199technologies.org>

YONETANI Tomokazu wrote:
On Thu, Mar 06, 2008 at 10:03:21PM -0500, Chris Turner wrote:
1) does anyone have ACPI (instead of APM)
   sleep / suspend / wakeup working on Dfly ?
Cheers.
ditto..

Suppose this should go to docs@ - in any case..

Thinking about setting up a wiki page on the issue so we
can discuss / track what 'good' hardware / drivers / implementations / 
etc are 'out there' - anyone have any suggestions on where this should
go?

http://wiki.dragonflybsd.org/index.cgi/acpi-overview.html

Remains from the handbook conversion - but I'm hesitant to 'over wikify'
this ..



From c.turner at 199technologies.org  Wed Mar 12 15:36:52 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Wed, 12 Mar 2008 15:36:52 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: devel/cscope
Message-ID: <47D85A08.8040103@199technologies.org>

why oh why did I take so long to try this out !!!

just sharing my eureka moment with the list..

- Chris




From dudu at dudu.ro  Wed Mar 12 15:50:14 2008
From: dudu at dudu.ro (Vlad GALU)
Date: Wed, 12 Mar 2008 15:50:14 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: devel/cscope
In-Reply-To: <47D85A08.8040103@199technologies.org>
Message-ID: <ad79ad6b0803121547r2bf67ffep9e40badaac6490f8@mail.gmail.com>

On 3/13/08, Chris Turner <c.turner at 199technologies.org> wrote:
> why oh why did I take so long to try this out !!!
>
>  just sharing my eureka moment with the list..


    Works nice with vim, too!

>
>
>  - Chris
>


-- 
Mahnahmahnah!




From justin at shiningsilence.com  Sun Mar 16 21:06:13 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Sun, 16 Mar 2008 21:06:13 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: binary packages for 1.12 coming in
Message-ID: <1372.192.168.0.252.1205726088.squirrel@www.shiningsilence.com>

The binary build for 1.12 is taking quite a while.  I've started copying
in newly built packages to
pkgbox.dragonflybsd.org/packages/DragonFly-1.12/i386/ - this should be
getting copied out to mirrors over the next while.

There are currently 1283 packages built, which leaves a whole lot to go;
I'll copy new packages in as they complete.





From hasso at estpak.ee  Wed Mar 19 04:31:08 2008
From: hasso at estpak.ee (Hasso Tepper)
Date: Wed, 19 Mar 2008 04:31:08 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Some questions regarding ACPI
Message-ID: <200803191322.46366.hasso@estpak.ee>

I'm working on bringing in some laptop (and especially thinkpad) specific 
ACPI code from FreeBSD into DragonFly. I never touched ACPI stuff before 
and haven't followed it much either, so I have some questions.

* FreeBSD uses ACPI_SERIAL_* heavily. What's the locking situation in 
  DragonFly and why?

* As far as I can see, PCI integration is commented out in DragonFly. 
  What's the state of it and why?

* platform/pc32/acpica5/acpi_toshiba.c - why is it there? I don't think 
  that this is something pc32 specific in it and it should work in pc64 
  laptops as well. Any objections to move it into 
  dev/acpica5/acpi_toshiba/ ?

What's the current status of ACPI in general? AFAICS our acpica is quite 
old - what needs to be done to bring in newer one?


-- 
Hasso




From qhwt+dfly at les.ath.cx  Wed Mar 19 09:24:50 2008
From: qhwt+dfly at les.ath.cx (YONETANI Tomokazu)
Date: Wed, 19 Mar 2008 09:24:50 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Some questions regarding ACPI
In-Reply-To: <200803191322.46366.hasso@estpak.ee>
Message-ID: <20080319161703.GA51509@les.ath.cx>

On Wed, Mar 19, 2008 at 01:22:46PM +0200, Hasso Tepper wrote:
> I'm working on bringing in some laptop (and especially thinkpad) specific 
> ACPI code from FreeBSD into DragonFly. I never touched ACPI stuff before 
> and haven't followed it much either, so I have some questions.

So you want to port some of ACPI support drivers, or to do a fresh port
of ACPI driver from FreeBSD?

> * FreeBSD uses ACPI_SERIAL_* heavily. What's the locking situation in 
>   DragonFly and why?

The current ACPI driver in DragonFly is based on that of FreeBSD as of
end of June, 2004, plus some fixes brought in later (and ACPICA part
has been updated twice since then).  That was before they introduced
the MPSAFE changes into ACPI code, and we use critical section
(crit_{enter,exit}) in most places (and lockmgr lock in a few place).

> * As far as I can see, PCI integration is commented out in DragonFly. 
>   What's the state of it and why?

When we replaced the implementation taken from FreeBSD 4.x with that
brought from FreeBSD 5.x, which added the PCI part, many people
experienced problems until they turned off ACPI completely, or add "pci"
to "debug.acpi.disabled" loader variable.  AFAIK the PCI part in the ACPI
driver almost hasn't been adjusted to work with our version of PCI code.

> * platform/pc32/acpica5/acpi_toshiba.c - why is it there? I don't think 
>   that this is something pc32 specific in it and it should work in pc64 
>   laptops as well. Any objections to move it into 
>   dev/acpica5/acpi_toshiba/ ?

In FreeBSD it used to be sitting at i386/acpica/acpi_toshiba.c and was
later moved into acpi_support.  That change hasn't hit our tree (in fact,
we have no acpi support drivers other than that).  It seems that FreeBSD
has them in dev/acpi_support now, and we for some reason have that
directory in our CVS repository (but containing no files in it).

> What's the current status of ACPI in general? AFAICS our acpica is quite 
> old - what needs to be done to bring in newer one?

Actually, it's not very important to keep just ACPICA latest, but
if you bring the ACPI driver from FreeBSD you need to bring ACPICA code
that matches their version, and it IS important.  And it generally requires
you much work to just update ACPICA part anyway because of how they
change things on every release.

Cheers.




From hasso at estpak.ee  Wed Mar 19 12:29:52 2008
From: hasso at estpak.ee (Hasso Tepper)
Date: Wed, 19 Mar 2008 12:29:52 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Some questions regarding ACPI
In-Reply-To: <200803191322.46366.hasso@estpak.ee>
Message-ID: <200803192115.35396.hasso@estpak.ee>

YONETANI Tomokazu wrote:
> On Wed, Mar 19, 2008 at 01:22:46PM +0200, Hasso Tepper wrote:
> > I'm working on bringing in some laptop (and especially thinkpad)
> > specific ACPI code from FreeBSD into DragonFly. I never touched ACPI
> > stuff before and haven't followed it much either, so I have some
> > questions.
>
> So you want to port some of ACPI support drivers, or to do a fresh port
> of ACPI driver from FreeBSD?

I'm only interested in support drivers and the reason is pure practical - 
newer thinkpads handle less and less hotkeys etc in hardware and require 
support form OS. acpi_ibm and acpi_video are examples of such modules 
which would help a lot of these newer thinkpad users.

acpi_ibm is almost ready to commit (renamed to acpi_thinkpad though).

> > * FreeBSD uses ACPI_SERIAL_* heavily. What's the locking situation in
> >   DragonFly and why?
>
> The current ACPI driver in DragonFly is based on that of FreeBSD as of
> end of June, 2004, plus some fixes brought in later (and ACPICA part
> has been updated twice since then).  That was before they introduced
> the MPSAFE changes into ACPI code, and we use critical section
> (crit_{enter,exit}) in most places (and lockmgr lock in a few place).

Mkay. Will look at more closely.

> > * As far as I can see, PCI integration is commented out in DragonFly.
> >   What's the state of it and why?
>
> When we replaced the implementation taken from FreeBSD 4.x with that
> brought from FreeBSD 5.x, which added the PCI part, many people
> experienced problems until they turned off ACPI completely, or add
> "pci" to "debug.acpi.disabled" loader variable.  AFAIK the PCI part in
> the ACPI driver almost hasn't been adjusted to work with our version of
> PCI code.

I'm afraid that it's beyond my skills, but while looking at acpi_video I 
discovered that it's hard to handle correctly without PCI support.

> > * platform/pc32/acpica5/acpi_toshiba.c - why is it there? I don't
> > think that this is something pc32 specific in it and it should work
> > in pc64 laptops as well. Any objections to move it into
> >   dev/acpica5/acpi_toshiba/ ?
>
> In FreeBSD it used to be sitting at i386/acpica/acpi_toshiba.c and was
> later moved into acpi_support.  That change hasn't hit our tree (in
> fact, we have no acpi support drivers other than that).  It seems that
> FreeBSD has them in dev/acpi_support now, and we for some reason have
> that directory in our CVS repository (but containing no files in it).

I don't see it ;). Makes sense though. So, any objections if I move 
acpi_toshiba into sys/dev/acpi_support and add new acpi_thinkpad there as 
well? 

> > What's the current status of ACPI in general? AFAICS our acpica is
> > quite old - what needs to be done to bring in newer one?
>
> Actually, it's not very important to keep just ACPICA latest, but
> if you bring the ACPI driver from FreeBSD you need to bring ACPICA code
> that matches their version, and it IS important.  And it generally
> requires you much work to just update ACPICA part anyway because of how
> they change things on every release.

Someone else has to do it :).

Thanks for info.


-- 
Hasso




From dillon at apollo.backplane.com  Wed Mar 19 14:01:13 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Wed, 19 Mar 2008 14:01:13 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: panic: assertion: hammer_btree_cmp(cursor->left_bound,	&cursor->node->ondisk->elms[0].leaf.base) <= 0 in btree_split_leaf
In-Reply-To: <200802232204.m1NM4cxd046264@apollo.backplane.com>
Message-ID: <200803192054.m2JKsjwn045137@apollo.backplane.com>


:Hi.
:While trying to find a procedure to reliably reproduce the panic
:I reported last time, I caught a different panic (uploaded at
: ~y0netan1/crash/9/ on my leaf account).  I wrote the following shell
:script (make sure to edit variables DISKS and MOUNTPT before using this
:script or it may trash your system):
:  #!/bin/sh -ex
:  DISKS="/dev/ad0s1f"
:  MOUNTPT=/mnt/HAMMER
:
:  cd /
:  newfs_hammer -L TEST $DISKS
:  for i in `seq 1 100`; do
:..
:And the panic is triggered by rm command.
:I'll try to see if it's possible to reproduce the last one without
:unmounting then mounting the HAMMER fs.
:
:Cheers.

    I believe I have fixed this panic.  hammer_make_separator() had a bug
    in it.

    There is still an issue with the node ref count on umount.

    Please continue to life-test the code.  The reblocking code
    (hammer reblock /mnt) should work now, as should the pruning code
    (e.g. hammer prune /mnt everything).

    The filesystem full case is still not handled and will cause bad things
    to happen.  The undo code isn't finished yet either but it is getting
    there (it's writing stuff out but not setting the sequence number and
    not trying to recover-on-mount yet).

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From qhwt+dfly at les.ath.cx  Wed Mar 19 19:45:40 2008
From: qhwt+dfly at les.ath.cx (YONETANI Tomokazu)
Date: Wed, 19 Mar 2008 19:45:40 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Some questions regarding ACPI
In-Reply-To: <200803191322.46366.hasso@estpak.ee>
Message-ID: <20080320023828.GA53648@les.ath.cx>

On Wed, Mar 19, 2008 at 09:15:35PM +0200, Hasso Tepper wrote:
> YONETANI Tomokazu wrote:
> > On Wed, Mar 19, 2008 at 01:22:46PM +0200, Hasso Tepper wrote:
> > > I'm working on bringing in some laptop (and especially thinkpad)
> > > specific ACPI code from FreeBSD into DragonFly. I never touched ACPI
> > > stuff before and haven't followed it much either, so I have some
> > > questions.
> >
> > So you want to port some of ACPI support drivers, or to do a fresh port
> > of ACPI driver from FreeBSD?
> 
> I'm only interested in support drivers and the reason is pure practical - 
> newer thinkpads handle less and less hotkeys etc in hardware and require 
> support form OS. acpi_ibm and acpi_video are examples of such modules 
> which would help a lot of these newer thinkpad users.
> 
> acpi_ibm is almost ready to commit (renamed to acpi_thinkpad though).

Ah, that's a good news!  My only concern is that ISTR someone mentioned
me that his colleague was thinking about porting ACPI driver itself,
so if you're not the person you may want to collaborate with him/her
so as not to waste the effort or time...

			:

> > In FreeBSD it used to be sitting at i386/acpica/acpi_toshiba.c and was
> > later moved into acpi_support.  That change hasn't hit our tree (in
> > fact, we have no acpi support drivers other than that).  It seems that
> > FreeBSD has them in dev/acpi_support now, and we for some reason have
> > that directory in our CVS repository (but containing no files in it).
> 
> I don't see it ;). Makes sense though. So, any objections if I move 
> acpi_toshiba into sys/dev/acpi_support and add new acpi_thinkpad there as 
> well? 

Sorry, I checked the CVS repository and it doesn't exist actually :)
I don't have any objection to moving it there.

Cheers.




From hasso at estpak.ee  Thu Mar 20 00:14:05 2008
From: hasso at estpak.ee (Hasso Tepper)
Date: Thu, 20 Mar 2008 00:14:05 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Some questions regarding ACPI
In-Reply-To: <200803191322.46366.hasso@estpak.ee>
Message-ID: <200803200904.50875.hasso@estpak.ee>

YONETANI Tomokazu wrote:
> On Wed, Mar 19, 2008 at 09:15:35PM +0200, Hasso Tepper wrote:
> > acpi_ibm is almost ready to commit (renamed to acpi_thinkpad though).
>
> Ah, that's a good news!  My only concern is that ISTR someone mentioned
> me that his colleague was thinking about porting ACPI driver itself,
> so if you're not the person you may want to collaborate with him/her
> so as not to waste the effort or time...

Current state in my repo is attached. It should work on 1.12 as well as it 
doesn't depend yet on moving stuff around.

add-acpi-if-m.patch adds some new stuff to the ACPI code to access 
embedded controllers and match ACPI devices by ID. Not sure how, where 
and whether at all these should be documented.

add-acpi-thinkpad.patch is the driver itself. Note that some stuff doesn't 
work yet on newer thinkpads, I plan to work on it later.

There is still some things to do though. I have to decide what to do with 
led(4) part and with locking. There is also one fatal issue - laptop 
locks up hardly (no panic) while unloading module. Any idea regarding 
this is welcome. And of course test results :).


-- 
Hasso
# HG changeset patch
# User Hasso Tepper <hasso at estpak.ee>
# Date 1205919290 -7200
# Branch HEAD
# Node ID 5a6e2705cc95a340abf973ae5df73ef34e070b79
# Parent  cd529e2e7f849034d5d5a0973cb98af50db0e797
imported patch adding-acpi-if-m.patch

diff --git a/sys/conf/files b/sys/conf/files
--- a/sys/conf/files
+++ b/sys/conf/files
@@ -1387,6 +1387,7 @@ emulation/dragonfly12/dfbsd12_stat.c	non
 ${OSACPI_MI_DIR}/acpi_cmbat.c		optional acpi
 ${OSACPI_MI_DIR}/acpi_cpu.c		optional acpi
 ${OSACPI_MI_DIR}/acpi_ec.c		optional acpi
+${OSACPI_MI_DIR}/acpi_if.m		optional acpi
 ${OSACPI_MI_DIR}/acpi_isab.c		optional acpi isa
 ${OSACPI_MI_DIR}/acpi_lid.c		optional acpi
 ${OSACPI_MI_DIR}/acpi_package.c		optional acpi
diff --git a/sys/conf/kmod.mk b/sys/conf/kmod.mk
--- a/sys/conf/kmod.mk
+++ b/sys/conf/kmod.mk
@@ -275,7 +275,7 @@ MFILES?= kern/bus_if.m kern/device_if.m 
     bus/pccard/card_if.m bus/pccard/power_if.m bus/pci/pci_if.m \
     bus/pci/pcib_if.m \
     bus/ppbus/ppbus_if.m bus/smbus/smbus_if.m bus/usb/usb_if.m \
-    dev/disk/nata/ata_if.m \
+    dev/acpica5/acpi_if.m dev/disk/nata/ata_if.m \
     dev/sound/pcm/ac97_if.m dev/sound/pcm/channel_if.m \
     dev/sound/pcm/feeder_if.m dev/sound/pcm/mixer_if.m \
     libiconv/iconv_converter_if.m dev/agp/agp_if.m opencrypto/crypto_if.m
diff --git a/sys/dev/acpica5/Makefile b/sys/dev/acpica5/Makefile
--- a/sys/dev/acpica5/Makefile
+++ b/sys/dev/acpica5/Makefile
@@ -69,12 +69,14 @@ SRCS+=  acpi_package.c
 # SRCS+=	acpi_pci.c acpi_pcib.c acpi_pcib_acpi.c acpi_pcib_pci.c
 # SRCS+=	acpi_pci_link.c
 SRCS+=  acpi_powerres.c acpi_resource.c acpi_thermal.c
-SRCS+=  acpi_timer.c
+SRCS+=  acpi_timer.c acpi_if.c
 SRCS+=  OsdDebug.c
 SRCS+=  OsdHardware.c OsdInterface.c OsdInterrupt.c OsdMemory.c OsdSchedule.c
 SRCS+=  OsdStream.c OsdSynch.c OsdTable.c OsdEnvironment.c
 SRCS+=  opt_acpi.h opt_bus.h opt_ddb.h
-SRCS+=  device_if.h bus_if.h pci_if.h pcib_if.h isa_if.h
+SRCS+=  device_if.h bus_if.h pci_if.h pcib_if.h isa_if.h acpi_if.h
+MFILES = kern/device_if.m kern/bus_if.m bus/pci/pci_if.m bus/pci/pcib_if.m
+MFILES+= bus/isa/isa_if.m dev/acpica5/acpi_if.m
 
 # Debugging support
 DBSRC=	dbcmds.c dbdisply.c dbexec.c dbfileio.c dbhistry.c
diff --git a/sys/dev/acpica5/acpi.c b/sys/dev/acpica5/acpi.c
--- a/sys/dev/acpica5/acpi.c
+++ b/sys/dev/acpica5/acpi.c
@@ -135,6 +135,7 @@ static int	acpi_release_resource(device_
 			int rid, struct resource *r);
 static uint32_t	acpi_isa_get_logicalid(device_t dev);
 static int	acpi_isa_get_compatid(device_t dev, uint32_t *cids, int count);
+static char	*acpi_device_id_probe(device_t bus, device_t dev, char **ids);
 static int	acpi_isa_pnp_probe(device_t bus, device_t child,
 			struct isa_pnp_id *ids);
 static void	acpi_probe_children(device_t bus);
@@ -189,6 +190,9 @@ static device_method_t acpi_methods[] = 
     DEVMETHOD(bus_deactivate_resource,	bus_generic_deactivate_resource),
     DEVMETHOD(bus_setup_intr,		bus_generic_setup_intr),
     DEVMETHOD(bus_teardown_intr,	bus_generic_teardown_intr),
+
+    /* ACPI bus */
+    DEVMETHOD(acpi_id_probe,		acpi_device_id_probe),
 
     /* ISA emulation */
     DEVMETHOD(isa_pnp_probe,		acpi_isa_pnp_probe),
@@ -1121,6 +1125,24 @@ out:
 	AcpiOsFree(buf.Pointer);
     ACPI_UNLOCK;
     return_VALUE (valid);
+}
+
+static char *
+acpi_device_id_probe(device_t bus, device_t dev, char **ids) 
+{
+    ACPI_HANDLE h;
+    int i;
+
+    h = acpi_get_handle(dev);
+    if (ids == NULL || h == NULL || acpi_get_type(dev) != ACPI_TYPE_DEVICE)
+	return (NULL);
+
+    /* Try to match one of the array of IDs with a HID or CID. */
+    for (i = 0; ids[i] != NULL; i++) {
+	if (acpi_MatchHid(h, ids[i]))
+	    return (ids[i]);
+    }
+    return (NULL);
 }
 
 static int
diff --git a/sys/dev/acpica5/acpi_ec.c b/sys/dev/acpica5/acpi_ec.c
--- a/sys/dev/acpica5/acpi_ec.c
+++ b/sys/dev/acpica5/acpi_ec.c
@@ -327,11 +327,19 @@ static ACPI_STATUS	EcWrite(struct acpi_e
 				UINT8 *Data);
 static int		acpi_ec_probe(device_t dev);
 static int		acpi_ec_attach(device_t dev);
+static int		acpi_ec_read_method(device_t dev, u_int addr,
+				ACPI_INTEGER *val, int width);
+static int		acpi_ec_write_method(device_t dev, u_int addr,
+				ACPI_INTEGER val, int width);
 
 static device_method_t acpi_ec_methods[] = {
     /* Device interface */
     DEVMETHOD(device_probe,	acpi_ec_probe),
     DEVMETHOD(device_attach,	acpi_ec_attach),
+
+    /* Embedded controller interface */
+    DEVMETHOD(acpi_ec_read,     acpi_ec_read_method),
+    DEVMETHOD(acpi_ec_write,    acpi_ec_write_method),
 
     {0, 0}
 };
@@ -620,6 +628,33 @@ error:
 			     sc->ec_data_res);
     /* mtx_destroy(&sc->ec_mtx); */
     return (ENXIO);
+}
+
+/* Methods to allow other devices (e.g., smbat) to read/write EC space. */
+static int
+acpi_ec_read_method(device_t dev, u_int addr, ACPI_INTEGER *val, int width)
+{
+    struct acpi_ec_softc *sc;
+    ACPI_STATUS status;
+
+    sc = device_get_softc(dev);
+    status = EcSpaceHandler(ACPI_READ, addr, width * 8, val, sc, NULL);
+    if (ACPI_FAILURE(status))
+        return (ENXIO);
+    return (0);
+}
+
+static int
+acpi_ec_write_method(device_t dev, u_int addr, ACPI_INTEGER val, int width)
+{
+    struct acpi_ec_softc *sc;
+    ACPI_STATUS status;
+
+    sc = device_get_softc(dev);
+    status = EcSpaceHandler(ACPI_WRITE, addr, width * 8, &val, sc, NULL);
+    if (ACPI_FAILURE(status))
+        return (ENXIO);
+    return (0);
 }
 
 static void
diff --git a/sys/dev/acpica5/acpi_if.m b/sys/dev/acpica5/acpi_if.m
new file mode 100644
--- /dev/null
+++ b/sys/dev/acpica5/acpi_if.m
@@ -0,0 +1,92 @@
+#-
+# Copyright (c) 2004 Nate Lawson
+# All rights reserved.
+#
+# Redistribution and use in source and binary forms, with or without
+# modification, are permitted provided that the following conditions
+# are met:
+# 1. Redistributions of source code must retain the above copyright
+#    notice, this list of conditions and the following disclaimer.
+# 2. Redistributions in binary form must reproduce the above copyright
+#    notice, this list of conditions and the following disclaimer in the
+#    documentation and/or other materials provided with the distribution.
+#
+# THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
+# ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+# ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
+# FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+# DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+# OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+# HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+# LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+# OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+# SUCH DAMAGE.
+#
+# $DragonFly$
+#
+
+#include <sys/bus.h>
+#include <sys/types.h>
+#include "acpi.h"
+
+INTERFACE acpi;
+
+#
+# Default implementation for acpi_id_probe().
+#
+CODE {
+	static char *
+	acpi_generic_id_probe(device_t bus, device_t dev, char **ids)
+	{
+		return (NULL);
+	}
+};
+
+#
+# Check a device for a match in a list of ID strings.  The strings can be
+# EISA PNP IDs or ACPI _HID/_CID values.
+#
+# device_t bus:  parent bus for the device
+#
+# device_t dev:  device being considered
+#
+# char **ids:  array of ID strings to consider
+#
+# Returns:  ID string matched or NULL if no match
+#
+METHOD char * id_probe {
+	device_t	bus;
+	device_t	dev;
+	char		**ids;
+} DEFAULT acpi_generic_id_probe;
+
+#
+# Read embedded controller (EC) address space
+#
+# device_t dev:  EC device
+# u_int addr:  Address to read from in EC space
+# ACPI_INTEGER *val:  Location to store read value
+# int width:  Size of area to read in bytes
+#
+METHOD int ec_read {
+	device_t	dev;
+	u_int		addr;
+	ACPI_INTEGER	*val;
+	int		width;
+};
+
+#
+# Write embedded controller (EC) address space
+#
+# device_t dev:  EC device
+# u_int addr:  Address to write to in EC space
+# ACPI_INTEGER val:  Value to write
+# int width:  Size of value to write in bytes
+#
+METHOD int ec_write {
+	device_t	dev;
+	u_int		addr;
+	ACPI_INTEGER	val;
+	int		width;
+};
diff --git a/sys/dev/acpica5/acpivar.h b/sys/dev/acpica5/acpivar.h
--- a/sys/dev/acpica5/acpivar.h
+++ b/sys/dev/acpica5/acpivar.h
@@ -29,6 +29,7 @@
  * $DragonFly: src/sys/dev/acpica5/acpivar.h,v 1.12 2007/10/23 03:04:48 y0netan1 Exp $
  */
 
+#include "acpi_if.h"
 #include "bus_if.h"
 #include <sys/eventhandler.h>
 #include <sys/sysctl.h>
# HG changeset patch
# User Hasso Tepper <hasso at estpak.ee>
# Date 1205995474 -7200
# Branch HEAD
# Node ID c5db8d4a7c6b25a8576a8d42c5029aaf0e23bfb6
# Parent  5a6e2705cc95a340abf973ae5df73ef34e070b79
[mq]: adding-acpi-thinkpad.patch

diff --git a/sys/dev/acpica5/Makefile b/sys/dev/acpica5/Makefile
--- a/sys/dev/acpica5/Makefile
+++ b/sys/dev/acpica5/Makefile
@@ -117,7 +117,7 @@ acpi_wakecode.h: acpi_wakecode.S
 	${MAKE} -f ${SYSDIR}/${OSACPI_MD_DIR}/Makefile \
 		MAKESRCPATH=${SYSDIR}/${OSACPI_MD_DIR}
 
-SUBDIR=	acpi_toshiba
+SUBDIR=	acpi_toshiba acpi_thinkpad
 all: ${PROG} ${SUBDIR}
 
 # *.o file for each patched *.c file is created under the same directory,
diff --git a/sys/dev/acpica5/acpi_thinkpad/Makefile b/sys/dev/acpica5/acpi_thinkpad/Makefile
new file mode 100644
--- /dev/null
+++ b/sys/dev/acpica5/acpi_thinkpad/Makefile
@@ -0,0 +1,9 @@
+# $DragonFly$
+
+SYSDIR?=${.CURDIR}/../../..
+
+KMOD=		acpi_thinkpad
+CFLAGS+=	-I${.OBJDIR}/.. -I${.CURDIR}/..
+SRCS=		acpi_thinkpad.c opt_acpi.h device_if.h bus_if.h
+
+.include <bsd.kmod.mk>
diff --git a/sys/dev/acpica5/acpi_thinkpad/acpi_thinkpad.c b/sys/dev/acpica5/acpi_thinkpad/acpi_thinkpad.c
new file mode 100644
--- /dev/null
+++ b/sys/dev/acpica5/acpi_thinkpad/acpi_thinkpad.c
@@ -0,0 +1,1046 @@
+/*
+ * Copyright (c) 2004 Takanori Watanabe
+ * Copyright (c) 2005 Markus Brueffer <markus at FreeBSD.org>
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *    notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *    notice, this list of conditions and the following disclaimer in the
+ *    documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+ */
+
+/*
+ * Driver for extra ACPI-controlled gadgets found on IBM and Lenovo ThinkPad
+ * laptops. Inspired by the ibm-acpi and tpb projects which implement these
+ * features on Linux.
+ *
+ *   acpi-ibm: <http://ibm-acpi.sourceforge.net/>
+ *        tpb: <http://www.nongnu.org/tpb/>
+ */
+
+#include "opt_acpi.h"
+#include <sys/param.h>
+#include <sys/kernel.h>
+#include <sys/bus.h>
+#include <machine/cpufunc.h>
+#include <sys/module.h>
+/* #include <dev/led/led.h> */
+#include <sys/sensors.h>
+#include <sys/sysctl.h>
+#include <machine/clock.h>
+
+#include "acpi.h"
+#include "acpivar.h"
+#include "acpi_if.h"
+
+#define _COMPONENT	ACPI_OEM
+ACPI_MODULE_NAME("THINKPAD")
+
+/* Internal methods */
+#define ACPI_THINKPAD_METHOD_EVENTS		1
+#define ACPI_THINKPAD_METHOD_EVENTMASK		2
+#define ACPI_THINKPAD_METHOD_HOTKEY		3
+#define ACPI_THINKPAD_METHOD_BRIGHTNESS		4
+#define ACPI_THINKPAD_METHOD_VOLUME		5
+#define ACPI_THINKPAD_METHOD_MUTE		6
+#define ACPI_THINKPAD_METHOD_THINKLIGHT		7
+#define ACPI_THINKPAD_METHOD_BLUETOOTH		8
+#define ACPI_THINKPAD_METHOD_WLAN		9
+#define ACPI_THINKPAD_METHOD_FANSPEED		10
+#define ACPI_THINKPAD_METHOD_FANLEVEL		11
+#define ACPI_THINKPAD_METHOD_FANSTATUS		12
+#define ACPI_THINKPAD_METHOD_THERMAL		13
+
+/* Hotkeys/Buttons */
+#define THINKPAD_RTC_HOTKEY1			0x64
+#define   THINKPAD_RTC_MASK_HOME		(1 << 0)
+#define   THINKPAD_RTC_MASK_SEARCH		(1 << 1)
+#define   THINKPAD_RTC_MASK_MAIL		(1 << 2)
+#define   THINKPAD_RTC_MASK_WLAN		(1 << 5)
+#define THINKPAD_RTC_HOTKEY2			0x65
+#define   THINKPAD_RTC_MASK_THINKPAD		(1 << 3)
+#define   THINKPAD_RTC_MASK_ZOOM		(1 << 5)
+#define   THINKPAD_RTC_MASK_VIDEO		(1 << 6)
+#define   THINKPAD_RTC_MASK_HIBERNATE		(1 << 7)
+#define THINKPAD_RTC_THINKLIGHT			0x66
+#define   THINKPAD_RTC_MASK_THINKLIGHT		(1 << 4)
+#define THINKPAD_RTC_SCREENEXPAND		0x67
+#define   THINKPAD_RTC_MASK_SCREENEXPAND	(1 << 5)
+#define THINKPAD_RTC_BRIGHTNESS			0x6c
+#define   THINKPAD_RTC_MASK_BRIGHTNESS		(1 << 5)
+#define THINKPAD_RTC_VOLUME			0x6e
+#define   THINKPAD_RTC_MASK_VOLUME		(1 << 7)
+
+/* Embedded Controller registers */
+#define THINKPAD_EC_BRIGHTNESS			0x31
+#define   THINKPAD_EC_MASK_BRI			0x7
+#define THINKPAD_EC_VOLUME			0x30
+#define   THINKPAD_EC_MASK_VOL			0xf
+#define   THINKPAD_EC_MASK_MUTE			(1 << 6)
+#define THINKPAD_EC_FANSTATUS			0x2F
+#define   THINKPAD_EC_MASK_FANLEVEL		0x3f
+#define   THINKPAD_EC_MASK_FANDISENGAGED	(1 << 6)
+#define   THINKPAD_EC_MASK_FANSTATUS		(1 << 7)
+#define THINKPAD_EC_FANSPEED			0x84
+
+/* CMOS Commands */
+#define THINKPAD_CMOS_VOLUME_DOWN		0
+#define THINKPAD_CMOS_VOLUME_UP			1
+#define THINKPAD_CMOS_VOLUME_MUTE		2
+#define THINKPAD_CMOS_BRIGHTNESS_UP		4
+#define THINKPAD_CMOS_BRIGHTNESS_DOWN		5
+
+/* ACPI methods */
+#define THINKPAD_NAME_KEYLIGHT			"KBLT"
+#define THINKPAD_NAME_WLAN_BT_GET		"GBDC"
+#define THINKPAD_NAME_WLAN_BT_SET		"SBDC"
+#define   THINKPAD_NAME_MASK_BT			(1 << 1)
+#define   THINKPAD_NAME_MASK_WLAN		(1 << 2)
+#define THINKPAD_NAME_THERMAL_GET		"TMP7"
+#define THINKPAD_NAME_THERMAL_UPDT		"UPDT"
+
+#define THINKPAD_NAME_EVENTS_STATUS_GET		"DHKC"
+#define THINKPAD_NAME_EVENTS_MASK_GET		"DHKN"
+#define THINKPAD_NAME_EVENTS_STATUS_SET		"MHKC"
+#define THINKPAD_NAME_EVENTS_MASK_SET		"MHKM"
+#define THINKPAD_NAME_EVENTS_GET		"MHKP"
+#define THINKPAD_NAME_EVENTS_AVAILMASK		"MHKA"
+
+#define ABS(x) (((x) < 0)? -(x) : (x))
+
+struct acpi_thinkpad_softc {
+	device_t	dev;
+	ACPI_HANDLE	handle;
+
+	/* Embedded controller */
+	device_t	ec_dev;
+	ACPI_HANDLE	ec_handle;
+
+	/* CMOS */
+	ACPI_HANDLE	cmos_handle;
+
+	/* Fan status */
+	ACPI_HANDLE	fan_handle;
+	int		fan_levels;
+
+	/* Keylight commands and states */
+	ACPI_HANDLE	light_handle;
+	int		light_cmd_on;
+	int		light_cmd_off;
+	int		light_val;
+	int		light_get_supported;
+	int		light_set_supported;
+
+	/* led(4) interface */
+	struct cdev	*led_dev;
+	int		led_busy;
+	int		led_state;
+
+	int		wlan_bt_flags;
+	int		thermal_updt_supported;
+
+	unsigned int	events_availmask;
+	unsigned int	events_initialmask;
+	int		events_mask_supported;
+	int		events_enable;
+
+	/* sensors(9) related */
+	struct ksensordev sensordev;
+	struct ksensor sensors[9];	/* XXX: 8 thermal + fan */
+
+	struct sysctl_ctx_list	*sysctl_ctx;
+	struct sysctl_oid	*sysctl_tree;
+};
+
+static struct {
+	char	*name;
+	int	method;
+	char	*description;
+	int	access;
+} acpi_thinkpad_sysctls[] = {
+	{
+		.name		= "events",
+		.method		= ACPI_THINKPAD_METHOD_EVENTS,
+		.description	= "ACPI events enable",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "eventmask",
+		.method		= ACPI_THINKPAD_METHOD_EVENTMASK,
+		.description	= "ACPI eventmask",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "hotkey",
+		.method		= ACPI_THINKPAD_METHOD_HOTKEY,
+		.description	= "Key Status",
+		.access		= CTLTYPE_INT | CTLFLAG_RD
+	},
+	{
+		.name		= "lcd_brightness",
+		.method		= ACPI_THINKPAD_METHOD_BRIGHTNESS,
+		.description	= "LCD Brightness",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "volume",
+		.method		= ACPI_THINKPAD_METHOD_VOLUME,
+		.description	= "Volume",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "mute",
+		.method		= ACPI_THINKPAD_METHOD_MUTE,
+		.description	= "Mute",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "thinklight",
+		.method		= ACPI_THINKPAD_METHOD_THINKLIGHT,
+		.description	= "Thinklight enable",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "bluetooth",
+		.method		= ACPI_THINKPAD_METHOD_BLUETOOTH,
+		.description	= "Bluetooth enable",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "wlan",
+		.method		= ACPI_THINKPAD_METHOD_WLAN,
+		.description	= "WLAN enable",
+		.access		= CTLTYPE_INT | CTLFLAG_RD
+	},
+	{
+		.name		= "fan_level",
+		.method		= ACPI_THINKPAD_METHOD_FANLEVEL,
+		.description	= "Fan level",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "fan",
+		.method		= ACPI_THINKPAD_METHOD_FANSTATUS,
+		.description	= "Fan enable",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+
+	{ NULL, 0, NULL, 0 }
+};
+
+/* ACPI_SERIAL_DECL(thinkpad, "ACPI THINKPAD extras"); */
+static int	acpi_thinkpad_probe(device_t dev);
+static int	acpi_thinkpad_attach(device_t dev);
+static int	acpi_thinkpad_detach(device_t dev);
+
+#if 0 /* not yet */
+static void	thinkpad_led(void *softc, int onoff);
+static void	thinkpad_led_task(struct acpi_thinkpad_softc *sc,
+		int pending __unused);
+#endif
+
+static int	acpi_thinkpad_sysctl(SYSCTL_HANDLER_ARGS);
+static int	acpi_thinkpad_sysctl_init(struct acpi_thinkpad_softc *sc,
+		int method);
+static int	acpi_thinkpad_sysctl_get(struct acpi_thinkpad_softc *sc,
+		int method);
+static int	acpi_thinkpad_sysctl_set(struct acpi_thinkpad_softc *sc,
+		int method, int val);
+
+static int	acpi_thinkpad_eventmask_set(struct acpi_thinkpad_softc *sc,
+		int val);
+static void	acpi_thinkpad_notify(ACPI_HANDLE h, UINT32 notify,
+		void *context);
+static void	acpi_thinkpad_refresh(void *);
+
+static device_method_t acpi_thinkpad_methods[] = {
+	/* Device interface */
+	DEVMETHOD(device_probe, acpi_thinkpad_probe),
+	DEVMETHOD(device_attach, acpi_thinkpad_attach),
+	DEVMETHOD(device_detach, acpi_thinkpad_detach),
+	{0, 0}
+};
+
+static driver_t	acpi_thinkpad_driver = {
+	"acpi_thinkpad",
+	acpi_thinkpad_methods,
+	sizeof(struct acpi_thinkpad_softc),
+};
+
+static devclass_t acpi_thinkpad_devclass;
+
+DRIVER_MODULE(acpi_thinkpad, acpi, acpi_thinkpad_driver,
+    acpi_thinkpad_devclass, 0, 0);
+MODULE_DEPEND(acpi_thinkpad, acpi, 1, 1, 1);
+static char    *thinkpad_ids[] = {"IBM0068", NULL};
+
+#if 0 /* not yet */
+static void
+thinkpad_led(void *softc, int onoff)
+{
+	struct acpi_thinkpad_softc* sc = (struct acpi_thinkpad_softc*) softc;
+
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+
+	if (sc->led_busy)
+		return;
+
+	sc->led_busy = 1;
+	sc->led_state = onoff;
+
+	AcpiOsExecute(OSL_NOTIFY_HANDLER, (void *)thinkpad_led_task, sc);
+}
+
+static void
+thinkpad_led_task(struct acpi_thinkpad_softc *sc, int pending __unused)
+{
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+
+	/* ACPI_SERIAL_BEGIN(thinkpad); */
+	acpi_thinkpad_sysctl_set(sc, ACPI_THINKPAD_METHOD_THINKLIGHT, sc->led_state);
+	/* ACPI_SERIAL_END(thinkpad); */
+
+	sc->led_busy = 0;
+}
+#endif
+
+static int
+acpi_thinkpad_probe(device_t dev)
+{
+	if (acpi_disabled("thinkpad") ||
+	    ACPI_ID_PROBE(device_get_parent(dev), dev, thinkpad_ids) == NULL ||
+	    device_get_unit(dev) != 0) 
+		return (ENXIO);
+
+	device_set_desc(dev, "IBM/Lenovo ThinkPad ACPI Extras");
+	return (0);
+}
+
+static int
+acpi_thinkpad_attach(device_t dev)
+{
+	struct acpi_thinkpad_softc	*sc;
+	struct acpi_softc	*acpi_sc;
+	devclass_t		ec_devclass;
+	int			i;
+
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t) __func__);
+
+	sc = device_get_softc(dev);
+	sc->dev = dev;
+	sc->handle = acpi_get_handle(dev);
+
+	acpi_sc = acpi_device_get_parent_softc(dev);
+
+	/* Look for the first embedded controller */
+        if (!(ec_devclass = devclass_find ("acpi_ec"))) {
+		if (bootverbose)
+			device_printf(dev, "Couldn't find acpi_ec devclass\n");
+		return (EINVAL);
+	}
+        if (!(sc->ec_dev = devclass_get_device(ec_devclass, 0))) {
+		if (bootverbose)
+			device_printf(dev, "Couldn't find acpi_ec device\n");
+		return (EINVAL);
+	}
+	sc->ec_handle = acpi_get_handle(sc->ec_dev);
+
+	/* ACPI_SERIAL_BEGIN(thinkpad); */
+
+#if 0
+	/* Get the sysctl tree */
+	sc->sysctl_ctx = device_get_sysctl_ctx(dev);
+	sc->sysctl_tree = device_get_sysctl_tree(dev);
+#endif
+	sysctl_ctx_init(sc->sysctl_ctx);
+	sc->sysctl_tree = SYSCTL_ADD_NODE(sc->sysctl_ctx,
+	    SYSCTL_CHILDREN(acpi_sc->acpi_sysctl_tree), OID_AUTO,
+	    "thinkpad", CTLFLAG_RD, 0, "");
+
+	/* Look for event mask and hook up the nodes */
+	sc->events_mask_supported = ACPI_SUCCESS(acpi_GetInteger(sc->handle,
+	    THINKPAD_NAME_EVENTS_MASK_GET, &sc->events_initialmask));
+
+	if (sc->events_mask_supported) {
+		SYSCTL_ADD_INT(sc->sysctl_ctx,
+		    SYSCTL_CHILDREN(sc->sysctl_tree), OID_AUTO,
+		    "initialmask", CTLFLAG_RD,
+		    &sc->events_initialmask, 0, "Initial eventmask");
+
+		/* The availmask is the bitmask of supported events */
+		if (ACPI_FAILURE(acpi_GetInteger(sc->handle,
+		    THINKPAD_NAME_EVENTS_AVAILMASK, &sc->events_availmask)))
+			sc->events_availmask = 0xffffffff;
+
+		SYSCTL_ADD_INT(sc->sysctl_ctx,
+		    SYSCTL_CHILDREN(sc->sysctl_tree), OID_AUTO,
+		    "availmask", CTLFLAG_RD,
+		    &sc->events_availmask, 0, "Mask of supported events");
+	}
+
+	/* Hook up proc nodes */
+	for (i = 0; acpi_thinkpad_sysctls[i].name != NULL; i++) {
+		if (!acpi_thinkpad_sysctl_init(sc,
+		    acpi_thinkpad_sysctls[i].method))
+			continue;
+
+		SYSCTL_ADD_PROC(sc->sysctl_ctx,
+		    SYSCTL_CHILDREN(sc->sysctl_tree), OID_AUTO,
+		    acpi_thinkpad_sysctls[i].name,
+		    acpi_thinkpad_sysctls[i].access,
+		    sc, i, acpi_thinkpad_sysctl, "I",
+		    acpi_thinkpad_sysctls[i].description);
+	}
+
+	/* ACPI_SERIAL_END(thinkpad); */
+
+	/* Handle notifies */
+	AcpiInstallNotifyHandler(sc->handle, ACPI_DEVICE_NOTIFY,
+	    acpi_thinkpad_notify, dev);
+
+#if 0
+	/* Hook up light to led(4) */
+	if (sc->light_set_supported)
+		sc->led_dev = led_create_state(thinkpad_led, sc, "thinklight",
+		    sc->light_val);
+#endif
+	/* Attach sensors(9). */
+	if (sensor_task_register(sc, acpi_thinkpad_refresh, 5)) {
+		device_printf(sc->dev, "unable to register update task\n");
+		return 1;
+	}
+
+	strlcpy(sc->sensordev.xname, device_get_nameunit(sc->dev),
+	    sizeof(sc->sensordev.xname));
+
+	/* XXX: Temp sensors */
+	for (i = 0; i < 8; ++i) {
+		sc->sensors[i].type = SENSOR_TEMP;
+		sensor_attach(&sc->sensordev, &sc->sensors[i]);
+	}
+	
+	/* Fan RPM sensor */
+	sc->sensors[8].type = SENSOR_FANRPM;
+	sensor_attach(&sc->sensordev, &sc->sensors[8]);
+
+	sensordev_install(&sc->sensordev);
+
+	return (0);
+}
+
+static int
+acpi_thinkpad_detach(device_t dev)
+{
+	int i;
+
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t) __func__);
+
+	struct acpi_thinkpad_softc *sc = device_get_softc(dev);
+
+	/* Disable events and restore eventmask */
+	/* ACPI_SERIAL_BEGIN(thinkpad); */
+	acpi_thinkpad_sysctl_set(sc, ACPI_THINKPAD_METHOD_EVENTS, 0);
+	acpi_thinkpad_sysctl_set(sc, ACPI_THINKPAD_METHOD_EVENTMASK,
+	    sc->events_initialmask);
+	/* ACPI_SERIAL_END(thinkpad); */
+
+	AcpiRemoveNotifyHandler(sc->handle, ACPI_DEVICE_NOTIFY,
+	    acpi_thinkpad_notify);
+
+	sysctl_ctx_free(sc->sysctl_ctx);
+
+#if 0
+	if (sc->led_dev != NULL)
+		led_destroy(sc->led_dev);
+#endif
+	sensordev_deinstall(&sc->sensordev);
+	for (i = 0; i < 9; i++)
+		sensor_detach(&sc->sensordev, &sc->sensors[i]);
+	sensor_task_unregister(sc);
+
+	return (0);
+}
+
+static int
+acpi_thinkpad_eventmask_set(struct acpi_thinkpad_softc *sc, int val)
+{
+	int i;
+	ACPI_OBJECT		arg[2];
+	ACPI_OBJECT_LIST	args;
+	ACPI_STATUS		status;
+
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+	/* ACPI_SERIAL_ASSERT(thinkpad); */
+
+	args.Count = 2;
+	args.Pointer = arg;
+	arg[0].Type = ACPI_TYPE_INTEGER;
+	arg[1].Type = ACPI_TYPE_INTEGER;
+
+	for (i = 0; i < 32; ++i) {
+		arg[0].Integer.Value = i+1;
+		arg[1].Integer.Value = (((1 << i) & val) != 0);
+		status = AcpiEvaluateObject(sc->handle,
+		    THINKPAD_NAME_EVENTS_MASK_SET, &args, NULL);
+
+		if (ACPI_FAILURE(status))
+			return (status);
+	}
+
+	return (0);
+}
+
+static int
+acpi_thinkpad_sysctl(SYSCTL_HANDLER_ARGS)
+{
+	struct acpi_thinkpad_softc	*sc;
+	int			arg;
+	int			error = 0;
+	int			function;
+	int			method;
+	
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+
+	sc = (struct acpi_thinkpad_softc *)oidp->oid_arg1;
+	function = oidp->oid_arg2;
+	method = acpi_thinkpad_sysctls[function].method;
+
+	/* ACPI_SERIAL_BEGIN(thinkpad); */
+	arg = acpi_thinkpad_sysctl_get(sc, method);
+	error = sysctl_handle_int(oidp, &arg, 0, req);
+
+	/* Sanity check */
+	if (error != 0 || req->newptr == NULL)
+		goto out;
+
+	/* Update */
+	error = acpi_thinkpad_sysctl_set(sc, method, arg);
+
+out:
+	/* ACPI_SERIAL_END(thinkpad); */
+	return (error);
+}
+
+static int
+acpi_thinkpad_sysctl_get(struct acpi_thinkpad_softc *sc, int method)
+{
+	ACPI_INTEGER	val_ec;
+	int 		val = 0, key;
+
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+	/* ACPI_SERIAL_ASSERT(thinkpad); */
+
+	switch (method) {
+	case ACPI_THINKPAD_METHOD_EVENTS:
+		acpi_GetInteger(sc->handle, THINKPAD_NAME_EVENTS_STATUS_GET,
+		    &val);
+		break;
+
+	case ACPI_THINKPAD_METHOD_EVENTMASK:
+		if (sc->events_mask_supported)
+			acpi_GetInteger(sc->handle,
+			    THINKPAD_NAME_EVENTS_MASK_GET, &val);
+		break;
+
+	case ACPI_THINKPAD_METHOD_HOTKEY:
+		/*
+		 * Construct the hotkey as a bitmask as illustrated below.
+		 * Note that whenever a key was pressed, the respecting bit
+		 * toggles and nothing else changes.
+		 * +--+--+-+-+-+-+-+-+-+-+-+-+
+		 * |11|10|9|8|7|6|5|4|3|2|1|0|
+		 * +--+--+-+-+-+-+-+-+-+-+-+-+
+		 *   |  | | | | | | | | | | |
+		 *   |  | | | | | | | | | | +- Home Button
+		 *   |  | | | | | | | | | +--- Search Button
+		 *   |  | | | | | | | | +----- Mail Button
+		 *   |  | | | | | | | +------- Thinkpad Button
+		 *   |  | | | | | | +--------- Zoom (Fn + Space)
+		 *   |  | | | | | +----------- WLAN Button
+		 *   |  | | | | +------------- Video Button
+		 *   |  | | | +--------------- Hibernate Button
+		 *   |  | | +----------------- Thinklight Button
+		 *   |  | +------------------- Screen expand (Fn + F8)
+		 *   |  +--------------------- Brightness
+		 *   +------------------------ Volume/Mute
+		 */
+		key = rtcin(THINKPAD_RTC_HOTKEY1);
+		val = (THINKPAD_RTC_MASK_HOME | THINKPAD_RTC_MASK_SEARCH |
+		    THINKPAD_RTC_MASK_MAIL | THINKPAD_RTC_MASK_WLAN) & key;
+		key = rtcin(THINKPAD_RTC_HOTKEY2);
+		val |= (THINKPAD_RTC_MASK_THINKPAD | THINKPAD_RTC_MASK_VIDEO |
+		    THINKPAD_RTC_MASK_HIBERNATE) & key;
+		val |= (THINKPAD_RTC_MASK_ZOOM & key) >> 1;
+		key = rtcin(THINKPAD_RTC_THINKLIGHT);
+		val |= (THINKPAD_RTC_MASK_THINKLIGHT & key) << 4;
+		key = rtcin(THINKPAD_RTC_SCREENEXPAND);
+		val |= (THINKPAD_RTC_MASK_THINKLIGHT & key) << 4;
+		key = rtcin(THINKPAD_RTC_BRIGHTNESS);
+		val |= (THINKPAD_RTC_MASK_BRIGHTNESS & key) << 5;
+		key = rtcin(THINKPAD_RTC_VOLUME);
+		val |= (THINKPAD_RTC_MASK_VOLUME & key) << 4;
+		break;
+
+	case ACPI_THINKPAD_METHOD_BRIGHTNESS:
+		ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_BRIGHTNESS, &val_ec, 1);
+		val = val_ec & THINKPAD_EC_MASK_BRI;
+		break;
+
+	case ACPI_THINKPAD_METHOD_VOLUME:
+		ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_VOLUME, &val_ec, 1);
+		val = val_ec & THINKPAD_EC_MASK_VOL;
+		break;
+
+	case ACPI_THINKPAD_METHOD_MUTE:
+		val = ((val_ec & THINKPAD_EC_MASK_MUTE) ==
+		    THINKPAD_EC_MASK_MUTE);
+		break;
+
+	case ACPI_THINKPAD_METHOD_THINKLIGHT:
+		if (sc->light_get_supported)
+			acpi_GetInteger(sc->ec_handle, THINKPAD_NAME_KEYLIGHT,
+			    &val);
+		else
+			val = sc->light_val;
+		break;
+
+	case ACPI_THINKPAD_METHOD_BLUETOOTH:
+		acpi_GetInteger(sc->handle, THINKPAD_NAME_WLAN_BT_GET, &val);
+		sc->wlan_bt_flags = val;
+		val = ((val & THINKPAD_NAME_MASK_BT) != 0);
+		break;
+
+	case ACPI_THINKPAD_METHOD_WLAN:
+		acpi_GetInteger(sc->handle, THINKPAD_NAME_WLAN_BT_GET, &val);
+		sc->wlan_bt_flags = val;
+		val = ((val & THINKPAD_NAME_MASK_WLAN) != 0);
+		break;
+
+	case ACPI_THINKPAD_METHOD_FANSPEED:
+		if (sc->fan_handle) {
+			if (ACPI_FAILURE(acpi_GetInteger(sc->fan_handle,
+			    NULL, &val)))
+				val = -1;
+		}
+		else {
+			ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_FANSPEED,
+			    &val_ec, 2);
+			val = val_ec;
+		}
+		break;
+
+	case ACPI_THINKPAD_METHOD_FANLEVEL:
+		/*
+		 * The THINKPAD_EC_FANSTATUS register works as follows:
+		 * Bit 0-5 indicate the level at which the fan operates. Only
+		 *       values between 0 and 7 have an effect. Everything
+		 *       above 7 is treated the same as level 7
+		 * Bit 6 overrides the fan speed limit if set to 1
+		 * Bit 7 indicates at which mode the fan operates:
+		 *       manual (0) or automatic (1)
+		 */
+		if (!sc->fan_handle) {
+			ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_FANSTATUS,
+			    &val_ec, 1);
+			val = val_ec & THINKPAD_EC_MASK_FANLEVEL;
+		}
+		break;
+
+	case ACPI_THINKPAD_METHOD_FANSTATUS:
+		if (!sc->fan_handle) {
+			ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_FANSTATUS,
+			    &val_ec, 1);
+			val = (val_ec & THINKPAD_EC_MASK_FANSTATUS) ==
+			    THINKPAD_EC_MASK_FANSTATUS;
+		}
+		else
+			val = -1;
+		break;
+	}
+
+	return (val);
+}
+
+static int
+acpi_thinkpad_sysctl_set(struct acpi_thinkpad_softc *sc, int method, int arg)
+{
+	int			val, step, i;
+	ACPI_INTEGER		val_ec;
+	ACPI_OBJECT		Arg;
+	ACPI_OBJECT_LIST	Args;
+	ACPI_STATUS		status;
+
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+	/* ACPI_SERIAL_ASSERT(thinkpad); */
+
+	switch (method) {
+	case ACPI_THINKPAD_METHOD_EVENTS:
+		if (arg < 0 || arg > 1)
+			return (EINVAL);
+
+		status = acpi_SetInteger(sc->handle,
+		    THINKPAD_NAME_EVENTS_STATUS_SET, arg);
+		if (ACPI_FAILURE(status))
+			return (status);
+		if (sc->events_mask_supported)
+			return acpi_thinkpad_eventmask_set(sc,
+			    sc->events_availmask);
+		break;
+
+	case ACPI_THINKPAD_METHOD_EVENTMASK:
+		if (sc->events_mask_supported)
+			return acpi_thinkpad_eventmask_set(sc, arg);
+		break;
+
+	case ACPI_THINKPAD_METHOD_BRIGHTNESS:
+		if (arg < 0 || arg > 7)
+			return (EINVAL);
+
+		if (sc->cmos_handle) {
+			/* Read the current brightness */
+			status = ACPI_EC_READ(sc->ec_dev,
+			    THINKPAD_EC_BRIGHTNESS, &val_ec, 1);
+			if (ACPI_FAILURE(status))
+				return (status);
+			val = val_ec & THINKPAD_EC_MASK_BRI;
+
+			Args.Count = 1;
+			Args.Pointer = &Arg;
+			Arg.Type = ACPI_TYPE_INTEGER;
+			Arg.Integer.Value = (arg > val) ?
+			    THINKPAD_CMOS_BRIGHTNESS_UP :
+			    THINKPAD_CMOS_BRIGHTNESS_DOWN;
+
+			step = (arg > val) ? 1 : -1;
+			for (i = val; i != arg; i += step) {
+				status = AcpiEvaluateObject(sc->cmos_handle,
+				    NULL, &Args, NULL);
+				if (ACPI_FAILURE(status))
+					break;
+			}
+		}
+		return ACPI_EC_WRITE(sc->ec_dev, THINKPAD_EC_BRIGHTNESS,
+		    arg, 1);
+		break;
+
+	case ACPI_THINKPAD_METHOD_VOLUME:
+		if (arg < 0 || arg > 14)
+			return (EINVAL);
+
+		status = ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_VOLUME,
+		    &val_ec, 1);
+		if (ACPI_FAILURE(status))
+			return (status);
+
+		if (sc->cmos_handle) {
+			val = val_ec & THINKPAD_EC_MASK_VOL;
+
+			Args.Count = 1;
+			Args.Pointer = &Arg;
+			Arg.Type = ACPI_TYPE_INTEGER;
+			Arg.Integer.Value = (arg > val) ?
+			    THINKPAD_CMOS_VOLUME_UP : THINKPAD_CMOS_VOLUME_DOWN;
+
+			step = (arg > val) ? 1 : -1;
+			for (i = val; i != arg; i += step) {
+				status = AcpiEvaluateObject(sc->cmos_handle,
+				    NULL, &Args, NULL);
+				if (ACPI_FAILURE(status))
+					break;
+			}
+		}
+		return ACPI_EC_WRITE(sc->ec_dev, THINKPAD_EC_VOLUME, arg +
+		    (val_ec & (~THINKPAD_EC_MASK_VOL)), 1);
+		break;
+
+	case ACPI_THINKPAD_METHOD_MUTE:
+		if (arg < 0 || arg > 1)
+			return (EINVAL);
+
+		status = ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_VOLUME,
+		    &val_ec, 1);
+		if (ACPI_FAILURE(status))
+			return (status);
+
+		if (sc->cmos_handle) {
+			val = val_ec & THINKPAD_EC_MASK_VOL;
+
+			Args.Count = 1;
+			Args.Pointer = &Arg;
+			Arg.Type = ACPI_TYPE_INTEGER;
+			Arg.Integer.Value = THINKPAD_CMOS_VOLUME_MUTE;
+
+			status = AcpiEvaluateObject(sc->cmos_handle, NULL,
+			    &Args, NULL);
+			if (ACPI_FAILURE(status))
+				break;
+		}
+		return ACPI_EC_WRITE(sc->ec_dev, THINKPAD_EC_VOLUME, (arg==1) ?
+		   val_ec | THINKPAD_EC_MASK_MUTE :
+		   val_ec & (~THINKPAD_EC_MASK_MUTE), 1);
+		break;
+
+	case ACPI_THINKPAD_METHOD_THINKLIGHT:
+		if (arg < 0 || arg > 1)
+			return (EINVAL);
+
+		if (sc->light_set_supported) {
+			Args.Count = 1;
+			Args.Pointer = &Arg;
+			Arg.Type = ACPI_TYPE_INTEGER;
+			Arg.Integer.Value = arg ?
+			    sc->light_cmd_on : sc->light_cmd_off;
+
+			status = AcpiEvaluateObject(sc->light_handle, NULL,
+			    &Args, NULL);
+			if (ACPI_SUCCESS(status))
+				sc->light_val = arg;
+			return (status);
+		}
+		break;
+
+	case ACPI_THINKPAD_METHOD_BLUETOOTH:
+		if (arg < 0 || arg > 1)
+			return (EINVAL);
+
+		val = (arg == 1) ? sc->wlan_bt_flags |
+		    THINKPAD_NAME_MASK_BT :
+		    sc->wlan_bt_flags & (~THINKPAD_NAME_MASK_BT);
+		return acpi_SetInteger(sc->handle, THINKPAD_NAME_WLAN_BT_SET,
+		    val);
+		break;
+
+	case ACPI_THINKPAD_METHOD_FANLEVEL:
+		if (arg < 0 || arg > 7)
+			return (EINVAL);
+
+		if (!sc->fan_handle) {
+			/* Read the current fanstatus */
+			ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_FANSTATUS,
+			    &val_ec, 1);
+			val = val_ec & (~THINKPAD_EC_MASK_FANLEVEL);
+
+			return ACPI_EC_WRITE(sc->ec_dev, THINKPAD_EC_FANSTATUS,
+			    val | arg, 1);
+		}
+		break;
+
+	case ACPI_THINKPAD_METHOD_FANSTATUS:
+		if (arg < 0 || arg > 1)
+			return (EINVAL);
+
+		if (!sc->fan_handle) {
+			/* Read the current fanstatus */
+			ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_FANSTATUS,
+			    &val_ec, 1);
+
+			return ACPI_EC_WRITE(sc->ec_dev, THINKPAD_EC_FANSTATUS,
+			    (arg == 1) ? (val_ec | THINKPAD_EC_MASK_FANSTATUS) :
+			    (val_ec & (~THINKPAD_EC_MASK_FANSTATUS)), 1);
+		}
+		break;
+	}
+
+	return (0);
+}
+
+static int
+acpi_thinkpad_sysctl_init(struct acpi_thinkpad_softc *sc, int method)
+{
+	int 			dummy;
+	ACPI_OBJECT_TYPE 	cmos_t;
+	ACPI_HANDLE		ledb_handle;
+
+	switch (method) {
+	case ACPI_THINKPAD_METHOD_EVENTS:
+		/* Events are disabled by default */
+		return (TRUE);
+
+	case ACPI_THINKPAD_METHOD_EVENTMASK:
+		return (sc->events_mask_supported);
+
+	case ACPI_THINKPAD_METHOD_HOTKEY:
+	case ACPI_THINKPAD_METHOD_BRIGHTNESS:
+	case ACPI_THINKPAD_METHOD_VOLUME:
+	case ACPI_THINKPAD_METHOD_MUTE:
+		/* EC is required here, which was already checked before */
+		return (TRUE);
+
+	case ACPI_THINKPAD_METHOD_THINKLIGHT:
+		sc->cmos_handle = NULL;
+		sc->light_get_supported = ACPI_SUCCESS(acpi_GetInteger(
+		    sc->ec_handle, THINKPAD_NAME_KEYLIGHT, &sc->light_val));
+
+		if ((ACPI_SUCCESS(AcpiGetHandle(sc->handle, "\\UCMS",
+		    &sc->light_handle)) ||
+		    ACPI_SUCCESS(AcpiGetHandle(sc->handle, "\\CMOS",
+		    &sc->light_handle)) ||
+		    ACPI_SUCCESS(AcpiGetHandle(sc->handle, "\\CMS",
+		    &sc->light_handle))) &&
+		    ACPI_SUCCESS(AcpiGetType(sc->light_handle, &cmos_t)) &&
+		    cmos_t == ACPI_TYPE_METHOD) {
+			sc->light_cmd_on = 0x0c;
+			sc->light_cmd_off = 0x0d;
+			sc->cmos_handle = sc->light_handle;
+		}
+		else if (ACPI_SUCCESS(AcpiGetHandle(sc->handle, "\\LGHT",
+		    &sc->light_handle))) {
+			sc->light_cmd_on = 1;
+			sc->light_cmd_off = 0;
+		}
+		else
+			sc->light_handle = NULL;
+
+		sc->light_set_supported = (sc->light_handle &&
+		    ACPI_FAILURE(AcpiGetHandle(sc->ec_handle, "LEDB",
+		    &ledb_handle)));
+
+		if (sc->light_get_supported)
+			return (TRUE);
+
+		if (sc->light_set_supported) {
+			sc->light_val = 0;
+			return (TRUE);
+		}
+
+		return (FALSE);
+
+	case ACPI_THINKPAD_METHOD_BLUETOOTH:
+	case ACPI_THINKPAD_METHOD_WLAN:
+		if (ACPI_SUCCESS(acpi_GetInteger(sc->handle,
+		    THINKPAD_NAME_WLAN_BT_GET, &dummy)))
+			return (TRUE);
+		return (FALSE);
+
+	case ACPI_THINKPAD_METHOD_FANSPEED:
+		/* 
+		 * Some models report the fan speed in levels from 0-7
+		 * Newer models report it contiguously
+		 */
+		sc->fan_levels = (ACPI_SUCCESS(AcpiGetHandle(sc->handle, "GFAN",
+		    &sc->fan_handle)) ||
+		    ACPI_SUCCESS(AcpiGetHandle(sc->handle, "\\FSPD",
+		    &sc->fan_handle)));
+		return (TRUE);
+
+	case ACPI_THINKPAD_METHOD_FANLEVEL:
+	case ACPI_THINKPAD_METHOD_FANSTATUS:
+		/* 
+		 * Fan status is only supported on those models,
+		 * which report fan RPM contiguously, not in levels
+		 */
+		if (sc->fan_levels)
+			return (FALSE);
+		return (TRUE);
+
+	case ACPI_THINKPAD_METHOD_THERMAL:
+		if (ACPI_SUCCESS(acpi_GetInteger(sc->ec_handle,
+		    THINKPAD_NAME_THERMAL_GET, &dummy))) {
+			sc->thermal_updt_supported =
+			    ACPI_SUCCESS(acpi_GetInteger(sc->ec_handle,
+			    THINKPAD_NAME_THERMAL_UPDT, &dummy));
+			return (TRUE);
+		}
+		return (FALSE);
+	}
+	return (FALSE);
+}
+
+static void
+acpi_thinkpad_notify(ACPI_HANDLE h, UINT32 notify, void *context)
+{
+	int		event, arg, type;
+	device_t	dev = context;
+	struct acpi_thinkpad_softc *sc = device_get_softc(dev);
+
+	ACPI_FUNCTION_TRACE_U32((char *)(uintptr_t)__func__, notify);
+
+	if (notify != 0x80)
+		device_printf(dev, "Unknown notify\n");
+
+	for (;;) {
+		acpi_GetInteger(acpi_get_handle(dev), THINKPAD_NAME_EVENTS_GET,
+		    &event);
+
+		if (event == 0)
+			break;
+
+		type = (event >> 12) & 0xf;
+		arg = event & 0xfff;
+		switch (type) {
+		case 1:
+			if (!(sc->events_availmask & (1 << (arg - 1)))) {
+				device_printf(dev, "Unknown key %d\n", arg);
+				break;
+			}
+
+			/* Notify devd(8) */
+			device_printf(dev, "THINKPAD event: %u\n",
+			    (arg & 0xff));
+			acpi_UserNotify("THINKPAD", h, (arg & 0xff));
+			break;
+		default:
+			break;
+		}
+	}
+}
+
+static void
+acpi_thinkpad_refresh(void *arg)
+{
+	struct acpi_thinkpad_softc *sc = (struct acpi_thinkpad_softc *)arg;
+	char temp_cmd[] = "TMP0";
+	int data, i;
+	ACPI_INTEGER speed;
+
+	for (i = 0; i < 8; i++) {
+		temp_cmd[3] = '0' + i;
+		
+                /*
+                 * The TMPx methods seem to return +/- 128 or 0
+                 * when the respecting sensor is not available
+                 */
+		sc->sensors[i].flags &= ~SENSOR_FINVALID;
+                if (ACPI_FAILURE(acpi_GetInteger(sc->ec_handle, temp_cmd,
+                    &data)) || ABS(data) == 128 || data == 0) {
+			sc->sensors[i].flags |= SENSOR_FINVALID;
+                        data = 0;
+		}
+                else if (sc->thermal_updt_supported) {
+                        /* XXX: Temperature is reported in tenth of Kelvin */
+                        data = (data - 2732 + 5) / 10;
+		}
+		sc->sensors[i].value = data * 1000000 + 273150000;
+        }
+	
+	sc->sensors[8].flags &= ~SENSOR_FINVALID;
+	if (sc->fan_handle) {
+		if (ACPI_FAILURE(acpi_GetInteger(sc->fan_handle,
+		    NULL, &data)))
+			sc->sensors[8].flags |= SENSOR_FINVALID;
+                        data = -1;
+        }
+        else {
+                ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_FANSPEED, &speed, 2);
+                data = speed;
+        }
+
+	sc->sensors[8].value = data;
+}
diff --git a/sys/platform/pc32/conf/files b/sys/platform/pc32/conf/files
--- a/sys/platform/pc32/conf/files
+++ b/sys/platform/pc32/conf/files
@@ -72,6 +72,7 @@ dev/serial/dgb/dgm.c			optional	dgm
 ${OSACPI_MD_DIR}/acpi_machdep.c		optional        acpi
 ${OSACPI_MD_DIR}/acpi_wakeup.c		optional        acpi
 ${OSACPI_MD_DIR}/acpi_toshiba.c		optional        acpi_toshiba acpi
+${ACPICA_DIR}/acpi_thinkpad/acpi_thinkpad.c optional	acpi_thinkpad acpi
 acpi.h					optional	acpi		\
 	dependency	"$S/${ACPICA_DIR}/include/acpi.h"		\
 	compile-with	"cp $S/${ACPICA_DIR}/include/acpi.h ${.OBJDIR}/"	\



From hasso at estpak.ee  Thu Mar 20 03:49:13 2008
From: hasso at estpak.ee (Hasso Tepper)
Date: Thu, 20 Mar 2008 03:49:13 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Some questions regarding ACPI
In-Reply-To: <200803191322.46366.hasso@estpak.ee>
Message-ID: <200803201237.28823.hasso@estpak.ee>

Hasso Tepper wrote:
> There is also one fatal issue -laptop locks up hardly (no panic) while 
> unloading module. Any idea regarding this is welcome.

Nevermind, solved.


-- 
Hasso




From dillon at apollo.backplane.com  Fri Mar 21 19:24:01 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Fri, 21 Mar 2008 19:24:01 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: panic: assertion: hammer_btree_cmp(cursor->left_bound,	&cursor->node->ondisk->elms[0].leaf.base) <= 0 in btree_split_leaf
In-Reply-To: <200802232204.m1NM4cxd046264@apollo.backplane.com>
Message-ID: <200803220212.m2M2CiAY014435@apollo.backplane.com>

:While trying to find a procedure to reliably reproduce the panic
:I reported last time, I caught a different panic (uploaded at
: ~y0netan1/crash/9/ on my leaf account).  I wrote the following shell
:script (make sure to edit variables DISKS and MOUNTPT before using this
:script or it may trash your system):

    Ok, I believe I have fixed the left_bound assertion.  I also believe
    I have fixed the node ref count assertion on umount.

    There is currently one unfixed assertion related to the I/O
    path... sometimes the bp is being improperly disassociated from the
    related HAMMER structure.

    The full-filesystem case is still not being handled so don't test that :-)

					    -Matt





From c.turner at 199technologies.org  Sun Mar 23 09:48:29 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Sun, 23 Mar 2008 09:48:29 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
Message-ID: <47E6870C.4080709@199technologies.org>

I'm finally getting around to doing 1.12 upgrades, and have setup a 
separate machine to do my bulk package builds / upgrades etc,
so as not to disrupt my 'dev server' while things are being
built / tested

However, this seems kind of wasteful - the only purpose of this machine
is to build packages against a specific release..
And since building packages for a particular release generally requires 
only the userland, appropriate headers and correct 'uname' output - so:

it seems like if spoofing uname is configured inside a jail,
the next (or previous..) release can be installed into a jail and
used for building / testing packages without the overhead of a VM or 
maintaining a separate physical host

I did a quick scan of the tree to see what this would take, and, high 
level, it seems like only the following changes would need to be made:

- update struct jail to add a 'osrelease' string
  (implies bumping 'jail api' to 2?)
- update jail(8) to actually pass this information along
- update sys_uname to test ucred for jailed processes, and
  use the struct jail osrelease if appropriate
- similarly update sysctl kern.osrelease to support jail spoofing
  (if possible - didn't get this far in the research yet)
  could be less of a problem for builds, as I think most things use
 uname(1) ... but good to keep the environment consistent I suppose..
I'm still a bit confused as to how 'osrelease' is defined - everything
I'm finding is showing up as extern char[] .. perhaps this is something 
in the build I'm not familiar with?

also,

is the so-called 'stupid hackery' in sys_uname needed still?

Before I start any coding, does this:

- sound like something useful
- sound like the right approach
Thinking this could have wider useful implications e.g. for pkgbox
& so on -  for example setting up automated bulks w/various combinations 
of pkgsrc and releases, etc.

Cheers,

- Chris





From corecode at fs.ei.tum.de  Sun Mar 23 10:06:38 2008
From: corecode at fs.ei.tum.de (Simon 'corecode' Schubert)
Date: Sun, 23 Mar 2008 10:06:38 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <47E68C74.3080808@fs.ei.tum.de>

Chris Turner wrote:
I did a quick scan of the tree to see what this would take, and, high 
level, it seems like only the following changes would need to be made:
brave investigation.  but you could also simply set UNAME_r :)

sweatshorts % uname -r
1.13.0-DEVELOPMENT
sweatshorts % UNAME_r=1.12-RELEASE uname -r
1.12-RELEASE
I think that's good enough :D

cheers
  simon
--
Serve - BSD     +++  RENT this banner advert  +++    ASCII Ribbon   /"\
Work - Mac      +++  space for low ????????? NOW!1  +++      Campaign     \ /
Party Enjoy Relax   |   http://dragonflybsd.org      Against  HTML   \
Dude 2c 2 the max   !   http://golden-apple.biz       Mail + News   / \




From c.turner at 199technologies.org  Sun Mar 23 10:50:13 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Sun, 23 Mar 2008 10:50:13 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <47E69656.8080605@199technologies.org>

Simon 'corecode' Schubert wrote:
brave investigation.  but you could also simply set UNAME_r :)
Doh! Thanks for the tip!

they should change the phrase from RTFM to 'Carefully RTFM' :)

well.. scratch that change then. 1 less patch to write.

- Chris





From c.turner at 199technologies.org  Sun Mar 23 11:15:52 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Sun, 23 Mar 2008 11:15:52 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <47E69C7C.8010109@199technologies.org>

Chris Turner wrote:
Simon 'corecode' Schubert wrote:
brave investigation.  but you could also simply set UNAME_r :)

for the record - if anyone's interested - adding a line e.g.:

ALL_ENV+= UNAME_r=1.12-RELEASE

to mk.conf looks like it -might- work ..

(unless wants to chime in & verify)





From joerg at britannica.bec.de  Sun Mar 23 11:46:53 2008
From: joerg at britannica.bec.de (Joerg Sonnenberger)
Date: Sun, 23 Mar 2008 11:46:53 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <20080323181428.GA2099@britannica.bec.de>

On Sun, Mar 23, 2008 at 01:41:42PM -0400, Chris Turner wrote:
> they should change the phrase from RTFM to 'Carefully RTFM' :)

RTFMAI -- Read The Fine Manual Again, Idiot.

Joerg




From dillon at apollo.backplane.com  Sun Mar 23 20:05:36 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Sun, 23 Mar 2008 20:05:36 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
Message-ID: <200803240257.m2O2voNH038355@apollo.backplane.com>

    Here's an update on the HAMMER work!

    Current status:

    * Passes all standard filesystem stress tests and buildworld will
      run with a HAMMER /usr/obj.  Large histories are able to accumulate
      without effecting performance.

    * Pruning and reblocking code is in and partially tested, but now needs
      more stringent testing.

    * Full historical access appears to be working but needs testing.
      Note that a sync is still needed to flush dirty cached data prior
      to acquiring a timestamp for the 'snapshot' to be set in stone.
      (dirty data cached in-memory has no historical tags and must be
      committed to physical disk before it can be accessed historically).


    Current bugs:

    * There is one known bug in the standard operations code paths
      that results in an assertion in HAMMER's I/O subsystem.

    * There are probably bugs in the reblocking and/or pruning code.  More
      likely in the reblocking code.


    There are two big-ticket and several little-ticket items left.  HAMMER
    will officially go Alpha when the big-ticket items are done, and beta
    when we get a few of the little-ticket items done.

    Big ticket items left:

    * UNDO (crash recovery) code.  Currently it writes out undo records but
      they are not yet sequenced, buffer writes are not yet ordered, and
      there is no mount-time recovery code yet.

      This is the last item needed before HAMMER can go operational.

    * Filesystem full handling.  Currently no space is reserved for dirty
      cached data so it is possible to create/write files and for HAMMER
      to not have sufficient space left on-disk to flush it.


    Little ticket items:

    * Automated reblocking (currently these functions are manually
      initialized via the hammer utility).

    * I/O clustering and preliminary BMAP op when writing out large files.

    * CRC checking (CRC fields are reserved but not entirely generated yet
      and not yet checked at all).

    * Disaster Recovery filesystem scan.

    * Boot support.

    I expect all of these items and more to be handled by the 2.0 release
    in July.

			    Additional HAMMER capabilities
				(no timeline yet)

    * Adding, removing, and resizing a HAMMER filesystem's backing store.

			Ultimate Goals and working towards them
				(no timeline yet)

    Our ultimate goal with HAMMER and DragonFly in general is to support
    fully cache coherent replication in a multi-machine environment.  This
    involves several steps and networking protocols.

    * Replication of synchronization streams based on the UNDO log.  If
      resynchronizing to a target which is too old a B-Tree scan will
      likely be required.

    * Cache coherency protocols for machine-machine coherency for both
      replicated and remote-HAMMER access.

    I have no time frame for these items yet.  It will depend on how quickly
    HAMMER moves to Alpha and Beta status.  I will say, however, now
    that HAMMER's on-disk format has solidified, that I have a very precise
    understanding of the protocols that will be needed to accomplish fully
    cache coherent remote access for both replicated and non-replicated
    (remote mount style) access.

    And, as you know, fully coherent filesystem access across machines is
    going to be the basis for DragonFly's clustering across said machines.

    In summary, things are progressing very well.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From justin at shiningsilence.com  Sun Mar 23 20:10:13 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Sun, 23 Mar 2008 20:10:13 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <53758.192.168.0.252.1206327873.squirrel@www.shiningsilence.com>

On Sun, March 23, 2008 12:36 pm, Chris Turner wrote:

> it seems like if spoofing uname is configured inside a jail,
> the next (or previous..) release can be installed into a jail and
> used for building / testing packages without the overhead of a VM or
> maintaining a separate physical host

If you don't need a jail to spoof uname, as others posted, you can
installworld into a chroot and build everything you want there using
Joerg's spiffy pbulk.  That's what I'm doing on pkgbox now; I can hand you
my somewhat terse notes if you want.  It would be relatively easy to set
up the configuration you're talking about.





From sepherosa at gmail.com  Sun Mar 23 20:18:20 2008
From: sepherosa at gmail.com (Sepherosa Ziehau)
Date: Sun, 23 Mar 2008 20:18:20 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <ea7b9c170803232012n2f27f893tf1d756d7c9770419@mail.gmail.com>

On Mon, Mar 24, 2008 at 2:14 AM, Joerg Sonnenberger
<joerg at britannica.bec.de> wrote:
> On Sun, Mar 23, 2008 at 01:41:42PM -0400, Chris Turner wrote:
>  > they should change the phrase from RTFM to 'Carefully RTFM' :)
>
>  RTFMAI -- Read The Fine Manual Again, Idiot.

http://leaf.dragonflybsd.org/~sephe/rtfm.jpg

:D

>
>  Joerg
>



-- 
Live Free or Die




From justin at shiningsilence.com  Sun Mar 23 20:38:30 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Sun, 23 Mar 2008 20:38:30 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: GSoC 2008 - mentors signup
Message-ID: <53885.192.168.0.252.1206329503.squirrel@www.shiningsilence.com>

If you are planning to be a mentor for a Summer of Code project, please
sign up here for the mentors mailing list:

http://groups.google.com/group/google-summer-of-code-mentors-list

If you've already signed up, your subscription should be set up tomorrow.





From justin at shiningsilence.com  Sun Mar 23 21:12:01 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Sun, 23 Mar 2008 21:12:01 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: GSoC 2008 - mentors signup
In-Reply-To: <53885.192.168.0.252.1206329503.squirrel@www.shiningsilence.com>
Message-ID: <54025.192.168.0.252.1206331572.squirrel@www.shiningsilence.com>

Also!

If you are a potential mentor and you have not done so yet:

http://code.google.com/soc/mentor_step1.html

Get yourself registered as a mentor for the Summer of Code project.  Once
you are in there, check off DragonFly in the "My Profile" section.

You will need a Google Account if you don't have one:

http://www.google.com/accounts

This will add you to the list of mentors in the Google Summer of Code web
application, so you can review/be attached to projects.

A guide is available if you want more information:

http://groups.google.com/group/google-summer-of-code-announce/web/guide-to-the-gsoc-web-app-for-mentors-and-organization-administrators






From c.turner at 199technologies.org  Mon Mar 24 04:29:28 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Mon, 24 Mar 2008 04:29:28 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <47E78ECE.4070307@199technologies.org>

Justin C. Sherrill wrote:
If you don't need a jail to spoof uname, as others posted, you can
installworld into a chroot and build everything you want there using
Joerg's spiffy pbulk.  That's what I'm doing on pkgbox now; I can hand you
my somewhat terse notes if you want.  It would be relatively easy to set
up the configuration you're talking about.
cheers - I guess I thought incorrectly that something 'special' was 
needed to get the uname to change .. have been using the legacy bulks in 
chroots / jails (for 'same os' builds) as I haven't quite migrated to 
pbulk yet ..

thanks for the help offer - I'll ask if I run into trouble.




From dillon at apollo.backplane.com  Mon Mar 24 08:28:49 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Mon, 24 Mar 2008 08:28:49 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <200803241500.m2OF0CG8043760@apollo.backplane.com>


:http://leaf.dragonflybsd.org/~sephe/rtfm.jpg
:
::D

    Ho!

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From elekktretterr at exemail.com.au  Mon Mar 24 09:10:15 2008
From: elekktretterr at exemail.com.au (Petr Janda)
Date: Mon, 24 Mar 2008 09:10:15 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
In-Reply-To: <200803240257.m2O2voNH038355@apollo.backplane.com>
Message-ID: <200803250138.49775.elekktretterr@exemail.com.au>


>
>     And, as you know, fully coherent filesystem access across machines is
>     going to be the basis for DragonFly's clustering across said machines.
>
>     In summary, things are progressing very well.
>


Hi Matt,
That's good to know things are going so well. Got a question. If memory serves 
me right, initially there was also going to be a thing called ANVIL, I can't 
remember what it was supposed to do and whether its still in your design. 
Could you elaborate a little?

Thanks,
Petr




From dillon at apollo.backplane.com  Mon Mar 24 14:12:11 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Mon, 24 Mar 2008 14:12:11 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
In-Reply-To: <200803240257.m2O2voNH038355@apollo.backplane.com>
Message-ID: <200803242100.m2OL0nWV046868@apollo.backplane.com>


:Hi Matt,
:That's good to know things are going so well. Got a question. If memory serves 
:me right, initially there was also going to be a thing called ANVIL, I can't 
:remember what it was supposed to do and whether its still in your design. 
:Could you elaborate a little?
:
:Thanks,
:Petr

    It's not really in the HAMMER design any more, primarily because HAMMER's
    volume model seems to work fine as-is.  Ultimately something like ANVIL
    (a block storage manager) would prove beneficial to the project but it
    would be treated as a separate project.  HAMMER's redundancy model is
    going to be baesd around replication and clustering.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From tgen at netphreax.net  Mon Mar 24 18:31:37 2008
From: tgen at netphreax.net (Thomas E. Spanjaard)
Date: Mon, 24 Mar 2008 18:31:37 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
In-Reply-To: <200803240257.m2O2voNH038355@apollo.backplane.com>
Message-ID: <47E85337.2070407@netphreax.net>

Matthew Dillon wrote:
    * Full historical access appears to be working but needs testing.
      Note that a sync is still needed to flush dirty cached data prior
      to acquiring a timestamp for the 'snapshot' to be set in stone.
      (dirty data cached in-memory has no historical tags and must be
      committed to physical disk before it can be accessed historically).
Wouldn't making timestamp queries (at least from userland) enforce a 
sync on the volume in question be useful here?
--
        Thomas E. Spanjaard
        tgen at netphreax.net
Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00005.pgp
Type: application/octet-stream
Size: 186 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080324/3077333f/attachment-0010.obj>

From dillon at apollo.backplane.com  Mon Mar 24 20:10:12 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Mon, 24 Mar 2008 20:10:12 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
In-Reply-To: <200803240257.m2O2voNH038355@apollo.backplane.com>
Message-ID: <200803250302.m2P32qLP050160@apollo.backplane.com>


:Wouldn't making timestamp queries (at least from userland) enforce a 
:sync on the volume in question be useful here?
:-- 
:         Thomas E. Spanjaard
:         tgen at netphreax.net

    Making the 'hammer now' command do a sync() is a good idea.  I will
    make that change right now so it doesn't get lost.

    Here's a general overview of the issues involved with having historical
    access to the filesystem:

				----------------

    Recording the timestamps in the in-memory cache, for a finer-grained
    snapshot capability, is doable but has its own issues.  Here's an
    illustration:

    open()  create file
    write() append 4K	(file size now 4K)
    write() append 4K	(file size now 8K)
    write() append 4K	(file size now 12K)
    write() append 4K	(file size now 16K)

    Now NONE of this has gone to disk yet, it's entirely in the in-memory
    cache.  The inode is in the in-memory cache.  The data is stored in
    the buffer cache.  Even the directory entry for the file that we
    just created is still in the in-memory cache (HAMMER caches the raw
    records it intends to commit later on).

    If I wanted to be able to acquire a timestamp between each write and
    'see' a snapshot of the file as of any point in the above sequence,
    then every write would also have to allocate a copy of the inode
    (because it changes size on each write).

    The data has the same problem though with a slightly different example.
    Lets say each write() was a seek-write, overwriting the previous data.
    Now with every write() I would have to allocate a copy of the data
    being overwritten.  This is complicated by the fact that the buffer
    cache has no clue about 'historical' accesses, so I would not be able
    to use the buffer cache to cache the data.

    There's also another problem and that is with the efficiency of the
    topology on-disk.  Even if I maintained all the copies of the inode
    and all the copies of the data in-memory, I would still have to sync
    all those copies to disk in order for things to remain historically
    coherent (whether it be in-cache or on-disk).  This would result in
    hundreds or even thousands of copies of the inode on-disk, not to
    mention potentially many copies of the data.

    I just don't want to do that right now, at least not as a default.  A
    lot of performance would be lost.  Hence a sync() is needed if
    you want to create a demark which you can accurately snapshot.

				-------------

    Here's a quick synopsis of how the cache would operate in a clustered
    filesystem:

    In order to properly integrate with in-memory caches, a wider cache
    coherency infrastructure is needed between machines such that
    modifications made on one machine proactively invalidate those
    protions of the cache(s) on other machines.  At the same time, any
    'dirty' cache data, for example when a file is created or written to,
    must lock the cache space in question on all other machines.
    The cache space in this case is not just the file data, but also the
    related namespaces (for creations, deletions, and renames).  Attempts
    to access locked spaces from other machines in the cluster would have
    to force a flush to the filesystem backing store and lower the cache
    states for the effected information on the original machine from dirty
    to shared-read-only.

    It will be easiest to integrate the cache coherency information into
    the buffer cache and namecache themselves.  Once a machine has dirtied
    an in-memory cache element... for example part of the namespace when
    creating a file or chunks of data written within a file, that machine
    must have a free hand to make further modifications to the cache spaces
    involved without further interaction with other machines.

				-------------

    Now, if you think of those two major elements you can see that they
    actually fit together quite well.  If I were to attempt to maintain
    transactional coherency on a per-system-call basis then the cache
    granularity between machines would have to be much, much smaller then
    our current in-memory caching elements provide.  That would become
    a really nasty coding problem.  So I don't even want to begin to
    complate transactional coherency at a finer-grain then sync() or
    fsync() until long after we actually have clustering working.

						-Matt





From elekktretterr at exemail.com.au  Mon Mar 24 21:56:58 2008
From: elekktretterr at exemail.com.au (Petr Janda)
Date: Mon, 24 Mar 2008 21:56:58 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
In-Reply-To: <200803240257.m2O2voNH038355@apollo.backplane.com>
Message-ID: <200803251516.16407.elekktretterr@exemail.com.au>

So is it needed to run hammer now in order to "create" a snapshot? What would 
I do in situation like this: got a hammer filesystem and couple of the files 
change on day to day basis. Then a week later I needed to access one of the 
files, in exactly the state they were 7 days ago.

Cheers,
Petr




From dillon at apollo.backplane.com  Mon Mar 24 22:34:15 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Mon, 24 Mar 2008 22:34:15 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
In-Reply-To: <200803240257.m2O2voNH038355@apollo.backplane.com>
Message-ID: <200803250526.m2P5QZ5X051081@apollo.backplane.com>


:So is it needed to run hammer now in order to "create" a snapshot? What would 
:I do in situation like this: got a hammer filesystem and couple of the files 
:change on day to day basis. Then a week later I needed to access one of the 
:files, in exactly the state they were 7 days ago.
:
:Cheers,
:Petr

    No, you do not have to run 'hammer now' to create a snapshot.  The
    kernel syncs all filesystems every 30 seconds, so if you do nothing
    at all you get a snapshot granularity of 30 seconds.

    Where you would use 'hammer now' is if you wanted the most current
    snapshot possible for the purpose of, say, backing up your filesystem
    to another machine.  You might do something like this:

	set timestamp = `hammer now`
	cpdup /mountpoint/@@$timestamp targethost:/somepath

    But if you didn't care about that you could just go back far enough
    that you get a stable historical view... e.g. go back 1 minute and you
    would have a stable view into your filesystem.

	set timestamp = `hammer stamp 60s`		<------ doesn't sync
	cpdup /mountpoint/@@$timestamp targethost:/somepath


    Ultimately the idea of managing filesystems this way is to still do
    regular backups from your production machine to your backup machine
    (ultimately by way of replication), with both running HAMMER, but only
    retain a limited amount of history on the production box.  You might
    desire to retain only one week's worth of history on the production box,
    retain one month's history on your local backup box, and retain a very
    granular one year's worth of history on your remote backup box.

    Come to think of it, I should add some more directives to the
    'hammer prune' command to make that easier to specify.

    Until I implement a live replication 'feed' the minimum granularity on
    the backup box will be how often you do your backups (e.g. once a day),
    and you can prune it into more granular forms from that starting point.
    Once we have a live replication feed the backup box will have the same
    30-second granularity that the production machine has.

    A major bullet point for this style of management is that the retention
    policy on the various boxes can be different even though they are
    all slaved off the same production filesystem.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From justin at shiningsilence.com  Tue Mar 25 05:58:49 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Tue, 25 Mar 2008 05:58:49 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: SoC - student signups
Message-ID: <58180.65.106.147.226.1206449676.squirrel@www.shiningsilence.com>

Here's a quick link roundup:

Are you a student?  Put in your application for a Google Summer of Code here:

http://code.google.com/soc/2008/student_signup.html

Student guide:
http://groups.google.com/group/google-summer-of-code-announce/web/guide-to-the-gsoc-web-app-for-student-applicants

Are you a mentor?  (That means hasso, hsu, sephe, matthias, TGEN, and
corecode right now)

Student proposals will show up on the mentor page, linked below.  You will
get to rate them, and take the one(s) that you want to mentor.

Mentor page:
http://code.google.com/soc/2008/mentor_home.html
Mentor guide:
http://groups.google.com/group/google-summer-of-code-announce/web/guide-to-the-gsoc-web-app-for-mentors-and-organization-administrators

If you are a mentor and are communicating with potential students, send
them the URLs above for student signup and the student guide; work with
them if they ask for advice on what to say in the application.  They can
resubmit up to 20 times if they want to correct it.

Deadline is March 31st.






From noah.yan at gmail.com  Thu Mar 27 20:17:48 2008
From: noah.yan at gmail.com (Yonghong Yan)
Date: Thu, 27 Mar 2008 20:17:48 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: About DFBSD.64
In-Reply-To: <47EB0B5B.5020802@gmail.com>
Message-ID: <59521b110803272015y1cc8cc39uc93f154ed36e0505@mail.gmail.com>

thanks for your interest.

I owe to everybody for any update or work in the past four months. so
many things happen in my work and my family (they are all good:) and
keep me extremely busy. But i am not leaving and will be back on this
soon.

the latest sources are in http://repo.or.cz/w/dragonfly/port-amd64.git
, I did have a compiled kernel long time before, but I have to break
it to work on the pmap. you can pick up from there. TGEN will help you
a lot, also keep me posted too, if you like.

Noah

On Wed, Mar 26, 2008 at 9:50 PM, Sdavtaker <sdavtaker at gmail.com> wrote:
> Hello,
>  Im applying to GSoC to work in the x64 version of DFBSD with TGEN, i
>  found some work already done in the repository and some mails in the
>  archive from you.
>  I was wondering if you already had a working compiled kernel in AMD64
>  machine and what was not working yet to continue that work.
>  Thanks for any info.
>  Sdav
>




From dillon at apollo.backplane.com  Sat Mar 29 13:27:43 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Sat, 29 Mar 2008 13:27:43 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 29-Mar-2008
Message-ID: <200803292022.m2TKMLGe004942@apollo.backplane.com>

    Good progress continues to be made.  HAMMER survived acting as my
    LAN backup machine (in full historical mode) for almost a week before
    it hit an assertion.  I've fixed that issue and believe that the core
    filesystem implementation code is now 'very stable'.

    Note that the recent commit will result in many more 'hammer_lock_ex:'
    messages on the console then you may have previously observed.  This is
    due to the way object id's are allocated in the face of parallel 
    modifications to the filesystem, resulting in too much locality of
    reference in the B-Tree.  I do intend to improve it.

    I am still working on the two major items needed before HAMMER can be
    declared operational, those being the filesystem full handling and the
    undo/recovery-on-mount code.  These are the last 'hard' bits left in
    the design.

    With exception to filling up the filesystem, which *will* create a mess,
    and noting that no crash recovery code exists yet (so you have to newfs
    it if you crash), I'd appreciate it if interested parties could test
    the other functions of the filesystem, in particular the pruning and
    reblocking functions (man hammer), and the historical access functions.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From dillon at apollo.backplane.com  Sun Mar 30 15:11:03 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Sun, 30 Mar 2008 15:11:03 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Need ideas on how to solve an st_ino/st_dev test issue for HAMMER.
Message-ID: <200803302207.m2UM7BCp016402@apollo.backplane.com>

    Here's the problem, given historical access softlinks as shown below:

test30# ls -lda cra*
drwxr-xr-x  1 root  wheel  Mar 29 13:04 crater
lrwxr-xr-x  1 root  wheel  Mar 29 18:57 crater.20080329 -> crater@@0x47eef383
lrwxr-xr-x  1 root  wheel  Mar 30 01:24 crater.20080330 -> crater@@0x47ef4e29
-rw-r--r--  2 root  wheel  Mar 30 01:24 crater.log

    The problem is that if I do this:

    diff -r crater.20080329/var/log crater.20080330/var/log

    Diff just returns without actually diffing anything.  The reason is
    because diff checks st_ino and st_dev and believes the directories/files
    to be identical because they match.

    I considered munging the inode number for historical accesses, but
    that would seriously break NFS exports which try to access historical
    files and directories.  Right now NFS *is* able to distinguish between
    the two because NFS handles are 128-bit-wide entities, so I can encode
    the as-of transaction id as part of the filehandle.  But userland
    programs only have access to a 64-bit-wide inode so userland still
    believes the files to be identical.

    st_dev is only 32 bits, carefully munging it is an option if we
    could figure out a way to do it, but I'd rather not.

    I am considering using st_gen but then we'd have to patch third
    party software to test st_gen along with everything else.  This may
    be the only workable solution, though, and only a few programs would
    need to be patched.  st_gen is only 32 bits but it would solve the
    problem as we would be able to use all 32 bits.

    If anyone has any bright ideas, including 'leave it alone', I'm all
    ears.

						-Matt





From justin at shiningsilence.com  Mon Mar 31 10:40:42 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Mon, 31 Mar 2008 10:40:42 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: SoC student applications due by 5PM PDT tomorrow
In-Reply-To: <1942.192.168.0.242.1206930479.squirrel@www.shiningsilence.com>
Message-ID: <11892.67.108.184.175.1206984967.squirrel@www.shiningsilence.com>

On Sun, March 30, 2008 10:27 pm, Justin C. Sherrill wrote:
> SoC students:
>
> If you have an application to submit for DragonFly/Summer of Code, please
> do so by 17:00 Pacific time on the 31st - that's tomorrow, at least for
> me.

The deadline for student proposals has been extended to April 7th; all
other dates move forward one week to acommodate.

This is a good time to update existing applications or submit new ones. 
Talk to your (potential) mentors if you are curious.






From nthery at gmail.com  Mon Mar 31 11:29:49 2008
From: nthery at gmail.com (Nicolas Thery)
Date: Mon, 31 Mar 2008 11:29:49 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
Message-ID: <64fc43b0803311126na7d0b27obaa9d35bac6d32ee@mail.gmail.com>

Hello,

Now that the release is over, I'll try to get rid of zones and migrate
allocations to objcache.

Here is a 1st patch that migrate struct proc.  I'll commit it in a
couple of days if nobody objects.

I'm also implementing a way to monitor objcache statistics.  So far,
I've hacked sth similar to
sysctl vm.zone: stats are returned in one giant string, one line per
cache.  That's simple but ugly and hard to read because there are
quite a few stats per cache.

So I'm thinking about implementing a small tool, ocstat, that extracts
stats from sysctl the way ps(1) does (thru libkvm iirc) and formats it
in various ways.  What do you think?

Cheers,
Nicolas

Index: src2/sys/kern/kern_exit.c
===================================================================
--- src2.orig/sys/kern/kern_exit.c	2008-03-31 08:05:59.139796000 +0200
+++ src2/sys/kern/kern_exit.c	2008-03-31 10:31:39.000000000 +0200
@@ -834,7 +834,7 @@ loop:
 			}

 			vm_waitproc(p);
-			zfree(proc_zone, p);
+			objcache_put(proc_cache, p);
 			nprocs--;
 			return (0);
 		}
Index: src2/sys/kern/kern_proc.c
===================================================================
--- src2.orig/sys/kern/kern_proc.c	2008-03-31 08:05:59.139918000 +0200
+++ src2/sys/kern/kern_proc.c	2008-03-31 10:31:39.000000000 +0200
@@ -84,7 +84,7 @@ u_long pgrphash;
 struct proclist allproc;
 struct proclist zombproc;
 struct spinlock allproc_spin;
-vm_zone_t proc_zone;
+struct objcache* proc_cache;
 vm_zone_t lwp_zone;
 vm_zone_t thread_zone;

@@ -131,7 +131,7 @@ procinit(void)
 	spin_init(&allproc_spin);
 	pidhashtbl = hashinit(maxproc / 4, M_PROC, &pidhash);
 	pgrphashtbl = hashinit(maxproc / 4, M_PROC, &pgrphash);
-	proc_zone = zinit("PROC", sizeof (struct proc), 0, 0, 5);
+	proc_cache = objcache_create_simple(M_PROC, sizeof(struct proc));
 	lwp_zone = zinit("LWP", sizeof (struct lwp), 0, 0, 5);
 	thread_zone = zinit("THREAD", sizeof (struct thread), 0, 0, 5);
 	uihashinit();
Index: src2/sys/sys/proc.h
===================================================================
--- src2.orig/sys/sys/proc.h	2008-03-31 08:05:59.140325000 +0200
+++ src2/sys/sys/proc.h	2008-03-31 10:31:39.000000000 +0200
@@ -473,7 +473,7 @@ struct proc *zpfind (pid_t);	/* Find zom
 struct vm_zone;
 struct globaldata;
 struct lwp_params;
-extern struct vm_zone *proc_zone;
+extern struct objcache *proc_cache;
 extern struct vm_zone *lwp_zone;

 int	enterpgrp (struct proc *p, pid_t pgid, int mksess);
Index: src2/sys/kern/kern_fork.c
===================================================================
--- src2.orig/sys/kern/kern_fork.c	2008-03-31 08:05:59.140042000 +0200
+++ src2/sys/kern/kern_fork.c	2008-03-31 10:31:39.000000000 +0200
@@ -332,7 +332,7 @@ fork1(struct lwp *lp1, int flags, struct
 	}

 	/* Allocate new proc. */
-	p2 = zalloc(proc_zone);
+	p2 = objcache_get(proc_cache, M_WAITOK);
 	bzero(p2, sizeof(*p2));

 	/*




From hsu at dragonflybsd.org  Mon Mar 31 11:44:34 2008
From: hsu at dragonflybsd.org (Jeffrey Hsu)
Date: Mon, 31 Mar 2008 11:44:34 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <64fc43b0803311126na7d0b27obaa9d35bac6d32ee@mail.gmail.com>
Message-ID: <200803311841.m2VIfQAI007579@nlpi001.prodigy.net>

The object cache is not a general-purpose memory allocator.  It's a cache of
pre-initialized objects.  Are the significant portions of the proc structure
that can be restored to initialized state on object puts?  If not, it's best
to just use a general-purpose memory allocator.

								Jeffrey




From corecode at fs.ei.tum.de  Mon Mar 31 12:07:02 2008
From: corecode at fs.ei.tum.de (Simon 'corecode' Schubert)
Date: Mon, 31 Mar 2008 12:07:02 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <200803311841.m2VIfQAI007579@nlpi001.prodigy.net>
Message-ID: <47F1357B.1070302@fs.ei.tum.de>

Jeffrey Hsu wrote:
> The object cache is not a general-purpose memory allocator.  It's a cache of
> pre-initialized objects.  Are the significant portions of the proc structure
> that can be restored to initialized state on object puts?  If not, it's best
> to just use a general-purpose memory allocator.

Why?  What's the loss if we use the object cache to allocate struct procs?

cheers
  simon

Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00006.pgp
Type: application/octet-stream
Size: 252 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080331/a4a24314/attachment-0010.obj>

From nthery at gmail.com  Mon Mar 31 12:17:03 2008
From: nthery at gmail.com (Nicolas Thery)
Date: Mon, 31 Mar 2008 12:17:03 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <nthery@gmail.com>
Message-ID: <64fc43b0803311214u7da6bbb8xaf971de1a80e7258@mail.gmail.com>

2008/3/31, Jeffrey Hsu <hsu at dragonflybsd.org>:
> The object cache is not a general-purpose memory allocator.  It's a cache of
>  pre-initialized objects.  Are the significant portions of the proc structure
>  that can be restored to initialized state on object puts?  If not, it's best
>  to just use a general-purpose memory allocator.

Well, I haven't checked this yet.  I planned to do this in a second
step after getting rid of zones.

I thought that even without  the pre-initialization part, objcache has
the advantage
of pre-allocating set of objects (as zones) and is additionally
mp-safe (contrary to zones and, granted, as malloc()).   The latter
may be interesting as we talk of improving MP support.

Cheers,
Nicolas




From dillon at apollo.backplane.com  Mon Mar 31 12:23:40 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Mon, 31 Mar 2008 12:23:40 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <200803311841.m2VIfQAI007579@nlpi001.prodigy.net>
Message-ID: <200803311921.m2VJLITB027669@apollo.backplane.com>

    I both agree and disagree with Jeff.  I think the only *disadvantage*
    to using objcache for struct proc is that objcache must cache a minimum
    number of free structures to be efficient so the overall kernel memory
    use would be a bit greater verses uses kmalloc().  But I agree with Jeff
    in that objcache's biggest advantage is that you can keep structural state
    intact and struct proc might not be a good candidate (yet).

    What I suggest is that you convert struct proc from zone to kmalloc
    first, and then look into a possible objcache adaptation.  kmalloc
    is not slow.. it's a very fast allocator.  Objcache is probably a tad
    faster but not by much.  Where objcache really wins is in not having
    to completey reinitialize the allocated structures.

    Over the years I've removed (I think) all the dependancies on requiring
    the proc structure to be in stable memory so I believe it can be moved to
    kmalloc/objcache now without any major pain.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From corecode at fs.ei.tum.de  Mon Mar 31 12:37:40 2008
From: corecode at fs.ei.tum.de (Simon 'corecode' Schubert)
Date: Mon, 31 Mar 2008 12:37:40 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: SoC student applications due by 5PM PDT tomorrow
In-Reply-To: <1942.192.168.0.242.1206930479.squirrel@www.shiningsilence.com>
Message-ID: <47F13CDA.6010703@fs.ei.tum.de>

Justin C. Sherrill wrote:
> On Sun, March 30, 2008 10:27 pm, Justin C. Sherrill wrote:
>> SoC students:
>>
>> If you have an application to submit for DragonFly/Summer of Code, please
>> do so by 17:00 Pacific time on the 31st - that's tomorrow, at least for
>> me.
> The deadline for student proposals has been extended to April 7th; all
> other dates move forward one week to acommodate.

This is very good.

Some more ideas for eager students (we want to keep the ratio, right?):

Enhance the FreeBSD/DragonFly sound infrastructure to support surround
sound/multichannel output.

Update sound drivers to support S/PDIF output.

Make the sound infrastructure OSSv4 compatible (there was a SoC at
FreeBSD last year or so)


of course only if it doesn't exist already :)

cheers
  simon


Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00007.pgp
Type: application/octet-stream
Size: 252 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080331/6da61cff/attachment-0010.obj>

From corecode at fs.ei.tum.de  Mon Mar 31 12:41:30 2008
From: corecode at fs.ei.tum.de (Simon 'corecode' Schubert)
Date: Mon, 31 Mar 2008 12:41:30 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <200803311841.m2VIfQAI007579@nlpi001.prodigy.net>
Message-ID: <47F13DE4.10205@fs.ei.tum.de>

Matthew Dillon wrote:
>     What I suggest is that you convert struct proc from zone to kmalloc
>     first, and then look into a possible objcache adaptation.  kmalloc
>     is not slow.. it's a very fast allocator.  Objcache is probably a tad
>     faster but not by much.  Where objcache really wins is in not having
>     to completey reinitialize the allocated structures.

Could we please not move to kmalloc, but instead try to move all fast
path allocations to objcache?  I don't like the idea of allocating
everything with kmalloc.  Caching struct procs is not a bad thing itself.

cheers
  simon


Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00008.pgp
Type: application/octet-stream
Size: 252 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080331/ac328c08/attachment-0010.obj>

From hsu at FreeBSD.org  Mon Mar 31 12:59:05 2008
From: hsu at FreeBSD.org (Jeffrey Hsu)
Date: Mon, 31 Mar 2008 12:59:05 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <47F1357B.1070302@fs.ei.tum.de>
Message-ID: <200803311920.m2VJK5Ln018015@nlpi015.prodigy.net>

The object cache sits on top of a general-purpose memory allocator such
as kmalloc or zalloc and provides pre-initialized object caching functionality.
If you're not going to use the object caching functionality, you can just
call the underlying memory allocator directly.

							Jeffrey




From dillon at apollo.backplane.com  Mon Mar 31 16:17:19 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Mon, 31 Mar 2008 16:17:19 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <200803311841.m2VIfQAI007579@nlpi001.prodigy.net>
Message-ID: <200803312311.m2VNBumd029866@apollo.backplane.com>

:Could we please not move to kmalloc, but instead try to move all fast
:path allocations to objcache?  I don't like the idea of allocating
:everything with kmalloc.  Caching struct procs is not a bad thing itself.=
:
:
:cheers
:  simon

    I will state for the record that I'm fine with either objcache or
    kmalloc.  I agree with Jeff that using objcache for struct proc
    probably isn't necessary but I also agree that it would not hurt either,
    and if the intent is to optimize the initialization of the proc
    structure in the future then moving to objcache now would save us
    from having to do it later.

    So whichever method Nicolas wants to use is fine with me.

						-Matt




From hsu at dragonflybsd.org  Mon Mar 31 19:22:47 2008
From: hsu at dragonflybsd.org (Jeffrey Hsu)
Date: Mon, 31 Mar 2008 19:22:47 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <64fc43b0803311214u7da6bbb8xaf971de1a80e7258@mail.gmail.com>
Message-ID: <200804010218.m312IVUq003624@nlpi043.prodigy.net>

  >> Are there significant portions of the proc structure
  >> that can be restored to initialized state on object puts?

  > I planned to do this in a second step after getting rid of zones.

I'll all in favor of making more use of caching pre-initialized objects, so
if this is your objective, then please go ahead.  It's just that I'd convert
over to the object cache in one step.

  > I thought that even without  the pre-initialization part, objcache has
  > the advantage of pre-allocating set of objects (as zones) and is additionally
  > mp-safe (contrary to zones and, granted, as malloc()).

Well, the zone allocator is MP-safe.  It's not hard to lock up the places that
manipulate the linked-list of free items. Look for uses of the zlock field.

								Jeffrey




From tgen at netphreax.net  Sat Mar  1 12:57:53 2008
From: tgen at netphreax.net (Thomas E. Spanjaard)
Date: Sat, 1 Mar 2008 12:57:53 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: [Fwd: Project Support Open Source: $50 donation to support you      project]
In-Reply-To: <2468.192.168.0.242.1204346451.squirrel@www.shiningsilence.com>
Message-ID: <47C9C1B7.50203@netphreax.net>

Justin C. Sherrill wrote:
The "donation" happens after you place an "acknowledgement" on an open
source project's web page.  I'm putting those words in scare quotes
because I think it's a "payment" for an "advertisement".  The supplied
link has nothing to do with DragonFly, to say the least.

<a href="http://www.2insure4less.com /" title="We support FOSS software
projects.">Online Insurance Quotes</a>
To think our souls are only worth $50...
--
        Thomas E. Spanjaard
        tgen at netphreax.net
Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00000.pgp
Type: application/octet-stream
Size: 186 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080301/0d61e240/attachment-0011.obj>

From c.turner at 199technologies.org  Sat Mar  1 17:52:31 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Sat, 1 Mar 2008 17:52:31 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Misc. ACPI / suspend
Message-ID: <47CA073B.6020106@199technologies.org>

Wondering if anyone more well versed in the ACPI implementation could
comment on the applicability of:
http://lkml.org/lkml/2007/4/6/69

w/r/t the current state of the art in Dfly

(or BSD's in general)

Cheers!

- Chris




From elekktretterr at exemail.com.au  Sun Mar  2 00:41:25 2008
From: elekktretterr at exemail.com.au (Petr Janda)
Date: Sun, 2 Mar 2008 00:41:25 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: CARP question
Message-ID: <200803021934.21669.elekktretterr@exemail.com.au>

So Ive setup CARP on 2 DF-based mailservers. Installation went fine. Box 1 has 
adskew of 0 therefore it is the MASTER. Box 2 has adskew of 254, therefore is 
BACKUP.  If i down the carp0 interface on Box 1, then Box 2 carp interface 
gets promoted to MASTER. Then I up the carp interface on Box 1, logically Box 
2 should become BACKUP again as Box 1 becomes MASTER due to adskew set to 0.

However it doesnt happen. When carp0 interface on Box 1 is upped it becomes a 
BACKUP, not a MASTER even though according to adskew it should be MASTER.

What is the desired behaviour?

Cheers
Petr




From qhwt+dfly at les.ath.cx  Sun Mar  2 02:50:14 2008
From: qhwt+dfly at les.ath.cx (YONETANI Tomokazu)
Date: Sun, 2 Mar 2008 02:50:14 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: panic: assertion: hammer_btree_cmp(cursor->left_bound,	&cursor->node->ondisk->elms[0].leaf.base) <= 0 in btree_split_leaf
In-Reply-To: <200802232204.m1NM4cxd046264@apollo.backplane.com>
Message-ID: <20080302104554.GA22813@les.ath.cx>

Hi.
While trying to find a procedure to reliably reproduce the panic
I reported last time, I caught a different panic (uploaded at
 ~y0netan1/crash/9/ on my leaf account).  I wrote the following shell
script (make sure to edit variables DISKS and MOUNTPT before using this
script or it may trash your system):
  #!/bin/sh -ex
  DISKS="/dev/ad0s1f"
  MOUNTPT=/mnt/HAMMER

  cd /
  newfs_hammer -L TEST $DISKS
  for i in `seq 1 100`; do
	  mount_hammer $DISKS $MOUNTPT
	  /bin/rm -rf $MOUNTPT/??
	  (set +x; for x in `seq 1 10000`; do echo -n > $MOUNTPT/$x; done)
	  umount $MOUNTPT
  done

And the panic is triggered by rm command.
I'll try to see if it's possible to reproduce the last one without
unmounting then mounting the HAMMER fs.

Cheers.




From dillon at apollo.backplane.com  Sun Mar  2 13:25:33 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Sun, 2 Mar 2008 13:25:33 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: panic: assertion: hammer_btree_cmp(cursor->left_bound,	&cursor->node->ondisk->elms[0].leaf.base) <= 0 in btree_split_leaf
In-Reply-To: <200802232204.m1NM4cxd046264@apollo.backplane.com>
Message-ID: <200803022119.m22LJRCY037076@apollo.backplane.com>


:Hi.
:While trying to find a procedure to reliably reproduce the panic
:I reported last time, I caught a different panic (uploaded at
: ~y0netan1/crash/9/ on my leaf account).  I wrote the following shell
:script (make sure to edit variables DISKS and MOUNTPT before using this
:script or it may trash your system):

(from the core)

panic: assertion: node->lock.refs == 0 && node->ondisk == NULL in hammer_flush_buffer_nodes

    Yah, I've seen this failure.  Add a sync or two before the umount and
    tell me if it still occurs.  It's either a node reference leak somewhere
    or it is a race between bufdaemon and umount.  The assertions are really
    strict there precisely to catch those sorts of cases.

    Also note that the code to deal with a full HAMMMER filesystem has not
    been written yet (The failure you are reporting is unrelated to a full
    HAMMER filesystem, though, just mentioning it).

						-Matt





From dillon at apollo.backplane.com  Sun Mar  2 13:29:03 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Sun, 2 Mar 2008 13:29:03 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Misc. ACPI / suspend
In-Reply-To: <47CA073B.6020106@199technologies.org>
Message-ID: <200803022126.m22LQbfI037188@apollo.backplane.com>


:Wondering if anyone more well versed in the ACPI implementation could
:comment on the applicability of:
:
:http://lkml.org/lkml/2007/4/6/69
:
:w/r/t the current state of the art in Dfly
:
:(or BSD's in general)
:
:Cheers!
:
:- Chris

    I really have no idea re: this.  Suspension in general is not well
    supported by any of the BSDs.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From dillon at apollo.backplane.com  Sun Mar  2 13:34:05 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Sun, 2 Mar 2008 13:34:05 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: [Fwd: Project Support Open Source: $50 donation to support you      project]
In-Reply-To: <2468.192.168.0.242.1204346451.squirrel@www.shiningsilence.com>
Message-ID: <200803022131.m22LVOe9037250@apollo.backplane.com>

:..
:source project's web page.  I'm putting those words in scare quotes
:because I think it's a "payment" for an "advertisement".  The supplied
:link has nothing to do with DragonFly, to say the least.
:
:I don't think this is a good idea, obviously, and replied to that effect. 
:However, I wanted to put this on a DragonFly list, in part to show this
:strange thing, and in part because I'm not comfortable making
:administrative decisions on behalf of the Project without being open as
:possible about it.

    It doesn't really cry out to me either.

						-Matt





From wbh at conducive.org  Sun Mar  2 20:36:32 2008
From: wbh at conducive.org (Bill Hacker)
Date: Mon, 03 Mar 2008 04:36:32 +0000
Subject: Misc. ACPI / suspend
In-Reply-To: <47CA073B.6020106@199technologies.org>
Message-ID: <47cb8050$0$855$415eb37d@crater_reader.dragonflybsd.org>

Matthew Dillon wrote:
:Wondering if anyone more well versed in the ACPI implementation could
:comment on the applicability of:
:
:http://lkml.org/lkml/2007/4/6/69
:
:w/r/t the current state of the art in Dfly
:
:(or BSD's in general)
:
:Cheers!
:
:- Chris
    I really have no idea re: this.  Suspension in general is not well
    supported by any of the BSDs.
					-Matt
					Matthew Dillon 
					<dillon at backplane.com>


. . and there seems to be a bit of a 'Catch 22' there in any case.

If the BIOS can alter 'stuff' out of site of the OS it is parking, what 
does the existence of such a 'feature' do to a(ny) security model?

Seems to at least beg creating the option of setting a flag to 
specifically *prevent* suspend-to-disk/hibernation (and/or force a 
reboot on wake-up).

Just because one is paranoid....  etc

Bill





From matthias at dragonflybsd.org  Tue Mar  4 02:30:52 2008
From: matthias at dragonflybsd.org (Matthias Schmidt)
Date: Tue, 4 Mar 2008 02:30:52 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
Message-ID: <20080304102335.GI9833@staatsfeind.org>

Hi,

Google just announced its Summer of Code for 2008:

	http://code.google.com/soc/2008/

I think this would be a great opportunity for DragonFly to participate
as a mentoring organisation.  We could attract new developers and could
get code/work done.  Looking at the SoC results of the other BSDs most
of their projects were a success.  Of course, not all, but a reasonable
percentage.  See [1] and [2].

It is some extra work for us, but IMO the benefits outweigh the extra
work.  And yes, I would volunteer as a mentor.  What do others
(developers) think?  Any more volunteers? :)

Some project ideas that come into my mind.  More ideas are listed in the
wiki:  http://wiki.dragonflybsd.org/index.cgi/ProjectsPage

 * Fix all remaining bugs in dma(8) and implement all missing features
 * Add a driver for newer Intel Wireless cards (I think sephe@ would
   love that :)
 * Bring our ACPI stuff in shape.  Maybe suspend2disk ...

 * [Add your own thoughts here]

Cheers,

	Matthias

PS: I don't want to create a bikeshed here whether you like the SoC or
not :)

[1] http://code.google.com/soc/2007/freebsd/about.html
[2] http://code.google.com/soc/2007/netbsd/about.html




From corecode at fs.ei.tum.de  Tue Mar  4 04:46:14 2008
From: corecode at fs.ei.tum.de (Simon 'corecode' Schubert)
Date: Tue, 4 Mar 2008 04:46:14 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47CD4386.1000704@fs.ei.tum.de>

Matthias Schmidt wrote:
>  * [Add your own thoughts here]

MP lock removal for network stack

and for the system  (first profile, find hot spots, fix hot spots, repeat)

cheers
  simon




From c.turner at 199technologies.org  Tue Mar  4 06:02:20 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Tue, 4 Mar 2008 06:02:20 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47CD551E.1040604@199technologies.org>

Matthias Schmidt wrote:
Some project ideas that come into my mind.  More ideas are listed in the
wiki:  http://wiki.dragonflybsd.org/index.cgi/ProjectsPage
+1 acpi
+1 interrupt routing
+1 SMP / giant removal
+1 pf synchup with openbsd
though there are several others on the page that are good..

need to dig up my wiki login and place appropriately..

also: thinking the ZFS port should be removed from the page - makes 
sense to everyone else? (e.g. fragments effort w/r/t hammer)





From tgen at netphreax.net  Tue Mar  4 06:54:31 2008
From: tgen at netphreax.net (Thomas E. Spanjaard)
Date: Tue, 4 Mar 2008 06:54:31 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47CD615F.8010209@netphreax.net>

Matthias Schmidt wrote:
Google just announced its Summer of Code for 2008:

 * [Add your own thoughts here]
x86-64 port :).
--
        Thomas E. Spanjaard
        tgen at netphreax.net
Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00001.pgp
Type: application/octet-stream
Size: 186 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080304/0d921000/attachment-0011.obj>

From rdivacky at FreeBSD.org  Tue Mar  4 07:07:03 2008
From: rdivacky at FreeBSD.org (Roman Divacky)
Date: Tue, 4 Mar 2008 07:07:03 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <20080304150255.GA8831@freebsd.org>

On Tue, Mar 04, 2008 at 02:49:03PM +0000, Thomas E. Spanjaard wrote:
> Matthias Schmidt wrote:
> >Google just announced its Summer of Code for 2008:
> >
> > * [Add your own thoughts here]
> 
> x86-64 port :).

all those ideas are great and needed etc. but keep in
mind that the projects should be doable by students
who might see dfly for the very first time.

don't overestimate whats possible and select projects
that look realistic

Roman Divacky (former SoC student)




From justin at shiningsilence.com  Tue Mar  4 08:32:56 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Tue, 4 Mar 2008 08:32:56 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <60322.65.106.147.226.1204648095.squirrel@www.shiningsilence.com>

On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
> Hi,
>
> Google just announced its Summer of Code for 2008:
>
> 	http://code.google.com/soc/2008/
>
> I think this would be a great opportunity for DragonFly to participate
> as a mentoring organisation.  We could attract new developers and could
> get code/work done.  Looking at the SoC results of the other BSDs most
> of their projects were a success.  Of course, not all, but a reasonable
> percentage.  See [1] and [2].

We've applied in previous years - Jeff Hsu did one year, and I put
together the application last year.  The hardest thing to find was
students (and they are the thing that helps SoC applications a lot, I
think).

Any student volunteers?  We have mentors.





From rluciani at gmail.com  Tue Mar  4 09:38:29 2008
From: rluciani at gmail.com (Robert Luciani)
Date: Tue, 04 Mar 2008 18:38:29 +0100
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47cd8915$0$854$415eb37d@crater_reader.dragonflybsd.org>

Justin C. Sherrill wrote:
> On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
>> Hi,
>>
>> Google just announced its Summer of Code for 2008:
>>
>> 	http://code.google.com/soc/2008/
>>
>> I think this would be a great opportunity for DragonFly to participate
>> as a mentoring organisation.  We could attract new developers and could
>> get code/work done.  Looking at the SoC results of the other BSDs most
>> of their projects were a success.  Of course, not all, but a reasonable
>> percentage.  See [1] and [2].
> 
> We've applied in previous years - Jeff Hsu did one year, and I put
> together the application last year.  The hardest thing to find was
> students (and they are the thing that helps SoC applications a lot, I
> think).
> 
> Any student volunteers?  We have mentors.
> 

bingo

-- 
Robert Luciani
Chalmers University of Technology, SWE
Department of Computer Science and Engineering
http://www.rluciani.com/public.key




From sdavtaker at gmail.com  Tue Mar  4 09:31:08 2008
From: sdavtaker at gmail.com (=?UTF-8?Q?Sd=C3=A4vtaker?=)
Date: Tue, 4 Mar 2008 09:31:08 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <c37d69f60803040926k206218a3kb8496d0cd18148bd@mail.gmail.com>

If you mentor, i will apply for coder :-)
Still in last year of university. :-)
Sdav

On Tue, Mar 4, 2008 at 1:28 PM, Justin C. Sherrill
<justin at shiningsilence.com> wrote:
> On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
>  > Hi,
>  >
>  > Google just announced its Summer of Code for 2008:
>  >
>  >       http://code.google.com/soc/2008/
>  >
>  > I think this would be a great opportunity for DragonFly to participate
>  > as a mentoring organisation.  We could attract new developers and could
>  > get code/work done.  Looking at the SoC results of the other BSDs most
>  > of their projects were a success.  Of course, not all, but a reasonable
>  > percentage.  See [1] and [2].
>
>  We've applied in previous years - Jeff Hsu did one year, and I put
>  together the application last year.  The hardest thing to find was
>  students (and they are the thing that helps SoC applications a lot, I
>  think).
>
>  Any student volunteers?  We have mentors.
>
>



-- 
Sd?vtaker prays to Rikku goddess for a good treasure.



From rluciani at gmail.com  Tue Mar  4 09:44:02 2008
From: rluciani at gmail.com (Robert Luciani)
Date: Tue, 04 Mar 2008 18:44:02 +0100
Subject: google soc "DragonFly"
Message-ID: <47cd8a63$0$855$415eb37d@crater_reader.dragonflybsd.org>

On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
> > Hi,
> >
> > Google just announced its Summer of Code for 2008:
> >
> > 	http://code.google.com/soc/2008/
> >
> > I think this would be a great opportunity for DragonFly to participate
> > as a mentoring organisation.  We could attract new developers and could
> > get code/work done.  Looking at the SoC results of the other BSDs most
> > of their projects were a success.  Of course, not all, but a reasonable
> > percentage.  See [1] and [2].

We've applied in previous years - Jeff Hsu did one year, and I put
together the application last year.  The hardest thing to find was
students (and they are the thing that helps SoC applications a lot, I
think).

Any student volunteers?  We have mentors.


-- 
Robert Luciani
Chalmers University of Technology, SWE
Department of Computer Science and Engineering
http://www.rluciani.com/public.key




From rluciani at gmail.com  Tue Mar  4 10:04:14 2008
From: rluciani at gmail.com (Robert Luciani)
Date: Tue, 04 Mar 2008 19:04:14 +0100
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47cd8f1f$0$856$415eb37d@crater_reader.dragonflybsd.org>

Robert Luciani wrote:
> Justin C. Sherrill wrote:
>> On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
>>> Hi,
>>>
>>> Google just announced its Summer of Code for 2008:
>>>
>>> 	http://code.google.com/soc/2008/
>>>
>>> I think this would be a great opportunity for DragonFly to participate
>>> as a mentoring organisation.  We could attract new developers and could
>>> get code/work done.  Looking at the SoC results of the other BSDs most
>>> of their projects were a success.  Of course, not all, but a reasonable
>>> percentage.  See [1] and [2].
>> We've applied in previous years - Jeff Hsu did one year, and I put
>> together the application last year.  The hardest thing to find was
>> students (and they are the thing that helps SoC applications a lot, I
>> think).
>>
>> Any student volunteers?  We have mentors.
>>
> 
> bingo
> 
My girlfriend Danwei noted that she would also like partake in the SoC.
She's studying IT here at Chalmers and will join the mailing list shortly.
-- 
Robert Luciani
Chalmers University of Technology, SWE
Department of Computer Science and Engineering
http://www.rluciani.com/public.key




From dillon at apollo.backplane.com  Tue Mar  4 13:08:30 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Tue, 4 Mar 2008 13:08:30 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Going to have to roll 1.12.1
Message-ID: <200803042104.m24L43g1065278@apollo.backplane.com>

    Due to a critical bug in sendmail that can cause it to seg-fault I will
    be rolling 1.12.1 as soon as I get verification that the current
    fix deals with it.

						-Matt





From sdavtaker at gmail.com  Tue Mar  4 17:40:43 2008
From: sdavtaker at gmail.com (=?UTF-8?B?U2TDpHZ0YWtlcg==?=)
Date: Tue, 4 Mar 2008 17:40:43 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: [Fwd: Project Support Open Source: $50 donation to support you  project]
In-Reply-To: <2468.192.168.0.242.1204346451.squirrel@www.shiningsilence.com>
Message-ID: <47CDF8D1.9070100@gmail.com>

50 bucks?
Come on...
You can get a meal a lot more expensive than that just going to a free 
HP conference about linux and you only have to rent your soul 3-5 hours ;-)
Sdav

Matthew Dillon escribi?:
:..
:source project's web page.  I'm putting those words in scare quotes
:because I think it's a "payment" for an "advertisement".  The supplied
:link has nothing to do with DragonFly, to say the least.
:
:I don't think this is a good idea, obviously, and replied to that effect. 
:However, I wanted to put this on a DragonFly list, in part to show this
:strange thing, and in part because I'm not comfortable making
:administrative decisions on behalf of the Project without being open as
:possible about it.

    It doesn't really cry out to me either.

						-Matt

  






From sdavtaker at gmail.com  Tue Mar  4 17:56:35 2008
From: sdavtaker at gmail.com (=?UTF-8?B?U2TDpHZ0YWtlcg==?=)
Date: Tue, 4 Mar 2008 17:56:35 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47CDFCCE.1010106@gmail.com>

A cute idea for for GSOC would be to finish the installer.
We were talking about this in my local BUG, we trying to find out how to 
help on that from here.
There is a few missing features in the CD.

   * FDISK, you need to create the slides from another OS before
     install DFBSD, i think port FDisk from FBSD or any *BSD will solve it.
   * Add to the make release a way to add some custom applications to
     the released liveCD (suppose you want to add nmap or ssh or
     something just to use as test disk in some enviroment).
   * Make the installer a little more customizable, and maybe w/ a GUI
     (I like a lot the console approach, but GUI installer will be a
     popularity move, DFBSD w/X makes a Desktop machine work, actually
     im using it that way and really like it).
I think those projects can be done in a SOC by students (like me) with a 
little guide.
Im a lot more interested in things network related and kernel, but i 
dont mind to work on those things, they need to be done some day.
What u think?
Sdav

Robert Luciani escribi?:
Robert Luciani wrote:
  
Justin C. Sherrill wrote:
    
On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
      
Hi,

Google just announced its Summer of Code for 2008:

	http://code.google.com/soc/2008/

I think this would be a great opportunity for DragonFly to participate
as a mentoring organisation.  We could attract new developers and could
get code/work done.  Looking at the SoC results of the other BSDs most
of their projects were a success.  Of course, not all, but a reasonable
percentage.  See [1] and [2].
        
We've applied in previous years - Jeff Hsu did one year, and I put
together the application last year.  The hardest thing to find was
students (and they are the thing that helps SoC applications a lot, I
think).
Any student volunteers?  We have mentors.

      
bingo

    
My girlfriend Danwei noted that she would also like partake in the SoC.
She's studying IT here at Chalmers and will join the mailing list shortly.
  






From c.turner at 199technologies.org  Tue Mar  4 18:30:53 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Tue, 4 Mar 2008 18:30:53 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47CE04C9.1010902@199technologies.org>

Justin C. Sherrill wrote:
together the application last year.  The hardest thing to find was
students (and they are the thing that helps SoC applications a lot, I
think).
umm.. if google wants to send me back to school, I'll sign up - hows 
that for a fair trade :?






From wbh at conducive.org  Tue Mar  4 23:52:13 2008
From: wbh at conducive.org (Bill Hacker)
Date: Wed, 05 Mar 2008 07:52:13 +0000
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47ce512e$0$855$415eb37d@crater_reader.dragonflybsd.org>

Sd?vtaker wrote:
A cute idea for for GSOC would be to finish the installer.
We were talking about this in my local BUG, we trying to find out how to 
help on that from here.
There is a few missing features in the CD.

   * FDISK, you need to create the slides from another OS before
     install DFBSD, i think port FDisk from FBSD or any *BSD will solve it.
I'd rather see that 'reversed' - i.e. - build a more capable fdisk in 
DFLY with hope that it might be seen worth importing into Free/Net/Open, 
or *at least* be able to do a more flexible job than those now do.

And disklabels as well. Hand in glove.

Here's why:

- At the moment, working with Free, Open, DFLY, and OpenSolaris on the 
same HDD requires a bit of acrobatics.

- There seems to now be greater divergence between/among the *BSD's as 
to being able to read each other's disklabels, mount and use each 
other's 'flavor' of FFS/UFS (not to mention Apple's implementation of 
UFS) than there is among the vast multitude of Linux ext2/3 denizens.

Even to the point where use of a *Linux* fs is the more universal way 
for being able to share mounts among the *BSD's. Think detached drives. 
And no - FAT is not all that practical for several reasons.

- DFLY currently has the most fine-grain ability to create slices and 
partitions. But the others cannot all (any?) read those.

'progress' w/r any of the *BSD's direction as to changes, improvements 
(or not) in their once-common-ancestry fs & disklabels need not be 
sacrificed.

I'm not holding out wish or hope for all players agreeing to return to 
'one sacred way'. Nor 'one new universal fs'. Neither is gonna happen.

But a 'legacy compatible' or least-common-denominator mode would do fine 
- most especially for portable / SAN devices.

So - how about a 'flexible' DFLY fdisk to go along with a 'flexible' 
disklabel that could adapt to whatever it found / was told to create?

JM2CW - but that *might* be a good place to get a cross-*BSD team together.

*snip* (other good stuff)

Bill Hacker




From matthias at dragonflybsd.org  Wed Mar  5 01:02:43 2008
From: matthias at dragonflybsd.org (Matthias Schmidt)
Date: Wed, 5 Mar 2008 01:02:43 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <20080305085747.GJ9833@staatsfeind.org>

Hi,

* Justin C. Sherrill wrote:
> 
> We've applied in previous years - Jeff Hsu did one year, and I put
> together the application last year.  The hardest thing to find was
> students (and they are the thing that helps SoC applications a lot, I
> think).

This is good to know, so we could coordinate that if we have enough
mentors and projects?!?  I put together a small text in the wiki:

http://wiki.dragonflybsd.org/index.cgi/GoogleSoC2008

Feel free to add project or missing stuff.  I'm sure I missed a lot of
things :)

> Any student volunteers?  We have mentors.

According to the discussion we could have some students, who would be a
mentor (besides me)?

Regards

	Matthias





From sdavtaker at gmail.com  Wed Mar  5 06:28:37 2008
From: sdavtaker at gmail.com (=?UTF-8?Q?Sd=C3=A4vtaker?=)
Date: Wed, 5 Mar 2008 06:28:37 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <c37d69f60803050624kd86d3d0w3b44a02d0e5a5391@mail.gmail.com>

<quote>
Write a driver (from scratch) for Intel 3945 wireless device
Mentor: Sepherosa Ziehau
</quote>

Yes yes yes, i want to :-)
Someone else planning to mentor in drivers coding?
Sdav

On Wed, Mar 5, 2008 at 5:57 AM, Matthias Schmidt
<matthias at dragonflybsd.org> wrote:
> Hi,
>
>
>  * Justin C. Sherrill wrote:
>  >
>  > We've applied in previous years - Jeff Hsu did one year, and I put
>  > together the application last year.  The hardest thing to find was
>  > students (and they are the thing that helps SoC applications a lot, I
>  > think).
>
>  This is good to know, so we could coordinate that if we have enough
>  mentors and projects?!?  I put together a small text in the wiki:
>
>  http://wiki.dragonflybsd.org/index.cgi/GoogleSoC2008
>
>  Feel free to add project or missing stuff.  I'm sure I missed a lot of
>  things :)
>
>
>  > Any student volunteers?  We have mentors.
>
>  According to the discussion we could have some students, who would be a
>  mentor (besides me)?
>
>  Regards
>
>         Matthias
>
>



-- 
Sd?vtaker prays to Rikku goddess for a good treasure.



From rluciani at gmail.com  Wed Mar  5 10:56:42 2008
From: rluciani at gmail.com (Robert Luciani)
Date: Wed, 05 Mar 2008 19:56:42 +0100
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47ceecea$0$847$415eb37d@crater_reader.dragonflybsd.org>

Sd?vtaker wrote:
> <quote>
> Write a driver (from scratch) for Intel 3945 wireless device
> Mentor: Sepherosa Ziehau
> </quote>
> 
> Yes yes yes, i want to :-)
> Someone else planning to mentor in drivers coding?
> Sdav
> 
> On Wed, Mar 5, 2008 at 5:57 AM, Matthias Schmidt
> <matthias at dragonflybsd.org> wrote:
>> Hi,
>>
>>
>>  * Justin C. Sherrill wrote:
>>  >
>>  > We've applied in previous years - Jeff Hsu did one year, and I put
>>  > together the application last year.  The hardest thing to find was
>>  > students (and they are the thing that helps SoC applications a lot, I
>>  > think).
>>
>>  This is good to know, so we could coordinate that if we have enough
>>  mentors and projects?!?  I put together a small text in the wiki:
>>
>>  http://wiki.dragonflybsd.org/index.cgi/GoogleSoC2008
>>
>>  Feel free to add project or missing stuff.  I'm sure I missed a lot of
>>  things :)
>>
>>
>>  > Any student volunteers?  We have mentors.
>>
>>  According to the discussion we could have some students, who would be a
>>  mentor (besides me)?
>>
>>  Regards
>>
>>         Matthias
>>
>>
> 
> 
>

IF someone starts to write a 3945 Intel driver,
please keep the newer 4965 in mind too.

-- 
Robert Luciani
Chalmers University of Technology, SWE
Department of Computer Science and Engineering
http://www.rluciani.com/public.key




From joerg at britannica.bec.de  Wed Mar  5 12:01:05 2008
From: joerg at britannica.bec.de (Joerg Sonnenberger)
Date: Wed, 5 Mar 2008 12:01:05 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <20080305195711.GA9981@britannica.bec.de>

On Wed, Mar 05, 2008 at 07:56:42PM +0100, Robert Luciani wrote:
> IF someone starts to write a 3945 Intel driver,
> please keep the newer 4965 in mind too.

NetBSD's wpi works quite well. The hardware is quite different from
4945.

Joerg




From sepherosa at gmail.com  Wed Mar  5 17:48:50 2008
From: sepherosa at gmail.com (Sepherosa Ziehau)
Date: Wed, 5 Mar 2008 17:48:50 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <ea7b9c170803051744u22b09484ofc994f034f11df3b@mail.gmail.com>

On Thu, Mar 6, 2008 at 2:56 AM, Robert Luciani <rluciani at gmail.com> wrote:
>  IF someone starts to write a 3945 Intel driver,

"IF" you know that trying to fix any wired bugs in certain drivers
(e.g. ipw, ral) will require you to read through all of the vendor's
linux code (yes, even including register values and position), i.e.
there is not much difference between writing one from scratch and
porting+fixing_bugs, then you probably will not put "IF" at the start
of your sentence.
If what I said sounded too harsh to you, then I was sorry.

>  please keep the newer 4965 in mind too.

Will do, once generic 11n support is brought in from freebsd.

Best Regards,
sephe

-- 
Live Free or Die




From saw at online.de  Thu Mar  6 05:34:14 2008
From: saw at online.de (Sascha Wildner)
Date: Thu, 06 Mar 2008 14:34:14 +0100
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
Message-ID: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>

Hi all,

this is probably as good a moment as any to come out of the forest with 
this. The patch at

http://leaf.dragonflybsd.org/~swildner/nrelease_gui.diff

adds some code to nrelease/ to build a LiveCD with xorg and so on 
(currently, only the xorg metapackages and fluxbox are added). In order 
to build one, you need a local dir with the pkgsrc binary packages (see 
below).

The following commands should then do the trick:

cd /usr/src
make buildworld
make buildkernel
cd nrelease
patch -p 0 </path/to/the/patch
make PKGSRC_PKG_PATH=/path/to/packages/dir/All realquick gui
The resulting ISO will be in /usr/release/dfly-gui.iso then. It will not 
boot into xorg automatically (although this is easily possible), so you 
need to login as root and do startx.

As of now, this all is kind of basic, more a proof of concept than 
anything else. As our release framework installs packages via chroot, 
the current setup just copies _all_ packages to the chroot before 
installing (kind of a hack).

That said, I'm now primarily interested in opinions/ideas/... about the 
direction this should take. Which packages would we like to see on the 
CD? Should it be a generic setup with the "most common things" 
installed, so a system can be quickly setup by the installer (which will 
cpdup /usr/pkg). Or should it be a more specialized set of tools? Or 
even as many packages as possible (Live DVD?). Etc., etc.

Before continuing on it, I'm really interested in people's input so 
don't hold anything back, please. :)

Sascha

--
http://yoyodyne.ath.cx



From rluciani at gmail.com  Thu Mar  6 06:42:03 2008
From: rluciani at gmail.com (Robert Luciani)
Date: Thu, 06 Mar 2008 15:42:03 +0100
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <47d002bc$0$847$415eb37d@crater_reader.dragonflybsd.org>

Sascha Wildner wrote:
> Hi all,
> 
> this is probably as good a moment as any to come out of the forest with
> this. The patch at
> 
> http://leaf.dragonflybsd.org/~swildner/nrelease_gui.diff
> 
> adds some code to nrelease/ to build a LiveCD with xorg and so on
> (currently, only the xorg metapackages and fluxbox are added). In order
> to build one, you need a local dir with the pkgsrc binary packages (see
> below).
> 
> The following commands should then do the trick:
> 
> cd /usr/src
> make buildworld
> make buildkernel
> cd nrelease
> patch -p 0 </path/to/the/patch
> make PKGSRC_PKG_PATH=/path/to/packages/dir/All realquick gui
> 
> The resulting ISO will be in /usr/release/dfly-gui.iso then. It will not
> boot into xorg automatically (although this is easily possible), so you
> need to login as root and do startx.
> 
> As of now, this all is kind of basic, more a proof of concept than
> anything else. As our release framework installs packages via chroot,
> the current setup just copies _all_ packages to the chroot before
> installing (kind of a hack).
> 
> That said, I'm now primarily interested in opinions/ideas/... about the
> direction this should take. Which packages would we like to see on the
> CD? Should it be a generic setup with the "most common things"
> installed, so a system can be quickly setup by the installer (which will
> cpdup /usr/pkg). Or should it be a more specialized set of tools? Or
> even as many packages as possible (Live DVD?). Etc., etc.
> 
> Before continuing on it, I'm really interested in people's input so
> don't hold anything back, please. :)
> 
> Sascha
> 

I think the main point of such a live-cd would be to test
dragonfly-specific features such as vkernels and more. Mplayer and
OpenOffic work the same on all platforms, so they might not be super
important, while irssi, firefox, networking tools, vim, a few more
shells/terminals might make it easier to for people to quickly gauge if
they can reproduce their current productivity and also what is new.

And if the point of a livecd is to test that kind of stuff, then it
would be nice for it to have a kernel that supports as much as possible
like ALTQ, and drivers.

Also if it has lots and lots of programs (thinking multimedia, java,
etc..) it might be hard to keep the future x64 and x86 live-cds on par.
Gentoo had this problem many years ago and it was very bothersome.

-- 
Robert Luciani
Chalmers University of Technology, SWE
Department of Computer Science and Engineering
http://www.rluciani.com/public.key




From matthias at dragonflybsd.org  Thu Mar  6 07:12:43 2008
From: matthias at dragonflybsd.org (Matthias Schmidt)
Date: Thu, 6 Mar 2008 07:12:43 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <20080306150757.GN9833@staatsfeind.org>

* Sascha Wildner wrote:
> Hi all,
> 
> this is probably as good a moment as any to come out of the forest with this. 
> The patch at
> 
> http://leaf.dragonflybsd.org/~swildner/nrelease_gui.diff
> 
> adds some code to nrelease/ to build a LiveCD with xorg and so on (currently, 
> only the xorg metapackages and fluxbox are added). In order to build one, you 
> need a local dir with the pkgsrc binary packages (see below).

Great work Sascha.

I agree with Robert on most of his stated points.
It would be nice to see some DragonFly specific features on the CD
(although I'm not sure if that will work for all features).  A little
environment where most Unix users feel at home (fluxbox, xfce, firefox,
thunderbird, gvim) should be enough.

Big applications like OO.org, java etc won't work because they are not
available as pkgsrc packages neither is it possible to compile them on
DragonFly.  At least to my knowledge.

Regards

	Matthias




From dillon at apollo.backplane.com  Thu Mar  6 09:31:52 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Thu, 6 Mar 2008 09:31:52 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <200803061728.m26HSR3O091809@apollo.backplane.com>


:Hi all,
:
:this is probably as good a moment as any to come out of the forest with 
:this. The patch at
:
:http://leaf.dragonflybsd.org/~swildner/nrelease_gui.diff
:
:adds some code to nrelease/ to build a LiveCD with xorg and so on 
:(currently, only the xorg metapackages and fluxbox are added). In order 
:to build one, you need a local dir with the pkgsrc binary packages (see 
:below).
:
:The following commands should then do the trick:

    It looks reasonable, though the package copy has to be tightened
    up a bit I think.

:...
:installed, so a system can be quickly setup by the installer (which will 
:cpdup /usr/pkg). Or should it be a more specialized set of tools? Or 
:even as many packages as possible (Live DVD?). Etc., etc.
:
:Before continuing on it, I'm really interested in people's input so 
:don't hold anything back, please. :)
:
:Sascha

    I think this is an excellent time to work up a DVD build and to
    add various 'flavor' extras.  So, e.g.:

	make installer gui gui_extras release dvd

    (All 'dvd' would do is generate a dvd compatible image for burning to
    dvd instead of cd).  I did a quick perusal of what I have on my
    workstation:

    * X
    * Firefox
    * Linux emulation
    * Open Office (linux version)
    * fvwm2
    * xpdf
    * freetype2

    I'd also suggest some image editing tools like gimp, and maybe the KDE
    gui suite.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From justin at shiningsilence.com  Thu Mar  6 09:42:44 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Thu, 6 Mar 2008 09:42:44 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <55427.65.106.147.226.1204825168.squirrel@www.shiningsilence.com>

On Thu, March 6, 2008 8:34 am, Sascha Wildner wrote:

> That said, I'm now primarily interested in opinions/ideas/... about the
> direction this should take. Which packages would we like to see on the
> CD? Should it be a generic setup with the "most common things"
> installed, so a system can be quickly setup by the installer (which will
> cpdup /usr/pkg). Or should it be a more specialized set of tools? Or
> even as many packages as possible (Live DVD?). Etc., etc.

What Robert said is good - whatever's needed to enable DragonFly-specific
features.  Along with that would be some sort of documentation (a README? 
A HTML file on whatever desktop we provide) that points people at the
different DragonFly tools, so they know what to try and how to try it.

There's going to be some percentage of people who try DragonFly who don't
know about vkernels, for instance, but there's our chance to educate them.
 I'm probably volunteering myself, aren't I?





From sdavtaker at gmail.com  Thu Mar  6 09:50:09 2008
From: sdavtaker at gmail.com (=?UTF-8?Q?Sd=C3=A4vtaker?=)
Date: Thu, 6 Mar 2008 09:50:09 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <c37d69f60803060947t110750c0sd6b542ea505d188d@mail.gmail.com>

Cool Sascha :-)
I just posted about this 1 or 2 days ago in the SOC project ideas thread.
Want to mentor this one? ;-)
Damian

On Thu, Mar 6, 2008 at 2:28 PM, Matthew Dillon
<dillon at apollo.backplane.com> wrote:
>
>  :Hi all,
>
> :
>  :this is probably as good a moment as any to come out of the forest with
>  :this. The patch at
>  :
>  :http://leaf.dragonflybsd.org/~swildner/nrelease_gui.diff
>  :
>  :adds some code to nrelease/ to build a LiveCD with xorg and so on
>  :(currently, only the xorg metapackages and fluxbox are added). In order
>  :to build one, you need a local dir with the pkgsrc binary packages (see
>  :below).
>  :
>  :The following commands should then do the trick:
>
>     It looks reasonable, though the package copy has to be tightened
>     up a bit I think.
>
>  :...
>  :installed, so a system can be quickly setup by the installer (which will
>
> :cpdup /usr/pkg). Or should it be a more specialized set of tools? Or
>  :even as many packages as possible (Live DVD?). Etc., etc.
>  :
>  :Before continuing on it, I'm really interested in people's input so
>  :don't hold anything back, please. :)
>  :
>  :Sascha
>
>     I think this is an excellent time to work up a DVD build and to
>     add various 'flavor' extras.  So, e.g.:
>
>         make installer gui gui_extras release dvd
>
>     (All 'dvd' would do is generate a dvd compatible image for burning to
>     dvd instead of cd).  I did a quick perusal of what I have on my
>     workstation:
>
>     * X
>     * Firefox
>     * Linux emulation
>     * Open Office (linux version)
>     * fvwm2
>     * xpdf
>     * freetype2
>
>     I'd also suggest some image editing tools like gimp, and maybe the KDE
>     gui suite.
>
>                                         -Matt
>                                         Matthew Dillon
>                                         <dillon at backplane.com>
>



-- 
Sd?vtaker prays to Rikku goddess for a good treasure.



From saw at online.de  Thu Mar  6 11:54:01 2008
From: saw at online.de (Sascha Wildner)
Date: Thu, 06 Mar 2008 20:54:01 +0100
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <47d04ba2$0$856$415eb37d@crater_reader.dragonflybsd.org>

Matthew Dillon wrote:
    It looks reasonable, though the package copy has to be tightened
    up a bit I think.
It looks as if it would work with mount_null'ing the chroot's 
/tmp/packages. I'll have a better patch ready tomorrow.

Sascha

--
http://yoyodyne.ath.cx



From c.turner at 199technologies.org  Thu Mar  6 19:11:44 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Thu, 6 Mar 2008 19:11:44 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Misc. ACPI / suspend
In-Reply-To: <47CA073B.6020106@199technologies.org>
Message-ID: <47D0B079.3060905@199technologies.org>

Chris Turner wrote:
Wondering if anyone more well versed in the ACPI implementation could
comment on the applicability of:
http://lkml.org/lkml/2007/4/6/69

Doing a little digging, it seems like

. /platform/pc32/i386/i686_mem.c

*might* have the necessary infrastructure to remap the MTRR's per the 
thread referenced,

but:

. /platform/pc32/acpica5/acpi_wakeup.c

doesn't seem to be using this infrastructure..

I'm no where near reaching an understanding of this yet,
but I'm wondering 3 things:
1) does anyone have ACPI (instead of APM)
   sleep / suspend / wakeup working on Dfly ?
2) If so, what machines are being used ?
3) Same question for other BSDs - my understanding is NetBSD is most
   'advanced' w/r/t power managment - but I'm not 100% on this ...
would looove to have a sleeping / resuming / scaling laptop running some 
BSD flavor.. am willing to work towards that end, esp. w/r/t Dfly -
trying to chart a course to figguring this out.

Thanks all,

- Chris




From c.turner at 199technologies.org  Thu Mar  6 19:12:33 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Thu, 6 Mar 2008 19:12:33 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: PCI Bios / Interrupt remapping / etc
Message-ID: <47D0B211.6000002@199technologies.org>

Doing a bit of digging here for my long-standing CBB+SIO interupt and 
buffer problem -

one machine I've tested against was an OpenBSD machine, which didn't
always work to handle the cardbus sio card on a PCI cardbus adapter
-

tuning up some of the device flags in:

http://www.openbsd.org/cgi-bin/man.cgi?query=pcibios&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=html

seems to have alleviated the problem for that os..

I'm just only starting to get up to speed on how DF handles these types 
of things (namely initial PIC / interrupt layout at boot time device 
enumeration), but am wondering if anyone familiar with this area of the 
code has any comments / advice w/r/t the capabilities of the DF bios 
drivers
and the various quirks / fixup mentioned in the link above..

looking to possibly investigate fixing up some of these issues over time.

Thanks

- Chris







From pavalos at theshell.com  Fri Mar  7 01:14:55 2008
From: pavalos at theshell.com (Peter Avalos)
Date: Fri, 7 Mar 2008 01:14:55 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: cam locking
Message-ID: <20080307091024.GC1652@ylem.theshell.com>

So I've been working on locking up cam using lockmgr locks, and here's
what I have so far:

http://www.theshell.com/~pavalos/wip/cam-lock.patch

Most of the work is obtained from FreeBSD.  I've only been running this
on my SCSI machine for a day, but because the patch is so large, I wanted
to make it available for people to review if they have some spare time.

Thanks,
Peter
Attachment:
pgp00002.pgp
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00002.pgp
Type: application/octet-stream
Size: 197 bytes
Desc: "Description: PGP signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080307/9a17ecd8/attachment-0011.obj>

From jspringe at uos.de  Fri Mar  7 03:25:17 2008
From: jspringe at uos.de (Jost Tobias Springenberg)
Date: Fri, 7 Mar 2008 12:25:17 +0100
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <20080307122517.72c9e2b1.jspringe@uos.de>

On Tue, 4 Mar 2008 11:28:15 -0500 (EST)
"Justin C. Sherrill" <justin at shiningsilence.com> wrote:

> On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
> > Hi,
> >
> > Google just announced its Summer of Code for 2008:
> >
> > 	http://code.google.com/soc/2008/
> >
> > I think this would be a great opportunity for DragonFly to participate
> > as a mentoring organisation.  We could attract new developers and could
> > get code/work done.  Looking at the SoC results of the other BSDs most
> > of their projects were a success.  Of course, not all, but a reasonable
> > percentage.  See [1] and [2].
> 
> We've applied in previous years - Jeff Hsu did one year, and I put
> together the application last year.  The hardest thing to find was
> students (and they are the thing that helps SoC applications a lot, I
> think).
> 
> Any student volunteers?  We have mentors.
> 

I read this mailing list for quite a while now and thought about contributing stuff
to DFfly several times, so yes why not take this opportunity if it's there.

-- 
Jost Tobias Springenberg <jspringe at uos.de>




From tgen at netphreax.net  Fri Mar  7 05:17:27 2008
From: tgen at netphreax.net (Thomas E. Spanjaard)
Date: Fri, 7 Mar 2008 05:17:27 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: PCI Bios / Interrupt remapping / etc
In-Reply-To: <47D0B211.6000002@199technologies.org>
Message-ID: <47D13FB4.5080306@netphreax.net>

Chris Turner wrote:
Doing a bit of digging here for my long-standing CBB+SIO interupt and 
buffer problem -

one machine I've tested against was an OpenBSD machine, which didn't
always work to handle the cardbus sio card on a PCI cardbus adapter
-

tuning up some of the device flags in:

http://www.openbsd.org/cgi-bin/man.cgi?query=pcibios&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=html 

seems to have alleviated the problem for that os..

I'm just only starting to get up to speed on how DF handles these types 
of things (namely initial PIC / interrupt layout at boot time device 
enumeration), but am wondering if anyone familiar with this area of the 
code has any comments / advice w/r/t the capabilities of the DF bios 
drivers
and the various quirks / fixup mentioned in the link above..

looking to possibly investigate fixing up some of these issues over time.
Our code that handles issues like this (in cases where you're not using 
APICs, just PICs and PIRs) lives in bus/pci/i386/. Not that running 
without APIC support is all that common on modern machines anymore...
--
        Thomas E. Spanjaard
        tgen at netphreax.net
Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00003.pgp
Type: application/octet-stream
Size: 186 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080307/61366b5c/attachment-0011.obj>

From tgen at netphreax.net  Fri Mar  7 05:16:51 2008
From: tgen at netphreax.net (Thomas E. Spanjaard)
Date: Fri, 7 Mar 2008 05:16:51 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Misc. ACPI / suspend
In-Reply-To: <47CA073B.6020106@199technologies.org>
Message-ID: <47D13F07.9080308@netphreax.net>

Chris Turner wrote:
1) does anyone have ACPI (instead of APM)
   sleep / suspend / wakeup working on Dfly ?
2) If so, what machines are being used ?
3) Same question for other BSDs - my understanding is NetBSD is most
   'advanced' w/r/t power managment - but I'm not 100% on this ...
would looove to have a sleeping / resuming / scaling laptop running some 
BSD flavor.. am willing to work towards that end, esp. w/r/t Dfly -
trying to chart a course to figguring this out.
I have ACPI S3 suspend working like a charm on my IBM ThinkPad R40 
(Pentium M "Banias" 1.3GHz, speedstepping works just fine), running 
NetBSD 3.99.21.
--
        Thomas E. Spanjaard
        tgen at netphreax.net
Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00004.pgp
Type: application/octet-stream
Size: 186 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080307/de3e5104/attachment-0011.obj>

From civilizd at gmail.com  Fri Mar  7 09:06:41 2008
From: civilizd at gmail.com (Vita "CiV" Cizek)
Date: Fri, 7 Mar 2008 09:06:41 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <98d564710803070853q1c73d795m6e6c5cc5049fa099@mail.gmail.com>

>  Any student volunteers?  We have mentors.
>
I am interested too, especially in some kernel-related work.




From justin at shiningsilence.com  Sat Mar  8 12:07:51 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Sat, 8 Mar 2008 12:07:51 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google SoC 2008 - mentors mentors mentors
Message-ID: <51558.192.168.0.252.1205006403.squirrel@www.shiningsilence.com>

If you are willing to mentor for the Google 2008 Summer of Code, please
speak up.  Right now we have: (from our wiki page)

Matthias
Sephe
TGEN
corecode

Part of the application process includes naming people as mentors (student
applications come later), so I want to get as complete a list as possible.

The application is due on the 12th, so if you want to mentor, now's the
time to say so.

Google's SoC FAQ is here: http://code.google.com/soc/2008/faqs.html

Our wiki page is here: http://wiki.dragonflybsd.org/index.cgi/GoogleSoC2008

- much credit to Matthias and others for getting that set up.





From saw at online.de  Sat Mar  8 14:26:07 2008
From: saw at online.de (Sascha Wildner)
Date: Sat, 08 Mar 2008 23:26:07 +0100
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <47d31245$0$848$415eb37d@crater_reader.dragonflybsd.org>

Sascha Wildner wrote:
Hi all,

this is probably as good a moment as any to come out of the forest with 
this. The patch at

http://leaf.dragonflybsd.org/~swildner/nrelease_gui.diff
Ok, I have committed the stuff as an example.

I'm not sure if my free time permits to work on a full-blown live CD 
with X11 and other good things (I already feel my interest wandering off 
in other directions) so if anyone wants to pick up the ball, go ahead. :)

Sascha

--
http://yoyodyne.ath.cx



From qhwt+dfly at les.ath.cx  Tue Mar 11 22:21:31 2008
From: qhwt+dfly at les.ath.cx (YONETANI Tomokazu)
Date: Tue, 11 Mar 2008 22:21:31 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Misc. ACPI / suspend
In-Reply-To: <47CA073B.6020106@199technologies.org>
Message-ID: <20080312051219.GA56091@les.ath.cx>

On Thu, Mar 06, 2008 at 10:03:21PM -0500, Chris Turner wrote:
> 1) does anyone have ACPI (instead of APM)
>    sleep / suspend / wakeup working on Dfly ?
> 2) If so, what machines are being used ?

Dynabook SS3500 (http://www.tlt.co.jp/pc/catalog/ss/02110735/index_j.htm).
It's old and can get very hot(thus frequently turns on the cooling fan)
even when it's running Windows.  I haven't turned it on for about several
months though.

Cheers.




From c.turner at 199technologies.org  Wed Mar 12 04:37:22 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Wed, 12 Mar 2008 04:37:22 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Misc. ACPI / suspend
In-Reply-To: <47CA073B.6020106@199technologies.org>
Message-ID: <47D7BEE3.6010907@199technologies.org>

YONETANI Tomokazu wrote:
On Thu, Mar 06, 2008 at 10:03:21PM -0500, Chris Turner wrote:
1) does anyone have ACPI (instead of APM)
   sleep / suspend / wakeup working on Dfly ?
Cheers.
ditto..

Suppose this should go to docs@ - in any case..

Thinking about setting up a wiki page on the issue so we
can discuss / track what 'good' hardware / drivers / implementations / 
etc are 'out there' - anyone have any suggestions on where this should
go?

http://wiki.dragonflybsd.org/index.cgi/acpi-overview.html

Remains from the handbook conversion - but I'm hesitant to 'over wikify'
this ..



From c.turner at 199technologies.org  Wed Mar 12 15:36:52 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Wed, 12 Mar 2008 15:36:52 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: devel/cscope
Message-ID: <47D85A08.8040103@199technologies.org>

why oh why did I take so long to try this out !!!

just sharing my eureka moment with the list..

- Chris




From dudu at dudu.ro  Wed Mar 12 15:50:14 2008
From: dudu at dudu.ro (Vlad GALU)
Date: Wed, 12 Mar 2008 15:50:14 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: devel/cscope
In-Reply-To: <47D85A08.8040103@199technologies.org>
Message-ID: <ad79ad6b0803121547r2bf67ffep9e40badaac6490f8@mail.gmail.com>

On 3/13/08, Chris Turner <c.turner at 199technologies.org> wrote:
> why oh why did I take so long to try this out !!!
>
>  just sharing my eureka moment with the list..


    Works nice with vim, too!

>
>
>  - Chris
>


-- 
Mahnahmahnah!




From justin at shiningsilence.com  Sun Mar 16 21:06:13 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Sun, 16 Mar 2008 21:06:13 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: binary packages for 1.12 coming in
Message-ID: <1372.192.168.0.252.1205726088.squirrel@www.shiningsilence.com>

The binary build for 1.12 is taking quite a while.  I've started copying
in newly built packages to
pkgbox.dragonflybsd.org/packages/DragonFly-1.12/i386/ - this should be
getting copied out to mirrors over the next while.

There are currently 1283 packages built, which leaves a whole lot to go;
I'll copy new packages in as they complete.





From hasso at estpak.ee  Wed Mar 19 04:31:08 2008
From: hasso at estpak.ee (Hasso Tepper)
Date: Wed, 19 Mar 2008 04:31:08 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Some questions regarding ACPI
Message-ID: <200803191322.46366.hasso@estpak.ee>

I'm working on bringing in some laptop (and especially thinkpad) specific 
ACPI code from FreeBSD into DragonFly. I never touched ACPI stuff before 
and haven't followed it much either, so I have some questions.

* FreeBSD uses ACPI_SERIAL_* heavily. What's the locking situation in 
  DragonFly and why?

* As far as I can see, PCI integration is commented out in DragonFly. 
  What's the state of it and why?

* platform/pc32/acpica5/acpi_toshiba.c - why is it there? I don't think 
  that this is something pc32 specific in it and it should work in pc64 
  laptops as well. Any objections to move it into 
  dev/acpica5/acpi_toshiba/ ?

What's the current status of ACPI in general? AFAICS our acpica is quite 
old - what needs to be done to bring in newer one?


-- 
Hasso




From qhwt+dfly at les.ath.cx  Wed Mar 19 09:24:50 2008
From: qhwt+dfly at les.ath.cx (YONETANI Tomokazu)
Date: Wed, 19 Mar 2008 09:24:50 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Some questions regarding ACPI
In-Reply-To: <200803191322.46366.hasso@estpak.ee>
Message-ID: <20080319161703.GA51509@les.ath.cx>

On Wed, Mar 19, 2008 at 01:22:46PM +0200, Hasso Tepper wrote:
> I'm working on bringing in some laptop (and especially thinkpad) specific 
> ACPI code from FreeBSD into DragonFly. I never touched ACPI stuff before 
> and haven't followed it much either, so I have some questions.

So you want to port some of ACPI support drivers, or to do a fresh port
of ACPI driver from FreeBSD?

> * FreeBSD uses ACPI_SERIAL_* heavily. What's the locking situation in 
>   DragonFly and why?

The current ACPI driver in DragonFly is based on that of FreeBSD as of
end of June, 2004, plus some fixes brought in later (and ACPICA part
has been updated twice since then).  That was before they introduced
the MPSAFE changes into ACPI code, and we use critical section
(crit_{enter,exit}) in most places (and lockmgr lock in a few place).

> * As far as I can see, PCI integration is commented out in DragonFly. 
>   What's the state of it and why?

When we replaced the implementation taken from FreeBSD 4.x with that
brought from FreeBSD 5.x, which added the PCI part, many people
experienced problems until they turned off ACPI completely, or add "pci"
to "debug.acpi.disabled" loader variable.  AFAIK the PCI part in the ACPI
driver almost hasn't been adjusted to work with our version of PCI code.

> * platform/pc32/acpica5/acpi_toshiba.c - why is it there? I don't think 
>   that this is something pc32 specific in it and it should work in pc64 
>   laptops as well. Any objections to move it into 
>   dev/acpica5/acpi_toshiba/ ?

In FreeBSD it used to be sitting at i386/acpica/acpi_toshiba.c and was
later moved into acpi_support.  That change hasn't hit our tree (in fact,
we have no acpi support drivers other than that).  It seems that FreeBSD
has them in dev/acpi_support now, and we for some reason have that
directory in our CVS repository (but containing no files in it).

> What's the current status of ACPI in general? AFAICS our acpica is quite 
> old - what needs to be done to bring in newer one?

Actually, it's not very important to keep just ACPICA latest, but
if you bring the ACPI driver from FreeBSD you need to bring ACPICA code
that matches their version, and it IS important.  And it generally requires
you much work to just update ACPICA part anyway because of how they
change things on every release.

Cheers.




From hasso at estpak.ee  Wed Mar 19 12:29:52 2008
From: hasso at estpak.ee (Hasso Tepper)
Date: Wed, 19 Mar 2008 12:29:52 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Some questions regarding ACPI
In-Reply-To: <200803191322.46366.hasso@estpak.ee>
Message-ID: <200803192115.35396.hasso@estpak.ee>

YONETANI Tomokazu wrote:
> On Wed, Mar 19, 2008 at 01:22:46PM +0200, Hasso Tepper wrote:
> > I'm working on bringing in some laptop (and especially thinkpad)
> > specific ACPI code from FreeBSD into DragonFly. I never touched ACPI
> > stuff before and haven't followed it much either, so I have some
> > questions.
>
> So you want to port some of ACPI support drivers, or to do a fresh port
> of ACPI driver from FreeBSD?

I'm only interested in support drivers and the reason is pure practical - 
newer thinkpads handle less and less hotkeys etc in hardware and require 
support form OS. acpi_ibm and acpi_video are examples of such modules 
which would help a lot of these newer thinkpad users.

acpi_ibm is almost ready to commit (renamed to acpi_thinkpad though).

> > * FreeBSD uses ACPI_SERIAL_* heavily. What's the locking situation in
> >   DragonFly and why?
>
> The current ACPI driver in DragonFly is based on that of FreeBSD as of
> end of June, 2004, plus some fixes brought in later (and ACPICA part
> has been updated twice since then).  That was before they introduced
> the MPSAFE changes into ACPI code, and we use critical section
> (crit_{enter,exit}) in most places (and lockmgr lock in a few place).

Mkay. Will look at more closely.

> > * As far as I can see, PCI integration is commented out in DragonFly.
> >   What's the state of it and why?
>
> When we replaced the implementation taken from FreeBSD 4.x with that
> brought from FreeBSD 5.x, which added the PCI part, many people
> experienced problems until they turned off ACPI completely, or add
> "pci" to "debug.acpi.disabled" loader variable.  AFAIK the PCI part in
> the ACPI driver almost hasn't been adjusted to work with our version of
> PCI code.

I'm afraid that it's beyond my skills, but while looking at acpi_video I 
discovered that it's hard to handle correctly without PCI support.

> > * platform/pc32/acpica5/acpi_toshiba.c - why is it there? I don't
> > think that this is something pc32 specific in it and it should work
> > in pc64 laptops as well. Any objections to move it into
> >   dev/acpica5/acpi_toshiba/ ?
>
> In FreeBSD it used to be sitting at i386/acpica/acpi_toshiba.c and was
> later moved into acpi_support.  That change hasn't hit our tree (in
> fact, we have no acpi support drivers other than that).  It seems that
> FreeBSD has them in dev/acpi_support now, and we for some reason have
> that directory in our CVS repository (but containing no files in it).

I don't see it ;). Makes sense though. So, any objections if I move 
acpi_toshiba into sys/dev/acpi_support and add new acpi_thinkpad there as 
well? 

> > What's the current status of ACPI in general? AFAICS our acpica is
> > quite old - what needs to be done to bring in newer one?
>
> Actually, it's not very important to keep just ACPICA latest, but
> if you bring the ACPI driver from FreeBSD you need to bring ACPICA code
> that matches their version, and it IS important.  And it generally
> requires you much work to just update ACPICA part anyway because of how
> they change things on every release.

Someone else has to do it :).

Thanks for info.


-- 
Hasso




From dillon at apollo.backplane.com  Wed Mar 19 14:01:13 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Wed, 19 Mar 2008 14:01:13 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: panic: assertion: hammer_btree_cmp(cursor->left_bound,	&cursor->node->ondisk->elms[0].leaf.base) <= 0 in btree_split_leaf
In-Reply-To: <200802232204.m1NM4cxd046264@apollo.backplane.com>
Message-ID: <200803192054.m2JKsjwn045137@apollo.backplane.com>


:Hi.
:While trying to find a procedure to reliably reproduce the panic
:I reported last time, I caught a different panic (uploaded at
: ~y0netan1/crash/9/ on my leaf account).  I wrote the following shell
:script (make sure to edit variables DISKS and MOUNTPT before using this
:script or it may trash your system):
:  #!/bin/sh -ex
:  DISKS="/dev/ad0s1f"
:  MOUNTPT=/mnt/HAMMER
:
:  cd /
:  newfs_hammer -L TEST $DISKS
:  for i in `seq 1 100`; do
:..
:And the panic is triggered by rm command.
:I'll try to see if it's possible to reproduce the last one without
:unmounting then mounting the HAMMER fs.
:
:Cheers.

    I believe I have fixed this panic.  hammer_make_separator() had a bug
    in it.

    There is still an issue with the node ref count on umount.

    Please continue to life-test the code.  The reblocking code
    (hammer reblock /mnt) should work now, as should the pruning code
    (e.g. hammer prune /mnt everything).

    The filesystem full case is still not handled and will cause bad things
    to happen.  The undo code isn't finished yet either but it is getting
    there (it's writing stuff out but not setting the sequence number and
    not trying to recover-on-mount yet).

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From qhwt+dfly at les.ath.cx  Wed Mar 19 19:45:40 2008
From: qhwt+dfly at les.ath.cx (YONETANI Tomokazu)
Date: Wed, 19 Mar 2008 19:45:40 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Some questions regarding ACPI
In-Reply-To: <200803191322.46366.hasso@estpak.ee>
Message-ID: <20080320023828.GA53648@les.ath.cx>

On Wed, Mar 19, 2008 at 09:15:35PM +0200, Hasso Tepper wrote:
> YONETANI Tomokazu wrote:
> > On Wed, Mar 19, 2008 at 01:22:46PM +0200, Hasso Tepper wrote:
> > > I'm working on bringing in some laptop (and especially thinkpad)
> > > specific ACPI code from FreeBSD into DragonFly. I never touched ACPI
> > > stuff before and haven't followed it much either, so I have some
> > > questions.
> >
> > So you want to port some of ACPI support drivers, or to do a fresh port
> > of ACPI driver from FreeBSD?
> 
> I'm only interested in support drivers and the reason is pure practical - 
> newer thinkpads handle less and less hotkeys etc in hardware and require 
> support form OS. acpi_ibm and acpi_video are examples of such modules 
> which would help a lot of these newer thinkpad users.
> 
> acpi_ibm is almost ready to commit (renamed to acpi_thinkpad though).

Ah, that's a good news!  My only concern is that ISTR someone mentioned
me that his colleague was thinking about porting ACPI driver itself,
so if you're not the person you may want to collaborate with him/her
so as not to waste the effort or time...

			:

> > In FreeBSD it used to be sitting at i386/acpica/acpi_toshiba.c and was
> > later moved into acpi_support.  That change hasn't hit our tree (in
> > fact, we have no acpi support drivers other than that).  It seems that
> > FreeBSD has them in dev/acpi_support now, and we for some reason have
> > that directory in our CVS repository (but containing no files in it).
> 
> I don't see it ;). Makes sense though. So, any objections if I move 
> acpi_toshiba into sys/dev/acpi_support and add new acpi_thinkpad there as 
> well? 

Sorry, I checked the CVS repository and it doesn't exist actually :)
I don't have any objection to moving it there.

Cheers.




From hasso at estpak.ee  Thu Mar 20 00:14:05 2008
From: hasso at estpak.ee (Hasso Tepper)
Date: Thu, 20 Mar 2008 00:14:05 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Some questions regarding ACPI
In-Reply-To: <200803191322.46366.hasso@estpak.ee>
Message-ID: <200803200904.50875.hasso@estpak.ee>

YONETANI Tomokazu wrote:
> On Wed, Mar 19, 2008 at 09:15:35PM +0200, Hasso Tepper wrote:
> > acpi_ibm is almost ready to commit (renamed to acpi_thinkpad though).
>
> Ah, that's a good news!  My only concern is that ISTR someone mentioned
> me that his colleague was thinking about porting ACPI driver itself,
> so if you're not the person you may want to collaborate with him/her
> so as not to waste the effort or time...

Current state in my repo is attached. It should work on 1.12 as well as it 
doesn't depend yet on moving stuff around.

add-acpi-if-m.patch adds some new stuff to the ACPI code to access 
embedded controllers and match ACPI devices by ID. Not sure how, where 
and whether at all these should be documented.

add-acpi-thinkpad.patch is the driver itself. Note that some stuff doesn't 
work yet on newer thinkpads, I plan to work on it later.

There is still some things to do though. I have to decide what to do with 
led(4) part and with locking. There is also one fatal issue - laptop 
locks up hardly (no panic) while unloading module. Any idea regarding 
this is welcome. And of course test results :).


-- 
Hasso
# HG changeset patch
# User Hasso Tepper <hasso at estpak.ee>
# Date 1205919290 -7200
# Branch HEAD
# Node ID 5a6e2705cc95a340abf973ae5df73ef34e070b79
# Parent  cd529e2e7f849034d5d5a0973cb98af50db0e797
imported patch adding-acpi-if-m.patch

diff --git a/sys/conf/files b/sys/conf/files
--- a/sys/conf/files
+++ b/sys/conf/files
@@ -1387,6 +1387,7 @@ emulation/dragonfly12/dfbsd12_stat.c	non
 ${OSACPI_MI_DIR}/acpi_cmbat.c		optional acpi
 ${OSACPI_MI_DIR}/acpi_cpu.c		optional acpi
 ${OSACPI_MI_DIR}/acpi_ec.c		optional acpi
+${OSACPI_MI_DIR}/acpi_if.m		optional acpi
 ${OSACPI_MI_DIR}/acpi_isab.c		optional acpi isa
 ${OSACPI_MI_DIR}/acpi_lid.c		optional acpi
 ${OSACPI_MI_DIR}/acpi_package.c		optional acpi
diff --git a/sys/conf/kmod.mk b/sys/conf/kmod.mk
--- a/sys/conf/kmod.mk
+++ b/sys/conf/kmod.mk
@@ -275,7 +275,7 @@ MFILES?= kern/bus_if.m kern/device_if.m 
     bus/pccard/card_if.m bus/pccard/power_if.m bus/pci/pci_if.m \
     bus/pci/pcib_if.m \
     bus/ppbus/ppbus_if.m bus/smbus/smbus_if.m bus/usb/usb_if.m \
-    dev/disk/nata/ata_if.m \
+    dev/acpica5/acpi_if.m dev/disk/nata/ata_if.m \
     dev/sound/pcm/ac97_if.m dev/sound/pcm/channel_if.m \
     dev/sound/pcm/feeder_if.m dev/sound/pcm/mixer_if.m \
     libiconv/iconv_converter_if.m dev/agp/agp_if.m opencrypto/crypto_if.m
diff --git a/sys/dev/acpica5/Makefile b/sys/dev/acpica5/Makefile
--- a/sys/dev/acpica5/Makefile
+++ b/sys/dev/acpica5/Makefile
@@ -69,12 +69,14 @@ SRCS+=  acpi_package.c
 # SRCS+=	acpi_pci.c acpi_pcib.c acpi_pcib_acpi.c acpi_pcib_pci.c
 # SRCS+=	acpi_pci_link.c
 SRCS+=  acpi_powerres.c acpi_resource.c acpi_thermal.c
-SRCS+=  acpi_timer.c
+SRCS+=  acpi_timer.c acpi_if.c
 SRCS+=  OsdDebug.c
 SRCS+=  OsdHardware.c OsdInterface.c OsdInterrupt.c OsdMemory.c OsdSchedule.c
 SRCS+=  OsdStream.c OsdSynch.c OsdTable.c OsdEnvironment.c
 SRCS+=  opt_acpi.h opt_bus.h opt_ddb.h
-SRCS+=  device_if.h bus_if.h pci_if.h pcib_if.h isa_if.h
+SRCS+=  device_if.h bus_if.h pci_if.h pcib_if.h isa_if.h acpi_if.h
+MFILES = kern/device_if.m kern/bus_if.m bus/pci/pci_if.m bus/pci/pcib_if.m
+MFILES+= bus/isa/isa_if.m dev/acpica5/acpi_if.m
 
 # Debugging support
 DBSRC=	dbcmds.c dbdisply.c dbexec.c dbfileio.c dbhistry.c
diff --git a/sys/dev/acpica5/acpi.c b/sys/dev/acpica5/acpi.c
--- a/sys/dev/acpica5/acpi.c
+++ b/sys/dev/acpica5/acpi.c
@@ -135,6 +135,7 @@ static int	acpi_release_resource(device_
 			int rid, struct resource *r);
 static uint32_t	acpi_isa_get_logicalid(device_t dev);
 static int	acpi_isa_get_compatid(device_t dev, uint32_t *cids, int count);
+static char	*acpi_device_id_probe(device_t bus, device_t dev, char **ids);
 static int	acpi_isa_pnp_probe(device_t bus, device_t child,
 			struct isa_pnp_id *ids);
 static void	acpi_probe_children(device_t bus);
@@ -189,6 +190,9 @@ static device_method_t acpi_methods[] = 
     DEVMETHOD(bus_deactivate_resource,	bus_generic_deactivate_resource),
     DEVMETHOD(bus_setup_intr,		bus_generic_setup_intr),
     DEVMETHOD(bus_teardown_intr,	bus_generic_teardown_intr),
+
+    /* ACPI bus */
+    DEVMETHOD(acpi_id_probe,		acpi_device_id_probe),
 
     /* ISA emulation */
     DEVMETHOD(isa_pnp_probe,		acpi_isa_pnp_probe),
@@ -1121,6 +1125,24 @@ out:
 	AcpiOsFree(buf.Pointer);
     ACPI_UNLOCK;
     return_VALUE (valid);
+}
+
+static char *
+acpi_device_id_probe(device_t bus, device_t dev, char **ids) 
+{
+    ACPI_HANDLE h;
+    int i;
+
+    h = acpi_get_handle(dev);
+    if (ids == NULL || h == NULL || acpi_get_type(dev) != ACPI_TYPE_DEVICE)
+	return (NULL);
+
+    /* Try to match one of the array of IDs with a HID or CID. */
+    for (i = 0; ids[i] != NULL; i++) {
+	if (acpi_MatchHid(h, ids[i]))
+	    return (ids[i]);
+    }
+    return (NULL);
 }
 
 static int
diff --git a/sys/dev/acpica5/acpi_ec.c b/sys/dev/acpica5/acpi_ec.c
--- a/sys/dev/acpica5/acpi_ec.c
+++ b/sys/dev/acpica5/acpi_ec.c
@@ -327,11 +327,19 @@ static ACPI_STATUS	EcWrite(struct acpi_e
 				UINT8 *Data);
 static int		acpi_ec_probe(device_t dev);
 static int		acpi_ec_attach(device_t dev);
+static int		acpi_ec_read_method(device_t dev, u_int addr,
+				ACPI_INTEGER *val, int width);
+static int		acpi_ec_write_method(device_t dev, u_int addr,
+				ACPI_INTEGER val, int width);
 
 static device_method_t acpi_ec_methods[] = {
     /* Device interface */
     DEVMETHOD(device_probe,	acpi_ec_probe),
     DEVMETHOD(device_attach,	acpi_ec_attach),
+
+    /* Embedded controller interface */
+    DEVMETHOD(acpi_ec_read,     acpi_ec_read_method),
+    DEVMETHOD(acpi_ec_write,    acpi_ec_write_method),
 
     {0, 0}
 };
@@ -620,6 +628,33 @@ error:
 			     sc->ec_data_res);
     /* mtx_destroy(&sc->ec_mtx); */
     return (ENXIO);
+}
+
+/* Methods to allow other devices (e.g., smbat) to read/write EC space. */
+static int
+acpi_ec_read_method(device_t dev, u_int addr, ACPI_INTEGER *val, int width)
+{
+    struct acpi_ec_softc *sc;
+    ACPI_STATUS status;
+
+    sc = device_get_softc(dev);
+    status = EcSpaceHandler(ACPI_READ, addr, width * 8, val, sc, NULL);
+    if (ACPI_FAILURE(status))
+        return (ENXIO);
+    return (0);
+}
+
+static int
+acpi_ec_write_method(device_t dev, u_int addr, ACPI_INTEGER val, int width)
+{
+    struct acpi_ec_softc *sc;
+    ACPI_STATUS status;
+
+    sc = device_get_softc(dev);
+    status = EcSpaceHandler(ACPI_WRITE, addr, width * 8, &val, sc, NULL);
+    if (ACPI_FAILURE(status))
+        return (ENXIO);
+    return (0);
 }
 
 static void
diff --git a/sys/dev/acpica5/acpi_if.m b/sys/dev/acpica5/acpi_if.m
new file mode 100644
--- /dev/null
+++ b/sys/dev/acpica5/acpi_if.m
@@ -0,0 +1,92 @@
+#-
+# Copyright (c) 2004 Nate Lawson
+# All rights reserved.
+#
+# Redistribution and use in source and binary forms, with or without
+# modification, are permitted provided that the following conditions
+# are met:
+# 1. Redistributions of source code must retain the above copyright
+#    notice, this list of conditions and the following disclaimer.
+# 2. Redistributions in binary form must reproduce the above copyright
+#    notice, this list of conditions and the following disclaimer in the
+#    documentation and/or other materials provided with the distribution.
+#
+# THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
+# ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+# ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
+# FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+# DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+# OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+# HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+# LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+# OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+# SUCH DAMAGE.
+#
+# $DragonFly$
+#
+
+#include <sys/bus.h>
+#include <sys/types.h>
+#include "acpi.h"
+
+INTERFACE acpi;
+
+#
+# Default implementation for acpi_id_probe().
+#
+CODE {
+	static char *
+	acpi_generic_id_probe(device_t bus, device_t dev, char **ids)
+	{
+		return (NULL);
+	}
+};
+
+#
+# Check a device for a match in a list of ID strings.  The strings can be
+# EISA PNP IDs or ACPI _HID/_CID values.
+#
+# device_t bus:  parent bus for the device
+#
+# device_t dev:  device being considered
+#
+# char **ids:  array of ID strings to consider
+#
+# Returns:  ID string matched or NULL if no match
+#
+METHOD char * id_probe {
+	device_t	bus;
+	device_t	dev;
+	char		**ids;
+} DEFAULT acpi_generic_id_probe;
+
+#
+# Read embedded controller (EC) address space
+#
+# device_t dev:  EC device
+# u_int addr:  Address to read from in EC space
+# ACPI_INTEGER *val:  Location to store read value
+# int width:  Size of area to read in bytes
+#
+METHOD int ec_read {
+	device_t	dev;
+	u_int		addr;
+	ACPI_INTEGER	*val;
+	int		width;
+};
+
+#
+# Write embedded controller (EC) address space
+#
+# device_t dev:  EC device
+# u_int addr:  Address to write to in EC space
+# ACPI_INTEGER val:  Value to write
+# int width:  Size of value to write in bytes
+#
+METHOD int ec_write {
+	device_t	dev;
+	u_int		addr;
+	ACPI_INTEGER	val;
+	int		width;
+};
diff --git a/sys/dev/acpica5/acpivar.h b/sys/dev/acpica5/acpivar.h
--- a/sys/dev/acpica5/acpivar.h
+++ b/sys/dev/acpica5/acpivar.h
@@ -29,6 +29,7 @@
  * $DragonFly: src/sys/dev/acpica5/acpivar.h,v 1.12 2007/10/23 03:04:48 y0netan1 Exp $
  */
 
+#include "acpi_if.h"
 #include "bus_if.h"
 #include <sys/eventhandler.h>
 #include <sys/sysctl.h>
# HG changeset patch
# User Hasso Tepper <hasso at estpak.ee>
# Date 1205995474 -7200
# Branch HEAD
# Node ID c5db8d4a7c6b25a8576a8d42c5029aaf0e23bfb6
# Parent  5a6e2705cc95a340abf973ae5df73ef34e070b79
[mq]: adding-acpi-thinkpad.patch

diff --git a/sys/dev/acpica5/Makefile b/sys/dev/acpica5/Makefile
--- a/sys/dev/acpica5/Makefile
+++ b/sys/dev/acpica5/Makefile
@@ -117,7 +117,7 @@ acpi_wakecode.h: acpi_wakecode.S
 	${MAKE} -f ${SYSDIR}/${OSACPI_MD_DIR}/Makefile \
 		MAKESRCPATH=${SYSDIR}/${OSACPI_MD_DIR}
 
-SUBDIR=	acpi_toshiba
+SUBDIR=	acpi_toshiba acpi_thinkpad
 all: ${PROG} ${SUBDIR}
 
 # *.o file for each patched *.c file is created under the same directory,
diff --git a/sys/dev/acpica5/acpi_thinkpad/Makefile b/sys/dev/acpica5/acpi_thinkpad/Makefile
new file mode 100644
--- /dev/null
+++ b/sys/dev/acpica5/acpi_thinkpad/Makefile
@@ -0,0 +1,9 @@
+# $DragonFly$
+
+SYSDIR?=${.CURDIR}/../../..
+
+KMOD=		acpi_thinkpad
+CFLAGS+=	-I${.OBJDIR}/.. -I${.CURDIR}/..
+SRCS=		acpi_thinkpad.c opt_acpi.h device_if.h bus_if.h
+
+.include <bsd.kmod.mk>
diff --git a/sys/dev/acpica5/acpi_thinkpad/acpi_thinkpad.c b/sys/dev/acpica5/acpi_thinkpad/acpi_thinkpad.c
new file mode 100644
--- /dev/null
+++ b/sys/dev/acpica5/acpi_thinkpad/acpi_thinkpad.c
@@ -0,0 +1,1046 @@
+/*
+ * Copyright (c) 2004 Takanori Watanabe
+ * Copyright (c) 2005 Markus Brueffer <markus at FreeBSD.org>
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *    notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *    notice, this list of conditions and the following disclaimer in the
+ *    documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+ */
+
+/*
+ * Driver for extra ACPI-controlled gadgets found on IBM and Lenovo ThinkPad
+ * laptops. Inspired by the ibm-acpi and tpb projects which implement these
+ * features on Linux.
+ *
+ *   acpi-ibm: <http://ibm-acpi.sourceforge.net/>
+ *        tpb: <http://www.nongnu.org/tpb/>
+ */
+
+#include "opt_acpi.h"
+#include <sys/param.h>
+#include <sys/kernel.h>
+#include <sys/bus.h>
+#include <machine/cpufunc.h>
+#include <sys/module.h>
+/* #include <dev/led/led.h> */
+#include <sys/sensors.h>
+#include <sys/sysctl.h>
+#include <machine/clock.h>
+
+#include "acpi.h"
+#include "acpivar.h"
+#include "acpi_if.h"
+
+#define _COMPONENT	ACPI_OEM
+ACPI_MODULE_NAME("THINKPAD")
+
+/* Internal methods */
+#define ACPI_THINKPAD_METHOD_EVENTS		1
+#define ACPI_THINKPAD_METHOD_EVENTMASK		2
+#define ACPI_THINKPAD_METHOD_HOTKEY		3
+#define ACPI_THINKPAD_METHOD_BRIGHTNESS		4
+#define ACPI_THINKPAD_METHOD_VOLUME		5
+#define ACPI_THINKPAD_METHOD_MUTE		6
+#define ACPI_THINKPAD_METHOD_THINKLIGHT		7
+#define ACPI_THINKPAD_METHOD_BLUETOOTH		8
+#define ACPI_THINKPAD_METHOD_WLAN		9
+#define ACPI_THINKPAD_METHOD_FANSPEED		10
+#define ACPI_THINKPAD_METHOD_FANLEVEL		11
+#define ACPI_THINKPAD_METHOD_FANSTATUS		12
+#define ACPI_THINKPAD_METHOD_THERMAL		13
+
+/* Hotkeys/Buttons */
+#define THINKPAD_RTC_HOTKEY1			0x64
+#define   THINKPAD_RTC_MASK_HOME		(1 << 0)
+#define   THINKPAD_RTC_MASK_SEARCH		(1 << 1)
+#define   THINKPAD_RTC_MASK_MAIL		(1 << 2)
+#define   THINKPAD_RTC_MASK_WLAN		(1 << 5)
+#define THINKPAD_RTC_HOTKEY2			0x65
+#define   THINKPAD_RTC_MASK_THINKPAD		(1 << 3)
+#define   THINKPAD_RTC_MASK_ZOOM		(1 << 5)
+#define   THINKPAD_RTC_MASK_VIDEO		(1 << 6)
+#define   THINKPAD_RTC_MASK_HIBERNATE		(1 << 7)
+#define THINKPAD_RTC_THINKLIGHT			0x66
+#define   THINKPAD_RTC_MASK_THINKLIGHT		(1 << 4)
+#define THINKPAD_RTC_SCREENEXPAND		0x67
+#define   THINKPAD_RTC_MASK_SCREENEXPAND	(1 << 5)
+#define THINKPAD_RTC_BRIGHTNESS			0x6c
+#define   THINKPAD_RTC_MASK_BRIGHTNESS		(1 << 5)
+#define THINKPAD_RTC_VOLUME			0x6e
+#define   THINKPAD_RTC_MASK_VOLUME		(1 << 7)
+
+/* Embedded Controller registers */
+#define THINKPAD_EC_BRIGHTNESS			0x31
+#define   THINKPAD_EC_MASK_BRI			0x7
+#define THINKPAD_EC_VOLUME			0x30
+#define   THINKPAD_EC_MASK_VOL			0xf
+#define   THINKPAD_EC_MASK_MUTE			(1 << 6)
+#define THINKPAD_EC_FANSTATUS			0x2F
+#define   THINKPAD_EC_MASK_FANLEVEL		0x3f
+#define   THINKPAD_EC_MASK_FANDISENGAGED	(1 << 6)
+#define   THINKPAD_EC_MASK_FANSTATUS		(1 << 7)
+#define THINKPAD_EC_FANSPEED			0x84
+
+/* CMOS Commands */
+#define THINKPAD_CMOS_VOLUME_DOWN		0
+#define THINKPAD_CMOS_VOLUME_UP			1
+#define THINKPAD_CMOS_VOLUME_MUTE		2
+#define THINKPAD_CMOS_BRIGHTNESS_UP		4
+#define THINKPAD_CMOS_BRIGHTNESS_DOWN		5
+
+/* ACPI methods */
+#define THINKPAD_NAME_KEYLIGHT			"KBLT"
+#define THINKPAD_NAME_WLAN_BT_GET		"GBDC"
+#define THINKPAD_NAME_WLAN_BT_SET		"SBDC"
+#define   THINKPAD_NAME_MASK_BT			(1 << 1)
+#define   THINKPAD_NAME_MASK_WLAN		(1 << 2)
+#define THINKPAD_NAME_THERMAL_GET		"TMP7"
+#define THINKPAD_NAME_THERMAL_UPDT		"UPDT"
+
+#define THINKPAD_NAME_EVENTS_STATUS_GET		"DHKC"
+#define THINKPAD_NAME_EVENTS_MASK_GET		"DHKN"
+#define THINKPAD_NAME_EVENTS_STATUS_SET		"MHKC"
+#define THINKPAD_NAME_EVENTS_MASK_SET		"MHKM"
+#define THINKPAD_NAME_EVENTS_GET		"MHKP"
+#define THINKPAD_NAME_EVENTS_AVAILMASK		"MHKA"
+
+#define ABS(x) (((x) < 0)? -(x) : (x))
+
+struct acpi_thinkpad_softc {
+	device_t	dev;
+	ACPI_HANDLE	handle;
+
+	/* Embedded controller */
+	device_t	ec_dev;
+	ACPI_HANDLE	ec_handle;
+
+	/* CMOS */
+	ACPI_HANDLE	cmos_handle;
+
+	/* Fan status */
+	ACPI_HANDLE	fan_handle;
+	int		fan_levels;
+
+	/* Keylight commands and states */
+	ACPI_HANDLE	light_handle;
+	int		light_cmd_on;
+	int		light_cmd_off;
+	int		light_val;
+	int		light_get_supported;
+	int		light_set_supported;
+
+	/* led(4) interface */
+	struct cdev	*led_dev;
+	int		led_busy;
+	int		led_state;
+
+	int		wlan_bt_flags;
+	int		thermal_updt_supported;
+
+	unsigned int	events_availmask;
+	unsigned int	events_initialmask;
+	int		events_mask_supported;
+	int		events_enable;
+
+	/* sensors(9) related */
+	struct ksensordev sensordev;
+	struct ksensor sensors[9];	/* XXX: 8 thermal + fan */
+
+	struct sysctl_ctx_list	*sysctl_ctx;
+	struct sysctl_oid	*sysctl_tree;
+};
+
+static struct {
+	char	*name;
+	int	method;
+	char	*description;
+	int	access;
+} acpi_thinkpad_sysctls[] = {
+	{
+		.name		= "events",
+		.method		= ACPI_THINKPAD_METHOD_EVENTS,
+		.description	= "ACPI events enable",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "eventmask",
+		.method		= ACPI_THINKPAD_METHOD_EVENTMASK,
+		.description	= "ACPI eventmask",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "hotkey",
+		.method		= ACPI_THINKPAD_METHOD_HOTKEY,
+		.description	= "Key Status",
+		.access		= CTLTYPE_INT | CTLFLAG_RD
+	},
+	{
+		.name		= "lcd_brightness",
+		.method		= ACPI_THINKPAD_METHOD_BRIGHTNESS,
+		.description	= "LCD Brightness",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "volume",
+		.method		= ACPI_THINKPAD_METHOD_VOLUME,
+		.description	= "Volume",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "mute",
+		.method		= ACPI_THINKPAD_METHOD_MUTE,
+		.description	= "Mute",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "thinklight",
+		.method		= ACPI_THINKPAD_METHOD_THINKLIGHT,
+		.description	= "Thinklight enable",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "bluetooth",
+		.method		= ACPI_THINKPAD_METHOD_BLUETOOTH,
+		.description	= "Bluetooth enable",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "wlan",
+		.method		= ACPI_THINKPAD_METHOD_WLAN,
+		.description	= "WLAN enable",
+		.access		= CTLTYPE_INT | CTLFLAG_RD
+	},
+	{
+		.name		= "fan_level",
+		.method		= ACPI_THINKPAD_METHOD_FANLEVEL,
+		.description	= "Fan level",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "fan",
+		.method		= ACPI_THINKPAD_METHOD_FANSTATUS,
+		.description	= "Fan enable",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+
+	{ NULL, 0, NULL, 0 }
+};
+
+/* ACPI_SERIAL_DECL(thinkpad, "ACPI THINKPAD extras"); */
+static int	acpi_thinkpad_probe(device_t dev);
+static int	acpi_thinkpad_attach(device_t dev);
+static int	acpi_thinkpad_detach(device_t dev);
+
+#if 0 /* not yet */
+static void	thinkpad_led(void *softc, int onoff);
+static void	thinkpad_led_task(struct acpi_thinkpad_softc *sc,
+		int pending __unused);
+#endif
+
+static int	acpi_thinkpad_sysctl(SYSCTL_HANDLER_ARGS);
+static int	acpi_thinkpad_sysctl_init(struct acpi_thinkpad_softc *sc,
+		int method);
+static int	acpi_thinkpad_sysctl_get(struct acpi_thinkpad_softc *sc,
+		int method);
+static int	acpi_thinkpad_sysctl_set(struct acpi_thinkpad_softc *sc,
+		int method, int val);
+
+static int	acpi_thinkpad_eventmask_set(struct acpi_thinkpad_softc *sc,
+		int val);
+static void	acpi_thinkpad_notify(ACPI_HANDLE h, UINT32 notify,
+		void *context);
+static void	acpi_thinkpad_refresh(void *);
+
+static device_method_t acpi_thinkpad_methods[] = {
+	/* Device interface */
+	DEVMETHOD(device_probe, acpi_thinkpad_probe),
+	DEVMETHOD(device_attach, acpi_thinkpad_attach),
+	DEVMETHOD(device_detach, acpi_thinkpad_detach),
+	{0, 0}
+};
+
+static driver_t	acpi_thinkpad_driver = {
+	"acpi_thinkpad",
+	acpi_thinkpad_methods,
+	sizeof(struct acpi_thinkpad_softc),
+};
+
+static devclass_t acpi_thinkpad_devclass;
+
+DRIVER_MODULE(acpi_thinkpad, acpi, acpi_thinkpad_driver,
+    acpi_thinkpad_devclass, 0, 0);
+MODULE_DEPEND(acpi_thinkpad, acpi, 1, 1, 1);
+static char    *thinkpad_ids[] = {"IBM0068", NULL};
+
+#if 0 /* not yet */
+static void
+thinkpad_led(void *softc, int onoff)
+{
+	struct acpi_thinkpad_softc* sc = (struct acpi_thinkpad_softc*) softc;
+
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+
+	if (sc->led_busy)
+		return;
+
+	sc->led_busy = 1;
+	sc->led_state = onoff;
+
+	AcpiOsExecute(OSL_NOTIFY_HANDLER, (void *)thinkpad_led_task, sc);
+}
+
+static void
+thinkpad_led_task(struct acpi_thinkpad_softc *sc, int pending __unused)
+{
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+
+	/* ACPI_SERIAL_BEGIN(thinkpad); */
+	acpi_thinkpad_sysctl_set(sc, ACPI_THINKPAD_METHOD_THINKLIGHT, sc->led_state);
+	/* ACPI_SERIAL_END(thinkpad); */
+
+	sc->led_busy = 0;
+}
+#endif
+
+static int
+acpi_thinkpad_probe(device_t dev)
+{
+	if (acpi_disabled("thinkpad") ||
+	    ACPI_ID_PROBE(device_get_parent(dev), dev, thinkpad_ids) == NULL ||
+	    device_get_unit(dev) != 0) 
+		return (ENXIO);
+
+	device_set_desc(dev, "IBM/Lenovo ThinkPad ACPI Extras");
+	return (0);
+}
+
+static int
+acpi_thinkpad_attach(device_t dev)
+{
+	struct acpi_thinkpad_softc	*sc;
+	struct acpi_softc	*acpi_sc;
+	devclass_t		ec_devclass;
+	int			i;
+
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t) __func__);
+
+	sc = device_get_softc(dev);
+	sc->dev = dev;
+	sc->handle = acpi_get_handle(dev);
+
+	acpi_sc = acpi_device_get_parent_softc(dev);
+
+	/* Look for the first embedded controller */
+        if (!(ec_devclass = devclass_find ("acpi_ec"))) {
+		if (bootverbose)
+			device_printf(dev, "Couldn't find acpi_ec devclass\n");
+		return (EINVAL);
+	}
+        if (!(sc->ec_dev = devclass_get_device(ec_devclass, 0))) {
+		if (bootverbose)
+			device_printf(dev, "Couldn't find acpi_ec device\n");
+		return (EINVAL);
+	}
+	sc->ec_handle = acpi_get_handle(sc->ec_dev);
+
+	/* ACPI_SERIAL_BEGIN(thinkpad); */
+
+#if 0
+	/* Get the sysctl tree */
+	sc->sysctl_ctx = device_get_sysctl_ctx(dev);
+	sc->sysctl_tree = device_get_sysctl_tree(dev);
+#endif
+	sysctl_ctx_init(sc->sysctl_ctx);
+	sc->sysctl_tree = SYSCTL_ADD_NODE(sc->sysctl_ctx,
+	    SYSCTL_CHILDREN(acpi_sc->acpi_sysctl_tree), OID_AUTO,
+	    "thinkpad", CTLFLAG_RD, 0, "");
+
+	/* Look for event mask and hook up the nodes */
+	sc->events_mask_supported = ACPI_SUCCESS(acpi_GetInteger(sc->handle,
+	    THINKPAD_NAME_EVENTS_MASK_GET, &sc->events_initialmask));
+
+	if (sc->events_mask_supported) {
+		SYSCTL_ADD_INT(sc->sysctl_ctx,
+		    SYSCTL_CHILDREN(sc->sysctl_tree), OID_AUTO,
+		    "initialmask", CTLFLAG_RD,
+		    &sc->events_initialmask, 0, "Initial eventmask");
+
+		/* The availmask is the bitmask of supported events */
+		if (ACPI_FAILURE(acpi_GetInteger(sc->handle,
+		    THINKPAD_NAME_EVENTS_AVAILMASK, &sc->events_availmask)))
+			sc->events_availmask = 0xffffffff;
+
+		SYSCTL_ADD_INT(sc->sysctl_ctx,
+		    SYSCTL_CHILDREN(sc->sysctl_tree), OID_AUTO,
+		    "availmask", CTLFLAG_RD,
+		    &sc->events_availmask, 0, "Mask of supported events");
+	}
+
+	/* Hook up proc nodes */
+	for (i = 0; acpi_thinkpad_sysctls[i].name != NULL; i++) {
+		if (!acpi_thinkpad_sysctl_init(sc,
+		    acpi_thinkpad_sysctls[i].method))
+			continue;
+
+		SYSCTL_ADD_PROC(sc->sysctl_ctx,
+		    SYSCTL_CHILDREN(sc->sysctl_tree), OID_AUTO,
+		    acpi_thinkpad_sysctls[i].name,
+		    acpi_thinkpad_sysctls[i].access,
+		    sc, i, acpi_thinkpad_sysctl, "I",
+		    acpi_thinkpad_sysctls[i].description);
+	}
+
+	/* ACPI_SERIAL_END(thinkpad); */
+
+	/* Handle notifies */
+	AcpiInstallNotifyHandler(sc->handle, ACPI_DEVICE_NOTIFY,
+	    acpi_thinkpad_notify, dev);
+
+#if 0
+	/* Hook up light to led(4) */
+	if (sc->light_set_supported)
+		sc->led_dev = led_create_state(thinkpad_led, sc, "thinklight",
+		    sc->light_val);
+#endif
+	/* Attach sensors(9). */
+	if (sensor_task_register(sc, acpi_thinkpad_refresh, 5)) {
+		device_printf(sc->dev, "unable to register update task\n");
+		return 1;
+	}
+
+	strlcpy(sc->sensordev.xname, device_get_nameunit(sc->dev),
+	    sizeof(sc->sensordev.xname));
+
+	/* XXX: Temp sensors */
+	for (i = 0; i < 8; ++i) {
+		sc->sensors[i].type = SENSOR_TEMP;
+		sensor_attach(&sc->sensordev, &sc->sensors[i]);
+	}
+	
+	/* Fan RPM sensor */
+	sc->sensors[8].type = SENSOR_FANRPM;
+	sensor_attach(&sc->sensordev, &sc->sensors[8]);
+
+	sensordev_install(&sc->sensordev);
+
+	return (0);
+}
+
+static int
+acpi_thinkpad_detach(device_t dev)
+{
+	int i;
+
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t) __func__);
+
+	struct acpi_thinkpad_softc *sc = device_get_softc(dev);
+
+	/* Disable events and restore eventmask */
+	/* ACPI_SERIAL_BEGIN(thinkpad); */
+	acpi_thinkpad_sysctl_set(sc, ACPI_THINKPAD_METHOD_EVENTS, 0);
+	acpi_thinkpad_sysctl_set(sc, ACPI_THINKPAD_METHOD_EVENTMASK,
+	    sc->events_initialmask);
+	/* ACPI_SERIAL_END(thinkpad); */
+
+	AcpiRemoveNotifyHandler(sc->handle, ACPI_DEVICE_NOTIFY,
+	    acpi_thinkpad_notify);
+
+	sysctl_ctx_free(sc->sysctl_ctx);
+
+#if 0
+	if (sc->led_dev != NULL)
+		led_destroy(sc->led_dev);
+#endif
+	sensordev_deinstall(&sc->sensordev);
+	for (i = 0; i < 9; i++)
+		sensor_detach(&sc->sensordev, &sc->sensors[i]);
+	sensor_task_unregister(sc);
+
+	return (0);
+}
+
+static int
+acpi_thinkpad_eventmask_set(struct acpi_thinkpad_softc *sc, int val)
+{
+	int i;
+	ACPI_OBJECT		arg[2];
+	ACPI_OBJECT_LIST	args;
+	ACPI_STATUS		status;
+
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+	/* ACPI_SERIAL_ASSERT(thinkpad); */
+
+	args.Count = 2;
+	args.Pointer = arg;
+	arg[0].Type = ACPI_TYPE_INTEGER;
+	arg[1].Type = ACPI_TYPE_INTEGER;
+
+	for (i = 0; i < 32; ++i) {
+		arg[0].Integer.Value = i+1;
+		arg[1].Integer.Value = (((1 << i) & val) != 0);
+		status = AcpiEvaluateObject(sc->handle,
+		    THINKPAD_NAME_EVENTS_MASK_SET, &args, NULL);
+
+		if (ACPI_FAILURE(status))
+			return (status);
+	}
+
+	return (0);
+}
+
+static int
+acpi_thinkpad_sysctl(SYSCTL_HANDLER_ARGS)
+{
+	struct acpi_thinkpad_softc	*sc;
+	int			arg;
+	int			error = 0;
+	int			function;
+	int			method;
+	
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+
+	sc = (struct acpi_thinkpad_softc *)oidp->oid_arg1;
+	function = oidp->oid_arg2;
+	method = acpi_thinkpad_sysctls[function].method;
+
+	/* ACPI_SERIAL_BEGIN(thinkpad); */
+	arg = acpi_thinkpad_sysctl_get(sc, method);
+	error = sysctl_handle_int(oidp, &arg, 0, req);
+
+	/* Sanity check */
+	if (error != 0 || req->newptr == NULL)
+		goto out;
+
+	/* Update */
+	error = acpi_thinkpad_sysctl_set(sc, method, arg);
+
+out:
+	/* ACPI_SERIAL_END(thinkpad); */
+	return (error);
+}
+
+static int
+acpi_thinkpad_sysctl_get(struct acpi_thinkpad_softc *sc, int method)
+{
+	ACPI_INTEGER	val_ec;
+	int 		val = 0, key;
+
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+	/* ACPI_SERIAL_ASSERT(thinkpad); */
+
+	switch (method) {
+	case ACPI_THINKPAD_METHOD_EVENTS:
+		acpi_GetInteger(sc->handle, THINKPAD_NAME_EVENTS_STATUS_GET,
+		    &val);
+		break;
+
+	case ACPI_THINKPAD_METHOD_EVENTMASK:
+		if (sc->events_mask_supported)
+			acpi_GetInteger(sc->handle,
+			    THINKPAD_NAME_EVENTS_MASK_GET, &val);
+		break;
+
+	case ACPI_THINKPAD_METHOD_HOTKEY:
+		/*
+		 * Construct the hotkey as a bitmask as illustrated below.
+		 * Note that whenever a key was pressed, the respecting bit
+		 * toggles and nothing else changes.
+		 * +--+--+-+-+-+-+-+-+-+-+-+-+
+		 * |11|10|9|8|7|6|5|4|3|2|1|0|
+		 * +--+--+-+-+-+-+-+-+-+-+-+-+
+		 *   |  | | | | | | | | | | |
+		 *   |  | | | | | | | | | | +- Home Button
+		 *   |  | | | | | | | | | +--- Search Button
+		 *   |  | | | | | | | | +----- Mail Button
+		 *   |  | | | | | | | +------- Thinkpad Button
+		 *   |  | | | | | | +--------- Zoom (Fn + Space)
+		 *   |  | | | | | +----------- WLAN Button
+		 *   |  | | | | +------------- Video Button
+		 *   |  | | | +--------------- Hibernate Button
+		 *   |  | | +----------------- Thinklight Button
+		 *   |  | +------------------- Screen expand (Fn + F8)
+		 *   |  +--------------------- Brightness
+		 *   +------------------------ Volume/Mute
+		 */
+		key = rtcin(THINKPAD_RTC_HOTKEY1);
+		val = (THINKPAD_RTC_MASK_HOME | THINKPAD_RTC_MASK_SEARCH |
+		    THINKPAD_RTC_MASK_MAIL | THINKPAD_RTC_MASK_WLAN) & key;
+		key = rtcin(THINKPAD_RTC_HOTKEY2);
+		val |= (THINKPAD_RTC_MASK_THINKPAD | THINKPAD_RTC_MASK_VIDEO |
+		    THINKPAD_RTC_MASK_HIBERNATE) & key;
+		val |= (THINKPAD_RTC_MASK_ZOOM & key) >> 1;
+		key = rtcin(THINKPAD_RTC_THINKLIGHT);
+		val |= (THINKPAD_RTC_MASK_THINKLIGHT & key) << 4;
+		key = rtcin(THINKPAD_RTC_SCREENEXPAND);
+		val |= (THINKPAD_RTC_MASK_THINKLIGHT & key) << 4;
+		key = rtcin(THINKPAD_RTC_BRIGHTNESS);
+		val |= (THINKPAD_RTC_MASK_BRIGHTNESS & key) << 5;
+		key = rtcin(THINKPAD_RTC_VOLUME);
+		val |= (THINKPAD_RTC_MASK_VOLUME & key) << 4;
+		break;
+
+	case ACPI_THINKPAD_METHOD_BRIGHTNESS:
+		ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_BRIGHTNESS, &val_ec, 1);
+		val = val_ec & THINKPAD_EC_MASK_BRI;
+		break;
+
+	case ACPI_THINKPAD_METHOD_VOLUME:
+		ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_VOLUME, &val_ec, 1);
+		val = val_ec & THINKPAD_EC_MASK_VOL;
+		break;
+
+	case ACPI_THINKPAD_METHOD_MUTE:
+		val = ((val_ec & THINKPAD_EC_MASK_MUTE) ==
+		    THINKPAD_EC_MASK_MUTE);
+		break;
+
+	case ACPI_THINKPAD_METHOD_THINKLIGHT:
+		if (sc->light_get_supported)
+			acpi_GetInteger(sc->ec_handle, THINKPAD_NAME_KEYLIGHT,
+			    &val);
+		else
+			val = sc->light_val;
+		break;
+
+	case ACPI_THINKPAD_METHOD_BLUETOOTH:
+		acpi_GetInteger(sc->handle, THINKPAD_NAME_WLAN_BT_GET, &val);
+		sc->wlan_bt_flags = val;
+		val = ((val & THINKPAD_NAME_MASK_BT) != 0);
+		break;
+
+	case ACPI_THINKPAD_METHOD_WLAN:
+		acpi_GetInteger(sc->handle, THINKPAD_NAME_WLAN_BT_GET, &val);
+		sc->wlan_bt_flags = val;
+		val = ((val & THINKPAD_NAME_MASK_WLAN) != 0);
+		break;
+
+	case ACPI_THINKPAD_METHOD_FANSPEED:
+		if (sc->fan_handle) {
+			if (ACPI_FAILURE(acpi_GetInteger(sc->fan_handle,
+			    NULL, &val)))
+				val = -1;
+		}
+		else {
+			ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_FANSPEED,
+			    &val_ec, 2);
+			val = val_ec;
+		}
+		break;
+
+	case ACPI_THINKPAD_METHOD_FANLEVEL:
+		/*
+		 * The THINKPAD_EC_FANSTATUS register works as follows:
+		 * Bit 0-5 indicate the level at which the fan operates. Only
+		 *       values between 0 and 7 have an effect. Everything
+		 *       above 7 is treated the same as level 7
+		 * Bit 6 overrides the fan speed limit if set to 1
+		 * Bit 7 indicates at which mode the fan operates:
+		 *       manual (0) or automatic (1)
+		 */
+		if (!sc->fan_handle) {
+			ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_FANSTATUS,
+			    &val_ec, 1);
+			val = val_ec & THINKPAD_EC_MASK_FANLEVEL;
+		}
+		break;
+
+	case ACPI_THINKPAD_METHOD_FANSTATUS:
+		if (!sc->fan_handle) {
+			ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_FANSTATUS,
+			    &val_ec, 1);
+			val = (val_ec & THINKPAD_EC_MASK_FANSTATUS) ==
+			    THINKPAD_EC_MASK_FANSTATUS;
+		}
+		else
+			val = -1;
+		break;
+	}
+
+	return (val);
+}
+
+static int
+acpi_thinkpad_sysctl_set(struct acpi_thinkpad_softc *sc, int method, int arg)
+{
+	int			val, step, i;
+	ACPI_INTEGER		val_ec;
+	ACPI_OBJECT		Arg;
+	ACPI_OBJECT_LIST	Args;
+	ACPI_STATUS		status;
+
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+	/* ACPI_SERIAL_ASSERT(thinkpad); */
+
+	switch (method) {
+	case ACPI_THINKPAD_METHOD_EVENTS:
+		if (arg < 0 || arg > 1)
+			return (EINVAL);
+
+		status = acpi_SetInteger(sc->handle,
+		    THINKPAD_NAME_EVENTS_STATUS_SET, arg);
+		if (ACPI_FAILURE(status))
+			return (status);
+		if (sc->events_mask_supported)
+			return acpi_thinkpad_eventmask_set(sc,
+			    sc->events_availmask);
+		break;
+
+	case ACPI_THINKPAD_METHOD_EVENTMASK:
+		if (sc->events_mask_supported)
+			return acpi_thinkpad_eventmask_set(sc, arg);
+		break;
+
+	case ACPI_THINKPAD_METHOD_BRIGHTNESS:
+		if (arg < 0 || arg > 7)
+			return (EINVAL);
+
+		if (sc->cmos_handle) {
+			/* Read the current brightness */
+			status = ACPI_EC_READ(sc->ec_dev,
+			    THINKPAD_EC_BRIGHTNESS, &val_ec, 1);
+			if (ACPI_FAILURE(status))
+				return (status);
+			val = val_ec & THINKPAD_EC_MASK_BRI;
+
+			Args.Count = 1;
+			Args.Pointer = &Arg;
+			Arg.Type = ACPI_TYPE_INTEGER;
+			Arg.Integer.Value = (arg > val) ?
+			    THINKPAD_CMOS_BRIGHTNESS_UP :
+			    THINKPAD_CMOS_BRIGHTNESS_DOWN;
+
+			step = (arg > val) ? 1 : -1;
+			for (i = val; i != arg; i += step) {
+				status = AcpiEvaluateObject(sc->cmos_handle,
+				    NULL, &Args, NULL);
+				if (ACPI_FAILURE(status))
+					break;
+			}
+		}
+		return ACPI_EC_WRITE(sc->ec_dev, THINKPAD_EC_BRIGHTNESS,
+		    arg, 1);
+		break;
+
+	case ACPI_THINKPAD_METHOD_VOLUME:
+		if (arg < 0 || arg > 14)
+			return (EINVAL);
+
+		status = ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_VOLUME,
+		    &val_ec, 1);
+		if (ACPI_FAILURE(status))
+			return (status);
+
+		if (sc->cmos_handle) {
+			val = val_ec & THINKPAD_EC_MASK_VOL;
+
+			Args.Count = 1;
+			Args.Pointer = &Arg;
+			Arg.Type = ACPI_TYPE_INTEGER;
+			Arg.Integer.Value = (arg > val) ?
+			    THINKPAD_CMOS_VOLUME_UP : THINKPAD_CMOS_VOLUME_DOWN;
+
+			step = (arg > val) ? 1 : -1;
+			for (i = val; i != arg; i += step) {
+				status = AcpiEvaluateObject(sc->cmos_handle,
+				    NULL, &Args, NULL);
+				if (ACPI_FAILURE(status))
+					break;
+			}
+		}
+		return ACPI_EC_WRITE(sc->ec_dev, THINKPAD_EC_VOLUME, arg +
+		    (val_ec & (~THINKPAD_EC_MASK_VOL)), 1);
+		break;
+
+	case ACPI_THINKPAD_METHOD_MUTE:
+		if (arg < 0 || arg > 1)
+			return (EINVAL);
+
+		status = ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_VOLUME,
+		    &val_ec, 1);
+		if (ACPI_FAILURE(status))
+			return (status);
+
+		if (sc->cmos_handle) {
+			val = val_ec & THINKPAD_EC_MASK_VOL;
+
+			Args.Count = 1;
+			Args.Pointer = &Arg;
+			Arg.Type = ACPI_TYPE_INTEGER;
+			Arg.Integer.Value = THINKPAD_CMOS_VOLUME_MUTE;
+
+			status = AcpiEvaluateObject(sc->cmos_handle, NULL,
+			    &Args, NULL);
+			if (ACPI_FAILURE(status))
+				break;
+		}
+		return ACPI_EC_WRITE(sc->ec_dev, THINKPAD_EC_VOLUME, (arg==1) ?
+		   val_ec | THINKPAD_EC_MASK_MUTE :
+		   val_ec & (~THINKPAD_EC_MASK_MUTE), 1);
+		break;
+
+	case ACPI_THINKPAD_METHOD_THINKLIGHT:
+		if (arg < 0 || arg > 1)
+			return (EINVAL);
+
+		if (sc->light_set_supported) {
+			Args.Count = 1;
+			Args.Pointer = &Arg;
+			Arg.Type = ACPI_TYPE_INTEGER;
+			Arg.Integer.Value = arg ?
+			    sc->light_cmd_on : sc->light_cmd_off;
+
+			status = AcpiEvaluateObject(sc->light_handle, NULL,
+			    &Args, NULL);
+			if (ACPI_SUCCESS(status))
+				sc->light_val = arg;
+			return (status);
+		}
+		break;
+
+	case ACPI_THINKPAD_METHOD_BLUETOOTH:
+		if (arg < 0 || arg > 1)
+			return (EINVAL);
+
+		val = (arg == 1) ? sc->wlan_bt_flags |
+		    THINKPAD_NAME_MASK_BT :
+		    sc->wlan_bt_flags & (~THINKPAD_NAME_MASK_BT);
+		return acpi_SetInteger(sc->handle, THINKPAD_NAME_WLAN_BT_SET,
+		    val);
+		break;
+
+	case ACPI_THINKPAD_METHOD_FANLEVEL:
+		if (arg < 0 || arg > 7)
+			return (EINVAL);
+
+		if (!sc->fan_handle) {
+			/* Read the current fanstatus */
+			ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_FANSTATUS,
+			    &val_ec, 1);
+			val = val_ec & (~THINKPAD_EC_MASK_FANLEVEL);
+
+			return ACPI_EC_WRITE(sc->ec_dev, THINKPAD_EC_FANSTATUS,
+			    val | arg, 1);
+		}
+		break;
+
+	case ACPI_THINKPAD_METHOD_FANSTATUS:
+		if (arg < 0 || arg > 1)
+			return (EINVAL);
+
+		if (!sc->fan_handle) {
+			/* Read the current fanstatus */
+			ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_FANSTATUS,
+			    &val_ec, 1);
+
+			return ACPI_EC_WRITE(sc->ec_dev, THINKPAD_EC_FANSTATUS,
+			    (arg == 1) ? (val_ec | THINKPAD_EC_MASK_FANSTATUS) :
+			    (val_ec & (~THINKPAD_EC_MASK_FANSTATUS)), 1);
+		}
+		break;
+	}
+
+	return (0);
+}
+
+static int
+acpi_thinkpad_sysctl_init(struct acpi_thinkpad_softc *sc, int method)
+{
+	int 			dummy;
+	ACPI_OBJECT_TYPE 	cmos_t;
+	ACPI_HANDLE		ledb_handle;
+
+	switch (method) {
+	case ACPI_THINKPAD_METHOD_EVENTS:
+		/* Events are disabled by default */
+		return (TRUE);
+
+	case ACPI_THINKPAD_METHOD_EVENTMASK:
+		return (sc->events_mask_supported);
+
+	case ACPI_THINKPAD_METHOD_HOTKEY:
+	case ACPI_THINKPAD_METHOD_BRIGHTNESS:
+	case ACPI_THINKPAD_METHOD_VOLUME:
+	case ACPI_THINKPAD_METHOD_MUTE:
+		/* EC is required here, which was already checked before */
+		return (TRUE);
+
+	case ACPI_THINKPAD_METHOD_THINKLIGHT:
+		sc->cmos_handle = NULL;
+		sc->light_get_supported = ACPI_SUCCESS(acpi_GetInteger(
+		    sc->ec_handle, THINKPAD_NAME_KEYLIGHT, &sc->light_val));
+
+		if ((ACPI_SUCCESS(AcpiGetHandle(sc->handle, "\\UCMS",
+		    &sc->light_handle)) ||
+		    ACPI_SUCCESS(AcpiGetHandle(sc->handle, "\\CMOS",
+		    &sc->light_handle)) ||
+		    ACPI_SUCCESS(AcpiGetHandle(sc->handle, "\\CMS",
+		    &sc->light_handle))) &&
+		    ACPI_SUCCESS(AcpiGetType(sc->light_handle, &cmos_t)) &&
+		    cmos_t == ACPI_TYPE_METHOD) {
+			sc->light_cmd_on = 0x0c;
+			sc->light_cmd_off = 0x0d;
+			sc->cmos_handle = sc->light_handle;
+		}
+		else if (ACPI_SUCCESS(AcpiGetHandle(sc->handle, "\\LGHT",
+		    &sc->light_handle))) {
+			sc->light_cmd_on = 1;
+			sc->light_cmd_off = 0;
+		}
+		else
+			sc->light_handle = NULL;
+
+		sc->light_set_supported = (sc->light_handle &&
+		    ACPI_FAILURE(AcpiGetHandle(sc->ec_handle, "LEDB",
+		    &ledb_handle)));
+
+		if (sc->light_get_supported)
+			return (TRUE);
+
+		if (sc->light_set_supported) {
+			sc->light_val = 0;
+			return (TRUE);
+		}
+
+		return (FALSE);
+
+	case ACPI_THINKPAD_METHOD_BLUETOOTH:
+	case ACPI_THINKPAD_METHOD_WLAN:
+		if (ACPI_SUCCESS(acpi_GetInteger(sc->handle,
+		    THINKPAD_NAME_WLAN_BT_GET, &dummy)))
+			return (TRUE);
+		return (FALSE);
+
+	case ACPI_THINKPAD_METHOD_FANSPEED:
+		/* 
+		 * Some models report the fan speed in levels from 0-7
+		 * Newer models report it contiguously
+		 */
+		sc->fan_levels = (ACPI_SUCCESS(AcpiGetHandle(sc->handle, "GFAN",
+		    &sc->fan_handle)) ||
+		    ACPI_SUCCESS(AcpiGetHandle(sc->handle, "\\FSPD",
+		    &sc->fan_handle)));
+		return (TRUE);
+
+	case ACPI_THINKPAD_METHOD_FANLEVEL:
+	case ACPI_THINKPAD_METHOD_FANSTATUS:
+		/* 
+		 * Fan status is only supported on those models,
+		 * which report fan RPM contiguously, not in levels
+		 */
+		if (sc->fan_levels)
+			return (FALSE);
+		return (TRUE);
+
+	case ACPI_THINKPAD_METHOD_THERMAL:
+		if (ACPI_SUCCESS(acpi_GetInteger(sc->ec_handle,
+		    THINKPAD_NAME_THERMAL_GET, &dummy))) {
+			sc->thermal_updt_supported =
+			    ACPI_SUCCESS(acpi_GetInteger(sc->ec_handle,
+			    THINKPAD_NAME_THERMAL_UPDT, &dummy));
+			return (TRUE);
+		}
+		return (FALSE);
+	}
+	return (FALSE);
+}
+
+static void
+acpi_thinkpad_notify(ACPI_HANDLE h, UINT32 notify, void *context)
+{
+	int		event, arg, type;
+	device_t	dev = context;
+	struct acpi_thinkpad_softc *sc = device_get_softc(dev);
+
+	ACPI_FUNCTION_TRACE_U32((char *)(uintptr_t)__func__, notify);
+
+	if (notify != 0x80)
+		device_printf(dev, "Unknown notify\n");
+
+	for (;;) {
+		acpi_GetInteger(acpi_get_handle(dev), THINKPAD_NAME_EVENTS_GET,
+		    &event);
+
+		if (event == 0)
+			break;
+
+		type = (event >> 12) & 0xf;
+		arg = event & 0xfff;
+		switch (type) {
+		case 1:
+			if (!(sc->events_availmask & (1 << (arg - 1)))) {
+				device_printf(dev, "Unknown key %d\n", arg);
+				break;
+			}
+
+			/* Notify devd(8) */
+			device_printf(dev, "THINKPAD event: %u\n",
+			    (arg & 0xff));
+			acpi_UserNotify("THINKPAD", h, (arg & 0xff));
+			break;
+		default:
+			break;
+		}
+	}
+}
+
+static void
+acpi_thinkpad_refresh(void *arg)
+{
+	struct acpi_thinkpad_softc *sc = (struct acpi_thinkpad_softc *)arg;
+	char temp_cmd[] = "TMP0";
+	int data, i;
+	ACPI_INTEGER speed;
+
+	for (i = 0; i < 8; i++) {
+		temp_cmd[3] = '0' + i;
+		
+                /*
+                 * The TMPx methods seem to return +/- 128 or 0
+                 * when the respecting sensor is not available
+                 */
+		sc->sensors[i].flags &= ~SENSOR_FINVALID;
+                if (ACPI_FAILURE(acpi_GetInteger(sc->ec_handle, temp_cmd,
+                    &data)) || ABS(data) == 128 || data == 0) {
+			sc->sensors[i].flags |= SENSOR_FINVALID;
+                        data = 0;
+		}
+                else if (sc->thermal_updt_supported) {
+                        /* XXX: Temperature is reported in tenth of Kelvin */
+                        data = (data - 2732 + 5) / 10;
+		}
+		sc->sensors[i].value = data * 1000000 + 273150000;
+        }
+	
+	sc->sensors[8].flags &= ~SENSOR_FINVALID;
+	if (sc->fan_handle) {
+		if (ACPI_FAILURE(acpi_GetInteger(sc->fan_handle,
+		    NULL, &data)))
+			sc->sensors[8].flags |= SENSOR_FINVALID;
+                        data = -1;
+        }
+        else {
+                ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_FANSPEED, &speed, 2);
+                data = speed;
+        }
+
+	sc->sensors[8].value = data;
+}
diff --git a/sys/platform/pc32/conf/files b/sys/platform/pc32/conf/files
--- a/sys/platform/pc32/conf/files
+++ b/sys/platform/pc32/conf/files
@@ -72,6 +72,7 @@ dev/serial/dgb/dgm.c			optional	dgm
 ${OSACPI_MD_DIR}/acpi_machdep.c		optional        acpi
 ${OSACPI_MD_DIR}/acpi_wakeup.c		optional        acpi
 ${OSACPI_MD_DIR}/acpi_toshiba.c		optional        acpi_toshiba acpi
+${ACPICA_DIR}/acpi_thinkpad/acpi_thinkpad.c optional	acpi_thinkpad acpi
 acpi.h					optional	acpi		\
 	dependency	"$S/${ACPICA_DIR}/include/acpi.h"		\
 	compile-with	"cp $S/${ACPICA_DIR}/include/acpi.h ${.OBJDIR}/"	\



From hasso at estpak.ee  Thu Mar 20 03:49:13 2008
From: hasso at estpak.ee (Hasso Tepper)
Date: Thu, 20 Mar 2008 03:49:13 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Some questions regarding ACPI
In-Reply-To: <200803191322.46366.hasso@estpak.ee>
Message-ID: <200803201237.28823.hasso@estpak.ee>

Hasso Tepper wrote:
> There is also one fatal issue -laptop locks up hardly (no panic) while 
> unloading module. Any idea regarding this is welcome.

Nevermind, solved.


-- 
Hasso




From dillon at apollo.backplane.com  Fri Mar 21 19:24:01 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Fri, 21 Mar 2008 19:24:01 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: panic: assertion: hammer_btree_cmp(cursor->left_bound,	&cursor->node->ondisk->elms[0].leaf.base) <= 0 in btree_split_leaf
In-Reply-To: <200802232204.m1NM4cxd046264@apollo.backplane.com>
Message-ID: <200803220212.m2M2CiAY014435@apollo.backplane.com>

:While trying to find a procedure to reliably reproduce the panic
:I reported last time, I caught a different panic (uploaded at
: ~y0netan1/crash/9/ on my leaf account).  I wrote the following shell
:script (make sure to edit variables DISKS and MOUNTPT before using this
:script or it may trash your system):

    Ok, I believe I have fixed the left_bound assertion.  I also believe
    I have fixed the node ref count assertion on umount.

    There is currently one unfixed assertion related to the I/O
    path... sometimes the bp is being improperly disassociated from the
    related HAMMER structure.

    The full-filesystem case is still not being handled so don't test that :-)

					    -Matt





From c.turner at 199technologies.org  Sun Mar 23 09:48:29 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Sun, 23 Mar 2008 09:48:29 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
Message-ID: <47E6870C.4080709@199technologies.org>

I'm finally getting around to doing 1.12 upgrades, and have setup a 
separate machine to do my bulk package builds / upgrades etc,
so as not to disrupt my 'dev server' while things are being
built / tested

However, this seems kind of wasteful - the only purpose of this machine
is to build packages against a specific release..
And since building packages for a particular release generally requires 
only the userland, appropriate headers and correct 'uname' output - so:

it seems like if spoofing uname is configured inside a jail,
the next (or previous..) release can be installed into a jail and
used for building / testing packages without the overhead of a VM or 
maintaining a separate physical host

I did a quick scan of the tree to see what this would take, and, high 
level, it seems like only the following changes would need to be made:

- update struct jail to add a 'osrelease' string
  (implies bumping 'jail api' to 2?)
- update jail(8) to actually pass this information along
- update sys_uname to test ucred for jailed processes, and
  use the struct jail osrelease if appropriate
- similarly update sysctl kern.osrelease to support jail spoofing
  (if possible - didn't get this far in the research yet)
  could be less of a problem for builds, as I think most things use
 uname(1) ... but good to keep the environment consistent I suppose..
I'm still a bit confused as to how 'osrelease' is defined - everything
I'm finding is showing up as extern char[] .. perhaps this is something 
in the build I'm not familiar with?

also,

is the so-called 'stupid hackery' in sys_uname needed still?

Before I start any coding, does this:

- sound like something useful
- sound like the right approach
Thinking this could have wider useful implications e.g. for pkgbox
& so on -  for example setting up automated bulks w/various combinations 
of pkgsrc and releases, etc.

Cheers,

- Chris





From corecode at fs.ei.tum.de  Sun Mar 23 10:06:38 2008
From: corecode at fs.ei.tum.de (Simon 'corecode' Schubert)
Date: Sun, 23 Mar 2008 10:06:38 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <47E68C74.3080808@fs.ei.tum.de>

Chris Turner wrote:
I did a quick scan of the tree to see what this would take, and, high 
level, it seems like only the following changes would need to be made:
brave investigation.  but you could also simply set UNAME_r :)

sweatshorts % uname -r
1.13.0-DEVELOPMENT
sweatshorts % UNAME_r=1.12-RELEASE uname -r
1.12-RELEASE
I think that's good enough :D

cheers
  simon
--
Serve - BSD     +++  RENT this banner advert  +++    ASCII Ribbon   /"\
Work - Mac      +++  space for low ????????? NOW!1  +++      Campaign     \ /
Party Enjoy Relax   |   http://dragonflybsd.org      Against  HTML   \
Dude 2c 2 the max   !   http://golden-apple.biz       Mail + News   / \




From c.turner at 199technologies.org  Sun Mar 23 10:50:13 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Sun, 23 Mar 2008 10:50:13 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <47E69656.8080605@199technologies.org>

Simon 'corecode' Schubert wrote:
brave investigation.  but you could also simply set UNAME_r :)
Doh! Thanks for the tip!

they should change the phrase from RTFM to 'Carefully RTFM' :)

well.. scratch that change then. 1 less patch to write.

- Chris





From c.turner at 199technologies.org  Sun Mar 23 11:15:52 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Sun, 23 Mar 2008 11:15:52 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <47E69C7C.8010109@199technologies.org>

Chris Turner wrote:
Simon 'corecode' Schubert wrote:
brave investigation.  but you could also simply set UNAME_r :)

for the record - if anyone's interested - adding a line e.g.:

ALL_ENV+= UNAME_r=1.12-RELEASE

to mk.conf looks like it -might- work ..

(unless wants to chime in & verify)





From joerg at britannica.bec.de  Sun Mar 23 11:46:53 2008
From: joerg at britannica.bec.de (Joerg Sonnenberger)
Date: Sun, 23 Mar 2008 11:46:53 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <20080323181428.GA2099@britannica.bec.de>

On Sun, Mar 23, 2008 at 01:41:42PM -0400, Chris Turner wrote:
> they should change the phrase from RTFM to 'Carefully RTFM' :)

RTFMAI -- Read The Fine Manual Again, Idiot.

Joerg




From dillon at apollo.backplane.com  Sun Mar 23 20:05:36 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Sun, 23 Mar 2008 20:05:36 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
Message-ID: <200803240257.m2O2voNH038355@apollo.backplane.com>

    Here's an update on the HAMMER work!

    Current status:

    * Passes all standard filesystem stress tests and buildworld will
      run with a HAMMER /usr/obj.  Large histories are able to accumulate
      without effecting performance.

    * Pruning and reblocking code is in and partially tested, but now needs
      more stringent testing.

    * Full historical access appears to be working but needs testing.
      Note that a sync is still needed to flush dirty cached data prior
      to acquiring a timestamp for the 'snapshot' to be set in stone.
      (dirty data cached in-memory has no historical tags and must be
      committed to physical disk before it can be accessed historically).


    Current bugs:

    * There is one known bug in the standard operations code paths
      that results in an assertion in HAMMER's I/O subsystem.

    * There are probably bugs in the reblocking and/or pruning code.  More
      likely in the reblocking code.


    There are two big-ticket and several little-ticket items left.  HAMMER
    will officially go Alpha when the big-ticket items are done, and beta
    when we get a few of the little-ticket items done.

    Big ticket items left:

    * UNDO (crash recovery) code.  Currently it writes out undo records but
      they are not yet sequenced, buffer writes are not yet ordered, and
      there is no mount-time recovery code yet.

      This is the last item needed before HAMMER can go operational.

    * Filesystem full handling.  Currently no space is reserved for dirty
      cached data so it is possible to create/write files and for HAMMER
      to not have sufficient space left on-disk to flush it.


    Little ticket items:

    * Automated reblocking (currently these functions are manually
      initialized via the hammer utility).

    * I/O clustering and preliminary BMAP op when writing out large files.

    * CRC checking (CRC fields are reserved but not entirely generated yet
      and not yet checked at all).

    * Disaster Recovery filesystem scan.

    * Boot support.

    I expect all of these items and more to be handled by the 2.0 release
    in July.

			    Additional HAMMER capabilities
				(no timeline yet)

    * Adding, removing, and resizing a HAMMER filesystem's backing store.

			Ultimate Goals and working towards them
				(no timeline yet)

    Our ultimate goal with HAMMER and DragonFly in general is to support
    fully cache coherent replication in a multi-machine environment.  This
    involves several steps and networking protocols.

    * Replication of synchronization streams based on the UNDO log.  If
      resynchronizing to a target which is too old a B-Tree scan will
      likely be required.

    * Cache coherency protocols for machine-machine coherency for both
      replicated and remote-HAMMER access.

    I have no time frame for these items yet.  It will depend on how quickly
    HAMMER moves to Alpha and Beta status.  I will say, however, now
    that HAMMER's on-disk format has solidified, that I have a very precise
    understanding of the protocols that will be needed to accomplish fully
    cache coherent remote access for both replicated and non-replicated
    (remote mount style) access.

    And, as you know, fully coherent filesystem access across machines is
    going to be the basis for DragonFly's clustering across said machines.

    In summary, things are progressing very well.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From justin at shiningsilence.com  Sun Mar 23 20:10:13 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Sun, 23 Mar 2008 20:10:13 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <53758.192.168.0.252.1206327873.squirrel@www.shiningsilence.com>

On Sun, March 23, 2008 12:36 pm, Chris Turner wrote:

> it seems like if spoofing uname is configured inside a jail,
> the next (or previous..) release can be installed into a jail and
> used for building / testing packages without the overhead of a VM or
> maintaining a separate physical host

If you don't need a jail to spoof uname, as others posted, you can
installworld into a chroot and build everything you want there using
Joerg's spiffy pbulk.  That's what I'm doing on pkgbox now; I can hand you
my somewhat terse notes if you want.  It would be relatively easy to set
up the configuration you're talking about.





From sepherosa at gmail.com  Sun Mar 23 20:18:20 2008
From: sepherosa at gmail.com (Sepherosa Ziehau)
Date: Sun, 23 Mar 2008 20:18:20 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <ea7b9c170803232012n2f27f893tf1d756d7c9770419@mail.gmail.com>

On Mon, Mar 24, 2008 at 2:14 AM, Joerg Sonnenberger
<joerg at britannica.bec.de> wrote:
> On Sun, Mar 23, 2008 at 01:41:42PM -0400, Chris Turner wrote:
>  > they should change the phrase from RTFM to 'Carefully RTFM' :)
>
>  RTFMAI -- Read The Fine Manual Again, Idiot.

http://leaf.dragonflybsd.org/~sephe/rtfm.jpg

:D

>
>  Joerg
>



-- 
Live Free or Die




From justin at shiningsilence.com  Sun Mar 23 20:38:30 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Sun, 23 Mar 2008 20:38:30 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: GSoC 2008 - mentors signup
Message-ID: <53885.192.168.0.252.1206329503.squirrel@www.shiningsilence.com>

If you are planning to be a mentor for a Summer of Code project, please
sign up here for the mentors mailing list:

http://groups.google.com/group/google-summer-of-code-mentors-list

If you've already signed up, your subscription should be set up tomorrow.





From justin at shiningsilence.com  Sun Mar 23 21:12:01 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Sun, 23 Mar 2008 21:12:01 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: GSoC 2008 - mentors signup
In-Reply-To: <53885.192.168.0.252.1206329503.squirrel@www.shiningsilence.com>
Message-ID: <54025.192.168.0.252.1206331572.squirrel@www.shiningsilence.com>

Also!

If you are a potential mentor and you have not done so yet:

http://code.google.com/soc/mentor_step1.html

Get yourself registered as a mentor for the Summer of Code project.  Once
you are in there, check off DragonFly in the "My Profile" section.

You will need a Google Account if you don't have one:

http://www.google.com/accounts

This will add you to the list of mentors in the Google Summer of Code web
application, so you can review/be attached to projects.

A guide is available if you want more information:

http://groups.google.com/group/google-summer-of-code-announce/web/guide-to-the-gsoc-web-app-for-mentors-and-organization-administrators






From c.turner at 199technologies.org  Mon Mar 24 04:29:28 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Mon, 24 Mar 2008 04:29:28 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <47E78ECE.4070307@199technologies.org>

Justin C. Sherrill wrote:
If you don't need a jail to spoof uname, as others posted, you can
installworld into a chroot and build everything you want there using
Joerg's spiffy pbulk.  That's what I'm doing on pkgbox now; I can hand you
my somewhat terse notes if you want.  It would be relatively easy to set
up the configuration you're talking about.
cheers - I guess I thought incorrectly that something 'special' was 
needed to get the uname to change .. have been using the legacy bulks in 
chroots / jails (for 'same os' builds) as I haven't quite migrated to 
pbulk yet ..

thanks for the help offer - I'll ask if I run into trouble.




From dillon at apollo.backplane.com  Mon Mar 24 08:28:49 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Mon, 24 Mar 2008 08:28:49 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <200803241500.m2OF0CG8043760@apollo.backplane.com>


:http://leaf.dragonflybsd.org/~sephe/rtfm.jpg
:
::D

    Ho!

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From elekktretterr at exemail.com.au  Mon Mar 24 09:10:15 2008
From: elekktretterr at exemail.com.au (Petr Janda)
Date: Mon, 24 Mar 2008 09:10:15 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
In-Reply-To: <200803240257.m2O2voNH038355@apollo.backplane.com>
Message-ID: <200803250138.49775.elekktretterr@exemail.com.au>


>
>     And, as you know, fully coherent filesystem access across machines is
>     going to be the basis for DragonFly's clustering across said machines.
>
>     In summary, things are progressing very well.
>


Hi Matt,
That's good to know things are going so well. Got a question. If memory serves 
me right, initially there was also going to be a thing called ANVIL, I can't 
remember what it was supposed to do and whether its still in your design. 
Could you elaborate a little?

Thanks,
Petr




From dillon at apollo.backplane.com  Mon Mar 24 14:12:11 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Mon, 24 Mar 2008 14:12:11 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
In-Reply-To: <200803240257.m2O2voNH038355@apollo.backplane.com>
Message-ID: <200803242100.m2OL0nWV046868@apollo.backplane.com>


:Hi Matt,
:That's good to know things are going so well. Got a question. If memory serves 
:me right, initially there was also going to be a thing called ANVIL, I can't 
:remember what it was supposed to do and whether its still in your design. 
:Could you elaborate a little?
:
:Thanks,
:Petr

    It's not really in the HAMMER design any more, primarily because HAMMER's
    volume model seems to work fine as-is.  Ultimately something like ANVIL
    (a block storage manager) would prove beneficial to the project but it
    would be treated as a separate project.  HAMMER's redundancy model is
    going to be baesd around replication and clustering.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From tgen at netphreax.net  Mon Mar 24 18:31:37 2008
From: tgen at netphreax.net (Thomas E. Spanjaard)
Date: Mon, 24 Mar 2008 18:31:37 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
In-Reply-To: <200803240257.m2O2voNH038355@apollo.backplane.com>
Message-ID: <47E85337.2070407@netphreax.net>

Matthew Dillon wrote:
    * Full historical access appears to be working but needs testing.
      Note that a sync is still needed to flush dirty cached data prior
      to acquiring a timestamp for the 'snapshot' to be set in stone.
      (dirty data cached in-memory has no historical tags and must be
      committed to physical disk before it can be accessed historically).
Wouldn't making timestamp queries (at least from userland) enforce a 
sync on the volume in question be useful here?
--
        Thomas E. Spanjaard
        tgen at netphreax.net
Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00005.pgp
Type: application/octet-stream
Size: 186 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080324/3077333f/attachment-0011.obj>

From dillon at apollo.backplane.com  Mon Mar 24 20:10:12 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Mon, 24 Mar 2008 20:10:12 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
In-Reply-To: <200803240257.m2O2voNH038355@apollo.backplane.com>
Message-ID: <200803250302.m2P32qLP050160@apollo.backplane.com>


:Wouldn't making timestamp queries (at least from userland) enforce a 
:sync on the volume in question be useful here?
:-- 
:         Thomas E. Spanjaard
:         tgen at netphreax.net

    Making the 'hammer now' command do a sync() is a good idea.  I will
    make that change right now so it doesn't get lost.

    Here's a general overview of the issues involved with having historical
    access to the filesystem:

				----------------

    Recording the timestamps in the in-memory cache, for a finer-grained
    snapshot capability, is doable but has its own issues.  Here's an
    illustration:

    open()  create file
    write() append 4K	(file size now 4K)
    write() append 4K	(file size now 8K)
    write() append 4K	(file size now 12K)
    write() append 4K	(file size now 16K)

    Now NONE of this has gone to disk yet, it's entirely in the in-memory
    cache.  The inode is in the in-memory cache.  The data is stored in
    the buffer cache.  Even the directory entry for the file that we
    just created is still in the in-memory cache (HAMMER caches the raw
    records it intends to commit later on).

    If I wanted to be able to acquire a timestamp between each write and
    'see' a snapshot of the file as of any point in the above sequence,
    then every write would also have to allocate a copy of the inode
    (because it changes size on each write).

    The data has the same problem though with a slightly different example.
    Lets say each write() was a seek-write, overwriting the previous data.
    Now with every write() I would have to allocate a copy of the data
    being overwritten.  This is complicated by the fact that the buffer
    cache has no clue about 'historical' accesses, so I would not be able
    to use the buffer cache to cache the data.

    There's also another problem and that is with the efficiency of the
    topology on-disk.  Even if I maintained all the copies of the inode
    and all the copies of the data in-memory, I would still have to sync
    all those copies to disk in order for things to remain historically
    coherent (whether it be in-cache or on-disk).  This would result in
    hundreds or even thousands of copies of the inode on-disk, not to
    mention potentially many copies of the data.

    I just don't want to do that right now, at least not as a default.  A
    lot of performance would be lost.  Hence a sync() is needed if
    you want to create a demark which you can accurately snapshot.

				-------------

    Here's a quick synopsis of how the cache would operate in a clustered
    filesystem:

    In order to properly integrate with in-memory caches, a wider cache
    coherency infrastructure is needed between machines such that
    modifications made on one machine proactively invalidate those
    protions of the cache(s) on other machines.  At the same time, any
    'dirty' cache data, for example when a file is created or written to,
    must lock the cache space in question on all other machines.
    The cache space in this case is not just the file data, but also the
    related namespaces (for creations, deletions, and renames).  Attempts
    to access locked spaces from other machines in the cluster would have
    to force a flush to the filesystem backing store and lower the cache
    states for the effected information on the original machine from dirty
    to shared-read-only.

    It will be easiest to integrate the cache coherency information into
    the buffer cache and namecache themselves.  Once a machine has dirtied
    an in-memory cache element... for example part of the namespace when
    creating a file or chunks of data written within a file, that machine
    must have a free hand to make further modifications to the cache spaces
    involved without further interaction with other machines.

				-------------

    Now, if you think of those two major elements you can see that they
    actually fit together quite well.  If I were to attempt to maintain
    transactional coherency on a per-system-call basis then the cache
    granularity between machines would have to be much, much smaller then
    our current in-memory caching elements provide.  That would become
    a really nasty coding problem.  So I don't even want to begin to
    complate transactional coherency at a finer-grain then sync() or
    fsync() until long after we actually have clustering working.

						-Matt





From elekktretterr at exemail.com.au  Mon Mar 24 21:56:58 2008
From: elekktretterr at exemail.com.au (Petr Janda)
Date: Mon, 24 Mar 2008 21:56:58 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
In-Reply-To: <200803240257.m2O2voNH038355@apollo.backplane.com>
Message-ID: <200803251516.16407.elekktretterr@exemail.com.au>

So is it needed to run hammer now in order to "create" a snapshot? What would 
I do in situation like this: got a hammer filesystem and couple of the files 
change on day to day basis. Then a week later I needed to access one of the 
files, in exactly the state they were 7 days ago.

Cheers,
Petr




From dillon at apollo.backplane.com  Mon Mar 24 22:34:15 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Mon, 24 Mar 2008 22:34:15 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
In-Reply-To: <200803240257.m2O2voNH038355@apollo.backplane.com>
Message-ID: <200803250526.m2P5QZ5X051081@apollo.backplane.com>


:So is it needed to run hammer now in order to "create" a snapshot? What would 
:I do in situation like this: got a hammer filesystem and couple of the files 
:change on day to day basis. Then a week later I needed to access one of the 
:files, in exactly the state they were 7 days ago.
:
:Cheers,
:Petr

    No, you do not have to run 'hammer now' to create a snapshot.  The
    kernel syncs all filesystems every 30 seconds, so if you do nothing
    at all you get a snapshot granularity of 30 seconds.

    Where you would use 'hammer now' is if you wanted the most current
    snapshot possible for the purpose of, say, backing up your filesystem
    to another machine.  You might do something like this:

	set timestamp = `hammer now`
	cpdup /mountpoint/@@$timestamp targethost:/somepath

    But if you didn't care about that you could just go back far enough
    that you get a stable historical view... e.g. go back 1 minute and you
    would have a stable view into your filesystem.

	set timestamp = `hammer stamp 60s`		<------ doesn't sync
	cpdup /mountpoint/@@$timestamp targethost:/somepath


    Ultimately the idea of managing filesystems this way is to still do
    regular backups from your production machine to your backup machine
    (ultimately by way of replication), with both running HAMMER, but only
    retain a limited amount of history on the production box.  You might
    desire to retain only one week's worth of history on the production box,
    retain one month's history on your local backup box, and retain a very
    granular one year's worth of history on your remote backup box.

    Come to think of it, I should add some more directives to the
    'hammer prune' command to make that easier to specify.

    Until I implement a live replication 'feed' the minimum granularity on
    the backup box will be how often you do your backups (e.g. once a day),
    and you can prune it into more granular forms from that starting point.
    Once we have a live replication feed the backup box will have the same
    30-second granularity that the production machine has.

    A major bullet point for this style of management is that the retention
    policy on the various boxes can be different even though they are
    all slaved off the same production filesystem.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From justin at shiningsilence.com  Tue Mar 25 05:58:49 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Tue, 25 Mar 2008 05:58:49 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: SoC - student signups
Message-ID: <58180.65.106.147.226.1206449676.squirrel@www.shiningsilence.com>

Here's a quick link roundup:

Are you a student?  Put in your application for a Google Summer of Code here:

http://code.google.com/soc/2008/student_signup.html

Student guide:
http://groups.google.com/group/google-summer-of-code-announce/web/guide-to-the-gsoc-web-app-for-student-applicants

Are you a mentor?  (That means hasso, hsu, sephe, matthias, TGEN, and
corecode right now)

Student proposals will show up on the mentor page, linked below.  You will
get to rate them, and take the one(s) that you want to mentor.

Mentor page:
http://code.google.com/soc/2008/mentor_home.html
Mentor guide:
http://groups.google.com/group/google-summer-of-code-announce/web/guide-to-the-gsoc-web-app-for-mentors-and-organization-administrators

If you are a mentor and are communicating with potential students, send
them the URLs above for student signup and the student guide; work with
them if they ask for advice on what to say in the application.  They can
resubmit up to 20 times if they want to correct it.

Deadline is March 31st.






From noah.yan at gmail.com  Thu Mar 27 20:17:48 2008
From: noah.yan at gmail.com (Yonghong Yan)
Date: Thu, 27 Mar 2008 20:17:48 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: About DFBSD.64
In-Reply-To: <47EB0B5B.5020802@gmail.com>
Message-ID: <59521b110803272015y1cc8cc39uc93f154ed36e0505@mail.gmail.com>

thanks for your interest.

I owe to everybody for any update or work in the past four months. so
many things happen in my work and my family (they are all good:) and
keep me extremely busy. But i am not leaving and will be back on this
soon.

the latest sources are in http://repo.or.cz/w/dragonfly/port-amd64.git
, I did have a compiled kernel long time before, but I have to break
it to work on the pmap. you can pick up from there. TGEN will help you
a lot, also keep me posted too, if you like.

Noah

On Wed, Mar 26, 2008 at 9:50 PM, Sdavtaker <sdavtaker at gmail.com> wrote:
> Hello,
>  Im applying to GSoC to work in the x64 version of DFBSD with TGEN, i
>  found some work already done in the repository and some mails in the
>  archive from you.
>  I was wondering if you already had a working compiled kernel in AMD64
>  machine and what was not working yet to continue that work.
>  Thanks for any info.
>  Sdav
>




From dillon at apollo.backplane.com  Sat Mar 29 13:27:43 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Sat, 29 Mar 2008 13:27:43 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 29-Mar-2008
Message-ID: <200803292022.m2TKMLGe004942@apollo.backplane.com>

    Good progress continues to be made.  HAMMER survived acting as my
    LAN backup machine (in full historical mode) for almost a week before
    it hit an assertion.  I've fixed that issue and believe that the core
    filesystem implementation code is now 'very stable'.

    Note that the recent commit will result in many more 'hammer_lock_ex:'
    messages on the console then you may have previously observed.  This is
    due to the way object id's are allocated in the face of parallel 
    modifications to the filesystem, resulting in too much locality of
    reference in the B-Tree.  I do intend to improve it.

    I am still working on the two major items needed before HAMMER can be
    declared operational, those being the filesystem full handling and the
    undo/recovery-on-mount code.  These are the last 'hard' bits left in
    the design.

    With exception to filling up the filesystem, which *will* create a mess,
    and noting that no crash recovery code exists yet (so you have to newfs
    it if you crash), I'd appreciate it if interested parties could test
    the other functions of the filesystem, in particular the pruning and
    reblocking functions (man hammer), and the historical access functions.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From dillon at apollo.backplane.com  Sun Mar 30 15:11:03 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Sun, 30 Mar 2008 15:11:03 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Need ideas on how to solve an st_ino/st_dev test issue for HAMMER.
Message-ID: <200803302207.m2UM7BCp016402@apollo.backplane.com>

    Here's the problem, given historical access softlinks as shown below:

test30# ls -lda cra*
drwxr-xr-x  1 root  wheel  Mar 29 13:04 crater
lrwxr-xr-x  1 root  wheel  Mar 29 18:57 crater.20080329 -> crater@@0x47eef383
lrwxr-xr-x  1 root  wheel  Mar 30 01:24 crater.20080330 -> crater@@0x47ef4e29
-rw-r--r--  2 root  wheel  Mar 30 01:24 crater.log

    The problem is that if I do this:

    diff -r crater.20080329/var/log crater.20080330/var/log

    Diff just returns without actually diffing anything.  The reason is
    because diff checks st_ino and st_dev and believes the directories/files
    to be identical because they match.

    I considered munging the inode number for historical accesses, but
    that would seriously break NFS exports which try to access historical
    files and directories.  Right now NFS *is* able to distinguish between
    the two because NFS handles are 128-bit-wide entities, so I can encode
    the as-of transaction id as part of the filehandle.  But userland
    programs only have access to a 64-bit-wide inode so userland still
    believes the files to be identical.

    st_dev is only 32 bits, carefully munging it is an option if we
    could figure out a way to do it, but I'd rather not.

    I am considering using st_gen but then we'd have to patch third
    party software to test st_gen along with everything else.  This may
    be the only workable solution, though, and only a few programs would
    need to be patched.  st_gen is only 32 bits but it would solve the
    problem as we would be able to use all 32 bits.

    If anyone has any bright ideas, including 'leave it alone', I'm all
    ears.

						-Matt





From justin at shiningsilence.com  Mon Mar 31 10:40:42 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Mon, 31 Mar 2008 10:40:42 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: SoC student applications due by 5PM PDT tomorrow
In-Reply-To: <1942.192.168.0.242.1206930479.squirrel@www.shiningsilence.com>
Message-ID: <11892.67.108.184.175.1206984967.squirrel@www.shiningsilence.com>

On Sun, March 30, 2008 10:27 pm, Justin C. Sherrill wrote:
> SoC students:
>
> If you have an application to submit for DragonFly/Summer of Code, please
> do so by 17:00 Pacific time on the 31st - that's tomorrow, at least for
> me.

The deadline for student proposals has been extended to April 7th; all
other dates move forward one week to acommodate.

This is a good time to update existing applications or submit new ones. 
Talk to your (potential) mentors if you are curious.






From nthery at gmail.com  Mon Mar 31 11:29:49 2008
From: nthery at gmail.com (Nicolas Thery)
Date: Mon, 31 Mar 2008 11:29:49 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
Message-ID: <64fc43b0803311126na7d0b27obaa9d35bac6d32ee@mail.gmail.com>

Hello,

Now that the release is over, I'll try to get rid of zones and migrate
allocations to objcache.

Here is a 1st patch that migrate struct proc.  I'll commit it in a
couple of days if nobody objects.

I'm also implementing a way to monitor objcache statistics.  So far,
I've hacked sth similar to
sysctl vm.zone: stats are returned in one giant string, one line per
cache.  That's simple but ugly and hard to read because there are
quite a few stats per cache.

So I'm thinking about implementing a small tool, ocstat, that extracts
stats from sysctl the way ps(1) does (thru libkvm iirc) and formats it
in various ways.  What do you think?

Cheers,
Nicolas

Index: src2/sys/kern/kern_exit.c
===================================================================
--- src2.orig/sys/kern/kern_exit.c	2008-03-31 08:05:59.139796000 +0200
+++ src2/sys/kern/kern_exit.c	2008-03-31 10:31:39.000000000 +0200
@@ -834,7 +834,7 @@ loop:
 			}

 			vm_waitproc(p);
-			zfree(proc_zone, p);
+			objcache_put(proc_cache, p);
 			nprocs--;
 			return (0);
 		}
Index: src2/sys/kern/kern_proc.c
===================================================================
--- src2.orig/sys/kern/kern_proc.c	2008-03-31 08:05:59.139918000 +0200
+++ src2/sys/kern/kern_proc.c	2008-03-31 10:31:39.000000000 +0200
@@ -84,7 +84,7 @@ u_long pgrphash;
 struct proclist allproc;
 struct proclist zombproc;
 struct spinlock allproc_spin;
-vm_zone_t proc_zone;
+struct objcache* proc_cache;
 vm_zone_t lwp_zone;
 vm_zone_t thread_zone;

@@ -131,7 +131,7 @@ procinit(void)
 	spin_init(&allproc_spin);
 	pidhashtbl = hashinit(maxproc / 4, M_PROC, &pidhash);
 	pgrphashtbl = hashinit(maxproc / 4, M_PROC, &pgrphash);
-	proc_zone = zinit("PROC", sizeof (struct proc), 0, 0, 5);
+	proc_cache = objcache_create_simple(M_PROC, sizeof(struct proc));
 	lwp_zone = zinit("LWP", sizeof (struct lwp), 0, 0, 5);
 	thread_zone = zinit("THREAD", sizeof (struct thread), 0, 0, 5);
 	uihashinit();
Index: src2/sys/sys/proc.h
===================================================================
--- src2.orig/sys/sys/proc.h	2008-03-31 08:05:59.140325000 +0200
+++ src2/sys/sys/proc.h	2008-03-31 10:31:39.000000000 +0200
@@ -473,7 +473,7 @@ struct proc *zpfind (pid_t);	/* Find zom
 struct vm_zone;
 struct globaldata;
 struct lwp_params;
-extern struct vm_zone *proc_zone;
+extern struct objcache *proc_cache;
 extern struct vm_zone *lwp_zone;

 int	enterpgrp (struct proc *p, pid_t pgid, int mksess);
Index: src2/sys/kern/kern_fork.c
===================================================================
--- src2.orig/sys/kern/kern_fork.c	2008-03-31 08:05:59.140042000 +0200
+++ src2/sys/kern/kern_fork.c	2008-03-31 10:31:39.000000000 +0200
@@ -332,7 +332,7 @@ fork1(struct lwp *lp1, int flags, struct
 	}

 	/* Allocate new proc. */
-	p2 = zalloc(proc_zone);
+	p2 = objcache_get(proc_cache, M_WAITOK);
 	bzero(p2, sizeof(*p2));

 	/*




From hsu at dragonflybsd.org  Mon Mar 31 11:44:34 2008
From: hsu at dragonflybsd.org (Jeffrey Hsu)
Date: Mon, 31 Mar 2008 11:44:34 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <64fc43b0803311126na7d0b27obaa9d35bac6d32ee@mail.gmail.com>
Message-ID: <200803311841.m2VIfQAI007579@nlpi001.prodigy.net>

The object cache is not a general-purpose memory allocator.  It's a cache of
pre-initialized objects.  Are the significant portions of the proc structure
that can be restored to initialized state on object puts?  If not, it's best
to just use a general-purpose memory allocator.

								Jeffrey




From corecode at fs.ei.tum.de  Mon Mar 31 12:07:02 2008
From: corecode at fs.ei.tum.de (Simon 'corecode' Schubert)
Date: Mon, 31 Mar 2008 12:07:02 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <200803311841.m2VIfQAI007579@nlpi001.prodigy.net>
Message-ID: <47F1357B.1070302@fs.ei.tum.de>

Jeffrey Hsu wrote:
> The object cache is not a general-purpose memory allocator.  It's a cache of
> pre-initialized objects.  Are the significant portions of the proc structure
> that can be restored to initialized state on object puts?  If not, it's best
> to just use a general-purpose memory allocator.

Why?  What's the loss if we use the object cache to allocate struct procs?

cheers
  simon

Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00006.pgp
Type: application/octet-stream
Size: 252 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080331/a4a24314/attachment-0011.obj>

From nthery at gmail.com  Mon Mar 31 12:17:03 2008
From: nthery at gmail.com (Nicolas Thery)
Date: Mon, 31 Mar 2008 12:17:03 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <nthery@gmail.com>
Message-ID: <64fc43b0803311214u7da6bbb8xaf971de1a80e7258@mail.gmail.com>

2008/3/31, Jeffrey Hsu <hsu at dragonflybsd.org>:
> The object cache is not a general-purpose memory allocator.  It's a cache of
>  pre-initialized objects.  Are the significant portions of the proc structure
>  that can be restored to initialized state on object puts?  If not, it's best
>  to just use a general-purpose memory allocator.

Well, I haven't checked this yet.  I planned to do this in a second
step after getting rid of zones.

I thought that even without  the pre-initialization part, objcache has
the advantage
of pre-allocating set of objects (as zones) and is additionally
mp-safe (contrary to zones and, granted, as malloc()).   The latter
may be interesting as we talk of improving MP support.

Cheers,
Nicolas




From dillon at apollo.backplane.com  Mon Mar 31 12:23:40 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Mon, 31 Mar 2008 12:23:40 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <200803311841.m2VIfQAI007579@nlpi001.prodigy.net>
Message-ID: <200803311921.m2VJLITB027669@apollo.backplane.com>

    I both agree and disagree with Jeff.  I think the only *disadvantage*
    to using objcache for struct proc is that objcache must cache a minimum
    number of free structures to be efficient so the overall kernel memory
    use would be a bit greater verses uses kmalloc().  But I agree with Jeff
    in that objcache's biggest advantage is that you can keep structural state
    intact and struct proc might not be a good candidate (yet).

    What I suggest is that you convert struct proc from zone to kmalloc
    first, and then look into a possible objcache adaptation.  kmalloc
    is not slow.. it's a very fast allocator.  Objcache is probably a tad
    faster but not by much.  Where objcache really wins is in not having
    to completey reinitialize the allocated structures.

    Over the years I've removed (I think) all the dependancies on requiring
    the proc structure to be in stable memory so I believe it can be moved to
    kmalloc/objcache now without any major pain.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From corecode at fs.ei.tum.de  Mon Mar 31 12:37:40 2008
From: corecode at fs.ei.tum.de (Simon 'corecode' Schubert)
Date: Mon, 31 Mar 2008 12:37:40 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: SoC student applications due by 5PM PDT tomorrow
In-Reply-To: <1942.192.168.0.242.1206930479.squirrel@www.shiningsilence.com>
Message-ID: <47F13CDA.6010703@fs.ei.tum.de>

Justin C. Sherrill wrote:
> On Sun, March 30, 2008 10:27 pm, Justin C. Sherrill wrote:
>> SoC students:
>>
>> If you have an application to submit for DragonFly/Summer of Code, please
>> do so by 17:00 Pacific time on the 31st - that's tomorrow, at least for
>> me.
> The deadline for student proposals has been extended to April 7th; all
> other dates move forward one week to acommodate.

This is very good.

Some more ideas for eager students (we want to keep the ratio, right?):

Enhance the FreeBSD/DragonFly sound infrastructure to support surround
sound/multichannel output.

Update sound drivers to support S/PDIF output.

Make the sound infrastructure OSSv4 compatible (there was a SoC at
FreeBSD last year or so)


of course only if it doesn't exist already :)

cheers
  simon


Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00007.pgp
Type: application/octet-stream
Size: 252 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080331/6da61cff/attachment-0011.obj>

From corecode at fs.ei.tum.de  Mon Mar 31 12:41:30 2008
From: corecode at fs.ei.tum.de (Simon 'corecode' Schubert)
Date: Mon, 31 Mar 2008 12:41:30 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <200803311841.m2VIfQAI007579@nlpi001.prodigy.net>
Message-ID: <47F13DE4.10205@fs.ei.tum.de>

Matthew Dillon wrote:
>     What I suggest is that you convert struct proc from zone to kmalloc
>     first, and then look into a possible objcache adaptation.  kmalloc
>     is not slow.. it's a very fast allocator.  Objcache is probably a tad
>     faster but not by much.  Where objcache really wins is in not having
>     to completey reinitialize the allocated structures.

Could we please not move to kmalloc, but instead try to move all fast
path allocations to objcache?  I don't like the idea of allocating
everything with kmalloc.  Caching struct procs is not a bad thing itself.

cheers
  simon


Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00008.pgp
Type: application/octet-stream
Size: 252 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080331/ac328c08/attachment-0011.obj>

From hsu at FreeBSD.org  Mon Mar 31 12:59:05 2008
From: hsu at FreeBSD.org (Jeffrey Hsu)
Date: Mon, 31 Mar 2008 12:59:05 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <47F1357B.1070302@fs.ei.tum.de>
Message-ID: <200803311920.m2VJK5Ln018015@nlpi015.prodigy.net>

The object cache sits on top of a general-purpose memory allocator such
as kmalloc or zalloc and provides pre-initialized object caching functionality.
If you're not going to use the object caching functionality, you can just
call the underlying memory allocator directly.

							Jeffrey




From dillon at apollo.backplane.com  Mon Mar 31 16:17:19 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Mon, 31 Mar 2008 16:17:19 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <200803311841.m2VIfQAI007579@nlpi001.prodigy.net>
Message-ID: <200803312311.m2VNBumd029866@apollo.backplane.com>

:Could we please not move to kmalloc, but instead try to move all fast
:path allocations to objcache?  I don't like the idea of allocating
:everything with kmalloc.  Caching struct procs is not a bad thing itself.=
:
:
:cheers
:  simon

    I will state for the record that I'm fine with either objcache or
    kmalloc.  I agree with Jeff that using objcache for struct proc
    probably isn't necessary but I also agree that it would not hurt either,
    and if the intent is to optimize the initialization of the proc
    structure in the future then moving to objcache now would save us
    from having to do it later.

    So whichever method Nicolas wants to use is fine with me.

						-Matt




From hsu at dragonflybsd.org  Mon Mar 31 19:22:47 2008
From: hsu at dragonflybsd.org (Jeffrey Hsu)
Date: Mon, 31 Mar 2008 19:22:47 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <64fc43b0803311214u7da6bbb8xaf971de1a80e7258@mail.gmail.com>
Message-ID: <200804010218.m312IVUq003624@nlpi043.prodigy.net>

  >> Are there significant portions of the proc structure
  >> that can be restored to initialized state on object puts?

  > I planned to do this in a second step after getting rid of zones.

I'll all in favor of making more use of caching pre-initialized objects, so
if this is your objective, then please go ahead.  It's just that I'd convert
over to the object cache in one step.

  > I thought that even without  the pre-initialization part, objcache has
  > the advantage of pre-allocating set of objects (as zones) and is additionally
  > mp-safe (contrary to zones and, granted, as malloc()).

Well, the zone allocator is MP-safe.  It's not hard to lock up the places that
manipulate the linked-list of free items. Look for uses of the zlock field.

								Jeffrey




From tgen at netphreax.net  Sat Mar  1 12:57:53 2008
From: tgen at netphreax.net (Thomas E. Spanjaard)
Date: Sat, 1 Mar 2008 12:57:53 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: [Fwd: Project Support Open Source: $50 donation to support you      project]
In-Reply-To: <2468.192.168.0.242.1204346451.squirrel@www.shiningsilence.com>
Message-ID: <47C9C1B7.50203@netphreax.net>

Justin C. Sherrill wrote:
The "donation" happens after you place an "acknowledgement" on an open
source project's web page.  I'm putting those words in scare quotes
because I think it's a "payment" for an "advertisement".  The supplied
link has nothing to do with DragonFly, to say the least.

<a href="http://www.2insure4less.com /" title="We support FOSS software
projects.">Online Insurance Quotes</a>
To think our souls are only worth $50...
--
        Thomas E. Spanjaard
        tgen at netphreax.net
Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00000.pgp
Type: application/octet-stream
Size: 186 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080301/0d61e240/attachment-0012.obj>

From c.turner at 199technologies.org  Sat Mar  1 17:52:31 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Sat, 1 Mar 2008 17:52:31 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Misc. ACPI / suspend
Message-ID: <47CA073B.6020106@199technologies.org>

Wondering if anyone more well versed in the ACPI implementation could
comment on the applicability of:
http://lkml.org/lkml/2007/4/6/69

w/r/t the current state of the art in Dfly

(or BSD's in general)

Cheers!

- Chris




From elekktretterr at exemail.com.au  Sun Mar  2 00:41:25 2008
From: elekktretterr at exemail.com.au (Petr Janda)
Date: Sun, 2 Mar 2008 00:41:25 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: CARP question
Message-ID: <200803021934.21669.elekktretterr@exemail.com.au>

So Ive setup CARP on 2 DF-based mailservers. Installation went fine. Box 1 has 
adskew of 0 therefore it is the MASTER. Box 2 has adskew of 254, therefore is 
BACKUP.  If i down the carp0 interface on Box 1, then Box 2 carp interface 
gets promoted to MASTER. Then I up the carp interface on Box 1, logically Box 
2 should become BACKUP again as Box 1 becomes MASTER due to adskew set to 0.

However it doesnt happen. When carp0 interface on Box 1 is upped it becomes a 
BACKUP, not a MASTER even though according to adskew it should be MASTER.

What is the desired behaviour?

Cheers
Petr




From qhwt+dfly at les.ath.cx  Sun Mar  2 02:50:14 2008
From: qhwt+dfly at les.ath.cx (YONETANI Tomokazu)
Date: Sun, 2 Mar 2008 02:50:14 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: panic: assertion: hammer_btree_cmp(cursor->left_bound,	&cursor->node->ondisk->elms[0].leaf.base) <= 0 in btree_split_leaf
In-Reply-To: <200802232204.m1NM4cxd046264@apollo.backplane.com>
Message-ID: <20080302104554.GA22813@les.ath.cx>

Hi.
While trying to find a procedure to reliably reproduce the panic
I reported last time, I caught a different panic (uploaded at
 ~y0netan1/crash/9/ on my leaf account).  I wrote the following shell
script (make sure to edit variables DISKS and MOUNTPT before using this
script or it may trash your system):
  #!/bin/sh -ex
  DISKS="/dev/ad0s1f"
  MOUNTPT=/mnt/HAMMER

  cd /
  newfs_hammer -L TEST $DISKS
  for i in `seq 1 100`; do
	  mount_hammer $DISKS $MOUNTPT
	  /bin/rm -rf $MOUNTPT/??
	  (set +x; for x in `seq 1 10000`; do echo -n > $MOUNTPT/$x; done)
	  umount $MOUNTPT
  done

And the panic is triggered by rm command.
I'll try to see if it's possible to reproduce the last one without
unmounting then mounting the HAMMER fs.

Cheers.




From dillon at apollo.backplane.com  Sun Mar  2 13:25:33 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Sun, 2 Mar 2008 13:25:33 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: panic: assertion: hammer_btree_cmp(cursor->left_bound,	&cursor->node->ondisk->elms[0].leaf.base) <= 0 in btree_split_leaf
In-Reply-To: <200802232204.m1NM4cxd046264@apollo.backplane.com>
Message-ID: <200803022119.m22LJRCY037076@apollo.backplane.com>


:Hi.
:While trying to find a procedure to reliably reproduce the panic
:I reported last time, I caught a different panic (uploaded at
: ~y0netan1/crash/9/ on my leaf account).  I wrote the following shell
:script (make sure to edit variables DISKS and MOUNTPT before using this
:script or it may trash your system):

(from the core)

panic: assertion: node->lock.refs == 0 && node->ondisk == NULL in hammer_flush_buffer_nodes

    Yah, I've seen this failure.  Add a sync or two before the umount and
    tell me if it still occurs.  It's either a node reference leak somewhere
    or it is a race between bufdaemon and umount.  The assertions are really
    strict there precisely to catch those sorts of cases.

    Also note that the code to deal with a full HAMMMER filesystem has not
    been written yet (The failure you are reporting is unrelated to a full
    HAMMER filesystem, though, just mentioning it).

						-Matt





From dillon at apollo.backplane.com  Sun Mar  2 13:29:03 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Sun, 2 Mar 2008 13:29:03 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Misc. ACPI / suspend
In-Reply-To: <47CA073B.6020106@199technologies.org>
Message-ID: <200803022126.m22LQbfI037188@apollo.backplane.com>


:Wondering if anyone more well versed in the ACPI implementation could
:comment on the applicability of:
:
:http://lkml.org/lkml/2007/4/6/69
:
:w/r/t the current state of the art in Dfly
:
:(or BSD's in general)
:
:Cheers!
:
:- Chris

    I really have no idea re: this.  Suspension in general is not well
    supported by any of the BSDs.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From dillon at apollo.backplane.com  Sun Mar  2 13:34:05 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Sun, 2 Mar 2008 13:34:05 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: [Fwd: Project Support Open Source: $50 donation to support you      project]
In-Reply-To: <2468.192.168.0.242.1204346451.squirrel@www.shiningsilence.com>
Message-ID: <200803022131.m22LVOe9037250@apollo.backplane.com>

:..
:source project's web page.  I'm putting those words in scare quotes
:because I think it's a "payment" for an "advertisement".  The supplied
:link has nothing to do with DragonFly, to say the least.
:
:I don't think this is a good idea, obviously, and replied to that effect. 
:However, I wanted to put this on a DragonFly list, in part to show this
:strange thing, and in part because I'm not comfortable making
:administrative decisions on behalf of the Project without being open as
:possible about it.

    It doesn't really cry out to me either.

						-Matt





From wbh at conducive.org  Sun Mar  2 20:36:32 2008
From: wbh at conducive.org (Bill Hacker)
Date: Mon, 03 Mar 2008 04:36:32 +0000
Subject: Misc. ACPI / suspend
In-Reply-To: <47CA073B.6020106@199technologies.org>
Message-ID: <47cb8050$0$855$415eb37d@crater_reader.dragonflybsd.org>

Matthew Dillon wrote:
:Wondering if anyone more well versed in the ACPI implementation could
:comment on the applicability of:
:
:http://lkml.org/lkml/2007/4/6/69
:
:w/r/t the current state of the art in Dfly
:
:(or BSD's in general)
:
:Cheers!
:
:- Chris
    I really have no idea re: this.  Suspension in general is not well
    supported by any of the BSDs.
					-Matt
					Matthew Dillon 
					<dillon at backplane.com>


. . and there seems to be a bit of a 'Catch 22' there in any case.

If the BIOS can alter 'stuff' out of site of the OS it is parking, what 
does the existence of such a 'feature' do to a(ny) security model?

Seems to at least beg creating the option of setting a flag to 
specifically *prevent* suspend-to-disk/hibernation (and/or force a 
reboot on wake-up).

Just because one is paranoid....  etc

Bill





From matthias at dragonflybsd.org  Tue Mar  4 02:30:52 2008
From: matthias at dragonflybsd.org (Matthias Schmidt)
Date: Tue, 4 Mar 2008 02:30:52 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
Message-ID: <20080304102335.GI9833@staatsfeind.org>

Hi,

Google just announced its Summer of Code for 2008:

	http://code.google.com/soc/2008/

I think this would be a great opportunity for DragonFly to participate
as a mentoring organisation.  We could attract new developers and could
get code/work done.  Looking at the SoC results of the other BSDs most
of their projects were a success.  Of course, not all, but a reasonable
percentage.  See [1] and [2].

It is some extra work for us, but IMO the benefits outweigh the extra
work.  And yes, I would volunteer as a mentor.  What do others
(developers) think?  Any more volunteers? :)

Some project ideas that come into my mind.  More ideas are listed in the
wiki:  http://wiki.dragonflybsd.org/index.cgi/ProjectsPage

 * Fix all remaining bugs in dma(8) and implement all missing features
 * Add a driver for newer Intel Wireless cards (I think sephe@ would
   love that :)
 * Bring our ACPI stuff in shape.  Maybe suspend2disk ...

 * [Add your own thoughts here]

Cheers,

	Matthias

PS: I don't want to create a bikeshed here whether you like the SoC or
not :)

[1] http://code.google.com/soc/2007/freebsd/about.html
[2] http://code.google.com/soc/2007/netbsd/about.html




From corecode at fs.ei.tum.de  Tue Mar  4 04:46:14 2008
From: corecode at fs.ei.tum.de (Simon 'corecode' Schubert)
Date: Tue, 4 Mar 2008 04:46:14 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47CD4386.1000704@fs.ei.tum.de>

Matthias Schmidt wrote:
>  * [Add your own thoughts here]

MP lock removal for network stack

and for the system  (first profile, find hot spots, fix hot spots, repeat)

cheers
  simon




From c.turner at 199technologies.org  Tue Mar  4 06:02:20 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Tue, 4 Mar 2008 06:02:20 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47CD551E.1040604@199technologies.org>

Matthias Schmidt wrote:
Some project ideas that come into my mind.  More ideas are listed in the
wiki:  http://wiki.dragonflybsd.org/index.cgi/ProjectsPage
+1 acpi
+1 interrupt routing
+1 SMP / giant removal
+1 pf synchup with openbsd
though there are several others on the page that are good..

need to dig up my wiki login and place appropriately..

also: thinking the ZFS port should be removed from the page - makes 
sense to everyone else? (e.g. fragments effort w/r/t hammer)





From tgen at netphreax.net  Tue Mar  4 06:54:31 2008
From: tgen at netphreax.net (Thomas E. Spanjaard)
Date: Tue, 4 Mar 2008 06:54:31 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47CD615F.8010209@netphreax.net>

Matthias Schmidt wrote:
Google just announced its Summer of Code for 2008:

 * [Add your own thoughts here]
x86-64 port :).
--
        Thomas E. Spanjaard
        tgen at netphreax.net
Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00001.pgp
Type: application/octet-stream
Size: 186 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080304/0d921000/attachment-0012.obj>

From rdivacky at FreeBSD.org  Tue Mar  4 07:07:03 2008
From: rdivacky at FreeBSD.org (Roman Divacky)
Date: Tue, 4 Mar 2008 07:07:03 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <20080304150255.GA8831@freebsd.org>

On Tue, Mar 04, 2008 at 02:49:03PM +0000, Thomas E. Spanjaard wrote:
> Matthias Schmidt wrote:
> >Google just announced its Summer of Code for 2008:
> >
> > * [Add your own thoughts here]
> 
> x86-64 port :).

all those ideas are great and needed etc. but keep in
mind that the projects should be doable by students
who might see dfly for the very first time.

don't overestimate whats possible and select projects
that look realistic

Roman Divacky (former SoC student)




From justin at shiningsilence.com  Tue Mar  4 08:32:56 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Tue, 4 Mar 2008 08:32:56 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <60322.65.106.147.226.1204648095.squirrel@www.shiningsilence.com>

On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
> Hi,
>
> Google just announced its Summer of Code for 2008:
>
> 	http://code.google.com/soc/2008/
>
> I think this would be a great opportunity for DragonFly to participate
> as a mentoring organisation.  We could attract new developers and could
> get code/work done.  Looking at the SoC results of the other BSDs most
> of their projects were a success.  Of course, not all, but a reasonable
> percentage.  See [1] and [2].

We've applied in previous years - Jeff Hsu did one year, and I put
together the application last year.  The hardest thing to find was
students (and they are the thing that helps SoC applications a lot, I
think).

Any student volunteers?  We have mentors.





From rluciani at gmail.com  Tue Mar  4 09:38:29 2008
From: rluciani at gmail.com (Robert Luciani)
Date: Tue, 04 Mar 2008 18:38:29 +0100
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47cd8915$0$854$415eb37d@crater_reader.dragonflybsd.org>

Justin C. Sherrill wrote:
> On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
>> Hi,
>>
>> Google just announced its Summer of Code for 2008:
>>
>> 	http://code.google.com/soc/2008/
>>
>> I think this would be a great opportunity for DragonFly to participate
>> as a mentoring organisation.  We could attract new developers and could
>> get code/work done.  Looking at the SoC results of the other BSDs most
>> of their projects were a success.  Of course, not all, but a reasonable
>> percentage.  See [1] and [2].
> 
> We've applied in previous years - Jeff Hsu did one year, and I put
> together the application last year.  The hardest thing to find was
> students (and they are the thing that helps SoC applications a lot, I
> think).
> 
> Any student volunteers?  We have mentors.
> 

bingo

-- 
Robert Luciani
Chalmers University of Technology, SWE
Department of Computer Science and Engineering
http://www.rluciani.com/public.key




From sdavtaker at gmail.com  Tue Mar  4 09:31:08 2008
From: sdavtaker at gmail.com (=?UTF-8?Q?Sd=C3=A4vtaker?=)
Date: Tue, 4 Mar 2008 09:31:08 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <c37d69f60803040926k206218a3kb8496d0cd18148bd@mail.gmail.com>

If you mentor, i will apply for coder :-)
Still in last year of university. :-)
Sdav

On Tue, Mar 4, 2008 at 1:28 PM, Justin C. Sherrill
<justin at shiningsilence.com> wrote:
> On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
>  > Hi,
>  >
>  > Google just announced its Summer of Code for 2008:
>  >
>  >       http://code.google.com/soc/2008/
>  >
>  > I think this would be a great opportunity for DragonFly to participate
>  > as a mentoring organisation.  We could attract new developers and could
>  > get code/work done.  Looking at the SoC results of the other BSDs most
>  > of their projects were a success.  Of course, not all, but a reasonable
>  > percentage.  See [1] and [2].
>
>  We've applied in previous years - Jeff Hsu did one year, and I put
>  together the application last year.  The hardest thing to find was
>  students (and they are the thing that helps SoC applications a lot, I
>  think).
>
>  Any student volunteers?  We have mentors.
>
>



-- 
Sd?vtaker prays to Rikku goddess for a good treasure.



From rluciani at gmail.com  Tue Mar  4 09:44:02 2008
From: rluciani at gmail.com (Robert Luciani)
Date: Tue, 04 Mar 2008 18:44:02 +0100
Subject: google soc "DragonFly"
Message-ID: <47cd8a63$0$855$415eb37d@crater_reader.dragonflybsd.org>

On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
> > Hi,
> >
> > Google just announced its Summer of Code for 2008:
> >
> > 	http://code.google.com/soc/2008/
> >
> > I think this would be a great opportunity for DragonFly to participate
> > as a mentoring organisation.  We could attract new developers and could
> > get code/work done.  Looking at the SoC results of the other BSDs most
> > of their projects were a success.  Of course, not all, but a reasonable
> > percentage.  See [1] and [2].

We've applied in previous years - Jeff Hsu did one year, and I put
together the application last year.  The hardest thing to find was
students (and they are the thing that helps SoC applications a lot, I
think).

Any student volunteers?  We have mentors.


-- 
Robert Luciani
Chalmers University of Technology, SWE
Department of Computer Science and Engineering
http://www.rluciani.com/public.key




From rluciani at gmail.com  Tue Mar  4 10:04:14 2008
From: rluciani at gmail.com (Robert Luciani)
Date: Tue, 04 Mar 2008 19:04:14 +0100
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47cd8f1f$0$856$415eb37d@crater_reader.dragonflybsd.org>

Robert Luciani wrote:
> Justin C. Sherrill wrote:
>> On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
>>> Hi,
>>>
>>> Google just announced its Summer of Code for 2008:
>>>
>>> 	http://code.google.com/soc/2008/
>>>
>>> I think this would be a great opportunity for DragonFly to participate
>>> as a mentoring organisation.  We could attract new developers and could
>>> get code/work done.  Looking at the SoC results of the other BSDs most
>>> of their projects were a success.  Of course, not all, but a reasonable
>>> percentage.  See [1] and [2].
>> We've applied in previous years - Jeff Hsu did one year, and I put
>> together the application last year.  The hardest thing to find was
>> students (and they are the thing that helps SoC applications a lot, I
>> think).
>>
>> Any student volunteers?  We have mentors.
>>
> 
> bingo
> 
My girlfriend Danwei noted that she would also like partake in the SoC.
She's studying IT here at Chalmers and will join the mailing list shortly.
-- 
Robert Luciani
Chalmers University of Technology, SWE
Department of Computer Science and Engineering
http://www.rluciani.com/public.key




From dillon at apollo.backplane.com  Tue Mar  4 13:08:30 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Tue, 4 Mar 2008 13:08:30 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Going to have to roll 1.12.1
Message-ID: <200803042104.m24L43g1065278@apollo.backplane.com>

    Due to a critical bug in sendmail that can cause it to seg-fault I will
    be rolling 1.12.1 as soon as I get verification that the current
    fix deals with it.

						-Matt





From sdavtaker at gmail.com  Tue Mar  4 17:40:43 2008
From: sdavtaker at gmail.com (=?UTF-8?B?U2TDpHZ0YWtlcg==?=)
Date: Tue, 4 Mar 2008 17:40:43 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: [Fwd: Project Support Open Source: $50 donation to support you  project]
In-Reply-To: <2468.192.168.0.242.1204346451.squirrel@www.shiningsilence.com>
Message-ID: <47CDF8D1.9070100@gmail.com>

50 bucks?
Come on...
You can get a meal a lot more expensive than that just going to a free 
HP conference about linux and you only have to rent your soul 3-5 hours ;-)
Sdav

Matthew Dillon escribi?:
:..
:source project's web page.  I'm putting those words in scare quotes
:because I think it's a "payment" for an "advertisement".  The supplied
:link has nothing to do with DragonFly, to say the least.
:
:I don't think this is a good idea, obviously, and replied to that effect. 
:However, I wanted to put this on a DragonFly list, in part to show this
:strange thing, and in part because I'm not comfortable making
:administrative decisions on behalf of the Project without being open as
:possible about it.

    It doesn't really cry out to me either.

						-Matt

  






From sdavtaker at gmail.com  Tue Mar  4 17:56:35 2008
From: sdavtaker at gmail.com (=?UTF-8?B?U2TDpHZ0YWtlcg==?=)
Date: Tue, 4 Mar 2008 17:56:35 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47CDFCCE.1010106@gmail.com>

A cute idea for for GSOC would be to finish the installer.
We were talking about this in my local BUG, we trying to find out how to 
help on that from here.
There is a few missing features in the CD.

   * FDISK, you need to create the slides from another OS before
     install DFBSD, i think port FDisk from FBSD or any *BSD will solve it.
   * Add to the make release a way to add some custom applications to
     the released liveCD (suppose you want to add nmap or ssh or
     something just to use as test disk in some enviroment).
   * Make the installer a little more customizable, and maybe w/ a GUI
     (I like a lot the console approach, but GUI installer will be a
     popularity move, DFBSD w/X makes a Desktop machine work, actually
     im using it that way and really like it).
I think those projects can be done in a SOC by students (like me) with a 
little guide.
Im a lot more interested in things network related and kernel, but i 
dont mind to work on those things, they need to be done some day.
What u think?
Sdav

Robert Luciani escribi?:
Robert Luciani wrote:
  
Justin C. Sherrill wrote:
    
On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
      
Hi,

Google just announced its Summer of Code for 2008:

	http://code.google.com/soc/2008/

I think this would be a great opportunity for DragonFly to participate
as a mentoring organisation.  We could attract new developers and could
get code/work done.  Looking at the SoC results of the other BSDs most
of their projects were a success.  Of course, not all, but a reasonable
percentage.  See [1] and [2].
        
We've applied in previous years - Jeff Hsu did one year, and I put
together the application last year.  The hardest thing to find was
students (and they are the thing that helps SoC applications a lot, I
think).
Any student volunteers?  We have mentors.

      
bingo

    
My girlfriend Danwei noted that she would also like partake in the SoC.
She's studying IT here at Chalmers and will join the mailing list shortly.
  






From c.turner at 199technologies.org  Tue Mar  4 18:30:53 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Tue, 4 Mar 2008 18:30:53 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47CE04C9.1010902@199technologies.org>

Justin C. Sherrill wrote:
together the application last year.  The hardest thing to find was
students (and they are the thing that helps SoC applications a lot, I
think).
umm.. if google wants to send me back to school, I'll sign up - hows 
that for a fair trade :?






From wbh at conducive.org  Tue Mar  4 23:52:13 2008
From: wbh at conducive.org (Bill Hacker)
Date: Wed, 05 Mar 2008 07:52:13 +0000
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47ce512e$0$855$415eb37d@crater_reader.dragonflybsd.org>

Sd?vtaker wrote:
A cute idea for for GSOC would be to finish the installer.
We were talking about this in my local BUG, we trying to find out how to 
help on that from here.
There is a few missing features in the CD.

   * FDISK, you need to create the slides from another OS before
     install DFBSD, i think port FDisk from FBSD or any *BSD will solve it.
I'd rather see that 'reversed' - i.e. - build a more capable fdisk in 
DFLY with hope that it might be seen worth importing into Free/Net/Open, 
or *at least* be able to do a more flexible job than those now do.

And disklabels as well. Hand in glove.

Here's why:

- At the moment, working with Free, Open, DFLY, and OpenSolaris on the 
same HDD requires a bit of acrobatics.

- There seems to now be greater divergence between/among the *BSD's as 
to being able to read each other's disklabels, mount and use each 
other's 'flavor' of FFS/UFS (not to mention Apple's implementation of 
UFS) than there is among the vast multitude of Linux ext2/3 denizens.

Even to the point where use of a *Linux* fs is the more universal way 
for being able to share mounts among the *BSD's. Think detached drives. 
And no - FAT is not all that practical for several reasons.

- DFLY currently has the most fine-grain ability to create slices and 
partitions. But the others cannot all (any?) read those.

'progress' w/r any of the *BSD's direction as to changes, improvements 
(or not) in their once-common-ancestry fs & disklabels need not be 
sacrificed.

I'm not holding out wish or hope for all players agreeing to return to 
'one sacred way'. Nor 'one new universal fs'. Neither is gonna happen.

But a 'legacy compatible' or least-common-denominator mode would do fine 
- most especially for portable / SAN devices.

So - how about a 'flexible' DFLY fdisk to go along with a 'flexible' 
disklabel that could adapt to whatever it found / was told to create?

JM2CW - but that *might* be a good place to get a cross-*BSD team together.

*snip* (other good stuff)

Bill Hacker




From matthias at dragonflybsd.org  Wed Mar  5 01:02:43 2008
From: matthias at dragonflybsd.org (Matthias Schmidt)
Date: Wed, 5 Mar 2008 01:02:43 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <20080305085747.GJ9833@staatsfeind.org>

Hi,

* Justin C. Sherrill wrote:
> 
> We've applied in previous years - Jeff Hsu did one year, and I put
> together the application last year.  The hardest thing to find was
> students (and they are the thing that helps SoC applications a lot, I
> think).

This is good to know, so we could coordinate that if we have enough
mentors and projects?!?  I put together a small text in the wiki:

http://wiki.dragonflybsd.org/index.cgi/GoogleSoC2008

Feel free to add project or missing stuff.  I'm sure I missed a lot of
things :)

> Any student volunteers?  We have mentors.

According to the discussion we could have some students, who would be a
mentor (besides me)?

Regards

	Matthias





From sdavtaker at gmail.com  Wed Mar  5 06:28:37 2008
From: sdavtaker at gmail.com (=?UTF-8?Q?Sd=C3=A4vtaker?=)
Date: Wed, 5 Mar 2008 06:28:37 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <c37d69f60803050624kd86d3d0w3b44a02d0e5a5391@mail.gmail.com>

<quote>
Write a driver (from scratch) for Intel 3945 wireless device
Mentor: Sepherosa Ziehau
</quote>

Yes yes yes, i want to :-)
Someone else planning to mentor in drivers coding?
Sdav

On Wed, Mar 5, 2008 at 5:57 AM, Matthias Schmidt
<matthias at dragonflybsd.org> wrote:
> Hi,
>
>
>  * Justin C. Sherrill wrote:
>  >
>  > We've applied in previous years - Jeff Hsu did one year, and I put
>  > together the application last year.  The hardest thing to find was
>  > students (and they are the thing that helps SoC applications a lot, I
>  > think).
>
>  This is good to know, so we could coordinate that if we have enough
>  mentors and projects?!?  I put together a small text in the wiki:
>
>  http://wiki.dragonflybsd.org/index.cgi/GoogleSoC2008
>
>  Feel free to add project or missing stuff.  I'm sure I missed a lot of
>  things :)
>
>
>  > Any student volunteers?  We have mentors.
>
>  According to the discussion we could have some students, who would be a
>  mentor (besides me)?
>
>  Regards
>
>         Matthias
>
>



-- 
Sd?vtaker prays to Rikku goddess for a good treasure.



From rluciani at gmail.com  Wed Mar  5 10:56:42 2008
From: rluciani at gmail.com (Robert Luciani)
Date: Wed, 05 Mar 2008 19:56:42 +0100
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47ceecea$0$847$415eb37d@crater_reader.dragonflybsd.org>

Sd?vtaker wrote:
> <quote>
> Write a driver (from scratch) for Intel 3945 wireless device
> Mentor: Sepherosa Ziehau
> </quote>
> 
> Yes yes yes, i want to :-)
> Someone else planning to mentor in drivers coding?
> Sdav
> 
> On Wed, Mar 5, 2008 at 5:57 AM, Matthias Schmidt
> <matthias at dragonflybsd.org> wrote:
>> Hi,
>>
>>
>>  * Justin C. Sherrill wrote:
>>  >
>>  > We've applied in previous years - Jeff Hsu did one year, and I put
>>  > together the application last year.  The hardest thing to find was
>>  > students (and they are the thing that helps SoC applications a lot, I
>>  > think).
>>
>>  This is good to know, so we could coordinate that if we have enough
>>  mentors and projects?!?  I put together a small text in the wiki:
>>
>>  http://wiki.dragonflybsd.org/index.cgi/GoogleSoC2008
>>
>>  Feel free to add project or missing stuff.  I'm sure I missed a lot of
>>  things :)
>>
>>
>>  > Any student volunteers?  We have mentors.
>>
>>  According to the discussion we could have some students, who would be a
>>  mentor (besides me)?
>>
>>  Regards
>>
>>         Matthias
>>
>>
> 
> 
>

IF someone starts to write a 3945 Intel driver,
please keep the newer 4965 in mind too.

-- 
Robert Luciani
Chalmers University of Technology, SWE
Department of Computer Science and Engineering
http://www.rluciani.com/public.key




From joerg at britannica.bec.de  Wed Mar  5 12:01:05 2008
From: joerg at britannica.bec.de (Joerg Sonnenberger)
Date: Wed, 5 Mar 2008 12:01:05 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <20080305195711.GA9981@britannica.bec.de>

On Wed, Mar 05, 2008 at 07:56:42PM +0100, Robert Luciani wrote:
> IF someone starts to write a 3945 Intel driver,
> please keep the newer 4965 in mind too.

NetBSD's wpi works quite well. The hardware is quite different from
4945.

Joerg




From sepherosa at gmail.com  Wed Mar  5 17:48:50 2008
From: sepherosa at gmail.com (Sepherosa Ziehau)
Date: Wed, 5 Mar 2008 17:48:50 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <ea7b9c170803051744u22b09484ofc994f034f11df3b@mail.gmail.com>

On Thu, Mar 6, 2008 at 2:56 AM, Robert Luciani <rluciani at gmail.com> wrote:
>  IF someone starts to write a 3945 Intel driver,

"IF" you know that trying to fix any wired bugs in certain drivers
(e.g. ipw, ral) will require you to read through all of the vendor's
linux code (yes, even including register values and position), i.e.
there is not much difference between writing one from scratch and
porting+fixing_bugs, then you probably will not put "IF" at the start
of your sentence.
If what I said sounded too harsh to you, then I was sorry.

>  please keep the newer 4965 in mind too.

Will do, once generic 11n support is brought in from freebsd.

Best Regards,
sephe

-- 
Live Free or Die




From saw at online.de  Thu Mar  6 05:34:14 2008
From: saw at online.de (Sascha Wildner)
Date: Thu, 06 Mar 2008 14:34:14 +0100
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
Message-ID: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>

Hi all,

this is probably as good a moment as any to come out of the forest with 
this. The patch at

http://leaf.dragonflybsd.org/~swildner/nrelease_gui.diff

adds some code to nrelease/ to build a LiveCD with xorg and so on 
(currently, only the xorg metapackages and fluxbox are added). In order 
to build one, you need a local dir with the pkgsrc binary packages (see 
below).

The following commands should then do the trick:

cd /usr/src
make buildworld
make buildkernel
cd nrelease
patch -p 0 </path/to/the/patch
make PKGSRC_PKG_PATH=/path/to/packages/dir/All realquick gui
The resulting ISO will be in /usr/release/dfly-gui.iso then. It will not 
boot into xorg automatically (although this is easily possible), so you 
need to login as root and do startx.

As of now, this all is kind of basic, more a proof of concept than 
anything else. As our release framework installs packages via chroot, 
the current setup just copies _all_ packages to the chroot before 
installing (kind of a hack).

That said, I'm now primarily interested in opinions/ideas/... about the 
direction this should take. Which packages would we like to see on the 
CD? Should it be a generic setup with the "most common things" 
installed, so a system can be quickly setup by the installer (which will 
cpdup /usr/pkg). Or should it be a more specialized set of tools? Or 
even as many packages as possible (Live DVD?). Etc., etc.

Before continuing on it, I'm really interested in people's input so 
don't hold anything back, please. :)

Sascha

--
http://yoyodyne.ath.cx



From rluciani at gmail.com  Thu Mar  6 06:42:03 2008
From: rluciani at gmail.com (Robert Luciani)
Date: Thu, 06 Mar 2008 15:42:03 +0100
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <47d002bc$0$847$415eb37d@crater_reader.dragonflybsd.org>

Sascha Wildner wrote:
> Hi all,
> 
> this is probably as good a moment as any to come out of the forest with
> this. The patch at
> 
> http://leaf.dragonflybsd.org/~swildner/nrelease_gui.diff
> 
> adds some code to nrelease/ to build a LiveCD with xorg and so on
> (currently, only the xorg metapackages and fluxbox are added). In order
> to build one, you need a local dir with the pkgsrc binary packages (see
> below).
> 
> The following commands should then do the trick:
> 
> cd /usr/src
> make buildworld
> make buildkernel
> cd nrelease
> patch -p 0 </path/to/the/patch
> make PKGSRC_PKG_PATH=/path/to/packages/dir/All realquick gui
> 
> The resulting ISO will be in /usr/release/dfly-gui.iso then. It will not
> boot into xorg automatically (although this is easily possible), so you
> need to login as root and do startx.
> 
> As of now, this all is kind of basic, more a proof of concept than
> anything else. As our release framework installs packages via chroot,
> the current setup just copies _all_ packages to the chroot before
> installing (kind of a hack).
> 
> That said, I'm now primarily interested in opinions/ideas/... about the
> direction this should take. Which packages would we like to see on the
> CD? Should it be a generic setup with the "most common things"
> installed, so a system can be quickly setup by the installer (which will
> cpdup /usr/pkg). Or should it be a more specialized set of tools? Or
> even as many packages as possible (Live DVD?). Etc., etc.
> 
> Before continuing on it, I'm really interested in people's input so
> don't hold anything back, please. :)
> 
> Sascha
> 

I think the main point of such a live-cd would be to test
dragonfly-specific features such as vkernels and more. Mplayer and
OpenOffic work the same on all platforms, so they might not be super
important, while irssi, firefox, networking tools, vim, a few more
shells/terminals might make it easier to for people to quickly gauge if
they can reproduce their current productivity and also what is new.

And if the point of a livecd is to test that kind of stuff, then it
would be nice for it to have a kernel that supports as much as possible
like ALTQ, and drivers.

Also if it has lots and lots of programs (thinking multimedia, java,
etc..) it might be hard to keep the future x64 and x86 live-cds on par.
Gentoo had this problem many years ago and it was very bothersome.

-- 
Robert Luciani
Chalmers University of Technology, SWE
Department of Computer Science and Engineering
http://www.rluciani.com/public.key




From matthias at dragonflybsd.org  Thu Mar  6 07:12:43 2008
From: matthias at dragonflybsd.org (Matthias Schmidt)
Date: Thu, 6 Mar 2008 07:12:43 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <20080306150757.GN9833@staatsfeind.org>

* Sascha Wildner wrote:
> Hi all,
> 
> this is probably as good a moment as any to come out of the forest with this. 
> The patch at
> 
> http://leaf.dragonflybsd.org/~swildner/nrelease_gui.diff
> 
> adds some code to nrelease/ to build a LiveCD with xorg and so on (currently, 
> only the xorg metapackages and fluxbox are added). In order to build one, you 
> need a local dir with the pkgsrc binary packages (see below).

Great work Sascha.

I agree with Robert on most of his stated points.
It would be nice to see some DragonFly specific features on the CD
(although I'm not sure if that will work for all features).  A little
environment where most Unix users feel at home (fluxbox, xfce, firefox,
thunderbird, gvim) should be enough.

Big applications like OO.org, java etc won't work because they are not
available as pkgsrc packages neither is it possible to compile them on
DragonFly.  At least to my knowledge.

Regards

	Matthias




From dillon at apollo.backplane.com  Thu Mar  6 09:31:52 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Thu, 6 Mar 2008 09:31:52 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <200803061728.m26HSR3O091809@apollo.backplane.com>


:Hi all,
:
:this is probably as good a moment as any to come out of the forest with 
:this. The patch at
:
:http://leaf.dragonflybsd.org/~swildner/nrelease_gui.diff
:
:adds some code to nrelease/ to build a LiveCD with xorg and so on 
:(currently, only the xorg metapackages and fluxbox are added). In order 
:to build one, you need a local dir with the pkgsrc binary packages (see 
:below).
:
:The following commands should then do the trick:

    It looks reasonable, though the package copy has to be tightened
    up a bit I think.

:...
:installed, so a system can be quickly setup by the installer (which will 
:cpdup /usr/pkg). Or should it be a more specialized set of tools? Or 
:even as many packages as possible (Live DVD?). Etc., etc.
:
:Before continuing on it, I'm really interested in people's input so 
:don't hold anything back, please. :)
:
:Sascha

    I think this is an excellent time to work up a DVD build and to
    add various 'flavor' extras.  So, e.g.:

	make installer gui gui_extras release dvd

    (All 'dvd' would do is generate a dvd compatible image for burning to
    dvd instead of cd).  I did a quick perusal of what I have on my
    workstation:

    * X
    * Firefox
    * Linux emulation
    * Open Office (linux version)
    * fvwm2
    * xpdf
    * freetype2

    I'd also suggest some image editing tools like gimp, and maybe the KDE
    gui suite.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From justin at shiningsilence.com  Thu Mar  6 09:42:44 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Thu, 6 Mar 2008 09:42:44 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <55427.65.106.147.226.1204825168.squirrel@www.shiningsilence.com>

On Thu, March 6, 2008 8:34 am, Sascha Wildner wrote:

> That said, I'm now primarily interested in opinions/ideas/... about the
> direction this should take. Which packages would we like to see on the
> CD? Should it be a generic setup with the "most common things"
> installed, so a system can be quickly setup by the installer (which will
> cpdup /usr/pkg). Or should it be a more specialized set of tools? Or
> even as many packages as possible (Live DVD?). Etc., etc.

What Robert said is good - whatever's needed to enable DragonFly-specific
features.  Along with that would be some sort of documentation (a README? 
A HTML file on whatever desktop we provide) that points people at the
different DragonFly tools, so they know what to try and how to try it.

There's going to be some percentage of people who try DragonFly who don't
know about vkernels, for instance, but there's our chance to educate them.
 I'm probably volunteering myself, aren't I?





From sdavtaker at gmail.com  Thu Mar  6 09:50:09 2008
From: sdavtaker at gmail.com (=?UTF-8?Q?Sd=C3=A4vtaker?=)
Date: Thu, 6 Mar 2008 09:50:09 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <c37d69f60803060947t110750c0sd6b542ea505d188d@mail.gmail.com>

Cool Sascha :-)
I just posted about this 1 or 2 days ago in the SOC project ideas thread.
Want to mentor this one? ;-)
Damian

On Thu, Mar 6, 2008 at 2:28 PM, Matthew Dillon
<dillon at apollo.backplane.com> wrote:
>
>  :Hi all,
>
> :
>  :this is probably as good a moment as any to come out of the forest with
>  :this. The patch at
>  :
>  :http://leaf.dragonflybsd.org/~swildner/nrelease_gui.diff
>  :
>  :adds some code to nrelease/ to build a LiveCD with xorg and so on
>  :(currently, only the xorg metapackages and fluxbox are added). In order
>  :to build one, you need a local dir with the pkgsrc binary packages (see
>  :below).
>  :
>  :The following commands should then do the trick:
>
>     It looks reasonable, though the package copy has to be tightened
>     up a bit I think.
>
>  :...
>  :installed, so a system can be quickly setup by the installer (which will
>
> :cpdup /usr/pkg). Or should it be a more specialized set of tools? Or
>  :even as many packages as possible (Live DVD?). Etc., etc.
>  :
>  :Before continuing on it, I'm really interested in people's input so
>  :don't hold anything back, please. :)
>  :
>  :Sascha
>
>     I think this is an excellent time to work up a DVD build and to
>     add various 'flavor' extras.  So, e.g.:
>
>         make installer gui gui_extras release dvd
>
>     (All 'dvd' would do is generate a dvd compatible image for burning to
>     dvd instead of cd).  I did a quick perusal of what I have on my
>     workstation:
>
>     * X
>     * Firefox
>     * Linux emulation
>     * Open Office (linux version)
>     * fvwm2
>     * xpdf
>     * freetype2
>
>     I'd also suggest some image editing tools like gimp, and maybe the KDE
>     gui suite.
>
>                                         -Matt
>                                         Matthew Dillon
>                                         <dillon at backplane.com>
>



-- 
Sd?vtaker prays to Rikku goddess for a good treasure.



From saw at online.de  Thu Mar  6 11:54:01 2008
From: saw at online.de (Sascha Wildner)
Date: Thu, 06 Mar 2008 20:54:01 +0100
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <47d04ba2$0$856$415eb37d@crater_reader.dragonflybsd.org>

Matthew Dillon wrote:
    It looks reasonable, though the package copy has to be tightened
    up a bit I think.
It looks as if it would work with mount_null'ing the chroot's 
/tmp/packages. I'll have a better patch ready tomorrow.

Sascha

--
http://yoyodyne.ath.cx



From c.turner at 199technologies.org  Thu Mar  6 19:11:44 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Thu, 6 Mar 2008 19:11:44 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Misc. ACPI / suspend
In-Reply-To: <47CA073B.6020106@199technologies.org>
Message-ID: <47D0B079.3060905@199technologies.org>

Chris Turner wrote:
Wondering if anyone more well versed in the ACPI implementation could
comment on the applicability of:
http://lkml.org/lkml/2007/4/6/69

Doing a little digging, it seems like

. /platform/pc32/i386/i686_mem.c

*might* have the necessary infrastructure to remap the MTRR's per the 
thread referenced,

but:

. /platform/pc32/acpica5/acpi_wakeup.c

doesn't seem to be using this infrastructure..

I'm no where near reaching an understanding of this yet,
but I'm wondering 3 things:
1) does anyone have ACPI (instead of APM)
   sleep / suspend / wakeup working on Dfly ?
2) If so, what machines are being used ?
3) Same question for other BSDs - my understanding is NetBSD is most
   'advanced' w/r/t power managment - but I'm not 100% on this ...
would looove to have a sleeping / resuming / scaling laptop running some 
BSD flavor.. am willing to work towards that end, esp. w/r/t Dfly -
trying to chart a course to figguring this out.

Thanks all,

- Chris




From c.turner at 199technologies.org  Thu Mar  6 19:12:33 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Thu, 6 Mar 2008 19:12:33 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: PCI Bios / Interrupt remapping / etc
Message-ID: <47D0B211.6000002@199technologies.org>

Doing a bit of digging here for my long-standing CBB+SIO interupt and 
buffer problem -

one machine I've tested against was an OpenBSD machine, which didn't
always work to handle the cardbus sio card on a PCI cardbus adapter
-

tuning up some of the device flags in:

http://www.openbsd.org/cgi-bin/man.cgi?query=pcibios&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=html

seems to have alleviated the problem for that os..

I'm just only starting to get up to speed on how DF handles these types 
of things (namely initial PIC / interrupt layout at boot time device 
enumeration), but am wondering if anyone familiar with this area of the 
code has any comments / advice w/r/t the capabilities of the DF bios 
drivers
and the various quirks / fixup mentioned in the link above..

looking to possibly investigate fixing up some of these issues over time.

Thanks

- Chris







From pavalos at theshell.com  Fri Mar  7 01:14:55 2008
From: pavalos at theshell.com (Peter Avalos)
Date: Fri, 7 Mar 2008 01:14:55 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: cam locking
Message-ID: <20080307091024.GC1652@ylem.theshell.com>

So I've been working on locking up cam using lockmgr locks, and here's
what I have so far:

http://www.theshell.com/~pavalos/wip/cam-lock.patch

Most of the work is obtained from FreeBSD.  I've only been running this
on my SCSI machine for a day, but because the patch is so large, I wanted
to make it available for people to review if they have some spare time.

Thanks,
Peter
Attachment:
pgp00002.pgp
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00002.pgp
Type: application/octet-stream
Size: 197 bytes
Desc: "Description: PGP signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080307/9a17ecd8/attachment-0012.obj>

From jspringe at uos.de  Fri Mar  7 03:25:17 2008
From: jspringe at uos.de (Jost Tobias Springenberg)
Date: Fri, 7 Mar 2008 12:25:17 +0100
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <20080307122517.72c9e2b1.jspringe@uos.de>

On Tue, 4 Mar 2008 11:28:15 -0500 (EST)
"Justin C. Sherrill" <justin at shiningsilence.com> wrote:

> On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
> > Hi,
> >
> > Google just announced its Summer of Code for 2008:
> >
> > 	http://code.google.com/soc/2008/
> >
> > I think this would be a great opportunity for DragonFly to participate
> > as a mentoring organisation.  We could attract new developers and could
> > get code/work done.  Looking at the SoC results of the other BSDs most
> > of their projects were a success.  Of course, not all, but a reasonable
> > percentage.  See [1] and [2].
> 
> We've applied in previous years - Jeff Hsu did one year, and I put
> together the application last year.  The hardest thing to find was
> students (and they are the thing that helps SoC applications a lot, I
> think).
> 
> Any student volunteers?  We have mentors.
> 

I read this mailing list for quite a while now and thought about contributing stuff
to DFfly several times, so yes why not take this opportunity if it's there.

-- 
Jost Tobias Springenberg <jspringe at uos.de>




From tgen at netphreax.net  Fri Mar  7 05:17:27 2008
From: tgen at netphreax.net (Thomas E. Spanjaard)
Date: Fri, 7 Mar 2008 05:17:27 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: PCI Bios / Interrupt remapping / etc
In-Reply-To: <47D0B211.6000002@199technologies.org>
Message-ID: <47D13FB4.5080306@netphreax.net>

Chris Turner wrote:
Doing a bit of digging here for my long-standing CBB+SIO interupt and 
buffer problem -

one machine I've tested against was an OpenBSD machine, which didn't
always work to handle the cardbus sio card on a PCI cardbus adapter
-

tuning up some of the device flags in:

http://www.openbsd.org/cgi-bin/man.cgi?query=pcibios&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=html 

seems to have alleviated the problem for that os..

I'm just only starting to get up to speed on how DF handles these types 
of things (namely initial PIC / interrupt layout at boot time device 
enumeration), but am wondering if anyone familiar with this area of the 
code has any comments / advice w/r/t the capabilities of the DF bios 
drivers
and the various quirks / fixup mentioned in the link above..

looking to possibly investigate fixing up some of these issues over time.
Our code that handles issues like this (in cases where you're not using 
APICs, just PICs and PIRs) lives in bus/pci/i386/. Not that running 
without APIC support is all that common on modern machines anymore...
--
        Thomas E. Spanjaard
        tgen at netphreax.net
Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00003.pgp
Type: application/octet-stream
Size: 186 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080307/61366b5c/attachment-0012.obj>

From tgen at netphreax.net  Fri Mar  7 05:16:51 2008
From: tgen at netphreax.net (Thomas E. Spanjaard)
Date: Fri, 7 Mar 2008 05:16:51 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Misc. ACPI / suspend
In-Reply-To: <47CA073B.6020106@199technologies.org>
Message-ID: <47D13F07.9080308@netphreax.net>

Chris Turner wrote:
1) does anyone have ACPI (instead of APM)
   sleep / suspend / wakeup working on Dfly ?
2) If so, what machines are being used ?
3) Same question for other BSDs - my understanding is NetBSD is most
   'advanced' w/r/t power managment - but I'm not 100% on this ...
would looove to have a sleeping / resuming / scaling laptop running some 
BSD flavor.. am willing to work towards that end, esp. w/r/t Dfly -
trying to chart a course to figguring this out.
I have ACPI S3 suspend working like a charm on my IBM ThinkPad R40 
(Pentium M "Banias" 1.3GHz, speedstepping works just fine), running 
NetBSD 3.99.21.
--
        Thomas E. Spanjaard
        tgen at netphreax.net
Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00004.pgp
Type: application/octet-stream
Size: 186 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080307/de3e5104/attachment-0012.obj>

From civilizd at gmail.com  Fri Mar  7 09:06:41 2008
From: civilizd at gmail.com (Vita "CiV" Cizek)
Date: Fri, 7 Mar 2008 09:06:41 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <98d564710803070853q1c73d795m6e6c5cc5049fa099@mail.gmail.com>

>  Any student volunteers?  We have mentors.
>
I am interested too, especially in some kernel-related work.




From justin at shiningsilence.com  Sat Mar  8 12:07:51 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Sat, 8 Mar 2008 12:07:51 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google SoC 2008 - mentors mentors mentors
Message-ID: <51558.192.168.0.252.1205006403.squirrel@www.shiningsilence.com>

If you are willing to mentor for the Google 2008 Summer of Code, please
speak up.  Right now we have: (from our wiki page)

Matthias
Sephe
TGEN
corecode

Part of the application process includes naming people as mentors (student
applications come later), so I want to get as complete a list as possible.

The application is due on the 12th, so if you want to mentor, now's the
time to say so.

Google's SoC FAQ is here: http://code.google.com/soc/2008/faqs.html

Our wiki page is here: http://wiki.dragonflybsd.org/index.cgi/GoogleSoC2008

- much credit to Matthias and others for getting that set up.





From saw at online.de  Sat Mar  8 14:26:07 2008
From: saw at online.de (Sascha Wildner)
Date: Sat, 08 Mar 2008 23:26:07 +0100
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <47d31245$0$848$415eb37d@crater_reader.dragonflybsd.org>

Sascha Wildner wrote:
Hi all,

this is probably as good a moment as any to come out of the forest with 
this. The patch at

http://leaf.dragonflybsd.org/~swildner/nrelease_gui.diff
Ok, I have committed the stuff as an example.

I'm not sure if my free time permits to work on a full-blown live CD 
with X11 and other good things (I already feel my interest wandering off 
in other directions) so if anyone wants to pick up the ball, go ahead. :)

Sascha

--
http://yoyodyne.ath.cx



From qhwt+dfly at les.ath.cx  Tue Mar 11 22:21:31 2008
From: qhwt+dfly at les.ath.cx (YONETANI Tomokazu)
Date: Tue, 11 Mar 2008 22:21:31 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Misc. ACPI / suspend
In-Reply-To: <47CA073B.6020106@199technologies.org>
Message-ID: <20080312051219.GA56091@les.ath.cx>

On Thu, Mar 06, 2008 at 10:03:21PM -0500, Chris Turner wrote:
> 1) does anyone have ACPI (instead of APM)
>    sleep / suspend / wakeup working on Dfly ?
> 2) If so, what machines are being used ?

Dynabook SS3500 (http://www.tlt.co.jp/pc/catalog/ss/02110735/index_j.htm).
It's old and can get very hot(thus frequently turns on the cooling fan)
even when it's running Windows.  I haven't turned it on for about several
months though.

Cheers.




From c.turner at 199technologies.org  Wed Mar 12 04:37:22 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Wed, 12 Mar 2008 04:37:22 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Misc. ACPI / suspend
In-Reply-To: <47CA073B.6020106@199technologies.org>
Message-ID: <47D7BEE3.6010907@199technologies.org>

YONETANI Tomokazu wrote:
On Thu, Mar 06, 2008 at 10:03:21PM -0500, Chris Turner wrote:
1) does anyone have ACPI (instead of APM)
   sleep / suspend / wakeup working on Dfly ?
Cheers.
ditto..

Suppose this should go to docs@ - in any case..

Thinking about setting up a wiki page on the issue so we
can discuss / track what 'good' hardware / drivers / implementations / 
etc are 'out there' - anyone have any suggestions on where this should
go?

http://wiki.dragonflybsd.org/index.cgi/acpi-overview.html

Remains from the handbook conversion - but I'm hesitant to 'over wikify'
this ..



From c.turner at 199technologies.org  Wed Mar 12 15:36:52 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Wed, 12 Mar 2008 15:36:52 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: devel/cscope
Message-ID: <47D85A08.8040103@199technologies.org>

why oh why did I take so long to try this out !!!

just sharing my eureka moment with the list..

- Chris




From dudu at dudu.ro  Wed Mar 12 15:50:14 2008
From: dudu at dudu.ro (Vlad GALU)
Date: Wed, 12 Mar 2008 15:50:14 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: devel/cscope
In-Reply-To: <47D85A08.8040103@199technologies.org>
Message-ID: <ad79ad6b0803121547r2bf67ffep9e40badaac6490f8@mail.gmail.com>

On 3/13/08, Chris Turner <c.turner at 199technologies.org> wrote:
> why oh why did I take so long to try this out !!!
>
>  just sharing my eureka moment with the list..


    Works nice with vim, too!

>
>
>  - Chris
>


-- 
Mahnahmahnah!




From justin at shiningsilence.com  Sun Mar 16 21:06:13 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Sun, 16 Mar 2008 21:06:13 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: binary packages for 1.12 coming in
Message-ID: <1372.192.168.0.252.1205726088.squirrel@www.shiningsilence.com>

The binary build for 1.12 is taking quite a while.  I've started copying
in newly built packages to
pkgbox.dragonflybsd.org/packages/DragonFly-1.12/i386/ - this should be
getting copied out to mirrors over the next while.

There are currently 1283 packages built, which leaves a whole lot to go;
I'll copy new packages in as they complete.





From hasso at estpak.ee  Wed Mar 19 04:31:08 2008
From: hasso at estpak.ee (Hasso Tepper)
Date: Wed, 19 Mar 2008 04:31:08 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Some questions regarding ACPI
Message-ID: <200803191322.46366.hasso@estpak.ee>

I'm working on bringing in some laptop (and especially thinkpad) specific 
ACPI code from FreeBSD into DragonFly. I never touched ACPI stuff before 
and haven't followed it much either, so I have some questions.

* FreeBSD uses ACPI_SERIAL_* heavily. What's the locking situation in 
  DragonFly and why?

* As far as I can see, PCI integration is commented out in DragonFly. 
  What's the state of it and why?

* platform/pc32/acpica5/acpi_toshiba.c - why is it there? I don't think 
  that this is something pc32 specific in it and it should work in pc64 
  laptops as well. Any objections to move it into 
  dev/acpica5/acpi_toshiba/ ?

What's the current status of ACPI in general? AFAICS our acpica is quite 
old - what needs to be done to bring in newer one?


-- 
Hasso




From qhwt+dfly at les.ath.cx  Wed Mar 19 09:24:50 2008
From: qhwt+dfly at les.ath.cx (YONETANI Tomokazu)
Date: Wed, 19 Mar 2008 09:24:50 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Some questions regarding ACPI
In-Reply-To: <200803191322.46366.hasso@estpak.ee>
Message-ID: <20080319161703.GA51509@les.ath.cx>

On Wed, Mar 19, 2008 at 01:22:46PM +0200, Hasso Tepper wrote:
> I'm working on bringing in some laptop (and especially thinkpad) specific 
> ACPI code from FreeBSD into DragonFly. I never touched ACPI stuff before 
> and haven't followed it much either, so I have some questions.

So you want to port some of ACPI support drivers, or to do a fresh port
of ACPI driver from FreeBSD?

> * FreeBSD uses ACPI_SERIAL_* heavily. What's the locking situation in 
>   DragonFly and why?

The current ACPI driver in DragonFly is based on that of FreeBSD as of
end of June, 2004, plus some fixes brought in later (and ACPICA part
has been updated twice since then).  That was before they introduced
the MPSAFE changes into ACPI code, and we use critical section
(crit_{enter,exit}) in most places (and lockmgr lock in a few place).

> * As far as I can see, PCI integration is commented out in DragonFly. 
>   What's the state of it and why?

When we replaced the implementation taken from FreeBSD 4.x with that
brought from FreeBSD 5.x, which added the PCI part, many people
experienced problems until they turned off ACPI completely, or add "pci"
to "debug.acpi.disabled" loader variable.  AFAIK the PCI part in the ACPI
driver almost hasn't been adjusted to work with our version of PCI code.

> * platform/pc32/acpica5/acpi_toshiba.c - why is it there? I don't think 
>   that this is something pc32 specific in it and it should work in pc64 
>   laptops as well. Any objections to move it into 
>   dev/acpica5/acpi_toshiba/ ?

In FreeBSD it used to be sitting at i386/acpica/acpi_toshiba.c and was
later moved into acpi_support.  That change hasn't hit our tree (in fact,
we have no acpi support drivers other than that).  It seems that FreeBSD
has them in dev/acpi_support now, and we for some reason have that
directory in our CVS repository (but containing no files in it).

> What's the current status of ACPI in general? AFAICS our acpica is quite 
> old - what needs to be done to bring in newer one?

Actually, it's not very important to keep just ACPICA latest, but
if you bring the ACPI driver from FreeBSD you need to bring ACPICA code
that matches their version, and it IS important.  And it generally requires
you much work to just update ACPICA part anyway because of how they
change things on every release.

Cheers.




From hasso at estpak.ee  Wed Mar 19 12:29:52 2008
From: hasso at estpak.ee (Hasso Tepper)
Date: Wed, 19 Mar 2008 12:29:52 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Some questions regarding ACPI
In-Reply-To: <200803191322.46366.hasso@estpak.ee>
Message-ID: <200803192115.35396.hasso@estpak.ee>

YONETANI Tomokazu wrote:
> On Wed, Mar 19, 2008 at 01:22:46PM +0200, Hasso Tepper wrote:
> > I'm working on bringing in some laptop (and especially thinkpad)
> > specific ACPI code from FreeBSD into DragonFly. I never touched ACPI
> > stuff before and haven't followed it much either, so I have some
> > questions.
>
> So you want to port some of ACPI support drivers, or to do a fresh port
> of ACPI driver from FreeBSD?

I'm only interested in support drivers and the reason is pure practical - 
newer thinkpads handle less and less hotkeys etc in hardware and require 
support form OS. acpi_ibm and acpi_video are examples of such modules 
which would help a lot of these newer thinkpad users.

acpi_ibm is almost ready to commit (renamed to acpi_thinkpad though).

> > * FreeBSD uses ACPI_SERIAL_* heavily. What's the locking situation in
> >   DragonFly and why?
>
> The current ACPI driver in DragonFly is based on that of FreeBSD as of
> end of June, 2004, plus some fixes brought in later (and ACPICA part
> has been updated twice since then).  That was before they introduced
> the MPSAFE changes into ACPI code, and we use critical section
> (crit_{enter,exit}) in most places (and lockmgr lock in a few place).

Mkay. Will look at more closely.

> > * As far as I can see, PCI integration is commented out in DragonFly.
> >   What's the state of it and why?
>
> When we replaced the implementation taken from FreeBSD 4.x with that
> brought from FreeBSD 5.x, which added the PCI part, many people
> experienced problems until they turned off ACPI completely, or add
> "pci" to "debug.acpi.disabled" loader variable.  AFAIK the PCI part in
> the ACPI driver almost hasn't been adjusted to work with our version of
> PCI code.

I'm afraid that it's beyond my skills, but while looking at acpi_video I 
discovered that it's hard to handle correctly without PCI support.

> > * platform/pc32/acpica5/acpi_toshiba.c - why is it there? I don't
> > think that this is something pc32 specific in it and it should work
> > in pc64 laptops as well. Any objections to move it into
> >   dev/acpica5/acpi_toshiba/ ?
>
> In FreeBSD it used to be sitting at i386/acpica/acpi_toshiba.c and was
> later moved into acpi_support.  That change hasn't hit our tree (in
> fact, we have no acpi support drivers other than that).  It seems that
> FreeBSD has them in dev/acpi_support now, and we for some reason have
> that directory in our CVS repository (but containing no files in it).

I don't see it ;). Makes sense though. So, any objections if I move 
acpi_toshiba into sys/dev/acpi_support and add new acpi_thinkpad there as 
well? 

> > What's the current status of ACPI in general? AFAICS our acpica is
> > quite old - what needs to be done to bring in newer one?
>
> Actually, it's not very important to keep just ACPICA latest, but
> if you bring the ACPI driver from FreeBSD you need to bring ACPICA code
> that matches their version, and it IS important.  And it generally
> requires you much work to just update ACPICA part anyway because of how
> they change things on every release.

Someone else has to do it :).

Thanks for info.


-- 
Hasso




From dillon at apollo.backplane.com  Wed Mar 19 14:01:13 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Wed, 19 Mar 2008 14:01:13 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: panic: assertion: hammer_btree_cmp(cursor->left_bound,	&cursor->node->ondisk->elms[0].leaf.base) <= 0 in btree_split_leaf
In-Reply-To: <200802232204.m1NM4cxd046264@apollo.backplane.com>
Message-ID: <200803192054.m2JKsjwn045137@apollo.backplane.com>


:Hi.
:While trying to find a procedure to reliably reproduce the panic
:I reported last time, I caught a different panic (uploaded at
: ~y0netan1/crash/9/ on my leaf account).  I wrote the following shell
:script (make sure to edit variables DISKS and MOUNTPT before using this
:script or it may trash your system):
:  #!/bin/sh -ex
:  DISKS="/dev/ad0s1f"
:  MOUNTPT=/mnt/HAMMER
:
:  cd /
:  newfs_hammer -L TEST $DISKS
:  for i in `seq 1 100`; do
:..
:And the panic is triggered by rm command.
:I'll try to see if it's possible to reproduce the last one without
:unmounting then mounting the HAMMER fs.
:
:Cheers.

    I believe I have fixed this panic.  hammer_make_separator() had a bug
    in it.

    There is still an issue with the node ref count on umount.

    Please continue to life-test the code.  The reblocking code
    (hammer reblock /mnt) should work now, as should the pruning code
    (e.g. hammer prune /mnt everything).

    The filesystem full case is still not handled and will cause bad things
    to happen.  The undo code isn't finished yet either but it is getting
    there (it's writing stuff out but not setting the sequence number and
    not trying to recover-on-mount yet).

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From qhwt+dfly at les.ath.cx  Wed Mar 19 19:45:40 2008
From: qhwt+dfly at les.ath.cx (YONETANI Tomokazu)
Date: Wed, 19 Mar 2008 19:45:40 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Some questions regarding ACPI
In-Reply-To: <200803191322.46366.hasso@estpak.ee>
Message-ID: <20080320023828.GA53648@les.ath.cx>

On Wed, Mar 19, 2008 at 09:15:35PM +0200, Hasso Tepper wrote:
> YONETANI Tomokazu wrote:
> > On Wed, Mar 19, 2008 at 01:22:46PM +0200, Hasso Tepper wrote:
> > > I'm working on bringing in some laptop (and especially thinkpad)
> > > specific ACPI code from FreeBSD into DragonFly. I never touched ACPI
> > > stuff before and haven't followed it much either, so I have some
> > > questions.
> >
> > So you want to port some of ACPI support drivers, or to do a fresh port
> > of ACPI driver from FreeBSD?
> 
> I'm only interested in support drivers and the reason is pure practical - 
> newer thinkpads handle less and less hotkeys etc in hardware and require 
> support form OS. acpi_ibm and acpi_video are examples of such modules 
> which would help a lot of these newer thinkpad users.
> 
> acpi_ibm is almost ready to commit (renamed to acpi_thinkpad though).

Ah, that's a good news!  My only concern is that ISTR someone mentioned
me that his colleague was thinking about porting ACPI driver itself,
so if you're not the person you may want to collaborate with him/her
so as not to waste the effort or time...

			:

> > In FreeBSD it used to be sitting at i386/acpica/acpi_toshiba.c and was
> > later moved into acpi_support.  That change hasn't hit our tree (in
> > fact, we have no acpi support drivers other than that).  It seems that
> > FreeBSD has them in dev/acpi_support now, and we for some reason have
> > that directory in our CVS repository (but containing no files in it).
> 
> I don't see it ;). Makes sense though. So, any objections if I move 
> acpi_toshiba into sys/dev/acpi_support and add new acpi_thinkpad there as 
> well? 

Sorry, I checked the CVS repository and it doesn't exist actually :)
I don't have any objection to moving it there.

Cheers.




From hasso at estpak.ee  Thu Mar 20 00:14:05 2008
From: hasso at estpak.ee (Hasso Tepper)
Date: Thu, 20 Mar 2008 00:14:05 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Some questions regarding ACPI
In-Reply-To: <200803191322.46366.hasso@estpak.ee>
Message-ID: <200803200904.50875.hasso@estpak.ee>

YONETANI Tomokazu wrote:
> On Wed, Mar 19, 2008 at 09:15:35PM +0200, Hasso Tepper wrote:
> > acpi_ibm is almost ready to commit (renamed to acpi_thinkpad though).
>
> Ah, that's a good news!  My only concern is that ISTR someone mentioned
> me that his colleague was thinking about porting ACPI driver itself,
> so if you're not the person you may want to collaborate with him/her
> so as not to waste the effort or time...

Current state in my repo is attached. It should work on 1.12 as well as it 
doesn't depend yet on moving stuff around.

add-acpi-if-m.patch adds some new stuff to the ACPI code to access 
embedded controllers and match ACPI devices by ID. Not sure how, where 
and whether at all these should be documented.

add-acpi-thinkpad.patch is the driver itself. Note that some stuff doesn't 
work yet on newer thinkpads, I plan to work on it later.

There is still some things to do though. I have to decide what to do with 
led(4) part and with locking. There is also one fatal issue - laptop 
locks up hardly (no panic) while unloading module. Any idea regarding 
this is welcome. And of course test results :).


-- 
Hasso
# HG changeset patch
# User Hasso Tepper <hasso at estpak.ee>
# Date 1205919290 -7200
# Branch HEAD
# Node ID 5a6e2705cc95a340abf973ae5df73ef34e070b79
# Parent  cd529e2e7f849034d5d5a0973cb98af50db0e797
imported patch adding-acpi-if-m.patch

diff --git a/sys/conf/files b/sys/conf/files
--- a/sys/conf/files
+++ b/sys/conf/files
@@ -1387,6 +1387,7 @@ emulation/dragonfly12/dfbsd12_stat.c	non
 ${OSACPI_MI_DIR}/acpi_cmbat.c		optional acpi
 ${OSACPI_MI_DIR}/acpi_cpu.c		optional acpi
 ${OSACPI_MI_DIR}/acpi_ec.c		optional acpi
+${OSACPI_MI_DIR}/acpi_if.m		optional acpi
 ${OSACPI_MI_DIR}/acpi_isab.c		optional acpi isa
 ${OSACPI_MI_DIR}/acpi_lid.c		optional acpi
 ${OSACPI_MI_DIR}/acpi_package.c		optional acpi
diff --git a/sys/conf/kmod.mk b/sys/conf/kmod.mk
--- a/sys/conf/kmod.mk
+++ b/sys/conf/kmod.mk
@@ -275,7 +275,7 @@ MFILES?= kern/bus_if.m kern/device_if.m 
     bus/pccard/card_if.m bus/pccard/power_if.m bus/pci/pci_if.m \
     bus/pci/pcib_if.m \
     bus/ppbus/ppbus_if.m bus/smbus/smbus_if.m bus/usb/usb_if.m \
-    dev/disk/nata/ata_if.m \
+    dev/acpica5/acpi_if.m dev/disk/nata/ata_if.m \
     dev/sound/pcm/ac97_if.m dev/sound/pcm/channel_if.m \
     dev/sound/pcm/feeder_if.m dev/sound/pcm/mixer_if.m \
     libiconv/iconv_converter_if.m dev/agp/agp_if.m opencrypto/crypto_if.m
diff --git a/sys/dev/acpica5/Makefile b/sys/dev/acpica5/Makefile
--- a/sys/dev/acpica5/Makefile
+++ b/sys/dev/acpica5/Makefile
@@ -69,12 +69,14 @@ SRCS+=  acpi_package.c
 # SRCS+=	acpi_pci.c acpi_pcib.c acpi_pcib_acpi.c acpi_pcib_pci.c
 # SRCS+=	acpi_pci_link.c
 SRCS+=  acpi_powerres.c acpi_resource.c acpi_thermal.c
-SRCS+=  acpi_timer.c
+SRCS+=  acpi_timer.c acpi_if.c
 SRCS+=  OsdDebug.c
 SRCS+=  OsdHardware.c OsdInterface.c OsdInterrupt.c OsdMemory.c OsdSchedule.c
 SRCS+=  OsdStream.c OsdSynch.c OsdTable.c OsdEnvironment.c
 SRCS+=  opt_acpi.h opt_bus.h opt_ddb.h
-SRCS+=  device_if.h bus_if.h pci_if.h pcib_if.h isa_if.h
+SRCS+=  device_if.h bus_if.h pci_if.h pcib_if.h isa_if.h acpi_if.h
+MFILES = kern/device_if.m kern/bus_if.m bus/pci/pci_if.m bus/pci/pcib_if.m
+MFILES+= bus/isa/isa_if.m dev/acpica5/acpi_if.m
 
 # Debugging support
 DBSRC=	dbcmds.c dbdisply.c dbexec.c dbfileio.c dbhistry.c
diff --git a/sys/dev/acpica5/acpi.c b/sys/dev/acpica5/acpi.c
--- a/sys/dev/acpica5/acpi.c
+++ b/sys/dev/acpica5/acpi.c
@@ -135,6 +135,7 @@ static int	acpi_release_resource(device_
 			int rid, struct resource *r);
 static uint32_t	acpi_isa_get_logicalid(device_t dev);
 static int	acpi_isa_get_compatid(device_t dev, uint32_t *cids, int count);
+static char	*acpi_device_id_probe(device_t bus, device_t dev, char **ids);
 static int	acpi_isa_pnp_probe(device_t bus, device_t child,
 			struct isa_pnp_id *ids);
 static void	acpi_probe_children(device_t bus);
@@ -189,6 +190,9 @@ static device_method_t acpi_methods[] = 
     DEVMETHOD(bus_deactivate_resource,	bus_generic_deactivate_resource),
     DEVMETHOD(bus_setup_intr,		bus_generic_setup_intr),
     DEVMETHOD(bus_teardown_intr,	bus_generic_teardown_intr),
+
+    /* ACPI bus */
+    DEVMETHOD(acpi_id_probe,		acpi_device_id_probe),
 
     /* ISA emulation */
     DEVMETHOD(isa_pnp_probe,		acpi_isa_pnp_probe),
@@ -1121,6 +1125,24 @@ out:
 	AcpiOsFree(buf.Pointer);
     ACPI_UNLOCK;
     return_VALUE (valid);
+}
+
+static char *
+acpi_device_id_probe(device_t bus, device_t dev, char **ids) 
+{
+    ACPI_HANDLE h;
+    int i;
+
+    h = acpi_get_handle(dev);
+    if (ids == NULL || h == NULL || acpi_get_type(dev) != ACPI_TYPE_DEVICE)
+	return (NULL);
+
+    /* Try to match one of the array of IDs with a HID or CID. */
+    for (i = 0; ids[i] != NULL; i++) {
+	if (acpi_MatchHid(h, ids[i]))
+	    return (ids[i]);
+    }
+    return (NULL);
 }
 
 static int
diff --git a/sys/dev/acpica5/acpi_ec.c b/sys/dev/acpica5/acpi_ec.c
--- a/sys/dev/acpica5/acpi_ec.c
+++ b/sys/dev/acpica5/acpi_ec.c
@@ -327,11 +327,19 @@ static ACPI_STATUS	EcWrite(struct acpi_e
 				UINT8 *Data);
 static int		acpi_ec_probe(device_t dev);
 static int		acpi_ec_attach(device_t dev);
+static int		acpi_ec_read_method(device_t dev, u_int addr,
+				ACPI_INTEGER *val, int width);
+static int		acpi_ec_write_method(device_t dev, u_int addr,
+				ACPI_INTEGER val, int width);
 
 static device_method_t acpi_ec_methods[] = {
     /* Device interface */
     DEVMETHOD(device_probe,	acpi_ec_probe),
     DEVMETHOD(device_attach,	acpi_ec_attach),
+
+    /* Embedded controller interface */
+    DEVMETHOD(acpi_ec_read,     acpi_ec_read_method),
+    DEVMETHOD(acpi_ec_write,    acpi_ec_write_method),
 
     {0, 0}
 };
@@ -620,6 +628,33 @@ error:
 			     sc->ec_data_res);
     /* mtx_destroy(&sc->ec_mtx); */
     return (ENXIO);
+}
+
+/* Methods to allow other devices (e.g., smbat) to read/write EC space. */
+static int
+acpi_ec_read_method(device_t dev, u_int addr, ACPI_INTEGER *val, int width)
+{
+    struct acpi_ec_softc *sc;
+    ACPI_STATUS status;
+
+    sc = device_get_softc(dev);
+    status = EcSpaceHandler(ACPI_READ, addr, width * 8, val, sc, NULL);
+    if (ACPI_FAILURE(status))
+        return (ENXIO);
+    return (0);
+}
+
+static int
+acpi_ec_write_method(device_t dev, u_int addr, ACPI_INTEGER val, int width)
+{
+    struct acpi_ec_softc *sc;
+    ACPI_STATUS status;
+
+    sc = device_get_softc(dev);
+    status = EcSpaceHandler(ACPI_WRITE, addr, width * 8, &val, sc, NULL);
+    if (ACPI_FAILURE(status))
+        return (ENXIO);
+    return (0);
 }
 
 static void
diff --git a/sys/dev/acpica5/acpi_if.m b/sys/dev/acpica5/acpi_if.m
new file mode 100644
--- /dev/null
+++ b/sys/dev/acpica5/acpi_if.m
@@ -0,0 +1,92 @@
+#-
+# Copyright (c) 2004 Nate Lawson
+# All rights reserved.
+#
+# Redistribution and use in source and binary forms, with or without
+# modification, are permitted provided that the following conditions
+# are met:
+# 1. Redistributions of source code must retain the above copyright
+#    notice, this list of conditions and the following disclaimer.
+# 2. Redistributions in binary form must reproduce the above copyright
+#    notice, this list of conditions and the following disclaimer in the
+#    documentation and/or other materials provided with the distribution.
+#
+# THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
+# ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+# ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
+# FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+# DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+# OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+# HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+# LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+# OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+# SUCH DAMAGE.
+#
+# $DragonFly$
+#
+
+#include <sys/bus.h>
+#include <sys/types.h>
+#include "acpi.h"
+
+INTERFACE acpi;
+
+#
+# Default implementation for acpi_id_probe().
+#
+CODE {
+	static char *
+	acpi_generic_id_probe(device_t bus, device_t dev, char **ids)
+	{
+		return (NULL);
+	}
+};
+
+#
+# Check a device for a match in a list of ID strings.  The strings can be
+# EISA PNP IDs or ACPI _HID/_CID values.
+#
+# device_t bus:  parent bus for the device
+#
+# device_t dev:  device being considered
+#
+# char **ids:  array of ID strings to consider
+#
+# Returns:  ID string matched or NULL if no match
+#
+METHOD char * id_probe {
+	device_t	bus;
+	device_t	dev;
+	char		**ids;
+} DEFAULT acpi_generic_id_probe;
+
+#
+# Read embedded controller (EC) address space
+#
+# device_t dev:  EC device
+# u_int addr:  Address to read from in EC space
+# ACPI_INTEGER *val:  Location to store read value
+# int width:  Size of area to read in bytes
+#
+METHOD int ec_read {
+	device_t	dev;
+	u_int		addr;
+	ACPI_INTEGER	*val;
+	int		width;
+};
+
+#
+# Write embedded controller (EC) address space
+#
+# device_t dev:  EC device
+# u_int addr:  Address to write to in EC space
+# ACPI_INTEGER val:  Value to write
+# int width:  Size of value to write in bytes
+#
+METHOD int ec_write {
+	device_t	dev;
+	u_int		addr;
+	ACPI_INTEGER	val;
+	int		width;
+};
diff --git a/sys/dev/acpica5/acpivar.h b/sys/dev/acpica5/acpivar.h
--- a/sys/dev/acpica5/acpivar.h
+++ b/sys/dev/acpica5/acpivar.h
@@ -29,6 +29,7 @@
  * $DragonFly: src/sys/dev/acpica5/acpivar.h,v 1.12 2007/10/23 03:04:48 y0netan1 Exp $
  */
 
+#include "acpi_if.h"
 #include "bus_if.h"
 #include <sys/eventhandler.h>
 #include <sys/sysctl.h>
# HG changeset patch
# User Hasso Tepper <hasso at estpak.ee>
# Date 1205995474 -7200
# Branch HEAD
# Node ID c5db8d4a7c6b25a8576a8d42c5029aaf0e23bfb6
# Parent  5a6e2705cc95a340abf973ae5df73ef34e070b79
[mq]: adding-acpi-thinkpad.patch

diff --git a/sys/dev/acpica5/Makefile b/sys/dev/acpica5/Makefile
--- a/sys/dev/acpica5/Makefile
+++ b/sys/dev/acpica5/Makefile
@@ -117,7 +117,7 @@ acpi_wakecode.h: acpi_wakecode.S
 	${MAKE} -f ${SYSDIR}/${OSACPI_MD_DIR}/Makefile \
 		MAKESRCPATH=${SYSDIR}/${OSACPI_MD_DIR}
 
-SUBDIR=	acpi_toshiba
+SUBDIR=	acpi_toshiba acpi_thinkpad
 all: ${PROG} ${SUBDIR}
 
 # *.o file for each patched *.c file is created under the same directory,
diff --git a/sys/dev/acpica5/acpi_thinkpad/Makefile b/sys/dev/acpica5/acpi_thinkpad/Makefile
new file mode 100644
--- /dev/null
+++ b/sys/dev/acpica5/acpi_thinkpad/Makefile
@@ -0,0 +1,9 @@
+# $DragonFly$
+
+SYSDIR?=${.CURDIR}/../../..
+
+KMOD=		acpi_thinkpad
+CFLAGS+=	-I${.OBJDIR}/.. -I${.CURDIR}/..
+SRCS=		acpi_thinkpad.c opt_acpi.h device_if.h bus_if.h
+
+.include <bsd.kmod.mk>
diff --git a/sys/dev/acpica5/acpi_thinkpad/acpi_thinkpad.c b/sys/dev/acpica5/acpi_thinkpad/acpi_thinkpad.c
new file mode 100644
--- /dev/null
+++ b/sys/dev/acpica5/acpi_thinkpad/acpi_thinkpad.c
@@ -0,0 +1,1046 @@
+/*
+ * Copyright (c) 2004 Takanori Watanabe
+ * Copyright (c) 2005 Markus Brueffer <markus at FreeBSD.org>
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *    notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *    notice, this list of conditions and the following disclaimer in the
+ *    documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+ */
+
+/*
+ * Driver for extra ACPI-controlled gadgets found on IBM and Lenovo ThinkPad
+ * laptops. Inspired by the ibm-acpi and tpb projects which implement these
+ * features on Linux.
+ *
+ *   acpi-ibm: <http://ibm-acpi.sourceforge.net/>
+ *        tpb: <http://www.nongnu.org/tpb/>
+ */
+
+#include "opt_acpi.h"
+#include <sys/param.h>
+#include <sys/kernel.h>
+#include <sys/bus.h>
+#include <machine/cpufunc.h>
+#include <sys/module.h>
+/* #include <dev/led/led.h> */
+#include <sys/sensors.h>
+#include <sys/sysctl.h>
+#include <machine/clock.h>
+
+#include "acpi.h"
+#include "acpivar.h"
+#include "acpi_if.h"
+
+#define _COMPONENT	ACPI_OEM
+ACPI_MODULE_NAME("THINKPAD")
+
+/* Internal methods */
+#define ACPI_THINKPAD_METHOD_EVENTS		1
+#define ACPI_THINKPAD_METHOD_EVENTMASK		2
+#define ACPI_THINKPAD_METHOD_HOTKEY		3
+#define ACPI_THINKPAD_METHOD_BRIGHTNESS		4
+#define ACPI_THINKPAD_METHOD_VOLUME		5
+#define ACPI_THINKPAD_METHOD_MUTE		6
+#define ACPI_THINKPAD_METHOD_THINKLIGHT		7
+#define ACPI_THINKPAD_METHOD_BLUETOOTH		8
+#define ACPI_THINKPAD_METHOD_WLAN		9
+#define ACPI_THINKPAD_METHOD_FANSPEED		10
+#define ACPI_THINKPAD_METHOD_FANLEVEL		11
+#define ACPI_THINKPAD_METHOD_FANSTATUS		12
+#define ACPI_THINKPAD_METHOD_THERMAL		13
+
+/* Hotkeys/Buttons */
+#define THINKPAD_RTC_HOTKEY1			0x64
+#define   THINKPAD_RTC_MASK_HOME		(1 << 0)
+#define   THINKPAD_RTC_MASK_SEARCH		(1 << 1)
+#define   THINKPAD_RTC_MASK_MAIL		(1 << 2)
+#define   THINKPAD_RTC_MASK_WLAN		(1 << 5)
+#define THINKPAD_RTC_HOTKEY2			0x65
+#define   THINKPAD_RTC_MASK_THINKPAD		(1 << 3)
+#define   THINKPAD_RTC_MASK_ZOOM		(1 << 5)
+#define   THINKPAD_RTC_MASK_VIDEO		(1 << 6)
+#define   THINKPAD_RTC_MASK_HIBERNATE		(1 << 7)
+#define THINKPAD_RTC_THINKLIGHT			0x66
+#define   THINKPAD_RTC_MASK_THINKLIGHT		(1 << 4)
+#define THINKPAD_RTC_SCREENEXPAND		0x67
+#define   THINKPAD_RTC_MASK_SCREENEXPAND	(1 << 5)
+#define THINKPAD_RTC_BRIGHTNESS			0x6c
+#define   THINKPAD_RTC_MASK_BRIGHTNESS		(1 << 5)
+#define THINKPAD_RTC_VOLUME			0x6e
+#define   THINKPAD_RTC_MASK_VOLUME		(1 << 7)
+
+/* Embedded Controller registers */
+#define THINKPAD_EC_BRIGHTNESS			0x31
+#define   THINKPAD_EC_MASK_BRI			0x7
+#define THINKPAD_EC_VOLUME			0x30
+#define   THINKPAD_EC_MASK_VOL			0xf
+#define   THINKPAD_EC_MASK_MUTE			(1 << 6)
+#define THINKPAD_EC_FANSTATUS			0x2F
+#define   THINKPAD_EC_MASK_FANLEVEL		0x3f
+#define   THINKPAD_EC_MASK_FANDISENGAGED	(1 << 6)
+#define   THINKPAD_EC_MASK_FANSTATUS		(1 << 7)
+#define THINKPAD_EC_FANSPEED			0x84
+
+/* CMOS Commands */
+#define THINKPAD_CMOS_VOLUME_DOWN		0
+#define THINKPAD_CMOS_VOLUME_UP			1
+#define THINKPAD_CMOS_VOLUME_MUTE		2
+#define THINKPAD_CMOS_BRIGHTNESS_UP		4
+#define THINKPAD_CMOS_BRIGHTNESS_DOWN		5
+
+/* ACPI methods */
+#define THINKPAD_NAME_KEYLIGHT			"KBLT"
+#define THINKPAD_NAME_WLAN_BT_GET		"GBDC"
+#define THINKPAD_NAME_WLAN_BT_SET		"SBDC"
+#define   THINKPAD_NAME_MASK_BT			(1 << 1)
+#define   THINKPAD_NAME_MASK_WLAN		(1 << 2)
+#define THINKPAD_NAME_THERMAL_GET		"TMP7"
+#define THINKPAD_NAME_THERMAL_UPDT		"UPDT"
+
+#define THINKPAD_NAME_EVENTS_STATUS_GET		"DHKC"
+#define THINKPAD_NAME_EVENTS_MASK_GET		"DHKN"
+#define THINKPAD_NAME_EVENTS_STATUS_SET		"MHKC"
+#define THINKPAD_NAME_EVENTS_MASK_SET		"MHKM"
+#define THINKPAD_NAME_EVENTS_GET		"MHKP"
+#define THINKPAD_NAME_EVENTS_AVAILMASK		"MHKA"
+
+#define ABS(x) (((x) < 0)? -(x) : (x))
+
+struct acpi_thinkpad_softc {
+	device_t	dev;
+	ACPI_HANDLE	handle;
+
+	/* Embedded controller */
+	device_t	ec_dev;
+	ACPI_HANDLE	ec_handle;
+
+	/* CMOS */
+	ACPI_HANDLE	cmos_handle;
+
+	/* Fan status */
+	ACPI_HANDLE	fan_handle;
+	int		fan_levels;
+
+	/* Keylight commands and states */
+	ACPI_HANDLE	light_handle;
+	int		light_cmd_on;
+	int		light_cmd_off;
+	int		light_val;
+	int		light_get_supported;
+	int		light_set_supported;
+
+	/* led(4) interface */
+	struct cdev	*led_dev;
+	int		led_busy;
+	int		led_state;
+
+	int		wlan_bt_flags;
+	int		thermal_updt_supported;
+
+	unsigned int	events_availmask;
+	unsigned int	events_initialmask;
+	int		events_mask_supported;
+	int		events_enable;
+
+	/* sensors(9) related */
+	struct ksensordev sensordev;
+	struct ksensor sensors[9];	/* XXX: 8 thermal + fan */
+
+	struct sysctl_ctx_list	*sysctl_ctx;
+	struct sysctl_oid	*sysctl_tree;
+};
+
+static struct {
+	char	*name;
+	int	method;
+	char	*description;
+	int	access;
+} acpi_thinkpad_sysctls[] = {
+	{
+		.name		= "events",
+		.method		= ACPI_THINKPAD_METHOD_EVENTS,
+		.description	= "ACPI events enable",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "eventmask",
+		.method		= ACPI_THINKPAD_METHOD_EVENTMASK,
+		.description	= "ACPI eventmask",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "hotkey",
+		.method		= ACPI_THINKPAD_METHOD_HOTKEY,
+		.description	= "Key Status",
+		.access		= CTLTYPE_INT | CTLFLAG_RD
+	},
+	{
+		.name		= "lcd_brightness",
+		.method		= ACPI_THINKPAD_METHOD_BRIGHTNESS,
+		.description	= "LCD Brightness",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "volume",
+		.method		= ACPI_THINKPAD_METHOD_VOLUME,
+		.description	= "Volume",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "mute",
+		.method		= ACPI_THINKPAD_METHOD_MUTE,
+		.description	= "Mute",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "thinklight",
+		.method		= ACPI_THINKPAD_METHOD_THINKLIGHT,
+		.description	= "Thinklight enable",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "bluetooth",
+		.method		= ACPI_THINKPAD_METHOD_BLUETOOTH,
+		.description	= "Bluetooth enable",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "wlan",
+		.method		= ACPI_THINKPAD_METHOD_WLAN,
+		.description	= "WLAN enable",
+		.access		= CTLTYPE_INT | CTLFLAG_RD
+	},
+	{
+		.name		= "fan_level",
+		.method		= ACPI_THINKPAD_METHOD_FANLEVEL,
+		.description	= "Fan level",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "fan",
+		.method		= ACPI_THINKPAD_METHOD_FANSTATUS,
+		.description	= "Fan enable",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+
+	{ NULL, 0, NULL, 0 }
+};
+
+/* ACPI_SERIAL_DECL(thinkpad, "ACPI THINKPAD extras"); */
+static int	acpi_thinkpad_probe(device_t dev);
+static int	acpi_thinkpad_attach(device_t dev);
+static int	acpi_thinkpad_detach(device_t dev);
+
+#if 0 /* not yet */
+static void	thinkpad_led(void *softc, int onoff);
+static void	thinkpad_led_task(struct acpi_thinkpad_softc *sc,
+		int pending __unused);
+#endif
+
+static int	acpi_thinkpad_sysctl(SYSCTL_HANDLER_ARGS);
+static int	acpi_thinkpad_sysctl_init(struct acpi_thinkpad_softc *sc,
+		int method);
+static int	acpi_thinkpad_sysctl_get(struct acpi_thinkpad_softc *sc,
+		int method);
+static int	acpi_thinkpad_sysctl_set(struct acpi_thinkpad_softc *sc,
+		int method, int val);
+
+static int	acpi_thinkpad_eventmask_set(struct acpi_thinkpad_softc *sc,
+		int val);
+static void	acpi_thinkpad_notify(ACPI_HANDLE h, UINT32 notify,
+		void *context);
+static void	acpi_thinkpad_refresh(void *);
+
+static device_method_t acpi_thinkpad_methods[] = {
+	/* Device interface */
+	DEVMETHOD(device_probe, acpi_thinkpad_probe),
+	DEVMETHOD(device_attach, acpi_thinkpad_attach),
+	DEVMETHOD(device_detach, acpi_thinkpad_detach),
+	{0, 0}
+};
+
+static driver_t	acpi_thinkpad_driver = {
+	"acpi_thinkpad",
+	acpi_thinkpad_methods,
+	sizeof(struct acpi_thinkpad_softc),
+};
+
+static devclass_t acpi_thinkpad_devclass;
+
+DRIVER_MODULE(acpi_thinkpad, acpi, acpi_thinkpad_driver,
+    acpi_thinkpad_devclass, 0, 0);
+MODULE_DEPEND(acpi_thinkpad, acpi, 1, 1, 1);
+static char    *thinkpad_ids[] = {"IBM0068", NULL};
+
+#if 0 /* not yet */
+static void
+thinkpad_led(void *softc, int onoff)
+{
+	struct acpi_thinkpad_softc* sc = (struct acpi_thinkpad_softc*) softc;
+
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+
+	if (sc->led_busy)
+		return;
+
+	sc->led_busy = 1;
+	sc->led_state = onoff;
+
+	AcpiOsExecute(OSL_NOTIFY_HANDLER, (void *)thinkpad_led_task, sc);
+}
+
+static void
+thinkpad_led_task(struct acpi_thinkpad_softc *sc, int pending __unused)
+{
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+
+	/* ACPI_SERIAL_BEGIN(thinkpad); */
+	acpi_thinkpad_sysctl_set(sc, ACPI_THINKPAD_METHOD_THINKLIGHT, sc->led_state);
+	/* ACPI_SERIAL_END(thinkpad); */
+
+	sc->led_busy = 0;
+}
+#endif
+
+static int
+acpi_thinkpad_probe(device_t dev)
+{
+	if (acpi_disabled("thinkpad") ||
+	    ACPI_ID_PROBE(device_get_parent(dev), dev, thinkpad_ids) == NULL ||
+	    device_get_unit(dev) != 0) 
+		return (ENXIO);
+
+	device_set_desc(dev, "IBM/Lenovo ThinkPad ACPI Extras");
+	return (0);
+}
+
+static int
+acpi_thinkpad_attach(device_t dev)
+{
+	struct acpi_thinkpad_softc	*sc;
+	struct acpi_softc	*acpi_sc;
+	devclass_t		ec_devclass;
+	int			i;
+
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t) __func__);
+
+	sc = device_get_softc(dev);
+	sc->dev = dev;
+	sc->handle = acpi_get_handle(dev);
+
+	acpi_sc = acpi_device_get_parent_softc(dev);
+
+	/* Look for the first embedded controller */
+        if (!(ec_devclass = devclass_find ("acpi_ec"))) {
+		if (bootverbose)
+			device_printf(dev, "Couldn't find acpi_ec devclass\n");
+		return (EINVAL);
+	}
+        if (!(sc->ec_dev = devclass_get_device(ec_devclass, 0))) {
+		if (bootverbose)
+			device_printf(dev, "Couldn't find acpi_ec device\n");
+		return (EINVAL);
+	}
+	sc->ec_handle = acpi_get_handle(sc->ec_dev);
+
+	/* ACPI_SERIAL_BEGIN(thinkpad); */
+
+#if 0
+	/* Get the sysctl tree */
+	sc->sysctl_ctx = device_get_sysctl_ctx(dev);
+	sc->sysctl_tree = device_get_sysctl_tree(dev);
+#endif
+	sysctl_ctx_init(sc->sysctl_ctx);
+	sc->sysctl_tree = SYSCTL_ADD_NODE(sc->sysctl_ctx,
+	    SYSCTL_CHILDREN(acpi_sc->acpi_sysctl_tree), OID_AUTO,
+	    "thinkpad", CTLFLAG_RD, 0, "");
+
+	/* Look for event mask and hook up the nodes */
+	sc->events_mask_supported = ACPI_SUCCESS(acpi_GetInteger(sc->handle,
+	    THINKPAD_NAME_EVENTS_MASK_GET, &sc->events_initialmask));
+
+	if (sc->events_mask_supported) {
+		SYSCTL_ADD_INT(sc->sysctl_ctx,
+		    SYSCTL_CHILDREN(sc->sysctl_tree), OID_AUTO,
+		    "initialmask", CTLFLAG_RD,
+		    &sc->events_initialmask, 0, "Initial eventmask");
+
+		/* The availmask is the bitmask of supported events */
+		if (ACPI_FAILURE(acpi_GetInteger(sc->handle,
+		    THINKPAD_NAME_EVENTS_AVAILMASK, &sc->events_availmask)))
+			sc->events_availmask = 0xffffffff;
+
+		SYSCTL_ADD_INT(sc->sysctl_ctx,
+		    SYSCTL_CHILDREN(sc->sysctl_tree), OID_AUTO,
+		    "availmask", CTLFLAG_RD,
+		    &sc->events_availmask, 0, "Mask of supported events");
+	}
+
+	/* Hook up proc nodes */
+	for (i = 0; acpi_thinkpad_sysctls[i].name != NULL; i++) {
+		if (!acpi_thinkpad_sysctl_init(sc,
+		    acpi_thinkpad_sysctls[i].method))
+			continue;
+
+		SYSCTL_ADD_PROC(sc->sysctl_ctx,
+		    SYSCTL_CHILDREN(sc->sysctl_tree), OID_AUTO,
+		    acpi_thinkpad_sysctls[i].name,
+		    acpi_thinkpad_sysctls[i].access,
+		    sc, i, acpi_thinkpad_sysctl, "I",
+		    acpi_thinkpad_sysctls[i].description);
+	}
+
+	/* ACPI_SERIAL_END(thinkpad); */
+
+	/* Handle notifies */
+	AcpiInstallNotifyHandler(sc->handle, ACPI_DEVICE_NOTIFY,
+	    acpi_thinkpad_notify, dev);
+
+#if 0
+	/* Hook up light to led(4) */
+	if (sc->light_set_supported)
+		sc->led_dev = led_create_state(thinkpad_led, sc, "thinklight",
+		    sc->light_val);
+#endif
+	/* Attach sensors(9). */
+	if (sensor_task_register(sc, acpi_thinkpad_refresh, 5)) {
+		device_printf(sc->dev, "unable to register update task\n");
+		return 1;
+	}
+
+	strlcpy(sc->sensordev.xname, device_get_nameunit(sc->dev),
+	    sizeof(sc->sensordev.xname));
+
+	/* XXX: Temp sensors */
+	for (i = 0; i < 8; ++i) {
+		sc->sensors[i].type = SENSOR_TEMP;
+		sensor_attach(&sc->sensordev, &sc->sensors[i]);
+	}
+	
+	/* Fan RPM sensor */
+	sc->sensors[8].type = SENSOR_FANRPM;
+	sensor_attach(&sc->sensordev, &sc->sensors[8]);
+
+	sensordev_install(&sc->sensordev);
+
+	return (0);
+}
+
+static int
+acpi_thinkpad_detach(device_t dev)
+{
+	int i;
+
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t) __func__);
+
+	struct acpi_thinkpad_softc *sc = device_get_softc(dev);
+
+	/* Disable events and restore eventmask */
+	/* ACPI_SERIAL_BEGIN(thinkpad); */
+	acpi_thinkpad_sysctl_set(sc, ACPI_THINKPAD_METHOD_EVENTS, 0);
+	acpi_thinkpad_sysctl_set(sc, ACPI_THINKPAD_METHOD_EVENTMASK,
+	    sc->events_initialmask);
+	/* ACPI_SERIAL_END(thinkpad); */
+
+	AcpiRemoveNotifyHandler(sc->handle, ACPI_DEVICE_NOTIFY,
+	    acpi_thinkpad_notify);
+
+	sysctl_ctx_free(sc->sysctl_ctx);
+
+#if 0
+	if (sc->led_dev != NULL)
+		led_destroy(sc->led_dev);
+#endif
+	sensordev_deinstall(&sc->sensordev);
+	for (i = 0; i < 9; i++)
+		sensor_detach(&sc->sensordev, &sc->sensors[i]);
+	sensor_task_unregister(sc);
+
+	return (0);
+}
+
+static int
+acpi_thinkpad_eventmask_set(struct acpi_thinkpad_softc *sc, int val)
+{
+	int i;
+	ACPI_OBJECT		arg[2];
+	ACPI_OBJECT_LIST	args;
+	ACPI_STATUS		status;
+
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+	/* ACPI_SERIAL_ASSERT(thinkpad); */
+
+	args.Count = 2;
+	args.Pointer = arg;
+	arg[0].Type = ACPI_TYPE_INTEGER;
+	arg[1].Type = ACPI_TYPE_INTEGER;
+
+	for (i = 0; i < 32; ++i) {
+		arg[0].Integer.Value = i+1;
+		arg[1].Integer.Value = (((1 << i) & val) != 0);
+		status = AcpiEvaluateObject(sc->handle,
+		    THINKPAD_NAME_EVENTS_MASK_SET, &args, NULL);
+
+		if (ACPI_FAILURE(status))
+			return (status);
+	}
+
+	return (0);
+}
+
+static int
+acpi_thinkpad_sysctl(SYSCTL_HANDLER_ARGS)
+{
+	struct acpi_thinkpad_softc	*sc;
+	int			arg;
+	int			error = 0;
+	int			function;
+	int			method;
+	
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+
+	sc = (struct acpi_thinkpad_softc *)oidp->oid_arg1;
+	function = oidp->oid_arg2;
+	method = acpi_thinkpad_sysctls[function].method;
+
+	/* ACPI_SERIAL_BEGIN(thinkpad); */
+	arg = acpi_thinkpad_sysctl_get(sc, method);
+	error = sysctl_handle_int(oidp, &arg, 0, req);
+
+	/* Sanity check */
+	if (error != 0 || req->newptr == NULL)
+		goto out;
+
+	/* Update */
+	error = acpi_thinkpad_sysctl_set(sc, method, arg);
+
+out:
+	/* ACPI_SERIAL_END(thinkpad); */
+	return (error);
+}
+
+static int
+acpi_thinkpad_sysctl_get(struct acpi_thinkpad_softc *sc, int method)
+{
+	ACPI_INTEGER	val_ec;
+	int 		val = 0, key;
+
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+	/* ACPI_SERIAL_ASSERT(thinkpad); */
+
+	switch (method) {
+	case ACPI_THINKPAD_METHOD_EVENTS:
+		acpi_GetInteger(sc->handle, THINKPAD_NAME_EVENTS_STATUS_GET,
+		    &val);
+		break;
+
+	case ACPI_THINKPAD_METHOD_EVENTMASK:
+		if (sc->events_mask_supported)
+			acpi_GetInteger(sc->handle,
+			    THINKPAD_NAME_EVENTS_MASK_GET, &val);
+		break;
+
+	case ACPI_THINKPAD_METHOD_HOTKEY:
+		/*
+		 * Construct the hotkey as a bitmask as illustrated below.
+		 * Note that whenever a key was pressed, the respecting bit
+		 * toggles and nothing else changes.
+		 * +--+--+-+-+-+-+-+-+-+-+-+-+
+		 * |11|10|9|8|7|6|5|4|3|2|1|0|
+		 * +--+--+-+-+-+-+-+-+-+-+-+-+
+		 *   |  | | | | | | | | | | |
+		 *   |  | | | | | | | | | | +- Home Button
+		 *   |  | | | | | | | | | +--- Search Button
+		 *   |  | | | | | | | | +----- Mail Button
+		 *   |  | | | | | | | +------- Thinkpad Button
+		 *   |  | | | | | | +--------- Zoom (Fn + Space)
+		 *   |  | | | | | +----------- WLAN Button
+		 *   |  | | | | +------------- Video Button
+		 *   |  | | | +--------------- Hibernate Button
+		 *   |  | | +----------------- Thinklight Button
+		 *   |  | +------------------- Screen expand (Fn + F8)
+		 *   |  +--------------------- Brightness
+		 *   +------------------------ Volume/Mute
+		 */
+		key = rtcin(THINKPAD_RTC_HOTKEY1);
+		val = (THINKPAD_RTC_MASK_HOME | THINKPAD_RTC_MASK_SEARCH |
+		    THINKPAD_RTC_MASK_MAIL | THINKPAD_RTC_MASK_WLAN) & key;
+		key = rtcin(THINKPAD_RTC_HOTKEY2);
+		val |= (THINKPAD_RTC_MASK_THINKPAD | THINKPAD_RTC_MASK_VIDEO |
+		    THINKPAD_RTC_MASK_HIBERNATE) & key;
+		val |= (THINKPAD_RTC_MASK_ZOOM & key) >> 1;
+		key = rtcin(THINKPAD_RTC_THINKLIGHT);
+		val |= (THINKPAD_RTC_MASK_THINKLIGHT & key) << 4;
+		key = rtcin(THINKPAD_RTC_SCREENEXPAND);
+		val |= (THINKPAD_RTC_MASK_THINKLIGHT & key) << 4;
+		key = rtcin(THINKPAD_RTC_BRIGHTNESS);
+		val |= (THINKPAD_RTC_MASK_BRIGHTNESS & key) << 5;
+		key = rtcin(THINKPAD_RTC_VOLUME);
+		val |= (THINKPAD_RTC_MASK_VOLUME & key) << 4;
+		break;
+
+	case ACPI_THINKPAD_METHOD_BRIGHTNESS:
+		ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_BRIGHTNESS, &val_ec, 1);
+		val = val_ec & THINKPAD_EC_MASK_BRI;
+		break;
+
+	case ACPI_THINKPAD_METHOD_VOLUME:
+		ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_VOLUME, &val_ec, 1);
+		val = val_ec & THINKPAD_EC_MASK_VOL;
+		break;
+
+	case ACPI_THINKPAD_METHOD_MUTE:
+		val = ((val_ec & THINKPAD_EC_MASK_MUTE) ==
+		    THINKPAD_EC_MASK_MUTE);
+		break;
+
+	case ACPI_THINKPAD_METHOD_THINKLIGHT:
+		if (sc->light_get_supported)
+			acpi_GetInteger(sc->ec_handle, THINKPAD_NAME_KEYLIGHT,
+			    &val);
+		else
+			val = sc->light_val;
+		break;
+
+	case ACPI_THINKPAD_METHOD_BLUETOOTH:
+		acpi_GetInteger(sc->handle, THINKPAD_NAME_WLAN_BT_GET, &val);
+		sc->wlan_bt_flags = val;
+		val = ((val & THINKPAD_NAME_MASK_BT) != 0);
+		break;
+
+	case ACPI_THINKPAD_METHOD_WLAN:
+		acpi_GetInteger(sc->handle, THINKPAD_NAME_WLAN_BT_GET, &val);
+		sc->wlan_bt_flags = val;
+		val = ((val & THINKPAD_NAME_MASK_WLAN) != 0);
+		break;
+
+	case ACPI_THINKPAD_METHOD_FANSPEED:
+		if (sc->fan_handle) {
+			if (ACPI_FAILURE(acpi_GetInteger(sc->fan_handle,
+			    NULL, &val)))
+				val = -1;
+		}
+		else {
+			ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_FANSPEED,
+			    &val_ec, 2);
+			val = val_ec;
+		}
+		break;
+
+	case ACPI_THINKPAD_METHOD_FANLEVEL:
+		/*
+		 * The THINKPAD_EC_FANSTATUS register works as follows:
+		 * Bit 0-5 indicate the level at which the fan operates. Only
+		 *       values between 0 and 7 have an effect. Everything
+		 *       above 7 is treated the same as level 7
+		 * Bit 6 overrides the fan speed limit if set to 1
+		 * Bit 7 indicates at which mode the fan operates:
+		 *       manual (0) or automatic (1)
+		 */
+		if (!sc->fan_handle) {
+			ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_FANSTATUS,
+			    &val_ec, 1);
+			val = val_ec & THINKPAD_EC_MASK_FANLEVEL;
+		}
+		break;
+
+	case ACPI_THINKPAD_METHOD_FANSTATUS:
+		if (!sc->fan_handle) {
+			ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_FANSTATUS,
+			    &val_ec, 1);
+			val = (val_ec & THINKPAD_EC_MASK_FANSTATUS) ==
+			    THINKPAD_EC_MASK_FANSTATUS;
+		}
+		else
+			val = -1;
+		break;
+	}
+
+	return (val);
+}
+
+static int
+acpi_thinkpad_sysctl_set(struct acpi_thinkpad_softc *sc, int method, int arg)
+{
+	int			val, step, i;
+	ACPI_INTEGER		val_ec;
+	ACPI_OBJECT		Arg;
+	ACPI_OBJECT_LIST	Args;
+	ACPI_STATUS		status;
+
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+	/* ACPI_SERIAL_ASSERT(thinkpad); */
+
+	switch (method) {
+	case ACPI_THINKPAD_METHOD_EVENTS:
+		if (arg < 0 || arg > 1)
+			return (EINVAL);
+
+		status = acpi_SetInteger(sc->handle,
+		    THINKPAD_NAME_EVENTS_STATUS_SET, arg);
+		if (ACPI_FAILURE(status))
+			return (status);
+		if (sc->events_mask_supported)
+			return acpi_thinkpad_eventmask_set(sc,
+			    sc->events_availmask);
+		break;
+
+	case ACPI_THINKPAD_METHOD_EVENTMASK:
+		if (sc->events_mask_supported)
+			return acpi_thinkpad_eventmask_set(sc, arg);
+		break;
+
+	case ACPI_THINKPAD_METHOD_BRIGHTNESS:
+		if (arg < 0 || arg > 7)
+			return (EINVAL);
+
+		if (sc->cmos_handle) {
+			/* Read the current brightness */
+			status = ACPI_EC_READ(sc->ec_dev,
+			    THINKPAD_EC_BRIGHTNESS, &val_ec, 1);
+			if (ACPI_FAILURE(status))
+				return (status);
+			val = val_ec & THINKPAD_EC_MASK_BRI;
+
+			Args.Count = 1;
+			Args.Pointer = &Arg;
+			Arg.Type = ACPI_TYPE_INTEGER;
+			Arg.Integer.Value = (arg > val) ?
+			    THINKPAD_CMOS_BRIGHTNESS_UP :
+			    THINKPAD_CMOS_BRIGHTNESS_DOWN;
+
+			step = (arg > val) ? 1 : -1;
+			for (i = val; i != arg; i += step) {
+				status = AcpiEvaluateObject(sc->cmos_handle,
+				    NULL, &Args, NULL);
+				if (ACPI_FAILURE(status))
+					break;
+			}
+		}
+		return ACPI_EC_WRITE(sc->ec_dev, THINKPAD_EC_BRIGHTNESS,
+		    arg, 1);
+		break;
+
+	case ACPI_THINKPAD_METHOD_VOLUME:
+		if (arg < 0 || arg > 14)
+			return (EINVAL);
+
+		status = ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_VOLUME,
+		    &val_ec, 1);
+		if (ACPI_FAILURE(status))
+			return (status);
+
+		if (sc->cmos_handle) {
+			val = val_ec & THINKPAD_EC_MASK_VOL;
+
+			Args.Count = 1;
+			Args.Pointer = &Arg;
+			Arg.Type = ACPI_TYPE_INTEGER;
+			Arg.Integer.Value = (arg > val) ?
+			    THINKPAD_CMOS_VOLUME_UP : THINKPAD_CMOS_VOLUME_DOWN;
+
+			step = (arg > val) ? 1 : -1;
+			for (i = val; i != arg; i += step) {
+				status = AcpiEvaluateObject(sc->cmos_handle,
+				    NULL, &Args, NULL);
+				if (ACPI_FAILURE(status))
+					break;
+			}
+		}
+		return ACPI_EC_WRITE(sc->ec_dev, THINKPAD_EC_VOLUME, arg +
+		    (val_ec & (~THINKPAD_EC_MASK_VOL)), 1);
+		break;
+
+	case ACPI_THINKPAD_METHOD_MUTE:
+		if (arg < 0 || arg > 1)
+			return (EINVAL);
+
+		status = ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_VOLUME,
+		    &val_ec, 1);
+		if (ACPI_FAILURE(status))
+			return (status);
+
+		if (sc->cmos_handle) {
+			val = val_ec & THINKPAD_EC_MASK_VOL;
+
+			Args.Count = 1;
+			Args.Pointer = &Arg;
+			Arg.Type = ACPI_TYPE_INTEGER;
+			Arg.Integer.Value = THINKPAD_CMOS_VOLUME_MUTE;
+
+			status = AcpiEvaluateObject(sc->cmos_handle, NULL,
+			    &Args, NULL);
+			if (ACPI_FAILURE(status))
+				break;
+		}
+		return ACPI_EC_WRITE(sc->ec_dev, THINKPAD_EC_VOLUME, (arg==1) ?
+		   val_ec | THINKPAD_EC_MASK_MUTE :
+		   val_ec & (~THINKPAD_EC_MASK_MUTE), 1);
+		break;
+
+	case ACPI_THINKPAD_METHOD_THINKLIGHT:
+		if (arg < 0 || arg > 1)
+			return (EINVAL);
+
+		if (sc->light_set_supported) {
+			Args.Count = 1;
+			Args.Pointer = &Arg;
+			Arg.Type = ACPI_TYPE_INTEGER;
+			Arg.Integer.Value = arg ?
+			    sc->light_cmd_on : sc->light_cmd_off;
+
+			status = AcpiEvaluateObject(sc->light_handle, NULL,
+			    &Args, NULL);
+			if (ACPI_SUCCESS(status))
+				sc->light_val = arg;
+			return (status);
+		}
+		break;
+
+	case ACPI_THINKPAD_METHOD_BLUETOOTH:
+		if (arg < 0 || arg > 1)
+			return (EINVAL);
+
+		val = (arg == 1) ? sc->wlan_bt_flags |
+		    THINKPAD_NAME_MASK_BT :
+		    sc->wlan_bt_flags & (~THINKPAD_NAME_MASK_BT);
+		return acpi_SetInteger(sc->handle, THINKPAD_NAME_WLAN_BT_SET,
+		    val);
+		break;
+
+	case ACPI_THINKPAD_METHOD_FANLEVEL:
+		if (arg < 0 || arg > 7)
+			return (EINVAL);
+
+		if (!sc->fan_handle) {
+			/* Read the current fanstatus */
+			ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_FANSTATUS,
+			    &val_ec, 1);
+			val = val_ec & (~THINKPAD_EC_MASK_FANLEVEL);
+
+			return ACPI_EC_WRITE(sc->ec_dev, THINKPAD_EC_FANSTATUS,
+			    val | arg, 1);
+		}
+		break;
+
+	case ACPI_THINKPAD_METHOD_FANSTATUS:
+		if (arg < 0 || arg > 1)
+			return (EINVAL);
+
+		if (!sc->fan_handle) {
+			/* Read the current fanstatus */
+			ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_FANSTATUS,
+			    &val_ec, 1);
+
+			return ACPI_EC_WRITE(sc->ec_dev, THINKPAD_EC_FANSTATUS,
+			    (arg == 1) ? (val_ec | THINKPAD_EC_MASK_FANSTATUS) :
+			    (val_ec & (~THINKPAD_EC_MASK_FANSTATUS)), 1);
+		}
+		break;
+	}
+
+	return (0);
+}
+
+static int
+acpi_thinkpad_sysctl_init(struct acpi_thinkpad_softc *sc, int method)
+{
+	int 			dummy;
+	ACPI_OBJECT_TYPE 	cmos_t;
+	ACPI_HANDLE		ledb_handle;
+
+	switch (method) {
+	case ACPI_THINKPAD_METHOD_EVENTS:
+		/* Events are disabled by default */
+		return (TRUE);
+
+	case ACPI_THINKPAD_METHOD_EVENTMASK:
+		return (sc->events_mask_supported);
+
+	case ACPI_THINKPAD_METHOD_HOTKEY:
+	case ACPI_THINKPAD_METHOD_BRIGHTNESS:
+	case ACPI_THINKPAD_METHOD_VOLUME:
+	case ACPI_THINKPAD_METHOD_MUTE:
+		/* EC is required here, which was already checked before */
+		return (TRUE);
+
+	case ACPI_THINKPAD_METHOD_THINKLIGHT:
+		sc->cmos_handle = NULL;
+		sc->light_get_supported = ACPI_SUCCESS(acpi_GetInteger(
+		    sc->ec_handle, THINKPAD_NAME_KEYLIGHT, &sc->light_val));
+
+		if ((ACPI_SUCCESS(AcpiGetHandle(sc->handle, "\\UCMS",
+		    &sc->light_handle)) ||
+		    ACPI_SUCCESS(AcpiGetHandle(sc->handle, "\\CMOS",
+		    &sc->light_handle)) ||
+		    ACPI_SUCCESS(AcpiGetHandle(sc->handle, "\\CMS",
+		    &sc->light_handle))) &&
+		    ACPI_SUCCESS(AcpiGetType(sc->light_handle, &cmos_t)) &&
+		    cmos_t == ACPI_TYPE_METHOD) {
+			sc->light_cmd_on = 0x0c;
+			sc->light_cmd_off = 0x0d;
+			sc->cmos_handle = sc->light_handle;
+		}
+		else if (ACPI_SUCCESS(AcpiGetHandle(sc->handle, "\\LGHT",
+		    &sc->light_handle))) {
+			sc->light_cmd_on = 1;
+			sc->light_cmd_off = 0;
+		}
+		else
+			sc->light_handle = NULL;
+
+		sc->light_set_supported = (sc->light_handle &&
+		    ACPI_FAILURE(AcpiGetHandle(sc->ec_handle, "LEDB",
+		    &ledb_handle)));
+
+		if (sc->light_get_supported)
+			return (TRUE);
+
+		if (sc->light_set_supported) {
+			sc->light_val = 0;
+			return (TRUE);
+		}
+
+		return (FALSE);
+
+	case ACPI_THINKPAD_METHOD_BLUETOOTH:
+	case ACPI_THINKPAD_METHOD_WLAN:
+		if (ACPI_SUCCESS(acpi_GetInteger(sc->handle,
+		    THINKPAD_NAME_WLAN_BT_GET, &dummy)))
+			return (TRUE);
+		return (FALSE);
+
+	case ACPI_THINKPAD_METHOD_FANSPEED:
+		/* 
+		 * Some models report the fan speed in levels from 0-7
+		 * Newer models report it contiguously
+		 */
+		sc->fan_levels = (ACPI_SUCCESS(AcpiGetHandle(sc->handle, "GFAN",
+		    &sc->fan_handle)) ||
+		    ACPI_SUCCESS(AcpiGetHandle(sc->handle, "\\FSPD",
+		    &sc->fan_handle)));
+		return (TRUE);
+
+	case ACPI_THINKPAD_METHOD_FANLEVEL:
+	case ACPI_THINKPAD_METHOD_FANSTATUS:
+		/* 
+		 * Fan status is only supported on those models,
+		 * which report fan RPM contiguously, not in levels
+		 */
+		if (sc->fan_levels)
+			return (FALSE);
+		return (TRUE);
+
+	case ACPI_THINKPAD_METHOD_THERMAL:
+		if (ACPI_SUCCESS(acpi_GetInteger(sc->ec_handle,
+		    THINKPAD_NAME_THERMAL_GET, &dummy))) {
+			sc->thermal_updt_supported =
+			    ACPI_SUCCESS(acpi_GetInteger(sc->ec_handle,
+			    THINKPAD_NAME_THERMAL_UPDT, &dummy));
+			return (TRUE);
+		}
+		return (FALSE);
+	}
+	return (FALSE);
+}
+
+static void
+acpi_thinkpad_notify(ACPI_HANDLE h, UINT32 notify, void *context)
+{
+	int		event, arg, type;
+	device_t	dev = context;
+	struct acpi_thinkpad_softc *sc = device_get_softc(dev);
+
+	ACPI_FUNCTION_TRACE_U32((char *)(uintptr_t)__func__, notify);
+
+	if (notify != 0x80)
+		device_printf(dev, "Unknown notify\n");
+
+	for (;;) {
+		acpi_GetInteger(acpi_get_handle(dev), THINKPAD_NAME_EVENTS_GET,
+		    &event);
+
+		if (event == 0)
+			break;
+
+		type = (event >> 12) & 0xf;
+		arg = event & 0xfff;
+		switch (type) {
+		case 1:
+			if (!(sc->events_availmask & (1 << (arg - 1)))) {
+				device_printf(dev, "Unknown key %d\n", arg);
+				break;
+			}
+
+			/* Notify devd(8) */
+			device_printf(dev, "THINKPAD event: %u\n",
+			    (arg & 0xff));
+			acpi_UserNotify("THINKPAD", h, (arg & 0xff));
+			break;
+		default:
+			break;
+		}
+	}
+}
+
+static void
+acpi_thinkpad_refresh(void *arg)
+{
+	struct acpi_thinkpad_softc *sc = (struct acpi_thinkpad_softc *)arg;
+	char temp_cmd[] = "TMP0";
+	int data, i;
+	ACPI_INTEGER speed;
+
+	for (i = 0; i < 8; i++) {
+		temp_cmd[3] = '0' + i;
+		
+                /*
+                 * The TMPx methods seem to return +/- 128 or 0
+                 * when the respecting sensor is not available
+                 */
+		sc->sensors[i].flags &= ~SENSOR_FINVALID;
+                if (ACPI_FAILURE(acpi_GetInteger(sc->ec_handle, temp_cmd,
+                    &data)) || ABS(data) == 128 || data == 0) {
+			sc->sensors[i].flags |= SENSOR_FINVALID;
+                        data = 0;
+		}
+                else if (sc->thermal_updt_supported) {
+                        /* XXX: Temperature is reported in tenth of Kelvin */
+                        data = (data - 2732 + 5) / 10;
+		}
+		sc->sensors[i].value = data * 1000000 + 273150000;
+        }
+	
+	sc->sensors[8].flags &= ~SENSOR_FINVALID;
+	if (sc->fan_handle) {
+		if (ACPI_FAILURE(acpi_GetInteger(sc->fan_handle,
+		    NULL, &data)))
+			sc->sensors[8].flags |= SENSOR_FINVALID;
+                        data = -1;
+        }
+        else {
+                ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_FANSPEED, &speed, 2);
+                data = speed;
+        }
+
+	sc->sensors[8].value = data;
+}
diff --git a/sys/platform/pc32/conf/files b/sys/platform/pc32/conf/files
--- a/sys/platform/pc32/conf/files
+++ b/sys/platform/pc32/conf/files
@@ -72,6 +72,7 @@ dev/serial/dgb/dgm.c			optional	dgm
 ${OSACPI_MD_DIR}/acpi_machdep.c		optional        acpi
 ${OSACPI_MD_DIR}/acpi_wakeup.c		optional        acpi
 ${OSACPI_MD_DIR}/acpi_toshiba.c		optional        acpi_toshiba acpi
+${ACPICA_DIR}/acpi_thinkpad/acpi_thinkpad.c optional	acpi_thinkpad acpi
 acpi.h					optional	acpi		\
 	dependency	"$S/${ACPICA_DIR}/include/acpi.h"		\
 	compile-with	"cp $S/${ACPICA_DIR}/include/acpi.h ${.OBJDIR}/"	\



From hasso at estpak.ee  Thu Mar 20 03:49:13 2008
From: hasso at estpak.ee (Hasso Tepper)
Date: Thu, 20 Mar 2008 03:49:13 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Some questions regarding ACPI
In-Reply-To: <200803191322.46366.hasso@estpak.ee>
Message-ID: <200803201237.28823.hasso@estpak.ee>

Hasso Tepper wrote:
> There is also one fatal issue -laptop locks up hardly (no panic) while 
> unloading module. Any idea regarding this is welcome.

Nevermind, solved.


-- 
Hasso




From dillon at apollo.backplane.com  Fri Mar 21 19:24:01 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Fri, 21 Mar 2008 19:24:01 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: panic: assertion: hammer_btree_cmp(cursor->left_bound,	&cursor->node->ondisk->elms[0].leaf.base) <= 0 in btree_split_leaf
In-Reply-To: <200802232204.m1NM4cxd046264@apollo.backplane.com>
Message-ID: <200803220212.m2M2CiAY014435@apollo.backplane.com>

:While trying to find a procedure to reliably reproduce the panic
:I reported last time, I caught a different panic (uploaded at
: ~y0netan1/crash/9/ on my leaf account).  I wrote the following shell
:script (make sure to edit variables DISKS and MOUNTPT before using this
:script or it may trash your system):

    Ok, I believe I have fixed the left_bound assertion.  I also believe
    I have fixed the node ref count assertion on umount.

    There is currently one unfixed assertion related to the I/O
    path... sometimes the bp is being improperly disassociated from the
    related HAMMER structure.

    The full-filesystem case is still not being handled so don't test that :-)

					    -Matt





From c.turner at 199technologies.org  Sun Mar 23 09:48:29 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Sun, 23 Mar 2008 09:48:29 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
Message-ID: <47E6870C.4080709@199technologies.org>

I'm finally getting around to doing 1.12 upgrades, and have setup a 
separate machine to do my bulk package builds / upgrades etc,
so as not to disrupt my 'dev server' while things are being
built / tested

However, this seems kind of wasteful - the only purpose of this machine
is to build packages against a specific release..
And since building packages for a particular release generally requires 
only the userland, appropriate headers and correct 'uname' output - so:

it seems like if spoofing uname is configured inside a jail,
the next (or previous..) release can be installed into a jail and
used for building / testing packages without the overhead of a VM or 
maintaining a separate physical host

I did a quick scan of the tree to see what this would take, and, high 
level, it seems like only the following changes would need to be made:

- update struct jail to add a 'osrelease' string
  (implies bumping 'jail api' to 2?)
- update jail(8) to actually pass this information along
- update sys_uname to test ucred for jailed processes, and
  use the struct jail osrelease if appropriate
- similarly update sysctl kern.osrelease to support jail spoofing
  (if possible - didn't get this far in the research yet)
  could be less of a problem for builds, as I think most things use
 uname(1) ... but good to keep the environment consistent I suppose..
I'm still a bit confused as to how 'osrelease' is defined - everything
I'm finding is showing up as extern char[] .. perhaps this is something 
in the build I'm not familiar with?

also,

is the so-called 'stupid hackery' in sys_uname needed still?

Before I start any coding, does this:

- sound like something useful
- sound like the right approach
Thinking this could have wider useful implications e.g. for pkgbox
& so on -  for example setting up automated bulks w/various combinations 
of pkgsrc and releases, etc.

Cheers,

- Chris





From corecode at fs.ei.tum.de  Sun Mar 23 10:06:38 2008
From: corecode at fs.ei.tum.de (Simon 'corecode' Schubert)
Date: Sun, 23 Mar 2008 10:06:38 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <47E68C74.3080808@fs.ei.tum.de>

Chris Turner wrote:
I did a quick scan of the tree to see what this would take, and, high 
level, it seems like only the following changes would need to be made:
brave investigation.  but you could also simply set UNAME_r :)

sweatshorts % uname -r
1.13.0-DEVELOPMENT
sweatshorts % UNAME_r=1.12-RELEASE uname -r
1.12-RELEASE
I think that's good enough :D

cheers
  simon
--
Serve - BSD     +++  RENT this banner advert  +++    ASCII Ribbon   /"\
Work - Mac      +++  space for low ????????? NOW!1  +++      Campaign     \ /
Party Enjoy Relax   |   http://dragonflybsd.org      Against  HTML   \
Dude 2c 2 the max   !   http://golden-apple.biz       Mail + News   / \




From c.turner at 199technologies.org  Sun Mar 23 10:50:13 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Sun, 23 Mar 2008 10:50:13 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <47E69656.8080605@199technologies.org>

Simon 'corecode' Schubert wrote:
brave investigation.  but you could also simply set UNAME_r :)
Doh! Thanks for the tip!

they should change the phrase from RTFM to 'Carefully RTFM' :)

well.. scratch that change then. 1 less patch to write.

- Chris





From c.turner at 199technologies.org  Sun Mar 23 11:15:52 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Sun, 23 Mar 2008 11:15:52 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <47E69C7C.8010109@199technologies.org>

Chris Turner wrote:
Simon 'corecode' Schubert wrote:
brave investigation.  but you could also simply set UNAME_r :)

for the record - if anyone's interested - adding a line e.g.:

ALL_ENV+= UNAME_r=1.12-RELEASE

to mk.conf looks like it -might- work ..

(unless wants to chime in & verify)





From joerg at britannica.bec.de  Sun Mar 23 11:46:53 2008
From: joerg at britannica.bec.de (Joerg Sonnenberger)
Date: Sun, 23 Mar 2008 11:46:53 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <20080323181428.GA2099@britannica.bec.de>

On Sun, Mar 23, 2008 at 01:41:42PM -0400, Chris Turner wrote:
> they should change the phrase from RTFM to 'Carefully RTFM' :)

RTFMAI -- Read The Fine Manual Again, Idiot.

Joerg




From dillon at apollo.backplane.com  Sun Mar 23 20:05:36 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Sun, 23 Mar 2008 20:05:36 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
Message-ID: <200803240257.m2O2voNH038355@apollo.backplane.com>

    Here's an update on the HAMMER work!

    Current status:

    * Passes all standard filesystem stress tests and buildworld will
      run with a HAMMER /usr/obj.  Large histories are able to accumulate
      without effecting performance.

    * Pruning and reblocking code is in and partially tested, but now needs
      more stringent testing.

    * Full historical access appears to be working but needs testing.
      Note that a sync is still needed to flush dirty cached data prior
      to acquiring a timestamp for the 'snapshot' to be set in stone.
      (dirty data cached in-memory has no historical tags and must be
      committed to physical disk before it can be accessed historically).


    Current bugs:

    * There is one known bug in the standard operations code paths
      that results in an assertion in HAMMER's I/O subsystem.

    * There are probably bugs in the reblocking and/or pruning code.  More
      likely in the reblocking code.


    There are two big-ticket and several little-ticket items left.  HAMMER
    will officially go Alpha when the big-ticket items are done, and beta
    when we get a few of the little-ticket items done.

    Big ticket items left:

    * UNDO (crash recovery) code.  Currently it writes out undo records but
      they are not yet sequenced, buffer writes are not yet ordered, and
      there is no mount-time recovery code yet.

      This is the last item needed before HAMMER can go operational.

    * Filesystem full handling.  Currently no space is reserved for dirty
      cached data so it is possible to create/write files and for HAMMER
      to not have sufficient space left on-disk to flush it.


    Little ticket items:

    * Automated reblocking (currently these functions are manually
      initialized via the hammer utility).

    * I/O clustering and preliminary BMAP op when writing out large files.

    * CRC checking (CRC fields are reserved but not entirely generated yet
      and not yet checked at all).

    * Disaster Recovery filesystem scan.

    * Boot support.

    I expect all of these items and more to be handled by the 2.0 release
    in July.

			    Additional HAMMER capabilities
				(no timeline yet)

    * Adding, removing, and resizing a HAMMER filesystem's backing store.

			Ultimate Goals and working towards them
				(no timeline yet)

    Our ultimate goal with HAMMER and DragonFly in general is to support
    fully cache coherent replication in a multi-machine environment.  This
    involves several steps and networking protocols.

    * Replication of synchronization streams based on the UNDO log.  If
      resynchronizing to a target which is too old a B-Tree scan will
      likely be required.

    * Cache coherency protocols for machine-machine coherency for both
      replicated and remote-HAMMER access.

    I have no time frame for these items yet.  It will depend on how quickly
    HAMMER moves to Alpha and Beta status.  I will say, however, now
    that HAMMER's on-disk format has solidified, that I have a very precise
    understanding of the protocols that will be needed to accomplish fully
    cache coherent remote access for both replicated and non-replicated
    (remote mount style) access.

    And, as you know, fully coherent filesystem access across machines is
    going to be the basis for DragonFly's clustering across said machines.

    In summary, things are progressing very well.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From justin at shiningsilence.com  Sun Mar 23 20:10:13 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Sun, 23 Mar 2008 20:10:13 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <53758.192.168.0.252.1206327873.squirrel@www.shiningsilence.com>

On Sun, March 23, 2008 12:36 pm, Chris Turner wrote:

> it seems like if spoofing uname is configured inside a jail,
> the next (or previous..) release can be installed into a jail and
> used for building / testing packages without the overhead of a VM or
> maintaining a separate physical host

If you don't need a jail to spoof uname, as others posted, you can
installworld into a chroot and build everything you want there using
Joerg's spiffy pbulk.  That's what I'm doing on pkgbox now; I can hand you
my somewhat terse notes if you want.  It would be relatively easy to set
up the configuration you're talking about.





From sepherosa at gmail.com  Sun Mar 23 20:18:20 2008
From: sepherosa at gmail.com (Sepherosa Ziehau)
Date: Sun, 23 Mar 2008 20:18:20 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <ea7b9c170803232012n2f27f893tf1d756d7c9770419@mail.gmail.com>

On Mon, Mar 24, 2008 at 2:14 AM, Joerg Sonnenberger
<joerg at britannica.bec.de> wrote:
> On Sun, Mar 23, 2008 at 01:41:42PM -0400, Chris Turner wrote:
>  > they should change the phrase from RTFM to 'Carefully RTFM' :)
>
>  RTFMAI -- Read The Fine Manual Again, Idiot.

http://leaf.dragonflybsd.org/~sephe/rtfm.jpg

:D

>
>  Joerg
>



-- 
Live Free or Die




From justin at shiningsilence.com  Sun Mar 23 20:38:30 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Sun, 23 Mar 2008 20:38:30 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: GSoC 2008 - mentors signup
Message-ID: <53885.192.168.0.252.1206329503.squirrel@www.shiningsilence.com>

If you are planning to be a mentor for a Summer of Code project, please
sign up here for the mentors mailing list:

http://groups.google.com/group/google-summer-of-code-mentors-list

If you've already signed up, your subscription should be set up tomorrow.





From justin at shiningsilence.com  Sun Mar 23 21:12:01 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Sun, 23 Mar 2008 21:12:01 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: GSoC 2008 - mentors signup
In-Reply-To: <53885.192.168.0.252.1206329503.squirrel@www.shiningsilence.com>
Message-ID: <54025.192.168.0.252.1206331572.squirrel@www.shiningsilence.com>

Also!

If you are a potential mentor and you have not done so yet:

http://code.google.com/soc/mentor_step1.html

Get yourself registered as a mentor for the Summer of Code project.  Once
you are in there, check off DragonFly in the "My Profile" section.

You will need a Google Account if you don't have one:

http://www.google.com/accounts

This will add you to the list of mentors in the Google Summer of Code web
application, so you can review/be attached to projects.

A guide is available if you want more information:

http://groups.google.com/group/google-summer-of-code-announce/web/guide-to-the-gsoc-web-app-for-mentors-and-organization-administrators






From c.turner at 199technologies.org  Mon Mar 24 04:29:28 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Mon, 24 Mar 2008 04:29:28 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <47E78ECE.4070307@199technologies.org>

Justin C. Sherrill wrote:
If you don't need a jail to spoof uname, as others posted, you can
installworld into a chroot and build everything you want there using
Joerg's spiffy pbulk.  That's what I'm doing on pkgbox now; I can hand you
my somewhat terse notes if you want.  It would be relatively easy to set
up the configuration you're talking about.
cheers - I guess I thought incorrectly that something 'special' was 
needed to get the uname to change .. have been using the legacy bulks in 
chroots / jails (for 'same os' builds) as I haven't quite migrated to 
pbulk yet ..

thanks for the help offer - I'll ask if I run into trouble.




From dillon at apollo.backplane.com  Mon Mar 24 08:28:49 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Mon, 24 Mar 2008 08:28:49 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <200803241500.m2OF0CG8043760@apollo.backplane.com>


:http://leaf.dragonflybsd.org/~sephe/rtfm.jpg
:
::D

    Ho!

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From elekktretterr at exemail.com.au  Mon Mar 24 09:10:15 2008
From: elekktretterr at exemail.com.au (Petr Janda)
Date: Mon, 24 Mar 2008 09:10:15 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
In-Reply-To: <200803240257.m2O2voNH038355@apollo.backplane.com>
Message-ID: <200803250138.49775.elekktretterr@exemail.com.au>


>
>     And, as you know, fully coherent filesystem access across machines is
>     going to be the basis for DragonFly's clustering across said machines.
>
>     In summary, things are progressing very well.
>


Hi Matt,
That's good to know things are going so well. Got a question. If memory serves 
me right, initially there was also going to be a thing called ANVIL, I can't 
remember what it was supposed to do and whether its still in your design. 
Could you elaborate a little?

Thanks,
Petr




From dillon at apollo.backplane.com  Mon Mar 24 14:12:11 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Mon, 24 Mar 2008 14:12:11 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
In-Reply-To: <200803240257.m2O2voNH038355@apollo.backplane.com>
Message-ID: <200803242100.m2OL0nWV046868@apollo.backplane.com>


:Hi Matt,
:That's good to know things are going so well. Got a question. If memory serves 
:me right, initially there was also going to be a thing called ANVIL, I can't 
:remember what it was supposed to do and whether its still in your design. 
:Could you elaborate a little?
:
:Thanks,
:Petr

    It's not really in the HAMMER design any more, primarily because HAMMER's
    volume model seems to work fine as-is.  Ultimately something like ANVIL
    (a block storage manager) would prove beneficial to the project but it
    would be treated as a separate project.  HAMMER's redundancy model is
    going to be baesd around replication and clustering.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From tgen at netphreax.net  Mon Mar 24 18:31:37 2008
From: tgen at netphreax.net (Thomas E. Spanjaard)
Date: Mon, 24 Mar 2008 18:31:37 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
In-Reply-To: <200803240257.m2O2voNH038355@apollo.backplane.com>
Message-ID: <47E85337.2070407@netphreax.net>

Matthew Dillon wrote:
    * Full historical access appears to be working but needs testing.
      Note that a sync is still needed to flush dirty cached data prior
      to acquiring a timestamp for the 'snapshot' to be set in stone.
      (dirty data cached in-memory has no historical tags and must be
      committed to physical disk before it can be accessed historically).
Wouldn't making timestamp queries (at least from userland) enforce a 
sync on the volume in question be useful here?
--
        Thomas E. Spanjaard
        tgen at netphreax.net
Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00005.pgp
Type: application/octet-stream
Size: 186 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080324/3077333f/attachment-0012.obj>

From dillon at apollo.backplane.com  Mon Mar 24 20:10:12 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Mon, 24 Mar 2008 20:10:12 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
In-Reply-To: <200803240257.m2O2voNH038355@apollo.backplane.com>
Message-ID: <200803250302.m2P32qLP050160@apollo.backplane.com>


:Wouldn't making timestamp queries (at least from userland) enforce a 
:sync on the volume in question be useful here?
:-- 
:         Thomas E. Spanjaard
:         tgen at netphreax.net

    Making the 'hammer now' command do a sync() is a good idea.  I will
    make that change right now so it doesn't get lost.

    Here's a general overview of the issues involved with having historical
    access to the filesystem:

				----------------

    Recording the timestamps in the in-memory cache, for a finer-grained
    snapshot capability, is doable but has its own issues.  Here's an
    illustration:

    open()  create file
    write() append 4K	(file size now 4K)
    write() append 4K	(file size now 8K)
    write() append 4K	(file size now 12K)
    write() append 4K	(file size now 16K)

    Now NONE of this has gone to disk yet, it's entirely in the in-memory
    cache.  The inode is in the in-memory cache.  The data is stored in
    the buffer cache.  Even the directory entry for the file that we
    just created is still in the in-memory cache (HAMMER caches the raw
    records it intends to commit later on).

    If I wanted to be able to acquire a timestamp between each write and
    'see' a snapshot of the file as of any point in the above sequence,
    then every write would also have to allocate a copy of the inode
    (because it changes size on each write).

    The data has the same problem though with a slightly different example.
    Lets say each write() was a seek-write, overwriting the previous data.
    Now with every write() I would have to allocate a copy of the data
    being overwritten.  This is complicated by the fact that the buffer
    cache has no clue about 'historical' accesses, so I would not be able
    to use the buffer cache to cache the data.

    There's also another problem and that is with the efficiency of the
    topology on-disk.  Even if I maintained all the copies of the inode
    and all the copies of the data in-memory, I would still have to sync
    all those copies to disk in order for things to remain historically
    coherent (whether it be in-cache or on-disk).  This would result in
    hundreds or even thousands of copies of the inode on-disk, not to
    mention potentially many copies of the data.

    I just don't want to do that right now, at least not as a default.  A
    lot of performance would be lost.  Hence a sync() is needed if
    you want to create a demark which you can accurately snapshot.

				-------------

    Here's a quick synopsis of how the cache would operate in a clustered
    filesystem:

    In order to properly integrate with in-memory caches, a wider cache
    coherency infrastructure is needed between machines such that
    modifications made on one machine proactively invalidate those
    protions of the cache(s) on other machines.  At the same time, any
    'dirty' cache data, for example when a file is created or written to,
    must lock the cache space in question on all other machines.
    The cache space in this case is not just the file data, but also the
    related namespaces (for creations, deletions, and renames).  Attempts
    to access locked spaces from other machines in the cluster would have
    to force a flush to the filesystem backing store and lower the cache
    states for the effected information on the original machine from dirty
    to shared-read-only.

    It will be easiest to integrate the cache coherency information into
    the buffer cache and namecache themselves.  Once a machine has dirtied
    an in-memory cache element... for example part of the namespace when
    creating a file or chunks of data written within a file, that machine
    must have a free hand to make further modifications to the cache spaces
    involved without further interaction with other machines.

				-------------

    Now, if you think of those two major elements you can see that they
    actually fit together quite well.  If I were to attempt to maintain
    transactional coherency on a per-system-call basis then the cache
    granularity between machines would have to be much, much smaller then
    our current in-memory caching elements provide.  That would become
    a really nasty coding problem.  So I don't even want to begin to
    complate transactional coherency at a finer-grain then sync() or
    fsync() until long after we actually have clustering working.

						-Matt





From elekktretterr at exemail.com.au  Mon Mar 24 21:56:58 2008
From: elekktretterr at exemail.com.au (Petr Janda)
Date: Mon, 24 Mar 2008 21:56:58 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
In-Reply-To: <200803240257.m2O2voNH038355@apollo.backplane.com>
Message-ID: <200803251516.16407.elekktretterr@exemail.com.au>

So is it needed to run hammer now in order to "create" a snapshot? What would 
I do in situation like this: got a hammer filesystem and couple of the files 
change on day to day basis. Then a week later I needed to access one of the 
files, in exactly the state they were 7 days ago.

Cheers,
Petr




From dillon at apollo.backplane.com  Mon Mar 24 22:34:15 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Mon, 24 Mar 2008 22:34:15 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
In-Reply-To: <200803240257.m2O2voNH038355@apollo.backplane.com>
Message-ID: <200803250526.m2P5QZ5X051081@apollo.backplane.com>


:So is it needed to run hammer now in order to "create" a snapshot? What would 
:I do in situation like this: got a hammer filesystem and couple of the files 
:change on day to day basis. Then a week later I needed to access one of the 
:files, in exactly the state they were 7 days ago.
:
:Cheers,
:Petr

    No, you do not have to run 'hammer now' to create a snapshot.  The
    kernel syncs all filesystems every 30 seconds, so if you do nothing
    at all you get a snapshot granularity of 30 seconds.

    Where you would use 'hammer now' is if you wanted the most current
    snapshot possible for the purpose of, say, backing up your filesystem
    to another machine.  You might do something like this:

	set timestamp = `hammer now`
	cpdup /mountpoint/@@$timestamp targethost:/somepath

    But if you didn't care about that you could just go back far enough
    that you get a stable historical view... e.g. go back 1 minute and you
    would have a stable view into your filesystem.

	set timestamp = `hammer stamp 60s`		<------ doesn't sync
	cpdup /mountpoint/@@$timestamp targethost:/somepath


    Ultimately the idea of managing filesystems this way is to still do
    regular backups from your production machine to your backup machine
    (ultimately by way of replication), with both running HAMMER, but only
    retain a limited amount of history on the production box.  You might
    desire to retain only one week's worth of history on the production box,
    retain one month's history on your local backup box, and retain a very
    granular one year's worth of history on your remote backup box.

    Come to think of it, I should add some more directives to the
    'hammer prune' command to make that easier to specify.

    Until I implement a live replication 'feed' the minimum granularity on
    the backup box will be how often you do your backups (e.g. once a day),
    and you can prune it into more granular forms from that starting point.
    Once we have a live replication feed the backup box will have the same
    30-second granularity that the production machine has.

    A major bullet point for this style of management is that the retention
    policy on the various boxes can be different even though they are
    all slaved off the same production filesystem.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From justin at shiningsilence.com  Tue Mar 25 05:58:49 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Tue, 25 Mar 2008 05:58:49 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: SoC - student signups
Message-ID: <58180.65.106.147.226.1206449676.squirrel@www.shiningsilence.com>

Here's a quick link roundup:

Are you a student?  Put in your application for a Google Summer of Code here:

http://code.google.com/soc/2008/student_signup.html

Student guide:
http://groups.google.com/group/google-summer-of-code-announce/web/guide-to-the-gsoc-web-app-for-student-applicants

Are you a mentor?  (That means hasso, hsu, sephe, matthias, TGEN, and
corecode right now)

Student proposals will show up on the mentor page, linked below.  You will
get to rate them, and take the one(s) that you want to mentor.

Mentor page:
http://code.google.com/soc/2008/mentor_home.html
Mentor guide:
http://groups.google.com/group/google-summer-of-code-announce/web/guide-to-the-gsoc-web-app-for-mentors-and-organization-administrators

If you are a mentor and are communicating with potential students, send
them the URLs above for student signup and the student guide; work with
them if they ask for advice on what to say in the application.  They can
resubmit up to 20 times if they want to correct it.

Deadline is March 31st.






From noah.yan at gmail.com  Thu Mar 27 20:17:48 2008
From: noah.yan at gmail.com (Yonghong Yan)
Date: Thu, 27 Mar 2008 20:17:48 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: About DFBSD.64
In-Reply-To: <47EB0B5B.5020802@gmail.com>
Message-ID: <59521b110803272015y1cc8cc39uc93f154ed36e0505@mail.gmail.com>

thanks for your interest.

I owe to everybody for any update or work in the past four months. so
many things happen in my work and my family (they are all good:) and
keep me extremely busy. But i am not leaving and will be back on this
soon.

the latest sources are in http://repo.or.cz/w/dragonfly/port-amd64.git
, I did have a compiled kernel long time before, but I have to break
it to work on the pmap. you can pick up from there. TGEN will help you
a lot, also keep me posted too, if you like.

Noah

On Wed, Mar 26, 2008 at 9:50 PM, Sdavtaker <sdavtaker at gmail.com> wrote:
> Hello,
>  Im applying to GSoC to work in the x64 version of DFBSD with TGEN, i
>  found some work already done in the repository and some mails in the
>  archive from you.
>  I was wondering if you already had a working compiled kernel in AMD64
>  machine and what was not working yet to continue that work.
>  Thanks for any info.
>  Sdav
>




From dillon at apollo.backplane.com  Sat Mar 29 13:27:43 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Sat, 29 Mar 2008 13:27:43 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 29-Mar-2008
Message-ID: <200803292022.m2TKMLGe004942@apollo.backplane.com>

    Good progress continues to be made.  HAMMER survived acting as my
    LAN backup machine (in full historical mode) for almost a week before
    it hit an assertion.  I've fixed that issue and believe that the core
    filesystem implementation code is now 'very stable'.

    Note that the recent commit will result in many more 'hammer_lock_ex:'
    messages on the console then you may have previously observed.  This is
    due to the way object id's are allocated in the face of parallel 
    modifications to the filesystem, resulting in too much locality of
    reference in the B-Tree.  I do intend to improve it.

    I am still working on the two major items needed before HAMMER can be
    declared operational, those being the filesystem full handling and the
    undo/recovery-on-mount code.  These are the last 'hard' bits left in
    the design.

    With exception to filling up the filesystem, which *will* create a mess,
    and noting that no crash recovery code exists yet (so you have to newfs
    it if you crash), I'd appreciate it if interested parties could test
    the other functions of the filesystem, in particular the pruning and
    reblocking functions (man hammer), and the historical access functions.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From dillon at apollo.backplane.com  Sun Mar 30 15:11:03 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Sun, 30 Mar 2008 15:11:03 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Need ideas on how to solve an st_ino/st_dev test issue for HAMMER.
Message-ID: <200803302207.m2UM7BCp016402@apollo.backplane.com>

    Here's the problem, given historical access softlinks as shown below:

test30# ls -lda cra*
drwxr-xr-x  1 root  wheel  Mar 29 13:04 crater
lrwxr-xr-x  1 root  wheel  Mar 29 18:57 crater.20080329 -> crater@@0x47eef383
lrwxr-xr-x  1 root  wheel  Mar 30 01:24 crater.20080330 -> crater@@0x47ef4e29
-rw-r--r--  2 root  wheel  Mar 30 01:24 crater.log

    The problem is that if I do this:

    diff -r crater.20080329/var/log crater.20080330/var/log

    Diff just returns without actually diffing anything.  The reason is
    because diff checks st_ino and st_dev and believes the directories/files
    to be identical because they match.

    I considered munging the inode number for historical accesses, but
    that would seriously break NFS exports which try to access historical
    files and directories.  Right now NFS *is* able to distinguish between
    the two because NFS handles are 128-bit-wide entities, so I can encode
    the as-of transaction id as part of the filehandle.  But userland
    programs only have access to a 64-bit-wide inode so userland still
    believes the files to be identical.

    st_dev is only 32 bits, carefully munging it is an option if we
    could figure out a way to do it, but I'd rather not.

    I am considering using st_gen but then we'd have to patch third
    party software to test st_gen along with everything else.  This may
    be the only workable solution, though, and only a few programs would
    need to be patched.  st_gen is only 32 bits but it would solve the
    problem as we would be able to use all 32 bits.

    If anyone has any bright ideas, including 'leave it alone', I'm all
    ears.

						-Matt





From justin at shiningsilence.com  Mon Mar 31 10:40:42 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Mon, 31 Mar 2008 10:40:42 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: SoC student applications due by 5PM PDT tomorrow
In-Reply-To: <1942.192.168.0.242.1206930479.squirrel@www.shiningsilence.com>
Message-ID: <11892.67.108.184.175.1206984967.squirrel@www.shiningsilence.com>

On Sun, March 30, 2008 10:27 pm, Justin C. Sherrill wrote:
> SoC students:
>
> If you have an application to submit for DragonFly/Summer of Code, please
> do so by 17:00 Pacific time on the 31st - that's tomorrow, at least for
> me.

The deadline for student proposals has been extended to April 7th; all
other dates move forward one week to acommodate.

This is a good time to update existing applications or submit new ones. 
Talk to your (potential) mentors if you are curious.






From nthery at gmail.com  Mon Mar 31 11:29:49 2008
From: nthery at gmail.com (Nicolas Thery)
Date: Mon, 31 Mar 2008 11:29:49 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
Message-ID: <64fc43b0803311126na7d0b27obaa9d35bac6d32ee@mail.gmail.com>

Hello,

Now that the release is over, I'll try to get rid of zones and migrate
allocations to objcache.

Here is a 1st patch that migrate struct proc.  I'll commit it in a
couple of days if nobody objects.

I'm also implementing a way to monitor objcache statistics.  So far,
I've hacked sth similar to
sysctl vm.zone: stats are returned in one giant string, one line per
cache.  That's simple but ugly and hard to read because there are
quite a few stats per cache.

So I'm thinking about implementing a small tool, ocstat, that extracts
stats from sysctl the way ps(1) does (thru libkvm iirc) and formats it
in various ways.  What do you think?

Cheers,
Nicolas

Index: src2/sys/kern/kern_exit.c
===================================================================
--- src2.orig/sys/kern/kern_exit.c	2008-03-31 08:05:59.139796000 +0200
+++ src2/sys/kern/kern_exit.c	2008-03-31 10:31:39.000000000 +0200
@@ -834,7 +834,7 @@ loop:
 			}

 			vm_waitproc(p);
-			zfree(proc_zone, p);
+			objcache_put(proc_cache, p);
 			nprocs--;
 			return (0);
 		}
Index: src2/sys/kern/kern_proc.c
===================================================================
--- src2.orig/sys/kern/kern_proc.c	2008-03-31 08:05:59.139918000 +0200
+++ src2/sys/kern/kern_proc.c	2008-03-31 10:31:39.000000000 +0200
@@ -84,7 +84,7 @@ u_long pgrphash;
 struct proclist allproc;
 struct proclist zombproc;
 struct spinlock allproc_spin;
-vm_zone_t proc_zone;
+struct objcache* proc_cache;
 vm_zone_t lwp_zone;
 vm_zone_t thread_zone;

@@ -131,7 +131,7 @@ procinit(void)
 	spin_init(&allproc_spin);
 	pidhashtbl = hashinit(maxproc / 4, M_PROC, &pidhash);
 	pgrphashtbl = hashinit(maxproc / 4, M_PROC, &pgrphash);
-	proc_zone = zinit("PROC", sizeof (struct proc), 0, 0, 5);
+	proc_cache = objcache_create_simple(M_PROC, sizeof(struct proc));
 	lwp_zone = zinit("LWP", sizeof (struct lwp), 0, 0, 5);
 	thread_zone = zinit("THREAD", sizeof (struct thread), 0, 0, 5);
 	uihashinit();
Index: src2/sys/sys/proc.h
===================================================================
--- src2.orig/sys/sys/proc.h	2008-03-31 08:05:59.140325000 +0200
+++ src2/sys/sys/proc.h	2008-03-31 10:31:39.000000000 +0200
@@ -473,7 +473,7 @@ struct proc *zpfind (pid_t);	/* Find zom
 struct vm_zone;
 struct globaldata;
 struct lwp_params;
-extern struct vm_zone *proc_zone;
+extern struct objcache *proc_cache;
 extern struct vm_zone *lwp_zone;

 int	enterpgrp (struct proc *p, pid_t pgid, int mksess);
Index: src2/sys/kern/kern_fork.c
===================================================================
--- src2.orig/sys/kern/kern_fork.c	2008-03-31 08:05:59.140042000 +0200
+++ src2/sys/kern/kern_fork.c	2008-03-31 10:31:39.000000000 +0200
@@ -332,7 +332,7 @@ fork1(struct lwp *lp1, int flags, struct
 	}

 	/* Allocate new proc. */
-	p2 = zalloc(proc_zone);
+	p2 = objcache_get(proc_cache, M_WAITOK);
 	bzero(p2, sizeof(*p2));

 	/*




From hsu at dragonflybsd.org  Mon Mar 31 11:44:34 2008
From: hsu at dragonflybsd.org (Jeffrey Hsu)
Date: Mon, 31 Mar 2008 11:44:34 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <64fc43b0803311126na7d0b27obaa9d35bac6d32ee@mail.gmail.com>
Message-ID: <200803311841.m2VIfQAI007579@nlpi001.prodigy.net>

The object cache is not a general-purpose memory allocator.  It's a cache of
pre-initialized objects.  Are the significant portions of the proc structure
that can be restored to initialized state on object puts?  If not, it's best
to just use a general-purpose memory allocator.

								Jeffrey




From corecode at fs.ei.tum.de  Mon Mar 31 12:07:02 2008
From: corecode at fs.ei.tum.de (Simon 'corecode' Schubert)
Date: Mon, 31 Mar 2008 12:07:02 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <200803311841.m2VIfQAI007579@nlpi001.prodigy.net>
Message-ID: <47F1357B.1070302@fs.ei.tum.de>

Jeffrey Hsu wrote:
> The object cache is not a general-purpose memory allocator.  It's a cache of
> pre-initialized objects.  Are the significant portions of the proc structure
> that can be restored to initialized state on object puts?  If not, it's best
> to just use a general-purpose memory allocator.

Why?  What's the loss if we use the object cache to allocate struct procs?

cheers
  simon

Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00006.pgp
Type: application/octet-stream
Size: 252 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080331/a4a24314/attachment-0012.obj>

From nthery at gmail.com  Mon Mar 31 12:17:03 2008
From: nthery at gmail.com (Nicolas Thery)
Date: Mon, 31 Mar 2008 12:17:03 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <nthery@gmail.com>
Message-ID: <64fc43b0803311214u7da6bbb8xaf971de1a80e7258@mail.gmail.com>

2008/3/31, Jeffrey Hsu <hsu at dragonflybsd.org>:
> The object cache is not a general-purpose memory allocator.  It's a cache of
>  pre-initialized objects.  Are the significant portions of the proc structure
>  that can be restored to initialized state on object puts?  If not, it's best
>  to just use a general-purpose memory allocator.

Well, I haven't checked this yet.  I planned to do this in a second
step after getting rid of zones.

I thought that even without  the pre-initialization part, objcache has
the advantage
of pre-allocating set of objects (as zones) and is additionally
mp-safe (contrary to zones and, granted, as malloc()).   The latter
may be interesting as we talk of improving MP support.

Cheers,
Nicolas




From dillon at apollo.backplane.com  Mon Mar 31 12:23:40 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Mon, 31 Mar 2008 12:23:40 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <200803311841.m2VIfQAI007579@nlpi001.prodigy.net>
Message-ID: <200803311921.m2VJLITB027669@apollo.backplane.com>

    I both agree and disagree with Jeff.  I think the only *disadvantage*
    to using objcache for struct proc is that objcache must cache a minimum
    number of free structures to be efficient so the overall kernel memory
    use would be a bit greater verses uses kmalloc().  But I agree with Jeff
    in that objcache's biggest advantage is that you can keep structural state
    intact and struct proc might not be a good candidate (yet).

    What I suggest is that you convert struct proc from zone to kmalloc
    first, and then look into a possible objcache adaptation.  kmalloc
    is not slow.. it's a very fast allocator.  Objcache is probably a tad
    faster but not by much.  Where objcache really wins is in not having
    to completey reinitialize the allocated structures.

    Over the years I've removed (I think) all the dependancies on requiring
    the proc structure to be in stable memory so I believe it can be moved to
    kmalloc/objcache now without any major pain.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From corecode at fs.ei.tum.de  Mon Mar 31 12:37:40 2008
From: corecode at fs.ei.tum.de (Simon 'corecode' Schubert)
Date: Mon, 31 Mar 2008 12:37:40 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: SoC student applications due by 5PM PDT tomorrow
In-Reply-To: <1942.192.168.0.242.1206930479.squirrel@www.shiningsilence.com>
Message-ID: <47F13CDA.6010703@fs.ei.tum.de>

Justin C. Sherrill wrote:
> On Sun, March 30, 2008 10:27 pm, Justin C. Sherrill wrote:
>> SoC students:
>>
>> If you have an application to submit for DragonFly/Summer of Code, please
>> do so by 17:00 Pacific time on the 31st - that's tomorrow, at least for
>> me.
> The deadline for student proposals has been extended to April 7th; all
> other dates move forward one week to acommodate.

This is very good.

Some more ideas for eager students (we want to keep the ratio, right?):

Enhance the FreeBSD/DragonFly sound infrastructure to support surround
sound/multichannel output.

Update sound drivers to support S/PDIF output.

Make the sound infrastructure OSSv4 compatible (there was a SoC at
FreeBSD last year or so)


of course only if it doesn't exist already :)

cheers
  simon


Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00007.pgp
Type: application/octet-stream
Size: 252 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080331/6da61cff/attachment-0012.obj>

From corecode at fs.ei.tum.de  Mon Mar 31 12:41:30 2008
From: corecode at fs.ei.tum.de (Simon 'corecode' Schubert)
Date: Mon, 31 Mar 2008 12:41:30 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <200803311841.m2VIfQAI007579@nlpi001.prodigy.net>
Message-ID: <47F13DE4.10205@fs.ei.tum.de>

Matthew Dillon wrote:
>     What I suggest is that you convert struct proc from zone to kmalloc
>     first, and then look into a possible objcache adaptation.  kmalloc
>     is not slow.. it's a very fast allocator.  Objcache is probably a tad
>     faster but not by much.  Where objcache really wins is in not having
>     to completey reinitialize the allocated structures.

Could we please not move to kmalloc, but instead try to move all fast
path allocations to objcache?  I don't like the idea of allocating
everything with kmalloc.  Caching struct procs is not a bad thing itself.

cheers
  simon


Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00008.pgp
Type: application/octet-stream
Size: 252 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080331/ac328c08/attachment-0012.obj>

From hsu at FreeBSD.org  Mon Mar 31 12:59:05 2008
From: hsu at FreeBSD.org (Jeffrey Hsu)
Date: Mon, 31 Mar 2008 12:59:05 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <47F1357B.1070302@fs.ei.tum.de>
Message-ID: <200803311920.m2VJK5Ln018015@nlpi015.prodigy.net>

The object cache sits on top of a general-purpose memory allocator such
as kmalloc or zalloc and provides pre-initialized object caching functionality.
If you're not going to use the object caching functionality, you can just
call the underlying memory allocator directly.

							Jeffrey




From dillon at apollo.backplane.com  Mon Mar 31 16:17:19 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Mon, 31 Mar 2008 16:17:19 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <200803311841.m2VIfQAI007579@nlpi001.prodigy.net>
Message-ID: <200803312311.m2VNBumd029866@apollo.backplane.com>

:Could we please not move to kmalloc, but instead try to move all fast
:path allocations to objcache?  I don't like the idea of allocating
:everything with kmalloc.  Caching struct procs is not a bad thing itself.=
:
:
:cheers
:  simon

    I will state for the record that I'm fine with either objcache or
    kmalloc.  I agree with Jeff that using objcache for struct proc
    probably isn't necessary but I also agree that it would not hurt either,
    and if the intent is to optimize the initialization of the proc
    structure in the future then moving to objcache now would save us
    from having to do it later.

    So whichever method Nicolas wants to use is fine with me.

						-Matt




From hsu at dragonflybsd.org  Mon Mar 31 19:22:47 2008
From: hsu at dragonflybsd.org (Jeffrey Hsu)
Date: Mon, 31 Mar 2008 19:22:47 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <64fc43b0803311214u7da6bbb8xaf971de1a80e7258@mail.gmail.com>
Message-ID: <200804010218.m312IVUq003624@nlpi043.prodigy.net>

  >> Are there significant portions of the proc structure
  >> that can be restored to initialized state on object puts?

  > I planned to do this in a second step after getting rid of zones.

I'll all in favor of making more use of caching pre-initialized objects, so
if this is your objective, then please go ahead.  It's just that I'd convert
over to the object cache in one step.

  > I thought that even without  the pre-initialization part, objcache has
  > the advantage of pre-allocating set of objects (as zones) and is additionally
  > mp-safe (contrary to zones and, granted, as malloc()).

Well, the zone allocator is MP-safe.  It's not hard to lock up the places that
manipulate the linked-list of free items. Look for uses of the zlock field.

								Jeffrey




From tgen at netphreax.net  Sat Mar  1 12:57:53 2008
From: tgen at netphreax.net (Thomas E. Spanjaard)
Date: Sat, 1 Mar 2008 12:57:53 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: [Fwd: Project Support Open Source: $50 donation to support you      project]
In-Reply-To: <2468.192.168.0.242.1204346451.squirrel@www.shiningsilence.com>
Message-ID: <47C9C1B7.50203@netphreax.net>

Justin C. Sherrill wrote:
The "donation" happens after you place an "acknowledgement" on an open
source project's web page.  I'm putting those words in scare quotes
because I think it's a "payment" for an "advertisement".  The supplied
link has nothing to do with DragonFly, to say the least.

<a href="http://www.2insure4less.com /" title="We support FOSS software
projects.">Online Insurance Quotes</a>
To think our souls are only worth $50...
--
        Thomas E. Spanjaard
        tgen at netphreax.net
Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00000.pgp
Type: application/octet-stream
Size: 186 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080301/0d61e240/attachment-0013.obj>

From c.turner at 199technologies.org  Sat Mar  1 17:52:31 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Sat, 1 Mar 2008 17:52:31 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Misc. ACPI / suspend
Message-ID: <47CA073B.6020106@199technologies.org>

Wondering if anyone more well versed in the ACPI implementation could
comment on the applicability of:
http://lkml.org/lkml/2007/4/6/69

w/r/t the current state of the art in Dfly

(or BSD's in general)

Cheers!

- Chris




From elekktretterr at exemail.com.au  Sun Mar  2 00:41:25 2008
From: elekktretterr at exemail.com.au (Petr Janda)
Date: Sun, 2 Mar 2008 00:41:25 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: CARP question
Message-ID: <200803021934.21669.elekktretterr@exemail.com.au>

So Ive setup CARP on 2 DF-based mailservers. Installation went fine. Box 1 has 
adskew of 0 therefore it is the MASTER. Box 2 has adskew of 254, therefore is 
BACKUP.  If i down the carp0 interface on Box 1, then Box 2 carp interface 
gets promoted to MASTER. Then I up the carp interface on Box 1, logically Box 
2 should become BACKUP again as Box 1 becomes MASTER due to adskew set to 0.

However it doesnt happen. When carp0 interface on Box 1 is upped it becomes a 
BACKUP, not a MASTER even though according to adskew it should be MASTER.

What is the desired behaviour?

Cheers
Petr




From qhwt+dfly at les.ath.cx  Sun Mar  2 02:50:14 2008
From: qhwt+dfly at les.ath.cx (YONETANI Tomokazu)
Date: Sun, 2 Mar 2008 02:50:14 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: panic: assertion: hammer_btree_cmp(cursor->left_bound,	&cursor->node->ondisk->elms[0].leaf.base) <= 0 in btree_split_leaf
In-Reply-To: <200802232204.m1NM4cxd046264@apollo.backplane.com>
Message-ID: <20080302104554.GA22813@les.ath.cx>

Hi.
While trying to find a procedure to reliably reproduce the panic
I reported last time, I caught a different panic (uploaded at
 ~y0netan1/crash/9/ on my leaf account).  I wrote the following shell
script (make sure to edit variables DISKS and MOUNTPT before using this
script or it may trash your system):
  #!/bin/sh -ex
  DISKS="/dev/ad0s1f"
  MOUNTPT=/mnt/HAMMER

  cd /
  newfs_hammer -L TEST $DISKS
  for i in `seq 1 100`; do
	  mount_hammer $DISKS $MOUNTPT
	  /bin/rm -rf $MOUNTPT/??
	  (set +x; for x in `seq 1 10000`; do echo -n > $MOUNTPT/$x; done)
	  umount $MOUNTPT
  done

And the panic is triggered by rm command.
I'll try to see if it's possible to reproduce the last one without
unmounting then mounting the HAMMER fs.

Cheers.




From dillon at apollo.backplane.com  Sun Mar  2 13:25:33 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Sun, 2 Mar 2008 13:25:33 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: panic: assertion: hammer_btree_cmp(cursor->left_bound,	&cursor->node->ondisk->elms[0].leaf.base) <= 0 in btree_split_leaf
In-Reply-To: <200802232204.m1NM4cxd046264@apollo.backplane.com>
Message-ID: <200803022119.m22LJRCY037076@apollo.backplane.com>


:Hi.
:While trying to find a procedure to reliably reproduce the panic
:I reported last time, I caught a different panic (uploaded at
: ~y0netan1/crash/9/ on my leaf account).  I wrote the following shell
:script (make sure to edit variables DISKS and MOUNTPT before using this
:script or it may trash your system):

(from the core)

panic: assertion: node->lock.refs == 0 && node->ondisk == NULL in hammer_flush_buffer_nodes

    Yah, I've seen this failure.  Add a sync or two before the umount and
    tell me if it still occurs.  It's either a node reference leak somewhere
    or it is a race between bufdaemon and umount.  The assertions are really
    strict there precisely to catch those sorts of cases.

    Also note that the code to deal with a full HAMMMER filesystem has not
    been written yet (The failure you are reporting is unrelated to a full
    HAMMER filesystem, though, just mentioning it).

						-Matt





From dillon at apollo.backplane.com  Sun Mar  2 13:29:03 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Sun, 2 Mar 2008 13:29:03 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Misc. ACPI / suspend
In-Reply-To: <47CA073B.6020106@199technologies.org>
Message-ID: <200803022126.m22LQbfI037188@apollo.backplane.com>


:Wondering if anyone more well versed in the ACPI implementation could
:comment on the applicability of:
:
:http://lkml.org/lkml/2007/4/6/69
:
:w/r/t the current state of the art in Dfly
:
:(or BSD's in general)
:
:Cheers!
:
:- Chris

    I really have no idea re: this.  Suspension in general is not well
    supported by any of the BSDs.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From dillon at apollo.backplane.com  Sun Mar  2 13:34:05 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Sun, 2 Mar 2008 13:34:05 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: [Fwd: Project Support Open Source: $50 donation to support you      project]
In-Reply-To: <2468.192.168.0.242.1204346451.squirrel@www.shiningsilence.com>
Message-ID: <200803022131.m22LVOe9037250@apollo.backplane.com>

:..
:source project's web page.  I'm putting those words in scare quotes
:because I think it's a "payment" for an "advertisement".  The supplied
:link has nothing to do with DragonFly, to say the least.
:
:I don't think this is a good idea, obviously, and replied to that effect. 
:However, I wanted to put this on a DragonFly list, in part to show this
:strange thing, and in part because I'm not comfortable making
:administrative decisions on behalf of the Project without being open as
:possible about it.

    It doesn't really cry out to me either.

						-Matt





From wbh at conducive.org  Sun Mar  2 20:36:32 2008
From: wbh at conducive.org (Bill Hacker)
Date: Mon, 03 Mar 2008 04:36:32 +0000
Subject: Misc. ACPI / suspend
In-Reply-To: <47CA073B.6020106@199technologies.org>
Message-ID: <47cb8050$0$855$415eb37d@crater_reader.dragonflybsd.org>

Matthew Dillon wrote:
:Wondering if anyone more well versed in the ACPI implementation could
:comment on the applicability of:
:
:http://lkml.org/lkml/2007/4/6/69
:
:w/r/t the current state of the art in Dfly
:
:(or BSD's in general)
:
:Cheers!
:
:- Chris
    I really have no idea re: this.  Suspension in general is not well
    supported by any of the BSDs.
					-Matt
					Matthew Dillon 
					<dillon at backplane.com>


. . and there seems to be a bit of a 'Catch 22' there in any case.

If the BIOS can alter 'stuff' out of site of the OS it is parking, what 
does the existence of such a 'feature' do to a(ny) security model?

Seems to at least beg creating the option of setting a flag to 
specifically *prevent* suspend-to-disk/hibernation (and/or force a 
reboot on wake-up).

Just because one is paranoid....  etc

Bill





From matthias at dragonflybsd.org  Tue Mar  4 02:30:52 2008
From: matthias at dragonflybsd.org (Matthias Schmidt)
Date: Tue, 4 Mar 2008 02:30:52 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
Message-ID: <20080304102335.GI9833@staatsfeind.org>

Hi,

Google just announced its Summer of Code for 2008:

	http://code.google.com/soc/2008/

I think this would be a great opportunity for DragonFly to participate
as a mentoring organisation.  We could attract new developers and could
get code/work done.  Looking at the SoC results of the other BSDs most
of their projects were a success.  Of course, not all, but a reasonable
percentage.  See [1] and [2].

It is some extra work for us, but IMO the benefits outweigh the extra
work.  And yes, I would volunteer as a mentor.  What do others
(developers) think?  Any more volunteers? :)

Some project ideas that come into my mind.  More ideas are listed in the
wiki:  http://wiki.dragonflybsd.org/index.cgi/ProjectsPage

 * Fix all remaining bugs in dma(8) and implement all missing features
 * Add a driver for newer Intel Wireless cards (I think sephe@ would
   love that :)
 * Bring our ACPI stuff in shape.  Maybe suspend2disk ...

 * [Add your own thoughts here]

Cheers,

	Matthias

PS: I don't want to create a bikeshed here whether you like the SoC or
not :)

[1] http://code.google.com/soc/2007/freebsd/about.html
[2] http://code.google.com/soc/2007/netbsd/about.html




From corecode at fs.ei.tum.de  Tue Mar  4 04:46:14 2008
From: corecode at fs.ei.tum.de (Simon 'corecode' Schubert)
Date: Tue, 4 Mar 2008 04:46:14 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47CD4386.1000704@fs.ei.tum.de>

Matthias Schmidt wrote:
>  * [Add your own thoughts here]

MP lock removal for network stack

and for the system  (first profile, find hot spots, fix hot spots, repeat)

cheers
  simon




From c.turner at 199technologies.org  Tue Mar  4 06:02:20 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Tue, 4 Mar 2008 06:02:20 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47CD551E.1040604@199technologies.org>

Matthias Schmidt wrote:
Some project ideas that come into my mind.  More ideas are listed in the
wiki:  http://wiki.dragonflybsd.org/index.cgi/ProjectsPage
+1 acpi
+1 interrupt routing
+1 SMP / giant removal
+1 pf synchup with openbsd
though there are several others on the page that are good..

need to dig up my wiki login and place appropriately..

also: thinking the ZFS port should be removed from the page - makes 
sense to everyone else? (e.g. fragments effort w/r/t hammer)





From tgen at netphreax.net  Tue Mar  4 06:54:31 2008
From: tgen at netphreax.net (Thomas E. Spanjaard)
Date: Tue, 4 Mar 2008 06:54:31 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47CD615F.8010209@netphreax.net>

Matthias Schmidt wrote:
Google just announced its Summer of Code for 2008:

 * [Add your own thoughts here]
x86-64 port :).
--
        Thomas E. Spanjaard
        tgen at netphreax.net
Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00001.pgp
Type: application/octet-stream
Size: 186 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080304/0d921000/attachment-0013.obj>

From rdivacky at FreeBSD.org  Tue Mar  4 07:07:03 2008
From: rdivacky at FreeBSD.org (Roman Divacky)
Date: Tue, 4 Mar 2008 07:07:03 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <20080304150255.GA8831@freebsd.org>

On Tue, Mar 04, 2008 at 02:49:03PM +0000, Thomas E. Spanjaard wrote:
> Matthias Schmidt wrote:
> >Google just announced its Summer of Code for 2008:
> >
> > * [Add your own thoughts here]
> 
> x86-64 port :).

all those ideas are great and needed etc. but keep in
mind that the projects should be doable by students
who might see dfly for the very first time.

don't overestimate whats possible and select projects
that look realistic

Roman Divacky (former SoC student)




From justin at shiningsilence.com  Tue Mar  4 08:32:56 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Tue, 4 Mar 2008 08:32:56 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <60322.65.106.147.226.1204648095.squirrel@www.shiningsilence.com>

On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
> Hi,
>
> Google just announced its Summer of Code for 2008:
>
> 	http://code.google.com/soc/2008/
>
> I think this would be a great opportunity for DragonFly to participate
> as a mentoring organisation.  We could attract new developers and could
> get code/work done.  Looking at the SoC results of the other BSDs most
> of their projects were a success.  Of course, not all, but a reasonable
> percentage.  See [1] and [2].

We've applied in previous years - Jeff Hsu did one year, and I put
together the application last year.  The hardest thing to find was
students (and they are the thing that helps SoC applications a lot, I
think).

Any student volunteers?  We have mentors.





From rluciani at gmail.com  Tue Mar  4 09:38:29 2008
From: rluciani at gmail.com (Robert Luciani)
Date: Tue, 04 Mar 2008 18:38:29 +0100
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47cd8915$0$854$415eb37d@crater_reader.dragonflybsd.org>

Justin C. Sherrill wrote:
> On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
>> Hi,
>>
>> Google just announced its Summer of Code for 2008:
>>
>> 	http://code.google.com/soc/2008/
>>
>> I think this would be a great opportunity for DragonFly to participate
>> as a mentoring organisation.  We could attract new developers and could
>> get code/work done.  Looking at the SoC results of the other BSDs most
>> of their projects were a success.  Of course, not all, but a reasonable
>> percentage.  See [1] and [2].
> 
> We've applied in previous years - Jeff Hsu did one year, and I put
> together the application last year.  The hardest thing to find was
> students (and they are the thing that helps SoC applications a lot, I
> think).
> 
> Any student volunteers?  We have mentors.
> 

bingo

-- 
Robert Luciani
Chalmers University of Technology, SWE
Department of Computer Science and Engineering
http://www.rluciani.com/public.key




From sdavtaker at gmail.com  Tue Mar  4 09:31:08 2008
From: sdavtaker at gmail.com (=?UTF-8?Q?Sd=C3=A4vtaker?=)
Date: Tue, 4 Mar 2008 09:31:08 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <c37d69f60803040926k206218a3kb8496d0cd18148bd@mail.gmail.com>

If you mentor, i will apply for coder :-)
Still in last year of university. :-)
Sdav

On Tue, Mar 4, 2008 at 1:28 PM, Justin C. Sherrill
<justin at shiningsilence.com> wrote:
> On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
>  > Hi,
>  >
>  > Google just announced its Summer of Code for 2008:
>  >
>  >       http://code.google.com/soc/2008/
>  >
>  > I think this would be a great opportunity for DragonFly to participate
>  > as a mentoring organisation.  We could attract new developers and could
>  > get code/work done.  Looking at the SoC results of the other BSDs most
>  > of their projects were a success.  Of course, not all, but a reasonable
>  > percentage.  See [1] and [2].
>
>  We've applied in previous years - Jeff Hsu did one year, and I put
>  together the application last year.  The hardest thing to find was
>  students (and they are the thing that helps SoC applications a lot, I
>  think).
>
>  Any student volunteers?  We have mentors.
>
>



-- 
Sd?vtaker prays to Rikku goddess for a good treasure.



From rluciani at gmail.com  Tue Mar  4 09:44:02 2008
From: rluciani at gmail.com (Robert Luciani)
Date: Tue, 04 Mar 2008 18:44:02 +0100
Subject: google soc "DragonFly"
Message-ID: <47cd8a63$0$855$415eb37d@crater_reader.dragonflybsd.org>

On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
> > Hi,
> >
> > Google just announced its Summer of Code for 2008:
> >
> > 	http://code.google.com/soc/2008/
> >
> > I think this would be a great opportunity for DragonFly to participate
> > as a mentoring organisation.  We could attract new developers and could
> > get code/work done.  Looking at the SoC results of the other BSDs most
> > of their projects were a success.  Of course, not all, but a reasonable
> > percentage.  See [1] and [2].

We've applied in previous years - Jeff Hsu did one year, and I put
together the application last year.  The hardest thing to find was
students (and they are the thing that helps SoC applications a lot, I
think).

Any student volunteers?  We have mentors.


-- 
Robert Luciani
Chalmers University of Technology, SWE
Department of Computer Science and Engineering
http://www.rluciani.com/public.key




From rluciani at gmail.com  Tue Mar  4 10:04:14 2008
From: rluciani at gmail.com (Robert Luciani)
Date: Tue, 04 Mar 2008 19:04:14 +0100
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47cd8f1f$0$856$415eb37d@crater_reader.dragonflybsd.org>

Robert Luciani wrote:
> Justin C. Sherrill wrote:
>> On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
>>> Hi,
>>>
>>> Google just announced its Summer of Code for 2008:
>>>
>>> 	http://code.google.com/soc/2008/
>>>
>>> I think this would be a great opportunity for DragonFly to participate
>>> as a mentoring organisation.  We could attract new developers and could
>>> get code/work done.  Looking at the SoC results of the other BSDs most
>>> of their projects were a success.  Of course, not all, but a reasonable
>>> percentage.  See [1] and [2].
>> We've applied in previous years - Jeff Hsu did one year, and I put
>> together the application last year.  The hardest thing to find was
>> students (and they are the thing that helps SoC applications a lot, I
>> think).
>>
>> Any student volunteers?  We have mentors.
>>
> 
> bingo
> 
My girlfriend Danwei noted that she would also like partake in the SoC.
She's studying IT here at Chalmers and will join the mailing list shortly.
-- 
Robert Luciani
Chalmers University of Technology, SWE
Department of Computer Science and Engineering
http://www.rluciani.com/public.key




From dillon at apollo.backplane.com  Tue Mar  4 13:08:30 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Tue, 4 Mar 2008 13:08:30 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Going to have to roll 1.12.1
Message-ID: <200803042104.m24L43g1065278@apollo.backplane.com>

    Due to a critical bug in sendmail that can cause it to seg-fault I will
    be rolling 1.12.1 as soon as I get verification that the current
    fix deals with it.

						-Matt





From sdavtaker at gmail.com  Tue Mar  4 17:40:43 2008
From: sdavtaker at gmail.com (=?UTF-8?B?U2TDpHZ0YWtlcg==?=)
Date: Tue, 4 Mar 2008 17:40:43 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: [Fwd: Project Support Open Source: $50 donation to support you  project]
In-Reply-To: <2468.192.168.0.242.1204346451.squirrel@www.shiningsilence.com>
Message-ID: <47CDF8D1.9070100@gmail.com>

50 bucks?
Come on...
You can get a meal a lot more expensive than that just going to a free 
HP conference about linux and you only have to rent your soul 3-5 hours ;-)
Sdav

Matthew Dillon escribi?:
:..
:source project's web page.  I'm putting those words in scare quotes
:because I think it's a "payment" for an "advertisement".  The supplied
:link has nothing to do with DragonFly, to say the least.
:
:I don't think this is a good idea, obviously, and replied to that effect. 
:However, I wanted to put this on a DragonFly list, in part to show this
:strange thing, and in part because I'm not comfortable making
:administrative decisions on behalf of the Project without being open as
:possible about it.

    It doesn't really cry out to me either.

						-Matt

  






From sdavtaker at gmail.com  Tue Mar  4 17:56:35 2008
From: sdavtaker at gmail.com (=?UTF-8?B?U2TDpHZ0YWtlcg==?=)
Date: Tue, 4 Mar 2008 17:56:35 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47CDFCCE.1010106@gmail.com>

A cute idea for for GSOC would be to finish the installer.
We were talking about this in my local BUG, we trying to find out how to 
help on that from here.
There is a few missing features in the CD.

   * FDISK, you need to create the slides from another OS before
     install DFBSD, i think port FDisk from FBSD or any *BSD will solve it.
   * Add to the make release a way to add some custom applications to
     the released liveCD (suppose you want to add nmap or ssh or
     something just to use as test disk in some enviroment).
   * Make the installer a little more customizable, and maybe w/ a GUI
     (I like a lot the console approach, but GUI installer will be a
     popularity move, DFBSD w/X makes a Desktop machine work, actually
     im using it that way and really like it).
I think those projects can be done in a SOC by students (like me) with a 
little guide.
Im a lot more interested in things network related and kernel, but i 
dont mind to work on those things, they need to be done some day.
What u think?
Sdav

Robert Luciani escribi?:
Robert Luciani wrote:
  
Justin C. Sherrill wrote:
    
On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
      
Hi,

Google just announced its Summer of Code for 2008:

	http://code.google.com/soc/2008/

I think this would be a great opportunity for DragonFly to participate
as a mentoring organisation.  We could attract new developers and could
get code/work done.  Looking at the SoC results of the other BSDs most
of their projects were a success.  Of course, not all, but a reasonable
percentage.  See [1] and [2].
        
We've applied in previous years - Jeff Hsu did one year, and I put
together the application last year.  The hardest thing to find was
students (and they are the thing that helps SoC applications a lot, I
think).
Any student volunteers?  We have mentors.

      
bingo

    
My girlfriend Danwei noted that she would also like partake in the SoC.
She's studying IT here at Chalmers and will join the mailing list shortly.
  






From c.turner at 199technologies.org  Tue Mar  4 18:30:53 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Tue, 4 Mar 2008 18:30:53 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47CE04C9.1010902@199technologies.org>

Justin C. Sherrill wrote:
together the application last year.  The hardest thing to find was
students (and they are the thing that helps SoC applications a lot, I
think).
umm.. if google wants to send me back to school, I'll sign up - hows 
that for a fair trade :?






From wbh at conducive.org  Tue Mar  4 23:52:13 2008
From: wbh at conducive.org (Bill Hacker)
Date: Wed, 05 Mar 2008 07:52:13 +0000
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47ce512e$0$855$415eb37d@crater_reader.dragonflybsd.org>

Sd?vtaker wrote:
A cute idea for for GSOC would be to finish the installer.
We were talking about this in my local BUG, we trying to find out how to 
help on that from here.
There is a few missing features in the CD.

   * FDISK, you need to create the slides from another OS before
     install DFBSD, i think port FDisk from FBSD or any *BSD will solve it.
I'd rather see that 'reversed' - i.e. - build a more capable fdisk in 
DFLY with hope that it might be seen worth importing into Free/Net/Open, 
or *at least* be able to do a more flexible job than those now do.

And disklabels as well. Hand in glove.

Here's why:

- At the moment, working with Free, Open, DFLY, and OpenSolaris on the 
same HDD requires a bit of acrobatics.

- There seems to now be greater divergence between/among the *BSD's as 
to being able to read each other's disklabels, mount and use each 
other's 'flavor' of FFS/UFS (not to mention Apple's implementation of 
UFS) than there is among the vast multitude of Linux ext2/3 denizens.

Even to the point where use of a *Linux* fs is the more universal way 
for being able to share mounts among the *BSD's. Think detached drives. 
And no - FAT is not all that practical for several reasons.

- DFLY currently has the most fine-grain ability to create slices and 
partitions. But the others cannot all (any?) read those.

'progress' w/r any of the *BSD's direction as to changes, improvements 
(or not) in their once-common-ancestry fs & disklabels need not be 
sacrificed.

I'm not holding out wish or hope for all players agreeing to return to 
'one sacred way'. Nor 'one new universal fs'. Neither is gonna happen.

But a 'legacy compatible' or least-common-denominator mode would do fine 
- most especially for portable / SAN devices.

So - how about a 'flexible' DFLY fdisk to go along with a 'flexible' 
disklabel that could adapt to whatever it found / was told to create?

JM2CW - but that *might* be a good place to get a cross-*BSD team together.

*snip* (other good stuff)

Bill Hacker




From matthias at dragonflybsd.org  Wed Mar  5 01:02:43 2008
From: matthias at dragonflybsd.org (Matthias Schmidt)
Date: Wed, 5 Mar 2008 01:02:43 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <20080305085747.GJ9833@staatsfeind.org>

Hi,

* Justin C. Sherrill wrote:
> 
> We've applied in previous years - Jeff Hsu did one year, and I put
> together the application last year.  The hardest thing to find was
> students (and they are the thing that helps SoC applications a lot, I
> think).

This is good to know, so we could coordinate that if we have enough
mentors and projects?!?  I put together a small text in the wiki:

http://wiki.dragonflybsd.org/index.cgi/GoogleSoC2008

Feel free to add project or missing stuff.  I'm sure I missed a lot of
things :)

> Any student volunteers?  We have mentors.

According to the discussion we could have some students, who would be a
mentor (besides me)?

Regards

	Matthias





From sdavtaker at gmail.com  Wed Mar  5 06:28:37 2008
From: sdavtaker at gmail.com (=?UTF-8?Q?Sd=C3=A4vtaker?=)
Date: Wed, 5 Mar 2008 06:28:37 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <c37d69f60803050624kd86d3d0w3b44a02d0e5a5391@mail.gmail.com>

<quote>
Write a driver (from scratch) for Intel 3945 wireless device
Mentor: Sepherosa Ziehau
</quote>

Yes yes yes, i want to :-)
Someone else planning to mentor in drivers coding?
Sdav

On Wed, Mar 5, 2008 at 5:57 AM, Matthias Schmidt
<matthias at dragonflybsd.org> wrote:
> Hi,
>
>
>  * Justin C. Sherrill wrote:
>  >
>  > We've applied in previous years - Jeff Hsu did one year, and I put
>  > together the application last year.  The hardest thing to find was
>  > students (and they are the thing that helps SoC applications a lot, I
>  > think).
>
>  This is good to know, so we could coordinate that if we have enough
>  mentors and projects?!?  I put together a small text in the wiki:
>
>  http://wiki.dragonflybsd.org/index.cgi/GoogleSoC2008
>
>  Feel free to add project or missing stuff.  I'm sure I missed a lot of
>  things :)
>
>
>  > Any student volunteers?  We have mentors.
>
>  According to the discussion we could have some students, who would be a
>  mentor (besides me)?
>
>  Regards
>
>         Matthias
>
>



-- 
Sd?vtaker prays to Rikku goddess for a good treasure.



From rluciani at gmail.com  Wed Mar  5 10:56:42 2008
From: rluciani at gmail.com (Robert Luciani)
Date: Wed, 05 Mar 2008 19:56:42 +0100
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47ceecea$0$847$415eb37d@crater_reader.dragonflybsd.org>

Sd?vtaker wrote:
> <quote>
> Write a driver (from scratch) for Intel 3945 wireless device
> Mentor: Sepherosa Ziehau
> </quote>
> 
> Yes yes yes, i want to :-)
> Someone else planning to mentor in drivers coding?
> Sdav
> 
> On Wed, Mar 5, 2008 at 5:57 AM, Matthias Schmidt
> <matthias at dragonflybsd.org> wrote:
>> Hi,
>>
>>
>>  * Justin C. Sherrill wrote:
>>  >
>>  > We've applied in previous years - Jeff Hsu did one year, and I put
>>  > together the application last year.  The hardest thing to find was
>>  > students (and they are the thing that helps SoC applications a lot, I
>>  > think).
>>
>>  This is good to know, so we could coordinate that if we have enough
>>  mentors and projects?!?  I put together a small text in the wiki:
>>
>>  http://wiki.dragonflybsd.org/index.cgi/GoogleSoC2008
>>
>>  Feel free to add project or missing stuff.  I'm sure I missed a lot of
>>  things :)
>>
>>
>>  > Any student volunteers?  We have mentors.
>>
>>  According to the discussion we could have some students, who would be a
>>  mentor (besides me)?
>>
>>  Regards
>>
>>         Matthias
>>
>>
> 
> 
>

IF someone starts to write a 3945 Intel driver,
please keep the newer 4965 in mind too.

-- 
Robert Luciani
Chalmers University of Technology, SWE
Department of Computer Science and Engineering
http://www.rluciani.com/public.key




From joerg at britannica.bec.de  Wed Mar  5 12:01:05 2008
From: joerg at britannica.bec.de (Joerg Sonnenberger)
Date: Wed, 5 Mar 2008 12:01:05 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <20080305195711.GA9981@britannica.bec.de>

On Wed, Mar 05, 2008 at 07:56:42PM +0100, Robert Luciani wrote:
> IF someone starts to write a 3945 Intel driver,
> please keep the newer 4965 in mind too.

NetBSD's wpi works quite well. The hardware is quite different from
4945.

Joerg




From sepherosa at gmail.com  Wed Mar  5 17:48:50 2008
From: sepherosa at gmail.com (Sepherosa Ziehau)
Date: Wed, 5 Mar 2008 17:48:50 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <ea7b9c170803051744u22b09484ofc994f034f11df3b@mail.gmail.com>

On Thu, Mar 6, 2008 at 2:56 AM, Robert Luciani <rluciani at gmail.com> wrote:
>  IF someone starts to write a 3945 Intel driver,

"IF" you know that trying to fix any wired bugs in certain drivers
(e.g. ipw, ral) will require you to read through all of the vendor's
linux code (yes, even including register values and position), i.e.
there is not much difference between writing one from scratch and
porting+fixing_bugs, then you probably will not put "IF" at the start
of your sentence.
If what I said sounded too harsh to you, then I was sorry.

>  please keep the newer 4965 in mind too.

Will do, once generic 11n support is brought in from freebsd.

Best Regards,
sephe

-- 
Live Free or Die




From saw at online.de  Thu Mar  6 05:34:14 2008
From: saw at online.de (Sascha Wildner)
Date: Thu, 06 Mar 2008 14:34:14 +0100
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
Message-ID: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>

Hi all,

this is probably as good a moment as any to come out of the forest with 
this. The patch at

http://leaf.dragonflybsd.org/~swildner/nrelease_gui.diff

adds some code to nrelease/ to build a LiveCD with xorg and so on 
(currently, only the xorg metapackages and fluxbox are added). In order 
to build one, you need a local dir with the pkgsrc binary packages (see 
below).

The following commands should then do the trick:

cd /usr/src
make buildworld
make buildkernel
cd nrelease
patch -p 0 </path/to/the/patch
make PKGSRC_PKG_PATH=/path/to/packages/dir/All realquick gui
The resulting ISO will be in /usr/release/dfly-gui.iso then. It will not 
boot into xorg automatically (although this is easily possible), so you 
need to login as root and do startx.

As of now, this all is kind of basic, more a proof of concept than 
anything else. As our release framework installs packages via chroot, 
the current setup just copies _all_ packages to the chroot before 
installing (kind of a hack).

That said, I'm now primarily interested in opinions/ideas/... about the 
direction this should take. Which packages would we like to see on the 
CD? Should it be a generic setup with the "most common things" 
installed, so a system can be quickly setup by the installer (which will 
cpdup /usr/pkg). Or should it be a more specialized set of tools? Or 
even as many packages as possible (Live DVD?). Etc., etc.

Before continuing on it, I'm really interested in people's input so 
don't hold anything back, please. :)

Sascha

--
http://yoyodyne.ath.cx



From rluciani at gmail.com  Thu Mar  6 06:42:03 2008
From: rluciani at gmail.com (Robert Luciani)
Date: Thu, 06 Mar 2008 15:42:03 +0100
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <47d002bc$0$847$415eb37d@crater_reader.dragonflybsd.org>

Sascha Wildner wrote:
> Hi all,
> 
> this is probably as good a moment as any to come out of the forest with
> this. The patch at
> 
> http://leaf.dragonflybsd.org/~swildner/nrelease_gui.diff
> 
> adds some code to nrelease/ to build a LiveCD with xorg and so on
> (currently, only the xorg metapackages and fluxbox are added). In order
> to build one, you need a local dir with the pkgsrc binary packages (see
> below).
> 
> The following commands should then do the trick:
> 
> cd /usr/src
> make buildworld
> make buildkernel
> cd nrelease
> patch -p 0 </path/to/the/patch
> make PKGSRC_PKG_PATH=/path/to/packages/dir/All realquick gui
> 
> The resulting ISO will be in /usr/release/dfly-gui.iso then. It will not
> boot into xorg automatically (although this is easily possible), so you
> need to login as root and do startx.
> 
> As of now, this all is kind of basic, more a proof of concept than
> anything else. As our release framework installs packages via chroot,
> the current setup just copies _all_ packages to the chroot before
> installing (kind of a hack).
> 
> That said, I'm now primarily interested in opinions/ideas/... about the
> direction this should take. Which packages would we like to see on the
> CD? Should it be a generic setup with the "most common things"
> installed, so a system can be quickly setup by the installer (which will
> cpdup /usr/pkg). Or should it be a more specialized set of tools? Or
> even as many packages as possible (Live DVD?). Etc., etc.
> 
> Before continuing on it, I'm really interested in people's input so
> don't hold anything back, please. :)
> 
> Sascha
> 

I think the main point of such a live-cd would be to test
dragonfly-specific features such as vkernels and more. Mplayer and
OpenOffic work the same on all platforms, so they might not be super
important, while irssi, firefox, networking tools, vim, a few more
shells/terminals might make it easier to for people to quickly gauge if
they can reproduce their current productivity and also what is new.

And if the point of a livecd is to test that kind of stuff, then it
would be nice for it to have a kernel that supports as much as possible
like ALTQ, and drivers.

Also if it has lots and lots of programs (thinking multimedia, java,
etc..) it might be hard to keep the future x64 and x86 live-cds on par.
Gentoo had this problem many years ago and it was very bothersome.

-- 
Robert Luciani
Chalmers University of Technology, SWE
Department of Computer Science and Engineering
http://www.rluciani.com/public.key




From matthias at dragonflybsd.org  Thu Mar  6 07:12:43 2008
From: matthias at dragonflybsd.org (Matthias Schmidt)
Date: Thu, 6 Mar 2008 07:12:43 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <20080306150757.GN9833@staatsfeind.org>

* Sascha Wildner wrote:
> Hi all,
> 
> this is probably as good a moment as any to come out of the forest with this. 
> The patch at
> 
> http://leaf.dragonflybsd.org/~swildner/nrelease_gui.diff
> 
> adds some code to nrelease/ to build a LiveCD with xorg and so on (currently, 
> only the xorg metapackages and fluxbox are added). In order to build one, you 
> need a local dir with the pkgsrc binary packages (see below).

Great work Sascha.

I agree with Robert on most of his stated points.
It would be nice to see some DragonFly specific features on the CD
(although I'm not sure if that will work for all features).  A little
environment where most Unix users feel at home (fluxbox, xfce, firefox,
thunderbird, gvim) should be enough.

Big applications like OO.org, java etc won't work because they are not
available as pkgsrc packages neither is it possible to compile them on
DragonFly.  At least to my knowledge.

Regards

	Matthias




From dillon at apollo.backplane.com  Thu Mar  6 09:31:52 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Thu, 6 Mar 2008 09:31:52 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <200803061728.m26HSR3O091809@apollo.backplane.com>


:Hi all,
:
:this is probably as good a moment as any to come out of the forest with 
:this. The patch at
:
:http://leaf.dragonflybsd.org/~swildner/nrelease_gui.diff
:
:adds some code to nrelease/ to build a LiveCD with xorg and so on 
:(currently, only the xorg metapackages and fluxbox are added). In order 
:to build one, you need a local dir with the pkgsrc binary packages (see 
:below).
:
:The following commands should then do the trick:

    It looks reasonable, though the package copy has to be tightened
    up a bit I think.

:...
:installed, so a system can be quickly setup by the installer (which will 
:cpdup /usr/pkg). Or should it be a more specialized set of tools? Or 
:even as many packages as possible (Live DVD?). Etc., etc.
:
:Before continuing on it, I'm really interested in people's input so 
:don't hold anything back, please. :)
:
:Sascha

    I think this is an excellent time to work up a DVD build and to
    add various 'flavor' extras.  So, e.g.:

	make installer gui gui_extras release dvd

    (All 'dvd' would do is generate a dvd compatible image for burning to
    dvd instead of cd).  I did a quick perusal of what I have on my
    workstation:

    * X
    * Firefox
    * Linux emulation
    * Open Office (linux version)
    * fvwm2
    * xpdf
    * freetype2

    I'd also suggest some image editing tools like gimp, and maybe the KDE
    gui suite.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From justin at shiningsilence.com  Thu Mar  6 09:42:44 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Thu, 6 Mar 2008 09:42:44 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <55427.65.106.147.226.1204825168.squirrel@www.shiningsilence.com>

On Thu, March 6, 2008 8:34 am, Sascha Wildner wrote:

> That said, I'm now primarily interested in opinions/ideas/... about the
> direction this should take. Which packages would we like to see on the
> CD? Should it be a generic setup with the "most common things"
> installed, so a system can be quickly setup by the installer (which will
> cpdup /usr/pkg). Or should it be a more specialized set of tools? Or
> even as many packages as possible (Live DVD?). Etc., etc.

What Robert said is good - whatever's needed to enable DragonFly-specific
features.  Along with that would be some sort of documentation (a README? 
A HTML file on whatever desktop we provide) that points people at the
different DragonFly tools, so they know what to try and how to try it.

There's going to be some percentage of people who try DragonFly who don't
know about vkernels, for instance, but there's our chance to educate them.
 I'm probably volunteering myself, aren't I?





From sdavtaker at gmail.com  Thu Mar  6 09:50:09 2008
From: sdavtaker at gmail.com (=?UTF-8?Q?Sd=C3=A4vtaker?=)
Date: Thu, 6 Mar 2008 09:50:09 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <c37d69f60803060947t110750c0sd6b542ea505d188d@mail.gmail.com>

Cool Sascha :-)
I just posted about this 1 or 2 days ago in the SOC project ideas thread.
Want to mentor this one? ;-)
Damian

On Thu, Mar 6, 2008 at 2:28 PM, Matthew Dillon
<dillon at apollo.backplane.com> wrote:
>
>  :Hi all,
>
> :
>  :this is probably as good a moment as any to come out of the forest with
>  :this. The patch at
>  :
>  :http://leaf.dragonflybsd.org/~swildner/nrelease_gui.diff
>  :
>  :adds some code to nrelease/ to build a LiveCD with xorg and so on
>  :(currently, only the xorg metapackages and fluxbox are added). In order
>  :to build one, you need a local dir with the pkgsrc binary packages (see
>  :below).
>  :
>  :The following commands should then do the trick:
>
>     It looks reasonable, though the package copy has to be tightened
>     up a bit I think.
>
>  :...
>  :installed, so a system can be quickly setup by the installer (which will
>
> :cpdup /usr/pkg). Or should it be a more specialized set of tools? Or
>  :even as many packages as possible (Live DVD?). Etc., etc.
>  :
>  :Before continuing on it, I'm really interested in people's input so
>  :don't hold anything back, please. :)
>  :
>  :Sascha
>
>     I think this is an excellent time to work up a DVD build and to
>     add various 'flavor' extras.  So, e.g.:
>
>         make installer gui gui_extras release dvd
>
>     (All 'dvd' would do is generate a dvd compatible image for burning to
>     dvd instead of cd).  I did a quick perusal of what I have on my
>     workstation:
>
>     * X
>     * Firefox
>     * Linux emulation
>     * Open Office (linux version)
>     * fvwm2
>     * xpdf
>     * freetype2
>
>     I'd also suggest some image editing tools like gimp, and maybe the KDE
>     gui suite.
>
>                                         -Matt
>                                         Matthew Dillon
>                                         <dillon at backplane.com>
>



-- 
Sd?vtaker prays to Rikku goddess for a good treasure.



From saw at online.de  Thu Mar  6 11:54:01 2008
From: saw at online.de (Sascha Wildner)
Date: Thu, 06 Mar 2008 20:54:01 +0100
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <47d04ba2$0$856$415eb37d@crater_reader.dragonflybsd.org>

Matthew Dillon wrote:
    It looks reasonable, though the package copy has to be tightened
    up a bit I think.
It looks as if it would work with mount_null'ing the chroot's 
/tmp/packages. I'll have a better patch ready tomorrow.

Sascha

--
http://yoyodyne.ath.cx



From c.turner at 199technologies.org  Thu Mar  6 19:11:44 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Thu, 6 Mar 2008 19:11:44 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Misc. ACPI / suspend
In-Reply-To: <47CA073B.6020106@199technologies.org>
Message-ID: <47D0B079.3060905@199technologies.org>

Chris Turner wrote:
Wondering if anyone more well versed in the ACPI implementation could
comment on the applicability of:
http://lkml.org/lkml/2007/4/6/69

Doing a little digging, it seems like

. /platform/pc32/i386/i686_mem.c

*might* have the necessary infrastructure to remap the MTRR's per the 
thread referenced,

but:

. /platform/pc32/acpica5/acpi_wakeup.c

doesn't seem to be using this infrastructure..

I'm no where near reaching an understanding of this yet,
but I'm wondering 3 things:
1) does anyone have ACPI (instead of APM)
   sleep / suspend / wakeup working on Dfly ?
2) If so, what machines are being used ?
3) Same question for other BSDs - my understanding is NetBSD is most
   'advanced' w/r/t power managment - but I'm not 100% on this ...
would looove to have a sleeping / resuming / scaling laptop running some 
BSD flavor.. am willing to work towards that end, esp. w/r/t Dfly -
trying to chart a course to figguring this out.

Thanks all,

- Chris




From c.turner at 199technologies.org  Thu Mar  6 19:12:33 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Thu, 6 Mar 2008 19:12:33 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: PCI Bios / Interrupt remapping / etc
Message-ID: <47D0B211.6000002@199technologies.org>

Doing a bit of digging here for my long-standing CBB+SIO interupt and 
buffer problem -

one machine I've tested against was an OpenBSD machine, which didn't
always work to handle the cardbus sio card on a PCI cardbus adapter
-

tuning up some of the device flags in:

http://www.openbsd.org/cgi-bin/man.cgi?query=pcibios&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=html

seems to have alleviated the problem for that os..

I'm just only starting to get up to speed on how DF handles these types 
of things (namely initial PIC / interrupt layout at boot time device 
enumeration), but am wondering if anyone familiar with this area of the 
code has any comments / advice w/r/t the capabilities of the DF bios 
drivers
and the various quirks / fixup mentioned in the link above..

looking to possibly investigate fixing up some of these issues over time.

Thanks

- Chris







From pavalos at theshell.com  Fri Mar  7 01:14:55 2008
From: pavalos at theshell.com (Peter Avalos)
Date: Fri, 7 Mar 2008 01:14:55 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: cam locking
Message-ID: <20080307091024.GC1652@ylem.theshell.com>

So I've been working on locking up cam using lockmgr locks, and here's
what I have so far:

http://www.theshell.com/~pavalos/wip/cam-lock.patch

Most of the work is obtained from FreeBSD.  I've only been running this
on my SCSI machine for a day, but because the patch is so large, I wanted
to make it available for people to review if they have some spare time.

Thanks,
Peter
Attachment:
pgp00002.pgp
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00002.pgp
Type: application/octet-stream
Size: 197 bytes
Desc: "Description: PGP signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080307/9a17ecd8/attachment-0013.obj>

From jspringe at uos.de  Fri Mar  7 03:25:17 2008
From: jspringe at uos.de (Jost Tobias Springenberg)
Date: Fri, 7 Mar 2008 12:25:17 +0100
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <20080307122517.72c9e2b1.jspringe@uos.de>

On Tue, 4 Mar 2008 11:28:15 -0500 (EST)
"Justin C. Sherrill" <justin at shiningsilence.com> wrote:

> On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
> > Hi,
> >
> > Google just announced its Summer of Code for 2008:
> >
> > 	http://code.google.com/soc/2008/
> >
> > I think this would be a great opportunity for DragonFly to participate
> > as a mentoring organisation.  We could attract new developers and could
> > get code/work done.  Looking at the SoC results of the other BSDs most
> > of their projects were a success.  Of course, not all, but a reasonable
> > percentage.  See [1] and [2].
> 
> We've applied in previous years - Jeff Hsu did one year, and I put
> together the application last year.  The hardest thing to find was
> students (and they are the thing that helps SoC applications a lot, I
> think).
> 
> Any student volunteers?  We have mentors.
> 

I read this mailing list for quite a while now and thought about contributing stuff
to DFfly several times, so yes why not take this opportunity if it's there.

-- 
Jost Tobias Springenberg <jspringe at uos.de>




From tgen at netphreax.net  Fri Mar  7 05:17:27 2008
From: tgen at netphreax.net (Thomas E. Spanjaard)
Date: Fri, 7 Mar 2008 05:17:27 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: PCI Bios / Interrupt remapping / etc
In-Reply-To: <47D0B211.6000002@199technologies.org>
Message-ID: <47D13FB4.5080306@netphreax.net>

Chris Turner wrote:
Doing a bit of digging here for my long-standing CBB+SIO interupt and 
buffer problem -

one machine I've tested against was an OpenBSD machine, which didn't
always work to handle the cardbus sio card on a PCI cardbus adapter
-

tuning up some of the device flags in:

http://www.openbsd.org/cgi-bin/man.cgi?query=pcibios&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=html 

seems to have alleviated the problem for that os..

I'm just only starting to get up to speed on how DF handles these types 
of things (namely initial PIC / interrupt layout at boot time device 
enumeration), but am wondering if anyone familiar with this area of the 
code has any comments / advice w/r/t the capabilities of the DF bios 
drivers
and the various quirks / fixup mentioned in the link above..

looking to possibly investigate fixing up some of these issues over time.
Our code that handles issues like this (in cases where you're not using 
APICs, just PICs and PIRs) lives in bus/pci/i386/. Not that running 
without APIC support is all that common on modern machines anymore...
--
        Thomas E. Spanjaard
        tgen at netphreax.net
Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00003.pgp
Type: application/octet-stream
Size: 186 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080307/61366b5c/attachment-0013.obj>

From tgen at netphreax.net  Fri Mar  7 05:16:51 2008
From: tgen at netphreax.net (Thomas E. Spanjaard)
Date: Fri, 7 Mar 2008 05:16:51 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Misc. ACPI / suspend
In-Reply-To: <47CA073B.6020106@199technologies.org>
Message-ID: <47D13F07.9080308@netphreax.net>

Chris Turner wrote:
1) does anyone have ACPI (instead of APM)
   sleep / suspend / wakeup working on Dfly ?
2) If so, what machines are being used ?
3) Same question for other BSDs - my understanding is NetBSD is most
   'advanced' w/r/t power managment - but I'm not 100% on this ...
would looove to have a sleeping / resuming / scaling laptop running some 
BSD flavor.. am willing to work towards that end, esp. w/r/t Dfly -
trying to chart a course to figguring this out.
I have ACPI S3 suspend working like a charm on my IBM ThinkPad R40 
(Pentium M "Banias" 1.3GHz, speedstepping works just fine), running 
NetBSD 3.99.21.
--
        Thomas E. Spanjaard
        tgen at netphreax.net
Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00004.pgp
Type: application/octet-stream
Size: 186 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080307/de3e5104/attachment-0013.obj>

From civilizd at gmail.com  Fri Mar  7 09:06:41 2008
From: civilizd at gmail.com (Vita "CiV" Cizek)
Date: Fri, 7 Mar 2008 09:06:41 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <98d564710803070853q1c73d795m6e6c5cc5049fa099@mail.gmail.com>

>  Any student volunteers?  We have mentors.
>
I am interested too, especially in some kernel-related work.




From justin at shiningsilence.com  Sat Mar  8 12:07:51 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Sat, 8 Mar 2008 12:07:51 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google SoC 2008 - mentors mentors mentors
Message-ID: <51558.192.168.0.252.1205006403.squirrel@www.shiningsilence.com>

If you are willing to mentor for the Google 2008 Summer of Code, please
speak up.  Right now we have: (from our wiki page)

Matthias
Sephe
TGEN
corecode

Part of the application process includes naming people as mentors (student
applications come later), so I want to get as complete a list as possible.

The application is due on the 12th, so if you want to mentor, now's the
time to say so.

Google's SoC FAQ is here: http://code.google.com/soc/2008/faqs.html

Our wiki page is here: http://wiki.dragonflybsd.org/index.cgi/GoogleSoC2008

- much credit to Matthias and others for getting that set up.





From saw at online.de  Sat Mar  8 14:26:07 2008
From: saw at online.de (Sascha Wildner)
Date: Sat, 08 Mar 2008 23:26:07 +0100
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <47d31245$0$848$415eb37d@crater_reader.dragonflybsd.org>

Sascha Wildner wrote:
Hi all,

this is probably as good a moment as any to come out of the forest with 
this. The patch at

http://leaf.dragonflybsd.org/~swildner/nrelease_gui.diff
Ok, I have committed the stuff as an example.

I'm not sure if my free time permits to work on a full-blown live CD 
with X11 and other good things (I already feel my interest wandering off 
in other directions) so if anyone wants to pick up the ball, go ahead. :)

Sascha

--
http://yoyodyne.ath.cx



From qhwt+dfly at les.ath.cx  Tue Mar 11 22:21:31 2008
From: qhwt+dfly at les.ath.cx (YONETANI Tomokazu)
Date: Tue, 11 Mar 2008 22:21:31 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Misc. ACPI / suspend
In-Reply-To: <47CA073B.6020106@199technologies.org>
Message-ID: <20080312051219.GA56091@les.ath.cx>

On Thu, Mar 06, 2008 at 10:03:21PM -0500, Chris Turner wrote:
> 1) does anyone have ACPI (instead of APM)
>    sleep / suspend / wakeup working on Dfly ?
> 2) If so, what machines are being used ?

Dynabook SS3500 (http://www.tlt.co.jp/pc/catalog/ss/02110735/index_j.htm).
It's old and can get very hot(thus frequently turns on the cooling fan)
even when it's running Windows.  I haven't turned it on for about several
months though.

Cheers.




From c.turner at 199technologies.org  Wed Mar 12 04:37:22 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Wed, 12 Mar 2008 04:37:22 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Misc. ACPI / suspend
In-Reply-To: <47CA073B.6020106@199technologies.org>
Message-ID: <47D7BEE3.6010907@199technologies.org>

YONETANI Tomokazu wrote:
On Thu, Mar 06, 2008 at 10:03:21PM -0500, Chris Turner wrote:
1) does anyone have ACPI (instead of APM)
   sleep / suspend / wakeup working on Dfly ?
Cheers.
ditto..

Suppose this should go to docs@ - in any case..

Thinking about setting up a wiki page on the issue so we
can discuss / track what 'good' hardware / drivers / implementations / 
etc are 'out there' - anyone have any suggestions on where this should
go?

http://wiki.dragonflybsd.org/index.cgi/acpi-overview.html

Remains from the handbook conversion - but I'm hesitant to 'over wikify'
this ..



From c.turner at 199technologies.org  Wed Mar 12 15:36:52 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Wed, 12 Mar 2008 15:36:52 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: devel/cscope
Message-ID: <47D85A08.8040103@199technologies.org>

why oh why did I take so long to try this out !!!

just sharing my eureka moment with the list..

- Chris




From dudu at dudu.ro  Wed Mar 12 15:50:14 2008
From: dudu at dudu.ro (Vlad GALU)
Date: Wed, 12 Mar 2008 15:50:14 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: devel/cscope
In-Reply-To: <47D85A08.8040103@199technologies.org>
Message-ID: <ad79ad6b0803121547r2bf67ffep9e40badaac6490f8@mail.gmail.com>

On 3/13/08, Chris Turner <c.turner at 199technologies.org> wrote:
> why oh why did I take so long to try this out !!!
>
>  just sharing my eureka moment with the list..


    Works nice with vim, too!

>
>
>  - Chris
>


-- 
Mahnahmahnah!




From justin at shiningsilence.com  Sun Mar 16 21:06:13 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Sun, 16 Mar 2008 21:06:13 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: binary packages for 1.12 coming in
Message-ID: <1372.192.168.0.252.1205726088.squirrel@www.shiningsilence.com>

The binary build for 1.12 is taking quite a while.  I've started copying
in newly built packages to
pkgbox.dragonflybsd.org/packages/DragonFly-1.12/i386/ - this should be
getting copied out to mirrors over the next while.

There are currently 1283 packages built, which leaves a whole lot to go;
I'll copy new packages in as they complete.





From hasso at estpak.ee  Wed Mar 19 04:31:08 2008
From: hasso at estpak.ee (Hasso Tepper)
Date: Wed, 19 Mar 2008 04:31:08 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Some questions regarding ACPI
Message-ID: <200803191322.46366.hasso@estpak.ee>

I'm working on bringing in some laptop (and especially thinkpad) specific 
ACPI code from FreeBSD into DragonFly. I never touched ACPI stuff before 
and haven't followed it much either, so I have some questions.

* FreeBSD uses ACPI_SERIAL_* heavily. What's the locking situation in 
  DragonFly and why?

* As far as I can see, PCI integration is commented out in DragonFly. 
  What's the state of it and why?

* platform/pc32/acpica5/acpi_toshiba.c - why is it there? I don't think 
  that this is something pc32 specific in it and it should work in pc64 
  laptops as well. Any objections to move it into 
  dev/acpica5/acpi_toshiba/ ?

What's the current status of ACPI in general? AFAICS our acpica is quite 
old - what needs to be done to bring in newer one?


-- 
Hasso




From qhwt+dfly at les.ath.cx  Wed Mar 19 09:24:50 2008
From: qhwt+dfly at les.ath.cx (YONETANI Tomokazu)
Date: Wed, 19 Mar 2008 09:24:50 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Some questions regarding ACPI
In-Reply-To: <200803191322.46366.hasso@estpak.ee>
Message-ID: <20080319161703.GA51509@les.ath.cx>

On Wed, Mar 19, 2008 at 01:22:46PM +0200, Hasso Tepper wrote:
> I'm working on bringing in some laptop (and especially thinkpad) specific 
> ACPI code from FreeBSD into DragonFly. I never touched ACPI stuff before 
> and haven't followed it much either, so I have some questions.

So you want to port some of ACPI support drivers, or to do a fresh port
of ACPI driver from FreeBSD?

> * FreeBSD uses ACPI_SERIAL_* heavily. What's the locking situation in 
>   DragonFly and why?

The current ACPI driver in DragonFly is based on that of FreeBSD as of
end of June, 2004, plus some fixes brought in later (and ACPICA part
has been updated twice since then).  That was before they introduced
the MPSAFE changes into ACPI code, and we use critical section
(crit_{enter,exit}) in most places (and lockmgr lock in a few place).

> * As far as I can see, PCI integration is commented out in DragonFly. 
>   What's the state of it and why?

When we replaced the implementation taken from FreeBSD 4.x with that
brought from FreeBSD 5.x, which added the PCI part, many people
experienced problems until they turned off ACPI completely, or add "pci"
to "debug.acpi.disabled" loader variable.  AFAIK the PCI part in the ACPI
driver almost hasn't been adjusted to work with our version of PCI code.

> * platform/pc32/acpica5/acpi_toshiba.c - why is it there? I don't think 
>   that this is something pc32 specific in it and it should work in pc64 
>   laptops as well. Any objections to move it into 
>   dev/acpica5/acpi_toshiba/ ?

In FreeBSD it used to be sitting at i386/acpica/acpi_toshiba.c and was
later moved into acpi_support.  That change hasn't hit our tree (in fact,
we have no acpi support drivers other than that).  It seems that FreeBSD
has them in dev/acpi_support now, and we for some reason have that
directory in our CVS repository (but containing no files in it).

> What's the current status of ACPI in general? AFAICS our acpica is quite 
> old - what needs to be done to bring in newer one?

Actually, it's not very important to keep just ACPICA latest, but
if you bring the ACPI driver from FreeBSD you need to bring ACPICA code
that matches their version, and it IS important.  And it generally requires
you much work to just update ACPICA part anyway because of how they
change things on every release.

Cheers.




From hasso at estpak.ee  Wed Mar 19 12:29:52 2008
From: hasso at estpak.ee (Hasso Tepper)
Date: Wed, 19 Mar 2008 12:29:52 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Some questions regarding ACPI
In-Reply-To: <200803191322.46366.hasso@estpak.ee>
Message-ID: <200803192115.35396.hasso@estpak.ee>

YONETANI Tomokazu wrote:
> On Wed, Mar 19, 2008 at 01:22:46PM +0200, Hasso Tepper wrote:
> > I'm working on bringing in some laptop (and especially thinkpad)
> > specific ACPI code from FreeBSD into DragonFly. I never touched ACPI
> > stuff before and haven't followed it much either, so I have some
> > questions.
>
> So you want to port some of ACPI support drivers, or to do a fresh port
> of ACPI driver from FreeBSD?

I'm only interested in support drivers and the reason is pure practical - 
newer thinkpads handle less and less hotkeys etc in hardware and require 
support form OS. acpi_ibm and acpi_video are examples of such modules 
which would help a lot of these newer thinkpad users.

acpi_ibm is almost ready to commit (renamed to acpi_thinkpad though).

> > * FreeBSD uses ACPI_SERIAL_* heavily. What's the locking situation in
> >   DragonFly and why?
>
> The current ACPI driver in DragonFly is based on that of FreeBSD as of
> end of June, 2004, plus some fixes brought in later (and ACPICA part
> has been updated twice since then).  That was before they introduced
> the MPSAFE changes into ACPI code, and we use critical section
> (crit_{enter,exit}) in most places (and lockmgr lock in a few place).

Mkay. Will look at more closely.

> > * As far as I can see, PCI integration is commented out in DragonFly.
> >   What's the state of it and why?
>
> When we replaced the implementation taken from FreeBSD 4.x with that
> brought from FreeBSD 5.x, which added the PCI part, many people
> experienced problems until they turned off ACPI completely, or add
> "pci" to "debug.acpi.disabled" loader variable.  AFAIK the PCI part in
> the ACPI driver almost hasn't been adjusted to work with our version of
> PCI code.

I'm afraid that it's beyond my skills, but while looking at acpi_video I 
discovered that it's hard to handle correctly without PCI support.

> > * platform/pc32/acpica5/acpi_toshiba.c - why is it there? I don't
> > think that this is something pc32 specific in it and it should work
> > in pc64 laptops as well. Any objections to move it into
> >   dev/acpica5/acpi_toshiba/ ?
>
> In FreeBSD it used to be sitting at i386/acpica/acpi_toshiba.c and was
> later moved into acpi_support.  That change hasn't hit our tree (in
> fact, we have no acpi support drivers other than that).  It seems that
> FreeBSD has them in dev/acpi_support now, and we for some reason have
> that directory in our CVS repository (but containing no files in it).

I don't see it ;). Makes sense though. So, any objections if I move 
acpi_toshiba into sys/dev/acpi_support and add new acpi_thinkpad there as 
well? 

> > What's the current status of ACPI in general? AFAICS our acpica is
> > quite old - what needs to be done to bring in newer one?
>
> Actually, it's not very important to keep just ACPICA latest, but
> if you bring the ACPI driver from FreeBSD you need to bring ACPICA code
> that matches their version, and it IS important.  And it generally
> requires you much work to just update ACPICA part anyway because of how
> they change things on every release.

Someone else has to do it :).

Thanks for info.


-- 
Hasso




From dillon at apollo.backplane.com  Wed Mar 19 14:01:13 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Wed, 19 Mar 2008 14:01:13 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: panic: assertion: hammer_btree_cmp(cursor->left_bound,	&cursor->node->ondisk->elms[0].leaf.base) <= 0 in btree_split_leaf
In-Reply-To: <200802232204.m1NM4cxd046264@apollo.backplane.com>
Message-ID: <200803192054.m2JKsjwn045137@apollo.backplane.com>


:Hi.
:While trying to find a procedure to reliably reproduce the panic
:I reported last time, I caught a different panic (uploaded at
: ~y0netan1/crash/9/ on my leaf account).  I wrote the following shell
:script (make sure to edit variables DISKS and MOUNTPT before using this
:script or it may trash your system):
:  #!/bin/sh -ex
:  DISKS="/dev/ad0s1f"
:  MOUNTPT=/mnt/HAMMER
:
:  cd /
:  newfs_hammer -L TEST $DISKS
:  for i in `seq 1 100`; do
:..
:And the panic is triggered by rm command.
:I'll try to see if it's possible to reproduce the last one without
:unmounting then mounting the HAMMER fs.
:
:Cheers.

    I believe I have fixed this panic.  hammer_make_separator() had a bug
    in it.

    There is still an issue with the node ref count on umount.

    Please continue to life-test the code.  The reblocking code
    (hammer reblock /mnt) should work now, as should the pruning code
    (e.g. hammer prune /mnt everything).

    The filesystem full case is still not handled and will cause bad things
    to happen.  The undo code isn't finished yet either but it is getting
    there (it's writing stuff out but not setting the sequence number and
    not trying to recover-on-mount yet).

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From qhwt+dfly at les.ath.cx  Wed Mar 19 19:45:40 2008
From: qhwt+dfly at les.ath.cx (YONETANI Tomokazu)
Date: Wed, 19 Mar 2008 19:45:40 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Some questions regarding ACPI
In-Reply-To: <200803191322.46366.hasso@estpak.ee>
Message-ID: <20080320023828.GA53648@les.ath.cx>

On Wed, Mar 19, 2008 at 09:15:35PM +0200, Hasso Tepper wrote:
> YONETANI Tomokazu wrote:
> > On Wed, Mar 19, 2008 at 01:22:46PM +0200, Hasso Tepper wrote:
> > > I'm working on bringing in some laptop (and especially thinkpad)
> > > specific ACPI code from FreeBSD into DragonFly. I never touched ACPI
> > > stuff before and haven't followed it much either, so I have some
> > > questions.
> >
> > So you want to port some of ACPI support drivers, or to do a fresh port
> > of ACPI driver from FreeBSD?
> 
> I'm only interested in support drivers and the reason is pure practical - 
> newer thinkpads handle less and less hotkeys etc in hardware and require 
> support form OS. acpi_ibm and acpi_video are examples of such modules 
> which would help a lot of these newer thinkpad users.
> 
> acpi_ibm is almost ready to commit (renamed to acpi_thinkpad though).

Ah, that's a good news!  My only concern is that ISTR someone mentioned
me that his colleague was thinking about porting ACPI driver itself,
so if you're not the person you may want to collaborate with him/her
so as not to waste the effort or time...

			:

> > In FreeBSD it used to be sitting at i386/acpica/acpi_toshiba.c and was
> > later moved into acpi_support.  That change hasn't hit our tree (in
> > fact, we have no acpi support drivers other than that).  It seems that
> > FreeBSD has them in dev/acpi_support now, and we for some reason have
> > that directory in our CVS repository (but containing no files in it).
> 
> I don't see it ;). Makes sense though. So, any objections if I move 
> acpi_toshiba into sys/dev/acpi_support and add new acpi_thinkpad there as 
> well? 

Sorry, I checked the CVS repository and it doesn't exist actually :)
I don't have any objection to moving it there.

Cheers.




From hasso at estpak.ee  Thu Mar 20 00:14:05 2008
From: hasso at estpak.ee (Hasso Tepper)
Date: Thu, 20 Mar 2008 00:14:05 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Some questions regarding ACPI
In-Reply-To: <200803191322.46366.hasso@estpak.ee>
Message-ID: <200803200904.50875.hasso@estpak.ee>

YONETANI Tomokazu wrote:
> On Wed, Mar 19, 2008 at 09:15:35PM +0200, Hasso Tepper wrote:
> > acpi_ibm is almost ready to commit (renamed to acpi_thinkpad though).
>
> Ah, that's a good news!  My only concern is that ISTR someone mentioned
> me that his colleague was thinking about porting ACPI driver itself,
> so if you're not the person you may want to collaborate with him/her
> so as not to waste the effort or time...

Current state in my repo is attached. It should work on 1.12 as well as it 
doesn't depend yet on moving stuff around.

add-acpi-if-m.patch adds some new stuff to the ACPI code to access 
embedded controllers and match ACPI devices by ID. Not sure how, where 
and whether at all these should be documented.

add-acpi-thinkpad.patch is the driver itself. Note that some stuff doesn't 
work yet on newer thinkpads, I plan to work on it later.

There is still some things to do though. I have to decide what to do with 
led(4) part and with locking. There is also one fatal issue - laptop 
locks up hardly (no panic) while unloading module. Any idea regarding 
this is welcome. And of course test results :).


-- 
Hasso
# HG changeset patch
# User Hasso Tepper <hasso at estpak.ee>
# Date 1205919290 -7200
# Branch HEAD
# Node ID 5a6e2705cc95a340abf973ae5df73ef34e070b79
# Parent  cd529e2e7f849034d5d5a0973cb98af50db0e797
imported patch adding-acpi-if-m.patch

diff --git a/sys/conf/files b/sys/conf/files
--- a/sys/conf/files
+++ b/sys/conf/files
@@ -1387,6 +1387,7 @@ emulation/dragonfly12/dfbsd12_stat.c	non
 ${OSACPI_MI_DIR}/acpi_cmbat.c		optional acpi
 ${OSACPI_MI_DIR}/acpi_cpu.c		optional acpi
 ${OSACPI_MI_DIR}/acpi_ec.c		optional acpi
+${OSACPI_MI_DIR}/acpi_if.m		optional acpi
 ${OSACPI_MI_DIR}/acpi_isab.c		optional acpi isa
 ${OSACPI_MI_DIR}/acpi_lid.c		optional acpi
 ${OSACPI_MI_DIR}/acpi_package.c		optional acpi
diff --git a/sys/conf/kmod.mk b/sys/conf/kmod.mk
--- a/sys/conf/kmod.mk
+++ b/sys/conf/kmod.mk
@@ -275,7 +275,7 @@ MFILES?= kern/bus_if.m kern/device_if.m 
     bus/pccard/card_if.m bus/pccard/power_if.m bus/pci/pci_if.m \
     bus/pci/pcib_if.m \
     bus/ppbus/ppbus_if.m bus/smbus/smbus_if.m bus/usb/usb_if.m \
-    dev/disk/nata/ata_if.m \
+    dev/acpica5/acpi_if.m dev/disk/nata/ata_if.m \
     dev/sound/pcm/ac97_if.m dev/sound/pcm/channel_if.m \
     dev/sound/pcm/feeder_if.m dev/sound/pcm/mixer_if.m \
     libiconv/iconv_converter_if.m dev/agp/agp_if.m opencrypto/crypto_if.m
diff --git a/sys/dev/acpica5/Makefile b/sys/dev/acpica5/Makefile
--- a/sys/dev/acpica5/Makefile
+++ b/sys/dev/acpica5/Makefile
@@ -69,12 +69,14 @@ SRCS+=  acpi_package.c
 # SRCS+=	acpi_pci.c acpi_pcib.c acpi_pcib_acpi.c acpi_pcib_pci.c
 # SRCS+=	acpi_pci_link.c
 SRCS+=  acpi_powerres.c acpi_resource.c acpi_thermal.c
-SRCS+=  acpi_timer.c
+SRCS+=  acpi_timer.c acpi_if.c
 SRCS+=  OsdDebug.c
 SRCS+=  OsdHardware.c OsdInterface.c OsdInterrupt.c OsdMemory.c OsdSchedule.c
 SRCS+=  OsdStream.c OsdSynch.c OsdTable.c OsdEnvironment.c
 SRCS+=  opt_acpi.h opt_bus.h opt_ddb.h
-SRCS+=  device_if.h bus_if.h pci_if.h pcib_if.h isa_if.h
+SRCS+=  device_if.h bus_if.h pci_if.h pcib_if.h isa_if.h acpi_if.h
+MFILES = kern/device_if.m kern/bus_if.m bus/pci/pci_if.m bus/pci/pcib_if.m
+MFILES+= bus/isa/isa_if.m dev/acpica5/acpi_if.m
 
 # Debugging support
 DBSRC=	dbcmds.c dbdisply.c dbexec.c dbfileio.c dbhistry.c
diff --git a/sys/dev/acpica5/acpi.c b/sys/dev/acpica5/acpi.c
--- a/sys/dev/acpica5/acpi.c
+++ b/sys/dev/acpica5/acpi.c
@@ -135,6 +135,7 @@ static int	acpi_release_resource(device_
 			int rid, struct resource *r);
 static uint32_t	acpi_isa_get_logicalid(device_t dev);
 static int	acpi_isa_get_compatid(device_t dev, uint32_t *cids, int count);
+static char	*acpi_device_id_probe(device_t bus, device_t dev, char **ids);
 static int	acpi_isa_pnp_probe(device_t bus, device_t child,
 			struct isa_pnp_id *ids);
 static void	acpi_probe_children(device_t bus);
@@ -189,6 +190,9 @@ static device_method_t acpi_methods[] = 
     DEVMETHOD(bus_deactivate_resource,	bus_generic_deactivate_resource),
     DEVMETHOD(bus_setup_intr,		bus_generic_setup_intr),
     DEVMETHOD(bus_teardown_intr,	bus_generic_teardown_intr),
+
+    /* ACPI bus */
+    DEVMETHOD(acpi_id_probe,		acpi_device_id_probe),
 
     /* ISA emulation */
     DEVMETHOD(isa_pnp_probe,		acpi_isa_pnp_probe),
@@ -1121,6 +1125,24 @@ out:
 	AcpiOsFree(buf.Pointer);
     ACPI_UNLOCK;
     return_VALUE (valid);
+}
+
+static char *
+acpi_device_id_probe(device_t bus, device_t dev, char **ids) 
+{
+    ACPI_HANDLE h;
+    int i;
+
+    h = acpi_get_handle(dev);
+    if (ids == NULL || h == NULL || acpi_get_type(dev) != ACPI_TYPE_DEVICE)
+	return (NULL);
+
+    /* Try to match one of the array of IDs with a HID or CID. */
+    for (i = 0; ids[i] != NULL; i++) {
+	if (acpi_MatchHid(h, ids[i]))
+	    return (ids[i]);
+    }
+    return (NULL);
 }
 
 static int
diff --git a/sys/dev/acpica5/acpi_ec.c b/sys/dev/acpica5/acpi_ec.c
--- a/sys/dev/acpica5/acpi_ec.c
+++ b/sys/dev/acpica5/acpi_ec.c
@@ -327,11 +327,19 @@ static ACPI_STATUS	EcWrite(struct acpi_e
 				UINT8 *Data);
 static int		acpi_ec_probe(device_t dev);
 static int		acpi_ec_attach(device_t dev);
+static int		acpi_ec_read_method(device_t dev, u_int addr,
+				ACPI_INTEGER *val, int width);
+static int		acpi_ec_write_method(device_t dev, u_int addr,
+				ACPI_INTEGER val, int width);
 
 static device_method_t acpi_ec_methods[] = {
     /* Device interface */
     DEVMETHOD(device_probe,	acpi_ec_probe),
     DEVMETHOD(device_attach,	acpi_ec_attach),
+
+    /* Embedded controller interface */
+    DEVMETHOD(acpi_ec_read,     acpi_ec_read_method),
+    DEVMETHOD(acpi_ec_write,    acpi_ec_write_method),
 
     {0, 0}
 };
@@ -620,6 +628,33 @@ error:
 			     sc->ec_data_res);
     /* mtx_destroy(&sc->ec_mtx); */
     return (ENXIO);
+}
+
+/* Methods to allow other devices (e.g., smbat) to read/write EC space. */
+static int
+acpi_ec_read_method(device_t dev, u_int addr, ACPI_INTEGER *val, int width)
+{
+    struct acpi_ec_softc *sc;
+    ACPI_STATUS status;
+
+    sc = device_get_softc(dev);
+    status = EcSpaceHandler(ACPI_READ, addr, width * 8, val, sc, NULL);
+    if (ACPI_FAILURE(status))
+        return (ENXIO);
+    return (0);
+}
+
+static int
+acpi_ec_write_method(device_t dev, u_int addr, ACPI_INTEGER val, int width)
+{
+    struct acpi_ec_softc *sc;
+    ACPI_STATUS status;
+
+    sc = device_get_softc(dev);
+    status = EcSpaceHandler(ACPI_WRITE, addr, width * 8, &val, sc, NULL);
+    if (ACPI_FAILURE(status))
+        return (ENXIO);
+    return (0);
 }
 
 static void
diff --git a/sys/dev/acpica5/acpi_if.m b/sys/dev/acpica5/acpi_if.m
new file mode 100644
--- /dev/null
+++ b/sys/dev/acpica5/acpi_if.m
@@ -0,0 +1,92 @@
+#-
+# Copyright (c) 2004 Nate Lawson
+# All rights reserved.
+#
+# Redistribution and use in source and binary forms, with or without
+# modification, are permitted provided that the following conditions
+# are met:
+# 1. Redistributions of source code must retain the above copyright
+#    notice, this list of conditions and the following disclaimer.
+# 2. Redistributions in binary form must reproduce the above copyright
+#    notice, this list of conditions and the following disclaimer in the
+#    documentation and/or other materials provided with the distribution.
+#
+# THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
+# ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+# ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
+# FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+# DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+# OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+# HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+# LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+# OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+# SUCH DAMAGE.
+#
+# $DragonFly$
+#
+
+#include <sys/bus.h>
+#include <sys/types.h>
+#include "acpi.h"
+
+INTERFACE acpi;
+
+#
+# Default implementation for acpi_id_probe().
+#
+CODE {
+	static char *
+	acpi_generic_id_probe(device_t bus, device_t dev, char **ids)
+	{
+		return (NULL);
+	}
+};
+
+#
+# Check a device for a match in a list of ID strings.  The strings can be
+# EISA PNP IDs or ACPI _HID/_CID values.
+#
+# device_t bus:  parent bus for the device
+#
+# device_t dev:  device being considered
+#
+# char **ids:  array of ID strings to consider
+#
+# Returns:  ID string matched or NULL if no match
+#
+METHOD char * id_probe {
+	device_t	bus;
+	device_t	dev;
+	char		**ids;
+} DEFAULT acpi_generic_id_probe;
+
+#
+# Read embedded controller (EC) address space
+#
+# device_t dev:  EC device
+# u_int addr:  Address to read from in EC space
+# ACPI_INTEGER *val:  Location to store read value
+# int width:  Size of area to read in bytes
+#
+METHOD int ec_read {
+	device_t	dev;
+	u_int		addr;
+	ACPI_INTEGER	*val;
+	int		width;
+};
+
+#
+# Write embedded controller (EC) address space
+#
+# device_t dev:  EC device
+# u_int addr:  Address to write to in EC space
+# ACPI_INTEGER val:  Value to write
+# int width:  Size of value to write in bytes
+#
+METHOD int ec_write {
+	device_t	dev;
+	u_int		addr;
+	ACPI_INTEGER	val;
+	int		width;
+};
diff --git a/sys/dev/acpica5/acpivar.h b/sys/dev/acpica5/acpivar.h
--- a/sys/dev/acpica5/acpivar.h
+++ b/sys/dev/acpica5/acpivar.h
@@ -29,6 +29,7 @@
  * $DragonFly: src/sys/dev/acpica5/acpivar.h,v 1.12 2007/10/23 03:04:48 y0netan1 Exp $
  */
 
+#include "acpi_if.h"
 #include "bus_if.h"
 #include <sys/eventhandler.h>
 #include <sys/sysctl.h>
# HG changeset patch
# User Hasso Tepper <hasso at estpak.ee>
# Date 1205995474 -7200
# Branch HEAD
# Node ID c5db8d4a7c6b25a8576a8d42c5029aaf0e23bfb6
# Parent  5a6e2705cc95a340abf973ae5df73ef34e070b79
[mq]: adding-acpi-thinkpad.patch

diff --git a/sys/dev/acpica5/Makefile b/sys/dev/acpica5/Makefile
--- a/sys/dev/acpica5/Makefile
+++ b/sys/dev/acpica5/Makefile
@@ -117,7 +117,7 @@ acpi_wakecode.h: acpi_wakecode.S
 	${MAKE} -f ${SYSDIR}/${OSACPI_MD_DIR}/Makefile \
 		MAKESRCPATH=${SYSDIR}/${OSACPI_MD_DIR}
 
-SUBDIR=	acpi_toshiba
+SUBDIR=	acpi_toshiba acpi_thinkpad
 all: ${PROG} ${SUBDIR}
 
 # *.o file for each patched *.c file is created under the same directory,
diff --git a/sys/dev/acpica5/acpi_thinkpad/Makefile b/sys/dev/acpica5/acpi_thinkpad/Makefile
new file mode 100644
--- /dev/null
+++ b/sys/dev/acpica5/acpi_thinkpad/Makefile
@@ -0,0 +1,9 @@
+# $DragonFly$
+
+SYSDIR?=${.CURDIR}/../../..
+
+KMOD=		acpi_thinkpad
+CFLAGS+=	-I${.OBJDIR}/.. -I${.CURDIR}/..
+SRCS=		acpi_thinkpad.c opt_acpi.h device_if.h bus_if.h
+
+.include <bsd.kmod.mk>
diff --git a/sys/dev/acpica5/acpi_thinkpad/acpi_thinkpad.c b/sys/dev/acpica5/acpi_thinkpad/acpi_thinkpad.c
new file mode 100644
--- /dev/null
+++ b/sys/dev/acpica5/acpi_thinkpad/acpi_thinkpad.c
@@ -0,0 +1,1046 @@
+/*
+ * Copyright (c) 2004 Takanori Watanabe
+ * Copyright (c) 2005 Markus Brueffer <markus at FreeBSD.org>
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *    notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *    notice, this list of conditions and the following disclaimer in the
+ *    documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+ */
+
+/*
+ * Driver for extra ACPI-controlled gadgets found on IBM and Lenovo ThinkPad
+ * laptops. Inspired by the ibm-acpi and tpb projects which implement these
+ * features on Linux.
+ *
+ *   acpi-ibm: <http://ibm-acpi.sourceforge.net/>
+ *        tpb: <http://www.nongnu.org/tpb/>
+ */
+
+#include "opt_acpi.h"
+#include <sys/param.h>
+#include <sys/kernel.h>
+#include <sys/bus.h>
+#include <machine/cpufunc.h>
+#include <sys/module.h>
+/* #include <dev/led/led.h> */
+#include <sys/sensors.h>
+#include <sys/sysctl.h>
+#include <machine/clock.h>
+
+#include "acpi.h"
+#include "acpivar.h"
+#include "acpi_if.h"
+
+#define _COMPONENT	ACPI_OEM
+ACPI_MODULE_NAME("THINKPAD")
+
+/* Internal methods */
+#define ACPI_THINKPAD_METHOD_EVENTS		1
+#define ACPI_THINKPAD_METHOD_EVENTMASK		2
+#define ACPI_THINKPAD_METHOD_HOTKEY		3
+#define ACPI_THINKPAD_METHOD_BRIGHTNESS		4
+#define ACPI_THINKPAD_METHOD_VOLUME		5
+#define ACPI_THINKPAD_METHOD_MUTE		6
+#define ACPI_THINKPAD_METHOD_THINKLIGHT		7
+#define ACPI_THINKPAD_METHOD_BLUETOOTH		8
+#define ACPI_THINKPAD_METHOD_WLAN		9
+#define ACPI_THINKPAD_METHOD_FANSPEED		10
+#define ACPI_THINKPAD_METHOD_FANLEVEL		11
+#define ACPI_THINKPAD_METHOD_FANSTATUS		12
+#define ACPI_THINKPAD_METHOD_THERMAL		13
+
+/* Hotkeys/Buttons */
+#define THINKPAD_RTC_HOTKEY1			0x64
+#define   THINKPAD_RTC_MASK_HOME		(1 << 0)
+#define   THINKPAD_RTC_MASK_SEARCH		(1 << 1)
+#define   THINKPAD_RTC_MASK_MAIL		(1 << 2)
+#define   THINKPAD_RTC_MASK_WLAN		(1 << 5)
+#define THINKPAD_RTC_HOTKEY2			0x65
+#define   THINKPAD_RTC_MASK_THINKPAD		(1 << 3)
+#define   THINKPAD_RTC_MASK_ZOOM		(1 << 5)
+#define   THINKPAD_RTC_MASK_VIDEO		(1 << 6)
+#define   THINKPAD_RTC_MASK_HIBERNATE		(1 << 7)
+#define THINKPAD_RTC_THINKLIGHT			0x66
+#define   THINKPAD_RTC_MASK_THINKLIGHT		(1 << 4)
+#define THINKPAD_RTC_SCREENEXPAND		0x67
+#define   THINKPAD_RTC_MASK_SCREENEXPAND	(1 << 5)
+#define THINKPAD_RTC_BRIGHTNESS			0x6c
+#define   THINKPAD_RTC_MASK_BRIGHTNESS		(1 << 5)
+#define THINKPAD_RTC_VOLUME			0x6e
+#define   THINKPAD_RTC_MASK_VOLUME		(1 << 7)
+
+/* Embedded Controller registers */
+#define THINKPAD_EC_BRIGHTNESS			0x31
+#define   THINKPAD_EC_MASK_BRI			0x7
+#define THINKPAD_EC_VOLUME			0x30
+#define   THINKPAD_EC_MASK_VOL			0xf
+#define   THINKPAD_EC_MASK_MUTE			(1 << 6)
+#define THINKPAD_EC_FANSTATUS			0x2F
+#define   THINKPAD_EC_MASK_FANLEVEL		0x3f
+#define   THINKPAD_EC_MASK_FANDISENGAGED	(1 << 6)
+#define   THINKPAD_EC_MASK_FANSTATUS		(1 << 7)
+#define THINKPAD_EC_FANSPEED			0x84
+
+/* CMOS Commands */
+#define THINKPAD_CMOS_VOLUME_DOWN		0
+#define THINKPAD_CMOS_VOLUME_UP			1
+#define THINKPAD_CMOS_VOLUME_MUTE		2
+#define THINKPAD_CMOS_BRIGHTNESS_UP		4
+#define THINKPAD_CMOS_BRIGHTNESS_DOWN		5
+
+/* ACPI methods */
+#define THINKPAD_NAME_KEYLIGHT			"KBLT"
+#define THINKPAD_NAME_WLAN_BT_GET		"GBDC"
+#define THINKPAD_NAME_WLAN_BT_SET		"SBDC"
+#define   THINKPAD_NAME_MASK_BT			(1 << 1)
+#define   THINKPAD_NAME_MASK_WLAN		(1 << 2)
+#define THINKPAD_NAME_THERMAL_GET		"TMP7"
+#define THINKPAD_NAME_THERMAL_UPDT		"UPDT"
+
+#define THINKPAD_NAME_EVENTS_STATUS_GET		"DHKC"
+#define THINKPAD_NAME_EVENTS_MASK_GET		"DHKN"
+#define THINKPAD_NAME_EVENTS_STATUS_SET		"MHKC"
+#define THINKPAD_NAME_EVENTS_MASK_SET		"MHKM"
+#define THINKPAD_NAME_EVENTS_GET		"MHKP"
+#define THINKPAD_NAME_EVENTS_AVAILMASK		"MHKA"
+
+#define ABS(x) (((x) < 0)? -(x) : (x))
+
+struct acpi_thinkpad_softc {
+	device_t	dev;
+	ACPI_HANDLE	handle;
+
+	/* Embedded controller */
+	device_t	ec_dev;
+	ACPI_HANDLE	ec_handle;
+
+	/* CMOS */
+	ACPI_HANDLE	cmos_handle;
+
+	/* Fan status */
+	ACPI_HANDLE	fan_handle;
+	int		fan_levels;
+
+	/* Keylight commands and states */
+	ACPI_HANDLE	light_handle;
+	int		light_cmd_on;
+	int		light_cmd_off;
+	int		light_val;
+	int		light_get_supported;
+	int		light_set_supported;
+
+	/* led(4) interface */
+	struct cdev	*led_dev;
+	int		led_busy;
+	int		led_state;
+
+	int		wlan_bt_flags;
+	int		thermal_updt_supported;
+
+	unsigned int	events_availmask;
+	unsigned int	events_initialmask;
+	int		events_mask_supported;
+	int		events_enable;
+
+	/* sensors(9) related */
+	struct ksensordev sensordev;
+	struct ksensor sensors[9];	/* XXX: 8 thermal + fan */
+
+	struct sysctl_ctx_list	*sysctl_ctx;
+	struct sysctl_oid	*sysctl_tree;
+};
+
+static struct {
+	char	*name;
+	int	method;
+	char	*description;
+	int	access;
+} acpi_thinkpad_sysctls[] = {
+	{
+		.name		= "events",
+		.method		= ACPI_THINKPAD_METHOD_EVENTS,
+		.description	= "ACPI events enable",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "eventmask",
+		.method		= ACPI_THINKPAD_METHOD_EVENTMASK,
+		.description	= "ACPI eventmask",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "hotkey",
+		.method		= ACPI_THINKPAD_METHOD_HOTKEY,
+		.description	= "Key Status",
+		.access		= CTLTYPE_INT | CTLFLAG_RD
+	},
+	{
+		.name		= "lcd_brightness",
+		.method		= ACPI_THINKPAD_METHOD_BRIGHTNESS,
+		.description	= "LCD Brightness",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "volume",
+		.method		= ACPI_THINKPAD_METHOD_VOLUME,
+		.description	= "Volume",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "mute",
+		.method		= ACPI_THINKPAD_METHOD_MUTE,
+		.description	= "Mute",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "thinklight",
+		.method		= ACPI_THINKPAD_METHOD_THINKLIGHT,
+		.description	= "Thinklight enable",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "bluetooth",
+		.method		= ACPI_THINKPAD_METHOD_BLUETOOTH,
+		.description	= "Bluetooth enable",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "wlan",
+		.method		= ACPI_THINKPAD_METHOD_WLAN,
+		.description	= "WLAN enable",
+		.access		= CTLTYPE_INT | CTLFLAG_RD
+	},
+	{
+		.name		= "fan_level",
+		.method		= ACPI_THINKPAD_METHOD_FANLEVEL,
+		.description	= "Fan level",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "fan",
+		.method		= ACPI_THINKPAD_METHOD_FANSTATUS,
+		.description	= "Fan enable",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+
+	{ NULL, 0, NULL, 0 }
+};
+
+/* ACPI_SERIAL_DECL(thinkpad, "ACPI THINKPAD extras"); */
+static int	acpi_thinkpad_probe(device_t dev);
+static int	acpi_thinkpad_attach(device_t dev);
+static int	acpi_thinkpad_detach(device_t dev);
+
+#if 0 /* not yet */
+static void	thinkpad_led(void *softc, int onoff);
+static void	thinkpad_led_task(struct acpi_thinkpad_softc *sc,
+		int pending __unused);
+#endif
+
+static int	acpi_thinkpad_sysctl(SYSCTL_HANDLER_ARGS);
+static int	acpi_thinkpad_sysctl_init(struct acpi_thinkpad_softc *sc,
+		int method);
+static int	acpi_thinkpad_sysctl_get(struct acpi_thinkpad_softc *sc,
+		int method);
+static int	acpi_thinkpad_sysctl_set(struct acpi_thinkpad_softc *sc,
+		int method, int val);
+
+static int	acpi_thinkpad_eventmask_set(struct acpi_thinkpad_softc *sc,
+		int val);
+static void	acpi_thinkpad_notify(ACPI_HANDLE h, UINT32 notify,
+		void *context);
+static void	acpi_thinkpad_refresh(void *);
+
+static device_method_t acpi_thinkpad_methods[] = {
+	/* Device interface */
+	DEVMETHOD(device_probe, acpi_thinkpad_probe),
+	DEVMETHOD(device_attach, acpi_thinkpad_attach),
+	DEVMETHOD(device_detach, acpi_thinkpad_detach),
+	{0, 0}
+};
+
+static driver_t	acpi_thinkpad_driver = {
+	"acpi_thinkpad",
+	acpi_thinkpad_methods,
+	sizeof(struct acpi_thinkpad_softc),
+};
+
+static devclass_t acpi_thinkpad_devclass;
+
+DRIVER_MODULE(acpi_thinkpad, acpi, acpi_thinkpad_driver,
+    acpi_thinkpad_devclass, 0, 0);
+MODULE_DEPEND(acpi_thinkpad, acpi, 1, 1, 1);
+static char    *thinkpad_ids[] = {"IBM0068", NULL};
+
+#if 0 /* not yet */
+static void
+thinkpad_led(void *softc, int onoff)
+{
+	struct acpi_thinkpad_softc* sc = (struct acpi_thinkpad_softc*) softc;
+
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+
+	if (sc->led_busy)
+		return;
+
+	sc->led_busy = 1;
+	sc->led_state = onoff;
+
+	AcpiOsExecute(OSL_NOTIFY_HANDLER, (void *)thinkpad_led_task, sc);
+}
+
+static void
+thinkpad_led_task(struct acpi_thinkpad_softc *sc, int pending __unused)
+{
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+
+	/* ACPI_SERIAL_BEGIN(thinkpad); */
+	acpi_thinkpad_sysctl_set(sc, ACPI_THINKPAD_METHOD_THINKLIGHT, sc->led_state);
+	/* ACPI_SERIAL_END(thinkpad); */
+
+	sc->led_busy = 0;
+}
+#endif
+
+static int
+acpi_thinkpad_probe(device_t dev)
+{
+	if (acpi_disabled("thinkpad") ||
+	    ACPI_ID_PROBE(device_get_parent(dev), dev, thinkpad_ids) == NULL ||
+	    device_get_unit(dev) != 0) 
+		return (ENXIO);
+
+	device_set_desc(dev, "IBM/Lenovo ThinkPad ACPI Extras");
+	return (0);
+}
+
+static int
+acpi_thinkpad_attach(device_t dev)
+{
+	struct acpi_thinkpad_softc	*sc;
+	struct acpi_softc	*acpi_sc;
+	devclass_t		ec_devclass;
+	int			i;
+
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t) __func__);
+
+	sc = device_get_softc(dev);
+	sc->dev = dev;
+	sc->handle = acpi_get_handle(dev);
+
+	acpi_sc = acpi_device_get_parent_softc(dev);
+
+	/* Look for the first embedded controller */
+        if (!(ec_devclass = devclass_find ("acpi_ec"))) {
+		if (bootverbose)
+			device_printf(dev, "Couldn't find acpi_ec devclass\n");
+		return (EINVAL);
+	}
+        if (!(sc->ec_dev = devclass_get_device(ec_devclass, 0))) {
+		if (bootverbose)
+			device_printf(dev, "Couldn't find acpi_ec device\n");
+		return (EINVAL);
+	}
+	sc->ec_handle = acpi_get_handle(sc->ec_dev);
+
+	/* ACPI_SERIAL_BEGIN(thinkpad); */
+
+#if 0
+	/* Get the sysctl tree */
+	sc->sysctl_ctx = device_get_sysctl_ctx(dev);
+	sc->sysctl_tree = device_get_sysctl_tree(dev);
+#endif
+	sysctl_ctx_init(sc->sysctl_ctx);
+	sc->sysctl_tree = SYSCTL_ADD_NODE(sc->sysctl_ctx,
+	    SYSCTL_CHILDREN(acpi_sc->acpi_sysctl_tree), OID_AUTO,
+	    "thinkpad", CTLFLAG_RD, 0, "");
+
+	/* Look for event mask and hook up the nodes */
+	sc->events_mask_supported = ACPI_SUCCESS(acpi_GetInteger(sc->handle,
+	    THINKPAD_NAME_EVENTS_MASK_GET, &sc->events_initialmask));
+
+	if (sc->events_mask_supported) {
+		SYSCTL_ADD_INT(sc->sysctl_ctx,
+		    SYSCTL_CHILDREN(sc->sysctl_tree), OID_AUTO,
+		    "initialmask", CTLFLAG_RD,
+		    &sc->events_initialmask, 0, "Initial eventmask");
+
+		/* The availmask is the bitmask of supported events */
+		if (ACPI_FAILURE(acpi_GetInteger(sc->handle,
+		    THINKPAD_NAME_EVENTS_AVAILMASK, &sc->events_availmask)))
+			sc->events_availmask = 0xffffffff;
+
+		SYSCTL_ADD_INT(sc->sysctl_ctx,
+		    SYSCTL_CHILDREN(sc->sysctl_tree), OID_AUTO,
+		    "availmask", CTLFLAG_RD,
+		    &sc->events_availmask, 0, "Mask of supported events");
+	}
+
+	/* Hook up proc nodes */
+	for (i = 0; acpi_thinkpad_sysctls[i].name != NULL; i++) {
+		if (!acpi_thinkpad_sysctl_init(sc,
+		    acpi_thinkpad_sysctls[i].method))
+			continue;
+
+		SYSCTL_ADD_PROC(sc->sysctl_ctx,
+		    SYSCTL_CHILDREN(sc->sysctl_tree), OID_AUTO,
+		    acpi_thinkpad_sysctls[i].name,
+		    acpi_thinkpad_sysctls[i].access,
+		    sc, i, acpi_thinkpad_sysctl, "I",
+		    acpi_thinkpad_sysctls[i].description);
+	}
+
+	/* ACPI_SERIAL_END(thinkpad); */
+
+	/* Handle notifies */
+	AcpiInstallNotifyHandler(sc->handle, ACPI_DEVICE_NOTIFY,
+	    acpi_thinkpad_notify, dev);
+
+#if 0
+	/* Hook up light to led(4) */
+	if (sc->light_set_supported)
+		sc->led_dev = led_create_state(thinkpad_led, sc, "thinklight",
+		    sc->light_val);
+#endif
+	/* Attach sensors(9). */
+	if (sensor_task_register(sc, acpi_thinkpad_refresh, 5)) {
+		device_printf(sc->dev, "unable to register update task\n");
+		return 1;
+	}
+
+	strlcpy(sc->sensordev.xname, device_get_nameunit(sc->dev),
+	    sizeof(sc->sensordev.xname));
+
+	/* XXX: Temp sensors */
+	for (i = 0; i < 8; ++i) {
+		sc->sensors[i].type = SENSOR_TEMP;
+		sensor_attach(&sc->sensordev, &sc->sensors[i]);
+	}
+	
+	/* Fan RPM sensor */
+	sc->sensors[8].type = SENSOR_FANRPM;
+	sensor_attach(&sc->sensordev, &sc->sensors[8]);
+
+	sensordev_install(&sc->sensordev);
+
+	return (0);
+}
+
+static int
+acpi_thinkpad_detach(device_t dev)
+{
+	int i;
+
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t) __func__);
+
+	struct acpi_thinkpad_softc *sc = device_get_softc(dev);
+
+	/* Disable events and restore eventmask */
+	/* ACPI_SERIAL_BEGIN(thinkpad); */
+	acpi_thinkpad_sysctl_set(sc, ACPI_THINKPAD_METHOD_EVENTS, 0);
+	acpi_thinkpad_sysctl_set(sc, ACPI_THINKPAD_METHOD_EVENTMASK,
+	    sc->events_initialmask);
+	/* ACPI_SERIAL_END(thinkpad); */
+
+	AcpiRemoveNotifyHandler(sc->handle, ACPI_DEVICE_NOTIFY,
+	    acpi_thinkpad_notify);
+
+	sysctl_ctx_free(sc->sysctl_ctx);
+
+#if 0
+	if (sc->led_dev != NULL)
+		led_destroy(sc->led_dev);
+#endif
+	sensordev_deinstall(&sc->sensordev);
+	for (i = 0; i < 9; i++)
+		sensor_detach(&sc->sensordev, &sc->sensors[i]);
+	sensor_task_unregister(sc);
+
+	return (0);
+}
+
+static int
+acpi_thinkpad_eventmask_set(struct acpi_thinkpad_softc *sc, int val)
+{
+	int i;
+	ACPI_OBJECT		arg[2];
+	ACPI_OBJECT_LIST	args;
+	ACPI_STATUS		status;
+
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+	/* ACPI_SERIAL_ASSERT(thinkpad); */
+
+	args.Count = 2;
+	args.Pointer = arg;
+	arg[0].Type = ACPI_TYPE_INTEGER;
+	arg[1].Type = ACPI_TYPE_INTEGER;
+
+	for (i = 0; i < 32; ++i) {
+		arg[0].Integer.Value = i+1;
+		arg[1].Integer.Value = (((1 << i) & val) != 0);
+		status = AcpiEvaluateObject(sc->handle,
+		    THINKPAD_NAME_EVENTS_MASK_SET, &args, NULL);
+
+		if (ACPI_FAILURE(status))
+			return (status);
+	}
+
+	return (0);
+}
+
+static int
+acpi_thinkpad_sysctl(SYSCTL_HANDLER_ARGS)
+{
+	struct acpi_thinkpad_softc	*sc;
+	int			arg;
+	int			error = 0;
+	int			function;
+	int			method;
+	
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+
+	sc = (struct acpi_thinkpad_softc *)oidp->oid_arg1;
+	function = oidp->oid_arg2;
+	method = acpi_thinkpad_sysctls[function].method;
+
+	/* ACPI_SERIAL_BEGIN(thinkpad); */
+	arg = acpi_thinkpad_sysctl_get(sc, method);
+	error = sysctl_handle_int(oidp, &arg, 0, req);
+
+	/* Sanity check */
+	if (error != 0 || req->newptr == NULL)
+		goto out;
+
+	/* Update */
+	error = acpi_thinkpad_sysctl_set(sc, method, arg);
+
+out:
+	/* ACPI_SERIAL_END(thinkpad); */
+	return (error);
+}
+
+static int
+acpi_thinkpad_sysctl_get(struct acpi_thinkpad_softc *sc, int method)
+{
+	ACPI_INTEGER	val_ec;
+	int 		val = 0, key;
+
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+	/* ACPI_SERIAL_ASSERT(thinkpad); */
+
+	switch (method) {
+	case ACPI_THINKPAD_METHOD_EVENTS:
+		acpi_GetInteger(sc->handle, THINKPAD_NAME_EVENTS_STATUS_GET,
+		    &val);
+		break;
+
+	case ACPI_THINKPAD_METHOD_EVENTMASK:
+		if (sc->events_mask_supported)
+			acpi_GetInteger(sc->handle,
+			    THINKPAD_NAME_EVENTS_MASK_GET, &val);
+		break;
+
+	case ACPI_THINKPAD_METHOD_HOTKEY:
+		/*
+		 * Construct the hotkey as a bitmask as illustrated below.
+		 * Note that whenever a key was pressed, the respecting bit
+		 * toggles and nothing else changes.
+		 * +--+--+-+-+-+-+-+-+-+-+-+-+
+		 * |11|10|9|8|7|6|5|4|3|2|1|0|
+		 * +--+--+-+-+-+-+-+-+-+-+-+-+
+		 *   |  | | | | | | | | | | |
+		 *   |  | | | | | | | | | | +- Home Button
+		 *   |  | | | | | | | | | +--- Search Button
+		 *   |  | | | | | | | | +----- Mail Button
+		 *   |  | | | | | | | +------- Thinkpad Button
+		 *   |  | | | | | | +--------- Zoom (Fn + Space)
+		 *   |  | | | | | +----------- WLAN Button
+		 *   |  | | | | +------------- Video Button
+		 *   |  | | | +--------------- Hibernate Button
+		 *   |  | | +----------------- Thinklight Button
+		 *   |  | +------------------- Screen expand (Fn + F8)
+		 *   |  +--------------------- Brightness
+		 *   +------------------------ Volume/Mute
+		 */
+		key = rtcin(THINKPAD_RTC_HOTKEY1);
+		val = (THINKPAD_RTC_MASK_HOME | THINKPAD_RTC_MASK_SEARCH |
+		    THINKPAD_RTC_MASK_MAIL | THINKPAD_RTC_MASK_WLAN) & key;
+		key = rtcin(THINKPAD_RTC_HOTKEY2);
+		val |= (THINKPAD_RTC_MASK_THINKPAD | THINKPAD_RTC_MASK_VIDEO |
+		    THINKPAD_RTC_MASK_HIBERNATE) & key;
+		val |= (THINKPAD_RTC_MASK_ZOOM & key) >> 1;
+		key = rtcin(THINKPAD_RTC_THINKLIGHT);
+		val |= (THINKPAD_RTC_MASK_THINKLIGHT & key) << 4;
+		key = rtcin(THINKPAD_RTC_SCREENEXPAND);
+		val |= (THINKPAD_RTC_MASK_THINKLIGHT & key) << 4;
+		key = rtcin(THINKPAD_RTC_BRIGHTNESS);
+		val |= (THINKPAD_RTC_MASK_BRIGHTNESS & key) << 5;
+		key = rtcin(THINKPAD_RTC_VOLUME);
+		val |= (THINKPAD_RTC_MASK_VOLUME & key) << 4;
+		break;
+
+	case ACPI_THINKPAD_METHOD_BRIGHTNESS:
+		ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_BRIGHTNESS, &val_ec, 1);
+		val = val_ec & THINKPAD_EC_MASK_BRI;
+		break;
+
+	case ACPI_THINKPAD_METHOD_VOLUME:
+		ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_VOLUME, &val_ec, 1);
+		val = val_ec & THINKPAD_EC_MASK_VOL;
+		break;
+
+	case ACPI_THINKPAD_METHOD_MUTE:
+		val = ((val_ec & THINKPAD_EC_MASK_MUTE) ==
+		    THINKPAD_EC_MASK_MUTE);
+		break;
+
+	case ACPI_THINKPAD_METHOD_THINKLIGHT:
+		if (sc->light_get_supported)
+			acpi_GetInteger(sc->ec_handle, THINKPAD_NAME_KEYLIGHT,
+			    &val);
+		else
+			val = sc->light_val;
+		break;
+
+	case ACPI_THINKPAD_METHOD_BLUETOOTH:
+		acpi_GetInteger(sc->handle, THINKPAD_NAME_WLAN_BT_GET, &val);
+		sc->wlan_bt_flags = val;
+		val = ((val & THINKPAD_NAME_MASK_BT) != 0);
+		break;
+
+	case ACPI_THINKPAD_METHOD_WLAN:
+		acpi_GetInteger(sc->handle, THINKPAD_NAME_WLAN_BT_GET, &val);
+		sc->wlan_bt_flags = val;
+		val = ((val & THINKPAD_NAME_MASK_WLAN) != 0);
+		break;
+
+	case ACPI_THINKPAD_METHOD_FANSPEED:
+		if (sc->fan_handle) {
+			if (ACPI_FAILURE(acpi_GetInteger(sc->fan_handle,
+			    NULL, &val)))
+				val = -1;
+		}
+		else {
+			ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_FANSPEED,
+			    &val_ec, 2);
+			val = val_ec;
+		}
+		break;
+
+	case ACPI_THINKPAD_METHOD_FANLEVEL:
+		/*
+		 * The THINKPAD_EC_FANSTATUS register works as follows:
+		 * Bit 0-5 indicate the level at which the fan operates. Only
+		 *       values between 0 and 7 have an effect. Everything
+		 *       above 7 is treated the same as level 7
+		 * Bit 6 overrides the fan speed limit if set to 1
+		 * Bit 7 indicates at which mode the fan operates:
+		 *       manual (0) or automatic (1)
+		 */
+		if (!sc->fan_handle) {
+			ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_FANSTATUS,
+			    &val_ec, 1);
+			val = val_ec & THINKPAD_EC_MASK_FANLEVEL;
+		}
+		break;
+
+	case ACPI_THINKPAD_METHOD_FANSTATUS:
+		if (!sc->fan_handle) {
+			ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_FANSTATUS,
+			    &val_ec, 1);
+			val = (val_ec & THINKPAD_EC_MASK_FANSTATUS) ==
+			    THINKPAD_EC_MASK_FANSTATUS;
+		}
+		else
+			val = -1;
+		break;
+	}
+
+	return (val);
+}
+
+static int
+acpi_thinkpad_sysctl_set(struct acpi_thinkpad_softc *sc, int method, int arg)
+{
+	int			val, step, i;
+	ACPI_INTEGER		val_ec;
+	ACPI_OBJECT		Arg;
+	ACPI_OBJECT_LIST	Args;
+	ACPI_STATUS		status;
+
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+	/* ACPI_SERIAL_ASSERT(thinkpad); */
+
+	switch (method) {
+	case ACPI_THINKPAD_METHOD_EVENTS:
+		if (arg < 0 || arg > 1)
+			return (EINVAL);
+
+		status = acpi_SetInteger(sc->handle,
+		    THINKPAD_NAME_EVENTS_STATUS_SET, arg);
+		if (ACPI_FAILURE(status))
+			return (status);
+		if (sc->events_mask_supported)
+			return acpi_thinkpad_eventmask_set(sc,
+			    sc->events_availmask);
+		break;
+
+	case ACPI_THINKPAD_METHOD_EVENTMASK:
+		if (sc->events_mask_supported)
+			return acpi_thinkpad_eventmask_set(sc, arg);
+		break;
+
+	case ACPI_THINKPAD_METHOD_BRIGHTNESS:
+		if (arg < 0 || arg > 7)
+			return (EINVAL);
+
+		if (sc->cmos_handle) {
+			/* Read the current brightness */
+			status = ACPI_EC_READ(sc->ec_dev,
+			    THINKPAD_EC_BRIGHTNESS, &val_ec, 1);
+			if (ACPI_FAILURE(status))
+				return (status);
+			val = val_ec & THINKPAD_EC_MASK_BRI;
+
+			Args.Count = 1;
+			Args.Pointer = &Arg;
+			Arg.Type = ACPI_TYPE_INTEGER;
+			Arg.Integer.Value = (arg > val) ?
+			    THINKPAD_CMOS_BRIGHTNESS_UP :
+			    THINKPAD_CMOS_BRIGHTNESS_DOWN;
+
+			step = (arg > val) ? 1 : -1;
+			for (i = val; i != arg; i += step) {
+				status = AcpiEvaluateObject(sc->cmos_handle,
+				    NULL, &Args, NULL);
+				if (ACPI_FAILURE(status))
+					break;
+			}
+		}
+		return ACPI_EC_WRITE(sc->ec_dev, THINKPAD_EC_BRIGHTNESS,
+		    arg, 1);
+		break;
+
+	case ACPI_THINKPAD_METHOD_VOLUME:
+		if (arg < 0 || arg > 14)
+			return (EINVAL);
+
+		status = ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_VOLUME,
+		    &val_ec, 1);
+		if (ACPI_FAILURE(status))
+			return (status);
+
+		if (sc->cmos_handle) {
+			val = val_ec & THINKPAD_EC_MASK_VOL;
+
+			Args.Count = 1;
+			Args.Pointer = &Arg;
+			Arg.Type = ACPI_TYPE_INTEGER;
+			Arg.Integer.Value = (arg > val) ?
+			    THINKPAD_CMOS_VOLUME_UP : THINKPAD_CMOS_VOLUME_DOWN;
+
+			step = (arg > val) ? 1 : -1;
+			for (i = val; i != arg; i += step) {
+				status = AcpiEvaluateObject(sc->cmos_handle,
+				    NULL, &Args, NULL);
+				if (ACPI_FAILURE(status))
+					break;
+			}
+		}
+		return ACPI_EC_WRITE(sc->ec_dev, THINKPAD_EC_VOLUME, arg +
+		    (val_ec & (~THINKPAD_EC_MASK_VOL)), 1);
+		break;
+
+	case ACPI_THINKPAD_METHOD_MUTE:
+		if (arg < 0 || arg > 1)
+			return (EINVAL);
+
+		status = ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_VOLUME,
+		    &val_ec, 1);
+		if (ACPI_FAILURE(status))
+			return (status);
+
+		if (sc->cmos_handle) {
+			val = val_ec & THINKPAD_EC_MASK_VOL;
+
+			Args.Count = 1;
+			Args.Pointer = &Arg;
+			Arg.Type = ACPI_TYPE_INTEGER;
+			Arg.Integer.Value = THINKPAD_CMOS_VOLUME_MUTE;
+
+			status = AcpiEvaluateObject(sc->cmos_handle, NULL,
+			    &Args, NULL);
+			if (ACPI_FAILURE(status))
+				break;
+		}
+		return ACPI_EC_WRITE(sc->ec_dev, THINKPAD_EC_VOLUME, (arg==1) ?
+		   val_ec | THINKPAD_EC_MASK_MUTE :
+		   val_ec & (~THINKPAD_EC_MASK_MUTE), 1);
+		break;
+
+	case ACPI_THINKPAD_METHOD_THINKLIGHT:
+		if (arg < 0 || arg > 1)
+			return (EINVAL);
+
+		if (sc->light_set_supported) {
+			Args.Count = 1;
+			Args.Pointer = &Arg;
+			Arg.Type = ACPI_TYPE_INTEGER;
+			Arg.Integer.Value = arg ?
+			    sc->light_cmd_on : sc->light_cmd_off;
+
+			status = AcpiEvaluateObject(sc->light_handle, NULL,
+			    &Args, NULL);
+			if (ACPI_SUCCESS(status))
+				sc->light_val = arg;
+			return (status);
+		}
+		break;
+
+	case ACPI_THINKPAD_METHOD_BLUETOOTH:
+		if (arg < 0 || arg > 1)
+			return (EINVAL);
+
+		val = (arg == 1) ? sc->wlan_bt_flags |
+		    THINKPAD_NAME_MASK_BT :
+		    sc->wlan_bt_flags & (~THINKPAD_NAME_MASK_BT);
+		return acpi_SetInteger(sc->handle, THINKPAD_NAME_WLAN_BT_SET,
+		    val);
+		break;
+
+	case ACPI_THINKPAD_METHOD_FANLEVEL:
+		if (arg < 0 || arg > 7)
+			return (EINVAL);
+
+		if (!sc->fan_handle) {
+			/* Read the current fanstatus */
+			ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_FANSTATUS,
+			    &val_ec, 1);
+			val = val_ec & (~THINKPAD_EC_MASK_FANLEVEL);
+
+			return ACPI_EC_WRITE(sc->ec_dev, THINKPAD_EC_FANSTATUS,
+			    val | arg, 1);
+		}
+		break;
+
+	case ACPI_THINKPAD_METHOD_FANSTATUS:
+		if (arg < 0 || arg > 1)
+			return (EINVAL);
+
+		if (!sc->fan_handle) {
+			/* Read the current fanstatus */
+			ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_FANSTATUS,
+			    &val_ec, 1);
+
+			return ACPI_EC_WRITE(sc->ec_dev, THINKPAD_EC_FANSTATUS,
+			    (arg == 1) ? (val_ec | THINKPAD_EC_MASK_FANSTATUS) :
+			    (val_ec & (~THINKPAD_EC_MASK_FANSTATUS)), 1);
+		}
+		break;
+	}
+
+	return (0);
+}
+
+static int
+acpi_thinkpad_sysctl_init(struct acpi_thinkpad_softc *sc, int method)
+{
+	int 			dummy;
+	ACPI_OBJECT_TYPE 	cmos_t;
+	ACPI_HANDLE		ledb_handle;
+
+	switch (method) {
+	case ACPI_THINKPAD_METHOD_EVENTS:
+		/* Events are disabled by default */
+		return (TRUE);
+
+	case ACPI_THINKPAD_METHOD_EVENTMASK:
+		return (sc->events_mask_supported);
+
+	case ACPI_THINKPAD_METHOD_HOTKEY:
+	case ACPI_THINKPAD_METHOD_BRIGHTNESS:
+	case ACPI_THINKPAD_METHOD_VOLUME:
+	case ACPI_THINKPAD_METHOD_MUTE:
+		/* EC is required here, which was already checked before */
+		return (TRUE);
+
+	case ACPI_THINKPAD_METHOD_THINKLIGHT:
+		sc->cmos_handle = NULL;
+		sc->light_get_supported = ACPI_SUCCESS(acpi_GetInteger(
+		    sc->ec_handle, THINKPAD_NAME_KEYLIGHT, &sc->light_val));
+
+		if ((ACPI_SUCCESS(AcpiGetHandle(sc->handle, "\\UCMS",
+		    &sc->light_handle)) ||
+		    ACPI_SUCCESS(AcpiGetHandle(sc->handle, "\\CMOS",
+		    &sc->light_handle)) ||
+		    ACPI_SUCCESS(AcpiGetHandle(sc->handle, "\\CMS",
+		    &sc->light_handle))) &&
+		    ACPI_SUCCESS(AcpiGetType(sc->light_handle, &cmos_t)) &&
+		    cmos_t == ACPI_TYPE_METHOD) {
+			sc->light_cmd_on = 0x0c;
+			sc->light_cmd_off = 0x0d;
+			sc->cmos_handle = sc->light_handle;
+		}
+		else if (ACPI_SUCCESS(AcpiGetHandle(sc->handle, "\\LGHT",
+		    &sc->light_handle))) {
+			sc->light_cmd_on = 1;
+			sc->light_cmd_off = 0;
+		}
+		else
+			sc->light_handle = NULL;
+
+		sc->light_set_supported = (sc->light_handle &&
+		    ACPI_FAILURE(AcpiGetHandle(sc->ec_handle, "LEDB",
+		    &ledb_handle)));
+
+		if (sc->light_get_supported)
+			return (TRUE);
+
+		if (sc->light_set_supported) {
+			sc->light_val = 0;
+			return (TRUE);
+		}
+
+		return (FALSE);
+
+	case ACPI_THINKPAD_METHOD_BLUETOOTH:
+	case ACPI_THINKPAD_METHOD_WLAN:
+		if (ACPI_SUCCESS(acpi_GetInteger(sc->handle,
+		    THINKPAD_NAME_WLAN_BT_GET, &dummy)))
+			return (TRUE);
+		return (FALSE);
+
+	case ACPI_THINKPAD_METHOD_FANSPEED:
+		/* 
+		 * Some models report the fan speed in levels from 0-7
+		 * Newer models report it contiguously
+		 */
+		sc->fan_levels = (ACPI_SUCCESS(AcpiGetHandle(sc->handle, "GFAN",
+		    &sc->fan_handle)) ||
+		    ACPI_SUCCESS(AcpiGetHandle(sc->handle, "\\FSPD",
+		    &sc->fan_handle)));
+		return (TRUE);
+
+	case ACPI_THINKPAD_METHOD_FANLEVEL:
+	case ACPI_THINKPAD_METHOD_FANSTATUS:
+		/* 
+		 * Fan status is only supported on those models,
+		 * which report fan RPM contiguously, not in levels
+		 */
+		if (sc->fan_levels)
+			return (FALSE);
+		return (TRUE);
+
+	case ACPI_THINKPAD_METHOD_THERMAL:
+		if (ACPI_SUCCESS(acpi_GetInteger(sc->ec_handle,
+		    THINKPAD_NAME_THERMAL_GET, &dummy))) {
+			sc->thermal_updt_supported =
+			    ACPI_SUCCESS(acpi_GetInteger(sc->ec_handle,
+			    THINKPAD_NAME_THERMAL_UPDT, &dummy));
+			return (TRUE);
+		}
+		return (FALSE);
+	}
+	return (FALSE);
+}
+
+static void
+acpi_thinkpad_notify(ACPI_HANDLE h, UINT32 notify, void *context)
+{
+	int		event, arg, type;
+	device_t	dev = context;
+	struct acpi_thinkpad_softc *sc = device_get_softc(dev);
+
+	ACPI_FUNCTION_TRACE_U32((char *)(uintptr_t)__func__, notify);
+
+	if (notify != 0x80)
+		device_printf(dev, "Unknown notify\n");
+
+	for (;;) {
+		acpi_GetInteger(acpi_get_handle(dev), THINKPAD_NAME_EVENTS_GET,
+		    &event);
+
+		if (event == 0)
+			break;
+
+		type = (event >> 12) & 0xf;
+		arg = event & 0xfff;
+		switch (type) {
+		case 1:
+			if (!(sc->events_availmask & (1 << (arg - 1)))) {
+				device_printf(dev, "Unknown key %d\n", arg);
+				break;
+			}
+
+			/* Notify devd(8) */
+			device_printf(dev, "THINKPAD event: %u\n",
+			    (arg & 0xff));
+			acpi_UserNotify("THINKPAD", h, (arg & 0xff));
+			break;
+		default:
+			break;
+		}
+	}
+}
+
+static void
+acpi_thinkpad_refresh(void *arg)
+{
+	struct acpi_thinkpad_softc *sc = (struct acpi_thinkpad_softc *)arg;
+	char temp_cmd[] = "TMP0";
+	int data, i;
+	ACPI_INTEGER speed;
+
+	for (i = 0; i < 8; i++) {
+		temp_cmd[3] = '0' + i;
+		
+                /*
+                 * The TMPx methods seem to return +/- 128 or 0
+                 * when the respecting sensor is not available
+                 */
+		sc->sensors[i].flags &= ~SENSOR_FINVALID;
+                if (ACPI_FAILURE(acpi_GetInteger(sc->ec_handle, temp_cmd,
+                    &data)) || ABS(data) == 128 || data == 0) {
+			sc->sensors[i].flags |= SENSOR_FINVALID;
+                        data = 0;
+		}
+                else if (sc->thermal_updt_supported) {
+                        /* XXX: Temperature is reported in tenth of Kelvin */
+                        data = (data - 2732 + 5) / 10;
+		}
+		sc->sensors[i].value = data * 1000000 + 273150000;
+        }
+	
+	sc->sensors[8].flags &= ~SENSOR_FINVALID;
+	if (sc->fan_handle) {
+		if (ACPI_FAILURE(acpi_GetInteger(sc->fan_handle,
+		    NULL, &data)))
+			sc->sensors[8].flags |= SENSOR_FINVALID;
+                        data = -1;
+        }
+        else {
+                ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_FANSPEED, &speed, 2);
+                data = speed;
+        }
+
+	sc->sensors[8].value = data;
+}
diff --git a/sys/platform/pc32/conf/files b/sys/platform/pc32/conf/files
--- a/sys/platform/pc32/conf/files
+++ b/sys/platform/pc32/conf/files
@@ -72,6 +72,7 @@ dev/serial/dgb/dgm.c			optional	dgm
 ${OSACPI_MD_DIR}/acpi_machdep.c		optional        acpi
 ${OSACPI_MD_DIR}/acpi_wakeup.c		optional        acpi
 ${OSACPI_MD_DIR}/acpi_toshiba.c		optional        acpi_toshiba acpi
+${ACPICA_DIR}/acpi_thinkpad/acpi_thinkpad.c optional	acpi_thinkpad acpi
 acpi.h					optional	acpi		\
 	dependency	"$S/${ACPICA_DIR}/include/acpi.h"		\
 	compile-with	"cp $S/${ACPICA_DIR}/include/acpi.h ${.OBJDIR}/"	\



From hasso at estpak.ee  Thu Mar 20 03:49:13 2008
From: hasso at estpak.ee (Hasso Tepper)
Date: Thu, 20 Mar 2008 03:49:13 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Some questions regarding ACPI
In-Reply-To: <200803191322.46366.hasso@estpak.ee>
Message-ID: <200803201237.28823.hasso@estpak.ee>

Hasso Tepper wrote:
> There is also one fatal issue -laptop locks up hardly (no panic) while 
> unloading module. Any idea regarding this is welcome.

Nevermind, solved.


-- 
Hasso




From dillon at apollo.backplane.com  Fri Mar 21 19:24:01 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Fri, 21 Mar 2008 19:24:01 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: panic: assertion: hammer_btree_cmp(cursor->left_bound,	&cursor->node->ondisk->elms[0].leaf.base) <= 0 in btree_split_leaf
In-Reply-To: <200802232204.m1NM4cxd046264@apollo.backplane.com>
Message-ID: <200803220212.m2M2CiAY014435@apollo.backplane.com>

:While trying to find a procedure to reliably reproduce the panic
:I reported last time, I caught a different panic (uploaded at
: ~y0netan1/crash/9/ on my leaf account).  I wrote the following shell
:script (make sure to edit variables DISKS and MOUNTPT before using this
:script or it may trash your system):

    Ok, I believe I have fixed the left_bound assertion.  I also believe
    I have fixed the node ref count assertion on umount.

    There is currently one unfixed assertion related to the I/O
    path... sometimes the bp is being improperly disassociated from the
    related HAMMER structure.

    The full-filesystem case is still not being handled so don't test that :-)

					    -Matt





From c.turner at 199technologies.org  Sun Mar 23 09:48:29 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Sun, 23 Mar 2008 09:48:29 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
Message-ID: <47E6870C.4080709@199technologies.org>

I'm finally getting around to doing 1.12 upgrades, and have setup a 
separate machine to do my bulk package builds / upgrades etc,
so as not to disrupt my 'dev server' while things are being
built / tested

However, this seems kind of wasteful - the only purpose of this machine
is to build packages against a specific release..
And since building packages for a particular release generally requires 
only the userland, appropriate headers and correct 'uname' output - so:

it seems like if spoofing uname is configured inside a jail,
the next (or previous..) release can be installed into a jail and
used for building / testing packages without the overhead of a VM or 
maintaining a separate physical host

I did a quick scan of the tree to see what this would take, and, high 
level, it seems like only the following changes would need to be made:

- update struct jail to add a 'osrelease' string
  (implies bumping 'jail api' to 2?)
- update jail(8) to actually pass this information along
- update sys_uname to test ucred for jailed processes, and
  use the struct jail osrelease if appropriate
- similarly update sysctl kern.osrelease to support jail spoofing
  (if possible - didn't get this far in the research yet)
  could be less of a problem for builds, as I think most things use
 uname(1) ... but good to keep the environment consistent I suppose..
I'm still a bit confused as to how 'osrelease' is defined - everything
I'm finding is showing up as extern char[] .. perhaps this is something 
in the build I'm not familiar with?

also,

is the so-called 'stupid hackery' in sys_uname needed still?

Before I start any coding, does this:

- sound like something useful
- sound like the right approach
Thinking this could have wider useful implications e.g. for pkgbox
& so on -  for example setting up automated bulks w/various combinations 
of pkgsrc and releases, etc.

Cheers,

- Chris





From corecode at fs.ei.tum.de  Sun Mar 23 10:06:38 2008
From: corecode at fs.ei.tum.de (Simon 'corecode' Schubert)
Date: Sun, 23 Mar 2008 10:06:38 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <47E68C74.3080808@fs.ei.tum.de>

Chris Turner wrote:
I did a quick scan of the tree to see what this would take, and, high 
level, it seems like only the following changes would need to be made:
brave investigation.  but you could also simply set UNAME_r :)

sweatshorts % uname -r
1.13.0-DEVELOPMENT
sweatshorts % UNAME_r=1.12-RELEASE uname -r
1.12-RELEASE
I think that's good enough :D

cheers
  simon
--
Serve - BSD     +++  RENT this banner advert  +++    ASCII Ribbon   /"\
Work - Mac      +++  space for low ????????? NOW!1  +++      Campaign     \ /
Party Enjoy Relax   |   http://dragonflybsd.org      Against  HTML   \
Dude 2c 2 the max   !   http://golden-apple.biz       Mail + News   / \




From c.turner at 199technologies.org  Sun Mar 23 10:50:13 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Sun, 23 Mar 2008 10:50:13 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <47E69656.8080605@199technologies.org>

Simon 'corecode' Schubert wrote:
brave investigation.  but you could also simply set UNAME_r :)
Doh! Thanks for the tip!

they should change the phrase from RTFM to 'Carefully RTFM' :)

well.. scratch that change then. 1 less patch to write.

- Chris





From c.turner at 199technologies.org  Sun Mar 23 11:15:52 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Sun, 23 Mar 2008 11:15:52 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <47E69C7C.8010109@199technologies.org>

Chris Turner wrote:
Simon 'corecode' Schubert wrote:
brave investigation.  but you could also simply set UNAME_r :)

for the record - if anyone's interested - adding a line e.g.:

ALL_ENV+= UNAME_r=1.12-RELEASE

to mk.conf looks like it -might- work ..

(unless wants to chime in & verify)





From joerg at britannica.bec.de  Sun Mar 23 11:46:53 2008
From: joerg at britannica.bec.de (Joerg Sonnenberger)
Date: Sun, 23 Mar 2008 11:46:53 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <20080323181428.GA2099@britannica.bec.de>

On Sun, Mar 23, 2008 at 01:41:42PM -0400, Chris Turner wrote:
> they should change the phrase from RTFM to 'Carefully RTFM' :)

RTFMAI -- Read The Fine Manual Again, Idiot.

Joerg




From dillon at apollo.backplane.com  Sun Mar 23 20:05:36 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Sun, 23 Mar 2008 20:05:36 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
Message-ID: <200803240257.m2O2voNH038355@apollo.backplane.com>

    Here's an update on the HAMMER work!

    Current status:

    * Passes all standard filesystem stress tests and buildworld will
      run with a HAMMER /usr/obj.  Large histories are able to accumulate
      without effecting performance.

    * Pruning and reblocking code is in and partially tested, but now needs
      more stringent testing.

    * Full historical access appears to be working but needs testing.
      Note that a sync is still needed to flush dirty cached data prior
      to acquiring a timestamp for the 'snapshot' to be set in stone.
      (dirty data cached in-memory has no historical tags and must be
      committed to physical disk before it can be accessed historically).


    Current bugs:

    * There is one known bug in the standard operations code paths
      that results in an assertion in HAMMER's I/O subsystem.

    * There are probably bugs in the reblocking and/or pruning code.  More
      likely in the reblocking code.


    There are two big-ticket and several little-ticket items left.  HAMMER
    will officially go Alpha when the big-ticket items are done, and beta
    when we get a few of the little-ticket items done.

    Big ticket items left:

    * UNDO (crash recovery) code.  Currently it writes out undo records but
      they are not yet sequenced, buffer writes are not yet ordered, and
      there is no mount-time recovery code yet.

      This is the last item needed before HAMMER can go operational.

    * Filesystem full handling.  Currently no space is reserved for dirty
      cached data so it is possible to create/write files and for HAMMER
      to not have sufficient space left on-disk to flush it.


    Little ticket items:

    * Automated reblocking (currently these functions are manually
      initialized via the hammer utility).

    * I/O clustering and preliminary BMAP op when writing out large files.

    * CRC checking (CRC fields are reserved but not entirely generated yet
      and not yet checked at all).

    * Disaster Recovery filesystem scan.

    * Boot support.

    I expect all of these items and more to be handled by the 2.0 release
    in July.

			    Additional HAMMER capabilities
				(no timeline yet)

    * Adding, removing, and resizing a HAMMER filesystem's backing store.

			Ultimate Goals and working towards them
				(no timeline yet)

    Our ultimate goal with HAMMER and DragonFly in general is to support
    fully cache coherent replication in a multi-machine environment.  This
    involves several steps and networking protocols.

    * Replication of synchronization streams based on the UNDO log.  If
      resynchronizing to a target which is too old a B-Tree scan will
      likely be required.

    * Cache coherency protocols for machine-machine coherency for both
      replicated and remote-HAMMER access.

    I have no time frame for these items yet.  It will depend on how quickly
    HAMMER moves to Alpha and Beta status.  I will say, however, now
    that HAMMER's on-disk format has solidified, that I have a very precise
    understanding of the protocols that will be needed to accomplish fully
    cache coherent remote access for both replicated and non-replicated
    (remote mount style) access.

    And, as you know, fully coherent filesystem access across machines is
    going to be the basis for DragonFly's clustering across said machines.

    In summary, things are progressing very well.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From justin at shiningsilence.com  Sun Mar 23 20:10:13 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Sun, 23 Mar 2008 20:10:13 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <53758.192.168.0.252.1206327873.squirrel@www.shiningsilence.com>

On Sun, March 23, 2008 12:36 pm, Chris Turner wrote:

> it seems like if spoofing uname is configured inside a jail,
> the next (or previous..) release can be installed into a jail and
> used for building / testing packages without the overhead of a VM or
> maintaining a separate physical host

If you don't need a jail to spoof uname, as others posted, you can
installworld into a chroot and build everything you want there using
Joerg's spiffy pbulk.  That's what I'm doing on pkgbox now; I can hand you
my somewhat terse notes if you want.  It would be relatively easy to set
up the configuration you're talking about.





From sepherosa at gmail.com  Sun Mar 23 20:18:20 2008
From: sepherosa at gmail.com (Sepherosa Ziehau)
Date: Sun, 23 Mar 2008 20:18:20 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <ea7b9c170803232012n2f27f893tf1d756d7c9770419@mail.gmail.com>

On Mon, Mar 24, 2008 at 2:14 AM, Joerg Sonnenberger
<joerg at britannica.bec.de> wrote:
> On Sun, Mar 23, 2008 at 01:41:42PM -0400, Chris Turner wrote:
>  > they should change the phrase from RTFM to 'Carefully RTFM' :)
>
>  RTFMAI -- Read The Fine Manual Again, Idiot.

http://leaf.dragonflybsd.org/~sephe/rtfm.jpg

:D

>
>  Joerg
>



-- 
Live Free or Die




From justin at shiningsilence.com  Sun Mar 23 20:38:30 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Sun, 23 Mar 2008 20:38:30 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: GSoC 2008 - mentors signup
Message-ID: <53885.192.168.0.252.1206329503.squirrel@www.shiningsilence.com>

If you are planning to be a mentor for a Summer of Code project, please
sign up here for the mentors mailing list:

http://groups.google.com/group/google-summer-of-code-mentors-list

If you've already signed up, your subscription should be set up tomorrow.





From justin at shiningsilence.com  Sun Mar 23 21:12:01 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Sun, 23 Mar 2008 21:12:01 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: GSoC 2008 - mentors signup
In-Reply-To: <53885.192.168.0.252.1206329503.squirrel@www.shiningsilence.com>
Message-ID: <54025.192.168.0.252.1206331572.squirrel@www.shiningsilence.com>

Also!

If you are a potential mentor and you have not done so yet:

http://code.google.com/soc/mentor_step1.html

Get yourself registered as a mentor for the Summer of Code project.  Once
you are in there, check off DragonFly in the "My Profile" section.

You will need a Google Account if you don't have one:

http://www.google.com/accounts

This will add you to the list of mentors in the Google Summer of Code web
application, so you can review/be attached to projects.

A guide is available if you want more information:

http://groups.google.com/group/google-summer-of-code-announce/web/guide-to-the-gsoc-web-app-for-mentors-and-organization-administrators






From c.turner at 199technologies.org  Mon Mar 24 04:29:28 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Mon, 24 Mar 2008 04:29:28 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <47E78ECE.4070307@199technologies.org>

Justin C. Sherrill wrote:
If you don't need a jail to spoof uname, as others posted, you can
installworld into a chroot and build everything you want there using
Joerg's spiffy pbulk.  That's what I'm doing on pkgbox now; I can hand you
my somewhat terse notes if you want.  It would be relatively easy to set
up the configuration you're talking about.
cheers - I guess I thought incorrectly that something 'special' was 
needed to get the uname to change .. have been using the legacy bulks in 
chroots / jails (for 'same os' builds) as I haven't quite migrated to 
pbulk yet ..

thanks for the help offer - I'll ask if I run into trouble.




From dillon at apollo.backplane.com  Mon Mar 24 08:28:49 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Mon, 24 Mar 2008 08:28:49 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <200803241500.m2OF0CG8043760@apollo.backplane.com>


:http://leaf.dragonflybsd.org/~sephe/rtfm.jpg
:
::D

    Ho!

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From elekktretterr at exemail.com.au  Mon Mar 24 09:10:15 2008
From: elekktretterr at exemail.com.au (Petr Janda)
Date: Mon, 24 Mar 2008 09:10:15 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
In-Reply-To: <200803240257.m2O2voNH038355@apollo.backplane.com>
Message-ID: <200803250138.49775.elekktretterr@exemail.com.au>


>
>     And, as you know, fully coherent filesystem access across machines is
>     going to be the basis for DragonFly's clustering across said machines.
>
>     In summary, things are progressing very well.
>


Hi Matt,
That's good to know things are going so well. Got a question. If memory serves 
me right, initially there was also going to be a thing called ANVIL, I can't 
remember what it was supposed to do and whether its still in your design. 
Could you elaborate a little?

Thanks,
Petr




From dillon at apollo.backplane.com  Mon Mar 24 14:12:11 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Mon, 24 Mar 2008 14:12:11 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
In-Reply-To: <200803240257.m2O2voNH038355@apollo.backplane.com>
Message-ID: <200803242100.m2OL0nWV046868@apollo.backplane.com>


:Hi Matt,
:That's good to know things are going so well. Got a question. If memory serves 
:me right, initially there was also going to be a thing called ANVIL, I can't 
:remember what it was supposed to do and whether its still in your design. 
:Could you elaborate a little?
:
:Thanks,
:Petr

    It's not really in the HAMMER design any more, primarily because HAMMER's
    volume model seems to work fine as-is.  Ultimately something like ANVIL
    (a block storage manager) would prove beneficial to the project but it
    would be treated as a separate project.  HAMMER's redundancy model is
    going to be baesd around replication and clustering.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From tgen at netphreax.net  Mon Mar 24 18:31:37 2008
From: tgen at netphreax.net (Thomas E. Spanjaard)
Date: Mon, 24 Mar 2008 18:31:37 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
In-Reply-To: <200803240257.m2O2voNH038355@apollo.backplane.com>
Message-ID: <47E85337.2070407@netphreax.net>

Matthew Dillon wrote:
    * Full historical access appears to be working but needs testing.
      Note that a sync is still needed to flush dirty cached data prior
      to acquiring a timestamp for the 'snapshot' to be set in stone.
      (dirty data cached in-memory has no historical tags and must be
      committed to physical disk before it can be accessed historically).
Wouldn't making timestamp queries (at least from userland) enforce a 
sync on the volume in question be useful here?
--
        Thomas E. Spanjaard
        tgen at netphreax.net
Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00005.pgp
Type: application/octet-stream
Size: 186 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080324/3077333f/attachment-0013.obj>

From dillon at apollo.backplane.com  Mon Mar 24 20:10:12 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Mon, 24 Mar 2008 20:10:12 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
In-Reply-To: <200803240257.m2O2voNH038355@apollo.backplane.com>
Message-ID: <200803250302.m2P32qLP050160@apollo.backplane.com>


:Wouldn't making timestamp queries (at least from userland) enforce a 
:sync on the volume in question be useful here?
:-- 
:         Thomas E. Spanjaard
:         tgen at netphreax.net

    Making the 'hammer now' command do a sync() is a good idea.  I will
    make that change right now so it doesn't get lost.

    Here's a general overview of the issues involved with having historical
    access to the filesystem:

				----------------

    Recording the timestamps in the in-memory cache, for a finer-grained
    snapshot capability, is doable but has its own issues.  Here's an
    illustration:

    open()  create file
    write() append 4K	(file size now 4K)
    write() append 4K	(file size now 8K)
    write() append 4K	(file size now 12K)
    write() append 4K	(file size now 16K)

    Now NONE of this has gone to disk yet, it's entirely in the in-memory
    cache.  The inode is in the in-memory cache.  The data is stored in
    the buffer cache.  Even the directory entry for the file that we
    just created is still in the in-memory cache (HAMMER caches the raw
    records it intends to commit later on).

    If I wanted to be able to acquire a timestamp between each write and
    'see' a snapshot of the file as of any point in the above sequence,
    then every write would also have to allocate a copy of the inode
    (because it changes size on each write).

    The data has the same problem though with a slightly different example.
    Lets say each write() was a seek-write, overwriting the previous data.
    Now with every write() I would have to allocate a copy of the data
    being overwritten.  This is complicated by the fact that the buffer
    cache has no clue about 'historical' accesses, so I would not be able
    to use the buffer cache to cache the data.

    There's also another problem and that is with the efficiency of the
    topology on-disk.  Even if I maintained all the copies of the inode
    and all the copies of the data in-memory, I would still have to sync
    all those copies to disk in order for things to remain historically
    coherent (whether it be in-cache or on-disk).  This would result in
    hundreds or even thousands of copies of the inode on-disk, not to
    mention potentially many copies of the data.

    I just don't want to do that right now, at least not as a default.  A
    lot of performance would be lost.  Hence a sync() is needed if
    you want to create a demark which you can accurately snapshot.

				-------------

    Here's a quick synopsis of how the cache would operate in a clustered
    filesystem:

    In order to properly integrate with in-memory caches, a wider cache
    coherency infrastructure is needed between machines such that
    modifications made on one machine proactively invalidate those
    protions of the cache(s) on other machines.  At the same time, any
    'dirty' cache data, for example when a file is created or written to,
    must lock the cache space in question on all other machines.
    The cache space in this case is not just the file data, but also the
    related namespaces (for creations, deletions, and renames).  Attempts
    to access locked spaces from other machines in the cluster would have
    to force a flush to the filesystem backing store and lower the cache
    states for the effected information on the original machine from dirty
    to shared-read-only.

    It will be easiest to integrate the cache coherency information into
    the buffer cache and namecache themselves.  Once a machine has dirtied
    an in-memory cache element... for example part of the namespace when
    creating a file or chunks of data written within a file, that machine
    must have a free hand to make further modifications to the cache spaces
    involved without further interaction with other machines.

				-------------

    Now, if you think of those two major elements you can see that they
    actually fit together quite well.  If I were to attempt to maintain
    transactional coherency on a per-system-call basis then the cache
    granularity between machines would have to be much, much smaller then
    our current in-memory caching elements provide.  That would become
    a really nasty coding problem.  So I don't even want to begin to
    complate transactional coherency at a finer-grain then sync() or
    fsync() until long after we actually have clustering working.

						-Matt





From elekktretterr at exemail.com.au  Mon Mar 24 21:56:58 2008
From: elekktretterr at exemail.com.au (Petr Janda)
Date: Mon, 24 Mar 2008 21:56:58 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
In-Reply-To: <200803240257.m2O2voNH038355@apollo.backplane.com>
Message-ID: <200803251516.16407.elekktretterr@exemail.com.au>

So is it needed to run hammer now in order to "create" a snapshot? What would 
I do in situation like this: got a hammer filesystem and couple of the files 
change on day to day basis. Then a week later I needed to access one of the 
files, in exactly the state they were 7 days ago.

Cheers,
Petr




From dillon at apollo.backplane.com  Mon Mar 24 22:34:15 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Mon, 24 Mar 2008 22:34:15 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
In-Reply-To: <200803240257.m2O2voNH038355@apollo.backplane.com>
Message-ID: <200803250526.m2P5QZ5X051081@apollo.backplane.com>


:So is it needed to run hammer now in order to "create" a snapshot? What would 
:I do in situation like this: got a hammer filesystem and couple of the files 
:change on day to day basis. Then a week later I needed to access one of the 
:files, in exactly the state they were 7 days ago.
:
:Cheers,
:Petr

    No, you do not have to run 'hammer now' to create a snapshot.  The
    kernel syncs all filesystems every 30 seconds, so if you do nothing
    at all you get a snapshot granularity of 30 seconds.

    Where you would use 'hammer now' is if you wanted the most current
    snapshot possible for the purpose of, say, backing up your filesystem
    to another machine.  You might do something like this:

	set timestamp = `hammer now`
	cpdup /mountpoint/@@$timestamp targethost:/somepath

    But if you didn't care about that you could just go back far enough
    that you get a stable historical view... e.g. go back 1 minute and you
    would have a stable view into your filesystem.

	set timestamp = `hammer stamp 60s`		<------ doesn't sync
	cpdup /mountpoint/@@$timestamp targethost:/somepath


    Ultimately the idea of managing filesystems this way is to still do
    regular backups from your production machine to your backup machine
    (ultimately by way of replication), with both running HAMMER, but only
    retain a limited amount of history on the production box.  You might
    desire to retain only one week's worth of history on the production box,
    retain one month's history on your local backup box, and retain a very
    granular one year's worth of history on your remote backup box.

    Come to think of it, I should add some more directives to the
    'hammer prune' command to make that easier to specify.

    Until I implement a live replication 'feed' the minimum granularity on
    the backup box will be how often you do your backups (e.g. once a day),
    and you can prune it into more granular forms from that starting point.
    Once we have a live replication feed the backup box will have the same
    30-second granularity that the production machine has.

    A major bullet point for this style of management is that the retention
    policy on the various boxes can be different even though they are
    all slaved off the same production filesystem.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From justin at shiningsilence.com  Tue Mar 25 05:58:49 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Tue, 25 Mar 2008 05:58:49 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: SoC - student signups
Message-ID: <58180.65.106.147.226.1206449676.squirrel@www.shiningsilence.com>

Here's a quick link roundup:

Are you a student?  Put in your application for a Google Summer of Code here:

http://code.google.com/soc/2008/student_signup.html

Student guide:
http://groups.google.com/group/google-summer-of-code-announce/web/guide-to-the-gsoc-web-app-for-student-applicants

Are you a mentor?  (That means hasso, hsu, sephe, matthias, TGEN, and
corecode right now)

Student proposals will show up on the mentor page, linked below.  You will
get to rate them, and take the one(s) that you want to mentor.

Mentor page:
http://code.google.com/soc/2008/mentor_home.html
Mentor guide:
http://groups.google.com/group/google-summer-of-code-announce/web/guide-to-the-gsoc-web-app-for-mentors-and-organization-administrators

If you are a mentor and are communicating with potential students, send
them the URLs above for student signup and the student guide; work with
them if they ask for advice on what to say in the application.  They can
resubmit up to 20 times if they want to correct it.

Deadline is March 31st.






From noah.yan at gmail.com  Thu Mar 27 20:17:48 2008
From: noah.yan at gmail.com (Yonghong Yan)
Date: Thu, 27 Mar 2008 20:17:48 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: About DFBSD.64
In-Reply-To: <47EB0B5B.5020802@gmail.com>
Message-ID: <59521b110803272015y1cc8cc39uc93f154ed36e0505@mail.gmail.com>

thanks for your interest.

I owe to everybody for any update or work in the past four months. so
many things happen in my work and my family (they are all good:) and
keep me extremely busy. But i am not leaving and will be back on this
soon.

the latest sources are in http://repo.or.cz/w/dragonfly/port-amd64.git
, I did have a compiled kernel long time before, but I have to break
it to work on the pmap. you can pick up from there. TGEN will help you
a lot, also keep me posted too, if you like.

Noah

On Wed, Mar 26, 2008 at 9:50 PM, Sdavtaker <sdavtaker at gmail.com> wrote:
> Hello,
>  Im applying to GSoC to work in the x64 version of DFBSD with TGEN, i
>  found some work already done in the repository and some mails in the
>  archive from you.
>  I was wondering if you already had a working compiled kernel in AMD64
>  machine and what was not working yet to continue that work.
>  Thanks for any info.
>  Sdav
>




From dillon at apollo.backplane.com  Sat Mar 29 13:27:43 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Sat, 29 Mar 2008 13:27:43 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 29-Mar-2008
Message-ID: <200803292022.m2TKMLGe004942@apollo.backplane.com>

    Good progress continues to be made.  HAMMER survived acting as my
    LAN backup machine (in full historical mode) for almost a week before
    it hit an assertion.  I've fixed that issue and believe that the core
    filesystem implementation code is now 'very stable'.

    Note that the recent commit will result in many more 'hammer_lock_ex:'
    messages on the console then you may have previously observed.  This is
    due to the way object id's are allocated in the face of parallel 
    modifications to the filesystem, resulting in too much locality of
    reference in the B-Tree.  I do intend to improve it.

    I am still working on the two major items needed before HAMMER can be
    declared operational, those being the filesystem full handling and the
    undo/recovery-on-mount code.  These are the last 'hard' bits left in
    the design.

    With exception to filling up the filesystem, which *will* create a mess,
    and noting that no crash recovery code exists yet (so you have to newfs
    it if you crash), I'd appreciate it if interested parties could test
    the other functions of the filesystem, in particular the pruning and
    reblocking functions (man hammer), and the historical access functions.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From dillon at apollo.backplane.com  Sun Mar 30 15:11:03 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Sun, 30 Mar 2008 15:11:03 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Need ideas on how to solve an st_ino/st_dev test issue for HAMMER.
Message-ID: <200803302207.m2UM7BCp016402@apollo.backplane.com>

    Here's the problem, given historical access softlinks as shown below:

test30# ls -lda cra*
drwxr-xr-x  1 root  wheel  Mar 29 13:04 crater
lrwxr-xr-x  1 root  wheel  Mar 29 18:57 crater.20080329 -> crater@@0x47eef383
lrwxr-xr-x  1 root  wheel  Mar 30 01:24 crater.20080330 -> crater@@0x47ef4e29
-rw-r--r--  2 root  wheel  Mar 30 01:24 crater.log

    The problem is that if I do this:

    diff -r crater.20080329/var/log crater.20080330/var/log

    Diff just returns without actually diffing anything.  The reason is
    because diff checks st_ino and st_dev and believes the directories/files
    to be identical because they match.

    I considered munging the inode number for historical accesses, but
    that would seriously break NFS exports which try to access historical
    files and directories.  Right now NFS *is* able to distinguish between
    the two because NFS handles are 128-bit-wide entities, so I can encode
    the as-of transaction id as part of the filehandle.  But userland
    programs only have access to a 64-bit-wide inode so userland still
    believes the files to be identical.

    st_dev is only 32 bits, carefully munging it is an option if we
    could figure out a way to do it, but I'd rather not.

    I am considering using st_gen but then we'd have to patch third
    party software to test st_gen along with everything else.  This may
    be the only workable solution, though, and only a few programs would
    need to be patched.  st_gen is only 32 bits but it would solve the
    problem as we would be able to use all 32 bits.

    If anyone has any bright ideas, including 'leave it alone', I'm all
    ears.

						-Matt





From justin at shiningsilence.com  Mon Mar 31 10:40:42 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Mon, 31 Mar 2008 10:40:42 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: SoC student applications due by 5PM PDT tomorrow
In-Reply-To: <1942.192.168.0.242.1206930479.squirrel@www.shiningsilence.com>
Message-ID: <11892.67.108.184.175.1206984967.squirrel@www.shiningsilence.com>

On Sun, March 30, 2008 10:27 pm, Justin C. Sherrill wrote:
> SoC students:
>
> If you have an application to submit for DragonFly/Summer of Code, please
> do so by 17:00 Pacific time on the 31st - that's tomorrow, at least for
> me.

The deadline for student proposals has been extended to April 7th; all
other dates move forward one week to acommodate.

This is a good time to update existing applications or submit new ones. 
Talk to your (potential) mentors if you are curious.






From nthery at gmail.com  Mon Mar 31 11:29:49 2008
From: nthery at gmail.com (Nicolas Thery)
Date: Mon, 31 Mar 2008 11:29:49 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
Message-ID: <64fc43b0803311126na7d0b27obaa9d35bac6d32ee@mail.gmail.com>

Hello,

Now that the release is over, I'll try to get rid of zones and migrate
allocations to objcache.

Here is a 1st patch that migrate struct proc.  I'll commit it in a
couple of days if nobody objects.

I'm also implementing a way to monitor objcache statistics.  So far,
I've hacked sth similar to
sysctl vm.zone: stats are returned in one giant string, one line per
cache.  That's simple but ugly and hard to read because there are
quite a few stats per cache.

So I'm thinking about implementing a small tool, ocstat, that extracts
stats from sysctl the way ps(1) does (thru libkvm iirc) and formats it
in various ways.  What do you think?

Cheers,
Nicolas

Index: src2/sys/kern/kern_exit.c
===================================================================
--- src2.orig/sys/kern/kern_exit.c	2008-03-31 08:05:59.139796000 +0200
+++ src2/sys/kern/kern_exit.c	2008-03-31 10:31:39.000000000 +0200
@@ -834,7 +834,7 @@ loop:
 			}

 			vm_waitproc(p);
-			zfree(proc_zone, p);
+			objcache_put(proc_cache, p);
 			nprocs--;
 			return (0);
 		}
Index: src2/sys/kern/kern_proc.c
===================================================================
--- src2.orig/sys/kern/kern_proc.c	2008-03-31 08:05:59.139918000 +0200
+++ src2/sys/kern/kern_proc.c	2008-03-31 10:31:39.000000000 +0200
@@ -84,7 +84,7 @@ u_long pgrphash;
 struct proclist allproc;
 struct proclist zombproc;
 struct spinlock allproc_spin;
-vm_zone_t proc_zone;
+struct objcache* proc_cache;
 vm_zone_t lwp_zone;
 vm_zone_t thread_zone;

@@ -131,7 +131,7 @@ procinit(void)
 	spin_init(&allproc_spin);
 	pidhashtbl = hashinit(maxproc / 4, M_PROC, &pidhash);
 	pgrphashtbl = hashinit(maxproc / 4, M_PROC, &pgrphash);
-	proc_zone = zinit("PROC", sizeof (struct proc), 0, 0, 5);
+	proc_cache = objcache_create_simple(M_PROC, sizeof(struct proc));
 	lwp_zone = zinit("LWP", sizeof (struct lwp), 0, 0, 5);
 	thread_zone = zinit("THREAD", sizeof (struct thread), 0, 0, 5);
 	uihashinit();
Index: src2/sys/sys/proc.h
===================================================================
--- src2.orig/sys/sys/proc.h	2008-03-31 08:05:59.140325000 +0200
+++ src2/sys/sys/proc.h	2008-03-31 10:31:39.000000000 +0200
@@ -473,7 +473,7 @@ struct proc *zpfind (pid_t);	/* Find zom
 struct vm_zone;
 struct globaldata;
 struct lwp_params;
-extern struct vm_zone *proc_zone;
+extern struct objcache *proc_cache;
 extern struct vm_zone *lwp_zone;

 int	enterpgrp (struct proc *p, pid_t pgid, int mksess);
Index: src2/sys/kern/kern_fork.c
===================================================================
--- src2.orig/sys/kern/kern_fork.c	2008-03-31 08:05:59.140042000 +0200
+++ src2/sys/kern/kern_fork.c	2008-03-31 10:31:39.000000000 +0200
@@ -332,7 +332,7 @@ fork1(struct lwp *lp1, int flags, struct
 	}

 	/* Allocate new proc. */
-	p2 = zalloc(proc_zone);
+	p2 = objcache_get(proc_cache, M_WAITOK);
 	bzero(p2, sizeof(*p2));

 	/*




From hsu at dragonflybsd.org  Mon Mar 31 11:44:34 2008
From: hsu at dragonflybsd.org (Jeffrey Hsu)
Date: Mon, 31 Mar 2008 11:44:34 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <64fc43b0803311126na7d0b27obaa9d35bac6d32ee@mail.gmail.com>
Message-ID: <200803311841.m2VIfQAI007579@nlpi001.prodigy.net>

The object cache is not a general-purpose memory allocator.  It's a cache of
pre-initialized objects.  Are the significant portions of the proc structure
that can be restored to initialized state on object puts?  If not, it's best
to just use a general-purpose memory allocator.

								Jeffrey




From corecode at fs.ei.tum.de  Mon Mar 31 12:07:02 2008
From: corecode at fs.ei.tum.de (Simon 'corecode' Schubert)
Date: Mon, 31 Mar 2008 12:07:02 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <200803311841.m2VIfQAI007579@nlpi001.prodigy.net>
Message-ID: <47F1357B.1070302@fs.ei.tum.de>

Jeffrey Hsu wrote:
> The object cache is not a general-purpose memory allocator.  It's a cache of
> pre-initialized objects.  Are the significant portions of the proc structure
> that can be restored to initialized state on object puts?  If not, it's best
> to just use a general-purpose memory allocator.

Why?  What's the loss if we use the object cache to allocate struct procs?

cheers
  simon

Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00006.pgp
Type: application/octet-stream
Size: 252 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080331/a4a24314/attachment-0013.obj>

From nthery at gmail.com  Mon Mar 31 12:17:03 2008
From: nthery at gmail.com (Nicolas Thery)
Date: Mon, 31 Mar 2008 12:17:03 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <nthery@gmail.com>
Message-ID: <64fc43b0803311214u7da6bbb8xaf971de1a80e7258@mail.gmail.com>

2008/3/31, Jeffrey Hsu <hsu at dragonflybsd.org>:
> The object cache is not a general-purpose memory allocator.  It's a cache of
>  pre-initialized objects.  Are the significant portions of the proc structure
>  that can be restored to initialized state on object puts?  If not, it's best
>  to just use a general-purpose memory allocator.

Well, I haven't checked this yet.  I planned to do this in a second
step after getting rid of zones.

I thought that even without  the pre-initialization part, objcache has
the advantage
of pre-allocating set of objects (as zones) and is additionally
mp-safe (contrary to zones and, granted, as malloc()).   The latter
may be interesting as we talk of improving MP support.

Cheers,
Nicolas




From dillon at apollo.backplane.com  Mon Mar 31 12:23:40 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Mon, 31 Mar 2008 12:23:40 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <200803311841.m2VIfQAI007579@nlpi001.prodigy.net>
Message-ID: <200803311921.m2VJLITB027669@apollo.backplane.com>

    I both agree and disagree with Jeff.  I think the only *disadvantage*
    to using objcache for struct proc is that objcache must cache a minimum
    number of free structures to be efficient so the overall kernel memory
    use would be a bit greater verses uses kmalloc().  But I agree with Jeff
    in that objcache's biggest advantage is that you can keep structural state
    intact and struct proc might not be a good candidate (yet).

    What I suggest is that you convert struct proc from zone to kmalloc
    first, and then look into a possible objcache adaptation.  kmalloc
    is not slow.. it's a very fast allocator.  Objcache is probably a tad
    faster but not by much.  Where objcache really wins is in not having
    to completey reinitialize the allocated structures.

    Over the years I've removed (I think) all the dependancies on requiring
    the proc structure to be in stable memory so I believe it can be moved to
    kmalloc/objcache now without any major pain.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From corecode at fs.ei.tum.de  Mon Mar 31 12:37:40 2008
From: corecode at fs.ei.tum.de (Simon 'corecode' Schubert)
Date: Mon, 31 Mar 2008 12:37:40 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: SoC student applications due by 5PM PDT tomorrow
In-Reply-To: <1942.192.168.0.242.1206930479.squirrel@www.shiningsilence.com>
Message-ID: <47F13CDA.6010703@fs.ei.tum.de>

Justin C. Sherrill wrote:
> On Sun, March 30, 2008 10:27 pm, Justin C. Sherrill wrote:
>> SoC students:
>>
>> If you have an application to submit for DragonFly/Summer of Code, please
>> do so by 17:00 Pacific time on the 31st - that's tomorrow, at least for
>> me.
> The deadline for student proposals has been extended to April 7th; all
> other dates move forward one week to acommodate.

This is very good.

Some more ideas for eager students (we want to keep the ratio, right?):

Enhance the FreeBSD/DragonFly sound infrastructure to support surround
sound/multichannel output.

Update sound drivers to support S/PDIF output.

Make the sound infrastructure OSSv4 compatible (there was a SoC at
FreeBSD last year or so)


of course only if it doesn't exist already :)

cheers
  simon


Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00007.pgp
Type: application/octet-stream
Size: 252 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080331/6da61cff/attachment-0013.obj>

From corecode at fs.ei.tum.de  Mon Mar 31 12:41:30 2008
From: corecode at fs.ei.tum.de (Simon 'corecode' Schubert)
Date: Mon, 31 Mar 2008 12:41:30 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <200803311841.m2VIfQAI007579@nlpi001.prodigy.net>
Message-ID: <47F13DE4.10205@fs.ei.tum.de>

Matthew Dillon wrote:
>     What I suggest is that you convert struct proc from zone to kmalloc
>     first, and then look into a possible objcache adaptation.  kmalloc
>     is not slow.. it's a very fast allocator.  Objcache is probably a tad
>     faster but not by much.  Where objcache really wins is in not having
>     to completey reinitialize the allocated structures.

Could we please not move to kmalloc, but instead try to move all fast
path allocations to objcache?  I don't like the idea of allocating
everything with kmalloc.  Caching struct procs is not a bad thing itself.

cheers
  simon


Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00008.pgp
Type: application/octet-stream
Size: 252 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080331/ac328c08/attachment-0013.obj>

From hsu at FreeBSD.org  Mon Mar 31 12:59:05 2008
From: hsu at FreeBSD.org (Jeffrey Hsu)
Date: Mon, 31 Mar 2008 12:59:05 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <47F1357B.1070302@fs.ei.tum.de>
Message-ID: <200803311920.m2VJK5Ln018015@nlpi015.prodigy.net>

The object cache sits on top of a general-purpose memory allocator such
as kmalloc or zalloc and provides pre-initialized object caching functionality.
If you're not going to use the object caching functionality, you can just
call the underlying memory allocator directly.

							Jeffrey




From dillon at apollo.backplane.com  Mon Mar 31 16:17:19 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Mon, 31 Mar 2008 16:17:19 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <200803311841.m2VIfQAI007579@nlpi001.prodigy.net>
Message-ID: <200803312311.m2VNBumd029866@apollo.backplane.com>

:Could we please not move to kmalloc, but instead try to move all fast
:path allocations to objcache?  I don't like the idea of allocating
:everything with kmalloc.  Caching struct procs is not a bad thing itself.=
:
:
:cheers
:  simon

    I will state for the record that I'm fine with either objcache or
    kmalloc.  I agree with Jeff that using objcache for struct proc
    probably isn't necessary but I also agree that it would not hurt either,
    and if the intent is to optimize the initialization of the proc
    structure in the future then moving to objcache now would save us
    from having to do it later.

    So whichever method Nicolas wants to use is fine with me.

						-Matt




From hsu at dragonflybsd.org  Mon Mar 31 19:22:47 2008
From: hsu at dragonflybsd.org (Jeffrey Hsu)
Date: Mon, 31 Mar 2008 19:22:47 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <64fc43b0803311214u7da6bbb8xaf971de1a80e7258@mail.gmail.com>
Message-ID: <200804010218.m312IVUq003624@nlpi043.prodigy.net>

  >> Are there significant portions of the proc structure
  >> that can be restored to initialized state on object puts?

  > I planned to do this in a second step after getting rid of zones.

I'll all in favor of making more use of caching pre-initialized objects, so
if this is your objective, then please go ahead.  It's just that I'd convert
over to the object cache in one step.

  > I thought that even without  the pre-initialization part, objcache has
  > the advantage of pre-allocating set of objects (as zones) and is additionally
  > mp-safe (contrary to zones and, granted, as malloc()).

Well, the zone allocator is MP-safe.  It's not hard to lock up the places that
manipulate the linked-list of free items. Look for uses of the zlock field.

								Jeffrey




From tgen at netphreax.net  Sat Mar  1 12:57:53 2008
From: tgen at netphreax.net (Thomas E. Spanjaard)
Date: Sat, 1 Mar 2008 12:57:53 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: [Fwd: Project Support Open Source: $50 donation to support you      project]
In-Reply-To: <2468.192.168.0.242.1204346451.squirrel@www.shiningsilence.com>
Message-ID: <47C9C1B7.50203@netphreax.net>

Justin C. Sherrill wrote:
The "donation" happens after you place an "acknowledgement" on an open
source project's web page.  I'm putting those words in scare quotes
because I think it's a "payment" for an "advertisement".  The supplied
link has nothing to do with DragonFly, to say the least.

<a href="http://www.2insure4less.com /" title="We support FOSS software
projects.">Online Insurance Quotes</a>
To think our souls are only worth $50...
--
        Thomas E. Spanjaard
        tgen at netphreax.net
Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00000.pgp
Type: application/octet-stream
Size: 186 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080301/0d61e240/attachment-0014.obj>

From c.turner at 199technologies.org  Sat Mar  1 17:52:31 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Sat, 1 Mar 2008 17:52:31 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Misc. ACPI / suspend
Message-ID: <47CA073B.6020106@199technologies.org>

Wondering if anyone more well versed in the ACPI implementation could
comment on the applicability of:
http://lkml.org/lkml/2007/4/6/69

w/r/t the current state of the art in Dfly

(or BSD's in general)

Cheers!

- Chris




From elekktretterr at exemail.com.au  Sun Mar  2 00:41:25 2008
From: elekktretterr at exemail.com.au (Petr Janda)
Date: Sun, 2 Mar 2008 00:41:25 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: CARP question
Message-ID: <200803021934.21669.elekktretterr@exemail.com.au>

So Ive setup CARP on 2 DF-based mailservers. Installation went fine. Box 1 has 
adskew of 0 therefore it is the MASTER. Box 2 has adskew of 254, therefore is 
BACKUP.  If i down the carp0 interface on Box 1, then Box 2 carp interface 
gets promoted to MASTER. Then I up the carp interface on Box 1, logically Box 
2 should become BACKUP again as Box 1 becomes MASTER due to adskew set to 0.

However it doesnt happen. When carp0 interface on Box 1 is upped it becomes a 
BACKUP, not a MASTER even though according to adskew it should be MASTER.

What is the desired behaviour?

Cheers
Petr




From qhwt+dfly at les.ath.cx  Sun Mar  2 02:50:14 2008
From: qhwt+dfly at les.ath.cx (YONETANI Tomokazu)
Date: Sun, 2 Mar 2008 02:50:14 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: panic: assertion: hammer_btree_cmp(cursor->left_bound,	&cursor->node->ondisk->elms[0].leaf.base) <= 0 in btree_split_leaf
In-Reply-To: <200802232204.m1NM4cxd046264@apollo.backplane.com>
Message-ID: <20080302104554.GA22813@les.ath.cx>

Hi.
While trying to find a procedure to reliably reproduce the panic
I reported last time, I caught a different panic (uploaded at
 ~y0netan1/crash/9/ on my leaf account).  I wrote the following shell
script (make sure to edit variables DISKS and MOUNTPT before using this
script or it may trash your system):
  #!/bin/sh -ex
  DISKS="/dev/ad0s1f"
  MOUNTPT=/mnt/HAMMER

  cd /
  newfs_hammer -L TEST $DISKS
  for i in `seq 1 100`; do
	  mount_hammer $DISKS $MOUNTPT
	  /bin/rm -rf $MOUNTPT/??
	  (set +x; for x in `seq 1 10000`; do echo -n > $MOUNTPT/$x; done)
	  umount $MOUNTPT
  done

And the panic is triggered by rm command.
I'll try to see if it's possible to reproduce the last one without
unmounting then mounting the HAMMER fs.

Cheers.




From dillon at apollo.backplane.com  Sun Mar  2 13:25:33 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Sun, 2 Mar 2008 13:25:33 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: panic: assertion: hammer_btree_cmp(cursor->left_bound,	&cursor->node->ondisk->elms[0].leaf.base) <= 0 in btree_split_leaf
In-Reply-To: <200802232204.m1NM4cxd046264@apollo.backplane.com>
Message-ID: <200803022119.m22LJRCY037076@apollo.backplane.com>


:Hi.
:While trying to find a procedure to reliably reproduce the panic
:I reported last time, I caught a different panic (uploaded at
: ~y0netan1/crash/9/ on my leaf account).  I wrote the following shell
:script (make sure to edit variables DISKS and MOUNTPT before using this
:script or it may trash your system):

(from the core)

panic: assertion: node->lock.refs == 0 && node->ondisk == NULL in hammer_flush_buffer_nodes

    Yah, I've seen this failure.  Add a sync or two before the umount and
    tell me if it still occurs.  It's either a node reference leak somewhere
    or it is a race between bufdaemon and umount.  The assertions are really
    strict there precisely to catch those sorts of cases.

    Also note that the code to deal with a full HAMMMER filesystem has not
    been written yet (The failure you are reporting is unrelated to a full
    HAMMER filesystem, though, just mentioning it).

						-Matt





From dillon at apollo.backplane.com  Sun Mar  2 13:29:03 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Sun, 2 Mar 2008 13:29:03 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Misc. ACPI / suspend
In-Reply-To: <47CA073B.6020106@199technologies.org>
Message-ID: <200803022126.m22LQbfI037188@apollo.backplane.com>


:Wondering if anyone more well versed in the ACPI implementation could
:comment on the applicability of:
:
:http://lkml.org/lkml/2007/4/6/69
:
:w/r/t the current state of the art in Dfly
:
:(or BSD's in general)
:
:Cheers!
:
:- Chris

    I really have no idea re: this.  Suspension in general is not well
    supported by any of the BSDs.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From dillon at apollo.backplane.com  Sun Mar  2 13:34:05 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Sun, 2 Mar 2008 13:34:05 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: [Fwd: Project Support Open Source: $50 donation to support you      project]
In-Reply-To: <2468.192.168.0.242.1204346451.squirrel@www.shiningsilence.com>
Message-ID: <200803022131.m22LVOe9037250@apollo.backplane.com>

:..
:source project's web page.  I'm putting those words in scare quotes
:because I think it's a "payment" for an "advertisement".  The supplied
:link has nothing to do with DragonFly, to say the least.
:
:I don't think this is a good idea, obviously, and replied to that effect. 
:However, I wanted to put this on a DragonFly list, in part to show this
:strange thing, and in part because I'm not comfortable making
:administrative decisions on behalf of the Project without being open as
:possible about it.

    It doesn't really cry out to me either.

						-Matt





From wbh at conducive.org  Sun Mar  2 20:36:32 2008
From: wbh at conducive.org (Bill Hacker)
Date: Mon, 03 Mar 2008 04:36:32 +0000
Subject: Misc. ACPI / suspend
In-Reply-To: <47CA073B.6020106@199technologies.org>
Message-ID: <47cb8050$0$855$415eb37d@crater_reader.dragonflybsd.org>

Matthew Dillon wrote:
:Wondering if anyone more well versed in the ACPI implementation could
:comment on the applicability of:
:
:http://lkml.org/lkml/2007/4/6/69
:
:w/r/t the current state of the art in Dfly
:
:(or BSD's in general)
:
:Cheers!
:
:- Chris
    I really have no idea re: this.  Suspension in general is not well
    supported by any of the BSDs.
					-Matt
					Matthew Dillon 
					<dillon at backplane.com>


. . and there seems to be a bit of a 'Catch 22' there in any case.

If the BIOS can alter 'stuff' out of site of the OS it is parking, what 
does the existence of such a 'feature' do to a(ny) security model?

Seems to at least beg creating the option of setting a flag to 
specifically *prevent* suspend-to-disk/hibernation (and/or force a 
reboot on wake-up).

Just because one is paranoid....  etc

Bill





From matthias at dragonflybsd.org  Tue Mar  4 02:30:52 2008
From: matthias at dragonflybsd.org (Matthias Schmidt)
Date: Tue, 4 Mar 2008 02:30:52 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
Message-ID: <20080304102335.GI9833@staatsfeind.org>

Hi,

Google just announced its Summer of Code for 2008:

	http://code.google.com/soc/2008/

I think this would be a great opportunity for DragonFly to participate
as a mentoring organisation.  We could attract new developers and could
get code/work done.  Looking at the SoC results of the other BSDs most
of their projects were a success.  Of course, not all, but a reasonable
percentage.  See [1] and [2].

It is some extra work for us, but IMO the benefits outweigh the extra
work.  And yes, I would volunteer as a mentor.  What do others
(developers) think?  Any more volunteers? :)

Some project ideas that come into my mind.  More ideas are listed in the
wiki:  http://wiki.dragonflybsd.org/index.cgi/ProjectsPage

 * Fix all remaining bugs in dma(8) and implement all missing features
 * Add a driver for newer Intel Wireless cards (I think sephe@ would
   love that :)
 * Bring our ACPI stuff in shape.  Maybe suspend2disk ...

 * [Add your own thoughts here]

Cheers,

	Matthias

PS: I don't want to create a bikeshed here whether you like the SoC or
not :)

[1] http://code.google.com/soc/2007/freebsd/about.html
[2] http://code.google.com/soc/2007/netbsd/about.html




From corecode at fs.ei.tum.de  Tue Mar  4 04:46:14 2008
From: corecode at fs.ei.tum.de (Simon 'corecode' Schubert)
Date: Tue, 4 Mar 2008 04:46:14 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47CD4386.1000704@fs.ei.tum.de>

Matthias Schmidt wrote:
>  * [Add your own thoughts here]

MP lock removal for network stack

and for the system  (first profile, find hot spots, fix hot spots, repeat)

cheers
  simon




From c.turner at 199technologies.org  Tue Mar  4 06:02:20 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Tue, 4 Mar 2008 06:02:20 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47CD551E.1040604@199technologies.org>

Matthias Schmidt wrote:
Some project ideas that come into my mind.  More ideas are listed in the
wiki:  http://wiki.dragonflybsd.org/index.cgi/ProjectsPage
+1 acpi
+1 interrupt routing
+1 SMP / giant removal
+1 pf synchup with openbsd
though there are several others on the page that are good..

need to dig up my wiki login and place appropriately..

also: thinking the ZFS port should be removed from the page - makes 
sense to everyone else? (e.g. fragments effort w/r/t hammer)





From tgen at netphreax.net  Tue Mar  4 06:54:31 2008
From: tgen at netphreax.net (Thomas E. Spanjaard)
Date: Tue, 4 Mar 2008 06:54:31 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47CD615F.8010209@netphreax.net>

Matthias Schmidt wrote:
Google just announced its Summer of Code for 2008:

 * [Add your own thoughts here]
x86-64 port :).
--
        Thomas E. Spanjaard
        tgen at netphreax.net
Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00001.pgp
Type: application/octet-stream
Size: 186 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080304/0d921000/attachment-0014.obj>

From rdivacky at FreeBSD.org  Tue Mar  4 07:07:03 2008
From: rdivacky at FreeBSD.org (Roman Divacky)
Date: Tue, 4 Mar 2008 07:07:03 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <20080304150255.GA8831@freebsd.org>

On Tue, Mar 04, 2008 at 02:49:03PM +0000, Thomas E. Spanjaard wrote:
> Matthias Schmidt wrote:
> >Google just announced its Summer of Code for 2008:
> >
> > * [Add your own thoughts here]
> 
> x86-64 port :).

all those ideas are great and needed etc. but keep in
mind that the projects should be doable by students
who might see dfly for the very first time.

don't overestimate whats possible and select projects
that look realistic

Roman Divacky (former SoC student)




From justin at shiningsilence.com  Tue Mar  4 08:32:56 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Tue, 4 Mar 2008 08:32:56 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <60322.65.106.147.226.1204648095.squirrel@www.shiningsilence.com>

On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
> Hi,
>
> Google just announced its Summer of Code for 2008:
>
> 	http://code.google.com/soc/2008/
>
> I think this would be a great opportunity for DragonFly to participate
> as a mentoring organisation.  We could attract new developers and could
> get code/work done.  Looking at the SoC results of the other BSDs most
> of their projects were a success.  Of course, not all, but a reasonable
> percentage.  See [1] and [2].

We've applied in previous years - Jeff Hsu did one year, and I put
together the application last year.  The hardest thing to find was
students (and they are the thing that helps SoC applications a lot, I
think).

Any student volunteers?  We have mentors.





From rluciani at gmail.com  Tue Mar  4 09:38:29 2008
From: rluciani at gmail.com (Robert Luciani)
Date: Tue, 04 Mar 2008 18:38:29 +0100
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47cd8915$0$854$415eb37d@crater_reader.dragonflybsd.org>

Justin C. Sherrill wrote:
> On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
>> Hi,
>>
>> Google just announced its Summer of Code for 2008:
>>
>> 	http://code.google.com/soc/2008/
>>
>> I think this would be a great opportunity for DragonFly to participate
>> as a mentoring organisation.  We could attract new developers and could
>> get code/work done.  Looking at the SoC results of the other BSDs most
>> of their projects were a success.  Of course, not all, but a reasonable
>> percentage.  See [1] and [2].
> 
> We've applied in previous years - Jeff Hsu did one year, and I put
> together the application last year.  The hardest thing to find was
> students (and they are the thing that helps SoC applications a lot, I
> think).
> 
> Any student volunteers?  We have mentors.
> 

bingo

-- 
Robert Luciani
Chalmers University of Technology, SWE
Department of Computer Science and Engineering
http://www.rluciani.com/public.key




From sdavtaker at gmail.com  Tue Mar  4 09:31:08 2008
From: sdavtaker at gmail.com (=?UTF-8?Q?Sd=C3=A4vtaker?=)
Date: Tue, 4 Mar 2008 09:31:08 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <c37d69f60803040926k206218a3kb8496d0cd18148bd@mail.gmail.com>

If you mentor, i will apply for coder :-)
Still in last year of university. :-)
Sdav

On Tue, Mar 4, 2008 at 1:28 PM, Justin C. Sherrill
<justin at shiningsilence.com> wrote:
> On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
>  > Hi,
>  >
>  > Google just announced its Summer of Code for 2008:
>  >
>  >       http://code.google.com/soc/2008/
>  >
>  > I think this would be a great opportunity for DragonFly to participate
>  > as a mentoring organisation.  We could attract new developers and could
>  > get code/work done.  Looking at the SoC results of the other BSDs most
>  > of their projects were a success.  Of course, not all, but a reasonable
>  > percentage.  See [1] and [2].
>
>  We've applied in previous years - Jeff Hsu did one year, and I put
>  together the application last year.  The hardest thing to find was
>  students (and they are the thing that helps SoC applications a lot, I
>  think).
>
>  Any student volunteers?  We have mentors.
>
>



-- 
Sd?vtaker prays to Rikku goddess for a good treasure.



From rluciani at gmail.com  Tue Mar  4 09:44:02 2008
From: rluciani at gmail.com (Robert Luciani)
Date: Tue, 04 Mar 2008 18:44:02 +0100
Subject: google soc "DragonFly"
Message-ID: <47cd8a63$0$855$415eb37d@crater_reader.dragonflybsd.org>

On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
> > Hi,
> >
> > Google just announced its Summer of Code for 2008:
> >
> > 	http://code.google.com/soc/2008/
> >
> > I think this would be a great opportunity for DragonFly to participate
> > as a mentoring organisation.  We could attract new developers and could
> > get code/work done.  Looking at the SoC results of the other BSDs most
> > of their projects were a success.  Of course, not all, but a reasonable
> > percentage.  See [1] and [2].

We've applied in previous years - Jeff Hsu did one year, and I put
together the application last year.  The hardest thing to find was
students (and they are the thing that helps SoC applications a lot, I
think).

Any student volunteers?  We have mentors.


-- 
Robert Luciani
Chalmers University of Technology, SWE
Department of Computer Science and Engineering
http://www.rluciani.com/public.key




From rluciani at gmail.com  Tue Mar  4 10:04:14 2008
From: rluciani at gmail.com (Robert Luciani)
Date: Tue, 04 Mar 2008 19:04:14 +0100
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47cd8f1f$0$856$415eb37d@crater_reader.dragonflybsd.org>

Robert Luciani wrote:
> Justin C. Sherrill wrote:
>> On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
>>> Hi,
>>>
>>> Google just announced its Summer of Code for 2008:
>>>
>>> 	http://code.google.com/soc/2008/
>>>
>>> I think this would be a great opportunity for DragonFly to participate
>>> as a mentoring organisation.  We could attract new developers and could
>>> get code/work done.  Looking at the SoC results of the other BSDs most
>>> of their projects were a success.  Of course, not all, but a reasonable
>>> percentage.  See [1] and [2].
>> We've applied in previous years - Jeff Hsu did one year, and I put
>> together the application last year.  The hardest thing to find was
>> students (and they are the thing that helps SoC applications a lot, I
>> think).
>>
>> Any student volunteers?  We have mentors.
>>
> 
> bingo
> 
My girlfriend Danwei noted that she would also like partake in the SoC.
She's studying IT here at Chalmers and will join the mailing list shortly.
-- 
Robert Luciani
Chalmers University of Technology, SWE
Department of Computer Science and Engineering
http://www.rluciani.com/public.key




From dillon at apollo.backplane.com  Tue Mar  4 13:08:30 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Tue, 4 Mar 2008 13:08:30 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Going to have to roll 1.12.1
Message-ID: <200803042104.m24L43g1065278@apollo.backplane.com>

    Due to a critical bug in sendmail that can cause it to seg-fault I will
    be rolling 1.12.1 as soon as I get verification that the current
    fix deals with it.

						-Matt





From sdavtaker at gmail.com  Tue Mar  4 17:40:43 2008
From: sdavtaker at gmail.com (=?UTF-8?B?U2TDpHZ0YWtlcg==?=)
Date: Tue, 4 Mar 2008 17:40:43 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: [Fwd: Project Support Open Source: $50 donation to support you  project]
In-Reply-To: <2468.192.168.0.242.1204346451.squirrel@www.shiningsilence.com>
Message-ID: <47CDF8D1.9070100@gmail.com>

50 bucks?
Come on...
You can get a meal a lot more expensive than that just going to a free 
HP conference about linux and you only have to rent your soul 3-5 hours ;-)
Sdav

Matthew Dillon escribi?:
:..
:source project's web page.  I'm putting those words in scare quotes
:because I think it's a "payment" for an "advertisement".  The supplied
:link has nothing to do with DragonFly, to say the least.
:
:I don't think this is a good idea, obviously, and replied to that effect. 
:However, I wanted to put this on a DragonFly list, in part to show this
:strange thing, and in part because I'm not comfortable making
:administrative decisions on behalf of the Project without being open as
:possible about it.

    It doesn't really cry out to me either.

						-Matt

  






From sdavtaker at gmail.com  Tue Mar  4 17:56:35 2008
From: sdavtaker at gmail.com (=?UTF-8?B?U2TDpHZ0YWtlcg==?=)
Date: Tue, 4 Mar 2008 17:56:35 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47CDFCCE.1010106@gmail.com>

A cute idea for for GSOC would be to finish the installer.
We were talking about this in my local BUG, we trying to find out how to 
help on that from here.
There is a few missing features in the CD.

   * FDISK, you need to create the slides from another OS before
     install DFBSD, i think port FDisk from FBSD or any *BSD will solve it.
   * Add to the make release a way to add some custom applications to
     the released liveCD (suppose you want to add nmap or ssh or
     something just to use as test disk in some enviroment).
   * Make the installer a little more customizable, and maybe w/ a GUI
     (I like a lot the console approach, but GUI installer will be a
     popularity move, DFBSD w/X makes a Desktop machine work, actually
     im using it that way and really like it).
I think those projects can be done in a SOC by students (like me) with a 
little guide.
Im a lot more interested in things network related and kernel, but i 
dont mind to work on those things, they need to be done some day.
What u think?
Sdav

Robert Luciani escribi?:
Robert Luciani wrote:
  
Justin C. Sherrill wrote:
    
On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
      
Hi,

Google just announced its Summer of Code for 2008:

	http://code.google.com/soc/2008/

I think this would be a great opportunity for DragonFly to participate
as a mentoring organisation.  We could attract new developers and could
get code/work done.  Looking at the SoC results of the other BSDs most
of their projects were a success.  Of course, not all, but a reasonable
percentage.  See [1] and [2].
        
We've applied in previous years - Jeff Hsu did one year, and I put
together the application last year.  The hardest thing to find was
students (and they are the thing that helps SoC applications a lot, I
think).
Any student volunteers?  We have mentors.

      
bingo

    
My girlfriend Danwei noted that she would also like partake in the SoC.
She's studying IT here at Chalmers and will join the mailing list shortly.
  






From c.turner at 199technologies.org  Tue Mar  4 18:30:53 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Tue, 4 Mar 2008 18:30:53 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47CE04C9.1010902@199technologies.org>

Justin C. Sherrill wrote:
together the application last year.  The hardest thing to find was
students (and they are the thing that helps SoC applications a lot, I
think).
umm.. if google wants to send me back to school, I'll sign up - hows 
that for a fair trade :?






From wbh at conducive.org  Tue Mar  4 23:52:13 2008
From: wbh at conducive.org (Bill Hacker)
Date: Wed, 05 Mar 2008 07:52:13 +0000
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47ce512e$0$855$415eb37d@crater_reader.dragonflybsd.org>

Sd?vtaker wrote:
A cute idea for for GSOC would be to finish the installer.
We were talking about this in my local BUG, we trying to find out how to 
help on that from here.
There is a few missing features in the CD.

   * FDISK, you need to create the slides from another OS before
     install DFBSD, i think port FDisk from FBSD or any *BSD will solve it.
I'd rather see that 'reversed' - i.e. - build a more capable fdisk in 
DFLY with hope that it might be seen worth importing into Free/Net/Open, 
or *at least* be able to do a more flexible job than those now do.

And disklabels as well. Hand in glove.

Here's why:

- At the moment, working with Free, Open, DFLY, and OpenSolaris on the 
same HDD requires a bit of acrobatics.

- There seems to now be greater divergence between/among the *BSD's as 
to being able to read each other's disklabels, mount and use each 
other's 'flavor' of FFS/UFS (not to mention Apple's implementation of 
UFS) than there is among the vast multitude of Linux ext2/3 denizens.

Even to the point where use of a *Linux* fs is the more universal way 
for being able to share mounts among the *BSD's. Think detached drives. 
And no - FAT is not all that practical for several reasons.

- DFLY currently has the most fine-grain ability to create slices and 
partitions. But the others cannot all (any?) read those.

'progress' w/r any of the *BSD's direction as to changes, improvements 
(or not) in their once-common-ancestry fs & disklabels need not be 
sacrificed.

I'm not holding out wish or hope for all players agreeing to return to 
'one sacred way'. Nor 'one new universal fs'. Neither is gonna happen.

But a 'legacy compatible' or least-common-denominator mode would do fine 
- most especially for portable / SAN devices.

So - how about a 'flexible' DFLY fdisk to go along with a 'flexible' 
disklabel that could adapt to whatever it found / was told to create?

JM2CW - but that *might* be a good place to get a cross-*BSD team together.

*snip* (other good stuff)

Bill Hacker




From matthias at dragonflybsd.org  Wed Mar  5 01:02:43 2008
From: matthias at dragonflybsd.org (Matthias Schmidt)
Date: Wed, 5 Mar 2008 01:02:43 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <20080305085747.GJ9833@staatsfeind.org>

Hi,

* Justin C. Sherrill wrote:
> 
> We've applied in previous years - Jeff Hsu did one year, and I put
> together the application last year.  The hardest thing to find was
> students (and they are the thing that helps SoC applications a lot, I
> think).

This is good to know, so we could coordinate that if we have enough
mentors and projects?!?  I put together a small text in the wiki:

http://wiki.dragonflybsd.org/index.cgi/GoogleSoC2008

Feel free to add project or missing stuff.  I'm sure I missed a lot of
things :)

> Any student volunteers?  We have mentors.

According to the discussion we could have some students, who would be a
mentor (besides me)?

Regards

	Matthias





From sdavtaker at gmail.com  Wed Mar  5 06:28:37 2008
From: sdavtaker at gmail.com (=?UTF-8?Q?Sd=C3=A4vtaker?=)
Date: Wed, 5 Mar 2008 06:28:37 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <c37d69f60803050624kd86d3d0w3b44a02d0e5a5391@mail.gmail.com>

<quote>
Write a driver (from scratch) for Intel 3945 wireless device
Mentor: Sepherosa Ziehau
</quote>

Yes yes yes, i want to :-)
Someone else planning to mentor in drivers coding?
Sdav

On Wed, Mar 5, 2008 at 5:57 AM, Matthias Schmidt
<matthias at dragonflybsd.org> wrote:
> Hi,
>
>
>  * Justin C. Sherrill wrote:
>  >
>  > We've applied in previous years - Jeff Hsu did one year, and I put
>  > together the application last year.  The hardest thing to find was
>  > students (and they are the thing that helps SoC applications a lot, I
>  > think).
>
>  This is good to know, so we could coordinate that if we have enough
>  mentors and projects?!?  I put together a small text in the wiki:
>
>  http://wiki.dragonflybsd.org/index.cgi/GoogleSoC2008
>
>  Feel free to add project or missing stuff.  I'm sure I missed a lot of
>  things :)
>
>
>  > Any student volunteers?  We have mentors.
>
>  According to the discussion we could have some students, who would be a
>  mentor (besides me)?
>
>  Regards
>
>         Matthias
>
>



-- 
Sd?vtaker prays to Rikku goddess for a good treasure.



From rluciani at gmail.com  Wed Mar  5 10:56:42 2008
From: rluciani at gmail.com (Robert Luciani)
Date: Wed, 05 Mar 2008 19:56:42 +0100
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47ceecea$0$847$415eb37d@crater_reader.dragonflybsd.org>

Sd?vtaker wrote:
> <quote>
> Write a driver (from scratch) for Intel 3945 wireless device
> Mentor: Sepherosa Ziehau
> </quote>
> 
> Yes yes yes, i want to :-)
> Someone else planning to mentor in drivers coding?
> Sdav
> 
> On Wed, Mar 5, 2008 at 5:57 AM, Matthias Schmidt
> <matthias at dragonflybsd.org> wrote:
>> Hi,
>>
>>
>>  * Justin C. Sherrill wrote:
>>  >
>>  > We've applied in previous years - Jeff Hsu did one year, and I put
>>  > together the application last year.  The hardest thing to find was
>>  > students (and they are the thing that helps SoC applications a lot, I
>>  > think).
>>
>>  This is good to know, so we could coordinate that if we have enough
>>  mentors and projects?!?  I put together a small text in the wiki:
>>
>>  http://wiki.dragonflybsd.org/index.cgi/GoogleSoC2008
>>
>>  Feel free to add project or missing stuff.  I'm sure I missed a lot of
>>  things :)
>>
>>
>>  > Any student volunteers?  We have mentors.
>>
>>  According to the discussion we could have some students, who would be a
>>  mentor (besides me)?
>>
>>  Regards
>>
>>         Matthias
>>
>>
> 
> 
>

IF someone starts to write a 3945 Intel driver,
please keep the newer 4965 in mind too.

-- 
Robert Luciani
Chalmers University of Technology, SWE
Department of Computer Science and Engineering
http://www.rluciani.com/public.key




From joerg at britannica.bec.de  Wed Mar  5 12:01:05 2008
From: joerg at britannica.bec.de (Joerg Sonnenberger)
Date: Wed, 5 Mar 2008 12:01:05 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <20080305195711.GA9981@britannica.bec.de>

On Wed, Mar 05, 2008 at 07:56:42PM +0100, Robert Luciani wrote:
> IF someone starts to write a 3945 Intel driver,
> please keep the newer 4965 in mind too.

NetBSD's wpi works quite well. The hardware is quite different from
4945.

Joerg




From sepherosa at gmail.com  Wed Mar  5 17:48:50 2008
From: sepherosa at gmail.com (Sepherosa Ziehau)
Date: Wed, 5 Mar 2008 17:48:50 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <ea7b9c170803051744u22b09484ofc994f034f11df3b@mail.gmail.com>

On Thu, Mar 6, 2008 at 2:56 AM, Robert Luciani <rluciani at gmail.com> wrote:
>  IF someone starts to write a 3945 Intel driver,

"IF" you know that trying to fix any wired bugs in certain drivers
(e.g. ipw, ral) will require you to read through all of the vendor's
linux code (yes, even including register values and position), i.e.
there is not much difference between writing one from scratch and
porting+fixing_bugs, then you probably will not put "IF" at the start
of your sentence.
If what I said sounded too harsh to you, then I was sorry.

>  please keep the newer 4965 in mind too.

Will do, once generic 11n support is brought in from freebsd.

Best Regards,
sephe

-- 
Live Free or Die




From saw at online.de  Thu Mar  6 05:34:14 2008
From: saw at online.de (Sascha Wildner)
Date: Thu, 06 Mar 2008 14:34:14 +0100
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
Message-ID: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>

Hi all,

this is probably as good a moment as any to come out of the forest with 
this. The patch at

http://leaf.dragonflybsd.org/~swildner/nrelease_gui.diff

adds some code to nrelease/ to build a LiveCD with xorg and so on 
(currently, only the xorg metapackages and fluxbox are added). In order 
to build one, you need a local dir with the pkgsrc binary packages (see 
below).

The following commands should then do the trick:

cd /usr/src
make buildworld
make buildkernel
cd nrelease
patch -p 0 </path/to/the/patch
make PKGSRC_PKG_PATH=/path/to/packages/dir/All realquick gui
The resulting ISO will be in /usr/release/dfly-gui.iso then. It will not 
boot into xorg automatically (although this is easily possible), so you 
need to login as root and do startx.

As of now, this all is kind of basic, more a proof of concept than 
anything else. As our release framework installs packages via chroot, 
the current setup just copies _all_ packages to the chroot before 
installing (kind of a hack).

That said, I'm now primarily interested in opinions/ideas/... about the 
direction this should take. Which packages would we like to see on the 
CD? Should it be a generic setup with the "most common things" 
installed, so a system can be quickly setup by the installer (which will 
cpdup /usr/pkg). Or should it be a more specialized set of tools? Or 
even as many packages as possible (Live DVD?). Etc., etc.

Before continuing on it, I'm really interested in people's input so 
don't hold anything back, please. :)

Sascha

--
http://yoyodyne.ath.cx



From rluciani at gmail.com  Thu Mar  6 06:42:03 2008
From: rluciani at gmail.com (Robert Luciani)
Date: Thu, 06 Mar 2008 15:42:03 +0100
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <47d002bc$0$847$415eb37d@crater_reader.dragonflybsd.org>

Sascha Wildner wrote:
> Hi all,
> 
> this is probably as good a moment as any to come out of the forest with
> this. The patch at
> 
> http://leaf.dragonflybsd.org/~swildner/nrelease_gui.diff
> 
> adds some code to nrelease/ to build a LiveCD with xorg and so on
> (currently, only the xorg metapackages and fluxbox are added). In order
> to build one, you need a local dir with the pkgsrc binary packages (see
> below).
> 
> The following commands should then do the trick:
> 
> cd /usr/src
> make buildworld
> make buildkernel
> cd nrelease
> patch -p 0 </path/to/the/patch
> make PKGSRC_PKG_PATH=/path/to/packages/dir/All realquick gui
> 
> The resulting ISO will be in /usr/release/dfly-gui.iso then. It will not
> boot into xorg automatically (although this is easily possible), so you
> need to login as root and do startx.
> 
> As of now, this all is kind of basic, more a proof of concept than
> anything else. As our release framework installs packages via chroot,
> the current setup just copies _all_ packages to the chroot before
> installing (kind of a hack).
> 
> That said, I'm now primarily interested in opinions/ideas/... about the
> direction this should take. Which packages would we like to see on the
> CD? Should it be a generic setup with the "most common things"
> installed, so a system can be quickly setup by the installer (which will
> cpdup /usr/pkg). Or should it be a more specialized set of tools? Or
> even as many packages as possible (Live DVD?). Etc., etc.
> 
> Before continuing on it, I'm really interested in people's input so
> don't hold anything back, please. :)
> 
> Sascha
> 

I think the main point of such a live-cd would be to test
dragonfly-specific features such as vkernels and more. Mplayer and
OpenOffic work the same on all platforms, so they might not be super
important, while irssi, firefox, networking tools, vim, a few more
shells/terminals might make it easier to for people to quickly gauge if
they can reproduce their current productivity and also what is new.

And if the point of a livecd is to test that kind of stuff, then it
would be nice for it to have a kernel that supports as much as possible
like ALTQ, and drivers.

Also if it has lots and lots of programs (thinking multimedia, java,
etc..) it might be hard to keep the future x64 and x86 live-cds on par.
Gentoo had this problem many years ago and it was very bothersome.

-- 
Robert Luciani
Chalmers University of Technology, SWE
Department of Computer Science and Engineering
http://www.rluciani.com/public.key




From matthias at dragonflybsd.org  Thu Mar  6 07:12:43 2008
From: matthias at dragonflybsd.org (Matthias Schmidt)
Date: Thu, 6 Mar 2008 07:12:43 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <20080306150757.GN9833@staatsfeind.org>

* Sascha Wildner wrote:
> Hi all,
> 
> this is probably as good a moment as any to come out of the forest with this. 
> The patch at
> 
> http://leaf.dragonflybsd.org/~swildner/nrelease_gui.diff
> 
> adds some code to nrelease/ to build a LiveCD with xorg and so on (currently, 
> only the xorg metapackages and fluxbox are added). In order to build one, you 
> need a local dir with the pkgsrc binary packages (see below).

Great work Sascha.

I agree with Robert on most of his stated points.
It would be nice to see some DragonFly specific features on the CD
(although I'm not sure if that will work for all features).  A little
environment where most Unix users feel at home (fluxbox, xfce, firefox,
thunderbird, gvim) should be enough.

Big applications like OO.org, java etc won't work because they are not
available as pkgsrc packages neither is it possible to compile them on
DragonFly.  At least to my knowledge.

Regards

	Matthias




From dillon at apollo.backplane.com  Thu Mar  6 09:31:52 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Thu, 6 Mar 2008 09:31:52 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <200803061728.m26HSR3O091809@apollo.backplane.com>


:Hi all,
:
:this is probably as good a moment as any to come out of the forest with 
:this. The patch at
:
:http://leaf.dragonflybsd.org/~swildner/nrelease_gui.diff
:
:adds some code to nrelease/ to build a LiveCD with xorg and so on 
:(currently, only the xorg metapackages and fluxbox are added). In order 
:to build one, you need a local dir with the pkgsrc binary packages (see 
:below).
:
:The following commands should then do the trick:

    It looks reasonable, though the package copy has to be tightened
    up a bit I think.

:...
:installed, so a system can be quickly setup by the installer (which will 
:cpdup /usr/pkg). Or should it be a more specialized set of tools? Or 
:even as many packages as possible (Live DVD?). Etc., etc.
:
:Before continuing on it, I'm really interested in people's input so 
:don't hold anything back, please. :)
:
:Sascha

    I think this is an excellent time to work up a DVD build and to
    add various 'flavor' extras.  So, e.g.:

	make installer gui gui_extras release dvd

    (All 'dvd' would do is generate a dvd compatible image for burning to
    dvd instead of cd).  I did a quick perusal of what I have on my
    workstation:

    * X
    * Firefox
    * Linux emulation
    * Open Office (linux version)
    * fvwm2
    * xpdf
    * freetype2

    I'd also suggest some image editing tools like gimp, and maybe the KDE
    gui suite.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From justin at shiningsilence.com  Thu Mar  6 09:42:44 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Thu, 6 Mar 2008 09:42:44 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <55427.65.106.147.226.1204825168.squirrel@www.shiningsilence.com>

On Thu, March 6, 2008 8:34 am, Sascha Wildner wrote:

> That said, I'm now primarily interested in opinions/ideas/... about the
> direction this should take. Which packages would we like to see on the
> CD? Should it be a generic setup with the "most common things"
> installed, so a system can be quickly setup by the installer (which will
> cpdup /usr/pkg). Or should it be a more specialized set of tools? Or
> even as many packages as possible (Live DVD?). Etc., etc.

What Robert said is good - whatever's needed to enable DragonFly-specific
features.  Along with that would be some sort of documentation (a README? 
A HTML file on whatever desktop we provide) that points people at the
different DragonFly tools, so they know what to try and how to try it.

There's going to be some percentage of people who try DragonFly who don't
know about vkernels, for instance, but there's our chance to educate them.
 I'm probably volunteering myself, aren't I?





From sdavtaker at gmail.com  Thu Mar  6 09:50:09 2008
From: sdavtaker at gmail.com (=?UTF-8?Q?Sd=C3=A4vtaker?=)
Date: Thu, 6 Mar 2008 09:50:09 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <c37d69f60803060947t110750c0sd6b542ea505d188d@mail.gmail.com>

Cool Sascha :-)
I just posted about this 1 or 2 days ago in the SOC project ideas thread.
Want to mentor this one? ;-)
Damian

On Thu, Mar 6, 2008 at 2:28 PM, Matthew Dillon
<dillon at apollo.backplane.com> wrote:
>
>  :Hi all,
>
> :
>  :this is probably as good a moment as any to come out of the forest with
>  :this. The patch at
>  :
>  :http://leaf.dragonflybsd.org/~swildner/nrelease_gui.diff
>  :
>  :adds some code to nrelease/ to build a LiveCD with xorg and so on
>  :(currently, only the xorg metapackages and fluxbox are added). In order
>  :to build one, you need a local dir with the pkgsrc binary packages (see
>  :below).
>  :
>  :The following commands should then do the trick:
>
>     It looks reasonable, though the package copy has to be tightened
>     up a bit I think.
>
>  :...
>  :installed, so a system can be quickly setup by the installer (which will
>
> :cpdup /usr/pkg). Or should it be a more specialized set of tools? Or
>  :even as many packages as possible (Live DVD?). Etc., etc.
>  :
>  :Before continuing on it, I'm really interested in people's input so
>  :don't hold anything back, please. :)
>  :
>  :Sascha
>
>     I think this is an excellent time to work up a DVD build and to
>     add various 'flavor' extras.  So, e.g.:
>
>         make installer gui gui_extras release dvd
>
>     (All 'dvd' would do is generate a dvd compatible image for burning to
>     dvd instead of cd).  I did a quick perusal of what I have on my
>     workstation:
>
>     * X
>     * Firefox
>     * Linux emulation
>     * Open Office (linux version)
>     * fvwm2
>     * xpdf
>     * freetype2
>
>     I'd also suggest some image editing tools like gimp, and maybe the KDE
>     gui suite.
>
>                                         -Matt
>                                         Matthew Dillon
>                                         <dillon at backplane.com>
>



-- 
Sd?vtaker prays to Rikku goddess for a good treasure.



From saw at online.de  Thu Mar  6 11:54:01 2008
From: saw at online.de (Sascha Wildner)
Date: Thu, 06 Mar 2008 20:54:01 +0100
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <47d04ba2$0$856$415eb37d@crater_reader.dragonflybsd.org>

Matthew Dillon wrote:
    It looks reasonable, though the package copy has to be tightened
    up a bit I think.
It looks as if it would work with mount_null'ing the chroot's 
/tmp/packages. I'll have a better patch ready tomorrow.

Sascha

--
http://yoyodyne.ath.cx



From c.turner at 199technologies.org  Thu Mar  6 19:11:44 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Thu, 6 Mar 2008 19:11:44 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Misc. ACPI / suspend
In-Reply-To: <47CA073B.6020106@199technologies.org>
Message-ID: <47D0B079.3060905@199technologies.org>

Chris Turner wrote:
Wondering if anyone more well versed in the ACPI implementation could
comment on the applicability of:
http://lkml.org/lkml/2007/4/6/69

Doing a little digging, it seems like

. /platform/pc32/i386/i686_mem.c

*might* have the necessary infrastructure to remap the MTRR's per the 
thread referenced,

but:

. /platform/pc32/acpica5/acpi_wakeup.c

doesn't seem to be using this infrastructure..

I'm no where near reaching an understanding of this yet,
but I'm wondering 3 things:
1) does anyone have ACPI (instead of APM)
   sleep / suspend / wakeup working on Dfly ?
2) If so, what machines are being used ?
3) Same question for other BSDs - my understanding is NetBSD is most
   'advanced' w/r/t power managment - but I'm not 100% on this ...
would looove to have a sleeping / resuming / scaling laptop running some 
BSD flavor.. am willing to work towards that end, esp. w/r/t Dfly -
trying to chart a course to figguring this out.

Thanks all,

- Chris




From c.turner at 199technologies.org  Thu Mar  6 19:12:33 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Thu, 6 Mar 2008 19:12:33 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: PCI Bios / Interrupt remapping / etc
Message-ID: <47D0B211.6000002@199technologies.org>

Doing a bit of digging here for my long-standing CBB+SIO interupt and 
buffer problem -

one machine I've tested against was an OpenBSD machine, which didn't
always work to handle the cardbus sio card on a PCI cardbus adapter
-

tuning up some of the device flags in:

http://www.openbsd.org/cgi-bin/man.cgi?query=pcibios&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=html

seems to have alleviated the problem for that os..

I'm just only starting to get up to speed on how DF handles these types 
of things (namely initial PIC / interrupt layout at boot time device 
enumeration), but am wondering if anyone familiar with this area of the 
code has any comments / advice w/r/t the capabilities of the DF bios 
drivers
and the various quirks / fixup mentioned in the link above..

looking to possibly investigate fixing up some of these issues over time.

Thanks

- Chris







From pavalos at theshell.com  Fri Mar  7 01:14:55 2008
From: pavalos at theshell.com (Peter Avalos)
Date: Fri, 7 Mar 2008 01:14:55 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: cam locking
Message-ID: <20080307091024.GC1652@ylem.theshell.com>

So I've been working on locking up cam using lockmgr locks, and here's
what I have so far:

http://www.theshell.com/~pavalos/wip/cam-lock.patch

Most of the work is obtained from FreeBSD.  I've only been running this
on my SCSI machine for a day, but because the patch is so large, I wanted
to make it available for people to review if they have some spare time.

Thanks,
Peter
Attachment:
pgp00002.pgp
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00002.pgp
Type: application/octet-stream
Size: 197 bytes
Desc: "Description: PGP signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080307/9a17ecd8/attachment-0014.obj>

From jspringe at uos.de  Fri Mar  7 03:25:17 2008
From: jspringe at uos.de (Jost Tobias Springenberg)
Date: Fri, 7 Mar 2008 12:25:17 +0100
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <20080307122517.72c9e2b1.jspringe@uos.de>

On Tue, 4 Mar 2008 11:28:15 -0500 (EST)
"Justin C. Sherrill" <justin at shiningsilence.com> wrote:

> On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
> > Hi,
> >
> > Google just announced its Summer of Code for 2008:
> >
> > 	http://code.google.com/soc/2008/
> >
> > I think this would be a great opportunity for DragonFly to participate
> > as a mentoring organisation.  We could attract new developers and could
> > get code/work done.  Looking at the SoC results of the other BSDs most
> > of their projects were a success.  Of course, not all, but a reasonable
> > percentage.  See [1] and [2].
> 
> We've applied in previous years - Jeff Hsu did one year, and I put
> together the application last year.  The hardest thing to find was
> students (and they are the thing that helps SoC applications a lot, I
> think).
> 
> Any student volunteers?  We have mentors.
> 

I read this mailing list for quite a while now and thought about contributing stuff
to DFfly several times, so yes why not take this opportunity if it's there.

-- 
Jost Tobias Springenberg <jspringe at uos.de>




From tgen at netphreax.net  Fri Mar  7 05:17:27 2008
From: tgen at netphreax.net (Thomas E. Spanjaard)
Date: Fri, 7 Mar 2008 05:17:27 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: PCI Bios / Interrupt remapping / etc
In-Reply-To: <47D0B211.6000002@199technologies.org>
Message-ID: <47D13FB4.5080306@netphreax.net>

Chris Turner wrote:
Doing a bit of digging here for my long-standing CBB+SIO interupt and 
buffer problem -

one machine I've tested against was an OpenBSD machine, which didn't
always work to handle the cardbus sio card on a PCI cardbus adapter
-

tuning up some of the device flags in:

http://www.openbsd.org/cgi-bin/man.cgi?query=pcibios&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=html 

seems to have alleviated the problem for that os..

I'm just only starting to get up to speed on how DF handles these types 
of things (namely initial PIC / interrupt layout at boot time device 
enumeration), but am wondering if anyone familiar with this area of the 
code has any comments / advice w/r/t the capabilities of the DF bios 
drivers
and the various quirks / fixup mentioned in the link above..

looking to possibly investigate fixing up some of these issues over time.
Our code that handles issues like this (in cases where you're not using 
APICs, just PICs and PIRs) lives in bus/pci/i386/. Not that running 
without APIC support is all that common on modern machines anymore...
--
        Thomas E. Spanjaard
        tgen at netphreax.net
Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00003.pgp
Type: application/octet-stream
Size: 186 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080307/61366b5c/attachment-0014.obj>

From tgen at netphreax.net  Fri Mar  7 05:16:51 2008
From: tgen at netphreax.net (Thomas E. Spanjaard)
Date: Fri, 7 Mar 2008 05:16:51 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Misc. ACPI / suspend
In-Reply-To: <47CA073B.6020106@199technologies.org>
Message-ID: <47D13F07.9080308@netphreax.net>

Chris Turner wrote:
1) does anyone have ACPI (instead of APM)
   sleep / suspend / wakeup working on Dfly ?
2) If so, what machines are being used ?
3) Same question for other BSDs - my understanding is NetBSD is most
   'advanced' w/r/t power managment - but I'm not 100% on this ...
would looove to have a sleeping / resuming / scaling laptop running some 
BSD flavor.. am willing to work towards that end, esp. w/r/t Dfly -
trying to chart a course to figguring this out.
I have ACPI S3 suspend working like a charm on my IBM ThinkPad R40 
(Pentium M "Banias" 1.3GHz, speedstepping works just fine), running 
NetBSD 3.99.21.
--
        Thomas E. Spanjaard
        tgen at netphreax.net
Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00004.pgp
Type: application/octet-stream
Size: 186 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080307/de3e5104/attachment-0014.obj>

From civilizd at gmail.com  Fri Mar  7 09:06:41 2008
From: civilizd at gmail.com (Vita "CiV" Cizek)
Date: Fri, 7 Mar 2008 09:06:41 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <98d564710803070853q1c73d795m6e6c5cc5049fa099@mail.gmail.com>

>  Any student volunteers?  We have mentors.
>
I am interested too, especially in some kernel-related work.




From justin at shiningsilence.com  Sat Mar  8 12:07:51 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Sat, 8 Mar 2008 12:07:51 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google SoC 2008 - mentors mentors mentors
Message-ID: <51558.192.168.0.252.1205006403.squirrel@www.shiningsilence.com>

If you are willing to mentor for the Google 2008 Summer of Code, please
speak up.  Right now we have: (from our wiki page)

Matthias
Sephe
TGEN
corecode

Part of the application process includes naming people as mentors (student
applications come later), so I want to get as complete a list as possible.

The application is due on the 12th, so if you want to mentor, now's the
time to say so.

Google's SoC FAQ is here: http://code.google.com/soc/2008/faqs.html

Our wiki page is here: http://wiki.dragonflybsd.org/index.cgi/GoogleSoC2008

- much credit to Matthias and others for getting that set up.





From saw at online.de  Sat Mar  8 14:26:07 2008
From: saw at online.de (Sascha Wildner)
Date: Sat, 08 Mar 2008 23:26:07 +0100
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <47d31245$0$848$415eb37d@crater_reader.dragonflybsd.org>

Sascha Wildner wrote:
Hi all,

this is probably as good a moment as any to come out of the forest with 
this. The patch at

http://leaf.dragonflybsd.org/~swildner/nrelease_gui.diff
Ok, I have committed the stuff as an example.

I'm not sure if my free time permits to work on a full-blown live CD 
with X11 and other good things (I already feel my interest wandering off 
in other directions) so if anyone wants to pick up the ball, go ahead. :)

Sascha

--
http://yoyodyne.ath.cx



From qhwt+dfly at les.ath.cx  Tue Mar 11 22:21:31 2008
From: qhwt+dfly at les.ath.cx (YONETANI Tomokazu)
Date: Tue, 11 Mar 2008 22:21:31 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Misc. ACPI / suspend
In-Reply-To: <47CA073B.6020106@199technologies.org>
Message-ID: <20080312051219.GA56091@les.ath.cx>

On Thu, Mar 06, 2008 at 10:03:21PM -0500, Chris Turner wrote:
> 1) does anyone have ACPI (instead of APM)
>    sleep / suspend / wakeup working on Dfly ?
> 2) If so, what machines are being used ?

Dynabook SS3500 (http://www.tlt.co.jp/pc/catalog/ss/02110735/index_j.htm).
It's old and can get very hot(thus frequently turns on the cooling fan)
even when it's running Windows.  I haven't turned it on for about several
months though.

Cheers.




From c.turner at 199technologies.org  Wed Mar 12 04:37:22 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Wed, 12 Mar 2008 04:37:22 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Misc. ACPI / suspend
In-Reply-To: <47CA073B.6020106@199technologies.org>
Message-ID: <47D7BEE3.6010907@199technologies.org>

YONETANI Tomokazu wrote:
On Thu, Mar 06, 2008 at 10:03:21PM -0500, Chris Turner wrote:
1) does anyone have ACPI (instead of APM)
   sleep / suspend / wakeup working on Dfly ?
Cheers.
ditto..

Suppose this should go to docs@ - in any case..

Thinking about setting up a wiki page on the issue so we
can discuss / track what 'good' hardware / drivers / implementations / 
etc are 'out there' - anyone have any suggestions on where this should
go?

http://wiki.dragonflybsd.org/index.cgi/acpi-overview.html

Remains from the handbook conversion - but I'm hesitant to 'over wikify'
this ..



From c.turner at 199technologies.org  Wed Mar 12 15:36:52 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Wed, 12 Mar 2008 15:36:52 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: devel/cscope
Message-ID: <47D85A08.8040103@199technologies.org>

why oh why did I take so long to try this out !!!

just sharing my eureka moment with the list..

- Chris




From dudu at dudu.ro  Wed Mar 12 15:50:14 2008
From: dudu at dudu.ro (Vlad GALU)
Date: Wed, 12 Mar 2008 15:50:14 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: devel/cscope
In-Reply-To: <47D85A08.8040103@199technologies.org>
Message-ID: <ad79ad6b0803121547r2bf67ffep9e40badaac6490f8@mail.gmail.com>

On 3/13/08, Chris Turner <c.turner at 199technologies.org> wrote:
> why oh why did I take so long to try this out !!!
>
>  just sharing my eureka moment with the list..


    Works nice with vim, too!

>
>
>  - Chris
>


-- 
Mahnahmahnah!




From justin at shiningsilence.com  Sun Mar 16 21:06:13 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Sun, 16 Mar 2008 21:06:13 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: binary packages for 1.12 coming in
Message-ID: <1372.192.168.0.252.1205726088.squirrel@www.shiningsilence.com>

The binary build for 1.12 is taking quite a while.  I've started copying
in newly built packages to
pkgbox.dragonflybsd.org/packages/DragonFly-1.12/i386/ - this should be
getting copied out to mirrors over the next while.

There are currently 1283 packages built, which leaves a whole lot to go;
I'll copy new packages in as they complete.





From hasso at estpak.ee  Wed Mar 19 04:31:08 2008
From: hasso at estpak.ee (Hasso Tepper)
Date: Wed, 19 Mar 2008 04:31:08 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Some questions regarding ACPI
Message-ID: <200803191322.46366.hasso@estpak.ee>

I'm working on bringing in some laptop (and especially thinkpad) specific 
ACPI code from FreeBSD into DragonFly. I never touched ACPI stuff before 
and haven't followed it much either, so I have some questions.

* FreeBSD uses ACPI_SERIAL_* heavily. What's the locking situation in 
  DragonFly and why?

* As far as I can see, PCI integration is commented out in DragonFly. 
  What's the state of it and why?

* platform/pc32/acpica5/acpi_toshiba.c - why is it there? I don't think 
  that this is something pc32 specific in it and it should work in pc64 
  laptops as well. Any objections to move it into 
  dev/acpica5/acpi_toshiba/ ?

What's the current status of ACPI in general? AFAICS our acpica is quite 
old - what needs to be done to bring in newer one?


-- 
Hasso




From qhwt+dfly at les.ath.cx  Wed Mar 19 09:24:50 2008
From: qhwt+dfly at les.ath.cx (YONETANI Tomokazu)
Date: Wed, 19 Mar 2008 09:24:50 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Some questions regarding ACPI
In-Reply-To: <200803191322.46366.hasso@estpak.ee>
Message-ID: <20080319161703.GA51509@les.ath.cx>

On Wed, Mar 19, 2008 at 01:22:46PM +0200, Hasso Tepper wrote:
> I'm working on bringing in some laptop (and especially thinkpad) specific 
> ACPI code from FreeBSD into DragonFly. I never touched ACPI stuff before 
> and haven't followed it much either, so I have some questions.

So you want to port some of ACPI support drivers, or to do a fresh port
of ACPI driver from FreeBSD?

> * FreeBSD uses ACPI_SERIAL_* heavily. What's the locking situation in 
>   DragonFly and why?

The current ACPI driver in DragonFly is based on that of FreeBSD as of
end of June, 2004, plus some fixes brought in later (and ACPICA part
has been updated twice since then).  That was before they introduced
the MPSAFE changes into ACPI code, and we use critical section
(crit_{enter,exit}) in most places (and lockmgr lock in a few place).

> * As far as I can see, PCI integration is commented out in DragonFly. 
>   What's the state of it and why?

When we replaced the implementation taken from FreeBSD 4.x with that
brought from FreeBSD 5.x, which added the PCI part, many people
experienced problems until they turned off ACPI completely, or add "pci"
to "debug.acpi.disabled" loader variable.  AFAIK the PCI part in the ACPI
driver almost hasn't been adjusted to work with our version of PCI code.

> * platform/pc32/acpica5/acpi_toshiba.c - why is it there? I don't think 
>   that this is something pc32 specific in it and it should work in pc64 
>   laptops as well. Any objections to move it into 
>   dev/acpica5/acpi_toshiba/ ?

In FreeBSD it used to be sitting at i386/acpica/acpi_toshiba.c and was
later moved into acpi_support.  That change hasn't hit our tree (in fact,
we have no acpi support drivers other than that).  It seems that FreeBSD
has them in dev/acpi_support now, and we for some reason have that
directory in our CVS repository (but containing no files in it).

> What's the current status of ACPI in general? AFAICS our acpica is quite 
> old - what needs to be done to bring in newer one?

Actually, it's not very important to keep just ACPICA latest, but
if you bring the ACPI driver from FreeBSD you need to bring ACPICA code
that matches their version, and it IS important.  And it generally requires
you much work to just update ACPICA part anyway because of how they
change things on every release.

Cheers.




From hasso at estpak.ee  Wed Mar 19 12:29:52 2008
From: hasso at estpak.ee (Hasso Tepper)
Date: Wed, 19 Mar 2008 12:29:52 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Some questions regarding ACPI
In-Reply-To: <200803191322.46366.hasso@estpak.ee>
Message-ID: <200803192115.35396.hasso@estpak.ee>

YONETANI Tomokazu wrote:
> On Wed, Mar 19, 2008 at 01:22:46PM +0200, Hasso Tepper wrote:
> > I'm working on bringing in some laptop (and especially thinkpad)
> > specific ACPI code from FreeBSD into DragonFly. I never touched ACPI
> > stuff before and haven't followed it much either, so I have some
> > questions.
>
> So you want to port some of ACPI support drivers, or to do a fresh port
> of ACPI driver from FreeBSD?

I'm only interested in support drivers and the reason is pure practical - 
newer thinkpads handle less and less hotkeys etc in hardware and require 
support form OS. acpi_ibm and acpi_video are examples of such modules 
which would help a lot of these newer thinkpad users.

acpi_ibm is almost ready to commit (renamed to acpi_thinkpad though).

> > * FreeBSD uses ACPI_SERIAL_* heavily. What's the locking situation in
> >   DragonFly and why?
>
> The current ACPI driver in DragonFly is based on that of FreeBSD as of
> end of June, 2004, plus some fixes brought in later (and ACPICA part
> has been updated twice since then).  That was before they introduced
> the MPSAFE changes into ACPI code, and we use critical section
> (crit_{enter,exit}) in most places (and lockmgr lock in a few place).

Mkay. Will look at more closely.

> > * As far as I can see, PCI integration is commented out in DragonFly.
> >   What's the state of it and why?
>
> When we replaced the implementation taken from FreeBSD 4.x with that
> brought from FreeBSD 5.x, which added the PCI part, many people
> experienced problems until they turned off ACPI completely, or add
> "pci" to "debug.acpi.disabled" loader variable.  AFAIK the PCI part in
> the ACPI driver almost hasn't been adjusted to work with our version of
> PCI code.

I'm afraid that it's beyond my skills, but while looking at acpi_video I 
discovered that it's hard to handle correctly without PCI support.

> > * platform/pc32/acpica5/acpi_toshiba.c - why is it there? I don't
> > think that this is something pc32 specific in it and it should work
> > in pc64 laptops as well. Any objections to move it into
> >   dev/acpica5/acpi_toshiba/ ?
>
> In FreeBSD it used to be sitting at i386/acpica/acpi_toshiba.c and was
> later moved into acpi_support.  That change hasn't hit our tree (in
> fact, we have no acpi support drivers other than that).  It seems that
> FreeBSD has them in dev/acpi_support now, and we for some reason have
> that directory in our CVS repository (but containing no files in it).

I don't see it ;). Makes sense though. So, any objections if I move 
acpi_toshiba into sys/dev/acpi_support and add new acpi_thinkpad there as 
well? 

> > What's the current status of ACPI in general? AFAICS our acpica is
> > quite old - what needs to be done to bring in newer one?
>
> Actually, it's not very important to keep just ACPICA latest, but
> if you bring the ACPI driver from FreeBSD you need to bring ACPICA code
> that matches their version, and it IS important.  And it generally
> requires you much work to just update ACPICA part anyway because of how
> they change things on every release.

Someone else has to do it :).

Thanks for info.


-- 
Hasso




From dillon at apollo.backplane.com  Wed Mar 19 14:01:13 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Wed, 19 Mar 2008 14:01:13 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: panic: assertion: hammer_btree_cmp(cursor->left_bound,	&cursor->node->ondisk->elms[0].leaf.base) <= 0 in btree_split_leaf
In-Reply-To: <200802232204.m1NM4cxd046264@apollo.backplane.com>
Message-ID: <200803192054.m2JKsjwn045137@apollo.backplane.com>


:Hi.
:While trying to find a procedure to reliably reproduce the panic
:I reported last time, I caught a different panic (uploaded at
: ~y0netan1/crash/9/ on my leaf account).  I wrote the following shell
:script (make sure to edit variables DISKS and MOUNTPT before using this
:script or it may trash your system):
:  #!/bin/sh -ex
:  DISKS="/dev/ad0s1f"
:  MOUNTPT=/mnt/HAMMER
:
:  cd /
:  newfs_hammer -L TEST $DISKS
:  for i in `seq 1 100`; do
:..
:And the panic is triggered by rm command.
:I'll try to see if it's possible to reproduce the last one without
:unmounting then mounting the HAMMER fs.
:
:Cheers.

    I believe I have fixed this panic.  hammer_make_separator() had a bug
    in it.

    There is still an issue with the node ref count on umount.

    Please continue to life-test the code.  The reblocking code
    (hammer reblock /mnt) should work now, as should the pruning code
    (e.g. hammer prune /mnt everything).

    The filesystem full case is still not handled and will cause bad things
    to happen.  The undo code isn't finished yet either but it is getting
    there (it's writing stuff out but not setting the sequence number and
    not trying to recover-on-mount yet).

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From qhwt+dfly at les.ath.cx  Wed Mar 19 19:45:40 2008
From: qhwt+dfly at les.ath.cx (YONETANI Tomokazu)
Date: Wed, 19 Mar 2008 19:45:40 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Some questions regarding ACPI
In-Reply-To: <200803191322.46366.hasso@estpak.ee>
Message-ID: <20080320023828.GA53648@les.ath.cx>

On Wed, Mar 19, 2008 at 09:15:35PM +0200, Hasso Tepper wrote:
> YONETANI Tomokazu wrote:
> > On Wed, Mar 19, 2008 at 01:22:46PM +0200, Hasso Tepper wrote:
> > > I'm working on bringing in some laptop (and especially thinkpad)
> > > specific ACPI code from FreeBSD into DragonFly. I never touched ACPI
> > > stuff before and haven't followed it much either, so I have some
> > > questions.
> >
> > So you want to port some of ACPI support drivers, or to do a fresh port
> > of ACPI driver from FreeBSD?
> 
> I'm only interested in support drivers and the reason is pure practical - 
> newer thinkpads handle less and less hotkeys etc in hardware and require 
> support form OS. acpi_ibm and acpi_video are examples of such modules 
> which would help a lot of these newer thinkpad users.
> 
> acpi_ibm is almost ready to commit (renamed to acpi_thinkpad though).

Ah, that's a good news!  My only concern is that ISTR someone mentioned
me that his colleague was thinking about porting ACPI driver itself,
so if you're not the person you may want to collaborate with him/her
so as not to waste the effort or time...

			:

> > In FreeBSD it used to be sitting at i386/acpica/acpi_toshiba.c and was
> > later moved into acpi_support.  That change hasn't hit our tree (in
> > fact, we have no acpi support drivers other than that).  It seems that
> > FreeBSD has them in dev/acpi_support now, and we for some reason have
> > that directory in our CVS repository (but containing no files in it).
> 
> I don't see it ;). Makes sense though. So, any objections if I move 
> acpi_toshiba into sys/dev/acpi_support and add new acpi_thinkpad there as 
> well? 

Sorry, I checked the CVS repository and it doesn't exist actually :)
I don't have any objection to moving it there.

Cheers.




From hasso at estpak.ee  Thu Mar 20 00:14:05 2008
From: hasso at estpak.ee (Hasso Tepper)
Date: Thu, 20 Mar 2008 00:14:05 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Some questions regarding ACPI
In-Reply-To: <200803191322.46366.hasso@estpak.ee>
Message-ID: <200803200904.50875.hasso@estpak.ee>

YONETANI Tomokazu wrote:
> On Wed, Mar 19, 2008 at 09:15:35PM +0200, Hasso Tepper wrote:
> > acpi_ibm is almost ready to commit (renamed to acpi_thinkpad though).
>
> Ah, that's a good news!  My only concern is that ISTR someone mentioned
> me that his colleague was thinking about porting ACPI driver itself,
> so if you're not the person you may want to collaborate with him/her
> so as not to waste the effort or time...

Current state in my repo is attached. It should work on 1.12 as well as it 
doesn't depend yet on moving stuff around.

add-acpi-if-m.patch adds some new stuff to the ACPI code to access 
embedded controllers and match ACPI devices by ID. Not sure how, where 
and whether at all these should be documented.

add-acpi-thinkpad.patch is the driver itself. Note that some stuff doesn't 
work yet on newer thinkpads, I plan to work on it later.

There is still some things to do though. I have to decide what to do with 
led(4) part and with locking. There is also one fatal issue - laptop 
locks up hardly (no panic) while unloading module. Any idea regarding 
this is welcome. And of course test results :).


-- 
Hasso
# HG changeset patch
# User Hasso Tepper <hasso at estpak.ee>
# Date 1205919290 -7200
# Branch HEAD
# Node ID 5a6e2705cc95a340abf973ae5df73ef34e070b79
# Parent  cd529e2e7f849034d5d5a0973cb98af50db0e797
imported patch adding-acpi-if-m.patch

diff --git a/sys/conf/files b/sys/conf/files
--- a/sys/conf/files
+++ b/sys/conf/files
@@ -1387,6 +1387,7 @@ emulation/dragonfly12/dfbsd12_stat.c	non
 ${OSACPI_MI_DIR}/acpi_cmbat.c		optional acpi
 ${OSACPI_MI_DIR}/acpi_cpu.c		optional acpi
 ${OSACPI_MI_DIR}/acpi_ec.c		optional acpi
+${OSACPI_MI_DIR}/acpi_if.m		optional acpi
 ${OSACPI_MI_DIR}/acpi_isab.c		optional acpi isa
 ${OSACPI_MI_DIR}/acpi_lid.c		optional acpi
 ${OSACPI_MI_DIR}/acpi_package.c		optional acpi
diff --git a/sys/conf/kmod.mk b/sys/conf/kmod.mk
--- a/sys/conf/kmod.mk
+++ b/sys/conf/kmod.mk
@@ -275,7 +275,7 @@ MFILES?= kern/bus_if.m kern/device_if.m 
     bus/pccard/card_if.m bus/pccard/power_if.m bus/pci/pci_if.m \
     bus/pci/pcib_if.m \
     bus/ppbus/ppbus_if.m bus/smbus/smbus_if.m bus/usb/usb_if.m \
-    dev/disk/nata/ata_if.m \
+    dev/acpica5/acpi_if.m dev/disk/nata/ata_if.m \
     dev/sound/pcm/ac97_if.m dev/sound/pcm/channel_if.m \
     dev/sound/pcm/feeder_if.m dev/sound/pcm/mixer_if.m \
     libiconv/iconv_converter_if.m dev/agp/agp_if.m opencrypto/crypto_if.m
diff --git a/sys/dev/acpica5/Makefile b/sys/dev/acpica5/Makefile
--- a/sys/dev/acpica5/Makefile
+++ b/sys/dev/acpica5/Makefile
@@ -69,12 +69,14 @@ SRCS+=  acpi_package.c
 # SRCS+=	acpi_pci.c acpi_pcib.c acpi_pcib_acpi.c acpi_pcib_pci.c
 # SRCS+=	acpi_pci_link.c
 SRCS+=  acpi_powerres.c acpi_resource.c acpi_thermal.c
-SRCS+=  acpi_timer.c
+SRCS+=  acpi_timer.c acpi_if.c
 SRCS+=  OsdDebug.c
 SRCS+=  OsdHardware.c OsdInterface.c OsdInterrupt.c OsdMemory.c OsdSchedule.c
 SRCS+=  OsdStream.c OsdSynch.c OsdTable.c OsdEnvironment.c
 SRCS+=  opt_acpi.h opt_bus.h opt_ddb.h
-SRCS+=  device_if.h bus_if.h pci_if.h pcib_if.h isa_if.h
+SRCS+=  device_if.h bus_if.h pci_if.h pcib_if.h isa_if.h acpi_if.h
+MFILES = kern/device_if.m kern/bus_if.m bus/pci/pci_if.m bus/pci/pcib_if.m
+MFILES+= bus/isa/isa_if.m dev/acpica5/acpi_if.m
 
 # Debugging support
 DBSRC=	dbcmds.c dbdisply.c dbexec.c dbfileio.c dbhistry.c
diff --git a/sys/dev/acpica5/acpi.c b/sys/dev/acpica5/acpi.c
--- a/sys/dev/acpica5/acpi.c
+++ b/sys/dev/acpica5/acpi.c
@@ -135,6 +135,7 @@ static int	acpi_release_resource(device_
 			int rid, struct resource *r);
 static uint32_t	acpi_isa_get_logicalid(device_t dev);
 static int	acpi_isa_get_compatid(device_t dev, uint32_t *cids, int count);
+static char	*acpi_device_id_probe(device_t bus, device_t dev, char **ids);
 static int	acpi_isa_pnp_probe(device_t bus, device_t child,
 			struct isa_pnp_id *ids);
 static void	acpi_probe_children(device_t bus);
@@ -189,6 +190,9 @@ static device_method_t acpi_methods[] = 
     DEVMETHOD(bus_deactivate_resource,	bus_generic_deactivate_resource),
     DEVMETHOD(bus_setup_intr,		bus_generic_setup_intr),
     DEVMETHOD(bus_teardown_intr,	bus_generic_teardown_intr),
+
+    /* ACPI bus */
+    DEVMETHOD(acpi_id_probe,		acpi_device_id_probe),
 
     /* ISA emulation */
     DEVMETHOD(isa_pnp_probe,		acpi_isa_pnp_probe),
@@ -1121,6 +1125,24 @@ out:
 	AcpiOsFree(buf.Pointer);
     ACPI_UNLOCK;
     return_VALUE (valid);
+}
+
+static char *
+acpi_device_id_probe(device_t bus, device_t dev, char **ids) 
+{
+    ACPI_HANDLE h;
+    int i;
+
+    h = acpi_get_handle(dev);
+    if (ids == NULL || h == NULL || acpi_get_type(dev) != ACPI_TYPE_DEVICE)
+	return (NULL);
+
+    /* Try to match one of the array of IDs with a HID or CID. */
+    for (i = 0; ids[i] != NULL; i++) {
+	if (acpi_MatchHid(h, ids[i]))
+	    return (ids[i]);
+    }
+    return (NULL);
 }
 
 static int
diff --git a/sys/dev/acpica5/acpi_ec.c b/sys/dev/acpica5/acpi_ec.c
--- a/sys/dev/acpica5/acpi_ec.c
+++ b/sys/dev/acpica5/acpi_ec.c
@@ -327,11 +327,19 @@ static ACPI_STATUS	EcWrite(struct acpi_e
 				UINT8 *Data);
 static int		acpi_ec_probe(device_t dev);
 static int		acpi_ec_attach(device_t dev);
+static int		acpi_ec_read_method(device_t dev, u_int addr,
+				ACPI_INTEGER *val, int width);
+static int		acpi_ec_write_method(device_t dev, u_int addr,
+				ACPI_INTEGER val, int width);
 
 static device_method_t acpi_ec_methods[] = {
     /* Device interface */
     DEVMETHOD(device_probe,	acpi_ec_probe),
     DEVMETHOD(device_attach,	acpi_ec_attach),
+
+    /* Embedded controller interface */
+    DEVMETHOD(acpi_ec_read,     acpi_ec_read_method),
+    DEVMETHOD(acpi_ec_write,    acpi_ec_write_method),
 
     {0, 0}
 };
@@ -620,6 +628,33 @@ error:
 			     sc->ec_data_res);
     /* mtx_destroy(&sc->ec_mtx); */
     return (ENXIO);
+}
+
+/* Methods to allow other devices (e.g., smbat) to read/write EC space. */
+static int
+acpi_ec_read_method(device_t dev, u_int addr, ACPI_INTEGER *val, int width)
+{
+    struct acpi_ec_softc *sc;
+    ACPI_STATUS status;
+
+    sc = device_get_softc(dev);
+    status = EcSpaceHandler(ACPI_READ, addr, width * 8, val, sc, NULL);
+    if (ACPI_FAILURE(status))
+        return (ENXIO);
+    return (0);
+}
+
+static int
+acpi_ec_write_method(device_t dev, u_int addr, ACPI_INTEGER val, int width)
+{
+    struct acpi_ec_softc *sc;
+    ACPI_STATUS status;
+
+    sc = device_get_softc(dev);
+    status = EcSpaceHandler(ACPI_WRITE, addr, width * 8, &val, sc, NULL);
+    if (ACPI_FAILURE(status))
+        return (ENXIO);
+    return (0);
 }
 
 static void
diff --git a/sys/dev/acpica5/acpi_if.m b/sys/dev/acpica5/acpi_if.m
new file mode 100644
--- /dev/null
+++ b/sys/dev/acpica5/acpi_if.m
@@ -0,0 +1,92 @@
+#-
+# Copyright (c) 2004 Nate Lawson
+# All rights reserved.
+#
+# Redistribution and use in source and binary forms, with or without
+# modification, are permitted provided that the following conditions
+# are met:
+# 1. Redistributions of source code must retain the above copyright
+#    notice, this list of conditions and the following disclaimer.
+# 2. Redistributions in binary form must reproduce the above copyright
+#    notice, this list of conditions and the following disclaimer in the
+#    documentation and/or other materials provided with the distribution.
+#
+# THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
+# ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+# ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
+# FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+# DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+# OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+# HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+# LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+# OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+# SUCH DAMAGE.
+#
+# $DragonFly$
+#
+
+#include <sys/bus.h>
+#include <sys/types.h>
+#include "acpi.h"
+
+INTERFACE acpi;
+
+#
+# Default implementation for acpi_id_probe().
+#
+CODE {
+	static char *
+	acpi_generic_id_probe(device_t bus, device_t dev, char **ids)
+	{
+		return (NULL);
+	}
+};
+
+#
+# Check a device for a match in a list of ID strings.  The strings can be
+# EISA PNP IDs or ACPI _HID/_CID values.
+#
+# device_t bus:  parent bus for the device
+#
+# device_t dev:  device being considered
+#
+# char **ids:  array of ID strings to consider
+#
+# Returns:  ID string matched or NULL if no match
+#
+METHOD char * id_probe {
+	device_t	bus;
+	device_t	dev;
+	char		**ids;
+} DEFAULT acpi_generic_id_probe;
+
+#
+# Read embedded controller (EC) address space
+#
+# device_t dev:  EC device
+# u_int addr:  Address to read from in EC space
+# ACPI_INTEGER *val:  Location to store read value
+# int width:  Size of area to read in bytes
+#
+METHOD int ec_read {
+	device_t	dev;
+	u_int		addr;
+	ACPI_INTEGER	*val;
+	int		width;
+};
+
+#
+# Write embedded controller (EC) address space
+#
+# device_t dev:  EC device
+# u_int addr:  Address to write to in EC space
+# ACPI_INTEGER val:  Value to write
+# int width:  Size of value to write in bytes
+#
+METHOD int ec_write {
+	device_t	dev;
+	u_int		addr;
+	ACPI_INTEGER	val;
+	int		width;
+};
diff --git a/sys/dev/acpica5/acpivar.h b/sys/dev/acpica5/acpivar.h
--- a/sys/dev/acpica5/acpivar.h
+++ b/sys/dev/acpica5/acpivar.h
@@ -29,6 +29,7 @@
  * $DragonFly: src/sys/dev/acpica5/acpivar.h,v 1.12 2007/10/23 03:04:48 y0netan1 Exp $
  */
 
+#include "acpi_if.h"
 #include "bus_if.h"
 #include <sys/eventhandler.h>
 #include <sys/sysctl.h>
# HG changeset patch
# User Hasso Tepper <hasso at estpak.ee>
# Date 1205995474 -7200
# Branch HEAD
# Node ID c5db8d4a7c6b25a8576a8d42c5029aaf0e23bfb6
# Parent  5a6e2705cc95a340abf973ae5df73ef34e070b79
[mq]: adding-acpi-thinkpad.patch

diff --git a/sys/dev/acpica5/Makefile b/sys/dev/acpica5/Makefile
--- a/sys/dev/acpica5/Makefile
+++ b/sys/dev/acpica5/Makefile
@@ -117,7 +117,7 @@ acpi_wakecode.h: acpi_wakecode.S
 	${MAKE} -f ${SYSDIR}/${OSACPI_MD_DIR}/Makefile \
 		MAKESRCPATH=${SYSDIR}/${OSACPI_MD_DIR}
 
-SUBDIR=	acpi_toshiba
+SUBDIR=	acpi_toshiba acpi_thinkpad
 all: ${PROG} ${SUBDIR}
 
 # *.o file for each patched *.c file is created under the same directory,
diff --git a/sys/dev/acpica5/acpi_thinkpad/Makefile b/sys/dev/acpica5/acpi_thinkpad/Makefile
new file mode 100644
--- /dev/null
+++ b/sys/dev/acpica5/acpi_thinkpad/Makefile
@@ -0,0 +1,9 @@
+# $DragonFly$
+
+SYSDIR?=${.CURDIR}/../../..
+
+KMOD=		acpi_thinkpad
+CFLAGS+=	-I${.OBJDIR}/.. -I${.CURDIR}/..
+SRCS=		acpi_thinkpad.c opt_acpi.h device_if.h bus_if.h
+
+.include <bsd.kmod.mk>
diff --git a/sys/dev/acpica5/acpi_thinkpad/acpi_thinkpad.c b/sys/dev/acpica5/acpi_thinkpad/acpi_thinkpad.c
new file mode 100644
--- /dev/null
+++ b/sys/dev/acpica5/acpi_thinkpad/acpi_thinkpad.c
@@ -0,0 +1,1046 @@
+/*
+ * Copyright (c) 2004 Takanori Watanabe
+ * Copyright (c) 2005 Markus Brueffer <markus at FreeBSD.org>
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *    notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *    notice, this list of conditions and the following disclaimer in the
+ *    documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+ */
+
+/*
+ * Driver for extra ACPI-controlled gadgets found on IBM and Lenovo ThinkPad
+ * laptops. Inspired by the ibm-acpi and tpb projects which implement these
+ * features on Linux.
+ *
+ *   acpi-ibm: <http://ibm-acpi.sourceforge.net/>
+ *        tpb: <http://www.nongnu.org/tpb/>
+ */
+
+#include "opt_acpi.h"
+#include <sys/param.h>
+#include <sys/kernel.h>
+#include <sys/bus.h>
+#include <machine/cpufunc.h>
+#include <sys/module.h>
+/* #include <dev/led/led.h> */
+#include <sys/sensors.h>
+#include <sys/sysctl.h>
+#include <machine/clock.h>
+
+#include "acpi.h"
+#include "acpivar.h"
+#include "acpi_if.h"
+
+#define _COMPONENT	ACPI_OEM
+ACPI_MODULE_NAME("THINKPAD")
+
+/* Internal methods */
+#define ACPI_THINKPAD_METHOD_EVENTS		1
+#define ACPI_THINKPAD_METHOD_EVENTMASK		2
+#define ACPI_THINKPAD_METHOD_HOTKEY		3
+#define ACPI_THINKPAD_METHOD_BRIGHTNESS		4
+#define ACPI_THINKPAD_METHOD_VOLUME		5
+#define ACPI_THINKPAD_METHOD_MUTE		6
+#define ACPI_THINKPAD_METHOD_THINKLIGHT		7
+#define ACPI_THINKPAD_METHOD_BLUETOOTH		8
+#define ACPI_THINKPAD_METHOD_WLAN		9
+#define ACPI_THINKPAD_METHOD_FANSPEED		10
+#define ACPI_THINKPAD_METHOD_FANLEVEL		11
+#define ACPI_THINKPAD_METHOD_FANSTATUS		12
+#define ACPI_THINKPAD_METHOD_THERMAL		13
+
+/* Hotkeys/Buttons */
+#define THINKPAD_RTC_HOTKEY1			0x64
+#define   THINKPAD_RTC_MASK_HOME		(1 << 0)
+#define   THINKPAD_RTC_MASK_SEARCH		(1 << 1)
+#define   THINKPAD_RTC_MASK_MAIL		(1 << 2)
+#define   THINKPAD_RTC_MASK_WLAN		(1 << 5)
+#define THINKPAD_RTC_HOTKEY2			0x65
+#define   THINKPAD_RTC_MASK_THINKPAD		(1 << 3)
+#define   THINKPAD_RTC_MASK_ZOOM		(1 << 5)
+#define   THINKPAD_RTC_MASK_VIDEO		(1 << 6)
+#define   THINKPAD_RTC_MASK_HIBERNATE		(1 << 7)
+#define THINKPAD_RTC_THINKLIGHT			0x66
+#define   THINKPAD_RTC_MASK_THINKLIGHT		(1 << 4)
+#define THINKPAD_RTC_SCREENEXPAND		0x67
+#define   THINKPAD_RTC_MASK_SCREENEXPAND	(1 << 5)
+#define THINKPAD_RTC_BRIGHTNESS			0x6c
+#define   THINKPAD_RTC_MASK_BRIGHTNESS		(1 << 5)
+#define THINKPAD_RTC_VOLUME			0x6e
+#define   THINKPAD_RTC_MASK_VOLUME		(1 << 7)
+
+/* Embedded Controller registers */
+#define THINKPAD_EC_BRIGHTNESS			0x31
+#define   THINKPAD_EC_MASK_BRI			0x7
+#define THINKPAD_EC_VOLUME			0x30
+#define   THINKPAD_EC_MASK_VOL			0xf
+#define   THINKPAD_EC_MASK_MUTE			(1 << 6)
+#define THINKPAD_EC_FANSTATUS			0x2F
+#define   THINKPAD_EC_MASK_FANLEVEL		0x3f
+#define   THINKPAD_EC_MASK_FANDISENGAGED	(1 << 6)
+#define   THINKPAD_EC_MASK_FANSTATUS		(1 << 7)
+#define THINKPAD_EC_FANSPEED			0x84
+
+/* CMOS Commands */
+#define THINKPAD_CMOS_VOLUME_DOWN		0
+#define THINKPAD_CMOS_VOLUME_UP			1
+#define THINKPAD_CMOS_VOLUME_MUTE		2
+#define THINKPAD_CMOS_BRIGHTNESS_UP		4
+#define THINKPAD_CMOS_BRIGHTNESS_DOWN		5
+
+/* ACPI methods */
+#define THINKPAD_NAME_KEYLIGHT			"KBLT"
+#define THINKPAD_NAME_WLAN_BT_GET		"GBDC"
+#define THINKPAD_NAME_WLAN_BT_SET		"SBDC"
+#define   THINKPAD_NAME_MASK_BT			(1 << 1)
+#define   THINKPAD_NAME_MASK_WLAN		(1 << 2)
+#define THINKPAD_NAME_THERMAL_GET		"TMP7"
+#define THINKPAD_NAME_THERMAL_UPDT		"UPDT"
+
+#define THINKPAD_NAME_EVENTS_STATUS_GET		"DHKC"
+#define THINKPAD_NAME_EVENTS_MASK_GET		"DHKN"
+#define THINKPAD_NAME_EVENTS_STATUS_SET		"MHKC"
+#define THINKPAD_NAME_EVENTS_MASK_SET		"MHKM"
+#define THINKPAD_NAME_EVENTS_GET		"MHKP"
+#define THINKPAD_NAME_EVENTS_AVAILMASK		"MHKA"
+
+#define ABS(x) (((x) < 0)? -(x) : (x))
+
+struct acpi_thinkpad_softc {
+	device_t	dev;
+	ACPI_HANDLE	handle;
+
+	/* Embedded controller */
+	device_t	ec_dev;
+	ACPI_HANDLE	ec_handle;
+
+	/* CMOS */
+	ACPI_HANDLE	cmos_handle;
+
+	/* Fan status */
+	ACPI_HANDLE	fan_handle;
+	int		fan_levels;
+
+	/* Keylight commands and states */
+	ACPI_HANDLE	light_handle;
+	int		light_cmd_on;
+	int		light_cmd_off;
+	int		light_val;
+	int		light_get_supported;
+	int		light_set_supported;
+
+	/* led(4) interface */
+	struct cdev	*led_dev;
+	int		led_busy;
+	int		led_state;
+
+	int		wlan_bt_flags;
+	int		thermal_updt_supported;
+
+	unsigned int	events_availmask;
+	unsigned int	events_initialmask;
+	int		events_mask_supported;
+	int		events_enable;
+
+	/* sensors(9) related */
+	struct ksensordev sensordev;
+	struct ksensor sensors[9];	/* XXX: 8 thermal + fan */
+
+	struct sysctl_ctx_list	*sysctl_ctx;
+	struct sysctl_oid	*sysctl_tree;
+};
+
+static struct {
+	char	*name;
+	int	method;
+	char	*description;
+	int	access;
+} acpi_thinkpad_sysctls[] = {
+	{
+		.name		= "events",
+		.method		= ACPI_THINKPAD_METHOD_EVENTS,
+		.description	= "ACPI events enable",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "eventmask",
+		.method		= ACPI_THINKPAD_METHOD_EVENTMASK,
+		.description	= "ACPI eventmask",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "hotkey",
+		.method		= ACPI_THINKPAD_METHOD_HOTKEY,
+		.description	= "Key Status",
+		.access		= CTLTYPE_INT | CTLFLAG_RD
+	},
+	{
+		.name		= "lcd_brightness",
+		.method		= ACPI_THINKPAD_METHOD_BRIGHTNESS,
+		.description	= "LCD Brightness",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "volume",
+		.method		= ACPI_THINKPAD_METHOD_VOLUME,
+		.description	= "Volume",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "mute",
+		.method		= ACPI_THINKPAD_METHOD_MUTE,
+		.description	= "Mute",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "thinklight",
+		.method		= ACPI_THINKPAD_METHOD_THINKLIGHT,
+		.description	= "Thinklight enable",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "bluetooth",
+		.method		= ACPI_THINKPAD_METHOD_BLUETOOTH,
+		.description	= "Bluetooth enable",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "wlan",
+		.method		= ACPI_THINKPAD_METHOD_WLAN,
+		.description	= "WLAN enable",
+		.access		= CTLTYPE_INT | CTLFLAG_RD
+	},
+	{
+		.name		= "fan_level",
+		.method		= ACPI_THINKPAD_METHOD_FANLEVEL,
+		.description	= "Fan level",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "fan",
+		.method		= ACPI_THINKPAD_METHOD_FANSTATUS,
+		.description	= "Fan enable",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+
+	{ NULL, 0, NULL, 0 }
+};
+
+/* ACPI_SERIAL_DECL(thinkpad, "ACPI THINKPAD extras"); */
+static int	acpi_thinkpad_probe(device_t dev);
+static int	acpi_thinkpad_attach(device_t dev);
+static int	acpi_thinkpad_detach(device_t dev);
+
+#if 0 /* not yet */
+static void	thinkpad_led(void *softc, int onoff);
+static void	thinkpad_led_task(struct acpi_thinkpad_softc *sc,
+		int pending __unused);
+#endif
+
+static int	acpi_thinkpad_sysctl(SYSCTL_HANDLER_ARGS);
+static int	acpi_thinkpad_sysctl_init(struct acpi_thinkpad_softc *sc,
+		int method);
+static int	acpi_thinkpad_sysctl_get(struct acpi_thinkpad_softc *sc,
+		int method);
+static int	acpi_thinkpad_sysctl_set(struct acpi_thinkpad_softc *sc,
+		int method, int val);
+
+static int	acpi_thinkpad_eventmask_set(struct acpi_thinkpad_softc *sc,
+		int val);
+static void	acpi_thinkpad_notify(ACPI_HANDLE h, UINT32 notify,
+		void *context);
+static void	acpi_thinkpad_refresh(void *);
+
+static device_method_t acpi_thinkpad_methods[] = {
+	/* Device interface */
+	DEVMETHOD(device_probe, acpi_thinkpad_probe),
+	DEVMETHOD(device_attach, acpi_thinkpad_attach),
+	DEVMETHOD(device_detach, acpi_thinkpad_detach),
+	{0, 0}
+};
+
+static driver_t	acpi_thinkpad_driver = {
+	"acpi_thinkpad",
+	acpi_thinkpad_methods,
+	sizeof(struct acpi_thinkpad_softc),
+};
+
+static devclass_t acpi_thinkpad_devclass;
+
+DRIVER_MODULE(acpi_thinkpad, acpi, acpi_thinkpad_driver,
+    acpi_thinkpad_devclass, 0, 0);
+MODULE_DEPEND(acpi_thinkpad, acpi, 1, 1, 1);
+static char    *thinkpad_ids[] = {"IBM0068", NULL};
+
+#if 0 /* not yet */
+static void
+thinkpad_led(void *softc, int onoff)
+{
+	struct acpi_thinkpad_softc* sc = (struct acpi_thinkpad_softc*) softc;
+
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+
+	if (sc->led_busy)
+		return;
+
+	sc->led_busy = 1;
+	sc->led_state = onoff;
+
+	AcpiOsExecute(OSL_NOTIFY_HANDLER, (void *)thinkpad_led_task, sc);
+}
+
+static void
+thinkpad_led_task(struct acpi_thinkpad_softc *sc, int pending __unused)
+{
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+
+	/* ACPI_SERIAL_BEGIN(thinkpad); */
+	acpi_thinkpad_sysctl_set(sc, ACPI_THINKPAD_METHOD_THINKLIGHT, sc->led_state);
+	/* ACPI_SERIAL_END(thinkpad); */
+
+	sc->led_busy = 0;
+}
+#endif
+
+static int
+acpi_thinkpad_probe(device_t dev)
+{
+	if (acpi_disabled("thinkpad") ||
+	    ACPI_ID_PROBE(device_get_parent(dev), dev, thinkpad_ids) == NULL ||
+	    device_get_unit(dev) != 0) 
+		return (ENXIO);
+
+	device_set_desc(dev, "IBM/Lenovo ThinkPad ACPI Extras");
+	return (0);
+}
+
+static int
+acpi_thinkpad_attach(device_t dev)
+{
+	struct acpi_thinkpad_softc	*sc;
+	struct acpi_softc	*acpi_sc;
+	devclass_t		ec_devclass;
+	int			i;
+
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t) __func__);
+
+	sc = device_get_softc(dev);
+	sc->dev = dev;
+	sc->handle = acpi_get_handle(dev);
+
+	acpi_sc = acpi_device_get_parent_softc(dev);
+
+	/* Look for the first embedded controller */
+        if (!(ec_devclass = devclass_find ("acpi_ec"))) {
+		if (bootverbose)
+			device_printf(dev, "Couldn't find acpi_ec devclass\n");
+		return (EINVAL);
+	}
+        if (!(sc->ec_dev = devclass_get_device(ec_devclass, 0))) {
+		if (bootverbose)
+			device_printf(dev, "Couldn't find acpi_ec device\n");
+		return (EINVAL);
+	}
+	sc->ec_handle = acpi_get_handle(sc->ec_dev);
+
+	/* ACPI_SERIAL_BEGIN(thinkpad); */
+
+#if 0
+	/* Get the sysctl tree */
+	sc->sysctl_ctx = device_get_sysctl_ctx(dev);
+	sc->sysctl_tree = device_get_sysctl_tree(dev);
+#endif
+	sysctl_ctx_init(sc->sysctl_ctx);
+	sc->sysctl_tree = SYSCTL_ADD_NODE(sc->sysctl_ctx,
+	    SYSCTL_CHILDREN(acpi_sc->acpi_sysctl_tree), OID_AUTO,
+	    "thinkpad", CTLFLAG_RD, 0, "");
+
+	/* Look for event mask and hook up the nodes */
+	sc->events_mask_supported = ACPI_SUCCESS(acpi_GetInteger(sc->handle,
+	    THINKPAD_NAME_EVENTS_MASK_GET, &sc->events_initialmask));
+
+	if (sc->events_mask_supported) {
+		SYSCTL_ADD_INT(sc->sysctl_ctx,
+		    SYSCTL_CHILDREN(sc->sysctl_tree), OID_AUTO,
+		    "initialmask", CTLFLAG_RD,
+		    &sc->events_initialmask, 0, "Initial eventmask");
+
+		/* The availmask is the bitmask of supported events */
+		if (ACPI_FAILURE(acpi_GetInteger(sc->handle,
+		    THINKPAD_NAME_EVENTS_AVAILMASK, &sc->events_availmask)))
+			sc->events_availmask = 0xffffffff;
+
+		SYSCTL_ADD_INT(sc->sysctl_ctx,
+		    SYSCTL_CHILDREN(sc->sysctl_tree), OID_AUTO,
+		    "availmask", CTLFLAG_RD,
+		    &sc->events_availmask, 0, "Mask of supported events");
+	}
+
+	/* Hook up proc nodes */
+	for (i = 0; acpi_thinkpad_sysctls[i].name != NULL; i++) {
+		if (!acpi_thinkpad_sysctl_init(sc,
+		    acpi_thinkpad_sysctls[i].method))
+			continue;
+
+		SYSCTL_ADD_PROC(sc->sysctl_ctx,
+		    SYSCTL_CHILDREN(sc->sysctl_tree), OID_AUTO,
+		    acpi_thinkpad_sysctls[i].name,
+		    acpi_thinkpad_sysctls[i].access,
+		    sc, i, acpi_thinkpad_sysctl, "I",
+		    acpi_thinkpad_sysctls[i].description);
+	}
+
+	/* ACPI_SERIAL_END(thinkpad); */
+
+	/* Handle notifies */
+	AcpiInstallNotifyHandler(sc->handle, ACPI_DEVICE_NOTIFY,
+	    acpi_thinkpad_notify, dev);
+
+#if 0
+	/* Hook up light to led(4) */
+	if (sc->light_set_supported)
+		sc->led_dev = led_create_state(thinkpad_led, sc, "thinklight",
+		    sc->light_val);
+#endif
+	/* Attach sensors(9). */
+	if (sensor_task_register(sc, acpi_thinkpad_refresh, 5)) {
+		device_printf(sc->dev, "unable to register update task\n");
+		return 1;
+	}
+
+	strlcpy(sc->sensordev.xname, device_get_nameunit(sc->dev),
+	    sizeof(sc->sensordev.xname));
+
+	/* XXX: Temp sensors */
+	for (i = 0; i < 8; ++i) {
+		sc->sensors[i].type = SENSOR_TEMP;
+		sensor_attach(&sc->sensordev, &sc->sensors[i]);
+	}
+	
+	/* Fan RPM sensor */
+	sc->sensors[8].type = SENSOR_FANRPM;
+	sensor_attach(&sc->sensordev, &sc->sensors[8]);
+
+	sensordev_install(&sc->sensordev);
+
+	return (0);
+}
+
+static int
+acpi_thinkpad_detach(device_t dev)
+{
+	int i;
+
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t) __func__);
+
+	struct acpi_thinkpad_softc *sc = device_get_softc(dev);
+
+	/* Disable events and restore eventmask */
+	/* ACPI_SERIAL_BEGIN(thinkpad); */
+	acpi_thinkpad_sysctl_set(sc, ACPI_THINKPAD_METHOD_EVENTS, 0);
+	acpi_thinkpad_sysctl_set(sc, ACPI_THINKPAD_METHOD_EVENTMASK,
+	    sc->events_initialmask);
+	/* ACPI_SERIAL_END(thinkpad); */
+
+	AcpiRemoveNotifyHandler(sc->handle, ACPI_DEVICE_NOTIFY,
+	    acpi_thinkpad_notify);
+
+	sysctl_ctx_free(sc->sysctl_ctx);
+
+#if 0
+	if (sc->led_dev != NULL)
+		led_destroy(sc->led_dev);
+#endif
+	sensordev_deinstall(&sc->sensordev);
+	for (i = 0; i < 9; i++)
+		sensor_detach(&sc->sensordev, &sc->sensors[i]);
+	sensor_task_unregister(sc);
+
+	return (0);
+}
+
+static int
+acpi_thinkpad_eventmask_set(struct acpi_thinkpad_softc *sc, int val)
+{
+	int i;
+	ACPI_OBJECT		arg[2];
+	ACPI_OBJECT_LIST	args;
+	ACPI_STATUS		status;
+
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+	/* ACPI_SERIAL_ASSERT(thinkpad); */
+
+	args.Count = 2;
+	args.Pointer = arg;
+	arg[0].Type = ACPI_TYPE_INTEGER;
+	arg[1].Type = ACPI_TYPE_INTEGER;
+
+	for (i = 0; i < 32; ++i) {
+		arg[0].Integer.Value = i+1;
+		arg[1].Integer.Value = (((1 << i) & val) != 0);
+		status = AcpiEvaluateObject(sc->handle,
+		    THINKPAD_NAME_EVENTS_MASK_SET, &args, NULL);
+
+		if (ACPI_FAILURE(status))
+			return (status);
+	}
+
+	return (0);
+}
+
+static int
+acpi_thinkpad_sysctl(SYSCTL_HANDLER_ARGS)
+{
+	struct acpi_thinkpad_softc	*sc;
+	int			arg;
+	int			error = 0;
+	int			function;
+	int			method;
+	
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+
+	sc = (struct acpi_thinkpad_softc *)oidp->oid_arg1;
+	function = oidp->oid_arg2;
+	method = acpi_thinkpad_sysctls[function].method;
+
+	/* ACPI_SERIAL_BEGIN(thinkpad); */
+	arg = acpi_thinkpad_sysctl_get(sc, method);
+	error = sysctl_handle_int(oidp, &arg, 0, req);
+
+	/* Sanity check */
+	if (error != 0 || req->newptr == NULL)
+		goto out;
+
+	/* Update */
+	error = acpi_thinkpad_sysctl_set(sc, method, arg);
+
+out:
+	/* ACPI_SERIAL_END(thinkpad); */
+	return (error);
+}
+
+static int
+acpi_thinkpad_sysctl_get(struct acpi_thinkpad_softc *sc, int method)
+{
+	ACPI_INTEGER	val_ec;
+	int 		val = 0, key;
+
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+	/* ACPI_SERIAL_ASSERT(thinkpad); */
+
+	switch (method) {
+	case ACPI_THINKPAD_METHOD_EVENTS:
+		acpi_GetInteger(sc->handle, THINKPAD_NAME_EVENTS_STATUS_GET,
+		    &val);
+		break;
+
+	case ACPI_THINKPAD_METHOD_EVENTMASK:
+		if (sc->events_mask_supported)
+			acpi_GetInteger(sc->handle,
+			    THINKPAD_NAME_EVENTS_MASK_GET, &val);
+		break;
+
+	case ACPI_THINKPAD_METHOD_HOTKEY:
+		/*
+		 * Construct the hotkey as a bitmask as illustrated below.
+		 * Note that whenever a key was pressed, the respecting bit
+		 * toggles and nothing else changes.
+		 * +--+--+-+-+-+-+-+-+-+-+-+-+
+		 * |11|10|9|8|7|6|5|4|3|2|1|0|
+		 * +--+--+-+-+-+-+-+-+-+-+-+-+
+		 *   |  | | | | | | | | | | |
+		 *   |  | | | | | | | | | | +- Home Button
+		 *   |  | | | | | | | | | +--- Search Button
+		 *   |  | | | | | | | | +----- Mail Button
+		 *   |  | | | | | | | +------- Thinkpad Button
+		 *   |  | | | | | | +--------- Zoom (Fn + Space)
+		 *   |  | | | | | +----------- WLAN Button
+		 *   |  | | | | +------------- Video Button
+		 *   |  | | | +--------------- Hibernate Button
+		 *   |  | | +----------------- Thinklight Button
+		 *   |  | +------------------- Screen expand (Fn + F8)
+		 *   |  +--------------------- Brightness
+		 *   +------------------------ Volume/Mute
+		 */
+		key = rtcin(THINKPAD_RTC_HOTKEY1);
+		val = (THINKPAD_RTC_MASK_HOME | THINKPAD_RTC_MASK_SEARCH |
+		    THINKPAD_RTC_MASK_MAIL | THINKPAD_RTC_MASK_WLAN) & key;
+		key = rtcin(THINKPAD_RTC_HOTKEY2);
+		val |= (THINKPAD_RTC_MASK_THINKPAD | THINKPAD_RTC_MASK_VIDEO |
+		    THINKPAD_RTC_MASK_HIBERNATE) & key;
+		val |= (THINKPAD_RTC_MASK_ZOOM & key) >> 1;
+		key = rtcin(THINKPAD_RTC_THINKLIGHT);
+		val |= (THINKPAD_RTC_MASK_THINKLIGHT & key) << 4;
+		key = rtcin(THINKPAD_RTC_SCREENEXPAND);
+		val |= (THINKPAD_RTC_MASK_THINKLIGHT & key) << 4;
+		key = rtcin(THINKPAD_RTC_BRIGHTNESS);
+		val |= (THINKPAD_RTC_MASK_BRIGHTNESS & key) << 5;
+		key = rtcin(THINKPAD_RTC_VOLUME);
+		val |= (THINKPAD_RTC_MASK_VOLUME & key) << 4;
+		break;
+
+	case ACPI_THINKPAD_METHOD_BRIGHTNESS:
+		ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_BRIGHTNESS, &val_ec, 1);
+		val = val_ec & THINKPAD_EC_MASK_BRI;
+		break;
+
+	case ACPI_THINKPAD_METHOD_VOLUME:
+		ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_VOLUME, &val_ec, 1);
+		val = val_ec & THINKPAD_EC_MASK_VOL;
+		break;
+
+	case ACPI_THINKPAD_METHOD_MUTE:
+		val = ((val_ec & THINKPAD_EC_MASK_MUTE) ==
+		    THINKPAD_EC_MASK_MUTE);
+		break;
+
+	case ACPI_THINKPAD_METHOD_THINKLIGHT:
+		if (sc->light_get_supported)
+			acpi_GetInteger(sc->ec_handle, THINKPAD_NAME_KEYLIGHT,
+			    &val);
+		else
+			val = sc->light_val;
+		break;
+
+	case ACPI_THINKPAD_METHOD_BLUETOOTH:
+		acpi_GetInteger(sc->handle, THINKPAD_NAME_WLAN_BT_GET, &val);
+		sc->wlan_bt_flags = val;
+		val = ((val & THINKPAD_NAME_MASK_BT) != 0);
+		break;
+
+	case ACPI_THINKPAD_METHOD_WLAN:
+		acpi_GetInteger(sc->handle, THINKPAD_NAME_WLAN_BT_GET, &val);
+		sc->wlan_bt_flags = val;
+		val = ((val & THINKPAD_NAME_MASK_WLAN) != 0);
+		break;
+
+	case ACPI_THINKPAD_METHOD_FANSPEED:
+		if (sc->fan_handle) {
+			if (ACPI_FAILURE(acpi_GetInteger(sc->fan_handle,
+			    NULL, &val)))
+				val = -1;
+		}
+		else {
+			ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_FANSPEED,
+			    &val_ec, 2);
+			val = val_ec;
+		}
+		break;
+
+	case ACPI_THINKPAD_METHOD_FANLEVEL:
+		/*
+		 * The THINKPAD_EC_FANSTATUS register works as follows:
+		 * Bit 0-5 indicate the level at which the fan operates. Only
+		 *       values between 0 and 7 have an effect. Everything
+		 *       above 7 is treated the same as level 7
+		 * Bit 6 overrides the fan speed limit if set to 1
+		 * Bit 7 indicates at which mode the fan operates:
+		 *       manual (0) or automatic (1)
+		 */
+		if (!sc->fan_handle) {
+			ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_FANSTATUS,
+			    &val_ec, 1);
+			val = val_ec & THINKPAD_EC_MASK_FANLEVEL;
+		}
+		break;
+
+	case ACPI_THINKPAD_METHOD_FANSTATUS:
+		if (!sc->fan_handle) {
+			ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_FANSTATUS,
+			    &val_ec, 1);
+			val = (val_ec & THINKPAD_EC_MASK_FANSTATUS) ==
+			    THINKPAD_EC_MASK_FANSTATUS;
+		}
+		else
+			val = -1;
+		break;
+	}
+
+	return (val);
+}
+
+static int
+acpi_thinkpad_sysctl_set(struct acpi_thinkpad_softc *sc, int method, int arg)
+{
+	int			val, step, i;
+	ACPI_INTEGER		val_ec;
+	ACPI_OBJECT		Arg;
+	ACPI_OBJECT_LIST	Args;
+	ACPI_STATUS		status;
+
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+	/* ACPI_SERIAL_ASSERT(thinkpad); */
+
+	switch (method) {
+	case ACPI_THINKPAD_METHOD_EVENTS:
+		if (arg < 0 || arg > 1)
+			return (EINVAL);
+
+		status = acpi_SetInteger(sc->handle,
+		    THINKPAD_NAME_EVENTS_STATUS_SET, arg);
+		if (ACPI_FAILURE(status))
+			return (status);
+		if (sc->events_mask_supported)
+			return acpi_thinkpad_eventmask_set(sc,
+			    sc->events_availmask);
+		break;
+
+	case ACPI_THINKPAD_METHOD_EVENTMASK:
+		if (sc->events_mask_supported)
+			return acpi_thinkpad_eventmask_set(sc, arg);
+		break;
+
+	case ACPI_THINKPAD_METHOD_BRIGHTNESS:
+		if (arg < 0 || arg > 7)
+			return (EINVAL);
+
+		if (sc->cmos_handle) {
+			/* Read the current brightness */
+			status = ACPI_EC_READ(sc->ec_dev,
+			    THINKPAD_EC_BRIGHTNESS, &val_ec, 1);
+			if (ACPI_FAILURE(status))
+				return (status);
+			val = val_ec & THINKPAD_EC_MASK_BRI;
+
+			Args.Count = 1;
+			Args.Pointer = &Arg;
+			Arg.Type = ACPI_TYPE_INTEGER;
+			Arg.Integer.Value = (arg > val) ?
+			    THINKPAD_CMOS_BRIGHTNESS_UP :
+			    THINKPAD_CMOS_BRIGHTNESS_DOWN;
+
+			step = (arg > val) ? 1 : -1;
+			for (i = val; i != arg; i += step) {
+				status = AcpiEvaluateObject(sc->cmos_handle,
+				    NULL, &Args, NULL);
+				if (ACPI_FAILURE(status))
+					break;
+			}
+		}
+		return ACPI_EC_WRITE(sc->ec_dev, THINKPAD_EC_BRIGHTNESS,
+		    arg, 1);
+		break;
+
+	case ACPI_THINKPAD_METHOD_VOLUME:
+		if (arg < 0 || arg > 14)
+			return (EINVAL);
+
+		status = ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_VOLUME,
+		    &val_ec, 1);
+		if (ACPI_FAILURE(status))
+			return (status);
+
+		if (sc->cmos_handle) {
+			val = val_ec & THINKPAD_EC_MASK_VOL;
+
+			Args.Count = 1;
+			Args.Pointer = &Arg;
+			Arg.Type = ACPI_TYPE_INTEGER;
+			Arg.Integer.Value = (arg > val) ?
+			    THINKPAD_CMOS_VOLUME_UP : THINKPAD_CMOS_VOLUME_DOWN;
+
+			step = (arg > val) ? 1 : -1;
+			for (i = val; i != arg; i += step) {
+				status = AcpiEvaluateObject(sc->cmos_handle,
+				    NULL, &Args, NULL);
+				if (ACPI_FAILURE(status))
+					break;
+			}
+		}
+		return ACPI_EC_WRITE(sc->ec_dev, THINKPAD_EC_VOLUME, arg +
+		    (val_ec & (~THINKPAD_EC_MASK_VOL)), 1);
+		break;
+
+	case ACPI_THINKPAD_METHOD_MUTE:
+		if (arg < 0 || arg > 1)
+			return (EINVAL);
+
+		status = ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_VOLUME,
+		    &val_ec, 1);
+		if (ACPI_FAILURE(status))
+			return (status);
+
+		if (sc->cmos_handle) {
+			val = val_ec & THINKPAD_EC_MASK_VOL;
+
+			Args.Count = 1;
+			Args.Pointer = &Arg;
+			Arg.Type = ACPI_TYPE_INTEGER;
+			Arg.Integer.Value = THINKPAD_CMOS_VOLUME_MUTE;
+
+			status = AcpiEvaluateObject(sc->cmos_handle, NULL,
+			    &Args, NULL);
+			if (ACPI_FAILURE(status))
+				break;
+		}
+		return ACPI_EC_WRITE(sc->ec_dev, THINKPAD_EC_VOLUME, (arg==1) ?
+		   val_ec | THINKPAD_EC_MASK_MUTE :
+		   val_ec & (~THINKPAD_EC_MASK_MUTE), 1);
+		break;
+
+	case ACPI_THINKPAD_METHOD_THINKLIGHT:
+		if (arg < 0 || arg > 1)
+			return (EINVAL);
+
+		if (sc->light_set_supported) {
+			Args.Count = 1;
+			Args.Pointer = &Arg;
+			Arg.Type = ACPI_TYPE_INTEGER;
+			Arg.Integer.Value = arg ?
+			    sc->light_cmd_on : sc->light_cmd_off;
+
+			status = AcpiEvaluateObject(sc->light_handle, NULL,
+			    &Args, NULL);
+			if (ACPI_SUCCESS(status))
+				sc->light_val = arg;
+			return (status);
+		}
+		break;
+
+	case ACPI_THINKPAD_METHOD_BLUETOOTH:
+		if (arg < 0 || arg > 1)
+			return (EINVAL);
+
+		val = (arg == 1) ? sc->wlan_bt_flags |
+		    THINKPAD_NAME_MASK_BT :
+		    sc->wlan_bt_flags & (~THINKPAD_NAME_MASK_BT);
+		return acpi_SetInteger(sc->handle, THINKPAD_NAME_WLAN_BT_SET,
+		    val);
+		break;
+
+	case ACPI_THINKPAD_METHOD_FANLEVEL:
+		if (arg < 0 || arg > 7)
+			return (EINVAL);
+
+		if (!sc->fan_handle) {
+			/* Read the current fanstatus */
+			ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_FANSTATUS,
+			    &val_ec, 1);
+			val = val_ec & (~THINKPAD_EC_MASK_FANLEVEL);
+
+			return ACPI_EC_WRITE(sc->ec_dev, THINKPAD_EC_FANSTATUS,
+			    val | arg, 1);
+		}
+		break;
+
+	case ACPI_THINKPAD_METHOD_FANSTATUS:
+		if (arg < 0 || arg > 1)
+			return (EINVAL);
+
+		if (!sc->fan_handle) {
+			/* Read the current fanstatus */
+			ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_FANSTATUS,
+			    &val_ec, 1);
+
+			return ACPI_EC_WRITE(sc->ec_dev, THINKPAD_EC_FANSTATUS,
+			    (arg == 1) ? (val_ec | THINKPAD_EC_MASK_FANSTATUS) :
+			    (val_ec & (~THINKPAD_EC_MASK_FANSTATUS)), 1);
+		}
+		break;
+	}
+
+	return (0);
+}
+
+static int
+acpi_thinkpad_sysctl_init(struct acpi_thinkpad_softc *sc, int method)
+{
+	int 			dummy;
+	ACPI_OBJECT_TYPE 	cmos_t;
+	ACPI_HANDLE		ledb_handle;
+
+	switch (method) {
+	case ACPI_THINKPAD_METHOD_EVENTS:
+		/* Events are disabled by default */
+		return (TRUE);
+
+	case ACPI_THINKPAD_METHOD_EVENTMASK:
+		return (sc->events_mask_supported);
+
+	case ACPI_THINKPAD_METHOD_HOTKEY:
+	case ACPI_THINKPAD_METHOD_BRIGHTNESS:
+	case ACPI_THINKPAD_METHOD_VOLUME:
+	case ACPI_THINKPAD_METHOD_MUTE:
+		/* EC is required here, which was already checked before */
+		return (TRUE);
+
+	case ACPI_THINKPAD_METHOD_THINKLIGHT:
+		sc->cmos_handle = NULL;
+		sc->light_get_supported = ACPI_SUCCESS(acpi_GetInteger(
+		    sc->ec_handle, THINKPAD_NAME_KEYLIGHT, &sc->light_val));
+
+		if ((ACPI_SUCCESS(AcpiGetHandle(sc->handle, "\\UCMS",
+		    &sc->light_handle)) ||
+		    ACPI_SUCCESS(AcpiGetHandle(sc->handle, "\\CMOS",
+		    &sc->light_handle)) ||
+		    ACPI_SUCCESS(AcpiGetHandle(sc->handle, "\\CMS",
+		    &sc->light_handle))) &&
+		    ACPI_SUCCESS(AcpiGetType(sc->light_handle, &cmos_t)) &&
+		    cmos_t == ACPI_TYPE_METHOD) {
+			sc->light_cmd_on = 0x0c;
+			sc->light_cmd_off = 0x0d;
+			sc->cmos_handle = sc->light_handle;
+		}
+		else if (ACPI_SUCCESS(AcpiGetHandle(sc->handle, "\\LGHT",
+		    &sc->light_handle))) {
+			sc->light_cmd_on = 1;
+			sc->light_cmd_off = 0;
+		}
+		else
+			sc->light_handle = NULL;
+
+		sc->light_set_supported = (sc->light_handle &&
+		    ACPI_FAILURE(AcpiGetHandle(sc->ec_handle, "LEDB",
+		    &ledb_handle)));
+
+		if (sc->light_get_supported)
+			return (TRUE);
+
+		if (sc->light_set_supported) {
+			sc->light_val = 0;
+			return (TRUE);
+		}
+
+		return (FALSE);
+
+	case ACPI_THINKPAD_METHOD_BLUETOOTH:
+	case ACPI_THINKPAD_METHOD_WLAN:
+		if (ACPI_SUCCESS(acpi_GetInteger(sc->handle,
+		    THINKPAD_NAME_WLAN_BT_GET, &dummy)))
+			return (TRUE);
+		return (FALSE);
+
+	case ACPI_THINKPAD_METHOD_FANSPEED:
+		/* 
+		 * Some models report the fan speed in levels from 0-7
+		 * Newer models report it contiguously
+		 */
+		sc->fan_levels = (ACPI_SUCCESS(AcpiGetHandle(sc->handle, "GFAN",
+		    &sc->fan_handle)) ||
+		    ACPI_SUCCESS(AcpiGetHandle(sc->handle, "\\FSPD",
+		    &sc->fan_handle)));
+		return (TRUE);
+
+	case ACPI_THINKPAD_METHOD_FANLEVEL:
+	case ACPI_THINKPAD_METHOD_FANSTATUS:
+		/* 
+		 * Fan status is only supported on those models,
+		 * which report fan RPM contiguously, not in levels
+		 */
+		if (sc->fan_levels)
+			return (FALSE);
+		return (TRUE);
+
+	case ACPI_THINKPAD_METHOD_THERMAL:
+		if (ACPI_SUCCESS(acpi_GetInteger(sc->ec_handle,
+		    THINKPAD_NAME_THERMAL_GET, &dummy))) {
+			sc->thermal_updt_supported =
+			    ACPI_SUCCESS(acpi_GetInteger(sc->ec_handle,
+			    THINKPAD_NAME_THERMAL_UPDT, &dummy));
+			return (TRUE);
+		}
+		return (FALSE);
+	}
+	return (FALSE);
+}
+
+static void
+acpi_thinkpad_notify(ACPI_HANDLE h, UINT32 notify, void *context)
+{
+	int		event, arg, type;
+	device_t	dev = context;
+	struct acpi_thinkpad_softc *sc = device_get_softc(dev);
+
+	ACPI_FUNCTION_TRACE_U32((char *)(uintptr_t)__func__, notify);
+
+	if (notify != 0x80)
+		device_printf(dev, "Unknown notify\n");
+
+	for (;;) {
+		acpi_GetInteger(acpi_get_handle(dev), THINKPAD_NAME_EVENTS_GET,
+		    &event);
+
+		if (event == 0)
+			break;
+
+		type = (event >> 12) & 0xf;
+		arg = event & 0xfff;
+		switch (type) {
+		case 1:
+			if (!(sc->events_availmask & (1 << (arg - 1)))) {
+				device_printf(dev, "Unknown key %d\n", arg);
+				break;
+			}
+
+			/* Notify devd(8) */
+			device_printf(dev, "THINKPAD event: %u\n",
+			    (arg & 0xff));
+			acpi_UserNotify("THINKPAD", h, (arg & 0xff));
+			break;
+		default:
+			break;
+		}
+	}
+}
+
+static void
+acpi_thinkpad_refresh(void *arg)
+{
+	struct acpi_thinkpad_softc *sc = (struct acpi_thinkpad_softc *)arg;
+	char temp_cmd[] = "TMP0";
+	int data, i;
+	ACPI_INTEGER speed;
+
+	for (i = 0; i < 8; i++) {
+		temp_cmd[3] = '0' + i;
+		
+                /*
+                 * The TMPx methods seem to return +/- 128 or 0
+                 * when the respecting sensor is not available
+                 */
+		sc->sensors[i].flags &= ~SENSOR_FINVALID;
+                if (ACPI_FAILURE(acpi_GetInteger(sc->ec_handle, temp_cmd,
+                    &data)) || ABS(data) == 128 || data == 0) {
+			sc->sensors[i].flags |= SENSOR_FINVALID;
+                        data = 0;
+		}
+                else if (sc->thermal_updt_supported) {
+                        /* XXX: Temperature is reported in tenth of Kelvin */
+                        data = (data - 2732 + 5) / 10;
+		}
+		sc->sensors[i].value = data * 1000000 + 273150000;
+        }
+	
+	sc->sensors[8].flags &= ~SENSOR_FINVALID;
+	if (sc->fan_handle) {
+		if (ACPI_FAILURE(acpi_GetInteger(sc->fan_handle,
+		    NULL, &data)))
+			sc->sensors[8].flags |= SENSOR_FINVALID;
+                        data = -1;
+        }
+        else {
+                ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_FANSPEED, &speed, 2);
+                data = speed;
+        }
+
+	sc->sensors[8].value = data;
+}
diff --git a/sys/platform/pc32/conf/files b/sys/platform/pc32/conf/files
--- a/sys/platform/pc32/conf/files
+++ b/sys/platform/pc32/conf/files
@@ -72,6 +72,7 @@ dev/serial/dgb/dgm.c			optional	dgm
 ${OSACPI_MD_DIR}/acpi_machdep.c		optional        acpi
 ${OSACPI_MD_DIR}/acpi_wakeup.c		optional        acpi
 ${OSACPI_MD_DIR}/acpi_toshiba.c		optional        acpi_toshiba acpi
+${ACPICA_DIR}/acpi_thinkpad/acpi_thinkpad.c optional	acpi_thinkpad acpi
 acpi.h					optional	acpi		\
 	dependency	"$S/${ACPICA_DIR}/include/acpi.h"		\
 	compile-with	"cp $S/${ACPICA_DIR}/include/acpi.h ${.OBJDIR}/"	\



From hasso at estpak.ee  Thu Mar 20 03:49:13 2008
From: hasso at estpak.ee (Hasso Tepper)
Date: Thu, 20 Mar 2008 03:49:13 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Some questions regarding ACPI
In-Reply-To: <200803191322.46366.hasso@estpak.ee>
Message-ID: <200803201237.28823.hasso@estpak.ee>

Hasso Tepper wrote:
> There is also one fatal issue -laptop locks up hardly (no panic) while 
> unloading module. Any idea regarding this is welcome.

Nevermind, solved.


-- 
Hasso




From dillon at apollo.backplane.com  Fri Mar 21 19:24:01 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Fri, 21 Mar 2008 19:24:01 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: panic: assertion: hammer_btree_cmp(cursor->left_bound,	&cursor->node->ondisk->elms[0].leaf.base) <= 0 in btree_split_leaf
In-Reply-To: <200802232204.m1NM4cxd046264@apollo.backplane.com>
Message-ID: <200803220212.m2M2CiAY014435@apollo.backplane.com>

:While trying to find a procedure to reliably reproduce the panic
:I reported last time, I caught a different panic (uploaded at
: ~y0netan1/crash/9/ on my leaf account).  I wrote the following shell
:script (make sure to edit variables DISKS and MOUNTPT before using this
:script or it may trash your system):

    Ok, I believe I have fixed the left_bound assertion.  I also believe
    I have fixed the node ref count assertion on umount.

    There is currently one unfixed assertion related to the I/O
    path... sometimes the bp is being improperly disassociated from the
    related HAMMER structure.

    The full-filesystem case is still not being handled so don't test that :-)

					    -Matt





From c.turner at 199technologies.org  Sun Mar 23 09:48:29 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Sun, 23 Mar 2008 09:48:29 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
Message-ID: <47E6870C.4080709@199technologies.org>

I'm finally getting around to doing 1.12 upgrades, and have setup a 
separate machine to do my bulk package builds / upgrades etc,
so as not to disrupt my 'dev server' while things are being
built / tested

However, this seems kind of wasteful - the only purpose of this machine
is to build packages against a specific release..
And since building packages for a particular release generally requires 
only the userland, appropriate headers and correct 'uname' output - so:

it seems like if spoofing uname is configured inside a jail,
the next (or previous..) release can be installed into a jail and
used for building / testing packages without the overhead of a VM or 
maintaining a separate physical host

I did a quick scan of the tree to see what this would take, and, high 
level, it seems like only the following changes would need to be made:

- update struct jail to add a 'osrelease' string
  (implies bumping 'jail api' to 2?)
- update jail(8) to actually pass this information along
- update sys_uname to test ucred for jailed processes, and
  use the struct jail osrelease if appropriate
- similarly update sysctl kern.osrelease to support jail spoofing
  (if possible - didn't get this far in the research yet)
  could be less of a problem for builds, as I think most things use
 uname(1) ... but good to keep the environment consistent I suppose..
I'm still a bit confused as to how 'osrelease' is defined - everything
I'm finding is showing up as extern char[] .. perhaps this is something 
in the build I'm not familiar with?

also,

is the so-called 'stupid hackery' in sys_uname needed still?

Before I start any coding, does this:

- sound like something useful
- sound like the right approach
Thinking this could have wider useful implications e.g. for pkgbox
& so on -  for example setting up automated bulks w/various combinations 
of pkgsrc and releases, etc.

Cheers,

- Chris





From corecode at fs.ei.tum.de  Sun Mar 23 10:06:38 2008
From: corecode at fs.ei.tum.de (Simon 'corecode' Schubert)
Date: Sun, 23 Mar 2008 10:06:38 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <47E68C74.3080808@fs.ei.tum.de>

Chris Turner wrote:
I did a quick scan of the tree to see what this would take, and, high 
level, it seems like only the following changes would need to be made:
brave investigation.  but you could also simply set UNAME_r :)

sweatshorts % uname -r
1.13.0-DEVELOPMENT
sweatshorts % UNAME_r=1.12-RELEASE uname -r
1.12-RELEASE
I think that's good enough :D

cheers
  simon
--
Serve - BSD     +++  RENT this banner advert  +++    ASCII Ribbon   /"\
Work - Mac      +++  space for low ????????? NOW!1  +++      Campaign     \ /
Party Enjoy Relax   |   http://dragonflybsd.org      Against  HTML   \
Dude 2c 2 the max   !   http://golden-apple.biz       Mail + News   / \




From c.turner at 199technologies.org  Sun Mar 23 10:50:13 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Sun, 23 Mar 2008 10:50:13 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <47E69656.8080605@199technologies.org>

Simon 'corecode' Schubert wrote:
brave investigation.  but you could also simply set UNAME_r :)
Doh! Thanks for the tip!

they should change the phrase from RTFM to 'Carefully RTFM' :)

well.. scratch that change then. 1 less patch to write.

- Chris





From c.turner at 199technologies.org  Sun Mar 23 11:15:52 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Sun, 23 Mar 2008 11:15:52 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <47E69C7C.8010109@199technologies.org>

Chris Turner wrote:
Simon 'corecode' Schubert wrote:
brave investigation.  but you could also simply set UNAME_r :)

for the record - if anyone's interested - adding a line e.g.:

ALL_ENV+= UNAME_r=1.12-RELEASE

to mk.conf looks like it -might- work ..

(unless wants to chime in & verify)





From joerg at britannica.bec.de  Sun Mar 23 11:46:53 2008
From: joerg at britannica.bec.de (Joerg Sonnenberger)
Date: Sun, 23 Mar 2008 11:46:53 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <20080323181428.GA2099@britannica.bec.de>

On Sun, Mar 23, 2008 at 01:41:42PM -0400, Chris Turner wrote:
> they should change the phrase from RTFM to 'Carefully RTFM' :)

RTFMAI -- Read The Fine Manual Again, Idiot.

Joerg




From dillon at apollo.backplane.com  Sun Mar 23 20:05:36 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Sun, 23 Mar 2008 20:05:36 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
Message-ID: <200803240257.m2O2voNH038355@apollo.backplane.com>

    Here's an update on the HAMMER work!

    Current status:

    * Passes all standard filesystem stress tests and buildworld will
      run with a HAMMER /usr/obj.  Large histories are able to accumulate
      without effecting performance.

    * Pruning and reblocking code is in and partially tested, but now needs
      more stringent testing.

    * Full historical access appears to be working but needs testing.
      Note that a sync is still needed to flush dirty cached data prior
      to acquiring a timestamp for the 'snapshot' to be set in stone.
      (dirty data cached in-memory has no historical tags and must be
      committed to physical disk before it can be accessed historically).


    Current bugs:

    * There is one known bug in the standard operations code paths
      that results in an assertion in HAMMER's I/O subsystem.

    * There are probably bugs in the reblocking and/or pruning code.  More
      likely in the reblocking code.


    There are two big-ticket and several little-ticket items left.  HAMMER
    will officially go Alpha when the big-ticket items are done, and beta
    when we get a few of the little-ticket items done.

    Big ticket items left:

    * UNDO (crash recovery) code.  Currently it writes out undo records but
      they are not yet sequenced, buffer writes are not yet ordered, and
      there is no mount-time recovery code yet.

      This is the last item needed before HAMMER can go operational.

    * Filesystem full handling.  Currently no space is reserved for dirty
      cached data so it is possible to create/write files and for HAMMER
      to not have sufficient space left on-disk to flush it.


    Little ticket items:

    * Automated reblocking (currently these functions are manually
      initialized via the hammer utility).

    * I/O clustering and preliminary BMAP op when writing out large files.

    * CRC checking (CRC fields are reserved but not entirely generated yet
      and not yet checked at all).

    * Disaster Recovery filesystem scan.

    * Boot support.

    I expect all of these items and more to be handled by the 2.0 release
    in July.

			    Additional HAMMER capabilities
				(no timeline yet)

    * Adding, removing, and resizing a HAMMER filesystem's backing store.

			Ultimate Goals and working towards them
				(no timeline yet)

    Our ultimate goal with HAMMER and DragonFly in general is to support
    fully cache coherent replication in a multi-machine environment.  This
    involves several steps and networking protocols.

    * Replication of synchronization streams based on the UNDO log.  If
      resynchronizing to a target which is too old a B-Tree scan will
      likely be required.

    * Cache coherency protocols for machine-machine coherency for both
      replicated and remote-HAMMER access.

    I have no time frame for these items yet.  It will depend on how quickly
    HAMMER moves to Alpha and Beta status.  I will say, however, now
    that HAMMER's on-disk format has solidified, that I have a very precise
    understanding of the protocols that will be needed to accomplish fully
    cache coherent remote access for both replicated and non-replicated
    (remote mount style) access.

    And, as you know, fully coherent filesystem access across machines is
    going to be the basis for DragonFly's clustering across said machines.

    In summary, things are progressing very well.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From justin at shiningsilence.com  Sun Mar 23 20:10:13 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Sun, 23 Mar 2008 20:10:13 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <53758.192.168.0.252.1206327873.squirrel@www.shiningsilence.com>

On Sun, March 23, 2008 12:36 pm, Chris Turner wrote:

> it seems like if spoofing uname is configured inside a jail,
> the next (or previous..) release can be installed into a jail and
> used for building / testing packages without the overhead of a VM or
> maintaining a separate physical host

If you don't need a jail to spoof uname, as others posted, you can
installworld into a chroot and build everything you want there using
Joerg's spiffy pbulk.  That's what I'm doing on pkgbox now; I can hand you
my somewhat terse notes if you want.  It would be relatively easy to set
up the configuration you're talking about.





From sepherosa at gmail.com  Sun Mar 23 20:18:20 2008
From: sepherosa at gmail.com (Sepherosa Ziehau)
Date: Sun, 23 Mar 2008 20:18:20 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <ea7b9c170803232012n2f27f893tf1d756d7c9770419@mail.gmail.com>

On Mon, Mar 24, 2008 at 2:14 AM, Joerg Sonnenberger
<joerg at britannica.bec.de> wrote:
> On Sun, Mar 23, 2008 at 01:41:42PM -0400, Chris Turner wrote:
>  > they should change the phrase from RTFM to 'Carefully RTFM' :)
>
>  RTFMAI -- Read The Fine Manual Again, Idiot.

http://leaf.dragonflybsd.org/~sephe/rtfm.jpg

:D

>
>  Joerg
>



-- 
Live Free or Die




From justin at shiningsilence.com  Sun Mar 23 20:38:30 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Sun, 23 Mar 2008 20:38:30 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: GSoC 2008 - mentors signup
Message-ID: <53885.192.168.0.252.1206329503.squirrel@www.shiningsilence.com>

If you are planning to be a mentor for a Summer of Code project, please
sign up here for the mentors mailing list:

http://groups.google.com/group/google-summer-of-code-mentors-list

If you've already signed up, your subscription should be set up tomorrow.





From justin at shiningsilence.com  Sun Mar 23 21:12:01 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Sun, 23 Mar 2008 21:12:01 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: GSoC 2008 - mentors signup
In-Reply-To: <53885.192.168.0.252.1206329503.squirrel@www.shiningsilence.com>
Message-ID: <54025.192.168.0.252.1206331572.squirrel@www.shiningsilence.com>

Also!

If you are a potential mentor and you have not done so yet:

http://code.google.com/soc/mentor_step1.html

Get yourself registered as a mentor for the Summer of Code project.  Once
you are in there, check off DragonFly in the "My Profile" section.

You will need a Google Account if you don't have one:

http://www.google.com/accounts

This will add you to the list of mentors in the Google Summer of Code web
application, so you can review/be attached to projects.

A guide is available if you want more information:

http://groups.google.com/group/google-summer-of-code-announce/web/guide-to-the-gsoc-web-app-for-mentors-and-organization-administrators






From c.turner at 199technologies.org  Mon Mar 24 04:29:28 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Mon, 24 Mar 2008 04:29:28 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <47E78ECE.4070307@199technologies.org>

Justin C. Sherrill wrote:
If you don't need a jail to spoof uname, as others posted, you can
installworld into a chroot and build everything you want there using
Joerg's spiffy pbulk.  That's what I'm doing on pkgbox now; I can hand you
my somewhat terse notes if you want.  It would be relatively easy to set
up the configuration you're talking about.
cheers - I guess I thought incorrectly that something 'special' was 
needed to get the uname to change .. have been using the legacy bulks in 
chroots / jails (for 'same os' builds) as I haven't quite migrated to 
pbulk yet ..

thanks for the help offer - I'll ask if I run into trouble.




From dillon at apollo.backplane.com  Mon Mar 24 08:28:49 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Mon, 24 Mar 2008 08:28:49 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <200803241500.m2OF0CG8043760@apollo.backplane.com>


:http://leaf.dragonflybsd.org/~sephe/rtfm.jpg
:
::D

    Ho!

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From elekktretterr at exemail.com.au  Mon Mar 24 09:10:15 2008
From: elekktretterr at exemail.com.au (Petr Janda)
Date: Mon, 24 Mar 2008 09:10:15 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
In-Reply-To: <200803240257.m2O2voNH038355@apollo.backplane.com>
Message-ID: <200803250138.49775.elekktretterr@exemail.com.au>


>
>     And, as you know, fully coherent filesystem access across machines is
>     going to be the basis for DragonFly's clustering across said machines.
>
>     In summary, things are progressing very well.
>


Hi Matt,
That's good to know things are going so well. Got a question. If memory serves 
me right, initially there was also going to be a thing called ANVIL, I can't 
remember what it was supposed to do and whether its still in your design. 
Could you elaborate a little?

Thanks,
Petr




From dillon at apollo.backplane.com  Mon Mar 24 14:12:11 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Mon, 24 Mar 2008 14:12:11 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
In-Reply-To: <200803240257.m2O2voNH038355@apollo.backplane.com>
Message-ID: <200803242100.m2OL0nWV046868@apollo.backplane.com>


:Hi Matt,
:That's good to know things are going so well. Got a question. If memory serves 
:me right, initially there was also going to be a thing called ANVIL, I can't 
:remember what it was supposed to do and whether its still in your design. 
:Could you elaborate a little?
:
:Thanks,
:Petr

    It's not really in the HAMMER design any more, primarily because HAMMER's
    volume model seems to work fine as-is.  Ultimately something like ANVIL
    (a block storage manager) would prove beneficial to the project but it
    would be treated as a separate project.  HAMMER's redundancy model is
    going to be baesd around replication and clustering.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From tgen at netphreax.net  Mon Mar 24 18:31:37 2008
From: tgen at netphreax.net (Thomas E. Spanjaard)
Date: Mon, 24 Mar 2008 18:31:37 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
In-Reply-To: <200803240257.m2O2voNH038355@apollo.backplane.com>
Message-ID: <47E85337.2070407@netphreax.net>

Matthew Dillon wrote:
    * Full historical access appears to be working but needs testing.
      Note that a sync is still needed to flush dirty cached data prior
      to acquiring a timestamp for the 'snapshot' to be set in stone.
      (dirty data cached in-memory has no historical tags and must be
      committed to physical disk before it can be accessed historically).
Wouldn't making timestamp queries (at least from userland) enforce a 
sync on the volume in question be useful here?
--
        Thomas E. Spanjaard
        tgen at netphreax.net
Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00005.pgp
Type: application/octet-stream
Size: 186 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080324/3077333f/attachment-0014.obj>

From dillon at apollo.backplane.com  Mon Mar 24 20:10:12 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Mon, 24 Mar 2008 20:10:12 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
In-Reply-To: <200803240257.m2O2voNH038355@apollo.backplane.com>
Message-ID: <200803250302.m2P32qLP050160@apollo.backplane.com>


:Wouldn't making timestamp queries (at least from userland) enforce a 
:sync on the volume in question be useful here?
:-- 
:         Thomas E. Spanjaard
:         tgen at netphreax.net

    Making the 'hammer now' command do a sync() is a good idea.  I will
    make that change right now so it doesn't get lost.

    Here's a general overview of the issues involved with having historical
    access to the filesystem:

				----------------

    Recording the timestamps in the in-memory cache, for a finer-grained
    snapshot capability, is doable but has its own issues.  Here's an
    illustration:

    open()  create file
    write() append 4K	(file size now 4K)
    write() append 4K	(file size now 8K)
    write() append 4K	(file size now 12K)
    write() append 4K	(file size now 16K)

    Now NONE of this has gone to disk yet, it's entirely in the in-memory
    cache.  The inode is in the in-memory cache.  The data is stored in
    the buffer cache.  Even the directory entry for the file that we
    just created is still in the in-memory cache (HAMMER caches the raw
    records it intends to commit later on).

    If I wanted to be able to acquire a timestamp between each write and
    'see' a snapshot of the file as of any point in the above sequence,
    then every write would also have to allocate a copy of the inode
    (because it changes size on each write).

    The data has the same problem though with a slightly different example.
    Lets say each write() was a seek-write, overwriting the previous data.
    Now with every write() I would have to allocate a copy of the data
    being overwritten.  This is complicated by the fact that the buffer
    cache has no clue about 'historical' accesses, so I would not be able
    to use the buffer cache to cache the data.

    There's also another problem and that is with the efficiency of the
    topology on-disk.  Even if I maintained all the copies of the inode
    and all the copies of the data in-memory, I would still have to sync
    all those copies to disk in order for things to remain historically
    coherent (whether it be in-cache or on-disk).  This would result in
    hundreds or even thousands of copies of the inode on-disk, not to
    mention potentially many copies of the data.

    I just don't want to do that right now, at least not as a default.  A
    lot of performance would be lost.  Hence a sync() is needed if
    you want to create a demark which you can accurately snapshot.

				-------------

    Here's a quick synopsis of how the cache would operate in a clustered
    filesystem:

    In order to properly integrate with in-memory caches, a wider cache
    coherency infrastructure is needed between machines such that
    modifications made on one machine proactively invalidate those
    protions of the cache(s) on other machines.  At the same time, any
    'dirty' cache data, for example when a file is created or written to,
    must lock the cache space in question on all other machines.
    The cache space in this case is not just the file data, but also the
    related namespaces (for creations, deletions, and renames).  Attempts
    to access locked spaces from other machines in the cluster would have
    to force a flush to the filesystem backing store and lower the cache
    states for the effected information on the original machine from dirty
    to shared-read-only.

    It will be easiest to integrate the cache coherency information into
    the buffer cache and namecache themselves.  Once a machine has dirtied
    an in-memory cache element... for example part of the namespace when
    creating a file or chunks of data written within a file, that machine
    must have a free hand to make further modifications to the cache spaces
    involved without further interaction with other machines.

				-------------

    Now, if you think of those two major elements you can see that they
    actually fit together quite well.  If I were to attempt to maintain
    transactional coherency on a per-system-call basis then the cache
    granularity between machines would have to be much, much smaller then
    our current in-memory caching elements provide.  That would become
    a really nasty coding problem.  So I don't even want to begin to
    complate transactional coherency at a finer-grain then sync() or
    fsync() until long after we actually have clustering working.

						-Matt





From elekktretterr at exemail.com.au  Mon Mar 24 21:56:58 2008
From: elekktretterr at exemail.com.au (Petr Janda)
Date: Mon, 24 Mar 2008 21:56:58 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
In-Reply-To: <200803240257.m2O2voNH038355@apollo.backplane.com>
Message-ID: <200803251516.16407.elekktretterr@exemail.com.au>

So is it needed to run hammer now in order to "create" a snapshot? What would 
I do in situation like this: got a hammer filesystem and couple of the files 
change on day to day basis. Then a week later I needed to access one of the 
files, in exactly the state they were 7 days ago.

Cheers,
Petr




From dillon at apollo.backplane.com  Mon Mar 24 22:34:15 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Mon, 24 Mar 2008 22:34:15 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
In-Reply-To: <200803240257.m2O2voNH038355@apollo.backplane.com>
Message-ID: <200803250526.m2P5QZ5X051081@apollo.backplane.com>


:So is it needed to run hammer now in order to "create" a snapshot? What would 
:I do in situation like this: got a hammer filesystem and couple of the files 
:change on day to day basis. Then a week later I needed to access one of the 
:files, in exactly the state they were 7 days ago.
:
:Cheers,
:Petr

    No, you do not have to run 'hammer now' to create a snapshot.  The
    kernel syncs all filesystems every 30 seconds, so if you do nothing
    at all you get a snapshot granularity of 30 seconds.

    Where you would use 'hammer now' is if you wanted the most current
    snapshot possible for the purpose of, say, backing up your filesystem
    to another machine.  You might do something like this:

	set timestamp = `hammer now`
	cpdup /mountpoint/@@$timestamp targethost:/somepath

    But if you didn't care about that you could just go back far enough
    that you get a stable historical view... e.g. go back 1 minute and you
    would have a stable view into your filesystem.

	set timestamp = `hammer stamp 60s`		<------ doesn't sync
	cpdup /mountpoint/@@$timestamp targethost:/somepath


    Ultimately the idea of managing filesystems this way is to still do
    regular backups from your production machine to your backup machine
    (ultimately by way of replication), with both running HAMMER, but only
    retain a limited amount of history on the production box.  You might
    desire to retain only one week's worth of history on the production box,
    retain one month's history on your local backup box, and retain a very
    granular one year's worth of history on your remote backup box.

    Come to think of it, I should add some more directives to the
    'hammer prune' command to make that easier to specify.

    Until I implement a live replication 'feed' the minimum granularity on
    the backup box will be how often you do your backups (e.g. once a day),
    and you can prune it into more granular forms from that starting point.
    Once we have a live replication feed the backup box will have the same
    30-second granularity that the production machine has.

    A major bullet point for this style of management is that the retention
    policy on the various boxes can be different even though they are
    all slaved off the same production filesystem.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From justin at shiningsilence.com  Tue Mar 25 05:58:49 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Tue, 25 Mar 2008 05:58:49 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: SoC - student signups
Message-ID: <58180.65.106.147.226.1206449676.squirrel@www.shiningsilence.com>

Here's a quick link roundup:

Are you a student?  Put in your application for a Google Summer of Code here:

http://code.google.com/soc/2008/student_signup.html

Student guide:
http://groups.google.com/group/google-summer-of-code-announce/web/guide-to-the-gsoc-web-app-for-student-applicants

Are you a mentor?  (That means hasso, hsu, sephe, matthias, TGEN, and
corecode right now)

Student proposals will show up on the mentor page, linked below.  You will
get to rate them, and take the one(s) that you want to mentor.

Mentor page:
http://code.google.com/soc/2008/mentor_home.html
Mentor guide:
http://groups.google.com/group/google-summer-of-code-announce/web/guide-to-the-gsoc-web-app-for-mentors-and-organization-administrators

If you are a mentor and are communicating with potential students, send
them the URLs above for student signup and the student guide; work with
them if they ask for advice on what to say in the application.  They can
resubmit up to 20 times if they want to correct it.

Deadline is March 31st.






From noah.yan at gmail.com  Thu Mar 27 20:17:48 2008
From: noah.yan at gmail.com (Yonghong Yan)
Date: Thu, 27 Mar 2008 20:17:48 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: About DFBSD.64
In-Reply-To: <47EB0B5B.5020802@gmail.com>
Message-ID: <59521b110803272015y1cc8cc39uc93f154ed36e0505@mail.gmail.com>

thanks for your interest.

I owe to everybody for any update or work in the past four months. so
many things happen in my work and my family (they are all good:) and
keep me extremely busy. But i am not leaving and will be back on this
soon.

the latest sources are in http://repo.or.cz/w/dragonfly/port-amd64.git
, I did have a compiled kernel long time before, but I have to break
it to work on the pmap. you can pick up from there. TGEN will help you
a lot, also keep me posted too, if you like.

Noah

On Wed, Mar 26, 2008 at 9:50 PM, Sdavtaker <sdavtaker at gmail.com> wrote:
> Hello,
>  Im applying to GSoC to work in the x64 version of DFBSD with TGEN, i
>  found some work already done in the repository and some mails in the
>  archive from you.
>  I was wondering if you already had a working compiled kernel in AMD64
>  machine and what was not working yet to continue that work.
>  Thanks for any info.
>  Sdav
>




From dillon at apollo.backplane.com  Sat Mar 29 13:27:43 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Sat, 29 Mar 2008 13:27:43 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 29-Mar-2008
Message-ID: <200803292022.m2TKMLGe004942@apollo.backplane.com>

    Good progress continues to be made.  HAMMER survived acting as my
    LAN backup machine (in full historical mode) for almost a week before
    it hit an assertion.  I've fixed that issue and believe that the core
    filesystem implementation code is now 'very stable'.

    Note that the recent commit will result in many more 'hammer_lock_ex:'
    messages on the console then you may have previously observed.  This is
    due to the way object id's are allocated in the face of parallel 
    modifications to the filesystem, resulting in too much locality of
    reference in the B-Tree.  I do intend to improve it.

    I am still working on the two major items needed before HAMMER can be
    declared operational, those being the filesystem full handling and the
    undo/recovery-on-mount code.  These are the last 'hard' bits left in
    the design.

    With exception to filling up the filesystem, which *will* create a mess,
    and noting that no crash recovery code exists yet (so you have to newfs
    it if you crash), I'd appreciate it if interested parties could test
    the other functions of the filesystem, in particular the pruning and
    reblocking functions (man hammer), and the historical access functions.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From dillon at apollo.backplane.com  Sun Mar 30 15:11:03 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Sun, 30 Mar 2008 15:11:03 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Need ideas on how to solve an st_ino/st_dev test issue for HAMMER.
Message-ID: <200803302207.m2UM7BCp016402@apollo.backplane.com>

    Here's the problem, given historical access softlinks as shown below:

test30# ls -lda cra*
drwxr-xr-x  1 root  wheel  Mar 29 13:04 crater
lrwxr-xr-x  1 root  wheel  Mar 29 18:57 crater.20080329 -> crater@@0x47eef383
lrwxr-xr-x  1 root  wheel  Mar 30 01:24 crater.20080330 -> crater@@0x47ef4e29
-rw-r--r--  2 root  wheel  Mar 30 01:24 crater.log

    The problem is that if I do this:

    diff -r crater.20080329/var/log crater.20080330/var/log

    Diff just returns without actually diffing anything.  The reason is
    because diff checks st_ino and st_dev and believes the directories/files
    to be identical because they match.

    I considered munging the inode number for historical accesses, but
    that would seriously break NFS exports which try to access historical
    files and directories.  Right now NFS *is* able to distinguish between
    the two because NFS handles are 128-bit-wide entities, so I can encode
    the as-of transaction id as part of the filehandle.  But userland
    programs only have access to a 64-bit-wide inode so userland still
    believes the files to be identical.

    st_dev is only 32 bits, carefully munging it is an option if we
    could figure out a way to do it, but I'd rather not.

    I am considering using st_gen but then we'd have to patch third
    party software to test st_gen along with everything else.  This may
    be the only workable solution, though, and only a few programs would
    need to be patched.  st_gen is only 32 bits but it would solve the
    problem as we would be able to use all 32 bits.

    If anyone has any bright ideas, including 'leave it alone', I'm all
    ears.

						-Matt





From justin at shiningsilence.com  Mon Mar 31 10:40:42 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Mon, 31 Mar 2008 10:40:42 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: SoC student applications due by 5PM PDT tomorrow
In-Reply-To: <1942.192.168.0.242.1206930479.squirrel@www.shiningsilence.com>
Message-ID: <11892.67.108.184.175.1206984967.squirrel@www.shiningsilence.com>

On Sun, March 30, 2008 10:27 pm, Justin C. Sherrill wrote:
> SoC students:
>
> If you have an application to submit for DragonFly/Summer of Code, please
> do so by 17:00 Pacific time on the 31st - that's tomorrow, at least for
> me.

The deadline for student proposals has been extended to April 7th; all
other dates move forward one week to acommodate.

This is a good time to update existing applications or submit new ones. 
Talk to your (potential) mentors if you are curious.






From nthery at gmail.com  Mon Mar 31 11:29:49 2008
From: nthery at gmail.com (Nicolas Thery)
Date: Mon, 31 Mar 2008 11:29:49 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
Message-ID: <64fc43b0803311126na7d0b27obaa9d35bac6d32ee@mail.gmail.com>

Hello,

Now that the release is over, I'll try to get rid of zones and migrate
allocations to objcache.

Here is a 1st patch that migrate struct proc.  I'll commit it in a
couple of days if nobody objects.

I'm also implementing a way to monitor objcache statistics.  So far,
I've hacked sth similar to
sysctl vm.zone: stats are returned in one giant string, one line per
cache.  That's simple but ugly and hard to read because there are
quite a few stats per cache.

So I'm thinking about implementing a small tool, ocstat, that extracts
stats from sysctl the way ps(1) does (thru libkvm iirc) and formats it
in various ways.  What do you think?

Cheers,
Nicolas

Index: src2/sys/kern/kern_exit.c
===================================================================
--- src2.orig/sys/kern/kern_exit.c	2008-03-31 08:05:59.139796000 +0200
+++ src2/sys/kern/kern_exit.c	2008-03-31 10:31:39.000000000 +0200
@@ -834,7 +834,7 @@ loop:
 			}

 			vm_waitproc(p);
-			zfree(proc_zone, p);
+			objcache_put(proc_cache, p);
 			nprocs--;
 			return (0);
 		}
Index: src2/sys/kern/kern_proc.c
===================================================================
--- src2.orig/sys/kern/kern_proc.c	2008-03-31 08:05:59.139918000 +0200
+++ src2/sys/kern/kern_proc.c	2008-03-31 10:31:39.000000000 +0200
@@ -84,7 +84,7 @@ u_long pgrphash;
 struct proclist allproc;
 struct proclist zombproc;
 struct spinlock allproc_spin;
-vm_zone_t proc_zone;
+struct objcache* proc_cache;
 vm_zone_t lwp_zone;
 vm_zone_t thread_zone;

@@ -131,7 +131,7 @@ procinit(void)
 	spin_init(&allproc_spin);
 	pidhashtbl = hashinit(maxproc / 4, M_PROC, &pidhash);
 	pgrphashtbl = hashinit(maxproc / 4, M_PROC, &pgrphash);
-	proc_zone = zinit("PROC", sizeof (struct proc), 0, 0, 5);
+	proc_cache = objcache_create_simple(M_PROC, sizeof(struct proc));
 	lwp_zone = zinit("LWP", sizeof (struct lwp), 0, 0, 5);
 	thread_zone = zinit("THREAD", sizeof (struct thread), 0, 0, 5);
 	uihashinit();
Index: src2/sys/sys/proc.h
===================================================================
--- src2.orig/sys/sys/proc.h	2008-03-31 08:05:59.140325000 +0200
+++ src2/sys/sys/proc.h	2008-03-31 10:31:39.000000000 +0200
@@ -473,7 +473,7 @@ struct proc *zpfind (pid_t);	/* Find zom
 struct vm_zone;
 struct globaldata;
 struct lwp_params;
-extern struct vm_zone *proc_zone;
+extern struct objcache *proc_cache;
 extern struct vm_zone *lwp_zone;

 int	enterpgrp (struct proc *p, pid_t pgid, int mksess);
Index: src2/sys/kern/kern_fork.c
===================================================================
--- src2.orig/sys/kern/kern_fork.c	2008-03-31 08:05:59.140042000 +0200
+++ src2/sys/kern/kern_fork.c	2008-03-31 10:31:39.000000000 +0200
@@ -332,7 +332,7 @@ fork1(struct lwp *lp1, int flags, struct
 	}

 	/* Allocate new proc. */
-	p2 = zalloc(proc_zone);
+	p2 = objcache_get(proc_cache, M_WAITOK);
 	bzero(p2, sizeof(*p2));

 	/*




From hsu at dragonflybsd.org  Mon Mar 31 11:44:34 2008
From: hsu at dragonflybsd.org (Jeffrey Hsu)
Date: Mon, 31 Mar 2008 11:44:34 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <64fc43b0803311126na7d0b27obaa9d35bac6d32ee@mail.gmail.com>
Message-ID: <200803311841.m2VIfQAI007579@nlpi001.prodigy.net>

The object cache is not a general-purpose memory allocator.  It's a cache of
pre-initialized objects.  Are the significant portions of the proc structure
that can be restored to initialized state on object puts?  If not, it's best
to just use a general-purpose memory allocator.

								Jeffrey




From corecode at fs.ei.tum.de  Mon Mar 31 12:07:02 2008
From: corecode at fs.ei.tum.de (Simon 'corecode' Schubert)
Date: Mon, 31 Mar 2008 12:07:02 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <200803311841.m2VIfQAI007579@nlpi001.prodigy.net>
Message-ID: <47F1357B.1070302@fs.ei.tum.de>

Jeffrey Hsu wrote:
> The object cache is not a general-purpose memory allocator.  It's a cache of
> pre-initialized objects.  Are the significant portions of the proc structure
> that can be restored to initialized state on object puts?  If not, it's best
> to just use a general-purpose memory allocator.

Why?  What's the loss if we use the object cache to allocate struct procs?

cheers
  simon

Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00006.pgp
Type: application/octet-stream
Size: 252 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080331/a4a24314/attachment-0014.obj>

From nthery at gmail.com  Mon Mar 31 12:17:03 2008
From: nthery at gmail.com (Nicolas Thery)
Date: Mon, 31 Mar 2008 12:17:03 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <nthery@gmail.com>
Message-ID: <64fc43b0803311214u7da6bbb8xaf971de1a80e7258@mail.gmail.com>

2008/3/31, Jeffrey Hsu <hsu at dragonflybsd.org>:
> The object cache is not a general-purpose memory allocator.  It's a cache of
>  pre-initialized objects.  Are the significant portions of the proc structure
>  that can be restored to initialized state on object puts?  If not, it's best
>  to just use a general-purpose memory allocator.

Well, I haven't checked this yet.  I planned to do this in a second
step after getting rid of zones.

I thought that even without  the pre-initialization part, objcache has
the advantage
of pre-allocating set of objects (as zones) and is additionally
mp-safe (contrary to zones and, granted, as malloc()).   The latter
may be interesting as we talk of improving MP support.

Cheers,
Nicolas




From dillon at apollo.backplane.com  Mon Mar 31 12:23:40 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Mon, 31 Mar 2008 12:23:40 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <200803311841.m2VIfQAI007579@nlpi001.prodigy.net>
Message-ID: <200803311921.m2VJLITB027669@apollo.backplane.com>

    I both agree and disagree with Jeff.  I think the only *disadvantage*
    to using objcache for struct proc is that objcache must cache a minimum
    number of free structures to be efficient so the overall kernel memory
    use would be a bit greater verses uses kmalloc().  But I agree with Jeff
    in that objcache's biggest advantage is that you can keep structural state
    intact and struct proc might not be a good candidate (yet).

    What I suggest is that you convert struct proc from zone to kmalloc
    first, and then look into a possible objcache adaptation.  kmalloc
    is not slow.. it's a very fast allocator.  Objcache is probably a tad
    faster but not by much.  Where objcache really wins is in not having
    to completey reinitialize the allocated structures.

    Over the years I've removed (I think) all the dependancies on requiring
    the proc structure to be in stable memory so I believe it can be moved to
    kmalloc/objcache now without any major pain.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From corecode at fs.ei.tum.de  Mon Mar 31 12:37:40 2008
From: corecode at fs.ei.tum.de (Simon 'corecode' Schubert)
Date: Mon, 31 Mar 2008 12:37:40 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: SoC student applications due by 5PM PDT tomorrow
In-Reply-To: <1942.192.168.0.242.1206930479.squirrel@www.shiningsilence.com>
Message-ID: <47F13CDA.6010703@fs.ei.tum.de>

Justin C. Sherrill wrote:
> On Sun, March 30, 2008 10:27 pm, Justin C. Sherrill wrote:
>> SoC students:
>>
>> If you have an application to submit for DragonFly/Summer of Code, please
>> do so by 17:00 Pacific time on the 31st - that's tomorrow, at least for
>> me.
> The deadline for student proposals has been extended to April 7th; all
> other dates move forward one week to acommodate.

This is very good.

Some more ideas for eager students (we want to keep the ratio, right?):

Enhance the FreeBSD/DragonFly sound infrastructure to support surround
sound/multichannel output.

Update sound drivers to support S/PDIF output.

Make the sound infrastructure OSSv4 compatible (there was a SoC at
FreeBSD last year or so)


of course only if it doesn't exist already :)

cheers
  simon


Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00007.pgp
Type: application/octet-stream
Size: 252 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080331/6da61cff/attachment-0014.obj>

From corecode at fs.ei.tum.de  Mon Mar 31 12:41:30 2008
From: corecode at fs.ei.tum.de (Simon 'corecode' Schubert)
Date: Mon, 31 Mar 2008 12:41:30 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <200803311841.m2VIfQAI007579@nlpi001.prodigy.net>
Message-ID: <47F13DE4.10205@fs.ei.tum.de>

Matthew Dillon wrote:
>     What I suggest is that you convert struct proc from zone to kmalloc
>     first, and then look into a possible objcache adaptation.  kmalloc
>     is not slow.. it's a very fast allocator.  Objcache is probably a tad
>     faster but not by much.  Where objcache really wins is in not having
>     to completey reinitialize the allocated structures.

Could we please not move to kmalloc, but instead try to move all fast
path allocations to objcache?  I don't like the idea of allocating
everything with kmalloc.  Caching struct procs is not a bad thing itself.

cheers
  simon


Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00008.pgp
Type: application/octet-stream
Size: 252 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080331/ac328c08/attachment-0014.obj>

From hsu at FreeBSD.org  Mon Mar 31 12:59:05 2008
From: hsu at FreeBSD.org (Jeffrey Hsu)
Date: Mon, 31 Mar 2008 12:59:05 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <47F1357B.1070302@fs.ei.tum.de>
Message-ID: <200803311920.m2VJK5Ln018015@nlpi015.prodigy.net>

The object cache sits on top of a general-purpose memory allocator such
as kmalloc or zalloc and provides pre-initialized object caching functionality.
If you're not going to use the object caching functionality, you can just
call the underlying memory allocator directly.

							Jeffrey




From dillon at apollo.backplane.com  Mon Mar 31 16:17:19 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Mon, 31 Mar 2008 16:17:19 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <200803311841.m2VIfQAI007579@nlpi001.prodigy.net>
Message-ID: <200803312311.m2VNBumd029866@apollo.backplane.com>

:Could we please not move to kmalloc, but instead try to move all fast
:path allocations to objcache?  I don't like the idea of allocating
:everything with kmalloc.  Caching struct procs is not a bad thing itself.=
:
:
:cheers
:  simon

    I will state for the record that I'm fine with either objcache or
    kmalloc.  I agree with Jeff that using objcache for struct proc
    probably isn't necessary but I also agree that it would not hurt either,
    and if the intent is to optimize the initialization of the proc
    structure in the future then moving to objcache now would save us
    from having to do it later.

    So whichever method Nicolas wants to use is fine with me.

						-Matt




From hsu at dragonflybsd.org  Mon Mar 31 19:22:47 2008
From: hsu at dragonflybsd.org (Jeffrey Hsu)
Date: Mon, 31 Mar 2008 19:22:47 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <64fc43b0803311214u7da6bbb8xaf971de1a80e7258@mail.gmail.com>
Message-ID: <200804010218.m312IVUq003624@nlpi043.prodigy.net>

  >> Are there significant portions of the proc structure
  >> that can be restored to initialized state on object puts?

  > I planned to do this in a second step after getting rid of zones.

I'll all in favor of making more use of caching pre-initialized objects, so
if this is your objective, then please go ahead.  It's just that I'd convert
over to the object cache in one step.

  > I thought that even without  the pre-initialization part, objcache has
  > the advantage of pre-allocating set of objects (as zones) and is additionally
  > mp-safe (contrary to zones and, granted, as malloc()).

Well, the zone allocator is MP-safe.  It's not hard to lock up the places that
manipulate the linked-list of free items. Look for uses of the zlock field.

								Jeffrey




From tgen at netphreax.net  Sat Mar  1 12:57:53 2008
From: tgen at netphreax.net (Thomas E. Spanjaard)
Date: Sat, 1 Mar 2008 12:57:53 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: [Fwd: Project Support Open Source: $50 donation to support you      project]
In-Reply-To: <2468.192.168.0.242.1204346451.squirrel@www.shiningsilence.com>
Message-ID: <47C9C1B7.50203@netphreax.net>

Justin C. Sherrill wrote:
The "donation" happens after you place an "acknowledgement" on an open
source project's web page.  I'm putting those words in scare quotes
because I think it's a "payment" for an "advertisement".  The supplied
link has nothing to do with DragonFly, to say the least.

<a href="http://www.2insure4less.com /" title="We support FOSS software
projects.">Online Insurance Quotes</a>
To think our souls are only worth $50...
--
        Thomas E. Spanjaard
        tgen at netphreax.net
Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00000.pgp
Type: application/octet-stream
Size: 186 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080301/0d61e240/attachment-0015.obj>

From c.turner at 199technologies.org  Sat Mar  1 17:52:31 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Sat, 1 Mar 2008 17:52:31 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Misc. ACPI / suspend
Message-ID: <47CA073B.6020106@199technologies.org>

Wondering if anyone more well versed in the ACPI implementation could
comment on the applicability of:
http://lkml.org/lkml/2007/4/6/69

w/r/t the current state of the art in Dfly

(or BSD's in general)

Cheers!

- Chris




From elekktretterr at exemail.com.au  Sun Mar  2 00:41:25 2008
From: elekktretterr at exemail.com.au (Petr Janda)
Date: Sun, 2 Mar 2008 00:41:25 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: CARP question
Message-ID: <200803021934.21669.elekktretterr@exemail.com.au>

So Ive setup CARP on 2 DF-based mailservers. Installation went fine. Box 1 has 
adskew of 0 therefore it is the MASTER. Box 2 has adskew of 254, therefore is 
BACKUP.  If i down the carp0 interface on Box 1, then Box 2 carp interface 
gets promoted to MASTER. Then I up the carp interface on Box 1, logically Box 
2 should become BACKUP again as Box 1 becomes MASTER due to adskew set to 0.

However it doesnt happen. When carp0 interface on Box 1 is upped it becomes a 
BACKUP, not a MASTER even though according to adskew it should be MASTER.

What is the desired behaviour?

Cheers
Petr




From qhwt+dfly at les.ath.cx  Sun Mar  2 02:50:14 2008
From: qhwt+dfly at les.ath.cx (YONETANI Tomokazu)
Date: Sun, 2 Mar 2008 02:50:14 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: panic: assertion: hammer_btree_cmp(cursor->left_bound,	&cursor->node->ondisk->elms[0].leaf.base) <= 0 in btree_split_leaf
In-Reply-To: <200802232204.m1NM4cxd046264@apollo.backplane.com>
Message-ID: <20080302104554.GA22813@les.ath.cx>

Hi.
While trying to find a procedure to reliably reproduce the panic
I reported last time, I caught a different panic (uploaded at
 ~y0netan1/crash/9/ on my leaf account).  I wrote the following shell
script (make sure to edit variables DISKS and MOUNTPT before using this
script or it may trash your system):
  #!/bin/sh -ex
  DISKS="/dev/ad0s1f"
  MOUNTPT=/mnt/HAMMER

  cd /
  newfs_hammer -L TEST $DISKS
  for i in `seq 1 100`; do
	  mount_hammer $DISKS $MOUNTPT
	  /bin/rm -rf $MOUNTPT/??
	  (set +x; for x in `seq 1 10000`; do echo -n > $MOUNTPT/$x; done)
	  umount $MOUNTPT
  done

And the panic is triggered by rm command.
I'll try to see if it's possible to reproduce the last one without
unmounting then mounting the HAMMER fs.

Cheers.




From dillon at apollo.backplane.com  Sun Mar  2 13:25:33 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Sun, 2 Mar 2008 13:25:33 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: panic: assertion: hammer_btree_cmp(cursor->left_bound,	&cursor->node->ondisk->elms[0].leaf.base) <= 0 in btree_split_leaf
In-Reply-To: <200802232204.m1NM4cxd046264@apollo.backplane.com>
Message-ID: <200803022119.m22LJRCY037076@apollo.backplane.com>


:Hi.
:While trying to find a procedure to reliably reproduce the panic
:I reported last time, I caught a different panic (uploaded at
: ~y0netan1/crash/9/ on my leaf account).  I wrote the following shell
:script (make sure to edit variables DISKS and MOUNTPT before using this
:script or it may trash your system):

(from the core)

panic: assertion: node->lock.refs == 0 && node->ondisk == NULL in hammer_flush_buffer_nodes

    Yah, I've seen this failure.  Add a sync or two before the umount and
    tell me if it still occurs.  It's either a node reference leak somewhere
    or it is a race between bufdaemon and umount.  The assertions are really
    strict there precisely to catch those sorts of cases.

    Also note that the code to deal with a full HAMMMER filesystem has not
    been written yet (The failure you are reporting is unrelated to a full
    HAMMER filesystem, though, just mentioning it).

						-Matt





From dillon at apollo.backplane.com  Sun Mar  2 13:29:03 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Sun, 2 Mar 2008 13:29:03 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Misc. ACPI / suspend
In-Reply-To: <47CA073B.6020106@199technologies.org>
Message-ID: <200803022126.m22LQbfI037188@apollo.backplane.com>


:Wondering if anyone more well versed in the ACPI implementation could
:comment on the applicability of:
:
:http://lkml.org/lkml/2007/4/6/69
:
:w/r/t the current state of the art in Dfly
:
:(or BSD's in general)
:
:Cheers!
:
:- Chris

    I really have no idea re: this.  Suspension in general is not well
    supported by any of the BSDs.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From dillon at apollo.backplane.com  Sun Mar  2 13:34:05 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Sun, 2 Mar 2008 13:34:05 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: [Fwd: Project Support Open Source: $50 donation to support you      project]
In-Reply-To: <2468.192.168.0.242.1204346451.squirrel@www.shiningsilence.com>
Message-ID: <200803022131.m22LVOe9037250@apollo.backplane.com>

:..
:source project's web page.  I'm putting those words in scare quotes
:because I think it's a "payment" for an "advertisement".  The supplied
:link has nothing to do with DragonFly, to say the least.
:
:I don't think this is a good idea, obviously, and replied to that effect. 
:However, I wanted to put this on a DragonFly list, in part to show this
:strange thing, and in part because I'm not comfortable making
:administrative decisions on behalf of the Project without being open as
:possible about it.

    It doesn't really cry out to me either.

						-Matt





From wbh at conducive.org  Sun Mar  2 20:36:32 2008
From: wbh at conducive.org (Bill Hacker)
Date: Mon, 03 Mar 2008 04:36:32 +0000
Subject: Misc. ACPI / suspend
In-Reply-To: <47CA073B.6020106@199technologies.org>
Message-ID: <47cb8050$0$855$415eb37d@crater_reader.dragonflybsd.org>

Matthew Dillon wrote:
:Wondering if anyone more well versed in the ACPI implementation could
:comment on the applicability of:
:
:http://lkml.org/lkml/2007/4/6/69
:
:w/r/t the current state of the art in Dfly
:
:(or BSD's in general)
:
:Cheers!
:
:- Chris
    I really have no idea re: this.  Suspension in general is not well
    supported by any of the BSDs.
					-Matt
					Matthew Dillon 
					<dillon at backplane.com>


. . and there seems to be a bit of a 'Catch 22' there in any case.

If the BIOS can alter 'stuff' out of site of the OS it is parking, what 
does the existence of such a 'feature' do to a(ny) security model?

Seems to at least beg creating the option of setting a flag to 
specifically *prevent* suspend-to-disk/hibernation (and/or force a 
reboot on wake-up).

Just because one is paranoid....  etc

Bill





From matthias at dragonflybsd.org  Tue Mar  4 02:30:52 2008
From: matthias at dragonflybsd.org (Matthias Schmidt)
Date: Tue, 4 Mar 2008 02:30:52 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
Message-ID: <20080304102335.GI9833@staatsfeind.org>

Hi,

Google just announced its Summer of Code for 2008:

	http://code.google.com/soc/2008/

I think this would be a great opportunity for DragonFly to participate
as a mentoring organisation.  We could attract new developers and could
get code/work done.  Looking at the SoC results of the other BSDs most
of their projects were a success.  Of course, not all, but a reasonable
percentage.  See [1] and [2].

It is some extra work for us, but IMO the benefits outweigh the extra
work.  And yes, I would volunteer as a mentor.  What do others
(developers) think?  Any more volunteers? :)

Some project ideas that come into my mind.  More ideas are listed in the
wiki:  http://wiki.dragonflybsd.org/index.cgi/ProjectsPage

 * Fix all remaining bugs in dma(8) and implement all missing features
 * Add a driver for newer Intel Wireless cards (I think sephe@ would
   love that :)
 * Bring our ACPI stuff in shape.  Maybe suspend2disk ...

 * [Add your own thoughts here]

Cheers,

	Matthias

PS: I don't want to create a bikeshed here whether you like the SoC or
not :)

[1] http://code.google.com/soc/2007/freebsd/about.html
[2] http://code.google.com/soc/2007/netbsd/about.html




From corecode at fs.ei.tum.de  Tue Mar  4 04:46:14 2008
From: corecode at fs.ei.tum.de (Simon 'corecode' Schubert)
Date: Tue, 4 Mar 2008 04:46:14 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47CD4386.1000704@fs.ei.tum.de>

Matthias Schmidt wrote:
>  * [Add your own thoughts here]

MP lock removal for network stack

and for the system  (first profile, find hot spots, fix hot spots, repeat)

cheers
  simon




From c.turner at 199technologies.org  Tue Mar  4 06:02:20 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Tue, 4 Mar 2008 06:02:20 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47CD551E.1040604@199technologies.org>

Matthias Schmidt wrote:
Some project ideas that come into my mind.  More ideas are listed in the
wiki:  http://wiki.dragonflybsd.org/index.cgi/ProjectsPage
+1 acpi
+1 interrupt routing
+1 SMP / giant removal
+1 pf synchup with openbsd
though there are several others on the page that are good..

need to dig up my wiki login and place appropriately..

also: thinking the ZFS port should be removed from the page - makes 
sense to everyone else? (e.g. fragments effort w/r/t hammer)





From tgen at netphreax.net  Tue Mar  4 06:54:31 2008
From: tgen at netphreax.net (Thomas E. Spanjaard)
Date: Tue, 4 Mar 2008 06:54:31 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47CD615F.8010209@netphreax.net>

Matthias Schmidt wrote:
Google just announced its Summer of Code for 2008:

 * [Add your own thoughts here]
x86-64 port :).
--
        Thomas E. Spanjaard
        tgen at netphreax.net
Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00001.pgp
Type: application/octet-stream
Size: 186 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080304/0d921000/attachment-0015.obj>

From rdivacky at FreeBSD.org  Tue Mar  4 07:07:03 2008
From: rdivacky at FreeBSD.org (Roman Divacky)
Date: Tue, 4 Mar 2008 07:07:03 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <20080304150255.GA8831@freebsd.org>

On Tue, Mar 04, 2008 at 02:49:03PM +0000, Thomas E. Spanjaard wrote:
> Matthias Schmidt wrote:
> >Google just announced its Summer of Code for 2008:
> >
> > * [Add your own thoughts here]
> 
> x86-64 port :).

all those ideas are great and needed etc. but keep in
mind that the projects should be doable by students
who might see dfly for the very first time.

don't overestimate whats possible and select projects
that look realistic

Roman Divacky (former SoC student)




From justin at shiningsilence.com  Tue Mar  4 08:32:56 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Tue, 4 Mar 2008 08:32:56 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <60322.65.106.147.226.1204648095.squirrel@www.shiningsilence.com>

On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
> Hi,
>
> Google just announced its Summer of Code for 2008:
>
> 	http://code.google.com/soc/2008/
>
> I think this would be a great opportunity for DragonFly to participate
> as a mentoring organisation.  We could attract new developers and could
> get code/work done.  Looking at the SoC results of the other BSDs most
> of their projects were a success.  Of course, not all, but a reasonable
> percentage.  See [1] and [2].

We've applied in previous years - Jeff Hsu did one year, and I put
together the application last year.  The hardest thing to find was
students (and they are the thing that helps SoC applications a lot, I
think).

Any student volunteers?  We have mentors.





From rluciani at gmail.com  Tue Mar  4 09:38:29 2008
From: rluciani at gmail.com (Robert Luciani)
Date: Tue, 04 Mar 2008 18:38:29 +0100
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47cd8915$0$854$415eb37d@crater_reader.dragonflybsd.org>

Justin C. Sherrill wrote:
> On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
>> Hi,
>>
>> Google just announced its Summer of Code for 2008:
>>
>> 	http://code.google.com/soc/2008/
>>
>> I think this would be a great opportunity for DragonFly to participate
>> as a mentoring organisation.  We could attract new developers and could
>> get code/work done.  Looking at the SoC results of the other BSDs most
>> of their projects were a success.  Of course, not all, but a reasonable
>> percentage.  See [1] and [2].
> 
> We've applied in previous years - Jeff Hsu did one year, and I put
> together the application last year.  The hardest thing to find was
> students (and they are the thing that helps SoC applications a lot, I
> think).
> 
> Any student volunteers?  We have mentors.
> 

bingo

-- 
Robert Luciani
Chalmers University of Technology, SWE
Department of Computer Science and Engineering
http://www.rluciani.com/public.key




From sdavtaker at gmail.com  Tue Mar  4 09:31:08 2008
From: sdavtaker at gmail.com (=?UTF-8?Q?Sd=C3=A4vtaker?=)
Date: Tue, 4 Mar 2008 09:31:08 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <c37d69f60803040926k206218a3kb8496d0cd18148bd@mail.gmail.com>

If you mentor, i will apply for coder :-)
Still in last year of university. :-)
Sdav

On Tue, Mar 4, 2008 at 1:28 PM, Justin C. Sherrill
<justin at shiningsilence.com> wrote:
> On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
>  > Hi,
>  >
>  > Google just announced its Summer of Code for 2008:
>  >
>  >       http://code.google.com/soc/2008/
>  >
>  > I think this would be a great opportunity for DragonFly to participate
>  > as a mentoring organisation.  We could attract new developers and could
>  > get code/work done.  Looking at the SoC results of the other BSDs most
>  > of their projects were a success.  Of course, not all, but a reasonable
>  > percentage.  See [1] and [2].
>
>  We've applied in previous years - Jeff Hsu did one year, and I put
>  together the application last year.  The hardest thing to find was
>  students (and they are the thing that helps SoC applications a lot, I
>  think).
>
>  Any student volunteers?  We have mentors.
>
>



-- 
Sd?vtaker prays to Rikku goddess for a good treasure.



From rluciani at gmail.com  Tue Mar  4 09:44:02 2008
From: rluciani at gmail.com (Robert Luciani)
Date: Tue, 04 Mar 2008 18:44:02 +0100
Subject: google soc "DragonFly"
Message-ID: <47cd8a63$0$855$415eb37d@crater_reader.dragonflybsd.org>

On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
> > Hi,
> >
> > Google just announced its Summer of Code for 2008:
> >
> > 	http://code.google.com/soc/2008/
> >
> > I think this would be a great opportunity for DragonFly to participate
> > as a mentoring organisation.  We could attract new developers and could
> > get code/work done.  Looking at the SoC results of the other BSDs most
> > of their projects were a success.  Of course, not all, but a reasonable
> > percentage.  See [1] and [2].

We've applied in previous years - Jeff Hsu did one year, and I put
together the application last year.  The hardest thing to find was
students (and they are the thing that helps SoC applications a lot, I
think).

Any student volunteers?  We have mentors.


-- 
Robert Luciani
Chalmers University of Technology, SWE
Department of Computer Science and Engineering
http://www.rluciani.com/public.key




From rluciani at gmail.com  Tue Mar  4 10:04:14 2008
From: rluciani at gmail.com (Robert Luciani)
Date: Tue, 04 Mar 2008 19:04:14 +0100
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47cd8f1f$0$856$415eb37d@crater_reader.dragonflybsd.org>

Robert Luciani wrote:
> Justin C. Sherrill wrote:
>> On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
>>> Hi,
>>>
>>> Google just announced its Summer of Code for 2008:
>>>
>>> 	http://code.google.com/soc/2008/
>>>
>>> I think this would be a great opportunity for DragonFly to participate
>>> as a mentoring organisation.  We could attract new developers and could
>>> get code/work done.  Looking at the SoC results of the other BSDs most
>>> of their projects were a success.  Of course, not all, but a reasonable
>>> percentage.  See [1] and [2].
>> We've applied in previous years - Jeff Hsu did one year, and I put
>> together the application last year.  The hardest thing to find was
>> students (and they are the thing that helps SoC applications a lot, I
>> think).
>>
>> Any student volunteers?  We have mentors.
>>
> 
> bingo
> 
My girlfriend Danwei noted that she would also like partake in the SoC.
She's studying IT here at Chalmers and will join the mailing list shortly.
-- 
Robert Luciani
Chalmers University of Technology, SWE
Department of Computer Science and Engineering
http://www.rluciani.com/public.key




From dillon at apollo.backplane.com  Tue Mar  4 13:08:30 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Tue, 4 Mar 2008 13:08:30 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Going to have to roll 1.12.1
Message-ID: <200803042104.m24L43g1065278@apollo.backplane.com>

    Due to a critical bug in sendmail that can cause it to seg-fault I will
    be rolling 1.12.1 as soon as I get verification that the current
    fix deals with it.

						-Matt





From sdavtaker at gmail.com  Tue Mar  4 17:40:43 2008
From: sdavtaker at gmail.com (=?UTF-8?B?U2TDpHZ0YWtlcg==?=)
Date: Tue, 4 Mar 2008 17:40:43 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: [Fwd: Project Support Open Source: $50 donation to support you  project]
In-Reply-To: <2468.192.168.0.242.1204346451.squirrel@www.shiningsilence.com>
Message-ID: <47CDF8D1.9070100@gmail.com>

50 bucks?
Come on...
You can get a meal a lot more expensive than that just going to a free 
HP conference about linux and you only have to rent your soul 3-5 hours ;-)
Sdav

Matthew Dillon escribi?:
:..
:source project's web page.  I'm putting those words in scare quotes
:because I think it's a "payment" for an "advertisement".  The supplied
:link has nothing to do with DragonFly, to say the least.
:
:I don't think this is a good idea, obviously, and replied to that effect. 
:However, I wanted to put this on a DragonFly list, in part to show this
:strange thing, and in part because I'm not comfortable making
:administrative decisions on behalf of the Project without being open as
:possible about it.

    It doesn't really cry out to me either.

						-Matt

  






From sdavtaker at gmail.com  Tue Mar  4 17:56:35 2008
From: sdavtaker at gmail.com (=?UTF-8?B?U2TDpHZ0YWtlcg==?=)
Date: Tue, 4 Mar 2008 17:56:35 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47CDFCCE.1010106@gmail.com>

A cute idea for for GSOC would be to finish the installer.
We were talking about this in my local BUG, we trying to find out how to 
help on that from here.
There is a few missing features in the CD.

   * FDISK, you need to create the slides from another OS before
     install DFBSD, i think port FDisk from FBSD or any *BSD will solve it.
   * Add to the make release a way to add some custom applications to
     the released liveCD (suppose you want to add nmap or ssh or
     something just to use as test disk in some enviroment).
   * Make the installer a little more customizable, and maybe w/ a GUI
     (I like a lot the console approach, but GUI installer will be a
     popularity move, DFBSD w/X makes a Desktop machine work, actually
     im using it that way and really like it).
I think those projects can be done in a SOC by students (like me) with a 
little guide.
Im a lot more interested in things network related and kernel, but i 
dont mind to work on those things, they need to be done some day.
What u think?
Sdav

Robert Luciani escribi?:
Robert Luciani wrote:
  
Justin C. Sherrill wrote:
    
On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
      
Hi,

Google just announced its Summer of Code for 2008:

	http://code.google.com/soc/2008/

I think this would be a great opportunity for DragonFly to participate
as a mentoring organisation.  We could attract new developers and could
get code/work done.  Looking at the SoC results of the other BSDs most
of their projects were a success.  Of course, not all, but a reasonable
percentage.  See [1] and [2].
        
We've applied in previous years - Jeff Hsu did one year, and I put
together the application last year.  The hardest thing to find was
students (and they are the thing that helps SoC applications a lot, I
think).
Any student volunteers?  We have mentors.

      
bingo

    
My girlfriend Danwei noted that she would also like partake in the SoC.
She's studying IT here at Chalmers and will join the mailing list shortly.
  






From c.turner at 199technologies.org  Tue Mar  4 18:30:53 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Tue, 4 Mar 2008 18:30:53 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47CE04C9.1010902@199technologies.org>

Justin C. Sherrill wrote:
together the application last year.  The hardest thing to find was
students (and they are the thing that helps SoC applications a lot, I
think).
umm.. if google wants to send me back to school, I'll sign up - hows 
that for a fair trade :?






From wbh at conducive.org  Tue Mar  4 23:52:13 2008
From: wbh at conducive.org (Bill Hacker)
Date: Wed, 05 Mar 2008 07:52:13 +0000
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47ce512e$0$855$415eb37d@crater_reader.dragonflybsd.org>

Sd?vtaker wrote:
A cute idea for for GSOC would be to finish the installer.
We were talking about this in my local BUG, we trying to find out how to 
help on that from here.
There is a few missing features in the CD.

   * FDISK, you need to create the slides from another OS before
     install DFBSD, i think port FDisk from FBSD or any *BSD will solve it.
I'd rather see that 'reversed' - i.e. - build a more capable fdisk in 
DFLY with hope that it might be seen worth importing into Free/Net/Open, 
or *at least* be able to do a more flexible job than those now do.

And disklabels as well. Hand in glove.

Here's why:

- At the moment, working with Free, Open, DFLY, and OpenSolaris on the 
same HDD requires a bit of acrobatics.

- There seems to now be greater divergence between/among the *BSD's as 
to being able to read each other's disklabels, mount and use each 
other's 'flavor' of FFS/UFS (not to mention Apple's implementation of 
UFS) than there is among the vast multitude of Linux ext2/3 denizens.

Even to the point where use of a *Linux* fs is the more universal way 
for being able to share mounts among the *BSD's. Think detached drives. 
And no - FAT is not all that practical for several reasons.

- DFLY currently has the most fine-grain ability to create slices and 
partitions. But the others cannot all (any?) read those.

'progress' w/r any of the *BSD's direction as to changes, improvements 
(or not) in their once-common-ancestry fs & disklabels need not be 
sacrificed.

I'm not holding out wish or hope for all players agreeing to return to 
'one sacred way'. Nor 'one new universal fs'. Neither is gonna happen.

But a 'legacy compatible' or least-common-denominator mode would do fine 
- most especially for portable / SAN devices.

So - how about a 'flexible' DFLY fdisk to go along with a 'flexible' 
disklabel that could adapt to whatever it found / was told to create?

JM2CW - but that *might* be a good place to get a cross-*BSD team together.

*snip* (other good stuff)

Bill Hacker




From matthias at dragonflybsd.org  Wed Mar  5 01:02:43 2008
From: matthias at dragonflybsd.org (Matthias Schmidt)
Date: Wed, 5 Mar 2008 01:02:43 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <20080305085747.GJ9833@staatsfeind.org>

Hi,

* Justin C. Sherrill wrote:
> 
> We've applied in previous years - Jeff Hsu did one year, and I put
> together the application last year.  The hardest thing to find was
> students (and they are the thing that helps SoC applications a lot, I
> think).

This is good to know, so we could coordinate that if we have enough
mentors and projects?!?  I put together a small text in the wiki:

http://wiki.dragonflybsd.org/index.cgi/GoogleSoC2008

Feel free to add project or missing stuff.  I'm sure I missed a lot of
things :)

> Any student volunteers?  We have mentors.

According to the discussion we could have some students, who would be a
mentor (besides me)?

Regards

	Matthias





From sdavtaker at gmail.com  Wed Mar  5 06:28:37 2008
From: sdavtaker at gmail.com (=?UTF-8?Q?Sd=C3=A4vtaker?=)
Date: Wed, 5 Mar 2008 06:28:37 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <c37d69f60803050624kd86d3d0w3b44a02d0e5a5391@mail.gmail.com>

<quote>
Write a driver (from scratch) for Intel 3945 wireless device
Mentor: Sepherosa Ziehau
</quote>

Yes yes yes, i want to :-)
Someone else planning to mentor in drivers coding?
Sdav

On Wed, Mar 5, 2008 at 5:57 AM, Matthias Schmidt
<matthias at dragonflybsd.org> wrote:
> Hi,
>
>
>  * Justin C. Sherrill wrote:
>  >
>  > We've applied in previous years - Jeff Hsu did one year, and I put
>  > together the application last year.  The hardest thing to find was
>  > students (and they are the thing that helps SoC applications a lot, I
>  > think).
>
>  This is good to know, so we could coordinate that if we have enough
>  mentors and projects?!?  I put together a small text in the wiki:
>
>  http://wiki.dragonflybsd.org/index.cgi/GoogleSoC2008
>
>  Feel free to add project or missing stuff.  I'm sure I missed a lot of
>  things :)
>
>
>  > Any student volunteers?  We have mentors.
>
>  According to the discussion we could have some students, who would be a
>  mentor (besides me)?
>
>  Regards
>
>         Matthias
>
>



-- 
Sd?vtaker prays to Rikku goddess for a good treasure.



From rluciani at gmail.com  Wed Mar  5 10:56:42 2008
From: rluciani at gmail.com (Robert Luciani)
Date: Wed, 05 Mar 2008 19:56:42 +0100
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47ceecea$0$847$415eb37d@crater_reader.dragonflybsd.org>

Sd?vtaker wrote:
> <quote>
> Write a driver (from scratch) for Intel 3945 wireless device
> Mentor: Sepherosa Ziehau
> </quote>
> 
> Yes yes yes, i want to :-)
> Someone else planning to mentor in drivers coding?
> Sdav
> 
> On Wed, Mar 5, 2008 at 5:57 AM, Matthias Schmidt
> <matthias at dragonflybsd.org> wrote:
>> Hi,
>>
>>
>>  * Justin C. Sherrill wrote:
>>  >
>>  > We've applied in previous years - Jeff Hsu did one year, and I put
>>  > together the application last year.  The hardest thing to find was
>>  > students (and they are the thing that helps SoC applications a lot, I
>>  > think).
>>
>>  This is good to know, so we could coordinate that if we have enough
>>  mentors and projects?!?  I put together a small text in the wiki:
>>
>>  http://wiki.dragonflybsd.org/index.cgi/GoogleSoC2008
>>
>>  Feel free to add project or missing stuff.  I'm sure I missed a lot of
>>  things :)
>>
>>
>>  > Any student volunteers?  We have mentors.
>>
>>  According to the discussion we could have some students, who would be a
>>  mentor (besides me)?
>>
>>  Regards
>>
>>         Matthias
>>
>>
> 
> 
>

IF someone starts to write a 3945 Intel driver,
please keep the newer 4965 in mind too.

-- 
Robert Luciani
Chalmers University of Technology, SWE
Department of Computer Science and Engineering
http://www.rluciani.com/public.key




From joerg at britannica.bec.de  Wed Mar  5 12:01:05 2008
From: joerg at britannica.bec.de (Joerg Sonnenberger)
Date: Wed, 5 Mar 2008 12:01:05 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <20080305195711.GA9981@britannica.bec.de>

On Wed, Mar 05, 2008 at 07:56:42PM +0100, Robert Luciani wrote:
> IF someone starts to write a 3945 Intel driver,
> please keep the newer 4965 in mind too.

NetBSD's wpi works quite well. The hardware is quite different from
4945.

Joerg




From sepherosa at gmail.com  Wed Mar  5 17:48:50 2008
From: sepherosa at gmail.com (Sepherosa Ziehau)
Date: Wed, 5 Mar 2008 17:48:50 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <ea7b9c170803051744u22b09484ofc994f034f11df3b@mail.gmail.com>

On Thu, Mar 6, 2008 at 2:56 AM, Robert Luciani <rluciani at gmail.com> wrote:
>  IF someone starts to write a 3945 Intel driver,

"IF" you know that trying to fix any wired bugs in certain drivers
(e.g. ipw, ral) will require you to read through all of the vendor's
linux code (yes, even including register values and position), i.e.
there is not much difference between writing one from scratch and
porting+fixing_bugs, then you probably will not put "IF" at the start
of your sentence.
If what I said sounded too harsh to you, then I was sorry.

>  please keep the newer 4965 in mind too.

Will do, once generic 11n support is brought in from freebsd.

Best Regards,
sephe

-- 
Live Free or Die




From saw at online.de  Thu Mar  6 05:34:14 2008
From: saw at online.de (Sascha Wildner)
Date: Thu, 06 Mar 2008 14:34:14 +0100
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
Message-ID: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>

Hi all,

this is probably as good a moment as any to come out of the forest with 
this. The patch at

http://leaf.dragonflybsd.org/~swildner/nrelease_gui.diff

adds some code to nrelease/ to build a LiveCD with xorg and so on 
(currently, only the xorg metapackages and fluxbox are added). In order 
to build one, you need a local dir with the pkgsrc binary packages (see 
below).

The following commands should then do the trick:

cd /usr/src
make buildworld
make buildkernel
cd nrelease
patch -p 0 </path/to/the/patch
make PKGSRC_PKG_PATH=/path/to/packages/dir/All realquick gui
The resulting ISO will be in /usr/release/dfly-gui.iso then. It will not 
boot into xorg automatically (although this is easily possible), so you 
need to login as root and do startx.

As of now, this all is kind of basic, more a proof of concept than 
anything else. As our release framework installs packages via chroot, 
the current setup just copies _all_ packages to the chroot before 
installing (kind of a hack).

That said, I'm now primarily interested in opinions/ideas/... about the 
direction this should take. Which packages would we like to see on the 
CD? Should it be a generic setup with the "most common things" 
installed, so a system can be quickly setup by the installer (which will 
cpdup /usr/pkg). Or should it be a more specialized set of tools? Or 
even as many packages as possible (Live DVD?). Etc., etc.

Before continuing on it, I'm really interested in people's input so 
don't hold anything back, please. :)

Sascha

--
http://yoyodyne.ath.cx



From rluciani at gmail.com  Thu Mar  6 06:42:03 2008
From: rluciani at gmail.com (Robert Luciani)
Date: Thu, 06 Mar 2008 15:42:03 +0100
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <47d002bc$0$847$415eb37d@crater_reader.dragonflybsd.org>

Sascha Wildner wrote:
> Hi all,
> 
> this is probably as good a moment as any to come out of the forest with
> this. The patch at
> 
> http://leaf.dragonflybsd.org/~swildner/nrelease_gui.diff
> 
> adds some code to nrelease/ to build a LiveCD with xorg and so on
> (currently, only the xorg metapackages and fluxbox are added). In order
> to build one, you need a local dir with the pkgsrc binary packages (see
> below).
> 
> The following commands should then do the trick:
> 
> cd /usr/src
> make buildworld
> make buildkernel
> cd nrelease
> patch -p 0 </path/to/the/patch
> make PKGSRC_PKG_PATH=/path/to/packages/dir/All realquick gui
> 
> The resulting ISO will be in /usr/release/dfly-gui.iso then. It will not
> boot into xorg automatically (although this is easily possible), so you
> need to login as root and do startx.
> 
> As of now, this all is kind of basic, more a proof of concept than
> anything else. As our release framework installs packages via chroot,
> the current setup just copies _all_ packages to the chroot before
> installing (kind of a hack).
> 
> That said, I'm now primarily interested in opinions/ideas/... about the
> direction this should take. Which packages would we like to see on the
> CD? Should it be a generic setup with the "most common things"
> installed, so a system can be quickly setup by the installer (which will
> cpdup /usr/pkg). Or should it be a more specialized set of tools? Or
> even as many packages as possible (Live DVD?). Etc., etc.
> 
> Before continuing on it, I'm really interested in people's input so
> don't hold anything back, please. :)
> 
> Sascha
> 

I think the main point of such a live-cd would be to test
dragonfly-specific features such as vkernels and more. Mplayer and
OpenOffic work the same on all platforms, so they might not be super
important, while irssi, firefox, networking tools, vim, a few more
shells/terminals might make it easier to for people to quickly gauge if
they can reproduce their current productivity and also what is new.

And if the point of a livecd is to test that kind of stuff, then it
would be nice for it to have a kernel that supports as much as possible
like ALTQ, and drivers.

Also if it has lots and lots of programs (thinking multimedia, java,
etc..) it might be hard to keep the future x64 and x86 live-cds on par.
Gentoo had this problem many years ago and it was very bothersome.

-- 
Robert Luciani
Chalmers University of Technology, SWE
Department of Computer Science and Engineering
http://www.rluciani.com/public.key




From matthias at dragonflybsd.org  Thu Mar  6 07:12:43 2008
From: matthias at dragonflybsd.org (Matthias Schmidt)
Date: Thu, 6 Mar 2008 07:12:43 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <20080306150757.GN9833@staatsfeind.org>

* Sascha Wildner wrote:
> Hi all,
> 
> this is probably as good a moment as any to come out of the forest with this. 
> The patch at
> 
> http://leaf.dragonflybsd.org/~swildner/nrelease_gui.diff
> 
> adds some code to nrelease/ to build a LiveCD with xorg and so on (currently, 
> only the xorg metapackages and fluxbox are added). In order to build one, you 
> need a local dir with the pkgsrc binary packages (see below).

Great work Sascha.

I agree with Robert on most of his stated points.
It would be nice to see some DragonFly specific features on the CD
(although I'm not sure if that will work for all features).  A little
environment where most Unix users feel at home (fluxbox, xfce, firefox,
thunderbird, gvim) should be enough.

Big applications like OO.org, java etc won't work because they are not
available as pkgsrc packages neither is it possible to compile them on
DragonFly.  At least to my knowledge.

Regards

	Matthias




From dillon at apollo.backplane.com  Thu Mar  6 09:31:52 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Thu, 6 Mar 2008 09:31:52 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <200803061728.m26HSR3O091809@apollo.backplane.com>


:Hi all,
:
:this is probably as good a moment as any to come out of the forest with 
:this. The patch at
:
:http://leaf.dragonflybsd.org/~swildner/nrelease_gui.diff
:
:adds some code to nrelease/ to build a LiveCD with xorg and so on 
:(currently, only the xorg metapackages and fluxbox are added). In order 
:to build one, you need a local dir with the pkgsrc binary packages (see 
:below).
:
:The following commands should then do the trick:

    It looks reasonable, though the package copy has to be tightened
    up a bit I think.

:...
:installed, so a system can be quickly setup by the installer (which will 
:cpdup /usr/pkg). Or should it be a more specialized set of tools? Or 
:even as many packages as possible (Live DVD?). Etc., etc.
:
:Before continuing on it, I'm really interested in people's input so 
:don't hold anything back, please. :)
:
:Sascha

    I think this is an excellent time to work up a DVD build and to
    add various 'flavor' extras.  So, e.g.:

	make installer gui gui_extras release dvd

    (All 'dvd' would do is generate a dvd compatible image for burning to
    dvd instead of cd).  I did a quick perusal of what I have on my
    workstation:

    * X
    * Firefox
    * Linux emulation
    * Open Office (linux version)
    * fvwm2
    * xpdf
    * freetype2

    I'd also suggest some image editing tools like gimp, and maybe the KDE
    gui suite.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From justin at shiningsilence.com  Thu Mar  6 09:42:44 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Thu, 6 Mar 2008 09:42:44 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <55427.65.106.147.226.1204825168.squirrel@www.shiningsilence.com>

On Thu, March 6, 2008 8:34 am, Sascha Wildner wrote:

> That said, I'm now primarily interested in opinions/ideas/... about the
> direction this should take. Which packages would we like to see on the
> CD? Should it be a generic setup with the "most common things"
> installed, so a system can be quickly setup by the installer (which will
> cpdup /usr/pkg). Or should it be a more specialized set of tools? Or
> even as many packages as possible (Live DVD?). Etc., etc.

What Robert said is good - whatever's needed to enable DragonFly-specific
features.  Along with that would be some sort of documentation (a README? 
A HTML file on whatever desktop we provide) that points people at the
different DragonFly tools, so they know what to try and how to try it.

There's going to be some percentage of people who try DragonFly who don't
know about vkernels, for instance, but there's our chance to educate them.
 I'm probably volunteering myself, aren't I?





From sdavtaker at gmail.com  Thu Mar  6 09:50:09 2008
From: sdavtaker at gmail.com (=?UTF-8?Q?Sd=C3=A4vtaker?=)
Date: Thu, 6 Mar 2008 09:50:09 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <c37d69f60803060947t110750c0sd6b542ea505d188d@mail.gmail.com>

Cool Sascha :-)
I just posted about this 1 or 2 days ago in the SOC project ideas thread.
Want to mentor this one? ;-)
Damian

On Thu, Mar 6, 2008 at 2:28 PM, Matthew Dillon
<dillon at apollo.backplane.com> wrote:
>
>  :Hi all,
>
> :
>  :this is probably as good a moment as any to come out of the forest with
>  :this. The patch at
>  :
>  :http://leaf.dragonflybsd.org/~swildner/nrelease_gui.diff
>  :
>  :adds some code to nrelease/ to build a LiveCD with xorg and so on
>  :(currently, only the xorg metapackages and fluxbox are added). In order
>  :to build one, you need a local dir with the pkgsrc binary packages (see
>  :below).
>  :
>  :The following commands should then do the trick:
>
>     It looks reasonable, though the package copy has to be tightened
>     up a bit I think.
>
>  :...
>  :installed, so a system can be quickly setup by the installer (which will
>
> :cpdup /usr/pkg). Or should it be a more specialized set of tools? Or
>  :even as many packages as possible (Live DVD?). Etc., etc.
>  :
>  :Before continuing on it, I'm really interested in people's input so
>  :don't hold anything back, please. :)
>  :
>  :Sascha
>
>     I think this is an excellent time to work up a DVD build and to
>     add various 'flavor' extras.  So, e.g.:
>
>         make installer gui gui_extras release dvd
>
>     (All 'dvd' would do is generate a dvd compatible image for burning to
>     dvd instead of cd).  I did a quick perusal of what I have on my
>     workstation:
>
>     * X
>     * Firefox
>     * Linux emulation
>     * Open Office (linux version)
>     * fvwm2
>     * xpdf
>     * freetype2
>
>     I'd also suggest some image editing tools like gimp, and maybe the KDE
>     gui suite.
>
>                                         -Matt
>                                         Matthew Dillon
>                                         <dillon at backplane.com>
>



-- 
Sd?vtaker prays to Rikku goddess for a good treasure.



From saw at online.de  Thu Mar  6 11:54:01 2008
From: saw at online.de (Sascha Wildner)
Date: Thu, 06 Mar 2008 20:54:01 +0100
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <47d04ba2$0$856$415eb37d@crater_reader.dragonflybsd.org>

Matthew Dillon wrote:
    It looks reasonable, though the package copy has to be tightened
    up a bit I think.
It looks as if it would work with mount_null'ing the chroot's 
/tmp/packages. I'll have a better patch ready tomorrow.

Sascha

--
http://yoyodyne.ath.cx



From c.turner at 199technologies.org  Thu Mar  6 19:11:44 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Thu, 6 Mar 2008 19:11:44 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Misc. ACPI / suspend
In-Reply-To: <47CA073B.6020106@199technologies.org>
Message-ID: <47D0B079.3060905@199technologies.org>

Chris Turner wrote:
Wondering if anyone more well versed in the ACPI implementation could
comment on the applicability of:
http://lkml.org/lkml/2007/4/6/69

Doing a little digging, it seems like

. /platform/pc32/i386/i686_mem.c

*might* have the necessary infrastructure to remap the MTRR's per the 
thread referenced,

but:

. /platform/pc32/acpica5/acpi_wakeup.c

doesn't seem to be using this infrastructure..

I'm no where near reaching an understanding of this yet,
but I'm wondering 3 things:
1) does anyone have ACPI (instead of APM)
   sleep / suspend / wakeup working on Dfly ?
2) If so, what machines are being used ?
3) Same question for other BSDs - my understanding is NetBSD is most
   'advanced' w/r/t power managment - but I'm not 100% on this ...
would looove to have a sleeping / resuming / scaling laptop running some 
BSD flavor.. am willing to work towards that end, esp. w/r/t Dfly -
trying to chart a course to figguring this out.

Thanks all,

- Chris




From c.turner at 199technologies.org  Thu Mar  6 19:12:33 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Thu, 6 Mar 2008 19:12:33 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: PCI Bios / Interrupt remapping / etc
Message-ID: <47D0B211.6000002@199technologies.org>

Doing a bit of digging here for my long-standing CBB+SIO interupt and 
buffer problem -

one machine I've tested against was an OpenBSD machine, which didn't
always work to handle the cardbus sio card on a PCI cardbus adapter
-

tuning up some of the device flags in:

http://www.openbsd.org/cgi-bin/man.cgi?query=pcibios&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=html

seems to have alleviated the problem for that os..

I'm just only starting to get up to speed on how DF handles these types 
of things (namely initial PIC / interrupt layout at boot time device 
enumeration), but am wondering if anyone familiar with this area of the 
code has any comments / advice w/r/t the capabilities of the DF bios 
drivers
and the various quirks / fixup mentioned in the link above..

looking to possibly investigate fixing up some of these issues over time.

Thanks

- Chris







From pavalos at theshell.com  Fri Mar  7 01:14:55 2008
From: pavalos at theshell.com (Peter Avalos)
Date: Fri, 7 Mar 2008 01:14:55 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: cam locking
Message-ID: <20080307091024.GC1652@ylem.theshell.com>

So I've been working on locking up cam using lockmgr locks, and here's
what I have so far:

http://www.theshell.com/~pavalos/wip/cam-lock.patch

Most of the work is obtained from FreeBSD.  I've only been running this
on my SCSI machine for a day, but because the patch is so large, I wanted
to make it available for people to review if they have some spare time.

Thanks,
Peter
Attachment:
pgp00002.pgp
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00002.pgp
Type: application/octet-stream
Size: 197 bytes
Desc: "Description: PGP signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080307/9a17ecd8/attachment-0015.obj>

From jspringe at uos.de  Fri Mar  7 03:25:17 2008
From: jspringe at uos.de (Jost Tobias Springenberg)
Date: Fri, 7 Mar 2008 12:25:17 +0100
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <20080307122517.72c9e2b1.jspringe@uos.de>

On Tue, 4 Mar 2008 11:28:15 -0500 (EST)
"Justin C. Sherrill" <justin at shiningsilence.com> wrote:

> On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
> > Hi,
> >
> > Google just announced its Summer of Code for 2008:
> >
> > 	http://code.google.com/soc/2008/
> >
> > I think this would be a great opportunity for DragonFly to participate
> > as a mentoring organisation.  We could attract new developers and could
> > get code/work done.  Looking at the SoC results of the other BSDs most
> > of their projects were a success.  Of course, not all, but a reasonable
> > percentage.  See [1] and [2].
> 
> We've applied in previous years - Jeff Hsu did one year, and I put
> together the application last year.  The hardest thing to find was
> students (and they are the thing that helps SoC applications a lot, I
> think).
> 
> Any student volunteers?  We have mentors.
> 

I read this mailing list for quite a while now and thought about contributing stuff
to DFfly several times, so yes why not take this opportunity if it's there.

-- 
Jost Tobias Springenberg <jspringe at uos.de>




From tgen at netphreax.net  Fri Mar  7 05:17:27 2008
From: tgen at netphreax.net (Thomas E. Spanjaard)
Date: Fri, 7 Mar 2008 05:17:27 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: PCI Bios / Interrupt remapping / etc
In-Reply-To: <47D0B211.6000002@199technologies.org>
Message-ID: <47D13FB4.5080306@netphreax.net>

Chris Turner wrote:
Doing a bit of digging here for my long-standing CBB+SIO interupt and 
buffer problem -

one machine I've tested against was an OpenBSD machine, which didn't
always work to handle the cardbus sio card on a PCI cardbus adapter
-

tuning up some of the device flags in:

http://www.openbsd.org/cgi-bin/man.cgi?query=pcibios&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=html 

seems to have alleviated the problem for that os..

I'm just only starting to get up to speed on how DF handles these types 
of things (namely initial PIC / interrupt layout at boot time device 
enumeration), but am wondering if anyone familiar with this area of the 
code has any comments / advice w/r/t the capabilities of the DF bios 
drivers
and the various quirks / fixup mentioned in the link above..

looking to possibly investigate fixing up some of these issues over time.
Our code that handles issues like this (in cases where you're not using 
APICs, just PICs and PIRs) lives in bus/pci/i386/. Not that running 
without APIC support is all that common on modern machines anymore...
--
        Thomas E. Spanjaard
        tgen at netphreax.net
Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00003.pgp
Type: application/octet-stream
Size: 186 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080307/61366b5c/attachment-0015.obj>

From tgen at netphreax.net  Fri Mar  7 05:16:51 2008
From: tgen at netphreax.net (Thomas E. Spanjaard)
Date: Fri, 7 Mar 2008 05:16:51 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Misc. ACPI / suspend
In-Reply-To: <47CA073B.6020106@199technologies.org>
Message-ID: <47D13F07.9080308@netphreax.net>

Chris Turner wrote:
1) does anyone have ACPI (instead of APM)
   sleep / suspend / wakeup working on Dfly ?
2) If so, what machines are being used ?
3) Same question for other BSDs - my understanding is NetBSD is most
   'advanced' w/r/t power managment - but I'm not 100% on this ...
would looove to have a sleeping / resuming / scaling laptop running some 
BSD flavor.. am willing to work towards that end, esp. w/r/t Dfly -
trying to chart a course to figguring this out.
I have ACPI S3 suspend working like a charm on my IBM ThinkPad R40 
(Pentium M "Banias" 1.3GHz, speedstepping works just fine), running 
NetBSD 3.99.21.
--
        Thomas E. Spanjaard
        tgen at netphreax.net
Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00004.pgp
Type: application/octet-stream
Size: 186 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080307/de3e5104/attachment-0015.obj>

From civilizd at gmail.com  Fri Mar  7 09:06:41 2008
From: civilizd at gmail.com (Vita "CiV" Cizek)
Date: Fri, 7 Mar 2008 09:06:41 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <98d564710803070853q1c73d795m6e6c5cc5049fa099@mail.gmail.com>

>  Any student volunteers?  We have mentors.
>
I am interested too, especially in some kernel-related work.




From justin at shiningsilence.com  Sat Mar  8 12:07:51 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Sat, 8 Mar 2008 12:07:51 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google SoC 2008 - mentors mentors mentors
Message-ID: <51558.192.168.0.252.1205006403.squirrel@www.shiningsilence.com>

If you are willing to mentor for the Google 2008 Summer of Code, please
speak up.  Right now we have: (from our wiki page)

Matthias
Sephe
TGEN
corecode

Part of the application process includes naming people as mentors (student
applications come later), so I want to get as complete a list as possible.

The application is due on the 12th, so if you want to mentor, now's the
time to say so.

Google's SoC FAQ is here: http://code.google.com/soc/2008/faqs.html

Our wiki page is here: http://wiki.dragonflybsd.org/index.cgi/GoogleSoC2008

- much credit to Matthias and others for getting that set up.





From saw at online.de  Sat Mar  8 14:26:07 2008
From: saw at online.de (Sascha Wildner)
Date: Sat, 08 Mar 2008 23:26:07 +0100
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <47d31245$0$848$415eb37d@crater_reader.dragonflybsd.org>

Sascha Wildner wrote:
Hi all,

this is probably as good a moment as any to come out of the forest with 
this. The patch at

http://leaf.dragonflybsd.org/~swildner/nrelease_gui.diff
Ok, I have committed the stuff as an example.

I'm not sure if my free time permits to work on a full-blown live CD 
with X11 and other good things (I already feel my interest wandering off 
in other directions) so if anyone wants to pick up the ball, go ahead. :)

Sascha

--
http://yoyodyne.ath.cx



From qhwt+dfly at les.ath.cx  Tue Mar 11 22:21:31 2008
From: qhwt+dfly at les.ath.cx (YONETANI Tomokazu)
Date: Tue, 11 Mar 2008 22:21:31 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Misc. ACPI / suspend
In-Reply-To: <47CA073B.6020106@199technologies.org>
Message-ID: <20080312051219.GA56091@les.ath.cx>

On Thu, Mar 06, 2008 at 10:03:21PM -0500, Chris Turner wrote:
> 1) does anyone have ACPI (instead of APM)
>    sleep / suspend / wakeup working on Dfly ?
> 2) If so, what machines are being used ?

Dynabook SS3500 (http://www.tlt.co.jp/pc/catalog/ss/02110735/index_j.htm).
It's old and can get very hot(thus frequently turns on the cooling fan)
even when it's running Windows.  I haven't turned it on for about several
months though.

Cheers.




From c.turner at 199technologies.org  Wed Mar 12 04:37:22 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Wed, 12 Mar 2008 04:37:22 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Misc. ACPI / suspend
In-Reply-To: <47CA073B.6020106@199technologies.org>
Message-ID: <47D7BEE3.6010907@199technologies.org>

YONETANI Tomokazu wrote:
On Thu, Mar 06, 2008 at 10:03:21PM -0500, Chris Turner wrote:
1) does anyone have ACPI (instead of APM)
   sleep / suspend / wakeup working on Dfly ?
Cheers.
ditto..

Suppose this should go to docs@ - in any case..

Thinking about setting up a wiki page on the issue so we
can discuss / track what 'good' hardware / drivers / implementations / 
etc are 'out there' - anyone have any suggestions on where this should
go?

http://wiki.dragonflybsd.org/index.cgi/acpi-overview.html

Remains from the handbook conversion - but I'm hesitant to 'over wikify'
this ..



From c.turner at 199technologies.org  Wed Mar 12 15:36:52 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Wed, 12 Mar 2008 15:36:52 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: devel/cscope
Message-ID: <47D85A08.8040103@199technologies.org>

why oh why did I take so long to try this out !!!

just sharing my eureka moment with the list..

- Chris




From dudu at dudu.ro  Wed Mar 12 15:50:14 2008
From: dudu at dudu.ro (Vlad GALU)
Date: Wed, 12 Mar 2008 15:50:14 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: devel/cscope
In-Reply-To: <47D85A08.8040103@199technologies.org>
Message-ID: <ad79ad6b0803121547r2bf67ffep9e40badaac6490f8@mail.gmail.com>

On 3/13/08, Chris Turner <c.turner at 199technologies.org> wrote:
> why oh why did I take so long to try this out !!!
>
>  just sharing my eureka moment with the list..


    Works nice with vim, too!

>
>
>  - Chris
>


-- 
Mahnahmahnah!




From justin at shiningsilence.com  Sun Mar 16 21:06:13 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Sun, 16 Mar 2008 21:06:13 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: binary packages for 1.12 coming in
Message-ID: <1372.192.168.0.252.1205726088.squirrel@www.shiningsilence.com>

The binary build for 1.12 is taking quite a while.  I've started copying
in newly built packages to
pkgbox.dragonflybsd.org/packages/DragonFly-1.12/i386/ - this should be
getting copied out to mirrors over the next while.

There are currently 1283 packages built, which leaves a whole lot to go;
I'll copy new packages in as they complete.





From hasso at estpak.ee  Wed Mar 19 04:31:08 2008
From: hasso at estpak.ee (Hasso Tepper)
Date: Wed, 19 Mar 2008 04:31:08 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Some questions regarding ACPI
Message-ID: <200803191322.46366.hasso@estpak.ee>

I'm working on bringing in some laptop (and especially thinkpad) specific 
ACPI code from FreeBSD into DragonFly. I never touched ACPI stuff before 
and haven't followed it much either, so I have some questions.

* FreeBSD uses ACPI_SERIAL_* heavily. What's the locking situation in 
  DragonFly and why?

* As far as I can see, PCI integration is commented out in DragonFly. 
  What's the state of it and why?

* platform/pc32/acpica5/acpi_toshiba.c - why is it there? I don't think 
  that this is something pc32 specific in it and it should work in pc64 
  laptops as well. Any objections to move it into 
  dev/acpica5/acpi_toshiba/ ?

What's the current status of ACPI in general? AFAICS our acpica is quite 
old - what needs to be done to bring in newer one?


-- 
Hasso




From qhwt+dfly at les.ath.cx  Wed Mar 19 09:24:50 2008
From: qhwt+dfly at les.ath.cx (YONETANI Tomokazu)
Date: Wed, 19 Mar 2008 09:24:50 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Some questions regarding ACPI
In-Reply-To: <200803191322.46366.hasso@estpak.ee>
Message-ID: <20080319161703.GA51509@les.ath.cx>

On Wed, Mar 19, 2008 at 01:22:46PM +0200, Hasso Tepper wrote:
> I'm working on bringing in some laptop (and especially thinkpad) specific 
> ACPI code from FreeBSD into DragonFly. I never touched ACPI stuff before 
> and haven't followed it much either, so I have some questions.

So you want to port some of ACPI support drivers, or to do a fresh port
of ACPI driver from FreeBSD?

> * FreeBSD uses ACPI_SERIAL_* heavily. What's the locking situation in 
>   DragonFly and why?

The current ACPI driver in DragonFly is based on that of FreeBSD as of
end of June, 2004, plus some fixes brought in later (and ACPICA part
has been updated twice since then).  That was before they introduced
the MPSAFE changes into ACPI code, and we use critical section
(crit_{enter,exit}) in most places (and lockmgr lock in a few place).

> * As far as I can see, PCI integration is commented out in DragonFly. 
>   What's the state of it and why?

When we replaced the implementation taken from FreeBSD 4.x with that
brought from FreeBSD 5.x, which added the PCI part, many people
experienced problems until they turned off ACPI completely, or add "pci"
to "debug.acpi.disabled" loader variable.  AFAIK the PCI part in the ACPI
driver almost hasn't been adjusted to work with our version of PCI code.

> * platform/pc32/acpica5/acpi_toshiba.c - why is it there? I don't think 
>   that this is something pc32 specific in it and it should work in pc64 
>   laptops as well. Any objections to move it into 
>   dev/acpica5/acpi_toshiba/ ?

In FreeBSD it used to be sitting at i386/acpica/acpi_toshiba.c and was
later moved into acpi_support.  That change hasn't hit our tree (in fact,
we have no acpi support drivers other than that).  It seems that FreeBSD
has them in dev/acpi_support now, and we for some reason have that
directory in our CVS repository (but containing no files in it).

> What's the current status of ACPI in general? AFAICS our acpica is quite 
> old - what needs to be done to bring in newer one?

Actually, it's not very important to keep just ACPICA latest, but
if you bring the ACPI driver from FreeBSD you need to bring ACPICA code
that matches their version, and it IS important.  And it generally requires
you much work to just update ACPICA part anyway because of how they
change things on every release.

Cheers.




From hasso at estpak.ee  Wed Mar 19 12:29:52 2008
From: hasso at estpak.ee (Hasso Tepper)
Date: Wed, 19 Mar 2008 12:29:52 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Some questions regarding ACPI
In-Reply-To: <200803191322.46366.hasso@estpak.ee>
Message-ID: <200803192115.35396.hasso@estpak.ee>

YONETANI Tomokazu wrote:
> On Wed, Mar 19, 2008 at 01:22:46PM +0200, Hasso Tepper wrote:
> > I'm working on bringing in some laptop (and especially thinkpad)
> > specific ACPI code from FreeBSD into DragonFly. I never touched ACPI
> > stuff before and haven't followed it much either, so I have some
> > questions.
>
> So you want to port some of ACPI support drivers, or to do a fresh port
> of ACPI driver from FreeBSD?

I'm only interested in support drivers and the reason is pure practical - 
newer thinkpads handle less and less hotkeys etc in hardware and require 
support form OS. acpi_ibm and acpi_video are examples of such modules 
which would help a lot of these newer thinkpad users.

acpi_ibm is almost ready to commit (renamed to acpi_thinkpad though).

> > * FreeBSD uses ACPI_SERIAL_* heavily. What's the locking situation in
> >   DragonFly and why?
>
> The current ACPI driver in DragonFly is based on that of FreeBSD as of
> end of June, 2004, plus some fixes brought in later (and ACPICA part
> has been updated twice since then).  That was before they introduced
> the MPSAFE changes into ACPI code, and we use critical section
> (crit_{enter,exit}) in most places (and lockmgr lock in a few place).

Mkay. Will look at more closely.

> > * As far as I can see, PCI integration is commented out in DragonFly.
> >   What's the state of it and why?
>
> When we replaced the implementation taken from FreeBSD 4.x with that
> brought from FreeBSD 5.x, which added the PCI part, many people
> experienced problems until they turned off ACPI completely, or add
> "pci" to "debug.acpi.disabled" loader variable.  AFAIK the PCI part in
> the ACPI driver almost hasn't been adjusted to work with our version of
> PCI code.

I'm afraid that it's beyond my skills, but while looking at acpi_video I 
discovered that it's hard to handle correctly without PCI support.

> > * platform/pc32/acpica5/acpi_toshiba.c - why is it there? I don't
> > think that this is something pc32 specific in it and it should work
> > in pc64 laptops as well. Any objections to move it into
> >   dev/acpica5/acpi_toshiba/ ?
>
> In FreeBSD it used to be sitting at i386/acpica/acpi_toshiba.c and was
> later moved into acpi_support.  That change hasn't hit our tree (in
> fact, we have no acpi support drivers other than that).  It seems that
> FreeBSD has them in dev/acpi_support now, and we for some reason have
> that directory in our CVS repository (but containing no files in it).

I don't see it ;). Makes sense though. So, any objections if I move 
acpi_toshiba into sys/dev/acpi_support and add new acpi_thinkpad there as 
well? 

> > What's the current status of ACPI in general? AFAICS our acpica is
> > quite old - what needs to be done to bring in newer one?
>
> Actually, it's not very important to keep just ACPICA latest, but
> if you bring the ACPI driver from FreeBSD you need to bring ACPICA code
> that matches their version, and it IS important.  And it generally
> requires you much work to just update ACPICA part anyway because of how
> they change things on every release.

Someone else has to do it :).

Thanks for info.


-- 
Hasso




From dillon at apollo.backplane.com  Wed Mar 19 14:01:13 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Wed, 19 Mar 2008 14:01:13 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: panic: assertion: hammer_btree_cmp(cursor->left_bound,	&cursor->node->ondisk->elms[0].leaf.base) <= 0 in btree_split_leaf
In-Reply-To: <200802232204.m1NM4cxd046264@apollo.backplane.com>
Message-ID: <200803192054.m2JKsjwn045137@apollo.backplane.com>


:Hi.
:While trying to find a procedure to reliably reproduce the panic
:I reported last time, I caught a different panic (uploaded at
: ~y0netan1/crash/9/ on my leaf account).  I wrote the following shell
:script (make sure to edit variables DISKS and MOUNTPT before using this
:script or it may trash your system):
:  #!/bin/sh -ex
:  DISKS="/dev/ad0s1f"
:  MOUNTPT=/mnt/HAMMER
:
:  cd /
:  newfs_hammer -L TEST $DISKS
:  for i in `seq 1 100`; do
:..
:And the panic is triggered by rm command.
:I'll try to see if it's possible to reproduce the last one without
:unmounting then mounting the HAMMER fs.
:
:Cheers.

    I believe I have fixed this panic.  hammer_make_separator() had a bug
    in it.

    There is still an issue with the node ref count on umount.

    Please continue to life-test the code.  The reblocking code
    (hammer reblock /mnt) should work now, as should the pruning code
    (e.g. hammer prune /mnt everything).

    The filesystem full case is still not handled and will cause bad things
    to happen.  The undo code isn't finished yet either but it is getting
    there (it's writing stuff out but not setting the sequence number and
    not trying to recover-on-mount yet).

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From qhwt+dfly at les.ath.cx  Wed Mar 19 19:45:40 2008
From: qhwt+dfly at les.ath.cx (YONETANI Tomokazu)
Date: Wed, 19 Mar 2008 19:45:40 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Some questions regarding ACPI
In-Reply-To: <200803191322.46366.hasso@estpak.ee>
Message-ID: <20080320023828.GA53648@les.ath.cx>

On Wed, Mar 19, 2008 at 09:15:35PM +0200, Hasso Tepper wrote:
> YONETANI Tomokazu wrote:
> > On Wed, Mar 19, 2008 at 01:22:46PM +0200, Hasso Tepper wrote:
> > > I'm working on bringing in some laptop (and especially thinkpad)
> > > specific ACPI code from FreeBSD into DragonFly. I never touched ACPI
> > > stuff before and haven't followed it much either, so I have some
> > > questions.
> >
> > So you want to port some of ACPI support drivers, or to do a fresh port
> > of ACPI driver from FreeBSD?
> 
> I'm only interested in support drivers and the reason is pure practical - 
> newer thinkpads handle less and less hotkeys etc in hardware and require 
> support form OS. acpi_ibm and acpi_video are examples of such modules 
> which would help a lot of these newer thinkpad users.
> 
> acpi_ibm is almost ready to commit (renamed to acpi_thinkpad though).

Ah, that's a good news!  My only concern is that ISTR someone mentioned
me that his colleague was thinking about porting ACPI driver itself,
so if you're not the person you may want to collaborate with him/her
so as not to waste the effort or time...

			:

> > In FreeBSD it used to be sitting at i386/acpica/acpi_toshiba.c and was
> > later moved into acpi_support.  That change hasn't hit our tree (in
> > fact, we have no acpi support drivers other than that).  It seems that
> > FreeBSD has them in dev/acpi_support now, and we for some reason have
> > that directory in our CVS repository (but containing no files in it).
> 
> I don't see it ;). Makes sense though. So, any objections if I move 
> acpi_toshiba into sys/dev/acpi_support and add new acpi_thinkpad there as 
> well? 

Sorry, I checked the CVS repository and it doesn't exist actually :)
I don't have any objection to moving it there.

Cheers.




From hasso at estpak.ee  Thu Mar 20 00:14:05 2008
From: hasso at estpak.ee (Hasso Tepper)
Date: Thu, 20 Mar 2008 00:14:05 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Some questions regarding ACPI
In-Reply-To: <200803191322.46366.hasso@estpak.ee>
Message-ID: <200803200904.50875.hasso@estpak.ee>

YONETANI Tomokazu wrote:
> On Wed, Mar 19, 2008 at 09:15:35PM +0200, Hasso Tepper wrote:
> > acpi_ibm is almost ready to commit (renamed to acpi_thinkpad though).
>
> Ah, that's a good news!  My only concern is that ISTR someone mentioned
> me that his colleague was thinking about porting ACPI driver itself,
> so if you're not the person you may want to collaborate with him/her
> so as not to waste the effort or time...

Current state in my repo is attached. It should work on 1.12 as well as it 
doesn't depend yet on moving stuff around.

add-acpi-if-m.patch adds some new stuff to the ACPI code to access 
embedded controllers and match ACPI devices by ID. Not sure how, where 
and whether at all these should be documented.

add-acpi-thinkpad.patch is the driver itself. Note that some stuff doesn't 
work yet on newer thinkpads, I plan to work on it later.

There is still some things to do though. I have to decide what to do with 
led(4) part and with locking. There is also one fatal issue - laptop 
locks up hardly (no panic) while unloading module. Any idea regarding 
this is welcome. And of course test results :).


-- 
Hasso
# HG changeset patch
# User Hasso Tepper <hasso at estpak.ee>
# Date 1205919290 -7200
# Branch HEAD
# Node ID 5a6e2705cc95a340abf973ae5df73ef34e070b79
# Parent  cd529e2e7f849034d5d5a0973cb98af50db0e797
imported patch adding-acpi-if-m.patch

diff --git a/sys/conf/files b/sys/conf/files
--- a/sys/conf/files
+++ b/sys/conf/files
@@ -1387,6 +1387,7 @@ emulation/dragonfly12/dfbsd12_stat.c	non
 ${OSACPI_MI_DIR}/acpi_cmbat.c		optional acpi
 ${OSACPI_MI_DIR}/acpi_cpu.c		optional acpi
 ${OSACPI_MI_DIR}/acpi_ec.c		optional acpi
+${OSACPI_MI_DIR}/acpi_if.m		optional acpi
 ${OSACPI_MI_DIR}/acpi_isab.c		optional acpi isa
 ${OSACPI_MI_DIR}/acpi_lid.c		optional acpi
 ${OSACPI_MI_DIR}/acpi_package.c		optional acpi
diff --git a/sys/conf/kmod.mk b/sys/conf/kmod.mk
--- a/sys/conf/kmod.mk
+++ b/sys/conf/kmod.mk
@@ -275,7 +275,7 @@ MFILES?= kern/bus_if.m kern/device_if.m 
     bus/pccard/card_if.m bus/pccard/power_if.m bus/pci/pci_if.m \
     bus/pci/pcib_if.m \
     bus/ppbus/ppbus_if.m bus/smbus/smbus_if.m bus/usb/usb_if.m \
-    dev/disk/nata/ata_if.m \
+    dev/acpica5/acpi_if.m dev/disk/nata/ata_if.m \
     dev/sound/pcm/ac97_if.m dev/sound/pcm/channel_if.m \
     dev/sound/pcm/feeder_if.m dev/sound/pcm/mixer_if.m \
     libiconv/iconv_converter_if.m dev/agp/agp_if.m opencrypto/crypto_if.m
diff --git a/sys/dev/acpica5/Makefile b/sys/dev/acpica5/Makefile
--- a/sys/dev/acpica5/Makefile
+++ b/sys/dev/acpica5/Makefile
@@ -69,12 +69,14 @@ SRCS+=  acpi_package.c
 # SRCS+=	acpi_pci.c acpi_pcib.c acpi_pcib_acpi.c acpi_pcib_pci.c
 # SRCS+=	acpi_pci_link.c
 SRCS+=  acpi_powerres.c acpi_resource.c acpi_thermal.c
-SRCS+=  acpi_timer.c
+SRCS+=  acpi_timer.c acpi_if.c
 SRCS+=  OsdDebug.c
 SRCS+=  OsdHardware.c OsdInterface.c OsdInterrupt.c OsdMemory.c OsdSchedule.c
 SRCS+=  OsdStream.c OsdSynch.c OsdTable.c OsdEnvironment.c
 SRCS+=  opt_acpi.h opt_bus.h opt_ddb.h
-SRCS+=  device_if.h bus_if.h pci_if.h pcib_if.h isa_if.h
+SRCS+=  device_if.h bus_if.h pci_if.h pcib_if.h isa_if.h acpi_if.h
+MFILES = kern/device_if.m kern/bus_if.m bus/pci/pci_if.m bus/pci/pcib_if.m
+MFILES+= bus/isa/isa_if.m dev/acpica5/acpi_if.m
 
 # Debugging support
 DBSRC=	dbcmds.c dbdisply.c dbexec.c dbfileio.c dbhistry.c
diff --git a/sys/dev/acpica5/acpi.c b/sys/dev/acpica5/acpi.c
--- a/sys/dev/acpica5/acpi.c
+++ b/sys/dev/acpica5/acpi.c
@@ -135,6 +135,7 @@ static int	acpi_release_resource(device_
 			int rid, struct resource *r);
 static uint32_t	acpi_isa_get_logicalid(device_t dev);
 static int	acpi_isa_get_compatid(device_t dev, uint32_t *cids, int count);
+static char	*acpi_device_id_probe(device_t bus, device_t dev, char **ids);
 static int	acpi_isa_pnp_probe(device_t bus, device_t child,
 			struct isa_pnp_id *ids);
 static void	acpi_probe_children(device_t bus);
@@ -189,6 +190,9 @@ static device_method_t acpi_methods[] = 
     DEVMETHOD(bus_deactivate_resource,	bus_generic_deactivate_resource),
     DEVMETHOD(bus_setup_intr,		bus_generic_setup_intr),
     DEVMETHOD(bus_teardown_intr,	bus_generic_teardown_intr),
+
+    /* ACPI bus */
+    DEVMETHOD(acpi_id_probe,		acpi_device_id_probe),
 
     /* ISA emulation */
     DEVMETHOD(isa_pnp_probe,		acpi_isa_pnp_probe),
@@ -1121,6 +1125,24 @@ out:
 	AcpiOsFree(buf.Pointer);
     ACPI_UNLOCK;
     return_VALUE (valid);
+}
+
+static char *
+acpi_device_id_probe(device_t bus, device_t dev, char **ids) 
+{
+    ACPI_HANDLE h;
+    int i;
+
+    h = acpi_get_handle(dev);
+    if (ids == NULL || h == NULL || acpi_get_type(dev) != ACPI_TYPE_DEVICE)
+	return (NULL);
+
+    /* Try to match one of the array of IDs with a HID or CID. */
+    for (i = 0; ids[i] != NULL; i++) {
+	if (acpi_MatchHid(h, ids[i]))
+	    return (ids[i]);
+    }
+    return (NULL);
 }
 
 static int
diff --git a/sys/dev/acpica5/acpi_ec.c b/sys/dev/acpica5/acpi_ec.c
--- a/sys/dev/acpica5/acpi_ec.c
+++ b/sys/dev/acpica5/acpi_ec.c
@@ -327,11 +327,19 @@ static ACPI_STATUS	EcWrite(struct acpi_e
 				UINT8 *Data);
 static int		acpi_ec_probe(device_t dev);
 static int		acpi_ec_attach(device_t dev);
+static int		acpi_ec_read_method(device_t dev, u_int addr,
+				ACPI_INTEGER *val, int width);
+static int		acpi_ec_write_method(device_t dev, u_int addr,
+				ACPI_INTEGER val, int width);
 
 static device_method_t acpi_ec_methods[] = {
     /* Device interface */
     DEVMETHOD(device_probe,	acpi_ec_probe),
     DEVMETHOD(device_attach,	acpi_ec_attach),
+
+    /* Embedded controller interface */
+    DEVMETHOD(acpi_ec_read,     acpi_ec_read_method),
+    DEVMETHOD(acpi_ec_write,    acpi_ec_write_method),
 
     {0, 0}
 };
@@ -620,6 +628,33 @@ error:
 			     sc->ec_data_res);
     /* mtx_destroy(&sc->ec_mtx); */
     return (ENXIO);
+}
+
+/* Methods to allow other devices (e.g., smbat) to read/write EC space. */
+static int
+acpi_ec_read_method(device_t dev, u_int addr, ACPI_INTEGER *val, int width)
+{
+    struct acpi_ec_softc *sc;
+    ACPI_STATUS status;
+
+    sc = device_get_softc(dev);
+    status = EcSpaceHandler(ACPI_READ, addr, width * 8, val, sc, NULL);
+    if (ACPI_FAILURE(status))
+        return (ENXIO);
+    return (0);
+}
+
+static int
+acpi_ec_write_method(device_t dev, u_int addr, ACPI_INTEGER val, int width)
+{
+    struct acpi_ec_softc *sc;
+    ACPI_STATUS status;
+
+    sc = device_get_softc(dev);
+    status = EcSpaceHandler(ACPI_WRITE, addr, width * 8, &val, sc, NULL);
+    if (ACPI_FAILURE(status))
+        return (ENXIO);
+    return (0);
 }
 
 static void
diff --git a/sys/dev/acpica5/acpi_if.m b/sys/dev/acpica5/acpi_if.m
new file mode 100644
--- /dev/null
+++ b/sys/dev/acpica5/acpi_if.m
@@ -0,0 +1,92 @@
+#-
+# Copyright (c) 2004 Nate Lawson
+# All rights reserved.
+#
+# Redistribution and use in source and binary forms, with or without
+# modification, are permitted provided that the following conditions
+# are met:
+# 1. Redistributions of source code must retain the above copyright
+#    notice, this list of conditions and the following disclaimer.
+# 2. Redistributions in binary form must reproduce the above copyright
+#    notice, this list of conditions and the following disclaimer in the
+#    documentation and/or other materials provided with the distribution.
+#
+# THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
+# ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+# ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
+# FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+# DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+# OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+# HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+# LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+# OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+# SUCH DAMAGE.
+#
+# $DragonFly$
+#
+
+#include <sys/bus.h>
+#include <sys/types.h>
+#include "acpi.h"
+
+INTERFACE acpi;
+
+#
+# Default implementation for acpi_id_probe().
+#
+CODE {
+	static char *
+	acpi_generic_id_probe(device_t bus, device_t dev, char **ids)
+	{
+		return (NULL);
+	}
+};
+
+#
+# Check a device for a match in a list of ID strings.  The strings can be
+# EISA PNP IDs or ACPI _HID/_CID values.
+#
+# device_t bus:  parent bus for the device
+#
+# device_t dev:  device being considered
+#
+# char **ids:  array of ID strings to consider
+#
+# Returns:  ID string matched or NULL if no match
+#
+METHOD char * id_probe {
+	device_t	bus;
+	device_t	dev;
+	char		**ids;
+} DEFAULT acpi_generic_id_probe;
+
+#
+# Read embedded controller (EC) address space
+#
+# device_t dev:  EC device
+# u_int addr:  Address to read from in EC space
+# ACPI_INTEGER *val:  Location to store read value
+# int width:  Size of area to read in bytes
+#
+METHOD int ec_read {
+	device_t	dev;
+	u_int		addr;
+	ACPI_INTEGER	*val;
+	int		width;
+};
+
+#
+# Write embedded controller (EC) address space
+#
+# device_t dev:  EC device
+# u_int addr:  Address to write to in EC space
+# ACPI_INTEGER val:  Value to write
+# int width:  Size of value to write in bytes
+#
+METHOD int ec_write {
+	device_t	dev;
+	u_int		addr;
+	ACPI_INTEGER	val;
+	int		width;
+};
diff --git a/sys/dev/acpica5/acpivar.h b/sys/dev/acpica5/acpivar.h
--- a/sys/dev/acpica5/acpivar.h
+++ b/sys/dev/acpica5/acpivar.h
@@ -29,6 +29,7 @@
  * $DragonFly: src/sys/dev/acpica5/acpivar.h,v 1.12 2007/10/23 03:04:48 y0netan1 Exp $
  */
 
+#include "acpi_if.h"
 #include "bus_if.h"
 #include <sys/eventhandler.h>
 #include <sys/sysctl.h>
# HG changeset patch
# User Hasso Tepper <hasso at estpak.ee>
# Date 1205995474 -7200
# Branch HEAD
# Node ID c5db8d4a7c6b25a8576a8d42c5029aaf0e23bfb6
# Parent  5a6e2705cc95a340abf973ae5df73ef34e070b79
[mq]: adding-acpi-thinkpad.patch

diff --git a/sys/dev/acpica5/Makefile b/sys/dev/acpica5/Makefile
--- a/sys/dev/acpica5/Makefile
+++ b/sys/dev/acpica5/Makefile
@@ -117,7 +117,7 @@ acpi_wakecode.h: acpi_wakecode.S
 	${MAKE} -f ${SYSDIR}/${OSACPI_MD_DIR}/Makefile \
 		MAKESRCPATH=${SYSDIR}/${OSACPI_MD_DIR}
 
-SUBDIR=	acpi_toshiba
+SUBDIR=	acpi_toshiba acpi_thinkpad
 all: ${PROG} ${SUBDIR}
 
 # *.o file for each patched *.c file is created under the same directory,
diff --git a/sys/dev/acpica5/acpi_thinkpad/Makefile b/sys/dev/acpica5/acpi_thinkpad/Makefile
new file mode 100644
--- /dev/null
+++ b/sys/dev/acpica5/acpi_thinkpad/Makefile
@@ -0,0 +1,9 @@
+# $DragonFly$
+
+SYSDIR?=${.CURDIR}/../../..
+
+KMOD=		acpi_thinkpad
+CFLAGS+=	-I${.OBJDIR}/.. -I${.CURDIR}/..
+SRCS=		acpi_thinkpad.c opt_acpi.h device_if.h bus_if.h
+
+.include <bsd.kmod.mk>
diff --git a/sys/dev/acpica5/acpi_thinkpad/acpi_thinkpad.c b/sys/dev/acpica5/acpi_thinkpad/acpi_thinkpad.c
new file mode 100644
--- /dev/null
+++ b/sys/dev/acpica5/acpi_thinkpad/acpi_thinkpad.c
@@ -0,0 +1,1046 @@
+/*
+ * Copyright (c) 2004 Takanori Watanabe
+ * Copyright (c) 2005 Markus Brueffer <markus at FreeBSD.org>
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *    notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *    notice, this list of conditions and the following disclaimer in the
+ *    documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+ */
+
+/*
+ * Driver for extra ACPI-controlled gadgets found on IBM and Lenovo ThinkPad
+ * laptops. Inspired by the ibm-acpi and tpb projects which implement these
+ * features on Linux.
+ *
+ *   acpi-ibm: <http://ibm-acpi.sourceforge.net/>
+ *        tpb: <http://www.nongnu.org/tpb/>
+ */
+
+#include "opt_acpi.h"
+#include <sys/param.h>
+#include <sys/kernel.h>
+#include <sys/bus.h>
+#include <machine/cpufunc.h>
+#include <sys/module.h>
+/* #include <dev/led/led.h> */
+#include <sys/sensors.h>
+#include <sys/sysctl.h>
+#include <machine/clock.h>
+
+#include "acpi.h"
+#include "acpivar.h"
+#include "acpi_if.h"
+
+#define _COMPONENT	ACPI_OEM
+ACPI_MODULE_NAME("THINKPAD")
+
+/* Internal methods */
+#define ACPI_THINKPAD_METHOD_EVENTS		1
+#define ACPI_THINKPAD_METHOD_EVENTMASK		2
+#define ACPI_THINKPAD_METHOD_HOTKEY		3
+#define ACPI_THINKPAD_METHOD_BRIGHTNESS		4
+#define ACPI_THINKPAD_METHOD_VOLUME		5
+#define ACPI_THINKPAD_METHOD_MUTE		6
+#define ACPI_THINKPAD_METHOD_THINKLIGHT		7
+#define ACPI_THINKPAD_METHOD_BLUETOOTH		8
+#define ACPI_THINKPAD_METHOD_WLAN		9
+#define ACPI_THINKPAD_METHOD_FANSPEED		10
+#define ACPI_THINKPAD_METHOD_FANLEVEL		11
+#define ACPI_THINKPAD_METHOD_FANSTATUS		12
+#define ACPI_THINKPAD_METHOD_THERMAL		13
+
+/* Hotkeys/Buttons */
+#define THINKPAD_RTC_HOTKEY1			0x64
+#define   THINKPAD_RTC_MASK_HOME		(1 << 0)
+#define   THINKPAD_RTC_MASK_SEARCH		(1 << 1)
+#define   THINKPAD_RTC_MASK_MAIL		(1 << 2)
+#define   THINKPAD_RTC_MASK_WLAN		(1 << 5)
+#define THINKPAD_RTC_HOTKEY2			0x65
+#define   THINKPAD_RTC_MASK_THINKPAD		(1 << 3)
+#define   THINKPAD_RTC_MASK_ZOOM		(1 << 5)
+#define   THINKPAD_RTC_MASK_VIDEO		(1 << 6)
+#define   THINKPAD_RTC_MASK_HIBERNATE		(1 << 7)
+#define THINKPAD_RTC_THINKLIGHT			0x66
+#define   THINKPAD_RTC_MASK_THINKLIGHT		(1 << 4)
+#define THINKPAD_RTC_SCREENEXPAND		0x67
+#define   THINKPAD_RTC_MASK_SCREENEXPAND	(1 << 5)
+#define THINKPAD_RTC_BRIGHTNESS			0x6c
+#define   THINKPAD_RTC_MASK_BRIGHTNESS		(1 << 5)
+#define THINKPAD_RTC_VOLUME			0x6e
+#define   THINKPAD_RTC_MASK_VOLUME		(1 << 7)
+
+/* Embedded Controller registers */
+#define THINKPAD_EC_BRIGHTNESS			0x31
+#define   THINKPAD_EC_MASK_BRI			0x7
+#define THINKPAD_EC_VOLUME			0x30
+#define   THINKPAD_EC_MASK_VOL			0xf
+#define   THINKPAD_EC_MASK_MUTE			(1 << 6)
+#define THINKPAD_EC_FANSTATUS			0x2F
+#define   THINKPAD_EC_MASK_FANLEVEL		0x3f
+#define   THINKPAD_EC_MASK_FANDISENGAGED	(1 << 6)
+#define   THINKPAD_EC_MASK_FANSTATUS		(1 << 7)
+#define THINKPAD_EC_FANSPEED			0x84
+
+/* CMOS Commands */
+#define THINKPAD_CMOS_VOLUME_DOWN		0
+#define THINKPAD_CMOS_VOLUME_UP			1
+#define THINKPAD_CMOS_VOLUME_MUTE		2
+#define THINKPAD_CMOS_BRIGHTNESS_UP		4
+#define THINKPAD_CMOS_BRIGHTNESS_DOWN		5
+
+/* ACPI methods */
+#define THINKPAD_NAME_KEYLIGHT			"KBLT"
+#define THINKPAD_NAME_WLAN_BT_GET		"GBDC"
+#define THINKPAD_NAME_WLAN_BT_SET		"SBDC"
+#define   THINKPAD_NAME_MASK_BT			(1 << 1)
+#define   THINKPAD_NAME_MASK_WLAN		(1 << 2)
+#define THINKPAD_NAME_THERMAL_GET		"TMP7"
+#define THINKPAD_NAME_THERMAL_UPDT		"UPDT"
+
+#define THINKPAD_NAME_EVENTS_STATUS_GET		"DHKC"
+#define THINKPAD_NAME_EVENTS_MASK_GET		"DHKN"
+#define THINKPAD_NAME_EVENTS_STATUS_SET		"MHKC"
+#define THINKPAD_NAME_EVENTS_MASK_SET		"MHKM"
+#define THINKPAD_NAME_EVENTS_GET		"MHKP"
+#define THINKPAD_NAME_EVENTS_AVAILMASK		"MHKA"
+
+#define ABS(x) (((x) < 0)? -(x) : (x))
+
+struct acpi_thinkpad_softc {
+	device_t	dev;
+	ACPI_HANDLE	handle;
+
+	/* Embedded controller */
+	device_t	ec_dev;
+	ACPI_HANDLE	ec_handle;
+
+	/* CMOS */
+	ACPI_HANDLE	cmos_handle;
+
+	/* Fan status */
+	ACPI_HANDLE	fan_handle;
+	int		fan_levels;
+
+	/* Keylight commands and states */
+	ACPI_HANDLE	light_handle;
+	int		light_cmd_on;
+	int		light_cmd_off;
+	int		light_val;
+	int		light_get_supported;
+	int		light_set_supported;
+
+	/* led(4) interface */
+	struct cdev	*led_dev;
+	int		led_busy;
+	int		led_state;
+
+	int		wlan_bt_flags;
+	int		thermal_updt_supported;
+
+	unsigned int	events_availmask;
+	unsigned int	events_initialmask;
+	int		events_mask_supported;
+	int		events_enable;
+
+	/* sensors(9) related */
+	struct ksensordev sensordev;
+	struct ksensor sensors[9];	/* XXX: 8 thermal + fan */
+
+	struct sysctl_ctx_list	*sysctl_ctx;
+	struct sysctl_oid	*sysctl_tree;
+};
+
+static struct {
+	char	*name;
+	int	method;
+	char	*description;
+	int	access;
+} acpi_thinkpad_sysctls[] = {
+	{
+		.name		= "events",
+		.method		= ACPI_THINKPAD_METHOD_EVENTS,
+		.description	= "ACPI events enable",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "eventmask",
+		.method		= ACPI_THINKPAD_METHOD_EVENTMASK,
+		.description	= "ACPI eventmask",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "hotkey",
+		.method		= ACPI_THINKPAD_METHOD_HOTKEY,
+		.description	= "Key Status",
+		.access		= CTLTYPE_INT | CTLFLAG_RD
+	},
+	{
+		.name		= "lcd_brightness",
+		.method		= ACPI_THINKPAD_METHOD_BRIGHTNESS,
+		.description	= "LCD Brightness",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "volume",
+		.method		= ACPI_THINKPAD_METHOD_VOLUME,
+		.description	= "Volume",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "mute",
+		.method		= ACPI_THINKPAD_METHOD_MUTE,
+		.description	= "Mute",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "thinklight",
+		.method		= ACPI_THINKPAD_METHOD_THINKLIGHT,
+		.description	= "Thinklight enable",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "bluetooth",
+		.method		= ACPI_THINKPAD_METHOD_BLUETOOTH,
+		.description	= "Bluetooth enable",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "wlan",
+		.method		= ACPI_THINKPAD_METHOD_WLAN,
+		.description	= "WLAN enable",
+		.access		= CTLTYPE_INT | CTLFLAG_RD
+	},
+	{
+		.name		= "fan_level",
+		.method		= ACPI_THINKPAD_METHOD_FANLEVEL,
+		.description	= "Fan level",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "fan",
+		.method		= ACPI_THINKPAD_METHOD_FANSTATUS,
+		.description	= "Fan enable",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+
+	{ NULL, 0, NULL, 0 }
+};
+
+/* ACPI_SERIAL_DECL(thinkpad, "ACPI THINKPAD extras"); */
+static int	acpi_thinkpad_probe(device_t dev);
+static int	acpi_thinkpad_attach(device_t dev);
+static int	acpi_thinkpad_detach(device_t dev);
+
+#if 0 /* not yet */
+static void	thinkpad_led(void *softc, int onoff);
+static void	thinkpad_led_task(struct acpi_thinkpad_softc *sc,
+		int pending __unused);
+#endif
+
+static int	acpi_thinkpad_sysctl(SYSCTL_HANDLER_ARGS);
+static int	acpi_thinkpad_sysctl_init(struct acpi_thinkpad_softc *sc,
+		int method);
+static int	acpi_thinkpad_sysctl_get(struct acpi_thinkpad_softc *sc,
+		int method);
+static int	acpi_thinkpad_sysctl_set(struct acpi_thinkpad_softc *sc,
+		int method, int val);
+
+static int	acpi_thinkpad_eventmask_set(struct acpi_thinkpad_softc *sc,
+		int val);
+static void	acpi_thinkpad_notify(ACPI_HANDLE h, UINT32 notify,
+		void *context);
+static void	acpi_thinkpad_refresh(void *);
+
+static device_method_t acpi_thinkpad_methods[] = {
+	/* Device interface */
+	DEVMETHOD(device_probe, acpi_thinkpad_probe),
+	DEVMETHOD(device_attach, acpi_thinkpad_attach),
+	DEVMETHOD(device_detach, acpi_thinkpad_detach),
+	{0, 0}
+};
+
+static driver_t	acpi_thinkpad_driver = {
+	"acpi_thinkpad",
+	acpi_thinkpad_methods,
+	sizeof(struct acpi_thinkpad_softc),
+};
+
+static devclass_t acpi_thinkpad_devclass;
+
+DRIVER_MODULE(acpi_thinkpad, acpi, acpi_thinkpad_driver,
+    acpi_thinkpad_devclass, 0, 0);
+MODULE_DEPEND(acpi_thinkpad, acpi, 1, 1, 1);
+static char    *thinkpad_ids[] = {"IBM0068", NULL};
+
+#if 0 /* not yet */
+static void
+thinkpad_led(void *softc, int onoff)
+{
+	struct acpi_thinkpad_softc* sc = (struct acpi_thinkpad_softc*) softc;
+
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+
+	if (sc->led_busy)
+		return;
+
+	sc->led_busy = 1;
+	sc->led_state = onoff;
+
+	AcpiOsExecute(OSL_NOTIFY_HANDLER, (void *)thinkpad_led_task, sc);
+}
+
+static void
+thinkpad_led_task(struct acpi_thinkpad_softc *sc, int pending __unused)
+{
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+
+	/* ACPI_SERIAL_BEGIN(thinkpad); */
+	acpi_thinkpad_sysctl_set(sc, ACPI_THINKPAD_METHOD_THINKLIGHT, sc->led_state);
+	/* ACPI_SERIAL_END(thinkpad); */
+
+	sc->led_busy = 0;
+}
+#endif
+
+static int
+acpi_thinkpad_probe(device_t dev)
+{
+	if (acpi_disabled("thinkpad") ||
+	    ACPI_ID_PROBE(device_get_parent(dev), dev, thinkpad_ids) == NULL ||
+	    device_get_unit(dev) != 0) 
+		return (ENXIO);
+
+	device_set_desc(dev, "IBM/Lenovo ThinkPad ACPI Extras");
+	return (0);
+}
+
+static int
+acpi_thinkpad_attach(device_t dev)
+{
+	struct acpi_thinkpad_softc	*sc;
+	struct acpi_softc	*acpi_sc;
+	devclass_t		ec_devclass;
+	int			i;
+
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t) __func__);
+
+	sc = device_get_softc(dev);
+	sc->dev = dev;
+	sc->handle = acpi_get_handle(dev);
+
+	acpi_sc = acpi_device_get_parent_softc(dev);
+
+	/* Look for the first embedded controller */
+        if (!(ec_devclass = devclass_find ("acpi_ec"))) {
+		if (bootverbose)
+			device_printf(dev, "Couldn't find acpi_ec devclass\n");
+		return (EINVAL);
+	}
+        if (!(sc->ec_dev = devclass_get_device(ec_devclass, 0))) {
+		if (bootverbose)
+			device_printf(dev, "Couldn't find acpi_ec device\n");
+		return (EINVAL);
+	}
+	sc->ec_handle = acpi_get_handle(sc->ec_dev);
+
+	/* ACPI_SERIAL_BEGIN(thinkpad); */
+
+#if 0
+	/* Get the sysctl tree */
+	sc->sysctl_ctx = device_get_sysctl_ctx(dev);
+	sc->sysctl_tree = device_get_sysctl_tree(dev);
+#endif
+	sysctl_ctx_init(sc->sysctl_ctx);
+	sc->sysctl_tree = SYSCTL_ADD_NODE(sc->sysctl_ctx,
+	    SYSCTL_CHILDREN(acpi_sc->acpi_sysctl_tree), OID_AUTO,
+	    "thinkpad", CTLFLAG_RD, 0, "");
+
+	/* Look for event mask and hook up the nodes */
+	sc->events_mask_supported = ACPI_SUCCESS(acpi_GetInteger(sc->handle,
+	    THINKPAD_NAME_EVENTS_MASK_GET, &sc->events_initialmask));
+
+	if (sc->events_mask_supported) {
+		SYSCTL_ADD_INT(sc->sysctl_ctx,
+		    SYSCTL_CHILDREN(sc->sysctl_tree), OID_AUTO,
+		    "initialmask", CTLFLAG_RD,
+		    &sc->events_initialmask, 0, "Initial eventmask");
+
+		/* The availmask is the bitmask of supported events */
+		if (ACPI_FAILURE(acpi_GetInteger(sc->handle,
+		    THINKPAD_NAME_EVENTS_AVAILMASK, &sc->events_availmask)))
+			sc->events_availmask = 0xffffffff;
+
+		SYSCTL_ADD_INT(sc->sysctl_ctx,
+		    SYSCTL_CHILDREN(sc->sysctl_tree), OID_AUTO,
+		    "availmask", CTLFLAG_RD,
+		    &sc->events_availmask, 0, "Mask of supported events");
+	}
+
+	/* Hook up proc nodes */
+	for (i = 0; acpi_thinkpad_sysctls[i].name != NULL; i++) {
+		if (!acpi_thinkpad_sysctl_init(sc,
+		    acpi_thinkpad_sysctls[i].method))
+			continue;
+
+		SYSCTL_ADD_PROC(sc->sysctl_ctx,
+		    SYSCTL_CHILDREN(sc->sysctl_tree), OID_AUTO,
+		    acpi_thinkpad_sysctls[i].name,
+		    acpi_thinkpad_sysctls[i].access,
+		    sc, i, acpi_thinkpad_sysctl, "I",
+		    acpi_thinkpad_sysctls[i].description);
+	}
+
+	/* ACPI_SERIAL_END(thinkpad); */
+
+	/* Handle notifies */
+	AcpiInstallNotifyHandler(sc->handle, ACPI_DEVICE_NOTIFY,
+	    acpi_thinkpad_notify, dev);
+
+#if 0
+	/* Hook up light to led(4) */
+	if (sc->light_set_supported)
+		sc->led_dev = led_create_state(thinkpad_led, sc, "thinklight",
+		    sc->light_val);
+#endif
+	/* Attach sensors(9). */
+	if (sensor_task_register(sc, acpi_thinkpad_refresh, 5)) {
+		device_printf(sc->dev, "unable to register update task\n");
+		return 1;
+	}
+
+	strlcpy(sc->sensordev.xname, device_get_nameunit(sc->dev),
+	    sizeof(sc->sensordev.xname));
+
+	/* XXX: Temp sensors */
+	for (i = 0; i < 8; ++i) {
+		sc->sensors[i].type = SENSOR_TEMP;
+		sensor_attach(&sc->sensordev, &sc->sensors[i]);
+	}
+	
+	/* Fan RPM sensor */
+	sc->sensors[8].type = SENSOR_FANRPM;
+	sensor_attach(&sc->sensordev, &sc->sensors[8]);
+
+	sensordev_install(&sc->sensordev);
+
+	return (0);
+}
+
+static int
+acpi_thinkpad_detach(device_t dev)
+{
+	int i;
+
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t) __func__);
+
+	struct acpi_thinkpad_softc *sc = device_get_softc(dev);
+
+	/* Disable events and restore eventmask */
+	/* ACPI_SERIAL_BEGIN(thinkpad); */
+	acpi_thinkpad_sysctl_set(sc, ACPI_THINKPAD_METHOD_EVENTS, 0);
+	acpi_thinkpad_sysctl_set(sc, ACPI_THINKPAD_METHOD_EVENTMASK,
+	    sc->events_initialmask);
+	/* ACPI_SERIAL_END(thinkpad); */
+
+	AcpiRemoveNotifyHandler(sc->handle, ACPI_DEVICE_NOTIFY,
+	    acpi_thinkpad_notify);
+
+	sysctl_ctx_free(sc->sysctl_ctx);
+
+#if 0
+	if (sc->led_dev != NULL)
+		led_destroy(sc->led_dev);
+#endif
+	sensordev_deinstall(&sc->sensordev);
+	for (i = 0; i < 9; i++)
+		sensor_detach(&sc->sensordev, &sc->sensors[i]);
+	sensor_task_unregister(sc);
+
+	return (0);
+}
+
+static int
+acpi_thinkpad_eventmask_set(struct acpi_thinkpad_softc *sc, int val)
+{
+	int i;
+	ACPI_OBJECT		arg[2];
+	ACPI_OBJECT_LIST	args;
+	ACPI_STATUS		status;
+
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+	/* ACPI_SERIAL_ASSERT(thinkpad); */
+
+	args.Count = 2;
+	args.Pointer = arg;
+	arg[0].Type = ACPI_TYPE_INTEGER;
+	arg[1].Type = ACPI_TYPE_INTEGER;
+
+	for (i = 0; i < 32; ++i) {
+		arg[0].Integer.Value = i+1;
+		arg[1].Integer.Value = (((1 << i) & val) != 0);
+		status = AcpiEvaluateObject(sc->handle,
+		    THINKPAD_NAME_EVENTS_MASK_SET, &args, NULL);
+
+		if (ACPI_FAILURE(status))
+			return (status);
+	}
+
+	return (0);
+}
+
+static int
+acpi_thinkpad_sysctl(SYSCTL_HANDLER_ARGS)
+{
+	struct acpi_thinkpad_softc	*sc;
+	int			arg;
+	int			error = 0;
+	int			function;
+	int			method;
+	
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+
+	sc = (struct acpi_thinkpad_softc *)oidp->oid_arg1;
+	function = oidp->oid_arg2;
+	method = acpi_thinkpad_sysctls[function].method;
+
+	/* ACPI_SERIAL_BEGIN(thinkpad); */
+	arg = acpi_thinkpad_sysctl_get(sc, method);
+	error = sysctl_handle_int(oidp, &arg, 0, req);
+
+	/* Sanity check */
+	if (error != 0 || req->newptr == NULL)
+		goto out;
+
+	/* Update */
+	error = acpi_thinkpad_sysctl_set(sc, method, arg);
+
+out:
+	/* ACPI_SERIAL_END(thinkpad); */
+	return (error);
+}
+
+static int
+acpi_thinkpad_sysctl_get(struct acpi_thinkpad_softc *sc, int method)
+{
+	ACPI_INTEGER	val_ec;
+	int 		val = 0, key;
+
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+	/* ACPI_SERIAL_ASSERT(thinkpad); */
+
+	switch (method) {
+	case ACPI_THINKPAD_METHOD_EVENTS:
+		acpi_GetInteger(sc->handle, THINKPAD_NAME_EVENTS_STATUS_GET,
+		    &val);
+		break;
+
+	case ACPI_THINKPAD_METHOD_EVENTMASK:
+		if (sc->events_mask_supported)
+			acpi_GetInteger(sc->handle,
+			    THINKPAD_NAME_EVENTS_MASK_GET, &val);
+		break;
+
+	case ACPI_THINKPAD_METHOD_HOTKEY:
+		/*
+		 * Construct the hotkey as a bitmask as illustrated below.
+		 * Note that whenever a key was pressed, the respecting bit
+		 * toggles and nothing else changes.
+		 * +--+--+-+-+-+-+-+-+-+-+-+-+
+		 * |11|10|9|8|7|6|5|4|3|2|1|0|
+		 * +--+--+-+-+-+-+-+-+-+-+-+-+
+		 *   |  | | | | | | | | | | |
+		 *   |  | | | | | | | | | | +- Home Button
+		 *   |  | | | | | | | | | +--- Search Button
+		 *   |  | | | | | | | | +----- Mail Button
+		 *   |  | | | | | | | +------- Thinkpad Button
+		 *   |  | | | | | | +--------- Zoom (Fn + Space)
+		 *   |  | | | | | +----------- WLAN Button
+		 *   |  | | | | +------------- Video Button
+		 *   |  | | | +--------------- Hibernate Button
+		 *   |  | | +----------------- Thinklight Button
+		 *   |  | +------------------- Screen expand (Fn + F8)
+		 *   |  +--------------------- Brightness
+		 *   +------------------------ Volume/Mute
+		 */
+		key = rtcin(THINKPAD_RTC_HOTKEY1);
+		val = (THINKPAD_RTC_MASK_HOME | THINKPAD_RTC_MASK_SEARCH |
+		    THINKPAD_RTC_MASK_MAIL | THINKPAD_RTC_MASK_WLAN) & key;
+		key = rtcin(THINKPAD_RTC_HOTKEY2);
+		val |= (THINKPAD_RTC_MASK_THINKPAD | THINKPAD_RTC_MASK_VIDEO |
+		    THINKPAD_RTC_MASK_HIBERNATE) & key;
+		val |= (THINKPAD_RTC_MASK_ZOOM & key) >> 1;
+		key = rtcin(THINKPAD_RTC_THINKLIGHT);
+		val |= (THINKPAD_RTC_MASK_THINKLIGHT & key) << 4;
+		key = rtcin(THINKPAD_RTC_SCREENEXPAND);
+		val |= (THINKPAD_RTC_MASK_THINKLIGHT & key) << 4;
+		key = rtcin(THINKPAD_RTC_BRIGHTNESS);
+		val |= (THINKPAD_RTC_MASK_BRIGHTNESS & key) << 5;
+		key = rtcin(THINKPAD_RTC_VOLUME);
+		val |= (THINKPAD_RTC_MASK_VOLUME & key) << 4;
+		break;
+
+	case ACPI_THINKPAD_METHOD_BRIGHTNESS:
+		ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_BRIGHTNESS, &val_ec, 1);
+		val = val_ec & THINKPAD_EC_MASK_BRI;
+		break;
+
+	case ACPI_THINKPAD_METHOD_VOLUME:
+		ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_VOLUME, &val_ec, 1);
+		val = val_ec & THINKPAD_EC_MASK_VOL;
+		break;
+
+	case ACPI_THINKPAD_METHOD_MUTE:
+		val = ((val_ec & THINKPAD_EC_MASK_MUTE) ==
+		    THINKPAD_EC_MASK_MUTE);
+		break;
+
+	case ACPI_THINKPAD_METHOD_THINKLIGHT:
+		if (sc->light_get_supported)
+			acpi_GetInteger(sc->ec_handle, THINKPAD_NAME_KEYLIGHT,
+			    &val);
+		else
+			val = sc->light_val;
+		break;
+
+	case ACPI_THINKPAD_METHOD_BLUETOOTH:
+		acpi_GetInteger(sc->handle, THINKPAD_NAME_WLAN_BT_GET, &val);
+		sc->wlan_bt_flags = val;
+		val = ((val & THINKPAD_NAME_MASK_BT) != 0);
+		break;
+
+	case ACPI_THINKPAD_METHOD_WLAN:
+		acpi_GetInteger(sc->handle, THINKPAD_NAME_WLAN_BT_GET, &val);
+		sc->wlan_bt_flags = val;
+		val = ((val & THINKPAD_NAME_MASK_WLAN) != 0);
+		break;
+
+	case ACPI_THINKPAD_METHOD_FANSPEED:
+		if (sc->fan_handle) {
+			if (ACPI_FAILURE(acpi_GetInteger(sc->fan_handle,
+			    NULL, &val)))
+				val = -1;
+		}
+		else {
+			ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_FANSPEED,
+			    &val_ec, 2);
+			val = val_ec;
+		}
+		break;
+
+	case ACPI_THINKPAD_METHOD_FANLEVEL:
+		/*
+		 * The THINKPAD_EC_FANSTATUS register works as follows:
+		 * Bit 0-5 indicate the level at which the fan operates. Only
+		 *       values between 0 and 7 have an effect. Everything
+		 *       above 7 is treated the same as level 7
+		 * Bit 6 overrides the fan speed limit if set to 1
+		 * Bit 7 indicates at which mode the fan operates:
+		 *       manual (0) or automatic (1)
+		 */
+		if (!sc->fan_handle) {
+			ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_FANSTATUS,
+			    &val_ec, 1);
+			val = val_ec & THINKPAD_EC_MASK_FANLEVEL;
+		}
+		break;
+
+	case ACPI_THINKPAD_METHOD_FANSTATUS:
+		if (!sc->fan_handle) {
+			ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_FANSTATUS,
+			    &val_ec, 1);
+			val = (val_ec & THINKPAD_EC_MASK_FANSTATUS) ==
+			    THINKPAD_EC_MASK_FANSTATUS;
+		}
+		else
+			val = -1;
+		break;
+	}
+
+	return (val);
+}
+
+static int
+acpi_thinkpad_sysctl_set(struct acpi_thinkpad_softc *sc, int method, int arg)
+{
+	int			val, step, i;
+	ACPI_INTEGER		val_ec;
+	ACPI_OBJECT		Arg;
+	ACPI_OBJECT_LIST	Args;
+	ACPI_STATUS		status;
+
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+	/* ACPI_SERIAL_ASSERT(thinkpad); */
+
+	switch (method) {
+	case ACPI_THINKPAD_METHOD_EVENTS:
+		if (arg < 0 || arg > 1)
+			return (EINVAL);
+
+		status = acpi_SetInteger(sc->handle,
+		    THINKPAD_NAME_EVENTS_STATUS_SET, arg);
+		if (ACPI_FAILURE(status))
+			return (status);
+		if (sc->events_mask_supported)
+			return acpi_thinkpad_eventmask_set(sc,
+			    sc->events_availmask);
+		break;
+
+	case ACPI_THINKPAD_METHOD_EVENTMASK:
+		if (sc->events_mask_supported)
+			return acpi_thinkpad_eventmask_set(sc, arg);
+		break;
+
+	case ACPI_THINKPAD_METHOD_BRIGHTNESS:
+		if (arg < 0 || arg > 7)
+			return (EINVAL);
+
+		if (sc->cmos_handle) {
+			/* Read the current brightness */
+			status = ACPI_EC_READ(sc->ec_dev,
+			    THINKPAD_EC_BRIGHTNESS, &val_ec, 1);
+			if (ACPI_FAILURE(status))
+				return (status);
+			val = val_ec & THINKPAD_EC_MASK_BRI;
+
+			Args.Count = 1;
+			Args.Pointer = &Arg;
+			Arg.Type = ACPI_TYPE_INTEGER;
+			Arg.Integer.Value = (arg > val) ?
+			    THINKPAD_CMOS_BRIGHTNESS_UP :
+			    THINKPAD_CMOS_BRIGHTNESS_DOWN;
+
+			step = (arg > val) ? 1 : -1;
+			for (i = val; i != arg; i += step) {
+				status = AcpiEvaluateObject(sc->cmos_handle,
+				    NULL, &Args, NULL);
+				if (ACPI_FAILURE(status))
+					break;
+			}
+		}
+		return ACPI_EC_WRITE(sc->ec_dev, THINKPAD_EC_BRIGHTNESS,
+		    arg, 1);
+		break;
+
+	case ACPI_THINKPAD_METHOD_VOLUME:
+		if (arg < 0 || arg > 14)
+			return (EINVAL);
+
+		status = ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_VOLUME,
+		    &val_ec, 1);
+		if (ACPI_FAILURE(status))
+			return (status);
+
+		if (sc->cmos_handle) {
+			val = val_ec & THINKPAD_EC_MASK_VOL;
+
+			Args.Count = 1;
+			Args.Pointer = &Arg;
+			Arg.Type = ACPI_TYPE_INTEGER;
+			Arg.Integer.Value = (arg > val) ?
+			    THINKPAD_CMOS_VOLUME_UP : THINKPAD_CMOS_VOLUME_DOWN;
+
+			step = (arg > val) ? 1 : -1;
+			for (i = val; i != arg; i += step) {
+				status = AcpiEvaluateObject(sc->cmos_handle,
+				    NULL, &Args, NULL);
+				if (ACPI_FAILURE(status))
+					break;
+			}
+		}
+		return ACPI_EC_WRITE(sc->ec_dev, THINKPAD_EC_VOLUME, arg +
+		    (val_ec & (~THINKPAD_EC_MASK_VOL)), 1);
+		break;
+
+	case ACPI_THINKPAD_METHOD_MUTE:
+		if (arg < 0 || arg > 1)
+			return (EINVAL);
+
+		status = ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_VOLUME,
+		    &val_ec, 1);
+		if (ACPI_FAILURE(status))
+			return (status);
+
+		if (sc->cmos_handle) {
+			val = val_ec & THINKPAD_EC_MASK_VOL;
+
+			Args.Count = 1;
+			Args.Pointer = &Arg;
+			Arg.Type = ACPI_TYPE_INTEGER;
+			Arg.Integer.Value = THINKPAD_CMOS_VOLUME_MUTE;
+
+			status = AcpiEvaluateObject(sc->cmos_handle, NULL,
+			    &Args, NULL);
+			if (ACPI_FAILURE(status))
+				break;
+		}
+		return ACPI_EC_WRITE(sc->ec_dev, THINKPAD_EC_VOLUME, (arg==1) ?
+		   val_ec | THINKPAD_EC_MASK_MUTE :
+		   val_ec & (~THINKPAD_EC_MASK_MUTE), 1);
+		break;
+
+	case ACPI_THINKPAD_METHOD_THINKLIGHT:
+		if (arg < 0 || arg > 1)
+			return (EINVAL);
+
+		if (sc->light_set_supported) {
+			Args.Count = 1;
+			Args.Pointer = &Arg;
+			Arg.Type = ACPI_TYPE_INTEGER;
+			Arg.Integer.Value = arg ?
+			    sc->light_cmd_on : sc->light_cmd_off;
+
+			status = AcpiEvaluateObject(sc->light_handle, NULL,
+			    &Args, NULL);
+			if (ACPI_SUCCESS(status))
+				sc->light_val = arg;
+			return (status);
+		}
+		break;
+
+	case ACPI_THINKPAD_METHOD_BLUETOOTH:
+		if (arg < 0 || arg > 1)
+			return (EINVAL);
+
+		val = (arg == 1) ? sc->wlan_bt_flags |
+		    THINKPAD_NAME_MASK_BT :
+		    sc->wlan_bt_flags & (~THINKPAD_NAME_MASK_BT);
+		return acpi_SetInteger(sc->handle, THINKPAD_NAME_WLAN_BT_SET,
+		    val);
+		break;
+
+	case ACPI_THINKPAD_METHOD_FANLEVEL:
+		if (arg < 0 || arg > 7)
+			return (EINVAL);
+
+		if (!sc->fan_handle) {
+			/* Read the current fanstatus */
+			ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_FANSTATUS,
+			    &val_ec, 1);
+			val = val_ec & (~THINKPAD_EC_MASK_FANLEVEL);
+
+			return ACPI_EC_WRITE(sc->ec_dev, THINKPAD_EC_FANSTATUS,
+			    val | arg, 1);
+		}
+		break;
+
+	case ACPI_THINKPAD_METHOD_FANSTATUS:
+		if (arg < 0 || arg > 1)
+			return (EINVAL);
+
+		if (!sc->fan_handle) {
+			/* Read the current fanstatus */
+			ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_FANSTATUS,
+			    &val_ec, 1);
+
+			return ACPI_EC_WRITE(sc->ec_dev, THINKPAD_EC_FANSTATUS,
+			    (arg == 1) ? (val_ec | THINKPAD_EC_MASK_FANSTATUS) :
+			    (val_ec & (~THINKPAD_EC_MASK_FANSTATUS)), 1);
+		}
+		break;
+	}
+
+	return (0);
+}
+
+static int
+acpi_thinkpad_sysctl_init(struct acpi_thinkpad_softc *sc, int method)
+{
+	int 			dummy;
+	ACPI_OBJECT_TYPE 	cmos_t;
+	ACPI_HANDLE		ledb_handle;
+
+	switch (method) {
+	case ACPI_THINKPAD_METHOD_EVENTS:
+		/* Events are disabled by default */
+		return (TRUE);
+
+	case ACPI_THINKPAD_METHOD_EVENTMASK:
+		return (sc->events_mask_supported);
+
+	case ACPI_THINKPAD_METHOD_HOTKEY:
+	case ACPI_THINKPAD_METHOD_BRIGHTNESS:
+	case ACPI_THINKPAD_METHOD_VOLUME:
+	case ACPI_THINKPAD_METHOD_MUTE:
+		/* EC is required here, which was already checked before */
+		return (TRUE);
+
+	case ACPI_THINKPAD_METHOD_THINKLIGHT:
+		sc->cmos_handle = NULL;
+		sc->light_get_supported = ACPI_SUCCESS(acpi_GetInteger(
+		    sc->ec_handle, THINKPAD_NAME_KEYLIGHT, &sc->light_val));
+
+		if ((ACPI_SUCCESS(AcpiGetHandle(sc->handle, "\\UCMS",
+		    &sc->light_handle)) ||
+		    ACPI_SUCCESS(AcpiGetHandle(sc->handle, "\\CMOS",
+		    &sc->light_handle)) ||
+		    ACPI_SUCCESS(AcpiGetHandle(sc->handle, "\\CMS",
+		    &sc->light_handle))) &&
+		    ACPI_SUCCESS(AcpiGetType(sc->light_handle, &cmos_t)) &&
+		    cmos_t == ACPI_TYPE_METHOD) {
+			sc->light_cmd_on = 0x0c;
+			sc->light_cmd_off = 0x0d;
+			sc->cmos_handle = sc->light_handle;
+		}
+		else if (ACPI_SUCCESS(AcpiGetHandle(sc->handle, "\\LGHT",
+		    &sc->light_handle))) {
+			sc->light_cmd_on = 1;
+			sc->light_cmd_off = 0;
+		}
+		else
+			sc->light_handle = NULL;
+
+		sc->light_set_supported = (sc->light_handle &&
+		    ACPI_FAILURE(AcpiGetHandle(sc->ec_handle, "LEDB",
+		    &ledb_handle)));
+
+		if (sc->light_get_supported)
+			return (TRUE);
+
+		if (sc->light_set_supported) {
+			sc->light_val = 0;
+			return (TRUE);
+		}
+
+		return (FALSE);
+
+	case ACPI_THINKPAD_METHOD_BLUETOOTH:
+	case ACPI_THINKPAD_METHOD_WLAN:
+		if (ACPI_SUCCESS(acpi_GetInteger(sc->handle,
+		    THINKPAD_NAME_WLAN_BT_GET, &dummy)))
+			return (TRUE);
+		return (FALSE);
+
+	case ACPI_THINKPAD_METHOD_FANSPEED:
+		/* 
+		 * Some models report the fan speed in levels from 0-7
+		 * Newer models report it contiguously
+		 */
+		sc->fan_levels = (ACPI_SUCCESS(AcpiGetHandle(sc->handle, "GFAN",
+		    &sc->fan_handle)) ||
+		    ACPI_SUCCESS(AcpiGetHandle(sc->handle, "\\FSPD",
+		    &sc->fan_handle)));
+		return (TRUE);
+
+	case ACPI_THINKPAD_METHOD_FANLEVEL:
+	case ACPI_THINKPAD_METHOD_FANSTATUS:
+		/* 
+		 * Fan status is only supported on those models,
+		 * which report fan RPM contiguously, not in levels
+		 */
+		if (sc->fan_levels)
+			return (FALSE);
+		return (TRUE);
+
+	case ACPI_THINKPAD_METHOD_THERMAL:
+		if (ACPI_SUCCESS(acpi_GetInteger(sc->ec_handle,
+		    THINKPAD_NAME_THERMAL_GET, &dummy))) {
+			sc->thermal_updt_supported =
+			    ACPI_SUCCESS(acpi_GetInteger(sc->ec_handle,
+			    THINKPAD_NAME_THERMAL_UPDT, &dummy));
+			return (TRUE);
+		}
+		return (FALSE);
+	}
+	return (FALSE);
+}
+
+static void
+acpi_thinkpad_notify(ACPI_HANDLE h, UINT32 notify, void *context)
+{
+	int		event, arg, type;
+	device_t	dev = context;
+	struct acpi_thinkpad_softc *sc = device_get_softc(dev);
+
+	ACPI_FUNCTION_TRACE_U32((char *)(uintptr_t)__func__, notify);
+
+	if (notify != 0x80)
+		device_printf(dev, "Unknown notify\n");
+
+	for (;;) {
+		acpi_GetInteger(acpi_get_handle(dev), THINKPAD_NAME_EVENTS_GET,
+		    &event);
+
+		if (event == 0)
+			break;
+
+		type = (event >> 12) & 0xf;
+		arg = event & 0xfff;
+		switch (type) {
+		case 1:
+			if (!(sc->events_availmask & (1 << (arg - 1)))) {
+				device_printf(dev, "Unknown key %d\n", arg);
+				break;
+			}
+
+			/* Notify devd(8) */
+			device_printf(dev, "THINKPAD event: %u\n",
+			    (arg & 0xff));
+			acpi_UserNotify("THINKPAD", h, (arg & 0xff));
+			break;
+		default:
+			break;
+		}
+	}
+}
+
+static void
+acpi_thinkpad_refresh(void *arg)
+{
+	struct acpi_thinkpad_softc *sc = (struct acpi_thinkpad_softc *)arg;
+	char temp_cmd[] = "TMP0";
+	int data, i;
+	ACPI_INTEGER speed;
+
+	for (i = 0; i < 8; i++) {
+		temp_cmd[3] = '0' + i;
+		
+                /*
+                 * The TMPx methods seem to return +/- 128 or 0
+                 * when the respecting sensor is not available
+                 */
+		sc->sensors[i].flags &= ~SENSOR_FINVALID;
+                if (ACPI_FAILURE(acpi_GetInteger(sc->ec_handle, temp_cmd,
+                    &data)) || ABS(data) == 128 || data == 0) {
+			sc->sensors[i].flags |= SENSOR_FINVALID;
+                        data = 0;
+		}
+                else if (sc->thermal_updt_supported) {
+                        /* XXX: Temperature is reported in tenth of Kelvin */
+                        data = (data - 2732 + 5) / 10;
+		}
+		sc->sensors[i].value = data * 1000000 + 273150000;
+        }
+	
+	sc->sensors[8].flags &= ~SENSOR_FINVALID;
+	if (sc->fan_handle) {
+		if (ACPI_FAILURE(acpi_GetInteger(sc->fan_handle,
+		    NULL, &data)))
+			sc->sensors[8].flags |= SENSOR_FINVALID;
+                        data = -1;
+        }
+        else {
+                ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_FANSPEED, &speed, 2);
+                data = speed;
+        }
+
+	sc->sensors[8].value = data;
+}
diff --git a/sys/platform/pc32/conf/files b/sys/platform/pc32/conf/files
--- a/sys/platform/pc32/conf/files
+++ b/sys/platform/pc32/conf/files
@@ -72,6 +72,7 @@ dev/serial/dgb/dgm.c			optional	dgm
 ${OSACPI_MD_DIR}/acpi_machdep.c		optional        acpi
 ${OSACPI_MD_DIR}/acpi_wakeup.c		optional        acpi
 ${OSACPI_MD_DIR}/acpi_toshiba.c		optional        acpi_toshiba acpi
+${ACPICA_DIR}/acpi_thinkpad/acpi_thinkpad.c optional	acpi_thinkpad acpi
 acpi.h					optional	acpi		\
 	dependency	"$S/${ACPICA_DIR}/include/acpi.h"		\
 	compile-with	"cp $S/${ACPICA_DIR}/include/acpi.h ${.OBJDIR}/"	\



From hasso at estpak.ee  Thu Mar 20 03:49:13 2008
From: hasso at estpak.ee (Hasso Tepper)
Date: Thu, 20 Mar 2008 03:49:13 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Some questions regarding ACPI
In-Reply-To: <200803191322.46366.hasso@estpak.ee>
Message-ID: <200803201237.28823.hasso@estpak.ee>

Hasso Tepper wrote:
> There is also one fatal issue -laptop locks up hardly (no panic) while 
> unloading module. Any idea regarding this is welcome.

Nevermind, solved.


-- 
Hasso




From dillon at apollo.backplane.com  Fri Mar 21 19:24:01 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Fri, 21 Mar 2008 19:24:01 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: panic: assertion: hammer_btree_cmp(cursor->left_bound,	&cursor->node->ondisk->elms[0].leaf.base) <= 0 in btree_split_leaf
In-Reply-To: <200802232204.m1NM4cxd046264@apollo.backplane.com>
Message-ID: <200803220212.m2M2CiAY014435@apollo.backplane.com>

:While trying to find a procedure to reliably reproduce the panic
:I reported last time, I caught a different panic (uploaded at
: ~y0netan1/crash/9/ on my leaf account).  I wrote the following shell
:script (make sure to edit variables DISKS and MOUNTPT before using this
:script or it may trash your system):

    Ok, I believe I have fixed the left_bound assertion.  I also believe
    I have fixed the node ref count assertion on umount.

    There is currently one unfixed assertion related to the I/O
    path... sometimes the bp is being improperly disassociated from the
    related HAMMER structure.

    The full-filesystem case is still not being handled so don't test that :-)

					    -Matt





From c.turner at 199technologies.org  Sun Mar 23 09:48:29 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Sun, 23 Mar 2008 09:48:29 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
Message-ID: <47E6870C.4080709@199technologies.org>

I'm finally getting around to doing 1.12 upgrades, and have setup a 
separate machine to do my bulk package builds / upgrades etc,
so as not to disrupt my 'dev server' while things are being
built / tested

However, this seems kind of wasteful - the only purpose of this machine
is to build packages against a specific release..
And since building packages for a particular release generally requires 
only the userland, appropriate headers and correct 'uname' output - so:

it seems like if spoofing uname is configured inside a jail,
the next (or previous..) release can be installed into a jail and
used for building / testing packages without the overhead of a VM or 
maintaining a separate physical host

I did a quick scan of the tree to see what this would take, and, high 
level, it seems like only the following changes would need to be made:

- update struct jail to add a 'osrelease' string
  (implies bumping 'jail api' to 2?)
- update jail(8) to actually pass this information along
- update sys_uname to test ucred for jailed processes, and
  use the struct jail osrelease if appropriate
- similarly update sysctl kern.osrelease to support jail spoofing
  (if possible - didn't get this far in the research yet)
  could be less of a problem for builds, as I think most things use
 uname(1) ... but good to keep the environment consistent I suppose..
I'm still a bit confused as to how 'osrelease' is defined - everything
I'm finding is showing up as extern char[] .. perhaps this is something 
in the build I'm not familiar with?

also,

is the so-called 'stupid hackery' in sys_uname needed still?

Before I start any coding, does this:

- sound like something useful
- sound like the right approach
Thinking this could have wider useful implications e.g. for pkgbox
& so on -  for example setting up automated bulks w/various combinations 
of pkgsrc and releases, etc.

Cheers,

- Chris





From corecode at fs.ei.tum.de  Sun Mar 23 10:06:38 2008
From: corecode at fs.ei.tum.de (Simon 'corecode' Schubert)
Date: Sun, 23 Mar 2008 10:06:38 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <47E68C74.3080808@fs.ei.tum.de>

Chris Turner wrote:
I did a quick scan of the tree to see what this would take, and, high 
level, it seems like only the following changes would need to be made:
brave investigation.  but you could also simply set UNAME_r :)

sweatshorts % uname -r
1.13.0-DEVELOPMENT
sweatshorts % UNAME_r=1.12-RELEASE uname -r
1.12-RELEASE
I think that's good enough :D

cheers
  simon
--
Serve - BSD     +++  RENT this banner advert  +++    ASCII Ribbon   /"\
Work - Mac      +++  space for low ????????? NOW!1  +++      Campaign     \ /
Party Enjoy Relax   |   http://dragonflybsd.org      Against  HTML   \
Dude 2c 2 the max   !   http://golden-apple.biz       Mail + News   / \




From c.turner at 199technologies.org  Sun Mar 23 10:50:13 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Sun, 23 Mar 2008 10:50:13 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <47E69656.8080605@199technologies.org>

Simon 'corecode' Schubert wrote:
brave investigation.  but you could also simply set UNAME_r :)
Doh! Thanks for the tip!

they should change the phrase from RTFM to 'Carefully RTFM' :)

well.. scratch that change then. 1 less patch to write.

- Chris





From c.turner at 199technologies.org  Sun Mar 23 11:15:52 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Sun, 23 Mar 2008 11:15:52 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <47E69C7C.8010109@199technologies.org>

Chris Turner wrote:
Simon 'corecode' Schubert wrote:
brave investigation.  but you could also simply set UNAME_r :)

for the record - if anyone's interested - adding a line e.g.:

ALL_ENV+= UNAME_r=1.12-RELEASE

to mk.conf looks like it -might- work ..

(unless wants to chime in & verify)





From joerg at britannica.bec.de  Sun Mar 23 11:46:53 2008
From: joerg at britannica.bec.de (Joerg Sonnenberger)
Date: Sun, 23 Mar 2008 11:46:53 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <20080323181428.GA2099@britannica.bec.de>

On Sun, Mar 23, 2008 at 01:41:42PM -0400, Chris Turner wrote:
> they should change the phrase from RTFM to 'Carefully RTFM' :)

RTFMAI -- Read The Fine Manual Again, Idiot.

Joerg




From dillon at apollo.backplane.com  Sun Mar 23 20:05:36 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Sun, 23 Mar 2008 20:05:36 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
Message-ID: <200803240257.m2O2voNH038355@apollo.backplane.com>

    Here's an update on the HAMMER work!

    Current status:

    * Passes all standard filesystem stress tests and buildworld will
      run with a HAMMER /usr/obj.  Large histories are able to accumulate
      without effecting performance.

    * Pruning and reblocking code is in and partially tested, but now needs
      more stringent testing.

    * Full historical access appears to be working but needs testing.
      Note that a sync is still needed to flush dirty cached data prior
      to acquiring a timestamp for the 'snapshot' to be set in stone.
      (dirty data cached in-memory has no historical tags and must be
      committed to physical disk before it can be accessed historically).


    Current bugs:

    * There is one known bug in the standard operations code paths
      that results in an assertion in HAMMER's I/O subsystem.

    * There are probably bugs in the reblocking and/or pruning code.  More
      likely in the reblocking code.


    There are two big-ticket and several little-ticket items left.  HAMMER
    will officially go Alpha when the big-ticket items are done, and beta
    when we get a few of the little-ticket items done.

    Big ticket items left:

    * UNDO (crash recovery) code.  Currently it writes out undo records but
      they are not yet sequenced, buffer writes are not yet ordered, and
      there is no mount-time recovery code yet.

      This is the last item needed before HAMMER can go operational.

    * Filesystem full handling.  Currently no space is reserved for dirty
      cached data so it is possible to create/write files and for HAMMER
      to not have sufficient space left on-disk to flush it.


    Little ticket items:

    * Automated reblocking (currently these functions are manually
      initialized via the hammer utility).

    * I/O clustering and preliminary BMAP op when writing out large files.

    * CRC checking (CRC fields are reserved but not entirely generated yet
      and not yet checked at all).

    * Disaster Recovery filesystem scan.

    * Boot support.

    I expect all of these items and more to be handled by the 2.0 release
    in July.

			    Additional HAMMER capabilities
				(no timeline yet)

    * Adding, removing, and resizing a HAMMER filesystem's backing store.

			Ultimate Goals and working towards them
				(no timeline yet)

    Our ultimate goal with HAMMER and DragonFly in general is to support
    fully cache coherent replication in a multi-machine environment.  This
    involves several steps and networking protocols.

    * Replication of synchronization streams based on the UNDO log.  If
      resynchronizing to a target which is too old a B-Tree scan will
      likely be required.

    * Cache coherency protocols for machine-machine coherency for both
      replicated and remote-HAMMER access.

    I have no time frame for these items yet.  It will depend on how quickly
    HAMMER moves to Alpha and Beta status.  I will say, however, now
    that HAMMER's on-disk format has solidified, that I have a very precise
    understanding of the protocols that will be needed to accomplish fully
    cache coherent remote access for both replicated and non-replicated
    (remote mount style) access.

    And, as you know, fully coherent filesystem access across machines is
    going to be the basis for DragonFly's clustering across said machines.

    In summary, things are progressing very well.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From justin at shiningsilence.com  Sun Mar 23 20:10:13 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Sun, 23 Mar 2008 20:10:13 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <53758.192.168.0.252.1206327873.squirrel@www.shiningsilence.com>

On Sun, March 23, 2008 12:36 pm, Chris Turner wrote:

> it seems like if spoofing uname is configured inside a jail,
> the next (or previous..) release can be installed into a jail and
> used for building / testing packages without the overhead of a VM or
> maintaining a separate physical host

If you don't need a jail to spoof uname, as others posted, you can
installworld into a chroot and build everything you want there using
Joerg's spiffy pbulk.  That's what I'm doing on pkgbox now; I can hand you
my somewhat terse notes if you want.  It would be relatively easy to set
up the configuration you're talking about.





From sepherosa at gmail.com  Sun Mar 23 20:18:20 2008
From: sepherosa at gmail.com (Sepherosa Ziehau)
Date: Sun, 23 Mar 2008 20:18:20 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <ea7b9c170803232012n2f27f893tf1d756d7c9770419@mail.gmail.com>

On Mon, Mar 24, 2008 at 2:14 AM, Joerg Sonnenberger
<joerg at britannica.bec.de> wrote:
> On Sun, Mar 23, 2008 at 01:41:42PM -0400, Chris Turner wrote:
>  > they should change the phrase from RTFM to 'Carefully RTFM' :)
>
>  RTFMAI -- Read The Fine Manual Again, Idiot.

http://leaf.dragonflybsd.org/~sephe/rtfm.jpg

:D

>
>  Joerg
>



-- 
Live Free or Die




From justin at shiningsilence.com  Sun Mar 23 20:38:30 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Sun, 23 Mar 2008 20:38:30 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: GSoC 2008 - mentors signup
Message-ID: <53885.192.168.0.252.1206329503.squirrel@www.shiningsilence.com>

If you are planning to be a mentor for a Summer of Code project, please
sign up here for the mentors mailing list:

http://groups.google.com/group/google-summer-of-code-mentors-list

If you've already signed up, your subscription should be set up tomorrow.





From justin at shiningsilence.com  Sun Mar 23 21:12:01 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Sun, 23 Mar 2008 21:12:01 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: GSoC 2008 - mentors signup
In-Reply-To: <53885.192.168.0.252.1206329503.squirrel@www.shiningsilence.com>
Message-ID: <54025.192.168.0.252.1206331572.squirrel@www.shiningsilence.com>

Also!

If you are a potential mentor and you have not done so yet:

http://code.google.com/soc/mentor_step1.html

Get yourself registered as a mentor for the Summer of Code project.  Once
you are in there, check off DragonFly in the "My Profile" section.

You will need a Google Account if you don't have one:

http://www.google.com/accounts

This will add you to the list of mentors in the Google Summer of Code web
application, so you can review/be attached to projects.

A guide is available if you want more information:

http://groups.google.com/group/google-summer-of-code-announce/web/guide-to-the-gsoc-web-app-for-mentors-and-organization-administrators






From c.turner at 199technologies.org  Mon Mar 24 04:29:28 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Mon, 24 Mar 2008 04:29:28 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <47E78ECE.4070307@199technologies.org>

Justin C. Sherrill wrote:
If you don't need a jail to spoof uname, as others posted, you can
installworld into a chroot and build everything you want there using
Joerg's spiffy pbulk.  That's what I'm doing on pkgbox now; I can hand you
my somewhat terse notes if you want.  It would be relatively easy to set
up the configuration you're talking about.
cheers - I guess I thought incorrectly that something 'special' was 
needed to get the uname to change .. have been using the legacy bulks in 
chroots / jails (for 'same os' builds) as I haven't quite migrated to 
pbulk yet ..

thanks for the help offer - I'll ask if I run into trouble.




From dillon at apollo.backplane.com  Mon Mar 24 08:28:49 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Mon, 24 Mar 2008 08:28:49 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <200803241500.m2OF0CG8043760@apollo.backplane.com>


:http://leaf.dragonflybsd.org/~sephe/rtfm.jpg
:
::D

    Ho!

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From elekktretterr at exemail.com.au  Mon Mar 24 09:10:15 2008
From: elekktretterr at exemail.com.au (Petr Janda)
Date: Mon, 24 Mar 2008 09:10:15 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
In-Reply-To: <200803240257.m2O2voNH038355@apollo.backplane.com>
Message-ID: <200803250138.49775.elekktretterr@exemail.com.au>


>
>     And, as you know, fully coherent filesystem access across machines is
>     going to be the basis for DragonFly's clustering across said machines.
>
>     In summary, things are progressing very well.
>


Hi Matt,
That's good to know things are going so well. Got a question. If memory serves 
me right, initially there was also going to be a thing called ANVIL, I can't 
remember what it was supposed to do and whether its still in your design. 
Could you elaborate a little?

Thanks,
Petr




From dillon at apollo.backplane.com  Mon Mar 24 14:12:11 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Mon, 24 Mar 2008 14:12:11 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
In-Reply-To: <200803240257.m2O2voNH038355@apollo.backplane.com>
Message-ID: <200803242100.m2OL0nWV046868@apollo.backplane.com>


:Hi Matt,
:That's good to know things are going so well. Got a question. If memory serves 
:me right, initially there was also going to be a thing called ANVIL, I can't 
:remember what it was supposed to do and whether its still in your design. 
:Could you elaborate a little?
:
:Thanks,
:Petr

    It's not really in the HAMMER design any more, primarily because HAMMER's
    volume model seems to work fine as-is.  Ultimately something like ANVIL
    (a block storage manager) would prove beneficial to the project but it
    would be treated as a separate project.  HAMMER's redundancy model is
    going to be baesd around replication and clustering.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From tgen at netphreax.net  Mon Mar 24 18:31:37 2008
From: tgen at netphreax.net (Thomas E. Spanjaard)
Date: Mon, 24 Mar 2008 18:31:37 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
In-Reply-To: <200803240257.m2O2voNH038355@apollo.backplane.com>
Message-ID: <47E85337.2070407@netphreax.net>

Matthew Dillon wrote:
    * Full historical access appears to be working but needs testing.
      Note that a sync is still needed to flush dirty cached data prior
      to acquiring a timestamp for the 'snapshot' to be set in stone.
      (dirty data cached in-memory has no historical tags and must be
      committed to physical disk before it can be accessed historically).
Wouldn't making timestamp queries (at least from userland) enforce a 
sync on the volume in question be useful here?
--
        Thomas E. Spanjaard
        tgen at netphreax.net
Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00005.pgp
Type: application/octet-stream
Size: 186 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080324/3077333f/attachment-0015.obj>

From dillon at apollo.backplane.com  Mon Mar 24 20:10:12 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Mon, 24 Mar 2008 20:10:12 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
In-Reply-To: <200803240257.m2O2voNH038355@apollo.backplane.com>
Message-ID: <200803250302.m2P32qLP050160@apollo.backplane.com>


:Wouldn't making timestamp queries (at least from userland) enforce a 
:sync on the volume in question be useful here?
:-- 
:         Thomas E. Spanjaard
:         tgen at netphreax.net

    Making the 'hammer now' command do a sync() is a good idea.  I will
    make that change right now so it doesn't get lost.

    Here's a general overview of the issues involved with having historical
    access to the filesystem:

				----------------

    Recording the timestamps in the in-memory cache, for a finer-grained
    snapshot capability, is doable but has its own issues.  Here's an
    illustration:

    open()  create file
    write() append 4K	(file size now 4K)
    write() append 4K	(file size now 8K)
    write() append 4K	(file size now 12K)
    write() append 4K	(file size now 16K)

    Now NONE of this has gone to disk yet, it's entirely in the in-memory
    cache.  The inode is in the in-memory cache.  The data is stored in
    the buffer cache.  Even the directory entry for the file that we
    just created is still in the in-memory cache (HAMMER caches the raw
    records it intends to commit later on).

    If I wanted to be able to acquire a timestamp between each write and
    'see' a snapshot of the file as of any point in the above sequence,
    then every write would also have to allocate a copy of the inode
    (because it changes size on each write).

    The data has the same problem though with a slightly different example.
    Lets say each write() was a seek-write, overwriting the previous data.
    Now with every write() I would have to allocate a copy of the data
    being overwritten.  This is complicated by the fact that the buffer
    cache has no clue about 'historical' accesses, so I would not be able
    to use the buffer cache to cache the data.

    There's also another problem and that is with the efficiency of the
    topology on-disk.  Even if I maintained all the copies of the inode
    and all the copies of the data in-memory, I would still have to sync
    all those copies to disk in order for things to remain historically
    coherent (whether it be in-cache or on-disk).  This would result in
    hundreds or even thousands of copies of the inode on-disk, not to
    mention potentially many copies of the data.

    I just don't want to do that right now, at least not as a default.  A
    lot of performance would be lost.  Hence a sync() is needed if
    you want to create a demark which you can accurately snapshot.

				-------------

    Here's a quick synopsis of how the cache would operate in a clustered
    filesystem:

    In order to properly integrate with in-memory caches, a wider cache
    coherency infrastructure is needed between machines such that
    modifications made on one machine proactively invalidate those
    protions of the cache(s) on other machines.  At the same time, any
    'dirty' cache data, for example when a file is created or written to,
    must lock the cache space in question on all other machines.
    The cache space in this case is not just the file data, but also the
    related namespaces (for creations, deletions, and renames).  Attempts
    to access locked spaces from other machines in the cluster would have
    to force a flush to the filesystem backing store and lower the cache
    states for the effected information on the original machine from dirty
    to shared-read-only.

    It will be easiest to integrate the cache coherency information into
    the buffer cache and namecache themselves.  Once a machine has dirtied
    an in-memory cache element... for example part of the namespace when
    creating a file or chunks of data written within a file, that machine
    must have a free hand to make further modifications to the cache spaces
    involved without further interaction with other machines.

				-------------

    Now, if you think of those two major elements you can see that they
    actually fit together quite well.  If I were to attempt to maintain
    transactional coherency on a per-system-call basis then the cache
    granularity between machines would have to be much, much smaller then
    our current in-memory caching elements provide.  That would become
    a really nasty coding problem.  So I don't even want to begin to
    complate transactional coherency at a finer-grain then sync() or
    fsync() until long after we actually have clustering working.

						-Matt





From elekktretterr at exemail.com.au  Mon Mar 24 21:56:58 2008
From: elekktretterr at exemail.com.au (Petr Janda)
Date: Mon, 24 Mar 2008 21:56:58 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
In-Reply-To: <200803240257.m2O2voNH038355@apollo.backplane.com>
Message-ID: <200803251516.16407.elekktretterr@exemail.com.au>

So is it needed to run hammer now in order to "create" a snapshot? What would 
I do in situation like this: got a hammer filesystem and couple of the files 
change on day to day basis. Then a week later I needed to access one of the 
files, in exactly the state they were 7 days ago.

Cheers,
Petr




From dillon at apollo.backplane.com  Mon Mar 24 22:34:15 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Mon, 24 Mar 2008 22:34:15 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
In-Reply-To: <200803240257.m2O2voNH038355@apollo.backplane.com>
Message-ID: <200803250526.m2P5QZ5X051081@apollo.backplane.com>


:So is it needed to run hammer now in order to "create" a snapshot? What would 
:I do in situation like this: got a hammer filesystem and couple of the files 
:change on day to day basis. Then a week later I needed to access one of the 
:files, in exactly the state they were 7 days ago.
:
:Cheers,
:Petr

    No, you do not have to run 'hammer now' to create a snapshot.  The
    kernel syncs all filesystems every 30 seconds, so if you do nothing
    at all you get a snapshot granularity of 30 seconds.

    Where you would use 'hammer now' is if you wanted the most current
    snapshot possible for the purpose of, say, backing up your filesystem
    to another machine.  You might do something like this:

	set timestamp = `hammer now`
	cpdup /mountpoint/@@$timestamp targethost:/somepath

    But if you didn't care about that you could just go back far enough
    that you get a stable historical view... e.g. go back 1 minute and you
    would have a stable view into your filesystem.

	set timestamp = `hammer stamp 60s`		<------ doesn't sync
	cpdup /mountpoint/@@$timestamp targethost:/somepath


    Ultimately the idea of managing filesystems this way is to still do
    regular backups from your production machine to your backup machine
    (ultimately by way of replication), with both running HAMMER, but only
    retain a limited amount of history on the production box.  You might
    desire to retain only one week's worth of history on the production box,
    retain one month's history on your local backup box, and retain a very
    granular one year's worth of history on your remote backup box.

    Come to think of it, I should add some more directives to the
    'hammer prune' command to make that easier to specify.

    Until I implement a live replication 'feed' the minimum granularity on
    the backup box will be how often you do your backups (e.g. once a day),
    and you can prune it into more granular forms from that starting point.
    Once we have a live replication feed the backup box will have the same
    30-second granularity that the production machine has.

    A major bullet point for this style of management is that the retention
    policy on the various boxes can be different even though they are
    all slaved off the same production filesystem.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From justin at shiningsilence.com  Tue Mar 25 05:58:49 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Tue, 25 Mar 2008 05:58:49 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: SoC - student signups
Message-ID: <58180.65.106.147.226.1206449676.squirrel@www.shiningsilence.com>

Here's a quick link roundup:

Are you a student?  Put in your application for a Google Summer of Code here:

http://code.google.com/soc/2008/student_signup.html

Student guide:
http://groups.google.com/group/google-summer-of-code-announce/web/guide-to-the-gsoc-web-app-for-student-applicants

Are you a mentor?  (That means hasso, hsu, sephe, matthias, TGEN, and
corecode right now)

Student proposals will show up on the mentor page, linked below.  You will
get to rate them, and take the one(s) that you want to mentor.

Mentor page:
http://code.google.com/soc/2008/mentor_home.html
Mentor guide:
http://groups.google.com/group/google-summer-of-code-announce/web/guide-to-the-gsoc-web-app-for-mentors-and-organization-administrators

If you are a mentor and are communicating with potential students, send
them the URLs above for student signup and the student guide; work with
them if they ask for advice on what to say in the application.  They can
resubmit up to 20 times if they want to correct it.

Deadline is March 31st.






From noah.yan at gmail.com  Thu Mar 27 20:17:48 2008
From: noah.yan at gmail.com (Yonghong Yan)
Date: Thu, 27 Mar 2008 20:17:48 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: About DFBSD.64
In-Reply-To: <47EB0B5B.5020802@gmail.com>
Message-ID: <59521b110803272015y1cc8cc39uc93f154ed36e0505@mail.gmail.com>

thanks for your interest.

I owe to everybody for any update or work in the past four months. so
many things happen in my work and my family (they are all good:) and
keep me extremely busy. But i am not leaving and will be back on this
soon.

the latest sources are in http://repo.or.cz/w/dragonfly/port-amd64.git
, I did have a compiled kernel long time before, but I have to break
it to work on the pmap. you can pick up from there. TGEN will help you
a lot, also keep me posted too, if you like.

Noah

On Wed, Mar 26, 2008 at 9:50 PM, Sdavtaker <sdavtaker at gmail.com> wrote:
> Hello,
>  Im applying to GSoC to work in the x64 version of DFBSD with TGEN, i
>  found some work already done in the repository and some mails in the
>  archive from you.
>  I was wondering if you already had a working compiled kernel in AMD64
>  machine and what was not working yet to continue that work.
>  Thanks for any info.
>  Sdav
>




From dillon at apollo.backplane.com  Sat Mar 29 13:27:43 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Sat, 29 Mar 2008 13:27:43 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 29-Mar-2008
Message-ID: <200803292022.m2TKMLGe004942@apollo.backplane.com>

    Good progress continues to be made.  HAMMER survived acting as my
    LAN backup machine (in full historical mode) for almost a week before
    it hit an assertion.  I've fixed that issue and believe that the core
    filesystem implementation code is now 'very stable'.

    Note that the recent commit will result in many more 'hammer_lock_ex:'
    messages on the console then you may have previously observed.  This is
    due to the way object id's are allocated in the face of parallel 
    modifications to the filesystem, resulting in too much locality of
    reference in the B-Tree.  I do intend to improve it.

    I am still working on the two major items needed before HAMMER can be
    declared operational, those being the filesystem full handling and the
    undo/recovery-on-mount code.  These are the last 'hard' bits left in
    the design.

    With exception to filling up the filesystem, which *will* create a mess,
    and noting that no crash recovery code exists yet (so you have to newfs
    it if you crash), I'd appreciate it if interested parties could test
    the other functions of the filesystem, in particular the pruning and
    reblocking functions (man hammer), and the historical access functions.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From dillon at apollo.backplane.com  Sun Mar 30 15:11:03 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Sun, 30 Mar 2008 15:11:03 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Need ideas on how to solve an st_ino/st_dev test issue for HAMMER.
Message-ID: <200803302207.m2UM7BCp016402@apollo.backplane.com>

    Here's the problem, given historical access softlinks as shown below:

test30# ls -lda cra*
drwxr-xr-x  1 root  wheel  Mar 29 13:04 crater
lrwxr-xr-x  1 root  wheel  Mar 29 18:57 crater.20080329 -> crater@@0x47eef383
lrwxr-xr-x  1 root  wheel  Mar 30 01:24 crater.20080330 -> crater@@0x47ef4e29
-rw-r--r--  2 root  wheel  Mar 30 01:24 crater.log

    The problem is that if I do this:

    diff -r crater.20080329/var/log crater.20080330/var/log

    Diff just returns without actually diffing anything.  The reason is
    because diff checks st_ino and st_dev and believes the directories/files
    to be identical because they match.

    I considered munging the inode number for historical accesses, but
    that would seriously break NFS exports which try to access historical
    files and directories.  Right now NFS *is* able to distinguish between
    the two because NFS handles are 128-bit-wide entities, so I can encode
    the as-of transaction id as part of the filehandle.  But userland
    programs only have access to a 64-bit-wide inode so userland still
    believes the files to be identical.

    st_dev is only 32 bits, carefully munging it is an option if we
    could figure out a way to do it, but I'd rather not.

    I am considering using st_gen but then we'd have to patch third
    party software to test st_gen along with everything else.  This may
    be the only workable solution, though, and only a few programs would
    need to be patched.  st_gen is only 32 bits but it would solve the
    problem as we would be able to use all 32 bits.

    If anyone has any bright ideas, including 'leave it alone', I'm all
    ears.

						-Matt





From justin at shiningsilence.com  Mon Mar 31 10:40:42 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Mon, 31 Mar 2008 10:40:42 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: SoC student applications due by 5PM PDT tomorrow
In-Reply-To: <1942.192.168.0.242.1206930479.squirrel@www.shiningsilence.com>
Message-ID: <11892.67.108.184.175.1206984967.squirrel@www.shiningsilence.com>

On Sun, March 30, 2008 10:27 pm, Justin C. Sherrill wrote:
> SoC students:
>
> If you have an application to submit for DragonFly/Summer of Code, please
> do so by 17:00 Pacific time on the 31st - that's tomorrow, at least for
> me.

The deadline for student proposals has been extended to April 7th; all
other dates move forward one week to acommodate.

This is a good time to update existing applications or submit new ones. 
Talk to your (potential) mentors if you are curious.






From nthery at gmail.com  Mon Mar 31 11:29:49 2008
From: nthery at gmail.com (Nicolas Thery)
Date: Mon, 31 Mar 2008 11:29:49 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
Message-ID: <64fc43b0803311126na7d0b27obaa9d35bac6d32ee@mail.gmail.com>

Hello,

Now that the release is over, I'll try to get rid of zones and migrate
allocations to objcache.

Here is a 1st patch that migrate struct proc.  I'll commit it in a
couple of days if nobody objects.

I'm also implementing a way to monitor objcache statistics.  So far,
I've hacked sth similar to
sysctl vm.zone: stats are returned in one giant string, one line per
cache.  That's simple but ugly and hard to read because there are
quite a few stats per cache.

So I'm thinking about implementing a small tool, ocstat, that extracts
stats from sysctl the way ps(1) does (thru libkvm iirc) and formats it
in various ways.  What do you think?

Cheers,
Nicolas

Index: src2/sys/kern/kern_exit.c
===================================================================
--- src2.orig/sys/kern/kern_exit.c	2008-03-31 08:05:59.139796000 +0200
+++ src2/sys/kern/kern_exit.c	2008-03-31 10:31:39.000000000 +0200
@@ -834,7 +834,7 @@ loop:
 			}

 			vm_waitproc(p);
-			zfree(proc_zone, p);
+			objcache_put(proc_cache, p);
 			nprocs--;
 			return (0);
 		}
Index: src2/sys/kern/kern_proc.c
===================================================================
--- src2.orig/sys/kern/kern_proc.c	2008-03-31 08:05:59.139918000 +0200
+++ src2/sys/kern/kern_proc.c	2008-03-31 10:31:39.000000000 +0200
@@ -84,7 +84,7 @@ u_long pgrphash;
 struct proclist allproc;
 struct proclist zombproc;
 struct spinlock allproc_spin;
-vm_zone_t proc_zone;
+struct objcache* proc_cache;
 vm_zone_t lwp_zone;
 vm_zone_t thread_zone;

@@ -131,7 +131,7 @@ procinit(void)
 	spin_init(&allproc_spin);
 	pidhashtbl = hashinit(maxproc / 4, M_PROC, &pidhash);
 	pgrphashtbl = hashinit(maxproc / 4, M_PROC, &pgrphash);
-	proc_zone = zinit("PROC", sizeof (struct proc), 0, 0, 5);
+	proc_cache = objcache_create_simple(M_PROC, sizeof(struct proc));
 	lwp_zone = zinit("LWP", sizeof (struct lwp), 0, 0, 5);
 	thread_zone = zinit("THREAD", sizeof (struct thread), 0, 0, 5);
 	uihashinit();
Index: src2/sys/sys/proc.h
===================================================================
--- src2.orig/sys/sys/proc.h	2008-03-31 08:05:59.140325000 +0200
+++ src2/sys/sys/proc.h	2008-03-31 10:31:39.000000000 +0200
@@ -473,7 +473,7 @@ struct proc *zpfind (pid_t);	/* Find zom
 struct vm_zone;
 struct globaldata;
 struct lwp_params;
-extern struct vm_zone *proc_zone;
+extern struct objcache *proc_cache;
 extern struct vm_zone *lwp_zone;

 int	enterpgrp (struct proc *p, pid_t pgid, int mksess);
Index: src2/sys/kern/kern_fork.c
===================================================================
--- src2.orig/sys/kern/kern_fork.c	2008-03-31 08:05:59.140042000 +0200
+++ src2/sys/kern/kern_fork.c	2008-03-31 10:31:39.000000000 +0200
@@ -332,7 +332,7 @@ fork1(struct lwp *lp1, int flags, struct
 	}

 	/* Allocate new proc. */
-	p2 = zalloc(proc_zone);
+	p2 = objcache_get(proc_cache, M_WAITOK);
 	bzero(p2, sizeof(*p2));

 	/*




From hsu at dragonflybsd.org  Mon Mar 31 11:44:34 2008
From: hsu at dragonflybsd.org (Jeffrey Hsu)
Date: Mon, 31 Mar 2008 11:44:34 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <64fc43b0803311126na7d0b27obaa9d35bac6d32ee@mail.gmail.com>
Message-ID: <200803311841.m2VIfQAI007579@nlpi001.prodigy.net>

The object cache is not a general-purpose memory allocator.  It's a cache of
pre-initialized objects.  Are the significant portions of the proc structure
that can be restored to initialized state on object puts?  If not, it's best
to just use a general-purpose memory allocator.

								Jeffrey




From corecode at fs.ei.tum.de  Mon Mar 31 12:07:02 2008
From: corecode at fs.ei.tum.de (Simon 'corecode' Schubert)
Date: Mon, 31 Mar 2008 12:07:02 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <200803311841.m2VIfQAI007579@nlpi001.prodigy.net>
Message-ID: <47F1357B.1070302@fs.ei.tum.de>

Jeffrey Hsu wrote:
> The object cache is not a general-purpose memory allocator.  It's a cache of
> pre-initialized objects.  Are the significant portions of the proc structure
> that can be restored to initialized state on object puts?  If not, it's best
> to just use a general-purpose memory allocator.

Why?  What's the loss if we use the object cache to allocate struct procs?

cheers
  simon

Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00006.pgp
Type: application/octet-stream
Size: 252 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080331/a4a24314/attachment-0015.obj>

From nthery at gmail.com  Mon Mar 31 12:17:03 2008
From: nthery at gmail.com (Nicolas Thery)
Date: Mon, 31 Mar 2008 12:17:03 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <nthery@gmail.com>
Message-ID: <64fc43b0803311214u7da6bbb8xaf971de1a80e7258@mail.gmail.com>

2008/3/31, Jeffrey Hsu <hsu at dragonflybsd.org>:
> The object cache is not a general-purpose memory allocator.  It's a cache of
>  pre-initialized objects.  Are the significant portions of the proc structure
>  that can be restored to initialized state on object puts?  If not, it's best
>  to just use a general-purpose memory allocator.

Well, I haven't checked this yet.  I planned to do this in a second
step after getting rid of zones.

I thought that even without  the pre-initialization part, objcache has
the advantage
of pre-allocating set of objects (as zones) and is additionally
mp-safe (contrary to zones and, granted, as malloc()).   The latter
may be interesting as we talk of improving MP support.

Cheers,
Nicolas




From dillon at apollo.backplane.com  Mon Mar 31 12:23:40 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Mon, 31 Mar 2008 12:23:40 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <200803311841.m2VIfQAI007579@nlpi001.prodigy.net>
Message-ID: <200803311921.m2VJLITB027669@apollo.backplane.com>

    I both agree and disagree with Jeff.  I think the only *disadvantage*
    to using objcache for struct proc is that objcache must cache a minimum
    number of free structures to be efficient so the overall kernel memory
    use would be a bit greater verses uses kmalloc().  But I agree with Jeff
    in that objcache's biggest advantage is that you can keep structural state
    intact and struct proc might not be a good candidate (yet).

    What I suggest is that you convert struct proc from zone to kmalloc
    first, and then look into a possible objcache adaptation.  kmalloc
    is not slow.. it's a very fast allocator.  Objcache is probably a tad
    faster but not by much.  Where objcache really wins is in not having
    to completey reinitialize the allocated structures.

    Over the years I've removed (I think) all the dependancies on requiring
    the proc structure to be in stable memory so I believe it can be moved to
    kmalloc/objcache now without any major pain.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From corecode at fs.ei.tum.de  Mon Mar 31 12:37:40 2008
From: corecode at fs.ei.tum.de (Simon 'corecode' Schubert)
Date: Mon, 31 Mar 2008 12:37:40 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: SoC student applications due by 5PM PDT tomorrow
In-Reply-To: <1942.192.168.0.242.1206930479.squirrel@www.shiningsilence.com>
Message-ID: <47F13CDA.6010703@fs.ei.tum.de>

Justin C. Sherrill wrote:
> On Sun, March 30, 2008 10:27 pm, Justin C. Sherrill wrote:
>> SoC students:
>>
>> If you have an application to submit for DragonFly/Summer of Code, please
>> do so by 17:00 Pacific time on the 31st - that's tomorrow, at least for
>> me.
> The deadline for student proposals has been extended to April 7th; all
> other dates move forward one week to acommodate.

This is very good.

Some more ideas for eager students (we want to keep the ratio, right?):

Enhance the FreeBSD/DragonFly sound infrastructure to support surround
sound/multichannel output.

Update sound drivers to support S/PDIF output.

Make the sound infrastructure OSSv4 compatible (there was a SoC at
FreeBSD last year or so)


of course only if it doesn't exist already :)

cheers
  simon


Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00007.pgp
Type: application/octet-stream
Size: 252 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080331/6da61cff/attachment-0015.obj>

From corecode at fs.ei.tum.de  Mon Mar 31 12:41:30 2008
From: corecode at fs.ei.tum.de (Simon 'corecode' Schubert)
Date: Mon, 31 Mar 2008 12:41:30 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <200803311841.m2VIfQAI007579@nlpi001.prodigy.net>
Message-ID: <47F13DE4.10205@fs.ei.tum.de>

Matthew Dillon wrote:
>     What I suggest is that you convert struct proc from zone to kmalloc
>     first, and then look into a possible objcache adaptation.  kmalloc
>     is not slow.. it's a very fast allocator.  Objcache is probably a tad
>     faster but not by much.  Where objcache really wins is in not having
>     to completey reinitialize the allocated structures.

Could we please not move to kmalloc, but instead try to move all fast
path allocations to objcache?  I don't like the idea of allocating
everything with kmalloc.  Caching struct procs is not a bad thing itself.

cheers
  simon


Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00008.pgp
Type: application/octet-stream
Size: 252 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080331/ac328c08/attachment-0015.obj>

From hsu at FreeBSD.org  Mon Mar 31 12:59:05 2008
From: hsu at FreeBSD.org (Jeffrey Hsu)
Date: Mon, 31 Mar 2008 12:59:05 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <47F1357B.1070302@fs.ei.tum.de>
Message-ID: <200803311920.m2VJK5Ln018015@nlpi015.prodigy.net>

The object cache sits on top of a general-purpose memory allocator such
as kmalloc or zalloc and provides pre-initialized object caching functionality.
If you're not going to use the object caching functionality, you can just
call the underlying memory allocator directly.

							Jeffrey




From dillon at apollo.backplane.com  Mon Mar 31 16:17:19 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Mon, 31 Mar 2008 16:17:19 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <200803311841.m2VIfQAI007579@nlpi001.prodigy.net>
Message-ID: <200803312311.m2VNBumd029866@apollo.backplane.com>

:Could we please not move to kmalloc, but instead try to move all fast
:path allocations to objcache?  I don't like the idea of allocating
:everything with kmalloc.  Caching struct procs is not a bad thing itself.=
:
:
:cheers
:  simon

    I will state for the record that I'm fine with either objcache or
    kmalloc.  I agree with Jeff that using objcache for struct proc
    probably isn't necessary but I also agree that it would not hurt either,
    and if the intent is to optimize the initialization of the proc
    structure in the future then moving to objcache now would save us
    from having to do it later.

    So whichever method Nicolas wants to use is fine with me.

						-Matt




From hsu at dragonflybsd.org  Mon Mar 31 19:22:47 2008
From: hsu at dragonflybsd.org (Jeffrey Hsu)
Date: Mon, 31 Mar 2008 19:22:47 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <64fc43b0803311214u7da6bbb8xaf971de1a80e7258@mail.gmail.com>
Message-ID: <200804010218.m312IVUq003624@nlpi043.prodigy.net>

  >> Are there significant portions of the proc structure
  >> that can be restored to initialized state on object puts?

  > I planned to do this in a second step after getting rid of zones.

I'll all in favor of making more use of caching pre-initialized objects, so
if this is your objective, then please go ahead.  It's just that I'd convert
over to the object cache in one step.

  > I thought that even without  the pre-initialization part, objcache has
  > the advantage of pre-allocating set of objects (as zones) and is additionally
  > mp-safe (contrary to zones and, granted, as malloc()).

Well, the zone allocator is MP-safe.  It's not hard to lock up the places that
manipulate the linked-list of free items. Look for uses of the zlock field.

								Jeffrey




From tgen at netphreax.net  Sat Mar  1 12:57:53 2008
From: tgen at netphreax.net (Thomas E. Spanjaard)
Date: Sat, 1 Mar 2008 12:57:53 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: [Fwd: Project Support Open Source: $50 donation to support you      project]
In-Reply-To: <2468.192.168.0.242.1204346451.squirrel@www.shiningsilence.com>
Message-ID: <47C9C1B7.50203@netphreax.net>

Justin C. Sherrill wrote:
The "donation" happens after you place an "acknowledgement" on an open
source project's web page.  I'm putting those words in scare quotes
because I think it's a "payment" for an "advertisement".  The supplied
link has nothing to do with DragonFly, to say the least.

<a href="http://www.2insure4less.com /" title="We support FOSS software
projects.">Online Insurance Quotes</a>
To think our souls are only worth $50...
--
        Thomas E. Spanjaard
        tgen at netphreax.net
Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00000.pgp
Type: application/octet-stream
Size: 186 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080301/0d61e240/attachment-0016.obj>

From c.turner at 199technologies.org  Sat Mar  1 17:52:31 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Sat, 1 Mar 2008 17:52:31 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Misc. ACPI / suspend
Message-ID: <47CA073B.6020106@199technologies.org>

Wondering if anyone more well versed in the ACPI implementation could
comment on the applicability of:
http://lkml.org/lkml/2007/4/6/69

w/r/t the current state of the art in Dfly

(or BSD's in general)

Cheers!

- Chris




From elekktretterr at exemail.com.au  Sun Mar  2 00:41:25 2008
From: elekktretterr at exemail.com.au (Petr Janda)
Date: Sun, 2 Mar 2008 00:41:25 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: CARP question
Message-ID: <200803021934.21669.elekktretterr@exemail.com.au>

So Ive setup CARP on 2 DF-based mailservers. Installation went fine. Box 1 has 
adskew of 0 therefore it is the MASTER. Box 2 has adskew of 254, therefore is 
BACKUP.  If i down the carp0 interface on Box 1, then Box 2 carp interface 
gets promoted to MASTER. Then I up the carp interface on Box 1, logically Box 
2 should become BACKUP again as Box 1 becomes MASTER due to adskew set to 0.

However it doesnt happen. When carp0 interface on Box 1 is upped it becomes a 
BACKUP, not a MASTER even though according to adskew it should be MASTER.

What is the desired behaviour?

Cheers
Petr




From qhwt+dfly at les.ath.cx  Sun Mar  2 02:50:14 2008
From: qhwt+dfly at les.ath.cx (YONETANI Tomokazu)
Date: Sun, 2 Mar 2008 02:50:14 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: panic: assertion: hammer_btree_cmp(cursor->left_bound,	&cursor->node->ondisk->elms[0].leaf.base) <= 0 in btree_split_leaf
In-Reply-To: <200802232204.m1NM4cxd046264@apollo.backplane.com>
Message-ID: <20080302104554.GA22813@les.ath.cx>

Hi.
While trying to find a procedure to reliably reproduce the panic
I reported last time, I caught a different panic (uploaded at
 ~y0netan1/crash/9/ on my leaf account).  I wrote the following shell
script (make sure to edit variables DISKS and MOUNTPT before using this
script or it may trash your system):
  #!/bin/sh -ex
  DISKS="/dev/ad0s1f"
  MOUNTPT=/mnt/HAMMER

  cd /
  newfs_hammer -L TEST $DISKS
  for i in `seq 1 100`; do
	  mount_hammer $DISKS $MOUNTPT
	  /bin/rm -rf $MOUNTPT/??
	  (set +x; for x in `seq 1 10000`; do echo -n > $MOUNTPT/$x; done)
	  umount $MOUNTPT
  done

And the panic is triggered by rm command.
I'll try to see if it's possible to reproduce the last one without
unmounting then mounting the HAMMER fs.

Cheers.




From dillon at apollo.backplane.com  Sun Mar  2 13:25:33 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Sun, 2 Mar 2008 13:25:33 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: panic: assertion: hammer_btree_cmp(cursor->left_bound,	&cursor->node->ondisk->elms[0].leaf.base) <= 0 in btree_split_leaf
In-Reply-To: <200802232204.m1NM4cxd046264@apollo.backplane.com>
Message-ID: <200803022119.m22LJRCY037076@apollo.backplane.com>


:Hi.
:While trying to find a procedure to reliably reproduce the panic
:I reported last time, I caught a different panic (uploaded at
: ~y0netan1/crash/9/ on my leaf account).  I wrote the following shell
:script (make sure to edit variables DISKS and MOUNTPT before using this
:script or it may trash your system):

(from the core)

panic: assertion: node->lock.refs == 0 && node->ondisk == NULL in hammer_flush_buffer_nodes

    Yah, I've seen this failure.  Add a sync or two before the umount and
    tell me if it still occurs.  It's either a node reference leak somewhere
    or it is a race between bufdaemon and umount.  The assertions are really
    strict there precisely to catch those sorts of cases.

    Also note that the code to deal with a full HAMMMER filesystem has not
    been written yet (The failure you are reporting is unrelated to a full
    HAMMER filesystem, though, just mentioning it).

						-Matt





From dillon at apollo.backplane.com  Sun Mar  2 13:29:03 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Sun, 2 Mar 2008 13:29:03 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Misc. ACPI / suspend
In-Reply-To: <47CA073B.6020106@199technologies.org>
Message-ID: <200803022126.m22LQbfI037188@apollo.backplane.com>


:Wondering if anyone more well versed in the ACPI implementation could
:comment on the applicability of:
:
:http://lkml.org/lkml/2007/4/6/69
:
:w/r/t the current state of the art in Dfly
:
:(or BSD's in general)
:
:Cheers!
:
:- Chris

    I really have no idea re: this.  Suspension in general is not well
    supported by any of the BSDs.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From dillon at apollo.backplane.com  Sun Mar  2 13:34:05 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Sun, 2 Mar 2008 13:34:05 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: [Fwd: Project Support Open Source: $50 donation to support you      project]
In-Reply-To: <2468.192.168.0.242.1204346451.squirrel@www.shiningsilence.com>
Message-ID: <200803022131.m22LVOe9037250@apollo.backplane.com>

:..
:source project's web page.  I'm putting those words in scare quotes
:because I think it's a "payment" for an "advertisement".  The supplied
:link has nothing to do with DragonFly, to say the least.
:
:I don't think this is a good idea, obviously, and replied to that effect. 
:However, I wanted to put this on a DragonFly list, in part to show this
:strange thing, and in part because I'm not comfortable making
:administrative decisions on behalf of the Project without being open as
:possible about it.

    It doesn't really cry out to me either.

						-Matt





From wbh at conducive.org  Sun Mar  2 20:36:32 2008
From: wbh at conducive.org (Bill Hacker)
Date: Mon, 03 Mar 2008 04:36:32 +0000
Subject: Misc. ACPI / suspend
In-Reply-To: <47CA073B.6020106@199technologies.org>
Message-ID: <47cb8050$0$855$415eb37d@crater_reader.dragonflybsd.org>

Matthew Dillon wrote:
:Wondering if anyone more well versed in the ACPI implementation could
:comment on the applicability of:
:
:http://lkml.org/lkml/2007/4/6/69
:
:w/r/t the current state of the art in Dfly
:
:(or BSD's in general)
:
:Cheers!
:
:- Chris
    I really have no idea re: this.  Suspension in general is not well
    supported by any of the BSDs.
					-Matt
					Matthew Dillon 
					<dillon at backplane.com>


. . and there seems to be a bit of a 'Catch 22' there in any case.

If the BIOS can alter 'stuff' out of site of the OS it is parking, what 
does the existence of such a 'feature' do to a(ny) security model?

Seems to at least beg creating the option of setting a flag to 
specifically *prevent* suspend-to-disk/hibernation (and/or force a 
reboot on wake-up).

Just because one is paranoid....  etc

Bill





From matthias at dragonflybsd.org  Tue Mar  4 02:30:52 2008
From: matthias at dragonflybsd.org (Matthias Schmidt)
Date: Tue, 4 Mar 2008 02:30:52 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
Message-ID: <20080304102335.GI9833@staatsfeind.org>

Hi,

Google just announced its Summer of Code for 2008:

	http://code.google.com/soc/2008/

I think this would be a great opportunity for DragonFly to participate
as a mentoring organisation.  We could attract new developers and could
get code/work done.  Looking at the SoC results of the other BSDs most
of their projects were a success.  Of course, not all, but a reasonable
percentage.  See [1] and [2].

It is some extra work for us, but IMO the benefits outweigh the extra
work.  And yes, I would volunteer as a mentor.  What do others
(developers) think?  Any more volunteers? :)

Some project ideas that come into my mind.  More ideas are listed in the
wiki:  http://wiki.dragonflybsd.org/index.cgi/ProjectsPage

 * Fix all remaining bugs in dma(8) and implement all missing features
 * Add a driver for newer Intel Wireless cards (I think sephe@ would
   love that :)
 * Bring our ACPI stuff in shape.  Maybe suspend2disk ...

 * [Add your own thoughts here]

Cheers,

	Matthias

PS: I don't want to create a bikeshed here whether you like the SoC or
not :)

[1] http://code.google.com/soc/2007/freebsd/about.html
[2] http://code.google.com/soc/2007/netbsd/about.html




From corecode at fs.ei.tum.de  Tue Mar  4 04:46:14 2008
From: corecode at fs.ei.tum.de (Simon 'corecode' Schubert)
Date: Tue, 4 Mar 2008 04:46:14 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47CD4386.1000704@fs.ei.tum.de>

Matthias Schmidt wrote:
>  * [Add your own thoughts here]

MP lock removal for network stack

and for the system  (first profile, find hot spots, fix hot spots, repeat)

cheers
  simon




From c.turner at 199technologies.org  Tue Mar  4 06:02:20 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Tue, 4 Mar 2008 06:02:20 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47CD551E.1040604@199technologies.org>

Matthias Schmidt wrote:
Some project ideas that come into my mind.  More ideas are listed in the
wiki:  http://wiki.dragonflybsd.org/index.cgi/ProjectsPage
+1 acpi
+1 interrupt routing
+1 SMP / giant removal
+1 pf synchup with openbsd
though there are several others on the page that are good..

need to dig up my wiki login and place appropriately..

also: thinking the ZFS port should be removed from the page - makes 
sense to everyone else? (e.g. fragments effort w/r/t hammer)





From tgen at netphreax.net  Tue Mar  4 06:54:31 2008
From: tgen at netphreax.net (Thomas E. Spanjaard)
Date: Tue, 4 Mar 2008 06:54:31 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47CD615F.8010209@netphreax.net>

Matthias Schmidt wrote:
Google just announced its Summer of Code for 2008:

 * [Add your own thoughts here]
x86-64 port :).
--
        Thomas E. Spanjaard
        tgen at netphreax.net
Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00001.pgp
Type: application/octet-stream
Size: 186 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080304/0d921000/attachment-0016.obj>

From rdivacky at FreeBSD.org  Tue Mar  4 07:07:03 2008
From: rdivacky at FreeBSD.org (Roman Divacky)
Date: Tue, 4 Mar 2008 07:07:03 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <20080304150255.GA8831@freebsd.org>

On Tue, Mar 04, 2008 at 02:49:03PM +0000, Thomas E. Spanjaard wrote:
> Matthias Schmidt wrote:
> >Google just announced its Summer of Code for 2008:
> >
> > * [Add your own thoughts here]
> 
> x86-64 port :).

all those ideas are great and needed etc. but keep in
mind that the projects should be doable by students
who might see dfly for the very first time.

don't overestimate whats possible and select projects
that look realistic

Roman Divacky (former SoC student)




From justin at shiningsilence.com  Tue Mar  4 08:32:56 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Tue, 4 Mar 2008 08:32:56 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <60322.65.106.147.226.1204648095.squirrel@www.shiningsilence.com>

On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
> Hi,
>
> Google just announced its Summer of Code for 2008:
>
> 	http://code.google.com/soc/2008/
>
> I think this would be a great opportunity for DragonFly to participate
> as a mentoring organisation.  We could attract new developers and could
> get code/work done.  Looking at the SoC results of the other BSDs most
> of their projects were a success.  Of course, not all, but a reasonable
> percentage.  See [1] and [2].

We've applied in previous years - Jeff Hsu did one year, and I put
together the application last year.  The hardest thing to find was
students (and they are the thing that helps SoC applications a lot, I
think).

Any student volunteers?  We have mentors.





From rluciani at gmail.com  Tue Mar  4 09:38:29 2008
From: rluciani at gmail.com (Robert Luciani)
Date: Tue, 04 Mar 2008 18:38:29 +0100
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47cd8915$0$854$415eb37d@crater_reader.dragonflybsd.org>

Justin C. Sherrill wrote:
> On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
>> Hi,
>>
>> Google just announced its Summer of Code for 2008:
>>
>> 	http://code.google.com/soc/2008/
>>
>> I think this would be a great opportunity for DragonFly to participate
>> as a mentoring organisation.  We could attract new developers and could
>> get code/work done.  Looking at the SoC results of the other BSDs most
>> of their projects were a success.  Of course, not all, but a reasonable
>> percentage.  See [1] and [2].
> 
> We've applied in previous years - Jeff Hsu did one year, and I put
> together the application last year.  The hardest thing to find was
> students (and they are the thing that helps SoC applications a lot, I
> think).
> 
> Any student volunteers?  We have mentors.
> 

bingo

-- 
Robert Luciani
Chalmers University of Technology, SWE
Department of Computer Science and Engineering
http://www.rluciani.com/public.key




From sdavtaker at gmail.com  Tue Mar  4 09:31:08 2008
From: sdavtaker at gmail.com (=?UTF-8?Q?Sd=C3=A4vtaker?=)
Date: Tue, 4 Mar 2008 09:31:08 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <c37d69f60803040926k206218a3kb8496d0cd18148bd@mail.gmail.com>

If you mentor, i will apply for coder :-)
Still in last year of university. :-)
Sdav

On Tue, Mar 4, 2008 at 1:28 PM, Justin C. Sherrill
<justin at shiningsilence.com> wrote:
> On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
>  > Hi,
>  >
>  > Google just announced its Summer of Code for 2008:
>  >
>  >       http://code.google.com/soc/2008/
>  >
>  > I think this would be a great opportunity for DragonFly to participate
>  > as a mentoring organisation.  We could attract new developers and could
>  > get code/work done.  Looking at the SoC results of the other BSDs most
>  > of their projects were a success.  Of course, not all, but a reasonable
>  > percentage.  See [1] and [2].
>
>  We've applied in previous years - Jeff Hsu did one year, and I put
>  together the application last year.  The hardest thing to find was
>  students (and they are the thing that helps SoC applications a lot, I
>  think).
>
>  Any student volunteers?  We have mentors.
>
>



-- 
Sd?vtaker prays to Rikku goddess for a good treasure.



From rluciani at gmail.com  Tue Mar  4 09:44:02 2008
From: rluciani at gmail.com (Robert Luciani)
Date: Tue, 04 Mar 2008 18:44:02 +0100
Subject: google soc "DragonFly"
Message-ID: <47cd8a63$0$855$415eb37d@crater_reader.dragonflybsd.org>

On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
> > Hi,
> >
> > Google just announced its Summer of Code for 2008:
> >
> > 	http://code.google.com/soc/2008/
> >
> > I think this would be a great opportunity for DragonFly to participate
> > as a mentoring organisation.  We could attract new developers and could
> > get code/work done.  Looking at the SoC results of the other BSDs most
> > of their projects were a success.  Of course, not all, but a reasonable
> > percentage.  See [1] and [2].

We've applied in previous years - Jeff Hsu did one year, and I put
together the application last year.  The hardest thing to find was
students (and they are the thing that helps SoC applications a lot, I
think).

Any student volunteers?  We have mentors.


-- 
Robert Luciani
Chalmers University of Technology, SWE
Department of Computer Science and Engineering
http://www.rluciani.com/public.key




From rluciani at gmail.com  Tue Mar  4 10:04:14 2008
From: rluciani at gmail.com (Robert Luciani)
Date: Tue, 04 Mar 2008 19:04:14 +0100
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47cd8f1f$0$856$415eb37d@crater_reader.dragonflybsd.org>

Robert Luciani wrote:
> Justin C. Sherrill wrote:
>> On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
>>> Hi,
>>>
>>> Google just announced its Summer of Code for 2008:
>>>
>>> 	http://code.google.com/soc/2008/
>>>
>>> I think this would be a great opportunity for DragonFly to participate
>>> as a mentoring organisation.  We could attract new developers and could
>>> get code/work done.  Looking at the SoC results of the other BSDs most
>>> of their projects were a success.  Of course, not all, but a reasonable
>>> percentage.  See [1] and [2].
>> We've applied in previous years - Jeff Hsu did one year, and I put
>> together the application last year.  The hardest thing to find was
>> students (and they are the thing that helps SoC applications a lot, I
>> think).
>>
>> Any student volunteers?  We have mentors.
>>
> 
> bingo
> 
My girlfriend Danwei noted that she would also like partake in the SoC.
She's studying IT here at Chalmers and will join the mailing list shortly.
-- 
Robert Luciani
Chalmers University of Technology, SWE
Department of Computer Science and Engineering
http://www.rluciani.com/public.key




From dillon at apollo.backplane.com  Tue Mar  4 13:08:30 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Tue, 4 Mar 2008 13:08:30 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Going to have to roll 1.12.1
Message-ID: <200803042104.m24L43g1065278@apollo.backplane.com>

    Due to a critical bug in sendmail that can cause it to seg-fault I will
    be rolling 1.12.1 as soon as I get verification that the current
    fix deals with it.

						-Matt





From sdavtaker at gmail.com  Tue Mar  4 17:40:43 2008
From: sdavtaker at gmail.com (=?UTF-8?B?U2TDpHZ0YWtlcg==?=)
Date: Tue, 4 Mar 2008 17:40:43 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: [Fwd: Project Support Open Source: $50 donation to support you  project]
In-Reply-To: <2468.192.168.0.242.1204346451.squirrel@www.shiningsilence.com>
Message-ID: <47CDF8D1.9070100@gmail.com>

50 bucks?
Come on...
You can get a meal a lot more expensive than that just going to a free 
HP conference about linux and you only have to rent your soul 3-5 hours ;-)
Sdav

Matthew Dillon escribi?:
:..
:source project's web page.  I'm putting those words in scare quotes
:because I think it's a "payment" for an "advertisement".  The supplied
:link has nothing to do with DragonFly, to say the least.
:
:I don't think this is a good idea, obviously, and replied to that effect. 
:However, I wanted to put this on a DragonFly list, in part to show this
:strange thing, and in part because I'm not comfortable making
:administrative decisions on behalf of the Project without being open as
:possible about it.

    It doesn't really cry out to me either.

						-Matt

  






From sdavtaker at gmail.com  Tue Mar  4 17:56:35 2008
From: sdavtaker at gmail.com (=?UTF-8?B?U2TDpHZ0YWtlcg==?=)
Date: Tue, 4 Mar 2008 17:56:35 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47CDFCCE.1010106@gmail.com>

A cute idea for for GSOC would be to finish the installer.
We were talking about this in my local BUG, we trying to find out how to 
help on that from here.
There is a few missing features in the CD.

   * FDISK, you need to create the slides from another OS before
     install DFBSD, i think port FDisk from FBSD or any *BSD will solve it.
   * Add to the make release a way to add some custom applications to
     the released liveCD (suppose you want to add nmap or ssh or
     something just to use as test disk in some enviroment).
   * Make the installer a little more customizable, and maybe w/ a GUI
     (I like a lot the console approach, but GUI installer will be a
     popularity move, DFBSD w/X makes a Desktop machine work, actually
     im using it that way and really like it).
I think those projects can be done in a SOC by students (like me) with a 
little guide.
Im a lot more interested in things network related and kernel, but i 
dont mind to work on those things, they need to be done some day.
What u think?
Sdav

Robert Luciani escribi?:
Robert Luciani wrote:
  
Justin C. Sherrill wrote:
    
On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
      
Hi,

Google just announced its Summer of Code for 2008:

	http://code.google.com/soc/2008/

I think this would be a great opportunity for DragonFly to participate
as a mentoring organisation.  We could attract new developers and could
get code/work done.  Looking at the SoC results of the other BSDs most
of their projects were a success.  Of course, not all, but a reasonable
percentage.  See [1] and [2].
        
We've applied in previous years - Jeff Hsu did one year, and I put
together the application last year.  The hardest thing to find was
students (and they are the thing that helps SoC applications a lot, I
think).
Any student volunteers?  We have mentors.

      
bingo

    
My girlfriend Danwei noted that she would also like partake in the SoC.
She's studying IT here at Chalmers and will join the mailing list shortly.
  






From c.turner at 199technologies.org  Tue Mar  4 18:30:53 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Tue, 4 Mar 2008 18:30:53 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47CE04C9.1010902@199technologies.org>

Justin C. Sherrill wrote:
together the application last year.  The hardest thing to find was
students (and they are the thing that helps SoC applications a lot, I
think).
umm.. if google wants to send me back to school, I'll sign up - hows 
that for a fair trade :?






From wbh at conducive.org  Tue Mar  4 23:52:13 2008
From: wbh at conducive.org (Bill Hacker)
Date: Wed, 05 Mar 2008 07:52:13 +0000
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47ce512e$0$855$415eb37d@crater_reader.dragonflybsd.org>

Sd?vtaker wrote:
A cute idea for for GSOC would be to finish the installer.
We were talking about this in my local BUG, we trying to find out how to 
help on that from here.
There is a few missing features in the CD.

   * FDISK, you need to create the slides from another OS before
     install DFBSD, i think port FDisk from FBSD or any *BSD will solve it.
I'd rather see that 'reversed' - i.e. - build a more capable fdisk in 
DFLY with hope that it might be seen worth importing into Free/Net/Open, 
or *at least* be able to do a more flexible job than those now do.

And disklabels as well. Hand in glove.

Here's why:

- At the moment, working with Free, Open, DFLY, and OpenSolaris on the 
same HDD requires a bit of acrobatics.

- There seems to now be greater divergence between/among the *BSD's as 
to being able to read each other's disklabels, mount and use each 
other's 'flavor' of FFS/UFS (not to mention Apple's implementation of 
UFS) than there is among the vast multitude of Linux ext2/3 denizens.

Even to the point where use of a *Linux* fs is the more universal way 
for being able to share mounts among the *BSD's. Think detached drives. 
And no - FAT is not all that practical for several reasons.

- DFLY currently has the most fine-grain ability to create slices and 
partitions. But the others cannot all (any?) read those.

'progress' w/r any of the *BSD's direction as to changes, improvements 
(or not) in their once-common-ancestry fs & disklabels need not be 
sacrificed.

I'm not holding out wish or hope for all players agreeing to return to 
'one sacred way'. Nor 'one new universal fs'. Neither is gonna happen.

But a 'legacy compatible' or least-common-denominator mode would do fine 
- most especially for portable / SAN devices.

So - how about a 'flexible' DFLY fdisk to go along with a 'flexible' 
disklabel that could adapt to whatever it found / was told to create?

JM2CW - but that *might* be a good place to get a cross-*BSD team together.

*snip* (other good stuff)

Bill Hacker




From matthias at dragonflybsd.org  Wed Mar  5 01:02:43 2008
From: matthias at dragonflybsd.org (Matthias Schmidt)
Date: Wed, 5 Mar 2008 01:02:43 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <20080305085747.GJ9833@staatsfeind.org>

Hi,

* Justin C. Sherrill wrote:
> 
> We've applied in previous years - Jeff Hsu did one year, and I put
> together the application last year.  The hardest thing to find was
> students (and they are the thing that helps SoC applications a lot, I
> think).

This is good to know, so we could coordinate that if we have enough
mentors and projects?!?  I put together a small text in the wiki:

http://wiki.dragonflybsd.org/index.cgi/GoogleSoC2008

Feel free to add project or missing stuff.  I'm sure I missed a lot of
things :)

> Any student volunteers?  We have mentors.

According to the discussion we could have some students, who would be a
mentor (besides me)?

Regards

	Matthias





From sdavtaker at gmail.com  Wed Mar  5 06:28:37 2008
From: sdavtaker at gmail.com (=?UTF-8?Q?Sd=C3=A4vtaker?=)
Date: Wed, 5 Mar 2008 06:28:37 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <c37d69f60803050624kd86d3d0w3b44a02d0e5a5391@mail.gmail.com>

<quote>
Write a driver (from scratch) for Intel 3945 wireless device
Mentor: Sepherosa Ziehau
</quote>

Yes yes yes, i want to :-)
Someone else planning to mentor in drivers coding?
Sdav

On Wed, Mar 5, 2008 at 5:57 AM, Matthias Schmidt
<matthias at dragonflybsd.org> wrote:
> Hi,
>
>
>  * Justin C. Sherrill wrote:
>  >
>  > We've applied in previous years - Jeff Hsu did one year, and I put
>  > together the application last year.  The hardest thing to find was
>  > students (and they are the thing that helps SoC applications a lot, I
>  > think).
>
>  This is good to know, so we could coordinate that if we have enough
>  mentors and projects?!?  I put together a small text in the wiki:
>
>  http://wiki.dragonflybsd.org/index.cgi/GoogleSoC2008
>
>  Feel free to add project or missing stuff.  I'm sure I missed a lot of
>  things :)
>
>
>  > Any student volunteers?  We have mentors.
>
>  According to the discussion we could have some students, who would be a
>  mentor (besides me)?
>
>  Regards
>
>         Matthias
>
>



-- 
Sd?vtaker prays to Rikku goddess for a good treasure.



From rluciani at gmail.com  Wed Mar  5 10:56:42 2008
From: rluciani at gmail.com (Robert Luciani)
Date: Wed, 05 Mar 2008 19:56:42 +0100
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47ceecea$0$847$415eb37d@crater_reader.dragonflybsd.org>

Sd?vtaker wrote:
> <quote>
> Write a driver (from scratch) for Intel 3945 wireless device
> Mentor: Sepherosa Ziehau
> </quote>
> 
> Yes yes yes, i want to :-)
> Someone else planning to mentor in drivers coding?
> Sdav
> 
> On Wed, Mar 5, 2008 at 5:57 AM, Matthias Schmidt
> <matthias at dragonflybsd.org> wrote:
>> Hi,
>>
>>
>>  * Justin C. Sherrill wrote:
>>  >
>>  > We've applied in previous years - Jeff Hsu did one year, and I put
>>  > together the application last year.  The hardest thing to find was
>>  > students (and they are the thing that helps SoC applications a lot, I
>>  > think).
>>
>>  This is good to know, so we could coordinate that if we have enough
>>  mentors and projects?!?  I put together a small text in the wiki:
>>
>>  http://wiki.dragonflybsd.org/index.cgi/GoogleSoC2008
>>
>>  Feel free to add project or missing stuff.  I'm sure I missed a lot of
>>  things :)
>>
>>
>>  > Any student volunteers?  We have mentors.
>>
>>  According to the discussion we could have some students, who would be a
>>  mentor (besides me)?
>>
>>  Regards
>>
>>         Matthias
>>
>>
> 
> 
>

IF someone starts to write a 3945 Intel driver,
please keep the newer 4965 in mind too.

-- 
Robert Luciani
Chalmers University of Technology, SWE
Department of Computer Science and Engineering
http://www.rluciani.com/public.key




From joerg at britannica.bec.de  Wed Mar  5 12:01:05 2008
From: joerg at britannica.bec.de (Joerg Sonnenberger)
Date: Wed, 5 Mar 2008 12:01:05 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <20080305195711.GA9981@britannica.bec.de>

On Wed, Mar 05, 2008 at 07:56:42PM +0100, Robert Luciani wrote:
> IF someone starts to write a 3945 Intel driver,
> please keep the newer 4965 in mind too.

NetBSD's wpi works quite well. The hardware is quite different from
4945.

Joerg




From sepherosa at gmail.com  Wed Mar  5 17:48:50 2008
From: sepherosa at gmail.com (Sepherosa Ziehau)
Date: Wed, 5 Mar 2008 17:48:50 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <ea7b9c170803051744u22b09484ofc994f034f11df3b@mail.gmail.com>

On Thu, Mar 6, 2008 at 2:56 AM, Robert Luciani <rluciani at gmail.com> wrote:
>  IF someone starts to write a 3945 Intel driver,

"IF" you know that trying to fix any wired bugs in certain drivers
(e.g. ipw, ral) will require you to read through all of the vendor's
linux code (yes, even including register values and position), i.e.
there is not much difference between writing one from scratch and
porting+fixing_bugs, then you probably will not put "IF" at the start
of your sentence.
If what I said sounded too harsh to you, then I was sorry.

>  please keep the newer 4965 in mind too.

Will do, once generic 11n support is brought in from freebsd.

Best Regards,
sephe

-- 
Live Free or Die




From saw at online.de  Thu Mar  6 05:34:14 2008
From: saw at online.de (Sascha Wildner)
Date: Thu, 06 Mar 2008 14:34:14 +0100
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
Message-ID: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>

Hi all,

this is probably as good a moment as any to come out of the forest with 
this. The patch at

http://leaf.dragonflybsd.org/~swildner/nrelease_gui.diff

adds some code to nrelease/ to build a LiveCD with xorg and so on 
(currently, only the xorg metapackages and fluxbox are added). In order 
to build one, you need a local dir with the pkgsrc binary packages (see 
below).

The following commands should then do the trick:

cd /usr/src
make buildworld
make buildkernel
cd nrelease
patch -p 0 </path/to/the/patch
make PKGSRC_PKG_PATH=/path/to/packages/dir/All realquick gui
The resulting ISO will be in /usr/release/dfly-gui.iso then. It will not 
boot into xorg automatically (although this is easily possible), so you 
need to login as root and do startx.

As of now, this all is kind of basic, more a proof of concept than 
anything else. As our release framework installs packages via chroot, 
the current setup just copies _all_ packages to the chroot before 
installing (kind of a hack).

That said, I'm now primarily interested in opinions/ideas/... about the 
direction this should take. Which packages would we like to see on the 
CD? Should it be a generic setup with the "most common things" 
installed, so a system can be quickly setup by the installer (which will 
cpdup /usr/pkg). Or should it be a more specialized set of tools? Or 
even as many packages as possible (Live DVD?). Etc., etc.

Before continuing on it, I'm really interested in people's input so 
don't hold anything back, please. :)

Sascha

--
http://yoyodyne.ath.cx



From rluciani at gmail.com  Thu Mar  6 06:42:03 2008
From: rluciani at gmail.com (Robert Luciani)
Date: Thu, 06 Mar 2008 15:42:03 +0100
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <47d002bc$0$847$415eb37d@crater_reader.dragonflybsd.org>

Sascha Wildner wrote:
> Hi all,
> 
> this is probably as good a moment as any to come out of the forest with
> this. The patch at
> 
> http://leaf.dragonflybsd.org/~swildner/nrelease_gui.diff
> 
> adds some code to nrelease/ to build a LiveCD with xorg and so on
> (currently, only the xorg metapackages and fluxbox are added). In order
> to build one, you need a local dir with the pkgsrc binary packages (see
> below).
> 
> The following commands should then do the trick:
> 
> cd /usr/src
> make buildworld
> make buildkernel
> cd nrelease
> patch -p 0 </path/to/the/patch
> make PKGSRC_PKG_PATH=/path/to/packages/dir/All realquick gui
> 
> The resulting ISO will be in /usr/release/dfly-gui.iso then. It will not
> boot into xorg automatically (although this is easily possible), so you
> need to login as root and do startx.
> 
> As of now, this all is kind of basic, more a proof of concept than
> anything else. As our release framework installs packages via chroot,
> the current setup just copies _all_ packages to the chroot before
> installing (kind of a hack).
> 
> That said, I'm now primarily interested in opinions/ideas/... about the
> direction this should take. Which packages would we like to see on the
> CD? Should it be a generic setup with the "most common things"
> installed, so a system can be quickly setup by the installer (which will
> cpdup /usr/pkg). Or should it be a more specialized set of tools? Or
> even as many packages as possible (Live DVD?). Etc., etc.
> 
> Before continuing on it, I'm really interested in people's input so
> don't hold anything back, please. :)
> 
> Sascha
> 

I think the main point of such a live-cd would be to test
dragonfly-specific features such as vkernels and more. Mplayer and
OpenOffic work the same on all platforms, so they might not be super
important, while irssi, firefox, networking tools, vim, a few more
shells/terminals might make it easier to for people to quickly gauge if
they can reproduce their current productivity and also what is new.

And if the point of a livecd is to test that kind of stuff, then it
would be nice for it to have a kernel that supports as much as possible
like ALTQ, and drivers.

Also if it has lots and lots of programs (thinking multimedia, java,
etc..) it might be hard to keep the future x64 and x86 live-cds on par.
Gentoo had this problem many years ago and it was very bothersome.

-- 
Robert Luciani
Chalmers University of Technology, SWE
Department of Computer Science and Engineering
http://www.rluciani.com/public.key




From matthias at dragonflybsd.org  Thu Mar  6 07:12:43 2008
From: matthias at dragonflybsd.org (Matthias Schmidt)
Date: Thu, 6 Mar 2008 07:12:43 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <20080306150757.GN9833@staatsfeind.org>

* Sascha Wildner wrote:
> Hi all,
> 
> this is probably as good a moment as any to come out of the forest with this. 
> The patch at
> 
> http://leaf.dragonflybsd.org/~swildner/nrelease_gui.diff
> 
> adds some code to nrelease/ to build a LiveCD with xorg and so on (currently, 
> only the xorg metapackages and fluxbox are added). In order to build one, you 
> need a local dir with the pkgsrc binary packages (see below).

Great work Sascha.

I agree with Robert on most of his stated points.
It would be nice to see some DragonFly specific features on the CD
(although I'm not sure if that will work for all features).  A little
environment where most Unix users feel at home (fluxbox, xfce, firefox,
thunderbird, gvim) should be enough.

Big applications like OO.org, java etc won't work because they are not
available as pkgsrc packages neither is it possible to compile them on
DragonFly.  At least to my knowledge.

Regards

	Matthias




From dillon at apollo.backplane.com  Thu Mar  6 09:31:52 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Thu, 6 Mar 2008 09:31:52 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <200803061728.m26HSR3O091809@apollo.backplane.com>


:Hi all,
:
:this is probably as good a moment as any to come out of the forest with 
:this. The patch at
:
:http://leaf.dragonflybsd.org/~swildner/nrelease_gui.diff
:
:adds some code to nrelease/ to build a LiveCD with xorg and so on 
:(currently, only the xorg metapackages and fluxbox are added). In order 
:to build one, you need a local dir with the pkgsrc binary packages (see 
:below).
:
:The following commands should then do the trick:

    It looks reasonable, though the package copy has to be tightened
    up a bit I think.

:...
:installed, so a system can be quickly setup by the installer (which will 
:cpdup /usr/pkg). Or should it be a more specialized set of tools? Or 
:even as many packages as possible (Live DVD?). Etc., etc.
:
:Before continuing on it, I'm really interested in people's input so 
:don't hold anything back, please. :)
:
:Sascha

    I think this is an excellent time to work up a DVD build and to
    add various 'flavor' extras.  So, e.g.:

	make installer gui gui_extras release dvd

    (All 'dvd' would do is generate a dvd compatible image for burning to
    dvd instead of cd).  I did a quick perusal of what I have on my
    workstation:

    * X
    * Firefox
    * Linux emulation
    * Open Office (linux version)
    * fvwm2
    * xpdf
    * freetype2

    I'd also suggest some image editing tools like gimp, and maybe the KDE
    gui suite.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From justin at shiningsilence.com  Thu Mar  6 09:42:44 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Thu, 6 Mar 2008 09:42:44 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <55427.65.106.147.226.1204825168.squirrel@www.shiningsilence.com>

On Thu, March 6, 2008 8:34 am, Sascha Wildner wrote:

> That said, I'm now primarily interested in opinions/ideas/... about the
> direction this should take. Which packages would we like to see on the
> CD? Should it be a generic setup with the "most common things"
> installed, so a system can be quickly setup by the installer (which will
> cpdup /usr/pkg). Or should it be a more specialized set of tools? Or
> even as many packages as possible (Live DVD?). Etc., etc.

What Robert said is good - whatever's needed to enable DragonFly-specific
features.  Along with that would be some sort of documentation (a README? 
A HTML file on whatever desktop we provide) that points people at the
different DragonFly tools, so they know what to try and how to try it.

There's going to be some percentage of people who try DragonFly who don't
know about vkernels, for instance, but there's our chance to educate them.
 I'm probably volunteering myself, aren't I?





From sdavtaker at gmail.com  Thu Mar  6 09:50:09 2008
From: sdavtaker at gmail.com (=?UTF-8?Q?Sd=C3=A4vtaker?=)
Date: Thu, 6 Mar 2008 09:50:09 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <c37d69f60803060947t110750c0sd6b542ea505d188d@mail.gmail.com>

Cool Sascha :-)
I just posted about this 1 or 2 days ago in the SOC project ideas thread.
Want to mentor this one? ;-)
Damian

On Thu, Mar 6, 2008 at 2:28 PM, Matthew Dillon
<dillon at apollo.backplane.com> wrote:
>
>  :Hi all,
>
> :
>  :this is probably as good a moment as any to come out of the forest with
>  :this. The patch at
>  :
>  :http://leaf.dragonflybsd.org/~swildner/nrelease_gui.diff
>  :
>  :adds some code to nrelease/ to build a LiveCD with xorg and so on
>  :(currently, only the xorg metapackages and fluxbox are added). In order
>  :to build one, you need a local dir with the pkgsrc binary packages (see
>  :below).
>  :
>  :The following commands should then do the trick:
>
>     It looks reasonable, though the package copy has to be tightened
>     up a bit I think.
>
>  :...
>  :installed, so a system can be quickly setup by the installer (which will
>
> :cpdup /usr/pkg). Or should it be a more specialized set of tools? Or
>  :even as many packages as possible (Live DVD?). Etc., etc.
>  :
>  :Before continuing on it, I'm really interested in people's input so
>  :don't hold anything back, please. :)
>  :
>  :Sascha
>
>     I think this is an excellent time to work up a DVD build and to
>     add various 'flavor' extras.  So, e.g.:
>
>         make installer gui gui_extras release dvd
>
>     (All 'dvd' would do is generate a dvd compatible image for burning to
>     dvd instead of cd).  I did a quick perusal of what I have on my
>     workstation:
>
>     * X
>     * Firefox
>     * Linux emulation
>     * Open Office (linux version)
>     * fvwm2
>     * xpdf
>     * freetype2
>
>     I'd also suggest some image editing tools like gimp, and maybe the KDE
>     gui suite.
>
>                                         -Matt
>                                         Matthew Dillon
>                                         <dillon at backplane.com>
>



-- 
Sd?vtaker prays to Rikku goddess for a good treasure.



From saw at online.de  Thu Mar  6 11:54:01 2008
From: saw at online.de (Sascha Wildner)
Date: Thu, 06 Mar 2008 20:54:01 +0100
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <47d04ba2$0$856$415eb37d@crater_reader.dragonflybsd.org>

Matthew Dillon wrote:
    It looks reasonable, though the package copy has to be tightened
    up a bit I think.
It looks as if it would work with mount_null'ing the chroot's 
/tmp/packages. I'll have a better patch ready tomorrow.

Sascha

--
http://yoyodyne.ath.cx



From c.turner at 199technologies.org  Thu Mar  6 19:11:44 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Thu, 6 Mar 2008 19:11:44 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Misc. ACPI / suspend
In-Reply-To: <47CA073B.6020106@199technologies.org>
Message-ID: <47D0B079.3060905@199technologies.org>

Chris Turner wrote:
Wondering if anyone more well versed in the ACPI implementation could
comment on the applicability of:
http://lkml.org/lkml/2007/4/6/69

Doing a little digging, it seems like

. /platform/pc32/i386/i686_mem.c

*might* have the necessary infrastructure to remap the MTRR's per the 
thread referenced,

but:

. /platform/pc32/acpica5/acpi_wakeup.c

doesn't seem to be using this infrastructure..

I'm no where near reaching an understanding of this yet,
but I'm wondering 3 things:
1) does anyone have ACPI (instead of APM)
   sleep / suspend / wakeup working on Dfly ?
2) If so, what machines are being used ?
3) Same question for other BSDs - my understanding is NetBSD is most
   'advanced' w/r/t power managment - but I'm not 100% on this ...
would looove to have a sleeping / resuming / scaling laptop running some 
BSD flavor.. am willing to work towards that end, esp. w/r/t Dfly -
trying to chart a course to figguring this out.

Thanks all,

- Chris




From c.turner at 199technologies.org  Thu Mar  6 19:12:33 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Thu, 6 Mar 2008 19:12:33 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: PCI Bios / Interrupt remapping / etc
Message-ID: <47D0B211.6000002@199technologies.org>

Doing a bit of digging here for my long-standing CBB+SIO interupt and 
buffer problem -

one machine I've tested against was an OpenBSD machine, which didn't
always work to handle the cardbus sio card on a PCI cardbus adapter
-

tuning up some of the device flags in:

http://www.openbsd.org/cgi-bin/man.cgi?query=pcibios&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=html

seems to have alleviated the problem for that os..

I'm just only starting to get up to speed on how DF handles these types 
of things (namely initial PIC / interrupt layout at boot time device 
enumeration), but am wondering if anyone familiar with this area of the 
code has any comments / advice w/r/t the capabilities of the DF bios 
drivers
and the various quirks / fixup mentioned in the link above..

looking to possibly investigate fixing up some of these issues over time.

Thanks

- Chris







From pavalos at theshell.com  Fri Mar  7 01:14:55 2008
From: pavalos at theshell.com (Peter Avalos)
Date: Fri, 7 Mar 2008 01:14:55 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: cam locking
Message-ID: <20080307091024.GC1652@ylem.theshell.com>

So I've been working on locking up cam using lockmgr locks, and here's
what I have so far:

http://www.theshell.com/~pavalos/wip/cam-lock.patch

Most of the work is obtained from FreeBSD.  I've only been running this
on my SCSI machine for a day, but because the patch is so large, I wanted
to make it available for people to review if they have some spare time.

Thanks,
Peter
Attachment:
pgp00002.pgp
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00002.pgp
Type: application/octet-stream
Size: 197 bytes
Desc: "Description: PGP signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080307/9a17ecd8/attachment-0016.obj>

From jspringe at uos.de  Fri Mar  7 03:25:17 2008
From: jspringe at uos.de (Jost Tobias Springenberg)
Date: Fri, 7 Mar 2008 12:25:17 +0100
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <20080307122517.72c9e2b1.jspringe@uos.de>

On Tue, 4 Mar 2008 11:28:15 -0500 (EST)
"Justin C. Sherrill" <justin at shiningsilence.com> wrote:

> On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
> > Hi,
> >
> > Google just announced its Summer of Code for 2008:
> >
> > 	http://code.google.com/soc/2008/
> >
> > I think this would be a great opportunity for DragonFly to participate
> > as a mentoring organisation.  We could attract new developers and could
> > get code/work done.  Looking at the SoC results of the other BSDs most
> > of their projects were a success.  Of course, not all, but a reasonable
> > percentage.  See [1] and [2].
> 
> We've applied in previous years - Jeff Hsu did one year, and I put
> together the application last year.  The hardest thing to find was
> students (and they are the thing that helps SoC applications a lot, I
> think).
> 
> Any student volunteers?  We have mentors.
> 

I read this mailing list for quite a while now and thought about contributing stuff
to DFfly several times, so yes why not take this opportunity if it's there.

-- 
Jost Tobias Springenberg <jspringe at uos.de>




From tgen at netphreax.net  Fri Mar  7 05:17:27 2008
From: tgen at netphreax.net (Thomas E. Spanjaard)
Date: Fri, 7 Mar 2008 05:17:27 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: PCI Bios / Interrupt remapping / etc
In-Reply-To: <47D0B211.6000002@199technologies.org>
Message-ID: <47D13FB4.5080306@netphreax.net>

Chris Turner wrote:
Doing a bit of digging here for my long-standing CBB+SIO interupt and 
buffer problem -

one machine I've tested against was an OpenBSD machine, which didn't
always work to handle the cardbus sio card on a PCI cardbus adapter
-

tuning up some of the device flags in:

http://www.openbsd.org/cgi-bin/man.cgi?query=pcibios&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=html 

seems to have alleviated the problem for that os..

I'm just only starting to get up to speed on how DF handles these types 
of things (namely initial PIC / interrupt layout at boot time device 
enumeration), but am wondering if anyone familiar with this area of the 
code has any comments / advice w/r/t the capabilities of the DF bios 
drivers
and the various quirks / fixup mentioned in the link above..

looking to possibly investigate fixing up some of these issues over time.
Our code that handles issues like this (in cases where you're not using 
APICs, just PICs and PIRs) lives in bus/pci/i386/. Not that running 
without APIC support is all that common on modern machines anymore...
--
        Thomas E. Spanjaard
        tgen at netphreax.net
Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00003.pgp
Type: application/octet-stream
Size: 186 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080307/61366b5c/attachment-0016.obj>

From tgen at netphreax.net  Fri Mar  7 05:16:51 2008
From: tgen at netphreax.net (Thomas E. Spanjaard)
Date: Fri, 7 Mar 2008 05:16:51 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Misc. ACPI / suspend
In-Reply-To: <47CA073B.6020106@199technologies.org>
Message-ID: <47D13F07.9080308@netphreax.net>

Chris Turner wrote:
1) does anyone have ACPI (instead of APM)
   sleep / suspend / wakeup working on Dfly ?
2) If so, what machines are being used ?
3) Same question for other BSDs - my understanding is NetBSD is most
   'advanced' w/r/t power managment - but I'm not 100% on this ...
would looove to have a sleeping / resuming / scaling laptop running some 
BSD flavor.. am willing to work towards that end, esp. w/r/t Dfly -
trying to chart a course to figguring this out.
I have ACPI S3 suspend working like a charm on my IBM ThinkPad R40 
(Pentium M "Banias" 1.3GHz, speedstepping works just fine), running 
NetBSD 3.99.21.
--
        Thomas E. Spanjaard
        tgen at netphreax.net
Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00004.pgp
Type: application/octet-stream
Size: 186 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080307/de3e5104/attachment-0016.obj>

From civilizd at gmail.com  Fri Mar  7 09:06:41 2008
From: civilizd at gmail.com (Vita "CiV" Cizek)
Date: Fri, 7 Mar 2008 09:06:41 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <98d564710803070853q1c73d795m6e6c5cc5049fa099@mail.gmail.com>

>  Any student volunteers?  We have mentors.
>
I am interested too, especially in some kernel-related work.




From justin at shiningsilence.com  Sat Mar  8 12:07:51 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Sat, 8 Mar 2008 12:07:51 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google SoC 2008 - mentors mentors mentors
Message-ID: <51558.192.168.0.252.1205006403.squirrel@www.shiningsilence.com>

If you are willing to mentor for the Google 2008 Summer of Code, please
speak up.  Right now we have: (from our wiki page)

Matthias
Sephe
TGEN
corecode

Part of the application process includes naming people as mentors (student
applications come later), so I want to get as complete a list as possible.

The application is due on the 12th, so if you want to mentor, now's the
time to say so.

Google's SoC FAQ is here: http://code.google.com/soc/2008/faqs.html

Our wiki page is here: http://wiki.dragonflybsd.org/index.cgi/GoogleSoC2008

- much credit to Matthias and others for getting that set up.





From saw at online.de  Sat Mar  8 14:26:07 2008
From: saw at online.de (Sascha Wildner)
Date: Sat, 08 Mar 2008 23:26:07 +0100
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <47d31245$0$848$415eb37d@crater_reader.dragonflybsd.org>

Sascha Wildner wrote:
Hi all,

this is probably as good a moment as any to come out of the forest with 
this. The patch at

http://leaf.dragonflybsd.org/~swildner/nrelease_gui.diff
Ok, I have committed the stuff as an example.

I'm not sure if my free time permits to work on a full-blown live CD 
with X11 and other good things (I already feel my interest wandering off 
in other directions) so if anyone wants to pick up the ball, go ahead. :)

Sascha

--
http://yoyodyne.ath.cx



From qhwt+dfly at les.ath.cx  Tue Mar 11 22:21:31 2008
From: qhwt+dfly at les.ath.cx (YONETANI Tomokazu)
Date: Tue, 11 Mar 2008 22:21:31 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Misc. ACPI / suspend
In-Reply-To: <47CA073B.6020106@199technologies.org>
Message-ID: <20080312051219.GA56091@les.ath.cx>

On Thu, Mar 06, 2008 at 10:03:21PM -0500, Chris Turner wrote:
> 1) does anyone have ACPI (instead of APM)
>    sleep / suspend / wakeup working on Dfly ?
> 2) If so, what machines are being used ?

Dynabook SS3500 (http://www.tlt.co.jp/pc/catalog/ss/02110735/index_j.htm).
It's old and can get very hot(thus frequently turns on the cooling fan)
even when it's running Windows.  I haven't turned it on for about several
months though.

Cheers.




From c.turner at 199technologies.org  Wed Mar 12 04:37:22 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Wed, 12 Mar 2008 04:37:22 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Misc. ACPI / suspend
In-Reply-To: <47CA073B.6020106@199technologies.org>
Message-ID: <47D7BEE3.6010907@199technologies.org>

YONETANI Tomokazu wrote:
On Thu, Mar 06, 2008 at 10:03:21PM -0500, Chris Turner wrote:
1) does anyone have ACPI (instead of APM)
   sleep / suspend / wakeup working on Dfly ?
Cheers.
ditto..

Suppose this should go to docs@ - in any case..

Thinking about setting up a wiki page on the issue so we
can discuss / track what 'good' hardware / drivers / implementations / 
etc are 'out there' - anyone have any suggestions on where this should
go?

http://wiki.dragonflybsd.org/index.cgi/acpi-overview.html

Remains from the handbook conversion - but I'm hesitant to 'over wikify'
this ..



From c.turner at 199technologies.org  Wed Mar 12 15:36:52 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Wed, 12 Mar 2008 15:36:52 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: devel/cscope
Message-ID: <47D85A08.8040103@199technologies.org>

why oh why did I take so long to try this out !!!

just sharing my eureka moment with the list..

- Chris




From dudu at dudu.ro  Wed Mar 12 15:50:14 2008
From: dudu at dudu.ro (Vlad GALU)
Date: Wed, 12 Mar 2008 15:50:14 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: devel/cscope
In-Reply-To: <47D85A08.8040103@199technologies.org>
Message-ID: <ad79ad6b0803121547r2bf67ffep9e40badaac6490f8@mail.gmail.com>

On 3/13/08, Chris Turner <c.turner at 199technologies.org> wrote:
> why oh why did I take so long to try this out !!!
>
>  just sharing my eureka moment with the list..


    Works nice with vim, too!

>
>
>  - Chris
>


-- 
Mahnahmahnah!




From justin at shiningsilence.com  Sun Mar 16 21:06:13 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Sun, 16 Mar 2008 21:06:13 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: binary packages for 1.12 coming in
Message-ID: <1372.192.168.0.252.1205726088.squirrel@www.shiningsilence.com>

The binary build for 1.12 is taking quite a while.  I've started copying
in newly built packages to
pkgbox.dragonflybsd.org/packages/DragonFly-1.12/i386/ - this should be
getting copied out to mirrors over the next while.

There are currently 1283 packages built, which leaves a whole lot to go;
I'll copy new packages in as they complete.





From hasso at estpak.ee  Wed Mar 19 04:31:08 2008
From: hasso at estpak.ee (Hasso Tepper)
Date: Wed, 19 Mar 2008 04:31:08 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Some questions regarding ACPI
Message-ID: <200803191322.46366.hasso@estpak.ee>

I'm working on bringing in some laptop (and especially thinkpad) specific 
ACPI code from FreeBSD into DragonFly. I never touched ACPI stuff before 
and haven't followed it much either, so I have some questions.

* FreeBSD uses ACPI_SERIAL_* heavily. What's the locking situation in 
  DragonFly and why?

* As far as I can see, PCI integration is commented out in DragonFly. 
  What's the state of it and why?

* platform/pc32/acpica5/acpi_toshiba.c - why is it there? I don't think 
  that this is something pc32 specific in it and it should work in pc64 
  laptops as well. Any objections to move it into 
  dev/acpica5/acpi_toshiba/ ?

What's the current status of ACPI in general? AFAICS our acpica is quite 
old - what needs to be done to bring in newer one?


-- 
Hasso




From qhwt+dfly at les.ath.cx  Wed Mar 19 09:24:50 2008
From: qhwt+dfly at les.ath.cx (YONETANI Tomokazu)
Date: Wed, 19 Mar 2008 09:24:50 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Some questions regarding ACPI
In-Reply-To: <200803191322.46366.hasso@estpak.ee>
Message-ID: <20080319161703.GA51509@les.ath.cx>

On Wed, Mar 19, 2008 at 01:22:46PM +0200, Hasso Tepper wrote:
> I'm working on bringing in some laptop (and especially thinkpad) specific 
> ACPI code from FreeBSD into DragonFly. I never touched ACPI stuff before 
> and haven't followed it much either, so I have some questions.

So you want to port some of ACPI support drivers, or to do a fresh port
of ACPI driver from FreeBSD?

> * FreeBSD uses ACPI_SERIAL_* heavily. What's the locking situation in 
>   DragonFly and why?

The current ACPI driver in DragonFly is based on that of FreeBSD as of
end of June, 2004, plus some fixes brought in later (and ACPICA part
has been updated twice since then).  That was before they introduced
the MPSAFE changes into ACPI code, and we use critical section
(crit_{enter,exit}) in most places (and lockmgr lock in a few place).

> * As far as I can see, PCI integration is commented out in DragonFly. 
>   What's the state of it and why?

When we replaced the implementation taken from FreeBSD 4.x with that
brought from FreeBSD 5.x, which added the PCI part, many people
experienced problems until they turned off ACPI completely, or add "pci"
to "debug.acpi.disabled" loader variable.  AFAIK the PCI part in the ACPI
driver almost hasn't been adjusted to work with our version of PCI code.

> * platform/pc32/acpica5/acpi_toshiba.c - why is it there? I don't think 
>   that this is something pc32 specific in it and it should work in pc64 
>   laptops as well. Any objections to move it into 
>   dev/acpica5/acpi_toshiba/ ?

In FreeBSD it used to be sitting at i386/acpica/acpi_toshiba.c and was
later moved into acpi_support.  That change hasn't hit our tree (in fact,
we have no acpi support drivers other than that).  It seems that FreeBSD
has them in dev/acpi_support now, and we for some reason have that
directory in our CVS repository (but containing no files in it).

> What's the current status of ACPI in general? AFAICS our acpica is quite 
> old - what needs to be done to bring in newer one?

Actually, it's not very important to keep just ACPICA latest, but
if you bring the ACPI driver from FreeBSD you need to bring ACPICA code
that matches their version, and it IS important.  And it generally requires
you much work to just update ACPICA part anyway because of how they
change things on every release.

Cheers.




From hasso at estpak.ee  Wed Mar 19 12:29:52 2008
From: hasso at estpak.ee (Hasso Tepper)
Date: Wed, 19 Mar 2008 12:29:52 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Some questions regarding ACPI
In-Reply-To: <200803191322.46366.hasso@estpak.ee>
Message-ID: <200803192115.35396.hasso@estpak.ee>

YONETANI Tomokazu wrote:
> On Wed, Mar 19, 2008 at 01:22:46PM +0200, Hasso Tepper wrote:
> > I'm working on bringing in some laptop (and especially thinkpad)
> > specific ACPI code from FreeBSD into DragonFly. I never touched ACPI
> > stuff before and haven't followed it much either, so I have some
> > questions.
>
> So you want to port some of ACPI support drivers, or to do a fresh port
> of ACPI driver from FreeBSD?

I'm only interested in support drivers and the reason is pure practical - 
newer thinkpads handle less and less hotkeys etc in hardware and require 
support form OS. acpi_ibm and acpi_video are examples of such modules 
which would help a lot of these newer thinkpad users.

acpi_ibm is almost ready to commit (renamed to acpi_thinkpad though).

> > * FreeBSD uses ACPI_SERIAL_* heavily. What's the locking situation in
> >   DragonFly and why?
>
> The current ACPI driver in DragonFly is based on that of FreeBSD as of
> end of June, 2004, plus some fixes brought in later (and ACPICA part
> has been updated twice since then).  That was before they introduced
> the MPSAFE changes into ACPI code, and we use critical section
> (crit_{enter,exit}) in most places (and lockmgr lock in a few place).

Mkay. Will look at more closely.

> > * As far as I can see, PCI integration is commented out in DragonFly.
> >   What's the state of it and why?
>
> When we replaced the implementation taken from FreeBSD 4.x with that
> brought from FreeBSD 5.x, which added the PCI part, many people
> experienced problems until they turned off ACPI completely, or add
> "pci" to "debug.acpi.disabled" loader variable.  AFAIK the PCI part in
> the ACPI driver almost hasn't been adjusted to work with our version of
> PCI code.

I'm afraid that it's beyond my skills, but while looking at acpi_video I 
discovered that it's hard to handle correctly without PCI support.

> > * platform/pc32/acpica5/acpi_toshiba.c - why is it there? I don't
> > think that this is something pc32 specific in it and it should work
> > in pc64 laptops as well. Any objections to move it into
> >   dev/acpica5/acpi_toshiba/ ?
>
> In FreeBSD it used to be sitting at i386/acpica/acpi_toshiba.c and was
> later moved into acpi_support.  That change hasn't hit our tree (in
> fact, we have no acpi support drivers other than that).  It seems that
> FreeBSD has them in dev/acpi_support now, and we for some reason have
> that directory in our CVS repository (but containing no files in it).

I don't see it ;). Makes sense though. So, any objections if I move 
acpi_toshiba into sys/dev/acpi_support and add new acpi_thinkpad there as 
well? 

> > What's the current status of ACPI in general? AFAICS our acpica is
> > quite old - what needs to be done to bring in newer one?
>
> Actually, it's not very important to keep just ACPICA latest, but
> if you bring the ACPI driver from FreeBSD you need to bring ACPICA code
> that matches their version, and it IS important.  And it generally
> requires you much work to just update ACPICA part anyway because of how
> they change things on every release.

Someone else has to do it :).

Thanks for info.


-- 
Hasso




From dillon at apollo.backplane.com  Wed Mar 19 14:01:13 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Wed, 19 Mar 2008 14:01:13 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: panic: assertion: hammer_btree_cmp(cursor->left_bound,	&cursor->node->ondisk->elms[0].leaf.base) <= 0 in btree_split_leaf
In-Reply-To: <200802232204.m1NM4cxd046264@apollo.backplane.com>
Message-ID: <200803192054.m2JKsjwn045137@apollo.backplane.com>


:Hi.
:While trying to find a procedure to reliably reproduce the panic
:I reported last time, I caught a different panic (uploaded at
: ~y0netan1/crash/9/ on my leaf account).  I wrote the following shell
:script (make sure to edit variables DISKS and MOUNTPT before using this
:script or it may trash your system):
:  #!/bin/sh -ex
:  DISKS="/dev/ad0s1f"
:  MOUNTPT=/mnt/HAMMER
:
:  cd /
:  newfs_hammer -L TEST $DISKS
:  for i in `seq 1 100`; do
:..
:And the panic is triggered by rm command.
:I'll try to see if it's possible to reproduce the last one without
:unmounting then mounting the HAMMER fs.
:
:Cheers.

    I believe I have fixed this panic.  hammer_make_separator() had a bug
    in it.

    There is still an issue with the node ref count on umount.

    Please continue to life-test the code.  The reblocking code
    (hammer reblock /mnt) should work now, as should the pruning code
    (e.g. hammer prune /mnt everything).

    The filesystem full case is still not handled and will cause bad things
    to happen.  The undo code isn't finished yet either but it is getting
    there (it's writing stuff out but not setting the sequence number and
    not trying to recover-on-mount yet).

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From qhwt+dfly at les.ath.cx  Wed Mar 19 19:45:40 2008
From: qhwt+dfly at les.ath.cx (YONETANI Tomokazu)
Date: Wed, 19 Mar 2008 19:45:40 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Some questions regarding ACPI
In-Reply-To: <200803191322.46366.hasso@estpak.ee>
Message-ID: <20080320023828.GA53648@les.ath.cx>

On Wed, Mar 19, 2008 at 09:15:35PM +0200, Hasso Tepper wrote:
> YONETANI Tomokazu wrote:
> > On Wed, Mar 19, 2008 at 01:22:46PM +0200, Hasso Tepper wrote:
> > > I'm working on bringing in some laptop (and especially thinkpad)
> > > specific ACPI code from FreeBSD into DragonFly. I never touched ACPI
> > > stuff before and haven't followed it much either, so I have some
> > > questions.
> >
> > So you want to port some of ACPI support drivers, or to do a fresh port
> > of ACPI driver from FreeBSD?
> 
> I'm only interested in support drivers and the reason is pure practical - 
> newer thinkpads handle less and less hotkeys etc in hardware and require 
> support form OS. acpi_ibm and acpi_video are examples of such modules 
> which would help a lot of these newer thinkpad users.
> 
> acpi_ibm is almost ready to commit (renamed to acpi_thinkpad though).

Ah, that's a good news!  My only concern is that ISTR someone mentioned
me that his colleague was thinking about porting ACPI driver itself,
so if you're not the person you may want to collaborate with him/her
so as not to waste the effort or time...

			:

> > In FreeBSD it used to be sitting at i386/acpica/acpi_toshiba.c and was
> > later moved into acpi_support.  That change hasn't hit our tree (in
> > fact, we have no acpi support drivers other than that).  It seems that
> > FreeBSD has them in dev/acpi_support now, and we for some reason have
> > that directory in our CVS repository (but containing no files in it).
> 
> I don't see it ;). Makes sense though. So, any objections if I move 
> acpi_toshiba into sys/dev/acpi_support and add new acpi_thinkpad there as 
> well? 

Sorry, I checked the CVS repository and it doesn't exist actually :)
I don't have any objection to moving it there.

Cheers.




From hasso at estpak.ee  Thu Mar 20 00:14:05 2008
From: hasso at estpak.ee (Hasso Tepper)
Date: Thu, 20 Mar 2008 00:14:05 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Some questions regarding ACPI
In-Reply-To: <200803191322.46366.hasso@estpak.ee>
Message-ID: <200803200904.50875.hasso@estpak.ee>

YONETANI Tomokazu wrote:
> On Wed, Mar 19, 2008 at 09:15:35PM +0200, Hasso Tepper wrote:
> > acpi_ibm is almost ready to commit (renamed to acpi_thinkpad though).
>
> Ah, that's a good news!  My only concern is that ISTR someone mentioned
> me that his colleague was thinking about porting ACPI driver itself,
> so if you're not the person you may want to collaborate with him/her
> so as not to waste the effort or time...

Current state in my repo is attached. It should work on 1.12 as well as it 
doesn't depend yet on moving stuff around.

add-acpi-if-m.patch adds some new stuff to the ACPI code to access 
embedded controllers and match ACPI devices by ID. Not sure how, where 
and whether at all these should be documented.

add-acpi-thinkpad.patch is the driver itself. Note that some stuff doesn't 
work yet on newer thinkpads, I plan to work on it later.

There is still some things to do though. I have to decide what to do with 
led(4) part and with locking. There is also one fatal issue - laptop 
locks up hardly (no panic) while unloading module. Any idea regarding 
this is welcome. And of course test results :).


-- 
Hasso
# HG changeset patch
# User Hasso Tepper <hasso at estpak.ee>
# Date 1205919290 -7200
# Branch HEAD
# Node ID 5a6e2705cc95a340abf973ae5df73ef34e070b79
# Parent  cd529e2e7f849034d5d5a0973cb98af50db0e797
imported patch adding-acpi-if-m.patch

diff --git a/sys/conf/files b/sys/conf/files
--- a/sys/conf/files
+++ b/sys/conf/files
@@ -1387,6 +1387,7 @@ emulation/dragonfly12/dfbsd12_stat.c	non
 ${OSACPI_MI_DIR}/acpi_cmbat.c		optional acpi
 ${OSACPI_MI_DIR}/acpi_cpu.c		optional acpi
 ${OSACPI_MI_DIR}/acpi_ec.c		optional acpi
+${OSACPI_MI_DIR}/acpi_if.m		optional acpi
 ${OSACPI_MI_DIR}/acpi_isab.c		optional acpi isa
 ${OSACPI_MI_DIR}/acpi_lid.c		optional acpi
 ${OSACPI_MI_DIR}/acpi_package.c		optional acpi
diff --git a/sys/conf/kmod.mk b/sys/conf/kmod.mk
--- a/sys/conf/kmod.mk
+++ b/sys/conf/kmod.mk
@@ -275,7 +275,7 @@ MFILES?= kern/bus_if.m kern/device_if.m 
     bus/pccard/card_if.m bus/pccard/power_if.m bus/pci/pci_if.m \
     bus/pci/pcib_if.m \
     bus/ppbus/ppbus_if.m bus/smbus/smbus_if.m bus/usb/usb_if.m \
-    dev/disk/nata/ata_if.m \
+    dev/acpica5/acpi_if.m dev/disk/nata/ata_if.m \
     dev/sound/pcm/ac97_if.m dev/sound/pcm/channel_if.m \
     dev/sound/pcm/feeder_if.m dev/sound/pcm/mixer_if.m \
     libiconv/iconv_converter_if.m dev/agp/agp_if.m opencrypto/crypto_if.m
diff --git a/sys/dev/acpica5/Makefile b/sys/dev/acpica5/Makefile
--- a/sys/dev/acpica5/Makefile
+++ b/sys/dev/acpica5/Makefile
@@ -69,12 +69,14 @@ SRCS+=  acpi_package.c
 # SRCS+=	acpi_pci.c acpi_pcib.c acpi_pcib_acpi.c acpi_pcib_pci.c
 # SRCS+=	acpi_pci_link.c
 SRCS+=  acpi_powerres.c acpi_resource.c acpi_thermal.c
-SRCS+=  acpi_timer.c
+SRCS+=  acpi_timer.c acpi_if.c
 SRCS+=  OsdDebug.c
 SRCS+=  OsdHardware.c OsdInterface.c OsdInterrupt.c OsdMemory.c OsdSchedule.c
 SRCS+=  OsdStream.c OsdSynch.c OsdTable.c OsdEnvironment.c
 SRCS+=  opt_acpi.h opt_bus.h opt_ddb.h
-SRCS+=  device_if.h bus_if.h pci_if.h pcib_if.h isa_if.h
+SRCS+=  device_if.h bus_if.h pci_if.h pcib_if.h isa_if.h acpi_if.h
+MFILES = kern/device_if.m kern/bus_if.m bus/pci/pci_if.m bus/pci/pcib_if.m
+MFILES+= bus/isa/isa_if.m dev/acpica5/acpi_if.m
 
 # Debugging support
 DBSRC=	dbcmds.c dbdisply.c dbexec.c dbfileio.c dbhistry.c
diff --git a/sys/dev/acpica5/acpi.c b/sys/dev/acpica5/acpi.c
--- a/sys/dev/acpica5/acpi.c
+++ b/sys/dev/acpica5/acpi.c
@@ -135,6 +135,7 @@ static int	acpi_release_resource(device_
 			int rid, struct resource *r);
 static uint32_t	acpi_isa_get_logicalid(device_t dev);
 static int	acpi_isa_get_compatid(device_t dev, uint32_t *cids, int count);
+static char	*acpi_device_id_probe(device_t bus, device_t dev, char **ids);
 static int	acpi_isa_pnp_probe(device_t bus, device_t child,
 			struct isa_pnp_id *ids);
 static void	acpi_probe_children(device_t bus);
@@ -189,6 +190,9 @@ static device_method_t acpi_methods[] = 
     DEVMETHOD(bus_deactivate_resource,	bus_generic_deactivate_resource),
     DEVMETHOD(bus_setup_intr,		bus_generic_setup_intr),
     DEVMETHOD(bus_teardown_intr,	bus_generic_teardown_intr),
+
+    /* ACPI bus */
+    DEVMETHOD(acpi_id_probe,		acpi_device_id_probe),
 
     /* ISA emulation */
     DEVMETHOD(isa_pnp_probe,		acpi_isa_pnp_probe),
@@ -1121,6 +1125,24 @@ out:
 	AcpiOsFree(buf.Pointer);
     ACPI_UNLOCK;
     return_VALUE (valid);
+}
+
+static char *
+acpi_device_id_probe(device_t bus, device_t dev, char **ids) 
+{
+    ACPI_HANDLE h;
+    int i;
+
+    h = acpi_get_handle(dev);
+    if (ids == NULL || h == NULL || acpi_get_type(dev) != ACPI_TYPE_DEVICE)
+	return (NULL);
+
+    /* Try to match one of the array of IDs with a HID or CID. */
+    for (i = 0; ids[i] != NULL; i++) {
+	if (acpi_MatchHid(h, ids[i]))
+	    return (ids[i]);
+    }
+    return (NULL);
 }
 
 static int
diff --git a/sys/dev/acpica5/acpi_ec.c b/sys/dev/acpica5/acpi_ec.c
--- a/sys/dev/acpica5/acpi_ec.c
+++ b/sys/dev/acpica5/acpi_ec.c
@@ -327,11 +327,19 @@ static ACPI_STATUS	EcWrite(struct acpi_e
 				UINT8 *Data);
 static int		acpi_ec_probe(device_t dev);
 static int		acpi_ec_attach(device_t dev);
+static int		acpi_ec_read_method(device_t dev, u_int addr,
+				ACPI_INTEGER *val, int width);
+static int		acpi_ec_write_method(device_t dev, u_int addr,
+				ACPI_INTEGER val, int width);
 
 static device_method_t acpi_ec_methods[] = {
     /* Device interface */
     DEVMETHOD(device_probe,	acpi_ec_probe),
     DEVMETHOD(device_attach,	acpi_ec_attach),
+
+    /* Embedded controller interface */
+    DEVMETHOD(acpi_ec_read,     acpi_ec_read_method),
+    DEVMETHOD(acpi_ec_write,    acpi_ec_write_method),
 
     {0, 0}
 };
@@ -620,6 +628,33 @@ error:
 			     sc->ec_data_res);
     /* mtx_destroy(&sc->ec_mtx); */
     return (ENXIO);
+}
+
+/* Methods to allow other devices (e.g., smbat) to read/write EC space. */
+static int
+acpi_ec_read_method(device_t dev, u_int addr, ACPI_INTEGER *val, int width)
+{
+    struct acpi_ec_softc *sc;
+    ACPI_STATUS status;
+
+    sc = device_get_softc(dev);
+    status = EcSpaceHandler(ACPI_READ, addr, width * 8, val, sc, NULL);
+    if (ACPI_FAILURE(status))
+        return (ENXIO);
+    return (0);
+}
+
+static int
+acpi_ec_write_method(device_t dev, u_int addr, ACPI_INTEGER val, int width)
+{
+    struct acpi_ec_softc *sc;
+    ACPI_STATUS status;
+
+    sc = device_get_softc(dev);
+    status = EcSpaceHandler(ACPI_WRITE, addr, width * 8, &val, sc, NULL);
+    if (ACPI_FAILURE(status))
+        return (ENXIO);
+    return (0);
 }
 
 static void
diff --git a/sys/dev/acpica5/acpi_if.m b/sys/dev/acpica5/acpi_if.m
new file mode 100644
--- /dev/null
+++ b/sys/dev/acpica5/acpi_if.m
@@ -0,0 +1,92 @@
+#-
+# Copyright (c) 2004 Nate Lawson
+# All rights reserved.
+#
+# Redistribution and use in source and binary forms, with or without
+# modification, are permitted provided that the following conditions
+# are met:
+# 1. Redistributions of source code must retain the above copyright
+#    notice, this list of conditions and the following disclaimer.
+# 2. Redistributions in binary form must reproduce the above copyright
+#    notice, this list of conditions and the following disclaimer in the
+#    documentation and/or other materials provided with the distribution.
+#
+# THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
+# ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+# ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
+# FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+# DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+# OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+# HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+# LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+# OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+# SUCH DAMAGE.
+#
+# $DragonFly$
+#
+
+#include <sys/bus.h>
+#include <sys/types.h>
+#include "acpi.h"
+
+INTERFACE acpi;
+
+#
+# Default implementation for acpi_id_probe().
+#
+CODE {
+	static char *
+	acpi_generic_id_probe(device_t bus, device_t dev, char **ids)
+	{
+		return (NULL);
+	}
+};
+
+#
+# Check a device for a match in a list of ID strings.  The strings can be
+# EISA PNP IDs or ACPI _HID/_CID values.
+#
+# device_t bus:  parent bus for the device
+#
+# device_t dev:  device being considered
+#
+# char **ids:  array of ID strings to consider
+#
+# Returns:  ID string matched or NULL if no match
+#
+METHOD char * id_probe {
+	device_t	bus;
+	device_t	dev;
+	char		**ids;
+} DEFAULT acpi_generic_id_probe;
+
+#
+# Read embedded controller (EC) address space
+#
+# device_t dev:  EC device
+# u_int addr:  Address to read from in EC space
+# ACPI_INTEGER *val:  Location to store read value
+# int width:  Size of area to read in bytes
+#
+METHOD int ec_read {
+	device_t	dev;
+	u_int		addr;
+	ACPI_INTEGER	*val;
+	int		width;
+};
+
+#
+# Write embedded controller (EC) address space
+#
+# device_t dev:  EC device
+# u_int addr:  Address to write to in EC space
+# ACPI_INTEGER val:  Value to write
+# int width:  Size of value to write in bytes
+#
+METHOD int ec_write {
+	device_t	dev;
+	u_int		addr;
+	ACPI_INTEGER	val;
+	int		width;
+};
diff --git a/sys/dev/acpica5/acpivar.h b/sys/dev/acpica5/acpivar.h
--- a/sys/dev/acpica5/acpivar.h
+++ b/sys/dev/acpica5/acpivar.h
@@ -29,6 +29,7 @@
  * $DragonFly: src/sys/dev/acpica5/acpivar.h,v 1.12 2007/10/23 03:04:48 y0netan1 Exp $
  */
 
+#include "acpi_if.h"
 #include "bus_if.h"
 #include <sys/eventhandler.h>
 #include <sys/sysctl.h>
# HG changeset patch
# User Hasso Tepper <hasso at estpak.ee>
# Date 1205995474 -7200
# Branch HEAD
# Node ID c5db8d4a7c6b25a8576a8d42c5029aaf0e23bfb6
# Parent  5a6e2705cc95a340abf973ae5df73ef34e070b79
[mq]: adding-acpi-thinkpad.patch

diff --git a/sys/dev/acpica5/Makefile b/sys/dev/acpica5/Makefile
--- a/sys/dev/acpica5/Makefile
+++ b/sys/dev/acpica5/Makefile
@@ -117,7 +117,7 @@ acpi_wakecode.h: acpi_wakecode.S
 	${MAKE} -f ${SYSDIR}/${OSACPI_MD_DIR}/Makefile \
 		MAKESRCPATH=${SYSDIR}/${OSACPI_MD_DIR}
 
-SUBDIR=	acpi_toshiba
+SUBDIR=	acpi_toshiba acpi_thinkpad
 all: ${PROG} ${SUBDIR}
 
 # *.o file for each patched *.c file is created under the same directory,
diff --git a/sys/dev/acpica5/acpi_thinkpad/Makefile b/sys/dev/acpica5/acpi_thinkpad/Makefile
new file mode 100644
--- /dev/null
+++ b/sys/dev/acpica5/acpi_thinkpad/Makefile
@@ -0,0 +1,9 @@
+# $DragonFly$
+
+SYSDIR?=${.CURDIR}/../../..
+
+KMOD=		acpi_thinkpad
+CFLAGS+=	-I${.OBJDIR}/.. -I${.CURDIR}/..
+SRCS=		acpi_thinkpad.c opt_acpi.h device_if.h bus_if.h
+
+.include <bsd.kmod.mk>
diff --git a/sys/dev/acpica5/acpi_thinkpad/acpi_thinkpad.c b/sys/dev/acpica5/acpi_thinkpad/acpi_thinkpad.c
new file mode 100644
--- /dev/null
+++ b/sys/dev/acpica5/acpi_thinkpad/acpi_thinkpad.c
@@ -0,0 +1,1046 @@
+/*
+ * Copyright (c) 2004 Takanori Watanabe
+ * Copyright (c) 2005 Markus Brueffer <markus at FreeBSD.org>
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *    notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *    notice, this list of conditions and the following disclaimer in the
+ *    documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+ */
+
+/*
+ * Driver for extra ACPI-controlled gadgets found on IBM and Lenovo ThinkPad
+ * laptops. Inspired by the ibm-acpi and tpb projects which implement these
+ * features on Linux.
+ *
+ *   acpi-ibm: <http://ibm-acpi.sourceforge.net/>
+ *        tpb: <http://www.nongnu.org/tpb/>
+ */
+
+#include "opt_acpi.h"
+#include <sys/param.h>
+#include <sys/kernel.h>
+#include <sys/bus.h>
+#include <machine/cpufunc.h>
+#include <sys/module.h>
+/* #include <dev/led/led.h> */
+#include <sys/sensors.h>
+#include <sys/sysctl.h>
+#include <machine/clock.h>
+
+#include "acpi.h"
+#include "acpivar.h"
+#include "acpi_if.h"
+
+#define _COMPONENT	ACPI_OEM
+ACPI_MODULE_NAME("THINKPAD")
+
+/* Internal methods */
+#define ACPI_THINKPAD_METHOD_EVENTS		1
+#define ACPI_THINKPAD_METHOD_EVENTMASK		2
+#define ACPI_THINKPAD_METHOD_HOTKEY		3
+#define ACPI_THINKPAD_METHOD_BRIGHTNESS		4
+#define ACPI_THINKPAD_METHOD_VOLUME		5
+#define ACPI_THINKPAD_METHOD_MUTE		6
+#define ACPI_THINKPAD_METHOD_THINKLIGHT		7
+#define ACPI_THINKPAD_METHOD_BLUETOOTH		8
+#define ACPI_THINKPAD_METHOD_WLAN		9
+#define ACPI_THINKPAD_METHOD_FANSPEED		10
+#define ACPI_THINKPAD_METHOD_FANLEVEL		11
+#define ACPI_THINKPAD_METHOD_FANSTATUS		12
+#define ACPI_THINKPAD_METHOD_THERMAL		13
+
+/* Hotkeys/Buttons */
+#define THINKPAD_RTC_HOTKEY1			0x64
+#define   THINKPAD_RTC_MASK_HOME		(1 << 0)
+#define   THINKPAD_RTC_MASK_SEARCH		(1 << 1)
+#define   THINKPAD_RTC_MASK_MAIL		(1 << 2)
+#define   THINKPAD_RTC_MASK_WLAN		(1 << 5)
+#define THINKPAD_RTC_HOTKEY2			0x65
+#define   THINKPAD_RTC_MASK_THINKPAD		(1 << 3)
+#define   THINKPAD_RTC_MASK_ZOOM		(1 << 5)
+#define   THINKPAD_RTC_MASK_VIDEO		(1 << 6)
+#define   THINKPAD_RTC_MASK_HIBERNATE		(1 << 7)
+#define THINKPAD_RTC_THINKLIGHT			0x66
+#define   THINKPAD_RTC_MASK_THINKLIGHT		(1 << 4)
+#define THINKPAD_RTC_SCREENEXPAND		0x67
+#define   THINKPAD_RTC_MASK_SCREENEXPAND	(1 << 5)
+#define THINKPAD_RTC_BRIGHTNESS			0x6c
+#define   THINKPAD_RTC_MASK_BRIGHTNESS		(1 << 5)
+#define THINKPAD_RTC_VOLUME			0x6e
+#define   THINKPAD_RTC_MASK_VOLUME		(1 << 7)
+
+/* Embedded Controller registers */
+#define THINKPAD_EC_BRIGHTNESS			0x31
+#define   THINKPAD_EC_MASK_BRI			0x7
+#define THINKPAD_EC_VOLUME			0x30
+#define   THINKPAD_EC_MASK_VOL			0xf
+#define   THINKPAD_EC_MASK_MUTE			(1 << 6)
+#define THINKPAD_EC_FANSTATUS			0x2F
+#define   THINKPAD_EC_MASK_FANLEVEL		0x3f
+#define   THINKPAD_EC_MASK_FANDISENGAGED	(1 << 6)
+#define   THINKPAD_EC_MASK_FANSTATUS		(1 << 7)
+#define THINKPAD_EC_FANSPEED			0x84
+
+/* CMOS Commands */
+#define THINKPAD_CMOS_VOLUME_DOWN		0
+#define THINKPAD_CMOS_VOLUME_UP			1
+#define THINKPAD_CMOS_VOLUME_MUTE		2
+#define THINKPAD_CMOS_BRIGHTNESS_UP		4
+#define THINKPAD_CMOS_BRIGHTNESS_DOWN		5
+
+/* ACPI methods */
+#define THINKPAD_NAME_KEYLIGHT			"KBLT"
+#define THINKPAD_NAME_WLAN_BT_GET		"GBDC"
+#define THINKPAD_NAME_WLAN_BT_SET		"SBDC"
+#define   THINKPAD_NAME_MASK_BT			(1 << 1)
+#define   THINKPAD_NAME_MASK_WLAN		(1 << 2)
+#define THINKPAD_NAME_THERMAL_GET		"TMP7"
+#define THINKPAD_NAME_THERMAL_UPDT		"UPDT"
+
+#define THINKPAD_NAME_EVENTS_STATUS_GET		"DHKC"
+#define THINKPAD_NAME_EVENTS_MASK_GET		"DHKN"
+#define THINKPAD_NAME_EVENTS_STATUS_SET		"MHKC"
+#define THINKPAD_NAME_EVENTS_MASK_SET		"MHKM"
+#define THINKPAD_NAME_EVENTS_GET		"MHKP"
+#define THINKPAD_NAME_EVENTS_AVAILMASK		"MHKA"
+
+#define ABS(x) (((x) < 0)? -(x) : (x))
+
+struct acpi_thinkpad_softc {
+	device_t	dev;
+	ACPI_HANDLE	handle;
+
+	/* Embedded controller */
+	device_t	ec_dev;
+	ACPI_HANDLE	ec_handle;
+
+	/* CMOS */
+	ACPI_HANDLE	cmos_handle;
+
+	/* Fan status */
+	ACPI_HANDLE	fan_handle;
+	int		fan_levels;
+
+	/* Keylight commands and states */
+	ACPI_HANDLE	light_handle;
+	int		light_cmd_on;
+	int		light_cmd_off;
+	int		light_val;
+	int		light_get_supported;
+	int		light_set_supported;
+
+	/* led(4) interface */
+	struct cdev	*led_dev;
+	int		led_busy;
+	int		led_state;
+
+	int		wlan_bt_flags;
+	int		thermal_updt_supported;
+
+	unsigned int	events_availmask;
+	unsigned int	events_initialmask;
+	int		events_mask_supported;
+	int		events_enable;
+
+	/* sensors(9) related */
+	struct ksensordev sensordev;
+	struct ksensor sensors[9];	/* XXX: 8 thermal + fan */
+
+	struct sysctl_ctx_list	*sysctl_ctx;
+	struct sysctl_oid	*sysctl_tree;
+};
+
+static struct {
+	char	*name;
+	int	method;
+	char	*description;
+	int	access;
+} acpi_thinkpad_sysctls[] = {
+	{
+		.name		= "events",
+		.method		= ACPI_THINKPAD_METHOD_EVENTS,
+		.description	= "ACPI events enable",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "eventmask",
+		.method		= ACPI_THINKPAD_METHOD_EVENTMASK,
+		.description	= "ACPI eventmask",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "hotkey",
+		.method		= ACPI_THINKPAD_METHOD_HOTKEY,
+		.description	= "Key Status",
+		.access		= CTLTYPE_INT | CTLFLAG_RD
+	},
+	{
+		.name		= "lcd_brightness",
+		.method		= ACPI_THINKPAD_METHOD_BRIGHTNESS,
+		.description	= "LCD Brightness",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "volume",
+		.method		= ACPI_THINKPAD_METHOD_VOLUME,
+		.description	= "Volume",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "mute",
+		.method		= ACPI_THINKPAD_METHOD_MUTE,
+		.description	= "Mute",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "thinklight",
+		.method		= ACPI_THINKPAD_METHOD_THINKLIGHT,
+		.description	= "Thinklight enable",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "bluetooth",
+		.method		= ACPI_THINKPAD_METHOD_BLUETOOTH,
+		.description	= "Bluetooth enable",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "wlan",
+		.method		= ACPI_THINKPAD_METHOD_WLAN,
+		.description	= "WLAN enable",
+		.access		= CTLTYPE_INT | CTLFLAG_RD
+	},
+	{
+		.name		= "fan_level",
+		.method		= ACPI_THINKPAD_METHOD_FANLEVEL,
+		.description	= "Fan level",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "fan",
+		.method		= ACPI_THINKPAD_METHOD_FANSTATUS,
+		.description	= "Fan enable",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+
+	{ NULL, 0, NULL, 0 }
+};
+
+/* ACPI_SERIAL_DECL(thinkpad, "ACPI THINKPAD extras"); */
+static int	acpi_thinkpad_probe(device_t dev);
+static int	acpi_thinkpad_attach(device_t dev);
+static int	acpi_thinkpad_detach(device_t dev);
+
+#if 0 /* not yet */
+static void	thinkpad_led(void *softc, int onoff);
+static void	thinkpad_led_task(struct acpi_thinkpad_softc *sc,
+		int pending __unused);
+#endif
+
+static int	acpi_thinkpad_sysctl(SYSCTL_HANDLER_ARGS);
+static int	acpi_thinkpad_sysctl_init(struct acpi_thinkpad_softc *sc,
+		int method);
+static int	acpi_thinkpad_sysctl_get(struct acpi_thinkpad_softc *sc,
+		int method);
+static int	acpi_thinkpad_sysctl_set(struct acpi_thinkpad_softc *sc,
+		int method, int val);
+
+static int	acpi_thinkpad_eventmask_set(struct acpi_thinkpad_softc *sc,
+		int val);
+static void	acpi_thinkpad_notify(ACPI_HANDLE h, UINT32 notify,
+		void *context);
+static void	acpi_thinkpad_refresh(void *);
+
+static device_method_t acpi_thinkpad_methods[] = {
+	/* Device interface */
+	DEVMETHOD(device_probe, acpi_thinkpad_probe),
+	DEVMETHOD(device_attach, acpi_thinkpad_attach),
+	DEVMETHOD(device_detach, acpi_thinkpad_detach),
+	{0, 0}
+};
+
+static driver_t	acpi_thinkpad_driver = {
+	"acpi_thinkpad",
+	acpi_thinkpad_methods,
+	sizeof(struct acpi_thinkpad_softc),
+};
+
+static devclass_t acpi_thinkpad_devclass;
+
+DRIVER_MODULE(acpi_thinkpad, acpi, acpi_thinkpad_driver,
+    acpi_thinkpad_devclass, 0, 0);
+MODULE_DEPEND(acpi_thinkpad, acpi, 1, 1, 1);
+static char    *thinkpad_ids[] = {"IBM0068", NULL};
+
+#if 0 /* not yet */
+static void
+thinkpad_led(void *softc, int onoff)
+{
+	struct acpi_thinkpad_softc* sc = (struct acpi_thinkpad_softc*) softc;
+
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+
+	if (sc->led_busy)
+		return;
+
+	sc->led_busy = 1;
+	sc->led_state = onoff;
+
+	AcpiOsExecute(OSL_NOTIFY_HANDLER, (void *)thinkpad_led_task, sc);
+}
+
+static void
+thinkpad_led_task(struct acpi_thinkpad_softc *sc, int pending __unused)
+{
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+
+	/* ACPI_SERIAL_BEGIN(thinkpad); */
+	acpi_thinkpad_sysctl_set(sc, ACPI_THINKPAD_METHOD_THINKLIGHT, sc->led_state);
+	/* ACPI_SERIAL_END(thinkpad); */
+
+	sc->led_busy = 0;
+}
+#endif
+
+static int
+acpi_thinkpad_probe(device_t dev)
+{
+	if (acpi_disabled("thinkpad") ||
+	    ACPI_ID_PROBE(device_get_parent(dev), dev, thinkpad_ids) == NULL ||
+	    device_get_unit(dev) != 0) 
+		return (ENXIO);
+
+	device_set_desc(dev, "IBM/Lenovo ThinkPad ACPI Extras");
+	return (0);
+}
+
+static int
+acpi_thinkpad_attach(device_t dev)
+{
+	struct acpi_thinkpad_softc	*sc;
+	struct acpi_softc	*acpi_sc;
+	devclass_t		ec_devclass;
+	int			i;
+
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t) __func__);
+
+	sc = device_get_softc(dev);
+	sc->dev = dev;
+	sc->handle = acpi_get_handle(dev);
+
+	acpi_sc = acpi_device_get_parent_softc(dev);
+
+	/* Look for the first embedded controller */
+        if (!(ec_devclass = devclass_find ("acpi_ec"))) {
+		if (bootverbose)
+			device_printf(dev, "Couldn't find acpi_ec devclass\n");
+		return (EINVAL);
+	}
+        if (!(sc->ec_dev = devclass_get_device(ec_devclass, 0))) {
+		if (bootverbose)
+			device_printf(dev, "Couldn't find acpi_ec device\n");
+		return (EINVAL);
+	}
+	sc->ec_handle = acpi_get_handle(sc->ec_dev);
+
+	/* ACPI_SERIAL_BEGIN(thinkpad); */
+
+#if 0
+	/* Get the sysctl tree */
+	sc->sysctl_ctx = device_get_sysctl_ctx(dev);
+	sc->sysctl_tree = device_get_sysctl_tree(dev);
+#endif
+	sysctl_ctx_init(sc->sysctl_ctx);
+	sc->sysctl_tree = SYSCTL_ADD_NODE(sc->sysctl_ctx,
+	    SYSCTL_CHILDREN(acpi_sc->acpi_sysctl_tree), OID_AUTO,
+	    "thinkpad", CTLFLAG_RD, 0, "");
+
+	/* Look for event mask and hook up the nodes */
+	sc->events_mask_supported = ACPI_SUCCESS(acpi_GetInteger(sc->handle,
+	    THINKPAD_NAME_EVENTS_MASK_GET, &sc->events_initialmask));
+
+	if (sc->events_mask_supported) {
+		SYSCTL_ADD_INT(sc->sysctl_ctx,
+		    SYSCTL_CHILDREN(sc->sysctl_tree), OID_AUTO,
+		    "initialmask", CTLFLAG_RD,
+		    &sc->events_initialmask, 0, "Initial eventmask");
+
+		/* The availmask is the bitmask of supported events */
+		if (ACPI_FAILURE(acpi_GetInteger(sc->handle,
+		    THINKPAD_NAME_EVENTS_AVAILMASK, &sc->events_availmask)))
+			sc->events_availmask = 0xffffffff;
+
+		SYSCTL_ADD_INT(sc->sysctl_ctx,
+		    SYSCTL_CHILDREN(sc->sysctl_tree), OID_AUTO,
+		    "availmask", CTLFLAG_RD,
+		    &sc->events_availmask, 0, "Mask of supported events");
+	}
+
+	/* Hook up proc nodes */
+	for (i = 0; acpi_thinkpad_sysctls[i].name != NULL; i++) {
+		if (!acpi_thinkpad_sysctl_init(sc,
+		    acpi_thinkpad_sysctls[i].method))
+			continue;
+
+		SYSCTL_ADD_PROC(sc->sysctl_ctx,
+		    SYSCTL_CHILDREN(sc->sysctl_tree), OID_AUTO,
+		    acpi_thinkpad_sysctls[i].name,
+		    acpi_thinkpad_sysctls[i].access,
+		    sc, i, acpi_thinkpad_sysctl, "I",
+		    acpi_thinkpad_sysctls[i].description);
+	}
+
+	/* ACPI_SERIAL_END(thinkpad); */
+
+	/* Handle notifies */
+	AcpiInstallNotifyHandler(sc->handle, ACPI_DEVICE_NOTIFY,
+	    acpi_thinkpad_notify, dev);
+
+#if 0
+	/* Hook up light to led(4) */
+	if (sc->light_set_supported)
+		sc->led_dev = led_create_state(thinkpad_led, sc, "thinklight",
+		    sc->light_val);
+#endif
+	/* Attach sensors(9). */
+	if (sensor_task_register(sc, acpi_thinkpad_refresh, 5)) {
+		device_printf(sc->dev, "unable to register update task\n");
+		return 1;
+	}
+
+	strlcpy(sc->sensordev.xname, device_get_nameunit(sc->dev),
+	    sizeof(sc->sensordev.xname));
+
+	/* XXX: Temp sensors */
+	for (i = 0; i < 8; ++i) {
+		sc->sensors[i].type = SENSOR_TEMP;
+		sensor_attach(&sc->sensordev, &sc->sensors[i]);
+	}
+	
+	/* Fan RPM sensor */
+	sc->sensors[8].type = SENSOR_FANRPM;
+	sensor_attach(&sc->sensordev, &sc->sensors[8]);
+
+	sensordev_install(&sc->sensordev);
+
+	return (0);
+}
+
+static int
+acpi_thinkpad_detach(device_t dev)
+{
+	int i;
+
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t) __func__);
+
+	struct acpi_thinkpad_softc *sc = device_get_softc(dev);
+
+	/* Disable events and restore eventmask */
+	/* ACPI_SERIAL_BEGIN(thinkpad); */
+	acpi_thinkpad_sysctl_set(sc, ACPI_THINKPAD_METHOD_EVENTS, 0);
+	acpi_thinkpad_sysctl_set(sc, ACPI_THINKPAD_METHOD_EVENTMASK,
+	    sc->events_initialmask);
+	/* ACPI_SERIAL_END(thinkpad); */
+
+	AcpiRemoveNotifyHandler(sc->handle, ACPI_DEVICE_NOTIFY,
+	    acpi_thinkpad_notify);
+
+	sysctl_ctx_free(sc->sysctl_ctx);
+
+#if 0
+	if (sc->led_dev != NULL)
+		led_destroy(sc->led_dev);
+#endif
+	sensordev_deinstall(&sc->sensordev);
+	for (i = 0; i < 9; i++)
+		sensor_detach(&sc->sensordev, &sc->sensors[i]);
+	sensor_task_unregister(sc);
+
+	return (0);
+}
+
+static int
+acpi_thinkpad_eventmask_set(struct acpi_thinkpad_softc *sc, int val)
+{
+	int i;
+	ACPI_OBJECT		arg[2];
+	ACPI_OBJECT_LIST	args;
+	ACPI_STATUS		status;
+
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+	/* ACPI_SERIAL_ASSERT(thinkpad); */
+
+	args.Count = 2;
+	args.Pointer = arg;
+	arg[0].Type = ACPI_TYPE_INTEGER;
+	arg[1].Type = ACPI_TYPE_INTEGER;
+
+	for (i = 0; i < 32; ++i) {
+		arg[0].Integer.Value = i+1;
+		arg[1].Integer.Value = (((1 << i) & val) != 0);
+		status = AcpiEvaluateObject(sc->handle,
+		    THINKPAD_NAME_EVENTS_MASK_SET, &args, NULL);
+
+		if (ACPI_FAILURE(status))
+			return (status);
+	}
+
+	return (0);
+}
+
+static int
+acpi_thinkpad_sysctl(SYSCTL_HANDLER_ARGS)
+{
+	struct acpi_thinkpad_softc	*sc;
+	int			arg;
+	int			error = 0;
+	int			function;
+	int			method;
+	
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+
+	sc = (struct acpi_thinkpad_softc *)oidp->oid_arg1;
+	function = oidp->oid_arg2;
+	method = acpi_thinkpad_sysctls[function].method;
+
+	/* ACPI_SERIAL_BEGIN(thinkpad); */
+	arg = acpi_thinkpad_sysctl_get(sc, method);
+	error = sysctl_handle_int(oidp, &arg, 0, req);
+
+	/* Sanity check */
+	if (error != 0 || req->newptr == NULL)
+		goto out;
+
+	/* Update */
+	error = acpi_thinkpad_sysctl_set(sc, method, arg);
+
+out:
+	/* ACPI_SERIAL_END(thinkpad); */
+	return (error);
+}
+
+static int
+acpi_thinkpad_sysctl_get(struct acpi_thinkpad_softc *sc, int method)
+{
+	ACPI_INTEGER	val_ec;
+	int 		val = 0, key;
+
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+	/* ACPI_SERIAL_ASSERT(thinkpad); */
+
+	switch (method) {
+	case ACPI_THINKPAD_METHOD_EVENTS:
+		acpi_GetInteger(sc->handle, THINKPAD_NAME_EVENTS_STATUS_GET,
+		    &val);
+		break;
+
+	case ACPI_THINKPAD_METHOD_EVENTMASK:
+		if (sc->events_mask_supported)
+			acpi_GetInteger(sc->handle,
+			    THINKPAD_NAME_EVENTS_MASK_GET, &val);
+		break;
+
+	case ACPI_THINKPAD_METHOD_HOTKEY:
+		/*
+		 * Construct the hotkey as a bitmask as illustrated below.
+		 * Note that whenever a key was pressed, the respecting bit
+		 * toggles and nothing else changes.
+		 * +--+--+-+-+-+-+-+-+-+-+-+-+
+		 * |11|10|9|8|7|6|5|4|3|2|1|0|
+		 * +--+--+-+-+-+-+-+-+-+-+-+-+
+		 *   |  | | | | | | | | | | |
+		 *   |  | | | | | | | | | | +- Home Button
+		 *   |  | | | | | | | | | +--- Search Button
+		 *   |  | | | | | | | | +----- Mail Button
+		 *   |  | | | | | | | +------- Thinkpad Button
+		 *   |  | | | | | | +--------- Zoom (Fn + Space)
+		 *   |  | | | | | +----------- WLAN Button
+		 *   |  | | | | +------------- Video Button
+		 *   |  | | | +--------------- Hibernate Button
+		 *   |  | | +----------------- Thinklight Button
+		 *   |  | +------------------- Screen expand (Fn + F8)
+		 *   |  +--------------------- Brightness
+		 *   +------------------------ Volume/Mute
+		 */
+		key = rtcin(THINKPAD_RTC_HOTKEY1);
+		val = (THINKPAD_RTC_MASK_HOME | THINKPAD_RTC_MASK_SEARCH |
+		    THINKPAD_RTC_MASK_MAIL | THINKPAD_RTC_MASK_WLAN) & key;
+		key = rtcin(THINKPAD_RTC_HOTKEY2);
+		val |= (THINKPAD_RTC_MASK_THINKPAD | THINKPAD_RTC_MASK_VIDEO |
+		    THINKPAD_RTC_MASK_HIBERNATE) & key;
+		val |= (THINKPAD_RTC_MASK_ZOOM & key) >> 1;
+		key = rtcin(THINKPAD_RTC_THINKLIGHT);
+		val |= (THINKPAD_RTC_MASK_THINKLIGHT & key) << 4;
+		key = rtcin(THINKPAD_RTC_SCREENEXPAND);
+		val |= (THINKPAD_RTC_MASK_THINKLIGHT & key) << 4;
+		key = rtcin(THINKPAD_RTC_BRIGHTNESS);
+		val |= (THINKPAD_RTC_MASK_BRIGHTNESS & key) << 5;
+		key = rtcin(THINKPAD_RTC_VOLUME);
+		val |= (THINKPAD_RTC_MASK_VOLUME & key) << 4;
+		break;
+
+	case ACPI_THINKPAD_METHOD_BRIGHTNESS:
+		ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_BRIGHTNESS, &val_ec, 1);
+		val = val_ec & THINKPAD_EC_MASK_BRI;
+		break;
+
+	case ACPI_THINKPAD_METHOD_VOLUME:
+		ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_VOLUME, &val_ec, 1);
+		val = val_ec & THINKPAD_EC_MASK_VOL;
+		break;
+
+	case ACPI_THINKPAD_METHOD_MUTE:
+		val = ((val_ec & THINKPAD_EC_MASK_MUTE) ==
+		    THINKPAD_EC_MASK_MUTE);
+		break;
+
+	case ACPI_THINKPAD_METHOD_THINKLIGHT:
+		if (sc->light_get_supported)
+			acpi_GetInteger(sc->ec_handle, THINKPAD_NAME_KEYLIGHT,
+			    &val);
+		else
+			val = sc->light_val;
+		break;
+
+	case ACPI_THINKPAD_METHOD_BLUETOOTH:
+		acpi_GetInteger(sc->handle, THINKPAD_NAME_WLAN_BT_GET, &val);
+		sc->wlan_bt_flags = val;
+		val = ((val & THINKPAD_NAME_MASK_BT) != 0);
+		break;
+
+	case ACPI_THINKPAD_METHOD_WLAN:
+		acpi_GetInteger(sc->handle, THINKPAD_NAME_WLAN_BT_GET, &val);
+		sc->wlan_bt_flags = val;
+		val = ((val & THINKPAD_NAME_MASK_WLAN) != 0);
+		break;
+
+	case ACPI_THINKPAD_METHOD_FANSPEED:
+		if (sc->fan_handle) {
+			if (ACPI_FAILURE(acpi_GetInteger(sc->fan_handle,
+			    NULL, &val)))
+				val = -1;
+		}
+		else {
+			ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_FANSPEED,
+			    &val_ec, 2);
+			val = val_ec;
+		}
+		break;
+
+	case ACPI_THINKPAD_METHOD_FANLEVEL:
+		/*
+		 * The THINKPAD_EC_FANSTATUS register works as follows:
+		 * Bit 0-5 indicate the level at which the fan operates. Only
+		 *       values between 0 and 7 have an effect. Everything
+		 *       above 7 is treated the same as level 7
+		 * Bit 6 overrides the fan speed limit if set to 1
+		 * Bit 7 indicates at which mode the fan operates:
+		 *       manual (0) or automatic (1)
+		 */
+		if (!sc->fan_handle) {
+			ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_FANSTATUS,
+			    &val_ec, 1);
+			val = val_ec & THINKPAD_EC_MASK_FANLEVEL;
+		}
+		break;
+
+	case ACPI_THINKPAD_METHOD_FANSTATUS:
+		if (!sc->fan_handle) {
+			ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_FANSTATUS,
+			    &val_ec, 1);
+			val = (val_ec & THINKPAD_EC_MASK_FANSTATUS) ==
+			    THINKPAD_EC_MASK_FANSTATUS;
+		}
+		else
+			val = -1;
+		break;
+	}
+
+	return (val);
+}
+
+static int
+acpi_thinkpad_sysctl_set(struct acpi_thinkpad_softc *sc, int method, int arg)
+{
+	int			val, step, i;
+	ACPI_INTEGER		val_ec;
+	ACPI_OBJECT		Arg;
+	ACPI_OBJECT_LIST	Args;
+	ACPI_STATUS		status;
+
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+	/* ACPI_SERIAL_ASSERT(thinkpad); */
+
+	switch (method) {
+	case ACPI_THINKPAD_METHOD_EVENTS:
+		if (arg < 0 || arg > 1)
+			return (EINVAL);
+
+		status = acpi_SetInteger(sc->handle,
+		    THINKPAD_NAME_EVENTS_STATUS_SET, arg);
+		if (ACPI_FAILURE(status))
+			return (status);
+		if (sc->events_mask_supported)
+			return acpi_thinkpad_eventmask_set(sc,
+			    sc->events_availmask);
+		break;
+
+	case ACPI_THINKPAD_METHOD_EVENTMASK:
+		if (sc->events_mask_supported)
+			return acpi_thinkpad_eventmask_set(sc, arg);
+		break;
+
+	case ACPI_THINKPAD_METHOD_BRIGHTNESS:
+		if (arg < 0 || arg > 7)
+			return (EINVAL);
+
+		if (sc->cmos_handle) {
+			/* Read the current brightness */
+			status = ACPI_EC_READ(sc->ec_dev,
+			    THINKPAD_EC_BRIGHTNESS, &val_ec, 1);
+			if (ACPI_FAILURE(status))
+				return (status);
+			val = val_ec & THINKPAD_EC_MASK_BRI;
+
+			Args.Count = 1;
+			Args.Pointer = &Arg;
+			Arg.Type = ACPI_TYPE_INTEGER;
+			Arg.Integer.Value = (arg > val) ?
+			    THINKPAD_CMOS_BRIGHTNESS_UP :
+			    THINKPAD_CMOS_BRIGHTNESS_DOWN;
+
+			step = (arg > val) ? 1 : -1;
+			for (i = val; i != arg; i += step) {
+				status = AcpiEvaluateObject(sc->cmos_handle,
+				    NULL, &Args, NULL);
+				if (ACPI_FAILURE(status))
+					break;
+			}
+		}
+		return ACPI_EC_WRITE(sc->ec_dev, THINKPAD_EC_BRIGHTNESS,
+		    arg, 1);
+		break;
+
+	case ACPI_THINKPAD_METHOD_VOLUME:
+		if (arg < 0 || arg > 14)
+			return (EINVAL);
+
+		status = ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_VOLUME,
+		    &val_ec, 1);
+		if (ACPI_FAILURE(status))
+			return (status);
+
+		if (sc->cmos_handle) {
+			val = val_ec & THINKPAD_EC_MASK_VOL;
+
+			Args.Count = 1;
+			Args.Pointer = &Arg;
+			Arg.Type = ACPI_TYPE_INTEGER;
+			Arg.Integer.Value = (arg > val) ?
+			    THINKPAD_CMOS_VOLUME_UP : THINKPAD_CMOS_VOLUME_DOWN;
+
+			step = (arg > val) ? 1 : -1;
+			for (i = val; i != arg; i += step) {
+				status = AcpiEvaluateObject(sc->cmos_handle,
+				    NULL, &Args, NULL);
+				if (ACPI_FAILURE(status))
+					break;
+			}
+		}
+		return ACPI_EC_WRITE(sc->ec_dev, THINKPAD_EC_VOLUME, arg +
+		    (val_ec & (~THINKPAD_EC_MASK_VOL)), 1);
+		break;
+
+	case ACPI_THINKPAD_METHOD_MUTE:
+		if (arg < 0 || arg > 1)
+			return (EINVAL);
+
+		status = ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_VOLUME,
+		    &val_ec, 1);
+		if (ACPI_FAILURE(status))
+			return (status);
+
+		if (sc->cmos_handle) {
+			val = val_ec & THINKPAD_EC_MASK_VOL;
+
+			Args.Count = 1;
+			Args.Pointer = &Arg;
+			Arg.Type = ACPI_TYPE_INTEGER;
+			Arg.Integer.Value = THINKPAD_CMOS_VOLUME_MUTE;
+
+			status = AcpiEvaluateObject(sc->cmos_handle, NULL,
+			    &Args, NULL);
+			if (ACPI_FAILURE(status))
+				break;
+		}
+		return ACPI_EC_WRITE(sc->ec_dev, THINKPAD_EC_VOLUME, (arg==1) ?
+		   val_ec | THINKPAD_EC_MASK_MUTE :
+		   val_ec & (~THINKPAD_EC_MASK_MUTE), 1);
+		break;
+
+	case ACPI_THINKPAD_METHOD_THINKLIGHT:
+		if (arg < 0 || arg > 1)
+			return (EINVAL);
+
+		if (sc->light_set_supported) {
+			Args.Count = 1;
+			Args.Pointer = &Arg;
+			Arg.Type = ACPI_TYPE_INTEGER;
+			Arg.Integer.Value = arg ?
+			    sc->light_cmd_on : sc->light_cmd_off;
+
+			status = AcpiEvaluateObject(sc->light_handle, NULL,
+			    &Args, NULL);
+			if (ACPI_SUCCESS(status))
+				sc->light_val = arg;
+			return (status);
+		}
+		break;
+
+	case ACPI_THINKPAD_METHOD_BLUETOOTH:
+		if (arg < 0 || arg > 1)
+			return (EINVAL);
+
+		val = (arg == 1) ? sc->wlan_bt_flags |
+		    THINKPAD_NAME_MASK_BT :
+		    sc->wlan_bt_flags & (~THINKPAD_NAME_MASK_BT);
+		return acpi_SetInteger(sc->handle, THINKPAD_NAME_WLAN_BT_SET,
+		    val);
+		break;
+
+	case ACPI_THINKPAD_METHOD_FANLEVEL:
+		if (arg < 0 || arg > 7)
+			return (EINVAL);
+
+		if (!sc->fan_handle) {
+			/* Read the current fanstatus */
+			ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_FANSTATUS,
+			    &val_ec, 1);
+			val = val_ec & (~THINKPAD_EC_MASK_FANLEVEL);
+
+			return ACPI_EC_WRITE(sc->ec_dev, THINKPAD_EC_FANSTATUS,
+			    val | arg, 1);
+		}
+		break;
+
+	case ACPI_THINKPAD_METHOD_FANSTATUS:
+		if (arg < 0 || arg > 1)
+			return (EINVAL);
+
+		if (!sc->fan_handle) {
+			/* Read the current fanstatus */
+			ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_FANSTATUS,
+			    &val_ec, 1);
+
+			return ACPI_EC_WRITE(sc->ec_dev, THINKPAD_EC_FANSTATUS,
+			    (arg == 1) ? (val_ec | THINKPAD_EC_MASK_FANSTATUS) :
+			    (val_ec & (~THINKPAD_EC_MASK_FANSTATUS)), 1);
+		}
+		break;
+	}
+
+	return (0);
+}
+
+static int
+acpi_thinkpad_sysctl_init(struct acpi_thinkpad_softc *sc, int method)
+{
+	int 			dummy;
+	ACPI_OBJECT_TYPE 	cmos_t;
+	ACPI_HANDLE		ledb_handle;
+
+	switch (method) {
+	case ACPI_THINKPAD_METHOD_EVENTS:
+		/* Events are disabled by default */
+		return (TRUE);
+
+	case ACPI_THINKPAD_METHOD_EVENTMASK:
+		return (sc->events_mask_supported);
+
+	case ACPI_THINKPAD_METHOD_HOTKEY:
+	case ACPI_THINKPAD_METHOD_BRIGHTNESS:
+	case ACPI_THINKPAD_METHOD_VOLUME:
+	case ACPI_THINKPAD_METHOD_MUTE:
+		/* EC is required here, which was already checked before */
+		return (TRUE);
+
+	case ACPI_THINKPAD_METHOD_THINKLIGHT:
+		sc->cmos_handle = NULL;
+		sc->light_get_supported = ACPI_SUCCESS(acpi_GetInteger(
+		    sc->ec_handle, THINKPAD_NAME_KEYLIGHT, &sc->light_val));
+
+		if ((ACPI_SUCCESS(AcpiGetHandle(sc->handle, "\\UCMS",
+		    &sc->light_handle)) ||
+		    ACPI_SUCCESS(AcpiGetHandle(sc->handle, "\\CMOS",
+		    &sc->light_handle)) ||
+		    ACPI_SUCCESS(AcpiGetHandle(sc->handle, "\\CMS",
+		    &sc->light_handle))) &&
+		    ACPI_SUCCESS(AcpiGetType(sc->light_handle, &cmos_t)) &&
+		    cmos_t == ACPI_TYPE_METHOD) {
+			sc->light_cmd_on = 0x0c;
+			sc->light_cmd_off = 0x0d;
+			sc->cmos_handle = sc->light_handle;
+		}
+		else if (ACPI_SUCCESS(AcpiGetHandle(sc->handle, "\\LGHT",
+		    &sc->light_handle))) {
+			sc->light_cmd_on = 1;
+			sc->light_cmd_off = 0;
+		}
+		else
+			sc->light_handle = NULL;
+
+		sc->light_set_supported = (sc->light_handle &&
+		    ACPI_FAILURE(AcpiGetHandle(sc->ec_handle, "LEDB",
+		    &ledb_handle)));
+
+		if (sc->light_get_supported)
+			return (TRUE);
+
+		if (sc->light_set_supported) {
+			sc->light_val = 0;
+			return (TRUE);
+		}
+
+		return (FALSE);
+
+	case ACPI_THINKPAD_METHOD_BLUETOOTH:
+	case ACPI_THINKPAD_METHOD_WLAN:
+		if (ACPI_SUCCESS(acpi_GetInteger(sc->handle,
+		    THINKPAD_NAME_WLAN_BT_GET, &dummy)))
+			return (TRUE);
+		return (FALSE);
+
+	case ACPI_THINKPAD_METHOD_FANSPEED:
+		/* 
+		 * Some models report the fan speed in levels from 0-7
+		 * Newer models report it contiguously
+		 */
+		sc->fan_levels = (ACPI_SUCCESS(AcpiGetHandle(sc->handle, "GFAN",
+		    &sc->fan_handle)) ||
+		    ACPI_SUCCESS(AcpiGetHandle(sc->handle, "\\FSPD",
+		    &sc->fan_handle)));
+		return (TRUE);
+
+	case ACPI_THINKPAD_METHOD_FANLEVEL:
+	case ACPI_THINKPAD_METHOD_FANSTATUS:
+		/* 
+		 * Fan status is only supported on those models,
+		 * which report fan RPM contiguously, not in levels
+		 */
+		if (sc->fan_levels)
+			return (FALSE);
+		return (TRUE);
+
+	case ACPI_THINKPAD_METHOD_THERMAL:
+		if (ACPI_SUCCESS(acpi_GetInteger(sc->ec_handle,
+		    THINKPAD_NAME_THERMAL_GET, &dummy))) {
+			sc->thermal_updt_supported =
+			    ACPI_SUCCESS(acpi_GetInteger(sc->ec_handle,
+			    THINKPAD_NAME_THERMAL_UPDT, &dummy));
+			return (TRUE);
+		}
+		return (FALSE);
+	}
+	return (FALSE);
+}
+
+static void
+acpi_thinkpad_notify(ACPI_HANDLE h, UINT32 notify, void *context)
+{
+	int		event, arg, type;
+	device_t	dev = context;
+	struct acpi_thinkpad_softc *sc = device_get_softc(dev);
+
+	ACPI_FUNCTION_TRACE_U32((char *)(uintptr_t)__func__, notify);
+
+	if (notify != 0x80)
+		device_printf(dev, "Unknown notify\n");
+
+	for (;;) {
+		acpi_GetInteger(acpi_get_handle(dev), THINKPAD_NAME_EVENTS_GET,
+		    &event);
+
+		if (event == 0)
+			break;
+
+		type = (event >> 12) & 0xf;
+		arg = event & 0xfff;
+		switch (type) {
+		case 1:
+			if (!(sc->events_availmask & (1 << (arg - 1)))) {
+				device_printf(dev, "Unknown key %d\n", arg);
+				break;
+			}
+
+			/* Notify devd(8) */
+			device_printf(dev, "THINKPAD event: %u\n",
+			    (arg & 0xff));
+			acpi_UserNotify("THINKPAD", h, (arg & 0xff));
+			break;
+		default:
+			break;
+		}
+	}
+}
+
+static void
+acpi_thinkpad_refresh(void *arg)
+{
+	struct acpi_thinkpad_softc *sc = (struct acpi_thinkpad_softc *)arg;
+	char temp_cmd[] = "TMP0";
+	int data, i;
+	ACPI_INTEGER speed;
+
+	for (i = 0; i < 8; i++) {
+		temp_cmd[3] = '0' + i;
+		
+                /*
+                 * The TMPx methods seem to return +/- 128 or 0
+                 * when the respecting sensor is not available
+                 */
+		sc->sensors[i].flags &= ~SENSOR_FINVALID;
+                if (ACPI_FAILURE(acpi_GetInteger(sc->ec_handle, temp_cmd,
+                    &data)) || ABS(data) == 128 || data == 0) {
+			sc->sensors[i].flags |= SENSOR_FINVALID;
+                        data = 0;
+		}
+                else if (sc->thermal_updt_supported) {
+                        /* XXX: Temperature is reported in tenth of Kelvin */
+                        data = (data - 2732 + 5) / 10;
+		}
+		sc->sensors[i].value = data * 1000000 + 273150000;
+        }
+	
+	sc->sensors[8].flags &= ~SENSOR_FINVALID;
+	if (sc->fan_handle) {
+		if (ACPI_FAILURE(acpi_GetInteger(sc->fan_handle,
+		    NULL, &data)))
+			sc->sensors[8].flags |= SENSOR_FINVALID;
+                        data = -1;
+        }
+        else {
+                ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_FANSPEED, &speed, 2);
+                data = speed;
+        }
+
+	sc->sensors[8].value = data;
+}
diff --git a/sys/platform/pc32/conf/files b/sys/platform/pc32/conf/files
--- a/sys/platform/pc32/conf/files
+++ b/sys/platform/pc32/conf/files
@@ -72,6 +72,7 @@ dev/serial/dgb/dgm.c			optional	dgm
 ${OSACPI_MD_DIR}/acpi_machdep.c		optional        acpi
 ${OSACPI_MD_DIR}/acpi_wakeup.c		optional        acpi
 ${OSACPI_MD_DIR}/acpi_toshiba.c		optional        acpi_toshiba acpi
+${ACPICA_DIR}/acpi_thinkpad/acpi_thinkpad.c optional	acpi_thinkpad acpi
 acpi.h					optional	acpi		\
 	dependency	"$S/${ACPICA_DIR}/include/acpi.h"		\
 	compile-with	"cp $S/${ACPICA_DIR}/include/acpi.h ${.OBJDIR}/"	\



From hasso at estpak.ee  Thu Mar 20 03:49:13 2008
From: hasso at estpak.ee (Hasso Tepper)
Date: Thu, 20 Mar 2008 03:49:13 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Some questions regarding ACPI
In-Reply-To: <200803191322.46366.hasso@estpak.ee>
Message-ID: <200803201237.28823.hasso@estpak.ee>

Hasso Tepper wrote:
> There is also one fatal issue -laptop locks up hardly (no panic) while 
> unloading module. Any idea regarding this is welcome.

Nevermind, solved.


-- 
Hasso




From dillon at apollo.backplane.com  Fri Mar 21 19:24:01 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Fri, 21 Mar 2008 19:24:01 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: panic: assertion: hammer_btree_cmp(cursor->left_bound,	&cursor->node->ondisk->elms[0].leaf.base) <= 0 in btree_split_leaf
In-Reply-To: <200802232204.m1NM4cxd046264@apollo.backplane.com>
Message-ID: <200803220212.m2M2CiAY014435@apollo.backplane.com>

:While trying to find a procedure to reliably reproduce the panic
:I reported last time, I caught a different panic (uploaded at
: ~y0netan1/crash/9/ on my leaf account).  I wrote the following shell
:script (make sure to edit variables DISKS and MOUNTPT before using this
:script or it may trash your system):

    Ok, I believe I have fixed the left_bound assertion.  I also believe
    I have fixed the node ref count assertion on umount.

    There is currently one unfixed assertion related to the I/O
    path... sometimes the bp is being improperly disassociated from the
    related HAMMER structure.

    The full-filesystem case is still not being handled so don't test that :-)

					    -Matt





From c.turner at 199technologies.org  Sun Mar 23 09:48:29 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Sun, 23 Mar 2008 09:48:29 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
Message-ID: <47E6870C.4080709@199technologies.org>

I'm finally getting around to doing 1.12 upgrades, and have setup a 
separate machine to do my bulk package builds / upgrades etc,
so as not to disrupt my 'dev server' while things are being
built / tested

However, this seems kind of wasteful - the only purpose of this machine
is to build packages against a specific release..
And since building packages for a particular release generally requires 
only the userland, appropriate headers and correct 'uname' output - so:

it seems like if spoofing uname is configured inside a jail,
the next (or previous..) release can be installed into a jail and
used for building / testing packages without the overhead of a VM or 
maintaining a separate physical host

I did a quick scan of the tree to see what this would take, and, high 
level, it seems like only the following changes would need to be made:

- update struct jail to add a 'osrelease' string
  (implies bumping 'jail api' to 2?)
- update jail(8) to actually pass this information along
- update sys_uname to test ucred for jailed processes, and
  use the struct jail osrelease if appropriate
- similarly update sysctl kern.osrelease to support jail spoofing
  (if possible - didn't get this far in the research yet)
  could be less of a problem for builds, as I think most things use
 uname(1) ... but good to keep the environment consistent I suppose..
I'm still a bit confused as to how 'osrelease' is defined - everything
I'm finding is showing up as extern char[] .. perhaps this is something 
in the build I'm not familiar with?

also,

is the so-called 'stupid hackery' in sys_uname needed still?

Before I start any coding, does this:

- sound like something useful
- sound like the right approach
Thinking this could have wider useful implications e.g. for pkgbox
& so on -  for example setting up automated bulks w/various combinations 
of pkgsrc and releases, etc.

Cheers,

- Chris





From corecode at fs.ei.tum.de  Sun Mar 23 10:06:38 2008
From: corecode at fs.ei.tum.de (Simon 'corecode' Schubert)
Date: Sun, 23 Mar 2008 10:06:38 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <47E68C74.3080808@fs.ei.tum.de>

Chris Turner wrote:
I did a quick scan of the tree to see what this would take, and, high 
level, it seems like only the following changes would need to be made:
brave investigation.  but you could also simply set UNAME_r :)

sweatshorts % uname -r
1.13.0-DEVELOPMENT
sweatshorts % UNAME_r=1.12-RELEASE uname -r
1.12-RELEASE
I think that's good enough :D

cheers
  simon
--
Serve - BSD     +++  RENT this banner advert  +++    ASCII Ribbon   /"\
Work - Mac      +++  space for low ????????? NOW!1  +++      Campaign     \ /
Party Enjoy Relax   |   http://dragonflybsd.org      Against  HTML   \
Dude 2c 2 the max   !   http://golden-apple.biz       Mail + News   / \




From c.turner at 199technologies.org  Sun Mar 23 10:50:13 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Sun, 23 Mar 2008 10:50:13 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <47E69656.8080605@199technologies.org>

Simon 'corecode' Schubert wrote:
brave investigation.  but you could also simply set UNAME_r :)
Doh! Thanks for the tip!

they should change the phrase from RTFM to 'Carefully RTFM' :)

well.. scratch that change then. 1 less patch to write.

- Chris





From c.turner at 199technologies.org  Sun Mar 23 11:15:52 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Sun, 23 Mar 2008 11:15:52 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <47E69C7C.8010109@199technologies.org>

Chris Turner wrote:
Simon 'corecode' Schubert wrote:
brave investigation.  but you could also simply set UNAME_r :)

for the record - if anyone's interested - adding a line e.g.:

ALL_ENV+= UNAME_r=1.12-RELEASE

to mk.conf looks like it -might- work ..

(unless wants to chime in & verify)





From joerg at britannica.bec.de  Sun Mar 23 11:46:53 2008
From: joerg at britannica.bec.de (Joerg Sonnenberger)
Date: Sun, 23 Mar 2008 11:46:53 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <20080323181428.GA2099@britannica.bec.de>

On Sun, Mar 23, 2008 at 01:41:42PM -0400, Chris Turner wrote:
> they should change the phrase from RTFM to 'Carefully RTFM' :)

RTFMAI -- Read The Fine Manual Again, Idiot.

Joerg




From dillon at apollo.backplane.com  Sun Mar 23 20:05:36 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Sun, 23 Mar 2008 20:05:36 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
Message-ID: <200803240257.m2O2voNH038355@apollo.backplane.com>

    Here's an update on the HAMMER work!

    Current status:

    * Passes all standard filesystem stress tests and buildworld will
      run with a HAMMER /usr/obj.  Large histories are able to accumulate
      without effecting performance.

    * Pruning and reblocking code is in and partially tested, but now needs
      more stringent testing.

    * Full historical access appears to be working but needs testing.
      Note that a sync is still needed to flush dirty cached data prior
      to acquiring a timestamp for the 'snapshot' to be set in stone.
      (dirty data cached in-memory has no historical tags and must be
      committed to physical disk before it can be accessed historically).


    Current bugs:

    * There is one known bug in the standard operations code paths
      that results in an assertion in HAMMER's I/O subsystem.

    * There are probably bugs in the reblocking and/or pruning code.  More
      likely in the reblocking code.


    There are two big-ticket and several little-ticket items left.  HAMMER
    will officially go Alpha when the big-ticket items are done, and beta
    when we get a few of the little-ticket items done.

    Big ticket items left:

    * UNDO (crash recovery) code.  Currently it writes out undo records but
      they are not yet sequenced, buffer writes are not yet ordered, and
      there is no mount-time recovery code yet.

      This is the last item needed before HAMMER can go operational.

    * Filesystem full handling.  Currently no space is reserved for dirty
      cached data so it is possible to create/write files and for HAMMER
      to not have sufficient space left on-disk to flush it.


    Little ticket items:

    * Automated reblocking (currently these functions are manually
      initialized via the hammer utility).

    * I/O clustering and preliminary BMAP op when writing out large files.

    * CRC checking (CRC fields are reserved but not entirely generated yet
      and not yet checked at all).

    * Disaster Recovery filesystem scan.

    * Boot support.

    I expect all of these items and more to be handled by the 2.0 release
    in July.

			    Additional HAMMER capabilities
				(no timeline yet)

    * Adding, removing, and resizing a HAMMER filesystem's backing store.

			Ultimate Goals and working towards them
				(no timeline yet)

    Our ultimate goal with HAMMER and DragonFly in general is to support
    fully cache coherent replication in a multi-machine environment.  This
    involves several steps and networking protocols.

    * Replication of synchronization streams based on the UNDO log.  If
      resynchronizing to a target which is too old a B-Tree scan will
      likely be required.

    * Cache coherency protocols for machine-machine coherency for both
      replicated and remote-HAMMER access.

    I have no time frame for these items yet.  It will depend on how quickly
    HAMMER moves to Alpha and Beta status.  I will say, however, now
    that HAMMER's on-disk format has solidified, that I have a very precise
    understanding of the protocols that will be needed to accomplish fully
    cache coherent remote access for both replicated and non-replicated
    (remote mount style) access.

    And, as you know, fully coherent filesystem access across machines is
    going to be the basis for DragonFly's clustering across said machines.

    In summary, things are progressing very well.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From justin at shiningsilence.com  Sun Mar 23 20:10:13 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Sun, 23 Mar 2008 20:10:13 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <53758.192.168.0.252.1206327873.squirrel@www.shiningsilence.com>

On Sun, March 23, 2008 12:36 pm, Chris Turner wrote:

> it seems like if spoofing uname is configured inside a jail,
> the next (or previous..) release can be installed into a jail and
> used for building / testing packages without the overhead of a VM or
> maintaining a separate physical host

If you don't need a jail to spoof uname, as others posted, you can
installworld into a chroot and build everything you want there using
Joerg's spiffy pbulk.  That's what I'm doing on pkgbox now; I can hand you
my somewhat terse notes if you want.  It would be relatively easy to set
up the configuration you're talking about.





From sepherosa at gmail.com  Sun Mar 23 20:18:20 2008
From: sepherosa at gmail.com (Sepherosa Ziehau)
Date: Sun, 23 Mar 2008 20:18:20 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <ea7b9c170803232012n2f27f893tf1d756d7c9770419@mail.gmail.com>

On Mon, Mar 24, 2008 at 2:14 AM, Joerg Sonnenberger
<joerg at britannica.bec.de> wrote:
> On Sun, Mar 23, 2008 at 01:41:42PM -0400, Chris Turner wrote:
>  > they should change the phrase from RTFM to 'Carefully RTFM' :)
>
>  RTFMAI -- Read The Fine Manual Again, Idiot.

http://leaf.dragonflybsd.org/~sephe/rtfm.jpg

:D

>
>  Joerg
>



-- 
Live Free or Die




From justin at shiningsilence.com  Sun Mar 23 20:38:30 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Sun, 23 Mar 2008 20:38:30 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: GSoC 2008 - mentors signup
Message-ID: <53885.192.168.0.252.1206329503.squirrel@www.shiningsilence.com>

If you are planning to be a mentor for a Summer of Code project, please
sign up here for the mentors mailing list:

http://groups.google.com/group/google-summer-of-code-mentors-list

If you've already signed up, your subscription should be set up tomorrow.





From justin at shiningsilence.com  Sun Mar 23 21:12:01 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Sun, 23 Mar 2008 21:12:01 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: GSoC 2008 - mentors signup
In-Reply-To: <53885.192.168.0.252.1206329503.squirrel@www.shiningsilence.com>
Message-ID: <54025.192.168.0.252.1206331572.squirrel@www.shiningsilence.com>

Also!

If you are a potential mentor and you have not done so yet:

http://code.google.com/soc/mentor_step1.html

Get yourself registered as a mentor for the Summer of Code project.  Once
you are in there, check off DragonFly in the "My Profile" section.

You will need a Google Account if you don't have one:

http://www.google.com/accounts

This will add you to the list of mentors in the Google Summer of Code web
application, so you can review/be attached to projects.

A guide is available if you want more information:

http://groups.google.com/group/google-summer-of-code-announce/web/guide-to-the-gsoc-web-app-for-mentors-and-organization-administrators






From c.turner at 199technologies.org  Mon Mar 24 04:29:28 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Mon, 24 Mar 2008 04:29:28 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <47E78ECE.4070307@199technologies.org>

Justin C. Sherrill wrote:
If you don't need a jail to spoof uname, as others posted, you can
installworld into a chroot and build everything you want there using
Joerg's spiffy pbulk.  That's what I'm doing on pkgbox now; I can hand you
my somewhat terse notes if you want.  It would be relatively easy to set
up the configuration you're talking about.
cheers - I guess I thought incorrectly that something 'special' was 
needed to get the uname to change .. have been using the legacy bulks in 
chroots / jails (for 'same os' builds) as I haven't quite migrated to 
pbulk yet ..

thanks for the help offer - I'll ask if I run into trouble.




From dillon at apollo.backplane.com  Mon Mar 24 08:28:49 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Mon, 24 Mar 2008 08:28:49 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <200803241500.m2OF0CG8043760@apollo.backplane.com>


:http://leaf.dragonflybsd.org/~sephe/rtfm.jpg
:
::D

    Ho!

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From elekktretterr at exemail.com.au  Mon Mar 24 09:10:15 2008
From: elekktretterr at exemail.com.au (Petr Janda)
Date: Mon, 24 Mar 2008 09:10:15 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
In-Reply-To: <200803240257.m2O2voNH038355@apollo.backplane.com>
Message-ID: <200803250138.49775.elekktretterr@exemail.com.au>


>
>     And, as you know, fully coherent filesystem access across machines is
>     going to be the basis for DragonFly's clustering across said machines.
>
>     In summary, things are progressing very well.
>


Hi Matt,
That's good to know things are going so well. Got a question. If memory serves 
me right, initially there was also going to be a thing called ANVIL, I can't 
remember what it was supposed to do and whether its still in your design. 
Could you elaborate a little?

Thanks,
Petr




From dillon at apollo.backplane.com  Mon Mar 24 14:12:11 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Mon, 24 Mar 2008 14:12:11 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
In-Reply-To: <200803240257.m2O2voNH038355@apollo.backplane.com>
Message-ID: <200803242100.m2OL0nWV046868@apollo.backplane.com>


:Hi Matt,
:That's good to know things are going so well. Got a question. If memory serves 
:me right, initially there was also going to be a thing called ANVIL, I can't 
:remember what it was supposed to do and whether its still in your design. 
:Could you elaborate a little?
:
:Thanks,
:Petr

    It's not really in the HAMMER design any more, primarily because HAMMER's
    volume model seems to work fine as-is.  Ultimately something like ANVIL
    (a block storage manager) would prove beneficial to the project but it
    would be treated as a separate project.  HAMMER's redundancy model is
    going to be baesd around replication and clustering.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From tgen at netphreax.net  Mon Mar 24 18:31:37 2008
From: tgen at netphreax.net (Thomas E. Spanjaard)
Date: Mon, 24 Mar 2008 18:31:37 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
In-Reply-To: <200803240257.m2O2voNH038355@apollo.backplane.com>
Message-ID: <47E85337.2070407@netphreax.net>

Matthew Dillon wrote:
    * Full historical access appears to be working but needs testing.
      Note that a sync is still needed to flush dirty cached data prior
      to acquiring a timestamp for the 'snapshot' to be set in stone.
      (dirty data cached in-memory has no historical tags and must be
      committed to physical disk before it can be accessed historically).
Wouldn't making timestamp queries (at least from userland) enforce a 
sync on the volume in question be useful here?
--
        Thomas E. Spanjaard
        tgen at netphreax.net
Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00005.pgp
Type: application/octet-stream
Size: 186 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080324/3077333f/attachment-0016.obj>

From dillon at apollo.backplane.com  Mon Mar 24 20:10:12 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Mon, 24 Mar 2008 20:10:12 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
In-Reply-To: <200803240257.m2O2voNH038355@apollo.backplane.com>
Message-ID: <200803250302.m2P32qLP050160@apollo.backplane.com>


:Wouldn't making timestamp queries (at least from userland) enforce a 
:sync on the volume in question be useful here?
:-- 
:         Thomas E. Spanjaard
:         tgen at netphreax.net

    Making the 'hammer now' command do a sync() is a good idea.  I will
    make that change right now so it doesn't get lost.

    Here's a general overview of the issues involved with having historical
    access to the filesystem:

				----------------

    Recording the timestamps in the in-memory cache, for a finer-grained
    snapshot capability, is doable but has its own issues.  Here's an
    illustration:

    open()  create file
    write() append 4K	(file size now 4K)
    write() append 4K	(file size now 8K)
    write() append 4K	(file size now 12K)
    write() append 4K	(file size now 16K)

    Now NONE of this has gone to disk yet, it's entirely in the in-memory
    cache.  The inode is in the in-memory cache.  The data is stored in
    the buffer cache.  Even the directory entry for the file that we
    just created is still in the in-memory cache (HAMMER caches the raw
    records it intends to commit later on).

    If I wanted to be able to acquire a timestamp between each write and
    'see' a snapshot of the file as of any point in the above sequence,
    then every write would also have to allocate a copy of the inode
    (because it changes size on each write).

    The data has the same problem though with a slightly different example.
    Lets say each write() was a seek-write, overwriting the previous data.
    Now with every write() I would have to allocate a copy of the data
    being overwritten.  This is complicated by the fact that the buffer
    cache has no clue about 'historical' accesses, so I would not be able
    to use the buffer cache to cache the data.

    There's also another problem and that is with the efficiency of the
    topology on-disk.  Even if I maintained all the copies of the inode
    and all the copies of the data in-memory, I would still have to sync
    all those copies to disk in order for things to remain historically
    coherent (whether it be in-cache or on-disk).  This would result in
    hundreds or even thousands of copies of the inode on-disk, not to
    mention potentially many copies of the data.

    I just don't want to do that right now, at least not as a default.  A
    lot of performance would be lost.  Hence a sync() is needed if
    you want to create a demark which you can accurately snapshot.

				-------------

    Here's a quick synopsis of how the cache would operate in a clustered
    filesystem:

    In order to properly integrate with in-memory caches, a wider cache
    coherency infrastructure is needed between machines such that
    modifications made on one machine proactively invalidate those
    protions of the cache(s) on other machines.  At the same time, any
    'dirty' cache data, for example when a file is created or written to,
    must lock the cache space in question on all other machines.
    The cache space in this case is not just the file data, but also the
    related namespaces (for creations, deletions, and renames).  Attempts
    to access locked spaces from other machines in the cluster would have
    to force a flush to the filesystem backing store and lower the cache
    states for the effected information on the original machine from dirty
    to shared-read-only.

    It will be easiest to integrate the cache coherency information into
    the buffer cache and namecache themselves.  Once a machine has dirtied
    an in-memory cache element... for example part of the namespace when
    creating a file or chunks of data written within a file, that machine
    must have a free hand to make further modifications to the cache spaces
    involved without further interaction with other machines.

				-------------

    Now, if you think of those two major elements you can see that they
    actually fit together quite well.  If I were to attempt to maintain
    transactional coherency on a per-system-call basis then the cache
    granularity between machines would have to be much, much smaller then
    our current in-memory caching elements provide.  That would become
    a really nasty coding problem.  So I don't even want to begin to
    complate transactional coherency at a finer-grain then sync() or
    fsync() until long after we actually have clustering working.

						-Matt





From elekktretterr at exemail.com.au  Mon Mar 24 21:56:58 2008
From: elekktretterr at exemail.com.au (Petr Janda)
Date: Mon, 24 Mar 2008 21:56:58 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
In-Reply-To: <200803240257.m2O2voNH038355@apollo.backplane.com>
Message-ID: <200803251516.16407.elekktretterr@exemail.com.au>

So is it needed to run hammer now in order to "create" a snapshot? What would 
I do in situation like this: got a hammer filesystem and couple of the files 
change on day to day basis. Then a week later I needed to access one of the 
files, in exactly the state they were 7 days ago.

Cheers,
Petr




From dillon at apollo.backplane.com  Mon Mar 24 22:34:15 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Mon, 24 Mar 2008 22:34:15 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
In-Reply-To: <200803240257.m2O2voNH038355@apollo.backplane.com>
Message-ID: <200803250526.m2P5QZ5X051081@apollo.backplane.com>


:So is it needed to run hammer now in order to "create" a snapshot? What would 
:I do in situation like this: got a hammer filesystem and couple of the files 
:change on day to day basis. Then a week later I needed to access one of the 
:files, in exactly the state they were 7 days ago.
:
:Cheers,
:Petr

    No, you do not have to run 'hammer now' to create a snapshot.  The
    kernel syncs all filesystems every 30 seconds, so if you do nothing
    at all you get a snapshot granularity of 30 seconds.

    Where you would use 'hammer now' is if you wanted the most current
    snapshot possible for the purpose of, say, backing up your filesystem
    to another machine.  You might do something like this:

	set timestamp = `hammer now`
	cpdup /mountpoint/@@$timestamp targethost:/somepath

    But if you didn't care about that you could just go back far enough
    that you get a stable historical view... e.g. go back 1 minute and you
    would have a stable view into your filesystem.

	set timestamp = `hammer stamp 60s`		<------ doesn't sync
	cpdup /mountpoint/@@$timestamp targethost:/somepath


    Ultimately the idea of managing filesystems this way is to still do
    regular backups from your production machine to your backup machine
    (ultimately by way of replication), with both running HAMMER, but only
    retain a limited amount of history on the production box.  You might
    desire to retain only one week's worth of history on the production box,
    retain one month's history on your local backup box, and retain a very
    granular one year's worth of history on your remote backup box.

    Come to think of it, I should add some more directives to the
    'hammer prune' command to make that easier to specify.

    Until I implement a live replication 'feed' the minimum granularity on
    the backup box will be how often you do your backups (e.g. once a day),
    and you can prune it into more granular forms from that starting point.
    Once we have a live replication feed the backup box will have the same
    30-second granularity that the production machine has.

    A major bullet point for this style of management is that the retention
    policy on the various boxes can be different even though they are
    all slaved off the same production filesystem.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From justin at shiningsilence.com  Tue Mar 25 05:58:49 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Tue, 25 Mar 2008 05:58:49 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: SoC - student signups
Message-ID: <58180.65.106.147.226.1206449676.squirrel@www.shiningsilence.com>

Here's a quick link roundup:

Are you a student?  Put in your application for a Google Summer of Code here:

http://code.google.com/soc/2008/student_signup.html

Student guide:
http://groups.google.com/group/google-summer-of-code-announce/web/guide-to-the-gsoc-web-app-for-student-applicants

Are you a mentor?  (That means hasso, hsu, sephe, matthias, TGEN, and
corecode right now)

Student proposals will show up on the mentor page, linked below.  You will
get to rate them, and take the one(s) that you want to mentor.

Mentor page:
http://code.google.com/soc/2008/mentor_home.html
Mentor guide:
http://groups.google.com/group/google-summer-of-code-announce/web/guide-to-the-gsoc-web-app-for-mentors-and-organization-administrators

If you are a mentor and are communicating with potential students, send
them the URLs above for student signup and the student guide; work with
them if they ask for advice on what to say in the application.  They can
resubmit up to 20 times if they want to correct it.

Deadline is March 31st.






From noah.yan at gmail.com  Thu Mar 27 20:17:48 2008
From: noah.yan at gmail.com (Yonghong Yan)
Date: Thu, 27 Mar 2008 20:17:48 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: About DFBSD.64
In-Reply-To: <47EB0B5B.5020802@gmail.com>
Message-ID: <59521b110803272015y1cc8cc39uc93f154ed36e0505@mail.gmail.com>

thanks for your interest.

I owe to everybody for any update or work in the past four months. so
many things happen in my work and my family (they are all good:) and
keep me extremely busy. But i am not leaving and will be back on this
soon.

the latest sources are in http://repo.or.cz/w/dragonfly/port-amd64.git
, I did have a compiled kernel long time before, but I have to break
it to work on the pmap. you can pick up from there. TGEN will help you
a lot, also keep me posted too, if you like.

Noah

On Wed, Mar 26, 2008 at 9:50 PM, Sdavtaker <sdavtaker at gmail.com> wrote:
> Hello,
>  Im applying to GSoC to work in the x64 version of DFBSD with TGEN, i
>  found some work already done in the repository and some mails in the
>  archive from you.
>  I was wondering if you already had a working compiled kernel in AMD64
>  machine and what was not working yet to continue that work.
>  Thanks for any info.
>  Sdav
>




From dillon at apollo.backplane.com  Sat Mar 29 13:27:43 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Sat, 29 Mar 2008 13:27:43 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 29-Mar-2008
Message-ID: <200803292022.m2TKMLGe004942@apollo.backplane.com>

    Good progress continues to be made.  HAMMER survived acting as my
    LAN backup machine (in full historical mode) for almost a week before
    it hit an assertion.  I've fixed that issue and believe that the core
    filesystem implementation code is now 'very stable'.

    Note that the recent commit will result in many more 'hammer_lock_ex:'
    messages on the console then you may have previously observed.  This is
    due to the way object id's are allocated in the face of parallel 
    modifications to the filesystem, resulting in too much locality of
    reference in the B-Tree.  I do intend to improve it.

    I am still working on the two major items needed before HAMMER can be
    declared operational, those being the filesystem full handling and the
    undo/recovery-on-mount code.  These are the last 'hard' bits left in
    the design.

    With exception to filling up the filesystem, which *will* create a mess,
    and noting that no crash recovery code exists yet (so you have to newfs
    it if you crash), I'd appreciate it if interested parties could test
    the other functions of the filesystem, in particular the pruning and
    reblocking functions (man hammer), and the historical access functions.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From dillon at apollo.backplane.com  Sun Mar 30 15:11:03 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Sun, 30 Mar 2008 15:11:03 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Need ideas on how to solve an st_ino/st_dev test issue for HAMMER.
Message-ID: <200803302207.m2UM7BCp016402@apollo.backplane.com>

    Here's the problem, given historical access softlinks as shown below:

test30# ls -lda cra*
drwxr-xr-x  1 root  wheel  Mar 29 13:04 crater
lrwxr-xr-x  1 root  wheel  Mar 29 18:57 crater.20080329 -> crater@@0x47eef383
lrwxr-xr-x  1 root  wheel  Mar 30 01:24 crater.20080330 -> crater@@0x47ef4e29
-rw-r--r--  2 root  wheel  Mar 30 01:24 crater.log

    The problem is that if I do this:

    diff -r crater.20080329/var/log crater.20080330/var/log

    Diff just returns without actually diffing anything.  The reason is
    because diff checks st_ino and st_dev and believes the directories/files
    to be identical because they match.

    I considered munging the inode number for historical accesses, but
    that would seriously break NFS exports which try to access historical
    files and directories.  Right now NFS *is* able to distinguish between
    the two because NFS handles are 128-bit-wide entities, so I can encode
    the as-of transaction id as part of the filehandle.  But userland
    programs only have access to a 64-bit-wide inode so userland still
    believes the files to be identical.

    st_dev is only 32 bits, carefully munging it is an option if we
    could figure out a way to do it, but I'd rather not.

    I am considering using st_gen but then we'd have to patch third
    party software to test st_gen along with everything else.  This may
    be the only workable solution, though, and only a few programs would
    need to be patched.  st_gen is only 32 bits but it would solve the
    problem as we would be able to use all 32 bits.

    If anyone has any bright ideas, including 'leave it alone', I'm all
    ears.

						-Matt





From justin at shiningsilence.com  Mon Mar 31 10:40:42 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Mon, 31 Mar 2008 10:40:42 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: SoC student applications due by 5PM PDT tomorrow
In-Reply-To: <1942.192.168.0.242.1206930479.squirrel@www.shiningsilence.com>
Message-ID: <11892.67.108.184.175.1206984967.squirrel@www.shiningsilence.com>

On Sun, March 30, 2008 10:27 pm, Justin C. Sherrill wrote:
> SoC students:
>
> If you have an application to submit for DragonFly/Summer of Code, please
> do so by 17:00 Pacific time on the 31st - that's tomorrow, at least for
> me.

The deadline for student proposals has been extended to April 7th; all
other dates move forward one week to acommodate.

This is a good time to update existing applications or submit new ones. 
Talk to your (potential) mentors if you are curious.






From nthery at gmail.com  Mon Mar 31 11:29:49 2008
From: nthery at gmail.com (Nicolas Thery)
Date: Mon, 31 Mar 2008 11:29:49 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
Message-ID: <64fc43b0803311126na7d0b27obaa9d35bac6d32ee@mail.gmail.com>

Hello,

Now that the release is over, I'll try to get rid of zones and migrate
allocations to objcache.

Here is a 1st patch that migrate struct proc.  I'll commit it in a
couple of days if nobody objects.

I'm also implementing a way to monitor objcache statistics.  So far,
I've hacked sth similar to
sysctl vm.zone: stats are returned in one giant string, one line per
cache.  That's simple but ugly and hard to read because there are
quite a few stats per cache.

So I'm thinking about implementing a small tool, ocstat, that extracts
stats from sysctl the way ps(1) does (thru libkvm iirc) and formats it
in various ways.  What do you think?

Cheers,
Nicolas

Index: src2/sys/kern/kern_exit.c
===================================================================
--- src2.orig/sys/kern/kern_exit.c	2008-03-31 08:05:59.139796000 +0200
+++ src2/sys/kern/kern_exit.c	2008-03-31 10:31:39.000000000 +0200
@@ -834,7 +834,7 @@ loop:
 			}

 			vm_waitproc(p);
-			zfree(proc_zone, p);
+			objcache_put(proc_cache, p);
 			nprocs--;
 			return (0);
 		}
Index: src2/sys/kern/kern_proc.c
===================================================================
--- src2.orig/sys/kern/kern_proc.c	2008-03-31 08:05:59.139918000 +0200
+++ src2/sys/kern/kern_proc.c	2008-03-31 10:31:39.000000000 +0200
@@ -84,7 +84,7 @@ u_long pgrphash;
 struct proclist allproc;
 struct proclist zombproc;
 struct spinlock allproc_spin;
-vm_zone_t proc_zone;
+struct objcache* proc_cache;
 vm_zone_t lwp_zone;
 vm_zone_t thread_zone;

@@ -131,7 +131,7 @@ procinit(void)
 	spin_init(&allproc_spin);
 	pidhashtbl = hashinit(maxproc / 4, M_PROC, &pidhash);
 	pgrphashtbl = hashinit(maxproc / 4, M_PROC, &pgrphash);
-	proc_zone = zinit("PROC", sizeof (struct proc), 0, 0, 5);
+	proc_cache = objcache_create_simple(M_PROC, sizeof(struct proc));
 	lwp_zone = zinit("LWP", sizeof (struct lwp), 0, 0, 5);
 	thread_zone = zinit("THREAD", sizeof (struct thread), 0, 0, 5);
 	uihashinit();
Index: src2/sys/sys/proc.h
===================================================================
--- src2.orig/sys/sys/proc.h	2008-03-31 08:05:59.140325000 +0200
+++ src2/sys/sys/proc.h	2008-03-31 10:31:39.000000000 +0200
@@ -473,7 +473,7 @@ struct proc *zpfind (pid_t);	/* Find zom
 struct vm_zone;
 struct globaldata;
 struct lwp_params;
-extern struct vm_zone *proc_zone;
+extern struct objcache *proc_cache;
 extern struct vm_zone *lwp_zone;

 int	enterpgrp (struct proc *p, pid_t pgid, int mksess);
Index: src2/sys/kern/kern_fork.c
===================================================================
--- src2.orig/sys/kern/kern_fork.c	2008-03-31 08:05:59.140042000 +0200
+++ src2/sys/kern/kern_fork.c	2008-03-31 10:31:39.000000000 +0200
@@ -332,7 +332,7 @@ fork1(struct lwp *lp1, int flags, struct
 	}

 	/* Allocate new proc. */
-	p2 = zalloc(proc_zone);
+	p2 = objcache_get(proc_cache, M_WAITOK);
 	bzero(p2, sizeof(*p2));

 	/*




From hsu at dragonflybsd.org  Mon Mar 31 11:44:34 2008
From: hsu at dragonflybsd.org (Jeffrey Hsu)
Date: Mon, 31 Mar 2008 11:44:34 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <64fc43b0803311126na7d0b27obaa9d35bac6d32ee@mail.gmail.com>
Message-ID: <200803311841.m2VIfQAI007579@nlpi001.prodigy.net>

The object cache is not a general-purpose memory allocator.  It's a cache of
pre-initialized objects.  Are the significant portions of the proc structure
that can be restored to initialized state on object puts?  If not, it's best
to just use a general-purpose memory allocator.

								Jeffrey




From corecode at fs.ei.tum.de  Mon Mar 31 12:07:02 2008
From: corecode at fs.ei.tum.de (Simon 'corecode' Schubert)
Date: Mon, 31 Mar 2008 12:07:02 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <200803311841.m2VIfQAI007579@nlpi001.prodigy.net>
Message-ID: <47F1357B.1070302@fs.ei.tum.de>

Jeffrey Hsu wrote:
> The object cache is not a general-purpose memory allocator.  It's a cache of
> pre-initialized objects.  Are the significant portions of the proc structure
> that can be restored to initialized state on object puts?  If not, it's best
> to just use a general-purpose memory allocator.

Why?  What's the loss if we use the object cache to allocate struct procs?

cheers
  simon

Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00006.pgp
Type: application/octet-stream
Size: 252 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080331/a4a24314/attachment-0016.obj>

From nthery at gmail.com  Mon Mar 31 12:17:03 2008
From: nthery at gmail.com (Nicolas Thery)
Date: Mon, 31 Mar 2008 12:17:03 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <nthery@gmail.com>
Message-ID: <64fc43b0803311214u7da6bbb8xaf971de1a80e7258@mail.gmail.com>

2008/3/31, Jeffrey Hsu <hsu at dragonflybsd.org>:
> The object cache is not a general-purpose memory allocator.  It's a cache of
>  pre-initialized objects.  Are the significant portions of the proc structure
>  that can be restored to initialized state on object puts?  If not, it's best
>  to just use a general-purpose memory allocator.

Well, I haven't checked this yet.  I planned to do this in a second
step after getting rid of zones.

I thought that even without  the pre-initialization part, objcache has
the advantage
of pre-allocating set of objects (as zones) and is additionally
mp-safe (contrary to zones and, granted, as malloc()).   The latter
may be interesting as we talk of improving MP support.

Cheers,
Nicolas




From dillon at apollo.backplane.com  Mon Mar 31 12:23:40 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Mon, 31 Mar 2008 12:23:40 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <200803311841.m2VIfQAI007579@nlpi001.prodigy.net>
Message-ID: <200803311921.m2VJLITB027669@apollo.backplane.com>

    I both agree and disagree with Jeff.  I think the only *disadvantage*
    to using objcache for struct proc is that objcache must cache a minimum
    number of free structures to be efficient so the overall kernel memory
    use would be a bit greater verses uses kmalloc().  But I agree with Jeff
    in that objcache's biggest advantage is that you can keep structural state
    intact and struct proc might not be a good candidate (yet).

    What I suggest is that you convert struct proc from zone to kmalloc
    first, and then look into a possible objcache adaptation.  kmalloc
    is not slow.. it's a very fast allocator.  Objcache is probably a tad
    faster but not by much.  Where objcache really wins is in not having
    to completey reinitialize the allocated structures.

    Over the years I've removed (I think) all the dependancies on requiring
    the proc structure to be in stable memory so I believe it can be moved to
    kmalloc/objcache now without any major pain.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From corecode at fs.ei.tum.de  Mon Mar 31 12:37:40 2008
From: corecode at fs.ei.tum.de (Simon 'corecode' Schubert)
Date: Mon, 31 Mar 2008 12:37:40 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: SoC student applications due by 5PM PDT tomorrow
In-Reply-To: <1942.192.168.0.242.1206930479.squirrel@www.shiningsilence.com>
Message-ID: <47F13CDA.6010703@fs.ei.tum.de>

Justin C. Sherrill wrote:
> On Sun, March 30, 2008 10:27 pm, Justin C. Sherrill wrote:
>> SoC students:
>>
>> If you have an application to submit for DragonFly/Summer of Code, please
>> do so by 17:00 Pacific time on the 31st - that's tomorrow, at least for
>> me.
> The deadline for student proposals has been extended to April 7th; all
> other dates move forward one week to acommodate.

This is very good.

Some more ideas for eager students (we want to keep the ratio, right?):

Enhance the FreeBSD/DragonFly sound infrastructure to support surround
sound/multichannel output.

Update sound drivers to support S/PDIF output.

Make the sound infrastructure OSSv4 compatible (there was a SoC at
FreeBSD last year or so)


of course only if it doesn't exist already :)

cheers
  simon


Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00007.pgp
Type: application/octet-stream
Size: 252 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080331/6da61cff/attachment-0016.obj>

From corecode at fs.ei.tum.de  Mon Mar 31 12:41:30 2008
From: corecode at fs.ei.tum.de (Simon 'corecode' Schubert)
Date: Mon, 31 Mar 2008 12:41:30 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <200803311841.m2VIfQAI007579@nlpi001.prodigy.net>
Message-ID: <47F13DE4.10205@fs.ei.tum.de>

Matthew Dillon wrote:
>     What I suggest is that you convert struct proc from zone to kmalloc
>     first, and then look into a possible objcache adaptation.  kmalloc
>     is not slow.. it's a very fast allocator.  Objcache is probably a tad
>     faster but not by much.  Where objcache really wins is in not having
>     to completey reinitialize the allocated structures.

Could we please not move to kmalloc, but instead try to move all fast
path allocations to objcache?  I don't like the idea of allocating
everything with kmalloc.  Caching struct procs is not a bad thing itself.

cheers
  simon


Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00008.pgp
Type: application/octet-stream
Size: 252 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080331/ac328c08/attachment-0016.obj>

From hsu at FreeBSD.org  Mon Mar 31 12:59:05 2008
From: hsu at FreeBSD.org (Jeffrey Hsu)
Date: Mon, 31 Mar 2008 12:59:05 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <47F1357B.1070302@fs.ei.tum.de>
Message-ID: <200803311920.m2VJK5Ln018015@nlpi015.prodigy.net>

The object cache sits on top of a general-purpose memory allocator such
as kmalloc or zalloc and provides pre-initialized object caching functionality.
If you're not going to use the object caching functionality, you can just
call the underlying memory allocator directly.

							Jeffrey




From dillon at apollo.backplane.com  Mon Mar 31 16:17:19 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Mon, 31 Mar 2008 16:17:19 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <200803311841.m2VIfQAI007579@nlpi001.prodigy.net>
Message-ID: <200803312311.m2VNBumd029866@apollo.backplane.com>

:Could we please not move to kmalloc, but instead try to move all fast
:path allocations to objcache?  I don't like the idea of allocating
:everything with kmalloc.  Caching struct procs is not a bad thing itself.=
:
:
:cheers
:  simon

    I will state for the record that I'm fine with either objcache or
    kmalloc.  I agree with Jeff that using objcache for struct proc
    probably isn't necessary but I also agree that it would not hurt either,
    and if the intent is to optimize the initialization of the proc
    structure in the future then moving to objcache now would save us
    from having to do it later.

    So whichever method Nicolas wants to use is fine with me.

						-Matt




From hsu at dragonflybsd.org  Mon Mar 31 19:22:47 2008
From: hsu at dragonflybsd.org (Jeffrey Hsu)
Date: Mon, 31 Mar 2008 19:22:47 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <64fc43b0803311214u7da6bbb8xaf971de1a80e7258@mail.gmail.com>
Message-ID: <200804010218.m312IVUq003624@nlpi043.prodigy.net>

  >> Are there significant portions of the proc structure
  >> that can be restored to initialized state on object puts?

  > I planned to do this in a second step after getting rid of zones.

I'll all in favor of making more use of caching pre-initialized objects, so
if this is your objective, then please go ahead.  It's just that I'd convert
over to the object cache in one step.

  > I thought that even without  the pre-initialization part, objcache has
  > the advantage of pre-allocating set of objects (as zones) and is additionally
  > mp-safe (contrary to zones and, granted, as malloc()).

Well, the zone allocator is MP-safe.  It's not hard to lock up the places that
manipulate the linked-list of free items. Look for uses of the zlock field.

								Jeffrey




From tgen at netphreax.net  Sat Mar  1 12:57:53 2008
From: tgen at netphreax.net (Thomas E. Spanjaard)
Date: Sat, 1 Mar 2008 12:57:53 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: [Fwd: Project Support Open Source: $50 donation to support you      project]
In-Reply-To: <2468.192.168.0.242.1204346451.squirrel@www.shiningsilence.com>
Message-ID: <47C9C1B7.50203@netphreax.net>

Justin C. Sherrill wrote:
The "donation" happens after you place an "acknowledgement" on an open
source project's web page.  I'm putting those words in scare quotes
because I think it's a "payment" for an "advertisement".  The supplied
link has nothing to do with DragonFly, to say the least.

<a href="http://www.2insure4less.com /" title="We support FOSS software
projects.">Online Insurance Quotes</a>
To think our souls are only worth $50...
--
        Thomas E. Spanjaard
        tgen at netphreax.net
Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00000.pgp
Type: application/octet-stream
Size: 186 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080301/0d61e240/attachment-0017.obj>

From c.turner at 199technologies.org  Sat Mar  1 17:52:31 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Sat, 1 Mar 2008 17:52:31 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Misc. ACPI / suspend
Message-ID: <47CA073B.6020106@199technologies.org>

Wondering if anyone more well versed in the ACPI implementation could
comment on the applicability of:
http://lkml.org/lkml/2007/4/6/69

w/r/t the current state of the art in Dfly

(or BSD's in general)

Cheers!

- Chris




From elekktretterr at exemail.com.au  Sun Mar  2 00:41:25 2008
From: elekktretterr at exemail.com.au (Petr Janda)
Date: Sun, 2 Mar 2008 00:41:25 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: CARP question
Message-ID: <200803021934.21669.elekktretterr@exemail.com.au>

So Ive setup CARP on 2 DF-based mailservers. Installation went fine. Box 1 has 
adskew of 0 therefore it is the MASTER. Box 2 has adskew of 254, therefore is 
BACKUP.  If i down the carp0 interface on Box 1, then Box 2 carp interface 
gets promoted to MASTER. Then I up the carp interface on Box 1, logically Box 
2 should become BACKUP again as Box 1 becomes MASTER due to adskew set to 0.

However it doesnt happen. When carp0 interface on Box 1 is upped it becomes a 
BACKUP, not a MASTER even though according to adskew it should be MASTER.

What is the desired behaviour?

Cheers
Petr




From qhwt+dfly at les.ath.cx  Sun Mar  2 02:50:14 2008
From: qhwt+dfly at les.ath.cx (YONETANI Tomokazu)
Date: Sun, 2 Mar 2008 02:50:14 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: panic: assertion: hammer_btree_cmp(cursor->left_bound,	&cursor->node->ondisk->elms[0].leaf.base) <= 0 in btree_split_leaf
In-Reply-To: <200802232204.m1NM4cxd046264@apollo.backplane.com>
Message-ID: <20080302104554.GA22813@les.ath.cx>

Hi.
While trying to find a procedure to reliably reproduce the panic
I reported last time, I caught a different panic (uploaded at
 ~y0netan1/crash/9/ on my leaf account).  I wrote the following shell
script (make sure to edit variables DISKS and MOUNTPT before using this
script or it may trash your system):
  #!/bin/sh -ex
  DISKS="/dev/ad0s1f"
  MOUNTPT=/mnt/HAMMER

  cd /
  newfs_hammer -L TEST $DISKS
  for i in `seq 1 100`; do
	  mount_hammer $DISKS $MOUNTPT
	  /bin/rm -rf $MOUNTPT/??
	  (set +x; for x in `seq 1 10000`; do echo -n > $MOUNTPT/$x; done)
	  umount $MOUNTPT
  done

And the panic is triggered by rm command.
I'll try to see if it's possible to reproduce the last one without
unmounting then mounting the HAMMER fs.

Cheers.




From dillon at apollo.backplane.com  Sun Mar  2 13:25:33 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Sun, 2 Mar 2008 13:25:33 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: panic: assertion: hammer_btree_cmp(cursor->left_bound,	&cursor->node->ondisk->elms[0].leaf.base) <= 0 in btree_split_leaf
In-Reply-To: <200802232204.m1NM4cxd046264@apollo.backplane.com>
Message-ID: <200803022119.m22LJRCY037076@apollo.backplane.com>


:Hi.
:While trying to find a procedure to reliably reproduce the panic
:I reported last time, I caught a different panic (uploaded at
: ~y0netan1/crash/9/ on my leaf account).  I wrote the following shell
:script (make sure to edit variables DISKS and MOUNTPT before using this
:script or it may trash your system):

(from the core)

panic: assertion: node->lock.refs == 0 && node->ondisk == NULL in hammer_flush_buffer_nodes

    Yah, I've seen this failure.  Add a sync or two before the umount and
    tell me if it still occurs.  It's either a node reference leak somewhere
    or it is a race between bufdaemon and umount.  The assertions are really
    strict there precisely to catch those sorts of cases.

    Also note that the code to deal with a full HAMMMER filesystem has not
    been written yet (The failure you are reporting is unrelated to a full
    HAMMER filesystem, though, just mentioning it).

						-Matt





From dillon at apollo.backplane.com  Sun Mar  2 13:29:03 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Sun, 2 Mar 2008 13:29:03 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Misc. ACPI / suspend
In-Reply-To: <47CA073B.6020106@199technologies.org>
Message-ID: <200803022126.m22LQbfI037188@apollo.backplane.com>


:Wondering if anyone more well versed in the ACPI implementation could
:comment on the applicability of:
:
:http://lkml.org/lkml/2007/4/6/69
:
:w/r/t the current state of the art in Dfly
:
:(or BSD's in general)
:
:Cheers!
:
:- Chris

    I really have no idea re: this.  Suspension in general is not well
    supported by any of the BSDs.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From dillon at apollo.backplane.com  Sun Mar  2 13:34:05 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Sun, 2 Mar 2008 13:34:05 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: [Fwd: Project Support Open Source: $50 donation to support you      project]
In-Reply-To: <2468.192.168.0.242.1204346451.squirrel@www.shiningsilence.com>
Message-ID: <200803022131.m22LVOe9037250@apollo.backplane.com>

:..
:source project's web page.  I'm putting those words in scare quotes
:because I think it's a "payment" for an "advertisement".  The supplied
:link has nothing to do with DragonFly, to say the least.
:
:I don't think this is a good idea, obviously, and replied to that effect. 
:However, I wanted to put this on a DragonFly list, in part to show this
:strange thing, and in part because I'm not comfortable making
:administrative decisions on behalf of the Project without being open as
:possible about it.

    It doesn't really cry out to me either.

						-Matt





From wbh at conducive.org  Sun Mar  2 20:36:32 2008
From: wbh at conducive.org (Bill Hacker)
Date: Mon, 03 Mar 2008 04:36:32 +0000
Subject: Misc. ACPI / suspend
In-Reply-To: <47CA073B.6020106@199technologies.org>
Message-ID: <47cb8050$0$855$415eb37d@crater_reader.dragonflybsd.org>

Matthew Dillon wrote:
:Wondering if anyone more well versed in the ACPI implementation could
:comment on the applicability of:
:
:http://lkml.org/lkml/2007/4/6/69
:
:w/r/t the current state of the art in Dfly
:
:(or BSD's in general)
:
:Cheers!
:
:- Chris
    I really have no idea re: this.  Suspension in general is not well
    supported by any of the BSDs.
					-Matt
					Matthew Dillon 
					<dillon at backplane.com>


. . and there seems to be a bit of a 'Catch 22' there in any case.

If the BIOS can alter 'stuff' out of site of the OS it is parking, what 
does the existence of such a 'feature' do to a(ny) security model?

Seems to at least beg creating the option of setting a flag to 
specifically *prevent* suspend-to-disk/hibernation (and/or force a 
reboot on wake-up).

Just because one is paranoid....  etc

Bill





From matthias at dragonflybsd.org  Tue Mar  4 02:30:52 2008
From: matthias at dragonflybsd.org (Matthias Schmidt)
Date: Tue, 4 Mar 2008 02:30:52 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
Message-ID: <20080304102335.GI9833@staatsfeind.org>

Hi,

Google just announced its Summer of Code for 2008:

	http://code.google.com/soc/2008/

I think this would be a great opportunity for DragonFly to participate
as a mentoring organisation.  We could attract new developers and could
get code/work done.  Looking at the SoC results of the other BSDs most
of their projects were a success.  Of course, not all, but a reasonable
percentage.  See [1] and [2].

It is some extra work for us, but IMO the benefits outweigh the extra
work.  And yes, I would volunteer as a mentor.  What do others
(developers) think?  Any more volunteers? :)

Some project ideas that come into my mind.  More ideas are listed in the
wiki:  http://wiki.dragonflybsd.org/index.cgi/ProjectsPage

 * Fix all remaining bugs in dma(8) and implement all missing features
 * Add a driver for newer Intel Wireless cards (I think sephe@ would
   love that :)
 * Bring our ACPI stuff in shape.  Maybe suspend2disk ...

 * [Add your own thoughts here]

Cheers,

	Matthias

PS: I don't want to create a bikeshed here whether you like the SoC or
not :)

[1] http://code.google.com/soc/2007/freebsd/about.html
[2] http://code.google.com/soc/2007/netbsd/about.html




From corecode at fs.ei.tum.de  Tue Mar  4 04:46:14 2008
From: corecode at fs.ei.tum.de (Simon 'corecode' Schubert)
Date: Tue, 4 Mar 2008 04:46:14 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47CD4386.1000704@fs.ei.tum.de>

Matthias Schmidt wrote:
>  * [Add your own thoughts here]

MP lock removal for network stack

and for the system  (first profile, find hot spots, fix hot spots, repeat)

cheers
  simon




From c.turner at 199technologies.org  Tue Mar  4 06:02:20 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Tue, 4 Mar 2008 06:02:20 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47CD551E.1040604@199technologies.org>

Matthias Schmidt wrote:
Some project ideas that come into my mind.  More ideas are listed in the
wiki:  http://wiki.dragonflybsd.org/index.cgi/ProjectsPage
+1 acpi
+1 interrupt routing
+1 SMP / giant removal
+1 pf synchup with openbsd
though there are several others on the page that are good..

need to dig up my wiki login and place appropriately..

also: thinking the ZFS port should be removed from the page - makes 
sense to everyone else? (e.g. fragments effort w/r/t hammer)





From tgen at netphreax.net  Tue Mar  4 06:54:31 2008
From: tgen at netphreax.net (Thomas E. Spanjaard)
Date: Tue, 4 Mar 2008 06:54:31 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47CD615F.8010209@netphreax.net>

Matthias Schmidt wrote:
Google just announced its Summer of Code for 2008:

 * [Add your own thoughts here]
x86-64 port :).
--
        Thomas E. Spanjaard
        tgen at netphreax.net
Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00001.pgp
Type: application/octet-stream
Size: 186 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080304/0d921000/attachment-0017.obj>

From rdivacky at FreeBSD.org  Tue Mar  4 07:07:03 2008
From: rdivacky at FreeBSD.org (Roman Divacky)
Date: Tue, 4 Mar 2008 07:07:03 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <20080304150255.GA8831@freebsd.org>

On Tue, Mar 04, 2008 at 02:49:03PM +0000, Thomas E. Spanjaard wrote:
> Matthias Schmidt wrote:
> >Google just announced its Summer of Code for 2008:
> >
> > * [Add your own thoughts here]
> 
> x86-64 port :).

all those ideas are great and needed etc. but keep in
mind that the projects should be doable by students
who might see dfly for the very first time.

don't overestimate whats possible and select projects
that look realistic

Roman Divacky (former SoC student)




From justin at shiningsilence.com  Tue Mar  4 08:32:56 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Tue, 4 Mar 2008 08:32:56 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <60322.65.106.147.226.1204648095.squirrel@www.shiningsilence.com>

On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
> Hi,
>
> Google just announced its Summer of Code for 2008:
>
> 	http://code.google.com/soc/2008/
>
> I think this would be a great opportunity for DragonFly to participate
> as a mentoring organisation.  We could attract new developers and could
> get code/work done.  Looking at the SoC results of the other BSDs most
> of their projects were a success.  Of course, not all, but a reasonable
> percentage.  See [1] and [2].

We've applied in previous years - Jeff Hsu did one year, and I put
together the application last year.  The hardest thing to find was
students (and they are the thing that helps SoC applications a lot, I
think).

Any student volunteers?  We have mentors.





From rluciani at gmail.com  Tue Mar  4 09:38:29 2008
From: rluciani at gmail.com (Robert Luciani)
Date: Tue, 04 Mar 2008 18:38:29 +0100
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47cd8915$0$854$415eb37d@crater_reader.dragonflybsd.org>

Justin C. Sherrill wrote:
> On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
>> Hi,
>>
>> Google just announced its Summer of Code for 2008:
>>
>> 	http://code.google.com/soc/2008/
>>
>> I think this would be a great opportunity for DragonFly to participate
>> as a mentoring organisation.  We could attract new developers and could
>> get code/work done.  Looking at the SoC results of the other BSDs most
>> of their projects were a success.  Of course, not all, but a reasonable
>> percentage.  See [1] and [2].
> 
> We've applied in previous years - Jeff Hsu did one year, and I put
> together the application last year.  The hardest thing to find was
> students (and they are the thing that helps SoC applications a lot, I
> think).
> 
> Any student volunteers?  We have mentors.
> 

bingo

-- 
Robert Luciani
Chalmers University of Technology, SWE
Department of Computer Science and Engineering
http://www.rluciani.com/public.key




From sdavtaker at gmail.com  Tue Mar  4 09:31:08 2008
From: sdavtaker at gmail.com (=?UTF-8?Q?Sd=C3=A4vtaker?=)
Date: Tue, 4 Mar 2008 09:31:08 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <c37d69f60803040926k206218a3kb8496d0cd18148bd@mail.gmail.com>

If you mentor, i will apply for coder :-)
Still in last year of university. :-)
Sdav

On Tue, Mar 4, 2008 at 1:28 PM, Justin C. Sherrill
<justin at shiningsilence.com> wrote:
> On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
>  > Hi,
>  >
>  > Google just announced its Summer of Code for 2008:
>  >
>  >       http://code.google.com/soc/2008/
>  >
>  > I think this would be a great opportunity for DragonFly to participate
>  > as a mentoring organisation.  We could attract new developers and could
>  > get code/work done.  Looking at the SoC results of the other BSDs most
>  > of their projects were a success.  Of course, not all, but a reasonable
>  > percentage.  See [1] and [2].
>
>  We've applied in previous years - Jeff Hsu did one year, and I put
>  together the application last year.  The hardest thing to find was
>  students (and they are the thing that helps SoC applications a lot, I
>  think).
>
>  Any student volunteers?  We have mentors.
>
>



-- 
Sd?vtaker prays to Rikku goddess for a good treasure.



From rluciani at gmail.com  Tue Mar  4 09:44:02 2008
From: rluciani at gmail.com (Robert Luciani)
Date: Tue, 04 Mar 2008 18:44:02 +0100
Subject: google soc "DragonFly"
Message-ID: <47cd8a63$0$855$415eb37d@crater_reader.dragonflybsd.org>

On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
> > Hi,
> >
> > Google just announced its Summer of Code for 2008:
> >
> > 	http://code.google.com/soc/2008/
> >
> > I think this would be a great opportunity for DragonFly to participate
> > as a mentoring organisation.  We could attract new developers and could
> > get code/work done.  Looking at the SoC results of the other BSDs most
> > of their projects were a success.  Of course, not all, but a reasonable
> > percentage.  See [1] and [2].

We've applied in previous years - Jeff Hsu did one year, and I put
together the application last year.  The hardest thing to find was
students (and they are the thing that helps SoC applications a lot, I
think).

Any student volunteers?  We have mentors.


-- 
Robert Luciani
Chalmers University of Technology, SWE
Department of Computer Science and Engineering
http://www.rluciani.com/public.key




From rluciani at gmail.com  Tue Mar  4 10:04:14 2008
From: rluciani at gmail.com (Robert Luciani)
Date: Tue, 04 Mar 2008 19:04:14 +0100
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47cd8f1f$0$856$415eb37d@crater_reader.dragonflybsd.org>

Robert Luciani wrote:
> Justin C. Sherrill wrote:
>> On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
>>> Hi,
>>>
>>> Google just announced its Summer of Code for 2008:
>>>
>>> 	http://code.google.com/soc/2008/
>>>
>>> I think this would be a great opportunity for DragonFly to participate
>>> as a mentoring organisation.  We could attract new developers and could
>>> get code/work done.  Looking at the SoC results of the other BSDs most
>>> of their projects were a success.  Of course, not all, but a reasonable
>>> percentage.  See [1] and [2].
>> We've applied in previous years - Jeff Hsu did one year, and I put
>> together the application last year.  The hardest thing to find was
>> students (and they are the thing that helps SoC applications a lot, I
>> think).
>>
>> Any student volunteers?  We have mentors.
>>
> 
> bingo
> 
My girlfriend Danwei noted that she would also like partake in the SoC.
She's studying IT here at Chalmers and will join the mailing list shortly.
-- 
Robert Luciani
Chalmers University of Technology, SWE
Department of Computer Science and Engineering
http://www.rluciani.com/public.key




From dillon at apollo.backplane.com  Tue Mar  4 13:08:30 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Tue, 4 Mar 2008 13:08:30 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Going to have to roll 1.12.1
Message-ID: <200803042104.m24L43g1065278@apollo.backplane.com>

    Due to a critical bug in sendmail that can cause it to seg-fault I will
    be rolling 1.12.1 as soon as I get verification that the current
    fix deals with it.

						-Matt





From sdavtaker at gmail.com  Tue Mar  4 17:40:43 2008
From: sdavtaker at gmail.com (=?UTF-8?B?U2TDpHZ0YWtlcg==?=)
Date: Tue, 4 Mar 2008 17:40:43 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: [Fwd: Project Support Open Source: $50 donation to support you  project]
In-Reply-To: <2468.192.168.0.242.1204346451.squirrel@www.shiningsilence.com>
Message-ID: <47CDF8D1.9070100@gmail.com>

50 bucks?
Come on...
You can get a meal a lot more expensive than that just going to a free 
HP conference about linux and you only have to rent your soul 3-5 hours ;-)
Sdav

Matthew Dillon escribi?:
:..
:source project's web page.  I'm putting those words in scare quotes
:because I think it's a "payment" for an "advertisement".  The supplied
:link has nothing to do with DragonFly, to say the least.
:
:I don't think this is a good idea, obviously, and replied to that effect. 
:However, I wanted to put this on a DragonFly list, in part to show this
:strange thing, and in part because I'm not comfortable making
:administrative decisions on behalf of the Project without being open as
:possible about it.

    It doesn't really cry out to me either.

						-Matt

  






From sdavtaker at gmail.com  Tue Mar  4 17:56:35 2008
From: sdavtaker at gmail.com (=?UTF-8?B?U2TDpHZ0YWtlcg==?=)
Date: Tue, 4 Mar 2008 17:56:35 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47CDFCCE.1010106@gmail.com>

A cute idea for for GSOC would be to finish the installer.
We were talking about this in my local BUG, we trying to find out how to 
help on that from here.
There is a few missing features in the CD.

   * FDISK, you need to create the slides from another OS before
     install DFBSD, i think port FDisk from FBSD or any *BSD will solve it.
   * Add to the make release a way to add some custom applications to
     the released liveCD (suppose you want to add nmap or ssh or
     something just to use as test disk in some enviroment).
   * Make the installer a little more customizable, and maybe w/ a GUI
     (I like a lot the console approach, but GUI installer will be a
     popularity move, DFBSD w/X makes a Desktop machine work, actually
     im using it that way and really like it).
I think those projects can be done in a SOC by students (like me) with a 
little guide.
Im a lot more interested in things network related and kernel, but i 
dont mind to work on those things, they need to be done some day.
What u think?
Sdav

Robert Luciani escribi?:
Robert Luciani wrote:
  
Justin C. Sherrill wrote:
    
On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
      
Hi,

Google just announced its Summer of Code for 2008:

	http://code.google.com/soc/2008/

I think this would be a great opportunity for DragonFly to participate
as a mentoring organisation.  We could attract new developers and could
get code/work done.  Looking at the SoC results of the other BSDs most
of their projects were a success.  Of course, not all, but a reasonable
percentage.  See [1] and [2].
        
We've applied in previous years - Jeff Hsu did one year, and I put
together the application last year.  The hardest thing to find was
students (and they are the thing that helps SoC applications a lot, I
think).
Any student volunteers?  We have mentors.

      
bingo

    
My girlfriend Danwei noted that she would also like partake in the SoC.
She's studying IT here at Chalmers and will join the mailing list shortly.
  






From c.turner at 199technologies.org  Tue Mar  4 18:30:53 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Tue, 4 Mar 2008 18:30:53 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47CE04C9.1010902@199technologies.org>

Justin C. Sherrill wrote:
together the application last year.  The hardest thing to find was
students (and they are the thing that helps SoC applications a lot, I
think).
umm.. if google wants to send me back to school, I'll sign up - hows 
that for a fair trade :?






From wbh at conducive.org  Tue Mar  4 23:52:13 2008
From: wbh at conducive.org (Bill Hacker)
Date: Wed, 05 Mar 2008 07:52:13 +0000
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47ce512e$0$855$415eb37d@crater_reader.dragonflybsd.org>

Sd?vtaker wrote:
A cute idea for for GSOC would be to finish the installer.
We were talking about this in my local BUG, we trying to find out how to 
help on that from here.
There is a few missing features in the CD.

   * FDISK, you need to create the slides from another OS before
     install DFBSD, i think port FDisk from FBSD or any *BSD will solve it.
I'd rather see that 'reversed' - i.e. - build a more capable fdisk in 
DFLY with hope that it might be seen worth importing into Free/Net/Open, 
or *at least* be able to do a more flexible job than those now do.

And disklabels as well. Hand in glove.

Here's why:

- At the moment, working with Free, Open, DFLY, and OpenSolaris on the 
same HDD requires a bit of acrobatics.

- There seems to now be greater divergence between/among the *BSD's as 
to being able to read each other's disklabels, mount and use each 
other's 'flavor' of FFS/UFS (not to mention Apple's implementation of 
UFS) than there is among the vast multitude of Linux ext2/3 denizens.

Even to the point where use of a *Linux* fs is the more universal way 
for being able to share mounts among the *BSD's. Think detached drives. 
And no - FAT is not all that practical for several reasons.

- DFLY currently has the most fine-grain ability to create slices and 
partitions. But the others cannot all (any?) read those.

'progress' w/r any of the *BSD's direction as to changes, improvements 
(or not) in their once-common-ancestry fs & disklabels need not be 
sacrificed.

I'm not holding out wish or hope for all players agreeing to return to 
'one sacred way'. Nor 'one new universal fs'. Neither is gonna happen.

But a 'legacy compatible' or least-common-denominator mode would do fine 
- most especially for portable / SAN devices.

So - how about a 'flexible' DFLY fdisk to go along with a 'flexible' 
disklabel that could adapt to whatever it found / was told to create?

JM2CW - but that *might* be a good place to get a cross-*BSD team together.

*snip* (other good stuff)

Bill Hacker




From matthias at dragonflybsd.org  Wed Mar  5 01:02:43 2008
From: matthias at dragonflybsd.org (Matthias Schmidt)
Date: Wed, 5 Mar 2008 01:02:43 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <20080305085747.GJ9833@staatsfeind.org>

Hi,

* Justin C. Sherrill wrote:
> 
> We've applied in previous years - Jeff Hsu did one year, and I put
> together the application last year.  The hardest thing to find was
> students (and they are the thing that helps SoC applications a lot, I
> think).

This is good to know, so we could coordinate that if we have enough
mentors and projects?!?  I put together a small text in the wiki:

http://wiki.dragonflybsd.org/index.cgi/GoogleSoC2008

Feel free to add project or missing stuff.  I'm sure I missed a lot of
things :)

> Any student volunteers?  We have mentors.

According to the discussion we could have some students, who would be a
mentor (besides me)?

Regards

	Matthias





From sdavtaker at gmail.com  Wed Mar  5 06:28:37 2008
From: sdavtaker at gmail.com (=?UTF-8?Q?Sd=C3=A4vtaker?=)
Date: Wed, 5 Mar 2008 06:28:37 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <c37d69f60803050624kd86d3d0w3b44a02d0e5a5391@mail.gmail.com>

<quote>
Write a driver (from scratch) for Intel 3945 wireless device
Mentor: Sepherosa Ziehau
</quote>

Yes yes yes, i want to :-)
Someone else planning to mentor in drivers coding?
Sdav

On Wed, Mar 5, 2008 at 5:57 AM, Matthias Schmidt
<matthias at dragonflybsd.org> wrote:
> Hi,
>
>
>  * Justin C. Sherrill wrote:
>  >
>  > We've applied in previous years - Jeff Hsu did one year, and I put
>  > together the application last year.  The hardest thing to find was
>  > students (and they are the thing that helps SoC applications a lot, I
>  > think).
>
>  This is good to know, so we could coordinate that if we have enough
>  mentors and projects?!?  I put together a small text in the wiki:
>
>  http://wiki.dragonflybsd.org/index.cgi/GoogleSoC2008
>
>  Feel free to add project or missing stuff.  I'm sure I missed a lot of
>  things :)
>
>
>  > Any student volunteers?  We have mentors.
>
>  According to the discussion we could have some students, who would be a
>  mentor (besides me)?
>
>  Regards
>
>         Matthias
>
>



-- 
Sd?vtaker prays to Rikku goddess for a good treasure.



From rluciani at gmail.com  Wed Mar  5 10:56:42 2008
From: rluciani at gmail.com (Robert Luciani)
Date: Wed, 05 Mar 2008 19:56:42 +0100
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47ceecea$0$847$415eb37d@crater_reader.dragonflybsd.org>

Sd?vtaker wrote:
> <quote>
> Write a driver (from scratch) for Intel 3945 wireless device
> Mentor: Sepherosa Ziehau
> </quote>
> 
> Yes yes yes, i want to :-)
> Someone else planning to mentor in drivers coding?
> Sdav
> 
> On Wed, Mar 5, 2008 at 5:57 AM, Matthias Schmidt
> <matthias at dragonflybsd.org> wrote:
>> Hi,
>>
>>
>>  * Justin C. Sherrill wrote:
>>  >
>>  > We've applied in previous years - Jeff Hsu did one year, and I put
>>  > together the application last year.  The hardest thing to find was
>>  > students (and they are the thing that helps SoC applications a lot, I
>>  > think).
>>
>>  This is good to know, so we could coordinate that if we have enough
>>  mentors and projects?!?  I put together a small text in the wiki:
>>
>>  http://wiki.dragonflybsd.org/index.cgi/GoogleSoC2008
>>
>>  Feel free to add project or missing stuff.  I'm sure I missed a lot of
>>  things :)
>>
>>
>>  > Any student volunteers?  We have mentors.
>>
>>  According to the discussion we could have some students, who would be a
>>  mentor (besides me)?
>>
>>  Regards
>>
>>         Matthias
>>
>>
> 
> 
>

IF someone starts to write a 3945 Intel driver,
please keep the newer 4965 in mind too.

-- 
Robert Luciani
Chalmers University of Technology, SWE
Department of Computer Science and Engineering
http://www.rluciani.com/public.key




From joerg at britannica.bec.de  Wed Mar  5 12:01:05 2008
From: joerg at britannica.bec.de (Joerg Sonnenberger)
Date: Wed, 5 Mar 2008 12:01:05 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <20080305195711.GA9981@britannica.bec.de>

On Wed, Mar 05, 2008 at 07:56:42PM +0100, Robert Luciani wrote:
> IF someone starts to write a 3945 Intel driver,
> please keep the newer 4965 in mind too.

NetBSD's wpi works quite well. The hardware is quite different from
4945.

Joerg




From sepherosa at gmail.com  Wed Mar  5 17:48:50 2008
From: sepherosa at gmail.com (Sepherosa Ziehau)
Date: Wed, 5 Mar 2008 17:48:50 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <ea7b9c170803051744u22b09484ofc994f034f11df3b@mail.gmail.com>

On Thu, Mar 6, 2008 at 2:56 AM, Robert Luciani <rluciani at gmail.com> wrote:
>  IF someone starts to write a 3945 Intel driver,

"IF" you know that trying to fix any wired bugs in certain drivers
(e.g. ipw, ral) will require you to read through all of the vendor's
linux code (yes, even including register values and position), i.e.
there is not much difference between writing one from scratch and
porting+fixing_bugs, then you probably will not put "IF" at the start
of your sentence.
If what I said sounded too harsh to you, then I was sorry.

>  please keep the newer 4965 in mind too.

Will do, once generic 11n support is brought in from freebsd.

Best Regards,
sephe

-- 
Live Free or Die




From saw at online.de  Thu Mar  6 05:34:14 2008
From: saw at online.de (Sascha Wildner)
Date: Thu, 06 Mar 2008 14:34:14 +0100
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
Message-ID: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>

Hi all,

this is probably as good a moment as any to come out of the forest with 
this. The patch at

http://leaf.dragonflybsd.org/~swildner/nrelease_gui.diff

adds some code to nrelease/ to build a LiveCD with xorg and so on 
(currently, only the xorg metapackages and fluxbox are added). In order 
to build one, you need a local dir with the pkgsrc binary packages (see 
below).

The following commands should then do the trick:

cd /usr/src
make buildworld
make buildkernel
cd nrelease
patch -p 0 </path/to/the/patch
make PKGSRC_PKG_PATH=/path/to/packages/dir/All realquick gui
The resulting ISO will be in /usr/release/dfly-gui.iso then. It will not 
boot into xorg automatically (although this is easily possible), so you 
need to login as root and do startx.

As of now, this all is kind of basic, more a proof of concept than 
anything else. As our release framework installs packages via chroot, 
the current setup just copies _all_ packages to the chroot before 
installing (kind of a hack).

That said, I'm now primarily interested in opinions/ideas/... about the 
direction this should take. Which packages would we like to see on the 
CD? Should it be a generic setup with the "most common things" 
installed, so a system can be quickly setup by the installer (which will 
cpdup /usr/pkg). Or should it be a more specialized set of tools? Or 
even as many packages as possible (Live DVD?). Etc., etc.

Before continuing on it, I'm really interested in people's input so 
don't hold anything back, please. :)

Sascha

--
http://yoyodyne.ath.cx



From rluciani at gmail.com  Thu Mar  6 06:42:03 2008
From: rluciani at gmail.com (Robert Luciani)
Date: Thu, 06 Mar 2008 15:42:03 +0100
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <47d002bc$0$847$415eb37d@crater_reader.dragonflybsd.org>

Sascha Wildner wrote:
> Hi all,
> 
> this is probably as good a moment as any to come out of the forest with
> this. The patch at
> 
> http://leaf.dragonflybsd.org/~swildner/nrelease_gui.diff
> 
> adds some code to nrelease/ to build a LiveCD with xorg and so on
> (currently, only the xorg metapackages and fluxbox are added). In order
> to build one, you need a local dir with the pkgsrc binary packages (see
> below).
> 
> The following commands should then do the trick:
> 
> cd /usr/src
> make buildworld
> make buildkernel
> cd nrelease
> patch -p 0 </path/to/the/patch
> make PKGSRC_PKG_PATH=/path/to/packages/dir/All realquick gui
> 
> The resulting ISO will be in /usr/release/dfly-gui.iso then. It will not
> boot into xorg automatically (although this is easily possible), so you
> need to login as root and do startx.
> 
> As of now, this all is kind of basic, more a proof of concept than
> anything else. As our release framework installs packages via chroot,
> the current setup just copies _all_ packages to the chroot before
> installing (kind of a hack).
> 
> That said, I'm now primarily interested in opinions/ideas/... about the
> direction this should take. Which packages would we like to see on the
> CD? Should it be a generic setup with the "most common things"
> installed, so a system can be quickly setup by the installer (which will
> cpdup /usr/pkg). Or should it be a more specialized set of tools? Or
> even as many packages as possible (Live DVD?). Etc., etc.
> 
> Before continuing on it, I'm really interested in people's input so
> don't hold anything back, please. :)
> 
> Sascha
> 

I think the main point of such a live-cd would be to test
dragonfly-specific features such as vkernels and more. Mplayer and
OpenOffic work the same on all platforms, so they might not be super
important, while irssi, firefox, networking tools, vim, a few more
shells/terminals might make it easier to for people to quickly gauge if
they can reproduce their current productivity and also what is new.

And if the point of a livecd is to test that kind of stuff, then it
would be nice for it to have a kernel that supports as much as possible
like ALTQ, and drivers.

Also if it has lots and lots of programs (thinking multimedia, java,
etc..) it might be hard to keep the future x64 and x86 live-cds on par.
Gentoo had this problem many years ago and it was very bothersome.

-- 
Robert Luciani
Chalmers University of Technology, SWE
Department of Computer Science and Engineering
http://www.rluciani.com/public.key




From matthias at dragonflybsd.org  Thu Mar  6 07:12:43 2008
From: matthias at dragonflybsd.org (Matthias Schmidt)
Date: Thu, 6 Mar 2008 07:12:43 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <20080306150757.GN9833@staatsfeind.org>

* Sascha Wildner wrote:
> Hi all,
> 
> this is probably as good a moment as any to come out of the forest with this. 
> The patch at
> 
> http://leaf.dragonflybsd.org/~swildner/nrelease_gui.diff
> 
> adds some code to nrelease/ to build a LiveCD with xorg and so on (currently, 
> only the xorg metapackages and fluxbox are added). In order to build one, you 
> need a local dir with the pkgsrc binary packages (see below).

Great work Sascha.

I agree with Robert on most of his stated points.
It would be nice to see some DragonFly specific features on the CD
(although I'm not sure if that will work for all features).  A little
environment where most Unix users feel at home (fluxbox, xfce, firefox,
thunderbird, gvim) should be enough.

Big applications like OO.org, java etc won't work because they are not
available as pkgsrc packages neither is it possible to compile them on
DragonFly.  At least to my knowledge.

Regards

	Matthias




From dillon at apollo.backplane.com  Thu Mar  6 09:31:52 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Thu, 6 Mar 2008 09:31:52 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <200803061728.m26HSR3O091809@apollo.backplane.com>


:Hi all,
:
:this is probably as good a moment as any to come out of the forest with 
:this. The patch at
:
:http://leaf.dragonflybsd.org/~swildner/nrelease_gui.diff
:
:adds some code to nrelease/ to build a LiveCD with xorg and so on 
:(currently, only the xorg metapackages and fluxbox are added). In order 
:to build one, you need a local dir with the pkgsrc binary packages (see 
:below).
:
:The following commands should then do the trick:

    It looks reasonable, though the package copy has to be tightened
    up a bit I think.

:...
:installed, so a system can be quickly setup by the installer (which will 
:cpdup /usr/pkg). Or should it be a more specialized set of tools? Or 
:even as many packages as possible (Live DVD?). Etc., etc.
:
:Before continuing on it, I'm really interested in people's input so 
:don't hold anything back, please. :)
:
:Sascha

    I think this is an excellent time to work up a DVD build and to
    add various 'flavor' extras.  So, e.g.:

	make installer gui gui_extras release dvd

    (All 'dvd' would do is generate a dvd compatible image for burning to
    dvd instead of cd).  I did a quick perusal of what I have on my
    workstation:

    * X
    * Firefox
    * Linux emulation
    * Open Office (linux version)
    * fvwm2
    * xpdf
    * freetype2

    I'd also suggest some image editing tools like gimp, and maybe the KDE
    gui suite.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From justin at shiningsilence.com  Thu Mar  6 09:42:44 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Thu, 6 Mar 2008 09:42:44 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <55427.65.106.147.226.1204825168.squirrel@www.shiningsilence.com>

On Thu, March 6, 2008 8:34 am, Sascha Wildner wrote:

> That said, I'm now primarily interested in opinions/ideas/... about the
> direction this should take. Which packages would we like to see on the
> CD? Should it be a generic setup with the "most common things"
> installed, so a system can be quickly setup by the installer (which will
> cpdup /usr/pkg). Or should it be a more specialized set of tools? Or
> even as many packages as possible (Live DVD?). Etc., etc.

What Robert said is good - whatever's needed to enable DragonFly-specific
features.  Along with that would be some sort of documentation (a README? 
A HTML file on whatever desktop we provide) that points people at the
different DragonFly tools, so they know what to try and how to try it.

There's going to be some percentage of people who try DragonFly who don't
know about vkernels, for instance, but there's our chance to educate them.
 I'm probably volunteering myself, aren't I?





From sdavtaker at gmail.com  Thu Mar  6 09:50:09 2008
From: sdavtaker at gmail.com (=?UTF-8?Q?Sd=C3=A4vtaker?=)
Date: Thu, 6 Mar 2008 09:50:09 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <c37d69f60803060947t110750c0sd6b542ea505d188d@mail.gmail.com>

Cool Sascha :-)
I just posted about this 1 or 2 days ago in the SOC project ideas thread.
Want to mentor this one? ;-)
Damian

On Thu, Mar 6, 2008 at 2:28 PM, Matthew Dillon
<dillon at apollo.backplane.com> wrote:
>
>  :Hi all,
>
> :
>  :this is probably as good a moment as any to come out of the forest with
>  :this. The patch at
>  :
>  :http://leaf.dragonflybsd.org/~swildner/nrelease_gui.diff
>  :
>  :adds some code to nrelease/ to build a LiveCD with xorg and so on
>  :(currently, only the xorg metapackages and fluxbox are added). In order
>  :to build one, you need a local dir with the pkgsrc binary packages (see
>  :below).
>  :
>  :The following commands should then do the trick:
>
>     It looks reasonable, though the package copy has to be tightened
>     up a bit I think.
>
>  :...
>  :installed, so a system can be quickly setup by the installer (which will
>
> :cpdup /usr/pkg). Or should it be a more specialized set of tools? Or
>  :even as many packages as possible (Live DVD?). Etc., etc.
>  :
>  :Before continuing on it, I'm really interested in people's input so
>  :don't hold anything back, please. :)
>  :
>  :Sascha
>
>     I think this is an excellent time to work up a DVD build and to
>     add various 'flavor' extras.  So, e.g.:
>
>         make installer gui gui_extras release dvd
>
>     (All 'dvd' would do is generate a dvd compatible image for burning to
>     dvd instead of cd).  I did a quick perusal of what I have on my
>     workstation:
>
>     * X
>     * Firefox
>     * Linux emulation
>     * Open Office (linux version)
>     * fvwm2
>     * xpdf
>     * freetype2
>
>     I'd also suggest some image editing tools like gimp, and maybe the KDE
>     gui suite.
>
>                                         -Matt
>                                         Matthew Dillon
>                                         <dillon at backplane.com>
>



-- 
Sd?vtaker prays to Rikku goddess for a good treasure.



From saw at online.de  Thu Mar  6 11:54:01 2008
From: saw at online.de (Sascha Wildner)
Date: Thu, 06 Mar 2008 20:54:01 +0100
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <47d04ba2$0$856$415eb37d@crater_reader.dragonflybsd.org>

Matthew Dillon wrote:
    It looks reasonable, though the package copy has to be tightened
    up a bit I think.
It looks as if it would work with mount_null'ing the chroot's 
/tmp/packages. I'll have a better patch ready tomorrow.

Sascha

--
http://yoyodyne.ath.cx



From c.turner at 199technologies.org  Thu Mar  6 19:11:44 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Thu, 6 Mar 2008 19:11:44 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Misc. ACPI / suspend
In-Reply-To: <47CA073B.6020106@199technologies.org>
Message-ID: <47D0B079.3060905@199technologies.org>

Chris Turner wrote:
Wondering if anyone more well versed in the ACPI implementation could
comment on the applicability of:
http://lkml.org/lkml/2007/4/6/69

Doing a little digging, it seems like

. /platform/pc32/i386/i686_mem.c

*might* have the necessary infrastructure to remap the MTRR's per the 
thread referenced,

but:

. /platform/pc32/acpica5/acpi_wakeup.c

doesn't seem to be using this infrastructure..

I'm no where near reaching an understanding of this yet,
but I'm wondering 3 things:
1) does anyone have ACPI (instead of APM)
   sleep / suspend / wakeup working on Dfly ?
2) If so, what machines are being used ?
3) Same question for other BSDs - my understanding is NetBSD is most
   'advanced' w/r/t power managment - but I'm not 100% on this ...
would looove to have a sleeping / resuming / scaling laptop running some 
BSD flavor.. am willing to work towards that end, esp. w/r/t Dfly -
trying to chart a course to figguring this out.

Thanks all,

- Chris




From c.turner at 199technologies.org  Thu Mar  6 19:12:33 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Thu, 6 Mar 2008 19:12:33 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: PCI Bios / Interrupt remapping / etc
Message-ID: <47D0B211.6000002@199technologies.org>

Doing a bit of digging here for my long-standing CBB+SIO interupt and 
buffer problem -

one machine I've tested against was an OpenBSD machine, which didn't
always work to handle the cardbus sio card on a PCI cardbus adapter
-

tuning up some of the device flags in:

http://www.openbsd.org/cgi-bin/man.cgi?query=pcibios&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=html

seems to have alleviated the problem for that os..

I'm just only starting to get up to speed on how DF handles these types 
of things (namely initial PIC / interrupt layout at boot time device 
enumeration), but am wondering if anyone familiar with this area of the 
code has any comments / advice w/r/t the capabilities of the DF bios 
drivers
and the various quirks / fixup mentioned in the link above..

looking to possibly investigate fixing up some of these issues over time.

Thanks

- Chris







From pavalos at theshell.com  Fri Mar  7 01:14:55 2008
From: pavalos at theshell.com (Peter Avalos)
Date: Fri, 7 Mar 2008 01:14:55 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: cam locking
Message-ID: <20080307091024.GC1652@ylem.theshell.com>

So I've been working on locking up cam using lockmgr locks, and here's
what I have so far:

http://www.theshell.com/~pavalos/wip/cam-lock.patch

Most of the work is obtained from FreeBSD.  I've only been running this
on my SCSI machine for a day, but because the patch is so large, I wanted
to make it available for people to review if they have some spare time.

Thanks,
Peter
Attachment:
pgp00002.pgp
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00002.pgp
Type: application/octet-stream
Size: 197 bytes
Desc: "Description: PGP signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080307/9a17ecd8/attachment-0017.obj>

From jspringe at uos.de  Fri Mar  7 03:25:17 2008
From: jspringe at uos.de (Jost Tobias Springenberg)
Date: Fri, 7 Mar 2008 12:25:17 +0100
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <20080307122517.72c9e2b1.jspringe@uos.de>

On Tue, 4 Mar 2008 11:28:15 -0500 (EST)
"Justin C. Sherrill" <justin at shiningsilence.com> wrote:

> On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
> > Hi,
> >
> > Google just announced its Summer of Code for 2008:
> >
> > 	http://code.google.com/soc/2008/
> >
> > I think this would be a great opportunity for DragonFly to participate
> > as a mentoring organisation.  We could attract new developers and could
> > get code/work done.  Looking at the SoC results of the other BSDs most
> > of their projects were a success.  Of course, not all, but a reasonable
> > percentage.  See [1] and [2].
> 
> We've applied in previous years - Jeff Hsu did one year, and I put
> together the application last year.  The hardest thing to find was
> students (and they are the thing that helps SoC applications a lot, I
> think).
> 
> Any student volunteers?  We have mentors.
> 

I read this mailing list for quite a while now and thought about contributing stuff
to DFfly several times, so yes why not take this opportunity if it's there.

-- 
Jost Tobias Springenberg <jspringe at uos.de>




From tgen at netphreax.net  Fri Mar  7 05:17:27 2008
From: tgen at netphreax.net (Thomas E. Spanjaard)
Date: Fri, 7 Mar 2008 05:17:27 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: PCI Bios / Interrupt remapping / etc
In-Reply-To: <47D0B211.6000002@199technologies.org>
Message-ID: <47D13FB4.5080306@netphreax.net>

Chris Turner wrote:
Doing a bit of digging here for my long-standing CBB+SIO interupt and 
buffer problem -

one machine I've tested against was an OpenBSD machine, which didn't
always work to handle the cardbus sio card on a PCI cardbus adapter
-

tuning up some of the device flags in:

http://www.openbsd.org/cgi-bin/man.cgi?query=pcibios&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=html 

seems to have alleviated the problem for that os..

I'm just only starting to get up to speed on how DF handles these types 
of things (namely initial PIC / interrupt layout at boot time device 
enumeration), but am wondering if anyone familiar with this area of the 
code has any comments / advice w/r/t the capabilities of the DF bios 
drivers
and the various quirks / fixup mentioned in the link above..

looking to possibly investigate fixing up some of these issues over time.
Our code that handles issues like this (in cases where you're not using 
APICs, just PICs and PIRs) lives in bus/pci/i386/. Not that running 
without APIC support is all that common on modern machines anymore...
--
        Thomas E. Spanjaard
        tgen at netphreax.net
Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00003.pgp
Type: application/octet-stream
Size: 186 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080307/61366b5c/attachment-0017.obj>

From tgen at netphreax.net  Fri Mar  7 05:16:51 2008
From: tgen at netphreax.net (Thomas E. Spanjaard)
Date: Fri, 7 Mar 2008 05:16:51 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Misc. ACPI / suspend
In-Reply-To: <47CA073B.6020106@199technologies.org>
Message-ID: <47D13F07.9080308@netphreax.net>

Chris Turner wrote:
1) does anyone have ACPI (instead of APM)
   sleep / suspend / wakeup working on Dfly ?
2) If so, what machines are being used ?
3) Same question for other BSDs - my understanding is NetBSD is most
   'advanced' w/r/t power managment - but I'm not 100% on this ...
would looove to have a sleeping / resuming / scaling laptop running some 
BSD flavor.. am willing to work towards that end, esp. w/r/t Dfly -
trying to chart a course to figguring this out.
I have ACPI S3 suspend working like a charm on my IBM ThinkPad R40 
(Pentium M "Banias" 1.3GHz, speedstepping works just fine), running 
NetBSD 3.99.21.
--
        Thomas E. Spanjaard
        tgen at netphreax.net
Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00004.pgp
Type: application/octet-stream
Size: 186 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080307/de3e5104/attachment-0017.obj>

From civilizd at gmail.com  Fri Mar  7 09:06:41 2008
From: civilizd at gmail.com (Vita "CiV" Cizek)
Date: Fri, 7 Mar 2008 09:06:41 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <98d564710803070853q1c73d795m6e6c5cc5049fa099@mail.gmail.com>

>  Any student volunteers?  We have mentors.
>
I am interested too, especially in some kernel-related work.




From justin at shiningsilence.com  Sat Mar  8 12:07:51 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Sat, 8 Mar 2008 12:07:51 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google SoC 2008 - mentors mentors mentors
Message-ID: <51558.192.168.0.252.1205006403.squirrel@www.shiningsilence.com>

If you are willing to mentor for the Google 2008 Summer of Code, please
speak up.  Right now we have: (from our wiki page)

Matthias
Sephe
TGEN
corecode

Part of the application process includes naming people as mentors (student
applications come later), so I want to get as complete a list as possible.

The application is due on the 12th, so if you want to mentor, now's the
time to say so.

Google's SoC FAQ is here: http://code.google.com/soc/2008/faqs.html

Our wiki page is here: http://wiki.dragonflybsd.org/index.cgi/GoogleSoC2008

- much credit to Matthias and others for getting that set up.





From saw at online.de  Sat Mar  8 14:26:07 2008
From: saw at online.de (Sascha Wildner)
Date: Sat, 08 Mar 2008 23:26:07 +0100
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <47d31245$0$848$415eb37d@crater_reader.dragonflybsd.org>

Sascha Wildner wrote:
Hi all,

this is probably as good a moment as any to come out of the forest with 
this. The patch at

http://leaf.dragonflybsd.org/~swildner/nrelease_gui.diff
Ok, I have committed the stuff as an example.

I'm not sure if my free time permits to work on a full-blown live CD 
with X11 and other good things (I already feel my interest wandering off 
in other directions) so if anyone wants to pick up the ball, go ahead. :)

Sascha

--
http://yoyodyne.ath.cx



From qhwt+dfly at les.ath.cx  Tue Mar 11 22:21:31 2008
From: qhwt+dfly at les.ath.cx (YONETANI Tomokazu)
Date: Tue, 11 Mar 2008 22:21:31 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Misc. ACPI / suspend
In-Reply-To: <47CA073B.6020106@199technologies.org>
Message-ID: <20080312051219.GA56091@les.ath.cx>

On Thu, Mar 06, 2008 at 10:03:21PM -0500, Chris Turner wrote:
> 1) does anyone have ACPI (instead of APM)
>    sleep / suspend / wakeup working on Dfly ?
> 2) If so, what machines are being used ?

Dynabook SS3500 (http://www.tlt.co.jp/pc/catalog/ss/02110735/index_j.htm).
It's old and can get very hot(thus frequently turns on the cooling fan)
even when it's running Windows.  I haven't turned it on for about several
months though.

Cheers.




From c.turner at 199technologies.org  Wed Mar 12 04:37:22 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Wed, 12 Mar 2008 04:37:22 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Misc. ACPI / suspend
In-Reply-To: <47CA073B.6020106@199technologies.org>
Message-ID: <47D7BEE3.6010907@199technologies.org>

YONETANI Tomokazu wrote:
On Thu, Mar 06, 2008 at 10:03:21PM -0500, Chris Turner wrote:
1) does anyone have ACPI (instead of APM)
   sleep / suspend / wakeup working on Dfly ?
Cheers.
ditto..

Suppose this should go to docs@ - in any case..

Thinking about setting up a wiki page on the issue so we
can discuss / track what 'good' hardware / drivers / implementations / 
etc are 'out there' - anyone have any suggestions on where this should
go?

http://wiki.dragonflybsd.org/index.cgi/acpi-overview.html

Remains from the handbook conversion - but I'm hesitant to 'over wikify'
this ..



From c.turner at 199technologies.org  Wed Mar 12 15:36:52 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Wed, 12 Mar 2008 15:36:52 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: devel/cscope
Message-ID: <47D85A08.8040103@199technologies.org>

why oh why did I take so long to try this out !!!

just sharing my eureka moment with the list..

- Chris




From dudu at dudu.ro  Wed Mar 12 15:50:14 2008
From: dudu at dudu.ro (Vlad GALU)
Date: Wed, 12 Mar 2008 15:50:14 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: devel/cscope
In-Reply-To: <47D85A08.8040103@199technologies.org>
Message-ID: <ad79ad6b0803121547r2bf67ffep9e40badaac6490f8@mail.gmail.com>

On 3/13/08, Chris Turner <c.turner at 199technologies.org> wrote:
> why oh why did I take so long to try this out !!!
>
>  just sharing my eureka moment with the list..


    Works nice with vim, too!

>
>
>  - Chris
>


-- 
Mahnahmahnah!




From justin at shiningsilence.com  Sun Mar 16 21:06:13 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Sun, 16 Mar 2008 21:06:13 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: binary packages for 1.12 coming in
Message-ID: <1372.192.168.0.252.1205726088.squirrel@www.shiningsilence.com>

The binary build for 1.12 is taking quite a while.  I've started copying
in newly built packages to
pkgbox.dragonflybsd.org/packages/DragonFly-1.12/i386/ - this should be
getting copied out to mirrors over the next while.

There are currently 1283 packages built, which leaves a whole lot to go;
I'll copy new packages in as they complete.





From hasso at estpak.ee  Wed Mar 19 04:31:08 2008
From: hasso at estpak.ee (Hasso Tepper)
Date: Wed, 19 Mar 2008 04:31:08 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Some questions regarding ACPI
Message-ID: <200803191322.46366.hasso@estpak.ee>

I'm working on bringing in some laptop (and especially thinkpad) specific 
ACPI code from FreeBSD into DragonFly. I never touched ACPI stuff before 
and haven't followed it much either, so I have some questions.

* FreeBSD uses ACPI_SERIAL_* heavily. What's the locking situation in 
  DragonFly and why?

* As far as I can see, PCI integration is commented out in DragonFly. 
  What's the state of it and why?

* platform/pc32/acpica5/acpi_toshiba.c - why is it there? I don't think 
  that this is something pc32 specific in it and it should work in pc64 
  laptops as well. Any objections to move it into 
  dev/acpica5/acpi_toshiba/ ?

What's the current status of ACPI in general? AFAICS our acpica is quite 
old - what needs to be done to bring in newer one?


-- 
Hasso




From qhwt+dfly at les.ath.cx  Wed Mar 19 09:24:50 2008
From: qhwt+dfly at les.ath.cx (YONETANI Tomokazu)
Date: Wed, 19 Mar 2008 09:24:50 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Some questions regarding ACPI
In-Reply-To: <200803191322.46366.hasso@estpak.ee>
Message-ID: <20080319161703.GA51509@les.ath.cx>

On Wed, Mar 19, 2008 at 01:22:46PM +0200, Hasso Tepper wrote:
> I'm working on bringing in some laptop (and especially thinkpad) specific 
> ACPI code from FreeBSD into DragonFly. I never touched ACPI stuff before 
> and haven't followed it much either, so I have some questions.

So you want to port some of ACPI support drivers, or to do a fresh port
of ACPI driver from FreeBSD?

> * FreeBSD uses ACPI_SERIAL_* heavily. What's the locking situation in 
>   DragonFly and why?

The current ACPI driver in DragonFly is based on that of FreeBSD as of
end of June, 2004, plus some fixes brought in later (and ACPICA part
has been updated twice since then).  That was before they introduced
the MPSAFE changes into ACPI code, and we use critical section
(crit_{enter,exit}) in most places (and lockmgr lock in a few place).

> * As far as I can see, PCI integration is commented out in DragonFly. 
>   What's the state of it and why?

When we replaced the implementation taken from FreeBSD 4.x with that
brought from FreeBSD 5.x, which added the PCI part, many people
experienced problems until they turned off ACPI completely, or add "pci"
to "debug.acpi.disabled" loader variable.  AFAIK the PCI part in the ACPI
driver almost hasn't been adjusted to work with our version of PCI code.

> * platform/pc32/acpica5/acpi_toshiba.c - why is it there? I don't think 
>   that this is something pc32 specific in it and it should work in pc64 
>   laptops as well. Any objections to move it into 
>   dev/acpica5/acpi_toshiba/ ?

In FreeBSD it used to be sitting at i386/acpica/acpi_toshiba.c and was
later moved into acpi_support.  That change hasn't hit our tree (in fact,
we have no acpi support drivers other than that).  It seems that FreeBSD
has them in dev/acpi_support now, and we for some reason have that
directory in our CVS repository (but containing no files in it).

> What's the current status of ACPI in general? AFAICS our acpica is quite 
> old - what needs to be done to bring in newer one?

Actually, it's not very important to keep just ACPICA latest, but
if you bring the ACPI driver from FreeBSD you need to bring ACPICA code
that matches their version, and it IS important.  And it generally requires
you much work to just update ACPICA part anyway because of how they
change things on every release.

Cheers.




From hasso at estpak.ee  Wed Mar 19 12:29:52 2008
From: hasso at estpak.ee (Hasso Tepper)
Date: Wed, 19 Mar 2008 12:29:52 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Some questions regarding ACPI
In-Reply-To: <200803191322.46366.hasso@estpak.ee>
Message-ID: <200803192115.35396.hasso@estpak.ee>

YONETANI Tomokazu wrote:
> On Wed, Mar 19, 2008 at 01:22:46PM +0200, Hasso Tepper wrote:
> > I'm working on bringing in some laptop (and especially thinkpad)
> > specific ACPI code from FreeBSD into DragonFly. I never touched ACPI
> > stuff before and haven't followed it much either, so I have some
> > questions.
>
> So you want to port some of ACPI support drivers, or to do a fresh port
> of ACPI driver from FreeBSD?

I'm only interested in support drivers and the reason is pure practical - 
newer thinkpads handle less and less hotkeys etc in hardware and require 
support form OS. acpi_ibm and acpi_video are examples of such modules 
which would help a lot of these newer thinkpad users.

acpi_ibm is almost ready to commit (renamed to acpi_thinkpad though).

> > * FreeBSD uses ACPI_SERIAL_* heavily. What's the locking situation in
> >   DragonFly and why?
>
> The current ACPI driver in DragonFly is based on that of FreeBSD as of
> end of June, 2004, plus some fixes brought in later (and ACPICA part
> has been updated twice since then).  That was before they introduced
> the MPSAFE changes into ACPI code, and we use critical section
> (crit_{enter,exit}) in most places (and lockmgr lock in a few place).

Mkay. Will look at more closely.

> > * As far as I can see, PCI integration is commented out in DragonFly.
> >   What's the state of it and why?
>
> When we replaced the implementation taken from FreeBSD 4.x with that
> brought from FreeBSD 5.x, which added the PCI part, many people
> experienced problems until they turned off ACPI completely, or add
> "pci" to "debug.acpi.disabled" loader variable.  AFAIK the PCI part in
> the ACPI driver almost hasn't been adjusted to work with our version of
> PCI code.

I'm afraid that it's beyond my skills, but while looking at acpi_video I 
discovered that it's hard to handle correctly without PCI support.

> > * platform/pc32/acpica5/acpi_toshiba.c - why is it there? I don't
> > think that this is something pc32 specific in it and it should work
> > in pc64 laptops as well. Any objections to move it into
> >   dev/acpica5/acpi_toshiba/ ?
>
> In FreeBSD it used to be sitting at i386/acpica/acpi_toshiba.c and was
> later moved into acpi_support.  That change hasn't hit our tree (in
> fact, we have no acpi support drivers other than that).  It seems that
> FreeBSD has them in dev/acpi_support now, and we for some reason have
> that directory in our CVS repository (but containing no files in it).

I don't see it ;). Makes sense though. So, any objections if I move 
acpi_toshiba into sys/dev/acpi_support and add new acpi_thinkpad there as 
well? 

> > What's the current status of ACPI in general? AFAICS our acpica is
> > quite old - what needs to be done to bring in newer one?
>
> Actually, it's not very important to keep just ACPICA latest, but
> if you bring the ACPI driver from FreeBSD you need to bring ACPICA code
> that matches their version, and it IS important.  And it generally
> requires you much work to just update ACPICA part anyway because of how
> they change things on every release.

Someone else has to do it :).

Thanks for info.


-- 
Hasso




From dillon at apollo.backplane.com  Wed Mar 19 14:01:13 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Wed, 19 Mar 2008 14:01:13 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: panic: assertion: hammer_btree_cmp(cursor->left_bound,	&cursor->node->ondisk->elms[0].leaf.base) <= 0 in btree_split_leaf
In-Reply-To: <200802232204.m1NM4cxd046264@apollo.backplane.com>
Message-ID: <200803192054.m2JKsjwn045137@apollo.backplane.com>


:Hi.
:While trying to find a procedure to reliably reproduce the panic
:I reported last time, I caught a different panic (uploaded at
: ~y0netan1/crash/9/ on my leaf account).  I wrote the following shell
:script (make sure to edit variables DISKS and MOUNTPT before using this
:script or it may trash your system):
:  #!/bin/sh -ex
:  DISKS="/dev/ad0s1f"
:  MOUNTPT=/mnt/HAMMER
:
:  cd /
:  newfs_hammer -L TEST $DISKS
:  for i in `seq 1 100`; do
:..
:And the panic is triggered by rm command.
:I'll try to see if it's possible to reproduce the last one without
:unmounting then mounting the HAMMER fs.
:
:Cheers.

    I believe I have fixed this panic.  hammer_make_separator() had a bug
    in it.

    There is still an issue with the node ref count on umount.

    Please continue to life-test the code.  The reblocking code
    (hammer reblock /mnt) should work now, as should the pruning code
    (e.g. hammer prune /mnt everything).

    The filesystem full case is still not handled and will cause bad things
    to happen.  The undo code isn't finished yet either but it is getting
    there (it's writing stuff out but not setting the sequence number and
    not trying to recover-on-mount yet).

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From qhwt+dfly at les.ath.cx  Wed Mar 19 19:45:40 2008
From: qhwt+dfly at les.ath.cx (YONETANI Tomokazu)
Date: Wed, 19 Mar 2008 19:45:40 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Some questions regarding ACPI
In-Reply-To: <200803191322.46366.hasso@estpak.ee>
Message-ID: <20080320023828.GA53648@les.ath.cx>

On Wed, Mar 19, 2008 at 09:15:35PM +0200, Hasso Tepper wrote:
> YONETANI Tomokazu wrote:
> > On Wed, Mar 19, 2008 at 01:22:46PM +0200, Hasso Tepper wrote:
> > > I'm working on bringing in some laptop (and especially thinkpad)
> > > specific ACPI code from FreeBSD into DragonFly. I never touched ACPI
> > > stuff before and haven't followed it much either, so I have some
> > > questions.
> >
> > So you want to port some of ACPI support drivers, or to do a fresh port
> > of ACPI driver from FreeBSD?
> 
> I'm only interested in support drivers and the reason is pure practical - 
> newer thinkpads handle less and less hotkeys etc in hardware and require 
> support form OS. acpi_ibm and acpi_video are examples of such modules 
> which would help a lot of these newer thinkpad users.
> 
> acpi_ibm is almost ready to commit (renamed to acpi_thinkpad though).

Ah, that's a good news!  My only concern is that ISTR someone mentioned
me that his colleague was thinking about porting ACPI driver itself,
so if you're not the person you may want to collaborate with him/her
so as not to waste the effort or time...

			:

> > In FreeBSD it used to be sitting at i386/acpica/acpi_toshiba.c and was
> > later moved into acpi_support.  That change hasn't hit our tree (in
> > fact, we have no acpi support drivers other than that).  It seems that
> > FreeBSD has them in dev/acpi_support now, and we for some reason have
> > that directory in our CVS repository (but containing no files in it).
> 
> I don't see it ;). Makes sense though. So, any objections if I move 
> acpi_toshiba into sys/dev/acpi_support and add new acpi_thinkpad there as 
> well? 

Sorry, I checked the CVS repository and it doesn't exist actually :)
I don't have any objection to moving it there.

Cheers.




From hasso at estpak.ee  Thu Mar 20 00:14:05 2008
From: hasso at estpak.ee (Hasso Tepper)
Date: Thu, 20 Mar 2008 00:14:05 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Some questions regarding ACPI
In-Reply-To: <200803191322.46366.hasso@estpak.ee>
Message-ID: <200803200904.50875.hasso@estpak.ee>

YONETANI Tomokazu wrote:
> On Wed, Mar 19, 2008 at 09:15:35PM +0200, Hasso Tepper wrote:
> > acpi_ibm is almost ready to commit (renamed to acpi_thinkpad though).
>
> Ah, that's a good news!  My only concern is that ISTR someone mentioned
> me that his colleague was thinking about porting ACPI driver itself,
> so if you're not the person you may want to collaborate with him/her
> so as not to waste the effort or time...

Current state in my repo is attached. It should work on 1.12 as well as it 
doesn't depend yet on moving stuff around.

add-acpi-if-m.patch adds some new stuff to the ACPI code to access 
embedded controllers and match ACPI devices by ID. Not sure how, where 
and whether at all these should be documented.

add-acpi-thinkpad.patch is the driver itself. Note that some stuff doesn't 
work yet on newer thinkpads, I plan to work on it later.

There is still some things to do though. I have to decide what to do with 
led(4) part and with locking. There is also one fatal issue - laptop 
locks up hardly (no panic) while unloading module. Any idea regarding 
this is welcome. And of course test results :).


-- 
Hasso
# HG changeset patch
# User Hasso Tepper <hasso at estpak.ee>
# Date 1205919290 -7200
# Branch HEAD
# Node ID 5a6e2705cc95a340abf973ae5df73ef34e070b79
# Parent  cd529e2e7f849034d5d5a0973cb98af50db0e797
imported patch adding-acpi-if-m.patch

diff --git a/sys/conf/files b/sys/conf/files
--- a/sys/conf/files
+++ b/sys/conf/files
@@ -1387,6 +1387,7 @@ emulation/dragonfly12/dfbsd12_stat.c	non
 ${OSACPI_MI_DIR}/acpi_cmbat.c		optional acpi
 ${OSACPI_MI_DIR}/acpi_cpu.c		optional acpi
 ${OSACPI_MI_DIR}/acpi_ec.c		optional acpi
+${OSACPI_MI_DIR}/acpi_if.m		optional acpi
 ${OSACPI_MI_DIR}/acpi_isab.c		optional acpi isa
 ${OSACPI_MI_DIR}/acpi_lid.c		optional acpi
 ${OSACPI_MI_DIR}/acpi_package.c		optional acpi
diff --git a/sys/conf/kmod.mk b/sys/conf/kmod.mk
--- a/sys/conf/kmod.mk
+++ b/sys/conf/kmod.mk
@@ -275,7 +275,7 @@ MFILES?= kern/bus_if.m kern/device_if.m 
     bus/pccard/card_if.m bus/pccard/power_if.m bus/pci/pci_if.m \
     bus/pci/pcib_if.m \
     bus/ppbus/ppbus_if.m bus/smbus/smbus_if.m bus/usb/usb_if.m \
-    dev/disk/nata/ata_if.m \
+    dev/acpica5/acpi_if.m dev/disk/nata/ata_if.m \
     dev/sound/pcm/ac97_if.m dev/sound/pcm/channel_if.m \
     dev/sound/pcm/feeder_if.m dev/sound/pcm/mixer_if.m \
     libiconv/iconv_converter_if.m dev/agp/agp_if.m opencrypto/crypto_if.m
diff --git a/sys/dev/acpica5/Makefile b/sys/dev/acpica5/Makefile
--- a/sys/dev/acpica5/Makefile
+++ b/sys/dev/acpica5/Makefile
@@ -69,12 +69,14 @@ SRCS+=  acpi_package.c
 # SRCS+=	acpi_pci.c acpi_pcib.c acpi_pcib_acpi.c acpi_pcib_pci.c
 # SRCS+=	acpi_pci_link.c
 SRCS+=  acpi_powerres.c acpi_resource.c acpi_thermal.c
-SRCS+=  acpi_timer.c
+SRCS+=  acpi_timer.c acpi_if.c
 SRCS+=  OsdDebug.c
 SRCS+=  OsdHardware.c OsdInterface.c OsdInterrupt.c OsdMemory.c OsdSchedule.c
 SRCS+=  OsdStream.c OsdSynch.c OsdTable.c OsdEnvironment.c
 SRCS+=  opt_acpi.h opt_bus.h opt_ddb.h
-SRCS+=  device_if.h bus_if.h pci_if.h pcib_if.h isa_if.h
+SRCS+=  device_if.h bus_if.h pci_if.h pcib_if.h isa_if.h acpi_if.h
+MFILES = kern/device_if.m kern/bus_if.m bus/pci/pci_if.m bus/pci/pcib_if.m
+MFILES+= bus/isa/isa_if.m dev/acpica5/acpi_if.m
 
 # Debugging support
 DBSRC=	dbcmds.c dbdisply.c dbexec.c dbfileio.c dbhistry.c
diff --git a/sys/dev/acpica5/acpi.c b/sys/dev/acpica5/acpi.c
--- a/sys/dev/acpica5/acpi.c
+++ b/sys/dev/acpica5/acpi.c
@@ -135,6 +135,7 @@ static int	acpi_release_resource(device_
 			int rid, struct resource *r);
 static uint32_t	acpi_isa_get_logicalid(device_t dev);
 static int	acpi_isa_get_compatid(device_t dev, uint32_t *cids, int count);
+static char	*acpi_device_id_probe(device_t bus, device_t dev, char **ids);
 static int	acpi_isa_pnp_probe(device_t bus, device_t child,
 			struct isa_pnp_id *ids);
 static void	acpi_probe_children(device_t bus);
@@ -189,6 +190,9 @@ static device_method_t acpi_methods[] = 
     DEVMETHOD(bus_deactivate_resource,	bus_generic_deactivate_resource),
     DEVMETHOD(bus_setup_intr,		bus_generic_setup_intr),
     DEVMETHOD(bus_teardown_intr,	bus_generic_teardown_intr),
+
+    /* ACPI bus */
+    DEVMETHOD(acpi_id_probe,		acpi_device_id_probe),
 
     /* ISA emulation */
     DEVMETHOD(isa_pnp_probe,		acpi_isa_pnp_probe),
@@ -1121,6 +1125,24 @@ out:
 	AcpiOsFree(buf.Pointer);
     ACPI_UNLOCK;
     return_VALUE (valid);
+}
+
+static char *
+acpi_device_id_probe(device_t bus, device_t dev, char **ids) 
+{
+    ACPI_HANDLE h;
+    int i;
+
+    h = acpi_get_handle(dev);
+    if (ids == NULL || h == NULL || acpi_get_type(dev) != ACPI_TYPE_DEVICE)
+	return (NULL);
+
+    /* Try to match one of the array of IDs with a HID or CID. */
+    for (i = 0; ids[i] != NULL; i++) {
+	if (acpi_MatchHid(h, ids[i]))
+	    return (ids[i]);
+    }
+    return (NULL);
 }
 
 static int
diff --git a/sys/dev/acpica5/acpi_ec.c b/sys/dev/acpica5/acpi_ec.c
--- a/sys/dev/acpica5/acpi_ec.c
+++ b/sys/dev/acpica5/acpi_ec.c
@@ -327,11 +327,19 @@ static ACPI_STATUS	EcWrite(struct acpi_e
 				UINT8 *Data);
 static int		acpi_ec_probe(device_t dev);
 static int		acpi_ec_attach(device_t dev);
+static int		acpi_ec_read_method(device_t dev, u_int addr,
+				ACPI_INTEGER *val, int width);
+static int		acpi_ec_write_method(device_t dev, u_int addr,
+				ACPI_INTEGER val, int width);
 
 static device_method_t acpi_ec_methods[] = {
     /* Device interface */
     DEVMETHOD(device_probe,	acpi_ec_probe),
     DEVMETHOD(device_attach,	acpi_ec_attach),
+
+    /* Embedded controller interface */
+    DEVMETHOD(acpi_ec_read,     acpi_ec_read_method),
+    DEVMETHOD(acpi_ec_write,    acpi_ec_write_method),
 
     {0, 0}
 };
@@ -620,6 +628,33 @@ error:
 			     sc->ec_data_res);
     /* mtx_destroy(&sc->ec_mtx); */
     return (ENXIO);
+}
+
+/* Methods to allow other devices (e.g., smbat) to read/write EC space. */
+static int
+acpi_ec_read_method(device_t dev, u_int addr, ACPI_INTEGER *val, int width)
+{
+    struct acpi_ec_softc *sc;
+    ACPI_STATUS status;
+
+    sc = device_get_softc(dev);
+    status = EcSpaceHandler(ACPI_READ, addr, width * 8, val, sc, NULL);
+    if (ACPI_FAILURE(status))
+        return (ENXIO);
+    return (0);
+}
+
+static int
+acpi_ec_write_method(device_t dev, u_int addr, ACPI_INTEGER val, int width)
+{
+    struct acpi_ec_softc *sc;
+    ACPI_STATUS status;
+
+    sc = device_get_softc(dev);
+    status = EcSpaceHandler(ACPI_WRITE, addr, width * 8, &val, sc, NULL);
+    if (ACPI_FAILURE(status))
+        return (ENXIO);
+    return (0);
 }
 
 static void
diff --git a/sys/dev/acpica5/acpi_if.m b/sys/dev/acpica5/acpi_if.m
new file mode 100644
--- /dev/null
+++ b/sys/dev/acpica5/acpi_if.m
@@ -0,0 +1,92 @@
+#-
+# Copyright (c) 2004 Nate Lawson
+# All rights reserved.
+#
+# Redistribution and use in source and binary forms, with or without
+# modification, are permitted provided that the following conditions
+# are met:
+# 1. Redistributions of source code must retain the above copyright
+#    notice, this list of conditions and the following disclaimer.
+# 2. Redistributions in binary form must reproduce the above copyright
+#    notice, this list of conditions and the following disclaimer in the
+#    documentation and/or other materials provided with the distribution.
+#
+# THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
+# ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+# ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
+# FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+# DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+# OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+# HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+# LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+# OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+# SUCH DAMAGE.
+#
+# $DragonFly$
+#
+
+#include <sys/bus.h>
+#include <sys/types.h>
+#include "acpi.h"
+
+INTERFACE acpi;
+
+#
+# Default implementation for acpi_id_probe().
+#
+CODE {
+	static char *
+	acpi_generic_id_probe(device_t bus, device_t dev, char **ids)
+	{
+		return (NULL);
+	}
+};
+
+#
+# Check a device for a match in a list of ID strings.  The strings can be
+# EISA PNP IDs or ACPI _HID/_CID values.
+#
+# device_t bus:  parent bus for the device
+#
+# device_t dev:  device being considered
+#
+# char **ids:  array of ID strings to consider
+#
+# Returns:  ID string matched or NULL if no match
+#
+METHOD char * id_probe {
+	device_t	bus;
+	device_t	dev;
+	char		**ids;
+} DEFAULT acpi_generic_id_probe;
+
+#
+# Read embedded controller (EC) address space
+#
+# device_t dev:  EC device
+# u_int addr:  Address to read from in EC space
+# ACPI_INTEGER *val:  Location to store read value
+# int width:  Size of area to read in bytes
+#
+METHOD int ec_read {
+	device_t	dev;
+	u_int		addr;
+	ACPI_INTEGER	*val;
+	int		width;
+};
+
+#
+# Write embedded controller (EC) address space
+#
+# device_t dev:  EC device
+# u_int addr:  Address to write to in EC space
+# ACPI_INTEGER val:  Value to write
+# int width:  Size of value to write in bytes
+#
+METHOD int ec_write {
+	device_t	dev;
+	u_int		addr;
+	ACPI_INTEGER	val;
+	int		width;
+};
diff --git a/sys/dev/acpica5/acpivar.h b/sys/dev/acpica5/acpivar.h
--- a/sys/dev/acpica5/acpivar.h
+++ b/sys/dev/acpica5/acpivar.h
@@ -29,6 +29,7 @@
  * $DragonFly: src/sys/dev/acpica5/acpivar.h,v 1.12 2007/10/23 03:04:48 y0netan1 Exp $
  */
 
+#include "acpi_if.h"
 #include "bus_if.h"
 #include <sys/eventhandler.h>
 #include <sys/sysctl.h>
# HG changeset patch
# User Hasso Tepper <hasso at estpak.ee>
# Date 1205995474 -7200
# Branch HEAD
# Node ID c5db8d4a7c6b25a8576a8d42c5029aaf0e23bfb6
# Parent  5a6e2705cc95a340abf973ae5df73ef34e070b79
[mq]: adding-acpi-thinkpad.patch

diff --git a/sys/dev/acpica5/Makefile b/sys/dev/acpica5/Makefile
--- a/sys/dev/acpica5/Makefile
+++ b/sys/dev/acpica5/Makefile
@@ -117,7 +117,7 @@ acpi_wakecode.h: acpi_wakecode.S
 	${MAKE} -f ${SYSDIR}/${OSACPI_MD_DIR}/Makefile \
 		MAKESRCPATH=${SYSDIR}/${OSACPI_MD_DIR}
 
-SUBDIR=	acpi_toshiba
+SUBDIR=	acpi_toshiba acpi_thinkpad
 all: ${PROG} ${SUBDIR}
 
 # *.o file for each patched *.c file is created under the same directory,
diff --git a/sys/dev/acpica5/acpi_thinkpad/Makefile b/sys/dev/acpica5/acpi_thinkpad/Makefile
new file mode 100644
--- /dev/null
+++ b/sys/dev/acpica5/acpi_thinkpad/Makefile
@@ -0,0 +1,9 @@
+# $DragonFly$
+
+SYSDIR?=${.CURDIR}/../../..
+
+KMOD=		acpi_thinkpad
+CFLAGS+=	-I${.OBJDIR}/.. -I${.CURDIR}/..
+SRCS=		acpi_thinkpad.c opt_acpi.h device_if.h bus_if.h
+
+.include <bsd.kmod.mk>
diff --git a/sys/dev/acpica5/acpi_thinkpad/acpi_thinkpad.c b/sys/dev/acpica5/acpi_thinkpad/acpi_thinkpad.c
new file mode 100644
--- /dev/null
+++ b/sys/dev/acpica5/acpi_thinkpad/acpi_thinkpad.c
@@ -0,0 +1,1046 @@
+/*
+ * Copyright (c) 2004 Takanori Watanabe
+ * Copyright (c) 2005 Markus Brueffer <markus at FreeBSD.org>
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *    notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *    notice, this list of conditions and the following disclaimer in the
+ *    documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+ */
+
+/*
+ * Driver for extra ACPI-controlled gadgets found on IBM and Lenovo ThinkPad
+ * laptops. Inspired by the ibm-acpi and tpb projects which implement these
+ * features on Linux.
+ *
+ *   acpi-ibm: <http://ibm-acpi.sourceforge.net/>
+ *        tpb: <http://www.nongnu.org/tpb/>
+ */
+
+#include "opt_acpi.h"
+#include <sys/param.h>
+#include <sys/kernel.h>
+#include <sys/bus.h>
+#include <machine/cpufunc.h>
+#include <sys/module.h>
+/* #include <dev/led/led.h> */
+#include <sys/sensors.h>
+#include <sys/sysctl.h>
+#include <machine/clock.h>
+
+#include "acpi.h"
+#include "acpivar.h"
+#include "acpi_if.h"
+
+#define _COMPONENT	ACPI_OEM
+ACPI_MODULE_NAME("THINKPAD")
+
+/* Internal methods */
+#define ACPI_THINKPAD_METHOD_EVENTS		1
+#define ACPI_THINKPAD_METHOD_EVENTMASK		2
+#define ACPI_THINKPAD_METHOD_HOTKEY		3
+#define ACPI_THINKPAD_METHOD_BRIGHTNESS		4
+#define ACPI_THINKPAD_METHOD_VOLUME		5
+#define ACPI_THINKPAD_METHOD_MUTE		6
+#define ACPI_THINKPAD_METHOD_THINKLIGHT		7
+#define ACPI_THINKPAD_METHOD_BLUETOOTH		8
+#define ACPI_THINKPAD_METHOD_WLAN		9
+#define ACPI_THINKPAD_METHOD_FANSPEED		10
+#define ACPI_THINKPAD_METHOD_FANLEVEL		11
+#define ACPI_THINKPAD_METHOD_FANSTATUS		12
+#define ACPI_THINKPAD_METHOD_THERMAL		13
+
+/* Hotkeys/Buttons */
+#define THINKPAD_RTC_HOTKEY1			0x64
+#define   THINKPAD_RTC_MASK_HOME		(1 << 0)
+#define   THINKPAD_RTC_MASK_SEARCH		(1 << 1)
+#define   THINKPAD_RTC_MASK_MAIL		(1 << 2)
+#define   THINKPAD_RTC_MASK_WLAN		(1 << 5)
+#define THINKPAD_RTC_HOTKEY2			0x65
+#define   THINKPAD_RTC_MASK_THINKPAD		(1 << 3)
+#define   THINKPAD_RTC_MASK_ZOOM		(1 << 5)
+#define   THINKPAD_RTC_MASK_VIDEO		(1 << 6)
+#define   THINKPAD_RTC_MASK_HIBERNATE		(1 << 7)
+#define THINKPAD_RTC_THINKLIGHT			0x66
+#define   THINKPAD_RTC_MASK_THINKLIGHT		(1 << 4)
+#define THINKPAD_RTC_SCREENEXPAND		0x67
+#define   THINKPAD_RTC_MASK_SCREENEXPAND	(1 << 5)
+#define THINKPAD_RTC_BRIGHTNESS			0x6c
+#define   THINKPAD_RTC_MASK_BRIGHTNESS		(1 << 5)
+#define THINKPAD_RTC_VOLUME			0x6e
+#define   THINKPAD_RTC_MASK_VOLUME		(1 << 7)
+
+/* Embedded Controller registers */
+#define THINKPAD_EC_BRIGHTNESS			0x31
+#define   THINKPAD_EC_MASK_BRI			0x7
+#define THINKPAD_EC_VOLUME			0x30
+#define   THINKPAD_EC_MASK_VOL			0xf
+#define   THINKPAD_EC_MASK_MUTE			(1 << 6)
+#define THINKPAD_EC_FANSTATUS			0x2F
+#define   THINKPAD_EC_MASK_FANLEVEL		0x3f
+#define   THINKPAD_EC_MASK_FANDISENGAGED	(1 << 6)
+#define   THINKPAD_EC_MASK_FANSTATUS		(1 << 7)
+#define THINKPAD_EC_FANSPEED			0x84
+
+/* CMOS Commands */
+#define THINKPAD_CMOS_VOLUME_DOWN		0
+#define THINKPAD_CMOS_VOLUME_UP			1
+#define THINKPAD_CMOS_VOLUME_MUTE		2
+#define THINKPAD_CMOS_BRIGHTNESS_UP		4
+#define THINKPAD_CMOS_BRIGHTNESS_DOWN		5
+
+/* ACPI methods */
+#define THINKPAD_NAME_KEYLIGHT			"KBLT"
+#define THINKPAD_NAME_WLAN_BT_GET		"GBDC"
+#define THINKPAD_NAME_WLAN_BT_SET		"SBDC"
+#define   THINKPAD_NAME_MASK_BT			(1 << 1)
+#define   THINKPAD_NAME_MASK_WLAN		(1 << 2)
+#define THINKPAD_NAME_THERMAL_GET		"TMP7"
+#define THINKPAD_NAME_THERMAL_UPDT		"UPDT"
+
+#define THINKPAD_NAME_EVENTS_STATUS_GET		"DHKC"
+#define THINKPAD_NAME_EVENTS_MASK_GET		"DHKN"
+#define THINKPAD_NAME_EVENTS_STATUS_SET		"MHKC"
+#define THINKPAD_NAME_EVENTS_MASK_SET		"MHKM"
+#define THINKPAD_NAME_EVENTS_GET		"MHKP"
+#define THINKPAD_NAME_EVENTS_AVAILMASK		"MHKA"
+
+#define ABS(x) (((x) < 0)? -(x) : (x))
+
+struct acpi_thinkpad_softc {
+	device_t	dev;
+	ACPI_HANDLE	handle;
+
+	/* Embedded controller */
+	device_t	ec_dev;
+	ACPI_HANDLE	ec_handle;
+
+	/* CMOS */
+	ACPI_HANDLE	cmos_handle;
+
+	/* Fan status */
+	ACPI_HANDLE	fan_handle;
+	int		fan_levels;
+
+	/* Keylight commands and states */
+	ACPI_HANDLE	light_handle;
+	int		light_cmd_on;
+	int		light_cmd_off;
+	int		light_val;
+	int		light_get_supported;
+	int		light_set_supported;
+
+	/* led(4) interface */
+	struct cdev	*led_dev;
+	int		led_busy;
+	int		led_state;
+
+	int		wlan_bt_flags;
+	int		thermal_updt_supported;
+
+	unsigned int	events_availmask;
+	unsigned int	events_initialmask;
+	int		events_mask_supported;
+	int		events_enable;
+
+	/* sensors(9) related */
+	struct ksensordev sensordev;
+	struct ksensor sensors[9];	/* XXX: 8 thermal + fan */
+
+	struct sysctl_ctx_list	*sysctl_ctx;
+	struct sysctl_oid	*sysctl_tree;
+};
+
+static struct {
+	char	*name;
+	int	method;
+	char	*description;
+	int	access;
+} acpi_thinkpad_sysctls[] = {
+	{
+		.name		= "events",
+		.method		= ACPI_THINKPAD_METHOD_EVENTS,
+		.description	= "ACPI events enable",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "eventmask",
+		.method		= ACPI_THINKPAD_METHOD_EVENTMASK,
+		.description	= "ACPI eventmask",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "hotkey",
+		.method		= ACPI_THINKPAD_METHOD_HOTKEY,
+		.description	= "Key Status",
+		.access		= CTLTYPE_INT | CTLFLAG_RD
+	},
+	{
+		.name		= "lcd_brightness",
+		.method		= ACPI_THINKPAD_METHOD_BRIGHTNESS,
+		.description	= "LCD Brightness",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "volume",
+		.method		= ACPI_THINKPAD_METHOD_VOLUME,
+		.description	= "Volume",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "mute",
+		.method		= ACPI_THINKPAD_METHOD_MUTE,
+		.description	= "Mute",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "thinklight",
+		.method		= ACPI_THINKPAD_METHOD_THINKLIGHT,
+		.description	= "Thinklight enable",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "bluetooth",
+		.method		= ACPI_THINKPAD_METHOD_BLUETOOTH,
+		.description	= "Bluetooth enable",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "wlan",
+		.method		= ACPI_THINKPAD_METHOD_WLAN,
+		.description	= "WLAN enable",
+		.access		= CTLTYPE_INT | CTLFLAG_RD
+	},
+	{
+		.name		= "fan_level",
+		.method		= ACPI_THINKPAD_METHOD_FANLEVEL,
+		.description	= "Fan level",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "fan",
+		.method		= ACPI_THINKPAD_METHOD_FANSTATUS,
+		.description	= "Fan enable",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+
+	{ NULL, 0, NULL, 0 }
+};
+
+/* ACPI_SERIAL_DECL(thinkpad, "ACPI THINKPAD extras"); */
+static int	acpi_thinkpad_probe(device_t dev);
+static int	acpi_thinkpad_attach(device_t dev);
+static int	acpi_thinkpad_detach(device_t dev);
+
+#if 0 /* not yet */
+static void	thinkpad_led(void *softc, int onoff);
+static void	thinkpad_led_task(struct acpi_thinkpad_softc *sc,
+		int pending __unused);
+#endif
+
+static int	acpi_thinkpad_sysctl(SYSCTL_HANDLER_ARGS);
+static int	acpi_thinkpad_sysctl_init(struct acpi_thinkpad_softc *sc,
+		int method);
+static int	acpi_thinkpad_sysctl_get(struct acpi_thinkpad_softc *sc,
+		int method);
+static int	acpi_thinkpad_sysctl_set(struct acpi_thinkpad_softc *sc,
+		int method, int val);
+
+static int	acpi_thinkpad_eventmask_set(struct acpi_thinkpad_softc *sc,
+		int val);
+static void	acpi_thinkpad_notify(ACPI_HANDLE h, UINT32 notify,
+		void *context);
+static void	acpi_thinkpad_refresh(void *);
+
+static device_method_t acpi_thinkpad_methods[] = {
+	/* Device interface */
+	DEVMETHOD(device_probe, acpi_thinkpad_probe),
+	DEVMETHOD(device_attach, acpi_thinkpad_attach),
+	DEVMETHOD(device_detach, acpi_thinkpad_detach),
+	{0, 0}
+};
+
+static driver_t	acpi_thinkpad_driver = {
+	"acpi_thinkpad",
+	acpi_thinkpad_methods,
+	sizeof(struct acpi_thinkpad_softc),
+};
+
+static devclass_t acpi_thinkpad_devclass;
+
+DRIVER_MODULE(acpi_thinkpad, acpi, acpi_thinkpad_driver,
+    acpi_thinkpad_devclass, 0, 0);
+MODULE_DEPEND(acpi_thinkpad, acpi, 1, 1, 1);
+static char    *thinkpad_ids[] = {"IBM0068", NULL};
+
+#if 0 /* not yet */
+static void
+thinkpad_led(void *softc, int onoff)
+{
+	struct acpi_thinkpad_softc* sc = (struct acpi_thinkpad_softc*) softc;
+
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+
+	if (sc->led_busy)
+		return;
+
+	sc->led_busy = 1;
+	sc->led_state = onoff;
+
+	AcpiOsExecute(OSL_NOTIFY_HANDLER, (void *)thinkpad_led_task, sc);
+}
+
+static void
+thinkpad_led_task(struct acpi_thinkpad_softc *sc, int pending __unused)
+{
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+
+	/* ACPI_SERIAL_BEGIN(thinkpad); */
+	acpi_thinkpad_sysctl_set(sc, ACPI_THINKPAD_METHOD_THINKLIGHT, sc->led_state);
+	/* ACPI_SERIAL_END(thinkpad); */
+
+	sc->led_busy = 0;
+}
+#endif
+
+static int
+acpi_thinkpad_probe(device_t dev)
+{
+	if (acpi_disabled("thinkpad") ||
+	    ACPI_ID_PROBE(device_get_parent(dev), dev, thinkpad_ids) == NULL ||
+	    device_get_unit(dev) != 0) 
+		return (ENXIO);
+
+	device_set_desc(dev, "IBM/Lenovo ThinkPad ACPI Extras");
+	return (0);
+}
+
+static int
+acpi_thinkpad_attach(device_t dev)
+{
+	struct acpi_thinkpad_softc	*sc;
+	struct acpi_softc	*acpi_sc;
+	devclass_t		ec_devclass;
+	int			i;
+
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t) __func__);
+
+	sc = device_get_softc(dev);
+	sc->dev = dev;
+	sc->handle = acpi_get_handle(dev);
+
+	acpi_sc = acpi_device_get_parent_softc(dev);
+
+	/* Look for the first embedded controller */
+        if (!(ec_devclass = devclass_find ("acpi_ec"))) {
+		if (bootverbose)
+			device_printf(dev, "Couldn't find acpi_ec devclass\n");
+		return (EINVAL);
+	}
+        if (!(sc->ec_dev = devclass_get_device(ec_devclass, 0))) {
+		if (bootverbose)
+			device_printf(dev, "Couldn't find acpi_ec device\n");
+		return (EINVAL);
+	}
+	sc->ec_handle = acpi_get_handle(sc->ec_dev);
+
+	/* ACPI_SERIAL_BEGIN(thinkpad); */
+
+#if 0
+	/* Get the sysctl tree */
+	sc->sysctl_ctx = device_get_sysctl_ctx(dev);
+	sc->sysctl_tree = device_get_sysctl_tree(dev);
+#endif
+	sysctl_ctx_init(sc->sysctl_ctx);
+	sc->sysctl_tree = SYSCTL_ADD_NODE(sc->sysctl_ctx,
+	    SYSCTL_CHILDREN(acpi_sc->acpi_sysctl_tree), OID_AUTO,
+	    "thinkpad", CTLFLAG_RD, 0, "");
+
+	/* Look for event mask and hook up the nodes */
+	sc->events_mask_supported = ACPI_SUCCESS(acpi_GetInteger(sc->handle,
+	    THINKPAD_NAME_EVENTS_MASK_GET, &sc->events_initialmask));
+
+	if (sc->events_mask_supported) {
+		SYSCTL_ADD_INT(sc->sysctl_ctx,
+		    SYSCTL_CHILDREN(sc->sysctl_tree), OID_AUTO,
+		    "initialmask", CTLFLAG_RD,
+		    &sc->events_initialmask, 0, "Initial eventmask");
+
+		/* The availmask is the bitmask of supported events */
+		if (ACPI_FAILURE(acpi_GetInteger(sc->handle,
+		    THINKPAD_NAME_EVENTS_AVAILMASK, &sc->events_availmask)))
+			sc->events_availmask = 0xffffffff;
+
+		SYSCTL_ADD_INT(sc->sysctl_ctx,
+		    SYSCTL_CHILDREN(sc->sysctl_tree), OID_AUTO,
+		    "availmask", CTLFLAG_RD,
+		    &sc->events_availmask, 0, "Mask of supported events");
+	}
+
+	/* Hook up proc nodes */
+	for (i = 0; acpi_thinkpad_sysctls[i].name != NULL; i++) {
+		if (!acpi_thinkpad_sysctl_init(sc,
+		    acpi_thinkpad_sysctls[i].method))
+			continue;
+
+		SYSCTL_ADD_PROC(sc->sysctl_ctx,
+		    SYSCTL_CHILDREN(sc->sysctl_tree), OID_AUTO,
+		    acpi_thinkpad_sysctls[i].name,
+		    acpi_thinkpad_sysctls[i].access,
+		    sc, i, acpi_thinkpad_sysctl, "I",
+		    acpi_thinkpad_sysctls[i].description);
+	}
+
+	/* ACPI_SERIAL_END(thinkpad); */
+
+	/* Handle notifies */
+	AcpiInstallNotifyHandler(sc->handle, ACPI_DEVICE_NOTIFY,
+	    acpi_thinkpad_notify, dev);
+
+#if 0
+	/* Hook up light to led(4) */
+	if (sc->light_set_supported)
+		sc->led_dev = led_create_state(thinkpad_led, sc, "thinklight",
+		    sc->light_val);
+#endif
+	/* Attach sensors(9). */
+	if (sensor_task_register(sc, acpi_thinkpad_refresh, 5)) {
+		device_printf(sc->dev, "unable to register update task\n");
+		return 1;
+	}
+
+	strlcpy(sc->sensordev.xname, device_get_nameunit(sc->dev),
+	    sizeof(sc->sensordev.xname));
+
+	/* XXX: Temp sensors */
+	for (i = 0; i < 8; ++i) {
+		sc->sensors[i].type = SENSOR_TEMP;
+		sensor_attach(&sc->sensordev, &sc->sensors[i]);
+	}
+	
+	/* Fan RPM sensor */
+	sc->sensors[8].type = SENSOR_FANRPM;
+	sensor_attach(&sc->sensordev, &sc->sensors[8]);
+
+	sensordev_install(&sc->sensordev);
+
+	return (0);
+}
+
+static int
+acpi_thinkpad_detach(device_t dev)
+{
+	int i;
+
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t) __func__);
+
+	struct acpi_thinkpad_softc *sc = device_get_softc(dev);
+
+	/* Disable events and restore eventmask */
+	/* ACPI_SERIAL_BEGIN(thinkpad); */
+	acpi_thinkpad_sysctl_set(sc, ACPI_THINKPAD_METHOD_EVENTS, 0);
+	acpi_thinkpad_sysctl_set(sc, ACPI_THINKPAD_METHOD_EVENTMASK,
+	    sc->events_initialmask);
+	/* ACPI_SERIAL_END(thinkpad); */
+
+	AcpiRemoveNotifyHandler(sc->handle, ACPI_DEVICE_NOTIFY,
+	    acpi_thinkpad_notify);
+
+	sysctl_ctx_free(sc->sysctl_ctx);
+
+#if 0
+	if (sc->led_dev != NULL)
+		led_destroy(sc->led_dev);
+#endif
+	sensordev_deinstall(&sc->sensordev);
+	for (i = 0; i < 9; i++)
+		sensor_detach(&sc->sensordev, &sc->sensors[i]);
+	sensor_task_unregister(sc);
+
+	return (0);
+}
+
+static int
+acpi_thinkpad_eventmask_set(struct acpi_thinkpad_softc *sc, int val)
+{
+	int i;
+	ACPI_OBJECT		arg[2];
+	ACPI_OBJECT_LIST	args;
+	ACPI_STATUS		status;
+
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+	/* ACPI_SERIAL_ASSERT(thinkpad); */
+
+	args.Count = 2;
+	args.Pointer = arg;
+	arg[0].Type = ACPI_TYPE_INTEGER;
+	arg[1].Type = ACPI_TYPE_INTEGER;
+
+	for (i = 0; i < 32; ++i) {
+		arg[0].Integer.Value = i+1;
+		arg[1].Integer.Value = (((1 << i) & val) != 0);
+		status = AcpiEvaluateObject(sc->handle,
+		    THINKPAD_NAME_EVENTS_MASK_SET, &args, NULL);
+
+		if (ACPI_FAILURE(status))
+			return (status);
+	}
+
+	return (0);
+}
+
+static int
+acpi_thinkpad_sysctl(SYSCTL_HANDLER_ARGS)
+{
+	struct acpi_thinkpad_softc	*sc;
+	int			arg;
+	int			error = 0;
+	int			function;
+	int			method;
+	
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+
+	sc = (struct acpi_thinkpad_softc *)oidp->oid_arg1;
+	function = oidp->oid_arg2;
+	method = acpi_thinkpad_sysctls[function].method;
+
+	/* ACPI_SERIAL_BEGIN(thinkpad); */
+	arg = acpi_thinkpad_sysctl_get(sc, method);
+	error = sysctl_handle_int(oidp, &arg, 0, req);
+
+	/* Sanity check */
+	if (error != 0 || req->newptr == NULL)
+		goto out;
+
+	/* Update */
+	error = acpi_thinkpad_sysctl_set(sc, method, arg);
+
+out:
+	/* ACPI_SERIAL_END(thinkpad); */
+	return (error);
+}
+
+static int
+acpi_thinkpad_sysctl_get(struct acpi_thinkpad_softc *sc, int method)
+{
+	ACPI_INTEGER	val_ec;
+	int 		val = 0, key;
+
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+	/* ACPI_SERIAL_ASSERT(thinkpad); */
+
+	switch (method) {
+	case ACPI_THINKPAD_METHOD_EVENTS:
+		acpi_GetInteger(sc->handle, THINKPAD_NAME_EVENTS_STATUS_GET,
+		    &val);
+		break;
+
+	case ACPI_THINKPAD_METHOD_EVENTMASK:
+		if (sc->events_mask_supported)
+			acpi_GetInteger(sc->handle,
+			    THINKPAD_NAME_EVENTS_MASK_GET, &val);
+		break;
+
+	case ACPI_THINKPAD_METHOD_HOTKEY:
+		/*
+		 * Construct the hotkey as a bitmask as illustrated below.
+		 * Note that whenever a key was pressed, the respecting bit
+		 * toggles and nothing else changes.
+		 * +--+--+-+-+-+-+-+-+-+-+-+-+
+		 * |11|10|9|8|7|6|5|4|3|2|1|0|
+		 * +--+--+-+-+-+-+-+-+-+-+-+-+
+		 *   |  | | | | | | | | | | |
+		 *   |  | | | | | | | | | | +- Home Button
+		 *   |  | | | | | | | | | +--- Search Button
+		 *   |  | | | | | | | | +----- Mail Button
+		 *   |  | | | | | | | +------- Thinkpad Button
+		 *   |  | | | | | | +--------- Zoom (Fn + Space)
+		 *   |  | | | | | +----------- WLAN Button
+		 *   |  | | | | +------------- Video Button
+		 *   |  | | | +--------------- Hibernate Button
+		 *   |  | | +----------------- Thinklight Button
+		 *   |  | +------------------- Screen expand (Fn + F8)
+		 *   |  +--------------------- Brightness
+		 *   +------------------------ Volume/Mute
+		 */
+		key = rtcin(THINKPAD_RTC_HOTKEY1);
+		val = (THINKPAD_RTC_MASK_HOME | THINKPAD_RTC_MASK_SEARCH |
+		    THINKPAD_RTC_MASK_MAIL | THINKPAD_RTC_MASK_WLAN) & key;
+		key = rtcin(THINKPAD_RTC_HOTKEY2);
+		val |= (THINKPAD_RTC_MASK_THINKPAD | THINKPAD_RTC_MASK_VIDEO |
+		    THINKPAD_RTC_MASK_HIBERNATE) & key;
+		val |= (THINKPAD_RTC_MASK_ZOOM & key) >> 1;
+		key = rtcin(THINKPAD_RTC_THINKLIGHT);
+		val |= (THINKPAD_RTC_MASK_THINKLIGHT & key) << 4;
+		key = rtcin(THINKPAD_RTC_SCREENEXPAND);
+		val |= (THINKPAD_RTC_MASK_THINKLIGHT & key) << 4;
+		key = rtcin(THINKPAD_RTC_BRIGHTNESS);
+		val |= (THINKPAD_RTC_MASK_BRIGHTNESS & key) << 5;
+		key = rtcin(THINKPAD_RTC_VOLUME);
+		val |= (THINKPAD_RTC_MASK_VOLUME & key) << 4;
+		break;
+
+	case ACPI_THINKPAD_METHOD_BRIGHTNESS:
+		ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_BRIGHTNESS, &val_ec, 1);
+		val = val_ec & THINKPAD_EC_MASK_BRI;
+		break;
+
+	case ACPI_THINKPAD_METHOD_VOLUME:
+		ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_VOLUME, &val_ec, 1);
+		val = val_ec & THINKPAD_EC_MASK_VOL;
+		break;
+
+	case ACPI_THINKPAD_METHOD_MUTE:
+		val = ((val_ec & THINKPAD_EC_MASK_MUTE) ==
+		    THINKPAD_EC_MASK_MUTE);
+		break;
+
+	case ACPI_THINKPAD_METHOD_THINKLIGHT:
+		if (sc->light_get_supported)
+			acpi_GetInteger(sc->ec_handle, THINKPAD_NAME_KEYLIGHT,
+			    &val);
+		else
+			val = sc->light_val;
+		break;
+
+	case ACPI_THINKPAD_METHOD_BLUETOOTH:
+		acpi_GetInteger(sc->handle, THINKPAD_NAME_WLAN_BT_GET, &val);
+		sc->wlan_bt_flags = val;
+		val = ((val & THINKPAD_NAME_MASK_BT) != 0);
+		break;
+
+	case ACPI_THINKPAD_METHOD_WLAN:
+		acpi_GetInteger(sc->handle, THINKPAD_NAME_WLAN_BT_GET, &val);
+		sc->wlan_bt_flags = val;
+		val = ((val & THINKPAD_NAME_MASK_WLAN) != 0);
+		break;
+
+	case ACPI_THINKPAD_METHOD_FANSPEED:
+		if (sc->fan_handle) {
+			if (ACPI_FAILURE(acpi_GetInteger(sc->fan_handle,
+			    NULL, &val)))
+				val = -1;
+		}
+		else {
+			ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_FANSPEED,
+			    &val_ec, 2);
+			val = val_ec;
+		}
+		break;
+
+	case ACPI_THINKPAD_METHOD_FANLEVEL:
+		/*
+		 * The THINKPAD_EC_FANSTATUS register works as follows:
+		 * Bit 0-5 indicate the level at which the fan operates. Only
+		 *       values between 0 and 7 have an effect. Everything
+		 *       above 7 is treated the same as level 7
+		 * Bit 6 overrides the fan speed limit if set to 1
+		 * Bit 7 indicates at which mode the fan operates:
+		 *       manual (0) or automatic (1)
+		 */
+		if (!sc->fan_handle) {
+			ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_FANSTATUS,
+			    &val_ec, 1);
+			val = val_ec & THINKPAD_EC_MASK_FANLEVEL;
+		}
+		break;
+
+	case ACPI_THINKPAD_METHOD_FANSTATUS:
+		if (!sc->fan_handle) {
+			ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_FANSTATUS,
+			    &val_ec, 1);
+			val = (val_ec & THINKPAD_EC_MASK_FANSTATUS) ==
+			    THINKPAD_EC_MASK_FANSTATUS;
+		}
+		else
+			val = -1;
+		break;
+	}
+
+	return (val);
+}
+
+static int
+acpi_thinkpad_sysctl_set(struct acpi_thinkpad_softc *sc, int method, int arg)
+{
+	int			val, step, i;
+	ACPI_INTEGER		val_ec;
+	ACPI_OBJECT		Arg;
+	ACPI_OBJECT_LIST	Args;
+	ACPI_STATUS		status;
+
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+	/* ACPI_SERIAL_ASSERT(thinkpad); */
+
+	switch (method) {
+	case ACPI_THINKPAD_METHOD_EVENTS:
+		if (arg < 0 || arg > 1)
+			return (EINVAL);
+
+		status = acpi_SetInteger(sc->handle,
+		    THINKPAD_NAME_EVENTS_STATUS_SET, arg);
+		if (ACPI_FAILURE(status))
+			return (status);
+		if (sc->events_mask_supported)
+			return acpi_thinkpad_eventmask_set(sc,
+			    sc->events_availmask);
+		break;
+
+	case ACPI_THINKPAD_METHOD_EVENTMASK:
+		if (sc->events_mask_supported)
+			return acpi_thinkpad_eventmask_set(sc, arg);
+		break;
+
+	case ACPI_THINKPAD_METHOD_BRIGHTNESS:
+		if (arg < 0 || arg > 7)
+			return (EINVAL);
+
+		if (sc->cmos_handle) {
+			/* Read the current brightness */
+			status = ACPI_EC_READ(sc->ec_dev,
+			    THINKPAD_EC_BRIGHTNESS, &val_ec, 1);
+			if (ACPI_FAILURE(status))
+				return (status);
+			val = val_ec & THINKPAD_EC_MASK_BRI;
+
+			Args.Count = 1;
+			Args.Pointer = &Arg;
+			Arg.Type = ACPI_TYPE_INTEGER;
+			Arg.Integer.Value = (arg > val) ?
+			    THINKPAD_CMOS_BRIGHTNESS_UP :
+			    THINKPAD_CMOS_BRIGHTNESS_DOWN;
+
+			step = (arg > val) ? 1 : -1;
+			for (i = val; i != arg; i += step) {
+				status = AcpiEvaluateObject(sc->cmos_handle,
+				    NULL, &Args, NULL);
+				if (ACPI_FAILURE(status))
+					break;
+			}
+		}
+		return ACPI_EC_WRITE(sc->ec_dev, THINKPAD_EC_BRIGHTNESS,
+		    arg, 1);
+		break;
+
+	case ACPI_THINKPAD_METHOD_VOLUME:
+		if (arg < 0 || arg > 14)
+			return (EINVAL);
+
+		status = ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_VOLUME,
+		    &val_ec, 1);
+		if (ACPI_FAILURE(status))
+			return (status);
+
+		if (sc->cmos_handle) {
+			val = val_ec & THINKPAD_EC_MASK_VOL;
+
+			Args.Count = 1;
+			Args.Pointer = &Arg;
+			Arg.Type = ACPI_TYPE_INTEGER;
+			Arg.Integer.Value = (arg > val) ?
+			    THINKPAD_CMOS_VOLUME_UP : THINKPAD_CMOS_VOLUME_DOWN;
+
+			step = (arg > val) ? 1 : -1;
+			for (i = val; i != arg; i += step) {
+				status = AcpiEvaluateObject(sc->cmos_handle,
+				    NULL, &Args, NULL);
+				if (ACPI_FAILURE(status))
+					break;
+			}
+		}
+		return ACPI_EC_WRITE(sc->ec_dev, THINKPAD_EC_VOLUME, arg +
+		    (val_ec & (~THINKPAD_EC_MASK_VOL)), 1);
+		break;
+
+	case ACPI_THINKPAD_METHOD_MUTE:
+		if (arg < 0 || arg > 1)
+			return (EINVAL);
+
+		status = ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_VOLUME,
+		    &val_ec, 1);
+		if (ACPI_FAILURE(status))
+			return (status);
+
+		if (sc->cmos_handle) {
+			val = val_ec & THINKPAD_EC_MASK_VOL;
+
+			Args.Count = 1;
+			Args.Pointer = &Arg;
+			Arg.Type = ACPI_TYPE_INTEGER;
+			Arg.Integer.Value = THINKPAD_CMOS_VOLUME_MUTE;
+
+			status = AcpiEvaluateObject(sc->cmos_handle, NULL,
+			    &Args, NULL);
+			if (ACPI_FAILURE(status))
+				break;
+		}
+		return ACPI_EC_WRITE(sc->ec_dev, THINKPAD_EC_VOLUME, (arg==1) ?
+		   val_ec | THINKPAD_EC_MASK_MUTE :
+		   val_ec & (~THINKPAD_EC_MASK_MUTE), 1);
+		break;
+
+	case ACPI_THINKPAD_METHOD_THINKLIGHT:
+		if (arg < 0 || arg > 1)
+			return (EINVAL);
+
+		if (sc->light_set_supported) {
+			Args.Count = 1;
+			Args.Pointer = &Arg;
+			Arg.Type = ACPI_TYPE_INTEGER;
+			Arg.Integer.Value = arg ?
+			    sc->light_cmd_on : sc->light_cmd_off;
+
+			status = AcpiEvaluateObject(sc->light_handle, NULL,
+			    &Args, NULL);
+			if (ACPI_SUCCESS(status))
+				sc->light_val = arg;
+			return (status);
+		}
+		break;
+
+	case ACPI_THINKPAD_METHOD_BLUETOOTH:
+		if (arg < 0 || arg > 1)
+			return (EINVAL);
+
+		val = (arg == 1) ? sc->wlan_bt_flags |
+		    THINKPAD_NAME_MASK_BT :
+		    sc->wlan_bt_flags & (~THINKPAD_NAME_MASK_BT);
+		return acpi_SetInteger(sc->handle, THINKPAD_NAME_WLAN_BT_SET,
+		    val);
+		break;
+
+	case ACPI_THINKPAD_METHOD_FANLEVEL:
+		if (arg < 0 || arg > 7)
+			return (EINVAL);
+
+		if (!sc->fan_handle) {
+			/* Read the current fanstatus */
+			ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_FANSTATUS,
+			    &val_ec, 1);
+			val = val_ec & (~THINKPAD_EC_MASK_FANLEVEL);
+
+			return ACPI_EC_WRITE(sc->ec_dev, THINKPAD_EC_FANSTATUS,
+			    val | arg, 1);
+		}
+		break;
+
+	case ACPI_THINKPAD_METHOD_FANSTATUS:
+		if (arg < 0 || arg > 1)
+			return (EINVAL);
+
+		if (!sc->fan_handle) {
+			/* Read the current fanstatus */
+			ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_FANSTATUS,
+			    &val_ec, 1);
+
+			return ACPI_EC_WRITE(sc->ec_dev, THINKPAD_EC_FANSTATUS,
+			    (arg == 1) ? (val_ec | THINKPAD_EC_MASK_FANSTATUS) :
+			    (val_ec & (~THINKPAD_EC_MASK_FANSTATUS)), 1);
+		}
+		break;
+	}
+
+	return (0);
+}
+
+static int
+acpi_thinkpad_sysctl_init(struct acpi_thinkpad_softc *sc, int method)
+{
+	int 			dummy;
+	ACPI_OBJECT_TYPE 	cmos_t;
+	ACPI_HANDLE		ledb_handle;
+
+	switch (method) {
+	case ACPI_THINKPAD_METHOD_EVENTS:
+		/* Events are disabled by default */
+		return (TRUE);
+
+	case ACPI_THINKPAD_METHOD_EVENTMASK:
+		return (sc->events_mask_supported);
+
+	case ACPI_THINKPAD_METHOD_HOTKEY:
+	case ACPI_THINKPAD_METHOD_BRIGHTNESS:
+	case ACPI_THINKPAD_METHOD_VOLUME:
+	case ACPI_THINKPAD_METHOD_MUTE:
+		/* EC is required here, which was already checked before */
+		return (TRUE);
+
+	case ACPI_THINKPAD_METHOD_THINKLIGHT:
+		sc->cmos_handle = NULL;
+		sc->light_get_supported = ACPI_SUCCESS(acpi_GetInteger(
+		    sc->ec_handle, THINKPAD_NAME_KEYLIGHT, &sc->light_val));
+
+		if ((ACPI_SUCCESS(AcpiGetHandle(sc->handle, "\\UCMS",
+		    &sc->light_handle)) ||
+		    ACPI_SUCCESS(AcpiGetHandle(sc->handle, "\\CMOS",
+		    &sc->light_handle)) ||
+		    ACPI_SUCCESS(AcpiGetHandle(sc->handle, "\\CMS",
+		    &sc->light_handle))) &&
+		    ACPI_SUCCESS(AcpiGetType(sc->light_handle, &cmos_t)) &&
+		    cmos_t == ACPI_TYPE_METHOD) {
+			sc->light_cmd_on = 0x0c;
+			sc->light_cmd_off = 0x0d;
+			sc->cmos_handle = sc->light_handle;
+		}
+		else if (ACPI_SUCCESS(AcpiGetHandle(sc->handle, "\\LGHT",
+		    &sc->light_handle))) {
+			sc->light_cmd_on = 1;
+			sc->light_cmd_off = 0;
+		}
+		else
+			sc->light_handle = NULL;
+
+		sc->light_set_supported = (sc->light_handle &&
+		    ACPI_FAILURE(AcpiGetHandle(sc->ec_handle, "LEDB",
+		    &ledb_handle)));
+
+		if (sc->light_get_supported)
+			return (TRUE);
+
+		if (sc->light_set_supported) {
+			sc->light_val = 0;
+			return (TRUE);
+		}
+
+		return (FALSE);
+
+	case ACPI_THINKPAD_METHOD_BLUETOOTH:
+	case ACPI_THINKPAD_METHOD_WLAN:
+		if (ACPI_SUCCESS(acpi_GetInteger(sc->handle,
+		    THINKPAD_NAME_WLAN_BT_GET, &dummy)))
+			return (TRUE);
+		return (FALSE);
+
+	case ACPI_THINKPAD_METHOD_FANSPEED:
+		/* 
+		 * Some models report the fan speed in levels from 0-7
+		 * Newer models report it contiguously
+		 */
+		sc->fan_levels = (ACPI_SUCCESS(AcpiGetHandle(sc->handle, "GFAN",
+		    &sc->fan_handle)) ||
+		    ACPI_SUCCESS(AcpiGetHandle(sc->handle, "\\FSPD",
+		    &sc->fan_handle)));
+		return (TRUE);
+
+	case ACPI_THINKPAD_METHOD_FANLEVEL:
+	case ACPI_THINKPAD_METHOD_FANSTATUS:
+		/* 
+		 * Fan status is only supported on those models,
+		 * which report fan RPM contiguously, not in levels
+		 */
+		if (sc->fan_levels)
+			return (FALSE);
+		return (TRUE);
+
+	case ACPI_THINKPAD_METHOD_THERMAL:
+		if (ACPI_SUCCESS(acpi_GetInteger(sc->ec_handle,
+		    THINKPAD_NAME_THERMAL_GET, &dummy))) {
+			sc->thermal_updt_supported =
+			    ACPI_SUCCESS(acpi_GetInteger(sc->ec_handle,
+			    THINKPAD_NAME_THERMAL_UPDT, &dummy));
+			return (TRUE);
+		}
+		return (FALSE);
+	}
+	return (FALSE);
+}
+
+static void
+acpi_thinkpad_notify(ACPI_HANDLE h, UINT32 notify, void *context)
+{
+	int		event, arg, type;
+	device_t	dev = context;
+	struct acpi_thinkpad_softc *sc = device_get_softc(dev);
+
+	ACPI_FUNCTION_TRACE_U32((char *)(uintptr_t)__func__, notify);
+
+	if (notify != 0x80)
+		device_printf(dev, "Unknown notify\n");
+
+	for (;;) {
+		acpi_GetInteger(acpi_get_handle(dev), THINKPAD_NAME_EVENTS_GET,
+		    &event);
+
+		if (event == 0)
+			break;
+
+		type = (event >> 12) & 0xf;
+		arg = event & 0xfff;
+		switch (type) {
+		case 1:
+			if (!(sc->events_availmask & (1 << (arg - 1)))) {
+				device_printf(dev, "Unknown key %d\n", arg);
+				break;
+			}
+
+			/* Notify devd(8) */
+			device_printf(dev, "THINKPAD event: %u\n",
+			    (arg & 0xff));
+			acpi_UserNotify("THINKPAD", h, (arg & 0xff));
+			break;
+		default:
+			break;
+		}
+	}
+}
+
+static void
+acpi_thinkpad_refresh(void *arg)
+{
+	struct acpi_thinkpad_softc *sc = (struct acpi_thinkpad_softc *)arg;
+	char temp_cmd[] = "TMP0";
+	int data, i;
+	ACPI_INTEGER speed;
+
+	for (i = 0; i < 8; i++) {
+		temp_cmd[3] = '0' + i;
+		
+                /*
+                 * The TMPx methods seem to return +/- 128 or 0
+                 * when the respecting sensor is not available
+                 */
+		sc->sensors[i].flags &= ~SENSOR_FINVALID;
+                if (ACPI_FAILURE(acpi_GetInteger(sc->ec_handle, temp_cmd,
+                    &data)) || ABS(data) == 128 || data == 0) {
+			sc->sensors[i].flags |= SENSOR_FINVALID;
+                        data = 0;
+		}
+                else if (sc->thermal_updt_supported) {
+                        /* XXX: Temperature is reported in tenth of Kelvin */
+                        data = (data - 2732 + 5) / 10;
+		}
+		sc->sensors[i].value = data * 1000000 + 273150000;
+        }
+	
+	sc->sensors[8].flags &= ~SENSOR_FINVALID;
+	if (sc->fan_handle) {
+		if (ACPI_FAILURE(acpi_GetInteger(sc->fan_handle,
+		    NULL, &data)))
+			sc->sensors[8].flags |= SENSOR_FINVALID;
+                        data = -1;
+        }
+        else {
+                ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_FANSPEED, &speed, 2);
+                data = speed;
+        }
+
+	sc->sensors[8].value = data;
+}
diff --git a/sys/platform/pc32/conf/files b/sys/platform/pc32/conf/files
--- a/sys/platform/pc32/conf/files
+++ b/sys/platform/pc32/conf/files
@@ -72,6 +72,7 @@ dev/serial/dgb/dgm.c			optional	dgm
 ${OSACPI_MD_DIR}/acpi_machdep.c		optional        acpi
 ${OSACPI_MD_DIR}/acpi_wakeup.c		optional        acpi
 ${OSACPI_MD_DIR}/acpi_toshiba.c		optional        acpi_toshiba acpi
+${ACPICA_DIR}/acpi_thinkpad/acpi_thinkpad.c optional	acpi_thinkpad acpi
 acpi.h					optional	acpi		\
 	dependency	"$S/${ACPICA_DIR}/include/acpi.h"		\
 	compile-with	"cp $S/${ACPICA_DIR}/include/acpi.h ${.OBJDIR}/"	\



From hasso at estpak.ee  Thu Mar 20 03:49:13 2008
From: hasso at estpak.ee (Hasso Tepper)
Date: Thu, 20 Mar 2008 03:49:13 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Some questions regarding ACPI
In-Reply-To: <200803191322.46366.hasso@estpak.ee>
Message-ID: <200803201237.28823.hasso@estpak.ee>

Hasso Tepper wrote:
> There is also one fatal issue -laptop locks up hardly (no panic) while 
> unloading module. Any idea regarding this is welcome.

Nevermind, solved.


-- 
Hasso




From dillon at apollo.backplane.com  Fri Mar 21 19:24:01 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Fri, 21 Mar 2008 19:24:01 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: panic: assertion: hammer_btree_cmp(cursor->left_bound,	&cursor->node->ondisk->elms[0].leaf.base) <= 0 in btree_split_leaf
In-Reply-To: <200802232204.m1NM4cxd046264@apollo.backplane.com>
Message-ID: <200803220212.m2M2CiAY014435@apollo.backplane.com>

:While trying to find a procedure to reliably reproduce the panic
:I reported last time, I caught a different panic (uploaded at
: ~y0netan1/crash/9/ on my leaf account).  I wrote the following shell
:script (make sure to edit variables DISKS and MOUNTPT before using this
:script or it may trash your system):

    Ok, I believe I have fixed the left_bound assertion.  I also believe
    I have fixed the node ref count assertion on umount.

    There is currently one unfixed assertion related to the I/O
    path... sometimes the bp is being improperly disassociated from the
    related HAMMER structure.

    The full-filesystem case is still not being handled so don't test that :-)

					    -Matt





From c.turner at 199technologies.org  Sun Mar 23 09:48:29 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Sun, 23 Mar 2008 09:48:29 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
Message-ID: <47E6870C.4080709@199technologies.org>

I'm finally getting around to doing 1.12 upgrades, and have setup a 
separate machine to do my bulk package builds / upgrades etc,
so as not to disrupt my 'dev server' while things are being
built / tested

However, this seems kind of wasteful - the only purpose of this machine
is to build packages against a specific release..
And since building packages for a particular release generally requires 
only the userland, appropriate headers and correct 'uname' output - so:

it seems like if spoofing uname is configured inside a jail,
the next (or previous..) release can be installed into a jail and
used for building / testing packages without the overhead of a VM or 
maintaining a separate physical host

I did a quick scan of the tree to see what this would take, and, high 
level, it seems like only the following changes would need to be made:

- update struct jail to add a 'osrelease' string
  (implies bumping 'jail api' to 2?)
- update jail(8) to actually pass this information along
- update sys_uname to test ucred for jailed processes, and
  use the struct jail osrelease if appropriate
- similarly update sysctl kern.osrelease to support jail spoofing
  (if possible - didn't get this far in the research yet)
  could be less of a problem for builds, as I think most things use
 uname(1) ... but good to keep the environment consistent I suppose..
I'm still a bit confused as to how 'osrelease' is defined - everything
I'm finding is showing up as extern char[] .. perhaps this is something 
in the build I'm not familiar with?

also,

is the so-called 'stupid hackery' in sys_uname needed still?

Before I start any coding, does this:

- sound like something useful
- sound like the right approach
Thinking this could have wider useful implications e.g. for pkgbox
& so on -  for example setting up automated bulks w/various combinations 
of pkgsrc and releases, etc.

Cheers,

- Chris





From corecode at fs.ei.tum.de  Sun Mar 23 10:06:38 2008
From: corecode at fs.ei.tum.de (Simon 'corecode' Schubert)
Date: Sun, 23 Mar 2008 10:06:38 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <47E68C74.3080808@fs.ei.tum.de>

Chris Turner wrote:
I did a quick scan of the tree to see what this would take, and, high 
level, it seems like only the following changes would need to be made:
brave investigation.  but you could also simply set UNAME_r :)

sweatshorts % uname -r
1.13.0-DEVELOPMENT
sweatshorts % UNAME_r=1.12-RELEASE uname -r
1.12-RELEASE
I think that's good enough :D

cheers
  simon
--
Serve - BSD     +++  RENT this banner advert  +++    ASCII Ribbon   /"\
Work - Mac      +++  space for low ????????? NOW!1  +++      Campaign     \ /
Party Enjoy Relax   |   http://dragonflybsd.org      Against  HTML   \
Dude 2c 2 the max   !   http://golden-apple.biz       Mail + News   / \




From c.turner at 199technologies.org  Sun Mar 23 10:50:13 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Sun, 23 Mar 2008 10:50:13 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <47E69656.8080605@199technologies.org>

Simon 'corecode' Schubert wrote:
brave investigation.  but you could also simply set UNAME_r :)
Doh! Thanks for the tip!

they should change the phrase from RTFM to 'Carefully RTFM' :)

well.. scratch that change then. 1 less patch to write.

- Chris





From c.turner at 199technologies.org  Sun Mar 23 11:15:52 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Sun, 23 Mar 2008 11:15:52 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <47E69C7C.8010109@199technologies.org>

Chris Turner wrote:
Simon 'corecode' Schubert wrote:
brave investigation.  but you could also simply set UNAME_r :)

for the record - if anyone's interested - adding a line e.g.:

ALL_ENV+= UNAME_r=1.12-RELEASE

to mk.conf looks like it -might- work ..

(unless wants to chime in & verify)





From joerg at britannica.bec.de  Sun Mar 23 11:46:53 2008
From: joerg at britannica.bec.de (Joerg Sonnenberger)
Date: Sun, 23 Mar 2008 11:46:53 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <20080323181428.GA2099@britannica.bec.de>

On Sun, Mar 23, 2008 at 01:41:42PM -0400, Chris Turner wrote:
> they should change the phrase from RTFM to 'Carefully RTFM' :)

RTFMAI -- Read The Fine Manual Again, Idiot.

Joerg




From dillon at apollo.backplane.com  Sun Mar 23 20:05:36 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Sun, 23 Mar 2008 20:05:36 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
Message-ID: <200803240257.m2O2voNH038355@apollo.backplane.com>

    Here's an update on the HAMMER work!

    Current status:

    * Passes all standard filesystem stress tests and buildworld will
      run with a HAMMER /usr/obj.  Large histories are able to accumulate
      without effecting performance.

    * Pruning and reblocking code is in and partially tested, but now needs
      more stringent testing.

    * Full historical access appears to be working but needs testing.
      Note that a sync is still needed to flush dirty cached data prior
      to acquiring a timestamp for the 'snapshot' to be set in stone.
      (dirty data cached in-memory has no historical tags and must be
      committed to physical disk before it can be accessed historically).


    Current bugs:

    * There is one known bug in the standard operations code paths
      that results in an assertion in HAMMER's I/O subsystem.

    * There are probably bugs in the reblocking and/or pruning code.  More
      likely in the reblocking code.


    There are two big-ticket and several little-ticket items left.  HAMMER
    will officially go Alpha when the big-ticket items are done, and beta
    when we get a few of the little-ticket items done.

    Big ticket items left:

    * UNDO (crash recovery) code.  Currently it writes out undo records but
      they are not yet sequenced, buffer writes are not yet ordered, and
      there is no mount-time recovery code yet.

      This is the last item needed before HAMMER can go operational.

    * Filesystem full handling.  Currently no space is reserved for dirty
      cached data so it is possible to create/write files and for HAMMER
      to not have sufficient space left on-disk to flush it.


    Little ticket items:

    * Automated reblocking (currently these functions are manually
      initialized via the hammer utility).

    * I/O clustering and preliminary BMAP op when writing out large files.

    * CRC checking (CRC fields are reserved but not entirely generated yet
      and not yet checked at all).

    * Disaster Recovery filesystem scan.

    * Boot support.

    I expect all of these items and more to be handled by the 2.0 release
    in July.

			    Additional HAMMER capabilities
				(no timeline yet)

    * Adding, removing, and resizing a HAMMER filesystem's backing store.

			Ultimate Goals and working towards them
				(no timeline yet)

    Our ultimate goal with HAMMER and DragonFly in general is to support
    fully cache coherent replication in a multi-machine environment.  This
    involves several steps and networking protocols.

    * Replication of synchronization streams based on the UNDO log.  If
      resynchronizing to a target which is too old a B-Tree scan will
      likely be required.

    * Cache coherency protocols for machine-machine coherency for both
      replicated and remote-HAMMER access.

    I have no time frame for these items yet.  It will depend on how quickly
    HAMMER moves to Alpha and Beta status.  I will say, however, now
    that HAMMER's on-disk format has solidified, that I have a very precise
    understanding of the protocols that will be needed to accomplish fully
    cache coherent remote access for both replicated and non-replicated
    (remote mount style) access.

    And, as you know, fully coherent filesystem access across machines is
    going to be the basis for DragonFly's clustering across said machines.

    In summary, things are progressing very well.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From justin at shiningsilence.com  Sun Mar 23 20:10:13 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Sun, 23 Mar 2008 20:10:13 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <53758.192.168.0.252.1206327873.squirrel@www.shiningsilence.com>

On Sun, March 23, 2008 12:36 pm, Chris Turner wrote:

> it seems like if spoofing uname is configured inside a jail,
> the next (or previous..) release can be installed into a jail and
> used for building / testing packages without the overhead of a VM or
> maintaining a separate physical host

If you don't need a jail to spoof uname, as others posted, you can
installworld into a chroot and build everything you want there using
Joerg's spiffy pbulk.  That's what I'm doing on pkgbox now; I can hand you
my somewhat terse notes if you want.  It would be relatively easy to set
up the configuration you're talking about.





From sepherosa at gmail.com  Sun Mar 23 20:18:20 2008
From: sepherosa at gmail.com (Sepherosa Ziehau)
Date: Sun, 23 Mar 2008 20:18:20 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <ea7b9c170803232012n2f27f893tf1d756d7c9770419@mail.gmail.com>

On Mon, Mar 24, 2008 at 2:14 AM, Joerg Sonnenberger
<joerg at britannica.bec.de> wrote:
> On Sun, Mar 23, 2008 at 01:41:42PM -0400, Chris Turner wrote:
>  > they should change the phrase from RTFM to 'Carefully RTFM' :)
>
>  RTFMAI -- Read The Fine Manual Again, Idiot.

http://leaf.dragonflybsd.org/~sephe/rtfm.jpg

:D

>
>  Joerg
>



-- 
Live Free or Die




From justin at shiningsilence.com  Sun Mar 23 20:38:30 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Sun, 23 Mar 2008 20:38:30 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: GSoC 2008 - mentors signup
Message-ID: <53885.192.168.0.252.1206329503.squirrel@www.shiningsilence.com>

If you are planning to be a mentor for a Summer of Code project, please
sign up here for the mentors mailing list:

http://groups.google.com/group/google-summer-of-code-mentors-list

If you've already signed up, your subscription should be set up tomorrow.





From justin at shiningsilence.com  Sun Mar 23 21:12:01 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Sun, 23 Mar 2008 21:12:01 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: GSoC 2008 - mentors signup
In-Reply-To: <53885.192.168.0.252.1206329503.squirrel@www.shiningsilence.com>
Message-ID: <54025.192.168.0.252.1206331572.squirrel@www.shiningsilence.com>

Also!

If you are a potential mentor and you have not done so yet:

http://code.google.com/soc/mentor_step1.html

Get yourself registered as a mentor for the Summer of Code project.  Once
you are in there, check off DragonFly in the "My Profile" section.

You will need a Google Account if you don't have one:

http://www.google.com/accounts

This will add you to the list of mentors in the Google Summer of Code web
application, so you can review/be attached to projects.

A guide is available if you want more information:

http://groups.google.com/group/google-summer-of-code-announce/web/guide-to-the-gsoc-web-app-for-mentors-and-organization-administrators






From c.turner at 199technologies.org  Mon Mar 24 04:29:28 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Mon, 24 Mar 2008 04:29:28 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <47E78ECE.4070307@199technologies.org>

Justin C. Sherrill wrote:
If you don't need a jail to spoof uname, as others posted, you can
installworld into a chroot and build everything you want there using
Joerg's spiffy pbulk.  That's what I'm doing on pkgbox now; I can hand you
my somewhat terse notes if you want.  It would be relatively easy to set
up the configuration you're talking about.
cheers - I guess I thought incorrectly that something 'special' was 
needed to get the uname to change .. have been using the legacy bulks in 
chroots / jails (for 'same os' builds) as I haven't quite migrated to 
pbulk yet ..

thanks for the help offer - I'll ask if I run into trouble.




From dillon at apollo.backplane.com  Mon Mar 24 08:28:49 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Mon, 24 Mar 2008 08:28:49 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <200803241500.m2OF0CG8043760@apollo.backplane.com>


:http://leaf.dragonflybsd.org/~sephe/rtfm.jpg
:
::D

    Ho!

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From elekktretterr at exemail.com.au  Mon Mar 24 09:10:15 2008
From: elekktretterr at exemail.com.au (Petr Janda)
Date: Mon, 24 Mar 2008 09:10:15 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
In-Reply-To: <200803240257.m2O2voNH038355@apollo.backplane.com>
Message-ID: <200803250138.49775.elekktretterr@exemail.com.au>


>
>     And, as you know, fully coherent filesystem access across machines is
>     going to be the basis for DragonFly's clustering across said machines.
>
>     In summary, things are progressing very well.
>


Hi Matt,
That's good to know things are going so well. Got a question. If memory serves 
me right, initially there was also going to be a thing called ANVIL, I can't 
remember what it was supposed to do and whether its still in your design. 
Could you elaborate a little?

Thanks,
Petr




From dillon at apollo.backplane.com  Mon Mar 24 14:12:11 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Mon, 24 Mar 2008 14:12:11 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
In-Reply-To: <200803240257.m2O2voNH038355@apollo.backplane.com>
Message-ID: <200803242100.m2OL0nWV046868@apollo.backplane.com>


:Hi Matt,
:That's good to know things are going so well. Got a question. If memory serves 
:me right, initially there was also going to be a thing called ANVIL, I can't 
:remember what it was supposed to do and whether its still in your design. 
:Could you elaborate a little?
:
:Thanks,
:Petr

    It's not really in the HAMMER design any more, primarily because HAMMER's
    volume model seems to work fine as-is.  Ultimately something like ANVIL
    (a block storage manager) would prove beneficial to the project but it
    would be treated as a separate project.  HAMMER's redundancy model is
    going to be baesd around replication and clustering.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From tgen at netphreax.net  Mon Mar 24 18:31:37 2008
From: tgen at netphreax.net (Thomas E. Spanjaard)
Date: Mon, 24 Mar 2008 18:31:37 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
In-Reply-To: <200803240257.m2O2voNH038355@apollo.backplane.com>
Message-ID: <47E85337.2070407@netphreax.net>

Matthew Dillon wrote:
    * Full historical access appears to be working but needs testing.
      Note that a sync is still needed to flush dirty cached data prior
      to acquiring a timestamp for the 'snapshot' to be set in stone.
      (dirty data cached in-memory has no historical tags and must be
      committed to physical disk before it can be accessed historically).
Wouldn't making timestamp queries (at least from userland) enforce a 
sync on the volume in question be useful here?
--
        Thomas E. Spanjaard
        tgen at netphreax.net
Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00005.pgp
Type: application/octet-stream
Size: 186 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080324/3077333f/attachment-0017.obj>

From dillon at apollo.backplane.com  Mon Mar 24 20:10:12 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Mon, 24 Mar 2008 20:10:12 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
In-Reply-To: <200803240257.m2O2voNH038355@apollo.backplane.com>
Message-ID: <200803250302.m2P32qLP050160@apollo.backplane.com>


:Wouldn't making timestamp queries (at least from userland) enforce a 
:sync on the volume in question be useful here?
:-- 
:         Thomas E. Spanjaard
:         tgen at netphreax.net

    Making the 'hammer now' command do a sync() is a good idea.  I will
    make that change right now so it doesn't get lost.

    Here's a general overview of the issues involved with having historical
    access to the filesystem:

				----------------

    Recording the timestamps in the in-memory cache, for a finer-grained
    snapshot capability, is doable but has its own issues.  Here's an
    illustration:

    open()  create file
    write() append 4K	(file size now 4K)
    write() append 4K	(file size now 8K)
    write() append 4K	(file size now 12K)
    write() append 4K	(file size now 16K)

    Now NONE of this has gone to disk yet, it's entirely in the in-memory
    cache.  The inode is in the in-memory cache.  The data is stored in
    the buffer cache.  Even the directory entry for the file that we
    just created is still in the in-memory cache (HAMMER caches the raw
    records it intends to commit later on).

    If I wanted to be able to acquire a timestamp between each write and
    'see' a snapshot of the file as of any point in the above sequence,
    then every write would also have to allocate a copy of the inode
    (because it changes size on each write).

    The data has the same problem though with a slightly different example.
    Lets say each write() was a seek-write, overwriting the previous data.
    Now with every write() I would have to allocate a copy of the data
    being overwritten.  This is complicated by the fact that the buffer
    cache has no clue about 'historical' accesses, so I would not be able
    to use the buffer cache to cache the data.

    There's also another problem and that is with the efficiency of the
    topology on-disk.  Even if I maintained all the copies of the inode
    and all the copies of the data in-memory, I would still have to sync
    all those copies to disk in order for things to remain historically
    coherent (whether it be in-cache or on-disk).  This would result in
    hundreds or even thousands of copies of the inode on-disk, not to
    mention potentially many copies of the data.

    I just don't want to do that right now, at least not as a default.  A
    lot of performance would be lost.  Hence a sync() is needed if
    you want to create a demark which you can accurately snapshot.

				-------------

    Here's a quick synopsis of how the cache would operate in a clustered
    filesystem:

    In order to properly integrate with in-memory caches, a wider cache
    coherency infrastructure is needed between machines such that
    modifications made on one machine proactively invalidate those
    protions of the cache(s) on other machines.  At the same time, any
    'dirty' cache data, for example when a file is created or written to,
    must lock the cache space in question on all other machines.
    The cache space in this case is not just the file data, but also the
    related namespaces (for creations, deletions, and renames).  Attempts
    to access locked spaces from other machines in the cluster would have
    to force a flush to the filesystem backing store and lower the cache
    states for the effected information on the original machine from dirty
    to shared-read-only.

    It will be easiest to integrate the cache coherency information into
    the buffer cache and namecache themselves.  Once a machine has dirtied
    an in-memory cache element... for example part of the namespace when
    creating a file or chunks of data written within a file, that machine
    must have a free hand to make further modifications to the cache spaces
    involved without further interaction with other machines.

				-------------

    Now, if you think of those two major elements you can see that they
    actually fit together quite well.  If I were to attempt to maintain
    transactional coherency on a per-system-call basis then the cache
    granularity between machines would have to be much, much smaller then
    our current in-memory caching elements provide.  That would become
    a really nasty coding problem.  So I don't even want to begin to
    complate transactional coherency at a finer-grain then sync() or
    fsync() until long after we actually have clustering working.

						-Matt





From elekktretterr at exemail.com.au  Mon Mar 24 21:56:58 2008
From: elekktretterr at exemail.com.au (Petr Janda)
Date: Mon, 24 Mar 2008 21:56:58 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
In-Reply-To: <200803240257.m2O2voNH038355@apollo.backplane.com>
Message-ID: <200803251516.16407.elekktretterr@exemail.com.au>

So is it needed to run hammer now in order to "create" a snapshot? What would 
I do in situation like this: got a hammer filesystem and couple of the files 
change on day to day basis. Then a week later I needed to access one of the 
files, in exactly the state they were 7 days ago.

Cheers,
Petr




From dillon at apollo.backplane.com  Mon Mar 24 22:34:15 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Mon, 24 Mar 2008 22:34:15 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
In-Reply-To: <200803240257.m2O2voNH038355@apollo.backplane.com>
Message-ID: <200803250526.m2P5QZ5X051081@apollo.backplane.com>


:So is it needed to run hammer now in order to "create" a snapshot? What would 
:I do in situation like this: got a hammer filesystem and couple of the files 
:change on day to day basis. Then a week later I needed to access one of the 
:files, in exactly the state they were 7 days ago.
:
:Cheers,
:Petr

    No, you do not have to run 'hammer now' to create a snapshot.  The
    kernel syncs all filesystems every 30 seconds, so if you do nothing
    at all you get a snapshot granularity of 30 seconds.

    Where you would use 'hammer now' is if you wanted the most current
    snapshot possible for the purpose of, say, backing up your filesystem
    to another machine.  You might do something like this:

	set timestamp = `hammer now`
	cpdup /mountpoint/@@$timestamp targethost:/somepath

    But if you didn't care about that you could just go back far enough
    that you get a stable historical view... e.g. go back 1 minute and you
    would have a stable view into your filesystem.

	set timestamp = `hammer stamp 60s`		<------ doesn't sync
	cpdup /mountpoint/@@$timestamp targethost:/somepath


    Ultimately the idea of managing filesystems this way is to still do
    regular backups from your production machine to your backup machine
    (ultimately by way of replication), with both running HAMMER, but only
    retain a limited amount of history on the production box.  You might
    desire to retain only one week's worth of history on the production box,
    retain one month's history on your local backup box, and retain a very
    granular one year's worth of history on your remote backup box.

    Come to think of it, I should add some more directives to the
    'hammer prune' command to make that easier to specify.

    Until I implement a live replication 'feed' the minimum granularity on
    the backup box will be how often you do your backups (e.g. once a day),
    and you can prune it into more granular forms from that starting point.
    Once we have a live replication feed the backup box will have the same
    30-second granularity that the production machine has.

    A major bullet point for this style of management is that the retention
    policy on the various boxes can be different even though they are
    all slaved off the same production filesystem.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From justin at shiningsilence.com  Tue Mar 25 05:58:49 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Tue, 25 Mar 2008 05:58:49 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: SoC - student signups
Message-ID: <58180.65.106.147.226.1206449676.squirrel@www.shiningsilence.com>

Here's a quick link roundup:

Are you a student?  Put in your application for a Google Summer of Code here:

http://code.google.com/soc/2008/student_signup.html

Student guide:
http://groups.google.com/group/google-summer-of-code-announce/web/guide-to-the-gsoc-web-app-for-student-applicants

Are you a mentor?  (That means hasso, hsu, sephe, matthias, TGEN, and
corecode right now)

Student proposals will show up on the mentor page, linked below.  You will
get to rate them, and take the one(s) that you want to mentor.

Mentor page:
http://code.google.com/soc/2008/mentor_home.html
Mentor guide:
http://groups.google.com/group/google-summer-of-code-announce/web/guide-to-the-gsoc-web-app-for-mentors-and-organization-administrators

If you are a mentor and are communicating with potential students, send
them the URLs above for student signup and the student guide; work with
them if they ask for advice on what to say in the application.  They can
resubmit up to 20 times if they want to correct it.

Deadline is March 31st.






From noah.yan at gmail.com  Thu Mar 27 20:17:48 2008
From: noah.yan at gmail.com (Yonghong Yan)
Date: Thu, 27 Mar 2008 20:17:48 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: About DFBSD.64
In-Reply-To: <47EB0B5B.5020802@gmail.com>
Message-ID: <59521b110803272015y1cc8cc39uc93f154ed36e0505@mail.gmail.com>

thanks for your interest.

I owe to everybody for any update or work in the past four months. so
many things happen in my work and my family (they are all good:) and
keep me extremely busy. But i am not leaving and will be back on this
soon.

the latest sources are in http://repo.or.cz/w/dragonfly/port-amd64.git
, I did have a compiled kernel long time before, but I have to break
it to work on the pmap. you can pick up from there. TGEN will help you
a lot, also keep me posted too, if you like.

Noah

On Wed, Mar 26, 2008 at 9:50 PM, Sdavtaker <sdavtaker at gmail.com> wrote:
> Hello,
>  Im applying to GSoC to work in the x64 version of DFBSD with TGEN, i
>  found some work already done in the repository and some mails in the
>  archive from you.
>  I was wondering if you already had a working compiled kernel in AMD64
>  machine and what was not working yet to continue that work.
>  Thanks for any info.
>  Sdav
>




From dillon at apollo.backplane.com  Sat Mar 29 13:27:43 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Sat, 29 Mar 2008 13:27:43 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 29-Mar-2008
Message-ID: <200803292022.m2TKMLGe004942@apollo.backplane.com>

    Good progress continues to be made.  HAMMER survived acting as my
    LAN backup machine (in full historical mode) for almost a week before
    it hit an assertion.  I've fixed that issue and believe that the core
    filesystem implementation code is now 'very stable'.

    Note that the recent commit will result in many more 'hammer_lock_ex:'
    messages on the console then you may have previously observed.  This is
    due to the way object id's are allocated in the face of parallel 
    modifications to the filesystem, resulting in too much locality of
    reference in the B-Tree.  I do intend to improve it.

    I am still working on the two major items needed before HAMMER can be
    declared operational, those being the filesystem full handling and the
    undo/recovery-on-mount code.  These are the last 'hard' bits left in
    the design.

    With exception to filling up the filesystem, which *will* create a mess,
    and noting that no crash recovery code exists yet (so you have to newfs
    it if you crash), I'd appreciate it if interested parties could test
    the other functions of the filesystem, in particular the pruning and
    reblocking functions (man hammer), and the historical access functions.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From dillon at apollo.backplane.com  Sun Mar 30 15:11:03 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Sun, 30 Mar 2008 15:11:03 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Need ideas on how to solve an st_ino/st_dev test issue for HAMMER.
Message-ID: <200803302207.m2UM7BCp016402@apollo.backplane.com>

    Here's the problem, given historical access softlinks as shown below:

test30# ls -lda cra*
drwxr-xr-x  1 root  wheel  Mar 29 13:04 crater
lrwxr-xr-x  1 root  wheel  Mar 29 18:57 crater.20080329 -> crater@@0x47eef383
lrwxr-xr-x  1 root  wheel  Mar 30 01:24 crater.20080330 -> crater@@0x47ef4e29
-rw-r--r--  2 root  wheel  Mar 30 01:24 crater.log

    The problem is that if I do this:

    diff -r crater.20080329/var/log crater.20080330/var/log

    Diff just returns without actually diffing anything.  The reason is
    because diff checks st_ino and st_dev and believes the directories/files
    to be identical because they match.

    I considered munging the inode number for historical accesses, but
    that would seriously break NFS exports which try to access historical
    files and directories.  Right now NFS *is* able to distinguish between
    the two because NFS handles are 128-bit-wide entities, so I can encode
    the as-of transaction id as part of the filehandle.  But userland
    programs only have access to a 64-bit-wide inode so userland still
    believes the files to be identical.

    st_dev is only 32 bits, carefully munging it is an option if we
    could figure out a way to do it, but I'd rather not.

    I am considering using st_gen but then we'd have to patch third
    party software to test st_gen along with everything else.  This may
    be the only workable solution, though, and only a few programs would
    need to be patched.  st_gen is only 32 bits but it would solve the
    problem as we would be able to use all 32 bits.

    If anyone has any bright ideas, including 'leave it alone', I'm all
    ears.

						-Matt





From justin at shiningsilence.com  Mon Mar 31 10:40:42 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Mon, 31 Mar 2008 10:40:42 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: SoC student applications due by 5PM PDT tomorrow
In-Reply-To: <1942.192.168.0.242.1206930479.squirrel@www.shiningsilence.com>
Message-ID: <11892.67.108.184.175.1206984967.squirrel@www.shiningsilence.com>

On Sun, March 30, 2008 10:27 pm, Justin C. Sherrill wrote:
> SoC students:
>
> If you have an application to submit for DragonFly/Summer of Code, please
> do so by 17:00 Pacific time on the 31st - that's tomorrow, at least for
> me.

The deadline for student proposals has been extended to April 7th; all
other dates move forward one week to acommodate.

This is a good time to update existing applications or submit new ones. 
Talk to your (potential) mentors if you are curious.






From nthery at gmail.com  Mon Mar 31 11:29:49 2008
From: nthery at gmail.com (Nicolas Thery)
Date: Mon, 31 Mar 2008 11:29:49 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
Message-ID: <64fc43b0803311126na7d0b27obaa9d35bac6d32ee@mail.gmail.com>

Hello,

Now that the release is over, I'll try to get rid of zones and migrate
allocations to objcache.

Here is a 1st patch that migrate struct proc.  I'll commit it in a
couple of days if nobody objects.

I'm also implementing a way to monitor objcache statistics.  So far,
I've hacked sth similar to
sysctl vm.zone: stats are returned in one giant string, one line per
cache.  That's simple but ugly and hard to read because there are
quite a few stats per cache.

So I'm thinking about implementing a small tool, ocstat, that extracts
stats from sysctl the way ps(1) does (thru libkvm iirc) and formats it
in various ways.  What do you think?

Cheers,
Nicolas

Index: src2/sys/kern/kern_exit.c
===================================================================
--- src2.orig/sys/kern/kern_exit.c	2008-03-31 08:05:59.139796000 +0200
+++ src2/sys/kern/kern_exit.c	2008-03-31 10:31:39.000000000 +0200
@@ -834,7 +834,7 @@ loop:
 			}

 			vm_waitproc(p);
-			zfree(proc_zone, p);
+			objcache_put(proc_cache, p);
 			nprocs--;
 			return (0);
 		}
Index: src2/sys/kern/kern_proc.c
===================================================================
--- src2.orig/sys/kern/kern_proc.c	2008-03-31 08:05:59.139918000 +0200
+++ src2/sys/kern/kern_proc.c	2008-03-31 10:31:39.000000000 +0200
@@ -84,7 +84,7 @@ u_long pgrphash;
 struct proclist allproc;
 struct proclist zombproc;
 struct spinlock allproc_spin;
-vm_zone_t proc_zone;
+struct objcache* proc_cache;
 vm_zone_t lwp_zone;
 vm_zone_t thread_zone;

@@ -131,7 +131,7 @@ procinit(void)
 	spin_init(&allproc_spin);
 	pidhashtbl = hashinit(maxproc / 4, M_PROC, &pidhash);
 	pgrphashtbl = hashinit(maxproc / 4, M_PROC, &pgrphash);
-	proc_zone = zinit("PROC", sizeof (struct proc), 0, 0, 5);
+	proc_cache = objcache_create_simple(M_PROC, sizeof(struct proc));
 	lwp_zone = zinit("LWP", sizeof (struct lwp), 0, 0, 5);
 	thread_zone = zinit("THREAD", sizeof (struct thread), 0, 0, 5);
 	uihashinit();
Index: src2/sys/sys/proc.h
===================================================================
--- src2.orig/sys/sys/proc.h	2008-03-31 08:05:59.140325000 +0200
+++ src2/sys/sys/proc.h	2008-03-31 10:31:39.000000000 +0200
@@ -473,7 +473,7 @@ struct proc *zpfind (pid_t);	/* Find zom
 struct vm_zone;
 struct globaldata;
 struct lwp_params;
-extern struct vm_zone *proc_zone;
+extern struct objcache *proc_cache;
 extern struct vm_zone *lwp_zone;

 int	enterpgrp (struct proc *p, pid_t pgid, int mksess);
Index: src2/sys/kern/kern_fork.c
===================================================================
--- src2.orig/sys/kern/kern_fork.c	2008-03-31 08:05:59.140042000 +0200
+++ src2/sys/kern/kern_fork.c	2008-03-31 10:31:39.000000000 +0200
@@ -332,7 +332,7 @@ fork1(struct lwp *lp1, int flags, struct
 	}

 	/* Allocate new proc. */
-	p2 = zalloc(proc_zone);
+	p2 = objcache_get(proc_cache, M_WAITOK);
 	bzero(p2, sizeof(*p2));

 	/*




From hsu at dragonflybsd.org  Mon Mar 31 11:44:34 2008
From: hsu at dragonflybsd.org (Jeffrey Hsu)
Date: Mon, 31 Mar 2008 11:44:34 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <64fc43b0803311126na7d0b27obaa9d35bac6d32ee@mail.gmail.com>
Message-ID: <200803311841.m2VIfQAI007579@nlpi001.prodigy.net>

The object cache is not a general-purpose memory allocator.  It's a cache of
pre-initialized objects.  Are the significant portions of the proc structure
that can be restored to initialized state on object puts?  If not, it's best
to just use a general-purpose memory allocator.

								Jeffrey




From corecode at fs.ei.tum.de  Mon Mar 31 12:07:02 2008
From: corecode at fs.ei.tum.de (Simon 'corecode' Schubert)
Date: Mon, 31 Mar 2008 12:07:02 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <200803311841.m2VIfQAI007579@nlpi001.prodigy.net>
Message-ID: <47F1357B.1070302@fs.ei.tum.de>

Jeffrey Hsu wrote:
> The object cache is not a general-purpose memory allocator.  It's a cache of
> pre-initialized objects.  Are the significant portions of the proc structure
> that can be restored to initialized state on object puts?  If not, it's best
> to just use a general-purpose memory allocator.

Why?  What's the loss if we use the object cache to allocate struct procs?

cheers
  simon

Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00006.pgp
Type: application/octet-stream
Size: 252 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080331/a4a24314/attachment-0017.obj>

From nthery at gmail.com  Mon Mar 31 12:17:03 2008
From: nthery at gmail.com (Nicolas Thery)
Date: Mon, 31 Mar 2008 12:17:03 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <nthery@gmail.com>
Message-ID: <64fc43b0803311214u7da6bbb8xaf971de1a80e7258@mail.gmail.com>

2008/3/31, Jeffrey Hsu <hsu at dragonflybsd.org>:
> The object cache is not a general-purpose memory allocator.  It's a cache of
>  pre-initialized objects.  Are the significant portions of the proc structure
>  that can be restored to initialized state on object puts?  If not, it's best
>  to just use a general-purpose memory allocator.

Well, I haven't checked this yet.  I planned to do this in a second
step after getting rid of zones.

I thought that even without  the pre-initialization part, objcache has
the advantage
of pre-allocating set of objects (as zones) and is additionally
mp-safe (contrary to zones and, granted, as malloc()).   The latter
may be interesting as we talk of improving MP support.

Cheers,
Nicolas




From dillon at apollo.backplane.com  Mon Mar 31 12:23:40 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Mon, 31 Mar 2008 12:23:40 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <200803311841.m2VIfQAI007579@nlpi001.prodigy.net>
Message-ID: <200803311921.m2VJLITB027669@apollo.backplane.com>

    I both agree and disagree with Jeff.  I think the only *disadvantage*
    to using objcache for struct proc is that objcache must cache a minimum
    number of free structures to be efficient so the overall kernel memory
    use would be a bit greater verses uses kmalloc().  But I agree with Jeff
    in that objcache's biggest advantage is that you can keep structural state
    intact and struct proc might not be a good candidate (yet).

    What I suggest is that you convert struct proc from zone to kmalloc
    first, and then look into a possible objcache adaptation.  kmalloc
    is not slow.. it's a very fast allocator.  Objcache is probably a tad
    faster but not by much.  Where objcache really wins is in not having
    to completey reinitialize the allocated structures.

    Over the years I've removed (I think) all the dependancies on requiring
    the proc structure to be in stable memory so I believe it can be moved to
    kmalloc/objcache now without any major pain.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From corecode at fs.ei.tum.de  Mon Mar 31 12:37:40 2008
From: corecode at fs.ei.tum.de (Simon 'corecode' Schubert)
Date: Mon, 31 Mar 2008 12:37:40 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: SoC student applications due by 5PM PDT tomorrow
In-Reply-To: <1942.192.168.0.242.1206930479.squirrel@www.shiningsilence.com>
Message-ID: <47F13CDA.6010703@fs.ei.tum.de>

Justin C. Sherrill wrote:
> On Sun, March 30, 2008 10:27 pm, Justin C. Sherrill wrote:
>> SoC students:
>>
>> If you have an application to submit for DragonFly/Summer of Code, please
>> do so by 17:00 Pacific time on the 31st - that's tomorrow, at least for
>> me.
> The deadline for student proposals has been extended to April 7th; all
> other dates move forward one week to acommodate.

This is very good.

Some more ideas for eager students (we want to keep the ratio, right?):

Enhance the FreeBSD/DragonFly sound infrastructure to support surround
sound/multichannel output.

Update sound drivers to support S/PDIF output.

Make the sound infrastructure OSSv4 compatible (there was a SoC at
FreeBSD last year or so)


of course only if it doesn't exist already :)

cheers
  simon


Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00007.pgp
Type: application/octet-stream
Size: 252 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080331/6da61cff/attachment-0017.obj>

From corecode at fs.ei.tum.de  Mon Mar 31 12:41:30 2008
From: corecode at fs.ei.tum.de (Simon 'corecode' Schubert)
Date: Mon, 31 Mar 2008 12:41:30 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <200803311841.m2VIfQAI007579@nlpi001.prodigy.net>
Message-ID: <47F13DE4.10205@fs.ei.tum.de>

Matthew Dillon wrote:
>     What I suggest is that you convert struct proc from zone to kmalloc
>     first, and then look into a possible objcache adaptation.  kmalloc
>     is not slow.. it's a very fast allocator.  Objcache is probably a tad
>     faster but not by much.  Where objcache really wins is in not having
>     to completey reinitialize the allocated structures.

Could we please not move to kmalloc, but instead try to move all fast
path allocations to objcache?  I don't like the idea of allocating
everything with kmalloc.  Caching struct procs is not a bad thing itself.

cheers
  simon


Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00008.pgp
Type: application/octet-stream
Size: 252 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080331/ac328c08/attachment-0017.obj>

From hsu at FreeBSD.org  Mon Mar 31 12:59:05 2008
From: hsu at FreeBSD.org (Jeffrey Hsu)
Date: Mon, 31 Mar 2008 12:59:05 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <47F1357B.1070302@fs.ei.tum.de>
Message-ID: <200803311920.m2VJK5Ln018015@nlpi015.prodigy.net>

The object cache sits on top of a general-purpose memory allocator such
as kmalloc or zalloc and provides pre-initialized object caching functionality.
If you're not going to use the object caching functionality, you can just
call the underlying memory allocator directly.

							Jeffrey




From dillon at apollo.backplane.com  Mon Mar 31 16:17:19 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Mon, 31 Mar 2008 16:17:19 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <200803311841.m2VIfQAI007579@nlpi001.prodigy.net>
Message-ID: <200803312311.m2VNBumd029866@apollo.backplane.com>

:Could we please not move to kmalloc, but instead try to move all fast
:path allocations to objcache?  I don't like the idea of allocating
:everything with kmalloc.  Caching struct procs is not a bad thing itself.=
:
:
:cheers
:  simon

    I will state for the record that I'm fine with either objcache or
    kmalloc.  I agree with Jeff that using objcache for struct proc
    probably isn't necessary but I also agree that it would not hurt either,
    and if the intent is to optimize the initialization of the proc
    structure in the future then moving to objcache now would save us
    from having to do it later.

    So whichever method Nicolas wants to use is fine with me.

						-Matt




From hsu at dragonflybsd.org  Mon Mar 31 19:22:47 2008
From: hsu at dragonflybsd.org (Jeffrey Hsu)
Date: Mon, 31 Mar 2008 19:22:47 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <64fc43b0803311214u7da6bbb8xaf971de1a80e7258@mail.gmail.com>
Message-ID: <200804010218.m312IVUq003624@nlpi043.prodigy.net>

  >> Are there significant portions of the proc structure
  >> that can be restored to initialized state on object puts?

  > I planned to do this in a second step after getting rid of zones.

I'll all in favor of making more use of caching pre-initialized objects, so
if this is your objective, then please go ahead.  It's just that I'd convert
over to the object cache in one step.

  > I thought that even without  the pre-initialization part, objcache has
  > the advantage of pre-allocating set of objects (as zones) and is additionally
  > mp-safe (contrary to zones and, granted, as malloc()).

Well, the zone allocator is MP-safe.  It's not hard to lock up the places that
manipulate the linked-list of free items. Look for uses of the zlock field.

								Jeffrey




From tgen at netphreax.net  Sat Mar  1 12:57:53 2008
From: tgen at netphreax.net (Thomas E. Spanjaard)
Date: Sat, 1 Mar 2008 12:57:53 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: [Fwd: Project Support Open Source: $50 donation to support you      project]
In-Reply-To: <2468.192.168.0.242.1204346451.squirrel@www.shiningsilence.com>
Message-ID: <47C9C1B7.50203@netphreax.net>

Justin C. Sherrill wrote:
The "donation" happens after you place an "acknowledgement" on an open
source project's web page.  I'm putting those words in scare quotes
because I think it's a "payment" for an "advertisement".  The supplied
link has nothing to do with DragonFly, to say the least.

<a href="http://www.2insure4less.com /" title="We support FOSS software
projects.">Online Insurance Quotes</a>
To think our souls are only worth $50...
--
        Thomas E. Spanjaard
        tgen at netphreax.net
Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00000.pgp
Type: application/octet-stream
Size: 186 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080301/0d61e240/attachment-0018.obj>

From c.turner at 199technologies.org  Sat Mar  1 17:52:31 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Sat, 1 Mar 2008 17:52:31 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Misc. ACPI / suspend
Message-ID: <47CA073B.6020106@199technologies.org>

Wondering if anyone more well versed in the ACPI implementation could
comment on the applicability of:
http://lkml.org/lkml/2007/4/6/69

w/r/t the current state of the art in Dfly

(or BSD's in general)

Cheers!

- Chris




From elekktretterr at exemail.com.au  Sun Mar  2 00:41:25 2008
From: elekktretterr at exemail.com.au (Petr Janda)
Date: Sun, 2 Mar 2008 00:41:25 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: CARP question
Message-ID: <200803021934.21669.elekktretterr@exemail.com.au>

So Ive setup CARP on 2 DF-based mailservers. Installation went fine. Box 1 has 
adskew of 0 therefore it is the MASTER. Box 2 has adskew of 254, therefore is 
BACKUP.  If i down the carp0 interface on Box 1, then Box 2 carp interface 
gets promoted to MASTER. Then I up the carp interface on Box 1, logically Box 
2 should become BACKUP again as Box 1 becomes MASTER due to adskew set to 0.

However it doesnt happen. When carp0 interface on Box 1 is upped it becomes a 
BACKUP, not a MASTER even though according to adskew it should be MASTER.

What is the desired behaviour?

Cheers
Petr




From qhwt+dfly at les.ath.cx  Sun Mar  2 02:50:14 2008
From: qhwt+dfly at les.ath.cx (YONETANI Tomokazu)
Date: Sun, 2 Mar 2008 02:50:14 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: panic: assertion: hammer_btree_cmp(cursor->left_bound,	&cursor->node->ondisk->elms[0].leaf.base) <= 0 in btree_split_leaf
In-Reply-To: <200802232204.m1NM4cxd046264@apollo.backplane.com>
Message-ID: <20080302104554.GA22813@les.ath.cx>

Hi.
While trying to find a procedure to reliably reproduce the panic
I reported last time, I caught a different panic (uploaded at
 ~y0netan1/crash/9/ on my leaf account).  I wrote the following shell
script (make sure to edit variables DISKS and MOUNTPT before using this
script or it may trash your system):
  #!/bin/sh -ex
  DISKS="/dev/ad0s1f"
  MOUNTPT=/mnt/HAMMER

  cd /
  newfs_hammer -L TEST $DISKS
  for i in `seq 1 100`; do
	  mount_hammer $DISKS $MOUNTPT
	  /bin/rm -rf $MOUNTPT/??
	  (set +x; for x in `seq 1 10000`; do echo -n > $MOUNTPT/$x; done)
	  umount $MOUNTPT
  done

And the panic is triggered by rm command.
I'll try to see if it's possible to reproduce the last one without
unmounting then mounting the HAMMER fs.

Cheers.




From dillon at apollo.backplane.com  Sun Mar  2 13:25:33 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Sun, 2 Mar 2008 13:25:33 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: panic: assertion: hammer_btree_cmp(cursor->left_bound,	&cursor->node->ondisk->elms[0].leaf.base) <= 0 in btree_split_leaf
In-Reply-To: <200802232204.m1NM4cxd046264@apollo.backplane.com>
Message-ID: <200803022119.m22LJRCY037076@apollo.backplane.com>


:Hi.
:While trying to find a procedure to reliably reproduce the panic
:I reported last time, I caught a different panic (uploaded at
: ~y0netan1/crash/9/ on my leaf account).  I wrote the following shell
:script (make sure to edit variables DISKS and MOUNTPT before using this
:script or it may trash your system):

(from the core)

panic: assertion: node->lock.refs == 0 && node->ondisk == NULL in hammer_flush_buffer_nodes

    Yah, I've seen this failure.  Add a sync or two before the umount and
    tell me if it still occurs.  It's either a node reference leak somewhere
    or it is a race between bufdaemon and umount.  The assertions are really
    strict there precisely to catch those sorts of cases.

    Also note that the code to deal with a full HAMMMER filesystem has not
    been written yet (The failure you are reporting is unrelated to a full
    HAMMER filesystem, though, just mentioning it).

						-Matt





From dillon at apollo.backplane.com  Sun Mar  2 13:29:03 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Sun, 2 Mar 2008 13:29:03 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Misc. ACPI / suspend
In-Reply-To: <47CA073B.6020106@199technologies.org>
Message-ID: <200803022126.m22LQbfI037188@apollo.backplane.com>


:Wondering if anyone more well versed in the ACPI implementation could
:comment on the applicability of:
:
:http://lkml.org/lkml/2007/4/6/69
:
:w/r/t the current state of the art in Dfly
:
:(or BSD's in general)
:
:Cheers!
:
:- Chris

    I really have no idea re: this.  Suspension in general is not well
    supported by any of the BSDs.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From dillon at apollo.backplane.com  Sun Mar  2 13:34:05 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Sun, 2 Mar 2008 13:34:05 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: [Fwd: Project Support Open Source: $50 donation to support you      project]
In-Reply-To: <2468.192.168.0.242.1204346451.squirrel@www.shiningsilence.com>
Message-ID: <200803022131.m22LVOe9037250@apollo.backplane.com>

:..
:source project's web page.  I'm putting those words in scare quotes
:because I think it's a "payment" for an "advertisement".  The supplied
:link has nothing to do with DragonFly, to say the least.
:
:I don't think this is a good idea, obviously, and replied to that effect. 
:However, I wanted to put this on a DragonFly list, in part to show this
:strange thing, and in part because I'm not comfortable making
:administrative decisions on behalf of the Project without being open as
:possible about it.

    It doesn't really cry out to me either.

						-Matt





From wbh at conducive.org  Sun Mar  2 20:36:32 2008
From: wbh at conducive.org (Bill Hacker)
Date: Mon, 03 Mar 2008 04:36:32 +0000
Subject: Misc. ACPI / suspend
In-Reply-To: <47CA073B.6020106@199technologies.org>
Message-ID: <47cb8050$0$855$415eb37d@crater_reader.dragonflybsd.org>

Matthew Dillon wrote:
:Wondering if anyone more well versed in the ACPI implementation could
:comment on the applicability of:
:
:http://lkml.org/lkml/2007/4/6/69
:
:w/r/t the current state of the art in Dfly
:
:(or BSD's in general)
:
:Cheers!
:
:- Chris
    I really have no idea re: this.  Suspension in general is not well
    supported by any of the BSDs.
					-Matt
					Matthew Dillon 
					<dillon at backplane.com>


. . and there seems to be a bit of a 'Catch 22' there in any case.

If the BIOS can alter 'stuff' out of site of the OS it is parking, what 
does the existence of such a 'feature' do to a(ny) security model?

Seems to at least beg creating the option of setting a flag to 
specifically *prevent* suspend-to-disk/hibernation (and/or force a 
reboot on wake-up).

Just because one is paranoid....  etc

Bill





From matthias at dragonflybsd.org  Tue Mar  4 02:30:52 2008
From: matthias at dragonflybsd.org (Matthias Schmidt)
Date: Tue, 4 Mar 2008 02:30:52 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
Message-ID: <20080304102335.GI9833@staatsfeind.org>

Hi,

Google just announced its Summer of Code for 2008:

	http://code.google.com/soc/2008/

I think this would be a great opportunity for DragonFly to participate
as a mentoring organisation.  We could attract new developers and could
get code/work done.  Looking at the SoC results of the other BSDs most
of their projects were a success.  Of course, not all, but a reasonable
percentage.  See [1] and [2].

It is some extra work for us, but IMO the benefits outweigh the extra
work.  And yes, I would volunteer as a mentor.  What do others
(developers) think?  Any more volunteers? :)

Some project ideas that come into my mind.  More ideas are listed in the
wiki:  http://wiki.dragonflybsd.org/index.cgi/ProjectsPage

 * Fix all remaining bugs in dma(8) and implement all missing features
 * Add a driver for newer Intel Wireless cards (I think sephe@ would
   love that :)
 * Bring our ACPI stuff in shape.  Maybe suspend2disk ...

 * [Add your own thoughts here]

Cheers,

	Matthias

PS: I don't want to create a bikeshed here whether you like the SoC or
not :)

[1] http://code.google.com/soc/2007/freebsd/about.html
[2] http://code.google.com/soc/2007/netbsd/about.html




From corecode at fs.ei.tum.de  Tue Mar  4 04:46:14 2008
From: corecode at fs.ei.tum.de (Simon 'corecode' Schubert)
Date: Tue, 4 Mar 2008 04:46:14 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47CD4386.1000704@fs.ei.tum.de>

Matthias Schmidt wrote:
>  * [Add your own thoughts here]

MP lock removal for network stack

and for the system  (first profile, find hot spots, fix hot spots, repeat)

cheers
  simon




From c.turner at 199technologies.org  Tue Mar  4 06:02:20 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Tue, 4 Mar 2008 06:02:20 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47CD551E.1040604@199technologies.org>

Matthias Schmidt wrote:
Some project ideas that come into my mind.  More ideas are listed in the
wiki:  http://wiki.dragonflybsd.org/index.cgi/ProjectsPage
+1 acpi
+1 interrupt routing
+1 SMP / giant removal
+1 pf synchup with openbsd
though there are several others on the page that are good..

need to dig up my wiki login and place appropriately..

also: thinking the ZFS port should be removed from the page - makes 
sense to everyone else? (e.g. fragments effort w/r/t hammer)





From tgen at netphreax.net  Tue Mar  4 06:54:31 2008
From: tgen at netphreax.net (Thomas E. Spanjaard)
Date: Tue, 4 Mar 2008 06:54:31 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47CD615F.8010209@netphreax.net>

Matthias Schmidt wrote:
Google just announced its Summer of Code for 2008:

 * [Add your own thoughts here]
x86-64 port :).
--
        Thomas E. Spanjaard
        tgen at netphreax.net
Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00001.pgp
Type: application/octet-stream
Size: 186 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080304/0d921000/attachment-0018.obj>

From rdivacky at FreeBSD.org  Tue Mar  4 07:07:03 2008
From: rdivacky at FreeBSD.org (Roman Divacky)
Date: Tue, 4 Mar 2008 07:07:03 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <20080304150255.GA8831@freebsd.org>

On Tue, Mar 04, 2008 at 02:49:03PM +0000, Thomas E. Spanjaard wrote:
> Matthias Schmidt wrote:
> >Google just announced its Summer of Code for 2008:
> >
> > * [Add your own thoughts here]
> 
> x86-64 port :).

all those ideas are great and needed etc. but keep in
mind that the projects should be doable by students
who might see dfly for the very first time.

don't overestimate whats possible and select projects
that look realistic

Roman Divacky (former SoC student)




From justin at shiningsilence.com  Tue Mar  4 08:32:56 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Tue, 4 Mar 2008 08:32:56 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <60322.65.106.147.226.1204648095.squirrel@www.shiningsilence.com>

On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
> Hi,
>
> Google just announced its Summer of Code for 2008:
>
> 	http://code.google.com/soc/2008/
>
> I think this would be a great opportunity for DragonFly to participate
> as a mentoring organisation.  We could attract new developers and could
> get code/work done.  Looking at the SoC results of the other BSDs most
> of their projects were a success.  Of course, not all, but a reasonable
> percentage.  See [1] and [2].

We've applied in previous years - Jeff Hsu did one year, and I put
together the application last year.  The hardest thing to find was
students (and they are the thing that helps SoC applications a lot, I
think).

Any student volunteers?  We have mentors.





From rluciani at gmail.com  Tue Mar  4 09:38:29 2008
From: rluciani at gmail.com (Robert Luciani)
Date: Tue, 04 Mar 2008 18:38:29 +0100
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47cd8915$0$854$415eb37d@crater_reader.dragonflybsd.org>

Justin C. Sherrill wrote:
> On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
>> Hi,
>>
>> Google just announced its Summer of Code for 2008:
>>
>> 	http://code.google.com/soc/2008/
>>
>> I think this would be a great opportunity for DragonFly to participate
>> as a mentoring organisation.  We could attract new developers and could
>> get code/work done.  Looking at the SoC results of the other BSDs most
>> of their projects were a success.  Of course, not all, but a reasonable
>> percentage.  See [1] and [2].
> 
> We've applied in previous years - Jeff Hsu did one year, and I put
> together the application last year.  The hardest thing to find was
> students (and they are the thing that helps SoC applications a lot, I
> think).
> 
> Any student volunteers?  We have mentors.
> 

bingo

-- 
Robert Luciani
Chalmers University of Technology, SWE
Department of Computer Science and Engineering
http://www.rluciani.com/public.key




From sdavtaker at gmail.com  Tue Mar  4 09:31:08 2008
From: sdavtaker at gmail.com (=?UTF-8?Q?Sd=C3=A4vtaker?=)
Date: Tue, 4 Mar 2008 09:31:08 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <c37d69f60803040926k206218a3kb8496d0cd18148bd@mail.gmail.com>

If you mentor, i will apply for coder :-)
Still in last year of university. :-)
Sdav

On Tue, Mar 4, 2008 at 1:28 PM, Justin C. Sherrill
<justin at shiningsilence.com> wrote:
> On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
>  > Hi,
>  >
>  > Google just announced its Summer of Code for 2008:
>  >
>  >       http://code.google.com/soc/2008/
>  >
>  > I think this would be a great opportunity for DragonFly to participate
>  > as a mentoring organisation.  We could attract new developers and could
>  > get code/work done.  Looking at the SoC results of the other BSDs most
>  > of their projects were a success.  Of course, not all, but a reasonable
>  > percentage.  See [1] and [2].
>
>  We've applied in previous years - Jeff Hsu did one year, and I put
>  together the application last year.  The hardest thing to find was
>  students (and they are the thing that helps SoC applications a lot, I
>  think).
>
>  Any student volunteers?  We have mentors.
>
>



-- 
Sd?vtaker prays to Rikku goddess for a good treasure.



From rluciani at gmail.com  Tue Mar  4 09:44:02 2008
From: rluciani at gmail.com (Robert Luciani)
Date: Tue, 04 Mar 2008 18:44:02 +0100
Subject: google soc "DragonFly"
Message-ID: <47cd8a63$0$855$415eb37d@crater_reader.dragonflybsd.org>

On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
> > Hi,
> >
> > Google just announced its Summer of Code for 2008:
> >
> > 	http://code.google.com/soc/2008/
> >
> > I think this would be a great opportunity for DragonFly to participate
> > as a mentoring organisation.  We could attract new developers and could
> > get code/work done.  Looking at the SoC results of the other BSDs most
> > of their projects were a success.  Of course, not all, but a reasonable
> > percentage.  See [1] and [2].

We've applied in previous years - Jeff Hsu did one year, and I put
together the application last year.  The hardest thing to find was
students (and they are the thing that helps SoC applications a lot, I
think).

Any student volunteers?  We have mentors.


-- 
Robert Luciani
Chalmers University of Technology, SWE
Department of Computer Science and Engineering
http://www.rluciani.com/public.key




From rluciani at gmail.com  Tue Mar  4 10:04:14 2008
From: rluciani at gmail.com (Robert Luciani)
Date: Tue, 04 Mar 2008 19:04:14 +0100
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47cd8f1f$0$856$415eb37d@crater_reader.dragonflybsd.org>

Robert Luciani wrote:
> Justin C. Sherrill wrote:
>> On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
>>> Hi,
>>>
>>> Google just announced its Summer of Code for 2008:
>>>
>>> 	http://code.google.com/soc/2008/
>>>
>>> I think this would be a great opportunity for DragonFly to participate
>>> as a mentoring organisation.  We could attract new developers and could
>>> get code/work done.  Looking at the SoC results of the other BSDs most
>>> of their projects were a success.  Of course, not all, but a reasonable
>>> percentage.  See [1] and [2].
>> We've applied in previous years - Jeff Hsu did one year, and I put
>> together the application last year.  The hardest thing to find was
>> students (and they are the thing that helps SoC applications a lot, I
>> think).
>>
>> Any student volunteers?  We have mentors.
>>
> 
> bingo
> 
My girlfriend Danwei noted that she would also like partake in the SoC.
She's studying IT here at Chalmers and will join the mailing list shortly.
-- 
Robert Luciani
Chalmers University of Technology, SWE
Department of Computer Science and Engineering
http://www.rluciani.com/public.key




From dillon at apollo.backplane.com  Tue Mar  4 13:08:30 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Tue, 4 Mar 2008 13:08:30 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Going to have to roll 1.12.1
Message-ID: <200803042104.m24L43g1065278@apollo.backplane.com>

    Due to a critical bug in sendmail that can cause it to seg-fault I will
    be rolling 1.12.1 as soon as I get verification that the current
    fix deals with it.

						-Matt





From sdavtaker at gmail.com  Tue Mar  4 17:40:43 2008
From: sdavtaker at gmail.com (=?UTF-8?B?U2TDpHZ0YWtlcg==?=)
Date: Tue, 4 Mar 2008 17:40:43 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: [Fwd: Project Support Open Source: $50 donation to support you  project]
In-Reply-To: <2468.192.168.0.242.1204346451.squirrel@www.shiningsilence.com>
Message-ID: <47CDF8D1.9070100@gmail.com>

50 bucks?
Come on...
You can get a meal a lot more expensive than that just going to a free 
HP conference about linux and you only have to rent your soul 3-5 hours ;-)
Sdav

Matthew Dillon escribi?:
:..
:source project's web page.  I'm putting those words in scare quotes
:because I think it's a "payment" for an "advertisement".  The supplied
:link has nothing to do with DragonFly, to say the least.
:
:I don't think this is a good idea, obviously, and replied to that effect. 
:However, I wanted to put this on a DragonFly list, in part to show this
:strange thing, and in part because I'm not comfortable making
:administrative decisions on behalf of the Project without being open as
:possible about it.

    It doesn't really cry out to me either.

						-Matt

  






From sdavtaker at gmail.com  Tue Mar  4 17:56:35 2008
From: sdavtaker at gmail.com (=?UTF-8?B?U2TDpHZ0YWtlcg==?=)
Date: Tue, 4 Mar 2008 17:56:35 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47CDFCCE.1010106@gmail.com>

A cute idea for for GSOC would be to finish the installer.
We were talking about this in my local BUG, we trying to find out how to 
help on that from here.
There is a few missing features in the CD.

   * FDISK, you need to create the slides from another OS before
     install DFBSD, i think port FDisk from FBSD or any *BSD will solve it.
   * Add to the make release a way to add some custom applications to
     the released liveCD (suppose you want to add nmap or ssh or
     something just to use as test disk in some enviroment).
   * Make the installer a little more customizable, and maybe w/ a GUI
     (I like a lot the console approach, but GUI installer will be a
     popularity move, DFBSD w/X makes a Desktop machine work, actually
     im using it that way and really like it).
I think those projects can be done in a SOC by students (like me) with a 
little guide.
Im a lot more interested in things network related and kernel, but i 
dont mind to work on those things, they need to be done some day.
What u think?
Sdav

Robert Luciani escribi?:
Robert Luciani wrote:
  
Justin C. Sherrill wrote:
    
On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
      
Hi,

Google just announced its Summer of Code for 2008:

	http://code.google.com/soc/2008/

I think this would be a great opportunity for DragonFly to participate
as a mentoring organisation.  We could attract new developers and could
get code/work done.  Looking at the SoC results of the other BSDs most
of their projects were a success.  Of course, not all, but a reasonable
percentage.  See [1] and [2].
        
We've applied in previous years - Jeff Hsu did one year, and I put
together the application last year.  The hardest thing to find was
students (and they are the thing that helps SoC applications a lot, I
think).
Any student volunteers?  We have mentors.

      
bingo

    
My girlfriend Danwei noted that she would also like partake in the SoC.
She's studying IT here at Chalmers and will join the mailing list shortly.
  






From c.turner at 199technologies.org  Tue Mar  4 18:30:53 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Tue, 4 Mar 2008 18:30:53 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47CE04C9.1010902@199technologies.org>

Justin C. Sherrill wrote:
together the application last year.  The hardest thing to find was
students (and they are the thing that helps SoC applications a lot, I
think).
umm.. if google wants to send me back to school, I'll sign up - hows 
that for a fair trade :?






From wbh at conducive.org  Tue Mar  4 23:52:13 2008
From: wbh at conducive.org (Bill Hacker)
Date: Wed, 05 Mar 2008 07:52:13 +0000
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47ce512e$0$855$415eb37d@crater_reader.dragonflybsd.org>

Sd?vtaker wrote:
A cute idea for for GSOC would be to finish the installer.
We were talking about this in my local BUG, we trying to find out how to 
help on that from here.
There is a few missing features in the CD.

   * FDISK, you need to create the slides from another OS before
     install DFBSD, i think port FDisk from FBSD or any *BSD will solve it.
I'd rather see that 'reversed' - i.e. - build a more capable fdisk in 
DFLY with hope that it might be seen worth importing into Free/Net/Open, 
or *at least* be able to do a more flexible job than those now do.

And disklabels as well. Hand in glove.

Here's why:

- At the moment, working with Free, Open, DFLY, and OpenSolaris on the 
same HDD requires a bit of acrobatics.

- There seems to now be greater divergence between/among the *BSD's as 
to being able to read each other's disklabels, mount and use each 
other's 'flavor' of FFS/UFS (not to mention Apple's implementation of 
UFS) than there is among the vast multitude of Linux ext2/3 denizens.

Even to the point where use of a *Linux* fs is the more universal way 
for being able to share mounts among the *BSD's. Think detached drives. 
And no - FAT is not all that practical for several reasons.

- DFLY currently has the most fine-grain ability to create slices and 
partitions. But the others cannot all (any?) read those.

'progress' w/r any of the *BSD's direction as to changes, improvements 
(or not) in their once-common-ancestry fs & disklabels need not be 
sacrificed.

I'm not holding out wish or hope for all players agreeing to return to 
'one sacred way'. Nor 'one new universal fs'. Neither is gonna happen.

But a 'legacy compatible' or least-common-denominator mode would do fine 
- most especially for portable / SAN devices.

So - how about a 'flexible' DFLY fdisk to go along with a 'flexible' 
disklabel that could adapt to whatever it found / was told to create?

JM2CW - but that *might* be a good place to get a cross-*BSD team together.

*snip* (other good stuff)

Bill Hacker




From matthias at dragonflybsd.org  Wed Mar  5 01:02:43 2008
From: matthias at dragonflybsd.org (Matthias Schmidt)
Date: Wed, 5 Mar 2008 01:02:43 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <20080305085747.GJ9833@staatsfeind.org>

Hi,

* Justin C. Sherrill wrote:
> 
> We've applied in previous years - Jeff Hsu did one year, and I put
> together the application last year.  The hardest thing to find was
> students (and they are the thing that helps SoC applications a lot, I
> think).

This is good to know, so we could coordinate that if we have enough
mentors and projects?!?  I put together a small text in the wiki:

http://wiki.dragonflybsd.org/index.cgi/GoogleSoC2008

Feel free to add project or missing stuff.  I'm sure I missed a lot of
things :)

> Any student volunteers?  We have mentors.

According to the discussion we could have some students, who would be a
mentor (besides me)?

Regards

	Matthias





From sdavtaker at gmail.com  Wed Mar  5 06:28:37 2008
From: sdavtaker at gmail.com (=?UTF-8?Q?Sd=C3=A4vtaker?=)
Date: Wed, 5 Mar 2008 06:28:37 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <c37d69f60803050624kd86d3d0w3b44a02d0e5a5391@mail.gmail.com>

<quote>
Write a driver (from scratch) for Intel 3945 wireless device
Mentor: Sepherosa Ziehau
</quote>

Yes yes yes, i want to :-)
Someone else planning to mentor in drivers coding?
Sdav

On Wed, Mar 5, 2008 at 5:57 AM, Matthias Schmidt
<matthias at dragonflybsd.org> wrote:
> Hi,
>
>
>  * Justin C. Sherrill wrote:
>  >
>  > We've applied in previous years - Jeff Hsu did one year, and I put
>  > together the application last year.  The hardest thing to find was
>  > students (and they are the thing that helps SoC applications a lot, I
>  > think).
>
>  This is good to know, so we could coordinate that if we have enough
>  mentors and projects?!?  I put together a small text in the wiki:
>
>  http://wiki.dragonflybsd.org/index.cgi/GoogleSoC2008
>
>  Feel free to add project or missing stuff.  I'm sure I missed a lot of
>  things :)
>
>
>  > Any student volunteers?  We have mentors.
>
>  According to the discussion we could have some students, who would be a
>  mentor (besides me)?
>
>  Regards
>
>         Matthias
>
>



-- 
Sd?vtaker prays to Rikku goddess for a good treasure.



From rluciani at gmail.com  Wed Mar  5 10:56:42 2008
From: rluciani at gmail.com (Robert Luciani)
Date: Wed, 05 Mar 2008 19:56:42 +0100
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47ceecea$0$847$415eb37d@crater_reader.dragonflybsd.org>

Sd?vtaker wrote:
> <quote>
> Write a driver (from scratch) for Intel 3945 wireless device
> Mentor: Sepherosa Ziehau
> </quote>
> 
> Yes yes yes, i want to :-)
> Someone else planning to mentor in drivers coding?
> Sdav
> 
> On Wed, Mar 5, 2008 at 5:57 AM, Matthias Schmidt
> <matthias at dragonflybsd.org> wrote:
>> Hi,
>>
>>
>>  * Justin C. Sherrill wrote:
>>  >
>>  > We've applied in previous years - Jeff Hsu did one year, and I put
>>  > together the application last year.  The hardest thing to find was
>>  > students (and they are the thing that helps SoC applications a lot, I
>>  > think).
>>
>>  This is good to know, so we could coordinate that if we have enough
>>  mentors and projects?!?  I put together a small text in the wiki:
>>
>>  http://wiki.dragonflybsd.org/index.cgi/GoogleSoC2008
>>
>>  Feel free to add project or missing stuff.  I'm sure I missed a lot of
>>  things :)
>>
>>
>>  > Any student volunteers?  We have mentors.
>>
>>  According to the discussion we could have some students, who would be a
>>  mentor (besides me)?
>>
>>  Regards
>>
>>         Matthias
>>
>>
> 
> 
>

IF someone starts to write a 3945 Intel driver,
please keep the newer 4965 in mind too.

-- 
Robert Luciani
Chalmers University of Technology, SWE
Department of Computer Science and Engineering
http://www.rluciani.com/public.key




From joerg at britannica.bec.de  Wed Mar  5 12:01:05 2008
From: joerg at britannica.bec.de (Joerg Sonnenberger)
Date: Wed, 5 Mar 2008 12:01:05 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <20080305195711.GA9981@britannica.bec.de>

On Wed, Mar 05, 2008 at 07:56:42PM +0100, Robert Luciani wrote:
> IF someone starts to write a 3945 Intel driver,
> please keep the newer 4965 in mind too.

NetBSD's wpi works quite well. The hardware is quite different from
4945.

Joerg




From sepherosa at gmail.com  Wed Mar  5 17:48:50 2008
From: sepherosa at gmail.com (Sepherosa Ziehau)
Date: Wed, 5 Mar 2008 17:48:50 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <ea7b9c170803051744u22b09484ofc994f034f11df3b@mail.gmail.com>

On Thu, Mar 6, 2008 at 2:56 AM, Robert Luciani <rluciani at gmail.com> wrote:
>  IF someone starts to write a 3945 Intel driver,

"IF" you know that trying to fix any wired bugs in certain drivers
(e.g. ipw, ral) will require you to read through all of the vendor's
linux code (yes, even including register values and position), i.e.
there is not much difference between writing one from scratch and
porting+fixing_bugs, then you probably will not put "IF" at the start
of your sentence.
If what I said sounded too harsh to you, then I was sorry.

>  please keep the newer 4965 in mind too.

Will do, once generic 11n support is brought in from freebsd.

Best Regards,
sephe

-- 
Live Free or Die




From saw at online.de  Thu Mar  6 05:34:14 2008
From: saw at online.de (Sascha Wildner)
Date: Thu, 06 Mar 2008 14:34:14 +0100
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
Message-ID: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>

Hi all,

this is probably as good a moment as any to come out of the forest with 
this. The patch at

http://leaf.dragonflybsd.org/~swildner/nrelease_gui.diff

adds some code to nrelease/ to build a LiveCD with xorg and so on 
(currently, only the xorg metapackages and fluxbox are added). In order 
to build one, you need a local dir with the pkgsrc binary packages (see 
below).

The following commands should then do the trick:

cd /usr/src
make buildworld
make buildkernel
cd nrelease
patch -p 0 </path/to/the/patch
make PKGSRC_PKG_PATH=/path/to/packages/dir/All realquick gui
The resulting ISO will be in /usr/release/dfly-gui.iso then. It will not 
boot into xorg automatically (although this is easily possible), so you 
need to login as root and do startx.

As of now, this all is kind of basic, more a proof of concept than 
anything else. As our release framework installs packages via chroot, 
the current setup just copies _all_ packages to the chroot before 
installing (kind of a hack).

That said, I'm now primarily interested in opinions/ideas/... about the 
direction this should take. Which packages would we like to see on the 
CD? Should it be a generic setup with the "most common things" 
installed, so a system can be quickly setup by the installer (which will 
cpdup /usr/pkg). Or should it be a more specialized set of tools? Or 
even as many packages as possible (Live DVD?). Etc., etc.

Before continuing on it, I'm really interested in people's input so 
don't hold anything back, please. :)

Sascha

--
http://yoyodyne.ath.cx



From rluciani at gmail.com  Thu Mar  6 06:42:03 2008
From: rluciani at gmail.com (Robert Luciani)
Date: Thu, 06 Mar 2008 15:42:03 +0100
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <47d002bc$0$847$415eb37d@crater_reader.dragonflybsd.org>

Sascha Wildner wrote:
> Hi all,
> 
> this is probably as good a moment as any to come out of the forest with
> this. The patch at
> 
> http://leaf.dragonflybsd.org/~swildner/nrelease_gui.diff
> 
> adds some code to nrelease/ to build a LiveCD with xorg and so on
> (currently, only the xorg metapackages and fluxbox are added). In order
> to build one, you need a local dir with the pkgsrc binary packages (see
> below).
> 
> The following commands should then do the trick:
> 
> cd /usr/src
> make buildworld
> make buildkernel
> cd nrelease
> patch -p 0 </path/to/the/patch
> make PKGSRC_PKG_PATH=/path/to/packages/dir/All realquick gui
> 
> The resulting ISO will be in /usr/release/dfly-gui.iso then. It will not
> boot into xorg automatically (although this is easily possible), so you
> need to login as root and do startx.
> 
> As of now, this all is kind of basic, more a proof of concept than
> anything else. As our release framework installs packages via chroot,
> the current setup just copies _all_ packages to the chroot before
> installing (kind of a hack).
> 
> That said, I'm now primarily interested in opinions/ideas/... about the
> direction this should take. Which packages would we like to see on the
> CD? Should it be a generic setup with the "most common things"
> installed, so a system can be quickly setup by the installer (which will
> cpdup /usr/pkg). Or should it be a more specialized set of tools? Or
> even as many packages as possible (Live DVD?). Etc., etc.
> 
> Before continuing on it, I'm really interested in people's input so
> don't hold anything back, please. :)
> 
> Sascha
> 

I think the main point of such a live-cd would be to test
dragonfly-specific features such as vkernels and more. Mplayer and
OpenOffic work the same on all platforms, so they might not be super
important, while irssi, firefox, networking tools, vim, a few more
shells/terminals might make it easier to for people to quickly gauge if
they can reproduce their current productivity and also what is new.

And if the point of a livecd is to test that kind of stuff, then it
would be nice for it to have a kernel that supports as much as possible
like ALTQ, and drivers.

Also if it has lots and lots of programs (thinking multimedia, java,
etc..) it might be hard to keep the future x64 and x86 live-cds on par.
Gentoo had this problem many years ago and it was very bothersome.

-- 
Robert Luciani
Chalmers University of Technology, SWE
Department of Computer Science and Engineering
http://www.rluciani.com/public.key




From matthias at dragonflybsd.org  Thu Mar  6 07:12:43 2008
From: matthias at dragonflybsd.org (Matthias Schmidt)
Date: Thu, 6 Mar 2008 07:12:43 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <20080306150757.GN9833@staatsfeind.org>

* Sascha Wildner wrote:
> Hi all,
> 
> this is probably as good a moment as any to come out of the forest with this. 
> The patch at
> 
> http://leaf.dragonflybsd.org/~swildner/nrelease_gui.diff
> 
> adds some code to nrelease/ to build a LiveCD with xorg and so on (currently, 
> only the xorg metapackages and fluxbox are added). In order to build one, you 
> need a local dir with the pkgsrc binary packages (see below).

Great work Sascha.

I agree with Robert on most of his stated points.
It would be nice to see some DragonFly specific features on the CD
(although I'm not sure if that will work for all features).  A little
environment where most Unix users feel at home (fluxbox, xfce, firefox,
thunderbird, gvim) should be enough.

Big applications like OO.org, java etc won't work because they are not
available as pkgsrc packages neither is it possible to compile them on
DragonFly.  At least to my knowledge.

Regards

	Matthias




From dillon at apollo.backplane.com  Thu Mar  6 09:31:52 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Thu, 6 Mar 2008 09:31:52 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <200803061728.m26HSR3O091809@apollo.backplane.com>


:Hi all,
:
:this is probably as good a moment as any to come out of the forest with 
:this. The patch at
:
:http://leaf.dragonflybsd.org/~swildner/nrelease_gui.diff
:
:adds some code to nrelease/ to build a LiveCD with xorg and so on 
:(currently, only the xorg metapackages and fluxbox are added). In order 
:to build one, you need a local dir with the pkgsrc binary packages (see 
:below).
:
:The following commands should then do the trick:

    It looks reasonable, though the package copy has to be tightened
    up a bit I think.

:...
:installed, so a system can be quickly setup by the installer (which will 
:cpdup /usr/pkg). Or should it be a more specialized set of tools? Or 
:even as many packages as possible (Live DVD?). Etc., etc.
:
:Before continuing on it, I'm really interested in people's input so 
:don't hold anything back, please. :)
:
:Sascha

    I think this is an excellent time to work up a DVD build and to
    add various 'flavor' extras.  So, e.g.:

	make installer gui gui_extras release dvd

    (All 'dvd' would do is generate a dvd compatible image for burning to
    dvd instead of cd).  I did a quick perusal of what I have on my
    workstation:

    * X
    * Firefox
    * Linux emulation
    * Open Office (linux version)
    * fvwm2
    * xpdf
    * freetype2

    I'd also suggest some image editing tools like gimp, and maybe the KDE
    gui suite.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From justin at shiningsilence.com  Thu Mar  6 09:42:44 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Thu, 6 Mar 2008 09:42:44 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <55427.65.106.147.226.1204825168.squirrel@www.shiningsilence.com>

On Thu, March 6, 2008 8:34 am, Sascha Wildner wrote:

> That said, I'm now primarily interested in opinions/ideas/... about the
> direction this should take. Which packages would we like to see on the
> CD? Should it be a generic setup with the "most common things"
> installed, so a system can be quickly setup by the installer (which will
> cpdup /usr/pkg). Or should it be a more specialized set of tools? Or
> even as many packages as possible (Live DVD?). Etc., etc.

What Robert said is good - whatever's needed to enable DragonFly-specific
features.  Along with that would be some sort of documentation (a README? 
A HTML file on whatever desktop we provide) that points people at the
different DragonFly tools, so they know what to try and how to try it.

There's going to be some percentage of people who try DragonFly who don't
know about vkernels, for instance, but there's our chance to educate them.
 I'm probably volunteering myself, aren't I?





From sdavtaker at gmail.com  Thu Mar  6 09:50:09 2008
From: sdavtaker at gmail.com (=?UTF-8?Q?Sd=C3=A4vtaker?=)
Date: Thu, 6 Mar 2008 09:50:09 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <c37d69f60803060947t110750c0sd6b542ea505d188d@mail.gmail.com>

Cool Sascha :-)
I just posted about this 1 or 2 days ago in the SOC project ideas thread.
Want to mentor this one? ;-)
Damian

On Thu, Mar 6, 2008 at 2:28 PM, Matthew Dillon
<dillon at apollo.backplane.com> wrote:
>
>  :Hi all,
>
> :
>  :this is probably as good a moment as any to come out of the forest with
>  :this. The patch at
>  :
>  :http://leaf.dragonflybsd.org/~swildner/nrelease_gui.diff
>  :
>  :adds some code to nrelease/ to build a LiveCD with xorg and so on
>  :(currently, only the xorg metapackages and fluxbox are added). In order
>  :to build one, you need a local dir with the pkgsrc binary packages (see
>  :below).
>  :
>  :The following commands should then do the trick:
>
>     It looks reasonable, though the package copy has to be tightened
>     up a bit I think.
>
>  :...
>  :installed, so a system can be quickly setup by the installer (which will
>
> :cpdup /usr/pkg). Or should it be a more specialized set of tools? Or
>  :even as many packages as possible (Live DVD?). Etc., etc.
>  :
>  :Before continuing on it, I'm really interested in people's input so
>  :don't hold anything back, please. :)
>  :
>  :Sascha
>
>     I think this is an excellent time to work up a DVD build and to
>     add various 'flavor' extras.  So, e.g.:
>
>         make installer gui gui_extras release dvd
>
>     (All 'dvd' would do is generate a dvd compatible image for burning to
>     dvd instead of cd).  I did a quick perusal of what I have on my
>     workstation:
>
>     * X
>     * Firefox
>     * Linux emulation
>     * Open Office (linux version)
>     * fvwm2
>     * xpdf
>     * freetype2
>
>     I'd also suggest some image editing tools like gimp, and maybe the KDE
>     gui suite.
>
>                                         -Matt
>                                         Matthew Dillon
>                                         <dillon at backplane.com>
>



-- 
Sd?vtaker prays to Rikku goddess for a good treasure.



From saw at online.de  Thu Mar  6 11:54:01 2008
From: saw at online.de (Sascha Wildner)
Date: Thu, 06 Mar 2008 20:54:01 +0100
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <47d04ba2$0$856$415eb37d@crater_reader.dragonflybsd.org>

Matthew Dillon wrote:
    It looks reasonable, though the package copy has to be tightened
    up a bit I think.
It looks as if it would work with mount_null'ing the chroot's 
/tmp/packages. I'll have a better patch ready tomorrow.

Sascha

--
http://yoyodyne.ath.cx



From c.turner at 199technologies.org  Thu Mar  6 19:11:44 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Thu, 6 Mar 2008 19:11:44 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Misc. ACPI / suspend
In-Reply-To: <47CA073B.6020106@199technologies.org>
Message-ID: <47D0B079.3060905@199technologies.org>

Chris Turner wrote:
Wondering if anyone more well versed in the ACPI implementation could
comment on the applicability of:
http://lkml.org/lkml/2007/4/6/69

Doing a little digging, it seems like

. /platform/pc32/i386/i686_mem.c

*might* have the necessary infrastructure to remap the MTRR's per the 
thread referenced,

but:

. /platform/pc32/acpica5/acpi_wakeup.c

doesn't seem to be using this infrastructure..

I'm no where near reaching an understanding of this yet,
but I'm wondering 3 things:
1) does anyone have ACPI (instead of APM)
   sleep / suspend / wakeup working on Dfly ?
2) If so, what machines are being used ?
3) Same question for other BSDs - my understanding is NetBSD is most
   'advanced' w/r/t power managment - but I'm not 100% on this ...
would looove to have a sleeping / resuming / scaling laptop running some 
BSD flavor.. am willing to work towards that end, esp. w/r/t Dfly -
trying to chart a course to figguring this out.

Thanks all,

- Chris




From c.turner at 199technologies.org  Thu Mar  6 19:12:33 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Thu, 6 Mar 2008 19:12:33 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: PCI Bios / Interrupt remapping / etc
Message-ID: <47D0B211.6000002@199technologies.org>

Doing a bit of digging here for my long-standing CBB+SIO interupt and 
buffer problem -

one machine I've tested against was an OpenBSD machine, which didn't
always work to handle the cardbus sio card on a PCI cardbus adapter
-

tuning up some of the device flags in:

http://www.openbsd.org/cgi-bin/man.cgi?query=pcibios&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=html

seems to have alleviated the problem for that os..

I'm just only starting to get up to speed on how DF handles these types 
of things (namely initial PIC / interrupt layout at boot time device 
enumeration), but am wondering if anyone familiar with this area of the 
code has any comments / advice w/r/t the capabilities of the DF bios 
drivers
and the various quirks / fixup mentioned in the link above..

looking to possibly investigate fixing up some of these issues over time.

Thanks

- Chris







From pavalos at theshell.com  Fri Mar  7 01:14:55 2008
From: pavalos at theshell.com (Peter Avalos)
Date: Fri, 7 Mar 2008 01:14:55 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: cam locking
Message-ID: <20080307091024.GC1652@ylem.theshell.com>

So I've been working on locking up cam using lockmgr locks, and here's
what I have so far:

http://www.theshell.com/~pavalos/wip/cam-lock.patch

Most of the work is obtained from FreeBSD.  I've only been running this
on my SCSI machine for a day, but because the patch is so large, I wanted
to make it available for people to review if they have some spare time.

Thanks,
Peter
Attachment:
pgp00002.pgp
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00002.pgp
Type: application/octet-stream
Size: 197 bytes
Desc: "Description: PGP signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080307/9a17ecd8/attachment-0018.obj>

From jspringe at uos.de  Fri Mar  7 03:25:17 2008
From: jspringe at uos.de (Jost Tobias Springenberg)
Date: Fri, 7 Mar 2008 12:25:17 +0100
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <20080307122517.72c9e2b1.jspringe@uos.de>

On Tue, 4 Mar 2008 11:28:15 -0500 (EST)
"Justin C. Sherrill" <justin at shiningsilence.com> wrote:

> On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
> > Hi,
> >
> > Google just announced its Summer of Code for 2008:
> >
> > 	http://code.google.com/soc/2008/
> >
> > I think this would be a great opportunity for DragonFly to participate
> > as a mentoring organisation.  We could attract new developers and could
> > get code/work done.  Looking at the SoC results of the other BSDs most
> > of their projects were a success.  Of course, not all, but a reasonable
> > percentage.  See [1] and [2].
> 
> We've applied in previous years - Jeff Hsu did one year, and I put
> together the application last year.  The hardest thing to find was
> students (and they are the thing that helps SoC applications a lot, I
> think).
> 
> Any student volunteers?  We have mentors.
> 

I read this mailing list for quite a while now and thought about contributing stuff
to DFfly several times, so yes why not take this opportunity if it's there.

-- 
Jost Tobias Springenberg <jspringe at uos.de>




From tgen at netphreax.net  Fri Mar  7 05:17:27 2008
From: tgen at netphreax.net (Thomas E. Spanjaard)
Date: Fri, 7 Mar 2008 05:17:27 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: PCI Bios / Interrupt remapping / etc
In-Reply-To: <47D0B211.6000002@199technologies.org>
Message-ID: <47D13FB4.5080306@netphreax.net>

Chris Turner wrote:
Doing a bit of digging here for my long-standing CBB+SIO interupt and 
buffer problem -

one machine I've tested against was an OpenBSD machine, which didn't
always work to handle the cardbus sio card on a PCI cardbus adapter
-

tuning up some of the device flags in:

http://www.openbsd.org/cgi-bin/man.cgi?query=pcibios&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=html 

seems to have alleviated the problem for that os..

I'm just only starting to get up to speed on how DF handles these types 
of things (namely initial PIC / interrupt layout at boot time device 
enumeration), but am wondering if anyone familiar with this area of the 
code has any comments / advice w/r/t the capabilities of the DF bios 
drivers
and the various quirks / fixup mentioned in the link above..

looking to possibly investigate fixing up some of these issues over time.
Our code that handles issues like this (in cases where you're not using 
APICs, just PICs and PIRs) lives in bus/pci/i386/. Not that running 
without APIC support is all that common on modern machines anymore...
--
        Thomas E. Spanjaard
        tgen at netphreax.net
Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00003.pgp
Type: application/octet-stream
Size: 186 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080307/61366b5c/attachment-0018.obj>

From tgen at netphreax.net  Fri Mar  7 05:16:51 2008
From: tgen at netphreax.net (Thomas E. Spanjaard)
Date: Fri, 7 Mar 2008 05:16:51 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Misc. ACPI / suspend
In-Reply-To: <47CA073B.6020106@199technologies.org>
Message-ID: <47D13F07.9080308@netphreax.net>

Chris Turner wrote:
1) does anyone have ACPI (instead of APM)
   sleep / suspend / wakeup working on Dfly ?
2) If so, what machines are being used ?
3) Same question for other BSDs - my understanding is NetBSD is most
   'advanced' w/r/t power managment - but I'm not 100% on this ...
would looove to have a sleeping / resuming / scaling laptop running some 
BSD flavor.. am willing to work towards that end, esp. w/r/t Dfly -
trying to chart a course to figguring this out.
I have ACPI S3 suspend working like a charm on my IBM ThinkPad R40 
(Pentium M "Banias" 1.3GHz, speedstepping works just fine), running 
NetBSD 3.99.21.
--
        Thomas E. Spanjaard
        tgen at netphreax.net
Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00004.pgp
Type: application/octet-stream
Size: 186 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080307/de3e5104/attachment-0018.obj>

From civilizd at gmail.com  Fri Mar  7 09:06:41 2008
From: civilizd at gmail.com (Vita "CiV" Cizek)
Date: Fri, 7 Mar 2008 09:06:41 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <98d564710803070853q1c73d795m6e6c5cc5049fa099@mail.gmail.com>

>  Any student volunteers?  We have mentors.
>
I am interested too, especially in some kernel-related work.




From justin at shiningsilence.com  Sat Mar  8 12:07:51 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Sat, 8 Mar 2008 12:07:51 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google SoC 2008 - mentors mentors mentors
Message-ID: <51558.192.168.0.252.1205006403.squirrel@www.shiningsilence.com>

If you are willing to mentor for the Google 2008 Summer of Code, please
speak up.  Right now we have: (from our wiki page)

Matthias
Sephe
TGEN
corecode

Part of the application process includes naming people as mentors (student
applications come later), so I want to get as complete a list as possible.

The application is due on the 12th, so if you want to mentor, now's the
time to say so.

Google's SoC FAQ is here: http://code.google.com/soc/2008/faqs.html

Our wiki page is here: http://wiki.dragonflybsd.org/index.cgi/GoogleSoC2008

- much credit to Matthias and others for getting that set up.





From saw at online.de  Sat Mar  8 14:26:07 2008
From: saw at online.de (Sascha Wildner)
Date: Sat, 08 Mar 2008 23:26:07 +0100
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <47d31245$0$848$415eb37d@crater_reader.dragonflybsd.org>

Sascha Wildner wrote:
Hi all,

this is probably as good a moment as any to come out of the forest with 
this. The patch at

http://leaf.dragonflybsd.org/~swildner/nrelease_gui.diff
Ok, I have committed the stuff as an example.

I'm not sure if my free time permits to work on a full-blown live CD 
with X11 and other good things (I already feel my interest wandering off 
in other directions) so if anyone wants to pick up the ball, go ahead. :)

Sascha

--
http://yoyodyne.ath.cx



From qhwt+dfly at les.ath.cx  Tue Mar 11 22:21:31 2008
From: qhwt+dfly at les.ath.cx (YONETANI Tomokazu)
Date: Tue, 11 Mar 2008 22:21:31 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Misc. ACPI / suspend
In-Reply-To: <47CA073B.6020106@199technologies.org>
Message-ID: <20080312051219.GA56091@les.ath.cx>

On Thu, Mar 06, 2008 at 10:03:21PM -0500, Chris Turner wrote:
> 1) does anyone have ACPI (instead of APM)
>    sleep / suspend / wakeup working on Dfly ?
> 2) If so, what machines are being used ?

Dynabook SS3500 (http://www.tlt.co.jp/pc/catalog/ss/02110735/index_j.htm).
It's old and can get very hot(thus frequently turns on the cooling fan)
even when it's running Windows.  I haven't turned it on for about several
months though.

Cheers.




From c.turner at 199technologies.org  Wed Mar 12 04:37:22 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Wed, 12 Mar 2008 04:37:22 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Misc. ACPI / suspend
In-Reply-To: <47CA073B.6020106@199technologies.org>
Message-ID: <47D7BEE3.6010907@199technologies.org>

YONETANI Tomokazu wrote:
On Thu, Mar 06, 2008 at 10:03:21PM -0500, Chris Turner wrote:
1) does anyone have ACPI (instead of APM)
   sleep / suspend / wakeup working on Dfly ?
Cheers.
ditto..

Suppose this should go to docs@ - in any case..

Thinking about setting up a wiki page on the issue so we
can discuss / track what 'good' hardware / drivers / implementations / 
etc are 'out there' - anyone have any suggestions on where this should
go?

http://wiki.dragonflybsd.org/index.cgi/acpi-overview.html

Remains from the handbook conversion - but I'm hesitant to 'over wikify'
this ..



From c.turner at 199technologies.org  Wed Mar 12 15:36:52 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Wed, 12 Mar 2008 15:36:52 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: devel/cscope
Message-ID: <47D85A08.8040103@199technologies.org>

why oh why did I take so long to try this out !!!

just sharing my eureka moment with the list..

- Chris




From dudu at dudu.ro  Wed Mar 12 15:50:14 2008
From: dudu at dudu.ro (Vlad GALU)
Date: Wed, 12 Mar 2008 15:50:14 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: devel/cscope
In-Reply-To: <47D85A08.8040103@199technologies.org>
Message-ID: <ad79ad6b0803121547r2bf67ffep9e40badaac6490f8@mail.gmail.com>

On 3/13/08, Chris Turner <c.turner at 199technologies.org> wrote:
> why oh why did I take so long to try this out !!!
>
>  just sharing my eureka moment with the list..


    Works nice with vim, too!

>
>
>  - Chris
>


-- 
Mahnahmahnah!




From justin at shiningsilence.com  Sun Mar 16 21:06:13 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Sun, 16 Mar 2008 21:06:13 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: binary packages for 1.12 coming in
Message-ID: <1372.192.168.0.252.1205726088.squirrel@www.shiningsilence.com>

The binary build for 1.12 is taking quite a while.  I've started copying
in newly built packages to
pkgbox.dragonflybsd.org/packages/DragonFly-1.12/i386/ - this should be
getting copied out to mirrors over the next while.

There are currently 1283 packages built, which leaves a whole lot to go;
I'll copy new packages in as they complete.





From hasso at estpak.ee  Wed Mar 19 04:31:08 2008
From: hasso at estpak.ee (Hasso Tepper)
Date: Wed, 19 Mar 2008 04:31:08 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Some questions regarding ACPI
Message-ID: <200803191322.46366.hasso@estpak.ee>

I'm working on bringing in some laptop (and especially thinkpad) specific 
ACPI code from FreeBSD into DragonFly. I never touched ACPI stuff before 
and haven't followed it much either, so I have some questions.

* FreeBSD uses ACPI_SERIAL_* heavily. What's the locking situation in 
  DragonFly and why?

* As far as I can see, PCI integration is commented out in DragonFly. 
  What's the state of it and why?

* platform/pc32/acpica5/acpi_toshiba.c - why is it there? I don't think 
  that this is something pc32 specific in it and it should work in pc64 
  laptops as well. Any objections to move it into 
  dev/acpica5/acpi_toshiba/ ?

What's the current status of ACPI in general? AFAICS our acpica is quite 
old - what needs to be done to bring in newer one?


-- 
Hasso




From qhwt+dfly at les.ath.cx  Wed Mar 19 09:24:50 2008
From: qhwt+dfly at les.ath.cx (YONETANI Tomokazu)
Date: Wed, 19 Mar 2008 09:24:50 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Some questions regarding ACPI
In-Reply-To: <200803191322.46366.hasso@estpak.ee>
Message-ID: <20080319161703.GA51509@les.ath.cx>

On Wed, Mar 19, 2008 at 01:22:46PM +0200, Hasso Tepper wrote:
> I'm working on bringing in some laptop (and especially thinkpad) specific 
> ACPI code from FreeBSD into DragonFly. I never touched ACPI stuff before 
> and haven't followed it much either, so I have some questions.

So you want to port some of ACPI support drivers, or to do a fresh port
of ACPI driver from FreeBSD?

> * FreeBSD uses ACPI_SERIAL_* heavily. What's the locking situation in 
>   DragonFly and why?

The current ACPI driver in DragonFly is based on that of FreeBSD as of
end of June, 2004, plus some fixes brought in later (and ACPICA part
has been updated twice since then).  That was before they introduced
the MPSAFE changes into ACPI code, and we use critical section
(crit_{enter,exit}) in most places (and lockmgr lock in a few place).

> * As far as I can see, PCI integration is commented out in DragonFly. 
>   What's the state of it and why?

When we replaced the implementation taken from FreeBSD 4.x with that
brought from FreeBSD 5.x, which added the PCI part, many people
experienced problems until they turned off ACPI completely, or add "pci"
to "debug.acpi.disabled" loader variable.  AFAIK the PCI part in the ACPI
driver almost hasn't been adjusted to work with our version of PCI code.

> * platform/pc32/acpica5/acpi_toshiba.c - why is it there? I don't think 
>   that this is something pc32 specific in it and it should work in pc64 
>   laptops as well. Any objections to move it into 
>   dev/acpica5/acpi_toshiba/ ?

In FreeBSD it used to be sitting at i386/acpica/acpi_toshiba.c and was
later moved into acpi_support.  That change hasn't hit our tree (in fact,
we have no acpi support drivers other than that).  It seems that FreeBSD
has them in dev/acpi_support now, and we for some reason have that
directory in our CVS repository (but containing no files in it).

> What's the current status of ACPI in general? AFAICS our acpica is quite 
> old - what needs to be done to bring in newer one?

Actually, it's not very important to keep just ACPICA latest, but
if you bring the ACPI driver from FreeBSD you need to bring ACPICA code
that matches their version, and it IS important.  And it generally requires
you much work to just update ACPICA part anyway because of how they
change things on every release.

Cheers.




From hasso at estpak.ee  Wed Mar 19 12:29:52 2008
From: hasso at estpak.ee (Hasso Tepper)
Date: Wed, 19 Mar 2008 12:29:52 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Some questions regarding ACPI
In-Reply-To: <200803191322.46366.hasso@estpak.ee>
Message-ID: <200803192115.35396.hasso@estpak.ee>

YONETANI Tomokazu wrote:
> On Wed, Mar 19, 2008 at 01:22:46PM +0200, Hasso Tepper wrote:
> > I'm working on bringing in some laptop (and especially thinkpad)
> > specific ACPI code from FreeBSD into DragonFly. I never touched ACPI
> > stuff before and haven't followed it much either, so I have some
> > questions.
>
> So you want to port some of ACPI support drivers, or to do a fresh port
> of ACPI driver from FreeBSD?

I'm only interested in support drivers and the reason is pure practical - 
newer thinkpads handle less and less hotkeys etc in hardware and require 
support form OS. acpi_ibm and acpi_video are examples of such modules 
which would help a lot of these newer thinkpad users.

acpi_ibm is almost ready to commit (renamed to acpi_thinkpad though).

> > * FreeBSD uses ACPI_SERIAL_* heavily. What's the locking situation in
> >   DragonFly and why?
>
> The current ACPI driver in DragonFly is based on that of FreeBSD as of
> end of June, 2004, plus some fixes brought in later (and ACPICA part
> has been updated twice since then).  That was before they introduced
> the MPSAFE changes into ACPI code, and we use critical section
> (crit_{enter,exit}) in most places (and lockmgr lock in a few place).

Mkay. Will look at more closely.

> > * As far as I can see, PCI integration is commented out in DragonFly.
> >   What's the state of it and why?
>
> When we replaced the implementation taken from FreeBSD 4.x with that
> brought from FreeBSD 5.x, which added the PCI part, many people
> experienced problems until they turned off ACPI completely, or add
> "pci" to "debug.acpi.disabled" loader variable.  AFAIK the PCI part in
> the ACPI driver almost hasn't been adjusted to work with our version of
> PCI code.

I'm afraid that it's beyond my skills, but while looking at acpi_video I 
discovered that it's hard to handle correctly without PCI support.

> > * platform/pc32/acpica5/acpi_toshiba.c - why is it there? I don't
> > think that this is something pc32 specific in it and it should work
> > in pc64 laptops as well. Any objections to move it into
> >   dev/acpica5/acpi_toshiba/ ?
>
> In FreeBSD it used to be sitting at i386/acpica/acpi_toshiba.c and was
> later moved into acpi_support.  That change hasn't hit our tree (in
> fact, we have no acpi support drivers other than that).  It seems that
> FreeBSD has them in dev/acpi_support now, and we for some reason have
> that directory in our CVS repository (but containing no files in it).

I don't see it ;). Makes sense though. So, any objections if I move 
acpi_toshiba into sys/dev/acpi_support and add new acpi_thinkpad there as 
well? 

> > What's the current status of ACPI in general? AFAICS our acpica is
> > quite old - what needs to be done to bring in newer one?
>
> Actually, it's not very important to keep just ACPICA latest, but
> if you bring the ACPI driver from FreeBSD you need to bring ACPICA code
> that matches their version, and it IS important.  And it generally
> requires you much work to just update ACPICA part anyway because of how
> they change things on every release.

Someone else has to do it :).

Thanks for info.


-- 
Hasso




From dillon at apollo.backplane.com  Wed Mar 19 14:01:13 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Wed, 19 Mar 2008 14:01:13 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: panic: assertion: hammer_btree_cmp(cursor->left_bound,	&cursor->node->ondisk->elms[0].leaf.base) <= 0 in btree_split_leaf
In-Reply-To: <200802232204.m1NM4cxd046264@apollo.backplane.com>
Message-ID: <200803192054.m2JKsjwn045137@apollo.backplane.com>


:Hi.
:While trying to find a procedure to reliably reproduce the panic
:I reported last time, I caught a different panic (uploaded at
: ~y0netan1/crash/9/ on my leaf account).  I wrote the following shell
:script (make sure to edit variables DISKS and MOUNTPT before using this
:script or it may trash your system):
:  #!/bin/sh -ex
:  DISKS="/dev/ad0s1f"
:  MOUNTPT=/mnt/HAMMER
:
:  cd /
:  newfs_hammer -L TEST $DISKS
:  for i in `seq 1 100`; do
:..
:And the panic is triggered by rm command.
:I'll try to see if it's possible to reproduce the last one without
:unmounting then mounting the HAMMER fs.
:
:Cheers.

    I believe I have fixed this panic.  hammer_make_separator() had a bug
    in it.

    There is still an issue with the node ref count on umount.

    Please continue to life-test the code.  The reblocking code
    (hammer reblock /mnt) should work now, as should the pruning code
    (e.g. hammer prune /mnt everything).

    The filesystem full case is still not handled and will cause bad things
    to happen.  The undo code isn't finished yet either but it is getting
    there (it's writing stuff out but not setting the sequence number and
    not trying to recover-on-mount yet).

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From qhwt+dfly at les.ath.cx  Wed Mar 19 19:45:40 2008
From: qhwt+dfly at les.ath.cx (YONETANI Tomokazu)
Date: Wed, 19 Mar 2008 19:45:40 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Some questions regarding ACPI
In-Reply-To: <200803191322.46366.hasso@estpak.ee>
Message-ID: <20080320023828.GA53648@les.ath.cx>

On Wed, Mar 19, 2008 at 09:15:35PM +0200, Hasso Tepper wrote:
> YONETANI Tomokazu wrote:
> > On Wed, Mar 19, 2008 at 01:22:46PM +0200, Hasso Tepper wrote:
> > > I'm working on bringing in some laptop (and especially thinkpad)
> > > specific ACPI code from FreeBSD into DragonFly. I never touched ACPI
> > > stuff before and haven't followed it much either, so I have some
> > > questions.
> >
> > So you want to port some of ACPI support drivers, or to do a fresh port
> > of ACPI driver from FreeBSD?
> 
> I'm only interested in support drivers and the reason is pure practical - 
> newer thinkpads handle less and less hotkeys etc in hardware and require 
> support form OS. acpi_ibm and acpi_video are examples of such modules 
> which would help a lot of these newer thinkpad users.
> 
> acpi_ibm is almost ready to commit (renamed to acpi_thinkpad though).

Ah, that's a good news!  My only concern is that ISTR someone mentioned
me that his colleague was thinking about porting ACPI driver itself,
so if you're not the person you may want to collaborate with him/her
so as not to waste the effort or time...

			:

> > In FreeBSD it used to be sitting at i386/acpica/acpi_toshiba.c and was
> > later moved into acpi_support.  That change hasn't hit our tree (in
> > fact, we have no acpi support drivers other than that).  It seems that
> > FreeBSD has them in dev/acpi_support now, and we for some reason have
> > that directory in our CVS repository (but containing no files in it).
> 
> I don't see it ;). Makes sense though. So, any objections if I move 
> acpi_toshiba into sys/dev/acpi_support and add new acpi_thinkpad there as 
> well? 

Sorry, I checked the CVS repository and it doesn't exist actually :)
I don't have any objection to moving it there.

Cheers.




From hasso at estpak.ee  Thu Mar 20 00:14:05 2008
From: hasso at estpak.ee (Hasso Tepper)
Date: Thu, 20 Mar 2008 00:14:05 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Some questions regarding ACPI
In-Reply-To: <200803191322.46366.hasso@estpak.ee>
Message-ID: <200803200904.50875.hasso@estpak.ee>

YONETANI Tomokazu wrote:
> On Wed, Mar 19, 2008 at 09:15:35PM +0200, Hasso Tepper wrote:
> > acpi_ibm is almost ready to commit (renamed to acpi_thinkpad though).
>
> Ah, that's a good news!  My only concern is that ISTR someone mentioned
> me that his colleague was thinking about porting ACPI driver itself,
> so if you're not the person you may want to collaborate with him/her
> so as not to waste the effort or time...

Current state in my repo is attached. It should work on 1.12 as well as it 
doesn't depend yet on moving stuff around.

add-acpi-if-m.patch adds some new stuff to the ACPI code to access 
embedded controllers and match ACPI devices by ID. Not sure how, where 
and whether at all these should be documented.

add-acpi-thinkpad.patch is the driver itself. Note that some stuff doesn't 
work yet on newer thinkpads, I plan to work on it later.

There is still some things to do though. I have to decide what to do with 
led(4) part and with locking. There is also one fatal issue - laptop 
locks up hardly (no panic) while unloading module. Any idea regarding 
this is welcome. And of course test results :).


-- 
Hasso
# HG changeset patch
# User Hasso Tepper <hasso at estpak.ee>
# Date 1205919290 -7200
# Branch HEAD
# Node ID 5a6e2705cc95a340abf973ae5df73ef34e070b79
# Parent  cd529e2e7f849034d5d5a0973cb98af50db0e797
imported patch adding-acpi-if-m.patch

diff --git a/sys/conf/files b/sys/conf/files
--- a/sys/conf/files
+++ b/sys/conf/files
@@ -1387,6 +1387,7 @@ emulation/dragonfly12/dfbsd12_stat.c	non
 ${OSACPI_MI_DIR}/acpi_cmbat.c		optional acpi
 ${OSACPI_MI_DIR}/acpi_cpu.c		optional acpi
 ${OSACPI_MI_DIR}/acpi_ec.c		optional acpi
+${OSACPI_MI_DIR}/acpi_if.m		optional acpi
 ${OSACPI_MI_DIR}/acpi_isab.c		optional acpi isa
 ${OSACPI_MI_DIR}/acpi_lid.c		optional acpi
 ${OSACPI_MI_DIR}/acpi_package.c		optional acpi
diff --git a/sys/conf/kmod.mk b/sys/conf/kmod.mk
--- a/sys/conf/kmod.mk
+++ b/sys/conf/kmod.mk
@@ -275,7 +275,7 @@ MFILES?= kern/bus_if.m kern/device_if.m 
     bus/pccard/card_if.m bus/pccard/power_if.m bus/pci/pci_if.m \
     bus/pci/pcib_if.m \
     bus/ppbus/ppbus_if.m bus/smbus/smbus_if.m bus/usb/usb_if.m \
-    dev/disk/nata/ata_if.m \
+    dev/acpica5/acpi_if.m dev/disk/nata/ata_if.m \
     dev/sound/pcm/ac97_if.m dev/sound/pcm/channel_if.m \
     dev/sound/pcm/feeder_if.m dev/sound/pcm/mixer_if.m \
     libiconv/iconv_converter_if.m dev/agp/agp_if.m opencrypto/crypto_if.m
diff --git a/sys/dev/acpica5/Makefile b/sys/dev/acpica5/Makefile
--- a/sys/dev/acpica5/Makefile
+++ b/sys/dev/acpica5/Makefile
@@ -69,12 +69,14 @@ SRCS+=  acpi_package.c
 # SRCS+=	acpi_pci.c acpi_pcib.c acpi_pcib_acpi.c acpi_pcib_pci.c
 # SRCS+=	acpi_pci_link.c
 SRCS+=  acpi_powerres.c acpi_resource.c acpi_thermal.c
-SRCS+=  acpi_timer.c
+SRCS+=  acpi_timer.c acpi_if.c
 SRCS+=  OsdDebug.c
 SRCS+=  OsdHardware.c OsdInterface.c OsdInterrupt.c OsdMemory.c OsdSchedule.c
 SRCS+=  OsdStream.c OsdSynch.c OsdTable.c OsdEnvironment.c
 SRCS+=  opt_acpi.h opt_bus.h opt_ddb.h
-SRCS+=  device_if.h bus_if.h pci_if.h pcib_if.h isa_if.h
+SRCS+=  device_if.h bus_if.h pci_if.h pcib_if.h isa_if.h acpi_if.h
+MFILES = kern/device_if.m kern/bus_if.m bus/pci/pci_if.m bus/pci/pcib_if.m
+MFILES+= bus/isa/isa_if.m dev/acpica5/acpi_if.m
 
 # Debugging support
 DBSRC=	dbcmds.c dbdisply.c dbexec.c dbfileio.c dbhistry.c
diff --git a/sys/dev/acpica5/acpi.c b/sys/dev/acpica5/acpi.c
--- a/sys/dev/acpica5/acpi.c
+++ b/sys/dev/acpica5/acpi.c
@@ -135,6 +135,7 @@ static int	acpi_release_resource(device_
 			int rid, struct resource *r);
 static uint32_t	acpi_isa_get_logicalid(device_t dev);
 static int	acpi_isa_get_compatid(device_t dev, uint32_t *cids, int count);
+static char	*acpi_device_id_probe(device_t bus, device_t dev, char **ids);
 static int	acpi_isa_pnp_probe(device_t bus, device_t child,
 			struct isa_pnp_id *ids);
 static void	acpi_probe_children(device_t bus);
@@ -189,6 +190,9 @@ static device_method_t acpi_methods[] = 
     DEVMETHOD(bus_deactivate_resource,	bus_generic_deactivate_resource),
     DEVMETHOD(bus_setup_intr,		bus_generic_setup_intr),
     DEVMETHOD(bus_teardown_intr,	bus_generic_teardown_intr),
+
+    /* ACPI bus */
+    DEVMETHOD(acpi_id_probe,		acpi_device_id_probe),
 
     /* ISA emulation */
     DEVMETHOD(isa_pnp_probe,		acpi_isa_pnp_probe),
@@ -1121,6 +1125,24 @@ out:
 	AcpiOsFree(buf.Pointer);
     ACPI_UNLOCK;
     return_VALUE (valid);
+}
+
+static char *
+acpi_device_id_probe(device_t bus, device_t dev, char **ids) 
+{
+    ACPI_HANDLE h;
+    int i;
+
+    h = acpi_get_handle(dev);
+    if (ids == NULL || h == NULL || acpi_get_type(dev) != ACPI_TYPE_DEVICE)
+	return (NULL);
+
+    /* Try to match one of the array of IDs with a HID or CID. */
+    for (i = 0; ids[i] != NULL; i++) {
+	if (acpi_MatchHid(h, ids[i]))
+	    return (ids[i]);
+    }
+    return (NULL);
 }
 
 static int
diff --git a/sys/dev/acpica5/acpi_ec.c b/sys/dev/acpica5/acpi_ec.c
--- a/sys/dev/acpica5/acpi_ec.c
+++ b/sys/dev/acpica5/acpi_ec.c
@@ -327,11 +327,19 @@ static ACPI_STATUS	EcWrite(struct acpi_e
 				UINT8 *Data);
 static int		acpi_ec_probe(device_t dev);
 static int		acpi_ec_attach(device_t dev);
+static int		acpi_ec_read_method(device_t dev, u_int addr,
+				ACPI_INTEGER *val, int width);
+static int		acpi_ec_write_method(device_t dev, u_int addr,
+				ACPI_INTEGER val, int width);
 
 static device_method_t acpi_ec_methods[] = {
     /* Device interface */
     DEVMETHOD(device_probe,	acpi_ec_probe),
     DEVMETHOD(device_attach,	acpi_ec_attach),
+
+    /* Embedded controller interface */
+    DEVMETHOD(acpi_ec_read,     acpi_ec_read_method),
+    DEVMETHOD(acpi_ec_write,    acpi_ec_write_method),
 
     {0, 0}
 };
@@ -620,6 +628,33 @@ error:
 			     sc->ec_data_res);
     /* mtx_destroy(&sc->ec_mtx); */
     return (ENXIO);
+}
+
+/* Methods to allow other devices (e.g., smbat) to read/write EC space. */
+static int
+acpi_ec_read_method(device_t dev, u_int addr, ACPI_INTEGER *val, int width)
+{
+    struct acpi_ec_softc *sc;
+    ACPI_STATUS status;
+
+    sc = device_get_softc(dev);
+    status = EcSpaceHandler(ACPI_READ, addr, width * 8, val, sc, NULL);
+    if (ACPI_FAILURE(status))
+        return (ENXIO);
+    return (0);
+}
+
+static int
+acpi_ec_write_method(device_t dev, u_int addr, ACPI_INTEGER val, int width)
+{
+    struct acpi_ec_softc *sc;
+    ACPI_STATUS status;
+
+    sc = device_get_softc(dev);
+    status = EcSpaceHandler(ACPI_WRITE, addr, width * 8, &val, sc, NULL);
+    if (ACPI_FAILURE(status))
+        return (ENXIO);
+    return (0);
 }
 
 static void
diff --git a/sys/dev/acpica5/acpi_if.m b/sys/dev/acpica5/acpi_if.m
new file mode 100644
--- /dev/null
+++ b/sys/dev/acpica5/acpi_if.m
@@ -0,0 +1,92 @@
+#-
+# Copyright (c) 2004 Nate Lawson
+# All rights reserved.
+#
+# Redistribution and use in source and binary forms, with or without
+# modification, are permitted provided that the following conditions
+# are met:
+# 1. Redistributions of source code must retain the above copyright
+#    notice, this list of conditions and the following disclaimer.
+# 2. Redistributions in binary form must reproduce the above copyright
+#    notice, this list of conditions and the following disclaimer in the
+#    documentation and/or other materials provided with the distribution.
+#
+# THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
+# ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+# ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
+# FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+# DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+# OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+# HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+# LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+# OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+# SUCH DAMAGE.
+#
+# $DragonFly$
+#
+
+#include <sys/bus.h>
+#include <sys/types.h>
+#include "acpi.h"
+
+INTERFACE acpi;
+
+#
+# Default implementation for acpi_id_probe().
+#
+CODE {
+	static char *
+	acpi_generic_id_probe(device_t bus, device_t dev, char **ids)
+	{
+		return (NULL);
+	}
+};
+
+#
+# Check a device for a match in a list of ID strings.  The strings can be
+# EISA PNP IDs or ACPI _HID/_CID values.
+#
+# device_t bus:  parent bus for the device
+#
+# device_t dev:  device being considered
+#
+# char **ids:  array of ID strings to consider
+#
+# Returns:  ID string matched or NULL if no match
+#
+METHOD char * id_probe {
+	device_t	bus;
+	device_t	dev;
+	char		**ids;
+} DEFAULT acpi_generic_id_probe;
+
+#
+# Read embedded controller (EC) address space
+#
+# device_t dev:  EC device
+# u_int addr:  Address to read from in EC space
+# ACPI_INTEGER *val:  Location to store read value
+# int width:  Size of area to read in bytes
+#
+METHOD int ec_read {
+	device_t	dev;
+	u_int		addr;
+	ACPI_INTEGER	*val;
+	int		width;
+};
+
+#
+# Write embedded controller (EC) address space
+#
+# device_t dev:  EC device
+# u_int addr:  Address to write to in EC space
+# ACPI_INTEGER val:  Value to write
+# int width:  Size of value to write in bytes
+#
+METHOD int ec_write {
+	device_t	dev;
+	u_int		addr;
+	ACPI_INTEGER	val;
+	int		width;
+};
diff --git a/sys/dev/acpica5/acpivar.h b/sys/dev/acpica5/acpivar.h
--- a/sys/dev/acpica5/acpivar.h
+++ b/sys/dev/acpica5/acpivar.h
@@ -29,6 +29,7 @@
  * $DragonFly: src/sys/dev/acpica5/acpivar.h,v 1.12 2007/10/23 03:04:48 y0netan1 Exp $
  */
 
+#include "acpi_if.h"
 #include "bus_if.h"
 #include <sys/eventhandler.h>
 #include <sys/sysctl.h>
# HG changeset patch
# User Hasso Tepper <hasso at estpak.ee>
# Date 1205995474 -7200
# Branch HEAD
# Node ID c5db8d4a7c6b25a8576a8d42c5029aaf0e23bfb6
# Parent  5a6e2705cc95a340abf973ae5df73ef34e070b79
[mq]: adding-acpi-thinkpad.patch

diff --git a/sys/dev/acpica5/Makefile b/sys/dev/acpica5/Makefile
--- a/sys/dev/acpica5/Makefile
+++ b/sys/dev/acpica5/Makefile
@@ -117,7 +117,7 @@ acpi_wakecode.h: acpi_wakecode.S
 	${MAKE} -f ${SYSDIR}/${OSACPI_MD_DIR}/Makefile \
 		MAKESRCPATH=${SYSDIR}/${OSACPI_MD_DIR}
 
-SUBDIR=	acpi_toshiba
+SUBDIR=	acpi_toshiba acpi_thinkpad
 all: ${PROG} ${SUBDIR}
 
 # *.o file for each patched *.c file is created under the same directory,
diff --git a/sys/dev/acpica5/acpi_thinkpad/Makefile b/sys/dev/acpica5/acpi_thinkpad/Makefile
new file mode 100644
--- /dev/null
+++ b/sys/dev/acpica5/acpi_thinkpad/Makefile
@@ -0,0 +1,9 @@
+# $DragonFly$
+
+SYSDIR?=${.CURDIR}/../../..
+
+KMOD=		acpi_thinkpad
+CFLAGS+=	-I${.OBJDIR}/.. -I${.CURDIR}/..
+SRCS=		acpi_thinkpad.c opt_acpi.h device_if.h bus_if.h
+
+.include <bsd.kmod.mk>
diff --git a/sys/dev/acpica5/acpi_thinkpad/acpi_thinkpad.c b/sys/dev/acpica5/acpi_thinkpad/acpi_thinkpad.c
new file mode 100644
--- /dev/null
+++ b/sys/dev/acpica5/acpi_thinkpad/acpi_thinkpad.c
@@ -0,0 +1,1046 @@
+/*
+ * Copyright (c) 2004 Takanori Watanabe
+ * Copyright (c) 2005 Markus Brueffer <markus at FreeBSD.org>
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *    notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *    notice, this list of conditions and the following disclaimer in the
+ *    documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+ */
+
+/*
+ * Driver for extra ACPI-controlled gadgets found on IBM and Lenovo ThinkPad
+ * laptops. Inspired by the ibm-acpi and tpb projects which implement these
+ * features on Linux.
+ *
+ *   acpi-ibm: <http://ibm-acpi.sourceforge.net/>
+ *        tpb: <http://www.nongnu.org/tpb/>
+ */
+
+#include "opt_acpi.h"
+#include <sys/param.h>
+#include <sys/kernel.h>
+#include <sys/bus.h>
+#include <machine/cpufunc.h>
+#include <sys/module.h>
+/* #include <dev/led/led.h> */
+#include <sys/sensors.h>
+#include <sys/sysctl.h>
+#include <machine/clock.h>
+
+#include "acpi.h"
+#include "acpivar.h"
+#include "acpi_if.h"
+
+#define _COMPONENT	ACPI_OEM
+ACPI_MODULE_NAME("THINKPAD")
+
+/* Internal methods */
+#define ACPI_THINKPAD_METHOD_EVENTS		1
+#define ACPI_THINKPAD_METHOD_EVENTMASK		2
+#define ACPI_THINKPAD_METHOD_HOTKEY		3
+#define ACPI_THINKPAD_METHOD_BRIGHTNESS		4
+#define ACPI_THINKPAD_METHOD_VOLUME		5
+#define ACPI_THINKPAD_METHOD_MUTE		6
+#define ACPI_THINKPAD_METHOD_THINKLIGHT		7
+#define ACPI_THINKPAD_METHOD_BLUETOOTH		8
+#define ACPI_THINKPAD_METHOD_WLAN		9
+#define ACPI_THINKPAD_METHOD_FANSPEED		10
+#define ACPI_THINKPAD_METHOD_FANLEVEL		11
+#define ACPI_THINKPAD_METHOD_FANSTATUS		12
+#define ACPI_THINKPAD_METHOD_THERMAL		13
+
+/* Hotkeys/Buttons */
+#define THINKPAD_RTC_HOTKEY1			0x64
+#define   THINKPAD_RTC_MASK_HOME		(1 << 0)
+#define   THINKPAD_RTC_MASK_SEARCH		(1 << 1)
+#define   THINKPAD_RTC_MASK_MAIL		(1 << 2)
+#define   THINKPAD_RTC_MASK_WLAN		(1 << 5)
+#define THINKPAD_RTC_HOTKEY2			0x65
+#define   THINKPAD_RTC_MASK_THINKPAD		(1 << 3)
+#define   THINKPAD_RTC_MASK_ZOOM		(1 << 5)
+#define   THINKPAD_RTC_MASK_VIDEO		(1 << 6)
+#define   THINKPAD_RTC_MASK_HIBERNATE		(1 << 7)
+#define THINKPAD_RTC_THINKLIGHT			0x66
+#define   THINKPAD_RTC_MASK_THINKLIGHT		(1 << 4)
+#define THINKPAD_RTC_SCREENEXPAND		0x67
+#define   THINKPAD_RTC_MASK_SCREENEXPAND	(1 << 5)
+#define THINKPAD_RTC_BRIGHTNESS			0x6c
+#define   THINKPAD_RTC_MASK_BRIGHTNESS		(1 << 5)
+#define THINKPAD_RTC_VOLUME			0x6e
+#define   THINKPAD_RTC_MASK_VOLUME		(1 << 7)
+
+/* Embedded Controller registers */
+#define THINKPAD_EC_BRIGHTNESS			0x31
+#define   THINKPAD_EC_MASK_BRI			0x7
+#define THINKPAD_EC_VOLUME			0x30
+#define   THINKPAD_EC_MASK_VOL			0xf
+#define   THINKPAD_EC_MASK_MUTE			(1 << 6)
+#define THINKPAD_EC_FANSTATUS			0x2F
+#define   THINKPAD_EC_MASK_FANLEVEL		0x3f
+#define   THINKPAD_EC_MASK_FANDISENGAGED	(1 << 6)
+#define   THINKPAD_EC_MASK_FANSTATUS		(1 << 7)
+#define THINKPAD_EC_FANSPEED			0x84
+
+/* CMOS Commands */
+#define THINKPAD_CMOS_VOLUME_DOWN		0
+#define THINKPAD_CMOS_VOLUME_UP			1
+#define THINKPAD_CMOS_VOLUME_MUTE		2
+#define THINKPAD_CMOS_BRIGHTNESS_UP		4
+#define THINKPAD_CMOS_BRIGHTNESS_DOWN		5
+
+/* ACPI methods */
+#define THINKPAD_NAME_KEYLIGHT			"KBLT"
+#define THINKPAD_NAME_WLAN_BT_GET		"GBDC"
+#define THINKPAD_NAME_WLAN_BT_SET		"SBDC"
+#define   THINKPAD_NAME_MASK_BT			(1 << 1)
+#define   THINKPAD_NAME_MASK_WLAN		(1 << 2)
+#define THINKPAD_NAME_THERMAL_GET		"TMP7"
+#define THINKPAD_NAME_THERMAL_UPDT		"UPDT"
+
+#define THINKPAD_NAME_EVENTS_STATUS_GET		"DHKC"
+#define THINKPAD_NAME_EVENTS_MASK_GET		"DHKN"
+#define THINKPAD_NAME_EVENTS_STATUS_SET		"MHKC"
+#define THINKPAD_NAME_EVENTS_MASK_SET		"MHKM"
+#define THINKPAD_NAME_EVENTS_GET		"MHKP"
+#define THINKPAD_NAME_EVENTS_AVAILMASK		"MHKA"
+
+#define ABS(x) (((x) < 0)? -(x) : (x))
+
+struct acpi_thinkpad_softc {
+	device_t	dev;
+	ACPI_HANDLE	handle;
+
+	/* Embedded controller */
+	device_t	ec_dev;
+	ACPI_HANDLE	ec_handle;
+
+	/* CMOS */
+	ACPI_HANDLE	cmos_handle;
+
+	/* Fan status */
+	ACPI_HANDLE	fan_handle;
+	int		fan_levels;
+
+	/* Keylight commands and states */
+	ACPI_HANDLE	light_handle;
+	int		light_cmd_on;
+	int		light_cmd_off;
+	int		light_val;
+	int		light_get_supported;
+	int		light_set_supported;
+
+	/* led(4) interface */
+	struct cdev	*led_dev;
+	int		led_busy;
+	int		led_state;
+
+	int		wlan_bt_flags;
+	int		thermal_updt_supported;
+
+	unsigned int	events_availmask;
+	unsigned int	events_initialmask;
+	int		events_mask_supported;
+	int		events_enable;
+
+	/* sensors(9) related */
+	struct ksensordev sensordev;
+	struct ksensor sensors[9];	/* XXX: 8 thermal + fan */
+
+	struct sysctl_ctx_list	*sysctl_ctx;
+	struct sysctl_oid	*sysctl_tree;
+};
+
+static struct {
+	char	*name;
+	int	method;
+	char	*description;
+	int	access;
+} acpi_thinkpad_sysctls[] = {
+	{
+		.name		= "events",
+		.method		= ACPI_THINKPAD_METHOD_EVENTS,
+		.description	= "ACPI events enable",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "eventmask",
+		.method		= ACPI_THINKPAD_METHOD_EVENTMASK,
+		.description	= "ACPI eventmask",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "hotkey",
+		.method		= ACPI_THINKPAD_METHOD_HOTKEY,
+		.description	= "Key Status",
+		.access		= CTLTYPE_INT | CTLFLAG_RD
+	},
+	{
+		.name		= "lcd_brightness",
+		.method		= ACPI_THINKPAD_METHOD_BRIGHTNESS,
+		.description	= "LCD Brightness",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "volume",
+		.method		= ACPI_THINKPAD_METHOD_VOLUME,
+		.description	= "Volume",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "mute",
+		.method		= ACPI_THINKPAD_METHOD_MUTE,
+		.description	= "Mute",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "thinklight",
+		.method		= ACPI_THINKPAD_METHOD_THINKLIGHT,
+		.description	= "Thinklight enable",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "bluetooth",
+		.method		= ACPI_THINKPAD_METHOD_BLUETOOTH,
+		.description	= "Bluetooth enable",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "wlan",
+		.method		= ACPI_THINKPAD_METHOD_WLAN,
+		.description	= "WLAN enable",
+		.access		= CTLTYPE_INT | CTLFLAG_RD
+	},
+	{
+		.name		= "fan_level",
+		.method		= ACPI_THINKPAD_METHOD_FANLEVEL,
+		.description	= "Fan level",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "fan",
+		.method		= ACPI_THINKPAD_METHOD_FANSTATUS,
+		.description	= "Fan enable",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+
+	{ NULL, 0, NULL, 0 }
+};
+
+/* ACPI_SERIAL_DECL(thinkpad, "ACPI THINKPAD extras"); */
+static int	acpi_thinkpad_probe(device_t dev);
+static int	acpi_thinkpad_attach(device_t dev);
+static int	acpi_thinkpad_detach(device_t dev);
+
+#if 0 /* not yet */
+static void	thinkpad_led(void *softc, int onoff);
+static void	thinkpad_led_task(struct acpi_thinkpad_softc *sc,
+		int pending __unused);
+#endif
+
+static int	acpi_thinkpad_sysctl(SYSCTL_HANDLER_ARGS);
+static int	acpi_thinkpad_sysctl_init(struct acpi_thinkpad_softc *sc,
+		int method);
+static int	acpi_thinkpad_sysctl_get(struct acpi_thinkpad_softc *sc,
+		int method);
+static int	acpi_thinkpad_sysctl_set(struct acpi_thinkpad_softc *sc,
+		int method, int val);
+
+static int	acpi_thinkpad_eventmask_set(struct acpi_thinkpad_softc *sc,
+		int val);
+static void	acpi_thinkpad_notify(ACPI_HANDLE h, UINT32 notify,
+		void *context);
+static void	acpi_thinkpad_refresh(void *);
+
+static device_method_t acpi_thinkpad_methods[] = {
+	/* Device interface */
+	DEVMETHOD(device_probe, acpi_thinkpad_probe),
+	DEVMETHOD(device_attach, acpi_thinkpad_attach),
+	DEVMETHOD(device_detach, acpi_thinkpad_detach),
+	{0, 0}
+};
+
+static driver_t	acpi_thinkpad_driver = {
+	"acpi_thinkpad",
+	acpi_thinkpad_methods,
+	sizeof(struct acpi_thinkpad_softc),
+};
+
+static devclass_t acpi_thinkpad_devclass;
+
+DRIVER_MODULE(acpi_thinkpad, acpi, acpi_thinkpad_driver,
+    acpi_thinkpad_devclass, 0, 0);
+MODULE_DEPEND(acpi_thinkpad, acpi, 1, 1, 1);
+static char    *thinkpad_ids[] = {"IBM0068", NULL};
+
+#if 0 /* not yet */
+static void
+thinkpad_led(void *softc, int onoff)
+{
+	struct acpi_thinkpad_softc* sc = (struct acpi_thinkpad_softc*) softc;
+
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+
+	if (sc->led_busy)
+		return;
+
+	sc->led_busy = 1;
+	sc->led_state = onoff;
+
+	AcpiOsExecute(OSL_NOTIFY_HANDLER, (void *)thinkpad_led_task, sc);
+}
+
+static void
+thinkpad_led_task(struct acpi_thinkpad_softc *sc, int pending __unused)
+{
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+
+	/* ACPI_SERIAL_BEGIN(thinkpad); */
+	acpi_thinkpad_sysctl_set(sc, ACPI_THINKPAD_METHOD_THINKLIGHT, sc->led_state);
+	/* ACPI_SERIAL_END(thinkpad); */
+
+	sc->led_busy = 0;
+}
+#endif
+
+static int
+acpi_thinkpad_probe(device_t dev)
+{
+	if (acpi_disabled("thinkpad") ||
+	    ACPI_ID_PROBE(device_get_parent(dev), dev, thinkpad_ids) == NULL ||
+	    device_get_unit(dev) != 0) 
+		return (ENXIO);
+
+	device_set_desc(dev, "IBM/Lenovo ThinkPad ACPI Extras");
+	return (0);
+}
+
+static int
+acpi_thinkpad_attach(device_t dev)
+{
+	struct acpi_thinkpad_softc	*sc;
+	struct acpi_softc	*acpi_sc;
+	devclass_t		ec_devclass;
+	int			i;
+
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t) __func__);
+
+	sc = device_get_softc(dev);
+	sc->dev = dev;
+	sc->handle = acpi_get_handle(dev);
+
+	acpi_sc = acpi_device_get_parent_softc(dev);
+
+	/* Look for the first embedded controller */
+        if (!(ec_devclass = devclass_find ("acpi_ec"))) {
+		if (bootverbose)
+			device_printf(dev, "Couldn't find acpi_ec devclass\n");
+		return (EINVAL);
+	}
+        if (!(sc->ec_dev = devclass_get_device(ec_devclass, 0))) {
+		if (bootverbose)
+			device_printf(dev, "Couldn't find acpi_ec device\n");
+		return (EINVAL);
+	}
+	sc->ec_handle = acpi_get_handle(sc->ec_dev);
+
+	/* ACPI_SERIAL_BEGIN(thinkpad); */
+
+#if 0
+	/* Get the sysctl tree */
+	sc->sysctl_ctx = device_get_sysctl_ctx(dev);
+	sc->sysctl_tree = device_get_sysctl_tree(dev);
+#endif
+	sysctl_ctx_init(sc->sysctl_ctx);
+	sc->sysctl_tree = SYSCTL_ADD_NODE(sc->sysctl_ctx,
+	    SYSCTL_CHILDREN(acpi_sc->acpi_sysctl_tree), OID_AUTO,
+	    "thinkpad", CTLFLAG_RD, 0, "");
+
+	/* Look for event mask and hook up the nodes */
+	sc->events_mask_supported = ACPI_SUCCESS(acpi_GetInteger(sc->handle,
+	    THINKPAD_NAME_EVENTS_MASK_GET, &sc->events_initialmask));
+
+	if (sc->events_mask_supported) {
+		SYSCTL_ADD_INT(sc->sysctl_ctx,
+		    SYSCTL_CHILDREN(sc->sysctl_tree), OID_AUTO,
+		    "initialmask", CTLFLAG_RD,
+		    &sc->events_initialmask, 0, "Initial eventmask");
+
+		/* The availmask is the bitmask of supported events */
+		if (ACPI_FAILURE(acpi_GetInteger(sc->handle,
+		    THINKPAD_NAME_EVENTS_AVAILMASK, &sc->events_availmask)))
+			sc->events_availmask = 0xffffffff;
+
+		SYSCTL_ADD_INT(sc->sysctl_ctx,
+		    SYSCTL_CHILDREN(sc->sysctl_tree), OID_AUTO,
+		    "availmask", CTLFLAG_RD,
+		    &sc->events_availmask, 0, "Mask of supported events");
+	}
+
+	/* Hook up proc nodes */
+	for (i = 0; acpi_thinkpad_sysctls[i].name != NULL; i++) {
+		if (!acpi_thinkpad_sysctl_init(sc,
+		    acpi_thinkpad_sysctls[i].method))
+			continue;
+
+		SYSCTL_ADD_PROC(sc->sysctl_ctx,
+		    SYSCTL_CHILDREN(sc->sysctl_tree), OID_AUTO,
+		    acpi_thinkpad_sysctls[i].name,
+		    acpi_thinkpad_sysctls[i].access,
+		    sc, i, acpi_thinkpad_sysctl, "I",
+		    acpi_thinkpad_sysctls[i].description);
+	}
+
+	/* ACPI_SERIAL_END(thinkpad); */
+
+	/* Handle notifies */
+	AcpiInstallNotifyHandler(sc->handle, ACPI_DEVICE_NOTIFY,
+	    acpi_thinkpad_notify, dev);
+
+#if 0
+	/* Hook up light to led(4) */
+	if (sc->light_set_supported)
+		sc->led_dev = led_create_state(thinkpad_led, sc, "thinklight",
+		    sc->light_val);
+#endif
+	/* Attach sensors(9). */
+	if (sensor_task_register(sc, acpi_thinkpad_refresh, 5)) {
+		device_printf(sc->dev, "unable to register update task\n");
+		return 1;
+	}
+
+	strlcpy(sc->sensordev.xname, device_get_nameunit(sc->dev),
+	    sizeof(sc->sensordev.xname));
+
+	/* XXX: Temp sensors */
+	for (i = 0; i < 8; ++i) {
+		sc->sensors[i].type = SENSOR_TEMP;
+		sensor_attach(&sc->sensordev, &sc->sensors[i]);
+	}
+	
+	/* Fan RPM sensor */
+	sc->sensors[8].type = SENSOR_FANRPM;
+	sensor_attach(&sc->sensordev, &sc->sensors[8]);
+
+	sensordev_install(&sc->sensordev);
+
+	return (0);
+}
+
+static int
+acpi_thinkpad_detach(device_t dev)
+{
+	int i;
+
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t) __func__);
+
+	struct acpi_thinkpad_softc *sc = device_get_softc(dev);
+
+	/* Disable events and restore eventmask */
+	/* ACPI_SERIAL_BEGIN(thinkpad); */
+	acpi_thinkpad_sysctl_set(sc, ACPI_THINKPAD_METHOD_EVENTS, 0);
+	acpi_thinkpad_sysctl_set(sc, ACPI_THINKPAD_METHOD_EVENTMASK,
+	    sc->events_initialmask);
+	/* ACPI_SERIAL_END(thinkpad); */
+
+	AcpiRemoveNotifyHandler(sc->handle, ACPI_DEVICE_NOTIFY,
+	    acpi_thinkpad_notify);
+
+	sysctl_ctx_free(sc->sysctl_ctx);
+
+#if 0
+	if (sc->led_dev != NULL)
+		led_destroy(sc->led_dev);
+#endif
+	sensordev_deinstall(&sc->sensordev);
+	for (i = 0; i < 9; i++)
+		sensor_detach(&sc->sensordev, &sc->sensors[i]);
+	sensor_task_unregister(sc);
+
+	return (0);
+}
+
+static int
+acpi_thinkpad_eventmask_set(struct acpi_thinkpad_softc *sc, int val)
+{
+	int i;
+	ACPI_OBJECT		arg[2];
+	ACPI_OBJECT_LIST	args;
+	ACPI_STATUS		status;
+
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+	/* ACPI_SERIAL_ASSERT(thinkpad); */
+
+	args.Count = 2;
+	args.Pointer = arg;
+	arg[0].Type = ACPI_TYPE_INTEGER;
+	arg[1].Type = ACPI_TYPE_INTEGER;
+
+	for (i = 0; i < 32; ++i) {
+		arg[0].Integer.Value = i+1;
+		arg[1].Integer.Value = (((1 << i) & val) != 0);
+		status = AcpiEvaluateObject(sc->handle,
+		    THINKPAD_NAME_EVENTS_MASK_SET, &args, NULL);
+
+		if (ACPI_FAILURE(status))
+			return (status);
+	}
+
+	return (0);
+}
+
+static int
+acpi_thinkpad_sysctl(SYSCTL_HANDLER_ARGS)
+{
+	struct acpi_thinkpad_softc	*sc;
+	int			arg;
+	int			error = 0;
+	int			function;
+	int			method;
+	
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+
+	sc = (struct acpi_thinkpad_softc *)oidp->oid_arg1;
+	function = oidp->oid_arg2;
+	method = acpi_thinkpad_sysctls[function].method;
+
+	/* ACPI_SERIAL_BEGIN(thinkpad); */
+	arg = acpi_thinkpad_sysctl_get(sc, method);
+	error = sysctl_handle_int(oidp, &arg, 0, req);
+
+	/* Sanity check */
+	if (error != 0 || req->newptr == NULL)
+		goto out;
+
+	/* Update */
+	error = acpi_thinkpad_sysctl_set(sc, method, arg);
+
+out:
+	/* ACPI_SERIAL_END(thinkpad); */
+	return (error);
+}
+
+static int
+acpi_thinkpad_sysctl_get(struct acpi_thinkpad_softc *sc, int method)
+{
+	ACPI_INTEGER	val_ec;
+	int 		val = 0, key;
+
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+	/* ACPI_SERIAL_ASSERT(thinkpad); */
+
+	switch (method) {
+	case ACPI_THINKPAD_METHOD_EVENTS:
+		acpi_GetInteger(sc->handle, THINKPAD_NAME_EVENTS_STATUS_GET,
+		    &val);
+		break;
+
+	case ACPI_THINKPAD_METHOD_EVENTMASK:
+		if (sc->events_mask_supported)
+			acpi_GetInteger(sc->handle,
+			    THINKPAD_NAME_EVENTS_MASK_GET, &val);
+		break;
+
+	case ACPI_THINKPAD_METHOD_HOTKEY:
+		/*
+		 * Construct the hotkey as a bitmask as illustrated below.
+		 * Note that whenever a key was pressed, the respecting bit
+		 * toggles and nothing else changes.
+		 * +--+--+-+-+-+-+-+-+-+-+-+-+
+		 * |11|10|9|8|7|6|5|4|3|2|1|0|
+		 * +--+--+-+-+-+-+-+-+-+-+-+-+
+		 *   |  | | | | | | | | | | |
+		 *   |  | | | | | | | | | | +- Home Button
+		 *   |  | | | | | | | | | +--- Search Button
+		 *   |  | | | | | | | | +----- Mail Button
+		 *   |  | | | | | | | +------- Thinkpad Button
+		 *   |  | | | | | | +--------- Zoom (Fn + Space)
+		 *   |  | | | | | +----------- WLAN Button
+		 *   |  | | | | +------------- Video Button
+		 *   |  | | | +--------------- Hibernate Button
+		 *   |  | | +----------------- Thinklight Button
+		 *   |  | +------------------- Screen expand (Fn + F8)
+		 *   |  +--------------------- Brightness
+		 *   +------------------------ Volume/Mute
+		 */
+		key = rtcin(THINKPAD_RTC_HOTKEY1);
+		val = (THINKPAD_RTC_MASK_HOME | THINKPAD_RTC_MASK_SEARCH |
+		    THINKPAD_RTC_MASK_MAIL | THINKPAD_RTC_MASK_WLAN) & key;
+		key = rtcin(THINKPAD_RTC_HOTKEY2);
+		val |= (THINKPAD_RTC_MASK_THINKPAD | THINKPAD_RTC_MASK_VIDEO |
+		    THINKPAD_RTC_MASK_HIBERNATE) & key;
+		val |= (THINKPAD_RTC_MASK_ZOOM & key) >> 1;
+		key = rtcin(THINKPAD_RTC_THINKLIGHT);
+		val |= (THINKPAD_RTC_MASK_THINKLIGHT & key) << 4;
+		key = rtcin(THINKPAD_RTC_SCREENEXPAND);
+		val |= (THINKPAD_RTC_MASK_THINKLIGHT & key) << 4;
+		key = rtcin(THINKPAD_RTC_BRIGHTNESS);
+		val |= (THINKPAD_RTC_MASK_BRIGHTNESS & key) << 5;
+		key = rtcin(THINKPAD_RTC_VOLUME);
+		val |= (THINKPAD_RTC_MASK_VOLUME & key) << 4;
+		break;
+
+	case ACPI_THINKPAD_METHOD_BRIGHTNESS:
+		ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_BRIGHTNESS, &val_ec, 1);
+		val = val_ec & THINKPAD_EC_MASK_BRI;
+		break;
+
+	case ACPI_THINKPAD_METHOD_VOLUME:
+		ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_VOLUME, &val_ec, 1);
+		val = val_ec & THINKPAD_EC_MASK_VOL;
+		break;
+
+	case ACPI_THINKPAD_METHOD_MUTE:
+		val = ((val_ec & THINKPAD_EC_MASK_MUTE) ==
+		    THINKPAD_EC_MASK_MUTE);
+		break;
+
+	case ACPI_THINKPAD_METHOD_THINKLIGHT:
+		if (sc->light_get_supported)
+			acpi_GetInteger(sc->ec_handle, THINKPAD_NAME_KEYLIGHT,
+			    &val);
+		else
+			val = sc->light_val;
+		break;
+
+	case ACPI_THINKPAD_METHOD_BLUETOOTH:
+		acpi_GetInteger(sc->handle, THINKPAD_NAME_WLAN_BT_GET, &val);
+		sc->wlan_bt_flags = val;
+		val = ((val & THINKPAD_NAME_MASK_BT) != 0);
+		break;
+
+	case ACPI_THINKPAD_METHOD_WLAN:
+		acpi_GetInteger(sc->handle, THINKPAD_NAME_WLAN_BT_GET, &val);
+		sc->wlan_bt_flags = val;
+		val = ((val & THINKPAD_NAME_MASK_WLAN) != 0);
+		break;
+
+	case ACPI_THINKPAD_METHOD_FANSPEED:
+		if (sc->fan_handle) {
+			if (ACPI_FAILURE(acpi_GetInteger(sc->fan_handle,
+			    NULL, &val)))
+				val = -1;
+		}
+		else {
+			ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_FANSPEED,
+			    &val_ec, 2);
+			val = val_ec;
+		}
+		break;
+
+	case ACPI_THINKPAD_METHOD_FANLEVEL:
+		/*
+		 * The THINKPAD_EC_FANSTATUS register works as follows:
+		 * Bit 0-5 indicate the level at which the fan operates. Only
+		 *       values between 0 and 7 have an effect. Everything
+		 *       above 7 is treated the same as level 7
+		 * Bit 6 overrides the fan speed limit if set to 1
+		 * Bit 7 indicates at which mode the fan operates:
+		 *       manual (0) or automatic (1)
+		 */
+		if (!sc->fan_handle) {
+			ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_FANSTATUS,
+			    &val_ec, 1);
+			val = val_ec & THINKPAD_EC_MASK_FANLEVEL;
+		}
+		break;
+
+	case ACPI_THINKPAD_METHOD_FANSTATUS:
+		if (!sc->fan_handle) {
+			ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_FANSTATUS,
+			    &val_ec, 1);
+			val = (val_ec & THINKPAD_EC_MASK_FANSTATUS) ==
+			    THINKPAD_EC_MASK_FANSTATUS;
+		}
+		else
+			val = -1;
+		break;
+	}
+
+	return (val);
+}
+
+static int
+acpi_thinkpad_sysctl_set(struct acpi_thinkpad_softc *sc, int method, int arg)
+{
+	int			val, step, i;
+	ACPI_INTEGER		val_ec;
+	ACPI_OBJECT		Arg;
+	ACPI_OBJECT_LIST	Args;
+	ACPI_STATUS		status;
+
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+	/* ACPI_SERIAL_ASSERT(thinkpad); */
+
+	switch (method) {
+	case ACPI_THINKPAD_METHOD_EVENTS:
+		if (arg < 0 || arg > 1)
+			return (EINVAL);
+
+		status = acpi_SetInteger(sc->handle,
+		    THINKPAD_NAME_EVENTS_STATUS_SET, arg);
+		if (ACPI_FAILURE(status))
+			return (status);
+		if (sc->events_mask_supported)
+			return acpi_thinkpad_eventmask_set(sc,
+			    sc->events_availmask);
+		break;
+
+	case ACPI_THINKPAD_METHOD_EVENTMASK:
+		if (sc->events_mask_supported)
+			return acpi_thinkpad_eventmask_set(sc, arg);
+		break;
+
+	case ACPI_THINKPAD_METHOD_BRIGHTNESS:
+		if (arg < 0 || arg > 7)
+			return (EINVAL);
+
+		if (sc->cmos_handle) {
+			/* Read the current brightness */
+			status = ACPI_EC_READ(sc->ec_dev,
+			    THINKPAD_EC_BRIGHTNESS, &val_ec, 1);
+			if (ACPI_FAILURE(status))
+				return (status);
+			val = val_ec & THINKPAD_EC_MASK_BRI;
+
+			Args.Count = 1;
+			Args.Pointer = &Arg;
+			Arg.Type = ACPI_TYPE_INTEGER;
+			Arg.Integer.Value = (arg > val) ?
+			    THINKPAD_CMOS_BRIGHTNESS_UP :
+			    THINKPAD_CMOS_BRIGHTNESS_DOWN;
+
+			step = (arg > val) ? 1 : -1;
+			for (i = val; i != arg; i += step) {
+				status = AcpiEvaluateObject(sc->cmos_handle,
+				    NULL, &Args, NULL);
+				if (ACPI_FAILURE(status))
+					break;
+			}
+		}
+		return ACPI_EC_WRITE(sc->ec_dev, THINKPAD_EC_BRIGHTNESS,
+		    arg, 1);
+		break;
+
+	case ACPI_THINKPAD_METHOD_VOLUME:
+		if (arg < 0 || arg > 14)
+			return (EINVAL);
+
+		status = ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_VOLUME,
+		    &val_ec, 1);
+		if (ACPI_FAILURE(status))
+			return (status);
+
+		if (sc->cmos_handle) {
+			val = val_ec & THINKPAD_EC_MASK_VOL;
+
+			Args.Count = 1;
+			Args.Pointer = &Arg;
+			Arg.Type = ACPI_TYPE_INTEGER;
+			Arg.Integer.Value = (arg > val) ?
+			    THINKPAD_CMOS_VOLUME_UP : THINKPAD_CMOS_VOLUME_DOWN;
+
+			step = (arg > val) ? 1 : -1;
+			for (i = val; i != arg; i += step) {
+				status = AcpiEvaluateObject(sc->cmos_handle,
+				    NULL, &Args, NULL);
+				if (ACPI_FAILURE(status))
+					break;
+			}
+		}
+		return ACPI_EC_WRITE(sc->ec_dev, THINKPAD_EC_VOLUME, arg +
+		    (val_ec & (~THINKPAD_EC_MASK_VOL)), 1);
+		break;
+
+	case ACPI_THINKPAD_METHOD_MUTE:
+		if (arg < 0 || arg > 1)
+			return (EINVAL);
+
+		status = ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_VOLUME,
+		    &val_ec, 1);
+		if (ACPI_FAILURE(status))
+			return (status);
+
+		if (sc->cmos_handle) {
+			val = val_ec & THINKPAD_EC_MASK_VOL;
+
+			Args.Count = 1;
+			Args.Pointer = &Arg;
+			Arg.Type = ACPI_TYPE_INTEGER;
+			Arg.Integer.Value = THINKPAD_CMOS_VOLUME_MUTE;
+
+			status = AcpiEvaluateObject(sc->cmos_handle, NULL,
+			    &Args, NULL);
+			if (ACPI_FAILURE(status))
+				break;
+		}
+		return ACPI_EC_WRITE(sc->ec_dev, THINKPAD_EC_VOLUME, (arg==1) ?
+		   val_ec | THINKPAD_EC_MASK_MUTE :
+		   val_ec & (~THINKPAD_EC_MASK_MUTE), 1);
+		break;
+
+	case ACPI_THINKPAD_METHOD_THINKLIGHT:
+		if (arg < 0 || arg > 1)
+			return (EINVAL);
+
+		if (sc->light_set_supported) {
+			Args.Count = 1;
+			Args.Pointer = &Arg;
+			Arg.Type = ACPI_TYPE_INTEGER;
+			Arg.Integer.Value = arg ?
+			    sc->light_cmd_on : sc->light_cmd_off;
+
+			status = AcpiEvaluateObject(sc->light_handle, NULL,
+			    &Args, NULL);
+			if (ACPI_SUCCESS(status))
+				sc->light_val = arg;
+			return (status);
+		}
+		break;
+
+	case ACPI_THINKPAD_METHOD_BLUETOOTH:
+		if (arg < 0 || arg > 1)
+			return (EINVAL);
+
+		val = (arg == 1) ? sc->wlan_bt_flags |
+		    THINKPAD_NAME_MASK_BT :
+		    sc->wlan_bt_flags & (~THINKPAD_NAME_MASK_BT);
+		return acpi_SetInteger(sc->handle, THINKPAD_NAME_WLAN_BT_SET,
+		    val);
+		break;
+
+	case ACPI_THINKPAD_METHOD_FANLEVEL:
+		if (arg < 0 || arg > 7)
+			return (EINVAL);
+
+		if (!sc->fan_handle) {
+			/* Read the current fanstatus */
+			ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_FANSTATUS,
+			    &val_ec, 1);
+			val = val_ec & (~THINKPAD_EC_MASK_FANLEVEL);
+
+			return ACPI_EC_WRITE(sc->ec_dev, THINKPAD_EC_FANSTATUS,
+			    val | arg, 1);
+		}
+		break;
+
+	case ACPI_THINKPAD_METHOD_FANSTATUS:
+		if (arg < 0 || arg > 1)
+			return (EINVAL);
+
+		if (!sc->fan_handle) {
+			/* Read the current fanstatus */
+			ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_FANSTATUS,
+			    &val_ec, 1);
+
+			return ACPI_EC_WRITE(sc->ec_dev, THINKPAD_EC_FANSTATUS,
+			    (arg == 1) ? (val_ec | THINKPAD_EC_MASK_FANSTATUS) :
+			    (val_ec & (~THINKPAD_EC_MASK_FANSTATUS)), 1);
+		}
+		break;
+	}
+
+	return (0);
+}
+
+static int
+acpi_thinkpad_sysctl_init(struct acpi_thinkpad_softc *sc, int method)
+{
+	int 			dummy;
+	ACPI_OBJECT_TYPE 	cmos_t;
+	ACPI_HANDLE		ledb_handle;
+
+	switch (method) {
+	case ACPI_THINKPAD_METHOD_EVENTS:
+		/* Events are disabled by default */
+		return (TRUE);
+
+	case ACPI_THINKPAD_METHOD_EVENTMASK:
+		return (sc->events_mask_supported);
+
+	case ACPI_THINKPAD_METHOD_HOTKEY:
+	case ACPI_THINKPAD_METHOD_BRIGHTNESS:
+	case ACPI_THINKPAD_METHOD_VOLUME:
+	case ACPI_THINKPAD_METHOD_MUTE:
+		/* EC is required here, which was already checked before */
+		return (TRUE);
+
+	case ACPI_THINKPAD_METHOD_THINKLIGHT:
+		sc->cmos_handle = NULL;
+		sc->light_get_supported = ACPI_SUCCESS(acpi_GetInteger(
+		    sc->ec_handle, THINKPAD_NAME_KEYLIGHT, &sc->light_val));
+
+		if ((ACPI_SUCCESS(AcpiGetHandle(sc->handle, "\\UCMS",
+		    &sc->light_handle)) ||
+		    ACPI_SUCCESS(AcpiGetHandle(sc->handle, "\\CMOS",
+		    &sc->light_handle)) ||
+		    ACPI_SUCCESS(AcpiGetHandle(sc->handle, "\\CMS",
+		    &sc->light_handle))) &&
+		    ACPI_SUCCESS(AcpiGetType(sc->light_handle, &cmos_t)) &&
+		    cmos_t == ACPI_TYPE_METHOD) {
+			sc->light_cmd_on = 0x0c;
+			sc->light_cmd_off = 0x0d;
+			sc->cmos_handle = sc->light_handle;
+		}
+		else if (ACPI_SUCCESS(AcpiGetHandle(sc->handle, "\\LGHT",
+		    &sc->light_handle))) {
+			sc->light_cmd_on = 1;
+			sc->light_cmd_off = 0;
+		}
+		else
+			sc->light_handle = NULL;
+
+		sc->light_set_supported = (sc->light_handle &&
+		    ACPI_FAILURE(AcpiGetHandle(sc->ec_handle, "LEDB",
+		    &ledb_handle)));
+
+		if (sc->light_get_supported)
+			return (TRUE);
+
+		if (sc->light_set_supported) {
+			sc->light_val = 0;
+			return (TRUE);
+		}
+
+		return (FALSE);
+
+	case ACPI_THINKPAD_METHOD_BLUETOOTH:
+	case ACPI_THINKPAD_METHOD_WLAN:
+		if (ACPI_SUCCESS(acpi_GetInteger(sc->handle,
+		    THINKPAD_NAME_WLAN_BT_GET, &dummy)))
+			return (TRUE);
+		return (FALSE);
+
+	case ACPI_THINKPAD_METHOD_FANSPEED:
+		/* 
+		 * Some models report the fan speed in levels from 0-7
+		 * Newer models report it contiguously
+		 */
+		sc->fan_levels = (ACPI_SUCCESS(AcpiGetHandle(sc->handle, "GFAN",
+		    &sc->fan_handle)) ||
+		    ACPI_SUCCESS(AcpiGetHandle(sc->handle, "\\FSPD",
+		    &sc->fan_handle)));
+		return (TRUE);
+
+	case ACPI_THINKPAD_METHOD_FANLEVEL:
+	case ACPI_THINKPAD_METHOD_FANSTATUS:
+		/* 
+		 * Fan status is only supported on those models,
+		 * which report fan RPM contiguously, not in levels
+		 */
+		if (sc->fan_levels)
+			return (FALSE);
+		return (TRUE);
+
+	case ACPI_THINKPAD_METHOD_THERMAL:
+		if (ACPI_SUCCESS(acpi_GetInteger(sc->ec_handle,
+		    THINKPAD_NAME_THERMAL_GET, &dummy))) {
+			sc->thermal_updt_supported =
+			    ACPI_SUCCESS(acpi_GetInteger(sc->ec_handle,
+			    THINKPAD_NAME_THERMAL_UPDT, &dummy));
+			return (TRUE);
+		}
+		return (FALSE);
+	}
+	return (FALSE);
+}
+
+static void
+acpi_thinkpad_notify(ACPI_HANDLE h, UINT32 notify, void *context)
+{
+	int		event, arg, type;
+	device_t	dev = context;
+	struct acpi_thinkpad_softc *sc = device_get_softc(dev);
+
+	ACPI_FUNCTION_TRACE_U32((char *)(uintptr_t)__func__, notify);
+
+	if (notify != 0x80)
+		device_printf(dev, "Unknown notify\n");
+
+	for (;;) {
+		acpi_GetInteger(acpi_get_handle(dev), THINKPAD_NAME_EVENTS_GET,
+		    &event);
+
+		if (event == 0)
+			break;
+
+		type = (event >> 12) & 0xf;
+		arg = event & 0xfff;
+		switch (type) {
+		case 1:
+			if (!(sc->events_availmask & (1 << (arg - 1)))) {
+				device_printf(dev, "Unknown key %d\n", arg);
+				break;
+			}
+
+			/* Notify devd(8) */
+			device_printf(dev, "THINKPAD event: %u\n",
+			    (arg & 0xff));
+			acpi_UserNotify("THINKPAD", h, (arg & 0xff));
+			break;
+		default:
+			break;
+		}
+	}
+}
+
+static void
+acpi_thinkpad_refresh(void *arg)
+{
+	struct acpi_thinkpad_softc *sc = (struct acpi_thinkpad_softc *)arg;
+	char temp_cmd[] = "TMP0";
+	int data, i;
+	ACPI_INTEGER speed;
+
+	for (i = 0; i < 8; i++) {
+		temp_cmd[3] = '0' + i;
+		
+                /*
+                 * The TMPx methods seem to return +/- 128 or 0
+                 * when the respecting sensor is not available
+                 */
+		sc->sensors[i].flags &= ~SENSOR_FINVALID;
+                if (ACPI_FAILURE(acpi_GetInteger(sc->ec_handle, temp_cmd,
+                    &data)) || ABS(data) == 128 || data == 0) {
+			sc->sensors[i].flags |= SENSOR_FINVALID;
+                        data = 0;
+		}
+                else if (sc->thermal_updt_supported) {
+                        /* XXX: Temperature is reported in tenth of Kelvin */
+                        data = (data - 2732 + 5) / 10;
+		}
+		sc->sensors[i].value = data * 1000000 + 273150000;
+        }
+	
+	sc->sensors[8].flags &= ~SENSOR_FINVALID;
+	if (sc->fan_handle) {
+		if (ACPI_FAILURE(acpi_GetInteger(sc->fan_handle,
+		    NULL, &data)))
+			sc->sensors[8].flags |= SENSOR_FINVALID;
+                        data = -1;
+        }
+        else {
+                ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_FANSPEED, &speed, 2);
+                data = speed;
+        }
+
+	sc->sensors[8].value = data;
+}
diff --git a/sys/platform/pc32/conf/files b/sys/platform/pc32/conf/files
--- a/sys/platform/pc32/conf/files
+++ b/sys/platform/pc32/conf/files
@@ -72,6 +72,7 @@ dev/serial/dgb/dgm.c			optional	dgm
 ${OSACPI_MD_DIR}/acpi_machdep.c		optional        acpi
 ${OSACPI_MD_DIR}/acpi_wakeup.c		optional        acpi
 ${OSACPI_MD_DIR}/acpi_toshiba.c		optional        acpi_toshiba acpi
+${ACPICA_DIR}/acpi_thinkpad/acpi_thinkpad.c optional	acpi_thinkpad acpi
 acpi.h					optional	acpi		\
 	dependency	"$S/${ACPICA_DIR}/include/acpi.h"		\
 	compile-with	"cp $S/${ACPICA_DIR}/include/acpi.h ${.OBJDIR}/"	\



From hasso at estpak.ee  Thu Mar 20 03:49:13 2008
From: hasso at estpak.ee (Hasso Tepper)
Date: Thu, 20 Mar 2008 03:49:13 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Some questions regarding ACPI
In-Reply-To: <200803191322.46366.hasso@estpak.ee>
Message-ID: <200803201237.28823.hasso@estpak.ee>

Hasso Tepper wrote:
> There is also one fatal issue -laptop locks up hardly (no panic) while 
> unloading module. Any idea regarding this is welcome.

Nevermind, solved.


-- 
Hasso




From dillon at apollo.backplane.com  Fri Mar 21 19:24:01 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Fri, 21 Mar 2008 19:24:01 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: panic: assertion: hammer_btree_cmp(cursor->left_bound,	&cursor->node->ondisk->elms[0].leaf.base) <= 0 in btree_split_leaf
In-Reply-To: <200802232204.m1NM4cxd046264@apollo.backplane.com>
Message-ID: <200803220212.m2M2CiAY014435@apollo.backplane.com>

:While trying to find a procedure to reliably reproduce the panic
:I reported last time, I caught a different panic (uploaded at
: ~y0netan1/crash/9/ on my leaf account).  I wrote the following shell
:script (make sure to edit variables DISKS and MOUNTPT before using this
:script or it may trash your system):

    Ok, I believe I have fixed the left_bound assertion.  I also believe
    I have fixed the node ref count assertion on umount.

    There is currently one unfixed assertion related to the I/O
    path... sometimes the bp is being improperly disassociated from the
    related HAMMER structure.

    The full-filesystem case is still not being handled so don't test that :-)

					    -Matt





From c.turner at 199technologies.org  Sun Mar 23 09:48:29 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Sun, 23 Mar 2008 09:48:29 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
Message-ID: <47E6870C.4080709@199technologies.org>

I'm finally getting around to doing 1.12 upgrades, and have setup a 
separate machine to do my bulk package builds / upgrades etc,
so as not to disrupt my 'dev server' while things are being
built / tested

However, this seems kind of wasteful - the only purpose of this machine
is to build packages against a specific release..
And since building packages for a particular release generally requires 
only the userland, appropriate headers and correct 'uname' output - so:

it seems like if spoofing uname is configured inside a jail,
the next (or previous..) release can be installed into a jail and
used for building / testing packages without the overhead of a VM or 
maintaining a separate physical host

I did a quick scan of the tree to see what this would take, and, high 
level, it seems like only the following changes would need to be made:

- update struct jail to add a 'osrelease' string
  (implies bumping 'jail api' to 2?)
- update jail(8) to actually pass this information along
- update sys_uname to test ucred for jailed processes, and
  use the struct jail osrelease if appropriate
- similarly update sysctl kern.osrelease to support jail spoofing
  (if possible - didn't get this far in the research yet)
  could be less of a problem for builds, as I think most things use
 uname(1) ... but good to keep the environment consistent I suppose..
I'm still a bit confused as to how 'osrelease' is defined - everything
I'm finding is showing up as extern char[] .. perhaps this is something 
in the build I'm not familiar with?

also,

is the so-called 'stupid hackery' in sys_uname needed still?

Before I start any coding, does this:

- sound like something useful
- sound like the right approach
Thinking this could have wider useful implications e.g. for pkgbox
& so on -  for example setting up automated bulks w/various combinations 
of pkgsrc and releases, etc.

Cheers,

- Chris





From corecode at fs.ei.tum.de  Sun Mar 23 10:06:38 2008
From: corecode at fs.ei.tum.de (Simon 'corecode' Schubert)
Date: Sun, 23 Mar 2008 10:06:38 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <47E68C74.3080808@fs.ei.tum.de>

Chris Turner wrote:
I did a quick scan of the tree to see what this would take, and, high 
level, it seems like only the following changes would need to be made:
brave investigation.  but you could also simply set UNAME_r :)

sweatshorts % uname -r
1.13.0-DEVELOPMENT
sweatshorts % UNAME_r=1.12-RELEASE uname -r
1.12-RELEASE
I think that's good enough :D

cheers
  simon
--
Serve - BSD     +++  RENT this banner advert  +++    ASCII Ribbon   /"\
Work - Mac      +++  space for low ????????? NOW!1  +++      Campaign     \ /
Party Enjoy Relax   |   http://dragonflybsd.org      Against  HTML   \
Dude 2c 2 the max   !   http://golden-apple.biz       Mail + News   / \




From c.turner at 199technologies.org  Sun Mar 23 10:50:13 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Sun, 23 Mar 2008 10:50:13 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <47E69656.8080605@199technologies.org>

Simon 'corecode' Schubert wrote:
brave investigation.  but you could also simply set UNAME_r :)
Doh! Thanks for the tip!

they should change the phrase from RTFM to 'Carefully RTFM' :)

well.. scratch that change then. 1 less patch to write.

- Chris





From c.turner at 199technologies.org  Sun Mar 23 11:15:52 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Sun, 23 Mar 2008 11:15:52 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <47E69C7C.8010109@199technologies.org>

Chris Turner wrote:
Simon 'corecode' Schubert wrote:
brave investigation.  but you could also simply set UNAME_r :)

for the record - if anyone's interested - adding a line e.g.:

ALL_ENV+= UNAME_r=1.12-RELEASE

to mk.conf looks like it -might- work ..

(unless wants to chime in & verify)





From joerg at britannica.bec.de  Sun Mar 23 11:46:53 2008
From: joerg at britannica.bec.de (Joerg Sonnenberger)
Date: Sun, 23 Mar 2008 11:46:53 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <20080323181428.GA2099@britannica.bec.de>

On Sun, Mar 23, 2008 at 01:41:42PM -0400, Chris Turner wrote:
> they should change the phrase from RTFM to 'Carefully RTFM' :)

RTFMAI -- Read The Fine Manual Again, Idiot.

Joerg




From dillon at apollo.backplane.com  Sun Mar 23 20:05:36 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Sun, 23 Mar 2008 20:05:36 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
Message-ID: <200803240257.m2O2voNH038355@apollo.backplane.com>

    Here's an update on the HAMMER work!

    Current status:

    * Passes all standard filesystem stress tests and buildworld will
      run with a HAMMER /usr/obj.  Large histories are able to accumulate
      without effecting performance.

    * Pruning and reblocking code is in and partially tested, but now needs
      more stringent testing.

    * Full historical access appears to be working but needs testing.
      Note that a sync is still needed to flush dirty cached data prior
      to acquiring a timestamp for the 'snapshot' to be set in stone.
      (dirty data cached in-memory has no historical tags and must be
      committed to physical disk before it can be accessed historically).


    Current bugs:

    * There is one known bug in the standard operations code paths
      that results in an assertion in HAMMER's I/O subsystem.

    * There are probably bugs in the reblocking and/or pruning code.  More
      likely in the reblocking code.


    There are two big-ticket and several little-ticket items left.  HAMMER
    will officially go Alpha when the big-ticket items are done, and beta
    when we get a few of the little-ticket items done.

    Big ticket items left:

    * UNDO (crash recovery) code.  Currently it writes out undo records but
      they are not yet sequenced, buffer writes are not yet ordered, and
      there is no mount-time recovery code yet.

      This is the last item needed before HAMMER can go operational.

    * Filesystem full handling.  Currently no space is reserved for dirty
      cached data so it is possible to create/write files and for HAMMER
      to not have sufficient space left on-disk to flush it.


    Little ticket items:

    * Automated reblocking (currently these functions are manually
      initialized via the hammer utility).

    * I/O clustering and preliminary BMAP op when writing out large files.

    * CRC checking (CRC fields are reserved but not entirely generated yet
      and not yet checked at all).

    * Disaster Recovery filesystem scan.

    * Boot support.

    I expect all of these items and more to be handled by the 2.0 release
    in July.

			    Additional HAMMER capabilities
				(no timeline yet)

    * Adding, removing, and resizing a HAMMER filesystem's backing store.

			Ultimate Goals and working towards them
				(no timeline yet)

    Our ultimate goal with HAMMER and DragonFly in general is to support
    fully cache coherent replication in a multi-machine environment.  This
    involves several steps and networking protocols.

    * Replication of synchronization streams based on the UNDO log.  If
      resynchronizing to a target which is too old a B-Tree scan will
      likely be required.

    * Cache coherency protocols for machine-machine coherency for both
      replicated and remote-HAMMER access.

    I have no time frame for these items yet.  It will depend on how quickly
    HAMMER moves to Alpha and Beta status.  I will say, however, now
    that HAMMER's on-disk format has solidified, that I have a very precise
    understanding of the protocols that will be needed to accomplish fully
    cache coherent remote access for both replicated and non-replicated
    (remote mount style) access.

    And, as you know, fully coherent filesystem access across machines is
    going to be the basis for DragonFly's clustering across said machines.

    In summary, things are progressing very well.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From justin at shiningsilence.com  Sun Mar 23 20:10:13 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Sun, 23 Mar 2008 20:10:13 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <53758.192.168.0.252.1206327873.squirrel@www.shiningsilence.com>

On Sun, March 23, 2008 12:36 pm, Chris Turner wrote:

> it seems like if spoofing uname is configured inside a jail,
> the next (or previous..) release can be installed into a jail and
> used for building / testing packages without the overhead of a VM or
> maintaining a separate physical host

If you don't need a jail to spoof uname, as others posted, you can
installworld into a chroot and build everything you want there using
Joerg's spiffy pbulk.  That's what I'm doing on pkgbox now; I can hand you
my somewhat terse notes if you want.  It would be relatively easy to set
up the configuration you're talking about.





From sepherosa at gmail.com  Sun Mar 23 20:18:20 2008
From: sepherosa at gmail.com (Sepherosa Ziehau)
Date: Sun, 23 Mar 2008 20:18:20 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <ea7b9c170803232012n2f27f893tf1d756d7c9770419@mail.gmail.com>

On Mon, Mar 24, 2008 at 2:14 AM, Joerg Sonnenberger
<joerg at britannica.bec.de> wrote:
> On Sun, Mar 23, 2008 at 01:41:42PM -0400, Chris Turner wrote:
>  > they should change the phrase from RTFM to 'Carefully RTFM' :)
>
>  RTFMAI -- Read The Fine Manual Again, Idiot.

http://leaf.dragonflybsd.org/~sephe/rtfm.jpg

:D

>
>  Joerg
>



-- 
Live Free or Die




From justin at shiningsilence.com  Sun Mar 23 20:38:30 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Sun, 23 Mar 2008 20:38:30 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: GSoC 2008 - mentors signup
Message-ID: <53885.192.168.0.252.1206329503.squirrel@www.shiningsilence.com>

If you are planning to be a mentor for a Summer of Code project, please
sign up here for the mentors mailing list:

http://groups.google.com/group/google-summer-of-code-mentors-list

If you've already signed up, your subscription should be set up tomorrow.





From justin at shiningsilence.com  Sun Mar 23 21:12:01 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Sun, 23 Mar 2008 21:12:01 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: GSoC 2008 - mentors signup
In-Reply-To: <53885.192.168.0.252.1206329503.squirrel@www.shiningsilence.com>
Message-ID: <54025.192.168.0.252.1206331572.squirrel@www.shiningsilence.com>

Also!

If you are a potential mentor and you have not done so yet:

http://code.google.com/soc/mentor_step1.html

Get yourself registered as a mentor for the Summer of Code project.  Once
you are in there, check off DragonFly in the "My Profile" section.

You will need a Google Account if you don't have one:

http://www.google.com/accounts

This will add you to the list of mentors in the Google Summer of Code web
application, so you can review/be attached to projects.

A guide is available if you want more information:

http://groups.google.com/group/google-summer-of-code-announce/web/guide-to-the-gsoc-web-app-for-mentors-and-organization-administrators






From c.turner at 199technologies.org  Mon Mar 24 04:29:28 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Mon, 24 Mar 2008 04:29:28 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <47E78ECE.4070307@199technologies.org>

Justin C. Sherrill wrote:
If you don't need a jail to spoof uname, as others posted, you can
installworld into a chroot and build everything you want there using
Joerg's spiffy pbulk.  That's what I'm doing on pkgbox now; I can hand you
my somewhat terse notes if you want.  It would be relatively easy to set
up the configuration you're talking about.
cheers - I guess I thought incorrectly that something 'special' was 
needed to get the uname to change .. have been using the legacy bulks in 
chroots / jails (for 'same os' builds) as I haven't quite migrated to 
pbulk yet ..

thanks for the help offer - I'll ask if I run into trouble.




From dillon at apollo.backplane.com  Mon Mar 24 08:28:49 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Mon, 24 Mar 2008 08:28:49 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <200803241500.m2OF0CG8043760@apollo.backplane.com>


:http://leaf.dragonflybsd.org/~sephe/rtfm.jpg
:
::D

    Ho!

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From elekktretterr at exemail.com.au  Mon Mar 24 09:10:15 2008
From: elekktretterr at exemail.com.au (Petr Janda)
Date: Mon, 24 Mar 2008 09:10:15 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
In-Reply-To: <200803240257.m2O2voNH038355@apollo.backplane.com>
Message-ID: <200803250138.49775.elekktretterr@exemail.com.au>


>
>     And, as you know, fully coherent filesystem access across machines is
>     going to be the basis for DragonFly's clustering across said machines.
>
>     In summary, things are progressing very well.
>


Hi Matt,
That's good to know things are going so well. Got a question. If memory serves 
me right, initially there was also going to be a thing called ANVIL, I can't 
remember what it was supposed to do and whether its still in your design. 
Could you elaborate a little?

Thanks,
Petr




From dillon at apollo.backplane.com  Mon Mar 24 14:12:11 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Mon, 24 Mar 2008 14:12:11 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
In-Reply-To: <200803240257.m2O2voNH038355@apollo.backplane.com>
Message-ID: <200803242100.m2OL0nWV046868@apollo.backplane.com>


:Hi Matt,
:That's good to know things are going so well. Got a question. If memory serves 
:me right, initially there was also going to be a thing called ANVIL, I can't 
:remember what it was supposed to do and whether its still in your design. 
:Could you elaborate a little?
:
:Thanks,
:Petr

    It's not really in the HAMMER design any more, primarily because HAMMER's
    volume model seems to work fine as-is.  Ultimately something like ANVIL
    (a block storage manager) would prove beneficial to the project but it
    would be treated as a separate project.  HAMMER's redundancy model is
    going to be baesd around replication and clustering.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From tgen at netphreax.net  Mon Mar 24 18:31:37 2008
From: tgen at netphreax.net (Thomas E. Spanjaard)
Date: Mon, 24 Mar 2008 18:31:37 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
In-Reply-To: <200803240257.m2O2voNH038355@apollo.backplane.com>
Message-ID: <47E85337.2070407@netphreax.net>

Matthew Dillon wrote:
    * Full historical access appears to be working but needs testing.
      Note that a sync is still needed to flush dirty cached data prior
      to acquiring a timestamp for the 'snapshot' to be set in stone.
      (dirty data cached in-memory has no historical tags and must be
      committed to physical disk before it can be accessed historically).
Wouldn't making timestamp queries (at least from userland) enforce a 
sync on the volume in question be useful here?
--
        Thomas E. Spanjaard
        tgen at netphreax.net
Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00005.pgp
Type: application/octet-stream
Size: 186 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080324/3077333f/attachment-0018.obj>

From dillon at apollo.backplane.com  Mon Mar 24 20:10:12 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Mon, 24 Mar 2008 20:10:12 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
In-Reply-To: <200803240257.m2O2voNH038355@apollo.backplane.com>
Message-ID: <200803250302.m2P32qLP050160@apollo.backplane.com>


:Wouldn't making timestamp queries (at least from userland) enforce a 
:sync on the volume in question be useful here?
:-- 
:         Thomas E. Spanjaard
:         tgen at netphreax.net

    Making the 'hammer now' command do a sync() is a good idea.  I will
    make that change right now so it doesn't get lost.

    Here's a general overview of the issues involved with having historical
    access to the filesystem:

				----------------

    Recording the timestamps in the in-memory cache, for a finer-grained
    snapshot capability, is doable but has its own issues.  Here's an
    illustration:

    open()  create file
    write() append 4K	(file size now 4K)
    write() append 4K	(file size now 8K)
    write() append 4K	(file size now 12K)
    write() append 4K	(file size now 16K)

    Now NONE of this has gone to disk yet, it's entirely in the in-memory
    cache.  The inode is in the in-memory cache.  The data is stored in
    the buffer cache.  Even the directory entry for the file that we
    just created is still in the in-memory cache (HAMMER caches the raw
    records it intends to commit later on).

    If I wanted to be able to acquire a timestamp between each write and
    'see' a snapshot of the file as of any point in the above sequence,
    then every write would also have to allocate a copy of the inode
    (because it changes size on each write).

    The data has the same problem though with a slightly different example.
    Lets say each write() was a seek-write, overwriting the previous data.
    Now with every write() I would have to allocate a copy of the data
    being overwritten.  This is complicated by the fact that the buffer
    cache has no clue about 'historical' accesses, so I would not be able
    to use the buffer cache to cache the data.

    There's also another problem and that is with the efficiency of the
    topology on-disk.  Even if I maintained all the copies of the inode
    and all the copies of the data in-memory, I would still have to sync
    all those copies to disk in order for things to remain historically
    coherent (whether it be in-cache or on-disk).  This would result in
    hundreds or even thousands of copies of the inode on-disk, not to
    mention potentially many copies of the data.

    I just don't want to do that right now, at least not as a default.  A
    lot of performance would be lost.  Hence a sync() is needed if
    you want to create a demark which you can accurately snapshot.

				-------------

    Here's a quick synopsis of how the cache would operate in a clustered
    filesystem:

    In order to properly integrate with in-memory caches, a wider cache
    coherency infrastructure is needed between machines such that
    modifications made on one machine proactively invalidate those
    protions of the cache(s) on other machines.  At the same time, any
    'dirty' cache data, for example when a file is created or written to,
    must lock the cache space in question on all other machines.
    The cache space in this case is not just the file data, but also the
    related namespaces (for creations, deletions, and renames).  Attempts
    to access locked spaces from other machines in the cluster would have
    to force a flush to the filesystem backing store and lower the cache
    states for the effected information on the original machine from dirty
    to shared-read-only.

    It will be easiest to integrate the cache coherency information into
    the buffer cache and namecache themselves.  Once a machine has dirtied
    an in-memory cache element... for example part of the namespace when
    creating a file or chunks of data written within a file, that machine
    must have a free hand to make further modifications to the cache spaces
    involved without further interaction with other machines.

				-------------

    Now, if you think of those two major elements you can see that they
    actually fit together quite well.  If I were to attempt to maintain
    transactional coherency on a per-system-call basis then the cache
    granularity between machines would have to be much, much smaller then
    our current in-memory caching elements provide.  That would become
    a really nasty coding problem.  So I don't even want to begin to
    complate transactional coherency at a finer-grain then sync() or
    fsync() until long after we actually have clustering working.

						-Matt





From elekktretterr at exemail.com.au  Mon Mar 24 21:56:58 2008
From: elekktretterr at exemail.com.au (Petr Janda)
Date: Mon, 24 Mar 2008 21:56:58 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
In-Reply-To: <200803240257.m2O2voNH038355@apollo.backplane.com>
Message-ID: <200803251516.16407.elekktretterr@exemail.com.au>

So is it needed to run hammer now in order to "create" a snapshot? What would 
I do in situation like this: got a hammer filesystem and couple of the files 
change on day to day basis. Then a week later I needed to access one of the 
files, in exactly the state they were 7 days ago.

Cheers,
Petr




From dillon at apollo.backplane.com  Mon Mar 24 22:34:15 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Mon, 24 Mar 2008 22:34:15 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
In-Reply-To: <200803240257.m2O2voNH038355@apollo.backplane.com>
Message-ID: <200803250526.m2P5QZ5X051081@apollo.backplane.com>


:So is it needed to run hammer now in order to "create" a snapshot? What would 
:I do in situation like this: got a hammer filesystem and couple of the files 
:change on day to day basis. Then a week later I needed to access one of the 
:files, in exactly the state they were 7 days ago.
:
:Cheers,
:Petr

    No, you do not have to run 'hammer now' to create a snapshot.  The
    kernel syncs all filesystems every 30 seconds, so if you do nothing
    at all you get a snapshot granularity of 30 seconds.

    Where you would use 'hammer now' is if you wanted the most current
    snapshot possible for the purpose of, say, backing up your filesystem
    to another machine.  You might do something like this:

	set timestamp = `hammer now`
	cpdup /mountpoint/@@$timestamp targethost:/somepath

    But if you didn't care about that you could just go back far enough
    that you get a stable historical view... e.g. go back 1 minute and you
    would have a stable view into your filesystem.

	set timestamp = `hammer stamp 60s`		<------ doesn't sync
	cpdup /mountpoint/@@$timestamp targethost:/somepath


    Ultimately the idea of managing filesystems this way is to still do
    regular backups from your production machine to your backup machine
    (ultimately by way of replication), with both running HAMMER, but only
    retain a limited amount of history on the production box.  You might
    desire to retain only one week's worth of history on the production box,
    retain one month's history on your local backup box, and retain a very
    granular one year's worth of history on your remote backup box.

    Come to think of it, I should add some more directives to the
    'hammer prune' command to make that easier to specify.

    Until I implement a live replication 'feed' the minimum granularity on
    the backup box will be how often you do your backups (e.g. once a day),
    and you can prune it into more granular forms from that starting point.
    Once we have a live replication feed the backup box will have the same
    30-second granularity that the production machine has.

    A major bullet point for this style of management is that the retention
    policy on the various boxes can be different even though they are
    all slaved off the same production filesystem.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From justin at shiningsilence.com  Tue Mar 25 05:58:49 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Tue, 25 Mar 2008 05:58:49 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: SoC - student signups
Message-ID: <58180.65.106.147.226.1206449676.squirrel@www.shiningsilence.com>

Here's a quick link roundup:

Are you a student?  Put in your application for a Google Summer of Code here:

http://code.google.com/soc/2008/student_signup.html

Student guide:
http://groups.google.com/group/google-summer-of-code-announce/web/guide-to-the-gsoc-web-app-for-student-applicants

Are you a mentor?  (That means hasso, hsu, sephe, matthias, TGEN, and
corecode right now)

Student proposals will show up on the mentor page, linked below.  You will
get to rate them, and take the one(s) that you want to mentor.

Mentor page:
http://code.google.com/soc/2008/mentor_home.html
Mentor guide:
http://groups.google.com/group/google-summer-of-code-announce/web/guide-to-the-gsoc-web-app-for-mentors-and-organization-administrators

If you are a mentor and are communicating with potential students, send
them the URLs above for student signup and the student guide; work with
them if they ask for advice on what to say in the application.  They can
resubmit up to 20 times if they want to correct it.

Deadline is March 31st.






From noah.yan at gmail.com  Thu Mar 27 20:17:48 2008
From: noah.yan at gmail.com (Yonghong Yan)
Date: Thu, 27 Mar 2008 20:17:48 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: About DFBSD.64
In-Reply-To: <47EB0B5B.5020802@gmail.com>
Message-ID: <59521b110803272015y1cc8cc39uc93f154ed36e0505@mail.gmail.com>

thanks for your interest.

I owe to everybody for any update or work in the past four months. so
many things happen in my work and my family (they are all good:) and
keep me extremely busy. But i am not leaving and will be back on this
soon.

the latest sources are in http://repo.or.cz/w/dragonfly/port-amd64.git
, I did have a compiled kernel long time before, but I have to break
it to work on the pmap. you can pick up from there. TGEN will help you
a lot, also keep me posted too, if you like.

Noah

On Wed, Mar 26, 2008 at 9:50 PM, Sdavtaker <sdavtaker at gmail.com> wrote:
> Hello,
>  Im applying to GSoC to work in the x64 version of DFBSD with TGEN, i
>  found some work already done in the repository and some mails in the
>  archive from you.
>  I was wondering if you already had a working compiled kernel in AMD64
>  machine and what was not working yet to continue that work.
>  Thanks for any info.
>  Sdav
>




From dillon at apollo.backplane.com  Sat Mar 29 13:27:43 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Sat, 29 Mar 2008 13:27:43 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 29-Mar-2008
Message-ID: <200803292022.m2TKMLGe004942@apollo.backplane.com>

    Good progress continues to be made.  HAMMER survived acting as my
    LAN backup machine (in full historical mode) for almost a week before
    it hit an assertion.  I've fixed that issue and believe that the core
    filesystem implementation code is now 'very stable'.

    Note that the recent commit will result in many more 'hammer_lock_ex:'
    messages on the console then you may have previously observed.  This is
    due to the way object id's are allocated in the face of parallel 
    modifications to the filesystem, resulting in too much locality of
    reference in the B-Tree.  I do intend to improve it.

    I am still working on the two major items needed before HAMMER can be
    declared operational, those being the filesystem full handling and the
    undo/recovery-on-mount code.  These are the last 'hard' bits left in
    the design.

    With exception to filling up the filesystem, which *will* create a mess,
    and noting that no crash recovery code exists yet (so you have to newfs
    it if you crash), I'd appreciate it if interested parties could test
    the other functions of the filesystem, in particular the pruning and
    reblocking functions (man hammer), and the historical access functions.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From dillon at apollo.backplane.com  Sun Mar 30 15:11:03 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Sun, 30 Mar 2008 15:11:03 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Need ideas on how to solve an st_ino/st_dev test issue for HAMMER.
Message-ID: <200803302207.m2UM7BCp016402@apollo.backplane.com>

    Here's the problem, given historical access softlinks as shown below:

test30# ls -lda cra*
drwxr-xr-x  1 root  wheel  Mar 29 13:04 crater
lrwxr-xr-x  1 root  wheel  Mar 29 18:57 crater.20080329 -> crater@@0x47eef383
lrwxr-xr-x  1 root  wheel  Mar 30 01:24 crater.20080330 -> crater@@0x47ef4e29
-rw-r--r--  2 root  wheel  Mar 30 01:24 crater.log

    The problem is that if I do this:

    diff -r crater.20080329/var/log crater.20080330/var/log

    Diff just returns without actually diffing anything.  The reason is
    because diff checks st_ino and st_dev and believes the directories/files
    to be identical because they match.

    I considered munging the inode number for historical accesses, but
    that would seriously break NFS exports which try to access historical
    files and directories.  Right now NFS *is* able to distinguish between
    the two because NFS handles are 128-bit-wide entities, so I can encode
    the as-of transaction id as part of the filehandle.  But userland
    programs only have access to a 64-bit-wide inode so userland still
    believes the files to be identical.

    st_dev is only 32 bits, carefully munging it is an option if we
    could figure out a way to do it, but I'd rather not.

    I am considering using st_gen but then we'd have to patch third
    party software to test st_gen along with everything else.  This may
    be the only workable solution, though, and only a few programs would
    need to be patched.  st_gen is only 32 bits but it would solve the
    problem as we would be able to use all 32 bits.

    If anyone has any bright ideas, including 'leave it alone', I'm all
    ears.

						-Matt





From justin at shiningsilence.com  Mon Mar 31 10:40:42 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Mon, 31 Mar 2008 10:40:42 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: SoC student applications due by 5PM PDT tomorrow
In-Reply-To: <1942.192.168.0.242.1206930479.squirrel@www.shiningsilence.com>
Message-ID: <11892.67.108.184.175.1206984967.squirrel@www.shiningsilence.com>

On Sun, March 30, 2008 10:27 pm, Justin C. Sherrill wrote:
> SoC students:
>
> If you have an application to submit for DragonFly/Summer of Code, please
> do so by 17:00 Pacific time on the 31st - that's tomorrow, at least for
> me.

The deadline for student proposals has been extended to April 7th; all
other dates move forward one week to acommodate.

This is a good time to update existing applications or submit new ones. 
Talk to your (potential) mentors if you are curious.






From nthery at gmail.com  Mon Mar 31 11:29:49 2008
From: nthery at gmail.com (Nicolas Thery)
Date: Mon, 31 Mar 2008 11:29:49 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
Message-ID: <64fc43b0803311126na7d0b27obaa9d35bac6d32ee@mail.gmail.com>

Hello,

Now that the release is over, I'll try to get rid of zones and migrate
allocations to objcache.

Here is a 1st patch that migrate struct proc.  I'll commit it in a
couple of days if nobody objects.

I'm also implementing a way to monitor objcache statistics.  So far,
I've hacked sth similar to
sysctl vm.zone: stats are returned in one giant string, one line per
cache.  That's simple but ugly and hard to read because there are
quite a few stats per cache.

So I'm thinking about implementing a small tool, ocstat, that extracts
stats from sysctl the way ps(1) does (thru libkvm iirc) and formats it
in various ways.  What do you think?

Cheers,
Nicolas

Index: src2/sys/kern/kern_exit.c
===================================================================
--- src2.orig/sys/kern/kern_exit.c	2008-03-31 08:05:59.139796000 +0200
+++ src2/sys/kern/kern_exit.c	2008-03-31 10:31:39.000000000 +0200
@@ -834,7 +834,7 @@ loop:
 			}

 			vm_waitproc(p);
-			zfree(proc_zone, p);
+			objcache_put(proc_cache, p);
 			nprocs--;
 			return (0);
 		}
Index: src2/sys/kern/kern_proc.c
===================================================================
--- src2.orig/sys/kern/kern_proc.c	2008-03-31 08:05:59.139918000 +0200
+++ src2/sys/kern/kern_proc.c	2008-03-31 10:31:39.000000000 +0200
@@ -84,7 +84,7 @@ u_long pgrphash;
 struct proclist allproc;
 struct proclist zombproc;
 struct spinlock allproc_spin;
-vm_zone_t proc_zone;
+struct objcache* proc_cache;
 vm_zone_t lwp_zone;
 vm_zone_t thread_zone;

@@ -131,7 +131,7 @@ procinit(void)
 	spin_init(&allproc_spin);
 	pidhashtbl = hashinit(maxproc / 4, M_PROC, &pidhash);
 	pgrphashtbl = hashinit(maxproc / 4, M_PROC, &pgrphash);
-	proc_zone = zinit("PROC", sizeof (struct proc), 0, 0, 5);
+	proc_cache = objcache_create_simple(M_PROC, sizeof(struct proc));
 	lwp_zone = zinit("LWP", sizeof (struct lwp), 0, 0, 5);
 	thread_zone = zinit("THREAD", sizeof (struct thread), 0, 0, 5);
 	uihashinit();
Index: src2/sys/sys/proc.h
===================================================================
--- src2.orig/sys/sys/proc.h	2008-03-31 08:05:59.140325000 +0200
+++ src2/sys/sys/proc.h	2008-03-31 10:31:39.000000000 +0200
@@ -473,7 +473,7 @@ struct proc *zpfind (pid_t);	/* Find zom
 struct vm_zone;
 struct globaldata;
 struct lwp_params;
-extern struct vm_zone *proc_zone;
+extern struct objcache *proc_cache;
 extern struct vm_zone *lwp_zone;

 int	enterpgrp (struct proc *p, pid_t pgid, int mksess);
Index: src2/sys/kern/kern_fork.c
===================================================================
--- src2.orig/sys/kern/kern_fork.c	2008-03-31 08:05:59.140042000 +0200
+++ src2/sys/kern/kern_fork.c	2008-03-31 10:31:39.000000000 +0200
@@ -332,7 +332,7 @@ fork1(struct lwp *lp1, int flags, struct
 	}

 	/* Allocate new proc. */
-	p2 = zalloc(proc_zone);
+	p2 = objcache_get(proc_cache, M_WAITOK);
 	bzero(p2, sizeof(*p2));

 	/*




From hsu at dragonflybsd.org  Mon Mar 31 11:44:34 2008
From: hsu at dragonflybsd.org (Jeffrey Hsu)
Date: Mon, 31 Mar 2008 11:44:34 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <64fc43b0803311126na7d0b27obaa9d35bac6d32ee@mail.gmail.com>
Message-ID: <200803311841.m2VIfQAI007579@nlpi001.prodigy.net>

The object cache is not a general-purpose memory allocator.  It's a cache of
pre-initialized objects.  Are the significant portions of the proc structure
that can be restored to initialized state on object puts?  If not, it's best
to just use a general-purpose memory allocator.

								Jeffrey




From corecode at fs.ei.tum.de  Mon Mar 31 12:07:02 2008
From: corecode at fs.ei.tum.de (Simon 'corecode' Schubert)
Date: Mon, 31 Mar 2008 12:07:02 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <200803311841.m2VIfQAI007579@nlpi001.prodigy.net>
Message-ID: <47F1357B.1070302@fs.ei.tum.de>

Jeffrey Hsu wrote:
> The object cache is not a general-purpose memory allocator.  It's a cache of
> pre-initialized objects.  Are the significant portions of the proc structure
> that can be restored to initialized state on object puts?  If not, it's best
> to just use a general-purpose memory allocator.

Why?  What's the loss if we use the object cache to allocate struct procs?

cheers
  simon

Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00006.pgp
Type: application/octet-stream
Size: 252 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080331/a4a24314/attachment-0018.obj>

From nthery at gmail.com  Mon Mar 31 12:17:03 2008
From: nthery at gmail.com (Nicolas Thery)
Date: Mon, 31 Mar 2008 12:17:03 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <nthery@gmail.com>
Message-ID: <64fc43b0803311214u7da6bbb8xaf971de1a80e7258@mail.gmail.com>

2008/3/31, Jeffrey Hsu <hsu at dragonflybsd.org>:
> The object cache is not a general-purpose memory allocator.  It's a cache of
>  pre-initialized objects.  Are the significant portions of the proc structure
>  that can be restored to initialized state on object puts?  If not, it's best
>  to just use a general-purpose memory allocator.

Well, I haven't checked this yet.  I planned to do this in a second
step after getting rid of zones.

I thought that even without  the pre-initialization part, objcache has
the advantage
of pre-allocating set of objects (as zones) and is additionally
mp-safe (contrary to zones and, granted, as malloc()).   The latter
may be interesting as we talk of improving MP support.

Cheers,
Nicolas




From dillon at apollo.backplane.com  Mon Mar 31 12:23:40 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Mon, 31 Mar 2008 12:23:40 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <200803311841.m2VIfQAI007579@nlpi001.prodigy.net>
Message-ID: <200803311921.m2VJLITB027669@apollo.backplane.com>

    I both agree and disagree with Jeff.  I think the only *disadvantage*
    to using objcache for struct proc is that objcache must cache a minimum
    number of free structures to be efficient so the overall kernel memory
    use would be a bit greater verses uses kmalloc().  But I agree with Jeff
    in that objcache's biggest advantage is that you can keep structural state
    intact and struct proc might not be a good candidate (yet).

    What I suggest is that you convert struct proc from zone to kmalloc
    first, and then look into a possible objcache adaptation.  kmalloc
    is not slow.. it's a very fast allocator.  Objcache is probably a tad
    faster but not by much.  Where objcache really wins is in not having
    to completey reinitialize the allocated structures.

    Over the years I've removed (I think) all the dependancies on requiring
    the proc structure to be in stable memory so I believe it can be moved to
    kmalloc/objcache now without any major pain.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From corecode at fs.ei.tum.de  Mon Mar 31 12:37:40 2008
From: corecode at fs.ei.tum.de (Simon 'corecode' Schubert)
Date: Mon, 31 Mar 2008 12:37:40 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: SoC student applications due by 5PM PDT tomorrow
In-Reply-To: <1942.192.168.0.242.1206930479.squirrel@www.shiningsilence.com>
Message-ID: <47F13CDA.6010703@fs.ei.tum.de>

Justin C. Sherrill wrote:
> On Sun, March 30, 2008 10:27 pm, Justin C. Sherrill wrote:
>> SoC students:
>>
>> If you have an application to submit for DragonFly/Summer of Code, please
>> do so by 17:00 Pacific time on the 31st - that's tomorrow, at least for
>> me.
> The deadline for student proposals has been extended to April 7th; all
> other dates move forward one week to acommodate.

This is very good.

Some more ideas for eager students (we want to keep the ratio, right?):

Enhance the FreeBSD/DragonFly sound infrastructure to support surround
sound/multichannel output.

Update sound drivers to support S/PDIF output.

Make the sound infrastructure OSSv4 compatible (there was a SoC at
FreeBSD last year or so)


of course only if it doesn't exist already :)

cheers
  simon


Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00007.pgp
Type: application/octet-stream
Size: 252 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080331/6da61cff/attachment-0018.obj>

From corecode at fs.ei.tum.de  Mon Mar 31 12:41:30 2008
From: corecode at fs.ei.tum.de (Simon 'corecode' Schubert)
Date: Mon, 31 Mar 2008 12:41:30 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <200803311841.m2VIfQAI007579@nlpi001.prodigy.net>
Message-ID: <47F13DE4.10205@fs.ei.tum.de>

Matthew Dillon wrote:
>     What I suggest is that you convert struct proc from zone to kmalloc
>     first, and then look into a possible objcache adaptation.  kmalloc
>     is not slow.. it's a very fast allocator.  Objcache is probably a tad
>     faster but not by much.  Where objcache really wins is in not having
>     to completey reinitialize the allocated structures.

Could we please not move to kmalloc, but instead try to move all fast
path allocations to objcache?  I don't like the idea of allocating
everything with kmalloc.  Caching struct procs is not a bad thing itself.

cheers
  simon


Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00008.pgp
Type: application/octet-stream
Size: 252 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080331/ac328c08/attachment-0018.obj>

From hsu at FreeBSD.org  Mon Mar 31 12:59:05 2008
From: hsu at FreeBSD.org (Jeffrey Hsu)
Date: Mon, 31 Mar 2008 12:59:05 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <47F1357B.1070302@fs.ei.tum.de>
Message-ID: <200803311920.m2VJK5Ln018015@nlpi015.prodigy.net>

The object cache sits on top of a general-purpose memory allocator such
as kmalloc or zalloc and provides pre-initialized object caching functionality.
If you're not going to use the object caching functionality, you can just
call the underlying memory allocator directly.

							Jeffrey




From dillon at apollo.backplane.com  Mon Mar 31 16:17:19 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Mon, 31 Mar 2008 16:17:19 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <200803311841.m2VIfQAI007579@nlpi001.prodigy.net>
Message-ID: <200803312311.m2VNBumd029866@apollo.backplane.com>

:Could we please not move to kmalloc, but instead try to move all fast
:path allocations to objcache?  I don't like the idea of allocating
:everything with kmalloc.  Caching struct procs is not a bad thing itself.=
:
:
:cheers
:  simon

    I will state for the record that I'm fine with either objcache or
    kmalloc.  I agree with Jeff that using objcache for struct proc
    probably isn't necessary but I also agree that it would not hurt either,
    and if the intent is to optimize the initialization of the proc
    structure in the future then moving to objcache now would save us
    from having to do it later.

    So whichever method Nicolas wants to use is fine with me.

						-Matt




From hsu at dragonflybsd.org  Mon Mar 31 19:22:47 2008
From: hsu at dragonflybsd.org (Jeffrey Hsu)
Date: Mon, 31 Mar 2008 19:22:47 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <64fc43b0803311214u7da6bbb8xaf971de1a80e7258@mail.gmail.com>
Message-ID: <200804010218.m312IVUq003624@nlpi043.prodigy.net>

  >> Are there significant portions of the proc structure
  >> that can be restored to initialized state on object puts?

  > I planned to do this in a second step after getting rid of zones.

I'll all in favor of making more use of caching pre-initialized objects, so
if this is your objective, then please go ahead.  It's just that I'd convert
over to the object cache in one step.

  > I thought that even without  the pre-initialization part, objcache has
  > the advantage of pre-allocating set of objects (as zones) and is additionally
  > mp-safe (contrary to zones and, granted, as malloc()).

Well, the zone allocator is MP-safe.  It's not hard to lock up the places that
manipulate the linked-list of free items. Look for uses of the zlock field.

								Jeffrey




From tgen at netphreax.net  Sat Mar  1 12:57:53 2008
From: tgen at netphreax.net (Thomas E. Spanjaard)
Date: Sat, 1 Mar 2008 12:57:53 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: [Fwd: Project Support Open Source: $50 donation to support you      project]
In-Reply-To: <2468.192.168.0.242.1204346451.squirrel@www.shiningsilence.com>
Message-ID: <47C9C1B7.50203@netphreax.net>

Justin C. Sherrill wrote:
The "donation" happens after you place an "acknowledgement" on an open
source project's web page.  I'm putting those words in scare quotes
because I think it's a "payment" for an "advertisement".  The supplied
link has nothing to do with DragonFly, to say the least.

<a href="http://www.2insure4less.com /" title="We support FOSS software
projects.">Online Insurance Quotes</a>
To think our souls are only worth $50...
--
        Thomas E. Spanjaard
        tgen at netphreax.net
Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00000.pgp
Type: application/octet-stream
Size: 186 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080301/0d61e240/attachment-0019.obj>

From c.turner at 199technologies.org  Sat Mar  1 17:52:31 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Sat, 1 Mar 2008 17:52:31 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Misc. ACPI / suspend
Message-ID: <47CA073B.6020106@199technologies.org>

Wondering if anyone more well versed in the ACPI implementation could
comment on the applicability of:
http://lkml.org/lkml/2007/4/6/69

w/r/t the current state of the art in Dfly

(or BSD's in general)

Cheers!

- Chris




From elekktretterr at exemail.com.au  Sun Mar  2 00:41:25 2008
From: elekktretterr at exemail.com.au (Petr Janda)
Date: Sun, 2 Mar 2008 00:41:25 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: CARP question
Message-ID: <200803021934.21669.elekktretterr@exemail.com.au>

So Ive setup CARP on 2 DF-based mailservers. Installation went fine. Box 1 has 
adskew of 0 therefore it is the MASTER. Box 2 has adskew of 254, therefore is 
BACKUP.  If i down the carp0 interface on Box 1, then Box 2 carp interface 
gets promoted to MASTER. Then I up the carp interface on Box 1, logically Box 
2 should become BACKUP again as Box 1 becomes MASTER due to adskew set to 0.

However it doesnt happen. When carp0 interface on Box 1 is upped it becomes a 
BACKUP, not a MASTER even though according to adskew it should be MASTER.

What is the desired behaviour?

Cheers
Petr




From qhwt+dfly at les.ath.cx  Sun Mar  2 02:50:14 2008
From: qhwt+dfly at les.ath.cx (YONETANI Tomokazu)
Date: Sun, 2 Mar 2008 02:50:14 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: panic: assertion: hammer_btree_cmp(cursor->left_bound,	&cursor->node->ondisk->elms[0].leaf.base) <= 0 in btree_split_leaf
In-Reply-To: <200802232204.m1NM4cxd046264@apollo.backplane.com>
Message-ID: <20080302104554.GA22813@les.ath.cx>

Hi.
While trying to find a procedure to reliably reproduce the panic
I reported last time, I caught a different panic (uploaded at
 ~y0netan1/crash/9/ on my leaf account).  I wrote the following shell
script (make sure to edit variables DISKS and MOUNTPT before using this
script or it may trash your system):
  #!/bin/sh -ex
  DISKS="/dev/ad0s1f"
  MOUNTPT=/mnt/HAMMER

  cd /
  newfs_hammer -L TEST $DISKS
  for i in `seq 1 100`; do
	  mount_hammer $DISKS $MOUNTPT
	  /bin/rm -rf $MOUNTPT/??
	  (set +x; for x in `seq 1 10000`; do echo -n > $MOUNTPT/$x; done)
	  umount $MOUNTPT
  done

And the panic is triggered by rm command.
I'll try to see if it's possible to reproduce the last one without
unmounting then mounting the HAMMER fs.

Cheers.




From dillon at apollo.backplane.com  Sun Mar  2 13:25:33 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Sun, 2 Mar 2008 13:25:33 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: panic: assertion: hammer_btree_cmp(cursor->left_bound,	&cursor->node->ondisk->elms[0].leaf.base) <= 0 in btree_split_leaf
In-Reply-To: <200802232204.m1NM4cxd046264@apollo.backplane.com>
Message-ID: <200803022119.m22LJRCY037076@apollo.backplane.com>


:Hi.
:While trying to find a procedure to reliably reproduce the panic
:I reported last time, I caught a different panic (uploaded at
: ~y0netan1/crash/9/ on my leaf account).  I wrote the following shell
:script (make sure to edit variables DISKS and MOUNTPT before using this
:script or it may trash your system):

(from the core)

panic: assertion: node->lock.refs == 0 && node->ondisk == NULL in hammer_flush_buffer_nodes

    Yah, I've seen this failure.  Add a sync or two before the umount and
    tell me if it still occurs.  It's either a node reference leak somewhere
    or it is a race between bufdaemon and umount.  The assertions are really
    strict there precisely to catch those sorts of cases.

    Also note that the code to deal with a full HAMMMER filesystem has not
    been written yet (The failure you are reporting is unrelated to a full
    HAMMER filesystem, though, just mentioning it).

						-Matt





From dillon at apollo.backplane.com  Sun Mar  2 13:29:03 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Sun, 2 Mar 2008 13:29:03 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Misc. ACPI / suspend
In-Reply-To: <47CA073B.6020106@199technologies.org>
Message-ID: <200803022126.m22LQbfI037188@apollo.backplane.com>


:Wondering if anyone more well versed in the ACPI implementation could
:comment on the applicability of:
:
:http://lkml.org/lkml/2007/4/6/69
:
:w/r/t the current state of the art in Dfly
:
:(or BSD's in general)
:
:Cheers!
:
:- Chris

    I really have no idea re: this.  Suspension in general is not well
    supported by any of the BSDs.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From dillon at apollo.backplane.com  Sun Mar  2 13:34:05 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Sun, 2 Mar 2008 13:34:05 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: [Fwd: Project Support Open Source: $50 donation to support you      project]
In-Reply-To: <2468.192.168.0.242.1204346451.squirrel@www.shiningsilence.com>
Message-ID: <200803022131.m22LVOe9037250@apollo.backplane.com>

:..
:source project's web page.  I'm putting those words in scare quotes
:because I think it's a "payment" for an "advertisement".  The supplied
:link has nothing to do with DragonFly, to say the least.
:
:I don't think this is a good idea, obviously, and replied to that effect. 
:However, I wanted to put this on a DragonFly list, in part to show this
:strange thing, and in part because I'm not comfortable making
:administrative decisions on behalf of the Project without being open as
:possible about it.

    It doesn't really cry out to me either.

						-Matt





From wbh at conducive.org  Sun Mar  2 20:36:32 2008
From: wbh at conducive.org (Bill Hacker)
Date: Mon, 03 Mar 2008 04:36:32 +0000
Subject: Misc. ACPI / suspend
In-Reply-To: <47CA073B.6020106@199technologies.org>
Message-ID: <47cb8050$0$855$415eb37d@crater_reader.dragonflybsd.org>

Matthew Dillon wrote:
:Wondering if anyone more well versed in the ACPI implementation could
:comment on the applicability of:
:
:http://lkml.org/lkml/2007/4/6/69
:
:w/r/t the current state of the art in Dfly
:
:(or BSD's in general)
:
:Cheers!
:
:- Chris
    I really have no idea re: this.  Suspension in general is not well
    supported by any of the BSDs.
					-Matt
					Matthew Dillon 
					<dillon at backplane.com>


. . and there seems to be a bit of a 'Catch 22' there in any case.

If the BIOS can alter 'stuff' out of site of the OS it is parking, what 
does the existence of such a 'feature' do to a(ny) security model?

Seems to at least beg creating the option of setting a flag to 
specifically *prevent* suspend-to-disk/hibernation (and/or force a 
reboot on wake-up).

Just because one is paranoid....  etc

Bill





From matthias at dragonflybsd.org  Tue Mar  4 02:30:52 2008
From: matthias at dragonflybsd.org (Matthias Schmidt)
Date: Tue, 4 Mar 2008 02:30:52 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
Message-ID: <20080304102335.GI9833@staatsfeind.org>

Hi,

Google just announced its Summer of Code for 2008:

	http://code.google.com/soc/2008/

I think this would be a great opportunity for DragonFly to participate
as a mentoring organisation.  We could attract new developers and could
get code/work done.  Looking at the SoC results of the other BSDs most
of their projects were a success.  Of course, not all, but a reasonable
percentage.  See [1] and [2].

It is some extra work for us, but IMO the benefits outweigh the extra
work.  And yes, I would volunteer as a mentor.  What do others
(developers) think?  Any more volunteers? :)

Some project ideas that come into my mind.  More ideas are listed in the
wiki:  http://wiki.dragonflybsd.org/index.cgi/ProjectsPage

 * Fix all remaining bugs in dma(8) and implement all missing features
 * Add a driver for newer Intel Wireless cards (I think sephe@ would
   love that :)
 * Bring our ACPI stuff in shape.  Maybe suspend2disk ...

 * [Add your own thoughts here]

Cheers,

	Matthias

PS: I don't want to create a bikeshed here whether you like the SoC or
not :)

[1] http://code.google.com/soc/2007/freebsd/about.html
[2] http://code.google.com/soc/2007/netbsd/about.html




From corecode at fs.ei.tum.de  Tue Mar  4 04:46:14 2008
From: corecode at fs.ei.tum.de (Simon 'corecode' Schubert)
Date: Tue, 4 Mar 2008 04:46:14 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47CD4386.1000704@fs.ei.tum.de>

Matthias Schmidt wrote:
>  * [Add your own thoughts here]

MP lock removal for network stack

and for the system  (first profile, find hot spots, fix hot spots, repeat)

cheers
  simon




From c.turner at 199technologies.org  Tue Mar  4 06:02:20 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Tue, 4 Mar 2008 06:02:20 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47CD551E.1040604@199technologies.org>

Matthias Schmidt wrote:
Some project ideas that come into my mind.  More ideas are listed in the
wiki:  http://wiki.dragonflybsd.org/index.cgi/ProjectsPage
+1 acpi
+1 interrupt routing
+1 SMP / giant removal
+1 pf synchup with openbsd
though there are several others on the page that are good..

need to dig up my wiki login and place appropriately..

also: thinking the ZFS port should be removed from the page - makes 
sense to everyone else? (e.g. fragments effort w/r/t hammer)





From tgen at netphreax.net  Tue Mar  4 06:54:31 2008
From: tgen at netphreax.net (Thomas E. Spanjaard)
Date: Tue, 4 Mar 2008 06:54:31 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47CD615F.8010209@netphreax.net>

Matthias Schmidt wrote:
Google just announced its Summer of Code for 2008:

 * [Add your own thoughts here]
x86-64 port :).
--
        Thomas E. Spanjaard
        tgen at netphreax.net
Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00001.pgp
Type: application/octet-stream
Size: 186 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080304/0d921000/attachment-0019.obj>

From rdivacky at FreeBSD.org  Tue Mar  4 07:07:03 2008
From: rdivacky at FreeBSD.org (Roman Divacky)
Date: Tue, 4 Mar 2008 07:07:03 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <20080304150255.GA8831@freebsd.org>

On Tue, Mar 04, 2008 at 02:49:03PM +0000, Thomas E. Spanjaard wrote:
> Matthias Schmidt wrote:
> >Google just announced its Summer of Code for 2008:
> >
> > * [Add your own thoughts here]
> 
> x86-64 port :).

all those ideas are great and needed etc. but keep in
mind that the projects should be doable by students
who might see dfly for the very first time.

don't overestimate whats possible and select projects
that look realistic

Roman Divacky (former SoC student)




From justin at shiningsilence.com  Tue Mar  4 08:32:56 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Tue, 4 Mar 2008 08:32:56 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <60322.65.106.147.226.1204648095.squirrel@www.shiningsilence.com>

On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
> Hi,
>
> Google just announced its Summer of Code for 2008:
>
> 	http://code.google.com/soc/2008/
>
> I think this would be a great opportunity for DragonFly to participate
> as a mentoring organisation.  We could attract new developers and could
> get code/work done.  Looking at the SoC results of the other BSDs most
> of their projects were a success.  Of course, not all, but a reasonable
> percentage.  See [1] and [2].

We've applied in previous years - Jeff Hsu did one year, and I put
together the application last year.  The hardest thing to find was
students (and they are the thing that helps SoC applications a lot, I
think).

Any student volunteers?  We have mentors.





From rluciani at gmail.com  Tue Mar  4 09:38:29 2008
From: rluciani at gmail.com (Robert Luciani)
Date: Tue, 04 Mar 2008 18:38:29 +0100
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47cd8915$0$854$415eb37d@crater_reader.dragonflybsd.org>

Justin C. Sherrill wrote:
> On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
>> Hi,
>>
>> Google just announced its Summer of Code for 2008:
>>
>> 	http://code.google.com/soc/2008/
>>
>> I think this would be a great opportunity for DragonFly to participate
>> as a mentoring organisation.  We could attract new developers and could
>> get code/work done.  Looking at the SoC results of the other BSDs most
>> of their projects were a success.  Of course, not all, but a reasonable
>> percentage.  See [1] and [2].
> 
> We've applied in previous years - Jeff Hsu did one year, and I put
> together the application last year.  The hardest thing to find was
> students (and they are the thing that helps SoC applications a lot, I
> think).
> 
> Any student volunteers?  We have mentors.
> 

bingo

-- 
Robert Luciani
Chalmers University of Technology, SWE
Department of Computer Science and Engineering
http://www.rluciani.com/public.key




From sdavtaker at gmail.com  Tue Mar  4 09:31:08 2008
From: sdavtaker at gmail.com (=?UTF-8?Q?Sd=C3=A4vtaker?=)
Date: Tue, 4 Mar 2008 09:31:08 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <c37d69f60803040926k206218a3kb8496d0cd18148bd@mail.gmail.com>

If you mentor, i will apply for coder :-)
Still in last year of university. :-)
Sdav

On Tue, Mar 4, 2008 at 1:28 PM, Justin C. Sherrill
<justin at shiningsilence.com> wrote:
> On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
>  > Hi,
>  >
>  > Google just announced its Summer of Code for 2008:
>  >
>  >       http://code.google.com/soc/2008/
>  >
>  > I think this would be a great opportunity for DragonFly to participate
>  > as a mentoring organisation.  We could attract new developers and could
>  > get code/work done.  Looking at the SoC results of the other BSDs most
>  > of their projects were a success.  Of course, not all, but a reasonable
>  > percentage.  See [1] and [2].
>
>  We've applied in previous years - Jeff Hsu did one year, and I put
>  together the application last year.  The hardest thing to find was
>  students (and they are the thing that helps SoC applications a lot, I
>  think).
>
>  Any student volunteers?  We have mentors.
>
>



-- 
Sd?vtaker prays to Rikku goddess for a good treasure.



From rluciani at gmail.com  Tue Mar  4 09:44:02 2008
From: rluciani at gmail.com (Robert Luciani)
Date: Tue, 04 Mar 2008 18:44:02 +0100
Subject: google soc "DragonFly"
Message-ID: <47cd8a63$0$855$415eb37d@crater_reader.dragonflybsd.org>

On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
> > Hi,
> >
> > Google just announced its Summer of Code for 2008:
> >
> > 	http://code.google.com/soc/2008/
> >
> > I think this would be a great opportunity for DragonFly to participate
> > as a mentoring organisation.  We could attract new developers and could
> > get code/work done.  Looking at the SoC results of the other BSDs most
> > of their projects were a success.  Of course, not all, but a reasonable
> > percentage.  See [1] and [2].

We've applied in previous years - Jeff Hsu did one year, and I put
together the application last year.  The hardest thing to find was
students (and they are the thing that helps SoC applications a lot, I
think).

Any student volunteers?  We have mentors.


-- 
Robert Luciani
Chalmers University of Technology, SWE
Department of Computer Science and Engineering
http://www.rluciani.com/public.key




From rluciani at gmail.com  Tue Mar  4 10:04:14 2008
From: rluciani at gmail.com (Robert Luciani)
Date: Tue, 04 Mar 2008 19:04:14 +0100
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47cd8f1f$0$856$415eb37d@crater_reader.dragonflybsd.org>

Robert Luciani wrote:
> Justin C. Sherrill wrote:
>> On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
>>> Hi,
>>>
>>> Google just announced its Summer of Code for 2008:
>>>
>>> 	http://code.google.com/soc/2008/
>>>
>>> I think this would be a great opportunity for DragonFly to participate
>>> as a mentoring organisation.  We could attract new developers and could
>>> get code/work done.  Looking at the SoC results of the other BSDs most
>>> of their projects were a success.  Of course, not all, but a reasonable
>>> percentage.  See [1] and [2].
>> We've applied in previous years - Jeff Hsu did one year, and I put
>> together the application last year.  The hardest thing to find was
>> students (and they are the thing that helps SoC applications a lot, I
>> think).
>>
>> Any student volunteers?  We have mentors.
>>
> 
> bingo
> 
My girlfriend Danwei noted that she would also like partake in the SoC.
She's studying IT here at Chalmers and will join the mailing list shortly.
-- 
Robert Luciani
Chalmers University of Technology, SWE
Department of Computer Science and Engineering
http://www.rluciani.com/public.key




From dillon at apollo.backplane.com  Tue Mar  4 13:08:30 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Tue, 4 Mar 2008 13:08:30 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Going to have to roll 1.12.1
Message-ID: <200803042104.m24L43g1065278@apollo.backplane.com>

    Due to a critical bug in sendmail that can cause it to seg-fault I will
    be rolling 1.12.1 as soon as I get verification that the current
    fix deals with it.

						-Matt





From sdavtaker at gmail.com  Tue Mar  4 17:40:43 2008
From: sdavtaker at gmail.com (=?UTF-8?B?U2TDpHZ0YWtlcg==?=)
Date: Tue, 4 Mar 2008 17:40:43 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: [Fwd: Project Support Open Source: $50 donation to support you  project]
In-Reply-To: <2468.192.168.0.242.1204346451.squirrel@www.shiningsilence.com>
Message-ID: <47CDF8D1.9070100@gmail.com>

50 bucks?
Come on...
You can get a meal a lot more expensive than that just going to a free 
HP conference about linux and you only have to rent your soul 3-5 hours ;-)
Sdav

Matthew Dillon escribi?:
:..
:source project's web page.  I'm putting those words in scare quotes
:because I think it's a "payment" for an "advertisement".  The supplied
:link has nothing to do with DragonFly, to say the least.
:
:I don't think this is a good idea, obviously, and replied to that effect. 
:However, I wanted to put this on a DragonFly list, in part to show this
:strange thing, and in part because I'm not comfortable making
:administrative decisions on behalf of the Project without being open as
:possible about it.

    It doesn't really cry out to me either.

						-Matt

  






From sdavtaker at gmail.com  Tue Mar  4 17:56:35 2008
From: sdavtaker at gmail.com (=?UTF-8?B?U2TDpHZ0YWtlcg==?=)
Date: Tue, 4 Mar 2008 17:56:35 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47CDFCCE.1010106@gmail.com>

A cute idea for for GSOC would be to finish the installer.
We were talking about this in my local BUG, we trying to find out how to 
help on that from here.
There is a few missing features in the CD.

   * FDISK, you need to create the slides from another OS before
     install DFBSD, i think port FDisk from FBSD or any *BSD will solve it.
   * Add to the make release a way to add some custom applications to
     the released liveCD (suppose you want to add nmap or ssh or
     something just to use as test disk in some enviroment).
   * Make the installer a little more customizable, and maybe w/ a GUI
     (I like a lot the console approach, but GUI installer will be a
     popularity move, DFBSD w/X makes a Desktop machine work, actually
     im using it that way and really like it).
I think those projects can be done in a SOC by students (like me) with a 
little guide.
Im a lot more interested in things network related and kernel, but i 
dont mind to work on those things, they need to be done some day.
What u think?
Sdav

Robert Luciani escribi?:
Robert Luciani wrote:
  
Justin C. Sherrill wrote:
    
On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
      
Hi,

Google just announced its Summer of Code for 2008:

	http://code.google.com/soc/2008/

I think this would be a great opportunity for DragonFly to participate
as a mentoring organisation.  We could attract new developers and could
get code/work done.  Looking at the SoC results of the other BSDs most
of their projects were a success.  Of course, not all, but a reasonable
percentage.  See [1] and [2].
        
We've applied in previous years - Jeff Hsu did one year, and I put
together the application last year.  The hardest thing to find was
students (and they are the thing that helps SoC applications a lot, I
think).
Any student volunteers?  We have mentors.

      
bingo

    
My girlfriend Danwei noted that she would also like partake in the SoC.
She's studying IT here at Chalmers and will join the mailing list shortly.
  






From c.turner at 199technologies.org  Tue Mar  4 18:30:53 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Tue, 4 Mar 2008 18:30:53 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47CE04C9.1010902@199technologies.org>

Justin C. Sherrill wrote:
together the application last year.  The hardest thing to find was
students (and they are the thing that helps SoC applications a lot, I
think).
umm.. if google wants to send me back to school, I'll sign up - hows 
that for a fair trade :?






From wbh at conducive.org  Tue Mar  4 23:52:13 2008
From: wbh at conducive.org (Bill Hacker)
Date: Wed, 05 Mar 2008 07:52:13 +0000
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47ce512e$0$855$415eb37d@crater_reader.dragonflybsd.org>

Sd?vtaker wrote:
A cute idea for for GSOC would be to finish the installer.
We were talking about this in my local BUG, we trying to find out how to 
help on that from here.
There is a few missing features in the CD.

   * FDISK, you need to create the slides from another OS before
     install DFBSD, i think port FDisk from FBSD or any *BSD will solve it.
I'd rather see that 'reversed' - i.e. - build a more capable fdisk in 
DFLY with hope that it might be seen worth importing into Free/Net/Open, 
or *at least* be able to do a more flexible job than those now do.

And disklabels as well. Hand in glove.

Here's why:

- At the moment, working with Free, Open, DFLY, and OpenSolaris on the 
same HDD requires a bit of acrobatics.

- There seems to now be greater divergence between/among the *BSD's as 
to being able to read each other's disklabels, mount and use each 
other's 'flavor' of FFS/UFS (not to mention Apple's implementation of 
UFS) than there is among the vast multitude of Linux ext2/3 denizens.

Even to the point where use of a *Linux* fs is the more universal way 
for being able to share mounts among the *BSD's. Think detached drives. 
And no - FAT is not all that practical for several reasons.

- DFLY currently has the most fine-grain ability to create slices and 
partitions. But the others cannot all (any?) read those.

'progress' w/r any of the *BSD's direction as to changes, improvements 
(or not) in their once-common-ancestry fs & disklabels need not be 
sacrificed.

I'm not holding out wish or hope for all players agreeing to return to 
'one sacred way'. Nor 'one new universal fs'. Neither is gonna happen.

But a 'legacy compatible' or least-common-denominator mode would do fine 
- most especially for portable / SAN devices.

So - how about a 'flexible' DFLY fdisk to go along with a 'flexible' 
disklabel that could adapt to whatever it found / was told to create?

JM2CW - but that *might* be a good place to get a cross-*BSD team together.

*snip* (other good stuff)

Bill Hacker




From matthias at dragonflybsd.org  Wed Mar  5 01:02:43 2008
From: matthias at dragonflybsd.org (Matthias Schmidt)
Date: Wed, 5 Mar 2008 01:02:43 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <20080305085747.GJ9833@staatsfeind.org>

Hi,

* Justin C. Sherrill wrote:
> 
> We've applied in previous years - Jeff Hsu did one year, and I put
> together the application last year.  The hardest thing to find was
> students (and they are the thing that helps SoC applications a lot, I
> think).

This is good to know, so we could coordinate that if we have enough
mentors and projects?!?  I put together a small text in the wiki:

http://wiki.dragonflybsd.org/index.cgi/GoogleSoC2008

Feel free to add project or missing stuff.  I'm sure I missed a lot of
things :)

> Any student volunteers?  We have mentors.

According to the discussion we could have some students, who would be a
mentor (besides me)?

Regards

	Matthias





From sdavtaker at gmail.com  Wed Mar  5 06:28:37 2008
From: sdavtaker at gmail.com (=?UTF-8?Q?Sd=C3=A4vtaker?=)
Date: Wed, 5 Mar 2008 06:28:37 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <c37d69f60803050624kd86d3d0w3b44a02d0e5a5391@mail.gmail.com>

<quote>
Write a driver (from scratch) for Intel 3945 wireless device
Mentor: Sepherosa Ziehau
</quote>

Yes yes yes, i want to :-)
Someone else planning to mentor in drivers coding?
Sdav

On Wed, Mar 5, 2008 at 5:57 AM, Matthias Schmidt
<matthias at dragonflybsd.org> wrote:
> Hi,
>
>
>  * Justin C. Sherrill wrote:
>  >
>  > We've applied in previous years - Jeff Hsu did one year, and I put
>  > together the application last year.  The hardest thing to find was
>  > students (and they are the thing that helps SoC applications a lot, I
>  > think).
>
>  This is good to know, so we could coordinate that if we have enough
>  mentors and projects?!?  I put together a small text in the wiki:
>
>  http://wiki.dragonflybsd.org/index.cgi/GoogleSoC2008
>
>  Feel free to add project or missing stuff.  I'm sure I missed a lot of
>  things :)
>
>
>  > Any student volunteers?  We have mentors.
>
>  According to the discussion we could have some students, who would be a
>  mentor (besides me)?
>
>  Regards
>
>         Matthias
>
>



-- 
Sd?vtaker prays to Rikku goddess for a good treasure.



From rluciani at gmail.com  Wed Mar  5 10:56:42 2008
From: rluciani at gmail.com (Robert Luciani)
Date: Wed, 05 Mar 2008 19:56:42 +0100
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47ceecea$0$847$415eb37d@crater_reader.dragonflybsd.org>

Sd?vtaker wrote:
> <quote>
> Write a driver (from scratch) for Intel 3945 wireless device
> Mentor: Sepherosa Ziehau
> </quote>
> 
> Yes yes yes, i want to :-)
> Someone else planning to mentor in drivers coding?
> Sdav
> 
> On Wed, Mar 5, 2008 at 5:57 AM, Matthias Schmidt
> <matthias at dragonflybsd.org> wrote:
>> Hi,
>>
>>
>>  * Justin C. Sherrill wrote:
>>  >
>>  > We've applied in previous years - Jeff Hsu did one year, and I put
>>  > together the application last year.  The hardest thing to find was
>>  > students (and they are the thing that helps SoC applications a lot, I
>>  > think).
>>
>>  This is good to know, so we could coordinate that if we have enough
>>  mentors and projects?!?  I put together a small text in the wiki:
>>
>>  http://wiki.dragonflybsd.org/index.cgi/GoogleSoC2008
>>
>>  Feel free to add project or missing stuff.  I'm sure I missed a lot of
>>  things :)
>>
>>
>>  > Any student volunteers?  We have mentors.
>>
>>  According to the discussion we could have some students, who would be a
>>  mentor (besides me)?
>>
>>  Regards
>>
>>         Matthias
>>
>>
> 
> 
>

IF someone starts to write a 3945 Intel driver,
please keep the newer 4965 in mind too.

-- 
Robert Luciani
Chalmers University of Technology, SWE
Department of Computer Science and Engineering
http://www.rluciani.com/public.key




From joerg at britannica.bec.de  Wed Mar  5 12:01:05 2008
From: joerg at britannica.bec.de (Joerg Sonnenberger)
Date: Wed, 5 Mar 2008 12:01:05 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <20080305195711.GA9981@britannica.bec.de>

On Wed, Mar 05, 2008 at 07:56:42PM +0100, Robert Luciani wrote:
> IF someone starts to write a 3945 Intel driver,
> please keep the newer 4965 in mind too.

NetBSD's wpi works quite well. The hardware is quite different from
4945.

Joerg




From sepherosa at gmail.com  Wed Mar  5 17:48:50 2008
From: sepherosa at gmail.com (Sepherosa Ziehau)
Date: Wed, 5 Mar 2008 17:48:50 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <ea7b9c170803051744u22b09484ofc994f034f11df3b@mail.gmail.com>

On Thu, Mar 6, 2008 at 2:56 AM, Robert Luciani <rluciani at gmail.com> wrote:
>  IF someone starts to write a 3945 Intel driver,

"IF" you know that trying to fix any wired bugs in certain drivers
(e.g. ipw, ral) will require you to read through all of the vendor's
linux code (yes, even including register values and position), i.e.
there is not much difference between writing one from scratch and
porting+fixing_bugs, then you probably will not put "IF" at the start
of your sentence.
If what I said sounded too harsh to you, then I was sorry.

>  please keep the newer 4965 in mind too.

Will do, once generic 11n support is brought in from freebsd.

Best Regards,
sephe

-- 
Live Free or Die




From saw at online.de  Thu Mar  6 05:34:14 2008
From: saw at online.de (Sascha Wildner)
Date: Thu, 06 Mar 2008 14:34:14 +0100
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
Message-ID: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>

Hi all,

this is probably as good a moment as any to come out of the forest with 
this. The patch at

http://leaf.dragonflybsd.org/~swildner/nrelease_gui.diff

adds some code to nrelease/ to build a LiveCD with xorg and so on 
(currently, only the xorg metapackages and fluxbox are added). In order 
to build one, you need a local dir with the pkgsrc binary packages (see 
below).

The following commands should then do the trick:

cd /usr/src
make buildworld
make buildkernel
cd nrelease
patch -p 0 </path/to/the/patch
make PKGSRC_PKG_PATH=/path/to/packages/dir/All realquick gui
The resulting ISO will be in /usr/release/dfly-gui.iso then. It will not 
boot into xorg automatically (although this is easily possible), so you 
need to login as root and do startx.

As of now, this all is kind of basic, more a proof of concept than 
anything else. As our release framework installs packages via chroot, 
the current setup just copies _all_ packages to the chroot before 
installing (kind of a hack).

That said, I'm now primarily interested in opinions/ideas/... about the 
direction this should take. Which packages would we like to see on the 
CD? Should it be a generic setup with the "most common things" 
installed, so a system can be quickly setup by the installer (which will 
cpdup /usr/pkg). Or should it be a more specialized set of tools? Or 
even as many packages as possible (Live DVD?). Etc., etc.

Before continuing on it, I'm really interested in people's input so 
don't hold anything back, please. :)

Sascha

--
http://yoyodyne.ath.cx



From rluciani at gmail.com  Thu Mar  6 06:42:03 2008
From: rluciani at gmail.com (Robert Luciani)
Date: Thu, 06 Mar 2008 15:42:03 +0100
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <47d002bc$0$847$415eb37d@crater_reader.dragonflybsd.org>

Sascha Wildner wrote:
> Hi all,
> 
> this is probably as good a moment as any to come out of the forest with
> this. The patch at
> 
> http://leaf.dragonflybsd.org/~swildner/nrelease_gui.diff
> 
> adds some code to nrelease/ to build a LiveCD with xorg and so on
> (currently, only the xorg metapackages and fluxbox are added). In order
> to build one, you need a local dir with the pkgsrc binary packages (see
> below).
> 
> The following commands should then do the trick:
> 
> cd /usr/src
> make buildworld
> make buildkernel
> cd nrelease
> patch -p 0 </path/to/the/patch
> make PKGSRC_PKG_PATH=/path/to/packages/dir/All realquick gui
> 
> The resulting ISO will be in /usr/release/dfly-gui.iso then. It will not
> boot into xorg automatically (although this is easily possible), so you
> need to login as root and do startx.
> 
> As of now, this all is kind of basic, more a proof of concept than
> anything else. As our release framework installs packages via chroot,
> the current setup just copies _all_ packages to the chroot before
> installing (kind of a hack).
> 
> That said, I'm now primarily interested in opinions/ideas/... about the
> direction this should take. Which packages would we like to see on the
> CD? Should it be a generic setup with the "most common things"
> installed, so a system can be quickly setup by the installer (which will
> cpdup /usr/pkg). Or should it be a more specialized set of tools? Or
> even as many packages as possible (Live DVD?). Etc., etc.
> 
> Before continuing on it, I'm really interested in people's input so
> don't hold anything back, please. :)
> 
> Sascha
> 

I think the main point of such a live-cd would be to test
dragonfly-specific features such as vkernels and more. Mplayer and
OpenOffic work the same on all platforms, so they might not be super
important, while irssi, firefox, networking tools, vim, a few more
shells/terminals might make it easier to for people to quickly gauge if
they can reproduce their current productivity and also what is new.

And if the point of a livecd is to test that kind of stuff, then it
would be nice for it to have a kernel that supports as much as possible
like ALTQ, and drivers.

Also if it has lots and lots of programs (thinking multimedia, java,
etc..) it might be hard to keep the future x64 and x86 live-cds on par.
Gentoo had this problem many years ago and it was very bothersome.

-- 
Robert Luciani
Chalmers University of Technology, SWE
Department of Computer Science and Engineering
http://www.rluciani.com/public.key




From matthias at dragonflybsd.org  Thu Mar  6 07:12:43 2008
From: matthias at dragonflybsd.org (Matthias Schmidt)
Date: Thu, 6 Mar 2008 07:12:43 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <20080306150757.GN9833@staatsfeind.org>

* Sascha Wildner wrote:
> Hi all,
> 
> this is probably as good a moment as any to come out of the forest with this. 
> The patch at
> 
> http://leaf.dragonflybsd.org/~swildner/nrelease_gui.diff
> 
> adds some code to nrelease/ to build a LiveCD with xorg and so on (currently, 
> only the xorg metapackages and fluxbox are added). In order to build one, you 
> need a local dir with the pkgsrc binary packages (see below).

Great work Sascha.

I agree with Robert on most of his stated points.
It would be nice to see some DragonFly specific features on the CD
(although I'm not sure if that will work for all features).  A little
environment where most Unix users feel at home (fluxbox, xfce, firefox,
thunderbird, gvim) should be enough.

Big applications like OO.org, java etc won't work because they are not
available as pkgsrc packages neither is it possible to compile them on
DragonFly.  At least to my knowledge.

Regards

	Matthias




From dillon at apollo.backplane.com  Thu Mar  6 09:31:52 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Thu, 6 Mar 2008 09:31:52 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <200803061728.m26HSR3O091809@apollo.backplane.com>


:Hi all,
:
:this is probably as good a moment as any to come out of the forest with 
:this. The patch at
:
:http://leaf.dragonflybsd.org/~swildner/nrelease_gui.diff
:
:adds some code to nrelease/ to build a LiveCD with xorg and so on 
:(currently, only the xorg metapackages and fluxbox are added). In order 
:to build one, you need a local dir with the pkgsrc binary packages (see 
:below).
:
:The following commands should then do the trick:

    It looks reasonable, though the package copy has to be tightened
    up a bit I think.

:...
:installed, so a system can be quickly setup by the installer (which will 
:cpdup /usr/pkg). Or should it be a more specialized set of tools? Or 
:even as many packages as possible (Live DVD?). Etc., etc.
:
:Before continuing on it, I'm really interested in people's input so 
:don't hold anything back, please. :)
:
:Sascha

    I think this is an excellent time to work up a DVD build and to
    add various 'flavor' extras.  So, e.g.:

	make installer gui gui_extras release dvd

    (All 'dvd' would do is generate a dvd compatible image for burning to
    dvd instead of cd).  I did a quick perusal of what I have on my
    workstation:

    * X
    * Firefox
    * Linux emulation
    * Open Office (linux version)
    * fvwm2
    * xpdf
    * freetype2

    I'd also suggest some image editing tools like gimp, and maybe the KDE
    gui suite.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From justin at shiningsilence.com  Thu Mar  6 09:42:44 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Thu, 6 Mar 2008 09:42:44 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <55427.65.106.147.226.1204825168.squirrel@www.shiningsilence.com>

On Thu, March 6, 2008 8:34 am, Sascha Wildner wrote:

> That said, I'm now primarily interested in opinions/ideas/... about the
> direction this should take. Which packages would we like to see on the
> CD? Should it be a generic setup with the "most common things"
> installed, so a system can be quickly setup by the installer (which will
> cpdup /usr/pkg). Or should it be a more specialized set of tools? Or
> even as many packages as possible (Live DVD?). Etc., etc.

What Robert said is good - whatever's needed to enable DragonFly-specific
features.  Along with that would be some sort of documentation (a README? 
A HTML file on whatever desktop we provide) that points people at the
different DragonFly tools, so they know what to try and how to try it.

There's going to be some percentage of people who try DragonFly who don't
know about vkernels, for instance, but there's our chance to educate them.
 I'm probably volunteering myself, aren't I?





From sdavtaker at gmail.com  Thu Mar  6 09:50:09 2008
From: sdavtaker at gmail.com (=?UTF-8?Q?Sd=C3=A4vtaker?=)
Date: Thu, 6 Mar 2008 09:50:09 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <c37d69f60803060947t110750c0sd6b542ea505d188d@mail.gmail.com>

Cool Sascha :-)
I just posted about this 1 or 2 days ago in the SOC project ideas thread.
Want to mentor this one? ;-)
Damian

On Thu, Mar 6, 2008 at 2:28 PM, Matthew Dillon
<dillon at apollo.backplane.com> wrote:
>
>  :Hi all,
>
> :
>  :this is probably as good a moment as any to come out of the forest with
>  :this. The patch at
>  :
>  :http://leaf.dragonflybsd.org/~swildner/nrelease_gui.diff
>  :
>  :adds some code to nrelease/ to build a LiveCD with xorg and so on
>  :(currently, only the xorg metapackages and fluxbox are added). In order
>  :to build one, you need a local dir with the pkgsrc binary packages (see
>  :below).
>  :
>  :The following commands should then do the trick:
>
>     It looks reasonable, though the package copy has to be tightened
>     up a bit I think.
>
>  :...
>  :installed, so a system can be quickly setup by the installer (which will
>
> :cpdup /usr/pkg). Or should it be a more specialized set of tools? Or
>  :even as many packages as possible (Live DVD?). Etc., etc.
>  :
>  :Before continuing on it, I'm really interested in people's input so
>  :don't hold anything back, please. :)
>  :
>  :Sascha
>
>     I think this is an excellent time to work up a DVD build and to
>     add various 'flavor' extras.  So, e.g.:
>
>         make installer gui gui_extras release dvd
>
>     (All 'dvd' would do is generate a dvd compatible image for burning to
>     dvd instead of cd).  I did a quick perusal of what I have on my
>     workstation:
>
>     * X
>     * Firefox
>     * Linux emulation
>     * Open Office (linux version)
>     * fvwm2
>     * xpdf
>     * freetype2
>
>     I'd also suggest some image editing tools like gimp, and maybe the KDE
>     gui suite.
>
>                                         -Matt
>                                         Matthew Dillon
>                                         <dillon at backplane.com>
>



-- 
Sd?vtaker prays to Rikku goddess for a good treasure.



From saw at online.de  Thu Mar  6 11:54:01 2008
From: saw at online.de (Sascha Wildner)
Date: Thu, 06 Mar 2008 20:54:01 +0100
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <47d04ba2$0$856$415eb37d@crater_reader.dragonflybsd.org>

Matthew Dillon wrote:
    It looks reasonable, though the package copy has to be tightened
    up a bit I think.
It looks as if it would work with mount_null'ing the chroot's 
/tmp/packages. I'll have a better patch ready tomorrow.

Sascha

--
http://yoyodyne.ath.cx



From c.turner at 199technologies.org  Thu Mar  6 19:11:44 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Thu, 6 Mar 2008 19:11:44 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Misc. ACPI / suspend
In-Reply-To: <47CA073B.6020106@199technologies.org>
Message-ID: <47D0B079.3060905@199technologies.org>

Chris Turner wrote:
Wondering if anyone more well versed in the ACPI implementation could
comment on the applicability of:
http://lkml.org/lkml/2007/4/6/69

Doing a little digging, it seems like

. /platform/pc32/i386/i686_mem.c

*might* have the necessary infrastructure to remap the MTRR's per the 
thread referenced,

but:

. /platform/pc32/acpica5/acpi_wakeup.c

doesn't seem to be using this infrastructure..

I'm no where near reaching an understanding of this yet,
but I'm wondering 3 things:
1) does anyone have ACPI (instead of APM)
   sleep / suspend / wakeup working on Dfly ?
2) If so, what machines are being used ?
3) Same question for other BSDs - my understanding is NetBSD is most
   'advanced' w/r/t power managment - but I'm not 100% on this ...
would looove to have a sleeping / resuming / scaling laptop running some 
BSD flavor.. am willing to work towards that end, esp. w/r/t Dfly -
trying to chart a course to figguring this out.

Thanks all,

- Chris




From c.turner at 199technologies.org  Thu Mar  6 19:12:33 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Thu, 6 Mar 2008 19:12:33 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: PCI Bios / Interrupt remapping / etc
Message-ID: <47D0B211.6000002@199technologies.org>

Doing a bit of digging here for my long-standing CBB+SIO interupt and 
buffer problem -

one machine I've tested against was an OpenBSD machine, which didn't
always work to handle the cardbus sio card on a PCI cardbus adapter
-

tuning up some of the device flags in:

http://www.openbsd.org/cgi-bin/man.cgi?query=pcibios&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=html

seems to have alleviated the problem for that os..

I'm just only starting to get up to speed on how DF handles these types 
of things (namely initial PIC / interrupt layout at boot time device 
enumeration), but am wondering if anyone familiar with this area of the 
code has any comments / advice w/r/t the capabilities of the DF bios 
drivers
and the various quirks / fixup mentioned in the link above..

looking to possibly investigate fixing up some of these issues over time.

Thanks

- Chris







From pavalos at theshell.com  Fri Mar  7 01:14:55 2008
From: pavalos at theshell.com (Peter Avalos)
Date: Fri, 7 Mar 2008 01:14:55 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: cam locking
Message-ID: <20080307091024.GC1652@ylem.theshell.com>

So I've been working on locking up cam using lockmgr locks, and here's
what I have so far:

http://www.theshell.com/~pavalos/wip/cam-lock.patch

Most of the work is obtained from FreeBSD.  I've only been running this
on my SCSI machine for a day, but because the patch is so large, I wanted
to make it available for people to review if they have some spare time.

Thanks,
Peter
Attachment:
pgp00002.pgp
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00002.pgp
Type: application/octet-stream
Size: 197 bytes
Desc: "Description: PGP signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080307/9a17ecd8/attachment-0019.obj>

From jspringe at uos.de  Fri Mar  7 03:25:17 2008
From: jspringe at uos.de (Jost Tobias Springenberg)
Date: Fri, 7 Mar 2008 12:25:17 +0100
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <20080307122517.72c9e2b1.jspringe@uos.de>

On Tue, 4 Mar 2008 11:28:15 -0500 (EST)
"Justin C. Sherrill" <justin at shiningsilence.com> wrote:

> On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
> > Hi,
> >
> > Google just announced its Summer of Code for 2008:
> >
> > 	http://code.google.com/soc/2008/
> >
> > I think this would be a great opportunity for DragonFly to participate
> > as a mentoring organisation.  We could attract new developers and could
> > get code/work done.  Looking at the SoC results of the other BSDs most
> > of their projects were a success.  Of course, not all, but a reasonable
> > percentage.  See [1] and [2].
> 
> We've applied in previous years - Jeff Hsu did one year, and I put
> together the application last year.  The hardest thing to find was
> students (and they are the thing that helps SoC applications a lot, I
> think).
> 
> Any student volunteers?  We have mentors.
> 

I read this mailing list for quite a while now and thought about contributing stuff
to DFfly several times, so yes why not take this opportunity if it's there.

-- 
Jost Tobias Springenberg <jspringe at uos.de>




From tgen at netphreax.net  Fri Mar  7 05:17:27 2008
From: tgen at netphreax.net (Thomas E. Spanjaard)
Date: Fri, 7 Mar 2008 05:17:27 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: PCI Bios / Interrupt remapping / etc
In-Reply-To: <47D0B211.6000002@199technologies.org>
Message-ID: <47D13FB4.5080306@netphreax.net>

Chris Turner wrote:
Doing a bit of digging here for my long-standing CBB+SIO interupt and 
buffer problem -

one machine I've tested against was an OpenBSD machine, which didn't
always work to handle the cardbus sio card on a PCI cardbus adapter
-

tuning up some of the device flags in:

http://www.openbsd.org/cgi-bin/man.cgi?query=pcibios&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=html 

seems to have alleviated the problem for that os..

I'm just only starting to get up to speed on how DF handles these types 
of things (namely initial PIC / interrupt layout at boot time device 
enumeration), but am wondering if anyone familiar with this area of the 
code has any comments / advice w/r/t the capabilities of the DF bios 
drivers
and the various quirks / fixup mentioned in the link above..

looking to possibly investigate fixing up some of these issues over time.
Our code that handles issues like this (in cases where you're not using 
APICs, just PICs and PIRs) lives in bus/pci/i386/. Not that running 
without APIC support is all that common on modern machines anymore...
--
        Thomas E. Spanjaard
        tgen at netphreax.net
Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00003.pgp
Type: application/octet-stream
Size: 186 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080307/61366b5c/attachment-0019.obj>

From tgen at netphreax.net  Fri Mar  7 05:16:51 2008
From: tgen at netphreax.net (Thomas E. Spanjaard)
Date: Fri, 7 Mar 2008 05:16:51 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Misc. ACPI / suspend
In-Reply-To: <47CA073B.6020106@199technologies.org>
Message-ID: <47D13F07.9080308@netphreax.net>

Chris Turner wrote:
1) does anyone have ACPI (instead of APM)
   sleep / suspend / wakeup working on Dfly ?
2) If so, what machines are being used ?
3) Same question for other BSDs - my understanding is NetBSD is most
   'advanced' w/r/t power managment - but I'm not 100% on this ...
would looove to have a sleeping / resuming / scaling laptop running some 
BSD flavor.. am willing to work towards that end, esp. w/r/t Dfly -
trying to chart a course to figguring this out.
I have ACPI S3 suspend working like a charm on my IBM ThinkPad R40 
(Pentium M "Banias" 1.3GHz, speedstepping works just fine), running 
NetBSD 3.99.21.
--
        Thomas E. Spanjaard
        tgen at netphreax.net
Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00004.pgp
Type: application/octet-stream
Size: 186 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080307/de3e5104/attachment-0019.obj>

From civilizd at gmail.com  Fri Mar  7 09:06:41 2008
From: civilizd at gmail.com (Vita "CiV" Cizek)
Date: Fri, 7 Mar 2008 09:06:41 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <98d564710803070853q1c73d795m6e6c5cc5049fa099@mail.gmail.com>

>  Any student volunteers?  We have mentors.
>
I am interested too, especially in some kernel-related work.




From justin at shiningsilence.com  Sat Mar  8 12:07:51 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Sat, 8 Mar 2008 12:07:51 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google SoC 2008 - mentors mentors mentors
Message-ID: <51558.192.168.0.252.1205006403.squirrel@www.shiningsilence.com>

If you are willing to mentor for the Google 2008 Summer of Code, please
speak up.  Right now we have: (from our wiki page)

Matthias
Sephe
TGEN
corecode

Part of the application process includes naming people as mentors (student
applications come later), so I want to get as complete a list as possible.

The application is due on the 12th, so if you want to mentor, now's the
time to say so.

Google's SoC FAQ is here: http://code.google.com/soc/2008/faqs.html

Our wiki page is here: http://wiki.dragonflybsd.org/index.cgi/GoogleSoC2008

- much credit to Matthias and others for getting that set up.





From saw at online.de  Sat Mar  8 14:26:07 2008
From: saw at online.de (Sascha Wildner)
Date: Sat, 08 Mar 2008 23:26:07 +0100
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <47d31245$0$848$415eb37d@crater_reader.dragonflybsd.org>

Sascha Wildner wrote:
Hi all,

this is probably as good a moment as any to come out of the forest with 
this. The patch at

http://leaf.dragonflybsd.org/~swildner/nrelease_gui.diff
Ok, I have committed the stuff as an example.

I'm not sure if my free time permits to work on a full-blown live CD 
with X11 and other good things (I already feel my interest wandering off 
in other directions) so if anyone wants to pick up the ball, go ahead. :)

Sascha

--
http://yoyodyne.ath.cx



From qhwt+dfly at les.ath.cx  Tue Mar 11 22:21:31 2008
From: qhwt+dfly at les.ath.cx (YONETANI Tomokazu)
Date: Tue, 11 Mar 2008 22:21:31 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Misc. ACPI / suspend
In-Reply-To: <47CA073B.6020106@199technologies.org>
Message-ID: <20080312051219.GA56091@les.ath.cx>

On Thu, Mar 06, 2008 at 10:03:21PM -0500, Chris Turner wrote:
> 1) does anyone have ACPI (instead of APM)
>    sleep / suspend / wakeup working on Dfly ?
> 2) If so, what machines are being used ?

Dynabook SS3500 (http://www.tlt.co.jp/pc/catalog/ss/02110735/index_j.htm).
It's old and can get very hot(thus frequently turns on the cooling fan)
even when it's running Windows.  I haven't turned it on for about several
months though.

Cheers.




From c.turner at 199technologies.org  Wed Mar 12 04:37:22 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Wed, 12 Mar 2008 04:37:22 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Misc. ACPI / suspend
In-Reply-To: <47CA073B.6020106@199technologies.org>
Message-ID: <47D7BEE3.6010907@199technologies.org>

YONETANI Tomokazu wrote:
On Thu, Mar 06, 2008 at 10:03:21PM -0500, Chris Turner wrote:
1) does anyone have ACPI (instead of APM)
   sleep / suspend / wakeup working on Dfly ?
Cheers.
ditto..

Suppose this should go to docs@ - in any case..

Thinking about setting up a wiki page on the issue so we
can discuss / track what 'good' hardware / drivers / implementations / 
etc are 'out there' - anyone have any suggestions on where this should
go?

http://wiki.dragonflybsd.org/index.cgi/acpi-overview.html

Remains from the handbook conversion - but I'm hesitant to 'over wikify'
this ..



From c.turner at 199technologies.org  Wed Mar 12 15:36:52 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Wed, 12 Mar 2008 15:36:52 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: devel/cscope
Message-ID: <47D85A08.8040103@199technologies.org>

why oh why did I take so long to try this out !!!

just sharing my eureka moment with the list..

- Chris




From dudu at dudu.ro  Wed Mar 12 15:50:14 2008
From: dudu at dudu.ro (Vlad GALU)
Date: Wed, 12 Mar 2008 15:50:14 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: devel/cscope
In-Reply-To: <47D85A08.8040103@199technologies.org>
Message-ID: <ad79ad6b0803121547r2bf67ffep9e40badaac6490f8@mail.gmail.com>

On 3/13/08, Chris Turner <c.turner at 199technologies.org> wrote:
> why oh why did I take so long to try this out !!!
>
>  just sharing my eureka moment with the list..


    Works nice with vim, too!

>
>
>  - Chris
>


-- 
Mahnahmahnah!




From justin at shiningsilence.com  Sun Mar 16 21:06:13 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Sun, 16 Mar 2008 21:06:13 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: binary packages for 1.12 coming in
Message-ID: <1372.192.168.0.252.1205726088.squirrel@www.shiningsilence.com>

The binary build for 1.12 is taking quite a while.  I've started copying
in newly built packages to
pkgbox.dragonflybsd.org/packages/DragonFly-1.12/i386/ - this should be
getting copied out to mirrors over the next while.

There are currently 1283 packages built, which leaves a whole lot to go;
I'll copy new packages in as they complete.





From hasso at estpak.ee  Wed Mar 19 04:31:08 2008
From: hasso at estpak.ee (Hasso Tepper)
Date: Wed, 19 Mar 2008 04:31:08 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Some questions regarding ACPI
Message-ID: <200803191322.46366.hasso@estpak.ee>

I'm working on bringing in some laptop (and especially thinkpad) specific 
ACPI code from FreeBSD into DragonFly. I never touched ACPI stuff before 
and haven't followed it much either, so I have some questions.

* FreeBSD uses ACPI_SERIAL_* heavily. What's the locking situation in 
  DragonFly and why?

* As far as I can see, PCI integration is commented out in DragonFly. 
  What's the state of it and why?

* platform/pc32/acpica5/acpi_toshiba.c - why is it there? I don't think 
  that this is something pc32 specific in it and it should work in pc64 
  laptops as well. Any objections to move it into 
  dev/acpica5/acpi_toshiba/ ?

What's the current status of ACPI in general? AFAICS our acpica is quite 
old - what needs to be done to bring in newer one?


-- 
Hasso




From qhwt+dfly at les.ath.cx  Wed Mar 19 09:24:50 2008
From: qhwt+dfly at les.ath.cx (YONETANI Tomokazu)
Date: Wed, 19 Mar 2008 09:24:50 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Some questions regarding ACPI
In-Reply-To: <200803191322.46366.hasso@estpak.ee>
Message-ID: <20080319161703.GA51509@les.ath.cx>

On Wed, Mar 19, 2008 at 01:22:46PM +0200, Hasso Tepper wrote:
> I'm working on bringing in some laptop (and especially thinkpad) specific 
> ACPI code from FreeBSD into DragonFly. I never touched ACPI stuff before 
> and haven't followed it much either, so I have some questions.

So you want to port some of ACPI support drivers, or to do a fresh port
of ACPI driver from FreeBSD?

> * FreeBSD uses ACPI_SERIAL_* heavily. What's the locking situation in 
>   DragonFly and why?

The current ACPI driver in DragonFly is based on that of FreeBSD as of
end of June, 2004, plus some fixes brought in later (and ACPICA part
has been updated twice since then).  That was before they introduced
the MPSAFE changes into ACPI code, and we use critical section
(crit_{enter,exit}) in most places (and lockmgr lock in a few place).

> * As far as I can see, PCI integration is commented out in DragonFly. 
>   What's the state of it and why?

When we replaced the implementation taken from FreeBSD 4.x with that
brought from FreeBSD 5.x, which added the PCI part, many people
experienced problems until they turned off ACPI completely, or add "pci"
to "debug.acpi.disabled" loader variable.  AFAIK the PCI part in the ACPI
driver almost hasn't been adjusted to work with our version of PCI code.

> * platform/pc32/acpica5/acpi_toshiba.c - why is it there? I don't think 
>   that this is something pc32 specific in it and it should work in pc64 
>   laptops as well. Any objections to move it into 
>   dev/acpica5/acpi_toshiba/ ?

In FreeBSD it used to be sitting at i386/acpica/acpi_toshiba.c and was
later moved into acpi_support.  That change hasn't hit our tree (in fact,
we have no acpi support drivers other than that).  It seems that FreeBSD
has them in dev/acpi_support now, and we for some reason have that
directory in our CVS repository (but containing no files in it).

> What's the current status of ACPI in general? AFAICS our acpica is quite 
> old - what needs to be done to bring in newer one?

Actually, it's not very important to keep just ACPICA latest, but
if you bring the ACPI driver from FreeBSD you need to bring ACPICA code
that matches their version, and it IS important.  And it generally requires
you much work to just update ACPICA part anyway because of how they
change things on every release.

Cheers.




From hasso at estpak.ee  Wed Mar 19 12:29:52 2008
From: hasso at estpak.ee (Hasso Tepper)
Date: Wed, 19 Mar 2008 12:29:52 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Some questions regarding ACPI
In-Reply-To: <200803191322.46366.hasso@estpak.ee>
Message-ID: <200803192115.35396.hasso@estpak.ee>

YONETANI Tomokazu wrote:
> On Wed, Mar 19, 2008 at 01:22:46PM +0200, Hasso Tepper wrote:
> > I'm working on bringing in some laptop (and especially thinkpad)
> > specific ACPI code from FreeBSD into DragonFly. I never touched ACPI
> > stuff before and haven't followed it much either, so I have some
> > questions.
>
> So you want to port some of ACPI support drivers, or to do a fresh port
> of ACPI driver from FreeBSD?

I'm only interested in support drivers and the reason is pure practical - 
newer thinkpads handle less and less hotkeys etc in hardware and require 
support form OS. acpi_ibm and acpi_video are examples of such modules 
which would help a lot of these newer thinkpad users.

acpi_ibm is almost ready to commit (renamed to acpi_thinkpad though).

> > * FreeBSD uses ACPI_SERIAL_* heavily. What's the locking situation in
> >   DragonFly and why?
>
> The current ACPI driver in DragonFly is based on that of FreeBSD as of
> end of June, 2004, plus some fixes brought in later (and ACPICA part
> has been updated twice since then).  That was before they introduced
> the MPSAFE changes into ACPI code, and we use critical section
> (crit_{enter,exit}) in most places (and lockmgr lock in a few place).

Mkay. Will look at more closely.

> > * As far as I can see, PCI integration is commented out in DragonFly.
> >   What's the state of it and why?
>
> When we replaced the implementation taken from FreeBSD 4.x with that
> brought from FreeBSD 5.x, which added the PCI part, many people
> experienced problems until they turned off ACPI completely, or add
> "pci" to "debug.acpi.disabled" loader variable.  AFAIK the PCI part in
> the ACPI driver almost hasn't been adjusted to work with our version of
> PCI code.

I'm afraid that it's beyond my skills, but while looking at acpi_video I 
discovered that it's hard to handle correctly without PCI support.

> > * platform/pc32/acpica5/acpi_toshiba.c - why is it there? I don't
> > think that this is something pc32 specific in it and it should work
> > in pc64 laptops as well. Any objections to move it into
> >   dev/acpica5/acpi_toshiba/ ?
>
> In FreeBSD it used to be sitting at i386/acpica/acpi_toshiba.c and was
> later moved into acpi_support.  That change hasn't hit our tree (in
> fact, we have no acpi support drivers other than that).  It seems that
> FreeBSD has them in dev/acpi_support now, and we for some reason have
> that directory in our CVS repository (but containing no files in it).

I don't see it ;). Makes sense though. So, any objections if I move 
acpi_toshiba into sys/dev/acpi_support and add new acpi_thinkpad there as 
well? 

> > What's the current status of ACPI in general? AFAICS our acpica is
> > quite old - what needs to be done to bring in newer one?
>
> Actually, it's not very important to keep just ACPICA latest, but
> if you bring the ACPI driver from FreeBSD you need to bring ACPICA code
> that matches their version, and it IS important.  And it generally
> requires you much work to just update ACPICA part anyway because of how
> they change things on every release.

Someone else has to do it :).

Thanks for info.


-- 
Hasso




From dillon at apollo.backplane.com  Wed Mar 19 14:01:13 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Wed, 19 Mar 2008 14:01:13 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: panic: assertion: hammer_btree_cmp(cursor->left_bound,	&cursor->node->ondisk->elms[0].leaf.base) <= 0 in btree_split_leaf
In-Reply-To: <200802232204.m1NM4cxd046264@apollo.backplane.com>
Message-ID: <200803192054.m2JKsjwn045137@apollo.backplane.com>


:Hi.
:While trying to find a procedure to reliably reproduce the panic
:I reported last time, I caught a different panic (uploaded at
: ~y0netan1/crash/9/ on my leaf account).  I wrote the following shell
:script (make sure to edit variables DISKS and MOUNTPT before using this
:script or it may trash your system):
:  #!/bin/sh -ex
:  DISKS="/dev/ad0s1f"
:  MOUNTPT=/mnt/HAMMER
:
:  cd /
:  newfs_hammer -L TEST $DISKS
:  for i in `seq 1 100`; do
:..
:And the panic is triggered by rm command.
:I'll try to see if it's possible to reproduce the last one without
:unmounting then mounting the HAMMER fs.
:
:Cheers.

    I believe I have fixed this panic.  hammer_make_separator() had a bug
    in it.

    There is still an issue with the node ref count on umount.

    Please continue to life-test the code.  The reblocking code
    (hammer reblock /mnt) should work now, as should the pruning code
    (e.g. hammer prune /mnt everything).

    The filesystem full case is still not handled and will cause bad things
    to happen.  The undo code isn't finished yet either but it is getting
    there (it's writing stuff out but not setting the sequence number and
    not trying to recover-on-mount yet).

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From qhwt+dfly at les.ath.cx  Wed Mar 19 19:45:40 2008
From: qhwt+dfly at les.ath.cx (YONETANI Tomokazu)
Date: Wed, 19 Mar 2008 19:45:40 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Some questions regarding ACPI
In-Reply-To: <200803191322.46366.hasso@estpak.ee>
Message-ID: <20080320023828.GA53648@les.ath.cx>

On Wed, Mar 19, 2008 at 09:15:35PM +0200, Hasso Tepper wrote:
> YONETANI Tomokazu wrote:
> > On Wed, Mar 19, 2008 at 01:22:46PM +0200, Hasso Tepper wrote:
> > > I'm working on bringing in some laptop (and especially thinkpad)
> > > specific ACPI code from FreeBSD into DragonFly. I never touched ACPI
> > > stuff before and haven't followed it much either, so I have some
> > > questions.
> >
> > So you want to port some of ACPI support drivers, or to do a fresh port
> > of ACPI driver from FreeBSD?
> 
> I'm only interested in support drivers and the reason is pure practical - 
> newer thinkpads handle less and less hotkeys etc in hardware and require 
> support form OS. acpi_ibm and acpi_video are examples of such modules 
> which would help a lot of these newer thinkpad users.
> 
> acpi_ibm is almost ready to commit (renamed to acpi_thinkpad though).

Ah, that's a good news!  My only concern is that ISTR someone mentioned
me that his colleague was thinking about porting ACPI driver itself,
so if you're not the person you may want to collaborate with him/her
so as not to waste the effort or time...

			:

> > In FreeBSD it used to be sitting at i386/acpica/acpi_toshiba.c and was
> > later moved into acpi_support.  That change hasn't hit our tree (in
> > fact, we have no acpi support drivers other than that).  It seems that
> > FreeBSD has them in dev/acpi_support now, and we for some reason have
> > that directory in our CVS repository (but containing no files in it).
> 
> I don't see it ;). Makes sense though. So, any objections if I move 
> acpi_toshiba into sys/dev/acpi_support and add new acpi_thinkpad there as 
> well? 

Sorry, I checked the CVS repository and it doesn't exist actually :)
I don't have any objection to moving it there.

Cheers.




From hasso at estpak.ee  Thu Mar 20 00:14:05 2008
From: hasso at estpak.ee (Hasso Tepper)
Date: Thu, 20 Mar 2008 00:14:05 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Some questions regarding ACPI
In-Reply-To: <200803191322.46366.hasso@estpak.ee>
Message-ID: <200803200904.50875.hasso@estpak.ee>

YONETANI Tomokazu wrote:
> On Wed, Mar 19, 2008 at 09:15:35PM +0200, Hasso Tepper wrote:
> > acpi_ibm is almost ready to commit (renamed to acpi_thinkpad though).
>
> Ah, that's a good news!  My only concern is that ISTR someone mentioned
> me that his colleague was thinking about porting ACPI driver itself,
> so if you're not the person you may want to collaborate with him/her
> so as not to waste the effort or time...

Current state in my repo is attached. It should work on 1.12 as well as it 
doesn't depend yet on moving stuff around.

add-acpi-if-m.patch adds some new stuff to the ACPI code to access 
embedded controllers and match ACPI devices by ID. Not sure how, where 
and whether at all these should be documented.

add-acpi-thinkpad.patch is the driver itself. Note that some stuff doesn't 
work yet on newer thinkpads, I plan to work on it later.

There is still some things to do though. I have to decide what to do with 
led(4) part and with locking. There is also one fatal issue - laptop 
locks up hardly (no panic) while unloading module. Any idea regarding 
this is welcome. And of course test results :).


-- 
Hasso
# HG changeset patch
# User Hasso Tepper <hasso at estpak.ee>
# Date 1205919290 -7200
# Branch HEAD
# Node ID 5a6e2705cc95a340abf973ae5df73ef34e070b79
# Parent  cd529e2e7f849034d5d5a0973cb98af50db0e797
imported patch adding-acpi-if-m.patch

diff --git a/sys/conf/files b/sys/conf/files
--- a/sys/conf/files
+++ b/sys/conf/files
@@ -1387,6 +1387,7 @@ emulation/dragonfly12/dfbsd12_stat.c	non
 ${OSACPI_MI_DIR}/acpi_cmbat.c		optional acpi
 ${OSACPI_MI_DIR}/acpi_cpu.c		optional acpi
 ${OSACPI_MI_DIR}/acpi_ec.c		optional acpi
+${OSACPI_MI_DIR}/acpi_if.m		optional acpi
 ${OSACPI_MI_DIR}/acpi_isab.c		optional acpi isa
 ${OSACPI_MI_DIR}/acpi_lid.c		optional acpi
 ${OSACPI_MI_DIR}/acpi_package.c		optional acpi
diff --git a/sys/conf/kmod.mk b/sys/conf/kmod.mk
--- a/sys/conf/kmod.mk
+++ b/sys/conf/kmod.mk
@@ -275,7 +275,7 @@ MFILES?= kern/bus_if.m kern/device_if.m 
     bus/pccard/card_if.m bus/pccard/power_if.m bus/pci/pci_if.m \
     bus/pci/pcib_if.m \
     bus/ppbus/ppbus_if.m bus/smbus/smbus_if.m bus/usb/usb_if.m \
-    dev/disk/nata/ata_if.m \
+    dev/acpica5/acpi_if.m dev/disk/nata/ata_if.m \
     dev/sound/pcm/ac97_if.m dev/sound/pcm/channel_if.m \
     dev/sound/pcm/feeder_if.m dev/sound/pcm/mixer_if.m \
     libiconv/iconv_converter_if.m dev/agp/agp_if.m opencrypto/crypto_if.m
diff --git a/sys/dev/acpica5/Makefile b/sys/dev/acpica5/Makefile
--- a/sys/dev/acpica5/Makefile
+++ b/sys/dev/acpica5/Makefile
@@ -69,12 +69,14 @@ SRCS+=  acpi_package.c
 # SRCS+=	acpi_pci.c acpi_pcib.c acpi_pcib_acpi.c acpi_pcib_pci.c
 # SRCS+=	acpi_pci_link.c
 SRCS+=  acpi_powerres.c acpi_resource.c acpi_thermal.c
-SRCS+=  acpi_timer.c
+SRCS+=  acpi_timer.c acpi_if.c
 SRCS+=  OsdDebug.c
 SRCS+=  OsdHardware.c OsdInterface.c OsdInterrupt.c OsdMemory.c OsdSchedule.c
 SRCS+=  OsdStream.c OsdSynch.c OsdTable.c OsdEnvironment.c
 SRCS+=  opt_acpi.h opt_bus.h opt_ddb.h
-SRCS+=  device_if.h bus_if.h pci_if.h pcib_if.h isa_if.h
+SRCS+=  device_if.h bus_if.h pci_if.h pcib_if.h isa_if.h acpi_if.h
+MFILES = kern/device_if.m kern/bus_if.m bus/pci/pci_if.m bus/pci/pcib_if.m
+MFILES+= bus/isa/isa_if.m dev/acpica5/acpi_if.m
 
 # Debugging support
 DBSRC=	dbcmds.c dbdisply.c dbexec.c dbfileio.c dbhistry.c
diff --git a/sys/dev/acpica5/acpi.c b/sys/dev/acpica5/acpi.c
--- a/sys/dev/acpica5/acpi.c
+++ b/sys/dev/acpica5/acpi.c
@@ -135,6 +135,7 @@ static int	acpi_release_resource(device_
 			int rid, struct resource *r);
 static uint32_t	acpi_isa_get_logicalid(device_t dev);
 static int	acpi_isa_get_compatid(device_t dev, uint32_t *cids, int count);
+static char	*acpi_device_id_probe(device_t bus, device_t dev, char **ids);
 static int	acpi_isa_pnp_probe(device_t bus, device_t child,
 			struct isa_pnp_id *ids);
 static void	acpi_probe_children(device_t bus);
@@ -189,6 +190,9 @@ static device_method_t acpi_methods[] = 
     DEVMETHOD(bus_deactivate_resource,	bus_generic_deactivate_resource),
     DEVMETHOD(bus_setup_intr,		bus_generic_setup_intr),
     DEVMETHOD(bus_teardown_intr,	bus_generic_teardown_intr),
+
+    /* ACPI bus */
+    DEVMETHOD(acpi_id_probe,		acpi_device_id_probe),
 
     /* ISA emulation */
     DEVMETHOD(isa_pnp_probe,		acpi_isa_pnp_probe),
@@ -1121,6 +1125,24 @@ out:
 	AcpiOsFree(buf.Pointer);
     ACPI_UNLOCK;
     return_VALUE (valid);
+}
+
+static char *
+acpi_device_id_probe(device_t bus, device_t dev, char **ids) 
+{
+    ACPI_HANDLE h;
+    int i;
+
+    h = acpi_get_handle(dev);
+    if (ids == NULL || h == NULL || acpi_get_type(dev) != ACPI_TYPE_DEVICE)
+	return (NULL);
+
+    /* Try to match one of the array of IDs with a HID or CID. */
+    for (i = 0; ids[i] != NULL; i++) {
+	if (acpi_MatchHid(h, ids[i]))
+	    return (ids[i]);
+    }
+    return (NULL);
 }
 
 static int
diff --git a/sys/dev/acpica5/acpi_ec.c b/sys/dev/acpica5/acpi_ec.c
--- a/sys/dev/acpica5/acpi_ec.c
+++ b/sys/dev/acpica5/acpi_ec.c
@@ -327,11 +327,19 @@ static ACPI_STATUS	EcWrite(struct acpi_e
 				UINT8 *Data);
 static int		acpi_ec_probe(device_t dev);
 static int		acpi_ec_attach(device_t dev);
+static int		acpi_ec_read_method(device_t dev, u_int addr,
+				ACPI_INTEGER *val, int width);
+static int		acpi_ec_write_method(device_t dev, u_int addr,
+				ACPI_INTEGER val, int width);
 
 static device_method_t acpi_ec_methods[] = {
     /* Device interface */
     DEVMETHOD(device_probe,	acpi_ec_probe),
     DEVMETHOD(device_attach,	acpi_ec_attach),
+
+    /* Embedded controller interface */
+    DEVMETHOD(acpi_ec_read,     acpi_ec_read_method),
+    DEVMETHOD(acpi_ec_write,    acpi_ec_write_method),
 
     {0, 0}
 };
@@ -620,6 +628,33 @@ error:
 			     sc->ec_data_res);
     /* mtx_destroy(&sc->ec_mtx); */
     return (ENXIO);
+}
+
+/* Methods to allow other devices (e.g., smbat) to read/write EC space. */
+static int
+acpi_ec_read_method(device_t dev, u_int addr, ACPI_INTEGER *val, int width)
+{
+    struct acpi_ec_softc *sc;
+    ACPI_STATUS status;
+
+    sc = device_get_softc(dev);
+    status = EcSpaceHandler(ACPI_READ, addr, width * 8, val, sc, NULL);
+    if (ACPI_FAILURE(status))
+        return (ENXIO);
+    return (0);
+}
+
+static int
+acpi_ec_write_method(device_t dev, u_int addr, ACPI_INTEGER val, int width)
+{
+    struct acpi_ec_softc *sc;
+    ACPI_STATUS status;
+
+    sc = device_get_softc(dev);
+    status = EcSpaceHandler(ACPI_WRITE, addr, width * 8, &val, sc, NULL);
+    if (ACPI_FAILURE(status))
+        return (ENXIO);
+    return (0);
 }
 
 static void
diff --git a/sys/dev/acpica5/acpi_if.m b/sys/dev/acpica5/acpi_if.m
new file mode 100644
--- /dev/null
+++ b/sys/dev/acpica5/acpi_if.m
@@ -0,0 +1,92 @@
+#-
+# Copyright (c) 2004 Nate Lawson
+# All rights reserved.
+#
+# Redistribution and use in source and binary forms, with or without
+# modification, are permitted provided that the following conditions
+# are met:
+# 1. Redistributions of source code must retain the above copyright
+#    notice, this list of conditions and the following disclaimer.
+# 2. Redistributions in binary form must reproduce the above copyright
+#    notice, this list of conditions and the following disclaimer in the
+#    documentation and/or other materials provided with the distribution.
+#
+# THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
+# ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+# ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
+# FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+# DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+# OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+# HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+# LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+# OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+# SUCH DAMAGE.
+#
+# $DragonFly$
+#
+
+#include <sys/bus.h>
+#include <sys/types.h>
+#include "acpi.h"
+
+INTERFACE acpi;
+
+#
+# Default implementation for acpi_id_probe().
+#
+CODE {
+	static char *
+	acpi_generic_id_probe(device_t bus, device_t dev, char **ids)
+	{
+		return (NULL);
+	}
+};
+
+#
+# Check a device for a match in a list of ID strings.  The strings can be
+# EISA PNP IDs or ACPI _HID/_CID values.
+#
+# device_t bus:  parent bus for the device
+#
+# device_t dev:  device being considered
+#
+# char **ids:  array of ID strings to consider
+#
+# Returns:  ID string matched or NULL if no match
+#
+METHOD char * id_probe {
+	device_t	bus;
+	device_t	dev;
+	char		**ids;
+} DEFAULT acpi_generic_id_probe;
+
+#
+# Read embedded controller (EC) address space
+#
+# device_t dev:  EC device
+# u_int addr:  Address to read from in EC space
+# ACPI_INTEGER *val:  Location to store read value
+# int width:  Size of area to read in bytes
+#
+METHOD int ec_read {
+	device_t	dev;
+	u_int		addr;
+	ACPI_INTEGER	*val;
+	int		width;
+};
+
+#
+# Write embedded controller (EC) address space
+#
+# device_t dev:  EC device
+# u_int addr:  Address to write to in EC space
+# ACPI_INTEGER val:  Value to write
+# int width:  Size of value to write in bytes
+#
+METHOD int ec_write {
+	device_t	dev;
+	u_int		addr;
+	ACPI_INTEGER	val;
+	int		width;
+};
diff --git a/sys/dev/acpica5/acpivar.h b/sys/dev/acpica5/acpivar.h
--- a/sys/dev/acpica5/acpivar.h
+++ b/sys/dev/acpica5/acpivar.h
@@ -29,6 +29,7 @@
  * $DragonFly: src/sys/dev/acpica5/acpivar.h,v 1.12 2007/10/23 03:04:48 y0netan1 Exp $
  */
 
+#include "acpi_if.h"
 #include "bus_if.h"
 #include <sys/eventhandler.h>
 #include <sys/sysctl.h>
# HG changeset patch
# User Hasso Tepper <hasso at estpak.ee>
# Date 1205995474 -7200
# Branch HEAD
# Node ID c5db8d4a7c6b25a8576a8d42c5029aaf0e23bfb6
# Parent  5a6e2705cc95a340abf973ae5df73ef34e070b79
[mq]: adding-acpi-thinkpad.patch

diff --git a/sys/dev/acpica5/Makefile b/sys/dev/acpica5/Makefile
--- a/sys/dev/acpica5/Makefile
+++ b/sys/dev/acpica5/Makefile
@@ -117,7 +117,7 @@ acpi_wakecode.h: acpi_wakecode.S
 	${MAKE} -f ${SYSDIR}/${OSACPI_MD_DIR}/Makefile \
 		MAKESRCPATH=${SYSDIR}/${OSACPI_MD_DIR}
 
-SUBDIR=	acpi_toshiba
+SUBDIR=	acpi_toshiba acpi_thinkpad
 all: ${PROG} ${SUBDIR}
 
 # *.o file for each patched *.c file is created under the same directory,
diff --git a/sys/dev/acpica5/acpi_thinkpad/Makefile b/sys/dev/acpica5/acpi_thinkpad/Makefile
new file mode 100644
--- /dev/null
+++ b/sys/dev/acpica5/acpi_thinkpad/Makefile
@@ -0,0 +1,9 @@
+# $DragonFly$
+
+SYSDIR?=${.CURDIR}/../../..
+
+KMOD=		acpi_thinkpad
+CFLAGS+=	-I${.OBJDIR}/.. -I${.CURDIR}/..
+SRCS=		acpi_thinkpad.c opt_acpi.h device_if.h bus_if.h
+
+.include <bsd.kmod.mk>
diff --git a/sys/dev/acpica5/acpi_thinkpad/acpi_thinkpad.c b/sys/dev/acpica5/acpi_thinkpad/acpi_thinkpad.c
new file mode 100644
--- /dev/null
+++ b/sys/dev/acpica5/acpi_thinkpad/acpi_thinkpad.c
@@ -0,0 +1,1046 @@
+/*
+ * Copyright (c) 2004 Takanori Watanabe
+ * Copyright (c) 2005 Markus Brueffer <markus at FreeBSD.org>
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *    notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *    notice, this list of conditions and the following disclaimer in the
+ *    documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+ */
+
+/*
+ * Driver for extra ACPI-controlled gadgets found on IBM and Lenovo ThinkPad
+ * laptops. Inspired by the ibm-acpi and tpb projects which implement these
+ * features on Linux.
+ *
+ *   acpi-ibm: <http://ibm-acpi.sourceforge.net/>
+ *        tpb: <http://www.nongnu.org/tpb/>
+ */
+
+#include "opt_acpi.h"
+#include <sys/param.h>
+#include <sys/kernel.h>
+#include <sys/bus.h>
+#include <machine/cpufunc.h>
+#include <sys/module.h>
+/* #include <dev/led/led.h> */
+#include <sys/sensors.h>
+#include <sys/sysctl.h>
+#include <machine/clock.h>
+
+#include "acpi.h"
+#include "acpivar.h"
+#include "acpi_if.h"
+
+#define _COMPONENT	ACPI_OEM
+ACPI_MODULE_NAME("THINKPAD")
+
+/* Internal methods */
+#define ACPI_THINKPAD_METHOD_EVENTS		1
+#define ACPI_THINKPAD_METHOD_EVENTMASK		2
+#define ACPI_THINKPAD_METHOD_HOTKEY		3
+#define ACPI_THINKPAD_METHOD_BRIGHTNESS		4
+#define ACPI_THINKPAD_METHOD_VOLUME		5
+#define ACPI_THINKPAD_METHOD_MUTE		6
+#define ACPI_THINKPAD_METHOD_THINKLIGHT		7
+#define ACPI_THINKPAD_METHOD_BLUETOOTH		8
+#define ACPI_THINKPAD_METHOD_WLAN		9
+#define ACPI_THINKPAD_METHOD_FANSPEED		10
+#define ACPI_THINKPAD_METHOD_FANLEVEL		11
+#define ACPI_THINKPAD_METHOD_FANSTATUS		12
+#define ACPI_THINKPAD_METHOD_THERMAL		13
+
+/* Hotkeys/Buttons */
+#define THINKPAD_RTC_HOTKEY1			0x64
+#define   THINKPAD_RTC_MASK_HOME		(1 << 0)
+#define   THINKPAD_RTC_MASK_SEARCH		(1 << 1)
+#define   THINKPAD_RTC_MASK_MAIL		(1 << 2)
+#define   THINKPAD_RTC_MASK_WLAN		(1 << 5)
+#define THINKPAD_RTC_HOTKEY2			0x65
+#define   THINKPAD_RTC_MASK_THINKPAD		(1 << 3)
+#define   THINKPAD_RTC_MASK_ZOOM		(1 << 5)
+#define   THINKPAD_RTC_MASK_VIDEO		(1 << 6)
+#define   THINKPAD_RTC_MASK_HIBERNATE		(1 << 7)
+#define THINKPAD_RTC_THINKLIGHT			0x66
+#define   THINKPAD_RTC_MASK_THINKLIGHT		(1 << 4)
+#define THINKPAD_RTC_SCREENEXPAND		0x67
+#define   THINKPAD_RTC_MASK_SCREENEXPAND	(1 << 5)
+#define THINKPAD_RTC_BRIGHTNESS			0x6c
+#define   THINKPAD_RTC_MASK_BRIGHTNESS		(1 << 5)
+#define THINKPAD_RTC_VOLUME			0x6e
+#define   THINKPAD_RTC_MASK_VOLUME		(1 << 7)
+
+/* Embedded Controller registers */
+#define THINKPAD_EC_BRIGHTNESS			0x31
+#define   THINKPAD_EC_MASK_BRI			0x7
+#define THINKPAD_EC_VOLUME			0x30
+#define   THINKPAD_EC_MASK_VOL			0xf
+#define   THINKPAD_EC_MASK_MUTE			(1 << 6)
+#define THINKPAD_EC_FANSTATUS			0x2F
+#define   THINKPAD_EC_MASK_FANLEVEL		0x3f
+#define   THINKPAD_EC_MASK_FANDISENGAGED	(1 << 6)
+#define   THINKPAD_EC_MASK_FANSTATUS		(1 << 7)
+#define THINKPAD_EC_FANSPEED			0x84
+
+/* CMOS Commands */
+#define THINKPAD_CMOS_VOLUME_DOWN		0
+#define THINKPAD_CMOS_VOLUME_UP			1
+#define THINKPAD_CMOS_VOLUME_MUTE		2
+#define THINKPAD_CMOS_BRIGHTNESS_UP		4
+#define THINKPAD_CMOS_BRIGHTNESS_DOWN		5
+
+/* ACPI methods */
+#define THINKPAD_NAME_KEYLIGHT			"KBLT"
+#define THINKPAD_NAME_WLAN_BT_GET		"GBDC"
+#define THINKPAD_NAME_WLAN_BT_SET		"SBDC"
+#define   THINKPAD_NAME_MASK_BT			(1 << 1)
+#define   THINKPAD_NAME_MASK_WLAN		(1 << 2)
+#define THINKPAD_NAME_THERMAL_GET		"TMP7"
+#define THINKPAD_NAME_THERMAL_UPDT		"UPDT"
+
+#define THINKPAD_NAME_EVENTS_STATUS_GET		"DHKC"
+#define THINKPAD_NAME_EVENTS_MASK_GET		"DHKN"
+#define THINKPAD_NAME_EVENTS_STATUS_SET		"MHKC"
+#define THINKPAD_NAME_EVENTS_MASK_SET		"MHKM"
+#define THINKPAD_NAME_EVENTS_GET		"MHKP"
+#define THINKPAD_NAME_EVENTS_AVAILMASK		"MHKA"
+
+#define ABS(x) (((x) < 0)? -(x) : (x))
+
+struct acpi_thinkpad_softc {
+	device_t	dev;
+	ACPI_HANDLE	handle;
+
+	/* Embedded controller */
+	device_t	ec_dev;
+	ACPI_HANDLE	ec_handle;
+
+	/* CMOS */
+	ACPI_HANDLE	cmos_handle;
+
+	/* Fan status */
+	ACPI_HANDLE	fan_handle;
+	int		fan_levels;
+
+	/* Keylight commands and states */
+	ACPI_HANDLE	light_handle;
+	int		light_cmd_on;
+	int		light_cmd_off;
+	int		light_val;
+	int		light_get_supported;
+	int		light_set_supported;
+
+	/* led(4) interface */
+	struct cdev	*led_dev;
+	int		led_busy;
+	int		led_state;
+
+	int		wlan_bt_flags;
+	int		thermal_updt_supported;
+
+	unsigned int	events_availmask;
+	unsigned int	events_initialmask;
+	int		events_mask_supported;
+	int		events_enable;
+
+	/* sensors(9) related */
+	struct ksensordev sensordev;
+	struct ksensor sensors[9];	/* XXX: 8 thermal + fan */
+
+	struct sysctl_ctx_list	*sysctl_ctx;
+	struct sysctl_oid	*sysctl_tree;
+};
+
+static struct {
+	char	*name;
+	int	method;
+	char	*description;
+	int	access;
+} acpi_thinkpad_sysctls[] = {
+	{
+		.name		= "events",
+		.method		= ACPI_THINKPAD_METHOD_EVENTS,
+		.description	= "ACPI events enable",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "eventmask",
+		.method		= ACPI_THINKPAD_METHOD_EVENTMASK,
+		.description	= "ACPI eventmask",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "hotkey",
+		.method		= ACPI_THINKPAD_METHOD_HOTKEY,
+		.description	= "Key Status",
+		.access		= CTLTYPE_INT | CTLFLAG_RD
+	},
+	{
+		.name		= "lcd_brightness",
+		.method		= ACPI_THINKPAD_METHOD_BRIGHTNESS,
+		.description	= "LCD Brightness",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "volume",
+		.method		= ACPI_THINKPAD_METHOD_VOLUME,
+		.description	= "Volume",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "mute",
+		.method		= ACPI_THINKPAD_METHOD_MUTE,
+		.description	= "Mute",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "thinklight",
+		.method		= ACPI_THINKPAD_METHOD_THINKLIGHT,
+		.description	= "Thinklight enable",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "bluetooth",
+		.method		= ACPI_THINKPAD_METHOD_BLUETOOTH,
+		.description	= "Bluetooth enable",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "wlan",
+		.method		= ACPI_THINKPAD_METHOD_WLAN,
+		.description	= "WLAN enable",
+		.access		= CTLTYPE_INT | CTLFLAG_RD
+	},
+	{
+		.name		= "fan_level",
+		.method		= ACPI_THINKPAD_METHOD_FANLEVEL,
+		.description	= "Fan level",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "fan",
+		.method		= ACPI_THINKPAD_METHOD_FANSTATUS,
+		.description	= "Fan enable",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+
+	{ NULL, 0, NULL, 0 }
+};
+
+/* ACPI_SERIAL_DECL(thinkpad, "ACPI THINKPAD extras"); */
+static int	acpi_thinkpad_probe(device_t dev);
+static int	acpi_thinkpad_attach(device_t dev);
+static int	acpi_thinkpad_detach(device_t dev);
+
+#if 0 /* not yet */
+static void	thinkpad_led(void *softc, int onoff);
+static void	thinkpad_led_task(struct acpi_thinkpad_softc *sc,
+		int pending __unused);
+#endif
+
+static int	acpi_thinkpad_sysctl(SYSCTL_HANDLER_ARGS);
+static int	acpi_thinkpad_sysctl_init(struct acpi_thinkpad_softc *sc,
+		int method);
+static int	acpi_thinkpad_sysctl_get(struct acpi_thinkpad_softc *sc,
+		int method);
+static int	acpi_thinkpad_sysctl_set(struct acpi_thinkpad_softc *sc,
+		int method, int val);
+
+static int	acpi_thinkpad_eventmask_set(struct acpi_thinkpad_softc *sc,
+		int val);
+static void	acpi_thinkpad_notify(ACPI_HANDLE h, UINT32 notify,
+		void *context);
+static void	acpi_thinkpad_refresh(void *);
+
+static device_method_t acpi_thinkpad_methods[] = {
+	/* Device interface */
+	DEVMETHOD(device_probe, acpi_thinkpad_probe),
+	DEVMETHOD(device_attach, acpi_thinkpad_attach),
+	DEVMETHOD(device_detach, acpi_thinkpad_detach),
+	{0, 0}
+};
+
+static driver_t	acpi_thinkpad_driver = {
+	"acpi_thinkpad",
+	acpi_thinkpad_methods,
+	sizeof(struct acpi_thinkpad_softc),
+};
+
+static devclass_t acpi_thinkpad_devclass;
+
+DRIVER_MODULE(acpi_thinkpad, acpi, acpi_thinkpad_driver,
+    acpi_thinkpad_devclass, 0, 0);
+MODULE_DEPEND(acpi_thinkpad, acpi, 1, 1, 1);
+static char    *thinkpad_ids[] = {"IBM0068", NULL};
+
+#if 0 /* not yet */
+static void
+thinkpad_led(void *softc, int onoff)
+{
+	struct acpi_thinkpad_softc* sc = (struct acpi_thinkpad_softc*) softc;
+
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+
+	if (sc->led_busy)
+		return;
+
+	sc->led_busy = 1;
+	sc->led_state = onoff;
+
+	AcpiOsExecute(OSL_NOTIFY_HANDLER, (void *)thinkpad_led_task, sc);
+}
+
+static void
+thinkpad_led_task(struct acpi_thinkpad_softc *sc, int pending __unused)
+{
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+
+	/* ACPI_SERIAL_BEGIN(thinkpad); */
+	acpi_thinkpad_sysctl_set(sc, ACPI_THINKPAD_METHOD_THINKLIGHT, sc->led_state);
+	/* ACPI_SERIAL_END(thinkpad); */
+
+	sc->led_busy = 0;
+}
+#endif
+
+static int
+acpi_thinkpad_probe(device_t dev)
+{
+	if (acpi_disabled("thinkpad") ||
+	    ACPI_ID_PROBE(device_get_parent(dev), dev, thinkpad_ids) == NULL ||
+	    device_get_unit(dev) != 0) 
+		return (ENXIO);
+
+	device_set_desc(dev, "IBM/Lenovo ThinkPad ACPI Extras");
+	return (0);
+}
+
+static int
+acpi_thinkpad_attach(device_t dev)
+{
+	struct acpi_thinkpad_softc	*sc;
+	struct acpi_softc	*acpi_sc;
+	devclass_t		ec_devclass;
+	int			i;
+
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t) __func__);
+
+	sc = device_get_softc(dev);
+	sc->dev = dev;
+	sc->handle = acpi_get_handle(dev);
+
+	acpi_sc = acpi_device_get_parent_softc(dev);
+
+	/* Look for the first embedded controller */
+        if (!(ec_devclass = devclass_find ("acpi_ec"))) {
+		if (bootverbose)
+			device_printf(dev, "Couldn't find acpi_ec devclass\n");
+		return (EINVAL);
+	}
+        if (!(sc->ec_dev = devclass_get_device(ec_devclass, 0))) {
+		if (bootverbose)
+			device_printf(dev, "Couldn't find acpi_ec device\n");
+		return (EINVAL);
+	}
+	sc->ec_handle = acpi_get_handle(sc->ec_dev);
+
+	/* ACPI_SERIAL_BEGIN(thinkpad); */
+
+#if 0
+	/* Get the sysctl tree */
+	sc->sysctl_ctx = device_get_sysctl_ctx(dev);
+	sc->sysctl_tree = device_get_sysctl_tree(dev);
+#endif
+	sysctl_ctx_init(sc->sysctl_ctx);
+	sc->sysctl_tree = SYSCTL_ADD_NODE(sc->sysctl_ctx,
+	    SYSCTL_CHILDREN(acpi_sc->acpi_sysctl_tree), OID_AUTO,
+	    "thinkpad", CTLFLAG_RD, 0, "");
+
+	/* Look for event mask and hook up the nodes */
+	sc->events_mask_supported = ACPI_SUCCESS(acpi_GetInteger(sc->handle,
+	    THINKPAD_NAME_EVENTS_MASK_GET, &sc->events_initialmask));
+
+	if (sc->events_mask_supported) {
+		SYSCTL_ADD_INT(sc->sysctl_ctx,
+		    SYSCTL_CHILDREN(sc->sysctl_tree), OID_AUTO,
+		    "initialmask", CTLFLAG_RD,
+		    &sc->events_initialmask, 0, "Initial eventmask");
+
+		/* The availmask is the bitmask of supported events */
+		if (ACPI_FAILURE(acpi_GetInteger(sc->handle,
+		    THINKPAD_NAME_EVENTS_AVAILMASK, &sc->events_availmask)))
+			sc->events_availmask = 0xffffffff;
+
+		SYSCTL_ADD_INT(sc->sysctl_ctx,
+		    SYSCTL_CHILDREN(sc->sysctl_tree), OID_AUTO,
+		    "availmask", CTLFLAG_RD,
+		    &sc->events_availmask, 0, "Mask of supported events");
+	}
+
+	/* Hook up proc nodes */
+	for (i = 0; acpi_thinkpad_sysctls[i].name != NULL; i++) {
+		if (!acpi_thinkpad_sysctl_init(sc,
+		    acpi_thinkpad_sysctls[i].method))
+			continue;
+
+		SYSCTL_ADD_PROC(sc->sysctl_ctx,
+		    SYSCTL_CHILDREN(sc->sysctl_tree), OID_AUTO,
+		    acpi_thinkpad_sysctls[i].name,
+		    acpi_thinkpad_sysctls[i].access,
+		    sc, i, acpi_thinkpad_sysctl, "I",
+		    acpi_thinkpad_sysctls[i].description);
+	}
+
+	/* ACPI_SERIAL_END(thinkpad); */
+
+	/* Handle notifies */
+	AcpiInstallNotifyHandler(sc->handle, ACPI_DEVICE_NOTIFY,
+	    acpi_thinkpad_notify, dev);
+
+#if 0
+	/* Hook up light to led(4) */
+	if (sc->light_set_supported)
+		sc->led_dev = led_create_state(thinkpad_led, sc, "thinklight",
+		    sc->light_val);
+#endif
+	/* Attach sensors(9). */
+	if (sensor_task_register(sc, acpi_thinkpad_refresh, 5)) {
+		device_printf(sc->dev, "unable to register update task\n");
+		return 1;
+	}
+
+	strlcpy(sc->sensordev.xname, device_get_nameunit(sc->dev),
+	    sizeof(sc->sensordev.xname));
+
+	/* XXX: Temp sensors */
+	for (i = 0; i < 8; ++i) {
+		sc->sensors[i].type = SENSOR_TEMP;
+		sensor_attach(&sc->sensordev, &sc->sensors[i]);
+	}
+	
+	/* Fan RPM sensor */
+	sc->sensors[8].type = SENSOR_FANRPM;
+	sensor_attach(&sc->sensordev, &sc->sensors[8]);
+
+	sensordev_install(&sc->sensordev);
+
+	return (0);
+}
+
+static int
+acpi_thinkpad_detach(device_t dev)
+{
+	int i;
+
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t) __func__);
+
+	struct acpi_thinkpad_softc *sc = device_get_softc(dev);
+
+	/* Disable events and restore eventmask */
+	/* ACPI_SERIAL_BEGIN(thinkpad); */
+	acpi_thinkpad_sysctl_set(sc, ACPI_THINKPAD_METHOD_EVENTS, 0);
+	acpi_thinkpad_sysctl_set(sc, ACPI_THINKPAD_METHOD_EVENTMASK,
+	    sc->events_initialmask);
+	/* ACPI_SERIAL_END(thinkpad); */
+
+	AcpiRemoveNotifyHandler(sc->handle, ACPI_DEVICE_NOTIFY,
+	    acpi_thinkpad_notify);
+
+	sysctl_ctx_free(sc->sysctl_ctx);
+
+#if 0
+	if (sc->led_dev != NULL)
+		led_destroy(sc->led_dev);
+#endif
+	sensordev_deinstall(&sc->sensordev);
+	for (i = 0; i < 9; i++)
+		sensor_detach(&sc->sensordev, &sc->sensors[i]);
+	sensor_task_unregister(sc);
+
+	return (0);
+}
+
+static int
+acpi_thinkpad_eventmask_set(struct acpi_thinkpad_softc *sc, int val)
+{
+	int i;
+	ACPI_OBJECT		arg[2];
+	ACPI_OBJECT_LIST	args;
+	ACPI_STATUS		status;
+
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+	/* ACPI_SERIAL_ASSERT(thinkpad); */
+
+	args.Count = 2;
+	args.Pointer = arg;
+	arg[0].Type = ACPI_TYPE_INTEGER;
+	arg[1].Type = ACPI_TYPE_INTEGER;
+
+	for (i = 0; i < 32; ++i) {
+		arg[0].Integer.Value = i+1;
+		arg[1].Integer.Value = (((1 << i) & val) != 0);
+		status = AcpiEvaluateObject(sc->handle,
+		    THINKPAD_NAME_EVENTS_MASK_SET, &args, NULL);
+
+		if (ACPI_FAILURE(status))
+			return (status);
+	}
+
+	return (0);
+}
+
+static int
+acpi_thinkpad_sysctl(SYSCTL_HANDLER_ARGS)
+{
+	struct acpi_thinkpad_softc	*sc;
+	int			arg;
+	int			error = 0;
+	int			function;
+	int			method;
+	
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+
+	sc = (struct acpi_thinkpad_softc *)oidp->oid_arg1;
+	function = oidp->oid_arg2;
+	method = acpi_thinkpad_sysctls[function].method;
+
+	/* ACPI_SERIAL_BEGIN(thinkpad); */
+	arg = acpi_thinkpad_sysctl_get(sc, method);
+	error = sysctl_handle_int(oidp, &arg, 0, req);
+
+	/* Sanity check */
+	if (error != 0 || req->newptr == NULL)
+		goto out;
+
+	/* Update */
+	error = acpi_thinkpad_sysctl_set(sc, method, arg);
+
+out:
+	/* ACPI_SERIAL_END(thinkpad); */
+	return (error);
+}
+
+static int
+acpi_thinkpad_sysctl_get(struct acpi_thinkpad_softc *sc, int method)
+{
+	ACPI_INTEGER	val_ec;
+	int 		val = 0, key;
+
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+	/* ACPI_SERIAL_ASSERT(thinkpad); */
+
+	switch (method) {
+	case ACPI_THINKPAD_METHOD_EVENTS:
+		acpi_GetInteger(sc->handle, THINKPAD_NAME_EVENTS_STATUS_GET,
+		    &val);
+		break;
+
+	case ACPI_THINKPAD_METHOD_EVENTMASK:
+		if (sc->events_mask_supported)
+			acpi_GetInteger(sc->handle,
+			    THINKPAD_NAME_EVENTS_MASK_GET, &val);
+		break;
+
+	case ACPI_THINKPAD_METHOD_HOTKEY:
+		/*
+		 * Construct the hotkey as a bitmask as illustrated below.
+		 * Note that whenever a key was pressed, the respecting bit
+		 * toggles and nothing else changes.
+		 * +--+--+-+-+-+-+-+-+-+-+-+-+
+		 * |11|10|9|8|7|6|5|4|3|2|1|0|
+		 * +--+--+-+-+-+-+-+-+-+-+-+-+
+		 *   |  | | | | | | | | | | |
+		 *   |  | | | | | | | | | | +- Home Button
+		 *   |  | | | | | | | | | +--- Search Button
+		 *   |  | | | | | | | | +----- Mail Button
+		 *   |  | | | | | | | +------- Thinkpad Button
+		 *   |  | | | | | | +--------- Zoom (Fn + Space)
+		 *   |  | | | | | +----------- WLAN Button
+		 *   |  | | | | +------------- Video Button
+		 *   |  | | | +--------------- Hibernate Button
+		 *   |  | | +----------------- Thinklight Button
+		 *   |  | +------------------- Screen expand (Fn + F8)
+		 *   |  +--------------------- Brightness
+		 *   +------------------------ Volume/Mute
+		 */
+		key = rtcin(THINKPAD_RTC_HOTKEY1);
+		val = (THINKPAD_RTC_MASK_HOME | THINKPAD_RTC_MASK_SEARCH |
+		    THINKPAD_RTC_MASK_MAIL | THINKPAD_RTC_MASK_WLAN) & key;
+		key = rtcin(THINKPAD_RTC_HOTKEY2);
+		val |= (THINKPAD_RTC_MASK_THINKPAD | THINKPAD_RTC_MASK_VIDEO |
+		    THINKPAD_RTC_MASK_HIBERNATE) & key;
+		val |= (THINKPAD_RTC_MASK_ZOOM & key) >> 1;
+		key = rtcin(THINKPAD_RTC_THINKLIGHT);
+		val |= (THINKPAD_RTC_MASK_THINKLIGHT & key) << 4;
+		key = rtcin(THINKPAD_RTC_SCREENEXPAND);
+		val |= (THINKPAD_RTC_MASK_THINKLIGHT & key) << 4;
+		key = rtcin(THINKPAD_RTC_BRIGHTNESS);
+		val |= (THINKPAD_RTC_MASK_BRIGHTNESS & key) << 5;
+		key = rtcin(THINKPAD_RTC_VOLUME);
+		val |= (THINKPAD_RTC_MASK_VOLUME & key) << 4;
+		break;
+
+	case ACPI_THINKPAD_METHOD_BRIGHTNESS:
+		ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_BRIGHTNESS, &val_ec, 1);
+		val = val_ec & THINKPAD_EC_MASK_BRI;
+		break;
+
+	case ACPI_THINKPAD_METHOD_VOLUME:
+		ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_VOLUME, &val_ec, 1);
+		val = val_ec & THINKPAD_EC_MASK_VOL;
+		break;
+
+	case ACPI_THINKPAD_METHOD_MUTE:
+		val = ((val_ec & THINKPAD_EC_MASK_MUTE) ==
+		    THINKPAD_EC_MASK_MUTE);
+		break;
+
+	case ACPI_THINKPAD_METHOD_THINKLIGHT:
+		if (sc->light_get_supported)
+			acpi_GetInteger(sc->ec_handle, THINKPAD_NAME_KEYLIGHT,
+			    &val);
+		else
+			val = sc->light_val;
+		break;
+
+	case ACPI_THINKPAD_METHOD_BLUETOOTH:
+		acpi_GetInteger(sc->handle, THINKPAD_NAME_WLAN_BT_GET, &val);
+		sc->wlan_bt_flags = val;
+		val = ((val & THINKPAD_NAME_MASK_BT) != 0);
+		break;
+
+	case ACPI_THINKPAD_METHOD_WLAN:
+		acpi_GetInteger(sc->handle, THINKPAD_NAME_WLAN_BT_GET, &val);
+		sc->wlan_bt_flags = val;
+		val = ((val & THINKPAD_NAME_MASK_WLAN) != 0);
+		break;
+
+	case ACPI_THINKPAD_METHOD_FANSPEED:
+		if (sc->fan_handle) {
+			if (ACPI_FAILURE(acpi_GetInteger(sc->fan_handle,
+			    NULL, &val)))
+				val = -1;
+		}
+		else {
+			ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_FANSPEED,
+			    &val_ec, 2);
+			val = val_ec;
+		}
+		break;
+
+	case ACPI_THINKPAD_METHOD_FANLEVEL:
+		/*
+		 * The THINKPAD_EC_FANSTATUS register works as follows:
+		 * Bit 0-5 indicate the level at which the fan operates. Only
+		 *       values between 0 and 7 have an effect. Everything
+		 *       above 7 is treated the same as level 7
+		 * Bit 6 overrides the fan speed limit if set to 1
+		 * Bit 7 indicates at which mode the fan operates:
+		 *       manual (0) or automatic (1)
+		 */
+		if (!sc->fan_handle) {
+			ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_FANSTATUS,
+			    &val_ec, 1);
+			val = val_ec & THINKPAD_EC_MASK_FANLEVEL;
+		}
+		break;
+
+	case ACPI_THINKPAD_METHOD_FANSTATUS:
+		if (!sc->fan_handle) {
+			ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_FANSTATUS,
+			    &val_ec, 1);
+			val = (val_ec & THINKPAD_EC_MASK_FANSTATUS) ==
+			    THINKPAD_EC_MASK_FANSTATUS;
+		}
+		else
+			val = -1;
+		break;
+	}
+
+	return (val);
+}
+
+static int
+acpi_thinkpad_sysctl_set(struct acpi_thinkpad_softc *sc, int method, int arg)
+{
+	int			val, step, i;
+	ACPI_INTEGER		val_ec;
+	ACPI_OBJECT		Arg;
+	ACPI_OBJECT_LIST	Args;
+	ACPI_STATUS		status;
+
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+	/* ACPI_SERIAL_ASSERT(thinkpad); */
+
+	switch (method) {
+	case ACPI_THINKPAD_METHOD_EVENTS:
+		if (arg < 0 || arg > 1)
+			return (EINVAL);
+
+		status = acpi_SetInteger(sc->handle,
+		    THINKPAD_NAME_EVENTS_STATUS_SET, arg);
+		if (ACPI_FAILURE(status))
+			return (status);
+		if (sc->events_mask_supported)
+			return acpi_thinkpad_eventmask_set(sc,
+			    sc->events_availmask);
+		break;
+
+	case ACPI_THINKPAD_METHOD_EVENTMASK:
+		if (sc->events_mask_supported)
+			return acpi_thinkpad_eventmask_set(sc, arg);
+		break;
+
+	case ACPI_THINKPAD_METHOD_BRIGHTNESS:
+		if (arg < 0 || arg > 7)
+			return (EINVAL);
+
+		if (sc->cmos_handle) {
+			/* Read the current brightness */
+			status = ACPI_EC_READ(sc->ec_dev,
+			    THINKPAD_EC_BRIGHTNESS, &val_ec, 1);
+			if (ACPI_FAILURE(status))
+				return (status);
+			val = val_ec & THINKPAD_EC_MASK_BRI;
+
+			Args.Count = 1;
+			Args.Pointer = &Arg;
+			Arg.Type = ACPI_TYPE_INTEGER;
+			Arg.Integer.Value = (arg > val) ?
+			    THINKPAD_CMOS_BRIGHTNESS_UP :
+			    THINKPAD_CMOS_BRIGHTNESS_DOWN;
+
+			step = (arg > val) ? 1 : -1;
+			for (i = val; i != arg; i += step) {
+				status = AcpiEvaluateObject(sc->cmos_handle,
+				    NULL, &Args, NULL);
+				if (ACPI_FAILURE(status))
+					break;
+			}
+		}
+		return ACPI_EC_WRITE(sc->ec_dev, THINKPAD_EC_BRIGHTNESS,
+		    arg, 1);
+		break;
+
+	case ACPI_THINKPAD_METHOD_VOLUME:
+		if (arg < 0 || arg > 14)
+			return (EINVAL);
+
+		status = ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_VOLUME,
+		    &val_ec, 1);
+		if (ACPI_FAILURE(status))
+			return (status);
+
+		if (sc->cmos_handle) {
+			val = val_ec & THINKPAD_EC_MASK_VOL;
+
+			Args.Count = 1;
+			Args.Pointer = &Arg;
+			Arg.Type = ACPI_TYPE_INTEGER;
+			Arg.Integer.Value = (arg > val) ?
+			    THINKPAD_CMOS_VOLUME_UP : THINKPAD_CMOS_VOLUME_DOWN;
+
+			step = (arg > val) ? 1 : -1;
+			for (i = val; i != arg; i += step) {
+				status = AcpiEvaluateObject(sc->cmos_handle,
+				    NULL, &Args, NULL);
+				if (ACPI_FAILURE(status))
+					break;
+			}
+		}
+		return ACPI_EC_WRITE(sc->ec_dev, THINKPAD_EC_VOLUME, arg +
+		    (val_ec & (~THINKPAD_EC_MASK_VOL)), 1);
+		break;
+
+	case ACPI_THINKPAD_METHOD_MUTE:
+		if (arg < 0 || arg > 1)
+			return (EINVAL);
+
+		status = ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_VOLUME,
+		    &val_ec, 1);
+		if (ACPI_FAILURE(status))
+			return (status);
+
+		if (sc->cmos_handle) {
+			val = val_ec & THINKPAD_EC_MASK_VOL;
+
+			Args.Count = 1;
+			Args.Pointer = &Arg;
+			Arg.Type = ACPI_TYPE_INTEGER;
+			Arg.Integer.Value = THINKPAD_CMOS_VOLUME_MUTE;
+
+			status = AcpiEvaluateObject(sc->cmos_handle, NULL,
+			    &Args, NULL);
+			if (ACPI_FAILURE(status))
+				break;
+		}
+		return ACPI_EC_WRITE(sc->ec_dev, THINKPAD_EC_VOLUME, (arg==1) ?
+		   val_ec | THINKPAD_EC_MASK_MUTE :
+		   val_ec & (~THINKPAD_EC_MASK_MUTE), 1);
+		break;
+
+	case ACPI_THINKPAD_METHOD_THINKLIGHT:
+		if (arg < 0 || arg > 1)
+			return (EINVAL);
+
+		if (sc->light_set_supported) {
+			Args.Count = 1;
+			Args.Pointer = &Arg;
+			Arg.Type = ACPI_TYPE_INTEGER;
+			Arg.Integer.Value = arg ?
+			    sc->light_cmd_on : sc->light_cmd_off;
+
+			status = AcpiEvaluateObject(sc->light_handle, NULL,
+			    &Args, NULL);
+			if (ACPI_SUCCESS(status))
+				sc->light_val = arg;
+			return (status);
+		}
+		break;
+
+	case ACPI_THINKPAD_METHOD_BLUETOOTH:
+		if (arg < 0 || arg > 1)
+			return (EINVAL);
+
+		val = (arg == 1) ? sc->wlan_bt_flags |
+		    THINKPAD_NAME_MASK_BT :
+		    sc->wlan_bt_flags & (~THINKPAD_NAME_MASK_BT);
+		return acpi_SetInteger(sc->handle, THINKPAD_NAME_WLAN_BT_SET,
+		    val);
+		break;
+
+	case ACPI_THINKPAD_METHOD_FANLEVEL:
+		if (arg < 0 || arg > 7)
+			return (EINVAL);
+
+		if (!sc->fan_handle) {
+			/* Read the current fanstatus */
+			ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_FANSTATUS,
+			    &val_ec, 1);
+			val = val_ec & (~THINKPAD_EC_MASK_FANLEVEL);
+
+			return ACPI_EC_WRITE(sc->ec_dev, THINKPAD_EC_FANSTATUS,
+			    val | arg, 1);
+		}
+		break;
+
+	case ACPI_THINKPAD_METHOD_FANSTATUS:
+		if (arg < 0 || arg > 1)
+			return (EINVAL);
+
+		if (!sc->fan_handle) {
+			/* Read the current fanstatus */
+			ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_FANSTATUS,
+			    &val_ec, 1);
+
+			return ACPI_EC_WRITE(sc->ec_dev, THINKPAD_EC_FANSTATUS,
+			    (arg == 1) ? (val_ec | THINKPAD_EC_MASK_FANSTATUS) :
+			    (val_ec & (~THINKPAD_EC_MASK_FANSTATUS)), 1);
+		}
+		break;
+	}
+
+	return (0);
+}
+
+static int
+acpi_thinkpad_sysctl_init(struct acpi_thinkpad_softc *sc, int method)
+{
+	int 			dummy;
+	ACPI_OBJECT_TYPE 	cmos_t;
+	ACPI_HANDLE		ledb_handle;
+
+	switch (method) {
+	case ACPI_THINKPAD_METHOD_EVENTS:
+		/* Events are disabled by default */
+		return (TRUE);
+
+	case ACPI_THINKPAD_METHOD_EVENTMASK:
+		return (sc->events_mask_supported);
+
+	case ACPI_THINKPAD_METHOD_HOTKEY:
+	case ACPI_THINKPAD_METHOD_BRIGHTNESS:
+	case ACPI_THINKPAD_METHOD_VOLUME:
+	case ACPI_THINKPAD_METHOD_MUTE:
+		/* EC is required here, which was already checked before */
+		return (TRUE);
+
+	case ACPI_THINKPAD_METHOD_THINKLIGHT:
+		sc->cmos_handle = NULL;
+		sc->light_get_supported = ACPI_SUCCESS(acpi_GetInteger(
+		    sc->ec_handle, THINKPAD_NAME_KEYLIGHT, &sc->light_val));
+
+		if ((ACPI_SUCCESS(AcpiGetHandle(sc->handle, "\\UCMS",
+		    &sc->light_handle)) ||
+		    ACPI_SUCCESS(AcpiGetHandle(sc->handle, "\\CMOS",
+		    &sc->light_handle)) ||
+		    ACPI_SUCCESS(AcpiGetHandle(sc->handle, "\\CMS",
+		    &sc->light_handle))) &&
+		    ACPI_SUCCESS(AcpiGetType(sc->light_handle, &cmos_t)) &&
+		    cmos_t == ACPI_TYPE_METHOD) {
+			sc->light_cmd_on = 0x0c;
+			sc->light_cmd_off = 0x0d;
+			sc->cmos_handle = sc->light_handle;
+		}
+		else if (ACPI_SUCCESS(AcpiGetHandle(sc->handle, "\\LGHT",
+		    &sc->light_handle))) {
+			sc->light_cmd_on = 1;
+			sc->light_cmd_off = 0;
+		}
+		else
+			sc->light_handle = NULL;
+
+		sc->light_set_supported = (sc->light_handle &&
+		    ACPI_FAILURE(AcpiGetHandle(sc->ec_handle, "LEDB",
+		    &ledb_handle)));
+
+		if (sc->light_get_supported)
+			return (TRUE);
+
+		if (sc->light_set_supported) {
+			sc->light_val = 0;
+			return (TRUE);
+		}
+
+		return (FALSE);
+
+	case ACPI_THINKPAD_METHOD_BLUETOOTH:
+	case ACPI_THINKPAD_METHOD_WLAN:
+		if (ACPI_SUCCESS(acpi_GetInteger(sc->handle,
+		    THINKPAD_NAME_WLAN_BT_GET, &dummy)))
+			return (TRUE);
+		return (FALSE);
+
+	case ACPI_THINKPAD_METHOD_FANSPEED:
+		/* 
+		 * Some models report the fan speed in levels from 0-7
+		 * Newer models report it contiguously
+		 */
+		sc->fan_levels = (ACPI_SUCCESS(AcpiGetHandle(sc->handle, "GFAN",
+		    &sc->fan_handle)) ||
+		    ACPI_SUCCESS(AcpiGetHandle(sc->handle, "\\FSPD",
+		    &sc->fan_handle)));
+		return (TRUE);
+
+	case ACPI_THINKPAD_METHOD_FANLEVEL:
+	case ACPI_THINKPAD_METHOD_FANSTATUS:
+		/* 
+		 * Fan status is only supported on those models,
+		 * which report fan RPM contiguously, not in levels
+		 */
+		if (sc->fan_levels)
+			return (FALSE);
+		return (TRUE);
+
+	case ACPI_THINKPAD_METHOD_THERMAL:
+		if (ACPI_SUCCESS(acpi_GetInteger(sc->ec_handle,
+		    THINKPAD_NAME_THERMAL_GET, &dummy))) {
+			sc->thermal_updt_supported =
+			    ACPI_SUCCESS(acpi_GetInteger(sc->ec_handle,
+			    THINKPAD_NAME_THERMAL_UPDT, &dummy));
+			return (TRUE);
+		}
+		return (FALSE);
+	}
+	return (FALSE);
+}
+
+static void
+acpi_thinkpad_notify(ACPI_HANDLE h, UINT32 notify, void *context)
+{
+	int		event, arg, type;
+	device_t	dev = context;
+	struct acpi_thinkpad_softc *sc = device_get_softc(dev);
+
+	ACPI_FUNCTION_TRACE_U32((char *)(uintptr_t)__func__, notify);
+
+	if (notify != 0x80)
+		device_printf(dev, "Unknown notify\n");
+
+	for (;;) {
+		acpi_GetInteger(acpi_get_handle(dev), THINKPAD_NAME_EVENTS_GET,
+		    &event);
+
+		if (event == 0)
+			break;
+
+		type = (event >> 12) & 0xf;
+		arg = event & 0xfff;
+		switch (type) {
+		case 1:
+			if (!(sc->events_availmask & (1 << (arg - 1)))) {
+				device_printf(dev, "Unknown key %d\n", arg);
+				break;
+			}
+
+			/* Notify devd(8) */
+			device_printf(dev, "THINKPAD event: %u\n",
+			    (arg & 0xff));
+			acpi_UserNotify("THINKPAD", h, (arg & 0xff));
+			break;
+		default:
+			break;
+		}
+	}
+}
+
+static void
+acpi_thinkpad_refresh(void *arg)
+{
+	struct acpi_thinkpad_softc *sc = (struct acpi_thinkpad_softc *)arg;
+	char temp_cmd[] = "TMP0";
+	int data, i;
+	ACPI_INTEGER speed;
+
+	for (i = 0; i < 8; i++) {
+		temp_cmd[3] = '0' + i;
+		
+                /*
+                 * The TMPx methods seem to return +/- 128 or 0
+                 * when the respecting sensor is not available
+                 */
+		sc->sensors[i].flags &= ~SENSOR_FINVALID;
+                if (ACPI_FAILURE(acpi_GetInteger(sc->ec_handle, temp_cmd,
+                    &data)) || ABS(data) == 128 || data == 0) {
+			sc->sensors[i].flags |= SENSOR_FINVALID;
+                        data = 0;
+		}
+                else if (sc->thermal_updt_supported) {
+                        /* XXX: Temperature is reported in tenth of Kelvin */
+                        data = (data - 2732 + 5) / 10;
+		}
+		sc->sensors[i].value = data * 1000000 + 273150000;
+        }
+	
+	sc->sensors[8].flags &= ~SENSOR_FINVALID;
+	if (sc->fan_handle) {
+		if (ACPI_FAILURE(acpi_GetInteger(sc->fan_handle,
+		    NULL, &data)))
+			sc->sensors[8].flags |= SENSOR_FINVALID;
+                        data = -1;
+        }
+        else {
+                ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_FANSPEED, &speed, 2);
+                data = speed;
+        }
+
+	sc->sensors[8].value = data;
+}
diff --git a/sys/platform/pc32/conf/files b/sys/platform/pc32/conf/files
--- a/sys/platform/pc32/conf/files
+++ b/sys/platform/pc32/conf/files
@@ -72,6 +72,7 @@ dev/serial/dgb/dgm.c			optional	dgm
 ${OSACPI_MD_DIR}/acpi_machdep.c		optional        acpi
 ${OSACPI_MD_DIR}/acpi_wakeup.c		optional        acpi
 ${OSACPI_MD_DIR}/acpi_toshiba.c		optional        acpi_toshiba acpi
+${ACPICA_DIR}/acpi_thinkpad/acpi_thinkpad.c optional	acpi_thinkpad acpi
 acpi.h					optional	acpi		\
 	dependency	"$S/${ACPICA_DIR}/include/acpi.h"		\
 	compile-with	"cp $S/${ACPICA_DIR}/include/acpi.h ${.OBJDIR}/"	\



From hasso at estpak.ee  Thu Mar 20 03:49:13 2008
From: hasso at estpak.ee (Hasso Tepper)
Date: Thu, 20 Mar 2008 03:49:13 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Some questions regarding ACPI
In-Reply-To: <200803191322.46366.hasso@estpak.ee>
Message-ID: <200803201237.28823.hasso@estpak.ee>

Hasso Tepper wrote:
> There is also one fatal issue -laptop locks up hardly (no panic) while 
> unloading module. Any idea regarding this is welcome.

Nevermind, solved.


-- 
Hasso




From dillon at apollo.backplane.com  Fri Mar 21 19:24:01 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Fri, 21 Mar 2008 19:24:01 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: panic: assertion: hammer_btree_cmp(cursor->left_bound,	&cursor->node->ondisk->elms[0].leaf.base) <= 0 in btree_split_leaf
In-Reply-To: <200802232204.m1NM4cxd046264@apollo.backplane.com>
Message-ID: <200803220212.m2M2CiAY014435@apollo.backplane.com>

:While trying to find a procedure to reliably reproduce the panic
:I reported last time, I caught a different panic (uploaded at
: ~y0netan1/crash/9/ on my leaf account).  I wrote the following shell
:script (make sure to edit variables DISKS and MOUNTPT before using this
:script or it may trash your system):

    Ok, I believe I have fixed the left_bound assertion.  I also believe
    I have fixed the node ref count assertion on umount.

    There is currently one unfixed assertion related to the I/O
    path... sometimes the bp is being improperly disassociated from the
    related HAMMER structure.

    The full-filesystem case is still not being handled so don't test that :-)

					    -Matt





From c.turner at 199technologies.org  Sun Mar 23 09:48:29 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Sun, 23 Mar 2008 09:48:29 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
Message-ID: <47E6870C.4080709@199technologies.org>

I'm finally getting around to doing 1.12 upgrades, and have setup a 
separate machine to do my bulk package builds / upgrades etc,
so as not to disrupt my 'dev server' while things are being
built / tested

However, this seems kind of wasteful - the only purpose of this machine
is to build packages against a specific release..
And since building packages for a particular release generally requires 
only the userland, appropriate headers and correct 'uname' output - so:

it seems like if spoofing uname is configured inside a jail,
the next (or previous..) release can be installed into a jail and
used for building / testing packages without the overhead of a VM or 
maintaining a separate physical host

I did a quick scan of the tree to see what this would take, and, high 
level, it seems like only the following changes would need to be made:

- update struct jail to add a 'osrelease' string
  (implies bumping 'jail api' to 2?)
- update jail(8) to actually pass this information along
- update sys_uname to test ucred for jailed processes, and
  use the struct jail osrelease if appropriate
- similarly update sysctl kern.osrelease to support jail spoofing
  (if possible - didn't get this far in the research yet)
  could be less of a problem for builds, as I think most things use
 uname(1) ... but good to keep the environment consistent I suppose..
I'm still a bit confused as to how 'osrelease' is defined - everything
I'm finding is showing up as extern char[] .. perhaps this is something 
in the build I'm not familiar with?

also,

is the so-called 'stupid hackery' in sys_uname needed still?

Before I start any coding, does this:

- sound like something useful
- sound like the right approach
Thinking this could have wider useful implications e.g. for pkgbox
& so on -  for example setting up automated bulks w/various combinations 
of pkgsrc and releases, etc.

Cheers,

- Chris





From corecode at fs.ei.tum.de  Sun Mar 23 10:06:38 2008
From: corecode at fs.ei.tum.de (Simon 'corecode' Schubert)
Date: Sun, 23 Mar 2008 10:06:38 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <47E68C74.3080808@fs.ei.tum.de>

Chris Turner wrote:
I did a quick scan of the tree to see what this would take, and, high 
level, it seems like only the following changes would need to be made:
brave investigation.  but you could also simply set UNAME_r :)

sweatshorts % uname -r
1.13.0-DEVELOPMENT
sweatshorts % UNAME_r=1.12-RELEASE uname -r
1.12-RELEASE
I think that's good enough :D

cheers
  simon
--
Serve - BSD     +++  RENT this banner advert  +++    ASCII Ribbon   /"\
Work - Mac      +++  space for low ????????? NOW!1  +++      Campaign     \ /
Party Enjoy Relax   |   http://dragonflybsd.org      Against  HTML   \
Dude 2c 2 the max   !   http://golden-apple.biz       Mail + News   / \




From c.turner at 199technologies.org  Sun Mar 23 10:50:13 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Sun, 23 Mar 2008 10:50:13 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <47E69656.8080605@199technologies.org>

Simon 'corecode' Schubert wrote:
brave investigation.  but you could also simply set UNAME_r :)
Doh! Thanks for the tip!

they should change the phrase from RTFM to 'Carefully RTFM' :)

well.. scratch that change then. 1 less patch to write.

- Chris





From c.turner at 199technologies.org  Sun Mar 23 11:15:52 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Sun, 23 Mar 2008 11:15:52 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <47E69C7C.8010109@199technologies.org>

Chris Turner wrote:
Simon 'corecode' Schubert wrote:
brave investigation.  but you could also simply set UNAME_r :)

for the record - if anyone's interested - adding a line e.g.:

ALL_ENV+= UNAME_r=1.12-RELEASE

to mk.conf looks like it -might- work ..

(unless wants to chime in & verify)





From joerg at britannica.bec.de  Sun Mar 23 11:46:53 2008
From: joerg at britannica.bec.de (Joerg Sonnenberger)
Date: Sun, 23 Mar 2008 11:46:53 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <20080323181428.GA2099@britannica.bec.de>

On Sun, Mar 23, 2008 at 01:41:42PM -0400, Chris Turner wrote:
> they should change the phrase from RTFM to 'Carefully RTFM' :)

RTFMAI -- Read The Fine Manual Again, Idiot.

Joerg




From dillon at apollo.backplane.com  Sun Mar 23 20:05:36 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Sun, 23 Mar 2008 20:05:36 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
Message-ID: <200803240257.m2O2voNH038355@apollo.backplane.com>

    Here's an update on the HAMMER work!

    Current status:

    * Passes all standard filesystem stress tests and buildworld will
      run with a HAMMER /usr/obj.  Large histories are able to accumulate
      without effecting performance.

    * Pruning and reblocking code is in and partially tested, but now needs
      more stringent testing.

    * Full historical access appears to be working but needs testing.
      Note that a sync is still needed to flush dirty cached data prior
      to acquiring a timestamp for the 'snapshot' to be set in stone.
      (dirty data cached in-memory has no historical tags and must be
      committed to physical disk before it can be accessed historically).


    Current bugs:

    * There is one known bug in the standard operations code paths
      that results in an assertion in HAMMER's I/O subsystem.

    * There are probably bugs in the reblocking and/or pruning code.  More
      likely in the reblocking code.


    There are two big-ticket and several little-ticket items left.  HAMMER
    will officially go Alpha when the big-ticket items are done, and beta
    when we get a few of the little-ticket items done.

    Big ticket items left:

    * UNDO (crash recovery) code.  Currently it writes out undo records but
      they are not yet sequenced, buffer writes are not yet ordered, and
      there is no mount-time recovery code yet.

      This is the last item needed before HAMMER can go operational.

    * Filesystem full handling.  Currently no space is reserved for dirty
      cached data so it is possible to create/write files and for HAMMER
      to not have sufficient space left on-disk to flush it.


    Little ticket items:

    * Automated reblocking (currently these functions are manually
      initialized via the hammer utility).

    * I/O clustering and preliminary BMAP op when writing out large files.

    * CRC checking (CRC fields are reserved but not entirely generated yet
      and not yet checked at all).

    * Disaster Recovery filesystem scan.

    * Boot support.

    I expect all of these items and more to be handled by the 2.0 release
    in July.

			    Additional HAMMER capabilities
				(no timeline yet)

    * Adding, removing, and resizing a HAMMER filesystem's backing store.

			Ultimate Goals and working towards them
				(no timeline yet)

    Our ultimate goal with HAMMER and DragonFly in general is to support
    fully cache coherent replication in a multi-machine environment.  This
    involves several steps and networking protocols.

    * Replication of synchronization streams based on the UNDO log.  If
      resynchronizing to a target which is too old a B-Tree scan will
      likely be required.

    * Cache coherency protocols for machine-machine coherency for both
      replicated and remote-HAMMER access.

    I have no time frame for these items yet.  It will depend on how quickly
    HAMMER moves to Alpha and Beta status.  I will say, however, now
    that HAMMER's on-disk format has solidified, that I have a very precise
    understanding of the protocols that will be needed to accomplish fully
    cache coherent remote access for both replicated and non-replicated
    (remote mount style) access.

    And, as you know, fully coherent filesystem access across machines is
    going to be the basis for DragonFly's clustering across said machines.

    In summary, things are progressing very well.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From justin at shiningsilence.com  Sun Mar 23 20:10:13 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Sun, 23 Mar 2008 20:10:13 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <53758.192.168.0.252.1206327873.squirrel@www.shiningsilence.com>

On Sun, March 23, 2008 12:36 pm, Chris Turner wrote:

> it seems like if spoofing uname is configured inside a jail,
> the next (or previous..) release can be installed into a jail and
> used for building / testing packages without the overhead of a VM or
> maintaining a separate physical host

If you don't need a jail to spoof uname, as others posted, you can
installworld into a chroot and build everything you want there using
Joerg's spiffy pbulk.  That's what I'm doing on pkgbox now; I can hand you
my somewhat terse notes if you want.  It would be relatively easy to set
up the configuration you're talking about.





From sepherosa at gmail.com  Sun Mar 23 20:18:20 2008
From: sepherosa at gmail.com (Sepherosa Ziehau)
Date: Sun, 23 Mar 2008 20:18:20 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <ea7b9c170803232012n2f27f893tf1d756d7c9770419@mail.gmail.com>

On Mon, Mar 24, 2008 at 2:14 AM, Joerg Sonnenberger
<joerg at britannica.bec.de> wrote:
> On Sun, Mar 23, 2008 at 01:41:42PM -0400, Chris Turner wrote:
>  > they should change the phrase from RTFM to 'Carefully RTFM' :)
>
>  RTFMAI -- Read The Fine Manual Again, Idiot.

http://leaf.dragonflybsd.org/~sephe/rtfm.jpg

:D

>
>  Joerg
>



-- 
Live Free or Die




From justin at shiningsilence.com  Sun Mar 23 20:38:30 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Sun, 23 Mar 2008 20:38:30 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: GSoC 2008 - mentors signup
Message-ID: <53885.192.168.0.252.1206329503.squirrel@www.shiningsilence.com>

If you are planning to be a mentor for a Summer of Code project, please
sign up here for the mentors mailing list:

http://groups.google.com/group/google-summer-of-code-mentors-list

If you've already signed up, your subscription should be set up tomorrow.





From justin at shiningsilence.com  Sun Mar 23 21:12:01 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Sun, 23 Mar 2008 21:12:01 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: GSoC 2008 - mentors signup
In-Reply-To: <53885.192.168.0.252.1206329503.squirrel@www.shiningsilence.com>
Message-ID: <54025.192.168.0.252.1206331572.squirrel@www.shiningsilence.com>

Also!

If you are a potential mentor and you have not done so yet:

http://code.google.com/soc/mentor_step1.html

Get yourself registered as a mentor for the Summer of Code project.  Once
you are in there, check off DragonFly in the "My Profile" section.

You will need a Google Account if you don't have one:

http://www.google.com/accounts

This will add you to the list of mentors in the Google Summer of Code web
application, so you can review/be attached to projects.

A guide is available if you want more information:

http://groups.google.com/group/google-summer-of-code-announce/web/guide-to-the-gsoc-web-app-for-mentors-and-organization-administrators






From c.turner at 199technologies.org  Mon Mar 24 04:29:28 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Mon, 24 Mar 2008 04:29:28 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <47E78ECE.4070307@199technologies.org>

Justin C. Sherrill wrote:
If you don't need a jail to spoof uname, as others posted, you can
installworld into a chroot and build everything you want there using
Joerg's spiffy pbulk.  That's what I'm doing on pkgbox now; I can hand you
my somewhat terse notes if you want.  It would be relatively easy to set
up the configuration you're talking about.
cheers - I guess I thought incorrectly that something 'special' was 
needed to get the uname to change .. have been using the legacy bulks in 
chroots / jails (for 'same os' builds) as I haven't quite migrated to 
pbulk yet ..

thanks for the help offer - I'll ask if I run into trouble.




From dillon at apollo.backplane.com  Mon Mar 24 08:28:49 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Mon, 24 Mar 2008 08:28:49 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <200803241500.m2OF0CG8043760@apollo.backplane.com>


:http://leaf.dragonflybsd.org/~sephe/rtfm.jpg
:
::D

    Ho!

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From elekktretterr at exemail.com.au  Mon Mar 24 09:10:15 2008
From: elekktretterr at exemail.com.au (Petr Janda)
Date: Mon, 24 Mar 2008 09:10:15 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
In-Reply-To: <200803240257.m2O2voNH038355@apollo.backplane.com>
Message-ID: <200803250138.49775.elekktretterr@exemail.com.au>


>
>     And, as you know, fully coherent filesystem access across machines is
>     going to be the basis for DragonFly's clustering across said machines.
>
>     In summary, things are progressing very well.
>


Hi Matt,
That's good to know things are going so well. Got a question. If memory serves 
me right, initially there was also going to be a thing called ANVIL, I can't 
remember what it was supposed to do and whether its still in your design. 
Could you elaborate a little?

Thanks,
Petr




From dillon at apollo.backplane.com  Mon Mar 24 14:12:11 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Mon, 24 Mar 2008 14:12:11 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
In-Reply-To: <200803240257.m2O2voNH038355@apollo.backplane.com>
Message-ID: <200803242100.m2OL0nWV046868@apollo.backplane.com>


:Hi Matt,
:That's good to know things are going so well. Got a question. If memory serves 
:me right, initially there was also going to be a thing called ANVIL, I can't 
:remember what it was supposed to do and whether its still in your design. 
:Could you elaborate a little?
:
:Thanks,
:Petr

    It's not really in the HAMMER design any more, primarily because HAMMER's
    volume model seems to work fine as-is.  Ultimately something like ANVIL
    (a block storage manager) would prove beneficial to the project but it
    would be treated as a separate project.  HAMMER's redundancy model is
    going to be baesd around replication and clustering.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From tgen at netphreax.net  Mon Mar 24 18:31:37 2008
From: tgen at netphreax.net (Thomas E. Spanjaard)
Date: Mon, 24 Mar 2008 18:31:37 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
In-Reply-To: <200803240257.m2O2voNH038355@apollo.backplane.com>
Message-ID: <47E85337.2070407@netphreax.net>

Matthew Dillon wrote:
    * Full historical access appears to be working but needs testing.
      Note that a sync is still needed to flush dirty cached data prior
      to acquiring a timestamp for the 'snapshot' to be set in stone.
      (dirty data cached in-memory has no historical tags and must be
      committed to physical disk before it can be accessed historically).
Wouldn't making timestamp queries (at least from userland) enforce a 
sync on the volume in question be useful here?
--
        Thomas E. Spanjaard
        tgen at netphreax.net
Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00005.pgp
Type: application/octet-stream
Size: 186 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080324/3077333f/attachment-0019.obj>

From dillon at apollo.backplane.com  Mon Mar 24 20:10:12 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Mon, 24 Mar 2008 20:10:12 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
In-Reply-To: <200803240257.m2O2voNH038355@apollo.backplane.com>
Message-ID: <200803250302.m2P32qLP050160@apollo.backplane.com>


:Wouldn't making timestamp queries (at least from userland) enforce a 
:sync on the volume in question be useful here?
:-- 
:         Thomas E. Spanjaard
:         tgen at netphreax.net

    Making the 'hammer now' command do a sync() is a good idea.  I will
    make that change right now so it doesn't get lost.

    Here's a general overview of the issues involved with having historical
    access to the filesystem:

				----------------

    Recording the timestamps in the in-memory cache, for a finer-grained
    snapshot capability, is doable but has its own issues.  Here's an
    illustration:

    open()  create file
    write() append 4K	(file size now 4K)
    write() append 4K	(file size now 8K)
    write() append 4K	(file size now 12K)
    write() append 4K	(file size now 16K)

    Now NONE of this has gone to disk yet, it's entirely in the in-memory
    cache.  The inode is in the in-memory cache.  The data is stored in
    the buffer cache.  Even the directory entry for the file that we
    just created is still in the in-memory cache (HAMMER caches the raw
    records it intends to commit later on).

    If I wanted to be able to acquire a timestamp between each write and
    'see' a snapshot of the file as of any point in the above sequence,
    then every write would also have to allocate a copy of the inode
    (because it changes size on each write).

    The data has the same problem though with a slightly different example.
    Lets say each write() was a seek-write, overwriting the previous data.
    Now with every write() I would have to allocate a copy of the data
    being overwritten.  This is complicated by the fact that the buffer
    cache has no clue about 'historical' accesses, so I would not be able
    to use the buffer cache to cache the data.

    There's also another problem and that is with the efficiency of the
    topology on-disk.  Even if I maintained all the copies of the inode
    and all the copies of the data in-memory, I would still have to sync
    all those copies to disk in order for things to remain historically
    coherent (whether it be in-cache or on-disk).  This would result in
    hundreds or even thousands of copies of the inode on-disk, not to
    mention potentially many copies of the data.

    I just don't want to do that right now, at least not as a default.  A
    lot of performance would be lost.  Hence a sync() is needed if
    you want to create a demark which you can accurately snapshot.

				-------------

    Here's a quick synopsis of how the cache would operate in a clustered
    filesystem:

    In order to properly integrate with in-memory caches, a wider cache
    coherency infrastructure is needed between machines such that
    modifications made on one machine proactively invalidate those
    protions of the cache(s) on other machines.  At the same time, any
    'dirty' cache data, for example when a file is created or written to,
    must lock the cache space in question on all other machines.
    The cache space in this case is not just the file data, but also the
    related namespaces (for creations, deletions, and renames).  Attempts
    to access locked spaces from other machines in the cluster would have
    to force a flush to the filesystem backing store and lower the cache
    states for the effected information on the original machine from dirty
    to shared-read-only.

    It will be easiest to integrate the cache coherency information into
    the buffer cache and namecache themselves.  Once a machine has dirtied
    an in-memory cache element... for example part of the namespace when
    creating a file or chunks of data written within a file, that machine
    must have a free hand to make further modifications to the cache spaces
    involved without further interaction with other machines.

				-------------

    Now, if you think of those two major elements you can see that they
    actually fit together quite well.  If I were to attempt to maintain
    transactional coherency on a per-system-call basis then the cache
    granularity between machines would have to be much, much smaller then
    our current in-memory caching elements provide.  That would become
    a really nasty coding problem.  So I don't even want to begin to
    complate transactional coherency at a finer-grain then sync() or
    fsync() until long after we actually have clustering working.

						-Matt





From elekktretterr at exemail.com.au  Mon Mar 24 21:56:58 2008
From: elekktretterr at exemail.com.au (Petr Janda)
Date: Mon, 24 Mar 2008 21:56:58 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
In-Reply-To: <200803240257.m2O2voNH038355@apollo.backplane.com>
Message-ID: <200803251516.16407.elekktretterr@exemail.com.au>

So is it needed to run hammer now in order to "create" a snapshot? What would 
I do in situation like this: got a hammer filesystem and couple of the files 
change on day to day basis. Then a week later I needed to access one of the 
files, in exactly the state they were 7 days ago.

Cheers,
Petr




From dillon at apollo.backplane.com  Mon Mar 24 22:34:15 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Mon, 24 Mar 2008 22:34:15 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
In-Reply-To: <200803240257.m2O2voNH038355@apollo.backplane.com>
Message-ID: <200803250526.m2P5QZ5X051081@apollo.backplane.com>


:So is it needed to run hammer now in order to "create" a snapshot? What would 
:I do in situation like this: got a hammer filesystem and couple of the files 
:change on day to day basis. Then a week later I needed to access one of the 
:files, in exactly the state they were 7 days ago.
:
:Cheers,
:Petr

    No, you do not have to run 'hammer now' to create a snapshot.  The
    kernel syncs all filesystems every 30 seconds, so if you do nothing
    at all you get a snapshot granularity of 30 seconds.

    Where you would use 'hammer now' is if you wanted the most current
    snapshot possible for the purpose of, say, backing up your filesystem
    to another machine.  You might do something like this:

	set timestamp = `hammer now`
	cpdup /mountpoint/@@$timestamp targethost:/somepath

    But if you didn't care about that you could just go back far enough
    that you get a stable historical view... e.g. go back 1 minute and you
    would have a stable view into your filesystem.

	set timestamp = `hammer stamp 60s`		<------ doesn't sync
	cpdup /mountpoint/@@$timestamp targethost:/somepath


    Ultimately the idea of managing filesystems this way is to still do
    regular backups from your production machine to your backup machine
    (ultimately by way of replication), with both running HAMMER, but only
    retain a limited amount of history on the production box.  You might
    desire to retain only one week's worth of history on the production box,
    retain one month's history on your local backup box, and retain a very
    granular one year's worth of history on your remote backup box.

    Come to think of it, I should add some more directives to the
    'hammer prune' command to make that easier to specify.

    Until I implement a live replication 'feed' the minimum granularity on
    the backup box will be how often you do your backups (e.g. once a day),
    and you can prune it into more granular forms from that starting point.
    Once we have a live replication feed the backup box will have the same
    30-second granularity that the production machine has.

    A major bullet point for this style of management is that the retention
    policy on the various boxes can be different even though they are
    all slaved off the same production filesystem.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From justin at shiningsilence.com  Tue Mar 25 05:58:49 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Tue, 25 Mar 2008 05:58:49 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: SoC - student signups
Message-ID: <58180.65.106.147.226.1206449676.squirrel@www.shiningsilence.com>

Here's a quick link roundup:

Are you a student?  Put in your application for a Google Summer of Code here:

http://code.google.com/soc/2008/student_signup.html

Student guide:
http://groups.google.com/group/google-summer-of-code-announce/web/guide-to-the-gsoc-web-app-for-student-applicants

Are you a mentor?  (That means hasso, hsu, sephe, matthias, TGEN, and
corecode right now)

Student proposals will show up on the mentor page, linked below.  You will
get to rate them, and take the one(s) that you want to mentor.

Mentor page:
http://code.google.com/soc/2008/mentor_home.html
Mentor guide:
http://groups.google.com/group/google-summer-of-code-announce/web/guide-to-the-gsoc-web-app-for-mentors-and-organization-administrators

If you are a mentor and are communicating with potential students, send
them the URLs above for student signup and the student guide; work with
them if they ask for advice on what to say in the application.  They can
resubmit up to 20 times if they want to correct it.

Deadline is March 31st.






From noah.yan at gmail.com  Thu Mar 27 20:17:48 2008
From: noah.yan at gmail.com (Yonghong Yan)
Date: Thu, 27 Mar 2008 20:17:48 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: About DFBSD.64
In-Reply-To: <47EB0B5B.5020802@gmail.com>
Message-ID: <59521b110803272015y1cc8cc39uc93f154ed36e0505@mail.gmail.com>

thanks for your interest.

I owe to everybody for any update or work in the past four months. so
many things happen in my work and my family (they are all good:) and
keep me extremely busy. But i am not leaving and will be back on this
soon.

the latest sources are in http://repo.or.cz/w/dragonfly/port-amd64.git
, I did have a compiled kernel long time before, but I have to break
it to work on the pmap. you can pick up from there. TGEN will help you
a lot, also keep me posted too, if you like.

Noah

On Wed, Mar 26, 2008 at 9:50 PM, Sdavtaker <sdavtaker at gmail.com> wrote:
> Hello,
>  Im applying to GSoC to work in the x64 version of DFBSD with TGEN, i
>  found some work already done in the repository and some mails in the
>  archive from you.
>  I was wondering if you already had a working compiled kernel in AMD64
>  machine and what was not working yet to continue that work.
>  Thanks for any info.
>  Sdav
>




From dillon at apollo.backplane.com  Sat Mar 29 13:27:43 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Sat, 29 Mar 2008 13:27:43 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 29-Mar-2008
Message-ID: <200803292022.m2TKMLGe004942@apollo.backplane.com>

    Good progress continues to be made.  HAMMER survived acting as my
    LAN backup machine (in full historical mode) for almost a week before
    it hit an assertion.  I've fixed that issue and believe that the core
    filesystem implementation code is now 'very stable'.

    Note that the recent commit will result in many more 'hammer_lock_ex:'
    messages on the console then you may have previously observed.  This is
    due to the way object id's are allocated in the face of parallel 
    modifications to the filesystem, resulting in too much locality of
    reference in the B-Tree.  I do intend to improve it.

    I am still working on the two major items needed before HAMMER can be
    declared operational, those being the filesystem full handling and the
    undo/recovery-on-mount code.  These are the last 'hard' bits left in
    the design.

    With exception to filling up the filesystem, which *will* create a mess,
    and noting that no crash recovery code exists yet (so you have to newfs
    it if you crash), I'd appreciate it if interested parties could test
    the other functions of the filesystem, in particular the pruning and
    reblocking functions (man hammer), and the historical access functions.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From dillon at apollo.backplane.com  Sun Mar 30 15:11:03 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Sun, 30 Mar 2008 15:11:03 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Need ideas on how to solve an st_ino/st_dev test issue for HAMMER.
Message-ID: <200803302207.m2UM7BCp016402@apollo.backplane.com>

    Here's the problem, given historical access softlinks as shown below:

test30# ls -lda cra*
drwxr-xr-x  1 root  wheel  Mar 29 13:04 crater
lrwxr-xr-x  1 root  wheel  Mar 29 18:57 crater.20080329 -> crater@@0x47eef383
lrwxr-xr-x  1 root  wheel  Mar 30 01:24 crater.20080330 -> crater@@0x47ef4e29
-rw-r--r--  2 root  wheel  Mar 30 01:24 crater.log

    The problem is that if I do this:

    diff -r crater.20080329/var/log crater.20080330/var/log

    Diff just returns without actually diffing anything.  The reason is
    because diff checks st_ino and st_dev and believes the directories/files
    to be identical because they match.

    I considered munging the inode number for historical accesses, but
    that would seriously break NFS exports which try to access historical
    files and directories.  Right now NFS *is* able to distinguish between
    the two because NFS handles are 128-bit-wide entities, so I can encode
    the as-of transaction id as part of the filehandle.  But userland
    programs only have access to a 64-bit-wide inode so userland still
    believes the files to be identical.

    st_dev is only 32 bits, carefully munging it is an option if we
    could figure out a way to do it, but I'd rather not.

    I am considering using st_gen but then we'd have to patch third
    party software to test st_gen along with everything else.  This may
    be the only workable solution, though, and only a few programs would
    need to be patched.  st_gen is only 32 bits but it would solve the
    problem as we would be able to use all 32 bits.

    If anyone has any bright ideas, including 'leave it alone', I'm all
    ears.

						-Matt





From justin at shiningsilence.com  Mon Mar 31 10:40:42 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Mon, 31 Mar 2008 10:40:42 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: SoC student applications due by 5PM PDT tomorrow
In-Reply-To: <1942.192.168.0.242.1206930479.squirrel@www.shiningsilence.com>
Message-ID: <11892.67.108.184.175.1206984967.squirrel@www.shiningsilence.com>

On Sun, March 30, 2008 10:27 pm, Justin C. Sherrill wrote:
> SoC students:
>
> If you have an application to submit for DragonFly/Summer of Code, please
> do so by 17:00 Pacific time on the 31st - that's tomorrow, at least for
> me.

The deadline for student proposals has been extended to April 7th; all
other dates move forward one week to acommodate.

This is a good time to update existing applications or submit new ones. 
Talk to your (potential) mentors if you are curious.






From nthery at gmail.com  Mon Mar 31 11:29:49 2008
From: nthery at gmail.com (Nicolas Thery)
Date: Mon, 31 Mar 2008 11:29:49 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
Message-ID: <64fc43b0803311126na7d0b27obaa9d35bac6d32ee@mail.gmail.com>

Hello,

Now that the release is over, I'll try to get rid of zones and migrate
allocations to objcache.

Here is a 1st patch that migrate struct proc.  I'll commit it in a
couple of days if nobody objects.

I'm also implementing a way to monitor objcache statistics.  So far,
I've hacked sth similar to
sysctl vm.zone: stats are returned in one giant string, one line per
cache.  That's simple but ugly and hard to read because there are
quite a few stats per cache.

So I'm thinking about implementing a small tool, ocstat, that extracts
stats from sysctl the way ps(1) does (thru libkvm iirc) and formats it
in various ways.  What do you think?

Cheers,
Nicolas

Index: src2/sys/kern/kern_exit.c
===================================================================
--- src2.orig/sys/kern/kern_exit.c	2008-03-31 08:05:59.139796000 +0200
+++ src2/sys/kern/kern_exit.c	2008-03-31 10:31:39.000000000 +0200
@@ -834,7 +834,7 @@ loop:
 			}

 			vm_waitproc(p);
-			zfree(proc_zone, p);
+			objcache_put(proc_cache, p);
 			nprocs--;
 			return (0);
 		}
Index: src2/sys/kern/kern_proc.c
===================================================================
--- src2.orig/sys/kern/kern_proc.c	2008-03-31 08:05:59.139918000 +0200
+++ src2/sys/kern/kern_proc.c	2008-03-31 10:31:39.000000000 +0200
@@ -84,7 +84,7 @@ u_long pgrphash;
 struct proclist allproc;
 struct proclist zombproc;
 struct spinlock allproc_spin;
-vm_zone_t proc_zone;
+struct objcache* proc_cache;
 vm_zone_t lwp_zone;
 vm_zone_t thread_zone;

@@ -131,7 +131,7 @@ procinit(void)
 	spin_init(&allproc_spin);
 	pidhashtbl = hashinit(maxproc / 4, M_PROC, &pidhash);
 	pgrphashtbl = hashinit(maxproc / 4, M_PROC, &pgrphash);
-	proc_zone = zinit("PROC", sizeof (struct proc), 0, 0, 5);
+	proc_cache = objcache_create_simple(M_PROC, sizeof(struct proc));
 	lwp_zone = zinit("LWP", sizeof (struct lwp), 0, 0, 5);
 	thread_zone = zinit("THREAD", sizeof (struct thread), 0, 0, 5);
 	uihashinit();
Index: src2/sys/sys/proc.h
===================================================================
--- src2.orig/sys/sys/proc.h	2008-03-31 08:05:59.140325000 +0200
+++ src2/sys/sys/proc.h	2008-03-31 10:31:39.000000000 +0200
@@ -473,7 +473,7 @@ struct proc *zpfind (pid_t);	/* Find zom
 struct vm_zone;
 struct globaldata;
 struct lwp_params;
-extern struct vm_zone *proc_zone;
+extern struct objcache *proc_cache;
 extern struct vm_zone *lwp_zone;

 int	enterpgrp (struct proc *p, pid_t pgid, int mksess);
Index: src2/sys/kern/kern_fork.c
===================================================================
--- src2.orig/sys/kern/kern_fork.c	2008-03-31 08:05:59.140042000 +0200
+++ src2/sys/kern/kern_fork.c	2008-03-31 10:31:39.000000000 +0200
@@ -332,7 +332,7 @@ fork1(struct lwp *lp1, int flags, struct
 	}

 	/* Allocate new proc. */
-	p2 = zalloc(proc_zone);
+	p2 = objcache_get(proc_cache, M_WAITOK);
 	bzero(p2, sizeof(*p2));

 	/*




From hsu at dragonflybsd.org  Mon Mar 31 11:44:34 2008
From: hsu at dragonflybsd.org (Jeffrey Hsu)
Date: Mon, 31 Mar 2008 11:44:34 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <64fc43b0803311126na7d0b27obaa9d35bac6d32ee@mail.gmail.com>
Message-ID: <200803311841.m2VIfQAI007579@nlpi001.prodigy.net>

The object cache is not a general-purpose memory allocator.  It's a cache of
pre-initialized objects.  Are the significant portions of the proc structure
that can be restored to initialized state on object puts?  If not, it's best
to just use a general-purpose memory allocator.

								Jeffrey




From corecode at fs.ei.tum.de  Mon Mar 31 12:07:02 2008
From: corecode at fs.ei.tum.de (Simon 'corecode' Schubert)
Date: Mon, 31 Mar 2008 12:07:02 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <200803311841.m2VIfQAI007579@nlpi001.prodigy.net>
Message-ID: <47F1357B.1070302@fs.ei.tum.de>

Jeffrey Hsu wrote:
> The object cache is not a general-purpose memory allocator.  It's a cache of
> pre-initialized objects.  Are the significant portions of the proc structure
> that can be restored to initialized state on object puts?  If not, it's best
> to just use a general-purpose memory allocator.

Why?  What's the loss if we use the object cache to allocate struct procs?

cheers
  simon

Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00006.pgp
Type: application/octet-stream
Size: 252 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080331/a4a24314/attachment-0019.obj>

From nthery at gmail.com  Mon Mar 31 12:17:03 2008
From: nthery at gmail.com (Nicolas Thery)
Date: Mon, 31 Mar 2008 12:17:03 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <nthery@gmail.com>
Message-ID: <64fc43b0803311214u7da6bbb8xaf971de1a80e7258@mail.gmail.com>

2008/3/31, Jeffrey Hsu <hsu at dragonflybsd.org>:
> The object cache is not a general-purpose memory allocator.  It's a cache of
>  pre-initialized objects.  Are the significant portions of the proc structure
>  that can be restored to initialized state on object puts?  If not, it's best
>  to just use a general-purpose memory allocator.

Well, I haven't checked this yet.  I planned to do this in a second
step after getting rid of zones.

I thought that even without  the pre-initialization part, objcache has
the advantage
of pre-allocating set of objects (as zones) and is additionally
mp-safe (contrary to zones and, granted, as malloc()).   The latter
may be interesting as we talk of improving MP support.

Cheers,
Nicolas




From dillon at apollo.backplane.com  Mon Mar 31 12:23:40 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Mon, 31 Mar 2008 12:23:40 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <200803311841.m2VIfQAI007579@nlpi001.prodigy.net>
Message-ID: <200803311921.m2VJLITB027669@apollo.backplane.com>

    I both agree and disagree with Jeff.  I think the only *disadvantage*
    to using objcache for struct proc is that objcache must cache a minimum
    number of free structures to be efficient so the overall kernel memory
    use would be a bit greater verses uses kmalloc().  But I agree with Jeff
    in that objcache's biggest advantage is that you can keep structural state
    intact and struct proc might not be a good candidate (yet).

    What I suggest is that you convert struct proc from zone to kmalloc
    first, and then look into a possible objcache adaptation.  kmalloc
    is not slow.. it's a very fast allocator.  Objcache is probably a tad
    faster but not by much.  Where objcache really wins is in not having
    to completey reinitialize the allocated structures.

    Over the years I've removed (I think) all the dependancies on requiring
    the proc structure to be in stable memory so I believe it can be moved to
    kmalloc/objcache now without any major pain.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From corecode at fs.ei.tum.de  Mon Mar 31 12:37:40 2008
From: corecode at fs.ei.tum.de (Simon 'corecode' Schubert)
Date: Mon, 31 Mar 2008 12:37:40 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: SoC student applications due by 5PM PDT tomorrow
In-Reply-To: <1942.192.168.0.242.1206930479.squirrel@www.shiningsilence.com>
Message-ID: <47F13CDA.6010703@fs.ei.tum.de>

Justin C. Sherrill wrote:
> On Sun, March 30, 2008 10:27 pm, Justin C. Sherrill wrote:
>> SoC students:
>>
>> If you have an application to submit for DragonFly/Summer of Code, please
>> do so by 17:00 Pacific time on the 31st - that's tomorrow, at least for
>> me.
> The deadline for student proposals has been extended to April 7th; all
> other dates move forward one week to acommodate.

This is very good.

Some more ideas for eager students (we want to keep the ratio, right?):

Enhance the FreeBSD/DragonFly sound infrastructure to support surround
sound/multichannel output.

Update sound drivers to support S/PDIF output.

Make the sound infrastructure OSSv4 compatible (there was a SoC at
FreeBSD last year or so)


of course only if it doesn't exist already :)

cheers
  simon


Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00007.pgp
Type: application/octet-stream
Size: 252 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080331/6da61cff/attachment-0019.obj>

From corecode at fs.ei.tum.de  Mon Mar 31 12:41:30 2008
From: corecode at fs.ei.tum.de (Simon 'corecode' Schubert)
Date: Mon, 31 Mar 2008 12:41:30 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <200803311841.m2VIfQAI007579@nlpi001.prodigy.net>
Message-ID: <47F13DE4.10205@fs.ei.tum.de>

Matthew Dillon wrote:
>     What I suggest is that you convert struct proc from zone to kmalloc
>     first, and then look into a possible objcache adaptation.  kmalloc
>     is not slow.. it's a very fast allocator.  Objcache is probably a tad
>     faster but not by much.  Where objcache really wins is in not having
>     to completey reinitialize the allocated structures.

Could we please not move to kmalloc, but instead try to move all fast
path allocations to objcache?  I don't like the idea of allocating
everything with kmalloc.  Caching struct procs is not a bad thing itself.

cheers
  simon


Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00008.pgp
Type: application/octet-stream
Size: 252 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080331/ac328c08/attachment-0019.obj>

From hsu at FreeBSD.org  Mon Mar 31 12:59:05 2008
From: hsu at FreeBSD.org (Jeffrey Hsu)
Date: Mon, 31 Mar 2008 12:59:05 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <47F1357B.1070302@fs.ei.tum.de>
Message-ID: <200803311920.m2VJK5Ln018015@nlpi015.prodigy.net>

The object cache sits on top of a general-purpose memory allocator such
as kmalloc or zalloc and provides pre-initialized object caching functionality.
If you're not going to use the object caching functionality, you can just
call the underlying memory allocator directly.

							Jeffrey




From dillon at apollo.backplane.com  Mon Mar 31 16:17:19 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Mon, 31 Mar 2008 16:17:19 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <200803311841.m2VIfQAI007579@nlpi001.prodigy.net>
Message-ID: <200803312311.m2VNBumd029866@apollo.backplane.com>

:Could we please not move to kmalloc, but instead try to move all fast
:path allocations to objcache?  I don't like the idea of allocating
:everything with kmalloc.  Caching struct procs is not a bad thing itself.=
:
:
:cheers
:  simon

    I will state for the record that I'm fine with either objcache or
    kmalloc.  I agree with Jeff that using objcache for struct proc
    probably isn't necessary but I also agree that it would not hurt either,
    and if the intent is to optimize the initialization of the proc
    structure in the future then moving to objcache now would save us
    from having to do it later.

    So whichever method Nicolas wants to use is fine with me.

						-Matt




From hsu at dragonflybsd.org  Mon Mar 31 19:22:47 2008
From: hsu at dragonflybsd.org (Jeffrey Hsu)
Date: Mon, 31 Mar 2008 19:22:47 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <64fc43b0803311214u7da6bbb8xaf971de1a80e7258@mail.gmail.com>
Message-ID: <200804010218.m312IVUq003624@nlpi043.prodigy.net>

  >> Are there significant portions of the proc structure
  >> that can be restored to initialized state on object puts?

  > I planned to do this in a second step after getting rid of zones.

I'll all in favor of making more use of caching pre-initialized objects, so
if this is your objective, then please go ahead.  It's just that I'd convert
over to the object cache in one step.

  > I thought that even without  the pre-initialization part, objcache has
  > the advantage of pre-allocating set of objects (as zones) and is additionally
  > mp-safe (contrary to zones and, granted, as malloc()).

Well, the zone allocator is MP-safe.  It's not hard to lock up the places that
manipulate the linked-list of free items. Look for uses of the zlock field.

								Jeffrey




From tgen at netphreax.net  Sat Mar  1 12:57:53 2008
From: tgen at netphreax.net (Thomas E. Spanjaard)
Date: Sat, 1 Mar 2008 12:57:53 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: [Fwd: Project Support Open Source: $50 donation to support you      project]
In-Reply-To: <2468.192.168.0.242.1204346451.squirrel@www.shiningsilence.com>
Message-ID: <47C9C1B7.50203@netphreax.net>

Justin C. Sherrill wrote:
The "donation" happens after you place an "acknowledgement" on an open
source project's web page.  I'm putting those words in scare quotes
because I think it's a "payment" for an "advertisement".  The supplied
link has nothing to do with DragonFly, to say the least.

<a href="http://www.2insure4less.com /" title="We support FOSS software
projects.">Online Insurance Quotes</a>
To think our souls are only worth $50...
--
        Thomas E. Spanjaard
        tgen at netphreax.net
Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00000.pgp
Type: application/octet-stream
Size: 186 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080301/0d61e240/attachment-0020.obj>

From c.turner at 199technologies.org  Sat Mar  1 17:52:31 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Sat, 1 Mar 2008 17:52:31 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Misc. ACPI / suspend
Message-ID: <47CA073B.6020106@199technologies.org>

Wondering if anyone more well versed in the ACPI implementation could
comment on the applicability of:
http://lkml.org/lkml/2007/4/6/69

w/r/t the current state of the art in Dfly

(or BSD's in general)

Cheers!

- Chris




From elekktretterr at exemail.com.au  Sun Mar  2 00:41:25 2008
From: elekktretterr at exemail.com.au (Petr Janda)
Date: Sun, 2 Mar 2008 00:41:25 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: CARP question
Message-ID: <200803021934.21669.elekktretterr@exemail.com.au>

So Ive setup CARP on 2 DF-based mailservers. Installation went fine. Box 1 has 
adskew of 0 therefore it is the MASTER. Box 2 has adskew of 254, therefore is 
BACKUP.  If i down the carp0 interface on Box 1, then Box 2 carp interface 
gets promoted to MASTER. Then I up the carp interface on Box 1, logically Box 
2 should become BACKUP again as Box 1 becomes MASTER due to adskew set to 0.

However it doesnt happen. When carp0 interface on Box 1 is upped it becomes a 
BACKUP, not a MASTER even though according to adskew it should be MASTER.

What is the desired behaviour?

Cheers
Petr




From qhwt+dfly at les.ath.cx  Sun Mar  2 02:50:14 2008
From: qhwt+dfly at les.ath.cx (YONETANI Tomokazu)
Date: Sun, 2 Mar 2008 02:50:14 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: panic: assertion: hammer_btree_cmp(cursor->left_bound,	&cursor->node->ondisk->elms[0].leaf.base) <= 0 in btree_split_leaf
In-Reply-To: <200802232204.m1NM4cxd046264@apollo.backplane.com>
Message-ID: <20080302104554.GA22813@les.ath.cx>

Hi.
While trying to find a procedure to reliably reproduce the panic
I reported last time, I caught a different panic (uploaded at
 ~y0netan1/crash/9/ on my leaf account).  I wrote the following shell
script (make sure to edit variables DISKS and MOUNTPT before using this
script or it may trash your system):
  #!/bin/sh -ex
  DISKS="/dev/ad0s1f"
  MOUNTPT=/mnt/HAMMER

  cd /
  newfs_hammer -L TEST $DISKS
  for i in `seq 1 100`; do
	  mount_hammer $DISKS $MOUNTPT
	  /bin/rm -rf $MOUNTPT/??
	  (set +x; for x in `seq 1 10000`; do echo -n > $MOUNTPT/$x; done)
	  umount $MOUNTPT
  done

And the panic is triggered by rm command.
I'll try to see if it's possible to reproduce the last one without
unmounting then mounting the HAMMER fs.

Cheers.




From dillon at apollo.backplane.com  Sun Mar  2 13:25:33 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Sun, 2 Mar 2008 13:25:33 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: panic: assertion: hammer_btree_cmp(cursor->left_bound,	&cursor->node->ondisk->elms[0].leaf.base) <= 0 in btree_split_leaf
In-Reply-To: <200802232204.m1NM4cxd046264@apollo.backplane.com>
Message-ID: <200803022119.m22LJRCY037076@apollo.backplane.com>


:Hi.
:While trying to find a procedure to reliably reproduce the panic
:I reported last time, I caught a different panic (uploaded at
: ~y0netan1/crash/9/ on my leaf account).  I wrote the following shell
:script (make sure to edit variables DISKS and MOUNTPT before using this
:script or it may trash your system):

(from the core)

panic: assertion: node->lock.refs == 0 && node->ondisk == NULL in hammer_flush_buffer_nodes

    Yah, I've seen this failure.  Add a sync or two before the umount and
    tell me if it still occurs.  It's either a node reference leak somewhere
    or it is a race between bufdaemon and umount.  The assertions are really
    strict there precisely to catch those sorts of cases.

    Also note that the code to deal with a full HAMMMER filesystem has not
    been written yet (The failure you are reporting is unrelated to a full
    HAMMER filesystem, though, just mentioning it).

						-Matt





From dillon at apollo.backplane.com  Sun Mar  2 13:29:03 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Sun, 2 Mar 2008 13:29:03 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Misc. ACPI / suspend
In-Reply-To: <47CA073B.6020106@199technologies.org>
Message-ID: <200803022126.m22LQbfI037188@apollo.backplane.com>


:Wondering if anyone more well versed in the ACPI implementation could
:comment on the applicability of:
:
:http://lkml.org/lkml/2007/4/6/69
:
:w/r/t the current state of the art in Dfly
:
:(or BSD's in general)
:
:Cheers!
:
:- Chris

    I really have no idea re: this.  Suspension in general is not well
    supported by any of the BSDs.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From dillon at apollo.backplane.com  Sun Mar  2 13:34:05 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Sun, 2 Mar 2008 13:34:05 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: [Fwd: Project Support Open Source: $50 donation to support you      project]
In-Reply-To: <2468.192.168.0.242.1204346451.squirrel@www.shiningsilence.com>
Message-ID: <200803022131.m22LVOe9037250@apollo.backplane.com>

:..
:source project's web page.  I'm putting those words in scare quotes
:because I think it's a "payment" for an "advertisement".  The supplied
:link has nothing to do with DragonFly, to say the least.
:
:I don't think this is a good idea, obviously, and replied to that effect. 
:However, I wanted to put this on a DragonFly list, in part to show this
:strange thing, and in part because I'm not comfortable making
:administrative decisions on behalf of the Project without being open as
:possible about it.

    It doesn't really cry out to me either.

						-Matt





From wbh at conducive.org  Sun Mar  2 20:36:32 2008
From: wbh at conducive.org (Bill Hacker)
Date: Mon, 03 Mar 2008 04:36:32 +0000
Subject: Misc. ACPI / suspend
In-Reply-To: <47CA073B.6020106@199technologies.org>
Message-ID: <47cb8050$0$855$415eb37d@crater_reader.dragonflybsd.org>

Matthew Dillon wrote:
:Wondering if anyone more well versed in the ACPI implementation could
:comment on the applicability of:
:
:http://lkml.org/lkml/2007/4/6/69
:
:w/r/t the current state of the art in Dfly
:
:(or BSD's in general)
:
:Cheers!
:
:- Chris
    I really have no idea re: this.  Suspension in general is not well
    supported by any of the BSDs.
					-Matt
					Matthew Dillon 
					<dillon at backplane.com>


. . and there seems to be a bit of a 'Catch 22' there in any case.

If the BIOS can alter 'stuff' out of site of the OS it is parking, what 
does the existence of such a 'feature' do to a(ny) security model?

Seems to at least beg creating the option of setting a flag to 
specifically *prevent* suspend-to-disk/hibernation (and/or force a 
reboot on wake-up).

Just because one is paranoid....  etc

Bill





From matthias at dragonflybsd.org  Tue Mar  4 02:30:52 2008
From: matthias at dragonflybsd.org (Matthias Schmidt)
Date: Tue, 4 Mar 2008 02:30:52 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
Message-ID: <20080304102335.GI9833@staatsfeind.org>

Hi,

Google just announced its Summer of Code for 2008:

	http://code.google.com/soc/2008/

I think this would be a great opportunity for DragonFly to participate
as a mentoring organisation.  We could attract new developers and could
get code/work done.  Looking at the SoC results of the other BSDs most
of their projects were a success.  Of course, not all, but a reasonable
percentage.  See [1] and [2].

It is some extra work for us, but IMO the benefits outweigh the extra
work.  And yes, I would volunteer as a mentor.  What do others
(developers) think?  Any more volunteers? :)

Some project ideas that come into my mind.  More ideas are listed in the
wiki:  http://wiki.dragonflybsd.org/index.cgi/ProjectsPage

 * Fix all remaining bugs in dma(8) and implement all missing features
 * Add a driver for newer Intel Wireless cards (I think sephe@ would
   love that :)
 * Bring our ACPI stuff in shape.  Maybe suspend2disk ...

 * [Add your own thoughts here]

Cheers,

	Matthias

PS: I don't want to create a bikeshed here whether you like the SoC or
not :)

[1] http://code.google.com/soc/2007/freebsd/about.html
[2] http://code.google.com/soc/2007/netbsd/about.html




From corecode at fs.ei.tum.de  Tue Mar  4 04:46:14 2008
From: corecode at fs.ei.tum.de (Simon 'corecode' Schubert)
Date: Tue, 4 Mar 2008 04:46:14 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47CD4386.1000704@fs.ei.tum.de>

Matthias Schmidt wrote:
>  * [Add your own thoughts here]

MP lock removal for network stack

and for the system  (first profile, find hot spots, fix hot spots, repeat)

cheers
  simon




From c.turner at 199technologies.org  Tue Mar  4 06:02:20 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Tue, 4 Mar 2008 06:02:20 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47CD551E.1040604@199technologies.org>

Matthias Schmidt wrote:
Some project ideas that come into my mind.  More ideas are listed in the
wiki:  http://wiki.dragonflybsd.org/index.cgi/ProjectsPage
+1 acpi
+1 interrupt routing
+1 SMP / giant removal
+1 pf synchup with openbsd
though there are several others on the page that are good..

need to dig up my wiki login and place appropriately..

also: thinking the ZFS port should be removed from the page - makes 
sense to everyone else? (e.g. fragments effort w/r/t hammer)





From tgen at netphreax.net  Tue Mar  4 06:54:31 2008
From: tgen at netphreax.net (Thomas E. Spanjaard)
Date: Tue, 4 Mar 2008 06:54:31 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47CD615F.8010209@netphreax.net>

Matthias Schmidt wrote:
Google just announced its Summer of Code for 2008:

 * [Add your own thoughts here]
x86-64 port :).
--
        Thomas E. Spanjaard
        tgen at netphreax.net
Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00001.pgp
Type: application/octet-stream
Size: 186 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080304/0d921000/attachment-0020.obj>

From rdivacky at FreeBSD.org  Tue Mar  4 07:07:03 2008
From: rdivacky at FreeBSD.org (Roman Divacky)
Date: Tue, 4 Mar 2008 07:07:03 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <20080304150255.GA8831@freebsd.org>

On Tue, Mar 04, 2008 at 02:49:03PM +0000, Thomas E. Spanjaard wrote:
> Matthias Schmidt wrote:
> >Google just announced its Summer of Code for 2008:
> >
> > * [Add your own thoughts here]
> 
> x86-64 port :).

all those ideas are great and needed etc. but keep in
mind that the projects should be doable by students
who might see dfly for the very first time.

don't overestimate whats possible and select projects
that look realistic

Roman Divacky (former SoC student)




From justin at shiningsilence.com  Tue Mar  4 08:32:56 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Tue, 4 Mar 2008 08:32:56 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <60322.65.106.147.226.1204648095.squirrel@www.shiningsilence.com>

On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
> Hi,
>
> Google just announced its Summer of Code for 2008:
>
> 	http://code.google.com/soc/2008/
>
> I think this would be a great opportunity for DragonFly to participate
> as a mentoring organisation.  We could attract new developers and could
> get code/work done.  Looking at the SoC results of the other BSDs most
> of their projects were a success.  Of course, not all, but a reasonable
> percentage.  See [1] and [2].

We've applied in previous years - Jeff Hsu did one year, and I put
together the application last year.  The hardest thing to find was
students (and they are the thing that helps SoC applications a lot, I
think).

Any student volunteers?  We have mentors.





From rluciani at gmail.com  Tue Mar  4 09:38:29 2008
From: rluciani at gmail.com (Robert Luciani)
Date: Tue, 04 Mar 2008 18:38:29 +0100
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47cd8915$0$854$415eb37d@crater_reader.dragonflybsd.org>

Justin C. Sherrill wrote:
> On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
>> Hi,
>>
>> Google just announced its Summer of Code for 2008:
>>
>> 	http://code.google.com/soc/2008/
>>
>> I think this would be a great opportunity for DragonFly to participate
>> as a mentoring organisation.  We could attract new developers and could
>> get code/work done.  Looking at the SoC results of the other BSDs most
>> of their projects were a success.  Of course, not all, but a reasonable
>> percentage.  See [1] and [2].
> 
> We've applied in previous years - Jeff Hsu did one year, and I put
> together the application last year.  The hardest thing to find was
> students (and they are the thing that helps SoC applications a lot, I
> think).
> 
> Any student volunteers?  We have mentors.
> 

bingo

-- 
Robert Luciani
Chalmers University of Technology, SWE
Department of Computer Science and Engineering
http://www.rluciani.com/public.key




From sdavtaker at gmail.com  Tue Mar  4 09:31:08 2008
From: sdavtaker at gmail.com (=?UTF-8?Q?Sd=C3=A4vtaker?=)
Date: Tue, 4 Mar 2008 09:31:08 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <c37d69f60803040926k206218a3kb8496d0cd18148bd@mail.gmail.com>

If you mentor, i will apply for coder :-)
Still in last year of university. :-)
Sdav

On Tue, Mar 4, 2008 at 1:28 PM, Justin C. Sherrill
<justin at shiningsilence.com> wrote:
> On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
>  > Hi,
>  >
>  > Google just announced its Summer of Code for 2008:
>  >
>  >       http://code.google.com/soc/2008/
>  >
>  > I think this would be a great opportunity for DragonFly to participate
>  > as a mentoring organisation.  We could attract new developers and could
>  > get code/work done.  Looking at the SoC results of the other BSDs most
>  > of their projects were a success.  Of course, not all, but a reasonable
>  > percentage.  See [1] and [2].
>
>  We've applied in previous years - Jeff Hsu did one year, and I put
>  together the application last year.  The hardest thing to find was
>  students (and they are the thing that helps SoC applications a lot, I
>  think).
>
>  Any student volunteers?  We have mentors.
>
>



-- 
Sd?vtaker prays to Rikku goddess for a good treasure.



From rluciani at gmail.com  Tue Mar  4 09:44:02 2008
From: rluciani at gmail.com (Robert Luciani)
Date: Tue, 04 Mar 2008 18:44:02 +0100
Subject: google soc "DragonFly"
Message-ID: <47cd8a63$0$855$415eb37d@crater_reader.dragonflybsd.org>

On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
> > Hi,
> >
> > Google just announced its Summer of Code for 2008:
> >
> > 	http://code.google.com/soc/2008/
> >
> > I think this would be a great opportunity for DragonFly to participate
> > as a mentoring organisation.  We could attract new developers and could
> > get code/work done.  Looking at the SoC results of the other BSDs most
> > of their projects were a success.  Of course, not all, but a reasonable
> > percentage.  See [1] and [2].

We've applied in previous years - Jeff Hsu did one year, and I put
together the application last year.  The hardest thing to find was
students (and they are the thing that helps SoC applications a lot, I
think).

Any student volunteers?  We have mentors.


-- 
Robert Luciani
Chalmers University of Technology, SWE
Department of Computer Science and Engineering
http://www.rluciani.com/public.key




From rluciani at gmail.com  Tue Mar  4 10:04:14 2008
From: rluciani at gmail.com (Robert Luciani)
Date: Tue, 04 Mar 2008 19:04:14 +0100
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47cd8f1f$0$856$415eb37d@crater_reader.dragonflybsd.org>

Robert Luciani wrote:
> Justin C. Sherrill wrote:
>> On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
>>> Hi,
>>>
>>> Google just announced its Summer of Code for 2008:
>>>
>>> 	http://code.google.com/soc/2008/
>>>
>>> I think this would be a great opportunity for DragonFly to participate
>>> as a mentoring organisation.  We could attract new developers and could
>>> get code/work done.  Looking at the SoC results of the other BSDs most
>>> of their projects were a success.  Of course, not all, but a reasonable
>>> percentage.  See [1] and [2].
>> We've applied in previous years - Jeff Hsu did one year, and I put
>> together the application last year.  The hardest thing to find was
>> students (and they are the thing that helps SoC applications a lot, I
>> think).
>>
>> Any student volunteers?  We have mentors.
>>
> 
> bingo
> 
My girlfriend Danwei noted that she would also like partake in the SoC.
She's studying IT here at Chalmers and will join the mailing list shortly.
-- 
Robert Luciani
Chalmers University of Technology, SWE
Department of Computer Science and Engineering
http://www.rluciani.com/public.key




From dillon at apollo.backplane.com  Tue Mar  4 13:08:30 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Tue, 4 Mar 2008 13:08:30 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Going to have to roll 1.12.1
Message-ID: <200803042104.m24L43g1065278@apollo.backplane.com>

    Due to a critical bug in sendmail that can cause it to seg-fault I will
    be rolling 1.12.1 as soon as I get verification that the current
    fix deals with it.

						-Matt





From sdavtaker at gmail.com  Tue Mar  4 17:40:43 2008
From: sdavtaker at gmail.com (=?UTF-8?B?U2TDpHZ0YWtlcg==?=)
Date: Tue, 4 Mar 2008 17:40:43 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: [Fwd: Project Support Open Source: $50 donation to support you  project]
In-Reply-To: <2468.192.168.0.242.1204346451.squirrel@www.shiningsilence.com>
Message-ID: <47CDF8D1.9070100@gmail.com>

50 bucks?
Come on...
You can get a meal a lot more expensive than that just going to a free 
HP conference about linux and you only have to rent your soul 3-5 hours ;-)
Sdav

Matthew Dillon escribi?:
:..
:source project's web page.  I'm putting those words in scare quotes
:because I think it's a "payment" for an "advertisement".  The supplied
:link has nothing to do with DragonFly, to say the least.
:
:I don't think this is a good idea, obviously, and replied to that effect. 
:However, I wanted to put this on a DragonFly list, in part to show this
:strange thing, and in part because I'm not comfortable making
:administrative decisions on behalf of the Project without being open as
:possible about it.

    It doesn't really cry out to me either.

						-Matt

  






From sdavtaker at gmail.com  Tue Mar  4 17:56:35 2008
From: sdavtaker at gmail.com (=?UTF-8?B?U2TDpHZ0YWtlcg==?=)
Date: Tue, 4 Mar 2008 17:56:35 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47CDFCCE.1010106@gmail.com>

A cute idea for for GSOC would be to finish the installer.
We were talking about this in my local BUG, we trying to find out how to 
help on that from here.
There is a few missing features in the CD.

   * FDISK, you need to create the slides from another OS before
     install DFBSD, i think port FDisk from FBSD or any *BSD will solve it.
   * Add to the make release a way to add some custom applications to
     the released liveCD (suppose you want to add nmap or ssh or
     something just to use as test disk in some enviroment).
   * Make the installer a little more customizable, and maybe w/ a GUI
     (I like a lot the console approach, but GUI installer will be a
     popularity move, DFBSD w/X makes a Desktop machine work, actually
     im using it that way and really like it).
I think those projects can be done in a SOC by students (like me) with a 
little guide.
Im a lot more interested in things network related and kernel, but i 
dont mind to work on those things, they need to be done some day.
What u think?
Sdav

Robert Luciani escribi?:
Robert Luciani wrote:
  
Justin C. Sherrill wrote:
    
On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
      
Hi,

Google just announced its Summer of Code for 2008:

	http://code.google.com/soc/2008/

I think this would be a great opportunity for DragonFly to participate
as a mentoring organisation.  We could attract new developers and could
get code/work done.  Looking at the SoC results of the other BSDs most
of their projects were a success.  Of course, not all, but a reasonable
percentage.  See [1] and [2].
        
We've applied in previous years - Jeff Hsu did one year, and I put
together the application last year.  The hardest thing to find was
students (and they are the thing that helps SoC applications a lot, I
think).
Any student volunteers?  We have mentors.

      
bingo

    
My girlfriend Danwei noted that she would also like partake in the SoC.
She's studying IT here at Chalmers and will join the mailing list shortly.
  






From c.turner at 199technologies.org  Tue Mar  4 18:30:53 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Tue, 4 Mar 2008 18:30:53 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47CE04C9.1010902@199technologies.org>

Justin C. Sherrill wrote:
together the application last year.  The hardest thing to find was
students (and they are the thing that helps SoC applications a lot, I
think).
umm.. if google wants to send me back to school, I'll sign up - hows 
that for a fair trade :?






From wbh at conducive.org  Tue Mar  4 23:52:13 2008
From: wbh at conducive.org (Bill Hacker)
Date: Wed, 05 Mar 2008 07:52:13 +0000
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47ce512e$0$855$415eb37d@crater_reader.dragonflybsd.org>

Sd?vtaker wrote:
A cute idea for for GSOC would be to finish the installer.
We were talking about this in my local BUG, we trying to find out how to 
help on that from here.
There is a few missing features in the CD.

   * FDISK, you need to create the slides from another OS before
     install DFBSD, i think port FDisk from FBSD or any *BSD will solve it.
I'd rather see that 'reversed' - i.e. - build a more capable fdisk in 
DFLY with hope that it might be seen worth importing into Free/Net/Open, 
or *at least* be able to do a more flexible job than those now do.

And disklabels as well. Hand in glove.

Here's why:

- At the moment, working with Free, Open, DFLY, and OpenSolaris on the 
same HDD requires a bit of acrobatics.

- There seems to now be greater divergence between/among the *BSD's as 
to being able to read each other's disklabels, mount and use each 
other's 'flavor' of FFS/UFS (not to mention Apple's implementation of 
UFS) than there is among the vast multitude of Linux ext2/3 denizens.

Even to the point where use of a *Linux* fs is the more universal way 
for being able to share mounts among the *BSD's. Think detached drives. 
And no - FAT is not all that practical for several reasons.

- DFLY currently has the most fine-grain ability to create slices and 
partitions. But the others cannot all (any?) read those.

'progress' w/r any of the *BSD's direction as to changes, improvements 
(or not) in their once-common-ancestry fs & disklabels need not be 
sacrificed.

I'm not holding out wish or hope for all players agreeing to return to 
'one sacred way'. Nor 'one new universal fs'. Neither is gonna happen.

But a 'legacy compatible' or least-common-denominator mode would do fine 
- most especially for portable / SAN devices.

So - how about a 'flexible' DFLY fdisk to go along with a 'flexible' 
disklabel that could adapt to whatever it found / was told to create?

JM2CW - but that *might* be a good place to get a cross-*BSD team together.

*snip* (other good stuff)

Bill Hacker




From matthias at dragonflybsd.org  Wed Mar  5 01:02:43 2008
From: matthias at dragonflybsd.org (Matthias Schmidt)
Date: Wed, 5 Mar 2008 01:02:43 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <20080305085747.GJ9833@staatsfeind.org>

Hi,

* Justin C. Sherrill wrote:
> 
> We've applied in previous years - Jeff Hsu did one year, and I put
> together the application last year.  The hardest thing to find was
> students (and they are the thing that helps SoC applications a lot, I
> think).

This is good to know, so we could coordinate that if we have enough
mentors and projects?!?  I put together a small text in the wiki:

http://wiki.dragonflybsd.org/index.cgi/GoogleSoC2008

Feel free to add project or missing stuff.  I'm sure I missed a lot of
things :)

> Any student volunteers?  We have mentors.

According to the discussion we could have some students, who would be a
mentor (besides me)?

Regards

	Matthias





From sdavtaker at gmail.com  Wed Mar  5 06:28:37 2008
From: sdavtaker at gmail.com (=?UTF-8?Q?Sd=C3=A4vtaker?=)
Date: Wed, 5 Mar 2008 06:28:37 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <c37d69f60803050624kd86d3d0w3b44a02d0e5a5391@mail.gmail.com>

<quote>
Write a driver (from scratch) for Intel 3945 wireless device
Mentor: Sepherosa Ziehau
</quote>

Yes yes yes, i want to :-)
Someone else planning to mentor in drivers coding?
Sdav

On Wed, Mar 5, 2008 at 5:57 AM, Matthias Schmidt
<matthias at dragonflybsd.org> wrote:
> Hi,
>
>
>  * Justin C. Sherrill wrote:
>  >
>  > We've applied in previous years - Jeff Hsu did one year, and I put
>  > together the application last year.  The hardest thing to find was
>  > students (and they are the thing that helps SoC applications a lot, I
>  > think).
>
>  This is good to know, so we could coordinate that if we have enough
>  mentors and projects?!?  I put together a small text in the wiki:
>
>  http://wiki.dragonflybsd.org/index.cgi/GoogleSoC2008
>
>  Feel free to add project or missing stuff.  I'm sure I missed a lot of
>  things :)
>
>
>  > Any student volunteers?  We have mentors.
>
>  According to the discussion we could have some students, who would be a
>  mentor (besides me)?
>
>  Regards
>
>         Matthias
>
>



-- 
Sd?vtaker prays to Rikku goddess for a good treasure.



From rluciani at gmail.com  Wed Mar  5 10:56:42 2008
From: rluciani at gmail.com (Robert Luciani)
Date: Wed, 05 Mar 2008 19:56:42 +0100
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <47ceecea$0$847$415eb37d@crater_reader.dragonflybsd.org>

Sd?vtaker wrote:
> <quote>
> Write a driver (from scratch) for Intel 3945 wireless device
> Mentor: Sepherosa Ziehau
> </quote>
> 
> Yes yes yes, i want to :-)
> Someone else planning to mentor in drivers coding?
> Sdav
> 
> On Wed, Mar 5, 2008 at 5:57 AM, Matthias Schmidt
> <matthias at dragonflybsd.org> wrote:
>> Hi,
>>
>>
>>  * Justin C. Sherrill wrote:
>>  >
>>  > We've applied in previous years - Jeff Hsu did one year, and I put
>>  > together the application last year.  The hardest thing to find was
>>  > students (and they are the thing that helps SoC applications a lot, I
>>  > think).
>>
>>  This is good to know, so we could coordinate that if we have enough
>>  mentors and projects?!?  I put together a small text in the wiki:
>>
>>  http://wiki.dragonflybsd.org/index.cgi/GoogleSoC2008
>>
>>  Feel free to add project or missing stuff.  I'm sure I missed a lot of
>>  things :)
>>
>>
>>  > Any student volunteers?  We have mentors.
>>
>>  According to the discussion we could have some students, who would be a
>>  mentor (besides me)?
>>
>>  Regards
>>
>>         Matthias
>>
>>
> 
> 
>

IF someone starts to write a 3945 Intel driver,
please keep the newer 4965 in mind too.

-- 
Robert Luciani
Chalmers University of Technology, SWE
Department of Computer Science and Engineering
http://www.rluciani.com/public.key




From joerg at britannica.bec.de  Wed Mar  5 12:01:05 2008
From: joerg at britannica.bec.de (Joerg Sonnenberger)
Date: Wed, 5 Mar 2008 12:01:05 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <20080305195711.GA9981@britannica.bec.de>

On Wed, Mar 05, 2008 at 07:56:42PM +0100, Robert Luciani wrote:
> IF someone starts to write a 3945 Intel driver,
> please keep the newer 4965 in mind too.

NetBSD's wpi works quite well. The hardware is quite different from
4945.

Joerg




From sepherosa at gmail.com  Wed Mar  5 17:48:50 2008
From: sepherosa at gmail.com (Sepherosa Ziehau)
Date: Wed, 5 Mar 2008 17:48:50 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <ea7b9c170803051744u22b09484ofc994f034f11df3b@mail.gmail.com>

On Thu, Mar 6, 2008 at 2:56 AM, Robert Luciani <rluciani at gmail.com> wrote:
>  IF someone starts to write a 3945 Intel driver,

"IF" you know that trying to fix any wired bugs in certain drivers
(e.g. ipw, ral) will require you to read through all of the vendor's
linux code (yes, even including register values and position), i.e.
there is not much difference between writing one from scratch and
porting+fixing_bugs, then you probably will not put "IF" at the start
of your sentence.
If what I said sounded too harsh to you, then I was sorry.

>  please keep the newer 4965 in mind too.

Will do, once generic 11n support is brought in from freebsd.

Best Regards,
sephe

-- 
Live Free or Die




From saw at online.de  Thu Mar  6 05:34:14 2008
From: saw at online.de (Sascha Wildner)
Date: Thu, 06 Mar 2008 14:34:14 +0100
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
Message-ID: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>

Hi all,

this is probably as good a moment as any to come out of the forest with 
this. The patch at

http://leaf.dragonflybsd.org/~swildner/nrelease_gui.diff

adds some code to nrelease/ to build a LiveCD with xorg and so on 
(currently, only the xorg metapackages and fluxbox are added). In order 
to build one, you need a local dir with the pkgsrc binary packages (see 
below).

The following commands should then do the trick:

cd /usr/src
make buildworld
make buildkernel
cd nrelease
patch -p 0 </path/to/the/patch
make PKGSRC_PKG_PATH=/path/to/packages/dir/All realquick gui
The resulting ISO will be in /usr/release/dfly-gui.iso then. It will not 
boot into xorg automatically (although this is easily possible), so you 
need to login as root and do startx.

As of now, this all is kind of basic, more a proof of concept than 
anything else. As our release framework installs packages via chroot, 
the current setup just copies _all_ packages to the chroot before 
installing (kind of a hack).

That said, I'm now primarily interested in opinions/ideas/... about the 
direction this should take. Which packages would we like to see on the 
CD? Should it be a generic setup with the "most common things" 
installed, so a system can be quickly setup by the installer (which will 
cpdup /usr/pkg). Or should it be a more specialized set of tools? Or 
even as many packages as possible (Live DVD?). Etc., etc.

Before continuing on it, I'm really interested in people's input so 
don't hold anything back, please. :)

Sascha

--
http://yoyodyne.ath.cx



From rluciani at gmail.com  Thu Mar  6 06:42:03 2008
From: rluciani at gmail.com (Robert Luciani)
Date: Thu, 06 Mar 2008 15:42:03 +0100
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <47d002bc$0$847$415eb37d@crater_reader.dragonflybsd.org>

Sascha Wildner wrote:
> Hi all,
> 
> this is probably as good a moment as any to come out of the forest with
> this. The patch at
> 
> http://leaf.dragonflybsd.org/~swildner/nrelease_gui.diff
> 
> adds some code to nrelease/ to build a LiveCD with xorg and so on
> (currently, only the xorg metapackages and fluxbox are added). In order
> to build one, you need a local dir with the pkgsrc binary packages (see
> below).
> 
> The following commands should then do the trick:
> 
> cd /usr/src
> make buildworld
> make buildkernel
> cd nrelease
> patch -p 0 </path/to/the/patch
> make PKGSRC_PKG_PATH=/path/to/packages/dir/All realquick gui
> 
> The resulting ISO will be in /usr/release/dfly-gui.iso then. It will not
> boot into xorg automatically (although this is easily possible), so you
> need to login as root and do startx.
> 
> As of now, this all is kind of basic, more a proof of concept than
> anything else. As our release framework installs packages via chroot,
> the current setup just copies _all_ packages to the chroot before
> installing (kind of a hack).
> 
> That said, I'm now primarily interested in opinions/ideas/... about the
> direction this should take. Which packages would we like to see on the
> CD? Should it be a generic setup with the "most common things"
> installed, so a system can be quickly setup by the installer (which will
> cpdup /usr/pkg). Or should it be a more specialized set of tools? Or
> even as many packages as possible (Live DVD?). Etc., etc.
> 
> Before continuing on it, I'm really interested in people's input so
> don't hold anything back, please. :)
> 
> Sascha
> 

I think the main point of such a live-cd would be to test
dragonfly-specific features such as vkernels and more. Mplayer and
OpenOffic work the same on all platforms, so they might not be super
important, while irssi, firefox, networking tools, vim, a few more
shells/terminals might make it easier to for people to quickly gauge if
they can reproduce their current productivity and also what is new.

And if the point of a livecd is to test that kind of stuff, then it
would be nice for it to have a kernel that supports as much as possible
like ALTQ, and drivers.

Also if it has lots and lots of programs (thinking multimedia, java,
etc..) it might be hard to keep the future x64 and x86 live-cds on par.
Gentoo had this problem many years ago and it was very bothersome.

-- 
Robert Luciani
Chalmers University of Technology, SWE
Department of Computer Science and Engineering
http://www.rluciani.com/public.key




From matthias at dragonflybsd.org  Thu Mar  6 07:12:43 2008
From: matthias at dragonflybsd.org (Matthias Schmidt)
Date: Thu, 6 Mar 2008 07:12:43 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <20080306150757.GN9833@staatsfeind.org>

* Sascha Wildner wrote:
> Hi all,
> 
> this is probably as good a moment as any to come out of the forest with this. 
> The patch at
> 
> http://leaf.dragonflybsd.org/~swildner/nrelease_gui.diff
> 
> adds some code to nrelease/ to build a LiveCD with xorg and so on (currently, 
> only the xorg metapackages and fluxbox are added). In order to build one, you 
> need a local dir with the pkgsrc binary packages (see below).

Great work Sascha.

I agree with Robert on most of his stated points.
It would be nice to see some DragonFly specific features on the CD
(although I'm not sure if that will work for all features).  A little
environment where most Unix users feel at home (fluxbox, xfce, firefox,
thunderbird, gvim) should be enough.

Big applications like OO.org, java etc won't work because they are not
available as pkgsrc packages neither is it possible to compile them on
DragonFly.  At least to my knowledge.

Regards

	Matthias




From dillon at apollo.backplane.com  Thu Mar  6 09:31:52 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Thu, 6 Mar 2008 09:31:52 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <200803061728.m26HSR3O091809@apollo.backplane.com>


:Hi all,
:
:this is probably as good a moment as any to come out of the forest with 
:this. The patch at
:
:http://leaf.dragonflybsd.org/~swildner/nrelease_gui.diff
:
:adds some code to nrelease/ to build a LiveCD with xorg and so on 
:(currently, only the xorg metapackages and fluxbox are added). In order 
:to build one, you need a local dir with the pkgsrc binary packages (see 
:below).
:
:The following commands should then do the trick:

    It looks reasonable, though the package copy has to be tightened
    up a bit I think.

:...
:installed, so a system can be quickly setup by the installer (which will 
:cpdup /usr/pkg). Or should it be a more specialized set of tools? Or 
:even as many packages as possible (Live DVD?). Etc., etc.
:
:Before continuing on it, I'm really interested in people's input so 
:don't hold anything back, please. :)
:
:Sascha

    I think this is an excellent time to work up a DVD build and to
    add various 'flavor' extras.  So, e.g.:

	make installer gui gui_extras release dvd

    (All 'dvd' would do is generate a dvd compatible image for burning to
    dvd instead of cd).  I did a quick perusal of what I have on my
    workstation:

    * X
    * Firefox
    * Linux emulation
    * Open Office (linux version)
    * fvwm2
    * xpdf
    * freetype2

    I'd also suggest some image editing tools like gimp, and maybe the KDE
    gui suite.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From justin at shiningsilence.com  Thu Mar  6 09:42:44 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Thu, 6 Mar 2008 09:42:44 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <55427.65.106.147.226.1204825168.squirrel@www.shiningsilence.com>

On Thu, March 6, 2008 8:34 am, Sascha Wildner wrote:

> That said, I'm now primarily interested in opinions/ideas/... about the
> direction this should take. Which packages would we like to see on the
> CD? Should it be a generic setup with the "most common things"
> installed, so a system can be quickly setup by the installer (which will
> cpdup /usr/pkg). Or should it be a more specialized set of tools? Or
> even as many packages as possible (Live DVD?). Etc., etc.

What Robert said is good - whatever's needed to enable DragonFly-specific
features.  Along with that would be some sort of documentation (a README? 
A HTML file on whatever desktop we provide) that points people at the
different DragonFly tools, so they know what to try and how to try it.

There's going to be some percentage of people who try DragonFly who don't
know about vkernels, for instance, but there's our chance to educate them.
 I'm probably volunteering myself, aren't I?





From sdavtaker at gmail.com  Thu Mar  6 09:50:09 2008
From: sdavtaker at gmail.com (=?UTF-8?Q?Sd=C3=A4vtaker?=)
Date: Thu, 6 Mar 2008 09:50:09 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <c37d69f60803060947t110750c0sd6b542ea505d188d@mail.gmail.com>

Cool Sascha :-)
I just posted about this 1 or 2 days ago in the SOC project ideas thread.
Want to mentor this one? ;-)
Damian

On Thu, Mar 6, 2008 at 2:28 PM, Matthew Dillon
<dillon at apollo.backplane.com> wrote:
>
>  :Hi all,
>
> :
>  :this is probably as good a moment as any to come out of the forest with
>  :this. The patch at
>  :
>  :http://leaf.dragonflybsd.org/~swildner/nrelease_gui.diff
>  :
>  :adds some code to nrelease/ to build a LiveCD with xorg and so on
>  :(currently, only the xorg metapackages and fluxbox are added). In order
>  :to build one, you need a local dir with the pkgsrc binary packages (see
>  :below).
>  :
>  :The following commands should then do the trick:
>
>     It looks reasonable, though the package copy has to be tightened
>     up a bit I think.
>
>  :...
>  :installed, so a system can be quickly setup by the installer (which will
>
> :cpdup /usr/pkg). Or should it be a more specialized set of tools? Or
>  :even as many packages as possible (Live DVD?). Etc., etc.
>  :
>  :Before continuing on it, I'm really interested in people's input so
>  :don't hold anything back, please. :)
>  :
>  :Sascha
>
>     I think this is an excellent time to work up a DVD build and to
>     add various 'flavor' extras.  So, e.g.:
>
>         make installer gui gui_extras release dvd
>
>     (All 'dvd' would do is generate a dvd compatible image for burning to
>     dvd instead of cd).  I did a quick perusal of what I have on my
>     workstation:
>
>     * X
>     * Firefox
>     * Linux emulation
>     * Open Office (linux version)
>     * fvwm2
>     * xpdf
>     * freetype2
>
>     I'd also suggest some image editing tools like gimp, and maybe the KDE
>     gui suite.
>
>                                         -Matt
>                                         Matthew Dillon
>                                         <dillon at backplane.com>
>



-- 
Sd?vtaker prays to Rikku goddess for a good treasure.



From saw at online.de  Thu Mar  6 11:54:01 2008
From: saw at online.de (Sascha Wildner)
Date: Thu, 06 Mar 2008 20:54:01 +0100
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <47d04ba2$0$856$415eb37d@crater_reader.dragonflybsd.org>

Matthew Dillon wrote:
    It looks reasonable, though the package copy has to be tightened
    up a bit I think.
It looks as if it would work with mount_null'ing the chroot's 
/tmp/packages. I'll have a better patch ready tomorrow.

Sascha

--
http://yoyodyne.ath.cx



From c.turner at 199technologies.org  Thu Mar  6 19:11:44 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Thu, 6 Mar 2008 19:11:44 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Misc. ACPI / suspend
In-Reply-To: <47CA073B.6020106@199technologies.org>
Message-ID: <47D0B079.3060905@199technologies.org>

Chris Turner wrote:
Wondering if anyone more well versed in the ACPI implementation could
comment on the applicability of:
http://lkml.org/lkml/2007/4/6/69

Doing a little digging, it seems like

. /platform/pc32/i386/i686_mem.c

*might* have the necessary infrastructure to remap the MTRR's per the 
thread referenced,

but:

. /platform/pc32/acpica5/acpi_wakeup.c

doesn't seem to be using this infrastructure..

I'm no where near reaching an understanding of this yet,
but I'm wondering 3 things:
1) does anyone have ACPI (instead of APM)
   sleep / suspend / wakeup working on Dfly ?
2) If so, what machines are being used ?
3) Same question for other BSDs - my understanding is NetBSD is most
   'advanced' w/r/t power managment - but I'm not 100% on this ...
would looove to have a sleeping / resuming / scaling laptop running some 
BSD flavor.. am willing to work towards that end, esp. w/r/t Dfly -
trying to chart a course to figguring this out.

Thanks all,

- Chris




From c.turner at 199technologies.org  Thu Mar  6 19:12:33 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Thu, 6 Mar 2008 19:12:33 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: PCI Bios / Interrupt remapping / etc
Message-ID: <47D0B211.6000002@199technologies.org>

Doing a bit of digging here for my long-standing CBB+SIO interupt and 
buffer problem -

one machine I've tested against was an OpenBSD machine, which didn't
always work to handle the cardbus sio card on a PCI cardbus adapter
-

tuning up some of the device flags in:

http://www.openbsd.org/cgi-bin/man.cgi?query=pcibios&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=html

seems to have alleviated the problem for that os..

I'm just only starting to get up to speed on how DF handles these types 
of things (namely initial PIC / interrupt layout at boot time device 
enumeration), but am wondering if anyone familiar with this area of the 
code has any comments / advice w/r/t the capabilities of the DF bios 
drivers
and the various quirks / fixup mentioned in the link above..

looking to possibly investigate fixing up some of these issues over time.

Thanks

- Chris







From pavalos at theshell.com  Fri Mar  7 01:14:55 2008
From: pavalos at theshell.com (Peter Avalos)
Date: Fri, 7 Mar 2008 01:14:55 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: cam locking
Message-ID: <20080307091024.GC1652@ylem.theshell.com>

So I've been working on locking up cam using lockmgr locks, and here's
what I have so far:

http://www.theshell.com/~pavalos/wip/cam-lock.patch

Most of the work is obtained from FreeBSD.  I've only been running this
on my SCSI machine for a day, but because the patch is so large, I wanted
to make it available for people to review if they have some spare time.

Thanks,
Peter
Attachment:
pgp00002.pgp
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00002.pgp
Type: application/octet-stream
Size: 197 bytes
Desc: "Description: PGP signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080307/9a17ecd8/attachment-0020.obj>

From jspringe at uos.de  Fri Mar  7 03:25:17 2008
From: jspringe at uos.de (Jost Tobias Springenberg)
Date: Fri, 7 Mar 2008 12:25:17 +0100
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <20080307122517.72c9e2b1.jspringe@uos.de>

On Tue, 4 Mar 2008 11:28:15 -0500 (EST)
"Justin C. Sherrill" <justin at shiningsilence.com> wrote:

> On Tue, March 4, 2008 5:23 am, Matthias Schmidt wrote:
> > Hi,
> >
> > Google just announced its Summer of Code for 2008:
> >
> > 	http://code.google.com/soc/2008/
> >
> > I think this would be a great opportunity for DragonFly to participate
> > as a mentoring organisation.  We could attract new developers and could
> > get code/work done.  Looking at the SoC results of the other BSDs most
> > of their projects were a success.  Of course, not all, but a reasonable
> > percentage.  See [1] and [2].
> 
> We've applied in previous years - Jeff Hsu did one year, and I put
> together the application last year.  The hardest thing to find was
> students (and they are the thing that helps SoC applications a lot, I
> think).
> 
> Any student volunteers?  We have mentors.
> 

I read this mailing list for quite a while now and thought about contributing stuff
to DFfly several times, so yes why not take this opportunity if it's there.

-- 
Jost Tobias Springenberg <jspringe at uos.de>




From tgen at netphreax.net  Fri Mar  7 05:17:27 2008
From: tgen at netphreax.net (Thomas E. Spanjaard)
Date: Fri, 7 Mar 2008 05:17:27 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: PCI Bios / Interrupt remapping / etc
In-Reply-To: <47D0B211.6000002@199technologies.org>
Message-ID: <47D13FB4.5080306@netphreax.net>

Chris Turner wrote:
Doing a bit of digging here for my long-standing CBB+SIO interupt and 
buffer problem -

one machine I've tested against was an OpenBSD machine, which didn't
always work to handle the cardbus sio card on a PCI cardbus adapter
-

tuning up some of the device flags in:

http://www.openbsd.org/cgi-bin/man.cgi?query=pcibios&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=html 

seems to have alleviated the problem for that os..

I'm just only starting to get up to speed on how DF handles these types 
of things (namely initial PIC / interrupt layout at boot time device 
enumeration), but am wondering if anyone familiar with this area of the 
code has any comments / advice w/r/t the capabilities of the DF bios 
drivers
and the various quirks / fixup mentioned in the link above..

looking to possibly investigate fixing up some of these issues over time.
Our code that handles issues like this (in cases where you're not using 
APICs, just PICs and PIRs) lives in bus/pci/i386/. Not that running 
without APIC support is all that common on modern machines anymore...
--
        Thomas E. Spanjaard
        tgen at netphreax.net
Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00003.pgp
Type: application/octet-stream
Size: 186 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080307/61366b5c/attachment-0020.obj>

From tgen at netphreax.net  Fri Mar  7 05:16:51 2008
From: tgen at netphreax.net (Thomas E. Spanjaard)
Date: Fri, 7 Mar 2008 05:16:51 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Misc. ACPI / suspend
In-Reply-To: <47CA073B.6020106@199technologies.org>
Message-ID: <47D13F07.9080308@netphreax.net>

Chris Turner wrote:
1) does anyone have ACPI (instead of APM)
   sleep / suspend / wakeup working on Dfly ?
2) If so, what machines are being used ?
3) Same question for other BSDs - my understanding is NetBSD is most
   'advanced' w/r/t power managment - but I'm not 100% on this ...
would looove to have a sleeping / resuming / scaling laptop running some 
BSD flavor.. am willing to work towards that end, esp. w/r/t Dfly -
trying to chart a course to figguring this out.
I have ACPI S3 suspend working like a charm on my IBM ThinkPad R40 
(Pentium M "Banias" 1.3GHz, speedstepping works just fine), running 
NetBSD 3.99.21.
--
        Thomas E. Spanjaard
        tgen at netphreax.net
Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00004.pgp
Type: application/octet-stream
Size: 186 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080307/de3e5104/attachment-0020.obj>

From civilizd at gmail.com  Fri Mar  7 09:06:41 2008
From: civilizd at gmail.com (Vita "CiV" Cizek)
Date: Fri, 7 Mar 2008 09:06:41 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google Sommer of Code 2008
In-Reply-To: <20080304102335.GI9833@staatsfeind.org>
Message-ID: <98d564710803070853q1c73d795m6e6c5cc5049fa099@mail.gmail.com>

>  Any student volunteers?  We have mentors.
>
I am interested too, especially in some kernel-related work.




From justin at shiningsilence.com  Sat Mar  8 12:07:51 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Sat, 8 Mar 2008 12:07:51 -0800 (PST)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Google SoC 2008 - mentors mentors mentors
Message-ID: <51558.192.168.0.252.1205006403.squirrel@www.shiningsilence.com>

If you are willing to mentor for the Google 2008 Summer of Code, please
speak up.  Right now we have: (from our wiki page)

Matthias
Sephe
TGEN
corecode

Part of the application process includes naming people as mentors (student
applications come later), so I want to get as complete a list as possible.

The application is due on the 12th, so if you want to mentor, now's the
time to say so.

Google's SoC FAQ is here: http://code.google.com/soc/2008/faqs.html

Our wiki page is here: http://wiki.dragonflybsd.org/index.cgi/GoogleSoC2008

- much credit to Matthias and others for getting that set up.





From saw at online.de  Sat Mar  8 14:26:07 2008
From: saw at online.de (Sascha Wildner)
Date: Sat, 08 Mar 2008 23:26:07 +0100
Subject: Pre-Alpha patch for a LiveCD with GUI... What next?
In-Reply-To: <47cff2a0$0$855$415eb37d@crater_reader.dragonflybsd.org>
Message-ID: <47d31245$0$848$415eb37d@crater_reader.dragonflybsd.org>

Sascha Wildner wrote:
Hi all,

this is probably as good a moment as any to come out of the forest with 
this. The patch at

http://leaf.dragonflybsd.org/~swildner/nrelease_gui.diff
Ok, I have committed the stuff as an example.

I'm not sure if my free time permits to work on a full-blown live CD 
with X11 and other good things (I already feel my interest wandering off 
in other directions) so if anyone wants to pick up the ball, go ahead. :)

Sascha

--
http://yoyodyne.ath.cx



From qhwt+dfly at les.ath.cx  Tue Mar 11 22:21:31 2008
From: qhwt+dfly at les.ath.cx (YONETANI Tomokazu)
Date: Tue, 11 Mar 2008 22:21:31 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Misc. ACPI / suspend
In-Reply-To: <47CA073B.6020106@199technologies.org>
Message-ID: <20080312051219.GA56091@les.ath.cx>

On Thu, Mar 06, 2008 at 10:03:21PM -0500, Chris Turner wrote:
> 1) does anyone have ACPI (instead of APM)
>    sleep / suspend / wakeup working on Dfly ?
> 2) If so, what machines are being used ?

Dynabook SS3500 (http://www.tlt.co.jp/pc/catalog/ss/02110735/index_j.htm).
It's old and can get very hot(thus frequently turns on the cooling fan)
even when it's running Windows.  I haven't turned it on for about several
months though.

Cheers.




From c.turner at 199technologies.org  Wed Mar 12 04:37:22 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Wed, 12 Mar 2008 04:37:22 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Misc. ACPI / suspend
In-Reply-To: <47CA073B.6020106@199technologies.org>
Message-ID: <47D7BEE3.6010907@199technologies.org>

YONETANI Tomokazu wrote:
On Thu, Mar 06, 2008 at 10:03:21PM -0500, Chris Turner wrote:
1) does anyone have ACPI (instead of APM)
   sleep / suspend / wakeup working on Dfly ?
Cheers.
ditto..

Suppose this should go to docs@ - in any case..

Thinking about setting up a wiki page on the issue so we
can discuss / track what 'good' hardware / drivers / implementations / 
etc are 'out there' - anyone have any suggestions on where this should
go?

http://wiki.dragonflybsd.org/index.cgi/acpi-overview.html

Remains from the handbook conversion - but I'm hesitant to 'over wikify'
this ..



From c.turner at 199technologies.org  Wed Mar 12 15:36:52 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Wed, 12 Mar 2008 15:36:52 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: devel/cscope
Message-ID: <47D85A08.8040103@199technologies.org>

why oh why did I take so long to try this out !!!

just sharing my eureka moment with the list..

- Chris




From dudu at dudu.ro  Wed Mar 12 15:50:14 2008
From: dudu at dudu.ro (Vlad GALU)
Date: Wed, 12 Mar 2008 15:50:14 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: devel/cscope
In-Reply-To: <47D85A08.8040103@199technologies.org>
Message-ID: <ad79ad6b0803121547r2bf67ffep9e40badaac6490f8@mail.gmail.com>

On 3/13/08, Chris Turner <c.turner at 199technologies.org> wrote:
> why oh why did I take so long to try this out !!!
>
>  just sharing my eureka moment with the list..


    Works nice with vim, too!

>
>
>  - Chris
>


-- 
Mahnahmahnah!




From justin at shiningsilence.com  Sun Mar 16 21:06:13 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Sun, 16 Mar 2008 21:06:13 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: binary packages for 1.12 coming in
Message-ID: <1372.192.168.0.252.1205726088.squirrel@www.shiningsilence.com>

The binary build for 1.12 is taking quite a while.  I've started copying
in newly built packages to
pkgbox.dragonflybsd.org/packages/DragonFly-1.12/i386/ - this should be
getting copied out to mirrors over the next while.

There are currently 1283 packages built, which leaves a whole lot to go;
I'll copy new packages in as they complete.





From hasso at estpak.ee  Wed Mar 19 04:31:08 2008
From: hasso at estpak.ee (Hasso Tepper)
Date: Wed, 19 Mar 2008 04:31:08 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Some questions regarding ACPI
Message-ID: <200803191322.46366.hasso@estpak.ee>

I'm working on bringing in some laptop (and especially thinkpad) specific 
ACPI code from FreeBSD into DragonFly. I never touched ACPI stuff before 
and haven't followed it much either, so I have some questions.

* FreeBSD uses ACPI_SERIAL_* heavily. What's the locking situation in 
  DragonFly and why?

* As far as I can see, PCI integration is commented out in DragonFly. 
  What's the state of it and why?

* platform/pc32/acpica5/acpi_toshiba.c - why is it there? I don't think 
  that this is something pc32 specific in it and it should work in pc64 
  laptops as well. Any objections to move it into 
  dev/acpica5/acpi_toshiba/ ?

What's the current status of ACPI in general? AFAICS our acpica is quite 
old - what needs to be done to bring in newer one?


-- 
Hasso




From qhwt+dfly at les.ath.cx  Wed Mar 19 09:24:50 2008
From: qhwt+dfly at les.ath.cx (YONETANI Tomokazu)
Date: Wed, 19 Mar 2008 09:24:50 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Some questions regarding ACPI
In-Reply-To: <200803191322.46366.hasso@estpak.ee>
Message-ID: <20080319161703.GA51509@les.ath.cx>

On Wed, Mar 19, 2008 at 01:22:46PM +0200, Hasso Tepper wrote:
> I'm working on bringing in some laptop (and especially thinkpad) specific 
> ACPI code from FreeBSD into DragonFly. I never touched ACPI stuff before 
> and haven't followed it much either, so I have some questions.

So you want to port some of ACPI support drivers, or to do a fresh port
of ACPI driver from FreeBSD?

> * FreeBSD uses ACPI_SERIAL_* heavily. What's the locking situation in 
>   DragonFly and why?

The current ACPI driver in DragonFly is based on that of FreeBSD as of
end of June, 2004, plus some fixes brought in later (and ACPICA part
has been updated twice since then).  That was before they introduced
the MPSAFE changes into ACPI code, and we use critical section
(crit_{enter,exit}) in most places (and lockmgr lock in a few place).

> * As far as I can see, PCI integration is commented out in DragonFly. 
>   What's the state of it and why?

When we replaced the implementation taken from FreeBSD 4.x with that
brought from FreeBSD 5.x, which added the PCI part, many people
experienced problems until they turned off ACPI completely, or add "pci"
to "debug.acpi.disabled" loader variable.  AFAIK the PCI part in the ACPI
driver almost hasn't been adjusted to work with our version of PCI code.

> * platform/pc32/acpica5/acpi_toshiba.c - why is it there? I don't think 
>   that this is something pc32 specific in it and it should work in pc64 
>   laptops as well. Any objections to move it into 
>   dev/acpica5/acpi_toshiba/ ?

In FreeBSD it used to be sitting at i386/acpica/acpi_toshiba.c and was
later moved into acpi_support.  That change hasn't hit our tree (in fact,
we have no acpi support drivers other than that).  It seems that FreeBSD
has them in dev/acpi_support now, and we for some reason have that
directory in our CVS repository (but containing no files in it).

> What's the current status of ACPI in general? AFAICS our acpica is quite 
> old - what needs to be done to bring in newer one?

Actually, it's not very important to keep just ACPICA latest, but
if you bring the ACPI driver from FreeBSD you need to bring ACPICA code
that matches their version, and it IS important.  And it generally requires
you much work to just update ACPICA part anyway because of how they
change things on every release.

Cheers.




From hasso at estpak.ee  Wed Mar 19 12:29:52 2008
From: hasso at estpak.ee (Hasso Tepper)
Date: Wed, 19 Mar 2008 12:29:52 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Some questions regarding ACPI
In-Reply-To: <200803191322.46366.hasso@estpak.ee>
Message-ID: <200803192115.35396.hasso@estpak.ee>

YONETANI Tomokazu wrote:
> On Wed, Mar 19, 2008 at 01:22:46PM +0200, Hasso Tepper wrote:
> > I'm working on bringing in some laptop (and especially thinkpad)
> > specific ACPI code from FreeBSD into DragonFly. I never touched ACPI
> > stuff before and haven't followed it much either, so I have some
> > questions.
>
> So you want to port some of ACPI support drivers, or to do a fresh port
> of ACPI driver from FreeBSD?

I'm only interested in support drivers and the reason is pure practical - 
newer thinkpads handle less and less hotkeys etc in hardware and require 
support form OS. acpi_ibm and acpi_video are examples of such modules 
which would help a lot of these newer thinkpad users.

acpi_ibm is almost ready to commit (renamed to acpi_thinkpad though).

> > * FreeBSD uses ACPI_SERIAL_* heavily. What's the locking situation in
> >   DragonFly and why?
>
> The current ACPI driver in DragonFly is based on that of FreeBSD as of
> end of June, 2004, plus some fixes brought in later (and ACPICA part
> has been updated twice since then).  That was before they introduced
> the MPSAFE changes into ACPI code, and we use critical section
> (crit_{enter,exit}) in most places (and lockmgr lock in a few place).

Mkay. Will look at more closely.

> > * As far as I can see, PCI integration is commented out in DragonFly.
> >   What's the state of it and why?
>
> When we replaced the implementation taken from FreeBSD 4.x with that
> brought from FreeBSD 5.x, which added the PCI part, many people
> experienced problems until they turned off ACPI completely, or add
> "pci" to "debug.acpi.disabled" loader variable.  AFAIK the PCI part in
> the ACPI driver almost hasn't been adjusted to work with our version of
> PCI code.

I'm afraid that it's beyond my skills, but while looking at acpi_video I 
discovered that it's hard to handle correctly without PCI support.

> > * platform/pc32/acpica5/acpi_toshiba.c - why is it there? I don't
> > think that this is something pc32 specific in it and it should work
> > in pc64 laptops as well. Any objections to move it into
> >   dev/acpica5/acpi_toshiba/ ?
>
> In FreeBSD it used to be sitting at i386/acpica/acpi_toshiba.c and was
> later moved into acpi_support.  That change hasn't hit our tree (in
> fact, we have no acpi support drivers other than that).  It seems that
> FreeBSD has them in dev/acpi_support now, and we for some reason have
> that directory in our CVS repository (but containing no files in it).

I don't see it ;). Makes sense though. So, any objections if I move 
acpi_toshiba into sys/dev/acpi_support and add new acpi_thinkpad there as 
well? 

> > What's the current status of ACPI in general? AFAICS our acpica is
> > quite old - what needs to be done to bring in newer one?
>
> Actually, it's not very important to keep just ACPICA latest, but
> if you bring the ACPI driver from FreeBSD you need to bring ACPICA code
> that matches their version, and it IS important.  And it generally
> requires you much work to just update ACPICA part anyway because of how
> they change things on every release.

Someone else has to do it :).

Thanks for info.


-- 
Hasso




From dillon at apollo.backplane.com  Wed Mar 19 14:01:13 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Wed, 19 Mar 2008 14:01:13 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: panic: assertion: hammer_btree_cmp(cursor->left_bound,	&cursor->node->ondisk->elms[0].leaf.base) <= 0 in btree_split_leaf
In-Reply-To: <200802232204.m1NM4cxd046264@apollo.backplane.com>
Message-ID: <200803192054.m2JKsjwn045137@apollo.backplane.com>


:Hi.
:While trying to find a procedure to reliably reproduce the panic
:I reported last time, I caught a different panic (uploaded at
: ~y0netan1/crash/9/ on my leaf account).  I wrote the following shell
:script (make sure to edit variables DISKS and MOUNTPT before using this
:script or it may trash your system):
:  #!/bin/sh -ex
:  DISKS="/dev/ad0s1f"
:  MOUNTPT=/mnt/HAMMER
:
:  cd /
:  newfs_hammer -L TEST $DISKS
:  for i in `seq 1 100`; do
:..
:And the panic is triggered by rm command.
:I'll try to see if it's possible to reproduce the last one without
:unmounting then mounting the HAMMER fs.
:
:Cheers.

    I believe I have fixed this panic.  hammer_make_separator() had a bug
    in it.

    There is still an issue with the node ref count on umount.

    Please continue to life-test the code.  The reblocking code
    (hammer reblock /mnt) should work now, as should the pruning code
    (e.g. hammer prune /mnt everything).

    The filesystem full case is still not handled and will cause bad things
    to happen.  The undo code isn't finished yet either but it is getting
    there (it's writing stuff out but not setting the sequence number and
    not trying to recover-on-mount yet).

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From qhwt+dfly at les.ath.cx  Wed Mar 19 19:45:40 2008
From: qhwt+dfly at les.ath.cx (YONETANI Tomokazu)
Date: Wed, 19 Mar 2008 19:45:40 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Some questions regarding ACPI
In-Reply-To: <200803191322.46366.hasso@estpak.ee>
Message-ID: <20080320023828.GA53648@les.ath.cx>

On Wed, Mar 19, 2008 at 09:15:35PM +0200, Hasso Tepper wrote:
> YONETANI Tomokazu wrote:
> > On Wed, Mar 19, 2008 at 01:22:46PM +0200, Hasso Tepper wrote:
> > > I'm working on bringing in some laptop (and especially thinkpad)
> > > specific ACPI code from FreeBSD into DragonFly. I never touched ACPI
> > > stuff before and haven't followed it much either, so I have some
> > > questions.
> >
> > So you want to port some of ACPI support drivers, or to do a fresh port
> > of ACPI driver from FreeBSD?
> 
> I'm only interested in support drivers and the reason is pure practical - 
> newer thinkpads handle less and less hotkeys etc in hardware and require 
> support form OS. acpi_ibm and acpi_video are examples of such modules 
> which would help a lot of these newer thinkpad users.
> 
> acpi_ibm is almost ready to commit (renamed to acpi_thinkpad though).

Ah, that's a good news!  My only concern is that ISTR someone mentioned
me that his colleague was thinking about porting ACPI driver itself,
so if you're not the person you may want to collaborate with him/her
so as not to waste the effort or time...

			:

> > In FreeBSD it used to be sitting at i386/acpica/acpi_toshiba.c and was
> > later moved into acpi_support.  That change hasn't hit our tree (in
> > fact, we have no acpi support drivers other than that).  It seems that
> > FreeBSD has them in dev/acpi_support now, and we for some reason have
> > that directory in our CVS repository (but containing no files in it).
> 
> I don't see it ;). Makes sense though. So, any objections if I move 
> acpi_toshiba into sys/dev/acpi_support and add new acpi_thinkpad there as 
> well? 

Sorry, I checked the CVS repository and it doesn't exist actually :)
I don't have any objection to moving it there.

Cheers.




From hasso at estpak.ee  Thu Mar 20 00:14:05 2008
From: hasso at estpak.ee (Hasso Tepper)
Date: Thu, 20 Mar 2008 00:14:05 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Some questions regarding ACPI
In-Reply-To: <200803191322.46366.hasso@estpak.ee>
Message-ID: <200803200904.50875.hasso@estpak.ee>

YONETANI Tomokazu wrote:
> On Wed, Mar 19, 2008 at 09:15:35PM +0200, Hasso Tepper wrote:
> > acpi_ibm is almost ready to commit (renamed to acpi_thinkpad though).
>
> Ah, that's a good news!  My only concern is that ISTR someone mentioned
> me that his colleague was thinking about porting ACPI driver itself,
> so if you're not the person you may want to collaborate with him/her
> so as not to waste the effort or time...

Current state in my repo is attached. It should work on 1.12 as well as it 
doesn't depend yet on moving stuff around.

add-acpi-if-m.patch adds some new stuff to the ACPI code to access 
embedded controllers and match ACPI devices by ID. Not sure how, where 
and whether at all these should be documented.

add-acpi-thinkpad.patch is the driver itself. Note that some stuff doesn't 
work yet on newer thinkpads, I plan to work on it later.

There is still some things to do though. I have to decide what to do with 
led(4) part and with locking. There is also one fatal issue - laptop 
locks up hardly (no panic) while unloading module. Any idea regarding 
this is welcome. And of course test results :).


-- 
Hasso
# HG changeset patch
# User Hasso Tepper <hasso at estpak.ee>
# Date 1205919290 -7200
# Branch HEAD
# Node ID 5a6e2705cc95a340abf973ae5df73ef34e070b79
# Parent  cd529e2e7f849034d5d5a0973cb98af50db0e797
imported patch adding-acpi-if-m.patch

diff --git a/sys/conf/files b/sys/conf/files
--- a/sys/conf/files
+++ b/sys/conf/files
@@ -1387,6 +1387,7 @@ emulation/dragonfly12/dfbsd12_stat.c	non
 ${OSACPI_MI_DIR}/acpi_cmbat.c		optional acpi
 ${OSACPI_MI_DIR}/acpi_cpu.c		optional acpi
 ${OSACPI_MI_DIR}/acpi_ec.c		optional acpi
+${OSACPI_MI_DIR}/acpi_if.m		optional acpi
 ${OSACPI_MI_DIR}/acpi_isab.c		optional acpi isa
 ${OSACPI_MI_DIR}/acpi_lid.c		optional acpi
 ${OSACPI_MI_DIR}/acpi_package.c		optional acpi
diff --git a/sys/conf/kmod.mk b/sys/conf/kmod.mk
--- a/sys/conf/kmod.mk
+++ b/sys/conf/kmod.mk
@@ -275,7 +275,7 @@ MFILES?= kern/bus_if.m kern/device_if.m 
     bus/pccard/card_if.m bus/pccard/power_if.m bus/pci/pci_if.m \
     bus/pci/pcib_if.m \
     bus/ppbus/ppbus_if.m bus/smbus/smbus_if.m bus/usb/usb_if.m \
-    dev/disk/nata/ata_if.m \
+    dev/acpica5/acpi_if.m dev/disk/nata/ata_if.m \
     dev/sound/pcm/ac97_if.m dev/sound/pcm/channel_if.m \
     dev/sound/pcm/feeder_if.m dev/sound/pcm/mixer_if.m \
     libiconv/iconv_converter_if.m dev/agp/agp_if.m opencrypto/crypto_if.m
diff --git a/sys/dev/acpica5/Makefile b/sys/dev/acpica5/Makefile
--- a/sys/dev/acpica5/Makefile
+++ b/sys/dev/acpica5/Makefile
@@ -69,12 +69,14 @@ SRCS+=  acpi_package.c
 # SRCS+=	acpi_pci.c acpi_pcib.c acpi_pcib_acpi.c acpi_pcib_pci.c
 # SRCS+=	acpi_pci_link.c
 SRCS+=  acpi_powerres.c acpi_resource.c acpi_thermal.c
-SRCS+=  acpi_timer.c
+SRCS+=  acpi_timer.c acpi_if.c
 SRCS+=  OsdDebug.c
 SRCS+=  OsdHardware.c OsdInterface.c OsdInterrupt.c OsdMemory.c OsdSchedule.c
 SRCS+=  OsdStream.c OsdSynch.c OsdTable.c OsdEnvironment.c
 SRCS+=  opt_acpi.h opt_bus.h opt_ddb.h
-SRCS+=  device_if.h bus_if.h pci_if.h pcib_if.h isa_if.h
+SRCS+=  device_if.h bus_if.h pci_if.h pcib_if.h isa_if.h acpi_if.h
+MFILES = kern/device_if.m kern/bus_if.m bus/pci/pci_if.m bus/pci/pcib_if.m
+MFILES+= bus/isa/isa_if.m dev/acpica5/acpi_if.m
 
 # Debugging support
 DBSRC=	dbcmds.c dbdisply.c dbexec.c dbfileio.c dbhistry.c
diff --git a/sys/dev/acpica5/acpi.c b/sys/dev/acpica5/acpi.c
--- a/sys/dev/acpica5/acpi.c
+++ b/sys/dev/acpica5/acpi.c
@@ -135,6 +135,7 @@ static int	acpi_release_resource(device_
 			int rid, struct resource *r);
 static uint32_t	acpi_isa_get_logicalid(device_t dev);
 static int	acpi_isa_get_compatid(device_t dev, uint32_t *cids, int count);
+static char	*acpi_device_id_probe(device_t bus, device_t dev, char **ids);
 static int	acpi_isa_pnp_probe(device_t bus, device_t child,
 			struct isa_pnp_id *ids);
 static void	acpi_probe_children(device_t bus);
@@ -189,6 +190,9 @@ static device_method_t acpi_methods[] = 
     DEVMETHOD(bus_deactivate_resource,	bus_generic_deactivate_resource),
     DEVMETHOD(bus_setup_intr,		bus_generic_setup_intr),
     DEVMETHOD(bus_teardown_intr,	bus_generic_teardown_intr),
+
+    /* ACPI bus */
+    DEVMETHOD(acpi_id_probe,		acpi_device_id_probe),
 
     /* ISA emulation */
     DEVMETHOD(isa_pnp_probe,		acpi_isa_pnp_probe),
@@ -1121,6 +1125,24 @@ out:
 	AcpiOsFree(buf.Pointer);
     ACPI_UNLOCK;
     return_VALUE (valid);
+}
+
+static char *
+acpi_device_id_probe(device_t bus, device_t dev, char **ids) 
+{
+    ACPI_HANDLE h;
+    int i;
+
+    h = acpi_get_handle(dev);
+    if (ids == NULL || h == NULL || acpi_get_type(dev) != ACPI_TYPE_DEVICE)
+	return (NULL);
+
+    /* Try to match one of the array of IDs with a HID or CID. */
+    for (i = 0; ids[i] != NULL; i++) {
+	if (acpi_MatchHid(h, ids[i]))
+	    return (ids[i]);
+    }
+    return (NULL);
 }
 
 static int
diff --git a/sys/dev/acpica5/acpi_ec.c b/sys/dev/acpica5/acpi_ec.c
--- a/sys/dev/acpica5/acpi_ec.c
+++ b/sys/dev/acpica5/acpi_ec.c
@@ -327,11 +327,19 @@ static ACPI_STATUS	EcWrite(struct acpi_e
 				UINT8 *Data);
 static int		acpi_ec_probe(device_t dev);
 static int		acpi_ec_attach(device_t dev);
+static int		acpi_ec_read_method(device_t dev, u_int addr,
+				ACPI_INTEGER *val, int width);
+static int		acpi_ec_write_method(device_t dev, u_int addr,
+				ACPI_INTEGER val, int width);
 
 static device_method_t acpi_ec_methods[] = {
     /* Device interface */
     DEVMETHOD(device_probe,	acpi_ec_probe),
     DEVMETHOD(device_attach,	acpi_ec_attach),
+
+    /* Embedded controller interface */
+    DEVMETHOD(acpi_ec_read,     acpi_ec_read_method),
+    DEVMETHOD(acpi_ec_write,    acpi_ec_write_method),
 
     {0, 0}
 };
@@ -620,6 +628,33 @@ error:
 			     sc->ec_data_res);
     /* mtx_destroy(&sc->ec_mtx); */
     return (ENXIO);
+}
+
+/* Methods to allow other devices (e.g., smbat) to read/write EC space. */
+static int
+acpi_ec_read_method(device_t dev, u_int addr, ACPI_INTEGER *val, int width)
+{
+    struct acpi_ec_softc *sc;
+    ACPI_STATUS status;
+
+    sc = device_get_softc(dev);
+    status = EcSpaceHandler(ACPI_READ, addr, width * 8, val, sc, NULL);
+    if (ACPI_FAILURE(status))
+        return (ENXIO);
+    return (0);
+}
+
+static int
+acpi_ec_write_method(device_t dev, u_int addr, ACPI_INTEGER val, int width)
+{
+    struct acpi_ec_softc *sc;
+    ACPI_STATUS status;
+
+    sc = device_get_softc(dev);
+    status = EcSpaceHandler(ACPI_WRITE, addr, width * 8, &val, sc, NULL);
+    if (ACPI_FAILURE(status))
+        return (ENXIO);
+    return (0);
 }
 
 static void
diff --git a/sys/dev/acpica5/acpi_if.m b/sys/dev/acpica5/acpi_if.m
new file mode 100644
--- /dev/null
+++ b/sys/dev/acpica5/acpi_if.m
@@ -0,0 +1,92 @@
+#-
+# Copyright (c) 2004 Nate Lawson
+# All rights reserved.
+#
+# Redistribution and use in source and binary forms, with or without
+# modification, are permitted provided that the following conditions
+# are met:
+# 1. Redistributions of source code must retain the above copyright
+#    notice, this list of conditions and the following disclaimer.
+# 2. Redistributions in binary form must reproduce the above copyright
+#    notice, this list of conditions and the following disclaimer in the
+#    documentation and/or other materials provided with the distribution.
+#
+# THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
+# ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+# ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
+# FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+# DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+# OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+# HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+# LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+# OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+# SUCH DAMAGE.
+#
+# $DragonFly$
+#
+
+#include <sys/bus.h>
+#include <sys/types.h>
+#include "acpi.h"
+
+INTERFACE acpi;
+
+#
+# Default implementation for acpi_id_probe().
+#
+CODE {
+	static char *
+	acpi_generic_id_probe(device_t bus, device_t dev, char **ids)
+	{
+		return (NULL);
+	}
+};
+
+#
+# Check a device for a match in a list of ID strings.  The strings can be
+# EISA PNP IDs or ACPI _HID/_CID values.
+#
+# device_t bus:  parent bus for the device
+#
+# device_t dev:  device being considered
+#
+# char **ids:  array of ID strings to consider
+#
+# Returns:  ID string matched or NULL if no match
+#
+METHOD char * id_probe {
+	device_t	bus;
+	device_t	dev;
+	char		**ids;
+} DEFAULT acpi_generic_id_probe;
+
+#
+# Read embedded controller (EC) address space
+#
+# device_t dev:  EC device
+# u_int addr:  Address to read from in EC space
+# ACPI_INTEGER *val:  Location to store read value
+# int width:  Size of area to read in bytes
+#
+METHOD int ec_read {
+	device_t	dev;
+	u_int		addr;
+	ACPI_INTEGER	*val;
+	int		width;
+};
+
+#
+# Write embedded controller (EC) address space
+#
+# device_t dev:  EC device
+# u_int addr:  Address to write to in EC space
+# ACPI_INTEGER val:  Value to write
+# int width:  Size of value to write in bytes
+#
+METHOD int ec_write {
+	device_t	dev;
+	u_int		addr;
+	ACPI_INTEGER	val;
+	int		width;
+};
diff --git a/sys/dev/acpica5/acpivar.h b/sys/dev/acpica5/acpivar.h
--- a/sys/dev/acpica5/acpivar.h
+++ b/sys/dev/acpica5/acpivar.h
@@ -29,6 +29,7 @@
  * $DragonFly: src/sys/dev/acpica5/acpivar.h,v 1.12 2007/10/23 03:04:48 y0netan1 Exp $
  */
 
+#include "acpi_if.h"
 #include "bus_if.h"
 #include <sys/eventhandler.h>
 #include <sys/sysctl.h>
# HG changeset patch
# User Hasso Tepper <hasso at estpak.ee>
# Date 1205995474 -7200
# Branch HEAD
# Node ID c5db8d4a7c6b25a8576a8d42c5029aaf0e23bfb6
# Parent  5a6e2705cc95a340abf973ae5df73ef34e070b79
[mq]: adding-acpi-thinkpad.patch

diff --git a/sys/dev/acpica5/Makefile b/sys/dev/acpica5/Makefile
--- a/sys/dev/acpica5/Makefile
+++ b/sys/dev/acpica5/Makefile
@@ -117,7 +117,7 @@ acpi_wakecode.h: acpi_wakecode.S
 	${MAKE} -f ${SYSDIR}/${OSACPI_MD_DIR}/Makefile \
 		MAKESRCPATH=${SYSDIR}/${OSACPI_MD_DIR}
 
-SUBDIR=	acpi_toshiba
+SUBDIR=	acpi_toshiba acpi_thinkpad
 all: ${PROG} ${SUBDIR}
 
 # *.o file for each patched *.c file is created under the same directory,
diff --git a/sys/dev/acpica5/acpi_thinkpad/Makefile b/sys/dev/acpica5/acpi_thinkpad/Makefile
new file mode 100644
--- /dev/null
+++ b/sys/dev/acpica5/acpi_thinkpad/Makefile
@@ -0,0 +1,9 @@
+# $DragonFly$
+
+SYSDIR?=${.CURDIR}/../../..
+
+KMOD=		acpi_thinkpad
+CFLAGS+=	-I${.OBJDIR}/.. -I${.CURDIR}/..
+SRCS=		acpi_thinkpad.c opt_acpi.h device_if.h bus_if.h
+
+.include <bsd.kmod.mk>
diff --git a/sys/dev/acpica5/acpi_thinkpad/acpi_thinkpad.c b/sys/dev/acpica5/acpi_thinkpad/acpi_thinkpad.c
new file mode 100644
--- /dev/null
+++ b/sys/dev/acpica5/acpi_thinkpad/acpi_thinkpad.c
@@ -0,0 +1,1046 @@
+/*
+ * Copyright (c) 2004 Takanori Watanabe
+ * Copyright (c) 2005 Markus Brueffer <markus at FreeBSD.org>
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *    notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *    notice, this list of conditions and the following disclaimer in the
+ *    documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+ */
+
+/*
+ * Driver for extra ACPI-controlled gadgets found on IBM and Lenovo ThinkPad
+ * laptops. Inspired by the ibm-acpi and tpb projects which implement these
+ * features on Linux.
+ *
+ *   acpi-ibm: <http://ibm-acpi.sourceforge.net/>
+ *        tpb: <http://www.nongnu.org/tpb/>
+ */
+
+#include "opt_acpi.h"
+#include <sys/param.h>
+#include <sys/kernel.h>
+#include <sys/bus.h>
+#include <machine/cpufunc.h>
+#include <sys/module.h>
+/* #include <dev/led/led.h> */
+#include <sys/sensors.h>
+#include <sys/sysctl.h>
+#include <machine/clock.h>
+
+#include "acpi.h"
+#include "acpivar.h"
+#include "acpi_if.h"
+
+#define _COMPONENT	ACPI_OEM
+ACPI_MODULE_NAME("THINKPAD")
+
+/* Internal methods */
+#define ACPI_THINKPAD_METHOD_EVENTS		1
+#define ACPI_THINKPAD_METHOD_EVENTMASK		2
+#define ACPI_THINKPAD_METHOD_HOTKEY		3
+#define ACPI_THINKPAD_METHOD_BRIGHTNESS		4
+#define ACPI_THINKPAD_METHOD_VOLUME		5
+#define ACPI_THINKPAD_METHOD_MUTE		6
+#define ACPI_THINKPAD_METHOD_THINKLIGHT		7
+#define ACPI_THINKPAD_METHOD_BLUETOOTH		8
+#define ACPI_THINKPAD_METHOD_WLAN		9
+#define ACPI_THINKPAD_METHOD_FANSPEED		10
+#define ACPI_THINKPAD_METHOD_FANLEVEL		11
+#define ACPI_THINKPAD_METHOD_FANSTATUS		12
+#define ACPI_THINKPAD_METHOD_THERMAL		13
+
+/* Hotkeys/Buttons */
+#define THINKPAD_RTC_HOTKEY1			0x64
+#define   THINKPAD_RTC_MASK_HOME		(1 << 0)
+#define   THINKPAD_RTC_MASK_SEARCH		(1 << 1)
+#define   THINKPAD_RTC_MASK_MAIL		(1 << 2)
+#define   THINKPAD_RTC_MASK_WLAN		(1 << 5)
+#define THINKPAD_RTC_HOTKEY2			0x65
+#define   THINKPAD_RTC_MASK_THINKPAD		(1 << 3)
+#define   THINKPAD_RTC_MASK_ZOOM		(1 << 5)
+#define   THINKPAD_RTC_MASK_VIDEO		(1 << 6)
+#define   THINKPAD_RTC_MASK_HIBERNATE		(1 << 7)
+#define THINKPAD_RTC_THINKLIGHT			0x66
+#define   THINKPAD_RTC_MASK_THINKLIGHT		(1 << 4)
+#define THINKPAD_RTC_SCREENEXPAND		0x67
+#define   THINKPAD_RTC_MASK_SCREENEXPAND	(1 << 5)
+#define THINKPAD_RTC_BRIGHTNESS			0x6c
+#define   THINKPAD_RTC_MASK_BRIGHTNESS		(1 << 5)
+#define THINKPAD_RTC_VOLUME			0x6e
+#define   THINKPAD_RTC_MASK_VOLUME		(1 << 7)
+
+/* Embedded Controller registers */
+#define THINKPAD_EC_BRIGHTNESS			0x31
+#define   THINKPAD_EC_MASK_BRI			0x7
+#define THINKPAD_EC_VOLUME			0x30
+#define   THINKPAD_EC_MASK_VOL			0xf
+#define   THINKPAD_EC_MASK_MUTE			(1 << 6)
+#define THINKPAD_EC_FANSTATUS			0x2F
+#define   THINKPAD_EC_MASK_FANLEVEL		0x3f
+#define   THINKPAD_EC_MASK_FANDISENGAGED	(1 << 6)
+#define   THINKPAD_EC_MASK_FANSTATUS		(1 << 7)
+#define THINKPAD_EC_FANSPEED			0x84
+
+/* CMOS Commands */
+#define THINKPAD_CMOS_VOLUME_DOWN		0
+#define THINKPAD_CMOS_VOLUME_UP			1
+#define THINKPAD_CMOS_VOLUME_MUTE		2
+#define THINKPAD_CMOS_BRIGHTNESS_UP		4
+#define THINKPAD_CMOS_BRIGHTNESS_DOWN		5
+
+/* ACPI methods */
+#define THINKPAD_NAME_KEYLIGHT			"KBLT"
+#define THINKPAD_NAME_WLAN_BT_GET		"GBDC"
+#define THINKPAD_NAME_WLAN_BT_SET		"SBDC"
+#define   THINKPAD_NAME_MASK_BT			(1 << 1)
+#define   THINKPAD_NAME_MASK_WLAN		(1 << 2)
+#define THINKPAD_NAME_THERMAL_GET		"TMP7"
+#define THINKPAD_NAME_THERMAL_UPDT		"UPDT"
+
+#define THINKPAD_NAME_EVENTS_STATUS_GET		"DHKC"
+#define THINKPAD_NAME_EVENTS_MASK_GET		"DHKN"
+#define THINKPAD_NAME_EVENTS_STATUS_SET		"MHKC"
+#define THINKPAD_NAME_EVENTS_MASK_SET		"MHKM"
+#define THINKPAD_NAME_EVENTS_GET		"MHKP"
+#define THINKPAD_NAME_EVENTS_AVAILMASK		"MHKA"
+
+#define ABS(x) (((x) < 0)? -(x) : (x))
+
+struct acpi_thinkpad_softc {
+	device_t	dev;
+	ACPI_HANDLE	handle;
+
+	/* Embedded controller */
+	device_t	ec_dev;
+	ACPI_HANDLE	ec_handle;
+
+	/* CMOS */
+	ACPI_HANDLE	cmos_handle;
+
+	/* Fan status */
+	ACPI_HANDLE	fan_handle;
+	int		fan_levels;
+
+	/* Keylight commands and states */
+	ACPI_HANDLE	light_handle;
+	int		light_cmd_on;
+	int		light_cmd_off;
+	int		light_val;
+	int		light_get_supported;
+	int		light_set_supported;
+
+	/* led(4) interface */
+	struct cdev	*led_dev;
+	int		led_busy;
+	int		led_state;
+
+	int		wlan_bt_flags;
+	int		thermal_updt_supported;
+
+	unsigned int	events_availmask;
+	unsigned int	events_initialmask;
+	int		events_mask_supported;
+	int		events_enable;
+
+	/* sensors(9) related */
+	struct ksensordev sensordev;
+	struct ksensor sensors[9];	/* XXX: 8 thermal + fan */
+
+	struct sysctl_ctx_list	*sysctl_ctx;
+	struct sysctl_oid	*sysctl_tree;
+};
+
+static struct {
+	char	*name;
+	int	method;
+	char	*description;
+	int	access;
+} acpi_thinkpad_sysctls[] = {
+	{
+		.name		= "events",
+		.method		= ACPI_THINKPAD_METHOD_EVENTS,
+		.description	= "ACPI events enable",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "eventmask",
+		.method		= ACPI_THINKPAD_METHOD_EVENTMASK,
+		.description	= "ACPI eventmask",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "hotkey",
+		.method		= ACPI_THINKPAD_METHOD_HOTKEY,
+		.description	= "Key Status",
+		.access		= CTLTYPE_INT | CTLFLAG_RD
+	},
+	{
+		.name		= "lcd_brightness",
+		.method		= ACPI_THINKPAD_METHOD_BRIGHTNESS,
+		.description	= "LCD Brightness",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "volume",
+		.method		= ACPI_THINKPAD_METHOD_VOLUME,
+		.description	= "Volume",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "mute",
+		.method		= ACPI_THINKPAD_METHOD_MUTE,
+		.description	= "Mute",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "thinklight",
+		.method		= ACPI_THINKPAD_METHOD_THINKLIGHT,
+		.description	= "Thinklight enable",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "bluetooth",
+		.method		= ACPI_THINKPAD_METHOD_BLUETOOTH,
+		.description	= "Bluetooth enable",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "wlan",
+		.method		= ACPI_THINKPAD_METHOD_WLAN,
+		.description	= "WLAN enable",
+		.access		= CTLTYPE_INT | CTLFLAG_RD
+	},
+	{
+		.name		= "fan_level",
+		.method		= ACPI_THINKPAD_METHOD_FANLEVEL,
+		.description	= "Fan level",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+	{
+		.name		= "fan",
+		.method		= ACPI_THINKPAD_METHOD_FANSTATUS,
+		.description	= "Fan enable",
+		.access		= CTLTYPE_INT | CTLFLAG_RW
+	},
+
+	{ NULL, 0, NULL, 0 }
+};
+
+/* ACPI_SERIAL_DECL(thinkpad, "ACPI THINKPAD extras"); */
+static int	acpi_thinkpad_probe(device_t dev);
+static int	acpi_thinkpad_attach(device_t dev);
+static int	acpi_thinkpad_detach(device_t dev);
+
+#if 0 /* not yet */
+static void	thinkpad_led(void *softc, int onoff);
+static void	thinkpad_led_task(struct acpi_thinkpad_softc *sc,
+		int pending __unused);
+#endif
+
+static int	acpi_thinkpad_sysctl(SYSCTL_HANDLER_ARGS);
+static int	acpi_thinkpad_sysctl_init(struct acpi_thinkpad_softc *sc,
+		int method);
+static int	acpi_thinkpad_sysctl_get(struct acpi_thinkpad_softc *sc,
+		int method);
+static int	acpi_thinkpad_sysctl_set(struct acpi_thinkpad_softc *sc,
+		int method, int val);
+
+static int	acpi_thinkpad_eventmask_set(struct acpi_thinkpad_softc *sc,
+		int val);
+static void	acpi_thinkpad_notify(ACPI_HANDLE h, UINT32 notify,
+		void *context);
+static void	acpi_thinkpad_refresh(void *);
+
+static device_method_t acpi_thinkpad_methods[] = {
+	/* Device interface */
+	DEVMETHOD(device_probe, acpi_thinkpad_probe),
+	DEVMETHOD(device_attach, acpi_thinkpad_attach),
+	DEVMETHOD(device_detach, acpi_thinkpad_detach),
+	{0, 0}
+};
+
+static driver_t	acpi_thinkpad_driver = {
+	"acpi_thinkpad",
+	acpi_thinkpad_methods,
+	sizeof(struct acpi_thinkpad_softc),
+};
+
+static devclass_t acpi_thinkpad_devclass;
+
+DRIVER_MODULE(acpi_thinkpad, acpi, acpi_thinkpad_driver,
+    acpi_thinkpad_devclass, 0, 0);
+MODULE_DEPEND(acpi_thinkpad, acpi, 1, 1, 1);
+static char    *thinkpad_ids[] = {"IBM0068", NULL};
+
+#if 0 /* not yet */
+static void
+thinkpad_led(void *softc, int onoff)
+{
+	struct acpi_thinkpad_softc* sc = (struct acpi_thinkpad_softc*) softc;
+
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+
+	if (sc->led_busy)
+		return;
+
+	sc->led_busy = 1;
+	sc->led_state = onoff;
+
+	AcpiOsExecute(OSL_NOTIFY_HANDLER, (void *)thinkpad_led_task, sc);
+}
+
+static void
+thinkpad_led_task(struct acpi_thinkpad_softc *sc, int pending __unused)
+{
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+
+	/* ACPI_SERIAL_BEGIN(thinkpad); */
+	acpi_thinkpad_sysctl_set(sc, ACPI_THINKPAD_METHOD_THINKLIGHT, sc->led_state);
+	/* ACPI_SERIAL_END(thinkpad); */
+
+	sc->led_busy = 0;
+}
+#endif
+
+static int
+acpi_thinkpad_probe(device_t dev)
+{
+	if (acpi_disabled("thinkpad") ||
+	    ACPI_ID_PROBE(device_get_parent(dev), dev, thinkpad_ids) == NULL ||
+	    device_get_unit(dev) != 0) 
+		return (ENXIO);
+
+	device_set_desc(dev, "IBM/Lenovo ThinkPad ACPI Extras");
+	return (0);
+}
+
+static int
+acpi_thinkpad_attach(device_t dev)
+{
+	struct acpi_thinkpad_softc	*sc;
+	struct acpi_softc	*acpi_sc;
+	devclass_t		ec_devclass;
+	int			i;
+
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t) __func__);
+
+	sc = device_get_softc(dev);
+	sc->dev = dev;
+	sc->handle = acpi_get_handle(dev);
+
+	acpi_sc = acpi_device_get_parent_softc(dev);
+
+	/* Look for the first embedded controller */
+        if (!(ec_devclass = devclass_find ("acpi_ec"))) {
+		if (bootverbose)
+			device_printf(dev, "Couldn't find acpi_ec devclass\n");
+		return (EINVAL);
+	}
+        if (!(sc->ec_dev = devclass_get_device(ec_devclass, 0))) {
+		if (bootverbose)
+			device_printf(dev, "Couldn't find acpi_ec device\n");
+		return (EINVAL);
+	}
+	sc->ec_handle = acpi_get_handle(sc->ec_dev);
+
+	/* ACPI_SERIAL_BEGIN(thinkpad); */
+
+#if 0
+	/* Get the sysctl tree */
+	sc->sysctl_ctx = device_get_sysctl_ctx(dev);
+	sc->sysctl_tree = device_get_sysctl_tree(dev);
+#endif
+	sysctl_ctx_init(sc->sysctl_ctx);
+	sc->sysctl_tree = SYSCTL_ADD_NODE(sc->sysctl_ctx,
+	    SYSCTL_CHILDREN(acpi_sc->acpi_sysctl_tree), OID_AUTO,
+	    "thinkpad", CTLFLAG_RD, 0, "");
+
+	/* Look for event mask and hook up the nodes */
+	sc->events_mask_supported = ACPI_SUCCESS(acpi_GetInteger(sc->handle,
+	    THINKPAD_NAME_EVENTS_MASK_GET, &sc->events_initialmask));
+
+	if (sc->events_mask_supported) {
+		SYSCTL_ADD_INT(sc->sysctl_ctx,
+		    SYSCTL_CHILDREN(sc->sysctl_tree), OID_AUTO,
+		    "initialmask", CTLFLAG_RD,
+		    &sc->events_initialmask, 0, "Initial eventmask");
+
+		/* The availmask is the bitmask of supported events */
+		if (ACPI_FAILURE(acpi_GetInteger(sc->handle,
+		    THINKPAD_NAME_EVENTS_AVAILMASK, &sc->events_availmask)))
+			sc->events_availmask = 0xffffffff;
+
+		SYSCTL_ADD_INT(sc->sysctl_ctx,
+		    SYSCTL_CHILDREN(sc->sysctl_tree), OID_AUTO,
+		    "availmask", CTLFLAG_RD,
+		    &sc->events_availmask, 0, "Mask of supported events");
+	}
+
+	/* Hook up proc nodes */
+	for (i = 0; acpi_thinkpad_sysctls[i].name != NULL; i++) {
+		if (!acpi_thinkpad_sysctl_init(sc,
+		    acpi_thinkpad_sysctls[i].method))
+			continue;
+
+		SYSCTL_ADD_PROC(sc->sysctl_ctx,
+		    SYSCTL_CHILDREN(sc->sysctl_tree), OID_AUTO,
+		    acpi_thinkpad_sysctls[i].name,
+		    acpi_thinkpad_sysctls[i].access,
+		    sc, i, acpi_thinkpad_sysctl, "I",
+		    acpi_thinkpad_sysctls[i].description);
+	}
+
+	/* ACPI_SERIAL_END(thinkpad); */
+
+	/* Handle notifies */
+	AcpiInstallNotifyHandler(sc->handle, ACPI_DEVICE_NOTIFY,
+	    acpi_thinkpad_notify, dev);
+
+#if 0
+	/* Hook up light to led(4) */
+	if (sc->light_set_supported)
+		sc->led_dev = led_create_state(thinkpad_led, sc, "thinklight",
+		    sc->light_val);
+#endif
+	/* Attach sensors(9). */
+	if (sensor_task_register(sc, acpi_thinkpad_refresh, 5)) {
+		device_printf(sc->dev, "unable to register update task\n");
+		return 1;
+	}
+
+	strlcpy(sc->sensordev.xname, device_get_nameunit(sc->dev),
+	    sizeof(sc->sensordev.xname));
+
+	/* XXX: Temp sensors */
+	for (i = 0; i < 8; ++i) {
+		sc->sensors[i].type = SENSOR_TEMP;
+		sensor_attach(&sc->sensordev, &sc->sensors[i]);
+	}
+	
+	/* Fan RPM sensor */
+	sc->sensors[8].type = SENSOR_FANRPM;
+	sensor_attach(&sc->sensordev, &sc->sensors[8]);
+
+	sensordev_install(&sc->sensordev);
+
+	return (0);
+}
+
+static int
+acpi_thinkpad_detach(device_t dev)
+{
+	int i;
+
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t) __func__);
+
+	struct acpi_thinkpad_softc *sc = device_get_softc(dev);
+
+	/* Disable events and restore eventmask */
+	/* ACPI_SERIAL_BEGIN(thinkpad); */
+	acpi_thinkpad_sysctl_set(sc, ACPI_THINKPAD_METHOD_EVENTS, 0);
+	acpi_thinkpad_sysctl_set(sc, ACPI_THINKPAD_METHOD_EVENTMASK,
+	    sc->events_initialmask);
+	/* ACPI_SERIAL_END(thinkpad); */
+
+	AcpiRemoveNotifyHandler(sc->handle, ACPI_DEVICE_NOTIFY,
+	    acpi_thinkpad_notify);
+
+	sysctl_ctx_free(sc->sysctl_ctx);
+
+#if 0
+	if (sc->led_dev != NULL)
+		led_destroy(sc->led_dev);
+#endif
+	sensordev_deinstall(&sc->sensordev);
+	for (i = 0; i < 9; i++)
+		sensor_detach(&sc->sensordev, &sc->sensors[i]);
+	sensor_task_unregister(sc);
+
+	return (0);
+}
+
+static int
+acpi_thinkpad_eventmask_set(struct acpi_thinkpad_softc *sc, int val)
+{
+	int i;
+	ACPI_OBJECT		arg[2];
+	ACPI_OBJECT_LIST	args;
+	ACPI_STATUS		status;
+
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+	/* ACPI_SERIAL_ASSERT(thinkpad); */
+
+	args.Count = 2;
+	args.Pointer = arg;
+	arg[0].Type = ACPI_TYPE_INTEGER;
+	arg[1].Type = ACPI_TYPE_INTEGER;
+
+	for (i = 0; i < 32; ++i) {
+		arg[0].Integer.Value = i+1;
+		arg[1].Integer.Value = (((1 << i) & val) != 0);
+		status = AcpiEvaluateObject(sc->handle,
+		    THINKPAD_NAME_EVENTS_MASK_SET, &args, NULL);
+
+		if (ACPI_FAILURE(status))
+			return (status);
+	}
+
+	return (0);
+}
+
+static int
+acpi_thinkpad_sysctl(SYSCTL_HANDLER_ARGS)
+{
+	struct acpi_thinkpad_softc	*sc;
+	int			arg;
+	int			error = 0;
+	int			function;
+	int			method;
+	
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+
+	sc = (struct acpi_thinkpad_softc *)oidp->oid_arg1;
+	function = oidp->oid_arg2;
+	method = acpi_thinkpad_sysctls[function].method;
+
+	/* ACPI_SERIAL_BEGIN(thinkpad); */
+	arg = acpi_thinkpad_sysctl_get(sc, method);
+	error = sysctl_handle_int(oidp, &arg, 0, req);
+
+	/* Sanity check */
+	if (error != 0 || req->newptr == NULL)
+		goto out;
+
+	/* Update */
+	error = acpi_thinkpad_sysctl_set(sc, method, arg);
+
+out:
+	/* ACPI_SERIAL_END(thinkpad); */
+	return (error);
+}
+
+static int
+acpi_thinkpad_sysctl_get(struct acpi_thinkpad_softc *sc, int method)
+{
+	ACPI_INTEGER	val_ec;
+	int 		val = 0, key;
+
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+	/* ACPI_SERIAL_ASSERT(thinkpad); */
+
+	switch (method) {
+	case ACPI_THINKPAD_METHOD_EVENTS:
+		acpi_GetInteger(sc->handle, THINKPAD_NAME_EVENTS_STATUS_GET,
+		    &val);
+		break;
+
+	case ACPI_THINKPAD_METHOD_EVENTMASK:
+		if (sc->events_mask_supported)
+			acpi_GetInteger(sc->handle,
+			    THINKPAD_NAME_EVENTS_MASK_GET, &val);
+		break;
+
+	case ACPI_THINKPAD_METHOD_HOTKEY:
+		/*
+		 * Construct the hotkey as a bitmask as illustrated below.
+		 * Note that whenever a key was pressed, the respecting bit
+		 * toggles and nothing else changes.
+		 * +--+--+-+-+-+-+-+-+-+-+-+-+
+		 * |11|10|9|8|7|6|5|4|3|2|1|0|
+		 * +--+--+-+-+-+-+-+-+-+-+-+-+
+		 *   |  | | | | | | | | | | |
+		 *   |  | | | | | | | | | | +- Home Button
+		 *   |  | | | | | | | | | +--- Search Button
+		 *   |  | | | | | | | | +----- Mail Button
+		 *   |  | | | | | | | +------- Thinkpad Button
+		 *   |  | | | | | | +--------- Zoom (Fn + Space)
+		 *   |  | | | | | +----------- WLAN Button
+		 *   |  | | | | +------------- Video Button
+		 *   |  | | | +--------------- Hibernate Button
+		 *   |  | | +----------------- Thinklight Button
+		 *   |  | +------------------- Screen expand (Fn + F8)
+		 *   |  +--------------------- Brightness
+		 *   +------------------------ Volume/Mute
+		 */
+		key = rtcin(THINKPAD_RTC_HOTKEY1);
+		val = (THINKPAD_RTC_MASK_HOME | THINKPAD_RTC_MASK_SEARCH |
+		    THINKPAD_RTC_MASK_MAIL | THINKPAD_RTC_MASK_WLAN) & key;
+		key = rtcin(THINKPAD_RTC_HOTKEY2);
+		val |= (THINKPAD_RTC_MASK_THINKPAD | THINKPAD_RTC_MASK_VIDEO |
+		    THINKPAD_RTC_MASK_HIBERNATE) & key;
+		val |= (THINKPAD_RTC_MASK_ZOOM & key) >> 1;
+		key = rtcin(THINKPAD_RTC_THINKLIGHT);
+		val |= (THINKPAD_RTC_MASK_THINKLIGHT & key) << 4;
+		key = rtcin(THINKPAD_RTC_SCREENEXPAND);
+		val |= (THINKPAD_RTC_MASK_THINKLIGHT & key) << 4;
+		key = rtcin(THINKPAD_RTC_BRIGHTNESS);
+		val |= (THINKPAD_RTC_MASK_BRIGHTNESS & key) << 5;
+		key = rtcin(THINKPAD_RTC_VOLUME);
+		val |= (THINKPAD_RTC_MASK_VOLUME & key) << 4;
+		break;
+
+	case ACPI_THINKPAD_METHOD_BRIGHTNESS:
+		ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_BRIGHTNESS, &val_ec, 1);
+		val = val_ec & THINKPAD_EC_MASK_BRI;
+		break;
+
+	case ACPI_THINKPAD_METHOD_VOLUME:
+		ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_VOLUME, &val_ec, 1);
+		val = val_ec & THINKPAD_EC_MASK_VOL;
+		break;
+
+	case ACPI_THINKPAD_METHOD_MUTE:
+		val = ((val_ec & THINKPAD_EC_MASK_MUTE) ==
+		    THINKPAD_EC_MASK_MUTE);
+		break;
+
+	case ACPI_THINKPAD_METHOD_THINKLIGHT:
+		if (sc->light_get_supported)
+			acpi_GetInteger(sc->ec_handle, THINKPAD_NAME_KEYLIGHT,
+			    &val);
+		else
+			val = sc->light_val;
+		break;
+
+	case ACPI_THINKPAD_METHOD_BLUETOOTH:
+		acpi_GetInteger(sc->handle, THINKPAD_NAME_WLAN_BT_GET, &val);
+		sc->wlan_bt_flags = val;
+		val = ((val & THINKPAD_NAME_MASK_BT) != 0);
+		break;
+
+	case ACPI_THINKPAD_METHOD_WLAN:
+		acpi_GetInteger(sc->handle, THINKPAD_NAME_WLAN_BT_GET, &val);
+		sc->wlan_bt_flags = val;
+		val = ((val & THINKPAD_NAME_MASK_WLAN) != 0);
+		break;
+
+	case ACPI_THINKPAD_METHOD_FANSPEED:
+		if (sc->fan_handle) {
+			if (ACPI_FAILURE(acpi_GetInteger(sc->fan_handle,
+			    NULL, &val)))
+				val = -1;
+		}
+		else {
+			ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_FANSPEED,
+			    &val_ec, 2);
+			val = val_ec;
+		}
+		break;
+
+	case ACPI_THINKPAD_METHOD_FANLEVEL:
+		/*
+		 * The THINKPAD_EC_FANSTATUS register works as follows:
+		 * Bit 0-5 indicate the level at which the fan operates. Only
+		 *       values between 0 and 7 have an effect. Everything
+		 *       above 7 is treated the same as level 7
+		 * Bit 6 overrides the fan speed limit if set to 1
+		 * Bit 7 indicates at which mode the fan operates:
+		 *       manual (0) or automatic (1)
+		 */
+		if (!sc->fan_handle) {
+			ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_FANSTATUS,
+			    &val_ec, 1);
+			val = val_ec & THINKPAD_EC_MASK_FANLEVEL;
+		}
+		break;
+
+	case ACPI_THINKPAD_METHOD_FANSTATUS:
+		if (!sc->fan_handle) {
+			ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_FANSTATUS,
+			    &val_ec, 1);
+			val = (val_ec & THINKPAD_EC_MASK_FANSTATUS) ==
+			    THINKPAD_EC_MASK_FANSTATUS;
+		}
+		else
+			val = -1;
+		break;
+	}
+
+	return (val);
+}
+
+static int
+acpi_thinkpad_sysctl_set(struct acpi_thinkpad_softc *sc, int method, int arg)
+{
+	int			val, step, i;
+	ACPI_INTEGER		val_ec;
+	ACPI_OBJECT		Arg;
+	ACPI_OBJECT_LIST	Args;
+	ACPI_STATUS		status;
+
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+	/* ACPI_SERIAL_ASSERT(thinkpad); */
+
+	switch (method) {
+	case ACPI_THINKPAD_METHOD_EVENTS:
+		if (arg < 0 || arg > 1)
+			return (EINVAL);
+
+		status = acpi_SetInteger(sc->handle,
+		    THINKPAD_NAME_EVENTS_STATUS_SET, arg);
+		if (ACPI_FAILURE(status))
+			return (status);
+		if (sc->events_mask_supported)
+			return acpi_thinkpad_eventmask_set(sc,
+			    sc->events_availmask);
+		break;
+
+	case ACPI_THINKPAD_METHOD_EVENTMASK:
+		if (sc->events_mask_supported)
+			return acpi_thinkpad_eventmask_set(sc, arg);
+		break;
+
+	case ACPI_THINKPAD_METHOD_BRIGHTNESS:
+		if (arg < 0 || arg > 7)
+			return (EINVAL);
+
+		if (sc->cmos_handle) {
+			/* Read the current brightness */
+			status = ACPI_EC_READ(sc->ec_dev,
+			    THINKPAD_EC_BRIGHTNESS, &val_ec, 1);
+			if (ACPI_FAILURE(status))
+				return (status);
+			val = val_ec & THINKPAD_EC_MASK_BRI;
+
+			Args.Count = 1;
+			Args.Pointer = &Arg;
+			Arg.Type = ACPI_TYPE_INTEGER;
+			Arg.Integer.Value = (arg > val) ?
+			    THINKPAD_CMOS_BRIGHTNESS_UP :
+			    THINKPAD_CMOS_BRIGHTNESS_DOWN;
+
+			step = (arg > val) ? 1 : -1;
+			for (i = val; i != arg; i += step) {
+				status = AcpiEvaluateObject(sc->cmos_handle,
+				    NULL, &Args, NULL);
+				if (ACPI_FAILURE(status))
+					break;
+			}
+		}
+		return ACPI_EC_WRITE(sc->ec_dev, THINKPAD_EC_BRIGHTNESS,
+		    arg, 1);
+		break;
+
+	case ACPI_THINKPAD_METHOD_VOLUME:
+		if (arg < 0 || arg > 14)
+			return (EINVAL);
+
+		status = ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_VOLUME,
+		    &val_ec, 1);
+		if (ACPI_FAILURE(status))
+			return (status);
+
+		if (sc->cmos_handle) {
+			val = val_ec & THINKPAD_EC_MASK_VOL;
+
+			Args.Count = 1;
+			Args.Pointer = &Arg;
+			Arg.Type = ACPI_TYPE_INTEGER;
+			Arg.Integer.Value = (arg > val) ?
+			    THINKPAD_CMOS_VOLUME_UP : THINKPAD_CMOS_VOLUME_DOWN;
+
+			step = (arg > val) ? 1 : -1;
+			for (i = val; i != arg; i += step) {
+				status = AcpiEvaluateObject(sc->cmos_handle,
+				    NULL, &Args, NULL);
+				if (ACPI_FAILURE(status))
+					break;
+			}
+		}
+		return ACPI_EC_WRITE(sc->ec_dev, THINKPAD_EC_VOLUME, arg +
+		    (val_ec & (~THINKPAD_EC_MASK_VOL)), 1);
+		break;
+
+	case ACPI_THINKPAD_METHOD_MUTE:
+		if (arg < 0 || arg > 1)
+			return (EINVAL);
+
+		status = ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_VOLUME,
+		    &val_ec, 1);
+		if (ACPI_FAILURE(status))
+			return (status);
+
+		if (sc->cmos_handle) {
+			val = val_ec & THINKPAD_EC_MASK_VOL;
+
+			Args.Count = 1;
+			Args.Pointer = &Arg;
+			Arg.Type = ACPI_TYPE_INTEGER;
+			Arg.Integer.Value = THINKPAD_CMOS_VOLUME_MUTE;
+
+			status = AcpiEvaluateObject(sc->cmos_handle, NULL,
+			    &Args, NULL);
+			if (ACPI_FAILURE(status))
+				break;
+		}
+		return ACPI_EC_WRITE(sc->ec_dev, THINKPAD_EC_VOLUME, (arg==1) ?
+		   val_ec | THINKPAD_EC_MASK_MUTE :
+		   val_ec & (~THINKPAD_EC_MASK_MUTE), 1);
+		break;
+
+	case ACPI_THINKPAD_METHOD_THINKLIGHT:
+		if (arg < 0 || arg > 1)
+			return (EINVAL);
+
+		if (sc->light_set_supported) {
+			Args.Count = 1;
+			Args.Pointer = &Arg;
+			Arg.Type = ACPI_TYPE_INTEGER;
+			Arg.Integer.Value = arg ?
+			    sc->light_cmd_on : sc->light_cmd_off;
+
+			status = AcpiEvaluateObject(sc->light_handle, NULL,
+			    &Args, NULL);
+			if (ACPI_SUCCESS(status))
+				sc->light_val = arg;
+			return (status);
+		}
+		break;
+
+	case ACPI_THINKPAD_METHOD_BLUETOOTH:
+		if (arg < 0 || arg > 1)
+			return (EINVAL);
+
+		val = (arg == 1) ? sc->wlan_bt_flags |
+		    THINKPAD_NAME_MASK_BT :
+		    sc->wlan_bt_flags & (~THINKPAD_NAME_MASK_BT);
+		return acpi_SetInteger(sc->handle, THINKPAD_NAME_WLAN_BT_SET,
+		    val);
+		break;
+
+	case ACPI_THINKPAD_METHOD_FANLEVEL:
+		if (arg < 0 || arg > 7)
+			return (EINVAL);
+
+		if (!sc->fan_handle) {
+			/* Read the current fanstatus */
+			ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_FANSTATUS,
+			    &val_ec, 1);
+			val = val_ec & (~THINKPAD_EC_MASK_FANLEVEL);
+
+			return ACPI_EC_WRITE(sc->ec_dev, THINKPAD_EC_FANSTATUS,
+			    val | arg, 1);
+		}
+		break;
+
+	case ACPI_THINKPAD_METHOD_FANSTATUS:
+		if (arg < 0 || arg > 1)
+			return (EINVAL);
+
+		if (!sc->fan_handle) {
+			/* Read the current fanstatus */
+			ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_FANSTATUS,
+			    &val_ec, 1);
+
+			return ACPI_EC_WRITE(sc->ec_dev, THINKPAD_EC_FANSTATUS,
+			    (arg == 1) ? (val_ec | THINKPAD_EC_MASK_FANSTATUS) :
+			    (val_ec & (~THINKPAD_EC_MASK_FANSTATUS)), 1);
+		}
+		break;
+	}
+
+	return (0);
+}
+
+static int
+acpi_thinkpad_sysctl_init(struct acpi_thinkpad_softc *sc, int method)
+{
+	int 			dummy;
+	ACPI_OBJECT_TYPE 	cmos_t;
+	ACPI_HANDLE		ledb_handle;
+
+	switch (method) {
+	case ACPI_THINKPAD_METHOD_EVENTS:
+		/* Events are disabled by default */
+		return (TRUE);
+
+	case ACPI_THINKPAD_METHOD_EVENTMASK:
+		return (sc->events_mask_supported);
+
+	case ACPI_THINKPAD_METHOD_HOTKEY:
+	case ACPI_THINKPAD_METHOD_BRIGHTNESS:
+	case ACPI_THINKPAD_METHOD_VOLUME:
+	case ACPI_THINKPAD_METHOD_MUTE:
+		/* EC is required here, which was already checked before */
+		return (TRUE);
+
+	case ACPI_THINKPAD_METHOD_THINKLIGHT:
+		sc->cmos_handle = NULL;
+		sc->light_get_supported = ACPI_SUCCESS(acpi_GetInteger(
+		    sc->ec_handle, THINKPAD_NAME_KEYLIGHT, &sc->light_val));
+
+		if ((ACPI_SUCCESS(AcpiGetHandle(sc->handle, "\\UCMS",
+		    &sc->light_handle)) ||
+		    ACPI_SUCCESS(AcpiGetHandle(sc->handle, "\\CMOS",
+		    &sc->light_handle)) ||
+		    ACPI_SUCCESS(AcpiGetHandle(sc->handle, "\\CMS",
+		    &sc->light_handle))) &&
+		    ACPI_SUCCESS(AcpiGetType(sc->light_handle, &cmos_t)) &&
+		    cmos_t == ACPI_TYPE_METHOD) {
+			sc->light_cmd_on = 0x0c;
+			sc->light_cmd_off = 0x0d;
+			sc->cmos_handle = sc->light_handle;
+		}
+		else if (ACPI_SUCCESS(AcpiGetHandle(sc->handle, "\\LGHT",
+		    &sc->light_handle))) {
+			sc->light_cmd_on = 1;
+			sc->light_cmd_off = 0;
+		}
+		else
+			sc->light_handle = NULL;
+
+		sc->light_set_supported = (sc->light_handle &&
+		    ACPI_FAILURE(AcpiGetHandle(sc->ec_handle, "LEDB",
+		    &ledb_handle)));
+
+		if (sc->light_get_supported)
+			return (TRUE);
+
+		if (sc->light_set_supported) {
+			sc->light_val = 0;
+			return (TRUE);
+		}
+
+		return (FALSE);
+
+	case ACPI_THINKPAD_METHOD_BLUETOOTH:
+	case ACPI_THINKPAD_METHOD_WLAN:
+		if (ACPI_SUCCESS(acpi_GetInteger(sc->handle,
+		    THINKPAD_NAME_WLAN_BT_GET, &dummy)))
+			return (TRUE);
+		return (FALSE);
+
+	case ACPI_THINKPAD_METHOD_FANSPEED:
+		/* 
+		 * Some models report the fan speed in levels from 0-7
+		 * Newer models report it contiguously
+		 */
+		sc->fan_levels = (ACPI_SUCCESS(AcpiGetHandle(sc->handle, "GFAN",
+		    &sc->fan_handle)) ||
+		    ACPI_SUCCESS(AcpiGetHandle(sc->handle, "\\FSPD",
+		    &sc->fan_handle)));
+		return (TRUE);
+
+	case ACPI_THINKPAD_METHOD_FANLEVEL:
+	case ACPI_THINKPAD_METHOD_FANSTATUS:
+		/* 
+		 * Fan status is only supported on those models,
+		 * which report fan RPM contiguously, not in levels
+		 */
+		if (sc->fan_levels)
+			return (FALSE);
+		return (TRUE);
+
+	case ACPI_THINKPAD_METHOD_THERMAL:
+		if (ACPI_SUCCESS(acpi_GetInteger(sc->ec_handle,
+		    THINKPAD_NAME_THERMAL_GET, &dummy))) {
+			sc->thermal_updt_supported =
+			    ACPI_SUCCESS(acpi_GetInteger(sc->ec_handle,
+			    THINKPAD_NAME_THERMAL_UPDT, &dummy));
+			return (TRUE);
+		}
+		return (FALSE);
+	}
+	return (FALSE);
+}
+
+static void
+acpi_thinkpad_notify(ACPI_HANDLE h, UINT32 notify, void *context)
+{
+	int		event, arg, type;
+	device_t	dev = context;
+	struct acpi_thinkpad_softc *sc = device_get_softc(dev);
+
+	ACPI_FUNCTION_TRACE_U32((char *)(uintptr_t)__func__, notify);
+
+	if (notify != 0x80)
+		device_printf(dev, "Unknown notify\n");
+
+	for (;;) {
+		acpi_GetInteger(acpi_get_handle(dev), THINKPAD_NAME_EVENTS_GET,
+		    &event);
+
+		if (event == 0)
+			break;
+
+		type = (event >> 12) & 0xf;
+		arg = event & 0xfff;
+		switch (type) {
+		case 1:
+			if (!(sc->events_availmask & (1 << (arg - 1)))) {
+				device_printf(dev, "Unknown key %d\n", arg);
+				break;
+			}
+
+			/* Notify devd(8) */
+			device_printf(dev, "THINKPAD event: %u\n",
+			    (arg & 0xff));
+			acpi_UserNotify("THINKPAD", h, (arg & 0xff));
+			break;
+		default:
+			break;
+		}
+	}
+}
+
+static void
+acpi_thinkpad_refresh(void *arg)
+{
+	struct acpi_thinkpad_softc *sc = (struct acpi_thinkpad_softc *)arg;
+	char temp_cmd[] = "TMP0";
+	int data, i;
+	ACPI_INTEGER speed;
+
+	for (i = 0; i < 8; i++) {
+		temp_cmd[3] = '0' + i;
+		
+                /*
+                 * The TMPx methods seem to return +/- 128 or 0
+                 * when the respecting sensor is not available
+                 */
+		sc->sensors[i].flags &= ~SENSOR_FINVALID;
+                if (ACPI_FAILURE(acpi_GetInteger(sc->ec_handle, temp_cmd,
+                    &data)) || ABS(data) == 128 || data == 0) {
+			sc->sensors[i].flags |= SENSOR_FINVALID;
+                        data = 0;
+		}
+                else if (sc->thermal_updt_supported) {
+                        /* XXX: Temperature is reported in tenth of Kelvin */
+                        data = (data - 2732 + 5) / 10;
+		}
+		sc->sensors[i].value = data * 1000000 + 273150000;
+        }
+	
+	sc->sensors[8].flags &= ~SENSOR_FINVALID;
+	if (sc->fan_handle) {
+		if (ACPI_FAILURE(acpi_GetInteger(sc->fan_handle,
+		    NULL, &data)))
+			sc->sensors[8].flags |= SENSOR_FINVALID;
+                        data = -1;
+        }
+        else {
+                ACPI_EC_READ(sc->ec_dev, THINKPAD_EC_FANSPEED, &speed, 2);
+                data = speed;
+        }
+
+	sc->sensors[8].value = data;
+}
diff --git a/sys/platform/pc32/conf/files b/sys/platform/pc32/conf/files
--- a/sys/platform/pc32/conf/files
+++ b/sys/platform/pc32/conf/files
@@ -72,6 +72,7 @@ dev/serial/dgb/dgm.c			optional	dgm
 ${OSACPI_MD_DIR}/acpi_machdep.c		optional        acpi
 ${OSACPI_MD_DIR}/acpi_wakeup.c		optional        acpi
 ${OSACPI_MD_DIR}/acpi_toshiba.c		optional        acpi_toshiba acpi
+${ACPICA_DIR}/acpi_thinkpad/acpi_thinkpad.c optional	acpi_thinkpad acpi
 acpi.h					optional	acpi		\
 	dependency	"$S/${ACPICA_DIR}/include/acpi.h"		\
 	compile-with	"cp $S/${ACPICA_DIR}/include/acpi.h ${.OBJDIR}/"	\



From hasso at estpak.ee  Thu Mar 20 03:49:13 2008
From: hasso at estpak.ee (Hasso Tepper)
Date: Thu, 20 Mar 2008 03:49:13 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Some questions regarding ACPI
In-Reply-To: <200803191322.46366.hasso@estpak.ee>
Message-ID: <200803201237.28823.hasso@estpak.ee>

Hasso Tepper wrote:
> There is also one fatal issue -laptop locks up hardly (no panic) while 
> unloading module. Any idea regarding this is welcome.

Nevermind, solved.


-- 
Hasso




From dillon at apollo.backplane.com  Fri Mar 21 19:24:01 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Fri, 21 Mar 2008 19:24:01 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: panic: assertion: hammer_btree_cmp(cursor->left_bound,	&cursor->node->ondisk->elms[0].leaf.base) <= 0 in btree_split_leaf
In-Reply-To: <200802232204.m1NM4cxd046264@apollo.backplane.com>
Message-ID: <200803220212.m2M2CiAY014435@apollo.backplane.com>

:While trying to find a procedure to reliably reproduce the panic
:I reported last time, I caught a different panic (uploaded at
: ~y0netan1/crash/9/ on my leaf account).  I wrote the following shell
:script (make sure to edit variables DISKS and MOUNTPT before using this
:script or it may trash your system):

    Ok, I believe I have fixed the left_bound assertion.  I also believe
    I have fixed the node ref count assertion on umount.

    There is currently one unfixed assertion related to the I/O
    path... sometimes the bp is being improperly disassociated from the
    related HAMMER structure.

    The full-filesystem case is still not being handled so don't test that :-)

					    -Matt





From c.turner at 199technologies.org  Sun Mar 23 09:48:29 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Sun, 23 Mar 2008 09:48:29 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
Message-ID: <47E6870C.4080709@199technologies.org>

I'm finally getting around to doing 1.12 upgrades, and have setup a 
separate machine to do my bulk package builds / upgrades etc,
so as not to disrupt my 'dev server' while things are being
built / tested

However, this seems kind of wasteful - the only purpose of this machine
is to build packages against a specific release..
And since building packages for a particular release generally requires 
only the userland, appropriate headers and correct 'uname' output - so:

it seems like if spoofing uname is configured inside a jail,
the next (or previous..) release can be installed into a jail and
used for building / testing packages without the overhead of a VM or 
maintaining a separate physical host

I did a quick scan of the tree to see what this would take, and, high 
level, it seems like only the following changes would need to be made:

- update struct jail to add a 'osrelease' string
  (implies bumping 'jail api' to 2?)
- update jail(8) to actually pass this information along
- update sys_uname to test ucred for jailed processes, and
  use the struct jail osrelease if appropriate
- similarly update sysctl kern.osrelease to support jail spoofing
  (if possible - didn't get this far in the research yet)
  could be less of a problem for builds, as I think most things use
 uname(1) ... but good to keep the environment consistent I suppose..
I'm still a bit confused as to how 'osrelease' is defined - everything
I'm finding is showing up as extern char[] .. perhaps this is something 
in the build I'm not familiar with?

also,

is the so-called 'stupid hackery' in sys_uname needed still?

Before I start any coding, does this:

- sound like something useful
- sound like the right approach
Thinking this could have wider useful implications e.g. for pkgbox
& so on -  for example setting up automated bulks w/various combinations 
of pkgsrc and releases, etc.

Cheers,

- Chris





From corecode at fs.ei.tum.de  Sun Mar 23 10:06:38 2008
From: corecode at fs.ei.tum.de (Simon 'corecode' Schubert)
Date: Sun, 23 Mar 2008 10:06:38 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <47E68C74.3080808@fs.ei.tum.de>

Chris Turner wrote:
I did a quick scan of the tree to see what this would take, and, high 
level, it seems like only the following changes would need to be made:
brave investigation.  but you could also simply set UNAME_r :)

sweatshorts % uname -r
1.13.0-DEVELOPMENT
sweatshorts % UNAME_r=1.12-RELEASE uname -r
1.12-RELEASE
I think that's good enough :D

cheers
  simon
--
Serve - BSD     +++  RENT this banner advert  +++    ASCII Ribbon   /"\
Work - Mac      +++  space for low ????????? NOW!1  +++      Campaign     \ /
Party Enjoy Relax   |   http://dragonflybsd.org      Against  HTML   \
Dude 2c 2 the max   !   http://golden-apple.biz       Mail + News   / \




From c.turner at 199technologies.org  Sun Mar 23 10:50:13 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Sun, 23 Mar 2008 10:50:13 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <47E69656.8080605@199technologies.org>

Simon 'corecode' Schubert wrote:
brave investigation.  but you could also simply set UNAME_r :)
Doh! Thanks for the tip!

they should change the phrase from RTFM to 'Carefully RTFM' :)

well.. scratch that change then. 1 less patch to write.

- Chris





From c.turner at 199technologies.org  Sun Mar 23 11:15:52 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Sun, 23 Mar 2008 11:15:52 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <47E69C7C.8010109@199technologies.org>

Chris Turner wrote:
Simon 'corecode' Schubert wrote:
brave investigation.  but you could also simply set UNAME_r :)

for the record - if anyone's interested - adding a line e.g.:

ALL_ENV+= UNAME_r=1.12-RELEASE

to mk.conf looks like it -might- work ..

(unless wants to chime in & verify)





From joerg at britannica.bec.de  Sun Mar 23 11:46:53 2008
From: joerg at britannica.bec.de (Joerg Sonnenberger)
Date: Sun, 23 Mar 2008 11:46:53 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <20080323181428.GA2099@britannica.bec.de>

On Sun, Mar 23, 2008 at 01:41:42PM -0400, Chris Turner wrote:
> they should change the phrase from RTFM to 'Carefully RTFM' :)

RTFMAI -- Read The Fine Manual Again, Idiot.

Joerg




From dillon at apollo.backplane.com  Sun Mar 23 20:05:36 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Sun, 23 Mar 2008 20:05:36 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
Message-ID: <200803240257.m2O2voNH038355@apollo.backplane.com>

    Here's an update on the HAMMER work!

    Current status:

    * Passes all standard filesystem stress tests and buildworld will
      run with a HAMMER /usr/obj.  Large histories are able to accumulate
      without effecting performance.

    * Pruning and reblocking code is in and partially tested, but now needs
      more stringent testing.

    * Full historical access appears to be working but needs testing.
      Note that a sync is still needed to flush dirty cached data prior
      to acquiring a timestamp for the 'snapshot' to be set in stone.
      (dirty data cached in-memory has no historical tags and must be
      committed to physical disk before it can be accessed historically).


    Current bugs:

    * There is one known bug in the standard operations code paths
      that results in an assertion in HAMMER's I/O subsystem.

    * There are probably bugs in the reblocking and/or pruning code.  More
      likely in the reblocking code.


    There are two big-ticket and several little-ticket items left.  HAMMER
    will officially go Alpha when the big-ticket items are done, and beta
    when we get a few of the little-ticket items done.

    Big ticket items left:

    * UNDO (crash recovery) code.  Currently it writes out undo records but
      they are not yet sequenced, buffer writes are not yet ordered, and
      there is no mount-time recovery code yet.

      This is the last item needed before HAMMER can go operational.

    * Filesystem full handling.  Currently no space is reserved for dirty
      cached data so it is possible to create/write files and for HAMMER
      to not have sufficient space left on-disk to flush it.


    Little ticket items:

    * Automated reblocking (currently these functions are manually
      initialized via the hammer utility).

    * I/O clustering and preliminary BMAP op when writing out large files.

    * CRC checking (CRC fields are reserved but not entirely generated yet
      and not yet checked at all).

    * Disaster Recovery filesystem scan.

    * Boot support.

    I expect all of these items and more to be handled by the 2.0 release
    in July.

			    Additional HAMMER capabilities
				(no timeline yet)

    * Adding, removing, and resizing a HAMMER filesystem's backing store.

			Ultimate Goals and working towards them
				(no timeline yet)

    Our ultimate goal with HAMMER and DragonFly in general is to support
    fully cache coherent replication in a multi-machine environment.  This
    involves several steps and networking protocols.

    * Replication of synchronization streams based on the UNDO log.  If
      resynchronizing to a target which is too old a B-Tree scan will
      likely be required.

    * Cache coherency protocols for machine-machine coherency for both
      replicated and remote-HAMMER access.

    I have no time frame for these items yet.  It will depend on how quickly
    HAMMER moves to Alpha and Beta status.  I will say, however, now
    that HAMMER's on-disk format has solidified, that I have a very precise
    understanding of the protocols that will be needed to accomplish fully
    cache coherent remote access for both replicated and non-replicated
    (remote mount style) access.

    And, as you know, fully coherent filesystem access across machines is
    going to be the basis for DragonFly's clustering across said machines.

    In summary, things are progressing very well.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From justin at shiningsilence.com  Sun Mar 23 20:10:13 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Sun, 23 Mar 2008 20:10:13 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <53758.192.168.0.252.1206327873.squirrel@www.shiningsilence.com>

On Sun, March 23, 2008 12:36 pm, Chris Turner wrote:

> it seems like if spoofing uname is configured inside a jail,
> the next (or previous..) release can be installed into a jail and
> used for building / testing packages without the overhead of a VM or
> maintaining a separate physical host

If you don't need a jail to spoof uname, as others posted, you can
installworld into a chroot and build everything you want there using
Joerg's spiffy pbulk.  That's what I'm doing on pkgbox now; I can hand you
my somewhat terse notes if you want.  It would be relatively easy to set
up the configuration you're talking about.





From sepherosa at gmail.com  Sun Mar 23 20:18:20 2008
From: sepherosa at gmail.com (Sepherosa Ziehau)
Date: Sun, 23 Mar 2008 20:18:20 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <ea7b9c170803232012n2f27f893tf1d756d7c9770419@mail.gmail.com>

On Mon, Mar 24, 2008 at 2:14 AM, Joerg Sonnenberger
<joerg at britannica.bec.de> wrote:
> On Sun, Mar 23, 2008 at 01:41:42PM -0400, Chris Turner wrote:
>  > they should change the phrase from RTFM to 'Carefully RTFM' :)
>
>  RTFMAI -- Read The Fine Manual Again, Idiot.

http://leaf.dragonflybsd.org/~sephe/rtfm.jpg

:D

>
>  Joerg
>



-- 
Live Free or Die




From justin at shiningsilence.com  Sun Mar 23 20:38:30 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Sun, 23 Mar 2008 20:38:30 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: GSoC 2008 - mentors signup
Message-ID: <53885.192.168.0.252.1206329503.squirrel@www.shiningsilence.com>

If you are planning to be a mentor for a Summer of Code project, please
sign up here for the mentors mailing list:

http://groups.google.com/group/google-summer-of-code-mentors-list

If you've already signed up, your subscription should be set up tomorrow.





From justin at shiningsilence.com  Sun Mar 23 21:12:01 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Sun, 23 Mar 2008 21:12:01 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: GSoC 2008 - mentors signup
In-Reply-To: <53885.192.168.0.252.1206329503.squirrel@www.shiningsilence.com>
Message-ID: <54025.192.168.0.252.1206331572.squirrel@www.shiningsilence.com>

Also!

If you are a potential mentor and you have not done so yet:

http://code.google.com/soc/mentor_step1.html

Get yourself registered as a mentor for the Summer of Code project.  Once
you are in there, check off DragonFly in the "My Profile" section.

You will need a Google Account if you don't have one:

http://www.google.com/accounts

This will add you to the list of mentors in the Google Summer of Code web
application, so you can review/be attached to projects.

A guide is available if you want more information:

http://groups.google.com/group/google-summer-of-code-announce/web/guide-to-the-gsoc-web-app-for-mentors-and-organization-administrators






From c.turner at 199technologies.org  Mon Mar 24 04:29:28 2008
From: c.turner at 199technologies.org (Chris Turner)
Date: Mon, 24 Mar 2008 04:29:28 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <47E78ECE.4070307@199technologies.org>

Justin C. Sherrill wrote:
If you don't need a jail to spoof uname, as others posted, you can
installworld into a chroot and build everything you want there using
Joerg's spiffy pbulk.  That's what I'm doing on pkgbox now; I can hand you
my somewhat terse notes if you want.  It would be relatively easy to set
up the configuration you're talking about.
cheers - I guess I thought incorrectly that something 'special' was 
needed to get the uname to change .. have been using the legacy bulks in 
chroots / jails (for 'same os' builds) as I haven't quite migrated to 
pbulk yet ..

thanks for the help offer - I'll ask if I run into trouble.




From dillon at apollo.backplane.com  Mon Mar 24 08:28:49 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Mon, 24 Mar 2008 08:28:49 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Jail uname spoofing / misc
In-Reply-To: <47E6870C.4080709@199technologies.org>
Message-ID: <200803241500.m2OF0CG8043760@apollo.backplane.com>


:http://leaf.dragonflybsd.org/~sephe/rtfm.jpg
:
::D

    Ho!

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From elekktretterr at exemail.com.au  Mon Mar 24 09:10:15 2008
From: elekktretterr at exemail.com.au (Petr Janda)
Date: Mon, 24 Mar 2008 09:10:15 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
In-Reply-To: <200803240257.m2O2voNH038355@apollo.backplane.com>
Message-ID: <200803250138.49775.elekktretterr@exemail.com.au>


>
>     And, as you know, fully coherent filesystem access across machines is
>     going to be the basis for DragonFly's clustering across said machines.
>
>     In summary, things are progressing very well.
>


Hi Matt,
That's good to know things are going so well. Got a question. If memory serves 
me right, initially there was also going to be a thing called ANVIL, I can't 
remember what it was supposed to do and whether its still in your design. 
Could you elaborate a little?

Thanks,
Petr




From dillon at apollo.backplane.com  Mon Mar 24 14:12:11 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Mon, 24 Mar 2008 14:12:11 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
In-Reply-To: <200803240257.m2O2voNH038355@apollo.backplane.com>
Message-ID: <200803242100.m2OL0nWV046868@apollo.backplane.com>


:Hi Matt,
:That's good to know things are going so well. Got a question. If memory serves 
:me right, initially there was also going to be a thing called ANVIL, I can't 
:remember what it was supposed to do and whether its still in your design. 
:Could you elaborate a little?
:
:Thanks,
:Petr

    It's not really in the HAMMER design any more, primarily because HAMMER's
    volume model seems to work fine as-is.  Ultimately something like ANVIL
    (a block storage manager) would prove beneficial to the project but it
    would be treated as a separate project.  HAMMER's redundancy model is
    going to be baesd around replication and clustering.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From tgen at netphreax.net  Mon Mar 24 18:31:37 2008
From: tgen at netphreax.net (Thomas E. Spanjaard)
Date: Mon, 24 Mar 2008 18:31:37 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
In-Reply-To: <200803240257.m2O2voNH038355@apollo.backplane.com>
Message-ID: <47E85337.2070407@netphreax.net>

Matthew Dillon wrote:
    * Full historical access appears to be working but needs testing.
      Note that a sync is still needed to flush dirty cached data prior
      to acquiring a timestamp for the 'snapshot' to be set in stone.
      (dirty data cached in-memory has no historical tags and must be
      committed to physical disk before it can be accessed historically).
Wouldn't making timestamp queries (at least from userland) enforce a 
sync on the volume in question be useful here?
--
        Thomas E. Spanjaard
        tgen at netphreax.net
Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00005.pgp
Type: application/octet-stream
Size: 186 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080324/3077333f/attachment-0020.obj>

From dillon at apollo.backplane.com  Mon Mar 24 20:10:12 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Mon, 24 Mar 2008 20:10:12 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
In-Reply-To: <200803240257.m2O2voNH038355@apollo.backplane.com>
Message-ID: <200803250302.m2P32qLP050160@apollo.backplane.com>


:Wouldn't making timestamp queries (at least from userland) enforce a 
:sync on the volume in question be useful here?
:-- 
:         Thomas E. Spanjaard
:         tgen at netphreax.net

    Making the 'hammer now' command do a sync() is a good idea.  I will
    make that change right now so it doesn't get lost.

    Here's a general overview of the issues involved with having historical
    access to the filesystem:

				----------------

    Recording the timestamps in the in-memory cache, for a finer-grained
    snapshot capability, is doable but has its own issues.  Here's an
    illustration:

    open()  create file
    write() append 4K	(file size now 4K)
    write() append 4K	(file size now 8K)
    write() append 4K	(file size now 12K)
    write() append 4K	(file size now 16K)

    Now NONE of this has gone to disk yet, it's entirely in the in-memory
    cache.  The inode is in the in-memory cache.  The data is stored in
    the buffer cache.  Even the directory entry for the file that we
    just created is still in the in-memory cache (HAMMER caches the raw
    records it intends to commit later on).

    If I wanted to be able to acquire a timestamp between each write and
    'see' a snapshot of the file as of any point in the above sequence,
    then every write would also have to allocate a copy of the inode
    (because it changes size on each write).

    The data has the same problem though with a slightly different example.
    Lets say each write() was a seek-write, overwriting the previous data.
    Now with every write() I would have to allocate a copy of the data
    being overwritten.  This is complicated by the fact that the buffer
    cache has no clue about 'historical' accesses, so I would not be able
    to use the buffer cache to cache the data.

    There's also another problem and that is with the efficiency of the
    topology on-disk.  Even if I maintained all the copies of the inode
    and all the copies of the data in-memory, I would still have to sync
    all those copies to disk in order for things to remain historically
    coherent (whether it be in-cache or on-disk).  This would result in
    hundreds or even thousands of copies of the inode on-disk, not to
    mention potentially many copies of the data.

    I just don't want to do that right now, at least not as a default.  A
    lot of performance would be lost.  Hence a sync() is needed if
    you want to create a demark which you can accurately snapshot.

				-------------

    Here's a quick synopsis of how the cache would operate in a clustered
    filesystem:

    In order to properly integrate with in-memory caches, a wider cache
    coherency infrastructure is needed between machines such that
    modifications made on one machine proactively invalidate those
    protions of the cache(s) on other machines.  At the same time, any
    'dirty' cache data, for example when a file is created or written to,
    must lock the cache space in question on all other machines.
    The cache space in this case is not just the file data, but also the
    related namespaces (for creations, deletions, and renames).  Attempts
    to access locked spaces from other machines in the cluster would have
    to force a flush to the filesystem backing store and lower the cache
    states for the effected information on the original machine from dirty
    to shared-read-only.

    It will be easiest to integrate the cache coherency information into
    the buffer cache and namecache themselves.  Once a machine has dirtied
    an in-memory cache element... for example part of the namespace when
    creating a file or chunks of data written within a file, that machine
    must have a free hand to make further modifications to the cache spaces
    involved without further interaction with other machines.

				-------------

    Now, if you think of those two major elements you can see that they
    actually fit together quite well.  If I were to attempt to maintain
    transactional coherency on a per-system-call basis then the cache
    granularity between machines would have to be much, much smaller then
    our current in-memory caching elements provide.  That would become
    a really nasty coding problem.  So I don't even want to begin to
    complate transactional coherency at a finer-grain then sync() or
    fsync() until long after we actually have clustering working.

						-Matt





From elekktretterr at exemail.com.au  Mon Mar 24 21:56:58 2008
From: elekktretterr at exemail.com.au (Petr Janda)
Date: Mon, 24 Mar 2008 21:56:58 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
In-Reply-To: <200803240257.m2O2voNH038355@apollo.backplane.com>
Message-ID: <200803251516.16407.elekktretterr@exemail.com.au>

So is it needed to run hammer now in order to "create" a snapshot? What would 
I do in situation like this: got a hammer filesystem and couple of the files 
change on day to day basis. Then a week later I needed to access one of the 
files, in exactly the state they were 7 days ago.

Cheers,
Petr




From dillon at apollo.backplane.com  Mon Mar 24 22:34:15 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Mon, 24 Mar 2008 22:34:15 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 23-Mar-08
In-Reply-To: <200803240257.m2O2voNH038355@apollo.backplane.com>
Message-ID: <200803250526.m2P5QZ5X051081@apollo.backplane.com>


:So is it needed to run hammer now in order to "create" a snapshot? What would 
:I do in situation like this: got a hammer filesystem and couple of the files 
:change on day to day basis. Then a week later I needed to access one of the 
:files, in exactly the state they were 7 days ago.
:
:Cheers,
:Petr

    No, you do not have to run 'hammer now' to create a snapshot.  The
    kernel syncs all filesystems every 30 seconds, so if you do nothing
    at all you get a snapshot granularity of 30 seconds.

    Where you would use 'hammer now' is if you wanted the most current
    snapshot possible for the purpose of, say, backing up your filesystem
    to another machine.  You might do something like this:

	set timestamp = `hammer now`
	cpdup /mountpoint/@@$timestamp targethost:/somepath

    But if you didn't care about that you could just go back far enough
    that you get a stable historical view... e.g. go back 1 minute and you
    would have a stable view into your filesystem.

	set timestamp = `hammer stamp 60s`		<------ doesn't sync
	cpdup /mountpoint/@@$timestamp targethost:/somepath


    Ultimately the idea of managing filesystems this way is to still do
    regular backups from your production machine to your backup machine
    (ultimately by way of replication), with both running HAMMER, but only
    retain a limited amount of history on the production box.  You might
    desire to retain only one week's worth of history on the production box,
    retain one month's history on your local backup box, and retain a very
    granular one year's worth of history on your remote backup box.

    Come to think of it, I should add some more directives to the
    'hammer prune' command to make that easier to specify.

    Until I implement a live replication 'feed' the minimum granularity on
    the backup box will be how often you do your backups (e.g. once a day),
    and you can prune it into more granular forms from that starting point.
    Once we have a live replication feed the backup box will have the same
    30-second granularity that the production machine has.

    A major bullet point for this style of management is that the retention
    policy on the various boxes can be different even though they are
    all slaved off the same production filesystem.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From justin at shiningsilence.com  Tue Mar 25 05:58:49 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Tue, 25 Mar 2008 05:58:49 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: SoC - student signups
Message-ID: <58180.65.106.147.226.1206449676.squirrel@www.shiningsilence.com>

Here's a quick link roundup:

Are you a student?  Put in your application for a Google Summer of Code here:

http://code.google.com/soc/2008/student_signup.html

Student guide:
http://groups.google.com/group/google-summer-of-code-announce/web/guide-to-the-gsoc-web-app-for-student-applicants

Are you a mentor?  (That means hasso, hsu, sephe, matthias, TGEN, and
corecode right now)

Student proposals will show up on the mentor page, linked below.  You will
get to rate them, and take the one(s) that you want to mentor.

Mentor page:
http://code.google.com/soc/2008/mentor_home.html
Mentor guide:
http://groups.google.com/group/google-summer-of-code-announce/web/guide-to-the-gsoc-web-app-for-mentors-and-organization-administrators

If you are a mentor and are communicating with potential students, send
them the URLs above for student signup and the student guide; work with
them if they ask for advice on what to say in the application.  They can
resubmit up to 20 times if they want to correct it.

Deadline is March 31st.






From noah.yan at gmail.com  Thu Mar 27 20:17:48 2008
From: noah.yan at gmail.com (Yonghong Yan)
Date: Thu, 27 Mar 2008 20:17:48 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: About DFBSD.64
In-Reply-To: <47EB0B5B.5020802@gmail.com>
Message-ID: <59521b110803272015y1cc8cc39uc93f154ed36e0505@mail.gmail.com>

thanks for your interest.

I owe to everybody for any update or work in the past four months. so
many things happen in my work and my family (they are all good:) and
keep me extremely busy. But i am not leaving and will be back on this
soon.

the latest sources are in http://repo.or.cz/w/dragonfly/port-amd64.git
, I did have a compiled kernel long time before, but I have to break
it to work on the pmap. you can pick up from there. TGEN will help you
a lot, also keep me posted too, if you like.

Noah

On Wed, Mar 26, 2008 at 9:50 PM, Sdavtaker <sdavtaker at gmail.com> wrote:
> Hello,
>  Im applying to GSoC to work in the x64 version of DFBSD with TGEN, i
>  found some work already done in the repository and some mails in the
>  archive from you.
>  I was wondering if you already had a working compiled kernel in AMD64
>  machine and what was not working yet to continue that work.
>  Thanks for any info.
>  Sdav
>




From dillon at apollo.backplane.com  Sat Mar 29 13:27:43 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Sat, 29 Mar 2008 13:27:43 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: HAMMER update 29-Mar-2008
Message-ID: <200803292022.m2TKMLGe004942@apollo.backplane.com>

    Good progress continues to be made.  HAMMER survived acting as my
    LAN backup machine (in full historical mode) for almost a week before
    it hit an assertion.  I've fixed that issue and believe that the core
    filesystem implementation code is now 'very stable'.

    Note that the recent commit will result in many more 'hammer_lock_ex:'
    messages on the console then you may have previously observed.  This is
    due to the way object id's are allocated in the face of parallel 
    modifications to the filesystem, resulting in too much locality of
    reference in the B-Tree.  I do intend to improve it.

    I am still working on the two major items needed before HAMMER can be
    declared operational, those being the filesystem full handling and the
    undo/recovery-on-mount code.  These are the last 'hard' bits left in
    the design.

    With exception to filling up the filesystem, which *will* create a mess,
    and noting that no crash recovery code exists yet (so you have to newfs
    it if you crash), I'd appreciate it if interested parties could test
    the other functions of the filesystem, in particular the pruning and
    reblocking functions (man hammer), and the historical access functions.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From dillon at apollo.backplane.com  Sun Mar 30 15:11:03 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Sun, 30 Mar 2008 15:11:03 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: Need ideas on how to solve an st_ino/st_dev test issue for HAMMER.
Message-ID: <200803302207.m2UM7BCp016402@apollo.backplane.com>

    Here's the problem, given historical access softlinks as shown below:

test30# ls -lda cra*
drwxr-xr-x  1 root  wheel  Mar 29 13:04 crater
lrwxr-xr-x  1 root  wheel  Mar 29 18:57 crater.20080329 -> crater@@0x47eef383
lrwxr-xr-x  1 root  wheel  Mar 30 01:24 crater.20080330 -> crater@@0x47ef4e29
-rw-r--r--  2 root  wheel  Mar 30 01:24 crater.log

    The problem is that if I do this:

    diff -r crater.20080329/var/log crater.20080330/var/log

    Diff just returns without actually diffing anything.  The reason is
    because diff checks st_ino and st_dev and believes the directories/files
    to be identical because they match.

    I considered munging the inode number for historical accesses, but
    that would seriously break NFS exports which try to access historical
    files and directories.  Right now NFS *is* able to distinguish between
    the two because NFS handles are 128-bit-wide entities, so I can encode
    the as-of transaction id as part of the filehandle.  But userland
    programs only have access to a 64-bit-wide inode so userland still
    believes the files to be identical.

    st_dev is only 32 bits, carefully munging it is an option if we
    could figure out a way to do it, but I'd rather not.

    I am considering using st_gen but then we'd have to patch third
    party software to test st_gen along with everything else.  This may
    be the only workable solution, though, and only a few programs would
    need to be patched.  st_gen is only 32 bits but it would solve the
    problem as we would be able to use all 32 bits.

    If anyone has any bright ideas, including 'leave it alone', I'm all
    ears.

						-Matt





From justin at shiningsilence.com  Mon Mar 31 10:40:42 2008
From: justin at shiningsilence.com (Justin C. Sherrill)
Date: Mon, 31 Mar 2008 10:40:42 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: SoC student applications due by 5PM PDT tomorrow
In-Reply-To: <1942.192.168.0.242.1206930479.squirrel@www.shiningsilence.com>
Message-ID: <11892.67.108.184.175.1206984967.squirrel@www.shiningsilence.com>

On Sun, March 30, 2008 10:27 pm, Justin C. Sherrill wrote:
> SoC students:
>
> If you have an application to submit for DragonFly/Summer of Code, please
> do so by 17:00 Pacific time on the 31st - that's tomorrow, at least for
> me.

The deadline for student proposals has been extended to April 7th; all
other dates move forward one week to acommodate.

This is a good time to update existing applications or submit new ones. 
Talk to your (potential) mentors if you are curious.






From nthery at gmail.com  Mon Mar 31 11:29:49 2008
From: nthery at gmail.com (Nicolas Thery)
Date: Mon, 31 Mar 2008 11:29:49 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
Message-ID: <64fc43b0803311126na7d0b27obaa9d35bac6d32ee@mail.gmail.com>

Hello,

Now that the release is over, I'll try to get rid of zones and migrate
allocations to objcache.

Here is a 1st patch that migrate struct proc.  I'll commit it in a
couple of days if nobody objects.

I'm also implementing a way to monitor objcache statistics.  So far,
I've hacked sth similar to
sysctl vm.zone: stats are returned in one giant string, one line per
cache.  That's simple but ugly and hard to read because there are
quite a few stats per cache.

So I'm thinking about implementing a small tool, ocstat, that extracts
stats from sysctl the way ps(1) does (thru libkvm iirc) and formats it
in various ways.  What do you think?

Cheers,
Nicolas

Index: src2/sys/kern/kern_exit.c
===================================================================
--- src2.orig/sys/kern/kern_exit.c	2008-03-31 08:05:59.139796000 +0200
+++ src2/sys/kern/kern_exit.c	2008-03-31 10:31:39.000000000 +0200
@@ -834,7 +834,7 @@ loop:
 			}

 			vm_waitproc(p);
-			zfree(proc_zone, p);
+			objcache_put(proc_cache, p);
 			nprocs--;
 			return (0);
 		}
Index: src2/sys/kern/kern_proc.c
===================================================================
--- src2.orig/sys/kern/kern_proc.c	2008-03-31 08:05:59.139918000 +0200
+++ src2/sys/kern/kern_proc.c	2008-03-31 10:31:39.000000000 +0200
@@ -84,7 +84,7 @@ u_long pgrphash;
 struct proclist allproc;
 struct proclist zombproc;
 struct spinlock allproc_spin;
-vm_zone_t proc_zone;
+struct objcache* proc_cache;
 vm_zone_t lwp_zone;
 vm_zone_t thread_zone;

@@ -131,7 +131,7 @@ procinit(void)
 	spin_init(&allproc_spin);
 	pidhashtbl = hashinit(maxproc / 4, M_PROC, &pidhash);
 	pgrphashtbl = hashinit(maxproc / 4, M_PROC, &pgrphash);
-	proc_zone = zinit("PROC", sizeof (struct proc), 0, 0, 5);
+	proc_cache = objcache_create_simple(M_PROC, sizeof(struct proc));
 	lwp_zone = zinit("LWP", sizeof (struct lwp), 0, 0, 5);
 	thread_zone = zinit("THREAD", sizeof (struct thread), 0, 0, 5);
 	uihashinit();
Index: src2/sys/sys/proc.h
===================================================================
--- src2.orig/sys/sys/proc.h	2008-03-31 08:05:59.140325000 +0200
+++ src2/sys/sys/proc.h	2008-03-31 10:31:39.000000000 +0200
@@ -473,7 +473,7 @@ struct proc *zpfind (pid_t);	/* Find zom
 struct vm_zone;
 struct globaldata;
 struct lwp_params;
-extern struct vm_zone *proc_zone;
+extern struct objcache *proc_cache;
 extern struct vm_zone *lwp_zone;

 int	enterpgrp (struct proc *p, pid_t pgid, int mksess);
Index: src2/sys/kern/kern_fork.c
===================================================================
--- src2.orig/sys/kern/kern_fork.c	2008-03-31 08:05:59.140042000 +0200
+++ src2/sys/kern/kern_fork.c	2008-03-31 10:31:39.000000000 +0200
@@ -332,7 +332,7 @@ fork1(struct lwp *lp1, int flags, struct
 	}

 	/* Allocate new proc. */
-	p2 = zalloc(proc_zone);
+	p2 = objcache_get(proc_cache, M_WAITOK);
 	bzero(p2, sizeof(*p2));

 	/*




From hsu at dragonflybsd.org  Mon Mar 31 11:44:34 2008
From: hsu at dragonflybsd.org (Jeffrey Hsu)
Date: Mon, 31 Mar 2008 11:44:34 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <64fc43b0803311126na7d0b27obaa9d35bac6d32ee@mail.gmail.com>
Message-ID: <200803311841.m2VIfQAI007579@nlpi001.prodigy.net>

The object cache is not a general-purpose memory allocator.  It's a cache of
pre-initialized objects.  Are the significant portions of the proc structure
that can be restored to initialized state on object puts?  If not, it's best
to just use a general-purpose memory allocator.

								Jeffrey




From corecode at fs.ei.tum.de  Mon Mar 31 12:07:02 2008
From: corecode at fs.ei.tum.de (Simon 'corecode' Schubert)
Date: Mon, 31 Mar 2008 12:07:02 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <200803311841.m2VIfQAI007579@nlpi001.prodigy.net>
Message-ID: <47F1357B.1070302@fs.ei.tum.de>

Jeffrey Hsu wrote:
> The object cache is not a general-purpose memory allocator.  It's a cache of
> pre-initialized objects.  Are the significant portions of the proc structure
> that can be restored to initialized state on object puts?  If not, it's best
> to just use a general-purpose memory allocator.

Why?  What's the loss if we use the object cache to allocate struct procs?

cheers
  simon

Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00006.pgp
Type: application/octet-stream
Size: 252 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080331/a4a24314/attachment-0020.obj>

From nthery at gmail.com  Mon Mar 31 12:17:03 2008
From: nthery at gmail.com (Nicolas Thery)
Date: Mon, 31 Mar 2008 12:17:03 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <nthery@gmail.com>
Message-ID: <64fc43b0803311214u7da6bbb8xaf971de1a80e7258@mail.gmail.com>

2008/3/31, Jeffrey Hsu <hsu at dragonflybsd.org>:
> The object cache is not a general-purpose memory allocator.  It's a cache of
>  pre-initialized objects.  Are the significant portions of the proc structure
>  that can be restored to initialized state on object puts?  If not, it's best
>  to just use a general-purpose memory allocator.

Well, I haven't checked this yet.  I planned to do this in a second
step after getting rid of zones.

I thought that even without  the pre-initialization part, objcache has
the advantage
of pre-allocating set of objects (as zones) and is additionally
mp-safe (contrary to zones and, granted, as malloc()).   The latter
may be interesting as we talk of improving MP support.

Cheers,
Nicolas




From dillon at apollo.backplane.com  Mon Mar 31 12:23:40 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Mon, 31 Mar 2008 12:23:40 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <200803311841.m2VIfQAI007579@nlpi001.prodigy.net>
Message-ID: <200803311921.m2VJLITB027669@apollo.backplane.com>

    I both agree and disagree with Jeff.  I think the only *disadvantage*
    to using objcache for struct proc is that objcache must cache a minimum
    number of free structures to be efficient so the overall kernel memory
    use would be a bit greater verses uses kmalloc().  But I agree with Jeff
    in that objcache's biggest advantage is that you can keep structural state
    intact and struct proc might not be a good candidate (yet).

    What I suggest is that you convert struct proc from zone to kmalloc
    first, and then look into a possible objcache adaptation.  kmalloc
    is not slow.. it's a very fast allocator.  Objcache is probably a tad
    faster but not by much.  Where objcache really wins is in not having
    to completey reinitialize the allocated structures.

    Over the years I've removed (I think) all the dependancies on requiring
    the proc structure to be in stable memory so I believe it can be moved to
    kmalloc/objcache now without any major pain.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>




From corecode at fs.ei.tum.de  Mon Mar 31 12:37:40 2008
From: corecode at fs.ei.tum.de (Simon 'corecode' Schubert)
Date: Mon, 31 Mar 2008 12:37:40 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: SoC student applications due by 5PM PDT tomorrow
In-Reply-To: <1942.192.168.0.242.1206930479.squirrel@www.shiningsilence.com>
Message-ID: <47F13CDA.6010703@fs.ei.tum.de>

Justin C. Sherrill wrote:
> On Sun, March 30, 2008 10:27 pm, Justin C. Sherrill wrote:
>> SoC students:
>>
>> If you have an application to submit for DragonFly/Summer of Code, please
>> do so by 17:00 Pacific time on the 31st - that's tomorrow, at least for
>> me.
> The deadline for student proposals has been extended to April 7th; all
> other dates move forward one week to acommodate.

This is very good.

Some more ideas for eager students (we want to keep the ratio, right?):

Enhance the FreeBSD/DragonFly sound infrastructure to support surround
sound/multichannel output.

Update sound drivers to support S/PDIF output.

Make the sound infrastructure OSSv4 compatible (there was a SoC at
FreeBSD last year or so)


of course only if it doesn't exist already :)

cheers
  simon


Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00007.pgp
Type: application/octet-stream
Size: 252 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080331/6da61cff/attachment-0020.obj>

From corecode at fs.ei.tum.de  Mon Mar 31 12:41:30 2008
From: corecode at fs.ei.tum.de (Simon 'corecode' Schubert)
Date: Mon, 31 Mar 2008 12:41:30 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <200803311841.m2VIfQAI007579@nlpi001.prodigy.net>
Message-ID: <47F13DE4.10205@fs.ei.tum.de>

Matthew Dillon wrote:
>     What I suggest is that you convert struct proc from zone to kmalloc
>     first, and then look into a possible objcache adaptation.  kmalloc
>     is not slow.. it's a very fast allocator.  Objcache is probably a tad
>     faster but not by much.  Where objcache really wins is in not having
>     to completey reinitialize the allocated structures.

Could we please not move to kmalloc, but instead try to move all fast
path allocations to objcache?  I don't like the idea of allocating
everything with kmalloc.  Caching struct procs is not a bad thing itself.

cheers
  simon


Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00008.pgp
Type: application/octet-stream
Size: 252 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080331/ac328c08/attachment-0020.obj>

From hsu at FreeBSD.org  Mon Mar 31 12:59:05 2008
From: hsu at FreeBSD.org (Jeffrey Hsu)
Date: Mon, 31 Mar 2008 12:59:05 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <47F1357B.1070302@fs.ei.tum.de>
Message-ID: <200803311920.m2VJK5Ln018015@nlpi015.prodigy.net>

The object cache sits on top of a general-purpose memory allocator such
as kmalloc or zalloc and provides pre-initialized object caching functionality.
If you're not going to use the object caching functionality, you can just
call the underlying memory allocator directly.

							Jeffrey




From dillon at apollo.backplane.com  Mon Mar 31 16:17:19 2008
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Mon, 31 Mar 2008 16:17:19 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <200803311841.m2VIfQAI007579@nlpi001.prodigy.net>
Message-ID: <200803312311.m2VNBumd029866@apollo.backplane.com>

:Could we please not move to kmalloc, but instead try to move all fast
:path allocations to objcache?  I don't like the idea of allocating
:everything with kmalloc.  Caching struct procs is not a bad thing itself.=
:
:
:cheers
:  simon

    I will state for the record that I'm fine with either objcache or
    kmalloc.  I agree with Jeff that using objcache for struct proc
    probably isn't necessary but I also agree that it would not hurt either,
    and if the intent is to optimize the initialization of the proc
    structure in the future then moving to objcache now would save us
    from having to do it later.

    So whichever method Nicolas wants to use is fine with me.

						-Matt




From hsu at dragonflybsd.org  Mon Mar 31 19:22:47 2008
From: hsu at dragonflybsd.org (Jeffrey Hsu)
Date: Mon, 31 Mar 2008 19:22:47 -0700 (PDT)	(envelope-from kernel-errors@crater.dragonflybsd.org)
Subject: migrating proc from zone to objcache
In-Reply-To: <64fc43b0803311214u7da6bbb8xaf971de1a80e7258@mail.gmail.com>
Message-ID: <200804010218.m312IVUq003624@nlpi043.prodigy.net>

  >> Are there significant portions of the proc structure
  >> that can be restored to initialized state on object puts?

  > I planned to do this in a second step after getting rid of zones.

I'll all in favor of making more use of caching pre-initialized objects, so
if this is your objective, then please go ahead.  It's just that I'd convert
over to the object cache in one step.

  > I thought that even without  the pre-initialization part, objcache has
  > the advantage of pre-allocating set of objects (as zones) and is additionally
  > mp-safe (contrary to zones and, granted, as malloc()).

Well, the zone allocator is MP-safe.  It's not hard to lock up the places that
manipulate the linked-list of free items. Look for uses of the zlock field.

								Jeffrey