From gausus at gausus.net  Tue Sep  1 14:35:58 2009
From: gausus at gausus.net (Maciej Jan Broniarz)
Date: Tue Sep  1 14:36:05 2009
Subject: zfs on gmirror slice
Message-ID: <a7454e2f0909010704g2fb27216hacb3ffd2cae5594c@mail.gmail.com>

Hi,

Is is a bad ida to create a zfs pool from a gmirrored slice?
zpool create tank /dev/mirror/gm0s1g works fine, but after the reboot
the filesystem failes consistency check.

Regards,
mjb


-- 
[ -----< Maciej Jan Broniarz || gausus@gausus.net >------ ]
| Siamo qui \ sotto la stessa luce \ sotto la sua croce \ |
| cantando ad una voce \ E l'Emmanuel Emmanuel, Emmanuel, |
[ ---------------< E l'Emmanuel, Emmanuel >-------------- ]
From fjwcash at gmail.com  Tue Sep  1 15:32:37 2009
From: fjwcash at gmail.com (Freddie Cash)
Date: Tue Sep  1 15:32:44 2009
Subject: zfs on gmirror slice
In-Reply-To: <a7454e2f0909010704g2fb27216hacb3ffd2cae5594c@mail.gmail.com>
References: <a7454e2f0909010704g2fb27216hacb3ffd2cae5594c@mail.gmail.com>
Message-ID: <b269bc570909010832s44cd4eb2ib612db6fabc3bf2d@mail.gmail.com>

On Tue, Sep 1, 2009 at 7:04 AM, Maciej Jan Broniarz <gausus@gausus.net>wrote:

> Is is a bad ida to create a zfs pool from a gmirrored slice?
> zpool create tank /dev/mirror/gm0s1g works fine, but after the reboot
> the filesystem failes consistency check.
>
> You could, but the question is ... why would you?

ZFS includes support for RAID0 (stripe), RAID1 (mirroring), RAID5 and RAID6
(raidz1/raidz2), and (soon in OpenSolaris) RAID7 (raidz3).  Why would you
want to build a pool out of devices that are already RAID'd together?

Just use the bare disks, or slices on disks, or partitions even.

-- 
Freddie Cash
fjwcash@gmail.com
From petefrench at ticketswitch.com  Tue Sep  1 15:56:25 2009
From: petefrench at ticketswitch.com (Pete French)
Date: Tue Sep  1 15:56:32 2009
Subject: zfs on gmirror slice
In-Reply-To: <b269bc570909010832s44cd4eb2ib612db6fabc3bf2d@mail.gmail.com>
Message-ID: <E1MiViS-0004N3-U2@dilbert.ticketswitch.com>

> ZFS includes support for RAID0 (stripe), RAID1 (mirroring), RAID5 and RAID6
> (raidz1/raidz2), and (soon in OpenSolaris) RAID7 (raidz3).  Why would you
> want to build a pool out of devices that are already RAID'd together?

Because gmirror type RAIDing is more appropriate for your application
than ZFS RAID ? I am not the original poster, but I can easily
see why one would want to do do this. For example making a gmirror
of a local drive and a remote drive - you can ask gmirror to prefer
reads on the local disc, but there isn't a way to specify that
in ZFS that I know of. Also gmirror on top of ggate behaves nicely if
the remote drive fails. ZFS does not behave nicely at all - or it didn't
when I ran tests. I havent tried on the latest version I admit.

But ZFS as a filesystem still has many significant advantages, so
runnng it on top of gmirror is actually a worthwhile thing to do.

-pete.
From mahlerrd at yahoo.com  Tue Sep  1 16:01:05 2009
From: mahlerrd at yahoo.com (Richard Mahlerwein)
Date: Tue Sep  1 16:01:13 2009
Subject: Fatal Trap 12 in various processes always at address 0x3030313a
In-Reply-To: <20090830203732.L24691@ury.york.ac.uk>
Message-ID: <165377.50875.qm@web51011.mail.re2.yahoo.com>

--- On Sun, 8/30/09, Gavin Atkinson <gavin@FreeBSD.org> wrote:

> From: Gavin Atkinson <gavin@FreeBSD.org>
> Subject: Re: Fatal Trap 12 in various processes always at address 0x3030313a
> To: "Richard Mahlerwein" <mahlerrd@yahoo.com>
> Cc: "FreeBSD-Stable" <freebsd-stable@FreeBSD.org>
> Date: Sunday, August 30, 2009, 3:47 PM
> On Sat, 29 Aug 2009, Richard
> Mahlerwein wrote:
> 
> > (Sorry, update to subject to be <something>)
> > 
> > 3 weeks ago:
> > I upgraded from 7.1-PRELEASE to -stable and all seemed
> fine
> > until I rebooted out of single user mode after doing
> make
> > installworld and mergemaster.? At that point, near
> the
> > end of the boot sequence I got a core dump,
> apparently
> > triggered by devd.
> > 
> > ****
> > Fatal trap 12: page fault while in kernel mode.
> > cpu id = 0; apic id = 00
> > fault virtual address = 0x3030313a
> > fault code = supervisor write, page not present
> > [snip]
> > current process = 355 (devd)
> > ****
> > 
> > [snip]
> > Does anyone have a further recommendation on what to
> do,
> > try, test or change?
> 
> Firstly, please set up a dump partition by adding
> 'dumpdev="AUTO"' to your rc.conf.
> 
> Then, can you compile in the kernel debugger (options KGB /
> options DDB) and when this happens again, please obtain a
> backtrace from the debugger with the "bt" command.?
> Then, give the "show registers" command so that we can
> establish which register is pointing to the odd address.
> Finally, issue the "call doadump()" command to hopefully
> save a copy of the kernel dump for later analysis.
> 
> Thanks,
> 
> Gavin

No problem, but for future reference by others reading this thread, the handbook says KGB should be KDB, which is what I'm enabling in the kernel config.  DDB is fine.

http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug-online-ddb.html



      
From gausus at gausus.net  Tue Sep  1 16:04:14 2009
From: gausus at gausus.net (Maciej Jan Broniarz)
Date: Tue Sep  1 16:04:22 2009
Subject: zfs on gmirror slice
In-Reply-To: <061541E3-F301-46C4-8ECB-5B05854F0EAA@exscape.org>
References: <a7454e2f0909010704g2fb27216hacb3ffd2cae5594c@mail.gmail.com>
	<061541E3-F301-46C4-8ECB-5B05854F0EAA@exscape.org>
Message-ID: <a7454e2f0909010904s224be2ectdd18eb887f4c1311@mail.gmail.com>

2009/9/1 Thomas Backman <serenity@exscape.org>:
> On Sep 1, 2009, at 4:04 PM, Maciej Jan Broniarz wrote:
>
>
> I'm not familiar with gmirror, but it'd be a way better idea to mirror it
> using ZFS if possible - that way you get self-healing and stuff like that,
> which you won't if ZFS doesn't have a mirror/RAIDZ setup, but only sees a
> single slice.
>

I would like to do so. I have to disks (ad4 and ad5). Is it possible
to create two slices on both disks (eg ad4s1 and ad4s2 for ad4).
Then to create gmirror on ad4s1, install freebsd on it so it would
boot from it. Then, after having my system running to create zfs
mirror from ad4s2 and ad5s2?

mjb



-- 
[ -----< Maciej Jan Broniarz || gausus@gausus.net >------ ]
| Siamo qui \ sotto la stessa luce \ sotto la sua croce \ |
| cantando ad una voce \ E l'Emmanuel Emmanuel, Emmanuel, |
[ ---------------< E l'Emmanuel, Emmanuel >-------------- ]
From fjwcash at gmail.com  Tue Sep  1 17:10:28 2009
From: fjwcash at gmail.com (Freddie Cash)
Date: Tue Sep  1 17:10:35 2009
Subject: zfs on gmirror slice
In-Reply-To: <a7454e2f0909010904s224be2ectdd18eb887f4c1311@mail.gmail.com>
References: <a7454e2f0909010704g2fb27216hacb3ffd2cae5594c@mail.gmail.com>
	<061541E3-F301-46C4-8ECB-5B05854F0EAA@exscape.org>
	<a7454e2f0909010904s224be2ectdd18eb887f4c1311@mail.gmail.com>
Message-ID: <b269bc570909011010q2dde51enccfbee3688860aef@mail.gmail.com>

On Tue, Sep 1, 2009 at 9:04 AM, Maciej Jan Broniarz <gausus@gausus.net>wrote:

> 2009/9/1 Thomas Backman <serenity@exscape.org>:
> > On Sep 1, 2009, at 4:04 PM, Maciej Jan Broniarz wrote:
> > I'm not familiar with gmirror, but it'd be a way better idea to mirror it
> > using ZFS if possible - that way you get self-healing and stuff like
> that,
> > which you won't if ZFS doesn't have a mirror/RAIDZ setup, but only sees a
> > single slice.
>
> I would like to do so. I have to disks (ad4 and ad5). Is it possible
> to create two slices on both disks (eg ad4s1 and ad4s2 for ad4).
> Then to create gmirror on ad4s1, install freebsd on it so it would
> boot from it. Then, after having my system running to create zfs
> mirror from ad4s2 and ad5s2?
>
> Yes, this is definitely doable.

You can use entire drives (ad4), single slices (ad4s1), or individual
partitions (ad4s1d) with ZFS.

Create two slices; install to and use s1 on both drives for the gmirror
RAID1; and use s2 on both drives for a ZFS RAID1.

-- 
Freddie Cash
fjwcash@gmail.com
From 000.fbsd at quip.cz  Tue Sep  1 17:10:39 2009
From: 000.fbsd at quip.cz (Miroslav Lachman)
Date: Tue Sep  1 17:10:50 2009
Subject: zfs on gmirror slice
In-Reply-To: <a7454e2f0909010904s224be2ectdd18eb887f4c1311@mail.gmail.com>
References: <a7454e2f0909010704g2fb27216hacb3ffd2cae5594c@mail.gmail.com>	<061541E3-F301-46C4-8ECB-5B05854F0EAA@exscape.org>
	<a7454e2f0909010904s224be2ectdd18eb887f4c1311@mail.gmail.com>
Message-ID: <4A9D558A.9070609@quip.cz>

Maciej Jan Broniarz wrote:
> 2009/9/1 Thomas Backman <serenity@exscape.org>:
> 
>>On Sep 1, 2009, at 4:04 PM, Maciej Jan Broniarz wrote:
>>
>>
>>I'm not familiar with gmirror, but it'd be a way better idea to mirror it
>>using ZFS if possible - that way you get self-healing and stuff like that,
>>which you won't if ZFS doesn't have a mirror/RAIDZ setup, but only sees a
>>single slice.
>>
> 
> 
> I would like to do so. I have to disks (ad4 and ad5). Is it possible
> to create two slices on both disks (eg ad4s1 and ad4s2 for ad4).
> Then to create gmirror on ad4s1, install freebsd on it so it would
> boot from it. Then, after having my system running to create zfs
> mirror from ad4s2 and ad5s2?

Yes, I am using it this way:

root@cage ~/# gmirror status
        Name    Status  Components
mirror/gms1  COMPLETE  ad4s1
                        ad6s1


root@cage ~/# zpool status
   pool: tank
  state: ONLINE
  scrub: none requested
config:

         NAME        STATE     READ WRITE CKSUM
         tank        ONLINE       0     0     0
           mirror    ONLINE       0     0     0
             ad4s2   ONLINE       0     0     0
             ad6s2   ONLINE       0     0     0

errors: No known data errors


root@cage ~/# zpool list
NAME                    SIZE    USED   AVAIL    CAP  HEALTH     ALTROOT
tank                    444G    353G   91.2G    79%  ONLINE     -


gmirror gms1 is for system files, ports etc. zpool (444GB) is for jails

Miroslav Lachman
From v.haisman at sh.cvut.cz  Tue Sep  1 17:13:29 2009
From: v.haisman at sh.cvut.cz (=?UTF-8?B?VsOhY2xhdiBIYWlzbWFu?=)
Date: Tue Sep  1 17:13:36 2009
Subject: GCC -m32 option on FreeBSD/AMD64 7.2
Message-ID: <4A9D561F.5000808@sh.cvut.cz>

Hi,
is C++ + GCC -m32 option officially supported by FreeBSD/AMD64 7.2? I am
getting the following errors for simplest input:

shell::wilx:~/tmp> cat >m32.cxx
#include <iostream>
shell::wilx:~/tmp> g++ -c m32.cxx
shell::wilx:~/tmp> g++ -m32 m32.cxx
In file included from /usr/include/c++/4.2/ext/new_allocator.h:37,
                 from /usr/include/c++/4.2/bits/c++allocator.h:39,
                 from /usr/include/c++/4.2/bits/allocator.h:53,
                 from /usr/include/c++/4.2/memory:54,
                 from /usr/include/c++/4.2/string:48,
                 from /usr/include/c++/4.2/bits/locale_classes.h:47,
                 from /usr/include/c++/4.2/bits/ios_base.h:47,
                 from /usr/include/c++/4.2/ios:48,
                 from /usr/include/c++/4.2/ostream:45,
                 from /usr/include/c++/4.2/iostream:45,
                 from m32.cxx:1:
/usr/include/c++/4.2/new:95: error: 'operator new' takes type 'size_t'
('unsigned int') as first parameter
/usr/include/c++/4.2/new:96: error: 'operator new' takes type 'size_t'
('unsigned int') as first parameter
/usr/include/c++/4.2/new:99: error: 'operator new' takes type 'size_t'
('unsigned int') as first parameter
/usr/include/c++/4.2/new:100: error: 'operator new' takes type 'size_t'
('unsigned int') as first parameter
/usr/include/c++/4.2/new:105: error: 'operator new' takes type 'size_t'
('unsigned int') as first parameter
/usr/include/c++/4.2/new:106: error: 'operator new' takes type 'size_t'
('unsigned int') as first parameter

--
VH

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090901/4ddaf01f/signature.pgp
From serenity at exscape.org  Tue Sep  1 18:26:05 2009
From: serenity at exscape.org (Thomas Backman)
Date: Tue Sep  1 18:26:18 2009
Subject: zfs on gmirror slice
In-Reply-To: <a7454e2f0909010904s224be2ectdd18eb887f4c1311@mail.gmail.com>
References: <a7454e2f0909010704g2fb27216hacb3ffd2cae5594c@mail.gmail.com>
	<061541E3-F301-46C4-8ECB-5B05854F0EAA@exscape.org>
	<a7454e2f0909010904s224be2ectdd18eb887f4c1311@mail.gmail.com>
Message-ID: <05E40037-FDB2-4F6A-B570-8E72ECE1B938@exscape.org>

On Sep 1, 2009, at 6:04 PM, Maciej Jan Broniarz wrote:

> 2009/9/1 Thomas Backman <serenity@exscape.org>:
>> On Sep 1, 2009, at 4:04 PM, Maciej Jan Broniarz wrote:
>>
>>
>> I'm not familiar with gmirror, but it'd be a way better idea to  
>> mirror it
>> using ZFS if possible - that way you get self-healing and stuff  
>> like that,
>> which you won't if ZFS doesn't have a mirror/RAIDZ setup, but only  
>> sees a
>> single slice.
>>
>
> I would like to do so. I have to disks (ad4 and ad5). Is it possible
> to create two slices on both disks (eg ad4s1 and ad4s2 for ad4).
> Then to create gmirror on ad4s1, install freebsd on it so it would
> boot from it. Then, after having my system running to create zfs
> mirror from ad4s2 and ad5s2?
Why not go ZFS all the way? ZFS on root is well supported these days  
(well, not by sysinstall, but it works great if you do it manually) -  
you don't even need UFS /boot anymore.
Again, not familiar with gmirror, but my guess (that will be corrected  
or confirmed by someone ;) is that your way would work too.

Regards,
Thomas
From serenity at exscape.org  Tue Sep  1 18:26:05 2009
From: serenity at exscape.org (Thomas Backman)
Date: Tue Sep  1 18:26:19 2009
Subject: zfs on gmirror slice
In-Reply-To: <a7454e2f0909010704g2fb27216hacb3ffd2cae5594c@mail.gmail.com>
References: <a7454e2f0909010704g2fb27216hacb3ffd2cae5594c@mail.gmail.com>
Message-ID: <061541E3-F301-46C4-8ECB-5B05854F0EAA@exscape.org>

On Sep 1, 2009, at 4:04 PM, Maciej Jan Broniarz wrote:

> Hi,
>
> Is is a bad ida to create a zfs pool from a gmirrored slice?
> zpool create tank /dev/mirror/gm0s1g works fine, but after the reboot
> the filesystem failes consistency check.
>
> Regards,
> mjb
I'm not familiar with gmirror, but it'd be a way better idea to mirror  
it using ZFS if possible - that way you get self-healing and stuff  
like that, which you won't if ZFS doesn't have a mirror/RAIDZ setup,  
but only sees a single slice.

Regards,
Thomas
From mahlerrd at yahoo.com  Tue Sep  1 18:58:27 2009
From: mahlerrd at yahoo.com (Richard Mahlerwein)
Date: Tue Sep  1 18:58:34 2009
Subject: Fatal Trap 12 in various processes always at address 0x3030313a
In-Reply-To: <20090830203732.L24691@ury.york.ac.uk>
Message-ID: <400450.59350.qm@web51010.mail.re2.yahoo.com>

> From: Gavin Atkinson <gavin@FreeBSD.org>
> Subject: Re: Fatal Trap 12 in various processes always at address 0x3030313a
> To: "Richard Mahlerwein" <mahlerrd@yahoo.com>
> Cc: "FreeBSD-Stable" <freebsd-stable@FreeBSD.org>
> Date: Sunday, August 30, 2009, 3:47 PM
> On Sat, 29 Aug 2009, Richard
> Mahlerwein wrote:
> 
>> I upgraded from 7.1-PRELEASE to -stable and all seemed fine
>> until I rebooted out of single user mode after doing make
>> installworld and mergemaster.? At that point, near the
>> end of the boot sequence I got a core dump, apparently
>> triggered by devd.
>> 
>> ****
>> Fatal trap 12: page fault while in kernel mode.
>> cpu id = 0; apic id = 00
>> fault virtual address = 0x3030313a
>> fault code = supervisor write, page not present
>> [snip]
>> current process = 355 (devd)
>> ****

>> Does anyone have a further recommendation on what to do,
>> try, test or change?
> 
> Firstly, please set up a dump partition by adding
> 'dumpdev="AUTO"' to your rc.conf.
> 
> Then, can you compile in the kernel debugger (options KGB /
> options DDB) and when this happens again, please obtain a
> backtrace from the debugger with the "bt" command.?
> Then, give the "show registers" command so that we can
> establish which register is pointing to the odd address.
> Finally, issue the "call" command to hopefully
> save a copy of the kernel dump for later analysis.
> 
> Thanks,
> 
> Gavin

Error at virtual address 0x3030313a
current process 352(sysctl) 

bt says (typing blind, but I think I got it):

Tracing pid 352 tid 100044 td 0xc3378480
sysctl_devctl_disable(c0c80ac0,0,0,d82fcba4,d82fcba4...) at sysctl_devctl_disable+0xaa
sysctl_root(d82fcba4,4,1,d82fcc60,0,...) at sysctl_root+0x187
userland_sysctl(c3378480,d82fcc14,3,0,0,...) at userland_sysctl+0x1c4
__sysctl(c3378480,d82fccfc,18,d82fcd38,d82fcd2c,...) at __sysctl_0x94
syscall(d82fcd38) at syscall_0x335
Xint0x80_syscall() at Xint0x80_syscall_0x20
--- syscall (202,FreeBSD ELF32, __sysctl, eip = 0x2815beaf, esp=0xbfbfe55c, epb = 0xbfbfe588 ---

show registers :

cs 0x20
ds 0xc1470028
es 0xc1470028
fs 0xc1460008
ss 0x28
eax 0xc0cea0cc devsoftc_0x4c
ecx 0
edx 0x30303132
ebx 0xc3181350
esp 0xd82fcb34
ebp 0xd82fcb54
esi 0
edi 0
eip 0xc08218da sysctl_devctl_disable+0xaa
efl 0x10202
sysctl_devctl_disable+0xaa: movl %eax,0x8(%edx)

I hope that tells someone on the list way more than it tells me.

Thanks again for all the help so far!

-Rich


      
From mahlerrd at yahoo.com  Tue Sep  1 19:47:47 2009
From: mahlerrd at yahoo.com (Richard Mahlerwein)
Date: Tue Sep  1 19:47:54 2009
Subject: Fatal Trap 12 in various processes always at address 0x3030313a
In-Reply-To: <400450.59350.qm@web51010.mail.re2.yahoo.com>
Message-ID: <79047.96509.qm@web51007.mail.re2.yahoo.com>

From: Richard Mahlerwein <mahlerrd@yahoo.com>
Subject: Re: Fatal Trap 12 in various processes always at address 0x3030313a
To: "FreeBSD-Stable" <freebsd-stable@freebsd.org>
Date: Tuesday, September 1, 2009, 2:58 PM

> From: Gavin Atkinson <gavin@FreeBSD.org>
> Subject: Re: Fatal Trap 12 in various processes always at address 0x3030313a
> To: "Richard Mahlerwein" <mahlerrd@yahoo.com>
> Cc: "FreeBSD-Stable" <freebsd-stable@FreeBSD.org>
> Date: Sunday, August 30, 2009, 3:47 PM
> On Sat, 29 Aug 2009, Richard
> Mahlerwein wrote:
> 
>> I upgraded from 7.1-PRELEASE to -stable and all seemed fine
>> until I rebooted out of single user mode after doing make
>> installworld and mergemaster.? At that point, near the
>> end of the boot sequence I got a core dump, apparently
>> triggered by devd.
>> 
>> ****
>> Fatal trap 12: page fault while in kernel mode.
>> cpu id = 0; apic id = 00
>> fault virtual address = 0x3030313a
>> fault code = supervisor write, page not present
>> [snip]
>> current process = 355 (devd)
>> ****

>> Does anyone have a further recommendation on what to do,
>> try, test or change?
> 
> Firstly, please set up a dump partition by adding
> 'dumpdev="AUTO"' to your rc.conf.
> 
> Then, can you compile in the kernel debugger (options KGB /
> options DDB) and when this happens again, please obtain a
> backtrace from the debugger with the "bt" command.?
> Then, give the "show registers" command so that we can
> establish which register is pointing to the odd address.
> Finally, issue the "call" command to hopefully
> save a copy of the kernel dump for later analysis.
> 
> Thanks,
> 
> Gavin

Error at virtual address 0x3030313a
current process 352(sysctl) 

bt says (typing blind, but I think I got it):

Tracing pid 352 tid 100044 td 0xc3378480
sysctl_devctl_disable(c0c80ac0,0,0,d82fcba4,d82fcba4...) at sysctl_devctl_disable+0xaa
sysctl_root(d82fcba4,4,1,d82fcc60,0,...) at sysctl_root+0x187
userland_sysctl(c3378480,d82fcc14,3,0,0,...) at userland_sysctl+0x1c4
__sysctl(c3378480,d82fccfc,18,d82fcd38,d82fcd2c,...) at __sysctl_0x94
syscall(d82fcd38) at syscall_0x335
Xint0x80_syscall() at Xint0x80_syscall_0x20
--- syscall (202,FreeBSD ELF32, __sysctl, eip = 0x2815beaf, esp=0xbfbfe55c, epb = 0xbfbfe588 ---

show registers :

cs 0x20
ds 0xc1470028
es 0xc1470028
fs 0xc1460008
ss 0x28
eax 0xc0cea0cc devsoftc_0x4c
ecx 0
edx 0x30303132
ebx 0xc3181350
esp 0xd82fcb34
ebp 0xd82fcb54
esi 0
edi 0
eip 0xc08218da sysctl_devctl_disable+0xaa
efl 0x10202
sysctl_devctl_disable+0xaa: movl %eax,0x8(%edx)

I hope that tells someone on the list way more than it tells me.

Thanks again for all the help so far!

-Rich
I hope changing back to non-text (to get around some messed-up-ed-ness I've been having in my Yahoo account) won't mess
 this up too bad.? Please don't yell at me if it does - just a polite mention will do.? :)

I
changed devd_enable="NO" to devd_enable="YES" in rc.conf, and get THIS
error (which is back to being almost the same as the original one I got
on the first attempt at a new kernel)

vault virtual address 0x3030313a
fault code = supervisor write, page not present
instruction pointer = 0x20:0xc08216dc
stack pointer = 0x28: 0xd8311b70
frame pointer = 0x28:0xd8300b8c
code segment = base 0x0, limit 0xfffff, type 0x1b
=DPL 0, pres 1, def32 1, gran 1
processor eflags = interrupt enabled, resume, IOPL = 0
current process -= 255 (devd)
[thread pid 355 tid 100045 ]
stopped at devread+0x12c: movl %eax,0x8(%edx)

bt says:
Tracing pid 355 tid 100045 tc 0xc3378240
devread(c30df400,d8300c60,0,c3434564,d8300bd8,...) at devread+0x12c
giant_read(c30df400,d8300c60,0,0,400,...) at giant_read+0x89
devfs_read_f(c33adb48,d8300c60,c3071300,0,c33adb48,...) at
 dofileread+0x96
kern_readv(c3378240,3,d8300c60,bfbfe9f7,400,...) at kern_readv+0x58
read(c3378240,d8300cfc,c,80000000,369e99,...) at read+0x4f
syscall(d8300d38) at syscall_0x335
Xint0x80_syscall() at Xint0x80_syscall_0x20
--- syscall (3, FreeBSD ELF32, read), eip - 0x8086c7f, esp = 0xbfbfe9bc, ebp = 0xbfbfee98 ---

And show registers:
cs=20,ds=d8300028, es=d8300028,fs= d8300008, ss=28, eax=c0cea0cc devsoftc_0x4c
ecx=0x4,,
edx=0x30303132, ebx=oxc3181350, esp=pxd8300b70, ebp=oxd8300b8c,
esi=0xc30df400, edi=0x6, eip=oxc08216dc devread_0x12c, efl=0x10202
devread+0x12c: movl %eax, 0x8(%edx)

I'm
still not quite sure what that's telling me, but is it significant that
it's the same virtual location with a different piece of code loaded
there because of a change in options?? No other change was made, just
changing devd_enable.? I'm going to check loader.conf, too, as someone
else suggested (but at this point, I didn't want to muddy the waters by
changing two things at once).



      
From ml at my.gd  Tue Sep  1 19:53:35 2009
From: ml at my.gd (Major Domo)
Date: Tue Sep  1 19:54:14 2009
Subject: Not getting an IPv6 in a jail
Message-ID: <ff6efe7e0909011230i414b6791k707f5c58383e9b53@mail.gmail.com>

Hello list,


Apologies if this has been discussed already but I searched the web
and the mailing lists and haven't found hints on my problem.

I've got a jail, I assign it a set of IP addresses, and it just won't
take the IP6 I give it.


Uname:
FreeBSD 7.2-STABLE


Sysctl jail MIBs:
security.jail.jail_max_af_ips: 255
security.jail.mount_allowed: 0
security.jail.chflags_allowed: 0
security.jail.allow_raw_sockets: 1
security.jail.enforce_statfs: 2
security.jail.sysvipc_allowed: 0
security.jail.socket_unixiproute_only: 1
security.jail.set_hostname_allowed: 0


/etc/rc.conf settings:
jail_enable="YES"
jail_set_hostname_allow="NO"
jail_list="ns"
jail_ns_interface="lo252"
jail_ns_hostname="[snip]"
jail_ns_ip="192.168.0.252,fe80::c0a8:fc"
jail_ns_rootdir="/var/jail/ns"
jail_ns_devfs_enable="YES"


jls -v:
   JID  Hostname                      Path
        Name                          State
        CPUSetID
        IP Address(es)
    23  [snip]                      /var/jail/ns
                                      ALIVE
        2
        192.168.0.252
        fe80::c0a8:fc


ifconfig lo252 from the host:
lo252: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
        inet 192.168.0.252 netmask 0xffffffff
        inet6 fe80::c0a8:fc%lo252 prefixlen 128 scopeid 0x5


ifconfig from the jail:
re0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=389b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_UCAST,WOL_MCAST,WOL_MAGIC>
        ether 00:e0:f4:19:e9:d2
        media: Ethernet autoselect (100baseTX <full-duplex>)
        status: active
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
pflog0: flags=141<UP,RUNNING,PROMISC> metric 0 mtu 33204
lo252: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
        inet 192.168.0.252 netmask 0xffffffff


ping6 from the host:
PING6(56=40+8+8 bytes) fe80::c0a8:fc%lo252 --> fe80::c0a8:fc%lo252
16 bytes from fe80::c0a8:fc%lo252, icmp_seq=0 hlim=64 time=0.082 ms


I fail to see what could be going wrong :(

Any pointers please ?


Regards
From ivoras at freebsd.org  Tue Sep  1 19:53:56 2009
From: ivoras at freebsd.org (Ivan Voras)
Date: Tue Sep  1 19:54:15 2009
Subject: zfs on gmirror slice
In-Reply-To: <a7454e2f0909010704g2fb27216hacb3ffd2cae5594c@mail.gmail.com>
References: <a7454e2f0909010704g2fb27216hacb3ffd2cae5594c@mail.gmail.com>
Message-ID: <h7ju3u$jf5$1@ger.gmane.org>

Maciej Jan Broniarz wrote:
> Hi,
> 
> Is is a bad ida to create a zfs pool from a gmirrored slice?
> zpool create tank /dev/mirror/gm0s1g works fine, but after the reboot
> the filesystem failes consistency check.

It *should* work. What error(s) do you get?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 259 bytes
Desc: OpenPGP digital signature
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090901/57163c93/signature.pgp
From mahlerrd at yahoo.com  Tue Sep  1 19:55:48 2009
From: mahlerrd at yahoo.com (Richard Mahlerwein)
Date: Tue Sep  1 19:55:55 2009
Subject: Fatal Trap 12 in various processes always at address 0x3030313a
In-Reply-To: <79047.96509.qm@web51007.mail.re2.yahoo.com>
Message-ID: <232414.46191.qm@web51004.mail.re2.yahoo.com>


From: Richard Mahlerwein <mahlerrd@yahoo.com>
Subject: Re: Fatal Trap 12 in various processes always at address 0x3030313a
To: "FreeBSD-Stable" <freebsd-stable@freebsd.org>
Date: Tuesday, September 1, 2009, 2:58 PM

> From: Gavin Atkinson <gavin@FreeBSD.org>
> Subject: Re: Fatal Trap 12 in various processes always at address 0x3030313a
> To: "Richard Mahlerwein" <mahlerrd@yahoo.com>
> Cc: "FreeBSD-Stable" <freebsd-stable@FreeBSD.org>
> Date: Sunday, August 30, 2009, 3:47 PM
> On Sat, 29 Aug 2009, Richard
> Mahlerwein wrote:
> 
>> I upgraded from 7.1-PRELEASE to -stable and all seemed fine
>> until I rebooted out of single user mode after doing make
>> installworld and mergemaster.? At that point, near the
>> end of the boot sequence I got a core dump, apparently
>> triggered by devd.
>> 
>> ****
>> Fatal trap 12: page fault while in kernel mode.
>> cpu id = 0; apic id = 00
>> fault virtual address = 0x3030313a
>> fault code = supervisor write, page not present
>> [snip]
>> current process = 355 (devd)
>> ****

>> Does anyone have a further recommendation on what to do,
>> try, test or change?
> 
> Firstly, please set up a dump partition by adding
> 'dumpdev="AUTO"' to your rc.conf.
> 
> Then, can you compile in the kernel debugger (options KGB /
> options DDB) and when this happens again, please obtain a
> backtrace from the debugger with the "bt" command.?
> Then, give the "show registers" command so that we can
> establish which register is pointing to the odd address.
> Finally, issue the "call" command to hopefully
> save a copy of the kernel dump for later analysis.
> 
> Thanks,
> 
> Gavin

TWO Pieces of information here, and please excuse the repost - darn mailer's making me look like such a noob (not like I need help at that!).? Again, mention it if this screws up the formatting too badly.? Now that I know certain stuff doesn't come across, I have not used it so hopefully this will turn out nicely.

Error at virtual address 0x3030313a
current process 352(sysctl) 

bt says (typing blind, but I think I got it):

Tracing pid 352 tid 100044 td 0xc3378480
sysctl_devctl_disable(c0c80ac0,0,0,d82fcba4,d82fcba4...) at sysctl_devctl_disable+0xaa
sysctl_root(d82fcba4,4,1,d82fcc60,0,...) at sysctl_root+0x187
userland_sysctl(c3378480,d82fcc14,3,0,0,...) at userland_sysctl+0x1c4
__sysctl(c3378480,d82fccfc,18,d82fcd38,d82fcd2c,...) at __sysctl_0x94
syscall(d82fcd38) at syscall_0x335
Xint0x80_syscall() at Xint0x80_syscall_0x20
--- syscall (202,FreeBSD ELF32, __sysctl, eip = 0x2815beaf, esp=0xbfbfe55c, epb = 0xbfbfe588 ---

show registers :

cs 0x20
ds 0xc1470028
es 0xc1470028
fs 0xc1460008
ss 0x28
eax 0xc0cea0cc devsoftc_0x4c
ecx 0
edx 0x30303132
ebx 0xc3181350
esp 0xd82fcb34
ebp 0xd82fcb54
esi 0
edi 0
eip 0xc08218da sysctl_devctl_disable+0xaa
efl 0x10202
sysctl_devctl_disable+0xaa: movl %eax,0x8(%edx)

I hope that tells someone on the list way more than it tells me.

On a hunch, I changed devd_enable="NO" to devd_enable="YES" in rc.conf, and get THIS
error (which is back to being almost the same as the original one I got on the first attempt at a new kernel)

vault virtual address 0x3030313a
fault code = supervisor write, page not present
instruction pointer = 0x20:0xc08216dc
stack pointer = 0x28: 0xd8311b70
frame pointer = 0x28:0xd8300b8c
code segment = base 0x0, limit 0xfffff, type 0x1b
???? = DPL 0, pres 1, def32 1, gran 1
processor eflags = interrupt enabled, resume, IOPL = 0
current process -= 255 (devd)
[thread pid 355 tid 100045 ]
stopped at devread+0x12c: movl %eax,0x8(%edx)

bt says:
Tracing pid 355 tid 100045 tc 0xc3378240
devread(c30df400,d8300c60,0,c3434564,d8300bd8,...) at devread+0x12c
giant_read(c30df400,d8300c60,0,0,400,...) at giant_read+0x89
devfs_read_f(c33adb48,d8300c60,c3071300,0,c33adb48,...) at dofileread+0x96
kern_readv(c3378240,3,d8300c60,bfbfe9f7,400,...) at kern_readv+0x58
read(c3378240,d8300cfc,c,80000000,369e99,...) at read+0x4f
syscall(d8300d38) at syscall_0x335
Xint0x80_syscall() at Xint0x80_syscall_0x20
--- syscall (3, FreeBSD ELF32, read), eip - 0x8086c7f, esp = 0xbfbfe9bc, ebp = 0xbfbfee98 ---

And show registers:
cs=20, ds=d8300028, es=d8300028, fs= d8300008, ss=28, eax=c0cea0cc devsoftc_0x4c
ecx=0x4, edx=0x30303132, ebx=oxc3181350, esp=pxd8300b70, ebp=oxd8300b8c,
esi=0xc30df400, edi=0x6, eip=oxc08216dc devread_0x12c, efl=0x10202
devread+0x12c: movl %eax, 0x8(%edx)

I'm still not quite sure what that's telling me, but is it significant that it's the same virtual location with a different piece of code loaded there because of a change in options?? No other change was made, just changing devd_enable.? I'm going to check loader.conf, too, as someone else suggested (but at this point, I didn't want to muddy the waters by changing two things at once).

Thanks again,
Rich



      
From jhay at meraka.org.za  Tue Sep  1 20:13:49 2009
From: jhay at meraka.org.za (John Hay)
Date: Tue Sep  1 20:13:57 2009
Subject: Not getting an IPv6 in a jail
In-Reply-To: <ff6efe7e0909011230i414b6791k707f5c58383e9b53@mail.gmail.com>
References: <ff6efe7e0909011230i414b6791k707f5c58383e9b53@mail.gmail.com>
Message-ID: <20090901201345.GA42379@zibbi.meraka.csir.co.za>

On Tue, Sep 01, 2009 at 09:30:15PM +0200, Major Domo wrote:
> Hello list,
> 
> 
> Apologies if this has been discussed already but I searched the web
> and the mailing lists and haven't found hints on my problem.
> 
> I've got a jail, I assign it a set of IP addresses, and it just won't
> take the IP6 I give it.
> 
> 
> Uname:
> FreeBSD 7.2-STABLE
> 
> 
> Sysctl jail MIBs:
> security.jail.jail_max_af_ips: 255
> security.jail.mount_allowed: 0
> security.jail.chflags_allowed: 0
> security.jail.allow_raw_sockets: 1
> security.jail.enforce_statfs: 2
> security.jail.sysvipc_allowed: 0
> security.jail.socket_unixiproute_only: 1
> security.jail.set_hostname_allowed: 0
> 
> 
> /etc/rc.conf settings:
> jail_enable="YES"
> jail_set_hostname_allow="NO"
> jail_list="ns"
> jail_ns_interface="lo252"
> jail_ns_hostname="[snip]"
> jail_ns_ip="192.168.0.252,fe80::c0a8:fc"
> jail_ns_rootdir="/var/jail/ns"
> jail_ns_devfs_enable="YES"
> 
> 
> jls -v:
>    JID  Hostname                      Path
>         Name                          State
>         CPUSetID
>         IP Address(es)
>     23  [snip]                      /var/jail/ns
>                                       ALIVE
>         2
>         192.168.0.252
>         fe80::c0a8:fc
> 
> 
> ifconfig lo252 from the host:
> lo252: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
>         inet 192.168.0.252 netmask 0xffffffff
>         inet6 fe80::c0a8:fc%lo252 prefixlen 128 scopeid 0x5
> 
> 
> ifconfig from the jail:
> re0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
>         options=389b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_UCAST,WOL_MCAST,WOL_MAGIC>
>         ether 00:e0:f4:19:e9:d2
>         media: Ethernet autoselect (100baseTX <full-duplex>)
>         status: active
> lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
> pflog0: flags=141<UP,RUNNING,PROMISC> metric 0 mtu 33204
> lo252: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
>         inet 192.168.0.252 netmask 0xffffffff
> 
> 
> ping6 from the host:
> PING6(56=40+8+8 bytes) fe80::c0a8:fc%lo252 --> fe80::c0a8:fc%lo252
> 16 bytes from fe80::c0a8:fc%lo252, icmp_seq=0 hlim=64 time=0.082 ms
> 
> 
> I fail to see what could be going wrong :(
> 
> Any pointers please ?

I have not used jails with link-local addresses, only global addresses
and that works. It looks like you did not specify the whole link-local
address in the jail_*_ip line. You need to add the %interface for a
proper ipv6 link-local address, eg. fe80::c0a8:fc%lo252. Not everything
works with link-local addresses though and jail might be one of them.

John
-- 
John Hay -- jhay@meraka.csir.co.za / jhay@FreeBSD.org
From bzeeb-lists at lists.zabbadoz.net  Tue Sep  1 20:20:07 2009
From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb)
Date: Tue Sep  1 20:20:16 2009
Subject: Not getting an IPv6 in a jail
In-Reply-To: <ff6efe7e0909011230i414b6791k707f5c58383e9b53@mail.gmail.com>
References: <ff6efe7e0909011230i414b6791k707f5c58383e9b53@mail.gmail.com>
Message-ID: <20090901200313.J68375@maildrop.int.zabbadoz.net>

On Tue, 1 Sep 2009, Major Domo wrote:

Hi,

> Apologies if this has been discussed already but I searched the web
> and the mailing lists and haven't found hints on my problem.
>
> I've got a jail, I assign it a set of IP addresses, and it just won't
> take the IP6 I give it.
>
>
> Uname:
> FreeBSD 7.2-STABLE
>
> jail_ns_ip="192.168.0.252,fe80::c0a8:fc"
>
> jls -v:
>   JID  Hostname                      Path
>        Name                          State
>        CPUSetID
>        IP Address(es)
>    23  [snip]                      /var/jail/ns
>                                      ALIVE
>        2
>        192.168.0.252
>        fe80::c0a8:fc
>
>
> ifconfig lo252 from the host:
> lo252: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
>        inet 192.168.0.252 netmask 0xffffffff
>        inet6 fe80::c0a8:fc%lo252 prefixlen 128 scopeid 0x5
>
>
> ifconfig from the jail:
> re0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
>        options=389b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_UCAST,WOL_MCAST,WOL_MAGIC>
>        ether 00:e0:f4:19:e9:d2
>        media: Ethernet autoselect (100baseTX <full-duplex>)
>        status: active
> lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
> pflog0: flags=141<UP,RUNNING,PROMISC> metric 0 mtu 33204
> lo252: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
>        inet 192.168.0.252 netmask 0xffffffff


This is a rather special case.  For link-local addresses you have to
give the scope as well but it won't take the scope with the %lo252
notation but only in the KAME in-kernel syntax I would assume.
Can you try:

jail_ns_ip="192.168.0.252,fe80:5::c0a8:fc"

Note the added 5 in the second group of hex digits.  That five is the
interface index.  I took it from the "scopeid 0x5". In case your
interface index changes you will need to adjust the address.

I cannot say if it'll work but it would be worth a try.

/bz

-- 
Bjoern A. Zeeb           What was I talking about and who are you again?
From ml-SPAM at my.gd  Tue Sep  1 21:46:10 2009
From: ml-SPAM at my.gd (FLEURIOT Damien)
Date: Tue Sep  1 21:46:18 2009
Subject: Not getting an IPv6 in a jail
In-Reply-To: <20090901201345.GA42379@zibbi.meraka.csir.co.za>
References: <ff6efe7e0909011230i414b6791k707f5c58383e9b53@mail.gmail.com>
	<20090901201345.GA42379@zibbi.meraka.csir.co.za>
Message-ID: <20090901212939.GA9713@sd-13813.dedibox.fr>

On Tue, Sep 01, 2009 at 10:13:45PM +0200 or thereabouts, John Hay wrote:
> On Tue, Sep 01, 2009 at 09:30:15PM +0200, Major Domo wrote:
> > Hello list,
> > 
> > 
> > Apologies if this has been discussed already but I searched the web
> > and the mailing lists and haven't found hints on my problem.
> > 
> > I've got a jail, I assign it a set of IP addresses, and it just won't
> > take the IP6 I give it.
> > 
> > 
> > Uname:
> > FreeBSD 7.2-STABLE
> > 
> > 
> > Sysctl jail MIBs:
> > security.jail.jail_max_af_ips: 255
> > security.jail.mount_allowed: 0
> > security.jail.chflags_allowed: 0
> > security.jail.allow_raw_sockets: 1
> > security.jail.enforce_statfs: 2
> > security.jail.sysvipc_allowed: 0
> > security.jail.socket_unixiproute_only: 1
> > security.jail.set_hostname_allowed: 0
> > 
> > 
> > /etc/rc.conf settings:
> > jail_enable="YES"
> > jail_set_hostname_allow="NO"
> > jail_list="ns"
> > jail_ns_interface="lo252"
> > jail_ns_hostname="[snip]"
> > jail_ns_ip="192.168.0.252,fe80::c0a8:fc"
> > jail_ns_rootdir="/var/jail/ns"
> > jail_ns_devfs_enable="YES"
> > 
> > 
> > jls -v:
> >    JID  Hostname                      Path
> >         Name                          State
> >         CPUSetID
> >         IP Address(es)
> >     23  [snip]                      /var/jail/ns
> >                                       ALIVE
> >         2
> >         192.168.0.252
> >         fe80::c0a8:fc
> > 
> > 
> > ifconfig lo252 from the host:
> > lo252: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
> >         inet 192.168.0.252 netmask 0xffffffff
> >         inet6 fe80::c0a8:fc%lo252 prefixlen 128 scopeid 0x5
> > 
> > 
> > ifconfig from the jail:
> > re0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
> >         options=389b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_UCAST,WOL_MCAST,WOL_MAGIC>
> >         ether 00:e0:f4:19:e9:d2
> >         media: Ethernet autoselect (100baseTX <full-duplex>)
> >         status: active
> > lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
> > pflog0: flags=141<UP,RUNNING,PROMISC> metric 0 mtu 33204
> > lo252: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
> >         inet 192.168.0.252 netmask 0xffffffff
> > 
> > 
> > ping6 from the host:
> > PING6(56=40+8+8 bytes) fe80::c0a8:fc%lo252 --> fe80::c0a8:fc%lo252
> > 16 bytes from fe80::c0a8:fc%lo252, icmp_seq=0 hlim=64 time=0.082 ms
> > 
> > 
> > I fail to see what could be going wrong :(
> > 
> > Any pointers please ?
> 
> I have not used jails with link-local addresses, only global addresses
> and that works. It looks like you did not specify the whole link-local
> address in the jail_*_ip line. You need to add the %interface for a
> proper ipv6 link-local address, eg. fe80::c0a8:fc%lo252. Not everything
> works with link-local addresses though and jail might be one of them.
> 
> John
> -- 
> John Hay -- jhay@meraka.csir.co.za / jhay@FreeBSD.org


Thanks for the hint John, I just tried by appending the interface %
and it still won't work any better:

rc.conf:
jail_ns_ip="192.168.0.252,fe80::c0a8:fc%lo252"

jls -v output doesn't change.
ifconfig output within the jail doesn't change.
ifconfig output on the host's lo252 doesn't change.

I'm afraid I don't have spare IP6s to assign to my public interface
so I can't test much more.


--
Damien Fleuriot

From jhay at meraka.org.za  Wed Sep  2 03:52:37 2009
From: jhay at meraka.org.za (John Hay)
Date: Wed Sep  2 03:52:45 2009
Subject: Not getting an IPv6 in a jail
In-Reply-To: <20090901212939.GA9713@sd-13813.dedibox.fr>
References: <ff6efe7e0909011230i414b6791k707f5c58383e9b53@mail.gmail.com>
	<20090901201345.GA42379@zibbi.meraka.csir.co.za>
	<20090901212939.GA9713@sd-13813.dedibox.fr>
Message-ID: <20090902035234.GA77802@zibbi.meraka.csir.co.za>

On Tue, Sep 01, 2009 at 11:29:40PM +0200, FLEURIOT Damien wrote:
> On Tue, Sep 01, 2009 at 10:13:45PM +0200 or thereabouts, John Hay wrote:
> > 
> > I have not used jails with link-local addresses, only global addresses
> > and that works. It looks like you did not specify the whole link-local
> > address in the jail_*_ip line. You need to add the %interface for a
> > proper ipv6 link-local address, eg. fe80::c0a8:fc%lo252. Not everything
> > works with link-local addresses though and jail might be one of them.
> > 
> > John
> > -- 
> > John Hay -- jhay@meraka.csir.co.za / jhay@FreeBSD.org
> 
> 
> Thanks for the hint John, I just tried by appending the interface %
> and it still won't work any better:
> 
> rc.conf:
> jail_ns_ip="192.168.0.252,fe80::c0a8:fc%lo252"
> 
> jls -v output doesn't change.
> ifconfig output within the jail doesn't change.
> ifconfig output on the host's lo252 doesn't change.
> 
> I'm afraid I don't have spare IP6s to assign to my public interface
> so I can't test much more.

You can use site-local (fec0::) or rfc4193 addresses for testing.

John
-- 
John Hay -- jhay@meraka.csir.co.za / jhay@FreeBSD.org
From stark at mapper.nl  Wed Sep  2 07:20:30 2009
From: stark at mapper.nl (Mark Stapper)
Date: Wed Sep  2 07:20:38 2009
Subject: zfs on gmirror slice
In-Reply-To: <4A9D558A.9070609@quip.cz>
References: <a7454e2f0909010704g2fb27216hacb3ffd2cae5594c@mail.gmail.com>	<061541E3-F301-46C4-8ECB-5B05854F0EAA@exscape.org>	<a7454e2f0909010904s224be2ectdd18eb887f4c1311@mail.gmail.com>
	<4A9D558A.9070609@quip.cz>
Message-ID: <4A9E1CB5.6030906@mapper.nl>

Miroslav Lachman wrote:
> Maciej Jan Broniarz wrote:
>> 2009/9/1 Thomas Backman <serenity@exscape.org>:
>>
>>> On Sep 1, 2009, at 4:04 PM, Maciej Jan Broniarz wrote:
>>>
>>>
>>> I'm not familiar with gmirror, but it'd be a way better idea to
>>> mirror it
>>> using ZFS if possible - that way you get self-healing and stuff like
>>> that,
>>> which you won't if ZFS doesn't have a mirror/RAIDZ setup, but only
>>> sees a
>>> single slice.
>>>
>>
>>
>> I would like to do so. I have to disks (ad4 and ad5). Is it possible
>> to create two slices on both disks (eg ad4s1 and ad4s2 for ad4).
>> Then to create gmirror on ad4s1, install freebsd on it so it would
>> boot from it. Then, after having my system running to create zfs
>> mirror from ad4s2 and ad5s2?
>
> Yes, I am using it this way:
>
> root@cage ~/# gmirror status
>        Name    Status  Components
> mirror/gms1  COMPLETE  ad4s1
>                        ad6s1
>
>
> root@cage ~/# zpool status
>   pool: tank
>  state: ONLINE
>  scrub: none requested
> config:
>
>         NAME        STATE     READ WRITE CKSUM
>         tank        ONLINE       0     0     0
>           mirror    ONLINE       0     0     0
>             ad4s2   ONLINE       0     0     0
>             ad6s2   ONLINE       0     0     0
>
> errors: No known data errors
>
>
> root@cage ~/# zpool list
> NAME                    SIZE    USED   AVAIL    CAP  HEALTH     ALTROOT
> tank                    444G    353G   91.2G    79%  ONLINE     -
>
>
> gmirror gms1 is for system files, ports etc. zpool (444GB) is for jails
>
> Miroslav Lachman
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
Hello,

I'm quite surprised by your setup, as you are using two mechanisms to
accomplish the exact same thing: data replication.
If you want two slices of toast do you use a toaster for one, and an
oven for the other?
My advice to you: either use zfs or gmirror to realize redundancy.
Of course, zfs provides far more flexibility then UFS. However, as
mentioned, booting from ZFS isn't something sysinstall can setup for you.
Besides, updating a zfs filesystem which you are running from is next to
impossible. And since ZFS is still under heavy development, you will
want to update your zfs version every now and then.
So, i would recommend setting up gmirror to mirror your whole disks,
install the base system(boot and "world") on a small UFS slice, and use
the rest of the disc as zfs slice.
If you feel comfortable enough running your entire system on zfs, you
could use a mirrored zpool to boot from. Takes a little more efford, but
is more uniform.
Updating zfs will be a pain though. You would have to boot from another
filesystem to be able to update your root filesystem.
If you'll be reinstalling your system, you might want to check out
FreeBSD 8 because zfs boot support is better.
Hope it helps.
Greetz,
Mark


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 259 bytes
Desc: OpenPGP digital signature
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090902/79c30425/signature.pgp
From emikulic at gmail.com  Wed Sep  2 07:44:50 2009
From: emikulic at gmail.com (Emil Mikulic)
Date: Wed Sep  2 07:44:57 2009
Subject: zfs on gmirror slice
In-Reply-To: <4A9E1CB5.6030906@mapper.nl>
References: <a7454e2f0909010704g2fb27216hacb3ffd2cae5594c@mail.gmail.com>
	<061541E3-F301-46C4-8ECB-5B05854F0EAA@exscape.org>
	<a7454e2f0909010904s224be2ectdd18eb887f4c1311@mail.gmail.com>
	<4A9D558A.9070609@quip.cz> <4A9E1CB5.6030906@mapper.nl>
Message-ID: <20090902074445.GA13588@dmr.ath.cx>

On Wed, Sep 02, 2009 at 09:20:21AM +0200, Mark Stapper wrote:
> updating a zfs filesystem which you are running from is next to
> impossible.

[citation needed]  :)

> So, i would recommend setting up gmirror to mirror your whole disks,
> install the base system(boot and "world") on a small UFS slice, and use
> the rest of the disc as zfs slice.

As Thomas Backman pointed out, this means you won't get self-healing.

I don't know if a ZFS mirror performs smarter disk access scheduling
than gmirror.  Someone oughta measure.  ;)

I recommend you (Maciej) do what Freddie Cash said: slice your disks
into two pieces each - a gmirror'd UFS root, and the rest for ZFS.
(or work out how to zfsboot)

--Emil
From kenyon at kenyonralph.com  Wed Sep  2 07:46:14 2009
From: kenyon at kenyonralph.com (Kenyon Ralph)
Date: Wed Sep  2 07:46:29 2009
Subject: zfs on gmirror slice
In-Reply-To: <4A9E1CB5.6030906@mapper.nl>
References: <a7454e2f0909010704g2fb27216hacb3ffd2cae5594c@mail.gmail.com>
	<061541E3-F301-46C4-8ECB-5B05854F0EAA@exscape.org>
	<a7454e2f0909010904s224be2ectdd18eb887f4c1311@mail.gmail.com>
	<4A9D558A.9070609@quip.cz> <4A9E1CB5.6030906@mapper.nl>
Message-ID: <20090902074611.GB7186@kenyonralph.com>

On 2009-09-02T09:20:21+0200, Mark Stapper <stark@mapper.nl> wrote:
> If you feel comfortable enough running your entire system on zfs, you
> could use a mirrored zpool to boot from. Takes a little more efford,
> but is more uniform.

This is what I did recently, made a 3-way ZFS mirror. Here are my notes:
https://kenyonralph.com/wiki/FreeBsdZfsBoot

Kenyon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090902/ace3cd8a/attachment.pgp
From 000.fbsd at quip.cz  Wed Sep  2 08:25:30 2009
From: 000.fbsd at quip.cz (Miroslav Lachman)
Date: Wed Sep  2 08:25:48 2009
Subject: zfs on gmirror slice
In-Reply-To: <4A9E1CB5.6030906@mapper.nl>
References: <a7454e2f0909010704g2fb27216hacb3ffd2cae5594c@mail.gmail.com>	<061541E3-F301-46C4-8ECB-5B05854F0EAA@exscape.org>	<a7454e2f0909010904s224be2ectdd18eb887f4c1311@mail.gmail.com>	<4A9D558A.9070609@quip.cz>
	<4A9E1CB5.6030906@mapper.nl>
Message-ID: <4A9E2BF6.6080803@quip.cz>

Mark Stapper wrote:
> Miroslav Lachman wrote:

[...]

>>Yes, I am using it this way:
>>
>>root@cage ~/# gmirror status
>>       Name    Status  Components
>>mirror/gms1  COMPLETE  ad4s1
>>                       ad6s1
>>
>>
>>root@cage ~/# zpool status
>>  pool: tank
>> state: ONLINE
>> scrub: none requested
>>config:
>>
>>        NAME        STATE     READ WRITE CKSUM
>>        tank        ONLINE       0     0     0
>>          mirror    ONLINE       0     0     0
>>            ad4s2   ONLINE       0     0     0
>>            ad6s2   ONLINE       0     0     0
>>
>>errors: No known data errors
>>
>>
>>root@cage ~/# zpool list
>>NAME                    SIZE    USED   AVAIL    CAP  HEALTH     ALTROOT
>>tank                    444G    353G   91.2G    79%  ONLINE     -
>>
>>
>>gmirror gms1 is for system files, ports etc. zpool (444GB) is for jails
>>
>>Miroslav Lachman
>>_______________________________________________
> 
> Hello,
> 
> I'm quite surprised by your setup, as you are using two mechanisms to
> accomplish the exact same thing: data replication.
> If you want two slices of toast do you use a toaster for one, and an
> oven for the other?
> My advice to you: either use zfs or gmirror to realize redundancy.
> Of course, zfs provides far more flexibility then UFS. However, as
> mentioned, booting from ZFS isn't something sysinstall can setup for you.
> Besides, updating a zfs filesystem which you are running from is next to
> impossible. And since ZFS is still under heavy development, you will
> want to update your zfs version every now and then.
> So, i would recommend setting up gmirror to mirror your whole disks,
> install the base system(boot and "world") on a small UFS slice, and use
> the rest of the disc as zfs slice.

The reason is simple - the machine was installed one year ago, when ZFS 
was more experimental and sometimes with unexpected results and kernel 
panics. It was safer to use UFS for base. And the reason for using 
gmirror for base (small slice) and not for whole drive is 
re-synchronization after panic. Sync of 500GB drives in gmirror takes 
about 2 hours or more if system is under load. Sync of ZFS mirror takes 
seconds - only few files are synchronized, not whole mirror.
ZFS mirror is better to avoid "silent data corruption" on mirrored drives.
And because the setup with gmirror of one slice and ZFS mirror for 
second slice works without problem, I see no reason to do any changes on 
this machine.

> If you feel comfortable enough running your entire system on zfs, you
> could use a mirrored zpool to boot from. Takes a little more efford, but
> is more uniform.
> Updating zfs will be a pain though. You would have to boot from another
> filesystem to be able to update your root filesystem.
> If you'll be reinstalling your system, you might want to check out
> FreeBSD 8 because zfs boot support is better.
> Hope it helps.
> Greetz,
> Mark

I am able to install and run system from ZFS only, but I have no such 
strong feeling to do it. I am using 2GB USB flashdisk with UFS to boot 
and run a system, then 4x 1TB drives in RAIDZ used as storage pool on 
backup server.
And again - ZFS is still experimental and this setup is better for me in 
case when I need to do some recovery or ZFS upgrade. All can be done 
remotelly without a need to boot some LiveCD etc.

It is my ? 0.02, YMMV.

Miroslav Lachman
From stark at mapper.nl  Wed Sep  2 08:27:48 2009
From: stark at mapper.nl (Mark Stapper)
Date: Wed Sep  2 08:27:56 2009
Subject: zfs on gmirror slice
In-Reply-To: <20090902074445.GA13588@dmr.ath.cx>
References: <a7454e2f0909010704g2fb27216hacb3ffd2cae5594c@mail.gmail.com>
	<061541E3-F301-46C4-8ECB-5B05854F0EAA@exscape.org>
	<a7454e2f0909010904s224be2ectdd18eb887f4c1311@mail.gmail.com>
	<4A9D558A.9070609@quip.cz> <4A9E1CB5.6030906@mapper.nl>
	<20090902074445.GA13588@dmr.ath.cx>
Message-ID: <4A9E2C7C.6030904@mapper.nl>

Emil Mikulic wrote:
> On Wed, Sep 02, 2009 at 09:20:21AM +0200, Mark Stapper wrote:
>   
>> updating a zfs filesystem which you are running from is next to
>> impossible.
>>     
>
> [citation needed]  :)
>   
Well, to update your zfs filesystem version, the filesystem is first
unmounted, then updated, and then mounted again.
citation coming up!
# umount /
umount: unmount of / failed: Invalid argument
>   
>> So, i would recommend setting up gmirror to mirror your whole disks,
>> install the base system(boot and "world") on a small UFS slice, and use
>> the rest of the disc as zfs slice.
>>     
>
> As Thomas Backman pointed out, this means you won't get self-healing.
>   
self-healing sounds very nice, but with mirrorring you have data on two
discs, so in that case there no "healing" involved, it's just
checksumming and reading the non-corrupted copy.
From the gmirror manpage: "All operations like failure detection, stale
component detection, rebuild of stale components, etc. are also done
automatically."
This would indicate the same functionality, with a much less fancy name.
However, i have not tested it the way they demonstrate zfs's
"self-healing" property.
I might, if I get the time to run it in a virtual machine one of these
days..
> I don't know if a ZFS mirror performs smarter disk access scheduling
> than gmirror.  Someone oughta measure.  ;)
>   
NCQ should help here, but still, very interesting.
gmirror is fast though. I've even heard it's faster than software
RAID1/ataraid. (not confirmed).
Even if this is true, running zfs on top of gmirror probably isn't
faster then running zfs with a mirrored pool.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 259 bytes
Desc: OpenPGP digital signature
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090902/5e1ec0a5/signature.pgp
From serenity at exscape.org  Wed Sep  2 08:33:59 2009
From: serenity at exscape.org (Thomas Backman)
Date: Wed Sep  2 08:34:06 2009
Subject: zfs on gmirror slice
In-Reply-To: <4A9E2C7C.6030904@mapper.nl>
References: <a7454e2f0909010704g2fb27216hacb3ffd2cae5594c@mail.gmail.com>
	<061541E3-F301-46C4-8ECB-5B05854F0EAA@exscape.org>
	<a7454e2f0909010904s224be2ectdd18eb887f4c1311@mail.gmail.com>
	<4A9D558A.9070609@quip.cz> <4A9E1CB5.6030906@mapper.nl>
	<20090902074445.GA13588@dmr.ath.cx> <4A9E2C7C.6030904@mapper.nl>
Message-ID: <DB79F60C-1F6F-4605-A39C-F916E20796B4@exscape.org>

On Sep 2, 2009, at 10:27 AM, Mark Stapper wrote:

> Emil Mikulic wrote:
>> On Wed, Sep 02, 2009 at 09:20:21AM +0200, Mark Stapper wrote:
>>
>>> updating a zfs filesystem which you are running from is next to
>>> impossible.
>>>
>>
>> [citation needed]  :)
>>
> Well, to update your zfs filesystem version, the filesystem is first
> unmounted, then updated, and then mounted again.
> citation coming up!
> # umount /
> umount: unmount of / failed: Invalid argument
Nothing a LiveCD or something to that regard can't handle. Obviously  
this doesn't work for everyone, but it should for many.

>>
>>> So, i would recommend setting up gmirror to mirror your whole disks,
>>> install the base system(boot and "world") on a small UFS slice,  
>>> and use
>>> the rest of the disc as zfs slice.
>>>
>>
>> As Thomas Backman pointed out, this means you won't get self-healing.
>>
> self-healing sounds very nice, but with mirrorring you have data on  
> two
> discs, so in that case there no "healing" involved, it's just
> checksumming and reading the non-corrupted copy.
> From the gmirror manpage: "All operations like failure detection,  
> stale
> component detection, rebuild of stale components, etc. are also done
> automatically."
> This would indicate the same functionality, with a much less fancy  
> name.
> However, i have not tested it the way they demonstrate zfs's
> "self-healing" property.
> I might, if I get the time to run it in a virtual machine one of these
> days..
If ZFS finds a corrupted copy and a non-corrupted one in a mirrored  
ZFS pool, it will repair the damage so that both copies are valid, so  
yes, self-healing will indeed occur. :)

Regards,
Thomas
From stark at mapper.nl  Wed Sep  2 08:49:29 2009
From: stark at mapper.nl (Mark Stapper)
Date: Wed Sep  2 08:49:36 2009
Subject: zfs on gmirror slice
In-Reply-To: <DB79F60C-1F6F-4605-A39C-F916E20796B4@exscape.org>
References: <a7454e2f0909010704g2fb27216hacb3ffd2cae5594c@mail.gmail.com>
	<061541E3-F301-46C4-8ECB-5B05854F0EAA@exscape.org>
	<a7454e2f0909010904s224be2ectdd18eb887f4c1311@mail.gmail.com>
	<4A9D558A.9070609@quip.cz> <4A9E1CB5.6030906@mapper.nl>
	<20090902074445.GA13588@dmr.ath.cx> <4A9E2C7C.6030904@mapper.nl>
	<DB79F60C-1F6F-4605-A39C-F916E20796B4@exscape.org>
Message-ID: <4A9E3181.9030601@mapper.nl>

Thomas Backman wrote:
> On Sep 2, 2009, at 10:27 AM, Mark Stapper wrote:
>
>>
> Nothing a LiveCD or something to that regard can't handle. Obviously
> this doesn't work for everyone, but it should for many.
Actually it won't because updating zfs comes with updating your world.
After updating you world, you will be running a newer ZFS version then
the one that come with the RELEASE install, hence the need to update
your zfs filesystems. Incidentally, the livefs CD contains the "old" zfs
version. You see where I'm going?

You could, of course, copy the base system to a USB drive, boot from it,
and so sidestep the whole "can't unmount root" problem, but it's hard to
insert a USB device over ssh... ... ...
>> self-healing sounds very nice, but with mirrorring you have data on two
>> discs, so in that case there no "healing" involved, it's just
>> checksumming and reading the non-corrupted copy.
>> From the gmirror manpage: "All operations like failure detection, stale
>> component detection, rebuild of stale components, etc. are also done
>> automatically."
>> This would indicate the same functionality, with a much less fancy name.
>> However, i have not tested it the way they demonstrate zfs's
>> "self-healing" property.
>> I might, if I get the time to run it in a virtual machine one of these
>> days..
> If ZFS finds a corrupted copy and a non-corrupted one in a mirrored
> ZFS pool, it will repair the damage so that both copies are valid, so
> yes, self-healing will indeed occur. :)
I'm feeling Shakespearean again... My point was that I find
"self-healing" too magic sounding. While indeed it means:"Automatic data
error detection and rebuilding" or something along those lines. We don't
call the automatic remapping of bad sectors in HDD's "self-healing" do we?
Alas, I must admit that on file-system level, some "healing" does take
place.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 259 bytes
Desc: OpenPGP digital signature
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090902/c6f1463d/signature.pgp
From ronald-freebsd8 at klop.yi.org  Wed Sep  2 09:18:03 2009
From: ronald-freebsd8 at klop.yi.org (Ronald Klop)
Date: Wed Sep  2 09:18:40 2009
Subject: zfs on gmirror slice
In-Reply-To: <4A9E3181.9030601@mapper.nl>
References: <a7454e2f0909010704g2fb27216hacb3ffd2cae5594c@mail.gmail.com>
	<061541E3-F301-46C4-8ECB-5B05854F0EAA@exscape.org>
	<a7454e2f0909010904s224be2ectdd18eb887f4c1311@mail.gmail.com>
	<4A9D558A.9070609@quip.cz> <4A9E1CB5.6030906@mapper.nl>
	<20090902074445.GA13588@dmr.ath.cx> <4A9E2C7C.6030904@mapper.nl>
	<DB79F60C-1F6F-4605-A39C-F916E20796B4@exscape.org>
	<4A9E3181.9030601@mapper.nl>
Message-ID: <op.uzmhf7ca8527sy@82-170-177-25.ip.telfort.nl>

On Wed, 02 Sep 2009 10:49:05 +0200, Mark Stapper <stark@mapper.nl> wrote:

> Thomas Backman wrote:
>> On Sep 2, 2009, at 10:27 AM, Mark Stapper wrote:
>>
>>>
>> Nothing a LiveCD or something to that regard can't handle. Obviously
>> this doesn't work for everyone, but it should for many.
> Actually it won't because updating zfs comes with updating your world.
> After updating you world, you will be running a newer ZFS version then
> the one that come with the RELEASE install, hence the need to update
> your zfs filesystems. Incidentally, the livefs CD contains the "old" zfs
> version. You see where I'm going?
>
> You could, of course, copy the base system to a USB drive, boot from it,
> and so sidestep the whole "can't unmount root" problem, but it's hard to
> insert a USB device over ssh... ... ...

Hi,

I did this (boot via usb to upgrade zfs /) a couple of months ago and the  
system told me the zfs pool was owned by another machine. How can I handle  
that?

Ronald.
From 000.fbsd at quip.cz  Wed Sep  2 10:29:10 2009
From: 000.fbsd at quip.cz (Miroslav Lachman)
Date: Wed Sep  2 10:29:17 2009
Subject: zfs on gmirror slice
In-Reply-To: <op.uzmhf7ca8527sy@82-170-177-25.ip.telfort.nl>
References: <a7454e2f0909010704g2fb27216hacb3ffd2cae5594c@mail.gmail.com>	<061541E3-F301-46C4-8ECB-5B05854F0EAA@exscape.org>	<a7454e2f0909010904s224be2ectdd18eb887f4c1311@mail.gmail.com>	<4A9D558A.9070609@quip.cz>
	<4A9E1CB5.6030906@mapper.nl>	<20090902074445.GA13588@dmr.ath.cx>
	<4A9E2C7C.6030904@mapper.nl>	<DB79F60C-1F6F-4605-A39C-F916E20796B4@exscape.org>	<4A9E3181.9030601@mapper.nl>
	<op.uzmhf7ca8527sy@82-170-177-25.ip.telfort.nl>
Message-ID: <4A9E48F1.60606@quip.cz>

Ronald Klop wrote:

> On Wed, 02 Sep 2009 10:49:05 +0200, Mark Stapper <stark@mapper.nl> wrote:

[...]

>> You could, of course, copy the base system to a USB drive, boot from it,
>> and so sidestep the whole "can't unmount root" problem, but it's hard to
>> insert a USB device over ssh... ... ...
> 
> 
> Hi,
> 
> I did this (boot via usb to upgrade zfs /) a couple of months ago and 
> the  system told me the zfs pool was owned by another machine. How can I 
> handle  that?

I think zpool export and then zpool import should fix it. See the manpage.

Miroslav Lachman
From oloringr at gmail.com  Wed Sep  2 10:49:58 2009
From: oloringr at gmail.com (Ed Jobs)
Date: Wed Sep  2 10:50:07 2009
Subject: zfs on gmirror slice
In-Reply-To: <4A9E48F1.60606@quip.cz>
References: <a7454e2f0909010704g2fb27216hacb3ffd2cae5594c@mail.gmail.com>
	<op.uzmhf7ca8527sy@82-170-177-25.ip.telfort.nl>
	<4A9E48F1.60606@quip.cz>
Message-ID: <200909021350.25025.oloringr@gmail.com>

On Wednesday 02 September 2009 13:29, Miroslav Lachman wrote:
>
> I think zpool export and then zpool import should fix it. See the manpage.
>

a simple zpool import will list all the pools available that you can import, 
then you can use 
zpool import -f <pool> to import it.

the only problem i found with that, is that on a fixit environment, i had a 
zroot pool mounted as legacy and when i imported it with -f it broke the whole 
thing. some libraries went missing and i couldn't even ls.
i have no idea how, but an opensolaris livecd handled it perfectly. it made 
the proper warnings and when i changed the mountpoints afterwards, all was 
ok.

so mind the "-f" option when importing.

just my 2 cents

-- 
Real programmers don't document. If it was hard to write, it should be hard to 
understand.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090902/ad16fb04/attachment-0001.pgp
From dimitry at andric.com  Wed Sep  2 14:10:10 2009
From: dimitry at andric.com (Dimitry Andric)
Date: Wed Sep  2 14:10:17 2009
Subject: zfs on gmirror slice
In-Reply-To: <4A9E2C7C.6030904@mapper.nl>
References: <a7454e2f0909010704g2fb27216hacb3ffd2cae5594c@mail.gmail.com>	<061541E3-F301-46C4-8ECB-5B05854F0EAA@exscape.org>	<a7454e2f0909010904s224be2ectdd18eb887f4c1311@mail.gmail.com>	<4A9D558A.9070609@quip.cz>
	<4A9E1CB5.6030906@mapper.nl>	<20090902074445.GA13588@dmr.ath.cx>
	<4A9E2C7C.6030904@mapper.nl>
Message-ID: <4A9E7CC3.1090605@andric.com>

On 2009-09-02 10:27, Mark Stapper wrote:
> self-healing sounds very nice, but with mirrorring you have data on two
> discs, so in that case there no "healing" involved, it's just
> checksumming and reading the non-corrupted copy.
> From the gmirror manpage: "All operations like failure detection, stale
> component detection, rebuild of stale components, etc. are also done
> automatically."
> This would indicate the same functionality, with a much less fancy name.

Not really. ZFS can checksum the actual file data, while gmirror can
only detect errors it gets told about by the underlying disk.  E.g. if
the disk silently corrupts data, you will never know about it.

Also, if gmirror needs to resynchronize, it must resynchronize the whole
disk, since it can't detect which specific parts of it were corrupted.
ZFS synchronizes on demand.

There are also some other advantages to ZFS mirroring, see pages 15 and
further of these slides:

http://www.opensolaris.org/os/community/zfs/docs/zfs_last.pdf
From mad at madpilot.net  Wed Sep  2 14:10:27 2009
From: mad at madpilot.net (Guido Falsi)
Date: Wed Sep  2 14:10:34 2009
Subject: zfs on gmirror slice
In-Reply-To: <200909021350.25025.oloringr@gmail.com>
References: <a7454e2f0909010704g2fb27216hacb3ffd2cae5594c@mail.gmail.com>
	<op.uzmhf7ca8527sy@82-170-177-25.ip.telfort.nl>
	<4A9E48F1.60606@quip.cz> <200909021350.25025.oloringr@gmail.com>
Message-ID: <20090902135413.GA29201@megatron.madpilot.net>

On Wed, Sep 02, 2009 at 01:50:24PM +0300, Ed Jobs wrote:
> On Wednesday 02 September 2009 13:29, Miroslav Lachman wrote:
> >
> > I think zpool export and then zpool import should fix it. See the manpage.
> >
> 
> a simple zpool import will list all the pools available that you can import, 
> then you can use 
> zpool import -f <pool> to import it.
> 
> the only problem i found with that, is that on a fixit environment, i had a 
> zroot pool mounted as legacy and when i imported it with -f it broke the whole 
> thing. some libraries went missing and i couldn't even ls.

Most probably you had mountpoint set to system paths (/usr, for
example).

The -R option could help ypu there, so all zfses will be mounted
relative to an alternative root and not overwrite the fixit system
paths. That is a proprietary property and will not be saved to the pool
anyway.

I evn usually set mountpoint=/ for the root zfs when I make zfs
boot systems, works like a charm.

-- 
Guido Falsi <mad@madpilot.net>
From fbsd.multimedia at rachie.is-a-geek.net  Wed Sep  2 14:17:14 2009
From: fbsd.multimedia at rachie.is-a-geek.net (Mel Flynn)
Date: Wed Sep  2 14:17:26 2009
Subject: x11/nvidia-driver cannot obtain EDID under 8.0-BETA3/i386
In-Reply-To: <20090828135029.GA21544@svzserv.kemerovo.su>
References: <20090828135029.GA21544@svzserv.kemerovo.su>
Message-ID: <200909021559.31093.fbsd.multimedia@rachie.is-a-geek.net>

On Friday 28 August 2009 15:50:30 Eugene Grosbein wrote:
> Hi!
>
> Fresh install of 8.0-BETA2 upgraded to 8.0-BETA3 using source,
> x.org installed from fresh ports tree. It cannot read EDID from
> Samsung 959NF CRT monitor. The same time, it can read EDID under 7.2-STABLE
> just fine. I've tried older nvidia-driver-180.60 (downgrading port)
> and current port's version 185.18.29, no change.
>
> (WW) NVIDIA(GPU-0): Unable to read EDID for display device CRT-1

Can't reproduce this with FreeBSD 8.0-BETA2 #10 r196398M both 180.60 and 
185.18.29 driver. World/kernel as of today is building, so I'll report back if 
I can reproduce it then.
Different (laptop) monitor though.
-- 
Mel
From steve at ibctech.ca  Wed Sep  2 15:52:35 2009
From: steve at ibctech.ca (Steve Bertrand)
Date: Wed Sep  2 15:52:42 2009
Subject: Not getting an IPv6 in a jail
In-Reply-To: <20090902035234.GA77802@zibbi.meraka.csir.co.za>
References: <ff6efe7e0909011230i414b6791k707f5c58383e9b53@mail.gmail.com>	<20090901201345.GA42379@zibbi.meraka.csir.co.za>	<20090901212939.GA9713@sd-13813.dedibox.fr>
	<20090902035234.GA77802@zibbi.meraka.csir.co.za>
Message-ID: <4A9E94C5.20209@ibctech.ca>

John Hay wrote:
> On Tue, Sep 01, 2009 at 11:29:40PM +0200, FLEURIOT Damien wrote:
>> On Tue, Sep 01, 2009 at 10:13:45PM +0200 or thereabouts, John Hay wrote:
>>> I have not used jails with link-local addresses, only global addresses
>>> and that works. It looks like you did not specify the whole link-local
>>> address in the jail_*_ip line. You need to add the %interface for a
>>> proper ipv6 link-local address, eg. fe80::c0a8:fc%lo252. Not everything
>>> works with link-local addresses though and jail might be one of them.
>>>
>>> John
>>> -- 
>>> John Hay -- jhay@meraka.csir.co.za / jhay@FreeBSD.org
>>
>> Thanks for the hint John, I just tried by appending the interface %
>> and it still won't work any better:
>>
>> rc.conf:
>> jail_ns_ip="192.168.0.252,fe80::c0a8:fc%lo252"
>>
>> jls -v output doesn't change.
>> ifconfig output within the jail doesn't change.
>> ifconfig output on the host's lo252 doesn't change.
>>
>> I'm afraid I don't have spare IP6s to assign to my public interface
>> so I can't test much more.
> 
> You can use site-local (fec0::) or rfc4193 addresses for testing.

In the event you don't have your own public v6 space (or not enough of
it), you can acquire it for free from the fabulous guys over at
http://he.net

Steve
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3233 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090902/7dd1de34/smime.bin
From ml-SPAM at my.gd  Wed Sep  2 16:04:54 2009
From: ml-SPAM at my.gd (FLEURIOT Damien)
Date: Wed Sep  2 16:05:01 2009
Subject: Not getting an IPv6 in a jail
In-Reply-To: <20090901200313.J68375@maildrop.int.zabbadoz.net>
References: <ff6efe7e0909011230i414b6791k707f5c58383e9b53@mail.gmail.com>
	<20090901200313.J68375@maildrop.int.zabbadoz.net>
Message-ID: <20090902160440.GA28417@sd-13813.dedibox.fr>

On Tue, Sep 01, 2009 at 08:15:24PM +0000 or thereabouts, Bjoern A. Zeeb wrote:
> On Tue, 1 Sep 2009, Major Domo wrote:
> 
> Hi,
> 
> >Apologies if this has been discussed already but I searched the web
> >and the mailing lists and haven't found hints on my problem.
> >
> >I've got a jail, I assign it a set of IP addresses, and it just won't
> >take the IP6 I give it.
> >
> >
> >Uname:
> >FreeBSD 7.2-STABLE
> >
> >jail_ns_ip="192.168.0.252,fe80::c0a8:fc"
> >
> >jls -v:
> >  JID  Hostname                      Path
> >       Name                          State
> >       CPUSetID
> >       IP Address(es)
> >   23  [snip]                      /var/jail/ns
> >                                     ALIVE
> >       2
> >       192.168.0.252
> >       fe80::c0a8:fc
> >
> >
> >ifconfig lo252 from the host:
> >lo252: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
> >       inet 192.168.0.252 netmask 0xffffffff
> >       inet6 fe80::c0a8:fc%lo252 prefixlen 128 scopeid 0x5
> >
> >
> >ifconfig from the jail:
> >re0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
> >       options=389b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_UCAST,WOL_MCAST,WOL_MAGIC>
> >       ether 00:e0:f4:19:e9:d2
> >       media: Ethernet autoselect (100baseTX <full-duplex>)
> >       status: active
> >lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
> >pflog0: flags=141<UP,RUNNING,PROMISC> metric 0 mtu 33204
> >lo252: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
> >       inet 192.168.0.252 netmask 0xffffffff
> 
> 
> This is a rather special case.  For link-local addresses you have to
> give the scope as well but it won't take the scope with the %lo252
> notation but only in the KAME in-kernel syntax I would assume.
> Can you try:
> 
> jail_ns_ip="192.168.0.252,fe80:5::c0a8:fc"
> 
> Note the added 5 in the second group of hex digits.  That five is the
> interface index.  I took it from the "scopeid 0x5". In case your
> interface index changes you will need to adjust the address.
> 
> I cannot say if it'll work but it would be worth a try.
> 
> /bz
> 
> -- 
> Bjoern A. Zeeb           What was I talking about and who are you again?


Hi list, Bjoern, John,


I confirm it is now working with the following line in /etc/rc.conf:
jail_ns_ip="192.168.0.252,fec0:5::df:252"

along with redirections in /etc/pf.conf:
rdr pass log on $ext_if inet proto {tcp,udp} to $ext_if port 53 ->
$lo252_if port 53
rdr pass log on $ext_if inet6 proto {tcp,udp} to $ext_if port 53 ->
$lo252_if port 53


Notice the use of both the interface's index and a site-local ip6
address instead of the old fe80 as suggested.

BIND's now happily running in its jail and responding to public
queries.


Perhaps a small addition to the jails entry in the Handbook to
advise people about the use of IP6 addresses on loopback interfaces
would be warranted ?

I realize how lousy it is to NAT IP6 but my host assigns only 1
IP6 address per server.


Thanks for the help !

Regards

--
Damien
From dougb at FreeBSD.org  Wed Sep  2 16:09:26 2009
From: dougb at FreeBSD.org (Doug Barton)
Date: Wed Sep  2 16:09:33 2009
Subject: Not getting an IPv6 in a jail
In-Reply-To: <20090902160440.GA28417@sd-13813.dedibox.fr>
References: <ff6efe7e0909011230i414b6791k707f5c58383e9b53@mail.gmail.com>	<20090901200313.J68375@maildrop.int.zabbadoz.net>
	<20090902160440.GA28417@sd-13813.dedibox.fr>
Message-ID: <4A9E98AD.1070202@FreeBSD.org>

FLEURIOT Damien wrote:

> BIND's now happily running in its jail and responding to public
> queries.

It's up to you if you choose to do it, but there is no reason to run
BIND in a jail. The chroot feature provided by default by rc.d/named
is quite adequate security.


Doug

-- 

    This .signature sanitized for your protection

From fjwcash at gmail.com  Wed Sep  2 16:40:35 2009
From: fjwcash at gmail.com (Freddie Cash)
Date: Wed Sep  2 16:40:42 2009
Subject: zfs on gmirror slice
In-Reply-To: <4A9E3181.9030601@mapper.nl>
References: <a7454e2f0909010704g2fb27216hacb3ffd2cae5594c@mail.gmail.com>
	<061541E3-F301-46C4-8ECB-5B05854F0EAA@exscape.org>
	<a7454e2f0909010904s224be2ectdd18eb887f4c1311@mail.gmail.com>
	<4A9D558A.9070609@quip.cz> <4A9E1CB5.6030906@mapper.nl>
	<20090902074445.GA13588@dmr.ath.cx> <4A9E2C7C.6030904@mapper.nl>
	<DB79F60C-1F6F-4605-A39C-F916E20796B4@exscape.org>
	<4A9E3181.9030601@mapper.nl>
Message-ID: <b269bc570909020940n6ea2a3a4y1e58d30fe9832b0b@mail.gmail.com>

On Wed, Sep 2, 2009 at 1:49 AM, Mark Stapper <stark@mapper.nl> wrote:

> Thomas Backman wrote:
> > On Sep 2, 2009, at 10:27 AM, Mark Stapper wrote:
>  >>
> > Nothing a LiveCD or something to that regard can't handle. Obviously
> > this doesn't work for everyone, but it should for many.
> Actually it won't because updating zfs comes with updating your world.
> After updating you world, you will be running a newer ZFS version then
> the one that come with the RELEASE install, hence the need to update
> your zfs filesystems. Incidentally, the livefs CD contains the "old" zfs
> version. You see where I'm going?
>

The new version of the ZFS tools (zpool/zfs) will work with older versions
of the on-disk formats (pool and filesystem).  Thus, you can boot into an
8.0 system while using ZFSv6 pool from a 7.2 system.  Upgrading the world
only upgrades the tools, it doesn't upgrade the on-disk format.

Once you *manually* upgrade your filesystems and pools to ZFSv13, then you
can no longer access them on older systems.

Thus, there's no issue.  You can start with a FreeBSD 7.x system running
ZFSv6, upgrade it via buildworld to FreeBSD 8.0, and continue running your
ZFSv6 pool and filesystems.  Sometime in the future, you can then upgrade
the pool and filesystems to ZFSv13, and continue on your merry way.

ZFS provides backward compatibility, and doesn't automatically upgrade your
pools or filesystems.


> > If ZFS finds a corrupted copy and a non-corrupted one in a mirrored
> > ZFS pool, it will repair the damage so that both copies are valid, so
> > yes, self-healing will indeed occur. :)
>


> I'm feeling Shakespearean again... My point was that I find
> "self-healing" too magic sounding. While indeed it means:"Automatic data
> error detection and rebuilding" or something along those lines. We don't
> call the automatic remapping of bad sectors in HDD's "self-healing" do we?
> Alas, I must admit that on file-system level, some "healing" does take
> place.
>

You should read some of the ZFS white papers and blog postings to better
understand what "self-healing" in ZFS is all about.  It's a lot more than
"automatically rebuild arrays" or "automatically re-map bad sectors".  And
it works at the individual file level (possibly the data block level)
instead of the "entire disk" level that gmirror works.

For fun, use dd to zero out some random sectors on a drive that's part of a
gmirror array and a ZFS mirror, and see what happens.  ;)

-- 
Freddie Cash
fjwcash@gmail.com
From besko at msu.edu  Wed Sep  2 16:55:22 2009
From: besko at msu.edu (Lisa Besko)
Date: Wed Sep  2 16:55:31 2009
Subject: zfs won't automount
Message-ID: <4A9EA37B.2020800@msu.edu>

I have a system that has a simple zfs raid 0 volume on it and it will 
now mount when the system boots.  After the system is up I can run 
/etc/rc.d/zfs start and it's fine.  I don't see any errors in the log 
file other than the ZFS is experimental in FreeBSD message.  I'm running 
FreeBSD 7.2 stable.  I have zfs_enable="YES" in the rc.conf file.  Am I 
missing something?

LB
From jb000003 at mr-happy.com  Wed Sep  2 17:28:17 2009
From: jb000003 at mr-happy.com (Jeff Blank)
Date: Wed Sep  2 17:28:29 2009
Subject: zfs on gmirror slice
In-Reply-To: <h7ju3u$jf5$1@ger.gmane.org>
References: <a7454e2f0909010704g2fb27216hacb3ffd2cae5594c@mail.gmail.com>
	<h7ju3u$jf5$1@ger.gmane.org>
Message-ID: <20090902172811.GA1361@mr-happy.com>

On Tue, Sep 01, 2009 at 09:53:28PM +0200, Ivan Voras wrote:
> Maciej Jan Broniarz wrote:
> > Is is a bad ida to create a zfs pool from a gmirrored slice?
> > zpool create tank /dev/mirror/gm0s1g works fine, but after the reboot
> > the filesystem failes consistency check.
> 
> It *should* work. What error(s) do you get?

I'm not the original poster, but I appear to be having similar
problems, though it's a panic rather than a failed consistency check.
I posted about it back in July, see
http://lists.freebsd.org/pipermail/freebsd-stable/2009-July/051167.html

I've since gotten a serial console working (needed to use uart instead
of sio), so I can now provide a backtrace, this from sources around
0600 UTC on 31 Aug.  My gmirror is entire disks (ad6/ad4), and my ZFS
pool/filesystems are still v6, on /dev/mirror/gm0s1d.

Jeff

================================
[...]
WARNING: ZFS is considered to be an experimental feature in FreeBSD.
Timecounters tick every 1.000 msec
ZFS filesystem version 13
ZFS storage pool version 13
ad4: 152587MB <SAMSUNG HE160HJ JF800-24> at ata2-master SATA300
ad6: 152587MB <SAMSUNG HE160HJ JF800-24> at ata3-master SATA300
GEOM_MIRROR: Device mirror/gm0 launched (1/2).
GEOM_MIRROR: Device gm0: rebuilding provider ad4.
acd0: CDROM <PBDS CD-ROM DH-48N1S/BD11> at ata4-master SATA150
acd1: CDRW <TSSTcorp CD-RW/DVD-ROM TS-H493B/D200> at ata5-master SATA150
hdac0: HDA Codec #0: Sigmatel STAC9220
pcm0: <HDA Sigmatel STAC9220 PCM #0 Analog> at cad 0 nid 1 on hdac0
SMP: AP CPU #1 Launched!
Trying to mount root from zfs:zgm0/root


Fatal trap 12: page fault while in kernel mode
cpuid = 1; apic id = 01
fault virtual address   = 0x0
fault code              = supervisor read data, page not present
instruction pointer     = 0x8:0xffffffff80da14fd
stack pointer           = 0x10:0xffffff800001efd0
frame pointer           = 0x10:0xffffff800001f020
code segment            = base 0x0, limit 0xfffff, type 0x1b
                        = DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags        = interrupt enabled, resume, IOPL = 0
current process         = 1 (swapper)
[thread pid 1 tid 100002 ]
Stopped at      vdev_geom_open+0x10d:   movq    (%r12),%rax
db> bt
Tracing pid 1 tid 100002 td 0xffffff000142eab0
vdev_geom_open() at vdev_geom_open+0x10d
vdev_open() at vdev_open+0xa8
vdev_root_open() at vdev_root_open+0x94
vdev_open() at vdev_open+0xa8
spa_load() at spa_load+0x1d2
spa_load() at spa_load+0x461
spa_open_common() at spa_open_common+0x12d
dsl_dir_open_spa() at dsl_dir_open_spa+0x279
dsl_dataset_hold() at dsl_dataset_hold+0x3b
dsl_prop_get() at dsl_prop_get+0x3c
zfs_mount() at zfs_mount+0x264
vfs_donmount() at vfs_donmount+0xdea
kernel_mount() at kernel_mount+0x88
kernel_vmount() at kernel_vmount+0xcb
vfs_mountroot_try() at vfs_mountroot_try+0x10c
vfs_mountroot() at vfs_mountroot+0x32e
start_init() at start_init+0x4d
fork_exit() at fork_exit+0x11e
fork_trampoline() at fork_trampoline+0xe
--- trap 0, rip = 0, rsp = 0xffffff800001fd30, rbp = 0 ---
db> 
From marka at isc.org  Wed Sep  2 23:04:36 2009
From: marka at isc.org (Mark Andrews)
Date: Wed Sep  2 23:04:48 2009
Subject: Not getting an IPv6 in a jail 
In-Reply-To: Your message of "Wed, 02 Sep 2009 18:04:42 +0200."
	<20090902160440.GA28417@sd-13813.dedibox.fr> 
References: <ff6efe7e0909011230i414b6791k707f5c58383e9b53@mail.gmail.com>
	<20090901200313.J68375@maildrop.int.zabbadoz.net>
	<20090902160440.GA28417@sd-13813.dedibox.fr> 
Message-ID: <200909022304.n82N4PHe079957@drugs.dv.isc.org>


In message <20090902160440.GA28417@sd-13813.dedibox.fr>, FLEURIOT Damien writes
:
> On Tue, Sep 01, 2009 at 08:15:24PM +0000 or thereabouts, Bjoern A. Zeeb wrote
> :
> > On Tue, 1 Sep 2009, Major Domo wrote:
> > 
> > Hi,
> > 
> > >Apologies if this has been discussed already but I searched the web
> > >and the mailing lists and haven't found hints on my problem.
> > >
> > >I've got a jail, I assign it a set of IP addresses, and it just won't
> > >take the IP6 I give it.
> > >
> > >
> > >Uname:
> > >FreeBSD 7.2-STABLE
> > >
> > >jail_ns_ip="192.168.0.252,fe80::c0a8:fc"
> > >
> > >jls -v:
> > >  JID  Hostname                      Path
> > >       Name                          State
> > >       CPUSetID
> > >       IP Address(es)
> > >   23  [snip]                      /var/jail/ns
> > >                                     ALIVE
> > >       2
> > >       192.168.0.252
> > >       fe80::c0a8:fc
> > >
> > >
> > >ifconfig lo252 from the host:
> > >lo252: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
> > >       inet 192.168.0.252 netmask 0xffffffff
> > >       inet6 fe80::c0a8:fc%lo252 prefixlen 128 scopeid 0x5
> > >
> > >
> > >ifconfig from the jail:
> > >re0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
> > >       options=389b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_
> UCAST,WOL_MCAST,WOL_MAGIC>
> > >       ether 00:e0:f4:19:e9:d2
> > >       media: Ethernet autoselect (100baseTX <full-duplex>)
> > >       status: active
> > >lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
> > >pflog0: flags=141<UP,RUNNING,PROMISC> metric 0 mtu 33204
> > >lo252: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
> > >       inet 192.168.0.252 netmask 0xffffffff
> > 
> > 
> > This is a rather special case.  For link-local addresses you have to
> > give the scope as well but it won't take the scope with the %lo252
> > notation but only in the KAME in-kernel syntax I would assume.
> > Can you try:
> > 
> > jail_ns_ip="192.168.0.252,fe80:5::c0a8:fc"
> > 
> > Note the added 5 in the second group of hex digits.  That five is the
> > interface index.  I took it from the "scopeid 0x5". In case your
> > interface index changes you will need to adjust the address.
> > 
> > I cannot say if it'll work but it would be worth a try.
> > 
> > /bz
> > 
> > -- 
> > Bjoern A. Zeeb           What was I talking about and who are you again?
> 
> 
> Hi list, Bjoern, John,
> 
> 
> I confirm it is now working with the following line in /etc/rc.conf:
> jail_ns_ip="192.168.0.252,fec0:5::df:252"
> 
> along with redirections in /etc/pf.conf:
> rdr pass log on $ext_if inet proto {tcp,udp} to $ext_if port 53 ->
> $lo252_if port 53
> rdr pass log on $ext_if inet6 proto {tcp,udp} to $ext_if port 53 ->
> $lo252_if port 53
> 
> 
> Notice the use of both the interface's index and a site-local ip6
> address instead of the old fe80 as suggested.
> 
> BIND's now happily running in its jail and responding to public
> queries.
> 
> 
> Perhaps a small addition to the jails entry in the Handbook to
> advise people about the use of IP6 addresses on loopback interfaces
> would be warranted ?
> 
> I realize how lousy it is to NAT IP6 but my host assigns only 1
> IP6 address per server.

Then complain.  There is no reason to be miserly with IPv6 addresses.

> Thanks for the help !
> 
> Regards
> 
> --
> Damien
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org
From emikulic at gmail.com  Thu Sep  3 03:19:12 2009
From: emikulic at gmail.com (Emil Mikulic)
Date: Thu Sep  3 03:19:18 2009
Subject: zfs on gmirror slice
In-Reply-To: <4A9E2C7C.6030904@mapper.nl>
References: <a7454e2f0909010704g2fb27216hacb3ffd2cae5594c@mail.gmail.com>
	<061541E3-F301-46C4-8ECB-5B05854F0EAA@exscape.org>
	<a7454e2f0909010904s224be2ectdd18eb887f4c1311@mail.gmail.com>
	<4A9D558A.9070609@quip.cz> <4A9E1CB5.6030906@mapper.nl>
	<20090902074445.GA13588@dmr.ath.cx> <4A9E2C7C.6030904@mapper.nl>
Message-ID: <20090903031908.GA18410@dmr.ath.cx>

On Wed, Sep 02, 2009 at 10:27:40AM +0200, Mark Stapper wrote:
> Emil Mikulic wrote:
> > As Thomas Backman pointed out, this means you won't get self-healing.
> >   
> self-healing sounds very nice, but with mirrorring you have data on two
> discs, so in that case there no "healing" involved, it's just
> checksumming and reading the non-corrupted copy.

This won't work through gmirror because ZFS sees the mirror as a single
disk.

When it gets corrupt data, it has no way of signalling the gmirror layer
to try reading the other disk(s) in the mirror.  It's simply stuck with
the corrupt data.

Whereas with mirroring done by ZFS itself, it -can- try the other disks.
And "self-healing" is where it writes the correct data back to the
damaged disk on the fly.  That's pretty cool.

> From the gmirror manpage: "All operations like failure detection, stale
> component detection, rebuild of stale components, etc. are also done
> automatically."
> This would indicate the same functionality, with a much less fancy name.

Sorry, but no.  ZFS can do some much fancier things if you let it manage
the disks directly, e.g.:

- it can detect disks returning bad data (because it has checksums)
  whereas gmirror's "failure detection" requires the disk to return
  errors or stop responding entirely

- rebuild of stale components ("resilver") is proportional to the
  amount of data stored rather than the full capacity of the disks being
  used.  i.e. ZFS won't rebuild the free space in the filesystem.

> gmirror is fast though. I've even heard it's faster than software
> RAID1/ataraid. (not confirmed).

gmirror -is- software raid.  ataraid is really broken based on my
reading of these lists, I wouldn't trust my data to it.

> Even if this is true, running zfs on top of gmirror probably isn't
> faster then running zfs with a mirrored pool.

Maybe you wouldn't see a speed difference, but there's a significant
difference in features and reliability.

--Emil
From spry at anarchy.in.the.ph  Thu Sep  3 05:59:05 2009
From: spry at anarchy.in.the.ph (Mars G Miro)
Date: Thu Sep  3 05:59:12 2009
Subject: Not getting an IPv6 in a jail
In-Reply-To: <200909022304.n82N4PHe079957@drugs.dv.isc.org>
References: <ff6efe7e0909011230i414b6791k707f5c58383e9b53@mail.gmail.com>
	<20090901200313.J68375@maildrop.int.zabbadoz.net>
	<20090902160440.GA28417@sd-13813.dedibox.fr>
	<200909022304.n82N4PHe079957@drugs.dv.isc.org>
Message-ID: <f12f408a0909022213p43ae39cevcf3e7d5a077cef0f@mail.gmail.com>

On Thu, Sep 3, 2009 at 7:04 AM, Mark Andrews<marka@isc.org> wrote:
>
> In message <20090902160440.GA28417@sd-13813.dedibox.fr>, FLEURIOT Damien writes
> :
>> On Tue, Sep 01, 2009 at 08:15:24PM +0000 or thereabouts, Bjoern A. Zeeb wrote
>> :
>> > On Tue, 1 Sep 2009, Major Domo wrote:
>> >
>> > Hi,
>> >
>> > >Apologies if this has been discussed already but I searched the web
>> > >and the mailing lists and haven't found hints on my problem.
>> > >
>> > >I've got a jail, I assign it a set of IP addresses, and it just won't
>> > >take the IP6 I give it.
>> > >
>> > >
>> > >Uname:
>> > >FreeBSD 7.2-STABLE
>> > >
>> > >jail_ns_ip="192.168.0.252,fe80::c0a8:fc"
>> > >
>> > >jls -v:
>> > > ?JID ?Hostname ? ? ? ? ? ? ? ? ? ? ?Path
>> > > ? ? ? Name ? ? ? ? ? ? ? ? ? ? ? ? ?State
>> > > ? ? ? CPUSetID
>> > > ? ? ? IP Address(es)
>> > > ? 23 ?[snip] ? ? ? ? ? ? ? ? ? ? ?/var/jail/ns
>> > > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ALIVE
>> > > ? ? ? 2
>> > > ? ? ? 192.168.0.252
>> > > ? ? ? fe80::c0a8:fc
>> > >
>> > >
>> > >ifconfig lo252 from the host:
>> > >lo252: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
>> > > ? ? ? inet 192.168.0.252 netmask 0xffffffff
>> > > ? ? ? inet6 fe80::c0a8:fc%lo252 prefixlen 128 scopeid 0x5
>> > >
>> > >
>> > >ifconfig from the jail:
>> > >re0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
>> > > ? ? ? options=389b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_
>> UCAST,WOL_MCAST,WOL_MAGIC>
>> > > ? ? ? ether 00:e0:f4:19:e9:d2
>> > > ? ? ? media: Ethernet autoselect (100baseTX <full-duplex>)
>> > > ? ? ? status: active
>> > >lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
>> > >pflog0: flags=141<UP,RUNNING,PROMISC> metric 0 mtu 33204
>> > >lo252: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
>> > > ? ? ? inet 192.168.0.252 netmask 0xffffffff
>> >
>> >
>> > This is a rather special case. ?For link-local addresses you have to
>> > give the scope as well but it won't take the scope with the %lo252
>> > notation but only in the KAME in-kernel syntax I would assume.
>> > Can you try:
>> >
>> > jail_ns_ip="192.168.0.252,fe80:5::c0a8:fc"
>> >
>> > Note the added 5 in the second group of hex digits. ?That five is the
>> > interface index. ?I took it from the "scopeid 0x5". In case your
>> > interface index changes you will need to adjust the address.
>> >
>> > I cannot say if it'll work but it would be worth a try.
>> >
>> > /bz
>> >
>> > --
>> > Bjoern A. Zeeb ? ? ? ? ? What was I talking about and who are you again?
>>
>>
>> Hi list, Bjoern, John,
>>
>>
>> I confirm it is now working with the following line in /etc/rc.conf:
>> jail_ns_ip="192.168.0.252,fec0:5::df:252"
>>
>> along with redirections in /etc/pf.conf:
>> rdr pass log on $ext_if inet proto {tcp,udp} to $ext_if port 53 ->
>> $lo252_if port 53
>> rdr pass log on $ext_if inet6 proto {tcp,udp} to $ext_if port 53 ->
>> $lo252_if port 53
>>
>>
>> Notice the use of both the interface's index and a site-local ip6
>> address instead of the old fe80 as suggested.
>>
>> BIND's now happily running in its jail and responding to public
>> queries.
>>
>>
>> Perhaps a small addition to the jails entry in the Handbook to
>> advise people about the use of IP6 addresses on loopback interfaces
>> would be warranted ?
>>
>> I realize how lousy it is to NAT IP6 but my host assigns only 1
>> IP6 address per server.
>
> Then complain. ?There is no reason to be miserly with IPv6 addresses.
>

True that. Or just sign up @HE. They can give you up to 4 tunnels w/ a
/64 and a /48 (if you opt) for each of these 4 tunnels!

All you hafta do is give them your contact info and a public IPv4 and
it doesn't hafta be static --- there are tools to update their
records..


>> Thanks for the help !
>>
>> Regards
>>
>> --
>> Damien
>> _______________________________________________
>> freebsd-stable@freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
>> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742 ? ? ? ? ? ? ? ? INTERNET: marka@isc.org
> _______________________________________________
> freebsd-jail@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-jail
> To unsubscribe, send any mail to "freebsd-jail-unsubscribe@freebsd.org"
>



-- 
cheers
mars
-----
Marie von Ebner-Eschenbach  - "Even a stopped clock is right twice a
day." - http://www.brainyquote.com/quotes/authors/m/marie_von_ebnereschenbac.html
From jhb at freebsd.org  Thu Sep  3 12:21:40 2009
From: jhb at freebsd.org (John Baldwin)
Date: Thu Sep  3 12:22:00 2009
Subject: Not getting an IPv6 in a jail
In-Reply-To: <4A9E98AD.1070202@FreeBSD.org>
References: <ff6efe7e0909011230i414b6791k707f5c58383e9b53@mail.gmail.com>
	<20090902160440.GA28417@sd-13813.dedibox.fr>
	<4A9E98AD.1070202@FreeBSD.org>
Message-ID: <200909030808.08440.jhb@freebsd.org>

On Wednesday 02 September 2009 12:09:17 pm Doug Barton wrote:
> FLEURIOT Damien wrote:
> 
> > BIND's now happily running in its jail and responding to public
> > queries.
> 
> It's up to you if you choose to do it, but there is no reason to run
> BIND in a jail. The chroot feature provided by default by rc.d/named
> is quite adequate security.

That is debatable.  One of the chief benefits of a jail is that if a server is 
compromised so that an attacker can gain root access that root access is 
limited in what it can do compared to a simple chroot.  That is true for any 
server you would run under a jail, not just BIND.

-- 
John Baldwin
From lars.eggert at nokia.com  Thu Sep  3 12:39:30 2009
From: lars.eggert at nokia.com (Lars Eggert)
Date: Thu Sep  3 12:39:37 2009
Subject: net.inet.tcp.tso=1 still neceesary with fxp was Re: TCP
	differences in 7.2 vs 7.1
In-Reply-To: <20090523013452.GA22204@michelle.cdnetworks.co.kr>
References: <4A09DEF1.2010202@delphij.net> <4A09FDB2.5080307@eyede.com>
	<20090513004131.GP65350@michelle.cdnetworks.co.kr>
	<DAF693BD-D7B0-49FA-97EF-41C1EA1FAF84@nokia.com>
	<20090514082750.GU65350@michelle.cdnetworks.co.kr>
	<310A73CC-A32D-4794-BF23-A49715AFCF99@nokia.com>
	<20090515085806.GX65350@michelle.cdnetworks.co.kr>
	<20090520173716.U1136@familysquires.net>
	<20090521034540.GM9043@michelle.cdnetworks.co.kr>
	<20090522153805.W1128@familysquires.net>
	<20090523013452.GA22204@michelle.cdnetworks.co.kr>
Message-ID: <D11BCA0B-5BEE-4864-8AF9-7C8C19877DB6@nokia.com>

Hi,

just a quick update: I still need to run with TSO off on RELENG_7  
build Sep 1, because otherwise throughput via em interfaces is  
sometimes very poor.

Lars
From steve at ibctech.ca  Thu Sep  3 13:28:48 2009
From: steve at ibctech.ca (Steve Bertrand)
Date: Thu Sep  3 13:28:55 2009
Subject: zfs won't automount
In-Reply-To: <4A9EA37B.2020800@msu.edu>
References: <4A9EA37B.2020800@msu.edu>
Message-ID: <4A9FC494.4040409@ibctech.ca>

Lisa Besko wrote:
> I have a system that has a simple zfs raid 0 volume on it and it will
> now mount when the system boots.  After the system is up I can run
> /etc/rc.d/zfs start and it's fine.  I don't see any errors in the log
> file other than the ZFS is experimental in FreeBSD message.  I'm running
> FreeBSD 7.2 stable.  I have zfs_enable="YES" in the rc.conf file.  Am I
> missing something?

My ZFS setups have worked so well for so long, I can't remember what all
to look for. However, I do remember having to create an entry in my
/boot/loader.conf ( IIRC, only the first two lines are mandatory, the
other two are just tweaks ):

zfs_load="YES"
vfs.root.mountfrom="zfs:storage"
vm.kmem_size="1536M"
vm.kmem_size_max="1536M"

Steve
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3233 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090903/f708ac3b/smime.bin
From steve at ibctech.ca  Thu Sep  3 13:31:18 2009
From: steve at ibctech.ca (Steve Bertrand)
Date: Thu Sep  3 13:31:26 2009
Subject: zfs won't automount
In-Reply-To: <4A9FC494.4040409@ibctech.ca>
References: <4A9EA37B.2020800@msu.edu> <4A9FC494.4040409@ibctech.ca>
Message-ID: <4A9FC52B.2090705@ibctech.ca>

Steve Bertrand wrote:
> Lisa Besko wrote:
>> I have a system that has a simple zfs raid 0 volume on it and it will
>> now mount when the system boots.  After the system is up I can run
>> /etc/rc.d/zfs start and it's fine.  I don't see any errors in the log
>> file other than the ZFS is experimental in FreeBSD message.  I'm running
>> FreeBSD 7.2 stable.  I have zfs_enable="YES" in the rc.conf file.  Am I
>> missing something?
> 
> My ZFS setups have worked so well for so long, I can't remember what all
> to look for. However, I do remember having to create an entry in my
> /boot/loader.conf ( IIRC, only the first two lines are mandatory, the
> other two are just tweaks ):
> 
> zfs_load="YES"
> vfs.root.mountfrom="zfs:storage"
> vm.kmem_size="1536M"
> vm.kmem_size_max="1536M"

D'oh! After hitting myself with the cluebat, I realized that those
entries are there because I am mounting / from ZFS. I don't think
they'll help in your case. Sorry!

Steve
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3233 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090903/ebca5f59/smime.bin
From dimitry at andric.com  Thu Sep  3 13:35:05 2009
From: dimitry at andric.com (Dimitry Andric)
Date: Thu Sep  3 13:35:13 2009
Subject: zfs won't automount
In-Reply-To: <4A9EA37B.2020800@msu.edu>
References: <4A9EA37B.2020800@msu.edu>
Message-ID: <4A9FC60A.2000904@andric.com>

On 2009-09-02 18:55, Lisa Besko wrote:
> I have a system that has a simple zfs raid 0 volume on it and it will 
> now mount when the system boots.  After the system is up I can run 
> /etc/rc.d/zfs start and it's fine.  I don't see any errors in the log 
> file other than the ZFS is experimental in FreeBSD message.  I'm running 
> FreeBSD 7.2 stable.  I have zfs_enable="YES" in the rc.conf file.  Am I 
> missing something?

What do "zpool list" and "zfs list" say?
From besko at msu.edu  Thu Sep  3 17:15:34 2009
From: besko at msu.edu (Lisa Besko)
Date: Thu Sep  3 17:15:42 2009
Subject: zfs won't automount
In-Reply-To: <4A9FC60A.2000904@andric.com>
References: <4A9EA37B.2020800@msu.edu> <4A9FC60A.2000904@andric.com>
Message-ID: <4A9FD29F.3010000@msu.edu>



Dimitry Andric wrote:
> On 2009-09-02 18:55, Lisa Besko wrote:
>> I have a system that has a simple zfs raid 0 volume on it and it will 
>> now mount when the system boots.  After the system is up I can run 
>> /etc/rc.d/zfs start and it's fine.  I don't see any errors in the log 
>> file other than the ZFS is experimental in FreeBSD message.  I'm running 
>> FreeBSD 7.2 stable.  I have zfs_enable="YES" in the rc.conf file.  Am I 
>> missing something?
> 
> What do "zpool list" and "zfs list" say?

After I mount them they say this:

# zfs list
NAME      USED  AVAIL  REFER  MOUNTPOINT
sniffer  66.5K  1.96T  18.5K  /sniffer
# zpool list
NAME      SIZE   USED  AVAIL    CAP  HEALTH  ALTROOT
sniffer  1.99T    75K  1.99T     0%  ONLINE  -

When it boots and they are not mounted it says:

# zfs list
NAME      USED  AVAIL  REFER  MOUNTPOINT
sniffer  66.5K  1.96T  18.5K  /sniffer
# zpool list
NAME      SIZE   USED  AVAIL    CAP  HEALTH  ALTROOT
sniffer  1.99T    75K  1.99T     0%  ONLINE  -

but it does not show up when I do a df.

LB

From edhoprima at gmail.com  Thu Sep  3 17:54:01 2009
From: edhoprima at gmail.com (Edho P Arief)
Date: Thu Sep  3 17:54:13 2009
Subject: zfs won't automount
In-Reply-To: <4A9FD29F.3010000@msu.edu>
References: <4A9EA37B.2020800@msu.edu> <4A9FC60A.2000904@andric.com>
	<4A9FD29F.3010000@msu.edu>
Message-ID: <a3780c060909031028s56fbbd74rffd29c60a7604c35@mail.gmail.com>

On Thu, Sep 3, 2009 at 9:28 PM, Lisa Besko<besko@msu.edu> wrote:
>
>
> Dimitry Andric wrote:
>>
>> On 2009-09-02 18:55, Lisa Besko wrote:
>>>
>>> I have a system that has a simple zfs raid 0 volume on it and it will now
>>> mount when the system boots. ?After the system is up I can run /etc/rc.d/zfs
>>> start and it's fine. ?I don't see any errors in the log file other than the
>>> ZFS is experimental in FreeBSD message. ?I'm running FreeBSD 7.2 stable. ?I
>>> have zfs_enable="YES" in the rc.conf file. ?Am I missing something?
>>
>> What do "zpool list" and "zfs list" say?
>
> After I mount them they say this:
>
> # zfs list
> NAME ? ? ?USED ?AVAIL ?REFER ?MOUNTPOINT
> sniffer ?66.5K ?1.96T ?18.5K ?/sniffer
> # zpool list
> NAME ? ? ?SIZE ? USED ?AVAIL ? ?CAP ?HEALTH ?ALTROOT
> sniffer ?1.99T ? ?75K ?1.99T ? ? 0% ?ONLINE ?-
>
> When it boots and they are not mounted it says:
>
> # zfs list
> NAME ? ? ?USED ?AVAIL ?REFER ?MOUNTPOINT
> sniffer ?66.5K ?1.96T ?18.5K ?/sniffer
> # zpool list
> NAME ? ? ?SIZE ? USED ?AVAIL ? ?CAP ?HEALTH ?ALTROOT
> sniffer ?1.99T ? ?75K ?1.99T ? ? 0% ?ONLINE ?-
>
> but it does not show up when I do a df.
>

fastest way would be adding entry

sniffer /sniffer zfs rw 0 0

to /etc/fstab

-- 
O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
From dimitry at andric.com  Thu Sep  3 19:29:57 2009
From: dimitry at andric.com (Dimitry Andric)
Date: Thu Sep  3 19:30:04 2009
Subject: zfs won't automount
In-Reply-To: <a3780c060909031028s56fbbd74rffd29c60a7604c35@mail.gmail.com>
References: <4A9EA37B.2020800@msu.edu>
	<4A9FC60A.2000904@andric.com>	<4A9FD29F.3010000@msu.edu>
	<a3780c060909031028s56fbbd74rffd29c60a7604c35@mail.gmail.com>
Message-ID: <4AA01933.8000509@andric.com>

On 2009-09-03 19:28, Edho P Arief wrote:
> fastest way would be adding entry
> 
> sniffer /sniffer zfs rw 0 0
> 
> to /etc/fstab

No, that is not the way you should do it with ZFS.
From kenyon at kenyonralph.com  Thu Sep  3 19:43:26 2009
From: kenyon at kenyonralph.com (Kenyon Ralph)
Date: Thu Sep  3 19:43:33 2009
Subject: zfs won't automount
In-Reply-To: <4A9EA37B.2020800@msu.edu>
References: <4A9EA37B.2020800@msu.edu>
Message-ID: <20090903194323.GE7186@kenyonralph.com>

On 2009-09-02T12:55:23-0400, Lisa Besko <besko@msu.edu> wrote:
> I have a system that has a simple zfs raid 0 volume on it and it will  
> now mount when the system boots.  After the system is up I can run  
> /etc/rc.d/zfs start and it's fine.  I don't see any errors in the log  
> file other than the ZFS is experimental in FreeBSD message.  I'm running  
> FreeBSD 7.2 stable.  I have zfs_enable="YES" in the rc.conf file.  Am I  
> missing something?

Do you have the zfs mountpoint properties set for the filesystems? Try
zfs get all | grep mountpoint. When you zfs set the mountpoint, the
filesystem will automatically be mounted there. The zfs man page has the
details.

Kenyon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090903/c1405c1e/attachment.pgp
From fjwcash at gmail.com  Thu Sep  3 20:30:41 2009
From: fjwcash at gmail.com (Freddie Cash)
Date: Thu Sep  3 20:30:48 2009
Subject: zfs won't automount
In-Reply-To: <20090903194323.GE7186@kenyonralph.com>
References: <4A9EA37B.2020800@msu.edu> <20090903194323.GE7186@kenyonralph.com>
Message-ID: <b269bc570909031330r58dd28cctea2fb316dc2c8f95@mail.gmail.com>

On Thu, Sep 3, 2009 at 12:43 PM, Kenyon Ralph <kenyon@kenyonralph.com>wrote:

> On 2009-09-02T12:55:23-0400, Lisa Besko <besko@msu.edu> wrote:
> > I have a system that has a simple zfs raid 0 volume on it and it will
> > now mount when the system boots.  After the system is up I can run
> > /etc/rc.d/zfs start and it's fine.  I don't see any errors in the log
> > file other than the ZFS is experimental in FreeBSD message.  I'm running
> > FreeBSD 7.2 stable.  I have zfs_enable="YES" in the rc.conf file.  Am I
> > missing something?
>
> Do you have the zfs mountpoint properties set for the filesystems? Try
> zfs get all | grep mountpoint. When you zfs set the mountpoint, the
>

No need for the grep command, just "zfs get mountpoint" is enough.  That
will show just the mounpoint property for all the filesystems, snapshots,
and volumes.

-- 
Freddie Cash
fjwcash@gmail.com
From jeffrey at goldmark.org  Fri Sep  4 04:17:44 2009
From: jeffrey at goldmark.org (Jeffrey Goldberg)
Date: Fri Sep  4 04:17:51 2009
Subject: Subscribe to your mailing list
In-Reply-To: <1251743631.3555.9.camel@bakacs.kerek.hu>
References: <1251743631.3555.9.camel@bakacs.kerek.hu>
Message-ID: <B6672233-3809-475C-AA3C-33FDE1799AEC@goldmark.org>

On Aug 31, 2009, at 1:33 PM, Sz?ra Gy?rgy wrote:

> I had some nuisance when after implementation booting  7.2 release. It
> denied me to boot the once installed release.

I don't understand what you are saying.  Are you saying that once you  
installed 7.2 the system wouldn't boot?

Azt mondod, hogy nem boot-ol az 7.2es insztelaci? utan?

> Further I have very strong annoyance implementing the Localisation.We
> need of accent over voayels aniway.
> Best regards Gyorgy Szara.

Considering your name, I understand why you need the accent marks.

Have you looked at the instructions in chapter 23 of the handbook?

  http://www.freebsd.org/doc/hu/books/handbook/l10n.html

Minden j?t kiv?nok

-jeff

-- 
Jeffrey Goldberg                        http://www.goldmark.org/jeff/

From stark at mapper.nl  Fri Sep  4 06:33:42 2009
From: stark at mapper.nl (Mark Stapper)
Date: Fri Sep  4 06:33:49 2009
Subject: Subscribe to your mailing list(off topic)
In-Reply-To: <B6672233-3809-475C-AA3C-33FDE1799AEC@goldmark.org>
References: <1251743631.3555.9.camel@bakacs.kerek.hu>
	<B6672233-3809-475C-AA3C-33FDE1799AEC@goldmark.org>
Message-ID: <4AA0B4A7.5010803@mapper.nl>

Jeffrey Goldberg wrote:
> On Aug 31, 2009, at 1:33 PM, Sz?ra Gy?rgy wrote:
>
>> I had some nuisance when after implementation booting  7.2 release. It
>> denied me to boot the once installed release.
>
> I don't understand what you are saying.  Are you saying that once you
> installed 7.2 the system wouldn't boot?
>
> Azt mondod, hogy nem boot-ol az 7.2es insztelaci? utan?
>
>> Further I have very strong annoyance implementing the Localisation.We
>> need of accent over voayels aniway.
>> Best regards Gyorgy Szara.
>
> Considering your name, I understand why you need the accent marks.
>
> Have you looked at the instructions in chapter 23 of the handbook?
>
>  http://www.freebsd.org/doc/hu/books/handbook/l10n.html
>
> Minden j?t kiv?nok
>
> -jeff
>
Just off topic.. but.. Magyar?
Eg?szs?gedre!
Mark

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 259 bytes
Desc: OpenPGP digital signature
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090904/92e0366c/signature.pgp
From jb000003 at mr-happy.com  Fri Sep  4 17:37:17 2009
From: jb000003 at mr-happy.com (Jeff Blank)
Date: Fri Sep  4 17:37:24 2009
Subject: 8.0-BETA3/IPv6: route: bad keyword: cloning
Message-ID: <20090904173716.GA2278@mr-happy.com>

Hi,

Upon booting an 8.0-BETA3 system with IPv6 enabled, I saw this in the
console boot output:

route: bad keyword: cloning
usage: route [-dnqtv] command [[modifiers] args]

This looks like it's from line 1062/1063 of /etc/network.subr
v1.195.2.4.

This system is not an IPv6 router, so do I particularly need
$ipv6_default_interface set in rc.conf?

Is there a situation where -cloning (still referenced in the man page)
is a valid option to route (in inet6 context at least)?  If no, should
I file a PR?  (I searched GNATS but didn't find anything matching
this.)

thanks,
Jeff
From thierry at FreeBSD.org  Fri Sep  4 17:56:29 2009
From: thierry at FreeBSD.org (Thierry Thomas)
Date: Fri Sep  4 17:56:35 2009
Subject: ifconfig_ed0="DHCP" does not work on 8.0-BETA3
Message-ID: <20090904173811.GA45176@graf.pompo.net>

Hello,

I have a machine with the following ethernet PCI card:

ed0: <RealTek 8029> port 0xdc00-0xdc1f irq 16 at device 0.0 on pci2
ed0: WARNING: using obsoleted if_watchdog interface
ed0: Ethernet address: 00:50:bf:27:ba:24
ed0: [ITHREAD]

It's rather an ancient card, and it worked on FreeBSD 7.2-STABLE (and
several previous versions) with the line:

ifconfig_ed0="DHCP"

in /etc/rc.conf.

I upgraded this machine to 8.0-BETA3, and ed0 does not get an IP anymore
at boot time! Running `dhclient ed0' manually is working, and then
everything is OK.

Well, I know that this device could be deprecated, but I'm sure it is
still running in many machines...

If I replace it by a newer card, e.g.

rl0: <RealTek 8139 10/100BaseTX> port 0xd800-0xd8ff mem 0xfbeffc00-0xfbeffcff irq 16 at device 0.0 on pci2
miibus1: <MII bus> on rl0
rlphy0: <RealTek internal media interface> PHY 0 on miibus1
rlphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
rl0: Ethernet address: 00:17:3f:d2:51:4c
rl0: [ITHREAD]

and replacing s/ed0/rl0/ in /etc/rc.conf, everything is working.

Strange, is'nt it?
-- 
Th. Thomas.
From qing.li at bluecoat.com  Fri Sep  4 18:15:54 2009
From: qing.li at bluecoat.com (Li, Qing)
Date: Fri Sep  4 18:16:01 2009
Subject: 8.0-BETA3/IPv6: route: bad keyword: cloning
In-Reply-To: <20090904173716.GA2278@mr-happy.com>
References: <20090904173716.GA2278@mr-happy.com>
Message-ID: <B583FBF374231F4A89607B4D08578A4305361EBE@bcs-mail03.internal.cacheflow.com>

> 
> Upon booting an 8.0-BETA3 system with IPv6 enabled, I saw this in the
> console boot output:
> 
> route: bad keyword: cloning
> usage: route [-dnqtv] command [[modifiers] args]
> 
> This looks like it's from line 1062/1063 of /etc/network.subr
> v1.195.2.4.
> 
> This system is not an IPv6 router, so do I particularly need
> $ipv6_default_interface set in rc.conf?
> 
> Is there a situation where -cloning (still referenced in the man page)
> is a valid option to route (in inet6 context at least)?  If no, should
> I file a PR?  (I searched GNATS but didn't find anything matching
> this.)
> 

	Route cloning is obsolete. Please report issues concerning
	8.0 to freebsd-current@freebsd.org.

	Thanks,

	-- Qing

From qing.li at bluecoat.com  Fri Sep  4 18:57:20 2009
From: qing.li at bluecoat.com (Li, Qing)
Date: Fri Sep  4 18:57:37 2009
Subject: 8.0-BETA3/IPv6: route: bad keyword: cloning
In-Reply-To: <B583FBF374231F4A89607B4D08578A4305361EBE@bcs-mail03.internal.cacheflow.com>
References: <20090904173716.GA2278@mr-happy.com>
	<B583FBF374231F4A89607B4D08578A4305361EBE@bcs-mail03.internal.cacheflow.com>
Message-ID: <B583FBF374231F4A89607B4D08578A4305361F0D@bcs-mail03.internal.cacheflow.com>

	Regarding the man page issue, after a quick investigation, and
to 
	make a long story short, Kip Macy and I spent a bunch of time
testing 
	and fixing a few last minute bugs before my big commit last
December. 

	Kip actually took care of this man page and one other issue in
"ndp"
	command. 

	Somehow these two last minute changes fell through the cracks
	and did not make it into r186119. Kip will fix it again.

	Thank you for catching the bug.

	-- Qing

	

> -----Original Message-----
> From: owner-freebsd-stable@freebsd.org [mailto:owner-freebsd-
> stable@freebsd.org] On Behalf Of Li, Qing
> Sent: Friday, September 04, 2009 11:15 AM
> To: Jeff Blank; freebsd-stable@freebsd.org
> Cc: FreeBSD Current
> Subject: RE: 8.0-BETA3/IPv6: route: bad keyword: cloning
> 
> >
> > Upon booting an 8.0-BETA3 system with IPv6 enabled, I saw this in
the
> > console boot output:
> >
> > route: bad keyword: cloning
> > usage: route [-dnqtv] command [[modifiers] args]
> >
> > This looks like it's from line 1062/1063 of /etc/network.subr
> > v1.195.2.4.
> >
> > This system is not an IPv6 router, so do I particularly need
> > $ipv6_default_interface set in rc.conf?
> >
> > Is there a situation where -cloning (still referenced in the man
page)
> > is a valid option to route (in inet6 context at least)?  If no,
> should
> > I file a PR?  (I searched GNATS but didn't find anything matching
> > this.)
> >
> 
> 	Route cloning is obsolete. Please report issues concerning
> 	8.0 to freebsd-current@freebsd.org.
> 
> 	Thanks,
> 
> 	-- Qing
> 
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-
> unsubscribe@freebsd.org"
From pyunyh at gmail.com  Fri Sep  4 21:42:48 2009
From: pyunyh at gmail.com (Pyun YongHyeon)
Date: Fri Sep  4 21:42:54 2009
Subject: ifconfig_ed0="DHCP" does not work on 8.0-BETA3
In-Reply-To: <20090904173811.GA45176@graf.pompo.net>
References: <20090904173811.GA45176@graf.pompo.net>
Message-ID: <20090904214148.GB9950@michelle.cdnetworks.com>

On Fri, Sep 04, 2009 at 07:38:11PM +0200, Thierry Thomas wrote:
> Hello,
> 
> I have a machine with the following ethernet PCI card:
> 
> ed0: <RealTek 8029> port 0xdc00-0xdc1f irq 16 at device 0.0 on pci2
> ed0: WARNING: using obsoleted if_watchdog interface
> ed0: Ethernet address: 00:50:bf:27:ba:24
> ed0: [ITHREAD]
> 
> It's rather an ancient card, and it worked on FreeBSD 7.2-STABLE (and
> several previous versions) with the line:
> 
> ifconfig_ed0="DHCP"
> 
> in /etc/rc.conf.
> 
> I upgraded this machine to 8.0-BETA3, and ed0 does not get an IP anymore
> at boot time! Running `dhclient ed0' manually is working, and then
> everything is OK.
> 

I guess it's related with link state handling. Can you see
"ed0: link state changed to UP" in dmesg output? Quick reading code
reveals only some variants(pccard) support mii(4) but others looks
dumb on link state handling. I vaguely remember I had ed(4)
hardwares in FreeBSD 2.2.x days but didn't have chance to read the
source.

> Well, I know that this device could be deprecated, but I'm sure it is
> still running in many machines...
> 
> If I replace it by a newer card, e.g.
> 
> rl0: <RealTek 8139 10/100BaseTX> port 0xd800-0xd8ff mem 0xfbeffc00-0xfbeffcff irq 16 at device 0.0 on pci2
> miibus1: <MII bus> on rl0
> rlphy0: <RealTek internal media interface> PHY 0 on miibus1
> rlphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
> rl0: Ethernet address: 00:17:3f:d2:51:4c
> rl0: [ITHREAD]
> 
> and replacing s/ed0/rl0/ in /etc/rc.conf, everything is working.
> 

Yes it should because it has active maintainer. :-)

> Strange, is'nt it?
> -- 
> Th. Thomas.
From thierry at FreeBSD.org  Fri Sep  4 21:56:10 2009
From: thierry at FreeBSD.org (Thierry Thomas)
Date: Fri Sep  4 21:56:17 2009
Subject: ifconfig_ed0="DHCP" does not work on 8.0-BETA3
In-Reply-To: <20090904214148.GB9950@michelle.cdnetworks.com>
References: <20090904173811.GA45176@graf.pompo.net>
	<20090904214148.GB9950@michelle.cdnetworks.com>
Message-ID: <20090904215559.GJ93393@graf.pompo.net>

Hello,

Le Ven  4 sep 09 ? 23:41:48 +0200, Pyun YongHyeon <pyunyh@gmail.com>
 ?crivait?:

> I guess it's related with link state handling. Can you see
> "ed0: link state changed to UP" in dmesg output? Quick reading code
> reveals only some variants(pccard) support mii(4) but others looks
> dumb on link state handling. I vaguely remember I had ed(4)
> hardwares in FreeBSD 2.2.x days but didn't have chance to read the
> source.

No, no lines
ed0: link state changed to DOWN
ed0: link state changed to UP
in 8.0-BETA3!

> > and replacing s/ed0/rl0/ in /etc/rc.conf, everything is working.
> > 
> 
> Yes it should because it has active maintainer. :-)

Great! ;-)
-- 
Th. Thomas.
From brooks at freebsd.org  Fri Sep  4 21:57:25 2009
From: brooks at freebsd.org (Brooks Davis)
Date: Fri Sep  4 21:57:34 2009
Subject: ifconfig_ed0="DHCP" does not work on 8.0-BETA3
In-Reply-To: <20090904214148.GB9950@michelle.cdnetworks.com>
References: <20090904173811.GA45176@graf.pompo.net>
	<20090904214148.GB9950@michelle.cdnetworks.com>
Message-ID: <20090904215747.GB82231@lor.one-eyed-alien.net>

On Fri, Sep 04, 2009 at 02:41:48PM -0700, Pyun YongHyeon wrote:
> On Fri, Sep 04, 2009 at 07:38:11PM +0200, Thierry Thomas wrote:
> > Hello,
> > 
> > I have a machine with the following ethernet PCI card:
> > 
> > ed0: <RealTek 8029> port 0xdc00-0xdc1f irq 16 at device 0.0 on pci2
> > ed0: WARNING: using obsoleted if_watchdog interface
> > ed0: Ethernet address: 00:50:bf:27:ba:24
> > ed0: [ITHREAD]
> > 
> > It's rather an ancient card, and it worked on FreeBSD 7.2-STABLE (and
> > several previous versions) with the line:
> > 
> > ifconfig_ed0="DHCP"
> > 
> > in /etc/rc.conf.
> > 
> > I upgraded this machine to 8.0-BETA3, and ed0 does not get an IP anymore
> > at boot time! Running `dhclient ed0' manually is working, and then
> > everything is OK.
> > 
> 
> I guess it's related with link state handling. Can you see
> "ed0: link state changed to UP" in dmesg output? Quick reading code
> reveals only some variants(pccard) support mii(4) but others looks
> dumb on link state handling. I vaguely remember I had ed(4)
> hardwares in FreeBSD 2.2.x days but didn't have chance to read the
> source.

This is a know issue with some devices supported by ed(4).  You can work
around it by changing DHCP to SYNCDHCP which will cause dhclient to
alwasy start immediatly on that interface instead of waiting for a link
state change that never happens.

-- brooks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090904/97a45a5c/attachment.pgp
From tinderbox at freebsd.org  Sat Sep  5 00:10:47 2009
From: tinderbox at freebsd.org (FreeBSD Tinderbox)
Date: Sat Sep  5 00:11:09 2009
Subject: [releng_7 tinderbox] failure on i386/i386
Message-ID: <20090905001044.7F22A1B5060@freebsd-stable.sentex.ca>

TB --- 2009-09-04 23:01:40 - tinderbox 2.6 running on freebsd-stable.sentex.ca
TB --- 2009-09-04 23:01:40 - starting RELENG_7 tinderbox run for i386/i386
TB --- 2009-09-04 23:01:40 - cleaning the object tree
TB --- 2009-09-04 23:02:01 - cvsupping the source tree
TB --- 2009-09-04 23:02:01 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/i386/i386/supfile
TB --- 2009-09-04 23:02:11 - building world
TB --- 2009-09-04 23:02:11 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-09-04 23:02:11 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-09-04 23:02:11 - TARGET=i386
TB --- 2009-09-04 23:02:11 - TARGET_ARCH=i386
TB --- 2009-09-04 23:02:11 - TZ=UTC
TB --- 2009-09-04 23:02:11 - __MAKE_CONF=/dev/null
TB --- 2009-09-04 23:02:11 - cd /src
TB --- 2009-09-04 23:02:11 - /usr/bin/make -B buildworld
>>> World build started on Fri Sep  4 23:02:13 UTC 2009
>>> Rebuilding the temporary build tree
>>> stage 1.1: legacy release compatibility shims
>>> stage 1.2: bootstrap tools
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3: cross tools
>>> stage 4.1: building includes
>>> stage 4.2: building libraries
>>> stage 4.3: make dependencies
>>> stage 4.4: building everything
>>> World build completed on Sat Sep  5 00:06:07 UTC 2009
TB --- 2009-09-05 00:06:07 - generating LINT kernel config
TB --- 2009-09-05 00:06:07 - cd /src/sys/i386/conf
TB --- 2009-09-05 00:06:07 - /usr/bin/make -B LINT
TB --- 2009-09-05 00:06:07 - building LINT kernel
TB --- 2009-09-05 00:06:07 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-09-05 00:06:07 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-09-05 00:06:07 - TARGET=i386
TB --- 2009-09-05 00:06:07 - TARGET_ARCH=i386
TB --- 2009-09-05 00:06:07 - TZ=UTC
TB --- 2009-09-05 00:06:07 - __MAKE_CONF=/dev/null
TB --- 2009-09-05 00:06:07 - cd /src
TB --- 2009-09-05 00:06:07 - /usr/bin/make -B buildkernel KERNCONF=LINT
>>> Kernel build for LINT started on Sat Sep  5 00:06:07 UTC 2009
>>> stage 1: configuring the kernel
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3.1: making dependencies
>>> stage 3.2: building everything
[...]
In file included from ./machine/vm.h:33,
                 from /src/sys/vm/vm.h:64,
                 from /src/sys/ddb/db_break.c:42:
./machine/specialreg.h: In function 'read_cyrix_reg':
./machine/specialreg.h:547: warning: implicit declaration of function 'outb'
./machine/specialreg.h:547: warning: nested extern declaration of 'outb'
./machine/specialreg.h:548: warning: implicit declaration of function 'inb'
./machine/specialreg.h:548: warning: nested extern declaration of 'inb'
*** Error code 1

Stop in /obj/src/sys/LINT.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
TB --- 2009-09-05 00:10:44 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2009-09-05 00:10:44 - ERROR: failed to build lint kernel
TB --- 2009-09-05 00:10:44 - 3465.36 user 377.23 system 4143.55 real


http://tinderbox.des.no/tinderbox-releng_7-RELENG_7-i386-i386.full
From tinderbox at freebsd.org  Sat Sep  5 00:23:23 2009
From: tinderbox at freebsd.org (FreeBSD Tinderbox)
Date: Sat Sep  5 00:23:32 2009
Subject: [releng_7 tinderbox] failure on i386/pc98
Message-ID: <20090905002319.8E6C11B5060@freebsd-stable.sentex.ca>

TB --- 2009-09-05 00:10:44 - tinderbox 2.6 running on freebsd-stable.sentex.ca
TB --- 2009-09-05 00:10:44 - starting RELENG_7 tinderbox run for i386/pc98
TB --- 2009-09-05 00:10:44 - cleaning the object tree
TB --- 2009-09-05 00:11:12 - cvsupping the source tree
TB --- 2009-09-05 00:11:12 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/i386/pc98/supfile
TB --- 2009-09-05 00:11:23 - building world
TB --- 2009-09-05 00:11:23 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-09-05 00:11:23 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-09-05 00:11:23 - TARGET=pc98
TB --- 2009-09-05 00:11:23 - TARGET_ARCH=i386
TB --- 2009-09-05 00:11:23 - TZ=UTC
TB --- 2009-09-05 00:11:23 - __MAKE_CONF=/dev/null
TB --- 2009-09-05 00:11:23 - cd /src
TB --- 2009-09-05 00:11:23 - /usr/bin/make -B buildworld
>>> World build started on Sat Sep  5 00:11:24 UTC 2009
>>> Rebuilding the temporary build tree
>>> stage 1.1: legacy release compatibility shims
>>> stage 1.2: bootstrap tools
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3: cross tools
>>> stage 4.1: building includes
>>> stage 4.2: building libraries
[...]
ln -sf /src/lib/libc/../../contrib/gdtoa/strtord.c gdtoa_strtord.c
ln -sf /src/lib/libc/../../contrib/gdtoa/sum.c gdtoa_sum.c
ln -sf /src/lib/libc/../../contrib/gdtoa/ulp.c gdtoa_ulp.c
rm -f .depend
mkdep -f .depend -a    -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/i386 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/pc98/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING /src/lib/libc/db/btree/bt_close.c /src/lib/libc/db/btree/bt_conv.c /src/lib/libc/db/btree/bt_debug.c /src/lib/libc/db/btree/bt_delete.c /src/lib/libc/db/btree/bt_get.c /src/lib/libc/db/btree/bt_open.c /src/lib/libc/db/btree/bt_overflow.c /src/lib/libc/db/btree/bt_page.c /src/lib/libc/db/btree/bt_put.c /src/lib/libc/db/btree/bt_search.c /src/lib/libc/db/btree/bt_seq.c /src/lib/libc/db/btree/bt_split.c /src/lib/libc/db/btree/bt_utils.c /src/lib/libc/db/db/db.c /src/lib/libc/db/hash/hash.c /src/lib/libc/db/hash/hash_bigkey.c /src/lib/libc/db/hash/hash_buf.c /src/lib/libc/db/hash/hash_func.c /src/lib/libc/db/hash/hash_log2.c /src/lib/libc
 /db/hash/hash_page.c /src/lib/libc/db/hash/ndbm.c /src/lib/libc/db/mpool/mpool.c /src/lib/libc/db/recno/rec_close.c /src/lib/libc/db/recno/rec_delete.c /src/lib/libc/db/recno/rec_get.c /src/lib/libc/db/recno/rec_open.c /src/lib/libc/db/recno/rec_put.c /src/lib/libc/db/recno/rec_search.c /src/lib/libc/db/recno/rec_seq.c /src/lib/libc/db/recno/rec_utils.c /src/lib/libc/compat-43/creat.c /src/lib/libc/compat-43/gethostid.c /src/lib/libc/compat-43/getwd.c /src/lib/libc/compat-43/killpg.c /src/lib/libc/compat-43/sethostid.c /src/lib/libc/compat-43/setpgrp.c /src/lib/libc/compat-43/setrgid.c /src/lib/libc/compat-43/setruid.c /src/lib/libc/compat-43/sigcompat.c /src/lib/libc/gen/__getosreldate.c /src/lib/libc/gen/__xuname.c /src/lib/libc/gen/_pthread_stubs.c /src/lib/libc/gen/_rand48.c /src/lib/libc/gen/_spinlock_stub.c /src/lib/libc/gen/_thread_init.c /src/lib/libc/gen/alarm.c /src/lib/libc/gen/arc4random.c /src/lib/libc/gen/assert.c /src/lib/libc/gen/basename.c /src/lib/libc/gen/
 check_utility_compat.c /src/lib/libc/gen/clock.c /src/lib/libc/gen/closedir.c /src/lib/libc/gen/confstr.c /src/lib/libc/gen/crypt.c /src/lib/libc/gen/ctermid.c /src/lib/libc/gen/daemon.c /src/lib/libc/gen/devname.c /src/lib/libc/gen/dirname.c /src/lib/libc/gen/disklabel.c /src/lib/libc/gen/dlfcn.c /src/lib/libc/gen/dlfunc.c /src/lib/libc/gen/drand48.c /src/lib/libc/gen/erand48.c /src/lib/libc/gen/err.c /src/lib/libc/gen/errlst.c /src/lib/libc/gen/errno.c /src/lib/libc/gen/exec.c /src/lib/libc/gen/feature_present.c /src/lib/libc/gen/fmtcheck.c /src/lib/libc/gen/fmtmsg.c /src/lib/libc/gen/fnmatch.c /src/lib/libc/gen/fpclassify.c /src/lib/libc/gen/frexp.c /src/lib/libc/gen/fstab.c /src/lib/libc/gen/ftok.c /src/lib/libc/gen/fts.c /src/lib/libc/gen/ftw.c /src/lib/libc/gen/getbootfile.c /src/lib/libc/gen/getbsize.c /src/lib/libc/gen/getcap.c /src/lib/libc/gen/getcwd.c /src/lib/libc/gen/getdomainname.c /src/lib/libc/gen/getgrent.c /src/lib/libc/gen/getgrouplist.c /src/lib/libc/gen/
 gethostname.c /src/lib/libc/gen/getloadavg.c /src/lib/libc/gen/getlogin.c /src/lib/libc/gen/getmntinfo.c /src/lib/libc/gen/getnetgrent.c /src/lib/libc/gen/getosreldate.c /src/lib/libc/gen/getpagesize.c /src/lib/libc/gen/getpeereid.c /src/lib/libc/gen/getprogname.c /src/lib/libc/gen/getpwent.c /src/lib/libc/gen/getttyent.c /src/lib/libc/gen/getusershell.c /src/lib/libc/gen/getvfsbyname.c /src/lib/libc/gen/glob.c /src/lib/libc/gen/initgroups.c /src/lib/libc/gen/isatty.c /src/lib/libc/gen/isinf.c /src/lib/libc/gen/isnan.c /src/lib/libc/gen/jrand48.c /src/lib/libc/gen/lcong48.c /src/lib/libc/gen/lockf.c /src/lib/libc/gen/lrand48.c /src/lib/libc/gen/mrand48.c /src/lib/libc/gen/nftw.c /src/lib/libc/gen/nice.c /src/lib/libc/gen/nlist.c /src/lib/libc/gen/nrand48.c /src/lib/libc/gen/opendir.c /src/lib/libc/gen/pause.c /src/lib/libc/gen/pmadvise.c /src/lib/libc/gen/popen.c /src/lib/libc/gen/posixshm.c /src/lib/libc/gen/pselect.c /src/lib/libc/gen/psignal.c /src/lib/libc/gen/pw_scan.c 
 /src/lib/libc/gen/pwcache.c /src/lib/libc/gen/raise.c /src/lib/libc/gen/readdir.c /src/lib/libc/gen/readpassphrase.c /src/lib/libc/gen/rewinddir.c /src/lib/libc/gen/scandir.c /src/lib/libc/gen/seed48.c /src/lib/libc/gen/seekdir.c /src/lib/libc/gen/sem.c /src/lib/libc/gen/semctl.c /src/lib/libc/gen/setdomainname.c /src/lib/libc/gen/sethostname.c /src/lib/libc/gen/setjmperr.c /src/lib/libc/gen/setmode.c /src/lib/libc/gen/setproctitle.c /src/lib/libc/gen/setprogname.c /src/lib/libc/gen/siginterrupt.c /src/lib/libc/gen/siglist.c /src/lib/libc/gen/signal.c /src/lib/libc/gen/sigsetops.c /src/lib/libc/gen/sleep.c /src/lib/libc/gen/srand48.c /src/lib/libc/gen/statvfs.c /src/lib/libc/gen/stringlist.c /src/lib/libc/gen/strtofflags.c /src/lib/libc/gen/sysconf.c /src/lib/libc/gen/sysctl.c /src/lib/libc/gen/sysctlbyname.c /src/lib/libc/gen/sysctlnametomib.c /src/lib/libc/gen/syslog.c /src/lib/libc/gen/telldir.c /src/lib/libc/gen/termios.c /src/lib/libc/gen/time.c /src/lib/libc/gen/times.
 c /src/lib/libc/gen/timezone.c /src/lib/libc/gen/tls.c /src/lib/libc/gen/ttyname.c /src/lib/libc/gen/ttyslot.c /src/lib/libc/gen/ualarm.c /src/lib/libc/gen/ulimit.c /src/lib/libc/gen/uname.c /src/lib/libc/gen/unvis.c /src/lib/libc/gen/usleep.c /src/lib/libc/gen/utime.c /src/lib/libc/gen/valloc.c /src/lib/libc/gen/vis.c /src/lib/libc/gen/wait.c /src/lib/libc/gen/wait3.c /src/lib/libc/gen/waitpid.c /src/lib/libc/gen/wordexp.c /src/lib/libc/i386/gen/_ctx_start.S /src/lib/libc/i386/gen/_setjmp.S /src/lib/libc/i386/gen/_set_tp.c /src/lib/libc/i386/gen/fabs.S /src/lib/libc/i386/gen/flt_rounds.c /src/lib/libc/i386/gen/infinity.c /src/lib/libc/i386/gen/ldexp.c /src/lib/libc/i386/gen/makecontext.c /src/lib/libc/i386/gen/modf.S /src/lib/libc/i386/gen/rfork_thread.S /src/lib/libc/i386/gen/setjmp.S /src/lib/libc/i386/gen/signalcontext.c /src/lib/libc/i386/gen/sigsetjmp.S /src/lib/libc/gmon/gmon.c /src/lib/libc/gmon/mcount.c /src/lib/libc/inet/inet_addr.c /src/lib/libc/inet/inet_cidr_nto
 p.c /src/lib/libc/inet/inet_cidr_pton.c /src/lib/libc/inet/inet_lnaof.c /src/lib/libc/inet/inet_makeaddr.c /src/lib/libc/inet/inet_net_ntop.c /src/lib/libc/inet/inet_net_pton.c /src/lib/libc/inet/inet_neta.c /src/lib/libc/inet/inet_netof.c /src/lib/libc/inet/inet_network.c /src/lib/libc/inet/inet_ntoa.c /src/lib/libc/inet/inet_ntop.c /src/lib/libc/inet/inet_pton.c /src/lib/libc/inet/nsap_addr.c /src/lib/libc/isc/ev_streams.c /src/lib/libc/isc/ev_timers.c /src/lib/libc/locale/big5.c /src/lib/libc/locale/btowc.c /src/lib/libc/locale/collate.c /src/lib/libc/locale/collcmp.c /src/lib/libc/locale/euc.c /src/lib/libc/locale/fix_grouping.c /src/lib/libc/locale/gb18030.c /src/lib/libc/locale/gb2312.c /src/lib/libc/locale/gbk.c /src/lib/libc/locale/isctype.c /src/lib/libc/locale/iswctype.c /src/lib/libc/locale/ldpart.c /src/lib/libc/locale/lmessages.c /src/lib/libc/locale/lmonetary.c /src/lib/libc/locale/lnumeric.c /src/lib/libc/locale/localeconv.c /src/lib/libc/locale/mblen.c /src/l
 ib/libc/locale/mbrlen.c /src/lib/libc/locale/mbrtowc.c /src/lib/libc/locale/mbsinit.c /src/lib/libc/locale/mbsnrtowcs.c /src/lib/libc/locale/mbsrtowcs.c /src/lib/libc/locale/mbtowc.c /src/lib/libc/locale/mbstowcs.c /src/lib/libc/locale/mskanji.c /src/lib/libc/locale/nextwctype.c /src/lib/libc/locale/nl_langinfo.c /src/lib/libc/locale/nomacros.c /src/lib/libc/locale/none.c /src/lib/libc/locale/rpmatch.c /src/lib/libc/locale/rune.c /src/lib/libc/locale/runetype.c /src/lib/libc/locale/setlocale.c /src/lib/libc/locale/setrunelocale.c /src/lib/libc/locale/table.c /src/lib/libc/locale/tolower.c /src/lib/libc/locale/toupper.c /src/lib/libc/locale/utf8.c /src/lib/libc/locale/wcrtomb.c /src/lib/libc/locale/wcsnrtombs.c /src/lib/libc/locale/wcsrtombs.c /src/lib/libc/locale/wcsftime.c /src/lib/libc/locale/wcstof.c /src/lib/libc/locale/wcstod.c /src/lib/libc/locale/wcstoimax.c /src/lib/libc/locale/wcstol.c /src/lib/libc/locale/wcstold.c /src/lib/libc/locale/wcstoll.c /src/lib/libc/local
 e/wcstombs.c /src/lib/libc/locale/wcstoul.c /src/lib/libc/locale/wcstoull.c /src/lib/libc/locale/wcstoumax.c /src/lib/libc/locale/wctob.c /src/lib/libc/locale/wctomb.c /src/lib/libc/locale/wctrans.c /src/lib/libc/locale/wctype.c /src/lib/libc/locale/wcwidth.c /src/lib/libc/nameser/ns_name.c /src/lib/libc/nameser/ns_netint.c /src/lib/libc/nameser/ns_parse.c /src/lib/libc/nameser/ns_print.c /src/lib/libc/nameser/ns_samedomain.c /src/lib/libc/nameser/ns_ttl.c /src/lib/libc/net/base64.c /src/lib/libc/net/ether_addr.c /src/lib/libc/net/eui64.c /src/lib/libc/net/gai_strerror.c /src/lib/libc/net/getaddrinfo.c /src/lib/libc/net/gethostbydns.c /src/lib/libc/net/gethostbyht.c /src/lib/libc/net/gethostbynis.c /src/lib/libc/net/gethostnamadr.c /src/lib/libc/net/getifaddrs.c /src/lib/libc/net/getifmaddrs.c /src/lib/libc/net/getnameinfo.c /src/lib/libc/net/getnetbydns.c /src/lib/libc/net/getnetbyht.c /src/lib/libc/net/getnetbynis.c /src/lib/libc/net/getnetnamadr.c /src/lib/libc/net/getpro
 to.c /src/lib/libc/net/getprotoent.c /src/lib/libc/net/getprotoname.c /src/lib/libc/net/getservent.c /src/lib/libc/net/if_indextoname.c /src/lib/libc/net/if_nameindex.c /src/lib/libc/net/if_nametoindex.c /src/lib/libc/net/ip6opt.c /src/lib/libc/net/linkaddr.c /src/lib/libc/net/map_v4v6.c /src/lib/libc/net/name6.c /src/lib/libc/net/ntoh.c /src/lib/libc/net/nsdispatch.c nslexer.c nsparser.c /src/lib/libc/net/nss_compat.c /src/lib/libc/net/rcmd.c /src/lib/libc/net/rcmdsh.c /src/lib/libc/net/recv.c /src/lib/libc/net/rthdr.c /src/lib/libc/net/sctp_sys_calls.c /src/lib/libc/net/send.c /src/lib/libc/net/sockatmark.c /src/lib/libc/net/sourcefilter.c /src/lib/libc/net/vars.c /src/lib/libc/net/nscache.c /src/lib/libc/net/nscachedcli.c /src/lib/libc/nls/msgcat.c /src/lib/libc/posix1e/acl_calc_mask.c /src/lib/libc/posix1e/acl_copy.c /src/lib/libc/posix1e/acl_delete.c /src/lib/libc/posix1e/acl_delete_entry.c /src/lib/libc/posix1e/acl_entry.c /src/lib/libc/posix1e/acl_free.c /src/lib/libc
 /posix1e/acl_from_text.c /src/lib/libc/posix1e/acl_get.c /src/lib/libc/posix1e/acl_init.c /src/lib/libc/posix1e/acl_perm.c /src/lib/libc/posix1e/acl_set.c /src/lib/libc/posix1e/acl_support.c /src/lib/libc/posix1e/acl_to_text.c /src/lib/libc/posix1e/acl_valid.c /src/lib/libc/posix1e/extattr.c /src/lib/libc/posix1e/mac.c /src/lib/libc/posix1e/mac_exec.c /src/lib/libc/posix1e/mac_get.c /src/lib/libc/posix1e/mac_set.c /src/lib/libc/quad/cmpdi2.c /src/lib/libc/quad/divdi3.c /src/lib/libc/quad/moddi3.c /src/lib/libc/quad/qdivrem.c /src/lib/libc/quad/ucmpdi2.c /src/lib/libc/quad/udivdi3.c /src/lib/libc/quad/umoddi3.c /src/lib/libc/regex/regcomp.c /src/lib/libc/regex/regerror.c /src/lib/libc/regex/regexec.c /src/lib/libc/regex/regfree.c /src/lib/libc/resolv/herror.c /src/lib/libc/resolv/h_errno.c /src/lib/libc/resolv/mtctxres.c /src/lib/libc/resolv/res_comp.c /src/lib/libc/resolv/res_data.c /src/lib/libc/resolv/res_debug.c /src/lib/libc/resolv/res_findzonecut.c /src/lib/libc/resolv/
 res_init.c /src/lib/libc/resolv/res_mkquery.c /src/lib/libc/resolv/res_mkupdate.c /src/lib/libc/resolv/res_query.c /src/lib/libc/resolv/res_send.c /src/lib/libc/resolv/res_state.c /src/lib/libc/resolv/res_update.c /src/lib/libc/stdio/_flock_stub.c /src/lib/libc/stdio/asprintf.c /src/lib/libc/stdio/clrerr.c /src/lib/libc/stdio/fclose.c /src/lib/libc/stdio/fcloseall.c /src/lib/libc/stdio/fdopen.c /src/lib/libc/stdio/feof.c /src/lib/libc/stdio/ferror.c /src/lib/libc/stdio/fflush.c /src/lib/libc/stdio/fgetc.c /src/lib/libc/stdio/fgetln.c /src/lib/libc/stdio/fgetpos.c /src/lib/libc/stdio/fgets.c /src/lib/libc/stdio/fgetwc.c /src/lib/libc/stdio/fgetwln.c /src/lib/libc/stdio/fgetws.c /src/lib/libc/stdio/fileno.c /src/lib/libc/stdio/findfp.c /src/lib/libc/stdio/flags.c /src/lib/libc/stdio/fopen.c /src/lib/libc/stdio/fprintf.c /src/lib/libc/stdio/fpurge.c /src/lib/libc/stdio/fputc.c /src/lib/libc/stdio/fputs.c /src/lib/libc/stdio/fputwc.c /src/lib/libc/stdio/fputws.c /src/lib/libc/st
 dio/fread.c /src/lib/libc/stdio/freopen.c /src/lib/libc/stdio/fscanf.c /src/lib/libc/stdio/fseek.c /src/lib/libc/stdio/fsetpos.c /src/lib/libc/stdio/ftell.c /src/lib/libc/stdio/funopen.c /src/lib/libc/stdio/fvwrite.c /src/lib/libc/stdio/fwalk.c /src/lib/libc/stdio/fwide.c /src/lib/libc/stdio/fwprintf.c /src/lib/libc/stdio/fwscanf.c /src/lib/libc/stdio/fwrite.c /src/lib/libc/stdio/getc.c /src/lib/libc/stdio/getchar.c /src/lib/libc/stdio/gets.c /src/lib/libc/stdio/getw.c /src/lib/libc/stdio/getwc.c /src/lib/libc/stdio/getwchar.c /src/lib/libc/stdio/makebuf.c /src/lib/libc/stdio/mktemp.c /src/lib/libc/stdio/perror.c /src/lib/libc/stdio/printf.c /src/lib/libc/stdio/putc.c /src/lib/libc/stdio/putchar.c /src/lib/libc/stdio/puts.c /src/lib/libc/stdio/putw.c /src/lib/libc/stdio/putwc.c /src/lib/libc/stdio/putwchar.c /src/lib/libc/stdio/refill.c /src/lib/libc/stdio/remove.c /src/lib/libc/stdio/rewind.c /src/lib/libc/stdio/rget.c /src/lib/libc/stdio/scanf.c /src/lib/libc/stdio/setbuf.
 c /src/lib/libc/stdio/setbuffer.c /src/lib/libc/stdio/setvbuf.c /src/lib/libc/stdio/snprintf.c /src/lib/libc/stdio/sprintf.c /src/lib/libc/stdio/sscanf.c /src/lib/libc/stdio/stdio.c /src/lib/libc/stdio/swprintf.c /src/lib/libc/stdio/swscanf.c /src/lib/libc/stdio/tempnam.c /src/lib/libc/stdio/tmpfile.c /src/lib/libc/stdio/tmpnam.c /src/lib/libc/stdio/ungetc.c /src/lib/libc/stdio/ungetwc.c /src/lib/libc/stdio/unlocked.c /src/lib/libc/stdio/vasprintf.c /src/lib/libc/stdio/vfprintf.c /src/lib/libc/stdio/vfscanf.c /src/lib/libc/stdio/vfwprintf.c /src/lib/libc/stdio/vfwscanf.c /src/lib/libc/stdio/vprintf.c /src/lib/libc/stdio/vscanf.c /src/lib/libc/stdio/vsnprintf.c /src/lib/libc/stdio/vsprintf.c /src/lib/libc/stdio/vsscanf.c /src/lib/libc/stdio/vswprintf.c /src/lib/libc/stdio/vswscanf.c /src/lib/libc/stdio/vwprintf.c /src/lib/libc/stdio/vwscanf.c /src/lib/libc/stdio/wbuf.c /src/lib/libc/stdio/wprintf.c /src/lib/libc/stdio/wscanf.c /src/lib/libc/stdio/wsetup.c /src/lib/libc/stdio/
 xprintf.c /src/lib/libc/stdio/xprintf_float.c /src/lib/libc/stdio/xprintf_int.c /src/lib/libc/stdio/xprintf_str.c /src/lib/libc/stdio/xprintf_errno.c /src/lib/libc/stdio/xprintf_hexdump.c /src/lib/libc/stdio/xprintf_quote.c /src/lib/libc/stdio/xprintf_time.c /src/lib/libc/stdio/xprintf_vis.c /src/lib/libc/stdtime/asctime.c /src/lib/libc/stdtime/difftime.c /src/lib/libc/stdtime/localtime.c /src/lib/libc/stdtime/strftime.c /src/lib/libc/stdtime/strptime.c /src/lib/libc/stdtime/timelocal.c /src/lib/libc/stdtime/time32.c /src/lib/libc/i386/sys/i386_clr_watch.c /src/lib/libc/i386/sys/i386_get_ioperm.c /src/lib/libc/i386/sys/i386_set_ioperm.c /src/lib/libc/i386/sys/i386_set_watch.c /src/lib/libc/i386/sys/i386_vm86.c /src/lib/libc/i386/sys/i386_get_fsbase.c /src/lib/libc/i386/sys/i386_get_gsbase.c /src/lib/libc/i386/sys/i386_get_ldt.c /src/lib/libc/i386/sys/i386_set_fsbase.c /src/lib/libc/i386/sys/i386_set_gsbase.c /src/lib/libc/i386/sys/i386_set_ldt.c /src/lib/libc/sys/stack_prote
 ctor.c /src/lib/libc/sys/__error.c /src/lib/libc/sys/fcntl.c /src/lib/libc/sys/ftruncate.c /src/lib/libc/sys/lseek.c /src/lib/libc/sys/mmap.c /src/lib/libc/sys/pread.c /src/lib/libc/sys/pwrite.c /src/lib/libc/sys/truncate.c /src/lib/libc/i386/sys/Ovfork.S /src/lib/libc/i386/sys/brk.S /src/lib/libc/i386/sys/cerror.S /src/lib/libc/i386/sys/exect.S /src/lib/libc/i386/sys/getcontext.S /src/lib/libc/i386/sys/pipe.S /src/lib/libc/i386/sys/ptrace.S /src/lib/libc/i386/sys/reboot.S /src/lib/libc/i386/sys/sbrk.S /src/lib/libc/i386/sys/setlogin.S /src/lib/libc/i386/sys/sigreturn.S /src/lib/libc/i386/sys/syscall.S fork.S read.S write.S open.S close.S wait4.S link.S unlink.S chdir.S fchdir.S mknod.S chmod.S chown.S freebsd4_getfsstat.S getpid.S mount.S unmount.S setuid.S getuid.S geteuid.S recvmsg.S sendmsg.S recvfrom.S accept.S getpeername.S getsockname.S access.S chflags.S fchflags.S sync.S kill.S getppid.S dup.S getegid.S profil.S ktrace.S getgid.S acct.S sigaltstack.S ioctl.S revoke.
 S symlink.S readlink.S execve.S umask.S chroot.S msync.S vadvise.S munmap.S mprotect.S madvise.S mincore.S getgroups.S setgroups.S getpgrp.S setpgid.S setitimer.S swapon.S getitimer.S getdtablesize.S dup2.S fcntl.S select.S fsync.S setpriority.S socket.S connect.S getpriority.S bind.S setsockopt.S listen.S gettimeofday.S getrusage.S getsockopt.S readv.S writev.S settimeofday.S fchown.S fchmod.S setreuid.S setregid.S rename.S flock.S mkfifo.S sendto.S shutdown.S socketpair.S mkdir.S rmdir.S utimes.S adjtime.S setsid.S quotactl.S nlm_syscall.S nfssvc.S freebsd4_statfs.S freebsd4_fstatfs.S lgetfh.S getfh.S sysarch.S rtprio.S semsys.S msgsys.S shmsys.S freebsd6_pread.S freebsd6_pwrite.S setfib.S ntp_adjtime.S setgid.S setegid.S seteuid.S stat.S fstat.S lstat.S pathconf.S fpathconf.S getrlimit.S setrlimit.S getdirentries.S freebsd6_mmap.S __syscall.S freebsd6_lseek.S freebsd6_truncate.S freebsd6_ftruncate.S __sysctl.S mlock.S munlock.S undelete.S futimes.S getpgid.S poll.S freebs
 d7___semctl.S semget.S semop.S freebsd7_msgctl.S msgget.S msgsnd.S msgrcv.S shmat.S freebsd7_shmctl.S shmdt.S shmget.S clock_gettime.S clock_settime.S clock_getres.S ktimer_create.S ktimer_delete.S ktimer_settime.S ktimer_gettime.S ktimer_getoverrun.S nanosleep.S ntp_gettime.S minherit.S rfork.S issetugid.S lchown.S aio_read.S aio_write.S lio_listio.S getdents.S lchmod.S netbsd_lchown.S lutimes.S netbsd_msync.S nstat.S nfstat.S nlstat.S preadv.S pwritev.S freebsd4_fhstatfs.S fhopen.S fhstat.S modnext.S modstat.S modfnext.S modfind.S kldload.S kldunload.S kldfind.S kldnext.S kldstat.S kldfirstmod.S getsid.S setresuid.S setresgid.S aio_return.S aio_suspend.S aio_cancel.S aio_error.S oaio_read.S oaio_write.S olio_listio.S mlockall.S munlockall.S __getcwd.S sched_setparam.S sched_getparam.S sched_setscheduler.S sched_getscheduler.S sched_yield.S sched_get_priority_max.S sched_get_priority_min.S sched_rr_get_interval.S utrace.S freebsd4_sendfile.S kldsym.S jail.S sigprocmask.S si
 gsuspend.S freebsd4_sigaction.S sigpending.S freebsd4_sigreturn.S sigtimedwait.S sigwaitinfo.S __acl_get_file.S __acl_set_file.S __acl_get_fd.S __acl_set_fd.S __acl_delete_file.S __acl_delete_fd.S __acl_aclcheck_file.S __acl_aclcheck_fd.S extattrctl.S extattr_set_file.S extattr_get_file.S extattr_delete_file.S aio_waitcomplete.S getresuid.S getresgid.S kqueue.S kevent.S extattr_set_fd.S extattr_get_fd.S extattr_delete_fd.S __setugid.S eaccess.S nmount.S kse_exit.S kse_wakeup.S kse_create.S kse_thr_interrupt.S kse_release.S __mac_get_proc.S __mac_set_proc.S __mac_get_fd.S __mac_get_file.S __mac_set_fd.S __mac_set_file.S kenv.S lchflags.S uuidgen.S sendfile.S mac_syscall.S getfsstat.S statfs.S fstatfs.S fhstatfs.S ksem_close.S ksem_post.S ksem_wait.S ksem_trywait.S ksem_init.S ksem_open.S ksem_unlink.S ksem_getvalue.S ksem_destroy.S __mac_get_pid.S __mac_get_link.S __mac_set_link.S extattr_set_link.S extattr_get_link.S extattr_delete_link.S __mac_execve.S sigaction.S setcontex
 t.S swapcontext.S swapoff.S __acl_get_link.S __acl_set_link.S __acl_delete_link.S __acl_aclcheck_link.S sigwait.S thr_create.S thr_exit.S thr_self.S thr_kill.S _umtx_lock.S _umtx_unlock.S jail_attach.S extattr_list_fd.S extattr_list_file.S extattr_list_link.S kse_switchin.S ksem_timedwait.S thr_suspend.S thr_wake.S kldunloadf.S audit.S auditon.S getauid.S setauid.S getaudit.S setaudit.S getaudit_addr.S setaudit_addr.S auditctl.S _umtx_op.S thr_new.S sigqueue.S kmq_open.S kmq_setattr.S kmq_timedreceive.S kmq_timedsend.S kmq_notify.S kmq_unlink.S abort2.S thr_set_name.S aio_fsync.S rtprio_thread.S sctp_peeloff.S sctp_generic_sendmsg.S sctp_generic_sendmsg_iov.S sctp_generic_recvmsg.S pread.S pwrite.S mmap.S lseek.S truncate.S ftruncate.S thr_kill2.S cpuset.S cpuset_setid.S cpuset_getid.S cpuset_getaffinity.S cpuset_setaffinity.S closefrom.S __semctl.S msgctl.S shmctl.S _getlogin.S _exit.S _pread.S _pwrite.S _lseek.S _mmap.S _ftruncate.S _truncate.S _fcntl.S /src/lib/libc/rpc/a
 uth_none.c /src/lib/libc/rpc/auth_unix.c /src/lib/libc/rpc/authunix_prot.c /src/lib/libc/rpc/bindresvport.c /src/lib/libc/rpc/clnt_bcast.c /src/lib/libc/rpc/clnt_dg.c /src/lib/libc/rpc/clnt_generic.c /src/lib/libc/rpc/clnt_perror.c /src/lib/libc/rpc/clnt_raw.c /src/lib/libc/rpc/clnt_simple.c /src/lib/libc/rpc/clnt_vc.c /src/lib/libc/rpc/rpc_dtablesize.c /src/lib/libc/rpc/getnetconfig.c /src/lib/libc/rpc/getnetpath.c /src/lib/libc/rpc/getrpcent.c /src/lib/libc/rpc/getrpcport.c /src/lib/libc/rpc/mt_misc.c /src/lib/libc/rpc/pmap_clnt.c /src/lib/libc/rpc/pmap_getmaps.c /src/lib/libc/rpc/pmap_getport.c /src/lib/libc/rpc/pmap_prot.c /src/lib/libc/rpc/pmap_prot2.c /src/lib/libc/rpc/pmap_rmt.c /src/lib/libc/rpc/rpc_prot.c /src/lib/libc/rpc/rpc_commondata.c /src/lib/libc/rpc/rpc_callmsg.c /src/lib/libc/rpc/rpc_generic.c /src/lib/libc/rpc/rpc_soc.c /src/lib/libc/rpc/rpcb_clnt.c /src/lib/libc/rpc/rpcb_prot.c /src/lib/libc/rpc/rpcb_st_xdr.c /src/lib/libc/rpc/svc.c /src/lib/libc/rpc/svc_
 auth.c /src/lib/libc/rpc/svc_dg.c /src/lib/libc/rpc/svc_auth_unix.c /src/lib/libc/rpc/svc_generic.c /src/lib/libc/rpc/svc_raw.c /src/lib/libc/rpc/svc_run.c /src/lib/libc/rpc/svc_simple.c /src/lib/libc/rpc/svc_vc.c /src/lib/libc/rpc/auth_time.c /src/lib/libc/rpc/auth_des.c /src/lib/libc/rpc/authdes_prot.c /src/lib/libc/rpc/des_crypt.c /src/lib/libc/rpc/des_soft.c /src/lib/libc/rpc/crypt_client.c /src/lib/libc/rpc/key_call.c /src/lib/libc/rpc/key_prot_xdr.c /src/lib/libc/rpc/getpublickey.c /src/lib/libc/rpc/svc_auth_des.c /src/lib/libc/rpc/netname.c /src/lib/libc/rpc/netnamer.c /src/lib/libc/rpc/rpcdname.c /src/lib/libc/rpc/rtime.c crypt_clnt.c crypt_xdr.c /src/lib/libc/uuid/uuid_compare.c /src/lib/libc/uuid/uuid_create.c /src/lib/libc/uuid/uuid_create_nil.c /src/lib/libc/uuid/uuid_equal.c /src/lib/libc/uuid/uuid_from_string.c /src/lib/libc/uuid/uuid_hash.c /src/lib/libc/uuid/uuid_is_nil.c /src/lib/libc/uuid/uuid_stream.c /src/lib/libc/uuid/uuid_to_string.c /src/lib/libc/xdr/x
 dr.c /src/lib/libc/xdr/xdr_array.c /src/lib/libc/xdr/xdr_float.c /src/lib/libc/xdr/xdr_mem.c /src/lib/libc/xdr/xdr_rec.c /src/lib/libc/xdr/xdr_reference.c /src/lib/libc/xdr/xdr_stdio.c /src/lib/libc/yp/xdryp.c yp_xdr.c /src/lib/libc/yp/yplib.c /src/lib/libc/gdtoa/machdep_ldisx.c /src/lib/libc/i386/stdlib/abs.S /src/lib/libc/i386/stdlib/div.S /src/lib/libc/i386/stdlib/labs.S /src/lib/libc/i386/stdlib/ldiv.S /src/lib/libc/i386/string/bcmp.S /src/lib/libc/i386/string/bcopy.S /src/lib/libc/i386/string/bzero.S /src/lib/libc/i386/string/ffs.S /src/lib/libc/i386/string/index.S /src/lib/libc/i386/string/memchr.S /src/lib/libc/i386/string/memcmp.S /src/lib/libc/i386/string/memcpy.S /src/lib/libc/i386/string/memmove.S /src/lib/libc/i386/string/memset.S /src/lib/libc/i386/string/rindex.S /src/lib/libc/i386/string/strcat.S /src/lib/libc/i386/string/strchr.S /src/lib/libc/i386/string/strcmp.S /src/lib/libc/i386/string/strcpy.S /src/lib/libc/i386/string/strlen.S /src/lib/libc/i386/string/
 strncmp.S /src/lib/libc/i386/string/strrchr.S /src/lib/libc/i386/string/swab.S /src/lib/libc/i386/string/wcschr.S /src/lib/libc/i386/string/wcscmp.S /src/lib/libc/i386/string/wcslen.S /src/lib/libc/i386/string/wmemchr.S /src/lib/libc/gdtoa/_hdtoa.c /src/lib/libc/gdtoa/_ldtoa.c /src/lib/libc/gdtoa/glue.c gdtoa_strtopx.c gdtoa_dmisc.c gdtoa_dtoa.c gdtoa_gdtoa.c gdtoa_gethex.c gdtoa_gmisc.c gdtoa_hd_init.c gdtoa_hexnan.c gdtoa_misc.c gdtoa_smisc.c gdtoa_strtod.c gdtoa_strtodg.c gdtoa_strtof.c gdtoa_strtord.c gdtoa_sum.c gdtoa_ulp.c /src/lib/libc/stdlib/_Exit.c /src/lib/libc/stdlib/a64l.c /src/lib/libc/stdlib/abort.c /src/lib/libc/stdlib/atexit.c /src/lib/libc/stdlib/atof.c /src/lib/libc/stdlib/atoi.c /src/lib/libc/stdlib/atol.c /src/lib/libc/stdlib/atoll.c /src/lib/libc/stdlib/bsearch.c /src/lib/libc/stdlib/exit.c /src/lib/libc/stdlib/getenv.c /src/lib/libc/stdlib/getopt.c /src/lib/libc/stdlib/getopt_long.c /src/lib/libc/stdlib/getsubopt.c /src/lib/libc/stdlib/grantpt.c /src/li
 b/libc/stdlib/hcreate.c /src/lib/libc/stdlib/heapsort.c /src/lib/libc/stdlib/imaxabs.c /src/lib/libc/stdlib/imaxdiv.c /src/lib/libc/stdlib/insque.c /src/lib/libc/stdlib/l64a.c /src/lib/libc/stdlib/llabs.c /src/lib/libc/stdlib/lldiv.c /src/lib/libc/stdlib/lsearch.c /src/lib/libc/stdlib/malloc.c /src/lib/libc/stdlib/merge.c /src/lib/libc/stdlib/qsort.c /src/lib/libc/stdlib/qsort_r.c /src/lib/libc/stdlib/radixsort.c /src/lib/libc/stdlib/rand.c /src/lib/libc/stdlib/random.c /src/lib/libc/stdlib/reallocf.c /src/lib/libc/stdlib/realpath.c /src/lib/libc/stdlib/remque.c /src/lib/libc/stdlib/strfmon.c /src/lib/libc/stdlib/strtoimax.c /src/lib/libc/stdlib/strtol.c /src/lib/libc/stdlib/strtoll.c /src/lib/libc/stdlib/strtoq.c /src/lib/libc/stdlib/strtoul.c /src/lib/libc/stdlib/strtonum.c /src/lib/libc/stdlib/strtoull.c /src/lib/libc/stdlib/strtoumax.c /src/lib/libc/stdlib/strtouq.c /src/lib/libc/stdlib/system.c /src/lib/libc/stdlib/tdelete.c /src/lib/libc/stdlib/tfind.c /src/lib/libc/st
 dlib/tsearch.c /src/lib/libc/stdlib/twalk.c /src/lib/libc/string/ffsl.c /src/lib/libc/string/ffsll.c /src/lib/libc/string/fls.c /src/lib/libc/string/flsl.c /src/lib/libc/string/flsll.c /src/lib/libc/string/memccpy.c /src/lib/libc/string/memrchr.c /src/lib/libc/string/memmem.c /src/lib/libc/string/stpcpy.c /src/lib/libc/string/strcasecmp.c /src/lib/libc/string/strcasestr.c /src/lib/libc/string/strcoll.c /src/lib/libc/string/strcspn.c /src/lib/libc/string/strdup.c /src/lib/libc/string/strerror.c /src/lib/libc/string/strlcat.c /src/lib/libc/string/strlcpy.c /src/lib/libc/string/strmode.c /src/lib/libc/string/strncat.c /src/lib/libc/string/strncpy.c /src/lib/libc/string/strndup.c /src/lib/libc/string/strnstr.c /src/lib/libc/string/strpbrk.c /src/lib/libc/string/strsep.c /src/lib/libc/string/strsignal.c /src/lib/libc/string/strspn.c /src/lib/libc/string/strstr.c /src/lib/libc/string/strtok.c /src/lib/libc/string/strxfrm.c /src/lib/libc/string/wcscat.c /src/lib/libc/string/wcscoll
 .c /src/lib/libc/string/wcscpy.c /src/lib/libc/string/wcscspn.c /src/lib/libc/string/wcsdup.c /src/lib/libc/string/wcslcat.c /src/lib/libc/string/wcslcpy.c /src/lib/libc/string/wcsncat.c /src/lib/libc/string/wcsncmp.c /src/lib/libc/string/wcsncpy.c /src/lib/libc/string/wcspbrk.c /src/lib/libc/string/wcsrchr.c /src/lib/libc/string/wcsspn.c /src/lib/libc/string/wcsstr.c /src/lib/libc/string/wcstok.c /src/lib/libc/string/wcswidth.c /src/lib/libc/string/wcsxfrm.c /src/lib/libc/string/wmemcmp.c /src/lib/libc/string/wmemcpy.c /src/lib/libc/string/wmemmove.c /src/lib/libc/string/wmemset.c
In file included from /src/lib/libc/gen/setproctitle.c:27:
/obj/pc98/src/tmp/usr/include/vm/vm.h:64:24: error: machine/vm.h: No such file or directory
mkdep: compile failed
*** Error code 1

Stop in /src/lib/libc.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
TB --- 2009-09-05 00:23:19 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2009-09-05 00:23:19 - ERROR: failed to build world
TB --- 2009-09-05 00:23:19 - 572.10 user 52.13 system 755.02 real


http://tinderbox.des.no/tinderbox-releng_7-RELENG_7-i386-pc98.full
From thierry at FreeBSD.org  Sat Sep  5 11:06:47 2009
From: thierry at FreeBSD.org (Thierry Thomas)
Date: Sat Sep  5 11:06:54 2009
Subject: ifconfig_ed0="DHCP" does not work on 8.0-BETA3
In-Reply-To: <20090904215747.GB82231@lor.one-eyed-alien.net>
References: <20090904173811.GA45176@graf.pompo.net>
	<20090904214148.GB9950@michelle.cdnetworks.com>
	<20090904215747.GB82231@lor.one-eyed-alien.net>
Message-ID: <20090905110635.GG87716@graf.pompo.net>

Le Ven  4 sep 09 ? 23:57:47 +0200, Brooks Davis <brooks@freebsd.org>
 ?crivait?:
 
> This is a know issue with some devices supported by ed(4).  You can work
> around it by changing DHCP to SYNCDHCP which will cause dhclient to
> alwasy start immediatly on that interface instead of waiting for a link
> state change that never happens.

Thanks for the hint!

What about the following patch?

--- man4_ed.4.diff begins here ---
--- src/share/man/man4/ed.4.orig	2009-08-03 10:13:06.000000000 +0200
+++ src/share/man/man4/ed.4	2009-09-05 12:51:51.000000000 +0200
@@ -425,3 +425,11 @@
 .Pp
 PC Card attachment supports the D-Link DMF650TX LAN/Modem card's Ethernet
 port only at this time.
+.Pp
+If the line "ed0: link state changed to UP" does not show up in dmesg, the line
+.Pp
+ifconfig_ed0="DHCP"
+.Pp
+in
+.Xr rc.conf 5
+will be ineffective. In this case, replace "DHCP" by "SYNCDHCP".
--- man4_ed.4.diff ends here ---

Don't hesitate to reword it - my englsh can be terrible!

Donation: if someone wants this card for investigations, I can bring it
at EuroBSDCon. It has 2 outputs: 1 RJ45 and 1 coaxial.

Regards,
-- 
Th. Thomas.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090905/1699c811/attachment.pgp
From parv at pair.com  Sat Sep  5 16:12:03 2009
From: parv at pair.com (parv@pair.com)
Date: Sat Sep  5 16:12:10 2009
Subject: FreeBSD 7-STABLE - ath, Atheros 5212 - crash on network activity
In-Reply-To: <20090807155141.GA1877@holstein.holy.cow>
References: <20090807155141.GA1877@holstein.holy.cow>
Message-ID: <20090905161428.GA49849@holstein.holy.cow>

in message <20090807155141.GA1877@holstein.holy.cow>,
wrote parv@pair.com thusly...
>
> I am in the process of upgrading from 6-STABLE to 7-STABLE, but
> have been stymied due to FreeBSD/i386 7 crashing on network
> activity.  Machine is Thinkpad T61 with Atheros 5212 (IBM 802.11
> [abg]) card.
...
> GNU gdb 6.1.1 [FreeBSD]
...
> This GDB was configured as "i386-marcel-freebsd"...
...
> Unread portion of the kernel message buffer:
> panic: operating mode 1
> cpuid = 1
> KDB: stack backtrace:
> db_trace_self_wrapper(c0c260f0,e8fbc8fc,c0852763,c0c5338d,1,...) at db_trace_self_wrapper+0x26
> kdb_backtrace(c0c5338d,1,c0c3326f,e8fbc908,1,...) at kdb_backtrace+0x29
> panic(c0c3326f,1,4,c0c21ab3,ce,...) at panic+0x114
> ieee80211_set_tim(c7aac000,1,c0c345ca,c7,0,c7aad510,c670d22c) at ieee80211_set_tim+0x2d
> ieee80211_pwrsave(c7aac000,c7b1ab00,c0be15cd,62c,c0c30884,...) at ieee80211_pwrsave+0x1f3
> ath_start(c6709000,c6709108,e8fbca08,c08ed81f,c6709000,...) at ath_start+0x4e3
> if_start(c6709000,0,c0c30884,195,2,...) at if_start+0x4f
> ether_output_frame(c6709000,c7b1ab00,6,0,e8fbca2a,...) at ether_output_frame+0x1ce
> ether_output(c6709000,c7b1ab00,e8fbcac0,c6b45e0c,0,...) at ether_output+0x48d
> ieee80211_output(c6709000,c7b1ab00,e8fbcac0,c6b45e0c,c6b402d0,...) at ieee80211_output+0x38
> ip_output(c7b1ab00,0,e8fbcabc,0,0,...) at ip_output+0xa10
> udp_send(c6b051a0,0,c7b1ab00,0,0,...) at udp_send+0x89b
> sosend_dgram(c6b051a0,0,e8fbcbe0,c7b1ab00,0,...) at sosend_dgram+0x359
> sosend(c6b051a0,0,e8fbcbe0,0,0,...) at sosend+0x3f
> kern_sendit(c6b49b40,4,e8fbcc5c,0,0,...) at kern_sendit+0x107
> sendit(0,7844401d,0,0,0,...) at sendit+0xad
> sendto(c6b49b40,e8fbccfc,18,c0c3ea41,c,...) at sendto+0x48
> syscall(e8fbcd38) at syscall+0x2a1
> Xint0x80_syscall() at Xint0x80_syscall+0x20
>  ...

Could anybody please clue me in about what I can do to solve the
problem of ath (Atheros 5212) crashing?  I had also filed the bug,
not much activity on it yet ...

  http://www.freebsd.org/cgi/query-pr.cgi?pr=137592


  - parv

-- 

From thierry.herbelot at free.fr  Sun Sep  6 09:21:23 2009
From: thierry.herbelot at free.fr (Thierry Herbelot)
Date: Sun Sep  6 09:21:30 2009
Subject: Panic in recent 7.2-Stable
Message-ID: <200909061102.40450.thierry.herbelot@free.fr>

Hello,

I'm having a panic with the latest kernel build of my -Stable file server 
(sources cvsupped around yesterday evening, CEST). The panic happens soon 
after entering multi-user :

panic: vm_phys_paddr_to_vm_page: paddr 0xf0000 is not in any segment
KDB: enter: panic
[thread pid 1005 tid 100154 ]
Stopped at      kdb_enter_why+0x3a:     movl    $0,kdb_why
db> where
Tracing pid 1005 tid 100154 td 0x8ecad480
kdb_enter_why(80ba731f,80ba731f,80bc1ad6,fb301a94,fb301a94,...) at 
kdb_enter_why+0x3a
panic(80bc1ad6,f0000,0,8ecad480,0,...) at panic+0xd1
vm_phys_paddr_to_vm_page(f0000,f0000,fb301ad8,1,80a36a78,...) at 
vm_phys_paddr_to_vm_page+0x4d
dev_pager_getpages(92b8d980,fb301c04,1,0,fb301bcc,...) at 
dev_pager_getpages+0xe1
vm_fault(89267bfc,33d90000,1,0,89b0b50c,...) at vm_fault+0x1020
trap_pfault(202,7,8583b900,80cd9800,89b0eb00,...) at trap_pfault+0x15b
trap(fb301d38) at trap+0x247

An excerpt of the dmesg is :

Copyright (c) 1992-2009 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
        The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 7.2-STABLE #35: Sun Sep  6 10:04:40 CEST 2009
    XXX@YYY:/usr/obj/usr/src/sys/GENERIC
Preloaded elf kernel "/boot/kernel/kernel" at 0x8101a000.
Preloaded elf module "/boot/kernel/zfs.ko" at 0x8101a188.
Preloaded elf module "/boot/kernel/opensolaris.ko" at 0x8101a230.
Preloaded elf module "/boot/kernel/snd_cmi.ko" at 0x8101a2e0.
Preloaded elf module "/boot/kernel/sound.ko" at 0x8101a38c.
Preloaded /boot/zfs/zpool.cache "/boot/zfs/zpool.cache" at 0x8101a438.
Preloaded elf module "/boot/kernel/acpi.ko" at 0x8101a490.

The previous kernel is older (around 22 august) and works as expected.

Some idents for the panic kernel are : (ie after SVN rev 196838)
$FreeBSD: src/sys/i386/i386/pmap.c,v 1.594.2.20 2009/09/04 19:59:32 jhb Exp $
$FreeBSD: src/sys/kern/kern_mbuf.c,v 1.32.2.6 2009/09/04 19:59:32 jhb Exp $
$FreeBSD: src/sys/vm/device_pager.c,v 1.84.2.3 2009/09/04 19:59:32 jhb Exp $
$FreeBSD: src/sys/vm/vm_object.c,v 1.385.2.7 2009/09/04 19:59:32 jhb Exp $
$FreeBSD: src/sys/vm/vm_page.c,v 1.357.2.10 2009/09/04 19:59:32 jhb Exp $
$FreeBSD: src/sys/vm/vm_phys.c,v 1.4.2.2 2009/09/04 19:59:32 jhb Exp $

	Cheers

	TfH
From tejblum at yandex-team.ru  Sun Sep  6 10:11:43 2009
From: tejblum at yandex-team.ru (Dmitrij Tejblum)
Date: Sun Sep  6 10:11:51 2009
Subject: Panic in recent 7.2-Stable
In-Reply-To: <200909061102.40450.thierry.herbelot@free.fr>
References: <200909061102.40450.thierry.herbelot@free.fr>
Message-ID: <4AA386B1.9020501@yandex-team.ru>

Thierry Herbelot wrote:
> Hello,
> 
> I'm having a panic with the latest kernel build of my -Stable file server 
> (sources cvsupped around yesterday evening, CEST). The panic happens soon 
> after entering multi-user :
> 
> panic: vm_phys_paddr_to_vm_page: paddr 0xf0000 is not in any segment
> KDB: enter: panic
> [thread pid 1005 tid 100154 ]
> Stopped at      kdb_enter_why+0x3a:     movl    $0,kdb_why
> db> where
> Tracing pid 1005 tid 100154 td 0x8ecad480
> kdb_enter_why(80ba731f,80ba731f,80bc1ad6,fb301a94,fb301a94,...) at 
> kdb_enter_why+0x3a
> panic(80bc1ad6,f0000,0,8ecad480,0,...) at panic+0xd1
> vm_phys_paddr_to_vm_page(f0000,f0000,fb301ad8,1,80a36a78,...) at 
> vm_phys_paddr_to_vm_page+0x4d
> dev_pager_getpages(92b8d980,fb301c04,1,0,fb301bcc,...) at 
> dev_pager_getpages+0xe1
> vm_fault(89267bfc,33d90000,1,0,89b0b50c,...) at vm_fault+0x1020
> trap_pfault(202,7,8583b900,80cd9800,89b0eb00,...) at trap_pfault+0x15b
> trap(fb301d38) at trap+0x247
> 

Similar panic here. I believe, the panic introduced in SVN revision 196838.

For us, the panic is caused by the `dmidecode' program. The dmidecode 
program mmap /dev/mem at offset 0xf0000 and reads on...

From kostikbel at gmail.com  Sun Sep  6 11:35:51 2009
From: kostikbel at gmail.com (Kostik Belousov)
Date: Sun Sep  6 11:35:58 2009
Subject: Panic in recent 7.2-Stable
In-Reply-To: <200909061102.40450.thierry.herbelot@free.fr>
References: <200909061102.40450.thierry.herbelot@free.fr>
Message-ID: <20090906110238.GH47688@deviant.kiev.zoral.com.ua>

On Sun, Sep 06, 2009 at 11:02:39AM +0200, Thierry Herbelot wrote:
> Hello,
> 
> I'm having a panic with the latest kernel build of my -Stable file server 
> (sources cvsupped around yesterday evening, CEST). The panic happens soon 
> after entering multi-user :
> 
> panic: vm_phys_paddr_to_vm_page: paddr 0xf0000 is not in any segment
> KDB: enter: panic
> [thread pid 1005 tid 100154 ]
> Stopped at      kdb_enter_why+0x3a:     movl    $0,kdb_why
> db> where
> Tracing pid 1005 tid 100154 td 0x8ecad480
> kdb_enter_why(80ba731f,80ba731f,80bc1ad6,fb301a94,fb301a94,...) at 
> kdb_enter_why+0x3a
> panic(80bc1ad6,f0000,0,8ecad480,0,...) at panic+0xd1
> vm_phys_paddr_to_vm_page(f0000,f0000,fb301ad8,1,80a36a78,...) at 
> vm_phys_paddr_to_vm_page+0x4d
> dev_pager_getpages(92b8d980,fb301c04,1,0,fb301bcc,...) at 
> dev_pager_getpages+0xe1
> vm_fault(89267bfc,33d90000,1,0,89b0b50c,...) at vm_fault+0x1020
> trap_pfault(202,7,8583b900,80cd9800,89b0eb00,...) at trap_pfault+0x15b
> trap(fb301d38) at trap+0x247
> 
> An excerpt of the dmesg is :
> 
> Copyright (c) 1992-2009 The FreeBSD Project.
> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
>         The Regents of the University of California. All rights reserved.
> FreeBSD is a registered trademark of The FreeBSD Foundation.
> FreeBSD 7.2-STABLE #35: Sun Sep  6 10:04:40 CEST 2009
>     XXX@YYY:/usr/obj/usr/src/sys/GENERIC
> Preloaded elf kernel "/boot/kernel/kernel" at 0x8101a000.
> Preloaded elf module "/boot/kernel/zfs.ko" at 0x8101a188.
> Preloaded elf module "/boot/kernel/opensolaris.ko" at 0x8101a230.
> Preloaded elf module "/boot/kernel/snd_cmi.ko" at 0x8101a2e0.
> Preloaded elf module "/boot/kernel/sound.ko" at 0x8101a38c.
> Preloaded /boot/zfs/zpool.cache "/boot/zfs/zpool.cache" at 0x8101a438.
> Preloaded elf module "/boot/kernel/acpi.ko" at 0x8101a490.
> 
> The previous kernel is older (around 22 august) and works as expected.
> 
> Some idents for the panic kernel are : (ie after SVN rev 196838)
> $FreeBSD: src/sys/i386/i386/pmap.c,v 1.594.2.20 2009/09/04 19:59:32 jhb Exp $
> $FreeBSD: src/sys/kern/kern_mbuf.c,v 1.32.2.6 2009/09/04 19:59:32 jhb Exp $
> $FreeBSD: src/sys/vm/device_pager.c,v 1.84.2.3 2009/09/04 19:59:32 jhb Exp $
> $FreeBSD: src/sys/vm/vm_object.c,v 1.385.2.7 2009/09/04 19:59:32 jhb Exp $
> $FreeBSD: src/sys/vm/vm_page.c,v 1.357.2.10 2009/09/04 19:59:32 jhb Exp $
> $FreeBSD: src/sys/vm/vm_phys.c,v 1.4.2.2 2009/09/04 19:59:32 jhb Exp $

I expect that the following patch, that is the partial merge of r194459,
would fix it. It patches sys/vm/vm_phys.c.

Index: vm_phys.c
===================================================================
--- vm_phys.c	(revision 194458)
+++ vm_phys.c	(revision 194459)
@@ -382,8 +382,7 @@
 		if (pa >= seg->start && pa < seg->end)
 			return (&seg->first_page[atop(pa - seg->start)]);
 	}
-	panic("vm_phys_paddr_to_vm_page: paddr %#jx is not in any segment",
-	    (uintmax_t)pa);
+	return (NULL);
 }
 
 /*
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090906/7bd0fc8c/attachment.pgp
From mikael at t-online.hu  Sun Sep  6 12:51:48 2009
From: mikael at t-online.hu (Mikael Bak)
Date: Sun Sep  6 12:51:55 2009
Subject: Build kernel failure
Message-ID: <4AA3AB97.1050403@t-online.hu>

Hi,

I have installed FreeBSD 7.2 on an old laptop. It's only for fun and
learning.

I wanted to make my console use full 1024x768, so I followed this howto:

http://kimklai.blogspot.com/2007/05/howto-freebsd-console-framebuffer.html

# make buildkernel KERNCONF=GENERICVESA
Gives me after quite long time this error message:

make: don't know how to make /usr/src/sys/sys/gdefs.h. Stop
*** Error code 2

Changes to GENERIC:

+options VESA
+options SC_PIXEL_MODE

-options SMP
-device apic
-device eisa

I would like to disable things I don't need, because the laptop is quite
old and slow and don't have too much RAM.

The laptop is an old Dell Latitude CPt C-series, 400MHz PII, 256 MB RAM,
6.5GB HDD.

If I succeed I will try to disable other thing in the kernel to optimize
even more. But perhaps I managed to disable somethig vital?

TIA,
Mikael
From mikael at t-online.hu  Sun Sep  6 13:12:46 2009
From: mikael at t-online.hu (Mikael Bak)
Date: Sun Sep  6 13:12:52 2009
Subject: Build kernel failure
In-Reply-To: <4AA3AB97.1050403@t-online.hu>
References: <4AA3AB97.1050403@t-online.hu>
Message-ID: <4AA3B548.9000500@t-online.hu>

Mikael Bak wrote:
> -options SMP
> -device apic
> -device eisa
> 

Responding to myself.
I reactivated the above options, and now I get a different error:

/usr/src/sys/dev/aic7xxx/aic7xxx.c:7896: internal compiler error: in
output_constructor, at varasm.c:4311
[snip]
*** Error code 1

I installed kernel source using sysinstall using an FTP mirror as
described here:
http://www.freebsd.org/doc/en/books/handbook/kernelconfig-building.html

Did I perhaps miss installing something?

TIA,
Mikael

From thierry.herbelot at free.fr  Sun Sep  6 14:10:22 2009
From: thierry.herbelot at free.fr (Thierry Herbelot)
Date: Sun Sep  6 14:10:31 2009
Subject: Panic in recent 7.2-Stable
In-Reply-To: <20090906110238.GH47688@deviant.kiev.zoral.com.ua>
References: <200909061102.40450.thierry.herbelot@free.fr>
	<20090906110238.GH47688@deviant.kiev.zoral.com.ua>
Message-ID: <200909061610.03858.thierry.herbelot@free.fr>

Le Sunday 06 September 2009, Kostik Belousov a ?crit :
>
> I expect that the following patch, that is the partial merge of r194459,
> would fix it. It patches sys/vm/vm_phys.c.
>
> Index: vm_phys.c
> ===================================================================
> --- vm_phys.c	(revision 194458)
> +++ vm_phys.c	(revision 194459)
> @@ -382,8 +382,7 @@
>  		if (pa >= seg->start && pa < seg->end)
>  			return (&seg->first_page[atop(pa - seg->start)]);
>  	}
> -	panic("vm_phys_paddr_to_vm_page: paddr %#jx is not in any segment",
> -	    (uintmax_t)pa);
> +	return (NULL);

This seems indeed the missing part : I should have looked in -current  ....

	Thanks

	TfH
>  }
>
>  /*


From rizzo at iet.unipi.it  Sun Sep  6 15:46:04 2009
From: rizzo at iet.unipi.it (Luigi Rizzo)
Date: Sun Sep  6 15:46:11 2009
Subject: incorrect usleep/select delays with HZ > 2500
Message-ID: <20090906155154.GA8283@onelab2.iet.unipi.it>

(this problem seems to affect both current and -stable,
so let's see if here i have better luck)

I just noticed [Note 1,2] that when setting HZ > 2500 (even if it is
an exact divisor of the APIC/CPU clock) there is a significant
drift between the delays generated by usleep()/select() and those
computed by gettimeofday().  In other words, the error grows with
the amount of delay requested.

To show the problem, try this function

        int f(int wait_time) {  // wait_time in usec
                struct timeval start, end;
                gettimeofday(&start);
                usleep(w);      // or try select
                gettimeofday(&end)
                timersub(&end, &start, &x);
                return = x.tv_usec + 1000000*x.tv_sec - wait_time;
        }

for various HZ (kern.hz=NNNN in /boot/loader.conf) and wait times.
Ideally, we would expect the timings to be in error by something
between 0 and 1 (or 2) ticks, irrespective of the value of wait_time.
In fact, this is what you see with HZ=1000, 2000 and 2500.
But larger values of HZ (e.g. 4000, 5000, 10k, 40k) create
a drift of 0.5% and above (i.e. with HZ=5000, a 1-second delay
lasts 1.0064s and a 10s delay lasts 10.062s; with HZ=10k the
error becomes 1% and at HZ=40k the error becomes even bigger.

Note that with the fixes described below, even HZ=40k works perfectly well.

Turns out that the error has three components (described with
possible fixes):

1.  CAUSE: Errors in the measurement of the TSC (and APIC) frequencies,
        see [Note 3] for more details. This is responsible for the drift.
    FIX: It can be removed by rounding the measurement to the closest
        nominal values (e.g. my APIC runs at 100 MHz; we can use a
        table of supported values). Otherwise, see [Note 4]
    PROBLEM: is this general enough ?

2.  CAUSE: Use of approximate kernel time functions (getnanotime/getmicrotime)
        in nanosleep() and select(). This imposes an error of max(1tick, 1ms)
        in the computation of delays, irrespective of HZ values.
        BTW For reasons I don't understand this seems to affect
        nanosleep() more than select().
    FIX: It can be reduced to just 1 tick making kern.timecounter.tick writable
        and letting the user set it to 1 if high precision is required.
    PROBLEM: none that i see.

3.  CAUSE an error in tvtohz(), reported long ago in
        http://www.dragonflybsd.org/presentations/nanosleep/
        which causes a systematic error of an extra tick in the computation
        of the sleep times.
    FIX: the above link also contains a proposed fix (which in fact
	reverts a bug introduced in some old commit on FreeBSD)
    PROBLEM: none that i see.

Applying these three fixes i was able to run a kernel with HZ=40000
and see timing errors within 80-90us even with ten second delays.
This would put us on par with Linux [Note 5].
This is a significant improvement over the current situation
and the reason why I would like to explore the possibility of applying
some of these fixes.

I know there are open problems -- e.g. when the timer source used
by gettimeofday() gets corrected by ntp or other things, hardclock()
still ticks at the same rate so you'll see a drift if you don't apply
corrections there as well. Similarly, if HZ is not an exact
divisor of the clock source used by gettimeofday(), i suppose
errors will accumulate as well. However fixing these other
drift seems reasonably orthogonal at least to #2 and #3 above, and
a lot more difficult so we could at least start from these simple
fixes.


Would anyone be interested in reproducing the experiment (test program
attached -- run it with 'lat -p -i wait_time_in_microseconds')
and try to explain me what changes the system's behaviour above HZ=2500 ?

	cheers
	luigi

Notes:

[Note 1] I have some interest in running machines with high HZ values
    because this gives better precision to dummynet and various
    other tasks with soft timing constraints.

[Note 2] I have seen the same phenomenon on the following platform:
        RELENG_8/amd64 with AMD BE-2400 dual core cpu
        RELENG_7/i386 with AMD BE-2400 dual core cpu
        RELENG_7/i386 with Intel Centrino single core (Dell X1 Laptop)


[Note 3] the TSC frequency is computed reading the tsc around a
        call to DELAY(1000000) and assuming that the i8254 runs
        at the nominal rate, 1.193182 MHz.
        From tests I have made, the measurement in init_TSC() returns
        a large error when HZ is large, whereas repeating the measurement
        at a later time returns a much more reliable value.
        As an example, see the following:

    Sep  6 14:21:59 lr kernel: TSC clock: at init_TSC 2323045616 Hz
    Sep  6 14:21:59 lr kernel: Features=0x178bfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT>
    Sep  6 14:21:59 lr kernel: AMD Features=0xea500800<SYSCALL,NX,MMX+,FFXSR,RDTSCP,LM,3DNow!+,3DNow!>
    Sep  6 14:21:59 lr kernel: TSC: P-state invariant
    Sep  6 14:21:59 lr kernel: TSC clock: at cpu_startup_end 2323056910 Hz
    Sep  6 14:21:59 lr kernel: TSC clock: at acpi_timer_probe 2311254060 Hz
    Sep  6 14:21:59 lr kernel: TSC clock: at acpi_timer_probe_2 2311191310 Hz
    Sep  6 14:21:59 lr kernel: TSC clock: at pn_probe_start 2300822648 Hz
    Sep  6 14:21:59 lr kernel: TSC clock: at pn_attach_start 2300830946 Hz
    Sep  6 14:21:59 lr kernel: TSC clock: at pn_probe_start 2300840133 Hz
    Sep  6 14:21:59 lr kernel: TSC clock: at pn_attach_start 2300835253 Hz
    Sep  6 14:21:59 lr kernel: TSC clock: at lapic_setup_clock 2300868376 Hz

        The latter values are close to what is reported when HZ=1000.

[Note 4] DELAY() uses the TSC when available, but perhaps for
        larger intervals (say above 100ms) it might be better
        to always use the 8254 which at least does not change frequency
        over time ?

[Note 5] Linux has some high precision timers which one could expect
    to use for high precision delays. In fact, I ran the test
    program on a recent Linux 2.6.30 (using HZ=1000), and the
    usleep() version has an error between 80 and 90us irrespective
    of the delay. However the select() version is much worse,
    and loses approx 1ms per second.

------------------------------------------------------
From kostikbel at gmail.com  Sun Sep  6 16:02:57 2009
From: kostikbel at gmail.com (Kostik Belousov)
Date: Sun Sep  6 16:03:04 2009
Subject: Panic in recent 7.2-Stable
In-Reply-To: <200909061537.n86FbqhP001617@satellite.xs4all.nl>
References: <20090906110238.GH47688@deviant.kiev.zoral.com.ua>
	<200909061537.n86FbqhP001617@satellite.xs4all.nl>
Message-ID: <20090906160247.GI47688@deviant.kiev.zoral.com.ua>

On Sun, Sep 06, 2009 at 05:37:52PM +0200, A.J. Fonz van Werven wrote:
> Kostik Belousov wrote:
> 
> > I expect that the following patch, that is the partial merge of r194459,
> > would fix it. It patches sys/vm/vm_phys.c.
> > 
> > Index: vm_phys.c
> > ===================================================================
> > --- vm_phys.c	(revision 194458)
> > +++ vm_phys.c	(revision 194459)
> > @@ -382,8 +382,7 @@
> >  		if (pa >= seg->start && pa < seg->end)
> >  			return (&seg->first_page[atop(pa - seg->start)]);
> >  	}
> > -	panic("vm_phys_paddr_to_vm_page: paddr %#jx is not in any segment",
> > -	    (uintmax_t)pa);
> > +	return (NULL);
> >  }
> >  
> >  /*
> 
> Hi,
> 
> A quick grep on the file in question revealed that there are two
> functions that may panic() with "page not in any segment": the
> vm_phys_paddr_to_vm_page() being patched and also the next function
> vm_phys_paddr_to_segind(). I'm not exactly current with the memory
> management code so this may be a very stupid question, but I'll ask it
> anyway: don't both functions need to be patched?

vm_phys_paddr_to_segind is used during vm bootstrap, the call sequence
is vm_page_startup->vm_phys_add_page->vm_phys_paddr_to_segind.

vm_page_startup calls vm_phys_add_page only for pages
that should not cause the mentioned panic in vm_phys_paddr_to_segind,
since it iterates over the pages of the segments created by
vm_phys_create_seg() in vm_phys_init().
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090906/54fc696f/attachment.pgp
From david at catwhisker.org  Sun Sep  6 16:06:33 2009
From: david at catwhisker.org (David Wolfskill)
Date: Sun Sep  6 16:06:40 2009
Subject: panic: vm_phys_paddr_to_vm_page: paddr 0xf8000 is not in any segment
Message-ID: <20090906154454.GN23018@albert.catwhisker.org>

First got this on my laptop (but not my headless build machine) --
each of which is i386 -- yesterday, at r196858; after reverting to
r196827 (from Thursday), then rebuilding stable/7 at r196886, it
recurred.

It appears to be happening when xdm(1) gets started., which is pretty
late in the transition to multi-user mode.

One oddity of which to be aware: all ports (save for misc/compat6x)
are built and installed while running stable/6.  (I track stable/6,
stable/7, and head, as well as track ports, daily, on both the build
machine and the laptop.  As I try to have some time to actually use
the laptop, rather than merely building stuff on it, I don't try
to update the ports collection daily for each of the 3 versions of
the OS I run.  And as the laptop is "user-facing," it tends to have
a lot (863, at last count) of ports installed.)  misc/compat6x was
installed and is updated under stable/7; it is presently at
compat6x-i386-6.4.604000.200810_3 -- updated Sep  4 06:03:18 2009.

For the past couple of weeks (until yesterday), I noticed that
during the attempt to start xdm(1), the laptop (when running stable/7)
would sometimes lock up (i.e., keyboard apparently non-functional;;
mouse non-functional; only thing I could find to make any progress
was a power cycle, then booting single-user & issuing "fsck -p && exit").
Since I wasn't able to get any information, I didn't mention
it here previously, but now aat least I have an apparently consistennt
panic -- but only when running stable/7.

I have no problems runnning xdm(1) under stable/6 (not that that's
a surprise), but I also have no problems runing xdm(1) under head.

I've copied the crashinfo(8) information to a file visible to my
Web server; it may be viewed at
<http://www.catwhisker.org/~david/FreeBSD/core.txt.6>.  I'll paste
the uname info & backtrace here, but for more details, please see that
page.  (Of course, if the details you seek aren't in the crashinfo(8)
output, please just let me know what you seek....)

FreeBSD localhost 7.2-STABLE FreeBSD 7.2-STABLE #935 r196886: Sun Sep  6 05:35:04 PDT 2009     root@g1-69.catwhisker.org:/common/S3/obj/usr/src/sys/CANARY  i386

#0  doadump () at pcpu.h:196
196     pcpu.h: No such file or directory.
        in pcpu.h
(kgdb) #0  doadump () at pcpu.h:196
#1  0xc049a979 in db_fncall (dummy1=1, dummy2=0, dummy3=-1060239008, 
    dummy4=0xc3b6986c "\200@??") at /usr/src/sys/ddb/db_command.c:516
#2  0xc049aefc in db_command (last_cmdp=0xc0c95694, cmd_table=0x0, dopager=1)
    at /usr/src/sys/ddb/db_command.c:413
#3  0xc049b00a in db_command_loop () at /usr/src/sys/ddb/db_command.c:466
#4  0xc049cabd in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_main.c:228
#5  0xc0812406 in kdb_trap (type=3, code=0, tf=0xc3b69a14)
    at /usr/src/sys/kern/subr_kdb.c:524
#6  0xc0af205b in trap (frame=0xc3b69a14) at /usr/src/sys/i386/i386/trap.c:692
#7  0xc0ad5d4b in calltrap () at /usr/src/sys/i386/i386/exception.s:166
#8  0xc081258a in kdb_enter_why (why=0xc0b93e11 "panic", 
    msg=0xc0b93e11 "panic") at cpufunc.h:60
#9  0xc07e55b6 in panic (
    fmt=0xc0bb024d "vm_phys_paddr_to_vm_page: paddr %#jx is not in any segment") at /usr/src/sys/kern/kern_shutdown.c:557
#10 0xc0a504bd in vm_phys_paddr_to_vm_page (pa=1015808)
    at /usr/src/sys/vm/vm_phys.c:385
#11 0xc0a2ec21 in dev_pager_getpages (object=0xc4d29000, m=0xc3b69c04, 
    count=1, reqpage=0) at /usr/src/sys/vm/device_pager.c:240
#12 0xc0a3ae90 in vm_fault (map=0xc4d0d000, vaddr=676900864, 
    fault_type=1 '\001', fault_flags=Variable "fault_flags" is not available.
) at vm_pager.h:130
#13 0xc0af13bb in trap_pfault (frame=0xc3b69d38, usermode=1, eva=676904576)
    at /usr/src/sys/i386/i386/trap.c:833
#14 0xc0af1d27 in trap (frame=0xc3b69d38) at /usr/src/sys/i386/i386/trap.c:399
#15 0xc0ad5d4b in calltrap () at /usr/src/sys/i386/i386/exception.s:166
#16 0x285599c1 in ?? ()
Previous frame inner to this frame (corrupt stack?)
(kgdb) 

Given that last ("Previous frame inner to this frame (corrupt
stack?)"), I'm not at all certain that the backtraace (or the dump)
will be all that useful.  And because of my odd configuration, this
may not be of sufficient interest to merit much expenditure of
anyone else's time.

I'm quite willing to experiment, try patches, or whatnot.  I have
local mirrors of the CVVS & SVN repositories handy.  I'm not much
of a kernel hacker per se, but I am fairly comfortable hacking
sources in general.

I welcome clues.

Thanks.

Peace,
david
-- 
David H. Wolfskill				david@catwhisker.org
Depriving a girl or boy of an opportunity for education is evil.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090906/0d069586/attachment.pgp
From thierry.herbelot at free.fr  Sun Sep  6 16:07:58 2009
From: thierry.herbelot at free.fr (Thierry Herbelot)
Date: Sun Sep  6 16:08:05 2009
Subject: Panic in recent 7.2-Stable
In-Reply-To: <200909061537.n86FbqhP001617@satellite.xs4all.nl>
References: <200909061537.n86FbqhP001617@satellite.xs4all.nl>
Message-ID: <200909061807.40053.thierry.herbelot@free.fr>

Le Sunday 06 September 2009, A.J. "Fonz" van Werven a ?crit :
> Kostik Belousov wrote:
> > I expect that the following patch, that is the partial merge of r194459,
> > would fix it. It patches sys/vm/vm_phys.c.
> >
> > Index: vm_phys.c
> > ===================================================================
> > --- vm_phys.c	(revision 194458)
> > +++ vm_phys.c	(revision 194459)
> > @@ -382,8 +382,7 @@
> >  		if (pa >= seg->start && pa < seg->end)
> >  			return (&seg->first_page[atop(pa - seg->start)]);
> >  	}
> > -	panic("vm_phys_paddr_to_vm_page: paddr %#jx is not in any segment",
> > -	    (uintmax_t)pa);
> > +	return (NULL);
> >  }
> >
> >  /*
>
> Hi,
>
> A quick grep on the file in question revealed that there are two
> functions that may panic() with "page not in any segment": the
> vm_phys_paddr_to_vm_page() being patched and also the next function
> vm_phys_paddr_to_segind(). I'm not exactly current with the memory
> management code so this may be a very stupid question, but I'll ask it
> anyway: don't both functions need to be patched?
>
> My apologies if I'm way off the mark here, but I'm just trying to help.

you are right : there seems the vm handling has been recently updated and 
maybe even "those who know" may not have reviewed/updated all panic 
conditions (removing the panic in vm_phys_paddr_to_vm_page at least allows 
correct operation of a -Stable kernel, like under -Current)

	TfH
>
> Regards,
>
> Alphons


From kostikbel at gmail.com  Sun Sep  6 16:10:05 2009
From: kostikbel at gmail.com (Kostik Belousov)
Date: Sun Sep  6 16:10:12 2009
Subject: panic: vm_phys_paddr_to_vm_page: paddr 0xf8000 is not in any
	segment
In-Reply-To: <20090906154454.GN23018@albert.catwhisker.org>
References: <20090906154454.GN23018@albert.catwhisker.org>
Message-ID: <20090906160955.GJ47688@deviant.kiev.zoral.com.ua>

On Sun, Sep 06, 2009 at 08:44:54AM -0700, David Wolfskill wrote:
> First got this on my laptop (but not my headless build machine) --
> each of which is i386 -- yesterday, at r196858; after reverting to
> r196827 (from Thursday), then rebuilding stable/7 at r196886, it
> recurred.
Please try r196894.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090906/30e8aeeb/attachment.pgp
From a.j.werven at student.utwente.nl  Sun Sep  6 16:12:18 2009
From: a.j.werven at student.utwente.nl (A.J. "Fonz" van Werven)
Date: Sun Sep  6 16:12:24 2009
Subject: Panic in recent 7.2-Stable
In-Reply-To: <20090906110238.GH47688@deviant.kiev.zoral.com.ua>
Message-ID: <200909061537.n86FbqhP001617@satellite.xs4all.nl>

Kostik Belousov wrote:

> I expect that the following patch, that is the partial merge of r194459,
> would fix it. It patches sys/vm/vm_phys.c.
> 
> Index: vm_phys.c
> ===================================================================
> --- vm_phys.c	(revision 194458)
> +++ vm_phys.c	(revision 194459)
> @@ -382,8 +382,7 @@
>  		if (pa >= seg->start && pa < seg->end)
>  			return (&seg->first_page[atop(pa - seg->start)]);
>  	}
> -	panic("vm_phys_paddr_to_vm_page: paddr %#jx is not in any segment",
> -	    (uintmax_t)pa);
> +	return (NULL);
>  }
>  
>  /*

Hi,

A quick grep on the file in question revealed that there are two
functions that may panic() with "page not in any segment": the
vm_phys_paddr_to_vm_page() being patched and also the next function
vm_phys_paddr_to_segind(). I'm not exactly current with the memory
management code so this may be a very stupid question, but I'll ask it
anyway: don't both functions need to be patched?

My apologies if I'm way off the mark here, but I'm just trying to help.

Regards,

Alphons

-- 
All right, that does it Bill [Donahue]. I'm pretty sure that killing
Jesus is not very Christian.
                 -- Pope Benedict XVI, Southpark season 11 episode 5
From a.j.werven at student.utwente.nl  Sun Sep  6 16:19:05 2009
From: a.j.werven at student.utwente.nl (A.J. "Fonz" van Werven)
Date: Sun Sep  6 16:19:11 2009
Subject: panic: vm_phys_paddr_to_vm_page: paddr 0xf8000 is not in
 any segment
In-Reply-To: <20090906154454.GN23018@albert.catwhisker.org>
Message-ID: <200909061618.n86GIo1D040432@satellite.xs4all.nl>

David Wolfskill wrote:

> It appears to be happening when xdm(1) gets started.

I'm getting the same when starting X manually (startx).

> I welcome clues.

A patch has been submitted to this list less than an hour ago and I've
already seen the SVN commit as well. I'm currently rebuilding, you might
want to try the same. Let's hope this fixes it.

Regards,

Alphons

-- 
All right, that does it Bill [Donahue]. I'm pretty sure that killing
Jesus is not very Christian.
                 -- Pope Benedict XVI, Southpark season 11 episode 5
From david at catwhisker.org  Sun Sep  6 17:00:27 2009
From: david at catwhisker.org (David Wolfskill)
Date: Sun Sep  6 17:00:34 2009
Subject: panic: vm_phys_paddr_to_vm_page: paddr 0xf8000 is not in any
	segment
In-Reply-To: <20090906160955.GJ47688@deviant.kiev.zoral.com.ua>
References: <20090906154454.GN23018@albert.catwhisker.org>
	<20090906160955.GJ47688@deviant.kiev.zoral.com.ua>
Message-ID: <20090906170026.GO23018@albert.catwhisker.org>

On Sun, Sep 06, 2009 at 07:09:55PM +0300, Kostik Belousov wrote:
> On Sun, Sep 06, 2009 at 08:44:54AM -0700, David Wolfskill wrote:
> > First got this on my laptop (but not my headless build machine) --
> > each of which is i386 -- yesterday, at r196858; after reverting to
> > r196827 (from Thursday), then rebuilding stable/7 at r196886, it
> > recurred.
> Please try r196894.

Hand-applied; rebuilt.  On reboot, no panic -- thanks!  :-)

[The bad news is that I did get the apparent hang at xdm(8) start-up.
Three out of three tries.... :-{]

Peace,
david
-- 
David H. Wolfskill				david@catwhisker.org
Depriving a girl or boy of an opportunity for education is evil.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090906/72a57788/attachment.pgp
From kostikbel at gmail.com  Sun Sep  6 17:26:26 2009
From: kostikbel at gmail.com (Kostik Belousov)
Date: Sun Sep  6 17:26:32 2009
Subject: panic: vm_phys_paddr_to_vm_page: paddr 0xf8000 is not in any
	segment
In-Reply-To: <20090906170026.GO23018@albert.catwhisker.org>
References: <20090906154454.GN23018@albert.catwhisker.org>
	<20090906160955.GJ47688@deviant.kiev.zoral.com.ua>
	<20090906170026.GO23018@albert.catwhisker.org>
Message-ID: <20090906172612.GK47688@deviant.kiev.zoral.com.ua>

On Sun, Sep 06, 2009 at 10:00:26AM -0700, David Wolfskill wrote:
> On Sun, Sep 06, 2009 at 07:09:55PM +0300, Kostik Belousov wrote:
> > On Sun, Sep 06, 2009 at 08:44:54AM -0700, David Wolfskill wrote:
> > > First got this on my laptop (but not my headless build machine) --
> > > each of which is i386 -- yesterday, at r196858; after reverting to
> > > r196827 (from Thursday), then rebuilding stable/7 at r196886, it
> > > recurred.
> > Please try r196894.
> 
> Hand-applied; rebuilt.  On reboot, no panic -- thanks!  :-)
> 
> [The bad news is that I did get the apparent hang at xdm(8) start-up.
> Three out of three tries.... :-{]

Could you, please, get more details ? I assume that hang occured
during the X server startup, actually.

Does machine respond to the pings ?
If yes, can you ssh into it ?

Also, you might try to install sysinstall/dmidecode and try running
it, to verify that /dev/mem works.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090906/aa3e1f2b/attachment.pgp
From peter at wemm.org  Mon Sep  7 01:08:42 2009
From: peter at wemm.org (Peter Wemm)
Date: Mon Sep  7 01:08:49 2009
Subject: incorrect usleep/select delays with HZ > 2500
In-Reply-To: <20090906155154.GA8283@onelab2.iet.unipi.it>
References: <20090906155154.GA8283@onelab2.iet.unipi.it>
Message-ID: <e7db6d980909061736p4affc054k3fa5070214adc2f8@mail.gmail.com>

On Sun, Sep 6, 2009 at 8:51 AM, Luigi Rizzo<rizzo@iet.unipi.it> wrote:
> (this problem seems to affect both current and -stable,
> so let's see if here i have better luck)
>
> I just noticed [Note 1,2] that when setting HZ > 2500 (even if it is
> an exact divisor of the APIC/CPU clock) there is a significant
> drift between the delays generated by usleep()/select() and those
> computed by gettimeofday(). ?In other words, the error grows with
> the amount of delay requested.
>
> To show the problem, try this function
>
> ? ? ? ?int f(int wait_time) { ?// wait_time in usec
> ? ? ? ? ? ? ? ?struct timeval start, end;
> ? ? ? ? ? ? ? ?gettimeofday(&start);
> ? ? ? ? ? ? ? ?usleep(w); ? ? ?// or try select
> ? ? ? ? ? ? ? ?gettimeofday(&end)
> ? ? ? ? ? ? ? ?timersub(&end, &start, &x);
> ? ? ? ? ? ? ? ?return = x.tv_usec + 1000000*x.tv_sec - wait_time;
> ? ? ? ?}
>
> for various HZ (kern.hz=NNNN in /boot/loader.conf) and wait times.
> Ideally, we would expect the timings to be in error by something
> between 0 and 1 (or 2) ticks, irrespective of the value of wait_time.
> In fact, this is what you see with HZ=1000, 2000 and 2500.
> But larger values of HZ (e.g. 4000, 5000, 10k, 40k) create
> a drift of 0.5% and above (i.e. with HZ=5000, a 1-second delay
> lasts 1.0064s and a 10s delay lasts 10.062s; with HZ=10k the
> error becomes 1% and at HZ=40k the error becomes even bigger.

Technically, it isn't even an error because the sleeps are defined as
'at least' the value specified.  If you're looking for real-time-OS
level performance, you probably need to look at one.

> Note that with the fixes described below, even HZ=40k works perfectly well.
>
> Turns out that the error has three components (described with
> possible fixes):
>
> 1. ?CAUSE: Errors in the measurement of the TSC (and APIC) frequencies,
> ? ? ? ?see [Note 3] for more details. This is responsible for the drift.
> ? ?FIX: It can be removed by rounding the measurement to the closest
> ? ? ? ?nominal values (e.g. my APIC runs at 100 MHz; we can use a
> ? ? ? ?table of supported values). Otherwise, see [Note 4]
> ? ?PROBLEM: is this general enough ?
>
> 2. ?CAUSE: Use of approximate kernel time functions (getnanotime/getmicrotime)
> ? ? ? ?in nanosleep() and select(). This imposes an error of max(1tick, 1ms)
> ? ? ? ?in the computation of delays, irrespective of HZ values.
> ? ? ? ?BTW For reasons I don't understand this seems to affect
> ? ? ? ?nanosleep() more than select().
> ? ?FIX: It can be reduced to just 1 tick making kern.timecounter.tick writable
> ? ? ? ?and letting the user set it to 1 if high precision is required.
> ? ?PROBLEM: none that i see.
>
> 3. ?CAUSE an error in tvtohz(), reported long ago in
> ? ? ? ?http://www.dragonflybsd.org/presentations/nanosleep/
> ? ? ? ?which causes a systematic error of an extra tick in the computation
> ? ? ? ?of the sleep times.
> ? ?FIX: the above link also contains a proposed fix (which in fact
> ? ? ? ?reverts a bug introduced in some old commit on FreeBSD)
> ? ?PROBLEM: none that i see.

This change, as-is, is extremely dangerous.  tsleep/msleep() use a
value of 0 meaning 'forever'.  Changing tvtohz() so that it can now
return 0 for a non-zero tv is setting land-mines all over the place.
There's something like 27 callers of tvtohz() in sys/kern alone, some
of which are used to supply tsleep/msleep() timeouts.  Note that the
dragonflybsd patch above only adds the 'returns 0' check to one single
caller.  You either need to patch all callers of tvtohz() since you've
change the semantics, or add a 'if (ticks == 0) ticks = 1' check (or
checks) in the appropriate places inside tvtohz().

If you don't do it, then you end up with callers of random functions
with very small timeouts instead finding themselves sleeping forever.

> Applying these three fixes i was able to run a kernel with HZ=40000
> and see timing errors within 80-90us even with ten second delays.
> This would put us on par with Linux [Note 5].
> This is a significant improvement over the current situation
> and the reason why I would like to explore the possibility of applying
> some of these fixes.
>
> I know there are open problems -- e.g. when the timer source used
> by gettimeofday() gets corrected by ntp or other things, hardclock()
> still ticks at the same rate so you'll see a drift if you don't apply
> corrections there as well. Similarly, if HZ is not an exact
> divisor of the clock source used by gettimeofday(), i suppose
> errors will accumulate as well. However fixing these other
> drift seems reasonably orthogonal at least to #2 and #3 above, and
> a lot more difficult so we could at least start from these simple
> fixes.
>
>
> Would anyone be interested in reproducing the experiment (test program
> attached -- run it with 'lat -p -i wait_time_in_microseconds')
> and try to explain me what changes the system's behaviour above HZ=2500 ?
>
> ? ? ? ?cheers
> ? ? ? ?luigi
>
> Notes:
>
> [Note 1] I have some interest in running machines with high HZ values
> ? ?because this gives better precision to dummynet and various
> ? ?other tasks with soft timing constraints.
>
> [Note 2] I have seen the same phenomenon on the following platform:
> ? ? ? ?RELENG_8/amd64 with AMD BE-2400 dual core cpu
> ? ? ? ?RELENG_7/i386 with AMD BE-2400 dual core cpu
> ? ? ? ?RELENG_7/i386 with Intel Centrino single core (Dell X1 Laptop)
>
>
> [Note 3] the TSC frequency is computed reading the tsc around a
> ? ? ? ?call to DELAY(1000000) and assuming that the i8254 runs
> ? ? ? ?at the nominal rate, 1.193182 MHz.
> ? ? ? ?From tests I have made, the measurement in init_TSC() returns
> ? ? ? ?a large error when HZ is large, whereas repeating the measurement
> ? ? ? ?at a later time returns a much more reliable value.
> ? ? ? ?As an example, see the following:
>
> ? ?Sep ?6 14:21:59 lr kernel: TSC clock: at init_TSC 2323045616 Hz
> ? ?Sep ?6 14:21:59 lr kernel: Features=0x178bfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT>
> ? ?Sep ?6 14:21:59 lr kernel: AMD Features=0xea500800<SYSCALL,NX,MMX+,FFXSR,RDTSCP,LM,3DNow!+,3DNow!>
> ? ?Sep ?6 14:21:59 lr kernel: TSC: P-state invariant
> ? ?Sep ?6 14:21:59 lr kernel: TSC clock: at cpu_startup_end 2323056910 Hz
> ? ?Sep ?6 14:21:59 lr kernel: TSC clock: at acpi_timer_probe 2311254060 Hz
> ? ?Sep ?6 14:21:59 lr kernel: TSC clock: at acpi_timer_probe_2 2311191310 Hz
> ? ?Sep ?6 14:21:59 lr kernel: TSC clock: at pn_probe_start 2300822648 Hz
> ? ?Sep ?6 14:21:59 lr kernel: TSC clock: at pn_attach_start 2300830946 Hz
> ? ?Sep ?6 14:21:59 lr kernel: TSC clock: at pn_probe_start 2300840133 Hz
> ? ?Sep ?6 14:21:59 lr kernel: TSC clock: at pn_attach_start 2300835253 Hz
> ? ?Sep ?6 14:21:59 lr kernel: TSC clock: at lapic_setup_clock 2300868376 Hz
>
> ? ? ? ?The latter values are close to what is reported when HZ=1000.
>
> [Note 4] DELAY() uses the TSC when available, but perhaps for
> ? ? ? ?larger intervals (say above 100ms) it might be better
> ? ? ? ?to always use the 8254 which at least does not change frequency
> ? ? ? ?over time ?
>
> [Note 5] Linux has some high precision timers which one could expect
> ? ?to use for high precision delays. In fact, I ran the test
> ? ?program on a recent Linux 2.6.30 (using HZ=1000), and the
> ? ?usleep() version has an error between 80 and 90us irrespective
> ? ?of the delay. However the select() version is much worse,
> ? ?and loses approx 1ms per second.
>
> ------------------------------------------------------
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
>




-- 
Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV
"All of this is for nothing if we don't go to the stars" - JMS/B5
"If Java had true garbage collection, most programs would delete
themselves upon execution." -- Robert Sewell
From rizzo at iet.unipi.it  Mon Sep  7 07:16:06 2009
From: rizzo at iet.unipi.it (Luigi Rizzo)
Date: Mon Sep  7 07:16:14 2009
Subject: incorrect usleep/select delays with HZ > 2500
In-Reply-To: <e7db6d980909061736p4affc054k3fa5070214adc2f8@mail.gmail.com>
References: <20090906155154.GA8283@onelab2.iet.unipi.it>
	<e7db6d980909061736p4affc054k3fa5070214adc2f8@mail.gmail.com>
Message-ID: <20090907072159.GA18906@onelab2.iet.unipi.it>

On Sun, Sep 06, 2009 at 05:36:29PM -0700, Peter Wemm wrote:
> On Sun, Sep 6, 2009 at 8:51 AM, Luigi Rizzo<rizzo@iet.unipi.it> wrote:
> > (this problem seems to affect both current and -stable,
> > so let's see if here i have better luck)
> >
> > I just noticed [Note 1,2] that when setting HZ > 2500 (even if it is
> > an exact divisor of the APIC/CPU clock) there is a significant
> > drift between the delays generated by usleep()/select() and those
> > computed by gettimeofday(). ?In other words, the error grows with
> > the amount of delay requested.
> >
> > To show the problem, try this function
> >
> > ? ? ? ?int f(int wait_time) { ?// wait_time in usec
> > ? ? ? ? ? ? ? ?struct timeval start, end;
> > ? ? ? ? ? ? ? ?gettimeofday(&start);
> > ? ? ? ? ? ? ? ?usleep(w); ? ? ?// or try select
> > ? ? ? ? ? ? ? ?gettimeofday(&end)
> > ? ? ? ? ? ? ? ?timersub(&end, &start, &x);
> > ? ? ? ? ? ? ? ?return = x.tv_usec + 1000000*x.tv_sec - wait_time;
> > ? ? ? ?}
> >
> > for various HZ (kern.hz=NNNN in /boot/loader.conf) and wait times.
> > Ideally, we would expect the timings to be in error by something
> > between 0 and 1 (or 2) ticks, irrespective of the value of wait_time.
> > In fact, this is what you see with HZ=1000, 2000 and 2500.
> > But larger values of HZ (e.g. 4000, 5000, 10k, 40k) create
> > a drift of 0.5% and above (i.e. with HZ=5000, a 1-second delay
> > lasts 1.0064s and a 10s delay lasts 10.062s; with HZ=10k the
> > error becomes 1% and at HZ=40k the error becomes even bigger.
> 
> Technically, it isn't even an error because the sleeps are defined as
> 'at least' the value specified.  If you're looking for real-time-OS
> level performance, you probably need to look at one.

I know a non RTOS has limitations on the guarantees it can give.
But with this in mind (e.g.  be happy with something that works as
expected just 'most of the times'), on this specific issue FreeBSD
could behave much better while still remaining technically correct.

> > 3. ?CAUSE an error in tvtohz(), reported long ago in
> > ? ? ? ?http://www.dragonflybsd.org/presentations/nanosleep/
> > ? ? ? ?which causes a systematic error of an extra tick in the computation
> > ? ? ? ?of the sleep times.
> > ? ?FIX: the above link also contains a proposed fix (which in fact
> > ? ? ? ?reverts a bug introduced in some old commit on FreeBSD)
> > ? ?PROBLEM: none that i see.
> 
> This change, as-is, is extremely dangerous.  tsleep/msleep() use a
> value of 0 meaning 'forever'.  Changing tvtohz() so that it can now
> return 0 for a non-zero tv is setting land-mines all over the place.
> There's something like 27 callers of tvtohz() in sys/kern alone, some
> of which are used to supply tsleep/msleep() timeouts.  Note that the
> dragonflybsd patch above only adds the 'returns 0' check to one single
> caller.  You either need to patch all callers of tvtohz() since you've
> change the semantics, or add a 'if (ticks == 0) ticks = 1' check (or
> checks) in the appropriate places inside tvtohz().
> 
> If you don't do it, then you end up with callers of random functions
> with very small timeouts instead finding themselves sleeping forever.

You are right, a proper fix for this third issue should be different
(if we want a fix at all -- I'd be almost satisfied by just
removing the drift).

The simplest option is perhaps to compute a custom value for
nanosleep, select and poll. This would remove the risk of side
effects to other parts of the system, and we could also use the
chance to compensate for the errors that arise when hz*tick !=
1000000 or when we know that hardclock does not run exactly every
'tick' (an integer) microseconds.

	cheers
	luigi
From pluknet at gmail.com  Mon Sep  7 09:37:27 2009
From: pluknet at gmail.com (pluknet)
Date: Mon Sep  7 09:37:34 2009
Subject: svn commit: r196210 - in stable/8/sys: . amd64/include/xen 
	cddl/contrib/opensolaris contrib/dev/acpica contrib/pf dev/ata
	dev/cxgb 
	dev/sound/usb dev/usb dev/usb/controller dev/usb/input dev/usb/mis...
In-Reply-To: <200908141122.n7EBM9ml032712@svn.freebsd.org>
References: <200908141122.n7EBM9ml032712@svn.freebsd.org>
Message-ID: <a31046fc0909070237g65b26be3t1fe2d66322a42805@mail.gmail.com>

2009/8/14 Konstantin Belousov <kib@freebsd.org>:
> Author: kib
> Date: Fri Aug 14 11:22:09 2009
> New Revision: 196210
> URL: http://svn.freebsd.org/changeset/base/196210
>
> Log:
> ?MFC r196206:
> ?Take the number of allocated freeblks into consideration for
> ?softdep_slowdown(), to prevent kernel memory exhaustioni on
> ?mass-truncation.
>
> ?Approved by: ?re (rwatson)
>
[...]

Hi.

Is it scheduled to be merged to stable/7 (and even to stable/6, which
also has this issue)?

Thanks.

> Modified: stable/8/sys/ufs/ffs/ffs_softdep.c
> ==============================================================================
> --- stable/8/sys/ufs/ffs/ffs_softdep.c ?Fri Aug 14 11:17:34 2009 ? ? ? ?(r196209)
> +++ stable/8/sys/ufs/ffs/ffs_softdep.c ?Fri Aug 14 11:22:09 2009 ? ? ? ?(r196210)
> @@ -663,6 +663,8 @@ static int req_clear_inodedeps; ? ? /* synce
> ?static int req_clear_remove; ? /* syncer process flush some freeblks */
> ?#define FLUSH_REMOVE ? ? ? ? ? 2
> ?#define FLUSH_REMOVE_WAIT ? ? ?3
> +static long num_freeblkdep; ? ?/* number of freeblks workitems allocated */
> +
> ?/*
> ?* runtime statistics
> ?*/
> @@ -2223,6 +2225,9 @@ softdep_setup_freeblocks(ip, length, fla
> ? ? ? ?freeblks->fb_uid = ip->i_uid;
> ? ? ? ?freeblks->fb_previousinum = ip->i_number;
> ? ? ? ?freeblks->fb_devvp = ip->i_devvp;
> + ? ? ? ACQUIRE_LOCK(&lk);
> + ? ? ? num_freeblkdep++;
> + ? ? ? FREE_LOCK(&lk);
> ? ? ? ?extblocks = 0;
> ? ? ? ?if (fs->fs_magic == FS_UFS2_MAGIC)
> ? ? ? ? ? ? ? ?extblocks = btodb(fragroundup(fs, ip->i_din2->di_extsize));
> @@ -2815,6 +2820,7 @@ handle_workitem_freeblocks(freeblks, fla
>
> ? ? ? ?ACQUIRE_LOCK(&lk);
> ? ? ? ?WORKITEM_FREE(freeblks, D_FREEBLKS);
> + ? ? ? num_freeblkdep--;
> ? ? ? ?FREE_LOCK(&lk);
> ?}
>
> @@ -5768,7 +5774,8 @@ softdep_slowdown(vp)
> ? ? ? ?max_softdeps_hard = max_softdeps * 11 / 10;
> ? ? ? ?if (num_dirrem < max_softdeps_hard / 2 &&
> ? ? ? ? ? ?num_inodedep < max_softdeps_hard &&
> - ? ? ? ? ? VFSTOUFS(vp->v_mount)->um_numindirdeps < maxindirdeps) {
> + ? ? ? ? ? VFSTOUFS(vp->v_mount)->um_numindirdeps < maxindirdeps &&
> + ? ? ? ? ? num_freeblkdep < max_softdeps_hard) {
> ? ? ? ? ? ? ? ?FREE_LOCK(&lk);
> ? ? ? ? ? ? ? ?return (0);
> ? ? ? ?}


-- 
wbr,
pluknet
From kensmith at buffalo.edu  Mon Sep  7 14:44:30 2009
From: kensmith at buffalo.edu (Ken Smith)
Date: Mon Sep  7 14:44:43 2009
Subject: 8.0-BETA4 Available
Message-ID: <1252333598.56240.23.camel@bauer.cse.buffalo.edu>


The fourth and most likely final BETA build for the FreeBSD 8.0 release
cycle is now available.  We expect the next test build to be the first
if the Release Candidates, RC1.  Since BETA3 many bugs that were
identified from testing done so far were addressed.  Some of the bigger
issues were an mbuf leak along with work done in the general IPv6, jail,
and usb subsystems.  Issues in other areas have been addressed as well.

Due to the issues identified in this early phase of testing the schedule
for release has been pushed back.  The current target for the release
itself is September 29th, with two RC builds between now and then.
Details about the current target schedule along with much more detail
about the current status of the release is available here:

	http://wiki.freebsd.org/8.0TODO

If you notice problems you can report them through the normal Gnats PR
system or on the freebsd-current mailing list.  I do cross-post
announcements to freebsd-stable because this particular release is
"about to become a stable branch" but when it comes to watching for
issues related to the release most of the developers pay more attention
to the freebsd-current list.

ISO images for all supported architectures are available on the FTP
sites, (sparc64 was uploaded a short time ago and may not be available
on some sites yet) and a "memory stick" image is available for
amd64/i386 architectures.  For amd64/i386 architectures the cdrom and
memstick images include the documentation packages this time but no
other packages.  The DVD image includes a first rough pass at what
packages will be available but the list will certainly change between
now and release.  None of the other images include packages.

If you are using csup/cvsup methods to update an older system the branch
tag to use is RELENG_8.

The freebsd-update(8) utility supports binary upgrades of i386 and amd64
systems running earlier FreeBSD releases. Systems running 7.0-RELEASE,
7.1-RELEASE, 7.2-RELEASE, 8.0-BETA1, 8.0-BETA2, or 8.0-BETA3 can upgrade
as follows:
  
# freebsd-update upgrade -r 8.0-BETA4
  
During this process, FreeBSD Update may ask the user to help by merging
some configuration files or by confirming that the automatically
performed merging was done correctly.  Systems running 8.0-BETA3 may
print the warning

	INDEX-OLD.all: Invalid arguments

when downloading updates; this warning is a harmless bug (fixed in
8.0-BETA4) and can be safely ignored.

# freebsd-update install
  
The system must be rebooted with the newly installed kernel before continuing.
  
# shutdown -r now
   
After rebooting, freebsd-update needs to be run again to install the new
userland components:

# freebsd-update install
   
At this point, users of systems being upgraded from FreeBSD 7.x will be
prompted by freebsd-update to rebuild all third-party applications
(e.g., ports installed from the ports tree) due to updates in system
libraries.  See:

http://www.daemonology.net/blog/2009-07-11-freebsd-update-to-8.0-beta1.html

for mode details.  After updating installed third-party applications
(and again, only if freebsd-update printed a message indicating that
this was necessary), run freebsd-update again so that it can delete the
old (no longer used) system libraries:

# freebsd-update install
   
Finally, reboot into 8.0-BETA4:
   
# shutdown -r now

MD5/SHA256 checksums for the image files:

MD5 (8.0-BETA4-amd64-bootonly.iso) = 4215023f0492e959be3c643fef44d448
MD5 (8.0-BETA4-amd64-disc1.iso) = f767d33bbaa0af665e33992c1f43cc39
MD5 (8.0-BETA4-amd64-dvd1.iso) = ac66ea49d75908607c0fe984f88b7a50
MD5 (8.0-BETA4-amd64-livefs.iso) = ead1d6a75cce81a24d3d3b8f0cbc8faf
MD5 (8.0-BETA4-amd64-memstick.img) = 69629e60befe708b4373871af23d61a3

MD5 (8.0-BETA4-i386-bootonly.iso) = db2e16a1a807d124a693743ca7a75992
MD5 (8.0-BETA4-i386-disc1.iso) = 30508ce737aa29d0fe2baf2f450ddc83
MD5 (8.0-BETA4-i386-dvd1.iso) = 307b28a35bcfbb547ce3afbbad051e89
MD5 (8.0-BETA4-i386-livefs.iso) = d65f152bfbd62ea5e3c2e1858bbb89ee
MD5 (8.0-BETA4-i386-memstick.img) = 5d262034175abd24b27ec7110ebd88a7

MD5 (8.0-BETA4-ia64-bootonly.iso) = 5147bd2c2dba2a72ec7f36eb8af0ccb6
MD5 (8.0-BETA4-ia64-disc1.iso) = 4da8a10c19c6642175a13aacf5fbf996
MD5 (8.0-BETA4-ia64-disc2.iso) = 895fca6034ecec7afb99878dbc93ded9
MD5 (8.0-BETA4-ia64-disc3.iso) = 49e440ad63251033bc154b35a48b379e
MD5 (8.0-BETA4-ia64-dvd1.iso) = 52350dd2bd330fa58271819cb82c5e79
MD5 (8.0-BETA4-ia64-livefs.iso) = 93018d3777f360780272188a4473dda5

MD5 (8.0-BETA4-pc98-bootonly.iso) = 3c1340312e19f5a14c46fbce001fbafa
MD5 (8.0-BETA4-pc98-disc1.iso) = 495674329c64d6d60b0d41f0922ac20a
MD5 (8.0-BETA4-pc98-livefs.iso) = ede97f44cbf9c0205ca0b50b0b7900b9

MD5 (8.0-BETA4-powerpc-bootonly.iso) = 71deda0e81c1bfa1c232e85aec7b5852
MD5 (8.0-BETA4-powerpc-disc1.iso) = cb437fe6c588035492d30a4c9a4ec7f9
MD5 (8.0-BETA4-powerpc-disc2.iso) = 2c59a9fcf633c64fe9462967bbd14a93
MD5 (8.0-BETA4-powerpc-disc3.iso) = fb2d9d5a59518d30c28c8454bdf66ed4

MD5 (8.0-BETA4-sparc64-bootonly.iso) = e2cc9393e0b596acdb36a8b07fbc480e
MD5 (8.0-BETA4-sparc64-disc1.iso) = 706f2e57ff1502ccaac37dd4571d898a
MD5 (8.0-BETA4-sparc64-dvd1.iso) = 9ac3509c8731874ae20009f170daf0e7

SHA256 (8.0-BETA4-amd64-bootonly.iso) = 3b4a1b964f64e68609f8010e43145c7a757c352e62b2b8128dff3947f08c330b
SHA256 (8.0-BETA4-amd64-disc1.iso) = e42cb6a4d46fcc924615949fe9da4217f9c824e4c30fb6371787e28d5ec50ff8
SHA256 (8.0-BETA4-amd64-dvd1.iso) = 61bb39599c2b2b76de0643d677702683c4274901dbaaa3944b3a419402046dcf
SHA256 (8.0-BETA4-amd64-livefs.iso) = f6b9fc2bfe74bb7bc730fa6786af09e4cca8d92a812ee1968283dff3eb6adc48
SHA256 (8.0-BETA4-amd64-memstick.img) = a930e419bed019114ddcf5833b3af1950f4ef32444bb02b1b84e84d91c754bda

SHA256 (8.0-BETA4-i386-bootonly.iso) = c2adde76995cbc25ac16afb2c4cb46686df54435f64e98ae4701908f024a0102
SHA256 (8.0-BETA4-i386-disc1.iso) = 0bbee2a9ffd4c00070cae001652037c8b194502dfc1a35c3ac0da1172c26bfdd
SHA256 (8.0-BETA4-i386-dvd1.iso) = 4dcd81040e977ff2f6c30aae04497416c2aec9eb8d4a5ac0dab6f2cd965bfaee
SHA256 (8.0-BETA4-i386-livefs.iso) = fac4c8c08698c30801f4555d5127c8bb5d786d6bebe164fd27e66bea737526bf
SHA256 (8.0-BETA4-i386-memstick.img) = 4a39d259b18f8d900a7bfc1878ed6ac4fda82812e13999da0265976eb1ba15e8

SHA256 (8.0-BETA4-ia64-bootonly.iso) = 5688b9c8bf13337835b2dce2fa7d6fb0ea17d397e927ef770d097a6728c8db23
SHA256 (8.0-BETA4-ia64-disc1.iso) = 33ddac157f6529bb31388d8c4ffdfb4824c989c0c0d843ecec071eb67ea36786
SHA256 (8.0-BETA4-ia64-disc2.iso) = ae71fd5d8d29666fa15689ddd8ffd45e3b6d354af9e1cb96b5a62280b452cbe5
SHA256 (8.0-BETA4-ia64-disc3.iso) = 330b43e5f81887de948257db46ed407a5c5a94c09e6d41155159e0617c0be53e
SHA256 (8.0-BETA4-ia64-dvd1.iso) = 4324c3c08d625b92942424a1c6e14085593ee62237ddd4f2eac2f35d7fb0f27b
SHA256 (8.0-BETA4-ia64-livefs.iso) = 860cad096ef74efa534bae3642dff5ec545ed47faa21a6cd65b197b12827885d

SHA256 (8.0-BETA4-pc98-bootonly.iso) = 0ce882dd48863f2f4180cbdf5f17ff595d7942bf7ac84029adef27a65b1b5481
SHA256 (8.0-BETA4-pc98-disc1.iso) = 4815a84ef0e834d3d57f7420c1f25ff93d0e3b698cc6eecee8b587f9896edd01
SHA256 (8.0-BETA4-pc98-livefs.iso) = cb6ea4a931551c2220c739d66f05c120926a7c2650373fc72770a25ea5e10a3d

SHA256 (8.0-BETA4-powerpc-bootonly.iso) = 6f97a8c061065661996e6efdad45bbbaaafc2e8f80717fa845b2bc3ae14d7212
SHA256 (8.0-BETA4-powerpc-disc1.iso) = 9b1fb4af1a9a53e5723fdfd897d8a57a4e815ada22637285b7360d24f512290c
SHA256 (8.0-BETA4-powerpc-disc2.iso) = 8e82ccaca6673cb3177870748ffdcb891fb16904eacd98822cca31f9888656ae
SHA256 (8.0-BETA4-powerpc-disc3.iso) = 651561d9021d5c68f266f21d6df31c87fec1368a428492274177810ea1333c3c

SHA256 (8.0-BETA4-sparc64-bootonly.iso) = 35dd8a303df41cb7ca744c37aee104e18f441967a14a3c9eb36bc4bcaf78c01b
SHA256 (8.0-BETA4-sparc64-disc1.iso) = 1d5ab4e67225a8640c9200424a140fff003203ab5edb855172d7030130974529
SHA256 (8.0-BETA4-sparc64-dvd1.iso) = 59ab2cca0fa637e9ef5007117f1005570c102cf4665009c6021992dd1b8bd77b

-- 
                                                Ken Smith
- From there to here, from here to      |       kensmith@buffalo.edu
  there, funny things are everywhere.   |
                      - Theodore Geisel |

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090907/eba45a1b/attachment.pgp
From cliftonr at lava.net  Mon Sep  7 19:52:11 2009
From: cliftonr at lava.net (Clifton Royston)
Date: Mon Sep  7 19:52:19 2009
Subject: incorrect usleep/select delays with HZ > 2500
In-Reply-To: <20090907072159.GA18906@onelab2.iet.unipi.it>
References: <20090906155154.GA8283@onelab2.iet.unipi.it>
	<e7db6d980909061736p4affc054k3fa5070214adc2f8@mail.gmail.com>
	<20090907072159.GA18906@onelab2.iet.unipi.it>
Message-ID: <20090907195207.GD10384@lava.net>

On Mon, Sep 07, 2009 at 09:21:59AM +0200, Luigi Rizzo wrote:
> On Sun, Sep 06, 2009 at 05:36:29PM -0700, Peter Wemm wrote:
> > On Sun, Sep 6, 2009 at 8:51 AM, Luigi Rizzo<rizzo@iet.unipi.it> wrote:
> > > (this problem seems to affect both current and -stable,
> > > so let's see if here i have better luck)
> > >
> > > I just noticed [Note 1,2] that when setting HZ > 2500 (even if it is
> > > an exact divisor of the APIC/CPU clock) there is a significant
> > > drift between the delays generated by usleep()/select() and those
> > > computed by gettimeofday(). ?In other words, the error grows with
> > > the amount of delay requested.
> > >
> > > To show the problem, try this function
> > >
> > > ? ? ? ?int f(int wait_time) { ?// wait_time in usec
> > > ? ? ? ? ? ? ? ?struct timeval start, end;
> > > ? ? ? ? ? ? ? ?gettimeofday(&start);
> > > ? ? ? ? ? ? ? ?usleep(w); ? ? ?// or try select
> > > ? ? ? ? ? ? ? ?gettimeofday(&end)
> > > ? ? ? ? ? ? ? ?timersub(&end, &start, &x);
> > > ? ? ? ? ? ? ? ?return = x.tv_usec + 1000000*x.tv_sec - wait_time;
> > > ? ? ? ?}
> > >
> > > for various HZ (kern.hz=NNNN in /boot/loader.conf) and wait times.
> > > Ideally, we would expect the timings to be in error by something
> > > between 0 and 1 (or 2) ticks, irrespective of the value of wait_time.
> > > In fact, this is what you see with HZ=1000, 2000 and 2500.
> > > But larger values of HZ (e.g. 4000, 5000, 10k, 40k) create
> > > a drift of 0.5% and above (i.e. with HZ=5000, a 1-second delay
> > > lasts 1.0064s and a 10s delay lasts 10.062s; with HZ=10k the
> > > error becomes 1% and at HZ=40k the error becomes even bigger.
> > 
> > Technically, it isn't even an error because the sleeps are defined as
> > 'at least' the value specified.  If you're looking for real-time-OS
> > level performance, you probably need to look at one.
> 
> I know a non RTOS has limitations on the guarantees it can give.
> But with this in mind (e.g.  be happy with something that works as
> expected just 'most of the times'), on this specific issue FreeBSD
> could behave much better while still remaining technically correct.

  I agree.  The best is the enemy of the good; while it will never be
an RTOS, there is no reason not to make the behavior as good as
possible, especially where a small investment of effort is required.

> > > 3. ?CAUSE an error in tvtohz(), reported long ago in
> > > ? ? ? ?http://www.dragonflybsd.org/presentations/nanosleep/
> > > ? ? ? ?which causes a systematic error of an extra tick in the computation
> > > ? ? ? ?of the sleep times.
> > > ? ?FIX: the above link also contains a proposed fix (which in fact
> > > ? ? ? ?reverts a bug introduced in some old commit on FreeBSD)
> > > ? ?PROBLEM: none that i see.
> > 
> > This change, as-is, is extremely dangerous.  tsleep/msleep() use a
> > value of 0 meaning 'forever'.  Changing tvtohz() so that it can now
> > return 0 for a non-zero tv is setting land-mines all over the place.
> > There's something like 27 callers of tvtohz() in sys/kern alone, some
> > of which are used to supply tsleep/msleep() timeouts.  Note that the
> > dragonflybsd patch above only adds the 'returns 0' check to one single
> > caller.  You either need to patch all callers of tvtohz() since you've
> > change the semantics, or add a 'if (ticks == 0) ticks = 1' check (or
> > checks) in the appropriate places inside tvtohz().
> > 
> > If you don't do it, then you end up with callers of random functions
> > with very small timeouts instead finding themselves sleeping forever.
> 
> You are right, a proper fix for this third issue should be different
> (if we want a fix at all -- I'd be almost satisfied by just
> removing the drift).
 
  Simply returning max(1, ticks) from tvtohz, as suggested above, would
eliminate this concern and still improve the performance for a great
number of cases.

> The simplest option is perhaps to compute a custom value for
> nanosleep, select and poll. This would remove the risk of side
> effects to other parts of the system, and we could also use the
> chance to compensate for the errors that arise when hz*tick !=
> 1000000 or when we know that hardclock does not run exactly every
> 'tick' (an integer) microseconds.

  This would also be a good solution.  It would be perfectly possible
to implement it in two stages - first by adapting tvothz() as above, as
an immediate and hopefully non-controversial improvement, and second by
refactoring the latter proposed change so that the non-sleep users
(nanosleep etc.) call a separate routine which is allowed to return 0;
tvtohz() could then be replaced with the degenerate function { return
(ticks = trueticks(tv) ? ticks : 1; }

  All IMHO, of course.
  -- Clifton

-- 
    Clifton Royston  --  cliftonr@iandicomputing.com / cliftonr@lava.net
       President  - I and I Computing * http://www.iandicomputing.com/
 Custom programming, network design, systems and network consulting services
From cswiger at mac.com  Mon Sep  7 22:09:01 2009
From: cswiger at mac.com (Chuck Swiger)
Date: Mon Sep  7 22:09:08 2009
Subject: incorrect usleep/select delays with HZ > 2500
In-Reply-To: <20090907072159.GA18906@onelab2.iet.unipi.it>
References: <20090906155154.GA8283@onelab2.iet.unipi.it>
	<e7db6d980909061736p4affc054k3fa5070214adc2f8@mail.gmail.com>
	<20090907072159.GA18906@onelab2.iet.unipi.it>
Message-ID: <6F002A04-5CF9-466F-AEFB-6B983C0E1980@mac.com>

Hi, all--

On Sep 7, 2009, at 12:21 AM, Luigi Rizzo wrote:
>>> 3. ?CAUSE an error in tvtohz(), reported long ago in
>>> ? ? ? ?http://www.dragonflybsd.org/presentations/nanosleep/
>>> ? ? ? ?which causes a systematic error of an extra tick in the  
>>> computation
>>> ? ? ? ?of the sleep times.
>>> ? ?FIX: the above link also contains a proposed fix (which in fact
>>> ? ? ? ?reverts a bug introduced in some old commit on FreeBSD)
>>> ? ?PROBLEM: none that i see.
>>
>> This change, as-is, is extremely dangerous.  tsleep/msleep() use a
>> value of 0 meaning 'forever'.  Changing tvtohz() so that it can now
>> return 0 for a non-zero tv is setting land-mines all over the place.
>> There's something like 27 callers of tvtohz() in sys/kern alone, some
>> of which are used to supply tsleep/msleep() timeouts.  Note that the
>> dragonflybsd patch above only adds the 'returns 0' check to one  
>> single
>> caller.  You either need to patch all callers of tvtohz() since  
>> you've
>> change the semantics, or add a 'if (ticks == 0) ticks = 1' check (or
>> checks) in the appropriate places inside tvtohz().
>>
>> If you don't do it, then you end up with callers of random functions
>> with very small timeouts instead finding themselves sleeping forever.
>
> You are right, a proper fix for this third issue should be different
> (if we want a fix at all -- I'd be almost satisfied by just
> removing the drift).

A while ago, I took a fairly close look at timing accuracy (ie, trying  
to sleep until exactly the next second or whatever, and then comparing  
the actual time you were woken up against the target time), did my own  
fancy graphs showing sawtooth waves indicating timer aliasing  
problems, etc.  There's no question that the system is allowed to  
sleep longer than requested, and, if the system is busy doing other  
tasks, some amount of extra delay is expected and OK, but missing the  
target time by more than several ticks, especially if the system is  
idle, is bogus.

The Dragonfly patch to tvtohz() definitely improves timer accuracy,  
but it ends up computing a tick value which is too small by one  
sometimes (ie, the target time lands *within* that scheduler quantum,  
rather than at or before the start of that tick), causing negative  
offsets from the desired time (ie, you woke up just a bit too soon).   
That's also bogus.  :-)

 From my own testing of various platforms, as well as the results  
reported elsewhere, MacOS X has the most consistent timer accuracy,  
which is probably not too surprising given that soft realtime  
capabilities for audio/visual processing tasks such as iTunes,  
Quicktime, LogicStudio, etc are pretty important to the Mac userbase.   
I just compared the tvtohz() implementations in kern/kern_clock.c  
between FreeBSD and Darwin/XNU (specifically xnu-1228.15.4, the kernel  
for 10.5.8), and they are effectively identical.  However, that's  
probably moot because Darwin uses tvtoabstime() rather than tvtohz()  
for the callouts in the setitimer()/getitimer() implementation from  
kern/kern_time.c:

/* FreeBSD */
int
kern_setitimer(struct thread *td, u_int which, struct itimerval *aitv,  
struct itimerval *oitv)
{
[ ... ]
         if (which == ITIMER_REAL) {
                 PROC_LOCK(p);
                 if (timevalisset(&p->p_realtimer.it_value))
                         callout_stop(&p->p_itcallout);
                 getmicrouptime(&ctv);
                 if (timevalisset(&aitv->it_value)) {
                         callout_reset(&p->p_itcallout, tvtohz(&aitv- 
 >it_value),
                             realitexpire, p);
                         timevaladd(&aitv->it_value, &ctv);
                 }
                 *oitv = p->p_realtimer;
                 p->p_realtimer = *aitv;
                 PROC_UNLOCK(p);
                 if (timevalisset(&oitv->it_value)) {
                         if (timevalcmp(&oitv->it_value, &ctv, <))
                                 timevalclear(&oitv->it_value);
                         else
                                 timevalsub(&oitv->it_value, &ctv);
                 }
[ ... ]

/* Darwin */
int
setitimer(struct proc *p, struct setitimer_args *uap, register_t  
*retval)
{
[ ... ]
         switch (uap->which) {

         case ITIMER_REAL:
                 proc_spinlock(p);
                 if (timerisset(&aitv.it_value)) {
                         microuptime(&p->p_rtime);
                         timevaladd(&p->p_rtime, &aitv.it_value);
                         p->p_realtimer = aitv;
                         if (!thread_call_enter_delayed(p->p_rcall,  
tvtoabstime(&p->p_rtime)))   // [1]
                                 p->p_ractive++;
                 } else  {
                         timerclear(&p->p_rtime);
                         p->p_realtimer = aitv;
                         if (thread_call_cancel(p->p_rcall))
                                 p->p_ractive--;
                 }
                 proc_spinunlock(p);

                 break;
[ ... ]

> The simplest option is perhaps to compute a custom value for
> nanosleep, select and poll. This would remove the risk of side
> effects to other parts of the system, and we could also use the
> chance to compensate for the errors that arise when hz*tick !=
> 1000000 or when we know that hardclock does not run exactly every
> 'tick' (an integer) microseconds.

I think it would be relatively simple to adapt the DragonFly change  
but ensure that tztohz() returns at least 1, and that would be helpful  
improvement.

However, in the long run, a callout mechanism based upon scheduler  
ticks rather than actual time values suffers an inherent loss of  
accuracy (you're performing an integer division of time intervals by  
HZ and rounding up to use the API, after all) and makes assumptions  
that the scheduler's clock is always running at a constant frequency  
such that tick * HZ is exactly a million microseconds.

Regards,
-- 
-Chuck

[1]: See http://www.opensource.apple.com/source/xnu/xnu-1228.15.4/osfmk/kern/thread_call.c
From tlott at gamesnet.de  Tue Sep  8 10:39:23 2009
From: tlott at gamesnet.de (Tobias Lott)
Date: Tue Sep  8 10:39:30 2009
Subject: System crawls after Upgrade 7.0->7.2
Message-ID: <20090908121945.43ba3976@sub.han.vpn.gamesnet.de>

Hey Everyone,

I upgraded a Dual Core Machine to 7.2-Stable (2 Days ago), all OS
related Stuff is located on an UFS Slice, Application is on a ZFS
Volume.

After the Upgrade everything seemed fine, but a User noticed one PHP
Script which is basically loading a plain Textfile into Mysql times out.
PHP Timeout was set to 60 secs, that was more then enough just one day
before the upgrade.

System-wise its like Mysql can't get get the data fast enough, process
is max at 10% cpu usage most of the time in sbwait state.

Haven't changed any sysctl (kern.maxvnodes="200000", vm.kmem_size="512M"
vm.kmem_size_max="512M" vfs.zfs.arc_max="100M" but had those before
already) or kernel parameter at that time. But according to the Wiki's
ZFS Tuning Guide those aren't needed anymore so I tried without but no
change there either.

I checked the following (and the current used values each):
maxproc
maxfiles
kern.ipc.somaxconn
kern.ipc.nmbclusters

Getting no error messages dmesg, syslog wise.

Tried moving Mysql to the UFS Slice but same thing happens happens
there.

Some very basic testing like dd-ing:
# dd if=/dev/da0 of=/dev/null bs=1024 count=1048576
1048576+0 records in
1048576+0 records out
1073741824 bytes transferred in 157.698602 secs (6808823 bytes/sec)

FreeBSD hostname 7.2-STABLE FreeBSD 7.2-STABLE #3 r196954:
Tue Sep  8 02:10:22 CEST 2009
root@hostname:/usr/obj/usr/src/sys/SPIRIT  amd64

Since I upgraded the Machines zpool to version 13 already I don't
really wanna go back to 7.0, but it seems the only way out atm.

Hopefully someone can give me a Hint where maybe I forgot to check.


Somehow it feels like the last Versions, I'd say starting with 7.x
doesn't really feel that Rock-Stable as Versions Prior used to
be. Prolly cause I'm using an Experimental Feature like ZFS, so no
Offense nor Blame and this is not intended as a Flame or whatsoever!
So don't get me wrong, I always liked, used, recommended FreeBSD since
4.0 and will continue to do so!

Best Regards

-- 
Tobias Lott
From doconnor at gsoft.com.au  Tue Sep  8 12:37:32 2009
From: doconnor at gsoft.com.au (Daniel O'Connor)
Date: Tue Sep  8 12:37:40 2009
Subject: Blocked process
In-Reply-To: <200908201204.24914.doconnor@gsoft.com.au>
References: <200908201204.24914.doconnor@gsoft.com.au>
Message-ID: <200909082207.24169.doconnor@gsoft.com.au>

On Thu, 20 Aug 2009, Daniel O'Connor wrote:
> Unfortunately the system is in Finland and I'm in Australia so I
> can't sit at the console :(

Someone visited the site and determined that the floppy drive cable was 
intermittently fouling the CPU fan. I believe this was causing the CPU 
to overheat and be throttled by the BIOS.

-- 
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
  -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090908/9ba9e67f/attachment.pgp
From doconnor at gsoft.com.au  Tue Sep  8 12:39:41 2009
From: doconnor at gsoft.com.au (Daniel O'Connor)
Date: Tue Sep  8 12:39:55 2009
Subject: Detecting CPU throttling on over temperature
Message-ID: <200909082209.37454.doconnor@gsoft.com.au>

Hi,
I recently discovered a system where the floppy drive cable was 
intermittently fouling the CPU fan - I believe this caused the CPU to 
overheat and then get throttled by the BIOS.

Does anyone know if it is possible to determine if this is the case? ie 
is there a way to be informed if throttling has occurred?

Thanks.

-- 
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
  -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090908/64f9ea31/attachment.pgp
From hrkfdn at gmail.com  Tue Sep  8 14:25:41 2009
From: hrkfdn at gmail.com (Henrik Friedrichsen)
Date: Tue Sep  8 14:26:14 2009
Subject: Detecting CPU throttling on over temperature
In-Reply-To: <200909082209.37454.doconnor@gsoft.com.au>
References: <200909082209.37454.doconnor@gsoft.com.au>
Message-ID: <cbbf66600909080652qa6a90cckff95e6d18561be24@mail.gmail.com>

I don't know whether there is a more convenient way, but you could
definitely check the current CPU frequency to detect whether it
changed from the previous one or not. There are several ways to this,
depends on the CPU. You can try messing with cpufreq(4).

On Tue, Sep 8, 2009 at 2:39 PM, Daniel O'Connor<doconnor@gsoft.com.au> wrote:
> Hi,
> I recently discovered a system where the floppy drive cable was
> intermittently fouling the CPU fan - I believe this caused the CPU to
> overheat and then get throttled by the BIOS.
>
> Does anyone know if it is possible to determine if this is the case? ie
> is there a way to be informed if throttling has occurred?
>
> Thanks.
>
> --
> Daniel O'Connor software and network engineer
> for Genesis Software - http://www.gsoft.com.au
> "The nice thing about standards is that there
> are so many of them to choose from."
> ?-- Andrew Tanenbaum
> GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
>
From gerrit at pmp.uni-hannover.de  Tue Sep  8 15:23:37 2009
From: gerrit at pmp.uni-hannover.de (Gerrit =?ISO-8859-1?Q?K=FChn?=)
Date: Tue Sep  8 15:23:43 2009
Subject: zfs kernel panic
Message-ID: <20090908172332.476d9e0b.gerrit@pmp.uni-hannover.de>

Hi folks,

I just upgraded a zfs server from 7.0-something to 7.2-stable and hoped to
get rid of some minor instabilities I experienced every 6 months or so.
Unfortunately, the new system crashed for the first time after only a few
hours when copying some files via scp onto it.
I got a kernel panic which looked quite similar to the one reported here
(kmem_map too small):
<http://www.archivum.info/freebsd-fs@freebsd.org/2009-04/00071/FreeBSD_7.2-RC1_-_ZFS_related_kernel_panic_quot_kmem_map_too_small_quot>

I have a dual cpu dual core opteron system with 4GB of RAM and a 3-disk
raidz1. I took out the memory settings from loader.conf as suggested in
UPDATING. I did not yet upgrade zpool nor zfs version (would that help?).
Are there any known issues or any further hints what might cause the
crash? I copied the files again, but this time everything went fine.


cu
  Gerrit
From serenity at exscape.org  Tue Sep  8 15:39:47 2009
From: serenity at exscape.org (Thomas Backman)
Date: Tue Sep  8 15:39:59 2009
Subject: zfs kernel panic
In-Reply-To: <20090908172332.476d9e0b.gerrit@pmp.uni-hannover.de>
References: <20090908172332.476d9e0b.gerrit@pmp.uni-hannover.de>
Message-ID: <E0D629E8-A58F-447B-B12F-237C8D634F5E@exscape.org>

On Sep 8, 2009, at 5:23 PM, Gerrit K?hn wrote:

> Hi folks,
>
> I just upgraded a zfs server from 7.0-something to 7.2-stable and  
> hoped to
> get rid of some minor instabilities I experienced every 6 months or  
> so.
> Unfortunately, the new system crashed for the first time after only  
> a few
> hours when copying some files via scp onto it.
> I got a kernel panic which looked quite similar to the one reported  
> here
> (kmem_map too small):
> <http://www.archivum.info/freebsd-fs@freebsd.org/2009-04/00071/FreeBSD_7.2-RC1_-_ZFS_related_kernel_panic_quot_kmem_map_too_small_quot 
> >
>
> I have a dual cpu dual core opteron system with 4GB of RAM and a 3- 
> disk
> raidz1. I took out the memory settings from loader.conf as suggested  
> in
> UPDATING. I did not yet upgrade zpool nor zfs version (would that  
> help?).
> Are there any known issues or any further hints what might cause the
> crash? I copied the files again, but this time everything went fine.
Hmm. Do you use i386 or amd64? This panic is (was?) pretty common on  
i386 before tuning, but... 4GB RAM and an Opteron should have you  
running amd64, no?

Regards,
Thomas
From pjd at FreeBSD.org  Tue Sep  8 16:44:18 2009
From: pjd at FreeBSD.org (Pawel Jakub Dawidek)
Date: Tue Sep  8 16:44:25 2009
Subject: zfs kernel panic
In-Reply-To: <20090908172332.476d9e0b.gerrit@pmp.uni-hannover.de>
References: <20090908172332.476d9e0b.gerrit@pmp.uni-hannover.de>
Message-ID: <20090908164413.GC1539@garage.freebsd.pl>

On Tue, Sep 08, 2009 at 05:23:32PM +0200, Gerrit K?hn wrote:
> Hi folks,
> 
> I just upgraded a zfs server from 7.0-something to 7.2-stable and hoped to
> get rid of some minor instabilities I experienced every 6 months or so.
> Unfortunately, the new system crashed for the first time after only a few
> hours when copying some files via scp onto it.
> I got a kernel panic which looked quite similar to the one reported here
> (kmem_map too small):
> <http://www.archivum.info/freebsd-fs@freebsd.org/2009-04/00071/FreeBSD_7.2-RC1_-_ZFS_related_kernel_panic_quot_kmem_map_too_small_quot>
> 
> I have a dual cpu dual core opteron system with 4GB of RAM and a 3-disk
> raidz1. I took out the memory settings from loader.conf as suggested in
> UPDATING. I did not yet upgrade zpool nor zfs version (would that help?).
> Are there any known issues or any further hints what might cause the
> crash? I copied the files again, but this time everything went fine.

If this is amd64, add vm.kmem_size="4G" to your loader.conf back.

-- 
Pawel Jakub Dawidek                       http://www.wheel.pl
pjd@FreeBSD.org                           http://www.FreeBSD.org
FreeBSD committer                         Am I Evil? Yes, I Am!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090908/53a4bc4a/attachment.pgp
From mav at FreeBSD.org  Tue Sep  8 17:28:10 2009
From: mav at FreeBSD.org (Alexander Motin)
Date: Tue Sep  8 17:28:17 2009
Subject: Detecting CPU throttling on over temperature
In-Reply-To: <1252426982.00160755.1252414203@10.7.7.3>
References: <1252426982.00160755.1252414203@10.7.7.3>
Message-ID: <4AA6860F.1020203@FreeBSD.org>

Daniel O'Connor wrote:
> I recently discovered a system where the floppy drive cable was 
> intermittently fouling the CPU fan - I believe this caused the CPU to 
> overheat and then get throttled by the BIOS.
> 
> Does anyone know if it is possible to determine if this is the case? ie 
> is there a way to be informed if throttling has occurred?

Theoretically it is possible. I know off-topic tool reporting this.
Also you can just monitor CPU temperature, depending on CPU type.

-- 
Alexander Motin
From jhb at freebsd.org  Tue Sep  8 18:00:13 2009
From: jhb at freebsd.org (John Baldwin)
Date: Tue Sep  8 18:00:20 2009
Subject: incorrect usleep/select delays with HZ > 2500
In-Reply-To: <20090906155154.GA8283@onelab2.iet.unipi.it>
References: <20090906155154.GA8283@onelab2.iet.unipi.it>
Message-ID: <200909081308.23345.jhb@freebsd.org>

On Sunday 06 September 2009 11:51:54 am Luigi Rizzo wrote:
> [Note 3] the TSC frequency is computed reading the tsc around a
>         call to DELAY(1000000) and assuming that the i8254 runs
>         at the nominal rate, 1.193182 MHz.
>         From tests I have made, the measurement in init_TSC() returns
>         a large error when HZ is large, whereas repeating the measurement
>         at a later time returns a much more reliable value.
>         As an example, see the following:
> 
>     Sep  6 14:21:59 lr kernel: TSC clock: at init_TSC 2323045616 Hz
>     Sep  6 14:21:59 lr kernel: 
Features=0x178bfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT>
>     Sep  6 14:21:59 lr kernel: AMD 
Features=0xea500800<SYSCALL,NX,MMX+,FFXSR,RDTSCP,LM,3DNow!+,3DNow!>
>     Sep  6 14:21:59 lr kernel: TSC: P-state invariant
>     Sep  6 14:21:59 lr kernel: TSC clock: at cpu_startup_end 2323056910 Hz
>     Sep  6 14:21:59 lr kernel: TSC clock: at acpi_timer_probe 2311254060 Hz
>     Sep  6 14:21:59 lr kernel: TSC clock: at acpi_timer_probe_2 2311191310 
Hz
>     Sep  6 14:21:59 lr kernel: TSC clock: at pn_probe_start 2300822648 Hz
>     Sep  6 14:21:59 lr kernel: TSC clock: at pn_attach_start 2300830946 Hz
>     Sep  6 14:21:59 lr kernel: TSC clock: at pn_probe_start 2300840133 Hz
>     Sep  6 14:21:59 lr kernel: TSC clock: at pn_attach_start 2300835253 Hz
>     Sep  6 14:21:59 lr kernel: TSC clock: at lapic_setup_clock 2300868376 Hz
> 
>         The latter values are close to what is reported when HZ=1000.

Try disabling legacy USB support in the BIOS to see if an SMI# is firing 
during the DELAY() causing the TSC freq to be too high.  I have seen the USB 
legacy support cause this in other machines.
 
-- 
John Baldwin
From smithi at nimnet.asn.au  Tue Sep  8 18:09:15 2009
From: smithi at nimnet.asn.au (Ian Smith)
Date: Tue Sep  8 18:09:24 2009
Subject: Detecting CPU throttling on over temperature
In-Reply-To: <cbbf66600909080652qa6a90cckff95e6d18561be24@mail.gmail.com>
References: <200909082209.37454.doconnor@gsoft.com.au>
	<cbbf66600909080652qa6a90cckff95e6d18561be24@mail.gmail.com>
Message-ID: <20090909030624.Y89278@sola.nimnet.asn.au>

On Tue, 8 Sep 2009, Henrik Friedrichsen wrote:
 > I don't know whether there is a more convenient way, but you could
 > definitely check the current CPU frequency to detect whether it
 > changed from the previous one or not. There are several ways to this,
 > depends on the CPU. You can try messing with cpufreq(4).
 > 
 > On Tue, Sep 8, 2009 at 2:39 PM, Daniel O'Connor<doconnor@gsoft.com.au> wrote:
 > > Hi,
 > > I recently discovered a system where the floppy drive cable was
 > > intermittently fouling the CPU fan - I believe this caused the CPU to
 > > overheat and then get throttled by the BIOS.
 > >
 > > Does anyone know if it is possible to determine if this is the case? ie
 > > is there a way to be informed if throttling has occurred?

Might be easier to hack powerd.c as an existing pretty lightweight way 
of monitoring CPU freq (to log or signal on detected freq lowered by 
throttling, say?) even if you don't need/want it to actually vary freq 
according to load, eg setting idle/busy shift factors to 'never/always'?

cheers, Ian
From dougb at FreeBSD.org  Tue Sep  8 18:27:57 2009
From: dougb at FreeBSD.org (Doug Barton)
Date: Tue Sep  8 18:28:04 2009
Subject: Not getting an IPv6 in a jail
In-Reply-To: <200909030808.08440.jhb@freebsd.org>
References: <ff6efe7e0909011230i414b6791k707f5c58383e9b53@mail.gmail.com>
	<20090902160440.GA28417@sd-13813.dedibox.fr>
	<4A9E98AD.1070202@FreeBSD.org> <200909030808.08440.jhb@freebsd.org>
Message-ID: <4AA6A22B.1070402@FreeBSD.org>

John Baldwin wrote:
> On Wednesday 02 September 2009 12:09:17 pm Doug Barton wrote:
>> FLEURIOT Damien wrote:
>>
>>> BIND's now happily running in its jail and responding to public
>>> queries.
>> It's up to you if you choose to do it, but there is no reason to run
>> BIND in a jail. The chroot feature provided by default by rc.d/named
>> is quite adequate security.
> 
> That is debatable.  One of the chief benefits of a jail is that if a server is 
> compromised so that an attacker can gain root access that root access is 
> limited in what it can do compared to a simple chroot.  That is true for any 
> server you would run under a jail, not just BIND.

On a strictly intellectual level I agree that jails are in some ways
more limited than chroots. OTOH, named chroots by default into
/var/named which has no binaries at all. The most "interesting" things
in the chroot environment are /dev/null and /dev/random. Jails by
nature have a more or less complete FreeBSD system available to the
attacker. Also, in addition to being chroot'ed named runs by default
as user 'bind' which is rather limited in what it can modify in the
chroot.

I realize that it's theoretically possible for an attacker to break
out of a chroot environment, escalate their privileges, etc. I suppose
my point is that if you're looking for things to tighten down on a
FreeBSD system the default named configuration is not the first place
I'd look. :)


Doug
From rizzo at iet.unipi.it  Tue Sep  8 20:55:04 2009
From: rizzo at iet.unipi.it (Luigi Rizzo)
Date: Tue Sep  8 20:55:12 2009
Subject: incorrect usleep/select delays with HZ > 2500
In-Reply-To: <200909081308.23345.jhb@freebsd.org>
References: <20090906155154.GA8283@onelab2.iet.unipi.it>
	<200909081308.23345.jhb@freebsd.org>
Message-ID: <20090908210100.GA72735@onelab2.iet.unipi.it>

On Tue, Sep 08, 2009 at 01:08:23PM -0400, John Baldwin wrote:
> On Sunday 06 September 2009 11:51:54 am Luigi Rizzo wrote:
> > [Note 3] the TSC frequency is computed reading the tsc around a
> >         call to DELAY(1000000) and assuming that the i8254 runs
> >         at the nominal rate, 1.193182 MHz.
> >         From tests I have made, the measurement in init_TSC() returns
> >         a large error when HZ is large, whereas repeating the measurement
> >         at a later time returns a much more reliable value.
> >         As an example, see the following:
> > 
> >     Sep  6 14:21:59 lr kernel: TSC clock: at init_TSC 2323045616 Hz
> >     Sep  6 14:21:59 lr kernel: 
> Features=0x178bfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT>
> >     Sep  6 14:21:59 lr kernel: AMD 
> Features=0xea500800<SYSCALL,NX,MMX+,FFXSR,RDTSCP,LM,3DNow!+,3DNow!>
> >     Sep  6 14:21:59 lr kernel: TSC: P-state invariant
> >     Sep  6 14:21:59 lr kernel: TSC clock: at cpu_startup_end 2323056910 Hz
> >     Sep  6 14:21:59 lr kernel: TSC clock: at acpi_timer_probe 2311254060 Hz
> >     Sep  6 14:21:59 lr kernel: TSC clock: at acpi_timer_probe_2 2311191310 
> Hz
> >     Sep  6 14:21:59 lr kernel: TSC clock: at pn_probe_start 2300822648 Hz
> >     Sep  6 14:21:59 lr kernel: TSC clock: at pn_attach_start 2300830946 Hz
> >     Sep  6 14:21:59 lr kernel: TSC clock: at pn_probe_start 2300840133 Hz
> >     Sep  6 14:21:59 lr kernel: TSC clock: at pn_attach_start 2300835253 Hz
> >     Sep  6 14:21:59 lr kernel: TSC clock: at lapic_setup_clock 2300868376 Hz
> > 
> >         The latter values are close to what is reported when HZ=1000.
> 
> Try disabling legacy USB support in the BIOS to see if an SMI# is firing 
> during the DELAY() causing the TSC freq to be too high.  I have seen the USB 
> legacy support cause this in other machines.

Thanks, will try tomorrow.
Would this explain the measurement becomes better as we get
further into the initialization, and why high HZ values affect
the measurement ?

	cheers
	luigi
From lambert at lambertfam.org  Wed Sep  9 00:08:10 2009
From: lambert at lambertfam.org (Scott Lambert)
Date: Wed Sep  9 00:08:18 2009
Subject: Not getting an IPv6 in a jail
In-Reply-To: <4AA6A22B.1070402@FreeBSD.org>
References: <ff6efe7e0909011230i414b6791k707f5c58383e9b53@mail.gmail.com>
	<20090902160440.GA28417@sd-13813.dedibox.fr>
	<4A9E98AD.1070202@FreeBSD.org> <200909030808.08440.jhb@freebsd.org>
	<4AA6A22B.1070402@FreeBSD.org>
Message-ID: <20090908234719.GC418@sysmon.tcworks.net>

On Tue, Sep 08, 2009 at 11:27:55AM -0700, Doug Barton wrote:
> John Baldwin wrote:
> > On Wednesday 02 September 2009 12:09:17 pm Doug Barton wrote:
> >> FLEURIOT Damien wrote:
> >>
> >>> BIND's now happily running in its jail and responding to public
> >>> queries.
> >>
> >> It's up to you if you choose to do it, but there is no reason to
> >> run BIND in a jail. The chroot feature provided by default by
> >> rc.d/named is quite adequate security.
> >
> > That is debatable.  One of the chief benefits of a jail is that if
> > a server is compromised so that an attacker can gain root access
> > that root access is limited in what it can do compared to a simple
> > chroot.  That is true for any server you would run under a jail, not
> > just BIND.
>
> On a strictly intellectual level I agree that jails are in some
> ways more limited than chroots. OTOH, named chroots by default into
> /var/named which has no binaries at all. The most "interesting" things
> in the chroot environment are /dev/null and /dev/random. Jails by
> nature have a more or less complete FreeBSD system available to the
> attacker. Also, in addition to being chroot'ed named runs by default
> as user 'bind' which is rather limited in what it can modify in the
> chroot.
>
> I realize that it's theoretically possible for an attacker to break
> out of a chroot environment, escalate their privileges, etc. I suppose
> my point is that if you're looking for things to tighten down on a
> FreeBSD system the default named configuration is not the first place
> I'd look. :)

Some of us are just using a jail per service to make the service more
portable between these massively overpowered machines these days.  For
me, jails are not always just about security.  I use them as cheap form
of virtualization.  The security seperation can be a cheap side effect
of the cheap virtualization.  This is especially cheap with the help of
sysutils/ezjail.

I do not currently have named inside a jail.  I still have a few P3
boxes in service handling some of the small tasks which I haven't gotten
around to rolling up yet.  Named inside a chroot inside a jail is not
the first thing I would go after, but when I get around to moving it off
the old server hardware, why not? :-)

-- 
Scott Lambert                    KC5MLE                       Unix SysAdmin
lambert@lambertfam.org

From dougb at FreeBSD.org  Wed Sep  9 00:11:44 2009
From: dougb at FreeBSD.org (Doug Barton)
Date: Wed Sep  9 00:12:26 2009
Subject: Not getting an IPv6 in a jail
In-Reply-To: <20090908234719.GC418@sysmon.tcworks.net>
References: <ff6efe7e0909011230i414b6791k707f5c58383e9b53@mail.gmail.com>	<20090902160440.GA28417@sd-13813.dedibox.fr>	<4A9E98AD.1070202@FreeBSD.org>
	<200909030808.08440.jhb@freebsd.org>	<4AA6A22B.1070402@FreeBSD.org>
	<20090908234719.GC418@sysmon.tcworks.net>
Message-ID: <4AA6F2B3.8000909@FreeBSD.org>

Scott Lambert wrote:

> Some of us are just using a jail per service to make the service more
> portable between these massively overpowered machines these days. 

Yes, that makes total sense. I'm not saying that running it in a jail
is a _bad_ thing, just that perhaps it is overkill.


Doug

-- 

    This .signature sanitized for your protection

From doconnor at gsoft.com.au  Wed Sep  9 00:48:15 2009
From: doconnor at gsoft.com.au (Daniel O'Connor)
Date: Wed Sep  9 00:48:22 2009
Subject: Detecting CPU throttling on over temperature
In-Reply-To: <4AA6860F.1020203@FreeBSD.org>
References: <1252426982.00160755.1252414203@10.7.7.3>
	<4AA6860F.1020203@FreeBSD.org>
Message-ID: <200909091018.10509.doconnor@gsoft.com.au>

On Wed, 9 Sep 2009, Alexander Motin wrote:
> Daniel O'Connor wrote:
> > I recently discovered a system where the floppy drive cable was
> > intermittently fouling the CPU fan - I believe this caused the CPU
> > to overheat and then get throttled by the BIOS.
> >
> > Does anyone know if it is possible to determine if this is the
> > case? ie is there a way to be informed if throttling has occurred?
>
> Theoretically it is possible. I know off-topic tool reporting this.
> Also you can just monitor CPU temperature, depending on CPU type.

Monitoring CPU temperature is a bit difficult, there are a lack of tools 
(although I have some code it's not complete).

The problem is that the CPU temperature is only a proxy measurement, I 
would much prefer to be told directly the BIOS is throttling rather 
than guess :)

-- 
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
  -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090909/0f584478/attachment.pgp
From doconnor at gsoft.com.au  Wed Sep  9 00:50:54 2009
From: doconnor at gsoft.com.au (Daniel O'Connor)
Date: Wed Sep  9 00:51:01 2009
Subject: Detecting CPU throttling on over temperature
In-Reply-To: <20090909030624.Y89278@sola.nimnet.asn.au>
References: <200909082209.37454.doconnor@gsoft.com.au>
	<cbbf66600909080652qa6a90cckff95e6d18561be24@mail.gmail.com>
	<20090909030624.Y89278@sola.nimnet.asn.au>
Message-ID: <200909091020.51049.doconnor@gsoft.com.au>

On Wed, 9 Sep 2009, Ian Smith wrote:
>  > > Does anyone know if it is possible to determine if this is the
>  > > case? ie is there a way to be informed if throttling has
>  > > occurred?
>
> Might be easier to hack powerd.c as an existing pretty lightweight
> way of monitoring CPU freq (to log or signal on detected freq lowered
> by throttling, say?) even if you don't need/want it to actually vary
> freq according to load, eg setting idle/busy shift factors to
> 'never/always'?

Hmm, that could work.

It seems odd to me that there is no direct way the BIOS can notify the 
OS it's throttling the CPU though.

-- 
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
  -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090909/af860d4f/attachment.pgp
From rnoland at FreeBSD.org  Wed Sep  9 03:42:56 2009
From: rnoland at FreeBSD.org (Robert Noland)
Date: Wed Sep  9 03:43:03 2009
Subject: Detecting CPU throttling on over temperature
In-Reply-To: <200909091020.51049.doconnor@gsoft.com.au>
References: <200909082209.37454.doconnor@gsoft.com.au>
	<cbbf66600909080652qa6a90cckff95e6d18561be24@mail.gmail.com>
	<20090909030624.Y89278@sola.nimnet.asn.au>
	<200909091020.51049.doconnor@gsoft.com.au>
Message-ID: <1252467764.85394.2903.camel@balrog.2hip.net>

On Wed, 2009-09-09 at 10:20 +0930, Daniel O'Connor wrote:
> On Wed, 9 Sep 2009, Ian Smith wrote:
> >  > > Does anyone know if it is possible to determine if this is the
> >  > > case? ie is there a way to be informed if throttling has
> >  > > occurred?
> >
> > Might be easier to hack powerd.c as an existing pretty lightweight
> > way of monitoring CPU freq (to log or signal on detected freq lowered
> > by throttling, say?) even if you don't need/want it to actually vary
> > freq according to load, eg setting idle/busy shift factors to
> > 'never/always'?
> 
> Hmm, that could work.
> 
> It seems odd to me that there is no direct way the BIOS can notify the 
> OS it's throttling the CPU though.

Some BIOS can and do send an ACPI event when the proc gets hot.  In my
experience, this was not a good thing though.  The BIOS that I remember
dealing with this on would continuously send the alarms, so while TCC
would kick in and throttle the CPU, the event processing kept it at 100%
utilization until it was powered off to cool.  I have also been able to
determine that TCC had kicked in by looking at the cpu frequency via
sysctl and comparing that to the max frequency reported for the proc.

If the BIOS sent the alarm, but throttled the rate it wouldn't have been
so bad.  Not that I had any active fan control on that box to do
anything about it really, but TCC might have actually worked if it
wasn't flooding the acpi event processor.

robert.


-- 
Robert Noland <rnoland@FreeBSD.org>
FreeBSD

From mav at FreeBSD.org  Wed Sep  9 04:21:43 2009
From: mav at FreeBSD.org (Alexander Motin)
Date: Wed Sep  9 04:21:50 2009
Subject: Detecting CPU throttling on over temperature
In-Reply-To: <200909091018.10509.doconnor@gsoft.com.au>
References: <1252426982.00160755.1252414203@10.7.7.3>
	<4AA6860F.1020203@FreeBSD.org>
	<200909091018.10509.doconnor@gsoft.com.au>
Message-ID: <4AA72D4D.9080505@FreeBSD.org>

Daniel O'Connor wrote:
> On Wed, 9 Sep 2009, Alexander Motin wrote:
>> Daniel O'Connor wrote:
>>> I recently discovered a system where the floppy drive cable was
>>> intermittently fouling the CPU fan - I believe this caused the CPU
>>> to overheat and then get throttled by the BIOS.
>>>
>>> Does anyone know if it is possible to determine if this is the
>>> case? ie is there a way to be informed if throttling has occurred?
>> Theoretically it is possible. I know off-topic tool reporting this.
>> Also you can just monitor CPU temperature, depending on CPU type.
> 
> Monitoring CPU temperature is a bit difficult, there are a lack of tools 
> (although I have some code it's not complete).

There indeed problems with MB monitoring, as it is non-standard. But
modern CPUs also include on-chip thermal sensors. For Core2Duo family
coretemp module works fine and precisely.

> The problem is that the CPU temperature is only a proxy measurement, I 
> would much prefer to be told directly the BIOS is throttling rather 
> than guess :)

While ACPI could implement thermal throttling, AFAIK TM1/TM2
technologies of P4 and above families are working just in CPU hardware.
BIOS only initializes them.

-- 
Alexander Motin
From gerrit at pmp.uni-hannover.de  Wed Sep  9 07:03:39 2009
From: gerrit at pmp.uni-hannover.de (Gerrit =?ISO-8859-1?Q?K=FChn?=)
Date: Wed Sep  9 07:03:52 2009
Subject: zfs kernel panic
In-Reply-To: <20090908164413.GC1539@garage.freebsd.pl>
References: <20090908172332.476d9e0b.gerrit@pmp.uni-hannover.de>
	<20090908164413.GC1539@garage.freebsd.pl>
Message-ID: <20090909090335.89a071df.gerrit@pmp.uni-hannover.de>

On Tue, 8 Sep 2009 18:44:13 +0200 Pawel Jakub Dawidek <pjd@FreeBSD.org>
wrote about Re: zfs kernel panic:

PJD> If this is amd64, add vm.kmem_size="4G" to your loader.conf back.

Yes, it is amd64 (sorry I did not mention that). I will add the option
back (the one I used before was set to a somewhat lower value, something
like 2G afaicr).


cu
  Gerrit
From gerrit at pmp.uni-hannover.de  Wed Sep  9 07:07:18 2009
From: gerrit at pmp.uni-hannover.de (Gerrit =?ISO-8859-1?Q?K=FChn?=)
Date: Wed Sep  9 07:07:29 2009
Subject: zfs kernel panic
In-Reply-To: <20090908164413.GC1539@garage.freebsd.pl>
References: <20090908172332.476d9e0b.gerrit@pmp.uni-hannover.de>
	<20090908164413.GC1539@garage.freebsd.pl>
Message-ID: <20090909090715.9d8a58ef.gerrit@pmp.uni-hannover.de>

On Tue, 8 Sep 2009 18:44:13 +0200 Pawel Jakub Dawidek <pjd@FreeBSD.org>
wrote about Re: zfs kernel panic:

PJD> If this is amd64, add vm.kmem_size="4G" to your loader.conf back.

What about vm.kmem_size_max? Does that also need tuning?


cu
  Gerrit
From doconnor at gsoft.com.au  Wed Sep  9 07:43:39 2009
From: doconnor at gsoft.com.au (Daniel O'Connor)
Date: Wed Sep  9 07:43:46 2009
Subject: Detecting CPU throttling on over temperature
In-Reply-To: <1252467764.85394.2903.camel@balrog.2hip.net>
References: <200909082209.37454.doconnor@gsoft.com.au>
	<200909091020.51049.doconnor@gsoft.com.au>
	<1252467764.85394.2903.camel@balrog.2hip.net>
Message-ID: <200909091713.34162.doconnor@gsoft.com.au>

On Wed, 9 Sep 2009, Robert Noland wrote:
> On Wed, 2009-09-09 at 10:20 +0930, Daniel O'Connor wrote:
> > On Wed, 9 Sep 2009, Ian Smith wrote:
> > >  > > Does anyone know if it is possible to determine if this is
> > >  > > the case? ie is there a way to be informed if throttling has
> > >  > > occurred?
> > >
> > > Might be easier to hack powerd.c as an existing pretty
> > > lightweight way of monitoring CPU freq (to log or signal on
> > > detected freq lowered by throttling, say?) even if you don't
> > > need/want it to actually vary freq according to load, eg setting
> > > idle/busy shift factors to 'never/always'?
> >
> > Hmm, that could work.
> >
> > It seems odd to me that there is no direct way the BIOS can notify
> > the OS it's throttling the CPU though.
>
> Some BIOS can and do send an ACPI event when the proc gets hot.  In
> my experience, this was not a good thing though.  The BIOS that I
> remember dealing with this on would continuously send the alarms, so
> while TCC would kick in and throttle the CPU, the event processing
> kept it at 100% utilization until it was powered off to cool.  I have

Ugh!
This system seems to stall for a few seconds and then come back, I 
haven't see any messages about it in dmesg though.

> also been able to determine that TCC had kicked in by looking at the
> cpu frequency via sysctl and comparing that to the max frequency
> reported for the proc.

Yeah, although I couldn't run ps when the CPU was stalled so I'm not 
sure if I'd catch it or not :)

> If the BIOS sent the alarm, but throttled the rate it wouldn't have
> been so bad.  Not that I had any active fan control on that box to do
> anything about it really, but TCC might have actually worked if it
> wasn't flooding the acpi event processor.

Having the BIOS or CPU do it automatically is sensible since it's a time 
critical task.. Some basic notification would be nice though. It 
boggles my mind how difficult it is to do such basic things sometimes..

-- 
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
  -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090909/dd86515e/attachment.pgp
From doconnor at gsoft.com.au  Wed Sep  9 08:17:24 2009
From: doconnor at gsoft.com.au (Daniel O'Connor)
Date: Wed Sep  9 08:17:31 2009
Subject: Detecting CPU throttling on over temperature
In-Reply-To: <4AA72D4D.9080505@FreeBSD.org>
References: <1252426982.00160755.1252414203@10.7.7.3>
	<200909091018.10509.doconnor@gsoft.com.au>
	<4AA72D4D.9080505@FreeBSD.org>
Message-ID: <200909091747.19696.doconnor@gsoft.com.au>

On Wed, 9 Sep 2009, Alexander Motin wrote:
> Daniel O'Connor wrote:
> > On Wed, 9 Sep 2009, Alexander Motin wrote:
> >> Daniel O'Connor wrote:
> >>> I recently discovered a system where the floppy drive cable was
> >>> intermittently fouling the CPU fan - I believe this caused the
> >>> CPU to overheat and then get throttled by the BIOS.
> >>>
> >>> Does anyone know if it is possible to determine if this is the
> >>> case? ie is there a way to be informed if throttling has
> >>> occurred?
> >>
> >> Theoretically it is possible. I know off-topic tool reporting
> >> this. Also you can just monitor CPU temperature, depending on CPU
> >> type.
> >
> > Monitoring CPU temperature is a bit difficult, there are a lack of
> > tools (although I have some code it's not complete).
>
> There indeed problems with MB monitoring, as it is non-standard. But
> modern CPUs also include on-chip thermal sensors. For Core2Duo family
> coretemp module works fine and precisely.

Ahh coretemp, I had forgotten about that.

I did a test on the bench (on a 7.2 system) here and realised that I 
can't actually detect throttling. coretemp reported 72 & 78C but the 
frequency was still 2933MHz.

I am pretty sure it would be throttling but I think that works by 
maintaining the frequency but stalling the CPU some percentage of the 
time. I have p4tcc loaded (in GENERIC) but it doesn't show up, I only 
get..

dev.cpu.0.%desc: ACPI CPU
dev.cpu.0.%driver: cpu
dev.cpu.0.%location: handle=\_PR_.CPU0
dev.cpu.0.%pnpinfo: _HID=none _UID=0
dev.cpu.0.%parent: acpi0
dev.cpu.0.freq: 2933
dev.cpu.0.freq_levels: 2933/35000 2566/30625 2199/26250 1833/21875 
1466/17500 1099/13125 733/8750 366/4375
dev.cpu.0.cx_supported: C1/0 C2/85
dev.cpu.0.cx_lowest: C1
dev.cpu.0.cx_usage: 100.00% 0.00%
dev.cpu.0.temperature: 44
dev.cpu.1.%desc: ACPI CPU
dev.cpu.1.%driver: cpu
dev.cpu.1.%location: handle=\_PR_.CPU1
dev.cpu.1.%pnpinfo: _HID=none _UID=0
dev.cpu.1.%parent: acpi0
dev.cpu.1.cx_supported: C1/0 C2/85
dev.cpu.1.cx_lowest: C1
dev.cpu.1.cx_usage: 100.00% 0.00%
dev.cpu.1.temperature: 36

I see some odd results if I disable the fan while running 'dd 
if=/dev/zero bs=128k count=5000 | md5' in a loop. The throughput seems 
to remain the same (odd) but the CPU idle time goes up when it gets 
hot.

> > The problem is that the CPU temperature is only a proxy
> > measurement, I would much prefer to be told directly the BIOS is
> > throttling rather than guess :)
>
> While ACPI could implement thermal throttling, AFAIK TM1/TM2
> technologies of P4 and above families are working just in CPU
> hardware. BIOS only initializes them.

OK.

-- 
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
  -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090909/37946657/attachment.pgp
From pjd at FreeBSD.org  Wed Sep  9 08:33:18 2009
From: pjd at FreeBSD.org (Pawel Jakub Dawidek)
Date: Wed Sep  9 08:33:30 2009
Subject: zfs kernel panic
In-Reply-To: <20090909090715.9d8a58ef.gerrit@pmp.uni-hannover.de>
References: <20090908172332.476d9e0b.gerrit@pmp.uni-hannover.de>
	<20090908164413.GC1539@garage.freebsd.pl>
	<20090909090715.9d8a58ef.gerrit@pmp.uni-hannover.de>
Message-ID: <20090909083313.GA1901@garage.freebsd.pl>

On Wed, Sep 09, 2009 at 09:07:15AM +0200, Gerrit K?hn wrote:
> On Tue, 8 Sep 2009 18:44:13 +0200 Pawel Jakub Dawidek <pjd@FreeBSD.org>
> wrote about Re: zfs kernel panic:
> 
> PJD> If this is amd64, add vm.kmem_size="4G" to your loader.conf back.
> 
> What about vm.kmem_size_max? Does that also need tuning?

No, this should be auto-tuned to some very large value.

-- 
Pawel Jakub Dawidek                       http://www.wheel.pl
pjd@FreeBSD.org                           http://www.FreeBSD.org
FreeBSD committer                         Am I Evil? Yes, I Am!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090909/2bdfd8aa/attachment.pgp
From mail25 at bzerk.org  Wed Sep  9 08:44:11 2009
From: mail25 at bzerk.org (Ruben de Groot)
Date: Wed Sep  9 08:44:18 2009
Subject: 8.0-BETA2 on soekris discarding packets?
Message-ID: <20090909084406.GA37977@ei.bzerk.org>


Hi,

I'm trying 8.0-BETA2 on a 4511 soekris board, but found a problem.

Outgoing networking is fine, but it looks like incoming connections are
silently discarded. No firewall is configured. Here's a tcpdump of normal
outgoing DNS traffic (IP address of the soekris is 192.168.179.15):

listening on sis0, link-type EN10MB (Ethernet), capture size 96 bytes
10:33:50.053875 IP 192.168.179.15.23093 > ei.lan.domain: 45893+ PTR? 255.179.168.192.in-addr.arpa. (46)
10:33:50.055038 IP ei.lan.domain > 192.168.179.15.23093: 45893 NXDomain* 0/1/0 (109)
10:33:50.066917 IP 192.168.179.15.13890 > ei.lan.domain: 45894+ PTR? 9.179.168.192.in-addr.arpa. (44)
10:33:50.067834 IP ei.lan.domain > 192.168.179.15.13890: 45894* 1/1/1 (113)

And here's a dump of an incoming ssh connection:

listening on sis0, link-type EN10MB (Ethernet), capture size 96 bytes
10:26:40.176756 IP ei.lan.55742 > 192.168.179.15.ssh: Flags [S], seq 1547228218, win 65535, options [mss 1460,nop,wscale 3,nop,nop,TS val 1961056657 ecr 0,sackOK,eol], length 0
10:26:43.175176 IP ei.lan.55742 > 192.168.179.15.ssh: Flags [S], seq 1547228218, win 65535, options [mss 1460,nop,wscale 3,nop,nop,TS val 1961059657 ecr 0,sackOK,eol], length 0
10:26:46.374688 IP ei.lan.55742 > 192.168.179.15.ssh: Flags [S], seq 1547228218, win 65535, options [mss 1460,nop,wscale 3,nop,nop,TS val 1961062857 ecr 0,sackOK,eol], length 0
10:26:49.574197 IP ei.lan.55742 > 192.168.179.15.ssh: Flags [S], seq 1547228218, win 65535, options [mss 1460,sackOK,eol], length 0
10:26:52.773759 IP ei.lan.55742 > 192.168.179.15.ssh: Flags [S], seq 1547228218, win 65535, options [mss 1460,sackOK,eol], length 0

Et cetera. No replies. This goes for all tcp ports, but ping works. nmap from another host says:

# nmap soekris

Starting Nmap 4.85BETA7 ( http://nmap.org ) at 2009-09-08 13:31 CEST
All 1000 scanned ports on 192.168.179.15 are filtered
MAC Address: 00:00:24:CB:93:28 (Connect AS)

Nmap done: 1 IP address (1 host up) scanned in 21.67 seconds

Anyone else seeing this?

Ruben

kernel config is below.


include GENERIC

cpu             I486_CPU
cpu             I586_CPU
ident           SOEKRIS

machine i386

options CPU_ELAN
options CPU_SOEKRIS
options HZ=150
#options CPU_ELAN_XTAL
options CPU_GEODE


_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
From tlott at gamesnet.de  Wed Sep  9 08:58:02 2009
From: tlott at gamesnet.de (Tobias Lott)
Date: Wed Sep  9 08:58:09 2009
Subject: System crawls after Upgrade 7.0->7.2
In-Reply-To: <20090908121945.43ba3976@sub.han.vpn.gamesnet.de>
References: <20090908121945.43ba3976@sub.han.vpn.gamesnet.de>
Message-ID: <20090909104807.633418ea@sub.han.vpn.gamesnet.de>



On Tue, 8 Sep 2009 12:19:45 +0200
Tobias Lott <tlott@gamesnet.de> wrote:

> Hey Everyone,
> 
> I upgraded a Dual Core Machine to 7.2-Stable (2 Days ago), all OS
> related Stuff is located on an UFS Slice, Application is on a ZFS
> Volume.
> 
> After the Upgrade everything seemed fine, but a User noticed one PHP
> Script which is basically loading a plain Textfile into Mysql times
> out. PHP Timeout was set to 60 secs, that was more then enough just
> one day before the upgrade.
> 
> System-wise its like Mysql can't get get the data fast enough, process
> is max at 10% cpu usage most of the time in sbwait state.
> 
> Haven't changed any sysctl (kern.maxvnodes="200000",
> vm.kmem_size="512M" vm.kmem_size_max="512M" vfs.zfs.arc_max="100M"
> but had those before already) or kernel parameter at that time. But
> according to the Wiki's ZFS Tuning Guide those aren't needed anymore
> so I tried without but no change there either.
> 
> I checked the following (and the current used values each):
> maxproc
> maxfiles
> kern.ipc.somaxconn
> kern.ipc.nmbclusters
> 
> Getting no error messages dmesg, syslog wise.
> 
> Tried moving Mysql to the UFS Slice but same thing happens happens
> there.
> 
> Some very basic testing like dd-ing:
> # dd if=/dev/da0 of=/dev/null bs=1024 count=1048576
> 1048576+0 records in
> 1048576+0 records out
> 1073741824 bytes transferred in 157.698602 secs (6808823 bytes/sec)
> 
> FreeBSD hostname 7.2-STABLE FreeBSD 7.2-STABLE #3 r196954:
> Tue Sep  8 02:10:22 CEST 2009
> root@hostname:/usr/obj/usr/src/sys/SPIRIT  amd64
> 
> Since I upgraded the Machines zpool to version 13 already I don't
> really wanna go back to 7.0, but it seems the only way out atm.
> 
> Hopefully someone can give me a Hint where maybe I forgot to check.
> 
> 
> Somehow it feels like the last Versions, I'd say starting with 7.x
> doesn't really feel that Rock-Stable as Versions Prior used to
> be. Prolly cause I'm using an Experimental Feature like ZFS, so no
> Offense nor Blame and this is not intended as a Flame or whatsoever!
> So don't get me wrong, I always liked, used, recommended FreeBSD since
> 4.0 and will continue to do so!
> 
> Best Regards
> 

I've tested some more it seems the Bottleneck is the HD, Raid Array is
Optimal checked it.
Running bonnie++ takes like forever, couldn't finish it since its a
Productive Machine, cause it renders the Server useless, every try to
access the server while bonnie is running times out. Weird thing is
bonnie++ is using max 1-3% CPU. But according to gstat its only ~3mb/s
(displayed as 100% busy) during first 3 Tests that is.


savecore: reboot after panic: page fault

But had no luck with the coredumb

# kgdb kernel.debug  /var/crash/vmcore.12
<snip>
Cannot access memory at address 0x0

Or is there any other method I could try?

Cause this is getting nasty unstable

-- 
Tobias Lott
From fbsd at dannysplace.net  Wed Sep  9 10:10:13 2009
From: fbsd at dannysplace.net (Danny Carroll)
Date: Wed Sep  9 10:11:08 2009
Subject: zfs kernel panic
In-Reply-To: <20090909083313.GA1901@garage.freebsd.pl>
References: <20090908172332.476d9e0b.gerrit@pmp.uni-hannover.de>	<20090908164413.GC1539@garage.freebsd.pl>	<20090909090715.9d8a58ef.gerrit@pmp.uni-hannover.de>
	<20090909083313.GA1901@garage.freebsd.pl>
Message-ID: <4AA77834.1010007@dannysplace.net>

On 9/09/2009 6:33 PM, Pawel Jakub Dawidek wrote:
> On Wed, Sep 09, 2009 at 09:07:15AM +0200, Gerrit K?hn wrote:
>    
>> On Tue, 8 Sep 2009 18:44:13 +0200 Pawel Jakub Dawidek<pjd@FreeBSD.org>
>> wrote about Re: zfs kernel panic:
>>
>> PJD>  If this is amd64, add vm.kmem_size="4G" to your loader.conf back.
>>
>> What about vm.kmem_size_max? Does that also need tuning?
>>      
> No, this should be auto-tuned to some very large value.
>
>    
Pawel (et al),

Would it be possible for you to post to the list your ideas of a 
complete set of tuning parameters for ZFS on amd64?  I have used the 
wiki article as a reference (http://wiki.freebsd.org/ZFSTuningGuide) but 
it states that if you have > 2g ram and 7.2 then you do not need to tune 
at all.

I for one would be interested in learning a little more about how the 
memory should be tuned.  Specifically what might be interesting is to 
know, once a parameter is set, is there an easy way to find out how it's 
being used? i.e. If you start limiting the arc, is is possible to know 
what sort of hit/miss rate you are getting.

-D


From pjd at FreeBSD.org  Wed Sep  9 10:44:02 2009
From: pjd at FreeBSD.org (Pawel Jakub Dawidek)
Date: Wed Sep  9 10:44:14 2009
Subject: zfs kernel panic
In-Reply-To: <4AA77834.1010007@dannysplace.net>
References: <20090908172332.476d9e0b.gerrit@pmp.uni-hannover.de>
	<20090908164413.GC1539@garage.freebsd.pl>
	<20090909090715.9d8a58ef.gerrit@pmp.uni-hannover.de>
	<20090909083313.GA1901@garage.freebsd.pl>
	<4AA77834.1010007@dannysplace.net>
Message-ID: <20090909104358.GG1901@garage.freebsd.pl>

On Wed, Sep 09, 2009 at 07:41:08PM +1000, Danny Carroll wrote:
> On 9/09/2009 6:33 PM, Pawel Jakub Dawidek wrote:
> >On Wed, Sep 09, 2009 at 09:07:15AM +0200, Gerrit K?hn wrote:
> >   
> >>On Tue, 8 Sep 2009 18:44:13 +0200 Pawel Jakub Dawidek<pjd@FreeBSD.org>
> >>wrote about Re: zfs kernel panic:
> >>
> >>PJD>  If this is amd64, add vm.kmem_size="4G" to your loader.conf back.
> >>
> >>What about vm.kmem_size_max? Does that also need tuning?
> >>     
> >No, this should be auto-tuned to some very large value.
> >
> >   
> Pawel (et al),
> 
> Would it be possible for you to post to the list your ideas of a 
> complete set of tuning parameters for ZFS on amd64?  I have used the 
> wiki article as a reference (http://wiki.freebsd.org/ZFSTuningGuide) but 
> it states that if you have > 2g ram and 7.2 then you do not need to tune 
> at all.

I think that was the idea, although I see no reason to have less kernel
address space than physical memory (except there might be other
in-kernel variables auto-tuned based on kmem size).

> I for one would be interested in learning a little more about how the 
> memory should be tuned.  Specifically what might be interesting is to 
> know, once a parameter is set, is there an easy way to find out how it's 
> being used? i.e. If you start limiting the arc, is is possible to know 
> what sort of hit/miss rate you are getting.

There are ARC statistics available here:

	# sysctl kstat.zfs

-- 
Pawel Jakub Dawidek                       http://www.wheel.pl
pjd@FreeBSD.org                           http://www.FreeBSD.org
FreeBSD committer                         Am I Evil? Yes, I Am!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090909/e45eb766/attachment.pgp
From sperber at deinprogramm.de  Wed Sep  9 12:42:17 2009
From: sperber at deinprogramm.de (Michael Sperber)
Date: Wed Sep  9 12:42:23 2009
Subject: Upgrade FreeBSD 7.1 to 7.2
In-Reply-To: <alpine.BSF.2.00.0908221229480.61512@fledge.watson.org> (Robert
	Watson's message of "Sat, 22 Aug 2009 12:32:11 +0100 (BST)")
References: <4A8EAE86.2000108@t-online.hu> <4A8ECB9C.2020909@quip.cz>
	<alpine.BSF.2.00.0908221229480.61512@fledge.watson.org>
Message-ID: <y9lws488fu9.fsf@c052021.wlan.net.ed.ac.uk>


Robert Watson <rwatson@FreeBSD.org> writes:

> FWIW, the main problem I ran into with my 8.0 upgrade is that 8.0 uses
> the uart(4) driver for serial ports, and sio(4), 7.2's default, has
> been removed. They require mutually exclusive lines in device.hints
> and different /etc/ttys lines.  If you rely on a serial console, I
> would recommend first switching 7.2 to using uart, pausing for a bit,
> and then switching forward to 8 so that you separate the risks
> associated with changing console drivers from those associated with
> sliding a major kernel version.

Could you briefly elaborate on how that's done with 7.x?  I.e. is
changing device.hints and /etc/ttys enough (what changes?), or do I need
to recompile the kernel?  (I'm a bit confused because both uart and sio
seem to be in GENERIC, but I haven't been able to active uart through
device.hints.  I couldn't find anything on freebsd.org or the internets,
either.)  A few hints would be much appreciated!

-- 
Cheers =8-} Mike
Friede, V?lkerverst?ndigung und ?berhaupt blabla
From dimitry at andric.com  Wed Sep  9 13:04:35 2009
From: dimitry at andric.com (Dimitry Andric)
Date: Wed Sep  9 13:04:42 2009
Subject: Upgrade FreeBSD 7.1 to 7.2
In-Reply-To: <y9lws488fu9.fsf@c052021.wlan.net.ed.ac.uk>
References: <4A8EAE86.2000108@t-online.hu>
	<4A8ECB9C.2020909@quip.cz>	<alpine.BSF.2.00.0908221229480.61512@fledge.watson.org>
	<y9lws488fu9.fsf@c052021.wlan.net.ed.ac.uk>
Message-ID: <4AA7A7E1.3040000@andric.com>

On 2009-09-09 14:25, Michael Sperber wrote:
>> If you rely on a serial console, I
>> would recommend first switching 7.2 to using uart
...>
> Could you briefly elaborate on how that's done with 7.x?  I.e. is
> changing device.hints and /etc/ttys enough (what changes?), or do I need
> to recompile the kernel?

You also need to remove device sio from your kernel configuration and
recompile.  If you have both sio and uart in your kernel (the default on
7.x IIRC), sio will take precedence.

N.B: please exercise caution when doing this to a server in a colo 10000
km away. :)
From rnoland at FreeBSD.org  Wed Sep  9 13:08:33 2009
From: rnoland at FreeBSD.org (Robert Noland)
Date: Wed Sep  9 13:08:40 2009
Subject: Detecting CPU throttling on over temperature
In-Reply-To: <200909091747.19696.doconnor@gsoft.com.au>
References: <1252426982.00160755.1252414203@10.7.7.3>
	<200909091018.10509.doconnor@gsoft.com.au>
	<4AA72D4D.9080505@FreeBSD.org>
	<200909091747.19696.doconnor@gsoft.com.au>
Message-ID: <1252501703.85394.3473.camel@balrog.2hip.net>

On Wed, 2009-09-09 at 17:47 +0930, Daniel O'Connor wrote:
> On Wed, 9 Sep 2009, Alexander Motin wrote:
> > Daniel O'Connor wrote:
> > > On Wed, 9 Sep 2009, Alexander Motin wrote:
> > >> Daniel O'Connor wrote:
> > >>> I recently discovered a system where the floppy drive cable was
> > >>> intermittently fouling the CPU fan - I believe this caused the
> > >>> CPU to overheat and then get throttled by the BIOS.
> > >>>
> > >>> Does anyone know if it is possible to determine if this is the
> > >>> case? ie is there a way to be informed if throttling has
> > >>> occurred?
> > >>
> > >> Theoretically it is possible. I know off-topic tool reporting
> > >> this. Also you can just monitor CPU temperature, depending on CPU
> > >> type.
> > >
> > > Monitoring CPU temperature is a bit difficult, there are a lack of
> > > tools (although I have some code it's not complete).
> >
> > There indeed problems with MB monitoring, as it is non-standard. But
> > modern CPUs also include on-chip thermal sensors. For Core2Duo family
> > coretemp module works fine and precisely.
> 
> Ahh coretemp, I had forgotten about that.
> 
> I did a test on the bench (on a 7.2 system) here and realised that I 
> can't actually detect throttling. coretemp reported 72 & 78C but the 
> frequency was still 2933MHz.
> 
> I am pretty sure it would be throttling but I think that works by 
> maintaining the frequency but stalling the CPU some percentage of the 
> time. I have p4tcc loaded (in GENERIC) but it doesn't show up, I only 
> get..

Is this a core2duo?  IIRC, they generally don't go into TCC until around
100C.  I did pull the c2d cpu docs at one point trying to look at
cpufreq.  If you are bored, you can grab the docs from intel and double
check.

robert.

> dev.cpu.0.%desc: ACPI CPU
> dev.cpu.0.%driver: cpu
> dev.cpu.0.%location: handle=\_PR_.CPU0
> dev.cpu.0.%pnpinfo: _HID=none _UID=0
> dev.cpu.0.%parent: acpi0
> dev.cpu.0.freq: 2933
> dev.cpu.0.freq_levels: 2933/35000 2566/30625 2199/26250 1833/21875 
> 1466/17500 1099/13125 733/8750 366/4375
> dev.cpu.0.cx_supported: C1/0 C2/85
> dev.cpu.0.cx_lowest: C1
> dev.cpu.0.cx_usage: 100.00% 0.00%
> dev.cpu.0.temperature: 44
> dev.cpu.1.%desc: ACPI CPU
> dev.cpu.1.%driver: cpu
> dev.cpu.1.%location: handle=\_PR_.CPU1
> dev.cpu.1.%pnpinfo: _HID=none _UID=0
> dev.cpu.1.%parent: acpi0
> dev.cpu.1.cx_supported: C1/0 C2/85
> dev.cpu.1.cx_lowest: C1
> dev.cpu.1.cx_usage: 100.00% 0.00%
> dev.cpu.1.temperature: 36
> 
> I see some odd results if I disable the fan while running 'dd 
> if=/dev/zero bs=128k count=5000 | md5' in a loop. The throughput seems 
> to remain the same (odd) but the CPU idle time goes up when it gets 
> hot.
> 
> > > The problem is that the CPU temperature is only a proxy
> > > measurement, I would much prefer to be told directly the BIOS is
> > > throttling rather than guess :)
> >
> > While ACPI could implement thermal throttling, AFAIK TM1/TM2
> > technologies of P4 and above families are working just in CPU
> > hardware. BIOS only initializes them.
> 
> OK.

-- 
Robert Noland <rnoland@FreeBSD.org>
FreeBSD

From mav at FreeBSD.org  Wed Sep  9 13:16:17 2009
From: mav at FreeBSD.org (Alexander Motin)
Date: Wed Sep  9 13:16:24 2009
Subject: Detecting CPU throttling on over temperature
In-Reply-To: <1252501703.85394.3473.camel@balrog.2hip.net>
References: <1252426982.00160755.1252414203@10.7.7.3>	
	<200909091018.10509.doconnor@gsoft.com.au>
	<4AA72D4D.9080505@FreeBSD.org>	
	<200909091747.19696.doconnor@gsoft.com.au>
	<1252501703.85394.3473.camel@balrog.2hip.net>
Message-ID: <4AA7AA9B.9010709@FreeBSD.org>

Robert Noland wrote:
> On Wed, 2009-09-09 at 17:47 +0930, Daniel O'Connor wrote:
>> On Wed, 9 Sep 2009, Alexander Motin wrote:
>>> Daniel O'Connor wrote:
>>>> On Wed, 9 Sep 2009, Alexander Motin wrote:
>>>>> Daniel O'Connor wrote:
>>>>>> I recently discovered a system where the floppy drive cable was
>>>>>> intermittently fouling the CPU fan - I believe this caused the
>>>>>> CPU to overheat and then get throttled by the BIOS.
>>>>>>
>>>>>> Does anyone know if it is possible to determine if this is the
>>>>>> case? ie is there a way to be informed if throttling has
>>>>>> occurred?
>>>>> Theoretically it is possible. I know off-topic tool reporting
>>>>> this. Also you can just monitor CPU temperature, depending on CPU
>>>>> type.
>>>> Monitoring CPU temperature is a bit difficult, there are a lack of
>>>> tools (although I have some code it's not complete).
>>> There indeed problems with MB monitoring, as it is non-standard. But
>>> modern CPUs also include on-chip thermal sensors. For Core2Duo family
>>> coretemp module works fine and precisely.
>> Ahh coretemp, I had forgotten about that.
>>
>> I did a test on the bench (on a 7.2 system) here and realised that I 
>> can't actually detect throttling. coretemp reported 72 & 78C but the 
>> frequency was still 2933MHz.
>>
>> I am pretty sure it would be throttling but I think that works by 
>> maintaining the frequency but stalling the CPU some percentage of the 
>> time. I have p4tcc loaded (in GENERIC) but it doesn't show up, I only 
>> get..
> 
> Is this a core2duo?  IIRC, they generally don't go into TCC until around
> 100C.  I did pull the c2d cpu docs at one point trying to look at
> cpufreq.  If you are bored, you can grab the docs from intel and double
> check.

AFAIR C2D supports three protection technologies. When CPU is hot, it
starts reducing frequency (multiplier) and voltage, alike to IEST. If it
is insufficient, it starts to skip core cycles, alike to TCC. If it is
still insufficient and temperature rises above about 100C, emergency
shutdown happens.

-- 
Alexander Motin
From rnoland at FreeBSD.org  Wed Sep  9 13:27:16 2009
From: rnoland at FreeBSD.org (Robert Noland)
Date: Wed Sep  9 13:27:22 2009
Subject: Detecting CPU throttling on over temperature
In-Reply-To: <4AA7AA9B.9010709@FreeBSD.org>
References: <1252426982.00160755.1252414203@10.7.7.3>
	<200909091018.10509.doconnor@gsoft.com.au>
	<4AA72D4D.9080505@FreeBSD.org>
	<200909091747.19696.doconnor@gsoft.com.au>
	<1252501703.85394.3473.camel@balrog.2hip.net>
	<4AA7AA9B.9010709@FreeBSD.org>
Message-ID: <1252502828.85394.3503.camel@balrog.2hip.net>

On Wed, 2009-09-09 at 16:16 +0300, Alexander Motin wrote:
> Robert Noland wrote:
> > On Wed, 2009-09-09 at 17:47 +0930, Daniel O'Connor wrote:
> >> On Wed, 9 Sep 2009, Alexander Motin wrote:
> >>> Daniel O'Connor wrote:
> >>>> On Wed, 9 Sep 2009, Alexander Motin wrote:
> >>>>> Daniel O'Connor wrote:
> >>>>>> I recently discovered a system where the floppy drive cable was
> >>>>>> intermittently fouling the CPU fan - I believe this caused the
> >>>>>> CPU to overheat and then get throttled by the BIOS.
> >>>>>>
> >>>>>> Does anyone know if it is possible to determine if this is the
> >>>>>> case? ie is there a way to be informed if throttling has
> >>>>>> occurred?
> >>>>> Theoretically it is possible. I know off-topic tool reporting
> >>>>> this. Also you can just monitor CPU temperature, depending on CPU
> >>>>> type.
> >>>> Monitoring CPU temperature is a bit difficult, there are a lack of
> >>>> tools (although I have some code it's not complete).
> >>> There indeed problems with MB monitoring, as it is non-standard. But
> >>> modern CPUs also include on-chip thermal sensors. For Core2Duo family
> >>> coretemp module works fine and precisely.
> >> Ahh coretemp, I had forgotten about that.
> >>
> >> I did a test on the bench (on a 7.2 system) here and realised that I 
> >> can't actually detect throttling. coretemp reported 72 & 78C but the 
> >> frequency was still 2933MHz.
> >>
> >> I am pretty sure it would be throttling but I think that works by 
> >> maintaining the frequency but stalling the CPU some percentage of the 
> >> time. I have p4tcc loaded (in GENERIC) but it doesn't show up, I only 
> >> get..
> > 
> > Is this a core2duo?  IIRC, they generally don't go into TCC until around
> > 100C.  I did pull the c2d cpu docs at one point trying to look at
> > cpufreq.  If you are bored, you can grab the docs from intel and double
> > check.
> 
> AFAIR C2D supports three protection technologies. When CPU is hot, it
> starts reducing frequency (multiplier) and voltage, alike to IEST. If it
> is insufficient, it starts to skip core cycles, alike to TCC. If it is
> still insufficient and temperature rises above about 100C, emergency
> shutdown happens.

Your recollection is probably more accurate than mine.  My brain is
full, so every new doc that I read pushes something else out.

robert.

-- 
Robert Noland <rnoland@FreeBSD.org>
FreeBSD

From pilists at c0mplx.org  Wed Sep  9 15:38:51 2009
From: pilists at c0mplx.org (Kurt Jaeger)
Date: Wed Sep  9 15:38:59 2009
Subject: Detecting CPU throttling on over temperature
In-Reply-To: <4AA7AA9B.9010709@FreeBSD.org>
References: <1252426982.00160755.1252414203@10.7.7.3>
	<200909091018.10509.doconnor@gsoft.com.au>
	<4AA72D4D.9080505@FreeBSD.org>
	<200909091747.19696.doconnor@gsoft.com.au>
	<1252501703.85394.3473.camel@balrog.2hip.net>
	<4AA7AA9B.9010709@FreeBSD.org>
Message-ID: <20090909153851.GE48206@home.opsec.eu>

Hi!

[on coretemp module, Alexander Motin <mav@FreeBSD.org> wrote:]
> AFAIR C2D supports three protection technologies. When CPU is hot, it
> starts reducing frequency (multiplier) and voltage, alike to IEST. If it
> is insufficient, it starts to skip core cycles, alike to TCC. If it is
> still insufficient and temperature rises above about 100C, emergency
> shutdown happens.

Cool. I just tested coretemp on some CPU here, works very nice!

Any information on what can be done with AMD CPUs with respect
to temperature monitoring ?

Thanks!

-- 
pi@opsec.eu            +49 171 3101372                        11 years to go !
From avg at icyb.net.ua  Wed Sep  9 15:47:26 2009
From: avg at icyb.net.ua (Andriy Gapon)
Date: Wed Sep  9 15:47:34 2009
Subject: Detecting CPU throttling on over temperature
In-Reply-To: <20090909153851.GE48206@home.opsec.eu>
References: <1252426982.00160755.1252414203@10.7.7.3>	<200909091018.10509.doconnor@gsoft.com.au>	<4AA72D4D.9080505@FreeBSD.org>	<200909091747.19696.doconnor@gsoft.com.au>	<1252501703.85394.3473.camel@balrog.2hip.net>	<4AA7AA9B.9010709@FreeBSD.org>
	<20090909153851.GE48206@home.opsec.eu>
Message-ID: <4AA7CE0A.9030502@icyb.net.ua>

on 09/09/2009 18:38 Kurt Jaeger said the following:
> Hi!
> 
> [on coretemp module, Alexander Motin <mav@FreeBSD.org> wrote:]
>> AFAIR C2D supports three protection technologies. When CPU is hot, it
>> starts reducing frequency (multiplier) and voltage, alike to IEST. If it
>> is insufficient, it starts to skip core cycles, alike to TCC. If it is
>> still insufficient and temperature rises above about 100C, emergency
>> shutdown happens.
> 
> Cool. I just tested coretemp on some CPU here, works very nice!
> 
> Any information on what can be done with AMD CPUs with respect
> to temperature monitoring ?

amdtemp(4) ? :-)


-- 
Andriy Gapon
From brooks at freebsd.org  Wed Sep  9 15:52:34 2009
From: brooks at freebsd.org (Brooks Davis)
Date: Wed Sep  9 15:52:41 2009
Subject: ifconfig_ed0="DHCP" does not work on 8.0-BETA3
In-Reply-To: <20090905110635.GG87716@graf.pompo.net>
References: <20090904173811.GA45176@graf.pompo.net>
	<20090904214148.GB9950@michelle.cdnetworks.com>
	<20090904215747.GB82231@lor.one-eyed-alien.net>
	<20090905110635.GG87716@graf.pompo.net>
Message-ID: <20090909155257.GF42196@lor.one-eyed-alien.net>

On Sat, Sep 05, 2009 at 01:06:35PM +0200, Thierry Thomas wrote:
> Le Ven  4 sep 09 ? 23:57:47 +0200, Brooks Davis <brooks@freebsd.org>
>  ?crivait?:
>  
> > This is a know issue with some devices supported by ed(4).  You can work
> > around it by changing DHCP to SYNCDHCP which will cause dhclient to
> > alwasy start immediatly on that interface instead of waiting for a link
> > state change that never happens.
> 
> Thanks for the hint!
> 
> What about the following patch?
> 
> --- man4_ed.4.diff begins here ---
> --- src/share/man/man4/ed.4.orig	2009-08-03 10:13:06.000000000 +0200
> +++ src/share/man/man4/ed.4	2009-09-05 12:51:51.000000000 +0200
> @@ -425,3 +425,11 @@
>  .Pp
>  PC Card attachment supports the D-Link DMF650TX LAN/Modem card's Ethernet
>  port only at this time.
> +.Pp
> +If the line "ed0: link state changed to UP" does not show up in dmesg, the line
> +.Pp
> +ifconfig_ed0="DHCP"
> +.Pp
> +in
> +.Xr rc.conf 5
> +will be ineffective. In this case, replace "DHCP" by "SYNCDHCP".
> --- man4_ed.4.diff ends here ---
> 
> Don't hesitate to reword it - my englsh can be terrible!

I'd rather not mention the "link state changed" message since I'd love
to see it go away.  How's this?

Index: ed.4
===================================================================
--- ed.4	(revision 196736)
+++ ed.4	(working copy)
@@ -425,3 +425,21 @@
 .Pp
 PC Card attachment supports the D-Link DMF650TX LAN/Modem card's
Ethernet
 port only at this time.
+.Pp
+Some devices supported by
+.Nm
+do no generate the link state change events used by
+.Xr devd 8
+to start
+.Xr dhclinet 8 .
+If you have problems with
+.Xr dhclient 8
+not starting and the device is always attached to the network it may
+be possible to work around this by changing
+.Dq Li DHCP
+to
+.Dq Li SYNCDHCP
+in the
+.Va ifconfig_ed0
+entry in
+.Pa /etc/rc.conf .

=- Brooks


From pilists at c0mplx.org  Wed Sep  9 15:59:21 2009
From: pilists at c0mplx.org (Kurt Jaeger)
Date: Wed Sep  9 15:59:27 2009
Subject: Detecting CPU throttling on over temperature
In-Reply-To: <4AA7CE0A.9030502@icyb.net.ua>
References: <1252426982.00160755.1252414203@10.7.7.3>
	<200909091018.10509.doconnor@gsoft.com.au>
	<4AA72D4D.9080505@FreeBSD.org>
	<200909091747.19696.doconnor@gsoft.com.au>
	<1252501703.85394.3473.camel@balrog.2hip.net>
	<4AA7AA9B.9010709@FreeBSD.org>
	<20090909153851.GE48206@home.opsec.eu>
	<4AA7CE0A.9030502@icyb.net.ua>
Message-ID: <20090909155921.GG48206@home.opsec.eu>

Hi!

> > Any information on what can be done with AMD CPUs with respect
> > to temperature monitoring ?
> 
> amdtemp(4) ? :-)

home$ man amdtemp
No manual entry for amdtemp

It's on 8.0-BETA4, but I have no amd64 running with that, yet.

-- 
pi@opsec.eu            +49 171 3101372                        11 years to go !
From vince at unsane.co.uk  Wed Sep  9 16:32:56 2009
From: vince at unsane.co.uk (Vincent Hoffman)
Date: Wed Sep  9 16:33:03 2009
Subject: general protection fault on boot.
Message-ID: <4AA7D8B3.1010203@unsane.co.uk>

Hi all,
          I've been running the 8.0-BETAs in a xen virtual machine
(hvm/fully virtualised) for testing and something between r196730 and
r196746 causes a general protection fault on boot. I'll try and narrow
it down if i get a chance but I'm a a bit busy at the moment.
 
backtrace is available at
http://unsane.co.uk/~jhary/freebsd/GPF-09-09-09.gif 
Xen dom0 is a centos5.3 box using the xen-3.3.1 rpms from
http://www.gitco.de/linux/i386/centos/5/rpms/  if thats of any use.

Let me know if I need to provide any more info.


Vince

From cliftonr at lava.net  Wed Sep  9 17:02:15 2009
From: cliftonr at lava.net (Clifton Royston)
Date: Wed Sep  9 17:02:29 2009
Subject: System crawls after Upgrade 7.0->7.2
In-Reply-To: <20090909104807.633418ea@sub.han.vpn.gamesnet.de>
References: <20090908121945.43ba3976@sub.han.vpn.gamesnet.de>
	<20090909104807.633418ea@sub.han.vpn.gamesnet.de>
Message-ID: <20090909170213.GA7925@lava.net>

On Wed, Sep 09, 2009 at 10:48:07AM +0200, Tobias Lott wrote:
> On Tue, 8 Sep 2009 12:19:45 +0200
> Tobias Lott <tlott@gamesnet.de> wrote:
> > Hey Everyone,
> > 
> > I upgraded a Dual Core Machine to 7.2-Stable (2 Days ago), all OS
> > related Stuff is located on an UFS Slice, Application is on a ZFS
> > Volume.
> > 
> > After the Upgrade everything seemed fine, but a User noticed one PHP
> > Script which is basically loading a plain Textfile into Mysql times
> > out. PHP Timeout was set to 60 secs, that was more then enough just
> > one day before the upgrade.
...
> > Since I upgraded the Machines zpool to version 13 already I don't
> > really wanna go back to 7.0, but it seems the only way out atm.
> > 
> > Hopefully someone can give me a Hint where maybe I forgot to check.
> > 
> > Somehow it feels like the last Versions, I'd say starting with 7.x
> > doesn't really feel that Rock-Stable as Versions Prior used to
> > be. Prolly cause I'm using an Experimental Feature like ZFS, so no
> > Offense nor Blame and this is not intended as a Flame or whatsoever!
> > So don't get me wrong, I always liked, used, recommended FreeBSD since
> > 4.0 and will continue to do so!
> > 
> > Best Regards
> > 
> 
> I've tested some more it seems the Bottleneck is the HD, Raid Array is
> Optimal checked it.

  Probably you already checked this, but did you go through the dmesg
output relating to ata and drive detection closely?

  In the past from time to time I've had machines suddenly start
crawling after an upgrade, and it turned out it was because some change
in the driver detection caused the ata to fall back to pio mode.  The
symptoms are pretty much like you describe - all HD IO takes forever.

  -- Clifton

-- 
    Clifton Royston  --  cliftonr@iandicomputing.com / cliftonr@lava.net
       President  - I and I Computing * http://www.iandicomputing.com/
 Custom programming, network design, systems and network consulting services
From thierry at FreeBSD.org  Wed Sep  9 17:07:11 2009
From: thierry at FreeBSD.org (Thierry Thomas)
Date: Wed Sep  9 17:07:25 2009
Subject: ifconfig_ed0="DHCP" does not work on 8.0-BETA3
In-Reply-To: <20090909155257.GF42196@lor.one-eyed-alien.net>
References: <20090904173811.GA45176@graf.pompo.net>
	<20090904214148.GB9950@michelle.cdnetworks.com>
	<20090904215747.GB82231@lor.one-eyed-alien.net>
	<20090905110635.GG87716@graf.pompo.net>
	<20090909155257.GF42196@lor.one-eyed-alien.net>
Message-ID: <20090909170701.GB38292@graf.pompo.net>

Le Mer  9 sep 09 ? 17:52:57 +0200, Brooks Davis <brooks@freebsd.org>
 ?crivait?:

> I'd rather not mention the "link state changed" message since I'd love
> to see it go away.  How's this?

Seems good, go!
-- 
Th. Thomas.
From thierry at FreeBSD.org  Wed Sep  9 17:15:40 2009
From: thierry at FreeBSD.org (Thierry Thomas)
Date: Wed Sep  9 17:15:47 2009
Subject: Detecting CPU throttling on over temperature
In-Reply-To: <200909082209.37454.doconnor@gsoft.com.au>
References: <200909082209.37454.doconnor@gsoft.com.au>
Message-ID: <20090909171530.GC38292@graf.pompo.net>

Le Mar  8 sep 09 ? 14:39:36 +0200, Daniel O'Connor <doconnor@gsoft.com.au>
 ?crivait?:
> Hi,
> I recently discovered a system where the floppy drive cable was 
> intermittently fouling the CPU fan - I believe this caused the CPU to 
> overheat and then get throttled by the BIOS.
> 
> Does anyone know if it is possible to determine if this is the case? ie 
> is there a way to be informed if throttling has occurred?

Have you tried the ports sysutils/lmmon and sysutils/wmlmmon?

Some others exist under /usr/ports/sysutils, but I don't use them.

Regards,
-- 
Th. Thomas.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090909/d4fec293/attachment.pgp
From marketing at donateshoes.org  Wed Sep  9 18:10:00 2009
From: marketing at donateshoes.org (Soles4Souls and Nine West)
Date: Wed Sep  9 18:10:08 2009
Subject: Get 15% off the Vintage America Collection for Nine West by
	Donating to Soles4Souls
Message-ID: <20090909102041.14885625@donateshoes.org>

Get 15% off the Vintage America Collection for Nine West by Donating to Soles4Souls
From jhb at freebsd.org  Wed Sep  9 18:24:12 2009
From: jhb at freebsd.org (John Baldwin)
Date: Wed Sep  9 18:24:24 2009
Subject: incorrect usleep/select delays with HZ > 2500
In-Reply-To: <20090908210100.GA72735@onelab2.iet.unipi.it>
References: <20090906155154.GA8283@onelab2.iet.unipi.it>
	<200909081308.23345.jhb@freebsd.org>
	<20090908210100.GA72735@onelab2.iet.unipi.it>
Message-ID: <200909091324.53668.jhb@freebsd.org>

On Tuesday 08 September 2009 5:01:00 pm Luigi Rizzo wrote:
> On Tue, Sep 08, 2009 at 01:08:23PM -0400, John Baldwin wrote:
> > On Sunday 06 September 2009 11:51:54 am Luigi Rizzo wrote:
> > > [Note 3] the TSC frequency is computed reading the tsc around a
> > >         call to DELAY(1000000) and assuming that the i8254 runs
> > >         at the nominal rate, 1.193182 MHz.
> > >         From tests I have made, the measurement in init_TSC() returns
> > >         a large error when HZ is large, whereas repeating the 
measurement
> > >         at a later time returns a much more reliable value.
> > >         As an example, see the following:
> > > 
> > >     Sep  6 14:21:59 lr kernel: TSC clock: at init_TSC 2323045616 Hz
> > >     Sep  6 14:21:59 lr kernel: 
> > 
Features=0x178bfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT>
> > >     Sep  6 14:21:59 lr kernel: AMD 
> > Features=0xea500800<SYSCALL,NX,MMX+,FFXSR,RDTSCP,LM,3DNow!+,3DNow!>
> > >     Sep  6 14:21:59 lr kernel: TSC: P-state invariant
> > >     Sep  6 14:21:59 lr kernel: TSC clock: at cpu_startup_end 2323056910 
Hz
> > >     Sep  6 14:21:59 lr kernel: TSC clock: at acpi_timer_probe 2311254060 
Hz
> > >     Sep  6 14:21:59 lr kernel: TSC clock: at acpi_timer_probe_2 
2311191310 
> > Hz
> > >     Sep  6 14:21:59 lr kernel: TSC clock: at pn_probe_start 2300822648 
Hz
> > >     Sep  6 14:21:59 lr kernel: TSC clock: at pn_attach_start 2300830946 
Hz
> > >     Sep  6 14:21:59 lr kernel: TSC clock: at pn_probe_start 2300840133 
Hz
> > >     Sep  6 14:21:59 lr kernel: TSC clock: at pn_attach_start 2300835253 
Hz
> > >     Sep  6 14:21:59 lr kernel: TSC clock: at lapic_setup_clock 
2300868376 Hz
> > > 
> > >         The latter values are close to what is reported when HZ=1000.
> > 
> > Try disabling legacy USB support in the BIOS to see if an SMI# is firing 
> > during the DELAY() causing the TSC freq to be too high.  I have seen the 
USB 
> > legacy support cause this in other machines.
> 
> Thanks, will try tomorrow.
> Would this explain the measurement becomes better as we get
> further into the initialization, and why high HZ values affect
> the measurement ?

It would explain why it gets better later since the uhci(4), ohci(4) and 
ehci(4) drivers disable the SMI# interrupts while attaching to the 
controllers.

-- 
John Baldwin
From jhb at freebsd.org  Wed Sep  9 18:24:13 2009
From: jhb at freebsd.org (John Baldwin)
Date: Wed Sep  9 18:24:25 2009
Subject: general protection fault on boot.
In-Reply-To: <4AA7D8B3.1010203@unsane.co.uk>
References: <4AA7D8B3.1010203@unsane.co.uk>
Message-ID: <200909091339.00193.jhb@freebsd.org>

On Wednesday 09 September 2009 12:32:51 pm Vincent Hoffman wrote:
> Hi all,
>           I've been running the 8.0-BETAs in a xen virtual machine
> (hvm/fully virtualised) for testing and something between r196730 and
> r196746 causes a general protection fault on boot. I'll try and narrow
> it down if i get a chance but I'm a a bit busy at the moment.
>  
> backtrace is available at
> http://unsane.co.uk/~jhary/freebsd/GPF-09-09-09.gif 
> Xen dom0 is a centos5.3 box using the xen-3.3.1 rpms from
> http://www.gitco.de/linux/i386/centos/5/rpms/  if thats of any use.
> 
> Let me know if I need to provide any more info.

Hmm, can you try reverting 196737?  Or actually, can you print out the value 
of %ebx ('p $ebx' in ddb will work I think)?  I wonder if this patch would 
fix it:

Index: pmap.c
===================================================================
--- pmap.c	(revision 196974)
+++ pmap.c	(working copy)
@@ -999,7 +999,7 @@
 		 * coherence domain.
 		 */
 		mfence();
-		for (; sva < eva; sva += cpu_clflush_line_size)
+		for (; sva <= eva; sva += cpu_clflush_line_size)
 			clflush(sva);
 		mfence();
 	} else {

-- 
John Baldwin
From jhb at freebsd.org  Wed Sep  9 18:46:53 2009
From: jhb at freebsd.org (John Baldwin)
Date: Wed Sep  9 18:47:00 2009
Subject: general protection fault on boot.
In-Reply-To: <200909091339.00193.jhb@freebsd.org>
References: <4AA7D8B3.1010203@unsane.co.uk>
	<200909091339.00193.jhb@freebsd.org>
Message-ID: <200909091446.47077.jhb@freebsd.org>

On Wednesday 09 September 2009 1:38:59 pm John Baldwin wrote:
> On Wednesday 09 September 2009 12:32:51 pm Vincent Hoffman wrote:
> > Hi all,
> >           I've been running the 8.0-BETAs in a xen virtual machine
> > (hvm/fully virtualised) for testing and something between r196730 and
> > r196746 causes a general protection fault on boot. I'll try and narrow
> > it down if i get a chance but I'm a a bit busy at the moment.
> >  
> > backtrace is available at
> > http://unsane.co.uk/~jhary/freebsd/GPF-09-09-09.gif 
> > Xen dom0 is a centos5.3 box using the xen-3.3.1 rpms from
> > http://www.gitco.de/linux/i386/centos/5/rpms/  if thats of any use.
> > 
> > Let me know if I need to provide any more info.
> 
> Hmm, can you try reverting 196737?  Or actually, can you print out the value 
> of %ebx ('p $ebx' in ddb will work I think)?  I wonder if this patch would 
> fix it:
> 
> Index: pmap.c
> ===================================================================
> --- pmap.c	(revision 196974)
> +++ pmap.c	(working copy)
> @@ -999,7 +999,7 @@
>  		 * coherence domain.
>  		 */
>  		mfence();
> -		for (; sva < eva; sva += cpu_clflush_line_size)
> +		for (; sva <= eva; sva += cpu_clflush_line_size)
>  			clflush(sva);
>  		mfence();
>  	} else {

This patch is probably bogus.  I am curious what %ebx is however.

-- 
John Baldwin
From kostikbel at gmail.com  Wed Sep  9 19:02:35 2009
From: kostikbel at gmail.com (Kostik Belousov)
Date: Wed Sep  9 19:02:41 2009
Subject: general protection fault on boot.
In-Reply-To: <200909091339.00193.jhb@freebsd.org>
References: <4AA7D8B3.1010203@unsane.co.uk>
	<200909091339.00193.jhb@freebsd.org>
Message-ID: <20090909190228.GC47688@deviant.kiev.zoral.com.ua>

On Wed, Sep 09, 2009 at 01:38:59PM -0400, John Baldwin wrote:
> On Wednesday 09 September 2009 12:32:51 pm Vincent Hoffman wrote:
> > Hi all,
> >           I've been running the 8.0-BETAs in a xen virtual machine
> > (hvm/fully virtualised) for testing and something between r196730 and
> > r196746 causes a general protection fault on boot. I'll try and narrow
> > it down if i get a chance but I'm a a bit busy at the moment.
> >  
> > backtrace is available at
> > http://unsane.co.uk/~jhary/freebsd/GPF-09-09-09.gif 
> > Xen dom0 is a centos5.3 box using the xen-3.3.1 rpms from
> > http://www.gitco.de/linux/i386/centos/5/rpms/  if thats of any use.
> > 
> > Let me know if I need to provide any more info.
> 
> Hmm, can you try reverting 196737?  Or actually, can you print out the value 
> of %ebx ('p $ebx' in ddb will work I think)?  I wonder if this patch would 
> fix it:
> 
> Index: pmap.c
> ===================================================================
> --- pmap.c	(revision 196974)
> +++ pmap.c	(working copy)
> @@ -999,7 +999,7 @@
>  		 * coherence domain.
>  		 */
>  		mfence();
> -		for (; sva < eva; sva += cpu_clflush_line_size)
> +		for (; sva <= eva; sva += cpu_clflush_line_size)
>  			clflush(sva);
>  		mfence();
>  	} else {

Oh, no, another pointy hat to me :(.

Please, try this patch instead.

diff --git a/sys/i386/xen/pmap.c b/sys/i386/xen/pmap.c
index 4b81aae..122318c 100644
--- a/sys/i386/xen/pmap.c
+++ b/sys/i386/xen/pmap.c
@@ -1004,8 +1004,8 @@ pmap_invalidate_cache_range(vm_offset_t sva, vm_offset_t eva)
 		 * coherence domain.
 		 */
 		mfence();
-		for (; eva < sva; eva += cpu_clflush_line_size)
-			clflush(eva);
+		for (; sva < eva; sva += cpu_clflush_line_size)
+			clflush(sva);
 		mfence();
 	} else {
 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090909/ef5c1329/attachment.pgp
From tlott at gamesnet.de  Wed Sep  9 19:30:28 2009
From: tlott at gamesnet.de (Tobias Lott)
Date: Wed Sep  9 19:30:35 2009
Subject: System crawls after Upgrade 7.0->7.2
In-Reply-To: <20090909170213.GA7925@lava.net>
References: <20090908121945.43ba3976@sub.han.vpn.gamesnet.de>
	<20090909104807.633418ea@sub.han.vpn.gamesnet.de>
	<20090909170213.GA7925@lava.net>
Message-ID: <20090909213022.34d64e47@sub.han.vpn.gamesnet.de>



On Wed, 9 Sep 2009 07:02:13 -1000
Clifton Royston <cliftonr@lava.net> wrote:

> On Wed, Sep 09, 2009 at 10:48:07AM +0200, Tobias Lott wrote:
> > On Tue, 8 Sep 2009 12:19:45 +0200
> > Tobias Lott <tlott@gamesnet.de> wrote:
> > > Hey Everyone,
> > > 
> > > I upgraded a Dual Core Machine to 7.2-Stable (2 Days ago), all OS
> > > related Stuff is located on an UFS Slice, Application is on a ZFS
> > > Volume.
> > > 
> > > After the Upgrade everything seemed fine, but a User noticed one
> > > PHP Script which is basically loading a plain Textfile into Mysql
> > > times out. PHP Timeout was set to 60 secs, that was more then
> > > enough just one day before the upgrade.
> ...
> > > Since I upgraded the Machines zpool to version 13 already I don't
> > > really wanna go back to 7.0, but it seems the only way out atm.
> > > 
> > > Hopefully someone can give me a Hint where maybe I forgot to
> > > check.
> > > 
> > > Somehow it feels like the last Versions, I'd say starting with 7.x
> > > doesn't really feel that Rock-Stable as Versions Prior used to
> > > be. Prolly cause I'm using an Experimental Feature like ZFS, so no
> > > Offense nor Blame and this is not intended as a Flame or
> > > whatsoever! So don't get me wrong, I always liked, used,
> > > recommended FreeBSD since 4.0 and will continue to do so!
> > > 
> > > Best Regards
> > > 
> > 
> > I've tested some more it seems the Bottleneck is the HD, Raid Array
> > is Optimal checked it.
> 
>   Probably you already checked this, but did you go through the dmesg
> output relating to ata and drive detection closely?
> 
>   In the past from time to time I've had machines suddenly start
> crawling after an upgrade, and it turned out it was because some
> change in the driver detection caused the ata to fall back to pio
> mode.  The symptoms are pretty much like you describe - all HD IO
> takes forever.
> 
>   -- Clifton
> 

Thanks for that Hint, checked again to be sure, but thats not the Case.

mpt0:vol0(mpt0:0:0): Settings ( Hot-Plug-Spares High-Priority-ReSync )
mpt0:vol0(mpt0:0:0): Using Spare Pool: 0
mpt0:vol0(mpt0:0:0): 2 Members:
      (mpt0:1:32:0): Primary Online
      (mpt0:1:1:0): Secondary Online
mpt0:vol0(mpt0:0:0): RAID-1 - Optimal
mpt0:vol0(mpt0:0:0): Status ( Enabled )
(mpt0:vol0:1): Physical (mpt0:0:1:0), Pass-thru (mpt0:1:0:0)
(mpt0:vol0:1): Online
(mpt0:vol0:0): Physical (mpt0:0:32:0), Pass-thru (mpt0:1:1:0)
(mpt0:vol0:0): Online
acd0: CDROM <HL-DT-ST GCR-8240N/1.10> at ata0-master UDMA33
acd1: CDROM <VIRTUALCDROM DRIVE/> at ata2-slave PIO3
da0 at mpt0 bus 0 target 0 lun 0
da0: <Dell VIRTUAL DISK 1028> Fixed Direct Access SCSI-5 device 
da0: 300.000MB/s transfers
da0: Command Queueing Enabled
SdMaP0::  A1P5 1C6P3U4 M#B1  (L3a1u0n5c4h6e4d3!2
 512 byte sectors: 255H 63S/T 19330C)


-- 
Tobias Lott
From tlott at gamesnet.de  Wed Sep  9 20:00:11 2009
From: tlott at gamesnet.de (Tobias Lott)
Date: Wed Sep  9 20:00:46 2009
Subject: System crawls after Upgrade 7.0->7.2
In-Reply-To: <20090909213022.34d64e47@sub.han.vpn.gamesnet.de>
References: <20090908121945.43ba3976@sub.han.vpn.gamesnet.de>
	<20090909104807.633418ea@sub.han.vpn.gamesnet.de>
	<20090909170213.GA7925@lava.net>
	<20090909213022.34d64e47@sub.han.vpn.gamesnet.de>
Message-ID: <20090909215959.6b5152f2@sub.han.vpn.gamesnet.de>



On Wed, 9 Sep 2009 21:30:22 +0200
Tobias Lott <tlott@gamesnet.de> wrote:

> 
> 
> On Wed, 9 Sep 2009 07:02:13 -1000
> Clifton Royston <cliftonr@lava.net> wrote:
> 
> > On Wed, Sep 09, 2009 at 10:48:07AM +0200, Tobias Lott wrote:
> > > On Tue, 8 Sep 2009 12:19:45 +0200
> > > Tobias Lott <tlott@gamesnet.de> wrote:
> > > > Hey Everyone,
> > > > 
> > > > I upgraded a Dual Core Machine to 7.2-Stable (2 Days ago), all
> > > > OS related Stuff is located on an UFS Slice, Application is on
> > > > a ZFS Volume.
> > > > 
> > > > After the Upgrade everything seemed fine, but a User noticed one
> > > > PHP Script which is basically loading a plain Textfile into
> > > > Mysql times out. PHP Timeout was set to 60 secs, that was more
> > > > then enough just one day before the upgrade.
> > ...
> > > > Since I upgraded the Machines zpool to version 13 already I
> > > > don't really wanna go back to 7.0, but it seems the only way
> > > > out atm.
> > > > 
> > > > Hopefully someone can give me a Hint where maybe I forgot to
> > > > check.
> > > > 
> > > > Somehow it feels like the last Versions, I'd say starting with
> > > > 7.x doesn't really feel that Rock-Stable as Versions Prior used
> > > > to be. Prolly cause I'm using an Experimental Feature like ZFS,
> > > > so no Offense nor Blame and this is not intended as a Flame or
> > > > whatsoever! So don't get me wrong, I always liked, used,
> > > > recommended FreeBSD since 4.0 and will continue to do so!
> > > > 
> > > > Best Regards
> > > > 
> > > 
> > > I've tested some more it seems the Bottleneck is the HD, Raid
> > > Array is Optimal checked it.
> > 
> >   Probably you already checked this, but did you go through the
> > dmesg output relating to ata and drive detection closely?
> > 
> >   In the past from time to time I've had machines suddenly start
> > crawling after an upgrade, and it turned out it was because some
> > change in the driver detection caused the ata to fall back to pio
> > mode.  The symptoms are pretty much like you describe - all HD IO
> > takes forever.
> > 
> >   -- Clifton
> > 
> 
> Thanks for that Hint, checked again to be sure, but thats not the
> Case.
> 
> mpt0:vol0(mpt0:0:0): Settings ( Hot-Plug-Spares High-Priority-ReSync )
> mpt0:vol0(mpt0:0:0): Using Spare Pool: 0
> mpt0:vol0(mpt0:0:0): 2 Members:
>       (mpt0:1:32:0): Primary Online
>       (mpt0:1:1:0): Secondary Online
> mpt0:vol0(mpt0:0:0): RAID-1 - Optimal
> mpt0:vol0(mpt0:0:0): Status ( Enabled )
> (mpt0:vol0:1): Physical (mpt0:0:1:0), Pass-thru (mpt0:1:0:0)
> (mpt0:vol0:1): Online
> (mpt0:vol0:0): Physical (mpt0:0:32:0), Pass-thru (mpt0:1:1:0)
> (mpt0:vol0:0): Online
> acd0: CDROM <HL-DT-ST GCR-8240N/1.10> at ata0-master UDMA33
> acd1: CDROM <VIRTUALCDROM DRIVE/> at ata2-slave PIO3
> da0 at mpt0 bus 0 target 0 lun 0
> da0: <Dell VIRTUAL DISK 1028> Fixed Direct Access SCSI-5 device 
> da0: 300.000MB/s transfers
> da0: Command Queueing Enabled
> SdMaP0::  A1P5 1C6P3U4 M#B1  (L3a1u0n5c4h6e4d3!2
>  512 byte sectors: 255H 63S/T 19330C)
> 
> 

Oh well just did some more research and found:
http://www.mail-archive.com/freebsd-performance@freebsd.org/msg02461.html

Gonna try it out later and gonna give a Report.

-- 
Tobias Lott
From rizzo at iet.unipi.it  Wed Sep  9 20:26:18 2009
From: rizzo at iet.unipi.it (Luigi Rizzo)
Date: Wed Sep  9 20:26:26 2009
Subject: incorrect usleep/select delays with HZ > 2500
In-Reply-To: <200909091324.53668.jhb@freebsd.org>
References: <20090906155154.GA8283@onelab2.iet.unipi.it>
	<200909081308.23345.jhb@freebsd.org>
	<20090908210100.GA72735@onelab2.iet.unipi.it>
	<200909091324.53668.jhb@freebsd.org>
Message-ID: <20090909203216.GA93761@onelab2.iet.unipi.it>

On Wed, Sep 09, 2009 at 01:24:53PM -0400, John Baldwin wrote:
> On Tuesday 08 September 2009 5:01:00 pm Luigi Rizzo wrote:
> > On Tue, Sep 08, 2009 at 01:08:23PM -0400, John Baldwin wrote:
> > > On Sunday 06 September 2009 11:51:54 am Luigi Rizzo wrote:
> > > > [Note 3] the TSC frequency is computed reading the tsc around a
> > > >         call to DELAY(1000000) and assuming that the i8254 runs
> > > >         at the nominal rate, 1.193182 MHz.
> > > >         From tests I have made, the measurement in init_TSC() returns
> > > >         a large error when HZ is large, whereas repeating the 
> measurement
> > > >         at a later time returns a much more reliable value.
...
> > > Try disabling legacy USB support in the BIOS to see if an SMI# is firing 
> > > during the DELAY() causing the TSC freq to be too high.  I have seen the 
> USB 
> > > legacy support cause this in other machines.
> > 
> > Thanks, will try tomorrow.
> > Would this explain the measurement becomes better as we get
> > further into the initialization, and why high HZ values affect
> > the measurement ?
> 
> It would explain why it gets better later since the uhci(4), ohci(4) and 
> ehci(4) drivers disable the SMI# interrupts while attaching to the 
> controllers.

ok makes sense -- if the SMI interrupts last longer than 1/HZ
they will cause us to miss one or more wraps of the i8254 in
$ARCH/isa/clock.c::DELAY(). I suppose with a few measurements
at different HZ values and some back of the envelope calculations
one could even determine estimate the frequency and duration
of those SMI interrupts!

thanks
luigi
From brooks at freebsd.org  Wed Sep  9 20:29:26 2009
From: brooks at freebsd.org (Brooks Davis)
Date: Wed Sep  9 20:29:32 2009
Subject: ifconfig_ed0="DHCP" does not work on 8.0-BETA3
In-Reply-To: <20090909170701.GB38292@graf.pompo.net>
References: <20090904173811.GA45176@graf.pompo.net>
	<20090904214148.GB9950@michelle.cdnetworks.com>
	<20090904215747.GB82231@lor.one-eyed-alien.net>
	<20090905110635.GG87716@graf.pompo.net>
	<20090909155257.GF42196@lor.one-eyed-alien.net>
	<20090909170701.GB38292@graf.pompo.net>
Message-ID: <20090909202948.GG42196@lor.one-eyed-alien.net>

On Wed, Sep 09, 2009 at 07:07:01PM +0200, Thierry Thomas wrote:
> Le Mer  9 sep 09 ? 17:52:57 +0200, Brooks Davis <brooks@freebsd.org>
>  ?crivait?:
> 
> > I'd rather not mention the "link state changed" message since I'd love
> > to see it go away.  How's this?
> 
> Seems good, go!

Thanks.  I've committed it.

Brooks
From jhb at freebsd.org  Wed Sep  9 20:42:13 2009
From: jhb at freebsd.org (John Baldwin)
Date: Wed Sep  9 20:42:20 2009
Subject: incorrect usleep/select delays with HZ > 2500
In-Reply-To: <20090909203216.GA93761@onelab2.iet.unipi.it>
References: <20090906155154.GA8283@onelab2.iet.unipi.it>
	<200909091324.53668.jhb@freebsd.org>
	<20090909203216.GA93761@onelab2.iet.unipi.it>
Message-ID: <200909091642.06046.jhb@freebsd.org>

On Wednesday 09 September 2009 4:32:16 pm Luigi Rizzo wrote:
> On Wed, Sep 09, 2009 at 01:24:53PM -0400, John Baldwin wrote:
> > On Tuesday 08 September 2009 5:01:00 pm Luigi Rizzo wrote:
> > > On Tue, Sep 08, 2009 at 01:08:23PM -0400, John Baldwin wrote:
> > > > On Sunday 06 September 2009 11:51:54 am Luigi Rizzo wrote:
> > > > > [Note 3] the TSC frequency is computed reading the tsc around a
> > > > >         call to DELAY(1000000) and assuming that the i8254 runs
> > > > >         at the nominal rate, 1.193182 MHz.
> > > > >         From tests I have made, the measurement in init_TSC() 
returns
> > > > >         a large error when HZ is large, whereas repeating the 
> > measurement
> > > > >         at a later time returns a much more reliable value.
> ...
> > > > Try disabling legacy USB support in the BIOS to see if an SMI# is 
firing 
> > > > during the DELAY() causing the TSC freq to be too high.  I have seen 
the 
> > USB 
> > > > legacy support cause this in other machines.
> > > 
> > > Thanks, will try tomorrow.
> > > Would this explain the measurement becomes better as we get
> > > further into the initialization, and why high HZ values affect
> > > the measurement ?
> > 
> > It would explain why it gets better later since the uhci(4), ohci(4) and 
> > ehci(4) drivers disable the SMI# interrupts while attaching to the 
> > controllers.
> 
> ok makes sense -- if the SMI interrupts last longer than 1/HZ
> they will cause us to miss one or more wraps of the i8254 in
> $ARCH/isa/clock.c::DELAY(). I suppose with a few measurements
> at different HZ values and some back of the envelope calculations
> one could even determine estimate the frequency and duration
> of those SMI interrupts!

On recent motherboards I have seen the SMI# interrupt fire every 250 ms with 
execution times ranging from 50 us to 1ms for the legacy USB interrupt 
handler.  We consistently see the TSC frequency miscalculated on the 
motherboards with the 1ms duration interrupt.  I suspect that the clock that 
drives the periodic SMI# interrupt is tied to the i8254 meaning that it often 
fires at the same time that the i8254 wraps causing the TSC frequency to 
often be wrong.

-- 
John Baldwin
From njm at njm.me.uk  Wed Sep  9 20:44:34 2009
From: njm at njm.me.uk (N.J. Mann)
Date: Wed Sep  9 20:44:42 2009
Subject: Upgrade FreeBSD 7.1 to 7.2
In-Reply-To: <y9lws488fu9.fsf@c052021.wlan.net.ed.ac.uk>
References: <4A8EAE86.2000108@t-online.hu> <4A8ECB9C.2020909@quip.cz>
	<alpine.BSF.2.00.0908221229480.61512@fledge.watson.org>
	<y9lws488fu9.fsf@c052021.wlan.net.ed.ac.uk>
Message-ID: <20090909204431.GB88622@titania.njm.me.uk>

In message <y9lws488fu9.fsf@c052021.wlan.net.ed.ac.uk>,
	Michael Sperber (sperber@deinprogramm.de) wrote:
> 
> Robert Watson <rwatson@FreeBSD.org> writes:
> 
> > FWIW, the main problem I ran into with my 8.0 upgrade is that 8.0 uses
> > the uart(4) driver for serial ports, and sio(4), 7.2's default, has
> > been removed. They require mutually exclusive lines in device.hints
> > and different /etc/ttys lines.  If you rely on a serial console, I
> > would recommend first switching 7.2 to using uart, pausing for a bit,
> > and then switching forward to 8 so that you separate the risks
> > associated with changing console drivers from those associated with
> > sliding a major kernel version.
> 
> Could you briefly elaborate on how that's done with 7.x?  I.e. is
> changing device.hints and /etc/ttys enough (what changes?), or do I need
> to recompile the kernel?  (I'm a bit confused because both uart and sio
> seem to be in GENERIC, but I haven't been able to active uart through
> device.hints.  I couldn't find anything on freebsd.org or the internets,
> either.)  A few hints would be much appreciated!

Robert's comment prompted me to try this on my home server which runs
7-STABLE, but which I will probably upgrade to 8-STABLE in a few months
time.  What I did was:

 1. Replace 'device sio' with 'device uart' in the kernel configuration
    file.
 2. In /etc/ttys change all ttydX to ttyuX, where X was 0 to 3 in my
    case.
 3. In /boot/device.hints change all hint.sio.X.Y to hint.uart.X.Y

I then rebooted with my fingers crossed since said machine is headless.
I need not have worried since it worked first time.

If anyone thinks I forgot something please _do_ speak up.

HTH


Cheers,
       Nick.
-- 

From peterjeremy at acm.org  Wed Sep  9 20:57:57 2009
From: peterjeremy at acm.org (Peter Jeremy)
Date: Wed Sep  9 20:58:03 2009
Subject: GCC -m32 option on FreeBSD/AMD64 7.2
In-Reply-To: <4A9D561F.5000808@sh.cvut.cz>
References: <4A9D561F.5000808@sh.cvut.cz>
Message-ID: <20090909193345.GA55347@server.vk2pj.dyndns.org>

On 2009-Sep-01 19:13:03 +0200, V?clav Haisman <v.haisman@sh.cvut.cz> wrote:
>is C++ + GCC -m32 option officially supported by FreeBSD/AMD64 7.2?

The short answer is "no" - though this is a common request and there
are some PRs open for it.  At present, the only supported way to build
i386 code on amd64 is by installing an i386 world and compiling in
either a jail or chroot.

Basically, whilst '-m32' correctly generates 32-bit code, virtually
all programs wind up (indirectly) #include'ing files from
/usr/include/machine and this directory assumes the native machine
definitions - in the case of amd64, longs and pointers are 64-bits.
Whilst it's not immediately obvious what happened here, I am confident
this is the underlying cause.

-- 
Peter Jeremy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090909/8440d7d0/attachment.pgp
From rizzo at iet.unipi.it  Wed Sep  9 21:05:26 2009
From: rizzo at iet.unipi.it (Luigi Rizzo)
Date: Wed Sep  9 21:05:33 2009
Subject: incorrect usleep/select delays with HZ > 2500
In-Reply-To: <200909091642.06046.jhb@freebsd.org>
References: <20090906155154.GA8283@onelab2.iet.unipi.it>
	<200909091324.53668.jhb@freebsd.org>
	<20090909203216.GA93761@onelab2.iet.unipi.it>
	<200909091642.06046.jhb@freebsd.org>
Message-ID: <20090909211123.GD93761@onelab2.iet.unipi.it>

On Wed, Sep 09, 2009 at 04:42:05PM -0400, John Baldwin wrote:
...
> > > It would explain why it gets better later since the uhci(4), ohci(4) and 
> > > ehci(4) drivers disable the SMI# interrupts while attaching to the 
> > > controllers.
> > 
> > ok makes sense -- if the SMI interrupts last longer than 1/HZ
> > they will cause us to miss one or more wraps of the i8254 in
> > $ARCH/isa/clock.c::DELAY(). I suppose with a few measurements
> > at different HZ values and some back of the envelope calculations
> > one could even determine estimate the frequency and duration
> > of those SMI interrupts!
> 
> On recent motherboards I have seen the SMI# interrupt fire every 250 ms with 
> execution times ranging from 50 us to 1ms for the legacy USB interrupt 
> handler.  We consistently see the TSC frequency miscalculated on the 
> motherboards with the 1ms duration interrupt.  I suspect that the clock that 
> drives the periodic SMI# interrupt is tied to the i8254 meaning that it often 
> fires at the same time that the i8254 wraps causing the TSC frequency to 
> often be wrong.

when or even how often it fires should not matter much -- as long
as the interrupt is shorter than 1 tick we will be able to see the
wrap and handle it correctly. I'll try to write a 1-sec loop around
rdtsc() and log large differences in the reads to figure out
whether i am getting some long interrupts.

cheers
luigi
From vince at unsane.co.uk  Wed Sep  9 22:12:35 2009
From: vince at unsane.co.uk (Vincent Hoffman)
Date: Wed Sep  9 22:12:42 2009
Subject: general protection fault on boot.
In-Reply-To: <200909091446.47077.jhb@freebsd.org>
References: <4AA7D8B3.1010203@unsane.co.uk>
	<200909091339.00193.jhb@freebsd.org>
	<200909091446.47077.jhb@freebsd.org>
Message-ID: <4AA82851.7060306@unsane.co.uk>

John Baldwin wrote:
> On Wednesday 09 September 2009 1:38:59 pm John Baldwin wrote:
>   
>> On Wednesday 09 September 2009 12:32:51 pm Vincent Hoffman wrote:
>>     
>>> Hi all,
>>>           I've been running the 8.0-BETAs in a xen virtual machine
>>> (hvm/fully virtualised) for testing and something between r196730 and
>>> r196746 causes a general protection fault on boot. I'll try and narrow
>>> it down if i get a chance but I'm a a bit busy at the moment.
>>>  
>>> backtrace is available at
>>> http://unsane.co.uk/~jhary/freebsd/GPF-09-09-09.gif 
>>> Xen dom0 is a centos5.3 box using the xen-3.3.1 rpms from
>>> http://www.gitco.de/linux/i386/centos/5/rpms/  if thats of any use.
>>>
>>> Let me know if I need to provide any more info.
>>>       
>> Hmm, can you try reverting 196737?  Or actually, can you print out the value 
>> of %ebx ('p $ebx' in ddb will work I think)?  I wonder if this patch would 
>> fix it:
>>
>> Index: pmap.c
>> ===================================================================
>> --- pmap.c	(revision 196974)
>> +++ pmap.c	(working copy)
>> @@ -999,7 +999,7 @@
>>  		 * coherence domain.
>>  		 */
>>  		mfence();
>> -		for (; sva < eva; sva += cpu_clflush_line_size)
>> +		for (; sva <= eva; sva += cpu_clflush_line_size)
>>  			clflush(sva);
>>  		mfence();
>>  	} else {
>>     
>
> This patch is probably bogus.  I am curious what %ebx is however.
>
>   
p $ebx
gives
c25a7000

Vince

From vince at unsane.co.uk  Wed Sep  9 22:13:30 2009
From: vince at unsane.co.uk (Vincent Hoffman)
Date: Wed Sep  9 22:13:37 2009
Subject: general protection fault on boot.
In-Reply-To: <20090909190228.GC47688@deviant.kiev.zoral.com.ua>
References: <4AA7D8B3.1010203@unsane.co.uk>
	<200909091339.00193.jhb@freebsd.org>
	<20090909190228.GC47688@deviant.kiev.zoral.com.ua>
Message-ID: <4AA82888.2080707@unsane.co.uk>

Kostik Belousov wrote:
> On Wed, Sep 09, 2009 at 01:38:59PM -0400, John Baldwin wrote:
>   
>> On Wednesday 09 September 2009 12:32:51 pm Vincent Hoffman wrote:
>>     
>>> Hi all,
>>>           I've been running the 8.0-BETAs in a xen virtual machine
>>> (hvm/fully virtualised) for testing and something between r196730 and
>>> r196746 causes a general protection fault on boot. I'll try and narrow
>>> it down if i get a chance but I'm a a bit busy at the moment.
>>>  
>>> backtrace is available at
>>> http://unsane.co.uk/~jhary/freebsd/GPF-09-09-09.gif 
>>> Xen dom0 is a centos5.3 box using the xen-3.3.1 rpms from
>>> http://www.gitco.de/linux/i386/centos/5/rpms/  if thats of any use.
>>>
>>> Let me know if I need to provide any more info.
>>>       
>> Hmm, can you try reverting 196737?  Or actually, can you print out the value 
>> of %ebx ('p $ebx' in ddb will work I think)?  I wonder if this patch would 
>> fix it:
>>
>> Index: pmap.c
>> ===================================================================
>> --- pmap.c	(revision 196974)
>> +++ pmap.c	(working copy)
>> @@ -999,7 +999,7 @@
>>  		 * coherence domain.
>>  		 */
>>  		mfence();
>> -		for (; sva < eva; sva += cpu_clflush_line_size)
>> +		for (; sva <= eva; sva += cpu_clflush_line_size)
>>  			clflush(sva);
>>  		mfence();
>>  	} else {
>>     
>
> Oh, no, another pointy hat to me :(.
>
> Please, try this patch instead.
>
> diff --git a/sys/i386/xen/pmap.c b/sys/i386/xen/pmap.c
> index 4b81aae..122318c 100644
> --- a/sys/i386/xen/pmap.c
> +++ b/sys/i386/xen/pmap.c
> @@ -1004,8 +1004,8 @@ pmap_invalidate_cache_range(vm_offset_t sva, vm_offset_t eva)
>  		 * coherence domain.
>  		 */
>  		mfence();
> -		for (; eva < sva; eva += cpu_clflush_line_size)
> -			clflush(eva);
> +		for (; sva < eva; sva += cpu_clflush_line_size)
> +			clflush(sva);
>  		mfence();
>  	} else {
>  
>   
Ok will try this tomorrow.

Vince
From doconnor at gsoft.com.au  Thu Sep 10 02:41:07 2009
From: doconnor at gsoft.com.au (Daniel O'Connor)
Date: Thu Sep 10 02:41:14 2009
Subject: Detecting CPU throttling on over temperature
In-Reply-To: <1252501703.85394.3473.camel@balrog.2hip.net>
References: <1252426982.00160755.1252414203@10.7.7.3>
	<200909091747.19696.doconnor@gsoft.com.au>
	<1252501703.85394.3473.camel@balrog.2hip.net>
Message-ID: <200909101211.01534.doconnor@gsoft.com.au>

On Wed, 9 Sep 2009, Robert Noland wrote:
> > I am pretty sure it would be throttling but I think that works by
> > maintaining the frequency but stalling the CPU some percentage of
> > the time. I have p4tcc loaded (in GENERIC) but it doesn't show up,
> > I only get..
>
> Is this a core2duo?  IIRC, they generally don't go into TCC until
> around 100C.  I did pull the c2d cpu docs at one point trying to look
> at cpufreq.  If you are bored, you can grab the docs from intel and
> double check.

Hmm, I only managed to get it to 75C or so..

Unfortunately the remote system which was exhibiting the problem has 
been fixed and the onsite guy doesn't have time to pull it out and 
break it again :(

The coretemp source suggests that there are 2 max junction temperatures 
for Core2Duos - 85C & 100C.

However I just realised the "faulty" system has an E2140 in it which has 
a 65W TDP, whereas the bench system has an E7500 with a TDP of 35W - I 
guess that could explain the difference.

-- 
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
  -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090910/d153ea81/attachment.pgp
From doconnor at gsoft.com.au  Thu Sep 10 02:48:10 2009
From: doconnor at gsoft.com.au (Daniel O'Connor)
Date: Thu Sep 10 02:48:18 2009
Subject: Detecting CPU throttling on over temperature
In-Reply-To: <4AA7AA9B.9010709@FreeBSD.org>
References: <1252426982.00160755.1252414203@10.7.7.3>
	<1252501703.85394.3473.camel@balrog.2hip.net>
	<4AA7AA9B.9010709@FreeBSD.org>
Message-ID: <200909101218.05070.doconnor@gsoft.com.au>

On Wed, 9 Sep 2009, Alexander Motin wrote:
> > around 100C.  I did pull the c2d cpu docs at one point trying to
> > look at cpufreq.  If you are bored, you can grab the docs from
> > intel and double check.
>
> AFAIR C2D supports three protection technologies. When CPU is hot, it
> starts reducing frequency (multiplier) and voltage, alike to IEST. If
> it is insufficient, it starts to skip core cycles, alike to TCC. If
> it is still insufficient and temperature rises above about 100C,
> emergency shutdown happens.

Hmm, I have since realised it's an E2140 which doesn't have Core2Duo 
branding (I don't know if it really IS one or not).

On the bench here I could not observe an effect by running 
dd if=/dev/zero bs=128k count=5000| md5
in a loop and checking the frequency with
dev.cpu.0.freq

However the idle time seemed to go up, but only to 10% or so, it was 
quite odd..

Still, now I have been reminded of coretemp I can monitor it 
on "suspect" systems :)

-- 
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
  -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090910/53cc230b/attachment.pgp
From vince at unsane.co.uk  Thu Sep 10 10:34:26 2009
From: vince at unsane.co.uk (Vincent Hoffman)
Date: Thu Sep 10 10:34:33 2009
Subject: general protection fault on boot.
In-Reply-To: <20090909190228.GC47688@deviant.kiev.zoral.com.ua>
References: <4AA7D8B3.1010203@unsane.co.uk>
	<200909091339.00193.jhb@freebsd.org>
	<20090909190228.GC47688@deviant.kiev.zoral.com.ua>
Message-ID: <4AA8D62F.1020901@unsane.co.uk>

Kostik Belousov wrote:
> On Wed, Sep 09, 2009 at 01:38:59PM -0400, John Baldwin wrote:
>   
>> On Wednesday 09 September 2009 12:32:51 pm Vincent Hoffman wrote:
>>     
>>> Hi all,
>>>           I've been running the 8.0-BETAs in a xen virtual machine
>>> (hvm/fully virtualised) for testing and something between r196730 and
>>> r196746 causes a general protection fault on boot. I'll try and narrow
>>> it down if i get a chance but I'm a a bit busy at the moment.
>>>  
>>> backtrace is available at
>>> http://unsane.co.uk/~jhary/freebsd/GPF-09-09-09.gif 
>>> Xen dom0 is a centos5.3 box using the xen-3.3.1 rpms from
>>> http://www.gitco.de/linux/i386/centos/5/rpms/  if thats of any use.
>>>
>>> Let me know if I need to provide any more info.
>>>       
>> Hmm, can you try reverting 196737?  Or actually, can you print out the value 
>> of %ebx ('p $ebx' in ddb will work I think)?  I wonder if this patch would 
>> fix it:
>>
>> Index: pmap.c
>> ===================================================================
>> --- pmap.c	(revision 196974)
>> +++ pmap.c	(working copy)
>> @@ -999,7 +999,7 @@
>>  		 * coherence domain.
>>  		 */
>>  		mfence();
>> -		for (; sva < eva; sva += cpu_clflush_line_size)
>> +		for (; sva <= eva; sva += cpu_clflush_line_size)
>>  			clflush(sva);
>>  		mfence();
>>  	} else {
>>     
>
> Oh, no, another pointy hat to me :(.
>
> Please, try this patch instead.
>
> diff --git a/sys/i386/xen/pmap.c b/sys/i386/xen/pmap.c
> index 4b81aae..122318c 100644
> --- a/sys/i386/xen/pmap.c
> +++ b/sys/i386/xen/pmap.c
> @@ -1004,8 +1004,8 @@ pmap_invalidate_cache_range(vm_offset_t sva, vm_offset_t eva)
>  		 * coherence domain.
>  		 */
>  		mfence();
> -		for (; eva < sva; eva += cpu_clflush_line_size)
> -			clflush(eva);
> +		for (; sva < eva; sva += cpu_clflush_line_size)
> +			clflush(sva);
>  		mfence();
>  	} else {
>  
>   
Hi,
    I tried this this morning with no joy i'm afraid.
not much change but new backtrace (with p $ebx) at
http://www.unsane.co.uk/~jhary/freebsd/10-09-09.gif

Just to check I'm not in need of more coffee as i'm still learning svn
(and my coding skills such as they are lie in shell and perl)

krill# svn info
Path: .
URL: svn://svn.freebsd.org/base/stable/8
Repository Root: svn://svn.freebsd.org/base
Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Revision: 196740
Node Kind: directory
Schedule: normal
Last Changed Author: rnoland
Last Changed Rev: 196737
Last Changed Date: 2009-09-01 17:41:28 +0100 (Tue, 01 Sep 2009)


krill# sed -n '1010,1017p' sys/i386/xen/pmap.c
                 * coherence domain.
                 */
                mfence();
                for (; sva < eva; sva += cpu_clflush_line_size)
                        clflush(sva);
                mfence();
        } else {

krill#

Happy to give vnc access to the console of the machine if that would help.

Vince
From kostikbel at gmail.com  Thu Sep 10 11:28:58 2009
From: kostikbel at gmail.com (Kostik Belousov)
Date: Thu Sep 10 11:29:05 2009
Subject: general protection fault on boot.
In-Reply-To: <4AA8D62F.1020901@unsane.co.uk>
References: <4AA7D8B3.1010203@unsane.co.uk>
	<200909091339.00193.jhb@freebsd.org>
	<20090909190228.GC47688@deviant.kiev.zoral.com.ua>
	<4AA8D62F.1020901@unsane.co.uk>
Message-ID: <20090910112850.GG47688@deviant.kiev.zoral.com.ua>

On Thu, Sep 10, 2009 at 11:34:23AM +0100, Vincent Hoffman wrote:
> Kostik Belousov wrote:
> > On Wed, Sep 09, 2009 at 01:38:59PM -0400, John Baldwin wrote:
> >   
> >> On Wednesday 09 September 2009 12:32:51 pm Vincent Hoffman wrote:
> >>     
> >>> Hi all,
> >>>           I've been running the 8.0-BETAs in a xen virtual machine
> >>> (hvm/fully virtualised) for testing and something between r196730 and
> >>> r196746 causes a general protection fault on boot. I'll try and narrow
> >>> it down if i get a chance but I'm a a bit busy at the moment.
> >>>  
> >>> backtrace is available at
> >>> http://unsane.co.uk/~jhary/freebsd/GPF-09-09-09.gif 
> >>> Xen dom0 is a centos5.3 box using the xen-3.3.1 rpms from
> >>> http://www.gitco.de/linux/i386/centos/5/rpms/  if thats of any use.
> >>>
> >>> Let me know if I need to provide any more info.
> >>>       
> >> Hmm, can you try reverting 196737?  Or actually, can you print out the value 
> >> of %ebx ('p $ebx' in ddb will work I think)?  I wonder if this patch would 
> >> fix it:
> >>
> >> Index: pmap.c
> >> ===================================================================
> >> --- pmap.c	(revision 196974)
> >> +++ pmap.c	(working copy)
> >> @@ -999,7 +999,7 @@
> >>  		 * coherence domain.
> >>  		 */
> >>  		mfence();
> >> -		for (; sva < eva; sva += cpu_clflush_line_size)
> >> +		for (; sva <= eva; sva += cpu_clflush_line_size)
> >>  			clflush(sva);
> >>  		mfence();
> >>  	} else {
> >>     
> >
> > Oh, no, another pointy hat to me :(.
> >
> > Please, try this patch instead.
> >
> > diff --git a/sys/i386/xen/pmap.c b/sys/i386/xen/pmap.c
> > index 4b81aae..122318c 100644
> > --- a/sys/i386/xen/pmap.c
> > +++ b/sys/i386/xen/pmap.c
> > @@ -1004,8 +1004,8 @@ pmap_invalidate_cache_range(vm_offset_t sva, vm_offset_t eva)
> >  		 * coherence domain.
> >  		 */
> >  		mfence();
> > -		for (; eva < sva; eva += cpu_clflush_line_size)
> > -			clflush(eva);
> > +		for (; sva < eva; sva += cpu_clflush_line_size)
> > +			clflush(sva);
> >  		mfence();
> >  	} else {
> >  
> >   
> Hi,
>     I tried this this morning with no joy i'm afraid.
> not much change but new backtrace (with p $ebx) at
> http://www.unsane.co.uk/~jhary/freebsd/10-09-09.gif
I would need the panic message and ddb lines that are not
present on your screenshot.

Also, the dmesg is interesting (CPU features report).
> 
> Just to check I'm not in need of more coffee as i'm still learning svn
> (and my coding skills such as they are lie in shell and perl)
> 
> krill# svn info
> Path: .
> URL: svn://svn.freebsd.org/base/stable/8
> Repository Root: svn://svn.freebsd.org/base
> Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
> Revision: 196740
> Node Kind: directory
> Schedule: normal
> Last Changed Author: rnoland
> Last Changed Rev: 196737
> Last Changed Date: 2009-09-01 17:41:28 +0100 (Tue, 01 Sep 2009)
> 
> 
> krill# sed -n '1010,1017p' sys/i386/xen/pmap.c
>                  * coherence domain.
>                  */
>                 mfence();
>                 for (; sva < eva; sva += cpu_clflush_line_size)
>                         clflush(sva);
>                 mfence();
>         } else {
> 
> krill#
> 
> Happy to give vnc access to the console of the machine if that would help.
> 
> Vince
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090910/73b39748/attachment-0001.pgp
From sagara at tomahawk.com.sg  Thu Sep 10 12:04:51 2009
From: sagara at tomahawk.com.sg (Sagara Wijetunga)
Date: Thu Sep 10 12:05:00 2009
Subject: Avahi compilation help needed
Message-ID: <4AA8EBBD.5020709@tomahawk.com.sg>

Dear FreeBSD community

I'm trying to compile Avahi-0.6.25 (http://avahi.org/) on FreeBSD 7.2 
(i386) [in fact, on Tomahawk Desktop]. It develops compilation errors. 
Is it possible someone to help us by compile Avahi and identify the 
compilations issues and propose relevant fixes. We use "./configure, 
gmake, gmake install" method. For an example, first compilation issue 
faced was <netinet6/in6.h> does not get included because 
-D_XOPEN_SOURCE=500 in the configure script.

We use D-Bus and Qt4 but do not use Mono. It may be doesn't matter to 
build on Qt3. Please help us to get Avahi compile cleanly. We can 
install and see whether it works or not.

Many thanks in advance.

Kind regards
Sagara


From dimitry at andric.com  Thu Sep 10 12:08:46 2009
From: dimitry at andric.com (Dimitry Andric)
Date: Thu Sep 10 12:08:53 2009
Subject: Avahi compilation help needed
In-Reply-To: <4AA8EBBD.5020709@tomahawk.com.sg>
References: <4AA8EBBD.5020709@tomahawk.com.sg>
Message-ID: <4AA8EC4D.3080800@andric.com>

On 2009-09-10 14:06, Sagara Wijetunga wrote:
> I'm trying to compile Avahi-0.6.25 (http://avahi.org/) on FreeBSD 7.2 
> (i386) [in fact, on Tomahawk Desktop]. It develops compilation errors. 

Any reason why you don't use the net/avahi port instead?  This will save
you most compilation and installation headaches.  
From doconnor at gsoft.com.au  Thu Sep 10 12:43:49 2009
From: doconnor at gsoft.com.au (Daniel O'Connor)
Date: Thu Sep 10 12:43:57 2009
Subject: Detecting CPU throttling on over temperature
In-Reply-To: <20090909153851.GE48206@home.opsec.eu>
References: <1252426982.00160755.1252414203@10.7.7.3>
	<4AA7AA9B.9010709@FreeBSD.org>
	<20090909153851.GE48206@home.opsec.eu>
Message-ID: <200909102213.36510.doconnor@gsoft.com.au>

On Thu, 10 Sep 2009, Kurt Jaeger wrote:
> Any information on what can be done with AMD CPUs with respect
> to temperature monitoring ?

I thought coretemp had be modified in HEAD to support Phenoms but I 
can't find any evidence of that in SVN so I am not sure what I am 
thinking..


-- 
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
  -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090910/8c6a50ba/attachment.pgp
From ertr1013 at student.uu.se  Thu Sep 10 12:47:15 2009
From: ertr1013 at student.uu.se (Erik Trulsson)
Date: Thu Sep 10 12:47:23 2009
Subject: Detecting CPU throttling on over temperature
In-Reply-To: <200909102213.36510.doconnor@gsoft.com.au>
References: <1252426982.00160755.1252414203@10.7.7.3>
	<4AA7AA9B.9010709@FreeBSD.org>
	<20090909153851.GE48206@home.opsec.eu>
	<200909102213.36510.doconnor@gsoft.com.au>
Message-ID: <20090910124705.GA93885@owl.midgard.homeip.net>

On Thu, Sep 10, 2009 at 10:13:28PM +0930, Daniel O'Connor wrote:
> On Thu, 10 Sep 2009, Kurt Jaeger wrote:
> > Any information on what can be done with AMD CPUs with respect
> > to temperature monitoring ?
> 
> I thought coretemp had be modified in HEAD to support Phenoms but I 
> can't find any evidence of that in SVN so I am not sure what I am 
> thinking..


Look for amdtemp or k8temp (which it was named before K10/K11 support was
added.)  



-- 
<Insert your favourite quote here.>
Erik Trulsson
ertr1013@student.uu.se
From thomas at ronner.org  Thu Sep 10 12:48:08 2009
From: thomas at ronner.org (Thomas Ronner)
Date: Thu Sep 10 12:48:23 2009
Subject: Detecting CPU throttling on over temperature
In-Reply-To: <200909102213.36510.doconnor@gsoft.com.au>
References: <1252426982.00160755.1252414203@10.7.7.3>
	<4AA7AA9B.9010709@FreeBSD.org>
	<20090909153851.GE48206@home.opsec.eu>
	<200909102213.36510.doconnor@gsoft.com.au>
Message-ID: <94AEB920-0384-4E03-8589-8315F5DC549C@ronner.org>

Hi,

On 10 Sep 2009, at 14:43, Daniel O'Connor wrote:

> I thought coretemp had be modified in HEAD to support Phenoms but I
> can't find any evidence of that in SVN so I am not sure what I am
> thinking..

How about 'k8temp'?

# make search name=k8temp
Port:	k8temp-0.4.0
Path:	/usr/ports/sysutils/k8temp
Info:	Athlon 64 and Opteron on-die temperature reader
Maint:	tom@hur.st
B-deps:	
R-deps:	
WWW:	http://hur.st/k8temp/
# k8temp
CPU 0 Core 0 Sensor 0: 35c
CPU 0 Core 1 Sensor 0: 36c

This is on the amd64 version of FreeBSD 8.0 using an Athlon64 X2 4200+.



Thomas
From dalroi at solfertje.student.utwente.nl  Thu Sep 10 12:50:58 2009
From: dalroi at solfertje.student.utwente.nl (Alban Hertroys)
Date: Thu Sep 10 12:51:05 2009
Subject: gconcat file system damage
Message-ID: <A8C66415-67AC-482D-B1DD-CBC155C4A41E@solfertje.student.utwente.nl>

Hello,

I recently added two disks to the mirror on my 3ware 9550 controller  
with the intend to expand my mirror. It doesn't support that with  
differently sized disks though, so I ended up creating a new mirror  
and gconcat-ed them together. Now I'm seeing lots of UNKNOWN FILETYPE  
and PARTIAL somethings if fsck verifies the disk, all in subsequent  
inodes so it looks like fsck gets some offset wrong somewhere. It  
started with a number of SOFTUPDATE INCONSISTENCY's, which of course  
went away after disabling softupdates on that FS (it's hardly ever  
written to anyway).

I originally created the concatted disk in two steps. First I created  
the concat on my new mirrored disks and copied the files from my  
existing mirror in there. Second I appended the existing mirror to my  
concatted disk. It seemed to work fine, but now I'm seeing so much  
errors that I can only mount the concat r/o!

Is there anything I can do to fix the issue? World is a stable from  
just after the 7.2 release, I'm building a fresh one now.

Here are a few details:

 > uname -a
FreeBSD solfertje.student.utwente.nl 7.2-STABLE FreeBSD 7.2-STABLE #1:  
Thu Sep 10 01:34:44 CEST 2009     dalroi@solfertje.student.utwente.nl:/ 
usr/obj/usr/src/sys/ERGOPROXY  i386

 > gconcat list
Geom name: media
State: UP
Status: Total=2, Online=2
Type: AUTOMATIC
ID: 1530457230
Providers:
1. Name: concat/media
    Mediasize: 819977973760 (764G)
    Sectorsize: 512
    Mode: r1w0e1
Consumers:
1. Name: da0p1
    Mediasize: 319988660736 (298G)
    Sectorsize: 512
    Mode: r1w0e2
    Start: 499989313536
    End: 819977973760
2. Name: da1p1
    Mediasize: 499989314048 (466G)
    Sectorsize: 512
    Mode: r1w0e2
    Start: 0
    End: 499989313536

tw_cli output:

//solfertje> /c0 show

Unit  UnitType  Status         %RCmpl  %V/I/M  Stripe  Size(GB)   
Cache  AVrfy
------------------------------------------------------------------------------
u0    RAID-1    OK             -       -       -       298.013    
ON     OFF
u1    RAID-1    OK             -       -       -       465.651    
ON     OFF

Port   Status           Unit   Size        Blocks        Serial
---------------------------------------------------------------
p0     OK               u1     465.76 GB   976773168     9VM18XZY
p1     OK               u0     298.09 GB   625142448     5QF383J7
p2     OK               u1     465.76 GB   976773168     9VM141ST
p3     OK               u0     298.09 GB   625142448     9QF3Z5LM

//solfertje> /c0 show unitstatus

Unit  UnitType  Status         %RCmpl  %V/I/M  Stripe  Size(GB)   
Cache  AVrfy
------------------------------------------------------------------------------
u0    RAID-1    OK             -       -       -       298.013    
ON     OFF
u1    RAID-1    OK             -       -       -       465.651    
ON     OFF


Alban Hertroys

--
Screwing up is the best way to attach something to the ceiling.


!DSPAM:74,4aa8f20512071992670156!


From vince at unsane.co.uk  Thu Sep 10 13:02:15 2009
From: vince at unsane.co.uk (Vincent Hoffman)
Date: Thu Sep 10 13:02:22 2009
Subject: general protection fault on boot.
In-Reply-To: <20090910112850.GG47688@deviant.kiev.zoral.com.ua>
References: <4AA7D8B3.1010203@unsane.co.uk>	<200909091339.00193.jhb@freebsd.org>	<20090909190228.GC47688@deviant.kiev.zoral.com.ua>	<4AA8D62F.1020901@unsane.co.uk>
	<20090910112850.GG47688@deviant.kiev.zoral.com.ua>
Message-ID: <4AA8F8D1.409@unsane.co.uk>

Kostik Belousov wrote:
> On Thu, Sep 10, 2009 at 11:34:23AM +0100, Vincent Hoffman wrote:
>   
>> Kostik Belousov wrote:
>>     
>>> On Wed, Sep 09, 2009 at 01:38:59PM -0400, John Baldwin wrote:
>>>   
>>>       
>>>> On Wednesday 09 September 2009 12:32:51 pm Vincent Hoffman wrote:
>>>>     
>>>>         
>>>>> Hi all,
>>>>>           I've been running the 8.0-BETAs in a xen virtual machine
>>>>> (hvm/fully virtualised) for testing and something between r196730 and
>>>>> r196746 causes a general protection fault on boot. I'll try and narrow
>>>>> it down if i get a chance but I'm a a bit busy at the moment.
>>>>>  
>>>>> backtrace is available at
>>>>> http://unsane.co.uk/~jhary/freebsd/GPF-09-09-09.gif 
>>>>> Xen dom0 is a centos5.3 box using the xen-3.3.1 rpms from
>>>>> http://www.gitco.de/linux/i386/centos/5/rpms/  if thats of any use.
>>>>>
>>>>> Let me know if I need to provide any more info.
>>>>>       
>>>>>           
>>>> Hmm, can you try reverting 196737?  Or actually, can you print out the value 
>>>> of %ebx ('p $ebx' in ddb will work I think)?  I wonder if this patch would 
>>>> fix it:
>>>>
>>>> Index: pmap.c
>>>> ===================================================================
>>>> --- pmap.c	(revision 196974)
>>>> +++ pmap.c	(working copy)
>>>> @@ -999,7 +999,7 @@
>>>>  		 * coherence domain.
>>>>  		 */
>>>>  		mfence();
>>>> -		for (; sva < eva; sva += cpu_clflush_line_size)
>>>> +		for (; sva <= eva; sva += cpu_clflush_line_size)
>>>>  			clflush(sva);
>>>>  		mfence();
>>>>  	} else {
>>>>     
>>>>         
>>> Oh, no, another pointy hat to me :(.
>>>
>>> Please, try this patch instead.
>>>
>>> diff --git a/sys/i386/xen/pmap.c b/sys/i386/xen/pmap.c
>>> index 4b81aae..122318c 100644
>>> --- a/sys/i386/xen/pmap.c
>>> +++ b/sys/i386/xen/pmap.c
>>> @@ -1004,8 +1004,8 @@ pmap_invalidate_cache_range(vm_offset_t sva, vm_offset_t eva)
>>>  		 * coherence domain.
>>>  		 */
>>>  		mfence();
>>> -		for (; eva < sva; eva += cpu_clflush_line_size)
>>> -			clflush(eva);
>>> +		for (; sva < eva; sva += cpu_clflush_line_size)
>>> +			clflush(sva);
>>>  		mfence();
>>>  	} else {
>>>  
>>>   
>>>       
>> Hi,
>>     I tried this this morning with no joy i'm afraid.
>> not much change but new backtrace (with p $ebx) at
>> http://www.unsane.co.uk/~jhary/freebsd/10-09-09.gif
>>     
> I would need the panic message and ddb lines that are not
> present on your screenshot.
>
> Also, the dmesg is interesting (CPU features report).
>   
Sorry, did need more coffee after all then.
http://unsane.co.uk/~jhary/freebsd/gpf-10-09-09-1.gif 
http://unsane.co.uk/~jhary/freebsd/gpf-10-09-09-2.gif
http://unsane.co.uk/~jhary/freebsd/dmesg.boot

like I said, Console access via vnc is available if wanted.

Vince


>> Just to check I'm not in need of more coffee as i'm still learning svn
>> (and my coding skills such as they are lie in shell and perl)
>>
>> krill# svn info
>> Path: .
>> URL: svn://svn.freebsd.org/base/stable/8
>> Repository Root: svn://svn.freebsd.org/base
>> Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
>> Revision: 196740
>> Node Kind: directory
>> Schedule: normal
>> Last Changed Author: rnoland
>> Last Changed Rev: 196737
>> Last Changed Date: 2009-09-01 17:41:28 +0100 (Tue, 01 Sep 2009)
>>
>>
>> krill# sed -n '1010,1017p' sys/i386/xen/pmap.c
>>                  * coherence domain.
>>                  */
>>                 mfence();
>>                 for (; sva < eva; sva += cpu_clflush_line_size)
>>                         clflush(sva);
>>                 mfence();
>>         } else {
>>
>> krill#
>>
>> Happy to give vnc access to the console of the machine if that would help.
>>
>> Vince
>>     

From lists at c0mplx.org  Thu Sep 10 13:21:08 2009
From: lists at c0mplx.org (Kurt Jaeger)
Date: Thu Sep 10 13:21:15 2009
Subject: Detecting CPU throttling on over temperature
In-Reply-To: <94AEB920-0384-4E03-8589-8315F5DC549C@ronner.org>
References: <1252426982.00160755.1252414203@10.7.7.3>
	<4AA7AA9B.9010709@FreeBSD.org>
	<20090909153851.GE48206@home.opsec.eu>
	<200909102213.36510.doconnor@gsoft.com.au>
	<94AEB920-0384-4E03-8589-8315F5DC549C@ronner.org>
Message-ID: <20090910132107.GH48206@home.opsec.eu>

Hi!

> > I thought coretemp had be modified in HEAD to support Phenoms but I
> > can't find any evidence of that in SVN so I am not sure what I am
> > thinking..
> 
> How about 'k8temp'?

/usr/ports/sysutils/k8temp

This works, very nice!

Thanks!

-- 
pi@opsec.eu            +49 171 3101372                        11 years to go !
From bap-fbsd-stable at a1.org.uk  Thu Sep 10 13:28:46 2009
From: bap-fbsd-stable at a1.org.uk (Bap)
Date: Thu Sep 10 13:28:52 2009
Subject: Detecting CPU throttling on over temperature
In-Reply-To: <20090909155921.GG48206@home.opsec.eu>
References: <1252426982.00160755.1252414203@10.7.7.3>
	<200909091018.10509.doconnor@gsoft.com.au>
	<4AA72D4D.9080505@FreeBSD.org>
	<200909091747.19696.doconnor@gsoft.com.au>
	<1252501703.85394.3473.camel@balrog.2hip.net>
	<4AA7AA9B.9010709@FreeBSD.org> <20090909153851.GE48206@home.opsec.eu>
	<4AA7CE0A.9030502@icyb.net.ua> <20090909155921.GG48206@home.opsec.eu>
Message-ID: <20090910140946.95543prdehmirhc0@mail.gwork.org>

Quoting Kurt Jaeger <pilists@c0mplx.org>:

> Hi!
>
>> > Any information on what can be done with AMD CPUs with respect
>> > to temperature monitoring ?
>>
>> amdtemp(4) ? :-)
>
> home$ man amdtemp
> No manual entry for amdtemp
>
> It's on 8.0-BETA4, but I have no amd64 running with that, yet.
>

wise# kldload k8temp
wise# sysctl -a | grep k8temp
dev.k8temp.0.%desc: AMD K8 Thermal Sensors
dev.k8temp.0.%driver: k8temp
dev.k8temp.0.%parent: hostb3
dev.k8temp.0.sensor0.core0: 21
dev.k8temp.0.sensor0.core1: 20
dev.k8temp.0.sensor1.core0: 21
dev.k8temp.0.sensor1.core1: 18
wise# uname -a
FreeBSD xxxxxxxxxxxxxxxxx 7.1-RELEASE FreeBSD 7.1-RELEASE #0: Thu Jan   
1 08:58:24 UTC 2009      
root@driscoll.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC  amd64


Bap.

> --
> pi@opsec.eu            +49 171 3101372                        11  
> years to go !
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
>

From rizzo at iet.unipi.it  Thu Sep 10 13:31:43 2009
From: rizzo at iet.unipi.it (Luigi Rizzo)
Date: Thu Sep 10 13:31:51 2009
Subject: Detecting CPU throttling on over temperature
In-Reply-To: <20090910132107.GH48206@home.opsec.eu>
References: <1252426982.00160755.1252414203@10.7.7.3>
	<4AA7AA9B.9010709@FreeBSD.org>
	<20090909153851.GE48206@home.opsec.eu>
	<200909102213.36510.doconnor@gsoft.com.au>
	<94AEB920-0384-4E03-8589-8315F5DC549C@ronner.org>
	<20090910132107.GH48206@home.opsec.eu>
Message-ID: <20090910133741.GA6000@onelab2.iet.unipi.it>

On Thu, Sep 10, 2009 at 03:21:07PM +0200, Kurt Jaeger wrote:
> Hi!
> 
> > > I thought coretemp had be modified in HEAD to support Phenoms but I
> > > can't find any evidence of that in SVN so I am not sure what I am
> > > thinking..
> > 
> > How about 'k8temp'?
> 
> /usr/ports/sysutils/k8temp
> 
> This works, very nice!

note though that the numbers you get seem way off reality:

bsd7# k8temp
CPU 0 Core 0 Sensor 0: 13c
CPU 0 Core 0 Sensor 1: 13c
CPU 0 Core 1 Sensor 0: 16c
CPU 0 Core 1 Sensor 1: 3c

(they do increase with CPU load).
From doconnor at gsoft.com.au  Thu Sep 10 13:32:34 2009
From: doconnor at gsoft.com.au (Daniel O'Connor)
Date: Thu Sep 10 13:32:41 2009
Subject: incorrect usleep/select delays with HZ > 2500
In-Reply-To: <200909091642.06046.jhb@freebsd.org>
References: <20090906155154.GA8283@onelab2.iet.unipi.it>
	<20090909203216.GA93761@onelab2.iet.unipi.it>
	<200909091642.06046.jhb@freebsd.org>
Message-ID: <200909102302.26318.doconnor@gsoft.com.au>

On Thu, 10 Sep 2009, John Baldwin wrote:
> > $ARCH/isa/clock.c::DELAY(). I suppose with a few measurements
> > at different HZ values and some back of the envelope calculations
> > one could even determine estimate the frequency and duration
> > of those SMI interrupts!
>
> On recent motherboards I have seen the SMI# interrupt fire every 250
> ms with execution times ranging from 50 us to 1ms for the legacy USB
> interrupt handler.  We consistently see the TSC frequency
> miscalculated on the motherboards with the 1ms duration interrupt.  I
> suspect that the clock that drives the periodic SMI# interrupt is
> tied to the i8254 meaning that it often fires at the same time that
> the i8254 wraps causing the TSC frequency to often be wrong.

Can the calculation code disable the SMI# interrupt? Disabling legacy 
USB could be a problem if you want to use a USB keyboard with the 
loader (I think).

-- 
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
  -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090910/258ba3f4/attachment.pgp
From doconnor at gsoft.com.au  Thu Sep 10 13:32:52 2009
From: doconnor at gsoft.com.au (Daniel O'Connor)
Date: Thu Sep 10 13:33:00 2009
Subject: Detecting CPU throttling on over temperature
In-Reply-To: <20090909171530.GC38292@graf.pompo.net>
References: <200909082209.37454.doconnor@gsoft.com.au>
	<20090909171530.GC38292@graf.pompo.net>
Message-ID: <200909102302.47809.doconnor@gsoft.com.au>

On Thu, 10 Sep 2009, Thierry Thomas wrote:
> > I recently discovered a system where the floppy drive cable was
> > intermittently fouling the CPU fan - I believe this caused the CPU
> > to overheat and then get throttled by the BIOS.
> >
> > Does anyone know if it is possible to determine if this is the
> > case? ie is there a way to be informed if throttling has occurred?
>
> Have you tried the ports sysutils/lmmon and sysutils/wmlmmon?
>
> Some others exist under /usr/ports/sysutils, but I don't use them.

Those tools are usually very difficult to get to work unless you can get 
information from your motherboard maker because various voltage 
dividers are set by the mobo maker..

In any case measuring the temperature is only a proxy, direct (rate 
limited!) notification of the throttling even would be better.

-- 
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
  -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090910/eb0db930/attachment.pgp
From rizzo at iet.unipi.it  Thu Sep 10 13:50:46 2009
From: rizzo at iet.unipi.it (Luigi Rizzo)
Date: Thu Sep 10 13:50:53 2009
Subject: incorrect usleep/select delays with HZ > 2500
In-Reply-To: <200909102302.26318.doconnor@gsoft.com.au>
References: <20090906155154.GA8283@onelab2.iet.unipi.it>
	<20090909203216.GA93761@onelab2.iet.unipi.it>
	<200909091642.06046.jhb@freebsd.org>
	<200909102302.26318.doconnor@gsoft.com.au>
Message-ID: <20090910135644.GA6109@onelab2.iet.unipi.it>

On Thu, Sep 10, 2009 at 11:02:19PM +0930, Daniel O'Connor wrote:
> On Thu, 10 Sep 2009, John Baldwin wrote:
> > > $ARCH/isa/clock.c::DELAY(). I suppose with a few measurements
> > > at different HZ values and some back of the envelope calculations
> > > one could even determine estimate the frequency and duration
> > > of those SMI interrupts!
> >
> > On recent motherboards I have seen the SMI# interrupt fire every 250
> > ms with execution times ranging from 50 us to 1ms for the legacy USB
> > interrupt handler.  We consistently see the TSC frequency
> > miscalculated on the motherboards with the 1ms duration interrupt.  I
> > suspect that the clock that drives the periodic SMI# interrupt is
> > tied to the i8254 meaning that it often fires at the same time that
> > the i8254 wraps causing the TSC frequency to often be wrong.
> 
> Can the calculation code disable the SMI# interrupt? Disabling legacy 
> USB could be a problem if you want to use a USB keyboard with the 
> loader (I think).

surely I don't think disabling these interrupts is a viable option.

Perhaps the best we can do in the calibration loop is alternate reads
of the tsc and the i8254 counter (getit()), and if we see too many ticks
between two subsequent calls to getit() it means that we have been
interrupted and should discard the last measurement interval.
Problem is, right now the calibration loop is

	start = rdtsc(); DELAY(1000000); b = rdtsc;

and DELAY is unaware of the existence of the TSC.
We should write some custom DELAY() code to implement the
calibration as above.

	cheers
	luigi
From sagara at tomahawk.com.sg  Thu Sep 10 14:37:57 2009
From: sagara at tomahawk.com.sg (Sagara Wijetunga)
Date: Thu Sep 10 14:38:04 2009
Subject: Avahi compilation help needed
In-Reply-To: <4AA8EC4D.3080800@andric.com>
References: <4AA8EBBD.5020709@tomahawk.com.sg> <4AA8EC4D.3080800@andric.com>
Message-ID: <4AA90F9F.6080702@tomahawk.com.sg>

Dimitry Andric wrote:
> On 2009-09-10 14:06, Sagara Wijetunga wrote:
>   
>> I'm trying to compile Avahi-0.6.25 (http://avahi.org/) on FreeBSD 7.2 
>> (i386) [in fact, on Tomahawk Desktop]. It develops compilation errors. 
>>     
>
> Any reason why you don't use the net/avahi port instead?  This will save
> you most compilation and installation headaches.  
>   
Tomahawk Desktop uses FreeBSD sources, it is not based on the FreeBSD distribution. It doesn't have a port system. Tomahawk Desktop is designed everything to be installed simply by "./configure, [g]make, [g]make install" which FreeBSD is not designed to support. In Tomahawk Desktop, anything you compile and install, can be cleanly uninstalled without any file left out, which is not possible in FreeBSD. Here "compile and install" means you take a package, unpack, make and make install, that's it. You don't have wait until somebody prepare a port for you.

Coming back to our problem, Avahi get compile errors on FreeBSD when its original build system is used. We need a help. Appreciate if somebody could give it a try to just compile (ie. download the package, unpack, ./configure and gmake).

Kind regards
Sagara


From mamalos at eng.auth.gr  Thu Sep 10 14:41:36 2009
From: mamalos at eng.auth.gr (George Mamalakis)
Date: Thu Sep 10 14:41:43 2009
Subject: FreeBSD 8.0-BETA4 IBM ServerRaid 8k issues 
Message-ID: <4AA90D88.4010004@eng.auth.gr>

Hello everybody,

Yesterday I installed FreeBSD 8.0-BETA4 on an IBM 3650, having a 
ServerRaid 8k adapter, and 6 sata disks on raid-6. The raid-6 volume was 
"synchronizing" for a day, so this syncing process was happening while I 
was installing fbsd on the server. During the installation I was 
understanding that (writing) performance was low, but this was rational, 
considering the fact that the raid controller had to synchronize its 
disks. After the system got installed, and while the controller was 
still syncing, I ran "portsnap fetch extract" to get the latest ports. 
During this process, all my terminals kept lagging when I was opening 
files, browsing directories, etc, and the following kernel message 
appeared in dmesg:

lock order reversal:
 1st 0xffffff807c133540 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2559
 2nd 0xffffff0003deb200 dirhash (dirhash) @ 
/usr/src/sys/ufs/ufs/ufs_dirhash.c:285
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2a
_witness_debugger() at _witness_debugger+0x2e
witness_checkorder() at witness_checkorder+0x81e
_sx_xlock() at _sx_xlock+0x55
ufsdirhash_acquire() at ufsdirhash_acquire+0x33
ufsdirhash_add() at ufsdirhash_add+0x19
ufs_direnter() at ufs_direnter+0x88b
ufs_makeinode() at ufs_makeinode+0x2a7
VOP_CREATE_APV() at VOP_CREATE_APV+0x8d
vn_open_cred() at vn_open_cred+0x468
kern_openat() at kern_openat+0x179
syscall() at syscall+0x1af
Xfast_syscall() at Xfast_syscall+0xe1
--- syscall (5, FreeBSD ELF64, open), rip = 0x800e32dfc, rsp = 
0x7fffffffe688, rbp = 0x1a4 ---
lock order reversal:
 1st 0xffffff00352cbd80 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2083
 2nd 0xffffff807c133540 bufwait (bufwait) @ 
/usr/src/sys/ufs/ffs/ffs_softdep.c:6177
 3rd 0xffffff00352cbba8 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2083
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2a
_witness_debugger() at _witness_debugger+0x2e
witness_checkorder() at witness_checkorder+0x81e
__lockmgr_args() at __lockmgr_args+0xcf3
ffs_lock() at ffs_lock+0x8c
VOP_LOCK1_APV() at VOP_LOCK1_APV+0x9b
_vn_lock() at _vn_lock+0x47
vget() at vget+0x7b
vfs_hash_get() at vfs_hash_get+0xd5
ffs_vgetf() at ffs_vgetf+0x48
softdep_sync_metadata() at softdep_sync_metadata+0x456
ffs_syncvnode() at ffs_syncvnode+0x210
ffs_fsync() at ffs_fsync+0x43
ufs_direnter() at ufs_direnter+0x315
ufs_makeinode() at ufs_makeinode+0x2a7
VOP_CREATE_APV() at VOP_CREATE_APV+0x8d
vn_open_cred() at vn_open_cred+0x468
kern_openat() at kern_openat+0x179
syscall() at syscall+0x1af
Xfast_syscall() at Xfast_syscall+0xe1
--- syscall (5, FreeBSD ELF64, open), rip = 0x800e32dfc, rsp = 
0x7fffffffe688, rbp = 0x1a4 ---
aac0: COMMAND 0xffffff80003e08a0 TIMEOUT AFTER 40 SECONDS
aac0: COMMAND 0xffffff80003d5070 TIMEOUT AFTER 40 SECONDS
aac0: COMMAND 0xffffff80003e0d00 TIMEOUT AFTER 40 SECONDS
aac0: COMMAND 0xffffff80003d9440 TIMEOUT AFTER 40 SECONDS
....

...and kept on like that, for many many lines, with decreasing timeouts. 
Once the syncing process stopped, everything came back to normal (not 
that I have stress-tested the machine, to be honest...). But since it 
happened once, during this specific procedure, then maybe it could also 
happen when the raid controller is reconstructing its volumes; and this 
would be very annoying, as far as the server's efficiency (and/or maybe 
stability) is concerned.

The kernel is GENERIC-amd64 and untouched, if someone may need more 
information (eg, dmesg output) please do not hesitate to say so.

Thank you all for your time in advance,

mamalos

-- 
George Mamalakis

IT Officer
Electrical and Computer Engineer (Aristotle Un. of Thessaloniki),
MSc (Imperial College of London)

Department of Electrical and Computer Engineering
Faculty of Engineering
Aristotle University of Thessaloniki

phone number : +30 (2310) 994379

From dimitry at andric.com  Thu Sep 10 14:46:56 2009
From: dimitry at andric.com (Dimitry Andric)
Date: Thu Sep 10 14:47:03 2009
Subject: Avahi compilation help needed
In-Reply-To: <4AA90F9F.6080702@tomahawk.com.sg>
References: <4AA8EBBD.5020709@tomahawk.com.sg> <4AA8EC4D.3080800@andric.com>
	<4AA90F9F.6080702@tomahawk.com.sg>
Message-ID: <4AA91160.40207@andric.com>

On 2009-09-10 16:39, Sagara Wijetunga wrote:
> Tomahawk Desktop uses FreeBSD sources, it is not based on the FreeBSD distribution.

Please contact the Tomahawk Desktop mailing lists then. :)
From ivoras at freebsd.org  Thu Sep 10 14:51:49 2009
From: ivoras at freebsd.org (Ivan Voras)
Date: Thu Sep 10 14:51:57 2009
Subject: FreeBSD 8.0-BETA4 IBM ServerRaid 8k issues
In-Reply-To: <4AA90D88.4010004@eng.auth.gr>
References: <4AA90D88.4010004@eng.auth.gr>
Message-ID: <h8b3p3$h2t$1@ger.gmane.org>

George Mamalakis wrote:
> Hello everybody,
> 
> Yesterday I installed FreeBSD 8.0-BETA4 on an IBM 3650, having a 

3650 M1 or M2?

> ServerRaid 8k adapter, and 6 sata disks on raid-6. The raid-6 volume was 
> "synchronizing" for a day, so this syncing process was happening while I 
> was installing fbsd on the server. During the installation I was 

I can give you only some generic information.

> lock order reversal:
> 1st 0xffffff807c133540 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2559
> 2nd 0xffffff0003deb200 dirhash (dirhash) @ 
> /usr/src/sys/ufs/ufs/ufs_dirhash.c:285

You have received this message because you are running a debug kernel; a 
normal kernel with debugging disabled would not have shown it.

By the fact that you did received it and the system managed to recover 
from it it is likely that the issue is harmless. It's likely related to 
the following timeouts.

> aac0: COMMAND 0xffffff80003e08a0 TIMEOUT AFTER 40 SECONDS
> aac0: COMMAND 0xffffff80003d5070 TIMEOUT AFTER 40 SECONDS
> aac0: COMMAND 0xffffff80003e0d00 TIMEOUT AFTER 40 SECONDS
> aac0: COMMAND 0xffffff80003d9440 TIMEOUT AFTER 40 SECONDS
> ....
> 
> ...and kept on like that, for many many lines, with decreasing timeouts. 

It looks like the controller was too busy rebuilding to take any new 
requests. It is possible you have filled the controller's write cache 
and that is why the lag happened at this point. You can easily test this 
theory.

> Once the syncing process stopped, everything came back to normal (not 
> that I have stress-tested the machine, to be honest...). But since it 
> happened once, during this specific procedure, then maybe it could also 
> happen when the raid controller is reconstructing its volumes; and this 
> would be very annoying, as far as the server's efficiency (and/or maybe 
> stability) is concerned.

Yes, you are right. But if the controller is the issue here, there is 
not much you can do about it. If it has a "priority" setting between 
normal usage and rebuilding/resyncing you might alter it to favour 
normal usage.

Initial rebuild of RAID 5/6 is also a bit specific as it touches all 
drives and, in some instances (don't know specifically about ServeRAID), 
it means all drives are rewritten in their entirety.

If you determine rebuild/resync is problematic, you might consider using 
a RAID mode that doesn't require it to be so extensive, like RAID 10 
with 4+ drives, or software RAID with ZFS.

From sagara at tomahawk.com.sg  Thu Sep 10 14:52:45 2009
From: sagara at tomahawk.com.sg (Sagara Wijetunga)
Date: Thu Sep 10 14:52:52 2009
Subject: Avahi compilation help needed
In-Reply-To: <4AA91160.40207@andric.com>
References: <4AA8EBBD.5020709@tomahawk.com.sg> <4AA8EC4D.3080800@andric.com>
	<4AA90F9F.6080702@tomahawk.com.sg> <4AA91160.40207@andric.com>
Message-ID: <4AA91318.50908@tomahawk.com.sg>

Dimitry Andric wrote:
> On 2009-09-10 16:39, Sagara Wijetunga wrote:
>   
>> Tomahawk Desktop uses FreeBSD sources, it is not based on the FreeBSD distribution.
>>     
>
> Please contact the Tomahawk Desktop mailing lists then. :)
>   
We are Tomahawk Desktop :)

From jhb at freebsd.org  Thu Sep 10 15:35:14 2009
From: jhb at freebsd.org (John Baldwin)
Date: Thu Sep 10 15:35:22 2009
Subject: Avahi compilation help needed
In-Reply-To: <4AA90F9F.6080702@tomahawk.com.sg>
References: <4AA8EBBD.5020709@tomahawk.com.sg> <4AA8EC4D.3080800@andric.com>
	<4AA90F9F.6080702@tomahawk.com.sg>
Message-ID: <200909101132.43781.jhb@freebsd.org>

On Thursday 10 September 2009 10:39:27 am Sagara Wijetunga wrote:
> Dimitry Andric wrote:
> > On 2009-09-10 14:06, Sagara Wijetunga wrote:
> >   
> >> I'm trying to compile Avahi-0.6.25 (http://avahi.org/) on FreeBSD 7.2 
> >> (i386) [in fact, on Tomahawk Desktop]. It develops compilation errors. 
> >>     
> >
> > Any reason why you don't use the net/avahi port instead?  This will save
> > you most compilation and installation headaches.  
> >   
> Tomahawk Desktop uses FreeBSD sources, it is not based on the FreeBSD 
distribution. It doesn't have a port system. Tomahawk Desktop is designed 
everything to be installed simply by "./configure, [g]make, [g]make install" 
which FreeBSD is not designed to support. In Tomahawk Desktop, anything you 
compile and install, can be cleanly uninstalled without any file left out, 
which is not possible in FreeBSD. Here "compile and install" means you take a 
package, unpack, make and make install, that's it. You don't have wait until 
somebody prepare a port for you.
> 
> Coming back to our problem, Avahi get compile errors on FreeBSD when its 
original build system is used. We need a help. Appreciate if somebody could 
give it a try to just compile (ie. download the package, unpack, ./configure 
and gmake).

The avahi ports can still be useful to look at as they contain patches that 
you will probably need.  For example, net/avahi-app has a patch against the 
configure script in files/patch-configure.  In total it seems that 
net/avahi-app has 21 different patches to the avahi sources (you may not need 
all of them however).  I would start by looking at those.

-- 
John Baldwin
From rsmith at xs4all.nl  Thu Sep 10 15:37:33 2009
From: rsmith at xs4all.nl (Roland Smith)
Date: Thu Sep 10 15:37:47 2009
Subject: Avahi compilation help needed
In-Reply-To: <4AA90F9F.6080702@tomahawk.com.sg>
References: <4AA8EBBD.5020709@tomahawk.com.sg> <4AA8EC4D.3080800@andric.com>
	<4AA90F9F.6080702@tomahawk.com.sg>
Message-ID: <20090910153729.GB30059@slackbox.xs4all.nl>

On Thu, Sep 10, 2009 at 10:39:27PM +0800, Sagara Wijetunga wrote:
> Dimitry Andric wrote:
> > On 2009-09-10 14:06, Sagara Wijetunga wrote:
> >   
> >> I'm trying to compile Avahi-0.6.25 (http://avahi.org/) on FreeBSD 7.2 
> >> (i386) [in fact, on Tomahawk Desktop]. It develops compilation errors. 
> >>     
> >
> > Any reason why you don't use the net/avahi port instead?  This will save
> > you most compilation and installation headaches.  

My thoughts exactly. 

> Tomahawk Desktop uses FreeBSD sources, it is not based on the FreeBSD
> distribution. 

What does that mean? The FreeBSD sources by default make a complete _base_
distribution.

> It doesn't have a port system. Tomahawk Desktop is designed
> everything to be installed simply by "./configure, [g]make, [g]make install"
> which FreeBSD is not designed to support. 

This is demonstrable not correct. The FreeBSD ports system _does_ use
configure and friends when available in the source of the package. E.g, every
port that has 'GNU_CONFIGURE= yes' in its Makefile uses it. The ports system
is nothing more than a wrapper to allow unmodified sources to be built on
FreeBSD.

> In Tomahawk Desktop, anything you compile and install, can be cleanly
> uninstalled without any file left out, which is not possible in FreeBSD.

Again this is demonstrable false. There are plenty of ports that deinstall
cleanly. One of my own ports, graphics/stl2pov, for example. If what you are
saying were true, it would come as a suprise to many ports developers. Sure,
there are ports with incorrect packing lists which leave files behind, but
usually that is not a big problem. 

And the ports system (correctly, IMO) will not delete files that have been
modified and non-empty directories; a ports system should _never_ delete any of
the users' files.

> Here "compile and install" means you take a package, unpack, make and make
> install, that's it. You don't have wait until somebody prepare a port for
> you.

But you do have to wait until somebody sorts out the compile problems... Which
amount to the same thing. And which can be a royal PITA as you are dicovering.
:-)

IMHO, what you are doing is effectively a huge duplication of effort. I would
advise you to switch over to the ports system and save yourself a lot of
work. If you require applications that are currently not in ports, it is
easier to submit and maintain a few ports than a complete system.

> Coming back to our problem, Avahi get compile errors on FreeBSD when its
> original build system is used. We need a help. Appreciate if somebody could
> give it a try to just compile (ie. download the package, unpack, ./configure
> and gmake).

Avahi needs patches to work properly on FreeBSD. See e.g. the files/ directory
in the net/avahi-app port. Applying those patches should solve most of your
problem.

Roland
-- 
R.F.Smith                                   http://www.xs4all.nl/~rsmith/
[plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated]
pgp: 1A2B 477F 9970 BA3C 2914  B7CE 1277 EFB0 C321 A725 (KeyID: C321A725)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090910/876c260a/attachment.pgp
From ivoras at freebsd.org  Thu Sep 10 16:06:33 2009
From: ivoras at freebsd.org (Ivan Voras)
Date: Thu Sep 10 16:06:40 2009
Subject: svn commit: r197065 - in stable/8: etc/defaults lib/libc/stdlib
	sys/amd64/conf sys/i386/conf sys/ia64/conf sys/pc98/conf
	sys/powerpc/conf sys/sparc64/conf
In-Reply-To: <1252595839.75144.26.camel@bauer.cse.buffalo.edu>
References: <200909101404.n8AE41C6021588@svn.freebsd.org>
	<1252592951.49151.3.camel@buffy.york.ac.uk> 
	<1252595839.75144.26.camel@bauer.cse.buffalo.edu>
Message-ID: <9bbcef730909100836l3835825cy83082a2cfe4da0c3@mail.gmail.com>

2009/9/10 Ken Smith <kensmith@cse.buffalo.edu>:
> On Thu, 2009-09-10 at 15:29 +0100, Gavin Atkinson wrote:

>> This seems like a step backwards to me: crash dumps have been left
>> enabled in 7.x and have proved very useful from the point of view of
>> improved quality of received PRs. ?I'm not aware of any problems
>> relating to leaving them enabled.
>>
>> I'd appreciate it if this decision was reconsidered.
>>
>
> Unfortunately as I said before there is no "Right answer" for this one.

No, but there is an "80% right" one, based on the question: did the
change in 7 cause known problems for any significant number of users
(or one of two big users - that should be enough).

After all, if users were fine with crashdumps & symbols being enabled
in 7, they should be find with them being enabled in 8.

> If there is (a lot) more push-back on this we'll reconsider it.  But the
> AUTO setting is only appropriate for machines that are "actively being
> watched over".  In -stable branches we start to have people using it for
> large data centers full of machines that are only "partially watched
> over" at best as well as machines stuffed in phone closets in remote
> locations, etc.  Having the AUTO setting for situations like that can
> mean increased time for a reboot to happen, there is extra risk of the
> machine wedging and not rebooting at all (requiring manual intervention
> to get it back up), there is risk of disk space issues, etc.
From jkim at FreeBSD.org  Thu Sep 10 16:16:09 2009
From: jkim at FreeBSD.org (Jung-uk Kim)
Date: Thu Sep 10 16:16:16 2009
Subject: Detecting CPU throttling on over temperature
In-Reply-To: <20090910133741.GA6000@onelab2.iet.unipi.it>
References: <1252426982.00160755.1252414203@10.7.7.3>
	<20090910132107.GH48206@home.opsec.eu>
	<20090910133741.GA6000@onelab2.iet.unipi.it>
Message-ID: <200909101216.01423.jkim@FreeBSD.org>

On Thursday 10 September 2009 09:37 am, Luigi Rizzo wrote:
> On Thu, Sep 10, 2009 at 03:21:07PM +0200, Kurt Jaeger wrote:
> > Hi!
> >
> > > > I thought coretemp had be modified in HEAD to support Phenoms
> > > > but I can't find any evidence of that in SVN so I am not sure
> > > > what I am thinking..
> > >
> > > How about 'k8temp'?
> >
> > /usr/ports/sysutils/k8temp
> >
> > This works, very nice!
>
> note though that the numbers you get seem way off reality:
>
> bsd7# k8temp
> CPU 0 Core 0 Sensor 0: 13c
> CPU 0 Core 0 Sensor 1: 13c
> CPU 0 Core 1 Sensor 0: 16c
> CPU 0 Core 1 Sensor 1: 3c
>
> (they do increase with CPU load).

I bet this is a Family 0Fh Revision G processor.  In fact, I 
(accidently) found the problem and wrote the attached patch for 
amdtemp(4) last night. :-)

Jung-uk Kim
-------------- next part --------------
--- sys/dev/amdtemp/amdtemp.c.orig	2009-08-20 15:43:50.000000000 -0400
+++ sys/dev/amdtemp/amdtemp.c	2009-09-09 18:44:26.000000000 -0400
@@ -360,8 +360,13 @@ amdtemp_gettemp0f(device_t dev, amdsenso
 	}
 	pci_write_config(dev, AMDTEMP_REG0F, cfg, 1);
 	temp = pci_read_config(dev, AMDTEMP_REG0F, 4);
-	temp = ((temp >> 16) & 0xff) * 10 + AMDTEMP_OFFSET0F;
-	
+
+	/* Revision G has two more bits. */
+	if ((cpu_id & CPUID_EXT_MODEL) >= 0x60000)
+		temp = ((temp >> 14) & 0x3ff) * 10 / 4 + AMDTEMP_OFFSET;
+	else
+		temp = ((temp >> 16) & 0xff) * 10 + AMDTEMP_OFFSET;
+
 	return (temp);
 }
 
From mamalos at eng.auth.gr  Thu Sep 10 16:53:12 2009
From: mamalos at eng.auth.gr (George Mamalakis)
Date: Thu Sep 10 16:53:19 2009
Subject: FreeBSD 8.0-BETA4 IBM ServerRaid 8k issues
In-Reply-To: <h8b3p3$h2t$1@ger.gmane.org>
References: <4AA90D88.4010004@eng.auth.gr> <h8b3p3$h2t$1@ger.gmane.org>
Message-ID: <4AA92EF1.6010804@eng.auth.gr>

Ivan, thank you very much for answering; and now to your comments:
>
> 3650 M1 or M2?
>
On the box it writes x3650 (I forgot the initial 'x' before, sorry).

>
> You have received this message because you are running a debug kernel; 
> a normal kernel with debugging disabled would not have shown it.
>
So far, I understood :)

> It looks like the controller was too busy rebuilding to take any new 
> requests. It is possible you have filled the controller's write cache 
> and that is why the lag happened at this point. You can easily test 
> this theory.
>
This is the exact reason why I am asking this question. If this behavior 
is normal, then there is no problem with me. But I couldn't be sure 
whether it was a driver's problem or a controller's problem.
>
> If you determine rebuild/resync is problematic, you might consider 
> using a RAID mode that doesn't require it to be so extensive, like 
> RAID 10 with 4+ drives, or software RAID with ZFS.
>
I was thinking of using other raid modes, along with ZFS (although still 
labeled 'experimental', and this is going to be our department's main 
file server, so I still have my second thoughts about it...), since 
FreeBSD does not recognize my 2.8T volume during installation. This 
means that I 'll have to break it into more volumes in order for FreeBSD 
to see it.

Thank you for your answer again, and (now that you mentioned it:) ) in 
case anyone knows whether we'll be able to see partitions > 2T in the 
future (or now?!), please say how :).

-- 
George Mamalakis

IT Officer
Electrical and Computer Engineer (Aristotle Un. of Thessaloniki),
MSc (Imperial College of London)

Department of Electrical and Computer Engineering
Faculty of Engineering
Aristotle University of Thessaloniki

phone number : +30 (2310) 994379

From pluknet at gmail.com  Thu Sep 10 18:18:08 2009
From: pluknet at gmail.com (pluknet)
Date: Thu Sep 10 18:18:15 2009
Subject: FreeBSD 8.0-BETA4 IBM ServerRaid 8k issues
In-Reply-To: <4AA92EF1.6010804@eng.auth.gr>
References: <4AA90D88.4010004@eng.auth.gr> <h8b3p3$h2t$1@ger.gmane.org>
	<4AA92EF1.6010804@eng.auth.gr>
Message-ID: <a31046fc0909101118u6de8d07ey73e06b8f3abb496c@mail.gmail.com>

2009/9/10 George Mamalakis <mamalos@eng.auth.gr>:
[about aac0: COMMAND 0xffffff80003d9440 TIMEOUT AFTER 40 SECONDS]
>> It looks like the controller was too busy rebuilding to take any new
>> requests. It is possible you have filled the controller's write cache and
>> that is why the lag happened at this point. You can easily test this theory.
>>
> This is the exact reason why I am asking this question. If this behavior is
> normal, then there is no problem with me. But I couldn't be sure whether it
> was a driver's problem or a controller's problem.
>

I see it from time to time on a number of boxes. You can often ignore this.
It might be due to (and a symptom of) high disk workload.
Btw, there was a recent change to increase command timeout to 120s.

> Thank you for your answer again, and (now that you mentioned it:) ) in case
> anyone knows whether we'll be able to see partitions > 2T in the future (or
> now?!), please say how :).
>

Look at gpart(8).

-- 
wbr,
pluknet
From ivoras at freebsd.org  Thu Sep 10 18:39:51 2009
From: ivoras at freebsd.org (Ivan Voras)
Date: Thu Sep 10 18:39:57 2009
Subject: FreeBSD 8.0-BETA4 IBM ServerRaid 8k issues
In-Reply-To: <4AA92EF1.6010804@eng.auth.gr>
References: <4AA90D88.4010004@eng.auth.gr> <h8b3p3$h2t$1@ger.gmane.org> 
	<4AA92EF1.6010804@eng.auth.gr>
Message-ID: <9bbcef730909101111l2d3a4e31y4710175e19e3f870@mail.gmail.com>

2009/9/10 George Mamalakis <mamalos@eng.auth.gr>:

> Thank you for your answer again, and (now that you mentioned it:) ) in case
> anyone knows whether we'll be able to see partitions > 2T in the future (or
> now?!), please say how :).

Actually, FreeBSD can use arbitrary sized drives and partitions
(64-bit) but it's only the default partition scheme (bsdlabel) that
doesn't support it. Since bsdlabel is used by the default installer
(sysinstall), it means you can't install FreeBSD on such a setup,
which is recognized to be a Bad Thing. The solution is to use a modern
partitioning scheme like GPT (which has 64-bit limits) and then:

a) partition the drive/array from a Live CD and do a manual install of
FreeBSD from the installer CDs - which isn't as hard as it sounds,
since it involves basically two steps: installing the boot loaders and
unpacking the files or

b) install on a smaller drive (or volume if your controller supports
creating arbitrary volumes / partitions on top of RAID topology) and
use this drive/volume for the OS, and then partition and use the
larger array/volume for data.

In either case, once you manually partition the drive/volume with GPT,
you will encounter no further size limits.

A really kludgy workaround, which I don't think you should use, is to
create two partitions (I don't know if you could create more than two
2 TB partitions)  and then use gconcat to concatenate them into a
bigger "JBOD-style" software RAID device.
From jbozza at mindsites.com  Thu Sep 10 20:26:48 2009
From: jbozza at mindsites.com (Jaime Bozza)
Date: Thu Sep 10 20:27:21 2009
Subject: ZFS Boot/7.2-STABLE
Message-ID: <CF092998EA82AE4D83AF9C9ECA9A8BDE02E868F60A@ATLAS.msg.local>

After much work and looking at all the different configurations, I have a running 7.2-STABLE (amd64) system running ZFS only with no partitions.   Unfortunately, this required a couple of things.

First - The patch here: 
http://lists.freebsd.org/pipermail/freebsd-stable/2009-June/050518.html

(just the patch to nfs.c - the other one is already in the tree)

Next, I re-enabled ZFS support in /sys/boot/i386/Makefile

Finally, I rebuilt and installed libstand, then rebuilt and installed the boot loader.   Once I had those pieces, my ZFS-only system booted fine.  

I've read the problems that caused the ZFS support to be backed out.  Could ZFS Boot (loader) support be something optional that isn't a default?   This would allow those who want to use ZFS Boot the ability without needing to move to 8.0 (which still isn't out officially).

I'd have no problems rebuilding world to enable ZFS Boot on a new system, but currently I'd have to remember to re-patch libstand and the loader Makefile each time I updated, or move to 8.0, which I'm not quite ready to do.   

At the very least, can someone MFC the libstand patch?  The link above is basically the diff between 7.x and 8.x for the nfs.c file.

Jaime Bozza

From brooks at FreeBSD.org  Thu Sep 10 20:31:34 2009
From: brooks at FreeBSD.org (Brooks Davis)
Date: Thu Sep 10 20:31:47 2009
Subject: svn commit: r197065 - in stable/8: etc/defaults
	lib/libc/stdlib sys/amd64/conf sys/i386/conf sys/ia64/conf
	sys/pc98/conf sys/powerpc/conf sys/sparc64/conf
In-Reply-To: <9bbcef730909100836l3835825cy83082a2cfe4da0c3@mail.gmail.com>
References: <200909101404.n8AE41C6021588@svn.freebsd.org>
	<1252592951.49151.3.camel@buffy.york.ac.uk>
	<1252595839.75144.26.camel@bauer.cse.buffalo.edu>
	<9bbcef730909100836l3835825cy83082a2cfe4da0c3@mail.gmail.com>
Message-ID: <20090910203156.GA55545@lor.one-eyed-alien.net>

On Thu, Sep 10, 2009 at 05:36:56PM +0200, Ivan Voras wrote:
> 2009/9/10 Ken Smith <kensmith@cse.buffalo.edu>:
> > On Thu, 2009-09-10 at 15:29 +0100, Gavin Atkinson wrote:
> 
> >> This seems like a step backwards to me: crash dumps have been left
> >> enabled in 7.x and have proved very useful from the point of view of
> >> improved quality of received PRs. ??I'm not aware of any problems
> >> relating to leaving them enabled.
> >>
> >> I'd appreciate it if this decision was reconsidered.
> >>
> >
> > Unfortunately as I said before there is no "Right answer" for this one.
> 
> No, but there is an "80% right" one, based on the question: did the
> change in 7 cause known problems for any significant number of users
> (or one of two big users - that should be enough).

Given that we've shipped three releases with it this way we should have
an answer here.  If we can't identify real problem instances by now,
there probably aren't significant ones in practice.  IMO, we have always
gone too far in disabling debugging.

-- Brooks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090910/dcde8c79/attachment.pgp
From andrew at modulus.org  Fri Sep 11 00:23:48 2009
From: andrew at modulus.org (Andrew Snow)
Date: Fri Sep 11 00:23:56 2009
Subject: gconcat file system damage
In-Reply-To: <A8C66415-67AC-482D-B1DD-CBC155C4A41E@solfertje.student.utwente.nl>
References: <A8C66415-67AC-482D-B1DD-CBC155C4A41E@solfertje.student.utwente.nl>
Message-ID: <4AA99819.9000601@modulus.org>



How did you expand the filesystem onto the new volume?  UFS2 expansion 
is not supported.

> I originally created the concatted disk in two steps. First I created 
> the concat on my new mirrored disks and copied the files from my 
> existing mirror in there. Second I appended the existing mirror to my 
> concatted disk. It seemed to work fine, but now I'm seeing so much 
> errors that I can only mount the concat r/o!

From pldrouin at pldrouin.net  Fri Sep 11 01:14:55 2009
From: pldrouin at pldrouin.net (Pierre-Luc Drouin)
Date: Fri Sep 11 01:15:02 2009
Subject: How to enable CPU turbo mode on FreeBSD?
Message-ID: <4AA9A07C.4050200@pldrouin.net>

Hi,

I have an overclocked i7 920 CPU for which I have enabled Turbo Mode in 
the BIOS (21x multiplier). The base clock is set at 190 MHz, so the CPU 
frequency with Turbo mode activated should be 3990 MHz. However the 
maximum value FreeBSD amd64 shows for the CPU frequency in dmesg and 
sysctl is 3790 MHz. How can I enable the Turbo Mode?

CPU: Intel(R) Core(TM) i7 CPU         920  @ 2.67GHz (3790.52-MHz 
K8-class CPU)

machdep.acpi_timer_freq: 3579545
machdep.tsc_freq: 3790522507
machdep.i8254_freq: 1193182
dev.cpu.0.freq: 349
dev.cpu.0.freq_levels: 2793/130000 2443/113750 2094/97500 1745/81250 
1396/65000 1047/48750 698/32500 349/16250

Thanks!

From andrew at modulus.org  Fri Sep 11 01:25:08 2009
From: andrew at modulus.org (Andrew Snow)
Date: Fri Sep 11 01:25:15 2009
Subject: How to enable CPU turbo mode on FreeBSD?
In-Reply-To: <4AA9A07C.4050200@pldrouin.net>
References: <4AA9A07C.4050200@pldrouin.net>
Message-ID: <4AA9A67F.6060800@modulus.org>

Pierre-Luc Drouin wrote:

> I have an overclocked i7 920 CPU for which I have enabled Turbo Mode in 
> the BIOS (21x multiplier). The base clock is set at 190 MHz, so the CPU 
> frequency with Turbo mode activated should be 3990 MHz. However the 
> maximum value FreeBSD amd64 shows for the CPU frequency in dmesg and 
> sysctl is 3790 MHz. How can I enable the Turbo Mode?

The turbo mode doesn't show up in dmesg or sysctl, it dynamically 
overclocks inside the CPU.  Also, some motherboards silently disable 
turbo mode when you overclock the base clock.

You may need to use a benchmark running on 1 vs 4 cores to see if turbo 
mode is having any effect.

- Andrew
From peter at simons-rock.edu  Fri Sep 11 03:42:57 2009
From: peter at simons-rock.edu (Peter C. Lai)
Date: Fri Sep 11 03:43:04 2009
Subject: gconcat file system damage
In-Reply-To: <15274_1252628653_4AA998AD_15274_284_1_4AA99819.9000601@modulus.org>
References: <A8C66415-67AC-482D-B1DD-CBC155C4A41E@solfertje.student.utwente.nl>
	<15274_1252628653_4AA998AD_15274_284_1_4AA99819.9000601@modulus.org>
Message-ID: <20090911034253.GM81123@cesium.hyperfine.info>

What is the status of growfs(8) then?

On 2009-09-11 10:21:45AM +1000, Andrew Snow wrote:
> 
> 
> How did you expand the filesystem onto the new volume?  UFS2 expansion is 
> not supported.
> 
>> I originally created the concatted disk in two steps. First I created the 
>> concat on my new mirrored disks and copied the files from my existing 
>> mirror in there. Second I appended the existing mirror to my concatted 
>> disk. It seemed to work fine, but now I'm seeing so much errors that I can 
>> only mount the concat r/o!
> 
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"

-- 
===========================================================
Peter C. Lai                 | Bard College at Simon's Rock
Systems Administrator        | 84 Alford Rd.
Information Technology Svcs. | Gt. Barrington, MA 01230 USA
peter AT simons-rock.edu     | (413) 528-7428
===========================================================

From andrew at modulus.org  Fri Sep 11 03:47:04 2009
From: andrew at modulus.org (Andrew Snow)
Date: Fri Sep 11 03:47:12 2009
Subject: gconcat file system damage
In-Reply-To: <20090911034253.GM81123@cesium.hyperfine.info>
References: <A8C66415-67AC-482D-B1DD-CBC155C4A41E@solfertje.student.utwente.nl>
	<15274_1252628653_4AA998AD_15274_284_1_4AA99819.9000601@modulus.org>
	<20090911034253.GM81123@cesium.hyperfine.info>
Message-ID: <4AA9C7C3.1000007@modulus.org>

Peter C. Lai wrote:
> What is the status of growfs(8) then?

As far as I can tell, it doesn't work reliably with UFS2 partitions, and 
it doesn't work at all with large partitions.

People who do try to use it, can end up with corrupted filesystems... 
and the code is currently unmaintained.

- Andrew
From bruce at cran.org.uk  Fri Sep 11 07:01:24 2009
From: bruce at cran.org.uk (Bruce Cran)
Date: Fri Sep 11 07:01:30 2009
Subject: How to enable CPU turbo mode on FreeBSD?
In-Reply-To: <4AA9A07C.4050200@pldrouin.net>
References: <4AA9A07C.4050200@pldrouin.net>
Message-ID: <20090911074123.00006179@unknown>

On Thu, 10 Sep 2009 20:57:32 -0400
Pierre-Luc Drouin <pldrouin@pldrouin.net> wrote:

> Hi,
> 
> I have an overclocked i7 920 CPU for which I have enabled Turbo Mode
> in the BIOS (21x multiplier). The base clock is set at 190 MHz, so
> the CPU frequency with Turbo mode activated should be 3990 MHz.
> However the maximum value FreeBSD amd64 shows for the CPU frequency
> in dmesg and sysctl is 3790 MHz. How can I enable the Turbo Mode?
> 
> CPU: Intel(R) Core(TM) i7 CPU         920  @ 2.67GHz (3790.52-MHz 
> K8-class CPU)
> 
> machdep.acpi_timer_freq: 3579545
> machdep.tsc_freq: 3790522507
> machdep.i8254_freq: 1193182
> dev.cpu.0.freq: 349
> dev.cpu.0.freq_levels: 2793/130000 2443/113750 2094/97500 1745/81250 
> 1396/65000 1047/48750 698/32500 349/16250

You may be able to use the cpuctl kernel module with sysutils/x86info
to see when the CPUs are using Turbo mode. I haven't had any success
yet but I know in Windows the System control panel reported the 2.66GHz
CPU running at 2.83GHz without me doing anything, so I guess FreeBSD
should be doing the same.

-- 
Bruce Cran
From sagara at tomahawk.com.sg  Fri Sep 11 08:07:05 2009
From: sagara at tomahawk.com.sg (Sagara Wijetunga)
Date: Fri Sep 11 08:07:14 2009
Subject: Avahi compilation help needed
In-Reply-To: <200909101132.43781.jhb@freebsd.org>
References: <4AA8EBBD.5020709@tomahawk.com.sg> <4AA8EC4D.3080800@andric.com>
	<4AA90F9F.6080702@tomahawk.com.sg>
	<200909101132.43781.jhb@freebsd.org>
Message-ID: <4AAA0580.10400@tomahawk.com.sg>

John Baldwin wrote:
> The avahi ports can still be useful to look at as they contain patches that 
> you will probably need.  For example, net/avahi-app has a patch against the 
> configure script in files/patch-configure.  In total it seems that 
> net/avahi-app has 21 different patches to the avahi sources (you may not need 
> all of them however).  I would start by looking at those.
>   

Here is the procedure we tried:

    Create system users and groups to handle Avahi daemons:
    - Create "avahid" for running avahi-daemon
    - Create "avahi-autoipd" for running the avahi-autoipd daemon

    Get FreeBSD patches:
    mkdir files
    cd files
    cp -v /sources/avahi/* .
    cd ..

    tar xzf avahi-0.6.25.tar.gz
    cd avahi-0.6.25

    Apply FreeBSD patches:
    patch -Np0 -i ../files/patch-Makefile.in
    patch -Np0 -i ../files/patch-avahi-autoipd_main.c
    patch -Np0 -i ../files/patch-avahi-client.pc.in
    patch -Np0 -i ../files/patch-avahi-compat-howl.pc.in
    patch -Np0 -i ../files/patch-avahi-compat-libdns_sd.pc.in
    patch -Np0 -i ../files/patch-avahi-compat-libdns_sd_Makefile.in
    patch -Np0 -i ../files/patch-avahi-core.pc.in
    patch -Np0 -i ../files/patch-avahi-daemon_Makefile.in
    patch -Np0 -i ../files/patch-avahi-daemon_main.c
    patch -Np0 -i ../files/patch-avahi-discover-standalone_Makefile.in
    patch -Np0 -i ../files/patch-avahi-glib.pc.in
    patch -Np0 -i ../files/patch-avahi-qt4.pc.in
    patch -Np0 -i ../files/patch-avahi-qt_Makefile.in
    patch -Np0 -i ../files/patch-avahi-ui_Makefile.in
    patch -Np0 -i ../files/patch-avahi-utils_Makefile.in
    patch -Np0 -i ../files/patch-configure
    patch -Np0 -i ../files/patch-dnsconfd_Makefile.in
    patch -Np0 -i ../files/patch-initscript_freebsd_Makefile.in

    Check after patching for any rejection:
    find . -name "*.rej" -exec echo {} \;
    No rejections


    sed -i '' -e 's|-ldl||g ; s|netdev|network|g' \
                configure \
                avahi-client/Makefile.in \
                avahi-daemon/Makefile.in

    find . -name Makefile.in | /usr/bin/xargs \
                sed -i '' -e 's|(LIBINTL)|(INTLLIBS)|g ; 
s|(LIBICONV)|(LTLIBICONV)|g'

###        sed -i '' -e 's|%%RC_SUBR%%|${RC_SUBR}| ; \
                s|%%GNOME_SUBR%%|${GNOME_SUBR}|' \
                initscript/freebsd/avahi-dnsconfd.sh.in \
                initscript/freebsd/avahi-daemon.sh.in

    sed -i '' -e 's|dbus_connection_disconnect|dbus_connection_close|g' \
                avahi-client/client.c \
                avahi-daemon/dbus-protocol.c

    sed -i '' -e 's|^_||g' \
                avahi-ui/*.desktop.in.in

    sed -i '' -e 's|-lavahi-common||g' \
    avahi-qt/Makefile.in avahi-qt/Makefile


    CPPFLAGS="-DHAVE_KQUEUE" PTHREAD_CFLAGS="" PTHREAD_LIBS="-pthread" \
    ./configure --prefix=/usr --sysconfdir=/etc \
            --infodir=/usr/share/info --mandir=/usr/share/man 
--localstatedir=/var \
        --with-distro=freebsd --with-dbus-sys=/etc/dbus-1/system.d \
        
--with-dbus-system-socket=unix:path=/var/run/dbus/system_bus_socket \
        --with-avahi-user=avahid --with-avahi-group=avahid \
        --with-avahi-priv-access-group=network --enable-compat-libdns_sd \
        --disable-qt3 --disable-mono --disable-monodoc

    gmake >& avahi-make.log


We appreciate if someone could try and let us know.

Kind regards
Sagara

From dalroi at solfertje.student.utwente.nl  Fri Sep 11 08:57:26 2009
From: dalroi at solfertje.student.utwente.nl (Alban Hertroys)
Date: Fri Sep 11 08:57:32 2009
Subject: gconcat file system damage
In-Reply-To: <4AA9C7C3.1000007@modulus.org>
References: <A8C66415-67AC-482D-B1DD-CBC155C4A41E@solfertje.student.utwente.nl>
	<15274_1252628653_4AA998AD_15274_284_1_4AA99819.9000601@modulus.org>
	<20090911034253.GM81123@cesium.hyperfine.info>
	<4AA9C7C3.1000007@modulus.org>
Message-ID: <0853758B-4823-49B8-B63E-B5B72FE2661B@solfertje.student.utwente.nl>

On 11 Sep 2009, at 5:45, Andrew Snow wrote:

> Peter C. Lai wrote:
>> What is the status of growfs(8) then?
>
> As far as I can tell, it doesn't work reliably with UFS2 partitions,  
> and it doesn't work at all with large partitions.
>
> People who do try to use it, can end up with corrupted  
> filesystems... and the code is currently unmaintained.

Aha, I forgot about that step, but I did indeed use growfs to expand  
it. Is there any way to repair the corruption without erasing my data,  
or do I need to buy an external disk to backup to first (which I need  
for backups anyway)? If so, what's the pattern of the corruption? Is  
it likely to only start after a certain size?

Lastly, having a tool in the base system that causes these kinds of  
issues doesn't seem like a very good idea. growfs does issue a warning  
that made me read the bugs section in the man page. That section  
points to an ffsinfo command that I ran on the filesystem in question,  
but it appears to be alright:

===== START CYLINDER SUMMARY =====
# 0@28202000: 0. csum in fscs
ndir   int32_t 0x00000001
nbfree int32_t 0x00002474
nifree int32_t 0x00005bfd
nffree int32_t 0x0000000d
===== END CYLINDER SUMMARY =====

The filesystem is 740G, which seems to fit in the 'critical data  
structure'; 1480 < 0x2474...

Or is this a different (and undocumented) issue?

Alban Hertroys

--
Screwing up is the best way to attach something to the ceiling.


!DSPAM:74,4aaa10f412071914714074!


From shurd at sasktel.net  Fri Sep 11 09:24:00 2009
From: shurd at sasktel.net (Stephen Hurd)
Date: Fri Sep 11 09:24:08 2009
Subject: 8.0-B4 gstripe / GEOM_PART_* upgrade woes
Message-ID: <4AAA1296.2080705@sasktel.net>

I've upgraded from 7.2-RELEASE_p2 to 8.0-BETA4 and using GEOM_PART_* 
with my sliced gstripe array causes the /dev/stripe/raid0a to disappear 
and the reset of the /dev/stripe/raid0[a-z] file systems to be unmountable.

My gvinum array is still working fine and, after chasing the ad* slices, 
they can be mounted as well.  It's just the gstripe slices which are 
corrupt/missing.

When I build without GEOM_PART_* and use GEOM_BSD and GEOM_MBR, it works 
fine.

I've attached an archive with various command outputs which may be 
helpfull... the 8.0 directory is 8.0 with GEOM_PART_* and 8.0-OLD is 
using GEOM_BSD and GEOM_MBR.  I'll paste the 8.0 ones in here in case 
attachments are stripped:

=========== dmesg ==============
Copyright (c) 1992-2009 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
    The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 8.0-BETA4 #0: Thu Sep 10 17:00:11 PDT 2009
    admin@ace.hurd.local:/tmp/obj/usr/src/sys/ACE
Timecounter "i8254" frequency 1193182 Hz quality 0
CPU: Intel(R) Xeon(TM) CPU 2.40GHz (2394.77-MHz 686-class CPU)
  Origin = "GenuineIntel"  Id = 0xf27  Stepping = 7
  
Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
  Features2=0x4400<CNXT-ID,xTPR>
real memory  = 1342013440 (1279 MB)
avail memory = 1299419136 (1239 MB)
ACPI APIC Table: <IBM    SERONYXP>
FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
FreeBSD/SMP: 2 package(s) x 1 core(s) x 2 HTT threads
 cpu0 (BSP): APIC ID:  0
 cpu1 (AP/HT): APIC ID:  1
 cpu2 (AP): APIC ID:  6
 cpu3 (AP/HT): APIC ID:  7
MADT: Forcing active-low polarity and level trigger for SCI
ioapic2 <Version 1.1> irqs 32-47 on motherboard
ioapic1 <Version 1.1> irqs 16-31 on motherboard
ioapic0 <Version 1.1> irqs 0-15 on motherboard
kbd1 at kbdmux0
smbios0: <System Management BIOS> at iomem 0xfdfe0-0xfdffe on motherboard
smbios0: Version: 2.3, BCD Revision: 2.3
acpi0: <IBM SERONYXP> on motherboard
acpi0: [ITHREAD]
acpi0: Power Button (fixed)
acpi0: reservation of 460, 2 (4) failed
Timecounter "ACPI-safe" frequency 3579545 Hz quality 850
acpi_timer0: <32-bit timer at 3.579545MHz> port 0x488-0x48b on acpi0
pcib0: <ACPI Host-PCI bridge> on acpi0
pci0: <ACPI PCI bus> on pcib0
pcm0: <Creative CT5880-C> port 0x2200-0x223f irq 16 at device 1.0 on pci0
pcm0: <SigmaTel STAC9721/23 AC97 Codec>
pcm0: [ITHREAD]
pcm0: <Playback: DAC1,DAC2 / Record: ADC>
vgapci0: <VGA-compatible display> port 0x2300-0x23ff mem 
0xfd000000-0xfdffffff,0xfebff000-0xfebfffff irq 26 at device 9.0 on pci0
drm0: <Rage XL> on vgapci0
vgapci0: child drm0 requested pci_enable_busmaster
info: [drm] Initialized mach64 2.0.0 20060718
atapci0: <ServerWorks CSB5 UDMA100 controller> port 
0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x700-0x70f at device 15.1 on pci0
ata0: <ATA channel 0> on atapci0
ata0: [ITHREAD]
ata1: <ATA channel 1> on atapci0
ata1: [ITHREAD]
ohci0: <OHCI (generic) USB controller> mem 0xfebfe000-0xfebfefff irq 11 
at device 15.2 on pci0
ohci0: [ITHREAD]
usbus0: <OHCI (generic) USB controller> on ohci0
isab0: <PCI-ISA bridge> at device 15.3 on pci0
isa0: <ISA bus> on isab0
pcib1: <ACPI Host-PCI bridge> on acpi0
pci2: <ACPI PCI bus> on pcib1
bge0: <Broadcom NetXtreme Gigabit Ethernet Controller, ASIC rev. 0x1002> 
mem 0xfbff0000-0xfbffffff irq 29 at device 8.0 on pci2
miibus0: <MII bus> on bge0
brgphy0: <BCM5703 10/100/1000baseTX PHY> PHY 1 on miibus0
brgphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 
1000baseT-FDX, auto
bge0: Ethernet address: 00:02:55:07:57:03
bge0: [ITHREAD]
pcib2: <ACPI Host-PCI bridge> on acpi0
pci5: <ACPI PCI bus> on pcib2
mpt0: <LSILogic 1030 Ultra4 Adapter> port 0x2400-0x24ff mem 
0xf9ff0000-0xf9ffffff,0xf9fe0000-0xf9feffff irq 27 at device 7.0 on pci5
mpt0: [ITHREAD]
mpt0: MPI Version=1.2.15.0
mpt0: Capabilities: ( RAID-1 SAFTE )
mpt0: 0 Active Volumes (1 Max)
mpt0: 0 Hidden Drive Members (6 Max)
mpt1: <LSILogic 1030 Ultra4 Adapter> port 0x2500-0x25ff mem 
0xf9fd0000-0xf9fdffff,0xf9fc0000-0xf9fcffff irq 28 at device 7.1 on pci5
mpt1: [ITHREAD]
mpt1: MPI Version=1.2.15.0
mpt1: Capabilities: ( RAID-1 SAFTE )
mpt1: 0 Active Volumes (1 Max)
mpt1: 0 Hidden Drive Members (6 Max)
pcib3: <ACPI Host-PCI bridge> on acpi0
pci7: <ACPI PCI bus> on pcib3
pcib4: <ACPI Host-PCI bridge> on acpi0
pci9: <ACPI PCI bus> on pcib4
fdc0: <floppy drive controller> port 0x3f0-0x3f5 irq 6 drq 2 on acpi0
fdc0: [FILTER]
fd0: <1440-KB 3.5" drive> on fdc0 drive 0
atrtc0: <AT realtime clock> port 0x70-0x73 irq 8 on acpi0
cpu0: <ACPI CPU> on acpi0
p4tcc0: <CPU Frequency Thermal Control> on cpu0
cpu1: <ACPI CPU> on acpi0
p4tcc1: <CPU Frequency Thermal Control> on cpu1
cpu2: <ACPI CPU> on acpi0
p4tcc2: <CPU Frequency Thermal Control> on cpu2
cpu3: <ACPI CPU> on acpi0
p4tcc3: <CPU Frequency Thermal Control> on cpu3
pmtimer0 on isa0
orm0: <ISA Option ROM> at iomem 0xc0000-0xc7fff pnpid ORM0000 on isa0
sc0: <System console> at flags 0x100 on isa0
sc0: VGA <16 virtual consoles, flags=0x300>
vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0
atkbdc0: <Keyboard controller (i8042)> at port 0x60,0x64 on isa0
atkbd0: <AT Keyboard> irq 1 on atkbdc0
kbd0 at atkbd0
atkbd0: [GIANT-LOCKED]
atkbd0: [ITHREAD]
psm0: <PS/2 Mouse> irq 12 on atkbdc0
psm0: [GIANT-LOCKED]
psm0: [ITHREAD]
psm0: model IntelliMouse, device ID 3
ppc0: <Parallel port> at port 0x378-0x37f irq 7 on isa0
ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode
ppc0: FIFO with 16/16/8 bytes threshold
ppc0: [ITHREAD]
ppbus0: <Parallel port bus> on ppc0
lpt0: <Printer> on ppbus0
lpt0: [ITHREAD]
lpt0: Interrupt-driven port
Timecounters tick every 0.838 msec
ipfw2 (+ipv6) initialized, divert enabled, nat loadable, rule-based 
forwarding disabled, default to deny, logging disabled
Waiting 5 seconds for SCSI devices to settle
usbus0: 12Mbps Full Speed USB v1.0
driver bug: Unable to set devclass (devname: (null))
ad0: 305245MB <Seagate ST3320820A 3.AAE> at ata0-master UDMA100
ugen0.1: <(0x1166)> at usbus0
uhub0: <(0x1166) OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus0
acd0: CDRW <HL-DT-ST GCE-8520B/1.04> at ata0-slave UDMA33
uhub0: 4 ports with 4 removable, self powered
ugen0.2: <Canon> at usbus0
umass0: <Canon MX700 series, class 0/0, rev 2.00/1.02, addr 2> on usbus0
umass0:  SCSI over Bulk-Only; quirks = 0x0000
acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00
(probe0:mpt0:0:8:0): TEST UNIT READY. CDB: 0 0 0 0 0 0
(probe0:mpt0:0:8:0): CAM Status: SCSI Status Error
(probe0:mpt0:0:8:0): SCSI Status: Check Condition
(probe0:mpt0:0:8:0): UNIT ATTENTION asc:29,0
(probe0:mpt0:0:8:0): Power on, reset, or bus device reset occurred
(probe0:mpt0:0:8:0): Retrying Command (per Sense Data)
umass0:5:0:-1: Attached to scbus5
(probe2:umass-sim0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0
(probe2:umass-sim0:0:0:0): CAM Status: SCSI Status Error
(probe2:umass-sim0:0:0:0): SCSI Status: Check Condition
(probe2:umass-sim0:0:0:0): UNIT ATTENTION asc:29,0
(probe2:umass-sim0:0:0:0): Power on, reset, or bus device reset occurred
(probe2:umass-sim0:0:0:0): Retrying Command (per Sense Data)
(probe2:umass-sim0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0
(probe2:umass-sim0:0:0:0): CAM Status: SCSI Status Error
(probe2:umass-sim0:0:0:0): SCSI Status: Check Condition
(probe2:umass-sim0:0:0:0): NOT READY asc:3a,0
(probe2:umass-sim0:0:0:0): Medium not present
(probe2:umass-sim0:0:0:0): Unretryable error
cd0 at ata0 bus 0 target 1 lun 0
cd0: <HL-DT-ST CD-RW GCE-8520B 1.04> Removable CD-ROM SCSI-0 device
cd0: 33.000MB/s transfers
cd0: cd present [3315 x 2048 byte records]
ses0 at mpt0 bus 0 target 8 lun 0
ses0: <IBM 32P0042a S320  1 1> Fixed Processor SCSI-2 device
ses0: 3.300MB/s transfers
ses0: SAF-TE Compliant Device
da0 at mpt0 bus 0 target 0 lun 0
da0: <HP 36.4GB C 80-D94N D94N> Fixed Direct Access SCSI-2 device
da0: 160.000MB/s transfers (80.000MHz DT, offset 63, 16bit)
da0: Command Queueing enabled
da0: 34732MB (71132960 512 byte sectors: 255H 63S/T 4427C)
da1 at mpt0 bus 0 target 1 lun 0
da1: <HP 36.4GB C 80-D94N D94N> Fixed Direct Access SCSI-2 device
da1: 160.000MB/s transfers (80.000MHz DT, offset 63, 16bit)
da1: Command Queueing enabled
da1: 34732MB (71132960 512 byte sectors: 255H 63S/T 4427C)
da2 at mpt0 bus 0 target 2 lun 0
da2: <HP 36.4GB C 80-8C34 8C34> Fixed Direct Access SCSI-2 device
da2: 160.000MB/s transfers (80.000MHz DT, offset 63, 16bit)
da2: Command Queueing enabled
da2: 34732MB (71132960 512 byte sectors: 255H 63S/T 4427C)
da3 at mpt0 bus 0 target 3 lun 0
da3: <HP 36.4G ST336704LC HP02> Fixed Direct Access SCSI-2 device
da3: 160.000MB/s transfers (80.000MHz DT, offset 63, 16bit)
da3: Command Queueing enabled
da3: 34732MB (71132960 512 byte sectors: 255H 63S/T 4427C)
SMP: AP CPU #1 Launched!
SMP: AP CPU #3 Launched!
da4 at umass-sim0 bus 0 target 0 lun 0
da4: <Canon MX700 series 1020> Removable Direct Access SCSI-2 device
da4: 1.000MB/s transfers
da4: Attempt to query device size failed: NOT READY, Medium not 
presentSMP: AP CPU #2 Launched!

GEOM: ad0: geometry does not match label (255h,63s != 16h,63s).
acd0: FAILURE - READ_BIG ILLEGAL REQUEST asc=0x64 ascq=0x00
acd0: FAILURE - READ_BIG ILLEGAL REQUEST asc=0x64 ascq=0x00
GEOM_STRIPE: Device raid0 created (id=40432321).
GEOM_STRIPE: Disk da0s2 attached to raid0.
GEOM_STRIPE: Disk da1s2 attached to raid0.
GEOM_STRIPE: Disk da2s2 attached to raid0.
GEOM_STRIPE: Disk da3s2 attached to raid0.
GEOM_STRIPE: Device raid0 activated.
Trying to mount root from ufs:/dev/da0s1a
<<111188>C>aCna'tn 'stta ts t/atd e/vd/aedv0s/1sgt:ri pNeo/ rsuacidh0 
af:i lNeo  sour directory
c
=========== END OF dmesg ===========

=========== gstripe list ===========
Geom name: raid0
State: UP
Status: Total=4, Online=4
Type: AUTOMATIC
Stripesize: 262144
ID: 40432321
Providers:
1. Name: stripe/raid0
   Mediasize: 42934992896 (40G)
   Sectorsize: 512
   Mode: r0w0e0
Consumers:
1. Name: da0s2
   Mediasize: 10733990400 (10G)
   Sectorsize: 512
   Mode: r0w0e0
   Number: 0
2. Name: da1s2
   Mediasize: 10733990400 (10G)
   Sectorsize: 512
   Mode: r0w0e0
   Number: 1
3. Name: da2s2
   Mediasize: 10733990400 (10G)
   Sectorsize: 512
   Mode: r0w0e0
   Number: 2
4. Name: da3s2
   Mediasize: 10733990400 (10G)
   Sectorsize: 512
   Mode: r0w0e0
   Number: 3
=========== END OF gstripe list ===========

=========== gstripe status ===========
        Name  Status  Components
stripe/raid0      UP  da0s2
                      da1s2
                      da2s2
                      da3s2
=========== END OF gstripe status ===========

From ivoras at freebsd.org  Fri Sep 11 10:21:49 2009
From: ivoras at freebsd.org (Ivan Voras)
Date: Fri Sep 11 10:21:56 2009
Subject: 8.0-B4 gstripe / GEOM_PART_* upgrade woes
In-Reply-To: <4AAA1296.2080705@sasktel.net>
References: <4AAA1296.2080705@sasktel.net>
Message-ID: <h8d8b5$b3q$1@ger.gmane.org>

Stephen Hurd wrote:
> I've upgraded from 7.2-RELEASE_p2 to 8.0-BETA4 and using GEOM_PART_* 
> with my sliced gstripe array causes the /dev/stripe/raid0a to disappear 
> and the reset of the /dev/stripe/raid0[a-z] file systems to be unmountable.
> 
> My gvinum array is still working fine and, after chasing the ad* slices, 
> they can be mounted as well.  It's just the gstripe slices which are 
> corrupt/missing.

Ouch.

> GEOM_STRIPE: Device raid0 created (id=40432321).
> GEOM_STRIPE: Disk da0s2 attached to raid0.
> GEOM_STRIPE: Disk da1s2 attached to raid0.
> GEOM_STRIPE: Disk da2s2 attached to raid0.
> GEOM_STRIPE: Disk da3s2 attached to raid0.
> GEOM_STRIPE: Device raid0 activated.
> Trying to mount root from ufs:/dev/da0s1a
> <<111188>C>aCna'tn 'stta ts t/atd e/vd/aedv0s/1sgt:ri pNeo/ rsuacidh0 
> af:i lNeo  sour directory
> c
> =========== END OF dmesg ===========
> 
> =========== gstripe list ===========
> Geom name: raid0
> State: UP
> Status: Total=4, Online=4
> Type: AUTOMATIC
> Stripesize: 262144
> ID: 40432321
> Providers:
> 1. Name: stripe/raid0
>   Mediasize: 42934992896 (40G)
>   Sectorsize: 512
>   Mode: r0w0e0
> Consumers:
> 1. Name: da0s2
>   Mediasize: 10733990400 (10G)
>   Sectorsize: 512
>   Mode: r0w0e0
>   Number: 0
> 2. Name: da1s2
>   Mediasize: 10733990400 (10G)
>   Sectorsize: 512
>   Mode: r0w0e0
>   Number: 1
> 3. Name: da2s2
>   Mediasize: 10733990400 (10G)
>   Sectorsize: 512
>   Mode: r0w0e0
>   Number: 2
> 4. Name: da3s2
>   Mediasize: 10733990400 (10G)
>   Sectorsize: 512
>   Mode: r0w0e0
>   Number: 3
> =========== END OF gstripe list ===========
> 
> =========== gstripe status ===========
>        Name  Status  Components
> stripe/raid0      UP  da0s2
>                      da1s2
>                      da2s2
>                      da3s2
> =========== END OF gstripe status ===========

 > When I build without GEOM_PART_* and use GEOM_BSD and GEOM_MBR, it works
 > fine.

An interesting problem. I presume that in either case (gpart or 
GEOM_BSD/MBR) the output of "gstripe status" is the same? Only the 
interpretation of the partition tables is problematic?

What is the expected ("good") structure of the partitions/file systems? 
Do you have a single MBR partition and inside it multiple BSD 
partitions? What are their partition types?


From artis.caune at gmail.com  Fri Sep 11 13:25:21 2009
From: artis.caune at gmail.com (Artis Caune)
Date: Fri Sep 11 13:25:58 2009
Subject: FreeBSD 8.0-BETA4 IBM ServerRaid 8k issues
In-Reply-To: <4AA90D88.4010004@eng.auth.gr>
References: <4AA90D88.4010004@eng.auth.gr>
Message-ID: <9e20d71e0909110601kaa87f2em2e4e618b8feb306b@mail.gmail.com>

2009/9/10 George Mamalakis <mamalos@eng.auth.gr>:
> Hello everybody,
>
> Yesterday I installed FreeBSD 8.0-BETA4 on an IBM 3650, having a ServerRaid
> 8k adapter, and 6 sata disks on raid-6.
> ....
> aac0: COMMAND 0xffffff80003e08a0 TIMEOUT AFTER 40 SECONDS
> aac0: COMMAND 0xffffff80003d5070 TIMEOUT AFTER 40 SECONDS
> aac0: COMMAND 0xffffff80003e0d00 TIMEOUT AFTER 40 SECONDS
> aac0: COMMAND 0xffffff80003d9440 TIMEOUT AFTER 40 SECONDS
> ....
>
> ...and kept on like that, for many many lines, with decreasing timeouts.
> Once the syncing process stopped, everything came back to normal (not that I
> have stress-tested the machine, to be honest...). But since it happened
> once, during this specific procedure, then maybe it could also happen when
> the raid controller is reconstructing its volumes; and this would be very
> annoying, as far as the server's efficiency (and/or maybe stability) is
> concerned.

Same problem here, thought we got timeouts also on idle boxes.

IBM support told to switch controller channel speed from auto(3Gbps)
to 1.5Gbps and update ServeRaid firmware. We are currently running
5.2.0-15429 (flashing them almost monthly :) ). You can change speed
in raid bios, in Ctrl-A menu.
But this issue is only with sata disks, sas works perfectly.




-- 
Artis Caune

    Everything should be made as simple as possible, but not simpler.
From pldrouin at pldrouin.net  Fri Sep 11 15:05:32 2009
From: pldrouin at pldrouin.net (Pierre-Luc Drouin)
Date: Fri Sep 11 15:05:39 2009
Subject: How to enable CPU turbo mode on FreeBSD?
In-Reply-To: <20090911074123.00006179@unknown>
References: <4AA9A07C.4050200@pldrouin.net> <20090911074123.00006179@unknown>
Message-ID: <4AAA6755.7070502@pldrouin.net>

Bruce Cran wrote:
> On Thu, 10 Sep 2009 20:57:32 -0400
> Pierre-Luc Drouin <pldrouin@pldrouin.net> wrote:
>
>   
>> Hi,
>>
>> I have an overclocked i7 920 CPU for which I have enabled Turbo Mode
>> in the BIOS (21x multiplier). The base clock is set at 190 MHz, so
>> the CPU frequency with Turbo mode activated should be 3990 MHz.
>> However the maximum value FreeBSD amd64 shows for the CPU frequency
>> in dmesg and sysctl is 3790 MHz. How can I enable the Turbo Mode?
>>
>> CPU: Intel(R) Core(TM) i7 CPU         920  @ 2.67GHz (3790.52-MHz 
>> K8-class CPU)
>>
>> machdep.acpi_timer_freq: 3579545
>> machdep.tsc_freq: 3790522507
>> machdep.i8254_freq: 1193182
>> dev.cpu.0.freq: 349
>> dev.cpu.0.freq_levels: 2793/130000 2443/113750 2094/97500 1745/81250 
>> 1396/65000 1047/48750 698/32500 349/16250
>>     
>
> You may be able to use the cpuctl kernel module with sysutils/x86info
> to see when the CPUs are using Turbo mode. I haven't had any success
> yet but I know in Windows the System control panel reported the 2.66GHz
> CPU running at 2.83GHz without me doing anything, so I guess FreeBSD
> should be doing the same.
>
>   
So I managed to test that the Turbo Mode is working. Here is how I 
tested it, if it can be useful for other people in the future:

I wrote this very dumb program in C (compiled using gcc -lpthread -o 
test test.c):
#include <stdlib.h>
#include <pthread.h>
#include <stdio.h>

int main(int nargs, char* args[]);
void* floop(void* args);
long long int niters;

int main(int nargs, char* args[])
{
 int nthrs;
 int i;
 pthread_t *threads;
 --nargs;
 ++args;

 if(nargs!=2) {
   fprintf(stderr,"Usage: loop nthreads niters\n");
   return 1;
 }
 sscanf(args[0],"%i",&nthrs);
 sscanf(args[1],"%lli",&niters);

 printf("Number of threads: %i\n",nthrs);
 printf("Number of iterations: %lli\n",niters);

 threads=(pthread_t*)malloc(nthrs*sizeof(pthread_t));

 for(i=nthrs-1; i>=0; --i) pthread_create(threads+i,NULL,floop,NULL);

 for(i=nthrs-1; i>=0; --i) pthread_join(threads[i],NULL);

 free(threads);
 return 0;
}

void* floop(void* args){
 long long int i;
 for(i=niters-1; i>=0; --i);
 return NULL;
}

I ran it with 8 threads and 150 000 000 000 iterations/threads using
time ./test 8 150000000000

I got a user time of 1827.24 sec with turbo and 1908.69 sec without, a 
4.5% speed difference, which is pretty close to the expected 5% (1-21/20 
where 21/20 is the ratio of CPU multipliers with and without turbo for 
my i7 920 CPU)
From jhb at freebsd.org  Fri Sep 11 15:19:28 2009
From: jhb at freebsd.org (John Baldwin)
Date: Fri Sep 11 15:19:40 2009
Subject: How to enable CPU turbo mode on FreeBSD?
In-Reply-To: <4AA9A07C.4050200@pldrouin.net>
References: <4AA9A07C.4050200@pldrouin.net>
Message-ID: <200909111105.01619.jhb@freebsd.org>

On Thursday 10 September 2009 8:57:32 pm Pierre-Luc Drouin wrote:
> Hi,
> 
> I have an overclocked i7 920 CPU for which I have enabled Turbo Mode in 
> the BIOS (21x multiplier). The base clock is set at 190 MHz, so the CPU 
> frequency with Turbo mode activated should be 3990 MHz. However the 
> maximum value FreeBSD amd64 shows for the CPU frequency in dmesg and 
> sysctl is 3790 MHz. How can I enable the Turbo Mode?
> 
> CPU: Intel(R) Core(TM) i7 CPU         920  @ 2.67GHz (3790.52-MHz 
> K8-class CPU)
> 
> machdep.acpi_timer_freq: 3579545
> machdep.tsc_freq: 3790522507
> machdep.i8254_freq: 1193182
> dev.cpu.0.freq: 349
> dev.cpu.0.freq_levels: 2793/130000 2443/113750 2094/97500 1745/81250 
> 1396/65000 1047/48750 698/32500 349/16250

You have to enable C2/C3 sleep states (possibly in your BIOS).  However, 
FreeBSD doesn't currently handle this but so well since that will probably 
turn off the local APIC timer interrupt when the CPU is idle causing FreeBSD 
to miss clock interrupts.

-- 
John Baldwin
From doug at polands.org  Fri Sep 11 15:26:39 2009
From: doug at polands.org (Doug Poland)
Date: Fri Sep 11 15:26:46 2009
Subject: NFS issues on 8.0-BETA4
Message-ID: <9ef3bf09fa0e081eca3965e3f0e84f82.squirrel@email.polands.org>

Hello,

I have a 7.2-RELEASE(i386) server hosting NFSv3.  I've installed
8.0-BETA4(amd64) in a VMware 6.5 workstation virtual machine.

I cannot sucessfully mount exports from the NFSv3 server on the
8.0-BETA4 client.  All works well with 7.2 clients.

The strange thing is, the directory in which I mount the nfs
filesystem disappears, and I get an error when I attempt to access the
directory.


On working the server, I set these knobs in /etc/rc.conf:
mountd_flags="-l"
nfs_reserved_port_only="NO"
nfs_server_enable="YES"
nfs_server_flags="-u -n 6"
rpc_lockd_enable="YES"
rpc_statd_enable="YES"

On the client, I set these knobs in /etc/rc.conf:
nfs_client_enable="YES"
rpc_lockd_enable="YES"
rpc_statd_enable="YES"

client#  mount -t nfs -o
nfsv3,retrycnt=3,intr,soft,rsize=32768,wsize=32768 fs:/usr/ports
/usr/ports

I get a long delay (several seconds)

client# echo $?
0

client# ls /usr/ports
ls: /usr/ports: Permission denied

client#  echo $?
1

client# mount -t nfs
fs:/usr/ports on /usr/ports (nfs)


client# umount /usr/ports
client#  ls -ld /usr/ports
drwxr-xr-x  2 root  wheel  512 Sep 11 08:54 /usr/ports

If I simplify the mount command, I get a different error:
client# mount -t nfs fs:/usr/ports /usr/ports
mount: /usr/ports: Permission denied
client# echo $?
64

client# mount -t nfs
fs:/usr/ports on /usr/ports (nfs)


Any suggestions?


-- 
Regards,
Doug

From pldrouin at pldrouin.net  Fri Sep 11 15:45:49 2009
From: pldrouin at pldrouin.net (Pierre-Luc Drouin)
Date: Fri Sep 11 15:45:55 2009
Subject: How to enable CPU turbo mode on FreeBSD?
In-Reply-To: <200909111105.01619.jhb@freebsd.org>
References: <4AA9A07C.4050200@pldrouin.net>
	<200909111105.01619.jhb@freebsd.org>
Message-ID: <4AAA70C5.5090408@pldrouin.net>

John Baldwin wrote:
> On Thursday 10 September 2009 8:57:32 pm Pierre-Luc Drouin wrote:
>   
>> Hi,
>>
>> I have an overclocked i7 920 CPU for which I have enabled Turbo Mode in 
>> the BIOS (21x multiplier). The base clock is set at 190 MHz, so the CPU 
>> frequency with Turbo mode activated should be 3990 MHz. However the 
>> maximum value FreeBSD amd64 shows for the CPU frequency in dmesg and 
>> sysctl is 3790 MHz. How can I enable the Turbo Mode?
>>
>> CPU: Intel(R) Core(TM) i7 CPU         920  @ 2.67GHz (3790.52-MHz 
>> K8-class CPU)
>>
>> machdep.acpi_timer_freq: 3579545
>> machdep.tsc_freq: 3790522507
>> machdep.i8254_freq: 1193182
>> dev.cpu.0.freq: 349
>> dev.cpu.0.freq_levels: 2793/130000 2443/113750 2094/97500 1745/81250 
>> 1396/65000 1047/48750 698/32500 349/16250
>>     
>
> You have to enable C2/C3 sleep states (possibly in your BIOS).  However, 
> FreeBD doesn't currently handle this but so well since that will probably 
> turn off the local APIC timer interrupt when the CPU is idle causing FreeBSD 
> to miss clock interrupts.
>
>   
Sorry I am not sure exactly what you are referring to. Do you mean that 
I need to enable C2/C3 states in order to have the correct max CPU freq 
value displayed at boot time/in sysctl, or you mean that I need these 
states in order to be able to use the Turbo Mode at all? Right now in 
the BIOS I had the following features disabled to test the overclocking 
(I was following what is recommended to do for Windows users to run 
stress tests):

-Intel SpeedStep: Use this function to enable the Intel SpeedStep 
technology (EIST)
-CxE Function: This function allows you to select the lowest C state 
supported according as CPU and MB. The options are Auto, Disabled, C1, 
C1E, C3 and C6

Thanks!
From mamalos at eng.auth.gr  Fri Sep 11 16:00:33 2009
From: mamalos at eng.auth.gr (George Mamalakis)
Date: Fri Sep 11 16:00:41 2009
Subject: FreeBSD 8.0-BETA4 IBM ServerRaid 8k issues
In-Reply-To: <9e20d71e0909110601kaa87f2em2e4e618b8feb306b@mail.gmail.com>
References: <4AA90D88.4010004@eng.auth.gr>
	<9e20d71e0909110601kaa87f2em2e4e618b8feb306b@mail.gmail.com>
Message-ID: <4AAA741A.7040105@eng.auth.gr>

Artis, and the rest of the guys, thank you all for your answers.

Ivan, I was thinking of using one of the techniques you mention (create 
two volumes, install fbsd on one of them, and use GTP on the second 
drive), but I was wondering if there would be any "incompatibility" 
issues with tools like df, etc.

Artis, let me get to your comments now:

> Same problem here, thought we got timeouts also on idle boxes.
>
> IBM support told to switch controller channel speed from auto(3Gbps)
> to 1.5Gbps and update ServeRaid firmware. We are currently running
> 5.2.0-15429 (flashing them almost monthly :) ). You can change speed
> in raid bios, in Ctrl-A menu.
> But this issue is only with sata disks, sas works perfectly.
>
>   
In case I do this (since I only have sata drives), will I end up with 
degraded disk performance? Theoretically I assume not, since 1.5 Gbps is 
adequate for *each* disk (it calculates to something like ~178MBps); but 
have you tried it on your disks, and everything works OK since (along 
with performance)?

Thank you all again for your answers, you've been truly helpful!

-- 
George Mamalakis

IT Officer
Electrical and Computer Engineer (Aristotle Un. of Thessaloniki),
MSc (Imperial College of London)

Department of Electrical and Computer Engineering
Faculty of Engineering
Aristotle University of Thessaloniki

phone number : +30 (2310) 994379

From dalroi at solfertje.student.utwente.nl  Fri Sep 11 16:18:50 2009
From: dalroi at solfertje.student.utwente.nl (Alban Hertroys)
Date: Fri Sep 11 16:18:56 2009
Subject: Kernel panic in ulpt
Message-ID: <B41B0A0F-63D7-42DD-B095-504E8A572B34@solfertje.student.utwente.nl>

Hello,

I just got a kernel panic on a FreeBSD 7.2 STABLE after a print job  
finished on ulpt. The kgdb output (ran in script) is attached. I'll  
keep the vmcore around in case anyone needs more info. Shout if you  
need more info.



!DSPAM:363,4aaa786713781058220185!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kgdb.out
Type: application/octet-stream
Size: 3943 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090911/4cde7890/kgdb.obj
-------------- next part --------------



Alban Hertroys

--
Screwing up is the best way to attach something to the ceiling.



!DSPAM:363,4aaa786713781058220185!
From mamalos at eng.auth.gr  Fri Sep 11 16:36:08 2009
From: mamalos at eng.auth.gr (George Mamalakis)
Date: Fri Sep 11 16:36:15 2009
Subject: MSI GT 627 unsuccessful installation in 7-STABLE and 8-BETA4
Message-ID: <4AAA7C71.8070708@eng.auth.gr>

Dear all,

My question should maybe have be sent to some other fbsd list; if so, 
please someone instruct me where, and excuse me for my potential mistake.

Now to my question:

I just bought the MSI GT 627 Laptop, and I tried to install FreeBSD on 
it. First I tried with 8-BETA4 amd, then with 8-BETA4 i386, and lastly 
with 7.2 latest snapshot. All attempts have been unsuccessful, so I 
tried NetBSD 5.0.1 to see if it would install, and it did!

The kernel messages I got on all FOUR attempts (even in NetBSD, although 
it worked finally) was something like that (in the beginning) (NetBSD 
excerpt, since it is the only that booted, so I could copy-paste it from 
dmesg, but FreeBSD gave the exact same Error messages (a few numbers 
differ)):

Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005,
    2006, 2007, 2008, 2009
    The NetBSD Foundation, Inc.  All rights reserved.
Copyright (c) 1982, 1986, 1989, 1991, 1993
    The Regents of the University of California.  All rights reserved.

NetBSD 5.0.1 (GENERIC) #0: Thu Jul 30 00:08:07 UTC 2009
        
builds@b7.netbsd.org:/home/builds/ab/netbsd-5-0-1-RELEASE/amd64/200907292356Z-obj/home/builds/ab/netbsd-5-0-1-RELEASE/src/sys/arch/amd64/compile/GENERIC
total memory = 4095 MB
avail memory = 3954 MB
timecounter: Timecounters tick every 10.000 msec
timecounter: Timecounter "i8254" frequency 1193182 Hz quality 100
SMBIOS rev. 2.5 @ 0x9a400 (45 entries)
Micro-Star International GT627       (Ver 1.000)
mainbus0 (root)
cpu0 at mainbus0 apid 0: Intel 686-class, 2394MHz, id 0x1067a
cpu1 at mainbus0 apid 1: Intel 686-class, 2394MHz, id 0x1067a
cpu2 at mainbus0 apid 2: Intel 686-class, 2394MHz, id 0x1067a
cpu3 at mainbus0 apid 3: Intel 686-class, 2394MHz, id 0x1067a
ioapic0 at mainbus0 apid 4: pa 0xfec00000, version 20, 24 pins
acpi0 at mainbus0: Intel ACPICA 20080321
acpi0: X/RSDT: OemId <MSI_NB,MEGABOOK,20090407>, AslId <MSFT,00000097>
ACPI Error (evregion-0427): No handler for Region [EC__] 
(0xffff800007e20400) [EmbeddedControl] [20080321]
ACPI Error (exfldio-0390): Region EmbeddedControl(3) has no handler 
[20080321]
ACPI Error (psparse-0627): Method parse/execution failed 
[\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xffff800007e23760), AE_NOT_EXIST
ACPI Error (uteval-0306): Method execution failed 
[\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xffff800007e23760), AE_NOT_EXIST
acpi0: SCI interrupting at int 9
acpi0: fixed-feature power button present
timecounter: Timecounter "ACPI-Fast" frequency 3579545 Hz quality 1000
ACPI-Fast 24-bit timer
ACPI Error (evregion-0427): No handler for Region [EC__] 
(0xffff800007e20400) [EmbeddedControl] [20080321]
ACPI Error (exfldio-0390): Region EmbeddedControl(3) has no handler 
[20080321]
ACPI Error (psparse-0627): Method parse/execution failed 
[\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xffff800007e23760), AE_NOT_EXIST
ACPI Error (uteval-0306): Method execution failed 
[\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xffff800007e23760), AE_NOT_EXIST
WMI1 (pnp0c14) at acpi0 not configured
....

where fbsd differed, was somewhere after identifying ad4 (the disk, 
which is WDC WD5000BEVT-22ZAT0 01.01A1), where it stated:

acd0: FAILURE - READ_BIG MEDIUM ERROR asc=0x11 ascq=0x05
run_interrupt_driven_hooks: still waiting after 60 seconds for xpt_config
run_interrupt_driven_hooks: still waiting after 120 seconds for xpt_config

and after that it kept on repeating the last message, only increasing 
the seconds to wait, until nothing more happened.

Does anyone know if this is something that will be fixed soon? I guess 
it has to do with MSI's ACPI or something like that.

Thank you all for your interest.

Regards,

mamalos.

-- 
George Mamalakis

IT Officer
Electrical and Computer Engineer (Aristotle Un. of Thessaloniki),
MSc (Imperial College of London)

Department of Electrical and Computer Engineering
Faculty of Engineering
Aristotle University of Thessaloniki

phone number : +30 (2310) 994379

From shurd at sasktel.net  Fri Sep 11 17:27:33 2009
From: shurd at sasktel.net (Stephen Hurd)
Date: Fri Sep 11 17:27:40 2009
Subject: 8.0-B4 gstripe / GEOM_PART_* upgrade woes
In-Reply-To: <h8d8b5$b3q$1@ger.gmane.org>
References: <4AAA1296.2080705@sasktel.net> <h8d8b5$b3q$1@ger.gmane.org>
Message-ID: <4AAA8881.7000609@sasktel.net>

Ivan Voras wrote:
> An interesting problem. I presume that in either case (gpart or 
> GEOM_BSD/MBR) the output of "gstripe status" is the same? Only the 
> interpretation of the partition tables is problematic?

Yes, but the output of gstripe list is different in the mode lines... 
for GEOM_PART, the mode is r0w0e0 in all consumers and for GEOM_*, the 
mode is r3w3e5.

> What is the expected ("good") structure of the partitions/file 
> systems? Do you have a single MBR partition and inside it multiple BSD 
> partitions? What are their partition types?

Not sure the correct way to get the info, but the output of fdisk and 
bsdlabel follow:
==== START of fdisk ====
 > fdisk /dev/stripe/raid0
******* Working on device /dev/stripe/raid0 *******
parameters extracted from in-core disklabel are:
cylinders=5219 heads=255 sectors/track=63 (16065 blks/cyl)

Figures below won't work with BIOS for partitions not in cyl 1
parameters to be used for BIOS calculations are:
cylinders=5219 heads=255 sectors/track=63 (16065 blks/cyl)

Media sector size is 512
Warning: BIOS sector numbering starts with sector 1
Information from DOS bootblock is:
The data for partition 1 is:
<UNUSED>
The data for partition 2 is:
<UNUSED>
The data for partition 3 is:
<UNUSED>
The data for partition 4 is:
sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD)
    start 0, size 50000 (24 Meg), flag 80 (active)
        beg: cyl 0/ head 0/ sector 1;
        end: cyl 1023/ head 254/ sector 63
==== END OF fdisk ====

==== START OF bsdlabel ====
 > bsdlabel /dev/stripe/raid0
# /dev/stripe/raid0:
8 partitions:
#        size   offset    fstype   [fsize bsize bps/cpg]
  a: 16777216       16    4.2BSD     2048 16384 28552
  b: 16777216 16777232    4.2BSD     2048 16384 28552
  c: 20964825  8385930    unused        0     0         # "raw" part, 
don't edit
  d: 50302960 33554448    4.2BSD     2048 16384 28552
bsdlabel: partition c doesn't start at 0!
bsdlabel: partition c doesn't cover the whole unit!
bsdlabel: An incorrect partition c may cause problems for standard 
system utilities
==== END OF bsdlabel ====

Now that I look at the bsdlabel output, I vaugely recall that I couldn't 
get c correct...

From sonic2000gr at gmail.com  Fri Sep 11 17:32:55 2009
From: sonic2000gr at gmail.com (Manolis Kiagias)
Date: Fri Sep 11 17:33:02 2009
Subject: MSI GT 627 unsuccessful installation in 7-STABLE and 8-BETA4
In-Reply-To: <4AAA7C71.8070708@eng.auth.gr>
References: <4AAA7C71.8070708@eng.auth.gr>
Message-ID: <4AAA848C.4060707@gmail.com>

George Mamalakis wrote:
> Dear all,
>
> My question should maybe have be sent to some other fbsd list; if so,
> please someone instruct me where, and excuse me for my potential mistake.
>
> Now to my question:
>
> I just bought the MSI GT 627 Laptop, and I tried to install FreeBSD on
> it. First I tried with 8-BETA4 amd, then with 8-BETA4 i386, and lastly
> with 7.2 latest snapshot. All attempts have been unsuccessful, so I
> tried NetBSD 5.0.1 to see if it would install, and it did!
>
> The kernel messages I got on all FOUR attempts (even in NetBSD,
> although it worked finally) was something like that (in the beginning)
> (NetBSD excerpt, since it is the only that booted, so I could
> copy-paste it from dmesg, but FreeBSD gave the exact same Error
> messages (a few numbers differ)):
>
> Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005,
>    2006, 2007, 2008, 2009
>    The NetBSD Foundation, Inc.  All rights reserved.
> Copyright (c) 1982, 1986, 1989, 1991, 1993
>    The Regents of the University of California.  All rights reserved.
>
> NetBSD 5.0.1 (GENERIC) #0: Thu Jul 30 00:08:07 UTC 2009
>       
> builds@b7.netbsd.org:/home/builds/ab/netbsd-5-0-1-RELEASE/amd64/200907292356Z-obj/home/builds/ab/netbsd-5-0-1-RELEASE/src/sys/arch/amd64/compile/GENERIC
>
> total memory = 4095 MB
> avail memory = 3954 MB
> timecounter: Timecounters tick every 10.000 msec
> timecounter: Timecounter "i8254" frequency 1193182 Hz quality 100
> SMBIOS rev. 2.5 @ 0x9a400 (45 entries)
> Micro-Star International GT627       (Ver 1.000)
> mainbus0 (root)
> cpu0 at mainbus0 apid 0: Intel 686-class, 2394MHz, id 0x1067a
> cpu1 at mainbus0 apid 1: Intel 686-class, 2394MHz, id 0x1067a
> cpu2 at mainbus0 apid 2: Intel 686-class, 2394MHz, id 0x1067a
> cpu3 at mainbus0 apid 3: Intel 686-class, 2394MHz, id 0x1067a
> ioapic0 at mainbus0 apid 4: pa 0xfec00000, version 20, 24 pins
> acpi0 at mainbus0: Intel ACPICA 20080321
> acpi0: X/RSDT: OemId <MSI_NB,MEGABOOK,20090407>, AslId <MSFT,00000097>
> ACPI Error (evregion-0427): No handler for Region [EC__]
> (0xffff800007e20400) [EmbeddedControl] [20080321]
> ACPI Error (exfldio-0390): Region EmbeddedControl(3) has no handler
> [20080321]
> ACPI Error (psparse-0627): Method parse/execution failed
> [\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xffff800007e23760), AE_NOT_EXIST
> ACPI Error (uteval-0306): Method execution failed
> [\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xffff800007e23760), AE_NOT_EXIST
> acpi0: SCI interrupting at int 9
> acpi0: fixed-feature power button present
> timecounter: Timecounter "ACPI-Fast" frequency 3579545 Hz quality 1000
> ACPI-Fast 24-bit timer
> ACPI Error (evregion-0427): No handler for Region [EC__]
> (0xffff800007e20400) [EmbeddedControl] [20080321]
> ACPI Error (exfldio-0390): Region EmbeddedControl(3) has no handler
> [20080321]
> ACPI Error (psparse-0627): Method parse/execution failed
> [\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xffff800007e23760), AE_NOT_EXIST
> ACPI Error (uteval-0306): Method execution failed
> [\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xffff800007e23760), AE_NOT_EXIST
> WMI1 (pnp0c14) at acpi0 not configured
> ....
>
> where fbsd differed, was somewhere after identifying ad4 (the disk,
> which is WDC WD5000BEVT-22ZAT0 01.01A1), where it stated:
>
> acd0: FAILURE - READ_BIG MEDIUM ERROR asc=0x11 ascq=0x05
> run_interrupt_driven_hooks: still waiting after 60 seconds for xpt_config
> run_interrupt_driven_hooks: still waiting after 120 seconds for
> xpt_config
>
> and after that it kept on repeating the last message, only increasing
> the seconds to wait, until nothing more happened.
>
> Does anyone know if this is something that will be fixed soon? I guess
> it has to do with MSI's ACPI or something like that.
>
> Thank you all for your interest.
>
> Regards,
>
> mamalos.
>
Is the laptop equipped with a firewire port?
I have a few Gigabyte 8IPE1000-G motherboards at school that exhibit the
exact same behaviour. (Using 7.X, have not tried with 8.0 yet). Although
the motherboard does not in fact have a firewire chip soldered on, the
BIOS presents a firewire device (in Windows it shows in the device
manager as a non-working, unknown problem device) and I believe this
confuses the FreeBSD boot sequence. Other people on the lists have also
suggested disabling device sbp in a custom kernel configuration file (or
even removing the entire  firewire section if you don't need it).
One possible first step would be to try disabling firewire in the BIOS
(Sadly I don't have this option at all in my case) and see if the boot
continues. If you install successfully you may then try building a
custom kernel and re-enabling the BIOS option.
From qing.li at bluecoat.com  Fri Sep 11 18:01:37 2009
From: qing.li at bluecoat.com (Li, Qing)
Date: Fri Sep 11 18:01:44 2009
Subject: NFS issues on 8.0-BETA4
In-Reply-To: <9ef3bf09fa0e081eca3965e3f0e84f82.squirrel@email.polands.org>
References: <9ef3bf09fa0e081eca3965e3f0e84f82.squirrel@email.polands.org>
Message-ID: <B583FBF374231F4A89607B4D08578A4305454467@bcs-mail03.internal.cacheflow.com>

> 
> I cannot sucessfully mount exports from the NFSv3 server on the
> 8.0-BETA4 client.  All works well with 7.2 clients.
> 
> The strange thing is, the directory in which I mount the nfs
> filesystem disappears, and I get an error when I attempt to access the
> directory.
> 

	This may be a known issue that a couple of us have been
	working on yesterday. Would you be willing to try out a 
	temporary patch?

	-- Qing

From doug at polands.org  Fri Sep 11 18:45:18 2009
From: doug at polands.org (Doug Poland)
Date: Fri Sep 11 18:45:27 2009
Subject: NFS issues on 8.0-BETA4
In-Reply-To: <B583FBF374231F4A89607B4D08578A4305454467@bcs-mail03.internal.cacheflow.co
	m>
References: <9ef3bf09fa0e081eca3965e3f0e84f82.squirrel@email.polands.org>
	<B583FBF374231F4A89607B4D08578A4305454467@bcs-mail03.internal.cacheflow.com>
Message-ID: <e1816e4c5ee2f3cb6241424b09681a44.squirrel@email.polands.org>


On Fri, September 11, 2009 13:00, Li, Qing wrote:
>>
>> I cannot successfully mount exports from the NFSv3 server on the
>> 8.0-BETA4 client.  All works well with 7.2 clients.
>>
>> The strange thing is, the directory in which I mount the nfs
>> filesystem disappears, and I get an error when I attempt to access
>> the directory.
>>
>
> 	This may be a known issue that a couple of us have been
> 	working on yesterday. Would you be willing to try out a
> 	temporary patch?
>
> 	-- Qing
>
I'd be happy to assist anyway I can.


-- 
Regards,
Doug

From artis.caune at gmail.com  Fri Sep 11 19:17:01 2009
From: artis.caune at gmail.com (Artis Caune)
Date: Fri Sep 11 19:17:08 2009
Subject: FreeBSD 8.0-BETA4 IBM ServerRaid 8k issues
In-Reply-To: <4AAA741A.7040105@eng.auth.gr>
References: <4AA90D88.4010004@eng.auth.gr>
	<9e20d71e0909110601kaa87f2em2e4e618b8feb306b@mail.gmail.com>
	<4AAA741A.7040105@eng.auth.gr>
Message-ID: <9e20d71e0909111217v6242c8f1ge391d72f00193344@mail.gmail.com>

2009/9/11 George Mamalakis <mamalos@eng.auth.gr>:
> Artis, and the rest of the guys, thank you all for your answers.
>
> Ivan, I was thinking of using one of the techniques you mention (create two
> volumes, install fbsd on one of them, and use GTP on the second drive), but
> I was wondering if there would be any "incompatibility" issues with tools
> like df, etc.
>
>
> In case I do this (since I only have sata drives), will I end up with
> degraded disk performance? Theoretically I assume not, since 1.5 Gbps is
> adequate for *each* disk (it calculates to something like ~178MBps); but
> have you tried it on your disks, and everything works OK since (along with
> performance)?
>

We didn't tested speed much, but looks like you loose few MB (very
quick tests with dd). We are hosting 40K+ mailboxes, on ZFS :), so we
are more random-read/seek bound than Gbps bound.
But yes, we are running at 1.5Gbps and are happy stable/7 ZFS v6 users
and after few weeks we are migrating to stable/8 ZFS v13 with GPT and
gptzfsboot.




-- 
Artis Caune

    Everything should be made as simple as possible, but not simpler.
From rmacklem at uoguelph.ca  Fri Sep 11 20:43:09 2009
From: rmacklem at uoguelph.ca (Rick Macklem)
Date: Fri Sep 11 20:43:16 2009
Subject: NFS issues on 8.0-BETA4
In-Reply-To: <Pine.GSO.4.63.0909111621420.6191@muncher.cs.uoguelph.ca>
References: <9ef3bf09fa0e081eca3965e3f0e84f82.squirrel@email.polands.org>
	<B583FBF374231F4A89607B4D08578A4305454467@bcs-mail03.internal.cacheflow.com>
	<Pine.GSO.4.63.0909111621420.6191@muncher.cs.uoguelph.ca>
Message-ID: <Pine.GSO.4.63.0909111641240.10263@muncher.cs.uoguelph.ca>



On Fri, 11 Sep 2009, Rick Macklem wrote:

>
>
>>> 
>>> I cannot sucessfully mount exports from the NFSv3 server on the
>>> 8.0-BETA4 client.  All works well with 7.2 clients.
>>> 
>>> The strange thing is, the directory in which I mount the nfs
>>> filesystem disappears, and I get an error when I attempt to access the
>>> directory.
>>> 
I just took another glance at your email and see you have your server
configured for UDP only, so that explains it.

As noted in the last posting, the current mount_nfs.c switches to
TCP for NFS by default, so...
- add "udp" to your mount options
OR
- add "-t" to your nfs_server_flags

and I think things will work better.

I vaguely recall posting w.r.t. this uses UDP for the mount protocol
and then TCP for NFS by default and didn't really get any responses.
(I'm new to this and probably posted to freebsd-fs or freebsd-arch.)
At that time, I didn't realize the change was post FreeBSD7, so I
didn't do anything more about it.

Good luck with it and let us know how it goes, rick

From rmacklem at uoguelph.ca  Fri Sep 11 21:01:17 2009
From: rmacklem at uoguelph.ca (Rick Macklem)
Date: Fri Sep 11 21:01:23 2009
Subject: NFS issues on 8.0-BETA4
In-Reply-To: <B583FBF374231F4A89607B4D08578A4305454467@bcs-mail03.internal.cacheflow.com>
References: <9ef3bf09fa0e081eca3965e3f0e84f82.squirrel@email.polands.org>
	<B583FBF374231F4A89607B4D08578A4305454467@bcs-mail03.internal.cacheflow.com>
Message-ID: <Pine.GSO.4.63.0909111621420.6191@muncher.cs.uoguelph.ca>



>>
>> I cannot sucessfully mount exports from the NFSv3 server on the
>> 8.0-BETA4 client.  All works well with 7.2 clients.
>>
>> The strange thing is, the directory in which I mount the nfs
>> filesystem disappears, and I get an error when I attempt to access the
>> directory.
>>

I went and looked at the message over in stable@ (I guess I have to join
that mailing list, too:-).

I think that the second mount attempt, which failed with errno==64
EHOSTDOWN probably gives you a better indication of what is broken
and hints at a networking problem, which hopefully others can help
with?

mount_nfs currently has the quirk that, if you don't specify either
"udp" or "tcp", it will use UDP for the mount protocol and then
switch to TCP for NFS. (I didn't make it that way, but noticed it
when I was adding changes for the experimental client.)
So, you might want to try adding "udp" or "tcp" to the mount
options for your "simplified mount" and see what happens? (I suggest
this, since it seems to have been able to talk to mountd on the server,
but not NFS on the server and the only explanation I can think of is
the switch to TCP for that.)

I think the first case failed after the retrycnt, due to the "soft"
option, but hadn't succeeded in doing any NFS Getattr, so the mount
point's type wasn't VDIR--> returning errno==1 EPERM for the "ls -l".

If the mount attempts with "udp" or "tcp" specified give you the same
behaviour, you could try using wireshark to capture the traffic.
(Wireshark is pretty good at decoding NFS traffic.) If you don't have
wireshark, you can use "tcpdump -w <file> -s 0 <host>" to capture the
traffic in a file that can be fed to wireshark later. (I'd be happy to
look at the traffic, if you were to email me the above <file>.)

Good luck with it, rick
ps: I'll assume that the client can talk to the server for other
     stuff ok.
pss: A big change between 7 and 8 is use of a new kernel RPC layer
     that handles the RPC transport (again, I wasn't the author, but
     am somewhat familiar with it).

From stefan.lambrev at moneybookers.com  Fri Sep 11 21:37:31 2009
From: stefan.lambrev at moneybookers.com (Stefan Lambrev)
Date: Fri Sep 11 21:37:41 2009
Subject: System crawls after Upgrade 7.0->7.2
In-Reply-To: <20090909215959.6b5152f2@sub.han.vpn.gamesnet.de>
References: <20090908121945.43ba3976@sub.han.vpn.gamesnet.de>
	<20090909104807.633418ea@sub.han.vpn.gamesnet.de>
	<20090909170213.GA7925@lava.net>
	<20090909213022.34d64e47@sub.han.vpn.gamesnet.de>
	<20090909215959.6b5152f2@sub.han.vpn.gamesnet.de>
Message-ID: <C676F9BF-4BCE-4FC7-A381-E95C27C89488@moneybookers.com>

Hi Tobias,

This is the "pseudo" RAID controller that comes by default with most  
Dell, low cost HP servers and probably others?
If you depend on I/O I would recommend you to change this raid with  
PERC6/i (looks like this is Dell server)
which is little more expensive, but comes with 256MB battery backed  
cache.

In my experience mpt devices are crap, and their performance is worse  
then software mirror.
PERC6/i is something totally different :) It's again LSI product  
branded from Dell and it works with mfi driver.

The only problem in the past with them was the management utility  
which was linux binary, but today there is
official native tool in ports, and in 8.0 in base install there will  
be a tool to manage your controller.

Well this wasn't that big problem compared to mpt which cannot be  
managed under FreeBSD at all?

On Sep 9, 2009, at 10:59 PM, Tobias Lott wrote:

>
>
> On Wed, 9 Sep 2009 21:30:22 +0200
> Tobias Lott <tlott@gamesnet.de> wrote:
>
>>
>>
>> On Wed, 9 Sep 2009 07:02:13 -1000
>> Clifton Royston <cliftonr@lava.net> wrote:
>>
>>> On Wed, Sep 09, 2009 at 10:48:07AM +0200, Tobias Lott wrote:
>>>> On Tue, 8 Sep 2009 12:19:45 +0200
>>>> Tobias Lott <tlott@gamesnet.de> wrote:
>>>>> Hey Everyone,
>>>>>
>>>>> I upgraded a Dual Core Machine to 7.2-Stable (2 Days ago), all
>>>>> OS related Stuff is located on an UFS Slice, Application is on
>>>>> a ZFS Volume.
>>>>>
>>>>> After the Upgrade everything seemed fine, but a User noticed one
>>>>> PHP Script which is basically loading a plain Textfile into
>>>>> Mysql times out. PHP Timeout was set to 60 secs, that was more
>>>>> then enough just one day before the upgrade.
>>> ...
>>>>> Since I upgraded the Machines zpool to version 13 already I
>>>>> don't really wanna go back to 7.0, but it seems the only way
>>>>> out atm.
>>>>>
>>>>> Hopefully someone can give me a Hint where maybe I forgot to
>>>>> check.
>>>>>
>>>>> Somehow it feels like the last Versions, I'd say starting with
>>>>> 7.x doesn't really feel that Rock-Stable as Versions Prior used
>>>>> to be. Prolly cause I'm using an Experimental Feature like ZFS,
>>>>> so no Offense nor Blame and this is not intended as a Flame or
>>>>> whatsoever! So don't get me wrong, I always liked, used,
>>>>> recommended FreeBSD since 4.0 and will continue to do so!
>>>>>
>>>>> Best Regards
>>>>>
>>>>
>>>> I've tested some more it seems the Bottleneck is the HD, Raid
>>>> Array is Optimal checked it.
>>>
>>>  Probably you already checked this, but did you go through the
>>> dmesg output relating to ata and drive detection closely?
>>>
>>>  In the past from time to time I've had machines suddenly start
>>> crawling after an upgrade, and it turned out it was because some
>>> change in the driver detection caused the ata to fall back to pio
>>> mode.  The symptoms are pretty much like you describe - all HD IO
>>> takes forever.
>>>
>>>  -- Clifton
>>>
>>
>> Thanks for that Hint, checked again to be sure, but thats not the
>> Case.
>>
>> mpt0:vol0(mpt0:0:0): Settings ( Hot-Plug-Spares High-Priority- 
>> ReSync )
>> mpt0:vol0(mpt0:0:0): Using Spare Pool: 0
>> mpt0:vol0(mpt0:0:0): 2 Members:
>>      (mpt0:1:32:0): Primary Online
>>      (mpt0:1:1:0): Secondary Online
>> mpt0:vol0(mpt0:0:0): RAID-1 - Optimal
>> mpt0:vol0(mpt0:0:0): Status ( Enabled )
>> (mpt0:vol0:1): Physical (mpt0:0:1:0), Pass-thru (mpt0:1:0:0)
>> (mpt0:vol0:1): Online
>> (mpt0:vol0:0): Physical (mpt0:0:32:0), Pass-thru (mpt0:1:1:0)
>> (mpt0:vol0:0): Online
>> acd0: CDROM <HL-DT-ST GCR-8240N/1.10> at ata0-master UDMA33
>> acd1: CDROM <VIRTUALCDROM DRIVE/> at ata2-slave PIO3
>> da0 at mpt0 bus 0 target 0 lun 0
>> da0: <Dell VIRTUAL DISK 1028> Fixed Direct Access SCSI-5 device
>> da0: 300.000MB/s transfers
>> da0: Command Queueing Enabled
>> SdMaP0::  A1P5 1C6P3U4 M#B1  (L3a1u0n5c4h6e4d3!2
>> 512 byte sectors: 255H 63S/T 19330C)
>>
>>
>
> Oh well just did some more research and found:
> http://www.mail-archive.com/freebsd-performance@freebsd.org/msg02461.html
>
> Gonna try it out later and gonna give a Report.
>
> -- 
> Tobias Lott
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org 
> "

--
Best Wishes,
Stefan Lambrev
ICQ# 24134177





From graham at menhennitt.com.au  Sat Sep 12 04:57:19 2009
From: graham at menhennitt.com.au (Graham Menhennitt)
Date: Sat Sep 12 04:57:26 2009
Subject: problem booting FreeBSD 8-Beta4 on Soekris net5501
Message-ID: <4AAB2A2C.2000803@menhennitt.com.au>

G'day,

I'm upgrading a Soekris net5501 from FreeBSD 7-Stable to 8-Beta4 (via
source). I've done a buildworld, buildkernel, and installkernel. When I
try to boot the new kernel, it stops very early on in the boot sequence.
The serial console shows:

/boot/kernel/kernel text=0x32f9f0 data=0x36374+0x1e580
syms=[0x4+0x40720+0x4+0x592a3]                                                                                                                

-                                                                                                                                                                                              

Hit [Enter] to boot immediately, or any other key for command
prompt.                                                                                                                          

Booting
[/boot/kernel/kernel]...                                                                                                                                                               

/

The slash at the end is the first character of the spinner as it's
loading the kernel. It never shows the second character. I've tried two
different kernel configs - my own (from 7 modified to build with 8) and
aragon's from
http://www.nabble.com/no-time-of-day-clock-registered-on-net5501,-FreeBSD-8-td24544248.html
(with the line "options STOP_NMI" removed to get it to build). They both
do the same thing.

My loader.conf is the same as in 7:

beastie_disable="YES"
comconsole_speed="19200"
console="comconsole"

My kernel config is below.

Does anybody have any clues please?

Thanks for any help,
  Graham

cpu            
I586_CPU                                                                                                                                       

ident          
maxwell                                                                                                                                        


options         CPU_GEODE
options         CPU_SOEKRIS


options         SCHED_ULE               # ULE scheduler
options         INET                    # InterNETworking
options         INET6                   # IPv6 communications protocols
options         SCTP                    # Stream Control Transmission
Protocol
options         FFS                     # Berkeley Fast Filesystem
options         SOFTUPDATES             # Enable FFS soft updates support
options         NFSCLIENT               # Network Filesystem Client
options         NFSSERVER               # Network Filesystem Server
options         PROCFS                  # Process filesystem (requires
PSEUDOFS)
options         PSEUDOFS                # Pseudo-filesystem framework
options         COMPAT_FREEBSD7         # Compatible with FreeBSD7
options         SYSVSHM                 # SYSV-style shared memory
options         SYSVMSG                 # SYSV-style message queues
options         SYSVSEM                 # SYSV-style semaphores
options         _KPOSIX_PRIORITY_SCHEDULING # Posix P1003_1B real-time
extensions
options         IPFIREWALL
options         IPFIREWALL_VERBOSE
options         IPDIVERT
options         IPFIREWALL_NAT          # ipfw kernel nat support
options         LIBALIAS

device          pci

device          ata
device          atadisk         # ATA disk drives
options         ATA_STATIC_ID   # Static device numbering

device          scbus           # SCSI bus (required for SCSI)
device          da              # Direct Access (disks)
device          uart            # Generic UART driver

device          miibus          # MII bus support
device          vr              # VIA Rhine, Rhine II

device          wlan            # 802.11 support
device          wlan_ccmp       # 802.11 CCMP support
device          wlan_tkip       # 802.11 TKIP support
device          ath             # Atheros pci/cardbus NIC's
device          ath_hal         # pci/cardbus chip support
options         AH_SUPPORT_AR5416       # enable AR5416 tx/rx descriptors
device          ath_rate_sample # SampleRate tx rate control for ath
device          loop            # Network loopback
device          random          # Entropy device
device          ether           # Ethernet support
device          tap             # Ethernet tunnel.
device          tun             # Packet tunnel.
device          pty             # BSD-style compatibility pseudo ttys
device          md              # Memory "disks"
device          gif             # IPv6 and IPv4 tunneling
device          bpf             # Berkeley packet filter
device          uhci            # UHCI PCI->USB interface
device          ohci            # OHCI PCI->USB interface
device          ehci            # EHCI PCI->USB interface (USB 2.0)
device          usb             # USB Bus (required)
device          ulpt            # Printer
device          umass           # Disks/Mass storage - Requires scbus and da
From doug at polands.org  Sat Sep 12 14:41:15 2009
From: doug at polands.org (Doug Poland)
Date: Sat Sep 12 14:41:24 2009
Subject: NFS issues on 8.0-BETA4
In-Reply-To: <Pine.GSO.4.63.0909111621420.6191@muncher.cs.uoguelph.ca>
References: <9ef3bf09fa0e081eca3965e3f0e84f82.squirrel@email.polands.org>
	<B583FBF374231F4A89607B4D08578A4305454467@bcs-mail03.internal.cacheflow.com>
	<Pine.GSO.4.63.0909111621420.6191@muncher.cs.uoguelph.ca>
Message-ID: <19c32ef4263ed3c2ab1624a43ae86c78.squirrel@email.polands.org>

On Fri, September 11, 2009 15:37, Rick Macklem wrote:
>
>>>
>>> I cannot sucessfully mount exports from the NFSv3 server on the
>>> 8.0-BETA4 client.  All works well with 7.2 clients.
>>>
>>> The strange thing is, the directory in which I mount the nfs
>>> filesystem disappears, and I get an error when I attempt to
>>> access the directory.
>>>
>
> I went and looked at the message over in stable@ (I guess I have to
> join that mailing list, too:-).
>
> I think that the second mount attempt, which failed with errno==64
> EHOSTDOWN probably gives you a better indication of what is broken
> and hints at a networking problem, which hopefully others can help
> with?
>
> mount_nfs currently has the quirk that, if you don't specify either
> "udp" or "tcp", it will use UDP for the mount protocol and then
> switch to TCP for NFS. (I didn't make it that way, but noticed it
> when I was adding changes for the experimental client.) So, you might
> want to try adding "udp" or "tcp" to the mount options for your
> "simplified mount" and see what happens? (I suggest this, since it
> seems to have been able to talk to mountd on the server, but not NFS
> on the server and the only explanation I can think of is the switch
> to TCP for that.)
>
> I think the first case failed after the retrycnt, due to the "soft"
> option, but hadn't succeeded in doing any NFS Getattr, so the mount
> point's type wasn't VDIR--> returning errno==1 EPERM for the "ls -l".
>
>
> If the mount attempts with "udp" or "tcp" specified give you the same
>  behaviour, you could try using wireshark to capture the traffic.
> (Wireshark is pretty good at decoding NFS traffic.) If you don't have
>  wireshark, you can use "tcpdump -w <file> -s 0 <host>" to capture
> the traffic in a file that can be fed to wireshark later. (I'd be
> happy to look at the traffic, if you were to email me the above
> <file>.)
>
> Good luck with it, rick ps: I'll assume that the client can talk to
> the server for other stuff ok. pss: A big change between 7 and 8 is
> use of a new kernel RPC layer that handles the RPC transport (again,
> I wasn't the author, but am somewhat familiar with it).
>
>
Simply adding -o udp to my mount command made the NFS mount work
correctly.  Qing, would it be beneficial to attempt the patch in light
of these findings?

Thanks all for the help, sorry for the noise.


-- 
Regards,
Doug

From qing.li at bluecoat.com  Sat Sep 12 18:51:03 2009
From: qing.li at bluecoat.com (Li, Qing)
Date: Sat Sep 12 18:51:16 2009
Subject: NFS issues on 8.0-BETA4
In-Reply-To: <19c32ef4263ed3c2ab1624a43ae86c78.squirrel@email.polands.org>
References: <9ef3bf09fa0e081eca3965e3f0e84f82.squirrel@email.polands.org>
	<B583FBF374231F4A89607B4D08578A4305454467@bcs-mail03.internal.cacheflow.com>
	<Pine.GSO.4.63.0909111621420.6191@muncher.cs.uoguelph.ca>
	<19c32ef4263ed3c2ab1624a43ae86c78.squirrel@email.polands.org>
Message-ID: <B583FBF374231F4A89607B4D08578A43054D4F00@bcs-mail03.internal.cacheflow.com>

Hi Doug,

> >
> Simply adding -o udp to my mount command made the NFS mount work
> correctly.  Qing, would it be beneficial to attempt the patch in light
> of these findings?
> 

Have you tried the patch that I sent you privately? Does it work for
you?

Thanks,

-- Qing

From gausus at gausus.net  Sat Sep 12 20:42:30 2009
From: gausus at gausus.net (Maciej Jan Broniarz)
Date: Sat Sep 12 20:42:37 2009
Subject: problem with link aggregation failover
Message-ID: <1704894341.63251252787681862.JavaMail.root@dagobah.intersec.pl>

Hello,

I am trying to configure lagg failover mode on 7.2. 

I do:

# ifconfig xl0 up
# ifconfig fxp0 up
# ifconfig lagg0 create
# ifconfig lagg0 up laggproto failover laggport xl0 laggport fxp0
# dhclient lagg0 

And all seems to work ok. Still I disconnect the cable from the master card the connection stops. 
Although fxp0 becomes active the connection is still dead. If I start pinging any host from that machine
the conection comes back to live, but having ping in background all the time is not the solution.

Am I doing something wrong or have I missed something in the configuration?

Best regards,
mjb
From attilio at freebsd.org  Sat Sep 12 21:32:52 2009
From: attilio at freebsd.org (Attilio Rao)
Date: Sat Sep 12 21:33:00 2009
Subject: 7.2-release/amd64: panic, spin lock held too long
In-Reply-To: <cf9b1ee00907061812r3da70018i1c8d8d12bb038a80@mail.gmail.com>
References: <cf9b1ee00907061812r3da70018i1c8d8d12bb038a80@mail.gmail.com>
Message-ID: <3bbf2fe10909121432x7bd4f7es497e9431c4e520d6@mail.gmail.com>

2009/7/7 Dan Naumov <dan.naumov@gmail.com>:
> I just got a panic following by a reboot a few seconds after running
> "portsnap update", /var/log/messages shows the following:
>
> Jul  7 03:49:38 atom syslogd: kernel boot file is /boot/kernel/kernel
> Jul  7 03:49:38 atom kernel: spin lock 0xffffffff80b3edc0 (sched lock
> 1) held by 0xffffff00017d8370 (tid 100054) too long
> Jul  7 03:49:38 atom kernel: panic: spin lock held too long
>
> /var/crash looks empty. This is a system running official 7.2-p1
> binaries since I am using freebsd-update to keep up with the patches
> (just updated to -p2 after this panic) running with very low load,
> mostly serving files to my home network over Samba and running a few
> irssi instances in a screen. What do I need to do to catch more
> information if/when this happens again?

Dan, is that machine equipped with Hyperthreading?

Attilio


-- 
Peace can only be achieved by understanding - A. Einstein
From svein-listmail at stillbilde.net  Sat Sep 12 21:51:32 2009
From: svein-listmail at stillbilde.net (Svein Skogen (listmail account))
Date: Sat Sep 12 21:51:39 2009
Subject: Question regarding vlans and lagg
Message-ID: <4AAC140F.2070203@stillbilde.net>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Can the vlan "vlandev" be a lagg port of multiple physical interfaces
(for redundancy)?

//Svein

- --
- --------+-------------------+-------------------------------
  /"\   |Svein Skogen       | svein@d80.iso100.no
  \ /   |Solberg ?stli 9    | PGP Key:  0xE5E76831
   X    |2020 Skedsmokorset | svein@jernhuset.no
  / \   |Norway             | PGP Key:  0xCE96CE13
        |                   | svein@stillbilde.net
 ascii  |                   | PGP Key:  0x58CD33B6
 ribbon |System Admin       | svein-listmail@stillbilde.net
Campaign|stillbilde.net     | PGP Key:  0x22D494A4
        +-------------------+-------------------------------
        |msn messenger:     | Mobile Phone: +47 907 03 575
        |svein@jernhuset.no | RIPE handle:    SS16503-RIPE
- --------+-------------------+-------------------------------
         If you really are in a hurry, mail me at
               svein-mobile@stillbilde.net
 This mailbox goes directly to my cellphone and is checked
        even when I'm not in front of my computer.
- ------------------------------------------------------------
                     Picture Gallery:
          https://gallery.stillbilde.net/v/svein/
- ------------------------------------------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkqsFA8ACgkQODUnwSLUlKQNNACgscocpg6X5c6s7Wm2eF8JyyMg
jV8AnjE8B4BzGn9/pSVrkB9MLJBY5SDR
=lZ9v
-----END PGP SIGNATURE-----
From dan.naumov at gmail.com  Sat Sep 12 22:02:37 2009
From: dan.naumov at gmail.com (Dan Naumov)
Date: Sat Sep 12 22:02:43 2009
Subject: 7.2-release/amd64: panic, spin lock held too long
In-Reply-To: <3bbf2fe10909121432x7bd4f7es497e9431c4e520d6@mail.gmail.com>
References: <cf9b1ee00907061812r3da70018i1c8d8d12bb038a80@mail.gmail.com>
	<3bbf2fe10909121432x7bd4f7es497e9431c4e520d6@mail.gmail.com>
Message-ID: <cf9b1ee00909121502v66566b46p754ed2f2e549555@mail.gmail.com>

On Sun, Sep 13, 2009 at 12:32 AM, Attilio Rao <attilio@freebsd.org> wrote:
> 2009/7/7 Dan Naumov <dan.naumov@gmail.com>:
>> I just got a panic following by a reboot a few seconds after running
>> "portsnap update", /var/log/messages shows the following:
>>
>> Jul ?7 03:49:38 atom syslogd: kernel boot file is /boot/kernel/kernel
>> Jul ?7 03:49:38 atom kernel: spin lock 0xffffffff80b3edc0 (sched lock
>> 1) held by 0xffffff00017d8370 (tid 100054) too long
>> Jul ?7 03:49:38 atom kernel: panic: spin lock held too long
>>
>> /var/crash looks empty. This is a system running official 7.2-p1
>> binaries since I am using freebsd-update to keep up with the patches
>> (just updated to -p2 after this panic) running with very low load,
>> mostly serving files to my home network over Samba and running a few
>> irssi instances in a screen. What do I need to do to catch more
>> information if/when this happens again?
>
> Dan, is that machine equipped with Hyperthreading?
>
> Attilio

Yes. It's an Intel Atom 330, which is a dualcore CPU with HT (4 cores
visible in "top" as a result)

- Dan
From gelraen.ua at gmail.com  Sat Sep 12 23:33:25 2009
From: gelraen.ua at gmail.com (Maxim Ignatenko)
Date: Sat Sep 12 23:33:59 2009
Subject: Question regarding vlans and lagg
In-Reply-To: <4AAC140F.2070203@stillbilde.net>
References: <4AAC140F.2070203@stillbilde.net>
Message-ID: <20090913021152.5b16bb8d@imax>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sat, 12 Sep 2009 23:35:11 +0200
"Svein Skogen (listmail account)" <svein-listmail@stillbilde.net> wrote:

> Can the vlan "vlandev" be a lagg port of multiple physical interfaces
> (for redundancy)?
> 
AFAIK, no, but you can try to achieve the same effect with ng_one2many(4)+ng_vlan(4)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.12 (FreeBSD)

iQEcBAEBAgAGBQJKrCq+AAoJEDKn2XrMqQjovjgH/2Gvv+n7ua6u3AerOmA/7+tR
yg4sirTc15Z0CjIwsjpmoYa4J1UvULrJ2pdBCa6IAHPbdSIC7/3SUvK91M/g/wKW
kQ5Qi+itwIAp7qpCxsPjyMiSObLn87Ns/j9fTJHA7jmvvwbG3fUO37q/CiL8TroX
gY4DO1HkzEn3q6t654lvIBCCG4bBdCRflmktdZ5yKUEn+bmVmOI2iRpYV4czwGVE
/uVUvSIZh2l4GsICcCX2kg+fBAJ7V0zrnI2erN1Uo+7DdkfWsWI0f1WGVloD9gHW
sYCon23RTTzctqb39pw9mmYNhNLGwLNjY8xTZsZre0qu6DfJuvXDZL58G4LC1lk=
=ANyB
-----END PGP SIGNATURE-----
From amarat at ksu.ru  Sat Sep 12 23:49:07 2009
From: amarat at ksu.ru (Marat N.Afanasyev)
Date: Sat Sep 12 23:49:15 2009
Subject: Question regarding vlans and lagg
In-Reply-To: <4AAC140F.2070203@stillbilde.net>
References: <4AAC140F.2070203@stillbilde.net>
Message-ID: <4AAC3343.5030806@ksu.ru>

Svein Skogen (listmail account) wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Can the vlan "vlandev" be a lagg port of multiple physical interfaces
> (for redundancy)?
> 
> //Svein
> 
> 

i think that you should try the following:

1. join two ports on switch to trunk, say vport1
2. assign allowed vlans to this vport1
3. create lagg0 on freebsd
4. create vlan interfaces on freebsd using vlandev lagg0

and i suppose it just should work ;)

-- 
SY, Marat
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3221 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090912/1d235ca3/smime.bin
From dave at hardman.name  Sun Sep 13 05:48:12 2009
From: dave at hardman.name (Dave Hardman)
Date: Sun Sep 13 05:48:20 2009
Subject: 8.0-BETA-4: no mouse or keyboard in X.
Message-ID: <20090913052958.GA3348@loc.alh.ost>

    I upgraded from 7.2 to 8.0-BETA4. Now X will not receive input
from either the mouse or keyboard. When this has happened in 7.1
or 7.2 it was fixed by running hal. The keyboard, mouse and hal
are all working. I did not configure X, the xorg.conf file was
auto generated when X was first started.

    I have tried a few things; new xorg.conf with Xorg -configure, 
putting config files, which I found in a mailing list, in
/usr/local/etc/hal/fdi/policy. Using a different window manager.
Nothing worked.

    Theres nothing in the log files that I recognise. Xorg.log
reported "config/hal Adding input device AT Keyboard."

    Any suggestions

    I also noticed the fuse.ko will not load, reporting "Exec
format error."
  
dave@loc:/usr/home/dave $ uname -a
FreeBSD loc.alh.ost 8.0-BETA4 FreeBSD 8.0-BETA4 #0: Sun Sep  6 04:44:31 UTC 2009     root@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC  amd64

Thanks Dave
From gausus at gausus.net  Sun Sep 13 10:02:40 2009
From: gausus at gausus.net (Maciej Jan Broniarz)
Date: Sun Sep 13 10:02:47 2009
Subject: problem with link aggregation failover
In-Reply-To: <1d3ed48c0909121425g4a255ebah293ce39e42623ab8@mail.gmail.com>
Message-ID: <88656044.63711252836705223.JavaMail.root@dagobah.intersec.pl>

Hello,

> xl0 and fxp0 both need to have the same mac address

I have configured the same mac on both cards. 
My lagg0 looks like this:

lagg0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
	options=9<RXCSUM,VLAN_MTU>
	ether 00:01:02:20:24:ef
	inet 192.168.1.104 netmask 0xffffff00 broadcast 192.168.1.255
	media: Ethernet autoselect
	status: active
	laggproto failover
	laggport: fxp0 flags=0<>
	laggport: xl0 flags=5<MASTER,ACTIVE>


When I disconnect the cable from xl0, the network connection dies, and my lagg0 looks like this:

lagg0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
	options=9<RXCSUM,VLAN_MTU>
	ether 00:01:02:20:24:ef
	inet 192.168.1.104 netmask 0xffffff00 broadcast 192.168.1.255
	media: Ethernet autoselect
	status: active
	laggproto failover
	laggport: fxp0 flags=4<ACTIVE>
	laggport: xl0 flags=1<MASTER>


Still, if I start pinging anything from that host, the connections comes back to live:

lagg0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
	options=9<RXCSUM,VLAN_MTU>
	ether 00:01:02:20:24:ef
	inet 192.168.1.104 netmask 0xffffff00 broadcast 192.168.1.255
	media: Ethernet autoselect
	status: active
	laggproto failover
	laggport: fxp0 flags=4<ACTIVE>
	laggport: xl0 flags=1<MASTER>

What might be the problem with that setup?

Thanks for your help,
mjb
 
> On Sat, Sep 12, 2009 at 1:34 PM, Maciej Jan Broniarz
> <gausus@gausus.net> wrote:
> > Hello,
> >
> > I am trying to configure lagg failover mode on 7.2.
> >
> > I do:
> >
> > # ifconfig xl0 up
> > # ifconfig fxp0 up
> > # ifconfig lagg0 create
> > # ifconfig lagg0 up laggproto failover laggport xl0 laggport fxp0
> > # dhclient lagg0
> >
> > And all seems to work ok. Still I disconnect the cable from the
> master card the connection stops.
> > Although fxp0 becomes active the connection is still dead. If I
> start pinging any host from that machine
> > the conection comes back to live, but having ping in background all
> the time is not the solution.
> >
> > Am I doing something wrong or have I missed something in the
> configuration?
> >
> > Best regards,
> > mjb
> > _______________________________________________
> > freebsd-stable@freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> > To unsubscribe, send any mail to
> "freebsd-stable-unsubscribe@freebsd.org"
> >
> 
> 
> 
> -- 
> And what is good, Phaedrus,
> And what is not good?
> Need we ask anyone to tell us these things?
From rnoland at FreeBSD.org  Sun Sep 13 10:49:25 2009
From: rnoland at FreeBSD.org (Robert Noland)
Date: Sun Sep 13 10:49:31 2009
Subject: 8.0-BETA-4: no mouse or keyboard in X.
In-Reply-To: <20090913052958.GA3348@loc.alh.ost>
References: <20090913052958.GA3348@loc.alh.ost>
Message-ID: <1252838956.1692.1217.camel@balrog.2hip.net>

On Sun, 2009-09-13 at 15:29 +1000, Dave Hardman wrote:
> I upgraded from 7.2 to 8.0-BETA4. Now X will not receive input
> from either the mouse or keyboard. When this has happened in 7.1
> or 7.2 it was fixed by running hal. The keyboard, mouse and hal
> are all working. I did not configure X, the xorg.conf file was
> auto generated when X was first started.
> 
>     I have tried a few things; new xorg.conf with Xorg -configure, 
> putting config files, which I found in a mailing list, in
> /usr/local/etc/hal/fdi/policy. Using a different window manager.
> Nothing worked.
> 
>     Theres nothing in the log files that I recognise. Xorg.log
> reported "config/hal Adding input device AT Keyboard."
> 
>     Any suggestions
> 
>     I also noticed the fuse.ko will not load, reporting "Exec
> format error."

This suggests that you have not rebuilt your ports.  At a minumum you
need to rebuild fuse and hal, though I strongly suggest that you rebuild
everything.

robert.

> dave@loc:/usr/home/dave $ uname -a
> FreeBSD loc.alh.ost 8.0-BETA4 FreeBSD 8.0-BETA4 #0: Sun Sep  6 04:44:31 UTC 2009     root@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC  amd64
> 
> Thanks Dave
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
-- 
Robert Noland <rnoland@FreeBSD.org>
FreeBSD

From patfbsd at davenulle.org  Sun Sep 13 10:57:39 2009
From: patfbsd at davenulle.org (Patrick Lamaiziere)
Date: Sun Sep 13 10:57:47 2009
Subject: 8.0-BETA-4: no mouse or keyboard in X.
In-Reply-To: <20090913052958.GA3348@loc.alh.ost>
References: <20090913052958.GA3348@loc.alh.ost>
Message-ID: <20090913124052.533e87fb@baby-jane.lamaiziere.net>

Le Sun, 13 Sep 2009 15:29:58 +1000,
Dave Hardman <dave@hardman.name> a ?crit :

>     I upgraded from 7.2 to 8.0-BETA4. Now X will not receive input
> from either the mouse or keyboard. When this has happened in 7.1
> or 7.2 it was fixed by running hal. The keyboard, mouse and hal
> are all working. I did not configure X, the xorg.conf file was
> auto generated when X was first started.
> 
>     I have tried a few things; new xorg.conf with Xorg -configure, 
> putting config files, which I found in a mailing list, in
> /usr/local/etc/hal/fdi/policy. Using a different window manager.
> Nothing worked.
> 
>     Theres nothing in the log files that I recognise. Xorg.log
> reported "config/hal Adding input device AT Keyboard."

You need to rebuild hal and to remove the old libusb port.
libusb is now part of the base system in 8.X and you must use this
version. You should rebuild all that depend on the old port libusb (at
least).

>     I also noticed the fuse.ko will not load, reporting "Exec
> format error."

Did you rebuild this module too?
From danny at cs.huji.ac.il  Sun Sep 13 13:06:29 2009
From: danny at cs.huji.ac.il (Daniel Braniss)
Date: Sun Sep 13 13:06:36 2009
Subject: zfs(v13)+nfs and open(..., O_WRONLY|O_CREAT|O_EXCL, ...) returns io 
 error
Message-ID: <E1Mmomg-000LP6-Mw@kabab.cs.huji.ac.il>

this was fixed back in June, but now, it cropped up under 8BETA/32 bits,
the 64 bit is ok.
see
	http://www.freebsd.org/cgi/query-pr.cgi?pr=135412
thanks,
	danny


From louisk at cryptomonkeys.org  Sun Sep 13 16:33:53 2009
From: louisk at cryptomonkeys.org (Louis Kowolowski)
Date: Sun Sep 13 16:34:00 2009
Subject: Question regarding vlans and lagg
In-Reply-To: <4AAC3343.5030806@ksu.ru>
References: <4AAC140F.2070203@stillbilde.net> <4AAC3343.5030806@ksu.ru>
Message-ID: <9DAD6CD5-0BD7-4B06-8FA7-D0159419FEAE@cryptomonkeys.org>

On Sep 12, 2009, at 4:48 PM, Marat N.Afanasyev wrote:

> * PGP - S/MIME Signed by an unverified key: September 12, 2009  
> 4:48:19 PM
>
> Svein Skogen (listmail account) wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>> Can the vlan "vlandev" be a lagg port of multiple physical interfaces
>> (for redundancy)?
>> //Svein
>
> i think that you should try the following:
>
> 1. join two ports on switch to trunk, say vport1
> 2. assign allowed vlans to this vport1
> 3. create lagg0 on freebsd
> 4. create vlan interfaces on freebsd using vlandev lagg0
>
> and i suppose it just should work ;)
>
You're looking for something along these lines:
cloned_interfaces="lagg0 vlan0 vlan1"
ifconfig_em0="up"
ifconfig_em1="up"
ifconfig_lagg0="laggproto failover laggport em0 laggport em1 up"
ifconfig_vlan0="vlan 2 vlandev lagg0 up"
ifconfig_vlan1="vlan 3 vlandev lagg0 up"
ifconfig_vlan0_alias0="inet 192.168.1.41/24"
ifconfig_vlan1_alias1="inet 172.16.0.20/24"

This will give you failover for your lagg(8) interface, I believe you  
can also use something like etherchannel.
--
Louis Kowolowski                                louisk@cryptomonkeys.org
Cryptomonkeys:                      http://www.cryptomonkeys.org/~louisk

Making life more interesting for people since 1977

From amarat at ksu.ru  Sun Sep 13 17:56:06 2009
From: amarat at ksu.ru (Marat N.Afanasyev)
Date: Sun Sep 13 17:56:13 2009
Subject: Question regarding vlans and lagg
In-Reply-To: <9DAD6CD5-0BD7-4B06-8FA7-D0159419FEAE@cryptomonkeys.org>
References: <4AAC140F.2070203@stillbilde.net> <4AAC3343.5030806@ksu.ru>
	<9DAD6CD5-0BD7-4B06-8FA7-D0159419FEAE@cryptomonkeys.org>
Message-ID: <4AAD3219.9040806@ksu.ru>

Louis Kowolowski wrote:
> On Sep 12, 2009, at 4:48 PM, Marat N.Afanasyev wrote:
> 
>> * PGP - S/MIME Signed by an unverified key: September 12, 2009 4:48:19 PM
>>
>> Svein Skogen (listmail account) wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>> Can the vlan "vlandev" be a lagg port of multiple physical interfaces
>>> (for redundancy)?
>>> //Svein
>>
>> i think that you should try the following:
>>
>> 1. join two ports on switch to trunk, say vport1
>> 2. assign allowed vlans to this vport1
>> 3. create lagg0 on freebsd
>> 4. create vlan interfaces on freebsd using vlandev lagg0
>>
>> and i suppose it just should work ;)
>>
> You're looking for something along these lines:
> cloned_interfaces="lagg0 vlan0 vlan1"
> ifconfig_em0="up"
> ifconfig_em1="up"
> ifconfig_lagg0="laggproto failover laggport em0 laggport em1 up"
> ifconfig_vlan0="vlan 2 vlandev lagg0 up"
> ifconfig_vlan1="vlan 3 vlandev lagg0 up"
> ifconfig_vlan0_alias0="inet 192.168.1.41/24"
> ifconfig_vlan1_alias1="inet 172.16.0.20/24"
> 
> This will give you failover for your lagg(8) interface, I believe you 
> can also use something like etherchannel.

lagg can be configured as etherchannel, afaik

and yes, everything i'd proposed could be done from rc.conf

and remember that cloned_interfaces could not be restarted via
/etc/rc.d/neif restart ifN

-- 
SY, Marat
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3221 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090913/d0fd744e/smime.bin
From jguojun at sbcglobal.net  Mon Sep 14 01:51:50 2009
From: jguojun at sbcglobal.net (Jin Guojun)
Date: Mon Sep 14 01:51:57 2009
Subject: 8.0-Beta installation problem -- Unable to find /dev/ad0s1b
Message-ID: <4AAD9B71.3080703@sbcglobal.net>

Tried to install from both 8.0-BETA{3, 4}-i386-dvd1.iso on a Phenom 9600
system and having
some disk problems.

The system is running 6.x and/or 7.2 FreeBSD (on different drives).

Disconnected rest drives and only left 7.2 drive in.
ad0: 76319MB <Seagate ST3802110A 3.AAJ> at ata0-master UDMA100

Boot 8.0-BETA3-i386-dvd1.iso and sees no partition at all on the 7.2 disk.
Boot back to 7.2 and everything works fine, so system has no hardware
problem.

Boot 8.0-BETA3-i386-dvd1.iso again, still sees no partition, so
reconfigured partition with
autoconfigure - A

512M for / on /dev/ad0s1a
about 4G for swap on /dev/ad0s1b
about 2.2G on /var
512M for /tmp
rest spaces are for /usr

After commit, installation says --

Unable to find device node for /dev/ad0s1b in /dev
The Creation of file system will abort.
OK
[Press enter or space]

Hit CR and see some other errors, then back to installation menu.
Reboot the system, 7.2 is gone.

Download 8.0-BETA4-i386-dvd1.iso and burned another DVD, also did verify
between DVD and ISO for OK.
Run installation from Beta4 DVD, the same problem presents again.

If my memory is correct, either 8.0-Beta1 or one version earlier than it
was working on this machine.

Is anything changed that requires different installation procedure? or
is this a bug introduced recently?

-Jin


From roberthuff at rcn.com  Mon Sep 14 02:41:43 2009
From: roberthuff at rcn.com (Robert Huff)
Date: Mon Sep 14 02:41:49 2009
Subject: 8.0-Beta installation problem -- Unable to find /dev/ad0s1b
In-Reply-To: <4AAD9B71.3080703@sbcglobal.net>
References: <4AAD9B71.3080703@sbcglobal.net>
Message-ID: <19117.42696.888649.236347@jerusalem.litteratus.org>


Jin Guojun writes:

>  Tried to install from both 8.0-BETA{3, 4}-i386-dvd1.iso on a
>  Phenom 9600 system and having some disk problems.
>  
>  After commit, installation says --
>  
>  Unable to find device node for /dev/ad0s1b in /dev
>  The Creation of file system will abort.
>  OK
>  [Press enter or space]

	Look at the archives of current@ within the last three weeks.
I (and I believe at least one other person) had what seems like the
same problem and found a work-around.


				Robert Huff
From jguojun at sbcglobal.net  Mon Sep 14 03:47:41 2009
From: jguojun at sbcglobal.net (Jin Guojun)
Date: Mon Sep 14 03:47:49 2009
Subject: 8.0-Beta installation problem -- Unable to find /dev/ad0s1b
In-Reply-To: <19117.42696.888649.236347@jerusalem.litteratus.org>
Message-ID: <582270.67371.qm@web82203.mail.mud.yahoo.com>

Did not find anything from current, but found the same problem has been reported in earlier releases in those archives, and the latest was May 2009:

    * Rambler: FreeBSD mail archives search
    * MarkMail: FreeBSD mail archives search

Two directly related to 8.0 was on Mar 25, 2009. One failure was due to the FreeBSD is on the second slice, which sound liek a bug; but the other is not clear.

In my case, FreeBSD is on the first slice, so it is not the same problem.

>From 8.0-Beta{3, 4} cannot recognize FreeBSD 7.2 partition tables, it looks like that there is a disklable and/or partition related problem in 8.0-Beta.

--- On Mon, 9/14/09, Robert Huff <roberthuff@rcn.com> wrote:

> From: Robert Huff <roberthuff@rcn.com>
> Subject: 8.0-Beta installation problem -- Unable to find /dev/ad0s1b
> To: "Jin Guojun" <jguojun@sbcglobal.net>
> Cc: questions@freebsd.org, freebsd-stable@freebsd.org
> Date: Monday, September 14, 2009, 2:13 AM
> 
> Jin Guojun writes:
> 
> >  Tried to install from both 8.0-BETA{3, 4}-i386-dvd1.iso on a
> >  Phenom 9600 system and having some disk problems.

The system is running 6.x and/or 7.2 FreeBSD (on different drives).

Disconnected rest drives and only left 7.2 drive in.
ad0: 76319MB <Seagate ST3802110A 3.AAJ> at ata0-master UDMA100

Boot 8.0-BETA3-i386-dvd1.iso and sees no partition at all on the 7.2 disk.
Boot back to 7.2 and everything works fine, so system has no hardware
problem.

Boot 8.0-BETA3-i386-dvd1.iso again, still sees no partition, so
reconfigured partition with
autoconfigure - A

512M for / on /dev/ad0s1a
about 4G for swap on /dev/ad0s1b
about 2.2G on /var
512M for /tmp
rest spaces are for /usr 

> >  After commit, installation says --
> >  
> >  Unable to find device node for /dev/ad0s1b in /dev
> >  The Creation of file system will abort.
> >  OK
> >  [Press enter or space]
> 
>     Look at the archives of current@ within
> the last three weeks.
> I (and I believe at least one other person) had what seems
> like the
> same problem and found a work-around.
> 
> 
>            
>     Robert Huff
> 
From roberthuff at rcn.com  Mon Sep 14 03:49:22 2009
From: roberthuff at rcn.com (Robert Huff)
Date: Mon Sep 14 03:49:34 2009
Subject: 8.0-Beta installation problem -- Unable to find /dev/ad0s1b
In-Reply-To: <582270.67371.qm@web82203.mail.mud.yahoo.com>
References: <19117.42696.888649.236347@jerusalem.litteratus.org>
	<582270.67371.qm@web82203.mail.mud.yahoo.com>
Message-ID: <19117.48448.269298.484728@jerusalem.litteratus.org>


Jin Guojun writes:

>  Did not find anything from current, but found the same problem
>  has been reported in earlier releases in those archives, and the
>  latest was May 2009:

	Try this (for the fix) :

http://lists.freebsd.org/pipermail/freebsd-current/2009-September/011254.html



					Robert Huff

From lists at c0mplx.org  Mon Sep 14 05:55:03 2009
From: lists at c0mplx.org (Kurt Jaeger)
Date: Mon Sep 14 05:55:10 2009
Subject: 8.0-Beta installation problem -- Unable to find /dev/ad0s1b
In-Reply-To: <19117.48448.269298.484728@jerusalem.litteratus.org>
References: <19117.42696.888649.236347@jerusalem.litteratus.org>
	<582270.67371.qm@web82203.mail.mud.yahoo.com>
	<19117.48448.269298.484728@jerusalem.litteratus.org>
Message-ID: <20090914055501.GM48206@home.opsec.eu>

Hello,

> >  Did not find anything from current, but found the same problem
> >  has been reported in earlier releases in those archives, and the
> >  latest was May 2009:
> 
> 	Try this (for the fix) :
> 
> http://lists.freebsd.org/pipermail/freebsd-current/2009-September/011254.html

I had the same problem with beta4:

http://lists.freebsd.org/pipermail/freebsd-current/2009-September/011470.html

and I tried this fix, and it did not solve the problem.

It might be related with the number of slices and partitions one
is creating ? I'll try this again today.

-- 
pi@opsec.eu            +49 171 3101372                        11 years to go !
From ivoras at freebsd.org  Mon Sep 14 10:22:03 2009
From: ivoras at freebsd.org (Ivan Voras)
Date: Mon Sep 14 10:22:11 2009
Subject: FreeBSD 8.0-BETA4 IBM ServerRaid 8k issues
In-Reply-To: <4AAA741A.7040105@eng.auth.gr>
References: <4AA90D88.4010004@eng.auth.gr>	<9e20d71e0909110601kaa87f2em2e4e618b8feb306b@mail.gmail.com>
	<4AAA741A.7040105@eng.auth.gr>
Message-ID: <h8l5fe$tn5$1@ger.gmane.org>

George Mamalakis wrote:
> Artis, and the rest of the guys, thank you all for your answers.
> 
> Ivan, I was thinking of using one of the techniques you mention (create 
> two volumes, install fbsd on one of them, and use GTP on the second 
> drive), but I was wondering if there would be any "incompatibility" 
> issues with tools like df, etc.

No, once you create a parition of large size, the system will "just work".

From attilio at freebsd.org  Mon Sep 14 12:43:07 2009
From: attilio at freebsd.org (Attilio Rao)
Date: Mon Sep 14 12:43:13 2009
Subject: 7.2-release/amd64: panic, spin lock held too long
In-Reply-To: <4A67C9C7.6090301@gmail.com>
References: <KN4BGI$40ABF3E58EAD1201403C9DA561E2402F@libero.it>
	<4A667469.1080805@gmail.com>
	<3bbf2fe10907220930y27b5da04sd0a71d57b6a9d191@mail.gmail.com>
	<4A67C9C7.6090301@gmail.com>
Message-ID: <3bbf2fe10909140543w56783cc8of964f464d9314db2@mail.gmail.com>

2009/7/23 C. C. Tang <hiyorin@gmail.com>:
> Attilio Rao wrote:
>>
>> 2009/7/22 C. C. Tang <hiyorin@gmail.com>:
>>>>
>>>> Could that one (on i386) be related?
>>>> http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/134584
>>>>
>>> I have no idea about it but I can tell the difference...
>>> My machine panic randomly rather than on shutdown and I remembered that
>>> it
>>> failed to write core dump. It also failed to reboot automatically..
>>
>> Is your problem on -CURRENT and amd64?
>> At some point there has been a problem with PAT support (and
>> tlb_shootdowns() could lead to a livelock hanging forever, leading to
>> such a bug) but I expect it is fixed now.
>> Can you try with a fresh new -CURRENT if any?
>
> My problem is on i386 version of 7.2-RELEASE-p2 on Intel Atom 330 CPU.
> And my system just panic randomly with "spin lock held too long".
> It didn't panic at reboot or shutdown so I think it the problem is somewhat
> different from that mentioned by Barbara's PR?
>
> Anyway I disabled powerd and it seems become stable now.
>
> And I am sorry that my system has been put into service so it would be hard
> for me to switch to -CURRENT...  :(

Can you re-enable powerd and try the attached patch?:
http://www.freebsd.org/~attilio/sched_ule.diff

The patch is against STABLE_7, but I think HEAD has the same bug.
Please try it and report to me.

Attilio


-- 
Peace can only be achieved by understanding - A. Einstein
From dan.naumov at gmail.com  Mon Sep 14 12:47:18 2009
From: dan.naumov at gmail.com (Dan Naumov)
Date: Mon Sep 14 12:47:25 2009
Subject: 7.2-release/amd64: panic, spin lock held too long
In-Reply-To: <3bbf2fe10909140543w56783cc8of964f464d9314db2@mail.gmail.com>
References: <KN4BGI$40ABF3E58EAD1201403C9DA561E2402F@libero.it>
	<4A667469.1080805@gmail.com>
	<3bbf2fe10907220930y27b5da04sd0a71d57b6a9d191@mail.gmail.com>
	<4A67C9C7.6090301@gmail.com>
	<3bbf2fe10909140543w56783cc8of964f464d9314db2@mail.gmail.com>
Message-ID: <cf9b1ee00909140547j67ed0fc6sc15fa238a8efbfc8@mail.gmail.com>

On Mon, Sep 14, 2009 at 3:43 PM, Attilio Rao <attilio@freebsd.org> wrote:
> 2009/7/23 C. C. Tang <hiyorin@gmail.com>:
>> Attilio Rao wrote:
>>>
>>> 2009/7/22 C. C. Tang <hiyorin@gmail.com>:
>>>>>
>>>>> Could that one (on i386) be related?
>>>>> http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/134584
>>>>>
>>>> I have no idea about it but I can tell the difference...
>>>> My machine panic randomly rather than on shutdown and I remembered that
>>>> it
>>>> failed to write core dump. It also failed to reboot automatically..
>>>
>>> Is your problem on -CURRENT and amd64?
>>> At some point there has been a problem with PAT support (and
>>> tlb_shootdowns() could lead to a livelock hanging forever, leading to
>>> such a bug) but I expect it is fixed now.
>>> Can you try with a fresh new -CURRENT if any?
>>
>> My problem is on i386 version of 7.2-RELEASE-p2 on Intel Atom 330 CPU.
>> And my system just panic randomly with "spin lock held too long".
>> It didn't panic at reboot or shutdown so I think it the problem is somewhat
>> different from that mentioned by Barbara's PR?
>>
>> Anyway I disabled powerd and it seems become stable now.
>>
>> And I am sorry that my system has been put into service so it would be hard
>> for me to switch to -CURRENT... ?:(
>
> Can you re-enable powerd and try the attached patch?:
> http://www.freebsd.org/~attilio/sched_ule.diff
>
> The patch is against STABLE_7, but I think HEAD has the same bug.
> Please try it and report to me.
>
> Attilio

Sadly I can't test this, I had to put the machine into production
using another OS. I hope the patch fixes the issue, so I can at some
point evaluate using FreeBSD on this hardware again.

- Dan
From jhb at freebsd.org  Mon Sep 14 13:13:29 2009
From: jhb at freebsd.org (John Baldwin)
Date: Mon Sep 14 13:13:53 2009
Subject: How to enable CPU turbo mode on FreeBSD?
In-Reply-To: <4AAA70C5.5090408@pldrouin.net>
References: <4AA9A07C.4050200@pldrouin.net>
	<200909111105.01619.jhb@freebsd.org>
	<4AAA70C5.5090408@pldrouin.net>
Message-ID: <200909140836.31559.jhb@freebsd.org>

On Friday 11 September 2009 11:46:13 am Pierre-Luc Drouin wrote:
> John Baldwin wrote:
> > On Thursday 10 September 2009 8:57:32 pm Pierre-Luc Drouin wrote:
> >   
> >> Hi,
> >>
> >> I have an overclocked i7 920 CPU for which I have enabled Turbo Mode in 
> >> the BIOS (21x multiplier). The base clock is set at 190 MHz, so the CPU 
> >> frequency with Turbo mode activated should be 3990 MHz. However the 
> >> maximum value FreeBSD amd64 shows for the CPU frequency in dmesg and 
> >> sysctl is 3790 MHz. How can I enable the Turbo Mode?
> >>
> >> CPU: Intel(R) Core(TM) i7 CPU         920  @ 2.67GHz (3790.52-MHz 
> >> K8-class CPU)
> >>
> >> machdep.acpi_timer_freq: 3579545
> >> machdep.tsc_freq: 3790522507
> >> machdep.i8254_freq: 1193182
> >> dev.cpu.0.freq: 349
> >> dev.cpu.0.freq_levels: 2793/130000 2443/113750 2094/97500 1745/81250 
> >> 1396/65000 1047/48750 698/32500 349/16250
> >>     
> >
> > You have to enable C2/C3 sleep states (possibly in your BIOS).  However, 
> > FreeBD doesn't currently handle this but so well since that will probably 
> > turn off the local APIC timer interrupt when the CPU is idle causing 
FreeBSD 
> > to miss clock interrupts.
> >
> >   
> Sorry I am not sure exactly what you are referring to. Do you mean that 
> I need to enable C2/C3 states in order to have the correct max CPU freq 
> value displayed at boot time/in sysctl, or you mean that I need these 
> states in order to be able to use the Turbo Mode at all? Right now in 
> the BIOS I had the following features disabled to test the overclocking 
> (I was following what is recommended to do for Windows users to run 
> stress tests):
> 
> -Intel SpeedStep: Use this function to enable the Intel SpeedStep 
> technology (EIST)
> -CxE Function: This function allows you to select the lowest C state 
> supported according as CPU and MB. The options are Auto, Disabled, C1, 
> C1E, C3 and C6

You need to have C2/C3 enabled for it to work at all, at least on Nehalem 
processors.

-- 
John Baldwin
From jhb at freebsd.org  Mon Sep 14 13:13:31 2009
From: jhb at freebsd.org (John Baldwin)
Date: Mon Sep 14 13:13:55 2009
Subject: Kernel panic in ulpt
In-Reply-To: <B41B0A0F-63D7-42DD-B095-504E8A572B34@solfertje.student.utwente.nl>
References: <B41B0A0F-63D7-42DD-B095-504E8A572B34@solfertje.student.utwente.nl>
Message-ID: <200909140841.27844.jhb@freebsd.org>

On Friday 11 September 2009 12:18:39 pm Alban Hertroys wrote:
> Hello,
> 
> I just got a kernel panic on a FreeBSD 7.2 STABLE after a print job  
> finished on ulpt. The kgdb output (ran in script) is attached. I'll  
> keep the vmcore around in case anyone needs more info. Shout if you  
> need more info.

In ulptclose() in sys/dev/usb/ulpt.c try changing the callout_stop() to a 
callout_drain().  Have you been able to reproduce this?

-- 
John Baldwin
From gerrit at pmp.uni-hannover.de  Mon Sep 14 14:53:07 2009
From: gerrit at pmp.uni-hannover.de (Gerrit =?ISO-8859-1?Q?K=FChn?=)
Date: Mon Sep 14 14:53:14 2009
Subject: Linux/KDE and NFS locking on 7-stable
Message-ID: <20090914165304.09540eb3.gerrit@pmp.uni-hannover.de>

Hi all,

I upgraded a FreeBSD fileserver last week from 7.0-stable to 7.2-stable
and experience some weird problems now with Linux NFS clients.
The Linux Clients mount their home directories via nfs. I usually use
"nolock" on the client side, because file locking was always troublesome
in the past. On the Clients the users run kde 3.5 or 4.2.
After the update of the server kde 3.5 quit starting up (after logging
in with kdm) on the spalsh screen and comes up with some kind of I/O error
when writing to the home dir. At the same time the server complains about

kernel: NLM: failed to contact remote rpcbind, stat = 5, port = 28416

Any other window manager (xfce, icewm, mwm, twm) seems to work fine.
Playing around with locking, udp/tcp, rebooting some times then somehow
magically made it work with kde 3.5 again (although I am using the same
mount options in the and as I used before):

mclane:/tank/home/gco  /tank/home/ghf nfs nfsvers=3,rw,nolock,nordirplus 0
0

Turning locking on definitely does not work (tried it three times).
rcp.lockd and rpc.statd are running on the server side, no further tuning
done there.

KDE 4.2 seems to have better, I have been able to get it working with
locking turned on (but it refused to work without locking with the same
errors as described above for kde 3.5).

I find the whole situation a bit unattractive. Can anybody here give me a
hint which combination of mount options should work for a FreeBSD Server
running 7.2-stable and Linux clients running 2.6.29 and KDE3/4? I am not
that much into performance here, I want a stable working solution. And why,
after all, is KDE so picky about locking and nfs homedirs anyway? All
other environments appear not to show these problems.


cu
  Gerrit
From jguojun at sbcglobal.net  Mon Sep 14 16:56:39 2009
From: jguojun at sbcglobal.net (Jin Guojun)
Date: Mon Sep 14 16:56:53 2009
Subject: 8.0-Beta installation problem -- Unable to find /dev/ad0s1b
In-Reply-To: <19117.48448.269298.484728@jerusalem.litteratus.org>
Message-ID: <947305.17407.qm@web82203.mail.mud.yahoo.com>

It seems that disklabel is the problem spot.

Use 8.0 Partition menu to allocate 2 slices (partitions) 20GB for S1 and rest for S2,
then install 8.0-Beta4 on S1.
W command in slice (Partition) menu succeed with bootloader manager installing option (Choose FreeBSD),
but W command in Label menu had the same error -- Unable to find device node ...

After quite installationm and restart the system, the bootloader is still show old
partitions (S1 DOS, S2/S3 7.2).

Boot 8.0-Beta4 DVD again, and Partition menu shows no partition at all (no slice allocated).
This indicates that disklabel did not correctly write disk partition information on to the dirve.


--- On Mon, 9/14/09, Robert Huff <roberthuff@rcn.com> wrote:

> From: Robert Huff <roberthuff@rcn.com>
> Subject: Re: 8.0-Beta installation problem -- Unable to find /dev/ad0s1b
> To: "Jin Guojun" <jguojun@sbcglobal.net>
> Cc: "Robert Huff" <roberthuff@rcn.com>, current@freebsd.org, bugs@freebsd.org, freebsd-stable@freebsd.org
> Date: Monday, September 14, 2009, 3:49 AM
> 
> Jin Guojun writes:
> 
> >  Did not find anything from current, but found
> the same problem
> >  has been reported in earlier releases in those
> archives, and the
> >  latest was May 2009:
> 
>     Try this (for the fix) :
> 
> http://lists.freebsd.org/pipermail/freebsd-current/2009-September/011254.html
> 
> 
> 
>            
>         Robert Huff
> 
> 
From thierry at FreeBSD.org  Mon Sep 14 18:45:20 2009
From: thierry at FreeBSD.org (Thierry Thomas)
Date: Mon Sep 14 18:45:34 2009
Subject: 8.0-Beta installation problem -- Unable to find /dev/ad0s1b
In-Reply-To: <947305.17407.qm@web82203.mail.mud.yahoo.com>
References: <19117.48448.269298.484728@jerusalem.litteratus.org>
	<947305.17407.qm@web82203.mail.mud.yahoo.com>
Message-ID: <20090914184507.GB5360@graf.pompo.net>

Le Lun 14 sep 09 ? 18:56:38 +0200, Jin Guojun <jguojun@sbcglobal.net>
 ?crivait?:
> It seems that disklabel is the problem spot.

Hello,

I encountered such a problem too; was your disk ad0 installed as
"dangerously dedicated"?

Regards,
-- 
Th. Thomas.
From jguojun at sbcglobal.net  Mon Sep 14 21:08:55 2009
From: jguojun at sbcglobal.net (Jin Guojun)
Date: Mon Sep 14 21:09:02 2009
Subject: 8.0-Beta installation problem -- Unable to find /dev/ad0s1b
In-Reply-To: <20090914184507.GB5360@graf.pompo.net>
Message-ID: <500794.80873.qm@web82208.mail.mud.yahoo.com>

I do not enve know how to make "dangerously dedicated" disk, and the 8.0 may do this sliently.

ad0 had three DOS partitions (slices),
S1 for DOS
S2 for FreeBSD 7.2
S3 for another FreeBSD

When boot to 8.0-Beta{3, 4}, 8.0 sees not partition, which means 8.0 looked at a wrong location for partition table.
After did partition (slices S1 for FreebSD and S2 for nothing) and 
Label (Unix partitions, failed to find device node /dev/ad0s1b in /dev),
content of 7.2 is gone.

But, the original partitions are still in the MBR (S1 for DOS, and S2 and S3 for FreeBSD).


--- On Mon, 9/14/09, Thierry Thomas <thierry@FreeBSD.org> wrote:

> From: Thierry Thomas <thierry@FreeBSD.org>
> Subject: Re: 8.0-Beta installation problem -- Unable to find /dev/ad0s1b
> To: "Jin Guojun" <jguojun@sbcglobal.net>
> Cc: bugs@freebsd.org, freebsd-stable@freebsd.org, current@freebsd.org
> Date: Monday, September 14, 2009, 6:45 PM
> Le Lun 14 sep 09 ? 18:56:38 +0200,
> Jin Guojun <jguojun@sbcglobal.net>
>  ?crivait :
> > It seems that disklabel is the problem spot.
> 
> Hello,
> 
> I encountered such a problem too; was your disk ad0
> installed as
> "dangerously dedicated"?
> 
> Regards,
> -- 
> Th. Thomas.
> 
From matthew.fleming at isilon.com  Mon Sep 14 21:28:56 2009
From: matthew.fleming at isilon.com (Matthew Fleming)
Date: Mon Sep 14 21:29:03 2009
Subject: cxgb LOR
Message-ID: <06D5F9F6F655AD4C92E28B662F7F853E030C6646@seaxch09.desktop.isilon.com>

We got a cxgb LOR report of:

1st 0xffffff8001e37be0 vlan_global (vlan_global) @
/build/mnt/src/sys/modules/if_vlan/../../net/if_vlan.c:1310
 2nd 0xffffff80010892f0 cxgb port lock (cxgb port lock) @
/build/mnt/src/sys/modules/cxgb/../../dev/cxgb/cxgb_main.c:1956
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2a
witness_checkorder() at witness_checkorder+0x9e2
_sx_xlock() at _sx_xlock+0x55
cxgb_ioctl() at cxgb_ioctl+0x1e8
vlan_ioctl() at vlan_ioctl+0x359
ifhwioctl() at ifhwioctl+0xb1
ifioctl() at ifioctl+0xb1
kern_ioctl() at kern_ioctl+0xa3
ioctl() at ioctl+0xf1
freebsd32_ioctl() at freebsd32_ioctl+0x13e
isi_syscall() at isi_syscall+0x94
ia32_syscall() at ia32_syscall+0x1a3
Xint0x80_syscall() at Xint0x80_syscall+0x60
--- syscall (54, FreeBSD ELF32, freebsd32_ioctl), rip = 0x2868db1b, rsp
= 0xffffd4bc, rbp = 0xffffda38 ---


So we tried changing cxgb to not USE_SX.  This resulted in a different
LOR:

lock order reversal: (sleepable after non-sleepable)
 1st 0xffffff8000f9d508 cxgb controller lock 0 (cxgb controller lock 0)
@
/build/mnt/src/sys/modules/cxgb/cxgb/../../../dev/cxgb/cxgb_main.c:1889
 2nd 0xffffffff806064e0 ACPI root bus (ACPI root bus) @
/build/mnt/src/sys/dev/acpica/acpi.c:1040
KDB: stack backtrace:
[ffffffff8018e9fa] db_trace_self_wrapper+0x2a
[ffffffff80298e89] witness_checkorder+0x719
[ffffffff8025bf75] _sx_xlock+0x55
[ffffffff8019678a] acpi_alloc_resource+0x9a
[ffffffff80281714] resource_list_alloc+0x184
[ffffffff801d9f98] pci_alloc_resource+0x158
[ffffffff802814b9] bus_alloc_resource+0x89
[ffffffff81804201] cxgb_setup_interrupts+0x51
[ffffffff81807f33] cxgb_up+0xa3
[ffffffff818083c0] cxgb_init_locked+0x1b0
[ffffffff81808539] cxgb_init+0x39
[ffffffff81808758] cxgb_ioctl+0x1f8
[ffffffff8031e9e1] ifhwioctl+0xb1
[ffffffff8031f720] ifioctl+0xb0
[ffffffff8029a873] kern_ioctl+0xa3
[ffffffff8029aad1] ioctl+0xf1
[ffffffff8041eb93] freebsd32_ioctl+0xb3
[ffffffff8025d963] isi_syscall+0x83
[ffffffff8041de63] ia32_syscall+0x1a3
[ffffffff803efc60] Xint0x80_syscall+0x60
--- syscall (54, FreeBSD ELF32, freebsd32_ioctl), rip = 0x2826ea67, rsp
= 0xffffd8ac, rbp = 0xffffd928 ---

(we modified cxgb_ioctl to call cxgb_init because otherwise the cxgb
interface would require an ifconfig up before it detected a link, which
was different behaviour from the em driver.  Since the locks in question
are acquired inside cxgb_init() I don't think the rest of the stack is
relevant, but network stack isn't my area of expertise).

So it seems that with cxgb we're damned if we do, damned if we don't.
Any advice on which LOR is "worse" or if one is harmless, or how to make
it go away?

Note also that if cxgb uses a mtx then it will do malloc while holding
the mtx in this stack:

[ffffffff803cc58a] uma_zalloc_arg+0x2da
[ffffffff80241ef9] malloc+0x89
[ffffffff8023115f] intr_event_add_handler+0x5f
[ffffffff803f26d2] intr_add_handler+0x72
[ffffffff801dc171] pci_setup_intr+0x41
[ffffffff801dc171] pci_setup_intr+0x41
[ffffffff802807e6] bus_setup_intr+0x96
[ffffffff8180423c] cxgb_setup_interrupts+0x8c
[ffffffff81807f33] cxgb_up+0xa3
[ffffffff818083c0] cxgb_init_locked+0x1b0
[ffffffff81808539] cxgb_init+0x39

Thanks,
matthew
From thierry at FreeBSD.org  Mon Sep 14 22:07:03 2009
From: thierry at FreeBSD.org (Thierry Thomas)
Date: Mon Sep 14 22:07:16 2009
Subject: 8.0-Beta installation problem -- Unable to find /dev/ad0s1b
In-Reply-To: <500794.80873.qm@web82208.mail.mud.yahoo.com>
References: <20090914184507.GB5360@graf.pompo.net>
	<500794.80873.qm@web82208.mail.mud.yahoo.com>
Message-ID: <20090914220651.GF5360@graf.pompo.net>

Le Lun 14 sep 09 ? 23:08:53 +0200, Jin Guojun <jguojun@sbcglobal.net>
 ?crivait?:
> I do not enve know how to make "dangerously dedicated" disk, and the
> 8.0 may do this sliently.

No, I don't think so! But such a problem may arise if your disk had been
installed as "dangerously dedicated" in a former version. Unfortunately,
previous versions of sysinstall have created uncorrect labels, and the
new gpart in 8.0 does not see them.

In that case, you have to boot kernel.old and wipe out the bad label. If
you reboot with a 7.2 kernel, can you see your missing partitions?
-- 
Th. Thomas.
From nparhar at gmail.com  Mon Sep 14 22:08:52 2009
From: nparhar at gmail.com (Navdeep Parhar)
Date: Mon Sep 14 22:09:03 2009
Subject: cxgb LOR
In-Reply-To: <06D5F9F6F655AD4C92E28B662F7F853E030C6646@seaxch09.desktop.isilon.com>
References: <06D5F9F6F655AD4C92E28B662F7F853E030C6646@seaxch09.desktop.isilon.com>
Message-ID: <d04e16b70909141447k2eb7f806oaa6d882059b9990e@mail.gmail.com>

A lot of these LORs were fixed in cxgb in FreeBSD 8.  You can look at
cxgb_main.c in 8 for details.  I'll also try and figure out if those
changes are easily MFC'able.

Regards,
Navdeep

On Mon, Sep 14, 2009 at 2:29 PM, Matthew Fleming
<matthew.fleming@isilon.com> wrote:
> We got a cxgb LOR report of:
>
> 1st 0xffffff8001e37be0 vlan_global (vlan_global) @
> /build/mnt/src/sys/modules/if_vlan/../../net/if_vlan.c:1310
> ?2nd 0xffffff80010892f0 cxgb port lock (cxgb port lock) @
> /build/mnt/src/sys/modules/cxgb/../../dev/cxgb/cxgb_main.c:1956
> KDB: stack backtrace:
> db_trace_self_wrapper() at db_trace_self_wrapper+0x2a
> witness_checkorder() at witness_checkorder+0x9e2
> _sx_xlock() at _sx_xlock+0x55
> cxgb_ioctl() at cxgb_ioctl+0x1e8
> vlan_ioctl() at vlan_ioctl+0x359
> ifhwioctl() at ifhwioctl+0xb1
> ifioctl() at ifioctl+0xb1
> kern_ioctl() at kern_ioctl+0xa3
> ioctl() at ioctl+0xf1
> freebsd32_ioctl() at freebsd32_ioctl+0x13e
> isi_syscall() at isi_syscall+0x94
> ia32_syscall() at ia32_syscall+0x1a3
> Xint0x80_syscall() at Xint0x80_syscall+0x60
> --- syscall (54, FreeBSD ELF32, freebsd32_ioctl), rip = 0x2868db1b, rsp
> = 0xffffd4bc, rbp = 0xffffda38 ---
>
>
> So we tried changing cxgb to not USE_SX. ?This resulted in a different
> LOR:
>
> lock order reversal: (sleepable after non-sleepable)
> ?1st 0xffffff8000f9d508 cxgb controller lock 0 (cxgb controller lock 0)
> @
> /build/mnt/src/sys/modules/cxgb/cxgb/../../../dev/cxgb/cxgb_main.c:1889
> ?2nd 0xffffffff806064e0 ACPI root bus (ACPI root bus) @
> /build/mnt/src/sys/dev/acpica/acpi.c:1040
> KDB: stack backtrace:
> [ffffffff8018e9fa] db_trace_self_wrapper+0x2a
> [ffffffff80298e89] witness_checkorder+0x719
> [ffffffff8025bf75] _sx_xlock+0x55
> [ffffffff8019678a] acpi_alloc_resource+0x9a
> [ffffffff80281714] resource_list_alloc+0x184
> [ffffffff801d9f98] pci_alloc_resource+0x158
> [ffffffff802814b9] bus_alloc_resource+0x89
> [ffffffff81804201] cxgb_setup_interrupts+0x51
> [ffffffff81807f33] cxgb_up+0xa3
> [ffffffff818083c0] cxgb_init_locked+0x1b0
> [ffffffff81808539] cxgb_init+0x39
> [ffffffff81808758] cxgb_ioctl+0x1f8
> [ffffffff8031e9e1] ifhwioctl+0xb1
> [ffffffff8031f720] ifioctl+0xb0
> [ffffffff8029a873] kern_ioctl+0xa3
> [ffffffff8029aad1] ioctl+0xf1
> [ffffffff8041eb93] freebsd32_ioctl+0xb3
> [ffffffff8025d963] isi_syscall+0x83
> [ffffffff8041de63] ia32_syscall+0x1a3
> [ffffffff803efc60] Xint0x80_syscall+0x60
> --- syscall (54, FreeBSD ELF32, freebsd32_ioctl), rip = 0x2826ea67, rsp
> = 0xffffd8ac, rbp = 0xffffd928 ---
>
> (we modified cxgb_ioctl to call cxgb_init because otherwise the cxgb
> interface would require an ifconfig up before it detected a link, which
> was different behaviour from the em driver. ?Since the locks in question
> are acquired inside cxgb_init() I don't think the rest of the stack is
> relevant, but network stack isn't my area of expertise).
>
> So it seems that with cxgb we're damned if we do, damned if we don't.
> Any advice on which LOR is "worse" or if one is harmless, or how to make
> it go away?
>
> Note also that if cxgb uses a mtx then it will do malloc while holding
> the mtx in this stack:
>
> [ffffffff803cc58a] uma_zalloc_arg+0x2da
> [ffffffff80241ef9] malloc+0x89
> [ffffffff8023115f] intr_event_add_handler+0x5f
> [ffffffff803f26d2] intr_add_handler+0x72
> [ffffffff801dc171] pci_setup_intr+0x41
> [ffffffff801dc171] pci_setup_intr+0x41
> [ffffffff802807e6] bus_setup_intr+0x96
> [ffffffff8180423c] cxgb_setup_interrupts+0x8c
> [ffffffff81807f33] cxgb_up+0xa3
> [ffffffff818083c0] cxgb_init_locked+0x1b0
> [ffffffff81808539] cxgb_init+0x39
>
> Thanks,
> matthew
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
>
From freebsd at edvax.de  Mon Sep 14 22:12:03 2009
From: freebsd at edvax.de (Polytropon)
Date: Mon Sep 14 22:12:15 2009
Subject: 8.0-Beta installation problem -- Unable to find /dev/ad0s1b
In-Reply-To: <500794.80873.qm@web82208.mail.mud.yahoo.com>
References: <20090914184507.GB5360@graf.pompo.net>
	<500794.80873.qm@web82208.mail.mud.yahoo.com>
Message-ID: <20090914235257.f0895686.freebsd@edvax.de>

On Mon, 14 Sep 2009 14:08:53 -0700 (PDT), Jin Guojun <jguojun@sbcglobal.net> wrote:
> I do not enve know how to make "dangerously dedicated" disk,
> and the 8.0 may do this sliently.

This term refers to a disk where no "DOS primary partition",
i. e. a slice, has been created. Usually, for a disk with
only FreeBSD on it, you first take a disk

	/dev/ad0

create a slice

	/dev/ad0s1

and put partitions into it (or just one partition), like

	/dev/ad0s1a = /
	/dev/ad0s1b = swap
	/dev/ad0s1d = /tmo
	/dev/ad0s1e = /var
	/dev/ad0s1f = /usr
	/dev/ad0s1g = /home

or something similar. In "dangerously dedicated" mode, you
omit the slice creation and create the partitions on the
disk device /dev/ad0, so you end up with

	/dev/ad0a = /
	/dev/ad0b = swap
	/dev/ad0d = /tmo
	/dev/ad0e = /var
	/dev/ad0f = /usr
	/dev/ad0g = /home

Using such mode is common for data disks, but not for disks
you boot from.


	
> ad0 had three DOS partitions (slices),
> S1 for DOS
> S2 for FreeBSD 7.2
> S3 for another FreeBSD
> 
> When boot to 8.0-Beta{3, 4}, 8.0 sees not partition, which means
> 8.0 looked at a wrong location for partition table.

What does the "fdisk" command report?



> After did partition (slices S1 for FreebSD and S2 for nothing) and 
> Label (Unix partitions, failed to find device node /dev/ad0s1b in /dev),
> content of 7.2 is gone.

Seems to be correct up to here; /dev/ad0s1b refers to the swap
partition.



> But, the original partitions are still in the MBR (S1 for DOS, and
> S2 and S3 for FreeBSD).

So an update of the MBR hasn't taken place?




-- 
Polytropon
Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...
From gphoto6 at gmail.com  Tue Sep 15 06:21:36 2009
From: gphoto6 at gmail.com (Tim Chen)
Date: Tue Sep 15 06:21:43 2009
Subject: panic: UMA: page_free used with invalid flags 4
Message-ID: <1f51039c0909142251l2155c733x929a6a9595bcff7f@mail.gmail.com>

Hello,
My server was using FreeBSD-7-Stable and performing
a mail server. Software I used is postfix 2.6.3
and dovecot 1.2.4.

The hardware is IBM blade server HS-21
CPU: dual Intel E5335 @ 2.00GHz
MEM: 3G
HD: onboard LSI RAID controller with 2 73G SAS HD.
(mpt0: <LSILogic SAS/SATA Adapter>)
The system is very stable until last week. After
csup the FreeBSD-7-STABLE source to around 2009/09/10,
it will halt randomly around every several hours. The
error message I saw  on console was the following:

panic: UMA: page_free used with invalid flags 4
cpuid = 0
Uptime: 3h1m14s
Physical memory: 3064MB
Dumping 1544MB: 1529 1513 1497....................

Reading freebsd-stable mailing shows there is some
vm related modfication during the first week of Sep.
(the panic: vm_phys_paddr_to_vm_page: paddr 0x series)
So, I csup my src back to 2009/09/01, the problem
disappeared, and system comes back with stable state.

Today, I csup my src to latest 7-STABLE (2009/09/15)
and problem comes again. It seems the problem is still
there and not be solved yet.

Would you please help to fix it?

Thanks very much.

Sincerely,
Tim Chen
From jguojun at sbcglobal.net  Tue Sep 15 06:25:22 2009
From: jguojun at sbcglobal.net (Jin Guojun)
Date: Tue Sep 15 06:25:34 2009
Subject: 8.0-Beta installation problem -- Unable to find /dev/ad0s1b
In-Reply-To: <20090914220651.GF5360@graf.pompo.net>
Message-ID: <386709.24333.qm@web82208.mail.mud.yahoo.com>

dd 1m zero on the drive and rerun the 8.0Beta4 DVD. Created two slices S1 and S2,
and did auto labling (unix partiton) on S1, hit W, the problem persists.

Boot system with freeBSD 6.4, and 6.4 sees two slices (MBR partitions) S1 and S2, 
but no any Unix partition (ad0s1a, ad0s1b etc) on S1.

Boot back to 8.0-Beta4, it still sees not Slice created. 
At this point, it is obviously that 8.0 looks in a wrong MBR location --
8.0 created slices can be seen by 6.4 but not 8.0 itself.

--- On Mon, 9/14/09, Thierry Thomas <thierry@FreeBSD.org> wrote:

> From: Thierry Thomas <thierry@FreeBSD.org>
> Subject: Re: 8.0-Beta installation problem -- Unable to find /dev/ad0s1b
> To: "Jin Guojun" <jguojun@sbcglobal.net>
> Cc: bugs@freebsd.org, freebsd-stable@freebsd.org, current@freebsd.org
> Date: Monday, September 14, 2009, 10:06 PM
> Le Lun 14 sep 09 ? 23:08:53 +0200,
> Jin Guojun <jguojun@sbcglobal.net>
>  ?crivait :
> > I do not enve know how to make "dangerously dedicated"
> disk, and the
> > 8.0 may do this sliently.
> 
> No, I don't think so! But such a problem may arise if your
> disk had been
> installed as "dangerously dedicated" in a former version.
> Unfortunately,
> previous versions of sysinstall have created uncorrect
> labels, and the
> new gpart in 8.0 does not see them.
> 
> In that case, you have to boot kernel.old and wipe out the
> bad label. If
> you reboot with a 7.2 kernel, can you see your missing
> partitions?
> -- 
> Th. Thomas.
> 
From lists at c0mplx.org  Tue Sep 15 06:48:32 2009
From: lists at c0mplx.org (Kurt Jaeger)
Date: Tue Sep 15 06:48:42 2009
Subject: 8.0-Beta installation problem -- Unable to find /dev/ad0s1b
In-Reply-To: <20090914055501.GM48206@home.opsec.eu>
References: <19117.42696.888649.236347@jerusalem.litteratus.org>
	<582270.67371.qm@web82203.mail.mud.yahoo.com>
	<19117.48448.269298.484728@jerusalem.litteratus.org>
	<20090914055501.GM48206@home.opsec.eu>
Message-ID: <20090915064830.GN48206@home.opsec.eu>

Hi!

> I had the same problem with beta4:
> 
> http://lists.freebsd.org/pipermail/freebsd-current/2009-September/011470.html
> 
> and I tried this fix, and it did not solve the problem.
> 
> It might be related with the number of slices and partitions one
> is creating ? I'll try this again today.

Tested it, no, it does not solve the problem.

Is there anything I can do to debug this ?

I think I can provide remote console access if necessary.
I'll try the LiveCD, too.

-- 
pi@opsec.eu            +49 171 3101372                        11 years to go !
From lists at c0mplx.org  Tue Sep 15 07:34:57 2009
From: lists at c0mplx.org (Kurt Jaeger)
Date: Tue Sep 15 07:35:04 2009
Subject: 8.0-Beta installation problem -- Unable to find /dev/ad0s1b
In-Reply-To: <20090915064830.GN48206@home.opsec.eu>
References: <19117.42696.888649.236347@jerusalem.litteratus.org>
	<582270.67371.qm@web82203.mail.mud.yahoo.com>
	<19117.48448.269298.484728@jerusalem.litteratus.org>
	<20090914055501.GM48206@home.opsec.eu>
	<20090915064830.GN48206@home.opsec.eu>
Message-ID: <20090915073457.GO48206@home.opsec.eu>

Hi!

> > I had the same problem with beta4:
[...]

My previous tests were with 8.0-beta4-amd64.

I now tested with 8.0-beta3-i386, this time installation and partitioning
worked.

I'll try to partition using a i386 boot cd and install using
the amd64 boot cd 8-)

It seems to be a bug with the amd64 code ?

-- 
pi@opsec.eu            +49 171 3101372                        11 years to go !
From peterjeremy at acm.org  Tue Sep 15 07:38:55 2009
From: peterjeremy at acm.org (peterjeremy@acm.org)
Date: Tue Sep 15 07:39:03 2009
Subject: problem with link aggregation failover
In-Reply-To: <88656044.63711252836705223.JavaMail.root@dagobah.intersec.pl>
References: <1d3ed48c0909121425g4a255ebah293ce39e42623ab8@mail.gmail.com>
	<88656044.63711252836705223.JavaMail.root@dagobah.intersec.pl>
Message-ID: <20090915073848.GD48679@server.vk2pj.dyndns.org>

On 2009-Sep-13 12:11:45 +0200, Maciej Jan Broniarz <gausus@gausus.net> wrote:
>I have configured the same mac on both cards. 

This should be done automatically by lagg.

>When I disconnect the cable from xl0, the network connection dies, and my lagg0 looks like this:
>
>lagg0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
>	options=9<RXCSUM,VLAN_MTU>
>	ether 00:01:02:20:24:ef
>	inet 192.168.1.104 netmask 0xffffff00 broadcast 192.168.1.255
>	media: Ethernet autoselect
>	status: active
>	laggproto failover
>	laggport: fxp0 flags=4<ACTIVE>
>	laggport: xl0 flags=1<MASTER>
>
>What might be the problem with that setup?

Both sides of a lagg need to co-operate to pass packets.  You need to
configure the switch to failover as well.

-- 
Peter Jeremy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090915/f1c75575/attachment.pgp
From gausus at gausus.net  Tue Sep 15 07:41:35 2009
From: gausus at gausus.net (Maciej Jan Broniarz)
Date: Tue Sep 15 07:41:43 2009
Subject: problem with link aggregation failover
In-Reply-To: <20090915073848.GD48679@server.vk2pj.dyndns.org>
Message-ID: <925889984.66391253001049613.JavaMail.root@dagobah.intersec.pl>


Hello,

> >What might be the problem with that setup?
> 
> Both sides of a lagg need to co-operate to pass packets.  You need to
> configure the switch to failover as well.

A simple LACP configuration should do?

mjb
From wolfgang at lyxys.ka.sub.org  Tue Sep 15 08:17:39 2009
From: wolfgang at lyxys.ka.sub.org (Wolfgang Zenker)
Date: Tue Sep 15 08:17:48 2009
Subject: 8.0-Beta installation problem -- Unable to find /dev/ad0s1b
In-Reply-To: <20090915073457.GO48206@home.opsec.eu>
References: <19117.42696.888649.236347@jerusalem.litteratus.org>
	<582270.67371.qm@web82203.mail.mud.yahoo.com>
	<19117.48448.269298.484728@jerusalem.litteratus.org>
	<20090914055501.GM48206@home.opsec.eu>
	<20090915064830.GN48206@home.opsec.eu>
	<20090915073457.GO48206@home.opsec.eu>
Message-ID: <20090915075400.GA2208@lyxys.ka.sub.org>

Hi,

* Kurt Jaeger <lists@c0mplx.org> [090915 09:34]:
> > > I had the same problem with beta4:
> [...]

> My previous tests were with 8.0-beta4-amd64.

> I now tested with 8.0-beta3-i386, this time installation and partitioning
> worked.

> I'll try to partition using a i386 boot cd and install using
> the amd64 boot cd 8-)

> It seems to be a bug with the amd64 code ?

a few days ago I installed a new system using the amd64 bootonly iso
and didn't have any problems with partitioning. Hardware is
atapci1: <Intel ICH7 SATA300 controller> port 0xd080-0xd087,0xd000-0xd003,0xcc00-0xcc07,0xc880-0xc883,0xc800-0xc80f irq 19 at device 31.2 on pci0
ad4: 476940MB <Hitachi HDP725050GLA360 GM4OA5CA> at ata2-master SATA150
On installation I had a different BIOS configuration though that caused
the SATA disk to be found as ad0, maybe that makes a difference.

Wolfgang
From bc979 at lafn.org  Tue Sep 15 09:33:06 2009
From: bc979 at lafn.org (Doug Hardie)
Date: Tue Sep 15 09:33:13 2009
Subject: 8.0 Install Failure
Message-ID: <B02499E7-4CE7-437F-91FD-D91C3E5FB27F@lafn.org>

Installing 8.0 Beta 4 on an i386 machine from disc 1.  IN the  
Extracting ports:

Panic: initiate_write_inodeblock_ufs2: already started
cpuid=0
KDB: enter: panic
[thread pid 19 tid 100045 ]
Stopped at kdb_enter+0x3a: movl  $0,kdb_why

I did a where but its way too much to type accurately by hand.  This  
is an older system, but it does boot disc 1 where some of the previous  
releases it would not boot disk 1 but had to use the live file system.

I'll try it again without adding the ports.

From thomas at ronner.org  Tue Sep 15 09:38:04 2009
From: thomas at ronner.org (Thomas Ronner)
Date: Tue Sep 15 09:38:12 2009
Subject: 8.0 Install Failure
In-Reply-To: <B02499E7-4CE7-437F-91FD-D91C3E5FB27F@lafn.org>
References: <B02499E7-4CE7-437F-91FD-D91C3E5FB27F@lafn.org>
Message-ID: <97E2F471-705B-48A1-936D-B92235656664@ronner.org>


On 15 Sep 2009, at 10:52, Doug Hardie wrote:

> Installing 8.0 Beta 4 on an i386 machine from disc 1.  IN the  
> Extracting ports:
>
> Panic: initiate_write_inodeblock_ufs2: already started
> cpuid=0
> KDB: enter: panic
> [thread pid 19 tid 100045 ]
> Stopped at kdb_enter+0x3a: movl  $0,kdb_why
>
> I did a where but its way too much to type accurately by hand.  This  
> is an older system, but it does boot disc 1 where some of the  
> previous releases it would not boot disk 1 but had to use the live  
> file system.

The same thing happened to me under VMWare Workstation, when I  
installed FreeBSD 8.0-BETA4 on a (virtual) disk connected to a  
(virtual) LSI SAS adaptor. Installing on a IDE disk worked around the  
problem. It happened with the i386 as well as the amd64 version.


Thomas
From bc979 at lafn.org  Tue Sep 15 09:43:43 2009
From: bc979 at lafn.org (Doug Hardie)
Date: Tue Sep 15 09:43:49 2009
Subject: 8.0 Install Failure
In-Reply-To: <B02499E7-4CE7-437F-91FD-D91C3E5FB27F@lafn.org>
References: <B02499E7-4CE7-437F-91FD-D91C3E5FB27F@lafn.org>
Message-ID: <AD8A34EE-8776-463E-B0FE-9124FF377CBC@lafn.org>

On 15 September 2009, at 01:52, Doug Hardie wrote:

> Installing 8.0 Beta 4 on an i386 machine from disc 1.  IN the  
> Extracting ports:
>
> Panic: initiate_write_inodeblock_ufs2: already started
> cpuid=0
> KDB: enter: panic
> [thread pid 19 tid 100045 ]
> Stopped at kdb_enter+0x3a: movl  $0,kdb_why
>
> I did a where but its way too much to type accurately by hand.  This  
> is an older system, but it does boot disc 1 where some of the  
> previous releases it would not boot disk 1 but had to use the live  
> file system.
>
> I'll try it again without adding the ports.

Well, now it no longer boots disc 1 but does boot the live fs.   
Reinstalled, but now I am getting a bunch of disk errors (SCSI) so I  
suspect the problem is hardware.


From peterjeremy at acm.org  Tue Sep 15 11:15:29 2009
From: peterjeremy at acm.org (Peter Jeremy)
Date: Tue Sep 15 11:15:35 2009
Subject: problem with link aggregation failover
In-Reply-To: <925889984.66391253001049613.JavaMail.root@dagobah.intersec.pl>
References: <20090915073848.GD48679@server.vk2pj.dyndns.org>
	<925889984.66391253001049613.JavaMail.root@dagobah.intersec.pl>
Message-ID: <20090915111515.GA88413@server.vk2pj.dyndns.org>

On 2009-Sep-15 09:50:49 +0200, Maciej Jan Broniarz <gausus@gausus.net> wrote:
>> >What might be the problem with that setup?
>> 
>> Both sides of a lagg need to co-operate to pass packets.  You need to
>> configure the switch to failover as well.
>
>A simple LACP configuration should do?

Yes.  I use LACP at $work.  See lagg(4) for other options.

-- 
Peter Jeremy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090915/8c4d78f2/attachment.pgp
From patfbsd at davenulle.org  Tue Sep 15 11:58:11 2009
From: patfbsd at davenulle.org (Patrick Lamaiziere)
Date: Tue Sep 15 11:58:20 2009
Subject: problem booting FreeBSD 8-Beta4 on Soekris net5501
In-Reply-To: <4AAB2A2C.2000803@menhennitt.com.au>
References: <4AAB2A2C.2000803@menhennitt.com.au>
Message-ID: <20090915135844.705e33cc@baby-jane.lamaiziere.net>

Le Sat, 12 Sep 2009 14:57:16 +1000,
Graham Menhennitt <graham@menhennitt.com.au> a ?crit :

> I'm upgrading a Soekris net5501 from FreeBSD 7-Stable to 8-Beta4 (via
> source). I've done a buildworld, buildkernel, and installkernel. When
> I try to boot the new kernel, it stops very early on in the boot
> sequence. The serial console shows:

...

> Does anybody have any clues please?

No. I can only say that it works for me (tm)
The only change I remember was to change /etc/ttys with ttyu[0..3]
instead ttyd[0..3] on 7.2
From roberthuff at rcn.com  Tue Sep 15 12:15:27 2009
From: roberthuff at rcn.com (Robert Huff)
Date: Tue Sep 15 12:15:33 2009
Subject: 8.0-Beta installation problem -- Unable to find
	/dev/ad0s1b
In-Reply-To: <20090915073457.GO48206@home.opsec.eu>
References: <20090915073457.GO48206@home.opsec.eu>
Message-ID: <19119.34140.222681.273625@jerusalem.litteratus.org>


Kurt Jaeger writes:

>  > > I had the same problem with beta4:
>  [...]
>  
>  My previous tests were with 8.0-beta4-amd64.
>  
>  I now tested with 8.0-beta3-i386, this time installation and
>  partitioning worked.
>	
>  It seems to be a bug with the amd64 code ?

	That might be.
	I have tried this with:

	1) amd64 beta3 and beta4 using the downloaded DVD images
	2) 7.1/7.2 using the installation CD from the set sold by
FreeBSD Mall.

	I also tried on several sets of hardware: SCSI, IDE, SATA.  The
number of disks and number of slices and partitions per disk had no
effect. 
	(1) always failed; (2) succeeded.  (Fruitlessly, since the
specification was for a clean install of 8.0 code and I had to wipe
and try (1) again.)


					Robert Huff





From roberthuff at rcn.com  Tue Sep 15 12:19:20 2009
From: roberthuff at rcn.com (Robert Huff)
Date: Tue Sep 15 12:19:27 2009
Subject: 8.0-Beta installation problem -- Unable to find
	/dev/ad0s1b
In-Reply-To: <500794.80873.qm@web82208.mail.mud.yahoo.com>
References: <500794.80873.qm@web82208.mail.mud.yahoo.com>
Message-ID: <19119.34344.94238.561005@jerusalem.litteratus.org>


Jin Guojun writes:

>  I do not enve know how to make "dangerously dedicated" disk, and
>  the 8.0 may do this sliently. 

	I was told in private conversation "dangerously dedicated" mode
is currently broken (at least with regards to installation), and
that it was removed as an option between beta3 and beta4.


					Robert Huff


From ronald-freebsd8 at klop.yi.org  Tue Sep 15 14:37:41 2009
From: ronald-freebsd8 at klop.yi.org (Ronald Klop)
Date: Tue Sep 15 14:37:52 2009
Subject: 8.0 rc.d scripts less verbose?
Message-ID: <op.u0aywxkp8527sy@82-170-177-25.ip.telfort.nl>

Hi,

Since I run 8.0 the rc.d scripts are less verbose. I have some problems  
with them, but the default output gives me no information anymore.

In the 8.0-TODO wiki there is a mention about verbosity of the rc.d  
scripts at the bottom. Is there a way for me to increase the verbosity?

Ronald.

From ferdinand.goldmann at jku.at  Tue Sep 15 14:58:41 2009
From: ferdinand.goldmann at jku.at (Ferdinand Goldmann)
Date: Tue Sep 15 14:58:48 2009
Subject: newsyslog can't execute command?
Message-ID: <4AAFA47F.6020701@jku.at>

Hi.

Have I overlooked something, or is it not possible with newsyslog to run a
certain command after log rotation? :-(

It looks like the patch mentioned here
http://unix.derkeiler.com/Mailing-Lists/FreeBSD/current/2006-06/msg00575.html
never made it into the FreeBSD distribution?

Bummer ...

-- 
>> Ferdinand Goldmann
>> Johannes Kepler University Linz - Server Systems/Information Management
>> Mail: Ferdinand.Goldmann@jku.at Phone: 00437024689398 Fax: 00437024689397
From 000.fbsd at quip.cz  Tue Sep 15 14:59:50 2009
From: 000.fbsd at quip.cz (Miroslav Lachman)
Date: Tue Sep 15 15:00:02 2009
Subject: 8.0 rc.d scripts less verbose?
In-Reply-To: <op.u0aywxkp8527sy@82-170-177-25.ip.telfort.nl>
References: <op.u0aywxkp8527sy@82-170-177-25.ip.telfort.nl>
Message-ID: <4AAFABE2.7@quip.cz>

Ronald Klop wrote:
> Hi,
> 
> Since I run 8.0 the rc.d scripts are less verbose. I have some problems  
> with them, but the default output gives me no information anymore.
> 
> In the 8.0-TODO wiki there is a mention about verbosity of the rc.d  
> scripts at the bottom. Is there a way for me to increase the verbosity?

You can use rc_debug or rc_info in your rc.conf

rc_debug  (bool) If set to ``YES'', enable output of debug messages
            from rc scripts.  This variable can be helpful in diagnosing
            mistakes when editing or integrating new scripts.  Beware
            that this produces copious output to the terminal and
            syslog(3).

rc_info	  (bool) If set to ``NO'', disable informational messages from
            the rc scripts.  Informational messages are displayed when a
            condition that is not serious enough to warrant a warning or
            an error occurs.

Miroslav Lachman
From ronald-freebsd8 at klop.yi.org  Tue Sep 15 15:15:09 2009
From: ronald-freebsd8 at klop.yi.org (Ronald Klop)
Date: Tue Sep 15 15:15:20 2009
Subject: 8.0 rc.d scripts less verbose?
In-Reply-To: <4AAFABE2.7@quip.cz>
References: <op.u0aywxkp8527sy@82-170-177-25.ip.telfort.nl>
	<4AAFABE2.7@quip.cz>
Message-ID: <op.u0a0nfxb8527sy@82-170-177-25.ip.telfort.nl>

On Tue, 15 Sep 2009 16:59:46 +0200, Miroslav Lachman <000.fbsd@quip.cz>  
wrote:

> Ronald Klop wrote:
>> Hi,
>>  Since I run 8.0 the rc.d scripts are less verbose. I have some  
>> problems  with them, but the default output gives me no information  
>> anymore.
>>  In the 8.0-TODO wiki there is a mention about verbosity of the rc.d   
>> scripts at the bottom. Is there a way for me to increase the verbosity?
>
> You can use rc_debug or rc_info in your rc.conf
>
> rc_debug  (bool) If set to ``YES'', enable output of debug messages
>             from rc scripts.  This variable can be helpful in diagnosing
>             mistakes when editing or integrating new scripts.  Beware
>             that this produces copious output to the terminal and
>             syslog(3).
>
> rc_info	  (bool) If set to ``NO'', disable informational messages from
>             the rc scripts.  Informational messages are displayed when a
>             condition that is not serious enough to warrant a warning or
>             an error occurs.

Rc_info gave me 1 line extra about kld green_saver being loaded. I still  
have to try rc_debug.

Ronald.
From a_romolo at hotmail.com  Tue Sep 15 17:50:19 2009
From: a_romolo at hotmail.com (Rom Albuquerque)
Date: Tue Sep 15 17:50:30 2009
Subject: Source level upgrade from 4.9 to CURRENT..
Message-ID: <SNT114-W81D034E5EFD1695113D57EDE30@phx.gbl>




 Hi folks. Need help in doing the following, but first want to check 
and see if it is feasible with the latest Release, or if I'm just going to 
be spinning my wheels on this one. 

The Objective.
==============

 I have a FreeBSD 4.9-RELEASE system which I want to upgrade to 7.X 
from the source level. Had a bunch of problems installing 7.1-RELEASE from 
the CD distribution I got from freebsdmall.com. Several problems that 
could not mount the CD at the time of installation causing sysinstall
to halt. So, 4.9 is installed and working, is there a source level
backward compatibility issue between 7.x and anything older than 6.0 ?
In other words, upgrading from the sources with such an old
distribution is a doable task ?  


Your response is greatly appreciated. 

Many thanks. 

 

--Rom
a_romolo at hotmail (dot) com






_________________________________________________________________
Ready for Fall shows? Use Bing to find helpful ratings and reviews on digital tv's.
http://www.bing.com/shopping/search?q=digital+tv's&form=MSHNCB&publ=WLHMTAG&crea=TEXT_MSHNCB_Vertical_Shopping_DigitalTVs_1x1
From jhs at berklix.com  Tue Sep 15 18:43:52 2009
From: jhs at berklix.com (Julian H. Stacey)
Date: Tue Sep 15 18:43:59 2009
Subject: Source level upgrade from 4.9 to CURRENT.. 
In-Reply-To: Your message "Tue, 15 Sep 2009 17:38:16 -0000."
	<SNT114-W81D034E5EFD1695113D57EDE30@phx.gbl> 
Message-ID: <200909151818.n8FIIkHN006731@fire.js.berklix.net>

Hi,
Reference:
> From:		Rom Albuquerque <a_romolo@hotmail.com> 
> Date:		Tue, 15 Sep 2009 17:38:16 +0000 
> Message-id:	<SNT114-W81D034E5EFD1695113D57EDE30@phx.gbl> 

Rom Albuquerque wrote:
> 
> 
> 
>  Hi folks. Need help in doing the following, but first want to check 
> and see if it is feasible with the latest Release, or if I'm just going to 
> be spinning my wheels on this one. 
> 
> The Objective.
> ==============
> 
>  I have a FreeBSD 4.9-RELEASE system which I want to upgrade to 7.X 
> from the source level. Had a bunch of problems installing 7.1-RELEASE from 
> the CD distribution I got from freebsdmall.com. Several problems that 
> could not mount the CD at the time of installation causing sysinstall
> to halt. So, 4.9 is installed and working, is there a source level
> backward compatibility issue between 7.x and anything older than 6.0 ?
> In other words, upgrading from the sources with such an old
> distribution is a doable task ?  
> 
> 
> Your response is greatly appreciated. 
> 
> Many thanks. 
> 
>  
> 
> --Rom
> a_romolo at hotmail (dot) com

I recently upgraded lots of hosts from 4.10 & 4.11 & 5 & 6 to 7.2,
So many to keep track I needed my 
	http://www.berklix.com/~jhs/txt/upgrade.html

I `just' moved in the binaries from CD alongside, flipped the directory
contents, rebooted, then built new custom kernels & make world & rebuilt
ports.
But I didnt do some cross compile from 4 to 7, too much like hard work that!

So quite possible to upgrade without repartitioning disc
& reloading data.  But you might want a bigger root. You might want
a newer FFS for performance (can't remember when that came in).
... there'll doubtless be a few other `Gotchas' so if you have problems/
not enough experience/ get stuck. the safe way is a back up, & reinstall.
Well, a back up's not exactly a foolish precaution anyway ;-)

Good luck.

Cheers,
Julian
-- 
Julian Stacey: BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com
  Mail ASCII plain text not HTML & Base64.      http://asciiribbon.org
  Virused Microsoft PCs cause spam.             http://berklix.com/free/
From dimitry at andric.com  Tue Sep 15 19:39:32 2009
From: dimitry at andric.com (Dimitry Andric)
Date: Tue Sep 15 19:39:39 2009
Subject: 8.0 rc.d scripts less verbose?
In-Reply-To: <op.u0aywxkp8527sy@82-170-177-25.ip.telfort.nl>
References: <op.u0aywxkp8527sy@82-170-177-25.ip.telfort.nl>
Message-ID: <4AAFED75.4020502@andric.com>

On 2009-09-15 16:37, Ronald Klop wrote:
> Since I run 8.0 the rc.d scripts are less verbose. I have some problems  
> with them, but the default output gives me no information anymore.
> 
> In the 8.0-TODO wiki there is a mention about verbosity of the rc.d  
> scripts at the bottom. Is there a way for me to increase the verbosity?

Nope, this was removed, apparently.  A pity, since this was very useful
information during boot time.  However, setting rc_debug will give you
enormous gobs of useless info (unless you're debugging rc scripts), and
rc_info doesn't seem to add much anymore, if anything.

To restore the old behaviour, apply the following patch (I have this in
my local repository for ages now):


Index: etc/rc.subr
===================================================================
--- etc/rc.subr	(revision 196888)
+++ etc/rc.subr	(working copy)
@@ -680,7 +680,7 @@ run_rc_command()
 
 					# setup the full command to run
 					#
-			[ -z "${rc_quiet}" ] && echo "Starting ${name}."
+			echo "Starting ${name}."
 			if [ -n "$_chroot" ]; then
 				_doit="\
 ${_nice:+nice -n $_nice }\
From dave at hardman.name  Tue Sep 15 20:44:30 2009
From: dave at hardman.name (Dave Hardman)
Date: Tue Sep 15 20:44:36 2009
Subject: 8.0-BETA-4: no mouse or keyboard in X.
In-Reply-To: <20090915032437.GA49718@loc.alh.ost>
References: <20090913052958.GA3348@loc.alh.ost>
	<20090913124052.533e87fb@baby-jane.lamaiziere.net>
	<20090915032437.GA49718@loc.alh.ost>
Message-ID: <20090915204427.GA73752@loc.alh.ost>

On Tue, Sep 15, 2009 at 01:24:37PM +1000, Dave Hardman wrote:
> On Sun, Sep 13, 2009 at 12:40:52PM +0200, Patrick Lamaiziere
> wrote:
> > Le Sun, 13 Sep 2009 15:29:58 +1000, Dave Hardman
> > <dave@hardman.name> a ?crit :
> > 
> > >     I upgraded from 7.2 to 8.0-BETA4. Now X will not receive
> > >     input from either the mouse or keyboard. 
> >[...] You need to rebuild hal and to remove the old libusb port.
> >libusb is now part of the base system in 8.X and you must use
> >this version. You should rebuild all that depend on the old port
> >libusb (at least).
>     I rebuilt all the ports (portupgrade -afc), during the upgrade
> and there was no indication of any failures.  I tried again
> (portmanager -u -f -l). hal-0.5.11_26 failed.  See below. 
>  
> > >     I also noticed the fuse.ko will not load, reporting "Exec
> > >     format error."
> > 
> > Did you rebuild this module too?
>     It rebuilt when I ran portmanager.
> 
>     I also tried to remove the libusb, as another responded
> suggested. However pkg_delete refused as it was required by other
> packages. Mostly gnome by the look of it eg, gnucash gnumeric.
> 
> Best
> Dave
> 
> gmake[5]: Entering directory `/usr/ports/sysutils/hal/work/hal-0.5.11/hald/freebsd/probing'
> cc -DHAVE_CONFIG_H -I. -I../../..  -DPACKAGE_SYSCONF_DIR=\""/usr/local/etc"\" -DPACKAGE_DATA_DIR=\""/usr/local/share"\" -DPACKAGE_BIN_DIR=\""/usr/local/bin"\" -DPACKAGE_LOCALE_DIR=\""/usr/local/share/locale"\" -DPACKAGE_LOCALSTATEDIR=\""/var"\" -I../../.. -I/usr/local/include/dbus-1.0 -I/usr/local/include/dbus-1.0/include   -I/usr/local/include -DHAVE_CK_0_3  -O2 -pipe -fno-strict-aliasing -Wall -Wchar-subscripts -Wmissing-declarations -Wnested-externs -Wpointer-arith -Wcast-align -Wsign-compare -MT probe-hiddev.o -MD -MP -MF .deps/probe-hiddev.Tpo -c -o probe-hiddev.o probe-hiddev.c
> probe-hiddev.c: In function 'main':
> probe-hiddev.c:81: error: 'USB_GET_REPORT_ID' undeclared (first use in this function)
> probe-hiddev.c:81: error: (Each undeclared identifier is reported only once
> probe-hiddev.c:81: error: for each function it appears in.)
> gmake[5]: *** [probe-hiddev.o] Error 1
> gmake[5]: Leaving directory `/usr/ports/sysutils/hal/work/hal-0.5.11/hald/freebsd/probing'
> gmake[4]: *** [all-recursive] Error 1
> gmake[4]: Leaving directory `/usr/ports/sysutils/hal/work/hal-0.5.11/hald/freebsd'
> gmake[3]: *** [all-recursive] Error 1
> gmake[3]: Leaving directory `/usr/ports/sysutils/hal/work/hal-0.5.11/hald'
> gmake[2]: *** [all] Error 2
> gmake[2]: Leaving directory `/usr/ports/sysutils/hal/work/hal-0.5.11/hald'
> gmake[1]: *** [all-recursive] Error 1
> gmake[1]: Leaving directory `/usr/ports/sysutils/hal/work/hal-0.5.11'
> gmake: *** [all] Error 2
> *** Error code 1
> 
> Stop in /usr/ports/sysutils/hal.
> *** Error code 1
> 
> Stop in /usr/ports/sysutils/hal.
> 	! sysutils/hal (hal-0.5.11_26)	(compiler error)
From areilly at bigpond.net.au  Wed Sep 16 01:04:37 2009
From: areilly at bigpond.net.au (Andrew Reilly)
Date: Wed Sep 16 01:04:44 2009
Subject: Source level upgrade from 4.9 to CURRENT..
In-Reply-To: <SNT114-W81D034E5EFD1695113D57EDE30@phx.gbl>
References: <SNT114-W81D034E5EFD1695113D57EDE30@phx.gbl>
Message-ID: <20090916010429.GA19167@duncan.reilly.home>

On Tue, Sep 15, 2009 at 05:38:16PM +0000, Rom Albuquerque wrote:
> to halt. So, 4.9 is installed and working, is there a source level
> backward compatibility issue between 7.x and anything older than 6.0 ?
> In other words, upgrading from the sources with such an old
> distribution is a doable task ?  

It's "doable", in that many of us have indeed upgraded through
those control points with source, but it can't necessarily be
done in one step.

Is it worth trying to do in multiple steps?  Maybe not: you'll
almost certainly want a larger root partition, and may very well
want to change to UFS2, both of which mean that you're going to
have to dump to backup, repartition, reformat and restore at
some stage (and that stage is one of the intermediate stops,
because you don't have UFS2 in 4.9).

So: you're going to need to be able to boot from the 7.2 (or
whatever) kernel+fixit combination to do the reformat anyway, so
why not go the whole hog and reinstall directly to 7.2 (or so)
at the same time?  That's what I did when I hit the UFS2
barrier, and I'm otherwise a died-in-the-wool source upgrader.
If you're having trouble getting 7.1 to boot from CD, then try
7.2 or otherwise sort out that problem, because not having a
bootable CD fallback position is not a comfortable place to be,
anyway.

Cheers,

-- 
Andrew
From cm at therek.net  Wed Sep 16 07:54:39 2009
From: cm at therek.net (Cezary Morga)
Date: Wed Sep 16 07:54:48 2009
Subject: 8.0 rc.d scripts less verbose?
In-Reply-To: <4AAFED75.4020502@andric.com>
References: <op.u0aywxkp8527sy@82-170-177-25.ip.telfort.nl>
	<4AAFED75.4020502@andric.com>
Message-ID: <4AB099BB.9040603@therek.net>

Dimitry Andric pisze:
> Index: etc/rc.subr
> ===================================================================
> --- etc/rc.subr	(revision 196888)
> +++ etc/rc.subr	(working copy)
> @@ -680,7 +680,7 @@ run_rc_command()
>  
>  					# setup the full command to run
>  					#
> -			[ -z "${rc_quiet}" ] && echo "Starting ${name}."
> +			echo "Starting ${name}."
>  			if [ -n "$_chroot" ]; then
>  				_doit="\
>  ${_nice:+nice -n $_nice }\

Wouldn't it be easier to set rc_quiet to zero-length value, like 
rc_quiet=""?

-- 
Cezary Morga
"Research is the process of going up alleys to see if they are blind." 
(Marston Bates)
From dimitry at andric.com  Wed Sep 16 09:53:29 2009
From: dimitry at andric.com (Dimitry Andric)
Date: Wed Sep 16 09:53:36 2009
Subject: 8.0 rc.d scripts less verbose?
In-Reply-To: <4AB099BB.9040603@therek.net>
References: <op.u0aywxkp8527sy@82-170-177-25.ip.telfort.nl>	<4AAFED75.4020502@andric.com>
	<4AB099BB.9040603@therek.net>
Message-ID: <4AB0B59A.4060405@andric.com>

On 2009-09-16 09:54, Cezary Morga wrote:
> Wouldn't it be easier to set rc_quiet to zero-length value, like 
> rc_quiet=""?

No, rc_quiet is not user-settable (at least not from /etc/rc.conf).
From olli at lurza.secnetix.de  Wed Sep 16 13:39:28 2009
From: olli at lurza.secnetix.de (Oliver Fromme)
Date: Wed Sep 16 13:39:35 2009
Subject: newsyslog can't execute command?
In-Reply-To: <4AAFA47F.6020701@jku.at>
Message-ID: <200909161339.n8GDdATZ042705@lurza.secnetix.de>

Ferdinand Goldmann wrote:
 > Have I overlooked something, or is it not possible with newsyslog to run a
 > certain command after log rotation? :-(

That's correct.

A simple workaround is to write a small shell script that
stores its PID in a file, then runs in the background and
waits for a signal.  It's a hack, but it works.

Basically, something like this will do:

 #!/bin/sh -
 echo $$ > /var/run/loghandler-foo.pid
 while :; do
 	kill -STOP $$
 	...
 	do whatever you want with the log file
 	...
 done

Make sure that shell script is run in the background
during system boot.

The newsyslog.conf entry should look like this:

/var/log/foo.log     644  3  100  *  B  /var/run/loghandler-foo.pid 19

The important thing is the number "19" at the end, which
will cause newsyslog to send SIGCONT to the shell script
after it has rotated the log file.

Alternatively you can also use the shell's built-in "trap"
command to use different signals.

Best regards
   Oliver

-- 
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606,  Gesch?ftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M?n-
chen, HRB 125758,  Gesch?ftsf?hrer: Maik Bachmann, Olaf Erb, Ralf Gebhart

FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd

"What is this talk of 'release'?  We do not make software 'releases'.
Our software 'escapes', leaving a bloody trail of designers and quality
assurance people in its wake."
From faber at isi.edu  Wed Sep 16 16:49:34 2009
From: faber at isi.edu (Ted Faber)
Date: Wed Sep 16 16:49:42 2009
Subject: PATA disks/DVD not detected on ATI IXP 700 - cannot boot
Message-ID: <20090916161327.GB87631@zod.isi.edu>

Hi.

I'm trying to upgrade a machine to a new motherboard (the ECS
A790GXM-AD3 AM3 790GX) my FreeBSD 7-STABLE system (GENERIC kernel,
compiled from source on 10 Sept 2009) reaches the point where it's going
to mount the root file system and can't find the disk.  It drops me into
the manual specification of root file system menu, but there are no
GEOM-managed disks to choose from.  

There's only one drive in the system, a PATA-connected drive that boots
correctly under the old (and I do mean old, circa 2005) motherboard.
Booting from an install/rescue CDROM on a PATA_connected drive proceeds
about the same: boots but cannot find the CDROM to mount.  SATA drives
seem to be found correctly, but I don't have any with FreeBSD on them. 

The ATA controller reports itself as an ATI IXP 700.

There's more info on the motherboard here:
http://www.newegg.com/Product/Product.aspx?Item=N82E16813135236&nm_mc=TEMC-RMA-Approvel&cm_mmc=TEMC-RMA-Approvel-_-Content-_-text-_-

I haven't tried to boot from a USB drive yet, because ATA has so rarely
failed me in the past, but I'm happy to do whatever will help to provide
more diagnostic info.  (The machine is at home, so I won't be able to do
much data-gathering until tonight.)

Thanks for any help.

-- 
Ted Faber
http://www.isi.edu/~faber           PGP: http://www.isi.edu/~faber/pubkeys.asc
Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090916/3b4c11ca/attachment.pgp
From dougb at FreeBSD.org  Thu Sep 17 00:03:13 2009
From: dougb at FreeBSD.org (Doug Barton)
Date: Thu Sep 17 00:03:20 2009
Subject: 8.0 rc.d scripts less verbose?
In-Reply-To: <4AB099BB.9040603@therek.net>
References: <op.u0aywxkp8527sy@82-170-177-25.ip.telfort.nl>	<4AAFED75.4020502@andric.com>
	<4AB099BB.9040603@therek.net>
Message-ID: <4AB17CB9.3040704@FreeBSD.org>

First off, this discussion should actually have been on
freebsd-current@ until 8.0-RELEASE is done, but that's a minor issue.


Cezary Morga wrote:
> Dimitry Andric pisze:
>> Index: etc/rc.subr
>> ===================================================================
>> --- etc/rc.subr    (revision 196888)
>> +++ etc/rc.subr    (working copy)
>> @@ -680,7 +680,7 @@ run_rc_command()
>>  
>>                      # setup the full command to run
>>                      #
>> -            [ -z "${rc_quiet}" ] && echo "Starting ${name}."
>> +            echo "Starting ${name}."
>>              if [ -n "$_chroot" ]; then
>>                  _doit="\
>>  ${_nice:+nice -n $_nice }\
> 
> Wouldn't it be easier to set rc_quiet to zero-length value, like
> rc_quiet=""?

That actually would give off too much information because rc_quiet
suppresses error messages about scripts that don't currently have
_enable set to anything useful. That's arguably a bug, but it's a bug
that we've come to depend on.

The attached patch adds a knob you can set in rc.conf to see "Starting
foo" messages again. If people find this useful I'll be glad to commit
it. I'm also open to suggestions for a better name.


Doug

-- 

    This .signature sanitized for your protection

-------------- next part --------------
--- /usr/src/etc/rc.subr	2009-09-16 14:18:07.000000000 -0700
+++ rc.subr	2009-09-16 16:56:39.000000000 -0700
@@ -708,7 +708,7 @@
 
 					# setup the full command to run
 					#
-			[ -z "${rc_quiet}" ] && echo "Starting ${name}."
+			[ -z "${rc_quiet}" -o -n "${rc_starting}" ] && echo "Starting ${name}."
 			if [ -n "$_chroot" ]; then
 				_doit="\
 ${_nice:+nice -n $_nice }\
From hiyorin at gmail.com  Thu Sep 17 03:08:53 2009
From: hiyorin at gmail.com (C. C. Tang)
Date: Thu Sep 17 03:09:00 2009
Subject: 7.2-release/amd64: panic, spin lock held too long
In-Reply-To: <cf9b1ee00909121502v66566b46p754ed2f2e549555@mail.gmail.com>
References: <cf9b1ee00907061812r3da70018i1c8d8d12bb038a80@mail.gmail.com>	<3bbf2fe10909121432x7bd4f7es497e9431c4e520d6@mail.gmail.com>
	<cf9b1ee00909121502v66566b46p754ed2f2e549555@mail.gmail.com>
Message-ID: <4AB1A838.2040406@gmail.com>

>> Dan, is that machine equipped with Hyperthreading?
>>
>> Attilio
> 
> Yes. It's an Intel Atom 330, which is a dualcore CPU with HT (4 cores
> visible in "top" as a result)

Yes, mine is also Atom 330.

I cannot test the patch because my machine is also in production now. 
But I have tested it with hyperthreading.
powerd with HyperThreading -> spin lock hold too long
powerd without HyperThreading -> no problem
no powerd with/without HyperThreading -> no problem

This blog article also describe the same situation:
http://hype-o-thetic.com/2009/07/09/freenas-d945gclf2-configuration/


By the way, I found that the readings of coretemp don't significant 
change when I enabled powerd so that I doubt that powerd may not be very 
useful for Atom CPU?

Thanks very much,
C.C.
From pluknet at gmail.com  Thu Sep 17 06:14:26 2009
From: pluknet at gmail.com (pluknet)
Date: Thu Sep 17 06:14:33 2009
Subject: 6.2 sporadically locks up
In-Reply-To: <20090617142952.GA73887@sandvine.com>
References: <a31046fc0906160323s3e4ec60bxb585bb29f9f3a02a@mail.gmail.com>
	<200906160830.29721.jhb@freebsd.org>
	<a31046fc0906160803n284604bcs741e6b038079ed12@mail.gmail.com>
	<20090617142952.GA73887@sandvine.com>
Message-ID: <a31046fc0909162314j67a797dcv10dbf342e45e134@mail.gmail.com>

2009/6/17 Ed Maste <emaste@freebsd.org>:
> On Tue, Jun 16, 2009 at 07:03:34PM +0400, pluknet wrote:
>
>> As for allpcpu, I often see the picture, when one CPU runs the "irq17:
>> bce1 aacu0" thread
>> and another one runs arcconf. I wonder if that might be a source of
>> bad locking or races, or..
>> The arcconf utility uses ioctl that goes into aac/aacu(4) internals.
>
> Do you see the same result w/ the in-tree aac(4) driver as opposed to
> Adaptec's version?
>
> -Ed
>

Sorry for late reply.
Several months testing shows that in-tree aac(4)
as of 6.4 (and later) has no this problem.

Thanks.

-- 
wbr,
pluknet
From olli at lurza.secnetix.de  Thu Sep 17 07:17:30 2009
From: olli at lurza.secnetix.de (Oliver Fromme)
Date: Thu Sep 17 07:17:37 2009
Subject: 8.0 rc.d scripts less verbose?
In-Reply-To: <4AB17CB9.3040704@FreeBSD.org>
Message-ID: <200909170717.n8H7HDe4081801@lurza.secnetix.de>

Doug Barton wrote:
 > The attached patch adds a knob you can set in rc.conf to see "Starting
 > foo" messages again. If people find this useful I'll be glad to commit
 > it. I'm also open to suggestions for a better name.

Thanks, this is definitely useful.
Actually I think this should be the default.

My feeling is that hiding all of the "starting" messages
is a regression that needs to be fixed.  I cannot think
of a good reason why they should be hidden, but there
are certainly good reasons to display them.

Just my 2 cents as a long-time admin and user.

Best regards
   Oliver

-- 
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606,  Gesch?ftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M?n-
chen, HRB 125758,  Gesch?ftsf?hrer: Maik Bachmann, Olaf Erb, Ralf Gebhart

FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd

"Perl will consistently give you what you want,
unless what you want is consistency."
        -- Larry Wall
From smithi at nimnet.asn.au  Thu Sep 17 08:55:18 2009
From: smithi at nimnet.asn.au (Ian Smith)
Date: Thu Sep 17 08:55:25 2009
Subject: 8.0 rc.d scripts less verbose?
In-Reply-To: <4AB17CB9.3040704@FreeBSD.org>
References: <op.u0aywxkp8527sy@82-170-177-25.ip.telfort.nl>
	<4AAFED75.4020502@andric.com>
	<4AB099BB.9040603@therek.net> <4AB17CB9.3040704@FreeBSD.org>
Message-ID: <20090917183525.O73400@sola.nimnet.asn.au>

On Wed, 16 Sep 2009, Doug Barton wrote:
 > Cezary Morga wrote:
 > > Dimitry Andric pisze:
 > >> Index: etc/rc.subr
 > >> ===================================================================
 > >> --- etc/rc.subr    (revision 196888)
 > >> +++ etc/rc.subr    (working copy)
 > >> @@ -680,7 +680,7 @@ run_rc_command()
 > >>  
 > >>                      # setup the full command to run
 > >>                      #
 > >> -            [ -z "${rc_quiet}" ] && echo "Starting ${name}."
 > >> +            echo "Starting ${name}."
 > >>              if [ -n "$_chroot" ]; then
 > >>                  _doit="\
 > >>  ${_nice:+nice -n $_nice }\
 > > 
 > > Wouldn't it be easier to set rc_quiet to zero-length value, like
 > > rc_quiet=""?
 > 
 > That actually would give off too much information because rc_quiet
 > suppresses error messages about scripts that don't currently have
 > _enable set to anything useful. That's arguably a bug, but it's a bug
 > that we've come to depend on.
 > 
 > The attached patch adds a knob you can set in rc.conf to see "Starting
 > foo" messages again. If people find this useful I'll be glad to commit
 > it. I'm also open to suggestions for a better name.

>From your patch:
-                       [ -z "${rc_quiet}" ] && echo "Starting ${name}."
+                       [ -z "${rc_quiet}" -o -n "${rc_starting}" ] && echo "Starting ${name}."

Presumably this variable would go in /etc/defaults/rc.conf .. seems that 
all the other rc.conf binary choices are either set "YES" or "NO" rather 
than something or empty, so perhaps more consistent with that might be:

 [ -z "${rc_quiet}" -o "${rc_starting}" = "YES" ] && echo "Starting ${name}."

As for name, not fussed, but maybe rc_startmsgs maybe more indicative?

Also, I agree with Oliver; YES should probably be the default (POLA) so 
folks annoyed by 'too much information' in console.log can disable it.

HTH, Ian
From dimitry at andric.com  Thu Sep 17 08:59:02 2009
From: dimitry at andric.com (Dimitry Andric)
Date: Thu Sep 17 08:59:09 2009
Subject: 8.0 rc.d scripts less verbose?
In-Reply-To: <200909170717.n8H7HDe4081801@lurza.secnetix.de>
References: <200909170717.n8H7HDe4081801@lurza.secnetix.de>
Message-ID: <4AB1FA57.5090502@andric.com>

On 2009-09-17 09:17, Oliver Fromme wrote:
> My feeling is that hiding all of the "starting" messages
> is a regression that needs to be fixed.  I cannot think
> of a good reason why they should be hidden, but there
> are certainly good reasons to display them.

The commit that introduced this, r179946, has this log message:

====
Move the diagnostic output when the rc.subr(8) glue automatically starts a
service behind $rc_quiet. Instead, output a warning if the pre-command
routine or the command itself failed. Arguably, it's more useful to know when
a command failed to start than it is to have an endless list of
"Starting ...." lines[1].

[1] - This change actually helped me to discover a bug in rc.d/{lockd,statd}
      (fixed in r179941) that used to fail silently before.
====

It is really a matter of taste, I guess.  There is something to be said
for eliminating verbosity, in order to make real errors more visible.

On the other hand, if one of your startup rc scripts hangs (for whatever
reason), it is nice to have an approximate idea which one it is. :)
From attilio at freebsd.org  Thu Sep 17 09:16:56 2009
From: attilio at freebsd.org (Attilio Rao)
Date: Thu Sep 17 09:17:04 2009
Subject: 7.2-release/amd64: panic, spin lock held too long
In-Reply-To: <4AB1A838.2040406@gmail.com>
References: <cf9b1ee00907061812r3da70018i1c8d8d12bb038a80@mail.gmail.com>
	<3bbf2fe10909121432x7bd4f7es497e9431c4e520d6@mail.gmail.com>
	<cf9b1ee00909121502v66566b46p754ed2f2e549555@mail.gmail.com>
	<4AB1A838.2040406@gmail.com>
Message-ID: <3bbf2fe10909170216u29d994aj55c21efdfbc26ba5@mail.gmail.com>

2009/9/17 C. C. Tang <hiyorin@gmail.com>:
>>> Dan, is that machine equipped with Hyperthreading?
>>>
>>> Attilio
>>
>> Yes. It's an Intel Atom 330, which is a dualcore CPU with HT (4 cores
>> visible in "top" as a result)
>
> Yes, mine is also Atom 330.
>
> I cannot test the patch because my machine is also in production now. But I
> have tested it with hyperthreading.
> powerd with HyperThreading -> spin lock hold too long
> powerd without HyperThreading -> no problem
> no powerd with/without HyperThreading -> no problem

But these are with the last patch I posted in?
(specifically, for 7.2:
http://www.freebsd.org/~attilio/sched_ule.diff
)

So with the patch in, powerd and hyperthreading on you still get a deadlock?

Attilio


-- 
Peace can only be achieved by understanding - A. Einstein
From hiyorin at gmail.com  Thu Sep 17 10:31:40 2009
From: hiyorin at gmail.com (C. C. Tang)
Date: Thu Sep 17 10:31:47 2009
Subject: 7.2-release/amd64: panic, spin lock held too long
In-Reply-To: <3bbf2fe10909170216u29d994aj55c21efdfbc26ba5@mail.gmail.com>
References: <cf9b1ee00907061812r3da70018i1c8d8d12bb038a80@mail.gmail.com>	
	<3bbf2fe10909121432x7bd4f7es497e9431c4e520d6@mail.gmail.com>	
	<cf9b1ee00909121502v66566b46p754ed2f2e549555@mail.gmail.com>	
	<4AB1A838.2040406@gmail.com>
	<3bbf2fe10909170216u29d994aj55c21efdfbc26ba5@mail.gmail.com>
Message-ID: <4AB21005.6040104@gmail.com>

Attilio Rao wrote:
> 2009/9/17 C. C. Tang <hiyorin@gmail.com>:
>>>> Dan, is that machine equipped with Hyperthreading?
>>>>
>>>> Attilio
>>> Yes. It's an Intel Atom 330, which is a dualcore CPU with HT (4 cores
>>> visible in "top" as a result)
>> Yes, mine is also Atom 330.
>>
>> I cannot test the patch because my machine is also in production now. But I
>> have tested it with hyperthreading.
>> powerd with HyperThreading -> spin lock hold too long
>> powerd without HyperThreading -> no problem
>> no powerd with/without HyperThreading -> no problem
> 
> But these are with the last patch I posted in?
> (specifically, for 7.2:
> http://www.freebsd.org/~attilio/sched_ule.diff
> )
> 
> So with the patch in, powerd and hyperthreading on you still get a deadlock?
> 
> Attilio
> 
> 
No, the kernel is not patched.

C.C.
From mikael at t-online.hu  Thu Sep 17 10:38:30 2009
From: mikael at t-online.hu (Mikael Bak)
Date: Thu Sep 17 10:38:37 2009
Subject: amavisd-new port "updates" configuration files
Message-ID: <4AB2119F.6000107@t-online.hu>

Hi list,

I'm not sure if this is the right place to ask about this.

Yesterday I upgraded amavisd-new with portupgrade.
The upgrade went fine but when I started amavisd-new it didn't behave
quite as I had expected.

It turned out that the upgrade had deleted my version of
/usr/local/etc/amavisd.conf with a default configuration file, quite
useless to me.

Fortunately I had a backup of my old config file, so no real damage. I
was surprised because I have never seen ports deleting user edited
config files before.

Is this a bug in this particular port or is this expected behaviour?

# uname -r
7.2-RELEASE-p2

Port versions:
amavisd-new-2.6.4_2,1
portupgrade-2.4.6_3,2

TIA,
Mikael
From dougb at FreeBSD.org  Thu Sep 17 10:42:42 2009
From: dougb at FreeBSD.org (Doug Barton)
Date: Thu Sep 17 10:42:55 2009
Subject: 8.0 rc.d scripts less verbose?
In-Reply-To: <20090917183525.O73400@sola.nimnet.asn.au>
References: <op.u0aywxkp8527sy@82-170-177-25.ip.telfort.nl>	<4AAFED75.4020502@andric.com>	<4AB099BB.9040603@therek.net>
	<4AB17CB9.3040704@FreeBSD.org>
	<20090917183525.O73400@sola.nimnet.asn.au>
Message-ID: <4AB21295.5080103@FreeBSD.org>

Please follow up to this post on the freebsd-rc@freebsd.org list, thanks.

See below for my comments.

Ian Smith wrote:
> On Wed, 16 Sep 2009, Doug Barton wrote:
>> Cezary Morga wrote:
>>> Dimitry Andric pisze:
>>>> Index: etc/rc.subr 
>>>> ===================================================================
>>>>  --- etc/rc.subr    (revision 196888) +++ etc/rc.subr
>>>> (working copy) @@ -680,7 +680,7 @@ run_rc_command()
>>>> 
>>>> # setup the full command to run # -            [ -z
>>>> "${rc_quiet}" ] && echo "Starting ${name}." +            echo
>>>> "Starting ${name}." if [ -n "$_chroot" ]; then _doit="\ 
>>>> ${_nice:+nice -n $_nice }\
>>> 
>>> Wouldn't it be easier to set rc_quiet to zero-length value,
>>> like rc_quiet=""?
>> 
>> That actually would give off too much information because
>> rc_quiet suppresses error messages about scripts that don't
>> currently have _enable set to anything useful. That's arguably a
>> bug, but it's a bug that we've come to depend on.
>> 
>> The attached patch adds a knob you can set in rc.conf to see
>> "Starting foo" messages again. If people find this useful I'll be
>> glad to commit it. I'm also open to suggestions for a better
>> name.
> 
>> From your patch:
> - [ -z "${rc_quiet}" ] && echo "Starting ${name}."
> + [ -z "${rc_quiet}" -o -n "${rc_starting}" ] && echo "Starting
${name}."
> 
> Presumably this variable would go in /etc/defaults/rc.conf .. seems
> that all the other rc.conf binary choices are either set "YES" or
> "NO" rather than something or empty, so perhaps more consistent
> with that might be:
> 
> [ -z "${rc_quiet}" -o "${rc_starting}" = "YES" ] && echo "Starting
> ${name}."

No, we don't test boolean flags for specific values. I've attached a
proper patch to this message.

> As for name, not fussed, but maybe rc_startmsgs maybe more
> indicative?

That sounds fine to me, if anyone else has a better idea follow up on
the freebsd-rc list.

> Also, I agree with Oliver; YES should probably be the default
> (POLA) so folks annoyed by 'too much information' in console.log
> can disable it.

This late in the release cycle I'm comfortable adding a knob, but I'm
not comfortable toggling the default. If there is consensus on the
freebsd-rc list to make the default "yes" then I will go with that
consensus.

Dimitry Andric wrote:
> On 2009-09-17 09:17, Oliver Fromme wrote:
>> My feeling is that hiding all of the "starting" messages is a
>> regression that needs to be fixed.  I cannot think of a good
>> reason why they should be hidden, but there are certainly good
>> reasons to display them.
> 
> The commit that introduced this, r179946, has this log message:
> 
> ==== Move the diagnostic output when the rc.subr(8) glue
> automatically starts a
> service behind $rc_quiet. Instead, output a warning if the
> pre-command routine or the command itself failed. Arguably, it's
> more useful to know when
> a command failed to start than it is to have an endless list of 
> "Starting ...." lines[1].
> 
> [1] - This change actually helped me to discover a bug in
> rc.d/{lockd,statd}
> (fixed in r179941) that used to fail silently before. ====
> 
> It is really a matter of taste, I guess.  There is something to be
> said for eliminating verbosity, in order to make real errors more
> visible.
> 
> On the other hand, if one of your startup rc scripts hangs (for
> whatever reason), it is nice to have an approximate idea which one
> it is. :)

I tend to agree that the current default is a little too un-verbose.
If there is support for adding this knob I'll follow up with re@ to
see about getting it into 8.0-release, although I'm not sure how
they'll feel about a change like this so late in the cycle.


Doug

-- 

    This .signature sanitized for your protection


-------------- next part --------------
Index: share/man/man5/rc.conf.5
===================================================================
--- share/man/man5/rc.conf.5	(revision 197259)
+++ share/man/man5/rc.conf.5	(working copy)
@@ -24,7 +24,7 @@
 .\"
 .\" $FreeBSD$
 .\"
-.Dd September 2, 2009
+.Dd September 17, 2009
 .Dt RC.CONF 5
 .Os
 .Sh NAME
@@ -95,6 +95,13 @@
 Informational messages are displayed when
 a condition that is not serious enough to warrant a warning or
 an error occurs.
+.It Va rc_startmsgs
+.Pq Vt bool
+If set to
+.Dq Li YES ,
+show
+.Dq Starting foo:
+when faststart is used (e.g., at boot time).
 .It Va early_late_divider
 .Pq Vt str
 The name of the script that should be used as the
Index: etc/defaults/rc.conf
===================================================================
--- etc/defaults/rc.conf	(revision 197259)
+++ etc/defaults/rc.conf	(working copy)
@@ -23,6 +23,7 @@
 
 rc_debug="NO"		# Set to YES to enable debugging output from rc.d
 rc_info="NO"		# Enables display of informational messages at boot.
+rc_startmsgs="NO" 	# Show "Starting foo:" messages at boot
 rcshutdown_timeout="30" # Seconds to wait before terminating rc.shutdown
 early_late_divider="FILESYSTEMS"	# Script that separates early/late
 			# stages of the boot process.  Make sure you know
Index: etc/rc.subr
===================================================================
--- etc/rc.subr	(revision 197259)
+++ etc/rc.subr	(working copy)
@@ -708,7 +708,13 @@
 
 					# setup the full command to run
 					#
-			[ -z "${rc_quiet}" ] && echo "Starting ${name}."
+			_show_startmsgs=1
+			if [ -n "${rc_quiet}" ]; then
+				if ! checkyesno rc_startmsgs; then
+					unset _show_startmsgs
+				fi
+			fi
+			[ -n "$_show_startmsgs" ] && echo "Starting ${name}."
 			if [ -n "$_chroot" ]; then
 				_doit="\
 ${_nice:+nice -n $_nice }\
From stb at lassitu.de  Thu Sep 17 11:07:31 2009
From: stb at lassitu.de (Stefan Bethke)
Date: Thu Sep 17 11:07:38 2009
Subject: amavisd-new port "updates" configuration files
In-Reply-To: <4AB2119F.6000107@t-online.hu>
References: <4AB2119F.6000107@t-online.hu>
Message-ID: <73745893-CD83-4C64-9F4A-F665801994F1@lassitu.de>

Am 17.09.2009 um 12:38 schrieb Mikael Bak:

> It turned out that the upgrade had deleted my version of
> /usr/local/etc/amavisd.conf with a default configuration file, quite
> useless to me.

Try contacting the port maintainer (the MAINTAINER variable in the  
port's Makefile).  Ports shouldn't overwrite user-edited files.


Stefan

-- 
Stefan Bethke <stb@lassitu.de>   Fon +49 151 14070811




From mrkvrg at acm.org  Thu Sep 17 16:52:30 2009
From: mrkvrg at acm.org (mfv)
Date: Thu Sep 17 16:52:37 2009
Subject: Not Able to Buildkernel
Message-ID: <200909171225.46906.mrkvrg@acm.org>

Hello,

After rebuilding FreeBSD for many years I am not able to build a GENERIC 
kernel for the last few days.

All my sources are up to date for -STABLE and am running i386 for 
version 7.2 on an amd64 cpu.

Ironically I am able to run "make buildworld" with no problem.  Despite 
removing my make.conf and src.conf files I am still not able to update 
my kernel.

Any help would be appreciated.

With thanks.

Marek

The following is the tail end of "make buildkernel":


cc -O2 -fno-strict-aliasing -pipe -D_KERNEL -DKLD_MODULE -std=c99 -
nostdinc -I
/usr/src/sys/modules/acpi/acpi/../../../contrib/dev/acpica
-DHAVE_KERNEL_OPTION_ HEADERS -include
/usr/obj/usr/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/a ltq
-finline-limit=8000 --param inline-unit-growth=100 --param large-
function-gr
owth=1000 -fno-common -g -I/usr/obj/usr/src/sys/GENERIC
-mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow
-mno-sse -mno-sse2 -mno-sse3 - ffreestanding -Wall -Wredundant-decls
-Wnested-externs -Wstrict-prototypes -Wmi ssing-prototypes -Wpointer-
arith
-Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c
/usr/src/sys/modules/acpi/acpi/../../../dev/acpica/Osd/O sdTable.c

cc -O2 -fno-strict-aliasing -pipe -D_KERNEL -DKLD_MODULE -std=c99 -
nostdinc -I
/usr/src/sys/modules/acpi/acpi/../../../contrib/dev/acpica
-DHAVE_KERNEL_OPTION_ HEADERS -include
/usr/obj/usr/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/a ltq
-finline-limit=8000 --param inline-unit-growth=100 --param large-
function-gr
owth=1000 -fno-common -g -I/usr/obj/usr/src/sys/GENERIC
-mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow
-mno-sse -mno-sse2 -mno-sse3 - ffreestanding -Wall -Wredundant-decls
-Wnested-externs -Wstrict-prototypes -Wmi ssing-prototypes -Wpointer-
arith
-Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c
/usr/src/sys/modules/acpi/acpi/../../../i386/acpica/OsdE nvironment.c

cc -O2 -fno-strict-aliasing -pipe -D_KERNEL -DKLD_MODULE -std=c99 -
nostdinc -I
/usr/src/sys/modules/acpi/acpi/../../../contrib/dev/acpica
-DHAVE_KERNEL_OPTION_ HEADERS -include
/usr/obj/usr/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/a ltq
-finline-limit=8000 --param inline-unit-growth=100 --param large-
function-gr
owth=1000 -fno-common -g -I/usr/obj/usr/src/sys/GENERIC
-mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow
-mno-sse -mno-sse2 -mno-sse3 - ffreestanding -Wall -Wredundant-decls
-Wnested-externs -Wstrict-prototypes -Wmi ssing-prototypes -Wpointer-
arith
-Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c
/usr/src/sys/modules/acpi/acpi/../../../i386/acpica/acpi _machdep.c @ ->
/usr/src/sys

ln: @/sys: Operation not permitted *** Error code 1

Stop in /usr/src/sys/modules/acpi/acpi.
*** Error code 1

Stop in /usr/src/sys/modules/acpi.
*** Error code 1

Stop in /usr/src/sys/modules.
*** Error code 1

Stop in /usr/obj/usr/src/sys/GENERIC.
*** Error code 1

Stop in /usr/src.
*** Error code 1

Stop in /usr/src.

[root] /usr/src #


From mamalos at eng.auth.gr  Thu Sep 17 18:28:14 2009
From: mamalos at eng.auth.gr (George Mamalakis)
Date: Thu Sep 17 18:28:26 2009
Subject: SASL problems with spnego on 8.0-BETA4
Message-ID: <4AB27FB6.4010806@eng.auth.gr>

Dear all,

I am trying to setup ldap with heimdal on my fbsd 8.0-BETA4 and when I 
run ldapsearch to see if I can authenticate via GSSAPI I keep getting 
the following error:

[root@ldap root]# ldapsearch  -H "ldap://ldap.example.com/" -b 
"dc=example,dc=com"
SASL/GSSAPI authentication started
dlopen: /usr/lib/libgssapi_spnego.so.10: Undefined symbol 
"GSS_C_NT_HOSTBASED_SERVICE"
ldap_sasl_interactive_bind_s: Local error (-2)


in ldap.conf (loglevel args stats) I am getting:

Sep 17 21:24:46 ldap slapd[44607]: conn=11 fd=13 ACCEPT from 
IP=192.168.35.10:32598 (IP=0.0.0.0:389)
Sep 17 21:24:46 ldap slapd[44607]: connection_get(13)
Sep 17 21:24:46 ldap slapd[44607]: conn=11 fd=13 closed (connection lost)

The ports I installed are:

cyrus-sasl-2.1.23
openldap-sasl-client-2.4.18
openldap-sasl-server-2.4.18_1

I cannot resolve this issue, so if anyone knows anything, I would be 
grateful if I could have a hint.

Thank you all for your time in advance.

-- 
George Mamalakis

IT Officer
Electrical and Computer Engineer (Aristotle Un. of Thessaloniki),
MSc (Imperial College of London)

Department of Electrical and Computer Engineering
Faculty of Engineering
Aristotle University of Thessaloniki

phone number : +30 (2310) 994379

From jasonh at DataIX.net  Thu Sep 17 21:50:13 2009
From: jasonh at DataIX.net (Jason J. Hellenthal)
Date: Thu Sep 17 21:50:19 2009
Subject: Fixup manpath.config suggestion
Message-ID: <alpine.BSF.2.00.0909171744280.19683@qvzrafvba.5c.ybpny>


Fix manpath.config optional manpath of /usr/X11R6. This has not been a actual 
path for some time now and is just a symlink to /usr/local which is already in 
the manpath.config.

The attached patch just deletes the referenced lines, it might be better off 
just commenting them out and adding a comment next to them referring to the 
symlink usage.

-- 

  Jason J. Hellenthal
  http://www.DataIX.net/
  jasonh@DataIX.net
  0x691411AC

  - (2^(N-1))
-------------- next part --------------
--- manpath.config.orig	2009-09-14 06:41:11.000000000 -0400
+++ manpath.config	2009-09-17 17:29:37.088290738 -0400
@@ -17,14 +17,12 @@
 # check if the directory exists and if it does, add it to MANPATH
 #
 OPTIONAL_MANPATH	/usr/local/man
-OPTIONAL_MANPATH	/usr/X11R6/man
 #
 # set up PATH to MANPATH mapping
 #
 MANPATH_MAP	/bin			/usr/share/man
 MANPATH_MAP	/usr/bin		/usr/share/man
 MANPATH_MAP	/usr/local/bin		/usr/local/man
-MANPATH_MAP	/usr/X11R6/bin		/usr/X11R6/man
 #
 # set man locales, if needed
 #
From ari at ish.com.au  Fri Sep 18 00:43:07 2009
From: ari at ish.com.au (Aristedes Maniatis)
Date: Fri Sep 18 00:43:15 2009
Subject: pcpu.h kernel crash with 7.2
Message-ID: <4AB2D797.9090603@ish.com.au>

This is a FreeBSD 7.2 machine in production. I'm not an expert at debugging kernel problems, but I've still got the vmcore if there is anything else I should run on it to extract more information.

Thanks

Ari Maniatis


# uname -a
FreeBSD dash.internal 7.2-RELEASE-p2 FreeBSD 7.2-RELEASE-p2 #0: Wed Jun 24 00:14:35 UTC 2009     root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC  amd64


#kgdb /boot/kernel/kernel /var/crash/vmcore.3
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "amd64-marcel-freebsd"...

Unread portion of the kernel message buffer:


Fatal trap 12: page fault while in kernel mode
cpuid = 4; apic id = 04
fault virtual address	= 0x11
fault code		= supervisor read data, page not present
instruction pointer	= 0x8:0xffffffff804fbec9
stack pointer	        = 0x10:0xffffffff7b6a2830
frame pointer	        = 0x10:0x1
code segment		= base 0x0, limit 0xfffff, type 0x1b
			= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags	= interrupt enabled, resume, IOPL = 0
current process		= 69329 (httpd)
trap number		= 12
panic: page fault
cpuid = 4
Uptime: 34d3h21m46s
Physical memory: 24561 MB
Dumping 5146 MB: 5131 5115 5099 5083 5067 5051 5035 5019 5003 4987 4971 4955 4939 4923 4907 4891 4875 4859 4843 4827 4811 4795 4779 4763 4747 4731 4715 4699 4683 4667 4651 4635 4619 4603 4587 4571 4555 4539 4523 4507 4491 4475 4459 4443 4427 4411 4395 4379 4363 4347 4331 4315 4299 4283 4267 4251 4235 4219 4203 4187 4171 4155 4139 4123 4107 4091 4075 4059 4043 4027 4011 3995 3979 3963 3947 3931 3915 3899 3883 3867 3851 3835 3819 3803 3787 3771 3755 3739 3723 3707 3691 3675 3659 3643 3627 3611 3595 3579 3563 3547 3531 3515 3499 3483 3467 3451 3435 3419 3403 3387 3371 3355 3339 3323 3307 3291 3275 3259 3243 3227 3211 3195 3179 3163 3147 3131 3115 3099 3083 3067 3051 3035 3019 3003 2987 2971 2955 2939 2923 2907 2891 2875 2859 2843 2827 2811 2795 2779 2763 2747 2731 2715 2699 2683 2667 2651 2635 2619 2603 2587 2571 2555 2539 2523 2507 2491 2475 2459 2443 2427 2411 2395 2379 2363 2347 2331 2315 2299 2283 2267 2251 2235 2219 2203 2187 2171 2155 2139 2123 2107 2091 2075 2059 2043 202
7 2011 1995 1979 1963 1947 1931 1915 1899 1883 1867 1851 1835 1819 1803 1787 1771 1755 1739 1723 1707 1691 1675 1659 1643 1627 1611 1595 1579 1563 1547 1531 1515 1499 1483 1467 1451 1435 1419 1403 1387 1371 1355 1339 1323 1307 1291 1275 1259 1243 1227 1211 1195 1179 1163 1147 1131 1115 1099 1083 1067 1051 1035 1019 1003 987 971 955 939 923 907 891 875 859 843 827 811 795 779 763 747 731 715 699 683 667 651 635 619 603 587 571 555 539 523 507 491 475 459 443 427 411 395 379 363 347 331 315 299 283 267 251 235 219 203 187 171 155 139 123 107 91 75 59 43 27 11

Reading symbols from /boot/kernel/zfs.ko...Reading symbols from /bootdir/boot/kernel/zfs.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/zfs.ko
Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols from /bootdir/boot/kernel/opensolaris.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/opensolaris.ko
Reading symbols from /boot/kernel/accf_http.ko...Reading symbols from /bootdir/boot/kernel/accf_http.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/accf_http.ko
Reading symbols from /boot/kernel/ipmi.ko...Reading symbols from /bootdir/boot/kernel/ipmi.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/ipmi.ko
Reading symbols from /boot/kernel/smbus.ko...Reading symbols from /bootdir/boot/kernel/smbus.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/smbus.ko
Reading symbols from /boot/kernel/pflog.ko...Reading symbols from /bootdir/boot/kernel/pflog.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/pflog.ko
Reading symbols from /boot/kernel/pf.ko...Reading symbols from /bootdir/boot/kernel/pf.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/pf.ko
#0  doadump () at pcpu.h:195
195	pcpu.h: No such file or directory.
	in pcpu.h




(kgdb) bt
#0  doadump () at pcpu.h:195
#1  0x0000000000000004 in ?? ()
#2  0xffffffff8050df79 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418
#3  0xffffffff8050e382 in panic (fmt=0x104 <Address 0x104 out of bounds>) at /usr/src/sys/kern/kern_shutdown.c:574
#4  0xffffffff807d2253 in trap_fatal (frame=0xffffff0315455370, eva=Variable "eva" is not available.
) at /usr/src/sys/amd64/amd64/trap.c:757
#5  0xffffffff807d2625 in trap_pfault (frame=0xffffffff7b6a2780, usermode=0) at /usr/src/sys/amd64/amd64/trap.c:673
#6  0xffffffff807d2f64 in trap (frame=0xffffffff7b6a2780) at /usr/src/sys/amd64/amd64/trap.c:444
#7  0xffffffff807b70ce in calltrap () at /usr/src/sys/amd64/amd64/exception.S:209
#8  0xffffffff804fbec9 in lf_free_lock (lock=0xffffff03d0518580) at sx.h:153
#9  0xffffffff804fda14 in lf_advlockasync (ap=Variable "ap" is not available.
) at /usr/src/sys/kern/kern_lockf.c:1458
#10 0xffffffff804fda69 in lf_advlock (ap=Variable "ap" is not available.
) at /usr/src/sys/kern/kern_lockf.c:741
#11 0xffffffff80582270 in vop_stdadvlock (ap=0xffffffff7b6a2a70) at /usr/src/sys/kern/vfs_default.c:222
#12 0xffffffff804e02a6 in kern_fcntl (td=0xffffff0315455370, fd=Variable "fd" is not available.
) at vnode_if.h:1036
#13 0xffffffff804e0539 in fcntl (td=0xffffff0315455370, uap=0xffffffff7b6a2bf0) at /usr/src/sys/kern/kern_descrip.c:374
#14 0xffffffff807d28a7 in syscall (frame=0xffffffff7b6a2c80) at /usr/src/sys/amd64/amd64/trap.c:900
#15 0xffffffff807b72db in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:330
#16 0x000000080113528c in ?? ()
Previous frame inner to this frame (corrupt stack?)


-- 

-------------------------->
ish
http://www.ish.com.au
Level 1, 30 Wilson Street Newtown 2042 Australia
phone +61 2 9550 5001   fax +61 2 9550 4001
GPG fingerprint CBFB 84B4 738D 4E87 5E5C  5EFA EF6A 7D2E 3E49 102A
From john.marshall at riverwillow.com.au  Fri Sep 18 03:49:43 2009
From: john.marshall at riverwillow.com.au (John Marshall)
Date: Fri Sep 18 03:49:49 2009
Subject: SASL problems with spnego on 8.0-BETA4
In-Reply-To: <4AB27FB6.4010806@eng.auth.gr>
References: <4AB27FB6.4010806@eng.auth.gr>
Message-ID: <20090918034933.GI1231@rwpc12.mby.riverwillow.net.au>

On Thu, 17 Sep 2009, 21:28 +0300, George Mamalakis wrote:
> Dear all,
> 
> I am trying to setup ldap with heimdal on my fbsd 8.0-BETA4 and when I 
> run ldapsearch to see if I can authenticate via GSSAPI I keep getting 
> the following error:
> 
> [root@ldap root]# ldapsearch  -H "ldap://ldap.example.com/" -b 
> "dc=example,dc=com"
> SASL/GSSAPI authentication started
> dlopen: /usr/lib/libgssapi_spnego.so.10: Undefined symbol 
> "GSS_C_NT_HOSTBASED_SERVICE"
> ldap_sasl_interactive_bind_s: Local error (-2)
> 
> 
> in ldap.conf (loglevel args stats) I am getting:
> 
> Sep 17 21:24:46 ldap slapd[44607]: conn=11 fd=13 ACCEPT from 
> IP=192.168.35.10:32598 (IP=0.0.0.0:389)
> Sep 17 21:24:46 ldap slapd[44607]: connection_get(13)
> Sep 17 21:24:46 ldap slapd[44607]: conn=11 fd=13 closed (connection lost)
> 
> The ports I installed are:
> 
> cyrus-sasl-2.1.23
> openldap-sasl-client-2.4.18
> openldap-sasl-server-2.4.18_1
> 
> I cannot resolve this issue, so if anyone knows anything, I would be 
> grateful if I could have a hint.
> 
> Thank you all for your time in advance.

I don't remember if the symptoms I saw were identical, but I couldn't
use GSSAPI to authenticate to OpenLDAP on 8.0-BETA2.  I solved my
problem by installing a newer Heimdal as a port and then rebuilding
SASL2 against the newer Heimdal.

NB. To build security/cyrus-sasl2 against the Heimdal port, I added the
following line to my /usr/local/etc/ports.conf (see:
ports-mgmt/portconf)

  security/cyrus-sasl2: HEIMDAL_HOME=/usr/local

FreeBSD 8.0 includes Heimdal 1.1.0 in the base system.  The Heimdal port
is older (1.0.1).  The heimdal-1.2.1 port patch I used was submitted to
GNATS a couple of hours ago.  No response from GNATS yet but it should
be available there sometime soon.

-- 
John Marshall
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090918/ffc040d2/attachment.pgp
From kostikbel at gmail.com  Fri Sep 18 07:59:00 2009
From: kostikbel at gmail.com (Kostik Belousov)
Date: Fri Sep 18 07:59:08 2009
Subject: lf_advlockasync panic [Was: pcpu.h kernel crash with 7.2]
In-Reply-To: <4AB2D797.9090603@ish.com.au>
References: <4AB2D797.9090603@ish.com.au>
Message-ID: <20090918075853.GL47688@deviant.kiev.zoral.com.ua>

On Fri, Sep 18, 2009 at 10:43:03AM +1000, Aristedes Maniatis wrote:
> This is a FreeBSD 7.2 machine in production. I'm not an expert at debugging 
> kernel problems, but I've still got the vmcore if there is anything else I 
> should run on it to extract more information.
It is believed that the problem is fixed in RELENG_7 branch.
If the issue is reproducable, it would worth the efforts to upgrade
at least the kernel to latest RELENG_7 and retest.

> 
> Thanks
> 
> Ari Maniatis
> 
> 
> # uname -a
> FreeBSD dash.internal 7.2-RELEASE-p2 FreeBSD 7.2-RELEASE-p2 #0: Wed Jun 24 
> 00:14:35 UTC 2009     
> root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC  amd64
> 
> 
> #kgdb /boot/kernel/kernel /var/crash/vmcore.3
> GNU gdb 6.1.1 [FreeBSD]
> Copyright 2004 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain 
> conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for details.
> This GDB was configured as "amd64-marcel-freebsd"...
> 
> Unread portion of the kernel message buffer:
> 
> 
> Fatal trap 12: page fault while in kernel mode
> cpuid = 4; apic id = 04
> fault virtual address	= 0x11
> fault code		= supervisor read data, page not present
> instruction pointer	= 0x8:0xffffffff804fbec9
> stack pointer	        = 0x10:0xffffffff7b6a2830
> frame pointer	        = 0x10:0x1
> code segment		= base 0x0, limit 0xfffff, type 0x1b
> 			= DPL 0, pres 1, long 1, def32 0, gran 1
> processor eflags	= interrupt enabled, resume, IOPL = 0
> current process		= 69329 (httpd)
> trap number		= 12
> panic: page fault
> cpuid = 4
> Uptime: 34d3h21m46s
> Physical memory: 24561 MB
> Dumping 5146 MB: 5131 5115 5099 5083 5067 5051 5035 5019 5003 4987 4971 
> 4955 4939 4923 4907 4891 4875 4859 4843 4827 4811 4795 4779 4763 4747 4731 
> 4715 4699 4683 4667 4651 4635 4619 4603 4587 4571 4555 4539 4523 4507 4491 
> 4475 4459 4443 4427 4411 4395 4379 4363 4347 4331 4315 4299 4283 4267 4251 
> 4235 4219 4203 4187 4171 4155 4139 4123 4107 4091 4075 4059 4043 4027 4011 
> 3995 3979 3963 3947 3931 3915 3899 3883 3867 3851 3835 3819 3803 3787 3771 
> 3755 3739 3723 3707 3691 3675 3659 3643 3627 3611 3595 3579 3563 3547 3531 
> 3515 3499 3483 3467 3451 3435 3419 3403 3387 3371 3355 3339 3323 3307 3291 
> 3275 3259 3243 3227 3211 3195 3179 3163 3147 3131 3115 3099 3083 3067 3051 
> 3035 3019 3003 2987 2971 2955 2939 2923 2907 2891 2875 2859 2843 2827 2811 
> 2795 2779 2763 2747 2731 2715 2699 2683 2667 2651 2635 2619 2603 2587 2571 
> 2555 2539 2523 2507 2491 2475 2459 2443 2427 2411 2395 2379 2363 2347 2331 
> 2315 2299 2283 2267 2251 2235 2219 2203 2187 2171 2155 2139 2123 2107 2091 
> 2075 2059 2043 202
> 7 2011 1995 1979 1963 1947 1931 1915 1899 1883 1867 1851 1835 1819 1803 
> 1787 1771 1755 1739 1723 1707 1691 1675 1659 1643 1627 1611 1595 1579 1563 
> 1547 1531 1515 1499 1483 1467 1451 1435 1419 1403 1387 1371 1355 1339 1323 
> 1307 1291 1275 1259 1243 1227 1211 1195 1179 1163 1147 1131 1115 1099 1083 
> 1067 1051 1035 1019 1003 987 971 955 939 923 907 891 875 859 843 827 811 
> 795 779 763 747 731 715 699 683 667 651 635 619 603 587 571 555 539 523 507 
> 491 475 459 443 427 411 395 379 363 347 331 315 299 283 267 251 235 219 203 
> 187 171 155 139 123 107 91 75 59 43 27 11
> 
> Reading symbols from /boot/kernel/zfs.ko...Reading symbols from 
> /bootdir/boot/kernel/zfs.ko.symbols...done.
> done.
> Loaded symbols for /boot/kernel/zfs.ko
> Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols from 
> /bootdir/boot/kernel/opensolaris.ko.symbols...done.
> done.
> Loaded symbols for /boot/kernel/opensolaris.ko
> Reading symbols from /boot/kernel/accf_http.ko...Reading symbols from 
> /bootdir/boot/kernel/accf_http.ko.symbols...done.
> done.
> Loaded symbols for /boot/kernel/accf_http.ko
> Reading symbols from /boot/kernel/ipmi.ko...Reading symbols from 
> /bootdir/boot/kernel/ipmi.ko.symbols...done.
> done.
> Loaded symbols for /boot/kernel/ipmi.ko
> Reading symbols from /boot/kernel/smbus.ko...Reading symbols from 
> /bootdir/boot/kernel/smbus.ko.symbols...done.
> done.
> Loaded symbols for /boot/kernel/smbus.ko
> Reading symbols from /boot/kernel/pflog.ko...Reading symbols from 
> /bootdir/boot/kernel/pflog.ko.symbols...done.
> done.
> Loaded symbols for /boot/kernel/pflog.ko
> Reading symbols from /boot/kernel/pf.ko...Reading symbols from 
> /bootdir/boot/kernel/pf.ko.symbols...done.
> done.
> Loaded symbols for /boot/kernel/pf.ko
> #0  doadump () at pcpu.h:195
> 195	pcpu.h: No such file or directory.
> 	in pcpu.h
> 
> 
> 
> 
> (kgdb) bt
> #0  doadump () at pcpu.h:195
> #1  0x0000000000000004 in ?? ()
> #2  0xffffffff8050df79 in boot (howto=260) at 
> /usr/src/sys/kern/kern_shutdown.c:418
> #3  0xffffffff8050e382 in panic (fmt=0x104 <Address 0x104 out of bounds>) 
> at /usr/src/sys/kern/kern_shutdown.c:574
> #4  0xffffffff807d2253 in trap_fatal (frame=0xffffff0315455370, 
> eva=Variable "eva" is not available.
> ) at /usr/src/sys/amd64/amd64/trap.c:757
> #5  0xffffffff807d2625 in trap_pfault (frame=0xffffffff7b6a2780, 
> usermode=0) at /usr/src/sys/amd64/amd64/trap.c:673
> #6  0xffffffff807d2f64 in trap (frame=0xffffffff7b6a2780) at 
> /usr/src/sys/amd64/amd64/trap.c:444
> #7  0xffffffff807b70ce in calltrap () at 
> /usr/src/sys/amd64/amd64/exception.S:209
> #8  0xffffffff804fbec9 in lf_free_lock (lock=0xffffff03d0518580) at sx.h:153
> #9  0xffffffff804fda14 in lf_advlockasync (ap=Variable "ap" is not 
> available.
> ) at /usr/src/sys/kern/kern_lockf.c:1458
> #10 0xffffffff804fda69 in lf_advlock (ap=Variable "ap" is not available.
> ) at /usr/src/sys/kern/kern_lockf.c:741
> #11 0xffffffff80582270 in vop_stdadvlock (ap=0xffffffff7b6a2a70) at 
> /usr/src/sys/kern/vfs_default.c:222
> #12 0xffffffff804e02a6 in kern_fcntl (td=0xffffff0315455370, fd=Variable 
> "fd" is not available.
> ) at vnode_if.h:1036
> #13 0xffffffff804e0539 in fcntl (td=0xffffff0315455370, 
> uap=0xffffffff7b6a2bf0) at /usr/src/sys/kern/kern_descrip.c:374
> #14 0xffffffff807d28a7 in syscall (frame=0xffffffff7b6a2c80) at 
> /usr/src/sys/amd64/amd64/trap.c:900
> #15 0xffffffff807b72db in Xfast_syscall () at 
> /usr/src/sys/amd64/amd64/exception.S:330
> #16 0x000000080113528c in ?? ()
> Previous frame inner to this frame (corrupt stack?)
> 
> 
> -- 
> 
> -------------------------->
> ish
> http://www.ish.com.au
> Level 1, 30 Wilson Street Newtown 2042 Australia
> phone +61 2 9550 5001   fax +61 2 9550 4001
> GPG fingerprint CBFB 84B4 738D 4E87 5E5C  5EFA EF6A 7D2E 3E49 102A
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090918/a77a5c13/attachment.pgp
From mamalos at eng.auth.gr  Fri Sep 18 08:21:26 2009
From: mamalos at eng.auth.gr (George Mamalakis)
Date: Fri Sep 18 08:21:33 2009
Subject: SASL problems with spnego, heimdal, AND openldap on 8.0-BETA4
Message-ID: <4AB342FF.8020103@eng.auth.gr>

Dear all,

I changed the subject of my email, due to today's results on my 
configurations, regarding SASL authentication on 
openldap-sasl-server-2.4.18_1, with cyrus-sasl-2.1.23, and fbsd's 
8-BETA4 heimdal. When I try to ldapsearch from another machine to the 
openldap server, slapd hangs!

The client goes like that:
(
client-host$ ldapsearch -d 255 -H ldap://ldap.example.com -b 
'dc=example,dc=com'

ldap_url_parse_ext(ldap://ldap.example.com)
ldap_create
ldap_url_parse_ext(ldap://ldap.example.com:389/??base)
ldap_sasl_interactive_bind_s: user selected: GSSAPI
ldap_int_sasl_bind: GSSAPI
ldap_new_connection 1 1 0
ldap_int_open_connection
ldap_connect_to_host: TCP ldap.example.com:389
ldap_new_socket: 3
ldap_prepare_socket: 3
ldap_connect_to_host: Trying 1.2.3.4:389
ldap_pvt_connect: fd: 3 tm: -1 async: 0
ldap_int_sasl_open: host=ldap.example.com
SASL/GSSAPI authentication started
ldap_sasl_bind_s
ldap_sasl_bind
ldap_send_initial_request
ldap_send_server_request
ber_scanf fmt ({it) ber:
ber_dump: buf=0x34142000 ptr=0x34142000 end=0x341422b4 len=692
  0000:  30 82 02 b0 02 01 01 60  82 02 a9 02 01 03 04 00   
0......`........ 
  0010:  a3 82 02 a0 04 06 47 53  53 41 50 49 04 82 02 94   
......GSSAPI.... 
  0020:  60 82 02 90 06 09 2a 86  48 86 f7 12 01 02 02 01   
`.....*.H....... 
  0030:  00 6e 82 02 7f 30 82 02  7b a0 03 02 01 05 a1 03   
.n...0..{....... 
..... packet infrormation.....

ber_scanf fmt ({i) ber:
ber_dump: buf=0x34142000 ptr=0x34142007 end=0x341422b4 len=685
 0000:  60 82 02 a9 02 01 03 04  00 a3 82 02 a0 04 06 47   
`..............G 
  0010:  53 53 41 50 49 04 82 02  94 60 82 02 90 06 09 2a   
SSAPI....`.....* 
  0020:  86 48 86 f7 12 01 02 02  01 00 6e 82 02 7f 30 82   
.H........n...0. 
..... more packet infrormation.....

ber_flush2: 692 bytes to sd 3
  0000:  30 82 02 b0 02 01 01 60  82 02 a9 02 01 03 04 00   
0......`........ 
  0010:  a3 82 02 a0 04 06 47 53  53 41 50 49 04 82 02 94   
......GSSAPI.... 
  0020:  60 82 02 90 06 09 2a 86  48 86 f7 12 01 02 02 01   
`.....*.H....... 
..... even more packet infrormation.....

ldap_write: want=692, written=692
  0000:  30 82 02 b0 02 01 01 60  82 02 a9 02 01 03 04 00   
0......`........ 
  0010:  a3 82 02 a0 04 06 47 53  53 41 50 49 04 82 02 94   
......GSSAPI.... 
..... even even more packet infrormation

ldap_result ld 0x34124040 msgid 1
wait4msg ld 0x34124040 msgid 1 (infinite timeout)
wait4msg continue ld 0x34124040 msgid 1 all 1
** ld 0x34124040 Connections:
* host: ldap.example.com  port: 389  (default)
  refcnt: 2  status: Connected
  last used: Fri Sep 18 11:02:10 2009


** ld 0x34124040 Outstanding Requests:
 * msgid 1,  origid 1, status InProgress
   outstanding referrals 0, parent count 0
  ld 0x34124040 request count 1 (abandoned 0)
** ld 0x34124040 Response Queue:
   Empty
  ld 0x34124040 response count 0
ldap_chkResponseList ld 0x34124040 msgid 1 all 1
ldap_chkResponseList returns ld 0x34124040 NULL
ldap_int_select
read1msg: ld 0x34124040 msgid 1 all 1
ber_get_next
ldap_read: want=8, got=0

ber_get_next failed.
ldap_free_connection 1 0
ldap_free_connection: actually freed
ldap_err2string
ldap_sasl_interactive_bind_s: Can't contact LDAP server (-1)

)

And this is where it loses connection. From the server's point of view, 
the only thing I get from the logs (loglevel args config stats) is:

Sep 18 11:02:08 ldap slapd[2257]: conn=1 fd=13 ACCEPT from 
IP=1.2.3.5:50345 (IP=0.0.0.0:389)
Sep 18 11:02:08 ldap slapd[2257]: connection_get(13)
Sep 18 11:02:08 ldap slapd[2257]: conn=1 op=0 BIND dn="" method=163
Sep 18 11:02:08 ldap slapd[2257]: ==> sasl_bind: dn="" mech=GSSAPI 
datalen=660

And after that the server is down..

I don't know what to do, I'll try to update heimdal to version 1.2.1, as 
John Marshall advised me in his last email..

If anyone knows anything more, I would be delighted if he could share it 
on this list.

Thanx again for  reading.

-- 
George Mamalakis

IT Officer
Electrical and Computer Engineer (Aristotle Un. of Thessaloniki),
MSc (Imperial College of London)

Department of Electrical and Computer Engineering
Faculty of Engineering
Aristotle University of Thessaloniki

phone number : +30 (2310) 994379

From mamalos at eng.auth.gr  Fri Sep 18 11:19:40 2009
From: mamalos at eng.auth.gr (George Mamalakis)
Date: Fri Sep 18 11:19:54 2009
Subject: SASL problems with spnego on 8.0-BETA4
In-Reply-To: <20090918034933.GI1231@rwpc12.mby.riverwillow.net.au>
References: <4AB27FB6.4010806@eng.auth.gr>
	<20090918034933.GI1231@rwpc12.mby.riverwillow.net.au>
Message-ID: <4AB36CC0.6010703@eng.auth.gr>

John Marshall wrote:
> On Thu, 17 Sep 2009, 21:28 +0300, George Mamalakis wrote:
>   
>> Dear all,
>>
>> I am trying to setup ldap with heimdal on my fbsd 8.0-BETA4 and when I 
>> run ldapsearch to see if I can authenticate via GSSAPI I keep getting 
>> the following error:
>>
>> [root@ldap root]# ldapsearch  -H "ldap://ldap.example.com/" -b 
>> "dc=example,dc=com"
>> SASL/GSSAPI authentication started
>> dlopen: /usr/lib/libgssapi_spnego.so.10: Undefined symbol 
>> "GSS_C_NT_HOSTBASED_SERVICE"
>> ldap_sasl_interactive_bind_s: Local error (-2)
>>
>>
>> in ldap.conf (loglevel args stats) I am getting:
>>
>> Sep 17 21:24:46 ldap slapd[44607]: conn=11 fd=13 ACCEPT from 
>> IP=192.168.35.10:32598 (IP=0.0.0.0:389)
>> Sep 17 21:24:46 ldap slapd[44607]: connection_get(13)
>> Sep 17 21:24:46 ldap slapd[44607]: conn=11 fd=13 closed (connection lost)
>>
>> The ports I installed are:
>>
>> cyrus-sasl-2.1.23
>> openldap-sasl-client-2.4.18
>> openldap-sasl-server-2.4.18_1
>>
>> I cannot resolve this issue, so if anyone knows anything, I would be 
>> grateful if I could have a hint.
>>
>> Thank you all for your time in advance.
>>     
>
> I don't remember if the symptoms I saw were identical, but I couldn't
> use GSSAPI to authenticate to OpenLDAP on 8.0-BETA2.  I solved my
> problem by installing a newer Heimdal as a port and then rebuilding
> SASL2 against the newer Heimdal.
>
> NB. To build security/cyrus-sasl2 against the Heimdal port, I added the
> following line to my /usr/local/etc/ports.conf (see:
> ports-mgmt/portconf)
>
>   security/cyrus-sasl2: HEIMDAL_HOME=/usr/local
>
> FreeBSD 8.0 includes Heimdal 1.1.0 in the base system.  The Heimdal port
> is older (1.0.1).  The heimdal-1.2.1 port patch I used was submitted to
> GNATS a couple of hours ago.  No response from GNATS yet but it should
> be available there sometime soon.
>
>   
John,

thank you for your answer, first of all. Now to your email:

Could you please send me the location from where you downloaded the 
heimdal-1.2.1 ? I would really appreciate it if you could send it to me 
to test it on my machine so as to proceed with my configuration. Thank 
you for your time in advance.

-- 
George Mamalakis

IT Officer
Electrical and Computer Engineer (Aristotle Un. of Thessaloniki),
MSc (Imperial College of London)

Department of Electrical and Computer Engineering
Faculty of Engineering
Aristotle University of Thessaloniki

phone number : +30 (2310) 994379

From hiyorin at gmail.com  Fri Sep 18 11:25:28 2009
From: hiyorin at gmail.com (C. C. Tang)
Date: Fri Sep 18 11:25:35 2009
Subject: 7.2-release/amd64: panic, spin lock held too long
In-Reply-To: <4AB21005.6040104@gmail.com>
References: <cf9b1ee00907061812r3da70018i1c8d8d12bb038a80@mail.gmail.com>	
	<3bbf2fe10909121432x7bd4f7es497e9431c4e520d6@mail.gmail.com>	
	<cf9b1ee00909121502v66566b46p754ed2f2e549555@mail.gmail.com>	
	<4AB1A838.2040406@gmail.com>
	<3bbf2fe10909170216u29d994aj55c21efdfbc26ba5@mail.gmail.com>
	<4AB21005.6040104@gmail.com>
Message-ID: <4AB36E1F.6080401@gmail.com>

> Attilio Rao wrote:
>> 2009/9/17 C. C. Tang <hiyorin@gmail.com>:
>>>>> Dan, is that machine equipped with Hyperthreading?
>>>>>
>>>>> Attilio
>>>> Yes. It's an Intel Atom 330, which is a dualcore CPU with HT (4 cores
>>>> visible in "top" as a result)
>>> Yes, mine is also Atom 330.
>>>
>>> I cannot test the patch because my machine is also in production now. 
>>> But I
>>> have tested it with hyperthreading.
>>> powerd with HyperThreading -> spin lock hold too long
>>> powerd without HyperThreading -> no problem
>>> no powerd with/without HyperThreading -> no problem
>>
>> But these are with the last patch I posted in?
>> (specifically, for 7.2:
>> http://www.freebsd.org/~attilio/sched_ule.diff
>> )
>>
>> So with the patch in, powerd and hyperthreading on you still get a 
>> deadlock?
>>
>> Attilio
>>
>>
I have patched the sched_ule.c and did a make buildkernel & make 
installkernel (is buildworld and installworld necessary?), rebooted and 
the machine is running now.
I will post here again if there is any update.

Thanks,
C.C.
From dalroi at solfertje.student.utwente.nl  Fri Sep 18 12:42:29 2009
From: dalroi at solfertje.student.utwente.nl (Alban Hertroys)
Date: Fri Sep 18 13:58:30 2009
Subject: Kernel panic in ulpt
In-Reply-To: <200909140841.27844.jhb@freebsd.org>
References: <B41B0A0F-63D7-42DD-B095-504E8A572B34@solfertje.student.utwente.nl>
	<200909140841.27844.jhb@freebsd.org>
Message-ID: <030D00B7-7AAE-4730-8FB6-766233969E05@solfertje.student.utwente.nl>

On 14 Sep 2009, at 14:41, John Baldwin wrote:

> On Friday 11 September 2009 12:18:39 pm Alban Hertroys wrote:
>> Hello,
>>
>> I just got a kernel panic on a FreeBSD 7.2 STABLE after a print job
>> finished on ulpt. The kgdb output (ran in script) is attached. I'll
>> keep the vmcore around in case anyone needs more info. Shout if you
>> need more info.
>
> In ulptclose() in sys/dev/usb/ulpt.c try changing the callout_stop()  
> to a
> callout_drain().  Have you been able to reproduce this?


Thanks,

I finally got around to testing the above, but unfortunately it  
doesn't fix the problem. Meanwhile I did configure savecore (the  
default /var isn't large enough for the core files) and crashinfo  
though, see attachments.

I send print jobs to my FreeBSD server from my Mac using cups on both  
sides. The panic appears to be related to what I print, even though  
that shouldn't matter at all at the driver-level.
The first document I printed was a large JPEG turned on its side and  
printed alright, without a panic.
After that I printed page 106 from a PDF-version of the FreeBSD  
handbook (section 3.2.6 Changing Console Video Modes) that I  
downloaded at June 3rd this year and the below panic occurred.

The previous panic I posted about was also caused by a 1-page PDF  
document.

Is there anything else I can provide to help fix this problem?



!DSPAM:74,4ab3803211681401413422!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: core.txt.0
Type: application/octet-stream
Size: 252219 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090918/e4ef6734/core.txt-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: info.0
Type: application/octet-stream
Size: 468 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090918/e4ef6734/info-0001.obj
-------------- next part --------------

Alban Hertroys

--
If you can't see the forest for the trees,
cut the trees and you'll see there is no forest.



!DSPAM:74,4ab3803211681401413422!
From rmacklem at uoguelph.ca  Fri Sep 18 16:17:20 2009
From: rmacklem at uoguelph.ca (Rick Macklem)
Date: Fri Sep 18 16:17:27 2009
Subject: SASL problems with spnego on 8.0-BETA4
In-Reply-To: <20090918034933.GI1231@rwpc12.mby.riverwillow.net.au>
References: <4AB27FB6.4010806@eng.auth.gr>
	<20090918034933.GI1231@rwpc12.mby.riverwillow.net.au>
Message-ID: <Pine.GSO.4.63.0909181218140.12411@muncher.cs.uoguelph.ca>



On Fri, 18 Sep 2009, John Marshall wrote:

> On Thu, 17 Sep 2009, 21:28 +0300, George Mamalakis wrote:
>> Dear all,
>>
>> I am trying to setup ldap with heimdal on my fbsd 8.0-BETA4 and when I
>> run ldapsearch to see if I can authenticate via GSSAPI I keep getting
>> the following error:
>>
>> [root@ldap root]# ldapsearch  -H "ldap://ldap.example.com/" -b
>> "dc=example,dc=com"
>> SASL/GSSAPI authentication started
>> dlopen: /usr/lib/libgssapi_spnego.so.10: Undefined symbol
>> "GSS_C_NT_HOSTBASED_SERVICE"
>> ldap_sasl_interactive_bind_s: Local error (-2)
>>
GSS_C_NT_HOSTBASED_SERVICE is defined in gss_names.o in libgssapi.

I don't know diddly about ldap (like a lot of the stuff I've been
posting w.r.t. lately, it seems:-), but maybe an extra "-lgssapi"
at the end of the libraries list for the Makefile, might help?
(ie. I'm guessing that maybe gss_names.o doesn't get pulled out
of libgssapi, since nothing that comes before it uses any of the
globals in it and -lgssapi_spnego is listed after it.)

One difference between the vanilla Heimdal and the one in FreeBSD
is where the globals live in the libraries.

Just a shot in the dark, rick

From bc979 at lafn.org  Fri Sep 18 20:34:33 2009
From: bc979 at lafn.org (Doug Hardie)
Date: Fri Sep 18 20:34:40 2009
Subject: Problems with 8.0 Beta 4
Message-ID: <4AC7C662-3BEE-4459-AF65-B04D4417503B@lafn.org>

I have switched to working hardware.  Sure makes a difference ;-)

Now I am down to a couple issues:

1.  When booting I first get the following:

F1: FreeBSD
F5: Drive 0

F6: PXE
Boot: F1

At that point it just sits and starts adding #s at the end of the Boot  
statement.  If I press F5 (none of the other F keys do anything), then  
I get another Boot:  F1 line and its sits for a moment and then boots  
from the disk.  I used the standard install with the FreeBSD Boot  
Loader.

After that the system comes up and runs fine.  I am only using it for  
network testing so haven't placed any great load on it but everything  
I have tried works fine - until I try and shut it down.  Then I get a  
panic at the very end.  It also does not shut off the power.  I have a  
console log of the entire boot/shutdown process.  The only user  
command I entered was shutdown -p now.

/boot.config: -Dh
Consoles: internal video/keyboard  serial port
BIOS drive A: is disk0
BIOS drive C: is disk1
BIOS 638kB/64512kB available memory

FreeBSD/i386 bootstrap loader, Revision 1.1
(root@almeida.cse.buffalo.edu, Sun Sep  6 03:42:03 UTC 2009)
Loading /boot/defaults/loader.conf
/boot/kernel/kernel text=0x8b2774 data=0xde874+0x1feb04 syms= 
[0x4+0x9c300+0
x4+0xd55bb]
|


  ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD?
  3                                         3
  3                                         3      ______
  3                                         3     |  ____| __ ___  ___
  3          Welcome to FreeBSD!            3     | |__ | '__/ _ \/ _ \
  3                                         3     |  __|| | |  __/  __/
  3                                         3     | |   | | |    |    |
  3  1. Boot FreeBSD [default]              3     |_|   |_|  \___|\___|
  3  2. Boot FreeBSD with ACPI enabled      3      ____   _____ _____
  3  3. Boot FreeBSD in Safe Mode           3     |  _ \ / ____|  __ \
  3  4. Boot FreeBSD in single user mode    3     | |_) | (___ | |  | |
  3  5. Boot FreeBSD with verbose logging   3     |  _ < \___ \| |  | |
  3  6. Escape to loader prompt             3     | |_) |____) | |__| |
  3  7. Reboot                              3     |     |      |      |
  3                                         3     |____/|_____/|_____/
  3                                         3
  3                                         3
  3                                         3
  3  Select option, [Enter] for default     3
  3  or [Space] to pause timer  7           3
  @DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY


GDB: no debug ports present
KDB: debugger backends: ddb
KDB: current backend: ddb
Copyright (c) 1992-2009 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
         The Regents of the University of California. All rights  
reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 8.0-BETA4 #0: Sun Sep  6 05:51:03 UTC 2009
     root@almeida.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC
WARNING: WITNESS option enabled, expect reduced performance.
Timecounter "i8254" frequency 1193182 Hz quality 0
CPU: Pentium II/Pentium II Xeon/Celeron (233.29-MHz 686-class CPU)
   Origin = "GenuineIntel"  Id = 0x634  Stepping = 4
    
Features 
=0x80f9ff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMO
V,MMX>
real memory  = 67108864 (64 MB)
avail memory = 46567424 (44 MB)
kbd1 at kbdmux0
ACPI Error: A valid RSDP was not found 20090521 tbxfroot-309
ACPI: Table initialisation failed: AE_NOT_FOUND
ACPI: Try disabling either ACPI or apic support.
pcib0: <Intel 82443LX (440 LX) host to PCI bridge> pcibus 0 on  
motherboard
pir0: <PCI Interrupt Routing Table: 7 Entries> on motherboard
pci0: <PCI bus> on pcib0
agp0: <Intel 82443LX (440 LX) host to PCI bridge> on hostb0
pcib1: <PCI-PCI bridge> at device 1.0 on pci0
pci1: <PCI bus> on pcib1
$PIR: ROUTE_INTERRUPT failed.
vgapci0: <VGA-compatible display> mem 0xfedc0000-0xfeddffff, 
0xfd800000-0xfd
ffffff,0xfe000000-0xfe7fffff irq 9 at device 0.0 on pci1
isab0: <PCI-ISA bridge> at device 7.0 on pci0
isa0: <ISA bus> on isab0
atapci0: <Intel PIIX4 UDMA33 controller> port  
0x1f0-0x1f7,0x3f6,0x170-0x177
,0x376,0xfcf0-0xfcff at device 7.1 on pci0
ata0: <ATA channel 0> on atapci0
ata0: [ITHREAD]
ata1: <ATA channel 1> on atapci0
ata1: [ITHREAD]
uhci0: <Intel 82371AB/EB (PIIX4) USB controller> port 0xfcc0-0xfcdf  
irq 11
at device 7.2 on pci0
uhci0: [ITHREAD]
usbus0: <Intel 82371AB/EB (PIIX4) USB controller> on uhci0
piix0: <PIIX Timecounter> port 0x7000-0x700f at device 7.3 on pci0
Timecounter "PIIX" frequency 3579545 Hz quality 0
xl0: <3Com 3c905-TX Fast Etherlink XL> port 0xfc40-0xfc7f irq 10 at  
device
13.0 on pci0
miibus0: <MII bus> on xl0
nsphy0: <DP83840 10/100 media interface> PHY 24 on miibus0
nsphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
xl0: Ethernet address: 00:10:4b:2c:bb:09
xl0: [ITHREAD]
cpu0 on motherboard
pmtimer0 on isa0
unknown: <PNP0c02> can't assign resources (port)
unknown: <PNP0c02> can't assign resources (memory)
unknown: <System Memory> can't assign resources (memory)
atrtc0: <AT realtime clock> at port 0x70-0x71 irq 8 pnpid PNP0b00 on  
isa0
atkbdc0: <Keyboard controller (i8042)> at port 0x60,0x64 irq 1 pnpid  
PNP030
3 on isa0
atkbd0: <AT Keyboard> irq 1 on atkbdc0
kbd0 at atkbd0
atkbd0: [GIANT-LOCKED]
atkbd0: [ITHREAD]
uart0: <16550 or compatible> at port 0x3f8-0x3ff irq 4 flags 0x10  
pnpid PNP
0501 on isa0
uart0: [FILTER]
uart0: console (9600,n,8,1)
fdc0: <Enhanced floppy controller> at port 0x3f0-0x3f5,0x3f7 irq 6 drq  
2 pn
pid PNP0700 on isa0
fdc0: [FILTER]
fd0: <1440-KB 3.5" drive> on fdc0 drive 0
ppc0: <Standard parallel printer port> at port 0x378-0x37f irq 7 pnpid  
PNP0
400 on isa0
ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode
ppc0: [ITHREAD]
ppbus0: <Parallel port bus> on ppc0
plip0: <PLIP network interface> on ppbus0
plip0: [ITHREAD]
lpt0: <Printer> on ppbus0
lpt0: [ITHREAD]
lpt0: Interrupt-driven port
ppi0: <Parallel I/O> on ppbus0
orm0: <ISA Option ROMs> at iomem 0xc0000-0xc6fff,0xe4000-0xeffff pnpid  
ORM0
000 on isa0
sc0: <System console> at flags 0x100 on isa0
sc0: VGA <16 virtual consoles, flags=0x300>
vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on  
isa0
unknown: <PNP0c02> can't assign resources (port)
unknown: <PNP0c02> can't assign resources (memory)
unknown: <System Memory> can't assign resources (memory)
Timecounter "TSC" frequency 233289523 Hz quality 800
Timecounters tick every 1.000 msec
usbus0: 12Mbps Full Speed USB v1.0
ad0: 2014MB <WDC AC12100L 09.09M08> at ata0-master UDMA33
ugen0.1: <Intel> at usbus0
uhub0: <Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus0
acd0: CDROM <TOSHIBA CD-ROM XM-6202B/1110> at ata1-master PIO4
WARNING: WITNESS option enabled, expect reduced performance.
uhub0: 2 ports with 2 removable, self powered
GEOM: ad0s1: geometry does not match label (255h,63s != 16h,63s).
Trying to mount root from ufs:/dev/ad0s1a
Entropy harvesting: interrupts ethernet point_to_point kickstart.
/dev/ad0s1a: FILE SYSTEM CLEAN; SKIPPING CHECKS
/dev/ad0s1a: clean, 165348 free (3260 frags, 20261 blocks, 1.3%  
fragmentati
on)
/dev/ad0s1d: FILE SYSTEM CLEAN; SKIPPING CHECKS
/dev/ad0s1d: clean, 487494 free (5150 frags, 60293 blocks, 0.7%  
fragmentati
on)
/etc/rc: WARNING: $hostname is not set -- see rc.conf(5).
Starting Network: lo0.
xl0: link state changed to DOWN
Configuring syscons: blanktime.

Fri Sep 18 13:38:17 PDT 2009
Sep 18 13:38:53  su: doug to root on /dev/ttyv0
Sep 18 13:39:10  shutdown: power-down by doug:
Stopping cron.
Stopping sshd.
Stopping devd.
Writing entropy file:.
Terminated
.
Sep 18 13:39:20  syslogd: exiting on signal 15
Waiting (max 60 seconds) for system process `vnlru' to stop...done
Waiting (max 60 seconds) for system process `bufdaemon' to stop...done
Waiting (max 60 seconds) for system process `syncer' to stop...
Syncing disks, vnodes remaining...0 0 done
All buffers synced.
lock order reversal:
  1st 0xc1eac8b8 ufs (ufs) @ /usr/src/sys/kern/vfs_mount.c:1200
  2nd 0xc1fdfce8 devfs (devfs) @ /usr/src/sys/ufs/ffs/ffs_vfsops.c:1194
KDB: stack backtrace:
db_trace_self_wrapper 
(c0c74987,c1bd399c,c08c0f75,c08b1cfb,c0c7785a,...) at
db_trace_self_wrapper+0x26
kdb_backtrace(c08b1cfb,c0c7785a,c1d2e938,c1d2e868,c1bd39f8,...) at  
kdb_back
trace+0x29
_witness_debugger(c0c7785a,c1fdfce8,c0c667ac,c1d2e868,c0c97ee0,...) at  
_wit
ness_debugger+0x25
witness_checkorder(c1fdfce8,9,c0c97ee0,4aa,c1fdfd04,...) at  
witness_checkor
der+0x839
__lockmgr_args(c1fdfce8,80400,c1fdfd04,0,0,...) at __lockmgr_args+0x7a7
vop_stdlock(c1bd3b00,556,c1bd3af8,80400,c1fdfc90,...) at vop_stdlock 
+0x62
VOP_LOCK1_APV(c0d535c0,c1bd3b00,c2020860,c0d90c80,c1fdfc90,...) at  
VOP_LOCK
1_APV+0xb5
_vn_lock(c1fdfc90,80400,c0c97ee0,4aa,c1fd2400,...) at _vn_lock+0x5e
ffs_flushfiles(c1f84a10,2,c1d6fd80,556,3,...) at ffs_flushfiles+0xa7
softdep_flushfiles(c1f84a10,2,c1d6fd80,c0c7eaec,8aa,...) at  
softdep_flushfi
les+0x2e
ffs_unmount(c1f84a10,80000,c1bd3bf4,4f5,c1bd3c00,...) at ffs_unmount 
+0x149
dounmount(c1f84a10,80000,c1d6fd80,c341fc50,0,...) at dounmount+0x46d
vfs_unmountall(c0c7e7c4,0,c0c715f2,129,0,...) at vfs_unmountall+0x4e
boot(c0dc4f70,0,c0c715f2,ac,bfbfe9c0,...) at boot+0x44f
reboot(c1d6fd80,c1bd3cf8,4,c0c78ac5,c0d56f04,...) at reboot+0x69
syscall(c1bd3d38) at syscall+0x2a3
Xint0x80_syscall() at Xint0x80_syscall+0x20
--- syscall (55, FreeBSD ELF32, reboot), eip = 0x8050f83, esp =  
0xbfbfe88c,
  ebp = 0xbfbfe968 ---
Uptime: 1m45s

The operating system has halted.
Please press any key to reboot.


From rmacklem at uoguelph.ca  Fri Sep 18 21:32:41 2009
From: rmacklem at uoguelph.ca (Rick Macklem)
Date: Fri Sep 18 21:32:53 2009
Subject: SASL problems with spnego on 8.0-BETA4
In-Reply-To: <20090918034933.GI1231@rwpc12.mby.riverwillow.net.au>
References: <4AB27FB6.4010806@eng.auth.gr>
	<20090918034933.GI1231@rwpc12.mby.riverwillow.net.au>
Message-ID: <Pine.GSO.4.63.0909181722270.23193@muncher.cs.uoguelph.ca>



On Fri, 18 Sep 2009, John Marshall wrote:

> On Thu, 17 Sep 2009, 21:28 +0300, George Mamalakis wrote:
>> Dear all,
>>
>> I am trying to setup ldap with heimdal on my fbsd 8.0-BETA4 and when I
>> run ldapsearch to see if I can authenticate via GSSAPI I keep getting
>> the following error:
>>
>> [root@ldap root]# ldapsearch  -H "ldap://ldap.example.com/" -b
>> "dc=example,dc=com"
>> SASL/GSSAPI authentication started
>> dlopen: /usr/lib/libgssapi_spnego.so.10: Undefined symbol
>> "GSS_C_NT_HOSTBASED_SERVICE"
>> ldap_sasl_interactive_bind_s: Local error (-2)
>>
I don't know if you guys feel like experimenting, but here's what little
I know about the heimdal/gssapi setup.

When cyrus-sasl2 builds, it uses the little shell script
/usr/bin/krb5-config with the args. "--libs gssapi" to get the list of
libraries to link against. This doesn't return "-lgssapi_spnego" in the
list. (The list can be changed by editting line #96 of 
/usr/bin/krb5-config.)

Nothing seems to link against "-lgssapi_spnego", so it's a mystery to
me how it ends up using it? (Maybe others with knowledge on how FreeBSD
loads libraries can explain it. The library is listed in /etc/gss/mech.)

GSS_C_NT_HOSTBASED_SERVICE is defined in the file gss_names.o in 
"-lgssapi", which is at the beginning of the list of libraries 
returned by "krb5-config --libs gssapi".

I'm hoping that someone who understands how libraries get loaded can
solve the puzzle, but barring that, you could try added "-lgssapi_spnego"
to line #96 of /usr/bin/krb5-config in front of "-lgssapi" and see if that
gets things to load properly?

Not much help, but I don't know how to test this stuff, rick

From sam at freebsd.org  Fri Sep 18 23:18:45 2009
From: sam at freebsd.org (Sam Leffler)
Date: Fri Sep 18 23:18:52 2009
Subject: SASL problems with spnego on 8.0-BETA4
In-Reply-To: <Pine.GSO.4.63.0909181722270.23193@muncher.cs.uoguelph.ca>
References: <4AB27FB6.4010806@eng.auth.gr>	<20090918034933.GI1231@rwpc12.mby.riverwillow.net.au>
	<Pine.GSO.4.63.0909181722270.23193@muncher.cs.uoguelph.ca>
Message-ID: <4AB40DC7.2060808@freebsd.org>

Rick Macklem wrote:
> 
> 
> On Fri, 18 Sep 2009, John Marshall wrote:
> 
>> On Thu, 17 Sep 2009, 21:28 +0300, George Mamalakis wrote:
>>> Dear all,
>>>
>>> I am trying to setup ldap with heimdal on my fbsd 8.0-BETA4 and when I
>>> run ldapsearch to see if I can authenticate via GSSAPI I keep getting
>>> the following error:
>>>
>>> [root@ldap root]# ldapsearch  -H "ldap://ldap.example.com/" -b
>>> "dc=example,dc=com"
>>> SASL/GSSAPI authentication started
>>> dlopen: /usr/lib/libgssapi_spnego.so.10: Undefined symbol
>>> "GSS_C_NT_HOSTBASED_SERVICE"
>>> ldap_sasl_interactive_bind_s: Local error (-2)
>>>
> I don't know if you guys feel like experimenting, but here's what little
> I know about the heimdal/gssapi setup.
> 
> When cyrus-sasl2 builds, it uses the little shell script
> /usr/bin/krb5-config with the args. "--libs gssapi" to get the list of
> libraries to link against. This doesn't return "-lgssapi_spnego" in the
> list. (The list can be changed by editting line #96 of
> /usr/bin/krb5-config.)
> 
> Nothing seems to link against "-lgssapi_spnego", so it's a mystery to
> me how it ends up using it? (Maybe others with knowledge on how FreeBSD
> loads libraries can explain it. The library is listed in /etc/gss/mech.)
> 
> GSS_C_NT_HOSTBASED_SERVICE is defined in the file gss_names.o in
> "-lgssapi", which is at the beginning of the list of libraries returned
> by "krb5-config --libs gssapi".
> 
> I'm hoping that someone who understands how libraries get loaded can
> solve the puzzle, but barring that, you could try added "-lgssapi_spnego"
> to line #96 of /usr/bin/krb5-config in front of "-lgssapi" and see if that
> gets things to load properly?
> 
> Not much help, but I don't know how to test this stuff, rick

FWIW I hit the same problem (I think) with cyrus imap and saslauthd.  I
am running HEAD and tried building w/ and w/o kerberos enabled but
cyradm aborts on startup complaining about the missing symbol.  I
started digging because I couldn't get cyrus imap to authenticate users.
 Feels like one or more of these ports are busted.

	Sam
From john.marshall at riverwillow.com.au  Fri Sep 18 23:22:08 2009
From: john.marshall at riverwillow.com.au (John Marshall)
Date: Fri Sep 18 23:22:15 2009
Subject: SASL problems with spnego on 8.0-BETA4
In-Reply-To: <4AB36CC0.6010703@eng.auth.gr>
References: <4AB27FB6.4010806@eng.auth.gr>
	<20090918034933.GI1231@rwpc12.mby.riverwillow.net.au>
	<4AB36CC0.6010703@eng.auth.gr>
Message-ID: <20090918232200.GJ1231@rwpc12.mby.riverwillow.net.au>

On Fri, 18 Sep 2009, 14:19 +0300, George Mamalakis wrote:
> Could you please send me the location from where you downloaded the 
> heimdal-1.2.1 ? I would really appreciate it if you could send it to me 
> to test it on my machine so as to proceed with my configuration. Thank 
> you for your time in advance.

The security/heimdal port patch is now in GNATS.  Just apply the patch
to the security/heimdal port in your ports tree and install the port.

<http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/138929>

But I think Rick Macklem is onto something with his /usr/bin/krb5-config
idea and suggest that you try that first - before introducing a Heimdal
port to your system.

-- 
John Marshall
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090918/50ff7655/attachment.pgp
From john.marshall at riverwillow.com.au  Fri Sep 18 23:32:06 2009
From: john.marshall at riverwillow.com.au (John Marshall)
Date: Fri Sep 18 23:32:13 2009
Subject: SASL problems with spnego on 8.0-BETA4
In-Reply-To: <Pine.GSO.4.63.0909181722270.23193@muncher.cs.uoguelph.ca>
References: <4AB27FB6.4010806@eng.auth.gr>
	<20090918034933.GI1231@rwpc12.mby.riverwillow.net.au>
	<Pine.GSO.4.63.0909181722270.23193@muncher.cs.uoguelph.ca>
Message-ID: <20090918233157.GK1231@rwpc12.mby.riverwillow.net.au>

On Fri, 18 Sep 2009, 17:38 -0400, Rick Macklem wrote:
> When cyrus-sasl2 builds, it uses the little shell script
> /usr/bin/krb5-config with the args. "--libs gssapi" to get the list of
> libraries to link against. This doesn't return "-lgssapi_spnego" in the
> list. (The list can be changed by editting line #96 of 
> /usr/bin/krb5-config.)

I think this sounds promising!  It makes sense.  Thanks for pointing us
in this direction.

I should already be out at a customer site but I hope to do some poking
in krb5-config early next week to see if that might be the key to
resolving the (non-spnego) kerberos problems I've been having with 8.0.
In my case, I'll be seeing what joy I get by adding -lgssapi_krb5.

-- 
John Marshall
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090918/b9126e0d/attachment.pgp
From faber at isi.edu  Sat Sep 19 03:52:15 2009
From: faber at isi.edu (Ted Faber)
Date: Sat Sep 19 03:52:24 2009
Subject: PATA disks/DVD not detected on ATI IXP 700 - cannot boot (dmesg
	attached)
In-Reply-To: <20090916161327.GB87631@zod.isi.edu>
References: <20090916161327.GB87631@zod.isi.edu>
Message-ID: <20090919035214.GA12889@zod.isi.edu>

Skipped content of type multipart/mixed-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090919/2fb4c834/attachment.pgp
From dan.naumov at gmail.com  Sat Sep 19 09:04:06 2009
From: dan.naumov at gmail.com (Dan Naumov)
Date: Sat Sep 19 09:04:13 2009
Subject: 7.2-release/amd64: panic, spin lock held too long
In-Reply-To: <4AB36E1F.6080401@gmail.com>
References: <cf9b1ee00907061812r3da70018i1c8d8d12bb038a80@mail.gmail.com>
	<3bbf2fe10909121432x7bd4f7es497e9431c4e520d6@mail.gmail.com>
	<cf9b1ee00909121502v66566b46p754ed2f2e549555@mail.gmail.com>
	<4AB1A838.2040406@gmail.com>
	<3bbf2fe10909170216u29d994aj55c21efdfbc26ba5@mail.gmail.com>
	<4AB21005.6040104@gmail.com> <4AB36E1F.6080401@gmail.com>
Message-ID: <cf9b1ee00909190204q33ded00dyb86a4b53ed5194be@mail.gmail.com>

On Fri, Sep 18, 2009 at 2:25 PM, C. C. Tang <hiyorin@gmail.com> wrote:
>> Attilio Rao wrote:
>>>
>>> 2009/9/17 C. C. Tang <hiyorin@gmail.com>:
>>>>>>
>>>>>> Dan, is that machine equipped with Hyperthreading?
>>>>>>
>>>>>> Attilio
>>>>>
>>>>> Yes. It's an Intel Atom 330, which is a dualcore CPU with HT (4 cores
>>>>> visible in "top" as a result)
>>>>
>>>> Yes, mine is also Atom 330.
>>>>
>>>> I cannot test the patch because my machine is also in production now.
>>>> But I
>>>> have tested it with hyperthreading.
>>>> powerd with HyperThreading -> spin lock hold too long
>>>> powerd without HyperThreading -> no problem
>>>> no powerd with/without HyperThreading -> no problem
>>>
>>> But these are with the last patch I posted in?
>>> (specifically, for 7.2:
>>> http://www.freebsd.org/~attilio/sched_ule.diff
>>> )
>>>
>>> So with the patch in, powerd and hyperthreading on you still get a
>>> deadlock?
>>>
>>> Attilio
>>>
>>>
> I have patched the sched_ule.c and did a make buildkernel & make
> installkernel (is buildworld and installworld necessary?), rebooted and the
> machine is running now.
> I will post here again if there is any update.

Considering we are at RC1 right now, is there any chance this patch
makes it into 8.0 release if the patch fixes the issue and doesn't
cause any regressions? Unfortunately I can't test it myself right now,
so I have to rely on other people experiencing the same issue to see
if the patch fixes it.

- Dan
From mamalos at eng.auth.gr  Sat Sep 19 09:58:48 2009
From: mamalos at eng.auth.gr (mamalos@eng.auth.gr)
Date: Sat Sep 19 09:58:56 2009
Subject: SASL problems with spnego on 8.0-BETA4
In-Reply-To: <20090918233157.GK1231@rwpc12.mby.riverwillow.net.au>
References: <4AB27FB6.4010806@eng.auth.gr>
	<20090918034933.GI1231@rwpc12.mby.riverwillow.net.au>
	<Pine.GSO.4.63.0909181722270.23193@muncher.cs.uoguelph.ca>
	<20090918233157.GK1231@rwpc12.mby.riverwillow.net.au>
Message-ID: <20090919125839.2z9gt5gtww884wgg@mail.eng.auth.gr>

Quoting John Marshall <john.marshall@riverwillow.com.au>:

> On Fri, 18 Sep 2009, 17:38 -0400, Rick Macklem wrote:
>> When cyrus-sasl2 builds, it uses the little shell script
>> /usr/bin/krb5-config with the args. "--libs gssapi" to get the list of
>> libraries to link against. This doesn't return "-lgssapi_spnego" in the
>> list. (The list can be changed by editting line #96 of
>> /usr/bin/krb5-config.)
>
> I think this sounds promising!  It makes sense.  Thanks for pointing us
> in this direction.
>
> I should already be out at a customer site but I hope to do some poking
> in krb5-config early next week to see if that might be the key to
> resolving the (non-spnego) kerberos problems I've been having with 8.0.
> In my case, I'll be seeing what joy I get by adding -lgssapi_krb5.
>
> --
> John Marshall
>

Guys,

you have all been more than just helpful! Thank you all for your  
instant and well pointed directions. I will try what Rick said about  
krb5-config on Monday morning, when I will get to work. If that won't  
work, I'll try John's view on the issue.

In any case I'll send feedback to the list.

Thank you all, once more, for your help and thoughts.

mamalos


-- 
George Mamalakis

IT Officer
Electrical and Computer Engineer (Aristotle Un. of Thessaloniki),
MSc (Imperial College of London)

Department of Electrical and Computer Engineering
Faculty of Engineering
Aristotle University of Thessaloniki

phone number : +30 (2310) 994379


From attilio at freebsd.org  Sat Sep 19 19:24:25 2009
From: attilio at freebsd.org (Attilio Rao)
Date: Sat Sep 19 19:24:36 2009
Subject: 7.2-release/amd64: panic, spin lock held too long
In-Reply-To: <cf9b1ee00909190204q33ded00dyb86a4b53ed5194be@mail.gmail.com>
References: <cf9b1ee00907061812r3da70018i1c8d8d12bb038a80@mail.gmail.com>
	<3bbf2fe10909121432x7bd4f7es497e9431c4e520d6@mail.gmail.com>
	<cf9b1ee00909121502v66566b46p754ed2f2e549555@mail.gmail.com>
	<4AB1A838.2040406@gmail.com>
	<3bbf2fe10909170216u29d994aj55c21efdfbc26ba5@mail.gmail.com>
	<4AB21005.6040104@gmail.com> <4AB36E1F.6080401@gmail.com>
	<cf9b1ee00909190204q33ded00dyb86a4b53ed5194be@mail.gmail.com>
Message-ID: <3bbf2fe10909191224m6061d325h8bc1a389e195aa30@mail.gmail.com>

2009/9/19 Dan Naumov <dan.naumov@gmail.com>:
> On Fri, Sep 18, 2009 at 2:25 PM, C. C. Tang <hiyorin@gmail.com> wrote:
>>> Attilio Rao wrote:
>>>>
>>>> 2009/9/17 C. C. Tang <hiyorin@gmail.com>:
>>>>>>>
>>>>>>> Dan, is that machine equipped with Hyperthreading?
>>>>>>>
>>>>>>> Attilio
>>>>>>
>>>>>> Yes. It's an Intel Atom 330, which is a dualcore CPU with HT (4 cores
>>>>>> visible in "top" as a result)
>>>>>
>>>>> Yes, mine is also Atom 330.
>>>>>
>>>>> I cannot test the patch because my machine is also in production now.
>>>>> But I
>>>>> have tested it with hyperthreading.
>>>>> powerd with HyperThreading -> spin lock hold too long
>>>>> powerd without HyperThreading -> no problem
>>>>> no powerd with/without HyperThreading -> no problem
>>>>
>>>> But these are with the last patch I posted in?
>>>> (specifically, for 7.2:
>>>> http://www.freebsd.org/~attilio/sched_ule.diff
>>>> )
>>>>
>>>> So with the patch in, powerd and hyperthreading on you still get a
>>>> deadlock?
>>>>
>>>> Attilio
>>>>
>>>>
>> I have patched the sched_ule.c and did a make buildkernel & make
>> installkernel (is buildworld and installworld necessary?), rebooted and the
>> machine is running now.
>> I will post here again if there is any update.
>
> Considering we are at RC1 right now, is there any chance this patch
> makes it into 8.0 release if the patch fixes the issue and doesn't
> cause any regressions? Unfortunately I can't test it myself right now,
> so I have to rely on other people experiencing the same issue to see
> if the patch fixes it.

I alredy committed it to STABLE_8 and then it will make it for sure.

Attilio


-- 
Peace can only be achieved by understanding - A. Einstein
From rmacklem at uoguelph.ca  Sat Sep 19 23:56:27 2009
From: rmacklem at uoguelph.ca (Rick Macklem)
Date: Sat Sep 19 23:56:34 2009
Subject: SASL problems with spnego on 8.0-BETA4
In-Reply-To: <4AB40DC7.2060808@freebsd.org>
References: <4AB27FB6.4010806@eng.auth.gr>
	<20090918034933.GI1231@rwpc12.mby.riverwillow.net.au>
	<Pine.GSO.4.63.0909181722270.23193@muncher.cs.uoguelph.ca>
	<4AB40DC7.2060808@freebsd.org>
Message-ID: <Pine.GSO.4.63.0909191939000.698@muncher.cs.uoguelph.ca>



On Fri, 18 Sep 2009, Sam Leffler wrote:

>
> FWIW I hit the same problem (I think) with cyrus imap and saslauthd.  I
> am running HEAD and tried building w/ and w/o kerberos enabled but
> cyradm aborts on startup complaining about the missing symbol.  I
> started digging because I couldn't get cyrus imap to authenticate users.
> Feels like one or more of these ports are busted.
>
This change might actually be worth trying... I diff'd the Makefile
for openldap-2.4.18 vs openldap-2.4.15 created by ports and found this
(along with the expected version change stuff). You could try patching
your Makefile in the openldap-2.4.18 directory (this was the one
created under net/openldap24-sasl-client/work).

rick
ps: I'll try the same "diff Makefile" trick for the cyrus stuff.
--- Makefile.openldap-2.4.18	Sat Sep 19 19:24:22 2009
+++ Makefile.openldap-2.4.15	Sat Sep 19 19:23:49 2009
@@ -187,9 +187,10 @@
  KRB5_LIBS =
  KRB_LIBS =
  SASL_LIBS = -lsasl2
+GSSAPI_LIBS = -lgssapi
  TLS_LIBS = -lssl -lcrypto
  AUTH_LIBS = 
-SECURITY_LIBS = $(SASL_LIBS) $(KRB_LIBS) $(TLS_LIBS) $(AUTH_LIBS)
+SECURITY_LIBS = $(SASL_LIBS) $(KRB_LIBS) $(GSSAPI_LIBS) $(TLS_LIBS) $(AUTH_LIBS)
  ICU_LIBS =

  MODULES_CPPFLAGS =
From wblock at wonkity.com  Sun Sep 20 14:06:17 2009
From: wblock at wonkity.com (Warren Block)
Date: Sun Sep 20 14:06:25 2009
Subject: What happened to DVD writing?
Message-ID: <alpine.BSF.2.00.0909200636310.98493@wonkity.com>

Recording data DVDs worked a few weeks/months ago on this system with a 
PATA Lite-On DVD recorder:

FreeBSD lightning 7.2-STABLE FreeBSD 7.2-STABLE #0: Sun Sep 20 07:25:58 
MDT 2009      root@lightning:/usr/obj/usr/src/sys/LIGHTNING  i386

Now growisofs starts, but appears to never manage to write to the DVD. 
It's a DVD-R, one from the same batch that has worked before:

   0.77% done, estimate finish Sun Sep 20 07:55:57 2009

and there it stops.  Rebooting is needed, and the machine can't quite 
bring itself to shut down after syncing buffers.  /var/log/messages:

Sep 20 07:42:44 lightning kernel: acd0: FAILURE - READ_BUFFER ILLEGAL REQUEST as c=0x24 ascq=0x00
Sep 20 07:42:46 lightning kernel: acd0: FAILURE - MODE_SELECT_BIG ILLEGAL REQUEST asc=0x24 ascq=0x00
Sep 20 07:42:56 lightning kernel: acd0: FAILURE - READ_TOC ILLEGAL REQUEST asc=0x24 ascq=0x00
Sep 20 07:43:25 lightning kernel: acd0: WARNING - TEST_UNIT_READY taskqueue time out - completing request directly
Sep 20 07:43:36 lightning kernel: acd0: WARNING - TEST_UNIT_READY freeing taskqueue zombie request
Sep 20 07:45:26 lightning kernel: acd0: WARNING - PREVENT_ALLOW taskqueue timeout - completing request directly
Sep 20 07:45:26 lightning kernel: acd0: WARNING - PREVENT_ALLOW freeing taskqueue zombie request

-Warren Block * Rapid City, South Dakota USA
From oliver.pntr at gmail.com  Sun Sep 20 15:10:09 2009
From: oliver.pntr at gmail.com (Oliver Pinter)
Date: Sun Sep 20 15:10:16 2009
Subject: octave compile error
Message-ID: <6101e8c40909200810l11d90ca4nc0985e644f8a0fc4@mail.gmail.com>

Hi all!

this is the error:

gmake -C src all
gmake[2]: Entering directory `/usr/ports/math/octave/work/octave-3.2.2/src'
making defaults.h from defaults.h.in
defaults.h is unchanged
making oct-conf.h from oct-conf.h.in
oct-conf.h is unchanged
making DOCSTRINGS
/libexec/ld-elf.so.1: /usr/lib/libstdc++.so.6: version GLIBCXX_3.4.11 required b
y ./gendoc not found
gmake[2]: *** [DOCSTRINGS] Error 1
gmake[2]: Leaving directory `/usr/ports/math/octave/work/octave-3.2.2/src'
gmake[1]: *** [src] Error 2
gmake[1]: Leaving directory `/usr/ports/math/octave/work/octave-3.2.2'
gmake: *** [all] Error 2
*** Error code 1

Stop in /usr/ports/math/octave.

and the system:
FreeBSD fbsd 7.2-STABLE FreeBSD 7.2-STABLE #9: Tue Sep 15 04:10:15
CEST 2009     root@fbsd:/usr/obj/usr/src/sys/stable  amd64
From tkjacobsen at gmail.com  Sun Sep 20 15:22:53 2009
From: tkjacobsen at gmail.com (Troels Kofoed Jacobsen)
Date: Sun Sep 20 15:23:00 2009
Subject: octave compile error
In-Reply-To: <6101e8c40909200810l11d90ca4nc0985e644f8a0fc4@mail.gmail.com>
References: <6101e8c40909200810l11d90ca4nc0985e644f8a0fc4@mail.gmail.com>
Message-ID: <200909201722.47024.tkjacobsen@gmail.com>

On Sunday 20 September 2009 17:10:07 Oliver Pinter wrote:
> Hi all!
> 
> this is the error:
> 
> gmake -C src all
> gmake[2]: Entering directory `/usr/ports/math/octave/work/octave-3.2.2/src'
> making defaults.h from defaults.h.in
> defaults.h is unchanged
> making oct-conf.h from oct-conf.h.in
> oct-conf.h is unchanged
> making DOCSTRINGS
> /libexec/ld-elf.so.1: /usr/lib/libstdc++.so.6: version GLIBCXX_3.4.11
>  required b y ./gendoc not found
> gmake[2]: *** [DOCSTRINGS] Error 1
> gmake[2]: Leaving directory `/usr/ports/math/octave/work/octave-3.2.2/src'
> gmake[1]: *** [src] Error 2
> gmake[1]: Leaving directory `/usr/ports/math/octave/work/octave-3.2.2'
> gmake: *** [all] Error 2
> *** Error code 1
> 
> Stop in /usr/ports/math/octave.
> 
> and the system:
> FreeBSD fbsd 7.2-STABLE FreeBSD 7.2-STABLE #9: Tue Sep 15 04:10:15
> CEST 2009     root@fbsd:/usr/obj/usr/src/sys/stable  amd64
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
> 

A bug has already been filed:
http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/138939
(ports/138939: math/octave doesn't build on 7.2)

Best regards
Troels Kofoed Jacobsen
From zbeeble at gmail.com  Sun Sep 20 18:25:18 2009
From: zbeeble at gmail.com (Zaphod Beeblebrox)
Date: Sun Sep 20 18:25:24 2009
Subject: What happened to DVD writing?
In-Reply-To: <alpine.BSF.2.00.0909200636310.98493@wonkity.com>
References: <alpine.BSF.2.00.0909200636310.98493@wonkity.com>
Message-ID: <5f67a8c40909201103g2dba2d26m414b6bec4142b724@mail.gmail.com>

On Sun, Sep 20, 2009 at 9:47 AM, Warren Block <wblock@wonkity.com> wrote:

> Recording data DVDs worked a few weeks/months ago on this system with a
> PATA Lite-On DVD recorder:
>
> FreeBSD lightning 7.2-STABLE FreeBSD 7.2-STABLE #0: Sun Sep 20 07:25:58 MDT
> 2009      root@lightning:/usr/obj/usr/src/sys/LIGHTNING  i386
>
> Now growisofs starts, but appears to never manage to write to the DVD. It's
> a DVD-R, one from the same batch that has worked before:
>
>  0.77% done, estimate finish Sun Sep 20 07:55:57 2009
>
> and there it stops.  Rebooting is needed, and the machine can't quite bring
> itself to shut down after syncing buffers.  /var/log/messages:
>
> Sep 20 07:42:44 lightning kernel: acd0: FAILURE - READ_BUFFER ILLEGAL
> REQUEST as c=0x24 ascq=0x00
> Sep 20 07:42:46 lightning kernel: acd0: FAILURE - MODE_SELECT_BIG ILLEGAL
> REQUEST asc=0x24 ascq=0x00
> Sep 20 07:42:56 lightning kernel: acd0: FAILURE - READ_TOC ILLEGAL REQUEST
> asc=0x24 ascq=0x00
> Sep 20 07:43:25 lightning kernel: acd0: WARNING - TEST_UNIT_READY taskqueue
> time out - completing request directly
> Sep 20 07:43:36 lightning kernel: acd0: WARNING - TEST_UNIT_READY freeing
> taskqueue zombie request
> Sep 20 07:45:26 lightning kernel: acd0: WARNING - PREVENT_ALLOW taskqueue
> timeout - completing request directly
> Sep 20 07:45:26 lightning kernel: acd0: WARNING - PREVENT_ALLOW freeing
> taskqueue zombie request
>
>
I recently upgraded from 7.0 to 7.2-p3.  I just last night cut a dual layer
DVD with growisofs.  It appears to have cut fine.

When growisofs stops in the middle like that, it's often caused by media
defects.  Have you tried another disk?

Another possibility is that the drive is worn out.  DVD writers have a
limited lifespan largely measured by the number of disks they cut.
From wblock at wonkity.com  Sun Sep 20 18:58:30 2009
From: wblock at wonkity.com (Warren Block)
Date: Sun Sep 20 18:58:36 2009
Subject: What happened to DVD writing?
In-Reply-To: <5f67a8c40909201103g2dba2d26m414b6bec4142b724@mail.gmail.com>
References: <alpine.BSF.2.00.0909200636310.98493@wonkity.com>
	<5f67a8c40909201103g2dba2d26m414b6bec4142b724@mail.gmail.com>
Message-ID: <alpine.BSF.2.00.0909201250190.99625@wonkity.com>

On Sun, 20 Sep 2009, Zaphod Beeblebrox wrote:
>>
>> FreeBSD lightning 7.2-STABLE FreeBSD 7.2-STABLE #0: Sun Sep 20 07:25:58 MDT
>> 2009      root@lightning:/usr/obj/usr/src/sys/LIGHTNING  i386
>>
>> Now growisofs starts, but appears to never manage to write to the DVD. It's
>> a DVD-R, one from the same batch that has worked before:
>>
>>  0.77% done, estimate finish Sun Sep 20 07:55:57 2009
>>
>> and there it stops.  Rebooting is needed, and the machine can't quite bring
>> itself to shut down after syncing buffers.  /var/log/messages:
>>
>> Sep 20 07:42:44 lightning kernel: acd0: FAILURE - READ_BUFFER ILLEGAL
>> REQUEST as c=0x24 ascq=0x00
>> Sep 20 07:42:46 lightning kernel: acd0: FAILURE - MODE_SELECT_BIG ILLEGAL
>> REQUEST asc=0x24 ascq=0x00
>> Sep 20 07:42:56 lightning kernel: acd0: FAILURE - READ_TOC ILLEGAL REQUEST
>> asc=0x24 ascq=0x00
>> Sep 20 07:43:25 lightning kernel: acd0: WARNING - TEST_UNIT_READY taskqueue
>> time out - completing request directly
>> Sep 20 07:43:36 lightning kernel: acd0: WARNING - TEST_UNIT_READY freeing
>> taskqueue zombie request
>> Sep 20 07:45:26 lightning kernel: acd0: WARNING - PREVENT_ALLOW taskqueue
>> timeout - completing request directly
>> Sep 20 07:45:26 lightning kernel: acd0: WARNING - PREVENT_ALLOW freeing
>> taskqueue zombie request
>>
> I recently upgraded from 7.0 to 7.2-p3.  I just last night cut a dual layer
> DVD with growisofs.  It appears to have cut fine.
>
> When growisofs stops in the middle like that, it's often caused by media
> defects.  Have you tried another disk?

Yes, same effect.  Also with a DVD+R.  Also tried it on 8-STABLE, same 
messages, same results.

> Another possibility is that the drive is worn out.  DVD writers have a
> limited lifespan largely measured by the number of disks they cut.

This drive has probably written under 50 DVDs, all ISOs used for backup. 
It's a Lite-On DH-20A4P bought in August 2008.  It's looking like the 
drive itself has failed.  Which seems odd, since I thought it could 
still burn CDs.

-Warren Block * Rapid City, South Dakota USA
From rb at gid.co.uk  Sun Sep 20 20:42:48 2009
From: rb at gid.co.uk (Bob Bishop)
Date: Sun Sep 20 20:42:55 2009
Subject: What happened to DVD writing?
In-Reply-To: <alpine.BSF.2.00.0909201250190.99625@wonkity.com>
References: <alpine.BSF.2.00.0909200636310.98493@wonkity.com>
	<5f67a8c40909201103g2dba2d26m414b6bec4142b724@mail.gmail.com>
	<alpine.BSF.2.00.0909201250190.99625@wonkity.com>
Message-ID: <16D3375E-4857-4068-868A-814C09478F3C@gid.co.uk>

Hi,

On 20 Sep 2009, at 19:58, Warren Block wrote:

> [...]This drive has probably written under 50 DVDs, all ISOs used  
> for backup. It's a Lite-On DH-20A4P bought in August 2008.  It's  
> looking like the drive itself has failed.  Which seems odd, since I  
> thought it could still burn CDs.

Have you tried a cleaning disk on it?

--
Bob Bishop
rb@gid.co.uk




From mahlerrd at yahoo.com  Sun Sep 20 21:02:40 2009
From: mahlerrd at yahoo.com (Richard Mahlerwein)
Date: Sun Sep 20 21:02:47 2009
Subject: What happened to DVD writing?
In-Reply-To: <alpine.BSF.2.00.0909201250190.99625@wonkity.com>
Message-ID: <673698.21068.qm@web51004.mail.re2.yahoo.com>

>From: Warren Block <wblock@wonkity.com>
>Subject: Re: What happened to DVD writing?
>Date: Sunday, September 20, 2009, 2:58 PM
>>On Sun, 20 Sep 2009, Zaphod Beeblebrox wrote:
>>>
>>> FreeBSD lightning 7.2-STABLE FreeBSD 7.2-STABLE #0: Sun Sep 20 07:25:58 MDT
>>> 2009? ? ? root@lightning:/usr/obj/usr/src/sys/LIGHTNING? i386
>>>
>>> Now growisofs starts, but appears to never manage to write to the DVD. It's
>>> a DVD-R, one from the same batch that has worked before:
>>>
>>>? 0.77% done, estimate finish Sun Sep 20 07:55:57 2009
>>>
>>> and there it stops.? Rebooting is needed, and the machine can't quite bring
>>> itself to shut down after syncing buffers.? /var/log/messages:
>>>
>> Another possibility is that the drive is worn out.? DVD writers have a
>> limited lifespan largely measured by the number of disks they cut.
>
>This drive has probably written under 50 DVDs, all ISOs used for backup. 
>It's a Lite-On DH-20A4P bought in August 2008.? It's looking like the 
>drive itself has failed.? Which seems odd, since I thought it could 
>still burn CDs.

I have had several exhibit behavior even more odd.

The most unusual was this particular CD writer... It read both DVDs and CDs but would write neither (it had worked fine the week before).? I took it out of the drive bay and hooked it to another PC to test and it worked fine there.? I put it back in the original PC and it failed.? I was swapping things around on that PC (assuming bad cable, bad power, etc) and had it sitting loose on the desk and found that it now worked again.? Put it back in the drive cage and it again would not write, though reading was fine.? Anyway, I finally figured out that even slight pressure in on the sides where it mounts would make it fail to burn CDs.? The cage itself exerted a bit of pressure and that was enough to make it fail at any attempt to burn a CD.

-Rich



      
From wblock at wonkity.com  Sun Sep 20 21:20:08 2009
From: wblock at wonkity.com (Warren Block)
Date: Sun Sep 20 21:20:16 2009
Subject: What happened to DVD writing?
In-Reply-To: <673698.21068.qm@web51004.mail.re2.yahoo.com>
References: <673698.21068.qm@web51004.mail.re2.yahoo.com>
Message-ID: <alpine.BSF.2.00.0909201518170.199@wonkity.com>

On Sun, 20 Sep 2009, Richard Mahlerwein wrote:
>>
>> This drive has probably written under 50 DVDs, all ISOs used for backup.
>> It's a Lite-On DH-20A4P bought in August 2008.? It's looking like the
>> drive itself has failed.? Which seems odd, since I thought it could
>> still burn CDs.
>
> I have had several exhibit behavior even more odd.
>
> The most unusual was this particular CD writer... It read both DVDs 
> and CDs but would write neither (it had worked fine the week before).? 
> I took it out of the drive bay and hooked it to another PC to test and 
> it worked fine there.? I put it back in the original PC and it 
> failed.? I was swapping things around on that PC (assuming bad cable, 
> bad power, etc) and had it sitting loose on the desk and found that it 
> now worked again.? Put it back in the drive cage and it again would 
> not write, though reading was fine.? Anyway, I finally figured out 
> that even slight pressure in on the sides where it mounts would make 
> it fail to burn CDs.? The cage itself exerted a bit of pressure and 
> that was enough to make it fail at any attempt to burn a CD.

It does appear to be hardware failure.  A web search suggests that this 
drive has two separate lasers, so DVD writing failing while CD writing 
still works is believable.

Sorry for the noise, and thanks to everyone for the suggestions.

-Warren Block * Rapid City, South Dakota USA
From christof.schulze at gmx.com  Sun Sep 20 21:42:25 2009
From: christof.schulze at gmx.com (Christof Schulze)
Date: Sun Sep 20 21:42:33 2009
Subject: zpool scrub hangs on 7.2-stable
Message-ID: <200909202342.22881.christof.schulze@gmx.com>

Hello,

currently I am running a 7.2 stable with zfs v13.
Things work nicely except that zpool scrub hangs without disk activity.
I do not get any error messages in dmesg or /var/log/messages and therefore I 
do not know where to look further.

Is this a known issue or should I investigate? If the latter is the case I 
would need some help doing so.

% uname -a                                           ~
FreeBSD ccschu935 7.2-STABLE FreeBSD 7.2-STABLE #0: Tue Jul  7 04:56:00 CEST 
2009     root@ccschu935:/usr/obj/usr/src/sys/GENERIC  amd64
% zpool status                                       ~
  pool: tank
 state: ONLINE
 scrub: scrub in progress for 0h3m, 0,00% done, 3370h48m to go
config:

	NAME        STATE     READ WRITE CKSUM
	tank        ONLINE       0     0     0
	  ad0s6     ONLINE       0     0     0
	  ad0s3f    ONLINE       0     0     0
	  ad0s3e    ONLINE       0     0     0
	cache
	  mmcsd0    UNAVAIL      0     0     0  cannot open

errors: No known data errors


kind Regards

Christof
From fbsdlist at src.cx  Sun Sep 20 22:35:35 2009
From: fbsdlist at src.cx (Artem Belevich)
Date: Sun Sep 20 22:35:42 2009
Subject: zpool scrub hangs on 7.2-stable
In-Reply-To: <200909202342.22881.christof.schulze@gmx.com>
References: <200909202342.22881.christof.schulze@gmx.com>
Message-ID: <ed91d4a80909201510o243aec5fjfd6efceba4370f11@mail.gmail.com>

Do you have ZIL disabled? I think I saw the same scrub stall on -7
when I had vfs.zfs.zil_disable=1. After re-enabling ZIL scrub
proceeded normally.

--Artem



On Sun, Sep 20, 2009 at 2:42 PM, Christof Schulze
<christof.schulze@gmx.com> wrote:
> Hello,
>
> currently I am running a 7.2 stable with zfs v13.
> Things work nicely except that zpool scrub hangs without disk activity.
> I do not get any error messages in dmesg or /var/log/messages and therefore I
> do not know where to look further.
>
> Is this a known issue or should I investigate? If the latter is the case I
> would need some help doing so.
>
> % uname -a ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ~
> FreeBSD ccschu935 7.2-STABLE FreeBSD 7.2-STABLE #0: Tue Jul ?7 04:56:00 CEST
> 2009 ? ? root@ccschu935:/usr/obj/usr/src/sys/GENERIC ?amd64
> % zpool status ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ~
> ?pool: tank
> ?state: ONLINE
> ?scrub: scrub in progress for 0h3m, 0,00% done, 3370h48m to go
> config:
>
> ? ? ? ?NAME ? ? ? ?STATE ? ? READ WRITE CKSUM
> ? ? ? ?tank ? ? ? ?ONLINE ? ? ? 0 ? ? 0 ? ? 0
> ? ? ? ? ?ad0s6 ? ? ONLINE ? ? ? 0 ? ? 0 ? ? 0
> ? ? ? ? ?ad0s3f ? ?ONLINE ? ? ? 0 ? ? 0 ? ? 0
> ? ? ? ? ?ad0s3e ? ?ONLINE ? ? ? 0 ? ? 0 ? ? 0
> ? ? ? ?cache
> ? ? ? ? ?mmcsd0 ? ?UNAVAIL ? ? ?0 ? ? 0 ? ? 0 ?cannot open
>
> errors: No known data errors
>
>
> kind Regards
>
> Christof
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
>
From zbeeble at gmail.com  Mon Sep 21 01:12:26 2009
From: zbeeble at gmail.com (Zaphod Beeblebrox)
Date: Mon Sep 21 01:12:33 2009
Subject: What happened to DVD writing?
In-Reply-To: <673698.21068.qm@web51004.mail.re2.yahoo.com>
References: <alpine.BSF.2.00.0909201250190.99625@wonkity.com>
	<673698.21068.qm@web51004.mail.re2.yahoo.com>
Message-ID: <5f67a8c40909201812l4a364cb5y46dffbf3ff6b0d49@mail.gmail.com>

On Sun, Sep 20, 2009 at 4:35 PM, Richard Mahlerwein <mahlerrd@yahoo.com>wrote:

>
> I have had several exhibit behavior even more odd.
>
> The most unusual was this particular CD writer... It read both DVDs and CDs
> but would write neither (it had worked fine the week before).  I took it out
> of the drive bay and hooked it to another PC to test and it worked fine
> there.  I put it back in the original PC and it failed.  I was swapping
> things around on that PC (assuming bad cable, bad power, etc) and had it
> sitting loose on the desk and found that it now worked again.  Put it back
> in the drive cage and it again would not write, though reading was fine.
> Anyway, I finally figured out that even slight pressure in on the sides
> where it mounts would make it fail to burn CDs.  The cage itself exerted a
> bit of pressure and that was enough to make it fail at any attempt to burn a
> CD.
>

This is not necessarily odd.  The CD burner is one of the highest draw bits
in your system... save possibly your CPU and/or graphics card (depending on
what they are).  I have found that various DVD drives have been very
sensitive to power supply voltages and fail to burn properly when they're
marginal.  Your description here seems to point in that direction.  If it
works in computer B, try using B's power supply for A --- or maybe B has
other lighter draws.

Power supplies can also degrade over time --- especially if you have some
cheap capacitors in there.

I find the DVD drive is often the canary for spotting power supply problems.
From john.marshall at riverwillow.com.au  Mon Sep 21 01:29:09 2009
From: john.marshall at riverwillow.com.au (John Marshall)
Date: Mon Sep 21 01:29:22 2009
Subject: SASL problems with spnego on 8.0-BETA4
In-Reply-To: <20090918233157.GK1231@rwpc12.mby.riverwillow.net.au>
References: <4AB27FB6.4010806@eng.auth.gr>
	<20090918034933.GI1231@rwpc12.mby.riverwillow.net.au>
	<Pine.GSO.4.63.0909181722270.23193@muncher.cs.uoguelph.ca>
	<20090918233157.GK1231@rwpc12.mby.riverwillow.net.au>
Message-ID: <20090921012855.GA1001@rwpc12.mby.riverwillow.net.au>

On Sat, 19 Sep 2009, 09:31 +1000, John Marshall wrote:
> On Fri, 18 Sep 2009, 17:38 -0400, Rick Macklem wrote:
> > When cyrus-sasl2 builds, it uses the little shell script
> > /usr/bin/krb5-config with the args. "--libs gssapi" to get the list of
> > libraries to link against. This doesn't return "-lgssapi_spnego" in the
> > list. (The list can be changed by editting line #96 of 
> > /usr/bin/krb5-config.)
> 
> I think this sounds promising!  It makes sense.  Thanks for pointing us
> in this direction.

This morning, on my 8.0-RC1 system, I did the following to confirm that
GSSAPI authentication to the LDAP server via SASL2 using the base
Heimdal was still broken:

 - removed the heimdal-1.2.1 port
 - rebuilt the cyrus-sasl-2.1.23 port (against the base heimdal)
 - started the openldap-sasl-server-2.4.18_1
 - queried the LDAP server from a separate client using ldapsearch:
     --------
     SASL/GSSAPI authentication started
     ldap_sasl_interactive_bind_s: Can't contact LDAP server (-1)
     --------
 - and noted that the ldap server died at that point.

I edited line 96 of /usr/bin/krb5-config to include -lgssapi_krb5 in the
libraries list:

        lib_flags="$lib_flags -lgssapi -lgssapi_krb5 -lheimntlm"

and then did the following:

 - rebuilt the cyrus-sasl-2.1.23 port (against the base heimdal)
 - started the openldap-sasl-server-2.4.18_1
 - queried the LDAP server from a separate client using ldapsearch
     --------
     SASL/GSSAPI authentication started
     SASL username: john@EXAMPLE.COM
     SASL SSF: 56
     SASL data security layer installed.
     # extended LDIF
     #
     # LDAPv3
     --------

SUCCESS!

So, this fix obviates THAT reason for installing the Heimdal port.  If
George meets with similar success adding -lgssapi_spnego for his spnego
problem, I suggest that both libraries be added to the list in line 96
of /usr/bin/krb5-config prior to release of FreeBSD 8.0.

It doesn't look like this fix is as simple as submitting a patch to
krb5-config.  It looks like magic needs to happen somewhere in the base
kerberos build system.

I notice that the Heimdal port doesn't build the separate libraries and
everything seems to be included in libgssapi (which explains why sasl2
"works" when linked against the Heimdal port).

-- 
John Marshall
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090921/9c4836d1/attachment.pgp
From martin at martinkjeldsen.dk  Mon Sep 21 07:46:02 2009
From: martin at martinkjeldsen.dk (Martin Kjeldsen)
Date: Mon Sep 21 07:46:09 2009
Subject: What happened to DVD writing?
In-Reply-To: <5f67a8c40909201812l4a364cb5y46dffbf3ff6b0d49@mail.gmail.com>
References: <alpine.BSF.2.00.0909201250190.99625@wonkity.com>
	<673698.21068.qm@web51004.mail.re2.yahoo.com>
	<5f67a8c40909201812l4a364cb5y46dffbf3ff6b0d49@mail.gmail.com>
Message-ID: <20090921071828.GA1681@baest.catpipe.net>

Zaphod Beeblebrox (21:12 2009-09-20):
> On Sun, Sep 20, 2009 at 4:35 PM, Richard Mahlerwein <mahlerrd@yahoo.com>wrote:
> 
> >
> > I have had several exhibit behavior even more odd.
> >
> > The most unusual was this particular CD writer... It read both DVDs and CDs
> > but would write neither (it had worked fine the week before).  I took it out
> > of the drive bay and hooked it to another PC to test and it worked fine
> > there.  I put it back in the original PC and it failed.  I was swapping
> > things around on that PC (assuming bad cable, bad power, etc) and had it
> > sitting loose on the desk and found that it now worked again.  Put it back
> > in the drive cage and it again would not write, though reading was fine.
> > Anyway, I finally figured out that even slight pressure in on the sides
> > where it mounts would make it fail to burn CDs.  The cage itself exerted a
> > bit of pressure and that was enough to make it fail at any attempt to burn a
> > CD.
> >
> 
> This is not necessarily odd.  The CD burner is one of the highest draw bits
> in your system... save possibly your CPU and/or graphics card (depending on
> what they are).  I have found that various DVD drives have been very
> sensitive to power supply voltages and fail to burn properly when they're
> marginal.  Your description here seems to point in that direction.  If it
> works in computer B, try using B's power supply for A --- or maybe B has
> other lighter draws.
> 
> Power supplies can also degrade over time --- especially if you have some
> cheap capacitors in there.
> 
> I find the DVD drive is often the canary for spotting power supply problems.

Hi,

I have the same problem. I can read DVDs and CDs and write CDs, but I'm unable 
to write DVDs. I can't be sure that it is a software problem, but I think it 
happened when upgrading from 8.0-BETA2 to 8.0-BETA4. Not sure at all though.


Martin
From mamalos at eng.auth.gr  Mon Sep 21 11:51:42 2009
From: mamalos at eng.auth.gr (George Mamalakis)
Date: Mon Sep 21 11:51:50 2009
Subject: SASL problems with spnego on 8.0-BETA4
In-Reply-To: <20090921012855.GA1001@rwpc12.mby.riverwillow.net.au>
References: <4AB27FB6.4010806@eng.auth.gr>	<20090918034933.GI1231@rwpc12.mby.riverwillow.net.au>	<Pine.GSO.4.63.0909181722270.23193@muncher.cs.uoguelph.ca>	<20090918233157.GK1231@rwpc12.mby.riverwillow.net.au>
	<20090921012855.GA1001@rwpc12.mby.riverwillow.net.au>
Message-ID: <4AB768C3.6030003@eng.auth.gr>

John Marshall wrote:
> On Sat, 19 Sep 2009, 09:31 +1000, John Marshall wrote:
>   
>> On Fri, 18 Sep 2009, 17:38 -0400, Rick Macklem wrote:
>>     
>>> When cyrus-sasl2 builds, it uses the little shell script
>>> /usr/bin/krb5-config with the args. "--libs gssapi" to get the list of
>>> libraries to link against. This doesn't return "-lgssapi_spnego" in the
>>> list. (The list can be changed by editting line #96 of 
>>> /usr/bin/krb5-config.)
>>>       
>> I think this sounds promising!  It makes sense.  Thanks for pointing us
>> in this direction.
>>     
>
> This morning, on my 8.0-RC1 system, I did the following to confirm that
> GSSAPI authentication to the LDAP server via SASL2 using the base
> Heimdal was still broken:
>
>  - removed the heimdal-1.2.1 port
>  - rebuilt the cyrus-sasl-2.1.23 port (against the base heimdal)
>  - started the openldap-sasl-server-2.4.18_1
>  - queried the LDAP server from a separate client using ldapsearch:
>      --------
>      SASL/GSSAPI authentication started
>      ldap_sasl_interactive_bind_s: Can't contact LDAP server (-1)
>      --------
>  - and noted that the ldap server died at that point.
>
> I edited line 96 of /usr/bin/krb5-config to include -lgssapi_krb5 in the
> libraries list:
>
>         lib_flags="$lib_flags -lgssapi -lgssapi_krb5 -lheimntlm"
>
> and then did the following:
>
>  - rebuilt the cyrus-sasl-2.1.23 port (against the base heimdal)
>  - started the openldap-sasl-server-2.4.18_1
>  - queried the LDAP server from a separate client using ldapsearch
>      --------
>      SASL/GSSAPI authentication started
>      SASL username: john@EXAMPLE.COM
>      SASL SSF: 56
>      SASL data security layer installed.
>      # extended LDIF
>      #
>      # LDAPv3
>      --------
>
> SUCCESS!
>
> So, this fix obviates THAT reason for installing the Heimdal port.  If
> George meets with similar success adding -lgssapi_spnego for his spnego
> problem, I suggest that both libraries be added to the list in line 96
> of /usr/bin/krb5-config prior to release of FreeBSD 8.0.
>
> It doesn't look like this fix is as simple as submitting a patch to
> krb5-config.  It looks like magic needs to happen somewhere in the base
> kerberos build system.
>
> I notice that the Heimdal port doesn't build the separate libraries and
> everything seems to be included in libgssapi (which explains why sasl2
> "works" when linked against the Heimdal port).
>
>   
Guys,

I changed my /usr/bin/krb5-config's line 96 to include -lgssapi_spnego 
and -lgssapi_krb5, and ever since both client and server work 
correctly!! Of course I get some other error, but at least this must be 
a configuration error :).

So, to sum up:

Still running on fbsd.8-BETA4, changed krb5-config to include the 
missing libraries, recompiled cyrus-sasl-2.1.23 after I changed the 
krb5-config, restarted openldap-sasl-server-2.4.18_1 and after 
performing an ldapsearch, the client does not complain (and exits) about 
missing libraries, NOR does the server crash on sasl authentication.

Great job guys, thank you all very very much for your help! I posted my 
query on the 17th of Sep. and in four days (weekend inclusive!) someone 
came up with an answer that resolves my issue! Great job, once more, and 
thank you all again!

-- 
George Mamalakis

IT Officer
Electrical and Computer Engineer (Aristotle Un. of Thessaloniki),
MSc (Imperial College of London)

Department of Electrical and Computer Engineering
Faculty of Engineering
Aristotle University of Thessaloniki

phone number : +30 (2310) 994379

From kama at pvp.se  Mon Sep 21 12:43:23 2009
From: kama at pvp.se (kama)
Date: Mon Sep 21 12:43:31 2009
Subject: FreeBSD 7.2-STABLE boot freeze when calibrating clock.
Message-ID: <20090921140345.H37424@ns1.as.pvp.se>


Hi.

I have recently upgraded the server from 6.X -> Latest 6.X -> 7.2. But
after the upgrade it boots OK once and after that it freezes.

Verbose boot give me these lines:

---- snip ----
Copyright (c) 1992-2009 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
        The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 7.2-STABLE #2: Fri Sep 18 13:22:40 CEST 2009
    root@gs4:/usr/obj/usr/src/sys/GENERIC
Preloaded elf kernel "/boot/kernel/kernel" at 0xc0e7e000.
Preloaded elf module "/boot/kernel/acpi.ko" at 0xc0e7e1d8.
Calibrating clock(s) ... i8254 clock: 1193116 Hz
CLK_USE_I8254_CALIBRATION not specified - using default frequency
Timecounter "i8254" frequency 1193182 Hz quality 0
Calibrating TSC clock ...
---- snap ----

I can boot the system without ACPI enabled w/o problem. But once it is
enabled it will freeze at this point.

This has happend on both servers I have upgraded. Both of them are
identical.

/Bjorn

Full dmesg w acpi disabled:

%dmesg
Copyright (c) 1992-2009 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
        The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 7.2-STABLE #2: Fri Sep 18 13:22:40 CEST 2009
    root@gs4:/usr/obj/usr/src/sys/GENERIC
Timecounter "i8254" frequency 1193182 Hz quality 0
CPU: AMD Opteron(tm) Processor 285 (2605.93-MHz 686-class CPU)
  Origin = "AuthenticAMD"  Id = 0x20f12  Stepping = 2

Features=0x178bfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT>
  Features2=0x1<SSE3>
  AMD Features=0xe2500800<SYSCALL,NX,MMX+,FFXSR,LM,3DNow!+,3DNow!>
  AMD Features2=0x2<CMP>
  Cores per package: 2
real memory  = 3221192704 (3071 MB)
avail memory = 3146604544 (3000 MB)
MPTable: <HP       PROLIANT    >
FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
 cpu0 (BSP): APIC ID:  0
 cpu1 (AP): APIC ID:  1
 cpu2 (AP): APIC ID:  2
 cpu3 (AP): APIC ID:  3
ioapic0: Assuming intbase of 0
ioapic1: Assuming intbase of 24
ioapic2: Assuming intbase of 28
ioapic3: Assuming intbase of 32
ioapic4: Assuming intbase of 36
ioapic0 <Version 1.1> irqs 0-23 on motherboard
ioapic1 <Version 1.1> irqs 24-27 on motherboard
ioapic2 <Version 1.1> irqs 28-31 on motherboard
ioapic3 <Version 1.1> irqs 32-35 on motherboard
ioapic4 <Version 1.1> irqs 36-39 on motherboard
kbd1 at kbdmux0
pcib0: <Host to PCI bridge> pcibus 0 on motherboard
pci0: <PCI bus> on pcib0
pcib1: <MPTable PCI-PCI bridge> at device 3.0 on pci0
pci1: <PCI bus> on pcib1
ohci0: <OHCI (generic) USB controller> mem 0xf7df0000-0xf7df0fff irq 19 at
device 0.0 on pci1
ohci0: [GIANT-LOCKED]
ohci0: [ITHREAD]
usb0: OHCI version 1.0, legacy support
usb0: SMM does not respond, resetting
usb0: <OHCI (generic) USB controller> on ohci0
usb0: USB revision 1.0
uhub0: <AMD OHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb0
uhub0: 3 ports with 3 removable, self powered
ohci1: <OHCI (generic) USB controller> mem 0xf7de0000-0xf7de0fff irq 19 at
device 0.1 on pci1
ohci1: [GIANT-LOCKED]
ohci1: [ITHREAD]
usb1: OHCI version 1.0, legacy support
usb1: SMM does not respond, resetting
usb1: <OHCI (generic) USB controller> on ohci1
usb1: USB revision 1.0
uhub1: <AMD OHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb1
uhub1: 3 ports with 3 removable, self powered
pci1: <base peripheral> at device 2.0 (no driver attached)
pci1: <base peripheral> at device 2.2 (no driver attached)
vgapci0: <VGA-compatible display> port 0x4400-0x44ff mem
0xf6000000-0xf6ffffff,0xf5ff0000-0xf5ff0fff at device 3.0 on pci1
isab0: <PCI-ISA bridge> at device 4.0 on pci0
isa0: <ISA bus> on isab0
atapci0: <AMD 8111 UDMA133 controller> port
0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x2000-0x200f at device 4.1 on pci0
ata0: <ATA channel 0> on atapci0
ata0: [ITHREAD]
ata1: <ATA channel 1> on atapci0
ata1: [ITHREAD]
pci0: <bridge> at device 4.3 (no driver attached)
pcib2: <MPTable PCI-PCI bridge> at device 7.0 on pci0
pci2: <PCI bus> on pcib2
ciss0: <HP Smart Array 6i> port 0x5000-0x50ff mem
0xf7ef0000-0xf7ef1fff,0xf7e80000-0xf7ebffff irq 24 at device 4.0 on pci2
ciss0: [ITHREAD]
pcib3: <MPTable PCI-PCI bridge> at device 8.0 on pci0
pci3: <PCI bus> on pcib3
bge0: <HP NC7782 Gigabit Server Adapter, ASIC rev. 0x2100> mem
0xf7ff0000-0xf7ffffff irq 28 at device 6.0 on pci3
miibus0: <MII bus> on bge0
brgphy0: <BCM5704 10/100/1000baseTX PHY> PHY 1 on miibus0
brgphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT,
1000baseT-FDX, auto
bge0: Ethernet address: 00:17:a4:8d:f9:2a
bge0: [ITHREAD]
bge1: <HP NC7782 Gigabit Server Adapter, ASIC rev. 0x2100> mem
0xf7fe0000-0xf7feffff irq 29 at device 6.1 on pci3
miibus1: <MII bus> on bge1
brgphy1: <BCM5704 10/100/1000baseTX PHY> PHY 1 on miibus1
brgphy1:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT,
1000baseT-FDX, auto
bge1: Ethernet address: 00:17:a4:8d:f9:29
bge1: [ITHREAD]
cpu0 on motherboard
powernow0: <Cool`n'Quiet K8> on cpu0
device_attach: powernow0 attach returned 6
cpu1 on motherboard
powernow1: <Cool`n'Quiet K8> on cpu1
device_attach: powernow1 attach returned 6
cpu2 on motherboard
powernow2: <Cool`n'Quiet K8> on cpu2
device_attach: powernow2 attach returned 6
cpu3 on motherboard
powernow3: <Cool`n'Quiet K8> on cpu3
device_attach: powernow3 attach returned 6
eisa0: <EISA bus> on motherboard
mainboard0: <CPQ0755 (System Board)> at slot 0 on eisa0
pnpbios: error 1/82 getting device count/size limit
pmtimer0 on isa0
orm0: <ISA Option ROMs> at iomem
0xc0000-0xc7fff,0xc8000-0xcbfff,0xee000-0xeffff pnpid ORM0000 on isa0
atkbdc0: <Keyboard controller (i8042)> at port 0x60,0x64 on isa0
atkbd0: <AT Keyboard> irq 1 on atkbdc0
kbd0 at atkbd0
atkbd0: [GIANT-LOCKED]
atkbd0: [ITHREAD]
psm0: <PS/2 Mouse> irq 12 on atkbdc0
psm0: [GIANT-LOCKED]
psm0: [ITHREAD]
psm0: model Generic PS/2 mouse, device ID 0
fdc0: <Enhanced floppy controller> at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2
on isa0
fdc0: [FILTER]
fd0: <1440-KB 3.5" drive> on fdc0 drive 0
ppc0: parallel port not found.
sc0: <System console> at flags 0x100 on isa0
sc0: VGA <16 virtual consoles, flags=0x300>
sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0
sio0: type 16550A
sio0: [FILTER]
sio1 at port 0x2f8-0x2ff irq 3 on isa0
sio1: type 16550A
sio1: [FILTER]
vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0
Timecounters tick every 1.000 msec
acd0: CDROM <TSSTcorpCD-ROM TS-L162C/N204> at ata0-master UDMA33
da0 at ciss0 bus 0 target 0 lun 0
da0: <COMPAQ RAID 1  VOLUME OK> Fixed Direct Access SCSI-0 device
da0: 135.168MB/s transfers
SdMaP0::  ACPo mCmPaUn d# 1Q uLeauuenicnhge dE!n
abled
da0: 69452MB (142239510 512 bSyMtPe:  sAePc tCoPrUs :# 22 5L5aunHc
h6e3dS/!T
 8854C)
SMP: AP CPU #3 Launched!
Trying to mount root from ufs:/dev/da0s1a
bge0: link state changed to UP

From kensmith at buffalo.edu  Mon Sep 21 13:36:07 2009
From: kensmith at buffalo.edu (Ken Smith)
Date: Mon Sep 21 13:36:22 2009
Subject: 8.0-RC1 Available
Message-ID: <1253540159.15847.31.camel@bauer.cse.buffalo.edu>


The first of the Release Candidates for the FreeBSD 8.0 release cycle is
now available.  How many RC's we have will depend on how well 8.0-RC1
does.  At the moment only one more RC is on the schedule but odds are
fairly high we will wind up inserting at least one more RC.  Between
BETA4 and RC1 a lot of work has gone into IPv6 issues as well as many
other issues that have been brought up from the public testing.  And a
patch set was committed by the people who handle porting ZFS to FreeBSD
that they felt makes ZFS production-ready.

Details about the current target schedule along with much more detail
about the current status of the release is available here:

        http://wiki.freebsd.org/8.0TODO

There are two known problems with 8.0-RC1.  One known issue with the
8.0-RC1 build was discovered after the builds got started so is not part
of the ISO images or FreeBSD-Update builds.  The issue is that local
IPv6 link-local addresses are not reachable.  A fix for it has been
committed to RELENG_8 so if you install from the 8.0-RC1 media or update
using FreeBSD-Update you will then need to update using csup/cvsup
mechanisms if you need that fix for your environment.  It should only
impact people using IPv6.

The other known issue is that the flowtable may direct packets to the
wrong interface under certain routing conditions. We feel confident that
this bug will be fixed so the flowtable is enabled in RC1 to maximize
testing. If you experience routing problems, please temporarily disable
the flowtable using the sysctl <XXXX>=0 and report the results to the
freebsd-current@ mailing list. If we are unable to resolve this issue by
RC2, we will disable the flowtable in 8.0-RELEASE.

If you notice problems you can report them through the normal Gnats PR
system or on the freebsd-current mailing list.  I do cross-post
announcements to freebsd-stable because this particular release is
"about to become a stable branch" but when it comes to watching for
issues related to the release most of the developers pay more attention
to the freebsd-current list.

ISO images for all supported architectures are available on the FTP
sites, and a "memory stick" image is available for amd64/i386
architectures.  For amd64/i386 architectures the cdrom and memstick
images include the documentation packages this time but no other
packages.  The DVD image includes a rough pass at what packages will be
available on the official release media but is subject to change between
now and release.  For sparc64 the DVD image has the set of packages that
currently build for sparc64, which is a sub-set of the set provided for
amd64/i386.  The sparc64 disc1 does not have any packages on it because
I noticed a little too late that adding the doc packages to disc1 caused
it to overflow the target size.  For 8.0-RC2 sparc64 will have the
livefs bits split out to a separate image (which is the way all the
other architectures have been for a while now) and the doc packages will
be provided on disc1.  None of the other images include packages.

If you are using csup/cvsup methods to update an older system the branch
tag to use is RELENG_8.

The freebsd-update(8) utility supports binary upgrades of i386 and amd64
systems running earlier FreeBSD releases. Systems running 7.0-RELEASE,
7.1-RELEASE, 7.2-RELEASE, 8.0-BETA1, 8.0-BETA2, 8.0-BETA3, or 8.0-BETA4
can upgrade as follows:
  
# freebsd-update upgrade -r 8.0-RC1
  
During this process, FreeBSD Update may ask the user to help by merging
some configuration files or by confirming that the automatically
performed merging was done correctly.  Systems running 8.0-BETA3 may
print the warning

        INDEX-OLD.all: Invalid arguments

when downloading updates; this warning is a harmless bug (fixed in
8.0-BETA4) and can be safely ignored.

# freebsd-update install
  
The system must be rebooted with the newly installed kernel before continuing.
  
# shutdown -r now
   
After rebooting, freebsd-update needs to be run again to install the new
userland components:

# freebsd-update install
   
At this point, users of systems being upgraded from FreeBSD 8.0-BETA2 or
earlier will be prompted by freebsd-update to rebuild all third-party
applications (e.g., ports installed from the ports tree) due to updates
in system libraries.  See:

http://www.daemonology.net/blog/2009-07-11-freebsd-update-to-8.0-beta1.html

for mode details.  After updating installed third-party applications
(and again, only if freebsd-update printed a message indicating that
this was necessary), run freebsd-update again so that it can delete the
old (no longer used) system libraries:

# freebsd-update install
   
Finally, reboot into 8.0-RC1:
   
# shutdown -r now

MD5/SHA256 checksums for the image files:

MD5 (8.0-RC1-amd64-bootonly.iso) = a84d43c8adaba3fee9a618098668154e
MD5 (8.0-RC1-amd64-disc1.iso) = fb4f75c74144239b4994dc3ad040af33
MD5 (8.0-RC1-amd64-dvd1.iso) = 5da3097634fbe049dd01ad4127d0f396
MD5 (8.0-RC1-amd64-livefs.iso) = 43a483ea73cbbe80f0ef068502594363
MD5 (8.0-RC1-amd64-memstick.img) = 9b1ffcab33ceed4dcdf1a0f3d862f811

MD5 (8.0-RC1-i386-bootonly.iso) = b569d950d6806c7c88a15d857bef6a02
MD5 (8.0-RC1-i386-disc1.iso) = 1cfecd1489b8be4a6d06040b07af941b
MD5 (8.0-RC1-i386-dvd1.iso) = 474b54e73a04a2f573b8a26ad00e3077
MD5 (8.0-RC1-i386-livefs.iso) = 7e5c3390c9f1e7915b9f229eb95f7e70
MD5 (8.0-RC1-i386-memstick.img) = 532736e255f069f7f891d6ed4f14970e

MD5 (8.0-RC1-ia64-bootonly.iso) = f53c920e46d3ceeb755617b2de20507a
MD5 (8.0-RC1-ia64-disc1.iso) = 504d3828b919563a83d7232d9a3a952b
MD5 (8.0-RC1-ia64-disc2.iso) = 5f22a63a89bff893038b32c0c53bf2eb
MD5 (8.0-RC1-ia64-disc3.iso) = bf17e84e9dfa62a6ce131e07bc701478
MD5 (8.0-RC1-ia64-dvd1.iso) = b8cf5cc2feab96c98da12b6fb1623136
MD5 (8.0-RC1-ia64-livefs.iso) = 2a83a1b32cfeb9a95f8ccc5e4cf36918

MD5 (8.0-RC1-pc98-bootonly.iso) = 60603f538db73c264ad7271da044e185
MD5 (8.0-RC1-pc98-disc1.iso) = 7c00a58b4b8f3e94b25a4539116542bd
MD5 (8.0-RC1-pc98-livefs.iso) = aa67b1f3d8246381764a4df867e23f67

MD5 (8.0-RC1-powerpc-bootonly.iso) = a498cafdb4118f2d33007c5f0cf6ca0d
MD5 (8.0-RC1-powerpc-disc1.iso) = 4448a906a36356c479623c8b4af7e685
MD5 (8.0-RC1-powerpc-disc2.iso) = bf9bf9e46da074a0787ca84da13251c8
MD5 (8.0-RC1-powerpc-disc3.iso) = 2f600348579d4adc87b2a32f565f3f03
MD5 (8.0-RC1-powerpc-livefs.iso) = 962f7d69cad7bb47e1cdfaf746b97f90

MD5 (8.0-RC1-sparc64-bootonly.iso) = 674724d0c2ddd997d86f91863c01ba20
MD5 (8.0-RC1-sparc64-disc1.iso) = 9e896ac68263ff816e3721b8b31e63bb
MD5 (8.0-RC1-sparc64-dvd1.iso) = 8451f6fee8523cd33e3e7e973922d2cf

SHA256 (8.0-RC1-amd64-bootonly.iso) = 0fcff1f76629c694be73133ad6ca5057a97a7030d824adb3a3a58bfe881528ab
SHA256 (8.0-RC1-amd64-disc1.iso) = 1b0246694012170ef83ce38395f4179c990d5689e1da2224a7cd2164770d1efb
SHA256 (8.0-RC1-amd64-dvd1.iso) = 63dec5385f549a22e6940a8d30d23be96dec0c27253550787107918631021bcc
SHA256 (8.0-RC1-amd64-livefs.iso) = adda93a732168586272697d32824626898bee6c95ec2efc9e691e649489b99c2
SHA256 (8.0-RC1-amd64-memstick.img) = d2d3f90d3fb3b11cb06734df3ff1eb8433e4184158c85d34c4bd41ba068e131c

SHA256 (8.0-RC1-i386-bootonly.iso) = 6b3f78fe556cb396cb1734fdcdfdd3619013b4318f94b1736349e641a0745dbb
SHA256 (8.0-RC1-i386-disc1.iso) = 06094f54d0b9141b571a8d22727a9c639a4ffb8a72dd05d12e995ef417eaaf37
SHA256 (8.0-RC1-i386-dvd1.iso) = 02009c487ce5a00f52e45d2ccefc5c7b47edea110d1922ff21fe05ee7b1c8cb3
SHA256 (8.0-RC1-i386-livefs.iso) = abcc0c3d975df784eaa4840af15555fc25f610f8699619142185c77b396e00aa
SHA256 (8.0-RC1-i386-memstick.img) = f6ed2716312b6fcdf4bea15e4290a122d34e569fda895fb8bdffa499eea6d9ce

SHA256 (8.0-RC1-ia64-bootonly.iso) = c307cdfa5f98d84b367ac8ef939da6f42a2a0454c07ab0f7b7fe17b78c3f4c9e
SHA256 (8.0-RC1-ia64-disc1.iso) = 44612f9922e8ee2ca6453f9a54b81c01bf351486580fa7cc9cd031b2f0b132c6
SHA256 (8.0-RC1-ia64-disc2.iso) = 01eb3badf81e2e64ab4ddcfd4921f5bc6710c6eb5eba514c92985266fcb805e5
SHA256 (8.0-RC1-ia64-disc3.iso) = 31fd356921f9430233bc7bf0699676746c735ddde9dc4d6ad21438ba66124912
SHA256 (8.0-RC1-ia64-dvd1.iso) = a5bbdf0b0a338ffdc744f1d47513ebede568e852c3e07062b7c0e2f2aafd108b
SHA256 (8.0-RC1-ia64-livefs.iso) = a3a5633900decc819982c50d672cdd653503fe4edebcb566eb4b27784f073635

SHA256 (8.0-RC1-pc98-bootonly.iso) = 5d50fd76e3a1124189acaf54e5258b92383ab0ce8b44b3e5b506020e011b9938
SHA256 (8.0-RC1-pc98-disc1.iso) = 4007e728e8a51fa04663ce9a234db2c1e1f587ebacc45bdeee0ba86261a89345
SHA256 (8.0-RC1-pc98-livefs.iso) = 18f2d066e7fb31b7ea5d95fc70f1bb99e2a9c6c72a45335858e461b9d4cad205

SHA256 (8.0-RC1-powerpc-bootonly.iso) = b3a63ef86773ea28c548082d46d7199d4838648dfa1ecec82c881d90bb0ce9ca
SHA256 (8.0-RC1-powerpc-disc1.iso) = 7cd4e68f0e6bdf95090121ffd89383134c44447a6d1a18a800d58fb1dcd8d1c6
SHA256 (8.0-RC1-powerpc-disc2.iso) = 65719abb58fc8d7904fcbd7052d807efbe44f137badbcfbe7cef623d738360c1
SHA256 (8.0-RC1-powerpc-disc3.iso) = 9ec803dd266e752dcafe2fd3c6d5bb37b3bb6ce00c1cb4683c84616f866ec44b
SHA256 (8.0-RC1-powerpc-livefs.iso) = 7ef3142568fc6c4837faa6cbbd371cf709ee8e1d65df24ea538fba94095eebb5

SHA256 (8.0-RC1-sparc64-bootonly.iso) = 91fb4fee46c0a68520ce97351774725ae95ad4479f06e5d0f3de3e07eeb422d9
SHA256 (8.0-RC1-sparc64-disc1.iso) = 99c74dc6fa9b3185e12fa5084589d1f48f540082c5166026deccf673be46c343
SHA256 (8.0-RC1-sparc64-dvd1.iso) = 777d8afc3330fae4089510d6b852ea1d1f9108a868b8ebb3d5a661b108a99196

-- 
                                                Ken Smith
- From there to here, from here to      |       kensmith@buffalo.edu
  there, funny things are everywhere.   |
                      - Theodore Geisel |

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090921/e73b81c5/attachment.pgp
From mahlerrd at yahoo.com  Mon Sep 21 13:41:49 2009
From: mahlerrd at yahoo.com (Richard Mahlerwein)
Date: Mon Sep 21 13:42:04 2009
Subject: What happened to DVD writing?
In-Reply-To: <5f67a8c40909201812l4a364cb5y46dffbf3ff6b0d49@mail.gmail.com>
Message-ID: <747770.524.qm@web51007.mail.re2.yahoo.com>

>From: Zaphod Beeblebrox <zbeeble@gmail.com>
>Subject: Re: What happened to DVD writing?
>To: mahlerrd@yahoo.com
>Cc: stable@freebsd.org
>Date: Sunday, September 20, 2009, 9:12 PM
>
>On Sun, Sep 20, 2009 at 4:35 PM, Richard Mahlerwein <mahlerrd@yahoo.com>wrote:
>
>>
>> I have had several exhibit behavior even more odd.
>>
>> The most unusual was this particular CD writer... It read both DVDs and CDs
>> but would write neither (it had worked fine the week before).? I took it out
>> of the drive bay and hooked it to another PC to test and it worked fine
>> there.? I put it back in the original PC and it failed.? I was swapping
>> things around on that PC (assuming bad cable, bad power, etc) and had it
>> sitting loose on the desk and found that it now worked again.? Put it back
>> in the drive cage and it again would not write, though reading was fine.
>> Anyway, I finally figured out that even slight pressure in on the sides
>> where it mounts would make it fail to burn CDs.? The cage itself exerted a
>> bit of pressure and that was enough to make it fail at any attempt to burn a
>> CD.
>>
>
>This is not necessarily odd.? The CD burner is one of the highest draw bits
>in your system... save possibly your CPU and/or graphics card (depending on
>what they are).? I have found that various DVD drives have been very
>sensitive to power supply voltages and fail to burn properly when they're
>marginal.? Your description here seems to point in that direction.? If it
>works in computer B, try using B's power supply for A --- or maybe B has
>other lighter draws.

>Power supplies can also degrade over time --- especially if you have some
>cheap capacitors in there.

>I find the DVD drive is often the canary for spotting power supply problems.

Sorry, the kids woke up from naps and I sent without realizing I hadn't quite finished.

Yes, you are completely correct.? There was another story where it was a power supply that was inadequate (should have been, but it was aged and seemed to just run out of steam earlier than it used to).? 

Anyway, the point I intended to make and forgot to was that in this case I'd confirm that the DVD drive itself is OK by popping it into another PC, if one is available.? If it fails in a different known-OK PC it is likely to be a hardware problem.? If it works OK there, try a different power cable on your existing PC, or try swapping out the power supply if you can.? You could also try just disconnecting any other power-hungry yet unneeded items temporarily (like additional CD/DVD readers/writers or that old 6x 9GB drive SCSI2 RAID array :), if you have any.






      
From bz at FreeBSD.org  Mon Sep 21 14:01:14 2009
From: bz at FreeBSD.org (Bjoern A. Zeeb)
Date: Mon Sep 21 14:01:21 2009
Subject: 8.0-RC1 Available
In-Reply-To: <1253540159.15847.31.camel@bauer.cse.buffalo.edu>
References: <1253540159.15847.31.camel@bauer.cse.buffalo.edu>
Message-ID: <20090921134158.R68375@maildrop.int.zabbadoz.net>

On Mon, 21 Sep 2009, Ken Smith wrote:

>
> The first of the Release Candidates for the FreeBSD 8.0 release cycle is
> now available.  How many RC's we have will depend on how well 8.0-RC1
> does.  At the moment only one more RC is on the schedule but odds are
> fairly high we will wind up inserting at least one more RC.  Between
> BETA4 and RC1 a lot of work has gone into IPv6 issues as well as many
> other issues that have been brought up from the public testing.  And a
> patch set was committed by the people who handle porting ZFS to FreeBSD
> that they felt makes ZFS production-ready.
>
> Details about the current target schedule along with much more detail
> about the current status of the release is available here:
>
>        http://wiki.freebsd.org/8.0TODO
>
> There are two known problems with 8.0-RC1.  One known issue with the
> 8.0-RC1 build was discovered after the builds got started so is not part
> of the ISO images or FreeBSD-Update builds.  The issue is that local
> IPv6 link-local addresses are not reachable.  A fix for it has been
> committed to RELENG_8 so if you install from the 8.0-RC1 media or update
> using FreeBSD-Update you will then need to update using csup/cvsup
> mechanisms if you need that fix for your environment.  It should only
> impact people using IPv6.
>
> The other known issue is that the flowtable may direct packets to the
> wrong interface under certain routing conditions. We feel confident that
> this bug will be fixed so the flowtable is enabled in RC1 to maximize
> testing. If you experience routing problems, please temporarily disable
> the flowtable using the sysctl <XXXX>=0 and report the results to the

That should be
 	sysctl net.inet.flowtable.enable=0

> freebsd-current@ mailing list. If we are unable to resolve this issue by
> RC2, we will disable the flowtable in 8.0-RELEASE.
>
> If you notice problems you can report them through the normal Gnats PR
> system or on the freebsd-current mailing list.  I do cross-post
> announcements to freebsd-stable because this particular release is
> "about to become a stable branch" but when it comes to watching for
> issues related to the release most of the developers pay more attention
> to the freebsd-current list.
>
> ISO images for all supported architectures are available on the FTP
> sites, and a "memory stick" image is available for amd64/i386
> architectures.  For amd64/i386 architectures the cdrom and memstick
> images include the documentation packages this time but no other
> packages.  The DVD image includes a rough pass at what packages will be
> available on the official release media but is subject to change between
> now and release.  For sparc64 the DVD image has the set of packages that
> currently build for sparc64, which is a sub-set of the set provided for
> amd64/i386.  The sparc64 disc1 does not have any packages on it because
> I noticed a little too late that adding the doc packages to disc1 caused
> it to overflow the target size.  For 8.0-RC2 sparc64 will have the
> livefs bits split out to a separate image (which is the way all the
> other architectures have been for a while now) and the doc packages will
> be provided on disc1.  None of the other images include packages.
>
> If you are using csup/cvsup methods to update an older system the branch
> tag to use is RELENG_8.
>
> The freebsd-update(8) utility supports binary upgrades of i386 and amd64
> systems running earlier FreeBSD releases. Systems running 7.0-RELEASE,
> 7.1-RELEASE, 7.2-RELEASE, 8.0-BETA1, 8.0-BETA2, 8.0-BETA3, or 8.0-BETA4
> can upgrade as follows:
>
> # freebsd-update upgrade -r 8.0-RC1
>
> During this process, FreeBSD Update may ask the user to help by merging
> some configuration files or by confirming that the automatically
> performed merging was done correctly.  Systems running 8.0-BETA3 may
> print the warning
>
>        INDEX-OLD.all: Invalid arguments
>
> when downloading updates; this warning is a harmless bug (fixed in
> 8.0-BETA4) and can be safely ignored.
>
> # freebsd-update install
>
> The system must be rebooted with the newly installed kernel before continuing.
>
> # shutdown -r now
>
> After rebooting, freebsd-update needs to be run again to install the new
> userland components:
>
> # freebsd-update install
>
> At this point, users of systems being upgraded from FreeBSD 8.0-BETA2 or
> earlier will be prompted by freebsd-update to rebuild all third-party
> applications (e.g., ports installed from the ports tree) due to updates
> in system libraries.  See:
>
> http://www.daemonology.net/blog/2009-07-11-freebsd-update-to-8.0-beta1.html
>
> for mode details.  After updating installed third-party applications
> (and again, only if freebsd-update printed a message indicating that
> this was necessary), run freebsd-update again so that it can delete the
> old (no longer used) system libraries:
>
> # freebsd-update install
>
> Finally, reboot into 8.0-RC1:
>
> # shutdown -r now
>
> MD5/SHA256 checksums for the image files:
>
> MD5 (8.0-RC1-amd64-bootonly.iso) = a84d43c8adaba3fee9a618098668154e
> MD5 (8.0-RC1-amd64-disc1.iso) = fb4f75c74144239b4994dc3ad040af33
> MD5 (8.0-RC1-amd64-dvd1.iso) = 5da3097634fbe049dd01ad4127d0f396
> MD5 (8.0-RC1-amd64-livefs.iso) = 43a483ea73cbbe80f0ef068502594363
> MD5 (8.0-RC1-amd64-memstick.img) = 9b1ffcab33ceed4dcdf1a0f3d862f811
>
> MD5 (8.0-RC1-i386-bootonly.iso) = b569d950d6806c7c88a15d857bef6a02
> MD5 (8.0-RC1-i386-disc1.iso) = 1cfecd1489b8be4a6d06040b07af941b
> MD5 (8.0-RC1-i386-dvd1.iso) = 474b54e73a04a2f573b8a26ad00e3077
> MD5 (8.0-RC1-i386-livefs.iso) = 7e5c3390c9f1e7915b9f229eb95f7e70
> MD5 (8.0-RC1-i386-memstick.img) = 532736e255f069f7f891d6ed4f14970e
>
> MD5 (8.0-RC1-ia64-bootonly.iso) = f53c920e46d3ceeb755617b2de20507a
> MD5 (8.0-RC1-ia64-disc1.iso) = 504d3828b919563a83d7232d9a3a952b
> MD5 (8.0-RC1-ia64-disc2.iso) = 5f22a63a89bff893038b32c0c53bf2eb
> MD5 (8.0-RC1-ia64-disc3.iso) = bf17e84e9dfa62a6ce131e07bc701478
> MD5 (8.0-RC1-ia64-dvd1.iso) = b8cf5cc2feab96c98da12b6fb1623136
> MD5 (8.0-RC1-ia64-livefs.iso) = 2a83a1b32cfeb9a95f8ccc5e4cf36918
>
> MD5 (8.0-RC1-pc98-bootonly.iso) = 60603f538db73c264ad7271da044e185
> MD5 (8.0-RC1-pc98-disc1.iso) = 7c00a58b4b8f3e94b25a4539116542bd
> MD5 (8.0-RC1-pc98-livefs.iso) = aa67b1f3d8246381764a4df867e23f67
>
> MD5 (8.0-RC1-powerpc-bootonly.iso) = a498cafdb4118f2d33007c5f0cf6ca0d
> MD5 (8.0-RC1-powerpc-disc1.iso) = 4448a906a36356c479623c8b4af7e685
> MD5 (8.0-RC1-powerpc-disc2.iso) = bf9bf9e46da074a0787ca84da13251c8
> MD5 (8.0-RC1-powerpc-disc3.iso) = 2f600348579d4adc87b2a32f565f3f03
> MD5 (8.0-RC1-powerpc-livefs.iso) = 962f7d69cad7bb47e1cdfaf746b97f90
>
> MD5 (8.0-RC1-sparc64-bootonly.iso) = 674724d0c2ddd997d86f91863c01ba20
> MD5 (8.0-RC1-sparc64-disc1.iso) = 9e896ac68263ff816e3721b8b31e63bb
> MD5 (8.0-RC1-sparc64-dvd1.iso) = 8451f6fee8523cd33e3e7e973922d2cf
>
> SHA256 (8.0-RC1-amd64-bootonly.iso) = 0fcff1f76629c694be73133ad6ca5057a97a7030d824adb3a3a58bfe881528ab
> SHA256 (8.0-RC1-amd64-disc1.iso) = 1b0246694012170ef83ce38395f4179c990d5689e1da2224a7cd2164770d1efb
> SHA256 (8.0-RC1-amd64-dvd1.iso) = 63dec5385f549a22e6940a8d30d23be96dec0c27253550787107918631021bcc
> SHA256 (8.0-RC1-amd64-livefs.iso) = adda93a732168586272697d32824626898bee6c95ec2efc9e691e649489b99c2
> SHA256 (8.0-RC1-amd64-memstick.img) = d2d3f90d3fb3b11cb06734df3ff1eb8433e4184158c85d34c4bd41ba068e131c
>
> SHA256 (8.0-RC1-i386-bootonly.iso) = 6b3f78fe556cb396cb1734fdcdfdd3619013b4318f94b1736349e641a0745dbb
> SHA256 (8.0-RC1-i386-disc1.iso) = 06094f54d0b9141b571a8d22727a9c639a4ffb8a72dd05d12e995ef417eaaf37
> SHA256 (8.0-RC1-i386-dvd1.iso) = 02009c487ce5a00f52e45d2ccefc5c7b47edea110d1922ff21fe05ee7b1c8cb3
> SHA256 (8.0-RC1-i386-livefs.iso) = abcc0c3d975df784eaa4840af15555fc25f610f8699619142185c77b396e00aa
> SHA256 (8.0-RC1-i386-memstick.img) = f6ed2716312b6fcdf4bea15e4290a122d34e569fda895fb8bdffa499eea6d9ce
>
> SHA256 (8.0-RC1-ia64-bootonly.iso) = c307cdfa5f98d84b367ac8ef939da6f42a2a0454c07ab0f7b7fe17b78c3f4c9e
> SHA256 (8.0-RC1-ia64-disc1.iso) = 44612f9922e8ee2ca6453f9a54b81c01bf351486580fa7cc9cd031b2f0b132c6
> SHA256 (8.0-RC1-ia64-disc2.iso) = 01eb3badf81e2e64ab4ddcfd4921f5bc6710c6eb5eba514c92985266fcb805e5
> SHA256 (8.0-RC1-ia64-disc3.iso) = 31fd356921f9430233bc7bf0699676746c735ddde9dc4d6ad21438ba66124912
> SHA256 (8.0-RC1-ia64-dvd1.iso) = a5bbdf0b0a338ffdc744f1d47513ebede568e852c3e07062b7c0e2f2aafd108b
> SHA256 (8.0-RC1-ia64-livefs.iso) = a3a5633900decc819982c50d672cdd653503fe4edebcb566eb4b27784f073635
>
> SHA256 (8.0-RC1-pc98-bootonly.iso) = 5d50fd76e3a1124189acaf54e5258b92383ab0ce8b44b3e5b506020e011b9938
> SHA256 (8.0-RC1-pc98-disc1.iso) = 4007e728e8a51fa04663ce9a234db2c1e1f587ebacc45bdeee0ba86261a89345
> SHA256 (8.0-RC1-pc98-livefs.iso) = 18f2d066e7fb31b7ea5d95fc70f1bb99e2a9c6c72a45335858e461b9d4cad205
>
> SHA256 (8.0-RC1-powerpc-bootonly.iso) = b3a63ef86773ea28c548082d46d7199d4838648dfa1ecec82c881d90bb0ce9ca
> SHA256 (8.0-RC1-powerpc-disc1.iso) = 7cd4e68f0e6bdf95090121ffd89383134c44447a6d1a18a800d58fb1dcd8d1c6
> SHA256 (8.0-RC1-powerpc-disc2.iso) = 65719abb58fc8d7904fcbd7052d807efbe44f137badbcfbe7cef623d738360c1
> SHA256 (8.0-RC1-powerpc-disc3.iso) = 9ec803dd266e752dcafe2fd3c6d5bb37b3bb6ce00c1cb4683c84616f866ec44b
> SHA256 (8.0-RC1-powerpc-livefs.iso) = 7ef3142568fc6c4837faa6cbbd371cf709ee8e1d65df24ea538fba94095eebb5
>
> SHA256 (8.0-RC1-sparc64-bootonly.iso) = 91fb4fee46c0a68520ce97351774725ae95ad4479f06e5d0f3de3e07eeb422d9
> SHA256 (8.0-RC1-sparc64-disc1.iso) = 99c74dc6fa9b3185e12fa5084589d1f48f540082c5166026deccf673be46c343
> SHA256 (8.0-RC1-sparc64-dvd1.iso) = 777d8afc3330fae4089510d6b852ea1d1f9108a868b8ebb3d5a661b108a99196
>
>

-- 
Bjoern A. Zeeb           What was I talking about and who are you again?
From quakelee at geekcn.org  Mon Sep 21 15:08:07 2009
From: quakelee at geekcn.org (Chao Shin)
Date: Mon Sep 21 15:08:16 2009
Subject: 8.0-RC1 Available
In-Reply-To: <1253540159.15847.31.camel@bauer.cse.buffalo.edu>
References: <1253540159.15847.31.camel@bauer.cse.buffalo.edu>
Message-ID: <op.u0l4blpchnq548@qld630>

>
> The first of the Release Candidates for the FreeBSD 8.0 release cycle is
> now available.  How many RC's we have will depend on how well 8.0-RC1
> does.  At the moment only one more RC is on the schedule but odds are
> fairly high we will wind up inserting at least one more RC.  Between
> BETA4 and RC1 a lot of work has gone into IPv6 issues as well as many
> other issues that have been brought up from the public testing.  And a
> patch set was committed by the people who handle porting ZFS to FreeBSD
> that they felt makes ZFS production-ready.
>
> Details about the current target schedule along with much more detail
> about the current status of the release is available here:
>
>         http://wiki.freebsd.org/8.0TODO
>
> There are two known problems with 8.0-RC1.  One known issue with the
> 8.0-RC1 build was discovered after the builds got started so is not part
> of the ISO images or FreeBSD-Update builds.  The issue is that local
> IPv6 link-local addresses are not reachable.  A fix for it has been
> committed to RELENG_8 so if you install from the 8.0-RC1 media or update
> using FreeBSD-Update you will then need to update using csup/cvsup
> mechanisms if you need that fix for your environment.  It should only
> impact people using IPv6.
>
> The other known issue is that the flowtable may direct packets to the
> wrong interface under certain routing conditions. We feel confident that
> this bug will be fixed so the flowtable is enabled in RC1 to maximize
> testing. If you experience routing problems, please temporarily disable
> the flowtable using the sysctl <XXXX>=0 and report the results to the
> freebsd-current@ mailing list. If we are unable to resolve this issue by
> RC2, we will disable the flowtable in 8.0-RELEASE.
>
> If you notice problems you can report them through the normal Gnats PR
> system or on the freebsd-current mailing list.  I do cross-post
> announcements to freebsd-stable because this particular release is
> "about to become a stable branch" but when it comes to watching for
> issues related to the release most of the developers pay more attention
> to the freebsd-current list.
>
> ISO images for all supported architectures are available on the FTP
> sites, and a "memory stick" image is available for amd64/i386
> architectures.  For amd64/i386 architectures the cdrom and memstick
> images include the documentation packages this time but no other
> packages.  The DVD image includes a rough pass at what packages will be
> available on the official release media but is subject to change between
> now and release.  For sparc64 the DVD image has the set of packages that
> currently build for sparc64, which is a sub-set of the set provided for
> amd64/i386.  The sparc64 disc1 does not have any packages on it because
> I noticed a little too late that adding the doc packages to disc1 caused
> it to overflow the target size.  For 8.0-RC2 sparc64 will have the
> livefs bits split out to a separate image (which is the way all the
> other architectures have been for a while now) and the doc packages will
> be provided on disc1.  None of the other images include packages.
>
> If you are using csup/cvsup methods to update an older system the branch
> tag to use is RELENG_8.
>
> The freebsd-update(8) utility supports binary upgrades of i386 and amd64
> systems running earlier FreeBSD releases. Systems running 7.0-RELEASE,
> 7.1-RELEASE, 7.2-RELEASE, 8.0-BETA1, 8.0-BETA2, 8.0-BETA3, or 8.0-BETA4
> can upgrade as follows:
> # freebsd-update upgrade -r 8.0-RC1
> During this process, FreeBSD Update may ask the user to help by merging
> some configuration files or by confirming that the automatically
> performed merging was done correctly.  Systems running 8.0-BETA3 may
> print the warning
>
>         INDEX-OLD.all: Invalid arguments
>
> when downloading updates; this warning is a harmless bug (fixed in
> 8.0-BETA4) and can be safely ignored.
>
> # freebsd-update install
> The system must be rebooted with the newly installed kernel before  
> continuing.
> # shutdown -r now
> After rebooting, freebsd-update needs to be run again to install the new
> userland components:
>
> # freebsd-update install
> At this point, users of systems being upgraded from FreeBSD 8.0-BETA2 or
> earlier will be prompted by freebsd-update to rebuild all third-party
> applications (e.g., ports installed from the ports tree) due to updates
> in system libraries.  See:
>
> http://www.daemonology.net/blog/2009-07-11-freebsd-update-to-8.0-beta1.html
>
> for mode details.  After updating installed third-party applications
> (and again, only if freebsd-update printed a message indicating that
> this was necessary), run freebsd-update again so that it can delete the
> old (no longer used) system libraries:
>
> # freebsd-update install
> Finally, reboot into 8.0-RC1:
> # shutdown -r now
>
> MD5/SHA256 checksums for the image files:
>
> MD5 (8.0-RC1-amd64-bootonly.iso) = a84d43c8adaba3fee9a618098668154e
> MD5 (8.0-RC1-amd64-disc1.iso) = fb4f75c74144239b4994dc3ad040af33
> MD5 (8.0-RC1-amd64-dvd1.iso) = 5da3097634fbe049dd01ad4127d0f396
> MD5 (8.0-RC1-amd64-livefs.iso) = 43a483ea73cbbe80f0ef068502594363
> MD5 (8.0-RC1-amd64-memstick.img) = 9b1ffcab33ceed4dcdf1a0f3d862f811
>
> MD5 (8.0-RC1-i386-bootonly.iso) = b569d950d6806c7c88a15d857bef6a02
> MD5 (8.0-RC1-i386-disc1.iso) = 1cfecd1489b8be4a6d06040b07af941b
> MD5 (8.0-RC1-i386-dvd1.iso) = 474b54e73a04a2f573b8a26ad00e3077
> MD5 (8.0-RC1-i386-livefs.iso) = 7e5c3390c9f1e7915b9f229eb95f7e70
> MD5 (8.0-RC1-i386-memstick.img) = 532736e255f069f7f891d6ed4f14970e
>
> MD5 (8.0-RC1-ia64-bootonly.iso) = f53c920e46d3ceeb755617b2de20507a
> MD5 (8.0-RC1-ia64-disc1.iso) = 504d3828b919563a83d7232d9a3a952b
> MD5 (8.0-RC1-ia64-disc2.iso) = 5f22a63a89bff893038b32c0c53bf2eb
> MD5 (8.0-RC1-ia64-disc3.iso) = bf17e84e9dfa62a6ce131e07bc701478
> MD5 (8.0-RC1-ia64-dvd1.iso) = b8cf5cc2feab96c98da12b6fb1623136
> MD5 (8.0-RC1-ia64-livefs.iso) = 2a83a1b32cfeb9a95f8ccc5e4cf36918
>
> MD5 (8.0-RC1-pc98-bootonly.iso) = 60603f538db73c264ad7271da044e185
> MD5 (8.0-RC1-pc98-disc1.iso) = 7c00a58b4b8f3e94b25a4539116542bd
> MD5 (8.0-RC1-pc98-livefs.iso) = aa67b1f3d8246381764a4df867e23f67
>
> MD5 (8.0-RC1-powerpc-bootonly.iso) = a498cafdb4118f2d33007c5f0cf6ca0d
> MD5 (8.0-RC1-powerpc-disc1.iso) = 4448a906a36356c479623c8b4af7e685
> MD5 (8.0-RC1-powerpc-disc2.iso) = bf9bf9e46da074a0787ca84da13251c8
> MD5 (8.0-RC1-powerpc-disc3.iso) = 2f600348579d4adc87b2a32f565f3f03
> MD5 (8.0-RC1-powerpc-livefs.iso) = 962f7d69cad7bb47e1cdfaf746b97f90
>
> MD5 (8.0-RC1-sparc64-bootonly.iso) = 674724d0c2ddd997d86f91863c01ba20
> MD5 (8.0-RC1-sparc64-disc1.iso) = 9e896ac68263ff816e3721b8b31e63bb
> MD5 (8.0-RC1-sparc64-dvd1.iso) = 8451f6fee8523cd33e3e7e973922d2cf
>
> SHA256 (8.0-RC1-amd64-bootonly.iso) =  
> 0fcff1f76629c694be73133ad6ca5057a97a7030d824adb3a3a58bfe881528ab
> SHA256 (8.0-RC1-amd64-disc1.iso) =  
> 1b0246694012170ef83ce38395f4179c990d5689e1da2224a7cd2164770d1efb
> SHA256 (8.0-RC1-amd64-dvd1.iso) =  
> 63dec5385f549a22e6940a8d30d23be96dec0c27253550787107918631021bcc
> SHA256 (8.0-RC1-amd64-livefs.iso) =  
> adda93a732168586272697d32824626898bee6c95ec2efc9e691e649489b99c2
> SHA256 (8.0-RC1-amd64-memstick.img) =  
> d2d3f90d3fb3b11cb06734df3ff1eb8433e4184158c85d34c4bd41ba068e131c
>
> SHA256 (8.0-RC1-i386-bootonly.iso) =  
> 6b3f78fe556cb396cb1734fdcdfdd3619013b4318f94b1736349e641a0745dbb
> SHA256 (8.0-RC1-i386-disc1.iso) =  
> 06094f54d0b9141b571a8d22727a9c639a4ffb8a72dd05d12e995ef417eaaf37
> SHA256 (8.0-RC1-i386-dvd1.iso) =  
> 02009c487ce5a00f52e45d2ccefc5c7b47edea110d1922ff21fe05ee7b1c8cb3
> SHA256 (8.0-RC1-i386-livefs.iso) =  
> abcc0c3d975df784eaa4840af15555fc25f610f8699619142185c77b396e00aa
> SHA256 (8.0-RC1-i386-memstick.img) =  
> f6ed2716312b6fcdf4bea15e4290a122d34e569fda895fb8bdffa499eea6d9ce
>
> SHA256 (8.0-RC1-ia64-bootonly.iso) =  
> c307cdfa5f98d84b367ac8ef939da6f42a2a0454c07ab0f7b7fe17b78c3f4c9e
> SHA256 (8.0-RC1-ia64-disc1.iso) =  
> 44612f9922e8ee2ca6453f9a54b81c01bf351486580fa7cc9cd031b2f0b132c6
> SHA256 (8.0-RC1-ia64-disc2.iso) =  
> 01eb3badf81e2e64ab4ddcfd4921f5bc6710c6eb5eba514c92985266fcb805e5
> SHA256 (8.0-RC1-ia64-disc3.iso) =  
> 31fd356921f9430233bc7bf0699676746c735ddde9dc4d6ad21438ba66124912
> SHA256 (8.0-RC1-ia64-dvd1.iso) =  
> a5bbdf0b0a338ffdc744f1d47513ebede568e852c3e07062b7c0e2f2aafd108b
> SHA256 (8.0-RC1-ia64-livefs.iso) =  
> a3a5633900decc819982c50d672cdd653503fe4edebcb566eb4b27784f073635
>
> SHA256 (8.0-RC1-pc98-bootonly.iso) =  
> 5d50fd76e3a1124189acaf54e5258b92383ab0ce8b44b3e5b506020e011b9938
> SHA256 (8.0-RC1-pc98-disc1.iso) =  
> 4007e728e8a51fa04663ce9a234db2c1e1f587ebacc45bdeee0ba86261a89345
> SHA256 (8.0-RC1-pc98-livefs.iso) =  
> 18f2d066e7fb31b7ea5d95fc70f1bb99e2a9c6c72a45335858e461b9d4cad205
>
> SHA256 (8.0-RC1-powerpc-bootonly.iso) =  
> b3a63ef86773ea28c548082d46d7199d4838648dfa1ecec82c881d90bb0ce9ca
> SHA256 (8.0-RC1-powerpc-disc1.iso) =  
> 7cd4e68f0e6bdf95090121ffd89383134c44447a6d1a18a800d58fb1dcd8d1c6
> SHA256 (8.0-RC1-powerpc-disc2.iso) =  
> 65719abb58fc8d7904fcbd7052d807efbe44f137badbcfbe7cef623d738360c1
> SHA256 (8.0-RC1-powerpc-disc3.iso) =  
> 9ec803dd266e752dcafe2fd3c6d5bb37b3bb6ce00c1cb4683c84616f866ec44b
> SHA256 (8.0-RC1-powerpc-livefs.iso) =  
> 7ef3142568fc6c4837faa6cbbd371cf709ee8e1d65df24ea538fba94095eebb5
>
> SHA256 (8.0-RC1-sparc64-bootonly.iso) =  
> 91fb4fee46c0a68520ce97351774725ae95ad4479f06e5d0f3de3e07eeb422d9
> SHA256 (8.0-RC1-sparc64-disc1.iso) =  
> 99c74dc6fa9b3185e12fa5084589d1f48f540082c5166026deccf673be46c343
> SHA256 (8.0-RC1-sparc64-dvd1.iso) =  
> 777d8afc3330fae4089510d6b852ea1d1f9108a868b8ebb3d5a661b108a99196
>

Hi Ken,

I don't know whether USB stick can't boot issue is a show stoper, but it
really a big problem for me. I hope it can resolve before 8.0-RELEASE.


-- 
The Power to Serve
From rmacklem at uoguelph.ca  Mon Sep 21 15:21:13 2009
From: rmacklem at uoguelph.ca (Rick Macklem)
Date: Mon Sep 21 15:22:28 2009
Subject: SASL problems with spnego on 8.0-BETA4
In-Reply-To: <4AB768C3.6030003@eng.auth.gr>
References: <4AB27FB6.4010806@eng.auth.gr>
	<20090918034933.GI1231@rwpc12.mby.riverwillow.net.au>
	<Pine.GSO.4.63.0909181722270.23193@muncher.cs.uoguelph.ca>
	<20090918233157.GK1231@rwpc12.mby.riverwillow.net.au>
	<20090921012855.GA1001@rwpc12.mby.riverwillow.net.au>
	<4AB768C3.6030003@eng.auth.gr>
Message-ID: <Pine.GSO.4.63.0909211122440.26309@muncher.cs.uoguelph.ca>



On Mon, 21 Sep 2009, George Mamalakis wrote:

[stuff snipped]
>> 
>> SUCCESS!
>> 
>> So, this fix obviates THAT reason for installing the Heimdal port.  If
>> George meets with similar success adding -lgssapi_spnego for his spnego
>> problem, I suggest that both libraries be added to the list in line 96
>> of /usr/bin/krb5-config prior to release of FreeBSD 8.0.
>> 
>> It doesn't look like this fix is as simple as submitting a patch to
>> krb5-config.  It looks like magic needs to happen somewhere in the base
>> kerberos build system.
>> 
>> I notice that the Heimdal port doesn't build the separate libraries and
>> everything seems to be included in libgssapi (which explains why sasl2
>> "works" when linked against the Heimdal port).
>>
>> 
> Guys,
>
> I changed my /usr/bin/krb5-config's line 96 to include -lgssapi_spnego and 
> -lgssapi_krb5, and ever since both client and server work correctly!! Of 
> course I get some other error, but at least this must be a configuration 
> error :).
>
> So, to sum up:
>
> Still running on fbsd.8-BETA4, changed krb5-config to include the missing 
> libraries, recompiled cyrus-sasl-2.1.23 after I changed the krb5-config, 
> restarted openldap-sasl-server-2.4.18_1 and after performing an ldapsearch, 
> the client does not complain (and exits) about missing libraries, NOR does 
> the server crash on sasl authentication.
>
> Great job guys, thank you all very very much for your help! I posted my query 
> on the 17th of Sep. and in four days (weekend inclusive!) someone came up 
> with an answer that resolves my issue! Great job, once more, and thank you 
> all again!
>
Now, hopefully someone who understands enough about dynamic linking will
know if this is the correct fix for 8.0? (I'm going on a couple of weeks
vacation at the end of this week, so I won't be around to commit anything
and don't understand it well enough to know if this is the correct way
to fix it.)

So, hopefully someone else can pick this one up?

Thanks for testing it, rick
From jasonh at DataIX.net  Mon Sep 21 15:32:21 2009
From: jasonh at DataIX.net (Jason J. Hellenthal)
Date: Mon Sep 21 15:32:33 2009
Subject: zpool scrub hangs on 7.2-stable
In-Reply-To: <200909202342.22881.christof.schulze@gmx.com>
References: <200909202342.22881.christof.schulze@gmx.com>
Message-ID: <alpine.BSF.2.00.0909211129540.13890@qvzrafvba.5c.ybpny>

On Sun, 20 Sep 2009 17:42 -0000, christof.schulze wrote:

> Hello,
>
> currently I am running a 7.2 stable with zfs v13.
> Things work nicely except that zpool scrub hangs without disk activity.
> I do not get any error messages in dmesg or /var/log/messages and therefore I
> do not know where to look further.
>
> Is this a known issue or should I investigate? If the latter is the case I
> would need some help doing so.
>
> % uname -a                                           ~
> FreeBSD ccschu935 7.2-STABLE FreeBSD 7.2-STABLE #0: Tue Jul  7 04:56:00 CEST
> 2009     root@ccschu935:/usr/obj/usr/src/sys/GENERIC  amd64
> % zpool status                                       ~
>  pool: tank
> state: ONLINE
> scrub: scrub in progress for 0h3m, 0,00% done, 3370h48m to go
> config:
>
> 	NAME        STATE     READ WRITE CKSUM
> 	tank        ONLINE       0     0     0
> 	  ad0s6     ONLINE       0     0     0
> 	  ad0s3f    ONLINE       0     0     0
> 	  ad0s3e    ONLINE       0     0     0
> 	cache
> 	  mmcsd0    UNAVAIL      0     0     0  cannot open
>
> errors: No known data errors
>
>
> kind Regards
>
> Christof
>

I see you cache is disabled no available. Even though I don't think this should 
or might be the problem can you remove the device from the pool and re-scrub to 
see if that relieves the problem.

-- 

  Jason J. Hellenthal
  http://www.DataIX.net/
  jasonh@DataIX.net
  0x691411AC

  - (2^(N-1))
From kensmith at buffalo.edu  Mon Sep 21 15:36:19 2009
From: kensmith at buffalo.edu (Ken Smith)
Date: Mon Sep 21 15:39:35 2009
Subject: 8.0-RC1 Available
In-Reply-To: <op.u0l4blpchnq548@qld630>
References: <1253540159.15847.31.camel@bauer.cse.buffalo.edu>
	<op.u0l4blpchnq548@qld630>
Message-ID: <1253546750.15847.50.camel@bauer.cse.buffalo.edu>

On Mon, 2009-09-21 at 23:08 +0800, Chao Shin wrote:
> I don't know whether USB stick can't boot issue is a show stoper, but it
> really a big problem for me. I hope it can resolve before 8.0-RELEASE.

Somebody is working on that, we hope to have it resolved before RC2.
It's one of several things that is making having an RC3 likely, we would
want there to be a reasonable amount of time for people to test the
changes that would be involved in that fix (as well as the flowtable fix
and a few other issues).

-- 
                                                Ken Smith
- From there to here, from here to      |       kensmith@buffalo.edu
  there, funny things are everywhere.   |
                      - Theodore Geisel |

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090921/6393d6f1/attachment.pgp
From jkim at FreeBSD.org  Mon Sep 21 16:39:42 2009
From: jkim at FreeBSD.org (Jung-uk Kim)
Date: Mon Sep 21 16:39:49 2009
Subject: PATA disks/DVD not detected on ATI IXP 700 - cannot boot (dmesg
	attached)
In-Reply-To: <20090919035214.GA12889@zod.isi.edu>
References: <20090916161327.GB87631@zod.isi.edu>
	<20090919035214.GA12889@zod.isi.edu>
Message-ID: <200909211239.25614.jkim@FreeBSD.org>

On Friday 18 September 2009 11:52 pm, Ted Faber wrote:
> On Wed, Sep 16, 2009 at 09:13:27AM -0700, Ted Faber wrote:
> > Hi.
> >
> > I'm trying to upgrade a machine to a new motherboard (the ECS
> > A790GXM-AD3 AM3 790GX) my FreeBSD 7-STABLE system (GENERIC
> > kernel, compiled from source on 10 Sept 2009) reaches the point
> > where it's going to mount the root file system and can't find the
> > disk.  It drops me into the manual specification of root file
> > system menu, but there are no GEOM-managed disks to choose from.
>
> [...]
>
> I managed to boot FreeBSD on this motherboard using a USB key. 
> Attached is the dmesg from a verbose boot.  Any help would be
> appreciated.

This is a known problem and should be fixed in 8.0.  Sorry, I haven't 
had time to back-port the code.  Proabably it's good time to consider 
testing 8.0-RC1. ;-)

Jung-uk Kim
From faber at isi.edu  Mon Sep 21 17:05:17 2009
From: faber at isi.edu (Ted Faber)
Date: Mon Sep 21 17:05:28 2009
Subject: PATA disks/DVD not detected on ATI IXP 700 - cannot boot (dmesg
	attached)
In-Reply-To: <200909211239.25614.jkim@FreeBSD.org>
References: <20090916161327.GB87631@zod.isi.edu>
	<20090919035214.GA12889@zod.isi.edu>
	<200909211239.25614.jkim@FreeBSD.org>
Message-ID: <20090921170516.GA52169@zod.isi.edu>

Skipped content of type multipart/mixed-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090921/f203c759/attachment.pgp
From peter at pean.org  Mon Sep 21 18:11:28 2009
From: peter at pean.org (=?iso-8859-1?Q?Peter_Ankerst=E5l?=)
Date: Mon Sep 21 18:11:36 2009
Subject: SASL problems with spnego on 8.0-BETA4
In-Reply-To: <Pine.GSO.4.63.0909211122440.26309@muncher.cs.uoguelph.ca>
References: <4AB27FB6.4010806@eng.auth.gr>
	<20090918034933.GI1231@rwpc12.mby.riverwillow.net.au>
	<Pine.GSO.4.63.0909181722270.23193@muncher.cs.uoguelph.ca>
	<20090918233157.GK1231@rwpc12.mby.riverwillow.net.au>
	<20090921012855.GA1001@rwpc12.mby.riverwillow.net.au>
	<4AB768C3.6030003@eng.auth.gr>
	<Pine.GSO.4.63.0909211122440.26309@muncher.cs.uoguelph.ca>
Message-ID: <1105595C-2914-49C4-9A71-87801D228982@pean.org>



On Sep 21, 2009, at 5:26 PM, Rick Macklem wrote:

>>
>>
> Now, hopefully someone who understands enough about dynamic linking  
> will
> know if this is the correct fix for 8.0? (I'm going on a couple of  
> weeks
> vacation at the end of this week, so I won't be around to commit  
> anything
> and don't understand it well enough to know if this is the correct way
> to fix it.)
>
> So, hopefully someone else can pick this one up?
>
> Thanks for testing it, rick
> _______________________________________________


Could this be the same problem I have with SASL and postfix?

http://lists.freebsd.org/pipermail/freebsd-questions/2009-September/205525.html

--
Peter Ankerst?l
peter@pean.org
http://www.pean.org/

From rmacklem at uoguelph.ca  Mon Sep 21 18:53:34 2009
From: rmacklem at uoguelph.ca (Rick Macklem)
Date: Mon Sep 21 18:53:46 2009
Subject: SASL problems with spnego on 8.0-BETA4
In-Reply-To: <1105595C-2914-49C4-9A71-87801D228982@pean.org>
References: <4AB27FB6.4010806@eng.auth.gr>
	<20090918034933.GI1231@rwpc12.mby.riverwillow.net.au>
	<Pine.GSO.4.63.0909181722270.23193@muncher.cs.uoguelph.ca>
	<20090918233157.GK1231@rwpc12.mby.riverwillow.net.au>
	<20090921012855.GA1001@rwpc12.mby.riverwillow.net.au>
	<4AB768C3.6030003@eng.auth.gr>
	<Pine.GSO.4.63.0909211122440.26309@muncher.cs.uoguelph.ca>
	<1105595C-2914-49C4-9A71-87801D228982@pean.org>
Message-ID: <Pine.GSO.4.63.0909211451200.11124@muncher.cs.uoguelph.ca>



On Mon, 21 Sep 2009, Peter Ankerst??l wrote:

>
> Could this be the same problem I have with SASL and postfix?
>
> http://lists.freebsd.org/pipermail/freebsd-questions/2009-September/205525.html
>
I have no idea, but there's one way to find out. Apply this patch to
/usr/bin/krb5-config and then rebuild all the cyrus-sasl2 stuff in 
/usr/ports. (If you "rm -r work" before "make build", you'll be sure
to use krb5-config again.)

--- krb5-config.sav	2009-09-18 16:54:42.000000000 -0400
+++ krb5-config	2009-09-21 14:49:34.000000000 -0400
@@ -93,7 +93,7 @@
      lib_flags="-L${libdir}"
      case $library in
      gssapi)
-	lib_flags="$lib_flags -lgssapi -lheimntlm"
+	lib_flags="$lib_flags -lgssapi -lgssapi_spnego -lgssapi_krb5 -lheimntlm"
  	;;
      kadm-client)
  	lib_flags="$lib_flags -lkadm5clnt"

Then see if the newly built binaries work.

Good luck with it, rick
From dillon at apollo.backplane.com  Mon Sep 21 19:12:14 2009
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Mon Sep 21 19:12:21 2009
Subject: incorrect usleep/select delays with HZ > 2500
References: <20090906155154.GA8283@onelab2.iet.unipi.it>
	<e7db6d980909061736p4affc054k3fa5070214adc2f8@mail.gmail.com>
	<20090907072159.GA18906@onelab2.iet.unipi.it>
	<6F002A04-5CF9-466F-AEFB-6B983C0E1980@mac.com>
Message-ID: <200909211859.n8LIxxZv028784@apollo.backplane.com>

    What we wound up doing was splitting tvtohz() into two functions.

    tvtohz_high(tv)

	Returned value meets or exceeds requested time.  A minimum value
	of 1 is returned (really only for {0,0}.. else minimum value is 2).

    tvtohz_low(tv)

	Returned value might be shorter then requested time, and 0 can
	be returned.

    Most kernel functions use the tvtohz_high() function.  Only a few
    use tvtohz_low().

    I have not found any 'good' solution to the problem.  For example,
    average-up errors can mount up when using the results to control a
    callout timer resulting in much longer delays then originally intended,
    and similarly same-tick interrupts (e.g. a value of 1) can create
    much shorter delays then expected.  Sometimes one cares more about
    the average interval being correct, other times the time must not
    be allowed to be too short.  You lose no matter what you choose.

	http://fxr.watson.org/fxr/source/kern/kern_clock.c?v=DFBSD

    If you look at tvtohz_high() you will note that the minimum value
    of 1 is only returned if the passed tv is essentially {0,0}.  i.e. 0uS.
    1uS == 2 ticks (((us + (tick - 1)) / tick) + 1).  The 'tick' global
    here is the number of uS per tick (not to be confused with 'ticks').

    Because of all of that I decided to split the function to make the
    requirements more apparent.

    --

    The nanosleep() work is a different issue... that's for userland calls
    (primarily the libc usleep() function).  We found that some linux
    programs assumed that nanosleep() was far more fine-grained then (hz)
    and, anyway, the system call is called 'nanosleep' and 'usleep' which
    kind of implies a fine-grained sleep, so we turned it into one when
    small time intervals were being requested.

	http://fxr.watson.org/fxr/source/kern/kern_time.c?v=DFBSD

    The way I figure it if a userland program wants to make system calls
    with fine-grained sleeps that are too small, it's really no different
    from treating that program as being cpu-bound anyway so why not try to
    accomodate it?

    --

    The 8254 issue is more one of a lack of interest in fixing it.
    Basically using the 8254 as a measure of realtime when the reload
    value is set to small (i.e. high hz) will always lead to serious
    timing problems.  The reason there is such a lack of interest
    in fixing it is that most machines have other timers available
    (lapic, acpi, hpet, tsc, etc).  A secondary issue might be tying
    real-time functions to 'ticks', which could still be driven by the
    8254 interrupt.... those have to be divorced from ticks.  I'm not
    sure if FreeBSD has any of those left (does date still skip quickly if
    hz is set ultra-high?  Even when other timers are available?).

    I will note that tying real-time functions to the hz-based tick
    function (which is also the 8254-driven problem when other timers
    are not available) leads to serious problems, particularly with ntpd,
    even if you only lose track of the full cycle of the timer
    occassionally.

    However, neither do you want to 'skip' the ticks value to catch up
    to a lost interrupt.  That will mess up tsleep() and other hz-based
    timeouts that assume that values of '2' will not instantly
    timeout.

    So actual realtime operations really do have to be completely divorced
    from the hz-based ticks counter and it must only be used for looser
    timing needs such as protocol timeouts and sleeps.

						-Matt

From christof.schulze at gmx.com  Mon Sep 21 20:01:25 2009
From: christof.schulze at gmx.com (Christof Schulze)
Date: Mon Sep 21 20:01:32 2009
Subject: zpool scrub hangs on 7.2-stable
In-Reply-To: <ed91d4a80909201510o243aec5fjfd6efceba4370f11@mail.gmail.com>
References: <200909202342.22881.christof.schulze@gmx.com>
	<ed91d4a80909201510o243aec5fjfd6efceba4370f11@mail.gmail.com>
Message-ID: <200909212201.21133.christof.schulze@gmx.com>

Am Montag 21 September 2009 00:10:39 schrieb Artem Belevich:
> Do you have ZIL disabled? I think I saw the same scrub stall on -7
> when I had vfs.zfs.zil_disable=1. After re-enabling ZIL scrub
> proceeded normally.
zil is not disabled
% sysctl vfs.zfs.zil_disable                                                      
vfs.zfs.zil_disable: 0

but thank you for the hint

Regards

Christof
From christof.schulze at gmx.com  Mon Sep 21 20:24:44 2009
From: christof.schulze at gmx.com (Christof Schulze)
Date: Mon Sep 21 20:24:50 2009
Subject: WORKAROUND Re: zpool scrub hangs on 7.2-stable
In-Reply-To: <alpine.BSF.2.00.0909211129540.13890@qvzrafvba.5c.ybpny>
References: <200909202342.22881.christof.schulze@gmx.com>
	<alpine.BSF.2.00.0909211129540.13890@qvzrafvba.5c.ybpny>
Message-ID: <200909212224.29096.christof.schulze@gmx.com>

having removed the cache did not do anything at first but after letting zpool 
scrub sit there for ~20 minutes (no CPU or HDD activity whatsoever) it 
suddenly started the scrubbing process.
So I seem to have hit a bug.

Regards

Christof

Am Montag 21 September 2009 17:32:05 schrieb Jason J. Hellenthal:
> On Sun, 20 Sep 2009 17:42 -0000, christof.schulze wrote:
> > Hello,
> >
> > currently I am running a 7.2 stable with zfs v13.
> > Things work nicely except that zpool scrub hangs without disk activity.
> > I do not get any error messages in dmesg or /var/log/messages and
> > therefore I do not know where to look further.
> >
> > Is this a known issue or should I investigate? If the latter is the case
> > I would need some help doing so.
> >
> > % uname -a                                           ~
> > FreeBSD ccschu935 7.2-STABLE FreeBSD 7.2-STABLE #0: Tue Jul  7 04:56:00
> > CEST 2009     root@ccschu935:/usr/obj/usr/src/sys/GENERIC  amd64
> > % zpool status                                       ~
> >  pool: tank
> > state: ONLINE
> > scrub: scrub in progress for 0h3m, 0,00% done, 3370h48m to go
> > config:
> >
> > 	NAME        STATE     READ WRITE CKSUM
> > 	tank        ONLINE       0     0     0
> > 	  ad0s6     ONLINE       0     0     0
> > 	  ad0s3f    ONLINE       0     0     0
> > 	  ad0s3e    ONLINE       0     0     0
> > 	cache
> > 	  mmcsd0    UNAVAIL      0     0     0  cannot open
> >
> > errors: No known data errors
> >
> >
> > kind Regards
> >
> > Christof
>
> I see you cache is disabled no available. Even though I don't think this
> should or might be the problem can you remove the device from the pool and
> re-scrub to see if that relieves the problem.
From lists at c0mplx.org  Mon Sep 21 21:30:41 2009
From: lists at c0mplx.org (Kurt Jaeger)
Date: Mon Sep 21 21:30:54 2009
Subject: 8.0-Beta installation problem -- Unable to find /dev/ad0s1b
In-Reply-To: <20090915073457.GO48206@home.opsec.eu>
References: <19117.42696.888649.236347@jerusalem.litteratus.org>
	<582270.67371.qm@web82203.mail.mud.yahoo.com>
	<19117.48448.269298.484728@jerusalem.litteratus.org>
	<20090914055501.GM48206@home.opsec.eu>
	<20090915064830.GN48206@home.opsec.eu>
	<20090915073457.GO48206@home.opsec.eu>
Message-ID: <20090921213039.GQ48206@home.opsec.eu>

Hi!

> My previous tests were with 8.0-beta4-amd64.

I now tested 8.0-RC1 and it works now, very nice!

-- 
pi@opsec.eu            +49 171 3101372                        11 years to go !
From hiyorin at gmail.com  Tue Sep 22 02:08:22 2009
From: hiyorin at gmail.com (C. C. Tang)
Date: Tue Sep 22 02:08:30 2009
Subject: 7.2-release/amd64: panic, spin lock held too long
In-Reply-To: <3bbf2fe10909191224m6061d325h8bc1a389e195aa30@mail.gmail.com>
References: <cf9b1ee00907061812r3da70018i1c8d8d12bb038a80@mail.gmail.com>	
	<3bbf2fe10909121432x7bd4f7es497e9431c4e520d6@mail.gmail.com>	
	<cf9b1ee00909121502v66566b46p754ed2f2e549555@mail.gmail.com>	
	<4AB1A838.2040406@gmail.com>	
	<3bbf2fe10909170216u29d994aj55c21efdfbc26ba5@mail.gmail.com>	
	<4AB21005.6040104@gmail.com> <4AB36E1F.6080401@gmail.com>	
	<cf9b1ee00909190204q33ded00dyb86a4b53ed5194be@mail.gmail.com>
	<3bbf2fe10909191224m6061d325h8bc1a389e195aa30@mail.gmail.com>
Message-ID: <4AB8318D.5000404@gmail.com>

>>>>>
>>>>>
>>> I have patched the sched_ule.c and did a make buildkernel & make
>>> installkernel (is buildworld and installworld necessary?), rebooted and the
>>> machine is running now.
>>> I will post here again if there is any update.

My server is up for 3.5 days now with HyperThreading & powerd enabled.
No panic occured yet.

C.C.

From attilio at freebsd.org  Tue Sep 22 02:10:05 2009
From: attilio at freebsd.org (Attilio Rao)
Date: Tue Sep 22 02:10:39 2009
Subject: 7.2-release/amd64: panic, spin lock held too long
In-Reply-To: <4AB8318D.5000404@gmail.com>
References: <cf9b1ee00907061812r3da70018i1c8d8d12bb038a80@mail.gmail.com>
	<3bbf2fe10909121432x7bd4f7es497e9431c4e520d6@mail.gmail.com>
	<cf9b1ee00909121502v66566b46p754ed2f2e549555@mail.gmail.com>
	<4AB1A838.2040406@gmail.com>
	<3bbf2fe10909170216u29d994aj55c21efdfbc26ba5@mail.gmail.com>
	<4AB21005.6040104@gmail.com> <4AB36E1F.6080401@gmail.com>
	<cf9b1ee00909190204q33ded00dyb86a4b53ed5194be@mail.gmail.com>
	<3bbf2fe10909191224m6061d325h8bc1a389e195aa30@mail.gmail.com>
	<4AB8318D.5000404@gmail.com>
Message-ID: <3bbf2fe10909211910r2ed6957cvb1f7f226e2a8b89d@mail.gmail.com>

2009/9/22 C. C. Tang <hiyorin@gmail.com>:
>>>>>>
>>>>>>
>>>> I have patched the sched_ule.c and did a make buildkernel & make
>>>> installkernel (is buildworld and installworld necessary?), rebooted and
>>>> the
>>>> machine is running now.
>>>> I will post here again if there is any update.
>
> My server is up for 3.5 days now with HyperThreading & powerd enabled.
> No panic occured yet.

Usually how long did it take to panic?

Attilio


-- 
Peace can only be achieved by understanding - A. Einstein
From hiyorin at gmail.com  Tue Sep 22 03:33:41 2009
From: hiyorin at gmail.com (C. C. Tang)
Date: Tue Sep 22 03:33:48 2009
Subject: 7.2-release/amd64: panic, spin lock held too long
In-Reply-To: <3bbf2fe10909211910r2ed6957cvb1f7f226e2a8b89d@mail.gmail.com>
References: <cf9b1ee00907061812r3da70018i1c8d8d12bb038a80@mail.gmail.com>	
	<3bbf2fe10909121432x7bd4f7es497e9431c4e520d6@mail.gmail.com>	
	<cf9b1ee00909121502v66566b46p754ed2f2e549555@mail.gmail.com>	
	<4AB1A838.2040406@gmail.com>	
	<3bbf2fe10909170216u29d994aj55c21efdfbc26ba5@mail.gmail.com>	
	<4AB21005.6040104@gmail.com> <4AB36E1F.6080401@gmail.com>	
	<cf9b1ee00909190204q33ded00dyb86a4b53ed5194be@mail.gmail.com>	
	<3bbf2fe10909191224m6061d325h8bc1a389e195aa30@mail.gmail.com>	
	<4AB8318D.5000404@gmail.com>
	<3bbf2fe10909211910r2ed6957cvb1f7f226e2a8b89d@mail.gmail.com>
Message-ID: <4AB8458C.8000404@gmail.com>

Attilio Rao wrote:
> 2009/9/22 C. C. Tang <hiyorin@gmail.com>:
>>>>>>>
>>>>> I have patched the sched_ule.c and did a make buildkernel & make
>>>>> installkernel (is buildworld and installworld necessary?), rebooted and
>>>>> the
>>>>> machine is running now.
>>>>> I will post here again if there is any update.
>> My server is up for 3.5 days now with HyperThreading & powerd enabled.
>> No panic occured yet.
> 
> Usually how long did it take to panic?
> 
> Attilio
> 
> 
It is rather random, but will usually panic within one week.
Anyway my server will keep running and I will report if it has any problem.

Thanks,
C.C.

From alandaluz at gmail.com  Tue Sep 22 05:51:36 2009
From: alandaluz at gmail.com (Cassidy Larson)
Date: Tue Sep 22 05:51:42 2009
Subject: Random Network Drops on Realtek Interfaces (re)
Message-ID: <d88efacd0909212225h3a301386p1446bc65a8b43cc9@mail.gmail.com>

All,

I've been experiencing an intermittent issue with a drop in networking
connectivity on a couple of boxes.

At random times I drop connectivity between the servers and their
gateway. I am able to login via the secondary interface and
"/etc/netstart" and everything starts behaving as normal. My switch
shows the link is up, ifconfig shows the link is up, but I am unable
to ping my gateway until running "/etc/netstart".  Somedays it'll
happen a few times an hour, some days once every 8-10 hours. It really
is intermittent, and driving me crazy trying to track down the issue.
I've tried different cables, switches, gateways, IPs, and locations.
Memtest for 5 days showed no errors. However, the same problem exists
on two separate installs at different times.  I am able to connect to
the one server from the second via their secondary interfaces, so the
problem isn't related to both network interfaces.

Both servers have the Supermicro X7SLM-L motherboard, same CPU, RAM
and disks.  Using the Realtek network driver (re). pciconf shows:
    vendor     = 'Realtek Semiconductor'
    device     = 'Gigabit Ethernet NIC(NDIS 6.0) (RTL8168/8111)'
    class      = network
    subclass   = ethernet

I've experienced the problem for some time now on both 7.2-RELEASE and
7.2-STABLE (09/20/09) using amd64.

Any help or suggestions would be useful in getting to the bottom of this.

Thanks,

-c
From gavin.atkinson at ury.york.ac.uk  Tue Sep 22 08:20:18 2009
From: gavin.atkinson at ury.york.ac.uk (Gavin Atkinson)
Date: Tue Sep 22 08:20:35 2009
Subject: Random Network Drops on Realtek Interfaces (re)
In-Reply-To: <d88efacd0909212225h3a301386p1446bc65a8b43cc9@mail.gmail.com>
References: <d88efacd0909212225h3a301386p1446bc65a8b43cc9@mail.gmail.com>
Message-ID: <041500ED-76EF-4203-949F-DF0C1A42EA93@ury.york.ac.uk>

On 22 Sep 2009, at 06:25, Cassidy Larson <alandaluz@gmail.com> wrote:

> I've been experiencing an intermittent issue with a drop in networking
> connectivity on a couple of boxes.
>
> At random times I drop connectivity between the servers and their
> gateway. I am able to login via the secondary interface and
> "/etc/netstart" and everything starts behaving as normal. My switch
> shows the link is up, ifconfig shows the link is up, but I am unable
> to ping my gateway until running "/etc/netstart".

Can you see if "arp -da" is sufficient to get the server online?

Thanks,

Gavin
From kama at pvp.se  Tue Sep 22 08:35:22 2009
From: kama at pvp.se (kama)
Date: Tue Sep 22 08:35:31 2009
Subject: FreeBSD 7.2-STABLE boot freeze when calibrating clock.
In-Reply-To: <20090921140345.H37424@ns1.as.pvp.se>
References: <20090921140345.H37424@ns1.as.pvp.se>
Message-ID: <20090922103150.V37424@ns1.as.pvp.se>


Ok.

I added KDB DDB and ACPI_DEBUG to the kernel and it then boots but with
this error:

---- snip ----
Preloaded elf kernel "/boot/kernel/kernel" at 0xc0ed3000.
Preloaded elf module "/boot/kernel/acpi.ko" at 0xc0ed31d8.
link_elf: symbol AcpiDmDumpMethodInfo undefined
KLD file acpi.ko - could not finalize loading
Calibrating clock(s) ... i8254 clock: 1193120 Hz
CLK_USE_I8254_CALIBRATION not specified - using default frequency
Timecounter "i8254" frequency 1193182 Hz quality 0
Calibrating TSC clock ... TSC clock: 2605923359 Hz
CPU: AMD Opteron(tm) Processor 285 (2605.92-MHz 686-class CPU)
---- snap ----

What else can I do to help you to figure this out?

/Bjorn

On Mon, 21 Sep 2009, kama wrote:

>
> Hi.
>
> I have recently upgraded the server from 6.X -> Latest 6.X -> 7.2. But
> after the upgrade it boots OK once and after that it freezes.
>
> Verbose boot give me these lines:
>
> ---- snip ----
> Copyright (c) 1992-2009 The FreeBSD Project.
> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
>         The Regents of the University of California. All rights reserved.
> FreeBSD is a registered trademark of The FreeBSD Foundation.
> FreeBSD 7.2-STABLE #2: Fri Sep 18 13:22:40 CEST 2009
>     root@gs4:/usr/obj/usr/src/sys/GENERIC
> Preloaded elf kernel "/boot/kernel/kernel" at 0xc0e7e000.
> Preloaded elf module "/boot/kernel/acpi.ko" at 0xc0e7e1d8.
> Calibrating clock(s) ... i8254 clock: 1193116 Hz
> CLK_USE_I8254_CALIBRATION not specified - using default frequency
> Timecounter "i8254" frequency 1193182 Hz quality 0
> Calibrating TSC clock ...
> ---- snap ----
>
> I can boot the system without ACPI enabled w/o problem. But once it is
> enabled it will freeze at this point.
>
> This has happend on both servers I have upgraded. Both of them are
> identical.
>
> /Bjorn
>
> Full dmesg w acpi disabled:
>
> %dmesg
> Copyright (c) 1992-2009 The FreeBSD Project.
> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
>         The Regents of the University of California. All rights reserved.
> FreeBSD is a registered trademark of The FreeBSD Foundation.
> FreeBSD 7.2-STABLE #2: Fri Sep 18 13:22:40 CEST 2009
>     root@gs4:/usr/obj/usr/src/sys/GENERIC
> Timecounter "i8254" frequency 1193182 Hz quality 0
> CPU: AMD Opteron(tm) Processor 285 (2605.93-MHz 686-class CPU)
>   Origin = "AuthenticAMD"  Id = 0x20f12  Stepping = 2
>
> Features=0x178bfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT>
>   Features2=0x1<SSE3>
>   AMD Features=0xe2500800<SYSCALL,NX,MMX+,FFXSR,LM,3DNow!+,3DNow!>
>   AMD Features2=0x2<CMP>
>   Cores per package: 2
> real memory  = 3221192704 (3071 MB)
> avail memory = 3146604544 (3000 MB)
> MPTable: <HP       PROLIANT    >
> FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
>  cpu0 (BSP): APIC ID:  0
>  cpu1 (AP): APIC ID:  1
>  cpu2 (AP): APIC ID:  2
>  cpu3 (AP): APIC ID:  3
> ioapic0: Assuming intbase of 0
> ioapic1: Assuming intbase of 24
> ioapic2: Assuming intbase of 28
> ioapic3: Assuming intbase of 32
> ioapic4: Assuming intbase of 36
> ioapic0 <Version 1.1> irqs 0-23 on motherboard
> ioapic1 <Version 1.1> irqs 24-27 on motherboard
> ioapic2 <Version 1.1> irqs 28-31 on motherboard
> ioapic3 <Version 1.1> irqs 32-35 on motherboard
> ioapic4 <Version 1.1> irqs 36-39 on motherboard
> kbd1 at kbdmux0
> pcib0: <Host to PCI bridge> pcibus 0 on motherboard
> pci0: <PCI bus> on pcib0
> pcib1: <MPTable PCI-PCI bridge> at device 3.0 on pci0
> pci1: <PCI bus> on pcib1
> ohci0: <OHCI (generic) USB controller> mem 0xf7df0000-0xf7df0fff irq 19 at
> device 0.0 on pci1
> ohci0: [GIANT-LOCKED]
> ohci0: [ITHREAD]
> usb0: OHCI version 1.0, legacy support
> usb0: SMM does not respond, resetting
> usb0: <OHCI (generic) USB controller> on ohci0
> usb0: USB revision 1.0
> uhub0: <AMD OHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb0
> uhub0: 3 ports with 3 removable, self powered
> ohci1: <OHCI (generic) USB controller> mem 0xf7de0000-0xf7de0fff irq 19 at
> device 0.1 on pci1
> ohci1: [GIANT-LOCKED]
> ohci1: [ITHREAD]
> usb1: OHCI version 1.0, legacy support
> usb1: SMM does not respond, resetting
> usb1: <OHCI (generic) USB controller> on ohci1
> usb1: USB revision 1.0
> uhub1: <AMD OHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb1
> uhub1: 3 ports with 3 removable, self powered
> pci1: <base peripheral> at device 2.0 (no driver attached)
> pci1: <base peripheral> at device 2.2 (no driver attached)
> vgapci0: <VGA-compatible display> port 0x4400-0x44ff mem
> 0xf6000000-0xf6ffffff,0xf5ff0000-0xf5ff0fff at device 3.0 on pci1
> isab0: <PCI-ISA bridge> at device 4.0 on pci0
> isa0: <ISA bus> on isab0
> atapci0: <AMD 8111 UDMA133 controller> port
> 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x2000-0x200f at device 4.1 on pci0
> ata0: <ATA channel 0> on atapci0
> ata0: [ITHREAD]
> ata1: <ATA channel 1> on atapci0
> ata1: [ITHREAD]
> pci0: <bridge> at device 4.3 (no driver attached)
> pcib2: <MPTable PCI-PCI bridge> at device 7.0 on pci0
> pci2: <PCI bus> on pcib2
> ciss0: <HP Smart Array 6i> port 0x5000-0x50ff mem
> 0xf7ef0000-0xf7ef1fff,0xf7e80000-0xf7ebffff irq 24 at device 4.0 on pci2
> ciss0: [ITHREAD]
> pcib3: <MPTable PCI-PCI bridge> at device 8.0 on pci0
> pci3: <PCI bus> on pcib3
> bge0: <HP NC7782 Gigabit Server Adapter, ASIC rev. 0x2100> mem
> 0xf7ff0000-0xf7ffffff irq 28 at device 6.0 on pci3
> miibus0: <MII bus> on bge0
> brgphy0: <BCM5704 10/100/1000baseTX PHY> PHY 1 on miibus0
> brgphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT,
> 1000baseT-FDX, auto
> bge0: Ethernet address: 00:17:a4:8d:f9:2a
> bge0: [ITHREAD]
> bge1: <HP NC7782 Gigabit Server Adapter, ASIC rev. 0x2100> mem
> 0xf7fe0000-0xf7feffff irq 29 at device 6.1 on pci3
> miibus1: <MII bus> on bge1
> brgphy1: <BCM5704 10/100/1000baseTX PHY> PHY 1 on miibus1
> brgphy1:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT,
> 1000baseT-FDX, auto
> bge1: Ethernet address: 00:17:a4:8d:f9:29
> bge1: [ITHREAD]
> cpu0 on motherboard
> powernow0: <Cool`n'Quiet K8> on cpu0
> device_attach: powernow0 attach returned 6
> cpu1 on motherboard
> powernow1: <Cool`n'Quiet K8> on cpu1
> device_attach: powernow1 attach returned 6
> cpu2 on motherboard
> powernow2: <Cool`n'Quiet K8> on cpu2
> device_attach: powernow2 attach returned 6
> cpu3 on motherboard
> powernow3: <Cool`n'Quiet K8> on cpu3
> device_attach: powernow3 attach returned 6
> eisa0: <EISA bus> on motherboard
> mainboard0: <CPQ0755 (System Board)> at slot 0 on eisa0
> pnpbios: error 1/82 getting device count/size limit
> pmtimer0 on isa0
> orm0: <ISA Option ROMs> at iomem
> 0xc0000-0xc7fff,0xc8000-0xcbfff,0xee000-0xeffff pnpid ORM0000 on isa0
> atkbdc0: <Keyboard controller (i8042)> at port 0x60,0x64 on isa0
> atkbd0: <AT Keyboard> irq 1 on atkbdc0
> kbd0 at atkbd0
> atkbd0: [GIANT-LOCKED]
> atkbd0: [ITHREAD]
> psm0: <PS/2 Mouse> irq 12 on atkbdc0
> psm0: [GIANT-LOCKED]
> psm0: [ITHREAD]
> psm0: model Generic PS/2 mouse, device ID 0
> fdc0: <Enhanced floppy controller> at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2
> on isa0
> fdc0: [FILTER]
> fd0: <1440-KB 3.5" drive> on fdc0 drive 0
> ppc0: parallel port not found.
> sc0: <System console> at flags 0x100 on isa0
> sc0: VGA <16 virtual consoles, flags=0x300>
> sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0
> sio0: type 16550A
> sio0: [FILTER]
> sio1 at port 0x2f8-0x2ff irq 3 on isa0
> sio1: type 16550A
> sio1: [FILTER]
> vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0
> Timecounters tick every 1.000 msec
> acd0: CDROM <TSSTcorpCD-ROM TS-L162C/N204> at ata0-master UDMA33
> da0 at ciss0 bus 0 target 0 lun 0
> da0: <COMPAQ RAID 1  VOLUME OK> Fixed Direct Access SCSI-0 device
> da0: 135.168MB/s transfers
> SdMaP0::  ACPo mCmPaUn d# 1Q uLeauuenicnhge dE!n
> abled
> da0: 69452MB (142239510 512 bSyMtPe:  sAePc tCoPrUs :# 22 5L5aunHc
> h6e3dS/!T
>  8854C)
> SMP: AP CPU #3 Launched!
> Trying to mount root from ufs:/dev/da0s1a
> bge0: link state changed to UP
>
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
>
From avg at icyb.net.ua  Tue Sep 22 10:39:31 2009
From: avg at icyb.net.ua (Andriy Gapon)
Date: Tue Sep 22 10:39:44 2009
Subject: FreeBSD 7.2-STABLE boot freeze when calibrating clock.
In-Reply-To: <20090922103150.V37424@ns1.as.pvp.se>
References: <20090921140345.H37424@ns1.as.pvp.se>
	<20090922103150.V37424@ns1.as.pvp.se>
Message-ID: <4AB8A95E.3060307@icyb.net.ua>

on 22/09/2009 11:35 kama said the following:
> Ok.
> 
> I added KDB DDB and ACPI_DEBUG to the kernel and it then boots but with
> this error:
> 
> ---- snip ----
> Preloaded elf kernel "/boot/kernel/kernel" at 0xc0ed3000.
> Preloaded elf module "/boot/kernel/acpi.ko" at 0xc0ed31d8.
> link_elf: symbol AcpiDmDumpMethodInfo undefined
> KLD file acpi.ko - could not finalize loading
> Calibrating clock(s) ... i8254 clock: 1193120 Hz
> CLK_USE_I8254_CALIBRATION not specified - using default frequency
> Timecounter "i8254" frequency 1193182 Hz quality 0
> Calibrating TSC clock ... TSC clock: 2605923359 Hz
> CPU: AMD Opteron(tm) Processor 285 (2605.92-MHz 686-class CPU)
> ---- snap ----
> 
> What else can I do to help you to figure this out?


This is a very strange error.
Did you install a binary distribution or did build your kernel from sources?
>From your demsg I think that it is the latter.
And I believe that your source tree may be damaged somehow.
Please try again with a clean checkout from (- this is important -) a known good
place, some cvsup mirrors have been known to serve inconsistent sources.


> On Mon, 21 Sep 2009, kama wrote:
> 
>> Hi.
>>
>> I have recently upgraded the server from 6.X -> Latest 6.X -> 7.2. But
>> after the upgrade it boots OK once and after that it freezes.
>>
>> Verbose boot give me these lines:
>>
>> ---- snip ----
>> Copyright (c) 1992-2009 The FreeBSD Project.
>> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
>>         The Regents of the University of California. All rights reserved.
>> FreeBSD is a registered trademark of The FreeBSD Foundation.
>> FreeBSD 7.2-STABLE #2: Fri Sep 18 13:22:40 CEST 2009
>>     root@gs4:/usr/obj/usr/src/sys/GENERIC
>> Preloaded elf kernel "/boot/kernel/kernel" at 0xc0e7e000.
>> Preloaded elf module "/boot/kernel/acpi.ko" at 0xc0e7e1d8.
>> Calibrating clock(s) ... i8254 clock: 1193116 Hz
>> CLK_USE_I8254_CALIBRATION not specified - using default frequency
>> Timecounter "i8254" frequency 1193182 Hz quality 0
>> Calibrating TSC clock ...
>> ---- snap ----
>>
>> I can boot the system without ACPI enabled w/o problem. But once it is
>> enabled it will freeze at this point.
>>
>> This has happend on both servers I have upgraded. Both of them are
>> identical.
>>
>> /Bjorn
>>
>> Full dmesg w acpi disabled:
>>
>> %dmesg
>> Copyright (c) 1992-2009 The FreeBSD Project.
>> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
>>         The Regents of the University of California. All rights reserved.
>> FreeBSD is a registered trademark of The FreeBSD Foundation.
>> FreeBSD 7.2-STABLE #2: Fri Sep 18 13:22:40 CEST 2009
>>     root@gs4:/usr/obj/usr/src/sys/GENERIC
>> Timecounter "i8254" frequency 1193182 Hz quality 0
>> CPU: AMD Opteron(tm) Processor 285 (2605.93-MHz 686-class CPU)
>>   Origin = "AuthenticAMD"  Id = 0x20f12  Stepping = 2
>>
>> Features=0x178bfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT>
>>   Features2=0x1<SSE3>
>>   AMD Features=0xe2500800<SYSCALL,NX,MMX+,FFXSR,LM,3DNow!+,3DNow!>
>>   AMD Features2=0x2<CMP>
>>   Cores per package: 2
>> real memory  = 3221192704 (3071 MB)
>> avail memory = 3146604544 (3000 MB)
>> MPTable: <HP       PROLIANT    >
>> FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
>>  cpu0 (BSP): APIC ID:  0
>>  cpu1 (AP): APIC ID:  1
>>  cpu2 (AP): APIC ID:  2
>>  cpu3 (AP): APIC ID:  3
>> ioapic0: Assuming intbase of 0
>> ioapic1: Assuming intbase of 24
>> ioapic2: Assuming intbase of 28
>> ioapic3: Assuming intbase of 32
>> ioapic4: Assuming intbase of 36
>> ioapic0 <Version 1.1> irqs 0-23 on motherboard
>> ioapic1 <Version 1.1> irqs 24-27 on motherboard
>> ioapic2 <Version 1.1> irqs 28-31 on motherboard
>> ioapic3 <Version 1.1> irqs 32-35 on motherboard
>> ioapic4 <Version 1.1> irqs 36-39 on motherboard
>> kbd1 at kbdmux0
>> pcib0: <Host to PCI bridge> pcibus 0 on motherboard
>> pci0: <PCI bus> on pcib0
>> pcib1: <MPTable PCI-PCI bridge> at device 3.0 on pci0
>> pci1: <PCI bus> on pcib1
>> ohci0: <OHCI (generic) USB controller> mem 0xf7df0000-0xf7df0fff irq 19 at
>> device 0.0 on pci1
>> ohci0: [GIANT-LOCKED]
>> ohci0: [ITHREAD]
>> usb0: OHCI version 1.0, legacy support
>> usb0: SMM does not respond, resetting
>> usb0: <OHCI (generic) USB controller> on ohci0
>> usb0: USB revision 1.0
>> uhub0: <AMD OHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb0
>> uhub0: 3 ports with 3 removable, self powered
>> ohci1: <OHCI (generic) USB controller> mem 0xf7de0000-0xf7de0fff irq 19 at
>> device 0.1 on pci1
>> ohci1: [GIANT-LOCKED]
>> ohci1: [ITHREAD]
>> usb1: OHCI version 1.0, legacy support
>> usb1: SMM does not respond, resetting
>> usb1: <OHCI (generic) USB controller> on ohci1
>> usb1: USB revision 1.0
>> uhub1: <AMD OHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb1
>> uhub1: 3 ports with 3 removable, self powered
>> pci1: <base peripheral> at device 2.0 (no driver attached)
>> pci1: <base peripheral> at device 2.2 (no driver attached)
>> vgapci0: <VGA-compatible display> port 0x4400-0x44ff mem
>> 0xf6000000-0xf6ffffff,0xf5ff0000-0xf5ff0fff at device 3.0 on pci1
>> isab0: <PCI-ISA bridge> at device 4.0 on pci0
>> isa0: <ISA bus> on isab0
>> atapci0: <AMD 8111 UDMA133 controller> port
>> 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x2000-0x200f at device 4.1 on pci0
>> ata0: <ATA channel 0> on atapci0
>> ata0: [ITHREAD]
>> ata1: <ATA channel 1> on atapci0
>> ata1: [ITHREAD]
>> pci0: <bridge> at device 4.3 (no driver attached)
>> pcib2: <MPTable PCI-PCI bridge> at device 7.0 on pci0
>> pci2: <PCI bus> on pcib2
>> ciss0: <HP Smart Array 6i> port 0x5000-0x50ff mem
>> 0xf7ef0000-0xf7ef1fff,0xf7e80000-0xf7ebffff irq 24 at device 4.0 on pci2
>> ciss0: [ITHREAD]
>> pcib3: <MPTable PCI-PCI bridge> at device 8.0 on pci0
>> pci3: <PCI bus> on pcib3
>> bge0: <HP NC7782 Gigabit Server Adapter, ASIC rev. 0x2100> mem
>> 0xf7ff0000-0xf7ffffff irq 28 at device 6.0 on pci3
>> miibus0: <MII bus> on bge0
>> brgphy0: <BCM5704 10/100/1000baseTX PHY> PHY 1 on miibus0
>> brgphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT,
>> 1000baseT-FDX, auto
>> bge0: Ethernet address: 00:17:a4:8d:f9:2a
>> bge0: [ITHREAD]
>> bge1: <HP NC7782 Gigabit Server Adapter, ASIC rev. 0x2100> mem
>> 0xf7fe0000-0xf7feffff irq 29 at device 6.1 on pci3
>> miibus1: <MII bus> on bge1
>> brgphy1: <BCM5704 10/100/1000baseTX PHY> PHY 1 on miibus1
>> brgphy1:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT,
>> 1000baseT-FDX, auto
>> bge1: Ethernet address: 00:17:a4:8d:f9:29
>> bge1: [ITHREAD]
>> cpu0 on motherboard
>> powernow0: <Cool`n'Quiet K8> on cpu0
>> device_attach: powernow0 attach returned 6
>> cpu1 on motherboard
>> powernow1: <Cool`n'Quiet K8> on cpu1
>> device_attach: powernow1 attach returned 6
>> cpu2 on motherboard
>> powernow2: <Cool`n'Quiet K8> on cpu2
>> device_attach: powernow2 attach returned 6
>> cpu3 on motherboard
>> powernow3: <Cool`n'Quiet K8> on cpu3
>> device_attach: powernow3 attach returned 6
>> eisa0: <EISA bus> on motherboard
>> mainboard0: <CPQ0755 (System Board)> at slot 0 on eisa0
>> pnpbios: error 1/82 getting device count/size limit
>> pmtimer0 on isa0
>> orm0: <ISA Option ROMs> at iomem
>> 0xc0000-0xc7fff,0xc8000-0xcbfff,0xee000-0xeffff pnpid ORM0000 on isa0
>> atkbdc0: <Keyboard controller (i8042)> at port 0x60,0x64 on isa0
>> atkbd0: <AT Keyboard> irq 1 on atkbdc0
>> kbd0 at atkbd0
>> atkbd0: [GIANT-LOCKED]
>> atkbd0: [ITHREAD]
>> psm0: <PS/2 Mouse> irq 12 on atkbdc0
>> psm0: [GIANT-LOCKED]
>> psm0: [ITHREAD]
>> psm0: model Generic PS/2 mouse, device ID 0
>> fdc0: <Enhanced floppy controller> at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2
>> on isa0
>> fdc0: [FILTER]
>> fd0: <1440-KB 3.5" drive> on fdc0 drive 0
>> ppc0: parallel port not found.
>> sc0: <System console> at flags 0x100 on isa0
>> sc0: VGA <16 virtual consoles, flags=0x300>
>> sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0
>> sio0: type 16550A
>> sio0: [FILTER]
>> sio1 at port 0x2f8-0x2ff irq 3 on isa0
>> sio1: type 16550A
>> sio1: [FILTER]
>> vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0
>> Timecounters tick every 1.000 msec
>> acd0: CDROM <TSSTcorpCD-ROM TS-L162C/N204> at ata0-master UDMA33
>> da0 at ciss0 bus 0 target 0 lun 0
>> da0: <COMPAQ RAID 1  VOLUME OK> Fixed Direct Access SCSI-0 device
>> da0: 135.168MB/s transfers
>> SdMaP0::  ACPo mCmPaUn d# 1Q uLeauuenicnhge dE!n
>> abled
>> da0: 69452MB (142239510 512 bSyMtPe:  sAePc tCoPrUs :# 22 5L5aunHc
>> h6e3dS/!T
>>  8854C)
>> SMP: AP CPU #3 Launched!
>> Trying to mount root from ufs:/dev/da0s1a
>> bge0: link state changed to UP
>>
>> _______________________________________________
>> freebsd-stable@freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
>> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
>>
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
> 


-- 
Andriy Gapon
From avg at icyb.net.ua  Tue Sep 22 10:54:51 2009
From: avg at icyb.net.ua (Andriy Gapon)
Date: Tue Sep 22 10:54:58 2009
Subject: PATA disks/DVD not detected on ATI IXP 700 - cannot boot (dmesg
 attached)
In-Reply-To: <20090921170516.GA52169@zod.isi.edu>
References: <20090916161327.GB87631@zod.isi.edu>	<20090919035214.GA12889@zod.isi.edu>	<200909211239.25614.jkim@FreeBSD.org>
	<20090921170516.GA52169@zod.isi.edu>
Message-ID: <4AB8ACF2.3080104@icyb.net.ua>

on 21/09/2009 20:05 Ted Faber said the following:
> Thanks for getting back to me.  It does seem to be fixed in 8.0-RC1 (and
> thanks for that fix, too).  That is, 8.0-RC1 finds the drive, but...
> 
> 8.0 (RELENG_8, from last night) doesn't seem to find the FBSD partitions
> on the drive.  It finds the drive and the BIOS partition (slice).  It
> fails on my old motherboard (not the one above) that boots 7.2-STABLE
> just fine.  It drops me into the menu to manually configure the root
> partition, but doesn't accept either the native device names for the
> root partition (/dev/ad0s1a) or a geom label (/dev/label/root).  The
> list of GEOM devices only includes ad0 and ad0s1.
> 
> The disk isn't dangerously dedicated, but I only added geom labels to
> the partitions last night.  The glabels work fine under 7.2-STABLE, but
> RELENG_8 seems to ignore them.  I've attached output from fdisk,
> bsdlabel, and glabel in case I'm misinterpreting them.
> 
> I've been waiting for a free moment to write a more complete report, but
> since I've got your attention...
> 
> Any ideas?  I'll be able to run more diagnostics under 8.0 tonight.

This could be another of GEOM_PART_BSD vs GEOM_BSD issues.
I think this topic has been discussed several times recently on -current.

-- 
Andriy Gapon
From gaijin.k at gmail.com  Tue Sep 22 12:55:36 2009
From: gaijin.k at gmail.com (Alexandre "Sunny" Kovalenko)
Date: Tue Sep 22 12:55:49 2009
Subject: Random Network Drops on Realtek Interfaces (re)
In-Reply-To: <d88efacd0909212225h3a301386p1446bc65a8b43cc9@mail.gmail.com>
References: <d88efacd0909212225h3a301386p1446bc65a8b43cc9@mail.gmail.com>
Message-ID: <1253624122.1321.9.camel@RabbitsDen>

On Mon, 2009-09-21 at 23:25 -0600, Cassidy Larson wrote:
> All,
> 
> I've been experiencing an intermittent issue with a drop in networking
> connectivity on a couple of boxes.
> 
> At random times I drop connectivity between the servers and their
> gateway. I am able to login via the secondary interface and
> "/etc/netstart" and everything starts behaving as normal. My switch
> shows the link is up, ifconfig shows the link is up, but I am unable
> to ping my gateway until running "/etc/netstart".  Somedays it'll
> happen a few times an hour, some days once every 8-10 hours. It really
> is intermittent, and driving me crazy trying to track down the issue.
> I've tried different cables, switches, gateways, IPs, and locations.
> Memtest for 5 days showed no errors. However, the same problem exists
> on two separate installs at different times.  I am able to connect to
> the one server from the second via their secondary interfaces, so the
> problem isn't related to both network interfaces.
> 
> Both servers have the Supermicro X7SLM-L motherboard, same CPU, RAM
> and disks.  Using the Realtek network driver (re). pciconf shows:
>     vendor     = 'Realtek Semiconductor'
>     device     = 'Gigabit Ethernet NIC(NDIS 6.0) (RTL8168/8111)'
>     class      = network
>     subclass   = ethernet
> 
> I've experienced the problem for some time now on both 7.2-RELEASE and
> 7.2-STABLE (09/20/09) using amd64.
> 
> Any help or suggestions would be useful in getting to the bottom of this.
I do not know how applicable this is in your case, but I have seen such
behavior when speed auto-negotiation was allowed on the box connected to
the Cisco switch. Condition was usually triggered by the certain volume
of traffic (e.g. system could be fine for weeks with SSH/telnet/X11 and
lose interface when someone sends large file over FTP or SCP).
Restarting the interface, usually fixed it for a while.

In my case it was platform-agnostic causing me to have a cheat-sheet on
how to disable auto-negotiation on AIX/Solaris/Linux/etc.

-- 
Alexandre Kovalenko (????????? ?????????)


From kama at pvp.se  Tue Sep 22 13:49:00 2009
From: kama at pvp.se (kama)
Date: Tue Sep 22 13:49:23 2009
Subject: FreeBSD 7.2-STABLE boot freeze when calibrating clock.
In-Reply-To: <4AB8A95E.3060307@icyb.net.ua>
References: <20090921140345.H37424@ns1.as.pvp.se>
	<20090922103150.V37424@ns1.as.pvp.se>
	<4AB8A95E.3060307@icyb.net.ua>
Message-ID: <20090922142526.P37424@ns1.as.pvp.se>



On Tue, 22 Sep 2009, Andriy Gapon wrote:

> on 22/09/2009 11:35 kama said the following:
> > Ok.
> >
> > I added KDB DDB and ACPI_DEBUG to the kernel and it then boots but with
> > this error:
> >
> > ---- snip ----
> > Preloaded elf kernel "/boot/kernel/kernel" at 0xc0ed3000.
> > Preloaded elf module "/boot/kernel/acpi.ko" at 0xc0ed31d8.
> > link_elf: symbol AcpiDmDumpMethodInfo undefined
> > KLD file acpi.ko - could not finalize loading
> > Calibrating clock(s) ... i8254 clock: 1193120 Hz
> > CLK_USE_I8254_CALIBRATION not specified - using default frequency
> > Timecounter "i8254" frequency 1193182 Hz quality 0
> > Calibrating TSC clock ... TSC clock: 2605923359 Hz
> > CPU: AMD Opteron(tm) Processor 285 (2605.92-MHz 686-class CPU)
> > ---- snap ----
> >
> > What else can I do to help you to figure this out?
>
>
> This is a very strange error.
> Did you install a binary distribution or did build your kernel from sources?
> >From your demsg I think that it is the latter.
> And I believe that your source tree may be damaged somehow.
> Please try again with a clean checkout from (- this is important -) a known good
> place, some cvsup mirrors have been known to serve inconsistent sources.

I have now changed from cvsup.dk.freebsd.org to cvsup.freebsd.org with no
luck.

These are the steps I do (and have done for ages):
# cd /usr/src
# make clean cleandir
# cd ..
# rm -rf src/* obj/*
# cd
# csup stable-supfile-7
# cd /usr/src
# make buildworld
# make buildkernel
# make installkernel
# mergemaster -p
# make installworld
# mergemaster -U -i
# reboot

I see that there are a newer BIOS on the HP homepage for this DL385. I
will try to update the BIOS later this week.

The servers are not up to be in production until early november, so there
are some time to test things.

/Bjorn
From avg at icyb.net.ua  Tue Sep 22 14:34:47 2009
From: avg at icyb.net.ua (Andriy Gapon)
Date: Tue Sep 22 14:34:55 2009
Subject: FreeBSD 7.2-STABLE boot freeze when calibrating clock.
In-Reply-To: <20090922142526.P37424@ns1.as.pvp.se>
References: <20090921140345.H37424@ns1.as.pvp.se>	<20090922103150.V37424@ns1.as.pvp.se>	<4AB8A95E.3060307@icyb.net.ua>
	<20090922142526.P37424@ns1.as.pvp.se>
Message-ID: <4AB8E082.8050100@icyb.net.ua>

on 22/09/2009 16:48 kama said the following:
> 
> On Tue, 22 Sep 2009, Andriy Gapon wrote:
> 
>> on 22/09/2009 11:35 kama said the following:
>>> Ok.
>>>
>>> I added KDB DDB and ACPI_DEBUG to the kernel and it then boots but with
>>> this error:
>>>
>>> ---- snip ----
>>> Preloaded elf kernel "/boot/kernel/kernel" at 0xc0ed3000.
>>> Preloaded elf module "/boot/kernel/acpi.ko" at 0xc0ed31d8.
>>> link_elf: symbol AcpiDmDumpMethodInfo undefined
>>> KLD file acpi.ko - could not finalize loading
>>> Calibrating clock(s) ... i8254 clock: 1193120 Hz
>>> CLK_USE_I8254_CALIBRATION not specified - using default frequency
>>> Timecounter "i8254" frequency 1193182 Hz quality 0
>>> Calibrating TSC clock ... TSC clock: 2605923359 Hz
>>> CPU: AMD Opteron(tm) Processor 285 (2605.92-MHz 686-class CPU)
>>> ---- snap ----
>>>
>>> What else can I do to help you to figure this out?
>>
>> This is a very strange error.
>> Did you install a binary distribution or did build your kernel from sources?
>> >From your demsg I think that it is the latter.
>> And I believe that your source tree may be damaged somehow.
>> Please try again with a clean checkout from (- this is important -) a known good
>> place, some cvsup mirrors have been known to serve inconsistent sources.
> 
> I have now changed from cvsup.dk.freebsd.org to cvsup.freebsd.org with no
> luck.
> 
> These are the steps I do (and have done for ages):
> # cd /usr/src
> # make clean cleandir
> # cd ..
> # rm -rf src/* obj/*
> # cd
> # csup stable-supfile-7
> # cd /usr/src
> # make buildworld
> # make buildkernel
> # make installkernel
> # mergemaster -p
> # make installworld
> # mergemaster -U -i
> # reboot
> 
> I see that there are a newer BIOS on the HP homepage for this DL385. I
> will try to update the BIOS later this week.
> 
> The servers are not up to be in production until early november, so there
> are some time to test things.
> 

I specifically meant this message:
link_elf: symbol AcpiDmDumpMethodInfo undefined

$ glimpse AcpiDmDumpMethodInfo
/usr/src/sys/contrib/dev/acpica/dmobject.c:  * FUNCTION:    AcpiDmDumpMethodInfo
/usr/src/sys/contrib/dev/acpica/dmobject.c: AcpiDmDumpMethodInfo (
/usr/src/sys/contrib/dev/acpica/dsmethod.c:         AcpiDmDumpMethodInfo (Status,
WalkState, WalkState->Op);
/usr/src/sys/contrib/dev/acpica/acdisasm.h: AcpiDmDumpMethodInfo (

So this function is both defined and used only inside acpi code (vendor part of it).
The error you get does not seem to be a run-time condition.
It seems to be a system build/install issue (and it looks like the issue is unique
to you).
I am almost out of guesses, maybe you have stale acpi.ko module in some modules
directory.

Hmm, one last idea - maybe you have something like "build modules with world"
option and also perhaps ACPI_DEBUG is defined somewhere?
It could be that something gets out of sync with respect to ACPI_DISASSEMBLER macro.
Output of the following command may be useful:
$ nm -A /boot/kernel/* | fgrep AcpiDmDumpMethodInfo

Could you please try investigating this? Maybe even include acpi into kernel?

-- 
Andriy Gapon
From faber at isi.edu  Tue Sep 22 15:31:41 2009
From: faber at isi.edu (Ted Faber)
Date: Tue Sep 22 15:31:47 2009
Subject: PATA disks/DVD not detected on ATI IXP 700 - cannot boot (dmesg
	attached)
In-Reply-To: <4AB8ACF2.3080104@icyb.net.ua>
References: <20090916161327.GB87631@zod.isi.edu>
	<20090919035214.GA12889@zod.isi.edu>
	<200909211239.25614.jkim@FreeBSD.org>
	<20090921170516.GA52169@zod.isi.edu> <4AB8ACF2.3080104@icyb.net.ua>
Message-ID: <20090922153139.GC38036@zod.isi.edu>

On Tue, Sep 22, 2009 at 01:54:42PM +0300, Andriy Gapon wrote:
> > Any ideas?  I'll be able to run more diagnostics under 8.0 tonight.
> 
> This could be another of GEOM_PART_BSD vs GEOM_BSD issues.
> I think this topic has been discussed several times recently on -current.

This looks like the problem.  Thanks for the pointer.  I remembered
something like this, but couldn't put my finger on it.  Just to make
life easier for the next guy the thread with this message (which
includes the dd hex that fixes it) seems to cover it.

http://docs.freebsd.org/cgi/getmsg.cgi?fetch=774931+0+archive/2009/freebsd-current/20090118.freebsd-current

Which looks like the exact right thing for me.  I'll follow up when I
know for sure, but thanks much for the pointer!

-- 
Ted Faber
http://www.isi.edu/~faber           PGP: http://www.isi.edu/~faber/pubkeys.asc
Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090922/f34809d2/attachment.pgp
From pyunyh at gmail.com  Tue Sep 22 20:01:46 2009
From: pyunyh at gmail.com (Pyun YongHyeon)
Date: Tue Sep 22 20:01:52 2009
Subject: Random Network Drops on Realtek Interfaces (re)
In-Reply-To: <d88efacd0909212225h3a301386p1446bc65a8b43cc9@mail.gmail.com>
References: <d88efacd0909212225h3a301386p1446bc65a8b43cc9@mail.gmail.com>
Message-ID: <20090922200053.GA1520@michelle.cdnetworks.com>

On Mon, Sep 21, 2009 at 11:25:17PM -0600, Cassidy Larson wrote:
> All,
> 
> I've been experiencing an intermittent issue with a drop in networking
> connectivity on a couple of boxes.
> 
> At random times I drop connectivity between the servers and their
> gateway. I am able to login via the secondary interface and
> "/etc/netstart" and everything starts behaving as normal. My switch
> shows the link is up, ifconfig shows the link is up, but I am unable
> to ping my gateway until running "/etc/netstart".  Somedays it'll
> happen a few times an hour, some days once every 8-10 hours. It really
> is intermittent, and driving me crazy trying to track down the issue.
> I've tried different cables, switches, gateways, IPs, and locations.
> Memtest for 5 days showed no errors. However, the same problem exists
> on two separate installs at different times.  I am able to connect to
> the one server from the second via their secondary interfaces, so the
> problem isn't related to both network interfaces.
> 
> Both servers have the Supermicro X7SLM-L motherboard, same CPU, RAM
> and disks.  Using the Realtek network driver (re). pciconf shows:
>     vendor     = 'Realtek Semiconductor'
>     device     = 'Gigabit Ethernet NIC(NDIS 6.0) (RTL8168/8111)'
>     class      = network
>     subclass   = ethernet
> 
> I've experienced the problem for some time now on both 7.2-RELEASE and
> 7.2-STABLE (09/20/09) using amd64.
> 
> Any help or suggestions would be useful in getting to the bottom of this.
> 
> Thanks,
> 

By chace can you find any messages in dmesg reported by re(4)?
dmesg output related to re(4) would be more helpful as RealTek
controllers used to show same device ids.
From alandaluz at gmail.com  Tue Sep 22 23:33:19 2009
From: alandaluz at gmail.com (Cassidy Larson)
Date: Tue Sep 22 23:33:27 2009
Subject: Random Network Drops on Realtek Interfaces (re)
In-Reply-To: <20090922200053.GA1520@michelle.cdnetworks.com>
References: <d88efacd0909212225h3a301386p1446bc65a8b43cc9@mail.gmail.com>
	<20090922200053.GA1520@michelle.cdnetworks.com>
Message-ID: <d88efacd0909221633w64b86766h6fc2adf7e8187d0f@mail.gmail.com>

Suggestions were:
 #1) try "arp -da".  This does not fix the issue.  I don't see any ARP
for any other IPs other than the local.
 #2) speed/duplex settings. I tried forcing 100FD on the box and that
didnt resolve the issue. When I did force 100 full-duplex on the
switch, the box appeared as if it was reporting 100HD. Odd.

> By chace can you find any messages in dmesg reported by re(4)?
> dmesg output related to re(4) would be more helpful as RealTek
> controllers used to show same device ids.

Here is my dmesg output for the re(4) devices:
re0: <RealTek 8168/8168B/8168C/8168CP/8168D/8168DP/8111B/8111C/8111CP/8111DP
PCIe Gigabit Ethernet> port 0xd800-0xd8ff mem
0xfeaff000-0xfeafffff,0xfdef0000-0xfdefffff irq 16 at device 0.0 on
pci2
re0: Using 1 MSI messages
re0: Chip rev. 0x3c000000
re0: MAC rev. 0x00400000
miibus0: <MII bus> on re0
re0: Ethernet address: 00:30:48:b0:ec:84
re0: [FILTER]
re1: <RealTek 8168/8168B/8168C/8168CP/8168D/8168DP/8111B/8111C/8111CP/8111DP
PCIe Gigabit Ethernet> port 0xe800-0xe8ff mem
0xfebff000-0xfebfffff,0xfdff0000-0xfdffffff irq 17 at device 0.0 on
pci3
re1: Using 1 MSI messages
re1: Chip rev. 0x3c000000
re1: MAC rev. 0x00400000
miibus1: <MII bus> on re1
re1: Ethernet address: 00:30:48:b0:ec:85
re1: [FILTER]

Currently, I am not using re1. Only re0 for access.

Another side note, I have updated the BIOS to 1.0a from Supermicro as
of yesterday, but that has not fixed this issue.

Thanks,

-c
From pyunyh at gmail.com  Wed Sep 23 00:04:53 2009
From: pyunyh at gmail.com (Pyun YongHyeon)
Date: Wed Sep 23 00:05:00 2009
Subject: Random Network Drops on Realtek Interfaces (re)
In-Reply-To: <d88efacd0909221633w64b86766h6fc2adf7e8187d0f@mail.gmail.com>
References: <d88efacd0909212225h3a301386p1446bc65a8b43cc9@mail.gmail.com>
	<20090922200053.GA1520@michelle.cdnetworks.com>
	<d88efacd0909221633w64b86766h6fc2adf7e8187d0f@mail.gmail.com>
Message-ID: <20090923000405.GC1520@michelle.cdnetworks.com>

On Tue, Sep 22, 2009 at 05:33:18PM -0600, Cassidy Larson wrote:
> Suggestions were:
>  #1) try "arp -da".  This does not fix the issue.  I don't see any ARP
> for any other IPs other than the local.
>  #2) speed/duplex settings. I tried forcing 100FD on the box and that
> didnt resolve the issue. When I did force 100 full-duplex on the
> switch, the box appeared as if it was reporting 100HD. Odd.
> 

Don't do that. It would be normal behavior if link partner's
media configuration is autodetect as link partner have to rely on
parallel detection. If you have to use forced link, both your NIC
and link partner should use the same forced media configuration
which is highly discouraged configuration on gigabit links.

> > By chace can you find any messages in dmesg reported by re(4)?
> > dmesg output related to re(4) would be more helpful as RealTek
> > controllers used to show same device ids.
> 
> Here is my dmesg output for the re(4) devices:
> re0: <RealTek 8168/8168B/8168C/8168CP/8168D/8168DP/8111B/8111C/8111CP/8111DP
> PCIe Gigabit Ethernet> port 0xd800-0xd8ff mem
> 0xfeaff000-0xfeafffff,0xfdef0000-0xfdefffff irq 16 at device 0.0 on
> pci2
> re0: Using 1 MSI messages
> re0: Chip rev. 0x3c000000
> re0: MAC rev. 0x00400000
> miibus0: <MII bus> on re0
> re0: Ethernet address: 00:30:48:b0:ec:84
> re0: [FILTER]
> re1: <RealTek 8168/8168B/8168C/8168CP/8168D/8168DP/8111B/8111C/8111CP/8111DP
> PCIe Gigabit Ethernet> port 0xe800-0xe8ff mem
> 0xfebff000-0xfebfffff,0xfdff0000-0xfdffffff irq 17 at device 0.0 on
> pci3
> re1: Using 1 MSI messages
> re1: Chip rev. 0x3c000000
> re1: MAC rev. 0x00400000
> miibus1: <MII bus> on re1
> re1: Ethernet address: 00:30:48:b0:ec:85
> re1: [FILTER]
> 
> Currently, I am not using re1. Only re0 for access.
> 

It looks plain RTL8168C PCIe controller. Is there any odd messages
reported by re(4) such as watchdog timeouts?
If you disable MSI feature does it make any difference?(Add
hw.re.msi_disable="1" to /boot/loader.conf to disable MSI.)

> Another side note, I have updated the BIOS to 1.0a from Supermicro as
> of yesterday, but that has not fixed this issue.
> 
> Thanks,
> 
> -c
From crapsh at monkeybrains.net  Wed Sep 23 00:10:11 2009
From: crapsh at monkeybrains.net (Rudy)
Date: Wed Sep 23 00:10:18 2009
Subject: em0 watchdog timeouts -- looking for dcgdis.zip
Message-ID: <4AB9638B.8040607@monkeybrains.net>

I am having watchdog timeout issues with my Intel 82573 Pro/1000 ...
http://lists.freebsd.org/pipermail/freebsd-net/2008-May/018075.html

link to dcgdis.zip didn't work.  Do you have a copy?

Thanks in advance,
Rudy

From alandaluz at gmail.com  Wed Sep 23 00:27:53 2009
From: alandaluz at gmail.com (Cassidy Larson)
Date: Wed Sep 23 00:28:01 2009
Subject: Random Network Drops on Realtek Interfaces (re)
In-Reply-To: <20090923000405.GC1520@michelle.cdnetworks.com>
References: <d88efacd0909212225h3a301386p1446bc65a8b43cc9@mail.gmail.com>
	<20090922200053.GA1520@michelle.cdnetworks.com>
	<d88efacd0909221633w64b86766h6fc2adf7e8187d0f@mail.gmail.com>
	<20090923000405.GC1520@michelle.cdnetworks.com>
Message-ID: <d88efacd0909221727r686a42fbh5f61f7fd9e936fc8@mail.gmail.com>

> It looks plain RTL8168C PCIe controller. Is there any odd messages
> reported by re(4) such as watchdog timeouts?
> If you disable MSI feature does it make any difference?(Add
> hw.re.msi_disable="1" to /boot/loader.conf to disable MSI.)

No watchdog timeouts reported. I'll try the msi_disable option tonight
and report back.

Thanks,

-c
From bu7cher at yandex.ru  Wed Sep 23 04:28:02 2009
From: bu7cher at yandex.ru (Andrey V. Elsukov)
Date: Wed Sep 23 04:28:09 2009
Subject: PATA disks/DVD not detected on ATI IXP 700 - cannot boot (dmesg
 attached)
In-Reply-To: <200909211239.25614.jkim@FreeBSD.org>
References: <20090916161327.GB87631@zod.isi.edu>	<20090919035214.GA12889@zod.isi.edu>
	<200909211239.25614.jkim@FreeBSD.org>
Message-ID: <4AB9A3CE.4090509@yandex.ru>

Jung-uk Kim wrote:
> This is a known problem and should be fixed in 8.0.  Sorry, I haven't 
> had time to back-port the code.  Proabably it's good time to consider 
> testing 8.0-RC1. ;-)

Hi,

Can you look at this?
http://butcher.heavennet.ru/patches/kernel/ata/ata-ati-r191568-backport-to-RELENG_7.diff

So, it isn't tested (sorry, i don't have any test machines with RELENG_7, only HEAD :)
Ted and Dennis can you try it?

-- 
WBR, Andrey V. Elsukov
From mamalos at eng.auth.gr  Wed Sep 23 08:11:22 2009
From: mamalos at eng.auth.gr (George Mamalakis)
Date: Wed Sep 23 08:11:30 2009
Subject: MSI GT 627 unsuccessful installation in 7-STABLE and 8-BETA4
In-Reply-To: <4AAA848C.4060707@gmail.com>
References: <4AAA7C71.8070708@eng.auth.gr> <4AAA848C.4060707@gmail.com>
Message-ID: <4AB9D823.9050300@eng.auth.gr>

Manolis Kiagias wrote:
> George Mamalakis wrote:
>   
>> Dear all,
>>
>> My question should maybe have be sent to some other fbsd list; if so,
>> please someone instruct me where, and excuse me for my potential mistake.
>>
>> Now to my question:
>>
>> I just bought the MSI GT 627 Laptop, and I tried to install FreeBSD on
>> it. First I tried with 8-BETA4 amd, then with 8-BETA4 i386, and lastly
>> with 7.2 latest snapshot. All attempts have been unsuccessful, so I
>> tried NetBSD 5.0.1 to see if it would install, and it did!
>>
>> The kernel messages I got on all FOUR attempts (even in NetBSD,
>> although it worked finally) was something like that (in the beginning)
>> (NetBSD excerpt, since it is the only that booted, so I could
>> copy-paste it from dmesg, but FreeBSD gave the exact same Error
>> messages (a few numbers differ)):
>>
>> Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005,
>>    2006, 2007, 2008, 2009
>>    The NetBSD Foundation, Inc.  All rights reserved.
>> Copyright (c) 1982, 1986, 1989, 1991, 1993
>>    The Regents of the University of California.  All rights reserved.
>>
>> NetBSD 5.0.1 (GENERIC) #0: Thu Jul 30 00:08:07 UTC 2009
>>       
>> builds@b7.netbsd.org:/home/builds/ab/netbsd-5-0-1-RELEASE/amd64/200907292356Z-obj/home/builds/ab/netbsd-5-0-1-RELEASE/src/sys/arch/amd64/compile/GENERIC
>>
>> total memory = 4095 MB
>> avail memory = 3954 MB
>> timecounter: Timecounters tick every 10.000 msec
>> timecounter: Timecounter "i8254" frequency 1193182 Hz quality 100
>> SMBIOS rev. 2.5 @ 0x9a400 (45 entries)
>> Micro-Star International GT627       (Ver 1.000)
>> mainbus0 (root)
>> cpu0 at mainbus0 apid 0: Intel 686-class, 2394MHz, id 0x1067a
>> cpu1 at mainbus0 apid 1: Intel 686-class, 2394MHz, id 0x1067a
>> cpu2 at mainbus0 apid 2: Intel 686-class, 2394MHz, id 0x1067a
>> cpu3 at mainbus0 apid 3: Intel 686-class, 2394MHz, id 0x1067a
>> ioapic0 at mainbus0 apid 4: pa 0xfec00000, version 20, 24 pins
>> acpi0 at mainbus0: Intel ACPICA 20080321
>> acpi0: X/RSDT: OemId <MSI_NB,MEGABOOK,20090407>, AslId <MSFT,00000097>
>> ACPI Error (evregion-0427): No handler for Region [EC__]
>> (0xffff800007e20400) [EmbeddedControl] [20080321]
>> ACPI Error (exfldio-0390): Region EmbeddedControl(3) has no handler
>> [20080321]
>> ACPI Error (psparse-0627): Method parse/execution failed
>> [\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xffff800007e23760), AE_NOT_EXIST
>> ACPI Error (uteval-0306): Method execution failed
>> [\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xffff800007e23760), AE_NOT_EXIST
>> acpi0: SCI interrupting at int 9
>> acpi0: fixed-feature power button present
>> timecounter: Timecounter "ACPI-Fast" frequency 3579545 Hz quality 1000
>> ACPI-Fast 24-bit timer
>> ACPI Error (evregion-0427): No handler for Region [EC__]
>> (0xffff800007e20400) [EmbeddedControl] [20080321]
>> ACPI Error (exfldio-0390): Region EmbeddedControl(3) has no handler
>> [20080321]
>> ACPI Error (psparse-0627): Method parse/execution failed
>> [\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xffff800007e23760), AE_NOT_EXIST
>> ACPI Error (uteval-0306): Method execution failed
>> [\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xffff800007e23760), AE_NOT_EXIST
>> WMI1 (pnp0c14) at acpi0 not configured
>> ....
>>
>> where fbsd differed, was somewhere after identifying ad4 (the disk,
>> which is WDC WD5000BEVT-22ZAT0 01.01A1), where it stated:
>>
>> acd0: FAILURE - READ_BIG MEDIUM ERROR asc=0x11 ascq=0x05
>> run_interrupt_driven_hooks: still waiting after 60 seconds for xpt_config
>> run_interrupt_driven_hooks: still waiting after 120 seconds for
>> xpt_config
>>
>> and after that it kept on repeating the last message, only increasing
>> the seconds to wait, until nothing more happened.
>>
>> Does anyone know if this is something that will be fixed soon? I guess
>> it has to do with MSI's ACPI or something like that.
>>
>> Thank you all for your interest.
>>
>> Regards,
>>
>> mamalos.
>>
>>     
> Is the laptop equipped with a firewire port?
> I have a few Gigabyte 8IPE1000-G motherboards at school that exhibit the
> exact same behaviour. (Using 7.X, have not tried with 8.0 yet). Although
> the motherboard does not in fact have a firewire chip soldered on, the
> BIOS presents a firewire device (in Windows it shows in the device
> manager as a non-working, unknown problem device) and I believe this
> confuses the FreeBSD boot sequence. Other people on the lists have also
> suggested disabling device sbp in a custom kernel configuration file (or
> even removing the entire  firewire section if you don't need it).
> One possible first step would be to try disabling firewire in the BIOS
> (Sadly I don't have this option at all in my case) and see if the boot
> continues. If you install successfully you may then try building a
> custom kernel and re-enabling the BIOS option.
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
>
>   

Manoli,

I built current in another machine's folder, addressed my laptop to boot 
from lan having this folder as it's nfsroot, and even then I kept having 
the problem. Then I compiled a kernel without firewire support (the 
whole section was excluded), and as you foresaw, the laptop booted 
eventually. I understand that this is a work around, but I think that 
somebody from the fbsd development team should maybe take a look at it, 
and resolve this issue.

Thank you for your help.

mamalos

-- 
George Mamalakis

IT Officer
Electrical and Computer Engineer (Aristotle Un. of Thessaloniki),
MSc (Imperial College of London)

Department of Electrical and Computer Engineering
Faculty of Engineering
Aristotle University of Thessaloniki

phone number : +30 (2310) 994379

From mamalos at eng.auth.gr  Wed Sep 23 12:02:50 2009
From: mamalos at eng.auth.gr (George Mamalakis)
Date: Wed Sep 23 12:02:57 2009
Subject: Base system's Heimdal with Openldap support?
Message-ID: <4ABA0E63.90209@eng.auth.gr>

Hi all,

I was wondering if there is a way to build fbsd's basesystem heimdal 
with openldap support. I saw that /usr/src/kerberos5/Makefile.inc has a 
section starting with .if defined(WITH_OPENLDAP), so I built the world 
with the flag -DWITH_OPENLDAP. What I managed was to link the kdc binary 
with my system's openldap libraries, but no openldap code was compiled 
in the binary. ( kdc --builtin-hdb didn't return ldap)

How could I achieve this with the base system's heimdal, without 
*hacking* the /usr/src/crypt/heimdal/configure* files? (the port's 
heimdal distribution gets configured with openldap backend)

In case I have sent this question in the wrong list, please somebody 
inform me so.

Thank you all in advance.

-- 
George Mamalakis

IT Officer
Electrical and Computer Engineer (Aristotle Un. of Thessaloniki),
MSc (Imperial College of London)

Department of Electrical and Computer Engineering
Faculty of Engineering
Aristotle University of Thessaloniki

phone number : +30 (2310) 994379

From kama at pvp.se  Wed Sep 23 12:47:45 2009
From: kama at pvp.se (kama)
Date: Wed Sep 23 12:47:58 2009
Subject: FreeBSD 7.2-STABLE boot freeze when calibrating clock.
In-Reply-To: <4AB8E082.8050100@icyb.net.ua>
References: <20090921140345.H37424@ns1.as.pvp.se>
	<20090922103150.V37424@ns1.as.pvp.se>
	<4AB8A95E.3060307@icyb.net.ua> <20090922142526.P37424@ns1.as.pvp.se>
	<4AB8E082.8050100@icyb.net.ua>
Message-ID: <20090922215700.V37424@ns1.as.pvp.se>



> > I see that there are a newer BIOS on the HP homepage for this DL385. I
> > will try to update the BIOS later this week.
> >
> > The servers are not up to be in production until early november, so there
> > are some time to test things.
> >
>
> I specifically meant this message:
> link_elf: symbol AcpiDmDumpMethodInfo undefined
>
> $ glimpse AcpiDmDumpMethodInfo
> /usr/src/sys/contrib/dev/acpica/dmobject.c:  * FUNCTION:    AcpiDmDumpMethodInfo
> /usr/src/sys/contrib/dev/acpica/dmobject.c: AcpiDmDumpMethodInfo (
> /usr/src/sys/contrib/dev/acpica/dsmethod.c:         AcpiDmDumpMethodInfo (Status,
> WalkState, WalkState->Op);
> /usr/src/sys/contrib/dev/acpica/acdisasm.h: AcpiDmDumpMethodInfo (
>
> So this function is both defined and used only inside acpi code (vendor part of it).
> The error you get does not seem to be a run-time condition.
> It seems to be a system build/install issue (and it looks like the issue is unique
> to you).
> I am almost out of guesses, maybe you have stale acpi.ko module in some modules
> directory.
>
> Hmm, one last idea - maybe you have something like "build modules with world"
> option and also perhaps ACPI_DEBUG is defined somewhere?

No, this is a clean installed system. Nothing in make.conf or src.conf.
And loader.conf is empty.

> It could be that something gets out of sync with respect to ACPI_DISASSEMBLER macro.
> Output of the following command may be useful:
> $ nm -A /boot/kernel/* | fgrep AcpiDmDumpMethodInfo

g24# nm -A /boot/kernel/* | fgrep AcpiDmDumpMethodInfo
/boot/kernel/acpi.ko:         U AcpiDmDumpMethodInfo
/boot/kernel/acpi.ko.symbols:         U AcpiDmDumpMethodInfo
nm: /boot/kernel/linker.hints: File format not recognized
g24#

> Could you please try investigating this? Maybe even include acpi into kernel?

Just adding 'device acpi' into the generic kernel made it boot
successfully. (without KDB DDB ACPI_DEBUG)

Here are the outputfiles suggested from the webpage:

http://fbsd-err.pvp.se/acpidump_acpi_compiled.asl
http://fbsd-err.pvp.se/dmesg_acpi_compiled.txt
http://fbsd-err.pvp.se/sysctl_acpi_compiled.txt

Please let me know what else to test or if you want more data...

Later today I will head over to the datacenter to swap a failed disk and
will then also update the BIOS on these servers. I'll post a message how
that goes later tonight.

/Bjorn
From avg at icyb.net.ua  Wed Sep 23 13:05:49 2009
From: avg at icyb.net.ua (Andriy Gapon)
Date: Wed Sep 23 13:05:56 2009
Subject: FreeBSD 7.2-STABLE boot freeze when calibrating clock.
In-Reply-To: <20090922215700.V37424@ns1.as.pvp.se>
References: <20090921140345.H37424@ns1.as.pvp.se>	<20090922103150.V37424@ns1.as.pvp.se>	<4AB8A95E.3060307@icyb.net.ua>
	<20090922142526.P37424@ns1.as.pvp.se>	<4AB8E082.8050100@icyb.net.ua>
	<20090922215700.V37424@ns1.as.pvp.se>
Message-ID: <4ABA1D1F.3080704@icyb.net.ua>

on 23/09/2009 15:47 kama said the following:
> g24# nm -A /boot/kernel/* | fgrep AcpiDmDumpMethodInfo
> /boot/kernel/acpi.ko:         U AcpiDmDumpMethodInfo
> /boot/kernel/acpi.ko.symbols:         U AcpiDmDumpMethodInfo

So this is what I was talking about - this symbol should not be undefined after
normal build. This symbol should not be present and referenced at all unless
ACPI_DISASSEMBLER is defined.
This is clearly a build problem of some sort.

> Just adding 'device acpi' into the generic kernel made it boot
> successfully. (without KDB DDB ACPI_DEBUG)

I am glad that this worked :)

> Here are the outputfiles suggested from the webpage:
> 
> http://fbsd-err.pvp.se/acpidump_acpi_compiled.asl
> http://fbsd-err.pvp.se/dmesg_acpi_compiled.txt
> http://fbsd-err.pvp.se/sysctl_acpi_compiled.txt

This doesn't make it nay clearer why you get that build problem.

-- 
Andriy Gapon
From doconnor at gsoft.com.au  Wed Sep 23 13:52:55 2009
From: doconnor at gsoft.com.au (Daniel O'Connor)
Date: Wed Sep 23 13:53:02 2009
Subject: 8.0-RC1 panic attaching ppc
Message-ID: <200909232322.51060.doconnor@gsoft.com.au>

If I enable the parallel port on this Gigabyte MA7785GM-US2H I get a 
trap 12 when booting up.

I forgot to take a picture of it at the time but I should be able to 
reproduce it tomorrow.

Has anyone seen anything before? (a quick google showed nothing). I did 
not see it on 7.2(ish) on the same hardware.

-- 
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
  -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090923/dc7391fe/attachment.pgp
From attilio at freebsd.org  Wed Sep 23 13:54:17 2009
From: attilio at freebsd.org (Attilio Rao)
Date: Wed Sep 23 13:54:24 2009
Subject: 8.0-RC1 panic attaching ppc
In-Reply-To: <200909232322.51060.doconnor@gsoft.com.au>
References: <200909232322.51060.doconnor@gsoft.com.au>
Message-ID: <3bbf2fe10909230654g2030b18aq8a93e26a7789b06f@mail.gmail.com>

2009/9/23 Daniel O'Connor <doconnor@gsoft.com.au>:
> If I enable the parallel port on this Gigabyte MA7785GM-US2H I get a
> trap 12 when booting up.
>
> I forgot to take a picture of it at the time but I should be able to
> reproduce it tomorrow.
>
> Has anyone seen anything before? (a quick google showed nothing). I did
> not see it on 7.2(ish) on the same hardware.

Are you able to enable KDB in your kernel config and return a backtrace here?

Attilio


-- 
Peace can only be achieved by understanding - A. Einstein
From faber at isi.edu  Wed Sep 23 15:19:26 2009
From: faber at isi.edu (Ted Faber)
Date: Wed Sep 23 15:19:39 2009
Subject: PATA disks/DVD not detected on ATI IXP 700 - cannot boot (dmesg
	attached)
In-Reply-To: <4AB9A3CE.4090509@yandex.ru>
References: <20090916161327.GB87631@zod.isi.edu>
	<20090919035214.GA12889@zod.isi.edu>
	<200909211239.25614.jkim@FreeBSD.org> <4AB9A3CE.4090509@yandex.ru>
Message-ID: <20090923151921.GA27328@zod.isi.edu>

On Wed, Sep 23, 2009 at 08:27:58AM +0400, Andrey V. Elsukov wrote:
> Jung-uk Kim wrote:
> >This is a known problem and should be fixed in 8.0.  Sorry, I haven't 
> >had time to back-port the code.  Proabably it's good time to consider 
> >testing 8.0-RC1. ;-)
> 
> Hi,
> 
> Can you look at this?
> http://butcher.heavennet.ru/patches/kernel/ata/ata-ati-r191568-backport-to-RELENG_7.diff
> 
> So, it isn't tested (sorry, i don't have any test machines with RELENG_7, 
> only HEAD :)
> Ted and Dennis can you try it?

I jumped forward to RELENG_8 to get the box up, and dropping back to
RELENG_7 is a little bit painful, bit I'll try to give it a shot later
this week.

-- 
Ted Faber
http://www.isi.edu/~faber           PGP: http://www.isi.edu/~faber/pubkeys.asc
Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090923/1ed27957/attachment.pgp
From kama at pvp.se  Wed Sep 23 15:19:26 2009
From: kama at pvp.se (kama)
Date: Wed Sep 23 15:19:40 2009
Subject: FreeBSD 7.2-STABLE boot freeze when calibrating clock.
In-Reply-To: <4ABA1D1F.3080704@icyb.net.ua>
References: <20090921140345.H37424@ns1.as.pvp.se>
	<20090922103150.V37424@ns1.as.pvp.se>
	<4AB8A95E.3060307@icyb.net.ua> <20090922142526.P37424@ns1.as.pvp.se>
	<4AB8E082.8050100@icyb.net.ua> <20090922215700.V37424@ns1.as.pvp.se>
	<4ABA1D1F.3080704@icyb.net.ua>
Message-ID: <20090923171004.Q37424@ns1.as.pvp.se>


On Wed, 23 Sep 2009, Andriy Gapon wrote:

> on 23/09/2009 15:47 kama said the following:
> > g24# nm -A /boot/kernel/* | fgrep AcpiDmDumpMethodInfo
> > /boot/kernel/acpi.ko:         U AcpiDmDumpMethodInfo
> > /boot/kernel/acpi.ko.symbols:         U AcpiDmDumpMethodInfo
>
> So this is what I was talking about - this symbol should not be undefined after
> normal build. This symbol should not be present and referenced at all unless
> ACPI_DISASSEMBLER is defined.
> This is clearly a build problem of some sort.

Even though they dont exists on a acpi_debug kernel. It does not really
matter since the real problem is that freebsd freezes on a normal generic
config.

> > Just adding 'device acpi' into the generic kernel made it boot
> > successfully. (without KDB DDB ACPI_DEBUG)
>
> I am glad that this worked :)

Me too. As a work around. But I would prefer a GENERIC kernel to boot.

> > Here are the outputfiles suggested from the webpage:
> >
> > http://fbsd-err.pvp.se/acpidump_acpi_compiled.asl
> > http://fbsd-err.pvp.se/dmesg_acpi_compiled.txt
> > http://fbsd-err.pvp.se/sysctl_acpi_compiled.txt
>
> This doesn't make it nay clearer why you get that build problem.

I dunno. I dont have any insight into kernel programming. Hence trying to
get information how to help the people to fix the actual problem. That the
server freezes at boot. Im kind of lucky to have HP ILO on my side, to
test things. =)

But I will upgrade the BIOS. If that does not work, I'll try a clean
7.2-REL install.

/Bjorn

PS.
Another unrelated issue. I get a bounce everytime I send a mail to you.

Final-Recipient: rfc822; avg@icyb.net.ua
Action: failed
Status: 5.0.0
Diagnostic-Code: X-Postfix; host mt.icyb.net.ua[212.40.38.132] said: 550
    (LHP01) Not accepted (in reply to RCPT TO command)
DS.
From faber at isi.edu  Wed Sep 23 15:20:57 2009
From: faber at isi.edu (Ted Faber)
Date: Wed Sep 23 15:21:04 2009
Subject: PATA disks/DVD not detected on ATI IXP 700 - cannot boot (dmesg
	attached)
In-Reply-To: <20090922153139.GC38036@zod.isi.edu>
References: <20090916161327.GB87631@zod.isi.edu>
	<20090919035214.GA12889@zod.isi.edu>
	<200909211239.25614.jkim@FreeBSD.org>
	<20090921170516.GA52169@zod.isi.edu> <4AB8ACF2.3080104@icyb.net.ua>
	<20090922153139.GC38036@zod.isi.edu>
Message-ID: <20090923152056.GB27328@zod.isi.edu>

On Tue, Sep 22, 2009 at 08:31:39AM -0700, Ted Faber wrote:
> On Tue, Sep 22, 2009 at 01:54:42PM +0300, Andriy Gapon wrote:
> > > Any ideas?  I'll be able to run more diagnostics under 8.0 tonight.
> > 
> > This could be another of GEOM_PART_BSD vs GEOM_BSD issues.
> > I think this topic has been discussed several times recently on -current.
> 
> This looks like the problem.  Thanks for the pointer.  I remembered
> something like this, but couldn't put my finger on it.  Just to make
> life easier for the next guy the thread with this message (which
> includes the dd hex that fixes it) seems to cover it.
> 
> http://docs.freebsd.org/cgi/getmsg.cgi?fetch=774931+0+archive/2009/freebsd-current/20090118.freebsd-current
> 
> Which looks like the exact right thing for me.  I'll follow up when I
> know for sure, but thanks much for the pointer!

Clearing the old bsdlabel as described in the mail message above fixed
my problem seeing the partition table.  Now I have to fix the apparently
wonky memory,,, >sigh<


-- 
Ted Faber
http://www.isi.edu/~faber           PGP: http://www.isi.edu/~faber/pubkeys.asc
Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090923/1e316b74/attachment.pgp
From alandaluz at gmail.com  Wed Sep 23 15:50:47 2009
From: alandaluz at gmail.com (Cassidy Larson)
Date: Wed Sep 23 15:50:53 2009
Subject: Random Network Drops on Realtek Interfaces (re)
In-Reply-To: <20090923000405.GC1520@michelle.cdnetworks.com>
References: <d88efacd0909212225h3a301386p1446bc65a8b43cc9@mail.gmail.com>
	<20090922200053.GA1520@michelle.cdnetworks.com>
	<d88efacd0909221633w64b86766h6fc2adf7e8187d0f@mail.gmail.com>
	<20090923000405.GC1520@michelle.cdnetworks.com>
Message-ID: <d88efacd0909230850g2ed8b742r1b4cb624663ab754@mail.gmail.com>

> It looks plain RTL8168C PCIe controller. Is there any odd messages
> reported by re(4) such as watchdog timeouts?
> If you disable MSI feature does it make any difference?(Add
> hw.re.msi_disable="1" to /boot/loader.conf to disable MSI.)

Disabling MSI didnt solve the problem.

Any other suggestions?

Thanks,

-c
From peter at simons-rock.edu  Wed Sep 23 15:54:06 2009
From: peter at simons-rock.edu (Peter C. Lai)
Date: Wed Sep 23 15:54:19 2009
Subject: Base system's Heimdal with Openldap support?
In-Reply-To: <4ABA0E63.90209@eng.auth.gr>
References: <4ABA0E63.90209@eng.auth.gr>
Message-ID: <20090923155402.GG81123@cesium.hyperfine.info>

It's probably a bad idea to link a binary in base with a library from ports...

security/heimdal has a WITH_LDAP make knob which should do what you want?

I'm not sure if it has OVERRIDE_BASE, though.

On 2009-09-23 03:02:43PM +0300, George Mamalakis wrote:
> Hi all,
> 
> I was wondering if there is a way to build fbsd's basesystem heimdal with 
> openldap support. I saw that /usr/src/kerberos5/Makefile.inc has a section 
> starting with .if defined(WITH_OPENLDAP), so I built the world with the 
> flag -DWITH_OPENLDAP. What I managed was to link the kdc binary with my 
> system's openldap libraries, but no openldap code was compiled in the 
> binary. ( kdc --builtin-hdb didn't return ldap)
> 
> How could I achieve this with the base system's heimdal, without *hacking* 
> the /usr/src/crypt/heimdal/configure* files? (the port's heimdal 
> distribution gets configured with openldap backend)
> 
> In case I have sent this question in the wrong list, please somebody inform 
> me so.
> 
> Thank you all in advance.
> 
> -- 
> George Mamalakis
> 
> IT Officer
> Electrical and Computer Engineer (Aristotle Un. of Thessaloniki),
> MSc (Imperial College of London)
> 
> Department of Electrical and Computer Engineering
> Faculty of Engineering
> Aristotle University of Thessaloniki
> 
> phone number : +30 (2310) 994379
> 
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"

-- 
===========================================================
Peter C. Lai                 | Bard College at Simon's Rock
Systems Administrator        | 84 Alford Rd.
Information Technology Svcs. | Gt. Barrington, MA 01230 USA
peter AT simons-rock.edu     | (413) 528-7428
===========================================================

From avg at freebsd.org  Wed Sep 23 15:57:54 2009
From: avg at freebsd.org (Andriy Gapon)
Date: Wed Sep 23 15:58:06 2009
Subject: FreeBSD 7.2-STABLE boot freeze when calibrating clock.
In-Reply-To: <20090923171004.Q37424@ns1.as.pvp.se>
References: <20090921140345.H37424@ns1.as.pvp.se>	<20090922103150.V37424@ns1.as.pvp.se>	<4AB8A95E.3060307@icyb.net.ua>
	<20090922142526.P37424@ns1.as.pvp.se>	<4AB8E082.8050100@icyb.net.ua>
	<20090922215700.V37424@ns1.as.pvp.se>	<4ABA1D1F.3080704@icyb.net.ua>
	<20090923171004.Q37424@ns1.as.pvp.se>
Message-ID: <4ABA457E.3060800@freebsd.org>

on 23/09/2009 18:19 kama said the following:
> On Wed, 23 Sep 2009, Andriy Gapon wrote:
> 
>> on 23/09/2009 15:47 kama said the following:
>>> g24# nm -A /boot/kernel/* | fgrep AcpiDmDumpMethodInfo
>>> /boot/kernel/acpi.ko:         U AcpiDmDumpMethodInfo
>>> /boot/kernel/acpi.ko.symbols:         U AcpiDmDumpMethodInfo
>> So this is what I was talking about - this symbol should not be undefined after
>> normal build. This symbol should not be present and referenced at all unless
>> ACPI_DISASSEMBLER is defined.
>> This is clearly a build problem of some sort.
> 
> Even though they dont exists on a acpi_debug kernel. It does not really
> matter since the real problem is that freebsd freezes on a normal generic
> config.

What is acpi_debug kernel?
And FreeBSD does not freeze on "a normal generic config".
It freezes because of a mysterious build bug that only you seem to have (so far).

>>> Just adding 'device acpi' into the generic kernel made it boot
>>> successfully. (without KDB DDB ACPI_DEBUG)
>> I am glad that this worked :)
> 
> Me too. As a work around. But I would prefer a GENERIC kernel to boot.

True GENERIC kernel is the one that you get from FreeBSD.Org :-)
The one that you built yourself even using GENERIC config can always get tainted
by unspecified problems with your build environment.
Can you reproduce this problem if you build world, install it somewhere, chroot to
it and then build a GENERIC kernel? (with no tweaking between the steps)

>From practical point of view, I don't see why moving acpi from module to kernel
could be an issue.

>>> Here are the outputfiles suggested from the webpage:
>>>
>>> http://fbsd-err.pvp.se/acpidump_acpi_compiled.asl
>>> http://fbsd-err.pvp.se/dmesg_acpi_compiled.txt
>>> http://fbsd-err.pvp.se/sysctl_acpi_compiled.txt
>> This doesn't make it nay clearer why you get that build problem.
> 
> I dunno. I dont have any insight into kernel programming. Hence trying to
> get information how to help the people to fix the actual problem. That the
> server freezes at boot. Im kind of lucky to have HP ILO on my side, to
> test things. =)
> 
> But I will upgrade the BIOS. If that does not work, I'll try a clean
> 7.2-REL install.

BIOS upgrade may improve some things for you, but I'd be very surprised if it
fixes the build problem in question.

> PS.
> Another unrelated issue. I get a bounce everytime I send a mail to you.
> 
> Final-Recipient: rfc822; avg@icyb.net.ua
> Action: failed
> Status: 5.0.0
> Diagnostic-Code: X-Postfix; host mt.icyb.net.ua[212.40.38.132] said: 550
>     (LHP01) Not accepted (in reply to RCPT TO command)

I'll investigate this.
Meanwhile I will use my freebsd.org address in From.

-- 
Andriy Gapon
From jhellenthal at gmail.com  Wed Sep 23 16:03:42 2009
From: jhellenthal at gmail.com (J. Hellenthal)
Date: Wed Sep 23 16:04:10 2009
Subject: Signing Request
Message-ID: <alpine.BSF.2.00.0909231132000.52005@qvzrafvba.5c.ybpny>


If you do not need to pgp/gpg sign email message to the lists please don't. I 
know I probably don't have your pgp public key and a lot more users probably do 
not either. Please use your best judgment.

Thank you and best regards.

-- 

  J. Hellenthal
  jhellenthal@gmail.com
From rnoland at FreeBSD.org  Wed Sep 23 16:09:40 2009
From: rnoland at FreeBSD.org (Robert Noland)
Date: Wed Sep 23 16:09:53 2009
Subject: Signing Request
In-Reply-To: <alpine.BSF.2.00.0909231132000.52005@qvzrafvba.5c.ybpny>
References: <alpine.BSF.2.00.0909231132000.52005@qvzrafvba.5c.ybpny>
Message-ID: <1253722172.2057.1017.camel@balrog.2hip.net>

On Wed, 2009-09-23 at 11:40 -0400, J. Hellenthal wrote:
> If you do not need to pgp/gpg sign email message to the lists please don't. I 
> know I probably don't have your pgp public key and a lot more users probably do 
> not either. Please use your best judgment.

http://www.freebsd.org/doc/pgpkeyring.txt

Frankly, I always sign messages, except that evolution / gpg support is
currently a bit broken...

robert.

> Thank you and best regards.

-- 
Robert Noland <rnoland@FreeBSD.org>
FreeBSD

From dnelson at allantgroup.com  Wed Sep 23 16:35:41 2009
From: dnelson at allantgroup.com (Dan Nelson)
Date: Wed Sep 23 16:35:48 2009
Subject: Signing Request
In-Reply-To: <1253722172.2057.1017.camel@balrog.2hip.net>
References: <alpine.BSF.2.00.0909231132000.52005@qvzrafvba.5c.ybpny>
	<1253722172.2057.1017.camel@balrog.2hip.net>
Message-ID: <20090923162937.GH29215@dan.emsphone.com>

In the last episode (Sep 23), Robert Noland said:
> On Wed, 2009-09-23 at 11:40 -0400, J. Hellenthal wrote:
> > If you do not need to pgp/gpg sign email message to the lists please
> > don't.  I know I probably don't have your pgp public key and a lot more
> > users probably do not either.  Please use your best judgment.
> 
> http://www.freebsd.org/doc/pgpkeyring.txt
> 
> Frankly, I always sign messages, except that evolution / gpg support is
> currently a bit broken...

There are also the public keyservers (subkeys.pgp.net, pgp.surfnet.nl,
pgp.mit.edu, etc), which I have found to hold most of the keys for people
that sign messages on these lists.

-- 
	Dan Nelson
	dnelson@allantgroup.com
From wmoran at potentialtech.com  Wed Sep 23 16:49:55 2009
From: wmoran at potentialtech.com (Bill Moran)
Date: Wed Sep 23 16:50:02 2009
Subject: Signing Request
In-Reply-To: <alpine.BSF.2.00.0909231132000.52005@qvzrafvba.5c.ybpny>
References: <alpine.BSF.2.00.0909231132000.52005@qvzrafvba.5c.ybpny>
Message-ID: <20090923123315.c65a0a2a.wmoran@potentialtech.com>

In response to "J. Hellenthal" <jhellenthal@gmail.com>:
> 
> If you do not need to pgp/gpg sign email message to the lists please don't.

What is the purpose of your message?  The above statement is self-cancelling.
If I go to the trouble to establish a pgp/gpg key, I will sign every single
message that I send out.  The purpose of this is to differentiate actual
messages from me from messages that may impersonate me.

> I 
> know I probably don't have your pgp public key and a lot more users probably do 
> not either. Please use your best judgment.

While you're free to voice your opinion, I don't understand your purpose
in spamming three mailing lists with this demand.  What problem are you
trying to solve?

-- 
Bill Moran
http://www.potentialtech.com
http://people.collaborativefusion.com/~wmoran/
From stephen at missouri.edu  Wed Sep 23 16:57:28 2009
From: stephen at missouri.edu (Stephen Montgomery-Smith)
Date: Wed Sep 23 16:57:39 2009
Subject: Signing Request
In-Reply-To: <1253722172.2057.1017.camel@balrog.2hip.net>
References: <alpine.BSF.2.00.0909231132000.52005@qvzrafvba.5c.ybpny>
	<1253722172.2057.1017.camel@balrog.2hip.net>
Message-ID: <alpine.BSF.2.00.0909231121150.26862@cauchy.math.missouri.edu>



On Wed, 23 Sep 2009, Robert Noland wrote:

> On Wed, 2009-09-23 at 11:40 -0400, J. Hellenthal wrote:
>> If you do not need to pgp/gpg sign email message to the lists please don't. I
>> know I probably don't have your pgp public key and a lot more users probably do
>> not either. Please use your best judgment.
>
> http://www.freebsd.org/doc/pgpkeyring.txt
>
> Frankly, I always sign messages, except that evolution / gpg support is
> currently a bit broken...
>
> robert.
>
>> Thank you and best regards.

I don't use PGP, but I don't see how it can affect me if someone else 
does.  I can still read the emails, so why should it bother me?

Stephen

From peter at simons-rock.edu  Wed Sep 23 17:22:23 2009
From: peter at simons-rock.edu (Peter C. Lai)
Date: Wed Sep 23 17:22:30 2009
Subject: Signing Request
In-Reply-To: <14572_1253722226_4ABA4872_14572_143_1_1253722172.2057.1017.camel@balrog.2hip.net>
References: <alpine.BSF.2.00.0909231132000.52005@qvzrafvba.5c.ybpny>
	<14572_1253722226_4ABA4872_14572_143_1_1253722172.2057.1017.camel@balrog.2hip.net>
Message-ID: <20090923172219.GI81123@cesium.hyperfine.info>

At the risk of sounding offtopic and political, as participants in IT and
the open source community at large, aren't we supposed to hold ourselves to
the "higher standard" and promote the use of encrypted email? If we're 
refusing to read signed messages because we have client-side problems with 
signatures (and are too lazy to fix them), how do we expect (or wish for) 
the rest of the world to do so?

On 2009-09-23 11:09:32AM -0500, Robert Noland wrote:
> On Wed, 2009-09-23 at 11:40 -0400, J. Hellenthal wrote:
> > If you do not need to pgp/gpg sign email message to the lists please don't. I 
> > know I probably don't have your pgp public key and a lot more users probably do 
> > not either. Please use your best judgment.
> 
> http://www.freebsd.org/doc/pgpkeyring.txt
> 
> Frankly, I always sign messages, except that evolution / gpg support is
> currently a bit broken...
> 
> robert.
> 
> > Thank you and best regards.
> 
> -- 
> Robert Noland <rnoland@FreeBSD.org>
> FreeBSD
> 
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"

-- 
===========================================================
Peter C. Lai                 | Bard College at Simon's Rock
Systems Administrator        | 84 Alford Rd.
Information Technology Svcs. | Gt. Barrington, MA 01230 USA
peter AT simons-rock.edu     | (413) 528-7428
===========================================================

From pyunyh at gmail.com  Wed Sep 23 17:35:05 2009
From: pyunyh at gmail.com (Pyun YongHyeon)
Date: Wed Sep 23 17:35:12 2009
Subject: Random Network Drops on Realtek Interfaces (re)
In-Reply-To: <d88efacd0909230850g2ed8b742r1b4cb624663ab754@mail.gmail.com>
References: <d88efacd0909212225h3a301386p1446bc65a8b43cc9@mail.gmail.com>
	<20090922200053.GA1520@michelle.cdnetworks.com>
	<d88efacd0909221633w64b86766h6fc2adf7e8187d0f@mail.gmail.com>
	<20090923000405.GC1520@michelle.cdnetworks.com>
	<d88efacd0909230850g2ed8b742r1b4cb624663ab754@mail.gmail.com>
Message-ID: <20090923173416.GB1099@michelle.cdnetworks.com>

On Wed, Sep 23, 2009 at 09:50:45AM -0600, Cassidy Larson wrote:
> > It looks plain RTL8168C PCIe controller. Is there any odd messages
> > reported by re(4) such as watchdog timeouts?
> > If you disable MSI feature does it make any difference?(Add
> > hw.re.msi_disable="1" to /boot/loader.conf to disable MSI.)
> 
> Disabling MSI didnt solve the problem.
> 
> Any other suggestions?
> 

Hmm, not yet. When you lost network connection on re can you still
see incoming traffics from other hosts with tcpdump? Also would you
check available mbuf with "netstat -m" when you think re is not
respond to any request?

> Thanks,
> 
> -c
From jhellenthal at gmail.com  Wed Sep 23 17:47:15 2009
From: jhellenthal at gmail.com (J. Hellenthal)
Date: Wed Sep 23 17:47:29 2009
Subject: Signing Request
In-Reply-To: <alpine.BSF.2.00.0909231132000.52005@qvzrafvba.5c.ybpny>
References: <alpine.BSF.2.00.0909231132000.52005@qvzrafvba.5c.ybpny>
Message-ID: <1253725826.2031.58.camel@balrog.2hip.net>

On Wed, 2009-09-23 at 11:40 -0400, J. Hellenthal wrote:
> If you do not need to pgp/gpg sign email message to the lists please don't. I 
> know I probably don't have your pgp public key and a lot more users probably do 
> not either. Please use your best judgment.
> 
> Thank you and best regards.

BTW, it also helps to mitigate messages like this one...

robert.

From jhellenthal at gmail.com  Wed Sep 23 22:11:04 2009
From: jhellenthal at gmail.com (J. Hellenthal)
Date: Wed Sep 23 22:11:22 2009
Subject: Signing Request
In-Reply-To: <alpine.BSF.2.00.0909231132000.52005@qvzrafvba.5c.ybpny>
References: <alpine.BSF.2.00.0909231132000.52005@qvzrafvba.5c.ybpny>
Message-ID: <alpine.BSF.2.00.0909231635310.11763@qvzrafvba.5c.ybpny>

On Wed, 23 Sep 2009 11:40 -0000, jhellenthal wrote:

>
> If you do not need to pgp/gpg sign email message to the lists please don't. I 
> know I probably don't have your pgp public key and a lot more users probably 
> do not either. Please use your best judgment.
>
> Thank you and best regards.
>
>

Alright If I must. Let me explain this email for the uncommon circumstances and 
big heads on the subject line.

This was just a request not an authoritative (must do) and certainly not spam as 
some have had a concern over.

If I do not have your public key in my keyring then I do not want it, do not 
need it and have no use for it at this time. This keeps my keyring small and 
manageable.

I do not feel the need to explain my process or setup on this matter as this 
email was intended as just a request as I don't see the need to sign a message to 
a mailing list when the information that is contained in more than half of the 
incoming email is not important enough to be signed.

For an example of the emails I am referring to (ports@):
 	"I am having problems with such/and/such/port/"

 	Why should it be signed ? I understand, shit happens....
 	but I don't need to verify that it happened to Random Joe.

Now on the other hand I firmly believe that a patch that is submitted by a 
maintainer or someone @FreeBSD.org should be signed. I am not referring to these 
emails at all in the last message and I apologize if that was unrecognizable to 
you.

There is a purpose for signing messages that contain information that someone 
needs to verify is actually from a trusted source but not all information that 
is transmitted needs to be verified. And that is all I was referring to when 
saying use your best judgment.

I will not be posting back on this subject as I never intended for this to be a 
off topic matter (just a request).

Best regards

-- 

J. Hellenthal (0x87337C16)
gmail.com!jhellenthal

:wq
From alandaluz at gmail.com  Thu Sep 24 02:43:41 2009
From: alandaluz at gmail.com (Cassidy Larson)
Date: Thu Sep 24 02:43:47 2009
Subject: Random Network Drops on Realtek Interfaces (re)
In-Reply-To: <20090923173416.GB1099@michelle.cdnetworks.com>
References: <d88efacd0909212225h3a301386p1446bc65a8b43cc9@mail.gmail.com>
	<20090922200053.GA1520@michelle.cdnetworks.com>
	<d88efacd0909221633w64b86766h6fc2adf7e8187d0f@mail.gmail.com>
	<20090923000405.GC1520@michelle.cdnetworks.com>
	<d88efacd0909230850g2ed8b742r1b4cb624663ab754@mail.gmail.com>
	<20090923173416.GB1099@michelle.cdnetworks.com>
Message-ID: <d88efacd0909231943m3ecbdb8anaef6ee6368cd70ee@mail.gmail.com>

> Hmm, not yet. When you lost network connection on re can you still
> see incoming traffics from other hosts with tcpdump? Also would you
> check available mbuf with "netstat -m" when you think re is not
> respond to any request?

No incoming traffic found with tcpdump, just outgoing arp requests
from the local machine.

netstat -m output:
258/777/1035 mbufs in use (current/cache/total)
256/396/652/25600 mbuf clusters in use (current/cache/total/max)
256/384 mbuf+clusters out of packet secondary zone in use (current/cache)
0/35/35/12800 4k (page size) jumbo clusters in use (current/cache/total/max)
0/0/0/6400 9k jumbo clusters in use (current/cache/total/max)
0/0/0/3200 16k jumbo clusters in use (current/cache/total/max)
576K/1126K/1702K bytes allocated to network (current/cache/total)
0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters)
0/0/0 requests for jumbo clusters denied (4k/9k/16k)
0/0/0 sfbufs in use (current/peak/max)
0 requests for sfbufs denied
0 requests for sfbufs delayed
0 requests for I/O initiated by sendfile
0 calls to protocol drain routines


-c
From doconnor at gsoft.com.au  Thu Sep 24 05:25:39 2009
From: doconnor at gsoft.com.au (Daniel O'Connor)
Date: Thu Sep 24 05:25:47 2009
Subject: 8.0-RC1 panic attaching ppc
In-Reply-To: <3bbf2fe10909230654g2030b18aq8a93e26a7789b06f@mail.gmail.com>
References: <200909232322.51060.doconnor@gsoft.com.au>
	<3bbf2fe10909230654g2030b18aq8a93e26a7789b06f@mail.gmail.com>
Message-ID: <200909241455.32216.doconnor@gsoft.com.au>

On Wed, 23 Sep 2009, Attilio Rao wrote:
> 2009/9/23 Daniel O'Connor <doconnor@gsoft.com.au>:
> > If I enable the parallel port on this Gigabyte MA7785GM-US2H I get
> > a trap 12 when booting up.
> >
> > I forgot to take a picture of it at the time but I should be able
> > to reproduce it tomorrow.
> >
> > Has anyone seen anything before? (a quick google showed nothing). I
> > did not see it on 7.2(ish) on the same hardware.
>
> Are you able to enable KDB in your kernel config and return a
> backtrace here?

Yes, here it is..

pmap_extract() at pmap_extract+0x13a
isa_dmarangecheck() at isa_dmarangecheck+0x7a
isa_dma_init() at isa_dma_init+0xda
ppc_isa_attach() at ppc_sa_attach+0x40
device_attach() at device_attach+0x69
bus_generic_attach() at bus_generic_attach+0x1a
acpi_attach() at acpi_attach+0x9f8

(there's more but I imagine the above is probably sufficient).

I took pictures, they are here
http://www.gsoft.com.au/~doconnor/SNC00111.jpg
http://www.gsoft.com.au/~doconnor/SNC00112.jpg

If I put the parallel port in EPP mode then it works, I presume that's 
because it doesn't require a DMA channel whereas ECP doesn't. I haven't 
enumerated the possibilities though :)

-- 
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
  -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090924/8d252ea8/attachment.pgp
From steve at ibctech.ca  Thu Sep 24 12:31:09 2009
From: steve at ibctech.ca (Steve Bertrand)
Date: Thu Sep 24 12:31:16 2009
Subject: Signing Request
In-Reply-To: <1253725826.2031.58.camel@balrog.2hip.net>
References: <alpine.BSF.2.00.0909231132000.52005@qvzrafvba.5c.ybpny>
	<1253725826.2031.58.camel@balrog.2hip.net>
Message-ID: <4ABB669F.6010409@ibctech.ca>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

J. Hellenthal wrote:
> On Wed, 2009-09-23 at 11:40 -0400, J. Hellenthal wrote:
>> If you do not need to pgp/gpg sign email message to the lists please don't. I 
>> know I probably don't have your pgp public key and a lot more users probably do 
>> not either. Please use your best judgment.
>>
>> Thank you and best regards.
> 
> BTW, it also helps to mitigate messages like this one...
> 
> robert.

Well, I got my laugh for the day :)

Steve
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)

iD8DBQFKu2af9T7Z4dPS9TkRAgV4AJ9DRQ74Wf39MXxee9GzL+do4CFGcwCeORV6
a4MYLLuEbVQXzPdpN65oKbA=
=0avG
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3233 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090924/d2ccd6e0/smime.bin
From kama at pvp.se  Thu Sep 24 12:35:37 2009
From: kama at pvp.se (kama)
Date: Thu Sep 24 12:35:45 2009
Subject: FreeBSD 7.2-STABLE boot freeze (was: when calibrating clock.)
In-Reply-To: <4ABA457E.3060800@freebsd.org>
References: <20090921140345.H37424@ns1.as.pvp.se>
	<20090922103150.V37424@ns1.as.pvp.se>
	<4AB8A95E.3060307@icyb.net.ua> <20090922142526.P37424@ns1.as.pvp.se>
	<4AB8E082.8050100@icyb.net.ua> <20090922215700.V37424@ns1.as.pvp.se>
	<4ABA1D1F.3080704@icyb.net.ua> <20090923171004.Q37424@ns1.as.pvp.se>
	<4ABA457E.3060800@freebsd.org>
Message-ID: <20090924141927.Y37424@ns1.as.pvp.se>



On Wed, 23 Sep 2009, Andriy Gapon wrote:

> on 23/09/2009 18:19 kama said the following:
> > On Wed, 23 Sep 2009, Andriy Gapon wrote:
> >
> >> on 23/09/2009 15:47 kama said the following:
> >>> g24# nm -A /boot/kernel/* | fgrep AcpiDmDumpMethodInfo
> >>> /boot/kernel/acpi.ko:         U AcpiDmDumpMethodInfo
> >>> /boot/kernel/acpi.ko.symbols:         U AcpiDmDumpMethodInfo
> >> So this is what I was talking about - this symbol should not be undefined after
> >> normal build. This symbol should not be present and referenced at all unless
> >> ACPI_DISASSEMBLER is defined.
> >> This is clearly a build problem of some sort.
> >
> > Even though they dont exists on a acpi_debug kernel. It does not really
> > matter since the real problem is that freebsd freezes on a normal generic
> > config.
>
> What is acpi_debug kernel?

The one with option ACPI_DEBUG in it.

> And FreeBSD does not freeze on "a normal generic config".
> It freezes because of a mysterious build bug that only you seem to have (so far).
>
> >>> Just adding 'device acpi' into the generic kernel made it boot
> >>> successfully. (without KDB DDB ACPI_DEBUG)
> >> I am glad that this worked :)
> >
> > Me too. As a work around. But I would prefer a GENERIC kernel to boot.
>
> True GENERIC kernel is the one that you get from FreeBSD.Org :-)
> The one that you built yourself even using GENERIC config can always get tainted
> by unspecified problems with your build environment.
> Can you reproduce this problem if you build world, install it somewhere, chroot to
> it and then build a GENERIC kernel? (with no tweaking between the steps)

Actually I spoke to fast. After an reboot it hanged again.

> >From practical point of view, I don't see why moving acpi from module to kernel
> could be an issue.
>
> >>> Here are the outputfiles suggested from the webpage:
> >>>
> >>> http://fbsd-err.pvp.se/acpidump_acpi_compiled.asl
> >>> http://fbsd-err.pvp.se/dmesg_acpi_compiled.txt
> >>> http://fbsd-err.pvp.se/sysctl_acpi_compiled.txt
> >> This doesn't make it nay clearer why you get that build problem.
> >
> > I dunno. I dont have any insight into kernel programming. Hence trying to
> > get information how to help the people to fix the actual problem. That the
> > server freezes at boot. Im kind of lucky to have HP ILO on my side, to
> > test things. =)
> >
> > But I will upgrade the BIOS. If that does not work, I'll try a clean
> > 7.2-REL install.
>
> BIOS upgrade may improve some things for you, but I'd be very surprised if it
> fixes the build problem in question.

Well, it did not improve anything. Apperently the output from ILO is not
the correct one. Probably it freezes the output to ILO before it can
update the screen. (I run ILO through SSH)

I took a photo of the actual output presented on a CRT.

http://fbsd-err.pvp.se/fbsd-freeze-dl385.jpg

(sorry for the blury image, but I cant get it any better from my
cellphone)

I did not have time to reinstall the system from scratch. But that can be
done remotely if needed.

I am currently building the source on another machine. Lets see if it will
build it any better.

(Remember that this happens on two different servers that are specified
the exact same way)

/Bjorn
From attilio at freebsd.org  Thu Sep 24 13:16:34 2009
From: attilio at freebsd.org (Attilio Rao)
Date: Thu Sep 24 13:16:42 2009
Subject: 8.0-RC1 panic attaching ppc
In-Reply-To: <200909241455.32216.doconnor@gsoft.com.au>
References: <200909232322.51060.doconnor@gsoft.com.au>
	<3bbf2fe10909230654g2030b18aq8a93e26a7789b06f@mail.gmail.com>
	<200909241455.32216.doconnor@gsoft.com.au>
Message-ID: <3bbf2fe10909240616k18de2bf8mbadb7526a46f1f58@mail.gmail.com>

2009/9/24 Daniel O'Connor <doconnor@gsoft.com.au>:
> On Wed, 23 Sep 2009, Attilio Rao wrote:
>> 2009/9/23 Daniel O'Connor <doconnor@gsoft.com.au>:
>> > If I enable the parallel port on this Gigabyte MA7785GM-US2H I get
>> > a trap 12 when booting up.
>> >
>> > I forgot to take a picture of it at the time but I should be able
>> > to reproduce it tomorrow.
>> >
>> > Has anyone seen anything before? (a quick google showed nothing). I
>> > did not see it on 7.2(ish) on the same hardware.
>>
>> Are you able to enable KDB in your kernel config and return a
>> backtrace here?
>
> Yes, here it is..
>
> pmap_extract() at pmap_extract+0x13a
> isa_dmarangecheck() at isa_dmarangecheck+0x7a
> isa_dma_init() at isa_dma_init+0xda
> ppc_isa_attach() at ppc_sa_attach+0x40
> device_attach() at device_attach+0x69
> bus_generic_attach() at bus_generic_attach+0x1a
> acpi_attach() at acpi_attach+0x9f8
>
> (there's more but I imagine the above is probably sufficient).
>
> I took pictures, they are here
> http://www.gsoft.com.au/~doconnor/SNC00111.jpg
> http://www.gsoft.com.au/~doconnor/SNC00112.jpg
>
> If I put the parallel port in EPP mode then it works, I presume that's
> because it doesn't require a DMA channel whereas ECP doesn't. I haven't
> enumerated the possibilities though :)

Can you try to get a kernel dump that we can analyze?
You would just need to recompile the kernel with options KDB, GDB and
debugging symbols.
Then we can do more on that.

Thanks,
Attilio


-- 
Peace can only be achieved by understanding - A. Einstein
From jhb at freebsd.org  Thu Sep 24 14:24:35 2009
From: jhb at freebsd.org (John Baldwin)
Date: Thu Sep 24 14:24:51 2009
Subject: 8.0-RC1 panic attaching ppc
In-Reply-To: <200909241455.32216.doconnor@gsoft.com.au>
References: <200909232322.51060.doconnor@gsoft.com.au>
	<3bbf2fe10909230654g2030b18aq8a93e26a7789b06f@mail.gmail.com>
	<200909241455.32216.doconnor@gsoft.com.au>
Message-ID: <200909240920.05027.jhb@freebsd.org>

On Thursday 24 September 2009 1:25:15 am Daniel O'Connor wrote:
> On Wed, 23 Sep 2009, Attilio Rao wrote:
> > 2009/9/23 Daniel O'Connor <doconnor@gsoft.com.au>:
> > > If I enable the parallel port on this Gigabyte MA7785GM-US2H I get
> > > a trap 12 when booting up.
> > >
> > > I forgot to take a picture of it at the time but I should be able
> > > to reproduce it tomorrow.
> > >
> > > Has anyone seen anything before? (a quick google showed nothing). I
> > > did not see it on 7.2(ish) on the same hardware.
> >
> > Are you able to enable KDB in your kernel config and return a
> > backtrace here?
> 
> Yes, here it is..
> 
> pmap_extract() at pmap_extract+0x13a
> isa_dmarangecheck() at isa_dmarangecheck+0x7a
> isa_dma_init() at isa_dma_init+0xda
> ppc_isa_attach() at ppc_sa_attach+0x40
> device_attach() at device_attach+0x69
> bus_generic_attach() at bus_generic_attach+0x1a
> acpi_attach() at acpi_attach+0x9f8
> 
> (there's more but I imagine the above is probably sufficient).

Can you try this patch perhaps:

Index: sys/amd64/isa/isa_dma.c
===================================================================
--- isa_dma.c	(revision 197430)
+++ isa_dma.c	(working copy)
@@ -247,7 +247,7 @@
 	}
 
 	/* translate to physical */
-	phys = pmap_extract(kernel_pmap, (vm_offset_t)addr);
+	phys = pmap_kextract((vm_offset_t)addr);
 
 	if (flags & ISADMA_RAW) {
 	    dma_auto_mode |= (1 << chan);
@@ -371,7 +371,7 @@
 
 	endva = (vm_offset_t)round_page((vm_offset_t)va + length);
 	for (; va < (caddr_t) endva ; va += PAGE_SIZE) {
-		phys = trunc_page(pmap_extract(kernel_pmap, (vm_offset_t)va));
+		phys = trunc_page(pmap_kextract((vm_offset_t)va));
 		if (phys == 0)
 			panic("isa_dmacheck: no physical page present");
 		if (phys >= ISARAM_END)

-- 
John Baldwin
From danger at FreeBSD.org  Thu Sep 24 15:32:15 2009
From: danger at FreeBSD.org (Daniel Gerzo)
Date: Thu Sep 24 15:32:47 2009
Subject: HEADSUP: Call for FreeBSD Status Reports
Message-ID: <4ABB8B31.7050505@FreeBSD.org>

Dear all,

I would like to remind you to submit your status reports as soon as 
possible. Long time has passed since the last status reports were 
released; and surely a lot has had happened since then.

Our developers are relaxed after DevSummit and EuroBSDCon in Cambridge, 
which both were great! I believe a lot of stuff has been discussed 
during these events (I hope we will have reports covering this too) and 
since the last report a lot of things have happened. During that time, 
two other conferences have been held (BSDCan and AsiaBSDCon), we have 
released 7.2, not to mention that 8.0 is behind the door. Google Summer 
of Code should be finished by now too, and we would like to hear about 
its results.
Surely there are a lot more projects which are currently being worked 
on, so please do not hesitate and write us a few lines - a short 
description about what you are working on, what are the plans and goals, 
so we can inform our community about your great work! It's useful for 
you as well as our users!

Please note, the submissions for this quarter (well...rather halfyear, 
because we should now cover 4-9/2009) are due by October 7th, 2009.

Please post the filled-in XML template to be found at 
http://www.freebsd.org/news/status/report-sample.xml to 
monthly@FreeBSD.org, or alternatively use our web based form at 
http://www.freebsd.org/cgi/monthly.cgi.

We are looking forward to see your submissions!


-- 
S pozdravom / Best regards
   Daniel Gerzo, FreeBSD committer
From dougb at FreeBSD.org  Thu Sep 24 22:37:56 2009
From: dougb at FreeBSD.org (Doug Barton)
Date: Thu Sep 24 22:38:03 2009
Subject: Base system's Heimdal with Openldap support?
In-Reply-To: <20090923155402.GG81123@cesium.hyperfine.info>
References: <4ABA0E63.90209@eng.auth.gr>
	<20090923155402.GG81123@cesium.hyperfine.info>
Message-ID: <4ABBF4B9.4070203@FreeBSD.org>

Peter C. Lai wrote:
> It's probably a bad idea to link a binary in base with a library from ports...

What is the reasoning behind this statement?


Doug

-- 

    This .signature sanitized for your protection

From peter at simons-rock.edu  Thu Sep 24 22:41:20 2009
From: peter at simons-rock.edu (Peter C. Lai)
Date: Thu Sep 24 22:41:27 2009
Subject: Base system's Heimdal with Openldap support?
In-Reply-To: <4ABBF4B9.4070203@FreeBSD.org>
References: <4ABA0E63.90209@eng.auth.gr>
	<20090923155402.GG81123@cesium.hyperfine.info>
	<4ABBF4B9.4070203@FreeBSD.org>
Message-ID: <20090924224115.GU81123@cesium.hyperfine.info>

What happens when you portupgrade? You will have to deal with rebuilding
that part of world?

On 2009-09-24 03:37:45PM -0700, Doug Barton wrote:
> Peter C. Lai wrote:
> > It's probably a bad idea to link a binary in base with a library from ports...
> 
> What is the reasoning behind this statement?
> 
> 
> Doug
> 
> -- 
> 
>     This .signature sanitized for your protection
> 

-- 
===========================================================
Peter C. Lai                 | Bard College at Simon's Rock
Systems Administrator        | 84 Alford Rd.
Information Technology Svcs. | Gt. Barrington, MA 01230 USA
peter AT simons-rock.edu     | (413) 528-7428
===========================================================

From dougb at FreeBSD.org  Thu Sep 24 23:45:38 2009
From: dougb at FreeBSD.org (Doug Barton)
Date: Thu Sep 24 23:45:45 2009
Subject: Base system's Heimdal with Openldap support?
In-Reply-To: <20090924224115.GU81123@cesium.hyperfine.info>
References: <4ABA0E63.90209@eng.auth.gr>	<20090923155402.GG81123@cesium.hyperfine.info>	<4ABBF4B9.4070203@FreeBSD.org>
	<20090924224115.GU81123@cesium.hyperfine.info>
Message-ID: <4ABC0481.9080000@FreeBSD.org>

Peter C. Lai wrote:
> What happens when you portupgrade? You will have to deal with rebuilding
> that part of world?

Not unless the shared library version number changes, that's the
beauty of shared libraries.


Doug
From eugen at kuzbass.ru  Fri Sep 25 05:44:57 2009
From: eugen at kuzbass.ru (Eugene Grosbein)
Date: Fri Sep 25 05:45:04 2009
Subject: amd/autofs
Message-ID: <20090925054452.GA30829@svzserv.kemerovo.su>

Hi!

What is a status of autofs (in the context of AMD) in FreeBSD these days?

Eugene Grosbein
From bu7cher at yandex.ru  Fri Sep 25 05:47:19 2009
From: bu7cher at yandex.ru (Andrey V. Elsukov)
Date: Fri Sep 25 05:48:33 2009
Subject: PATA disks/DVD not detected on ATI IXP 700 - cannot boot (dmesg
 attached)
In-Reply-To: <dde89ecd0909242239j4ecebc3dsfef5ec265237b5b3@mail.gmail.com>
References: <20090916161327.GB87631@zod.isi.edu>	
	<20090919035214.GA12889@zod.isi.edu>	
	<200909211239.25614.jkim@FreeBSD.org> <4AB9A3CE.4090509@yandex.ru>
	<dde89ecd0909242239j4ecebc3dsfef5ec265237b5b3@mail.gmail.com>
Message-ID: <4ABC5962.80404@yandex.ru>

Dennis Chikin wrote:
>> Ted and Dennis can you try it?
> 
> Seems OK.

Is it means that all works with this patch?
Can you show dmesg from patched system?

PS. Please reply to all CC'd recipients (i added persons who can commit this patch).

-- 
WBR, Andrey V. Elsukov
From doconnor at gsoft.com.au  Fri Sep 25 07:20:24 2009
From: doconnor at gsoft.com.au (Daniel O'Connor)
Date: Fri Sep 25 07:20:37 2009
Subject: 8.0-RC1 panic attaching ppc
In-Reply-To: <200909240920.05027.jhb@freebsd.org>
References: <200909232322.51060.doconnor@gsoft.com.au>
	<200909241455.32216.doconnor@gsoft.com.au>
	<200909240920.05027.jhb@freebsd.org>
Message-ID: <200909251650.16283.doconnor@gsoft.com.au>

On Thu, 24 Sep 2009, John Baldwin wrote:
> Can you try this patch perhaps:
>
> Index: sys/amd64/isa/isa_dma.c
> ===================================================================
> --- isa_dma.c	(revision 197430)
> +++ isa_dma.c	(working copy)

This patch fixes the panic for me.

I haven't tried printing (don't have any device handy here).

-- 
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
  -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090925/ac75989b/attachment.pgp
From doconnor at gsoft.com.au  Fri Sep 25 07:48:06 2009
From: doconnor at gsoft.com.au (Daniel O'Connor)
Date: Fri Sep 25 07:48:14 2009
Subject: USB problems with 8.0-RC1 & ATI SB6000
Message-ID: <200909251718.00245.doconnor@gsoft.com.au>

Skipped content of type multipart/mixed-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090925/912bfb3d/attachment.pgp
From to.my.trociny at gmail.com  Fri Sep 25 08:20:46 2009
From: to.my.trociny at gmail.com (Mikolaj Golub)
Date: Fri Sep 25 08:20:57 2009
Subject: May running megarc still cause memory corruption on 7.X?
Message-ID: <81d45flayz.fsf@zhuzha.ua1>

Hi,

Previously sysutils/megarc port was marked as broken with the statement:
running megarc may cause memory corruption/system instability.

http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/128082

But recently it has been re-enabled:

http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/137938

Gerrit Beine (the maintainer) said that he verified on 7.2 and it worked.

But yesterday we had the panic on 7.1-RELEASE-p5 that looked like was caused
by megarc with bt identical to reported in ports/128082.

Unread portion of the kernel message buffer:
TPTE at 0xbfd20830  IS ZERO @ VA 4820c000
panic: bad pte
cpuid = 0
Uptime: 10h19m56s
Physical memory: 3059 MB
Dumping 225 MB: 210 194 178 162 146 130 114 98 82 66 50 34 18 2

(kgdb) backtrace
#0  doadump () at pcpu.h:196
#1  0xc07910a7 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418
#2  0xc0791379 in panic (fmt=Variable "fmt" is not available.
) at /usr/src/sys/kern/kern_shutdown.c:574
#3  0xc0aa37f6 in pmap_remove_pages (pmap=0xc69ae6e4) at /usr/src/sys/i386/i386/pmap.c:3084
#4  0xc09cf79c in vmspace_exit (td=0xc64f68c0) at /usr/src/sys/vm/vm_map.c:404
#5  0xc076b6ad in exit1 (td=0xc64f68c0, rv=0) at /usr/src/sys/kern/kern_exit.c:305
#6  0xc076ca0d in sys_exit (td=Could not find the frame base for "sys_exit".
) at /usr/src/sys/kern/kern_exit.c:109
#7  0xc0aa81a5 in syscall (frame=0xe8d6ed38) at /usr/src/sys/i386/i386/trap.c:1090
#8  0xc0a8e6e0 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:255
#9  0x00000033 in ?? ()
Previous frame inner to this frame (corrupt stack?)

(kgdb) allpcpu 
cpuid        = 3
curthread    = 0xc6ae3d20: pid 48975 "sh"
curpcb       = 0xe8ea1d90
fpcurthread  = none
idlethread   = 0xc633daf0: pid 11 "idle: cpu3"
switchticks  = 37193321

cpuid        = 2
curthread    = 0xc633d8c0: pid 12 "idle: cpu2"
curpcb       = 0xe4f10d90
fpcurthread  = none
idlethread   = 0xc633d8c0: pid 12 "idle: cpu2"
switchticks  = 37193374

cpuid        = 1
curthread    = 0xc633d690: pid 13 "idle: cpu1"
curpcb       = 0xe4f13d90
fpcurthread  = none
idlethread   = 0xc633d690: pid 13 "idle: cpu1"
switchticks  = 37193374

cpuid        = 0
curthread    = 0xc64f68c0: pid 48980 "sh"
curpcb       = 0xe8d6ed90
fpcurthread  = none
idlethread   = 0xc633d460: pid 14 "idle: cpu0"
switchticks  = 37193321

(kgdb) ps
  pid  ppid  pgrp   uid   state   wmesg     wchan    cmd
48980 48975 48975     0  RE      CPU  0              sh
48978 48976 48976     0  R                           megarc
48976 48973 48976     0  Ss      wait     0xc826e570 sh
48975 48972 48975     0  Rs      CPU  3              sh
48973   705   705     0  S       piperd   0xc8303318 cron
48972   705   705     0  S       piperd   0xc674a18c cron
48267 18141 18141    80  S       lockf    0xc83922c0 httpd
48266 18141 18141    80  S       lockf    0xc7d62400 httpd
48265 18141 18141    80  S       select   0xc0c4ecb8 httpd
48264 18141 18141    80  S       lockf    0xc7ceb240 httpd
...

At the moment of the crash megarc was run by cron (48973) at the same time
other cron job was started (we have the following script set up to run in the
same time:

if [ -x /usr/local/bin/vnstat ] && [ `ls -l /var/db/vnstat/ | wc -l` -ge 1 ]; then /usr/local/bin/vnstat -u; fi)

and this sh process caused panic on its exit when kernel was trying to remove
its address space due to corrupted memory.

Should I add the comment to ports/137938 about this? I cc to Gerrit. Please
note, we are using 7.1-RELEASE-p5 while in ports/137938 it is said that it was
checked on 7.2. But it might be that Gerrit just did not test long enough? We
had megarc enabled on several 7.1 hosts for some times and saw only this one
panic (well, there was another one about a week ago, but it looked hardly
related, because megarc was not running at the moment of the crash and the
panic was when removing an entry from the namecache, I reported it to
hackers@).

Below some details from gdb session in case someone is interested to look at
this closer.

(kgdb) allchains 
# no output

(kgdb) fr 5
#5  0xc076b6ad in exit1 (td=0xc64f68c0, rv=0) at /usr/src/sys/kern/kern_exit.c:305
305             vmspace_exit(td);
(kgdb) p *td->td_proc
$1 = {p_list = {le_next = 0xc69a2570, le_prev = 0xc0c433f8}, p_threads = {tqh_first = 0xc64f68c0, 
    tqh_last = 0xc64f68c8}, p_upcalls = {tqh_first = 0x0, tqh_last = 0xc6502838}, p_slock = {
    lock_object = {lo_name = 0xc0b3b5ae "process slock", lo_type = 0xc0b3b5ae "process slock", 
      lo_flags = 720896, lo_witness_data = {lod_list = {stqe_next = 0x0}, lod_witness = 0x0}}, 
    mtx_lock = 4, mtx_recurse = 0}, p_ucred = 0xc708f700, p_fd = 0x0, p_fdtol = 0x0, 
  p_stats = 0xc64f8000, p_limit = 0xc7c60800, p_limco = {c_links = {sle = {sle_next = 0x0}, tqe = {
        tqe_next = 0x0, tqe_prev = 0x0}}, c_time = 0, c_arg = 0x0, c_func = 0, c_mtx = 0xc65028b8, 
    c_flags = 0}, p_sigacts = 0xc7d00000, p_flag = 268443648, p_state = PRS_NORMAL, p_pid = 48980, 
  p_hash = {le_next = 0x0, le_prev = 0xc632ad50}, p_pglist = {le_next = 0x0, le_prev = 0xc709b8a0}, 
  p_pptr = 0xc709b828, p_sibling = {le_next = 0x0, le_prev = 0xc709b8b4}, p_children = {
    lh_first = 0x0}, p_mtx = {lock_object = {lo_name = 0xc0b3b5a1 "process lock", 
      lo_type = 0xc0b3b5a1 "process lock", lo_flags = 21168128, lo_witness_data = {lod_list = {
          stqe_next = 0x0}, lod_witness = 0x0}}, mtx_lock = 4, mtx_recurse = 0}, p_ksi = 0xc6655cd0, 
  p_sigqueue = {sq_signals = {__bits = {0, 0, 0, 0}}, sq_kill = {__bits = {0, 0, 0, 0}}, sq_list = {
      tqh_first = 0x0, tqh_last = 0xc65028f4}, sq_proc = 0xc6502828, sq_flags = 1}, p_oppid = 0, 
  p_vmspace = 0xc69ae658, p_swtick = 37193315, p_realtimer = {it_interval = {tv_sec = 0, tv_usec = 0}, 
    it_value = {tv_sec = 0, tv_usec = 0}}, p_ru = {ru_utime = {tv_sec = 0, tv_usec = 0}, ru_stime = {
      tv_sec = 0, tv_usec = 0}, ru_maxrss = 0, ru_ixrss = 0, ru_idrss = 0, ru_isrss = 0, ru_minflt = 0, 
    ru_majflt = 0, ru_nswap = 0, ru_inblock = 0, ru_oublock = 0, ru_msgsnd = 0, ru_msgrcv = 0, 
    ru_nsignals = 0, ru_nvcsw = 0, ru_nivcsw = 0}, p_rux = {rux_runtime = 0, rux_uticks = 0, 
    rux_sticks = 0, rux_iticks = 0, rux_uu = 0, rux_su = 0, rux_tu = 0}, p_crux = {
    rux_runtime = 20485868, rux_uticks = 0, rux_sticks = 0, rux_iticks = 0, rux_uu = 0, rux_su = 6784, 
    rux_tu = 6784}, p_profthreads = 0, p_exitthreads = 0, p_traceflag = 0, p_tracevp = 0x0, 
  p_tracecred = 0x0, p_textvp = 0xc66dce04, p_lock = 0 '\0', p_sigiolst = {slh_first = 0x0}, 
  p_sigparent = 20, p_sig = 0, p_code = 0, p_stops = 0, p_stype = 0, p_step = 0 '\0', 
  p_pfsflags = 0 '\0', p_nlminfo = 0x0, p_aioinfo = 0x0, p_singlethread = 0x0, p_suspcount = 0, 
  p_xthread = 0x0, p_boundary_count = 0, p_pendingcnt = 0, p_itimers = 0x0, p_numupcalls = 0, 
  p_upsleeps = 0, p_completed = 0x0, p_nextupcall = 0, p_upquantum = 0, p_magic = 3203398350, 
  p_osrel = 701000, p_comm = "sh\000n\000er", '\0' <repeats 12 times>, p_pgrp = 0xc839c5c0, 
  p_sysent = 0xc0c0a6e0, p_args = 0xc7c25b00, p_cpulimit = 9223372036854775807, p_nice = 0 '\0', 
  p_fibnum = 0, p_xstat = 0, p_klist = {kl_list = {slh_first = 0x0}, 
    kl_lock = 0xc0766af0 <knlist_mtx_lock>, kl_unlock = 0xc07664d0 <knlist_mtx_unlock>, 
    kl_locked = 0xc07664b0 <knlist_mtx_locked>, kl_lockarg = 0xc65028b8}, p_numthreads = 1, p_md = {
    md_ldt = 0x0}, p_itcallout = {c_links = {sle = {sle_next = 0x0}, tqe = {tqe_next = 0x0, 
        tqe_prev = 0x0}}, c_time = 0, c_arg = 0x0, c_func = 0, c_mtx = 0x0, c_flags = 16}, 
  p_acflag = 1, p_peers = 0x0, p_leader = 0xc6502828, p_emuldata = 0x0, p_label = 0x0, 
  p_sched = 0xc6502ae0, p_ktr = {stqh_first = 0x0, stqh_last = 0xc6502ad0}, p_mqnotifier = {
    lh_first = 0x0}, p_dtrace = 0x0}
(kgdb) p *td
$8 = {td_lock = 0xc0c4bcc0, td_proc = 0xc6502828, td_plist = {tqe_next = 0x0, tqe_prev = 0xc6502830}, 
  td_slpq = {tqe_next = 0x0, tqe_prev = 0xc632f040}, td_lockq = {tqe_next = 0x0, 
    tqe_prev = 0xe8ee6a6c}, td_selq = {tqh_first = 0x0, tqh_last = 0xc64f68e0}, 
  td_sleepqueue = 0xc632f040, td_turnstile = 0xc68d6eb0, td_umtxq = 0xc64d8840, td_tid = 100094, 
  td_sigqueue = {sq_signals = {__bits = {0, 0, 0, 0}}, sq_kill = {__bits = {0, 0, 0, 0}}, sq_list = {
      tqh_first = 0x0, tqh_last = 0xc64f6918}, sq_proc = 0xc6502828, sq_flags = 1}, td_flags = 65542, 
  td_inhibitors = 0, td_pflags = 0, td_dupfd = 0, td_sqqueue = 0, td_wchan = 0x0, td_wmesg = 0x0, 
  td_lastcpu = 0 '\0', td_oncpu = 0 '\0', td_owepreempt = 0 '\0', td_locks = -2, td_tsqueue = 0 '\0', 
  td_blocked = 0x0, td_lockname = 0x0, td_contested = {lh_first = 0x0}, td_sleeplocks = 0x0, 
  td_intr_nesting_level = 0, td_pinned = 3, td_mailbox = 0x0, td_ucred = 0xc708f700, td_standin = 0x0, 
  td_upcall = 0x0, td_estcpu = 0, td_slptick = 0, td_ru = {ru_utime = {tv_sec = 0, tv_usec = 0}, 
    ru_stime = {tv_sec = 0, tv_usec = 0}, ru_maxrss = 1768, ru_ixrss = 1512, ru_idrss = 8792, 
    ru_isrss = 1792, ru_minflt = 51, ru_majflt = 0, ru_nswap = 0, ru_inblock = 0, ru_oublock = 0, 
    ru_msgsnd = 0, ru_msgrcv = 0, ru_nsignals = 0, ru_nvcsw = 2, ru_nivcsw = 1}, td_runtime = 3186278, 
  td_pticks = 13, td_sticks = 14, td_iticks = 0, td_uticks = 0, td_uuticks = 0, td_usticks = 0, 
  td_intrval = 0, td_oldsigmask = {__bits = {0, 0, 0, 0}}, td_sigmask = {__bits = {0, 0, 0, 0}}, 
  td_generation = 3, td_sigstk = {ss_sp = 0x0, ss_size = 0, ss_flags = 4}, td_kflags = 0, td_xsig = 0, 
  td_profil_addr = 0, td_profil_ticks = 0, td_name = '\0' <repeats 19 times>, td_base_pri = 134 '\206', 
  td_priority = 134 '\206', td_pri_class = 3 '\003', td_user_pri = 144 '\220', 
  td_base_user_pri = 144 '\220', td_pcb = 0xe8d6ed90, td_state = TDS_RUNNING, td_retval = {0, 
    134598480}, td_slpcallout = {c_links = {sle = {sle_next = 0x0}, tqe = {tqe_next = 0x0, 
        tqe_prev = 0xda3550f0}}, c_time = 34564372, c_arg = 0xc64f68c0, 
    c_func = 0xc07c2f90 <sleepq_timeout>, c_mtx = 0x0, c_flags = 18}, td_frame = 0xe8d6ed38, 
  td_kstack_obj = 0xc677e554, td_kstack = 3906392064, td_kstack_pages = 2, td_altkstack_obj = 0x0, 
  td_altkstack = 0, td_altkstack_pages = 0, td_critnest = 0, td_md = {md_spinlock_count = 0, 
    md_saved_flags = 70}, td_sched = 0xc64f6abc, td_ar = 0x0, td_syscalls = 75641, 
  td_incruntime = 3186278, td_cpuset = 0xc6331e38, td_fpop = 0x0, td_dtrace = 0x0, td_errno = 0}

(kgdb) thr 126
[Switching to thread 126 (Thread 100083)]#0  sched_switch (td=0xc674cd20, newtd=Variable "newtd" is not available.
)
    at /usr/src/sys/kern/sched_ule.c:1944
1944                    cpuid = PCPU_GET(cpuid);
(kgdb) backtrace
#0  sched_switch (td=0xc674cd20, newtd=Variable "newtd" is not available.
) at /usr/src/sys/kern/sched_ule.c:1944
#1  0xc0799136 in mi_switch (flags=Variable "flags" is not available.
) at /usr/src/sys/kern/kern_synch.c:440
#2  0xc07c284b in sleepq_switch (wchan=Variable "wchan" is not available.
) at /usr/src/sys/kern/subr_sleepqueue.c:497
#3  0xc07c2e96 in sleepq_wait (wchan=0xc6492f28) at /usr/src/sys/kern/subr_sleepqueue.c:580
#4  0xc07995a6 in _sleep (ident=0xc6492f28, lock=0xc647592c, priority=76, wmesg=0xc0b042bb "amrwcmd", 
    timo=0) at /usr/src/sys/kern/kern_synch.c:226
#5  0xc04e8ca4 in amr_wait_command (ac=0xc6492f28) at /usr/src/sys/dev/amr/amr.c:1392
#6  0xc04e9faa in amr_ioctl (dev=0xc645e700, cmd=3224388353, addr=0xc7bb1c40 "\003", flag=1, 
    td=0xc674cd20) at /usr/src/sys/dev/amr/amr.c:914
#7  0xc0755d37 in giant_ioctl (dev=0xc645e700, cmd=3224388353, data=0xc7bb1c40 "\003", fflag=1, 
    td=0xc674cd20) at /usr/src/sys/kern/kern_conf.c:408
#8  0xc071ff47 in devfs_ioctl_f (fp=0xc707063c, com=3224388353, data=0xc7bb1c40, cred=0xc707a200, 
    td=0xc674cd20) at /usr/src/sys/fs/devfs/devfs_vnops.c:595
#9  0xc07c8005 in kern_ioctl (td=0xc674cd20, fd=4, com=3224388353, data=0xc7bb1c40 "\003") at file.h:268
#10 0xc07c8164 in ioctl (td=0xc674cd20, uap=0xe8d33cfc) at /usr/src/sys/kern/sys_generic.c:570
#11 0xc0aa81a5 in syscall (frame=0xe8d33d38) at /usr/src/sys/i386/i386/trap.c:1090
#12 0xc0a8e6e0 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:255
#13 0x00000033 in ?? ()
Previous frame inner to this frame (corrupt stack?)

(kgdb) fr 4
#4  0xc07995a6 in _sleep (ident=0xc6492f28, lock=0xc647592c, priority=76, wmesg=0xc0b042bb "amrwcmd", 
    timo=0) at /usr/src/sys/kern/kern_synch.c:226
226                     sleepq_wait(ident);
(kgdb) p *lock
$2 = {lo_name = 0xc0b04655 "AMR List Lock", lo_type = 0xc0b04655 "AMR List Lock", lo_flags = 16973824, 
  lo_witness_data = {lod_list = {stqe_next = 0x0}, lod_witness = 0x0}}

(kgdb) fr 5
#5  0xc04e8ca4 in amr_wait_command (ac=0xc6492f28) at /usr/src/sys/dev/amr/amr.c:1392
1392            error = msleep(ac,&sc->amr_list_lock, PRIBIO, "amrwcmd", 0);
(kgdb) p ac
$3 = (struct amr_command *) 0xc6492f28
(kgdb) p *ac
$4 = {ac_link = {stqe_next = 0x0}, ac_sc = 0xc6475000, ac_slot = 118 'v', ac_status = 0, ac_sg = {
    sg32 = 0xe6993fe0, sg64 = 0xe6993fe0}, ac_sgbusaddr = 21716960, ac_sg64_lo = 0, ac_sg64_hi = 0, 
  ac_mailbox = {mb_command = 3 '\003', mb_ident = 119 'w', mb_blkcount = 0, mb_lba = 0, 
    mb_physaddr = 21773056, mb_drive = 0 '\0', mb_nsgelem = 0 '\0', res1 = 0 '\0', mb_busy = 0 '\0', 
    mb_nstatus = 0 '\0', mb_status = 0 '\0', mb_completed = '\0' <repeats 45 times>, mb_poll = 0 '\0', 
    mb_ack = 0 '\0', res2 = '\0' <repeats 15 times>}, ac_flags = 71, ac_retries = 0, ac_bio = 0x0, 
  ac_complete = 0, ac_private = 0x0, ac_data = 0xc672ac90, ac_length = 8, ac_dmamap = 0x0, 
  ac_dma64map = 0x0, ac_tag = 0xc647c600, ac_datamap = 0x0, ac_nsegments = 0, 
  ac_mb_physaddr = 27487376, ac_ccb = 0xe699eb00, ac_ccb_busaddr = 21773056}

(kgdb) fr 6
#6  0xc04e9faa in amr_ioctl (dev=0xc645e700, cmd=3224388353, addr=0xc7bb1c40 "\003", flag=1, 
    td=0xc674cd20) at /usr/src/sys/dev/amr/amr.c:914
914         error = amr_wait_command(ac);
(kgdb) p *td
$6 = {td_lock = 0xc0c4bcc0, td_proc = 0xc69a2570, td_plist = {tqe_next = 0x0, tqe_prev = 0xc69a2578}, 
  td_slpq = {tqe_next = 0x0, tqe_prev = 0xc632f3e0}, td_lockq = {tqe_next = 0x0, 
    tqe_prev = 0xe8fe9a6c}, td_selq = {tqh_first = 0x0, tqh_last = 0xc674cd40}, 
  td_sleepqueue = 0xc632f3e0, td_turnstile = 0xc7c95460, td_umtxq = 0xc66a2500, td_tid = 100083, 
  td_sigqueue = {sq_signals = {__bits = {0, 0, 0, 0}}, sq_kill = {__bits = {0, 0, 0, 0}}, sq_list = {
      tqh_first = 0x0, tqh_last = 0xc674cd78}, sq_proc = 0xc69a2570, sq_flags = 1}, td_flags = 4, 
  td_inhibitors = 0, td_pflags = 0, td_dupfd = -1, td_sqqueue = 0, td_wchan = 0x0, td_wmesg = 0x0, 
  td_lastcpu = 1 '\001', td_oncpu = 255 '?', td_owepreempt = 0 '\0', td_locks = 6, td_tsqueue = 0 '\0', 
  td_blocked = 0x0, td_lockname = 0x0, td_contested = {lh_first = 0x0}, td_sleeplocks = 0x0, 
  td_intr_nesting_level = 0, td_pinned = 0, td_mailbox = 0x0, td_ucred = 0xc707a200, td_standin = 0x0, 
  td_upcall = 0x0, td_estcpu = 0, td_slptick = 0, td_ru = {ru_utime = {tv_sec = 0, tv_usec = 0}, 
    ru_stime = {tv_sec = 0, tv_usec = 0}, ru_maxrss = 0, ru_ixrss = 0, ru_idrss = 0, ru_isrss = 0, 
    ru_minflt = 39, ru_majflt = 0, ru_nswap = 0, ru_inblock = 0, ru_oublock = 0, ru_msgsnd = 0, 
    ru_msgrcv = 0, ru_nsignals = 0, ru_nvcsw = 9, ru_nivcsw = 1}, td_runtime = 6243427, td_pticks = 0, 
  td_sticks = 0, td_iticks = 0, td_uticks = 0, td_uuticks = 0, td_usticks = 0, td_intrval = 0, 
  td_oldsigmask = {__bits = {0, 0, 0, 0}}, td_sigmask = {__bits = {0, 0, 0, 0}}, td_generation = 10, 
  td_sigstk = {ss_sp = 0x0, ss_size = 0, ss_flags = 4}, td_kflags = 0, td_xsig = 0, td_profil_addr = 0, 
  td_profil_ticks = 0, td_name = '\0' <repeats 19 times>, td_base_pri = 76 'L', td_priority = 76 'L', 
  td_pri_class = 3 '\003', td_user_pri = 128 '\200', td_base_user_pri = 128 '\200', 
  td_pcb = 0xe8d33d90, td_state = TDS_CAN_RUN, td_retval = {0, 17}, td_slpcallout = {c_links = {sle = {
        sle_next = 0xc0c3f8d0}, tqe = {tqe_next = 0xc0c3f8d0, tqe_prev = 0xda33fce8}}, 
    c_time = 34422419, c_arg = 0xc674cd20, c_func = 0xc07c2f90 <sleepq_timeout>, c_mtx = 0x0, 
    c_flags = 18}, td_frame = 0xe8d33d38, td_kstack_obj = 0xc68e9c1c, td_kstack = 3906150400, 
  td_kstack_pages = 2, td_altkstack_obj = 0x0, td_altkstack = 0, td_altkstack_pages = 0, 
  td_critnest = 1, td_md = {md_spinlock_count = 1, md_saved_flags = 582}, td_sched = 0xc674cf1c, 
  td_ar = 0x0, td_syscalls = 99004, td_incruntime = 6243427, td_cpuset = 0xc6331e38, 
  td_fpop = 0xc707063c, td_dtrace = 0x0, td_errno = 0}
(kgdb) p *td->td_proc
$7 = {p_list = {le_next = 0xc826e570, le_prev = 0xc6502828}, p_threads = {tqh_first = 0xc674cd20, 
    tqh_last = 0xc674cd28}, p_upcalls = {tqh_first = 0x0, tqh_last = 0xc69a2580}, p_slock = {
    lock_object = {lo_name = 0xc0b3b5ae "process slock", lo_type = 0xc0b3b5ae "process slock", 
      lo_flags = 720896, lo_witness_data = {lod_list = {stqe_next = 0x0}, lod_witness = 0x0}}, 
    mtx_lock = 4, mtx_recurse = 0}, p_ucred = 0xc707a200, p_fd = 0xc7c52d00, p_fdtol = 0x0, 
  p_stats = 0xc674fd00, p_limit = 0xc7c34000, p_limco = {c_links = {sle = {sle_next = 0x0}, tqe = {
        tqe_next = 0x0, tqe_prev = 0x0}}, c_time = 0, c_arg = 0x0, c_func = 0, c_mtx = 0xc69a2600, 
    c_flags = 0}, p_sigacts = 0xc7c76000, p_flag = 268451840, p_state = PRS_NORMAL, p_pid = 48978, 
  p_hash = {le_next = 0x0, le_prev = 0xc632ad48}, p_pglist = {le_next = 0x0, le_prev = 0xc826e5e8}, 
  p_pptr = 0xc826e570, p_sibling = {le_next = 0x0, le_prev = 0xc826e5fc}, p_children = {
    lh_first = 0x0}, p_mtx = {lock_object = {lo_name = 0xc0b3b5a1 "process lock", 
      lo_type = 0xc0b3b5a1 "process lock", lo_flags = 21168128, lo_witness_data = {lod_list = {
          stqe_next = 0x0}, lod_witness = 0x0}}, mtx_lock = 4, mtx_recurse = 0}, p_ksi = 0xc6656a00, 
  p_sigqueue = {sq_signals = {__bits = {0, 0, 0, 0}}, sq_kill = {__bits = {0, 0, 0, 0}}, sq_list = {
      tqh_first = 0x0, tqh_last = 0xc69a263c}, sq_proc = 0xc69a2570, sq_flags = 1}, p_oppid = 0, 
  p_vmspace = 0xc6fb7488, p_swtick = 37193314, p_realtimer = {it_interval = {tv_sec = 0, tv_usec = 0}, 
    it_value = {tv_sec = 0, tv_usec = 0}}, p_ru = {ru_utime = {tv_sec = 0, tv_usec = 0}, ru_stime = {
      tv_sec = 0, tv_usec = 0}, ru_maxrss = 0, ru_ixrss = 0, ru_idrss = 0, ru_isrss = 0, ru_minflt = 0, 
    ru_majflt = 0, ru_nswap = 0, ru_inblock = 0, ru_oublock = 0, ru_msgsnd = 0, ru_msgrcv = 0, 
    ru_nsignals = 0, ru_nvcsw = 0, ru_nivcsw = 0}, p_rux = {rux_runtime = 0, rux_uticks = 0, 
    rux_sticks = 0, rux_iticks = 0, rux_uu = 0, rux_su = 0, rux_tu = 0}, p_crux = {rux_runtime = 0, 
    rux_uticks = 0, rux_sticks = 0, rux_iticks = 0, rux_uu = 0, rux_su = 0, rux_tu = 0}, 
  p_profthreads = 0, p_exitthreads = 0, p_traceflag = 0, p_tracevp = 0x0, p_tracecred = 0x0, 
  p_textvp = 0xc6f368a0, p_lock = 0 '\0', p_sigiolst = {slh_first = 0x0}, p_sigparent = 20, p_sig = 0, 
  p_code = 0, p_stops = 0, p_stype = 0, p_step = 0 '\0', p_pfsflags = 0 '\0', p_nlminfo = 0x0, 
  p_aioinfo = 0x0, p_singlethread = 0x0, p_suspcount = 0, p_xthread = 0x0, p_boundary_count = 0, 
  p_pendingcnt = 0, p_itimers = 0x0, p_numupcalls = 0, p_upsleeps = 0, p_completed = 0x0, 
  p_nextupcall = 0, p_upquantum = 0, p_magic = 3203398350, p_osrel = 502010, 
  p_comm = "megarc", '\0' <repeats 13 times>, p_pgrp = 0xc839d140, p_sysent = 0xc0c0a6e0, 
  p_args = 0xc7bd6a00, p_cpulimit = 9223372036854775807, p_nice = 0 '\0', p_fibnum = 0, p_xstat = 0, 
  p_klist = {kl_list = {slh_first = 0x0}, kl_lock = 0xc0766af0 <knlist_mtx_lock>, 
    kl_unlock = 0xc07664d0 <knlist_mtx_unlock>, kl_locked = 0xc07664b0 <knlist_mtx_locked>, 
    kl_lockarg = 0xc69a2600}, p_numthreads = 1, p_md = {md_ldt = 0x0}, p_itcallout = {c_links = {sle = {
        sle_next = 0x0}, tqe = {tqe_next = 0x0, tqe_prev = 0x0}}, c_time = 0, c_arg = 0x0, c_func = 0, 
    c_mtx = 0x0, c_flags = 16}, p_acflag = 0, p_peers = 0x0, p_leader = 0xc69a2570, p_emuldata = 0x0, 
  p_label = 0x0, p_sched = 0xc69a2828, p_ktr = {stqh_first = 0x0, stqh_last = 0xc69a2818}, 
  p_mqnotifier = {lh_first = 0x0}, p_dtrace = 0x0}

I am keeping vmcore in case any additional output is needed.

-- 
Mikolaj Golub
From kama at pvp.se  Fri Sep 25 09:04:13 2009
From: kama at pvp.se (kama)
Date: Fri Sep 25 09:04:25 2009
Subject: FreeBSD 7.2-STABLE boot freeze (was: when calibrating clock.)
In-Reply-To: <20090924141927.Y37424@ns1.as.pvp.se>
References: <20090921140345.H37424@ns1.as.pvp.se>
	<20090922103150.V37424@ns1.as.pvp.se>
	<4AB8A95E.3060307@icyb.net.ua> <20090922142526.P37424@ns1.as.pvp.se>
	<4AB8E082.8050100@icyb.net.ua> <20090922215700.V37424@ns1.as.pvp.se>
	<4ABA1D1F.3080704@icyb.net.ua> <20090923171004.Q37424@ns1.as.pvp.se>
	<4ABA457E.3060800@freebsd.org> <20090924141927.Y37424@ns1.as.pvp.se>
Message-ID: <20090925110209.E37424@ns1.as.pvp.se>


On Thu, 24 Sep 2009, kama wrote:

> I am currently building the source on another machine. Lets see if it will
> build it any better.

Building the the world on another machine and install it on the DL385
machine made it also to freeze.

/Bjorn
From avg at freebsd.org  Fri Sep 25 09:11:46 2009
From: avg at freebsd.org (Andriy Gapon)
Date: Fri Sep 25 09:12:00 2009
Subject: FreeBSD 7.2-STABLE boot freeze
In-Reply-To: <20090925110209.E37424@ns1.as.pvp.se>
References: <20090921140345.H37424@ns1.as.pvp.se>
	<20090922103150.V37424@ns1.as.pvp.se>
	<4AB8A95E.3060307@icyb.net.ua>
	<20090922142526.P37424@ns1.as.pvp.se>
	<4AB8E082.8050100@icyb.net.ua>
	<20090922215700.V37424@ns1.as.pvp.se>
	<4ABA1D1F.3080704@icyb.net.ua>
	<20090923171004.Q37424@ns1.as.pvp.se>
	<4ABA457E.3060800@freebsd.org>
	<20090924141927.Y37424@ns1.as.pvp.se>
	<20090925110209.E37424@ns1.as.pvp.se>
Message-ID: <4ABC894E.7040204@freebsd.org>

on 25/09/2009 12:04 kama said the following:
> On Thu, 24 Sep 2009, kama wrote:
> 
>> I am currently building the source on another machine. Lets see if it will
>> build it any better.
> 
> Building the the world on another machine and install it on the DL385
> machine made it also to freeze.

Did you still get the message about unresolved symbol?

-- 
Andriy Gapon
From doconnor at gsoft.com.au  Fri Sep 25 09:12:54 2009
From: doconnor at gsoft.com.au (Daniel O'Connor)
Date: Fri Sep 25 09:13:01 2009
Subject: USB problems with 8.0-RC1 & ATI SB6000
In-Reply-To: <200909251718.00245.doconnor@gsoft.com.au>
References: <200909251718.00245.doconnor@gsoft.com.au>
Message-ID: <200909251842.51167.doconnor@gsoft.com.au>

On Fri, 25 Sep 2009, Daniel O'Connor wrote:
> I tried reverting to the old kernel but it behaves exactly the same
> now..

Never mind I found the thread on freebsd-usb@ titled "sb600/sb700 ohci 
experimental patch" which fixes it for me.

-- 
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
  -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090925/6198b377/attachment.pgp
From jhb at freebsd.org  Fri Sep 25 13:59:13 2009
From: jhb at freebsd.org (John Baldwin)
Date: Fri Sep 25 13:59:20 2009
Subject: 8.0-RC1 panic attaching ppc
In-Reply-To: <200909251650.16283.doconnor@gsoft.com.au>
References: <200909232322.51060.doconnor@gsoft.com.au>
	<200909240920.05027.jhb@freebsd.org>
	<200909251650.16283.doconnor@gsoft.com.au>
Message-ID: <200909250957.06252.jhb@freebsd.org>

On Friday 25 September 2009 3:20:05 am Daniel O'Connor wrote:
> On Thu, 24 Sep 2009, John Baldwin wrote:
> > Can you try this patch perhaps:
> >
> > Index: sys/amd64/isa/isa_dma.c
> > ===================================================================
> > --- isa_dma.c	(revision 197430)
> > +++ isa_dma.c	(working copy)
> 
> This patch fixes the panic for me.
> 
> I haven't tried printing (don't have any device handy here).

I wonder if pmap_extract(kernel_pmap) doesn't work with direct map addresses 
for some reason?  I kind of find that hard to believe actually.  Alan, the 
original panic was in pmap_extract(kernel_pmap, ...) calls in the isa_dma 
code.  My patch that "fixes" the panic just changes them to pmap_kextract(). 

-- 
John Baldwin
From brooks at freebsd.org  Fri Sep 25 14:57:13 2009
From: brooks at freebsd.org (Brooks Davis)
Date: Fri Sep 25 14:57:44 2009
Subject: Base system's Heimdal with Openldap support?
In-Reply-To: <4ABC0481.9080000@FreeBSD.org>
References: <4ABA0E63.90209@eng.auth.gr>
	<20090923155402.GG81123@cesium.hyperfine.info>
	<4ABBF4B9.4070203@FreeBSD.org>
	<20090924224115.GU81123@cesium.hyperfine.info>
	<4ABC0481.9080000@FreeBSD.org>
Message-ID: <20090925145620.GA27935@lor.one-eyed-alien.net>

On Thu, Sep 24, 2009 at 04:45:05PM -0700, Doug Barton wrote:
> Peter C. Lai wrote:
> > What happens when you portupgrade? You will have to deal with rebuilding
> > that part of world?
> 
> Not unless the shared library version number changes, that's the
> beauty of shared libraries.

Unfortunatly we're talking about openldap which has seen at least two
version bumps in the last 12 months IIRC.

-- Brooks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090925/de0c7350/attachment.pgp
From dsamms at nw-ds.com  Fri Sep 25 15:11:56 2009
From: dsamms at nw-ds.com (David Samms)
Date: Fri Sep 25 15:12:04 2009
Subject: May running megarc still cause memory corruption on 7.X?
In-Reply-To: <81d45flayz.fsf@zhuzha.ua1>
References: <81d45flayz.fsf@zhuzha.ua1>
Message-ID: <h9imiu$35b$1@ger.gmane.org>

Mikolaj Golub wrote:
> Hi,
> 
> Previously sysutils/megarc port was marked as broken with the statement:
> running megarc may cause memory corruption/system instability.
> 
> http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/128082
> 
> But recently it has been re-enabled:
> 
> http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/137938
> 
> Gerrit Beine (the maintainer) said that he verified on 7.2 and it worked.
> 
> But yesterday we had the panic on 7.1-RELEASE-p5 that looked like was caused
> by megarc with bt identical to reported in ports/128082.
> 
> Unread portion of the kernel message buffer:
> TPTE at 0xbfd20830  IS ZERO @ VA 4820c000
> panic: bad pte
> cpuid = 0
> Uptime: 10h19m56s
> Physical memory: 3059 MB
> Dumping 225 MB: 210 194 178 162 146 130 114 98 82 66 50 34 18 2
> 
> (kgdb) backtrace
> #0  doadump () at pcpu.h:196
> #1  0xc07910a7 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418
> #2  0xc0791379 in panic (fmt=Variable "fmt" is not available.
> ) at /usr/src/sys/kern/kern_shutdown.c:574
> #3  0xc0aa37f6 in pmap_remove_pages (pmap=0xc69ae6e4) at /usr/src/sys/i386/i386/pmap.c:3084
> #4  0xc09cf79c in vmspace_exit (td=0xc64f68c0) at /usr/src/sys/vm/vm_map.c:404
> #5  0xc076b6ad in exit1 (td=0xc64f68c0, rv=0) at /usr/src/sys/kern/kern_exit.c:305
> #6  0xc076ca0d in sys_exit (td=Could not find the frame base for "sys_exit".
> ) at /usr/src/sys/kern/kern_exit.c:109
> #7  0xc0aa81a5 in syscall (frame=0xe8d6ed38) at /usr/src/sys/i386/i386/trap.c:1090
> #8  0xc0a8e6e0 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:255
> #9  0x00000033 in ?? ()
> Previous frame inner to this frame (corrupt stack?)
> 
> (kgdb) allpcpu 
> cpuid        = 3
> curthread    = 0xc6ae3d20: pid 48975 "sh"
> curpcb       = 0xe8ea1d90
> fpcurthread  = none
> idlethread   = 0xc633daf0: pid 11 "idle: cpu3"
> switchticks  = 37193321
> 
> cpuid        = 2
> curthread    = 0xc633d8c0: pid 12 "idle: cpu2"
> curpcb       = 0xe4f10d90
> fpcurthread  = none
> idlethread   = 0xc633d8c0: pid 12 "idle: cpu2"
> switchticks  = 37193374
> 
> cpuid        = 1
> curthread    = 0xc633d690: pid 13 "idle: cpu1"
> curpcb       = 0xe4f13d90
> fpcurthread  = none
> idlethread   = 0xc633d690: pid 13 "idle: cpu1"
> switchticks  = 37193374
> 
> cpuid        = 0
> curthread    = 0xc64f68c0: pid 48980 "sh"
> curpcb       = 0xe8d6ed90
> fpcurthread  = none
> idlethread   = 0xc633d460: pid 14 "idle: cpu0"
> switchticks  = 37193321
> 
> (kgdb) ps
>   pid  ppid  pgrp   uid   state   wmesg     wchan    cmd
> 48980 48975 48975     0  RE      CPU  0              sh
> 48978 48976 48976     0  R                           megarc
> 48976 48973 48976     0  Ss      wait     0xc826e570 sh
> 48975 48972 48975     0  Rs      CPU  3              sh
> 48973   705   705     0  S       piperd   0xc8303318 cron
> 48972   705   705     0  S       piperd   0xc674a18c cron
> 48267 18141 18141    80  S       lockf    0xc83922c0 httpd
> 48266 18141 18141    80  S       lockf    0xc7d62400 httpd
> 48265 18141 18141    80  S       select   0xc0c4ecb8 httpd
> 48264 18141 18141    80  S       lockf    0xc7ceb240 httpd
> ...
> 
> At the moment of the crash megarc was run by cron (48973) at the same time
> other cron job was started (we have the following script set up to run in the
> same time:
> 
> if [ -x /usr/local/bin/vnstat ] && [ `ls -l /var/db/vnstat/ | wc -l` -ge 1 ]; then /usr/local/bin/vnstat -u; fi)
> 
> and this sh process caused panic on its exit when kernel was trying to remove
> its address space due to corrupted memory.
> 
> Should I add the comment to ports/137938 about this? I cc to Gerrit. Please
> note, we are using 7.1-RELEASE-p5 while in ports/137938 it is said that it was
> checked on 7.2. But it might be that Gerrit just did not test long enough? We
> had megarc enabled on several 7.1 hosts for some times and saw only this one
> panic (well, there was another one about a week ago, but it looked hardly
> related, because megarc was not running at the moment of the crash and the
> panic was when removing an entry from the namecache, I reported it to
> hackers@).
> 
> Below some details from gdb session in case someone is interested to look at
> this closer.
> 
> (kgdb) allchains 
> # no output
> 
> (kgdb) fr 5
> #5  0xc076b6ad in exit1 (td=0xc64f68c0, rv=0) at /usr/src/sys/kern/kern_exit.c:305
> 305             vmspace_exit(td);
> (kgdb) p *td->td_proc
> $1 = {p_list = {le_next = 0xc69a2570, le_prev = 0xc0c433f8}, p_threads = {tqh_first = 0xc64f68c0, 
>     tqh_last = 0xc64f68c8}, p_upcalls = {tqh_first = 0x0, tqh_last = 0xc6502838}, p_slock = {
>     lock_object = {lo_name = 0xc0b3b5ae "process slock", lo_type = 0xc0b3b5ae "process slock", 
>       lo_flags = 720896, lo_witness_data = {lod_list = {stqe_next = 0x0}, lod_witness = 0x0}}, 
>     mtx_lock = 4, mtx_recurse = 0}, p_ucred = 0xc708f700, p_fd = 0x0, p_fdtol = 0x0, 
>   p_stats = 0xc64f8000, p_limit = 0xc7c60800, p_limco = {c_links = {sle = {sle_next = 0x0}, tqe = {
>         tqe_next = 0x0, tqe_prev = 0x0}}, c_time = 0, c_arg = 0x0, c_func = 0, c_mtx = 0xc65028b8, 
>     c_flags = 0}, p_sigacts = 0xc7d00000, p_flag = 268443648, p_state = PRS_NORMAL, p_pid = 48980, 
>   p_hash = {le_next = 0x0, le_prev = 0xc632ad50}, p_pglist = {le_next = 0x0, le_prev = 0xc709b8a0}, 
>   p_pptr = 0xc709b828, p_sibling = {le_next = 0x0, le_prev = 0xc709b8b4}, p_children = {
>     lh_first = 0x0}, p_mtx = {lock_object = {lo_name = 0xc0b3b5a1 "process lock", 
>       lo_type = 0xc0b3b5a1 "process lock", lo_flags = 21168128, lo_witness_data = {lod_list = {
>           stqe_next = 0x0}, lod_witness = 0x0}}, mtx_lock = 4, mtx_recurse = 0}, p_ksi = 0xc6655cd0, 
>   p_sigqueue = {sq_signals = {__bits = {0, 0, 0, 0}}, sq_kill = {__bits = {0, 0, 0, 0}}, sq_list = {
>       tqh_first = 0x0, tqh_last = 0xc65028f4}, sq_proc = 0xc6502828, sq_flags = 1}, p_oppid = 0, 
>   p_vmspace = 0xc69ae658, p_swtick = 37193315, p_realtimer = {it_interval = {tv_sec = 0, tv_usec = 0}, 
>     it_value = {tv_sec = 0, tv_usec = 0}}, p_ru = {ru_utime = {tv_sec = 0, tv_usec = 0}, ru_stime = {
>       tv_sec = 0, tv_usec = 0}, ru_maxrss = 0, ru_ixrss = 0, ru_idrss = 0, ru_isrss = 0, ru_minflt = 0, 
>     ru_majflt = 0, ru_nswap = 0, ru_inblock = 0, ru_oublock = 0, ru_msgsnd = 0, ru_msgrcv = 0, 
>     ru_nsignals = 0, ru_nvcsw = 0, ru_nivcsw = 0}, p_rux = {rux_runtime = 0, rux_uticks = 0, 
>     rux_sticks = 0, rux_iticks = 0, rux_uu = 0, rux_su = 0, rux_tu = 0}, p_crux = {
>     rux_runtime = 20485868, rux_uticks = 0, rux_sticks = 0, rux_iticks = 0, rux_uu = 0, rux_su = 6784, 
>     rux_tu = 6784}, p_profthreads = 0, p_exitthreads = 0, p_traceflag = 0, p_tracevp = 0x0, 
>   p_tracecred = 0x0, p_textvp = 0xc66dce04, p_lock = 0 '\0', p_sigiolst = {slh_first = 0x0}, 
>   p_sigparent = 20, p_sig = 0, p_code = 0, p_stops = 0, p_stype = 0, p_step = 0 '\0', 
>   p_pfsflags = 0 '\0', p_nlminfo = 0x0, p_aioinfo = 0x0, p_singlethread = 0x0, p_suspcount = 0, 
>   p_xthread = 0x0, p_boundary_count = 0, p_pendingcnt = 0, p_itimers = 0x0, p_numupcalls = 0, 
>   p_upsleeps = 0, p_completed = 0x0, p_nextupcall = 0, p_upquantum = 0, p_magic = 3203398350, 
>   p_osrel = 701000, p_comm = "sh\000n\000er", '\0' <repeats 12 times>, p_pgrp = 0xc839c5c0, 
>   p_sysent = 0xc0c0a6e0, p_args = 0xc7c25b00, p_cpulimit = 9223372036854775807, p_nice = 0 '\0', 
>   p_fibnum = 0, p_xstat = 0, p_klist = {kl_list = {slh_first = 0x0}, 
>     kl_lock = 0xc0766af0 <knlist_mtx_lock>, kl_unlock = 0xc07664d0 <knlist_mtx_unlock>, 
>     kl_locked = 0xc07664b0 <knlist_mtx_locked>, kl_lockarg = 0xc65028b8}, p_numthreads = 1, p_md = {
>     md_ldt = 0x0}, p_itcallout = {c_links = {sle = {sle_next = 0x0}, tqe = {tqe_next = 0x0, 
>         tqe_prev = 0x0}}, c_time = 0, c_arg = 0x0, c_func = 0, c_mtx = 0x0, c_flags = 16}, 
>   p_acflag = 1, p_peers = 0x0, p_leader = 0xc6502828, p_emuldata = 0x0, p_label = 0x0, 
>   p_sched = 0xc6502ae0, p_ktr = {stqh_first = 0x0, stqh_last = 0xc6502ad0}, p_mqnotifier = {
>     lh_first = 0x0}, p_dtrace = 0x0}
> (kgdb) p *td
> $8 = {td_lock = 0xc0c4bcc0, td_proc = 0xc6502828, td_plist = {tqe_next = 0x0, tqe_prev = 0xc6502830}, 
>   td_slpq = {tqe_next = 0x0, tqe_prev = 0xc632f040}, td_lockq = {tqe_next = 0x0, 
>     tqe_prev = 0xe8ee6a6c}, td_selq = {tqh_first = 0x0, tqh_last = 0xc64f68e0}, 
>   td_sleepqueue = 0xc632f040, td_turnstile = 0xc68d6eb0, td_umtxq = 0xc64d8840, td_tid = 100094, 
>   td_sigqueue = {sq_signals = {__bits = {0, 0, 0, 0}}, sq_kill = {__bits = {0, 0, 0, 0}}, sq_list = {
>       tqh_first = 0x0, tqh_last = 0xc64f6918}, sq_proc = 0xc6502828, sq_flags = 1}, td_flags = 65542, 
>   td_inhibitors = 0, td_pflags = 0, td_dupfd = 0, td_sqqueue = 0, td_wchan = 0x0, td_wmesg = 0x0, 
>   td_lastcpu = 0 '\0', td_oncpu = 0 '\0', td_owepreempt = 0 '\0', td_locks = -2, td_tsqueue = 0 '\0', 
>   td_blocked = 0x0, td_lockname = 0x0, td_contested = {lh_first = 0x0}, td_sleeplocks = 0x0, 
>   td_intr_nesting_level = 0, td_pinned = 3, td_mailbox = 0x0, td_ucred = 0xc708f700, td_standin = 0x0, 
>   td_upcall = 0x0, td_estcpu = 0, td_slptick = 0, td_ru = {ru_utime = {tv_sec = 0, tv_usec = 0}, 
>     ru_stime = {tv_sec = 0, tv_usec = 0}, ru_maxrss = 1768, ru_ixrss = 1512, ru_idrss = 8792, 
>     ru_isrss = 1792, ru_minflt = 51, ru_majflt = 0, ru_nswap = 0, ru_inblock = 0, ru_oublock = 0, 
>     ru_msgsnd = 0, ru_msgrcv = 0, ru_nsignals = 0, ru_nvcsw = 2, ru_nivcsw = 1}, td_runtime = 3186278, 
>   td_pticks = 13, td_sticks = 14, td_iticks = 0, td_uticks = 0, td_uuticks = 0, td_usticks = 0, 
>   td_intrval = 0, td_oldsigmask = {__bits = {0, 0, 0, 0}}, td_sigmask = {__bits = {0, 0, 0, 0}}, 
>   td_generation = 3, td_sigstk = {ss_sp = 0x0, ss_size = 0, ss_flags = 4}, td_kflags = 0, td_xsig = 0, 
>   td_profil_addr = 0, td_profil_ticks = 0, td_name = '\0' <repeats 19 times>, td_base_pri = 134 '\206', 
>   td_priority = 134 '\206', td_pri_class = 3 '\003', td_user_pri = 144 '\220', 
>   td_base_user_pri = 144 '\220', td_pcb = 0xe8d6ed90, td_state = TDS_RUNNING, td_retval = {0, 
>     134598480}, td_slpcallout = {c_links = {sle = {sle_next = 0x0}, tqe = {tqe_next = 0x0, 
>         tqe_prev = 0xda3550f0}}, c_time = 34564372, c_arg = 0xc64f68c0, 
>     c_func = 0xc07c2f90 <sleepq_timeout>, c_mtx = 0x0, c_flags = 18}, td_frame = 0xe8d6ed38, 
>   td_kstack_obj = 0xc677e554, td_kstack = 3906392064, td_kstack_pages = 2, td_altkstack_obj = 0x0, 
>   td_altkstack = 0, td_altkstack_pages = 0, td_critnest = 0, td_md = {md_spinlock_count = 0, 
>     md_saved_flags = 70}, td_sched = 0xc64f6abc, td_ar = 0x0, td_syscalls = 75641, 
>   td_incruntime = 3186278, td_cpuset = 0xc6331e38, td_fpop = 0x0, td_dtrace = 0x0, td_errno = 0}
> 
> (kgdb) thr 126
> [Switching to thread 126 (Thread 100083)]#0  sched_switch (td=0xc674cd20, newtd=Variable "newtd" is not available.
> )
>     at /usr/src/sys/kern/sched_ule.c:1944
> 1944                    cpuid = PCPU_GET(cpuid);
> (kgdb) backtrace
> #0  sched_switch (td=0xc674cd20, newtd=Variable "newtd" is not available.
> ) at /usr/src/sys/kern/sched_ule.c:1944
> #1  0xc0799136 in mi_switch (flags=Variable "flags" is not available.
> ) at /usr/src/sys/kern/kern_synch.c:440
> #2  0xc07c284b in sleepq_switch (wchan=Variable "wchan" is not available.
> ) at /usr/src/sys/kern/subr_sleepqueue.c:497
> #3  0xc07c2e96 in sleepq_wait (wchan=0xc6492f28) at /usr/src/sys/kern/subr_sleepqueue.c:580
> #4  0xc07995a6 in _sleep (ident=0xc6492f28, lock=0xc647592c, priority=76, wmesg=0xc0b042bb "amrwcmd", 
>     timo=0) at /usr/src/sys/kern/kern_synch.c:226
> #5  0xc04e8ca4 in amr_wait_command (ac=0xc6492f28) at /usr/src/sys/dev/amr/amr.c:1392
> #6  0xc04e9faa in amr_ioctl (dev=0xc645e700, cmd=3224388353, addr=0xc7bb1c40 "\003", flag=1, 
>     td=0xc674cd20) at /usr/src/sys/dev/amr/amr.c:914
> #7  0xc0755d37 in giant_ioctl (dev=0xc645e700, cmd=3224388353, data=0xc7bb1c40 "\003", fflag=1, 
>     td=0xc674cd20) at /usr/src/sys/kern/kern_conf.c:408
> #8  0xc071ff47 in devfs_ioctl_f (fp=0xc707063c, com=3224388353, data=0xc7bb1c40, cred=0xc707a200, 
>     td=0xc674cd20) at /usr/src/sys/fs/devfs/devfs_vnops.c:595
> #9  0xc07c8005 in kern_ioctl (td=0xc674cd20, fd=4, com=3224388353, data=0xc7bb1c40 "\003") at file.h:268
> #10 0xc07c8164 in ioctl (td=0xc674cd20, uap=0xe8d33cfc) at /usr/src/sys/kern/sys_generic.c:570
> #11 0xc0aa81a5 in syscall (frame=0xe8d33d38) at /usr/src/sys/i386/i386/trap.c:1090
> #12 0xc0a8e6e0 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:255
> #13 0x00000033 in ?? ()
> Previous frame inner to this frame (corrupt stack?)
> 
> (kgdb) fr 4
> #4  0xc07995a6 in _sleep (ident=0xc6492f28, lock=0xc647592c, priority=76, wmesg=0xc0b042bb "amrwcmd", 
>     timo=0) at /usr/src/sys/kern/kern_synch.c:226
> 226                     sleepq_wait(ident);
> (kgdb) p *lock
> $2 = {lo_name = 0xc0b04655 "AMR List Lock", lo_type = 0xc0b04655 "AMR List Lock", lo_flags = 16973824, 
>   lo_witness_data = {lod_list = {stqe_next = 0x0}, lod_witness = 0x0}}
> 
> (kgdb) fr 5
> #5  0xc04e8ca4 in amr_wait_command (ac=0xc6492f28) at /usr/src/sys/dev/amr/amr.c:1392
> 1392            error = msleep(ac,&sc->amr_list_lock, PRIBIO, "amrwcmd", 0);
> (kgdb) p ac
> $3 = (struct amr_command *) 0xc6492f28
> (kgdb) p *ac
> $4 = {ac_link = {stqe_next = 0x0}, ac_sc = 0xc6475000, ac_slot = 118 'v', ac_status = 0, ac_sg = {
>     sg32 = 0xe6993fe0, sg64 = 0xe6993fe0}, ac_sgbusaddr = 21716960, ac_sg64_lo = 0, ac_sg64_hi = 0, 
>   ac_mailbox = {mb_command = 3 '\003', mb_ident = 119 'w', mb_blkcount = 0, mb_lba = 0, 
>     mb_physaddr = 21773056, mb_drive = 0 '\0', mb_nsgelem = 0 '\0', res1 = 0 '\0', mb_busy = 0 '\0', 
>     mb_nstatus = 0 '\0', mb_status = 0 '\0', mb_completed = '\0' <repeats 45 times>, mb_poll = 0 '\0', 
>     mb_ack = 0 '\0', res2 = '\0' <repeats 15 times>}, ac_flags = 71, ac_retries = 0, ac_bio = 0x0, 
>   ac_complete = 0, ac_private = 0x0, ac_data = 0xc672ac90, ac_length = 8, ac_dmamap = 0x0, 
>   ac_dma64map = 0x0, ac_tag = 0xc647c600, ac_datamap = 0x0, ac_nsegments = 0, 
>   ac_mb_physaddr = 27487376, ac_ccb = 0xe699eb00, ac_ccb_busaddr = 21773056}
> 
> (kgdb) fr 6
> #6  0xc04e9faa in amr_ioctl (dev=0xc645e700, cmd=3224388353, addr=0xc7bb1c40 "\003", flag=1, 
>     td=0xc674cd20) at /usr/src/sys/dev/amr/amr.c:914
> 914         error = amr_wait_command(ac);
> (kgdb) p *td
> $6 = {td_lock = 0xc0c4bcc0, td_proc = 0xc69a2570, td_plist = {tqe_next = 0x0, tqe_prev = 0xc69a2578}, 
>   td_slpq = {tqe_next = 0x0, tqe_prev = 0xc632f3e0}, td_lockq = {tqe_next = 0x0, 
>     tqe_prev = 0xe8fe9a6c}, td_selq = {tqh_first = 0x0, tqh_last = 0xc674cd40}, 
>   td_sleepqueue = 0xc632f3e0, td_turnstile = 0xc7c95460, td_umtxq = 0xc66a2500, td_tid = 100083, 
>   td_sigqueue = {sq_signals = {__bits = {0, 0, 0, 0}}, sq_kill = {__bits = {0, 0, 0, 0}}, sq_list = {
>       tqh_first = 0x0, tqh_last = 0xc674cd78}, sq_proc = 0xc69a2570, sq_flags = 1}, td_flags = 4, 
>   td_inhibitors = 0, td_pflags = 0, td_dupfd = -1, td_sqqueue = 0, td_wchan = 0x0, td_wmesg = 0x0, 
>   td_lastcpu = 1 '\001', td_oncpu = 255 '?', td_owepreempt = 0 '\0', td_locks = 6, td_tsqueue = 0 '\0', 
>   td_blocked = 0x0, td_lockname = 0x0, td_contested = {lh_first = 0x0}, td_sleeplocks = 0x0, 
>   td_intr_nesting_level = 0, td_pinned = 0, td_mailbox = 0x0, td_ucred = 0xc707a200, td_standin = 0x0, 
>   td_upcall = 0x0, td_estcpu = 0, td_slptick = 0, td_ru = {ru_utime = {tv_sec = 0, tv_usec = 0}, 
>     ru_stime = {tv_sec = 0, tv_usec = 0}, ru_maxrss = 0, ru_ixrss = 0, ru_idrss = 0, ru_isrss = 0, 
>     ru_minflt = 39, ru_majflt = 0, ru_nswap = 0, ru_inblock = 0, ru_oublock = 0, ru_msgsnd = 0, 
>     ru_msgrcv = 0, ru_nsignals = 0, ru_nvcsw = 9, ru_nivcsw = 1}, td_runtime = 6243427, td_pticks = 0, 
>   td_sticks = 0, td_iticks = 0, td_uticks = 0, td_uuticks = 0, td_usticks = 0, td_intrval = 0, 
>   td_oldsigmask = {__bits = {0, 0, 0, 0}}, td_sigmask = {__bits = {0, 0, 0, 0}}, td_generation = 10, 
>   td_sigstk = {ss_sp = 0x0, ss_size = 0, ss_flags = 4}, td_kflags = 0, td_xsig = 0, td_profil_addr = 0, 
>   td_profil_ticks = 0, td_name = '\0' <repeats 19 times>, td_base_pri = 76 'L', td_priority = 76 'L', 
>   td_pri_class = 3 '\003', td_user_pri = 128 '\200', td_base_user_pri = 128 '\200', 
>   td_pcb = 0xe8d33d90, td_state = TDS_CAN_RUN, td_retval = {0, 17}, td_slpcallout = {c_links = {sle = {
>         sle_next = 0xc0c3f8d0}, tqe = {tqe_next = 0xc0c3f8d0, tqe_prev = 0xda33fce8}}, 
>     c_time = 34422419, c_arg = 0xc674cd20, c_func = 0xc07c2f90 <sleepq_timeout>, c_mtx = 0x0, 
>     c_flags = 18}, td_frame = 0xe8d33d38, td_kstack_obj = 0xc68e9c1c, td_kstack = 3906150400, 
>   td_kstack_pages = 2, td_altkstack_obj = 0x0, td_altkstack = 0, td_altkstack_pages = 0, 
>   td_critnest = 1, td_md = {md_spinlock_count = 1, md_saved_flags = 582}, td_sched = 0xc674cf1c, 
>   td_ar = 0x0, td_syscalls = 99004, td_incruntime = 6243427, td_cpuset = 0xc6331e38, 
>   td_fpop = 0xc707063c, td_dtrace = 0x0, td_errno = 0}
> (kgdb) p *td->td_proc
> $7 = {p_list = {le_next = 0xc826e570, le_prev = 0xc6502828}, p_threads = {tqh_first = 0xc674cd20, 
>     tqh_last = 0xc674cd28}, p_upcalls = {tqh_first = 0x0, tqh_last = 0xc69a2580}, p_slock = {
>     lock_object = {lo_name = 0xc0b3b5ae "process slock", lo_type = 0xc0b3b5ae "process slock", 
>       lo_flags = 720896, lo_witness_data = {lod_list = {stqe_next = 0x0}, lod_witness = 0x0}}, 
>     mtx_lock = 4, mtx_recurse = 0}, p_ucred = 0xc707a200, p_fd = 0xc7c52d00, p_fdtol = 0x0, 
>   p_stats = 0xc674fd00, p_limit = 0xc7c34000, p_limco = {c_links = {sle = {sle_next = 0x0}, tqe = {
>         tqe_next = 0x0, tqe_prev = 0x0}}, c_time = 0, c_arg = 0x0, c_func = 0, c_mtx = 0xc69a2600, 
>     c_flags = 0}, p_sigacts = 0xc7c76000, p_flag = 268451840, p_state = PRS_NORMAL, p_pid = 48978, 
>   p_hash = {le_next = 0x0, le_prev = 0xc632ad48}, p_pglist = {le_next = 0x0, le_prev = 0xc826e5e8}, 
>   p_pptr = 0xc826e570, p_sibling = {le_next = 0x0, le_prev = 0xc826e5fc}, p_children = {
>     lh_first = 0x0}, p_mtx = {lock_object = {lo_name = 0xc0b3b5a1 "process lock", 
>       lo_type = 0xc0b3b5a1 "process lock", lo_flags = 21168128, lo_witness_data = {lod_list = {
>           stqe_next = 0x0}, lod_witness = 0x0}}, mtx_lock = 4, mtx_recurse = 0}, p_ksi = 0xc6656a00, 
>   p_sigqueue = {sq_signals = {__bits = {0, 0, 0, 0}}, sq_kill = {__bits = {0, 0, 0, 0}}, sq_list = {
>       tqh_first = 0x0, tqh_last = 0xc69a263c}, sq_proc = 0xc69a2570, sq_flags = 1}, p_oppid = 0, 
>   p_vmspace = 0xc6fb7488, p_swtick = 37193314, p_realtimer = {it_interval = {tv_sec = 0, tv_usec = 0}, 
>     it_value = {tv_sec = 0, tv_usec = 0}}, p_ru = {ru_utime = {tv_sec = 0, tv_usec = 0}, ru_stime = {
>       tv_sec = 0, tv_usec = 0}, ru_maxrss = 0, ru_ixrss = 0, ru_idrss = 0, ru_isrss = 0, ru_minflt = 0, 
>     ru_majflt = 0, ru_nswap = 0, ru_inblock = 0, ru_oublock = 0, ru_msgsnd = 0, ru_msgrcv = 0, 
>     ru_nsignals = 0, ru_nvcsw = 0, ru_nivcsw = 0}, p_rux = {rux_runtime = 0, rux_uticks = 0, 
>     rux_sticks = 0, rux_iticks = 0, rux_uu = 0, rux_su = 0, rux_tu = 0}, p_crux = {rux_runtime = 0, 
>     rux_uticks = 0, rux_sticks = 0, rux_iticks = 0, rux_uu = 0, rux_su = 0, rux_tu = 0}, 
>   p_profthreads = 0, p_exitthreads = 0, p_traceflag = 0, p_tracevp = 0x0, p_tracecred = 0x0, 
>   p_textvp = 0xc6f368a0, p_lock = 0 '\0', p_sigiolst = {slh_first = 0x0}, p_sigparent = 20, p_sig = 0, 
>   p_code = 0, p_stops = 0, p_stype = 0, p_step = 0 '\0', p_pfsflags = 0 '\0', p_nlminfo = 0x0, 
>   p_aioinfo = 0x0, p_singlethread = 0x0, p_suspcount = 0, p_xthread = 0x0, p_boundary_count = 0, 
>   p_pendingcnt = 0, p_itimers = 0x0, p_numupcalls = 0, p_upsleeps = 0, p_completed = 0x0, 
>   p_nextupcall = 0, p_upquantum = 0, p_magic = 3203398350, p_osrel = 502010, 
>   p_comm = "megarc", '\0' <repeats 13 times>, p_pgrp = 0xc839d140, p_sysent = 0xc0c0a6e0, 
>   p_args = 0xc7bd6a00, p_cpulimit = 9223372036854775807, p_nice = 0 '\0', p_fibnum = 0, p_xstat = 0, 
>   p_klist = {kl_list = {slh_first = 0x0}, kl_lock = 0xc0766af0 <knlist_mtx_lock>, 
>     kl_unlock = 0xc07664d0 <knlist_mtx_unlock>, kl_locked = 0xc07664b0 <knlist_mtx_locked>, 
>     kl_lockarg = 0xc69a2600}, p_numthreads = 1, p_md = {md_ldt = 0x0}, p_itcallout = {c_links = {sle = {
>         sle_next = 0x0}, tqe = {tqe_next = 0x0, tqe_prev = 0x0}}, c_time = 0, c_arg = 0x0, c_func = 0, 
>     c_mtx = 0x0, c_flags = 16}, p_acflag = 0, p_peers = 0x0, p_leader = 0xc69a2570, p_emuldata = 0x0, 
>   p_label = 0x0, p_sched = 0xc69a2828, p_ktr = {stqh_first = 0x0, stqh_last = 0xc69a2818}, 
>   p_mqnotifier = {lh_first = 0x0}, p_dtrace = 0x0}
> 
> I am keeping vmcore in case any additional output is needed.
> 

I run 7.2 and after seeing the note that megarc port should work on 7.2 
I re-synced the source and installed it on a production server.

I ran megarc just once, and the server locked up within 8 hours while 
under very light load.  I was not able to confirm the crash was related 
to megarc, but since it was the first server crash since 7.2 came out 
and I strongly suspect megarc.

From bahamasfranks at gmail.com  Fri Sep 25 16:15:49 2009
From: bahamasfranks at gmail.com (Steve Franks)
Date: Fri Sep 25 16:15:55 2009
Subject: 8-RC1: ral0: need multicast update callback
Message-ID: <539c60b90909250847j392d9002kf3daebeb7f2b143f@mail.gmail.com>

On my vanilla RC1 install (from ISO), ral seems to be having issues.
About every 1/2 hour it will hang the network when downloading ports,
or doing a large rsync transfer.  If you ctrl-c on the transfer &
restart, it fires right up.

The only error:
ral0: need multicast update callback

Exact chipset:
ral0: <Ralink Technology RT2561S> mem 0xf0200000-0xf0207fff irq 20 at
device 0.0 on pci3
ral0: MAC/BBP RT2561C, RF RT2527
ral0: [ITHREAD]

I noticed some people having this problem with ndis and iwi in 2008
(!) on the list, but no mention of ral...

Best,
Steve
From alc at cs.rice.edu  Fri Sep 25 17:38:32 2009
From: alc at cs.rice.edu (Alan Cox)
Date: Fri Sep 25 17:38:41 2009
Subject: 8.0-RC1 panic attaching ppc
In-Reply-To: <200909250957.06252.jhb@freebsd.org>
References: <200909232322.51060.doconnor@gsoft.com.au>
	<200909240920.05027.jhb@freebsd.org>
	<200909251650.16283.doconnor@gsoft.com.au>
	<200909250957.06252.jhb@freebsd.org>
Message-ID: <4ABD000F.5080007@cs.rice.edu>

John Baldwin wrote:
> On Friday 25 September 2009 3:20:05 am Daniel O'Connor wrote:
>   
>> On Thu, 24 Sep 2009, John Baldwin wrote:
>>     
>>> Can you try this patch perhaps:
>>>
>>> Index: sys/amd64/isa/isa_dma.c
>>> ===================================================================
>>> --- isa_dma.c	(revision 197430)
>>> +++ isa_dma.c	(working copy)
>>>       
>> This patch fixes the panic for me.
>>
>> I haven't tried printing (don't have any device handy here).
>>     
>
> I wonder if pmap_extract(kernel_pmap) doesn't work with direct map addresses 
> for some reason?  I kind of find that hard to believe actually.  Alan, the 
> original panic was in pmap_extract(kernel_pmap, ...) calls in the isa_dma 
> code.  My patch that "fixes" the panic just changes them to pmap_kextract(). 
>
>   

Is this problem occurring on an AMD processor?

Alan

From alc at cs.rice.edu  Fri Sep 25 17:56:07 2009
From: alc at cs.rice.edu (Alan Cox)
Date: Fri Sep 25 17:56:14 2009
Subject: 8.0-RC1 panic attaching ppc
In-Reply-To: <200909250957.06252.jhb@freebsd.org>
References: <200909232322.51060.doconnor@gsoft.com.au>
	<200909240920.05027.jhb@freebsd.org>
	<200909251650.16283.doconnor@gsoft.com.au>
	<200909250957.06252.jhb@freebsd.org>
Message-ID: <4ABCFDB0.3010302@cs.rice.edu>

John Baldwin wrote:
> On Friday 25 September 2009 3:20:05 am Daniel O'Connor wrote:
>   
>> On Thu, 24 Sep 2009, John Baldwin wrote:
>>     
>>> Can you try this patch perhaps:
>>>
>>> Index: sys/amd64/isa/isa_dma.c
>>> ===================================================================
>>> --- isa_dma.c	(revision 197430)
>>> +++ isa_dma.c	(working copy)
>>>       
>> This patch fixes the panic for me.
>>
>> I haven't tried printing (don't have any device handy here).
>>     
>
> I wonder if pmap_extract(kernel_pmap) doesn't work with direct map addresses 
> for some reason?  I kind of find that hard to believe actually.  Alan, the 
> original panic was in pmap_extract(kernel_pmap, ...) calls in the isa_dma 
> code.  My patch that "fixes" the panic just changes them to pmap_kextract(). 
>
>   

In principle, pmap_extract(kernel_pmap, ...) should work just fine.

Alan

From xcllnt at mac.com  Fri Sep 25 18:39:13 2009
From: xcllnt at mac.com (Marcel Moolenaar)
Date: Fri Sep 25 18:39:28 2009
Subject: 8.0-RC1: kernel page fault in NLM master thread (VIMAGE or ZFS
 related?)
Message-ID: <FD184B4B-517F-470E-BAC8-DD0795983C2B@mac.com>

All,

I just got this overnight on my server:

Fatal trap 12: page fault while in kernel mode
fault virtual address	= 0x90
fault code		= supervisor read, page not present
instruction pointer	= 0x20:0xc05ba39d
stack pointer	        = 0x28:0xf31077bc
frame pointer	        = 0x28:0xf31077c8
code segment		= base 0x0, limit 0xfffff, type 0x1b
			= DPL 0, pres 1, def32 1, gran 1
processor eflags	= interrupt enabled, resume, IOPL = 0
current process		= 928 (NLM: master)

(kgdb) bt
#0  doadump () at pcpu.h:246
#1  0xc05e03f3 in boot (howto=260) at /zmirror/nfs/freebsd/base/stable/ 
8/sys/kern/kern_shutdown.c:416
#2  0xc05e062d in panic (fmt=Variable "fmt" is not available.
) at /zmirror/nfs/freebsd/base/stable/8/sys/kern/kern_shutdown.c:579
#3  0xc04ac807 in db_panic (addr=Could not find the frame base for  
"db_panic".
) at /zmirror/nfs/freebsd/base/stable/8/sys/ddb/db_command.c:478
#4  0xc04acd91 in db_command (last_cmdp=0xc0881c3c, cmd_table=0x0,  
dopager=1) at /zmirror/nfs/freebsd/base/stable/8/sys/ddb/db_command.c: 
445
#5  0xc04aceea in db_command_loop () at /zmirror/nfs/freebsd/base/ 
stable/8/sys/ddb/db_command.c:498
#6  0xc04aed5d in db_trap (type=12, code=0) at /zmirror/nfs/freebsd/ 
base/stable/8/sys/ddb/db_main.c:229
#7  0xc0608a14 in kdb_trap (type=12, code=0, tf=0xf310777c) at / 
zmirror/nfs/freebsd/base/stable/8/sys/kern/subr_kdb.c:535
#8  0xc07c53af in trap_fatal (frame=0xf310777c, eva=144) at /zmirror/ 
nfs/freebsd/base/stable/8/sys/i386/i386/trap.c:924
#9  0xc07c5650 in trap_pfault (frame=0xf310777c, usermode=0, eva=144)  
at /zmirror/nfs/freebsd/base/stable/8/sys/i386/i386/trap.c:846
#10 0xc07c5ff2 in trap (frame=0xf310777c) at /zmirror/nfs/freebsd/base/ 
stable/8/sys/i386/i386/trap.c:528
#11 0xc07ac50b in calltrap () at /zmirror/nfs/freebsd/base/stable/8/ 
sys/i386/i386/exception.s:165
#12 0xc05ba39d in prison_priv_check (cred=0xc61e4880, priv=334) at / 
zmirror/nfs/freebsd/base/stable/8/sys/kern/kern_jail.c:3568
#13 0xc05d39ee in priv_check_cred (cred=0xc61e4880, priv=334, flags=0)  
at /zmirror/nfs/freebsd/base/stable/8/sys/kern/kern_priv.c:92
#14 0xc09dbffc in secpolicy_fs_owner (mp=0xc4112284, cred=0xc61e4880)  
at /zmirror/nfs/freebsd/base/stable/8/sys/modules/zfs/../../cddl/ 
compat/opensolaris/kern/opensolaris_policy.c:86
#15 0xc09dc527 in secpolicy_vnode_access (cred=0xc61e4880,  
vp=0xc4bb6d9c, owner=501, accmode=128)
     at /zmirror/nfs/freebsd/base/stable/8/sys/modules/zfs/../../cddl/ 
compat/opensolaris/kern/opensolaris_policy.c:125
#16 0xc0a56c5c in zfs_zaccess (zp=0xd4be8658, mode=2, flags=Variable  
"flags" is not available.
) at /zmirror/nfs/freebsd/base/stable/8/sys/modules/zfs/../../cddl/ 
contrib/opensolaris/uts/common/fs/zfs/zfs_acl.c:2445
#17 0xc0a56edb in zfs_zaccess_rwx (zp=0xd4be8658, mode=Variable "mode"  
is not available.
) at /zmirror/nfs/freebsd/base/stable/8/sys/modules/zfs/../../cddl/ 
contrib/opensolaris/uts/common/fs/zfs/zfs_acl.c:2484
#18 0xc0a6bfa4 in zfs_freebsd_access (ap=0xf31078d4) at /zmirror/nfs/ 
freebsd/base/stable/8/sys/modules/zfs/../../cddl/contrib/opensolaris/ 
uts/common/fs/zfs/zfs_vnops.c:1068
#19 0xc07cfeb2 in VOP_ACCESS_APV (vop=0xc0acfac0, a=0xf31078d4) at  
vnode_if.c:571
#20 0xc0718c93 in nlm_get_vfs_state (host=Variable "host" is not  
available.
) at vnode_if.h:254
#21 0xc0718e30 in nlm_do_unlock (argp=0xf31079c8, result=0xf3107a08,  
rqstp=0xcb199800, rpcp=0x0) at /zmirror/nfs/freebsd/base/stable/8/sys/ 
nlm/nlm_prot_impl.c:2227
#22 0xc071ac87 in nlm4_unlock_4_svc (argp=0xf31079c8,  
result=0xf3107a08, rqstp=0xcb199800) at /zmirror/nfs/freebsd/base/ 
stable/8/sys/nlm/nlm_prot_server.c:540
#23 0xc071bce3 in nlm_prog_4 (rqstp=0xcb199800, transp=0xc652de00) at / 
zmirror/nfs/freebsd/base/stable/8/sys/nlm/nlm_prot_svc.c:512
#24 0xc07284bf in svc_run_internal (pool=0xc61e4c80, ismaster=1) at / 
zmirror/nfs/freebsd/base/stable/8/sys/rpc/svc.c:893
#25 0xc072943d in svc_run (pool=0xc61e4c80) at /zmirror/nfs/freebsd/ 
base/stable/8/sys/rpc/svc.c:1233
#26 0xc071a348 in nlm_syscall (td=0xc6551000, uap=0xf3107cf8) at / 
zmirror/nfs/freebsd/base/stable/8/sys/nlm/nlm_prot_impl.c:1593
#27 0xc07c5977 in syscall (frame=0xf3107d38) at /zmirror/nfs/freebsd/ 
base/stable/8/sys/i386/i386/trap.c:1073
#28 0xc07ac570 in Xint0x80_syscall () at /zmirror/nfs/freebsd/base/ 
stable/8/sys/i386/i386/exception.s:261
#29 0x00000033 in ?? ()

(kgdb) frame 12
#12 0xc05ba39d in prison_priv_check (cred=0xc61e4880, priv=334) at / 
zmirror/nfs/freebsd/base/stable/8/sys/kern/kern_jail.c:3568
3568		switch (priv) {
(kgdb) l 3567
3562		 */
3563			if (cred->cr_prison->pr_flags & PR_VNET)
3564				return (0);
3565		}
3566	#endif /* VIMAGE */
3567	
3568		switch (priv) {
3569	
3570			/*
3571			 * Allow ktrace privileges for root in jail.
(kgdb) p cred->cr_prison
$4 = (struct prison *) 0x0

-- 
Marcel Moolenaar
xcllnt@mac.com



From doconnor at gsoft.com.au  Fri Sep 25 22:55:06 2009
From: doconnor at gsoft.com.au (Daniel O'Connor)
Date: Fri Sep 25 22:55:13 2009
Subject: 8.0-RC1 panic attaching ppc
In-Reply-To: <4ABD000F.5080007@cs.rice.edu>
References: <200909232322.51060.doconnor@gsoft.com.au>
	<200909250957.06252.jhb@freebsd.org> <4ABD000F.5080007@cs.rice.edu>
Message-ID: <200909260824.39985.doconnor@gsoft.com.au>

On Sat, 26 Sep 2009, Alan Cox wrote:
> John Baldwin wrote:
> > On Friday 25 September 2009 3:20:05 am Daniel O'Connor wrote:
> >> On Thu, 24 Sep 2009, John Baldwin wrote:
> >>> Can you try this patch perhaps:
> >>>
> >>> Index: sys/amd64/isa/isa_dma.c
> >>> =================================================================
> >>>== --- isa_dma.c	(revision 197430)
> >>> +++ isa_dma.c	(working copy)
> >>
> >> This patch fixes the panic for me.
> >>
> >> I haven't tried printing (don't have any device handy here).
> >
> > I wonder if pmap_extract(kernel_pmap) doesn't work with direct map
> > addresses for some reason?  I kind of find that hard to believe
> > actually.  Alan, the original panic was in
> > pmap_extract(kernel_pmap, ...) calls in the isa_dma code.  My patch
> > that "fixes" the panic just changes them to pmap_kextract().
>
> Is this problem occurring on an AMD processor?

Yes,
CPU: AMD Athlon(tm) II X2 240 Processor (2812.73-MHz K8-class CPU)
  Origin = "AuthenticAMD"  Id = 0x100f62  Stepping = 2
  Features=0x178bfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT>
  Features2=0x802009<SSE3,MON,CX16,POPCNT>
  AMD Features=0xee500800<SYSCALL,NX,MMX+,FFXSR,Page1GB,RDTSCP,LM,3DNow!+,3DNow!>
  AMD Features2=0x37ff<LAHF,CMP,SVM,ExtAPIC,CR8,ABM,SSE4A,MAS,Prefetch,OSVW,IBS,SKINIT,WDT>
  TSC: P-state invariant
real memory  = 4294967296 (4096 MB)
avail memory = 3974762496 (3790 MB)

-- 
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
  -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090925/87fded44/attachment.pgp
From doconnor at gsoft.com.au  Fri Sep 25 22:57:44 2009
From: doconnor at gsoft.com.au (Daniel O'Connor)
Date: Fri Sep 25 22:57:51 2009
Subject: 8.0-RC1 panic attaching ppc
In-Reply-To: <200909250957.06252.jhb@freebsd.org>
References: <200909232322.51060.doconnor@gsoft.com.au>
	<200909251650.16283.doconnor@gsoft.com.au>
	<200909250957.06252.jhb@freebsd.org>
Message-ID: <200909260827.38494.doconnor@gsoft.com.au>

On Fri, 25 Sep 2009, John Baldwin wrote:
> On Friday 25 September 2009 3:20:05 am Daniel O'Connor wrote:
> > On Thu, 24 Sep 2009, John Baldwin wrote:
> > > Can you try this patch perhaps:
> > >
> > > Index: sys/amd64/isa/isa_dma.c
> > > =================================================================
> > >== --- isa_dma.c	(revision 197430)
> > > +++ isa_dma.c	(working copy)
> >
> > This patch fixes the panic for me.
> >
> > I haven't tried printing (don't have any device handy here).
>
> I wonder if pmap_extract(kernel_pmap) doesn't work with direct map
> addresses for some reason?  I kind of find that hard to believe
> actually.  Alan, the original panic was in pmap_extract(kernel_pmap,
> ...) calls in the isa_dma code.  My patch that "fixes" the panic just
> changes them to pmap_kextract().

Well, if you want to test it some how let me know :)

-- 
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
  -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090925/781d652c/attachment.pgp
From jamie at FreeBSD.org  Fri Sep 25 23:13:37 2009
From: jamie at FreeBSD.org (Jamie Gritton)
Date: Fri Sep 25 23:13:44 2009
Subject: 8.0-RC1: kernel page fault in NLM master thread (VIMAGE or ZFS
 related?)
In-Reply-To: <FD184B4B-517F-470E-BAC8-DD0795983C2B@mac.com>
References: <FD184B4B-517F-470E-BAC8-DD0795983C2B@mac.com>
Message-ID: <4ABD4BB9.1030804@FreeBSD.org>

Marcel Moolenaar wrote:
> All,
> 
> I just got this overnight on my server:
> 
> Fatal trap 12: page fault while in kernel mode
> fault virtual address    = 0x90
> fault code        = supervisor read, page not present
> instruction pointer    = 0x20:0xc05ba39d
> stack pointer            = 0x28:0xf31077bc
> frame pointer            = 0x28:0xf31077c8
> code segment        = base 0x0, limit 0xfffff, type 0x1b
>             = DPL 0, pres 1, def32 1, gran 1
> processor eflags    = interrupt enabled, resume, IOPL = 0
> current process        = 928 (NLM: master)
> 
> (kgdb) bt
> #0  doadump () at pcpu.h:246
> #1  0xc05e03f3 in boot (howto=260) at 
> /zmirror/nfs/freebsd/base/stable/8/sys/kern/kern_shutdown.c:416
> #2  0xc05e062d in panic (fmt=Variable "fmt" is not available.
> ) at /zmirror/nfs/freebsd/base/stable/8/sys/kern/kern_shutdown.c:579
> #3  0xc04ac807 in db_panic (addr=Could not find the frame base for 
> "db_panic".
> ) at /zmirror/nfs/freebsd/base/stable/8/sys/ddb/db_command.c:478
> #4  0xc04acd91 in db_command (last_cmdp=0xc0881c3c, cmd_table=0x0, 
> dopager=1) at /zmirror/nfs/freebsd/base/stable/8/sys/ddb/db_command.c:445
> #5  0xc04aceea in db_command_loop () at 
> /zmirror/nfs/freebsd/base/stable/8/sys/ddb/db_command.c:498
> #6  0xc04aed5d in db_trap (type=12, code=0) at 
> /zmirror/nfs/freebsd/base/stable/8/sys/ddb/db_main.c:229
> #7  0xc0608a14 in kdb_trap (type=12, code=0, tf=0xf310777c) at 
> /zmirror/nfs/freebsd/base/stable/8/sys/kern/subr_kdb.c:535
> #8  0xc07c53af in trap_fatal (frame=0xf310777c, eva=144) at 
> /zmirror/nfs/freebsd/base/stable/8/sys/i386/i386/trap.c:924
> #9  0xc07c5650 in trap_pfault (frame=0xf310777c, usermode=0, eva=144) at 
> /zmirror/nfs/freebsd/base/stable/8/sys/i386/i386/trap.c:846
> #10 0xc07c5ff2 in trap (frame=0xf310777c) at 
> /zmirror/nfs/freebsd/base/stable/8/sys/i386/i386/trap.c:528
> #11 0xc07ac50b in calltrap () at 
> /zmirror/nfs/freebsd/base/stable/8/sys/i386/i386/exception.s:165
> #12 0xc05ba39d in prison_priv_check (cred=0xc61e4880, priv=334) at 
> /zmirror/nfs/freebsd/base/stable/8/sys/kern/kern_jail.c:3568
> #13 0xc05d39ee in priv_check_cred (cred=0xc61e4880, priv=334, flags=0) 
> at /zmirror/nfs/freebsd/base/stable/8/sys/kern/kern_priv.c:92
> #14 0xc09dbffc in secpolicy_fs_owner (mp=0xc4112284, cred=0xc61e4880) at 
> /zmirror/nfs/freebsd/base/stable/8/sys/modules/zfs/../../cddl/compat/opensolaris/kern/opensolaris_policy.c:86 
> 
> #15 0xc09dc527 in secpolicy_vnode_access (cred=0xc61e4880, 
> vp=0xc4bb6d9c, owner=501, accmode=128)
>     at 
> /zmirror/nfs/freebsd/base/stable/8/sys/modules/zfs/../../cddl/compat/opensolaris/kern/opensolaris_policy.c:125 
> 
> #16 0xc0a56c5c in zfs_zaccess (zp=0xd4be8658, mode=2, flags=Variable 
> "flags" is not available.
> ) at 
> /zmirror/nfs/freebsd/base/stable/8/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_acl.c:2445 
> 
> #17 0xc0a56edb in zfs_zaccess_rwx (zp=0xd4be8658, mode=Variable "mode" 
> is not available.
> ) at 
> /zmirror/nfs/freebsd/base/stable/8/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_acl.c:2484 
> 
> #18 0xc0a6bfa4 in zfs_freebsd_access (ap=0xf31078d4) at 
> /zmirror/nfs/freebsd/base/stable/8/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:1068 
> 
> #19 0xc07cfeb2 in VOP_ACCESS_APV (vop=0xc0acfac0, a=0xf31078d4) at 
> vnode_if.c:571
> #20 0xc0718c93 in nlm_get_vfs_state (host=Variable "host" is not available.
> ) at vnode_if.h:254
> #21 0xc0718e30 in nlm_do_unlock (argp=0xf31079c8, result=0xf3107a08, 
> rqstp=0xcb199800, rpcp=0x0) at 
> /zmirror/nfs/freebsd/base/stable/8/sys/nlm/nlm_prot_impl.c:2227
> #22 0xc071ac87 in nlm4_unlock_4_svc (argp=0xf31079c8, result=0xf3107a08, 
> rqstp=0xcb199800) at 
> /zmirror/nfs/freebsd/base/stable/8/sys/nlm/nlm_prot_server.c:540
> #23 0xc071bce3 in nlm_prog_4 (rqstp=0xcb199800, transp=0xc652de00) at 
> /zmirror/nfs/freebsd/base/stable/8/sys/nlm/nlm_prot_svc.c:512
> #24 0xc07284bf in svc_run_internal (pool=0xc61e4c80, ismaster=1) at 
> /zmirror/nfs/freebsd/base/stable/8/sys/rpc/svc.c:893
> #25 0xc072943d in svc_run (pool=0xc61e4c80) at 
> /zmirror/nfs/freebsd/base/stable/8/sys/rpc/svc.c:1233
> #26 0xc071a348 in nlm_syscall (td=0xc6551000, uap=0xf3107cf8) at 
> /zmirror/nfs/freebsd/base/stable/8/sys/nlm/nlm_prot_impl.c:1593
> #27 0xc07c5977 in syscall (frame=0xf3107d38) at 
> /zmirror/nfs/freebsd/base/stable/8/sys/i386/i386/trap.c:1073
> #28 0xc07ac570 in Xint0x80_syscall () at 
> /zmirror/nfs/freebsd/base/stable/8/sys/i386/i386/exception.s:261
> #29 0x00000033 in ?? ()
> 
> (kgdb) frame 12
> #12 0xc05ba39d in prison_priv_check (cred=0xc61e4880, priv=334) at 
> /zmirror/nfs/freebsd/base/stable/8/sys/kern/kern_jail.c:3568
> 3568        switch (priv) {
> (kgdb) l 3567
> 3562         */
> 3563            if (cred->cr_prison->pr_flags & PR_VNET)
> 3564                return (0);
> 3565        }
> 3566    #endif /* VIMAGE */
> 3567   
> 3568        switch (priv) {
> 3569   
> 3570            /*
> 3571             * Allow ktrace privileges for root in jail.
> (kgdb) p cred->cr_prison
> $4 = (struct prison *) 0x0

It seems to be NFS related.  I think the null pointer in question is
from the export's anonymous credential.  Try the patch below and see
if it helps (which I guess means run it overnight and see if it
crashes again).  I've also patched a similar missing cred prison in
GSS_SVC, since I'm not versed enough in NFS/RPC stuff to know if it
might be the problem.

- Jamie


Index: kern/vfs_export.c
===================================================================
--- kern/vfs_export.c	(revision 197506)
+++ kern/vfs_export.c	(working copy)
@@ -122,6 +122,8 @@
  		np->netc_anon->cr_uid = argp->ex_anon.cr_uid;
  		crsetgroups(np->netc_anon, argp->ex_anon.cr_ngroups,
  		    argp->ex_anon.cr_groups);
+		np->netc_anon->cr_prison = &prison0;
+		prison_hold(np->netc_anon->cr_prison);
  		np->netc_numsecflavors = argp->ex_numsecflavors;
  		bcopy(argp->ex_secflavors, np->netc_secflavors,
  		    sizeof(np->netc_secflavors));
@@ -206,6 +208,8 @@
  	np->netc_anon->cr_uid = argp->ex_anon.cr_uid;
  	crsetgroups(np->netc_anon, argp->ex_anon.cr_ngroups,
  	    np->netc_anon->cr_groups);
+	np->netc_anon->cr_prison = &prison0;
+	prison_hold(np->netc_anon->cr_prison);
  	np->netc_numsecflavors = argp->ex_numsecflavors;
  	bcopy(argp->ex_secflavors, np->netc_secflavors,
  	    sizeof(np->netc_secflavors));
Index: rpc/rpcsec_gss/svc_rpcsec_gss.c
===================================================================
--- rpc/rpcsec_gss/svc_rpcsec_gss.c	(revision 197506)
+++ rpc/rpcsec_gss/svc_rpcsec_gss.c	(working copy)
@@ -449,6 +449,8 @@
  	cr->cr_uid = cr->cr_ruid = cr->cr_svuid = uc->uid;
  	cr->cr_rgid = cr->cr_svgid = uc->gid;
  	crsetgroups(cr, uc->gidlen, uc->gidlist);
+	cr->cr_prison = &prison0;
+	prison_hold(cr->cr_prison);
  	*crp = crhold(cr);

  	return (TRUE);
From lambert at lambertfam.org  Fri Sep 25 23:29:23 2009
From: lambert at lambertfam.org (Scott Lambert)
Date: Fri Sep 25 23:29:30 2009
Subject: 8-RC1: ral0: need multicast update callback
In-Reply-To: <539c60b90909250847j392d9002kf3daebeb7f2b143f@mail.gmail.com>
References: <539c60b90909250847j392d9002kf3daebeb7f2b143f@mail.gmail.com>
Message-ID: <20090925232922.GE4858@sysmon.tcworks.net>

On Fri, Sep 25, 2009 at 08:47:38AM -0700, Steve Franks wrote:
> On my vanilla RC1 install (from ISO), ral seems to be having issues.
> About every 1/2 hour it will hang the network when downloading ports,
> or doing a large rsync transfer.  If you ctrl-c on the transfer &
> restart, it fires right up.
> 
> The only error:
> ral0: need multicast update callback
> 
> I noticed some people having this problem with ndis and iwi in 2008
> (!) on the list, but no mention of ral...

I've been seeing pauses in network connectivity with my iwn
in BETA-2 through 4.  I hadn't noticed it much until I set
"wpa_ptk_rekey=NNNN" down to 600.  Then it seemed like it hit me
every five minutes.  I think it was originally 1800.  But the
/usr/share/examples/etc/wpa_supplicant.conf, currently has it at 600 in
-RC1.  I could be remembering incorrectly.  It seems like it became much
less frequent when I changed wpa_ptk_rekey to 3600.

Maybe I just started noticing when I had to start doing a lot of ssh
sessions from the house.  My sessions would lock up and, usually,
continue in a few seconds to a few minutes.  If I hadn't been using a
session when the network paused, that session would usually be working
fine while I waited for my original session to continue.

I have not noticed it on my WEP AP, but I normally connect the ethernet
cable at that location.  I should test there. 

I have other issues with the iwn and haven't really dug into the problem
to try to figure out if it is wpa_supplicant or iwn or a combination.
iwn does not function after resume so I've actually run ethernet cables
to where I use the laptop now.

-- 
Scott Lambert                    KC5MLE                       Unix SysAdmin
lambert@lambertfam.org

From xcllnt at mac.com  Fri Sep 25 23:53:21 2009
From: xcllnt at mac.com (Marcel Moolenaar)
Date: Fri Sep 25 23:53:28 2009
Subject: 8.0-RC1: kernel page fault in NLM master thread (VIMAGE or ZFS
 related?)
In-Reply-To: <4ABD4BB9.1030804@FreeBSD.org>
References: <FD184B4B-517F-470E-BAC8-DD0795983C2B@mac.com>
	<4ABD4BB9.1030804@FreeBSD.org>
Message-ID: <584F5511-DD82-4BBD-B243-7698E4831072@mac.com>


On Sep 25, 2009, at 4:01 PM, Jamie Gritton wrote:
>> (kgdb) p cred->cr_prison
>> $4 = (struct prison *) 0x0
>
> It seems to be NFS related.  I think the null pointer in question is
> from the export's anonymous credential.  Try the patch below and see
> if it helps (which I guess means run it overnight and see if it
> crashes again).

Thanks. I'll give it a spin...

-- 
Marcel Moolenaar
xcllnt@mac.com



From jamesbrandongooch at gmail.com  Sat Sep 26 03:00:25 2009
From: jamesbrandongooch at gmail.com (Brandon Gooch)
Date: Sat Sep 26 03:00:31 2009
Subject: 8-RC1: ral0: need multicast update callback
In-Reply-To: <20090925232922.GE4858@sysmon.tcworks.net>
References: <539c60b90909250847j392d9002kf3daebeb7f2b143f@mail.gmail.com>
	<20090925232922.GE4858@sysmon.tcworks.net>
Message-ID: <179b97fb0909251933u6a415aden43b86a131698e749@mail.gmail.com>

On Fri, Sep 25, 2009 at 11:29 PM, Scott Lambert <lambert@lambertfam.org> wrote:
> iwn does not function after resume so I've actually run ethernet cables
> to where I use the laptop now.

I have to unload the if_iwn module on suspend, and reload it on resume
(via /etc/rc.[suspend|resume], of course).

Have you tried that?

-Brandon
From oliver at akephalos.de  Sat Sep 26 08:17:09 2009
From: oliver at akephalos.de (O.Herold)
Date: Sat Sep 26 08:17:16 2009
Subject: (no subject)
Message-ID: <92B888BB-4210-4E33-9CDB-66CA5366AD5C@akephalos.de>



pro bono publico
From christof.schulze at gmx.com  Sat Sep 26 13:25:23 2009
From: christof.schulze at gmx.com (Christof Schulze)
Date: Sat Sep 26 13:25:30 2009
Subject: various kde programs spin in a poll/read loop against their
	respective config files
Message-ID: <200909261525.18608.christof.schulze@gmx.com>

Hello everyone,

the discussion in -current and the behavior of my hard disk caused me to 
investigate. Whenever kde programs are run on this system, the hard disk 
will not spin down (even when excessive timeouts for syncs are in effect)
So I ran truss against kwallet and plasma-desktop to find out they do the 
same thing:

stat("/home/erika/.kde4/share/apps/kwallet",{ mode=drwx------ 
,inode=56314,size=3,blksize=4096 }) = 0 (0x0)
clock_gettime(4,{10454.430272035 })		 = 0 (0x0)
clock_gettime(4,{10454.430363671 })		 = 0 (0x0)
clock_gettime(4,{10454.430432397 })		 = 0 (0x0)
clock_gettime(4,{10454.430516490 })		 = 0 (0x0)
read(8,0x808f9102c,4096)			 ERR#35 'Resource temporarily 
unavailable'
poll({3/POLLIN 9/POLLIN 8/POLLIN 5/POLLIN},4,0)	 = 0 (0x0)
clock_gettime(4,{10454.430734403 })		 = 0 (0x0)
read(8,0x808f9102c,4096)			 ERR#35 'Resource temporarily 
unavailable'
clock_gettime(4,{10454.430882473 })		 = 0 (0x0)
read(8,0x808f9102c,4096)			 ERR#35 'Resource temporarily 
unavailable'
poll({3/POLLIN 9/POLLIN 8/POLLIN 5/POLLIN},4,499) = 0 (0x0)
clock_gettime(4,{10454.939752100 })		 = 0 (0x0)
read(8,0x808f9102c,4096)			 ERR#35 'Resource temporarily 
unavailable'
clock_gettime(4,{10454.939905198 })		 = 0 (0x0)
stat("/home/erika/.kde4/share/apps/kwallet",{ mode=drwx------ 
,inode=56314,size=3,blksize=4096 }) = 0 (0x0)
clock_gettime(4,{10454.940151049 })		 = 0 (0x0)
clock_gettime(4,{10454.940242126 })		 = 0 (0x0)
clock_gettime(4,{10454.940309456 })		 = 0 (0x0)
clock_gettime(4,{10454.940392710 })		 = 0 (0x0)
read(8,0x808f9102c,4096)			 ERR#35 'Resource temporarily 
unavailable'
poll({3/POLLIN 9/POLLIN 8/POLLIN 5/POLLIN},4,0)	 = 0 (0x0)
clock_gettime(4,{10454.940612580 })		 = 0 (0x0)
read(8,0x808f9102c,4096)			 ERR#35 'Resource temporarily 
unavailable'
clock_gettime(4,{10454.940760929 })		 = 0 (0x0)
read(8,0x808f9102c,4096)			 ERR#35 'Resource temporarily 
unavailable'


Shouldn't this be handled by fam/gamin in order to avoid this overhead? 
While it does not produce notable load it prevents my processor from 
saving power as well as spinning down the disks. I will gladly provide 
more information on this if necessary. 
This is a FreeBSD 7.2-STABLE FreeBSD 7.2-STABLE #0: Tue Jul  7 04:56:00 
CEST 2009     
root@ccschu935:/usr/obj/usr/src/sys/GENERIC  amd64
system


Regards

Christof
From tinderbox at freebsd.org  Sat Sep 26 15:55:06 2009
From: tinderbox at freebsd.org (FreeBSD Tinderbox)
Date: Sat Sep 26 15:55:24 2009
Subject: [releng_8 tinderbox] failure on ia64/ia64
Message-ID: <200909261555.n8QFt4b9058084@freebsd-current.sentex.ca>

TB --- 2009-09-26 15:45:35 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2009-09-26 15:45:35 - starting RELENG_8 tinderbox run for ia64/ia64
TB --- 2009-09-26 15:45:36 - cleaning the object tree
TB --- 2009-09-26 15:48:08 - cvsupping the source tree
TB --- 2009-09-26 15:48:08 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8/ia64/ia64/supfile
TB --- 2009-09-26 15:48:54 - building world
TB --- 2009-09-26 15:48:54 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-09-26 15:48:54 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-09-26 15:48:54 - TARGET=ia64
TB --- 2009-09-26 15:48:54 - TARGET_ARCH=ia64
TB --- 2009-09-26 15:48:54 - TZ=UTC
TB --- 2009-09-26 15:48:54 - __MAKE_CONF=/dev/null
TB --- 2009-09-26 15:48:54 - cd /src
TB --- 2009-09-26 15:48:54 - /usr/bin/make -B buildworld
>>> World build started on Sat Sep 26 15:48:56 UTC 2009
>>> Rebuilding the temporary build tree
>>> stage 1.1: legacy release compatibility shims
>>> stage 1.2: bootstrap tools
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3: cross tools
[...]
cc -O2 -pipe -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/obj/ia64/src/tmp/usr\" -DCROSS_COMPILE -I/obj/ia64/src/tmp/src/gnu/usr.bin/cc/cc_int/../cc_tools -I/src/gnu/usr.bin/cc/cc_int/../cc_tools -I/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc -I/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/config -I/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcclibs/include -I/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcclibs/libcpp/include -I/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcclibs/libdecnumber   -I/obj/ia64/src/tmp/legacy/usr/include -c /src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/cfganal.c
cc -O2 -pipe -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/obj/ia64/src/tmp/usr\" -DCROSS_COMPILE -I/obj/ia64/src/tmp/src/gnu/usr.bin/cc/cc_int/../cc_tools -I/src/gnu/usr.bin/cc/cc_int/../cc_tools -I/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc -I/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/config -I/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcclibs/include -I/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcclibs/libcpp/include -I/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcclibs/libdecnumber   -I/obj/ia64/src/tmp/legacy/usr/include -c /src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/cfgbuild.c
cc -O2 -pipe -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/obj/ia64/src/tmp/usr\" -DCROSS_COMPILE -I/obj/ia64/src/tmp/src/gnu/usr.bin/cc/cc_int/../cc_tools -I/src/gnu/usr.bin/cc/cc_int/../cc_tools -I/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc -I/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/config -I/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcclibs/include -I/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcclibs/libcpp/include -I/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcclibs/libdecnumber   -I/obj/ia64/src/tmp/legacy/usr/include -c /src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/cfgcleanup.c
/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/cfgcleanup.c: In function 'try_crossjump_to_edge':
/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/cfgcleanup.c:1601: internal compiler error: Segmentation fault: 11
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.
*** Error code 1

Stop in /src/gnu/usr.bin/cc/cc_int.
*** Error code 1

Stop in /src/gnu/usr.bin/cc.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
TB --- 2009-09-26 15:55:04 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2009-09-26 15:55:04 - ERROR: failed to build world
TB --- 2009-09-26 15:55:04 - 212.52 user 51.89 system 568.80 real


http://tinderbox.des.no/tinderbox-releng_8-RELENG_8-ia64-ia64.full
From chris at shenton.org  Sat Sep 26 19:22:46 2009
From: chris at shenton.org (Chris Shenton)
Date: Sat Sep 26 19:22:53 2009
Subject: How to upgrade kernel with gmirror boot?     
Message-ID: <86d45dh6jc.fsf@Boqueria.shenton.org>

I've got a couple FreeBSD 7.0 systems which I am trying to upgrade. I
had used ZFS for everything except the boot where I had used a gmirror.
I didn't really understand it all then, but it's been working fine.

The problem is that now with I "make buildworld" and "make
installkernel" I get the old original kernel, not the new one.  I
suspect it's because I'm not installing the kernel in the boot partition
that's actually being used, but am out of my depth here and need some
advice.

Here's how I created the gmirror and installed onto it back then, per my
notes. I had 2x 1TB drives and wanted to use a gmirror for the boot and
ZFS for the rest:

Did a minimal install onto a 1GB ad4s1a.
fdisk -BI ad6
bslabel ad4s1 > /tmp/label
bsdlabel -RB ad6s1 /tmp/label
gmirror label boot ad6s1a
newfs /dev/mirror/boot
mount /dev/mirror/boot /mnt
find -x / | cpio -pmd /mnt
rm -rf /mnt/var/* /mnt/usr/* /mnt/tmp/*
reboot
gmirror insert boot ad4s1a

Rebooting I believe is now booting from the gmirror comprised of ad4s1a
and ad6s1a:

$ df -h / /boot
Filesystem                   Size    Used   Avail Capacity  Mounted on
/dev/mirror/boot             989M    634M    276M    70%    /
/dev/mirror/boot             989M    634M    276M    70%    /

After "make installkernel" my /boot/GENERIC is still from 2008, when I
did the original installation.  My /boot/kernel is new, from the
installkernel.

What am I missing? It seems I am not "installkernel"-ing to the right place
where the boot loader is looking. 

Thanks.

PS: Current "gmirror list" output:

$ gmirror list
Geom name: boot
State: COMPLETE
Components: 1
Balance: split
Slice: 4096
Flags: NONE
GenID: 0
SyncID: 1
ID: 2728037890
Providers:
1. Name: mirror/boot
   Mediasize: 1073741312 (1.0G)
   Sectorsize: 512
   Mode: r1w1e1
Consumers:
1. Name: ad6s1a
   Mediasize: 1073741824 (1.0G)
   Sectorsize: 512
   Mode: r1w1e1
   State: ACTIVE
   Priority: 0
   Flags: NONE
   GenID: 0
   SyncID: 1
   ID: 2864447916
From alc at cs.rice.edu  Sat Sep 26 21:04:15 2009
From: alc at cs.rice.edu (Alan Cox)
Date: Sat Sep 26 21:04:22 2009
Subject: 8.0-RC1 panic attaching ppc
In-Reply-To: <200909260824.39985.doconnor@gsoft.com.au>
References: <200909232322.51060.doconnor@gsoft.com.au>
	<200909250957.06252.jhb@freebsd.org> <4ABD000F.5080007@cs.rice.edu>
	<200909260824.39985.doconnor@gsoft.com.au>
Message-ID: <4ABE81C5.2010009@cs.rice.edu>

Daniel O'Connor wrote:
> On Sat, 26 Sep 2009, Alan Cox wrote:
>   
>> John Baldwin wrote:
>>     
>>> On Friday 25 September 2009 3:20:05 am Daniel O'Connor wrote:
>>>       
>>>> On Thu, 24 Sep 2009, John Baldwin wrote:
>>>>         
>>>>> Can you try this patch perhaps:
>>>>>
>>>>> Index: sys/amd64/isa/isa_dma.c
>>>>> =================================================================
>>>>> == --- isa_dma.c	(revision 197430)
>>>>> +++ isa_dma.c	(working copy)
>>>>>           
>>>> This patch fixes the panic for me.
>>>>
>>>> I haven't tried printing (don't have any device handy here).
>>>>         
>>> I wonder if pmap_extract(kernel_pmap) doesn't work with direct map
>>> addresses for some reason?  I kind of find that hard to believe
>>> actually.  Alan, the original panic was in
>>> pmap_extract(kernel_pmap, ...) calls in the isa_dma code.  My patch
>>> that "fixes" the panic just changes them to pmap_kextract().
>>>       
>> Is this problem occurring on an AMD processor?
>>     
>
> Yes,
> CPU: AMD Athlon(tm) II X2 240 Processor (2812.73-MHz K8-class CPU)
>   Origin = "AuthenticAMD"  Id = 0x100f62  Stepping = 2
>   Features=0x178bfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT>
>   Features2=0x802009<SSE3,MON,CX16,POPCNT>
>   AMD Features=0xee500800<SYSCALL,NX,MMX+,FFXSR,Page1GB,RDTSCP,LM,3DNow!+,3DNow!>
>   AMD Features2=0x37ff<LAHF,CMP,SVM,ExtAPIC,CR8,ABM,SSE4A,MAS,Prefetch,OSVW,IBS,SKINIT,WDT>
>   TSC: P-state invariant
> real memory  = 4294967296 (4096 MB)
> avail memory = 3974762496 (3790 MB)
>
>   

Ok, now I can explain what is happening.  The kernel is using 1GB pages 
to implement the direct map.  Unfortunately, pmap_extract() doesn't know 
how to handle a 1GB page mapping.  pmap_kextract() only works by an 
"accident" of its different implementation.  In other words, it should 
not be relied upon to work either.

Please revert whatever patch John gave you and try the attached patch.  
It simply disables the use of 1GB page mapping by the direct map.

Regards,
Alan


-------------- next part --------------
Index: amd64/amd64/pmap.c
===================================================================
--- amd64/amd64/pmap.c	(revision 197425)
+++ amd64/amd64/pmap.c	(working copy)
@@ -442,7 +442,7 @@
 	if (ndmpdp < 4)		/* Minimum 4GB of dirmap */
 		ndmpdp = 4;
 	DMPDPphys = allocpages(firstaddr, NDMPML4E);
-	if ((amd_feature & AMDID_PAGE1GB) == 0)
+	if (TRUE || (amd_feature & AMDID_PAGE1GB) == 0)
 		DMPDphys = allocpages(firstaddr, ndmpdp);
 	dmaplimit = (vm_paddr_t)ndmpdp << PDPSHIFT;
 
@@ -476,7 +476,7 @@
 
 	/* Now set up the direct map space using either 2MB or 1GB pages */
 	/* Preset PG_M and PG_A because demotion expects it */
-	if ((amd_feature & AMDID_PAGE1GB) == 0) {
+	if (TRUE || (amd_feature & AMDID_PAGE1GB) == 0) {
 		for (i = 0; i < NPDEPG * ndmpdp; i++) {
 			((pd_entry_t *)DMPDphys)[i] = (vm_paddr_t)i << PDRSHIFT;
 			((pd_entry_t *)DMPDphys)[i] |= PG_RW | PG_V | PG_PS |
From graham at menhennitt.com.au  Sat Sep 26 21:57:43 2009
From: graham at menhennitt.com.au (Graham Menhennitt)
Date: Sat Sep 26 21:57:50 2009
Subject: ath0: stuck beacon; resetting (bmiss count 4)
In-Reply-To: <4A6020E1.9010600@menhennitt.com.au>
References: <4A6020E1.9010600@menhennitt.com.au>
Message-ID: <4ABE8E53.1050107@menhennitt.com.au>

Back in July, I asked the following on this list. I didn't get any replies.

I was running 7.2 at the time and the messages were coming up every
couple of minutes. Now I've upgraded to 8-RC1 and the same message is
coming out on the console every few seconds. The miss count limit is now
a sysctl tunable. I've increased it to 20 which slows the messages down
but they still happen. I then increased it to 2000 which has stopped
them completely. Although I did get a few "ath0: device timeout" messages.

It seems to work correctly as a WPA2 AP.

Below is the contents of my hostapd.conf and the relevant lines from
rc.conf. Is this something to worry about? Can I improve it any way?

Thanks for any help,
  Graham

hostapd.conf:
interface=wlan0
debug=1
ctrl_interface=/var/run/hostapd
ctrl_interface_group=wheel
ssid=Menhennitt
wpa=2
wpa_passphrase=xxxxx
wpa_key_mgmt=WPA-PSK
wpa_pairwise=CCMP

rc.conf:
ifconfig_wlan0="inet xx.xx.xx.xx/25"
wlans_ath0="wlan0"
create_args_wlan0="wlanmode hostap mode 11g"
hostapd_enable="YES"

Graham Menhennitt wrote:
> I'me getting the message "ath0: stuck beacon; resetting (bmiss count 4)"
> logged to syslog every so often. I have a Soekris net5501 with a Wistron
> CM9  mini-PCI wireless card. I'm running FreeBSD 7.2-stable and "dmesg |
> grep ath0" gives:
>
> ath0: <Atheros 5212> mem 0xa0010000-0xa001ffff irq 15 at device 17.0 on pci0
> ath0: [ITHREAD]
> ath0: WARNING: using obsoleted if_watchdog interface
> ath0: Ethernet address: 00:0b:6b:36:99:93
> ath0: mac 5.9 phy 4.3 radio 3.6
> ath0: ath_chan_set: unable to reset channel 6 (2437 Mhz, flags 0x490 hal
> flags 0x150), hal status 12
>
> I've seen Sam Leffler's reply to a previous question about the same log
> message at
> http://lists.freebsd.org/pipermail/freebsd-current/2009-March/004196.html.
>
> Looking at the source code of if_ath.c in stable:
>
> if (sc->sc_bmisscount > 3)        /* NB: 3 is a guess */
>             taskqueue_enqueue(sc->sc_tq, &sc->sc_bstucktask);\
>
> Now, in head the 3 has been made a variable but it doesn't seem to be
> able to be tuned in any reasonable way.
>
> I've tied increasing it to 20 and it doesn't seem to have any obvious
> bad effects.
>
> So, my questions:
> - is 3 really a good guess?
> - can it be increased safely?
> - what sort of values should I try?
> - are there any consequences of increasing it?
> - could it be made a sysctl tunable?
>   

From stb at lassitu.de  Sat Sep 26 22:20:02 2009
From: stb at lassitu.de (Stefan Bethke)
Date: Sat Sep 26 22:20:15 2009
Subject: How to upgrade kernel with gmirror boot?     
In-Reply-To: <86d45dh6jc.fsf@Boqueria.shenton.org>
References: <86d45dh6jc.fsf@Boqueria.shenton.org>
Message-ID: <E5F0AE90-F1C2-4038-979F-C52FCEB6D3C7@lassitu.de>

Am 26.09.2009 um 21:04 schrieb Chris Shenton:

> PS: Current "gmirror list" output:
>
> $ gmirror list
> Geom name: boot
> State: COMPLETE
> Components: 1
             ^^^

There's your problem: your mirror consist of only ad6s1a.  You need to  
add ad4s1a using gmirror insert, or tell your BIOS to boot from the  
second disk.


Stefan

-- 
Stefan Bethke <stb@lassitu.de>   Fon +49 151 14070811




From rwatson at FreeBSD.org  Sat Sep 26 23:47:20 2009
From: rwatson at FreeBSD.org (Robert Watson)
Date: Sat Sep 26 23:47:32 2009
Subject: 8.0-RC1: kernel page fault in NLM master thread (VIMAGE or ZFS
 related?)
In-Reply-To: <4ABD4BB9.1030804@FreeBSD.org>
References: <FD184B4B-517F-470E-BAC8-DD0795983C2B@mac.com>
	<4ABD4BB9.1030804@FreeBSD.org>
Message-ID: <alpine.BSF.2.00.0909270045590.31373@fledge.watson.org>


On Fri, 25 Sep 2009, Jamie Gritton wrote:

> It seems to be NFS related.  I think the null pointer in question is from 
> the export's anonymous credential.  Try the patch below and see if it helps 
> (which I guess means run it overnight and see if it crashes again).  I've 
> also patched a similar missing cred prison in GSS_SVC, since I'm not versed 
> enough in NFS/RPC stuff to know if it might be the problem.

This is one of the reasons I really dislike "magic" credentials and special 
handling of NULL credentials -- they always get into code the author doesn't 
expect, and either there are bad pointer dereferences, or incorrect security 
decisions.  It's almost always the case that a correct credential should have 
been cached or generated at some earlier point to represent the security 
context...

Robert

>
> - Jamie
>
>
> Index: kern/vfs_export.c
> ===================================================================
> --- kern/vfs_export.c	(revision 197506)
> +++ kern/vfs_export.c	(working copy)
> @@ -122,6 +122,8 @@
> 		np->netc_anon->cr_uid = argp->ex_anon.cr_uid;
> 		crsetgroups(np->netc_anon, argp->ex_anon.cr_ngroups,
> 		    argp->ex_anon.cr_groups);
> +		np->netc_anon->cr_prison = &prison0;
> +		prison_hold(np->netc_anon->cr_prison);
> 		np->netc_numsecflavors = argp->ex_numsecflavors;
> 		bcopy(argp->ex_secflavors, np->netc_secflavors,
> 		    sizeof(np->netc_secflavors));
> @@ -206,6 +208,8 @@
> 	np->netc_anon->cr_uid = argp->ex_anon.cr_uid;
> 	crsetgroups(np->netc_anon, argp->ex_anon.cr_ngroups,
> 	    np->netc_anon->cr_groups);
> +	np->netc_anon->cr_prison = &prison0;
> +	prison_hold(np->netc_anon->cr_prison);
> 	np->netc_numsecflavors = argp->ex_numsecflavors;
> 	bcopy(argp->ex_secflavors, np->netc_secflavors,
> 	    sizeof(np->netc_secflavors));
> Index: rpc/rpcsec_gss/svc_rpcsec_gss.c
> ===================================================================
> --- rpc/rpcsec_gss/svc_rpcsec_gss.c	(revision 197506)
> +++ rpc/rpcsec_gss/svc_rpcsec_gss.c	(working copy)
> @@ -449,6 +449,8 @@
> 	cr->cr_uid = cr->cr_ruid = cr->cr_svuid = uc->uid;
> 	cr->cr_rgid = cr->cr_svgid = uc->gid;
> 	crsetgroups(cr, uc->gidlen, uc->gidlist);
> +	cr->cr_prison = &prison0;
> +	prison_hold(cr->cr_prison);
> 	*crp = crhold(cr);
>
> 	return (TRUE);
> _______________________________________________
> freebsd-current@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
>
From patfbsd at davenulle.org  Sun Sep 27 07:07:25 2009
From: patfbsd at davenulle.org (Patrick Lamaiziere)
Date: Sun Sep 27 07:07:32 2009
Subject: various kde programs spin in a poll/read loop against their
 respective config files
In-Reply-To: <200909261525.18608.christof.schulze@gmx.com>
References: <200909261525.18608.christof.schulze@gmx.com>
Message-ID: <20090927090719.414ecf52@baby-jane.lamaiziere.net>

Le Sat, 26 Sep 2009 15:25:17 +0200,
Christof Schulze <christof.schulze@gmx.com> a ?crit :

> Hello everyone,

Hi,

> the discussion in -current and the behavior of my hard disk caused me
> to investigate. Whenever kde programs are run on this system, the
> hard disk will not spin down (even when excessive timeouts for syncs
> are in effect) So I ran truss against kwallet and plasma-desktop to
> find out they do the same thing:
> 
> stat("/home/erika/.kde4/share/apps/kwallet",{ mode=drwx------ 
> ,inode=56314,size=3,blksize=4096 }) = 0 (0x0)

> Shouldn't this be handled by fam/gamin in order to avoid this
> overhead? While it does not produce notable load it prevents my
> processor from saving power as well as spinning down the disks.

KDE with fam is broken, according to 
http://wiki.freebsd.org/KDE4

A work-around is to change the PollInterval in kdedrc
baby-jane:~$ less .kde4/share/config/kdedrc
[$Version]
update_info=kded.upd:kde3.0

[DirWatch]
PollInterval=60000

(IMHO, for KDE issues you should ask on the kde-freebsd@kde.org mailing
list).

See also this thread :
http://mail.kde.org/pipermail/kde-freebsd/2009-September/006447.html

Regards.
From uqs at spoerlein.net  Sun Sep 27 09:13:18 2009
From: uqs at spoerlein.net (Ulrich =?utf-8?B?U3DDtnJsZWlu?=)
Date: Sun Sep 27 09:13:25 2009
Subject: problem with link aggregation failover
In-Reply-To: <1704894341.63251252787681862.JavaMail.root@dagobah.intersec.pl>
References: <1704894341.63251252787681862.JavaMail.root@dagobah.intersec.pl>
Message-ID: <20090927091314.GG69612@acme.spoerlein.net>

On Sat, 12.09.2009 at 22:34:41 +0200, Maciej Jan Broniarz wrote:
> Hello,
> 
> I am trying to configure lagg failover mode on 7.2. 
> 
> I do:
> 
> # ifconfig xl0 up
> # ifconfig fxp0 up
> # ifconfig lagg0 create
> # ifconfig lagg0 up laggproto failover laggport xl0 laggport fxp0
> # dhclient lagg0 
> 
> And all seems to work ok. Still I disconnect the cable from the master card the connection stops. 
> Although fxp0 becomes active the connection is still dead. If I start pinging any host from that machine
> the conection comes back to live, but having ping in background all the time is not the solution.
> 
> Am I doing something wrong or have I missed something in the configuration?

Well, where is xl0 and fxp0 connected to? My first bet would be a
standard switch, if so try setting both devices to the same MAC address.
Otherwise the peers you connect to will send the IP packets to the wrong
MAC address and only after a timeout (or a forced push thanks to the
ping) will get their ARP cache into shape.

Regards,
Uli
From lambert at lambertfam.org  Sun Sep 27 11:19:25 2009
From: lambert at lambertfam.org (Scott Lambert)
Date: Sun Sep 27 11:19:33 2009
Subject: 8-RC1: iwn0 suspend/resume issues
Message-ID: <20090927111924.GG4858@sysmon.tcworks.net>

Threading broken to avoid potential takover of ral0 thread.

On Sat, Sep 26, 2009 at 02:33:26AM +0000, Brandon Gooch wrote:
> On Fri, Sep 25, 2009 at 11:29 PM, Scott Lambert <lambert@lambertfam.org> wrote:
> > iwn does not function after resume so I've actually run ethernet cables
> > to where I use the laptop now.
> 
> I have to unload the if_iwn module on suspend, and reload it on resume
> (via /etc/rc.[suspend|resume], of course).
> 
> Have you tried that?

I am glad to hear that it works for somebody.  There is hope!  I have:

 kldunload if_iwn

in /etc/rc.suspend and:

 kldload if_iwn

in /etc/rc.resume.

On resume there are lots of

iwn0: iwn_mem_lock: could not lock memory

and

iwn0: iwn_transfer_microcode: could not load boot firmware
iwn0: iwn_transfer_firmware: could not load boot firmware, error 60
iwn0: iwn_init_locked: could not load firmware, error 60

I did just notice:

iwn0: Reg Domain: \M^?\M^?\M^?\M^?iwn0: iwn_mem_lock: could not lock memory

Maybe I should set the regulatory domain?  But having just spent a few
minutes trying, it doesn't seem to be interested...

lambert@slambert:~> sudo ifconfig wlan0 regdomain FCC
ifconfig: SIOCS80211: Device busy
Exit 1
lambert@slambert:~> sudo ifconfig iwn0 regdomain FCC
ifconfig: unable to get regulatory domain info: Invalid argument
Exit 1

Same result with the other regulatory domains.  Maybe iwn just doesn't
support it?

lambert@slambert:~> sudo ifconfig wlan0 list regdomain
:regdomain 0 country US anywhere -ecm



  http://www.lambertfam.org/~lambert/laptop/TravelMate_5720-6911  

has my rc.[suspend|resume] and dmesg.[boot|resume] showing the
issues.  Other stuff in there that might be relevant too, if anyone is
interested.

-- 
Scott Lambert                    KC5MLE                       Unix SysAdmin
lambert@lambertfam.org

From doconnor at gsoft.com.au  Sun Sep 27 11:52:52 2009
From: doconnor at gsoft.com.au (Daniel O'Connor)
Date: Sun Sep 27 11:53:00 2009
Subject: NFS server replies on wrong IP
Message-ID: <200909272122.42528.doconnor@gsoft.com.au>

Hi,
I recently upgraded a system from 7.x to 8.0-RC1 (well, got new guts for 
it and copied the data over..) and I am having trouble getting NFS to 
work.

I have re0 like so
re0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 
mtu 1500
        
options=389b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_UCAST,WOL_MCAST,WOL_MAGIC>
        ether 00:24:1d:d1:92:cc
        inet 10.0.2.1 netmask 0xffffff00 broadcast 10.0.2.255
        inet 10.0.2.3 netmask 0xffffffff broadcast 10.0.2.3
        inet 10.0.2.4 netmask 0xffffffff broadcast 10.0.2.4
        inet 10.0.2.7 netmask 0xffffffff broadcast 10.0.2.7
        media: Ethernet autoselect (1000baseT <full-duplex>)
        status: active

and when I try and NFS mount something on 10.0.2.7 I see that the reply 
comes from the wrong address (10.0.2.1). ie from wireshark..
7	0.801704	10.0.2.1	10.0.2.103	NFS	V3 NULL Reply (Call In 6)
8	0.802742	10.0.2.103	10.0.2.1	ICMP	Destination unreachable (Port 
unreachable)

Interestingly Linux works OK, but perhaps it specifically allows it some 
how?

I can work around this by using -h to bind to 10.0.2.7 though, which is 
what I did on 7.x. I was wondering if there was a "correct" solution 
though.

-- 
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
  -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090927/bd6bbc70/attachment.pgp
From chris at shenton.org  Sun Sep 27 13:57:51 2009
From: chris at shenton.org (Chris Shenton)
Date: Sun Sep 27 13:57:58 2009
Subject: How to upgrade kernel with gmirror boot?     
In-Reply-To: <E5F0AE90-F1C2-4038-979F-C52FCEB6D3C7@lassitu.de>
References: <86d45dh6jc.fsf@Boqueria.shenton.org>
	<E5F0AE90-F1C2-4038-979F-C52FCEB6D3C7@lassitu.de>
Message-ID: <DCA98CB9-6FF4-4CBA-AFFA-EAD9D24245C7@shenton.org>


On Sep 26, 2009, at 5:47 PM, Stefan Bethke wrote:

> Am 26.09.2009 um 21:04 schrieb Chris Shenton:
>
>> PS: Current "gmirror list" output:
>>
>> $ gmirror list
>> Geom name: boot
>> State: COMPLETE
>> Components: 1
>            ^^^
>
> There's your problem: your mirror consist of only ad6s1a.  You need  
> to add ad4s1a using gmirror insert, or tell your BIOS to boot from  
> the second disk.

That was it, exactly. I've been running with a broken mirror all this  
time, doh!  Added the second disk partition and was able to build and  
install kernel and boot from it.

Many thanks.

From deischen at freebsd.org  Sun Sep 27 14:07:30 2009
From: deischen at freebsd.org (Daniel Eischen)
Date: Sun Sep 27 14:07:37 2009
Subject: problem with link aggregation failover
In-Reply-To: <20090927091314.GG69612@acme.spoerlein.net>
References: <1704894341.63251252787681862.JavaMail.root@dagobah.intersec.pl>
	<20090927091314.GG69612@acme.spoerlein.net>
Message-ID: <Pine.GSO.4.64.0909270946460.26181@sea.ntplx.net>

On Sun, 27 Sep 2009, Ulrich Spörlein wrote:

> On Sat, 12.09.2009 at 22:34:41 +0200, Maciej Jan Broniarz wrote:
>> Hello,
>>
>> I am trying to configure lagg failover mode on 7.2.
>>
>> I do:
>>
>> # ifconfig xl0 up
>> # ifconfig fxp0 up
>> # ifconfig lagg0 create
>> # ifconfig lagg0 up laggproto failover laggport xl0 laggport fxp0
>> # dhclient lagg0
>>
>> And all seems to work ok. Still I disconnect the cable from the master card the connection stops.
>> Although fxp0 becomes active the connection is still dead. If I start pinging any host from that machine
>> the conection comes back to live, but having ping in background all the time is not the solution.
>>
>> Am I doing something wrong or have I missed something in the configuration?
>
> Well, where is xl0 and fxp0 connected to? My first bet would be a
> standard switch, if so try setting both devices to the same MAC address.
> Otherwise the peers you connect to will send the IP packets to the wrong
> MAC address and only after a timeout (or a forced push thanks to the
> ping) will get their ARP cache into shape.

lagg should automatically make xl0 and fxp0 appear at the same MAC
address.  The only time you should have to manually set the MAC
address would be on cloned interfaces such as wlan, because the
cloned interfaces don't propagate the MAC change down to the
interface from which they were cloned.

-- 
DE
From doconnor at gsoft.com.au  Sun Sep 27 14:39:40 2009
From: doconnor at gsoft.com.au (Daniel O'Connor)
Date: Sun Sep 27 14:39:47 2009
Subject: Excessivly cheap USB device issue
Message-ID: <200909280009.28658.doconnor@gsoft.com.au>

I have a very cheap USB CF/SD/SM/MS connected to an 8.0-RC1 system and
 it is detected, ie..
Sep 27 14:29:18 midget kernel: da0 at umass-sim0 bus 0 target 0 lun 0
Sep 27 14:29:18 midget kernel: da0: <Generic USB SD Reader 1.00> Removable Direct Access SCSI-0 device
Sep 27 14:29:18 midget kernel: da0: 40.000MB/s transfers
Sep 27 14:29:18 midget kernel: da0: Attempt to query device size failed: NOT READY, Medium not present
Sep 27 14:29:18 midget kernel: (probe7:umass-sim0:0:0:1): TEST UNIT READY. CDB: 0 20 0 0 0 0
Sep 27 14:29:18 midget kernel: (probe7:umass-sim0:0:0:1): CAM Status: SCSI Status Error
Sep 27 14:29:18 midget kernel: (probe7:umass-sim0:0:0:1): SCSI Status: Check Condition
Sep 27 14:29:18 midget kernel: (probe7:umass-sim0:0:0:1): NOT READY csi:0,aa,55,40 asc:3a,0
Sep 27 14:29:18 midget kernel: (probe7:umass-sim0:0:0:1): Medium not present
Sep 27 14:29:18 midget kernel: (probe7:umass-sim0:0:0:1): Unretryable error
Sep 27 14:29:18 midget kernel: da1 at umass-sim0 bus 0 target 0 lun 1
Sep 27 14:29:18 midget kernel: da1: <Generic USB CF Reader 1.01> Removable Direct Access SCSI-0 device
Sep 27 14:29:18 midget kernel: da1: 40.000MB/s transfers
Sep 27 14:29:18 midget kernel: da1: Attempt to query device size failed: NOT READY, Medium not present

If I connect a CF card to da1 and run 'fdisk da1' I get..
[midget 0:06] ~ >fdisk da1
load: 0.29  cmd: fdisk 69630 [cgticb] 1.50r 0.00u 0.00s 0% 1160k
load: 0.19  cmd: fdisk 69630 [cbwait] 24.42r 0.00u 0.00s 0% 1160k
load: 0.19  cmd: fdisk 69630 [cbwait] 27.01r 0.00u 0.00s 0% 1160k
fdisk: unable to get correct path for da1: Input/output error

[midget 0:05] ~ >sudo usbconfig -u 5 -a 2 dump_device_desc
ugen5.2: <Mass Storage Device Generic> at usbus5, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON

  bLength = 0x0012
  bDescriptorType = 0x0001
  bcdUSB = 0x0200
  bDeviceClass = 0x0000
  bDeviceSubClass = 0x0000
  bDeviceProtocol = 0x0000
  bMaxPacketSize0 = 0x0040
  idVendor = 0x058f
  idProduct = 0x6362
  bcdDevice = 0x0129
load: 0.21  cmd: usbconfig 69643 [WCTRL] 1.73r 0.00u 0.00s 0% 1080k
  iManufacturer = 0x0001  <retrieving string failed>
load: 0.19  cmd: usbconfig 69643 [WCTRL] 8.56r 0.00u 0.00s 0% 1104k
  iProduct = 0x0002  <retrieving string failed>
  iSerialNumber = 0x0003  <retrieving string failed>
  bNumConfigurations = 0x0001

Perhaps some quirk would help but I'm not sure which one :)

-- 
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
  -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090927/6f75ba33/attachment.pgp
From rnoland at FreeBSD.org  Sun Sep 27 14:47:37 2009
From: rnoland at FreeBSD.org (Robert Noland)
Date: Sun Sep 27 14:47:44 2009
Subject: Excessivly cheap USB device issue
In-Reply-To: <200909280009.28658.doconnor@gsoft.com.au>
References: <200909280009.28658.doconnor@gsoft.com.au>
Message-ID: <1254062842.2048.1467.camel@balrog.2hip.net>

On Mon, 2009-09-28 at 00:09 +0930, Daniel O'Connor wrote:
> I have a very cheap USB CF/SD/SM/MS connected to an 8.0-RC1 system and
>  it is detected, ie..
> Sep 27 14:29:18 midget kernel: da0 at umass-sim0 bus 0 target 0 lun 0
> Sep 27 14:29:18 midget kernel: da0: <Generic USB SD Reader 1.00> Removable Direct Access SCSI-0 device
> Sep 27 14:29:18 midget kernel: da0: 40.000MB/s transfers
> Sep 27 14:29:18 midget kernel: da0: Attempt to query device size failed: NOT READY, Medium not present
> Sep 27 14:29:18 midget kernel: (probe7:umass-sim0:0:0:1): TEST UNIT READY. CDB: 0 20 0 0 0 0
> Sep 27 14:29:18 midget kernel: (probe7:umass-sim0:0:0:1): CAM Status: SCSI Status Error
> Sep 27 14:29:18 midget kernel: (probe7:umass-sim0:0:0:1): SCSI Status: Check Condition
> Sep 27 14:29:18 midget kernel: (probe7:umass-sim0:0:0:1): NOT READY csi:0,aa,55,40 asc:3a,0
> Sep 27 14:29:18 midget kernel: (probe7:umass-sim0:0:0:1): Medium not present
> Sep 27 14:29:18 midget kernel: (probe7:umass-sim0:0:0:1): Unretryable error
> Sep 27 14:29:18 midget kernel: da1 at umass-sim0 bus 0 target 0 lun 1
> Sep 27 14:29:18 midget kernel: da1: <Generic USB CF Reader 1.01> Removable Direct Access SCSI-0 device
> Sep 27 14:29:18 midget kernel: da1: 40.000MB/s transfers
> Sep 27 14:29:18 midget kernel: da1: Attempt to query device size failed: NOT READY, Medium not present
> 
> If I connect a CF card to da1 and run 'fdisk da1' I get..
> [midget 0:06] ~ >fdisk da1
> load: 0.29  cmd: fdisk 69630 [cgticb] 1.50r 0.00u 0.00s 0% 1160k
> load: 0.19  cmd: fdisk 69630 [cbwait] 24.42r 0.00u 0.00s 0% 1160k
> load: 0.19  cmd: fdisk 69630 [cbwait] 27.01r 0.00u 0.00s 0% 1160k
> fdisk: unable to get correct path for da1: Input/output error
> 
> [midget 0:05] ~ >sudo usbconfig -u 5 -a 2 dump_device_desc
> ugen5.2: <Mass Storage Device Generic> at usbus5, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON
> 
>   bLength = 0x0012
>   bDescriptorType = 0x0001
>   bcdUSB = 0x0200
>   bDeviceClass = 0x0000
>   bDeviceSubClass = 0x0000
>   bDeviceProtocol = 0x0000
>   bMaxPacketSize0 = 0x0040
>   idVendor = 0x058f
>   idProduct = 0x6362
>   bcdDevice = 0x0129
> load: 0.21  cmd: usbconfig 69643 [WCTRL] 1.73r 0.00u 0.00s 0% 1080k
>   iManufacturer = 0x0001  <retrieving string failed>
> load: 0.19  cmd: usbconfig 69643 [WCTRL] 8.56r 0.00u 0.00s 0% 1104k
>   iProduct = 0x0002  <retrieving string failed>
>   iSerialNumber = 0x0003  <retrieving string failed>
>   bNumConfigurations = 0x0001
> 
> Perhaps some quirk would help but I'm not sure which one :)

I also have a similar device, which I've been messing with a bit the
last couple of days.  In your case, it isn't seeing the media, just the
"drive".  I've had to try various combinations of unplugging the adapter
from usb, inserting the media then plugging it back in.  It does seem to
work fairly reliably if you boot with the media already inserted, but it
doesn't seem to detect media change at all.

robert.

-- 
Robert Noland <rnoland@FreeBSD.org>
FreeBSD

From lehmann at ans-netz.de  Sun Sep 27 15:29:23 2009
From: lehmann at ans-netz.de (Oliver Lehmann)
Date: Sun Sep 27 15:29:30 2009
Subject: glabel+gmirror
Message-ID: <20090927170244.0980d699.lehmann@ans-netz.de>

Hi,

I try to glabel (tunefs -L) my gmirror RAID-1. After labeling
the /usr, /tmp, /var partition, glabel status shows the labes are being
assigned to the mirror/gm0s1* partitions.
I then changed my /etc/fstab to use the ufs/<label> devices instead of
the mirror/gm0s1* devices.
After the system got rebootet, the system is now unable to mount the
partitions and puts me into the single user mode.
glabel status shows me now, that the labels are all assigned to da0s1*
instead of mirror/gm0s1*. How did this happen? glabel never shows the
mirror/gm0s1* partitions anyhow - only after labeling them. But after
reboot the labels are reassigned to da0s1* and glabel does not show any
mirror/gm0s1* label.

How can I prevent this to happen?

-- 
 Oliver Lehmann
  http://www.pofo.de/
  http://wishlist.ans-netz.de/
From uqs at spoerlein.net  Sun Sep 27 17:01:54 2009
From: uqs at spoerlein.net (Ulrich =?utf-8?B?U3DDtnJsZWlu?=)
Date: Sun Sep 27 17:02:14 2009
Subject: problem with link aggregation failover
In-Reply-To: <Pine.GSO.4.64.0909270946460.26181@sea.ntplx.net>
References: <1704894341.63251252787681862.JavaMail.root@dagobah.intersec.pl>
	<20090927091314.GG69612@acme.spoerlein.net>
	<Pine.GSO.4.64.0909270946460.26181@sea.ntplx.net>
Message-ID: <20090927170151.GK69612@acme.spoerlein.net>

On Sun, 27.09.2009 at 09:49:03 -0400, Daniel Eischen wrote:
> On Sun, 27 Sep 2009, Ulrich Sp?rlein wrote:
> 
> > On Sat, 12.09.2009 at 22:34:41 +0200, Maciej Jan Broniarz wrote:
> >> Hello,
> >>
> >> I am trying to configure lagg failover mode on 7.2.
> >>
> >> I do:
> >>
> >> # ifconfig xl0 up
> >> # ifconfig fxp0 up
> >> # ifconfig lagg0 create
> >> # ifconfig lagg0 up laggproto failover laggport xl0 laggport fxp0
> >> # dhclient lagg0
> >>
> >> And all seems to work ok. Still I disconnect the cable from the master card the connection stops.
> >> Although fxp0 becomes active the connection is still dead. If I start pinging any host from that machine
> >> the conection comes back to live, but having ping in background all the time is not the solution.
> >>
> >> Am I doing something wrong or have I missed something in the configuration?
> >
> > Well, where is xl0 and fxp0 connected to? My first bet would be a
> > standard switch, if so try setting both devices to the same MAC address.
> > Otherwise the peers you connect to will send the IP packets to the wrong
> > MAC address and only after a timeout (or a forced push thanks to the
> > ping) will get their ARP cache into shape.
> 
> lagg should automatically make xl0 and fxp0 appear at the same MAC
> address.  The only time you should have to manually set the MAC
> address would be on cloned interfaces such as wlan, because the
> cloned interfaces don't propagate the MAC change down to the
> interface from which they were cloned.

Interesting, thanks for the hint. I only use it for LAN/WLAN failover,
so that's why I have to do this anyway.

Regards,
Uli
From david at catwhisker.org  Sun Sep 27 17:35:20 2009
From: david at catwhisker.org (David Wolfskill)
Date: Sun Sep 27 17:35:28 2009
Subject: 6.4-STABLE @r197533: iwi(4) implicated in page fault while in
	kernel mode
Message-ID: <20090927173519.GC51983@albert.catwhisker.org>

See <http://www.catwhisker.org/~david/FreeBSD/core.txt.9> for more
details.  Here's the first part of it:

g1-89.catwhisker.org dumped core - see ./vmcore.9

Sun Sep 27 10:24:20 PDT 2009

FreeBSD g1-89.catwhisker.org 6.4-STABLE FreeBSD 6.4-STABLE #695 r197533: Sun Sep 27 04:22:07 PDT 2009     root@g1-88.catwhisker.org:/common/S1/obj/usr/src/sys/CANARY  i386

panic: page fault

GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-marcel-freebsd"...

Unread portion of the kernel message buffer:
kernel trap 12 with interrupts disabled

Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0x78
fault code              = supervisor read, page not present
instruction pointer     = 0x20:0xc06ad115
stack pointer           = 0x28:0xe4528aa0
frame pointer           = 0x28:0xe4528aa4
code segment            = base 0x0, limit 0xfffff, type 0x1b
                        = DPL 0, pres 1, def32 1, gran 1
processor eflags        = resume, IOPL = 0
current process         = 8027 (ifconfig)
trap number             = 12
panic: page fault
Uptime: 3h11m29s
Dumping 767 MB (2 chunks)
  chunk 0: 1MB (159 pages) ... ok
  chunk 1: 767MB (196322 pages) 751 735 719 703 687 671 655 639 623 607 591 575 559 543 527 511 495 479 463 447 431 415 399 383 367 351 335 319 303 287 271 255 239 223 207 191 175 159 143 127 111 95 79 63 47 31 15

Reading symbols from /boot/kernel/linux.ko...done.
Loaded symbols for /boot/kernel/linux.ko
Reading symbols from /boot/kernel/if_iwi.ko...done.
Loaded symbols for /boot/kernel/if_iwi.ko
Reading symbols from /boot/kernel/firmware.ko...done.
Loaded symbols for /boot/kernel/firmware.ko
Reading symbols from /boot/kernel/acpi.ko...done.
Loaded symbols for /boot/kernel/acpi.ko
Reading symbols from /boot/kernel/linprocfs.ko...done.
Loaded symbols for /boot/kernel/linprocfs.ko
Reading symbols from /boot/modules/iwi_bss.ko...done.
Loaded symbols for /boot/modules/iwi_bss.ko
Reading symbols from /usr/local/modules/rtc.ko...done.
Loaded symbols for /usr/local/modules/rtc.ko
Reading symbols from /boot/kernel/radeon.ko...done.
Loaded symbols for /boot/kernel/radeon.ko
Reading symbols from /boot/kernel/drm.ko...done.
Loaded symbols for /boot/kernel/drm.ko
#0  doadump () at pcpu.h:165
165     pcpu.h: No such file or directory.
        in pcpu.h
(kgdb) #0  doadump () at pcpu.h:165
#1  0xc068c1e6 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:410
#2  0xc068c47c in panic (fmt=0xc0957dd5 "%s")
    at /usr/src/sys/kern/kern_shutdown.c:566
#3  0xc08fd5a4 in trap_fatal (frame=0xe4528a60, eva=120)
    at /usr/src/sys/i386/i386/trap.c:838
#4  0xc08fcd42 in trap (frame=
      {tf_fs = 333447176, tf_es = 40, tf_ds = 780009512, tf_edi = -992778212, tf_esi = -985385088, tf_ebp = -464352604, tf_isp = -464352628, tf_ebx = -994579200, tf_edx = 0, tf_ecx = 4, tf_eax = -985385056, tf_trapno = 12, tf_err = 0, tf_eip = -1066741483, tf_cs = 32, tf_eflags = 65538, tf_esp = -985385088, tf_ss = -464352568}) at /usr/src/sys/i386/i386/trap.c:270
#5  0xc08ea1da in calltrap () at /usr/src/sys/i386/i386/exception.s:139
#6  0xc06ad115 in turnstile_setowner (ts=0xc4b7ed00, owner=0x4)
    at /usr/src/sys/kern/subr_turnstile.c:456
#7  0xc06ad472 in turnstile_wait (lock=0xc554557c, owner=0x4, queue=0)
    at /usr/src/sys/kern/subr_turnstile.c:661
#8  0xc0683082 in _mtx_lock_sleep (m=0xc554557c, tid=3309582208, opts=0, 
    file=0x0, line=0) at /usr/src/sys/kern/kern_mutex.c:579
#9  0xc070a618 in rtrequest1 (req=1, info=0xe4528b60, ret_nrt=0xe4528b54)
    at /usr/src/sys/net/route.c:792
#10 0xc070b0ff in rtinit (ifa=0xc5545500, cmd=1, flags=1)
    at /usr/src/sys/net/route.c:1201
#11 0xc0727b41 in in_addprefix (target=0xc5545500, flags=1)
    at /usr/src/sys/netinet/in.c:851
#12 0xc0727a6d in in_ifinit (ifp=0xc4922000, ia=0xc5545500, sin=0x4, scrub=0)
    at /usr/src/sys/netinet/in.c:778
#13 0xc0726d68 in in_control (so=0xc543bde8, cmd=1, data=0xc54911c0 "iwi0", 
    ifp=0xc4922000, td=0xc5443780) at /usr/src/sys/netinet/in.c:440
#14 0xc06fb2b8 in ifioctl (so=0xc543bde8, cmd=2151704858, 
    data=0xc54911c0 "iwi0", td=0xc5443780) at /usr/src/sys/net/if.c:1612
#15 0xc06b4e7b in soo_ioctl (fp=0xc54437a0, cmd=2151704858, data=0xc54911c0, 
    active_cred=0xc47d8d80, td=0xc5443780)
    at /usr/src/sys/kern/sys_socket.c:214
#16 0xc06af31d in ioctl (td=0xc5443780, uap=0xe4528d04) at file.h:265
#17 0xc08fd8bb in syscall (frame=
      {tf_fs = 59, tf_es = 59, tf_ds = 59, tf_edi = 134570944, tf_esi = 134580448, tf_ebp = -1077941288, tf_isp = -464351900, tf_ebx = -2143262438, tf_edx = 134583233, tf_ecx = 134570944, tf_eax = 54, tf_trapno = 12, tf_err = 2, tf_eip = 869574699, tf_cs = 51, tf_eflags = 646, tf_esp = -1077943412, tf_ss = 59})
    at /usr/src/sys/i386/i386/trap.c:984
#18 0xc08ea22f in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:200
#19 0x00000033 in ?? ()
Previous frame inner to this frame (corrupt stack?)
(kgdb) 


The access point was a little less than a meter away from the laptop
when that happened.

I'm preserving a copy of that environment on slice 2.

I'll be happy to test things, but note that this is not a common
occurrence; I have no confidence that I can re-create it.

Peace,
david
-- 
David H. Wolfskill				david@catwhisker.org
Depriving a girl or boy of an opportunity for education is evil.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090927/e40aa7be/attachment.pgp
From des at des.no  Sun Sep 27 19:24:51 2009
From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=)
Date: Sun Sep 27 19:24:58 2009
Subject: 8.0-RC1: kernel page fault in NLM master thread (VIMAGE or ZFS
	related?)
In-Reply-To: <4ABD4BB9.1030804@FreeBSD.org> (Jamie Gritton's message of "Fri, 
	25 Sep 2009 17:01:13 -0600")
References: <FD184B4B-517F-470E-BAC8-DD0795983C2B@mac.com>
	<4ABD4BB9.1030804@FreeBSD.org>
Message-ID: <86ab0g1a30.fsf@ds4.des.no>

Jamie Gritton <jamie@FreeBSD.org> writes:
> Index: kern/vfs_export.c
> ===================================================================
> --- kern/vfs_export.c	(revision 197506)
> +++ kern/vfs_export.c	(working copy)
> @@ -122,6 +122,8 @@
>  		np->netc_anon->cr_uid = argp->ex_anon.cr_uid;
>  		crsetgroups(np->netc_anon, argp->ex_anon.cr_ngroups,
>  		    argp->ex_anon.cr_groups);
> +		np->netc_anon->cr_prison = &prison0;
> +		prison_hold(np->netc_anon->cr_prison);
>  		np->netc_numsecflavors = argp->ex_numsecflavors;
>  		bcopy(argp->ex_secflavors, np->netc_secflavors,
>  		    sizeof(np->netc_secflavors));

You need to #include <sys/jail.h> for prison0...  See attached patch.

DES
-- 
Dag-Erling Sm?rgrav - des@des.no

-------------- next part --------------
A non-text attachment was scrubbed...
Name: nfslockd.diff
Type: text/x-patch
Size: 1602 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090927/bc8dac6f/nfslockd.bin
From sam at freebsd.org  Sun Sep 27 19:50:34 2009
From: sam at freebsd.org (Sam Leffler)
Date: Sun Sep 27 19:50:53 2009
Subject: 8-RC1: iwn0 suspend/resume issues
In-Reply-To: <20090927111924.GG4858@sysmon.tcworks.net>
References: <20090927111924.GG4858@sysmon.tcworks.net>
Message-ID: <4ABFC20A.3070100@freebsd.org>

Scott Lambert wrote:
> Threading broken to avoid potential takover of ral0 thread.
> 
> On Sat, Sep 26, 2009 at 02:33:26AM +0000, Brandon Gooch wrote:
>> On Fri, Sep 25, 2009 at 11:29 PM, Scott Lambert <lambert@lambertfam.org> wrote:
>>> iwn does not function after resume so I've actually run ethernet cables
>>> to where I use the laptop now.
>> I have to unload the if_iwn module on suspend, and reload it on resume
>> (via /etc/rc.[suspend|resume], of course).
>>
>> Have you tried that?
> 
> I am glad to hear that it works for somebody.  There is hope!  I have:
> 
>  kldunload if_iwn
> 
> in /etc/rc.suspend and:
> 
>  kldload if_iwn
> 
> in /etc/rc.resume.
> 
> On resume there are lots of
> 
> iwn0: iwn_mem_lock: could not lock memory
> 
> and
> 
> iwn0: iwn_transfer_microcode: could not load boot firmware
> iwn0: iwn_transfer_firmware: could not load boot firmware, error 60
> iwn0: iwn_init_locked: could not load firmware, error 60
> 
> I did just notice:
> 
> iwn0: Reg Domain: \M^?\M^?\M^?\M^?iwn0: iwn_mem_lock: could not lock memory
> 
> Maybe I should set the regulatory domain?  But having just spent a few
> minutes trying, it doesn't seem to be interested...
> 
> lambert@slambert:~> sudo ifconfig wlan0 regdomain FCC
> ifconfig: SIOCS80211: Device busy

wlan0 is marked UP; you cannot set regulatory state unless the interface
is down.

> Exit 1
> lambert@slambert:~> sudo ifconfig iwn0 regdomain FCC
> ifconfig: unable to get regulatory domain info: Invalid argument

iwn0 is the wrong interface to use; use wlan0

> Exit 1
> 
> Same result with the other regulatory domains.  Maybe iwn just doesn't
> support it?
> 
> lambert@slambert:~> sudo ifconfig wlan0 list regdomain
> :regdomain 0 country US anywhere -ecm
> 
> 
> 
>   http://www.lambertfam.org/~lambert/laptop/TravelMate_5720-6911  
> 
> has my rc.[suspend|resume] and dmesg.[boot|resume] showing the
> issues.  Other stuff in there that might be relevant too, if anyone is
> interested.
> 

Regarding regdomain stuff; AFAIK you cannot alter regulatory state of
any intel wireless card; it will enforce whatever is in the EEPROM.
Can't recall if the driver pushes EEPROM state up to net80211; if not
then it should and it should also reject all requests to change
regulatory until there's fw that supports it.

	Sam
From lehmann at ans-netz.de  Sun Sep 27 20:37:24 2009
From: lehmann at ans-netz.de (Oliver Lehmann)
Date: Sun Sep 27 20:37:30 2009
Subject: glabel+gmirror (8.0-RC1 problem)
In-Reply-To: <20090927170244.0980d699.lehmann@ans-netz.de>
References: <20090927170244.0980d699.lehmann@ans-netz.de>
Message-ID: <20090927223725.5893371f.lehmann@ans-netz.de>

Hi,

that gmirror together with glabel cannot be used looks like a problem
introduced with 8.0-RC1 to me.

What I did:

2. Installation
3. reboot
4. mirror Root-hdd
sysctl kern.geom.debugflags=17
gmirror label -vb round-robin gm0 da0
gmirror load
echo 'geom_mirror_load="YES"' >> /boot/loader.conf
echo 'geom_label_load="YES"' >> /boot/loader.conf

5. adjust fstab
vi /etc/fstab
:%s/ad/mirror\/gm/g

6. reboot

7. mirror Root-hdd
gmirror insert gm0 da1
gmirror status

8. wait until gmirror is done

9. reboot

10. glabel status

With 8.0-RC1 I see only da0s1a, da0s1d, da0s1e and da0s1f as Components
shown by glabel(8).
With 8.0-BETA3 I see mirror/gm0s1a, mirror/gm0s1d, mirror/gm0s1e and
mirror/gm0s1f as Components which would be correct here.

I use old IBM 2GB DFHS harddisks for that tests. I have a bunch of them
so I used for both tries "fresh" drives.

I can't see what has changed here between BETA3 and RC1 but something
must have changed in a way which renders gmirror together with glabel on
RC1 non-working.

I just did that as testing the configuration I want to use for my
fileserver when the new harddisks arrived but now I'm not sure If I
should rely on gmirror+glabel....

Oliver Lehmann wrote:

> Hi,
> 
> I try to glabel (tunefs -L) my gmirror RAID-1. After labeling
> the /usr, /tmp, /var partition, glabel status shows the labes are being
> assigned to the mirror/gm0s1* partitions.
> I then changed my /etc/fstab to use the ufs/<label> devices instead of
> the mirror/gm0s1* devices.
> After the system got rebootet, the system is now unable to mount the
> partitions and puts me into the single user mode.
> glabel status shows me now, that the labels are all assigned to da0s1*
> instead of mirror/gm0s1*. How did this happen? glabel never shows the
> mirror/gm0s1* partitions anyhow - only after labeling them. But after
> reboot the labels are reassigned to da0s1* and glabel does not show any
> mirror/gm0s1* label.
> 
> How can I prevent this to happen?
From mike at sentex.net  Mon Sep 28 00:52:16 2009
From: mike at sentex.net (Mike Tancsa)
Date: Mon Sep 28 00:52:24 2009
Subject: Excessivly cheap USB device issue
In-Reply-To: <1254062842.2048.1467.camel@balrog.2hip.net>
References: <200909280009.28658.doconnor@gsoft.com.au>
	<1254062842.2048.1467.camel@balrog.2hip.net>
Message-ID: <200909280052.n8S0qCpL032199@lava.sentex.ca>

At 10:47 AM 9/27/2009, Robert Noland wrote:
> > Sep 27 14:29:18 midget kernel: da1: Attempt to query device size 
> failed: NOT READY, Medium not present
> >
> > If I connect a CF card to da1 and run 'fdisk da1' I get..
> > [midget 0:06] ~ >fdisk da1
> > load: 0.29  cmd: fdisk 69630 [cgticb] 1.50r 0.00u 0.00s 0% 1160k
> > load: 0.19  cmd: fdisk 69630 [cbwait] 24.42r 0.00u 0.00s 0% 1160k
> > load: 0.19  cmd: fdisk 69630 [cbwait] 27.01r 0.00u 0.00s 0% 1160k
> > fdisk: unable to get correct path for da1: Input/output error
> >
> > [midget 0:05] ~ >sudo usbconfig -u 5 -a 2 dump_device_desc
> > ugen5.2: <Mass Storage Device Generic> at usbus5, cfg=0 md=HOST 
> spd=HIGH (480Mbps) pwr=ON
> >
> >   bLength = 0x0012
> >   bDescriptorType = 0x0001
> >   bcdUSB = 0x0200
> >   bDeviceClass = 0x0000
> >   bDeviceSubClass = 0x0000
> >   bDeviceProtocol = 0x0000
> >   bMaxPacketSize0 = 0x0040
> >   idVendor = 0x058f
> >   idProduct = 0x6362
> >   bcdDevice = 0x0129
> > load: 0.21  cmd: usbconfig 69643 [WCTRL] 1.73r 0.00u 0.00s 0% 1080k
> >   iManufacturer = 0x0001  <retrieving string failed>
> > load: 0.19  cmd: usbconfig 69643 [WCTRL] 8.56r 0.00u 0.00s 0% 1104k
> >   iProduct = 0x0002  <retrieving string failed>
> >   iSerialNumber = 0x0003  <retrieving string failed>
> >   bNumConfigurations = 0x0001
> >
> > Perhaps some quirk would help but I'm not sure which one :)
>
>I also have a similar device, which I've been messing with a bit the
>last couple of days.  In your case, it isn't seeing the media, just the
>"drive".  I've had to try various combinations of unplugging the adapter
>from usb, inserting the media then plugging it back in.  It does seem to
>work fairly reliably if you boot with the media already inserted, but it
>doesn't seem to detect media change at all.


I get around it (on my cheap reader) by  always doing a
cat /dev/null > /dev/da1
whever I change or insert new media into the reader

That seems to work with the gear I have 99% of the time.

         ---Mike

From doconnor at gsoft.com.au  Mon Sep 28 02:04:17 2009
From: doconnor at gsoft.com.au (Daniel O'Connor)
Date: Mon Sep 28 02:04:24 2009
Subject: 8.0-RC1 panic attaching ppc
In-Reply-To: <4ABE81C5.2010009@cs.rice.edu>
References: <200909232322.51060.doconnor@gsoft.com.au>
	<200909260824.39985.doconnor@gsoft.com.au>
	<4ABE81C5.2010009@cs.rice.edu>
Message-ID: <200909281134.04010.doconnor@gsoft.com.au>

On Sun, 27 Sep 2009, Alan Cox wrote:
> Ok, now I can explain what is happening.  The kernel is using 1GB
> pages to implement the direct map.  Unfortunately, pmap_extract()
> doesn't know how to handle a 1GB page mapping.  pmap_kextract() only
> works by an "accident" of its different implementation.  In other
> words, it should not be relied upon to work either.
>
> Please revert whatever patch John gave you and try the attached
> patch. It simply disables the use of 1GB page mapping by the direct
> map.

Your patch fixes (works around?) the problem.

Thanks!

-- 
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
  -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090928/ea5255f8/attachment.pgp
From hiyorin at gmail.com  Mon Sep 28 03:30:50 2009
From: hiyorin at gmail.com (C. C. Tang)
Date: Mon Sep 28 03:30:57 2009
Subject: 7.2-release/amd64: panic, spin lock held too long
In-Reply-To: <4AB8458C.8000404@gmail.com>
References: <cf9b1ee00907061812r3da70018i1c8d8d12bb038a80@mail.gmail.com>	
	<3bbf2fe10909121432x7bd4f7es497e9431c4e520d6@mail.gmail.com>	
	<cf9b1ee00909121502v66566b46p754ed2f2e549555@mail.gmail.com>	
	<4AB1A838.2040406@gmail.com>	
	<3bbf2fe10909170216u29d994aj55c21efdfbc26ba5@mail.gmail.com>	
	<4AB21005.6040104@gmail.com> <4AB36E1F.6080401@gmail.com>	
	<cf9b1ee00909190204q33ded00dyb86a4b53ed5194be@mail.gmail.com>	
	<3bbf2fe10909191224m6061d325h8bc1a389e195aa30@mail.gmail.com>	
	<4AB8318D.5000404@gmail.com>
	<3bbf2fe10909211910r2ed6957cvb1f7f226e2a8b89d@mail.gmail.com>
	<4AB8458C.8000404@gmail.com>
Message-ID: <4AC02DE3.9000901@gmail.com>

C. C. Tang wrote:
> Attilio Rao wrote:
>> 2009/9/22 C. C. Tang <hiyorin@gmail.com>:
>>>>>>>>
>>>>>> I have patched the sched_ule.c and did a make buildkernel & make
>>>>>> installkernel (is buildworld and installworld necessary?), 
>>>>>> rebooted and
>>>>>> the
>>>>>> machine is running now.
>>>>>> I will post here again if there is any update.
>>> My server is up for 3.5 days now with HyperThreading & powerd enabled.
>>> No panic occured yet.
>>
>> Usually how long did it take to panic?
>>
>> Attilio
>>
>>
> It is rather random, but will usually panic within one week.
> Anyway my server will keep running and I will report if it has any problem.
> 
> Thanks,
> C.C.
> 
My server is up for 9.5 days now. Seems working fine.

C.C.
From cmdlnkid at gmail.com  Mon Sep 28 03:37:22 2009
From: cmdlnkid at gmail.com (CmdLnKid)
Date: Mon Sep 28 03:37:30 2009
Subject: locate(1) ZFS addition
Message-ID: <alpine.BSF.2.00.0909272328400.62818@qvzrafvba.5c.ybpny>


I just came across what I believe to be just a oversight on locate(1). By 
default as stated in its locate.rc file in /etc it states that the default 
file systems that will be searched is "ufs ext2fs". Would it be wise to have the 
default be "ufs zfs xfs ext2fs" ? or some other combination.

PS: Should a PR be filed for this ?

Best regards

-- 

   - (2^(N-1))
From lambert at lambertfam.org  Mon Sep 28 04:52:59 2009
From: lambert at lambertfam.org (Scott Lambert)
Date: Mon Sep 28 04:53:06 2009
Subject: 8-RC1: iwn0 suspend/resume issues
In-Reply-To: <4ABFC20A.3070100@freebsd.org>
References: <20090927111924.GG4858@sysmon.tcworks.net>
	<4ABFC20A.3070100@freebsd.org>
Message-ID: <20090928045258.GH4858@sysmon.tcworks.net>

On Sun, Sep 27, 2009 at 12:50:34PM -0700, Sam Leffler wrote:
> Scott Lambert wrote:
> > I did just notice:
> > 
> > iwn0: Reg Domain: \M^?\M^?\M^?\M^?iwn0: iwn_mem_lock: could not lock memory
> > 
> > Maybe I should set the regulatory domain?  But having just spent a few
> > minutes trying, it doesn't seem to be interested...
> > 
> > lambert@slambert:~> sudo ifconfig wlan0 regdomain FCC
> > ifconfig: SIOCS80211: Device busy
> 
> wlan0 is marked UP; you cannot set regulatory state unless the interface
> is down.
> 
> > Exit 1
> > lambert@slambert:~> sudo ifconfig iwn0 regdomain FCC
> > ifconfig: unable to get regulatory domain info: Invalid argument
> 
> iwn0 is the wrong interface to use; use wlan0

Ah, a little education is a dangerous thing.  Setting regdomain does not
give errors when I use wlan0 and it is configured down.  

> Regarding regdomain stuff; AFAIK you cannot alter regulatory state of
> any intel wireless card; it will enforce whatever is in the EEPROM.
> Can't recall if the driver pushes EEPROM state up to net80211; if
> not then it should and it should also reject all requests to change
> regulatory until there's fw that supports it.

It did let me set country to jp and regdomain to JAPAN while playing.
That may not mean much.  The iwn driver is confused right now because it
has been through a suspend and resume cycle.
 
Thank you, Sam!

-- 
Scott Lambert                    KC5MLE                       Unix SysAdmin
lambert@lambertfam.org

From kama at pvp.se  Mon Sep 28 07:21:18 2009
From: kama at pvp.se (kama)
Date: Mon Sep 28 07:21:25 2009
Subject: FreeBSD 7.2-STABLE boot freeze
In-Reply-To: <4ABC894E.7040204@freebsd.org>
References: <20090921140345.H37424@ns1.as.pvp.se>
	<20090922103150.V37424@ns1.as.pvp.se>
	<4AB8A95E.3060307@icyb.net.ua> <20090922142526.P37424@ns1.as.pvp.se>
	<4AB8E082.8050100@icyb.net.ua> <20090922215700.V37424@ns1.as.pvp.se>
	<4ABA1D1F.3080704@icyb.net.ua> <20090923171004.Q37424@ns1.as.pvp.se>
	<4ABA457E.3060800@freebsd.org> <20090924141927.Y37424@ns1.as.pvp.se>
	<20090925110209.E37424@ns1.as.pvp.se> <4ABC894E.7040204@freebsd.org>
Message-ID: <20090928092026.B37424@ns1.as.pvp.se>



On Fri, 25 Sep 2009, Andriy Gapon wrote:

> on 25/09/2009 12:04 kama said the following:
> > On Thu, 24 Sep 2009, kama wrote:
> >
> >> I am currently building the source on another machine. Lets see if it will
> >> build it any better.
> >
> > Building the the world on another machine and install it on the DL385
> > machine made it also to freeze.
>
> Did you still get the message about unresolved symbol?

I did not try with ACPI_DEBUG enabled.

Another week, so I can start testing again...

/Bjorn
From avg at freebsd.org  Mon Sep 28 08:07:58 2009
From: avg at freebsd.org (Andriy Gapon)
Date: Mon Sep 28 08:08:10 2009
Subject: FreeBSD 7.2-STABLE boot freeze
In-Reply-To: <20090928092026.B37424@ns1.as.pvp.se>
References: <20090921140345.H37424@ns1.as.pvp.se>
	<20090922103150.V37424@ns1.as.pvp.se>
	<4AB8A95E.3060307@icyb.net.ua>
	<20090922142526.P37424@ns1.as.pvp.se>
	<4AB8E082.8050100@icyb.net.ua>
	<20090922215700.V37424@ns1.as.pvp.se>
	<4ABA1D1F.3080704@icyb.net.ua>
	<20090923171004.Q37424@ns1.as.pvp.se>
	<4ABA457E.3060800@freebsd.org>
	<20090924141927.Y37424@ns1.as.pvp.se>
	<20090925110209.E37424@ns1.as.pvp.se>
	<4ABC894E.7040204@freebsd.org>
	<20090928092026.B37424@ns1.as.pvp.se>
Message-ID: <4AC06ED6.7030402@freebsd.org>

on 28/09/2009 10:21 kama said the following:
> 
> On Fri, 25 Sep 2009, Andriy Gapon wrote:
> 
>> on 25/09/2009 12:04 kama said the following:
>>> On Thu, 24 Sep 2009, kama wrote:
>>>
>>>> I am currently building the source on another machine. Lets see if it will
>>>> build it any better.
>>> Building the the world on another machine and install it on the DL385
>>> machine made it also to freeze.
>> Did you still get the message about unresolved symbol?
> 
> I did not try with ACPI_DEBUG enabled.
> 
> Another week, so I can start testing again...

I did not ask that :-)
I asked -  when you got your latest freeze, did you see that 'unresolved'
message or not?


-- 
Andriy Gapon
From attilio at freebsd.org  Mon Sep 28 08:34:09 2009
From: attilio at freebsd.org (Attilio Rao)
Date: Mon Sep 28 08:34:15 2009
Subject: 7.2-release/amd64: panic, spin lock held too long
In-Reply-To: <4AC02DE3.9000901@gmail.com>
References: <cf9b1ee00907061812r3da70018i1c8d8d12bb038a80@mail.gmail.com>
	<3bbf2fe10909170216u29d994aj55c21efdfbc26ba5@mail.gmail.com>
	<4AB21005.6040104@gmail.com> <4AB36E1F.6080401@gmail.com>
	<cf9b1ee00909190204q33ded00dyb86a4b53ed5194be@mail.gmail.com>
	<3bbf2fe10909191224m6061d325h8bc1a389e195aa30@mail.gmail.com>
	<4AB8318D.5000404@gmail.com>
	<3bbf2fe10909211910r2ed6957cvb1f7f226e2a8b89d@mail.gmail.com>
	<4AB8458C.8000404@gmail.com> <4AC02DE3.9000901@gmail.com>
Message-ID: <3bbf2fe10909280134q5a35b173i2cca869edda3e7c7@mail.gmail.com>

2009/9/28 C. C. Tang <hiyorin@gmail.com>:
> C. C. Tang wrote:
>>
>> Attilio Rao wrote:
>>>
>>> 2009/9/22 C. C. Tang <hiyorin@gmail.com>:
>>>>>>>>>
>>>>>>> I have patched the sched_ule.c and did a make buildkernel & make
>>>>>>> installkernel (is buildworld and installworld necessary?), rebooted
>>>>>>> and
>>>>>>> the
>>>>>>> machine is running now.
>>>>>>> I will post here again if there is any update.
>>>>
>>>> My server is up for 3.5 days now with HyperThreading & powerd enabled.
>>>> No panic occured yet.
>>>
>>> Usually how long did it take to panic?
>>>
>>> Attilio
>>>
>>>
>> It is rather random, but will usually panic within one week.
>> Anyway my server will keep running and I will report if it has any
>> problem.
>>
>> Thanks,
>> C.C.
>>
> My server is up for 9.5 days now. Seems working fine.

The patch has been committed to STABLE_7 as well.

Attilio


-- 
Peace can only be achieved by understanding - A. Einstein
From pjd at FreeBSD.org  Mon Sep 28 08:40:39 2009
From: pjd at FreeBSD.org (Pawel Jakub Dawidek)
Date: Mon Sep 28 08:40:51 2009
Subject: glabel+gmirror (8.0-RC1 problem)
In-Reply-To: <20090927223725.5893371f.lehmann@ans-netz.de>
References: <20090927170244.0980d699.lehmann@ans-netz.de>
	<20090927223725.5893371f.lehmann@ans-netz.de>
Message-ID: <20090928084035.GB1659@garage.freebsd.pl>

On Sun, Sep 27, 2009 at 10:37:25PM +0200, Oliver Lehmann wrote:
> Hi,
> 
> that gmirror together with glabel cannot be used looks like a problem
> introduced with 8.0-RC1 to me.
[...]

Does anything change between you upgrade from BETA3 and RC1? For example
gmirror was compiled into the kernel before and now is loaded as module
or something similar?

Could you test this patch:

	http://people.freebsd.org/~pjd/patches/improved_taste.patch

-- 
Pawel Jakub Dawidek                       http://www.wheel.pl
pjd@FreeBSD.org                           http://www.FreeBSD.org
FreeBSD committer                         Am I Evil? Yes, I Am!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090928/1e9d1097/attachment.pgp
From gavin at FreeBSD.org  Mon Sep 28 09:19:54 2009
From: gavin at FreeBSD.org (Gavin Atkinson)
Date: Mon Sep 28 09:20:01 2009
Subject: locate(1) ZFS addition
In-Reply-To: <alpine.BSF.2.00.0909272328400.62818@qvzrafvba.5c.ybpny>
References: <alpine.BSF.2.00.0909272328400.62818@qvzrafvba.5c.ybpny>
Message-ID: <1254129590.74561.13.camel@buffy.york.ac.uk>

On Sun, 2009-09-27 at 23:37 -0400, CmdLnKid wrote:
> I just came across what I believe to be just a oversight on locate(1). By 
> default as stated in its locate.rc file in /etc it states that the default 
> file systems that will be searched is "ufs ext2fs". Would it be wise to have the 
> default be "ufs zfs xfs ext2fs" ? or some other combination.

It appears to be a little more confused than that.  In 8.x and 7.2, the
list of filesystems that are actually searched are "ufs ext2fs zfs".
The comment in the default /etc/locate.rc lists those, and also xfs.

The real problem seems to be that /etc/locate.rc seems to be missed by
mergemaster, and so updates to it aren't being picked up.  However, from
a quick inspection, I can't see why.

I think it would be a good idea to file a PR so that this doesn't get
lost.

Gavin
From des at des.no  Mon Sep 28 09:39:53 2009
From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=)
Date: Mon Sep 28 09:40:00 2009
Subject: glabel+gmirror (8.0-RC1 problem)
References: <20090927170244.0980d699.lehmann@ans-netz.de>
	<20090927223725.5893371f.lehmann@ans-netz.de>
	<20090928084035.GB1659@garage.freebsd.pl>
Message-ID: <86bpkv5sp3.fsf@ds4.des.no>

Pawel Jakub Dawidek <pjd@FreeBSD.org> writes:
> Oliver Lehmann <lehmann@ans-netz.de> writes:
> > that gmirror together with glabel cannot be used looks like a
> > problem introduced with 8.0-RC1 to me.
> Does anything change between you upgrade from BETA3 and RC1?  For
> example gmirror was compiled into the kernel before and now is loaded
> as module or something similar?

Looks like the same issue I mentioned to you (pjd) last night.  In my
case, it was an upgrade from a week-old head to last night's head, and
the only change was that the new kernel had NFS compiled in.  Both the
old and the new kernel loaded geom_label and geom_mirror as modules.

> Could you test this patch:
>
> 	http://people.freebsd.org/~pjd/patches/improved_taste.patch

Works for me.

DES
-- 
Dag-Erling Sm?rgrav - des@des.no
From ru at FreeBSD.org  Mon Sep 28 09:45:58 2009
From: ru at FreeBSD.org (Ruslan Ermilov)
Date: Mon Sep 28 09:46:05 2009
Subject: locate(1) ZFS addition
In-Reply-To: <alpine.BSF.2.00.0909272328400.62818@qvzrafvba.5c.ybpny>
References: <alpine.BSF.2.00.0909272328400.62818@qvzrafvba.5c.ybpny>
Message-ID: <20090928092238.GA68319@edoofus.dev.vega.ru>

On Sun, Sep 27, 2009 at 11:37:14PM -0400, CmdLnKid wrote:
> I just came across what I believe to be just a oversight on locate(1). By 
> default as stated in its locate.rc file in /etc it states that the default 
> file systems that will be searched is "ufs ext2fs".
> 
> Would it be wise to have the 
> default be "ufs zfs xfs ext2fs" ? or some other combination.
> 
> PS: Should a PR be filed for this ?

The default list is actually "ufs ext2fs zfs" for RELENG_7 now,
it's just that the comment hasn't been updated.  For HEAD and
RELENG_8, "the default list contains all local file systems that
are not synthetic, loopback mounts, or read-only, according to
lsvfs."


Cheers,
-- 
Ruslan Ermilov
ru@FreeBSD.org
FreeBSD committer
From ornoph at gmail.com  Mon Sep 28 10:15:52 2009
From: ornoph at gmail.com (Dennis Chikin)
Date: Mon Sep 28 10:16:26 2009
Subject: PATA disks/DVD not detected on ATI IXP 700 - cannot boot (dmesg
	attached)
In-Reply-To: <4ABC5962.80404@yandex.ru>
References: <20090916161327.GB87631@zod.isi.edu>
	<20090919035214.GA12889@zod.isi.edu>
	<200909211239.25614.jkim@FreeBSD.org> <4AB9A3CE.4090509@yandex.ru>
	<dde89ecd0909242239j4ecebc3dsfef5ec265237b5b3@mail.gmail.com>
	<4ABC5962.80404@yandex.ru>
Message-ID: <dde89ecd0909280247t3f14034cj2f81cb5019ee0264@mail.gmail.com>

> Is it means that all works with this patch?

No visible ata-specific faults encountered after loading the kernel.

> Can you show dmesg from patched system?


Copyright (c) 1992-2009 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
	The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 7.2-RELEASE-p3 #0: Sun Sep 27 23:57:27 YEKST 2009
    root@hq.sps.org:/work/usr/obj/work/usr/src/sys/GENERIC
Preloaded elf kernel "/boot/kernel/kernel" at 0xc0882000.
Preloaded elf module "/boot/kernel/acpi.ko" at 0xc0882188.
Calibrating clock(s) ... i8254 clock: 1193131 Hz
CLK_USE_I8254_CALIBRATION not specified - using default frequency
Timecounter "i8254" frequency 1193182 Hz quality 0
Calibrating TSC clock ... TSC clock: 3100300862 Hz
CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 6000+ (3100.30-MHz 686-class CPU)
  Origin = "AuthenticAMD"  Id = 0x60fb2  Stepping = 2
  Features=0x178bfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT>
  Features2=0x2001<SSE3,CX16>
  AMD Features=0xea500800<SYSCALL,NX,MMX+,FFXSR,RDTSCP,LM,3DNow!+,3DNow!>
  AMD Features2=0x11f<LAHF,CMP,SVM,ExtAPIC,CR8,Prefetch>
  TSC: P-state invariant
  Cores per package: 2
Data TLB: 32 entries, fully associative
Instruction TLB: 32 entries, fully associative
L1 data cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative
L1 instruction cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative
L2 internal cache: 512 kbytes, 64 bytes/line, 1 lines/tag, 8-way associative
real memory  = 1610285056 (1535 MB)
Physical memory chunk(s):
0x0000000000001000 - 0x000000000009efff, 647168 bytes (158 pages)
0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages)
0x0000000000c25000 - 0x000000005e460fff, 1568915456 bytes (383036 pages)
avail memory = 1568407552 (1495 MB)
Table 'FACP' at 0x5ffb0290
Table 'APIC' at 0x5ffb0390
MADT: Found table at 0x5ffb0390
MP Configuration Table version 1.4 found at 0xc00fcd20
APIC: Using the MADT enumerator.
MADT: Found CPU APIC ID 0 ACPI ID 1: enabled
SMP: Added CPU 0 (AP)
MADT: Found CPU APIC ID 1 ACPI ID 2: enabled
SMP: Added CPU 1 (AP)
MADT: Found CPU APIC ID 130 ACPI ID 3: disabled
MADT: Found CPU APIC ID 131 ACPI ID 4: disabled
ACPI APIC Table: <092208 APIC1629>
INTR: Adding local APIC 1 as a target
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
 cpu0 (BSP): APIC ID:  0
 cpu1 (AP): APIC ID:  1
bios32: Found BIOS32 Service Directory header at 0xc00f0000
bios32: Entry = 0xf0010 (c00f0010)  Rev = 0  Len = 1
pcibios: PCI BIOS entry at 0xf0000+0x31
pnpbios: Found PnP BIOS data at 0xc00f4ea0
pnpbios: Entry = f0000:660a  Rev = 1.0
Other BIOS signatures found:
APIC: CPU 0 has ACPI ID 1
APIC: CPU 1 has ACPI ID 2
ULE: setup cpu group 0
ULE: setup cpu 0
ULE: adding cpu 0 to group 0: cpus 1 mask 0x1
ULE: setup cpu group 1
ULE: setup cpu 1
ULE: adding cpu 1 to group 1: cpus 1 mask 0x2
ACPI: RSDP @ 0x0xf9d90/0x0024 (v  2 ACPIAM)
ACPI: XSDT @ 0x0x5ffb0100/0x0054 (v  1 092208 XSDT1629 0x20080922 MSFT
0x00000097)
ACPI: FACP @ 0x0x5ffb0290/0x00F4 (v  3 092208 FACP1629 0x20080922 MSFT
0x00000097)
ACPI: DSDT @ 0x0x5ffb0440/0x7214 (v  1  A78GM A78GM922 0x00000004 INTL
0x20051117)
ACPI: FACS @ 0x0x5ffbe000/0x0040
ACPI: APIC @ 0x0x5ffb0390/0x006C (v  1 092208 APIC1629 0x20080922 MSFT
0x00000097)
ACPI: MCFG @ 0x0x5ffb0400/0x003C (v  1 092208 OEMMCFG  0x20080922 MSFT
0x00000097)
ACPI: OEMB @ 0x0x5ffbe040/0x0071 (v  1 092208 OEMB1629 0x20080922 MSFT
0x00000097)
ACPI: HPET @ 0x0x5ffb7660/0x0038 (v  1 092208 OEMHPET  0x20080922 MSFT
0x00000097)
ACPI: SSDT @ 0x0x5ffb76a0/0x0350 (v  1 A M I  POWERNOW 0x00000001 AMD
0x00000001)
MADT: Found IO APIC ID 2, Interrupt 0 at 0xfec00000
ioapic0: Routing external 8259A's -> intpin 0
MADT: Interrupt override: source 0, irq 2
ioapic0: Routing IRQ 0 -> intpin 2
MADT: Interrupt override: source 9, irq 9
ioapic0: intpin 9 trigger: level
ioapic0: intpin 9 polarity: low
ioapic0 <Version 2.1> irqs 0-23 on motherboard
cpu0 BSP:
     ID: 0x00000000   VER: 0x80050010 LDR: 0x00000000 DFR: 0xffffffff
  lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff
  timer: 0x000100ef therm: 0x00010000 err: 0x0001000f pcm: 0x00010000
io: <I/O>
null: <null device, zero device>
kbd: new array size 4
kbd1 at kbdmux0
random: <entropy source, Software, Yarrow>
mem: <memory>
Pentium Pro MTRR support enabled
npx0: INT 16 interface
acpi0: <092208 XSDT1629> on motherboard
ioapic0: routing intpin 9 (ISA IRQ 9) to vector 48
acpi0: [MPSAFE]
acpi0: [ITHREAD]
acpi0: Power Button (fixed)
acpi0: wakeup code va 0xc439b000 pa 0x1000
pci_open(1):	mode 1 addr port (0x0cf8) is 0x8000a078
pci_open(1a):	mode1res=0x80000000 (0x80000000)
pci_cfgcheck:	device 0 [class=060000] [hdr=00] is there (id=96001022)
pcibios: BIOS version 3.00
AcpiOsDerivePciId: \\_SB_.PCI0.RS78.NB2_ -> bus 0 dev 0 func 0
acpi: bad write to port 0x000 (8), val 0x5a
acpi: bad write to port 0x000 (8), val 0x5a
acpi: bad write to port 0x000 (8), val 0x7
acpi: bad write to port 0x001 (8), val 0x7
acpi: bad write to port 0x000 (8), val 0x30
acpi: bad read from port 0x001 (8)
acpi: bad read from port 0x000 (8)
acpi: bad write to port 0x000 (8), val 0xa5
acpi: bad write to port 0x000 (8), val 0x5a
acpi: bad write to port 0x000 (8), val 0x5a
acpi: bad write to port 0x000 (8), val 0x7
acpi: bad write to port 0x001 (8), val 0x7
acpi: bad write to port 0x000 (8), val 0x30
acpi: bad read from port 0x001 (8)
acpi: bad read from port 0x000 (8)
acpi: bad write to port 0x000 (8), val 0xa5
acpi: bad write to port 0x000 (8), val 0x5a
acpi: bad write to port 0x000 (8), val 0x5a
acpi: bad write to port 0x000 (8), val 0x7
acpi: bad write to port 0x001 (8), val 0x7
acpi: bad write to port 0x000 (8), val 0x30
acpi: bad read from port 0x001 (8)
acpi: bad read from port 0x000 (8)
acpi: bad write to port 0x000 (8), val 0xa5
acpi: bad write to port 0x000 (8), val 0x5a
acpi: bad write to port 0x000 (8), val 0x5a
acpi: bad write to port 0x000 (8), val 0x7
acpi: bad write to port 0x001 (8), val 0x7
acpi: bad write to port 0x000 (8), val 0x30
acpi: bad read from port 0x001 (8)
acpi: bad read from port 0x000 (8)
acpi: bad write to port 0x000 (8), val 0xa5
acpi: bad write to port 0x000 (8), val 0x5a
acpi: bad write to port 0x000 (8), val 0x5a
acpi: bad write to port 0x000 (8), val 0x7
acpi: bad write to port 0x001 (8), val 0x7
acpi: bad write to port 0x000 (8), val 0x30
acpi: bad read from port 0x001 (8)
acpi: bad read from port 0x000 (8)
acpi: bad write to port 0x000 (8), val 0xa5
acpi: bad write to port 0x000 (8), val 0x5a
acpi: bad write to port 0x000 (8), val 0x5a
acpi: bad write to port 0x000 (8), val 0x7
acpi: bad write to port 0x001 (8), val 0x7
acpi: bad write to port 0x000 (8), val 0x30
acpi: bad read from port 0x001 (8)
acpi: bad read from port 0x000 (8)
acpi: bad write to port 0x000 (8), val 0xa5
acpi: bad write to port 0x000 (8), val 0x5a
acpi: bad write to port 0x000 (8), val 0x5a
acpi: bad write to port 0x000 (8), val 0x7
acpi: bad write to port 0x001 (8), val 0x7
acpi: bad write to port 0x000 (8), val 0x30
acpi: bad read from port 0x001 (8)
acpi: bad read from port 0x000 (8)
acpi: bad write to port 0x000 (8), val 0xa5
acpi: bad write to port 0x000 (8), val 0x5a
acpi: bad write to port 0x000 (8), val 0x5a
acpi: bad write to port 0x000 (8), val 0x7
acpi: bad write to port 0x001 (8), val 0x7
acpi: bad write to port 0x000 (8), val 0x30
acpi: bad read from port 0x001 (8)
acpi: bad read from port 0x000 (8)
acpi: bad write to port 0x000 (8), val 0xa5
acpi: bad write to port 0x000 (8), val 0x5a
acpi: bad write to port 0x000 (8), val 0x5a
acpi: bad write to port 0x000 (8), val 0x7
acpi: bad write to port 0x001 (8), val 0x7
acpi: bad write to port 0x000 (8), val 0x30
acpi: bad read from port 0x001 (8)
acpi: bad read from port 0x000 (8)
acpi: bad write to port 0x000 (8), val 0xa5
acpi: bad write to port 0x000 (8), val 0x5a
acpi: bad write to port 0x000 (8), val 0x5a
acpi: bad write to port 0x000 (8), val 0x7
acpi: bad write to port 0x001 (8), val 0x7
acpi: bad write to port 0x000 (8), val 0x30
acpi: bad read from port 0x001 (8)
acpi: bad read from port 0x000 (8)
acpi: bad write to port 0x000 (8), val 0xa5
AcpiOsDerivePciId: \\_SB_.PCI0.SATA.SACS -> bus 0 dev 17 func 0
acpi: bad write to port 0x000 (8), val 0x5a
acpi: bad write to port 0x000 (8), val 0x5a
acpi: bad write to port 0x000 (8), val 0x7
acpi: bad write to port 0x001 (8), val 0x7
acpi: bad write to port 0x000 (8), val 0x30
acpi: bad read from port 0x001 (8)
acpi: bad read from port 0x000 (8)
acpi: bad write to port 0x000 (8), val 0xa5
acpi: bad write to port 0x000 (8), val 0x5a
acpi: bad write to port 0x000 (8), val 0x5a
acpi: bad write to port 0x000 (8), val 0x7
acpi: bad write to port 0x001 (8), val 0x7
acpi: bad write to port 0x000 (8), val 0x30
acpi: bad read from port 0x001 (8)
acpi: bad read from port 0x000 (8)
acpi: bad write to port 0x000 (8), val 0xa5
acpi: bad write to port 0x000 (8), val 0x5a
acpi: bad write to port 0x000 (8), val 0x5a
acpi: bad write to port 0x000 (8), val 0x7
acpi: bad write to port 0x001 (8), val 0x7
acpi: bad write to port 0x000 (8), val 0x30
acpi: bad read from port 0x001 (8)
acpi: bad read from port 0x000 (8)
acpi: bad write to port 0x000 (8), val 0xa5
acpi: bad write to port 0x000 (8), val 0x5a
acpi: bad write to port 0x000 (8), val 0x5a
acpi: bad write to port 0x000 (8), val 0x7
acpi: bad write to port 0x001 (8), val 0x7
acpi: bad write to port 0x000 (8), val 0x30
acpi: bad read from port 0x001 (8)
acpi: bad read from port 0x000 (8)
acpi: bad write to port 0x000 (8), val 0xa5
acpi0: reservation of fee00000, 1000 (3) failed
acpi0: reservation of ffb80000, 80000 (3) failed
acpi0: reservation of fec10000, 20 (3) failed
acpi0: reservation of 0, a0000 (3) failed
acpi0: reservation of 100000, 5ff00000 (3) failed
ACPI HPET table warning: Sequence is non-zero (2)
ACPI timer: 0/3 0/5 0/3 0/3 1/2 0/3 0/4 0/3 0/3 0/3 -> 1
Timecounter "ACPI-safe" frequency 3579545 Hz quality 850
acpi_timer0: <32-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0
pci_link0:        Index  IRQ  Rtd  Ref  IRQs
  Initial Probe       0   10   N     0  4 7 10 11 12 14 15
  Validation          0   10   N     0  4 7 10 11 12 14 15
  After Disable       0  255   N     0  4 7 10 11 12 14 15
pci_link1:        Index  IRQ  Rtd  Ref  IRQs
  Initial Probe       0   11   N     0  4 7 10 11 12 14 15
  Validation          0   11   N     0  4 7 10 11 12 14 15
  After Disable       0  255   N     0  4 7 10 11 12 14 15
pci_link2:        Index  IRQ  Rtd  Ref  IRQs
  Initial Probe       0   11   N     0  4 7 10 11 12 14 15
  Validation          0   11   N     0  4 7 10 11 12 14 15
  After Disable       0  255   N     0  4 7 10 11 12 14 15
pci_link3:        Index  IRQ  Rtd  Ref  IRQs
  Initial Probe       0   10   N     0  4 7 10 11 12 14 15
  Validation          0   10   N     0  4 7 10 11 12 14 15
  After Disable       0  255   N     0  4 7 10 11 12 14 15
pci_link4:        Index  IRQ  Rtd  Ref  IRQs
  Initial Probe       0  255   N     0  4 7 10 11 12 14 15
  Validation          0  255   N     0  4 7 10 11 12 14 15
  After Disable       0  255   N     0  4 7 10 11 12 14 15
pci_link5:        Index  IRQ  Rtd  Ref  IRQs
  Initial Probe       0  255   N     0  4 7 10 11 12 14 15
  Validation          0  255   N     0  4 7 10 11 12 14 15
  After Disable       0  255   N     0  4 7 10 11 12 14 15
pci_link6:        Index  IRQ  Rtd  Ref  IRQs
  Initial Probe       0   10   N     0  4 10 11 12 14 15
  Validation          0   10   N     0  4 10 11 12 14 15
  After Disable       0  255   N     0  4 10 11 12 14 15
pci_link7:        Index  IRQ  Rtd  Ref  IRQs
  Initial Probe       0  255   N     0  4 7 10 11 12 14 15
  Validation          0  255   N     0  4 7 10 11 12 14 15
  After Disable       0  255   N     0  4 7 10 11 12 14 15
acpi_hpet0: <High Precision Event Timer> iomem 0xfed00000-0xfed003ff on acpi0
acpi_hpet0: vend: 0x4353 rev: 0x1 num: 3 hz: 14318180 opts: legacy_route
Timecounter "HPET" frequency 14318180 Hz quality 900
pcib0: <ACPI Host-PCI bridge> port 0xcf8-0xcff on acpi0
pci0: <ACPI PCI bus> on pcib0
pci0: domain=0, physical bus=0
found->	vendor=0x1022, dev=0x9600, revid=0x00
	domain=0, bus=0, slot=0, func=0
	class=06-00-00, hdrtype=0x00, mfdev=0
	cmdreg=0x0006, statreg=0x2230, cachelnsz=0 (dwords)
	lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
found->	vendor=0x1022, dev=0x9602, revid=0x00
	domain=0, bus=0, slot=1, func=0
	class=06-04-00, hdrtype=0x01, mfdev=0
	cmdreg=0x0107, statreg=0x0230, cachelnsz=0 (dwords)
	lattimer=0x40 (1920 ns), mingnt=0x1a (6500 ns), maxlat=0x00 (0 ns)
found->	vendor=0x1022, dev=0x9607, revid=0x00
	domain=0, bus=0, slot=7, func=0
	class=06-04-00, hdrtype=0x01, mfdev=0
	cmdreg=0x0107, statreg=0x0010, cachelnsz=16 (dwords)
	lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x00 (0 ns)
	intpin=a, irq=10
	powerspec 3  supports D0 D3  current D0
	MSI supports 1 message
pcib0: matched entry for 0.7.INTA
pcib0: slot 7 INTA hardwired to IRQ 19
found->	vendor=0x1002, dev=0x4390, revid=0x00
	domain=0, bus=0, slot=17, func=0
	class=01-01-8f, hdrtype=0x00, mfdev=0
	cmdreg=0x0107, statreg=0x0230, cachelnsz=16 (dwords)
	lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
	intpin=a, irq=10
	powerspec 2  supports D0 D3  current D0
	map[10]: type I/O Port, range 32, base 0xc000, size  3, enabled
	map[14]: type I/O Port, range 32, base 0xb000, size  2, enabled
	map[18]: type I/O Port, range 32, base 0xa000, size  3, enabled
	map[1c]: type I/O Port, range 32, base 0x9000, size  2, enabled
	map[20]: type I/O Port, range 32, base 0x8000, size  4, enabled
	map[24]: type Memory, range 32, base 0xfe8ff800, size 10, enabled
pcib0: matched entry for 0.17.INTA
pcib0: slot 17 INTA hardwired to IRQ 22
found->	vendor=0x1002, dev=0x4397, revid=0x00
	domain=0, bus=0, slot=18, func=0
	class=0c-03-10, hdrtype=0x00, mfdev=1
	cmdreg=0x0117, statreg=0x02a0, cachelnsz=16 (dwords)
	lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
	intpin=a, irq=10
	map[10]: type Memory, range 32, base 0xfe8fe000, size 12, enabled
pcib0: matched entry for 0.18.INTA
pcib0: slot 18 INTA hardwired to IRQ 16
found->	vendor=0x1002, dev=0x4398, revid=0x00
	domain=0, bus=0, slot=18, func=1
	class=0c-03-10, hdrtype=0x00, mfdev=0
	cmdreg=0x0117, statreg=0x02a0, cachelnsz=16 (dwords)
	lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
	intpin=a, irq=10
	map[10]: type Memory, range 32, base 0xfe8fd000, size 12, enabled
pcib0: matched entry for 0.18.INTA
pcib0: slot 18 INTA hardwired to IRQ 16
found->	vendor=0x1002, dev=0x4396, revid=0x00
	domain=0, bus=0, slot=18, func=2
	class=0c-03-20, hdrtype=0x00, mfdev=0
	cmdreg=0x0102, statreg=0x02b0, cachelnsz=16 (dwords)
	lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
	intpin=b, irq=11
	powerspec 2  supports D0 D1 D2 D3  current D0
	map[10]: type Memory, range 32, base 0xfe8ff000, size  8, enabled
pcib0: matched entry for 0.18.INTB
pcib0: slot 18 INTB hardwired to IRQ 17
found->	vendor=0x1002, dev=0x4397, revid=0x00
	domain=0, bus=0, slot=19, func=0
	class=0c-03-10, hdrtype=0x00, mfdev=1
	cmdreg=0x0117, statreg=0x02a0, cachelnsz=16 (dwords)
	lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
	intpin=a, irq=11
	map[10]: type Memory, range 32, base 0xfe8fc000, size 12, enabled
pcib0: matched entry for 0.19.INTA
pcib0: slot 19 INTA hardwired to IRQ 18
found->	vendor=0x1002, dev=0x4398, revid=0x00
	domain=0, bus=0, slot=19, func=1
	class=0c-03-10, hdrtype=0x00, mfdev=0
	cmdreg=0x0117, statreg=0x02a0, cachelnsz=16 (dwords)
	lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
	intpin=a, irq=11
	map[10]: type Memory, range 32, base 0xfe8fb000, size 12, enabled
pcib0: matched entry for 0.19.INTA
pcib0: slot 19 INTA hardwired to IRQ 18
found->	vendor=0x1002, dev=0x4396, revid=0x00
	domain=0, bus=0, slot=19, func=2
	class=0c-03-20, hdrtype=0x00, mfdev=0
	cmdreg=0x0117, statreg=0x02b0, cachelnsz=16 (dwords)
	lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
	intpin=b, irq=10
	powerspec 2  supports D0 D1 D2 D3  current D0
	map[10]: type Memory, range 32, base 0xfe8fa800, size  8, enabled
pcib0: matched entry for 0.19.INTB
pcib0: slot 19 INTB hardwired to IRQ 19
found->	vendor=0x1002, dev=0x4385, revid=0x3a
	domain=0, bus=0, slot=20, func=0
	class=0c-05-00, hdrtype=0x00, mfdev=1
	cmdreg=0x0403, statreg=0xd230, cachelnsz=0 (dwords)
	lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
found->	vendor=0x1002, dev=0x439c, revid=0x00
	domain=0, bus=0, slot=20, func=1
	class=01-01-8a, hdrtype=0x00, mfdev=0
	cmdreg=0x0005, statreg=0x0230, cachelnsz=0 (dwords)
	lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
	intpin=a, irq=255
	MSI supports 2 messages
	map[20]: type I/O Port, range 32, base 0xff00, size  4, enabled
found->	vendor=0x1002, dev=0x4383, revid=0x00
	domain=0, bus=0, slot=20, func=2
	class=04-03-00, hdrtype=0x00, mfdev=0
	cmdreg=0x0006, statreg=0x0410, cachelnsz=16 (dwords)
	lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
	intpin=a, irq=10
	powerspec 2  supports D0 D3  current D0
	map[10]: type Memory, range 64, base 0xfe8f4000, size 14, enabled
pcib0: matched entry for 0.20.INTA
pcib0: slot 20 INTA hardwired to IRQ 16
found->	vendor=0x1002, dev=0x439d, revid=0x00
	domain=0, bus=0, slot=20, func=3
	class=06-01-00, hdrtype=0x00, mfdev=1
	cmdreg=0x000f, statreg=0x0220, cachelnsz=0 (dwords)
	lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
found->	vendor=0x1002, dev=0x4384, revid=0x00
	domain=0, bus=0, slot=20, func=4
	class=06-04-01, hdrtype=0x01, mfdev=1
	cmdreg=0x0105, statreg=0x02a0, cachelnsz=0 (dwords)
	lattimer=0x40 (1920 ns), mingnt=0x03 (750 ns), maxlat=0x00 (0 ns)
found->	vendor=0x1002, dev=0x4399, revid=0x00
	domain=0, bus=0, slot=20, func=5
	class=0c-03-10, hdrtype=0x00, mfdev=0
	cmdreg=0x0117, statreg=0x02a0, cachelnsz=16 (dwords)
	lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
	intpin=c, irq=11
	map[10]: type Memory, range 32, base 0xfe8f9000, size 12, enabled
pcib0: matched entry for 0.20.INTC
pcib0: slot 20 INTC hardwired to IRQ 18
found->	vendor=0x1022, dev=0x1100, revid=0x00
	domain=0, bus=0, slot=24, func=0
	class=06-00-00, hdrtype=0x00, mfdev=1
	cmdreg=0x0000, statreg=0x0010, cachelnsz=0 (dwords)
	lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
found->	vendor=0x1022, dev=0x1101, revid=0x00
	domain=0, bus=0, slot=24, func=1
	class=06-00-00, hdrtype=0x00, mfdev=1
	cmdreg=0x0000, statreg=0x0000, cachelnsz=0 (dwords)
	lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
found->	vendor=0x1022, dev=0x1102, revid=0x00
	domain=0, bus=0, slot=24, func=2
	class=06-00-00, hdrtype=0x00, mfdev=1
	cmdreg=0x0000, statreg=0x0000, cachelnsz=0 (dwords)
	lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
found->	vendor=0x1022, dev=0x1103, revid=0x00
	domain=0, bus=0, slot=24, func=3
	class=06-00-00, hdrtype=0x00, mfdev=1
	cmdreg=0x0000, statreg=0x0010, cachelnsz=0 (dwords)
	lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
pcib1: <ACPI PCI-PCI bridge> at device 1.0 on pci0
pcib1:   domain            0
pcib1:   secondary bus     1
pcib1:   subordinate bus   1
pcib1:   I/O decode        0xd000-0xdfff
pcib1:   memory decode     0xfe900000-0xfeafffff
pcib1:   prefetched decode 0xd0000000-0xdfffffff
pci1: <ACPI PCI bus> on pcib1
pci1: domain=0, physical bus=1
found->	vendor=0x1002, dev=0x9610, revid=0x00
	domain=0, bus=1, slot=5, func=0
	class=03-00-00, hdrtype=0x00, mfdev=1
	cmdreg=0x0107, statreg=0x4010, cachelnsz=16 (dwords)
	lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
	intpin=a, irq=11
	powerspec 3  supports D0 D1 D2 D3  current D0
	MSI supports 1 message, 64 bit
	map[10]: type Prefetchable Memory, range 32, base 0xd0000000, size 28, enabled
pcib1: requested memory range 0xd0000000-0xdfffffff: good
	map[14]: type I/O Port, range 32, base 0xd000, size  8, enabled
pcib1: requested I/O range 0xd000-0xd0ff: in range
	map[18]: type Memory, range 32, base 0xfeaf0000, size 16, enabled
pcib1: requested memory range 0xfeaf0000-0xfeafffff: good
	map[24]: type Memory, range 32, base 0xfe900000, size 20, enabled
pcib1: requested memory range 0xfe900000-0xfe9fffff: good
pcib1: matched entry for 1.5.INTA
pcib1: slot 5 INTA hardwired to IRQ 18
found->	vendor=0x1002, dev=0x960f, revid=0x00
	domain=0, bus=1, slot=5, func=1
	class=04-03-00, hdrtype=0x00, mfdev=1
	cmdreg=0x0107, statreg=0x4010, cachelnsz=16 (dwords)
	lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
	intpin=b, irq=10
	powerspec 3  supports D0 D1 D2 D3  current D0
	MSI supports 1 message, 64 bit
	map[10]: type Memory, range 32, base 0xfeae8000, size 14, enabled
pcib1: requested memory range 0xfeae8000-0xfeaebfff: good
pcib1: matched entry for 1.5.INTB
pcib1: slot 5 INTB hardwired to IRQ 19
vgapci0: <VGA-compatible display> port 0xd000-0xd0ff mem
0xd0000000-0xdfffffff,0xfeaf0000-0xfeafffff,0xfe900000-0xfe9fffff irq
18 at device 5.0 on pci1
pci1: <multimedia, HDA> at device 5.1 (no driver attached)
pcib2: <ACPI PCI-PCI bridge> irq 19 at device 7.0 on pci0
pcib2:   domain            0
pcib2:   secondary bus     2
pcib2:   subordinate bus   2
pcib2:   I/O decode        0xe000-0xefff
pcib2:   memory decode     0xfeb00000-0xfebfffff
pcib2:   prefetched decode 0xfdf00000-0xfdffffff
pci2: <ACPI PCI bus> on pcib2
pci2: domain=0, physical bus=2
found->	vendor=0x10ec, dev=0x8168, revid=0x02
	domain=0, bus=2, slot=0, func=0
	class=02-00-00, hdrtype=0x00, mfdev=0
	cmdreg=0x0107, statreg=0x0010, cachelnsz=16 (dwords)
	lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
	intpin=a, irq=10
	powerspec 3  supports D0 D1 D2 D3  current D0
	MSI supports 1 message, 64 bit
	MSI-X supports 2 messages in map 0x20
	map[10]: type I/O Port, range 32, base 0xe800, size  8, enabled
pcib2: requested I/O range 0xe800-0xe8ff: in range
	map[18]: type Memory, range 64, base 0xfebff000, size 12, enabled
pcib2: requested memory range 0xfebff000-0xfebfffff: good
	map[20]: type Prefetchable Memory, range 64, base 0xfdff0000, size 16, enabled
pcib2: requested memory range 0xfdff0000-0xfdffffff: good
pcib2: matched entry for 2.0.INTA
pcib2: slot 0 INTA hardwired to IRQ 19
re0: <RealTek 8168/8168B/8168C/8168CP/8168D/8111B/8111C/8111CP PCIe
Gigabit Ethernet> port 0xe800-0xe8ff mem
0xfebff000-0xfebfffff,0xfdff0000-0xfdffffff irq 19 at device 0.0 on
pci2
re0: Reserved 0x1000 bytes for rid 0x18 type 3 at 0xfebff000
re0: MSI count : 1
re0: attempting to allocate 1 MSI vectors (1 supported)
msi: routing MSI IRQ 256 to vector 49
re0: using IRQ 256 for MSI
re0: Using 1 MSI messages
re0: Chip rev. 0x3c000000
re0: MAC rev. 0x00400000
miibus0: <MII bus> on re0
rgephy0: <RTL8169S/8110S/8211B media interface> PHY 1 on miibus0
rgephy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT,
1000baseT-FDX, auto
re0: bpf attached
re0: Ethernet address: 00:e0:4d:a9:ad:dd
re0: [MPSAFE]
re0: [FILTER]
atapci0: <ATI (ID=43901002) AHCI controller> port
0xc000-0xc007,0xb000-0xb003,0xa000-0xa007,0x9000-0x9003,0x8000-0x800f
mem 0xfe8ff800-0xfe8ffbff irq 22 at device 17.0 on pci0
atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0x8000
atapci0: Reserved 0x400 bytes for rid 0x24 type 3 at 0xfe8ff800
ioapic0: routing intpin 22 (PCI IRQ 22) to vector 50
atapci0: [MPSAFE]
atapci0: [ITHREAD]
atapci0: AHCI Version 01.10 controller with 4 ports detected
ata2: <ATA channel 0> on atapci0
ata2: SATA connect time=0ms
ata2: SIGNATURE: 00000101
ata2: ahci_reset devices=0x1<ATA_MASTER>
ata2: [MPSAFE]
ata2: [ITHREAD]
ata3: <ATA channel 1> on atapci0
ata3: SATA connect status=00000000
ata3: ahci_reset devices=0x0
ata3: [MPSAFE]
ata3: [ITHREAD]
ata4: <ATA channel 2> on atapci0
ata4: SATA connect status=00000000
ata4: ahci_reset devices=0x0
ata4: [MPSAFE]
ata4: [ITHREAD]
ata5: <ATA channel 3> on atapci0
ata5: SATA connect status=00000000
ata5: ahci_reset devices=0x0
ata5: [MPSAFE]
ata5: [ITHREAD]
ohci0: <OHCI (generic) USB controller> mem 0xfe8fe000-0xfe8fefff irq
16 at device 18.0 on pci0
ohci0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xfe8fe000
ioapic0: routing intpin 16 (PCI IRQ 16) to vector 51
ohci0: [GIANT-LOCKED]
ohci0: [ITHREAD]
usb0: OHCI version 1.0, legacy support
usb0: <OHCI (generic) USB controller> on ohci0
usb0: USB revision 1.0
uhub0: <ATI OHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb0
uhub0: 3 ports with 3 removable, self powered
ohci1: <OHCI (generic) USB controller> mem 0xfe8fd000-0xfe8fdfff irq
16 at device 18.1 on pci0
ohci1: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xfe8fd000
ohci1: [GIANT-LOCKED]
ohci1: [ITHREAD]
usb1: OHCI version 1.0, legacy support
usb1: <OHCI (generic) USB controller> on ohci1
usb1: USB revision 1.0
uhub1: <ATI OHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb1
uhub1: 3 ports with 3 removable, self powered
ehci0: <EHCI (generic) USB 2.0 controller> mem 0xfe8ff000-0xfe8ff0ff
irq 17 at device 18.2 on pci0
ehci0: Reserved 0x100 bytes for rid 0x10 type 3 at 0xfe8ff000
ioapic0: routing intpin 17 (PCI IRQ 17) to vector 52
ehci0: [GIANT-LOCKED]
ehci0: [ITHREAD]
ehci0: Dropped interrupts workaround enabled
usb2: EHCI version 1.0
usb2: companion controllers, 3 ports each: usb0 usb1
usb2: <EHCI (generic) USB 2.0 controller> on ehci0
usb2: USB revision 2.0
uhub2: <ATI EHCI root hub, class 9/0, rev 2.00/1.00, addr 1> on usb2
uhub2: 6 ports with 6 removable, self powered
ohci2: <OHCI (generic) USB controller> mem 0xfe8fc000-0xfe8fcfff irq
18 at device 19.0 on pci0
ohci2: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xfe8fc000
ioapic0: routing intpin 18 (PCI IRQ 18) to vector 53
ohci2: [GIANT-LOCKED]
ohci2: [ITHREAD]
usb3: OHCI version 1.0, legacy support
usb3: <OHCI (generic) USB controller> on ohci2
usb3: USB revision 1.0
uhub3: <ATI OHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb3
uhub3: 3 ports with 3 removable, self powered
ohci3: <OHCI (generic) USB controller> mem 0xfe8fb000-0xfe8fbfff irq
18 at device 19.1 on pci0
ohci3: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xfe8fb000
ohci3: [GIANT-LOCKED]
ohci3: [ITHREAD]
usb4: OHCI version 1.0, legacy support
usb4: <OHCI (generic) USB controller> on ohci3
usb4: USB revision 1.0
uhub4: <ATI OHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb4
uhub4: 3 ports with 3 removable, self powered
ehci1: <EHCI (generic) USB 2.0 controller> mem 0xfe8fa800-0xfe8fa8ff
irq 19 at device 19.2 on pci0
ehci1: Reserved 0x100 bytes for rid 0x10 type 3 at 0xfe8fa800
ioapic0: routing intpin 19 (PCI IRQ 19) to vector 54
ehci1: [GIANT-LOCKED]
ehci1: [ITHREAD]
ehci1: Dropped interrupts workaround enabled
usb5: EHCI version 1.0
usb5: companion controllers, 3 ports each: usb3 usb4
usb5: <EHCI (generic) USB 2.0 controller> on ehci1
usb5: USB revision 2.0
uhub5: <ATI EHCI root hub, class 9/0, rev 2.00/1.00, addr 1> on usb5
uhub5: 6 ports with 6 removable, self powered
pci0: <serial bus, SMBus> at device 20.0 (no driver attached)
atapci1: <ATI IXP700 UDMA133 controller> port
0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xff00-0xff0f at device 20.1 on
pci0
atapci1: Reserved 0x10 bytes for rid 0x20 type 4 at 0xff00
ata0: <ATA channel 0> on atapci1
atapci1: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0
atapci1: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6
ata0: reset tp1 mask=03 ostat0=7f ostat1=7f
ata0: stat0=0x7f err=0xff lsb=0xff msb=0xff
ata0: stat0=0x7f err=0xff lsb=0xff msb=0xff
ata0: stat0=0x7f err=0xff lsb=0xff msb=0xff
ata0: stat0=0x7f err=0xff lsb=0xff msb=0xff
ata0: stat0=0x7f err=0xff lsb=0xff msb=0xff
ata0: stat0=0x7f err=0xff lsb=0xff msb=0xff
ata0: stat0=0x7f err=0xff lsb=0xff msb=0xff
ata0: stat0=0x7f err=0xff lsb=0xff msb=0xff
ata0: stat0=0x7f err=0xff lsb=0xff msb=0xff
ata0: stat0=0x7f err=0xff lsb=0xff msb=0xff
ata0: stat0=0x7f err=0xff lsb=0xff msb=0xff
ata0: stat0=0x7f err=0xff lsb=0xff msb=0xff
ata0: stat0=0x7f err=0xff lsb=0xff msb=0xff
ata0: stat0=0x7f err=0xff lsb=0xff msb=0xff
ata0: stat0=0x7f err=0xff lsb=0xff msb=0xff
ata0: stat0=0x7f err=0xff lsb=0xff msb=0xff
ata0: stat0=0x7f err=0xff lsb=0xff msb=0xff
ata0: stat0=0x7f err=0xff lsb=0xff msb=0xff
ata0: stat0=0x7f err=0xff lsb=0xff msb=0xff
ata0: stat0=0x7f err=0xff lsb=0xff msb=0xff
ata0: stat0=0x7f err=0xff lsb=0xff msb=0xff
ata0: stat0=0x7f err=0xff lsb=0xff msb=0xff
ata0: stat1=0x7f err=0xff lsb=0xff msb=0xff
ata0: reset tp2 stat0=ff stat1=ff devices=0x0
ioapic0: routing intpin 14 (ISA IRQ 14) to vector 55
ata0: [MPSAFE]
ata0: [ITHREAD]
ata1: <ATA channel 1> on atapci1
atapci1: Reserved 0x8 bytes for rid 0x18 type 4 at 0x170
atapci1: Reserved 0x1 bytes for rid 0x1c type 4 at 0x376
ata1: reset tp1 mask=03 ostat0=50 ostat1=50
ata1: stat0=0x50 err=0x01 lsb=0x00 msb=0x00
ata1: stat1=0x00 err=0x01 lsb=0x14 msb=0xeb
ata1: reset tp2 stat0=50 stat1=00 devices=0x9<ATAPI_SLAVE,ATA_MASTER>
ioapic0: routing intpin 15 (ISA IRQ 15) to vector 56
ata1: [MPSAFE]
ata1: [ITHREAD]
pci0: <multimedia, HDA> at device 20.2 (no driver attached)
isab0: <PCI-ISA bridge> at device 20.3 on pci0
isa0: <ISA bus> on isab0
pcib3: <ACPI PCI-PCI bridge> at device 20.4 on pci0
pcib3:   domain            0
pcib3:   secondary bus     3
pcib3:   subordinate bus   3
pcib3:   I/O decode        0xf000-0xfff
pcib3:   no prefetched decode
pcib3:   Subtractively decoded bridge.
pci3: <ACPI PCI bus> on pcib3
pci3: domain=0, physical bus=3
ohci4: <OHCI (generic) USB controller> mem 0xfe8f9000-0xfe8f9fff irq
18 at device 20.5 on pci0
ohci4: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xfe8f9000
ohci4: [GIANT-LOCKED]
ohci4: [ITHREAD]
usb6: OHCI version 1.0, legacy support
usb6: <OHCI (generic) USB controller> on ohci4
usb6: USB revision 1.0
uhub6: <ATI OHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb6
uhub6: 2 ports with 2 removable, self powered
acpi_button0: <Power Button> on acpi0
acpi_tz0: <Thermal Zone> on acpi0
acpi: bad write to port 0x000 (8), val 0x5a
acpi: bad write to port 0x000 (8), val 0x5a
acpi: bad write to port 0x000 (8), val 0x7
acpi: bad write to port 0x001 (8), val 0x7
acpi: bad write to port 0x000 (8), val 0x30
acpi: bad read from port 0x001 (8)
acpi: bad read from port 0x000 (8)
acpi: bad write to port 0x000 (8), val 0xa5
acpi: bad write to port 0x000 (8), val 0x5a
acpi: bad write to port 0x000 (8), val 0x5a
acpi: bad write to port 0x000 (8), val 0x7
acpi: bad write to port 0x001 (8), val 0x7
acpi: bad write to port 0x000 (8), val 0x30
acpi: bad read from port 0x001 (8)
acpi: bad read from port 0x000 (8)
acpi: bad write to port 0x000 (8), val 0xa5
acpi: bad write to port 0x000 (8), val 0x5a
acpi: bad write to port 0x000 (8), val 0x5a
acpi: bad write to port 0x000 (8), val 0x7
acpi: bad write to port 0x001 (8), val 0x7
acpi: bad write to port 0x000 (8), val 0x30
acpi: bad read from port 0x001 (8)
acpi: bad read from port 0x000 (8)
acpi: bad write to port 0x000 (8), val 0xa5
acpi: bad write to port 0x000 (8), val 0x5a
acpi: bad write to port 0x000 (8), val 0x5a
acpi: bad write to port 0x000 (8), val 0x7
acpi: bad write to port 0x001 (8), val 0x7
acpi: bad write to port 0x000 (8), val 0x30
acpi: bad read from port 0x001 (8)
acpi: bad read from port 0x000 (8)
acpi: bad write to port 0x000 (8), val 0xa5
acpi: bad write to port 0x000 (8), val 0x5a
acpi: bad write to port 0x000 (8), val 0x5a
acpi: bad write to port 0x000 (8), val 0x7
acpi: bad write to port 0x001 (8), val 0x7
acpi: bad write to port 0x000 (8), val 0x30
acpi: bad read from port 0x001 (8)
acpi: bad read from port 0x000 (8)
acpi: bad write to port 0x000 (8), val 0xa5
acpi: bad write to port 0x000 (8), val 0x5a
acpi: bad write to port 0x000 (8), val 0x5a
acpi: bad write to port 0x000 (8), val 0x7
acpi: bad write to port 0x001 (8), val 0x7
acpi: bad write to port 0x000 (8), val 0x30
acpi: bad read from port 0x001 (8)
acpi: bad read from port 0x000 (8)
acpi: bad write to port 0x000 (8), val 0xa5
atkbdc0: <Keyboard controller (i8042)> port 0x60,0x64 irq 1 on acpi0
atkbd0: <AT Keyboard> irq 1 on atkbdc0
atkbd: the current kbd controller command byte 0065
atkbd: keyboard ID 0x41ab (2)
kbd0 at atkbd0
kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000
ioapic0: routing intpin 1 (ISA IRQ 1) to vector 57
atkbd0: [GIANT-LOCKED]
atkbd0: [ITHREAD]
psm0: unable to allocate IRQ
acpi: bad write to port 0x000 (8), val 0x5a
acpi: bad write to port 0x000 (8), val 0x5a
acpi: bad write to port 0x000 (8), val 0x7
acpi: bad write to port 0x001 (8), val 0x7
acpi: bad write to port 0x000 (8), val 0x30
acpi: bad read from port 0x001 (8)
acpi: bad read from port 0x000 (8)
acpi: bad write to port 0x000 (8), val 0xa5
acpi: bad write to port 0x000 (8), val 0x5a
acpi: bad write to port 0x000 (8), val 0x5a
acpi: bad write to port 0x000 (8), val 0x7
acpi: bad write to port 0x001 (8), val 0x7
acpi: bad write to port 0x000 (8), val 0x30
acpi: bad read from port 0x001 (8)
acpi: bad read from port 0x000 (8)
acpi: bad write to port 0x000 (8), val 0xa5
acpi: bad write to port 0x000 (8), val 0x5a
acpi: bad write to port 0x000 (8), val 0x5a
acpi: bad write to port 0x000 (8), val 0x7
acpi: bad write to port 0x001 (8), val 0x7
acpi: bad write to port 0x000 (8), val 0x30
acpi: bad read from port 0x001 (8)
acpi: bad read from port 0x000 (8)
acpi: bad write to port 0x000 (8), val 0xa5
acpi: bad write to port 0x000 (8), val 0x5a
acpi: bad write to port 0x000 (8), val 0x5a
acpi: bad write to port 0x000 (8), val 0x7
acpi: bad write to port 0x001 (8), val 0x7
acpi: bad write to port 0x000 (8), val 0x30
acpi: bad read from port 0x001 (8)
acpi: bad read from port 0x000 (8)
acpi: bad write to port 0x000 (8), val 0xa5
acpi: bad write to port 0x000 (8), val 0x5a
acpi: bad write to port 0x000 (8), val 0x5a
acpi: bad write to port 0x000 (8), val 0x7
acpi: bad write to port 0x001 (8), val 0x7
acpi: bad write to port 0x000 (8), val 0x30
acpi: bad read from port 0x001 (8)
acpi: bad read from port 0x000 (8)
acpi: bad write to port 0x000 (8), val 0xa5
acpi: bad write to port 0x000 (8), val 0x5a
acpi: bad write to port 0x000 (8), val 0x5a
acpi: bad write to port 0x000 (8), val 0x7
acpi: bad write to port 0x001 (8), val 0x7
acpi: bad write to port 0x000 (8), val 0x30
acpi: bad read from port 0x001 (8)
acpi: bad read from port 0x000 (8)
acpi: bad write to port 0x000 (8), val 0xa5
psmcpnp0: <PS/2 mouse port> irq 12 on acpi0
psm0: current command byte:0065
psm0: <PS/2 Mouse> irq 12 on atkbdc0
ioapic0: routing intpin 12 (ISA IRQ 12) to vector 58
psm0: [GIANT-LOCKED]
psm0: [ITHREAD]
psm0: model NetMouse/NetScroll Optical, device ID 0-00, 3 buttons
psm0: config:00000000, flags:00000008, packet size:4
psm0: syncmask:08, syncbits:00
acpi: bad write to port 0x000 (8), val 0x5a
acpi: bad write to port 0x000 (8), val 0x5a
acpi: bad write to port 0x000 (8), val 0x7
acpi: bad write to port 0x001 (8), val 0x7
acpi: bad write to port 0x000 (8), val 0x30
acpi: bad read from port 0x001 (8)
acpi: bad read from port 0x000 (8)
acpi: bad write to port 0x000 (8), val 0xa5
acpi: bad write to port 0x000 (8), val 0x5a
acpi: bad write to port 0x000 (8), val 0x5a
acpi: bad write to port 0x000 (8), val 0x7
acpi: bad write to port 0x001 (8), val 0x7
acpi: bad write to port 0x000 (8), val 0x30
acpi: bad read from port 0x001 (8)
acpi: bad read from port 0x000 (8)
acpi: bad write to port 0x000 (8), val 0xa5
fdc0: <floppy drive controller (FDE)> port 0x3f0-0x3f5,0x3f7 irq 6 drq
2 on acpi0
fdc0: ic_type 90 part_id 80
ioapic0: routing intpin 6 (ISA IRQ 6) to vector 59
fdc0: [FILTER]
fd0: <1440-KB 3.5" drive> on fdc0 drive 0
psmcpnp1: <PS/2 mouse port> irq 12 on acpi0
cpu0: <ACPI CPU> on acpi0
cpu0: switching to generic Cx mode
acpi_throttle0: <ACPI CPU Throttling> on cpu0
acpi_throttle0: P_CNT from P_BLK 0x810
powernow0: <PowerNow! K8> on cpu0
cpu1: <ACPI CPU> on acpi0
powernow1: <PowerNow! K8> on cpu1
atkbdc: atkbdc0 already exists; skipping it
fdc: fdc0 already exists; skipping it
pnp_identify: Trying Read_Port at 203
pnp_identify: Trying Read_Port at 243
pnp_identify: Trying Read_Port at 283
pnp_identify: Trying Read_Port at 2c3
pnp_identify: Trying Read_Port at 303
pnp_identify: Trying Read_Port at 343
pnp_identify: Trying Read_Port at 383
pnp_identify: Trying Read_Port at 3c3
PNP Identify complete
sc: sc0 already exists; skipping it
vga: vga0 already exists; skipping it
isa_probe_children: disabling PnP devices
isa_probe_children: probing non-PnP devices
pmtimer0 on isa0
ppc0: parallel port found at 0x378
ppc0: using extended I/O port range
ppc0: ECP SPP ECP+EPP SPP
ppc0: <Parallel port> at port 0x378-0x37f irq 7 on isa0
ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode
ppc0: FIFO with 16/16/16 bytes threshold
ppbus0: <Parallel port bus> on ppc0
ioapic0: routing intpin 7 (ISA IRQ 7) to vector 60
ppbus0: [MPSAFE]
ppbus0: [ITHREAD]
lpt0: <Printer> on ppbus0
lpt0: Interrupt-driven port
ppi0: <Parallel I/O> on ppbus0
ppc0: [GIANT-LOCKED]
ppc0: [ITHREAD]
sc0: <System console> at flags 0x100 on isa0
sc0: VGA <16 virtual consoles, flags=0x300>
sc0: fb0, kbd1, terminal emulator: sc (syscons terminal)
sio0: not probed (disabled)
sio1: not probed (disabled)
sio2: not probed (disabled)
sio3: not probed (disabled)
vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0
isa_probe_children: probing PnP devices
Device configuration finished.
Reducing kern.maxvnodes 102154 -> 100000
procfs registered
lapic: Divisor 2, Frequency 100009714 hz
Timecounter "TSC" frequency 3100300862 Hz quality -100
Timecounters tick every 1.000 msec
lo0: bpf attached
ata1-slave: pio=PIO4 wdma=WDMA2 udma=UDMA33 cable=80 wire
ata1-master: pio=PIO4 wdma=WDMA2 udma=UDMA100 cable=80 wire
ad2: setting PIO4 on IXP700 chip
ad2: setting UDMA100 on IXP700 chip
ad2: 76351MB <SAMSUNG SP8004H QW100-61> at ata1-master UDMA100
ad2: 156368016 sectors [155127C/16H/63S] 16 sectors/interrupt 1 depth queue
acd0: setting PIO4 on IXP700 chip
acd0: setting UDMA33 on IXP700 chip
acd0: <TOSHIBA ODD-DVD SD-R1512/1010> CDRW drive at ata1 as slave
acd0: read 8268KB/s (8268KB/s) write 8268KB/s (8268KB/s), 2048KB buffer, UDMA33
acd0: Reads: CDR, CDRW, CDDA stream, DVDROM, DVDR, DVDRAM, packet
acd0: Writes: CDR, CDRW, test write, burnproof
acd0: Audio: play, 16 volume levels
acd0: Mechanism: ejectable tray, unlocked
acd0: Medium: no/blank disc
ata2-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire
ad4: 305245MB <Seagate ST3320418AS CC35> at ata2-master SATA300
ad4: 625142448 sectors [620181C/16H/63S] 16 sectors/interrupt 1 depth queue
SMP: AP CPU #1 Launched!
cpu1 AP:
     ID: 0x01000000   VER: 0x80050010 LDR: 0x00000000 DFR: 0xffffffff
  lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff
  timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010000
ioapic0: Assigning ISA IRQ 1 to local APIC 0
ioapic0: Assigning ISA IRQ 6 to local APIC 1
ioapic0: Assigning ISA IRQ 7 to local APIC 0
ioapic0: Assigning ISA IRQ 9 to local APIC 1
ioapic0: Assigning ISA IRQ 12 to local APIC 0
ioapic0: Assigning ISA IRQ 14 to local APIC 1
ioapic0: Assigning ISA IRQ 15 to local APIC 0
ioapic0: Assigning PCI IRQ 16 to local APIC 1
ioapic0: Assigning PCI IRQ 17 to local APIC 0
ioapic0: Assigning PCI IRQ 18 to local APIC 1
ioapic0: Assigning PCI IRQ 19 to local APIC 0
ioapic0: Assigning PCI IRQ 22 to local APIC 1
msi: Assigning MSI IRQ 256 to local APIC 0
GEOM: new disk ad2
GEOM: new disk ad4
GEOM_JOURNAL: Journal 103692779: ad4s4d contains data.
GEOM_JOURNAL: Journal 103692779: ad4s4d contains journal.
GEOM_JOURNAL: Journal ad4s4d clean.
GEOM_JOURNAL: Journal 2979540398: ad4s4e contains data.
GEOM_JOURNAL: Journal 2979540398: ad4s4e contains journal.
GEOM_JOURNAL: Journal ad4s4e clean.
Root mount waiting for: GJOURNAL
Trying to mount root from ufs:/dev/ad4s4a
start_init: trying /sbin/init
acpi: bad write to port 0x000 (8), val 0x5a
acpi: bad write to port 0x000 (8), val 0x5a
acpi: bad write to port 0x000 (8), val 0x7
acpi: bad write to port 0x001 (8), val 0x7
acpi: bad write to port 0x000 (8), val 0x30
acpi: bad read from port 0x001 (8)
acpi: bad read from port 0x000 (8)
acpi: bad write to port 0x000 (8), val 0xa5
acpi: bad write to port 0x000 (8), val 0x5a
acpi: bad write to port 0x000 (8), val 0x5a
acpi: bad write to port 0x000 (8), val 0x7
acpi: bad write to port 0x001 (8), val 0x7
acpi: bad write to port 0x000 (8), val 0x30
acpi: bad read from port 0x001 (8)
acpi: bad read from port 0x000 (8)
acpi: bad write to port 0x000 (8), val 0xa5
acpi: bad write to port 0x000 (8), val 0x5a
acpi: bad write to port 0x000 (8), val 0x5a
acpi: bad write to port 0x000 (8), val 0x7
acpi: bad write to port 0x001 (8), val 0x7
acpi: bad write to port 0x000 (8), val 0x30
acpi: bad read from port 0x001 (8)
acpi: bad read from port 0x000 (8)
acpi: bad write to port 0x000 (8), val 0xa5
acpi: bad write to port 0x000 (8), val 0x5a
acpi: bad write to port 0x000 (8), val 0x5a
acpi: bad write to port 0x000 (8), val 0x7
acpi: bad write to port 0x001 (8), val 0x7
acpi: bad write to port 0x000 (8), val 0x30
acpi: bad read from port 0x001 (8)
acpi: bad read from port 0x000 (8)
acpi: bad write to port 0x000 (8), val 0xa5
Linux ELF exec handler installed
linprocfs registered
tun0: bpf attached
From borjam at sarenet.es  Mon Sep 28 16:09:44 2009
From: borjam at sarenet.es (Borja Marcos)
Date: Mon Sep 28 16:09:51 2009
Subject: [LOR] unmounting a filesystem
Message-ID: <800887B3-34CB-49D5-8C0D-F1BB2DC5CA64@sarenet.es>

Sep 28 19:47:46  kernel: lock order reversal:
Sep 28 19:47:46  kernel: 1st 0xffffff0002a9a308 ufs (ufs) @ /usr/src/ 
sys/kern/vfs_mount.c:1200
Sep 28 19:47:46  kernel: 2nd 0xffffff0002a63a58 devfs (devfs) @ /usr/ 
src/sys/ufs/ffs/ffs_vfsops.c:1194
Sep 28 19:47:46  kernel: KDB: stack backtrace:
Sep 28 19:47:46  kernel: db_trace_self_wrapper() at  
db_trace_self_wrapper+0x2a
Sep 28 19:47:46  kernel: _witness_debugger() at _witness_debugger+0x2e
Sep 28 19:47:46  kernel: witness_checkorder() at witness_checkorder 
+0x81e
Sep 28 19:47:46  kernel: __lockmgr_args() at __lockmgr_args+0xd03
Sep 28 19:47:46  kernel: vop_stdlock() at vop_stdlock+0x39
Sep 28 19:47:46  kernel: VOP_LOCK1_APV() at VOP_LOCK1_APV+0x9b
Sep 28 19:47:46  kernel: _vn_lock() at _vn_lock+0x57
Sep 28 19:47:46  kernel: ffs_flushfiles() at ffs_flushfiles+0xc5
Sep 28 19:47:46  kernel: softdep_flushfiles() at softdep_flushfiles+0x63
Sep 28 19:47:46  kernel: ffs_unmount() at ffs_unmount+0x2e1
Sep 28 19:47:46  kernel: dounmount() at dounmount+0x2e6
Sep 28 19:47:46  kernel: unmount() at unmount+0x27e
Sep 28 19:47:46  kernel: syscall() at syscall+0x1d0
Sep 28 19:47:46  kernel: Xfast_syscall() at Xfast_syscall+0xe1
Sep 28 19:47:46  kernel: --- syscall (22, FreeBSD ELF64, unmount), rip  
= 0x8006a09bc, rsp = 0x7fffffffe3b8, rbp = 0 ---

FreeBSD  8.0-RC1 FreeBSD 8.0-RC1 #0: Fri Sep 25 16:55:06 CEST 2009      
root@:/usr/obj/usr/src/sys/DEBUG  amd64

I'm running it on VMWare Fussion, but it shouldn't matter.

The system has two disks, one of them just a root partition and the  
other one has two filesystems, one for /usr/src and the other for /usr/ 
obj

How to reproduce?

Right after boot, I have mounted /usr/src and /usr/obj.

Unmounting /usr/obj has given this LOR.

I can reproduce it easily, please let me know if I can do anything else.





Borja.

From alc at cs.rice.edu  Mon Sep 28 17:25:17 2009
From: alc at cs.rice.edu (Alan Cox)
Date: Mon Sep 28 17:25:31 2009
Subject: 8.0-RC1 panic attaching ppc
In-Reply-To: <200909281134.04010.doconnor@gsoft.com.au>
References: <200909232322.51060.doconnor@gsoft.com.au>
	<200909260824.39985.doconnor@gsoft.com.au>
	<4ABE81C5.2010009@cs.rice.edu>
	<200909281134.04010.doconnor@gsoft.com.au>
Message-ID: <4AC0F173.10300@cs.rice.edu>

Daniel O'Connor wrote:
> On Sun, 27 Sep 2009, Alan Cox wrote:
>   
>> Ok, now I can explain what is happening.  The kernel is using 1GB
>> pages to implement the direct map.  Unfortunately, pmap_extract()
>> doesn't know how to handle a 1GB page mapping.  pmap_kextract() only
>> works by an "accident" of its different implementation.  In other
>> words, it should not be relied upon to work either.
>>
>> Please revert whatever patch John gave you and try the attached
>> patch. It simply disables the use of 1GB page mapping by the direct
>> map.
>>     
>
> Your patch fixes (works around?) the problem.
>   

Thanks.  I've committed the patch.

Yes, it's a work around.  Fortunately(?), on my test machine, I don't 
see any measurable effect from disabling the use of 1GB pages by the 
direct map.

Alan

From lehmann at ans-netz.de  Mon Sep 28 18:38:01 2009
From: lehmann at ans-netz.de (Oliver Lehmann)
Date: Mon Sep 28 18:38:08 2009
Subject: glabel+gmirror (8.0-RC1 problem)
In-Reply-To: <20090928084035.GB1659@garage.freebsd.pl>
References: <20090927170244.0980d699.lehmann@ans-netz.de>
	<20090927223725.5893371f.lehmann@ans-netz.de>
	<20090928084035.GB1659@garage.freebsd.pl>
Message-ID: <20090928203756.ef70e0c6.lehmann@ans-netz.de>

Hi Pawel,

Pawel Jakub Dawidek wrote:

> Does anything change between you upgrade from BETA3 and RC1? For example
> gmirror was compiled into the kernel before and now is loaded as module
> or something similar?

Nope, it was a clean BETA3 installation with the default GENERIC kernel
which has afaik geom_label in kernel, but not geom_mirror (nevertheless I
loaded geom_label.ko at boottime as well as geom_mirror)
The same with RC1 - clean and fresh installation with the default GENERIC
kernel and geom_label in kernel (default), but still loaded as module at
boottime as well as geom_mirror.

> Could you test this patch:
> 
> 	http://people.freebsd.org/~pjd/patches/improved_taste.patch

This makes gmirror+glabel work again on RC1

One thing which I noticed. I labeled in single user mode, my root
partition with tunefs - as well as all my other partitions. After this
was done, I remounted my root partition (mount -rw /) and changed my
fstab to use the new geom labels instead. But somehow this "killed" the
new root-label of my mirror/gm0s1a partition. After I rebooted, the label
was gone and I had to manually specify the root partition
ufs:mirror/gm0s1a to mount. All the labels of my other mirrored
partitions where there (usr, tmp, var). I then rebooted once more into
single user mode (specified once more the root partition manually) and
did a tunefs -L once more. Then I rebooted directly and the label is now
there.

Is it possible that mount -rw / (which remounts /dev/mirror/gm0s1a) could
have been killed the freshly given label?

-- 
 Oliver Lehmann
  http://www.pofo.de/
  http://wishlist.ans-netz.de/
From mav at FreeBSD.org  Mon Sep 28 18:46:18 2009
From: mav at FreeBSD.org (Alexander Motin)
Date: Mon Sep 28 18:46:25 2009
Subject: PATA disks/DVD not detected on ATI IXP 700 - cannot boot (dmesg
 attached)
In-Reply-To: <dde89ecd0909280247t3f14034cj2f81cb5019ee0264@mail.gmail.com>
References: <20090916161327.GB87631@zod.isi.edu>	
	<20090919035214.GA12889@zod.isi.edu>	
	<200909211239.25614.jkim@FreeBSD.org> <4AB9A3CE.4090509@yandex.ru>	
	<dde89ecd0909242239j4ecebc3dsfef5ec265237b5b3@mail.gmail.com>	
	<4ABC5962.80404@yandex.ru>
	<dde89ecd0909280247t3f14034cj2f81cb5019ee0264@mail.gmail.com>
Message-ID: <4AC0FEBD.2020705@FreeBSD.org>

Dennis Chikin wrote:
>> Is it means that all works with this patch?
> 
> No visible ata-specific faults encountered after loading the kernel.
> 
>> Can you show dmesg from patched system?

> atapci0: <ATI (ID=43901002) AHCI controller> port
> 0xc000-0xc007,0xb000-0xb003,0xa000-0xa007,0x9000-0x9003,0x8000-0x800f
> mem 0xfe8ff800-0xfe8ffbff irq 22 at device 17.0 on pci0
> atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0x8000
> atapci0: Reserved 0x400 bytes for rid 0x24 type 3 at 0xfe8ff800
> ioapic0: routing intpin 22 (PCI IRQ 22) to vector 50
> atapci0: [MPSAFE]
> atapci0: [ITHREAD]
> atapci0: AHCI Version 01.10 controller with 4 ports detected
> ata2: <ATA channel 0> on atapci0
> ata2: SATA connect time=0ms
> ata2: SIGNATURE: 00000101
> ata2: ahci_reset devices=0x1<ATA_MASTER>
> ata2: [MPSAFE]
> ata2: [ITHREAD]
> ata3: <ATA channel 1> on atapci0
> ata3: SATA connect status=00000000
> ata3: ahci_reset devices=0x0
> ata3: [MPSAFE]
> ata3: [ITHREAD]
> ata4: <ATA channel 2> on atapci0
> ata4: SATA connect status=00000000
> ata4: ahci_reset devices=0x0
> ata4: [MPSAFE]
> ata4: [ITHREAD]
> ata5: <ATA channel 3> on atapci0
> ata5: SATA connect status=00000000
> ata5: ahci_reset devices=0x0
> ata5: [MPSAFE]
> ata5: [ITHREAD]
> atapci1: <ATI IXP700 UDMA133 controller> port
> 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xff00-0xff0f at device 20.1 on
> pci0
> atapci1: Reserved 0x10 bytes for rid 0x20 type 4 at 0xff00
> ata0: <ATA channel 0> on atapci1
> atapci1: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0
> atapci1: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6
> ata0: reset tp1 mask=03 ostat0=7f ostat1=7f
> ata0: stat0=0x7f err=0xff lsb=0xff msb=0xff
> ata0: stat0=0x7f err=0xff lsb=0xff msb=0xff
> ata0: stat0=0x7f err=0xff lsb=0xff msb=0xff
> ata0: stat0=0x7f err=0xff lsb=0xff msb=0xff
> ata0: stat0=0x7f err=0xff lsb=0xff msb=0xff
> ata0: stat0=0x7f err=0xff lsb=0xff msb=0xff
> ata0: stat0=0x7f err=0xff lsb=0xff msb=0xff
> ata0: stat0=0x7f err=0xff lsb=0xff msb=0xff
> ata0: stat0=0x7f err=0xff lsb=0xff msb=0xff
> ata0: stat0=0x7f err=0xff lsb=0xff msb=0xff
> ata0: stat0=0x7f err=0xff lsb=0xff msb=0xff
> ata0: stat0=0x7f err=0xff lsb=0xff msb=0xff
> ata0: stat0=0x7f err=0xff lsb=0xff msb=0xff
> ata0: stat0=0x7f err=0xff lsb=0xff msb=0xff
> ata0: stat0=0x7f err=0xff lsb=0xff msb=0xff
> ata0: stat0=0x7f err=0xff lsb=0xff msb=0xff
> ata0: stat0=0x7f err=0xff lsb=0xff msb=0xff
> ata0: stat0=0x7f err=0xff lsb=0xff msb=0xff
> ata0: stat0=0x7f err=0xff lsb=0xff msb=0xff
> ata0: stat0=0x7f err=0xff lsb=0xff msb=0xff
> ata0: stat0=0x7f err=0xff lsb=0xff msb=0xff
> ata0: stat0=0x7f err=0xff lsb=0xff msb=0xff
> ata0: stat1=0x7f err=0xff lsb=0xff msb=0xff
> ata0: reset tp2 stat0=ff stat1=ff devices=0x0
> ioapic0: routing intpin 14 (ISA IRQ 14) to vector 55
> ata0: [MPSAFE]
> ata0: [ITHREAD]
> ata1: <ATA channel 1> on atapci1
> atapci1: Reserved 0x8 bytes for rid 0x18 type 4 at 0x170
> atapci1: Reserved 0x1 bytes for rid 0x1c type 4 at 0x376
> ata1: reset tp1 mask=03 ostat0=50 ostat1=50
> ata1: stat0=0x50 err=0x01 lsb=0x00 msb=0x00
> ata1: stat1=0x00 err=0x01 lsb=0x14 msb=0xeb
> ata1: reset tp2 stat0=50 stat1=00 devices=0x9<ATAPI_SLAVE,ATA_MASTER>

Here we can see detected: 4 (not 6!) SATA channels on AHCI controller,
one PATA channel and 2 SATA channels in legacy emulation (why?).
Actually, the same happens if I comment out all that device class magic.
Looks like the only thing really required to fix problem with two lost
channels is this part of patch:

-    /* IXP600 & IXP700 only have 1 PATA channel */
-    if ((ctlr->chip->chipid == ATA_ATI_IXP600) ||
-       (ctlr->chip->chipid == ATA_ATI_IXP700))
+    /* IXP600 only have 1 PATA channel */
+    if (ctlr->chip->chipid == ATA_ATI_IXP600)

Looks like part of changing device class just not working. Today I have
bought IXP700 based board and can acknowledge that the same situation I
can see with recent HEAD. `pciconf -l` reports to me original PATA
device class and only 4 channels reported by AHCI.

So jkim@, could you please comment, how should it really work and why it
doesn't?

PS: I have tried to disable all that ATI-specific code and found that
both legacy PCI ATA and AHCI drivers looks like working fine with
IXP700. Do we really need AHCI forcing for IXP700?

-- 
Alexander Motin
From pjd at FreeBSD.org  Mon Sep 28 18:49:34 2009
From: pjd at FreeBSD.org (Pawel Jakub Dawidek)
Date: Mon Sep 28 18:49:41 2009
Subject: glabel+gmirror (8.0-RC1 problem)
In-Reply-To: <20090928203756.ef70e0c6.lehmann@ans-netz.de>
References: <20090927170244.0980d699.lehmann@ans-netz.de>
	<20090927223725.5893371f.lehmann@ans-netz.de>
	<20090928084035.GB1659@garage.freebsd.pl>
	<20090928203756.ef70e0c6.lehmann@ans-netz.de>
Message-ID: <20090928184926.GA2016@garage.freebsd.pl>

On Mon, Sep 28, 2009 at 08:37:56PM +0200, Oliver Lehmann wrote:
> Hi Pawel,
> 
> Pawel Jakub Dawidek wrote:
> 
> > Does anything change between you upgrade from BETA3 and RC1? For example
> > gmirror was compiled into the kernel before and now is loaded as module
> > or something similar?
> 
> Nope, it was a clean BETA3 installation with the default GENERIC kernel
> which has afaik geom_label in kernel, but not geom_mirror (nevertheless I
> loaded geom_label.ko at boottime as well as geom_mirror)
> The same with RC1 - clean and fresh installation with the default GENERIC
> kernel and geom_label in kernel (default), but still loaded as module at
> boottime as well as geom_mirror.
> 
> > Could you test this patch:
> > 
> > 	http://people.freebsd.org/~pjd/patches/improved_taste.patch
> 
> This makes gmirror+glabel work again on RC1

Thanks for confirmation.

> One thing which I noticed. I labeled in single user mode, my root
> partition with tunefs - as well as all my other partitions. After this
> was done, I remounted my root partition (mount -rw /) and changed my
> fstab to use the new geom labels instead. But somehow this "killed" the
> new root-label of my mirror/gm0s1a partition. After I rebooted, the label
> was gone and I had to manually specify the root partition
> ufs:mirror/gm0s1a to mount. All the labels of my other mirrored
> partitions where there (usr, tmp, var). I then rebooted once more into
> single user mode (specified once more the root partition manually) and
> did a tunefs -L once more. Then I rebooted directly and the label is now
> there.
> 
> Is it possible that mount -rw / (which remounts /dev/mirror/gm0s1a) could
> have been killed the freshly given label?

Yes. tunefs(8) updates only on-disk super-block, but the kernel holds
super-block that was read before. Now when you do 'mount -rw /' the
in-kernel super-block is stored to the disk, and there is nothing about
your label in there, so it gets overwritten.

-- 
Pawel Jakub Dawidek                       http://www.wheel.pl
pjd@FreeBSD.org                           http://www.FreeBSD.org
FreeBSD committer                         Am I Evil? Yes, I Am!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090928/6d307f4f/attachment.pgp
From lehmann at ans-netz.de  Mon Sep 28 19:04:41 2009
From: lehmann at ans-netz.de (Oliver Lehmann)
Date: Mon Sep 28 19:04:55 2009
Subject: glabel+gmirror (8.0-RC1 problem)
In-Reply-To: <20090928184926.GA2016@garage.freebsd.pl>
References: <20090927170244.0980d699.lehmann@ans-netz.de>
	<20090927223725.5893371f.lehmann@ans-netz.de>
	<20090928084035.GB1659@garage.freebsd.pl>
	<20090928203756.ef70e0c6.lehmann@ans-netz.de>
	<20090928184926.GA2016@garage.freebsd.pl>
Message-ID: <20090928210438.ddd2af93.lehmann@ans-netz.de>

Pawel Jakub Dawidek wrote:

> Yes. tunefs(8) updates only on-disk super-block, but the kernel holds
> super-block that was read before. Now when you do 'mount -rw /' the
> in-kernel super-block is stored to the disk, and there is nothing about
> your label in there, so it gets overwritten.

Ok this sounds familar to me - maybe I have read about this before ;)
What would be the prefered way to label the root partition and changing
fstab without entering the root partition at bootup manually at least
once? Is there a way to do so?

I noticed that even when I boot in multiuser, change fstab, then return
into single user mode and remount / read-only, the label cannot be set.
I need to boot directly into single user mode. Looks like writing the
label is denied when the partition was once mounted rw before - even if
it is actually mounted ro.

-- 
 Oliver Lehmann
  http://www.pofo.de/
  http://wishlist.ans-netz.de/
From kama at pvp.se  Mon Sep 28 21:52:21 2009
From: kama at pvp.se (kama)
Date: Mon Sep 28 21:52:28 2009
Subject: FreeBSD 7.2-STABLE boot freeze
In-Reply-To: <4AC06ED6.7030402@freebsd.org>
References: <20090921140345.H37424@ns1.as.pvp.se>
	<20090922103150.V37424@ns1.as.pvp.se>
	<4AB8A95E.3060307@icyb.net.ua> <20090922142526.P37424@ns1.as.pvp.se>
	<4AB8E082.8050100@icyb.net.ua> <20090922215700.V37424@ns1.as.pvp.se>
	<4ABA1D1F.3080704@icyb.net.ua> <20090923171004.Q37424@ns1.as.pvp.se>
	<4ABA457E.3060800@freebsd.org> <20090924141927.Y37424@ns1.as.pvp.se>
	<20090925110209.E37424@ns1.as.pvp.se> <4ABC894E.7040204@freebsd.org>
	<20090928092026.B37424@ns1.as.pvp.se> <4AC06ED6.7030402@freebsd.org>
Message-ID: <20090928235136.F37424@ns1.as.pvp.se>



On Mon, 28 Sep 2009, Andriy Gapon wrote:

> on 28/09/2009 10:21 kama said the following:
> >
> > On Fri, 25 Sep 2009, Andriy Gapon wrote:
> >
> >> on 25/09/2009 12:04 kama said the following:
> >>> On Thu, 24 Sep 2009, kama wrote:
> >>>
> >>>> I am currently building the source on another machine. Lets see if it will
> >>>> build it any better.
> >>> Building the the world on another machine and install it on the DL385
> >>> machine made it also to freeze.
> >> Did you still get the message about unresolved symbol?
> >
> > I did not try with ACPI_DEBUG enabled.
> >
> > Another week, so I can start testing again...
>
> I did not ask that :-)
> I asked -  when you got your latest freeze, did you see that 'unresolved'
> message or not?

But that only appears when I enable ACPI_DEBUG.

/Bjorn
From rgrover1 at gmail.com  Mon Sep 28 22:21:40 2009
From: rgrover1 at gmail.com (Rohit Grover)
Date: Mon Sep 28 22:21:47 2009
Subject: Laggy X11 after updating to 8.0-RC1
Message-ID: <426bed110909281500w194c7c19taf29b1a3996c91fc@mail.gmail.com>

I have upgraded to 8.0-RC1 (from 7.2-STABLE) on my MacBook 4,1. I did
so by checking out stable/8 under /usr/src, rebuilding kernel/world,
and using portupgrade to update all installed ports from packages
available on the 8.0RC1 DVD-iso.

Since the update, my X11 is laggy. Now, I often have to move the mouse
before keystrokes/button presses take effect.

wiki.freebsd.org/USB mentions about a similar situation under the
question: "Screen updates in X111 are slow/broken/laggy," and their
recommended solution is to update kernel/world, remove old libs, and
rebuild the port libpciaccess.

As I've mentioned, I've updated the kernel/world, and updated
libpciaccess. Perhaps I'm having issues because I need to remove old
libs. How do I remove old libs?

Could there be another cause for the symptoms I'm experiencing?

thanks.
From wblock at wonkity.com  Mon Sep 28 23:30:47 2009
From: wblock at wonkity.com (Warren Block)
Date: Mon Sep 28 23:30:54 2009
Subject: Laggy X11 after updating to 8.0-RC1
In-Reply-To: <426bed110909281500w194c7c19taf29b1a3996c91fc@mail.gmail.com>
References: <426bed110909281500w194c7c19taf29b1a3996c91fc@mail.gmail.com>
Message-ID: <alpine.BSF.2.00.0909281725060.39795@wonkity.com>

On Tue, 29 Sep 2009, Rohit Grover wrote:

> I have upgraded to 8.0-RC1 (from 7.2-STABLE) on my MacBook 4,1. I did
> so by checking out stable/8 under /usr/src, rebuilding kernel/world,
> and using portupgrade to update all installed ports from packages
> available on the 8.0RC1 DVD-iso.
>
> Since the update, my X11 is laggy. Now, I often have to move the mouse
> before keystrokes/button presses take effect.

Make sure hal and dbus are enabled in rc.conf and running.  In 
xorg.conf, remove Option "AllowEmptyInput" "off".

A bonus of using hal is that you can remove the keyboard and mouse 
sections from xorg.conf.

> As I've mentioned, I've updated the kernel/world, and updated
> libpciaccess. Perhaps I'm having issues because I need to remove old
> libs. How do I remove old libs?

cd /usr/src
make check-old-libs
make delete-old-libs

/usr/src/Makefile lists all the options.

-Warren Block * Rapid City, South Dakota USA
From rgrover1 at gmail.com  Tue Sep 29 01:18:55 2009
From: rgrover1 at gmail.com (Rohit Grover)
Date: Tue Sep 29 01:19:02 2009
Subject: Laggy X11 after updating to 8.0-RC1
In-Reply-To: <alpine.BSF.2.00.0909281725060.39795@wonkity.com>
References: <426bed110909281500w194c7c19taf29b1a3996c91fc@mail.gmail.com>
	<alpine.BSF.2.00.0909281725060.39795@wonkity.com>
Message-ID: <426bed110909281818t68ab8fe5r9a6370c5fa368d7a@mail.gmail.com>

On Tue, Sep 29, 2009 at 7:30 AM, Warren Block <wblock@wonkity.com> wrote:
> On Tue, 29 Sep 2009, Rohit Grover wrote:
>
>> I have upgraded to 8.0-RC1 (from 7.2-STABLE) on my MacBook 4,1. I did
>> so by checking out stable/8 under /usr/src, rebuilding kernel/world,
>> and using portupgrade to update all installed ports from packages
>> available on the 8.0RC1 DVD-iso.
>>
>> Since the update, my X11 is laggy. Now, I often have to move the mouse
>> before keystrokes/button presses take effect.
>
> Make sure hal and dbus are enabled in rc.conf and running. ?In xorg.conf,
> remove Option "AllowEmptyInput" "off".
>
> A bonus of using hal is that you can remove the keyboard and mouse sections
> from xorg.conf.
>
>> As I've mentioned, I've updated the kernel/world, and updated
>> libpciaccess. Perhaps I'm having issues because I need to remove old
>> libs. How do I remove old libs?
>
> cd /usr/src
> make check-old-libs
> make delete-old-libs


I deleted old libs using 'make delete-old-libs' from /usr/src, but
that has led to many other problems.
It seems many libraries currently in use were deleted in the process.
I'm having to rebuild/reinstall many of my applications to get them
working again.
And gdm doesn't work anymore. Initially X was complaining about
missing libraries, but after reinstalling a few packages, I now have
gdm going into an endless loop in which it X tries to startup,
displays the mouse pointer, and then re-initializes itself.
Starting X by itself gets me similar behaviour: the screen blanks out,
and then nothing happens.

There is nothing in /var/log/messages or on the console to help debug
the problem. No man page for gdm. Any ideas on what should be done?

thanks.
From wblock at wonkity.com  Tue Sep 29 01:29:50 2009
From: wblock at wonkity.com (Warren Block)
Date: Tue Sep 29 01:29:56 2009
Subject: Laggy X11 after updating to 8.0-RC1
In-Reply-To: <426bed110909281818t68ab8fe5r9a6370c5fa368d7a@mail.gmail.com>
References: <426bed110909281500w194c7c19taf29b1a3996c91fc@mail.gmail.com>
	<alpine.BSF.2.00.0909281725060.39795@wonkity.com>
	<426bed110909281818t68ab8fe5r9a6370c5fa368d7a@mail.gmail.com>
Message-ID: <alpine.BSF.2.00.0909281926180.40193@wonkity.com>

On Tue, 29 Sep 2009, Rohit Grover wrote:

> On Tue, Sep 29, 2009 at 7:30 AM, Warren Block <wblock@wonkity.com> wrote:
>> On Tue, 29 Sep 2009, Rohit Grover wrote:
>>
>>> I have upgraded to 8.0-RC1 (from 7.2-STABLE) on my MacBook 4,1. I did
>>> so by checking out stable/8 under /usr/src, rebuilding kernel/world,
>>> and using portupgrade to update all installed ports from packages
>>> available on the 8.0RC1 DVD-iso.
>>>
>>> Since the update, my X11 is laggy. Now, I often have to move the mouse
>>> before keystrokes/button presses take effect.
>>
>> Make sure hal and dbus are enabled in rc.conf and running. ?In xorg.conf,
>> remove Option "AllowEmptyInput" "off".
>>
>> A bonus of using hal is that you can remove the keyboard and mouse sections
>> from xorg.conf.
>>
>>> As I've mentioned, I've updated the kernel/world, and updated
>>> libpciaccess. Perhaps I'm having issues because I need to remove old
>>> libs. How do I remove old libs?
>>
>> cd /usr/src
>> make check-old-libs
>> make delete-old-libs
>
>
> I deleted old libs using 'make delete-old-libs' from /usr/src, but
> that has led to many other problems.
> It seems many libraries currently in use were deleted in the process.
> I'm having to rebuild/reinstall many of my applications to get them
> working again.

When upgrading from one major release of FreeBSD to another, the 
standard recommendation is to delete all installed applications 
(pkg_delete -a) and then reinstall everything.  There may be some 
incantation of portupgrade or portmaster that will do it.  pkg_libchk 
from sysutils/bsdadminscripts may help.  But that is likely to take 
longer than just pkg_delete -a and reinstalling applications.

-Warren Block * Rapid City, South Dakota USA
From lambert at lambertfam.org  Tue Sep 29 03:55:45 2009
From: lambert at lambertfam.org (Scott Lambert)
Date: Tue Sep 29 03:55:52 2009
Subject: Laggy X11 after updating to 8.0-RC1
In-Reply-To: <alpine.BSF.2.00.0909281926180.40193@wonkity.com>
References: <426bed110909281500w194c7c19taf29b1a3996c91fc@mail.gmail.com>
	<alpine.BSF.2.00.0909281725060.39795@wonkity.com>
	<426bed110909281818t68ab8fe5r9a6370c5fa368d7a@mail.gmail.com>
	<alpine.BSF.2.00.0909281926180.40193@wonkity.com>
Message-ID: <20090929035544.GJ4858@sysmon.tcworks.net>

On Mon, Sep 28, 2009 at 07:29:46PM -0600, Warren Block wrote:
> On Tue, 29 Sep 2009, Rohit Grover wrote:
> >
> >On Tue, Sep 29, 2009 at 7:30 AM, Warren Block <wblock@wonkity.com> wrote:
> >>On Tue, 29 Sep 2009, Rohit Grover wrote:
> >>
> >>>I have upgraded to 8.0-RC1 (from 7.2-STABLE) on my MacBook 4,1. I
> >>>did so by checking out stable/8 under /usr/src, rebuilding
> >>>kernel/world, and using portupgrade to update all installed ports
> >>>from packages available on the 8.0RC1 DVD-iso.
> >>>
> >>>Since the update, my X11 is laggy. Now, I often have to move the
> >>>mouse before keystrokes/button presses take effect.
> >>
> >>Make sure hal and dbus are enabled in rc.conf and running. ?In
> >>xorg.conf, remove Option "AllowEmptyInput" "off".
> >>
> >>A bonus of using hal is that you can remove the keyboard and mouse
> >>sections from xorg.conf.
> >>
> >>>As I've mentioned, I've updated the kernel/world, and updated
> >>>libpciaccess. Perhaps I'm having issues because I need to remove
> >>>old libs. How do I remove old libs?
> >>
> >>cd /usr/src make check-old-libs make delete-old-libs
> >
> >
> >I deleted old libs using 'make delete-old-libs' from /usr/src,
> >but that has led to many other problems.  It seems many libraries
> >currently in use were deleted in the process.  I'm having to
> >rebuild/reinstall many of my applications to get them working again.

I'm seeing something similar to OP, apparent keyboard buffer delays, but
maybe not exactly.  When I click from one xterm to another, it may be
1 - 30 seconds before my key entries show.  Firefox seems to have less
delay after clicks into text fields, but sometimes it is noticeable maybe
0.25 to 1 second.  Just two xterms, the fluxbox toolbar, and firefox
running.  No frufru stuff.  

I haven't had time to systematically try to narrow down the actual
problem.

Wiggling the mouse, hitting various keys all seemed like they helped
at one time or another, but I think I was just trying things until the
buffer released.  If I leave it alone, the delays seem to be of about
the same length as when I'm trying random things to break it loose.

Only clicking in a window (particularly an xterm) seems to stall the
keyboard buffer.  Just wiggling the mouse above or around the focused
window is no problem.  Clicks take effect immediately.  I can drag
the window by the title bar or resize the window without stalling the
keyboard buffer.

I haven't lost a key press that I've noticed.  Now I just type blind
until it catches up or I actually need to see the results of my typing.

Oh, it seems like if there is something in the xterm which can use the
mouse input, it may not be stalling the keyboard buffer.  I need to
watch that more closely.

I've tried with and without an explicit xorg.conf.  Switching
back to the console works better without.  With doesn't leave me a
usable display outside of X.  

It seems like the delays get longer and longer the longer the X session
has been up.  But sometimes there will be no delay.  If I switch
windows/desktops with alt-tab, ctrl-f#, there is no delay.  I've been
wondering if it could be due to the synaptics touchpad.  I enabled the
synaptics features about the same time to try to get rid of tap events
from the touchpad.  I hate touchpads and still haven't figured out how
to kill tapping.

agp0: <Intel GM965 SVGA controller> on vgapci0

I've done the delete-old stuff and got mad at KDE4 and did a pkg_delete
-a in a fit of rage.  I went back with fluxbox, took about 2 to 3 hours
to compile everything from source to have my multiple xterms back.
Firefox took another 2 hours.  But I was able to *work* while that
built.

I was running FreeBSD 8-CURRENT pre-beta cycle.  KDE4 was giving me so
many fits that I would just run Windows instead so I could get work
done, sad.  I don't know if I would have noticed an input buffer delay
before I upgraded to BETA2 and replaced KDE with fluxbox.  I just
couldn't stand to spend that much time in X.  Windows finally annoyed me
enough to try something different (fluxbox).  This problem has been with
me through the BETAs and now into RC1, as far as I can remember.  I've
been busy and trying really hard to ignore workstation issues to get
work done ever since my PowerBook died.

> When upgrading from one major release of FreeBSD to another, the 
> standard recommendation is to delete all installed applications 
> (pkg_delete -a) and then reinstall everything.  There may be some 
> incantation of portupgrade or portmaster that will do it.  pkg_libchk 
> from sysutils/bsdadminscripts may help.  But that is likely to take 
> longer than just pkg_delete -a and reinstalling applications.

portmaster's man page suggests pkg_delete -a.  It has explicit
instructions so you don't miss anything putting them back on.  Not
that I've used the instructions yet.  Rage is not condusive to reading
manuals.
 
-- 
Scott Lambert                    KC5MLE                       Unix SysAdmin
lambert@lambertfam.org

From doconnor at gsoft.com.au  Tue Sep 29 05:05:13 2009
From: doconnor at gsoft.com.au (Daniel O'Connor)
Date: Tue Sep 29 05:05:21 2009
Subject: Excessivly cheap USB device issue
In-Reply-To: <200909280052.n8S0qCpL032199@lava.sentex.ca>
References: <200909280009.28658.doconnor@gsoft.com.au>
	<1254062842.2048.1467.camel@balrog.2hip.net>
	<200909280052.n8S0qCpL032199@lava.sentex.ca>
Message-ID: <200909291435.08797.doconnor@gsoft.com.au>

On Mon, 28 Sep 2009, Mike Tancsa wrote:
> >I also have a similar device, which I've been messing with a bit the
> >last couple of days.  In your case, it isn't seeing the media, just
> > the "drive".  I've had to try various combinations of unplugging
> > the adapter from usb, inserting the media then plugging it back in.
> >  It does seem to work fairly reliably if you boot with the media
> > already inserted, but it doesn't seem to detect media change at
> > all.
>
> I get around it (on my cheap reader) by  always doing a
> cat /dev/null > /dev/da1
> whever I change or insert new media into the reader
>
> That seems to work with the gear I have 99% of the time.

Hmm OK, I sort of expected fdisk da1 to fail straightaway though (it 
takes ~30 seconds to fail for me).

I have unplugged it for now, it interacts annoyingly with SANE because 
that scans the SCSI bus(es) looking for scanner and each umass takes 
30+ seconds to fail.

-- 
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
  -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090929/cb7adea6/attachment.pgp
From bjornh at pvp.se  Tue Sep 29 07:22:00 2009
From: bjornh at pvp.se (Bjorn Hellqvist)
Date: Tue Sep 29 07:22:14 2009
Subject: FreeBSD 7.2-STABLE boot freeze
In-Reply-To: <20090928235136.F37424@ns1.as.pvp.se>
References: <20090921140345.H37424@ns1.as.pvp.se>
	<20090922103150.V37424@ns1.as.pvp.se>
	<4AB8A95E.3060307@icyb.net.ua> <20090922142526.P37424@ns1.as.pvp.se>
	<4AB8E082.8050100@icyb.net.ua> <20090922215700.V37424@ns1.as.pvp.se>
	<4ABA1D1F.3080704@icyb.net.ua> <20090923171004.Q37424@ns1.as.pvp.se>
	<4ABA457E.3060800@freebsd.org> <20090924141927.Y37424@ns1.as.pvp.se>
	<20090925110209.E37424@ns1.as.pvp.se> <4ABC894E.7040204@freebsd.org>
	<20090928092026.B37424@ns1.as.pvp.se> <4AC06ED6.7030402@freebsd.org>
	<20090928235136.F37424@ns1.as.pvp.se>
Message-ID: <20090929085000.B37424@ns1.as.pvp.se>


On Mon, 28 Sep 2009, kama wrote:

>
>
> On Mon, 28 Sep 2009, Andriy Gapon wrote:
>
> > on 28/09/2009 10:21 kama said the following:
> > >
> > > On Fri, 25 Sep 2009, Andriy Gapon wrote:
> > >
> > >> on 25/09/2009 12:04 kama said the following:
> > >>> On Thu, 24 Sep 2009, kama wrote:
> > >>>
> > >>>> I am currently building the source on another machine. Lets see if it will
> > >>>> build it any better.
> > >>> Building the the world on another machine and install it on the DL385
> > >>> machine made it also to freeze.
> > >> Did you still get the message about unresolved symbol?
> > >
> > > I did not try with ACPI_DEBUG enabled.
> > >
> > > Another week, so I can start testing again...
> >
> > I did not ask that :-)
> > I asked -  when you got your latest freeze, did you see that 'unresolved'
> > message or not?
>
> But that only appears when I enable ACPI_DEBUG.


And yes. It stills gets the same undefined symbols. (I presume its these
you are referring to...)

# dmesg | grep -i acpi
Preloaded elf module "/boot/kernel/acpi.ko" at 0xc0ed31d8.
link_elf: symbol AcpiDmDumpMethodInfo undefined
KLD file acpi.ko - could not finalize loading

# nm -A /boot/kernel/* | fgrep AcpiDmDumpMethodInfo
/boot/kernel/acpi.ko:         U AcpiDmDumpMethodInfo
/boot/kernel/acpi.ko.symbols:         U AcpiDmDumpMethodInfo
nm: /boot/kernel/linker.hints: File format not recognized

# uname -a
FreeBSD g24.gs.pvp.se 7.2-STABLE FreeBSD 7.2-STABLE #0: Mon Sep 28
13:39:01 CEST 2009     root@s11.gs.pvp.se:/usr/obj/usr/src/sys/ddb  i386

# diff -ub /usr/src/sys/i386/conf/GENERIC  /usr/src/sys/i386/conf/ddb
--- /usr/src/sys/i386/conf/GENERIC      2009-07-15 10:32:19.000000000
+0200
+++ /usr/src/sys/i386/conf/ddb  2009-09-28 13:25:20.000000000 +0200
@@ -67,6 +67,10 @@
 options        AUDIT                   # Security event auditing
 #options       KDTRACE_HOOKS           # Kernel DTrace hooks

+options                KDB
+options                DDB
+options         ACPI_DEBUG
+
 # To make an SMP kernel, the next two lines are needed
 options        SMP                     # Symmetric MultiProcessor Kernel
 device         apic                    # I/O APIC
#


Its too bad that I cant get into the debugger. The server gets
unresponsive when the freeze occurs. Is there any other option that I can
add so it goes to the debugger?

/Bjorn
From borjam at sarenet.es  Tue Sep 29 08:29:30 2009
From: borjam at sarenet.es (Borja Marcos)
Date: Tue Sep 29 08:29:38 2009
Subject: 8.0RC1, ZFS: deadlock
Message-ID: <089F63A7-574B-4646-97C7-D82B226CD4CF@sarenet.es>


Hello,

I have observed a deadlock condition when using ZFS. We are making a  
heavy usage of zfs send/zfs receive to keep a replica of a dataset on  
a remote machine. It can be done at one minute intervals. Maybe we're  
doing a somehow atypical usage of ZFS, but, well, seems to be a great  
solution to keep filesystem replicas once this is sorted out.


How to reproduce:

Set up two systems. A dataset with heavy I/O activity is replicated  
from the first to the second one. I've used a dataset containing /usr/ 
obj while I did a make buildworld.

Replicate the dataset from the first machine to the second one using  
an incremental send

zfs send -i pool/dataset@Nminus1 pool/dataset@N | ssh destination zfs  
receive -d pool

When there is read activity on the second system, reading the  
replicated system, I mean, having read access while zfs receive is  
updating it, there can be a deadlock. We have discovered this doing a  
test on a hopefully soon in production server, with 8 GB RAM. A Bacula  
backup agent was running and ZFS deadlocked.

I have set up a couple of VMWare Fussion virtual machines in order to  
test this, and it has deadlocked as well. The virtual machines have  
little memory, 512 MB, but I don't believe this is the actual problem.  
There is no complaint about lack of memory.

A running top shows processes stuck on "zfsvfs"

last pid:  2051;  load averages:  0.00,  0.07,  0.55    up 0+01:18:25   
12:05:48
37 processes:  1 running, 36 sleeping
CPU:  0.0% user,  0.0% nice,  0.0% system,  0.0% interrupt,  100% idle
Mem: 18M Active, 20M Inact, 114M Wired, 40K Cache, 59M Buf, 327M Free
Swap: 1024M Total, 1024M Free

   PID USERNAME  THR PRI NICE   SIZE    RES STATE   C   TIME   WCPU  
COMMAND
  1914 root        1  62    0 11932K  2564K zfsvfs  0   0:51  0.00%  
bsdtar
  1093 borjam      1  44    0  8304K  2464K CPU1    1   0:32  0.00% top
  1913 root        1  54    0 11932K  2600K rrl->r  0   0:19  0.00%  
bsdtar
  1019 root        1  44    0 25108K  4812K select  0   0:05  0.00% sshd
  2008 root        1  76    0 13600K  1904K tx->tx  0   0:04  0.00% zfs
  1089 borjam      1  44    0 37040K  5216K select  1   0:04  0.00% sshd
   995 root        1  76    0  8252K  2652K pause   0   0:02  0.00% csh
   840 root        1  44    0 11044K  3828K select  1   0:02  0.00%  
sendmail
  1086 root        1  76    0 37040K  5156K sbwait  1   0:01  0.00% sshd
   850 root        1  44    0  6920K  1612K nanslp  0   0:01  0.00% cron
   607 root        1  44    0  5992K  1540K select  1   0:01  0.00%  
syslogd
  1090 borjam      1  76    0  8252K  2636K pause   1   0:01  0.00% csh
   990 borjam      1  44    0 37040K  5220K select  0   0:00  0.00% sshd
   985 root        1  48    0 37040K  5160K sbwait  1   0:00  0.00% sshd
   911 root        1  44    0  8252K  2608K ttyin   0   0:00  0.00% csh
   991 borjam      1  56    0  8252K  2636K pause   0   0:00  0.00% csh
   844 smmsp       1  46    0 11044K  3852K pause   0   0:00  0.00%  
sendmail

Interestingly, this has blocked access to all the filesystems. I  
cannot, for instance, ssh into the machine anymore, even though all  
the system-important filesystems are on  ufs, I was just using ZFS for  
a test.

Any ideas on what information might be useful to collect? I have the  
vmware machine right now. I've made a couple of VMWare snapshots of  
it, first before breaking into DDB with the deadlock just started, the  
second being into DDB (I've broken into DDB with sysctl).

Also, a copy of the VMWare virtual machine with snapshots is avaiable  
on request. Your choice ;)






Borja.


From borjam at sarenet.es  Tue Sep 29 08:43:43 2009
From: borjam at sarenet.es (Borja Marcos)
Date: Tue Sep 29 08:43:51 2009
Subject: 8.0RC1, ZFS: deadlock
In-Reply-To: <089F63A7-574B-4646-97C7-D82B226CD4CF@sarenet.es>
References: <089F63A7-574B-4646-97C7-D82B226CD4CF@sarenet.es>
Message-ID: <6C7DE346-65C5-4130-86B8-56A60A1DAC28@sarenet.es>


On Sep 29, 2009, at 10:29 AM, Borja Marcos wrote:

>
> Hello,
>
> I have observed a deadlock condition when using ZFS. We are making a  
> heavy usage of zfs send/zfs receive to keep a replica of a dataset  
> on a remote machine. It can be done at one minute intervals. Maybe  
> we're doing a somehow atypical usage of ZFS, but, well, seems to be  
> a great solution to keep filesystem replicas once this is sorted out.
>
>
> How to reproduce:
>
> Set up two systems. A dataset with heavy I/O activity is replicated  
> from the first to the second one. I've used a dataset containing / 
> usr/obj while I did a make buildworld.
>
> Replicate the dataset from the first machine to the second one using  
> an incremental send
>
> zfs send -i pool/dataset@Nminus1 pool/dataset@N | ssh destination  
> zfs receive -d pool
>
> When there is read activity on the second system, reading the  
> replicated system, I mean, having read access while zfs receive is  
> updating it, there can be a deadlock. We have discovered this doing  
> a test on a hopefully soon in production server, with 8 GB RAM. A  
> Bacula backup agent was running and ZFS deadlocked.

Sorry, forgot to explain what was happening on the second system (the  
one receiving the incremental snapshots) for the deadlock to happen.

It was just running an endless loop, copying the contents of /usr/obj  
to another dataset, in order to keep the reading activity going on.

That's how it has deadlocked. On the original test system an rsync did  
the same trick.





Borja

From rgrover1 at gmail.com  Tue Sep 29 09:15:25 2009
From: rgrover1 at gmail.com (Rohit Grover)
Date: Tue Sep 29 09:15:32 2009
Subject: Laggy X11 after updating to 8.0-RC1
In-Reply-To: <20090929035544.GJ4858@sysmon.tcworks.net>
References: <426bed110909281500w194c7c19taf29b1a3996c91fc@mail.gmail.com>
	<alpine.BSF.2.00.0909281725060.39795@wonkity.com>
	<426bed110909281818t68ab8fe5r9a6370c5fa368d7a@mail.gmail.com>
	<alpine.BSF.2.00.0909281926180.40193@wonkity.com>
	<20090929035544.GJ4858@sysmon.tcworks.net>
Message-ID: <426bed110909290215q4a6330b1yeb167d642b16d1ac@mail.gmail.com>

On Tue, Sep 29, 2009 at 11:55 AM, Scott Lambert <lambert@lambertfam.org> wrote:
> On Mon, Sep 28, 2009 at 07:29:46PM -0600, Warren Block wrote:
>> On Tue, 29 Sep 2009, Rohit Grover wrote:
>> >
>> >On Tue, Sep 29, 2009 at 7:30 AM, Warren Block <wblock@wonkity.com> wrote:
>> >>On Tue, 29 Sep 2009, Rohit Grover wrote:
>> >>
>> >>>I have upgraded to 8.0-RC1 (from 7.2-STABLE) on my MacBook 4,1. I
>> >>>did so by checking out stable/8 under /usr/src, rebuilding
>> >>>kernel/world, and using portupgrade to update all installed ports
>> >>>from packages available on the 8.0RC1 DVD-iso.
>> >>>
>> >>>Since the update, my X11 is laggy. Now, I often have to move the
>> >>>mouse before keystrokes/button presses take effect.
>> >>
>> >>Make sure hal and dbus are enabled in rc.conf and running. ?In
>> >>xorg.conf, remove Option "AllowEmptyInput" "off".
>> >>
>> >>A bonus of using hal is that you can remove the keyboard and mouse
>> >>sections from xorg.conf.
>> >>
>> >>>As I've mentioned, I've updated the kernel/world, and updated
>> >>>libpciaccess. Perhaps I'm having issues because I need to remove
>> >>>old libs. How do I remove old libs?
>> >>
>> >>cd /usr/src make check-old-libs make delete-old-libs
>> >
>> >
>> >I deleted old libs using 'make delete-old-libs' from /usr/src,
>> >but that has led to many other problems. ?It seems many libraries
>> >currently in use were deleted in the process. ?I'm having to
>> >rebuild/reinstall many of my applications to get them working again.
>
> I'm seeing something similar to OP, apparent keyboard buffer delays, but
> maybe not exactly. ?When I click from one xterm to another, it may be
> 1 - 30 seconds before my key entries show. ?Firefox seems to have less
> delay after clicks into text fields, but sometimes it is noticeable maybe
> 0.25 to 1 second. ?Just two xterms, the fluxbox toolbar, and firefox
> running. ?No frufru stuff.
>
> I haven't had time to systematically try to narrow down the actual
> problem.
>
> Wiggling the mouse, hitting various keys all seemed like they helped
> at one time or another, but I think I was just trying things until the
> buffer released. ?If I leave it alone, the delays seem to be of about
> the same length as when I'm trying random things to break it loose.
>
> Only clicking in a window (particularly an xterm) seems to stall the
> keyboard buffer. ?Just wiggling the mouse above or around the focused
> window is no problem. ?Clicks take effect immediately. ?I can drag
> the window by the title bar or resize the window without stalling the
> keyboard buffer.
>
> I haven't lost a key press that I've noticed. ?Now I just type blind
> until it catches up or I actually need to see the results of my typing.
>
> Oh, it seems like if there is something in the xterm which can use the
> mouse input, it may not be stalling the keyboard buffer. ?I need to
> watch that more closely.
>
> I've tried with and without an explicit xorg.conf. ?Switching
> back to the console works better without. ?With doesn't leave me a
> usable display outside of X.
>
> It seems like the delays get longer and longer the longer the X session
> has been up. ?But sometimes there will be no delay. ?If I switch
> windows/desktops with alt-tab, ctrl-f#, there is no delay. ?I've been
> wondering if it could be due to the synaptics touchpad. ?I enabled the
> synaptics features about the same time to try to get rid of tap events
> from the touchpad. ?I hate touchpads and still haven't figured out how
> to kill tapping.
>
> agp0: <Intel GM965 SVGA controller> on vgapci0
>
> I've done the delete-old stuff and got mad at KDE4 and did a pkg_delete
> -a in a fit of rage. ?I went back with fluxbox, took about 2 to 3 hours
> to compile everything from source to have my multiple xterms back.
> Firefox took another 2 hours. ?But I was able to *work* while that
> built.
>
> I was running FreeBSD 8-CURRENT pre-beta cycle. ?KDE4 was giving me so
> many fits that I would just run Windows instead so I could get work
> done, sad. ?I don't know if I would have noticed an input buffer delay
> before I upgraded to BETA2 and replaced KDE with fluxbox. ?I just
> couldn't stand to spend that much time in X. ?Windows finally annoyed me
> enough to try something different (fluxbox). ?This problem has been with
> me through the BETAs and now into RC1, as far as I can remember. ?I've
> been busy and trying really hard to ignore workstation issues to get
> work done ever since my PowerBook died.
>
>> When upgrading from one major release of FreeBSD to another, the
>> standard recommendation is to delete all installed applications
>> (pkg_delete -a) and then reinstall everything. ?There may be some
>> incantation of portupgrade or portmaster that will do it. ?pkg_libchk
>> from sysutils/bsdadminscripts may help. ?But that is likely to take
>> longer than just pkg_delete -a and reinstalling applications.
>
> portmaster's man page suggests pkg_delete -a. ?It has explicit
> instructions so you don't miss anything putting them back on. ?Not
> that I've used the instructions yet. ?Rage is not condusive to reading
> manuals.
>

I did a 'pkg_delete -a' to delete all packages, and then installed
fresh packages from the 8.0-RC1 DVD as necessary. I'm back to a useful
system and  X11 isn't lagging anymore.

I hope someone investigates why X11 didn't behave well right after
updating the kernel/world/some-packages.

Thanks.
From marius at nuenneri.ch  Tue Sep 29 09:31:14 2009
From: marius at nuenneri.ch (=?ISO-8859-1?Q?Marius_N=FCnnerich?=)
Date: Tue Sep 29 09:31:20 2009
Subject: Booting FreeBSD 8.0-RC1 from usb stick
Message-ID: <b649e5e0909290201o6f038fd3xdccf94c5039c9e1@mail.gmail.com>

Hi all,

FreeBSD 8.0-RC1 was installed onto hard disk. The root filesystem was
transferred to a usb memory stick via
#pwd
/
# find -print . -x | cpio -pdm /mnt/usbstick

The fstab on the stick was modified such that "/" was to be mounted
from /dev/da0s1a, the ufs fs on the usb stick.
This had proven to work perfectly with 7.2.
In 8.0-RC1, however, this approach fails. After booting the kernel,
the system does not automatically mount the "/" partition. Instead, it
asks for a partition to mount to "/", and when exactly the same
location is entered ("ufs:/dev/da0s1a"), it mounts this partition and
works perfectly.
Explicitly setting the root partition
(vfs.root.mountfrom="ufs:/dev/da0s1a") in /boot/loader.conf does not
help either: Again, the system knows which partition it should mount
to "/", but it fails to do so. (vfs.root.mountfrom.options=rw was set
too).

Any ideas?
Marius
From rnoland at FreeBSD.org  Tue Sep 29 10:11:34 2009
From: rnoland at FreeBSD.org (Robert Noland)
Date: Tue Sep 29 10:11:57 2009
Subject: Excessivly cheap USB device issue
In-Reply-To: <200909291435.08797.doconnor@gsoft.com.au>
References: <200909280009.28658.doconnor@gsoft.com.au>
	<1254062842.2048.1467.camel@balrog.2hip.net>
	<200909280052.n8S0qCpL032199@lava.sentex.ca>
	<200909291435.08797.doconnor@gsoft.com.au>
Message-ID: <1254219084.2248.982.camel@balrog.2hip.net>

On Tue, 2009-09-29 at 14:35 +0930, Daniel O'Connor wrote:
> On Mon, 28 Sep 2009, Mike Tancsa wrote:
> > >I also have a similar device, which I've been messing with a bit the
> > >last couple of days.  In your case, it isn't seeing the media, just
> > > the "drive".  I've had to try various combinations of unplugging
> > > the adapter from usb, inserting the media then plugging it back in.
> > >  It does seem to work fairly reliably if you boot with the media
> > > already inserted, but it doesn't seem to detect media change at
> > > all.
> >
> > I get around it (on my cheap reader) by  always doing a
> > cat /dev/null > /dev/da1
> > whever I change or insert new media into the reader
> >
> > That seems to work with the gear I have 99% of the time.
> 
> Hmm OK, I sort of expected fdisk da1 to fail straightaway though (it 
> takes ~30 seconds to fail for me).
> 
> I have unplugged it for now, it interacts annoyingly with SANE because 
> that scans the SCSI bus(es) looking for scanner and each umass takes 
> 30+ seconds to fail.

FWIW, on yesterdays kernel, mine seems to be working properly and
detecting media change.  I'm not sure what change helped.  Note that I
am running -CURRENT.

robert.

-- 
Robert Noland <rnoland@FreeBSD.org>
FreeBSD

From bu7cher at yandex.ru  Tue Sep 29 10:29:18 2009
From: bu7cher at yandex.ru (Andrey V. Elsukov)
Date: Tue Sep 29 10:29:26 2009
Subject: Booting FreeBSD 8.0-RC1 from usb stick
In-Reply-To: <b649e5e0909290201o6f038fd3xdccf94c5039c9e1@mail.gmail.com>
References: <b649e5e0909290201o6f038fd3xdccf94c5039c9e1@mail.gmail.com>
Message-ID: <4AC1E179.4000908@yandex.ru>

Marius Nu"nnerich wrote:
> Explicitly setting the root partition
> (vfs.root.mountfrom="ufs:/dev/da0s1a") in /boot/loader.conf does not
> help either: Again, the system knows which partition it should mount
> to "/", but it fails to do so. (vfs.root.mountfrom.options=rw was set
> too).

It's known problem and we are waiting for fix. There is a race between
USB and CAM/SCSI subsystems.

-- 
WBR, Andrey V. Elsukov
From des at des.no  Tue Sep 29 10:29:34 2009
From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=)
Date: Tue Sep 29 10:29:41 2009
Subject: glabel+gmirror (8.0-RC1 problem)
In-Reply-To: <20090928210438.ddd2af93.lehmann@ans-netz.de> (Oliver Lehmann's
	message of "Mon, 28 Sep 2009 21:04:38 +0200")
References: <20090927170244.0980d699.lehmann@ans-netz.de>
	<20090927223725.5893371f.lehmann@ans-netz.de>
	<20090928084035.GB1659@garage.freebsd.pl>
	<20090928203756.ef70e0c6.lehmann@ans-netz.de>
	<20090928184926.GA2016@garage.freebsd.pl>
	<20090928210438.ddd2af93.lehmann@ans-netz.de>
Message-ID: <86y6nygi2a.fsf@ds4.des.no>

Oliver Lehmann <lehmann@ans-netz.de> writes:
> I noticed that even when I boot in multiuser, change fstab, then return
> into single user mode and remount / read-only, the label cannot be set.
> I need to boot directly into single user mode. Looks like writing the
> label is denied when the partition was once mounted rw before - even if
> it is actually mounted ro.

IIRC, the underlying GEOM is promoted from ro to rw when you mount the
file system, but it is never "demoted" back to ro.  I don't know if
that's fixable.

DES
-- 
Dag-Erling Sm?rgrav - des@des.no
From thompsa at FreeBSD.org  Tue Sep 29 10:34:40 2009
From: thompsa at FreeBSD.org (Andrew Thompson)
Date: Tue Sep 29 10:34:47 2009
Subject: Excessivly cheap USB device issue
In-Reply-To: <1254219084.2248.982.camel@balrog.2hip.net>
References: <200909280009.28658.doconnor@gsoft.com.au>
	<1254062842.2048.1467.camel@balrog.2hip.net>
	<200909280052.n8S0qCpL032199@lava.sentex.ca>
	<200909291435.08797.doconnor@gsoft.com.au>
	<1254219084.2248.982.camel@balrog.2hip.net>
Message-ID: <20090929101622.GA64206@citylink.fud.org.nz>

On Tue, Sep 29, 2009 at 05:11:24AM -0500, Robert Noland wrote:
> On Tue, 2009-09-29 at 14:35 +0930, Daniel O'Connor wrote:
> > On Mon, 28 Sep 2009, Mike Tancsa wrote:
> > > >I also have a similar device, which I've been messing with a bit the
> > > >last couple of days.  In your case, it isn't seeing the media, just
> > > > the "drive".  I've had to try various combinations of unplugging
> > > > the adapter from usb, inserting the media then plugging it back in.
> > > >  It does seem to work fairly reliably if you boot with the media
> > > > already inserted, but it doesn't seem to detect media change at
> > > > all.
> > >
> > > I get around it (on my cheap reader) by  always doing a
> > > cat /dev/null > /dev/da1
> > > whever I change or insert new media into the reader
> > >
> > > That seems to work with the gear I have 99% of the time.
> > 
> > Hmm OK, I sort of expected fdisk da1 to fail straightaway though (it 
> > takes ~30 seconds to fail for me).
> > 
> > I have unplugged it for now, it interacts annoyingly with SANE because 
> > that scans the SCSI bus(es) looking for scanner and each umass takes 
> > 30+ seconds to fail.
> 
> FWIW, on yesterdays kernel, mine seems to be working properly and
> detecting media change.  I'm not sure what change helped.  Note that I
> am running -CURRENT.

Was that after the sync to Hans's repo? There were around 20 commits so
if anyone can narrow it down to a single rev then it may be able to be
merged.


Andrew
From rnoland at FreeBSD.org  Tue Sep 29 10:38:17 2009
From: rnoland at FreeBSD.org (Robert Noland)
Date: Tue Sep 29 10:38:23 2009
Subject: Excessivly cheap USB device issue
In-Reply-To: <20090929101622.GA64206@citylink.fud.org.nz>
References: <200909280009.28658.doconnor@gsoft.com.au>
	<1254062842.2048.1467.camel@balrog.2hip.net>
	<200909280052.n8S0qCpL032199@lava.sentex.ca>
	<200909291435.08797.doconnor@gsoft.com.au>
	<1254219084.2248.982.camel@balrog.2hip.net>
	<20090929101622.GA64206@citylink.fud.org.nz>
Message-ID: <1254220688.2248.1011.camel@balrog.2hip.net>

On Tue, 2009-09-29 at 23:16 +1300, Andrew Thompson wrote:
> On Tue, Sep 29, 2009 at 05:11:24AM -0500, Robert Noland wrote:
> > On Tue, 2009-09-29 at 14:35 +0930, Daniel O'Connor wrote:
> > > On Mon, 28 Sep 2009, Mike Tancsa wrote:
> > > > >I also have a similar device, which I've been messing with a bit the
> > > > >last couple of days.  In your case, it isn't seeing the media, just
> > > > > the "drive".  I've had to try various combinations of unplugging
> > > > > the adapter from usb, inserting the media then plugging it back in.
> > > > >  It does seem to work fairly reliably if you boot with the media
> > > > > already inserted, but it doesn't seem to detect media change at
> > > > > all.
> > > >
> > > > I get around it (on my cheap reader) by  always doing a
> > > > cat /dev/null > /dev/da1
> > > > whever I change or insert new media into the reader
> > > >
> > > > That seems to work with the gear I have 99% of the time.
> > > 
> > > Hmm OK, I sort of expected fdisk da1 to fail straightaway though (it 
> > > takes ~30 seconds to fail for me).
> > > 
> > > I have unplugged it for now, it interacts annoyingly with SANE because 
> > > that scans the SCSI bus(es) looking for scanner and each umass takes 
> > > 30+ seconds to fail.
> > 
> > FWIW, on yesterdays kernel, mine seems to be working properly and
> > detecting media change.  I'm not sure what change helped.  Note that I
> > am running -CURRENT.
> 
> Was that after the sync to Hans's repo? There were around 20 commits so
> if anyone can narrow it down to a single rev then it may be able to be
> merged.

Looks like I'm at r197575, now.

robert.

> 
> Andrew
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
-- 
Robert Noland <rnoland@FreeBSD.org>
FreeBSD

From borjam at sarenet.es  Tue Sep 29 08:53:45 2009
From: borjam at sarenet.es (Borja Marcos)
Date: Tue Sep 29 11:44:41 2009
Subject: 8.0RC1, ZFS: deadlock
In-R