Re: {arch}/conf/DEFAULTS and uart
On Fri Sep 10 10, John Baldwin wrote: > On Thursday, September 09, 2010 3:50:45 pm Alexander Best wrote: > > On Thu Sep 9 10, Alexander Best wrote: > > > On Thu Sep 9 10, Alexander Best wrote: > > > > hi there, > > > > > > > > except for arm most archs seem to enforce uart support in > > > > conf/DEFAULTS. is > > > > this really necessary? shouldn't DEFAULTS only contain vital > > > > devices/options > > > > without a kernel on a specific arch won't function at all? > > > > > > jhb just explained to me, that the uart entry in DEFAULTS is not a > > > controller > > > or something like that, but the uart backend to use *if* uart gets > > > defined in > > > the kernel config. > > > > > > sorry for the noise folks. > > > > however i found some missing comments and incorrect syntax which i fixed. > > > > see the attached patch. > > I think the ia64 ordering for 'io and mem' is probably more correct > (alphabetically sorted), so I would fix i386 and amd64 and leave ia64 alone. > > The powerpc 'machine' changes are wrong I think as it would break GENERIC64 > and powerpc64 kernel configs in general. Nathan purposefully removed > 'machine' from the powerpc DEFAULTS. here's try #2. ;) cheers. alex > > -- > John Baldwin -- a13x diff --git a/sys/amd64/conf/DEFAULTS b/sys/amd64/conf/DEFAULTS index 1fb52b3..c525935 100644 --- a/sys/amd64/conf/DEFAULTS +++ b/sys/amd64/conf/DEFAULTS @@ -5,12 +5,12 @@ machineamd64 -# Bus support. +# Bus support device isa -# Pseudo devices. -device mem # Memory and kernel memory devices +# Pseudo devices device io # I/O device +device mem # Memory and kernel memory devices # UART chips on this platform device uart_ns8250 diff --git a/sys/arm/conf/DEFAULTS b/sys/arm/conf/DEFAULTS index 591a0a1..5e1512f 100644 --- a/sys/arm/conf/DEFAULTS +++ b/sys/arm/conf/DEFAULTS @@ -5,7 +5,9 @@ machinearm -device mem +# Pseudo devices +device mem # Memory and kernel memory devices +# Default partitioning schemes optionsGEOM_PART_BSD optionsGEOM_PART_MBR diff --git a/sys/i386/conf/DEFAULTS b/sys/i386/conf/DEFAULTS index 32e77e4..d364389 100644 --- a/sys/i386/conf/DEFAULTS +++ b/sys/i386/conf/DEFAULTS @@ -5,16 +5,16 @@ machinei386 -# Bus support. +# Bus support device isa optionsISAPNP -# Floating point support. +# Floating point support device npx -# Pseudo devices. -device mem # Memory and kernel memory devices +# Pseudo devices device io # I/O device +device mem # Memory and kernel memory devices # UART chips on this platform device uart_ns8250 @@ -26,5 +26,5 @@ options GEOM_PART_EBR_COMPAT optionsGEOM_PART_MBR # enable support for native hardware -optionsNATIVE device atpic +optionsNATIVE diff --git a/sys/ia64/conf/DEFAULTS b/sys/ia64/conf/DEFAULTS index 2cb2330..608dcc1 100644 --- a/sys/ia64/conf/DEFAULTS +++ b/sys/ia64/conf/DEFAULTS @@ -5,16 +5,17 @@ machineia64 -# Bus support. +# Bus support device acpi# ACPI support -# Pseudo devices. +# Pseudo devices device io # I/O & EFI runtime device device mem # Memory and kernel memory devices # UART chips on this platform device uart_ns8250 +# Default partitioning schemes optionsGEOM_PART_BSD optionsGEOM_PART_GPT optionsGEOM_PART_MBR diff --git a/sys/mips/conf/DEFAULTS b/sys/mips/conf/DEFAULTS index dc480ce..59e4442 100644 --- a/sys/mips/conf/DEFAULTS +++ b/sys/mips/conf/DEFAULTS @@ -5,9 +5,12 @@ machinemips -device mem +# Pseudo devices +device mem # Memory and kernel memory devices +# UART chips on this platform device uart_ns8250 +# Default partitioning schemes optionsGEOM_PART_BSD optionsGEOM_PART_MBR diff --git a/sys/pc98/conf/DEFAULTS b/sys/pc98/conf/DEFAULTS index f30501e..246f309 100644 --- a/sys/pc98/conf/DEFAULTS +++ b/sys/pc98/conf/DEFAULTS @@ -6,16 +6,16 @@ machinepc98 i386 optionsPC98 -# Bus support. +# Bus support device isa optionsISAPNP -# Floating point support. +# Floating point support device npx -# Pseudo devices. -device mem # Memory and kernel memory devices +# Pseudo devices device io # I/O device +device mem # Memory and kernel memory devices # UART chips on this platform device uart_ns8250 diff --git a/sys/powerpc/conf/DEFAULTS b/sys/powerpc/conf/DEFAULTS index 658c221..5623732 100644 --- a/sys/powerpc/conf/DEFAULTS +++ b/sys/powerpc/conf/DEFAULTS @@ -3,12 +3,13 @@ # # $FreeBSD$ -# Pseudo devices. +# Pseudo devices device mem # Mem
Re: Experimental NFS server oddity
On Sep 11, 2010, at 5:26 PM, Rick Macklem wrote: >> On Sep 11, 2010, at 4:20 PM, Rick Macklem wrote: >> >>> You can also look in /var/log/messages to see if any of the daemons >>> are complaining about something. >> >> Only warning I see on a system reboot is: >> nfsd: can't open /var/db/nfs-stablerestart >> >> Creating this file and then rebooting the system seems to get things >> working. >> >> This file certainly wasn't required by the old nfsd. >> Should this file be created by /etc/rc.d/nfsserver at boot time (if it >> doesn't exist)? >> Or should it be created by installworld? >> > Technically, it should only be created for a fresh install on a disk > that has never been set up before. (ie. Not on an update/upgrade > unless it has never existed before.) > > As such, I just documented it in "man nfsv4" for now, This is going to bite people on upgrades since the old server didn't require this file, so people upgrading from the old nfsd are going to hit this problem pretty consistently. I'd like to at least consider alternatives to the current behavior; maybe one of the following? * If the file doesn't exist on startup, create it and warn loudly. * Similar to isc-dhcp, periodically make a a backup copy of the file and only create a fresh blank one if the file and backup are both missing. * "make installworld" is certainly capable of creating this file only if it doesn't already exist. (That doesn't cover the binary update case, of course.) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Experimental NFS server oddity
> On Sep 11, 2010, at 4:20 PM, Rick Macklem wrote: > > >> I just tried adding > >> > >> nfsv4_server_enable="YES" > >> > >> to my rc.conf and found that after I rebooted the server, my > >> FreeBSD 8 > >> client (still using NFSv3) couldn't connect because there was no > >> RPC > >> mapping for nfs. > > > Did you specify both of these in rc.conf? > > nfs_server_enable="YES" > > nfsv4_server_enable="YES" > > > > You need to specify both of them (and nfsuserd="YES" if you going to > > use > > NFSv4). See "man nfsv4" for more. > > Both specified, as well as > rpcbind_enable="YES" > > > If you did specify both, then do a "ps axHl" to see what didn't > > start up. > > rpcbind, mountd, and nfsuserd are all running, but nfsd is not > running. > > > You can also look in /var/log/messages to see if any of the daemons > > are complaining about something. > > Only warning I see on a system reboot is: > nfsd: can't open /var/db/nfs-stablerestart > > Creating this file and then rebooting the system seems to get things > working. > > This file certainly wasn't required by the old nfsd. > Should this file be created by /etc/rc.d/nfsserver at boot time (if it > doesn't exist)? > Or should it be created by installworld? > Technically, it should only be created for a fresh install on a disk that has never been set up before. (ie. Not on an update/upgrade unless it has never existed before.) If this file is lost during a crash, the technically correct thing is to recover it from backups and not let the server start until it is recovered, since the information in it is critical to a correct reboot recovery of the NFSv4 state. So the answer is "no" for /etc/rc.d/nfsserver unless you don't care about correct server crash recovery. I don't know if installworld can differentiate between a fresh install and an upgrade? (I suppose it could create it if it doesn't already exist.) As such, I just documented it in "man nfsv4" for now, rick ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CPU C-state storange on Panasonic TOUGH BOOK CF-R9
On Sun, 12 Sep 2010 08:14:09 +0900
Norikatsu Shigemura wrote:
> According to acpidump -dt, I could find CPU0CST table, but
> not found _CST.
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> - - - -
> Scope (\)
> {
> Name (SSDT, Package (0x0C)
> {
> :
> "CPU0CST ",
> 0xDA9AB618,
> 0x05CD,
> :
> })
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> - - - -
> Hum... ACPI CA 20100806 has a bug?
Humm... I wonder if CF-R9 required another initialization?
I don't know what is HI0 and HC0. But default values of HI0 and
HC0 is 0, and HI0 and HC0 are set CST related values by GCAP,
I think..
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - -
Scope (\_PR.CPU0)
{
Name (HI0, Zero)
Name (HC0, Zero)
:
Method (GCAP, 1, NotSerialized)
{
CreateDWordField (Arg0, Zero, STS0)
CreateDWordField (Arg0, 0x04, CAP0)
If (LOr (LEqual (STS0, 0x06), LEqual (STS0, 0x0A)))
{
Return (Zero)
}
If (And (STS0, One))
{
And (CAP0, 0x0BFF, CAP0)
Return (Zero)
}
Or (And (PDC0, 0x7FFF), CAP0, PDC0)
If (And (CFGD, One))
{
If (LAnd (LAnd (And (CFGD, 0x0100), LEqual (And (PDC0,
0x09), 0x09)), LNot (And (SDTL, One
{
Or (SDTL, One, SDTL)
OperationRegion (IST0, SystemMemory, DerefOf (Index (SSDT,
One)), DerefOf (Index (SSDT, 0x02
)))
Load (IST0, HI0)
}
}
If (And (CFGD, 0xF0))
{
If (LAnd (LAnd (And (CFGD, 0x0100), And (PDC0, 0x18
)), LNot (And (SDTL, 0x02
{
Or (SDTL, 0x02, SDTL)
OperationRegion (CST0, SystemMemory, DerefOf (Index (SSDT,
0x07)), DerefOf (Index (SSDT, 0x08
)))
Load (CST0, HC0)
}
}
Return (Zero)
}
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - -
Thank you.
--
Norikatsu Shigemura
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
ZFS v28 and sendfile()
Seems to not work properly, at least as implemented in the nginx web server (specifically www/nginx-devel from ports). I have "sendfile on;" in my nginx.conf and files served from a ZFS filesystem are garbled in seemingly random ways (their md5 changes every time). Shutting it off resolves the problem. Using sendfile with a UFS partition on the same machine causes no problems. -- Rob Farmer ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Experimental NFS server oddity
On Sep 11, 2010, at 4:20 PM, Rick Macklem wrote: >> I just tried adding >> >> nfsv4_server_enable="YES" >> >> to my rc.conf and found that after I rebooted the server, my FreeBSD 8 >> client (still using NFSv3) couldn't connect because there was no RPC >> mapping for nfs. > Did you specify both of these in rc.conf? > nfs_server_enable="YES" > nfsv4_server_enable="YES" > > You need to specify both of them (and nfsuserd="YES" if you going to use > NFSv4). See "man nfsv4" for more. Both specified, as well as rpcbind_enable="YES" > If you did specify both, then do a "ps axHl" to see what didn't start up. rpcbind, mountd, and nfsuserd are all running, but nfsd is not running. > You can also look in /var/log/messages to see if any of the daemons > are complaining about something. Only warning I see on a system reboot is: nfsd: can't open /var/db/nfs-stablerestart Creating this file and then rebooting the system seems to get things working. This file certainly wasn't required by the old nfsd. Should this file be created by /etc/rc.d/nfsserver at boot time (if it doesn't exist)? Or should it be created by installworld? Tim ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Experimental NFS server oddity
> I just tried adding > > nfsv4_server_enable="YES" > > to my rc.conf and found that after I rebooted the server, my FreeBSD 8 > client (still using NFSv3) couldn't connect because there was no RPC > mapping for nfs. > > Did you specify both of these in rc.conf? nfs_server_enable="YES" nfsv4_server_enable="YES" You need to specify both of them (and nfsuserd="YES" if you going to use NFSv4). See "man nfsv4" for more. If you did specify both, then do a "ps axHl" to see what didn't start up. There should be: rpcbind mountd nfsd and for NFSv4 to work nfsuserd You can also look in /var/log/messages to see if any of the daemons are complaining about something. rick ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CPU C-state storange on Panasonic TOUGH BOOK CF-R9
Hi nate.
On Sat, 11 Sep 2010 11:30:29 -0700
Nate Lawson wrote:
> I think the issue is that C2 is not available for some reason and thus
> C3 can't be used either. The way to tell is to use acpidump and look for
> the CPU objects' _CST fields.
I attached acpidump -dt (nork-CFR9.asl.bz2) on previous mail, and
I couldn't find _CST, too.
And I added more ACPI debug option, ACPI_DB_INFO. I got following:
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - -
cpu0: on acpi0
PROCESSOR-0311 [230584] cpu_attach: acpi_cpu0: P_BLK at 0x410/6
ACPI: SSDT 0xda9adc18 002AA (v01 PmRef Cpu0Ist 3000 INTL 20061109)
ACPI: Dynamic OEM Table Load:
ACPI: SSDT 0 002AA (v01 PmRef Cpu0Ist 3000 INTL 20061109)
ACPI: SSDT 0xda9ab618 005CD (v01 PmRef Cpu0Cst 3001 INTL 20061109)
ACPI: Dynamic OEM Table Load:
ACPI: SSDT 0 005CD (v01 PmRef Cpu0Cst 3001 INTL 20061109)
PROCESSOR-0696 [241753] cpu_cx_cst: acpi_cpu0: C2[1] not available.
PROCESSOR-0730 [241753] cpu_cx_cst: acpi_cpu0: Got C3 - 245 latency
cpu1: on acpi0
PROCESSOR-0311 [241991] cpu_attach: acpi_cpu1: P_BLK at 0x410/6
ACPI: SSDT 0xda9aca98 00303 (v01 PmRefApIst 3000 INTL 20061109)
ACPI: Dynamic OEM Table Load:
ACPI: SSDT 0 00303 (v01 PmRefApIst 3000 INTL 20061109)
ACPI: SSDT 0xda9aad98 00119 (v01 PmRefApCst 3000 INTL 20061109)
ACPI: Dynamic OEM Table Load:
ACPI: SSDT 0 00119 (v01 PmRefApCst 3000 INTL 20061109)
PROCESSOR-0696 [254000] cpu_cx_cst: acpi_cpu1: C2[1] not available.
PROCESSOR-0730 [254000] cpu_cx_cst: acpi_cpu1: Got C3 - 245 latency
cpu2: on acpi0
PROCESSOR-0311 [254238] cpu_attach: acpi_cpu2: P_BLK at 0x410/6
PROCESSOR-0696 [255657] cpu_cx_cst: acpi_cpu2: C2[1] not available.
PROCESSOR-0730 [255657] cpu_cx_cst: acpi_cpu2: Got C3 - 245 latency
cpu3: on acpi0
PROCESSOR-0311 [255895] cpu_attach: acpi_cpu3: P_BLK at 0x410/6
PROCESSOR-0696 [257314] cpu_cx_cst: acpi_cpu3: C2[1] not available.
PROCESSOR-0730 [257314] cpu_cx_cst: acpi_cpu3: Got C3 - 245 latency
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - -
According to acpidump -dt, I could find CPU0CST table, but
not found _CST.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - -
Scope (\)
{
Name (SSDT, Package (0x0C)
{
:
"CPU0CST ",
0xDA9AB618,
0x05CD,
:
})
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - -
Hum... ACPI CA 20100806 has a bug?
Thank you.
--
Norikatsu Shigemura
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: about in_multi_mtx @ netinet/in_mcast.c:1095
On Fri, Sep 10, 2010 at 05:17:39PM -0400, John Baldwin wrote: > On Friday, September 10, 2010 4:28:58 pm Weongyo Jeong wrote: > > On Thu, Sep 09, 2010 at 02:32:52PM -0400, John Baldwin wrote: > > > On Thursday, September 09, 2010 1:41:46 pm Weongyo Jeong wrote: > > > > On Thu, Sep 09, 2010 at 09:36:19AM -0400, John Baldwin wrote: > > > > > On Wednesday, September 08, 2010 4:14:19 pm Weongyo Jeong wrote: > > > > > > Hello, > > > > > > > > > > > > I have a question about IN_MULTI_LOCK() because it uses MTX_DEF flag > > > > > > when it's initialized so I always encounters the following LOR > > > > > > > > > > > > lock order reversal: (sleepable after non-sleepable) > > > > > > 1st 0x80d0b560 in_multi_mtx (in_multi_mtx) @ > > > > > netinet/in_mcast.c:1095 > > > > > > 2nd 0xff00014e3850 USB device SX lock (USB device SX lock) @ > > > > > > > > > /usr/home/freebsd_usb/sys/modules/usb/usb/../../../dev/usb/usb_request.c:441 > > > > > > KDB: stack backtrace: > > > > > > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > > > > > > _witness_debugger() at _witness_debugger+0x2e > > > > > > witness_checkorder() at witness_checkorder+0x807 > > > > > > _sx_xlock() at _sx_xlock+0x55 > > > > > > usbd_do_request_flags() at usbd_do_request_flags+0xe5 > > > > > > axe_cmd() at axe_cmd+0xc7 > > > > > > axe_setmulti_locked() at axe_setmulti_locked+0x70 > > > > > > axe_setmulti() at axe_setmulti+0x3e > > > > > > axe_ioctl() at axe_ioctl+0x132 > > > > > > if_addmulti() at if_addmulti+0x19b > > > > > > in_joingroup_locked() at in_joingroup_locked+0x1bc > > > > > > in_joingroup() at in_joingroup+0x52 > > > > > > in_control() at in_control+0x1144 > > > > > > ifioctl() at ifioctl+0x1118 > > > > > > kern_ioctl() at kern_ioctl+0xbe > > > > > > ioctl() at ioctl+0xfd > > > > > > syscallenter() at syscallenter+0x1aa > > > > > > syscall() at syscall+0x4c > > > > > > Xfast_syscall() at Xfast_syscall+0xe2 > > > > > > > > > > > > when I uses the following code at driver's ioctl routine: > > > > > > > > > > > > case SIOCADDMULTI: > > > > > > case SIOCDELMULTI: > > > > > > axe_setmulti(sc, 0); > > > > > > break; > > > > > > > > > > > > It means that USB driver always should defer SIOCADDMULTI / > > > > > > SIOCDELMULTI handling to the other process context to avoid LOR. > > > > > > > > > > > > My question is that is it safe if the multicasting operations for > USB > > > > > > device happens without IN_MULTI_LOCK? Or is there any race cases > > > > > > if > the > > > > > > task is deferred? > > > > > > > > > > Why is USB using an sx lock instead of a mutex? > > > > > > > > Frankly speaking I also don't know why hps@ uses sx lock. That is one > > > > of things I'd like to change it. > > > > > > > > Just looking the comment at usb_reques...@441: > > > > > > > > /* > > > > * Grab the default sx-lock so that serialisation > > > > * is achieved when multiple threads are involved: > > > > */ > > > > sx_xlock(&udev->ctrl_sx); > > > > > > > > I think he might want to hold the lock even if the thread is going into > > > > sleep. It might be for serialization. > > > > > > > > However even if we succeed to change the lock from sx to mutex, it's > > > > hard to avoid the requests going into the sleep. It means USB stack > > > > should call like below: > > > > > > > > mtx_sleep(chan, IN_MULTI_LOCK, ...); > > > > > > > > to avoid the kernel's complain (would be `sleep with holding > > > > non-sleepable lock'). > > > > > > > > What I'd like to say is that the sleeping is big problem if mutex is > > > > used that it'd be worse when multiple mutex locks are used. > > > > > > > > So I'm looking for a fundamental solution to solve this problem. > > > > Welcomes any ideas. > > > > > > It is probably fine to just schedule a task to do the actual work of > > > axe_setmulti(). I think you do not need to lock IN_MULTI_LOCK yourself > > > in > > > your task handler as long as your handler holds the appropriate lock > > > (if_maddr_rlock() IIRC) when walking the interface's multicast address > list. > > > > OK. I'll try to use a task handler for this case. > > > > One thing, just for curious. Why the lower layer (in this case it might > > be netinet/in_mcast.c) calls ioctl interface with holding IN_MULTI_LOCK? > > If it calls ioctl without holding the lock, all drivers (specially all > > USB drivers) which handles SIOCADDMULTI and SIOCDELMULTI don't need to > > implement their own taskqueue or process context. > > > > It looks to me that calling ioctl interface with holding IN_MULTI_LOCK > > is useless if the drivers hold if_maddr_rlock(ifp) lock properly though > > I could miss something important. > > It would introduce races in the multicast code to drop the lock around the > ioctl which would complicate it a good bit. Non-USB ethernet drivers just > use > plain locks which handle this situation just fine. OK I see. Thank yo
Experimental NFS server oddity
I just tried adding nfsv4_server_enable="YES" to my rc.conf and found that after I rebooted the server, my FreeBSD 8 client (still using NFSv3) couldn't connect because there was no RPC mapping for nfs. Removing the option above and rebooting the server makes it work again. Server is GENERIC 9-CURRENT r211027 Client is GENERIC 8-STABLE r211321 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CPU C-state storange on Panasonic TOUGH BOOK CF-R9
Norikatsu Shigemura wrote: > Hi ACPI specialists! > > I noticed that CPU cooling doesn't work with testing mav@'s > timers_oneshot*.patch, so I got following results: > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > - - - - > $ sysctl -a | grep cx > hw.acpi.cpu.cx_lowest: C1 > dev.cpu.0.cx_supported: C1/3 > dev.cpu.0.cx_lowest: C1 > dev.cpu.0.cx_usage: 100.00% last 24us > dev.cpu.1.cx_supported: C1/3 > dev.cpu.1.cx_lowest: C1 > dev.cpu.1.cx_usage: 100.00% last 485us > dev.cpu.2.cx_supported: C1/3 > dev.cpu.2.cx_lowest: C1 > dev.cpu.2.cx_usage: 100.00% last 155us > dev.cpu.3.cx_supported: C1/3 > dev.cpu.3.cx_lowest: C1 > dev.cpu.3.cx_usage: 100.00% last 590us I think the problem is here. > cpu0: on acpi0 > PROCESSOR-0311 [230584] cpu_attach: acpi_cpu0: P_BLK at 0x410/6 > ACPI: SSDT 0xda9adc18 002AA (v01 PmRef Cpu0Ist 3000 INTL 20061109) > ACPI: Dynamic OEM Table Load: > ACPI: SSDT 0 002AA (v01 PmRef Cpu0Ist 3000 INTL 20061109) > ACPI: SSDT 0xda9ab618 005CD (v01 PmRef Cpu0Cst 3001 INTL 20061109) > ACPI: Dynamic OEM Table Load: > ACPI: SSDT 0 005CD (v01 PmRef Cpu0Cst 3001 INTL 20061109) > PROCESSOR-0696 [241753] cpu_cx_cst: acpi_cpu0: C2[1] not > available. > PROCESSOR-0730 [241753] cpu_cx_cst: acpi_cpu0: Got C3 - 245 > latency > cpu1: on acpi0 > PROCESSOR-0311 [241991] cpu_attach: acpi_cpu1: P_BLK at 0x410/6 > ACPI: SSDT 0xda9aca98 00303 (v01 PmRefApIst 3000 INTL 20061109) > ACPI: Dynamic OEM Table Load: > ACPI: SSDT 0 00303 (v01 PmRefApIst 3000 INTL 20061109) > ACPI: SSDT 0xda9aad98 00119 (v01 PmRefApCst 3000 INTL 20061109) > ACPI: Dynamic OEM Table Load: > ACPI: SSDT 0 00119 (v01 PmRefApCst 3000 INTL 20061109) > PROCESSOR-0696 [254000] cpu_cx_cst: acpi_cpu1: C2[1] not > available. > PROCESSOR-0730 [254000] cpu_cx_cst: acpi_cpu1: Got C3 - 245 > latency > cpu2: on acpi0 > PROCESSOR-0311 [254238] cpu_attach: acpi_cpu2: P_BLK at 0x410/6 > PROCESSOR-0696 [255657] cpu_cx_cst: acpi_cpu2: C2[1] not > available. > PROCESSOR-0730 [255657] cpu_cx_cst: acpi_cpu2: Got C3 - 245 > latency > cpu3: on acpi0 > PROCESSOR-0311 [255895] cpu_attach: acpi_cpu3: P_BLK at 0x410/6 > PROCESSOR-0696 [257314] cpu_cx_cst: acpi_cpu3: C2[1] not > available. > PROCESSOR-0730 [257314] cpu_cx_cst: acpi_cpu3: Got C3 - 245 > latency I think the issue is that C2 is not available for some reason and thus C3 can't be used either. The way to tell is to use acpidump and look for the CPU objects' _CST fields. -- Nate ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Intel HD Graphics support ready?
Hi rnoland. Do you have any schedule to support Intel HD Graphics on Core i series like Clarkdale/Arrandle? I'm waiting for your patch:-). Thank you. -- Norikatsu Shigemura ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: g_event spinning 100% when doing 'gpart add'
On Fri, Sep 10, 2010 at 6:57 PM, Yuri Pankov wrote:
> Nevermind me. That's what I thought why I was getting the same gpart behavior
> switching between kernels, with and without DEBUG_LOCKS. Sorry about that.
>
> Same here, gpart hangs on:
> 3826 gpart CALL __sysctl(0x7fffa250,0x3,0,0x7fffa268,0,0)
> 3826 gpart SCTL "kern.geom.confxml"
When I was doing my sbuf changes I temporarily had a patch to change
these sysctls to use the new drains. I couldn't get any output from
the three kern.geom.conf{txt,dot,xml} sysctls (they didn't hang but
the output was empty) so I reverted those parts before committing. I
doubt my changes affected this, but I will check on Monday when I'm
back at work to see if the lack of output is due to my changes or
predates me.
Cheers,
matthew
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CFR: Replace man/manpath/whatis/apropos with a shell script
Anonymous writes: > PATH_MAN_SUB bin/../man > PATH_MAN_SUB bin/../.man # e.g. for ~/.bin + ~/.man > PATH_MAN_SUB /usr/bin/../share/man Oops, that would be non-trivial substitution. It's more like PATH_MAN_ADD bin ../man PATH_MAN_ADD .bin ../.man PATH_MAN_ADD /usr/bin ../share/man And the code for third example would look smth like # set by PATH_MAN_ADD first and second argument from=/usr/bin to=../share/man case "$path" in *$from) p="$path/$to" p=$(realpath $p) add_to_manpath "$p" ;; esac ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: DHCP server in base
On Fri, Sep 10, 2010 at 10:33:11PM -0700, Kevin Oberman wrote: > > Date: Fri, 10 Sep 2010 17:33:22 -0700 > > From: Doug Barton > > Sender: owner-freebsd-curr...@freebsd.org > > > > On 9/10/2010 1:48 PM, Aleksandr Rybalko wrote: > > > > > > Hi, > > > > > > another argument about hostapd :) if have access point we must have > > > way to assign IP for AP clients. > > > > To start with, your assumption is wrong. DHCPd is not *actually* a > > requirement, although I admit that practically it is. > > It is not. I routinely use hostapd for access for my iPod. I use > static addressing and don't run dhcpd. With IPv6 you can additionally use stateles autoconfiguration. The requirement for autoconfiguration with DHCP is a problem of IPv4, which won't have a long future for mainstream purspose anymore. Nevertheless there must be a decision about base and not-base and this point will always be questionable to some. I'm also not very strict about bind - it is handy to have dig available, but at the same time it is handy to have whois available, but the whois in base isn't good enough anymore for most cases. A DHCP client however can be required for initial network configuration to retrieve further packages. dig and co can be handy to debug initial network problems, but there are other tools in base for those problems. But to repeat a point which was already made: Someone who can configure a DHCP server really shouldn't have problems to install a package - installing packages or ports is so basic for an operationg system that this is likely one of the first things to learn. Additionally there are ready made systems based on FreeBSD for special purpose, which probably come with the required tools. > > > Since this device is router I must be > > > able to serve DHCP. And current implementation of dhcpclient, that we > > > have, is same isc-dhcp, and I replace system dhcpclient with ports > > > one+dhcpd but with small patch that put basic dhcp utils onto > > > libdhcp.so. DHCP servers don't have to live on routers and there are many reasons to have them installed somewhere else. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
bonnie++ failed on locally mounted NFS
Searching PR database for 'drastic I/O error' returns kern/33203, which seems a little bit irrelevant as there is no 'bad cookie' error in -CURRENT. cur /tmp> uname -a FreeBSD cur.local.domain 9.0-CURRENT FreeBSD 9.0-CURRENT #23: Sat Aug 14 07:25:01 CST 2010 r...@cur.local.domain:/usr/src/sys/i386/compile/cur i386 cur /tmp> cat /etc/exports /home/test -maproot=root cur /tmp> sudo mount localhost:/home/test /mnt/nfs && cd /mnt/nfs && mount /dev/ad0s2a on / (ufs, NFS exported, local) devfs on /dev (devfs, local, multilabel) /dev/ad0s2e on /var (ufs, local, soft-updates) /dev/ad0s2d.journal on /usr (ufs, asynchronous, NFS exported, local) /dev/md0 on /tmp (ufs, local, soft-updates) /dev/ad0s2f.eli on /home (ufs, NFS exported, local, soft-updates) localhost:/home/test on /mnt/nfs (nfs) cur /mnt/nfs> bonnie++ Writing a byte at a time...done Writing intelligently...done Rewriting...done Reading a byte at a time...done Reading intelligently...done start 'em...done...done...done...done...done... Create files in sequential order...done. Stat files in sequential order...done. Delete files in sequential order...Bonnie: drastic I/O error (rmdir): Directory not empty Cleaning up test directory after error. Exit 1 cur /mnt/nfs> Reproducible with RELENG_7, RELENG_8 and -CURRENT. However, running bonnie++ on local file system such like UFS won't fail. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CFR: Replace man/manpath/whatis/apropos with a shell script
Stefan Bethke writes: > Am 11.09.2010 um 09:35 schrieb Gordon Tetlow: > >> On Thu, Sep 9, 2010 at 8:17 PM, Anonymous wrote: >> >>> Gordon Tetlow writes: >>> 2. Imports configuration from /usr/local/etc/man.d/*.conf and >>> /etc/man.conf (purposefully changed the manpath.config file since it is a different syntax). >>> >>> Hmm, and if LOCALBASE != /usr/local? hier(7) does not specify /usr/local >>> as the only place installed packages may reside in, only default one. >>> >> >> That variable is not easily found in shell. I'm open to suggestions on how >> to figure it out. I suppose I could try something like make -V LOCALBASE Nah, don't bring make(1) dependency. The user may have WITHOUT_MAKE in his src.conf. So, just use LOCALBASE from environment if it's defined. >> since it would be in /etc/make.conf if it is set. Another alternative would >> be to parse the PATH and look for ../etc/man.d for each path component. That How about let user control search_path behaviour? PATH_MAN_SUB bin/../man PATH_MAN_SUB bin/../.man # e.g. for ~/.bin + ~/.man PATH_MAN_SUB /usr/bin/../share/man PATH_CONF_SUB bin/../etc/man.d It's a bit more flexible than MANPATH_MAP ever was. BTW, if you care about aesthetics ../../../../ can be eleminated with realpath(1). >> would be even more generic (and allow for the user to customize it >> potentially). > > Take it from /etc/man.conf, like the rc.d paths are resolved? This'll work, too. I already have to set a bunch of variables in rc.conf because rc.d avoids LOCALBASE as some kind of curse. While environ(7) exist just for that, make using non-default configuration more easy. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: DHCP server in base
On Fri, 10 Sep 2010 17:33:22 -0700 Doug Barton wrote: > On 9/10/2010 1:48 PM, Aleksandr Rybalko wrote: > > > > Hi, > > > > another argument about hostapd :) if have access point we must have > > way to assign IP for AP clients. > > To start with, your assumption is wrong. DHCPd is not *actually* a > requirement, although I admit that practically it is. > > > Last spring I made firmware based on FreeBSD for router with only 4MB > > NOR flash (D-Link DIR-320). > > In this category (micro-miniaturization) you're already in the > "significant customization needed" area, which means that general > arguments about "the base" don't apply. > > > Since this device is router I must be > > able to serve DHCP. And current implementation of dhcpclient, that we > > have, is same isc-dhcp, and I replace system dhcpclient with ports > > one+dhcpd but with small patch that put basic dhcp utils onto > > libdhcp.so. > > Your argument is creative and well thought out, but I personally don't > find it persuasive. Counter arguments that come immediately to mind are: > 1. The DHCP server is not going to benefit any but a small minority of > FreeBSD users. > 2. The software is already available in the ports tree, and adding a > port/package of it really is not an overwhelming burden. > > More generally, the main reason I want to keep more stuff out of the > base, and remove some of the stuff that's in there now, is that it makes > maintenance difficult across FreeBSD branches. We have a general policy > that if we have a major version N of something in a release branch that > we don't upgrade that major version without a really good reason to > avoid POLA surprises for our users. Once again using BIND as an example, > this has led to a really old and past-EOL version of BIND in FreeBSD 6 > which I've only gotten away with because anyone doing serious DNS work > nowadays has to upgrade to at least 9.6 anyway. But it's an ugly > situation, and I don't want to repeat it. > > The problems get worse and/or more complex with the more 3rd party stuff > you start including in the base. In part because of the product > lifecycle issues that are similar to BIND's, but also due to the > possibility of licensing issues (such as with gcc and/or other GPL > software) and other more esoteric factors. > > Even with home-grown stuff like our pkg_* tools we have problems because > when we want to introduce new features (or deprecate old ones) there is > currently a _minimum_ 3-year cycle we have to follow in order to make > sure that the new feature is/is not available on all supported versions > of FreeBSD. That's the main motivation behind my continuing to repeat > the suggestion to move those tools specifically into the ports tree so > that we can better support innovation in our ports/packages system. > > In my view what we've needed to do for a long time now is to seriously > strip down the notion of what "the base" should be to those items that > are needed to work together for a specific API/ABI/AKI release, and move > everything else into the ports tree. (Obviously there would be some > exemptions made for really basic/vital stuff like ls, etc.) We can do > this in a way that finds a middle ground between the linux model where > literally everything is a package and the traditional BSD model of > providing a "complete system," which is hardly ever true since I've > never been involved with any FreeBSD system administration where there > were absolutely no ports/packages installed at all. > > Such a system could also be streamlined by creating a ports virtual > category (something like "system") the packages for which could be > included in the install media as long as we are judicious about what > goes in there. Things like wpa_supplicant, dhclient, DNS tools, etc. > could all be in that category, and all we'd have to do to make that work > is to very slightly expand the list of questions that sysinstall already > asks. > > So this is a much longer version of my previous response which hopefully > gives you more background about why it's a bad idea to add *any* more > 3rd party stuff to the base. > > > Doug > > -- > > ... and that's just a little bit of history repeating. > -- Propellerheads > > Improve the effectiveness of your Internet presence with > a domain name makeover!http://SupersetSolutions.com/ > Hi, I fully agree with a small exception: Base dhclient -rwxr-xr-x 1 ray wheel 109296 Sep 11 15:53 dhclient Modified isc-dhcp -rwxr-xr-x 1 ray wheel 65316 Jun 4 12:33 dhclient -rwxr-xr-x 1 ray wheel 74768 Jun 4 12:33 dhcpd -rwxr-xr-x 1 ray wheel 12624 Jun 4 12:33 dhcrelay -rwxr-xr-x 1 ray wheel 128752 Jun 4 12:33 libdhcp.so 3 tools basically use same code (I move this code in libdhcp) Now in base already most of this code (Thought this is 70-80%%), why not pick up the remaining 20-30%% that add two useful
Re: CFR: Replace man/manpath/whatis/apropos with a shell script
On Thu, Sep 9, 2010 at 7:41 PM, Alexander Best wrote: > > Feedback on the man(1), manpath(1), apropos(1), and man.conf(5) manpages > > would be appreciated. I'm new to manpage authoring and could use a > review. > > you forgot the AUTHORS section in all of the man pages. ;) it's always nice > to > see who wrote the code by reading the man pages and not having to look at > the > source itself imho. > It felt weird to promote myself like that. I might add it. There is certainly precedent for either way. Gordon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CFR: Replace man/manpath/whatis/apropos with a shell script
On Thu, Sep 9, 2010 at 12:48 PM, Anonymous wrote: > The order is still bogus compared to gnu man. If I don't like our > ancient GNU tools and altered PATH in order to prefer ones from ports > then I certainly don't want to view old manpages, too. The base manpath > should be appended *after* any PATH substitutions. > > $ man -aw gperf # man.sh > /usr/share/man/en.UTF-8/man1/gperf.1.gz > /usr/share/man/man1/gperf.1.gz > LOCALBASE/man/man1/gperf.1.gz > > $ man -aw gperf # gnu man > LOCALBASE/man/man1/gperf.1.gz > /usr/share/man/en.UTF-8/man1/gperf.1.gz > > > $ echo $PATH > > > LOCALBASE/libexec/ccache:HOME/.bin:LOCALBASE/sbin:LOCALBASE/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:HOME/blah/bin > Fixed this up to no longer add an unconditional system search path. While I'm not planning on supporting MANPATH_MAP, I have added special casing for /bin and /usr/bin as encountered in PATH. > And it doesn't show anything when there are no arguments, not even > returning with exit code > 0. > > $ man # man.sh > > $ man # gnu man > What manual page do you want? > zsh: exit 1 man > Added. Updated drop location at: http://people.freebsd.org/~gordon/man.shar Thanks for the feedback, Gordon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[head tinderbox] failure on powerpc64/powerpc
TB --- 2010-09-11 06:11:11 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-09-11 06:11:11 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2010-09-11 06:11:11 - cleaning the object tree TB --- 2010-09-11 06:12:01 - cvsupping the source tree TB --- 2010-09-11 06:12:01 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc64/powerpc/supfile TB --- 2010-09-11 06:12:32 - building world TB --- 2010-09-11 06:12:32 - MAKEOBJDIRPREFIX=/obj TB --- 2010-09-11 06:12:32 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-09-11 06:12:32 - TARGET=powerpc TB --- 2010-09-11 06:12:32 - TARGET_ARCH=powerpc64 TB --- 2010-09-11 06:12:32 - TZ=UTC TB --- 2010-09-11 06:12:32 - __MAKE_CONF=/dev/null TB --- 2010-09-11 06:12:32 - cd /src TB --- 2010-09-11 06:12:32 - /usr/bin/make -B buildworld >>> World build started on Sat Sep 11 06:12:32 UTC 2010 >>> 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 >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Sat Sep 11 08:00:55 UTC 2010 TB --- 2010-09-11 08:00:55 - generating LINT kernel config TB --- 2010-09-11 08:00:55 - cd /src/sys/powerpc/conf TB --- 2010-09-11 08:00:55 - /usr/bin/make -B LINT TB --- 2010-09-11 08:00:55 - building LINT kernel TB --- 2010-09-11 08:00:55 - MAKEOBJDIRPREFIX=/obj TB --- 2010-09-11 08:00:55 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-09-11 08:00:55 - TARGET=powerpc TB --- 2010-09-11 08:00:55 - TARGET_ARCH=powerpc64 TB --- 2010-09-11 08:00:55 - TZ=UTC TB --- 2010-09-11 08:00:55 - __MAKE_CONF=/dev/null TB --- 2010-09-11 08:00:55 - cd /src TB --- 2010-09-11 08:00:55 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Sep 11 08:00:55 UTC 2010 >>> 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 [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/uart/uart_cpu_powerpc.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/kern/kern_clocksource.c /src/sys/kern/kern_clocksource.c: In function 'timer2cb': /src/sys/kern/kern_clocksource.c:174: error: 'IPI_STATCLOCK' undeclared (first use in this function) /src/sys/kern/kern_clocksource.c:174: error: (Each undeclared identifier is reported only once /src/sys/kern/kern_clocksource.c:174: error: for each function it appears in.) /src/sys/kern/kern_clocksource.c: In function 'configtimer': /src/sys/kern/kern_clocksource.c:281: error: 'IPI_STATCLOCK' undeclared (first use in this function) *** Error code 1 Stop in /obj/powerpc.powerpc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-09-11 08:14:13 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-09-11 08:14:13 - ERROR: failed to build lint kernel TB --- 2010-09-11 08:14:13 - 4890.38 user 1443.13 system 7381.63 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc64-powerpc.full ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[head tinderbox] failure on powerpc/powerpc
TB --- 2010-09-11 05:50:11 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-09-11 05:50:11 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2010-09-11 05:50:11 - cleaning the object tree TB --- 2010-09-11 05:50:54 - cvsupping the source tree TB --- 2010-09-11 05:50:54 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2010-09-11 05:51:44 - building world TB --- 2010-09-11 05:51:44 - MAKEOBJDIRPREFIX=/obj TB --- 2010-09-11 05:51:44 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-09-11 05:51:44 - TARGET=powerpc TB --- 2010-09-11 05:51:44 - TARGET_ARCH=powerpc TB --- 2010-09-11 05:51:44 - TZ=UTC TB --- 2010-09-11 05:51:44 - __MAKE_CONF=/dev/null TB --- 2010-09-11 05:51:44 - cd /src TB --- 2010-09-11 05:51:44 - /usr/bin/make -B buildworld >>> World build started on Sat Sep 11 05:51:45 UTC 2010 >>> 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 11 07:42:35 UTC 2010 TB --- 2010-09-11 07:42:35 - generating LINT kernel config TB --- 2010-09-11 07:42:35 - cd /src/sys/powerpc/conf TB --- 2010-09-11 07:42:35 - /usr/bin/make -B LINT TB --- 2010-09-11 07:42:35 - building LINT kernel TB --- 2010-09-11 07:42:35 - MAKEOBJDIRPREFIX=/obj TB --- 2010-09-11 07:42:35 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-09-11 07:42:35 - TARGET=powerpc TB --- 2010-09-11 07:42:35 - TARGET_ARCH=powerpc TB --- 2010-09-11 07:42:35 - TZ=UTC TB --- 2010-09-11 07:42:35 - __MAKE_CONF=/dev/null TB --- 2010-09-11 07:42:35 - cd /src TB --- 2010-09-11 07:42:35 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Sep 11 07:42:35 UTC 2010 >>> 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 [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/uart/uart_cpu_powerpc.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/kern/kern_clocksource.c /src/sys/kern/kern_clocksource.c: In function 'timer2cb': /src/sys/kern/kern_clocksource.c:174: error: 'IPI_STATCLOCK' undeclared (first use in this function) /src/sys/kern/kern_clocksource.c:174: error: (Each undeclared identifier is reported only once /src/sys/kern/kern_clocksource.c:174: error: for each function it appears in.) /src/sys/kern/kern_clocksource.c: In function 'configtimer': /src/sys/kern/kern_clocksource.c:281: error: 'IPI_STATCLOCK' undeclared (first use in this function) *** Error code 1 Stop in /obj/powerpc.powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-09-11 07:56:31 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-09-11 07:56:31 - ERROR: failed to build lint kernel TB --- 2010-09-11 07:56:31 - 5236.97 user 1290.70 system 7579.84 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc-powerpc.full ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CFR: Replace man/manpath/whatis/apropos with a shell script
Am 11.09.2010 um 09:35 schrieb Gordon Tetlow: > On Thu, Sep 9, 2010 at 8:17 PM, Anonymous wrote: > >> Gordon Tetlow writes: >> >>> 2. Imports configuration from /usr/local/etc/man.d/*.conf and >> /etc/man.conf >>> (purposefully changed the manpath.config file since it is a different >>> syntax). >> >> Hmm, and if LOCALBASE != /usr/local? hier(7) does not specify /usr/local >> as the only place installed packages may reside in, only default one. >> > > That variable is not easily found in shell. I'm open to suggestions on how > to figure it out. I suppose I could try something like make -V LOCALBASE > since it would be in /etc/make.conf if it is set. Another alternative would > be to parse the PATH and look for ../etc/man.d for each path component. That > would be even more generic (and allow for the user to customize it > potentially). Take it from /etc/man.conf, like the rc.d paths are resolved? Stefan -- Stefan BethkeFon +49 151 14070811 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CFR: Replace man/manpath/whatis/apropos with a shell script
On Thu, Sep 9, 2010 at 8:17 PM, Anonymous wrote: > Gordon Tetlow writes: > > > 2. Imports configuration from /usr/local/etc/man.d/*.conf and > /etc/man.conf > > (purposefully changed the manpath.config file since it is a different > > syntax). > > Hmm, and if LOCALBASE != /usr/local? hier(7) does not specify /usr/local > as the only place installed packages may reside in, only default one. > That variable is not easily found in shell. I'm open to suggestions on how to figure it out. I suppose I could try something like make -V LOCALBASE since it would be in /etc/make.conf if it is set. Another alternative would be to parse the PATH and look for ../etc/man.d for each path component. That would be even more generic (and allow for the user to customize it potentially). Thoughts? Gordon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
