From won.derick at yahoo.com  Mon Dec  1 00:13:12 2008
From: won.derick at yahoo.com (Won De Erick)
Date: Mon Dec  1 00:13:19 2008
Subject: Watchdog for Boser (HS-7001)
Message-ID: <547602.79284.qm@web45809.mail.sp1.yahoo.com>

Hello,

I was trying the assembly language program that is specified in the following document (p24) to set, reset the built-in watchdog timer for the Boser Box.

http://www.boser.com.tw/manual/HS-7001v1.1.pdf

I then installed nasm in FreeBSD 6.2, and added the following lines at the beginning.

section .text
  global _start

  _start:

I did assemble, link (ld) and got no error. But when I run, I got the following error:

# ./watchdog.out
Bus error (core dumped)

I noticed that the port addresses used are similar with the following used by Super Micro Computer. I don't know if these are standards or not. I suspect that the boards are using same controller chips from Intel. I've been googling the web for more documentations on these but I could hardly find one.

http://www.stinkfoot.org/wdt.txt

How should I make this program works?

Thanks,

Won


# dmesg
Copyright (c) 1992-2007 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 6.2-RELEASE #0: Fri Jan 12 10:40:27 UTC 2007
    root@dessler.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC
ACPI APIC Table: <IntelR AWRDACPI>
Timecounter "i8254" frequency 1193182 Hz quality 0
CPU: Intel(R) Pentium(R) 4 CPU 2.80GHz (2799.21-MHz 686-class CPU)
  Origin = "GenuineIntel"  Id = 0xf29  Stepping = 9
  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<CNTX-ID,<b14>>
real memory  = 528416768 (503 MB)
avail memory = 507666432 (484 MB)
ioapic0 <Version 2.0> irqs 0-23 on motherboard
kbd1 at kbdmux0
ath_hal: 0.9.17.2 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413)
acpi0: <IntelR AWRDACPI> on motherboard
acpi0: Power Button (fixed)
Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000
acpi_timer0: <24-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0
cpu0: <ACPI CPU> on acpi0
acpi_button0: <Power Button> on acpi0
pcib0: <ACPI Host-PCI bridge> port 0xcf8-0xcff on acpi0
pci0: <ACPI PCI bus> on pcib0
agp0: <Intel 82845G (845G GMCH) SVGA controller> mem 0xe0000000-0xe7ffffff,0xec700000-0xec77ffff irq 16 at device 2.0 on pci0
agp0: detected 8060k stolen memory
agp0: aperture size is 128M
uhci0: <Intel 82801DB (ICH4) USB controller USB-A> port 0xe200-0xe21f irq 16 at device 29.0 on pci0
uhci0: [GIANT-LOCKED]
usb0: <Intel 82801DB (ICH4) USB controller USB-A> on uhci0
usb0: USB revision 1.0
uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub0: 2 ports with 2 removable, self powered
uhci1: <Intel 82801DB (ICH4) USB controller USB-B> port 0xe000-0xe01f irq 19 at device 29.1 on pci0
uhci1: [GIANT-LOCKED]
usb1: <Intel 82801DB (ICH4) USB controller USB-B> on uhci1
usb1: USB revision 1.0
uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub1: 2 ports with 2 removable, self powered
uhci2: <Intel 82801DB (ICH4) USB controller USB-C> port 0xe100-0xe11f irq 18 at device 29.2 on pci0
uhci2: [GIANT-LOCKED]
usb2: <Intel 82801DB (ICH4) USB controller USB-C> on uhci2
usb2: USB revision 1.0
uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub2: 2 ports with 2 removable, self powered
ehci0: <Intel 82801DB/L/M (ICH4) USB 2.0 controller> mem 0xec780000-0xec7803ff irq 23 at device 29.7 on pci0
ehci0: [GIANT-LOCKED]
usb3: EHCI version 1.0
usb3: companion controllers, 2 ports each: usb0 usb1 usb2
usb3: <Intel 82801DB/L/M (ICH4) USB 2.0 controller> on ehci0
usb3: USB revision 2.0
uhub3: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1
uhub3: 6 ports with 6 removable, self powered
pcib1: <ACPI PCI-PCI bridge> at device 30.0 on pci0
pci1: <ACPI PCI bus> on pcib1
fxp0: <Intel 82801DB (ICH4) Pro/100 Ethernet> port 0xd100-0xd13f mem 0xec680000-0xec680fff irq 20 at device 8.0 on pci1
miibus0: <MII bus> on fxp0
inphy0: <i82562ET 10/100 media interface> on miibus0
inphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
fxp0: Ethernet address: 00:50:b7:f2:40:ea
em0: <Intel(R) PRO/1000 Network Connection Version - 6.2.9> port 0xd000-0xd03f mem 0xec620000-0xec63ffff,0xec600000-0xec61ffff irq 18 at device 9.0 on pci1
em0: Ethernet address: 00:50:b7:f2:40:eb
pci1: <network> at device 12.0 (no driver attached)
pci1: <network> at device 13.0 (no driver attached)
pcib2: <PCI-PCI bridge> at device 15.0 on pci1
pci2: <PCI bus> on pcib2
fxp1: <Intel 82559 Pro/100 Ethernet> port 0xc000-0xc03f mem 0xec502000-0xec502fff,0xec000000-0xec0fffff irq 23 at device 0.0 on pci2
miibus1: <MII bus> on fxp1
inphy1: <i82555 10/100 media interface> on miibus1
inphy1:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
fxp1: Ethernet address: 00:50:b7:f2:37:74
fxp2: <Intel 82559 Pro/100 Ethernet> port 0xc100-0xc13f mem 0xec500000-0xec500fff,0xec100000-0xec1fffff irq 20 at device 1.0 on pci2
miibus2: <MII bus> on fxp2
inphy2: <i82555 10/100 media interface> on miibus2
inphy2:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
fxp2: Ethernet address: 00:50:b7:f2:37:73
fxp3: <Intel 82559 Pro/100 Ethernet> port 0xc200-0xc23f mem 0xec503000-0xec503fff,0xec200000-0xec2fffff irq 21 at device 2.0 on pci2
miibus3: <MII bus> on fxp3
inphy3: <i82555 10/100 media interface> on miibus3
inphy3:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
fxp3: Ethernet address: 00:50:b7:f2:37:72
fxp4: <Intel 82559 Pro/100 Ethernet> port 0xc300-0xc33f mem 0xec501000-0xec501fff,0xec300000-0xec3fffff irq 22 at device 3.0 on pci2
miibus4: <MII bus> on fxp4
inphy4: <i82555 10/100 media interface> on miibus4
inphy4:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
fxp4: Ethernet address: 00:50:b7:f2:37:71
isab0: <PCI-ISA bridge> at device 31.0 on pci0
isa0: <ISA bus> on isab0
atapci0: <Intel ICH4 UDMA100 controller> port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xf000-0xf00f at device 31.1 on pci0
ata0: <ATA channel 0> on atapci0
ata1: <ATA channel 1> on atapci0
pci0: <serial bus, SMBus> at device 31.3 (no driver attached)
pci0: <multimedia, audio> at device 31.5 (no driver attached)
acpi_tz0: <Thermal Zone> on acpi0
fdc0: <floppy drive controller> port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0
fdc0: [FAST]
sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0
sio0: type 16550A
sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0
sio1: type 16550A
ppc0: <Standard parallel printer port> port 0x378-0x37f,0x778-0x77b irq 7 on acpi0
ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode
ppbus0: <Parallel port bus> on ppc0
plip0: <PLIP network interface> on ppbus0
lpt0: <Printer> on ppbus0
lpt0: Interrupt-driven port
ppi0: <Parallel I/O> on ppbus0
atkbdc0: <Keyboard controller (i8042)> port 0x60,0x64 irq 1 on acpi0
atkbd0: <AT Keyboard> irq 1 on atkbdc0
kbd0 at atkbd0
atkbd0: [GIANT-LOCKED]
sio2: <16550A-compatible COM port> port 0x3e8-0x3ef irq 10 on acpi0
sio2: type 16550A
sio3: <16550A-compatible COM port> port 0x2e8-0x2ef irq 11 on acpi0
sio3: type 16550A
pmtimer0 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
Timecounter "TSC" frequency 2799213056 Hz quality 800
Timecounters tick every 1.000 msec
ad0: 1946MB <TOSHIBA THNCF2G04QG 3.00> at ata0-master PIO4
Trying to mount root from ufs:/dev/ad0s1a
pid 17016 (watchdog.out), uid 0: exited on signal 10 (core dumped)
pid 17032 (watchdog.out), uid 0: exited on signal 10 (core dumped)



      

From rea-fbsd at codelabs.ru  Mon Dec  1 00:23:44 2008
From: rea-fbsd at codelabs.ru (Eygene Ryabinkin)
Date: Mon Dec  1 00:23:51 2008
Subject: keeping track of local modifications
In-Reply-To: <200812010830.17259.max@love2party.net>
References: <4931CB02.9070904@gmail.com> <4932E8CF.9040501@freebsd.org>
	<49337f04.p8QqvfzTga07ypa6%perryh@pluto.rain.com>
	<200812010830.17259.max@love2party.net>
Message-ID: <gFpinjQW6hEatbsT+XzE0kSsZf0@kjaK+/sQ5DW5981v71UogZJPf/0>

Max, good day.

Mon, Dec 01, 2008 at 08:30:16AM +0100, Max Laier wrote:
> On Monday 01 December 2008 07:07:00 perryh@pluto.rain.com wrote:
> > * http://wiki.freebsd.org/LocalMercurial
> >
> >   This seems less of a resource hog, and (if I am understanding
> >   matters correctly) is able to start from the installed /usr/src/...
> >   rather than requiring the would-be hacker to download a redundant
> >   instance, but I was concerned that the page may not be up to date
> >   with current FreeBSD development methodology (e.g. csup vs cvsup).
> 
> If you want to contribute back, this is *not* the way to go.  Patches from 
> anything other than SVN and maybe CVS are mostly useless.

May be I am missing something, but what's wrong with the patches from
other VCS, providing that with Subversion you can exchange only by the
plain diffs?  Yes, Git/Mercurial patches should be applied with 'patch
-p1', but that's all.  Subversion has no notion simular to 'git
format-patch' and 'git am', if I am not messing the things up, so the
only way to exchange with others are the patches themselves.

> The local hg/git
> approach is nice if you are already familiar with hg or git and just want to
> keep some patch sets for yourself.  If you are looking to keep/develop a patch
> set and eventually share it with the world, svn or svk is the way to go.

The only issue I do see is about '$FreeBSD$', but plain Subversion
clients shouldn't mess with it.  If person has commit privileges to the
FreeBSD repository, then yes, probably Subversion will be fine (but
there are git-svn and hgsvn, so locally user can work with the different
VCS even in this case).

Do I missing some important thing here?

Thanks!
-- 
Eygene
 _                ___       _.--.   #
 \`.|\..----...-'`   `-._.-'_.-'`   #  Remember that it is hard
 /  ' `         ,       __.--'      #  to read the on-line manual   
 )/' _/     \   `-_,   /            #  while single-stepping the kernel.
 `-'" `"\_  ,_.-;_.-\_ ',  fsc/as   #
     _.-'_./   {_.'   ; /           #    -- FreeBSD Developers handbook 
    {_.-``-'         {_/            #
-------------- 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-hackers/attachments/20081201/596112a8/attachment.pgp
From christoph.mallon at gmx.de  Mon Dec  1 00:38:54 2008
From: christoph.mallon at gmx.de (Christoph Mallon)
Date: Mon Dec  1 00:39:01 2008
Subject: Watchdog for Boser (HS-7001)
In-Reply-To: <547602.79284.qm@web45809.mail.sp1.yahoo.com>
References: <547602.79284.qm@web45809.mail.sp1.yahoo.com>
Message-ID: <4933A29B.8060907@gmx.de>

Won De Erick schrieb:
> Hello,
> 
> I was trying the assembly language program that is specified in the following document (p24) to set, reset the built-in watchdog timer for the Boser Box.
> 
> http://www.boser.com.tw/manual/HS-7001v1.1.pdf
> 
> I then installed nasm in FreeBSD 6.2, and added the following lines at the beginning.
> 
> section .text
>   global _start
> 
>   _start:
> 
> I did assemble, link (ld) and got no error. But when I run, I got the following error:
> 
> # ./watchdog.out
> Bus error (core dumped)

> MOV DX, 2EH
> MOV AL, 87H
> OUT DX, AL
> OUT DX, AL

Userland is not allowed to write to ports. That's the bus error you see. 
Also without a call to the exit syscall at the end, it will segfault.

Regards
	Christoph
From rink at FreeBSD.org  Mon Dec  1 01:03:48 2008
From: rink at FreeBSD.org (Rink Springer)
Date: Mon Dec  1 01:03:57 2008
Subject: Watchdog for Boser (HS-7001)
In-Reply-To: <4933A29B.8060907@gmx.de>
References: <547602.79284.qm@web45809.mail.sp1.yahoo.com>
	<4933A29B.8060907@gmx.de>
Message-ID: <20081201090421.GA99082@rink.nu>

On Mon, Dec 01, 2008 at 09:38:51AM +0100, Christoph Mallon wrote:
> Userland is not allowed to write to ports. That's the bus error you see. 
> Also without a call to the exit syscall at the end, it will segfault.

Note that you can write to ports from userland by opening /dev/io - if
you have it opened, you can write to the ports.

-- 
Rink P.W. Springer                                - http://rink.nu
"Anyway boys, this is America. Just because you get more votes doesn't
 mean you win." - Fox Mulder
From won.derick at yahoo.com  Mon Dec  1 01:20:16 2008
From: won.derick at yahoo.com (Won De Erick)
Date: Mon Dec  1 01:20:23 2008
Subject: Watchdog for Boser (HS-7001)
References: <547602.79284.qm@web45809.mail.sp1.yahoo.com>
	<4933A29B.8060907@gmx.de> <20081201090421.GA99082@rink.nu>
Message-ID: <611173.7111.qm@web45805.mail.sp1.yahoo.com>

> ----- Original Message ----

> From: Rink Springer <rink@FreeBSD.org>
> 
> 
On Mon, Dec 01, 2008 at 09:38:51AM +0100, Christoph Mallon wrote:
> > Userland is not allowed to write to ports. That's the bus error you see. 
> > Also without a call to the exit syscall at the end, it will segfault.
> 
> Note that you can write to ports from userland by opening /dev/io - if
> you have it opened, you can write to the ports.
> 

I've added the following at the end

  mov eax, 1 ; SYS_exit
  call doint

  doint:
     int 0x80
     ret

Besides, I can see the following at /dev
crw-------   1 root   wheel       0,  16 Nov 27 01:53 io

How should I make this open? do i need to %include this?


> -- 
> Rink P.W. Springer                                - http://rink.nu
> "Anyway boys, this is America. Just because you get more votes doesn't
>  mean you win." - Fox Mulder
> 



      

From rink at FreeBSD.org  Mon Dec  1 01:26:46 2008
From: rink at FreeBSD.org (Rink Springer)
Date: Mon Dec  1 01:26:58 2008
Subject: Watchdog for Boser (HS-7001)
In-Reply-To: <611173.7111.qm@web45805.mail.sp1.yahoo.com>
References: <547602.79284.qm@web45809.mail.sp1.yahoo.com>
	<4933A29B.8060907@gmx.de> <20081201090421.GA99082@rink.nu>
	<611173.7111.qm@web45805.mail.sp1.yahoo.com>
Message-ID: <20081201092720.GB99082@rink.nu>

On Mon, Dec 01, 2008 at 01:20:14AM -0800, Won De Erick wrote:
> Besides, I can see the following at /dev
> crw-------   1 root   wheel       0,  16 Nov 27 01:53 io
> 
> How should I make this open? do i need to %include this?

No, you need to invoke an open syscall just in the same way you did the
previous system call. Try looking at
http://goodfellas.shellcode.com.ar/docz/asm/aslenguage.html, which is a
tutorial for exactly this sort of thing.

You don't have to read or write to it; just opening it is enough to get
the I/O access you need.

Regards,

-- 
Rink P.W. Springer                                - http://rink.nu
"Anyway boys, this is America. Just because you get more votes doesn't
 mean you win." - Fox Mulder

> 
> 
> > -- 
> > Rink P.W. Springer                                - http://rink.nu
> > "Anyway boys, this is America. Just because you get more votes doesn't
> >  mean you win." - Fox Mulder
> > 
> 
> 
> 
>       
> 
> _______________________________________________
> freebsd-hackers@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
From christoph.mallon at gmx.de  Mon Dec  1 01:35:35 2008
From: christoph.mallon at gmx.de (Christoph Mallon)
Date: Mon Dec  1 01:35:42 2008
Subject: Watchdog for Boser (HS-7001)
In-Reply-To: <611173.7111.qm@web45805.mail.sp1.yahoo.com>
References: <547602.79284.qm@web45809.mail.sp1.yahoo.com>	<4933A29B.8060907@gmx.de>
	<20081201090421.GA99082@rink.nu>
	<611173.7111.qm@web45805.mail.sp1.yahoo.com>
Message-ID: <4933AFD4.3070501@gmx.de>

Won De Erick schrieb:
>> ----- Original Message ----
> 
>> From: Rink Springer <rink@FreeBSD.org>
>>
>>
> On Mon, Dec 01, 2008 at 09:38:51AM +0100, Christoph Mallon wrote:
>>> Userland is not allowed to write to ports. That's the bus error you see. 
>>> Also without a call to the exit syscall at the end, it will segfault.
>> Note that you can write to ports from userland by opening /dev/io - if
>> you have it opened, you can write to the ports.
>>
> 
> I've added the following at the end
> 
>   mov eax, 1 ; SYS_exit
>   call doint
> 
>   doint:
>      int 0x80
>      ret
> 
> Besides, I can see the following at /dev
> crw-------   1 root   wheel       0,  16 Nov 27 01:53 io
> 
> How should I make this open? do i need to %include this?

You're probably better of writing this in C. Here is a wrapper for the 
out instruction:

static inline outb(unsigned short port, unsigned char data)
{
   asm("outb %0, %1" : : "a" (data), "dN" (port));
}

As Rink mentioned, you have to open /dev/io. The process must have 
super-user privileges, see io(4).

Regards
	Christoph
From avg at icyb.net.ua  Mon Dec  1 02:22:20 2008
From: avg at icyb.net.ua (Andriy Gapon)
Date: Mon Dec  1 02:22:29 2008
Subject: dd if=/dev/mem can hang a machine?
In-Reply-To: <200811302014.mAUKE5YF046736@fire.js.berklix.net>
References: <200811302014.mAUKE5YF046736@fire.js.berklix.net>
Message-ID: <4933BAD3.2060700@icyb.net.ua>

on 30/11/2008 22:14 Julian Stacey said the following:
> Gary Jennejohn wrote:
>> On Fri, 28 Nov 2008 15:28:35 +0200
>> Andriy Gapon <avg@icyb.net.ua> wrote:
>>
>>> I have a new machine with DG33TL mainboard (ICH9/G33).
>>> In a course of some hacking I ran dd if=/dev/mem ... to scan all memory,
>>> this caused the machine to hang.
>>> I tried to reproduce and this is 100% reproducible.
>>>
>>> I am not used to such behavior. In older days I could scan all the
>>> memory without any issues.
>>>
>>> Could this be related to some modern form of memory-mapped IO? Or to
>>> Intel Management Engine (that seems t bite into DRAM)?
>>> Or something else?
>>>
>>> Just wondering.
>>>
>> That's what I would assume.  With some hardware just reading a register
>> can be harmful.
> 
> I just crashed 3 normally stable machines trying that.
> I only tried for casual interest. I acknowledge Gary's comment above :-)
> 
> 	dd if=/dev/mem of=/dev/null
> 
> 	FreeBSD lapa.js.berklix.net 4.11-RELEASE FreeBSD 4.11-RELEASE
> 	#0: Fri Jul  7 17:56:30 CEST 2006
> 	jhs@lapa.jhs.private:/usr/src/sys/compile/LAPA.small  i386
> 
> 	FreeBSD laps.js.berklix.net 7.0-RELEASE FreeBSD 7.0-RELEASE
> 	#2: Mon Sep  8 15:39:53 CEST 2008
> 	jhs@laps.js.berklix.net:/usr1/ftp/pri/FreeBSD/releases/7.0-RELEASE/src/sys/i386/compile/LAPS.small
> 	i386
> 
> 	FreeBSD john.js.berklix.net 7.1-BETA2 FreeBSD 7.1-BETA2 #0:
> 	Sun Oct 12 20:59:28 UTC 2008
> 	root@driscoll.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC  amd64

Thank you for going to all the trouble.
I see now that I have to be more careful in this respect.

-- 
Andriy Gapon
From laladelausanne at gmail.com  Mon Dec  1 03:08:21 2008
From: laladelausanne at gmail.com (=?UTF-8?Q?Nikola_Kne=C5=BEevi=C4=87?=)
Date: Mon Dec  1 03:10:13 2008
Subject: How to build kernel module spread on subdirectories?
In-Reply-To: <49332E5C.9020303@freebsd.org>
References: <711D7381-D852-4B6B-991A-84BA6DEFB679@gmail.com>	<2A1A4C21-8A2D-4151-BCA0-5FAE1D3BBE86@gmail.com>	<200811301843.28564.fbsd.hackers@rachie.is-a-geek.net>
	<94D09AB0-86B6-4D91-BD61-AB02A12CC260@gmail.com>
	<49332E5C.9020303@freebsd.org>
Message-ID: <D6756955-6E0B-429A-9216-2CF223D503D7@gmail.com>

On 1 Dec 2008, at 01:22 , Tim Kientzle wrote:

>> .MAKEFILEDEPS: elements.mk
>> .sinclude "elements.mk"
>> .include <bsd.kmod.mk>
>> --->8---
>> When I run make depend, it only includes SRCSs from BSDmakefile,  
>> not  those from elements.mk.
>
> I would try adding a "beforedepend" requirement:
>
> beforedepend: elements.mk
>
> Look at /usr/share/mk/bsd.dep.mk, which has the 'make depend'
> logic.  It supports optional "beforedepend" and "afterdepend"
> targets.

Hi Tim,
thanks for the tip.

I've tried adding beforedepend: elements.mk rule before .sinclude.

Unfortunately, everything is the same still. Is there a way to force  
explicitly what .MAKEFILEDEPS? beforedepend will create elements.mk,  
but that file won't be re-read and included before depend is called.

Cheers,
Nikola
From fbsd.hackers at rachie.is-a-geek.net  Mon Dec  1 03:31:55 2008
From: fbsd.hackers at rachie.is-a-geek.net (Mel)
Date: Mon Dec  1 03:32:02 2008
Subject: How to build kernel module spread on subdirectories?
In-Reply-To: <D6756955-6E0B-429A-9216-2CF223D503D7@gmail.com>
References: <711D7381-D852-4B6B-991A-84BA6DEFB679@gmail.com>
	<49332E5C.9020303@freebsd.org>
	<D6756955-6E0B-429A-9216-2CF223D503D7@gmail.com>
Message-ID: <200812011231.52262.fbsd.hackers@rachie.is-a-geek.net>

On Monday 01 December 2008 12:08:13 Nikola Kne?evi? wrote:
> On 1 Dec 2008, at 01:22 , Tim Kientzle wrote:
> >> .MAKEFILEDEPS: elements.mk
> >> .sinclude "elements.mk"
> >> .include <bsd.kmod.mk>
> >> --->8---
> >> When I run make depend, it only includes SRCSs from BSDmakefile,
> >> not  those from elements.mk.
> >
> > I would try adding a "beforedepend" requirement:
> >
> > beforedepend: elements.mk
> >
> > Look at /usr/share/mk/bsd.dep.mk, which has the 'make depend'
> > logic.  It supports optional "beforedepend" and "afterdepend"
> > targets.
>
> Hi Tim,
> thanks for the tip.
>
> I've tried adding beforedepend: elements.mk rule before .sinclude.
>
> Unfortunately, everything is the same still. Is there a way to force
> explicitly what .MAKEFILEDEPS? beforedepend will create elements.mk,
> but that file won't be re-read and included before depend is called.

Does it have to be generated? What's the contents of that file after 
generation and what generates it?

As you discovered, includes are done before targets. You would need seperate 
invocations of make, to generate the file and get it included.
Maybe this will work, tho I doubt it (I expect the include to screw with the 
beforedepend target):

beforedepend:
.if !exists(${.CURDIR}/elements.mk)
	${MAKE} ${MAKEFLAGS} -f ${MAKEFILE} genmk
.endif
.if exists(${.CURDIR}/elements.mk)
.include "${.CURDIR}/elements.mk"
.endif

genmk:
	# do whatever here to generate the mk file

-- 
Mel
From des at des.no  Mon Dec  1 03:44:51 2008
From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=)
Date: Mon Dec  1 03:44:57 2008
Subject: change to ee.c
In-Reply-To: <20081130004331.086941f3@tau> (Bruce Cran's message of "Sun, 30
	Nov 2008 00:43:31 -0800")
References: <49320FF7.4040901@gmail.com> <4932122A.8070209@delphij.net>
	<493214DC.2080904@gmail.com> <20081130004331.086941f3@tau>
Message-ID: <86r64sqfv1.fsf@ds4.des.no>

Bruce Cran <bruce@cran.org.uk> writes:
> The version of ee in FreeBSD is fairly old: the latest from
> http://mahon.cwx.net/ is 1.4.6.  Even so, the latest version still
> generates lots of warnings from gcc because the developer used NULL
> instead of '\0' (i.e the NULL constant instead of the NUL string).

This is a good reason to define NULL as ((void *)0)...

DES
-- 
Dag-Erling Sm?rgrav - des@des.no
From des at des.no  Mon Dec  1 03:55:42 2008
From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=)
Date: Mon Dec  1 03:55:49 2008
Subject: change to ee.c
In-Reply-To: <493214DC.2080904@gmail.com> (Eitan Adler's message of "Sat, 29
	Nov 2008 23:21:48 -0500")
References: <49320FF7.4040901@gmail.com> <4932122A.8070209@delphij.net>
	<493214DC.2080904@gmail.com>
Message-ID: <86myfgqfcy.fsf@ds4.des.no>

Eitan Adler <eitanadlerlist@gmail.com> writes:
> Xin LI <d@delphij.net> writes:
> > Tanks for interested in this but I'm afraid that your patch is
> > incorrect.  mkstemp returns a file descriptor rather than a string
> > pointer, therefore, the subsequent open() would have undefined
> > behavior.  It looks like that we actually want fd = mkstemp() here.
> Thanks.  If this is the case how come gcc did not return any warnings?

Because ee(1) is built with most warnings disabled, precisely because
the source code is of such poor quality (by modern standards).  Try
this:

$ cd /usr/src/usr.bin/ee
$ make clean
$ make WARNS=3 2>&1 | grep -cw warning
72
$ make WARNS=6 2>&1 | grep -cw warning 
188

This is on amd64; you will get fewer on i386.  Someone added casts to
silence legitimate warnings about pointers being assigned to integers,
so gcc will only complain about those assignments on platforms where
sizeof(int) == sizeof(void *).

DES
-- 
Dag-Erling Sm?rgrav - des@des.no
From des at des.no  Mon Dec  1 03:58:22 2008
From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=)
Date: Mon Dec  1 03:58:29 2008
Subject: Watchdog for Boser (HS-7001)
In-Reply-To: <4933AFD4.3070501@gmx.de> (Christoph Mallon's message of "Mon, 01
	Dec 2008 10:35:16 +0100")
References: <547602.79284.qm@web45809.mail.sp1.yahoo.com>
	<4933A29B.8060907@gmx.de> <20081201090421.GA99082@rink.nu>
	<611173.7111.qm@web45805.mail.sp1.yahoo.com> <4933AFD4.3070501@gmx.de>
Message-ID: <86fxl8qf8i.fsf@ds4.des.no>

Christoph Mallon <christoph.mallon@gmx.de> writes:
> You're probably better of writing this in C.

He's probably better off writing a watchdog(4) driver for the Boser (or
getting someone to write one for him - not easy to do without hardware
to test on, though)

DES
-- 
Dag-Erling Sm?rgrav - des@des.no
From gary.jennejohn at freenet.de  Mon Dec  1 04:19:16 2008
From: gary.jennejohn at freenet.de (Gary Jennejohn)
Date: Mon Dec  1 04:19:28 2008
Subject: Watchdog for Boser (HS-7001)
In-Reply-To: <4933A29B.8060907@gmx.de>
References: <547602.79284.qm@web45809.mail.sp1.yahoo.com>
	<4933A29B.8060907@gmx.de>
Message-ID: <20081201131912.355b8356@ernst.jennejohn.org>

On Mon, 01 Dec 2008 09:38:51 +0100
Christoph Mallon <christoph.mallon@gmx.de> wrote:

> Won De Erick schrieb:
> > Hello,
> > 
> > I was trying the assembly language program that is specified in the following document (p24) to set, reset the built-in watchdog timer for the Boser Box.
> > 
> > http://www.boser.com.tw/manual/HS-7001v1.1.pdf
> > 
> > I then installed nasm in FreeBSD 6.2, and added the following lines at the beginning.
> > 
> > section .text
> >   global _start
> > 
> >   _start:
> > 
> > I did assemble, link (ld) and got no error. But when I run, I got the following error:
> > 
> > # ./watchdog.out
> > Bus error (core dumped)
> 
> > MOV DX, 2EH
> > MOV AL, 87H
> > OUT DX, AL
> > OUT DX, AL
> 
> Userland is not allowed to write to ports. That's the bus error you see. 
> Also without a call to the exit syscall at the end, it will segfault.
> 

See io(4), i386_get_ioperm(2), i386_set_ioperm(2), mem(4).

---
Gary Jennejohn
From won.derick at yahoo.com  Mon Dec  1 04:48:33 2008
From: won.derick at yahoo.com (Won De Erick)
Date: Mon Dec  1 04:48:39 2008
Subject: Watchdog for Boser (HS-7001)
References: <547602.79284.qm@web45809.mail.sp1.yahoo.com>
	<4933A29B.8060907@gmx.de> <20081201090421.GA99082@rink.nu>
	<611173.7111.qm@web45805.mail.sp1.yahoo.com>
	<4933AFD4.3070501@gmx.de> <86fxl8qf8i.fsf@ds4.des.no>
Message-ID: <576032.29521.qm@web45815.mail.sp1.yahoo.com>

> ----- Original Message ----

> From: Dag-Erling Sm?rgrav <des@des.no>
> Christoph Mallon <christoph.mallon@gmx.de> writes:
> > You're probably better of writing this in C.
maybe i get this as an option.
> 
> He's probably better off writing a watchdog(4) driver for the Boser (or
> getting someone to write one for him - not easy to do without hardware
> to test on, though)
> 
this is a great info. i am used to settings like the following when using ipmi-compliant platform.
#bmc-watchdog -s -a 1 -i 100    (#set timeout action to hard reset after a timeout of 100 seconds)
then daemonize to constantly reset the timer, and prevent the box from restarting.

I installed watchdog(/usr/ports/sysutils/watchdog) from ports, then noticed the following from the manual.
     watchdog [-d] [-t timeout]

# watchdog -d -t 50
Timeout is 2^36 nanoseconds
watchdog: patting the dog: Operation not supported

but I don't know how it is linked with watchdogd(8).

Little more explanation is appreciated, and/or an example.

> DES
> -- 
> Dag-Erling Sm?rgrav - des@des.no


      

From won.derick at yahoo.com  Mon Dec  1 04:52:44 2008
From: won.derick at yahoo.com (Won De Erick)
Date: Mon Dec  1 04:52:56 2008
Subject: Watchdog for Boser (HS-7001)
Message-ID: <838497.65099.qm@web45808.mail.sp1.yahoo.com>

>----- Original Message ----

>From: Christoph Mallon <christoph.mallon@gmx.de>
>
>
Won De Erick schrieb:
>>> ----- Original Message ----
>> 
>>> From: Rink Springer <rink@FreeBSD.org>
>>> 
>>> 
>> On Mon, Dec 01, 2008 at 09:38:51AM +0100, Christoph Mallon wrote:
>>>> Userland is not allowed to write to ports. That's the bus error you see. Also without a call to the exit syscall at the end, it will segfault.
>>> Note that you can write to ports from userland by opening /dev/io - if
>>> you have it opened, you can write to the ports.
>>> 
>> 
>> I've added the following at the end
>> 
>>   mov eax, 1 ; SYS_exit
>>   call doint
>> 
>>   doint:
>>      int 0x80
>>      ret
>> 
>> Besides, I can see the following at /dev
>> crw-------   1 root   wheel       0,  16 Nov 27 01:53 io
>> 
>> How should I make this open? do i need to %include this?
>
>You're probably better of writing this in C. Here is a wrapper for the out instruction:
>
>static inline outb(unsigned short port, unsigned char data)
>{
>  asm("outb %0, %1" : : "a" (data), "dN" (port));
>}
>
>As Rink mentioned, you have to open /dev/io. The process must have super-user privileges, see io(4).

will this be ok?

int fd = open("/dev/fido", O_RDWR);


>
>Regards
>    Christoph



      

From won.derick at yahoo.com  Mon Dec  1 05:07:39 2008
From: won.derick at yahoo.com (Won De Erick)
Date: Mon Dec  1 05:07:45 2008
Subject: Watchdog for Boser (HS-7001)
Message-ID: <839504.20277.qm@web45816.mail.sp1.yahoo.com>

>From: Won De Erick <won.derick@yahoo.com>

>>From: Christoph Mallon <christoph.mallon@gmx.de>
>>
>
>Won De Erick schrieb:
>>>> ----- Original Message ----
>>> 
>>>> From: Rink Springer <rink@FreeBSD.org>
>>>> 
>>>> 
>>> On Mon, Dec 01, 2008 at 09:38:51AM +0100, Christoph Mallon wrote:
>>>>> Userland is not allowed to write to ports. That's the bus error you see. Also without a call to the exit syscall at the end, it will segfault.
>>>> Note that you can write to ports from userland by opening /dev/io - if
>>>> you have it opened, you can write to the ports.
>>>> 
>>> 
>>> I've added the following at the end
>>> 
>>>   mov eax, 1 ; SYS_exit
>>>   call doint
>>> 
>>>   doint:
>>>      int 0x80
>>>      ret
>>> 
>>> Besides, I can see the following at /dev
>>> crw-------   1 root   wheel       0,  16 Nov 27 01:53 io
>>> 
>>> How should I make this open? do i need to %include this?
>>
>>You're probably better of writing this in C. Here is a wrapper for the out instruction:
>>
>>static inline outb(unsigned short port, unsigned char data)
>>{
>>  asm("outb %0, %1" : : "a" (data), "dN" (port));
>>}
>>
>>As Rink mentioned, you have to open /dev/io. The process must have super-user privileges, see io(4).
>
>will this be ok?
>int fd = open("/dev/fido", O_RDWR);
>
aww.. i mean int sio = open("/dev/io", O_RDWR);
>
>>
>>Regards
>>    Christoph


      

From des at des.no  Mon Dec  1 05:32:28 2008
From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=)
Date: Mon Dec  1 05:32:36 2008
Subject: Watchdog for Boser (HS-7001)
In-Reply-To: <576032.29521.qm@web45815.mail.sp1.yahoo.com> (Won De Erick's
	message of "Mon, 1 Dec 2008 04:48:31 -0800 (PST)")
References: <547602.79284.qm@web45809.mail.sp1.yahoo.com>
	<4933A29B.8060907@gmx.de> <20081201090421.GA99082@rink.nu>
	<611173.7111.qm@web45805.mail.sp1.yahoo.com> <4933AFD4.3070501@gmx.de>
	<86fxl8qf8i.fsf@ds4.des.no>
	<576032.29521.qm@web45815.mail.sp1.yahoo.com>
Message-ID: <867i6kqavq.fsf@ds4.des.no>

Won De Erick <won.derick@yahoo.com> writes:
> this is a great info. i am used to settings like the following when using ipmi-compliant platform.
> #bmc-watchdog -s -a 1 -i 100    (#set timeout action to hard reset after a timeout of 100 seconds)
> then daemonize to constantly reset the timer, and prevent the box from restarting.
>
> I installed watchdog(/usr/ports/sysutils/watchdog) from ports,

Firt of all, that port won't help you; it only supports the AMD Elan
SoC.  Second, we've had kernel support for the Elan watchdog longer than
the port has existed.

> then noticed the following from the manual.
>      watchdog [-d] [-t timeout]

That's the base system watchdog(8); the port installs a watchdogd(8)
that works *only* for Elan chips.

There is a watchdogd(8) in the base system as well.

> # watchdog -d -t 50
> Timeout is 2^36 nanoseconds
> watchdog: patting the dog: Operation not supported

You need to load the appropriate watchdog driver first - and as far as I
know, we don't have one for the Boser HS-7001.

> but I don't know how it is linked with watchdogd(8).
>
> Little more explanation is appreciated, and/or an example.

man -k watchdog

DES
-- 
Dag-Erling Sm?rgrav - des@des.no
From marinosi at ceid.upatras.gr  Mon Dec  1 05:57:35 2008
From: marinosi at ceid.upatras.gr (Ilias Marinos)
Date: Mon Dec  1 05:58:00 2008
Subject: TPM Device Driver - FreeBSD
Message-ID: <20081201133333.GA6445@marinos.ceid.upatras.gr>


Hello list,

  We are two undergraduate students studying computer engineering and
informatics at Patra's University, Greece. We are currently working on
our diploma thesis which is about developing a driver for the TPM
(Trusted Platform Module) for FreeBSD.We think that TPM can enhance
security in FreeBSD and could be a great addition to the TrustedBSD
project.

  We are still in the begining of the project and since this is our first
effort in implementing a device driver we are trying to gather and read
all available documentation on the subject first. However, we were
unable to find a source of information related to how the BSD kernel and
device communication is implemented and we would greatly appreciate it
if you could point us one; either in form of a book or an
article/tutorial.

  Last but not least, we'd like to make clear that we are oppossed to any
DRM-related use of this device, however we believe that the TPM can be
used in security or cryptographic applications.

Thanks in advance for your time.

Best Regards,
Marinos Ilias <marinosi@ceid.upatras.gr>
Mellos Seraphim <mellos@ceid.upatras.gr>


--
echo "Sysadmin know better bash than english." | sed s/min/mins/ \
| sed 's/better bash/bash better/'
From tevans.uk at googlemail.com  Mon Dec  1 06:55:22 2008
From: tevans.uk at googlemail.com (Tom Evans)
Date: Mon Dec  1 06:55:29 2008
Subject: TPM Device Driver - FreeBSD
In-Reply-To: <20081201133333.GA6445@marinos.ceid.upatras.gr>
References: <20081201133333.GA6445@marinos.ceid.upatras.gr>
Message-ID: <1228141469.4196.20.camel@localhost>

On Mon, 2008-12-01 at 15:33 +0200, Ilias Marinos wrote:
> Hello list,
> 
>   We are two undergraduate students studying computer engineering and
> informatics at Patra's University, Greece. We are currently working on
> our diploma thesis which is about developing a driver for the TPM
> (Trusted Platform Module) for FreeBSD.We think that TPM can enhance
> security in FreeBSD and could be a great addition to the TrustedBSD
> project.
> 
>   We are still in the begining of the project and since this is our first
> effort in implementing a device driver we are trying to gather and read
> all available documentation on the subject first. However, we were
> unable to find a source of information related to how the BSD kernel and
> device communication is implemented and we would greatly appreciate it
> if you could point us one; either in form of a book or an
> article/tutorial.
> 
>   Last but not least, we'd like to make clear that we are oppossed to any
> DRM-related use of this device, however we believe that the TPM can be
> used in security or cryptographic applications.
> 
> Thanks in advance for your time.
> 
> Best Regards,
> Marinos Ilias <marinosi@ceid.upatras.gr>
> Mellos Seraphim <mellos@ceid.upatras.gr>
> 
> 
> --
> echo "Sysadmin know better bash than english." | sed s/min/mins/ \
> | sed 's/better bash/bash better/'

This book[1] is very good, well worth a read. Not totally upto date, but
reasonabley so.

Cheers

Tom

[1]
http://www.amazon.com/Design-Implementation-FreeBSD-Operating-System/dp/0201702452

From kabaev at gmail.com  Mon Dec  1 07:32:51 2008
From: kabaev at gmail.com (Alexander Kabaev)
Date: Mon Dec  1 07:32:57 2008
Subject: remapping kernel buffer in VMS of user process
In-Reply-To: <20081201013851.GA20549@debian.samsung.router>
References: <20081201013851.GA20549@debian.samsung.router>
Message-ID: <20081201101232.42d55473@kan.dnsalias.net>

On Mon, 1 Dec 2008 02:38:51 +0100
Alexej Sokolov <bsd.quest@googlemail.com> wrote:

> Hello, 
> 
> I would like to remap some buffers allocated in kernel space to memory
> space of certain process. 
> 
The simplest way is to expose this buffer through device pager.
Implement the driver callback and let userland to simply mmap the page.

-- 
Alexander Kabaev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20081201/ae1da3ac/signature.pgp
From des at des.no  Mon Dec  1 07:55:01 2008
From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=)
Date: Mon Dec  1 07:55:09 2008
Subject: Watchdog for Boser (HS-7001)
In-Reply-To: <867i6kqavq.fsf@ds4.des.no> ("Dag-Erling =?utf-8?Q?Sm=C3=B8rg?=
	=?utf-8?Q?rav=22's?= message of "Mon, 01 Dec 2008 14:32:25 +0100")
References: <547602.79284.qm@web45809.mail.sp1.yahoo.com>
	<4933A29B.8060907@gmx.de> <20081201090421.GA99082@rink.nu>
	<611173.7111.qm@web45805.mail.sp1.yahoo.com> <4933AFD4.3070501@gmx.de>
	<86fxl8qf8i.fsf@ds4.des.no>
	<576032.29521.qm@web45815.mail.sp1.yahoo.com>
	<867i6kqavq.fsf@ds4.des.no>
Message-ID: <86myffq4a4.fsf@ds4.des.no>

Dag-Erling Sm?rgrav <des@des.no> writes:
> You need to load the appropriate watchdog driver first - and as far as I
> know, we don't have one for the Boser HS-7001.

I can't find the 7001 on Boser's web site, but their other SBCs seem to
be ICH-based; try 'kldload ichwd'.

DES
-- 
Dag-Erling Sm?rgrav - des@des.no
From bsd.quest at googlemail.com  Mon Dec  1 08:34:28 2008
From: bsd.quest at googlemail.com (Alexej Sokolov)
Date: Mon Dec  1 08:34:34 2008
Subject: remapping kernel buffer in VMS of user process
In-Reply-To: <20081201101232.42d55473@kan.dnsalias.net>
References: <20081201013851.GA20549@debian.samsung.router>
	<20081201101232.42d55473@kan.dnsalias.net>
Message-ID: <20081201163354.GA5282@debian.samsung.router>

On Mon, Dec 01, 2008 at 10:12:09AM -0500, Alexander Kabaev wrote:
> On Mon, 1 Dec 2008 02:38:51 +0100
> Alexej Sokolov <bsd.quest@googlemail.com> wrote:
> 
> > Hello, 
> > 
> > I would like to remap some buffers allocated in kernel space to memory
> > space of certain process. 
> > 
> The simplest way is to expose this buffer through device pager.
> Implement the driver callback and let userland to simply mmap the page.
> 
Sorry, but I don't understand how to do it. I know how to implement mmap
through character device. But I am working with network driver. Network
devices doesn't appear in file system and they don't have any interface
for mmaping. 

I think I can try to solve with task with: 
vm_map_lookup - to get a vm_object of allocated space and then 
vm_map_find (map_of_process, ... founded_object ...) - allocate a new
space in the vms of process. 

I try to do it now with a small hope of success :-)


> -- 
> Alexander Kabaev



-- 
Alexej Sokolov <bsd.quest@googlemail.com>
From ancelgray at yahoo.com  Mon Dec  1 07:58:15 2008
From: ancelgray at yahoo.com (ancelgray)
Date: Mon Dec  1 08:59:03 2008
Subject: Hardware support for AMD Geode CS5536 audio?
In-Reply-To: <20081130232851.GA1214@casibsd.svkt.org>
References: <20080121170155.GC51116@hamlet.SetFilePointer.com>
	<20713056.post@talk.nabble.com>
	<20081130232851.GA1214@casibsd.svkt.org>
Message-ID: <20774487.post@talk.nabble.com>


Lionel,

This is Andrew Gray.  Thanx for testing. 
Does the command

cat sound.raw > /dev/dsp

output the sound of my voice out of
one of the speakers?

Does it also give the bus master error message?

Thanx
Andrew Gray













Lionel Flandrin wrote:
> 
> On Wed, Nov 26, 2008 at 07:30:41PM -0800, ancelgray wrote:
>> 
>> To AMD CS5536 users:
>> 
>> This is Andrew Gray.  I have finished the audio driver for the AMD CS5536
>> companion
>> chip. It is working on a  PC Engines Alix 1C low power board under
>> FreeBSD
>> 7.0.  
>> It can be found at:
>> 
>> http://modelofreality.org/snd_amd5536.html
>> 
>> Let me know how it goes.
> 
>   I own a fitpc[1] that runs an AMD Geode CPU with the AMD CS5536
> chip. I followed the README (kldloaded the module, ran the two sysctl)
> and everything seemed to work fine:
>  - As soon as I loaded the module I got (in the system messages):
> pcm0: <AMD CS5536> port 0xd400-0xd47f irq 10 at device 15.3 on pci0
> pcm0: [ITHREAD]
> pcm0: <Wolfson WM9711/12 AC97 Codec>
> 
>  - cat /dev/sndstat says:
> FreeBSD Audio Driver (newpcm: 32bit 2007061600/i386)
> Installed devices:
> pcm0: <AMD CS5536> at io 0xd400 irq 10 kld snd_cs5536 [MPSAFE] \
> (2p:0v/1r:0v channels duplex default)
> 
>   However if I try to play something with mpg123 I get no sound and
> "pcm0: bm0 bus master error" every half second or so in the system
> messages.
> 
> Please tell me if there's anything else I can provide to help you.
> 
> [1] http://www.fit-pc.com/new/fit-pc-1-0-specifications.html
> 
> Cheers,
> -- 
> Lionel Flandrin
> _______________________________________________
> freebsd-hackers@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
> 
> 

-- 
View this message in context: http://www.nabble.com/Hardware-support-for-AMD-Geode-CS5536-audio--tp15002428p20774487.html
Sent from the freebsd-hackers mailing list archive at Nabble.com.

From keramida at ceid.upatras.gr  Mon Dec  1 09:21:22 2008
From: keramida at ceid.upatras.gr (Giorgos Keramidas)
Date: Mon Dec  1 09:21:29 2008
Subject: keeping track of local modifications
In-Reply-To: <gFpinjQW6hEatbsT+XzE0kSsZf0@kjaK+/sQ5DW5981v71UogZJPf/0> (Eygene
	Ryabinkin's message of "Mon, 1 Dec 2008 11:23:40 +0300")
References: <4931CB02.9070904@gmail.com> <4932E8CF.9040501@freebsd.org>
	<49337f04.p8QqvfzTga07ypa6%perryh@pluto.rain.com>
	<200812010830.17259.max@love2party.net>
	<gFpinjQW6hEatbsT+XzE0kSsZf0@kjaK+/sQ5DW5981v71UogZJPf/0>
Message-ID: <874p1nlslc.fsf@kobe.laptop>

On Mon, 1 Dec 2008 11:23:40 +0300, Eygene Ryabinkin <rea-fbsd@codelabs.ru> wrote:
> May be I am missing something, but what's wrong with the patches from
> other VCS, providing that with Subversion you can exchange only by the
> plain diffs?  Yes, Git/Mercurial patches should be applied with 'patch
> -p1', but that's all.  Subversion has no notion simular to 'git
> format-patch' and 'git am', if I am not messing the things up, so the
> only way to exchange with others are the patches themselves.

Conflicts...

Git and Mercurial cannot import Subversion $FreeBSD$ lines so far, and
you may end up submitting patches that include unexpanded forms of the
"$FreeBSD: xxxx $" text.  These will fail to apply if they same patch
touches nearby lines.

I like Mercurial myself, but it's some times a pain to refresh patches
that touch lines near "$FreeBSD$".

> The only issue I do see is about '$FreeBSD$', but plain Subversion
> clients shouldn't mess with it.

Bingo :)

From rea-fbsd at codelabs.ru  Mon Dec  1 11:56:06 2008
From: rea-fbsd at codelabs.ru (Eygene Ryabinkin)
Date: Mon Dec  1 11:56:12 2008
Subject: keeping track of local modifications
In-Reply-To: <874p1nlslc.fsf@kobe.laptop>
References: <4931CB02.9070904@gmail.com> <4932E8CF.9040501@freebsd.org>
	<49337f04.p8QqvfzTga07ypa6%perryh@pluto.rain.com>
	<200812010830.17259.max@love2party.net>
	<gFpinjQW6hEatbsT+XzE0kSsZf0@kjaK+/sQ5DW5981v71UogZJPf/0>
	<874p1nlslc.fsf@kobe.laptop>
Message-ID: <8S1yocfZ0YutMO/GCIC1bN8RXQ0@kjaK+/sQ5DW5981v71UogZJPf/0>

Giorgos, good day.

Mon, Dec 01, 2008 at 07:21:03PM +0200, Giorgos Keramidas wrote:
> On Mon, 1 Dec 2008 11:23:40 +0300, Eygene Ryabinkin <rea-fbsd@codelabs.ru> wrote:
> > May be I am missing something, but what's wrong with the patches from
> > other VCS, providing that with Subversion you can exchange only by the
> > plain diffs?  Yes, Git/Mercurial patches should be applied with 'patch
> > -p1', but that's all.  Subversion has no notion simular to 'git
> > format-patch' and 'git am', if I am not messing the things up, so the
> > only way to exchange with others are the patches themselves.
> 
> Conflicts...
> 
> Git and Mercurial cannot import Subversion $FreeBSD$ lines so far, and
> you may end up submitting patches that include unexpanded forms of the
> "$FreeBSD: xxxx $" text.  These will fail to apply if they same patch
> touches nearby lines.

Ahm, yes.  "sed -e's|$FreeBSD: [^$]* \$|$FreeBSD$|g'" should help
in this case.

Thanks for clarification!
-- 
Eygene
 _                ___       _.--.   #
 \`.|\..----...-'`   `-._.-'_.-'`   #  Remember that it is hard
 /  ' `         ,       __.--'      #  to read the on-line manual   
 )/' _/     \   `-_,   /            #  while single-stepping the kernel.
 `-'" `"\_  ,_.-;_.-\_ ',  fsc/as   #
     _.-'_./   {_.'   ; /           #    -- FreeBSD Developers handbook 
    {_.-``-'         {_/            #
-------------- 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-hackers/attachments/20081201/643ef668/attachment.pgp
From keramida at freebsd.org  Mon Dec  1 14:16:28 2008
From: keramida at freebsd.org (Giorgos Keramidas)
Date: Mon Dec  1 14:16:36 2008
Subject: keeping track of local modifications
In-Reply-To: <8S1yocfZ0YutMO/GCIC1bN8RXQ0@kjaK+/sQ5DW5981v71UogZJPf/0> (Eygene
	Ryabinkin's message of "Mon, 1 Dec 2008 22:56:02 +0300")
References: <4931CB02.9070904@gmail.com> <4932E8CF.9040501@freebsd.org>
	<49337f04.p8QqvfzTga07ypa6%perryh@pluto.rain.com>
	<200812010830.17259.max@love2party.net>
	<gFpinjQW6hEatbsT+XzE0kSsZf0@kjaK+/sQ5DW5981v71UogZJPf/0>
	<874p1nlslc.fsf@kobe.laptop>
	<8S1yocfZ0YutMO/GCIC1bN8RXQ0@kjaK+/sQ5DW5981v71UogZJPf/0>
Message-ID: <87prkbk0d3.fsf@kobe.laptop>

On Mon, 1 Dec 2008 22:56:02 +0300, Eygene Ryabinkin <rea-fbsd@codelabs.ru> wrote:
> Giorgos, good day.

Hi Eygene, thanks.  The same to you too :)

>> Git and Mercurial cannot import Subversion $FreeBSD$ lines so far,
>> and you may end up submitting patches that include unexpanded forms
>> of the "$FreeBSD: xxxx $" text.  These will fail to apply if they
>> same patch touches nearby lines.
>
> Ahm, yes.  "sed -e's|$FreeBSD: [^$]* \$|$FreeBSD$|g'" should help in
> this case.
>
> Thanks for clarification!

Having said that, I have been using a patched version of the `crew'
branch of Mercurial, for local FreeBSD work.

I didn't want to convert the *full* history of the /head branch from
Subversion, so I started by converting only the changes of 2008, using a
local Subversion mirror for speed.  The `convert' extension of Hg can
pull changesets from Subversion, using the py-subversion bindings.

An initial conversion of all the 2008 commits of the /head branch was
bootstrapped with:

    % mkdir -p /hg/bsd
    % cd /hg/bsd
    % hg convert --config convert.svn.startrev='175021' \
            --config convert.svn.trunk='head' \
            --config convert.svn.branches='' \
            --config convert.svn.tags='' \
            file:///home/svn/base/ head

After running for a while, this produced `/hg/bsd/head/.hg' which takes
about 200 MB of space now, and it includes 6600+ changesets so far:

    % hg -R /hg/bsd/head tip
    changeset:   6603:bfec3e11214e
    branch:      head
    tag:         tip
    user:        jasone
    date:        Mon Dec 01 10:20:59 2008 +0000
    summary:     Fix a lock order reversal bug that could cause deadlock during fork(2).

    %

Rerunning the same command can incrementally pull only the new changes
from Subversion, and it is fast enough that I saved it to a shell script
called `/hg/bsd/pull-head.sh' and I run it from time to time, whenever I
want to resync with 8.0-CURRENT:

    % pwd
    /hg/bsd
    % \time ./pull-head.sh
    scanning source...
    sorting...
    converting...
    10 Adjustments to make a tags file a bit more suitable to amd64.
    9 Fix fread() to return a correct value on platforms where sizeof(int) !=
    8 Catch up with the disappearance of sys/dev/hfa.
    7 Trivial patch to show on which geom has the error been detected.
    6 The times(3) function returns the number of CLK_TCKs since the
    5 import ath hal
    4 Switch to ath hal source code. Note this removes the ath_hal
    3 Fix typo.
    2 Add controller suspend/resume support.
    1 Invoke _rtld_atfork_post earlier, before we reinitialize rtld locks
    0 Add ixgbe(4) and upgt(4).
           12.06 real         3.52 user         1.42 sys
    %

It's nice to be able to use local-only operation for merging some of the
patches I have to test, so it may be useful to anyone who wants to keep
doing local FreeBSD work with Hg.  In particular, it's nice to be able
to look at the local diffs very very fast.  Once the filesystem cache is
"warmed" with the .hg/ contents of one workspace, I like being able to
see stuff like:

    % \time hg diff -r bfec3e11214e:tip > /dev/null
            1.81 real         1.30 user         0.41 sys
    %

I'll try to write to the Wiki how I keep a few local patches around,
using a clone of the converted source tree.

From bsd.quest at googlemail.com  Mon Dec  1 14:20:20 2008
From: bsd.quest at googlemail.com (Alexej Sokolov)
Date: Mon Dec  1 14:20:28 2008
Subject: getting vm_object from allocated memory in kernel
Message-ID: <671bb5fc0812011420o6f20d8a0j691e4650aca2733f@mail.gmail.com>

Hello,
I try to allocate a memory in the system call and then I would like to get
vm_object
of allocated space to remap it later:

/* Syscall func */
static int
syscf(struct thread *td, void *sa)
{
...
        vm_offset_t addr;
...
        MALLOC(addr, vm_offset_t, PAGE_SIZE, M_DEVBUF, M_WAITOK | M_ZERO);

/* Then I try to get vm_obj */
        vm_map_lookup(&kernel_map, addr, VM_PROT_ALL,
                        &myentry, &myobject, &mypindex, &myprot, &mywired);
/* OUT */
        vm_map_lookup_done(&kernel_map, myentry);

/* If i try to make system call it work successful but after a few seconds
happens
    kernel panic */

...
}

could anyone give me a tip what I do wrong ?

# kgdb kernel.debug
vmcore.10
/home/alexandre/alexandre-da/misc/crash
kgdb: kvm_nlist(_stopped_cpus):
kgdb: kvm_nlist(_stoppcbs):
[GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so:
Undefined symbol "ps_pglobal_lookup"]
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   = 0x14
fault code              = supervisor read, page not present
instruction pointer     = 0x20:0xc0589028
stack pointer           = 0x28:0xe7a83758
frame pointer           = 0x28:0xe7a83774
code segment            = base 0x0, limit 0xfffff, type 0x1b
                        = DPL 0, pres 1, def32 1, gran 1
processor eflags        = resume, IOPL = 0
current process         = 792 (zsh)
panic: from debugger
Uptime: 20m59s
Physical memory: 2034 MB
Dumping 73 MB: 58 42 26 10

#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  0xc0558c03 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409
#2  0xc0558e2c in panic (fmt=Variable "fmt" is not available.
) at /usr/src/sys/kern/kern_shutdown.c:563
#3  0xc0457927 in db_panic (addr=Could not find the frame base for
"db_panic".
) at /usr/src/sys/ddb/db_command.c:433
#4  0xc0458085 in db_command_loop () at /usr/src/sys/ddb/db_command.c:401
#5  0xc0459ab5 in db_trap (type=12, code=0) at
/usr/src/sys/ddb/db_main.c:222
#6  0xc057ed84 in kdb_trap (type=12, code=0, tf=0xe7a83718) at
/usr/src/sys/kern/subr_kdb.c:502
#7  0xc06b3edf in trap_fatal (frame=0xe7a83718, eva=20) at
/usr/src/sys/i386/i386/trap.c:890
#8  0xc06b489a in trap (frame=0xe7a83718) at
/usr/src/sys/i386/i386/trap.c:280
#9  0xc069dacb in calltrap () at /usr/src/sys/i386/i386/exception.s:139
#10 0xc0589028 in propagate_priority (td=0xc5963210) at
/usr/src/sys/kern/subr_turnstile.c:272
#11 0xc05899a9 in turnstile_wait (ts=0xc5083870, owner=0xc5963210,
queue=Variable "queue" is not available.
) at /usr/src/sys/kern/subr_turnstile.c:739
#12 0xc054cdbd in _mtx_lock_sleep (m=0xc14540e8, tid=3312898576, opts=0,
file=0x0, line=0) at /usr/src/sys/kern/kern_mutex.c:416
#13 0xc054d141 in _mtx_lock_flags (m=0xc14540e8, opts=0, file=0x0, line=0)
at /usr/src/sys/kern/kern_mutex.c:186
#14 0xc066c234 in _vm_map_lock (map=0xc145408c, file=0x0, line=0) at
/usr/src/sys/vm/vm_map.c:449
#15 0xc0669e4a in kmem_malloc (map=0xc145408c, size=4096, flags=259) at
/usr/src/sys/vm/vm_kern.c:296
#16 0xc0660a77 in page_alloc (zone=0xc1445780, bytes=4096, pflag=0xe7a8388f
"\002\200\207D?\003", wait=259) at /usr/src/sys/vm/uma_core.c:955
#17 0xc065fb3c in slab_zalloc (zone=0xc1445780, wait=259) at
/usr/src/sys/vm/uma_core.c:820
#18 0xc0660014 in uma_zone_slab (zone=0xc1445780, flags=3) at
/usr/src/sys/vm/uma_core.c:2010
#19 0xc0663286 in uma_zalloc_arg (zone=0xc1445780, udata=0x0, flags=3) at
/usr/src/sys/vm/uma_core.c:2111
#20 0xc05bf62f in cache_enter (dvp=0xc5724770, vp=0x0, cnp=0xe7a83bd0) at
uma.h:277
#21 0xc06521d8 in ufs_lookup (ap=0xe7a83a00) at
/usr/src/sys/ufs/ufs/ufs_lookup.c:446
#22 0xc06c9ee2 in VOP_CACHEDLOOKUP_APV (vop=0xc073a180, a=0xe7a83a00) at
vnode_if.c:153
#23 0xc05bffa0 in vfs_cache_lookup (ap=0xe7a83a84) at vnode_if.h:83
#24 0xc06cbb26 in VOP_LOOKUP_APV (vop=0xc073a6a0, a=0xe7a83a84) at
vnode_if.c:99
#25 0xc05c64c1 in lookup (ndp=0xe7a83ba8) at vnode_if.h:57
#26 0xc05c7118 in namei (ndp=0xe7a83ba8) at
/usr/src/sys/kern/vfs_lookup.c:219
#27 0xc05d4b5d in kern_stat (td=0xc576d210, path=0xbfbe5238 <Address
0xbfbe5238 out of bounds>, pathseg=UIO_USERSPACE, sbp=0xe7a83c18)
    at /usr/src/sys/kern/vfs_syscalls.c:2109
#28 0xc05d4d0f in stat (td=0xc576d210, uap=0xe7a83cfc) at
/usr/src/sys/kern/vfs_syscalls.c:2093
#29 0xc06b44b7 in syscall (frame=0xe7a83d38) at
/usr/src/sys/i386/i386/trap.c:1035
#30 0xc069db30 in Xint0x80_syscall () at
/usr/src/sys/i386/i386/exception.s:196
#31 0x00000033 in ?? ()
Previous frame inner to this frame (corrupt stack?)
From eitanadlerlist at gmail.com  Mon Dec  1 17:19:11 2008
From: eitanadlerlist at gmail.com (Eitan Adler)
Date: Mon Dec  1 17:19:18 2008
Subject: change to ee.c
In-Reply-To: <20081201083604.545172dag60hadc0@webmail.leidinger.net>
References: <49320FF7.4040901@gmail.com>
	<4932122A.8070209@delphij.net>	<493214DC.2080904@gmail.com>
	<20081130004331.086941f3@tau>	<49329F4A.3070004@gmail.com>
	<20081130103156.6e4da70c@tau>
	<20081201083604.545172dag60hadc0@webmail.leidinger.net>
Message-ID: <49348D00.1040406@gmail.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Alexander Leidinger wrote:
 > It _may_ be more easy to find out which version is in our source tree,
> and make a diff between the original vendor version and what we have.
> Depending on the amount of changes there, this is faster than to real
> all the version control logs to determine if there's a difference or
> not. In the end you have to read some logs too, but only those, which
> change lines which a different from those of the vendor version (e.g.
> via the annotated view at cvsweb.freebsd.org).
I think I'm going to work on diff from current vendor release to ours
and see what happens.

- --
Eitan Adler
GNU Key fingerptrint: 2E13 BC16 5F54 0FBD 62ED 42B6 B65F 24AB E9C2 CCD1
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (FreeBSD)

iEYEARECAAYFAkk0jP8ACgkQtl8kq+nCzNHFvgCfcs7/au6FohllKbVTmMHjttn1
178Aniek69WKfyOHyh7woO9sDeBwNLMU
=ds5J
-----END PGP SIGNATURE-----
From perryh at pluto.rain.com  Mon Dec  1 19:36:33 2008
From: perryh at pluto.rain.com (perryh@pluto.rain.com)
Date: Mon Dec  1 19:36:40 2008
Subject: How to build kernel module spread on subdirectories?
In-Reply-To: <200812011231.52262.fbsd.hackers@rachie.is-a-geek.net>
References: <711D7381-D852-4B6B-991A-84BA6DEFB679@gmail.com>
	<49332E5C.9020303@freebsd.org>
	<D6756955-6E0B-429A-9216-2CF223D503D7@gmail.com>
	<200812011231.52262.fbsd.hackers@rachie.is-a-geek.net>
Message-ID: <4934a886.x0zd2wiIrFlfIq2T%perryh@pluto.rain.com>

> As you discovered, includes are done before targets. You would
> need seperate invocations of make, to generate the file and get
> it included.

<heresy> Provided the module in question is contemplated for delivery
as a port, rather than as part of the base -- so that having a build
dependency on a port is tolerable -- perhaps it would be more easily
built using devel/gmake? </heresy>
From perryh at pluto.rain.com  Mon Dec  1 21:13:08 2008
From: perryh at pluto.rain.com (perryh@pluto.rain.com)
Date: Mon Dec  1 21:13:14 2008
Subject: keeping track of local modifications
In-Reply-To: <8S1yocfZ0YutMO/GCIC1bN8RXQ0@kjaK+/sQ5DW5981v71UogZJPf/0>
References: <4931CB02.9070904@gmail.com> <4932E8CF.9040501@freebsd.org>
	<49337f04.p8QqvfzTga07ypa6%perryh@pluto.rain.com>
	<200812010830.17259.max@love2party.net>
	<gFpinjQW6hEatbsT+XzE0kSsZf0@kjaK+/sQ5DW5981v71UogZJPf/0>
	<874p1nlslc.fsf@kobe.laptop>
	<8S1yocfZ0YutMO/GCIC1bN8RXQ0@kjaK+/sQ5DW5981v71UogZJPf/0>
Message-ID: <4934c2c9./+HbbGwhphjtaXAT%perryh@pluto.rain.com>

> > Git and Mercurial cannot import Subversion $FreeBSD$ lines
> > so far, and you may end up submitting patches that include
> > unexpanded forms of the "$FreeBSD: xxxx $" text.  These will
> > fail to apply if they same patch touches nearby lines.
>
> Ahm, yes.  "sed -e's|$FreeBSD: [^$]* \$|$FreeBSD$|g'" should help
> in this case.

Not sure I understand what is meant by "unexpanded" here, since
it looks as if this sed example would convert an "expanded" form
-- containing the version info -- to an "unexpanded" one that
merely shows where that info should go.

Perhaps it's my ClearCase background showing through, but I'd think
it highly desirable for a patch to include what I think of as the
expanded tag line -- including the version info, as it appears in
the distributed files under /usr/src -- thereby explicitly showing
the version on which the patch is based (the "base contributor"
in ClearCase-speak).  This should greatly simplify merging in the
(likely) event that other development has occurred on the same file
in the meantime -- provided one is using a 3-way merge tool that
understands such things.
From ancelgray at yahoo.com  Mon Dec  1 22:46:25 2008
From: ancelgray at yahoo.com (ancelgray)
Date: Mon Dec  1 23:01:07 2008
Subject: Hardware support for AMD Geode CS5536 audio?
In-Reply-To: <e71790db0811280333g35dd9f5aqe4d78ef0f70511a9@mail.gmail.com>
References: <20080121170155.GC51116@hamlet.SetFilePointer.com>
	<20713056.post@talk.nabble.com>
	<e71790db0811280333g35dd9f5aqe4d78ef0f70511a9@mail.gmail.com>
Message-ID: <20786956.post@talk.nabble.com>


Lionel replies:


Hi Andrew, thank you for your quick reply.


"cat count.raw > /dev/dsp" does indeed work without any message in the
syslog.

If I try to cat /dev/urandom > /dev/dsp I get a very thin white-ish
noise and still no message. (I set all levels to 100 with mixer(8))

This is rather encouraging, I hope it helps.

By the way, I forgot to put the version I'm running in my last
email:
# uname -a
FreeBSD home.svkt.org 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #1: Sat \
Nov 1 23:24:38 CET 2008 \
simias@casibsd:/home/simias/build-fitpc/obj/i386/usr/src/sys/FITPC-CONF \
i386

Tell me if I can try something else or if you want me to provide you
more details about my system. I'm using a heavily trimmed down kernel
configuration so maybe I inadvertently disabled something mpg123
needs.

Lionell,

OK, this is indeed encouraging.  Perhaps my default block size of 256 bytes
is too small for the 
44 Khz audio.  I did not test the driver with mpg123.  I am using Linphone
with just
mono 8 Khz audio.  The 256 byte block size works fine for me.

I will install the mpg123 package soon and see what's up.

Thanx again for testing.

Andrew Gray
-- 
View this message in context: http://www.nabble.com/Hardware-support-for-AMD-Geode-CS5536-audio--tp15002428p20786956.html
Sent from the freebsd-hackers mailing list archive at Nabble.com.

From rea-fbsd at codelabs.ru  Mon Dec  1 23:45:01 2008
From: rea-fbsd at codelabs.ru (Eygene Ryabinkin)
Date: Mon Dec  1 23:45:10 2008
Subject: keeping track of local modifications
In-Reply-To: <4934c2c9./+HbbGwhphjtaXAT%perryh@pluto.rain.com>
References: <4931CB02.9070904@gmail.com> <4932E8CF.9040501@freebsd.org>
	<49337f04.p8QqvfzTga07ypa6%perryh@pluto.rain.com>
	<200812010830.17259.max@love2party.net>
	<gFpinjQW6hEatbsT+XzE0kSsZf0@kjaK+/sQ5DW5981v71UogZJPf/0>
	<874p1nlslc.fsf@kobe.laptop>
	<8S1yocfZ0YutMO/GCIC1bN8RXQ0@kjaK+/sQ5DW5981v71UogZJPf/0>
	<4934c2c9./+HbbGwhphjtaXAT%perryh@pluto.rain.com>
Message-ID: <oXnJun8c8OjxYDoPVy/fflpCqp4@1sSz4QqKMwRgwtJOiEEAoKyoIV0>

Perry, good day.

Mon, Dec 01, 2008 at 09:08:25PM -0800, perryh@pluto.rain.com wrote:
> > > Git and Mercurial cannot import Subversion $FreeBSD$ lines
> > > so far, and you may end up submitting patches that include
> > > unexpanded forms of the "$FreeBSD: xxxx $" text.  These will
> > > fail to apply if they same patch touches nearby lines.
> >
> > Ahm, yes.  "sed -e's|$FreeBSD: [^$]* \$|$FreeBSD$|g'" should help
> > in this case.
> 
> Not sure I understand what is meant by "unexpanded" here, since
> it looks as if this sed example would convert an "expanded" form
> -- containing the version info -- to an "unexpanded" one that
> merely shows where that info should go.

If you'll look at the diffs that are provided by Subversion, you'll
see that '$Id$' tags at the diff are shrinked to the '$Id' if keyword
expansion is enabled.  For example,
-----
Index: ChangeLog
===================================================================
--- ChangeLog   (revision 40)
+++ ChangeLog   (working copy)
@@ -1,4 +1,5 @@
 $Id$
+add

 Current version:
  - Added CRL check for all certificates in chain during S/MIME
-----
while original ChangeLog reads
-----
$Id: ChangeLog 35 2008-04-11 10:02:37Z root $
add

Current version:
 - Added CRL check for all certificates in chain during S/MIME
   verification.
-----

The above sed command will normalize $FreeBSD$ tags (de-expand them,
you're right that the wording was a bit ambigious).

But I was out of coffee yesterday, so I missed an important thing: such
diffs won't also apply, because you're really right: Subversion shrinks
'Id' (think 'FreeBSD') tags for diffs it is generating, but it has no
command 'svn patch' that will shrink these tags, apply the diff and
unshink them to the original form.  And this matters when you're
generating the diff against version N, but maintainer applies it to the
version N + m.  If I am correct, there is no simple automatic solution,
but special patching as described above will be needed.

Please, correct me if I am wrong.
-- 
Eygene
 _                ___       _.--.   #
 \`.|\..----...-'`   `-._.-'_.-'`   #  Remember that it is hard
 /  ' `         ,       __.--'      #  to read the on-line manual   
 )/' _/     \   `-_,   /            #  while single-stepping the kernel.
 `-'" `"\_  ,_.-;_.-\_ ',  fsc/as   #
     _.-'_./   {_.'   ; /           #    -- FreeBSD Developers handbook 
    {_.-``-'         {_/            #
-------------- 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-hackers/attachments/20081202/ba6d6e1f/attachment.pgp
From maslanbsd at gmail.com  Tue Dec  2 02:25:05 2008
From: maslanbsd at gmail.com (Maslan)
Date: Tue Dec  2 02:25:11 2008
Subject: Controlling a process
Message-ID: <319cceca0812020153y6cde7b0ara2cff1d1b0525e10@mail.gmail.com>

Hi guys,

What is the best way to control a process (running in chroot env):
1- Execution time
2- Memory limit
And to be able to kill the process when it breaks this limits.

Finally, i would like to know the exit status of the process or the
signal that killed it (sigfault, .....)

The idea is that I'm developing a problem judge that runs FreeBSD
(something like www.spoj.pl or topcoder.com/tc)
Where every problem has a run-time and a memory limit.

Thanks a lot


-- 
System Programmer
--
I'm Searching For Perfection,
So Even If U Need Portability U've To Use Assembly ;-)
--
http://libosdk.berlios.de
From rea-fbsd at codelabs.ru  Tue Dec  2 02:37:41 2008
From: rea-fbsd at codelabs.ru (Eygene Ryabinkin)
Date: Tue Dec  2 02:37:49 2008
Subject: Controlling a process
In-Reply-To: <319cceca0812020153y6cde7b0ara2cff1d1b0525e10@mail.gmail.com>
References: <319cceca0812020153y6cde7b0ara2cff1d1b0525e10@mail.gmail.com>
Message-ID: <j2Y/1ERA+pTg5cUUXFtkn4Voee8@qm7gbYKMPO53E/nl+D5eD8YyL1A>

Maslan, good day.

Tue, Dec 02, 2008 at 09:53:09AM +0000, Maslan wrote:
> What is the best way to control a process (running in chroot env):
> 1- Execution time
> 2- Memory limit
> And to be able to kill the process when it breaks this limits.

man 2 setrlimit

> Finally, i would like to know the exit status of the process or the
> signal that killed it (sigfault, .....)

If you're spawning the process in question, then 'man 2 wait'.
-- 
Eygene
 _                ___       _.--.   #
 \`.|\..----...-'`   `-._.-'_.-'`   #  Remember that it is hard
 /  ' `         ,       __.--'      #  to read the on-line manual   
 )/' _/     \   `-_,   /            #  while single-stepping the kernel.
 `-'" `"\_  ,_.-;_.-\_ ',  fsc/as   #
     _.-'_./   {_.'   ; /           #    -- FreeBSD Developers handbook 
    {_.-``-'         {_/            #
-------------- 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-hackers/attachments/20081202/459e0e21/attachment.pgp
From keramida at freebsd.org  Tue Dec  2 03:52:59 2008
From: keramida at freebsd.org (Giorgos Keramidas)
Date: Tue Dec  2 03:53:07 2008
Subject: keeping track of local modifications
In-Reply-To: <4934c2c9./+HbbGwhphjtaXAT%perryh@pluto.rain.com>
	(perryh@pluto.rain.com's message of "Mon, 01 Dec 2008 21:08:25 -0800")
References: <4931CB02.9070904@gmail.com> <4932E8CF.9040501@freebsd.org>
	<49337f04.p8QqvfzTga07ypa6%perryh@pluto.rain.com>
	<200812010830.17259.max@love2party.net>
	<gFpinjQW6hEatbsT+XzE0kSsZf0@kjaK+/sQ5DW5981v71UogZJPf/0>
	<874p1nlslc.fsf@kobe.laptop>
	<8S1yocfZ0YutMO/GCIC1bN8RXQ0@kjaK+/sQ5DW5981v71UogZJPf/0>
	<4934c2c9./+HbbGwhphjtaXAT%perryh@pluto.rain.com>
Message-ID: <87ej0q23qt.fsf@kobe.laptop>

On Mon, 01 Dec 2008 21:08:25 -0800, perryh@pluto.rain.com wrote:
>>> Git and Mercurial cannot import Subversion $FreeBSD$ lines so far,
>>> and you may end up submitting patches that include unexpanded forms
>>> of the "$FreeBSD: xxxx $" text.  These will fail to apply if they
>>> same patch touches nearby lines.
>>
>> Ahm, yes.  "sed -e's|$FreeBSD: [^$]* \$|$FreeBSD$|g'" should help
>> in this case.
>
> Not sure I understand what is meant by "unexpanded" here, since it
> looks as if this sed example would convert an "expanded" form --
> containing the version info -- to an "unexpanded" one that merely
> shows where that info should go.
>
> Perhaps it's my ClearCase background showing through, but I'd think it
> highly desirable for a patch to include what I think of as the
> expanded tag line -- including the version info, as it appears in the
> distributed files under /usr/src -- thereby explicitly showing the
> version on which the patch is based (the "base contributor" in
> ClearCase-speak).  This should greatly simplify merging in the
> (likely) event that other development has occurred on the same file in
> the meantime -- provided one is using a 3-way merge tool that
> understands such things.

You are right, of course.

The fact that `$FreeBSD$' is extracted in unexpanded form by the current
svn->hg converter is a limitation of the Python bindings of Subversion.
They do not support expansion of the svn:keywords property of checked
out files.

From danny at cs.huji.ac.il  Tue Dec  2 04:27:40 2008
From: danny at cs.huji.ac.il (Danny Braniss)
Date: Tue Dec  2 04:29:58 2008
Subject: btx/pxeboot problem
Message-ID: <E1L7Tjl-000Ert-J6@kabab.cs.huji.ac.il>

latest pxeboot (7.1):
	mother-board	NIC/LOM	CPU
	-------------   ------- ---
	Intel SWV25	 em	xeon	works fine
	SUN X2200	 bge	amd	works fine
	DELL PE 2950 	 bce	xeon	failes 95% of the times
					hangs or goes into btx dump regs. mode :-)
	Intel SE7320VP21 msk	xeon	failes 50% of the times - hangs

pxeboot with btx.S 1.45 2008/02/27 23:35:39, works fine.

so it seems that changes since 1.45 have fixed it for some, but it
brakes for others :-). I can help testing, but btx is way out of
my league.

danny



From des at des.no  Tue Dec  2 04:33:47 2008
From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=)
Date: Tue Dec  2 04:33:53 2008
Subject: How to build kernel module spread on subdirectories?
In-Reply-To: <4934a886.x0zd2wiIrFlfIq2T%perryh@pluto.rain.com>
	(perryh@pluto.rain.com's message of "Mon, 01 Dec 2008 19:16:22 -0800")
References: <711D7381-D852-4B6B-991A-84BA6DEFB679@gmail.com>
	<49332E5C.9020303@freebsd.org>
	<D6756955-6E0B-429A-9216-2CF223D503D7@gmail.com>
	<200812011231.52262.fbsd.hackers@rachie.is-a-geek.net>
	<4934a886.x0zd2wiIrFlfIq2T%perryh@pluto.rain.com>
Message-ID: <8663m269jt.fsf@ds4.des.no>

perryh@pluto.rain.com writes:
> <heresy> Provided the module in question is contemplated for delivery
> as a port, rather than as part of the base -- so that having a build
> dependency on a port is tolerable -- perhaps it would be more easily
> built using devel/gmake? </heresy>

You'd have to reproduce most of /usr/share/mk/*.mk in gmake syntax.

DES
-- 
Dag-Erling Sm?rgrav - des@des.no
From laladelausanne at gmail.com  Tue Dec  2 07:25:27 2008
From: laladelausanne at gmail.com (=?UTF-8?Q?Nikola_Kne=C5=BEevi=C4=87?=)
Date: Tue Dec  2 07:25:37 2008
Subject: How to build kernel module spread on subdirectories?
In-Reply-To: <8663m269jt.fsf@ds4.des.no>
References: <711D7381-D852-4B6B-991A-84BA6DEFB679@gmail.com>
	<49332E5C.9020303@freebsd.org>
	<D6756955-6E0B-429A-9216-2CF223D503D7@gmail.com>
	<200812011231.52262.fbsd.hackers@rachie.is-a-geek.net>
	<4934a886.x0zd2wiIrFlfIq2T%perryh@pluto.rain.com>
	<8663m269jt.fsf@ds4.des.no>
Message-ID: <6B2CC576-A295-4430-9CC9-B7FA7C276B6D@gmail.com>

On 2 Dec 2008, at 13:33 , Dag-Erling Sm?rgrav wrote:

> perryh@pluto.rain.com writes:
>> <heresy> Provided the module in question is contemplated for delivery
>> as a port, rather than as part of the base -- so that having a build
>> dependency on a port is tolerable -- perhaps it would be more easily
>> built using devel/gmake? </heresy>
>
> You'd have to reproduce most of /usr/share/mk/*.mk in gmake syntax.

That was the main reason why I decided to switch to make :) I had  
problems with CFLAGS set in that GNUmakefile, so I wanted to extract  
CFLAGS used to build the rest of the kernel. And it works now, without  
any problems :)

To answer the other question in other email: yes, that file needs to  
be generated, or I would need to regenerate it whenever I add a new  
element... Which I may forget... So, this is what I ended up using:
<snip til the end>
.MAKEFILEDEPS: elements.mk

beforedepend: elements.mk

.if make(depend) && !exists(${.CURDIR}/elements.mk)
.warning "You should first generate elements.mk"
afterdepend:
         rm -f .depend
         $(MAKE) depend
.endif

.sinclude "elements.mk"
.include <bsd.kmod.mk>

Cheers,
Nikola
From rizzo at iet.unipi.it  Tue Dec  2 07:45:13 2008
From: rizzo at iet.unipi.it (Luigi Rizzo)
Date: Tue Dec  2 07:45:24 2008
Subject: btx/pxeboot problem
In-Reply-To: <E1L7Tjl-000Ert-J6@kabab.cs.huji.ac.il>
References: <E1L7Tjl-000Ert-J6@kabab.cs.huji.ac.il>
Message-ID: <20081202153408.GC54445@onelab2.iet.unipi.it>

On Tue, Dec 02, 2008 at 01:48:17PM +0200, Danny Braniss wrote:
> latest pxeboot (7.1):
> 	mother-board	NIC/LOM	CPU
> 	-------------   ------- ---
> 	Intel SWV25	 em	xeon	works fine
> 	SUN X2200	 bge	amd	works fine
> 	DELL PE 2950 	 bce	xeon	failes 95% of the times
> 					hangs or goes into btx dump regs. mode :-)
> 	Intel SE7320VP21 msk	xeon	failes 50% of the times - hangs
> 
> pxeboot with btx.S 1.45 2008/02/27 23:35:39, works fine.

> so it seems that changes since 1.45 have fixed it for some, but it
> brakes for others :-). I can help testing, but btx is way out of
> my league.

interesting, so this is the same problem i was seeing on the Asus/amd
machines here...

the commit log for 1.47 mention interrupt issues which are consistent
with the random hangs or errors that I see while booting over the
network.

http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/boot/i386/btx/btx/btx.S.diff?r1=1.46;r2=1.47

I wonder if the hangs are related to interrupts coming in at the
wrong time. I also wonder whether the same symptoms might also
affect the standard loader and not just pxeloader, in which case
the problem would be slightly more serious.

I am afraid my ability to debug the problem isn't going much
beyond this...

cheers
luigi
From killing at multiplay.co.uk  Tue Dec  2 08:57:40 2008
From: killing at multiplay.co.uk (Steven Hartland)
Date: Tue Dec  2 08:57:48 2008
Subject: unionfs kernel panic on 7.1-PRERELEASE
Message-ID: <29A6B82D99A749799B4D662ABAE6A960@multiplay.co.uk>

Not sure where to go with this one any help appreciated:-
FreeBSD dedicated11.multiplay.co.uk 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #4: Tue Dec  2 16:53:30 UTC 2008 
root@dedicated11.multiplay.co.uk:/usr/obj/usr/src/sys/MULTIPLAY  i386

kgdb kernel /var/crash/vmcore.1
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:


Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address   = 0x150
fault code              = supervisor read, page not present
instruction pointer     = 0x20:0xc0624115
stack pointer           = 0x28:0xe62c3b80
frame pointer           = 0x28:0xe62c3ba8
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         = 763 (srcds_i686)
trap number             = 12
panic: page fault
cpuid = 0
Uptime: 2m5s
Physical memory: 1007 MB
Dumping 53 MB: 38 22 6


warning: kld_current_sos: Can't read filename: Input/output error

Reading symbols from /boot/kernel/acpi.ko...Reading symbols from /boot/kernel/acpi.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/acpi.ko
Reading symbols from /boot/kernel/linprocfs.ko...Reading symbols from /boot/kernel/linprocfs.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/linprocfs.ko
Reading symbols from /boot/kernel/linux.ko...Reading symbols from /boot/kernel/linux.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/linux.ko
Reading symbols from /boot/kernel/unionfs.ko...Reading symbols from /boot/kernel/unionfs.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/unionfs.ko
#0  doadump () at pcpu.h:196
196     pcpu.h: No such file or directory.
        in pcpu.h
(kgdb) list *0xc0624115
0xc0624115 is in getvnode (/usr/src/sys/kern/vfs_syscalls.c:3969).
3964            fp = NULL;
3965            if (fdp == NULL)
3966                    error = EBADF;
3967            else {
3968                    FILEDESC_SLOCK(fdp);
3969                    if ((u_int)fd >= fdp->fd_nfiles ||
3970                        (fp = fdp->fd_ofiles[fd]) == NULL)
3971                            error = EBADF;
3972                    else if (fp->f_vnode == NULL) {
3973                            fp = NULL;
(kgdb) bt
#0  doadump () at pcpu.h:196
#1  0xc05a0937 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418
#2  0xc05a0c09 in panic (fmt=Variable "fmt" is not available.
) at /usr/src/sys/kern/kern_shutdown.c:574
#3  0xc072eb8c in trap_fatal (frame=0xe62c3b40, eva=336) at /usr/src/sys/i386/i386/trap.c:939
#4  0xc072ee10 in trap_pfault (frame=0xe62c3b40, usermode=0, eva=336) at /usr/src/sys/i386/i386/trap.c:852
#5  0xc072f7cc in trap (frame=0xe62c3b40) at /usr/src/sys/i386/i386/trap.c:530
#6  0xc071563b in calltrap () at /usr/src/sys/i386/i386/exception.s:159
#7  0xc0624115 in getvnode (fdp=0xc40b4d00, fd=4, fpp=0xe62c3c70) at /usr/src/sys/kern/vfs_syscalls.c:3969
#8  0xc3e2a13d in getdents_common (td=0xc408f460, args=0xe62c3cfc, is64bit=0) at 
/usr/src/sys/modules/linux/../../compat/linux/linux_file.c:446
#9  0xc072f165 in syscall (frame=0xe62c3d38) at /usr/src/sys/i386/i386/trap.c:1090
#10 0xc07156a0 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:255
#11 0x00000033 in ?? ()
Previous frame inner to this frame (corrupt stack?)


(kgdb) frame 7
#7  0xc0624115 in getvnode (fdp=0xc40b4d00, fd=4, fpp=0xe62c3c70) at /usr/src/sys/kern/vfs_syscalls.c:3969
3969                    if ((u_int)fd >= fdp->fd_nfiles ||
(kgdb) print *fdp
$1 = {fd_ofiles = 0x140, fd_ofileflags = 0x154 <Address 0x154 out of bounds>, fd_cdir = 0x168, fd_rdir = 0x17c, fd_jdir = 0x18c, 
fd_nfiles = 512, fd_map = 0xc3bed560, fd_lastfile = 4,
  fd_freefile = 5, fd_cmask = 18, fd_refcnt = 1, fd_holdcnt = 1, fd_sx = {lock_object = {lo_name = 0xc076e1c2 "filedesc 
structure", lo_type = 0xc076e1c2 "filedesc structure", lo_flags = 37421056,
      lo_witness_data = {lod_list = {stqe_next = 0x0}, lod_witness = 0x0}}, sx_lock = 17, sx_recurse = 0}, fd_kqlist = {slh_first 
= 0x0}, fd_holdleaderscount = 0, fd_holdleaderswakeup = 0}
(kgdb) print fd
$2 = 4
(kgdb) print fdp->fd_ofiles
$3 = (struct file **) 0x140
(kgdb) print fdp->fd_ofiles[fd]
Cannot access memory at address 0x150
(kgdb) print fdp->fd_ofiles[0]
Cannot access memory at address 0x140
(kgdb) print *fdp->fd_ofiles
Cannot access memory at address 0x140

0xc3e2a13d is in getdents_common (/usr/src/sys/modules/linux/../../compat/linux/linux_file.c:446).
441                     nbytes = sizeof(linux_dirent);
442                     justone = 1;
443             } else
444                     justone = 0;
445
446             if ((error = getvnode(td->td_proc->p_fd, args->fd, &fp)) != 0)
447                     return (error);
448
449             if ((fp->f_flag & FREAD) == 0) {
450                     fdrop(fp, td);

(kgdb) print *args
$5 = {fd_l_ = 0xe62c3cfc "\004", fd = 4, fd_r_ = 0xe62c3d00 "?!\020\b", dirent_l_ = 0xe62c3d00 "?!\020\b", dirent = 0x81021b0, 
dirent_r_ = 0xe62c3d04 "", count_l_ = 0xe62c3d04 "", count = 4096,
  count_r_ = 0xe62c3d08 "?!\020\b?? (\234\235??"}


================================================
This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. 

In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337
or return the E.mail to postmaster@multiplay.co.uk.

From baldur at foo.is  Tue Dec  2 09:08:58 2008
From: baldur at foo.is (Baldur Gislason)
Date: Tue Dec  2 09:09:05 2008
Subject: Help debugging, machine won't boot anymore.
Message-ID: <20081202165258.GM12776@gremlin.foo.is>

I have a machine running 7.0-STABLE/amd64 and it has suddenly
stopped booting. It just leaves me at the debugger with this message:

Fatal trap 9: general protection fault while in kernel mode
cpuid = 0; apic id = 00
instruction pointer     = 0x8:0xffffffff804d913d
stack pointer           = 0x10:0xffffffff80c9ec10
frame pointer           = 0x10:0xffffffff80c9ec70
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         = 0 (swapper)
[thread pid 0 tid 0 ]
Stopped at      device_probe_child+0x61:        movq    0x28(%rax),%rsi
db>

dmesg at http://foo.is/~baldur/enigmaboot.txt
The ACPI warning has always been there.

Any places of interest in the debugger? What's a likely culprit? bad RAM?

Baldur

From kostikbel at gmail.com  Tue Dec  2 13:15:53 2008
From: kostikbel at gmail.com (Kostik Belousov)
Date: Tue Dec  2 13:16:00 2008
Subject: unionfs kernel panic on 7.1-PRERELEASE
In-Reply-To: <29A6B82D99A749799B4D662ABAE6A960@multiplay.co.uk>
References: <29A6B82D99A749799B4D662ABAE6A960@multiplay.co.uk>
Message-ID: <20081202203939.GD3045@deviant.kiev.zoral.com.ua>

On Tue, Dec 02, 2008 at 04:42:58PM -0000, Steven Hartland wrote:
> Not sure where to go with this one any help appreciated:-
> FreeBSD dedicated11.multiplay.co.uk 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE 
> #4: Tue Dec  2 16:53:30 UTC 2008 
> root@dedicated11.multiplay.co.uk:/usr/obj/usr/src/sys/MULTIPLAY  i386
> 
> kgdb kernel /var/crash/vmcore.1
> 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:
> 
> 
> Fatal trap 12: page fault while in kernel mode
> cpuid = 0; apic id = 00
> fault virtual address   = 0x150
> fault code              = supervisor read, page not present
> instruction pointer     = 0x20:0xc0624115
> stack pointer           = 0x28:0xe62c3b80
> frame pointer           = 0x28:0xe62c3ba8
> 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         = 763 (srcds_i686)
> trap number             = 12
> panic: page fault
> cpuid = 0
> Uptime: 2m5s
> Physical memory: 1007 MB
> Dumping 53 MB: 38 22 6
> 
> 
> warning: kld_current_sos: Can't read filename: Input/output error
> 
> Reading symbols from /boot/kernel/acpi.ko...Reading symbols from 
> /boot/kernel/acpi.ko.symbols...done.
> done.
> Loaded symbols for /boot/kernel/acpi.ko
> Reading symbols from /boot/kernel/linprocfs.ko...Reading symbols from 
> /boot/kernel/linprocfs.ko.symbols...done.
> done.
> Loaded symbols for /boot/kernel/linprocfs.ko
> Reading symbols from /boot/kernel/linux.ko...Reading symbols from 
> /boot/kernel/linux.ko.symbols...done.
> done.
> Loaded symbols for /boot/kernel/linux.ko
> Reading symbols from /boot/kernel/unionfs.ko...Reading symbols from 
> /boot/kernel/unionfs.ko.symbols...done.
> done.
> Loaded symbols for /boot/kernel/unionfs.ko
> #0  doadump () at pcpu.h:196
> 196     pcpu.h: No such file or directory.
>        in pcpu.h
> (kgdb) list *0xc0624115
> 0xc0624115 is in getvnode (/usr/src/sys/kern/vfs_syscalls.c:3969).
> 3964            fp = NULL;
> 3965            if (fdp == NULL)
> 3966                    error = EBADF;
> 3967            else {
> 3968                    FILEDESC_SLOCK(fdp);
> 3969                    if ((u_int)fd >= fdp->fd_nfiles ||
> 3970                        (fp = fdp->fd_ofiles[fd]) == NULL)
> 3971                            error = EBADF;
> 3972                    else if (fp->f_vnode == NULL) {
> 3973                            fp = NULL;
> (kgdb) bt
> #0  doadump () at pcpu.h:196
> #1  0xc05a0937 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418
> #2  0xc05a0c09 in panic (fmt=Variable "fmt" is not available.
> ) at /usr/src/sys/kern/kern_shutdown.c:574
> #3  0xc072eb8c in trap_fatal (frame=0xe62c3b40, eva=336) at 
> /usr/src/sys/i386/i386/trap.c:939
> #4  0xc072ee10 in trap_pfault (frame=0xe62c3b40, usermode=0, eva=336) at 
> /usr/src/sys/i386/i386/trap.c:852
> #5  0xc072f7cc in trap (frame=0xe62c3b40) at 
> /usr/src/sys/i386/i386/trap.c:530
> #6  0xc071563b in calltrap () at /usr/src/sys/i386/i386/exception.s:159
> #7  0xc0624115 in getvnode (fdp=0xc40b4d00, fd=4, fpp=0xe62c3c70) at 
> /usr/src/sys/kern/vfs_syscalls.c:3969
> #8  0xc3e2a13d in getdents_common (td=0xc408f460, args=0xe62c3cfc, 
> is64bit=0) at /usr/src/sys/modules/linux/../../compat/linux/linux_file.c:446
> #9  0xc072f165 in syscall (frame=0xe62c3d38) at 
> /usr/src/sys/i386/i386/trap.c:1090
> #10 0xc07156a0 in Xint0x80_syscall () at 
> /usr/src/sys/i386/i386/exception.s:255
> #11 0x00000033 in ?? ()
> Previous frame inner to this frame (corrupt stack?)
> 
> 
> (kgdb) frame 7
> #7  0xc0624115 in getvnode (fdp=0xc40b4d00, fd=4, fpp=0xe62c3c70) at 
> /usr/src/sys/kern/vfs_syscalls.c:3969
> 3969                    if ((u_int)fd >= fdp->fd_nfiles ||
> (kgdb) print *fdp
> $1 = {fd_ofiles = 0x140, fd_ofileflags = 0x154 <Address 0x154 out of 
> bounds>, fd_cdir = 0x168, fd_rdir = 0x17c, fd_jdir = 0x18c, fd_nfiles = 
> 512, fd_map = 0xc3bed560, fd_lastfile = 4,
>  fd_freefile = 5, fd_cmask = 18, fd_refcnt = 1, fd_holdcnt = 1, fd_sx = 
>  {lock_object = {lo_name = 0xc076e1c2 "filedesc structure", lo_type = 
> 0xc076e1c2 "filedesc structure", lo_flags = 37421056,
>      lo_witness_data = {lod_list = {stqe_next = 0x0}, lod_witness = 0x0}}, 
>      sx_lock = 17, sx_recurse = 0}, fd_kqlist = {slh_first = 0x0}, 
> fd_holdleaderscount = 0, fd_holdleaderswakeup = 0}
> (kgdb) print fd
> $2 = 4
> (kgdb) print fdp->fd_ofiles
> $3 = (struct file **) 0x140
> (kgdb) print fdp->fd_ofiles[fd]
> Cannot access memory at address 0x150
> (kgdb) print fdp->fd_ofiles[0]
> Cannot access memory at address 0x140
> (kgdb) print *fdp->fd_ofiles
> Cannot access memory at address 0x140
> 
> 0xc3e2a13d is in getdents_common 
> (/usr/src/sys/modules/linux/../../compat/linux/linux_file.c:446).
> 441                     nbytes = sizeof(linux_dirent);
> 442                     justone = 1;
> 443             } else
> 444                     justone = 0;
> 445
> 446             if ((error = getvnode(td->td_proc->p_fd, args->fd, &fp)) != 
> 0)
> 447                     return (error);
> 448
> 449             if ((fp->f_flag & FREAD) == 0) {
> 450                     fdrop(fp, td);
> 
> (kgdb) print *args
> $5 = {fd_l_ = 0xe62c3cfc "\004", fd = 4, fd_r_ = 0xe62c3d00 "?!\020\b", 
> dirent_l_ = 0xe62c3d00 "?!\020\b", dirent = 0x81021b0, dirent_r_ = 
> 0xe62c3d04 "", count_l_ = 0xe62c3d04 "", count = 4096,
>  count_r_ = 0xe62c3d08 "?!\020\b?? (\234\235??"}

Is it reproducable ?

The start of *fdp structure looks very suspicious,
fd_ofiles = 0x140, fd_ofileflags = 0x154, fd_cdir = 0x168, fd_rdir = 0x17c,
fd_jdir = 0x18c
The values are consequently increasing by 0x14, except fd_jdir, and
pointer values are wrong for kernel.
-------------- 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-hackers/attachments/20081202/265e5ee7/attachment.pgp
From noresult at xs4all.nl  Tue Dec  2 13:14:35 2008
From: noresult at xs4all.nl (Arjan van der Velde)
Date: Tue Dec  2 13:22:34 2008
Subject: TCSBRK not implemented in linux compat
Message-ID: <54A75E03-AE64-4DD9-8D15-7A7499E73D43@xs4all.nl>

Hi,

While trying to get a linux binary running on FreeBSD I encountered  
the following problem during serial port I/O.

Dec  1 22:22:34 soekris kernel: linux: pid 7239 (linuxbinary): ioctl  
fd=0, cmd=0x5409 ('T',9) is not implemented

0x5409  turns out to be TCSBRK, which is not implemented (yet?). Can  
anyone give me some clues where / how to start implementing this? It  
seems like the linux way of handling it is to call tcdrain(), but I'm  
not sure as to how this translates to the FreeBSD compat layer.

Thanks,

Regards,

Arjan



From rdivacky at freebsd.org  Tue Dec  2 13:35:07 2008
From: rdivacky at freebsd.org (Roman Divacky)
Date: Tue Dec  2 13:35:14 2008
Subject: TCSBRK not implemented in linux compat
In-Reply-To: <54A75E03-AE64-4DD9-8D15-7A7499E73D43@xs4all.nl>
References: <54A75E03-AE64-4DD9-8D15-7A7499E73D43@xs4all.nl>
Message-ID: <20081202213021.GA14877@freebsd.org>

On Tue, Dec 02, 2008 at 09:56:28PM +0100, Arjan van der Velde wrote:
> Hi,
> 
> While trying to get a linux binary running on FreeBSD I encountered  
> the following problem during serial port I/O.
> 
> Dec  1 22:22:34 soekris kernel: linux: pid 7239 (linuxbinary): ioctl  
> fd=0, cmd=0x5409 ('T',9) is not implemented
> 
> 0x5409  turns out to be TCSBRK, which is not implemented (yet?). Can  
> anyone give me some clues where / how to start implementing this? It  
> seems like the linux way of handling it is to call tcdrain(), but I'm  
> not sure as to how this translates to the FreeBSD compat layer.

I believe you want to talk to Ed Schouten as this is a TTY thing..

I CCed him
From killing at multiplay.co.uk  Tue Dec  2 14:03:13 2008
From: killing at multiplay.co.uk (Steven Hartland)
Date: Tue Dec  2 14:03:20 2008
Subject: unionfs kernel panic on 7.1-PRERELEASE
References: <29A6B82D99A749799B4D662ABAE6A960@multiplay.co.uk>
	<20081202203939.GD3045@deviant.kiev.zoral.com.ua>
Message-ID: <7F18FDB94BC14E3995D15F0C3BD6312D@multiplay.co.uk>

Yes every time, I've got a half life 2 dedicated install mounted under unionfs:-
mount -t unionfs -o noatime -o below /usr/local/games/hl2ds /usr/local/games/servers/1

As soon as I start the server from under servers/1 the machine panics I'm thinking its
a combination of the Linux ABI and unionfs interaction which is causing the issue.

    Regards
    Steve

----- Original Message ----- 
From: "Kostik Belousov" <kostikbel@gmail.com>
To: "Steven Hartland" <killing@multiplay.co.uk>
Cc: <freebsd-hackers@freebsd.org>
Sent: Tuesday, December 02, 2008 8:39 PM
Subject: Re: unionfs kernel panic on 7.1-PRERELEASE

Is it reproducible ?

The start of *fdp structure looks very suspicious,
fd_ofiles = 0x140, fd_ofileflags = 0x154, fd_cdir = 0x168, fd_rdir = 0x17c,
fd_jdir = 0x18c
The values are consequently increasing by 0x14, except fd_jdir, and
pointer values are wrong for kernel.

================================================
This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. 

In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337
or return the E.mail to postmaster@multiplay.co.uk.

From ed at 80386.nl  Tue Dec  2 14:13:50 2008
From: ed at 80386.nl (Ed Schouten)
Date: Tue Dec  2 14:13:57 2008
Subject: TCSBRK not implemented in linux compat
In-Reply-To: <54A75E03-AE64-4DD9-8D15-7A7499E73D43@xs4all.nl>
References: <54A75E03-AE64-4DD9-8D15-7A7499E73D43@xs4all.nl>
Message-ID: <20081202221349.GT64969@hoeg.nl>

Hello Arjan,

* Arjan van der Velde <noresult@xs4all.nl> wrote:
> While trying to get a linux binary running on FreeBSD I encountered the 
> following problem during serial port I/O.
>
> Dec  1 22:22:34 soekris kernel: linux: pid 7239 (linuxbinary): ioctl  
> fd=0, cmd=0x5409 ('T',9) is not implemented
>
> 0x5409  turns out to be TCSBRK, which is not implemented (yet?). Can  
> anyone give me some clues where / how to start implementing this? It  
> seems like the linux way of handling it is to call tcdrain(), but I'm  
> not sure as to how this translates to the FreeBSD compat layer.

I think you could just make it call TIOCDRAIN directly. Unfortunately
that's not correct if the argument is 0, because then we have to call
TIOCSBRK and TIOCCBRK with a 250 msec interval. I guess adding some kind
of printf() there should be good enough for now.

I can't look into it right now, because I have to get up at 6:15
tomorrow. Sorry! :-/

-- 
 Ed Schouten <ed@80386.nl>
 WWW: http://80386.nl/
-------------- 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-hackers/attachments/20081202/c3cf6ae4/attachment.pgp
From babkin at verizon.net  Tue Dec  2 14:09:22 2008
From: babkin at verizon.net (Sergey Babkin)
Date: Tue Dec  2 14:30:09 2008
Subject: TCSBRK not implemented in linux compat
Message-ID: <1446553908.92321228255743687.JavaMail.root@vms226.mailsrvcs.net>


   >While trying to get    >the following prob   >
   >Dec 1 22:22:34 soekris kernel:    >fd=0, cmd=0x5409 ('T',9)    >
   >0x5409 turns out to be TCSBRK, which is    >anyone give me some clues where / how    It
   >seems like the linux way of handlin   I'm
   >not sure as to how this transla   It should probably be translated to   is
   drain the buffer then send the seria   signal lasting
   longer than the length of o   detect this and generate
   an inte   stty parameters&n   ignbrk, brkint).
   -SB
From steve at Watt.COM  Tue Dec  2 15:28:26 2008
From: steve at Watt.COM (Steve Watt)
Date: Tue Dec  2 15:28:33 2008
Subject: tcsh loses the foreground process group?
In-Reply-To: <20081201042037.GA43208@wattres.Watt.COM>
Message-ID: <200812022328.mB2NSQa6049527@wattres.watt.com>

In article <20081201042037.GA43208@wattres.Watt.COM> you write:
[ ... ]
>I'm running 6-STABLE (6.4-PRE as of 24 Nov right now), tcsh 6.15.00, which
>shows
>
>  tcsh 6.15.00 (Astron) 2007-03-03 (i386-intel-FreeBSD) options wide,nls,dl,al,kan,sm,rh,color,filec
>
>as $version.
>
>The symptom is that when I do a long-ish running task inside a `` expansion
>that I then ^C, nobody gets the foreground process group...  I never get
>a prompt back after the ^C, and ^T gets me
>
>  load: 0.27 no foreground process group

[ ... ]

>One portable reproduction:
># cd /usr/src
># less `egrep -lir '^Foo.*baz' *`
>^Cload: 0.02 no foreground process group
>
>(I typed ^C ^T)
>
>SIGKILL to the shell seems to be the only way to get things back to
>normal.

I've gotten one "me too", which indicated that SIGHUP to the shell
will also make it go away, but does not solve the problem.

I've got another FreeBSD machine available that was running tcsh
6.14.00, and it does _NOT_ display the problem.  When I build
6.15.00 on that same box (/usr/src is more up to date than the
install right now), that does fail.

Thus I'm pretty comfortable saying that it's a tcsh bug of some
sort, and probably a regression.  Hopefully this can be fixed
(PR being filed now) before 6.4 releases...

-- 
Steve Watt KD6GGD  PP-ASEL-IA          ICBM: 121W 56' 57.5" / 37N 20' 15.3"
 Internet: steve @ Watt.COM                      Whois: SW32-ARIN
   Free time?  There's no such thing.  It just comes in varying prices...
From toyj at union.edu  Tue Dec  2 16:15:57 2008
From: toyj at union.edu (jT)
Date: Tue Dec  2 16:16:03 2008
Subject: keeping track of local modifications
In-Reply-To: <87ej0q23qt.fsf@kobe.laptop>
References: <4931CB02.9070904@gmail.com> <4932E8CF.9040501@freebsd.org>
	<49337f04.p8QqvfzTga07ypa6%perryh@pluto.rain.com>
	<200812010830.17259.max@love2party.net>
	<gFpinjQW6hEatbsT+XzE0kSsZf0@kjaK+/sQ5DW5981v71UogZJPf/0>
	<874p1nlslc.fsf@kobe.laptop>
	<8S1yocfZ0YutMO/GCIC1bN8RXQ0@kjaK+/sQ5DW5981v71UogZJPf/0>
	<4934c2c9./+HbbGwhphjtaXAT%perryh@pluto.rain.com>
	<87ej0q23qt.fsf@kobe.laptop>
Message-ID: <9f8af95f0812021615s1b06f10bl3a317da64b7263e8@mail.gmail.com>

On Tue, Dec 2, 2008 at 6:52 AM, Giorgos Keramidas <keramida@freebsd.org> wrote:
> On Mon, 01 Dec 2008 21:08:25 -0800, perryh@pluto.rain.com wrote:
>>>> Git and Mercurial cannot import Subversion $FreeBSD$ lines so far,
>>>> and you may end up submitting patches that include unexpanded forms
>>>> of the "$FreeBSD: xxxx $" text.  These will fail to apply if they
>>>> same patch touches nearby lines.
>>>
>>> Ahm, yes.  "sed -e's|$FreeBSD: [^$]* \$|$FreeBSD$|g'" should help
>>> in this case.
>
> You are right, of course.
>
> The fact that `$FreeBSD$' is extracted in unexpanded form by the current
> svn->hg converter is a limitation of the Python bindings of Subversion.
> They do not support expansion of the svn:keywords property of checked
> out files.
>

good evening Giorgos and Eygene (and list),

   So am i to understand that there is no automatic way to use Hg or
Git?  -- and as Eygene said in order to use them in such a manner
special patching will be required?  I too am looking to set something
else up other than my SVN repository because i personally prefer Hg
and Git to SVN.  Thank you to all who have contributed to this
conversation it has been extremely informative for me and i'm sure
several others.  I hope everyone is looking forward to the holidays


Respectfully,


-- 
/jT
http://git.zen-sources.org/?p=kernel/zenmm.git;a=summary
From david at catwhisker.org  Tue Dec  2 16:26:42 2008
From: david at catwhisker.org (David Wolfskill)
Date: Tue Dec  2 16:26:49 2008
Subject: NFS (& amd?) dysfunction descending a hierarchy
Message-ID: <20081203001538.GC96383@bunrab.catwhisker.org>

I seem to have a fairly- (though not deterministly so) reproducible
mode of failure with an NFS-mounted directory hierarchy:  An attempt to
traverse a "sufficiently large" hierarchy (e.g., via "tar zcpf" or "rm
-fr") will fail to "visit" some subdirectories, typically apparently
acting as if the subdirectories in question do not actually exist
(despite the names having been returned in the output of a previous
readdir()).

The file system is mounted read-write, courtesy of amd(8); none of
the files has any non-default flags; there are no ACLs involved;
and I owned the lot (that is, as "owning user" of the files).

An example of "sufficiently large" has been demonstrated to be a recent
copy of a FreeBSD ports tree.  (The problem was discovered using a
hierarchy that had some proprietary content; I tried a copy of the ports
tree to see if I could replicate the issue with something a FreeBSD
hacker would more likely have handy.  And avoid NDA issues.  :-})

Now, before I go further: I'm not pointing the finger at FreeBSD,
here (yet).  At minimum, there could be fault with FreeBSD (as the NFS
client); with amd(8); with the NetApp Filer (as the NFS server);
or the network -- or the configuration(s) of any of them.

But I just tried this, using the same NFS server, but a machine running
Solaris 8 as an NFS client, and was unable to re-create the problem.

And I found a way to avoid having the problem occur using a FreeBSD NFS
client:  whack amd(8)'s config so that the dismount_interval is 12 hours
instead of the default 2 minutes, thus effectivly preventing amd(8) from
its normal attempts to unmount file systems.  Please note that I don't
consider this a fix -- or even an acceptable circumvention, in the long
term.  Rather, it's a diagnostic change, in an attempt to better
understand the nature of the problem.

Here are step-by-step instructions to recreate the problem;
unfortunately, I believe I don't have the resources to test this
anywhere but at work, though I will try it at home, to the extent
that I can:

* Set up the environment.
  * The failing environment uses NetApp filers as NFS servers.  I don't
    know what kind or how recent the software is on them, but can
    find out.  (I exepct they're fairly well-maintained.)
  * Ensure that the NFS space available is at least 10 GB or more.
    I will refer to this as "~/NFS/", as I tend to create such symlinks
    to keep track of things.
  * I used a dual, quad-core machine running FreeBSD RELENG_7_1 as of
    yesterday morning as an NFS client.  It also had a recently-updated
    /usr/ports tree, which was a CVS working directory (so each "real"
    subdirectory also had a CVS subdirectory within it).
  * Set up amd(8) so that ~/NFS is mounted on demand when it's
    referenced, and only via amd(8).  Ensure that the dismount_interval
    has the default value of 120 seconds.
* Create a reference tarball.
  * cd /usr && tar zcpf ~/NFS/ports.tgz ports/
* Create the test directory hierarchy.
  * cd ~/NFS && tar zxpf ports.tgz
* Clear any cache.
  * Unmount ~/NFS, then re-mount it.  Or just reboot the NFS client
    machine.  Or arrange to have done all of the above set-up stuff
    from a differnet NFS client.
* Set up for information capture (optional).
  * Use ps(1) or your favorite alternative tool to determine the PID for
    amd(8).  Note that `cat /var/run/amd.pid` won't do the trick.  :-{
  * Run ktrace(1) to capture activity from amd(8) and its descendants,
    e.g.:

	sudo ktrace -dip ${amd_pid} -f ktrace_amd.out

  * Start a packet-capture for NFS traffic, e.g.:

	sudo tcpdump -s 0 -n -w nfs.bpf host ${nfs_server}

* Start the test.
  * Do this under ktrace(1), if you did the above optional step:

	rm -fr ~/NFS/ports; echo $?

    As soon as rm(1) issues a whine, you might as well interrupt it
    (^C).

* Stop the information capture, if you started it.
  * ^C for the tcpdump(1) process.
  * sudo ktrace -C


If the packet capture file is too big for the analysis program you
prefer to digest as a unit, see the net/tcpslice port for a bit of
relief.  (Wireshark seems to want to read an entire packet capture file
into main memory.)

I have performed the above, with the "information-gathering" step; I can
*probably* make that information available, but I'll need to check --
some organizations get paranoid about things like host names.  I don't
expect that my current employer is, but I don't know yet, so I won't
promise.

In the mean time, I should be able to extract somewhat-relevant
information from what I've collected, if that would be useful.  While I
wouldn't mind sharing the results, I strongly suspect that blow-by-blow
analysis wouldn't be ideal for this (or any other) mailing list; I would
be very happy to work with others to figure out what's gone wrong (or is
misconfigured) and get things working properly.

If someone(s) would be willing to help, I'd appreciate it very much.  If
(enough) folks would actually prefer that the details stay in the list
(or some other list), I'm willing to do that, too.

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: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20081203/ce02e1a2/attachment.pgp
From zbeeble at gmail.com  Tue Dec  2 17:44:11 2008
From: zbeeble at gmail.com (Zaphod Beeblebrox)
Date: Tue Dec  2 17:44:17 2008
Subject: AMD64 qemu completely broken?
Message-ID: <5f67a8c40812021718i4cc225fem5b02a448702ec606@mail.gmail.com>

I decided to take the comments about testing ZFS to heart --- so I decided
to try copying my 7.0 "v6" ZFS configuration into a qemu instance and
upgrading it.  To do this, I carefully copied my UFS boot partition and my
ZFS partion to a physical USB disk that I could put on a system to do the
test.

After compiling qemu and loading the kqemu and aio kernel module, I started
the emulator, first in VNC mode.  It loaded the kernel (currently 7.1-RC)
and tried to boot, but kept failing either shortly after kbdmux detected a
keyboard or it would get through to mounting root and not find any drives.
For reference, besides the display option (ie: -vnc or whatever), my command
line was:

qemu-system-x86_64 -hda /dev/da0 -snapshot -m 512

I couldn't scroll back in VNC mode using the pause/break key, so I tried to
get qemu running directly in X.

Now... I see a few posts stating that running qemu remotely causes an X
protocol error.  I can confirm that.  Something about Qemu's use of X will
no work over an SSH remote connection (with -X), nor will it work with
dxpc.  It dies for me every time at X event sequence number 22.  Xterms
work.  Gimp even works.  qemu does not.

So I got a vnc server running to run it locally.

And now it crashes reliably in one spot.  boot0 and boot1 don't recognize
the keyboard ... but the press space after crash does.  Besides that quirk,
the 7.1-RC kernel crashes with the following transcript reliably:

MADT: Forcing active-low polarity and level trigger for SCI
kbd1 at kbdmux0
ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413)


Fatal trap 9: general protection fault while in kernel mode
cpuid = 0; apic id=00
instruction pointer             = 0x8:0xffff

... and so on.

I'd like to test this... has anyone any successes with the AMD64 qemu?
From ken at mthelicon.com  Tue Dec  2 18:26:39 2008
From: ken at mthelicon.com (Pegasus Mc Cleaft)
Date: Tue Dec  2 18:26:46 2008
Subject: ZFS & make install with exec=no in /tmp
Message-ID: <200812030226.30448.ken@mthelicon.com>

Hello hackers, 

	I was wondering if there is a work around for this... 

	In 8.0-current I have installed the new version of ZFS and upgraded the 
filing systems to 13. I had a thought that I would make a zfs for /tmp and set 
the exec to no (thinking that nothing should ever be executed in the tmp). All 
seemed to work ok, however, I ran into a problem when I was installing a new 
world. The script immediately bombed out with a permission denied message. 

	I remembered seeing that type of message before when I was testing the no-
exec bit in /tmp before, so I reset it to 'yes' and all is well and installed 
fine.. 

	Is there any way to specify what directory is used for building and executing 
the install scripts? 

Ta,
Peg


From kris at FreeBSD.org  Tue Dec  2 18:53:53 2008
From: kris at FreeBSD.org (Kris Kennaway)
Date: Tue Dec  2 18:54:01 2008
Subject: ZFS & make install with exec=no in /tmp
In-Reply-To: <200812030226.30448.ken@mthelicon.com>
References: <200812030226.30448.ken@mthelicon.com>
Message-ID: <4935F4C1.8060907@FreeBSD.org>

Pegasus Mc Cleaft wrote:
> Hello hackers, 
> 
> 	I was wondering if there is a work around for this... 
> 
> 	In 8.0-current I have installed the new version of ZFS and upgraded the 
> filing systems to 13. I had a thought that I would make a zfs for /tmp and set 
> the exec to no (thinking that nothing should ever be executed in the tmp). All 
> seemed to work ok, however, I ran into a problem when I was installing a new 
> world. The script immediately bombed out with a permission denied message. 
> 
> 	I remembered seeing that type of message before when I was testing the no-
> exec bit in /tmp before, so I reset it to 'yes' and all is well and installed 
> fine.. 
> 
> 	Is there any way to specify what directory is used for building and executing 
> the install scripts? 

The standard UNIX way is to set the TMPDIR env variable.

Kris
From rea-fbsd at codelabs.ru  Tue Dec  2 23:10:08 2008
From: rea-fbsd at codelabs.ru (Eygene Ryabinkin)
Date: Tue Dec  2 23:10:15 2008
Subject: keeping track of local modifications
In-Reply-To: <9f8af95f0812021615s1b06f10bl3a317da64b7263e8@mail.gmail.com>
References: <4931CB02.9070904@gmail.com> <4932E8CF.9040501@freebsd.org>
	<49337f04.p8QqvfzTga07ypa6%perryh@pluto.rain.com>
	<200812010830.17259.max@love2party.net>
	<gFpinjQW6hEatbsT+XzE0kSsZf0@kjaK+/sQ5DW5981v71UogZJPf/0>
	<874p1nlslc.fsf@kobe.laptop>
	<8S1yocfZ0YutMO/GCIC1bN8RXQ0@kjaK+/sQ5DW5981v71UogZJPf/0>
	<4934c2c9./+HbbGwhphjtaXAT%perryh@pluto.rain.com>
	<87ej0q23qt.fsf@kobe.laptop>
	<9f8af95f0812021615s1b06f10bl3a317da64b7263e8@mail.gmail.com>
Message-ID: <eSGdGdtnFN7cPv01hb9QGH/cdeg@qfm1CqiMhq5PC0gOJEfEHBTn+A0>

jT, good day.

Tue, Dec 02, 2008 at 07:15:55PM -0500, jT wrote:
> On Tue, Dec 2, 2008 at 6:52 AM, Giorgos Keramidas <keramida@freebsd.org> wrote:
> > The fact that `$FreeBSD$' is extracted in unexpanded form by the current
> > svn->hg converter is a limitation of the Python bindings of Subversion.
> > They do not support expansion of the svn:keywords property of checked
> > out files.
> >
> 
>    So am i to understand that there is no automatic way to use Hg or
> Git? -- and as Eygene said in order to use them in such a manner
> special patching will be required?

I am happily using Git for my FreeBSD work: I have local repository that
is just CVSupped from time to time to sync the master branch to the
mainline and, possibly, rebase my work against it.  This isn't even
git-svn, just Git repo + CVSup.  Probably git-svn will also work here,
but as ports are still using CVS and I have both ports and src
repositories, this is just easier for me to use CVSup.  Yes, I am losing
the commit history, but I don't care about this: cvsweb.freebsd.org is
still alive and kicking.

About patching: the point was that some percentage of patches, that are
carrying '$FreeBSD$' tags in their body, won't apply cleanly in some
situations (namely, when your patch is based on the revision N and
maintainer applies it to the revision != N).  It turns to be true even
for Subversion itself, but the hope isn't completely lost -- for some
cases patches can be applied with fuzz (namely, ignoring the '$Id'
mismatch).  Larry Wall and others were smart about introducing the fuzz
factor ;))

> I too am looking to set something
> else up other than my SVN repository because i personally prefer Hg
> and Git to SVN.  Thank you to all who have contributed to this
> conversation it has been extremely informative for me and i'm sure
> several others.

I think that you can at least try to work with git-svn: you'll check out
the master timely and will be able to rebase your own work, provided
that it is lying in the separate branches.  This way you'll have the
whole history, at least you should.

Don't know for Mercurial, hadn't used it for FreeBSD yet.
-- 
Eygene
 _                ___       _.--.   #
 \`.|\..----...-'`   `-._.-'_.-'`   #  Remember that it is hard
 /  ' `         ,       __.--'      #  to read the on-line manual   
 )/' _/     \   `-_,   /            #  while single-stepping the kernel.
 `-'" `"\_  ,_.-;_.-\_ ',  fsc/as   #
     _.-'_./   {_.'   ; /           #    -- FreeBSD Developers handbook 
    {_.-``-'         {_/            #
-------------- 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-hackers/attachments/20081203/15ac9d74/attachment.pgp
From maslanbsd at gmail.com  Tue Dec  2 23:42:41 2008
From: maslanbsd at gmail.com (Maslan)
Date: Tue Dec  2 23:42:47 2008
Subject: Controlling a process
In-Reply-To: <j2Y/1ERA+pTg5cUUXFtkn4Voee8@qm7gbYKMPO53E/nl+D5eD8YyL1A>
References: <319cceca0812020153y6cde7b0ara2cff1d1b0525e10@mail.gmail.com>
	<j2Y/1ERA+pTg5cUUXFtkn4Voee8@qm7gbYKMPO53E/nl+D5eD8YyL1A>
Message-ID: <319cceca0812022342p5727d2e2n14dd52e54455a870@mail.gmail.com>

setrlimit(2)

Ok thanks a lot

On Tue, Dec 2, 2008 at 10:37 AM, Eygene Ryabinkin <rea-fbsd@codelabs.ru> wrote:
> Maslan, good day.
>
> Tue, Dec 02, 2008 at 09:53:09AM +0000, Maslan wrote:
>> What is the best way to control a process (running in chroot env):
>> 1- Execution time
>> 2- Memory limit
>> And to be able to kill the process when it breaks this limits.
>
> man 2 setrlimit
>
>> Finally, i would like to know the exit status of the process or the
>> signal that killed it (sigfault, .....)
>
> If you're spawning the process in question, then 'man 2 wait'.
> --
> Eygene
>  _                ___       _.--.   #
>  \`.|\..----...-'`   `-._.-'_.-'`   #  Remember that it is hard
>  /  ' `         ,       __.--'      #  to read the on-line manual
>  )/' _/     \   `-_,   /            #  while single-stepping the kernel.
>  `-'" `"\_  ,_.-;_.-\_ ',  fsc/as   #
>     _.-'_./   {_.'   ; /           #    -- FreeBSD Developers handbook
>    {_.-``-'         {_/            #
>



-- 
System Programmer
--
I'm Searching For Perfection,
So Even If U Need Portability U've To Use Assembly ;-)
--
http://libosdk.berlios.de
From danny at cs.huji.ac.il  Wed Dec  3 04:20:35 2008
From: danny at cs.huji.ac.il (Danny Braniss)
Date: Wed Dec  3 04:20:42 2008
Subject: NFS (& amd?) dysfunction descending a hierarchy 
In-Reply-To: <20081203001538.GC96383@bunrab.catwhisker.org> 
References: <20081203001538.GC96383@bunrab.catwhisker.org>
Message-ID: <E1L7qiW-0003np-NF@kabab.cs.huji.ac.il>

> 
> --hYooF8G/hrfVAmum
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable
> 
> I seem to have a fairly- (though not deterministly so) reproducible
> mode of failure with an NFS-mounted directory hierarchy:  An attempt to
> traverse a "sufficiently large" hierarchy (e.g., via "tar zcpf" or "rm
> -fr") will fail to "visit" some subdirectories, typically apparently
> acting as if the subdirectories in question do not actually exist
> (despite the names having been returned in the output of a previous
> readdir()).
> 
> The file system is mounted read-write, courtesy of amd(8); none of
> the files has any non-default flags; there are no ACLs involved;
> and I owned the lot (that is, as "owning user" of the files).
> 
> An example of "sufficiently large" has been demonstrated to be a recent
> copy of a FreeBSD ports tree.  (The problem was discovered using a
> hierarchy that had some proprietary content; I tried a copy of the ports
> tree to see if I could replicate the issue with something a FreeBSD
> hacker would more likely have handy.  And avoid NDA issues.  :-})
> 
> Now, before I go further: I'm not pointing the finger at FreeBSD,
> here (yet).  At minimum, there could be fault with FreeBSD (as the NFS
> client); with amd(8); with the NetApp Filer (as the NFS server);
> or the network -- or the configuration(s) of any of them.
> 
> But I just tried this, using the same NFS server, but a machine running
> Solaris 8 as an NFS client, and was unable to re-create the problem.
> 
> And I found a way to avoid having the problem occur using a FreeBSD NFS
> client:  whack amd(8)'s config so that the dismount_interval is 12 hours
> instead of the default 2 minutes, thus effectivly preventing amd(8) from
> its normal attempts to unmount file systems.  Please note that I don't
> consider this a fix -- or even an acceptable circumvention, in the long
> term.  Rather, it's a diagnostic change, in an attempt to better
> understand the nature of the problem.
> 
> Here are step-by-step instructions to recreate the problem;
> unfortunately, I believe I don't have the resources to test this
> anywhere but at work, though I will try it at home, to the extent
> that I can:
> 
> * Set up the environment.
>   * The failing environment uses NetApp filers as NFS servers.  I don't
>     know what kind or how recent the software is on them, but can
>     find out.  (I exepct they're fairly well-maintained.)
>   * Ensure that the NFS space available is at least 10 GB or more.
>     I will refer to this as "~/NFS/", as I tend to create such symlinks
>     to keep track of things.
>   * I used a dual, quad-core machine running FreeBSD RELENG_7_1 as of
>     yesterday morning as an NFS client.  It also had a recently-updated
>     /usr/ports tree, which was a CVS working directory (so each "real"
>     subdirectory also had a CVS subdirectory within it).
>   * Set up amd(8) so that ~/NFS is mounted on demand when it's
>     referenced, and only via amd(8).  Ensure that the dismount_interval
>     has the default value of 120 seconds.
> * Create a reference tarball.
>   * cd /usr && tar zcpf ~/NFS/ports.tgz ports/
> * Create the test directory hierarchy.
>   * cd ~/NFS && tar zxpf ports.tgz
> * Clear any cache.
>   * Unmount ~/NFS, then re-mount it.  Or just reboot the NFS client
>     machine.  Or arrange to have done all of the above set-up stuff
>     from a differnet NFS client.
> * Set up for information capture (optional).
>   * Use ps(1) or your favorite alternative tool to determine the PID for
>     amd(8).  Note that `cat /var/run/amd.pid` won't do the trick.  :-{
>   * Run ktrace(1) to capture activity from amd(8) and its descendants,
>     e.g.:
> 
> 	sudo ktrace -dip ${amd_pid} -f ktrace_amd.out
> 
>   * Start a packet-capture for NFS traffic, e.g.:
> 
> 	sudo tcpdump -s 0 -n -w nfs.bpf host ${nfs_server}
> 
> * Start the test.
>   * Do this under ktrace(1), if you did the above optional step:
> 
> 	rm -fr ~/NFS/ports; echo $?
> 
>     As soon as rm(1) issues a whine, you might as well interrupt it
>     (^C).
> 
> * Stop the information capture, if you started it.
>   * ^C for the tcpdump(1) process.
>   * sudo ktrace -C
> 
> 
> If the packet capture file is too big for the analysis program you
> prefer to digest as a unit, see the net/tcpslice port for a bit of
> relief.  (Wireshark seems to want to read an entire packet capture file
> into main memory.)
> 
> I have performed the above, with the "information-gathering" step; I can
> *probably* make that information available, but I'll need to check --
> some organizations get paranoid about things like host names.  I don't
> expect that my current employer is, but I don't know yet, so I won't
> promise.
> 
> In the mean time, I should be able to extract somewhat-relevant
> information from what I've collected, if that would be useful.  While I
> wouldn't mind sharing the results, I strongly suspect that blow-by-blow
> analysis wouldn't be ideal for this (or any other) mailing list; I would
> be very happy to work with others to figure out what's gone wrong (or is
> misconfigured) and get things working properly.
> 
> If someone(s) would be willing to help, I'd appreciate it very much.  If
> (enough) folks would actually prefer that the details stay in the list
> (or some other list), I'm willing to do that, too.
> 

i'll try to check it here soon, but in the meantime, could you try the same
but mounting directly, not via amd, to remove one item from the equation?
(I don't know how much amd is involved here, but if you are running on a
64bit host, amd could be swapped out, in which case it tends to realy screw
things up, which is not your case, but ...)

	danny

> Thanks!
> 
> Peace,
> david
> --=20
> 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.
> 
> --hYooF8G/hrfVAmum
> Content-Type: application/pgp-signature
> Content-Disposition: inline
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.0 (FreeBSD)
> 
> iEYEARECAAYFAkk1z6oACgkQmprOCmdXAD2mrwCfTEVXI1WgKKGBlhx9mKSzAcbb
> UucAniRFPjrIOXonJk9Id6v1lFhXsAvF
> =9NVu
> -----END PGP SIGNATURE-----
> 
> --hYooF8G/hrfVAmum--
> 


From david at catwhisker.org  Wed Dec  3 04:45:44 2008
From: david at catwhisker.org (David Wolfskill)
Date: Wed Dec  3 04:45:51 2008
Subject: NFS (& amd?) dysfunction descending a hierarchy
In-Reply-To: <E1L7qiW-0003np-NF@kabab.cs.huji.ac.il>
References: <20081203001538.GC96383@bunrab.catwhisker.org>
	<E1L7qiW-0003np-NF@kabab.cs.huji.ac.il>
Message-ID: <20081203124507.GE96383@bunrab.catwhisker.org>

On Wed, Dec 03, 2008 at 02:20:32PM +0200, Danny Braniss wrote:
> ...
> i'll try to check it here soon, but in the meantime, could you try the same
> but mounting directly, not via amd, to remove one item from the equation?
> (I don't know how much amd is involved here, but if you are running on a
> 64bit host, amd could be swapped out, in which case it tends to realy screw
> things up, which is not your case, but ...)

Sorry; I should have mentioned that the NFS client was running
RELENG_7_1 as of Monday morning, i386 arch.  The amd.conf file specifies
"plock" for amd(8).

Note that merely telling amd(8) to kick the interval of attempted
unmounts from 2 minutes to 12 hours appears to avoid the observed
symptoms, so I'm fairly confident that bypassing amd(8) altogether would
do so as well.

In looking at the output from ktrace against amd(8), I recall having
seen that shortly before an observed failure, the (master) amd
process forks a child to attempt the unmount; the child issues an
unmount, the return for which is EBUSY (IIRC -- I'm not in a good
position to check just at the moment), so the child terminates with an
"interrupted system call".

I'd have thought that since the attempted unmount failed, it wouldn't
make any difference, but it's right around that point that rm(1) is told
that a directory entry it found earlier doesn't exist, which rather
snowballs into the previously-described symptoms.

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: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20081203/8fce6e60/attachment.pgp
From danny at cs.huji.ac.il  Wed Dec  3 04:59:05 2008
From: danny at cs.huji.ac.il (Danny Braniss)
Date: Wed Dec  3 04:59:12 2008
Subject: NFS (& amd?) dysfunction descending a hierarchy 
In-Reply-To: <20081203124507.GE96383@bunrab.catwhisker.org> 
References: <20081203001538.GC96383@bunrab.catwhisker.org> 
	<E1L7qiW-0003np-NF@kabab.cs.huji.ac.il>
	<20081203124507.GE96383@bunrab.catwhisker.org>
Message-ID: <E1L7rJn-0004KA-OQ@kabab.cs.huji.ac.il>

> 
> --vmttodhTwj0NAgWp
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable
> 
> On Wed, Dec 03, 2008 at 02:20:32PM +0200, Danny Braniss wrote:
> > ...
> > i'll try to check it here soon, but in the meantime, could you try the sa=
> me
> > but mounting directly, not via amd, to remove one item from the equation?
> > (I don't know how much amd is involved here, but if you are running on a
> > 64bit host, amd could be swapped out, in which case it tends to realy scr=
> ew
> > things up, which is not your case, but ...)
> 
> Sorry; I should have mentioned that the NFS client was running
> RELENG_7_1 as of Monday morning, i386 arch.  The amd.conf file specifies
> "plock" for amd(8).
> 
> Note that merely telling amd(8) to kick the interval of attempted
> unmounts from 2 minutes to 12 hours appears to avoid the observed
> symptoms, so I'm fairly confident that bypassing amd(8) altogether would
> do so as well.
> 
> In looking at the output from ktrace against amd(8), I recall having
> seen that shortly before an observed failure, the (master) amd
> process forks a child to attempt the unmount; the child issues an
> unmount, the return for which is EBUSY (IIRC -- I'm not in a good
> position to check just at the moment), so the child terminates with an
> "interrupted system call".
> 
> I'd have thought that since the attempted unmount failed, it wouldn't
> make any difference, but it's right around that point that rm(1) is told
> that a directory entry it found earlier doesn't exist, which rather
> snowballs into the previously-described symptoms.

so it does point to amd - or something inocent it does - which triggers the 
error.
btw, there are some patches (5 I think), that try to fix some of amd problems.
I've installed them, and things are quiet/ok -most of the time- but I get a
glitch once in a while. would love to iron them out though.

cheers,
	danny


From kostikbel at gmail.com  Wed Dec  3 05:57:13 2008
From: kostikbel at gmail.com (Kostik Belousov)
Date: Wed Dec  3 05:57:39 2008
Subject: NFS (& amd?) dysfunction descending a hierarchy
In-Reply-To: <20081203001538.GC96383@bunrab.catwhisker.org>
References: <20081203001538.GC96383@bunrab.catwhisker.org>
Message-ID: <20081203131902.GK3045@deviant.kiev.zoral.com.ua>

On Tue, Dec 02, 2008 at 04:15:38PM -0800, David Wolfskill wrote:
> I seem to have a fairly- (though not deterministly so) reproducible
> mode of failure with an NFS-mounted directory hierarchy:  An attempt to
> traverse a "sufficiently large" hierarchy (e.g., via "tar zcpf" or "rm
> -fr") will fail to "visit" some subdirectories, typically apparently
> acting as if the subdirectories in question do not actually exist
> (despite the names having been returned in the output of a previous
> readdir()).
> 
> The file system is mounted read-write, courtesy of amd(8); none of
> the files has any non-default flags; there are no ACLs involved;
> and I owned the lot (that is, as "owning user" of the files).
> 
> An example of "sufficiently large" has been demonstrated to be a recent
> copy of a FreeBSD ports tree.  (The problem was discovered using a
> hierarchy that had some proprietary content; I tried a copy of the ports
> tree to see if I could replicate the issue with something a FreeBSD
> hacker would more likely have handy.  And avoid NDA issues.  :-})
> 
> Now, before I go further: I'm not pointing the finger at FreeBSD,
> here (yet).  At minimum, there could be fault with FreeBSD (as the NFS
> client); with amd(8); with the NetApp Filer (as the NFS server);
> or the network -- or the configuration(s) of any of them.
> 
> But I just tried this, using the same NFS server, but a machine running
> Solaris 8 as an NFS client, and was unable to re-create the problem.
> 
> And I found a way to avoid having the problem occur using a FreeBSD NFS
> client:  whack amd(8)'s config so that the dismount_interval is 12 hours
> instead of the default 2 minutes, thus effectivly preventing amd(8) from
> its normal attempts to unmount file systems.  Please note that I don't
> consider this a fix -- or even an acceptable circumvention, in the long
> term.  Rather, it's a diagnostic change, in an attempt to better
> understand the nature of the problem.
> 
> Here are step-by-step instructions to recreate the problem;
> unfortunately, I believe I don't have the resources to test this
> anywhere but at work, though I will try it at home, to the extent
> that I can:
> 
> * Set up the environment.
>   * The failing environment uses NetApp filers as NFS servers.  I don't
>     know what kind or how recent the software is on them, but can
>     find out.  (I exepct they're fairly well-maintained.)
>   * Ensure that the NFS space available is at least 10 GB or more.
>     I will refer to this as "~/NFS/", as I tend to create such symlinks
>     to keep track of things.
>   * I used a dual, quad-core machine running FreeBSD RELENG_7_1 as of
>     yesterday morning as an NFS client.  It also had a recently-updated
>     /usr/ports tree, which was a CVS working directory (so each "real"
>     subdirectory also had a CVS subdirectory within it).
>   * Set up amd(8) so that ~/NFS is mounted on demand when it's
>     referenced, and only via amd(8).  Ensure that the dismount_interval
>     has the default value of 120 seconds.
> * Create a reference tarball.
>   * cd /usr && tar zcpf ~/NFS/ports.tgz ports/
> * Create the test directory hierarchy.
>   * cd ~/NFS && tar zxpf ports.tgz
> * Clear any cache.
>   * Unmount ~/NFS, then re-mount it.  Or just reboot the NFS client
>     machine.  Or arrange to have done all of the above set-up stuff
>     from a differnet NFS client.
> * Set up for information capture (optional).
>   * Use ps(1) or your favorite alternative tool to determine the PID for
>     amd(8).  Note that `cat /var/run/amd.pid` won't do the trick.  :-{
>   * Run ktrace(1) to capture activity from amd(8) and its descendants,
>     e.g.:
> 
> 	sudo ktrace -dip ${amd_pid} -f ktrace_amd.out
> 
>   * Start a packet-capture for NFS traffic, e.g.:
> 
> 	sudo tcpdump -s 0 -n -w nfs.bpf host ${nfs_server}
> 
> * Start the test.
>   * Do this under ktrace(1), if you did the above optional step:
> 
> 	rm -fr ~/NFS/ports; echo $?
> 
>     As soon as rm(1) issues a whine, you might as well interrupt it
>     (^C).
> 
> * Stop the information capture, if you started it.
>   * ^C for the tcpdump(1) process.
>   * sudo ktrace -C
> 
> 
> If the packet capture file is too big for the analysis program you
> prefer to digest as a unit, see the net/tcpslice port for a bit of
> relief.  (Wireshark seems to want to read an entire packet capture file
> into main memory.)
> 
> I have performed the above, with the "information-gathering" step; I can
> *probably* make that information available, but I'll need to check --
> some organizations get paranoid about things like host names.  I don't
> expect that my current employer is, but I don't know yet, so I won't
> promise.
> 
> In the mean time, I should be able to extract somewhat-relevant
> information from what I've collected, if that would be useful.  While I
> wouldn't mind sharing the results, I strongly suspect that blow-by-blow
> analysis wouldn't be ideal for this (or any other) mailing list; I would
> be very happy to work with others to figure out what's gone wrong (or is
> misconfigured) and get things working properly.
> 
> If someone(s) would be willing to help, I'd appreciate it very much.  If
> (enough) folks would actually prefer that the details stay in the list
> (or some other list), I'm willing to do that, too.
> 

I highly suspect that I know what happen. What branch are you using ?
I committed a possible fix yesterday, r185557. The patch shall be
directly applicable to 7.
-------------- 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-hackers/attachments/20081203/239bdca6/attachment.pgp
From bsd.quest at googlemail.com  Wed Dec  3 06:35:32 2008
From: bsd.quest at googlemail.com (Alexej Sokolov)
Date: Wed Dec  3 06:35:38 2008
Subject: vm_map_entry for kernel virtual addres
Message-ID: <671bb5fc0812030635s1fd7fe4frc1840a85e87b4047@mail.gmail.com>

Hello,
If I allocate memory from a kernel module:
MALLOC(addr, vm_offset_t, PAGE_SIZE, M_DEVBUF, M_WAITOK | M_ZERO);

how can I get a pointer to vm_map_entry structure which describes the memory
region where "addr" is ?

Thanks,
Alexey
From noresult at xs4all.nl  Wed Dec  3 11:28:51 2008
From: noresult at xs4all.nl (Arjan van der Velde)
Date: Wed Dec  3 11:33:31 2008
Subject: TCSBRK not implemented in linux compat
In-Reply-To: <20081202221349.GT64969@hoeg.nl>
References: <54A75E03-AE64-4DD9-8D15-7A7499E73D43@xs4all.nl>
	<20081202221349.GT64969@hoeg.nl>
Message-ID: <E5326705-C609-42C0-A0FE-9242AEEE0D7B@xs4all.nl>

Hi, thanks. I think for now I can work around this although it would  
be nice to have this implemented.

Regards,

Arjan

On Dec 2, 2008, at 11:13 PM, Ed Schouten wrote:

> Hello Arjan,
>
> * Arjan van der Velde <noresult@xs4all.nl> wrote:
>> While trying to get a linux binary running on FreeBSD I encountered  
>> the
>> following problem during serial port I/O.
>>
>> Dec  1 22:22:34 soekris kernel: linux: pid 7239 (linuxbinary): ioctl
>> fd=0, cmd=0x5409 ('T',9) is not implemented
>>
>> 0x5409  turns out to be TCSBRK, which is not implemented (yet?). Can
>> anyone give me some clues where / how to start implementing this? It
>> seems like the linux way of handling it is to call tcdrain(), but I'm
>> not sure as to how this translates to the FreeBSD compat layer.
>
> I think you could just make it call TIOCDRAIN directly. Unfortunately
> that's not correct if the argument is 0, because then we have to call
> TIOCSBRK and TIOCCBRK with a 250 msec interval. I guess adding some  
> kind
> of printf() there should be good enough for now.
>
> I can't look into it right now, because I have to get up at 6:15
> tomorrow. Sorry! :-/
>
> -- 
> Ed Schouten <ed@80386.nl>
> WWW: http://80386.nl/

From neldredge at math.ucsd.edu  Wed Dec  3 16:19:03 2008
From: neldredge at math.ucsd.edu (Nate Eldredge)
Date: Wed Dec  3 16:19:09 2008
Subject: tcsh loses the foreground process group?
In-Reply-To: <200812022328.mB2NSQa6049527@wattres.watt.com>
References: <200812022328.mB2NSQa6049527@wattres.watt.com>
Message-ID: <Pine.GSO.4.64.0812031541330.1597@zeno.ucsd.edu>

On Tue, 2 Dec 2008, Steve Watt wrote:

> In article <20081201042037.GA43208@wattres.Watt.COM> you write:
> [ ... ]
>> I'm running 6-STABLE (6.4-PRE as of 24 Nov right now), tcsh 6.15.00, which
>> shows
>>
>>  tcsh 6.15.00 (Astron) 2007-03-03 (i386-intel-FreeBSD) options wide,nls,dl,al,kan,sm,rh,color,filec
>>
>> as $version.
>>
>> The symptom is that when I do a long-ish running task inside a `` expansion
>> that I then ^C, nobody gets the foreground process group...  I never get
>> a prompt back after the ^C, and ^T gets me
>>
>>  load: 0.27 no foreground process group
>
> [ ... ]
>
>> One portable reproduction:
>> # cd /usr/src
>> # less `egrep -lir '^Foo.*baz' *`
>> ^Cload: 0.02 no foreground process group
>>
>> (I typed ^C ^T)
>>
>> SIGKILL to the shell seems to be the only way to get things back to
>> normal.
>
> I've gotten one "me too", which indicated that SIGHUP to the shell
> will also make it go away, but does not solve the problem.
>
> I've got another FreeBSD machine available that was running tcsh
> 6.14.00, and it does _NOT_ display the problem.  When I build
> 6.15.00 on that same box (/usr/src is more up to date than the
> install right now), that does fail.
>
> Thus I'm pretty comfortable saying that it's a tcsh bug of some
> sort, and probably a regression.  Hopefully this can be fixed
> (PR being filed now) before 6.4 releases...

Thanks for the report.  It looks like this is yet another manifestation of 
a problem in tcsh, where it does inappropriate things in a vfork'ed 
subshell.  In my tests, running tcsh with -F (which causes it to use fork 
instead of vfork) causes the problem to go away.  It is also present in 
7.0-RELEASE and probably all later versions.

There are several open bugs related to this problem, but so far they do 
not seem to have attracted the interest of any committers.  Among them 
are:

bin/41297
bin/52746
bin/125185
amd64/128259
bin/129378 (which you just opened)

The fix is simple: make -F the default.  There is a minor performance 
penalty, but that's a small price to pay for correct behavior.  A more 
involved fix would be to make tcsh not do inappropriate things after vfork 
(modifying global variables), or at least clean up before exiting, but 
IMHO that is less clean; vfork really shouldn't be used here at all.

-- 

Nate Eldredge
neldredge@math.ucsd.edu
From neldredge at math.ucsd.edu  Wed Dec  3 16:33:26 2008
From: neldredge at math.ucsd.edu (Nate Eldredge)
Date: Wed Dec  3 16:33:33 2008
Subject: tcsh loses the foreground process group?
In-Reply-To: <Pine.GSO.4.64.0812031541330.1597@zeno.ucsd.edu>
References: <200812022328.mB2NSQa6049527@wattres.watt.com>
	<Pine.GSO.4.64.0812031541330.1597@zeno.ucsd.edu>
Message-ID: <Pine.GSO.4.64.0812031632060.1597@zeno.ucsd.edu>

On Wed, 3 Dec 2008, Nate Eldredge wrote:

> Thanks for the report.  It looks like this is yet another manifestation of a 
> problem in tcsh, where it does inappropriate things in a vfork'ed subshell. 
> In my tests, running tcsh with -F (which causes it to use fork instead of 
> vfork) causes the problem to go away.  It is also present in 7.0-RELEASE and 
> probably all later versions.
>
> There are several open bugs related to this problem, but so far they do not 
> seem to have attracted the interest of any committers.  Among them are:
>
> bin/41297
> bin/52746
> bin/125185
> amd64/128259
> bin/129378 (which you just opened)

I have opened bin/129405 as an omnibus PR for these problems.

-- 

Nate Eldredge
neldredge@math.ucsd.edu
From freebsd-hackers at adam.gs  Wed Dec  3 21:08:26 2008
From: freebsd-hackers at adam.gs (Adam Jacob Muller)
Date: Wed Dec  3 21:08:33 2008
Subject: FreeBSD 7.0-RELEASE amd64 on Dell M600 Blade
In-Reply-To: <f7fabe790809112303p38552a30oa71750c4696e8e99@mail.gmail.com>
References: <FC23644F154C4CAEB820FCEFF307E562@multiplay.co.uk>
	<39DC135F7F0571489196E0B6F5D58B4A03B460D0@MWBEXCH.mweb.com>
	<C148A335177546579649E37BCCB11919@multiplay.co.uk>
	<f7fabe790809112303p38552a30oa71750c4696e8e99@mail.gmail.com>
Message-ID: <BB4FCA74-E0BF-4733-8AC1-58D3E8CC3A4C@adam.gs>


On Sep 12, 2008, at 2:03 AM, Karl Fischer wrote:

> On Fri, Sep 12, 2008 at 01:00, Steven Hartland <killing@multiplay.co.uk 
> > wrote:
>> Thanks Rudi, would really like to get is sorted as they would make
>> ideal app servers.
>>
>> ----- Original Message ----- From: "Rudi Kramer - MWEB" <rkramer@mweb.com 
>> >
>>
>>
>> Hi Steven,
>>
>> We recently purchased a few M600's but haven't got around to loading
>> FBSD on them, we should start installing next week and I will let you
>> know if we run in to any problems.
>
> I have the same problem on my M600 Blades has anyone tested the 7.1  
> Beta and
> I'm about to purchase more of them.
>
> Karl
>
>

Anyone ever get this to work? Perhaps this was fixed in a newer  
FreeBSD? Have some M600 that i'd like to get FreeBSD running on :)

hint.apic.0.disabled seemed to change things a bit, it would reach  
loading mfs root but then lock hard again anyway :/


-Adam

From steve at Watt.COM  Wed Dec  3 22:52:35 2008
From: steve at Watt.COM (Steve Watt)
Date: Wed Dec  3 22:52:41 2008
Subject: tcsh loses the foreground process group?
In-Reply-To: <Pine.GSO.4.64.0812031541330.1597@zeno.ucsd.edu>
References: <200812022328.mB2NSQa6049527@wattres.watt.com>
	<Pine.GSO.4.64.0812031541330.1597@zeno.ucsd.edu>
Message-ID: <20081204065234.GA28327@wattres.Watt.COM>

On Wed, Dec 03, 2008 at 03:58:36PM -0800, Nate Eldredge wrote:
> On Tue, 2 Dec 2008, Steve Watt wrote:
> 
> >In <20081201042037.GA43208@wattres.Watt.COM> Steve Watt wrote:

[ tcsh 6.15.00 ]

> >>The symptom is that when I do a long-ish running task inside a `` 
> >>expansion
> >>that I then ^C, nobody gets the foreground process group...  I never get
> >>a prompt back after the ^C, and ^T gets me
> >>
> >> load: 0.27 no foreground process group
> >
> >I've got another FreeBSD machine available that was running tcsh
> >6.14.00, and it does _NOT_ display the problem.  When I build
> >6.15.00 on that same box (/usr/src is more up to date than the
> >install right now), that does fail.
>
> Thanks for the report.  It looks like this is yet another manifestation of 
> a problem in tcsh, where it does inappropriate things in a vfork'ed 
> subshell.  In my tests, running tcsh with -F (which causes it to use fork 
> instead of vfork) causes the problem to go away.  It is also present in 
> 7.0-RELEASE and probably all later versions.

Did the behavior change between 6.14.00 and 6.15.00?  (Yeah, OK, I can
go look myself.)

OK, I went and looked.  Answer:  Yep, lots of additions of inappropriate
things in backeval().  But it no longer has a 10K limit.

> There are several open bugs related to this problem, but so far they do 
> not seem to have attracted the interest of any committers.  Among them 
> are:
> 
> bin/41297
> bin/52746
> bin/125185
> amd64/128259
> bin/129378 (which you just opened)
> 
> The fix is simple: make -F the default.  There is a minor performance 
> penalty, but that's a small price to pay for correct behavior.  A more 
> involved fix would be to make tcsh not do inappropriate things after vfork 
> (modifying global variables), or at least clean up before exiting, but 
> IMHO that is less clean; vfork really shouldn't be used here at all.

Actually, there's another cost to making -F default:  It makes hashstat
rather less useful.  OK, it's not like it's that useful to begin with,
and is arguably a debugging function, but it's a side effect.

As for a possible "why?" -F changes the hashstat behavior so?  Probably
because it's counting on not-quite-legal vfork() activity.

Ugh.  I'd managed to forget how unfun the code inside that shell is.  I'll
try to forget again.
From bsd.quest at googlemail.com  Thu Dec  4 03:06:40 2008
From: bsd.quest at googlemail.com (Alexej Sokolov)
Date: Thu Dec  4 03:06:47 2008
Subject: vm_map_entry for kernel virtual addres
In-Reply-To: <200812031859.mB3IxHCi046359@casselton.net>
References: <671bb5fc0812031004j28e9bfc4j88df11ce18b436b6@mail.gmail.com>
	<200812031859.mB3IxHCi046359@casselton.net>
Message-ID: <671bb5fc0812040306i67345928wf5124e224d46bd52@mail.gmail.com>

2008/12/3 Mark Tinguely <tinguely@casselton.net>

> >  2008/12/3 Mark Tinguely <tinguely@casselton.net>
> >
> >  > on 3 Dec 2008 15:35:27, Alexej Sokolov <bsd.quest@googlemail.com>
> asked:
> >  >
> >  > >  Hello,
> >  > >  If I allocate memory from a kernel module:
> >  > >  MALLOC(addr, vm_offset_t, PAGE_SIZE, M_DEVBUF, M_WAITOK | M_ZERO);
> >  > >
> >  > >  how can I get a pointer to vm_map_entry structure which describes
> the
> >  > memory
> >  > >  region where "addr" is ?
> >  > >
> >  > >  Thanks,
> >  > >  Alexey
> >  >
> >  > MALLOC is a macro for malloc() which returns a kernel virtual address
> into
> >  > the variable addr in this case.
> >  >
> >  > You want to find the vm_map_entry, use something like:
> >  >
> >  >        vm_map_entry_t *result;
> >  >        if (vm_map_lookup_entry(kernel_map, addr, result)) {
> >  >                /* found */
> >  >        } else {
> >  >                /* not found */
> >  >        }
> >
> >
> >  1. Should i use any locks or mutex for doing it ?
>
>  Good question, it really should be:
>
>        vm_map_lock(map);
>
> >  2. What map is used by MALLOC? It can be a some submap. Should i use
> then a
> >  submap for searching entry?
>
> I thought originally that malloc() allocated memory from kernel map
> (kernel_map), but on closer inspection, malloc() seems to use the
> default UMA zone allocator [page_alloc()] which takes the memory from
> the kmem_map. Which I should have know, big mallocs fill the kmem space.
> sooo I guess the more correct code would be:
>
>        vm_map_entry_t result;
>        vm_map_lock(kmem_map);
>        if (vm_map_lookup_entry(kmem_map, addr, &result)) {
>                /* found */
>        } else {
>                /* not found */
>        }
>        vm_map_unlock(kmem_map);
>
> Ok, thanks a lot!
From yanefbsd at gmail.com  Thu Dec  4 03:27:36 2008
From: yanefbsd at gmail.com (Garrett Cooper)
Date: Thu Dec  4 03:27:42 2008
Subject: AMD64 qemu completely broken?
In-Reply-To: <5f67a8c40812021718i4cc225fem5b02a448702ec606@mail.gmail.com>
References: <5f67a8c40812021718i4cc225fem5b02a448702ec606@mail.gmail.com>
Message-ID: <7d6fde3d0812040327w7c92826i64c6073a453d65ef@mail.gmail.com>

On Tue, Dec 2, 2008 at 5:18 PM, Zaphod Beeblebrox <zbeeble@gmail.com> wrote:
> I decided to take the comments about testing ZFS to heart --- so I decided
> to try copying my 7.0 "v6" ZFS configuration into a qemu instance and
> upgrading it.  To do this, I carefully copied my UFS boot partition and my
> ZFS partion to a physical USB disk that I could put on a system to do the
> test.
>
> After compiling qemu and loading the kqemu and aio kernel module, I started
> the emulator, first in VNC mode.  It loaded the kernel (currently 7.1-RC)
> and tried to boot, but kept failing either shortly after kbdmux detected a
> keyboard or it would get through to mounting root and not find any drives.
> For reference, besides the display option (ie: -vnc or whatever), my command
> line was:
>
> qemu-system-x86_64 -hda /dev/da0 -snapshot -m 512
>
> I couldn't scroll back in VNC mode using the pause/break key, so I tried to
> get qemu running directly in X.
>
> Now... I see a few posts stating that running qemu remotely causes an X
> protocol error.  I can confirm that.  Something about Qemu's use of X will
> no work over an SSH remote connection (with -X), nor will it work with
> dxpc.  It dies for me every time at X event sequence number 22.  Xterms
> work.  Gimp even works.  qemu does not.
>
> So I got a vnc server running to run it locally.
>
> And now it crashes reliably in one spot.  boot0 and boot1 don't recognize
> the keyboard ... but the press space after crash does.  Besides that quirk,
> the 7.1-RC kernel crashes with the following transcript reliably:
>
> MADT: Forcing active-low polarity and level trigger for SCI
> kbd1 at kbdmux0
> ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413)
>
>
> Fatal trap 9: general protection fault while in kernel mode
> cpuid = 0; apic id=00
> instruction pointer             = 0x8:0xffff
>
> ... and so on.
>
> I'd like to test this... has anyone any successes with the AMD64 qemu?

Are you running the ports version, or a different version, and/or are
you using kqemu (I've heard this was broken, in the past)? My group at
Cisco has several issues with older versions of qemu for PPC and when
we applied patches, it improved support greatly in some cases, and
introduced bugs in other cases =\.

I'd definitely hit the devel list for QEMU and see what they say while
you're waiting for a more substantial reply here.

Cheers,
-Garrett
From yanefbsd at gmail.com  Thu Dec  4 03:30:02 2008
From: yanefbsd at gmail.com (Garrett Cooper)
Date: Thu Dec  4 03:30:21 2008
Subject: Help debugging, machine won't boot anymore.
In-Reply-To: <20081202165258.GM12776@gremlin.foo.is>
References: <20081202165258.GM12776@gremlin.foo.is>
Message-ID: <7d6fde3d0812040330n362bd709t1232a9b6a932d11c@mail.gmail.com>

On Tue, Dec 2, 2008 at 8:52 AM, Baldur Gislason <baldur@foo.is> wrote:
> I have a machine running 7.0-STABLE/amd64 and it has suddenly
> stopped booting. It just leaves me at the debugger with this message:
>
> Fatal trap 9: general protection fault while in kernel mode
> cpuid = 0; apic id = 00
> instruction pointer     = 0x8:0xffffffff804d913d
> stack pointer           = 0x10:0xffffffff80c9ec10
> frame pointer           = 0x10:0xffffffff80c9ec70
> 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         = 0 (swapper)
> [thread pid 0 tid 0 ]
> Stopped at      device_probe_child+0x61:        movq    0x28(%rax),%rsi
> db>
>
> dmesg at http://foo.is/~baldur/enigmaboot.txt
> The ACPI warning has always been there.
>
> Any places of interest in the debugger? What's a likely culprit? bad RAM?
>
> Baldur

As the stopped area suggests, it looks like it's stuck probing a
device. Have you added any new hardware to your system recently? Have
you checked the connections internally in the machine? Does all of the
hardware work with a vanilla livefs 7.0-RELEASE CD?
-Garrett
From bsd.quest at googlemail.com  Thu Dec  4 04:27:28 2008
From: bsd.quest at googlemail.com (Alexej Sokolov)
Date: Thu Dec  4 04:27:34 2008
Subject: kernel vm_submap's
Message-ID: <671bb5fc0812040427n6ff9a88fy7bf1cdc6382db8db@mail.gmail.com>

Hello,
Where/How can I get information about vm_submap's in the actual stable
kernel:
% uname -v
FreeBSD 7.0-RELEASE-p5 #0: Tue Oct  7 19:05:20 CEST 2008
And what kind of data is present in these submaps (mallocs, mbufs,
DMA-buffer..)?

Thanks,
From pluknet at gmail.com  Thu Dec  4 06:25:49 2008
From: pluknet at gmail.com (pluknet)
Date: Thu Dec  4 06:25:55 2008
Subject: kernel vm_submap's
In-Reply-To: <671bb5fc0812040427n6ff9a88fy7bf1cdc6382db8db@mail.gmail.com>
References: <671bb5fc0812040427n6ff9a88fy7bf1cdc6382db8db@mail.gmail.com>
Message-ID: <a31046fc0812040625m29aaac4dlcb6bcd9de38a5e7b@mail.gmail.com>

2008/12/4 Alexej Sokolov <bsd.quest@googlemail.com>:
> Hello,
> Where/How can I get information about vm_submap's in the actual stable
> kernel:
> % uname -v
> FreeBSD 7.0-RELEASE-p5 #0: Tue Oct  7 19:05:20 CEST 2008
> And what kind of data is present in these submaps (mallocs, mbufs,
> DMA-buffer..)?
>

vm_map_submap(9) might help you.
btw, it's called only from one place I can find: kmem_suballoc.

> Thanks,

-- 
wbr,
pluknet
From bsd.quest at googlemail.com  Thu Dec  4 08:33:01 2008
From: bsd.quest at googlemail.com (Alexej Sokolov)
Date: Thu Dec  4 08:33:08 2008
Subject: kernel vm_submap's
In-Reply-To: <a31046fc0812040625m29aaac4dlcb6bcd9de38a5e7b@mail.gmail.com>
References: <671bb5fc0812040427n6ff9a88fy7bf1cdc6382db8db@mail.gmail.com>
	<a31046fc0812040625m29aaac4dlcb6bcd9de38a5e7b@mail.gmail.com>
Message-ID: <671bb5fc0812040832x6ff884cbv805bddb3d1471671@mail.gmail.com>

2008/12/4 pluknet <pluknet@gmail.com>

> 2008/12/4 Alexej Sokolov <bsd.quest@googlemail.com>:
>  > Hello,
> > Where/How can I get information about vm_submap's in the actual stable
> > kernel:
> > % uname -v
> > FreeBSD 7.0-RELEASE-p5 #0: Tue Oct  7 19:05:20 CEST 2008
> > And what kind of data is present in these submaps (mallocs, mbufs,
> > DMA-buffer..)?
> >
>
> vm_map_submap(9) might help you.
> btw, it's called only from one place I can find: kmem_suballoc.

Ok, then the next question: If I have some kernel virtual addres, what is
the best way to find out which submap it belongs to?


>
>
> > Thanks,
>
> --
> wbr,
> pluknet
>
From zbeeble at gmail.com  Thu Dec  4 09:52:35 2008
From: zbeeble at gmail.com (Zaphod Beeblebrox)
Date: Thu Dec  4 09:52:42 2008
Subject: AMD64 qemu completely broken?
In-Reply-To: <7d6fde3d0812040327w7c92826i64c6073a453d65ef@mail.gmail.com>
References: <5f67a8c40812021718i4cc225fem5b02a448702ec606@mail.gmail.com>
	<7d6fde3d0812040327w7c92826i64c6073a453d65ef@mail.gmail.com>
Message-ID: <5f67a8c40812040952u1364563awcfd493695e7fea7c@mail.gmail.com>

On Thu, Dec 4, 2008 at 6:27 AM, Garrett Cooper <yanefbsd@gmail.com> wrote:

>
> Are you running the ports version, or a different version, and/or are
> you using kqemu (I've heard this was broken, in the past)? My group at
> Cisco has several issues with older versions of qemu for PPC and when
> we applied patches, it improved support greatly in some cases, and
> introduced bugs in other cases =\.
>
> I'd definitely hit the devel list for QEMU and see what they say while
> you're waiting for a more substantial reply here.


I'm using the ports version.  I am using kqemu... although I can try without
the kernel module later today.

How out-of-date is the port?
From avg at icyb.net.ua  Thu Dec  4 10:41:18 2008
From: avg at icyb.net.ua (Andriy Gapon)
Date: Thu Dec  4 10:41:31 2008
Subject: ichwd problem: watchdog doesn't "bark"
In-Reply-To: <49300020.6060603@icyb.net.ua>
References: <49300020.6060603@icyb.net.ua>
Message-ID: <49382449.80002@icyb.net.ua>

on 28/11/2008 16:28 Andriy Gapon said the following:
> uname:
> FreeBSD 7.1-PRERELEASE r185311 amd64
> 
> dmesg:
> ichwd0: <Intel ICH9R watchdog timer> on isa0
> ichwd0: Intel ICH9R watchdog timer (ICH9 or equivalent)
> ichwd0: timer disabled
> 
> pciconf:
> isab0@pci0:0:31:0:      class=0x060100 card=0x50448086 chip=0x29168086
> rev=0x02 hdr=0x00
>     vendor     = 'Intel Corporation'
>     device     = '82801IR (ICH9R) LPC Interface Controller'
>     class      = bridge
>     subclass   = PCI-ISA
> 
> 
> When I start watchdogd I see the following messages:
> timer enabled
> timeout set to 28 ticks
> and then a flow of messages:
> timer reloaded
> 
> Then I kill -9 watchdogd.
> "timer reloded" messages are no longer produced.
> And there are no other messages.
> 
> But nothing happens for many minutes that I waited.
> 

BTW, can someone knowledgeable tell me if watchdog better be firing SMI
or NMI when it runs down?
My bet is on NMI, but who knows.
Thanks!

Or maybe I am trying to ask a different question.
I see that NMI2SMI_EN bit of TCO1_CNT is set 1 on my machine and our
watchdog driver is careful to preserve this bit unmodified.
This means that watchdog would try to cause SMI instead of NMI.
On the other hand I see that bit GBL_SMI_EN of SMI_EN is set to zero,
which means that chipset would never generate an SMI.
So I think this is why I don't see anything happening.

Now, would should try first - reset NMI2SMI_EN to zero or set GBL_SMI_EN
to 1?

As additional data points: I see that TCO_EN bit of SMI_EN is 1 and it
is locked to that value because TCO_LOCK bit of TCO1_CNT is 1.
SMI_LOCK in PCI config register GEN_PMCON_1 is not set.

-- 
Andriy Gapon
From avg at icyb.net.ua  Thu Dec  4 10:42:39 2008
From: avg at icyb.net.ua (Andriy Gapon)
Date: Thu Dec  4 10:42:46 2008
Subject: dd if=/dev/mem can hang a machine?
In-Reply-To: <4933BAD3.2060700@icyb.net.ua>
References: <200811302014.mAUKE5YF046736@fire.js.berklix.net>
	<4933BAD3.2060700@icyb.net.ua>
Message-ID: <4938249A.20300@icyb.net.ua>


BTW, I think it was related to reading memory-mapped registers intended
to put CPU into Cx states (x >= 2).

-- 
Andriy Gapon
From yanefbsd at gmail.com  Thu Dec  4 11:05:06 2008
From: yanefbsd at gmail.com (Garrett Cooper)
Date: Thu Dec  4 11:05:12 2008
Subject: AMD64 qemu completely broken?
In-Reply-To: <5f67a8c40812040952u1364563awcfd493695e7fea7c@mail.gmail.com>
References: <5f67a8c40812021718i4cc225fem5b02a448702ec606@mail.gmail.com>
	<7d6fde3d0812040327w7c92826i64c6073a453d65ef@mail.gmail.com>
	<5f67a8c40812040952u1364563awcfd493695e7fea7c@mail.gmail.com>
Message-ID: <7d6fde3d0812041105h43cf6586r5092e234a6350310@mail.gmail.com>

On Thu, Dec 4, 2008 at 9:52 AM, Zaphod Beeblebrox <zbeeble@gmail.com> wrote:
> On Thu, Dec 4, 2008 at 6:27 AM, Garrett Cooper <yanefbsd@gmail.com> wrote:
>>
>> Are you running the ports version, or a different version, and/or are
>> you using kqemu (I've heard this was broken, in the past)? My group at
>> Cisco has several issues with older versions of qemu for PPC and when
>> we applied patches, it improved support greatly in some cases, and
>> introduced bugs in other cases =\.
>>
>> I'd definitely hit the devel list for QEMU and see what they say while
>> you're waiting for a more substantial reply here.
>
> I'm using the ports version.  I am using kqemu... although I can try without
> the kernel module later today.
>
> How out-of-date is the port?

1. Try without kqemu :) (or at least rebuild it, then disable it if
you continue to run into problems).
2. emulators/qemu is the latest stable, but there are typically a
number of changes floating out in the devel branch
(emulators/qemu-devel) that might be of interest to you:

[root@optimus /store]# grep -r ^PORTVERSION /usr/ports/emulators/qemu*
/usr/ports/emulators/qemu/Makefile:PORTVERSION= 0.9.1
/usr/ports/emulators/qemu-devel/Makefile:PORTVERSION=   0.9.1s.20080620

-Garrett
From tjaviss at gmail.com  Thu Dec  4 12:21:06 2008
From: tjaviss at gmail.com (Tyler Aviss)
Date: Thu Dec  4 12:42:39 2008
Subject: Issues with 7.0-RELEASE-p2 and netstat/ld.elf.so-1
Message-ID: <3a97ef0812041200yb85a426g3f8dc75dec513fe7@mail.gmail.com>

When running netstat on many boxes with this version of BSD, I'm
seeing funky errors in my /var/log/messages, such as:


Dec  4 14:55:49 server10 kernel: up_symbol
Dec  4 14:55:49 server10 kernel: : missing
Dec  4 14:55:49 server10 kernel: symbol h
Dec  4 14:55:49 server10 kernel: ash tabl
Dec  4 14:55:49 server10 kernel: e
Dec  4 14:55:49 server10 kernel:

I've traced this to whenever netstat runs. Unfortunately the box in
question is "inherited" from a previous admin, and I don't have any
other boxes that I've setup to check these files against. Can anyone
running 7.0-release-p2 verify these MD5's?

MD5 (/usr/bin/netstat) = e9e062b6523f2ccbc5befc8b52584346
MD5 (/libexec/ld-elf.so.1) = 86610ef79a07643572603c9b09b1af53


Thanks!

Tyler Aviss
From nox at jelal.kn-bremen.de  Thu Dec  4 13:10:23 2008
From: nox at jelal.kn-bremen.de (Juergen Lock)
Date: Thu Dec  4 13:17:30 2008
Subject: AMD64 qemu completely broken?
In-Reply-To: <7d6fde3d0812041105h43cf6586r5092e234a6350310@mail.gmail.com>
References: <5f67a8c40812021718i4cc225fem5b02a448702ec606@mail.gmail.com>
	<7d6fde3d0812040327w7c92826i64c6073a453d65ef@mail.gmail.com>
	<5f67a8c40812040952u1364563awcfd493695e7fea7c@mail.gmail.com>
Message-ID: <200812042046.mB4KkC0k016853@saturn.kn-bremen.de>

In article <7d6fde3d0812041105h43cf6586r5092e234a6350310@mail.gmail.com> you write:
>On Thu, Dec 4, 2008 at 9:52 AM, Zaphod Beeblebrox <zbeeble@gmail.com> wrote:
>> On Thu, Dec 4, 2008 at 6:27 AM, Garrett Cooper <yanefbsd@gmail.com> wrote:
>>>
>>> Are you running the ports version, or a different version, and/or are
>>> you using kqemu (I've heard this was broken, in the past)? My group at
>>> Cisco has several issues with older versions of qemu for PPC and when
>>> we applied patches, it improved support greatly in some cases, and
>>> introduced bugs in other cases =\.
>>>
>>> I'd definitely hit the devel list for QEMU and see what they say while
>>> you're waiting for a more substantial reply here.
>>
>> I'm using the ports version.  I am using kqemu... although I can try without
>> the kernel module later today.
>>
>> How out-of-date is the port?
>
>1. Try without kqemu :) (or at least rebuild it, then disable it if
>you continue to run into problems).
>2. emulators/qemu is the latest stable, but there are typically a
>number of changes floating out in the devel branch
>(emulators/qemu-devel) that might be of interest to you:
>
>[root@optimus /store]# grep -r ^PORTVERSION /usr/ports/emulators/qemu*
>/usr/ports/emulators/qemu/Makefile:PORTVERSION= 0.9.1
>/usr/ports/emulators/qemu-devel/Makefile:PORTVERSION=   0.9.1s.20080620

Yes, qemu-devel is worth a try.  I also post experimental port updates
on -emulation once in a while that bring the qemu-devel port to more recent
svn snapshots, like here:
	http://lists.freebsd.org/pipermail/freebsd-emulation/2008-November/005530.html

 Oh and btw -kernel-kqemu is known to be broken with FreeBSD/amd64 guests,
I was still able to boot 7.1-BETA2-amd64-livefs.iso into fixit->cdrom
and try a few things in there using `regular' (userland) kqemu and my
latest qemu-devel snapshot tho.

 HTH,
	Juergen
From jhb at freebsd.org  Thu Dec  4 13:25:23 2008
From: jhb at freebsd.org (John Baldwin)
Date: Thu Dec  4 13:25:46 2008
Subject: Help debugging, machine won't boot anymore.
In-Reply-To: <20081202165258.GM12776@gremlin.foo.is>
References: <20081202165258.GM12776@gremlin.foo.is>
Message-ID: <200812041506.22371.jhb@freebsd.org>

On Tuesday 02 December 2008 11:52:58 am Baldur Gislason wrote:
> I have a machine running 7.0-STABLE/amd64 and it has suddenly
> stopped booting. It just leaves me at the debugger with this message:
> 
> Fatal trap 9: general protection fault while in kernel mode
> cpuid = 0; apic id = 00
> instruction pointer     = 0x8:0xffffffff804d913d
> stack pointer           = 0x10:0xffffffff80c9ec10
> frame pointer           = 0x10:0xffffffff80c9ec70
> 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         = 0 (swapper)
> [thread pid 0 tid 0 ]
> Stopped at      device_probe_child+0x61:        movq    0x28(%rax),%rsi
> db>
> 
> dmesg at http://foo.is/~baldur/enigmaboot.txt
> The ACPI warning has always been there.
> 
> Any places of interest in the debugger? What's a likely culprit? bad RAM?

I would get a stack trace first.

-- 
John Baldwin
From nox at jelal.kn-bremen.de  Thu Dec  4 13:25:04 2008
From: nox at jelal.kn-bremen.de (Juergen Lock)
Date: Thu Dec  4 13:46:14 2008
Subject: AMD64 qemu completely broken?
In-Reply-To: <200812042046.mB4KkC0k016853@saturn.kn-bremen.de>
References: <5f67a8c40812021718i4cc225fem5b02a448702ec606@mail.gmail.com>
	<7d6fde3d0812040327w7c92826i64c6073a453d65ef@mail.gmail.com>
	<5f67a8c40812040952u1364563awcfd493695e7fea7c@mail.gmail.com>
	<200812042046.mB4KkC0k016853@saturn.kn-bremen.de>
Message-ID: <20081204212311.GA17962@saturn.kn-bremen.de>

On Thu, Dec 04, 2008 at 09:46:12PM +0100, I wrote:
> In article <7d6fde3d0812041105h43cf6586r5092e234a6350310@mail.gmail.com> you write:
> >On Thu, Dec 4, 2008 at 9:52 AM, Zaphod Beeblebrox <zbeeble@gmail.com> wrote:
> >> On Thu, Dec 4, 2008 at 6:27 AM, Garrett Cooper <yanefbsd@gmail.com> wrote:
> >>>
> >>> Are you running the ports version, or a different version, and/or are
> >>> you using kqemu (I've heard this was broken, in the past)? My group at
> >>> Cisco has several issues with older versions of qemu for PPC and when
> >>> we applied patches, it improved support greatly in some cases, and
> >>> introduced bugs in other cases =\.
> >>>
> >>> I'd definitely hit the devel list for QEMU and see what they say while
> >>> you're waiting for a more substantial reply here.
> >>
> >> I'm using the ports version.  I am using kqemu... although I can try without
> >> the kernel module later today.
> >>
> >> How out-of-date is the port?
> >
> >1. Try without kqemu :) (or at least rebuild it, then disable it if
> >you continue to run into problems).
> >2. emulators/qemu is the latest stable, but there are typically a
> >number of changes floating out in the devel branch
> >(emulators/qemu-devel) that might be of interest to you:
> >
> >[root@optimus /store]# grep -r ^PORTVERSION /usr/ports/emulators/qemu*
> >/usr/ports/emulators/qemu/Makefile:PORTVERSION= 0.9.1
> >/usr/ports/emulators/qemu-devel/Makefile:PORTVERSION=   0.9.1s.20080620
> 
> Yes, qemu-devel is worth a try.  I also post experimental port updates
> on -emulation once in a while that bring the qemu-devel port to more recent
> svn snapshots, like here:
> 	http://lists.freebsd.org/pipermail/freebsd-emulation/2008-November/005530.html
> 
>  Oh and btw -kernel-kqemu is known to be broken with FreeBSD/amd64 guests,
> I was still able to boot 7.1-BETA2-amd64-livefs.iso into fixit->cdrom
> and try a few things in there using `regular' (userland) kqemu and my
> latest qemu-devel snapshot tho.

I forgot to say the qemu-devel port (as well as the later snapshots I
posted about on -emulation) also support -curses, which shows the emulated
vga text(!)console on qemu's tty.  This works quite well with FreeBSD guests
(even the isos) if you extend your xterm/whatever by one line (the default
vga textconsole is 80x25 instead of 80x24.)

 Of course if you have an installed guest you can also configure it for a
serial console (in a FreeBSD guest:)
	# echo console=\"comconsole\" >>/boot/loader.conf
	# sed -i -e '/^ttyd0/s/off/on/' /etc/ttys
and from then on run qemu with -nographic.  (with -nographic, the guest's
serial console and qemu's monitor are multiplexed on qemu's tty, hit ctrl-a
and then `h' to show a small help.)  -nographic also works with older
qemu versions.

 HTH,
	Juergen
From neldredge at math.ucsd.edu  Thu Dec  4 14:43:48 2008
From: neldredge at math.ucsd.edu (Nate Eldredge)
Date: Thu Dec  4 14:43:55 2008
Subject: AMD64 qemu completely broken?
In-Reply-To: <20081204212311.GA17962@saturn.kn-bremen.de>
References: <5f67a8c40812021718i4cc225fem5b02a448702ec606@mail.gmail.com>
	<7d6fde3d0812040327w7c92826i64c6073a453d65ef@mail.gmail.com>
	<5f67a8c40812040952u1364563awcfd493695e7fea7c@mail.gmail.com>
	<200812042046.mB4KkC0k016853@saturn.kn-bremen.de>
	<20081204212311.GA17962@saturn.kn-bremen.de>
Message-ID: <Pine.GSO.4.64.0812041428400.22402@zeno.ucsd.edu>

On Thu, 4 Dec 2008, Juergen Lock wrote:

> I forgot to say the qemu-devel port (as well as the later snapshots I
> posted about on -emulation) also support -curses, which shows the emulated
> vga text(!)console on qemu's tty.  This works quite well with FreeBSD guests
> (even the isos) if you extend your xterm/whatever by one line (the default
> vga textconsole is 80x25 instead of 80x24.)

As long as we're sharing tips about qemu:

I've recently been working with qemu on amd64 and have set up a Debian 
etch i386 guest which is working well.  I am using the qemu-devel and 
kqemu-kmod-devel ports.  I am not using -kernel-kqemu at the moment; I 
thought I would get things working before trying to speed up.

Using qemu I've finally achieved my goal of being able to use flash on 
FreeBSD/amd64 (in some sense :-O).

savevm and loadvm don't work due to a security patch.  Since my guest 
system is trusted I reverted the patch.  I filed a PR as ports/129417 .

I found that '-net user' is horribly broken on amd64 (qemu segfaults). 
It uses some ancient [*] BSD TCP/IP code (via slirp) which assumes that 
pointers are 32 bits and doesn't hesitate to shove them into random 32-bit 
corners of externally defined structures if it's convenient.  Looks like a 
pain to clean up.  '-net tap' works fine, but requires root privileges and 
is more work to set up.

[*] Out of curiosity, I looked at some Unix Archive stuff and found the 
identical code in BSD's Net2, circa 1991.  It is identified in a comment 
as a "quick hack" and adorned with several /* XXX */.  Naturally the code 
and the comments survive intact, 17 years later. :-(

-- 

Nate Eldredge
neldredge@math.ucsd.edu
From ravi.murty at gmail.com  Thu Dec  4 16:45:54 2008
From: ravi.murty at gmail.com (Ravi Murty)
Date: Thu Dec  4 16:46:01 2008
Subject: local APIC 2 interrupt fifo limit
Message-ID: <95b10a340812041645t770b1d8sc7802773ab6beff2@mail.gmail.com>

Hello,

There is this comment in apicvar.h in the amd64 tree that talks about why
the kernel uses smp_ipi_mtx and how it prevents more than 2 outstanding IPIs
per interrupt vector. It appears that modern CPUs collapse the IRR bit if
there is an interrupt when both the IRR and ISR bits are set. I was
wondering why we need smp_ipi_mtx besides the fact that the kernel uses
global variables for things like invalidate page ranges.

Thanks,
Ravi
From perryh at pluto.rain.com  Fri Dec  5 00:20:43 2008
From: perryh at pluto.rain.com (perryh@pluto.rain.com)
Date: Fri Dec  5 00:20:49 2008
Subject: ichwd problem: watchdog doesn't "bark"
In-Reply-To: <49382449.80002@icyb.net.ua>
References: <49300020.6060603@icyb.net.ua> <49382449.80002@icyb.net.ua>
Message-ID: <4938e20c.nP8q+JgDZ0gKUsAU%perryh@pluto.rain.com>

[dropped stable@ since I'm not on it and
 I suspect it may not accept non-member posts]

> BTW, can someone knowledgeable tell me if watchdog better
> be firing SMI or NMI when it runs down?
> My bet is on NMI, but who knows.

It may depend on whether you want the BIOS, or FreeBSD, handling
the interrupt.  Unless you are running *very* old h/w, there's a
good chance the BIOS intercepts SMI, even with a protected-mode
OS running, and I wouldn't be surprised if the BIOS' response to
a watchdog timeout were an immediate reboot.  It might be good
to check the motherboard and/or BIOS manuals.

> Or maybe I am trying to ask a different question.
> I see that NMI2SMI_EN bit of TCO1_CNT is set 1 on my machine and
> our watchdog driver is careful to preserve this bit unmodified.
> This means that watchdog would try to cause SMI instead of NMI.
> On the other hand I see that bit GBL_SMI_EN of SMI_EN is set to
> zero, which means that chipset would never generate an SMI.
> So I think this is why I don't see anything happening.
>
> Now, would should try first - reset NMI2SMI_EN to zero or set
> GBL_SMI_EN to 1?

If you want to handle the interrupt in FreeBSD, I'd try resetting
NMI2SMI_EN to zero.
From yanefbsd at gmail.com  Fri Dec  5 00:35:32 2008
From: yanefbsd at gmail.com (Garrett Cooper)
Date: Fri Dec  5 00:35:38 2008
Subject: RFC: small syscons and kbd patch
In-Reply-To: <7d6fde3d0812050034y43a70ce8i49fbba92f9c8943b@mail.gmail.com>
References: <bb4a86c70812021701i621fdcfjb6a58a7f5cf781d5@mail.gmail.com>
	<7d6fde3d0812040324y3bf0901cy1f4a6d961362c314@mail.gmail.com>
	<bb4a86c70812040724w43ddec15yab72920d80d879d3@mail.gmail.com>
	<20081205072229.GE18652@hoeg.nl>
	<7d6fde3d0812050034y43a70ce8i49fbba92f9c8943b@mail.gmail.com>
Message-ID: <7d6fde3d0812050035u6e3ea930o9e093830a8608444@mail.gmail.com>

On Thu, Dec 4, 2008 at 11:22 PM, Ed Schouten <ed@80386.nl> wrote:
> * Maksim Yevmenkin <maksim.yevmenkin@gmail.com> wrote:
>> the idea was to ensure that kbd->kb_locked variable only takes values
>> 0 (zero) and 1 (one).
>
> I often use constructs like these to do that:
>
>        foo = bar ? 1 : 0;
>
> Maybe !!bar is a lot shorter to write, I think the line above is a lot
> easier to read.

Indeed. I had no idea (and I would assume that many people wouldn't in
my similar level of systems programming) what in the work you were
trying to do above with that line. The one-line conditional is
universal in almost all major high-level language dialects I've hit,
minus Python and Tcl.
-Garrett
From yanefbsd at gmail.com  Fri Dec  5 00:38:21 2008
From: yanefbsd at gmail.com (Garrett Cooper)
Date: Fri Dec  5 00:38:27 2008
Subject: ichwd problem: watchdog doesn't "bark"
In-Reply-To: <4938e20c.nP8q+JgDZ0gKUsAU%perryh@pluto.rain.com>
References: <49300020.6060603@icyb.net.ua> <49382449.80002@icyb.net.ua>
	<4938e20c.nP8q+JgDZ0gKUsAU%perryh@pluto.rain.com>
Message-ID: <7d6fde3d0812050038m766ecd92j352ab33bc37b6c8e@mail.gmail.com>

On Fri, Dec 5, 2008 at 12:10 AM,  <perryh@pluto.rain.com> wrote:
> [dropped stable@ since I'm not on it and
>  I suspect it may not accept non-member posts]
>
>> BTW, can someone knowledgeable tell me if watchdog better
>> be firing SMI or NMI when it runs down?
>> My bet is on NMI, but who knows.
>
> It may depend on whether you want the BIOS, or FreeBSD, handling
> the interrupt.  Unless you are running *very* old h/w, there's a
> good chance the BIOS intercepts SMI, even with a protected-mode
> OS running, and I wouldn't be surprised if the BIOS' response to
> a watchdog timeout were an immediate reboot.  It might be good
> to check the motherboard and/or BIOS manuals.

Yeah. I just recently have embarked on an adventure of installing
FreeBSD on my work T61 laptop, and while poking around the BIOS I
discovered that NMI could be enabled or disabled, so I'd determine
whether or not that feature is available, and see if it's turned on or
off.

Intel and/or the laptop vendor should be helpful in this pursuit.

-Garrett
From ertr1013 at student.uu.se  Fri Dec  5 00:44:45 2008
From: ertr1013 at student.uu.se (Erik Trulsson)
Date: Fri Dec  5 00:44:51 2008
Subject: RFC: small syscons and kbd patch
In-Reply-To: <7d6fde3d0812050035u6e3ea930o9e093830a8608444@mail.gmail.com>
References: <bb4a86c70812021701i621fdcfjb6a58a7f5cf781d5@mail.gmail.com>
	<7d6fde3d0812040324y3bf0901cy1f4a6d961362c314@mail.gmail.com>
	<bb4a86c70812040724w43ddec15yab72920d80d879d3@mail.gmail.com>
	<20081205072229.GE18652@hoeg.nl>
	<7d6fde3d0812050034y43a70ce8i49fbba92f9c8943b@mail.gmail.com>
	<7d6fde3d0812050035u6e3ea930o9e093830a8608444@mail.gmail.com>
Message-ID: <20081205084441.GA29312@owl.midgard.homeip.net>

On Fri, Dec 05, 2008 at 12:35:31AM -0800, Garrett Cooper wrote:
> On Thu, Dec 4, 2008 at 11:22 PM, Ed Schouten <ed@80386.nl> wrote:
> > * Maksim Yevmenkin <maksim.yevmenkin@gmail.com> wrote:
> >> the idea was to ensure that kbd->kb_locked variable only takes values
> >> 0 (zero) and 1 (one).
> >
> > I often use constructs like these to do that:
> >
> >        foo = bar ? 1 : 0;
> >
> > Maybe !!bar is a lot shorter to write, I think the line above is a lot
> > easier to read.
> 
> Indeed. I had no idea (and I would assume that many people wouldn't in
> my similar level of systems programming) what in the work you were
> trying to do above with that line. The one-line conditional is
> universal in almost all major high-level language dialects I've hit,
> minus Python and Tcl.
> -Garrett

The !!bar construction to map {0, not-0} to {0,1} is fairly common in C
programming, and I would certainly expect any experienced C programmer to
recognize it.




-- 
<Insert your favourite quote here.>
Erik Trulsson
ertr1013@student.uu.se
From yanefbsd at gmail.com  Fri Dec  5 00:50:39 2008
From: yanefbsd at gmail.com (Garrett Cooper)
Date: Fri Dec  5 00:50:50 2008
Subject: RFC: small syscons and kbd patch
In-Reply-To: <20081205084441.GA29312@owl.midgard.homeip.net>
References: <bb4a86c70812021701i621fdcfjb6a58a7f5cf781d5@mail.gmail.com>
	<7d6fde3d0812040324y3bf0901cy1f4a6d961362c314@mail.gmail.com>
	<bb4a86c70812040724w43ddec15yab72920d80d879d3@mail.gmail.com>
	<20081205072229.GE18652@hoeg.nl>
	<7d6fde3d0812050034y43a70ce8i49fbba92f9c8943b@mail.gmail.com>
	<7d6fde3d0812050035u6e3ea930o9e093830a8608444@mail.gmail.com>
	<20081205084441.GA29312@owl.midgard.homeip.net>
Message-ID: <7d6fde3d0812050050l57684eebkf14f252d78b68ec0@mail.gmail.com>

On Fri, Dec 5, 2008 at 12:44 AM, Erik Trulsson <ertr1013@student.uu.se> wrote:
> On Fri, Dec 05, 2008 at 12:35:31AM -0800, Garrett Cooper wrote:
>> On Thu, Dec 4, 2008 at 11:22 PM, Ed Schouten <ed@80386.nl> wrote:
>> > * Maksim Yevmenkin <maksim.yevmenkin@gmail.com> wrote:
>> >> the idea was to ensure that kbd->kb_locked variable only takes values
>> >> 0 (zero) and 1 (one).
>> >
>> > I often use constructs like these to do that:
>> >
>> >        foo = bar ? 1 : 0;
>> >
>> > Maybe !!bar is a lot shorter to write, I think the line above is a lot
>> > easier to read.
>>
>> Indeed. I had no idea (and I would assume that many people wouldn't in
>> my similar level of systems programming) what in the work you were
>> trying to do above with that line. The one-line conditional is
>> universal in almost all major high-level language dialects I've hit,
>> minus Python and Tcl.
>> -Garrett
>
> The !!bar construction to map {0, not-0} to {0,1} is fairly common in C
> programming, and I would certainly expect any experienced C programmer to
> recognize it.

(I feel like I'm getting off on a bikeshed topic, but...)

1. What dialect of C was it defined in? Is it still used in the
standard dialect (honestly, this is the first time I've ever seen it
before, but then again I am a younger generation user)?
2. Is it still taught in schools (I didn't learn it when I was taught
C)? If not in schools, what about the Richie text (it's sort of like
the defacto C programming standard book of course)?
3. What's the real loss of going to `? :', beyond maybe 3 extra
keystrokes if it's easier for folks who may not be as experienced to
read?

-Garrett
From christoph.mallon at gmx.de  Fri Dec  5 01:11:22 2008
From: christoph.mallon at gmx.de (Christoph Mallon)
Date: Fri Dec  5 01:11:29 2008
Subject: RFC: small syscons and kbd patch
In-Reply-To: <7d6fde3d0812050050l57684eebkf14f252d78b68ec0@mail.gmail.com>
References: <bb4a86c70812021701i621fdcfjb6a58a7f5cf781d5@mail.gmail.com>	<7d6fde3d0812040324y3bf0901cy1f4a6d961362c314@mail.gmail.com>	<bb4a86c70812040724w43ddec15yab72920d80d879d3@mail.gmail.com>	<20081205072229.GE18652@hoeg.nl>	<7d6fde3d0812050034y43a70ce8i49fbba92f9c8943b@mail.gmail.com>	<7d6fde3d0812050035u6e3ea930o9e093830a8608444@mail.gmail.com>	<20081205084441.GA29312@owl.midgard.homeip.net>
	<7d6fde3d0812050050l57684eebkf14f252d78b68ec0@mail.gmail.com>
Message-ID: <4938F036.4010600@gmx.de>

Garrett Cooper schrieb:
> (I feel like I'm getting off on a bikeshed topic, but...)
> 
> 1. What dialect of C was it defined in? Is it still used in the
> standard dialect (honestly, this is the first time I've ever seen it
> before, but then again I am a younger generation user)?

Dialect? The ! operator is plain vanilla standard C. It takes a scalar 
operand and returns 1, if it compares equal to 0, otherwise it returns 
0. !!, i.e. two consecutive ! operators, is one of the oldest tricks in 
the book, right next to (a > b) - (a < b) for comparison functions and 
countless other idioms.

> 3. What's the real loss of going to `? :', beyond maybe 3 extra
> keystrokes if it's easier for folks who may not be as experienced to
> read?

I'd like my bikeshed grass green, please.

	Christoph
From ertr1013 at student.uu.se  Fri Dec  5 01:30:10 2008
From: ertr1013 at student.uu.se (Erik Trulsson)
Date: Fri Dec  5 01:30:17 2008
Subject: RFC: small syscons and kbd patch
In-Reply-To: <7d6fde3d0812050050l57684eebkf14f252d78b68ec0@mail.gmail.com>
References: <bb4a86c70812021701i621fdcfjb6a58a7f5cf781d5@mail.gmail.com>
	<7d6fde3d0812040324y3bf0901cy1f4a6d961362c314@mail.gmail.com>
	<bb4a86c70812040724w43ddec15yab72920d80d879d3@mail.gmail.com>
	<20081205072229.GE18652@hoeg.nl>
	<7d6fde3d0812050034y43a70ce8i49fbba92f9c8943b@mail.gmail.com>
	<7d6fde3d0812050035u6e3ea930o9e093830a8608444@mail.gmail.com>
	<20081205084441.GA29312@owl.midgard.homeip.net>
	<7d6fde3d0812050050l57684eebkf14f252d78b68ec0@mail.gmail.com>
Message-ID: <20081205093005.GA29478@owl.midgard.homeip.net>

On Fri, Dec 05, 2008 at 12:50:38AM -0800, Garrett Cooper wrote:
> On Fri, Dec 5, 2008 at 12:44 AM, Erik Trulsson <ertr1013@student.uu.se> wrote:
> > On Fri, Dec 05, 2008 at 12:35:31AM -0800, Garrett Cooper wrote:
> >> On Thu, Dec 4, 2008 at 11:22 PM, Ed Schouten <ed@80386.nl> wrote:
> >> > * Maksim Yevmenkin <maksim.yevmenkin@gmail.com> wrote:
> >> >> the idea was to ensure that kbd->kb_locked variable only takes values
> >> >> 0 (zero) and 1 (one).
> >> >
> >> > I often use constructs like these to do that:
> >> >
> >> >        foo = bar ? 1 : 0;
> >> >
> >> > Maybe !!bar is a lot shorter to write, I think the line above is a lot
> >> > easier to read.
> >>
> >> Indeed. I had no idea (and I would assume that many people wouldn't in
> >> my similar level of systems programming) what in the work you were
> >> trying to do above with that line. The one-line conditional is
> >> universal in almost all major high-level language dialects I've hit,
> >> minus Python and Tcl.
> >> -Garrett
> >
> > The !!bar construction to map {0, not-0} to {0,1} is fairly common in C
> > programming, and I would certainly expect any experienced C programmer to
> > recognize it.
> 
> (I feel like I'm getting off on a bikeshed topic, but...)
> 
> 1. What dialect of C was it defined in? Is it still used in the
> standard dialect (honestly, this is the first time I've ever seen it
> before, but then again I am a younger generation user)?

The '!!x' construct is well defined in all dialects of C as far as I know.
It is after all just using the standard '!' logical negation operator twice
in a fairly straight-forward manner.
If you know what the '!' operator does it should not be too difficult to
figure out what applying it twice would do, even if one has never seen it
done that way before.


> 2. Is it still taught in schools (I didn't learn it when I was taught
> C)? If not in schools, what about the Richie text (it's sort of like
> the defacto C programming standard book of course)?

Since I did not learn C in a school I have no idea what is (or has been)
taught in schools in that regard. As for K&R I must admit to never having read it.



It is however one (of many) idiomatic constructions in C that I would not
really expect to be explicitly taught in a class.  It is rather something I
would expect programmers to either come up with on their own or to encounter
when reading other peoples programs.


> 3. What's the real loss of going to `? :', beyond maybe 3 extra
> keystrokes if it's easier for folks who may not be as experienced to
> read?

An inexperienced C programmer who do not understand the '!!x' construct is
not a programmer I would count on being familiar with the '? :' operator
either.  Besides, I personally find the corresponding '? :' construction
harder to read.



-- 
<Insert your favourite quote here.>
Erik Trulsson
ertr1013@student.uu.se
From yanefbsd at gmail.com  Fri Dec  5 01:31:13 2008
From: yanefbsd at gmail.com (Garrett Cooper)
Date: Fri Dec  5 01:31:20 2008
Subject: RFC: small syscons and kbd patch
In-Reply-To: <4938F036.4010600@gmx.de>
References: <bb4a86c70812021701i621fdcfjb6a58a7f5cf781d5@mail.gmail.com>
	<7d6fde3d0812040324y3bf0901cy1f4a6d961362c314@mail.gmail.com>
	<bb4a86c70812040724w43ddec15yab72920d80d879d3@mail.gmail.com>
	<20081205072229.GE18652@hoeg.nl>
	<7d6fde3d0812050034y43a70ce8i49fbba92f9c8943b@mail.gmail.com>
	<7d6fde3d0812050035u6e3ea930o9e093830a8608444@mail.gmail.com>
	<20081205084441.GA29312@owl.midgard.homeip.net>
	<7d6fde3d0812050050l57684eebkf14f252d78b68ec0@mail.gmail.com>
	<4938F036.4010600@gmx.de>
Message-ID: <7d6fde3d0812050131p2e9ac761n1c76575d3a3f5792@mail.gmail.com>

On Fri, Dec 5, 2008 at 1:11 AM, Christoph Mallon
<christoph.mallon@gmx.de> wrote:
> Garrett Cooper schrieb:
>>
>> (I feel like I'm getting off on a bikeshed topic, but...)
>>
>> 1. What dialect of C was it defined in? Is it still used in the
>> standard dialect (honestly, this is the first time I've ever seen it
>> before, but then again I am a younger generation user)?
>
> Dialect? The ! operator is plain vanilla standard C. It takes a scalar
> operand and returns 1, if it compares equal to 0, otherwise it returns 0.
> !!, i.e. two consecutive ! operators, is one of the oldest tricks in the
> book, right next to (a > b) - (a < b) for comparison functions and countless
> other idioms.
>
>> 3. What's the real loss of going to `? :', beyond maybe 3 extra
>> keystrokes if it's easier for folks who may not be as experienced to
>> read?
>
> I'd like my bikeshed grass green, please.
>
>        Christoph

If you really want to split hairs, ! only negates the logic value,
whereas ~ actually negates the bits. So technically, you're not
flipping 0 to make 1 and vice versa, but instead flipping 0 to make
non-zero, etc. There is a clear distinction in hardware.

The point was that !! isn't obvious at first glancing the C code. It's
important for code to be readable as well as functional (that's why we
have style(9)). Getting down to it I'd like to see what the compiler
optimizes each as, because I can see dumb compilers saying `!!'
translates to `not, bne => set, else set, continue', whereas `? :'
could be translated to `bne, set, else set, continue'; I'm sure gcc
has moved passed these really minute details.

Hopefully this helps shed more light on where I'm coming from.

-Garrett
From christoph.mallon at gmx.de  Fri Dec  5 01:54:08 2008
From: christoph.mallon at gmx.de (Christoph Mallon)
Date: Fri Dec  5 01:54:15 2008
Subject: RFC: small syscons and kbd patch
In-Reply-To: <7d6fde3d0812050131p2e9ac761n1c76575d3a3f5792@mail.gmail.com>
References: <bb4a86c70812021701i621fdcfjb6a58a7f5cf781d5@mail.gmail.com>	
	<7d6fde3d0812040324y3bf0901cy1f4a6d961362c314@mail.gmail.com>	
	<bb4a86c70812040724w43ddec15yab72920d80d879d3@mail.gmail.com>	
	<20081205072229.GE18652@hoeg.nl>	
	<7d6fde3d0812050034y43a70ce8i49fbba92f9c8943b@mail.gmail.com>	
	<7d6fde3d0812050035u6e3ea930o9e093830a8608444@mail.gmail.com>	
	<20081205084441.GA29312@owl.midgard.homeip.net>	
	<7d6fde3d0812050050l57684eebkf14f252d78b68ec0@mail.gmail.com>	
	<4938F036.4010600@gmx.de>
	<7d6fde3d0812050131p2e9ac761n1c76575d3a3f5792@mail.gmail.com>
Message-ID: <4938FA39.50709@gmx.de>

Garrett Cooper schrieb:
> On Fri, Dec 5, 2008 at 1:11 AM, Christoph Mallon
> <christoph.mallon@gmx.de> wrote:
>> Garrett Cooper schrieb:
>>> (I feel like I'm getting off on a bikeshed topic, but...)
>>>
>>> 1. What dialect of C was it defined in? Is it still used in the
>>> standard dialect (honestly, this is the first time I've ever seen it
>>> before, but then again I am a younger generation user)?
>> Dialect? The ! operator is plain vanilla standard C. It takes a scalar
>> operand and returns 1, if it compares equal to 0, otherwise it returns 0.
>> !!, i.e. two consecutive ! operators, is one of the oldest tricks in the
>> book, right next to (a > b) - (a < b) for comparison functions and countless
>> other idioms.
>>
>>> 3. What's the real loss of going to `? :', beyond maybe 3 extra
>>> keystrokes if it's easier for folks who may not be as experienced to
>>> read?
>> I'd like my bikeshed grass green, please.
>>
>>        Christoph
> 
> If you really want to split hairs, ! only negates the logic value,
> whereas ~ actually negates the bits. So technically, you're not
> flipping 0 to make 1 and vice versa, but instead flipping 0 to make
> non-zero, etc. There is a clear distinction in hardware.

I have no idea, what you are referring to. I did not even mention the 
bitwise complement operator ~. I just described, what ! does. I 
explicitely said, the operand is compared to 0. I just paraphrased, what 
the standard says. You can verify this by reading ISO/IEC 9899:1999 (E) 
?6.5.3.3:5.

> The point was that !! isn't obvious at first glancing the C code. It's

I disagree. I sometimes even see stuff like (x ? 0 : 1) or worse (x ? 
false : true). I find this hard to read, because the "true" case returns 
"false" and vice versa. I clearly prefer a nice and concise ! or two. 
But today !! is not as important anymore, because C99 has a real bool 
type, which always is 0 or 1. See _Bool and the header <stdbool.h>.

> important for code to be readable as well as functional (that's why we
> have style(9)). Getting down to it I'd like to see what the compiler

Don't try to argue about style(9). IMO it's horribly outdated, but there 
are conservative forces, which would prefer to cling to K&R. At least we 
got function prototypes!

> optimizes each as, because I can see dumb compilers saying `!!'
> translates to `not, bne => set, else set, continue', whereas `? :'
> could be translated to `bne, set, else set, continue'; I'm sure gcc
> has moved passed these really minute details.

If you use the classic approach to implement short circuit evaluation 
for && and || you also handle !. Otherwise the code generated for stuff 
like if (!x || !y) would be horrible. Here's a very short explanation: 
You generate jump labels for the "true" and "false" cases. When 
traversing a logical expression and encountering a !, you just swap the 
"true" and "false" jump labels - nothing more happens for a !. So at no 
point you generate code, which produces a 0/1 and compares it again. 
While evaluating a logical expression with short circuit evaluation, 
there are no intermediate 0 and 1 constants involved at all.
This is a very simpel model. Modern optimizing compilers do not generate 
code directly from the abstract syntax tree, but use a intermediate 
representation, which is more suited for optimization[1][2].

Hopefully this helps to shed a bit light on compiler construction.

	Christoph



[1] (self advertisement) FIRM is a modern graph based IR, which uses SSA 
form: http://www.libfirm.org/
[2] LLVM has a nice IR, too: http://www.llvm.org/
From des at des.no  Fri Dec  5 01:59:56 2008
From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=)
Date: Fri Dec  5 02:00:03 2008
Subject: RFC: small syscons and kbd patch
In-Reply-To: <7d6fde3d0812050131p2e9ac761n1c76575d3a3f5792@mail.gmail.com>
	(Garrett Cooper's message of "Fri, 5 Dec 2008 01:31:12 -0800")
References: <bb4a86c70812021701i621fdcfjb6a58a7f5cf781d5@mail.gmail.com>
	<7d6fde3d0812040324y3bf0901cy1f4a6d961362c314@mail.gmail.com>
	<bb4a86c70812040724w43ddec15yab72920d80d879d3@mail.gmail.com>
	<20081205072229.GE18652@hoeg.nl>
	<7d6fde3d0812050034y43a70ce8i49fbba92f9c8943b@mail.gmail.com>
	<7d6fde3d0812050035u6e3ea930o9e093830a8608444@mail.gmail.com>
	<20081205084441.GA29312@owl.midgard.homeip.net>
	<7d6fde3d0812050050l57684eebkf14f252d78b68ec0@mail.gmail.com>
	<4938F036.4010600@gmx.de>
	<7d6fde3d0812050131p2e9ac761n1c76575d3a3f5792@mail.gmail.com>
Message-ID: <861vwnhrhh.fsf@ds4.des.no>

"Garrett Cooper" <yanefbsd@gmail.com> writes:
> If you really want to split hairs, ! only negates the logic value,
> whereas ~ actually negates the bits. So technically, you're not
> flipping 0 to make 1 and vice versa, but instead flipping 0 to make
> non-zero, etc. There is a clear distinction in hardware.

He didn't say anything about flipping bits...  and you're wrong, !0 is
guaranteed to evaluate to 1.

> The point was that !! isn't obvious at first glancing the C code.

It is to an experienced C programmer.

> Getting down to it I'd like to see what the compiler optimizes each
> as, because I can see dumb compilers saying `!!'  translates to `not,
> bne => set, else set, continue', whereas `? :' could be translated to
> `bne, set, else set, continue'; I'm sure gcc has moved passed these
> really minute details.

Never try to second-guess the compiler.

DES
-- 
Dag-Erling Sm?rgrav - des@des.no
From des at des.no  Fri Dec  5 02:04:57 2008
From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=)
Date: Fri Dec  5 02:05:10 2008
Subject: ichwd problem: watchdog doesn't "bark"
In-Reply-To: <49382449.80002@icyb.net.ua> (Andriy Gapon's message of "Thu, 04
	Dec 2008 20:41:13 +0200")
References: <49300020.6060603@icyb.net.ua> <49382449.80002@icyb.net.ua>
Message-ID: <86wsefgcon.fsf@ds4.des.no>

Andriy Gapon <avg@icyb.net.ua> writes:
> When I start watchdogd I see the following messages:
> timer enabled
> timeout set to 28 ticks
> and then a flow of messages:
> timer reloaded
> 
> Then I kill -9 watchdogd.
> "timer reloded" messages are no longer produced.
> And there are no other messages.
> 
> But nothing happens for many minutes that I waited.

The watchdog may be disabled, either in hardware or by the BIOS at boot
time, but the driver should have detected that.  It is also possible
that the BIOS catches the SMI but ignores it.

> BTW, can someone knowledgeable tell me if watchdog better be firing SMI
> or NMI when it runs down?

It should fire SMI, IIRC.  Read the comments at the top of the code for
references to the relevant Intel documentation, which you can download
for free.

DES
-- 
Dag-Erling Sm?rgrav - des@des.no
From des at des.no  Fri Dec  5 03:17:04 2008
From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=)
Date: Fri Dec  5 03:17:11 2008
Subject: RFC: small syscons and kbd patch
In-Reply-To: <4938FA39.50709@gmx.de> (Christoph Mallon's message of "Fri, 05
	Dec 2008 10:54:01 +0100")
References: <bb4a86c70812021701i621fdcfjb6a58a7f5cf781d5@mail.gmail.com>
	<7d6fde3d0812040324y3bf0901cy1f4a6d961362c314@mail.gmail.com>
	<bb4a86c70812040724w43ddec15yab72920d80d879d3@mail.gmail.com>
	<20081205072229.GE18652@hoeg.nl>
	<7d6fde3d0812050034y43a70ce8i49fbba92f9c8943b@mail.gmail.com>
	<7d6fde3d0812050035u6e3ea930o9e093830a8608444@mail.gmail.com>
	<20081205084441.GA29312@owl.midgard.homeip.net>
	<7d6fde3d0812050050l57684eebkf14f252d78b68ec0@mail.gmail.com>
	<4938F036.4010600@gmx.de>
	<7d6fde3d0812050131p2e9ac761n1c76575d3a3f5792@mail.gmail.com>
	<4938FA39.50709@gmx.de>
Message-ID: <86skp2hnwx.fsf@ds4.des.no>

Christoph Mallon <christoph.mallon@gmx.de> writes:
> Don't try to argue about style(9). IMO it's horribly outdated, but
> there are conservative forces, which would prefer to cling to K&R. At
> least we got function prototypes!

If there's something specific in style(9) you don't like, you are
welcome to start a discussion about it, and we will consider the merits
of your arguments; talking about "conservative forces that would prefer
to cling to K&R" will get you nowhere.

DES
-- 
Dag-Erling Sm?rgrav - des@des.no
From avg at icyb.net.ua  Fri Dec  5 03:45:37 2008
From: avg at icyb.net.ua (Andriy Gapon)
Date: Fri Dec  5 03:45:43 2008
Subject: RFC: small syscons and kbd patch
In-Reply-To: <7d6fde3d0812050050l57684eebkf14f252d78b68ec0@mail.gmail.com>
References: <bb4a86c70812021701i621fdcfjb6a58a7f5cf781d5@mail.gmail.com>	<7d6fde3d0812040324y3bf0901cy1f4a6d961362c314@mail.gmail.com>	<bb4a86c70812040724w43ddec15yab72920d80d879d3@mail.gmail.com>	<20081205072229.GE18652@hoeg.nl>	<7d6fde3d0812050034y43a70ce8i49fbba92f9c8943b@mail.gmail.com>	<7d6fde3d0812050035u6e3ea930o9e093830a8608444@mail.gmail.com>	<20081205084441.GA29312@owl.midgard.homeip.net>
	<7d6fde3d0812050050l57684eebkf14f252d78b68ec0@mail.gmail.com>
Message-ID: <49391458.8060708@icyb.net.ua>

on 05/12/2008 10:50 Garrett Cooper said the following:
> On Fri, Dec 5, 2008 at 12:44 AM, Erik Trulsson <ertr1013@student.uu.se> wrote:
>> On Fri, Dec 05, 2008 at 12:35:31AM -0800, Garrett Cooper wrote:
>>> On Thu, Dec 4, 2008 at 11:22 PM, Ed Schouten <ed@80386.nl> wrote:
>>>> * Maksim Yevmenkin <maksim.yevmenkin@gmail.com> wrote:
>>>>> the idea was to ensure that kbd->kb_locked variable only takes values
>>>>> 0 (zero) and 1 (one).
>>>> I often use constructs like these to do that:
>>>>
>>>>        foo = bar ? 1 : 0;
>>>>
>>>> Maybe !!bar is a lot shorter to write, I think the line above is a lot
>>>> easier to read.
>>> Indeed. I had no idea (and I would assume that many people wouldn't in
>>> my similar level of systems programming) what in the work you were
>>> trying to do above with that line. The one-line conditional is
>>> universal in almost all major high-level language dialects I've hit,
>>> minus Python and Tcl.
>>> -Garrett
>> The !!bar construction to map {0, not-0} to {0,1} is fairly common in C
>> programming, and I would certainly expect any experienced C programmer to
>> recognize it.
> 
> (I feel like I'm getting off on a bikeshed topic, but...)
> 
> 1. What dialect of C was it defined in? Is it still used in the
> standard dialect (honestly, this is the first time I've ever seen it
> before, but then again I am a younger generation user)?

I am not sure what you meant by dialect of C, just in case you meant
something different from others understood here's my personal
observation: you will quite a bit of '!!' in Linux kernel code, you
would see much much fewer of them in our code.

-- 
Andriy Gapon
From frank at harz.behrens.de  Fri Dec  5 00:08:09 2008
From: frank at harz.behrens.de (Frank Behrens)
Date: Fri Dec  5 04:35:34 2008
Subject: AMD64 qemu completely broken?
In-Reply-To: <Pine.GSO.4.64.0812041428400.22402@zeno.ucsd.edu>
References: <20081204212311.GA17962@saturn.kn-bremen.de>
Message-ID: <200812050808.mB5880Fo050923@post.behrens.de>

Nate Eldredge <neldredge@math.ucsd.edu> wrote on 4 Dec 2008 14:43:
>...
> pain to clean up.  '-net tap' works fine, but requires root privileges and 

No.

> is more work to set up.

Yes, and this must be as root, but you can use later the tap device 
as unprivileged user. (Isn't it a virtual network jack, where you can 
plug into your cable? ;-)

-- 
Frank Behrens, Osterwieck, Germany
PGP-key 0x5B7C47ED on public servers available.

From rea-fbsd at codelabs.ru  Fri Dec  5 05:05:25 2008
From: rea-fbsd at codelabs.ru (Eygene Ryabinkin)
Date: Fri Dec  5 05:05:33 2008
Subject: RFC: small syscons and kbd patch
In-Reply-To: <7d6fde3d0812050050l57684eebkf14f252d78b68ec0@mail.gmail.com>
References: <bb4a86c70812021701i621fdcfjb6a58a7f5cf781d5@mail.gmail.com>
	<7d6fde3d0812040324y3bf0901cy1f4a6d961362c314@mail.gmail.com>
	<bb4a86c70812040724w43ddec15yab72920d80d879d3@mail.gmail.com>
	<20081205072229.GE18652@hoeg.nl>
	<7d6fde3d0812050034y43a70ce8i49fbba92f9c8943b@mail.gmail.com>
	<7d6fde3d0812050035u6e3ea930o9e093830a8608444@mail.gmail.com>
	<20081205084441.GA29312@owl.midgard.homeip.net>
	<7d6fde3d0812050050l57684eebkf14f252d78b68ec0@mail.gmail.com>
Message-ID: <WUFHrI95zEo9/wlGGrRYnWztEtI@qm7gbYKMPO53E/nl+D5eD8YyL1A>

Garret,

Fri, Dec 05, 2008 at 12:50:38AM -0800, Garrett Cooper wrote:
> 1. What dialect of C was it defined in? Is it still used in the
> standard dialect (honestly, this is the first time I've ever seen it
> before, but then again I am a younger generation user)?

It is the standard negation operator: !(expr) is equal to (expr == 0).

> 2. Is it still taught in schools (I didn't learn it when I was taught
> C)?

Yes.  I am personally teaching the people in school and I am explaining
the concept of double negation every two years ;))

> If not in schools, what about the Richie text (it's sort of like
> the defacto C programming standard book of course)?

K&R book is good but it at no means covers all tricks and idioms
of a C language.

> 3. What's the real loss of going to `? :', beyond maybe 3 extra
> keystrokes if it's easier for folks who may not be as experienced to
> read?

No real loss, just easier to type and looks more compact.  It is the
matter of a personal taste, I think.

If one knows this idiom, he will recognize it at a glance.  If not, one
should think a bit about the logics behind it, but it shouldn't be hard:
almost everyone uses constructs like 'if (!ptr)'.  And there is only one
step from there to the double negation.
-- 
Eygene
 _                ___       _.--.   #
 \`.|\..----...-'`   `-._.-'_.-'`   #  Remember that it is hard
 /  ' `         ,       __.--'      #  to read the on-line manual   
 )/' _/     \   `-_,   /            #  while single-stepping the kernel.
 `-'" `"\_  ,_.-;_.-\_ ',  fsc/as   #
     _.-'_./   {_.'   ; /           #    -- FreeBSD Developers handbook 
    {_.-``-'         {_/            #
-------------- 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-hackers/attachments/20081205/b382e393/attachment.pgp
From zbeeble at gmail.com  Fri Dec  5 10:10:14 2008
From: zbeeble at gmail.com (Zaphod Beeblebrox)
Date: Fri Dec  5 10:10:22 2008
Subject: IPMI shared ethernet ports (again).
Message-ID: <5f67a8c40812051010u55ef6d70m1b4270c98852d87c@mail.gmail.com>

I posted here a month or two ago about being amazed that some system
management cards can share a physical ethernet port.  Some of you responded
that it doesn't always work.

Well... I've encountered this and I'm wondering if I can work around it
somehow.

The ones that work are in Dell 1950-III servers (The R-200 seem to work,
too).  They have "bce" driver ports.

The HP DL/360 that I have here today have "bge" driver ports and the IPMI
console appears to stop working just as soon as FreeBSD probes the port.

Is this something that can be configured in BGE or is it just not going to
work?
From neldredge at math.ucsd.edu  Fri Dec  5 10:27:46 2008
From: neldredge at math.ucsd.edu (Nate Eldredge)
Date: Fri Dec  5 10:27:53 2008
Subject: RFC: small syscons and kbd patch
In-Reply-To: <7d6fde3d0812050131p2e9ac761n1c76575d3a3f5792@mail.gmail.com>
References: <bb4a86c70812021701i621fdcfjb6a58a7f5cf781d5@mail.gmail.com>
	<7d6fde3d0812040324y3bf0901cy1f4a6d961362c314@mail.gmail.com>
	<bb4a86c70812040724w43ddec15yab72920d80d879d3@mail.gmail.com>
	<20081205072229.GE18652@hoeg.nl>
	<7d6fde3d0812050034y43a70ce8i49fbba92f9c8943b@mail.gmail.com>
	<7d6fde3d0812050035u6e3ea930o9e093830a8608444@mail.gmail.com>
	<20081205084441.GA29312@owl.midgard.homeip.net>
	<7d6fde3d0812050050l57684eebkf14f252d78b68ec0@mail.gmail.com>
	<4938F036.4010600@gmx.de>
	<7d6fde3d0812050131p2e9ac761n1c76575d3a3f5792@mail.gmail.com>
Message-ID: <Pine.GSO.4.64.0812050956110.22402@zeno.ucsd.edu>

On Fri, 5 Dec 2008, Garrett Cooper wrote:

> On Fri, Dec 5, 2008 at 1:11 AM, Christoph Mallon
> <christoph.mallon@gmx.de> wrote:
>> Garrett Cooper schrieb:
>>>
>>> (I feel like I'm getting off on a bikeshed topic, but...)
>>>
>>> 1. What dialect of C was it defined in? Is it still used in the
>>> standard dialect (honestly, this is the first time I've ever seen it
>>> before, but then again I am a younger generation user)?
>>
>> Dialect? The ! operator is plain vanilla standard C. It takes a scalar
>> operand and returns 1, if it compares equal to 0, otherwise it returns 0.
>> !!, i.e. two consecutive ! operators, is one of the oldest tricks in the
>> book, right next to (a > b) - (a < b) for comparison functions and countless
>> other idioms.
>>
>>> 3. What's the real loss of going to `? :', beyond maybe 3 extra
>>> keystrokes if it's easier for folks who may not be as experienced to
>>> read?
>>
>> I'd like my bikeshed grass green, please.
>>
>>        Christoph
>
> If you really want to split hairs, ! only negates the logic value,
> whereas ~ actually negates the bits. So technically, you're not
> flipping 0 to make 1 and vice versa, but instead flipping 0 to make
> non-zero, etc. There is a clear distinction in hardware.
>
> The point was that !! isn't obvious at first glancing the C code. It's
> important for code to be readable as well as functional (that's why we
> have style(9)). Getting down to it I'd like to see what the compiler
> optimizes each as, because I can see dumb compilers saying `!!'
> translates to `not, bne => set, else set, continue', whereas `? :'
> could be translated to `bne, set, else set, continue'; I'm sure gcc
> has moved passed these really minute details.

Out of curiosity, I tried some various compilers, including gcc on i386, 
amd64, and sparc; Intel's C compiler on i386; tcc (tiny, non-optimizing C 
compiler) on i386; and Sun's compiler (old version) on sparc.

I compiled the following file:

int bangbang(int x) { return !!x; }
int ternary(int x) { return x ? 1 : 0; }

Intel's compiler generated different code for these two functions when 
optimization was turned off.  bangbang used a conditional set instruction, 
while ternary used conditional jumps.  With optimization on the two were 
identical.

All other compilers generated identical code for the two functions whether 
optimization was on or off.  (Of course, the generated code varied between 
compilers; tcc's in particular was decidedly non-optimized.)

I really don't think something as simple as this is worth worrying about 
in terms of code efficiency.  Even if they weren't identical, the 
difference is at most a couple of instructions and a pipeline flush, and 
if that's a serious problem you need to be using assembly anyway. 
Besides, it's not a piece of code that comes up all that often.

The only basis for arguing about it is style, and I think we've 
established that it's purely a matter of taste.  In particular, there 
isn't a clear favorite for which is easier to read.  IMHO, style(9) should 
remain agnostic and let the programmer decide.

However, if people really feel that consistency is necessary here, I 
propose the following: if the cents digit of the closing price of the Dow 
Jones Industrial Average on this coming Monday, December 8, 2008, is even, 
then style(9) shall be edited to indicate that `!!x' is preferred.  If 
odd, then style(9) shall prefer `x ? 1 : 0'.

:-)

-- 

Nate Eldredge
neldredge@math.ucsd.edu
From stephen at math.missouri.edu  Fri Dec  5 11:02:01 2008
From: stephen at math.missouri.edu (Stephen Montgomery-Smith)
Date: Fri Dec  5 11:02:09 2008
Subject: RFC: small syscons and kbd patch
In-Reply-To: <Pine.GSO.4.64.0812050956110.22402@zeno.ucsd.edu>
References: <bb4a86c70812021701i621fdcfjb6a58a7f5cf781d5@mail.gmail.com>	<7d6fde3d0812040324y3bf0901cy1f4a6d961362c314@mail.gmail.com>	<bb4a86c70812040724w43ddec15yab72920d80d879d3@mail.gmail.com>	<20081205072229.GE18652@hoeg.nl>	<7d6fde3d0812050034y43a70ce8i49fbba92f9c8943b@mail.gmail.com>	<7d6fde3d0812050035u6e3ea930o9e093830a8608444@mail.gmail.com>	<20081205084441.GA29312@owl.midgard.homeip.net>	<7d6fde3d0812050050l57684eebkf14f252d78b68ec0@mail.gmail.com>	<4938F036.4010600@gmx.de>	<7d6fde3d0812050131p2e9ac761n1c76575d3a3f5792@mail.gmail.com>
	<Pine.GSO.4.64.0812050956110.22402@zeno.ucsd.edu>
Message-ID: <493974DE.1050802@math.missouri.edu>

Nate Eldredge wrote:

> int bangbang(int x) { return !!x; }
> int ternary(int x) { return x ? 1 : 0; }

Stylewise, I prefer

int notzero(int x) { return x!=0; }
From neldredge at math.ucsd.edu  Fri Dec  5 11:12:28 2008
From: neldredge at math.ucsd.edu (Nate Eldredge)
Date: Fri Dec  5 11:12:34 2008
Subject: RFC: small syscons and kbd patch
In-Reply-To: <493974DE.1050802@math.missouri.edu>
References: <bb4a86c70812021701i621fdcfjb6a58a7f5cf781d5@mail.gmail.com>
	<7d6fde3d0812040324y3bf0901cy1f4a6d961362c314@mail.gmail.com>
	<bb4a86c70812040724w43ddec15yab72920d80d879d3@mail.gmail.com>
	<20081205072229.GE18652@hoeg.nl>
	<7d6fde3d0812050034y43a70ce8i49fbba92f9c8943b@mail.gmail.com>
	<7d6fde3d0812050035u6e3ea930o9e093830a8608444@mail.gmail.com>
	<20081205084441.GA29312@owl.midgard.homeip.net>
	<7d6fde3d0812050050l57684eebkf14f252d78b68ec0@mail.gmail.com>
	<4938F036.4010600@gmx.de>
	<7d6fde3d0812050131p2e9ac761n1c76575d3a3f5792@mail.gmail.com>
	<Pine.GSO.4.64.0812050956110.22402@zeno.ucsd.edu>
	<493974DE.1050802@math.missouri.edu>
Message-ID: <Pine.GSO.4.64.0812051105250.22402@zeno.ucsd.edu>

On Fri, 5 Dec 2008, Stephen Montgomery-Smith wrote:

> Nate Eldredge wrote:
>
>> int bangbang(int x) { return !!x; }
>> int ternary(int x) { return x ? 1 : 0; }
>
> Stylewise, I prefer
>
> int notzero(int x) { return x!=0; }

icc -O0 compiles notzero the same as bangbang (better than ternary).  tcc 
produces better code for notzero than the other two.  Sun cc without 
optimization produces slightly better code for notzero than the other two 
(one jump instead of two).  For everything else all three produce 
equivalent code.

`x && 1' and `x || 0' are some other possibilities.

Anyway, maybe there is something more useful we could all be doing. :)

-- 

Nate Eldredge
neldredge@math.ucsd.edu
From sheldon at sigsegv.ca  Fri Dec  5 14:44:55 2008
From: sheldon at sigsegv.ca (Sheldon Givens)
Date: Fri Dec  5 14:45:02 2008
Subject: Small change to wc
Message-ID: <f4ecc0930812051414n17867e1fi80d6ed458e879bde@mail.gmail.com>

Hello everyone,
In the process of migrating the last of a few Linux servers to FreeBSD, we
ran in to a bit of a snag with one of our scripts when BSD wc didn't have an
equivalent to the Linux -L. This flag tells wc to keep track of the longest
line in the input.

Here's a little diff to add this functionality to BSD wc.

With this patch, an additional parameter is added to output that shows the
length of the longest line

My apologies if this is in the wrong format. I don't often post here.

Happy Holidays,

Sheldon Givens


---snip---
65,66c65,66
< uintmax_t tlinect, twordct, tcharct;
< int doline, doword, dochar, domulti;
---
> uintmax_t tlinect, twordct, tcharct, tlongline;
> int doline, doword, dochar, domulti, dolongline;
78c78
<       while ((ch = getopt(argc, argv, "clmw")) != -1)
---
>       while ((ch = getopt(argc, argv, "clmwL")) != -1)
93a94,96
>               case 'L':
>                       dolongline = 1;
>                       break;
127a131,132
>               if (dolongline)
>                       (void)printf(" %7ju", tlongline);
137c142
<       uintmax_t linect, wordct, charct;
---
>       uintmax_t linect, wordct, charct, llcnt, tmpll;
146c151
<       linect = wordct = charct = 0;
---
>       linect = wordct = charct = llcnt = tmpll = 0;
171c176,179
<                                       if (*p == '\n')
---
>                                       if (*p == '\n') {
>                                               if (tmpll > llcnt)
>                                                       llcnt = tmpll;
>                                               tmpll = 0;
172a181
>                                       } else { tmpll++; }
179a189,192
>                       if (dolongline) {
>                               tlongline = llcnt;
>                               (void)printf(" %7ju", tlongline);
>                       }
197c210
<                               return (0);
---
>                       return (0);
231a245
>                       tmpll++;
234c248,251
<                       if (wch == L'\n')
---
>                       if (wch == L'\n') {
>                               if (tmpll > llcnt)
>                                       llcnt = tmpll;
>                               tmpll = 0;
235a253
>                       }
258a277,280
>       if (dolongline) {
>               tlongline = llcnt;
>               (void)printf(" %7ju", llcnt - 1);
>       }
266c288
<       (void)fprintf(stderr, "usage: wc [-clmw] [file ...]\n");
---
>       (void)fprintf(stderr, "usage: wc [-clmwL] [file ...]\n");

---unsnip---
From yanefbsd at gmail.com  Fri Dec  5 14:48:46 2008
From: yanefbsd at gmail.com (Garrett Cooper)
Date: Fri Dec  5 14:48:53 2008
Subject: Small change to wc
In-Reply-To: <f4ecc0930812051414n17867e1fi80d6ed458e879bde@mail.gmail.com>
References: <f4ecc0930812051414n17867e1fi80d6ed458e879bde@mail.gmail.com>
Message-ID: <7d6fde3d0812051448r1581d666v50d162cae348982a@mail.gmail.com>

On Fri, Dec 5, 2008 at 2:14 PM, Sheldon Givens <sheldon@sigsegv.ca> wrote:
> Hello everyone,
> In the process of migrating the last of a few Linux servers to FreeBSD, we
> ran in to a bit of a snag with one of our scripts when BSD wc didn't have an
> equivalent to the Linux -L. This flag tells wc to keep track of the longest
> line in the input.
>
> Here's a little diff to add this functionality to BSD wc.
>
> With this patch, an additional parameter is added to output that shows the
> length of the longest line
>
> My apologies if this is in the wrong format. I don't often post here.
>
> Happy Holidays,
>
> Sheldon Givens
>
>
> ---snip---
> 65,66c65,66
> < uintmax_t tlinect, twordct, tcharct;
> < int doline, doword, dochar, domulti;
> ---
>> uintmax_t tlinect, twordct, tcharct, tlongline;
>> int doline, doword, dochar, domulti, dolongline;
> 78c78
> <       while ((ch = getopt(argc, argv, "clmw")) != -1)
> ---
>>       while ((ch = getopt(argc, argv, "clmwL")) != -1)
> 93a94,96
>>               case 'L':
>>                       dolongline = 1;
>>                       break;
> 127a131,132
>>               if (dolongline)
>>                       (void)printf(" %7ju", tlongline);
> 137c142
> <       uintmax_t linect, wordct, charct;
> ---
>>       uintmax_t linect, wordct, charct, llcnt, tmpll;
> 146c151
> <       linect = wordct = charct = 0;
> ---
>>       linect = wordct = charct = llcnt = tmpll = 0;
> 171c176,179
> <                                       if (*p == '\n')
> ---
>>                                       if (*p == '\n') {
>>                                               if (tmpll > llcnt)
>>                                                       llcnt = tmpll;
>>                                               tmpll = 0;
> 172a181
>>                                       } else { tmpll++; }
> 179a189,192
>>                       if (dolongline) {
>>                               tlongline = llcnt;
>>                               (void)printf(" %7ju", tlongline);
>>                       }
> 197c210
> <                               return (0);
> ---
>>                       return (0);
> 231a245
>>                       tmpll++;
> 234c248,251
> <                       if (wch == L'\n')
> ---
>>                       if (wch == L'\n') {
>>                               if (tmpll > llcnt)
>>                                       llcnt = tmpll;
>>                               tmpll = 0;
> 235a253
>>                       }
> 258a277,280
>>       if (dolongline) {
>>               tlongline = llcnt;
>>               (void)printf(" %7ju", llcnt - 1);
>>       }
> 266c288
> <       (void)fprintf(stderr, "usage: wc [-clmw] [file ...]\n");
> ---
>>       (void)fprintf(stderr, "usage: wc [-clmwL] [file ...]\n");
>
> ---unsnip---

What's the plus side of having this? I can accomplish the same with
something like awk without the additional overhead, which would be
guaranteed to be portable.
-Garrett
From yanefbsd at gmail.com  Fri Dec  5 14:49:40 2008
From: yanefbsd at gmail.com (Garrett Cooper)
Date: Fri Dec  5 14:49:47 2008
Subject: Small change to wc
In-Reply-To: <7d6fde3d0812051448r1581d666v50d162cae348982a@mail.gmail.com>
References: <f4ecc0930812051414n17867e1fi80d6ed458e879bde@mail.gmail.com>
	<7d6fde3d0812051448r1581d666v50d162cae348982a@mail.gmail.com>
Message-ID: <7d6fde3d0812051449s2ada98a7y848afc78caa8d096@mail.gmail.com>

On Fri, Dec 5, 2008 at 2:48 PM, Garrett Cooper <yanefbsd@gmail.com> wrote:
> On Fri, Dec 5, 2008 at 2:14 PM, Sheldon Givens <sheldon@sigsegv.ca> wrote:
>> Hello everyone,
>> In the process of migrating the last of a few Linux servers to FreeBSD, we
>> ran in to a bit of a snag with one of our scripts when BSD wc didn't have an
>> equivalent to the Linux -L. This flag tells wc to keep track of the longest
>> line in the input.
>>
>> Here's a little diff to add this functionality to BSD wc.

[..]

> What's the plus side of having this? I can accomplish the same with
> something like awk without the additional overhead, which would be
> guaranteed to be portable.

s/overhead/overhead to wc/.

> -Garrett
From sheldon at sigsegv.ca  Fri Dec  5 15:10:58 2008
From: sheldon at sigsegv.ca (Sheldon Givens)
Date: Fri Dec  5 15:11:04 2008
Subject: Small change to wc
In-Reply-To: <7d6fde3d0812051448r1581d666v50d162cae348982a@mail.gmail.com>
References: <f4ecc0930812051414n17867e1fi80d6ed458e879bde@mail.gmail.com>
	<7d6fde3d0812051448r1581d666v50d162cae348982a@mail.gmail.com>
Message-ID: <f4ecc0930812051510v323ae95anccaca18d28fd174@mail.gmail.com>

What's the problem having it? The total code is mere bytes and it eases the
transition for others who are migrating from Linux.
You're absolutely right in that it can be done with awk (fairly simply, too)
but it doesn't hurt to explore options. Additionally, with awk, you can't
get other figures with the same command, which increases ease of use.
IE: What's the equivalent to "wc -clwL" in awk? Would you really rather run
wc -clw && awk '{if(length>x){x=length}}END{if(x>0){print x}else{print
0}}'`?

Isn't wc -L a more elegant solution than awk
'{if(length>x){x=length}}END{if(x>0){print x}else{print 0}}'`?

Should I continue?

On Fri, Dec 5, 2008 at 2:48 PM, Garrett Cooper <yanefbsd@gmail.com> wrote:

> On Fri, Dec 5, 2008 at 2:14 PM, Sheldon Givens <sheldon@sigsegv.ca> wrote:
> > Hello everyone,
> > In the process of migrating the last of a few Linux servers to FreeBSD,
> we
> > ran in to a bit of a snag with one of our scripts when BSD wc didn't have
> an
> > equivalent to the Linux -L. This flag tells wc to keep track of the
> longest
> > line in the input.
> >
> > Here's a little diff to add this functionality to BSD wc.
> >
> > With this patch, an additional parameter is added to output that shows
> the
> > length of the longest line
> >
> > My apologies if this is in the wrong format. I don't often post here.
> >
> > Happy Holidays,
> >
> > Sheldon Givens
> >
> >
> > ---snip---
> > 65,66c65,66
> > < uintmax_t tlinect, twordct, tcharct;
> > < int doline, doword, dochar, domulti;
> > ---
> >> uintmax_t tlinect, twordct, tcharct, tlongline;
> >> int doline, doword, dochar, domulti, dolongline;
> > 78c78
> > <       while ((ch = getopt(argc, argv, "clmw")) != -1)
> > ---
> >>       while ((ch = getopt(argc, argv, "clmwL")) != -1)
> > 93a94,96
> >>               case 'L':
> >>                       dolongline = 1;
> >>                       break;
> > 127a131,132
> >>               if (dolongline)
> >>                       (void)printf(" %7ju", tlongline);
> > 137c142
> > <       uintmax_t linect, wordct, charct;
> > ---
> >>       uintmax_t linect, wordct, charct, llcnt, tmpll;
> > 146c151
> > <       linect = wordct = charct = 0;
> > ---
> >>       linect = wordct = charct = llcnt = tmpll = 0;
> > 171c176,179
> > <                                       if (*p == '\n')
> > ---
> >>                                       if (*p == '\n') {
> >>                                               if (tmpll > llcnt)
> >>                                                       llcnt = tmpll;
> >>                                               tmpll = 0;
> > 172a181
> >>                                       } else { tmpll++; }
> > 179a189,192
> >>                       if (dolongline) {
> >>                               tlongline = llcnt;
> >>                               (void)printf(" %7ju", tlongline);
> >>                       }
> > 197c210
> > <                               return (0);
> > ---
> >>                       return (0);
> > 231a245
> >>                       tmpll++;
> > 234c248,251
> > <                       if (wch == L'\n')
> > ---
> >>                       if (wch == L'\n') {
> >>                               if (tmpll > llcnt)
> >>                                       llcnt = tmpll;
> >>                               tmpll = 0;
> > 235a253
> >>                       }
> > 258a277,280
> >>       if (dolongline) {
> >>               tlongline = llcnt;
> >>               (void)printf(" %7ju", llcnt - 1);
> >>       }
> > 266c288
> > <       (void)fprintf(stderr, "usage: wc [-clmw] [file ...]\n");
> > ---
> >>       (void)fprintf(stderr, "usage: wc [-clmwL] [file ...]\n");
> >
> > ---unsnip---
>
> What's the plus side of having this? I can accomplish the same with
> something like awk without the additional overhead, which would be
> guaranteed to be portable.
> -Garrett
>
From kostikbel at gmail.com  Fri Dec  5 15:15:07 2008
From: kostikbel at gmail.com (Kostik Belousov)
Date: Fri Dec  5 15:15:13 2008
Subject: Small change to wc
In-Reply-To: <f4ecc0930812051510v323ae95anccaca18d28fd174@mail.gmail.com>
References: <f4ecc0930812051414n17867e1fi80d6ed458e879bde@mail.gmail.com>
	<7d6fde3d0812051448r1581d666v50d162cae348982a@mail.gmail.com>
	<f4ecc0930812051510v323ae95anccaca18d28fd174@mail.gmail.com>
Message-ID: <20081205231458.GY2038@deviant.kiev.zoral.com.ua>

On Fri, Dec 05, 2008 at 03:10:56PM -0800, Sheldon Givens wrote:
> What's the problem having it? The total code is mere bytes and it eases the
> transition for others who are migrating from Linux.
> You're absolutely right in that it can be done with awk (fairly simply, too)
> but it doesn't hurt to explore options. Additionally, with awk, you can't
> get other figures with the same command, which increases ease of use.
> IE: What's the equivalent to "wc -clwL" in awk? Would you really rather run
> wc -clw && awk '{if(length>x){x=length}}END{if(x>0){print x}else{print
> 0}}'`?
> 
> Isn't wc -L a more elegant solution than awk
> '{if(length>x){x=length}}END{if(x>0){print x}else{print 0}}'`?
> 
> Should I continue?

Real argument pro is that you have one less thing to worry when you
trying to run some script, written on Linux, on the FreeBSD system.

> 
> On Fri, Dec 5, 2008 at 2:48 PM, Garrett Cooper <yanefbsd@gmail.com> wrote:
> 
> > On Fri, Dec 5, 2008 at 2:14 PM, Sheldon Givens <sheldon@sigsegv.ca> wrote:
> > > Hello everyone,
> > > In the process of migrating the last of a few Linux servers to FreeBSD,
> > we
> > > ran in to a bit of a snag with one of our scripts when BSD wc didn't have
> > an
> > > equivalent to the Linux -L. This flag tells wc to keep track of the
> > longest
> > > line in the input.
> > >
> > > Here's a little diff to add this functionality to BSD wc.
> > >
> > > With this patch, an additional parameter is added to output that shows
> > the
> > > length of the longest line
> > >
> > > My apologies if this is in the wrong format. I don't often post here.
> > >
> > > Happy Holidays,
> > >
> > > Sheldon Givens
> > >
> > >
> > > ---snip---
> > > 65,66c65,66
> > > < uintmax_t tlinect, twordct, tcharct;
> > > < int doline, doword, dochar, domulti;
> > > ---
> > >> uintmax_t tlinect, twordct, tcharct, tlongline;
> > >> int doline, doword, dochar, domulti, dolongline;
> > > 78c78
> > > <       while ((ch = getopt(argc, argv, "clmw")) != -1)
> > > ---
> > >>       while ((ch = getopt(argc, argv, "clmwL")) != -1)
> > > 93a94,96
> > >>               case 'L':
> > >>                       dolongline = 1;
> > >>                       break;
> > > 127a131,132
> > >>               if (dolongline)
> > >>                       (void)printf(" %7ju", tlongline);
> > > 137c142
> > > <       uintmax_t linect, wordct, charct;
> > > ---
> > >>       uintmax_t linect, wordct, charct, llcnt, tmpll;
> > > 146c151
> > > <       linect = wordct = charct = 0;
> > > ---
> > >>       linect = wordct = charct = llcnt = tmpll = 0;
> > > 171c176,179
> > > <                                       if (*p == '\n')
> > > ---
> > >>                                       if (*p == '\n') {
> > >>                                               if (tmpll > llcnt)
> > >>                                                       llcnt = tmpll;
> > >>                                               tmpll = 0;
> > > 172a181
> > >>                                       } else { tmpll++; }
> > > 179a189,192
> > >>                       if (dolongline) {
> > >>                               tlongline = llcnt;
> > >>                               (void)printf(" %7ju", tlongline);
> > >>                       }
> > > 197c210
> > > <                               return (0);
> > > ---
> > >>                       return (0);
> > > 231a245
> > >>                       tmpll++;
> > > 234c248,251
> > > <                       if (wch == L'\n')
> > > ---
> > >>                       if (wch == L'\n') {
> > >>                               if (tmpll > llcnt)
> > >>                                       llcnt = tmpll;
> > >>                               tmpll = 0;
> > > 235a253
> > >>                       }
> > > 258a277,280
> > >>       if (dolongline) {
> > >>               tlongline = llcnt;
> > >>               (void)printf(" %7ju", llcnt - 1);
> > >>       }
> > > 266c288
> > > <       (void)fprintf(stderr, "usage: wc [-clmw] [file ...]\n");
> > > ---
> > >>       (void)fprintf(stderr, "usage: wc [-clmwL] [file ...]\n");
> > >
> > > ---unsnip---
> >
> > What's the plus side of having this? I can accomplish the same with
> > something like awk without the additional overhead, which would be
> > guaranteed to be portable.
> > -Garrett
> >
> _______________________________________________
> freebsd-hackers@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
-------------- 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-hackers/attachments/20081205/ca8fc173/attachment.pgp
From julian at elischer.org  Fri Dec  5 15:20:02 2008
From: julian at elischer.org (Julian Elischer)
Date: Fri Dec  5 15:20:09 2008
Subject: Small change to wc
In-Reply-To: <7d6fde3d0812051448r1581d666v50d162cae348982a@mail.gmail.com>
References: <f4ecc0930812051414n17867e1fi80d6ed458e879bde@mail.gmail.com>
	<7d6fde3d0812051448r1581d666v50d162cae348982a@mail.gmail.com>
Message-ID: <4939B3A1.6060307@elischer.org>

Garrett Cooper wrote:
> On Fri, Dec 5, 2008 at 2:14 PM, Sheldon Givens <sheldon@sigsegv.ca> wrote:
>> Hello everyone,
>> In the process of migrating the last of a few Linux servers to FreeBSD, we
>> ran in to a bit of a snag with one of our scripts when BSD wc didn't have an
>> equivalent to the Linux -L. This flag tells wc to keep track of the longest
>> line in the input.
>>
>> Here's a little diff to add this functionality to BSD wc.
>>
>> With this patch, an additional parameter is added to output that shows the
>> length of the longest line
>>
>> My apologies if this is in the wrong format. I don't often post here.
>>
>> Happy Holidays,
>>
>> Sheldon Givens
>>
>>
>> ---snip---
>> 65,66c65,66
>> < uintmax_t tlinect, twordct, tcharct;
>> < int doline, doword, dochar, domulti;
>> ---
>>> uintmax_t tlinect, twordct, tcharct, tlongline;
>>> int doline, doword, dochar, domulti, dolongline;
>> 78c78
>> <       while ((ch = getopt(argc, argv, "clmw")) != -1)
>> ---
>>>       while ((ch = getopt(argc, argv, "clmwL")) != -1)
>> 93a94,96
>>>               case 'L':
>>>                       dolongline = 1;
>>>                       break;
>> 127a131,132
>>>               if (dolongline)
>>>                       (void)printf(" %7ju", tlongline);
>> 137c142
>> <       uintmax_t linect, wordct, charct;
>> ---
>>>       uintmax_t linect, wordct, charct, llcnt, tmpll;
>> 146c151
>> <       linect = wordct = charct = 0;
>> ---
>>>       linect = wordct = charct = llcnt = tmpll = 0;
>> 171c176,179
>> <                                       if (*p == '\n')
>> ---
>>>                                       if (*p == '\n') {
>>>                                               if (tmpll > llcnt)
>>>                                                       llcnt = tmpll;
>>>                                               tmpll = 0;
>> 172a181
>>>                                       } else { tmpll++; }
>> 179a189,192
>>>                       if (dolongline) {
>>>                               tlongline = llcnt;
>>>                               (void)printf(" %7ju", tlongline);
>>>                       }
>> 197c210
>> <                               return (0);
>> ---
>>>                       return (0);
>> 231a245
>>>                       tmpll++;
>> 234c248,251
>> <                       if (wch == L'\n')
>> ---
>>>                       if (wch == L'\n') {
>>>                               if (tmpll > llcnt)
>>>                                       llcnt = tmpll;
>>>                               tmpll = 0;
>> 235a253
>>>                       }
>> 258a277,280
>>>       if (dolongline) {
>>>               tlongline = llcnt;
>>>               (void)printf(" %7ju", llcnt - 1);
>>>       }
>> 266c288
>> <       (void)fprintf(stderr, "usage: wc [-clmw] [file ...]\n");
>> ---
>>>       (void)fprintf(stderr, "usage: wc [-clmwL] [file ...]\n");
>> ---unsnip---
> 
> What's the plus side of having this? I can accomplish the same with
> something like awk without the additional overhead, which would be
> guaranteed to be portable.

true, but this is a well known extension that people use and to tell 
the truth, I have no idea how I would do it in awk without reading a 
lot where in wc it's obvious from the synopsis.

> -Garrett
> _______________________________________________
> freebsd-hackers@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"

From yanefbsd at gmail.com  Fri Dec  5 15:23:01 2008
From: yanefbsd at gmail.com (Garrett Cooper)
Date: Fri Dec  5 15:23:11 2008
Subject: Small change to wc
In-Reply-To: <20081205231458.GY2038@deviant.kiev.zoral.com.ua>
References: <f4ecc0930812051414n17867e1fi80d6ed458e879bde@mail.gmail.com>
	<7d6fde3d0812051448r1581d666v50d162cae348982a@mail.gmail.com>
	<f4ecc0930812051510v323ae95anccaca18d28fd174@mail.gmail.com>
	<20081205231458.GY2038@deviant.kiev.zoral.com.ua>
Message-ID: <7d6fde3d0812051523p6be3fc19re3322f3ddba78b1e@mail.gmail.com>

On Fri, Dec 5, 2008 at 3:14 PM, Kostik Belousov <kostikbel@gmail.com> wrote:
> On Fri, Dec 05, 2008 at 03:10:56PM -0800, Sheldon Givens wrote:
>> What's the problem having it? The total code is mere bytes and it eases the
>> transition for others who are migrating from Linux.
>> You're absolutely right in that it can be done with awk (fairly simply, too)
>> but it doesn't hurt to explore options. Additionally, with awk, you can't
>> get other figures with the same command, which increases ease of use.
>> IE: What's the equivalent to "wc -clwL" in awk? Would you really rather run
>> wc -clw && awk '{if(length>x){x=length}}END{if(x>0){print x}else{print
>> 0}}'`?
>>
>> Isn't wc -L a more elegant solution than awk
>> '{if(length>x){x=length}}END{if(x>0){print x}else{print 0}}'`?
>>
>> Should I continue?
>
> Real argument pro is that you have one less thing to worry when you
> trying to run some script, written on Linux, on the FreeBSD system.
>
>>
>> On Fri, Dec 5, 2008 at 2:48 PM, Garrett Cooper <yanefbsd@gmail.com> wrote:
>>
>> > On Fri, Dec 5, 2008 at 2:14 PM, Sheldon Givens <sheldon@sigsegv.ca> wrote:
>> > > Hello everyone,
>> > > In the process of migrating the last of a few Linux servers to FreeBSD,
>> > we
>> > > ran in to a bit of a snag with one of our scripts when BSD wc didn't have
>> > an
>> > > equivalent to the Linux -L. This flag tells wc to keep track of the
>> > longest
>> > > line in the input.
>> > >
>> > > Here's a little diff to add this functionality to BSD wc.
>> > >
>> > > With this patch, an additional parameter is added to output that shows
>> > the
>> > > length of the longest line
>> > >
>> > > My apologies if this is in the wrong format. I don't often post here.
>> > >
>> > > Happy Holidays,
>> > >
>> > > Sheldon Givens
>> > >
>> > >
>> > > ---snip---
>> > > 65,66c65,66
>> > > < uintmax_t tlinect, twordct, tcharct;
>> > > < int doline, doword, dochar, domulti;
>> > > ---
>> > >> uintmax_t tlinect, twordct, tcharct, tlongline;
>> > >> int doline, doword, dochar, domulti, dolongline;
>> > > 78c78
>> > > <       while ((ch = getopt(argc, argv, "clmw")) != -1)
>> > > ---
>> > >>       while ((ch = getopt(argc, argv, "clmwL")) != -1)
>> > > 93a94,96
>> > >>               case 'L':
>> > >>                       dolongline = 1;
>> > >>                       break;
>> > > 127a131,132
>> > >>               if (dolongline)
>> > >>                       (void)printf(" %7ju", tlongline);
>> > > 137c142
>> > > <       uintmax_t linect, wordct, charct;
>> > > ---
>> > >>       uintmax_t linect, wordct, charct, llcnt, tmpll;
>> > > 146c151
>> > > <       linect = wordct = charct = 0;
>> > > ---
>> > >>       linect = wordct = charct = llcnt = tmpll = 0;
>> > > 171c176,179
>> > > <                                       if (*p == '\n')
>> > > ---
>> > >>                                       if (*p == '\n') {
>> > >>                                               if (tmpll > llcnt)
>> > >>                                                       llcnt = tmpll;
>> > >>                                               tmpll = 0;
>> > > 172a181
>> > >>                                       } else { tmpll++; }
>> > > 179a189,192
>> > >>                       if (dolongline) {
>> > >>                               tlongline = llcnt;
>> > >>                               (void)printf(" %7ju", tlongline);
>> > >>                       }
>> > > 197c210
>> > > <                               return (0);
>> > > ---
>> > >>                       return (0);
>> > > 231a245
>> > >>                       tmpll++;
>> > > 234c248,251
>> > > <                       if (wch == L'\n')
>> > > ---
>> > >>                       if (wch == L'\n') {
>> > >>                               if (tmpll > llcnt)
>> > >>                                       llcnt = tmpll;
>> > >>                               tmpll = 0;
>> > > 235a253
>> > >>                       }
>> > > 258a277,280
>> > >>       if (dolongline) {
>> > >>               tlongline = llcnt;
>> > >>               (void)printf(" %7ju", llcnt - 1);
>> > >>       }
>> > > 266c288
>> > > <       (void)fprintf(stderr, "usage: wc [-clmw] [file ...]\n");
>> > > ---
>> > >>       (void)fprintf(stderr, "usage: wc [-clmwL] [file ...]\n");
>> > >
>> > > ---unsnip---
>> >
>> > What's the plus side of having this? I can accomplish the same with
>> > something like awk without the additional overhead, which would be
>> > guaranteed to be portable.
>> > -Garrett

Very true. Ok, I've been easily won over :).
The patch looks largely ok, but have you gone through compiling it in
your own dev tree (vatting out possible warnings, etc).
-Garrett
From sheldon at sigsegv.ca  Fri Dec  5 15:28:01 2008
From: sheldon at sigsegv.ca (Sheldon Givens)
Date: Fri Dec  5 15:28:08 2008
Subject: Small change to wc
In-Reply-To: <7d6fde3d0812051523p6be3fc19re3322f3ddba78b1e@mail.gmail.com>
References: <f4ecc0930812051414n17867e1fi80d6ed458e879bde@mail.gmail.com>
	<7d6fde3d0812051448r1581d666v50d162cae348982a@mail.gmail.com>
	<f4ecc0930812051510v323ae95anccaca18d28fd174@mail.gmail.com>
	<20081205231458.GY2038@deviant.kiev.zoral.com.ua>
	<7d6fde3d0812051523p6be3fc19re3322f3ddba78b1e@mail.gmail.com>
Message-ID: <f4ecc0930812051528t5d005585ta5c3af7e3ed5d72b@mail.gmail.com>

I've successfully built it in multiple circumstances. The only thing I'm
worried about (I'm on the road now and can't test) is what will occur if wc
is fed a zero-length input... ie, a "touched" file or a echo "" | wc -L.

On Fri, Dec 5, 2008 at 3:23 PM, Garrett Cooper <yanefbsd@gmail.com> wrote:

> On Fri, Dec 5, 2008 at 3:14 PM, Kostik Belousov <kostikbel@gmail.com>
> wrote:
> > On Fri, Dec 05, 2008 at 03:10:56PM -0800, Sheldon Givens wrote:
> >> What's the problem having it? The total code is mere bytes and it eases
> the
> >> transition for others who are migrating from Linux.
> >> You're absolutely right in that it can be done with awk (fairly simply,
> too)
> >> but it doesn't hurt to explore options. Additionally, with awk, you
> can't
> >> get other figures with the same command, which increases ease of use.
> >> IE: What's the equivalent to "wc -clwL" in awk? Would you really rather
> run
> >> wc -clw && awk '{if(length>x){x=length}}END{if(x>0){print x}else{print
> >> 0}}'`?
> >>
> >> Isn't wc -L a more elegant solution than awk
> >> '{if(length>x){x=length}}END{if(x>0){print x}else{print 0}}'`?
> >>
> >> Should I continue?
> >
> > Real argument pro is that you have one less thing to worry when you
> > trying to run some script, written on Linux, on the FreeBSD system.
> >
> >>
> >> On Fri, Dec 5, 2008 at 2:48 PM, Garrett Cooper <yanefbsd@gmail.com>
> wrote:
> >>
> >> > On Fri, Dec 5, 2008 at 2:14 PM, Sheldon Givens <sheldon@sigsegv.ca>
> wrote:
> >> > > Hello everyone,
> >> > > In the process of migrating the last of a few Linux servers to
> FreeBSD,
> >> > we
> >> > > ran in to a bit of a snag with one of our scripts when BSD wc didn't
> have
> >> > an
> >> > > equivalent to the Linux -L. This flag tells wc to keep track of the
> >> > longest
> >> > > line in the input.
> >> > >
> >> > > Here's a little diff to add this functionality to BSD wc.
> >> > >
> >> > > With this patch, an additional parameter is added to output that
> shows
> >> > the
> >> > > length of the longest line
> >> > >
> >> > > My apologies if this is in the wrong format. I don't often post
> here.
> >> > >
> >> > > Happy Holidays,
> >> > >
> >> > > Sheldon Givens
> >> > >
> >> > >
> >> > > ---snip---
> >> > > 65,66c65,66
> >> > > < uintmax_t tlinect, twordct, tcharct;
> >> > > < int doline, doword, dochar, domulti;
> >> > > ---
> >> > >> uintmax_t tlinect, twordct, tcharct, tlongline;
> >> > >> int doline, doword, dochar, domulti, dolongline;
> >> > > 78c78
> >> > > <       while ((ch = getopt(argc, argv, "clmw")) != -1)
> >> > > ---
> >> > >>       while ((ch = getopt(argc, argv, "clmwL")) != -1)
> >> > > 93a94,96
> >> > >>               case 'L':
> >> > >>                       dolongline = 1;
> >> > >>                       break;
> >> > > 127a131,132
> >> > >>               if (dolongline)
> >> > >>                       (void)printf(" %7ju", tlongline);
> >> > > 137c142
> >> > > <       uintmax_t linect, wordct, charct;
> >> > > ---
> >> > >>       uintmax_t linect, wordct, charct, llcnt, tmpll;
> >> > > 146c151
> >> > > <       linect = wordct = charct = 0;
> >> > > ---
> >> > >>       linect = wordct = charct = llcnt = tmpll = 0;
> >> > > 171c176,179
> >> > > <                                       if (*p == '\n')
> >> > > ---
> >> > >>                                       if (*p == '\n') {
> >> > >>                                               if (tmpll > llcnt)
> >> > >>                                                       llcnt =
> tmpll;
> >> > >>                                               tmpll = 0;
> >> > > 172a181
> >> > >>                                       } else { tmpll++; }
> >> > > 179a189,192
> >> > >>                       if (dolongline) {
> >> > >>                               tlongline = llcnt;
> >> > >>                               (void)printf(" %7ju", tlongline);
> >> > >>                       }
> >> > > 197c210
> >> > > <                               return (0);
> >> > > ---
> >> > >>                       return (0);
> >> > > 231a245
> >> > >>                       tmpll++;
> >> > > 234c248,251
> >> > > <                       if (wch == L'\n')
> >> > > ---
> >> > >>                       if (wch == L'\n') {
> >> > >>                               if (tmpll > llcnt)
> >> > >>                                       llcnt = tmpll;
> >> > >>                               tmpll = 0;
> >> > > 235a253
> >> > >>                       }
> >> > > 258a277,280
> >> > >>       if (dolongline) {
> >> > >>               tlongline = llcnt;
> >> > >>               (void)printf(" %7ju", llcnt - 1);
> >> > >>       }
> >> > > 266c288
> >> > > <       (void)fprintf(stderr, "usage: wc [-clmw] [file ...]\n");
> >> > > ---
> >> > >>       (void)fprintf(stderr, "usage: wc [-clmwL] [file ...]\n");
> >> > >
> >> > > ---unsnip---
> >> >
> >> > What's the plus side of having this? I can accomplish the same with
> >> > something like awk without the additional overhead, which would be
> >> > guaranteed to be portable.
> >> > -Garrett
>
> Very true. Ok, I've been easily won over :).
> The patch looks largely ok, but have you gone through compiling it in
> your own dev tree (vatting out possible warnings, etc).
> -Garrett
>
From mwm-keyword-freebsdhackers2.e313df at mired.org  Fri Dec  5 15:40:17 2008
From: mwm-keyword-freebsdhackers2.e313df at mired.org (Mike Meyer)
Date: Fri Dec  5 15:40:24 2008
Subject: Small change to wc
In-Reply-To: <20081205231458.GY2038@deviant.kiev.zoral.com.ua>
References: <f4ecc0930812051414n17867e1fi80d6ed458e879bde@mail.gmail.com>
	<7d6fde3d0812051448r1581d666v50d162cae348982a@mail.gmail.com>
	<f4ecc0930812051510v323ae95anccaca18d28fd174@mail.gmail.com>
	<20081205231458.GY2038@deviant.kiev.zoral.com.ua>
Message-ID: <20081205183949.6ee1d288@bhuda.mired.org>

On Sat, 6 Dec 2008 01:14:58 +0200
Kostik Belousov <kostikbel@gmail.com> wrote:

> On Fri, Dec 05, 2008 at 03:10:56PM -0800, Sheldon Givens wrote:
> > What's the problem having it? The total code is mere bytes and it eases the
> > transition for others who are migrating from Linux.
> > You're absolutely right in that it can be done with awk (fairly simply, too)
> > but it doesn't hurt to explore options. Additionally, with awk, you can't
> > get other figures with the same command, which increases ease of use.
> > IE: What's the equivalent to "wc -clwL" in awk? Would you really rather run
> > wc -clw && awk '{if(length>x){x=length}}END{if(x>0){print x}else{print
> > 0}}'`?
> > 
> > Isn't wc -L a more elegant solution than awk
> > '{if(length>x){x=length}}END{if(x>0){print x}else{print 0}}'`?
> > 
> > Should I continue?
> 
> Real argument pro is that you have one less thing to worry when you
> trying to run some script, written on Linux, on the FreeBSD system.

Real argument con is that you're making life easier on users of
GNU/Linux software whose authors ought to be taught how to write
portable code.

I think compatibility with GNU/Linux is a miserable reason for
bloating software on BSD - especially considering how NU the typical
GNU/Linux extensions are. However, this seems like a useful feature in
and of itself, and fits in well with the command it's being added to.
So adding it - and adding it to wc - seem like reasonable things. And
if we're going to add a feature to a command, making it compatible
with an existing implementation seems like a good idea.

       <mike
-- 
Mike Meyer <mwm@mired.org>		http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.

O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
From keramida at ceid.upatras.gr  Fri Dec  5 16:17:13 2008
From: keramida at ceid.upatras.gr (Giorgos Keramidas)
Date: Fri Dec  5 16:17:22 2008
Subject: Small change to wc
In-Reply-To: <f4ecc0930812051414n17867e1fi80d6ed458e879bde@mail.gmail.com>
	(Sheldon Givens's message of "Fri, 5 Dec 2008 14:14:32 -0800")
References: <f4ecc0930812051414n17867e1fi80d6ed458e879bde@mail.gmail.com>
Message-ID: <871vwmtawz.fsf@kobe.laptop>

On Fri, 5 Dec 2008 14:14:32 -0800, "Sheldon Givens" <sheldon@sigsegv.ca> wrote:
> Hello everyone,
> In the process of migrating the last of a few Linux servers to
> FreeBSD, we ran in to a bit of a snag with one of our scripts when BSD
> wc didn't have an equivalent to the Linux -L. This flag tells wc to
> keep track of the longest line in the input.
>
> Here's a little diff to add this functionality to BSD wc.
>
> With this patch, an additional parameter is added to output that shows
> the length of the longest line

Adding the option to increase finger-compatibility and make shell
scripts a bit easier to port over sounds fine by me :)

> My apologies if this is in the wrong format. I don't often post here.
> ---snip---
> [patch]
> ---unsnip---

Can you post a `diff -u' or `diff -c' version of the patch?  I like the
idea of the new option but it would be easier to read in -u/-c format.
From sheldon at sigsegv.ca  Fri Dec  5 18:46:01 2008
From: sheldon at sigsegv.ca (Sheldon Givens)
Date: Fri Dec  5 18:46:08 2008
Subject: Small change to wc
In-Reply-To: <871vwmtawz.fsf@kobe.laptop>
References: <f4ecc0930812051414n17867e1fi80d6ed458e879bde@mail.gmail.com>
	<871vwmtawz.fsf@kobe.laptop>
Message-ID: <f4ecc0930812051846n27308fbdue6ea50a909d8d6ab@mail.gmail.com>

New diff -u:


--- /usr/src/usr.bin/wc/wc.c    2004-12-27 14:27:56.000000000 -0800
+++ wc/wc.c     2008-12-05 14:33:21.000000000 -0800
@@ -62,8 +62,8 @@
 #include <wchar.h>
 #include <wctype.h>
-uintmax_t tlinect, twordct, tcharct;
-int doline, doword, dochar, domulti;
+uintmax_t tlinect, twordct, tcharct, tlongline;
+int doline, doword, dochar, domulti, dolongline;
 static int     cnt(const char *);
 static void    usage(void);
@@ -75,7 +75,7 @@
        (void) setlocale(LC_CTYPE, "");
-       while ((ch = getopt(argc, argv, "clmw")) != -1)
+       while ((ch = getopt(argc, argv, "clmwL")) != -1)
                switch((char)ch) {
                case 'l':
                        doline = 1;
@@ -91,6 +91,9 @@
                        domulti = 1;
                        dochar = 0;
                        break;
+               case 'L':
+                       dolongline = 1;
+                       break;
                case '?':
                default:
                        usage();
@@ -125,6 +128,8 @@
                        (void)printf(" %7ju", twordct);
                if (dochar || domulti)
                        (void)printf(" %7ju", tcharct);
+               if (dolongline)
+                       (void)printf(" %7ju", tlongline);
                (void)printf(" total\n");
        }
        exit(errors == 0 ? 0 : 1);
@@ -134,7 +139,7 @@
 cnt(const char *file)
 {
        struct stat sb;
-       uintmax_t linect, wordct, charct;
+       uintmax_t linect, wordct, charct, llcnt, tmpll;
        int fd, len, warned;
        size_t clen;
        short gotsp;
@@ -143,7 +148,7 @@
        wchar_t wch;
        mbstate_t mbs;
-       linect = wordct = charct = 0;
+       linect = wordct = charct = llcnt = tmpll = 0;
        if (file == NULL) {
                file = "stdin";
                fd = STDIN_FILENO;
@@ -167,9 +172,13 @@
                                        return (1);
                                }
                                charct += len;
-                               for (p = buf; len--; ++p)
-                                       if (*p == '\n')
+                               for (p = buf; len--; ++p)
+                                       if (*p == '\n') {
+                                               if (tmpll > llcnt)
+                                                       llcnt = tmpll;
+                                               tmpll = 0;
                                                ++linect;
+                                               } else {tmpll++;}
                        }
                        tlinect += linect;
                        (void)printf(" %7ju", linect);
@@ -177,6 +186,10 @@
                                tcharct += charct;
                                (void)printf(" %7ju", charct);
                        }
+                       if (dolongline) {
+                               tlongline = llcnt;
+                               (void)printf(" %7ju", tlongline);
+                       }
                        (void)close(fd);
                        return (0);
                }
@@ -194,7 +207,7 @@
                                (void)printf(" %7lld", (long
long)sb.st_size);
                                tcharct += sb.st_size;
                                (void)close(fd);
-                               return (0);
+                       return (0);
                        }
                }
        }
@@ -229,10 +242,15 @@
                        else if (clen == 0)
                                clen = 1;
                        charct++;
+                       tmpll++;
                        len -= clen;
                        p += clen;
-                       if (wch == L'\n')
+                       if (wch == L'\n') {
+                               if (tmpll > llcnt)
+                                       llcnt = tmpll;
+                               tmpll = 0;
                                ++linect;
+                       }
                        if (iswspace(wch))
                                gotsp = 1;
                        else if (gotsp) {
@@ -256,6 +274,10 @@
                tcharct += charct;
                (void)printf(" %7ju", charct);
        }
+       if (dolongline) {
+               tlongline = llcnt;
+               (void)printf(" %7ju", llcnt - 1);
+       }
        (void)close(fd);
        return (0);
 }
@@ -263,6 +285,6 @@
 static void
 usage()
 {
-       (void)fprintf(stderr, "usage: wc [-clmw] [file ...]\n");
+       (void)fprintf(stderr, "usage: wc [-clmwL] [file ...]\n");
        exit(1);
 }



On Fri, Dec 5, 2008 at 4:17 PM, Giorgos Keramidas
<keramida@ceid.upatras.gr>wrote:

> On Fri, 5 Dec 2008 14:14:32 -0800, "Sheldon Givens" <sheldon@sigsegv.ca>
> wrote:
> > Hello everyone,
> > In the process of migrating the last of a few Linux servers to
> > FreeBSD, we ran in to a bit of a snag with one of our scripts when BSD
> > wc didn't have an equivalent to the Linux -L. This flag tells wc to
> > keep track of the longest line in the input.
> >
> > Here's a little diff to add this functionality to BSD wc.
> >
> > With this patch, an additional parameter is added to output that shows
> > the length of the longest line
>
> Adding the option to increase finger-compatibility and make shell
> scripts a bit easier to port over sounds fine by me :)
>
> > My apologies if this is in the wrong format. I don't often post here.
> > ---snip---
> > [patch]
> > ---unsnip---
>
> Can you post a `diff -u' or `diff -c' version of the patch?  I like the
> idea of the new option but it would be easier to read in -u/-c format.
>
From yanefbsd at gmail.com  Fri Dec  5 20:01:09 2008
From: yanefbsd at gmail.com (Garrett Cooper)
Date: Fri Dec  5 20:01:15 2008
Subject: Small change to wc
In-Reply-To: <f4ecc0930812051528t5d005585ta5c3af7e3ed5d72b@mail.gmail.com>
References: <f4ecc0930812051414n17867e1fi80d6ed458e879bde@mail.gmail.com>
	<7d6fde3d0812051448r1581d666v50d162cae348982a@mail.gmail.com>
	<f4ecc0930812051510v323ae95anccaca18d28fd174@mail.gmail.com>
	<20081205231458.GY2038@deviant.kiev.zoral.com.ua>
	<7d6fde3d0812051523p6be3fc19re3322f3ddba78b1e@mail.gmail.com>
	<f4ecc0930812051528t5d005585ta5c3af7e3ed5d72b@mail.gmail.com>
Message-ID: <7d6fde3d0812052001g4742c2l45cb830e1ea85c9@mail.gmail.com>

On Fri, Dec 5, 2008 at 3:28 PM, Sheldon Givens <sheldon@sigsegv.ca> wrote:
> I've successfully built it in multiple circumstances. The only thing I'm
> worried about (I'm on the road now and can't test) is what will occur if wc
> is fed a zero-length input... ie, a "touched" file or a echo "" | wc -L.
>
> On Fri, Dec 5, 2008 at 3:23 PM, Garrett Cooper <yanefbsd@gmail.com> wrote:
>>
>> On Fri, Dec 5, 2008 at 3:14 PM, Kostik Belousov <kostikbel@gmail.com>
>> wrote:
>> > On Fri, Dec 05, 2008 at 03:10:56PM -0800, Sheldon Givens wrote:
>> >> What's the problem having it? The total code is mere bytes and it eases
>> >> the
>> >> transition for others who are migrating from Linux.
>> >> You're absolutely right in that it can be done with awk (fairly simply,
>> >> too)
>> >> but it doesn't hurt to explore options. Additionally, with awk, you
>> >> can't
>> >> get other figures with the same command, which increases ease of use.
>> >> IE: What's the equivalent to "wc -clwL" in awk? Would you really rather
>> >> run
>> >> wc -clw && awk '{if(length>x){x=length}}END{if(x>0){print x}else{print
>> >> 0}}'`?
>> >>
>> >> Isn't wc -L a more elegant solution than awk
>> >> '{if(length>x){x=length}}END{if(x>0){print x}else{print 0}}'`?
>> >>
>> >> Should I continue?
>> >
>> > Real argument pro is that you have one less thing to worry when you
>> > trying to run some script, written on Linux, on the FreeBSD system.
>> >
>> >>
>> >> On Fri, Dec 5, 2008 at 2:48 PM, Garrett Cooper <yanefbsd@gmail.com>
>> >> wrote:
>> >>
>> >> > On Fri, Dec 5, 2008 at 2:14 PM, Sheldon Givens <sheldon@sigsegv.ca>
>> >> > wrote:
>> >> > > Hello everyone,
>> >> > > In the process of migrating the last of a few Linux servers to
>> >> > > FreeBSD,
>> >> > we
>> >> > > ran in to a bit of a snag with one of our scripts when BSD wc
>> >> > > didn't have
>> >> > an
>> >> > > equivalent to the Linux -L. This flag tells wc to keep track of the
>> >> > longest
>> >> > > line in the input.
>> >> > >
>> >> > > Here's a little diff to add this functionality to BSD wc.
>> >> > >
>> >> > > With this patch, an additional parameter is added to output that
>> >> > > shows
>> >> > the
>> >> > > length of the longest line
>> >> > >
>> >> > > My apologies if this is in the wrong format. I don't often post
>> >> > > here.
>> >> > >
>> >> > > Happy Holidays,
>> >> > >
>> >> > > Sheldon Givens
>> >> > >
>> >> > >
>> >> > > ---snip---
>> >> > > 65,66c65,66
>> >> > > < uintmax_t tlinect, twordct, tcharct;
>> >> > > < int doline, doword, dochar, domulti;
>> >> > > ---
>> >> > >> uintmax_t tlinect, twordct, tcharct, tlongline;
>> >> > >> int doline, doword, dochar, domulti, dolongline;
>> >> > > 78c78
>> >> > > <       while ((ch = getopt(argc, argv, "clmw")) != -1)
>> >> > > ---
>> >> > >>       while ((ch = getopt(argc, argv, "clmwL")) != -1)
>> >> > > 93a94,96
>> >> > >>               case 'L':
>> >> > >>                       dolongline = 1;
>> >> > >>                       break;
>> >> > > 127a131,132
>> >> > >>               if (dolongline)
>> >> > >>                       (void)printf(" %7ju", tlongline);
>> >> > > 137c142
>> >> > > <       uintmax_t linect, wordct, charct;
>> >> > > ---
>> >> > >>       uintmax_t linect, wordct, charct, llcnt, tmpll;
>> >> > > 146c151
>> >> > > <       linect = wordct = charct = 0;
>> >> > > ---
>> >> > >>       linect = wordct = charct = llcnt = tmpll = 0;
>> >> > > 171c176,179
>> >> > > <                                       if (*p == '\n')
>> >> > > ---
>> >> > >>                                       if (*p == '\n') {
>> >> > >>                                               if (tmpll > llcnt)
>> >> > >>                                                       llcnt =
>> >> > >> tmpll;
>> >> > >>                                               tmpll = 0;
>> >> > > 172a181
>> >> > >>                                       } else { tmpll++; }
>> >> > > 179a189,192
>> >> > >>                       if (dolongline) {
>> >> > >>                               tlongline = llcnt;
>> >> > >>                               (void)printf(" %7ju", tlongline);
>> >> > >>                       }
>> >> > > 197c210
>> >> > > <                               return (0);
>> >> > > ---
>> >> > >>                       return (0);
>> >> > > 231a245
>> >> > >>                       tmpll++;
>> >> > > 234c248,251
>> >> > > <                       if (wch == L'\n')
>> >> > > ---
>> >> > >>                       if (wch == L'\n') {
>> >> > >>                               if (tmpll > llcnt)
>> >> > >>                                       llcnt = tmpll;
>> >> > >>                               tmpll = 0;
>> >> > > 235a253
>> >> > >>                       }
>> >> > > 258a277,280
>> >> > >>       if (dolongline) {
>> >> > >>               tlongline = llcnt;
>> >> > >>               (void)printf(" %7ju", llcnt - 1);
>> >> > >>       }
>> >> > > 266c288
>> >> > > <       (void)fprintf(stderr, "usage: wc [-clmw] [file ...]\n");
>> >> > > ---
>> >> > >>       (void)fprintf(stderr, "usage: wc [-clmwL] [file ...]\n");
>> >> > >
>> >> > > ---unsnip---
>> >> >
>> >> > What's the plus side of having this? I can accomplish the same with
>> >> > something like awk without the additional overhead, which would be
>> >> > guaranteed to be portable.
>> >> > -Garrett
>>
>> Very true. Ok, I've been easily won over :).
>> The patch looks largely ok, but have you gone through compiling it in
>> your own dev tree (vatting out possible warnings, etc).
>> -Garrett

1. Please don't top-post.
2. Solving the problem is easy. Have the value default to something
unrealistic (like -1) and simply, set the value to 0, if indeed the
value is < 0.
Cheers,
-Garrett
From danny at cs.huji.ac.il  Sat Dec  6 00:43:33 2008
From: danny at cs.huji.ac.il (Danny Braniss)
Date: Sat Dec  6 00:43:45 2008
Subject: IPMI shared ethernet ports (again). 
In-Reply-To: <5f67a8c40812051010u55ef6d70m1b4270c98852d87c@mail.gmail.com> 
References: <5f67a8c40812051010u55ef6d70m1b4270c98852d87c@mail.gmail.com>
Message-ID: <E1L8sl9-000HvW-CR@kabab.cs.huji.ac.il>

> I posted here a month or two ago about being amazed that some system
> management cards can share a physical ethernet port.  Some of you responded
> that it doesn't always work.
> 
> Well... I've encountered this and I'm wondering if I can work around it
> somehow.
> 
> The ones that work are in Dell 1950-III servers (The R-200 seem to work,
> too).  They have "bce" driver ports.
> 
> The HP DL/360 that I have here today have "bge" driver ports and the IPMI
> console appears to stop working just as soon as FreeBSD probes the port.
> 
> Is this something that can be configured in BGE or is it just not going to
> work?
>
set 
	hw.bge.allow_asf=1
in /boot/loader.conf

from man bge:
     hw.bge.allow_asf
             Allow the ASF feature for cooperating with IPMI.  Can cause sys-
             tem lockup problems on a small number of systems.  Disabled by
             default.
cheers,
	danny
 _______________________________________________
> freebsd-hackers@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
> 


From keramida at freebsd.org  Sat Dec  6 04:09:06 2008
From: keramida at freebsd.org (Giorgos Keramidas)
Date: Sat Dec  6 04:09:12 2008
Subject: Small change to wc
In-Reply-To: <f4ecc0930812051846n27308fbdue6ea50a909d8d6ab@mail.gmail.com>
	(Sheldon Givens's message of "Fri, 5 Dec 2008 18:46:00 -0800")
References: <f4ecc0930812051414n17867e1fi80d6ed458e879bde@mail.gmail.com>
	<871vwmtawz.fsf@kobe.laptop>
	<f4ecc0930812051846n27308fbdue6ea50a909d8d6ab@mail.gmail.com>
Message-ID: <87prk5ms72.fsf@kobe.laptop>

On Fri, 5 Dec 2008 18:46:00 -0800, "Sheldon Givens" <sheldon@sigsegv.ca> wrote:
> On Fri, Dec 5, 2008 at 4:17 PM, Giorgos Keramidas <keramida@ceid.upatras.gr>wrote:
>> Adding the option to increase finger-compatibility and make shell
>> scripts a bit easier to port over sounds fine by me :)
>>
>> > My apologies if this is in the wrong format. I don't often post here.
>> > ---snip---
>> > [patch]
>> > ---unsnip---
>>
>> Can you post a `diff -u' or `diff -c' version of the patch?  I like the
>> idea of the new option but it would be easier to read in -u/-c format.
>
> New diff -u:

Excellent, thanks!  Other than a few minor style-bugs, which can be
fixed before committing it (see inline comments for details), the patch
looks great to me :-)

> --- /usr/src/usr.bin/wc/wc.c    2004-12-27 14:27:56.000000000 -0800
> +++ wc/wc.c     2008-12-05 14:33:21.000000000 -0800
> @@ -167,9 +172,13 @@
>                                         return (1);
>                                 }
>                                 charct += len;
> -                               for (p = buf; len--; ++p)
> -                                       if (*p == '\n')
> +                               for (p = buf; len--; ++p)
> +                                       if (*p == '\n') {
> +                                               if (tmpll > llcnt)
> +                                                       llcnt = tmpll;
> +                                               tmpll = 0;
>                                                 ++linect;
> +                                               } else {tmpll++;}

It's probably more 'stylish' to write the else part as:

                                       if (*p == '\n') {
                                               if (tmpll > llcnt)
                                                       llcnt = tmpll;
                                               tmpll = 0;
                                               ++linect;
                                       } else
                                               tmpll++;

> @@ -194,7 +207,7 @@
>                                 (void)printf(" %7lld", (long
> long)sb.st_size);
>                                 tcharct += sb.st_size;
>                                 (void)close(fd);
> -                               return (0);
> +                       return (0);

This change only removes indendation from a return statement.  We should
probably keep it out of the final commit.

Thanks for writing & posting the patch :-)

From keramida at ceid.upatras.gr  Sat Dec  6 07:40:28 2008
From: keramida at ceid.upatras.gr (Giorgos Keramidas)
Date: Sat Dec  6 07:40:37 2008
Subject: Small change to wc
In-Reply-To: <87prk5ms72.fsf@kobe.laptop> (Giorgos Keramidas's message of
	"Sat, 06 Dec 2008 13:57:53 +0200")
References: <f4ecc0930812051414n17867e1fi80d6ed458e879bde@mail.gmail.com>
	<871vwmtawz.fsf@kobe.laptop>
	<f4ecc0930812051846n27308fbdue6ea50a909d8d6ab@mail.gmail.com>
	<87prk5ms72.fsf@kobe.laptop>
Message-ID: <878wqtia75.fsf@kobe.laptop>

On Sat, 06 Dec 2008 13:57:53 +0200, Giorgos Keramidas <keramida@freebsd.org> wrote:
>>> Can you post a `diff -u' or `diff -c' version of the patch?  I like the
>>> idea of the new option but it would be easier to read in -u/-c format.
>>
>> New diff -u:
>
> Excellent, thanks!  Other than a few minor style-bugs, which can be
> fixed before committing it (see inline comments for details), the patch
> looks great to me :-)

Ok, I've fixed a few minor bugs I noticed:

  * When only -L is specified it should not enable the default 'cwl' set
    of options.
  * The tlongline total length should not be overwritten by each input
    file, unless we *did* find a longer line in the particular file.
  * The (llct - 1) trick is not needed when printing llcnt if we only
    count != '\n' characters near line 229.

The updated patch, and a manpage change to document the new option is
attached below.  Konstantin, if you like this version of the patch, I'll
commit it to /head and schedule an MFC after a week or so.

The longer line length that -L reports seems to work like this here:

: keramida@kobe:/hg/bsd/src/usr.bin/wc$ ./wc /etc/rc.conf
:      114     222    2632 /etc/rc.conf
: keramida@kobe:/hg/bsd/src/usr.bin/wc$ ./wc -L /etc/rc.conf
:       82 /etc/rc.conf
: keramida@kobe:/hg/bsd/src/usr.bin/wc$ ./wc -lwc -L /etc/rc.conf
:      114     222    2632      82 /etc/rc.conf
: keramida@kobe:/hg/bsd/src/usr.bin/wc$ ./wc -lwc -L /etc/rc.????
:      114     222    2632      82 /etc/rc.conf
:     1598    5648   36725      85 /etc/rc.subr
:     1712    5870   39357      85 total
: keramida@kobe:/hg/bsd/src/usr.bin/wc$

Here's the current patch version...

%%%
diff -r fb56dd4c9c47 usr.bin/wc/wc.1
--- a/usr.bin/wc/wc.1	Sat Dec 06 17:04:51 2008 +0200
+++ b/usr.bin/wc/wc.1	Sat Dec 06 17:39:17 2008 +0200
@@ -43,7 +43,7 @@
 .Nd word, line, character, and byte count
 .Sh SYNOPSIS
 .Nm
-.Op Fl clmw
+.Op Fl Lclmw
 .Op Ar
 .Sh DESCRIPTION
 The
@@ -71,6 +71,15 @@
 .Pp
 The following options are available:
 .Bl -tag -width indent
+.It Fl L
+The number of characters in the longest input line
+is written to the standard output.
+When more then one
+.Ar file
+argument is specified, the longest input line of
+.Em all
+files is reported as the value of the final
+.Dq total .
 .It Fl c
 The number of bytes in each input file
 is written to the standard output.
@@ -129,6 +138,10 @@
 as well as the totals for both:
 .Pp
 .Dl "wc -mlw report1 report2"
+.Pp
+Find the longest line in a list of files:
+.Pp
+.Dl "wc -L file1 file2 file3 | fgrep total"
 .Sh COMPATIBILITY
 Historically, the
 .Nm
@@ -154,6 +167,16 @@
 .Xr iswspace 3
 function, as required by
 .St -p1003.2 .
+.Pp
+The
+.Fl L
+option is a non-standard
+.Fx
+extension, compatible with the
+.Fl L
+option of the GNU
+.Nm
+utility.
 .Sh SEE ALSO
 .Xr iswspace 3
 .Sh STANDARDS
diff -r fb56dd4c9c47 usr.bin/wc/wc.c
--- a/usr.bin/wc/wc.c	Sat Dec 06 17:04:51 2008 +0200
+++ b/usr.bin/wc/wc.c	Sat Dec 06 17:39:17 2008 +0200
@@ -62,8 +62,8 @@
 #include <wchar.h>
 #include <wctype.h>
 
-uintmax_t tlinect, twordct, tcharct;
-int doline, doword, dochar, domulti;
+uintmax_t tlinect, twordct, tcharct, tlongline;
+int doline, doword, dochar, domulti, dolongline;
 
 static int	cnt(const char *);
 static void	usage(void);
@@ -75,7 +75,7 @@
 
 	(void) setlocale(LC_CTYPE, "");
 
-	while ((ch = getopt(argc, argv, "clmw")) != -1)
+	while ((ch = getopt(argc, argv, "clmwL")) != -1)
 		switch((char)ch) {
 		case 'l':
 			doline = 1;
@@ -87,6 +87,9 @@
 			dochar = 1;
 			domulti = 0;
 			break;
+		case 'L':
+			dolongline = 1;
+			break;
 		case 'm':
 			domulti = 1;
 			dochar = 0;
@@ -99,7 +102,7 @@
 	argc -= optind;
 
 	/* Wc's flags are on by default. */
-	if (doline + doword + dochar + domulti == 0)
+	if (doline + doword + dochar + domulti + dolongline == 0)
 		doline = doword = dochar = 1;
 
 	errors = 0;
@@ -125,6 +128,8 @@
 			(void)printf(" %7ju", twordct);
 		if (dochar || domulti)
 			(void)printf(" %7ju", tcharct);
+		if (dolongline)
+			(void)printf(" %7ju", tlongline);
 		(void)printf(" total\n");
 	}
 	exit(errors == 0 ? 0 : 1);
@@ -134,7 +139,7 @@
 cnt(const char *file)
 {
 	struct stat sb;
-	uintmax_t linect, wordct, charct;
+	uintmax_t linect, wordct, charct, llct, tmpll;
 	int fd, len, warned;
 	size_t clen;
 	short gotsp;
@@ -143,7 +148,7 @@
 	wchar_t wch;
 	mbstate_t mbs;
 
-	linect = wordct = charct = 0;
+	linect = wordct = charct = llct = tmpll = 0;
 	if (file == NULL) {
 		file = "stdin";
 		fd = STDIN_FILENO;
@@ -168,8 +173,13 @@
 				}
 				charct += len;
 				for (p = buf; len--; ++p)
-					if (*p == '\n')
+					if (*p == '\n') {
+						if (tmpll > llct)
+							llct = tmpll;
+						tmpll = 0;
 						++linect;
+					} else
+						tmpll++;
 			}
 			tlinect += linect;
 			(void)printf(" %7ju", linect);
@@ -177,6 +187,11 @@
 				tcharct += charct;
 				(void)printf(" %7ju", charct);
 			}
+			if (dolongline) {
+				if (llct > tlongline)
+					tlongline = llct;
+				(void)printf(" %7ju", tlongline);
+			}
 			(void)close(fd);
 			return (0);
 		}
@@ -229,10 +244,16 @@
 			else if (clen == 0)
 				clen = 1;
 			charct++;
+			if (wch != L'\n')
+				tmpll++;
 			len -= clen;
 			p += clen;
-			if (wch == L'\n')
+			if (wch == L'\n') {
+				if (tmpll > llct)
+					llct = tmpll;
+				tmpll = 0;
 				++linect;
+			}
 			if (iswspace(wch))
 				gotsp = 1;
 			else if (gotsp) {
@@ -256,6 +277,11 @@
 		tcharct += charct;
 		(void)printf(" %7ju", charct);
 	}
+	if (dolongline) {
+		if (llct > tlongline)
+			tlongline = llct;
+		(void)printf(" %7ju", llct);
+	}
 	(void)close(fd);
 	return (0);
 }
@@ -263,6 +289,6 @@
 static void
 usage()
 {
-	(void)fprintf(stderr, "usage: wc [-clmw] [file ...]\n");
+	(void)fprintf(stderr, "usage: wc [-Lclmw] [file ...]\n");
 	exit(1);
 }
%%%
From ed at 80386.nl  Sat Dec  6 07:59:09 2008
From: ed at 80386.nl (Ed Schouten)
Date: Sat Dec  6 07:59:16 2008
Subject: Syscons with xterm emulation: one step closer to UTF-8 support?
Message-ID: <20081206155908.GG18652@hoeg.nl>

Hello all,

I may have mentioned this to some people some time ago, but I thought it
would be nice to start a thread about this here on -hackers:

A couple of weeks ago I started working on a library (libteken) that
implements a subset of features (escape sequences) of xterm, our trusty
X11 terminal application. I've done most hacking/testing in userspace,
but this week I experimented with removing the terminal emulation from
syscons and replaced it by the library. The result:

- We can finally SSH to other operating systems, network switches, etc.
  without messing up our terminals. Almost any operating system out
  there has termcap entries for `xterm', which means stuff should Just
  Work (tm).

- My library only accepts one character set of input: UTF-8. Right now
  it just directly forwards the character codes to Syscons, hoping
  Syscons has a character map that is capable of displaying them (which
  doesn't work).

There are still many small issues I have to fix in the terminal
emulation library, but also in the Syscons <-> libteken code. I won't
commit it on short notice, obviously. If people want to test it, the
code is in the MPSAFE TTY branch in Perforce. Diffs are available at:

	http://people.FreeBSD.org/~ed/mpsafetty/

My question is if there are people out there who could help me
implementing UTF-8 font rendering. I wouldn't have a clue where to
start (yet).

Yours,
-- 
 Ed Schouten <ed@80386.nl>
 WWW: http://80386.nl/
-------------- 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-hackers/attachments/20081206/01ca8a2d/attachment.pgp
From keramida at ceid.upatras.gr  Sat Dec  6 11:25:25 2008
From: keramida at ceid.upatras.gr (Giorgos Keramidas)
Date: Sat Dec  6 11:25:32 2008
Subject: Small change to wc
In-Reply-To: <878wqtia75.fsf@kobe.laptop> (Giorgos Keramidas's message of
	"Sat, 06 Dec 2008 17:40:14 +0200")
References: <f4ecc0930812051414n17867e1fi80d6ed458e879bde@mail.gmail.com>
	<871vwmtawz.fsf@kobe.laptop>
	<f4ecc0930812051846n27308fbdue6ea50a909d8d6ab@mail.gmail.com>
	<87prk5ms72.fsf@kobe.laptop> <878wqtia75.fsf@kobe.laptop>
Message-ID: <87ljut2jji.fsf@kobe.laptop>

On Sat, 06 Dec 2008 17:40:14 +0200, Giorgos Keramidas <keramida@ceid.upatras.gr> wrote:
> The updated patch, and a manpage change to document the new option is
> attached below.  Konstantin, if you like this version of the patch,
> I'll commit it to /head and schedule an MFC after a week or so.

Committed to /head as change 185714:

http://svn.freebsd.org/viewvc/base?view=revision&revision=185714

Sheldon, thanks for the patch.  I will merge it to the stable branches
after about a few days :-)

From killing at multiplay.co.uk  Sat Dec  6 15:48:16 2008
From: killing at multiplay.co.uk (Steven Hartland)
Date: Sat Dec  6 15:48:23 2008
Subject: unionfs kernel panic on 7.1-PRERELEASE
References: <29A6B82D99A749799B4D662ABAE6A960@multiplay.co.uk><20081202203939.GD3045@deviant.kiev.zoral.com.ua>
	<7F18FDB94BC14E3995D15F0C3BD6312D@multiplay.co.uk>
Message-ID: <C8ACB40002FC495FA983E2B9295294C2@multiplay.co.uk>

Did you have any ideas where the root of this problem may lie Kostik?

----- Original Message ----- 
From: "Steven Hartland" <killing@multiplay.co.uk>


> Yes every time, I've got a half life 2 dedicated install mounted under unionfs:-
> mount -t unionfs -o noatime -o below /usr/local/games/hl2ds /usr/local/games/servers/1
> 
> As soon as I start the server from under servers/1 the machine panics I'm thinking its
> a combination of the Linux ABI and unionfs interaction which is causing the issue.
> 
>    Regards
>    Steve
> 
> ----- Original Message ----- 
> From: "Kostik Belousov" <kostikbel@gmail.com>
> To: "Steven Hartland" <killing@multiplay.co.uk>
> Cc: <freebsd-hackers@freebsd.org>
> Sent: Tuesday, December 02, 2008 8:39 PM
> Subject: Re: unionfs kernel panic on 7.1-PRERELEASE
> 
> Is it reproducible ?
> 
> The start of *fdp structure looks very suspicious,
> fd_ofiles = 0x140, fd_ofileflags = 0x154, fd_cdir = 0x168, fd_rdir = 0x17c,
> fd_jdir = 0x18c
> The values are consequently increasing by 0x14, except fd_jdir, and
> pointer values are wrong for kernel.

================================================
This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. 

In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337
or return the E.mail to postmaster@multiplay.co.uk.

From ken at mthelicon.com  Sat Dec  6 19:19:22 2008
From: ken at mthelicon.com (Pegasus Mc Cleaft)
Date: Sat Dec  6 19:19:35 2008
Subject: Problems with zfsboot loader if raidz present on any drive
Message-ID: <200812070319.18461.ken@mthelicon.com>

Hello Hackers, 

	Recently and friend and I have been trying to get the new gptzfsboot working 
on our machines and ran into a interesting problem. 

	Initially I was building the world without the environment variable 
LOADER_ZFS_SUPPORT=YES in the /etc/make.conf and this, of course, didnt work 
very well. Every time the machine booted, it would throw 2 lines after the 
pin-wheel and then reboot. I couldent read what the lines were it went so 
fast. 

	My friend had a bit more luck and got his machine working OK with a single 
drive and later a mirror drive added. 

	I added the environment variable and rebuilt everything and installed. This 
time, I could see the bios drives and a further 2 lines of ZFS something and a 
reboot...

	No matter what I tried, I couldent get the machine to boot up to a point 
where I could try and fix the problem, so I started pulling devices out and 
found the following: If there is a raidz pool on any drive (not necessarily 
the one that you are trying to boot from) the loader dies and reboots the 
machine. My friend, as an experiment created 3 gpt partitions (in addition to 
the single partition that he had been previously booted from) on his single 
drive and made a raidz pool for testing. His machine showed the same condition 
as mine, however he was able to capture the message before the machine 
rebooted:

<message>
ZFS: can only boot from disk or mirror vdevs

ZFS: inconsistent nvlist contents

/
</message>

~Peg

From dfr at rabson.org  Sun Dec  7 01:22:19 2008
From: dfr at rabson.org (Doug Rabson)
Date: Sun Dec  7 01:22:32 2008
Subject: Problems with zfsboot loader if raidz present on any drive
In-Reply-To: <200812070319.18461.ken@mthelicon.com>
References: <200812070319.18461.ken@mthelicon.com>
Message-ID: <66BF33BA-EC11-446F-9DE7-15395F293FE2@rabson.org>


On 7 Dec 2008, at 03:19, Pegasus Mc Cleaft wrote:

> Hello Hackers,
>
> 	Recently and friend and I have been trying to get the new  
> gptzfsboot working
> on our machines and ran into a interesting problem.
>
> 	Initially I was building the world without the environment variable
> LOADER_ZFS_SUPPORT=YES in the /etc/make.conf and this, of course,  
> didnt work
> very well. Every time the machine booted, it would throw 2 lines  
> after the
> pin-wheel and then reboot. I couldent read what the lines were it  
> went so
> fast.
>
> 	My friend had a bit more luck and got his machine working OK with a  
> single
> drive and later a mirror drive added.
>
> 	I added the environment variable and rebuilt everything and  
> installed. This
> time, I could see the bios drives and a further 2 lines of ZFS  
> something and a
> reboot...
>
> 	No matter what I tried, I couldent get the machine to boot up to a  
> point
> where I could try and fix the problem, so I started pulling devices  
> out and
> found the following: If there is a raidz pool on any drive (not  
> necessarily
> the one that you are trying to boot from) the loader dies and  
> reboots the
> machine. My friend, as an experiment created 3 gpt partitions (in  
> addition to
> the single partition that he had been previously booted from) on his  
> single
> drive and made a raidz pool for testing. His machine showed the same  
> condition
> as mine, however he was able to capture the message before the machine
> rebooted:
>
> <message>
> ZFS: can only boot from disk or mirror vdevs
>
> ZFS: inconsistent nvlist contents

The zfsboot code in current doesn't support raidz or raidz2. I have  
been working on adding that support but its not ready yet. The code  
works in my test harness but crashes instantly when I put it in the  
boot code :(. I should have time to finish debugging it soon.

From joao.barros at gmail.com  Sun Dec  7 03:13:34 2008
From: joao.barros at gmail.com (Joao Barros)
Date: Sun Dec  7 03:13:41 2008
Subject: Problems with zfsboot loader if raidz present on any drive
In-Reply-To: <66BF33BA-EC11-446F-9DE7-15395F293FE2@rabson.org>
References: <200812070319.18461.ken@mthelicon.com>
	<66BF33BA-EC11-446F-9DE7-15395F293FE2@rabson.org>
Message-ID: <70e8236f0812070248p3341c24aob024995be08b962a@mail.gmail.com>

On Sun, Dec 7, 2008 at 9:22 AM, Doug Rabson <dfr@rabson.org> wrote:
>
> On 7 Dec 2008, at 03:19, Pegasus Mc Cleaft wrote:
>
>> Hello Hackers,
>>
>>        Recently and friend and I have been trying to get the new
>> gptzfsboot working
>> on our machines and ran into a interesting problem.
>>
>>        Initially I was building the world without the environment variable
>> LOADER_ZFS_SUPPORT=YES in the /etc/make.conf and this, of course, didnt
>> work
>> very well. Every time the machine booted, it would throw 2 lines after the
>> pin-wheel and then reboot. I couldent read what the lines were it went so
>> fast.
>>
>>        My friend had a bit more luck and got his machine working OK with a
>> single
>> drive and later a mirror drive added.
>>
>>        I added the environment variable and rebuilt everything and
>> installed. This
>> time, I could see the bios drives and a further 2 lines of ZFS something
>> and a
>> reboot...
>>
>>        No matter what I tried, I couldent get the machine to boot up to a
>> point
>> where I could try and fix the problem, so I started pulling devices out
>> and
>> found the following: If there is a raidz pool on any drive (not
>> necessarily
>> the one that you are trying to boot from) the loader dies and reboots the
>> machine. My friend, as an experiment created 3 gpt partitions (in addition
>> to
>> the single partition that he had been previously booted from) on his
>> single
>> drive and made a raidz pool for testing. His machine showed the same
>> condition
>> as mine, however he was able to capture the message before the machine
>> rebooted:
>>
>> <message>
>> ZFS: can only boot from disk or mirror vdevs
>>
>> ZFS: inconsistent nvlist contents
>
> The zfsboot code in current doesn't support raidz or raidz2. I have been
> working on adding that support but its not ready yet. The code works in my
> test harness but crashes instantly when I put it in the boot code :(. I
> should have time to finish debugging it soon.
>

After installing my system yesterday on a single disk with gptzfsboot,
I connected my old raidz and I only got cyclic reboots. I knew
instantly it had something to do with the raidz. Disconnecting 2 out
of the 4 disks of the raidz would allow the system to boot as the
raidz would not present itself as ONLINE.
As a temporary workaround for this problem I disabled those 2 disks on
the BIOS, the system boots fine and the kernel is able to find them
later.
Doug, when you feel comfortable to share any patches, I'm willing to test :-)


-- 
Joao Barros
From ken at mthelicon.com  Sun Dec  7 04:17:24 2008
From: ken at mthelicon.com (Pegasus Mc Cleaft)
Date: Sun Dec  7 04:17:31 2008
Subject: Problems with zfsboot loader if raidz present on any drive
In-Reply-To: <66BF33BA-EC11-446F-9DE7-15395F293FE2@rabson.org>
References: <200812070319.18461.ken@mthelicon.com>
	<66BF33BA-EC11-446F-9DE7-15395F293FE2@rabson.org>
Message-ID: <200812071217.20500.ken@mthelicon.com>

On Sunday 07 December 2008 09:22:16 Doug Rabson wrote:
> On 7 Dec 2008, at 03:19, Pegasus Mc Cleaft wrote:
> > Hello Hackers,
> >
> > 	Recently and friend and I have been trying to get the new
> > gptzfsboot working
> > on our machines and ran into a interesting problem.
> >
> > 	Initially I was building the world without the environment variable
> > LOADER_ZFS_SUPPORT=YES in the /etc/make.conf and this, of course,
> > didnt work
> > very well. Every time the machine booted, it would throw 2 lines
> > after the
> > pin-wheel and then reboot. I couldent read what the lines were it
> > went so
> > fast.
> >
> > 	My friend had a bit more luck and got his machine working OK with a
> > single
> > drive and later a mirror drive added.
> >
> > 	I added the environment variable and rebuilt everything and
> > installed. This
> > time, I could see the bios drives and a further 2 lines of ZFS
> > something and a
> > reboot...
> >
> > 	No matter what I tried, I couldent get the machine to boot up to a
> > point
> > where I could try and fix the problem, so I started pulling devices
> > out and
> > found the following: If there is a raidz pool on any drive (not
> > necessarily
> > the one that you are trying to boot from) the loader dies and
> > reboots the
> > machine. My friend, as an experiment created 3 gpt partitions (in
> > addition to
> > the single partition that he had been previously booted from) on his
> > single
> > drive and made a raidz pool for testing. His machine showed the same
> > condition
> > as mine, however he was able to capture the message before the machine
> > rebooted:
> >
> > <message>
> > ZFS: can only boot from disk or mirror vdevs
> >
> > ZFS: inconsistent nvlist contents
>
> The zfsboot code in current doesn't support raidz or raidz2. I have
> been working on adding that support but its not ready yet. The code
> works in my test harness but crashes instantly when I put it in the
> boot code :(. I should have time to finish debugging it soon.

Hi Doug,

	In my haste to put a message to the group, I didnt do a very good job of 
explaining or give what platform I was working with. 

	I set up a single disk pool with the gptzfsboot code on it as a boot drive. 
My idea was to have a single disk boot (and after it boots and I can kill the 
UFS drive I am currently booting from) convert it to a mirror. But I have 6 
other drives in the machine that I have as a raidz for my /usr/home, et al. 

	If the 6 raidz drives are present at boot time, the machine starts to cyclic 
reboot just after the pin-wheel. 

	The machine I am working on is running FBSD8.0-Current as of midnight 
7/12/2008 and the platform is AMD64. 

	If I can help test in any way I would be more than happy to try, or provide 
any information necessary.. 

~Peg


From wojtek at wojtek.tensor.gdynia.pl  Sun Dec  7 00:40:58 2008
From: wojtek at wojtek.tensor.gdynia.pl (Wojciech Puchar)
Date: Sun Dec  7 04:39:54 2008
Subject: Why FreeBSD not popular on hardware vendors
In-Reply-To: <4be2da2e0812062344y26eddcc9sf589531d10c71a1c@mail.gmail.com>
References: <4be2da2e0812062344y26eddcc9sf589531d10c71a1c@mail.gmail.com>
Message-ID: <20081207093713.O5433@wojtek.tensor.gdynia.pl>

> manufacturers of hardware. More recently there were times when anybody from

because managers/bosses concentrate on majority, not minority of users.

> manufacturers did not notice Linux. However now it is possible to find a few

> given out "put normal OS - their list is at us on a site and then we will

i recommend you to find "normal shop" to buy hardware, that allow you to 
fully test computer before buying.


if you think there are larger (even hundreds means larger) start selling 
"FreeBSD compatible computers" in your area!

You could make money on that, many people will easily spend 100$ more for 
computer that is already tested 100% FreeBSD compatible.

All you have to do is to test/check lots of different parts of hardware if 
it actually work with FreeBSD fine, and make computers from that parts.

From yonyossef.lists at gmail.com  Sun Dec  7 07:56:48 2008
From: yonyossef.lists at gmail.com (Yony Yossef)
Date: Sun Dec  7 07:57:01 2008
Subject: Timer driven tasks in FreeBSD 7
Message-ID: <20def4870812070756n649f442fwc6e1d3da195a0669@mail.gmail.com>

Hi All,

What mechanism should I use for making my netwrok driver call a
function every half a second, for instnace?

I am already using task queues but I haven't found a way to make it
work with a timer.

Thanks

Yony
From keramida at ceid.upatras.gr  Sun Dec  7 08:03:38 2008
From: keramida at ceid.upatras.gr (Giorgos Keramidas)
Date: Sun Dec  7 08:03:51 2008
Subject: Timer driven tasks in FreeBSD 7
In-Reply-To: <20def4870812070756n649f442fwc6e1d3da195a0669@mail.gmail.com>
	(Yony Yossef's message of "Sun, 7 Dec 2008 17:56:47 +0200")
References: <20def4870812070756n649f442fwc6e1d3da195a0669@mail.gmail.com>
Message-ID: <877i6ct1kj.fsf@kobe.laptop>

On Sun, 7 Dec 2008 17:56:47 +0200, "Yony Yossef" <yonyossef.lists@gmail.com> wrote:
> Hi All,
>
> What mechanism should I use for making my netwrok driver call a
> function every half a second, for instnace?
>
> I am already using task queues but I haven't found a way to make it
> work with a timer.

callout_xxx() functions should do the trick.  See the timeout(9)
manpage for more details.

From marius at nuenneri.ch  Sun Dec  7 11:20:55 2008
From: marius at nuenneri.ch (=?ISO-8859-1?Q?Marius_N=FCnnerich?=)
Date: Sun Dec  7 11:21:02 2008
Subject: Why safe using msleep with timeout=0 but not tsleep?
Message-ID: <b649e5e0812071100v2bf7b377n63e85b3f2b123c24@mail.gmail.com>

See subject.
Interesting commit:
http://svn.freebsd.org/viewvc/base?view=revision&revision=77059

 - Marius
From kientzle at freebsd.org  Sun Dec  7 11:55:16 2008
From: kientzle at freebsd.org (Tim Kientzle)
Date: Sun Dec  7 11:55:22 2008
Subject: Syscons with xterm emulation: one step closer to UTF-8 support?
In-Reply-To: <20081206155908.GG18652@hoeg.nl>
References: <20081206155908.GG18652@hoeg.nl>
Message-ID: <493C2A0C.1080103@freebsd.org>

Ed Schouten wrote:
> 
> A couple of weeks ago I started working on a library (libteken) that
> implements a subset of features (escape sequences) of xterm, our trusty
> X11 terminal application.

Ed,

VT100 emulation in syscons is a great idea.

The first time ;-) I implemented VT100 emulation I didn't
know about all of the VT100 and VT220 torture tests
floating around.  If you haven't already, I strongly
suggest you track down some of them.  The various
VT100 "movies" are useful tests and kind of fun to watch.

Tim
From nox at jelal.kn-bremen.de  Sun Dec  7 09:59:51 2008
From: nox at jelal.kn-bremen.de (Juergen Lock)
Date: Sun Dec  7 12:32:08 2008
Subject: AMD64 qemu completely broken?
In-Reply-To: <Pine.GSO.4.64.0812041428400.22402@zeno.ucsd.edu>
References: <5f67a8c40812021718i4cc225fem5b02a448702ec606@mail.gmail.com>
	<7d6fde3d0812040327w7c92826i64c6073a453d65ef@mail.gmail.com>
	<5f67a8c40812040952u1364563awcfd493695e7fea7c@mail.gmail.com>
	<200812042046.mB4KkC0k016853@saturn.kn-bremen.de>
	<20081204212311.GA17962@saturn.kn-bremen.de>
	<Pine.GSO.4.64.0812041428400.22402@zeno.ucsd.edu>
Message-ID: <20081207175556.GA61107@saturn.kn-bremen.de>

On Thu, Dec 04, 2008 at 02:43:47PM -0800, Nate Eldredge wrote:
> On Thu, 4 Dec 2008, Juergen Lock wrote:
> 
>> I forgot to say the qemu-devel port (as well as the later snapshots I
>> posted about on -emulation) also support -curses, which shows the emulated
>> vga text(!)console on qemu's tty.  This works quite well with FreeBSD guests
>> (even the isos) if you extend your xterm/whatever by one line (the default
>> vga textconsole is 80x25 instead of 80x24.)
> 
> As long as we're sharing tips about qemu:
> 
> I've recently been working with qemu on amd64 and have set up a Debian etch 
> i386 guest which is working well.  I am using the qemu-devel and 
> kqemu-kmod-devel ports.  I am not using -kernel-kqemu at the moment; I 
> thought I would get things working before trying to speed up.
> 
> Using qemu I've finally achieved my goal of being able to use flash on 
> FreeBSD/amd64 (in some sense :-O).
> 
Actually at least on RELENG_7 and later the original www/linux-flashplugin9
+ www/nspluginwrapper don't work too bad at least for video sites these
days (on 6 and 7.0 you need a patch and there it probably doesn't quite
work on SMP because another patch concerning SMP can't be merged.)  See
e.g. this thread on -emulation for more:
        http://lists.freebsd.org/pipermail/freebsd-emulation/2008-October/005433.html
(also later on that thread iirc were reports of hangs with ff3 and
linux base fc4, so either use f7 or f8, or stick with ff2 for now,
like if you're on 6 + linprocfs patch where only fc4 works.  And
you want to run that nspluginwrapper -i command under 5. as the user
that will run the browser, not as root.  Oh and that flash9 advisory
is no longer an issue, it has been updated since.)

 I even got flash10 running, which probably can enter ports some time
after the slush:
        http://lists.freebsd.org/pipermail/freebsd-emulation/2008-October/005438.html

> savevm and loadvm don't work due to a security patch.  Since my guest 
> system is trusted I reverted the patch.  I filed a PR as ports/129417 .
> 
 Yup, fixed since.  (I'm only saying this for the benefit of other
readers. :)  Merged a fix from debian sid kvm.

> I found that '-net user' is horribly broken on amd64 (qemu segfaults). It 
> uses some ancient [*] BSD TCP/IP code (via slirp) which assumes that 
> pointers are 32 bits and doesn't hesitate to shove them into random 32-bit 
> corners of externally defined structures if it's convenient.  Looks like a 
> pain to clean up.

 Yup slirp is ancient code and doesnt really work on 64 bit hosts.
(as also mentioned in the qemu ports' pkg-message...)

>  '-net tap' works fine, but requires root privileges and 
> is more work to set up.
> 
 Actually it doesn't require root privs to run, only to setup.
(Ok you _might_ need sudo to ifconfig the tap device and/or bridge
in the qemu-ifup script...  But qemu itself can certainly run as user.)

> [*] Out of curiosity, I looked at some Unix Archive stuff and found the 
> identical code in BSD's Net2, circa 1991.  It is identified in a comment as 
> a "quick hack" and adorned with several /* XXX */.  Naturally the code and 
> the comments survive intact, 17 years later. :-(
> 
 This might be somewhat more understandable if you know that the original
slirp code was written many moons ago and only later resurrected for
emulation purposes.  (It was originally invented for dialup users that
logged into shellservers' gettys via serial modem lines so they could
also use the box' inet connection locally before things like ppp were
available...)

 Cheers,
	Juergen
From ed at 80386.nl  Sun Dec  7 13:16:04 2008
From: ed at 80386.nl (Ed Schouten)
Date: Sun Dec  7 13:16:10 2008
Subject: Syscons with xterm emulation: one step closer to UTF-8 support?
In-Reply-To: <493C2A0C.1080103@freebsd.org>
References: <20081206155908.GG18652@hoeg.nl> <493C2A0C.1080103@freebsd.org>
Message-ID: <20081207211602.GJ18652@hoeg.nl>

* Tim Kientzle <kientzle@freebsd.org> wrote:
> VT100 emulation in syscons is a great idea.
>
> The first time ;-) I implemented VT100 emulation I didn't
> know about all of the VT100 and VT220 torture tests
> floating around.  If you haven't already, I strongly
> suggest you track down some of them.  The various
> VT100 "movies" are useful tests and kind of fun to watch.

Yes. That's a very good idea. So far I've mainly done testing with
vttest, maintained by Thomas Dickey:

	http://invisible-island.net/vttest/vttest.html

But I'll see if I can find others. They are very good to monitor
regressions.

-- 
 Ed Schouten <ed@80386.nl>
 WWW: http://80386.nl/
-------------- 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-hackers/attachments/20081207/0900e4bb/attachment.pgp
From patfbsd at davenulle.org  Sun Dec  7 13:45:56 2008
From: patfbsd at davenulle.org (Patrick =?ISO-8859-15?Q?Lamaizi=E8re?=)
Date: Sun Dec  7 13:46:04 2008
Subject: crypto(9) choose another driver if we cannot open a session on it
Message-ID: <20081207224551.13ca3590@baby-jane>

Hello,

I wrote a small patch to allow the crypto framework to choose another
cryptographic driver if we cannot open a session on the driver.

The current version selects the driver that handles all the requested
algorithms and with the less count of active sessions. But this is not
enough, by example the glxsb(4) driver does not accept AES session
with key's length != 128 bits. It rejects also HMAC algorithms if
there is no AES encryption to do in the session (HMAC is done by
software to make it works with ipsec).

The other way to deal with this problem would be to implement in
the glxsb driver software implementations for AES 192 et AES 256.
(OpenBSD did it recently). But I think this is a hack and it's
better to revert to another driver.

diff of sys/opencrypto/crypto.c between 8-CURRENT
http://user.lamaiziere.net/patrick/opencrypto-071208/crypto.c-diff

sys/opencrypto/crypto.c
http://user.lamaiziere.net/patrick/opencrypto-071208/crypto.c

That should not break anything. It would be nice to test it on a box
with a Geode LX CPU and a crypto device like a VPN1411 card.
I don't have the hardware but I've checked that we revert to
the cryptosoft driver when using ipsec and glxsb with AES key's
length != 128 bits.

Thanks, regards.


From neldredge at math.ucsd.edu  Sun Dec  7 14:56:14 2008
From: neldredge at math.ucsd.edu (Nate Eldredge)
Date: Sun Dec  7 14:56:22 2008
Subject: AMD64 qemu completely broken?
In-Reply-To: <20081207175556.GA61107@saturn.kn-bremen.de>
References: <5f67a8c40812021718i4cc225fem5b02a448702ec606@mail.gmail.com>
	<7d6fde3d0812040327w7c92826i64c6073a453d65ef@mail.gmail.com>
	<5f67a8c40812040952u1364563awcfd493695e7fea7c@mail.gmail.com>
	<200812042046.mB4KkC0k016853@saturn.kn-bremen.de>
	<20081204212311.GA17962@saturn.kn-bremen.de>
	<Pine.GSO.4.64.0812041428400.22402@zeno.ucsd.edu>
	<20081207175556.GA61107@saturn.kn-bremen.de>
Message-ID: <Pine.GSO.4.64.0812071401060.22402@zeno.ucsd.edu>

On Sun, 7 Dec 2008, Juergen Lock wrote:

> On Thu, Dec 04, 2008 at 02:43:47PM -0800, Nate Eldredge wrote:
>> On Thu, 4 Dec 2008, Juergen Lock wrote:
>>
>>> I forgot to say the qemu-devel port (as well as the later snapshots I
>>> posted about on -emulation) also support -curses, which shows the emulated
>>> vga text(!)console on qemu's tty.  This works quite well with FreeBSD guests
>>> (even the isos) if you extend your xterm/whatever by one line (the default
>>> vga textconsole is 80x25 instead of 80x24.)
>>
>> As long as we're sharing tips about qemu:
>>
>> I've recently been working with qemu on amd64 and have set up a Debian etch
>> i386 guest which is working well.  I am using the qemu-devel and
>> kqemu-kmod-devel ports.  I am not using -kernel-kqemu at the moment; I
>> thought I would get things working before trying to speed up.
>>
>> Using qemu I've finally achieved my goal of being able to use flash on
>> FreeBSD/amd64 (in some sense :-O).
>>
> Actually at least on RELENG_7 and later the original www/linux-flashplugin9
> + www/nspluginwrapper don't work too bad at least for video sites these
> days (on 6 and 7.0 you need a patch and there it probably doesn't quite
> work on SMP because another patch concerning SMP can't be merged.)  See
> e.g. this thread on -emulation for more:
>        http://lists.freebsd.org/pipermail/freebsd-emulation/2008-October/005433.html

Thanks for the pointer.  I will probably wait until 7.1 is out and ports 
are defrosted, so I can go straight to flash10 and not to have to do 
everything twice, but this information should be very helpful.

>>  '-net tap' works fine, but requires root privileges and
>> is more work to set up.
>>
> Actually it doesn't require root privs to run, only to setup.
> (Ok you _might_ need sudo to ifconfig the tap device and/or bridge
> in the qemu-ifup script...  But qemu itself can certainly run as user.)

Okay.  I was being lazy and letting qemu do some of that work for me.

>> [*] Out of curiosity, I looked at some Unix Archive stuff and found the
>> identical code in BSD's Net2, circa 1991.  It is identified in a comment as
>> a "quick hack" and adorned with several /* XXX */.  Naturally the code and
>> the comments survive intact, 17 years later. :-(
>>
> This might be somewhat more understandable if you know that the original
> slirp code was written many moons ago and only later resurrected for
> emulation purposes.  (It was originally invented for dialup users that
> logged into shellservers' gettys via serial modem lines so they could
> also use the box' inet connection locally before things like ppp were
> available...)

Yep, I think I remember trying to use some slip implementation over a 
serial modem once.  It's just unfortunate that qemu chose that code for 
their TCP/IP implementation rather than something else more modern.  Not 
that I'm volunteering to update it :)

-- 

Nate Eldredge
neldredge@math.ucsd.edu
From auryn at zirakzigil.org  Mon Dec  8 02:18:55 2008
From: auryn at zirakzigil.org (Giulio Ferro)
Date: Mon Dec  8 02:19:02 2008
Subject: Problems with twa
Message-ID: <493CF049.8070004@zirakzigil.org>

I've installed a 3ware 9500 sata controller with 4 1TB disks
in raid 5.
Apart from the usual wrong geometry warning the starting configuration
is ok: I create a single partition with the default labels plus a /usr/home
label with takes most of the disk space (about 2.7TB).

When I reboot the system the /usr/home partition size drops unexplainably
to about 640GB.

In order to try to understand what happens I've installed freebsd anew, this
time creating 2 partitions: the first one 50GB, the second about 2.7TB (the
remaining space). Everything seems to work correctly.
I reboot the system and lo! the second partitions shrinks to about 640GB 
and
the partitioner (using sysinstall) tells me that there are 2048GB free!

This happens both with freebsd 7 and 8 current amd64.

Thanks for any help.
From ivoras at freebsd.org  Mon Dec  8 02:37:07 2008
From: ivoras at freebsd.org (Ivan Voras)
Date: Mon Dec  8 02:37:13 2008
Subject: Problems with twa
In-Reply-To: <493CF049.8070004@zirakzigil.org>
References: <493CF049.8070004@zirakzigil.org>
Message-ID: <ghitc8$qke$1@ger.gmane.org>

Giulio Ferro wrote:
> I've installed a 3ware 9500 sata controller with 4 1TB disks
> in raid 5.
> Apart from the usual wrong geometry warning the starting configuration
> is ok: I create a single partition with the default labels plus a /usr/home
> label with takes most of the disk space (about 2.7TB).
> 
> When I reboot the system the /usr/home partition size drops unexplainably
> to about 640GB.
> 
> In order to try to understand what happens I've installed freebsd anew,
> this
> time creating 2 partitions: the first one 50GB, the second about 2.7TB (the
> remaining space). Everything seems to work correctly.
> I reboot the system and lo! the second partitions shrinks to about 640GB
> and
> the partitioner (using sysinstall) tells me that there are 2048GB free!
> 
> This happens both with freebsd 7 and 8 current amd64.
> 
> Thanks for any help.

It's probably because you cannot create bsdlabels or fdisk partitions
larger than 2 TB. The sizes you're seeing are probably because of
overflows in calculations. It's not that the OS doesn't support larger
drives, the problem is the partition formats.

You might succeed by creating two large partitions, one ending just
before the 2 TB limit and one stretching the rest of the space, but a
more robust way would be to either create two smaller volumes (if the
controller supports creating them on the array) or you'll need to
install FreeBSD on a separate, smaller array and partition the large
array with GPT (or use ZFS).

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20081208/54b82560/signature.pgp
From avg at icyb.net.ua  Mon Dec  8 07:06:07 2008
From: avg at icyb.net.ua (Andriy Gapon)
Date: Mon Dec  8 07:06:20 2008
Subject: usb keyboard dying at loader prompt
In-Reply-To: <20081128134802.GA75900@onelab2.iet.unipi.it>
References: <4912E462.4090608@icyb.net.ua> <491586B9.2020303@vwsoft.com>
	<4919851B.7050800@icyb.net.ua> <492FF127.807@icyb.net.ua>
	<20081128134802.GA75900@onelab2.iet.unipi.it>
Message-ID: <493D37DB.6030902@icyb.net.ua>

[forwarded to the lists]

on 28/11/2008 15:48 Luigi Rizzo said the following:
> just as a test, can you check if /boot/loader from 6.2 (or sometime
> before jan.2008 - e.g. you could take one from a 6.3 CD) which you
> can also find at
> 
> http://info.iet.unipi.it/~luigi/doc/20081128-freebsd-6.3-boot-loader
> 
> gives the same behaviour ?
> 
> I was seeing bugs related to the loader with pxeboot and
> the behaviour that you mention below sounds related.
> 
> It also sounds related to a problem that i a started having
> recently with an usb keyboard after i upgraded to 7.x ....
> in fact i am going to try this old loader myself!
> 
> let me know how the old loader works and if it fixes the
> problem i will relate the two issues and bring them up
> on the lists for discussion

Luigi,

thank you very much for this!
With your loader the things are much much better.
The keyboard doesn't die anymore at the loader prompt!


All in all, it seems that this is right direction.

-- 
Andriy Gapon

From ivoras at freebsd.org  Mon Dec  8 11:41:52 2008
From: ivoras at freebsd.org (Ivan Voras)
Date: Mon Dec  8 11:42:00 2008
Subject: MAXFILES in subr_param.c
Message-ID: <ghjt9l$hg3$1@ger.gmane.org>

Hi,

I'm looking at kern/subr_param.c:

 72 #ifndef MAXFILES
 73 #define MAXFILES (maxproc * 2)
 74 #endif



Shouldn't this be at least maxproc*3, for stdin,out,err for every proc?

Also, it looks like MAXFILES is used only once, and in a bit funny way:

238         maxfiles = MAXFILES;
239         TUNABLE_INT_FETCH("kern.maxfiles", &maxfiles);
240         maxprocperuid = (maxproc * 9) / 10;
241         maxfilesperproc = (maxfiles * 9) / 10;

Historical reasons?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 258 bytes
Desc: OpenPGP digital signature
Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20081208/414875f0/signature.pgp
From philip at freebsd.org  Mon Dec  8 12:21:58 2008
From: philip at freebsd.org (Philip Paeps)
Date: Mon Dec  8 12:22:04 2008
Subject: crypto(9) choose another driver if we cannot open a session on
	it
In-Reply-To: <20081207224551.13ca3590@baby-jane>
References: <20081207224551.13ca3590@baby-jane>
Message-ID: <20081208202155.GA7403@detritus.paeps.cx>

On 2008-12-07 22:45:51 (+0100), Patrick Lamaizi?re <patfbsd@davenulle.org> wrote:
> I wrote a small patch to allow the crypto framework to choose another
> cryptographic driver if we cannot open a session on the driver.

Very cool. :-)  I've been hacking on this too, mainly to get rid of the code
duplication that currently exists.

> That should not break anything. It would be nice to test it on a box with a
> Geode LX CPU and a crypto device like a VPN1411 card.  I don't have the
> hardware but I've checked that we revert to the cryptosoft driver when using
> ipsec and glxsb with AES key's length != 128 bits.

I'll test that tonight.  I think I've got a hifn card hiding somewhere near a
soekris.

Thanks!

 - Philip

-- 
Philip Paeps                                    Please don't Cc me, I am
philip@freebsd.org                               subscribed to the list.

  "Maybe you should loosen her clothing or something."
          -- Gaspode the wonder dog
             (Terry Pratchett, Moving Pictures)
From jhb at freebsd.org  Mon Dec  8 12:52:19 2008
From: jhb at freebsd.org (John Baldwin)
Date: Mon Dec  8 12:52:25 2008
Subject: Why safe using msleep with timeout=0 but not tsleep?
In-Reply-To: <b649e5e0812071100v2bf7b377n63e85b3f2b123c24@mail.gmail.com>
References: <b649e5e0812071100v2bf7b377n63e85b3f2b123c24@mail.gmail.com>
Message-ID: <200812081517.39375.jhb@freebsd.org>

On Sunday 07 December 2008 02:00:30 pm Marius N?nnerich wrote:
> See subject.
> Interesting commit:
> http://svn.freebsd.org/viewvc/base?view=revision&revision=77059

Lost wakeups.   If you have code like so that doesn't use any locks:

int flag;

void
foo(void)
{

	flag = 1;
	wakeup(&flag);
}

void
bar(void)
{

	if (flag == 0)
		tsleep(&foo, ..., 0);
}

Then one CPU may run the 'foo' routine to completion after another CPU has 
seen 'flag == 0' but before it has put the thread to sleep in tsleep().  Even 
on UP systems with preemption you can still get this race if you get 
preempted by an interrupt (which runs foo()) in between the 'flag == 0' test 
and calling tsleep().  Using an interlock avoid this:

struct mtx lock;
int flag;

void
foo(void)
{

	mtx_lock(&lock);
	flag = 1;
	mtx_unlock(&lock);
	wakeup(&flag);
}

void
bar(void)
{

	mtx_lock(&lock);
	if (flag == 0)
		mtx_sleep(&foo, &lock, ..., 0);
	mtx_unlock(&lock);
}

In this case 'lock' closes the SMP/preemption races.

-- 
John Baldwin
From sobomax at FreeBSD.org  Mon Dec  8 14:51:14 2008
From: sobomax at FreeBSD.org (Maxim Sobolev)
Date: Mon Dec  8 14:51:27 2008
Subject: Enhancing cdboot [patch for review]
Message-ID: <493DA269.2070805@FreeBSD.org>

Hi,

Below please find patch that enhances cdboot with two compile-time options:

1. CDBOOT_SILENT. When this option is set, the cdboot doesn't produce
any messages except "Loading, please wait..." and it also passes
RBX_MUTE flag to the next stage to silence it as well. This is intended
for custom installations where end-user is not required to see any
messages or interfere with the boot process.

2. CDBOOT_PROMPT. When this option is enabled the cdboot behaves like
windows xp or vista cd loader, that is it reads MBR from the first hard
drive in the system and if the MBR is bootable (i.e. drive has some
other operating system installed on it) then it presents user with
"Press any key to boot from CD" prompt and waits 20 seconds. If key is
not pressed then the control is passed to the MBR, otherwise CD is
booted. This is intended for installation CD to allow unattended mode
and also helps when installation CD is unintentionally left in the drive
of the machine that is set to boot off CD.

Any comments/suggestions are appreciated. If there are no objections I
would like to commit the change. The long-term goal is to make
CDBOOT_PROMPT default mode for installation CD.

http://sobomax.sippysoft.com/~sobomax/cdboot.diff

-Maxim

From sobomax at sippysoft.com  Mon Dec  8 14:51:15 2008
From: sobomax at sippysoft.com (Maxim Sobolev)
Date: Mon Dec  8 15:06:17 2008
Subject: Enhancing cdboot [patch for review]
Message-ID: <493DA258.7010001@sippysoft.com>

Hi,

Below please find patch that enhances cdboot with two compile-time options:

1. CDBOOT_SILENT. When this option is set, the cdboot doesn't produce 
any messages except "Loading, please wait..." and it also passes 
RBX_MUTE flag to the next stage to silence it as well. This is intended 
for custom installations where end-user is not required to see any 
messages or interfere with the boot process.

2. CDBOOT_PROMPT. When this option is enabled the cdboot behaves like 
windows xp or vista cd loader, that is it reads MBR from the first hard 
drive in the system and if the MBR is bootable (i.e. drive has some 
other operating system installed on it) then it presents user with 
"Press any key to boot from CD" prompt and waits 20 seconds. If key is 
not pressed then the control is passed to the MBR, otherwise CD is 
booted. This is intended for installation CD to allow unattended mode 
and also helps when installation CD is unintentionally left in the drive 
of the machine that is set to boot off CD.

Any comments/suggestions are appreciated. If there are no objections I 
would like to commit the change. The long-term goal is to make 
CDBOOT_PROMPT default mode for installation CD.

http://sobomax.sippysoft.com/~sobomax/cdboot.diff

-Maxim
From marius at nuenneri.ch  Mon Dec  8 15:45:58 2008
From: marius at nuenneri.ch (=?ISO-8859-1?Q?Marius_N=FCnnerich?=)
Date: Mon Dec  8 15:46:04 2008
Subject: Why safe using msleep with timeout=0 but not tsleep?
In-Reply-To: <200812081517.39375.jhb@freebsd.org>
References: <b649e5e0812071100v2bf7b377n63e85b3f2b123c24@mail.gmail.com>
	<200812081517.39375.jhb@freebsd.org>
Message-ID: <b649e5e0812081545s21b17534ya822e2de0acc9c0a@mail.gmail.com>

On Mon, Dec 8, 2008 at 9:17 PM, John Baldwin <jhb@freebsd.org> wrote:
> On Sunday 07 December 2008 02:00:30 pm Marius N?nnerich wrote:
>> See subject.
>> Interesting commit:
>> http://svn.freebsd.org/viewvc/base?view=revision&revision=77059
>
> Lost wakeups.   If you have code like so that doesn't use any locks:
>
> int flag;
>
> void
> foo(void)
> {
>
>        flag = 1;
>        wakeup(&flag);
> }
>
> void
> bar(void)
> {
>
>        if (flag == 0)
>                tsleep(&foo, ..., 0);
> }
>
> Then one CPU may run the 'foo' routine to completion after another CPU has
> seen 'flag == 0' but before it has put the thread to sleep in tsleep().  Even
> on UP systems with preemption you can still get this race if you get
> preempted by an interrupt (which runs foo()) in between the 'flag == 0' test
> and calling tsleep().  Using an interlock avoid this:
>
> struct mtx lock;
> int flag;
>
> void
> foo(void)
> {
>
>        mtx_lock(&lock);
>        flag = 1;
>        mtx_unlock(&lock);
>        wakeup(&flag);
> }
>
> void
> bar(void)
> {
>
>        mtx_lock(&lock);
>        if (flag == 0)
>                mtx_sleep(&foo, &lock, ..., 0);
>        mtx_unlock(&lock);
> }
>
> In this case 'lock' closes the SMP/preemption races.
>
> --
> John Baldwin
>

Thank you for the explanation, John!
From rizzo at iet.unipi.it  Mon Dec  8 15:46:20 2008
From: rizzo at iet.unipi.it (Luigi Rizzo)
Date: Mon Dec  8 15:46:33 2008
Subject: Enhancing cdboot [patch for review]
In-Reply-To: <493DA269.2070805@FreeBSD.org>
References: <493DA269.2070805@FreeBSD.org>
Message-ID: <20081208235119.GA46608@onelab2.iet.unipi.it>

On Mon, Dec 08, 2008 at 02:40:41PM -0800, Maxim Sobolev wrote:
> Hi,
> 
> Below please find patch that enhances cdboot with two compile-time options:
...
> Any comments/suggestions are appreciated. If there are no objections I
> would like to commit the change. The long-term goal is to make
> CDBOOT_PROMPT default mode for installation CD.
> 
> http://sobomax.sippysoft.com/~sobomax/cdboot.diff

Looks good. Some comments:
1. since there is plenty of space in the cdboot sector, why don't you
   make the two option always compiled in, controlling which one to
   activate through flags in the bootsector itself, to be set
   patching the binary sector itself using a mechanism similar to
   boot0cfg.
      Of course you cannot alter a cdrom after you burn it,
   but it makes it easier to build CDs with one or the other defaults,
   patching cdboot or the iso image itself before creating/burning it.

2. in fact, the 'silent' option could be disabled at runtime by
   pressing some key (e.g. adding a short wait loop before proceeding;
   if this is meant for custom, unattended CDs the extra delay should not
   matter much);

3. one nitpick -- in one of the first chunks you replace $start
   with $LOAD, but if i am not mistaken operation depends on $LOAD = $start,
   so why don't you always use the same ?
     Also in terms of relocation size, wouldn't it be the case of
   hardwiring the size of the cd boot sector:

-       mov $((end_init - start)/2),%cx
+       mov 1024,%cx

4. another nitpick -- the value you pass in %si to the MBR does not
   seem to point to anything useful. As discussed about boot0.S and
   the followup in the mailing lists, there seems to be no standard
   but at least some MBR expect %si to point to a partition entry,
   so you should probably initialize one in a way similar way to that
   used by boot0.S

cheers
luigi
From sobomax at FreeBSD.org  Mon Dec  8 16:29:32 2008
From: sobomax at FreeBSD.org (Maxim Sobolev)
Date: Mon Dec  8 16:29:39 2008
Subject: Enhancing cdboot [patch for review]
In-Reply-To: <20081208235119.GA46608@onelab2.iet.unipi.it>
References: <493DA269.2070805@FreeBSD.org>
	<20081208235119.GA46608@onelab2.iet.unipi.it>
Message-ID: <493DBBD0.5080705@FreeBSD.org>

Luigi Rizzo wrote:
> On Mon, Dec 08, 2008 at 02:40:41PM -0800, Maxim Sobolev wrote:
>> Hi,
>>
>> Below please find patch that enhances cdboot with two compile-time options:
> ...
>> Any comments/suggestions are appreciated. If there are no objections I
>> would like to commit the change. The long-term goal is to make
>> CDBOOT_PROMPT default mode for installation CD.
>>
>> http://sobomax.sippysoft.com/~sobomax/cdboot.diff
> 
> Looks good. Some comments:

Thank you for the review and comments. Please see my answers below.

> 1. since there is plenty of space in the cdboot sector, why don't you
>    make the two option always compiled in, controlling which one to
>    activate through flags in the bootsector itself, to be set
>    patching the binary sector itself using a mechanism similar to
>    boot0cfg.
>       Of course you cannot alter a cdrom after you burn it,
>    but it makes it easier to build CDs with one or the other defaults,
>    patching cdboot or the iso image itself before creating/burning it.
> 
> 2. in fact, the 'silent' option could be disabled at runtime by
>    pressing some key (e.g. adding a short wait loop before proceeding;
>    if this is meant for custom, unattended CDs the extra delay should not
>    matter much);

Good idea, I will see if I can put that in. In fact this behavior should 
have to be optional as well, since one of the uses for the "silent" 
option here is to provide tamper-resistant boot process on custom hardware.

> 3. one nitpick -- in one of the first chunks you replace $start
>    with $LOAD, but if i am not mistaken operation depends on $LOAD = $start,
>    so why don't you always use the same ?

No, they are not the same. $LOAD is address where BIOS loads boot 
sector, which is 0x7c00 by default (you can configure it when building 
CD-ROM, which is why it's an option). On the other hand, $start is 
address where code is compiled to be located, which is 0x0600.

>      Also in terms of relocation size, wouldn't it be the case of
>    hardwiring the size of the cd boot sector:
> 
> -       mov $((end_init - start)/2),%cx
> +       mov 1024,%cx

Well, I don't see the reason to hardwire this. CDROM boot code can be of 
different size (within certain limits of course, to be selected when 
building ISO), it's not limited to fixed number of sectors like boot[012].

> 4. another nitpick -- the value you pass in %si to the MBR does not
>    seem to point to anything useful. As discussed about boot0.S and
>    the followup in the mailing lists, there seems to be no standard
>    but at least some MBR expect %si to point to a partition entry,
>    so you should probably initialize one in a way similar way to that
>    used by boot0.S

Hmm, maybe I misunderstood it then. What do you mean by "point to 
partition entry exactly"? Right now it points to the beginning on MBR.

-Maxim
From keramida at ceid.upatras.gr  Mon Dec  8 17:29:41 2008
From: keramida at ceid.upatras.gr (Giorgos Keramidas)
Date: Mon Dec  8 17:29:49 2008
Subject: Enhancing cdboot [patch for review]
In-Reply-To: <493DBBD0.5080705@FreeBSD.org> (Maxim Sobolev's message of "Mon, 
	08 Dec 2008 16:29:04 -0800")
References: <493DA269.2070805@FreeBSD.org>
	<20081208235119.GA46608@onelab2.iet.unipi.it>
	<493DBBD0.5080705@FreeBSD.org>
Message-ID: <87oczmjfuv.fsf@kobe.laptop>

On Mon, 08 Dec 2008 16:29:04 -0800, Maxim Sobolev <sobomax@freebsd.org> wrote:
> Luigi Rizzo wrote:
>> On Mon, Dec 08, 2008 at 02:40:41PM -0800, Maxim Sobolev wrote:
>>> Hi,
>>> Below please find patch that enhances cdboot with two compile-time options:
>> ...
>>> Any comments/suggestions are appreciated. If there are no objections I
>>> would like to commit the change. The long-term goal is to make
>>> CDBOOT_PROMPT default mode for installation CD.
>>>
>>> http://sobomax.sippysoft.com/~sobomax/cdboot.diff
>>
>> Looks good. Some comments:
>
> Thank you for the review and comments. Please see my answers below.
>
>> 1. since there is plenty of space in the cdboot sector, why don't you
>>    make the two option always compiled in, controlling which one to
>>    activate through flags in the bootsector itself, to be set
>>    patching the binary sector itself using a mechanism similar to
>>    boot0cfg.
>>       Of course you cannot alter a cdrom after you burn it,
>>    but it makes it easier to build CDs with one or the other defaults,
>>    patching cdboot or the iso image itself before creating/burning it.
>>
>> 2. in fact, the 'silent' option could be disabled at runtime by
>>    pressing some key (e.g. adding a short wait loop before proceeding;
>>    if this is meant for custom, unattended CDs the extra delay should not
>>    matter much);
>
> Good idea, I will see if I can put that in. In fact this behavior should
> have to be optional as well, since one of the uses for the "silent"
> option here is to provide tamper-resistant boot process on custom
> hardware.

Nice pair of features :-)

If there are no pressing space constraints maybe we can build both
options in by default, but still make them opt-out when necessary?

With a bit of makefile glue we can make it possible to compile with an
`src.conf' that includes:

    WITH_CDBOOT_SILENT=1
    WITHOUT_CDBOOT_PROMPT=1

This way the defaults can include support for both options, but we can
conditionally compile *out* the bits that are not needed for some custom
installation.

Something like this can define one or both of these options in CFLAGS,
depending on what `src.conf' contains:

  # When CDBOOT_SILENT is set, the cdboot doesn't produce any messages except
  # "Loading, please wait..." and it also passes RBX_MUTE flag to the next
  # stage to silence it as well. This is intended for custom installations
  # where end-user is not required to see any messages or interfere with the
  # boot process.

  .if ${MK_CDBOOT_SILENT} != "no"
  CFLAGS+= -DCDBOOT_SILENT
  .endif

  # When CDBOOT_PROMPT is enabled the cdboot behaves like windows xp or vista
  # cd loader, that is it reads MBR from the first hard drive in the system
  # and if the MBR is bootable (i.e. drive has some other operating system
  # installed on it) then it presents user with "Press any key to boot from
  # CD" prompt and waits for 20 seconds. If key is not pressed then the
  # control is passed to the MBR, otherwise CD is booted. This is intended for
  # installation CD to allow unattended mode and also helps when installation
  # CD has been unintentionally left in the drive of the machine that is set
  # to boot off CD.

  .if ${MK_CDBOOT_PROMPT} != "no"
  CFLAGS+= -DCDBOOT_PROMPT
  .endif

The defaults for ${MK_CDBOOT_XXX} will have to be explicitly set in
`src/share/mk/bsd.own.mk', near line 281:

    281 #
    282 # MK_* options which default to "yes".
    283 #
    284 .for var in \
    ...

But that shouldn't be a problem, AFAICT :-)

From rizzo at iet.unipi.it  Mon Dec  8 19:39:57 2008
From: rizzo at iet.unipi.it (Luigi Rizzo)
Date: Mon Dec  8 19:40:05 2008
Subject: Enhancing cdboot [patch for review]
In-Reply-To: <493DBBD0.5080705@FreeBSD.org>
References: <493DA269.2070805@FreeBSD.org>
	<20081208235119.GA46608@onelab2.iet.unipi.it>
	<493DBBD0.5080705@FreeBSD.org>
Message-ID: <20081209034456.GA54569@onelab2.iet.unipi.it>

On Mon, Dec 08, 2008 at 04:29:04PM -0800, Maxim Sobolev wrote:
> Luigi Rizzo wrote:
...
> >4. another nitpick -- the value you pass in %si to the MBR does not
> >   seem to point to anything useful. As discussed about boot0.S and
> >   the followup in the mailing lists, there seems to be no standard
> >   but at least some MBR expect %si to point to a partition entry,
> >   so you should probably initialize one in a way similar way to that
> >   used by boot0.S
> 
> Hmm, maybe I misunderstood it then. What do you mean by "point to 
> partition entry exactly"? Right now it points to the beginning on MBR.

ok, so here is what I know.

Even though there is no standard, at least ldlinux.sys and perhaps
other bootloaders expect %si to point to a 16-byte record containing
the partition descriptor (same structure as one of the 4 records
at 0x1be in the MBR) for the partition they were loaded from.

ldlinux.sys uses this info to "relocate": it knows the location of the
other sectors of ldlinux.sys relative to the beginning of the partition,
and uses the start-of-partition from the record at %si to compute
these locations in terms of absolute disk positions.

Note that in principle a MBR does not need this info -- even if it
is a multi-sector boot code such as boot0ext, it may well assume to
be located at offset 0.

On the other hand if the code on the MBR uses %si, then you should
set the entry so that at least the starting CHS and LBA info point
to the first sector on disk, i.e. CHS=0,0,1 and LBA=0.

In practical terms -- make %si point to a 16-byte area of memory
containing all 0's except for the byte representing the sector
number for the start of the partition.
See the code in a recent sys/boot/i386/boot0/boot0.S which gives
some details on this.

	cheers
	luigi
From sobomax at FreeBSD.org  Mon Dec  8 20:49:10 2008
From: sobomax at FreeBSD.org (Maxim Sobolev)
Date: Mon Dec  8 20:49:22 2008
Subject: Enhancing cdboot [patch for review]
In-Reply-To: <20081209034456.GA54569@onelab2.iet.unipi.it>
References: <493DA269.2070805@FreeBSD.org>
	<20081208235119.GA46608@onelab2.iet.unipi.it>
	<493DBBD0.5080705@FreeBSD.org>
	<20081209034456.GA54569@onelab2.iet.unipi.it>
Message-ID: <493DF8A3.6070905@FreeBSD.org>

Luigi Rizzo wrote:
> On Mon, Dec 08, 2008 at 04:29:04PM -0800, Maxim Sobolev wrote:
>> Luigi Rizzo wrote:
> ...
>>> 4. another nitpick -- the value you pass in %si to the MBR does not
>>>   seem to point to anything useful. As discussed about boot0.S and
>>>   the followup in the mailing lists, there seems to be no standard
>>>   but at least some MBR expect %si to point to a partition entry,
>>>   so you should probably initialize one in a way similar way to that
>>>   used by boot0.S
>> Hmm, maybe I misunderstood it then. What do you mean by "point to 
>> partition entry exactly"? Right now it points to the beginning on MBR.
> 
> ok, so here is what I know.
> 
> Even though there is no standard, at least ldlinux.sys and perhaps
> other bootloaders expect %si to point to a 16-byte record containing
> the partition descriptor (same structure as one of the 4 records
> at 0x1be in the MBR) for the partition they were loaded from.
> 
> ldlinux.sys uses this info to "relocate": it knows the location of the
> other sectors of ldlinux.sys relative to the beginning of the partition,
> and uses the start-of-partition from the record at %si to compute
> these locations in terms of absolute disk positions.
> 
> Note that in principle a MBR does not need this info -- even if it
> is a multi-sector boot code such as boot0ext, it may well assume to
> be located at offset 0.
> 
> On the other hand if the code on the MBR uses %si, then you should
> set the entry so that at least the starting CHS and LBA info point
> to the first sector on disk, i.e. CHS=0,0,1 and LBA=0.
> 
> In practical terms -- make %si point to a 16-byte area of memory
> containing all 0's except for the byte representing the sector
> number for the start of the partition.
> See the code in a recent sys/boot/i386/boot0/boot0.S which gives
> some details on this.

I see, thank you for the explanation. It looks like it only makes sense 
for multi-stage boot loaders, when the stage has been loaded from some 
location within the disk and it needs some clue to determine where it 
has came from. In this case we simply emulate BIOS loading MBR, and from 
what I've read here MBR code should make no assumptions with regard to 
%si, so that I would just set it to zero. Do you think it could create 
any issues?

-Maxim
From vadim_nuclight at mail.ru  Tue Dec  9 03:18:55 2008
From: vadim_nuclight at mail.ru (Vadim Goncharov)
Date: Tue Dec  9 03:19:01 2008
Subject: who on FreeBSD 8.0 - AMD64
References: <200811240152.13032.ken@mthelicon.com>
	<slrngil6va.2di4.vadim_nuclight@server.filona.x88.info>
	<20081124122718.GB28709@rink.nu>
Message-ID: <slrngjsl0i.28qc.vadim_nuclight@server.filona.x88.info>

Hi Rink Springer! 

On Mon, 24 Nov 2008 13:27:18 +0100; Rink Springer wrote about 'Re: who on FreeBSD 8.0 - AMD64':

>> By the way, are there pseudo-terminal names renamed in -CURRENT ? Why?
> Yes, this is the result of the new giant-free TTY layer that was
> imported a few months ago.

What was the reason to rename? Isn't that a POLA violation for both
users/older software?

-- 
WBR, Vadim Goncharov. ICQ#166852181       mailto:vadim_nuclight@mail.ru
[Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/nuclight]

From bsd.quest at googlemail.com  Tue Dec  9 07:02:51 2008
From: bsd.quest at googlemail.com (Alexej Sokolov)
Date: Tue Dec  9 07:02:57 2008
Subject: vm_map (9) + MAP_PREFAULT and MAP_PREFAULT_PARTIAL
Message-ID: <20081209150221.GC2875@debian.samsung.router>

Hello, 
could anyone explain what exactly do the cow-flags MAP_PREFAULT_PARTIAL,
MAP_PREFAULT. I couldn't understand it from man pages and from source
code. 
It's mean that the pages will be wired ? 

Thanks, 

-- 
Alexej Sokolov <bsd.quest@googlemail.com>
From pluknet at gmail.com  Tue Dec  9 08:46:33 2008
From: pluknet at gmail.com (pluknet)
Date: Tue Dec  9 08:46:39 2008
Subject: who on FreeBSD 8.0 - AMD64
In-Reply-To: <slrngjsl0i.28qc.vadim_nuclight@server.filona.x88.info>
References: <200811240152.13032.ken@mthelicon.com>
	<slrngil6va.2di4.vadim_nuclight@server.filona.x88.info>
	<20081124122718.GB28709@rink.nu>
	<slrngjsl0i.28qc.vadim_nuclight@server.filona.x88.info>
Message-ID: <a31046fc0812090846i22d13377ue03e962de3690feb@mail.gmail.com>

2008/12/9 Vadim Goncharov <vadim_nuclight@mail.ru>:
> Hi Rink Springer!
>
> On Mon, 24 Nov 2008 13:27:18 +0100; Rink Springer wrote about 'Re: who on FreeBSD 8.0 - AMD64':
>
>>> By the way, are there pseudo-terminal names renamed in -CURRENT ? Why?
>> Yes, this is the result of the new giant-free TTY layer that was
>> imported a few months ago.
>
> What was the reason to rename? Isn't that a POLA violation for both
> users/older software?
>

You should read pty(4).

-- 
wbr,
pluknet
From ancelgray at yahoo.com  Tue Dec  9 10:13:31 2008
From: ancelgray at yahoo.com (ancelgray)
Date: Tue Dec  9 10:13:38 2008
Subject: Hardware support for AMD Geode CS5536 audio?
In-Reply-To: <20786956.post@talk.nabble.com>
References: <20080121170155.GC51116@hamlet.SetFilePointer.com>
	<20713056.post@talk.nabble.com>
	<e71790db0811280333g35dd9f5aqe4d78ef0f70511a9@mail.gmail.com>
	<20786956.post@talk.nabble.com>
Message-ID: <20920300.post@talk.nabble.com>


Lionel,


Well, I installed mpg123 on my PC Engines ALIX 1C and it worked fine playing
mp3 files without changing my snd_amd5536.ko driver. 

However, I have gone ahead and made a version of snd_amd5536.ko that has
larger default buffers.
Hopefully, this will work on your machine.

Go here:

http://modelofreality.org/snd_amd5536.html

and download 

snd_amd5536.ko

underneath where it says    "Here's a version with larger (2k) default
buffers for test:"

Don't forget to turn off the vchan interface with     "sysctl
dev.pcm.0.play.vchans=0"
You must do this after each driver reload.

Let me know how it goes.


Andrew


-- 
View this message in context: http://www.nabble.com/Hardware-support-for-AMD-Geode-CS5536-audio--tp15002428p20920300.html
Sent from the freebsd-hackers mailing list archive at Nabble.com.

From david at catwhisker.org  Tue Dec  9 11:01:11 2008
From: david at catwhisker.org (David Wolfskill)
Date: Tue Dec  9 11:01:17 2008
Subject: NFS (& amd?) dysfunction descending a hierarchy
In-Reply-To: <20081203001538.GC96383@bunrab.catwhisker.org>
References: <20081203001538.GC96383@bunrab.catwhisker.org>
Message-ID: <20081209190110.GW60731@albert.catwhisker.org>

On Tue, Dec 02, 2008 at 04:15:38PM -0800, David Wolfskill wrote:
> I seem to have a fairly- (though not deterministly so) reproducible
> mode of failure with an NFS-mounted directory hierarchy:  An attempt to
> traverse a "sufficiently large" hierarchy (e.g., via "tar zcpf" or "rm
> -fr") will fail to "visit" some subdirectories, typically apparently
> acting as if the subdirectories in question do not actually exist
> (despite the names having been returned in the output of a previous
> readdir()).
> ... 

I was able to reproduce the external symptoms of the failure running
CURRENT as of yesterday, using "rm -fr" of a copy of a recent
/usr/ports hierachy on an NFS-mounted file system as a test case.
However, I believe the mechanism may be a bit different -- while
still being other than what I would expect.

One aspect in which the externally-observable symptoms were different
(under CURRENT, vs. RELENG_7) is that under CURRENT, once the error
condition occurred, the NFS client machine was in a state where it
merely kept repeating

	nfs server pid848@fbsd-build:/volume: not responding

until I logged in as root & rebooted it.


Here's a cut/paste of the kdump from the ktrace of the amd(8) process
under CURRENT, showing where the master amd(8) process (pid 848)
forks a child (4126) to try the unmount:

   848 amd      1228846258.722953 CALL  gettimeofday(0x8078e48,0)
   848 amd      1228846258.722964 RET   gettimeofday 0
   848 amd      1228846258.722982 CALL  sigprocmask(SIG_BLOCK,0xbfbfeaec,0xbfbfeadc)
   848 amd      1228846258.722993 RET   sigprocmask 0
   848 amd      1228846258.723003 CALL  fork
   848 amd      1228846258.730250 RET   fork 4126/0x101e
   848 amd      1228846258.730405 CALL  sigprocmask(SIG_SETMASK,0xbfbfeadc,0)
  4126 amd      1228846258.730252 RET   fork 0
  4126 amd      1228846258.730456 CALL  getpid
  4126 amd      1228846258.730467 RET   getpid 4126/0x101e
  4126 amd      1228846258.730493 CALL  unmount(0x2825f340,<invalid>0)
   848 amd      1228846258.730422 RET   sigprocmask 0
   848 amd      1228846258.730595 CALL  gettimeofday(0x8078e48,0)
   848 amd      1228846258.730608 RET   gettimeofday 0
...
   848 amd      1228846258.914814 CALL  sigprocmask(SIG_SETMASK,0xbfbfeba0,0)
   848 amd      1228846258.914826 RET   sigprocmask 0
   848 amd      1228846258.914838 CALL  select(0x400,0xbfbfec40,0,0,0xbfbfecd8)
  4126 amd      1228846259.090428 RET   unmount 0
  4126 amd      1228846259.090492 CALL  sigprocmask(SIG_BLOCK,0x2809b080,0xbfbfea0c)
  4126 amd      1228846259.090505 RET   sigprocmask 0
  4126 amd      1228846259.090518 CALL  sigprocmask(SIG_SETMASK,0x2809b090,0)
  4126 amd      1228846259.090530 RET   sigprocmask 0
  4126 amd      1228846259.090545 CALL  sigprocmask(SIG_BLOCK,0x2809b080,0xbfbfe9dc)
  4126 amd      1228846259.090556 RET   sigprocmask 0
  4126 amd      1228846259.090576 CALL  sigprocmask(SIG_SETMASK,0x2809b090,0)
  4126 amd      1228846259.090587 RET   sigprocmask 0
  4126 amd      1228846259.090605 CALL  exit(0)
   848 amd      1228846259.091248 RET   select -1 errno 4 Interrupted system call
   848 amd      1228846259.091277 PSIG  SIGCHLD caught handler=0x805e090 mask=0x0 code=0x0
   848 amd      1228846259.091298 CALL  wait4(0xffffffff,0xbfbfe83c,WNOHANG,0)
   848 amd      1228846259.091329 RET   wait4 4126/0x101e
   848 amd      1228846259.091342 CALL  wait4(0xffffffff,0xbfbfe83c,WNOHANG,0)
   848 amd      1228846259.091352 RET   wait4 -1 errno 10 No child processes
   848 amd      1228846259.091365 CALL  sigprocmask(SIG_SETMASK,0x80795bc,0)
   848 amd      1228846259.091377 RET   sigprocmask 0
   848 amd      1228846259.091390 CALL  sigprocmask(SIG_BLOCK,0x80792c4,0)
   848 amd      1228846259.091401 RET   sigprocmask 0
   848 amd      1228846259.091411 CALL  gettimeofday(0x8078e48,0)
   848 amd      1228846259.091422 RET   gettimeofday 0

Note that while the child didn't get EBUSY (as it does under RELENG_7)
-- indeed, the unmount call appears to have returned 0 -- the master
amd(8) process looks to be seeing "errno 4 Interrupted system call."


And here's a relevent part of the kdump from the "rm -fr" -- I had
kdump spit out Epoch timestamps with each in order to make correlation
easier:

  4121 rm       1228846258.736266 CALL  unlink(0x2821c148)
  4121 rm       1228846258.736281 NAMI  "distinfo"
  4121 rm       1228846258.738329 RET   unlink 0
  4121 rm       1228846258.738379 CALL  unlink(0x2821c1b8)
  4121 rm       1228846258.738401 NAMI  "pkg-descr"
  4121 rm       1228846258.739963 RET   unlink 0
  4121 rm       1228846258.739982 CALL  open(0x28178b6b,O_RDONLY,<unused>0)
  4121 rm       1228846258.740002 NAMI  ".."
  4121 rm       1228846258.740541 RET   open 4
  4121 rm       1228846258.740558 CALL  fstat(0x4,0xbfbfe96c)
  4121 rm       1228846258.740579 STRU  struct stat {dev=67174155, ino=22674937, mode=drwxr-xr-x , nlink=114, uid=9874, gid=929, rdev=0, atime=1228846258.184514000, stime
=1228846258.779501000, ctime=1228846258.779501000, birthtime=-1, size=12288, blksize=4096, blocks=24, flags=0x0 }
  4121 rm       1228846258.740593 RET   fstat 0
  4121 rm       1228846258.740608 CALL  fchdir(0x4)
  4121 rm       1228846258.740626 RET   fchdir 0
  4121 rm       1228846258.740641 CALL  close(0x4)
  4121 rm       1228846258.740976 RET   close 0
  4121 rm       1228846258.740991 CALL  rmdir(0x2821c538)
  4121 rm       1228846258.741007 NAMI  "dnscheck"
  4121 rm       1228846258.741764 RET   rmdir 0
  4121 rm       1228846258.741783 CALL  stat(0x2821d028,0xbfbfe900)
  4121 rm       1228846258.741799 NAMI  "dnsdoctor"
  4121 rm       1228846258.742050 STRU  struct stat {dev=67174155, ino=2519891, mode=drwxr-xr-x , nlink=3, uid=9874, gid=929, rdev=0, atime=1228844788, stime=1227555712, 
ctime=1228845836.981842000, birthtime=-1, size=4096, blksize=4096, blocks=8, flags=0x0 }
  4121 rm       1228846258.742066 RET   stat 0
  4121 rm       1228846258.742080 CALL  open(0x2821d028,O_NONBLOCK,<unused>0x28200000)
  4121 rm       1228846258.742097 NAMI  "dnsdoctor"
  4121 rm       1228846258.742419 RET   open 4
  4121 rm       1228846258.742435 CALL  fstat(0x4,0xbfbfe6a0)
  4121 rm       1228846258.742452 STRU  struct stat {dev=67174155, ino=2519891, mode=drwxr-xr-x , nlink=3, uid=9874, gid=929, rdev=0, atime=1228844788, stime=1227555712, 
ctime=1228845836.981842000, birthtime=-1, size=4096, blksize=4096, blocks=8, flags=0x0 }
  4121 rm       1228846258.742465 RET   fstat 0
  4121 rm       1228846258.742480 CALL  fcntl(0x4,F_SETFD,FD_CLOEXEC)
  4121 rm       1228846258.742495 RET   fcntl 0
  4121 rm       1228846258.742516 CALL  fstatfs(0x4,0xbfbfe700)
  4121 rm       1228846258.742792 RET   fstatfs -1 errno 2 No such file or directory
  4121 rm       1228846258.742809 CALL  close(0x4)
  4121 rm       1228846258.743187 RET   close 0
  4121 rm       1228846258.743203 CALL  stat(0x2821d098,0xbfbfe900)
  4121 rm       1228846258.743219 NAMI  "dnsflood"
  4121 rm       1228846258.743544 STRU  struct stat {dev=67174155, ino=2519892, mode=drwxr-xr-x , nlink=3, uid=9874, gid=929, rdev=0, atime=1228844788, stime=1227555712, ctime=1228845836.978868000, birthtime=-1, size=4096, blksize=4096, blocks=8, flags=0x0 }
  4121 rm       1228846258.743559 RET   stat 0
  4121 rm       1228846258.743574 CALL  open(0x2821d098,O_NONBLOCK,<unused>0x28200000)
  4121 rm       1228846258.743590 NAMI  "dnsflood"
  4121 rm       1228846258.743792 RET   open 4
  4121 rm       1228846258.743809 CALL  fstat(0x4,0xbfbfe6a0)
  4121 rm       1228846258.743826 STRU  struct stat {dev=67174155, ino=2519892, mode=drwxr-xr-x , nlink=3, uid=9874, gid=929, rdev=0, atime=1228844788, stime=1227555712, ctime=1228845836.978868000, birthtime=-1, size=4096, blksize=4096, blocks=8, flags=0x0 }
  4121 rm       1228846258.743840 RET   fstat 0
  4121 rm       1228846258.743854 CALL  fcntl(0x4,F_SETFD,FD_CLOEXEC)
  4121 rm       1228846258.743867 RET   fcntl 0
  4121 rm       1228846258.743882 CALL  fstatfs(0x4,0xbfbfe700)
  4121 rm       1228846258.744008 RET   fstatfs -1 errno 2 No such file or directory
  4121 rm       1228846258.744022 CALL  close(0x4)
  4121 rm       1228846258.744411 RET   close 0

[I included a moderate amount of successful processing near the
beginning of that excerpt, so folks could see the pattern.]


In contrast, here are the similar kdump excerpts from RELENG_7:

   702 amd      1228774660.297858 CALL  gettimeofday(0x807ad48,0)
   702 amd      1228774660.297864 RET   gettimeofday 0
   702 amd      1228774660.297872 CALL  sigprocmask(SIG_BLOCK,0xbfbfeaec,0xbfbfeadc)
   702 amd      1228774660.297878 RET   sigprocmask 0
   702 amd      1228774660.297883 CALL  fork
   702 amd      1228774660.302658 RET   fork 16840/0x41c8
 16840 amd      1228774660.302660 RET   fork 0
   702 amd      1228774660.302689 CALL  sigprocmask(SIG_SETMASK,0xbfbfeadc,0)
 16840 amd      1228774660.302707 CALL  getpid
 16840 amd      1228774660.302725 RET   getpid 16840/0x41c8
   702 amd      1228774660.302715 RET   sigprocmask 0
   702 amd      1228774660.302746 CALL  gettimeofday(0x807ad48,0)
 16840 amd      1228774660.302753 CALL  unmount(0x2837d310,<invalid>0)
   702 amd      1228774660.302753 RET   gettimeofday 0
...
   702 amd      1228774660.417933 CALL  select(0x400,0xbfbfec40,0,0,0xbfbfecd8)
 16840 amd      1228774660.434632 RET   unmount -1 errno 16 Device busy
 16840 amd      1228774660.434684 CALL  sigprocmask(SIG_BLOCK,0x28097c00,0xbfbfea0c)
 16840 amd      1228774660.434691 RET   sigprocmask 0
 16840 amd      1228774660.434699 CALL  sigprocmask(SIG_SETMASK,0x28097c10,0)
 16840 amd      1228774660.434705 RET   sigprocmask 0
 16840 amd      1228774660.434713 CALL  sigprocmask(SIG_BLOCK,0x28097c00,0xbfbfe9dc)
 16840 amd      1228774660.434718 RET   sigprocmask 0
 16840 amd      1228774660.434729 CALL  sigprocmask(SIG_SETMASK,0x28097c10,0)
 16840 amd      1228774660.434734 RET   sigprocmask 0
 16840 amd      1228774660.434745 CALL  exit(0x10)
   702 amd      1228774660.435214 RET   select -1 errno 4 Interrupted system call
   702 amd      1228774660.435227 PSIG  SIGCHLD caught handler=0x805de20 mask=0x0 code=0x0
   702 amd      1228774660.435237 CALL  wait4(0xffffffff,0xbfbfe83c,WNOHANG,0)
   702 amd      1228774660.435255 RET   wait4 16840/0x41c8
   702 amd      1228774660.435296 CALL  wait4(0xffffffff,0xbfbfe83c,WNOHANG,0)
   702 amd      1228774660.435302 RET   wait4 -1 errno 10 No child processes
   702 amd      1228774660.435307 CALL  sigprocmask(SIG_SETMASK,0x807ba7c,0)
   702 amd      1228774660.435312 RET   sigprocmask 0
   702 amd      1228774660.435317 CALL  sigprocmask(SIG_BLOCK,0x807b784,0)
   702 amd      1228774660.435323 RET   sigprocmask 0

and:

 16835 rm       1228774660.305162 CALL  open(0x2816280b,O_RDONLY,<unused>0)
 16835 rm       1228774660.305173 NAMI  ".."
 16835 rm       1228774660.305626 RET   open 4
 16835 rm       1228774660.305634 CALL  fstat(0x4,0xbfbfe93c)
 16835 rm       1228774660.305644 STRU  struct stat {dev=50396945, ino=29713037, mode=drwxr-xr-x , nlink=91, uid=9874, gid=929, rdev=0, atime=1228774657.877477000, stime=
1228774660.314260000, ctime=1228774660.314260000, birthtime=0, size=20480, blksize=4096, blocks=40, flags=0x0 }
 16835 rm       1228774660.305651 RET   fstat 0
 16835 rm       1228774660.305658 CALL  fchdir(0x4)
 16835 rm       1228774660.305667 RET   fchdir 0
 16835 rm       1228774660.305674 CALL  close(0x4)
 16835 rm       1228774660.305824 RET   close 0
 16835 rm       1228774660.305831 CALL  rmdir(0x2821afe8)
 16835 rm       1228774660.305838 NAMI  "p-interp"
 16835 rm       1228774660.306498 RET   rmdir 0
 16835 rm       1228774660.306513 CALL  stat(0x28218b48,0xbfbfe8cc)
 16835 rm       1228774660.306519 NAMI  "pcemu"
 16835 rm       1228774660.306756 STRU  struct stat {dev=50396945, ino=8465981, mode=drwxr-xr-x , nlink=5, uid=9874, gid=929, rdev=0, atime=1228772282, stime=1227555736, 
ctime=1228773351.399184000, birthtime=0, size=4096, blksize=4096, blocks=8, flags=0x0 }
 16835 rm       1228774660.306764 RET   stat 0
 16835 rm       1228774660.306770 CALL  open(0x28218b48,O_NONBLOCK,<unused>0x1)
 16835 rm       1228774660.306776 NAMI  "pcemu"
 16835 rm       1228774660.307003 RET   open 4
 16835 rm       1228774660.307010 CALL  fstat(0x4,0xbfbfe8cc)
 16835 rm       1228774660.307018 STRU  struct stat {dev=50396945, ino=8465981, mode=drwxr-xr-x , nlink=5, uid=9874, gid=929, rdev=0, atime=1228772282, stime=1227555736, 
ctime=1228773351.399184000, birthtime=0, size=4096, blksize=4096, blocks=8, flags=0x0 }
 16835 rm       1228774660.307025 RET   fstat 0
 16835 rm       1228774660.307031 CALL  fcntl(0x4,F_SETFD,FD_CLOEXEC)
 16835 rm       1228774660.307039 RET   fcntl 0
 16835 rm       1228774660.307049 CALL  fstatfs(0x4,0xbfbfe6f4)
 16835 rm       1228774660.307294 RET   fstatfs -1 errno 2 No such file or directory
 16835 rm       1228774660.307302 CALL  close(0x4)
 16835 rm       1228774660.307549 RET   close 0
 16835 rm       1228774660.307557 CALL  stat(0x28218b98,0xbfbfe8cc)
 16835 rm       1228774660.307563 NAMI  "pearpc"
 16835 rm       1228774660.307759 STRU  struct stat {dev=50396945, ino=27094159, mode=drwxr-xr-x , nlink=4, uid=9874, gid=929, rdev=0, atime=1228772282, stime=1227555736, ctime=1228773351.390236000, birthtime=0, size=4096, blksize=4096, blocks=8, flags=0x0 }
 16835 rm       1228774660.307767 RET   stat 0
 16835 rm       1228774660.307772 CALL  open(0x28218b98,O_NONBLOCK,<unused>0x1)
 16835 rm       1228774660.307779 NAMI  "pearpc"
 16835 rm       1228774660.308000 RET   open 4
 16835 rm       1228774660.308007 CALL  fstat(0x4,0xbfbfe8cc)
 16835 rm       1228774660.308015 STRU  struct stat {dev=50396945, ino=27094159, mode=drwxr-xr-x , nlink=4, uid=9874, gid=929, rdev=0, atime=1228772282, stime=1227555736, ctime=1228773351.390236000, birthtime=0, size=4096, blksize=4096, blocks=8, flags=0x0 }
 16835 rm       1228774660.308021 RET   fstat 0
 16835 rm       1228774660.308026 CALL  fcntl(0x4,F_SETFD,FD_CLOEXEC)
 16835 rm       1228774660.308032 RET   fcntl 0
 16835 rm       1228774660.308038 CALL  fstatfs(0x4,0xbfbfe6f4)
 16835 rm       1228774660.308101 RET   fstatfs -1 errno 2 No such file or directory
 16835 rm       1228774660.308108 CALL  close(0x4)
 16835 rm       1228774660.308350 RET   close 0


So either way, the user-level program attempting the directory hierarchy
traversal can be coded to be very careful, yet still receive a rude
surprise -- the system saying that a file that the program had already
opened (and still has opened) does not exist.

How rude!  :-{

I'll be very happy to test suggested patches, whether intended to fix
the problem or merely facilitate diagnosis.  That said, it shouldn't be
difficult to reproduce this -- I did it with a copy  of /usr/ports; a
colleague has reported doing so with a copy of /usr/src (though I
haven't witnessed that).

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: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20081209/340bd551/attachment.pgp
From kostikbel at gmail.com  Tue Dec  9 12:04:37 2008
From: kostikbel at gmail.com (Kostik Belousov)
Date: Tue Dec  9 12:04:44 2008
Subject: NFS (& amd?) dysfunction descending a hierarchy
In-Reply-To: <20081209190110.GW60731@albert.catwhisker.org>
References: <20081203001538.GC96383@bunrab.catwhisker.org>
	<20081209190110.GW60731@albert.catwhisker.org>
Message-ID: <20081209200431.GL2038@deviant.kiev.zoral.com.ua>

On Tue, Dec 09, 2008 at 11:01:10AM -0800, David Wolfskill wrote:
> On Tue, Dec 02, 2008 at 04:15:38PM -0800, David Wolfskill wrote:
> > I seem to have a fairly- (though not deterministly so) reproducible
> > mode of failure with an NFS-mounted directory hierarchy:  An attempt to
> > traverse a "sufficiently large" hierarchy (e.g., via "tar zcpf" or "rm
> > -fr") will fail to "visit" some subdirectories, typically apparently
> > acting as if the subdirectories in question do not actually exist
> > (despite the names having been returned in the output of a previous
> > readdir()).
> > ... 
> 

Did you saw me previous answer ? Supposed patch for your problem was
committed to head as r185557, and MFCed to 7 in r185796, and to
7.1 in r185801.

Please test with latest sources.
-------------- 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-hackers/attachments/20081209/242c381c/attachment.pgp
From marius at alchemy.franken.de  Tue Dec  9 14:24:52 2008
From: marius at alchemy.franken.de (Marius Strobl)
Date: Tue Dec  9 14:24:59 2008
Subject: Syscons with xterm emulation: one step closer to UTF-8 support?
In-Reply-To: <20081206155908.GG18652@hoeg.nl>
References: <20081206155908.GG18652@hoeg.nl>
Message-ID: <20081209221157.GA21934@alchemy.franken.de>

On Sat, Dec 06, 2008 at 04:59:08PM +0100, Ed Schouten wrote:
> 
> My question is if there are people out there who could help me
> implementing UTF-8 font rendering. I wouldn't have a clue where to
> start (yet).
> 

When implementing UTF-8 font rendering/creating UTF-8 fonts
please take into account 12x22 fonts as framebuffers used
on sparc64 have to be considered fixed mode and fonts
smaller than the Sun default look really bad with these
resolutions.

Marius

From julian at elischer.org  Tue Dec  9 14:48:37 2008
From: julian at elischer.org (Julian Elischer)
Date: Tue Dec  9 14:48:44 2008
Subject: NFS (& amd?) dysfunction descending a hierarchy
In-Reply-To: <20081209200431.GL2038@deviant.kiev.zoral.com.ua>
References: <20081203001538.GC96383@bunrab.catwhisker.org>	<20081209190110.GW60731@albert.catwhisker.org>
	<20081209200431.GL2038@deviant.kiev.zoral.com.ua>
Message-ID: <493EEF15.4050600@elischer.org>

Kostik Belousov wrote:
> On Tue, Dec 09, 2008 at 11:01:10AM -0800, David Wolfskill wrote:
>> On Tue, Dec 02, 2008 at 04:15:38PM -0800, David Wolfskill wrote:
>>> I seem to have a fairly- (though not deterministly so) reproducible
>>> mode of failure with an NFS-mounted directory hierarchy:  An attempt to
>>> traverse a "sufficiently large" hierarchy (e.g., via "tar zcpf" or "rm
>>> -fr") will fail to "visit" some subdirectories, typically apparently
>>> acting as if the subdirectories in question do not actually exist
>>> (despite the names having been returned in the output of a previous
>>> readdir()).
>>> ... 
> 
> Did you saw me previous answer ? Supposed patch for your problem was
> committed to head as r185557, and MFCed to 7 in r185796, and to
> 7.1 in r185801.
> 
> Please test with latest sources.


did you notice that he tested with latest -current and releng 7?

From david at catwhisker.org  Tue Dec  9 14:55:22 2008
From: david at catwhisker.org (David Wolfskill)
Date: Tue Dec  9 14:55:29 2008
Subject: NFS (& amd?) dysfunction descending a hierarchy
In-Reply-To: <493EEF15.4050600@elischer.org>
References: <20081203001538.GC96383@bunrab.catwhisker.org>
	<20081209190110.GW60731@albert.catwhisker.org>
	<20081209200431.GL2038@deviant.kiev.zoral.com.ua>
	<493EEF15.4050600@elischer.org>
Message-ID: <20081209225520.GB60731@albert.catwhisker.org>

On Tue, Dec 09, 2008 at 02:20:05PM -0800, Julian Elischer wrote:
> Kostik Belousov wrote:
> >...
> >Did you saw me previous answer ? Supposed patch for your problem was
> >committed to head as r185557, and MFCed to 7 in r185796, and to
> >7.1 in r185801.
> >
> >Please test with latest sources.
> 
> did you notice that he tested with latest -current and releng 7?

CURRENT was as of yesterday, as was RELENG_7; while kib@'s commit
hit HEAD on 02 Dec, but didn't hit RELENG_7 until after I grabbed
the sources for RELENG_7 yesterday.

I have some local infrastructure hassles to deal with so I can update
the sources in question, but I will test RELENG_7 with the commit &
report back.

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: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20081209/e48545f5/attachment.pgp
From paul at fletchermoorland.co.uk  Tue Dec  9 16:33:46 2008
From: paul at fletchermoorland.co.uk (Paul Wootton)
Date: Tue Dec  9 16:34:24 2008
Subject: Problems with zfsboot loader if raidz present on any drive
In-Reply-To: <200812071217.20500.ken@mthelicon.com>
References: <200812070319.18461.ken@mthelicon.com><66BF33BA-EC11-446F-9DE7-15395F293FE2@rabson.org>
	<200812071217.20500.ken@mthelicon.com>
Message-ID: <B4E4298CA0FC4E3489A0633F4E1105FF@apollo>

>-----Original Message-----
>From: owner-freebsd-hackers@freebsd.org 
>[mailto:owner-freebsd-hackers@freebsd.org] On Behalf Of Pegasus Mc 
>Cleaft
>Sent: 07 December 2008 12:17
> To: Doug Rabson
> Cc: hackers@freebsd.org; current@freebsd.org
> Subject: Re: Problems with zfsboot loader if raidz present on any 
>drive
> 
> On Sunday 07 December 2008 09:22:16 Doug Rabson wrote:
> On 7 Dec 2008, at 03:19, Pegasus Mc Cleaft wrote:
> > > Hello Hackers,
> > >
> > > 	Recently and friend and I have been trying to get the new 
> > > gptzfsboot working on our machines and ran into a interesting 
> > > problem.
> > >
> > > 	Initially I was building the world without the environment 
> > > variable LOADER_ZFS_SUPPORT=YES in the /etc/make.conf and this, of 
> > > course, didnt work very well. Every time the machine booted, it 
> > > would throw 2 lines after the pin-wheel and then reboot. I 
> > > couldent read what the lines were it went so fast.
> > >
> > > 	My friend had a bit more luck and got his machine working OK with 
> > > a single drive and later a mirror drive added.
> > >
> > > 	I added the environment variable and rebuilt everything and 
> > > installed. This time, I could see the bios drives and a further 2 
> > > lines of ZFS something and a reboot...
> > >
> > > 	No matter what I tried, I couldent get the machine to boot up to 
> > > a point where I could try and fix the problem, so I started 
> > > pulling devices out and found the following: If there is a raidz 
> > > pool on any drive (not necessarily the one that you are trying to 
> > > boot from) the loader dies and reboots the machine. My friend, as 
> > > an experiment created 3 gpt partitions (in addition to the single 
> > > partition that he had been previously booted from) on his single 
> > > drive and made a raidz pool for testing. His machine showed the 
> > > same condition as mine, however he was able to capture the message 
> > > before the machine
> > > rebooted:
> > >
> > > <message>
> > > ZFS: can only boot from disk or mirror vdevs
> > >
> > > ZFS: inconsistent nvlist contents
> >
> > The zfsboot code in current doesn't support raidz or raidz2. I have 
> > been working on adding that support but its not ready yet. The code 
> > works in my test harness but crashes instantly when I put it in the 
> > boot code :(. I should have time to finish debugging it soon.
> 
> Hi Doug,
> 
> 	In my haste to put a message to the group, I didnt do a very good
job 
> of explaining or give what platform I was working with.
> 
> 	I set up a single disk pool with the gptzfsboot code on it as a boot
drive. 
> My idea was to have a single disk boot (and after it boots and I can 
> kill the UFS drive I am currently booting from) convert it to a 
> mirror. But I have 6 other drives in the machine that I have as a raidz
for my /usr/home, et al.
> 
> 	If the 6 raidz drives are present at boot time, the machine starts
to 
> cyclic reboot just after the pin-wheel.
> 
> 	The machine I am working on is running FBSD8.0-Current as of
midnight
> 7/12/2008 and the platform is AMD64. 
> 
> 	If I can help test in any way I would be more than happy to try, or 
> provide any information necessary..
> 
> ~Peg

Hi Doug,
I was working with Peg on this over the weekend.
I think I have a patch for this - see
http://www.freebsd.org/cgi/query-pr.cgi?pr=129539
The problem was that we were not checking the return code from
vdev_init_from_nvlist() on line 726 in /usr/src/sys/boot/zfs/zfsimpl.c


Joao,
Do you want to try the attached patch? It seems to have fixed the problem,
at least on mine and Peg's machine. 


Cheers
Paul
-------------- next part --------------
A non-text attachment was scrubbed...
Name: zfsimpl.c.patch
Type: application/octet-stream
Size: 792 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20081210/a9fd1481/zfsimpl.c.obj
From stutiredboy at gmail.com  Tue Dec  9 22:25:51 2008
From: stutiredboy at gmail.com (=?GB2312?B?s8LQocn6?=)
Date: Tue Dec  9 22:25:58 2008
Subject: [help]strange problem about gethostbyname/getaddrinfo
Message-ID: <a35775750812092157i715ccb4bn542b871e1cb61fe0@mail.gmail.com>

hi,all,we have a project which must resolv some domains in the server
process
our system in FreeBSD 6.2 or 6.3, the server process may open 7000+
sockets,not fork
we have set the maxopensockets as 65536,as follows:

kern.ipc.numopensockets: 4737
kern.ipc.maxsockets: 65536
socket:          356,    65538,   4737,   6747, 64793968

and the follow is our limit info:

cputime      unlimited
filesize     unlimited
datasize     2621440 kbytes
stacksize    65536 kbytes
coredumpsize unlimited
memoryuse    unlimited
vmemoryuse   unlimited
descriptors  655000
memorylocked unlimited
maxproc      5547
sbsize       unlimited

I am sure we have set the /etc/reslov.conf correctly, I can resolve any
legal domain
use dig or gethostbyname or getaddrinfo in my another test program

The problem is we found when the server porcess open 1000+ or higher
sockets(but we
can query any legal domain in the system  normally), the gethostbyname or
getaddrinfo
might fetch nothing(sometimes the query is ok), the gethostbyname's return
error is:
errno=2,strerror=Host name lookup failure

and the getaddrinfo's return error is:
"hostname nor servname provided, or not known",    /* EAI_NONAME */

we have tried to use the tcpdump to analyse the query packets, unluckily ,
we catch nothing,
seem like that the program does not query anything(or get none dns
server,even 127.0.0.1) ,
neither using gethostbyname nor getaddrinfo,and we also try set the query
type as tcp and udp,
the same disappointment result.

The stranger thing is we have tried to run another demo process which have
open 4000+ sockets,
all work well..so the problem might not related to open too much
sockets..and we found that, even
we set the /etc/resolve.conf nothing, normally the gethostbyname/getaddrinfo
will check
127.0.0.1, and we can get the query packets

The server process's query is under a single process not multi threads

Can anyone help me analyse the error/problem, which may raise this situation
or any useful info,
thanks very much !
From crquan at gmail.com  Tue Dec  9 23:07:43 2008
From: crquan at gmail.com (Cheng Renquan)
Date: Tue Dec  9 23:07:53 2008
Subject: [help]strange problem about gethostbyname/getaddrinfo
In-Reply-To: <a35775750812092157i715ccb4bn542b871e1cb61fe0@mail.gmail.com>
References: <a35775750812092157i715ccb4bn542b871e1cb61fe0@mail.gmail.com>
Message-ID: <91b13c310812092236j7063f177yafd83948a891ea76@mail.gmail.com>

On Wed, Dec 10, 2008 at 1:57 PM, ??? <stutiredboy@gmail.com> wrote:
> hi,all,we have a project which must resolv some domains in the server
> process
> our system in FreeBSD 6.2 or 6.3, the server process may open 7000+
> sockets,not fork
> we have set the maxopensockets as 65536,as follows:

Use strace to trace it,

-- 
Cheng Renquan, Shenzhen, China
Marie von Ebner-Eschenbach  - "Even a stopped clock is right twice a day."
From rdivacky at freebsd.org  Wed Dec 10 00:09:19 2008
From: rdivacky at freebsd.org (Roman Divacky)
Date: Wed Dec 10 00:09:27 2008
Subject: [help]strange problem about gethostbyname/getaddrinfo
In-Reply-To: <91b13c310812092236j7063f177yafd83948a891ea76@mail.gmail.com>
References: <a35775750812092157i715ccb4bn542b871e1cb61fe0@mail.gmail.com>
	<91b13c310812092236j7063f177yafd83948a891ea76@mail.gmail.com>
Message-ID: <20081210080431.GA29866@freebsd.org>

On Wed, Dec 10, 2008 at 02:36:27PM +0800, Cheng Renquan wrote:
> On Wed, Dec 10, 2008 at 1:57 PM, ????????? <stutiredboy@gmail.com> wrote:
> > hi,all,we have a project which must resolv some domains in the server
> > process
> > our system in FreeBSD 6.2 or 6.3, the server process may open 7000+
> > sockets,not fork
> > we have set the maxopensockets as 65536,as follows:
> 
> Use strace to trace it,

I personally found strace on fbsd to lie to me everytime. I'd avoid
that and use ktrace/kdump instead...
From dfr at rabson.org  Wed Dec 10 00:29:01 2008
From: dfr at rabson.org (Doug Rabson)
Date: Wed Dec 10 00:29:14 2008
Subject: Problems with zfsboot loader if raidz present on any drive
In-Reply-To: <B4E4298CA0FC4E3489A0633F4E1105FF@apollo>
References: <200812070319.18461.ken@mthelicon.com><66BF33BA-EC11-446F-9DE7-15395F293FE2@rabson.org>
	<200812071217.20500.ken@mthelicon.com>
	<B4E4298CA0FC4E3489A0633F4E1105FF@apollo>
Message-ID: <FF8077BD-5A8D-4479-8968-65F2C52F4070@rabson.org>


On 9 Dec 2008, at 23:54, Paul Wootton wrote:

>> -----Original Message-----
>> From: owner-freebsd-hackers@freebsd.org
>> [mailto:owner-freebsd-hackers@freebsd.org] On Behalf Of Pegasus Mc
>> Cleaft
>> Sent: 07 December 2008 12:17
>> To: Doug Rabson
>> Cc: hackers@freebsd.org; current@freebsd.org
>> Subject: Re: Problems with zfsboot loader if raidz present on any
>> drive
>>
>> On Sunday 07 December 2008 09:22:16 Doug Rabson wrote:
>> On 7 Dec 2008, at 03:19, Pegasus Mc Cleaft wrote:
>>>> Hello Hackers,
>>>>
>>>> 	Recently and friend and I have been trying to get the new
>>>> gptzfsboot working on our machines and ran into a interesting
>>>> problem.
>>>>
>>>> 	Initially I was building the world without the environment
>>>> variable LOADER_ZFS_SUPPORT=YES in the /etc/make.conf and this, of
>>>> course, didnt work very well. Every time the machine booted, it
>>>> would throw 2 lines after the pin-wheel and then reboot. I
>>>> couldent read what the lines were it went so fast.
>>>>
>>>> 	My friend had a bit more luck and got his machine working OK with
>>>> a single drive and later a mirror drive added.
>>>>
>>>> 	I added the environment variable and rebuilt everything and
>>>> installed. This time, I could see the bios drives and a further 2
>>>> lines of ZFS something and a reboot...
>>>>
>>>> 	No matter what I tried, I couldent get the machine to boot up to
>>>> a point where I could try and fix the problem, so I started
>>>> pulling devices out and found the following: If there is a raidz
>>>> pool on any drive (not necessarily the one that you are trying to
>>>> boot from) the loader dies and reboots the machine. My friend, as
>>>> an experiment created 3 gpt partitions (in addition to the single
>>>> partition that he had been previously booted from) on his single
>>>> drive and made a raidz pool for testing. His machine showed the
>>>> same condition as mine, however he was able to capture the message
>>>> before the machine
>>>> rebooted:
>>>>
>>>> <message>
>>>> ZFS: can only boot from disk or mirror vdevs
>>>>
>>>> ZFS: inconsistent nvlist contents
>>>
>>> The zfsboot code in current doesn't support raidz or raidz2. I have
>>> been working on adding that support but its not ready yet. The code
>>> works in my test harness but crashes instantly when I put it in the
>>> boot code :(. I should have time to finish debugging it soon.
>>
>> Hi Doug,
>>
>> 	In my haste to put a message to the group, I didnt do a very good
> job
>> of explaining or give what platform I was working with.
>>
>> 	I set up a single disk pool with the gptzfsboot code on it as a boot
> drive.
>> My idea was to have a single disk boot (and after it boots and I can
>> kill the UFS drive I am currently booting from) convert it to a
>> mirror. But I have 6 other drives in the machine that I have as a  
>> raidz
> for my /usr/home, et al.
>>
>> 	If the 6 raidz drives are present at boot time, the machine starts
> to
>> cyclic reboot just after the pin-wheel.
>>
>> 	The machine I am working on is running FBSD8.0-Current as of
> midnight
>> 7/12/2008 and the platform is AMD64.
>>
>> 	If I can help test in any way I would be more than happy to try, or
>> provide any information necessary..
>>
>> ~Peg
>
> Hi Doug,
> I was working with Peg on this over the weekend.
> I think I have a patch for this - see
> http://www.freebsd.org/cgi/query-pr.cgi?pr=129539
> The problem was that we were not checking the return code from
> vdev_init_from_nvlist() on line 726 in /usr/src/sys/boot/zfs/zfsimpl.c
>
>
> Joao,
> Do you want to try the attached patch? It seems to have fixed the  
> problem,
> at least on mine and Peg's machine.

This looks like the right fix. I will commit something similar to this  
today.

From des at des.no  Wed Dec 10 03:21:26 2008
From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=)
Date: Wed Dec 10 03:21:38 2008
Subject: MAXFILES in subr_param.c
In-Reply-To: <ghjt9l$hg3$1@ger.gmane.org> (Ivan Voras's message of "Mon, 08
	Dec 2008 20:41:32 +0100")
References: <ghjt9l$hg3$1@ger.gmane.org>
Message-ID: <863agws2bv.fsf@ds4.des.no>

Ivan Voras <ivoras@freebsd.org> writes:
> I'm looking at kern/subr_param.c:
>
>  72 #ifndef MAXFILES
>  73 #define MAXFILES (maxproc * 2)
>  74 #endif
>
> Shouldn't this be at least maxproc*3, for stdin,out,err for every proc?

Even maxproc * 3 won't be enough, unless none of your processes actually
do anything.  It's just an arbitrary value, based on the assumption that
you will never have maxproc concurrent processes anyway.

> Also, it looks like MAXFILES is used only once, and in a bit funny way:
>
> 238         maxfiles = MAXFILES;
> 239         TUNABLE_INT_FETCH("kern.maxfiles", &maxfiles);
> 240         maxprocperuid = (maxproc * 9) / 10;
> 241         maxfilesperproc = (maxfiles * 9) / 10;

What's funny about it?

> Historical reasons?

To a certain degree, yes; MAXFILES used to be a static limit which you
could only change in your kernel config.  It is now a loader tunable
(though you can still change the default in your kernel config), so the
MAXFILES macro was replaced with a maxfiles variable wherever it is
used, and the former is now only used to initialize the latter.

DES
-- 
Dag-Erling Sm?rgrav - des@des.no
From ivoras at freebsd.org  Wed Dec 10 05:30:40 2008
From: ivoras at freebsd.org (Ivan Voras)
Date: Wed Dec 10 05:30:48 2008
Subject: MAXFILES in subr_param.c
In-Reply-To: <863agws2bv.fsf@ds4.des.no>
References: <ghjt9l$hg3$1@ger.gmane.org> <863agws2bv.fsf@ds4.des.no>
Message-ID: <ghog9e$r4e$1@ger.gmane.org>

Dag-Erling Sm?rgrav wrote:
> Ivan Voras <ivoras@freebsd.org> writes:
>> I'm looking at kern/subr_param.c:
>>
>>  72 #ifndef MAXFILES
>>  73 #define MAXFILES (maxproc * 2)
>>  74 #endif
>>
>> Shouldn't this be at least maxproc*3, for stdin,out,err for every proc?
> 
> Even maxproc * 3 won't be enough, unless none of your processes actually
> do anything. 
> It's just an arbitrary value, based on the assumption that
> you will never have maxproc concurrent processes anyway.

Ok.

> 
>> Also, it looks like MAXFILES is used only once, and in a bit funny way:
>>
>> 238         maxfiles = MAXFILES;
>> 239         TUNABLE_INT_FETCH("kern.maxfiles", &maxfiles);
>> 240         maxprocperuid = (maxproc * 9) / 10;
>> 241         maxfilesperproc = (maxfiles * 9) / 10;
> 
> What's funny about it?

MAXFILES is a macro used only once, where it resolves to (maxproc*2).
It's not technically incorrect, but it looks like it adds noise.

>> Historical reasons?
> 
> To a certain degree, yes; MAXFILES used to be a static limit which you
> could only change in your kernel config.  It is now a loader tunable
> (though you can still change the default in your kernel config), so the
> MAXFILES macro was replaced with a maxfiles variable wherever it is
> used, and the former is now only used to initialize the latter.

Ok.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20081210/d8dd283d/signature.pgp
From issapoet at gmail.com  Tue Dec  9 18:36:26 2008
From: issapoet at gmail.com (=?KOI8-R?B?4MzJ0SDzzc/Mycs=?=)
Date: Wed Dec 10 06:14:25 2008
Subject: FreeBSD
Message-ID: <b2945a570812091817qd72e6cep72f62d70d1a385b7@mail.gmail.com>

Hello dear command of developers of FreeBSD. I wish to take part in the
project on developing out of FreeBSD and to subscribe for dispatch.

Excuse me for my English.
From keramida at ceid.upatras.gr  Wed Dec 10 07:00:18 2008
From: keramida at ceid.upatras.gr (Giorgos Keramidas)
Date: Wed Dec 10 07:00:26 2008
Subject: MAXFILES in subr_param.c
In-Reply-To: <ghjt9l$hg3$1@ger.gmane.org> (Ivan Voras's message of "Mon, 08
	Dec 2008 20:41:32 +0100")
References: <ghjt9l$hg3$1@ger.gmane.org>
Message-ID: <87fxkwdqiz.fsf@kobe.laptop>

On Mon, 08 Dec 2008 20:41:32 +0100, Ivan Voras <ivoras@freebsd.org> wrote:
> Hi,
>
> I'm looking at kern/subr_param.c:
>
>  72 #ifndef MAXFILES
>  73 #define MAXFILES (maxproc * 2)
>  74 #endif
>
> Shouldn't this be at least maxproc*3, for stdin,out,err for every proc?
>
> Also, it looks like MAXFILES is used only once, and in a bit funny way:
>
> 238         maxfiles = MAXFILES;
> 239         TUNABLE_INT_FETCH("kern.maxfiles", &maxfiles);
> 240         maxprocperuid = (maxproc * 9) / 10;
> 241         maxfilesperproc = (maxfiles * 9) / 10;

This is an attempt to limit a rogue process from grabbing the full
maxfiles or maxproc value by opening too many files.  There will still
be (maxfiles / 10) file descriptors available and (maxproc / 10) process
table entries, so that you can for example try to log into the system
as root and try to fix things.

You can still cause all sorts of trouble by *forking* and then going off
into a file descriptor allocation spree, but as I said this is an
_attempt_ at keeping things in a relatively sane state in the _default_
state.  You can still use the loader to set the actual values of the
`kern.maxprocperuid' and `kern.maxfilesperproc' tunables to something
that is more robust for your particular application.

The defaults are just a `best effort' guess to keep things working in
the most common case.  Nothing funny about them :)

From keramida at ceid.upatras.gr  Wed Dec 10 07:02:41 2008
From: keramida at ceid.upatras.gr (Giorgos Keramidas)
Date: Wed Dec 10 07:02:47 2008
Subject: MAXFILES in subr_param.c
In-Reply-To: <ghog9e$r4e$1@ger.gmane.org> (Ivan Voras's message of "Wed, 10
	Dec 2008 14:30:24 +0100")
References: <ghjt9l$hg3$1@ger.gmane.org> <863agws2bv.fsf@ds4.des.no>
	<ghog9e$r4e$1@ger.gmane.org>
Message-ID: <87bpvkdqex.fsf@kobe.laptop>

On Wed, 10 Dec 2008 14:30:24 +0100, Ivan Voras <ivoras@freebsd.org> wrote:
>>> Also, it looks like MAXFILES is used only once, and in a bit funny way:
>>>
>>> 238         maxfiles = MAXFILES;
>>> 239         TUNABLE_INT_FETCH("kern.maxfiles", &maxfiles);
>>> 240         maxprocperuid = (maxproc * 9) / 10;
>>> 241         maxfilesperproc = (maxfiles * 9) / 10;
>>
>> What's funny about it?
>
> MAXFILES is a macro used only once, where it resolves to (maxproc*2).
> It's not technically incorrect, but it looks like it adds noise.

It doesn't add noise :-)

It's arguably a code quality and `documentation' feature.  It provides a
human-readable, useful name to the "magic" value (maxproc * 2).  If we
decide to bump the default to (maxproc * 10) sometime later, we won't
have to grovel through the entire src/sys/tree and look for maxproc
instances that need updating.

From killing at multiplay.co.uk  Wed Dec 10 07:05:10 2008
From: killing at multiplay.co.uk (Steven Hartland)
Date: Wed Dec 10 07:05:17 2008
Subject: 7.0 unusual performance issue - vmdaemon hang?
Message-ID: <38D2AA3D46354E8EA3EE2A1056A1BE4A@multiplay.co.uk>

Just had one of hour webservers flag as down here and on
investigation the machine seems to be struggling due to
a hung vmdaemon process.

top is reporting vmdaemon as using a constant 55.57% CPU
yet CPU time is not increasing:-

last pid: 36492;  load averages:  0.04,  0.05,  .11       up 89+19:53:21  14:36:08
223 processes: 9 running, 201 sleeping, 13 waiting
CPU states:  0.0% user,  0.0% nice,  0.0% system,  0.0% interrupt,  100% idle
Mem: 644M Active, 2780M Inact, 480M Wired, 249M Cache, 214M Buf, 3759M Free
Swap: 4096M Total, 537M Used, 3559M Free, 13% Inuse

  PID USERNAME     THR PRI NICE   SIZE    RES STATE  C   TIME   WCPU COMMAND
   11 root           1 171 ki31     0K    16K CPU7   7 2116.4 100.00% idle: cpu7
   12 root           1 171 ki31     0K    16K CPU6   6 2059.5 100.00% idle: cpu6
   13 root           1 171 ki31     0K    16K CPU5   5 2029.3 100.00% idle: cpu5
   14 root           1 171 ki31     0K    16K CPU4   4 1977.8 100.00% idle: cpu4
   15 root           1 171 ki31     0K    16K CPU3   3 1912.0 100.00% idle: cpu3
   16 root           1 171 ki31     0K    16K CPU2   2 1835.2 100.00% idle: cpu2
   17 root           1 171 ki31     0K    16K CPU1   1 1763.1 100.00% idle: cpu1
   18 root           1 171 ki31     0K    16K RUN    0 1727.6 100.00% idle: cpu0
   37 root           1  20    -     0K    16K psleep 5   0:56 55.57% vmdaemon
60198 www            1   4    0    98M 13516K sbwait 2  35:21  1.46% httpd
60264 www            1   4    0   133M  9248K sbwait 0  21:21  0.39% httpd
   30 root           1 -68    -     0K    16K -      7  18.3H  0.00% em1 taskq
   29 root           1 -68    -     0K    16K -      6 330:21  0.00% em0 taskq
   41 root           1  20    -     0K    16K syncer 1 212:42  0.00% syncer
   21 root           1 -44    -     0K    16K WAIT   0 201:02  0.00% swi1: net
   19 root           1 -32    -     0K    16K WAIT   0 120:15  0.00% swi4: clock
   22 root           1  44    -     0K    16K -      5  73:00  0.00% yarrow

I've tried to ktrace the process and it produced nothing, also tried
gdb and it failed to attach. Is there anything else I can try before
we reboot the machine to help determine what the problem is?

    Regards
    Steve

================================================
This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. 

In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337
or return the E.mail to postmaster@multiplay.co.uk.

From kostikbel at gmail.com  Wed Dec 10 07:05:26 2008
From: kostikbel at gmail.com (Kostik Belousov)
Date: Wed Dec 10 07:05:32 2008
Subject: NFS (& amd?) dysfunction descending a hierarchy
In-Reply-To: <493EEF15.4050600@elischer.org>
References: <20081203001538.GC96383@bunrab.catwhisker.org>
	<20081209190110.GW60731@albert.catwhisker.org>
	<20081209200431.GL2038@deviant.kiev.zoral.com.ua>
	<493EEF15.4050600@elischer.org>
Message-ID: <20081210150516.GN2038@deviant.kiev.zoral.com.ua>

On Tue, Dec 09, 2008 at 02:20:05PM -0800, Julian Elischer wrote:
> Kostik Belousov wrote:
> >On Tue, Dec 09, 2008 at 11:01:10AM -0800, David Wolfskill wrote:
> >>On Tue, Dec 02, 2008 at 04:15:38PM -0800, David Wolfskill wrote:
> >>>I seem to have a fairly- (though not deterministly so) reproducible
> >>>mode of failure with an NFS-mounted directory hierarchy:  An attempt to
> >>>traverse a "sufficiently large" hierarchy (e.g., via "tar zcpf" or "rm
> >>>-fr") will fail to "visit" some subdirectories, typically apparently
> >>>acting as if the subdirectories in question do not actually exist
> >>>(despite the names having been returned in the output of a previous
> >>>readdir()).
> >>>... 
> >
> >Did you saw me previous answer ? Supposed patch for your problem was
> >committed to head as r185557, and MFCed to 7 in r185796, and to
> >7.1 in r185801.
> >
> >Please test with latest sources.
> 
> 
> did you notice that he tested with latest -current and releng 7?

Yes, and failure mode on the HEAD looks like a different issue.
-------------- 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-hackers/attachments/20081210/0f7de1b6/attachment.pgp
From ivoras at freebsd.org  Wed Dec 10 07:21:07 2008
From: ivoras at freebsd.org (Ivan Voras)
Date: Wed Dec 10 07:21:15 2008
Subject: MAXFILES in subr_param.c
In-Reply-To: <87bpvkdqex.fsf@kobe.laptop>
References: <ghjt9l$hg3$1@ger.gmane.org> <863agws2bv.fsf@ds4.des.no>
	<ghog9e$r4e$1@ger.gmane.org> <87bpvkdqex.fsf@kobe.laptop>
Message-ID: <9bbcef730812100720h5b3aab6ek46c4f36c67a37d58@mail.gmail.com>

2008/12/10 Giorgos Keramidas <keramida@ceid.upatras.gr>:
> On Wed, 10 Dec 2008 14:30:24 +0100, Ivan Voras <ivoras@freebsd.org> wrote:
>>>> Also, it looks like MAXFILES is used only once, and in a bit funny way:
>>>>
>>>> 238         maxfiles = MAXFILES;
>>>> 239         TUNABLE_INT_FETCH("kern.maxfiles", &maxfiles);
>>>> 240         maxprocperuid = (maxproc * 9) / 10;
>>>> 241         maxfilesperproc = (maxfiles * 9) / 10;
>>>
>>> What's funny about it?
>>
>> MAXFILES is a macro used only once, where it resolves to (maxproc*2).
>> It's not technically incorrect, but it looks like it adds noise.
>
> It doesn't add noise :-)
>
> It's arguably a code quality and `documentation' feature.  It provides a
> human-readable, useful name to the "magic" value (maxproc * 2).  If we
> decide to bump the default to (maxproc * 10) sometime later, we won't
> have to grovel through the entire src/sys/tree and look for maxproc
> instances that need updating.

The macro is defined and used exactly once, in this file. Other files
probably use maxfiles. The problem is - since it's in an #ifdef block
- is it defined anywhere else? A quick grep yields only this:

conf/NOTES:options 	MAXFILES=999
conf/options:MAXFILES	opt_param.h

I don't know how config interacts with the source - does it shadow the
subr_param.c value?

This isn't a very important question as the system demonstratively
works in any case, I see it more as a style curiosity.
From danny at cs.huji.ac.il  Wed Dec 10 07:28:55 2008
From: danny at cs.huji.ac.il (Danny Braniss)
Date: Wed Dec 10 07:29:09 2008
Subject: zfs panics 
Message-ID: <E1LAQze-0005kh-92@kabab.cs.huji.ac.il>

hi,
	from a solaris or linux client, doing a ls(1) of a nfs exported zfs file,
for example: ls /net/zfs-server/h/.zfs/snapshot,
panics the server. The server is running latest 7.1-prerelease.
	when client is freebsd, it mostly works, but in a few cases
the server just goes into comma.
btw, the server is running vanilla zfs, no tunning, and the server is 
64bit with 8gb of memory and quad core (dell-pe2950)

Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address   = 0x168
fault code              = supervisor write data, page not present
instruction pointer     = 0x8:0xffffffff804a9175
stack pointer           = 0x10:0xffffffffb71fc550
frame pointer           = 0x10:0xffffffffb71fc560
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         = 802 (nfsd)
[thread pid 802 tid 100185 ]
Stopped at      _mtx_lock_flags+0x15:   lock cmpxchgq   %rsi,0x50(%rdi)
db> tr
Tracing pid 802 tid 100185 td 0xffffff0004d576e0
_mtx_lock_flags() at _mtx_lock_flags+0x15
vput() at vput+0x45
nfsrv_readdirplus() at nfsrv_readdirplus+0x83e
nfssvc() at nfssvc+0x400
syscall() at syscall+0x1bb
Xfast_syscall() at Xfast_syscall+0xab
--- syscall (155, FreeBSD ELF64, nfssvc), rip = 0x8006885cc, rsp = 
0x7fffffffea2


From rea-fbsd at codelabs.ru  Wed Dec 10 07:44:46 2008
From: rea-fbsd at codelabs.ru (Eygene Ryabinkin)
Date: Wed Dec 10 07:44:53 2008
Subject: FreeBSD
In-Reply-To: <b2945a570812091817qd72e6cep72f62d70d1a385b7@mail.gmail.com>
References: <b2945a570812091817qd72e6cep72f62d70d1a385b7@mail.gmail.com>
Message-ID: <LqxJbk1poWz4RDaWI9N8yB5HLUU@Nv45r0f9gWT8HCu35qu0Xm2Zg98>

Wed, Dec 10, 2008 at 04:17:48AM +0200, ???? ?????? wrote:
> Hello dear command of developers of FreeBSD. I wish to take part in the
> project on developing out of FreeBSD and to subscribe for dispatch.

http://lists.freebsd.org/pipermail/freebsd-hackers/2008-November/026566.html
and especially http://www.freebsd.org/projects/index.html
http://wiki.freebsd.org/ will be good too.
-- 
Eygene
 _                ___       _.--.   #
 \`.|\..----...-'`   `-._.-'_.-'`   #  Remember that it is hard
 /  ' `         ,       __.--'      #  to read the on-line manual   
 )/' _/     \   `-_,   /            #  while single-stepping the kernel.
 `-'" `"\_  ,_.-;_.-\_ ',  fsc/as   #
     _.-'_./   {_.'   ; /           #    -- FreeBSD Developers handbook 
    {_.-``-'         {_/            #
-------------- 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-hackers/attachments/20081210/057b50ab/attachment.pgp
From jh at saunalahti.fi  Wed Dec 10 08:18:20 2008
From: jh at saunalahti.fi (Jaakko Heinonen)
Date: Wed Dec 10 08:18:33 2008
Subject: zfs panics
In-Reply-To: <E1LAQze-0005kh-92@kabab.cs.huji.ac.il>
References: <E1LAQze-0005kh-92@kabab.cs.huji.ac.il>
Message-ID: <20081210160059.GA3495@a91-153-125-115.elisa-laajakaista.fi>


Hi,

On 2008-12-10, Danny Braniss wrote:
> 	from a solaris or linux client, doing a ls(1) of a nfs exported zfs file,
> for example: ls /net/zfs-server/h/.zfs/snapshot,
> panics the server. The server is running latest 7.1-prerelease.

This has been reported as PR kern/125149. I have described the problem
in this message:

http://lists.freebsd.org/pipermail/freebsd-fs/2008-October/005217.html

See the PR for RELENG_7 patches.
(http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/125149)

-- 
Jaakko
From des at des.no  Wed Dec 10 08:21:24 2008
From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=)
Date: Wed Dec 10 08:21:31 2008
Subject: MAXFILES in subr_param.c
In-Reply-To: <9bbcef730812100720h5b3aab6ek46c4f36c67a37d58@mail.gmail.com>
	(Ivan Voras's message of "Wed, 10 Dec 2008 16:20:41 +0100")
References: <ghjt9l$hg3$1@ger.gmane.org> <863agws2bv.fsf@ds4.des.no>
	<ghog9e$r4e$1@ger.gmane.org> <87bpvkdqex.fsf@kobe.laptop>
	<9bbcef730812100720h5b3aab6ek46c4f36c67a37d58@mail.gmail.com>
Message-ID: <86iqpsknlp.fsf@ds4.des.no>

"Ivan Voras" <ivoras@freebsd.org> writes:
> The macro is defined and used exactly once, in this file. Other files
> probably use maxfiles.

maxfiles is the real value; it's a loader tunable, and more importantly,
it can be modified at run time through the kern.maxfiles sysctl
variable.  MAXFILES is simply the default value to which maxfiles is
initialized.

> The problem is - since it's in an #ifdef block
> - is it defined anywhere else? A quick grep yields only this:
>
> conf/NOTES:options 	MAXFILES=999
> conf/options:MAXFILES	opt_param.h
>
> I don't know how config interacts with the source - does it shadow the
> subr_param.c value?

Yes.  If you use the MAXFILES option in your kernel config, config(8)
will add a corresponding #define MAXFILES to opt_param.h.

I doubt anyone would complain (or even notice) if you removed it
entirely.

DES
-- 
Dag-Erling Sm?rgrav - des@des.no
From david at catwhisker.org  Wed Dec 10 08:50:23 2008
From: david at catwhisker.org (David Wolfskill)
Date: Wed Dec 10 08:50:29 2008
Subject: NFS (& amd?) dysfunction descending a hierarchy
In-Reply-To: <Pine.GSO.4.63.0812101124430.24743@muncher.cs.uoguelph.ca>
References: <20081203001538.GC96383@bunrab.catwhisker.org>
	<20081209190110.GW60731@albert.catwhisker.org>
	<Pine.GSO.4.63.0812101124430.24743@muncher.cs.uoguelph.ca>
Message-ID: <20081210165022.GJ60731@albert.catwhisker.org>

On Wed, Dec 10, 2008 at 11:30:26AM -0500, Rick Macklem wrote:
>... 
> The different behaviour for -CURRENT could be the newer RPC layer that
> was recently introduced, but that doesn't explain the basic problem.

OK.

> All I can think of is to ask the obvious question. "Are you using
> interruptible or soft mounts?" If so, switch to hard mounts and see
> if the problem goes away. (imho, neither interruptible nor soft mounts
> are a good idea. You can use a forced dismount if there is a crashed
> NFS server that isn't coming back anytime soon.)

From examination of /etc/amd* -- I don't see how to get mount(8) or
amq(8) to report it -- it appears that we are using interruptible
mounts, as we always have.

The point is that the behavior has changed in an unexpected way.  And
I'm not so sure that the use of a forced dismount is generally
available, as it would require logging in to the NFS client first, which
may be difficult if the NFS server hosting non-root home directories is
failing to respond and direct root login via ssh(1) is not permitted (as
is the default).

> If you are getting this with hard mounts, I'm afraid I have no idea
> what the problem is, rick.

What concerns me is that even if the attempted unmount gets EBUSY, the
user-level process descending the directory hierarchy is getting ENOENT
trying to issue fstatfs() against an open file descriptor.

I'm having trouble figuring out any way that makes any sense.

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: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20081210/88a384f2/attachment.pgp
From kostikbel at gmail.com  Wed Dec 10 09:06:27 2008
From: kostikbel at gmail.com (Kostik Belousov)
Date: Wed Dec 10 09:06:37 2008
Subject: NFS (& amd?) dysfunction descending a hierarchy
In-Reply-To: <20081210165022.GJ60731@albert.catwhisker.org>
References: <20081203001538.GC96383@bunrab.catwhisker.org>
	<20081209190110.GW60731@albert.catwhisker.org>
	<Pine.GSO.4.63.0812101124430.24743@muncher.cs.uoguelph.ca>
	<20081210165022.GJ60731@albert.catwhisker.org>
Message-ID: <20081210170620.GS2038@deviant.kiev.zoral.com.ua>

On Wed, Dec 10, 2008 at 08:50:22AM -0800, David Wolfskill wrote:
> On Wed, Dec 10, 2008 at 11:30:26AM -0500, Rick Macklem wrote:
> >... 
> > The different behaviour for -CURRENT could be the newer RPC layer that
> > was recently introduced, but that doesn't explain the basic problem.
> 
> OK.
> 
> > All I can think of is to ask the obvious question. "Are you using
> > interruptible or soft mounts?" If so, switch to hard mounts and see
> > if the problem goes away. (imho, neither interruptible nor soft mounts
> > are a good idea. You can use a forced dismount if there is a crashed
> > NFS server that isn't coming back anytime soon.)
> 
> From examination of /etc/amd* -- I don't see how to get mount(8) or
> amq(8) to report it -- it appears that we are using interruptible
> mounts, as we always have.
> 
> The point is that the behavior has changed in an unexpected way.  And
> I'm not so sure that the use of a forced dismount is generally
> available, as it would require logging in to the NFS client first, which
> may be difficult if the NFS server hosting non-root home directories is
> failing to respond and direct root login via ssh(1) is not permitted (as
> is the default).
> 
> > If you are getting this with hard mounts, I'm afraid I have no idea
> > what the problem is, rick.
> 
> What concerns me is that even if the attempted unmount gets EBUSY, the
> user-level process descending the directory hierarchy is getting ENOENT
> trying to issue fstatfs() against an open file descriptor.
> 
> I'm having trouble figuring out any way that makes any sense.

Basically, the problem is that NFS uses shared lookup, and this allows
for the bug where several negative namecache entries are created for
non-existent node. Then this node gets created, removing only the first
negative namecache entry. For some reasons, vnode is reclaimed; amd'
tasting of unmount is a good reason for vnode to be reclaimed.

Now, you have existing path and a negative cache entry. This was
reported by Peter Holm first, I listed relevant revisions that
should fix this in previous mail.
-------------- 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-hackers/attachments/20081210/f50acb49/attachment.pgp
From julian at elischer.org  Wed Dec 10 09:43:55 2008
From: julian at elischer.org (Julian Elischer)
Date: Wed Dec 10 09:44:02 2008
Subject: FreeBSD  (russian)
In-Reply-To: <LqxJbk1poWz4RDaWI9N8yB5HLUU@Nv45r0f9gWT8HCu35qu0Xm2Zg98>
References: <b2945a570812091817qd72e6cep72f62d70d1a385b7@mail.gmail.com>
	<LqxJbk1poWz4RDaWI9N8yB5HLUU@Nv45r0f9gWT8HCu35qu0Xm2Zg98>
Message-ID: <493FF924.7010100@elischer.org>

Eygene Ryabinkin wrote:
> Wed, Dec 10, 2008 at 04:17:48AM +0200, ???? ?????? wrote:
>> Hello dear command of developers of FreeBSD. I wish to take part in the
>> project on developing out of FreeBSD and to subscribe for dispatch.
> 
> http://lists.freebsd.org/pipermail/freebsd-hackers/2008-November/026566.html
> and especially http://www.freebsd.org/projects/index.html
> http://wiki.freebsd.org/ will be good too.


can we have a russian speaking developer contact him too?

From pluknet at gmail.com  Wed Dec 10 10:32:21 2008
From: pluknet at gmail.com (pluknet)
Date: Wed Dec 10 10:32:27 2008
Subject: FreeBSD (russian)
In-Reply-To: <493FF924.7010100@elischer.org>
References: <b2945a570812091817qd72e6cep72f62d70d1a385b7@mail.gmail.com>
	<LqxJbk1poWz4RDaWI9N8yB5HLUU@Nv45r0f9gWT8HCu35qu0Xm2Zg98>
	<493FF924.7010100@elischer.org>
Message-ID: <a31046fc0812101032n145610e5ta330905cba5d92ff@mail.gmail.com>

2008/12/10 Julian Elischer <julian@elischer.org>:
> Eygene Ryabinkin wrote:
>>
>> Wed, Dec 10, 2008 at 04:17:48AM +0200, ???? ?????? wrote:
>>>
>>> Hello dear command of developers of FreeBSD. I wish to take part in the
>>> project on developing out of FreeBSD and to subscribe for dispatch.
>>
>>
>> http://lists.freebsd.org/pipermail/freebsd-hackers/2008-November/026566.html
>> and especially http://www.freebsd.org/projects/index.html
>> http://wiki.freebsd.org/ will be good too.
>
>
> can we have a russian speaking developer contact him too?

it's her :)

-- 
wbr,
pluknet
From jhb at freebsd.org  Wed Dec 10 10:53:26 2008
From: jhb at freebsd.org (John Baldwin)
Date: Wed Dec 10 10:54:03 2008
Subject: Enhancing cdboot [patch for review]
In-Reply-To: <20081208235119.GA46608@onelab2.iet.unipi.it>
References: <493DA269.2070805@FreeBSD.org>
	<20081208235119.GA46608@onelab2.iet.unipi.it>
Message-ID: <200812101331.24182.jhb@freebsd.org>

On Monday 08 December 2008 06:51:19 pm Luigi Rizzo wrote:
> On Mon, Dec 08, 2008 at 02:40:41PM -0800, Maxim Sobolev wrote:
> > Hi,
> > 
> > Below please find patch that enhances cdboot with two compile-time 
options:
> ...
> > Any comments/suggestions are appreciated. If there are no objections I
> > would like to commit the change. The long-term goal is to make
> > CDBOOT_PROMPT default mode for installation CD.
> > 
> > http://sobomax.sippysoft.com/~sobomax/cdboot.diff
> 
> Looks good. Some comments:
> 1. since there is plenty of space in the cdboot sector, why don't you
>    make the two option always compiled in, controlling which one to
>    activate through flags in the bootsector itself, to be set
>    patching the binary sector itself using a mechanism similar to
>    boot0cfg.
>       Of course you cannot alter a cdrom after you burn it,
>    but it makes it easier to build CDs with one or the other defaults,
>    patching cdboot or the iso image itself before creating/burning it.

I don't think this is very useful because CDs are read-only.  You can just as 
easily build a different cdboot rather than having to write some custom 
cdbootcfg util to patch the binary.

> 2. in fact, the 'silent' option could be disabled at runtime by
>    pressing some key (e.g. adding a short wait loop before proceeding;
>    if this is meant for custom, unattended CDs the extra delay should not
>    matter much);

I don't imagine anyone will know to press a key to get verbose messages, and 
the CD boot process is quick enough you would have to add an artificial delay 
to it to allow for the keypress.

> 3. one nitpick -- in one of the first chunks you replace $start
>    with $LOAD, but if i am not mistaken operation depends on $LOAD = $start,
>    so why don't you always use the same ?

No, because he relocates it, $start is now the relocated address, but the BIOS 
loads it at LOAD which is now != $start.

>      Also in terms of relocation size, wouldn't it be the case of
>    hardwiring the size of the cd boot sector:
> 
> -       mov $((end_init - start)/2),%cx
> +       mov 1024,%cx

I prefer the existing code to make sure and copy the full boot loader, 
whatever it's size is.

Maxim,

My only comment is to please make the new block comment match the style of the 
existing block comments by having '#\n' lines before and after.

-- 
John Baldwin
From julian at elischer.org  Wed Dec 10 12:06:41 2008
From: julian at elischer.org (Julian Elischer)
Date: Wed Dec 10 12:06:48 2008
Subject: FreeBSD (russian)
In-Reply-To: <a31046fc0812101032n145610e5ta330905cba5d92ff@mail.gmail.com>
References: <b2945a570812091817qd72e6cep72f62d70d1a385b7@mail.gmail.com>	
	<LqxJbk1poWz4RDaWI9N8yB5HLUU@Nv45r0f9gWT8HCu35qu0Xm2Zg98>	
	<493FF924.7010100@elischer.org>
	<a31046fc0812101032n145610e5ta330905cba5d92ff@mail.gmail.com>
Message-ID: <4940214F.8040103@elischer.org>

pluknet wrote:
> 2008/12/10 Julian Elischer <julian@elischer.org>:
>> Eygene Ryabinkin wrote:
>>> Wed, Dec 10, 2008 at 04:17:48AM +0200, ???? ?????? wrote:
>>>> Hello dear command of developers of FreeBSD. I wish to take part in the
>>>> project on developing out of FreeBSD and to subscribe for dispatch.
>>>
>>> http://lists.freebsd.org/pipermail/freebsd-hackers/2008-November/026566.html
>>> and especially http://www.freebsd.org/projects/index.html
>>> http://wiki.freebsd.org/ will be good too.
>>
>> can we have a russian speaking developer contact him too?
> 
> it's her :)
> 


yeah you are the 3rd person to tell me it's "Julia"..
I should know  better :-)

(and I see more emails ahead in my list that will probably tell me 
too. :-)


From rmacklem at uoguelph.ca  Wed Dec 10 08:47:02 2008
From: rmacklem at uoguelph.ca (Rick Macklem)
Date: Wed Dec 10 13:26:32 2008
Subject: NFS (& amd?) dysfunction descending a hierarchy
In-Reply-To: <20081209190110.GW60731@albert.catwhisker.org>
References: <20081203001538.GC96383@bunrab.catwhisker.org>
	<20081209190110.GW60731@albert.catwhisker.org>
Message-ID: <Pine.GSO.4.63.0812101124430.24743@muncher.cs.uoguelph.ca>



On Tue, 9 Dec 2008, David Wolfskill wrote:

> On Tue, Dec 02, 2008 at 04:15:38PM -0800, David Wolfskill wrote:
>> I seem to have a fairly- (though not deterministly so) reproducible
>> mode of failure with an NFS-mounted directory hierarchy:  An attempt to
>> traverse a "sufficiently large" hierarchy (e.g., via "tar zcpf" or "rm
>> -fr") will fail to "visit" some subdirectories, typically apparently
>> acting as if the subdirectories in question do not actually exist
>> (despite the names having been returned in the output of a previous
>> readdir()).
>> ...
>
> I was able to reproduce the external symptoms of the failure running
> CURRENT as of yesterday, using "rm -fr" of a copy of a recent
> /usr/ports hierachy on an NFS-mounted file system as a test case.
> However, I believe the mechanism may be a bit different -- while
> still being other than what I would expect.
>
> One aspect in which the externally-observable symptoms were different
> (under CURRENT, vs. RELENG_7) is that under CURRENT, once the error
> condition occurred, the NFS client machine was in a state where it
> merely kept repeating
>
> 	nfs server pid848@fbsd-build:/volume: not responding
>
> until I logged in as root & rebooted it.
>
The different behaviour for -CURRENT could be the newer RPC layer that
was recently introduced, but that doesn't explain the basic problem.

All I can think of is to ask the obvious question. "Are you using
interruptible or soft mounts?" If so, switch to hard mounts and see
if the problem goes away. (imho, neither interruptible nor soft mounts
are a good idea. You can use a forced dismount if there is a crashed
NFS server that isn't coming back anytime soon.)

If you are getting this with hard mounts, I'm afraid I have no idea
what the problem is, rick.

From patfbsd at davenulle.org  Wed Dec 10 14:34:46 2008
From: patfbsd at davenulle.org (Patrick =?ISO-8859-15?Q?Lamaizi=E8re?=)
Date: Wed Dec 10 14:34:54 2008
Subject: crypto(9) choose another driver if we cannot open a session on
 it
In-Reply-To: <20081208202155.GA7403@detritus.paeps.cx>
References: <20081207224551.13ca3590@baby-jane>
	<20081208202155.GA7403@detritus.paeps.cx>
Message-ID: <20081210233440.41bd1c47@baby-jane>

Le Mon, 8 Dec 2008 21:21:55 +0100,
Philip Paeps <philip@freebsd.org> a ?crit :

Hello,

> On 2008-12-07 22:45:51 (+0100), Patrick Lamaizi?re
> <patfbsd@davenulle.org> wrote:
> > I wrote a small patch to allow the crypto framework to choose
> > another cryptographic driver if we cannot open a session on the
> > driver.
> 
> Very cool. :-)  I've been hacking on this too, mainly to get rid of
> the code duplication that currently exists.

Which code exactly? Yes I'm curious :-)

I'm thinking about how to remove the need for a device to support all
the algorithms when we open a session. By using a fake "crypto
virtual device" to open and dispatch crypto requests to real devices or
to cryptosoft. But i don't have any code to show yet.

There is one thing I'm asking about crypto(9):
- I doubt that the migration of a session is safe and I think that
would be far easier to prevent a driver to unregister when there are
some pending sessions on it? glxsb and padlock do not allow to
unregister in this case. 

I've looked quickly the code of geli or ipsec. If the crypto
framework returns EAGAIN because the migration of the session, they
restart a crypto_dispatch(crp) but the datas in crp->crp_buf can be
corrupted by the previous crypto operation (IMHO, may be i've missed
something)?

Thanks, regards.
From sam at freebsd.org  Wed Dec 10 14:50:56 2008
From: sam at freebsd.org (Sam Leffler)
Date: Wed Dec 10 14:51:03 2008
Subject: crypto(9) choose another driver if we cannot open a session on
 it
In-Reply-To: <20081210233440.41bd1c47@baby-jane>
References: <20081207224551.13ca3590@baby-jane>	<20081208202155.GA7403@detritus.paeps.cx>
	<20081210233440.41bd1c47@baby-jane>
Message-ID: <494047CB.6050400@freebsd.org>

Patrick Lamaizi?re wrote:
> Le Mon, 8 Dec 2008 21:21:55 +0100,
> Philip Paeps <philip@freebsd.org> a ?crit :
>
> Hello,
>
>   
>> On 2008-12-07 22:45:51 (+0100), Patrick Lamaizi?re
>> <patfbsd@davenulle.org> wrote:
>>     
>>> I wrote a small patch to allow the crypto framework to choose
>>> another cryptographic driver if we cannot open a session on the
>>> driver.
>>>       
>> Very cool. :-)  I've been hacking on this too, mainly to get rid of
>> the code duplication that currently exists.
>>     
>
> Which code exactly? Yes I'm curious :-)
>
> I'm thinking about how to remove the need for a device to support all
> the algorithms when we open a session. By using a fake "crypto
> virtual device" to open and dispatch crypto requests to real devices or
> to cryptosoft. But i don't have any code to show yet.
>
> There is one thing I'm asking about crypto(9):
> - I doubt that the migration of a session is safe and I think that
> would be far easier to prevent a driver to unregister when there are
> some pending sessions on it? glxsb and padlock do not allow to
> unregister in this case. 
>
> I've looked quickly the code of geli or ipsec. If the crypto
> framework returns EAGAIN because the migration of the session, they
> restart a crypto_dispatch(crp) but the datas in crp->crp_buf can be
> corrupted by the previous crypto operation (IMHO, may be i've missed
> something)?
>   
This sounds like the session management layer I wanted to insert a while 
back.  It was a reason why I made the s/w driver into a pseudo device 
(so there'd be a handle).  I want to look at your mods but haven't had time.

As to unregister that was designed for devices like cardbus cards that 
might go away.  About the only way to simulate it today is to unload a 
driver module.  But it should work; if you see an issue we should try to 
fix it.  OTOH the limitations of the existing crypto code are dramatic 
and the rationale for maintaining the obsd api's (both in kernel and 
user space) are no longer valid.  It would be good to see someone take 
this stuff and overhaul it to do things like:

o add a session management layer that falls back to s/w when a device
   is incapable and when operations are more efficiently done in s/w (e.g
   ops too small to incur the dma setup/overhead)
o do load balancing over multiple devices
o support cpu resources as pseudo drivers (e.g. pin a thread to a cpu)
o replace the bogus fd session crud w/ device cloning

The linux folks have done some of this and there may be lessons to be 
learned from their efforts.  FWIW netbsd has some recent user api 
changes for doing async ops and batching to speedup openssl etc; if 
you're going to get into this stuff you might take a look.

    Sam

From sheldon at sigsegv.ca  Wed Dec 10 18:00:27 2008
From: sheldon at sigsegv.ca (Sheldon Givens)
Date: Wed Dec 10 18:00:35 2008
Subject: Small Change to chpass.c
Message-ID: <f4ecc0930812101800g601d9f10jc008e83d82b54a81@mail.gmail.com>

Hi guys,

When I was doing some user management today I noticed that chpass, and all
the utilities that use chpass.c, only give one attempt to authenticate to
make the change. After I messed this up once or twice (and after doing 4-5
minutes of editing only to have it lost when I typo'd the password) I wrote
this little change in to chpass.c.

When it needs the users password, it will enter into a for loop, increasing
itr until it hits max_retries (defined at top of main() declaration). If one
of these tries is successful (password given matches) then auth is set to
'1' and we break from the loop, and update info. If, after three tries, auth
is still '0' (the user didn't supply the proper password) we call baduser()
to handle it.

It's a pretty inconsequential change but it managed to relieve me of quite a
bit of stress :-)

Happy Holidays, everyone!

Sheldon Givens



---snip---
--- /usr/src/usr.bin/chpass.c   2008-12-11 01:55:27.000000000 -0800
+++ /usr/src/usr.bin/chpass.c   2008-12-11 01:57:09.000000000 -0800
@@ -80,10 +80,11 @@
 {
        enum { NEWSH, LOADENTRY, EDITENTRY, NEWPW, NEWEXP } op;
        struct passwd lpw, *old_pw, *pw;
-       int ch, pfd, tfd;
+       int ch, pfd, tfd, itr, auth;
        const char *password;
        char *arg = NULL;
        uid_t uid;
+       int max_retries = 3;
 #ifdef YP
        struct ypclnt *ypclnt;
        const char *yp_domain = NULL, *yp_host = NULL;
@@ -227,9 +228,16 @@
        }

        if (old_pw && !master_mode) {
-               password = getpass("Password: ");
-               if (strcmp(crypt(password, old_pw->pw_passwd),
-                   old_pw->pw_passwd) != 0)
+               auth = 0;
+               for(itr=0;itr<max_retries;itr++) {
+                       password = getpass("Password:");
+                       if(strcmp(crypt(password, old_pw->pw_passwd),
+                       old_pw->pw_passwd) == 0) {
+                               auth=1;
+                               break;
+                       }
+               }
+               if (!auth)
                        baduser();
        } else {
                password = "";
---snip---
From won.derick at yahoo.com  Wed Dec 10 20:52:50 2008
From: won.derick at yahoo.com (Won De Erick)
Date: Wed Dec 10 20:52:56 2008
Subject: Watchdog for Boser (HS-7001)
References: <547602.79284.qm@web45809.mail.sp1.yahoo.com>
	<4933A29B.8060907@gmx.de> <20081201090421.GA99082@rink.nu>
	<611173.7111.qm@web45805.mail.sp1.yahoo.com>
	<4933AFD4.3070501@gmx.de>
Message-ID: <832968.75350.qm@web45816.mail.sp1.yahoo.com>

Christoph Mallon wrote:

>
>
Won De Erick schrieb:
>>> ----- Original Message ----
>> 
>>> From: Rink Springer <rink@FreeBSD.org>
>>> 
>>> 
>> On Mon, Dec 01, 2008 at 09:38:51AM +0100, Christoph Mallon wrote:
>>>> Userland is not allowed to write to ports. That's the bus error you see. Also without a call to the exit syscall at the end, it will segfault.
>>> Note that you can write to ports from userland by opening /dev/io - if
>>> you have it opened, you can write to the ports.
>>> 
>> 
>> I've added the following at the end
>> 
>>   mov eax, 1 ; SYS_exit
>>   call doint
>> 
>>   doint:
>>      int 0x80
>>      ret
>> 
>> Besides, I can see the following at /dev
>> crw-------   1 root   wheel       0,  16 Nov 27 01:53 io
>> 
>> How should I make this open? do i need to %include this?
>
> You're probably better of writing this in C. Here is a wrapper for the out instruction:
>
> static inline outb(unsigned short port, unsigned char data)
> {
>  asm("outb %0, %1" : : "a" (data), "dN" (port));
> }
>
> As Rink mentioned, you have to open /dev/io. The process must have super-user privileges, see io(4).
>
>

OK thanks for all the tips. I have now a working watchdog. :)


      

From keramida at ceid.upatras.gr  Wed Dec 10 22:32:34 2008
From: keramida at ceid.upatras.gr (Giorgos Keramidas)
Date: Wed Dec 10 22:32:42 2008
Subject: Small Change to chpass.c
In-Reply-To: <f4ecc0930812101800g601d9f10jc008e83d82b54a81@mail.gmail.com>
	(Sheldon Givens's message of "Wed, 10 Dec 2008 18:00:25 -0800")
References: <f4ecc0930812101800g601d9f10jc008e83d82b54a81@mail.gmail.com>
Message-ID: <87vdtr9q8a.fsf@kobe.laptop>

On Wed, 10 Dec 2008 18:00:25 -0800, "Sheldon Givens" <sheldon@sigsegv.ca> wrote:
> Hi guys,
>
> When I was doing some user management today I noticed that chpass, and
> all the utilities that use chpass.c, only give one attempt to
> authenticate to make the change. After I messed this up once or twice
> (and after doing 4-5 minutes of editing only to have it lost when I
> typo'd the password) I wrote this little change in to chpass.c.

This seems useful, thanks for submitting the patch :)

> ---snip---
> --- /usr/src/usr.bin/chpass.c   2008-12-11 01:55:27.000000000 -0800
> +++ /usr/src/usr.bin/chpass.c   2008-12-11 01:57:09.000000000 -0800
> @@ -80,10 +80,11 @@
>  {
>         enum { NEWSH, LOADENTRY, EDITENTRY, NEWPW, NEWEXP } op;
>         struct passwd lpw, *old_pw, *pw;
> -       int ch, pfd, tfd;
> +       int ch, pfd, tfd, itr, auth;
>         const char *password;
>         char *arg = NULL;
>         uid_t uid;
> +       int max_retries = 3;
>  #ifdef YP
>         struct ypclnt *ypclnt;
>         const char *yp_domain = NULL, *yp_host = NULL;
> @@ -227,9 +228,16 @@
>         }
>
>         if (old_pw && !master_mode) {
> -               password = getpass("Password: ");
> -               if (strcmp(crypt(password, old_pw->pw_passwd),
> -                   old_pw->pw_passwd) != 0)
> +               auth = 0;
> +               for(itr=0;itr<max_retries;itr++) {
> +                       password = getpass("Password:");
> +                       if(strcmp(crypt(password, old_pw->pw_passwd),
> +                       old_pw->pw_passwd) == 0) {
> +                               auth=1;
> +                               break;
> +                       }
> +               }
> +               if (!auth)
>                         baduser();
>         } else {
>                 password = "";
> ---snip---

You can probably do away with `auth' and reset password to NULL when
strcmp() fails (note that we also use whitespace in for statements to
separate everything more clearly):

        if (old_pw && !master_mode) {
                for (itr = 0; itr < max_retries; itr++) {
                        password = getpass("Password:");
                        if (strcmp(crypt(password, old_pw->pw_passwd),
                            old_pw->pw_passwd) != 0)
                                break;
                        password = NULL;
                }
                if (password == NULL)
                        baduser();
        } else {
                password = "";

From jonathan+freebsd-hackers at hst.org.za  Wed Dec 10 22:53:28 2008
From: jonathan+freebsd-hackers at hst.org.za (Jonathan McKeown)
Date: Wed Dec 10 22:53:43 2008
Subject: Enhancing cdboot [patch for review]
In-Reply-To: <200812101331.24182.jhb@freebsd.org>
References: <493DA269.2070805@FreeBSD.org>
	<20081208235119.GA46608@onelab2.iet.unipi.it>
	<200812101331.24182.jhb@freebsd.org>
Message-ID: <200812110837.26316.jonathan+freebsd-hackers@hst.org.za>

While you're enhancing cdboot anyway, can I ask how complicated it would be to 
make cdboot serial-console capable? (I'm not a C programmer, I'm a sysadmin - 
but I'd be prepared to try and look at this myself if no-one else is 
interested).

As it stands, the only way I've found to do a serial-console CD-based 
installation is by enabling the serial console in /boot/loader.conf, by which 
time you've already missed several useful points, particularly the entry to 
BIOS settings (if you have a serial-capable BIOS).

Jonathan
From Trond.Endrestol at fagskolen.gjovik.no  Wed Dec 10 23:11:31 2008
From: Trond.Endrestol at fagskolen.gjovik.no (=?ISO-8859-1?Q?Trond_Endrest=F8l?=)
Date: Wed Dec 10 23:11:38 2008
Subject: Small Change to chpass.c
In-Reply-To: <87vdtr9q8a.fsf@kobe.laptop>
References: <f4ecc0930812101800g601d9f10jc008e83d82b54a81@mail.gmail.com>
	<87vdtr9q8a.fsf@kobe.laptop>
Message-ID: <20081211080955.T60586@ramstind.fig.ol.no>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, 11 Dec 2008 08:32+0200, Giorgos Keramidas wrote:

> On Wed, 10 Dec 2008 18:00:25 -0800, "Sheldon Givens" <sheldon@sigsegv.ca> wrote:

> > --- /usr/src/usr.bin/chpass.c   2008-12-11 01:55:27.000000000 -0800
> > +++ /usr/src/usr.bin/chpass.c   2008-12-11 01:57:09.000000000 -0800
> > @@ -80,10 +80,11 @@
> >  {
> >         enum { NEWSH, LOADENTRY, EDITENTRY, NEWPW, NEWEXP } op;
> >         struct passwd lpw, *old_pw, *pw;
> > -       int ch, pfd, tfd;
> > +       int ch, pfd, tfd, itr, auth;
> >         const char *password;
> >         char *arg = NULL;
> >         uid_t uid;
> > +       int max_retries = 3;
> >  #ifdef YP
> >         struct ypclnt *ypclnt;
> >         const char *yp_domain = NULL, *yp_host = NULL;
> > @@ -227,9 +228,16 @@
> >         }
> >
> >         if (old_pw && !master_mode) {
> > -               password = getpass("Password: ");

I'm sure you have noticed the trailing space in the string.

> > -               if (strcmp(crypt(password, old_pw->pw_passwd),
> > -                   old_pw->pw_passwd) != 0)
> > +               auth = 0;
> > +               for(itr=0;itr<max_retries;itr++) {
> > +                       password = getpass("Password:");

The space's missing in this string. It might be better to stay
consistent with the original code.

> > +                       if(strcmp(crypt(password, old_pw->pw_passwd),
> > +                       old_pw->pw_passwd) == 0) {
> > +                               auth=1;
> > +                               break;
> > +                       }
> > +               }
> > +               if (!auth)
> >                         baduser();
> >         } else {
> >                 password = "";

- -- 
- ----------------------------------------------------------------------
Trond Endrest?l                  | Trond.Endrestol@fagskolen.gjovik.no
ACM, NAS, NUUG, SAGE, USENIX     |      FreeBSD 6.2-STABLE & Pine 4.64

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (FreeBSD)

iD8DBQFJQL0dbYWZalUoElsRAolhAJoC4iTyrVY3xeoChg3iWRsDLpvonwCeP0yT
1kM28vaxZtNH9LGqyZzZCTA=
=0+CT
-----END PGP SIGNATURE-----
From keramida at ceid.upatras.gr  Thu Dec 11 00:45:59 2008
From: keramida at ceid.upatras.gr (Giorgos Keramidas)
Date: Thu Dec 11 00:46:06 2008
Subject: Enhancing cdboot [patch for review]
In-Reply-To: <200812110837.26316.jonathan+freebsd-hackers@hst.org.za>
	(Jonathan McKeown's message of "Thu, 11 Dec 2008 08:37:26 +0200")
References: <493DA269.2070805@FreeBSD.org>
	<20081208235119.GA46608@onelab2.iet.unipi.it>
	<200812101331.24182.jhb@freebsd.org>
	<200812110837.26316.jonathan+freebsd-hackers@hst.org.za>
Message-ID: <87prjzw156.fsf@kobe.laptop>

On Thu, 11 Dec 2008 08:37:26 +0200, Jonathan McKeown <jonathan+freebsd-hackers@hst.org.za> wrote:
> While you're enhancing cdboot anyway, can I ask how complicated it
> would be to make cdboot serial-console capable? (I'm not a C
> programmer, I'm a sysadmin - but I'd be prepared to try and look at
> this myself if no-one else is interested).
>
> As it stands, the only way I've found to do a serial-console CD-based
> installation is by enabling the serial console in /boot/loader.conf,
> by which time you've already missed several useful points,
> particularly the entry to BIOS settings (if you have a serial-capable
> BIOS).

cdboot runs long after the prompt for BIOS setup.  I don't think we can
modify cdboot to add serial console support to systems whose BIOS setup
doesn't support it.

From danny at cs.huji.ac.il  Thu Dec 11 01:08:56 2008
From: danny at cs.huji.ac.il (Danny Braniss)
Date: Thu Dec 11 01:09:04 2008
Subject: zfs panics 
In-Reply-To: <20081210160059.GA3495@a91-153-125-115.elisa-laajakaista.fi> 
References: <E1LAQze-0005kh-92@kabab.cs.huji.ac.il> 
	<20081210160059.GA3495@a91-153-125-115.elisa-laajakaista.fi>
Message-ID: <E1LAhXS-000GQW-BW@kabab.cs.huji.ac.il>

> 
> Hi,
> 
> On 2008-12-10, Danny Braniss wrote:
> > 	from a solaris or linux client, doing a ls(1) of a nfs exported zfs file,
> > for example: ls /net/zfs-server/h/.zfs/snapshot,
> > panics the server. The server is running latest 7.1-prerelease.
> 
> This has been reported as PR kern/125149. I have described the problem
> in this message:
> 
> http://lists.freebsd.org/pipermail/freebsd-fs/2008-October/005217.html
> 
> See the PR for RELENG_7 patches.
> (http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/125149)
> 
> -- 
> Jaakko

Hi Jaakko,
	did you apply the patches and it solved the problem?
and, btw, which patch?

To Jeremy,
	How about adding a line explaining that it would be
prudent to 'zfs set snapdir=hidden' ..., or, of cource
fix the bug :-)
I will apply the patch/es and see what happens.

cheers,
	danny


From vasanth.raonaik at gmail.com  Thu Dec 11 01:43:25 2008
From: vasanth.raonaik at gmail.com (vasanth raonaik)
Date: Thu Dec 11 01:43:32 2008
Subject: NTP: leap second adjustments.
Message-ID: <d9f479c10812110115k297e398udfea3ead1811b480@mail.gmail.com>

Hello Hackers,

I am working on ntpd 4.2.0-a.  I need to test whether this version of ntpd
is capable of handling leap second adjustments. Could any one please let me
know any details of how i can simulate the leap count adjustments. I need to
verify if the system does not crash with leap second and works fine.

Thanks,
Vasanth
From danny at cs.huji.ac.il  Thu Dec 11 02:28:34 2008
From: danny at cs.huji.ac.il (Danny Braniss)
Date: Thu Dec 11 02:28:46 2008
Subject: zfs panics 
In-Reply-To: <E1LAhXS-000GQW-BW@kabab.cs.huji.ac.il> 
References: <E1LAQze-0005kh-92@kabab.cs.huji.ac.il> 
	<20081210160059.GA3495@a91-153-125-115.elisa-laajakaista.fi> 
	<E1LAhXS-000GQW-BW@kabab.cs.huji.ac.il>
Message-ID: <E1LAimW-000HTT-JN@kabab.cs.huji.ac.il>

> > 
> > Hi,
> > 
> > On 2008-12-10, Danny Braniss wrote:
> > > 	from a solaris or linux client, doing a ls(1) of a nfs exported zfs file,
> > > for example: ls /net/zfs-server/h/.zfs/snapshot,
> > > panics the server. The server is running latest 7.1-prerelease.
> > 
> > This has been reported as PR kern/125149. I have described the problem
> > in this message:
> > 
> > http://lists.freebsd.org/pipermail/freebsd-fs/2008-October/005217.html
> > 
> > See the PR for RELENG_7 patches.
> > (http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/125149)
> > 
> > -- 
> > Jaakko
> 
> Hi Jaakko,
> 	did you apply the patches and it solved the problem?
> and, btw, which patch?
> 
> To Jeremy,
> 	How about adding a line explaining that it would be
> prudent to 'zfs set snapdir=hidden' ..., or, of cource
> fix the bug :-)
> I will apply the patch/es and see what happens.
> 
> cheers,
> 	danny

the patch to nfs_server.c does indeed prevent the panics.

danny



From rodrigo at bebik.net  Thu Dec 11 02:38:40 2008
From: rodrigo at bebik.net (Rodrigo OSORIO (ros))
Date: Thu Dec 11 02:38:48 2008
Subject: Small Change to chpass.c
In-Reply-To: <f4ecc0930812101800g601d9f10jc008e83d82b54a81@mail.gmail.com>
References: <f4ecc0930812101800g601d9f10jc008e83d82b54a81@mail.gmail.com>
Message-ID: <20081211100718.GA15362@hodja.bebik.net>

On 10/12/08 18:00 -0800, Sheldon Givens wrote:
> Hi guys,
> 
> When I was doing some user management today I noticed that chpass, and all
> the utilities that use chpass.c, only give one attempt to authenticate to
> make the change. After I messed this up once or twice (and after doing 4-5
> minutes of editing only to have it lost when I typo'd the password) I wrote
> this little change in to chpass.c.
> 
> When it needs the users password, it will enter into a for loop, increasing
> itr until it hits max_retries (defined at top of main() declaration). If one
> of these tries is successful (password given matches) then auth is set to
> '1' and we break from the loop, and update info. If, after three tries, auth
> is still '0' (the user didn't supply the proper password) we call baduser()
> to handle it.
> 
> It's a pretty inconsequential change but it managed to relieve me of quite a
> bit of stress :-)
> 
> Happy Holidays, everyone!
> 
> Sheldon Givens
> 
> 
> 
> ---snip---
> --- /usr/src/usr.bin/chpass.c   2008-12-11 01:55:27.000000000 -0800
> +++ /usr/src/usr.bin/chpass.c   2008-12-11 01:57:09.000000000 -0800
> @@ -80,10 +80,11 @@
>  {
>         enum { NEWSH, LOADENTRY, EDITENTRY, NEWPW, NEWEXP } op;
>         struct passwd lpw, *old_pw, *pw;
> -       int ch, pfd, tfd;
> +       int ch, pfd, tfd, itr, auth;
>         const char *password;
>         char *arg = NULL;
>         uid_t uid;
> +       int max_retries = 3;
>  #ifdef YP
>         struct ypclnt *ypclnt;
>         const char *yp_domain = NULL, *yp_host = NULL;
> @@ -227,9 +228,16 @@
>         }
> 
>         if (old_pw && !master_mode) {
> -               password = getpass("Password: ");
> -               if (strcmp(crypt(password, old_pw->pw_passwd),
> -                   old_pw->pw_passwd) != 0)
> +               auth = 0;
> +               for(itr=0;itr<max_retries;itr++) {
> +                       password = getpass("Password:");
> +                       if(strcmp(crypt(password, old_pw->pw_passwd),
> +                       old_pw->pw_passwd) == 0) {
> +                               auth=1;
> +                               break;
> +                       }
> +               }
> +               if (!auth)
>                         baduser();
>         } else {
>                 password = "";
> ---snip---
> _______________________________________________
> freebsd-hackers@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"

Hi,
Sure, your patch solves some admins nightmares :)
Bus it impacts the scripts or applications using chpass interactively, no?

- Rodrigo


From jonathan at hst.org.za  Thu Dec 11 00:52:31 2008
From: jonathan at hst.org.za (Jonathan McKeown)
Date: Thu Dec 11 04:39:36 2008
Subject: Enhancing cdboot [patch for review]
In-Reply-To: <87prjzw156.fsf@kobe.laptop>
References: <493DA269.2070805@FreeBSD.org>
	<200812110837.26316.jonathan+freebsd-hackers@hst.org.za>
	<87prjzw156.fsf@kobe.laptop>
Message-ID: <200812111052.50082.jonathan@hst.org.za>

On Thursday 11 December 2008 10:45:41 Giorgos Keramidas wrote:
> On Thu, 11 Dec 2008 08:37:26 +0200, Jonathan McKeown 
<jonathan+freebsd-hackers@hst.org.za> wrote:
> > While you're enhancing cdboot anyway, can I ask how complicated it
> > would be to make cdboot serial-console capable? (I'm not a C
> > programmer, I'm a sysadmin - but I'd be prepared to try and look at
> > this myself if no-one else is interested).
> >
> > As it stands, the only way I've found to do a serial-console CD-based
> > installation is by enabling the serial console in /boot/loader.conf,
> > by which time you've already missed several useful points,
> > particularly the entry to BIOS settings (if you have a serial-capable
> > BIOS).
>
> cdboot runs long after the prompt for BIOS setup.  I don't think we can
> modify cdboot to add serial console support to systems whose BIOS setup
> doesn't support it.

Sorry, of course you're right: I'm talking nonsense.

It's the stage immediately after that that isn't available. I wish I could 
remember why I thought that had caused me a problem once.

Certainly there's a big chunk of the boot process that is accessible through a 
serial console on a disk-based boot that's not available on a serial-console 
boot.
From keramida at freebsd.org  Thu Dec 11 04:43:04 2008
From: keramida at freebsd.org (Giorgos Keramidas)
Date: Thu Dec 11 04:43:11 2008
Subject: Enhancing cdboot [patch for review]
In-Reply-To: <200812111052.50082.jonathan@hst.org.za> (Jonathan McKeown's
	message of "Thu, 11 Dec 2008 10:52:49 +0200")
References: <493DA269.2070805@FreeBSD.org>
	<200812110837.26316.jonathan+freebsd-hackers@hst.org.za>
	<87prjzw156.fsf@kobe.laptop> <200812111052.50082.jonathan@hst.org.za>
Message-ID: <87r64eopbt.fsf@kobe.laptop>

On Thu, 11 Dec 2008 10:52:49 +0200, Jonathan McKeown <jonathan@hst.org.za> wrote:
>> cdboot runs long after the prompt for BIOS setup.  I don't think we
>> can modify cdboot to add serial console support to systems whose BIOS
>> setup doesn't support it.
>
> Sorry, of course you're right: I'm talking nonsense.
>
> It's the stage immediately after that that isn't available. I wish I
> could remember why I thought that had caused me a problem once.
>
> Certainly there's a big chunk of the boot process that is accessible
> through a serial console on a disk-based boot that's not available on
> a serial-console boot.

I'm still not sure what sort of `serial console boot' we are talking
about here.  What's the difference between a `serial console on a
disk-based boot' and a `serial console boot'?
From jonathan+freebsd-hackers at hst.org.za  Thu Dec 11 05:08:53 2008
From: jonathan+freebsd-hackers at hst.org.za (Jonathan McKeown)
Date: Thu Dec 11 05:09:00 2008
Subject: Enhancing cdboot [patch for review]
In-Reply-To: <87r64eopbt.fsf@kobe.laptop>
References: <493DA269.2070805@FreeBSD.org>
	<200812111052.50082.jonathan@hst.org.za>
	<87r64eopbt.fsf@kobe.laptop>
Message-ID: <200812111509.19099.jonathan+freebsd-hackers@hst.org.za>

On Thursday 11 December 2008 14:42:46 Giorgos Keramidas wrote:
> On Thu, 11 Dec 2008 10:52:49 +0200, Jonathan McKeown <jonathan@hst.org.za> 
wrote:
> >> cdboot runs long after the prompt for BIOS setup.  I don't think we
> >> can modify cdboot to add serial console support to systems whose BIOS
> >> setup doesn't support it.
> >
> > Sorry, of course you're right: I'm talking nonsense.
> >
> > It's the stage immediately after that that isn't available. I wish I
> > could remember why I thought that had caused me a problem once.
> >
> > Certainly there's a big chunk of the boot process that is accessible
> > through a serial console on a disk-based boot that's not available on
> > a serial-console boot.
>
> I'm still not sure what sort of `serial console boot' we are talking
> about here.  What's the difference between a `serial console on a
> disk-based boot' and a `serial console boot'?

Sorry, there's been an element of ``ready - fire - aim'' about my messages 
today - I'm trying to do several other things at once.

Let me get a serial-boot CD out and play with it - it's a while since I did a 
headless install so I'm working from a vague memory.

I think what I'm saying is that there are several stages in the boot process; 
when booting from a hard drive and using a serial console, all the stages are 
accessible: but when booting from a CD, only the last stage is.

I seem to remember that causing me a problem with a headless machine once upon 
a time (perhaps there was an error at an early stage, with the first hard 
drive failing, and I couldn't see loader(8) to tell it to boot off the second 
drive which was a mirror of the first?).

Certainly I've taken part in a couple of discussions in -questions over the 
last year or two in which people want to know how to make a serial-capable 
install CD - which is not as straightforward as it might be if there were a 
serial-capable cdboot (along the same lines as putting boot0sio instead of 
boot0 on a hard drive).

Jonathan
From keramida at ceid.upatras.gr  Thu Dec 11 05:15:35 2008
From: keramida at ceid.upatras.gr (Giorgos Keramidas)
Date: Thu Dec 11 05:15:44 2008
Subject: Small Change to chpass.c
In-Reply-To: <20081211080955.T60586@ramstind.fig.ol.no> ("Trond
	=?iso-8859-1?Q?Endrest=F8l=22's?=
	message of "Thu, 11 Dec 2008 08:11:20 +0100 (CET)")
References: <f4ecc0930812101800g601d9f10jc008e83d82b54a81@mail.gmail.com>
	<87vdtr9q8a.fsf@kobe.laptop>
	<20081211080955.T60586@ramstind.fig.ol.no>
Message-ID: <87zlj2kg4e.fsf@kobe.laptop>

On Thu, 11 Dec 2008 08:11:20 +0100 (CET), Trond Endrest?l <Trond.Endrestol@fagskolen.gjovik.no> wrote:
>On Thu, 11 Dec 2008 08:32+0200, Giorgos Keramidas wrote:
>> On Wed, 10 Dec 2008 18:00:25 -0800, "Sheldon Givens" <sheldon@sigsegv.ca> wrote:
>> > --- /usr/src/usr.bin/chpass.c   2008-12-11 01:55:27.000000000 -0800
>> > +++ /usr/src/usr.bin/chpass.c   2008-12-11 01:57:09.000000000 -0800
>> > @@ -80,10 +80,11 @@
>> >  {
>> >         enum { NEWSH, LOADENTRY, EDITENTRY, NEWPW, NEWEXP } op;
>> >         struct passwd lpw, *old_pw, *pw;
>> > -       int ch, pfd, tfd;
>> > +       int ch, pfd, tfd, itr, auth;
>> >         const char *password;
>> >         char *arg = NULL;
>> >         uid_t uid;
>> > +       int max_retries = 3;
>> >  #ifdef YP
>> >         struct ypclnt *ypclnt;
>> >         const char *yp_domain = NULL, *yp_host = NULL;
>> > @@ -227,9 +228,16 @@
>> >         }
>> >
>> >         if (old_pw && !master_mode) {
>> > -               password = getpass("Password: ");
>
> I'm sure you have noticed the trailing space in the string.
>
>> > -               if (strcmp(crypt(password, old_pw->pw_passwd),
>> > -                   old_pw->pw_passwd) != 0)
>> > +               auth = 0;
>> > +               for(itr=0;itr<max_retries;itr++) {
>> > +                       password = getpass("Password:");
>
> The space's missing in this string. It might be better to stay
> consistent with the original code.

Good catch.  No, I didn't notice the missing space the first time I read
the diff :/

From bms at FreeBSD.org  Thu Dec 11 08:40:55 2008
From: bms at FreeBSD.org (Bruce M. Simpson)
Date: Thu Dec 11 08:41:06 2008
Subject: Enhancing cdboot [patch for review]
In-Reply-To: <493DA269.2070805@FreeBSD.org>
References: <493DA269.2070805@FreeBSD.org>
Message-ID: <49413DFF.9030004@FreeBSD.org>

This sounds and looks cool, diff looks OK (haven't applied), Luigi's 
comments seem well thought out and expressed.

cheers
BMS
From danm at prime.gushi.org  Thu Dec 11 09:13:04 2008
From: danm at prime.gushi.org (Dan Mahoney, System Admin)
Date: Thu Dec 11 09:20:31 2008
Subject: (no subject)
Message-ID: <alpine.BSF.2.00.0812111140210.32947@prime.gushi.org>

Okay, new problem with regard to netgroups, NIS, and Pam:

Given the following situation:

* I want to be able to have su work normally in the event of an NIS 
disconnect, since I will likely need to su to fix said disconnect.

* The wheel group needs to stay local

* I want su to still use group ownership as a check

I recently could not get an admin account (defined in NIS) to su to root. 
Even though "groups username" showed he was in wheel (and the wheel group 
has been propagated into NIS), pam_group and pw groupshow show him as 
not.)  This is probably because the local wheel group overrode the NIS 
wheel group.  (I'm not that thrilled by having the wheel group in NIS 
anyway).

Since pam_group is "requisite", there's no easy way to call it multiple 
times, and no easy pam syntax to say "one of these two must pass". 
Required won't help, Otherwise I'd simply define an extra group, call it 
NISwheel or something, and configure access accordingly.

What I instead would propose is for pam_group to take an optional argument 
list instead of a single group (or possibly, multiple group= 
requirements).

Doing something with pam_exec is an option here as well, but I feel this 
functionality should be fairly elementary to add, moving forward.

-Dan

-- 

"You're a daddy.  I'm a mommy.  She's our baby.  Deal with it."

-Cali, 11/7/02, about 1:35 AM

--------Dan Mahoney--------
Techie,  Sysadmin,  WebGeek
Gushi on efnet/undernet IRC
ICQ: 13735144   AIM: LarpGM
Site:  http://www.gushi.org
---------------------------

From yanefbsd at gmail.com  Thu Dec 11 12:39:54 2008
From: yanefbsd at gmail.com (Garrett Cooper)
Date: Thu Dec 11 12:40:01 2008
Subject: Small Change to chpass.c
In-Reply-To: <87zlj2kg4e.fsf@kobe.laptop>
References: <f4ecc0930812101800g601d9f10jc008e83d82b54a81@mail.gmail.com>
	<87vdtr9q8a.fsf@kobe.laptop>
	<20081211080955.T60586@ramstind.fig.ol.no>
	<87zlj2kg4e.fsf@kobe.laptop>
Message-ID: <7d6fde3d0812111239i7a47037mf9b5e4e5386b540@mail.gmail.com>

On Thu, Dec 11, 2008 at 5:15 AM, Giorgos Keramidas
<keramida@ceid.upatras.gr> wrote:
> On Thu, 11 Dec 2008 08:11:20 +0100 (CET), Trond Endrest?l <Trond.Endrestol@fagskolen.gjovik.no> wrote:
>>On Thu, 11 Dec 2008 08:32+0200, Giorgos Keramidas wrote:
>>> On Wed, 10 Dec 2008 18:00:25 -0800, "Sheldon Givens" <sheldon@sigsegv.ca> wrote:
>>> > --- /usr/src/usr.bin/chpass.c   2008-12-11 01:55:27.000000000 -0800
>>> > +++ /usr/src/usr.bin/chpass.c   2008-12-11 01:57:09.000000000 -0800
>>> > @@ -80,10 +80,11 @@
>>> >  {
>>> >         enum { NEWSH, LOADENTRY, EDITENTRY, NEWPW, NEWEXP } op;
>>> >         struct passwd lpw, *old_pw, *pw;
>>> > -       int ch, pfd, tfd;
>>> > +       int ch, pfd, tfd, itr, auth;
>>> >         const char *password;
>>> >         char *arg = NULL;
>>> >         uid_t uid;
>>> > +       int max_retries = 3;
>>> >  #ifdef YP
>>> >         struct ypclnt *ypclnt;
>>> >         const char *yp_domain = NULL, *yp_host = NULL;
>>> > @@ -227,9 +228,16 @@
>>> >         }
>>> >
>>> >         if (old_pw && !master_mode) {
>>> > -               password = getpass("Password: ");
>>
>> I'm sure you have noticed the trailing space in the string.
>>
>>> > -               if (strcmp(crypt(password, old_pw->pw_passwd),
>>> > -                   old_pw->pw_passwd) != 0)
>>> > +               auth = 0;
>>> > +               for(itr=0;itr<max_retries;itr++) {
>>> > +                       password = getpass("Password:");
>>
>> The space's missing in this string. It might be better to stay
>> consistent with the original code.
>
> Good catch.  No, I didn't notice the missing space the first time I read
> the diff :/

A better way to solve this may be to add an option to set the number
of retries before failure and then just pass it through to this
function.
-Garrett
From david at catwhisker.org  Thu Dec 11 14:53:50 2008
From: david at catwhisker.org (David Wolfskill)
Date: Thu Dec 11 14:54:03 2008
Subject: NFS (& amd?) dysfunction descending a hierarchy
In-Reply-To: <20081210170620.GS2038@deviant.kiev.zoral.com.ua>
References: <20081203001538.GC96383@bunrab.catwhisker.org>
	<20081209190110.GW60731@albert.catwhisker.org>
	<Pine.GSO.4.63.0812101124430.24743@muncher.cs.uoguelph.ca>
	<20081210165022.GJ60731@albert.catwhisker.org>
	<20081210170620.GS2038@deviant.kiev.zoral.com.ua>
Message-ID: <20081211225349.GB5597@albert.catwhisker.org>

On Wed, Dec 10, 2008 at 07:06:20PM +0200, Kostik Belousov wrote:
> ...
> > What concerns me is that even if the attempted unmount gets EBUSY, the
> > user-level process descending the directory hierarchy is getting ENOENT
> > trying to issue fstatfs() against an open file descriptor.
> > 
> > I'm having trouble figuring out any way that makes any sense.
> 
> Basically, the problem is that NFS uses shared lookup, and this allows
> for the bug where several negative namecache entries are created for
> non-existent node. Then this node gets created, removing only the first
> negative namecache entry. For some reasons, vnode is reclaimed; amd'
> tasting of unmount is a good reason for vnode to be reclaimed.
> 
> Now, you have existing path and a negative cache entry. This was
> reported by Peter Holm first, I listed relevant revisions that
> should fix this in previous mail.

Well, I messed up the machine I had been using for testing, and needed
to wait for IT to do something to it since I don't have physical or
console access to it.

So after I happened to demonstrate the effect using my desktop  -- which
had been running RELENG_7_1, sources updated as of around 0400 hrs.
US/Pacific -- I decided to go ahead and update the desktop to RELENG_7_1
as of this morning (which had the commit to sys/kern/vfs_cache.c), then
test.

It still failed, apparently in the same way; details below.

First, here's a list of the files that were changed:

U lib/libarchive/archive_read_support_format_iso9660.c
U lib/libarchive/archive_string.c
U lib/libarchive/archive_string.h
U lib/libc/gen/times.3
U lib/libc/i386/sys/pipe.S
U lib/libc/i386/sys/reboot.S
U lib/libc/i386/sys/setlogin.S
U lib/libutil/Makefile
U lib/libutil/kinfo_getfile.c
U lib/libutil/kinfo_getvmmap.c
U lib/libutil/libutil.h
U share/man/man4/bce.4
U share/man/man5/Makefile
U share/man/man5/fstab.5
U share/man/man5/nullfs.5
U sys/amd64/Makefile
U sys/boot/forth/loader.conf.5
U sys/dev/ale/if_ale.c
U sys/dev/bce/if_bce.c
U sys/dev/cxgb/cxgb_main.c
U sys/dev/cxgb/common/cxgb_ael1002.c
U sys/dev/cxgb/common/cxgb_t3_hw.c
U sys/dev/cxgb/common/cxgb_xgmac.c
U sys/dev/re/if_re.c
U sys/fs/nullfs/null_vnops.c
U sys/kern/Make.tags.inc
U sys/kern/kern_descrip.c
U sys/kern/kern_proc.c
U sys/kern/vfs_cache.c
U sys/netinet/in_pcb.h
U sys/pci/if_rlreg.h
U sys/sys/sysctl.h
U sys/sys/user.h
U sys/ufs/ufs/ufs_quota.c
U usr.bin/procstat/Makefile
U usr.bin/procstat/procstat_files.c
U usr.bin/procstat/procstat_vm.c
U usr.bin/tar/util.c
U usr.bin/tar/test/Makefile
U usr.bin/tar/test/test_strip_components.c
U usr.bin/tar/test/test_symlink_dir.c
U usr.bin/xargs/xargs.1
U usr.sbin/mtree/mtree.c

We see that sys/kern/vfs_cache.c is, indeed, among them.  And:

dwolf-bsd(7.1-P)[5] grep '\$FreeBSD' /sys/kern/vfs_cache.c
__FBSDID("$FreeBSD: src/sys/kern/vfs_cache.c,v 1.114.2.3 2008/12/09 16:20:58 kib Exp $");
dwolf-bsd(7.1-P)[6] 

That should correspond to the desired version of the file.

Here we see an excerpt from the ktrace output for the amd(8) process and
its children; this is a point when amd(8) is trying an unmount() to see
if it can get away with it:

   977 amd      1229033597.269612 CALL  gettimeofday(0x807ad48,0)
   977 amd      1229033597.269620 RET   gettimeofday 0
   977 amd      1229033597.269630 CALL  sigprocmask(SIG_BLOCK,0xbfbfeaec,0xbfbfeadc)
   977 amd      1229033597.269637 RET   sigprocmask 0
   977 amd      1229033597.269645 CALL  fork
   977 amd      1229033597.273810 RET   fork 1712/0x6b0
  1712 amd      1229033597.273811 RET   fork 0
   977 amd      1229033597.273836 CALL  sigprocmask(SIG_SETMASK,0xbfbfeadc,0)
  1712 amd      1229033597.273845 CALL  getpid
   977 amd      1229033597.273850 RET   sigprocmask 0
  1712 amd      1229033597.273855 RET   getpid 1712/0x6b0
   977 amd      1229033597.273864 CALL  gettimeofday(0x807ad48,0)
   977 amd      1229033597.273874 RET   gettimeofday 0
  1712 amd      1229033597.273878 CALL  unmount(0x2832c610,<invalid>0)
...
  1712 amd      1229033597.352643 RET   unmount -1 errno 16 Device busy
  1712 amd      1229033597.352695 CALL  sigprocmask(SIG_BLOCK,0x28097c00,0xbfbfea0c)
  1712 amd      1229033597.352728 RET   sigprocmask 0
  1712 amd      1229033597.352751 CALL  sigprocmask(SIG_SETMASK,0x28097c10,0)
  1712 amd      1229033597.352769 RET   sigprocmask 0
  1712 amd      1229033597.352781 CALL  sigprocmask(SIG_BLOCK,0x28097c00,0xbfbfe9dc)
  1712 amd      1229033597.352790 RET   sigprocmask 0
  1712 amd      1229033597.352801 CALL  sigprocmask(SIG_SETMASK,0x28097c10,0)
  1712 amd      1229033597.352805 RET   sigprocmask 0
  1712 amd      1229033597.352815 CALL  exit(0x10)
   977 amd      1229033597.353085 RET   select -1 errno 4 Interrupted system call
   977 amd      1229033597.353093 PSIG  SIGCHLD caught handler=0x805de50 mask=0x0 code=0x0
   977 amd      1229033597.353103 CALL  wait4(0xffffffff,0xbfbfe83c,WNOHANG,0)
   977 amd      1229033597.353116 RET   wait4 1712/0x6b0
   977 amd      1229033597.353122 CALL  wait4(0xffffffff,0xbfbfe83c,WNOHANG,0)
   977 amd      1229033597.353127 RET   wait4 -1 errno 10 No child processes


So amd(8) master process (pid 977) jorks off a child (pid 1712) to
try an umount(), which it initiates at 1229033597.273878.  At
1229033597.352643 the child gets control back, as well as an EBUSY,
which I would expect to mean that the attempt failed.  The child
exits at 1229033597.352815 with a status code of 16.

Armed with that, we look at a ktrace excerpt from "rm -fr":

  1660 rm       1229033597.283277 CALL  rmdir(0x2822b388)
  1660 rm       1229033597.283283 NAMI  "stvef-paks"
  1660 rm       1229033597.285599 RET   rmdir 0
  1660 rm       1229033597.285620 CALL  stat(0x2822b3e8,0xbfbfe8dc)
  1660 rm       1229033597.285626 NAMI  "stvef-server"
  1660 rm       1229033597.286071 STRU  struct stat {dev=83951372, ino=20124614, mode=drwxr-xr-x , nlink=3, uid=9874, gid=929, rdev=0, atime=1228844788, stime=1227555769, ctime=1228845828.326650000, birthtime=0, size=4096, blksize=4096, blocks=8, flags=0x0 }
  1660 rm       1229033597.286078 RET   stat 0
  1660 rm       1229033597.286084 CALL  open(0x2822b3e8,O_NONBLOCK,<unused>0x1)
  1660 rm       1229033597.286091 NAMI  "stvef-server"
  1660 rm       1229033597.287145 RET   open 4
  1660 rm       1229033597.287154 CALL  fstat(0x4,0xbfbfe8dc)
  1660 rm       1229033597.287161 STRU  struct stat {dev=83951372, ino=20124614, mode=drwxr-xr-x , nlink=3, uid=9874, gid=929, rdev=0, atime=1228844788, stime=1227555769, ctime=1228845828.326650000, birthtime=0, size=4096, blksize=4096, blocks=8, flags=0x0 }
  1660 rm       1229033597.287166 RET   fstat 0
  1660 rm       1229033597.287171 CALL  fcntl(0x4,F_SETFD,FD_CLOEXEC)
  1660 rm       1229033597.287177 RET   fcntl 0
  1660 rm       1229033597.287187 CALL  fstatfs(0x4,0xbfbfe704)
  1660 rm       1229033597.287195 RET   fstatfs -1 errno 2 No such file or directory
  1660 rm       1229033597.287202 CALL  close(0x4)
  1660 rm       1229033597.287211 RET   close 0

[Sorry for the long lines....]

Here we see that the "rm" process (pid 1660) removed a directory
named stvef-paks sucessfully in the interval between 1229033597.283277
(when the request was made) and 1229033597.285599 (when the 0 return
occurred).  The "rm" process proceeds to process a directory named
stvef-server:

* At 1229033597.285620 it issues a stat(); the successful return
  is at 1229033597.286078.

* At 1229033597.286084 it issues an open(); the successful return
  is at 1229033597.287145.  The FD is 4.

* At 1229033597.287154 it issues an fstat() against FD 4; the successful
  return is at 1229033597.287166.

* At 1229033597.287171 it issues an fcntl() against FD 4; the
  successful return is at 1229033597.287177.

* At 1229033597.287187 it issues an fstatfs() against FD 4; the
  unsuccessful return is at 1229033597.287195, claiming ENOENT.

Say WHAT??!?

I expect to be able to test a bit more promptly now.

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: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20081211/4af8cb69/attachment.pgp
From avg at icyb.net.ua  Fri Dec 12 03:17:32 2008
From: avg at icyb.net.ua (Andriy Gapon)
Date: Fri Dec 12 03:17:39 2008
Subject: memtest86+ can not link: binutils issue?
In-Reply-To: <490B05BA.9090306@icyb.net.ua>
References: <4909DC03.1080901@icyb.net.ua>
	<20081030184625.GA99398@server.vk2pj.dyndns.org>
	<490B05BA.9090306@icyb.net.ua>
Message-ID: <4942483D.8000003@icyb.net.ua>

on 31/10/2008 15:18 Andriy Gapon said the following:
>>> ld --warn-constructors --warn-common -static -T memtest_shared.lds \
>>>        -o memtest_shared head.o reloc.o main.o test.o init.o lib.o
>>> patn.o screen_buffer.o config.o linuxbios.o memsize.o pci.o controller.o
>>> random.o extra.o spd.o error.o dmi.o && \
>>>        ld -shared -Bsymbolic -T memtest_shared.lds -o memtest_shared
>>> head.o reloc.o main.o test.o init.o lib.o patn.o screen_buffer.o
>>> config.o linuxbios.o memsize.o pci.o controller.o random.o extra.o spd.o
>>> error.o dmi.o
>>> head.o(.text+0x7): In function `startup_32':
>>> : undefined reference to `_GLOBAL_OFFSET_TABLE_'
>>> Segmentation fault (core dumped)

Just in case anybody still remembers this issue.
It seams that the main culprit here was the following line in the linker
script:

OUTPUT_FORMAT("elf32-i386");

I was tipped just today that it should have read:
OUTPUT_FORMAT("elf32-i386-freebsd", "elf32-i386-freebsd",
"elf32-i386-freebsd");

-- 
Andriy Gapon
From artis.caune at gmail.com  Fri Dec 12 03:45:47 2008
From: artis.caune at gmail.com (Artis Caune)
Date: Fri Dec 12 03:45:54 2008
Subject: Strange "changed paths" in svn commits
Message-ID: <9e20d71e0812120315l30d72b2doc899a8163fde829f@mail.gmail.com>

Hi,

Is it how merging works or I'm missing something?

Why /stable/7/sys and /stable/7/sys/contrib/pf are in changed paths in
commit r185814?
Starting from 2008 Aug they appear in almost all commits to stable/7.



# svn log -v svn://svn.freebsd.org/base/stable/7 -r185814
Changed paths:
   M /stable/7/sys
   M /stable/7/sys/contrib/pf
   M /stable/7/sys/netinet/in_pcb.h

Merge r185791 from head to stable/7:



# svn diff svn://svn.freebsd.org/base/stable/7 -r185805:185814
... diff to in_pcb.h ...

Property changes on: sys/contrib/pf
___________________________________________________________________
Modified: svn:mergeinfo
   Merged /head/sys/contrib/pf:r185791

Property changes on: sys
___________________________________________________________________
Modified: svn:mergeinfo
   Merged /head/sys:r185791



# svn log -v svn://svn.freebsd.org/base/head -r185791
------------------------------------------------------------------------
Changed paths:
   M /head/sys/netinet/in_pcb.h





-- 
regards,
Artis Caune

<----. CCNA | BSDA
<----|====================
<----' didii FreeBSD
From rihad at mail.ru  Fri Dec 12 01:58:37 2008
From: rihad at mail.ru (rihad)
Date: Fri Dec 12 04:48:01 2008
Subject: preventing FIFO from EOF
Message-ID: <494235CA.2050101@mail.ru>

$ mkfifo /var/tmp/foo
$ buffer -i /var/tmp/foo                    # misc/buffer
# in another console:
$ echo hi > /var/tmp/foo

buffer prints hi and exits. I want it to keep reading and printing 
indefinitely.

Further experimentation revealed that I need two writers: one dummy 
writer that just keeps /var/tmp/foo open for writing, and the other 
doing the "real work". This way buffer wouldn't exit. But how to emulate 
the dummy writer? It itself needs to block on something to keep 
/var/tmp/foo open. Any clean way to do this in shell? Maybe the solution 
is quite simple but isn't at the tip of my tongue.

Thanks.
From danny at cs.huji.ac.il  Fri Dec 12 05:24:10 2008
From: danny at cs.huji.ac.il (Danny Braniss)
Date: Fri Dec 12 05:24:17 2008
Subject: preventing FIFO from EOF 
In-Reply-To: <494235CA.2050101@mail.ru> 
References: <494235CA.2050101@mail.ru>
Message-ID: <E1LB7zz-0006kU-SU@kabab.cs.huji.ac.il>

> $ mkfifo /var/tmp/foo
> $ buffer -i /var/tmp/foo                    # misc/buffer
> # in another console:
> $ echo hi > /var/tmp/foo
> 
> buffer prints hi and exits. I want it to keep reading and printing 
> indefinitely.
> 
> Further experimentation revealed that I need two writers: one dummy 
> writer that just keeps /var/tmp/foo open for writing, and the other 
> doing the "real work". This way buffer wouldn't exit. But how to emulate 
> the dummy writer? It itself needs to block on something to keep 
> /var/tmp/foo open. Any clean way to do this in shell? Maybe the solution 
> is quite simple but isn't at the tip of my tongue.
> 
> Thanks.

too easy
n csh:
	while 1
		buffer -i /var/tmp/foo 
	end
or in sh:
	while true; do
		buffer -i /var/tmp/foo
	done



From kostikbel at gmail.com  Fri Dec 12 05:41:40 2008
From: kostikbel at gmail.com (Kostik Belousov)
Date: Fri Dec 12 05:41:47 2008
Subject: NFS (& amd?) dysfunction descending a hierarchy
In-Reply-To: <20081211225349.GB5597@albert.catwhisker.org>
References: <20081203001538.GC96383@bunrab.catwhisker.org>
	<20081209190110.GW60731@albert.catwhisker.org>
	<Pine.GSO.4.63.0812101124430.24743@muncher.cs.uoguelph.ca>
	<20081210165022.GJ60731@albert.catwhisker.org>
	<20081210170620.GS2038@deviant.kiev.zoral.com.ua>
	<20081211225349.GB5597@albert.catwhisker.org>
Message-ID: <20081212134129.GD2038@deviant.kiev.zoral.com.ua>

On Thu, Dec 11, 2008 at 02:53:49PM -0800, David Wolfskill wrote:
> On Wed, Dec 10, 2008 at 07:06:20PM +0200, Kostik Belousov wrote:
> > ...
> > > What concerns me is that even if the attempted unmount gets EBUSY, the
> > > user-level process descending the directory hierarchy is getting ENOENT
> > > trying to issue fstatfs() against an open file descriptor.
> > > 
> > > I'm having trouble figuring out any way that makes any sense.
> > 
> > Basically, the problem is that NFS uses shared lookup, and this allows
> > for the bug where several negative namecache entries are created for
> > non-existent node. Then this node gets created, removing only the first
> > negative namecache entry. For some reasons, vnode is reclaimed; amd'
> > tasting of unmount is a good reason for vnode to be reclaimed.
> > 
> > Now, you have existing path and a negative cache entry. This was
> > reported by Peter Holm first, I listed relevant revisions that
> > should fix this in previous mail.
> 
> Well, I messed up the machine I had been using for testing, and needed
> to wait for IT to do something to it since I don't have physical or
> console access to it.
> 
> So after I happened to demonstrate the effect using my desktop  -- which
> had been running RELENG_7_1, sources updated as of around 0400 hrs.
> US/Pacific -- I decided to go ahead and update the desktop to RELENG_7_1
> as of this morning (which had the commit to sys/kern/vfs_cache.c), then
> test.
> 
> It still failed, apparently in the same way; details below.
> 
> First, here's a list of the files that were changed:
> 
> U lib/libarchive/archive_read_support_format_iso9660.c
> U lib/libarchive/archive_string.c
> U lib/libarchive/archive_string.h
> U lib/libc/gen/times.3
> U lib/libc/i386/sys/pipe.S
> U lib/libc/i386/sys/reboot.S
> U lib/libc/i386/sys/setlogin.S
> U lib/libutil/Makefile
> U lib/libutil/kinfo_getfile.c
> U lib/libutil/kinfo_getvmmap.c
> U lib/libutil/libutil.h
> U share/man/man4/bce.4
> U share/man/man5/Makefile
> U share/man/man5/fstab.5
> U share/man/man5/nullfs.5
> U sys/amd64/Makefile
> U sys/boot/forth/loader.conf.5
> U sys/dev/ale/if_ale.c
> U sys/dev/bce/if_bce.c
> U sys/dev/cxgb/cxgb_main.c
> U sys/dev/cxgb/common/cxgb_ael1002.c
> U sys/dev/cxgb/common/cxgb_t3_hw.c
> U sys/dev/cxgb/common/cxgb_xgmac.c
> U sys/dev/re/if_re.c
> U sys/fs/nullfs/null_vnops.c
> U sys/kern/Make.tags.inc
> U sys/kern/kern_descrip.c
> U sys/kern/kern_proc.c
> U sys/kern/vfs_cache.c
> U sys/netinet/in_pcb.h
> U sys/pci/if_rlreg.h
> U sys/sys/sysctl.h
> U sys/sys/user.h
> U sys/ufs/ufs/ufs_quota.c
> U usr.bin/procstat/Makefile
> U usr.bin/procstat/procstat_files.c
> U usr.bin/procstat/procstat_vm.c
> U usr.bin/tar/util.c
> U usr.bin/tar/test/Makefile
> U usr.bin/tar/test/test_strip_components.c
> U usr.bin/tar/test/test_symlink_dir.c
> U usr.bin/xargs/xargs.1
> U usr.sbin/mtree/mtree.c
> 
> We see that sys/kern/vfs_cache.c is, indeed, among them.  And:
> 
> dwolf-bsd(7.1-P)[5] grep '\$FreeBSD' /sys/kern/vfs_cache.c
> __FBSDID("$FreeBSD: src/sys/kern/vfs_cache.c,v 1.114.2.3 2008/12/09 16:20:58 kib Exp $");
> dwolf-bsd(7.1-P)[6] 
> 
> That should correspond to the desired version of the file.
> 
> Here we see an excerpt from the ktrace output for the amd(8) process and
> its children; this is a point when amd(8) is trying an unmount() to see
> if it can get away with it:
> 
>    977 amd      1229033597.269612 CALL  gettimeofday(0x807ad48,0)
>    977 amd      1229033597.269620 RET   gettimeofday 0
>    977 amd      1229033597.269630 CALL  sigprocmask(SIG_BLOCK,0xbfbfeaec,0xbfbfeadc)
>    977 amd      1229033597.269637 RET   sigprocmask 0
>    977 amd      1229033597.269645 CALL  fork
>    977 amd      1229033597.273810 RET   fork 1712/0x6b0
>   1712 amd      1229033597.273811 RET   fork 0
>    977 amd      1229033597.273836 CALL  sigprocmask(SIG_SETMASK,0xbfbfeadc,0)
>   1712 amd      1229033597.273845 CALL  getpid
>    977 amd      1229033597.273850 RET   sigprocmask 0
>   1712 amd      1229033597.273855 RET   getpid 1712/0x6b0
>    977 amd      1229033597.273864 CALL  gettimeofday(0x807ad48,0)
>    977 amd      1229033597.273874 RET   gettimeofday 0
>   1712 amd      1229033597.273878 CALL  unmount(0x2832c610,<invalid>0)
> ...
>   1712 amd      1229033597.352643 RET   unmount -1 errno 16 Device busy
>   1712 amd      1229033597.352695 CALL  sigprocmask(SIG_BLOCK,0x28097c00,0xbfbfea0c)
>   1712 amd      1229033597.352728 RET   sigprocmask 0
>   1712 amd      1229033597.352751 CALL  sigprocmask(SIG_SETMASK,0x28097c10,0)
>   1712 amd      1229033597.352769 RET   sigprocmask 0
>   1712 amd      1229033597.352781 CALL  sigprocmask(SIG_BLOCK,0x28097c00,0xbfbfe9dc)
>   1712 amd      1229033597.352790 RET   sigprocmask 0
>   1712 amd      1229033597.352801 CALL  sigprocmask(SIG_SETMASK,0x28097c10,0)
>   1712 amd      1229033597.352805 RET   sigprocmask 0
>   1712 amd      1229033597.352815 CALL  exit(0x10)
>    977 amd      1229033597.353085 RET   select -1 errno 4 Interrupted system call
>    977 amd      1229033597.353093 PSIG  SIGCHLD caught handler=0x805de50 mask=0x0 code=0x0
>    977 amd      1229033597.353103 CALL  wait4(0xffffffff,0xbfbfe83c,WNOHANG,0)
>    977 amd      1229033597.353116 RET   wait4 1712/0x6b0
>    977 amd      1229033597.353122 CALL  wait4(0xffffffff,0xbfbfe83c,WNOHANG,0)
>    977 amd      1229033597.353127 RET   wait4 -1 errno 10 No child processes
> 
> 
> So amd(8) master process (pid 977) jorks off a child (pid 1712) to
> try an umount(), which it initiates at 1229033597.273878.  At
> 1229033597.352643 the child gets control back, as well as an EBUSY,
> which I would expect to mean that the attempt failed.  The child
> exits at 1229033597.352815 with a status code of 16.
> 
> Armed with that, we look at a ktrace excerpt from "rm -fr":
> 
>   1660 rm       1229033597.283277 CALL  rmdir(0x2822b388)
>   1660 rm       1229033597.283283 NAMI  "stvef-paks"
>   1660 rm       1229033597.285599 RET   rmdir 0
>   1660 rm       1229033597.285620 CALL  stat(0x2822b3e8,0xbfbfe8dc)
>   1660 rm       1229033597.285626 NAMI  "stvef-server"
>   1660 rm       1229033597.286071 STRU  struct stat {dev=83951372, ino=20124614, mode=drwxr-xr-x , nlink=3, uid=9874, gid=929, rdev=0, atime=1228844788, stime=1227555769, ctime=1228845828.326650000, birthtime=0, size=4096, blksize=4096, blocks=8, flags=0x0 }
>   1660 rm       1229033597.286078 RET   stat 0
>   1660 rm       1229033597.286084 CALL  open(0x2822b3e8,O_NONBLOCK,<unused>0x1)
>   1660 rm       1229033597.286091 NAMI  "stvef-server"
>   1660 rm       1229033597.287145 RET   open 4
>   1660 rm       1229033597.287154 CALL  fstat(0x4,0xbfbfe8dc)
>   1660 rm       1229033597.287161 STRU  struct stat {dev=83951372, ino=20124614, mode=drwxr-xr-x , nlink=3, uid=9874, gid=929, rdev=0, atime=1228844788, stime=1227555769, ctime=1228845828.326650000, birthtime=0, size=4096, blksize=4096, blocks=8, flags=0x0 }
>   1660 rm       1229033597.287166 RET   fstat 0
>   1660 rm       1229033597.287171 CALL  fcntl(0x4,F_SETFD,FD_CLOEXEC)
>   1660 rm       1229033597.287177 RET   fcntl 0
>   1660 rm       1229033597.287187 CALL  fstatfs(0x4,0xbfbfe704)
>   1660 rm       1229033597.287195 RET   fstatfs -1 errno 2 No such file or directory
>   1660 rm       1229033597.287202 CALL  close(0x4)
>   1660 rm       1229033597.287211 RET   close 0
> 
> [Sorry for the long lines....]
> 
> Here we see that the "rm" process (pid 1660) removed a directory
> named stvef-paks sucessfully in the interval between 1229033597.283277
> (when the request was made) and 1229033597.285599 (when the 0 return
> occurred).  The "rm" process proceeds to process a directory named
> stvef-server:
> 
> * At 1229033597.285620 it issues a stat(); the successful return
>   is at 1229033597.286078.
> 
> * At 1229033597.286084 it issues an open(); the successful return
>   is at 1229033597.287145.  The FD is 4.
> 
> * At 1229033597.287154 it issues an fstat() against FD 4; the successful
>   return is at 1229033597.287166.
> 
> * At 1229033597.287171 it issues an fcntl() against FD 4; the
>   successful return is at 1229033597.287177.
> 
> * At 1229033597.287187 it issues an fstatfs() against FD 4; the
>   unsuccessful return is at 1229033597.287195, claiming ENOENT.
> 
> Say WHAT??!?
> 
> I expect to be able to test a bit more promptly now.

But is this error transient or permanent ? I.e., would restart of rm
successful or failing ?

Anyway, this error looks different too.
-------------- 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-hackers/attachments/20081212/9a949dd9/attachment.pgp
From christoph.mallon at gmx.de  Fri Dec 12 05:51:00 2008
From: christoph.mallon at gmx.de (Christoph Mallon)
Date: Fri Dec 12 05:51:08 2008
Subject: preventing FIFO from EOF
In-Reply-To: <494235CA.2050101@mail.ru>
References: <494235CA.2050101@mail.ru>
Message-ID: <49426C40.6050802@gmx.de>

rihad schrieb:
> $ mkfifo /var/tmp/foo
> $ buffer -i /var/tmp/foo                    # misc/buffer
> # in another console:
> $ echo hi > /var/tmp/foo
> 
> buffer prints hi and exits. I want it to keep reading and printing 
> indefinitely.
> 
> Further experimentation revealed that I need two writers: one dummy 
> writer that just keeps /var/tmp/foo open for writing, and the other 
> doing the "real work". This way buffer wouldn't exit. But how to emulate 
> the dummy writer? It itself needs to block on something to keep 
> /var/tmp/foo open. Any clean way to do this in shell? Maybe the solution 
> is quite simple but isn't at the tip of my tongue.

Maybe "tail -f" is what you are looking for.
From david at catwhisker.org  Fri Dec 12 06:36:44 2008
From: david at catwhisker.org (David Wolfskill)
Date: Fri Dec 12 06:36:50 2008
Subject: NFS (& amd?) dysfunction descending a hierarchy
In-Reply-To: <20081212134129.GD2038@deviant.kiev.zoral.com.ua>
References: <20081203001538.GC96383@bunrab.catwhisker.org>
	<20081209190110.GW60731@albert.catwhisker.org>
	<Pine.GSO.4.63.0812101124430.24743@muncher.cs.uoguelph.ca>
	<20081210165022.GJ60731@albert.catwhisker.org>
	<20081210170620.GS2038@deviant.kiev.zoral.com.ua>
	<20081211225349.GB5597@albert.catwhisker.org>
	<20081212134129.GD2038@deviant.kiev.zoral.com.ua>
Message-ID: <20081212143643.GE5597@albert.catwhisker.org>

On Fri, Dec 12, 2008 at 03:41:29PM +0200, Kostik Belousov wrote:
> ...
> > * At 1229033597.287187 it issues an fstatfs() against FD 4; the
> >   unsuccessful return is at 1229033597.287195, claiming ENOENT.
> > 
> > Say WHAT??!?
> ...
> 
> But is this error transient or permanent ? I.e., would restart of rm
> successful or failing ?

In a test yesterday, it took 3 attempts (each attempt being an
invocations of "rm -fr ~bspace/ports") to actually complete removal of
the hierarchy.

Please note that:

* Done on a locally-mounted file systen (vs. NFS), a single invocation
  is sufficient and terminates normally.  Each of the above-cited
  attempts but the last terminated with a status code of 1 (as well as
  a whine that one or more subdirectories was not empty -- this, as a
  result of "rm" getting inconsistent information about the status of the
  file system).

* Done on either a locally- or NFS-mounted file system in FreeBSD 6.x, a
  single invocation is sufficient and terminates normally.

In other words, this is a regression.

> Anyway, this error looks different too.

?  From the earlier-posted results in 7.x?  Not that I can tell.  In
each case, the amd(8) child process is forked to attempt an unmount(),
tries it, gets EBUSY, and exits.  Meanwhile, rm(1) is descending a
directory tree.  It had performed a readdir(), and had been unlinking
files and performing rmdir() against empty subdirectories.  It
encounters an entry, issues stat(), finds that it's a subdirectory,
open()s it, gets an FD, issues fstat(), gets results that match those of
the earlier stat(), issues fcntl() against the FD (which returns 0),
tries to issue fstatfs() against the FD *that is still open*, and gets
told ENOENT.

It does differ from the behavior in 8-CURRENT, in that the amd(8) child
process in 8-CURRENT does not appear to get EBUSY.  The behavior from
rm(1)'s perspective is very similar, though.

If it would help, I could try getting a ktrace from a 6.x system, but I
expect it will be very boring: the amd(8) child process should get EBUSY
(as it does in 7.x), and nothing else should happen, since the unmount()
attempt failed.  And since it failed, rm(1) doesn't get told
inconsistent information, so things Just Work.

I admit that I'm no expert on VFS or much of the rest of the kernel,
for that matter.  But what I have observed happening in recent 7.x
is both wrong and a regression.

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: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20081212/c14f3851/attachment.pgp
From rick-freebsd2008 at kiwi-computer.com  Fri Dec 12 07:58:34 2008
From: rick-freebsd2008 at kiwi-computer.com (Rick C. Petty)
Date: Fri Dec 12 07:58:41 2008
Subject: Strange "changed paths" in svn commits
In-Reply-To: <9e20d71e0812120315l30d72b2doc899a8163fde829f@mail.gmail.com>
References: <9e20d71e0812120315l30d72b2doc899a8163fde829f@mail.gmail.com>
Message-ID: <20081212155833.GB82667@keira.kiwi-computer.com>

On Fri, Dec 12, 2008 at 01:15:17PM +0200, Artis Caune wrote:
> Hi,
> 
> Is it how merging works or I'm missing something?

I suspect you've run into a well-known svn bug that affects "svn merge".  I
thought they had fixed it with subversion 1.5.4, but apparently it's still
around.  When doing a merge, it seems to randomly touch a bunch of files..
it only updates the svn:mergeinfo property on those files, but it's still
annoying.  Whenever I do a merge, I always merge into a working copy, then
double-check the work with "svn diff" before committing.  When I see it
bring in extra files, I just do a revert on those, then the commit is
clean.

I'm hoping the tigris folks are working on this issue.

-- Rick C. Petty
From danny at cs.huji.ac.il  Fri Dec 12 08:14:08 2008
From: danny at cs.huji.ac.il (Danny Braniss)
Date: Fri Dec 12 08:14:15 2008
Subject: preventing FIFO from EOF 
In-Reply-To: <49426B64.1070004@mail.ru> 
References: <494235CA.2050101@mail.ru> <E1LB7zz-0006kU-SU@kabab.cs.huji.ac.il>
	<49426B64.1070004@mail.ru>
Message-ID: <E1LBAeU-00086X-I3@kabab.cs.huji.ac.il>

> Danny Braniss wrote:
> >> $ mkfifo /var/tmp/foo
> >> $ buffer -i /var/tmp/foo                    # misc/buffer
> >> # in another console:
> >> $ echo hi > /var/tmp/foo
> >>
> >> buffer prints hi and exits. I want it to keep reading and printing 
> >> indefinitely.
> >>
> >> Further experimentation revealed that I need two writers: one dummy 
> >> writer that just keeps /var/tmp/foo open for writing, and the other 
> >> doing the "real work". This way buffer wouldn't exit. But how to emulate 
> >> the dummy writer? It itself needs to block on something to keep 
> >> /var/tmp/foo open. Any clean way to do this in shell? Maybe the solution 
> >> is quite simple but isn't at the tip of my tongue.
> >>
> >> Thanks.
> > 
> > too easy
> > n csh:
> > 	while 1
> > 		buffer -i /var/tmp/foo 
> > 	end
> > or in sh:
> > 	while true; do
> > 		buffer -i /var/tmp/foo
> > 	done
> > 
> 
> > Thanks, but I should have said that buffer must always run to never miss any data. 
> 
> The reason being that buffer's output gets fed into another program that 
> shouldn't be restarted.

use 'tail -f' instead of 'buffer -i' then, or place the while in file
and execute that. BTW, buffer was written way back when memory was measured
in kilobytes and the ethernet was 10 mgb, so things have changed a bit, and
its effectivness is questionable :-)

danny


From kientzle at freebsd.org  Fri Dec 12 08:21:30 2008
From: kientzle at freebsd.org (Tim Kientzle)
Date: Fri Dec 12 08:21:37 2008
Subject: Strange "changed paths" in svn commits
In-Reply-To: <20081212155833.GB82667@keira.kiwi-computer.com>
References: <9e20d71e0812120315l30d72b2doc899a8163fde829f@mail.gmail.com>
	<20081212155833.GB82667@keira.kiwi-computer.com>
Message-ID: <49428F85.7030701@freebsd.org>

Rick C. Petty wrote:
> On Fri, Dec 12, 2008 at 01:15:17PM +0200, Artis Caune wrote:
> 
> I suspect you've run into a well-known svn bug that affects "svn merge".  I
> thought they had fixed it with subversion 1.5.4, but apparently it's still
> around.  When doing a merge, it seems to randomly touch a bunch of files..
> it only updates the svn:mergeinfo property on those files  ...

I've seen this happen only once and eventually figured
out that I had a partial checkout underneath the merge point.
It was especially confusing in my case because I actually
had a complete checkout---nothing was missing---but
one of the directories was marked "depth=immediates"
so it was treated as a partial checkout.

If the svn:mergeinfo has asterisks in it, this is why.

Tim
From danny at cs.huji.ac.il  Fri Dec 12 09:47:40 2008
From: danny at cs.huji.ac.il (Danny Braniss)
Date: Fri Dec 12 09:47:47 2008
Subject: preventing FIFO from EOF 
In-Reply-To: <49429027.8060701@mail.ru> 
References: <494235CA.2050101@mail.ru> <E1LB7zz-0006kU-SU@kabab.cs.huji.ac.il>
	<49426B64.1070004@mail.ru> <E1LBAeU-00086X-I3@kabab.cs.huji.ac.il> 
	<49429027.8060701@mail.ru>
Message-ID: <E1LBC70-0008qm-Gl@kabab.cs.huji.ac.il>

> > BTW, buffer was written way back when memory was measured
> > in kilobytes and the ethernet was 10 mgb, so things have changed a bit, and
> > its effectivness is questionable :-)
> > 
> My scenario:
> 
> prog1 | prog2
> 
> where both are daemons. prog1 does all the work, and sends commands for 
> prog2 to do when needed. I don't want prog1 to block while prog2 is busy 
> executing the command. So a buffer is inserted between the two:
> 
> prog1 | buffer | prog2
> 
> Asynchronous execution of commands. It's as simple as that.

ahh, but you see, you have now 4 processes, which the scheduler has no
real reason to treat specialy, each can block. Then again, I have
no idea how much data you are moving around, and how fast you need
to process it. buffer was designed to keep a magnetic tape writing
at full speed - streaming, or at least for some longer time.
then again, there is nothing better than trying it out, instead
of out guessing the os :-)

cheers,
	danny


From rihad at mail.ru  Fri Dec 12 05:42:21 2008
From: rihad at mail.ru (rihad)
Date: Fri Dec 12 10:22:49 2008
Subject: preventing FIFO from EOF
In-Reply-To: <E1LB7zz-0006kU-SU@kabab.cs.huji.ac.il>
References: <494235CA.2050101@mail.ru> <E1LB7zz-0006kU-SU@kabab.cs.huji.ac.il>
Message-ID: <49426A3A.4070806@mail.ru>

Danny Braniss wrote:
>> $ mkfifo /var/tmp/foo
>> $ buffer -i /var/tmp/foo                    # misc/buffer
>> # in another console:
>> $ echo hi > /var/tmp/foo
>>
>> buffer prints hi and exits. I want it to keep reading and printing 
>> indefinitely.
>>
>> Further experimentation revealed that I need two writers: one dummy 
>> writer that just keeps /var/tmp/foo open for writing, and the other 
>> doing the "real work". This way buffer wouldn't exit. But how to emulate 
>> the dummy writer? It itself needs to block on something to keep 
>> /var/tmp/foo open. Any clean way to do this in shell? Maybe the solution 
>> is quite simple but isn't at the tip of my tongue.
>>
>> Thanks.
> 
> too easy
> n csh:
> 	while 1
> 		buffer -i /var/tmp/foo 
> 	end
> or in sh:
> 	while true; do
> 		buffer -i /var/tmp/foo
> 	done
> 
Thanks, but I should have said that buffer must always run to never miss 
any data.
From rihad at mail.ru  Fri Dec 12 05:47:20 2008
From: rihad at mail.ru (rihad)
Date: Fri Dec 12 10:33:38 2008
Subject: preventing FIFO from EOF
In-Reply-To: <E1LB7zz-0006kU-SU@kabab.cs.huji.ac.il>
References: <494235CA.2050101@mail.ru> <E1LB7zz-0006kU-SU@kabab.cs.huji.ac.il>
Message-ID: <49426B64.1070004@mail.ru>

Danny Braniss wrote:
>> $ mkfifo /var/tmp/foo
>> $ buffer -i /var/tmp/foo                    # misc/buffer
>> # in another console:
>> $ echo hi > /var/tmp/foo
>>
>> buffer prints hi and exits. I want it to keep reading and printing 
>> indefinitely.
>>
>> Further experimentation revealed that I need two writers: one dummy 
>> writer that just keeps /var/tmp/foo open for writing, and the other 
>> doing the "real work". This way buffer wouldn't exit. But how to emulate 
>> the dummy writer? It itself needs to block on something to keep 
>> /var/tmp/foo open. Any clean way to do this in shell? Maybe the solution 
>> is quite simple but isn't at the tip of my tongue.
>>
>> Thanks.
> 
> too easy
> n csh:
> 	while 1
> 		buffer -i /var/tmp/foo 
> 	end
> or in sh:
> 	while true; do
> 		buffer -i /var/tmp/foo
> 	done
> 

> Thanks, but I should have said that buffer must always run to never miss any data. 

The reason being that buffer's output gets fed into another program that 
shouldn't be restarted.
From rihad at mail.ru  Fri Dec 12 06:12:47 2008
From: rihad at mail.ru (rihad)
Date: Fri Dec 12 10:33:48 2008
Subject: preventing FIFO from EOF
In-Reply-To: <49426C40.6050802@gmx.de>
References: <494235CA.2050101@mail.ru> <49426C40.6050802@gmx.de>
Message-ID: <4942715B.7090509@mail.ru>

Christoph Mallon wrote:
> rihad schrieb:

> Something as simple as this:
> $ sh < /dev/null > /var/tmp/kick 2>/dev/null
> seems to block indefinitely, but exits as soon as I run
> $ buffer -i /var/tmp/foo
> (and buffer exits too) 

Strangely enough, something as stupid as this does the trick:
sh < /dev/stdout > /var/tmp/kick 2>/dev/null

i.e. reading from stdout blocks. Now sh keeps buffer block on 
/var/tmp/kick and never exit ;) I'm not sure what this does or why and 
how it works Unix-wise.
From rihad at mail.ru  Fri Dec 12 07:48:10 2008
From: rihad at mail.ru (rihad)
Date: Fri Dec 12 10:33:57 2008
Subject: preventing FIFO from EOF
In-Reply-To: <49426C40.6050802@gmx.de>
References: <494235CA.2050101@mail.ru> <49426C40.6050802@gmx.de>
Message-ID: <49427027.60800@mail.ru>

Christoph Mallon wrote:
> rihad schrieb:
>> $ mkfifo /var/tmp/foo
>> $ buffer -i /var/tmp/foo                    # misc/buffer
>> # in another console:
>> $ echo hi > /var/tmp/foo
>>
>> buffer prints hi and exits. I want it to keep reading and printing 
>> indefinitely.
>>
>> Further experimentation revealed that I need two writers: one dummy 
>> writer that just keeps /var/tmp/foo open for writing, and the other 
>> doing the "real work". This way buffer wouldn't exit. But how to 
>> emulate the dummy writer? It itself needs to block on something to 
>> keep /var/tmp/foo open. Any clean way to do this in shell? Maybe the 
>> solution is quite simple but isn't at the tip of my tongue.
> 
> Maybe "tail -f" is what you are looking for.
> 
> 
You mean in place of buffer? buffer is there for a reason (so that 
writers never block).

Something as simple as this:
$ sh < /dev/null > /var/tmp/kick 2>/dev/null
seems to block indefinitely, but exits as soon as I run
$ buffer -i /var/tmp/foo
(and buffer exits too)
From rihad at mail.ru  Fri Dec 12 08:24:11 2008
From: rihad at mail.ru (rihad)
Date: Fri Dec 12 10:34:06 2008
Subject: preventing FIFO from EOF
In-Reply-To: <E1LBAeU-00086X-I3@kabab.cs.huji.ac.il>
References: <494235CA.2050101@mail.ru> <E1LB7zz-0006kU-SU@kabab.cs.huji.ac.il>
	<49426B64.1070004@mail.ru> <E1LBAeU-00086X-I3@kabab.cs.huji.ac.il>
Message-ID: <49429027.8060701@mail.ru>

> BTW, buffer was written way back when memory was measured
> in kilobytes and the ethernet was 10 mgb, so things have changed a bit, and
> its effectivness is questionable :-)
> 
My scenario:

prog1 | prog2

where both are daemons. prog1 does all the work, and sends commands for 
prog2 to do when needed. I don't want prog1 to block while prog2 is busy 
executing the command. So a buffer is inserted between the two:

prog1 | buffer | prog2

Asynchronous execution of commands. It's as simple as that.
From rick-freebsd2008 at kiwi-computer.com  Fri Dec 12 10:39:33 2008
From: rick-freebsd2008 at kiwi-computer.com (Rick C. Petty)
Date: Fri Dec 12 10:39:40 2008
Subject: Strange "changed paths" in svn commits
In-Reply-To: <49428F85.7030701@freebsd.org>
References: <9e20d71e0812120315l30d72b2doc899a8163fde829f@mail.gmail.com>
	<20081212155833.GB82667@keira.kiwi-computer.com>
	<49428F85.7030701@freebsd.org>
Message-ID: <20081212183931.GC82667@keira.kiwi-computer.com>

On Fri, Dec 12, 2008 at 08:21:25AM -0800, Tim Kientzle wrote:
> Rick C. Petty wrote:
> >On Fri, Dec 12, 2008 at 01:15:17PM +0200, Artis Caune wrote:
> >
> >I suspect you've run into a well-known svn bug that affects "svn merge".  I
> >thought they had fixed it with subversion 1.5.4, but apparently it's still
> >around.  When doing a merge, it seems to randomly touch a bunch of files..
> >it only updates the svn:mergeinfo property on those files  ...
> 
> I've seen this happen only once and eventually figured
> out that I had a partial checkout underneath the merge point.
> It was especially confusing in my case because I actually
> had a complete checkout---nothing was missing---but
> one of the directories was marked "depth=immediates"
> so it was treated as a partial checkout.
> 
> If the svn:mergeinfo has asterisks in it, this is why.

In my case, I had a fresh copy that I merged a single file into, but it
touched 5 other random files; files I had never seen, much less ever
edited.  We've seen this behavior for weeks, but the rate of occurances
dropped significantly with svn 1.5.4-- dropped, not disappeared completely.

-- Rick C. Petty
From patfbsd at davenulle.org  Fri Dec 12 14:57:39 2008
From: patfbsd at davenulle.org (Patrick =?ISO-8859-15?Q?Lamaizi=E8re?=)
Date: Fri Dec 12 14:57:47 2008
Subject: crypto(9) choose another driver if we cannot open a session on
 it
In-Reply-To: <494047CB.6050400@freebsd.org>
References: <20081207224551.13ca3590@baby-jane>
	<20081208202155.GA7403@detritus.paeps.cx>
	<20081210233440.41bd1c47@baby-jane> <494047CB.6050400@freebsd.org>
Message-ID: <20081212235735.7deaea52@baby-jane>

Le Wed, 10 Dec 2008 14:50:51 -0800,
Sam Leffler <sam@freebsd.org> a ?crit :

Hello,

> > Which code exactly? Yes I'm curious :-)
> >
> > I'm thinking about how to remove the need for a device to support
> > all the algorithms when we open a session. By using a fake "crypto
> > virtual device" to open and dispatch crypto requests to real
> > devices or to cryptosoft. But i don't have any code to show yet.
> >
> > There is one thing I'm asking about crypto(9):
> > - I doubt that the migration of a session is safe and I think that
> > would be far easier to prevent a driver to unregister when there are
> > some pending sessions on it? glxsb and padlock do not allow to
> > unregister in this case. 
> >
> > I've looked quickly the code of geli or ipsec. If the crypto
> > framework returns EAGAIN because the migration of the session, they
> > restart a crypto_dispatch(crp) but the datas in crp->crp_buf can be
> > corrupted by the previous crypto operation (IMHO, may be i've missed
> > something)?
> >   
> This sounds like the session management layer I wanted to insert a
> while back.  It was a reason why I made the s/w driver into a pseudo
> device (so there'd be a handle). 

That is the easiest way to do, i think.

> As to unregister that was designed for devices like cardbus cards
> that might go away.  About the only way to simulate it today is to
> unload a driver module.  But it should work; if you see an issue we
> should try to fix it.

Ok, thank you. I will try to tests it.

>  OTOH the limitations of the existing crypto
> code are dramatic and the rationale for maintaining the obsd api's
> (both in kernel and user space) are no longer valid.  It would be
> good to see someone take this stuff and overhaul it to do things like:
> 
> o add a session management layer that falls back to s/w when a device
>    is incapable and when operations are more efficiently done in s/w
> (e.g ops too small to incur the dma setup/overhead)
> o do load balancing over multiple devices
> o support cpu resources as pseudo drivers (e.g. pin a thread to a cpu)
> o replace the bogus fd session crud w/ device cloning
> 
> The linux folks have done some of this and there may be lessons to be 
> learned from their efforts.  FWIW netbsd has some recent user api 
> changes for doing async ops and batching to speedup openssl etc; if 
> you're going to get into this stuff you might take a look.

I don't know enough the kernel to make a revolution. Anyway I can make
some evolutions and try to help. Is there someone working on the
crypto framework ?

Regards.
From yonyossef.lists at gmail.com  Sun Dec 14 08:18:35 2008
From: yonyossef.lists at gmail.com (Yony Yossef)
Date: Sun Dec 14 08:18:47 2008
Subject: Detecting network memory leaks using netstat -m
Message-ID: <000001c95e07$9a00b750$220f000a@mtl.com>

Hi All,
 
I'm trying to find out whether my ethernet driver is leaking.
I just found out about netstat -m, but I don't understand some of it's
output.
 
Can somebody explain me what is "mbuf+clusters out of packet secondary zone
in use" ?
My output shows it raised significantly during equilibrium after several
stress runs:
 
BEFORE
 
16641/217734/234375 mbufs in use (current/cache/total)
16640/217766/234406/262144 mbuf clusters in use (current/cache/total/max)
256/1664 mbuf+clusters out of packet secondary zone in use (current/cache)
 
AFTER
 
625083/86562/711645 mbufs in use (current/cache/total)
180264/81880/262144/262144 mbuf clusters in use (current/cache/total/max)
160420/311 mbuf+clusters out of packet secondary zone in use (current/cache)
 
Thanks
Yony
 
From yoniy at mellanox.co.il  Sun Dec 14 08:16:23 2008
From: yoniy at mellanox.co.il (Yehonatan Yossef)
Date: Sun Dec 14 08:39:47 2008
Subject: Detecting network memory leaks using netstat -m
In-Reply-To: <877i6ct1kj.fsf@kobe.laptop>
References: <20def4870812070756n649f442fwc6e1d3da195a0669@mail.gmail.com>
	<877i6ct1kj.fsf@kobe.laptop>
Message-ID: <5D49E7A8952DC44FB38C38FA0D758EAD01335E8C@mtlexch01.mtl.com>

Hi All,

I'm trying to find out whether my ethernet driver is leaking.
I just found out about netstat -m, but I don't understand some of it's
output.

Can somebody explain me what is "mbuf+clusters out of packet secondary
zone in use" ?
My output shows it raised significantly during equilibrium after several
stress runs:

BEFORE

16641/217734/234375 mbufs in use (current/cache/total)
16640/217766/234406/262144 mbuf clusters in use
(current/cache/total/max)
256/1664 mbuf+clusters out of packet secondary zone in use
(current/cache)

AFTER

625083/86562/711645 mbufs in use (current/cache/total)
180264/81880/262144/262144 mbuf clusters in use
(current/cache/total/max)
160420/311 mbuf+clusters out of packet secondary zone in use
(current/cache)

Thanks
Yony
From ravi.murty at gmail.com  Sun Dec 14 21:03:19 2008
From: ravi.murty at gmail.com (Ravi Murty)
Date: Sun Dec 14 21:03:26 2008
Subject: td_critnest
Message-ID: <95b10a340812142103u3ab8bd2br97033a7c7e8bec3@mail.gmail.com>

Hello All,

The implementation of critical_enter and critical_exit changed between
freebsd 5 and freebsd 6. In the newer implemtnation, the code checks if
td_critnest is 1 and if it is sets it to zero, then checks if the thread
owes a preempt. If so, it increments td_critnest by 1 before grabbing a lock
and then decrements it back to zero. I can't figure out why it does this.
The freebsd 5 implementation seems straightforward where we check if the
thread owes a preempt and if so we switch to the new thread. Can anyone help
me with this?

Thanks
Ravi
From delphij at delphij.net  Sun Dec 14 21:42:57 2008
From: delphij at delphij.net (Xin LI)
Date: Sun Dec 14 21:43:04 2008
Subject: td_critnest
In-Reply-To: <95b10a340812142103u3ab8bd2br97033a7c7e8bec3@mail.gmail.com>
References: <95b10a340812142103u3ab8bd2br97033a7c7e8bec3@mail.gmail.com>
Message-ID: <4945EE55.2050401@delphij.net>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ravi Murty wrote:
> Hello All,
> 
> The implementation of critical_enter and critical_exit changed between
> freebsd 5 and freebsd 6. In the newer implemtnation, the code checks if
> td_critnest is 1 and if it is sets it to zero, then checks if the thread
> owes a preempt. If so, it increments td_critnest by 1 before grabbing a lock
> and then decrements it back to zero. I can't figure out why it does this.
> The freebsd 5 implementation seems straightforward where we check if the
> thread owes a preempt and if so we switch to the new thread. Can anyone help
> me with this?

My guess is to prevent race conditions (i.e. to split the owepreempt
flag into a separate variable), since this value could be changed in an
interrupt context, and not only during the current thread context.

Cheers,
- --
Xin LI <delphij@delphij.net>	http://www.delphij.net/
FreeBSD - The Power to Serve!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (FreeBSD)

iEYEARECAAYFAklF7lUACgkQi+vbBBjt66C0sQCeOZCFZu4VBTRk3it4/424pAbc
LRoAoLfdoS09ZX2SSZ1Z/SOw+rqkrkQ0
=P2Ez
-----END PGP SIGNATURE-----
From vasanth.raonaik at gmail.com  Mon Dec 15 01:27:15 2008
From: vasanth.raonaik at gmail.com (vasanth raonaik)
Date: Mon Dec 15 01:27:23 2008
Subject: simulate ntp leap second adjustments
Message-ID: <d9f479c10812150127n5dcebbf8kcd69fbec717a252e@mail.gmail.com>

I would like to test the behavior of ntpd during leap second adjustments.
Could any one please help me how to simulate the scenario locally to test if
ntpd works fine.

Thanks,
Vasanth
From avg at icyb.net.ua  Mon Dec 15 04:08:27 2008
From: avg at icyb.net.ua (Andriy Gapon)
Date: Mon Dec 15 04:08:34 2008
Subject: memtest86+ on freebsd
In-Reply-To: <4942483D.8000003@icyb.net.ua>
References: <4909DC03.1080901@icyb.net.ua>
	<20081030184625.GA99398@server.vk2pj.dyndns.org>
	<490B05BA.9090306@icyb.net.ua> <4942483D.8000003@icyb.net.ua>
Message-ID: <494648AF.6010009@icyb.net.ua>

on 12/12/2008 13:17 Andriy Gapon said the following:
> Just in case anybody still remembers this issue.
> It seams that the main culprit here was the following line in the linker
> script:
> 
> OUTPUT_FORMAT("elf32-i386");
> 
> I was tipped just today that it should have read:
> OUTPUT_FORMAT("elf32-i386-freebsd", "elf32-i386-freebsd",
> "elf32-i386-freebsd");

In fact it was Stephan Eisvogel who provided me with this hint.
He has also kindly pointed me to his version of memtest86+ for FreeBSD
that not only has porting changes but also some functional
changes/enhancements as well:
http://seitics.de/pub/memtest/

Stephan has also offered/suggested the following:
> If there is sufficient interest I could be persuaded to donate
> our Forth triple boot menu code that we use in our own products
> (primary FreeBSD partition, secondary dito, memtest) to help
> FreeBSD gain memtest on boot.

I personally think that this sounds cool, especially for certain kinds
of applications.


And just for the reference I am attaching my minimal patch that allows
memtest86+ to compile on FreeBSD. I haven't tested the result though.
I have some doubts about .code32 change in setup.S.
Also I see that Stephan changed memtest.lds so that
. = 0x10000;
became
. = 0xc0120000;

-- 
Andriy Gapon
-------------- next part --------------
diff -rup memtest86+-2.01/error.c memtest86+-2.01/error.c
--- memtest86+-2.01/error.c	2008-02-21 13:26:05.000000000 +0200
+++ memtest86+-2.01/error.c	2008-12-12 13:15:00.943778766 +0200
@@ -11,7 +11,6 @@
  
 #include "test.h"
 #include "config.h"
-#include <sys/io.h>
 #include "dmi.h"
 
 extern int test_ticks, nticks, beepmode;
diff -rup memtest86+-2.01/memtest.lds memtest86+-2.01/memtest.lds
--- memtest86+-2.01/memtest.lds	2008-02-21 13:26:05.000000000 +0200
+++ memtest86+-2.01/memtest.lds	2008-12-12 13:09:07.993226296 +0200
@@ -1,4 +1,4 @@
-OUTPUT_FORMAT("elf32-i386");
+OUTPUT_FORMAT("elf32-i386-freebsd", "elf32-i386-freebsd", "elf32-i386-freebsd");
 OUTPUT_ARCH(i386);
 
 ENTRY(_start); 
diff -rup memtest86+-2.01/memtest_shared.lds memtest86+-2.01/memtest_shared.lds
--- memtest86+-2.01/memtest_shared.lds	2008-02-21 13:26:05.000000000 +0200
+++ memtest86+-2.01/memtest_shared.lds	2008-12-12 13:09:19.184938804 +0200
@@ -1,4 +1,4 @@
-OUTPUT_FORMAT("elf32-i386");
+OUTPUT_FORMAT("elf32-i386-freebsd", "elf32-i386-freebsd", "elf32-i386-freebsd");
 OUTPUT_ARCH(i386);
 
 ENTRY(startup_32); 
diff -rup memtest86+-2.01/setup.S memtest86+-2.01/setup.S
--- memtest86+-2.01/setup.S	2008-02-21 13:26:05.000000000 +0200
+++ memtest86+-2.01/setup.S	2008-12-12 13:16:48.404989746 +0200
@@ -42,7 +42,9 @@ start:
 	jz	alt_a20_done
 	
 	/* set or clear bit1, the ALT_A20_GATE bit */
+	.code32
 	movb	4(%esp), %ah
+	.code16
 	testb	%ah, %ah
 	jz	alt_a20_cont1
 	orb	$2, %al
diff -rup memtest86+-2.01/test.c memtest86+-2.01/test.c
--- memtest86+-2.01/test.c	2008-02-21 13:26:05.000000000 +0200
+++ memtest86+-2.01/test.c	2008-12-12 13:14:06.257361411 +0200
@@ -9,9 +9,10 @@
  * http://www.x86-secret.com - http://www.memtest.org
  */
 
+#include <sys/types.h>
+#include <machine/cpufunc.h>
 #include "test.h"
 #include "config.h"
-#include <sys/io.h>
 #include "dmi.h"
 
 extern int segs, bail;
@@ -1407,18 +1408,18 @@ void beep(unsigned int frequency)
 	unsigned int count = 1193180 / frequency;
 
 	// Switch on the speaker
-	outb_p(inb_p(0x61)|3, 0x61);
+	outb(0x61, inb(0x61)|3);
 
 	// Set command for counter 2, 2 byte write
-	outb_p(0xB6, 0x43);
+	outb(0x43, 0xB6);
 
 	// Select desired Hz
-	outb_p(count & 0xff, 0x42);
-	outb((count >> 8) & 0xff, 0x42);
+	outb(0x42, count & 0xff);
+	outb(0x42, (count >> 8) & 0xff);
 
 	// Block for 100 microseconds
 	sleep(100, 1);
 
 	// Switch off the speaker
-	outb(inb_p(0x61)&0xFC, 0x61);
+	outb(0x61, inb(0x61)&0xFC);
 }
From vasanth.raonaik at gmail.com  Mon Dec 15 05:07:27 2008
From: vasanth.raonaik at gmail.com (vasanth raonaik)
Date: Mon Dec 15 05:07:34 2008
Subject: ntpd
Message-ID: <d9f479c10812150507g578cb7f8ldfeb5b61f1cc2a54@mail.gmail.com>

hello hackers,

I am looking into the ntpd code. I need to know in which file and function
does ntpd reply/reponse query packets are formulated. Please provide any
pointers for the same.

Thanks,
Vasanth
From max at love2party.net  Mon Dec 15 05:19:00 2008
From: max at love2party.net (Max Laier)
Date: Mon Dec 15 05:19:07 2008
Subject: ntpd
In-Reply-To: <d9f479c10812150507g578cb7f8ldfeb5b61f1cc2a54@mail.gmail.com>
References: <d9f479c10812150507g578cb7f8ldfeb5b61f1cc2a54@mail.gmail.com>
Message-ID: <200812151418.58169.max@love2party.net>

On Monday 15 December 2008 14:07:26 vasanth raonaik wrote:
> I am looking into the ntpd code. I need to know in which file and function
> does ntpd reply/reponse query packets are formulated. Please provide any
> pointers for the same.

I don't know what "query packets" are supposed to be in the NTP context, but 
it looks like you are looking for ntp_proto.c - convenient name, isn't it? ;)

-- 
/"\  Best regards,                      | mlaier@freebsd.org
\ /  Max Laier                          | ICQ #67774661
 X   http://pf4freebsd.love2party.net/  | mlaier@EFnet
/ \  ASCII Ribbon Campaign              | Against HTML Mail and News
From vasanth.raonaik at gmail.com  Mon Dec 15 05:26:55 2008
From: vasanth.raonaik at gmail.com (vasanth raonaik)
Date: Mon Dec 15 05:27:02 2008
Subject: ntpd
In-Reply-To: <200812151418.58169.max@love2party.net>
References: <d9f479c10812150507g578cb7f8ldfeb5b61f1cc2a54@mail.gmail.com>
	<200812151418.58169.max@love2party.net>
Message-ID: <d9f479c10812150526r236e7c02j67bf5ce588ce9ec7@mail.gmail.com>

Thanks for your reply Max. I will start from that file and let you know if I
need more info.

Thanks,
Vasanth
From rea-fbsd at codelabs.ru  Mon Dec 15 06:27:15 2008
From: rea-fbsd at codelabs.ru (Eygene Ryabinkin)
Date: Mon Dec 15 06:27:22 2008
Subject: memtest86+ on freebsd
In-Reply-To: <494648AF.6010009@icyb.net.ua>
References: <4909DC03.1080901@icyb.net.ua>
	<20081030184625.GA99398@server.vk2pj.dyndns.org>
	<490B05BA.9090306@icyb.net.ua> <4942483D.8000003@icyb.net.ua>
	<494648AF.6010009@icyb.net.ua>
Message-ID: <UtxGBGuVuemk8OcS1gDPEw78Aok@VULTLOHGNlPnB6yOjbBvjMB9mrA>

Andriy, good day.

Mon, Dec 15, 2008 at 02:08:15PM +0200, Andriy Gapon wrote:
> on 12/12/2008 13:17 Andriy Gapon said the following:
> > Just in case anybody still remembers this issue.
> > It seams that the main culprit here was the following line in the linker
> > script:
> > 
> > OUTPUT_FORMAT("elf32-i386");
> > 
> > I was tipped just today that it should have read:
> > OUTPUT_FORMAT("elf32-i386-freebsd", "elf32-i386-freebsd",
> > "elf32-i386-freebsd");
> 
> In fact it was Stephan Eisvogel who provided me with this hint.

Yes, it is a somewhat known culprit.  A number of packages that are
messing with assembly code have troubles due to this directive.  The
better way to overcome this issue is not to patch linker scripts, but to
override object format via '--oformat elf32-i386-freebsd' command-line
switch to ld(1).  With this your proposed patch could be made even
smaller, providing that you can override linker command-line switches,
and it will be more robust in respect to the patching troubles when
linker scripts will be changed.
-- 
Eygene
 _                ___       _.--.   #
 \`.|\..----...-'`   `-._.-'_.-'`   #  Remember that it is hard
 /  ' `         ,       __.--'      #  to read the on-line manual   
 )/' _/     \   `-_,   /            #  while single-stepping the kernel.
 `-'" `"\_  ,_.-;_.-\_ ',  fsc/as   #
     _.-'_./   {_.'   ; /           #    -- FreeBSD Developers handbook 
    {_.-``-'         {_/            #
-------------- 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-hackers/attachments/20081215/8a2373c5/attachment.pgp
From avg at icyb.net.ua  Mon Dec 15 06:39:00 2008
From: avg at icyb.net.ua (Andriy Gapon)
Date: Mon Dec 15 06:39:08 2008
Subject: memtest86+ on freebsd
In-Reply-To: <UtxGBGuVuemk8OcS1gDPEw78Aok@VULTLOHGNlPnB6yOjbBvjMB9mrA>
References: <4909DC03.1080901@icyb.net.ua>
	<20081030184625.GA99398@server.vk2pj.dyndns.org>
	<490B05BA.9090306@icyb.net.ua> <4942483D.8000003@icyb.net.ua>
	<494648AF.6010009@icyb.net.ua>
	<UtxGBGuVuemk8OcS1gDPEw78Aok@VULTLOHGNlPnB6yOjbBvjMB9mrA>
Message-ID: <49466B9E.1090900@icyb.net.ua>

on 15/12/2008 16:27 Eygene Ryabinkin said the following:
> Andriy, good day.
> 
> Mon, Dec 15, 2008 at 02:08:15PM +0200, Andriy Gapon wrote:
>> on 12/12/2008 13:17 Andriy Gapon said the following:
>>> Just in case anybody still remembers this issue.
>>> It seams that the main culprit here was the following line in the linker
>>> script:
>>>
>>> OUTPUT_FORMAT("elf32-i386");
>>>
>>> I was tipped just today that it should have read:
>>> OUTPUT_FORMAT("elf32-i386-freebsd", "elf32-i386-freebsd",
>>> "elf32-i386-freebsd");
>> In fact it was Stephan Eisvogel who provided me with this hint.
> 
> Yes, it is a somewhat known culprit.  A number of packages that are
> messing with assembly code have troubles due to this directive.  The
> better way to overcome this issue is not to patch linker scripts, but to
> override object format via '--oformat elf32-i386-freebsd' command-line
> switch to ld(1).  With this your proposed patch could be made even
> smaller, providing that you can override linker command-line switches,
> and it will be more robust in respect to the patching troubles when
> linker scripts will be changed.

Eygene,

thanks a lot! this option is indeed sufficient.

-- 
Andriy Gapon
From venkatb18 at gmail.com  Mon Dec 15 21:49:17 2008
From: venkatb18 at gmail.com (Venki B)
Date: Mon Dec 15 21:49:24 2008
Subject: [patch] Path MTU Discovery when routing over IPSec connections
Message-ID: <c215f13b0812152135l5b30ed6es4889d96642a9751e@mail.gmail.com>

Hi

Fallow this webpage:
http://www.ipsec-howto.org/x304.html
free bsd is similar to linux
Thanks,
--Venkatesh ?
From pluknet at gmail.com  Tue Dec 16 04:23:29 2008
From: pluknet at gmail.com (pluknet)
Date: Tue Dec 16 04:23:36 2008
Subject: PRINTF_BUFR_SIZE in freebsd6
Message-ID: <a31046fc0812160423g7508bdbdrb160e9d1ec12b6e3@mail.gmail.com>

Hi.

Could the PRINTF_BUFR_SIZE option be safely merged into RELENG_6 without
merging a possible underlining infrastructure and breaking something else?
I want to use it in my custom freebsd6 because I see "interspersed strings
written from different CPUs at the same time":

uuusseseerrvmrem: vlmivmeimtme :e mx:ceed eldi bly 2i89m68m (iihttt t
pde) eaxtx cfcorke1 22e3e
deded ebyd  by28 296898 68(h t(tpdh) att ftorkp1 22d3
) at fork1 223

I'm talking about only merging kern/subr_prf.c 1.126, 1.128, 1.129.

Thanks.

-- 
wbr,
pluknet
From avg at icyb.net.ua  Tue Dec 16 05:16:48 2008
From: avg at icyb.net.ua (Andriy Gapon)
Date: Tue Dec 16 05:16:54 2008
Subject: usb keyboard vs btx: an SMI theory
Message-ID: <4947AA3C.4040005@icyb.net.ua>


I am not a close-to-hardware guy, my knowledge of IA32 architecture and
IA32 assembly is very (very!) limited, so my reasoning can have some
glaring flaws. Also, I am quite fuzzy on the details of btx workings and
some other aspects.

Still I have a theory (or a "gut feeling") about the bad interaction
between "newer" loader and USB keyboard that I experienced. I believe
that a number other people had the same or similar issues.

It seems that i386 btx code contains routines, intx31/int_hw +
rret_tramp, to enter real mode, execute an interrupt handler and exit
real mode. It seems that this code can be invoked in two cases: (1) when
protected code wishes to execute a BIOS int function and calls into btx
via int 31h; (2) when a hardware interrupt happens while in protected mode.
It also looks that the routine saves and restores certain context before
entering and after exiting real mode. This is done in a special fixed
memory location (MEM_ESPR). This memory lcoation also seems to be used
as a stack base address for real mode.

Normally there can not be any shared/overlapping access to that
location. This is because in all cases interrupts are disabled and
machine is supposed to be uniprocessor mode still.

Now lets look at the other end - "USB legacy support". I think that BIOS
emulates PS/2 keyboard for real USB keyboard in the following way.
When a key is pressed a USB event is generated by the keyboard.
USB host controller generates an SMI upon the USB event.
SMM code checks if SMI was generated by USB, performs necessary USB
chores and then pretends as if the key press was made on an PS/2 keyboard.
This is something that I am very fuzzy about, but I think that SMM code
somehow invokes IRQ 1 handler.

And I think that because SMI is not maskable it can be "nested" inside
any other interrupt (software or hardware) and it is possible that IRQ1
handler for protected mode can be executed (and thus int_hw) while we
were already executing int_hw for some other reason -  a "system call"
from protected mode code or hardware interrupt.
In this case the context data stored in memory would get corrupted.
I suspect that what I actually observe looks like interrupts never
getting re-enabled.

Again, I am very fuzzy about the exact details, but I think that this is
something that could be happening and I think that SMI is of primary
interest here. I also think that this might explain to a certain degree
the difference in behavior between "older" btx and "newer" btx.


-- 
Andriy Gapon
From kostikbel at gmail.com  Tue Dec 16 05:40:44 2008
From: kostikbel at gmail.com (Kostik Belousov)
Date: Tue Dec 16 05:40:51 2008
Subject: PRINTF_BUFR_SIZE in freebsd6
In-Reply-To: <a31046fc0812160423g7508bdbdrb160e9d1ec12b6e3@mail.gmail.com>
References: <a31046fc0812160423g7508bdbdrb160e9d1ec12b6e3@mail.gmail.com>
Message-ID: <20081216134035.GU2038@deviant.kiev.zoral.com.ua>

On Tue, Dec 16, 2008 at 03:23:28PM +0300, pluknet wrote:
> Hi.
> 
> Could the PRINTF_BUFR_SIZE option be safely merged into RELENG_6 without
> merging a possible underlining infrastructure and breaking something else?
> I want to use it in my custom freebsd6 because I see "interspersed strings
> written from different CPUs at the same time":
> 
> uuusseseerrvmrem: vlmivmeimtme :e mx:ceed eldi bly 2i89m68m (iihttt t
> pde) eaxtx cfcorke1 22e3e
> deded ebyd  by28 296898 68(h t(tpdh) att ftorkp1 22d3
> ) at fork1 223
> 
> I'm talking about only merging kern/subr_prf.c 1.126, 1.128, 1.129.
> 
> Thanks.

I did a backport of the option some time ago, see
http://people.freebsd.org/~kib/misc/releng_6_printf_bufr.3.patch
-------------- 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-hackers/attachments/20081216/166bdb96/attachment.pgp
From lme at FreeBSD.org  Tue Dec 16 14:25:08 2008
From: lme at FreeBSD.org (Lars Engels)
Date: Tue Dec 16 14:25:15 2008
Subject: Small change to wc
In-Reply-To: <87ljut2jji.fsf@kobe.laptop>
References: <f4ecc0930812051414n17867e1fi80d6ed458e879bde@mail.gmail.com>
	<871vwmtawz.fsf@kobe.laptop>
	<f4ecc0930812051846n27308fbdue6ea50a909d8d6ab@mail.gmail.com>
	<87prk5ms72.fsf@kobe.laptop> <878wqtia75.fsf@kobe.laptop>
	<87ljut2jji.fsf@kobe.laptop>
Message-ID: <20081216222507.GP161@e.0x20.net>

On Sat, Dec 06, 2008 at 09:25:05PM +0200, Giorgos Keramidas wrote:
> On Sat, 06 Dec 2008 17:40:14 +0200, Giorgos Keramidas <keramida@ceid.upatras.gr> wrote:
> > The updated patch, and a manpage change to document the new option is
> > attached below.  Konstantin, if you like this version of the patch,
> > I'll commit it to /head and schedule an MFC after a week or so.
> 
> Committed to /head as change 185714:
> 
> http://svn.freebsd.org/viewvc/base?view=revision&revision=185714
> 
> Sheldon, thanks for the patch.  I will merge it to the stable branches
> after about a few days :-)

Yay, now we can add it to 7.1 release notes just like sun had "df now
supports -h" when Solaris 10 came out. ;-)
-------------- 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-hackers/attachments/20081216/e9942ecc/attachment.pgp
From keramida at freebsd.org  Tue Dec 16 15:00:20 2008
From: keramida at freebsd.org (Giorgos Keramidas)
Date: Tue Dec 16 15:00:28 2008
Subject: Small change to wc
In-Reply-To: <20081216222507.GP161@e.0x20.net> (Lars Engels's message of "Tue, 
	16 Dec 2008 23:25:07 +0100")
References: <f4ecc0930812051414n17867e1fi80d6ed458e879bde@mail.gmail.com>
	<871vwmtawz.fsf@kobe.laptop>
	<f4ecc0930812051846n27308fbdue6ea50a909d8d6ab@mail.gmail.com>
	<87prk5ms72.fsf@kobe.laptop> <878wqtia75.fsf@kobe.laptop>
	<87ljut2jji.fsf@kobe.laptop> <20081216222507.GP161@e.0x20.net>
Message-ID: <87zlivk9p6.fsf@kobe.laptop>

On Tue, 16 Dec 2008 23:25:07 +0100, Lars Engels <lme@FreeBSD.org> wrote:
>On Sat, Dec 06, 2008 at 09:25:05PM +0200, Giorgos Keramidas wrote:
>>On Sat, 06 Dec 2008 17:40:14 +0200, Giorgos Keramidas <keramida@ceid.upatras.gr> wrote:
>>> The updated patch, and a manpage change to document the new option is
>>> attached below.  Konstantin, if you like this version of the patch,
>>> I'll commit it to /head and schedule an MFC after a week or so.
>>
>> Committed to /head as change 185714:
>>
>> http://svn.freebsd.org/viewvc/base?view=revision&revision=185714
>>
>> Sheldon, thanks for the patch.  I will merge it to the stable branches
>> after about a few days :-)
>
> Yay, now we can add it to 7.1 release notes just like sun had "df now
> supports -h" when Solaris 10 came out. ;-)

I'm afraid it is too late for 7.1-RELEASE.  But it will be part of 7.2
for sure :)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20081216/d7bada1d/attachment.pgp
From Andre.Albsmeier at siemens.com  Tue Dec 16 15:20:35 2008
From: Andre.Albsmeier at siemens.com (Andre Albsmeier)
Date: Tue Dec 16 15:20:43 2008
Subject: How to "detach" a foreign driver from a device so my driver can
	attach?
Message-ID: <20081216230430.GA24352@curry.mchp.siemens.de>

Hello all,

I am writing a driver which attaches to the Host-PCI bridge. When
compiled into the kernel or loaded by the loader everything works
and the driver gets attached. This is due to the fact that I return
BUS_PROBE_SPECIFIC in my probe routine which gains over the -10000
returned by pci_hostb_probe() in i386/pci/pci_bus.c.

However, when I want to load my driver via kldload this fails since
the hostb device has already been attached during kernel load (when
my driver was not present):

hostb0@pci0:0:0:    class=0x060000 card=0x11d510cf chip=0x35808086 rev=0x02 hdr=0x00

What can I do to make my driver load via kldload?
Is there a way to detach the hostb0 from the Host-PCI bridge?
I have been digging around in the sources but didn't find
something similar.

In case of any hints, please CC me since I am currently travelling
and can't easily read the lists at home...

Thanks,

	-Andre
From v.haisman at sh.cvut.cz  Tue Dec 16 23:06:30 2008
From: v.haisman at sh.cvut.cz (=?UTF-8?B?VsOhY2xhdiBIYWlzbWFu?=)
Date: Tue Dec 16 23:07:14 2008
Subject: Small change to wc
In-Reply-To: <f4ecc0930812051414n17867e1fi80d6ed458e879bde@mail.gmail.com>
References: <f4ecc0930812051414n17867e1fi80d6ed458e879bde@mail.gmail.com>
Message-ID: <4948A4E7.8040706@sh.cvut.cz>

Sheldon Givens wrote, On 5.12.2008 23:14:
> Hello everyone,
> In the process of migrating the last of a few Linux servers to FreeBSD, we
> ran in to a bit of a snag with one of our scripts when BSD wc didn't have an
> equivalent to the Linux -L. This flag tells wc to keep track of the longest
> line in the input.
> 
> Here's a little diff to add this functionality to BSD wc.
> 
> With this patch, an additional parameter is added to output that shows the
> length of the longest line
> 
> My apologies if this is in the wrong format. I don't often post here.
> 
> Happy Holidays,
> 
> Sheldon Givens
>[...]
You can install sysutils/coreutils and use its gwc executable.

--
VH

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 219 bytes
Desc: OpenPGP digital signature
Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20081217/309babb3/signature.pgp
From pluknet at gmail.com  Wed Dec 17 02:48:12 2008
From: pluknet at gmail.com (pluknet)
Date: Wed Dec 17 02:48:18 2008
Subject: PRINTF_BUFR_SIZE in freebsd6
In-Reply-To: <20081216134035.GU2038@deviant.kiev.zoral.com.ua>
References: <a31046fc0812160423g7508bdbdrb160e9d1ec12b6e3@mail.gmail.com>
	<20081216134035.GU2038@deviant.kiev.zoral.com.ua>
Message-ID: <a31046fc0812170248g4fa19250j159c645bdcd4ac89@mail.gmail.com>

2008/12/16 Kostik Belousov <kostikbel@gmail.com>:
> On Tue, Dec 16, 2008 at 03:23:28PM +0300, pluknet wrote:
>> Hi.
>>
>> Could the PRINTF_BUFR_SIZE option be safely merged into RELENG_6 without
>> merging a possible underlining infrastructure and breaking something else?
>> I want to use it in my custom freebsd6 because I see "interspersed strings
>> written from different CPUs at the same time":
>>
>> uuusseseerrvmrem: vlmivmeimtme :e mx:ceed eldi bly 2i89m68m (iihttt t
>> pde) eaxtx cfcorke1 22e3e
>> deded ebyd  by28 296898 68(h t(tpdh) att ftorkp1 22d3
>> ) at fork1 223
>>
>> I'm talking about only merging kern/subr_prf.c 1.126, 1.128, 1.129.
>>
>> Thanks.
>
> I did a backport of the option some time ago, see
> http://people.freebsd.org/~kib/misc/releng_6_printf_bufr.3.patch
>

Thank you!

6.3 system panics (many page faults, one after another) early at boot
without the option, and boots with it in the QEMU environment.
Next step to test it on a real (and SMPable) hardware.

--
wbr,
pluknet
From pluknet at gmail.com  Wed Dec 17 05:52:39 2008
From: pluknet at gmail.com (pluknet)
Date: Wed Dec 17 05:52:46 2008
Subject: PRINTF_BUFR_SIZE in freebsd6
In-Reply-To: <a31046fc0812170248g4fa19250j159c645bdcd4ac89@mail.gmail.com>
References: <a31046fc0812160423g7508bdbdrb160e9d1ec12b6e3@mail.gmail.com>
	<20081216134035.GU2038@deviant.kiev.zoral.com.ua>
	<a31046fc0812170248g4fa19250j159c645bdcd4ac89@mail.gmail.com>
Message-ID: <a31046fc0812170552k31a7434cy9a13ea5c8322e94e@mail.gmail.com>

2008/12/17 pluknet <pluknet@gmail.com>:
> 2008/12/16 Kostik Belousov <kostikbel@gmail.com>:
>> On Tue, Dec 16, 2008 at 03:23:28PM +0300, pluknet wrote:
>>> Hi.
>>>
>>> Could the PRINTF_BUFR_SIZE option be safely merged into RELENG_6 without
>>> merging a possible underlining infrastructure and breaking something else?
>>> I want to use it in my custom freebsd6 because I see "interspersed strings
>>> written from different CPUs at the same time":
>>>
>>> uuusseseerrvmrem: vlmivmeimtme :e mx:ceed eldi bly 2i89m68m (iihttt t
>>> pde) eaxtx cfcorke1 22e3e
>>> deded ebyd  by28 296898 68(h t(tpdh) att ftorkp1 22d3
>>> ) at fork1 223
>>>
>>> I'm talking about only merging kern/subr_prf.c 1.126, 1.128, 1.129.
>>>
>>> Thanks.
>>
>> I did a backport of the option some time ago, see
>> http://people.freebsd.org/~kib/misc/releng_6_printf_bufr.3.patch
>>
>
> Thank you!
>
> 6.3 system panics (many page faults, one after another) early at boot
> without the option, and boots with it in the QEMU environment.
> Next step to test it on a real (and SMPable) hardware.
>

Now tested on a real 2xXeon 3.0 w/ HTT enabled w/ PRINTF_BUFR_SIZE enabled.

Received the following panic:

Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address   = 0x72
fault code              = supervisor read, page not present
instruction pointer     = 0x20:0xc07fc8c3
stack pointer           = 0x28:0xe4f56a78
frame pointer           = 0x28:0xe4f56b44
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         = 14 (swi4: clock sio)
[thread pid 14 tid 100002 ]
Stopped at      vm_fault+0x1e3: cmpw    $0,0x72(%eax)
db> bt
Tracing pid 14 tid 100002 td 0xc63e9c80
vm_fault(c1066000,c009e000,2,0) at vm_fault+0x1e3
trap_pfault(e4f56bb0,0,c009effe) at trap_pfault+0x137
trap(410008,c63e0028,e4f50028,c009effe,c638effe,...) at trap+0x325
calltrap() at calltrap+0x5
--- trap 0xc, eip = 0xc08a2cad, esp = 0xe4f56bf0, ebp = 0xe4f56c10 ---
generic_bcopy(c0a63a68,7cf,c0a63a4c,7cf,fffff832) at generic_bcopy+0x41
vga_txtdraw(c0a63a40,7cf,fffff832,0) at vga_txtdraw+0xbe
scrn_update(c0a63a40,1) at scrn_update+0x22d
scrn_timer(c0a6c1e0) at scrn_timer+0x1e0
softclock(0) at softclock+0x1f4
ithread_execute_handlers(c63e8460,c6629800) at ithread_execute_handlers+0xd6
ithread_loop(c63a7910,e4f56d38,c0a10040,0,c0922ea6,...) at ithread_loop+0x53
fork_exit(c068d158,c63a7910,e4f56d38) at fork_exit+0x61
fork_trampoline() at fork_trampoline+0x8
--- trap 0x1, eip = 0, esp = 0xe4f56d6c, ebp = 0 ---
db>
From onemda at gmail.com  Wed Dec 17 06:10:30 2008
From: onemda at gmail.com (Paul B. Mahol)
Date: Wed Dec 17 06:10:38 2008
Subject: PRINTF_BUFR_SIZE in freebsd6
In-Reply-To: <a31046fc0812170552k31a7434cy9a13ea5c8322e94e@mail.gmail.com>
References: <a31046fc0812160423g7508bdbdrb160e9d1ec12b6e3@mail.gmail.com>
	<20081216134035.GU2038@deviant.kiev.zoral.com.ua>
	<a31046fc0812170248g4fa19250j159c645bdcd4ac89@mail.gmail.com>
	<a31046fc0812170552k31a7434cy9a13ea5c8322e94e@mail.gmail.com>
Message-ID: <3a142e750812170610r25a48762y845010c6898f52d4@mail.gmail.com>

On 12/17/08, pluknet <pluknet@gmail.com> wrote:
> 2008/12/17 pluknet <pluknet@gmail.com>:
>> 2008/12/16 Kostik Belousov <kostikbel@gmail.com>:
>>> On Tue, Dec 16, 2008 at 03:23:28PM +0300, pluknet wrote:
>>>> Hi.
>>>>
>>>> Could the PRINTF_BUFR_SIZE option be safely merged into RELENG_6 without
>>>> merging a possible underlining infrastructure and breaking something
>>>> else?
>>>> I want to use it in my custom freebsd6 because I see "interspersed
>>>> strings
>>>> written from different CPUs at the same time":
>>>>
>>>> uuusseseerrvmrem: vlmivmeimtme :e mx:ceed eldi bly 2i89m68m (iihttt t
>>>> pde) eaxtx cfcorke1 22e3e
>>>> deded ebyd  by28 296898 68(h t(tpdh) att ftorkp1 22d3
>>>> ) at fork1 223
>>>>
>>>> I'm talking about only merging kern/subr_prf.c 1.126, 1.128, 1.129.
>>>>
>>>> Thanks.
>>>
>>> I did a backport of the option some time ago, see
>>> http://people.freebsd.org/~kib/misc/releng_6_printf_bufr.3.patch
>>>
>>
>> Thank you!
>>
>> 6.3 system panics (many page faults, one after another) early at boot
>> without the option, and boots with it in the QEMU environment.
>> Next step to test it on a real (and SMPable) hardware.
>>
>
> Now tested on a real 2xXeon 3.0 w/ HTT enabled w/ PRINTF_BUFR_SIZE enabled.
>
> Received the following panic:

And how big is PRINTF_BUFR_SIZE ?

-- 
Paul
From pluknet at gmail.com  Wed Dec 17 06:22:14 2008
From: pluknet at gmail.com (pluknet)
Date: Wed Dec 17 06:22:22 2008
Subject: PRINTF_BUFR_SIZE in freebsd6
In-Reply-To: <3a142e750812170610r25a48762y845010c6898f52d4@mail.gmail.com>
References: <a31046fc0812160423g7508bdbdrb160e9d1ec12b6e3@mail.gmail.com>
	<20081216134035.GU2038@deviant.kiev.zoral.com.ua>
	<a31046fc0812170248g4fa19250j159c645bdcd4ac89@mail.gmail.com>
	<a31046fc0812170552k31a7434cy9a13ea5c8322e94e@mail.gmail.com>
	<3a142e750812170610r25a48762y845010c6898f52d4@mail.gmail.com>
Message-ID: <a31046fc0812170622j1cfccfcem4bdc4c23f57de444@mail.gmail.com>

2008/12/17 Paul B. Mahol <onemda@gmail.com>:
> On 12/17/08, pluknet <pluknet@gmail.com> wrote:
>> 2008/12/17 pluknet <pluknet@gmail.com>:
>>> 2008/12/16 Kostik Belousov <kostikbel@gmail.com>:
>>>> On Tue, Dec 16, 2008 at 03:23:28PM +0300, pluknet wrote:
>>>>> Hi.
>>>>>
>>>>> Could the PRINTF_BUFR_SIZE option be safely merged into RELENG_6 without
>>>>> merging a possible underlining infrastructure and breaking something
>>>>> else?
>>>>> I want to use it in my custom freebsd6 because I see "interspersed
>>>>> strings
>>>>> written from different CPUs at the same time":
>>>>>
>>>>> uuusseseerrvmrem: vlmivmeimtme :e mx:ceed eldi bly 2i89m68m (iihttt t
>>>>> pde) eaxtx cfcorke1 22e3e
>>>>> deded ebyd  by28 296898 68(h t(tpdh) att ftorkp1 22d3
>>>>> ) at fork1 223
>>>>>
>>>>> I'm talking about only merging kern/subr_prf.c 1.126, 1.128, 1.129.
>>>>>
>>>>> Thanks.
>>>>
>>>> I did a backport of the option some time ago, see
>>>> http://people.freebsd.org/~kib/misc/releng_6_printf_bufr.3.patch
>>>>
>>>
>>> Thank you!
>>>
>>> 6.3 system panics (many page faults, one after another) early at boot
>>> without the option, and boots with it in the QEMU environment.
>>> Next step to test it on a real (and SMPable) hardware.
>>>
>>
>> Now tested on a real 2xXeon 3.0 w/ HTT enabled w/ PRINTF_BUFR_SIZE enabled.
>>
>> Received the following panic:
>
> And how big is PRINTF_BUFR_SIZE ?

Hi.

I set options PRINTF_BUFR_SIZE=128

And maybe it's not enough (?) because I stress-tested server triggering
to appear many kernel messages simultaneously.
I don't know coherence between buffer size and this panic though.

>
> --
> Paul
>
From onemda at gmail.com  Wed Dec 17 08:04:07 2008
From: onemda at gmail.com (Paul B. Mahol)
Date: Wed Dec 17 08:04:14 2008
Subject: PRINTF_BUFR_SIZE in freebsd6
In-Reply-To: <a31046fc0812170622j1cfccfcem4bdc4c23f57de444@mail.gmail.com>
References: <a31046fc0812160423g7508bdbdrb160e9d1ec12b6e3@mail.gmail.com>
	<20081216134035.GU2038@deviant.kiev.zoral.com.ua>
	<a31046fc0812170248g4fa19250j159c645bdcd4ac89@mail.gmail.com>
	<a31046fc0812170552k31a7434cy9a13ea5c8322e94e@mail.gmail.com>
	<3a142e750812170610r25a48762y845010c6898f52d4@mail.gmail.com>
	<a31046fc0812170622j1cfccfcem4bdc4c23f57de444@mail.gmail.com>
Message-ID: <3a142e750812170804v345457f0n1261baa418111a2f@mail.gmail.com>

On 12/17/08, pluknet <pluknet@gmail.com> wrote:
> 2008/12/17 Paul B. Mahol <onemda@gmail.com>:
>> On 12/17/08, pluknet <pluknet@gmail.com> wrote:
>>> 2008/12/17 pluknet <pluknet@gmail.com>:
>>>> 2008/12/16 Kostik Belousov <kostikbel@gmail.com>:
>>>>> On Tue, Dec 16, 2008 at 03:23:28PM +0300, pluknet wrote:
>>>>>> Hi.
>>>>>>
>>>>>> Could the PRINTF_BUFR_SIZE option be safely merged into RELENG_6
>>>>>> without
>>>>>> merging a possible underlining infrastructure and breaking something
>>>>>> else?
>>>>>> I want to use it in my custom freebsd6 because I see "interspersed
>>>>>> strings
>>>>>> written from different CPUs at the same time":
>>>>>>
>>>>>> uuusseseerrvmrem: vlmivmeimtme :e mx:ceed eldi bly 2i89m68m (iihttt t
>>>>>> pde) eaxtx cfcorke1 22e3e
>>>>>> deded ebyd  by28 296898 68(h t(tpdh) att ftorkp1 22d3
>>>>>> ) at fork1 223
>>>>>>
>>>>>> I'm talking about only merging kern/subr_prf.c 1.126, 1.128, 1.129.
>>>>>>
>>>>>> Thanks.
>>>>>
>>>>> I did a backport of the option some time ago, see
>>>>> http://people.freebsd.org/~kib/misc/releng_6_printf_bufr.3.patch
>>>>>
>>>>
>>>> Thank you!
>>>>
>>>> 6.3 system panics (many page faults, one after another) early at boot
>>>> without the option, and boots with it in the QEMU environment.
>>>> Next step to test it on a real (and SMPable) hardware.
>>>>
>>>
>>> Now tested on a real 2xXeon 3.0 w/ HTT enabled w/ PRINTF_BUFR_SIZE
>>> enabled.
>>>
>>> Received the following panic:
>>
>> And how big is PRINTF_BUFR_SIZE ?
>
> Hi.
>
> I set options PRINTF_BUFR_SIZE=128
>
> And maybe it's not enough (?) because I stress-tested server triggering
> to appear many kernel messages simultaneously.
> I don't know coherence between buffer size and this panic though.

How long such kernel messages are?

-- 
Paul
From pluknet at gmail.com  Wed Dec 17 08:40:44 2008
From: pluknet at gmail.com (pluknet)
Date: Wed Dec 17 08:41:01 2008
Subject: PRINTF_BUFR_SIZE in freebsd6
In-Reply-To: <3a142e750812170804v345457f0n1261baa418111a2f@mail.gmail.com>
References: <a31046fc0812160423g7508bdbdrb160e9d1ec12b6e3@mail.gmail.com>
	<20081216134035.GU2038@deviant.kiev.zoral.com.ua>
	<a31046fc0812170248g4fa19250j159c645bdcd4ac89@mail.gmail.com>
	<a31046fc0812170552k31a7434cy9a13ea5c8322e94e@mail.gmail.com>
	<3a142e750812170610r25a48762y845010c6898f52d4@mail.gmail.com>
	<a31046fc0812170622j1cfccfcem4bdc4c23f57de444@mail.gmail.com>
	<3a142e750812170804v345457f0n1261baa418111a2f@mail.gmail.com>
Message-ID: <a31046fc0812170840u5dffb6b0r179fb218432d83c1@mail.gmail.com>

2008/12/17 Paul B. Mahol <onemda@gmail.com>:
> On 12/17/08, pluknet <pluknet@gmail.com> wrote:
>> 2008/12/17 Paul B. Mahol <onemda@gmail.com>:
>>> On 12/17/08, pluknet <pluknet@gmail.com> wrote:
>>>> 2008/12/17 pluknet <pluknet@gmail.com>:
>>>>> 2008/12/16 Kostik Belousov <kostikbel@gmail.com>:
>>>>>> On Tue, Dec 16, 2008 at 03:23:28PM +0300, pluknet wrote:
>>>>>>> Hi.
>>>>>>>
>>>>>>> Could the PRINTF_BUFR_SIZE option be safely merged into RELENG_6
>>>>>>> without
>>>>>>> merging a possible underlining infrastructure and breaking something
>>>>>>> else?
>>>>>>> I want to use it in my custom freebsd6 because I see "interspersed
>>>>>>> strings
>>>>>>> written from different CPUs at the same time":
>>>>>>>
>>>>>>> uuusseseerrvmrem: vlmivmeimtme :e mx:ceed eldi bly 2i89m68m (iihttt t
>>>>>>> pde) eaxtx cfcorke1 22e3e
>>>>>>> deded ebyd  by28 296898 68(h t(tpdh) att ftorkp1 22d3
>>>>>>> ) at fork1 223
>>>>>>>
>>>>>>> I'm talking about only merging kern/subr_prf.c 1.126, 1.128, 1.129.
>>>>>>>
>>>>>>> Thanks.
>>>>>>
>>>>>> I did a backport of the option some time ago, see
>>>>>> http://people.freebsd.org/~kib/misc/releng_6_printf_bufr.3.patch
>>>>>>
>>>>>
>>>>> Thank you!
>>>>>
>>>>> 6.3 system panics (many page faults, one after another) early at boot
>>>>> without the option, and boots with it in the QEMU environment.
>>>>> Next step to test it on a real (and SMPable) hardware.
>>>>>
>>>>
>>>> Now tested on a real 2xXeon 3.0 w/ HTT enabled w/ PRINTF_BUFR_SIZE
>>>> enabled.
>>>>
>>>> Received the following panic:
>>>
>>> And how big is PRINTF_BUFR_SIZE ?
>>
>> Hi.
>>
>> I set options PRINTF_BUFR_SIZE=128
>>
>> And maybe it's not enough (?) because I stress-tested server triggering
>> to appear many kernel messages simultaneously.
>> I don't know coherence between buffer size and this panic though.
>
> How long such kernel messages are?

48 symbols plus length of a process name... it added 6 in my case,
i.e. 54 symbols totally.

-- 
wbr,
pluknet
From oxy at field.hu  Wed Dec 17 15:35:59 2008
From: oxy at field.hu (oxy)
Date: Wed Dec 17 15:36:06 2008
Subject: missing mount_devfs
Message-ID: <494988B6.4060600@field.hu>

hi!

I installed 7.0-RELEASE/amd64 and tried to create a jail with jailctl.
after a couple errors i noticed that mount_devfs is missing!
is there any other way to create devfs in order to make jails?
thank you!
From rick-freebsd2008 at kiwi-computer.com  Wed Dec 17 15:56:34 2008
From: rick-freebsd2008 at kiwi-computer.com (Rick C. Petty)
Date: Wed Dec 17 15:56:41 2008
Subject: missing mount_devfs
In-Reply-To: <494988B6.4060600@field.hu>
References: <494988B6.4060600@field.hu>
Message-ID: <20081217235633.GB59101@keira.kiwi-computer.com>

On Thu, Dec 18, 2008 at 12:18:14AM +0100, oxy wrote:
> 
> I installed 7.0-RELEASE/amd64 and tried to create a jail with jailctl.
> after a couple errors i noticed that mount_devfs is missing!
> is there any other way to create devfs in order to make jails?
> thank you!

What about:  "mount -t devfs devfs /dev"  I believe I saw recently that
devfs mounts were merged into standard mount code.

-- Rick C. Petty
From jille at quis.cx  Wed Dec 17 15:59:00 2008
From: jille at quis.cx (Jille Timmermans)
Date: Wed Dec 17 15:59:07 2008
Subject: missing mount_devfs
In-Reply-To: <494988B6.4060600@field.hu>
References: <494988B6.4060600@field.hu>
Message-ID: <49498DEA.6090805@quis.cx>

# alias mount_devfs="mount -t devfs"

(human: try mount -t devfs instead of mount_devfs)

-- Jille
(I think freebsd-questions is the appropriate list for this)

oxy schreef:
> hi!
> 
> I installed 7.0-RELEASE/amd64 and tried to create a jail with jailctl.
> after a couple errors i noticed that mount_devfs is missing!
> is there any other way to create devfs in order to make jails?
> thank you!
> _______________________________________________
> freebsd-hackers@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
From fernercc at gmail.com  Fri Dec 19 21:10:12 2008
From: fernercc at gmail.com (Ferner Cilloniz)
Date: Fri Dec 19 21:10:26 2008
Subject: adding proc to allproc
Message-ID: <1229726360.5614.15.camel@mobiliare.Belkin>

Hello everyone.

I am playing with freebsd and just learning some things about the
FreeBSD kernel. 

So for my first quest i am placing random processes from the allproc
list into a list of my own and trying to add them back into allproc

I have pasted the code below.

-----------------------------------------------------------------------
struct proc *p = a process from my own list;
if( p != NULL && (p->p_state == PRS_NEW || p->p_state == PRS_NORMAL) ){
       LIST_INSERT_HEAD(&allproc, p, p_list);
}
-----------------------------------------------------------------------

Thanks.

From julian at elischer.org  Fri Dec 19 21:27:24 2008
From: julian at elischer.org (Julian Elischer)
Date: Fri Dec 19 21:27:30 2008
Subject: adding proc to allproc
In-Reply-To: <1229726360.5614.15.camel@mobiliare.Belkin>
References: <1229726360.5614.15.camel@mobiliare.Belkin>
Message-ID: <494C8246.3020703@elischer.org>

Ferner Cilloniz wrote:
> Hello everyone.
> 
> I am playing with freebsd and just learning some things about the
> FreeBSD kernel. 
> 
> So for my first quest i am placing random processes from the allproc
> list into a list of my own and trying to add them back into allproc
> 
> I have pasted the code below.
> 
> -----------------------------------------------------------------------
> struct proc *p = a process from my own list;
> if( p != NULL && (p->p_state == PRS_NEW || p->p_state == PRS_NORMAL) ){
>        LIST_INSERT_HEAD(&allproc, p, p_list);
> }
> -----------------------------------------------------------------------
> 
> Thanks.

and your question is?


> 
> _______________________________________________
> freebsd-hackers@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"

From fernercc at gmail.com  Fri Dec 19 21:28:50 2008
From: fernercc at gmail.com (Ferner Cilloniz)
Date: Fri Dec 19 21:28:57 2008
Subject: adding proc to allproc
In-Reply-To: <494C8246.3020703@elischer.org>
References: <1229726360.5614.15.camel@mobiliare.Belkin>
	<494C8246.3020703@elischer.org>
Message-ID: <1229729326.5614.16.camel@mobiliare.Belkin>

When i run the code from a KLD it hangs the system. No reboot occurs
however, it just hangs there.


On Fri, 2008-12-19 at 21:27 -0800, Julian Elischer wrote:
> Ferner Cilloniz wrote:
> > Hello everyone.
> > 
> > I am playing with freebsd and just learning some things about the
> > FreeBSD kernel. 
> > 
> > So for my first quest i am placing random processes from the allproc
> > list into a list of my own and trying to add them back into allproc
> > 
> > I have pasted the code below.
> > 
> > -----------------------------------------------------------------------
> > struct proc *p = a process from my own list;
> > if( p != NULL && (p->p_state == PRS_NEW || p->p_state == PRS_NORMAL) ){
> >        LIST_INSERT_HEAD(&allproc, p, p_list);
> > }
> > -----------------------------------------------------------------------
> > 
> > Thanks.
> 
> and your question is?
> 
> 
> > 
> > _______________________________________________
> > freebsd-hackers@freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
> 
-- 
Cilloniz Bicchi, Ferner

Research Assistant
Dept. of Computer Sciences
The University of Texas at Austin
http://www.cs.utexas.edu/~fernercc
fernercc@cs.utexas.edu

From julian at elischer.org  Fri Dec 19 21:39:10 2008
From: julian at elischer.org (Julian Elischer)
Date: Fri Dec 19 21:39:16 2008
Subject: adding proc to allproc
In-Reply-To: <1229729326.5614.16.camel@mobiliare.Belkin>
References: <1229726360.5614.15.camel@mobiliare.Belkin>	
	<494C8246.3020703@elischer.org>
	<1229729326.5614.16.camel@mobiliare.Belkin>
Message-ID: <494C8508.2020000@elischer.org>

Ferner Cilloniz wrote:
> When i run the code from a KLD it hangs the system. No reboot occurs
> however, it just hangs there.

well, firstly you have no locking though that would probably let you 
get away with it most times.

Where does the process come from in the first place?

It sounds like you are making a circular list somewhere or somehow...

have you tried going into ddb?




> 
> 
> On Fri, 2008-12-19 at 21:27 -0800, Julian Elischer wrote:
>> Ferner Cilloniz wrote:
>>> Hello everyone.
>>>
>>> I am playing with freebsd and just learning some things about the
>>> FreeBSD kernel. 
>>>
>>> So for my first quest i am placing random processes from the allproc
>>> list into a list of my own and trying to add them back into allproc
>>>
>>> I have pasted the code below.
>>>
>>> -----------------------------------------------------------------------
>>> struct proc *p = a process from my own list;
>>> if( p != NULL && (p->p_state == PRS_NEW || p->p_state == PRS_NORMAL) ){
>>>        LIST_INSERT_HEAD(&allproc, p, p_list);
>>> }
>>> -----------------------------------------------------------------------

>>
>>> _______________________________________________
>>> freebsd-hackers@freebsd.org mailing list
>>> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
>>> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"

From fernercc at gmail.com  Sat Dec 20 00:23:26 2008
From: fernercc at gmail.com (Ferner Cilloniz)
Date: Sat Dec 20 00:23:33 2008
Subject: adding proc to allproc
In-Reply-To: <494C8508.2020000@elischer.org>
References: <1229726360.5614.15.camel@mobiliare.Belkin>
	<494C8246.3020703@elischer.org>
	<1229729326.5614.16.camel@mobiliare.Belkin>
	<494C8508.2020000@elischer.org>
Message-ID: <1229739800.5614.24.camel@mobiliare.Belkin>

The process comes from the allproc list.
I am simply iterating through this list and removing the first 1/2 of
allproc list and adding the removed process to my own singly linked
list.

LIST_REMOVE(current_proc, p_list);  // remove from the allproc
add_proc_entry(current_proc);

Later, i am iterating through my singly linked list and doing the below:

struct proc *p = current->p;
f( p != NULL && (p->p_state == PRS_NEW || p->p_state == PRS_NORMAL) ){
      LIST_INSERT_HEAD(&allproc, p, p_list);
}

Could this be causing a circular list?

I am adding the proc entries to my singly linked list as follows:

static void add_proc_entry(const struct proc *p)
{
    struct proc_ll *new_entry = (struct proc_ll*)malloc(sizeof(struct
proc_ll), M_TEMP, M_ZERO | M_NOWAIT);
    int done = 0;

    new_entry->p = p; // maybe doing this assignment isnt correct?

    if(proc_entries == NULL) {
        proc_entries = new_entry;
        return;
    }

    struct proc_ll *current = proc_entries;

    while(current != NULL) {
        if(current->next == NULL) {
            current->next = new_entry;
            break;
        }
        current = current->next;
    }
}


struct proc_ll {
    struct proc *p;
    struct proc_ll *next;
};


A circular list does sound like it could cause hanging to occur but the
above code, atleast from my eyes, doesn't seem to cause it.

On Fri, 2008-12-19 at 21:39 -0800, Julian Elischer wrote:
> Ferner Cilloniz wrote:
> > When i run the code from a KLD it hangs the system. No reboot occurs
> > however, it just hangs there.
> 
> well, firstly you have no locking though that would probably let you 
> get away with it most times.
> 
> Where does the process come from in the first place?
> 
> It sounds like you are making a circular list somewhere or somehow...
> 
> have you tried going into ddb?
> 
> 
> 
> 
> > 
> > 
> > On Fri, 2008-12-19 at 21:27 -0800, Julian Elischer wrote:
> >> Ferner Cilloniz wrote:
> >>> Hello everyone.
> >>>
> >>> I am playing with freebsd and just learning some things about the
> >>> FreeBSD kernel. 
> >>>
> >>> So for my first quest i am placing random processes from the allproc
> >>> list into a list of my own and trying to add them back into allproc
> >>>
> >>> I have pasted the code below.
> >>>
> >>> -----------------------------------------------------------------------
> >>> struct proc *p = a process from my own list;
> >>> if( p != NULL && (p->p_state == PRS_NEW || p->p_state == PRS_NORMAL) ){
> >>>        LIST_INSERT_HEAD(&allproc, p, p_list);
> >>> }
> >>> -----------------------------------------------------------------------
> 
> >>
> >>> _______________________________________________
> >>> freebsd-hackers@freebsd.org mailing list
> >>> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> >>> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
> 


From michelle_li_001 at yahoo.com  Sat Dec 20 18:31:50 2008
From: michelle_li_001 at yahoo.com (Michelle Li)
Date: Sat Dec 20 18:31:57 2008
Subject: reg: adding proc to allproc (Ferner Cilloniz) 
In-Reply-To: <20081220120017.322FA10656E1@hub.freebsd.org>
Message-ID: <823694.23548.qm@web65403.mail.ac4.yahoo.com>

reg: adding proc to allproc (Ferner Cilloniz) 

new_entry->p .....
 is accessing the "read/write" pointer declared in the proc_ll struct

new_entry->p = p; 
  is attempting an assignment of a "read ONLY" const pointer that
  has been passed into add_proc_entry() to a "read/write" pointer

new_entry->"read/write pointer" = "read ONLY pointer";  
   is invalid

"new_entry->p = p; // maybe doing this assignment isnt correct?"
   with this assertion I agree


freebsd-hackers-request@freebsd.org wrote: Send freebsd-hackers mailing list submissions to
 freebsd-hackers@freebsd.org

To subscribe or unsubscribe via the World Wide Web, visit
 http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
or, via email, send a message with subject or body 'help' to
 freebsd-hackers-request@freebsd.org

You can reach the person managing the list at
 freebsd-hackers-owner@freebsd.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of freebsd-hackers digest..."


Today's Topics:

   1. adding proc to allproc (Ferner Cilloniz)
   2. Re: adding proc to allproc (Julian Elischer)
   3. Re: adding proc to allproc (Ferner Cilloniz)
   4. Re: adding proc to allproc (Julian Elischer)
   5. Re: adding proc to allproc (Ferner Cilloniz)


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

Message: 1
Date: Fri, 19 Dec 2008 22:39:20 +0000
From: Ferner Cilloniz 
Subject: adding proc to allproc
To: freebsd-hackers@freebsd.org
Message-ID: <1229726360.5614.15.camel@mobiliare.Belkin>
Content-Type: text/plain

Hello everyone.

I am playing with freebsd and just learning some things about the
FreeBSD kernel. 

So for my first quest i am placing random processes from the allproc
list into a list of my own and trying to add them back into allproc

I have pasted the code below.

-----------------------------------------------------------------------
struct proc *p = a process from my own list;
if( p != NULL && (p->p_state == PRS_NEW || p->p_state == PRS_NORMAL) ){
       LIST_INSERT_HEAD(&allproc, p, p_list);
}
-----------------------------------------------------------------------

Thanks.



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

Message: 2
Date: Fri, 19 Dec 2008 21:27:34 -0800
From: Julian Elischer 
Subject: Re: adding proc to allproc
To: Ferner Cilloniz 
Cc: freebsd-hackers@freebsd.org
Message-ID: <494C8246.3020703@elischer.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Ferner Cilloniz wrote:
> Hello everyone.
> 
> I am playing with freebsd and just learning some things about the
> FreeBSD kernel. 
> 
> So for my first quest i am placing random processes from the allproc
> list into a list of my own and trying to add them back into allproc
> 
> I have pasted the code below.
> 
> -----------------------------------------------------------------------
> struct proc *p = a process from my own list;
> if( p != NULL && (p->p_state == PRS_NEW || p->p_state == PRS_NORMAL) ){
>        LIST_INSERT_HEAD(&allproc, p, p_list);
> }
> -----------------------------------------------------------------------
> 
> Thanks.

and your question is?


> 
> _______________________________________________
> freebsd-hackers@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"



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

Message: 3
Date: Fri, 19 Dec 2008 23:28:46 +0000
From: Ferner Cilloniz 
Subject: Re: adding proc to allproc
To: Julian Elischer 
Cc: freebsd-hackers@freebsd.org
Message-ID: <1229729326.5614.16.camel@mobiliare.Belkin>
Content-Type: text/plain

When i run the code from a KLD it hangs the system. No reboot occurs
however, it just hangs there.


On Fri, 2008-12-19 at 21:27 -0800, Julian Elischer wrote:
> Ferner Cilloniz wrote:
> > Hello everyone.
> > 
> > I am playing with freebsd and just learning some things about the
> > FreeBSD kernel. 
> > 
> > So for my first quest i am placing random processes from the allproc
> > list into a list of my own and trying to add them back into allproc
> > 
> > I have pasted the code below.
> > 
> > -----------------------------------------------------------------------
> > struct proc *p = a process from my own list;
> > if( p != NULL && (p->p_state == PRS_NEW || p->p_state == PRS_NORMAL) ){
> >        LIST_INSERT_HEAD(&allproc, p, p_list);
> > }
> > -----------------------------------------------------------------------
> > 
> > Thanks.
> 
> and your question is?
> 
> 
> > 
> > _______________________________________________
> > freebsd-hackers@freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
> 
-- 
Cilloniz Bicchi, Ferner

Research Assistant
Dept. of Computer Sciences
The University of Texas at Austin
http://www.cs.utexas.edu/~fernercc
fernercc@cs.utexas.edu



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

Message: 4
Date: Fri, 19 Dec 2008 21:39:20 -0800
From: Julian Elischer 
Subject: Re: adding proc to allproc
To: Ferner Cilloniz 
Cc: freebsd-hackers@freebsd.org
Message-ID: <494C8508.2020000@elischer.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Ferner Cilloniz wrote:
> When i run the code from a KLD it hangs the system. No reboot occurs
> however, it just hangs there.

well, firstly you have no locking though that would probably let you 
get away with it most times.

Where does the process come from in the first place?

It sounds like you are making a circular list somewhere or somehow...

have you tried going into ddb?




> 
> 
> On Fri, 2008-12-19 at 21:27 -0800, Julian Elischer wrote:
>> Ferner Cilloniz wrote:
>>> Hello everyone.
>>>
>>> I am playing with freebsd and just learning some things about the
>>> FreeBSD kernel. 
>>>
>>> So for my first quest i am placing random processes from the allproc
>>> list into a list of my own and trying to add them back into allproc
>>>
>>> I have pasted the code below.
>>>
>>> -----------------------------------------------------------------------
>>> struct proc *p = a process from my own list;
>>> if( p != NULL && (p->p_state == PRS_NEW || p->p_state == PRS_NORMAL) ){
>>>        LIST_INSERT_HEAD(&allproc, p, p_list);
>>> }
>>> -----------------------------------------------------------------------

>>
>>> _______________________________________________
>>> freebsd-hackers@freebsd.org mailing list
>>> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
>>> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"



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

Message: 5
Date: Sat, 20 Dec 2008 02:23:20 +0000
From: Ferner Cilloniz 
Subject: Re: adding proc to allproc
To: Julian Elischer 
Cc: freebsd-hackers@freebsd.org
Message-ID: <1229739800.5614.24.camel@mobiliare.Belkin>
Content-Type: text/plain

The process comes from the allproc list.
I am simply iterating through this list and removing the first 1/2 of
allproc list and adding the removed process to my own singly linked
list.

LIST_REMOVE(current_proc, p_list);  // remove from the allproc
add_proc_entry(current_proc);

Later, i am iterating through my singly linked list and doing the below:

struct proc *p = current->p;
f( p != NULL && (p->p_state == PRS_NEW || p->p_state == PRS_NORMAL) ){
      LIST_INSERT_HEAD(&allproc, p, p_list);
}

Could this be causing a circular list?

I am adding the proc entries to my singly linked list as follows:

static void add_proc_entry(const struct proc *p)
{
    struct proc_ll *new_entry = (struct proc_ll*)malloc(sizeof(struct
proc_ll), M_TEMP, M_ZERO | M_NOWAIT);
    int done = 0;

    new_entry->p = p; // maybe doing this assignment isnt correct?

    if(proc_entries == NULL) {
        proc_entries = new_entry;
        return;
    }

    struct proc_ll *current = proc_entries;

    while(current != NULL) {
        if(current->next == NULL) {
            current->next = new_entry;
            break;
        }
        current = current->next;
    }
}


struct proc_ll {
    struct proc *p;
    struct proc_ll *next;
};


A circular list does sound like it could cause hanging to occur but the
above code, atleast from my eyes, doesn't seem to cause it.

On Fri, 2008-12-19 at 21:39 -0800, Julian Elischer wrote:
> Ferner Cilloniz wrote:
> > When i run the code from a KLD it hangs the system. No reboot occurs
> > however, it just hangs there.
> 
> well, firstly you have no locking though that would probably let you 
> get away with it most times.
> 
> Where does the process come from in the first place?
> 
> It sounds like you are making a circular list somewhere or somehow...
> 
> have you tried going into ddb?
> 
> 
> 
> 
> > 
> > 
> > On Fri, 2008-12-19 at 21:27 -0800, Julian Elischer wrote:
> >> Ferner Cilloniz wrote:
> >>> Hello everyone.
> >>>
> >>> I am playing with freebsd and just learning some things about the
> >>> FreeBSD kernel. 
> >>>
> >>> So for my first quest i am placing random processes from the allproc
> >>> list into a list of my own and trying to add them back into allproc
> >>>
> >>> I have pasted the code below.
> >>>
> >>> -----------------------------------------------------------------------
> >>> struct proc *p = a process from my own list;
> >>> if( p != NULL && (p->p_state == PRS_NEW || p->p_state == PRS_NORMAL) ){
> >>>        LIST_INSERT_HEAD(&allproc, p, p_list);
> >>> }
> >>> -----------------------------------------------------------------------
> 
> >>
> >>> _______________________________________________
> >>> freebsd-hackers@freebsd.org mailing list
> >>> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> >>> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
> 




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

_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"

End of freebsd-hackers Digest, Vol 299, Issue 5
***********************************************


       
From fernercc at gmail.com  Sat Dec 20 18:49:44 2008
From: fernercc at gmail.com (Ferner Cilloniz)
Date: Sat Dec 20 18:49:51 2008
Subject: reg: adding proc to allproc
In-Reply-To: <823694.23548.qm@web65403.mail.ac4.yahoo.com>
References: <823694.23548.qm@web65403.mail.ac4.yahoo.com>
Message-ID: <1229806179.4952.3.camel@mobiliare.Belkin>

for the sake of this discussion its suffice to consider new_entry->p as
read-only pointer because i never modify it. I am just storing its
address. It easily just be considered an unsigned long value.

However, would really calling 
LIST_INSERT_HEAD(&allproc, entry->p, p_list)

result in a hang of the system? I'm flipping through pages in FreeBSD
design and implementation right now.

On Sat, 2008-12-20 at 18:05 -0800, Michelle Li wrote:
> reg: adding proc to allproc (Ferner Cilloniz) 
> 
> new_entry->p .....
>  is accessing the "read/write" pointer declared in the proc_ll struct
> 
> new_entry->p = p; 
>   is attempting an assignment of a "read ONLY" const pointer that
>   has been passed into add_proc_entry() to a "read/write" pointer
> 
> new_entry->"read/write pointer" = "read ONLY pointer";  
>    is invalid
> 
> "new_entry->p = p; // maybe doing this assignment isnt correct?"
>    with this assertion I agree
> 
> 
> freebsd-hackers-request@freebsd.org wrote: Send freebsd-hackers mailing list submissions to
>  freebsd-hackers@freebsd.org
> 
> To subscribe or unsubscribe via the World Wide Web, visit
>  http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> or, via email, send a message with subject or body 'help' to
>  freebsd-hackers-request@freebsd.org
> 
> You can reach the person managing the list at
>  freebsd-hackers-owner@freebsd.org
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of freebsd-hackers digest..."
> 
> 
> Today's Topics:
> 
>    1. adding proc to allproc (Ferner Cilloniz)
>    2. Re: adding proc to allproc (Julian Elischer)
>    3. Re: adding proc to allproc (Ferner Cilloniz)
>    4. Re: adding proc to allproc (Julian Elischer)
>    5. Re: adding proc to allproc (Ferner Cilloniz)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Fri, 19 Dec 2008 22:39:20 +0000
> From: Ferner Cilloniz 
> Subject: adding proc to allproc
> To: freebsd-hackers@freebsd.org
> Message-ID: <1229726360.5614.15.camel@mobiliare.Belkin>
> Content-Type: text/plain
> 
> Hello everyone.
> 
> I am playing with freebsd and just learning some things about the
> FreeBSD kernel. 
> 
> So for my first quest i am placing random processes from the allproc
> list into a list of my own and trying to add them back into allproc
> 
> I have pasted the code below.
> 
> -----------------------------------------------------------------------
> struct proc *p = a process from my own list;
> if( p != NULL && (p->p_state == PRS_NEW || p->p_state == PRS_NORMAL) ){
>        LIST_INSERT_HEAD(&allproc, p, p_list);
> }
> -----------------------------------------------------------------------
> 
> Thanks.
> 
> 
> 
> ------------------------------
> 
> Message: 2
> Date: Fri, 19 Dec 2008 21:27:34 -0800
> From: Julian Elischer 
> Subject: Re: adding proc to allproc
> To: Ferner Cilloniz 
> Cc: freebsd-hackers@freebsd.org
> Message-ID: <494C8246.3020703@elischer.org>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> 
> Ferner Cilloniz wrote:
> > Hello everyone.
> > 
> > I am playing with freebsd and just learning some things about the
> > FreeBSD kernel. 
> > 
> > So for my first quest i am placing random processes from the allproc
> > list into a list of my own and trying to add them back into allproc
> > 
> > I have pasted the code below.
> > 
> > -----------------------------------------------------------------------
> > struct proc *p = a process from my own list;
> > if( p != NULL && (p->p_state == PRS_NEW || p->p_state == PRS_NORMAL) ){
> >        LIST_INSERT_HEAD(&allproc, p, p_list);
> > }
> > -----------------------------------------------------------------------
> > 
> > Thanks.
> 
> and your question is?
> 
> 
> > 
> > _______________________________________________
> > freebsd-hackers@freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
> 
> 
> 
> ------------------------------
> 
> Message: 3
> Date: Fri, 19 Dec 2008 23:28:46 +0000
> From: Ferner Cilloniz 
> Subject: Re: adding proc to allproc
> To: Julian Elischer 
> Cc: freebsd-hackers@freebsd.org
> Message-ID: <1229729326.5614.16.camel@mobiliare.Belkin>
> Content-Type: text/plain
> 
> When i run the code from a KLD it hangs the system. No reboot occurs
> however, it just hangs there.
> 
> 
> On Fri, 2008-12-19 at 21:27 -0800, Julian Elischer wrote:
> > Ferner Cilloniz wrote:
> > > Hello everyone.
> > > 
> > > I am playing with freebsd and just learning some things about the
> > > FreeBSD kernel. 
> > > 
> > > So for my first quest i am placing random processes from the allproc
> > > list into a list of my own and trying to add them back into allproc
> > > 
> > > I have pasted the code below.
> > > 
> > > -----------------------------------------------------------------------
> > > struct proc *p = a process from my own list;
> > > if( p != NULL && (p->p_state == PRS_NEW || p->p_state == PRS_NORMAL) ){
> > >        LIST_INSERT_HEAD(&allproc, p, p_list);
> > > }
> > > -----------------------------------------------------------------------
> > > 
> > > Thanks.
> > 
> > and your question is?
> > 
> > 
> > > 
> > > _______________________________________________
> > > freebsd-hackers@freebsd.org mailing list
> > > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> > > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
> > 
> -- 
> Cilloniz Bicchi, Ferner
> 
> Research Assistant
> Dept. of Computer Sciences
> The University of Texas at Austin
> http://www.cs.utexas.edu/~fernercc
> fernercc@cs.utexas.edu
> 
> 
> 
> ------------------------------
> 
> Message: 4
> Date: Fri, 19 Dec 2008 21:39:20 -0800
> From: Julian Elischer 
> Subject: Re: adding proc to allproc
> To: Ferner Cilloniz 
> Cc: freebsd-hackers@freebsd.org
> Message-ID: <494C8508.2020000@elischer.org>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> 
> Ferner Cilloniz wrote:
> > When i run the code from a KLD it hangs the system. No reboot occurs
> > however, it just hangs there.
> 
> well, firstly you have no locking though that would probably let you 
> get away with it most times.
> 
> Where does the process come from in the first place?
> 
> It sounds like you are making a circular list somewhere or somehow...
> 
> have you tried going into ddb?
> 
> 
> 
> 
> > 
> > 
> > On Fri, 2008-12-19 at 21:27 -0800, Julian Elischer wrote:
> >> Ferner Cilloniz wrote:
> >>> Hello everyone.
> >>>
> >>> I am playing with freebsd and just learning some things about the
> >>> FreeBSD kernel. 
> >>>
> >>> So for my first quest i am placing random processes from the allproc
> >>> list into a list of my own and trying to add them back into allproc
> >>>
> >>> I have pasted the code below.
> >>>
> >>> -----------------------------------------------------------------------
> >>> struct proc *p = a process from my own list;
> >>> if( p != NULL && (p->p_state == PRS_NEW || p->p_state == PRS_NORMAL) ){
> >>>        LIST_INSERT_HEAD(&allproc, p, p_list);
> >>> }
> >>> -----------------------------------------------------------------------
> 
> >>
> >>> _______________________________________________
> >>> freebsd-hackers@freebsd.org mailing list
> >>> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> >>> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
> 
> 
> 
> ------------------------------
> 
> Message: 5
> Date: Sat, 20 Dec 2008 02:23:20 +0000
> From: Ferner Cilloniz 
> Subject: Re: adding proc to allproc
> To: Julian Elischer 
> Cc: freebsd-hackers@freebsd.org
> Message-ID: <1229739800.5614.24.camel@mobiliare.Belkin>
> Content-Type: text/plain
> 
> The process comes from the allproc list.
> I am simply iterating through this list and removing the first 1/2 of
> allproc list and adding the removed process to my own singly linked
> list.
> 
> LIST_REMOVE(current_proc, p_list);  // remove from the allproc
> add_proc_entry(current_proc);
> 
> Later, i am iterating through my singly linked list and doing the below:
> 
> struct proc *p = current->p;
> f( p != NULL && (p->p_state == PRS_NEW || p->p_state == PRS_NORMAL) ){
>       LIST_INSERT_HEAD(&allproc, p, p_list);
> }
> 
> Could this be causing a circular list?
> 
> I am adding the proc entries to my singly linked list as follows:
> 
> static void add_proc_entry(const struct proc *p)
> {
>     struct proc_ll *new_entry = (struct proc_ll*)malloc(sizeof(struct
> proc_ll), M_TEMP, M_ZERO | M_NOWAIT);
>     int done = 0;
> 
>     new_entry->p = p; // maybe doing this assignment isnt correct?
> 
>     if(proc_entries == NULL) {
>         proc_entries = new_entry;
>         return;
>     }
> 
>     struct proc_ll *current = proc_entries;
> 
>     while(current != NULL) {
>         if(current->next == NULL) {
>             current->next = new_entry;
>             break;
>         }
>         current = current->next;
>     }
> }
> 
> 
> struct proc_ll {
>     struct proc *p;
>     struct proc_ll *next;
> };
> 
> 
> A circular list does sound like it could cause hanging to occur but the
> above code, atleast from my eyes, doesn't seem to cause it.
> 
> On Fri, 2008-12-19 at 21:39 -0800, Julian Elischer wrote:
> > Ferner Cilloniz wrote:
> > > When i run the code from a KLD it hangs the system. No reboot occurs
> > > however, it just hangs there.
> > 
> > well, firstly you have no locking though that would probably let you 
> > get away with it most times.
> > 
> > Where does the process come from in the first place?
> > 
> > It sounds like you are making a circular list somewhere or somehow...
> > 
> > have you tried going into ddb?
> > 
> > 
> > 
> > 
> > > 
> > > 
> > > On Fri, 2008-12-19 at 21:27 -0800, Julian Elischer wrote:
> > >> Ferner Cilloniz wrote:
> > >>> Hello everyone.
> > >>>
> > >>> I am playing with freebsd and just learning some things about the
> > >>> FreeBSD kernel. 
> > >>>
> > >>> So for my first quest i am placing random processes from the allproc
> > >>> list into a list of my own and trying to add them back into allproc
> > >>>
> > >>> I have pasted the code below.
> > >>>
> > >>> -----------------------------------------------------------------------
> > >>> struct proc *p = a process from my own list;
> > >>> if( p != NULL && (p->p_state == PRS_NEW || p->p_state == PRS_NORMAL) ){
> > >>>        LIST_INSERT_HEAD(&allproc, p, p_list);
> > >>> }
> > >>> -----------------------------------------------------------------------
> > 
> > >>
> > >>> _______________________________________________
> > >>> freebsd-hackers@freebsd.org mailing list
> > >>> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> > >>> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
> > 
> 
> 
> 
> 
> ------------------------------
> 
> _______________________________________________
> freebsd-hackers@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
> 
> End of freebsd-hackers Digest, Vol 299, Issue 5
> ***********************************************
> 
> 
>        
> _______________________________________________
> freebsd-hackers@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
-- 
Cilloniz Bicchi, Ferner

Research Assistant
Dept. of Computer Sciences
The University of Texas at Austin
http://www.cs.utexas.edu/~fernercc
fernercc@cs.utexas.edu

From fernercc at gmail.com  Sat Dec 20 18:51:16 2008
From: fernercc at gmail.com (Ferner Cilloniz)
Date: Sat Dec 20 18:51:23 2008
Subject: reg: adding proc to allproc
In-Reply-To: <1229806179.4952.3.camel@mobiliare.Belkin>
References: <823694.23548.qm@web65403.mail.ac4.yahoo.com>
	<1229806179.4952.3.camel@mobiliare.Belkin>
Message-ID: <1229806271.4952.4.camel@mobiliare.Belkin>

Forgot to mention. Im using the below book and /sys/kern/kern_fork.c as
references for process management.

On Sat, 2008-12-20 at 20:49 +0000, Ferner Cilloniz wrote:
> for the sake of this discussion its suffice to consider new_entry->p as
> read-only pointer because i never modify it. I am just storing its
> address. It easily just be considered an unsigned long value.
> 
> However, would really calling 
> LIST_INSERT_HEAD(&allproc, entry->p, p_list)
> 
> result in a hang of the system? I'm flipping through pages in FreeBSD
> design and implementation right now.
> 
> On Sat, 2008-12-20 at 18:05 -0800, Michelle Li wrote:
> > reg: adding proc to allproc (Ferner Cilloniz) 
> > 
> > new_entry->p .....
> >  is accessing the "read/write" pointer declared in the proc_ll struct
> > 
> > new_entry->p = p; 
> >   is attempting an assignment of a "read ONLY" const pointer that
> >   has been passed into add_proc_entry() to a "read/write" pointer
> > 
> > new_entry->"read/write pointer" = "read ONLY pointer";  
> >    is invalid
> > 
> > "new_entry->p = p; // maybe doing this assignment isnt correct?"
> >    with this assertion I agree
> > 
> > 
> > freebsd-hackers-request@freebsd.org wrote: Send freebsd-hackers mailing list submissions to
> >  freebsd-hackers@freebsd.org
> > 
> > To subscribe or unsubscribe via the World Wide Web, visit
> >  http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> > or, via email, send a message with subject or body 'help' to
> >  freebsd-hackers-request@freebsd.org
> > 
> > You can reach the person managing the list at
> >  freebsd-hackers-owner@freebsd.org
> > 
> > When replying, please edit your Subject line so it is more specific
> > than "Re: Contents of freebsd-hackers digest..."
> > 
> > 
> > Today's Topics:
> > 
> >    1. adding proc to allproc (Ferner Cilloniz)
> >    2. Re: adding proc to allproc (Julian Elischer)
> >    3. Re: adding proc to allproc (Ferner Cilloniz)
> >    4. Re: adding proc to allproc (Julian Elischer)
> >    5. Re: adding proc to allproc (Ferner Cilloniz)
> > 
> > 
> > ----------------------------------------------------------------------
> > 
> > Message: 1
> > Date: Fri, 19 Dec 2008 22:39:20 +0000
> > From: Ferner Cilloniz 
> > Subject: adding proc to allproc
> > To: freebsd-hackers@freebsd.org
> > Message-ID: <1229726360.5614.15.camel@mobiliare.Belkin>
> > Content-Type: text/plain
> > 
> > Hello everyone.
> > 
> > I am playing with freebsd and just learning some things about the
> > FreeBSD kernel. 
> > 
> > So for my first quest i am placing random processes from the allproc
> > list into a list of my own and trying to add them back into allproc
> > 
> > I have pasted the code below.
> > 
> > -----------------------------------------------------------------------
> > struct proc *p = a process from my own list;
> > if( p != NULL && (p->p_state == PRS_NEW || p->p_state == PRS_NORMAL) ){
> >        LIST_INSERT_HEAD(&allproc, p, p_list);
> > }
> > -----------------------------------------------------------------------
> > 
> > Thanks.
> > 
> > 
> > 
> > ------------------------------
> > 
> > Message: 2
> > Date: Fri, 19 Dec 2008 21:27:34 -0800
> > From: Julian Elischer 
> > Subject: Re: adding proc to allproc
> > To: Ferner Cilloniz 
> > Cc: freebsd-hackers@freebsd.org
> > Message-ID: <494C8246.3020703@elischer.org>
> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> > 
> > Ferner Cilloniz wrote:
> > > Hello everyone.
> > > 
> > > I am playing with freebsd and just learning some things about the
> > > FreeBSD kernel. 
> > > 
> > > So for my first quest i am placing random processes from the allproc
> > > list into a list of my own and trying to add them back into allproc
> > > 
> > > I have pasted the code below.
> > > 
> > > -----------------------------------------------------------------------
> > > struct proc *p = a process from my own list;
> > > if( p != NULL && (p->p_state == PRS_NEW || p->p_state == PRS_NORMAL) ){
> > >        LIST_INSERT_HEAD(&allproc, p, p_list);
> > > }
> > > -----------------------------------------------------------------------
> > > 
> > > Thanks.
> > 
> > and your question is?
> > 
> > 
> > > 
> > > _______________________________________________
> > > freebsd-hackers@freebsd.org mailing list
> > > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> > > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
> > 
> > 
> > 
> > ------------------------------
> > 
> > Message: 3
> > Date: Fri, 19 Dec 2008 23:28:46 +0000
> > From: Ferner Cilloniz 
> > Subject: Re: adding proc to allproc
> > To: Julian Elischer 
> > Cc: freebsd-hackers@freebsd.org
> > Message-ID: <1229729326.5614.16.camel@mobiliare.Belkin>
> > Content-Type: text/plain
> > 
> > When i run the code from a KLD it hangs the system. No reboot occurs
> > however, it just hangs there.
> > 
> > 
> > On Fri, 2008-12-19 at 21:27 -0800, Julian Elischer wrote:
> > > Ferner Cilloniz wrote:
> > > > Hello everyone.
> > > > 
> > > > I am playing with freebsd and just learning some things about the
> > > > FreeBSD kernel. 
> > > > 
> > > > So for my first quest i am placing random processes from the allproc
> > > > list into a list of my own and trying to add them back into allproc
> > > > 
> > > > I have pasted the code below.
> > > > 
> > > > -----------------------------------------------------------------------
> > > > struct proc *p = a process from my own list;
> > > > if( p != NULL && (p->p_state == PRS_NEW || p->p_state == PRS_NORMAL) ){
> > > >        LIST_INSERT_HEAD(&allproc, p, p_list);
> > > > }
> > > > -----------------------------------------------------------------------
> > > > 
> > > > Thanks.
> > > 
> > > and your question is?
> > > 
> > > 
> > > > 
> > > > _______________________________________________
> > > > freebsd-hackers@freebsd.org mailing list
> > > > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> > > > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
> > > 
> > -- 
> > Cilloniz Bicchi, Ferner
> > 
> > Research Assistant
> > Dept. of Computer Sciences
> > The University of Texas at Austin
> > http://www.cs.utexas.edu/~fernercc
> > fernercc@cs.utexas.edu
> > 
> > 
> > 
> > ------------------------------
> > 
> > Message: 4
> > Date: Fri, 19 Dec 2008 21:39:20 -0800
> > From: Julian Elischer 
> > Subject: Re: adding proc to allproc
> > To: Ferner Cilloniz 
> > Cc: freebsd-hackers@freebsd.org
> > Message-ID: <494C8508.2020000@elischer.org>
> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> > 
> > Ferner Cilloniz wrote:
> > > When i run the code from a KLD it hangs the system. No reboot occurs
> > > however, it just hangs there.
> > 
> > well, firstly you have no locking though that would probably let you 
> > get away with it most times.
> > 
> > Where does the process come from in the first place?
> > 
> > It sounds like you are making a circular list somewhere or somehow...
> > 
> > have you tried going into ddb?
> > 
> > 
> > 
> > 
> > > 
> > > 
> > > On Fri, 2008-12-19 at 21:27 -0800, Julian Elischer wrote:
> > >> Ferner Cilloniz wrote:
> > >>> Hello everyone.
> > >>>
> > >>> I am playing with freebsd and just learning some things about the
> > >>> FreeBSD kernel. 
> > >>>
> > >>> So for my first quest i am placing random processes from the allproc
> > >>> list into a list of my own and trying to add them back into allproc
> > >>>
> > >>> I have pasted the code below.
> > >>>
> > >>> -----------------------------------------------------------------------
> > >>> struct proc *p = a process from my own list;
> > >>> if( p != NULL && (p->p_state == PRS_NEW || p->p_state == PRS_NORMAL) ){
> > >>>        LIST_INSERT_HEAD(&allproc, p, p_list);
> > >>> }
> > >>> -----------------------------------------------------------------------
> > 
> > >>
> > >>> _______________________________________________
> > >>> freebsd-hackers@freebsd.org mailing list
> > >>> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> > >>> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
> > 
> > 
> > 
> > ------------------------------
> > 
> > Message: 5
> > Date: Sat, 20 Dec 2008 02:23:20 +0000
> > From: Ferner Cilloniz 
> > Subject: Re: adding proc to allproc
> > To: Julian Elischer 
> > Cc: freebsd-hackers@freebsd.org
> > Message-ID: <1229739800.5614.24.camel@mobiliare.Belkin>
> > Content-Type: text/plain
> > 
> > The process comes from the allproc list.
> > I am simply iterating through this list and removing the first 1/2 of
> > allproc list and adding the removed process to my own singly linked
> > list.
> > 
> > LIST_REMOVE(current_proc, p_list);  // remove from the allproc
> > add_proc_entry(current_proc);
> > 
> > Later, i am iterating through my singly linked list and doing the below:
> > 
> > struct proc *p = current->p;
> > f( p != NULL && (p->p_state == PRS_NEW || p->p_state == PRS_NORMAL) ){
> >       LIST_INSERT_HEAD(&allproc, p, p_list);
> > }
> > 
> > Could this be causing a circular list?
> > 
> > I am adding the proc entries to my singly linked list as follows:
> > 
> > static void add_proc_entry(const struct proc *p)
> > {
> >     struct proc_ll *new_entry = (struct proc_ll*)malloc(sizeof(struct
> > proc_ll), M_TEMP, M_ZERO | M_NOWAIT);
> >     int done = 0;
> > 
> >     new_entry->p = p; // maybe doing this assignment isnt correct?
> > 
> >     if(proc_entries == NULL) {
> >         proc_entries = new_entry;
> >         return;
> >     }
> > 
> >     struct proc_ll *current = proc_entries;
> > 
> >     while(current != NULL) {
> >         if(current->next == NULL) {
> >             current->next = new_entry;
> >             break;
> >         }
> >         current = current->next;
> >     }
> > }
> > 
> > 
> > struct proc_ll {
> >     struct proc *p;
> >     struct proc_ll *next;
> > };
> > 
> > 
> > A circular list does sound like it could cause hanging to occur but the
> > above code, atleast from my eyes, doesn't seem to cause it.
> > 
> > On Fri, 2008-12-19 at 21:39 -0800, Julian Elischer wrote:
> > > Ferner Cilloniz wrote:
> > > > When i run the code from a KLD it hangs the system. No reboot occurs
> > > > however, it just hangs there.
> > > 
> > > well, firstly you have no locking though that would probably let you 
> > > get away with it most times.
> > > 
> > > Where does the process come from in the first place?
> > > 
> > > It sounds like you are making a circular list somewhere or somehow...
> > > 
> > > have you tried going into ddb?
> > > 
> > > 
> > > 
> > > 
> > > > 
> > > > 
> > > > On Fri, 2008-12-19 at 21:27 -0800, Julian Elischer wrote:
> > > >> Ferner Cilloniz wrote:
> > > >>> Hello everyone.
> > > >>>
> > > >>> I am playing with freebsd and just learning some things about the
> > > >>> FreeBSD kernel. 
> > > >>>
> > > >>> So for my first quest i am placing random processes from the allproc
> > > >>> list into a list of my own and trying to add them back into allproc
> > > >>>
> > > >>> I have pasted the code below.
> > > >>>
> > > >>> -----------------------------------------------------------------------
> > > >>> struct proc *p = a process from my own list;
> > > >>> if( p != NULL && (p->p_state == PRS_NEW || p->p_state == PRS_NORMAL) ){
> > > >>>        LIST_INSERT_HEAD(&allproc, p, p_list);
> > > >>> }
> > > >>> -----------------------------------------------------------------------
> > > 
> > > >>
> > > >>> _______________________________________________
> > > >>> freebsd-hackers@freebsd.org mailing list
> > > >>> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> > > >>> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
> > > 
> > 
> > 
> > 
> > 
> > ------------------------------
> > 
> > _______________________________________________
> > freebsd-hackers@freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
> > 
> > End of freebsd-hackers Digest, Vol 299, Issue 5
> > ***********************************************
> > 
> > 
> >        
> > _______________________________________________
> > freebsd-hackers@freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
-- 
Cilloniz Bicchi, Ferner

Research Assistant
Dept. of Computer Sciences
The University of Texas at Austin
http://www.cs.utexas.edu/~fernercc
fernercc@cs.utexas.edu

From davidxu at freebsd.org  Sat Dec 20 21:44:30 2008
From: davidxu at freebsd.org (David Xu)
Date: Sat Dec 20 21:44:38 2008
Subject: td_critnest
In-Reply-To: <95b10a340812142103u3ab8bd2br97033a7c7e8bec3@mail.gmail.com>
References: <95b10a340812142103u3ab8bd2br97033a7c7e8bec3@mail.gmail.com>
Message-ID: <494DD834.7050108@freebsd.org>

Ravi Murty wrote:
> Hello All,
> 
> The implementation of critical_enter and critical_exit changed between
> freebsd 5 and freebsd 6. In the newer implemtnation, the code checks if
> td_critnest is 1 and if it is sets it to zero, then checks if the thread
> owes a preempt. If so, it increments td_critnest by 1 before grabbing a lock
> and then decrements it back to zero. I can't figure out why it does this.
> The freebsd 5 implementation seems straightforward where we check if the
> thread owes a preempt and if so we switch to the new thread. Can anyone help
> me with this?
> 
> Thanks
> Ravi

I guess this becauses thread_lock() also calls critical_exit(), this
code avoids recursion.


From des at des.no  Sun Dec 21 14:31:20 2008
From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=)
Date: Sun Dec 21 14:31:27 2008
Subject: adding proc to allproc
In-Reply-To: <1229739800.5614.24.camel@mobiliare.Belkin> (Ferner Cilloniz's
	message of "Sat, 20 Dec 2008 02:23:20 +0000")
References: <1229726360.5614.15.camel@mobiliare.Belkin>
	<494C8246.3020703@elischer.org>
	<1229729326.5614.16.camel@mobiliare.Belkin>
	<494C8508.2020000@elischer.org>
	<1229739800.5614.24.camel@mobiliare.Belkin>
Message-ID: <86ocz55fex.fsf@ds4.des.no>

Ferner Cilloniz <fernercc@gmail.com> writes:
> The process comes from the allproc list.
> I am simply iterating through this list and removing the first 1/2 of
> allproc list and adding the removed process to my own singly linked
> list.
>
> LIST_REMOVE(current_proc, p_list);  // remove from the allproc
> add_proc_entry(current_proc);

You can't do that without holding allproc_lock.

> Later, i am iterating through my singly linked list and doing the below:
>
> struct proc *p = current->p;
> f( p != NULL && (p->p_state == PRS_NEW || p->p_state == PRS_NORMAL) ){
>       LIST_INSERT_HEAD(&allproc, p, p_list);
> }

You can't do that without holding allproc_lock.

>     struct proc_ll *new_entry = (struct proc_ll*)malloc(sizeof(struct
> proc_ll), M_TEMP, M_ZERO | M_NOWAIT);

unnecessary cast, missing NULL check

>     int done = 0;

unused variable

>     new_entry->p = p; // maybe doing this assignment isnt correct?
>
>     if(proc_entries == NULL) {
>         proc_entries = new_entry;
>         return;
>     }
>
>     struct proc_ll *current = proc_entries;
>
>     while(current != NULL) {
>         if(current->next == NULL) {
>             current->next = new_entry;
>             break;
>         }
>         current = current->next;
>     }

This is gross.  The usual idiom is

        new_entry->next = proc_entries;
        proc_entries = new_entry;

However, the simplest solution is to use the <sys/queue.h> macros.

> A circular list does sound like it could cause hanging to occur but the
> above code, atleast from my eyes, doesn't seem to cause it.

With no locking, who knows what really goes on in your code...

DES
-- 
Dag-Erling Sm?rgrav - des@des.no
From des at des.no  Sun Dec 21 14:32:33 2008
From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=)
Date: Sun Dec 21 14:32:40 2008
Subject: reg: adding proc to allproc (Ferner Cilloniz)
In-Reply-To: <823694.23548.qm@web65403.mail.ac4.yahoo.com> (Michelle Li's
	message of "Sat, 20 Dec 2008 18:05:06 -0800 (PST)")
References: <823694.23548.qm@web65403.mail.ac4.yahoo.com>
Message-ID: <86k59t5fcv.fsf@ds4.des.no>

Michelle Li <michelle_li_001@yahoo.com> writes:
> new_entry->p .....
>  is accessing the "read/write" pointer declared in the proc_ll struct
>
> new_entry->p = p; 
>   is attempting an assignment of a "read ONLY" const pointer that
>   has been passed into add_proc_entry() to a "read/write" pointer
>
> new_entry->"read/write pointer" = "read ONLY pointer";  
>    is invalid

It's bad form, but it makes no practical difference.

DES
-- 
Dag-Erling Sm?rgrav - des@des.no
From cornek at striata.com  Mon Dec 22 00:37:52 2008
From: cornek at striata.com (Corne Kotze)
Date: Mon Dec 22 00:38:02 2008
Subject: SSH Problem
Message-ID: <1229934159.8928.20.camel@jackal>

Hi all,

I have tried to register on the forums to search for any clues there,
but cannot as I keep on getting an error with regards to the image
verification.
"Image verification could not be verified due to server issues. Please
try again later."

The issue I have, hope somebody can help me, is with ssh security keys,
no matter if I use RSA or DSA keys with or without passwords, I still
have to login with a password to my FreeBSD server.
It is between a Linux server(Client server) and my FreeBSD server.

My setups are as follows:
>From client server:
Linux nagios-server 2.6.23-hardened-r4 #1 SMP
OpenSSH_4.7p1, OpenSSL 0.9.8g 19 Oct 2007


To FreeBSD server:
FreeBSD secure-server 6.1-RELEASE-p17 FreeBSD 6.1-RELEASE-p17 #0: Fri
May 25 19:54:30 IST 2007
root@secure-server:/usr/obj/usr/src/sys/SECURESRV-SMP  i386
OpenSSH_4.2p1 FreeBSD-20050903, OpenSSL 0.9.7e-p1 25 Oct 2004

In my "/etc/rc.conf":
sshd_enable="NO"
sshd2_enable="YES"


I have tried the public key in various directories, in the users home
directory, ie.
.ssh/authorized_keys
.ssh/authorized_keys2

.ssh2/authorized_keys
.ssh2/authorized_keys2

Permissions are set to 700 for the .ssh(2) directories and 600 for the
authorized_keys(2) files.

User and group access are also correct, and connection from the client
machine is also with the correct user.


If I change to the following in my "/etc/rc.conf" file:
sshd_enable="YES"
sshd2_enable="NO"

Restart sshd, the keys work fine, no issues, I connect 100% without
having to type any passwords.


Thank you kindly


CK
From rea-fbsd at codelabs.ru  Mon Dec 22 00:59:02 2008
From: rea-fbsd at codelabs.ru (Eygene Ryabinkin)
Date: Mon Dec 22 00:59:08 2008
Subject: SSH Problem
In-Reply-To: <1229934159.8928.20.camel@jackal>
References: <1229934159.8928.20.camel@jackal>
Message-ID: <dnoAcoCUUpmRgsgANBLPZChMEB8@TVy1gMAmSsiP9GTg//ziIjLy+sk>

Corne, good day.

Mon, Dec 22, 2008 at 10:22:39AM +0200, Corne Kotze wrote:
> The issue I have, hope somebody can help me, is with ssh security keys,
> no matter if I use RSA or DSA keys with or without passwords, I still
> have to login with a password to my FreeBSD server.
> It is between a Linux server(Client server) and my FreeBSD server.
> 
> My setups are as follows:
> >From client server:
> Linux nagios-server 2.6.23-hardened-r4 #1 SMP
> OpenSSH_4.7p1, OpenSSL 0.9.8g 19 Oct 2007
>
>
> To FreeBSD server:
> FreeBSD secure-server 6.1-RELEASE-p17 FreeBSD 6.1-RELEASE-p17 #0: Fri
> May 25 19:54:30 IST 2007
> root@secure-server:/usr/obj/usr/src/sys/SECURESRV-SMP  i386
> OpenSSH_4.2p1 FreeBSD-20050903, OpenSSL 0.9.7e-p1 25 Oct 2004
>
> In my "/etc/rc.conf":
> sshd_enable="NO"
> sshd2_enable="YES"

There is no 'sshd2_enable' knob, there is only 'sshd_enable' one.
The protocols (and other stuff) are configured in /etc/ssh/sshd_config.

> I have tried the public key in various directories, in the users home
> directory, ie.
> .ssh/authorized_keys
> .ssh/authorized_keys2
>
> .ssh2/authorized_keys
> .ssh2/authorized_keys2

This is also governed by host's sshd_config: by-default, .ssh/authorized_keys
are used:
-----
AuthorizedKeysFile     .ssh/authorized_keys
-----

> Permissions are set to 700 for the .ssh(2) directories and 600 for the
> authorized_keys(2) files.

That's fine.

> User and group access are also correct, and connection from the client
> machine is also with the correct user.

> If I change to the following in my "/etc/rc.conf" file:
> sshd_enable="YES"
> sshd2_enable="NO"
>
> Restart sshd, the keys work fine, no issues, I connect 100% without
> having to type any passwords.

Yes, it is expected.  Forget about sshd2_enable -- 'man sshd_config' is
your friend.  And if you're trying to enable only SSHv2, then the
default configuration of OpenSSH should be fine to you -- it allows only
v2 since ages.  For your 6.1 only v2 should allowed by-default, but you
can explicitely state it in /etc/ssh/sshd_config, just to be sure.
-- 
Eygene
 _                ___       _.--.   #
 \`.|\..----...-'`   `-._.-'_.-'`   #  Remember that it is hard
 /  ' `         ,       __.--'      #  to read the on-line manual   
 )/' _/     \   `-_,   /            #  while single-stepping the kernel.
 `-'" `"\_  ,_.-;_.-\_ ',  fsc/as   #
     _.-'_./   {_.'   ; /           #    -- FreeBSD Developers handbook 
    {_.-``-'         {_/            #
-------------- 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-hackers/attachments/20081222/3dcaf1d0/attachment.pgp
From cornek at striata.com  Mon Dec 22 01:22:11 2008
From: cornek at striata.com (Corne Kotze)
Date: Mon Dec 22 01:22:18 2008
Subject: SSH Problem
In-Reply-To: <dnoAcoCUUpmRgsgANBLPZChMEB8@TVy1gMAmSsiP9GTg//ziIjLy+sk>
References: <1229934159.8928.20.camel@jackal>
	<dnoAcoCUUpmRgsgANBLPZChMEB8@TVy1gMAmSsiP9GTg//ziIjLy+sk>
Message-ID: <1229937727.8928.24.camel@jackal>

Hi Eygene,

Thank for the reply.
Sorry for the ignorance, but I should have added this as well.

I am running apart from other things, a secure ftp server on this box as
well that chroot the users to their home directories.

I got the setup information from the following link:
http://www.bsdguides.org/guides/freebsd/security/sftp_chroot_users.php


Setting the "rc.conf" file to:
sshd_enable="YES"
sshd2_enable="NO"

Then my sftp setup does not work properly, unless I am missing something
that I can set in the "/etc/ssh/sshd_config" file.


Thanks again.

CK





On Mon, 2008-12-22 at 11:58 +0300, Eygene Ryabinkin wrote:

> Corne, good day.
> 
> Mon, Dec 22, 2008 at 10:22:39AM +0200, Corne Kotze wrote:
> > The issue I have, hope somebody can help me, is with ssh security keys,
> > no matter if I use RSA or DSA keys with or without passwords, I still
> > have to login with a password to my FreeBSD server.
> > It is between a Linux server(Client server) and my FreeBSD server.
> > 
> > My setups are as follows:
> > >From client server:
> > Linux nagios-server 2.6.23-hardened-r4 #1 SMP
> > OpenSSH_4.7p1, OpenSSL 0.9.8g 19 Oct 2007
> >
> >
> > To FreeBSD server:
> > FreeBSD secure-server 6.1-RELEASE-p17 FreeBSD 6.1-RELEASE-p17 #0: Fri
> > May 25 19:54:30 IST 2007
> > root@secure-server:/usr/obj/usr/src/sys/SECURESRV-SMP  i386
> > OpenSSH_4.2p1 FreeBSD-20050903, OpenSSL 0.9.7e-p1 25 Oct 2004
> >
> > In my "/etc/rc.conf":
> > sshd_enable="NO"
> > sshd2_enable="YES"
> 
> There is no 'sshd2_enable' knob, there is only 'sshd_enable' one.
> The protocols (and other stuff) are configured in /etc/ssh/sshd_config.
> 
> > I have tried the public key in various directories, in the users home
> > directory, ie.
> > .ssh/authorized_keys
> > .ssh/authorized_keys2
> >
> > .ssh2/authorized_keys
> > .ssh2/authorized_keys2
> 
> This is also governed by host's sshd_config: by-default, .ssh/authorized_keys
> are used:
> -----
> AuthorizedKeysFile     .ssh/authorized_keys
> -----
> 
> > Permissions are set to 700 for the .ssh(2) directories and 600 for the
> > authorized_keys(2) files.
> 
> That's fine.
> 
> > User and group access are also correct, and connection from the client
> > machine is also with the correct user.
> 
> > If I change to the following in my "/etc/rc.conf" file:
> > sshd_enable="YES"
> > sshd2_enable="NO"
> >
> > Restart sshd, the keys work fine, no issues, I connect 100% without
> > having to type any passwords.
> 
> Yes, it is expected.  Forget about sshd2_enable -- 'man sshd_config' is
> your friend.  And if you're trying to enable only SSHv2, then the
> default configuration of OpenSSH should be fine to you -- it allows only
> v2 since ages.  For your 6.1 only v2 should allowed by-default, but you
> can explicitely state it in /etc/ssh/sshd_config, just to be sure.






Corne Kotze
Systems Administrator

Striata messaging innovation

E: corne.kotze@za.striata.com
T: +27 11 530 9600     
F: +27 11 447 9122

This email and all contents are subject to the following disclaimer:

http://www.striata.com/_disclaimer/
From rea-fbsd at codelabs.ru  Mon Dec 22 02:22:30 2008
From: rea-fbsd at codelabs.ru (Eygene Ryabinkin)
Date: Mon Dec 22 02:22:38 2008
Subject: SSH Problem
In-Reply-To: <1229937727.8928.24.camel@jackal>
References: <1229934159.8928.20.camel@jackal>
	<dnoAcoCUUpmRgsgANBLPZChMEB8@TVy1gMAmSsiP9GTg//ziIjLy+sk>
	<1229937727.8928.24.camel@jackal>
Message-ID: <cltDob8TEMUTzywLFmwwThH6z5o@TVy1gMAmSsiP9GTg//ziIjLy+sk>

Corne,

Mon, Dec 22, 2008 at 11:22:07AM +0200, Corne Kotze wrote:
> Thank for the reply.
> Sorry for the ignorance, but I should have added this as well.
>
> I am running apart from other things, a secure ftp server on this box as
> well that chroot the users to their home directories.
>
> I got the setup information from the following link:
> http://www.bsdguides.org/guides/freebsd/security/sftp_chroot_users.php

Ahm, SSH.com's realization of SSH suite.  Forgot about this, sorry.
I had never used it, so can't say how to make it work with public key
authentication.  But read on ;))

However, OpenSSH had gained the chroot ability in February 2008,
  http://undeadly.org/cgi?action=article&sid=20080220110039

But if you're running 6.x, you won't be able to use it -- it was
imported only to 7.x and -CURRENT,
  SVN rev 182634 on 2008-09-01 20:03:13Z by des

Though, no hope is lost -- security/openssh-portable is at 5.0p1, and
chroot support is there.  But it is prone to the X11 MITM attack (at
least on HP/UX, don't currently know is FreeBSD is affected),
  http://www.openssh.com/txt/release-5.1
Your mileage may vary, if, for example, you're not using X11 forwarding,
then you might be fine with this.

> Setting the "rc.conf" file to:
> sshd_enable="YES"
> sshd2_enable="NO"
>
> Then my sftp setup does not work properly, unless I am missing something
> that I can set in the "/etc/ssh/sshd_config" file.

Ooookey, if you still prefer SSH.com's software, you may find the following
article very enlightening,
  http://www.ssh.com/support/documentation/online/ssh/adminguide/32/Public-Key_Authentication-2.html

At least for me it looks very sane and verbose.
-- 
Eygene
 _                ___       _.--.   #
 \`.|\..----...-'`   `-._.-'_.-'`   #  Remember that it is hard
 /  ' `         ,       __.--'      #  to read the on-line manual   
 )/' _/     \   `-_,   /            #  while single-stepping the kernel.
 `-'" `"\_  ,_.-;_.-\_ ',  fsc/as   #
     _.-'_./   {_.'   ; /           #    -- FreeBSD Developers handbook 
    {_.-``-'         {_/            #
-------------- 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-hackers/attachments/20081222/f98d31da/attachment.pgp
From des at des.no  Mon Dec 22 04:29:28 2008
From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=)
Date: Mon Dec 22 04:29:34 2008
Subject: SSH Problem
In-Reply-To: <1229934159.8928.20.camel@jackal> (Corne Kotze's message of "Mon, 
	22 Dec 2008 10:22:39 +0200")
References: <1229934159.8928.20.camel@jackal>
Message-ID: <868wq8jsux.fsf@ds4.des.no>

Corne Kotze <cornek@striata.com> writes:
> "Image verification could not be verified due to server issues. Please
> try again later."

This message has absolutely nothing to do with SSH.

> In my "/etc/rc.conf":
> sshd_enable="NO"
> sshd2_enable="YES"

This disables sshd entirely.  There is no sshd2 in FreeBSD.

> If I change to the following in my "/etc/rc.conf" file:
> sshd_enable="YES"
> sshd2_enable="NO"

This enables sshd.

DES
-- 
Dag-Erling Sm?rgrav - des@des.no
From gerryw at compvia.com  Mon Dec 22 16:35:38 2008
From: gerryw at compvia.com (Gerry Weaver)
Date: Mon Dec 22 16:35:46 2008
Subject: How to access kernel memory from user space
Message-ID: <20081223000534.f740ca8a@mail01.compvia.com>

Hello All,

I am working on a driver that collects various network statistics via pfil. I have a simple array of structures that I use to store the statistics. I also have a user space process that needs to collect these statistics every second or so. A copy operation from kernel to user space would be too expensive. Is there a mechanism that would allow me to gain direct access to my kernel array from user space? The user process would only need read access. It seems like maybe this could be done with mmap, but since this is not a character driver, there is no device file etc.. I'm a newbie, so I apologize if this is something that should be obvious.


Thanks in advance,
Gerry
From assaulter0x80 at gmail.com  Mon Dec 22 17:30:56 2008
From: assaulter0x80 at gmail.com (Jacky Oh)
Date: Mon Dec 22 17:31:02 2008
Subject: Fwd: How to access kernel memory from user space
In-Reply-To: <ed8027db0812221720u4e9398f0i1b7a829c9acc9249@mail.gmail.com>
References: <20081223000534.f740ca8a@mail01.compvia.com>
	<ed8027db0812221720u4e9398f0i1b7a829c9acc9249@mail.gmail.com>
Message-ID: <ed8027db0812221730q51ba4e41o43b9f0089d5da2e6@mail.gmail.com>

hi Gerry..
you may be interested in the following functions:

int copyin(const void *uaddr, void *kaddr, size_t len);
int copyout(const void *kaddr, void *uaddr, size_t len);
int copyinstr(const void *uaddr, void *kaddr, size_t len, size_t *done);
int bcopy(const void *src, const void *dst, len);

this functions are using for syscalls related work, among other
things..lucky!!

Jacky Ohwers

2008/12/23 Gerry Weaver <gerryw@compvia.com>

Hello All,
>
> I am working on a driver that collects various network statistics via pfil.
> I have a simple array of structures that I use to store the statistics. I
> also have a user space process that needs to collect these statistics every
> second or so. A copy operation from kernel to user space would be too
> expensive. Is there a mechanism that would allow me to gain direct access to
> my kernel array from user space? The user process would only need read
> access. It seems like maybe this could be done with mmap, but since this is
> not a character driver, there is no device file etc.. I'm a newbie, so I
> apologize if this is something that should be obvious.
>
>
> Thanks in advance,
> Gerry
> _______________________________________________
> freebsd-hackers@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
>
From assaulter0x80 at gmail.com  Mon Dec 22 17:45:52 2008
From: assaulter0x80 at gmail.com (Jacky Oh)
Date: Mon Dec 22 17:46:00 2008
Subject: How to access kernel memory from user space
In-Reply-To: <20081223000534.f740ca8a@mail01.compvia.com>
References: <20081223000534.f740ca8a@mail01.compvia.com>
Message-ID: <ed8027db0812221720u4e9398f0i1b7a829c9acc9249@mail.gmail.com>

hi Gerry..


you may be interested in the following functions:

int copyin(const void *uaddr, void *kaddr, size_t len);
int copyout(const void *kaddr, void *uaddr, size_t len);
int copyinstr(const void *uaddr, void *kaddr, size_t len, size_t *done);
int bcopy(const void *src, const void *dst, len);

this functions are using for syscalls related work, among other
things..lucky!!

Jacky Ohwers

2008/12/23 Gerry Weaver <gerryw@compvia.com>

> Hello All,
>
> I am working on a driver that collects various network statistics via pfil.
> I have a simple array of structures that I use to store the statistics. I
> also have a user space process that needs to collect these statistics every
> second or so. A copy operation from kernel to user space would be too
> expensive. Is there a mechanism that would allow me to gain direct access to
> my kernel array from user space? The user process would only need read
> access. It seems like maybe this could be done with mmap, but since this is
> not a character driver, there is no device file etc.. I'm a newbie, so I
> apologize if this is something that should be obvious.
>
>
> Thanks in advance,
> Gerry
> _______________________________________________
> freebsd-hackers@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
>
From rdivacky at freebsd.org  Tue Dec 23 01:06:57 2008
From: rdivacky at freebsd.org (Roman Divacky)
Date: Tue Dec 23 01:07:03 2008
Subject: How to access kernel memory from user space
In-Reply-To: <20081223000534.f740ca8a@mail01.compvia.com>
References: <20081223000534.f740ca8a@mail01.compvia.com>
Message-ID: <20081223090148.GA16158@freebsd.org>

On Mon, Dec 22, 2008 at 06:05:34PM -0600, Gerry Weaver wrote:
> Hello All,
> 
> I am working on a driver that collects various network statistics via pfil. I have a simple array of structures that I use to store the statistics. I also have a user space process that needs to collect these statistics every second or so. A copy operation from kernel to user space would be too expensive. Is there a mechanism that would allow me to gain direct access to my kernel array from user space? The user process would only need read access. It seems like maybe this could be done with mmap, but since this is not a character driver, there is no device file etc.. I'm a newbie, so I apologize if this is something that should be obvious.

would it be feasible to allocate a buffer in userspace and map it into the kernelspace?
if so, I believe sf_buf (man 9 sf_buf) should work


   roman
From tut at nhamon.com.ua  Tue Dec 23 03:03:26 2008
From: tut at nhamon.com.ua (Artem Naluzhnyy)
Date: Tue Dec 23 03:04:03 2008
Subject: RFD: support of per script nice(1) value in periodic.conf(5)
Message-ID: <65dfa4fc0812230303h65134bf0r2db3a1af625c5b0b@mail.gmail.com>

bin/129814


The patch adds support of per periodic(8) script nice(1) value the
script will be run at (similar to "<service>_nice" variables in
rc.conf). There are two features:

  * default_nice variable - default nice level
  * <basename>_<script>_nice variables - nice level for a specific script

Default behavior after the patch application is still the same - no
nice level changes.

periodic.conf(5) example:

  default_nice=10
  daily_status_mail_rejects_enable="YES"
  daily_status_mail_rejects_nice=8

-- 
Artem Naluzhnyy
From ed at 80386.nl  Tue Dec 23 05:59:52 2008
From: ed at 80386.nl (Ed Schouten)
Date: Tue Dec 23 05:59:59 2008
Subject: [Testers wanted] vt100/xterm-support for syscons
Message-ID: <20081223135951.GX1176@hoeg.nl>

Hello all,

Some time ago I sent a message to the lists about vt100/xterm/UTF-8
support for syscons. I think the code is pretty stable now and after
some minor improvements/fixes, it should be ready to hit the tree.

I'm sending this message to this list, because it would be nice if
people could test the patch before I commit it. Especially if people
with different fonts/keymaps could test it, it would be really nice.

Patches are available at:

	http://people.FreeBSD.org/~ed/mpsafetty/

Some random notes:

- The patch also contains some WIP manual pages of the MPSAFE TTY code.
  These won't be committed.

- PC98 will not be affected by this patch. The PC98 port has a custom
  scterm module, which shall be left intact.

- UTF-8 support has not been enabled. We need to fix other things first
  (keyboard input, fonts, etc) before we can enable it. If people
  already want to test the UTF-8 handling of the terminal emulator, they
  can search for `TEKEN_UTF8' in teken.h.

- I'm still leaving $TERM set to `cons25'. You can already do
  experiments by changing it to `xterm-color'. It should work pretty
  good, but we don't have support for SCS (Set Character Set) yet. This
  means things like box drawing will be broken if you enable it. I
  guess this should be fixed after we gain UTF-8 support. We can then
  just convert the character sets to their Unicode equivalents.

- Try SSH'ing/telneting to your Cisco/HP/etc network devices. This
  should work pretty good now.

If no serious issues turn up that I've not been able to fix before the
end of the year, I'll commit it one of the first days of January.
Thanks!

-- 
 Ed Schouten <ed@80386.nl>
 WWW: http://80386.nl/
-------------- 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-hackers/attachments/20081223/54632f53/attachment.pgp
From Andre.Albsmeier at siemens.com  Tue Dec 23 09:53:44 2008
From: Andre.Albsmeier at siemens.com (Andre Albsmeier)
Date: Tue Dec 23 09:54:00 2008
Subject: How to "detach" a foreign driver from a device so my driver
	can attach?
In-Reply-To: <20081216230430.GA24352@curry.mchp.siemens.de>
References: <20081216230430.GA24352@curry.mchp.siemens.de>
Message-ID: <20081223173322.GA4123@curry.mchp.siemens.de>

On Wed, 17-Dec-2008 at 00:04:30 +0100, Andre Albsmeier wrote:
> Hello all,
> 
> I am writing a driver which attaches to the Host-PCI bridge. When
> compiled into the kernel or loaded by the loader everything works
> and the driver gets attached. This is due to the fact that I return
> BUS_PROBE_SPECIFIC in my probe routine which gains over the -10000
> returned by pci_hostb_probe() in i386/pci/pci_bus.c.
> 
> However, when I want to load my driver via kldload this fails since
> the hostb device has already been attached during kernel load (when
> my driver was not present):
> 
> hostb0@pci0:0:0:    class=0x060000 card=0x11d510cf chip=0x35808086 rev=0x02 hdr=0x00
> 
> What can I do to make my driver load via kldload?
> Is there a way to detach the hostb0 from the Host-PCI bridge?

Found the answer myself but will post it here in case anyone
got a similar problem one day: I added the device detach method
for the hostb driver to sys/i386/pci/pci_bus.c:

--- sys/i386/pci/pci_bus.c.ORI	2007-08-17 08:12:33.000000000 +0200
+++ sys/i386/pci/pci_bus.c	2008-12-23 13:34:35.000000000 +0100
@@ -619,10 +619,13 @@
 	return 0;
 }
 
+static int pci_hostb_detach(device_t dev) { return 0; }
+
 static device_method_t pci_hostb_methods[] = {
 	/* Device interface */
 	DEVMETHOD(device_probe,		pci_hostb_probe),
 	DEVMETHOD(device_attach,	pci_hostb_attach),
+	DEVMETHOD(device_detach,	pci_hostb_detach),
 	DEVMETHOD(device_shutdown,	bus_generic_shutdown),
 	DEVMETHOD(device_suspend,	bus_generic_suspend),
 	DEVMETHOD(device_resume,	bus_generic_resume),

Now, when kldload'ing my driver, it can walk through all devices
and detach hostb using device_detach().

	-Andre
From keramida at freebsd.org  Tue Dec 23 11:21:53 2008
From: keramida at freebsd.org (Giorgos Keramidas)
Date: Tue Dec 23 11:22:00 2008
Subject: [Testers wanted] vt100/xterm-support for syscons
In-Reply-To: <20081223135951.GX1176@hoeg.nl> (Ed Schouten's message of "Tue,
	23 Dec 2008 14:59:51 +0100")
References: <20081223135951.GX1176@hoeg.nl>
Message-ID: <87zlim90gx.fsf@kobe.laptop>

On Tue, 23 Dec 2008 14:59:51 +0100, Ed Schouten <ed@80386.nl> wrote:
> Hello all,
> Some time ago I sent a message to the lists about vt100/xterm/UTF-8
> support for syscons. I think the code is pretty stable now and after
> some minor improvements/fixes, it should be ready to hit the tree.
>
> I'm sending this message to this list, because it would be nice if
> people could test the patch before I commit it. Especially if people
> with different fonts/keymaps could test it, it would be really nice.
>
> Patches are available at:
>
> 	http://people.FreeBSD.org/~ed/mpsafetty/

Hi Ed,

Do we just pick the latest version of mpsafetty changes?

I think I might be able to run a few tests with the xterm support patch
during the next week.

> If no serious issues turn up that I've not been able to fix before the
> end of the year, I'll commit it one of the first days of January.

Heh, that would be a good New Year's gift :-)

I have been using screen and a .bashrc snippet that sets TERM=vt220
inside screen until now.  This has proved to be a remarkably good
combination for [ FreeBSD console -> screen -> TERM=vt220 -> ssh ]
sessions to BSD, Linux *and* Solaris systems.

I suspect having full `TERM=xterm' support in the console would make at
least half of this setup obsolete and make ssh connections to non-BSD
systems Just Work(TM) without the screen+vt220 hack!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20081223/a27276a3/attachment.pgp
From ed at 80386.nl  Tue Dec 23 11:34:42 2008
From: ed at 80386.nl (Ed Schouten)
Date: Tue Dec 23 11:34:50 2008
Subject: [Testers wanted] vt100/xterm-support for syscons
In-Reply-To: <87zlim90gx.fsf@kobe.laptop>
References: <20081223135951.GX1176@hoeg.nl> <87zlim90gx.fsf@kobe.laptop>
Message-ID: <20081223193441.GD1176@hoeg.nl>

* Giorgos Keramidas <keramida@freebsd.org> wrote:
> On Tue, 23 Dec 2008 14:59:51 +0100, Ed Schouten <ed@80386.nl> wrote:
> > Hello all,
> > Some time ago I sent a message to the lists about vt100/xterm/UTF-8
> > support for syscons. I think the code is pretty stable now and after
> > some minor improvements/fixes, it should be ready to hit the tree.
> >
> > I'm sending this message to this list, because it would be nice if
> > people could test the patch before I commit it. Especially if people
> > with different fonts/keymaps could test it, it would be really nice.
> >
> > Patches are available at:
> >
> > 	http://people.FreeBSD.org/~ed/mpsafetty/
> 
> Hi Ed,
> 
> Do we just pick the latest version of mpsafetty changes?

Yes. Just download the latest version of the diff.

> I think I might be able to run a few tests with the xterm support patch
> during the next week.

Thanks!

-- 
 Ed Schouten <ed@80386.nl>
 WWW: http://80386.nl/
-------------- 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-hackers/attachments/20081223/ba0a9afd/attachment.pgp
From peterjeremy at optushome.com.au  Wed Dec 24 00:45:20 2008
From: peterjeremy at optushome.com.au (Peter Jeremy)
Date: Wed Dec 24 00:45:27 2008
Subject: How to access kernel memory from user space
In-Reply-To: <20081223000534.f740ca8a@mail01.compvia.com>
References: <20081223000534.f740ca8a@mail01.compvia.com>
Message-ID: <20081224084445.GA1081@server.vk2pj.dyndns.org>

On 2008-Dec-22 18:05:34 -0600, Gerry Weaver <gerryw@compvia.com> wrote:
>I am working on a driver that collects various network statistics via
>pfil. I have a simple array of structures that I use to store the
>statistics. I also have a user space process that needs to collect
>these statistics every second or so.

The easiest (and hackiest) approach would be to kldsym(2) to locate
the symbol in KVM and then mmap(2) the relevant part of /dev/kmem.
The biggest downside is that the userland process needs to be group
kmem.

The other approach would be for your kernel driver to grow a character
device node and directly support mmap.

-- 
Peter Jeremy
Please excuse any delays as the result of my ISP's inability to implement
an MTA that is either RFC2821-compliant or matches their claimed behaviour.
-------------- 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-hackers/attachments/20081224/d7dc8098/attachment.pgp
From ed at 80386.nl  Wed Dec 24 02:24:45 2008
From: ed at 80386.nl (Ed Schouten)
Date: Wed Dec 24 02:24:53 2008
Subject: [Testers wanted] vt100/xterm-support for syscons
In-Reply-To: <86y6y6ayo5.fsf@gmail.com>
References: <20081223135951.GX1176__30103.4640674063$1230042170$gmane$org@hoeg.nl>
	<86y6y6ayo5.fsf@gmail.com>
Message-ID: <20081224102444.GJ1176@hoeg.nl>

* swell.k@gmail.com <swell.k@gmail.com> wrote:
> Typing in `tcsh -f' (TERM=xterm)
> 
>     foo`^Abar
> 
> results in
> 
>     rabfoo`
> 
> with *characters* (not cursor) going from left to right. Cursor stays
> at the beginning of line until one types ^R (redisplay).
> Never happens with TERM=cons25 or TERM=vt100. Any ideas why?

Hmmmm... Strange thing is that I can't seem to reproduce this. Maybe the
terminal emulator stayed stuck in insert mode? Maybe you can reproduce
this for me by doing the following.

Go to /sys/dev/syscons/teken and run `make'. This will create a binary
called `teken_demo', which is a testing utility that simulates a
terminal using exactly the same code as syscons.

Just run this binary from an xterm (or at least a terminal we trust) and
see if you can reproduce it there. A nice thing is that you can just
restart the application, so we have a better picture of what triggered
this behaviour.

> BTW, it would be nice if xterm emulation support extension to display
> 256 colors
> 
>      :AB=\E[48;5;%dm:\
>      :AF=\E[38;5;%dm:
> 
> at least up to first batch of 8 colors and ignoring rest.

The reason why I didn't add support for 256 colors, is because it would
require fundamental changes to all syscons drivers as well. I'll look in
to it after I've committed this version.

Thanks for testing the patch!

-- 
 Ed Schouten <ed@80386.nl>
 WWW: http://80386.nl/
-------------- 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-hackers/attachments/20081224/fb058ed3/attachment.pgp
From ed at 80386.nl  Wed Dec 24 02:31:10 2008
From: ed at 80386.nl (Ed Schouten)
Date: Wed Dec 24 02:31:18 2008
Subject: [Testers wanted] vt100/xterm-support for syscons
In-Reply-To: <20081224102444.GJ1176@hoeg.nl>
References: <20081223135951.GX1176__30103.4640674063$1230042170$gmane$org@hoeg.nl>
	<86y6y6ayo5.fsf@gmail.com> <20081224102444.GJ1176@hoeg.nl>
Message-ID: <20081224103109.GK1176@hoeg.nl>

* Ed Schouten <ed@80386.nl> wrote:
> * swell.k@gmail.com <swell.k@gmail.com> wrote:
> > Typing in `tcsh -f' (TERM=xterm)
> > 
> >     foo`^Abar
> > 
> > results in
> > 
> >     rabfoo`
> > 
> > with *characters* (not cursor) going from left to right. Cursor stays
> > at the beginning of line until one types ^R (redisplay).
> > Never happens with TERM=cons25 or TERM=vt100. Any ideas why?
> 
> Hmmmm... Strange thing is that I can't seem to reproduce this.

Never mind. Now I can. I forgot to punch in the `. foo^Abar works
correctly, while foo`^Abar does not. I'll see if I can find the bug this
afternoon.

-- 
 Ed Schouten <ed@80386.nl>
 WWW: http://80386.nl/
-------------- 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-hackers/attachments/20081224/58eda06d/attachment.pgp
From ed at 80386.nl  Wed Dec 24 03:24:36 2008
From: ed at 80386.nl (Ed Schouten)
Date: Wed Dec 24 03:24:43 2008
Subject: [Testers wanted] vt100/xterm-support for syscons
In-Reply-To: <20081224103109.GK1176@hoeg.nl>
References: <20081223135951.GX1176__30103.4640674063$1230042170$gmane$org@hoeg.nl>
	<86y6y6ayo5.fsf@gmail.com> <20081224102444.GJ1176@hoeg.nl>
	<20081224103109.GK1176@hoeg.nl>
Message-ID: <20081224112435.GL1176@hoeg.nl>

* Ed Schouten <ed@80386.nl> wrote:
> Never mind. Now I can. I forgot to punch in the `. foo^Abar works
> correctly, while foo`^Abar does not. I'll see if I can find the bug this
> afternoon.

Done. Could you please try the latest mpsafetty patch (20081224)? The
problem was that the cursor didn't progress while in insert mode, while
it should. The reason why cons25 was unaffected, is because if you use
cons25, it won't use insert mode at all. Thanks for reporting the issue.

-- 
 Ed Schouten <ed@80386.nl>
 WWW: http://80386.nl/
-------------- 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-hackers/attachments/20081224/c74f8723/attachment.pgp
From universite at ukr.net  Wed Dec 24 12:09:12 2008
From: universite at ukr.net (Vladislav V. Prodan)
Date: Wed Dec 24 12:42:34 2008
Subject: Odd behavior routed
Message-ID: <49528E6F.30600@ukr.net>

# uname -a
FreeBSD mary-teresa.XXXXX 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Wed Dec 24 
05:06:55 EET 2008 
vlad11@mary-teresa.XXXXX:/usr/obj/usr/src/sys/mary-teresa.10  amd64

We have two providers on tun1 and tun2.

 >>/etc/rc.conf:
...
gateway_enable="YES"
router="/sbin/routed"
router_enable="YES"
router_flags="-s -T /var/log/routed.log -P no_rip"
...

# netstat -rn
Routing tables

Internet:
Destination        Gateway            Flags    Refs      Use  Netif Expire
default            89.209.95.254      UGS         0   653418   tun1
10.0.0.0/24        link#1             U           0    85595    re0
85.238.109.61      127.0.0.1          UH          0        0    lo0
89.209.XX.YY       127.0.0.1          UH          0      483    lo0
89.209.95.254      89.209.XX.YY       UH          0        0   tun1
127.0.0.1          link#6             UH          0    19781    lo0
192.168.152.0/24   10.0.0.20          UGS         0        0    re0
195.138.80.168     link#8             UH          0        5   tun2

Internet6:
Destination                       Gateway                       Flags 
  Netif Expire
::1                               link#6                        UH     lo0
fe80::%lo0/64                     link#6                        U     lo0
ff01:6::/32                       fe80::1%lo0                   U     lo0
ff01:7::/32                       fe80::2e0:4dff:fe7b:690c%tun1 UG    tun1
ff01:8::/32                       fe80::2e0:4dff:fe7b:690c%tun2 UG    tun2
ff02::%lo0/32                     fe80::1%lo0                   U     lo0
ff02::%tun1/32                    fe80::2e0:4dff:fe7b:690c%tun1 UG    tun1
ff02::%tun2/32                    fe80::2e0:4dff:fe7b:690c%tun2 UG    tun2


I would like to put some networks via a second ISP:
# /sbin/route add -net 79.140.0.0/20 -iface tun2
add net 79.140.0.0: gateway tun2
# /sbin/route add -net 85.238.96.0/19 -iface tun2
add net 85.238.96.0: gateway tun2
# /sbin/route add -net 195.138.64.0/19 -iface tun2
add net 195.138.64.0: gateway tun2

But routes do not appear, the table remains unchanged.
In the logs routed:

RTM_ADD from pid 7234: 79.140.0.0 (mask 0xfffff000) --> 85.238.109.61
static route 79.140.0.0 (mask 0xfffff000) --> 85.238.109.61 impossibly 
lacks ifp
-- 11:35:16 --
RTM_ADD from pid 7250: 85.238.96.0 (mask 0xffffe000) --> 85.238.109.61
static route 85.238.96.0 (mask 0xffffe000) --> 85.238.109.61 impossibly 
lacks ifp
-- 11:35:28 --
RTM_ADD from pid 7262: 195.138.64.0 (mask 0xffffe000) --> 85.238.109.61
static route 195.138.64.0 (mask 0xffffe000) --> 85.238.109.61 impossibly 
lacks ifp


Before rebuild kernel, it appeared, and now there is no.
It is now adding routes?

Using gated|quagga|zebra does not offer.


From gerryw at compvia.com  Wed Dec 24 13:22:20 2008
From: gerryw at compvia.com (Gerry Weaver)
Date: Wed Dec 24 13:22:27 2008
Subject: How to access kernel memory from user space
In-Reply-To: 20081224084445.GA1081@server.vk2pj.dyndns.org
Message-ID: <20081224212207.4cc4874b@mail01.compvia.com>

_____  

From: Peter Jeremy [mailto:peterjeremy@optushome.com.au]
To: Gerry Weaver [mailto:gerryw@compvia.com]
Cc: freebsd-hackers@freebsd.org
Sent: Wed, 24 Dec 2008 02:44:45 -0600
Subject: Re: How to access kernel memory from user space

On 2008-Dec-22 18:05:34 -0600, Gerry Weaver <gerryw@compvia.com> wrote:
  >I am working on a driver that collects various network statistics via
  >pfil. I have a simple array of structures that I use to store the
  >statistics. I also have a user space process that needs to collect
  >these statistics every second or so.
  
  The easiest (and hackiest) approach would be to kldsym(2) to locate
  the symbol in KVM and then mmap(2) the relevant part of /dev/kmem.
  The biggest downside is that the userland process needs to be group
  kmem.
  
  The other approach would be for your kernel driver to grow a character
  device node and directly support mmap.
  
  -- 
  Peter Jeremy
  Please excuse any delays as the result of my ISP's inability to implement
  an MTA that is either RFC2821-compliant or matches their claimed behaviour.Hello All,

Happy Holidays Everyone!!

Thanks for the advice Peter. In this case, the driver I'm working on will run on a dedicated
embedded platform, so process group membership shouldn't be an issue. My main 
concern is performance. Any additional overhead will effect the stats, so I want to try
to keep it minimal. Is there any significant trade off in performance between the two
approaches? The typical data array size is around 20k. Also, Is there anything in the source
or ports tree that I could use as an example for the device node case? I've been looking around,
but haven't found anything yet. I'll continue digging though ;-)

Thanks Again,
Gerry


  
From qing.li at bluecoat.com  Wed Dec 24 16:46:04 2008
From: qing.li at bluecoat.com (Li, Qing)
Date: Wed Dec 24 16:46:11 2008
Subject: Odd behavior routed
In-Reply-To: <49528E6F.30600@ukr.net>
References: <49528E6F.30600@ukr.net>
Message-ID: <B583FBF374231F4A89607B4D08578A4302A8BFAF@bcs-mail03.internal.cacheflow.com>

Hi,

Could you please provide the ifconfig output for completeness ?

Thanks,

-- Qing


> -----Original Message-----
> From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd-
> net@freebsd.org] On Behalf Of Vladislav V. Prodan
> Sent: Wednesday, December 24, 2008 11:33 AM
> To: freebsd-current@freebsd.org; freebsd-net@freebsd.org
> Cc: freebsd-hackers@freebsd.org
> Subject: Odd behavior routed
> 
> # uname -a
> FreeBSD mary-teresa.XXXXX 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Wed Dec
> 24
> 05:06:55 EET 2008
> vlad11@mary-teresa.XXXXX:/usr/obj/usr/src/sys/mary-teresa.10  amd64
> 
> We have two providers on tun1 and tun2.
> 
>  >>/etc/rc.conf:
> ...
> gateway_enable="YES"
> router="/sbin/routed"
> router_enable="YES"
> router_flags="-s -T /var/log/routed.log -P no_rip"
> ...
> 
> # netstat -rn
> Routing tables
> 
> Internet:
> Destination        Gateway            Flags    Refs      Use  Netif
> Expire
> default            89.209.95.254      UGS         0   653418   tun1
> 10.0.0.0/24        link#1             U           0    85595    re0
> 85.238.109.61      127.0.0.1          UH          0        0    lo0
> 89.209.XX.YY       127.0.0.1          UH          0      483    lo0
> 89.209.95.254      89.209.XX.YY       UH          0        0   tun1
> 127.0.0.1          link#6             UH          0    19781    lo0
> 192.168.152.0/24   10.0.0.20          UGS         0        0    re0
> 195.138.80.168     link#8             UH          0        5   tun2
> 
> Internet6:
> Destination                       Gateway                       Flags
>   Netif Expire
> ::1                               link#6                        UH
> lo0
> fe80::%lo0/64                     link#6                        U
> lo0
> ff01:6::/32                       fe80::1%lo0                   U
> lo0
> ff01:7::/32                       fe80::2e0:4dff:fe7b:690c%tun1 UG
> tun1
> ff01:8::/32                       fe80::2e0:4dff:fe7b:690c%tun2 UG
> tun2
> ff02::%lo0/32                     fe80::1%lo0                   U
> lo0
> ff02::%tun1/32                    fe80::2e0:4dff:fe7b:690c%tun1 UG
> tun1
> ff02::%tun2/32                    fe80::2e0:4dff:fe7b:690c%tun2 UG
> tun2
> 
> 
> I would like to put some networks via a second ISP:
> # /sbin/route add -net 79.140.0.0/20 -iface tun2
> add net 79.140.0.0: gateway tun2
> # /sbin/route add -net 85.238.96.0/19 -iface tun2
> add net 85.238.96.0: gateway tun2
> # /sbin/route add -net 195.138.64.0/19 -iface tun2
> add net 195.138.64.0: gateway tun2
> 
> But routes do not appear, the table remains unchanged.
> In the logs routed:
> 
> RTM_ADD from pid 7234: 79.140.0.0 (mask 0xfffff000) --> 85.238.109.61
> static route 79.140.0.0 (mask 0xfffff000) --> 85.238.109.61 impossibly
> lacks ifp
> -- 11:35:16 --
> RTM_ADD from pid 7250: 85.238.96.0 (mask 0xffffe000) --> 85.238.109.61
> static route 85.238.96.0 (mask 0xffffe000) --> 85.238.109.61 impossibly
> lacks ifp
> -- 11:35:28 --
> RTM_ADD from pid 7262: 195.138.64.0 (mask 0xffffe000) --> 85.238.109.61
> static route 195.138.64.0 (mask 0xffffe000) --> 85.238.109.61
> impossibly
> lacks ifp
> 
> 
> Before rebuild kernel, it appeared, and now there is no.
> It is now adding routes?
> 
> Using gated|quagga|zebra does not offer.
> 
> 
> _______________________________________________
> freebsd-net@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"
From Andre.Albsmeier at siemens.com  Thu Dec 25 01:53:35 2008
From: Andre.Albsmeier at siemens.com (Andre Albsmeier)
Date: Thu Dec 25 01:53:42 2008
Subject: Writing device drivers: How to access a specific memory area?
Message-ID: <20081225095333.GA12699@curry.mchp.siemens.de>

Hello all,

I am writing a driver which needs to access memory at a
specific location. The location depends on what the BIOS
has configured into the host bridge. For example, my
current machine uses an Intel 975X chipset and the memory
location I am interested in has been set to 0xFED14000 and
is 16KB in size (this is MCHBAR of the 975X memory hub).

I have no idea how to access this space from my driver.
I have played around with bus_alloc_resource() but this
only gives me back NULL.

However, a devinfo -r gives me:

nexus0
  npx0
  acpi0
      Interrupt request lines:
          9
      I/O ports:
          0x10-0x1f
...
          0x800-0x87f
      I/O memory addresses:
          0x0-0x9ffff
          0xc0000-0xdffff
          0xe0000-0xfffff
          0x100000-0x7fffffff
          0xf0000000-0xf3ffffff
          0xfec00000-0xfec00fff
          0xfed13000-0xfed19fff		<---
          0xfed1c000-0xfed1ffff
          0xfed20000-0xfed3ffff
          0xfed50000-0xfed8ffff
          0xfee00000-0xfee00fff
          0xffb00000-0xffbfffff
          0xfff00000-0xffffffff
    cpu0
...

The line marked with <--- shows the range which includes
the location I am interested in. It is probably assigned
to the acpi0 device.

How do I proceed from this? Do I have to hack around in
the ACPI-Code? I don't hope so ;-)

I only need access to this memory location during the
probe of my driver to read some configuration data.
I do not need to access it later anymore...

Thanks a lot for any hints,

	-Andre
From rpaulo at freebsd.org  Thu Dec 25 06:19:25 2008
From: rpaulo at freebsd.org (Rui Paulo)
Date: Thu Dec 25 06:19:32 2008
Subject: Writing device drivers: How to access a specific memory area?
In-Reply-To: <20081225095333.GA12699@curry.mchp.siemens.de>
References: <20081225095333.GA12699@curry.mchp.siemens.de>
Message-ID: <490EB16A-F626-4A40-9716-A02A32F04ED4@freebsd.org>


On 25 Dec 2008, at 09:53, Andre Albsmeier wrote:

> Hello all,
>
> I am writing a driver which needs to access memory at a
> specific location. The location depends on what the BIOS
> has configured into the host bridge. For example, my
> current machine uses an Intel 975X chipset and the memory
> location I am interested in has been set to 0xFED14000 and
> is 16KB in size (this is MCHBAR of the 975X memory hub).

You probably just need to do something like:

rid = PCI_BAR(number);
res = bus_alloc_resource_any(dev, SYS_RES_MEMORY, &rid, RF_ACTIVE);

And then,
bus_read_4(res, offset from specified PCI BAR);

>
>
> I have no idea how to access this space from my driver.
> I have played around with bus_alloc_resource() but this
> only gives me back NULL.
>
> However, a devinfo -r gives me:
>
> nexus0
>  npx0
>  acpi0
>      Interrupt request lines:
>          9
>      I/O ports:
>          0x10-0x1f
> ...
>          0x800-0x87f
>      I/O memory addresses:
>          0x0-0x9ffff
>          0xc0000-0xdffff
>          0xe0000-0xfffff
>          0x100000-0x7fffffff
>          0xf0000000-0xf3ffffff
>          0xfec00000-0xfec00fff
>          0xfed13000-0xfed19fff		<---
>          0xfed1c000-0xfed1ffff
>          0xfed20000-0xfed3ffff
>          0xfed50000-0xfed8ffff
>          0xfee00000-0xfee00fff
>          0xffb00000-0xffbfffff
>          0xfff00000-0xffffffff
>    cpu0
> ...
>
> The line marked with <--- shows the range which includes
> the location I am interested in. It is probably assigned
> to the acpi0 device.
>
> How do I proceed from this? Do I have to hack around in
> the ACPI-Code? I don't hope so ;-)

You'll probably need to create a fake ACPI child driver to access it.


Create your identify routine with something like:

static void mydriver_identify(driver_t *driver, device_t parent)
{
	if (device_find_child(parent, "mydriver", -1) == NULL &&
	    mydriver_match(parent))
		device_add_child(parent, "mydriver", -1);
}

mydriver_match() should check if you were given the acpi0 device.


>
>
> I only need access to this memory location during the
> probe of my driver to read some configuration data.

Is this pci configuration space ? If so, pci_read_config (man 9 pci)  
should be just what you need.

Regards,
--
Rui Paulo

From danny at cs.huji.ac.il  Thu Dec 25 06:35:45 2008
From: danny at cs.huji.ac.il (Danny Braniss)
Date: Thu Dec 25 06:35:52 2008
Subject: netapp dump/freebsd restore problem
Message-ID: <E1LFrJK-000MBg-F4@kabab.cs.huji.ac.il>

Hi,
	Some years ago I solved the problem (some swab issue) by a one
line fix to restore/tape.c, so 'rsh netapp dump ...| restore ...' worked.
	Now, while experimenting with zfs, we are tying to see if
we can dump the netapp onto a zfs for backup, but alas, the dumprestore.h has
changed.
	So, has anyone
		1- the dumprestore.h/u_spcl from NetAPP
		2- a restore that works.
	if not, then i'll have to do some reverse engineering ...

danny
PS: Season's greetings and a happy New Year!


From david at catwhisker.org  Thu Dec 25 17:14:02 2008
From: david at catwhisker.org (David Wolfskill)
Date: Thu Dec 25 17:14:09 2008
Subject: How to quickly determine if UFS2 FS is "clean" from command line?
Message-ID: <20081226011402.GP4100@albert.catwhisker.org>

At work, we have some machines we're setting up that have a fair amount
of UFS2 "scratch space."

While we would prefer to leave the file systems in question intact
iff they are "clean," we do not want to run fsck(8) against them
if they are not (because we expect that it would take too long);
rather, we want to merely recreate them (with newfs(8)).

While I might be able to hack something together by cribbing
appropriate bits of fsck_ffs(8), I'm a great deal more comfortable
cobbling up glue scripts and the like -- I don't fancy myself all
that much of a C coder.

Anyone know of a reasonable way to quickly determine whether or not
a UFS2 file system is clean from the command line?

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: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20081226/58243a0d/attachment.pgp
From bruce at cran.org.uk  Thu Dec 25 17:22:31 2008
From: bruce at cran.org.uk (Bruce Cran)
Date: Thu Dec 25 17:22:38 2008
Subject: How to quickly determine if UFS2 FS is "clean" from command
 line?
In-Reply-To: <20081226011402.GP4100@albert.catwhisker.org>
References: <20081226011402.GP4100@albert.catwhisker.org>
Message-ID: <20081226012224.2fbd579a@gluon>

On Thu, 25 Dec 2008 17:14:02 -0800
David Wolfskill <david@catwhisker.org> wrote:

> At work, we have some machines we're setting up that have a fair
> amount of UFS2 "scratch space."
> 
> While we would prefer to leave the file systems in question intact
> iff they are "clean," we do not want to run fsck(8) against them
> if they are not (because we expect that it would take too long);
> rather, we want to merely recreate them (with newfs(8)).
> 
> While I might be able to hack something together by cribbing
> appropriate bits of fsck_ffs(8), I'm a great deal more comfortable
> cobbling up glue scripts and the like -- I don't fancy myself all
> that much of a C coder.
> 
> Anyone know of a reasonable way to quickly determine whether or not
> a UFS2 file system is clean from the command line?

dumpfs will tell you the status of the 'clean' flag:

dumpfs /dev/ad0s1d | grep clean

That will output a line like:

cgrotor 0  fmod 0  ronly 0  clean 1

Just like with fsck you can also tell dumpfs the previous mountpoint
too and it'll use the right device.

-- 
Bruce Cran
From david at catwhisker.org  Thu Dec 25 17:49:56 2008
From: david at catwhisker.org (David Wolfskill)
Date: Thu Dec 25 17:50:03 2008
Subject: How to quickly determine if UFS2 FS is "clean" from command
	line?
In-Reply-To: <20081226012224.2fbd579a@gluon>
References: <20081226011402.GP4100@albert.catwhisker.org>
	<20081226012224.2fbd579a@gluon>
Message-ID: <20081226014956.GR4100@albert.catwhisker.org>

On Fri, Dec 26, 2008 at 01:22:24AM +0000, Bruce Cran wrote:
> ...
> > Anyone know of a reasonable way to quickly determine whether or not
> > a UFS2 file system is clean from the command line?
> 
> dumpfs will tell you the status of the 'clean' flag:
> 
> dumpfs /dev/ad0s1d | grep clean
> 
> That will output a line like:
> 
> cgrotor 0  fmod 0  ronly 0  clean 1
> 
> Just like with fsck you can also tell dumpfs the previous mountpoint
> too and it'll use the right device.

So this is quite useful.

A reality check later, I find that for the file systems in question,
dumpfs(8) produces the wanted information (and quite a bit more) nearly
instantly, then spends about 33 seconds dumping cylinder group
information that I have no interest in.

While I admitted not being much of a C coder, I have been known to hack
a bit.... :-}

I also see that the dumpfs(8) code has been fairly static in the last
couple of years.

Would anyone else be interested in a hack to dumpfs(8) in the form
of a command line flag (e.g., "-s" -- as in "short" or "super block
only") to tell it to just spit out the FS super block information
and skip the cylinder group stuff?  (The command presently has but one
command line flag;  it is "-m" and is optional; if present, it causes
the program to spit out a newfs(8) invocation to re-create the file
system in question.)

I'd be willing to cobble it up, test it, and submit a PR....

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: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20081226/438885e4/attachment.pgp
From bruce at cran.org.uk  Thu Dec 25 19:17:48 2008
From: bruce at cran.org.uk (Bruce Cran)
Date: Thu Dec 25 19:17:54 2008
Subject: How to quickly determine if UFS2 FS is "clean" from command
 line?
In-Reply-To: <20081226014956.GR4100@albert.catwhisker.org>
References: <20081226011402.GP4100@albert.catwhisker.org>
	<20081226012224.2fbd579a@gluon>
	<20081226014956.GR4100@albert.catwhisker.org>
Message-ID: <20081226030035.24154a3d@gluon>

On Thu, 25 Dec 2008 17:49:56 -0800
David Wolfskill <david@catwhisker.org> wrote:

> A reality check later, I find that for the file systems in question,
> dumpfs(8) produces the wanted information (and quite a bit more)
> nearly instantly, then spends about 33 seconds dumping cylinder group
> information that I have no interest in.

I only ran it on a 2GB filesystem so I didn't see how slow it is!

It looks like ffsinfo(8) can also display the superblock: by
specifying only level 0x001 it should be fast, though the flags are
combined into a single value in the output.

-- 
Bruce Cran
From david at catwhisker.org  Thu Dec 25 22:39:47 2008
From: david at catwhisker.org (David Wolfskill)
Date: Thu Dec 25 22:39:53 2008
Subject: How to quickly determine if UFS2 FS is "clean" from command
	line?
In-Reply-To: <20081226063542.GA20518@shark.localdomain>
References: <20081226011402.GP4100@albert.catwhisker.org>
	<20081226012224.2fbd579a@gluon>
	<20081226014956.GR4100@albert.catwhisker.org>
	<20081226063542.GA20518@shark.localdomain>
Message-ID: <20081226063946.GX4100@albert.catwhisker.org>

On Fri, Dec 26, 2008 at 09:35:42AM +0300, Sergey Zaharchenko wrote:
> ...
> Some of the stuff you want can be found here:
> 
> root@shark:~# file -s /dev/ufs/home 
> /dev/ufs/home: Unix Fast File system [v2] (little-endian) last mounted on /home, volume name home, last written at Fri Dec 26 06:33:07 2008, clean flag 0, readonly flag 0, number of blocks 13631488, number of data blocks 13202246, number of cylinder groups 145, block size 16384, fragment size 2048, average file size 16384, average number of files in dir 64, pending blocks to free 4, pending inodes to free 0, system-wide uuid 0, minimum percentage of free blocks 8, TIME optimization
> 
> You probably want the clean flag (which is 0 for me because that device
> node is mounted).

Very nice; thanks!  Seems that both ffsinfo(8) & file(1) can do the job
quickly; dumpfs(8) can do it, but takes around 33 seconds for a 400 GB
file system (because it also dumps the cylinder groups).

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: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20081226/80812f88/attachment.pgp
From doublef-ctm at yandex.ru  Thu Dec 25 22:54:59 2008
From: doublef-ctm at yandex.ru (Sergey Zaharchenko)
Date: Thu Dec 25 22:55:06 2008
Subject: How to quickly determine if UFS2 FS is "clean" from command
 line?
In-Reply-To: <20081226014956.GR4100@albert.catwhisker.org>
References: <20081226011402.GP4100@albert.catwhisker.org>
	<20081226012224.2fbd579a@gluon>
	<20081226014956.GR4100@albert.catwhisker.org>
Message-ID: <20081226063542.GA20518@shark.localdomain>

Hello David!

Thu, Dec 25, 2008 at 05:49:56PM -0800 you wrote:

> Would anyone else be interested in a hack to dumpfs(8) in the form
> of a command line flag (e.g., "-s" -- as in "short" or "super block
> only") to tell it to just spit out the FS super block information
> and skip the cylinder group stuff?

Some of the stuff you want can be found here:

root@shark:~# file -s /dev/ufs/home 
/dev/ufs/home: Unix Fast File system [v2] (little-endian) last mounted on /home, volume name home, last written at Fri Dec 26 06:33:07 2008, clean flag 0, readonly flag 0, number of blocks 13631488, number of data blocks 13202246, number of cylinder groups 145, block size 16384, fragment size 2048, average file size 16384, average number of files in dir 64, pending blocks to free 4, pending inodes to free 0, system-wide uuid 0, minimum percentage of free blocks 8, TIME optimization

You probably want the clean flag (which is 0 for me because that device
node is mounted).

HTH,

-- 
DoubleF
No virus detected in this message. Ehrm, wait a minute...
/kernel: pid 56921 (antivirus), uid 32000: exited on signal 9
Oh yes, no virus:)
-------------- 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-hackers/attachments/20081226/aaba2480/attachment.pgp
From unixmania at gmail.com  Fri Dec 26 03:59:12 2008
From: unixmania at gmail.com (Carlos A. M. dos Santos)
Date: Fri Dec 26 03:59:18 2008
Subject: How to quickly determine if UFS2 FS is "clean" from command
	line?
In-Reply-To: <20081226063946.GX4100@albert.catwhisker.org>
References: <20081226011402.GP4100@albert.catwhisker.org>
	<20081226012224.2fbd579a@gluon>
	<20081226014956.GR4100@albert.catwhisker.org>
	<20081226063542.GA20518@shark.localdomain>
	<20081226063946.GX4100@albert.catwhisker.org>
Message-ID: <e71790db0812260331x3c166de2u80db2f6aa7e2f8fa@mail.gmail.com>

On Fri, Dec 26, 2008 at 4:39 AM, David Wolfskill <david@catwhisker.org> wrote:
> On Fri, Dec 26, 2008 at 09:35:42AM +0300, Sergey Zaharchenko wrote:
>> ...
>> Some of the stuff you want can be found here:
>>
>> root@shark:~# file -s /dev/ufs/home
>> /dev/ufs/home: Unix Fast File system [v2] (little-endian) last mounted on /home, volume name home, last written at Fri Dec 26 06:33:07 2008, clean flag 0, readonly flag 0, number of blocks 13631488, number of data blocks 13202246, number of cylinder groups 145, block size 16384, fragment size 2048, average file size 16384, average number of files in dir 64, pending blocks to free 4, pending inodes to free 0, system-wide uuid 0, minimum percentage of free blocks 8, TIME optimization
>>
>> You probably want the clean flag (which is 0 for me because that device
>> node is mounted).
>
> Very nice; thanks!  Seems that both ffsinfo(8) & file(1) can do the job
> quickly; dumpfs(8) can do it, but takes around 33 seconds for a 400 GB
> file system (because it also dumps the cylinder groups).

Be warned that file(1) resides at /usr/bin and depends on
/usr/share/misc/magic*, so it may not be available in early boot
stages, when /usr is not mounted yet. The following combination will
suffice, and depends only on /sbin and /stand:

     /sbin/ffsinfo -l 1 /usr/local | /rescue/sed -n 's/^clean *int8_t
*\(.*\)/\1/p'

-- 
cd /usr/ports/sysutils/life
make clean
From sean at gothic.net.au  Fri Dec 26 05:21:01 2008
From: sean at gothic.net.au (Sean)
Date: Fri Dec 26 05:21:08 2008
Subject: How to quickly determine if UFS2 FS is "clean" from
	command	line?
In-Reply-To: <e71790db0812260331x3c166de2u80db2f6aa7e2f8fa@mail.gmail.com>
References: <20081226011402.GP4100@albert.catwhisker.org>	<20081226012224.2fbd579a@gluon>	<20081226014956.GR4100@albert.catwhisker.org>	<20081226063542.GA20518@shark.localdomain>	<20081226063946.GX4100@albert.catwhisker.org>
	<e71790db0812260331x3c166de2u80db2f6aa7e2f8fa@mail.gmail.com>
Message-ID: <4954DA22.5000904@gothic.net.au>

Carlos A. M. dos Santos wrote:
> On Fri, Dec 26, 2008 at 4:39 AM, David Wolfskill <david@catwhisker.org> wrote:
>> On Fri, Dec 26, 2008 at 09:35:42AM +0300, Sergey Zaharchenko wrote:
>>> ...
>>> Some of the stuff you want can be found here:
>>>
>>> root@shark:~# file -s /dev/ufs/home
>>> /dev/ufs/home: Unix Fast File system [v2] (little-endian) last mounted on /home, volume name home, last written at Fri Dec 26 06:33:07 2008, clean flag 0, readonly flag 0, number of blocks 13631488, number of data blocks 13202246, number of cylinder groups 145, block size 16384, fragment size 2048, average file size 16384, average number of files in dir 64, pending blocks to free 4, pending inodes to free 0, system-wide uuid 0, minimum percentage of free blocks 8, TIME optimization
>>>
>>> You probably want the clean flag (which is 0 for me because that device
>>> node is mounted).
>> Very nice; thanks!  Seems that both ffsinfo(8) & file(1) can do the job
>> quickly; dumpfs(8) can do it, but takes around 33 seconds for a 400 GB
>> file system (because it also dumps the cylinder groups).
> 
> Be warned that file(1) resides at /usr/bin and depends on
> /usr/share/misc/magic*, so it may not be available in early boot
> stages, when /usr is not mounted yet. The following combination will
> suffice, and depends only on /sbin and /stand:
> 
>      /sbin/ffsinfo -l 1 /usr/local | /rescue/sed -n 's/^clean *int8_t
> *\(.*\)/\1/p'
> 

Except FreeBSD hasn't had /stand for a long while, and there's no 
/rescue/sed (at least on 6.x and 7.x). Also, /stand was only ever 
populated on install and there's no guarantees it was ever up to date.
From unixmania at gmail.com  Fri Dec 26 05:32:17 2008
From: unixmania at gmail.com (Carlos A. M. dos Santos)
Date: Fri Dec 26 05:32:23 2008
Subject: How to quickly determine if UFS2 FS is "clean" from command
	line?
In-Reply-To: <4954DA22.5000904@gothic.net.au>
References: <20081226011402.GP4100@albert.catwhisker.org>
	<20081226012224.2fbd579a@gluon>
	<20081226014956.GR4100@albert.catwhisker.org>
	<20081226063542.GA20518@shark.localdomain>
	<20081226063946.GX4100@albert.catwhisker.org>
	<e71790db0812260331x3c166de2u80db2f6aa7e2f8fa@mail.gmail.com>
	<4954DA22.5000904@gothic.net.au>
Message-ID: <e71790db0812260532h33b1cc2bn963048c79282c1ca@mail.gmail.com>

On Fri, Dec 26, 2008 at 11:20 AM, Sean <sean@gothic.net.au> wrote:
> Carlos A. M. dos Santos wrote:
>>
>> Be warned that file(1) resides at /usr/bin and depends on
>> /usr/share/misc/magic*, so it may not be available in early boot
>> stages, when /usr is not mounted yet. The following combination will
>> suffice, and depends only on /sbin and /stand:
>>
>>     /sbin/ffsinfo -l 1 /usr/local | /rescue/sed -n 's/^clean *int8_t
>> *\(.*\)/\1/p'
>>
>
> Except FreeBSD hasn't had /stand for a long while, and there's no
> /rescue/sed (at least on 6.x and 7.x). Also, /stand was only ever populated
> on install and there's no guarantees it was ever up to date.

Humm, 8.0 has /rescue/sed.

-- 
cd /usr/ports/sysutils/life
make clean
From laladelausanne at gmail.com  Fri Dec 26 11:21:00 2008
From: laladelausanne at gmail.com (=?UTF-8?Q?Nikola_Kne=C5=BEevi=C4=87?=)
Date: Fri Dec 26 11:21:07 2008
Subject: ps not showing CPU# correctly
Message-ID: <7555893E-5D2F-4C3C-A1C7-7BCC2461AE23@gmail.com>

Hi,

on my system, I noticed that ps(1) is not showing the CPU# correctly  
(it always displays 0). There was a bug in it, and it was fetching  
ki_estcpu instead of ki_lastcpu.

The attached patch fixes this issue.

Cheers,
Nikola

-------------- next part --------------
A non-text attachment was scrubbed...
Name: ps.patch
Type: application/octet-stream
Size: 571 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20081226/f1cbc0e6/ps.obj
-------------- next part --------------

From lazaax.und at gmail.com  Fri Dec 26 11:54:57 2008
From: lazaax.und at gmail.com (lazaax -)
Date: Fri Dec 26 11:55:04 2008
Subject: hack bios hp compaq v3618la
Message-ID: <4374ff010812261128i4d723deby9aa1ed49eec1926c@mail.gmail.com>

hi, people, anyone knows how to hack bios from v3618la or had a bios
hacked, i want to bypass whitelist wireless network, i put a atheros
on mi hp and cant supported, sorry  my english is poor, i dont want ro
risk my computer... please help

-- 
Leon Chavez Colima, Mexico "lazaax"
From yanefbsd at gmail.com  Fri Dec 26 13:48:19 2008
From: yanefbsd at gmail.com (Garrett Cooper)
Date: Fri Dec 26 13:48:26 2008
Subject: ps not showing CPU# correctly
In-Reply-To: <7555893E-5D2F-4C3C-A1C7-7BCC2461AE23@gmail.com>
References: <7555893E-5D2F-4C3C-A1C7-7BCC2461AE23@gmail.com>
Message-ID: <B580FCC7-DFD3-416C-97C7-D509BB291C34@gmail.com>

On Dec 26, 2008, at 11:20, Nikola Kne?evi? <laladelausanne@gmail.com>  
wrote:

> Hi,
>
> on my system, I noticed that ps(1) is not showing the CPU# correctly  
> (it always displays 0). There was a bug in it, and it was fetching  
> ki_estcpu instead of ki_lastcpu.
>
> The attached patch fixes this issue.
>
> Cheers,
> Nikola
>
> <ps.patch>

>
Could you please submit this patch in a PR so we can track the change  
better?
Thanks!
Garrett
From pluknet at gmail.com  Fri Dec 26 14:26:28 2008
From: pluknet at gmail.com (pluknet)
Date: Fri Dec 26 14:26:34 2008
Subject: How to quickly determine if UFS2 FS is "clean" from command
	line?
In-Reply-To: <e71790db0812260532h33b1cc2bn963048c79282c1ca@mail.gmail.com>
References: <20081226011402.GP4100@albert.catwhisker.org>
	<20081226012224.2fbd579a@gluon>
	<20081226014956.GR4100@albert.catwhisker.org>
	<20081226063542.GA20518@shark.localdomain>
	<20081226063946.GX4100@albert.catwhisker.org>
	<e71790db0812260331x3c166de2u80db2f6aa7e2f8fa@mail.gmail.com>
	<4954DA22.5000904@gothic.net.au>
	<e71790db0812260532h33b1cc2bn963048c79282c1ca@mail.gmail.com>
Message-ID: <a31046fc0812261404r789df982i5cc5d2ea3f5d2ed8@mail.gmail.com>

2008/12/26 Carlos A. M. dos Santos <unixmania@gmail.com>:
> On Fri, Dec 26, 2008 at 11:20 AM, Sean <sean@gothic.net.au> wrote:
>> Carlos A. M. dos Santos wrote:
>>>
>>> Be warned that file(1) resides at /usr/bin and depends on
>>> /usr/share/misc/magic*, so it may not be available in early boot
>>> stages, when /usr is not mounted yet. The following combination will
>>> suffice, and depends only on /sbin and /stand:
>>>
>>>     /sbin/ffsinfo -l 1 /usr/local | /rescue/sed -n 's/^clean *int8_t
>>> *\(.*\)/\1/p'
>>>
>>
>> Except FreeBSD hasn't had /stand for a long while, and there's no
>> /rescue/sed (at least on 6.x and 7.x). Also, /stand was only ever populated
>> on install and there's no guarantees it was ever up to date.
>
> Humm, 8.0 has /rescue/sed.
>

It's was added there over a year ago, but not in stable.

-- 
wbr,
pluknet
From laladelausanne at gmail.com  Fri Dec 26 15:32:13 2008
From: laladelausanne at gmail.com (=?UTF-8?Q?Nikola_Kne=C5=BEevi=C4=87?=)
Date: Fri Dec 26 15:32:21 2008
Subject: debugging mbuf allocation/dealocation
Message-ID: <623D1024-5DA0-4252-8DA9-FA86E0407DA8@gmail.com>

Hi,

I'm trying to make some code which uses a lot of mbufs (Click modular  
router) running under FreeBSD 7.1. The problem is that it is leaking  
mbufs, and I can't find where...

After running the Click in a configuration which generates 150k  
packets (using m_dup) and discards them (m_freem), I get this in  
netstat -m output:
150258/1302/151560 mbufs in use (current/cache/total)
256/828/1084/4672 mbuf clusters in use (current/cache/total/max)
256/768 mbuf+clusters out of packet secondary zone in use (current/ 
cache)
0/135/135/2336 4k (page size) jumbo clusters in use (current/cache/ 
total/max)
0/0/0/1168 9k jumbo clusters in use (current/cache/total/max)
0/0/0/584 16k jumbo clusters in use (current/cache/total/max)
38076K/2521K/40598K 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


So, my question is: how to debug this? How can I track the usage of  
mbufs, profile it, and such? I'm running Click as a kernel module.

Thanks,
Nikola
From mjguzik at gmail.com  Fri Dec 26 17:51:40 2008
From: mjguzik at gmail.com (Mateusz Guzik)
Date: Fri Dec 26 17:52:12 2008
Subject: ps not showing CPU# correctly
In-Reply-To: <7555893E-5D2F-4C3C-A1C7-7BCC2461AE23@gmail.com>
References: <7555893E-5D2F-4C3C-A1C7-7BCC2461AE23@gmail.com>
Message-ID: <e7799ca20812261730x27e09d46p834b19d9dee17e97@mail.gmail.com>

Hi,

On Fri, Dec 26, 2008 at 8:20 PM, Nikola Kne?evi?
<laladelausanne@gmail.com> wrote:
> on my system, I noticed that ps(1) is not showing the CPU# correctly (it
> always displays 0). There was a bug in it, and it was fetching ki_estcpu
> instead of ki_lastcpu.
>

From the man page:
     cpu        short-term CPU usage factor (for scheduling)

Apparently not last cpu's number. :) You're probably using SCHED_ULE -
this scheduler does not alter td_estcpu and that's why ps -o cpu gives
you only 0.

--
Mateusz Guzik
From laladelausanne at gmail.com  Sat Dec 27 04:04:34 2008
From: laladelausanne at gmail.com (=?ISO-8859-2?Q?Nikola_Kne=BEevi=E6?=)
Date: Sat Dec 27 04:04:40 2008
Subject: ps not showing CPU# correctly
In-Reply-To: <e7799ca20812261730x27e09d46p834b19d9dee17e97@mail.gmail.com>
References: <7555893E-5D2F-4C3C-A1C7-7BCC2461AE23@gmail.com>
	<e7799ca20812261730x27e09d46p834b19d9dee17e97@mail.gmail.com>
Message-ID: <13986D39-BE78-4CB4-A1E5-83F0382915AC@gmail.com>

On 27 Dec 2008, at 02:30 , Mateusz Guzik wrote:

>> on my system, I noticed that ps(1) is not showing the CPU#  
>> correctly (it
>> always displays 0). There was a bug in it, and it was fetching  
>> ki_estcpu
>> instead of ki_lastcpu.
>>
>
> From the man page:
>     cpu        short-term CPU usage factor (for scheduling)
>
> Apparently not last cpu's number. :) You're probably using SCHED_ULE -
> this scheduler does not alter td_estcpu and that's why ps -o cpu gives
> you only 0.

Ups :)
I got mislead with top showing the cpu on which process executes.

I find the information on which cpu is process/thread executed quite  
useful for performance debugging. Maybe I should add it to ps as cpu#  
or cpuno or cpuid?

Cheers,
Nikola
From rwatson at FreeBSD.org  Sat Dec 27 09:22:43 2008
From: rwatson at FreeBSD.org (Robert Watson)
Date: Sat Dec 27 09:22:49 2008
Subject: debugging mbuf allocation/dealocation
In-Reply-To: <623D1024-5DA0-4252-8DA9-FA86E0407DA8@gmail.com>
References: <623D1024-5DA0-4252-8DA9-FA86E0407DA8@gmail.com>
Message-ID: <alpine.BSF.1.10.0812271720510.47096@fledge.watson.org>

On Sat, 27 Dec 2008, Nikola Kne?evi? wrote:

> After running the Click in a configuration which generates 150k packets 
> (using m_dup) and discards them (m_freem), I get this in netstat -m output:
> 150258/1302/151560 mbufs in use (current/cache/total)
> 256/828/1084/4672 mbuf clusters in use (current/cache/total/max)
> 256/768 mbuf+clusters out of packet secondary zone in use (current/cache)
> 0/135/135/2336 4k (page size) jumbo clusters in use (current/cache/total/max)
> 0/0/0/1168 9k jumbo clusters in use (current/cache/total/max)
> 0/0/0/584 16k jumbo clusters in use (current/cache/total/max)
> 38076K/2521K/40598K 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
>
> So, my question is: how to debug this? How can I track the usage of mbufs, 
> profile it, and such? I'm running Click as a kernel module.

Hi Nikola:

You can use the KTR(4) facility to trace memory allocations and deallocations, 
logging them to memory, disk, etc.  Unfortunately interpreting the data can be 
fairly tricky, as network leaks tend to happen over a long period of time, be 
stored in sockets, etc, but it's definitely possible and has been done. :-) 
Processing the results with a perl script goes a long way, as the 
allocated/freed pointers are included, etc.

Robert N M Watson
Computer Laboratory
University of Cambridge
From peterjeremy at optushome.com.au  Sat Dec 27 15:48:01 2008
From: peterjeremy at optushome.com.au (Peter Jeremy)
Date: Sat Dec 27 15:48:07 2008
Subject: How to access kernel memory from user space
In-Reply-To: <20081224212207.4cc4874b@mail01.compvia.com>
References: <20081224212207.4cc4874b@mail01.compvia.com>
Message-ID: <20081227234726.GC64280@server.vk2pj.dyndns.org>

On 2008-Dec-24 15:22:07 -0600, Gerry Weaver <gerryw@compvia.com> wrote:
>to keep it minimal. Is there any significant trade off in performance
>between the two approaches?

No.  In both cases, the actual access is managed through the normal
hardware translation the same as any other data.  About the only
difference is that the kmem approach will probably involve an
additional page of mapping because your data structure probably won't
be page-aligned by default.

> Also, Is there anything in the source or ports tree that I could
>use as an example for the device node case?

I presume you've been looking thru device drivers that initialise
d_mmap.  I've got an example but it only has 1 page of status info so
the allocation is a bit different.  I'll see what I can find.

-- 
Peter Jeremy
Please excuse any delays as the result of my ISP's inability to implement
an MTA that is either RFC2821-compliant or matches their claimed behaviour.
-------------- 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-hackers/attachments/20081227/cbe0ee91/attachment.pgp
From unixmania at gmail.com  Sat Dec 27 18:51:35 2008
From: unixmania at gmail.com (Carlos A. M. dos Santos)
Date: Sat Dec 27 18:51:41 2008
Subject: hack bios hp compaq v3618la
In-Reply-To: <4374ff010812261128i4d723deby9aa1ed49eec1926c@mail.gmail.com>
References: <4374ff010812261128i4d723deby9aa1ed49eec1926c@mail.gmail.com>
Message-ID: <e71790db0812271851oaf5cdfflc51400003aa24a1b@mail.gmail.com>

On Fri, Dec 26, 2008 at 5:28 PM, lazaax - <lazaax.und@gmail.com> wrote:
> hi, people, anyone knows how to hack bios from v3618la or had a bios
> hacked, i want to bypass whitelist wireless network, i put a atheros
> on mi hp and cant supported, sorry  my english is poor, i dont want ro
> risk my computer... please help

I attempted to replace the wireless card of a similar HP notebook and
gave up. I suggest you to use a USB "dongle", instead. This is a cheap
and much safer approach. Hacking the BIOS may lead to a broken
notebook that can be hard to recover.

Also, this kind of question should be sent to freebsd-questions, not
to -hackers.

-- 
cd /usr/ports/sysutils/life
make clean
From sam at freebsd.org  Sat Dec 27 19:18:24 2008
From: sam at freebsd.org (Sam Leffler)
Date: Sat Dec 27 19:18:30 2008
Subject: hack bios hp compaq v3618la
In-Reply-To: <e71790db0812271851oaf5cdfflc51400003aa24a1b@mail.gmail.com>
References: <4374ff010812261128i4d723deby9aa1ed49eec1926c@mail.gmail.com>
	<e71790db0812271851oaf5cdfflc51400003aa24a1b@mail.gmail.com>
Message-ID: <4956EFFE.7070603@freebsd.org>

Carlos A. M. dos Santos wrote:
> On Fri, Dec 26, 2008 at 5:28 PM, lazaax - <lazaax.und@gmail.com> wrote:
>   
>> hi, people, anyone knows how to hack bios from v3618la or had a bios
>> hacked, i want to bypass whitelist wireless network, i put a atheros
>> on mi hp and cant supported, sorry  my english is poor, i dont want ro
>> risk my computer... please help
>>     
>
> I attempted to replace the wireless card of a similar HP notebook and
> gave up. I suggest you to use a USB "dongle", instead. This is a cheap
> and much safer approach. Hacking the BIOS may lead to a broken
> notebook that can be hard to recover.
>
> Also, this kind of question should be sent to freebsd-questions, not
> to -hackers.
>
>   
The usual way to deal w/ this is to overwrite the pci dev id in the 
card's eeprom so it matches the bios whitelist.  Then map that device id 
to something ath will attach to.  I'm not allowed to give out the recipe 
for writing the eeprom but it's well-known and easily found with google.

    Sam

From Andre.Albsmeier at siemens.com  Sun Dec 28 02:54:04 2008
From: Andre.Albsmeier at siemens.com (Andre Albsmeier)
Date: Sun Dec 28 02:54:12 2008
Subject: Writing device drivers: How to access a specific memory area?
In-Reply-To: <490EB16A-F626-4A40-9716-A02A32F04ED4@freebsd.org>
References: <20081225095333.GA12699@curry.mchp.siemens.de>
	<490EB16A-F626-4A40-9716-A02A32F04ED4@freebsd.org>
Message-ID: <20081228105401.GA28657@curry.mchp.siemens.de>

On Thu, 25-Dec-2008 at 13:57:00 +0000, Rui Paulo wrote:
> 
> On 25 Dec 2008, at 09:53, Andre Albsmeier wrote:
> 
> > Hello all,
> >
> > I am writing a driver which needs to access memory at a
> > specific location. The location depends on what the BIOS
> > has configured into the host bridge. For example, my
> > current machine uses an Intel 975X chipset and the memory
> > location I am interested in has been set to 0xFED14000 and
> > is 16KB in size (this is MCHBAR of the 975X memory hub).
> 
> You probably just need to do something like:
> 
> rid = PCI_BAR(number);
> res = bus_alloc_resource_any(dev, SYS_RES_MEMORY, &rid, RF_ACTIVE);

The problem was, that this memory belongs to acpi0
so I couldn't read it from my driver which has no
resources assigned to it. But, I found a way, see below...

> 
> And then,
> bus_read_4(res, offset from specified PCI BAR);
> 
> >
> >
> > I have no idea how to access this space from my driver.
> > I have played around with bus_alloc_resource() but this
> > only gives me back NULL.
> >
> > However, a devinfo -r gives me:
> >
> > nexus0
> >  npx0
> >  acpi0
> >      Interrupt request lines:
> >          9
> >      I/O ports:
> >          0x10-0x1f
> > ...
> >          0x800-0x87f
> >      I/O memory addresses:
> >          0x0-0x9ffff
> >          0xc0000-0xdffff
> >          0xe0000-0xfffff
> >          0x100000-0x7fffffff
> >          0xf0000000-0xf3ffffff
> >          0xfec00000-0xfec00fff
> >          0xfed13000-0xfed19fff		<---
> >          0xfed1c000-0xfed1ffff
> >          0xfed20000-0xfed3ffff
> >          0xfed50000-0xfed8ffff
> >          0xfee00000-0xfee00fff
> >          0xffb00000-0xffbfffff
> >          0xfff00000-0xffffffff
> >    cpu0
> > ...
> >
> > The line marked with <--- shows the range which includes
> > the location I am interested in. It is probably assigned
> > to the acpi0 device.
> >
> > How do I proceed from this? Do I have to hack around in
> > the ACPI-Code? I don't hope so ;-)
> 
> You'll probably need to create a fake ACPI child driver to access it.
> 
> 
> Create your identify routine with something like:
> 
> static void mydriver_identify(driver_t *driver, device_t parent)
> {
> 	if (device_find_child(parent, "mydriver", -1) == NULL &&
> 	    mydriver_match(parent))
> 		device_add_child(parent, "mydriver", -1);
> }
> 
> mydriver_match() should check if you were given the acpi0 device.

Found something easier: I just do a bus_set_resource() followed
by bus_alloc_resource_any(), access my host bridge registers,
and free things with bus_release_resource() followed by
bus_delete_resource().

> 
> 
> >
> >
> > I only need access to this memory location during the
> > probe of my driver to read some configuration data.
> 
> Is this pci configuration space ? If so, pci_read_config (man 9 pci)  

Unfortunately not. As I wrote, it is a 16k memory window
where the 975x maps a part of its config registers. The
address of this window can be read by pci_read_config( dev, 0x44, 4 ).
Then you can access the bridge's cXdrcY registers through
this memory window which I needed to determine the
machines RAM layout.

Thanks anyway for your help,

	-Andre
From yuri at rawbw.com  Sun Dec 28 21:28:28 2008
From: yuri at rawbw.com (Yuri)
Date: Sun Dec 28 21:28:35 2008
Subject: How process size is calculated? Is it always based on the current
 highest available address in memory space?
Message-ID: <49585C75.80203@rawbw.com>

malloc(3) can be controlled by MALLOC_OPTIONS to use mmap-based 
allocation as opposed to sbrk-based allocation.
But allocations/deallocations with mmaps can eventually lead to 
non-continuously mmapped memory (having some non-mmapped gaps).

Are  these gaps excluded from the process size or size is always linked 
to the current highest available address in memory space?

Yuri
From laladelausanne at gmail.com  Mon Dec 29 02:13:59 2008
From: laladelausanne at gmail.com (=?ISO-8859-2?Q?Nikola_Kne=BEevi=E6?=)
Date: Mon Dec 29 02:14:04 2008
Subject: debugging mbuf allocation/dealocation
In-Reply-To: <alpine.BSF.1.10.0812271720510.47096@fledge.watson.org>
References: <623D1024-5DA0-4252-8DA9-FA86E0407DA8@gmail.com>
	<alpine.BSF.1.10.0812271720510.47096@fledge.watson.org>
Message-ID: <DFC7E12E-3FE7-47F0-A7C7-6FBF042581D1@gmail.com>

>
> You can use the KTR(4) facility to trace memory allocations and  
> deallocations, logging them to memory, disk, etc.  Unfortunately  
> interpreting the data can be fairly tricky, as network leaks tend to  
> happen over a long period of time, be stored in sockets, etc, but  
> it's definitely possible and has been done. :-) Processing the  
> results with a perl script goes a long way, as the allocated/freed  
> pointers are included, etc.

Hi Robert,

thanks for the pointers :)
I discovered that root cause of the leakage - Click::Packet had a bad  
destructor, which wasn't free-ing mbufs all the time. Since there are  
some other forms of leaking in Click, I'll use KTR do discover them.

Cheers,
Nikola
From dnelson at allantgroup.com  Mon Dec 29 16:16:03 2008
From: dnelson at allantgroup.com (Dan Nelson)
Date: Mon Dec 29 16:16:44 2008
Subject: How process size is calculated? Is it always based on the
	current highest available address in memory space?
In-Reply-To: <49585C75.80203@rawbw.com>
References: <49585C75.80203@rawbw.com>
Message-ID: <20081229154544.GB21654@dan.emsphone.com>

In the last episode (Dec 28), Yuri said:
> malloc(3) can be controlled by MALLOC_OPTIONS to use mmap-based
> allocation as opposed to sbrk-based allocation. But
> allocations/deallocations with mmaps can eventually lead to
> non-continuously mmapped memory (having some non-mmapped gaps).
> 
> Are these gaps excluded from the process size or size is always
> linked to the current highest available address in memory space?

It looks like only mapped memory is counted in process size.  The test
program below shows that the reported size goes down, even if a memory
range inbetween two others is unmapped:

$ ./mmap
Before mmap:
  UID   PID  PPID CPU PRI NI   VSZ   RSS MWCHAN STAT  TT       TIME COMMAND
 1000 48058 62165   0   8  0  1928   824 wait   S+    ph    0:00.01 ./mmap
mmap 64MB A=0x28280000
  UID   PID  PPID CPU PRI NI   VSZ   RSS MWCHAN STAT  TT       TIME COMMAND
 1000 48058 62165   0   8  0 67464   824 wait   S+    ph    0:00.01 ./mmap
mmap 64MB B=0x2c280000
  UID   PID  PPID CPU PRI NI   VSZ   RSS MWCHAN STAT  TT       TIME COMMAND
 1000 48058 62165   0   8  0 133000   824 wait   S+    ph    0:00.01 ./mmap
mmap 64MB C=0x30280000
  UID   PID  PPID CPU PRI NI   VSZ   RSS MWCHAN STAT  TT       TIME COMMAND
 1000 48058 62165   0   8  0 198536   824 wait   S+    ph    0:00.01 ./mmap
munmap B
  UID   PID  PPID CPU PRI NI   VSZ   RSS MWCHAN STAT  TT       TIME COMMAND
 1000 48058 62165   0   8  0 133000   824 wait   S+    ph    0:00.01 ./mmap


#include <stdio.h>
#include <stdlib.h>
#include <sys/mman.h>
#include <unistd.h>

int main(void)
{
  char *cmd;
  void *a, *b, *c;
  asprintf(&cmd, "ps axlp %d", getpid());
  printf("Before mmap:\n");
  system(cmd);
  a = mmap(NULL, 64 * 1024 * 1024, PROT_READ|PROT_WRITE, MAP_ANON, -1, 0);
  printf("mmap 64MB A=%p\n", a);
  system(cmd);
  b = mmap(NULL, 64 * 1024 * 1024, PROT_READ|PROT_WRITE, MAP_ANON, -1, 0);
  printf("mmap 64MB B=%p\n", b);
  system(cmd);
  c = mmap(NULL, 64 * 1024 * 1024, PROT_READ|PROT_WRITE, MAP_ANON, -1, 0);
  printf("mmap 64MB C=%p\n", c);
  system(cmd);
  printf("munmap B\n");
  munmap(b, 64 * 1024 * 1024);
  system(cmd);
  return 0;
}


-- 
	Dan Nelson
	dnelson@allantgroup.com
From rwatson at FreeBSD.org  Mon Dec 29 19:47:54 2008
From: rwatson at FreeBSD.org (Robert Watson)
Date: Mon Dec 29 19:48:02 2008
Subject: How process size is calculated? Is it always based on
 the	current highest available address in memory space?
In-Reply-To: <20081229154544.GB21654@dan.emsphone.com>
References: <49585C75.80203@rawbw.com>
	<20081229154544.GB21654@dan.emsphone.com>
Message-ID: <alpine.BSF.1.10.0812291947100.9438@fledge.watson.org>

On Mon, 29 Dec 2008, Dan Nelson wrote:

> In the last episode (Dec 28), Yuri said:
>> malloc(3) can be controlled by MALLOC_OPTIONS to use mmap-based allocation 
>> as opposed to sbrk-based allocation. But allocations/deallocations with 
>> mmaps can eventually lead to non-continuously mmapped memory (having some 
>> non-mmapped gaps).
>>
>> Are these gaps excluded from the process size or size is always linked to 
>> the current highest available address in memory space?
>
> It looks like only mapped memory is counted in process size.  The test 
> program below shows that the reported size goes down, even if a memory range 
> inbetween two others is unmapped:

You can use procstat(8), or on older versions of FreeBSD procfs, to explore 
the layout of process memory, which may also lend some insight to what's going 
on.

Robert N M Watson
Computer Laboratory
University of Cambridge

>
> $ ./mmap
> Before mmap:
>  UID   PID  PPID CPU PRI NI   VSZ   RSS MWCHAN STAT  TT       TIME COMMAND
> 1000 48058 62165   0   8  0  1928   824 wait   S+    ph    0:00.01 ./mmap
> mmap 64MB A=0x28280000
>  UID   PID  PPID CPU PRI NI   VSZ   RSS MWCHAN STAT  TT       TIME COMMAND
> 1000 48058 62165   0   8  0 67464   824 wait   S+    ph    0:00.01 ./mmap
> mmap 64MB B=0x2c280000
>  UID   PID  PPID CPU PRI NI   VSZ   RSS MWCHAN STAT  TT       TIME COMMAND
> 1000 48058 62165   0   8  0 133000   824 wait   S+    ph    0:00.01 ./mmap
> mmap 64MB C=0x30280000
>  UID   PID  PPID CPU PRI NI   VSZ   RSS MWCHAN STAT  TT       TIME COMMAND
> 1000 48058 62165   0   8  0 198536   824 wait   S+    ph    0:00.01 ./mmap
> munmap B
>  UID   PID  PPID CPU PRI NI   VSZ   RSS MWCHAN STAT  TT       TIME COMMAND
> 1000 48058 62165   0   8  0 133000   824 wait   S+    ph    0:00.01 ./mmap
>
>
> #include <stdio.h>
> #include <stdlib.h>
> #include <sys/mman.h>
> #include <unistd.h>
>
> int main(void)
> {
>  char *cmd;
>  void *a, *b, *c;
>  asprintf(&cmd, "ps axlp %d", getpid());
>  printf("Before mmap:\n");
>  system(cmd);
>  a = mmap(NULL, 64 * 1024 * 1024, PROT_READ|PROT_WRITE, MAP_ANON, -1, 0);
>  printf("mmap 64MB A=%p\n", a);
>  system(cmd);
>  b = mmap(NULL, 64 * 1024 * 1024, PROT_READ|PROT_WRITE, MAP_ANON, -1, 0);
>  printf("mmap 64MB B=%p\n", b);
>  system(cmd);
>  c = mmap(NULL, 64 * 1024 * 1024, PROT_READ|PROT_WRITE, MAP_ANON, -1, 0);
>  printf("mmap 64MB C=%p\n", c);
>  system(cmd);
>  printf("munmap B\n");
>  munmap(b, 64 * 1024 * 1024);
>  system(cmd);
>  return 0;
> }
>
>
> --
> 	Dan Nelson
> 	dnelson@allantgroup.com
> _______________________________________________
> freebsd-hackers@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
>
From naddy at mips.inka.de  Mon Dec 29 21:58:30 2008
From: naddy at mips.inka.de (Christian Weisgerber)
Date: Mon Dec 29 21:58:37 2008
Subject: lzo2 shows insane speed gap
Message-ID: <gjbf7c$hbm$1@lorvorc.mips.inka.de>

The archivers/lzo2 port runs a series of regression tests after the
actual build.  These tests show extremely divergent behavior on
different machines.  There are two types of machines:

Type #1:
  Running the tests takes roughly the same time as configure and
  compile did, whether it's 30 seconds on a fast machine or 10
  minutes on an old slow one.

Type #2:
  Running the tests takes much, much, MUCH longer.

I've tried this across alpha, amd64, i386, and sparc64, partially
on FreeBSD, partially on OpenBSD.  The operating system doesn't
matter and there is no pattern related to endianness or 32/64 bits.

You can find machines that are the same architecture (e.g. amd64)
and are of similar overall speed (e.g. an Intel Xeon Xeon E5405 and
an AMD Phenom 9350e) and one of these machines will be type #1 and
the other will be #2 and take _a hundred_ times longer to run the
tests.  A hundred times.

I have never seen anything like this before.

On the "slow" machines, the tests also consume a lot of system time.
I've seen figures from 20 to 50%.  However, ktrace shows nothing
out of the ordinary.

My best guess at this time is that lzo2 somehow manages to induce
crazy cache thrashing on some CPU models.

Ideas and explanations welcome.

-- 
Christian "naddy" Weisgerber                          naddy@mips.inka.de

From dimitry at andric.com  Mon Dec 29 23:17:50 2008
From: dimitry at andric.com (Dimitry Andric)
Date: Mon Dec 29 23:17:57 2008
Subject: lzo2 shows insane speed gap
In-Reply-To: <gjbf7c$hbm$1@lorvorc.mips.inka.de>
References: <gjbf7c$hbm$1@lorvorc.mips.inka.de>
Message-ID: <49595A9C.6050809@andric.com>

On 2008-12-29 22:25, Christian Weisgerber wrote:
> On the "slow" machines, the tests also consume a lot of system time.
> I've seen figures from 20 to 50%.  However, ktrace shows nothing
> out of the ordinary.

What's up with the memory on these machines?  Lzo tends to take insane amounts....
From dimitry at andric.com  Mon Dec 29 23:19:13 2008
From: dimitry at andric.com (Dimitry Andric)
Date: Mon Dec 29 23:19:20 2008
Subject: lzo2 shows insane speed gap
In-Reply-To: <49595A9C.6050809@andric.com>
References: <gjbf7c$hbm$1@lorvorc.mips.inka.de> <49595A9C.6050809@andric.com>
Message-ID: <49595AF2.30101@andric.com>

On 2008-12-30 00:17, Dimitry Andric wrote:
> What's up with the memory on these machines?  Lzo tends to take insane amounts....

Duh, nevermind... I'm confusing this with lzma. :)  Sorry for the noise.
From neldredge at math.ucsd.edu  Mon Dec 29 23:25:08 2008
From: neldredge at math.ucsd.edu (Nate Eldredge)
Date: Mon Dec 29 23:25:14 2008
Subject: lzo2 shows insane speed gap
In-Reply-To: <gjbf7c$hbm$1@lorvorc.mips.inka.de>
References: <gjbf7c$hbm$1@lorvorc.mips.inka.de>
Message-ID: <Pine.GSO.4.64.0812291512490.22968@zeno.ucsd.edu>

On Mon, 29 Dec 2008, Christian Weisgerber wrote:

> The archivers/lzo2 port runs a series of regression tests after the
> actual build.  These tests show extremely divergent behavior on
> different machines.  There are two types of machines:
>
> Type #1:
>  Running the tests takes roughly the same time as configure and
>  compile did, whether it's 30 seconds on a fast machine or 10
>  minutes on an old slow one.
>
> Type #2:
>  Running the tests takes much, much, MUCH longer.
>
> I've tried this across alpha, amd64, i386, and sparc64, partially
> on FreeBSD, partially on OpenBSD.  The operating system doesn't
> matter and there is no pattern related to endianness or 32/64 bits.
>
> You can find machines that are the same architecture (e.g. amd64)
> and are of similar overall speed (e.g. an Intel Xeon Xeon E5405 and
> an AMD Phenom 9350e) and one of these machines will be type #1 and
> the other will be #2 and take _a hundred_ times longer to run the
> tests.  A hundred times.
>
> I have never seen anything like this before.

It might be good first to rule out compiler / library differences.

First, can you isolate a single lzo command / input combination whose time 
differs dramatically?  This would simplify tests compared to running the 
whole test suite.  (It should be easy because it looks like the test suite 
prints the time for each test.)  It might also simplify things to work on 
one "fast" and one "slow" machine.

Then try copying the lzo binary from the "fast" machine to the "slow" 
machine (and vice versa) and see if the same test speeds up with the 
copied binary.  If not, try again with the binary statically linked.  If 
still not, it would be good to have a copy of the binary made available, 
along with more information about the "fast" and "slow" machines (CPU, 
amount of memory, load on the machine, kernel version, disk, etc).

If the copied binary isn't faster than the natively produced one, then it 
would be good to have information about the compiler options, versions, 
etc.

-- 

Nate Eldredge
neldredge@math.ucsd.edu
From yuri at rawbw.com  Mon Dec 29 23:57:26 2008
From: yuri at rawbw.com (Yuri)
Date: Mon Dec 29 23:57:32 2008
Subject: lzo2 shows insane speed gap
In-Reply-To: <gjbf7c$hbm$1@lorvorc.mips.inka.de>
References: <gjbf7c$hbm$1@lorvorc.mips.inka.de>
Message-ID: <495963E3.8010509@rawbw.com>

Christian Weisgerber wrote:
> <skipped>
>
> My best guess at this time is that lzo2 somehow manages to induce
> crazy cache thrashing on some CPU models.
>
> Ideas and explanations welcome.
>   

Did you ask the author? He might be the best person to ask.

Yuri

From fbsd.hackers at rachie.is-a-geek.net  Tue Dec 30 00:04:30 2008
From: fbsd.hackers at rachie.is-a-geek.net (Mel)
Date: Tue Dec 30 00:04:36 2008
Subject: lzo2 shows insane speed gap
In-Reply-To: <gjbf7c$hbm$1@lorvorc.mips.inka.de>
References: <gjbf7c$hbm$1@lorvorc.mips.inka.de>
Message-ID: <200812291504.28106.fbsd.hackers@rachie.is-a-geek.net>

On Monday 29 December 2008 12:25:00 Christian Weisgerber wrote:
> On the "slow" machines, the tests also consume a lot of system time.
> I've seen figures from 20 to 50%. ?However, ktrace shows nothing
> out of the ordinary.

If the program itself doesn't directly cause the system time, do interrupt 
rates give any hint as to what does?
And to rule out the obvious, you did check swapping?
-- 
Mel
From yuri at rawbw.com  Tue Dec 30 00:16:45 2008
From: yuri at rawbw.com (Yuri)
Date: Tue Dec 30 00:16:51 2008
Subject: lzo2 shows insane speed gap
In-Reply-To: <gjbf7c$hbm$1@lorvorc.mips.inka.de>
References: <gjbf7c$hbm$1@lorvorc.mips.inka.de>
Message-ID: <4959686C.7010009@rawbw.com>

Christian Weisgerber wrote:
> My best guess at this time is that lzo2 somehow manages to induce
> crazy cache thrashing on some CPU models.
>
> Ideas and explanations welcome


Try running single command that is different on different machines under
valgrind (callgrind) on these machines and see that at least number of 
instructions
executed is the same.

Lzo2 documentation says that there are a lot of algorithms implemented.
It might be choosing the algorithm based on the CPU and the choice it's 
making might be bad.

Yuri
From fbsdlist at src.cx  Tue Dec 30 00:34:06 2008
From: fbsdlist at src.cx (Artem Belevich)
Date: Tue Dec 30 00:34:13 2008
Subject: lzo2 shows insane speed gap
In-Reply-To: <Pine.GSO.4.64.0812291512490.22968@zeno.ucsd.edu>
References: <gjbf7c$hbm$1@lorvorc.mips.inka.de>
	<Pine.GSO.4.64.0812291512490.22968@zeno.ucsd.edu>
Message-ID: <ed91d4a80812291611y472d3d4an24edda5bd60d74a1@mail.gmail.com>

I see this performance difference on my boxes.

First one has Core2Duo(E5-something), 4GB and  runs RELENG_7/i386.
lzotest is very fast.
Second box is Core2Quad (Q9450), 8GB RAM and runs -current as of about
a week ago. lzo2 binary built from ports is *slow*. However, 32-bit
binary from the first box runs very fast.

The only interesting difference I can see in ktrace is that read and
munmap take much much longer in case of 64-bit lzotest.

Here are two excerpts from ktrace on the second box:
### 32-bit app - runs fast on both boxes.

 59657 lzotest  0.000010 CALL  open(0xffffd91b,O_RDONLY,<unused>0x1b6)
 59657 lzotest  0.000007 NAMI  "./src/lzo1_d.ch"
 59657 lzotest  0.000012 RET   open 3
 59657 lzotest  0.000005 CALL  fstat(0x3,0xffffd504)
 59657 lzotest  0.000007 STRU  struct stat {dev=102, ino=544718,
mode=-rw-r--r-- , nlink=1, uid=0, gid=0, rdev=2169160,
atime=1230595144, stime=1209559909, ctime=1230588212,
birthtime=1209559909, size=4563, blksize=4096, blocks=12, flags=0x0 }
 59657 lzotest  0.000005 RET   fstat 0
 59657 lzotest  0.000006 CALL  lseek(0x3,0,SEEK_SET,0x1)
 59657 lzotest  0.000005 RET   lseek 0
 59657 lzotest  0.000005 CALL  lseek(0x3,0x4000000,SEEK_SET,0)
 59657 lzotest  0.000005 RET   lseek 67108864/0x4000000
 59657 lzotest  0.000006 CALL  lseek(0x3,0,SEEK_SET,0)
 59657 lzotest  0.000005 RET   lseek 0
 59657 lzotest  0.000005 CALL
mmap(0,0x4000000,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,0xffffffff,0,0)
 59657 lzotest  0.000007 RET   mmap 673185792/0x28200000
 59657 lzotest  0.000006 CALL  read(0x3,0x28196000,0x1000)
 59657 lzotest  0.000010 GIO   fd 3 read 4096 bytes
 59657 lzotest  0.000029 RET   read 4096/0x1000
 59657 lzotest  0.000028 CALL  read(0x3,0x28196000,0x1000)
 59657 lzotest  0.000010 GIO   fd 3 read 467 bytes
 59657 lzotest  0.000005 RET   read 467/0x1d3
 59657 lzotest  0.000010 CALL  read(0x3,0x28196000,0x1000)
 59657 lzotest  0.000007 GIO   fd 3 read 0 bytes
 59657 lzotest  0.000006 RET   read 0
 59657 lzotest  0.000005 CALL  close(0x3)
 59657 lzotest  0.000010 RET   close 0
 59657 lzotest  0.000025 CALL  getrusage(0,0xffffd60c)
 59657 lzotest  0.000006 RET   getrusage 0
 59657 lzotest  0.000005 CALL  getrusage(0,0xffffd628)
 59657 lzotest  0.000006 RET   getrusage 0
 59657 lzotest  0.000005 CALL  getrusage(0,0xffffd60c)
 59657 lzotest  0.000006 RET   getrusage 0
 59657 lzotest  0.000064 CALL  getrusage(0,0xffffd60c)
 59657 lzotest  0.000006 RET   getrusage 0
 59657 lzotest  0.000005 CALL  getrusage(0,0xffffd60c)
 59657 lzotest  0.000006 RET   getrusage 0
 59657 lzotest  0.000029 CALL  getrusage(0,0xffffd60c)
 59657 lzotest  0.000006 RET   getrusage 0
 59657 lzotest  0.000012 CALL  getrusage(0,0xffffd60c)
 59657 lzotest  0.000036 RET   getrusage 0
 59657 lzotest  0.000010 CALL  write(0x1,0x28194000,0x4f)
 59657 lzotest  0.000010 GIO   fd 1 wrote 79 bytes
 59657 lzotest  0.000006 RET   write 79/0x4f
 59657 lzotest  0.000006 CALL  munmap(0x28200000,0x4000000)
 59657 lzotest  0.000017 RET   munmap 0

### same file. 64-bit app (slow). Look at read/munmap

 59158 lzotest  0.000015 CALL  open(0x7fffffffe760,O_RDONLY,<unused>0x1b6)
 59158 lzotest  0.000014 NAMI  "./src/lzo1_d.ch"
 59158 lzotest  0.000024 RET   open 3
 59158 lzotest  0.000011 CALL  fstat(0x3,0x7fffffffe2d0)
 59158 lzotest  0.000011 STRU  struct stat {dev=102, ino=544718,
mode=-rw-r--r-- , nlink=1, uid=0, gid=0, rdev=2169160,
atime=1230588427, stime=1209559909, ctime=1230588212,
birthtime=1209559909, size=4563, blksize=4096, blocks=12, flags=0x0 }
 59158 lzotest  0.000007 RET   fstat 0
 59158 lzotest  0.000015 CALL  lseek(0x3,0,SEEK_CUR)
 59158 lzotest  0.000007 RET   lseek 0
 59158 lzotest  0.000006 CALL  lseek(0x3,0x4000000,SEEK_SET)
 59158 lzotest  0.000007 RET   lseek 67108864/0x4000000
 59158 lzotest  0.000007 CALL  lseek(0x3,0,SEEK_SET)
 59158 lzotest  0.000006 RET   lseek 0
 59158 lzotest  0.000008 CALL
mmap(0,0x4000000,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,0xffffffff,0)
 59158 lzotest  0.000010 RET   mmap 11534336/0x800b00000
 59158 lzotest  0.074126 CALL  read(0x3,0x800a9e000,0x1000)
 59158 lzotest  0.000054 GIO   fd 3 read 4096 bytes
 59158 lzotest  0.000010 RET   read 4096/0x1000
 59158 lzotest  0.000007 CALL  read(0x3,0x800a9e000,0x1000)
 59158 lzotest  0.000012 GIO   fd 3 read 467 bytes
 59158 lzotest  0.000006 RET   read 467/0x1d3
 59158 lzotest  0.000007 CALL  read(0x3,0x800a9e000,0x1000)
 59158 lzotest  0.000009 GIO   fd 3 read 0 bytes
 59158 lzotest  0.000006 RET   read 0
 59158 lzotest  0.000008 CALL  close(0x3)
 59158 lzotest  0.000020 RET   close 0
 59158 lzotest  0.000029 CALL  getrusage(0,0x7fffffffe3d0)
 59158 lzotest  0.000010 RET   getrusage 0
 59158 lzotest  0.000007 CALL  getrusage(0,0x7fffffffe3e0)
 59158 lzotest  0.000007 RET   getrusage 0
 59158 lzotest  0.000007 CALL  getrusage(0,0x7fffffffe3d0)
 59158 lzotest  0.000007 RET   getrusage 0
 59158 lzotest  0.000069 CALL  getrusage(0,0x7fffffffe3d0)
 59158 lzotest  0.000007 RET   getrusage 0
 59158 lzotest  0.000006 CALL  getrusage(0,0x7fffffffe3d0)
 59158 lzotest  0.000007 RET   getrusage 0
 59158 lzotest  0.000030 CALL  getrusage(0,0x7fffffffe3d0)
 59158 lzotest  0.000006 RET   getrusage 0
 59158 lzotest  0.000014 CALL  getrusage(0,0x7fffffffe3d0)
 59158 lzotest  0.000006 RET   getrusage 0
 59158 lzotest  0.000024 CALL  write(0x1,0x800a9c000,0x4f)
 59158 lzotest  0.000030 GIO   fd 1 wrote 79 bytes
 59158 lzotest  0.000008 RET   write 79/0x4f
 59158 lzotest  0.015677 CALL  munmap(0x800b00000,0x4000000)
 59158 lzotest  0.005430 RET   munmap 0

--Artem
From naddy at mips.inka.de  Tue Dec 30 01:09:07 2008
From: naddy at mips.inka.de (Christian Weisgerber)
Date: Tue Dec 30 01:09:14 2008
Subject: lzo2 shows insane speed gap
References: <gjbf7c$hbm$1@lorvorc.mips.inka.de>
	<200812291504.28106.fbsd.hackers@rachie.is-a-geek.net>
Message-ID: <gjbsbg$5gj$1@lorvorc.mips.inka.de>

Mel <fbsd.hackers@rachie.is-a-geek.net> wrote:

> If the program itself doesn't directly cause the system time, do interrupt 
> rates give any hint as to what does?

systat -vmstat shows a conspicuously large number of traps, I think.
(I'm short on comparable FreeBSD machines.)

> And to rule out the obvious, you did check swapping?

No swapping.

-- 
Christian "naddy" Weisgerber                          naddy@mips.inka.de

From naddy at mips.inka.de  Tue Dec 30 01:20:00 2008
From: naddy at mips.inka.de (Christian Weisgerber)
Date: Tue Dec 30 01:20:11 2008
Subject: lzo2 shows insane speed gap
In-Reply-To: <Pine.GSO.4.64.0812291512490.22968@zeno.ucsd.edu>
References: <gjbf7c$hbm$1@lorvorc.mips.inka.de>
	<Pine.GSO.4.64.0812291512490.22968@zeno.ucsd.edu>
Message-ID: <20081230004747.GA55542@lorvorc.mips.inka.de>

Nate Eldredge:

> It might be good first to rule out compiler / library differences.

Sure.  Let's cut this short:

"Slow"
Athlon 64 X2 5200+ 2.6 GHz,          FreeBSD 8.0-CURRENT amd64   ~60 min
Phenom 9350e 2.0 GHz,                OpenBSD 4.4-CURRENT amd64   ~80 min
UltraSPARC-IIe 500 MHz (Blade 100),  OpenBSD 4.4-CURRENT sparc64  10 h++

"Fast"
Pentium 4 3.0 GHz,                   FreeBSD 6.4-RELEASE i386     36 s
Xeon E5405 2.0 GHz (PowerEdge 1950), OpenBSD 4.4-CURRENT amd64    47 s
Alpha 21164A 500 MHz (AlphaPC164),   OpenBSD 4.4-CURRENT alpha     9 min

Let me draw your attention to the fact that the two amd64 systems
that run different operating systems are both slow, whereas the two
amd64 systems that run the same operating system (compiler, libraries)
diverge in speed.


Oh, and everybody is invited to run

$ cd /usr/ports/archivers/lzo2 && make

and check for themselves.


PS: The Blade 100 is still crunching as I write this...
-- 
Christian "naddy" Weisgerber                          naddy@mips.inka.de
From bruce at cran.org.uk  Tue Dec 30 02:05:31 2008
From: bruce at cran.org.uk (Bruce Cran)
Date: Tue Dec 30 02:05:38 2008
Subject: lzo2 shows insane speed gap
In-Reply-To: <20081230004747.GA55542@lorvorc.mips.inka.de>
References: <gjbf7c$hbm$1@lorvorc.mips.inka.de>
	<Pine.GSO.4.64.0812291512490.22968@zeno.ucsd.edu>
	<20081230004747.GA55542@lorvorc.mips.inka.de>
Message-ID: <20081230020524.2563a6ac@gluon>

On Tue, 30 Dec 2008 01:47:47 +0100
Christian Weisgerber <naddy@mips.inka.de> wrote:

> Nate Eldredge:
> 
> > It might be good first to rule out compiler / library differences.
> 
> Sure.  Let's cut this short:
> 
> "Slow"
> Athlon 64 X2 5200+ 2.6 GHz,          FreeBSD 8.0-CURRENT amd64   ~60
> min Phenom 9350e 2.0 GHz,                OpenBSD 4.4-CURRENT amd64
> ~80 min UltraSPARC-IIe 500 MHz (Blade 100),  OpenBSD 4.4-CURRENT
> sparc64  10 h++
> 
> "Fast"
> Pentium 4 3.0 GHz,                   FreeBSD 6.4-RELEASE i386     36 s
> Xeon E5405 2.0 GHz (PowerEdge 1950), OpenBSD 4.4-CURRENT amd64    47 s
> Alpha 21164A 500 MHz (AlphaPC164),   OpenBSD 4.4-CURRENT alpha     9
> min
> 
> Let me draw your attention to the fact that the two amd64 systems
> that run different operating systems are both slow, whereas the two
> amd64 systems that run the same operating system (compiler, libraries)
> diverge in speed.
> 
> 
> Oh, and everybody is invited to run
> 
> $ cd /usr/ports/archivers/lzo2 && make

I'm running 8.0-CURRENT amd64 here on a Turion64 X2 machine. Without
malloc debugging (malloc.conf -> aj) 'make test' takes 25s; after
removing malloc.conf thus turning on debugging, it takes over 10
minutes.

-- 
Bruce Cran
From toasty at dragondata.com  Tue Dec 30 02:14:10 2008
From: toasty at dragondata.com (Kevin Day)
Date: Tue Dec 30 02:28:22 2008
Subject: lzo2 shows insane speed gap
In-Reply-To: <20081230004747.GA55542@lorvorc.mips.inka.de>
References: <gjbf7c$hbm$1@lorvorc.mips.inka.de>
	<Pine.GSO.4.64.0812291512490.22968@zeno.ucsd.edu>
	<20081230004747.GA55542@lorvorc.mips.inka.de>
Message-ID: <A829168A-EE8E-4AC9-BB49-DDE788FA3F75@dragondata.com>

>
>
> Oh, and everybody is invited to run
>
> $ cd /usr/ports/archivers/lzo2 && make
>
> and check for themselves.
>
>

I've used lzo2 quite a bit in the past and never saw this, so I  
thought I'd try this on a few boxes we have... Output is from "make  
fetch ; time make"

8-core Opteron 2350 2.0ghz, 64GB RAM, FreeBSD 7.1-PRERELEASE (just  
before RC1 was tagged), amd64
41.464u 20.671s 1:02.04 100.1%	2430+1556k 0+0io 377pf+0w

4-core Opteron 280 2.4ghz, 4GB RAM, FreeBSD 7.0-RELEASE-p6, amd64
40.907u 18.638s 1:03.08 94.3%	2339+603k 182+91io 681pf+0w

Dual Athlon MP 2100+ 1.73ghz, 1GB RAM, FreeBSD 6.3-RELEASE, i386
82.812u 44.963s 2:06.89 100.6%	959+37724k 32+82io 46pf+0w

Dual P3 850mhz, 1GB RAM, FreeBSD 7.0-RELEASE-p4, i386
208.494u 84.935s 8:07.23 60.2%	2270+990k 17+87io 60pf+0w

4-core Opteron 2218 2.6ghz, 16GB RAM, FreeBSD 7.0-RELEASE-p4, amd64
38.893u 16.623s 0:55.53 99.9%	2290+591k 96+99io 48pf+0w

Dual Xeon 3.06GHz, 4GB RAM, FreeBSD 7.0-RELEASE-p4, i386
60.910u 24.667s 1:22.54 103.6%	2143+988k 146+134io 105pf+0w

Dual P3 866mhz, 2GB RAM, FreeBSD 7.0-RELEASE-p4, i386
169.135u 58.198s 3:52.71 97.6%	2443+1002k 160+99io 368pf+0w

2-core Core 2 Duo 2.33ghz, 2GB RAM, Mac OS X 10.5.6, i386
48.155u 29.896s 1:25.14 91.6%	0+0k 30+222io 1845pf+0w

4-core Xeon 2.66ghz, 6GB RAM, Mac OS X 10.5.6, i386
real	1m17.024s user	0m44.373s sys	0m34.249s


None of these boxes were idle, so relative times are pretty useless,  
but i'm not seeing anything on the order of tens of minutes or hours.  
Is the source .tar.gz identical on all your systems?

-- Kevin

From spam at rm-rf.kiev.ua  Tue Dec 30 03:03:38 2008
From: spam at rm-rf.kiev.ua (Alex Kozlov)
Date: Tue Dec 30 03:03:54 2008
Subject: lzo2 shows insane speed gap
Message-ID: <20081230021442.GA11407@ravenloft.kiev.ua>

Christian Weisgerber <naddy@mips.inka.de> wrote:

> Oh, and everybody is invited to run                                                               
> $ cd /usr/ports/archivers/lzo2 && make
$cd /usr/ports/archivers/lzo2 && time sudo make
[...]
All tests passed. Now you are ready to install LZO.

real    1m1.041s
user    0m38.087s
sys     0m17.613s

This is Intel q6600.


--
Adios
From naddy at mips.inka.de  Tue Dec 30 13:20:56 2008
From: naddy at mips.inka.de (Christian Weisgerber)
Date: Tue Dec 30 13:21:03 2008
Subject: lzo2 shows insane speed gap
References: <gjbf7c$hbm$1@lorvorc.mips.inka.de>
	<Pine.GSO.4.64.0812291512490.22968@zeno.ucsd.edu>
	<20081230004747.GA55542@lorvorc.mips.inka.de>
	<20081230020524.2563a6ac@gluon>
Message-ID: <gjd77i$1h19$1@lorvorc.mips.inka.de>

Bruce Cran <bruce@cran.org.uk> wrote:

> I'm running 8.0-CURRENT amd64 here on a Turion64 X2 machine. Without
> malloc debugging (malloc.conf -> aj) 'make test' takes 25s; after
> removing malloc.conf thus turning on debugging, it takes over 10
> minutes.

Wow!  That.  Is.  It.

Toggling malloc debugging option J makes the "slow" machines "fast"
and vice versa.

> > Athlon 64 X2 5200+ 2.6 GHz,      FreeBSD 8.0-CURRENT amd64   ~60 min

19 seconds.

I guess that falls under the "obvious" configuration differences
to check, but since it usually doesn't cause a significant slowdown
I completely forgot about it.  Embarrassing.

But still.  Two orders of magnitude?  That is a pathological case.

-- 
Christian "naddy" Weisgerber                          naddy@mips.inka.de

From des at des.no  Tue Dec 30 14:07:02 2008
From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=)
Date: Tue Dec 30 14:07:18 2008
Subject: lzo2 shows insane speed gap
In-Reply-To: <20081230004747.GA55542@lorvorc.mips.inka.de> (Christian
	Weisgerber's message of "Tue, 30 Dec 2008 01:47:47 +0100")
References: <gjbf7c$hbm$1@lorvorc.mips.inka.de>
	<Pine.GSO.4.64.0812291512490.22968@zeno.ucsd.edu>
	<20081230004747.GA55542@lorvorc.mips.inka.de>
Message-ID: <86eizp4v0c.fsf@ds4.des.no>

Christian Weisgerber <naddy@mips.inka.de> writes:
> Oh, and everybody is invited to run
>
> $ cd /usr/ports/archivers/lzo2 && make

I assume you meant "time make".

This is insane:

     3108.27 real      1215.69 user      1888.06 sys

on an E6600 with 4 GB RAM.

What surprises me most is the high sys time.

DES
-- 
Dag-Erling Sm?rgrav - des@des.no
From brd at FreeBSD.org  Wed Dec 31 16:02:13 2008
From: brd at FreeBSD.org (Brad Davis)
Date: Wed Dec 31 16:02:19 2008
Subject: FreeBSD Status Reports due January 14th, 2009
Message-ID: <20081231153327.GD80570@valentine.liquidneon.com>

Hi Everyone,

Happy New Year!  We would like to remind everybody who has exciting
news to share to write a report about their project.  This is a
good way to improve exposure of your work, receive feedback and help.

We are looking forward to your reports.  As always you can either use
the template or the CGI generator and mail the output to monthly@ by
Wednesday January 14th, 2009.

http://www.freebsd.org/news/status/
http://www.freebsd.org/cgi/monthly.cgi
http://www.freebsd.org/news/status/report-sample.xml


Regards,
Brad Davis