From peterjeremy at optushome.com.au  Thu Jan  1 02:42:31 2009
From: peterjeremy at optushome.com.au (Peter Jeremy)
Date: Thu Jan  1 02:42:38 2009
Subject: Interval timers firing early
Message-ID: <20090101024228.GF87057@server.vk2pj.dyndns.org>

I have some code that uses setitimer() to generate one-shot timers of
~60s (the intent is to fire ~10msec before the minute boundary).

On my amd64 laptop running 7.0-stable from mid-March the SIGALRM
arrives at the expected time.  On a system running a recent amd64
-current, the SIGALRM arrives about 10msec late (which I'm not too
fussed about).

On two i386 systems running 7.1-PRE (from mid-Oct) and a fresh 7.1-RC2
install, the SIGALRM arrives early - ~11msec for the 7.1-PRE system and
~5msec for the 7.1-RC2 system.

All systems are running HZ=1000.  Two of the systems (the one running
7.1-PRE and the one running -current) are running BOINC.  All systems
are otherwise unloaded.  I've looked at the timer code and can't
quickly see anything that would explain this.  Does anyone have any
ideas?

The relevant code looks like the following:
    while (1) {
	struct timeval		now;
	struct itimerval	it;
	int			usecs;

	if (gettimeofday(&now, NULL) < 0) {
	    syslog(LOG_ERR, "gettimeofday: %m");
	    exit(1);
	}
	/* Set timer for just before next minute */
	it.it_interval.tv_sec = 0;
	it.it_interval.tv_usec = 0;
	usecs = 59990000 - ((now.tv_sec % 60) * 1000000 + now.tv_usec);
	if (usecs < 10000)	/* allow 10msec slop */
	    usecs += 60000000;
	it.it_value.tv_sec = usecs / 1000000;
	it.it_value.tv_usec = usecs % 1000000;
	if (setitimer(ITIMER_REAL, &it, NULL) < 0) {
	    syslog(LOG_ERR, "setitimer: %m");
	    exit(1);
	}
	printf("%d.%06ld %2d.%06ld %d\n", now.tv_sec, now.tv_usec,
	       it.it_value.tv_sec, it.it_value.tv_usec, usecs);
	/* do stuff here which is interrupted by SIGALRM */
    }

On the 7.1-PRE system, I get output like:
1230776939.991464 59.998536 59998536
1230776999.978991  0.011009 11009
1230776999.991996 59.998004 59998004
1230777059.979532  0.010468 10468
1230777059.991538 59.998462 59998462
1230777119.979058  0.010942 10942
1230777119.991065 59.998935 59998935
1230777179.978597  0.011403 11403
1230777179.991610 59.998390 59998390
1230777239.979139  0.010861 10861
1230777239.991142 59.998858 59998858

-- 
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-stable/attachments/20090101/9a2aa1b0/attachment.pgp
From barbara.xxx1975 at libero.it  Thu Jan  1 06:31:23 2009
From: barbara.xxx1975 at libero.it (Barbara)
Date: Thu Jan  1 06:31:31 2009
Subject: Lock enabling onboard lan (Attansic L1 GbE) on 7.1-PRERELEASE
Message-ID: <9459365.789371230791479265.JavaMail.defaultUser@defaultHost>

>> Today I decided to give it a try.
>> But if I try loading the if_age module, 
the
>> system prints the following lines and then it freezes.
>
>
>
>Could you 
please print the full dmesg / uname (build date) output?
>
>
>Thanks.
>
>
>---

>Kevin K.
>Systems Administrator
>www.linux-vps-servers.com
>

Sure!
/usr/src 
has been synced right before starting the buildworld.
# uname -a
FreeBSD 
satanasso.local.net 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #0: Wed Dec 31 03:55:
33 CET 2008     root@satanasso.local.net:/usr/obj/usr/src/sys/SATANASSO  i386


If I load age adding it in my kernconf or with the loader, the system freezes 
so the relevant part on dmesg should be the following two lines:
pci4: <ACPI 
PCI bus> on pcib5
pci4: <network, ethernet> at device 0.0 (no driver attached)



Here comes the full dmesg output.
Unfortunately the web client of my mail 
provider, does something stupid with the text, so I know it could be confused.

If asked I can send it via email as attachment.

# dmesg
Copyright (c) 1992-
2009 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 
1991, 1992, 1993, 1994
        The Regents of the University of California. All 
rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.

FreeBSD 7.1-PRERELEASE #0: Wed Dec 31 03:55:33 CET 2008
    root@satanasso.
local.net:/usr/obj/usr/src/sys/SATANASSO
Timecounter "i8254" frequency 1193182 
Hz quality 0
CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 4800+ (2499.74-MHz 
686-class CPU)
  Origin = "AuthenticAMD"  Id = 0x60fb1  Stepping = 1
  
Features=0x178bfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,
CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT>
  Features2=0x2001<SSE3,CX16>
  
AMD Features=0xea500800<SYSCALL,NX,MMX+,FFXSR,RDTSCP,LM,3DNow!+,3DNow!>
  AMD 
Features2=0x11f<LAHF,CMP,SVM,ExtAPIC,CR8,Prefetch>
  Cores per package: 2
real 
memory  = 2147155968 (2047 MB)
avail memory = 2087157760 (1990 MB)
ACPI APIC 
Table: <A_M_I_ OEMAPIC >
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
 
cpu0 (BSP): APIC ID:  0
 cpu1 (AP): APIC ID:  1
ioapic0 <Version 0.3> irqs 0-23 
on motherboard
ioapic1 <Version 0.3> irqs 24-47 on motherboard
kbd1 at kbdmux0

acpi0: <A_M_I_ OEMRSDT> on motherboard
acpi0: [ITHREAD]
acpi0: Power Button 
(fixed)
acpi0: reservation of 0, a0000 (3) failed
acpi0: reservation of 100000, 
7ff00000 (3) failed
Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000

acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0

acpi_hpet0: <High Precision Event Timer> iomem 0xfed00000-0xfed003ff on acpi0

Timecounter "HPET" frequency 14318180 Hz quality 900
pcib0: <ACPI Host-PCI 
bridge> port 0xcf8-0xcff on acpi0
pci0: <ACPI PCI bus> on pcib0
pcib1: <ACPI 
PCI-PCI bridge> at device 1.0 on pci0
pci1: <ACPI PCI bus> on pcib1
pcib2: 
<ACPI PCI-PCI bridge> irq 27 at device 2.0 on pci0
pci2: <ACPI PCI bus> on 
pcib2
vgapci0: <VGA-compatible display> port 0xdc00-0xdc7f mem 0xfa000000-
0xfaffffff,0xd0000000-0xdfffffff,0xf8000000-0xf9ffffff irq 24 at device 0.0 on 
pci2
nvidia0: <GeForce 8500 GT> on vgapci0
vgapci0: child nvidia0 requested 
pci_enable_busmaster
vgapci0: child nvidia0 requested pci_enable_io
nvidia0: 
[GIANT-LOCKED]
nvidia0: [ITHREAD]
pcib3: <ACPI PCI-PCI bridge> irq 31 at device 
3.0 on pci0
pci6: <ACPI PCI bus> on pcib3
pcib4: <ACPI PCI-PCI bridge> irq 35 
at device 3.1 on pci0
pci5: <ACPI PCI bus> on pcib4
pcib5: <ACPI PCI-PCI 
bridge> irq 39 at device 3.2 on pci0
pci4: <ACPI PCI bus> on pcib5
pci4: 
<network, ethernet> at device 0.0 (no driver attached)
pcib6: <ACPI PCI-PCI 
bridge> irq 43 at device 3.3 on pci0
pci3: <ACPI PCI bus> on pcib6
atapci0: 
<VIA 8237A SATA150 controller> port 0xcc00-0xcc07,0xc880-0xc883,0xc800-0xc807,
0xc480-0xc483,0xc400-0xc40f,0xc000-0xc0ff irq 21 at device 15.0 on pci0

atapci0: [ITHREAD]
ata2: <ATA channel 0> on atapci0
ata2: [ITHREAD]
ata3: <ATA 
channel 1> on atapci0
ata3: [ITHREAD]
atapci1: <VIA 8237A UDMA133 controller> 
port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfc00-0xfc0f at device 15.1 on pci0

ata0: <ATA channel 0> on atapci1
ata0: [ITHREAD]
ata1: <ATA channel 1> on 
atapci1
ata1: [ITHREAD]
uhci0: <VIA 83C572 USB controller> port 0xb480-0xb49f 
irq 20 at device 16.0 on pci0
uhci0: [GIANT-LOCKED]
uhci0: [ITHREAD]
usb0: <VIA 
83C572 USB controller> on uhci0
usb0: USB revision 1.0
uhub0: <VIA UHCI root 
hub, class 9/0, rev 1.00/1.00, addr 1> on usb0
uhub0: 2 ports with 2 removable, 
self powered
uhci1: <VIA 83C572 USB controller> port 0xb800-0xb81f irq 22 at 
device 16.1 on pci0
uhci1: [GIANT-LOCKED]
uhci1: [ITHREAD]
usb1: <VIA 83C572 
USB controller> on uhci1
usb1: USB revision 1.0
uhub1: <VIA UHCI root hub, 
class 9/0, rev 1.00/1.00, addr 1> on usb1
uhub1: 2 ports with 2 removable, self 
powered
uhci2: <VIA 83C572 USB controller> port 0xb880-0xb89f irq 21 at device 
16.2 on pci0
uhci2: [GIANT-LOCKED]
uhci2: [ITHREAD]
usb2: <VIA 83C572 USB 
controller> on uhci2
usb2: USB revision 1.0
uhub2: <VIA UHCI root hub, class 
9/0, rev 1.00/1.00, addr 1> on usb2
uhub2: 2 ports with 2 removable, self 
powered
uhci3: <VIA 83C572 USB controller> port 0xbc00-0xbc1f irq 23 at device 
16.3 on pci0
uhci3: [GIANT-LOCKED]
uhci3: [ITHREAD]
usb3: <VIA 83C572 USB 
controller> on uhci3
usb3: USB revision 1.0
uhub3: <VIA UHCI root hub, class 
9/0, rev 1.00/1.00, addr 1> on usb3
uhub3: 2 ports with 2 removable, self 
powered
ehci0: <VIA VT6202 USB 2.0 controller> mem 0xf7fffc00-0xf7fffcff irq 21 
at device 16.4 on pci0
ehci0: [GIANT-LOCKED]
ehci0: [ITHREAD]
usb4: EHCI 
version 1.0
usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3

usb4: <VIA VT6202 USB 2.0 controller> on ehci0
usb4: USB revision 2.0
uhub4: 
<VIA EHCI root hub, class 9/0, rev 2.00/1.00, addr 1> on usb4
uhub4: 8 ports 
with 8 removable, self powered
isab0: <PCI-ISA bridge> at device 17.0 on pci0

isa0: <ISA bus> on isab0
pcib7: <ACPI PCI-PCI bridge> at device 19.0 on pci0

pci128: <ACPI PCI bus> on pcib7
pcm0: <VIA VT8251/8237A High Definition Audio 
Controller> mem 0xfbffc000-0xfbffffff irq 17 at device 1.0 on pci128
pcm0: 
[ITHREAD]
pcib8: <ACPI PCI-PCI bridge> at device 19.1 on pci0
pci7: <ACPI PCI 
bus> on pcib8
rl0: <RealTek 8139 10/100BaseTX> port 0xe800-0xe8ff mem 
0xfbeffc00-0xfbeffcff irq 19 at device 9.0 on pci7
miibus0: <MII bus> on rl0

rlphy0: <RealTek internal media interface> PHY 0 on miibus0
rlphy0:  10baseT, 
10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
rl0: Ethernet address: 00:08:a1:27:
1f:bb
rl0: [ITHREAD]
acpi_button0: <Sleep Button> on acpi0
acpi_button1: <Power 
Button> on acpi0
fdc0: <floppy drive controller (FDE)> port 0x3f0-0x3f5,0x3f7 
irq 6 drq 2 on acpi0
fdc0: [FILTER]
fd0: <1440-KB 3.5" drive> on fdc0 drive 0

sio0: configured irq 4 not in bitmap of probed irqs 0
sio0: port may not be 
enabled
sio0: configured irq 4 not in bitmap of probed irqs 0
sio0: port may 
not be enabled
sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 
0x10 on acpi0
sio0: type 16550A
sio0: [FILTER]
atkbdc0: <Keyboard controller 
(i8042)> port 0x60,0x64 irq 1 on acpi0
atkbd0: <AT Keyboard> irq 1 on atkbdc0

kbd0 at atkbd0
atkbd0: [GIANT-LOCKED]
atkbd0: [ITHREAD]
psm0: <PS/2 Mouse> irq 
12 on atkbdc0
psm0: [GIANT-LOCKED]
psm0: [ITHREAD]
psm0: model IntelliMouse 
Explorer, device ID 4
cpu0: <ACPI CPU> on acpi0
acpi_throttle0: <ACPI CPU 
Throttling> on cpu0
powernow0: <PowerNow! K8> on cpu0
cpu1: <ACPI CPU> on acpi0

powernow1: <PowerNow! K8> on cpu1
pmtimer0 on isa0
orm0: <ISA Option ROM> at 
iomem 0xcd000-0xcdfff pnpid ORM0000 on isa0
sc0: <System console> at flags 
0x100 on isa0
sc0: VGA <16 virtual consoles, flags=0x300>
vga0: <Generic ISA 
VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0
ppc0: <Parallel port> at 
port 0x378-0x37f irq 7 on isa0
ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE 
mode
ppbus0: <Parallel port bus> on ppc0
ppbus0: [ITHREAD]
plip0: <PLIP network 
interface> on ppbus0
plip0: WARNING: using obsoleted IFF_NEEDSGIANT flag
lpt0: 
<Printer> on ppbus0
lpt0: Interrupt-driven port
ppi0: <Parallel I/O> on ppbus0

ppc0: [GIANT-LOCKED]
ppc0: [ITHREAD]
sio1: configured irq 3 not in bitmap of 
probed irqs 0
sio1: port may not be enabled
Timecounters tick every 1.000 msec

ad0: 152627MB <MAXTOR STM3160212A 3.AAJ> at ata0-master UDMA100
ad1: 117246MB 
<Maxtor 6Y120L0 YAR41BW0> at ata0-slave UDMA133
acd0: DVDR <PIONEER DVD-RW DVR-
109/1.58> at ata1-master UDMA66
ad4: 238475MB <WDC WD2500KS-00MJB0 02.01C03> at 
ata2-master SATA150
pcm0: <HDA Codec: Realtek ALC660>
pcm0: <HDA Driver 
Revision: 20080420_0052>
SMP: AP CPU #1 Launched!
GEOM_LABEL: Label for 
provider ad0s3 is ext2fs//boot.
GEOM_LABEL: Label for provider ad0s6 is 
ext2fs//.
Trying to mount root from ufs:/dev/ad4s3a

Thank you and happy new 
year.

From barbara.xxx1975 at libero.it  Thu Jan  1 06:36:28 2009
From: barbara.xxx1975 at libero.it (Barbara)
Date: Thu Jan  1 06:46:56 2009
Subject: Lock enabling onboard lan (Attansic L1 GbE) on 7.1-PRERELEASE
Message-ID: <23818446.789391230791785972.JavaMail.defaultUser@defaultHost>

>>> Today I decided to give it a try.
>>> But if I try loading the if_age 
module, 
>the
>>> system prints the following lines and then it freezes.
>>
>>

>>
>>Could you 
>please print the full dmesg / uname (build date) output?
>>
>>

>>Thanks.
>>
>>
>>---
>
>>Kevin K.
>>Systems Administrator
>>www.linux-vps-
servers.com
>>
>

Maybe this is better:
http://pastebin.ca/1297510

From ericlin at tamama.org  Thu Jan  1 15:59:48 2009
From: ericlin at tamama.org (Lin Jui-Nan Eric)
Date: Thu Jan  1 15:59:55 2009
Subject: amd(8) cores dump when load high
In-Reply-To: <20081229180508.GA78494@dragon.NUXI.org>
References: <47713ee10812220844r7889d286l3a98f294d780ccc0@mail.gmail.com>
	<6eb82e0812260202m1d8816c5mc7b0991514f83853@mail.gmail.com>
	<47713ee10812261117o6f772843o53ec9542bc773141@mail.gmail.com>
	<E1LGUt5-000Jpj-2L@kabab.cs.huji.ac.il>
	<47713ee10812270105o5866aa27u9998539dc127e549@mail.gmail.com>
	<E1LGWxW-000Kuc-AS@kabab.cs.huji.ac.il>
	<20081229103916.GA29184@hub.freebsd.org>
	<E1LHFfm-000NRe-6p@kabab.cs.huji.ac.il>
	<20081229180508.GA78494@dragon.NUXI.org>
Message-ID: <47713ee10901010759v9cf328pff89d0e678361053@mail.gmail.com>

Update: After we add -S flag to "amd_flags" in /etc/rc.conf, amd does
not core dump.
I think it is a workaround solution.

Thank you all guys!
From mattias.bjork at sydnet.net  Fri Jan  2 03:24:40 2009
From: mattias.bjork at sydnet.net (=?ISO-8859-1?Q?Mattias_Bj=F6rk?=)
Date: Fri Jan  2 03:24:48 2009
Subject: Make world builderror on 7.1-BETA2 with latest cvsup
Message-ID: <495D88B9.6060408@sydnet.net>

Hello everybody,

First of all, my bad if this get sent two times.

I have a compile error/problem when building world.

My uname -a output is:

FreeBSD barabolaptop 7.1-BETA2 FreeBSD 7.1-BETA2 #0: Thu Dec  4 20:52:35
CET 2008     root@barabolaptop:/usr/obj/usr/src/sys/BARABOLAPTOP  i386

My make.conf looks like:

# added by use.perl 2008-12-03 00:58:09
PERL_VER=5.8.8
PERL_VERSION=5.8.8
WRKDIRPREFIX=/var/tmp


The options.h file in /usr/obj/usr/src/gnu/usr.bin/cc/cc_tools/options.h

Here are the output of options.h from pastebin:

http://pastebin.com/m254dfedf


When I run "make -j1 buildworld" i get the error is as following:

http://pastebin.com/m57738677

I don't know much of programming (if any), but I have tried to change
things in (remove OPT_w from both places) options.h and runned
"make -j1 -DNOCLEAN buildworld"

But that have not solve anything of this, perhaps some can shine some
light on this or have I missed something trivial?
I can build ports and so on without any problems.

Thank you.

From mattias.bjork at sydnet.net  Fri Jan  2 03:29:28 2009
From: mattias.bjork at sydnet.net (=?ISO-8859-1?Q?Mattias_Bj=F6rk?=)
Date: Fri Jan  2 03:29:36 2009
Subject: Make world builderror on 7.1-BETA2 with latest cvsup
Message-ID: <495D8516.1080109@sydnet.net>

Hello everybody,

I have a compile error/problem when building world.

My uname -a output is:

FreeBSD barabolaptop 7.1-BETA2 FreeBSD 7.1-BETA2 #0: Thu Dec  4 20:52:35
CET 2008     root@barabolaptop:/usr/obj/usr/src/sys/BARABOLAPTOP  i386

My make.conf looks like:

# added by use.perl 2008-12-03 00:58:09
PERL_VER=5.8.8
PERL_VERSION=5.8.8
WRKDIRPREFIX=/var/tmp


The options.h file in /usr/obj/usr/src/gnu/usr.bin/cc/cc_tools/options.h

Here are the output of options.h from pastebin:

http://pastebin.com/m254dfedf


When I run "make -j1 buildworld" i get the error is as following:

http://pastebin.com/m57738677

I don't know much of programming (if any), but I have tried to change
things in (remove OPT_w from both places) options.h and runned
"make -j1 -DNOCLEAN buildworld"

But that have not solve anything of this, perhaps some can shine some
light on this or have I missed something trivial?
I can build ports and so on without any problems.

Thank you.
From yanefbsd at gmail.com  Fri Jan  2 05:50:36 2009
From: yanefbsd at gmail.com (Garrett Cooper)
Date: Fri Jan  2 05:50:44 2009
Subject: Make world builderror on 7.1-BETA2 with latest cvsup
In-Reply-To: <495D88B9.6060408@sydnet.net>
References: <495D88B9.6060408@sydnet.net>
Message-ID: <2D7731A8-9AAC-4F8C-B3A0-01DFBC84E407@gmail.com>

On Jan 1, 2009, at 19:23, Mattias Bj?rk <mattias.bjork@sydnet.net>  
wrote:

> Hello everybody,
>
> First of all, my bad if this get sent two times.
>
> I have a compile error/problem when building world.
>
> My uname -a output is:
>
> FreeBSD barabolaptop 7.1-BETA2 FreeBSD 7.1-BETA2 #0: Thu Dec  4  
> 20:52:35
> CET 2008     root@barabolaptop:/usr/obj/usr/src/sys/BARABOLAPTOP  i386
>
> My make.conf looks like:
>
> # added by use.perl 2008-12-03 00:58:09
> PERL_VER=5.8.8
> PERL_VERSION=5.8.8
> WRKDIRPREFIX=/var/tmp
>
>
> The options.h file in /usr/obj/usr/src/gnu/usr.bin/cc/cc_tools/ 
> options.h
>
> Here are the output of options.h from pastebin:
>
> http://pastebin.com/m254dfedf
>
>
> When I run "make -j1 buildworld" i get the error is as following:
>
> http://pastebin.com/m57738677
>
> I don't know much of programming (if any), but I have tried to change
> things in (remove OPT_w from both places) options.h and runned
> "make -j1 -DNOCLEAN buildworld"
>
> But that have not solve anything of this, perhaps some can shine some
> light on this or have I missed something trivial?
> I can build ports and so on without any problems.
>
> Thank you.

Not enough data. Please send a full compressed version of the log to me.
Thanks!
-Garrett
From ericlin at tamama.org  Fri Jan  2 06:49:30 2009
From: ericlin at tamama.org (Lin Jui-Nan Eric)
Date: Fri Jan  2 06:49:43 2009
Subject: TCP packet out-of-order problem
In-Reply-To: <47713ee10901012147k1f25c31bn512dd29b2b294ad5@mail.gmail.com>
References: <47713ee10812301206j12b35264o715976c154080a1b@mail.gmail.com>
	<47713ee10901012147k1f25c31bn512dd29b2b294ad5@mail.gmail.com>
Message-ID: <47713ee10901012249w65c659bbp3366e4d8ef25c59d@mail.gmail.com>

Dear All listers,

After running "netstat -s -p tcp", we found that lots of packets are
discarded due to memory problems. We googled for it, and found that
sysctl oid "net.inet.tcp.reass.maxsegments" became 0, therefore
packets never reassembled.

Then we checked our /boot/loader.conf and /etc/sysctl.conf, and found
that setting kern.ipc.nmbclusters="0" makes
net.inet.tcp.reass.maxsegments=0.
After setting net.inet.tcp.reass.maxsegments="1600" in
/boot/loader.conf, the network works perfectly now.

Thank you all for the help!
From kometen at gmail.com  Fri Jan  2 07:50:51 2009
From: kometen at gmail.com (Claus Guttesen)
Date: Fri Jan  2 07:50:58 2009
Subject: Make world builderror on 7.1-BETA2 with latest cvsup
In-Reply-To: <495D88B9.6060408@sydnet.net>
References: <495D88B9.6060408@sydnet.net>
Message-ID: <b41c75520901012323u4788ed33t60df7ee6e830999a@mail.gmail.com>

> I have a compile error/problem when building world.
>
> My uname -a output is:
>
> FreeBSD barabolaptop 7.1-BETA2 FreeBSD 7.1-BETA2 #0: Thu Dec  4 20:52:35
> CET 2008     root@barabolaptop:/usr/obj/usr/src/sys/BARABOLAPTOP  i386

Sync the time on your computer and try the buildworld again.

-- 
regards
Claus

When lenity and cruelty play for a kingdom,
the gentler gamester is the soonest winner.

Shakespeare
From david at catwhisker.org  Fri Jan  2 15:48:58 2009
From: david at catwhisker.org (David Wolfskill)
Date: Fri Jan  2 15:49:06 2009
Subject: newfs(8) parameters from "dumpfs -m" have bad -s value?
Message-ID: <20090102153455.GR4100@albert.catwhisker.org>

I have a requirement to be able to re-create a largish file system on
occasion.  The file system was created with some non-default newfs(8)
parameters.

Once I found about it, it seemed that the output of "dumpfs -m"
would be ideal to use in the script that performs the analysis &
(if appropriate) re-creation.

But I found that that output (in this case, at least) includes a rather
bogus "-s" parameter.  A circumvention is to interpose a sed(1)
invocation to elide the parameter, but that seems a tad ... ugly (though
admittedly effective).

I'm running 7.1-RC1 on the systems in question.

Here's the supporting evidence:

We start with one of the file systems in question as it is supposed to be:

pool10(7.1-RC1)[32] df -ki /dev/da1s1d
Filesystem  1024-blocks Used      Avail Capacity iused     ifree %iused  Mounted on
/dev/da1s1d  1702753030    4 1566532784     0%       2 220046332    0%   /b
pool10(7.1-RC1)[33] 

Here's what dumpfs(8) says:

pool10(7.1-RC1)[36] dumpfs -m /dev/da1s1d
# newfs command for /dev/da1s1d (/dev/da1s1d)
newfs -O 2 -U -a 8 -b 16384 -d 16384 -e 2048 -f 2048 -g 16384 -h 64 -m 8 -o time -s 879031908 /dev/da1s1d 
pool10(7.1-RC1)[37] 

I then unmount the file system & re-create it naively:

pool10(7.1-RC1)[37] umount /dev/da1s1d
pool10(7.1-RC1)[38] dumpfs -m /dev/da1s1d | sh
/dev/da1s1d: 429214.8MB (879031908 sectors) block size 16384, fragment size 2048
        using 2336 cylinder groups of 183.77MB, 11761 blks, 23552 inodes.
        with soft updates
super-block backups (for fsck -b #) at:
 160, 376512, 752864, 1129216, 1505568, 1881920, 2258272, 2634624, 3010976,
...
 876523968, 876900320, 877276672, 877653024, 878029376, 878405728, 878782080
pool10(7.1-RC1)[39] df -ki /dev/da1s1d
Filesystem         1024-blocks      Used     Avail Capacity  iused    ifree %iused  Mounted on
/dev/da1s1d          425686716         4 391631776     0%        2 55017468    0%   
pool10(7.1-RC1)[40] 

The file system had been 1702753030 KB; it is now 425686716 KB -- 25% of its
intended size.

By eliding the -s parameter, we get:

pool10(7.1-RC1)[40] dumpfs -m /b | sed -Ee 's/ -s [0-9]+ / /' | sh
/dev/da1s1d: 1716859.2MB (3516127632 sectors) block size 16384, fragment size 2048
        using 9343 cylinder groups of 183.77MB, 11761 blks, 23552 inodes.
        with soft updates
super-block backups (for fsck -b #) at:
 160, 376512, 752864, 1129216, 1505568, 1881920, 2258272, 2634624, 3010976,
...
 3513622432, 3513998784, 3514375136, 3514751488, 3515127840, 3515504192,
 3515880544
pool10(7.1-RC1)[41] df -ki /dev/da1s1d
Filesystem         1024-blocks      Used     Avail Capacity  iused    ifree %iused  Mounted on
/dev/da1s1d         1702753030         4 1566532784     0%        2 220046332    0%   
pool10(7.1-RC1)[42] 

[Sorry about the long lines....]

Is dumpfs(8) actually behaving as expected (or correctly) in this case?

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-stable/attachments/20090102/e0bb45dc/attachment.pgp
From mattias.bjork at sydnet.net  Fri Jan  2 19:52:33 2009
From: mattias.bjork at sydnet.net (=?UTF-8?B?TWF0dGlhcyBCasO2cms=?=)
Date: Fri Jan  2 19:52:41 2009
Subject: Make world builderror on 7.1-BETA2 with latest cvsup
In-Reply-To: <2D7731A8-9AAC-4F8C-B3A0-01DFBC84E407@gmail.com>
References: <495D88B9.6060408@sydnet.net>
	<2D7731A8-9AAC-4F8C-B3A0-01DFBC84E407@gmail.com>
Message-ID: <495E703F.5050805@sydnet.net>

Hello Garret,


Garrett Cooper wrote:
> On Jan 1, 2009, at 19:23, Mattias Bj?rk <mattias.bjork@sydnet.net> wrote:
> 
>> Hello everybody,
>>
>> First of all, my bad if this get sent two times.
>>
>> I have a compile error/problem when building world.
>>
>> My uname -a output is:
>>
>> FreeBSD barabolaptop 7.1-BETA2 FreeBSD 7.1-BETA2 #0: Thu Dec  4 20:52:35
>> CET 2008     root@barabolaptop:/usr/obj/usr/src/sys/BARABOLAPTOP  i386
>>
>> My make.conf looks like:
>>
>> # added by use.perl 2008-12-03 00:58:09
>> PERL_VER=5.8.8
>> PERL_VERSION=5.8.8
>> WRKDIRPREFIX=/var/tmp
>>
>>
>> The options.h file in /usr/obj/usr/src/gnu/usr.bin/cc/cc_tools/options.h
>>
>> Here are the output of options.h from pastebin:
>>
>> http://pastebin.com/m254dfedf
>>
>>
>> When I run "make -j1 buildworld" i get the error is as following:
>>
>> http://pastebin.com/m57738677
>>
>> I don't know much of programming (if any), but I have tried to change
>> things in (remove OPT_w from both places) options.h and runned
>> "make -j1 -DNOCLEAN buildworld"
>>
>> But that have not solve anything of this, perhaps some can shine some
>> light on this or have I missed something trivial?
>> I can build ports and so on without any problems.
>>
>> Thank you.
> 
> Not enough data. Please send a full compressed version of the log to me.
> Thanks!


No thank you, :) I will send it to you directly.


> -Garrett_______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
From mattias.bjork at sydnet.net  Fri Jan  2 20:05:55 2009
From: mattias.bjork at sydnet.net (=?ISO-8859-1?Q?Mattias_Bj=F6rk?=)
Date: Fri Jan  2 20:06:02 2009
Subject: Make world builderror on 7.1-BETA2 with latest cvsup
In-Reply-To: <b41c75520901012323u4788ed33t60df7ee6e830999a@mail.gmail.com>
References: <495D88B9.6060408@sydnet.net>
	<b41c75520901012323u4788ed33t60df7ee6e830999a@mail.gmail.com>
Message-ID: <495E735A.7060707@sydnet.net>

Hello Claus,

Claus Guttesen wrote:
>> I have a compile error/problem when building world.
>>
>> My uname -a output is:
>>
>> FreeBSD barabolaptop 7.1-BETA2 FreeBSD 7.1-BETA2 #0: Thu Dec  4 20:52:35
>> CET 2008     root@barabolaptop:/usr/obj/usr/src/sys/BARABOLAPTOP  i386
> 
> Sync the time on your computer and try the buildworld again.
> 


I have tried that several times, even removed /usr/src/* entirely and 
started from scratch. And tried a couple of other cvsup.XX.freebsd.org 
servers. Still no go Claus :(

Any more suggestions ?

Thanks so far.
From oliver.pntr at gmail.com  Fri Jan  2 20:09:51 2009
From: oliver.pntr at gmail.com (Oliver Pinter)
Date: Fri Jan  2 20:09:58 2009
Subject: FreeBSD 7.1 svn186551
Message-ID: <6101e8c40901021209g1eb6ca88wda79bd62823268bb@mail.gmail.com>

Hi All!

I have the question, why reverted the ICH10 support from 7.1?
This is the svn commit:
http://svnweb.freebsd.org/viewvc/base/releng/?pathrev=186551

What is the PR number of the base of this commit or what is the
problem description?

I have a motherboard with ich10r with 3 sata2 disc (hitachi) + 1 sata
dvd-rw (samsung), without any problem.

Sorry for bad spelling or english
From veldy71 at gmail.com  Fri Jan  2 21:03:03 2009
From: veldy71 at gmail.com (Thomas T. Veldhouse)
Date: Fri Jan  2 21:03:10 2009
Subject: Update ports on 6.3 or update OS to 7.1(RC2) and update ports?
Message-ID: <495E79EF.8000601@gmail.com>

I have a machine where several of my installed applications are getting 
way behind.  It is not a mission critical server, but I need it to be 
stable (I have all fairly old well supported hardware, nothing special).

Since updating and rebuilding all the ports is pretty much mandatory for 
the upgrade to 7.x and I plan to take that path soon, would most people 
consider 7.1RC2 stable enough for a move now?  The machine is a home 
server that provides several services on my network, but is rarely under 
any load.

I know this is rather vague question, so I will be happy with any vague 
answers; just positive or negative experiences with well supported 
hardware (old Dell 8250 P4 3.0GHz 1.5GB 1066 RAMBUS).

Thanks in advance,

Tom Veldhouse
From kensmith at cse.Buffalo.EDU  Fri Jan  2 21:08:25 2009
From: kensmith at cse.Buffalo.EDU (Ken Smith)
Date: Fri Jan  2 21:08:33 2009
Subject: FreeBSD 7.1 svn186551
In-Reply-To: <6101e8c40901021209g1eb6ca88wda79bd62823268bb@mail.gmail.com>
References: <6101e8c40901021209g1eb6ca88wda79bd62823268bb@mail.gmail.com>
Message-ID: <1230930492.12517.15.camel@neo.cse.buffalo.edu>

On Fri, 2009-01-02 at 21:09 +0100, Oliver Pinter wrote:
> Hi All!
> 
> I have the question, why reverted the ICH10 support from 7.1?
> This is the svn commit:
> http://svnweb.freebsd.org/viewvc/base/releng/?pathrev=186551
> 
> What is the PR number of the base of this commit or what is the
> problem description?
> 
> I have a motherboard with ich10r with 3 sata2 disc (hitachi) + 1 sata
> dvd-rw (samsung), without any problem.
> 
> Sorry for bad spelling or english

Unfortunately most of the email traffic related to this was off-list.
There was one message here on list from Greg Miller saying his system
locked up and giving a date for when the problem got introduced which
was between 7.1-RC1 and 7.1-RC2 so it had been a regression that snuck
in while we were in the RC phase.  It turned out the MFC that brought in
support for that chip was pulling in pieces of ATA from head that had
been intertwined with other work and it seemed likely the MFC wasn't
complete - more of the ATA pieces from head would need to be pulled in
to stabilize it.  Since we were already so far behind on getting 7.1 out
we opted to back out the change rather than try to work out what else
needed to be MFCed (which would have definitely required RC3 if we tried
to do that).

Sorry, it will just need to wait for 7.3 (though hopefully this plus the
extra stuff needed to stabilize it will work its way into 7-STABLE in
the not too distant future).

-- 
                                                Ken Smith
- From there to here, from here to      |       kensmith@cse.buffalo.edu
  there, funny things are everywhere.   |
                      - Theodore Geisel |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090102/95b69ed7/attachment.pgp
From oliver.pntr at gmail.com  Fri Jan  2 21:27:39 2009
From: oliver.pntr at gmail.com (Oliver Pinter)
Date: Fri Jan  2 21:27:46 2009
Subject: FreeBSD 7.1 svn186551
In-Reply-To: <1230930492.12517.15.camel@neo.cse.buffalo.edu>
References: <6101e8c40901021209g1eb6ca88wda79bd62823268bb@mail.gmail.com>
	<1230930492.12517.15.camel@neo.cse.buffalo.edu>
Message-ID: <6101e8c40901021327g7b976032hbe3ce935fbf15a5c@mail.gmail.com>

Thanks the problem description, then I revert the reverted patch in my
local tree.

I had a similar problem between 7.1-PRERELEASE and 7.1-RC1, it
presentdes only 1 week long, under heavy load (csup / kernel compile)
crashed the system, but after RC1 the system is very stable (more than
2 week uptime, and ooo3 and kde build, every day several times csup,
etc etc..)

On 1/2/09, Ken Smith <kensmith@cse.buffalo.edu> wrote:
> On Fri, 2009-01-02 at 21:09 +0100, Oliver Pinter wrote:
>> Hi All!
>>
>> I have the question, why reverted the ICH10 support from 7.1?
>> This is the svn commit:
>> http://svnweb.freebsd.org/viewvc/base/releng/?pathrev=186551
>>
>> What is the PR number of the base of this commit or what is the
>> problem description?
>>
>> I have a motherboard with ich10r with 3 sata2 disc (hitachi) + 1 sata
>> dvd-rw (samsung), without any problem.
>>
>> Sorry for bad spelling or english
>
> Unfortunately most of the email traffic related to this was off-list.
> There was one message here on list from Greg Miller saying his system
> locked up and giving a date for when the problem got introduced which
> was between 7.1-RC1 and 7.1-RC2 so it had been a regression that snuck
> in while we were in the RC phase.  It turned out the MFC that brought in
> support for that chip was pulling in pieces of ATA from head that had
> been intertwined with other work and it seemed likely the MFC wasn't
> complete - more of the ATA pieces from head would need to be pulled in
> to stabilize it.  Since we were already so far behind on getting 7.1 out
> we opted to back out the change rather than try to work out what else
> needed to be MFCed (which would have definitely required RC3 if we tried
> to do that).
>
> Sorry, it will just need to wait for 7.3 (though hopefully this plus the
> extra stuff needed to stabilize it will work its way into 7-STABLE in
> the not too distant future).
>
> --
>                                                 Ken Smith
> - From there to here, from here to      |       kensmith@cse.buffalo.edu
>   there, funny things are everywhere.   |
>                       - Theodore Geisel |
>
From yanefbsd at gmail.com  Fri Jan  2 22:54:40 2009
From: yanefbsd at gmail.com (Garrett Cooper)
Date: Fri Jan  2 22:54:48 2009
Subject: Update ports on 6.3 or update OS to 7.1(RC2) and update ports?
In-Reply-To: <495E79EF.8000601@gmail.com>
References: <495E79EF.8000601@gmail.com>
Message-ID: <AD59681D-CA24-4A77-B550-04E54A7105F2@gmail.com>

On Jan 2, 2009, at 12:32, "Thomas T. Veldhouse" <veldy71@gmail.com>  
wrote:

> I have a machine where several of my installed applications are  
> getting way behind.  It is not a mission critical server, but I need  
> it to be stable (I have all fairly old well supported hardware,  
> nothing special).
>
> Since updating and rebuilding all the ports is pretty much mandatory  
> for the upgrade to 7.x and I plan to take that path soon, would most  
> people consider 7.1RC2 stable enough for a move now?  The machine is  
> a home server that provides several services on my network, but is  
> rarely under any load.
>
> I know this is rather vague question, so I will be happy with any  
> vague answers; just positive or negative experiences with well  
> supported hardware (old Dell 8250 P4 3.0GHz 1.5GB 1066 RAMBUS).
>
> Thanks in advance,
>
> Tom Veldhouse

Tom,
     Based on my experimentation, I'd say 7.1 rc2 is stable enough for  
your hardware.
     More bleeding edge hardware appears to be a problem with the rc  
version.
Cheers,
-Garrett
From mattias.bjork at sydnet.net  Sat Jan  3 06:50:59 2009
From: mattias.bjork at sydnet.net (=?ISO-8859-1?Q?Mattias_Bj=F6rk?=)
Date: Sat Jan  3 06:51:07 2009
Subject: Make world builderror on 7.1-BETA2 with latest cvsup
In-Reply-To: <b41c75520901021231j385110bma699d56c4dc5ff7f@mail.gmail.com>
References: <495D88B9.6060408@sydnet.net>	
	<b41c75520901012323u4788ed33t60df7ee6e830999a@mail.gmail.com>	
	<495E735A.7060707@sydnet.net>
	<b41c75520901021231j385110bma699d56c4dc5ff7f@mail.gmail.com>
Message-ID: <495F0A8F.60400@sydnet.net>

Hello again :)

Claus Guttesen wrote:
> Hello Mattias.
> 
> On Fri, Jan 2, 2009 at 9:04 PM, Mattias Bj?rk <mattias.bjork@sydnet.net> wrote:
>> Hello Claus,
>>
>> Claus Guttesen wrote:
>>>> I have a compile error/problem when building world.
>>>>
>>>> My uname -a output is:
>>>>
>>>> FreeBSD barabolaptop 7.1-BETA2 FreeBSD 7.1-BETA2 #0: Thu Dec  4 20:52:35
>>>> CET 2008     root@barabolaptop:/usr/obj/usr/src/sys/BARABOLAPTOP  i386
>>> Sync the time on your computer and try the buildworld again.
>>>
>>
>> I have tried that several times, even removed /usr/src/* entirely and
>> started from scratch. And tried a couple of other cvsup.XX.freebsd.org
>> servers. Still no go Claus :(
>>
>> Any more suggestions ?
>>
>> Thanks so far.
> 
> Unfortunately not. :-/ The only times I've had problems recently
> building world was because the time on my computer was (way)
> incorrect.


Well I don't think anything is incorrect on the computer, can build
everything else fine and it goes on and on.


> You can try removing /usr/obj as well before doing a new buildworld.
> AFAIK you don't have to alter options.h to make a buildworld run
> smoothly.


I have tried too make clean ; make clean ; make cleandir ; make cleandir
and then rm -rf /usr/obj. Still the same problem I'm afraid.


> HTH.
> 

From petefrench at ticketswitch.com  Sun Jan  4 01:26:53 2009
From: petefrench at ticketswitch.com (Pete French)
Date: Sun Jan  4 01:27:01 2009
Subject: slow zvol performance compared to files on the same pool
Message-ID: <E1LJHlS-000EO4-SB@dilbert.ticketswitch.com>

I was experimenting with iscsi earlier, using both a flat file as the
backing store and also a zvol. I noticed that the zvol was giving me
dreadful performance - reading at about 20 meg/second and writing at
about 12. the fklat file gives about 45 meg/second both ways.

i thouht it was to do wuth the iscsi layer, but I then tried it using
dd on the machinbe itself and got the same results. it seems very
curious - I am creating both the filesystem for the iscsi file and the
zvol on the same pool, so the underlying discs (4 x 15k SCSI drives on
U320) are the same in both places, as is the pool.

anybody got any opinions ? this is on 7.1-RC2, but I have nothing else
to compare it to. 

-pete.
From lists at avioc.org  Sun Jan  4 01:33:24 2009
From: lists at avioc.org (Brandon Weisz)
Date: Sun Jan  4 01:33:33 2009
Subject: Panic in RELENG_7_1 with fxp(4)
Message-ID: <49600E2E.7070601@avioc.org>

After running 7-PRERELEASE from around November 25th, I upgraded today 
to find the system panics repeatably on RELENG_7_1 sources.  I can boot 
back to the old kernel and it operates as expected.  It seems to be 
related to fxp(4).

FreeBSD didy.internal 7.1-RELEASE FreeBSD 7.1-RELEASE #0: Sat Jan  3
18:11:18 CST 2009     bweisz@didy.internal:/usr/obj/usr/src/sys/DIDY  i386

(19:00:35 bweisz@didy </usr/obj/usr/src/sys/DIDY>) 507 $ sudo kgdb 
kernel.debug /var/crash/vmcore.2
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	= 0x40c
fault code		= supervisor read, page not present
instruction pointer	= 0x20:0xc0a94510
stack pointer	        = 0x28:0xe677b878
frame pointer	        = 0x28:0xe677b88c
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		= 843 (ntpd)
trap number		= 12
panic: page fault
cpuid = 0
Uptime: 25s
Physical memory: 995 MB
Dumping 94 MB: 79 63 47 31 15

Reading symbols from /boot/kernel/vesa.ko...Reading symbols from 
/boot/kernel/vesa.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/vesa.ko
Reading symbols from /boot/kernel/accf_http.ko...Reading symbols from 
/boot/kernel/accf_http.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/accf_http.ko
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/pflog.ko...Reading symbols from 
/boot/kernel/pflog.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/pflog.ko
Reading symbols from /boot/kernel/pf.ko...Reading symbols from 
/boot/kernel/pf.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/pf.ko
Reading symbols from /boot/kernel/nullfs.ko...Reading symbols from 
/boot/kernel/nullfs.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/nullfs.ko
Reading symbols from /boot/kernel/logo_saver.ko...Reading symbols from 
/boot/kernel/logo_saver.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/logo_saver.ko
#0  doadump () at pcpu.h:196
196		__asm __volatile("movl %%fs:0,%0" : "=r" (td));
(kgdb) list *0xc0a94510
0xc0a94510 is in _bus_dmamap_sync 
(/usr/src/sys/i386/i386/busdma_machdep.c:935).
930			CTR4(KTR_BUSDMA, "%s: tag %p tag flags 0x%x op 0x%x "
931			    "performing bounce", __func__, op, dmat, dmat->flags);
932	
933			if (op & BUS_DMASYNC_PREWRITE) {
934				while (bpage != NULL) {
935					bcopy((void *)bpage->datavaddr,
936					      (void *)bpage->vaddr,
937					      bpage->datacount);
938					bpage = STAILQ_NEXT(bpage, links);
939				}
(kgdb) bt
#0  doadump () at pcpu.h:196
#1  0xc079c1b7 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418
#2  0xc079c489 in panic (fmt=Variable "fmt" is not available.
) at /usr/src/sys/kern/kern_shutdown.c:574
#3  0xc0ab03bc in trap_fatal (frame=0xe677b838, eva=1036) at 
/usr/src/sys/i386/i386/trap.c:939
#4  0xc0ab0640 in trap_pfault (frame=0xe677b838, usermode=0, eva=1036) 
at /usr/src/sys/i386/i386/trap.c:852
#5  0xc0ab0ffc in trap (frame=0xe677b838) at 
/usr/src/sys/i386/i386/trap.c:530
#6  0xc0a96e6b in calltrap () at /usr/src/sys/i386/i386/exception.s:159
#7  0xc0a94510 in _bus_dmamap_sync (dmat=0xc4048880, map=0xc416e800, 
op=4) at /usr/src/sys/i386/i386/busdma_machdep.c:933
#8  0xc05cc3cd in fxp_start_body (ifp=0xc4163000) at 
/usr/src/sys/dev/fxp/if_fxp.c:1396
#9  0xc05ccc77 in fxp_start (ifp=0xc4163000) at 
/usr/src/sys/dev/fxp/if_fxp.c:1183
#10 0xc0830a89 in if_start (ifp=0xc4163000) at /usr/src/sys/net/if.c:2768
#11 0xc08374cb in ether_output_frame (ifp=0xc4163000, m=0xc43a5600) at 
/usr/src/sys/net/if_ethersubr.c:405
#12 0xc0837a7c in ether_output (ifp=0xc4163000, m=0xc43a5600, 
dst=0xc423b710, rt0=0xc4489364) at /usr/src/sys/net/if_ethersubr.c:374
#13 0xc087e115 in ip_output (m=0xc43a5600, opt=0x0, ro=0xe677bac4, 
flags=Variable "flags" is not available.
) at /usr/src/sys/netinet/ip_output.c:554
#14 0xc08eb9b9 in udp_send (so=0xc46ef9c0, flags=0, m=0xc43a5600, 
addr=0xc4462ab0, control=0x0, td=0xc421f230) at 
/usr/src/sys/netinet/udp_usrreq.c:1074
#15 0xc07f2546 in sosend_dgram (so=0xc46ef9c0, addr=0xc4462ab0, 
uio=0xe677bbe8, top=0xc43a5600, control=0x0, flags=Variable "flags" is 
not available.
) at /usr/src/sys/kern/uipc_socket.c:1059
#16 0xc07efbef in sosend (so=0xc46ef9c0, addr=0xc4462ab0, 
uio=0xe677bbe8, top=0x0, control=0x0, flags=0, td=0xc421f230) at 
/usr/src/sys/kern/uipc_socket.c:1288
#17 0xc07f6ef6 in kern_sendit (td=0xc421f230, s=23, mp=0xe677bc64, 
flags=0, control=0x0, segflg=UIO_USERSPACE) at 
/usr/src/sys/kern/uipc_syscalls.c:805
#18 0xc07fa141 in sendit (td=0xc421f230, s=23, mp=0xe677bc64, flags=0) 
at /usr/src/sys/kern/uipc_syscalls.c:742
#19 0xc07fa258 in sendto (td=0xc421f230, uap=0xe677bcfc) at 
/usr/src/sys/kern/uipc_syscalls.c:857
#20 0xc0ab0995 in syscall (frame=0xe677bd38) at 
/usr/src/sys/i386/i386/trap.c:1090
#21 0xc0a96ed0 in Xint0x80_syscall () at 
/usr/src/sys/i386/i386/exception.s:255
#22 0x00000033 in ?? ()
Previous frame inner to this frame (corrupt stack?)
(kgdb)


I replaced the fxp(4) card with an old xl(4) card lying on my desk and 
the panics stopped.  Is this a failing nic card or some other trigger?

Brandon
From andrew at modulus.org  Sun Jan  4 01:49:17 2009
From: andrew at modulus.org (Andrew Snow)
Date: Sun Jan  4 01:49:25 2009
Subject: slow zvol performance compared to files on the same pool
In-Reply-To: <E1LJHlS-000EO4-SB@dilbert.ticketswitch.com>
References: <E1LJHlS-000EO4-SB@dilbert.ticketswitch.com>
Message-ID: <496011CC.2010201@modulus.org>

Pete French wrote:
> I was experimenting with iscsi earlier, using both a flat file as the
> backing store and also a zvol. I noticed that the zvol was giving me
> dreadful performance - reading at about 20 meg/second and writing at
> about 12. the fklat file gives about 45 meg/second both ways.
> 
> i thouht it was to do wuth the iscsi layer, but I then tried it using
> dd on the machinbe itself and got the same results. it seems very
> curious - I am creating both the filesystem for the iscsi file and the
> zvol on the same pool, so the underlying discs (4 x 15k SCSI drives on
> U320) are the same in both places, as is the pool.
> 
> anybody got any opinions ? this is on 7.1-RC2, but I have nothing else
> to compare it to. 

On 7.x (where ZFS is really quite broken for server use - don't waste 
too much time on it) the ZVOL code did an "fsync" after every single 
block write.  Its a testament to your fast disks that you got as high as 
12mb/s.  I don't know why your read speed was so bad, but you should try 
again on 8-current as numerous fixes and improvements have happened.


- Andrew
From terry at tmk.com  Sun Jan  4 02:20:35 2009
From: terry at tmk.com (Terry Kennedy)
Date: Sun Jan  4 02:20:43 2009
Subject: rdump stuck in sbwait state (RELENG_7)
In-Reply-To: "Your message dated Tue, 30 Dec 2008 22:12:40 +1100"
	<20081230111240.GC87057@server.vk2pj.dyndns.org>
References: <01N3OFGBCXMS000125@tmk.com> <01N3OYSUCHAE000125@tmk.com>
Message-ID: <01N3VGDZ7EOM0008L3@tmk.com>

> Sorry, I can't think of any - by the time you see it hung, whatever
> went wrong has already happened.  You might glean some insight from
> the TCP socket state (on the FreeBSD side, use 'netstat -A' to print
> the PCB address and gdb to dump the contents but I'm not sure how to
> get this data out of OpenVMS).  The '-C' and '-W' options to tcpdump
> will help.

  Ok, I found some time to reproduce this while capturing a trace with
tcpdump.

  Here's the relevant output from netstat / kgdb:

(0:31) test4:~terry# netstat -A
Active Internet connections
Tcpcb    Proto Recv-Q Send-Q  Local Address      Foreign Address    (state)
c73eeae0 tcp4       0      0 test4.892          server.shell       ESTABLISHED
[snip]

(0:32) test4:~terry# kgdb
GNU gdb 6.1.1 [FreeBSD]
[snip]
#0  0x00000000 in ?? ()
(kgdb) print * (struct tcpcb *) 0xc73eeae0
$1 = {t_segq = {lh_first = 0x0}, t_segqlen = 0, t_dupacks = 0, 
  t_timers = 0xc73eec24, t_inpcb = 0xc7387708, t_state = 4, t_flags = 484, 
  snd_una = 292841209, snd_max = 292841209, snd_nxt = 292841209, 
  snd_up = 292780017, snd_wl1 = 3606352422, snd_wl2 = 292841209, 
  iss = 3955646224, irs = 3606284909, rcv_nxt = 3606352422, 
  rcv_adv = 3606415910, rcv_wnd = 63488, rcv_up = 3606352422, snd_wnd = 65535, 
  snd_cwnd = 65535, snd_bwnd = 1073725440, snd_ssthresh = 1073725440, 
  snd_bandwidth = 0, snd_recover = 3955646224, t_maxopd = 1460, 
  t_rcvtime = 11273919, t_starttime = 11024967, t_rtttime = 0, 
  t_rtseq = 292839154, t_bw_rtttime = 11024966, t_bw_rtseq = 3955646224, 
  t_rxtcur = 230, t_maxseg = 1448, t_srtt = 145, t_rttvar = 34, 
  t_rxtshift = 0, t_rttmin = 30, t_rttbest = 67, t_rttupdated = 232101, 
  max_sndwnd = 65535, t_softerror = 0, t_oobflags = 0 '\0', t_iobc = 0 '\0', 
  snd_scale = 0 '\0', rcv_scale = 3 '\003', request_r_scale = 3 '\003', 
  ts_recent = 1207233, ts_recent_age = 11273919, ts_offset = 0, 
  last_ack_sent = 3606352422, snd_cwnd_prev = 0, snd_ssthresh_prev = 0, 
  snd_recover_prev = 0, t_badrxtwin = 0, snd_limited = 0 '\0', 
  snd_numholes = 0, snd_holes = {tqh_first = 0x0, tqh_last = 0xc73eebb8}, 
  snd_fack = 0, rcv_numsacks = 0, sackblks = {{start = 0, end = 0}, {
      start = 0, end = 0}, {start = 0, end = 0}, {start = 0, end = 0}, {
      start = 0, end = 0}, {start = 0, end = 0}}, sack_newdata = 0, 
  sackhint = {nexthole = 0x0, sack_bytes_rexmit = 0}, t_rttlow = 1, 
  rfbuf_ts = 0, rfbuf_cnt = 0, t_pspare = {0x0, 0x0, 0x0}, t_tu = 0x0, 
  t_toe = 0x0}
(kgdb) q

  Rather than pasting the decoded tcpdump output here, the raw capture
file is at http://www.tmk.com/transient/rdump30.gz (it is only 76KB
compressed, 270KB uncompressed). It looks to me like the remote host
(the VMS box) has correctly ack'd all outstanding data from the FreeBSD
host, but that the FreeBSD host is just sitting there for some reason.

  As before, I have this sitting in the wedged state so if anyone needs
more data, I can either collect it or give you access to the system.

        Terry Kennedy             http://www.tmk.com
        terry@tmk.com             New York, NY USA
From ehrmann at gmail.com  Sun Jan  4 03:02:35 2009
From: ehrmann at gmail.com (David Ehrmann)
Date: Sun Jan  4 03:02:42 2009
Subject: slow zvol performance compared to files on the same pool
In-Reply-To: <496011CC.2010201@modulus.org>
References: <E1LJHlS-000EO4-SB@dilbert.ticketswitch.com>
	<496011CC.2010201@modulus.org>
Message-ID: <496026BE.3080107@gmail.com>

Andrew Snow wrote:
> On 7.x (where ZFS is really quite broken for server use - don't waste 
> too much time on it) 
How exactly is it broken?  I know there are some issues, but so serious 
you'd say it's broken?
From yanefbsd at gmail.com  Sun Jan  4 06:12:43 2009
From: yanefbsd at gmail.com (Garrett Cooper)
Date: Sun Jan  4 06:13:18 2009
Subject: Panic in RELENG_7_1 with fxp(4)
In-Reply-To: <49600E2E.7070601@avioc.org>
References: <49600E2E.7070601@avioc.org>
Message-ID: <3163F769-48B0-4CFC-8842-BBBDDAE78B51@gmail.com>

On Jan 3, 2009, at 5:17 PM, Brandon Weisz wrote:

> After running 7-PRERELEASE from around November 25th, I upgraded  
> today to find the system panics repeatably on RELENG_7_1 sources.  I  
> can boot back to the old kernel and it operates as expected.  It  
> seems to be related to fxp(4).
>
> FreeBSD didy.internal 7.1-RELEASE FreeBSD 7.1-RELEASE #0: Sat Jan  3
> 18:11:18 CST 2009     bweisz@didy.internal:/usr/obj/usr/src/sys/ 
> DIDY  i386
>
> (19:00:35 bweisz@didy </usr/obj/usr/src/sys/DIDY>) 507 $ sudo kgdb  
> kernel.debug /var/crash/vmcore.2
> 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	= 0x40c
> fault code		= supervisor read, page not present
> instruction pointer	= 0x20:0xc0a94510
> stack pointer	        = 0x28:0xe677b878
> frame pointer	        = 0x28:0xe677b88c
> 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		= 843 (ntpd)
> trap number		= 12
> panic: page fault
> cpuid = 0
> Uptime: 25s
> Physical memory: 995 MB
> Dumping 94 MB: 79 63 47 31 15
>
> Reading symbols from /boot/kernel/vesa.ko...Reading symbols from / 
> boot/kernel/vesa.ko.symbols...done.
> done.
> Loaded symbols for /boot/kernel/vesa.ko
> Reading symbols from /boot/kernel/accf_http.ko...Reading symbols  
> from /boot/kernel/accf_http.ko.symbols...done.
> done.
> Loaded symbols for /boot/kernel/accf_http.ko
> 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/pflog.ko...Reading symbols from / 
> boot/kernel/pflog.ko.symbols...done.
> done.
> Loaded symbols for /boot/kernel/pflog.ko
> Reading symbols from /boot/kernel/pf.ko...Reading symbols from /boot/ 
> kernel/pf.ko.symbols...done.
> done.
> Loaded symbols for /boot/kernel/pf.ko
> Reading symbols from /boot/kernel/nullfs.ko...Reading symbols from / 
> boot/kernel/nullfs.ko.symbols...done.
> done.
> Loaded symbols for /boot/kernel/nullfs.ko
> Reading symbols from /boot/kernel/logo_saver.ko...Reading symbols  
> from /boot/kernel/logo_saver.ko.symbols...done.
> done.
> Loaded symbols for /boot/kernel/logo_saver.ko
> #0  doadump () at pcpu.h:196
> 196		__asm __volatile("movl %%fs:0,%0" : "=r" (td));
> (kgdb) list *0xc0a94510
> 0xc0a94510 is in _bus_dmamap_sync (/usr/src/sys/i386/i386/ 
> busdma_machdep.c:935).
> 930			CTR4(KTR_BUSDMA, "%s: tag %p tag flags 0x%x op 0x%x "
> 931			    "performing bounce", __func__, op, dmat, dmat->flags);
> 932	
> 933			if (op & BUS_DMASYNC_PREWRITE) {
> 934				while (bpage != NULL) {
> 935					bcopy((void *)bpage->datavaddr,
> 936					      (void *)bpage->vaddr,
> 937					      bpage->datacount);
> 938					bpage = STAILQ_NEXT(bpage, links);
> 939				}
> (kgdb) bt
> #0  doadump () at pcpu.h:196
> #1  0xc079c1b7 in boot (howto=260) at /usr/src/sys/kern/ 
> kern_shutdown.c:418
> #2  0xc079c489 in panic (fmt=Variable "fmt" is not available.
> ) at /usr/src/sys/kern/kern_shutdown.c:574
> #3  0xc0ab03bc in trap_fatal (frame=0xe677b838, eva=1036) at /usr/ 
> src/sys/i386/i386/trap.c:939
> #4  0xc0ab0640 in trap_pfault (frame=0xe677b838, usermode=0,  
> eva=1036) at /usr/src/sys/i386/i386/trap.c:852
> #5  0xc0ab0ffc in trap (frame=0xe677b838) at /usr/src/sys/i386/i386/ 
> trap.c:530
> #6  0xc0a96e6b in calltrap () at /usr/src/sys/i386/i386/exception.s: 
> 159
> #7  0xc0a94510 in _bus_dmamap_sync (dmat=0xc4048880, map=0xc416e800,  
> op=4) at /usr/src/sys/i386/i386/busdma_machdep.c:933
> #8  0xc05cc3cd in fxp_start_body (ifp=0xc4163000) at /usr/src/sys/ 
> dev/fxp/if_fxp.c:1396
> #9  0xc05ccc77 in fxp_start (ifp=0xc4163000) at /usr/src/sys/dev/fxp/ 
> if_fxp.c:1183
> #10 0xc0830a89 in if_start (ifp=0xc4163000) at /usr/src/sys/net/if.c: 
> 2768
> #11 0xc08374cb in ether_output_frame (ifp=0xc4163000, m=0xc43a5600)  
> at /usr/src/sys/net/if_ethersubr.c:405
> #12 0xc0837a7c in ether_output (ifp=0xc4163000, m=0xc43a5600,  
> dst=0xc423b710, rt0=0xc4489364) at /usr/src/sys/net/if_ethersubr.c:374
> #13 0xc087e115 in ip_output (m=0xc43a5600, opt=0x0, ro=0xe677bac4,  
> flags=Variable "flags" is not available.
> ) at /usr/src/sys/netinet/ip_output.c:554
> #14 0xc08eb9b9 in udp_send (so=0xc46ef9c0, flags=0, m=0xc43a5600,  
> addr=0xc4462ab0, control=0x0, td=0xc421f230) at /usr/src/sys/netinet/ 
> udp_usrreq.c:1074
> #15 0xc07f2546 in sosend_dgram (so=0xc46ef9c0, addr=0xc4462ab0,  
> uio=0xe677bbe8, top=0xc43a5600, control=0x0, flags=Variable "flags"  
> is not available.
> ) at /usr/src/sys/kern/uipc_socket.c:1059
> #16 0xc07efbef in sosend (so=0xc46ef9c0, addr=0xc4462ab0,  
> uio=0xe677bbe8, top=0x0, control=0x0, flags=0, td=0xc421f230) at / 
> usr/src/sys/kern/uipc_socket.c:1288
> #17 0xc07f6ef6 in kern_sendit (td=0xc421f230, s=23, mp=0xe677bc64,  
> flags=0, control=0x0, segflg=UIO_USERSPACE) at /usr/src/sys/kern/ 
> uipc_syscalls.c:805
> #18 0xc07fa141 in sendit (td=0xc421f230, s=23, mp=0xe677bc64,  
> flags=0) at /usr/src/sys/kern/uipc_syscalls.c:742
> #19 0xc07fa258 in sendto (td=0xc421f230, uap=0xe677bcfc) at /usr/src/ 
> sys/kern/uipc_syscalls.c:857
> #20 0xc0ab0995 in syscall (frame=0xe677bd38) at /usr/src/sys/i386/ 
> i386/trap.c:1090
> #21 0xc0a96ed0 in Xint0x80_syscall () at /usr/src/sys/i386/i386/ 
> exception.s:255
> #22 0x00000033 in ?? ()
> Previous frame inner to this frame (corrupt stack?)
> (kgdb)
>
>
> I replaced the fxp(4) card with an old xl(4) card lying on my desk  
> and the panics stopped.  Is this a failing nic card or some other  
> trigger?
>
> Brandon

Memory serves me correctly an MFC was done not too long before 7.1  
release was setup.

Let's see what Pyun says...

-Garrett
From fjwcash at gmail.com  Sun Jan  4 08:33:30 2009
From: fjwcash at gmail.com (Freddie Cash)
Date: Sun Jan  4 08:33:36 2009
Subject: slow zvol performance compared to files on the same pool
In-Reply-To: <496026BE.3080107@gmail.com>
References: <E1LJHlS-000EO4-SB@dilbert.ticketswitch.com>
	<496011CC.2010201@modulus.org> <496026BE.3080107@gmail.com>
Message-ID: <b269bc570901040009j6fc9585i5fa609943a3c99c1@mail.gmail.com>

On Sat, Jan 3, 2009 at 7:02 PM, David Ehrmann <ehrmann@gmail.com> wrote:
> Andrew Snow wrote:
>>
>> On 7.x (where ZFS is really quite broken for server use - don't waste too
>> much time on it)
>
> How exactly is it broken?  I know there are some issues, but so serious
> you'd say it's broken?

It's not "broken" on 7.1, it just requires manual tuning and
monitoring.  Preferably, it should only be run on amd64 systems with
lots of RAM, but it can be run on i386 systems with at least 2 GB of
RAM (some people have it running on 32-bit systems with less RAM).

ZFS in 8-CURRENT is a more recent version (v13 I believe, while 7.1 is
v6), and has a bunch of auto-tuning features, along with a much higher
kmem_size_max setting (512 GB vs 2 GB I believe).

-- 
Freddie Cash
fjwcash@gmail.com
From mattias.bjork at sydnet.net  Sun Jan  4 10:40:43 2009
From: mattias.bjork at sydnet.net (=?ISO-8859-1?Q?Mattias_Bj=F6rk?=)
Date: Sun Jan  4 10:40:51 2009
Subject: Make world builderror on 7.1-BETA2 with latest cvsup
In-Reply-To: <7d6fde3d0901030249g6535a3bbsceae3a8949a0a536@mail.gmail.com>
References: <495D88B9.6060408@sydnet.net>	
	<2D7731A8-9AAC-4F8C-B3A0-01DFBC84E407@gmail.com>	
	<495E706E.40904@sydnet.net>
	<7d6fde3d0901030249g6535a3bbsceae3a8949a0a536@mail.gmail.com>
Message-ID: <496091E0.1070908@sydnet.net>

Hello again,


Garrett Cooper wrote:
> On Fri, Jan 2, 2009 at 11:52 AM, Mattias Bj?rk <mattias.bjork@sydnet.net> wrote:
>> Hello Garrett,
>>
>>
>> Sorry for top posting, but here is the attachment of the log.
>>
>>
>> Garrett Cooper wrote:
>>> On Jan 1, 2009, at 19:23, Mattias Bj?rk <mattias.bjork@sydnet.net> wrote:
>>>
>>>> Hello everybody,
>>>>
>>>> First of all, my bad if this get sent two times.
>>>>
>>>> I have a compile error/problem when building world.
>>>>
>>>> My uname -a output is:
>>>>
>>>> FreeBSD barabolaptop 7.1-BETA2 FreeBSD 7.1-BETA2 #0: Thu Dec  4 20:52:35
>>>> CET 2008     root@barabolaptop:/usr/obj/usr/src/sys/BARABOLAPTOP  i386
>>>>
>>>> My make.conf looks like:
>>>>
>>>> # added by use.perl 2008-12-03 00:58:09
>>>> PERL_VER=5.8.8
>>>> PERL_VERSION=5.8.8
>>>> WRKDIRPREFIX=/var/tmp
>>>>
>>>>
>>>> The options.h file in /usr/obj/usr/src/gnu/usr.bin/cc/cc_tools/options.h
>>>>
>>>> Here are the output of options.h from pastebin:
>>>>
>>>> http://pastebin.com/m254dfedf
>>>>
>>>>
>>>> When I run "make -j1 buildworld" i get the error is as following:
>>>>
>>>> http://pastebin.com/m57738677
>>>>
>>>> I don't know much of programming (if any), but I have tried to change
>>>> things in (remove OPT_w from both places) options.h and runned
>>>> "make -j1 -DNOCLEAN buildworld"
>>>>
>>>> But that have not solve anything of this, perhaps some can shine some
>>>> light on this or have I missed something trivial?
>>>> I can build ports and so on without any problems.
>>>>
>>>> Thank you.
>>> Not enough data. Please send a full compressed version of the log to me.
>>> Thanks!
>>> -Garrett
> 
> That's really odd why the symbol was redefined. Here're the relevant
> sections of the log:
> 
> c_tools/../../../../contrib/gcc/gencheck.c
> In file included from ./tm.h:4,
>                 from
> /usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/gencheck.c:25:
> ./options.h:901: error: redeclaration of enumerator 'OPT_w'
> ./options.h:899: error: previous definition of 'OPT_w' was here
> *** Error code 1
> 1 error
> *** Error code 2
> 1 error
> *** Error code 2
> 1 error
> *** Error code 2
> 
> 	Looking back, I'm not sure why OPT_w is printed into the file twice.
> I wonder if you met a rare race condition where options.sh printed out
> that line twice; then again that's unlikely, given the
> reproducibility... I could be wrong however.
> 	Is your source tree based off of RELENG_7 and what cvsup server is it
> synced against?
> -Garrett


I'm using cvsup.se.freebsd.org, cvsup.dk.freebsd.org, 
cvsup.no.freebsd.org I have tried to remove /usr/src/* right now and 
downloaded it again but it did not help after the build.

So I have no idea what to do from here.

But I guess It would be solved sometime in the future.

Thanks so far :)
From petefrench at ticketswitch.com  Sun Jan  4 12:40:31 2009
From: petefrench at ticketswitch.com (Pete French)
Date: Sun Jan  4 12:40:38 2009
Subject: slow zvol performance compared to files on the same pool
In-Reply-To: <496011CC.2010201@modulus.org>
Message-ID: <E1LJSHJ-000Gfj-UE@dilbert.ticketswitch.com>

> On 7.x (where ZFS is really quite broken for server use - don't waste 
> too much time on it) the ZVOL code did an "fsync" after every single 
> block write.  Its a testament to your fast disks that you got as high as 
> 12mb/s.  I don't know why your read speed was so bad, but you should try 
> again on 8-current as numerous fixes and improvements have happened.

Ah, thatnks. That explains it perfectly. I'll re-do the read test and
also give 8-CURRENT a try if I get the time. Thanks.

-pete.
From gavroche at gavroche.pl  Sun Jan  4 14:25:12 2009
From: gavroche at gavroche.pl (Dominik =?iso-8859-2?Q?=AFy=B3a?=)
Date: Sun Jan  4 14:25:19 2009
Subject: Make world builderror on 7.1-BETA2 with latest cvsup
In-Reply-To: <496091E0.1070908@sydnet.net>
References: <495D88B9.6060408@sydnet.net>
	<2D7731A8-9AAC-4F8C-B3A0-01DFBC84E407@gmail.com>
	<495E706E.40904@sydnet.net>
	<7d6fde3d0901030249g6535a3bbsceae3a8949a0a536@mail.gmail.com>
	<496091E0.1070908@sydnet.net>
Message-ID: <20090104140905.GA40108@mail.mercom.pl>

On Sun, Jan 04, 2009 at 11:39:28AM +0100, Mattias Bj?rk wrote:
> Hello again,
> 
> 
> Garrett Cooper wrote:
> > On Fri, Jan 2, 2009 at 11:52 AM, Mattias Bj?rk <mattias.bjork@sydnet.net> wrote:
> >> Hello Garrett,
> >>
> >>
> >> Sorry for top posting, but here is the attachment of the log.
> >>
> >>
> >> Garrett Cooper wrote:
> >>> On Jan 1, 2009, at 19:23, Mattias Bj?rk <mattias.bjork@sydnet.net> wrote:
> >>>
> >>>> Hello everybody,
> >>>>
> >>>> First of all, my bad if this get sent two times.
> >>>>
> >>>> I have a compile error/problem when building world.
> >>>>
> >>>> My uname -a output is:
> >>>>
> >>>> FreeBSD barabolaptop 7.1-BETA2 FreeBSD 7.1-BETA2 #0: Thu Dec  4 20:52:35
> >>>> CET 2008     root@barabolaptop:/usr/obj/usr/src/sys/BARABOLAPTOP  i386
> >>>>
> >>>> My make.conf looks like:
> >>>>
> >>>> # added by use.perl 2008-12-03 00:58:09
> >>>> PERL_VER=5.8.8
> >>>> PERL_VERSION=5.8.8
> >>>> WRKDIRPREFIX=/var/tmp
> >>>>
> >>>>
> >>>> The options.h file in /usr/obj/usr/src/gnu/usr.bin/cc/cc_tools/options.h
> >>>>
> >>>> Here are the output of options.h from pastebin:
> >>>>
> >>>> http://pastebin.com/m254dfedf
> >>>>
> >>>>
> >>>> When I run "make -j1 buildworld" i get the error is as following:
> >>>>
> >>>> http://pastebin.com/m57738677
> >>>>
> >>>> I don't know much of programming (if any), but I have tried to change
> >>>> things in (remove OPT_w from both places) options.h and runned
> >>>> "make -j1 -DNOCLEAN buildworld"
> >>>>
> >>>> But that have not solve anything of this, perhaps some can shine some
> >>>> light on this or have I missed something trivial?
> >>>> I can build ports and so on without any problems.
> >>>>
> >>>> Thank you.
> >>> Not enough data. Please send a full compressed version of the log to me.
> >>> Thanks!
> >>> -Garrett
> > 
> > That's really odd why the symbol was redefined. Here're the relevant
> > sections of the log:
> > 
> > c_tools/../../../../contrib/gcc/gencheck.c
> > In file included from ./tm.h:4,
> >                 from
> > /usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/gencheck.c:25:
> > ./options.h:901: error: redeclaration of enumerator 'OPT_w'
> > ./options.h:899: error: previous definition of 'OPT_w' was here
> > *** Error code 1
> > 1 error
> > *** Error code 2
> > 1 error
> > *** Error code 2
> > 1 error
> > *** Error code 2
> > 
> > 	Looking back, I'm not sure why OPT_w is printed into the file twice.
> > I wonder if you met a rare race condition where options.sh printed out
> > that line twice; then again that's unlikely, given the
> > reproducibility... I could be wrong however.
> > 	Is your source tree based off of RELENG_7 and what cvsup server is it
> > synced against?
> > -Garrett
> 
> 
> I'm using cvsup.se.freebsd.org, cvsup.dk.freebsd.org, 
> cvsup.no.freebsd.org I have tried to remove /usr/src/* right now and 
> downloaded it again but it did not help after the build.
> 
> So I have no idea what to do from here.
> 
> But I guess It would be solved sometime in the future.

Did you clean your /usr/obj/ directory?

-- 
Dominik ?y?a

	If you want a picture of the future, imagine a boot stamping on a human face - for ever..
From hawei at free.fr  Sun Jan  4 22:34:45 2009
From: hawei at free.fr (Harald Weis)
Date: Sun Jan  4 22:34:53 2009
Subject: Samsung SCX-4200 printer
Message-ID: <20090104221422.GA3114@pollux2.free.local.net>

Is there a way to install the SCX-4200 printer on a FreeBSD box ?
The printer is delivered with the install software required for Linux.
And CUPS does not seem to "know" it.

Thank you in advance for any help.

Harald Weis
-- 
FreeBSD 7.0-RELEASE #0: Sun Feb 24 19:59:52 UTC 2008
From mattias.bjork at sydnet.net  Mon Jan  5 02:26:31 2009
From: mattias.bjork at sydnet.net (=?ISO-8859-2?Q?Mattias_Bj=F6rk?=)
Date: Mon Jan  5 02:26:39 2009
Subject: Make world builderror on 7.1-BETA2 with latest cvsup
In-Reply-To: <20090104140905.GA40108@mail.mercom.pl>
References: <495D88B9.6060408@sydnet.net>
	<2D7731A8-9AAC-4F8C-B3A0-01DFBC84E407@gmail.com>
	<495E706E.40904@sydnet.net>
	<7d6fde3d0901030249g6535a3bbsceae3a8949a0a536@mail.gmail.com>
	<496091E0.1070908@sydnet.net>
	<20090104140905.GA40108@mail.mercom.pl>
Message-ID: <49616F89.4060500@sydnet.net>

Dominik ?y?a wrote:
> On Sun, Jan 04, 2009 at 11:39:28AM +0100, Mattias Bj?rk wrote:
>> Hello again,
>>
>>
>> Garrett Cooper wrote:
>>> On Fri, Jan 2, 2009 at 11:52 AM, Mattias Bj?rk <mattias.bjork@sydnet.net> wrote:
>>>> Hello Garrett,
>>>>
>>>>
>>>> Sorry for top posting, but here is the attachment of the log.
>>>>
>>>>
>>>> Garrett Cooper wrote:
>>>>> On Jan 1, 2009, at 19:23, Mattias Bj?rk <mattias.bjork@sydnet.net> wrote:
>>>>>
>>>>>> Hello everybody,
>>>>>>
>>>>>> First of all, my bad if this get sent two times.
>>>>>>
>>>>>> I have a compile error/problem when building world.
>>>>>>
>>>>>> My uname -a output is:
>>>>>>
>>>>>> FreeBSD barabolaptop 7.1-BETA2 FreeBSD 7.1-BETA2 #0: Thu Dec  4 20:52:35
>>>>>> CET 2008     root@barabolaptop:/usr/obj/usr/src/sys/BARABOLAPTOP  i386
>>>>>>
>>>>>> My make.conf looks like:
>>>>>>
>>>>>> # added by use.perl 2008-12-03 00:58:09
>>>>>> PERL_VER=5.8.8
>>>>>> PERL_VERSION=5.8.8
>>>>>> WRKDIRPREFIX=/var/tmp
>>>>>>
>>>>>>
>>>>>> The options.h file in /usr/obj/usr/src/gnu/usr.bin/cc/cc_tools/options.h
>>>>>>
>>>>>> Here are the output of options.h from pastebin:
>>>>>>
>>>>>> http://pastebin.com/m254dfedf
>>>>>>
>>>>>>
>>>>>> When I run "make -j1 buildworld" i get the error is as following:
>>>>>>
>>>>>> http://pastebin.com/m57738677
>>>>>>
>>>>>> I don't know much of programming (if any), but I have tried to change
>>>>>> things in (remove OPT_w from both places) options.h and runned
>>>>>> "make -j1 -DNOCLEAN buildworld"
>>>>>>
>>>>>> But that have not solve anything of this, perhaps some can shine some
>>>>>> light on this or have I missed something trivial?
>>>>>> I can build ports and so on without any problems.
>>>>>>
>>>>>> Thank you.
>>>>> Not enough data. Please send a full compressed version of the log to me.
>>>>> Thanks!
>>>>> -Garrett
>>> That's really odd why the symbol was redefined. Here're the relevant
>>> sections of the log:
>>>
>>> c_tools/../../../../contrib/gcc/gencheck.c
>>> In file included from ./tm.h:4,
>>>                 from
>>> /usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/gencheck.c:25:
>>> ./options.h:901: error: redeclaration of enumerator 'OPT_w'
>>> ./options.h:899: error: previous definition of 'OPT_w' was here
>>> *** Error code 1
>>> 1 error
>>> *** Error code 2
>>> 1 error
>>> *** Error code 2
>>> 1 error
>>> *** Error code 2
>>>
>>> 	Looking back, I'm not sure why OPT_w is printed into the file twice.
>>> I wonder if you met a rare race condition where options.sh printed out
>>> that line twice; then again that's unlikely, given the
>>> reproducibility... I could be wrong however.
>>> 	Is your source tree based off of RELENG_7 and what cvsup server is it
>>> synced against?
>>> -Garrett
>>
>> I'm using cvsup.se.freebsd.org, cvsup.dk.freebsd.org, 
>> cvsup.no.freebsd.org I have tried to remove /usr/src/* right now and 
>> downloaded it again but it did not help after the build.
>>
>> So I have no idea what to do from here.
>>
>> But I guess It would be solved sometime in the future.
> 
> Did you clean your /usr/obj/ directory?
> 

Yes I have also done that, still no luck there.

Thanks anyway.
From pyunyh at gmail.com  Mon Jan  5 03:27:07 2009
From: pyunyh at gmail.com (Pyun YongHyeon)
Date: Mon Jan  5 03:27:17 2009
Subject: Panic in RELENG_7_1 with fxp(4)
In-Reply-To: <3163F769-48B0-4CFC-8842-BBBDDAE78B51@gmail.com>
References: <49600E2E.7070601@avioc.org>
	<3163F769-48B0-4CFC-8842-BBBDDAE78B51@gmail.com>
Message-ID: <20090105032657.GA1842@cdnetworks.co.kr>

On Sat, Jan 03, 2009 at 10:16:58PM -0800, Garrett Cooper wrote:
 > On Jan 3, 2009, at 5:17 PM, Brandon Weisz wrote:
 > 
 > >After running 7-PRERELEASE from around November 25th, I upgraded  
 > >today to find the system panics repeatably on RELENG_7_1 sources.  I  
 > >can boot back to the old kernel and it operates as expected.  It  
 > >seems to be related to fxp(4).
 > >
 > >FreeBSD didy.internal 7.1-RELEASE FreeBSD 7.1-RELEASE #0: Sat Jan  3
 > >18:11:18 CST 2009     bweisz@didy.internal:/usr/obj/usr/src/sys/ 
 > >DIDY  i386
 > >
 > >(19:00:35 bweisz@didy </usr/obj/usr/src/sys/DIDY>) 507 $ sudo kgdb  
 > >kernel.debug /var/crash/vmcore.2
 > >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	= 0x40c
 > >fault code		= supervisor read, page not present
 > >instruction pointer	= 0x20:0xc0a94510
 > >stack pointer	        = 0x28:0xe677b878
 > >frame pointer	        = 0x28:0xe677b88c
 > >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		= 843 (ntpd)
 > >trap number		= 12
 > >panic: page fault
 > >cpuid = 0
 > >Uptime: 25s
 > >Physical memory: 995 MB
 > >Dumping 94 MB: 79 63 47 31 15
 > >
 > >Reading symbols from /boot/kernel/vesa.ko...Reading symbols from / 
 > >boot/kernel/vesa.ko.symbols...done.
 > >done.
 > >Loaded symbols for /boot/kernel/vesa.ko
 > >Reading symbols from /boot/kernel/accf_http.ko...Reading symbols  
 > >from /boot/kernel/accf_http.ko.symbols...done.
 > >done.
 > >Loaded symbols for /boot/kernel/accf_http.ko
 > >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/pflog.ko...Reading symbols from / 
 > >boot/kernel/pflog.ko.symbols...done.
 > >done.
 > >Loaded symbols for /boot/kernel/pflog.ko
 > >Reading symbols from /boot/kernel/pf.ko...Reading symbols from /boot/ 
 > >kernel/pf.ko.symbols...done.
 > >done.
 > >Loaded symbols for /boot/kernel/pf.ko
 > >Reading symbols from /boot/kernel/nullfs.ko...Reading symbols from / 
 > >boot/kernel/nullfs.ko.symbols...done.
 > >done.
 > >Loaded symbols for /boot/kernel/nullfs.ko
 > >Reading symbols from /boot/kernel/logo_saver.ko...Reading symbols  
 > >from /boot/kernel/logo_saver.ko.symbols...done.
 > >done.
 > >Loaded symbols for /boot/kernel/logo_saver.ko
 > >#0  doadump () at pcpu.h:196
 > >196		__asm __volatile("movl %%fs:0,%0" : "=r" (td));
 > >(kgdb) list *0xc0a94510
 > >0xc0a94510 is in _bus_dmamap_sync (/usr/src/sys/i386/i386/ 
 > >busdma_machdep.c:935).
 > >930			CTR4(KTR_BUSDMA, "%s: tag %p tag flags 0x%x op 0x%x "
 > >931			    "performing bounce", __func__, op, dmat, 
 > >dmat->flags);
 > >932	
 > >933			if (op & BUS_DMASYNC_PREWRITE) {
 > >934				while (bpage != NULL) {
 > >935					bcopy((void *)bpage->datavaddr,
 > >936					      (void *)bpage->vaddr,
 > >937					      bpage->datacount);
 > >938					bpage = STAILQ_NEXT(bpage, links);
 > >939				}
 > >(kgdb) bt
 > >#0  doadump () at pcpu.h:196
 > >#1  0xc079c1b7 in boot (howto=260) at /usr/src/sys/kern/ 
 > >kern_shutdown.c:418
 > >#2  0xc079c489 in panic (fmt=Variable "fmt" is not available.
 > >) at /usr/src/sys/kern/kern_shutdown.c:574
 > >#3  0xc0ab03bc in trap_fatal (frame=0xe677b838, eva=1036) at /usr/ 
 > >src/sys/i386/i386/trap.c:939
 > >#4  0xc0ab0640 in trap_pfault (frame=0xe677b838, usermode=0,  
 > >eva=1036) at /usr/src/sys/i386/i386/trap.c:852
 > >#5  0xc0ab0ffc in trap (frame=0xe677b838) at /usr/src/sys/i386/i386/ 
 > >trap.c:530
 > >#6  0xc0a96e6b in calltrap () at /usr/src/sys/i386/i386/exception.s: 
 > >159
 > >#7  0xc0a94510 in _bus_dmamap_sync (dmat=0xc4048880, map=0xc416e800,  
 > >op=4) at /usr/src/sys/i386/i386/busdma_machdep.c:933
 > >#8  0xc05cc3cd in fxp_start_body (ifp=0xc4163000) at /usr/src/sys/ 
 > >dev/fxp/if_fxp.c:1396
 > >#9  0xc05ccc77 in fxp_start (ifp=0xc4163000) at /usr/src/sys/dev/fxp/ 
 > >if_fxp.c:1183
 > >#10 0xc0830a89 in if_start (ifp=0xc4163000) at /usr/src/sys/net/if.c: 
 > >2768
 > >#11 0xc08374cb in ether_output_frame (ifp=0xc4163000, m=0xc43a5600)  
 > >at /usr/src/sys/net/if_ethersubr.c:405
 > >#12 0xc0837a7c in ether_output (ifp=0xc4163000, m=0xc43a5600,  
 > >dst=0xc423b710, rt0=0xc4489364) at /usr/src/sys/net/if_ethersubr.c:374
 > >#13 0xc087e115 in ip_output (m=0xc43a5600, opt=0x0, ro=0xe677bac4,  
 > >flags=Variable "flags" is not available.
 > >) at /usr/src/sys/netinet/ip_output.c:554
 > >#14 0xc08eb9b9 in udp_send (so=0xc46ef9c0, flags=0, m=0xc43a5600,  
 > >addr=0xc4462ab0, control=0x0, td=0xc421f230) at /usr/src/sys/netinet/ 
 > >udp_usrreq.c:1074
 > >#15 0xc07f2546 in sosend_dgram (so=0xc46ef9c0, addr=0xc4462ab0,  
 > >uio=0xe677bbe8, top=0xc43a5600, control=0x0, flags=Variable "flags"  
 > >is not available.
 > >) at /usr/src/sys/kern/uipc_socket.c:1059
 > >#16 0xc07efbef in sosend (so=0xc46ef9c0, addr=0xc4462ab0,  
 > >uio=0xe677bbe8, top=0x0, control=0x0, flags=0, td=0xc421f230) at / 
 > >usr/src/sys/kern/uipc_socket.c:1288
 > >#17 0xc07f6ef6 in kern_sendit (td=0xc421f230, s=23, mp=0xe677bc64,  
 > >flags=0, control=0x0, segflg=UIO_USERSPACE) at /usr/src/sys/kern/ 
 > >uipc_syscalls.c:805
 > >#18 0xc07fa141 in sendit (td=0xc421f230, s=23, mp=0xe677bc64,  
 > >flags=0) at /usr/src/sys/kern/uipc_syscalls.c:742
 > >#19 0xc07fa258 in sendto (td=0xc421f230, uap=0xe677bcfc) at /usr/src/ 
 > >sys/kern/uipc_syscalls.c:857
 > >#20 0xc0ab0995 in syscall (frame=0xe677bd38) at /usr/src/sys/i386/ 
 > >i386/trap.c:1090
 > >#21 0xc0a96ed0 in Xint0x80_syscall () at /usr/src/sys/i386/i386/ 
 > >exception.s:255
 > >#22 0x00000033 in ?? ()
 > >Previous frame inner to this frame (corrupt stack?)
 > >(kgdb)
 > >
 > >
 > >I replaced the fxp(4) card with an old xl(4) card lying on my desk  
 > >and the panics stopped.  Is this a failing nic card or some other  
 > >trigger?
 > >
 > >Brandon
 > 
 > Memory serves me correctly an MFC was done not too long before 7.1  
 > release was setup.
 > 

I don't know what MFCes were done, at least I didn't MFC any
changes I made.

 > Let's see what Pyun says...
 > 

I'm not sure what is root cause of this panic. If you can reliably
reproduce the panic would you let me know?
CURRENT has a couple of fixes for edge-cases as well as some new
hardware features(TSO, VLAN hardware tagging and WOL etc). Would
you try latest fxp(4) in HEAD?
I think you can use cvsweb interface to get latest files.
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/fxp/if_fxp.c
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/fxp/if_fxpreg.h
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/fxp/if_fxpvar.h

-- 
Regards,
Pyun YongHyeon
From jonc at chen.org.nz  Mon Jan  5 03:35:49 2009
From: jonc at chen.org.nz (Jonathan Chen)
Date: Mon Jan  5 03:35:57 2009
Subject: X11 on Dell D830 with latest 7.1-PRERELEASE
Message-ID: <20090105031744.GA74033@osiris.chen.org.nz>

Hi,

I've got a Dell Latitude D830 running 7.1-PRERELEASE/amd64 which I've
just csup'd to the -STABLE as of 5-Jan-2009, and after going thru' the
std build+install; XOrg now comes up with a blank screen, sometimes
interspersed with green dots. I did test out X prior to doing an
installworld, and that came up with no problems. However, after doing
an installworld, X is now broken.

Prior to this update, the D830 was running -STABLE from Nov-2008;
which appeared to work fine. All ports are up to date.

I'd appreciate any help in resolving this problem.

Cheers.
-- 
Jonathan Chen <jonc@chen.org.nz>
----------------------------------------------------------------------
                        "Irrationality is the square root of all evil"
                                                  - Douglas Hofstadter
From kensmith at cse.Buffalo.EDU  Mon Jan  5 04:44:51 2009
From: kensmith at cse.Buffalo.EDU (Ken Smith)
Date: Mon Jan  5 04:44:58 2009
Subject: FreeBSD 7.1-RELEASE Available...
Message-ID: <1231130677.13757.12.camel@neo.cse.buffalo.edu>


Just a quick note for those of you not subscribed to freebsd-announce@.
FreeBSD 7.1 is (finally...) released.  The announcement is here:

  http://www.freebsd.org/releases/7.1R/announce.html

Sorry for the delays and thanks for your continued interest in and
support of FreeBSD.

-- 
                                                Ken Smith
- From there to here, from here to      |       kensmith@cse.buffalo.edu
  there, funny things are everywhere.   |
                      - Theodore Geisel |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090105/bbb4e52d/attachment.pgp
From yanefbsd at gmail.com  Mon Jan  5 05:30:00 2009
From: yanefbsd at gmail.com (Garrett Cooper)
Date: Mon Jan  5 05:30:07 2009
Subject: X11 on Dell D830 with latest 7.1-PRERELEASE
In-Reply-To: <20090105031744.GA74033@osiris.chen.org.nz>
References: <20090105031744.GA74033@osiris.chen.org.nz>
Message-ID: <7d6fde3d0901042129i4dd2dagf06dcca7c6b7681b@mail.gmail.com>

On Sun, Jan 4, 2009 at 7:17 PM, Jonathan Chen <jonc@chen.org.nz> wrote:
> Hi,
>
> I've got a Dell Latitude D830 running 7.1-PRERELEASE/amd64 which I've
> just csup'd to the -STABLE as of 5-Jan-2009, and after going thru' the
> std build+install; XOrg now comes up with a blank screen, sometimes
> interspersed with green dots. I did test out X prior to doing an
> installworld, and that came up with no problems. However, after doing
> an installworld, X is now broken.
>
> Prior to this update, the D830 was running -STABLE from Nov-2008;
> which appeared to work fine. All ports are up to date.
>
> I'd appreciate any help in resolving this problem.
>
> Cheers.
> --
> Jonathan Chen <jonc@chen.org.nz>

Jonathan,
    What video card driver are you using and have you recompiled the driver?
Thanks,
-Garrett
From pyunyh at gmail.com  Mon Jan  5 07:48:49 2009
From: pyunyh at gmail.com (Pyun YongHyeon)
Date: Mon Jan  5 07:48:56 2009
Subject: Lock enabling onboard lan (Attansic L1 GbE) on 7.1-PRERELEASE
In-Reply-To: <4547243.744241230701648908.JavaMail.defaultUser@defaultHost>
References: <4547243.744241230701648908.JavaMail.defaultUser@defaultHost>
Message-ID: <20090105074839.GE1842@cdnetworks.co.kr>

On Wed, Dec 31, 2008 at 06:34:08AM +0100, Barbara wrote:
 > Hello,
 > one of my motherboards has an onboard Attansic network interface, I 
 > think an AR8121.
 > 
 > # pciconf -lcv
 > none0@pci0:4:0:0:       class=0x020000 
 > card=0x82261043 chip=0x10481969 rev=0xb0 hdr=0x00
 >     vendor     = 'Attansic 
 > (Now owned by Atheros)'
 >     device     = 'L1 Gigabit Ethernet 10/100/1000Base-T 
 > Ethernet Controller'
 >     class      = network
 >     subclass   = ethernet
 >     cap 
 > 01[40] = powerspec 2  supports D0 D3  current D0
 >     cap 05[48] = MSI supports 
 > 1 message, 64 bit
 >     cap 10[58] = PCI-Express 1 endpoint
 >     cap 03[6c] = VPD
 > 
 > 
 > Today I decided to give it a try.
 > But if I try loading the if_age module, the 
 > system prints the following lines and then it freezes.
 > 
 > age0: <Attansic 
 > Technology Corp, L1 Gigabit Ethernet> mem 0xfbdc0000-0xfbdfffff irq 36 at 
 > device 0.0 on pci4
 > age0: PCI device revision : 0x00b0
 > age0: Chip id/revision : 
 > 0x9006
 > age0: 1280 Tx FIFO, 2364 Rx FIFO
 > age0: MSIX count : 0
 > age0: MSI count : 
 > 1
 > age0: Using 1 MSI messages.
 > age0: Read request size : 512 bytes.
 > age0: TLP 
 > payload size : 128 bytes.
 > 

I guess it could be related with VPD access code in age(4) or
automatic power-down feature of hardware. Unfortunately I have no
longer access to L1 hardware so it looks hard to write a patch for
the issue. Would you try following instructions?
 - Shutdown your box.
 - Completely remove power cord from your system and wait 5 to 10
   min.(Just turning system off is not enough.)
 - Make sure to plug UTP cable to your controller before system
   boot.
 - Plug power cord and let system boot.
 - Enter BIOS menu and search onboard PCIe LAN configuration in the
   menu. If "LAN Option ROM" was enabled, disable the option.
 - Some motherboard might have set another option for "Check
   Atheros LAN cable". If it was set, disable it. If you also have
   an option for "Asus Express Gate" try disabling it.
 - Save changes and reboot.

Does that make any difference?

-- 
Regards,
Pyun YongHyeon
From jonc at chen.org.nz  Mon Jan  5 08:45:49 2009
From: jonc at chen.org.nz (Jonathan Chen)
Date: Mon Jan  5 08:45:56 2009
Subject: X11 on Dell D830 with latest 7.1-PRERELEASE
In-Reply-To: <7d6fde3d0901042129i4dd2dagf06dcca7c6b7681b@mail.gmail.com>
References: <20090105031744.GA74033@osiris.chen.org.nz>
	<7d6fde3d0901042129i4dd2dagf06dcca7c6b7681b@mail.gmail.com>
Message-ID: <20090105084545.GA91864@osiris.chen.org.nz>

On Sun, Jan 04, 2009 at 09:29:58PM -0800, Garrett Cooper wrote:
> On Sun, Jan 4, 2009 at 7:17 PM, Jonathan Chen <jonc@chen.org.nz> wrote:
> > Hi,
> >
> > I've got a Dell Latitude D830 running 7.1-PRERELEASE/amd64 which I've
> > just csup'd to the -STABLE as of 5-Jan-2009, and after going thru' the
> > std build+install; XOrg now comes up with a blank screen, sometimes
> > interspersed with green dots. I did test out X prior to doing an
> > installworld, and that came up with no problems. However, after doing
> > an installworld, X is now broken.
> >
> > Prior to this update, the D830 was running -STABLE from Nov-2008;
> > which appeared to work fine. All ports are up to date.
> >
> > I'd appreciate any help in resolving this problem.
> 
> Jonathan,
>     What video card driver are you using and have you recompiled the driver?

I'm using the "nv" driver. I've recompiled everything slaved to the x11/xorg
port, with no better results. Oddly enough, my desktop which also runs
the same snapshot (and same arch) with the "nv" driver works fine.

Currently, it looks like some userland change has tripped the driver
behaviour; as running a newer kernel on an older userland is still
okay.

Cheers.
-- 
Jonathan Chen <jonc@chen.org.nz>
----------------------------------------------------------------------
                                         "Nyuck, nyuck, nyuck" - Curly
From kamikaze at bsdforen.de  Mon Jan  5 09:42:09 2009
From: kamikaze at bsdforen.de (Dominic Fandrey)
Date: Mon Jan  5 09:42:17 2009
Subject: hald -> instant panic
Message-ID: <4961D5CE.4070703@bsdforen.de>

I just started hald on a RELENG_7 system, fetched and built yesterday.

The result was an instant panic, here's the backtrace:


GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "amd64-marcel-freebsd"...

Unread portion of the kernel message buffer:
kernel trap 12 with interrupts disabled


Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address	= 0x30
fault code		= supervisor read data, page not present
instruction pointer	= 0x8:0xffffffff80238a70
stack pointer	        = 0x10:0xffffffffaf32f920
frame pointer	        = 0x10:0xffffff0026618370
code segment		= base 0x0, limit 0xfffff, type 0x1b
			= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags	= resume, IOPL = 0
current process		= 7086 (hald-probe-storage)
trap number		= 12
panic: page fault
cpuid = 0
Uptime: 43m15s
Physical memory: 2029 MB
Dumping 314 MB: 299 283 267 251 235 219 203 187 (CTRL-C to abort)  (CTRL-C to abort)  (CTRL-C to abort)  171 155 139 123 107 91 75 59 43 27 11

Reading symbols from /boot/kernel/geom_md.ko...Reading symbols from /boot/kernel/geom_md.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/geom_md.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/if_bge.ko...Reading symbols from /boot/kernel/if_bge.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/if_bge.ko
Reading symbols from /boot/kernel/miibus.ko...Reading symbols from /boot/kernel/miibus.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/miibus.ko
Reading symbols from /boot/kernel/snd_hda.ko...Reading symbols from /boot/kernel/snd_hda.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/snd_hda.ko
Reading symbols from /boot/kernel/sound.ko...Reading symbols from /boot/kernel/sound.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/sound.ko
Reading symbols from /boot/kernel/usb.ko...Reading symbols from /boot/kernel/usb.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/usb.ko
Reading symbols from /boot/kernel/ugen.ko...Reading symbols from /boot/kernel/ugen.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/ugen.ko
Reading symbols from /boot/kernel/ums.ko...Reading symbols from /boot/kernel/ums.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/ums.ko
Reading symbols from /boot/kernel/umass.ko...Reading symbols from /boot/kernel/umass.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/umass.ko
Reading symbols from /boot/kernel/cam.ko...Reading symbols from /boot/kernel/cam.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/cam.ko
Reading symbols from /boot/kernel/agp.ko...Reading symbols from /boot/kernel/agp.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/agp.ko
Reading symbols from /boot/kernel/random.ko...Reading symbols from /boot/kernel/random.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/random.ko
Reading symbols from /boot/kernel/atadisk.ko...Reading symbols from /boot/kernel/atadisk.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/atadisk.ko
Reading symbols from /boot/kernel/ata.ko...Reading symbols from /boot/kernel/ata.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/ata.ko
Reading symbols from /boot/kernel/atapci.ko...Reading symbols from /boot/kernel/atapci.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/atapci.ko
Reading symbols from /boot/modules/u3g.ko...done.
Loaded symbols for /boot/modules/u3g.ko
Reading symbols from /boot/kernel/ucom.ko...Reading symbols from /boot/kernel/ucom.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/ucom.ko
Reading symbols from /boot/kernel/atapicd.ko...Reading symbols from /boot/kernel/atapicd.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/atapicd.ko
Reading symbols from /boot/kernel/atapicam.ko...Reading symbols from /boot/kernel/atapicam.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/atapicam.ko
Reading symbols from /boot/kernel/if_wpi.ko...Reading symbols from /boot/kernel/if_wpi.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/if_wpi.ko
Reading symbols from /boot/kernel/wlan.ko...Reading symbols from /boot/kernel/wlan.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/wlan.ko
Reading symbols from /boot/kernel/firmware.ko...Reading symbols from /boot/kernel/firmware.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/firmware.ko
Reading symbols from /boot/kernel/wlan_amrr.ko...Reading symbols from /boot/kernel/wlan_amrr.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/wlan_amrr.ko
Reading symbols from /boot/kernel/wpifw.ko...Reading symbols from /boot/kernel/wpifw.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/wpifw.ko
Reading symbols from /boot/kernel/wlan_scan_sta.ko...Reading symbols from /boot/kernel/wlan_scan_sta.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/wlan_scan_sta.ko
Reading symbols from /boot/kernel/wlan_ccmp.ko...Reading symbols from /boot/kernel/wlan_ccmp.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/wlan_ccmp.ko
Reading symbols from /boot/kernel/wlan_tkip.ko...Reading symbols from /boot/kernel/wlan_tkip.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/wlan_tkip.ko
Reading symbols from /boot/kernel/cpufreq.ko...Reading symbols from /boot/kernel/cpufreq.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/cpufreq.ko
Reading symbols from /boot/kernel/uvisor.ko...Reading symbols from /boot/kernel/uvisor.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/uvisor.ko
Reading symbols from /boot/kernel/nullfs.ko...Reading symbols from /boot/kernel/nullfs.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/nullfs.ko
Reading symbols from /boot/kernel/if_tun.ko...Reading symbols from /boot/kernel/if_tun.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/if_tun.ko
Reading symbols from /usr/local/modules/fuse.ko...done.
Loaded symbols for /usr/local/modules/fuse.ko
Reading symbols from /boot/kernel/i915.ko...Reading symbols from /boot/kernel/i915.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/i915.ko
Reading symbols from /boot/kernel/drm.ko...Reading symbols from /boot/kernel/drm.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/drm.ko
#0  doadump () at pcpu.h:195
195	pcpu.h: No such file or directory.
	in pcpu.h
(kgdb) bt
#0  doadump () at pcpu.h:195
#1  0x0000000000000004 in ?? ()
#2  0xffffffff80205ce1 in boot (howto=260)
    at /usr/src/sys/kern/kern_shutdown.c:418
#3  0xffffffff8020611c in panic (fmt=0x104 <Address 0x104 out of bounds>)
    at /usr/src/sys/kern/kern_shutdown.c:574
#4  0xffffffff803e93aa in trap_fatal (frame=0xffffff0026618370, eva=Variable "eva" is not available.
)
    at /usr/src/sys/amd64/amd64/trap.c:764
#5  0xffffffff803e9f74 in trap (frame=0xffffffffaf32f870)
    at /usr/src/sys/amd64/amd64/trap.c:290
#6  0xffffffff803d0b5e in calltrap ()
    at /usr/src/sys/amd64/amd64/exception.S:209
#7  0xffffffff80238a70 in turnstile_broadcast (ts=0x0, queue=0)
    at /usr/src/sys/kern/subr_turnstile.c:836
#8  0xffffffff801fa3d6 in _mtx_unlock_sleep (m=0xffffffff805aa180, opts=Variable "opts" is not available.
)
    at /usr/src/sys/kern/kern_mutex.c:619
#9  0xffffffff801fa6d3 in unlock_mtx (lock=0x0)
    at /usr/src/sys/kern/kern_mutex.c:158
#10 0xffffffff8020d760 in _sleep (ident=0x0, lock=0xffffffff805aa180, 
    priority=256, wmesg=0xffffffff80815847 "sgread", timo=0)
    at /usr/src/sys/kern/kern_synch.c:185
#11 0xffffffff8080e4a9 in sgread (dev=Variable "dev" is not available.
)
    at /usr/src/sys/modules/cam/../../cam/scsi/scsi_sg.c:798
#12 0xffffffff801d116f in giant_read (dev=0xffffff0003038800, 
    uio=0xffffffffaf32fb20, ioflag=0) at /usr/src/sys/kern/kern_conf.c:424
#13 0xffffffff80199f4c in devfs_read_f (fp=0xffffff003bbc4e00, 
    uio=0xffffffffaf32fb20, cred=Variable "cred" is not available.
) at /usr/src/sys/fs/devfs/devfs_vnops.c:1000
#14 0xffffffff8023ab8f in dofileread (td=0xffffff0026618370, fd=4, 
    fp=0xffffff003bbc4e00, auio=0xffffffffaf32fb20, offset=Variable "offset" is not available.
) at file.h:244
#15 0xffffffff8023ae58 in kern_readv (td=0xffffff0026618370, fd=4, 
    auio=0xffffffffaf32fb20) at /usr/src/sys/kern/sys_generic.c:192
#16 0xffffffff8023af18 in read (td=Variable "td" is not available.
) at /usr/src/sys/kern/sys_generic.c:108
#17 0xffffffff803e99bc in syscall (frame=0xffffffffaf32fc80)
    at /usr/src/sys/amd64/amd64/trap.c:907
#18 0xffffffff803d0d6b in Xfast_syscall ()
    at /usr/src/sys/amd64/amd64/exception.S:330
#19 0x0000000800cf03dc in ?? ()
Previous frame inner to this frame (corrupt stack?)
(kgdb) quit
From barbara.xxx1975 at libero.it  Mon Jan  5 10:36:57 2009
From: barbara.xxx1975 at libero.it (Barbara)
Date: Mon Jan  5 10:37:05 2009
Subject: Lock enabling onboard lan (Attansic L1 GbE) on 7.1-PRERELEASE
Message-ID: <28973184.939641231151814355.JavaMail.defaultUser@defaultHost>



>On Wed, Dec 31, 2008 at 06:34:08AM +0100, Barbara wrote:
> > Hello,
> > one 
of my motherboards has an onboard Attansic network interface, I 
> > think an 
AR8121.
> > 
> > # pciconf -lcv
> > none0@pci0:4:0:0:       class=0x020000 
> > 
card=0x82261043 chip=0x10481969 rev=0xb0 hdr=0x00
> >     vendor     = 
'Attansic 
> > (Now owned by Atheros)'
> >     device     = 'L1 Gigabit 
Ethernet 10/100/1000Base-T 
> > Ethernet Controller'
> >     class      = 
network
> >     subclass   = ethernet
> >     cap 
> > 01[40] = powerspec 2  
supports D0 D3  current D0
> >     cap 05[48] = MSI supports 
> > 1 message, 64 
bit
> >     cap 10[58] = PCI-Express 1 endpoint
> >     cap 03[6c] = VPD
> > 
> 
> 
> > Today I decided to give it a try.
> > But if I try loading the if_age 
module, the 
> > system prints the following lines and then it freezes.
> > 
> 
> age0: <Attansic 
> > Technology Corp, L1 Gigabit Ethernet> mem 0xfbdc0000-
0xfbdfffff irq 36 at 
> > device 0.0 on pci4
> > age0: PCI device revision : 
0x00b0
> > age0: Chip id/revision : 
> > 0x9006
> > age0: 1280 Tx FIFO, 2364 Rx 
FIFO
> > age0: MSIX count : 0
> > age0: MSI count : 
> > 1
> > age0: Using 1 
MSI messages.
> > age0: Read request size : 512 bytes.
> > age0: TLP 
> > 
payload size : 128 bytes.
> > 
>
>I guess it could be related with VPD access 
code in age(4) or
>automatic power-down feature of hardware. Unfortunately I 
have no
>longer access to L1 hardware so it looks hard to write a patch for

>the issue. Would you try following instructions?
> - Shutdown your box.
> - 
Completely remove power cord from your system and wait 5 to 10
>   min.(Just 
turning system off is not enough.)
> - Make sure to plug UTP cable to your 
controller before system
>   boot.
> - Plug power cord and let system boot.
> - 
Enter BIOS menu and search onboard PCIe LAN configuration in the
>   menu. If 
"LAN Option ROM" was enabled, disable the option.
> - Some motherboard might 
have set another option for "Check
>   Atheros LAN cable". If it was set, 
disable it. If you also have
>   an option for "Asus Express Gate" try 
disabling it.
> - Save changes and reboot.
>
>Does that make any difference?
>

>-- 
>Regards,
>Pyun YongHyeon

I've tried all the thing you've suggested with 
the same result.
I've disabled "LAN Option ROM", but it seems that I don't have 
the other options you mentioned.
I've downloaded and burned the 7.1-RELEASE dvd 
and tried to boot from it, but it hangs at the same point.
Finally I've tried 
booting a CURRENT snapshot cd (8.0-CURRENT-200812) and I was able to properly 
configure the device in sysinstall.
Any idea about the problem?
I've installed 
from 7.0 and I have another NIC, but being now age in GENERIC, I hope it will 
not cause troubles to other people installing for the first time.
Anyway thank 
you for now, and ask me if there is something that I can do to fix the problem 
like more tests, patches, etc.

Best regards
Barbara

From lists at avioc.org  Mon Jan  5 12:33:56 2009
From: lists at avioc.org (Brandon Weisz)
Date: Mon Jan  5 12:34:09 2009
Subject: Panic in RELENG_7_1 with fxp(4)
In-Reply-To: <20090105032657.GA1842@cdnetworks.co.kr>
References: <49600E2E.7070601@avioc.org>
	<3163F769-48B0-4CFC-8842-BBBDDAE78B51@gmail.com>
	<20090105032657.GA1842@cdnetworks.co.kr>
Message-ID: <4961FACE.4060203@avioc.org>

Pyun YongHyeon wrote:
> On Sat, Jan 03, 2009 at 10:16:58PM -0800, Garrett Cooper wrote:
>  > On Jan 3, 2009, at 5:17 PM, Brandon Weisz wrote:
>  > 
>  > >After running 7-PRERELEASE from around November 25th, I upgraded  
>  > >today to find the system panics repeatably on RELENG_7_1 sources.  I  
>  > >can boot back to the old kernel and it operates as expected.  It  
>  > >seems to be related to fxp(4).
>  > >
>  > >FreeBSD didy.internal 7.1-RELEASE FreeBSD 7.1-RELEASE #0: Sat Jan  3
>  > >18:11:18 CST 2009     bweisz@didy.internal:/usr/obj/usr/src/sys/ 
>  > >DIDY  i386
>  > >

....

>  > >
>  > >I replaced the fxp(4) card with an old xl(4) card lying on my desk  
>  > >and the panics stopped.  Is this a failing nic card or some other  
>  > >trigger?
>  > >
>  > >Brandon
>  > 
>  > Memory serves me correctly an MFC was done not too long before 7.1  
>  > release was setup.
>  > 
> 
> I don't know what MFCes were done, at least I didn't MFC any
> changes I made.
> 
>  > Let's see what Pyun says...
>  > 
> 
> I'm not sure what is root cause of this panic. If you can reliably
> reproduce the panic would you let me know?
> CURRENT has a couple of fixes for edge-cases as well as some new
> hardware features(TSO, VLAN hardware tagging and WOL etc). Would
> you try latest fxp(4) in HEAD?
> I think you can use cvsweb interface to get latest files.
> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/fxp/if_fxp.c
> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/fxp/if_fxpreg.h
> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/fxp/if_fxpvar.h
> 

Hi Pyun

The system reliably panics on boot up.  I tested fxp from HEAD with the 
same result.

7.1-RELEASE = Panic
7.1-RELEASE with fxp from HEAD = Panic
7.1-PRERELEASE from Tue Nov 25 = operates as expected

This is an old card.  Some details on the card:

fxp0: <Intel 82559 Pro/100 Ethernet> port 0xd100-0xd13f mem 
0xfca03000-0xfca03fff,0xfc800000-0xfc8fffff irq 17 at device 9.0 on pci0
miibus0: <MII bus> on fxp0
inphy0: <i82555 10/100 media interface> PHY 1 on miibus0
inphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
fxp0: Ethernet address: 00:d0:b7:6c:1c:0a
fxp0: [ITHREAD]

fxp0@pci0:0:9:0:	class=0x020000 card=0x000b8086 chip=0x12298086 rev=0x08 
hdr=0x00
     vendor     = 'Intel Corporation'
     device     = '82550/1/7/8/9 EtherExpress PRO/100(B) Ethernet Adapter'
     class      = network
     subclass   = ethernet

As a test, I unplugged the ethernet cable and the system booted fully, 
however it produced a panic as soon as I connected the cable.  This 
backtrace is from 7.1-RELEASE with fxp sources from HEAD.

Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address	= 0x40c
fault code		= supervisor read, page not present
instruction pointer	= 0x20:0xc0a950d0
stack pointer	        = 0x28:0xe4418750
frame pointer	        = 0x28:0xe4418764
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		= 23 (irq17: fxp0)
trap number		= 12
panic: page fault
cpuid = 0
Uptime: 1m33s
Physical memory: 995 MB
Dumping 179 MB: 164 148 132 116 100 84 68 52 36 20 4

Reading symbols from /boot/kernel/vesa.ko...Reading symbols from 
/boot/kernel/vesa.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/vesa.ko
Reading symbols from /boot/kernel/accf_http.ko...Reading symbols from 
/boot/kernel/accf_http.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/accf_http.ko
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/pflog.ko...Reading symbols from 
/boot/kernel/pflog.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/pflog.ko
Reading symbols from /boot/kernel/pf.ko...Reading symbols from 
/boot/kernel/pf.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/pf.ko
Reading symbols from /boot/kernel/nullfs.ko...Reading symbols from 
/boot/kernel/nullfs.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/nullfs.ko
Reading symbols from /boot/kernel/logo_saver.ko...Reading symbols from 
/boot/kernel/logo_saver.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/logo_saver.ko
#0  doadump () at pcpu.h:196
196		__asm __volatile("movl %%fs:0,%0" : "=r" (td));
(kgdb) list *0xc0a950d0
0xc0a950d0 is in _bus_dmamap_sync 
(/usr/src.local/sys/i386/i386/busdma_machdep.c:935).
930			CTR4(KTR_BUSDMA, "%s: tag %p tag flags 0x%x op 0x%x "
931			    "performing bounce", __func__, op, dmat, dmat->flags);
932	
933			if (op & BUS_DMASYNC_PREWRITE) {
934				while (bpage != NULL) {
935					bcopy((void *)bpage->datavaddr,
936					      (void *)bpage->vaddr,
937					      bpage->datacount);
938					bpage = STAILQ_NEXT(bpage, links);
939				}
(kgdb) bt
#0  doadump () at pcpu.h:196
#1  0xc079cd77 in boot (howto=260) at 
/usr/src.local/sys/kern/kern_shutdown.c:418
#2  0xc079d049 in panic (fmt=Variable "fmt" is not available.
) at /usr/src.local/sys/kern/kern_shutdown.c:574
#3  0xc0ab0f7c in trap_fatal (frame=0xe4418710, eva=1036) at 
/usr/src.local/sys/i386/i386/trap.c:939
#4  0xc0ab1200 in trap_pfault (frame=0xe4418710, usermode=0, eva=1036) 
at /usr/src.local/sys/i386/i386/trap.c:852
#5  0xc0ab1bbc in trap (frame=0xe4418710) at 
/usr/src.local/sys/i386/i386/trap.c:530
#6  0xc0a97a2b in calltrap () at 
/usr/src.local/sys/i386/i386/exception.s:159
#7  0xc0a950d0 in _bus_dmamap_sync (dmat=0xc4048880, map=0xc416e800, 
op=4) at /usr/src.local/sys/i386/i386/busdma_machdep.c:933
#8  0xc05cc72f in fxp_start_body (ifp=0xc4163000) at 
/usr/src.local/sys/dev/fxp/if_fxp.c:1525
#9  0xc05cd0f7 in fxp_start (ifp=0xc4163000) at 
/usr/src.local/sys/dev/fxp/if_fxp.c:1263
#10 0xc0831649 in if_start (ifp=0xc4163000) at 
/usr/src.local/sys/net/if.c:2768
#11 0xc083808b in ether_output_frame (ifp=0xc4163000, m=0xc43a3b00) at 
/usr/src.local/sys/net/if_ethersubr.c:405
#12 0xc083863c in ether_output (ifp=0xc4163000, m=0xc43a3b00, 
dst=0xc423b730, rt0=0xc4489364) at /usr/src.local/sys/net/if_ethersubr.c:374
#13 0xc087ecd5 in ip_output (m=0xc43a3b00, opt=0x0, ro=0xe44189ac, 
flags=Variable "flags" is not available.
) at /usr/src.local/sys/netinet/ip_output.c:554
#14 0xc08dfb6e in tcp_output (tp=0xc63651d0) at 
/usr/src.local/sys/netinet/tcp_output.c:1135
#15 0xc08dc995 in tcp_do_segment (m=0xc4178000, th=0xc41b2834, 
so=0xc633cd00, tp=0xc63651d0, drop_hdrlen=60, tlen=0) at 
/usr/src.local/sys/netinet/tcp_input.c:2358
#16 0xc08dd95e in tcp_input (m=0xc4178000, off0=20) at 
/usr/src.local/sys/netinet/tcp_input.c:846
#17 0xc087d190 in ip_input (m=0xc4178000) at 
/usr/src.local/sys/netinet/ip_input.c:665
#18 0xc08428f5 in netisr_dispatch (num=2, m=0xc4178000) at 
/usr/src.local/sys/net/netisr.c:185
#19 0xc0838861 in ether_demux (ifp=0xc4163000, m=0xc4178000) at 
/usr/src.local/sys/net/if_ethersubr.c:834
#20 0xc0838c53 in ether_input (ifp=0xc4163000, m=0xc4178000) at 
/usr/src.local/sys/net/if_ethersubr.c:692
#21 0xc05cd96c in fxp_intr (xsc=0xc4134000) at 
/usr/src.local/sys/dev/fxp/if_fxp.c:1945
#22 0xc077bd7b in ithread_loop (arg=0xc41609b0) at 
/usr/src.local/sys/kern/kern_intr.c:1088
#23 0xc07788e9 in fork_exit (callout=0xc077bbc0 <ithread_loop>, 
arg=0xc41609b0, frame=0xe4418d38) at /usr/src.local/sys/kern/kern_fork.c:804
#24 0xc0a97aa0 in fork_trampoline () at 
/usr/src.local/sys/i386/i386/exception.s:264
(kgdb)

Regards,

Brandon
From rwatson at FreeBSD.org  Mon Jan  5 13:13:25 2009
From: rwatson at FreeBSD.org (Robert Watson)
Date: Mon Jan  5 13:13:33 2009
Subject: TCP packet out-of-order problem
In-Reply-To: <47713ee10901012249w65c659bbp3366e4d8ef25c59d@mail.gmail.com>
References: <47713ee10812301206j12b35264o715976c154080a1b@mail.gmail.com>
	<47713ee10901012147k1f25c31bn512dd29b2b294ad5@mail.gmail.com>
	<47713ee10901012249w65c659bbp3366e4d8ef25c59d@mail.gmail.com>
Message-ID: <alpine.BSF.2.00.0901051312370.98366@fledge.watson.org>

On Fri, 2 Jan 2009, Lin Jui-Nan Eric wrote:

> After running "netstat -s -p tcp", we found that lots of packets are 
> discarded due to memory problems. We googled for it, and found that sysctl 
> oid "net.inet.tcp.reass.maxsegments" became 0, therefore packets never 
> reassembled.
>
> Then we checked our /boot/loader.conf and /etc/sysctl.conf, and found that 
> setting kern.ipc.nmbclusters="0" makes net.inet.tcp.reass.maxsegments=0. 
> After setting net.inet.tcp.reass.maxsegments="1600" in /boot/loader.conf, 
> the network works perfectly now.

Was it set to 0 through a configuration error, or did the system auto-tune 
improperly?

Robert N M Watson
Computer Laboratory
University of Cambridge

>
> Thank you all for the help!
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
>
From rwatson at FreeBSD.org  Mon Jan  5 13:18:28 2009
From: rwatson at FreeBSD.org (Robert Watson)
Date: Mon Jan  5 13:18:36 2009
Subject: rdump stuck in sbwait state (RELENG_7)
In-Reply-To: <01N3VGDZ7EOM0008L3@tmk.com>
References: <01N3OFGBCXMS000125@tmk.com> <01N3OYSUCHAE000125@tmk.com>
	<01N3VGDZ7EOM0008L3@tmk.com>
Message-ID: <alpine.BSF.2.00.0901051317160.98366@fledge.watson.org>

On Sat, 3 Jan 2009, Terry Kennedy wrote:

>> Sorry, I can't think of any - by the time you see it hung, whatever went 
>> wrong has already happened.  You might glean some insight from the TCP 
>> socket state (on the FreeBSD side, use 'netstat -A' to print the PCB 
>> address and gdb to dump the contents but I'm not sure how to get this data 
>> out of OpenVMS).  The '-C' and '-W' options to tcpdump will help.
>
>  Ok, I found some time to reproduce this while capturing a trace with 
> tcpdump.
>
>  Here's the relevant output from netstat / kgdb:

I may have missed this earlier in the thread, but I don't see a kernel stack 
trace of the stuck thread/process.  Could you grab one using procstat -k, DDB, 
or KGDB?  I'd like to confirm that the 'sbwait' really reflects waiting to 
send, rather than waiting to receive, which (for better or worse) uses the 
same wmesg.  procstat -k may be the simplest of the above to do if your system 
is reasonable recent.

Robert N M Watson
Computer Laboratory
University of Cambridge

>
> (0:31) test4:~terry# netstat -A
> Active Internet connections
> Tcpcb    Proto Recv-Q Send-Q  Local Address      Foreign Address    (state)
> c73eeae0 tcp4       0      0 test4.892          server.shell       ESTABLISHED
> [snip]
>
> (0:32) test4:~terry# kgdb
> GNU gdb 6.1.1 [FreeBSD]
> [snip]
> #0  0x00000000 in ?? ()
> (kgdb) print * (struct tcpcb *) 0xc73eeae0
> $1 = {t_segq = {lh_first = 0x0}, t_segqlen = 0, t_dupacks = 0,
>  t_timers = 0xc73eec24, t_inpcb = 0xc7387708, t_state = 4, t_flags = 484,
>  snd_una = 292841209, snd_max = 292841209, snd_nxt = 292841209,
>  snd_up = 292780017, snd_wl1 = 3606352422, snd_wl2 = 292841209,
>  iss = 3955646224, irs = 3606284909, rcv_nxt = 3606352422,
>  rcv_adv = 3606415910, rcv_wnd = 63488, rcv_up = 3606352422, snd_wnd = 65535,
>  snd_cwnd = 65535, snd_bwnd = 1073725440, snd_ssthresh = 1073725440,
>  snd_bandwidth = 0, snd_recover = 3955646224, t_maxopd = 1460,
>  t_rcvtime = 11273919, t_starttime = 11024967, t_rtttime = 0,
>  t_rtseq = 292839154, t_bw_rtttime = 11024966, t_bw_rtseq = 3955646224,
>  t_rxtcur = 230, t_maxseg = 1448, t_srtt = 145, t_rttvar = 34,
>  t_rxtshift = 0, t_rttmin = 30, t_rttbest = 67, t_rttupdated = 232101,
>  max_sndwnd = 65535, t_softerror = 0, t_oobflags = 0 '\0', t_iobc = 0 '\0',
>  snd_scale = 0 '\0', rcv_scale = 3 '\003', request_r_scale = 3 '\003',
>  ts_recent = 1207233, ts_recent_age = 11273919, ts_offset = 0,
>  last_ack_sent = 3606352422, snd_cwnd_prev = 0, snd_ssthresh_prev = 0,
>  snd_recover_prev = 0, t_badrxtwin = 0, snd_limited = 0 '\0',
>  snd_numholes = 0, snd_holes = {tqh_first = 0x0, tqh_last = 0xc73eebb8},
>  snd_fack = 0, rcv_numsacks = 0, sackblks = {{start = 0, end = 0}, {
>      start = 0, end = 0}, {start = 0, end = 0}, {start = 0, end = 0}, {
>      start = 0, end = 0}, {start = 0, end = 0}}, sack_newdata = 0,
>  sackhint = {nexthole = 0x0, sack_bytes_rexmit = 0}, t_rttlow = 1,
>  rfbuf_ts = 0, rfbuf_cnt = 0, t_pspare = {0x0, 0x0, 0x0}, t_tu = 0x0,
>  t_toe = 0x0}
> (kgdb) q
>
>  Rather than pasting the decoded tcpdump output here, the raw capture
> file is at http://www.tmk.com/transient/rdump30.gz (it is only 76KB
> compressed, 270KB uncompressed). It looks to me like the remote host
> (the VMS box) has correctly ack'd all outstanding data from the FreeBSD
> host, but that the FreeBSD host is just sitting there for some reason.
>
>  As before, I have this sitting in the wedged state so if anyone needs
> more data, I can either collect it or give you access to the system.
>
>        Terry Kennedy             http://www.tmk.com
>        terry@tmk.com             New York, NY USA
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
>
From terry at tmk.com  Mon Jan  5 13:28:57 2009
From: terry at tmk.com (Terry Kennedy)
Date: Mon Jan  5 13:29:05 2009
Subject: rdump stuck in sbwait state (RELENG_7)
In-Reply-To: "Your message dated Mon, 05 Jan 2009 13:18:27 +0000 (GMT)"
	<alpine.BSF.2.00.0901051317160.98366@fledge.watson.org>
References: <01N3OFGBCXMS000125@tmk.com> <01N3OYSUCHAE000125@tmk.com>
	<01N3VGDZ7EOM0008L3@tmk.com>
Message-ID: <01N3XI0VWEA00008L3@tmk.com>

> I may have missed this earlier in the thread, but I don't see a kernel stack
> trace of the stuck thread/process.  Could you grab one using procstat -k, DDB,
> or KGDB?  I'd like to confirm that the 'sbwait' really reflects waiting to
> send, rather than waiting to receive, which (for better or worse) uses the
> same wmesg.  procstat -k may be the simplest of the above to do if your system
> is reasonable recent.

  I didn't post that earlier as no-one had asked for it 8-)

  The system is current as of December 29th. Here's the relevant info:

(0:10) test4:/sysprog/terry# uname -a
FreeBSD test4.tmk.com 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #0: Mon Dec 29 11:48:04 EST 2008     terry@test4.tmk.com:/usr/obj/usr/src/sys/PE1550  i386
(0:11) test4:/sysprog/terry# ps -axwww | grep dump
  UID   PID  PPID CPU PRI NI   VSZ   RSS MWCHAN STAT  TT       TIME COMMAND
    0  4436  4411   0   8  0 35896 34552 wait   I+    p1    0:00.70 /sbin/rdump 0uLa -b 64 -C 32 -f server /usr (rdump)
    0  4439  4436   0   4  0 35896 34784 sbwait I+    p1    0:03.05 rdump: /dev/amrd0s1f: pass 4: 18.48% done, finished in 0:17 at Sat Jan  3 21:02:05 2009 (rdump)
    0  4440  4439   0  20  0 35896 34624 pause  I+    p1    0:05.26 /sbin/rdump 0uLa -b 64 -C 32 -f server /usr (rdump)
    0  4441  4439   0  20  0 35896 34624 pause  I+    p1    0:05.26 /sbin/rdump 0uLa -b 64 -C 32 -f server /usr (rdump)
    0  4442  4439   0   4  0 35896 34624 sbwait I+    p1    0:05.26 /sbin/rdump 0uLa -b 64 -C 32 -f server /usr (rdump)
(0:12) test4:/sysprog/terry# procstat -k 4436
  PID    TID COMM             TDNAME           KSTACK                       
 4436 100115 rdump            -                mi_switch sleepq_switch sleepq_catch_signals sleepq_wait_sig _sleep kern_wait wait4 syscall Xint0x80_syscall 
(0:13) test4:/sysprog/terry# procstat -k 4439
  PID    TID COMM             TDNAME           KSTACK                       
 4439 100127 rdump            -                mi_switch sleepq_switch sleepq_catch_signals sleepq_wait_sig _sleep sbwait soreceive_generic soreceive soo_read dofileread kern_readv read syscall Xint0x80_syscall 
(0:14) test4:/sysprog/terry# procstat -k 4440
  PID    TID COMM             TDNAME           KSTACK                       
 4440 100131 rdump            -                mi_switch sleepq_switch sleepq_catch_signals sleepq_wait_sig _sleep kern_sigsuspend sigsuspend syscall Xint0x80_syscall 
(0:15) test4:/sysprog/terry# procstat -k 4441
  PID    TID COMM             TDNAME           KSTACK                       
 4441 100105 rdump            -                mi_switch sleepq_switch sleepq_catch_signals sleepq_wait_sig _sleep kern_sigsuspend sigsuspend syscall Xint0x80_syscall 
(0:16) test4:/sysprog/terry# procstat -k 4442
  PID    TID COMM             TDNAME           KSTACK                       
 4442 100135 rdump            -                mi_switch sleepq_switch sleepq_catch_signals sleepq_wait_sig _sleep sbwait soreceive_generic soreceive soo_read dofileread kern_readv read syscall Xint0x80_syscall 

  As I understand it, the processes in sbwait state are waiting to receive.
That would seem to indicate that they don't see the ACKs from the other
end, despite the tcpdump showing that they were received.

  Let me know if you need more information.

        Terry Kennedy             http://www.tmk.com
        terry@tmk.com             New York, NY USA
From rwatson at FreeBSD.org  Mon Jan  5 14:16:58 2009
From: rwatson at FreeBSD.org (Robert Watson)
Date: Mon Jan  5 14:17:05 2009
Subject: rdump stuck in sbwait state (RELENG_7)
In-Reply-To: <01N3XI0VWEA00008L3@tmk.com>
References: <01N3OFGBCXMS000125@tmk.com> <01N3OYSUCHAE000125@tmk.com>
	<01N3VGDZ7EOM0008L3@tmk.com> <01N3XI0VWEA00008L3@tmk.com>
Message-ID: <alpine.BSF.2.00.0901051411240.98366@fledge.watson.org>

On Mon, 5 Jan 2009, Terry Kennedy wrote:

>> I may have missed this earlier in the thread, but I don't see a kernel 
>> stack trace of the stuck thread/process.  Could you grab one using procstat 
>> -k, DDB, or KGDB?  I'd like to confirm that the 'sbwait' really reflects 
>> waiting to send, rather than waiting to receive, which (for better or 
>> worse) uses the same wmesg.  procstat -k may be the simplest of the above 
>> to do if your system is reasonable recent.
>
> I didn't post that earlier as no-one had asked for it 8-)

Indeed :-).

> The system is current as of December 29th. Here's the relevant info:

Could I ask you to also send me procstat -f output?

More below the quote.

> (0:10) test4:/sysprog/terry# uname -a
> FreeBSD test4.tmk.com 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #0: Mon Dec 29 
> 11:48:04 EST 2008     terry@test4.tmk.com:/usr/obj/usr/src/sys/PE1550  i386
> (0:11) test4:/sysprog/terry# ps -axwww | grep dump
> UID   PID  PPID CPU PRI NI   VSZ   RSS MWCHAN STAT  TT       TIME COMMAND
>   0  4436  4411   0   8  0 35896 34552 wait   I+    p1    0:00.70 
> /sbin/rdump 0uLa -b 64 -C 32 -f server /usr (rdump)
>   0  4439  4436   0   4  0 35896 34784 sbwait I+    p1    0:03.05 rdump: 
> /dev/amrd0s1f: pass 4: 18.48% done, finished in 0:17 at Sat Jan  3 21:02:05 
> 2009 (rdump)
>   0  4440  4439   0  20  0 35896 34624 pause  I+    p1    0:05.26 
> /sbin/rdump 0uLa -b 64 -C 32 -f server /usr (rdump)
>   0  4441  4439   0  20  0 35896 34624 pause  I+    p1    0:05.26 
> /sbin/rdump 0uLa -b 64 -C 32 -f server /usr (rdump)
>   0  4442  4439   0   4  0 35896 34624 sbwait I+    p1    0:05.26 
> /sbin/rdump 0uLa -b 64 -C 32 -f server /usr (rdump)
> (0:12) test4:/sysprog/terry# procstat -k 4436
> PID    TID COMM             TDNAME           KSTACK 
> 4436 100115 rdump            -                mi_switch sleepq_switch 
> sleepq_catch_signals sleepq_wait_sig _sleep kern_wait wait4 syscall 
> Xint0x80_syscall (0:13) test4:/sysprog/terry# procstat -k 4439
> PID    TID COMM             TDNAME           KSTACK 
> 4439 100127 rdump            -                mi_switch sleepq_switch 
> sleepq_catch_signals sleepq_wait_sig _sleep sbwait soreceive_generic 
> soreceive soo_read dofileread kern_readv read syscall Xint0x80_syscall (0:14) 
> test4:/sysprog/terry# procstat -k 4440
> PID    TID COMM             TDNAME           KSTACK 
> 4440 100131 rdump            -                mi_switch sleepq_switch 
> sleepq_catch_signals sleepq_wait_sig _sleep kern_sigsuspend sigsuspend 
> syscall Xint0x80_syscall (0:15) test4:/sysprog/terry# procstat -k 4441
> PID    TID COMM             TDNAME           KSTACK 
> 4441 100105 rdump            -                mi_switch sleepq_switch 
> sleepq_catch_signals sleepq_wait_sig _sleep kern_sigsuspend sigsuspend 
> syscall Xint0x80_syscall (0:16) test4:/sysprog/terry# procstat -k 4442
> PID    TID COMM             TDNAME           KSTACK 
> 4442 100135 rdump            -                mi_switch sleepq_switch 
> sleepq_catch_signals sleepq_wait_sig _sleep sbwait soreceive_generic 
> soreceive soo_read dofileread kern_readv read syscall Xint0x80_syscall

> As I understand it, the processes in sbwait state are waiting to receive. 
> That would seem to indicate that they don't see the ACKs from the other end, 
> despite the tcpdump showing that they were received.

In general, being blocked in soreceive() means that the application at the 
other end hasn't sent data, or the other end hasn't received or correctly 
processed ACKs from the local end, so isn't sending more data that it has 
queued up.  The condition you describe sounds more like what would happen in a 
sender: that it has data to send, but the remote side hasn't ACK'd 
sufficiently to send it all.  If you have kgdb handy, it would be useful to 
look at *so and *so->so_domain in the soreceive_generic frame of proc 4439. 
If it's an inet socket, we'd like to see *(struct inpcb *)so->so_pcb, and if 
it's a TCP socket, *(struct tcpcb *)((struct inpcb *)so->so_pcb)->inp_ppcb.

Robert N M Watson
Computer Laboratory
University of Cambridge
From torfinn.ingolfsen at broadpark.no  Mon Jan  5 16:36:38 2009
From: torfinn.ingolfsen at broadpark.no (Torfinn Ingolfsen)
Date: Mon Jan  5 16:36:45 2009
Subject: Samsung SCX-4200 printer
In-Reply-To: <20090104221422.GA3114@pollux2.free.local.net>
References: <20090104221422.GA3114@pollux2.free.local.net>
Message-ID: <20090105173635.575e32ff.torfinn.ingolfsen@broadpark.no>

On Sun, 04 Jan 2009 23:14:22 +0100
Harald Weis <hawei@free.fr> wrote:

> Is there a way to install the SCX-4200 printer on a FreeBSD box ?
> The printer is delivered with the install software required for Linux.
> And CUPS does not seem to "know" it.

As always, check OpenPrinting.org first:
http://openprinting.org/show_printer.cgi?recnum=Samsung-SCX-4200

HTH
-- 
Regards,
Torfinn Ingolfsen

From erwan at rail.eu.org  Mon Jan  5 16:44:09 2009
From: erwan at rail.eu.org (Erwan David)
Date: Mon Jan  5 16:44:41 2009
Subject: Samsung SCX-4200 printer
In-Reply-To: <20090105173635.575e32ff.torfinn.ingolfsen@broadpark.no>
References: <20090104221422.GA3114@pollux2.free.local.net>
	<20090105173635.575e32ff.torfinn.ingolfsen@broadpark.no>
Message-ID: <20090105164403.GE3756@trusted-logic.com>

On Mon, Jan 05, 2009 at 05:36:35PM CET, Torfinn Ingolfsen <torfinn.ingolfsen@broadpark.no> said:
> On Sun, 04 Jan 2009 23:14:22 +0100
> Harald Weis <hawei@free.fr> wrote:
> 
> > Is there a way to install the SCX-4200 printer on a FreeBSD box ?
> > The printer is delivered with the install software required for Linux.
> > And CUPS does not seem to "know" it.
> 
> As always, check OpenPrinting.org first:
> http://openprinting.org/show_printer.cgi?recnum=Samsung-SCX-4200
> 

It is not always sufficient. My Brother DCP-540 CN is said to work
perfectly, but only with brother binary linux drivers, under linux. I
did not find any way to make it work under freeBSD.

-- 
Erwan
From brian at box201.com  Mon Jan  5 18:57:53 2009
From: brian at box201.com (Brian Duke)
Date: Mon Jan  5 18:58:01 2009
Subject: cvsup freebsd 6_2 to freebsd 7_1 not upgrading?
In-Reply-To: <4961FACE.4060203@avioc.org>
References: <49600E2E.7070601@avioc.org>	<3163F769-48B0-4CFC-8842-BBBDDAE78B51@gmail.com>	<20090105032657.GA1842@cdnetworks.co.kr>
	<4961FACE.4060203@avioc.org>
Message-ID: <008b01c96f65$517a9d60$f46fd820$@com>

Hello List,
I'm trying to upgrade my system from 6_2 to 7_1 and cannot seem to do it.
Perhaps I'm missing something. Here is the basic procedure I'm following.

#cp /usr/share/examples/cvsup/standard-supfile /root/stand_sup
#vi /root/stand_sup
<<<host=CHANGE_ME.freebsd.org
>>>host=cvsup15.us.FreeBSD.org
<<<tag=RELENG_6_2
>>>tag=RELENG_7_1

#cd /usr/src
#cvsup -g -L2 /root/stand_sup
...
#make -j4 buildworld; make -j4 buildkernel; make installkernel

... (come back a hour or so later)
#make installworld; reboot

After system is back up log in as root and...

# uname -a
FreeBSD lazerus.box201.com 6.2-RELEASE FreeBSD 6.2-RELEASE #0: Fri Jan 12
11:05:30 UTC 2007     root@dessler.cse.buffalo.edu:/usr/obj/usr/src/sys/SMP
i386

I cannot understand why this system will not upgrade. Even with the
mergemaster -p commands added this system always boots to FreeBSD
6.2-RELEASE. I've tried this in various ways about 20 times and slowly I'm
corrupting the 6.2 build. I have the install disks but the Upgrade FreeBSD
detects the /usr/src and refuses to over-write the directory. The make
commands always finish perfectly. Would someone give this apparent noob a
hand?
 


Agrapha
Solution Developer


From olli at lurza.secnetix.de  Mon Jan  5 19:24:00 2009
From: olli at lurza.secnetix.de (Oliver Fromme)
Date: Mon Jan  5 19:24:07 2009
Subject: newfs(8) parameters from "dumpfs -m" have bad -s value?
In-Reply-To: <20090102153455.GR4100@albert.catwhisker.org>
Message-ID: <200901051923.n05JNrwt038325@lurza.secnetix.de>

David Wolfskill wrote:
 > pool10(7.1-RC1)[32] df -ki /dev/da1s1d
 > Filesystem  1024-blocks Used      Avail Capacity iused     ifree %iused  Mounted on
 > /dev/da1s1d  1702753030    4 1566532784     0%       2 220046332    0%   /b
 > 
 > Here's what dumpfs(8) says:
 > 
 > pool10(7.1-RC1)[36] dumpfs -m /dev/da1s1d
 > # newfs command for /dev/da1s1d (/dev/da1s1d)
 > newfs -O 2 -U -a 8 -b 16384 -d 16384 -e 2048 -f 2048 -g 16384 -h 64 -m 8 -o time -s 879031908 /dev/da1s1d 

This seems to be a bug in dumpfs(8).  It simply prints
the value of the fs_size field of the superblock, which
is wrong.

The -s option of newfs(8) expects the available size in
sectors (i.e. 512 bytes), but the fs_size field contains
the size of the file system in 2KB units.  This seems to
be the fragment size, but I'm not sure if this is just
coincidence (the docs state that it's the size in blocks,
but this is misleading because the blocksize is usually
different; the default is 16K).

So, dumpfs(8) needs to be fixed to perform the proper
calculations when printing the value for the -s option.
Unfortunately I'm not sufficiently much of a UFS guru
to offer a fix.  My best guess would be to multiply the
fs_size value by the fragment size (measured in 512 byte
units), i.e. multiply by 4 in the most common case.
But I'm afraid the real solution is not that simple.

Best regards
   Oliver

-- 
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606,  Gesch?ftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M?n-
chen, HRB 125758,  Gesch?ftsf?hrer: Maik Bachmann, Olaf Erb, Ralf Gebhart

FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd

(On the statement print "42 monkeys" + "1 snake":)  By the way,
both perl and Python get this wrong.  Perl gives 43 and Python
gives "42 monkeys1 snake", when the answer is clearly "41 monkeys
and 1 fat snake".        -- Jim Fulton
From olli at lurza.secnetix.de  Mon Jan  5 19:46:50 2009
From: olli at lurza.secnetix.de (Oliver Fromme)
Date: Mon Jan  5 19:47:02 2009
Subject: FreeBSD 7.1-RC2 Available...
In-Reply-To: <200812292352.mBTNqZ7k085292@fire.js.berklix.net>
Message-ID: <200901051946.n05JkgWo039451@lurza.secnetix.de>

Hi Julian,

Julian Stacey wrote:
 > Martin wrote:
 > > "SDH Admin" <admin@stardothosting.com> wrote:
 > > > Try burning new cd media and/or try another cd-rom drive if possible,
 > > > if the acpi/dma doesn't work.
 > > 
 > > I've tried that already with RC1. I've burned it multiple times and
 > > tried 3 drives. It seems someone removed CD emulation boot from the
 > > livefs CD. It won't work with older PCs anymore. I'm using 8.0-CURRENT
 > > now, but I wanted to give you people a notice. Sometimes a live CD is
 > > useful and perhaps you won't be able to boot it anymore.
 > > 
 > > I just realized that the CD is not booting on older PCs only, that's
 > > why noone is really concerned about it here, perhaps thinking that I'm
 > > not able to burn an ISO or something like that. But I can definitely
 > > boot 8-CURRENT livefs without problems, so at least it's not a drive
 > > problem.
 > 
 > Nasty ! Even though some of us on lists might know to guess & avoid
 > or ask about this, it seems an un-necessary pain as CDROM is only
 > half full.  I recall people got caught last time FreeBSD CDs didnt
 > have both boot methods.  Maybe whoever removed the code didnt know
 > that ?  Hopefully someone could put it back so FreeBSD doesn't look
 > broken to some machines & people ?

In theory you can have multiple boot methods on the same
CD (this is supported by the "ElTorito" standard), but in
practice many BIOS implementations fail miserably at it.

Therefore it is better to use only one boot method, and
the "no emulation" boot method is well supported by today's
machines.  As far as I can tell, all other major operating
systems use it, including the ones from Redmond, so it will
likely work in the foreseeable future.  Apart from that,
the "no emulation" mode is more flexible because you're not
limited to the size of a floppy for the boot image.
I think the latter is the main reason why FreeBSD abandoned
the "floppy emulation" boot method.

I think FreeBSD used the "floppy emulation" boot method
up until 4.x.  So if you have really old hardware that
doesn't support "no emulation" mode, it might be a good
idea to keep an old CD around for rescue purposes.

Best regards
   Oliver

-- 
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606,  Gesch?ftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M?n-
chen, HRB 125758,  Gesch?ftsf?hrer: Maik Bachmann, Olaf Erb, Ralf Gebhart

FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd

"Python tricks" is a tough one, cuz the language is so clean. E.g.,
C makes an art of confusing pointers with arrays and strings, which
leads to lotsa neat pointer tricks; APL mistakes everything for an
array, leading to neat one-liners; and Perl confuses everything
period, making each line a joyous adventure <wink>.
        -- Tim Peters
From brooks at freebsd.org  Mon Jan  5 20:07:32 2009
From: brooks at freebsd.org (Brooks Davis)
Date: Mon Jan  5 20:07:39 2009
Subject: cvsup freebsd 6_2 to freebsd 7_1 not upgrading?
In-Reply-To: <008b01c96f65$517a9d60$f46fd820$@com>
References: <49600E2E.7070601@avioc.org>
	<3163F769-48B0-4CFC-8842-BBBDDAE78B51@gmail.com>
	<20090105032657.GA1842@cdnetworks.co.kr>
	<4961FACE.4060203@avioc.org> <008b01c96f65$517a9d60$f46fd820$@com>
Message-ID: <20090105193555.GA11721@lor.one-eyed-alien.net>

[This question would be better to ask on the freebsd-questions list, but see
below.]

On Mon, Jan 05, 2009 at 11:41:40AM -0700, Brian Duke wrote:
> Hello List,
> I'm trying to upgrade my system from 6_2 to 7_1 and cannot seem to do it.
> Perhaps I'm missing something. Here is the basic procedure I'm following.
> 
> #cp /usr/share/examples/cvsup/standard-supfile /root/stand_sup
> #vi /root/stand_sup
> <<<host=CHANGE_ME.freebsd.org
> >>>host=cvsup15.us.FreeBSD.org
> <<<tag=RELENG_6_2
> >>>tag=RELENG_7_1
> 
> #cd /usr/src
> #cvsup -g -L2 /root/stand_sup
> ...
> #make -j4 buildworld; make -j4 buildkernel; make installkernel
> 
> ... (come back a hour or so later)
> #make installworld; reboot
> 
> After system is back up log in as root and...
> 
> # uname -a
> FreeBSD lazerus.box201.com 6.2-RELEASE FreeBSD 6.2-RELEASE #0: Fri Jan 12
> 11:05:30 UTC 2007     root@dessler.cse.buffalo.edu:/usr/obj/usr/src/sys/SMP
> i386
> 
> I cannot understand why this system will not upgrade. Even with the
> mergemaster -p commands added this system always boots to FreeBSD
> 6.2-RELEASE. I've tried this in various ways about 20 times and slowly I'm
> corrupting the 6.2 build. I have the install disks but the Upgrade FreeBSD
> detects the /usr/src and refuses to over-write the directory. The make
> commands always finish perfectly. Would someone give this apparent noob a
> hand?

You have misunderstood the purpose of csup/cvsup.  It will upgrade
your source tree and allow you to compile a new kernel and userspace,
but it will not upgrade your system for your.  What you appear to want
to do (binary upgrade) can be accomplished using freebsd-update.  See
the Updating and Upgrading FreeBSD chapter of the FreeBSD Handbook,
particularly the FreeBSD Update section for more details:

http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/updating-upgrading.html

-- Brooks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090105/c68b0957/attachment.pgp
From brooks at freebsd.org  Mon Jan  5 20:26:49 2009
From: brooks at freebsd.org (Brooks Davis)
Date: Mon Jan  5 20:26:57 2009
Subject: cvsup freebsd 6_2 to freebsd 7_1 not upgrading?
In-Reply-To: <20090105193555.GA11721@lor.one-eyed-alien.net>
References: <49600E2E.7070601@avioc.org>
	<3163F769-48B0-4CFC-8842-BBBDDAE78B51@gmail.com>
	<20090105032657.GA1842@cdnetworks.co.kr>
	<4961FACE.4060203@avioc.org> <008b01c96f65$517a9d60$f46fd820$@com>
	<20090105193555.GA11721@lor.one-eyed-alien.net>
Message-ID: <20090105202525.GB11721@lor.one-eyed-alien.net>

OK, now I feel like an idiot, I completely misread the middle of your
e-mail.  You might still want to check out freebsd-update since it's a
lot quicker than rebuilding, but that's not your issue here.

On Mon, Jan 05, 2009 at 01:35:55PM -0600, Brooks Davis wrote:
> [This question would be better to ask on the freebsd-questions list, but see
> below.]
> 
> On Mon, Jan 05, 2009 at 11:41:40AM -0700, Brian Duke wrote:
> > Hello List,
> > I'm trying to upgrade my system from 6_2 to 7_1 and cannot seem to do it.
> > Perhaps I'm missing something. Here is the basic procedure I'm following.
> > 
> > #cp /usr/share/examples/cvsup/standard-supfile /root/stand_sup
> > #vi /root/stand_sup
> > <<<host=CHANGE_ME.freebsd.org
> > >>>host=cvsup15.us.FreeBSD.org
> > <<<tag=RELENG_6_2
> > >>>tag=RELENG_7_1
> > 
> > #cd /usr/src

Was /usr/src empty or populated before you did the initial cvsup?  
If it was populated, you need to adopt it before updating.

http://www.cvsup.org/faq.html#caniadopt

I personally just nuke the old tree in most cases.  If you want to try an
source update, this is probably a good option.

> > #cvsup -g -L2 /root/stand_sup
> > ...
> > #make -j4 buildworld; make -j4 buildkernel; make installkernel

Given a lack of a reboot here, you're lucky cvsup isn't working right.
If it was, you'd mostly likely have an unusable system part way through
the installworld below.

> > ... (come back a hour or so later)
> > #make installworld; reboot
> > 
> > After system is back up log in as root and...
> > 
> > # uname -a
> > FreeBSD lazerus.box201.com 6.2-RELEASE FreeBSD 6.2-RELEASE #0: Fri Jan 12
> > 11:05:30 UTC 2007     root@dessler.cse.buffalo.edu:/usr/obj/usr/src/sys/SMP
> > i386
> > 
> > I cannot understand why this system will not upgrade. Even with the
> > mergemaster -p commands added this system always boots to FreeBSD
> > 6.2-RELEASE. I've tried this in various ways about 20 times and slowly I'm
> > corrupting the 6.2 build. I have the install disks but the Upgrade FreeBSD
> > detects the /usr/src and refuses to over-write the directory. The make
> > commands always finish perfectly. Would someone give this apparent noob a
> > hand?

You might try removing the directory entirely and extracting over it.  You can
also do that manually by cating tall the split files into tar.

-- Brooks

> 
> You have misunderstood the purpose of csup/cvsup.  It will upgrade
> your source tree and allow you to compile a new kernel and userspace,
> but it will not upgrade your system for your.  What you appear to want
> to do (binary upgrade) can be accomplished using freebsd-update.  See
> the Updating and Upgrading FreeBSD chapter of the FreeBSD Handbook,
> particularly the FreeBSD Update section for more details:
> 
> http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/updating-upgrading.html


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090105/600e4f6a/attachment.pgp
From barbara.xxx1975 at libero.it  Mon Jan  5 21:01:52 2009
From: barbara.xxx1975 at libero.it (Barbara)
Date: Mon Jan  5 21:02:00 2009
Subject: R: cvsup freebsd 6_2 to freebsd 7_1 not upgrading?
Message-ID: <6108735.968101231189277098.JavaMail.root@wmail9.libero.it>


>Hello List,
>I'm trying to upgrade my system from 6_2 to 7_1 and cannot seem 
to do it.
>Perhaps I'm missing something. Here is the basic procedure I'm 
following.
>
>#cp /usr/share/examples/cvsup/standard-supfile /root/stand_sup

>#vi /root/stand_sup
><<<host=CHANGE_ME.freebsd.org
>>>>host=cvsup15.us.FreeBSD.
org
><<<tag=RELENG_6_2
>>>>tag=RELENG_7_1
>
>#cd /usr/src
>#cvsup -g -L2 
/root/stand_sup
>...
>#make -j4 buildworld; make -j4 buildkernel; make 
installkernel
>
>... (come back a hour or so later)
>#make installworld; reboot

>

It seems that you have missed to run "mergemaster -p" before, and 
"mergemaster" after running "make installworld".
IMHO, not running mergemaster, 
you have not updated /etc/motd so it shows 6.2...
And, as pointed by Brooks 
Davis you should have rebooted before running make installworld.


From barbara.xxx1975 at libero.it  Mon Jan  5 21:05:12 2009
From: barbara.xxx1975 at libero.it (Barbara)
Date: Mon Jan  5 21:05:19 2009
Subject: cvsup freebsd 6_2 to freebsd 7_1 not upgrading?
Message-ID: <32085272.968201231189478546.JavaMail.root@wmail9.libero.it>



>----Messaggio originale----
>Da: barbara.xxx1975@libero.it
>Data: 05/01/2009 
22.01
>A: <brian@box201.com>, <FreeBSD-stable@FreeBSD.org>
>Ogg: R: cvsup 
freebsd 6_2 to freebsd 7_1 not upgrading?
>
>
>>Hello List,
>>I'm trying to 
upgrade my system from 6_2 to 7_1 and cannot seem 
>to do it.
>>Perhaps I'm 
missing something. Here is the basic procedure I'm 
>following.
>>
>>#cp 
/usr/share/examples/cvsup/standard-supfile /root/stand_sup
>
>>#vi 
/root/stand_sup
>><<<host=CHANGE_ME.freebsd.org
>>>>>host=cvsup15.us.FreeBSD.

>org
>><<<tag=RELENG_6_2
>>>>>tag=RELENG_7_1
>>
>>#cd /usr/src
>>#cvsup -g -L2 

>/root/stand_sup
>>...
>>#make -j4 buildworld; make -j4 buildkernel; make 

>installkernel
>>
>>... (come back a hour or so later)
>>#make installworld; 
reboot
>
>>
>
>It seems that you have missed to run "mergemaster -p" before, 
and 
>"mergemaster" after running "make installworld".
>IMHO, not running 
mergemaster, 
>you have not updated /etc/motd so it shows 6.2...
Obviously 
among the other files.
>And, as pointed by Brooks 
>Davis you should have 
rebooted before running make installworld.
Try also reading the comments in 
/usr/src/Makefile

From brian at box201.com  Mon Jan  5 22:08:35 2009
From: brian at box201.com (Brian Duke)
Date: Mon Jan  5 22:08:42 2009
Subject: cvsup freebsd 6_2 to freebsd 7_1 not upgrading?
In-Reply-To: <32085272.968201231189478546.JavaMail.root@wmail9.libero.it>
References: <32085272.968201231189478546.JavaMail.root@wmail9.libero.it>
Message-ID: <010e01c96f82$252875d0$6f796170$@com>

Forgive me for not being as clear as I should have been. I was trying to be brief.
The original email stated in the paragraph below my procedure...

> I cannot understand why this system will not upgrade. Even with the 
> mergemaster -p commands added this system always boots to FreeBSD 
> 6.2-RELEASE.

I do reboot after the 
#make installkernel
I do run mergemaster;

The fact is I made a critical mistake at the beginning of this endeavor which left me in this condition.

I followed this procedure http://people.freebsd.org/~rse/upgrade/freebsd-upgrade-6x-7x.txt up to the point where I was supposed to change from /usr/src to /usr/adm and type "make update". At that moment I knew I made a mistake not coming from FreeBSD6.4. I got an immediate "Bad system call (core dumped)". I tried to correct the problem by building world and kernel manually. That didn't help. Everything builds find with no visible errors. Since then I've been trying to fix that mistake. Here is an example of what happens during freebsd-update.

# freebsd-update fetch
Looking up update.FreeBSD.org mirrors... Bad system call (core dumped)
none found.
Fetching public key from update.FreeBSD.org... done.
Fetching metadata signature for 6.2-RELEASE from update.FreeBSD.org... done.
Fetching metadata index... done.
Fetching 2 metadata files... done.
Inspecting system... done.
Preparing to download files... done.
Fetching 69 files... failed.
#

csup also does an immediate core dump. That?s why I'm using cvsup. My Perl5.8.8 seems unaffected. I'd like to keep my /usr/home if possible and certain video drivers. That?s why I downloaded and burned new 7.1 CD's to see if the upgrade there would correct my src. The install boots up and says it will not fix my src's and tells me to try cvsup again.

Does "uname -a" only show me the MOTD data? I thought that program was a bit more precise. I've used FreeBSD for years but still consider myself very new. 

My supfile looks like this:
------------------------------------------------
# IMPORTANT: Change the next line to use one of the CVSup mirror sites
# listed at http://www.freebsd.org/doc/handbook/mirrors.html.
*default host=cvsup15.us.FreeBSD.org
*default base=/var/db
*default prefix=/usr
*default release=cvs tag=RELENG_7_1
*default delete use-rel-suffix

# If you seem to be limited by CPU rather than network or disk bandwidth, try
# commenting out the following line.  (Normally, today's CPUs are fast enough
# that you want to run compression.)
*default compress

## Main Source Tree.
#
# The easiest way to get the main source tree is to use the "src-all"
# mega-collection.  It includes all of the individual "src-*" collections.
src-all
---------------------------------------------------------

I've used FreeBSD for years but still consider myself very new. I appreciate the help reminding me to reboot and then make installworld. I should have written the first email a bit clearer.  

agrapha

-----Original Message-----
From: owner-freebsd-stable@freebsd.org [mailto:owner-freebsd-stable@freebsd.org] On Behalf Of Barbara
Sent: Monday, January 05, 2009 2:05 PM
To: brian@box201.com
Cc: FreeBSD-stable@FreeBSD.org
Subject: cvsup freebsd 6_2 to freebsd 7_1 not upgrading?



>----Messaggio originale----
>Da: barbara.xxx1975@libero.it
>Data: 05/01/2009 
22.01
>A: <brian@box201.com>, <FreeBSD-stable@FreeBSD.org>
>Ogg: R: cvsup 
freebsd 6_2 to freebsd 7_1 not upgrading?
>
>
>>Hello List,
>>I'm trying to 
upgrade my system from 6_2 to 7_1 and cannot seem 
>to do it.
>>Perhaps I'm 
missing something. Here is the basic procedure I'm 
>following.
>>
>>#cp 
/usr/share/examples/cvsup/standard-supfile /root/stand_sup
>
>>#vi 
/root/stand_sup
>><<<host=CHANGE_ME.freebsd.org
>>>>>host=cvsup15.us.FreeBSD.

>org
>><<<tag=RELENG_6_2
>>>>>tag=RELENG_7_1
>>
>>#cd /usr/src
>>#cvsup -g -L2 

>/root/stand_sup
>>...
>>#make -j4 buildworld; make -j4 buildkernel; make 

>installkernel
>>
>>... (come back a hour or so later)
>>#make installworld; 
reboot
>
>>
>
>It seems that you have missed to run "mergemaster -p" before, 
and 
>"mergemaster" after running "make installworld".
>IMHO, not running 
mergemaster, 
>you have not updated /etc/motd so it shows 6.2...
Obviously 
among the other files.
>And, as pointed by Brooks 
>Davis you should have 
rebooted before running make installworld.
Try also reading the comments in 
/usr/src/Makefile

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

From rick-freebsd2008 at kiwi-computer.com  Mon Jan  5 22:13:53 2009
From: rick-freebsd2008 at kiwi-computer.com (Rick C. Petty)
Date: Mon Jan  5 22:14:01 2009
Subject: newfs(8) parameters from "dumpfs -m" have bad -s value?
In-Reply-To: <200901051923.n05JNrwt038325@lurza.secnetix.de>
References: <20090102153455.GR4100@albert.catwhisker.org>
	<200901051923.n05JNrwt038325@lurza.secnetix.de>
Message-ID: <20090105221352.GB35524@keira.kiwi-computer.com>

On Mon, Jan 05, 2009 at 08:23:53PM +0100, Oliver Fromme wrote:
> 
> This seems to be a bug in dumpfs(8).  It simply prints
> the value of the fs_size field of the superblock, which
> is wrong.
> 
> The -s option of newfs(8) expects the available size in
> sectors (i.e. 512 bytes), but the fs_size field contains
> the size of the file system in 2KB units.  This seems to
> be the fragment size, but I'm not sure if this is just

This *is* the fragment size.  UFS/FFS uses the plain term "block" to mean
the fragment size.  All blocks are indexed with this number, unlike "block
size" which is almost always 8 fragments ("blocks").  Confusing.

> So, dumpfs(8) needs to be fixed to perform the proper
> calculations when printing the value for the -s option.
> Unfortunately I'm not sufficiently much of a UFS guru
> to offer a fix.  My best guess would be to multiply the
> fs_size value by the fragment size (measured in 512 byte
> units), i.e. multiply by 4 in the most common case.
> But I'm afraid the real solution is not that simple.

The sector size and filesystem size parameters in newfs are remnants.
Everything is converted to number of media sectors (sector size as
specified by the device).  So one could assume for dumpfs to always use
512, since it's rarely different, and multiply fs_size by fs_fsize and
divide by 512, and then output "-S 512".

Better yet would be to add a parameter ("-z" perhaps) to newfs(8) to accept
number of bytes instead of multiples of sectorsize.

I would be willing to write up patches for dumpfs and newfs to both add the
raw byte size and the 512-byte sector size handling to correct said
mistake, unless someone else would rather.

-- Rick C. Petty
From mav at FreeBSD.org  Mon Jan  5 22:13:56 2009
From: mav at FreeBSD.org (Alexander Motin)
Date: Mon Jan  5 22:14:11 2009
Subject: HEADS UP: snd_hda MFC plan
Message-ID: <49628626.40202@FreeBSD.org>

If there will be no objections, I am going to merge latest snd_hda 
driver from HEAD to 7-STABLE next days. Driver was extensively tested by 
many people with numerous hardware on both HEAD and 7-STABLE and 
provides many significant benefits. Discussions can be found on 
multimedia@ list.

The most user-visible difference, is that new driver often provides 
several audio devices even on simple systems. That devices refer the 
different physical or logical audio hardware parts and using different 
hardware connectors. This feature described in details in updated man page.

On most systems having several devices is not a problem, as mostly used 
analog connectors are usually detected first. But on some systems (for 
example, having separate HDMI ports on video cards, which are now also 
supported and often detected first), user may be required to explicitly 
configure his audio applications or by using hw.snd.default_unit sysctl 
globally specify default audio device he wants to use. This moment 
explicitly specified in updated man page and I am going to specify it in 
UPDATING.

-- 
Alexander Motin
From l1nyx01d at googlemail.com  Mon Jan  5 22:18:48 2009
From: l1nyx01d at googlemail.com (L1NYX01D@GOOGLEMAIL.COM)
Date: Mon Jan  5 22:18:56 2009
Subject: FreeBSD6.2 to 7.1 Remote update
Message-ID: <475202416.20090106005232@gmail.com>

????????????, FreeBSD-stable.

It's real?
I have one server with hard to access physically.

Can I update him to new release over ssh only?


-- 
? ?????????,
 L1NYX01D                          mailto:l1nyx01d@googlemail.com

From rick-freebsd2008 at kiwi-computer.com  Mon Jan  5 22:20:54 2009
From: rick-freebsd2008 at kiwi-computer.com (Rick C. Petty)
Date: Mon Jan  5 22:21:01 2009
Subject: cvsup freebsd 6_2 to freebsd 7_1 not upgrading?
In-Reply-To: <008b01c96f65$517a9d60$f46fd820$@com>
References: <49600E2E.7070601@avioc.org>
	<3163F769-48B0-4CFC-8842-BBBDDAE78B51@gmail.com>
	<20090105032657.GA1842@cdnetworks.co.kr>
	<4961FACE.4060203@avioc.org> <008b01c96f65$517a9d60$f46fd820$@com>
Message-ID: <20090105215412.GA35524@keira.kiwi-computer.com>

On Mon, Jan 05, 2009 at 11:41:40AM -0700, Brian Duke wrote:
> 
> #cp /usr/share/examples/cvsup/standard-supfile /root/stand_sup
> #vi /root/stand_sup
> <<<host=CHANGE_ME.freebsd.org
> >>>host=cvsup15.us.FreeBSD.org
> <<<tag=RELENG_6_2
> >>>tag=RELENG_7_1
> 
> #cd /usr/src
> #cvsup -g -L2 /root/stand_sup
> ...
> #make -j4 buildworld; make -j4 buildkernel; make installkernel
> 
> ... (come back a hour or so later)
> #make installworld; reboot

You should always reboot into the new kernel before running the install
world, especially if updating the major version.  I always boot into
single-user to do my install world, although a new kernel should work with
old userland.  Although this isn't your problem.  You should see the
kernel's version at boot time (and through uname(1)), so somehow you're not
installing the kernel.  I'd probably change your line to:

make -j4 buildworld buildkernel && make installkernel

or just:

make -j4 buildworld kernel && echo "success"

-- Rick C. Petty
From brooks at freebsd.org  Mon Jan  5 22:33:40 2009
From: brooks at freebsd.org (Brooks Davis)
Date: Mon Jan  5 22:33:47 2009
Subject: cvsup freebsd 6_2 to freebsd 7_1 not upgrading?
In-Reply-To: <010e01c96f82$252875d0$6f796170$@com>
References: <32085272.968201231189478546.JavaMail.root@wmail9.libero.it>
	<010e01c96f82$252875d0$6f796170$@com>
Message-ID: <20090105223216.GE11721@lor.one-eyed-alien.net>

On Mon, Jan 05, 2009 at 03:08:01PM -0700, Brian Duke wrote:
> Forgive me for not being as clear as I should have been. I was trying to be brief.
> The original email stated in the paragraph below my procedure...
> 
> > I cannot understand why this system will not upgrade. Even with the 
> > mergemaster -p commands added this system always boots to FreeBSD 
> > 6.2-RELEASE.
> 
> I do reboot after the 
> #make installkernel
> I do run mergemaster;
> 
> The fact is I made a critical mistake at the beginning of this
> endeavor which left me in this condition.
> 
> I followed this procedure
> http://people.freebsd.org/~rse/upgrade/freebsd-upgrade-6x-7x.txt up
> to the point where I was supposed to change from /usr/src to /usr/adm
> and type "make update". At that moment I knew I made a mistake not
> coming from FreeBSD6.4. I got an immediate "Bad system call (core
> dumped)". I tried to correct the problem by building world and kernel
> manually. That didn't help. Everything builds find with no visible
> errors. Since then I've been trying to fix that mistake. Here is an
> example of what happens during freebsd-update.
>
> # freebsd-update fetch
> Looking up update.FreeBSD.org mirrors... Bad system call (core dumped)
> none found.
> Fetching public key from update.FreeBSD.org... done.
> Fetching metadata signature for 6.2-RELEASE from update.FreeBSD.org... done.
> Fetching metadata index... done.
> Fetching 2 metadata files... done.
> Inspecting system... done.
> Preparing to download files... done.
> Fetching 69 files... failed.
> #
> 
> csup also does an immediate core dump. That???s why I'm using
> cvsup. My Perl5.8.8 seems unaffected. I'd like to keep my /usr/home
> if possible and certain video drivers. That???s why I downloaded and
> burned new 7.1 CD's to see if the upgrade there would correct my
> src. The install boots up and says it will not fix my src's and tells
> me to try cvsup again.

Since it looks like your supfile below is OK, you might try blowing away
/usr/src and the contents of /var/db/sup and trying again.  Assuming
none of the build binaries are 6.4 or 7.1 dependent, you may be able to
recover from a clean tree.  Otherwise, it looks like you'll need to do a
manual refresh of 6.2 from the CD or reinstall.  A back up of key data and
reinstall may well be fastest at this point.

> Does "uname -a" only show me the MOTD data? I thought that program was
> a bit more precise. I've used FreeBSD for years but still consider
> myself very new.

uname -a returns the versions string it gets from the kernel so it
should be accurate. /etc/motd is updated at boot using the output of
uname.

> My supfile looks like this:
> ------------------------------------------------
> # IMPORTANT: Change the next line to use one of the CVSup mirror sites
> # listed at http://www.freebsd.org/doc/handbook/mirrors.html.
> *default host=cvsup15.us.FreeBSD.org
> *default base=/var/db
> *default prefix=/usr
> *default release=cvs tag=RELENG_7_1
> *default delete use-rel-suffix
> 
> # If you seem to be limited by CPU rather than network or disk bandwidth, try
> # commenting out the following line.  (Normally, today's CPUs are fast enough
> # that you want to run compression.)
> *default compress
> 
> ## Main Source Tree.
> #
> # The easiest way to get the main source tree is to use the "src-all"
> # mega-collection.  It includes all of the individual "src-*" collections.
> src-all
> ---------------------------------------------------------
> 
> I've used FreeBSD for years but still consider myself very
> new. I appreciate the help reminding me to reboot and then make
> installworld. I should have written the first email a bit clearer.
> 
> agrapha
> 
> -----Original Message-----
> From: owner-freebsd-stable@freebsd.org [mailto:owner-freebsd-stable@freebsd.org] On Behalf Of Barbara
> Sent: Monday, January 05, 2009 2:05 PM
> To: brian@box201.com
> Cc: FreeBSD-stable@FreeBSD.org
> Subject: cvsup freebsd 6_2 to freebsd 7_1 not upgrading?
> 
> 
> 
> >----Messaggio originale----
> >Da: barbara.xxx1975@libero.it
> >Data: 05/01/2009 
> 22.01
> >A: <brian@box201.com>, <FreeBSD-stable@FreeBSD.org>
> >Ogg: R: cvsup 
> freebsd 6_2 to freebsd 7_1 not upgrading?
> >
> >
> >>Hello List,
> >>I'm trying to 
> upgrade my system from 6_2 to 7_1 and cannot seem 
> >to do it.
> >>Perhaps I'm 
> missing something. Here is the basic procedure I'm 
> >following.
> >>
> >>#cp 
> /usr/share/examples/cvsup/standard-supfile /root/stand_sup
> >
> >>#vi 
> /root/stand_sup
> >><<<host=CHANGE_ME.freebsd.org
> >>>>>host=cvsup15.us.FreeBSD.
> 
> >org
> >><<<tag=RELENG_6_2
> >>>>>tag=RELENG_7_1
> >>
> >>#cd /usr/src
> >>#cvsup -g -L2 
> 
> >/root/stand_sup
> >>...
> >>#make -j4 buildworld; make -j4 buildkernel; make 
> 
> >installkernel
> >>
> >>... (come back a hour or so later)
> >>#make installworld; 
> reboot
> >
> >>
> >
> >It seems that you have missed to run "mergemaster -p" before, 
> and 
> >"mergemaster" after running "make installworld".
> >IMHO, not running 
> mergemaster, 
> >you have not updated /etc/motd so it shows 6.2...
> Obviously 
> among the other files.
> >And, as pointed by Brooks 
> >Davis you should have 
> rebooted before running make installworld.
> Try also reading the comments in 
> /usr/src/Makefile
> 
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
> 
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090105/ecbdc5d9/attachment.pgp
From brooks at freebsd.org  Mon Jan  5 22:35:11 2009
From: brooks at freebsd.org (Brooks Davis)
Date: Mon Jan  5 22:35:18 2009
Subject: FreeBSD6.2 to 7.1 Remote update
In-Reply-To: <475202416.20090106005232@gmail.com>
References: <475202416.20090106005232@gmail.com>
Message-ID: <20090105223355.GF11721@lor.one-eyed-alien.net>

On Tue, Jan 06, 2009 at 12:52:32AM +0300, L1NYX01D@GOOGLEMAIL.COM wrote:
> ????????????, FreeBSD-stable.
> 
> It's real?
> I have one server with hard to access physically.
> 
> Can I update him to new release over ssh only?

It's quite possible if you're careful, but there are plenty of ways to
do it wrong.  Make sure to reading the upgrading documentation and the
release notes carefully (especially if you have em* network interfaces).

-- Brooks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090105/404c7456/attachment.pgp
From rsmith at xs4all.nl  Mon Jan  5 22:44:48 2009
From: rsmith at xs4all.nl (Roland Smith)
Date: Mon Jan  5 22:44:57 2009
Subject: Samsung SCX-4200 printer
In-Reply-To: <20090105164403.GE3756@trusted-logic.com>
References: <20090104221422.GA3114@pollux2.free.local.net>
	<20090105173635.575e32ff.torfinn.ingolfsen@broadpark.no>
	<20090105164403.GE3756@trusted-logic.com>
Message-ID: <20090105222623.GA52838@slackbox.xs4all.nl>

On Mon, Jan 05, 2009 at 05:44:03PM +0100, Erwan David wrote:
> On Mon, Jan 05, 2009 at 05:36:35PM CET, Torfinn Ingolfsen <torfinn.ingolfsen@broadpark.no> said:
> > On Sun, 04 Jan 2009 23:14:22 +0100
> > Harald Weis <hawei@free.fr> wrote:
> > 
> > > Is there a way to install the SCX-4200 printer on a FreeBSD box ?
> > > The printer is delivered with the install software required for Linux.
> > > And CUPS does not seem to "know" it.
> > 
> > As always, check OpenPrinting.org first:
> > http://openprinting.org/show_printer.cgi?recnum=Samsung-SCX-4200
> > 
> 
> It is not always sufficient. My Brother DCP-540 CN is said to work
> perfectly, but only with brother binary linux drivers, under linux. I
> did not find any way to make it work under freeBSD.

This should be a FAQ: do yourself a favor and get a printer that
supports postscript. It will work with little effort with most
UNIX-based program (because they usually support postscript output) and
with most spoolers.

A postscript printer is probably a bit more expensive than others, but
if your printer doesn't work it doesn't matter how affordable is was; it
is just an expensive paperweight.

Roland
-- 
R.F.Smith                                   http://www.xs4all.nl/~rsmith/
[plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated]
pgp: 1A2B 477F 9970 BA3C 2914  B7CE 1277 EFB0 C321 A725 (KeyID: C321A725)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090105/fbbd92e6/attachment.pgp
From eitanadlerlist at gmail.com  Mon Jan  5 23:07:35 2009
From: eitanadlerlist at gmail.com (Eitan Adler)
Date: Mon Jan  5 23:07:42 2009
Subject: buildworld failure on SSH Makefile
Message-ID: <49628D2B.4090306@gmail.com>

When I do
make -DNO_PROFILE buildworld revision 186797 from svn
I get

==> secure/usr.bin/ssh-agent (cleandir)
rm -f ssh-agent ssh-agent.o ssh-agent.1.gz ssh-agent.1.cat.gz
rm -f .depend GPATH GRTAGS GSYMS GTAGS
===> secure/usr.bin/ssh-keygen (cleandir)
rm -f ssh-keygen ssh-keygen.o ssh-keygen.1.gz ssh-keygen.1.cat.gz
rm -f .depend GPATH GRTAGS GSYMS GTAGS
===> secure/usr.bin/ssh-keyscan (cleandir)
rm -f ssh-keyscan ssh-keyscan.o ssh-keyscan.1.gz ssh-keyscan.1.cat.gz
rm -f .depend GPATH GRTAGS GSYMS GTAGS
===> secure/usr.sbin (cleandir)
===> secure/usr.sbin/sshd (cleandir)
rm -f sshd sshd.o auth-rhosts.o auth-passwd.o auth-rsa.o auth-rh-rsa.o
sshpty.o

sshlogin.o servconf.o serverloop.o auth.o auth1.o auth2.o auth-options.o
session

.o auth-chall.o auth2-chall.o groupaccess.o auth-skey.o auth-bsdauth.o
auth2-hos

tbased.o auth2-kbdint.o auth2-none.o auth2-passwd.o auth2-pubkey.o
monitor_mm.o

monitor.o monitor_wrap.o kexdhs.o kexgexs.o auth-krb5.o auth2-gss.o
gss-serv.o g

ss-serv-krb5.o loginrec.o auth-pam.o auth-shadow.o auth-sia.o md5crypt.o
audit.o

 audit-bsm.o platform.o sftp-server.o sftp-common.o gss-genr.o sshd.8.gz
sshd_co

nfig.5.gz sshd.8.cat.gz sshd_config.5.cat.gz
rm -f .depend GPATH GRTAGS GSYMS GTAGS
===> share (cleandir)
"Makefile", line 1: Need an operator
make: fatal errors encountered -- cannot continue
*** Error code 1

Stop in /home/src/mysrc/local.
*** Error code 1

Stop in /home/src/mysrc/local.
*** Error code 1

Stop in /home/src/mysrc/local.


-- 
Eitan Adler
"Security is increased by designing for the way humans actually behave."
-Jakob Nielsen
From rizzo at iet.unipi.it  Mon Jan  5 23:18:58 2009
From: rizzo at iet.unipi.it (Luigi Rizzo)
Date: Mon Jan  5 23:19:05 2009
Subject: Samsung SCX-4200 printer
In-Reply-To: <20090105222623.GA52838@slackbox.xs4all.nl>
References: <20090104221422.GA3114@pollux2.free.local.net>
	<20090105173635.575e32ff.torfinn.ingolfsen@broadpark.no>
	<20090105164403.GE3756@trusted-logic.com>
	<20090105222623.GA52838@slackbox.xs4all.nl>
Message-ID: <20090105232354.GA85619@onelab2.iet.unipi.it>

On Mon, Jan 05, 2009 at 11:26:23PM +0100, Roland Smith wrote:
> On Mon, Jan 05, 2009 at 05:44:03PM +0100, Erwan David wrote:
> > On Mon, Jan 05, 2009 at 05:36:35PM CET, Torfinn Ingolfsen <torfinn.ingolfsen@broadpark.no> said:
> > > On Sun, 04 Jan 2009 23:14:22 +0100
> > > Harald Weis <hawei@free.fr> wrote:
> > > 
> > > > Is there a way to install the SCX-4200 printer on a FreeBSD box ?
> > > > The printer is delivered with the install software required for Linux.
> > > > And CUPS does not seem to "know" it.
...
> > It is not always sufficient. My Brother DCP-540 CN is said to work
> > perfectly, but only with brother binary linux drivers, under linux. I
> > did not find any way to make it work under freeBSD.
> 
> This should be a FAQ: do yourself a favor and get a printer that
> supports postscript. It will work with little effort with most
> UNIX-based program (because they usually support postscript output) and
> with most spoolers.

Actually, this is debatable. If everybody were following your
suggestion we wouldn't have support for a lot of devices (printers,
disk controllers, scanners, wireless and network devices, embedded
systems) that now do work with FreeBSD or other Open Source systems.

We are talking about a 70euro laser printer here -- it is not
unreasonable to take a bit of a risk and try it out, and it is also
good for the community to have people willing to test new hardware
and report success or failure.

	cheers
	luigi
From alex-goncharov at comcast.net  Tue Jan  6 00:14:20 2009
From: alex-goncharov at comcast.net (Alex Goncharov)
Date: Tue Jan  6 00:14:27 2009
Subject: Samsung SCX-4200 printer
In-Reply-To: <20090105232354.GA85619@onelab2.iet.unipi.it> (message from Luigi
	Rizzo on Tue, 6 Jan 2009 00:23:54 +0100)
References: <20090104221422.GA3114@pollux2.free.local.net>
	<20090105173635.575e32ff.torfinn.ingolfsen@broadpark.no>
	<20090105164403.GE3756@trusted-logic.com>
	<20090105222623.GA52838@slackbox.xs4all.nl>
	<20090105232354.GA85619@onelab2.iet.unipi.it>
Message-ID: <E1LJzNW-000OQZ-K4@daland.home>

On Mon, Jan 05, 2009 at 11:26:23PM +0100, Roland Smith wrote:
> On Mon, Jan 05, 2009 at 05:44:03PM +0100, Erwan David wrote:
> > On Mon, Jan 05, 2009 at 05:36:35PM CET, Torfinn Ingolfsen <torfinn.ingolfsen@broadpark.no> said:
> > > On Sun, 04 Jan 2009 23:14:22 +0100
> > > Harald Weis <hawei@free.fr> wrote:
> > > 
> > > > Is there a way to install the SCX-4200 printer on a FreeBSD box ?
> > > > The printer is delivered with the install software required for Linux.
> > > > And CUPS does not seem to "know" it.
> > It is not always sufficient. My Brother DCP-540 CN is said to work
> > perfectly, but only with brother binary linux drivers, under linux. I
> > did not find any way to make it work under freeBSD.
> 
> This should be a FAQ: do yourself a favor and get a printer that
> supports postscript. It will work with little effort with most
> UNIX-based program (because they usually support postscript output) and
> with most spoolers.

Try to install the cupsys, cupsys-bsd, cupsomatic-ppd and foomatic-db
ports and take a look at this link:

   http://forums.linux-foundation.org/read.php?31,302,320,quote=1

-- Alex -- alex-goncharov@comcast.net --
From terry at tmk.com  Tue Jan  6 02:51:16 2009
From: terry at tmk.com (Terry Kennedy)
Date: Tue Jan  6 02:51:22 2009
Subject: rdump stuck in sbwait state (RELENG_7)
In-Reply-To: "Your message dated Mon, 05 Jan 2009 14:16:57 +0000 (GMT)"
	<alpine.BSF.2.00.0901051411240.98366@fledge.watson.org>
References: <01N3OFGBCXMS000125@tmk.com> <01N3OYSUCHAE000125@tmk.com>
	<01N3VGDZ7EOM0008L3@tmk.com> <01N3XI0VWEA00008L3@tmk.com>
Message-ID: <01N3YA1PE7BE0008L3@tmk.com>

> Could I ask you to also send me procstat -f output?

  Sure:

(0:37) test4:/usr/src# procstat -f 4436
  PID COMM               FD T V FLAGS    REF  OFFSET PRO NAME        
 4436 rdump             cwd v d --------   -       - -   /tmp              
 4436 rdump            root v d --------   -       - -   /                 
 4436 rdump               0 v c rw------  31    7762 -   -                 
 4436 rdump               1 v c rw------  31    7762 -   -                 
 4436 rdump               2 v c rw------  31    7762 -   -                 
 4436 rdump               3 s - rw------   6       0 TCP 204.141.35.11:892 204.141.35.63:514
 4436 rdump               4 v r r-------   2       0 -   -                 
 4436 rdump               5 s - rw------   5       0 TCP 204.141.35.11:770 204.141.35.63:1020
(0:38) test4:/usr/src# procstat -f 4439
  PID COMM               FD T V FLAGS    REF  OFFSET PRO NAME        
 4439 rdump             cwd v d --------   -       - -   /tmp              
 4439 rdump            root v d --------   -       - -   /                 
 4439 rdump               0 v c rw------  31    7762 -   -                 
 4439 rdump               1 v c rw------  31    7762 -   -                 
 4439 rdump               2 v c rw------  31    7762 -   -                 
 4439 rdump               3 s - rw------   6       0 TCP 204.141.35.11:892 204.141.35.63:514
 4439 rdump               4 v r r-------   2       0 -   -                 
 4439 rdump               5 s - rw------   5       0 TCP 204.141.35.11:770 204.141.35.63:1020
 4439 rdump               6 s - rw------   4       0 UDS -
 4439 rdump               7 s - rw------   1       0 UDS -
 4439 rdump               8 s - rw------   3       0 UDS -
 4439 rdump               9 s - rw------   1       0 UDS -
 4439 rdump              10 s - rw------   2       0 UDS -
 4439 rdump              11 s - rw------   2       0 UDS -
(0:39) test4:/usr/src# procstat -f 4440
  PID COMM               FD T V FLAGS    REF  OFFSET PRO NAME        
 4440 rdump             cwd v d --------   -       - -   /tmp              
 4440 rdump            root v d --------   -       - -   /                 
 4440 rdump               0 v c rw------  31    7762 -   -                 
 4440 rdump               1 v c rw------  31    7762 -   -                 
 4440 rdump               2 v c rw------  31    7762 -   -                 
 4440 rdump               3 s - rw------   6       0 TCP 204.141.35.11:892 204.141.35.63:514
 4440 rdump               4 v c r-------   1       0 -   -                 
 4440 rdump               5 s - rw------   5       0 TCP 204.141.35.11:770 204.141.35.63:1020
 4440 rdump               6 s - rw------   4       0 UDS -
(0:40) test4:/usr/src# procstat -f 4441
  PID COMM               FD T V FLAGS    REF  OFFSET PRO NAME        
 4441 rdump             cwd v d --------   -       - -   /tmp              
 4441 rdump            root v d --------   -       - -   /                 
 4441 rdump               0 v c rw------  31    7762 -   -                 
 4441 rdump               1 v c rw------  31    7762 -   -                 
 4441 rdump               2 v c rw------  31    7762 -   -                 
 4441 rdump               3 s - rw------   6       0 TCP 204.141.35.11:892 204.141.35.63:514
 4441 rdump               4 v c r-------   1       0 -   -                 
 4441 rdump               5 s - rw------   5       0 TCP 204.141.35.11:770 204.141.35.63:1020
 4441 rdump               6 s - rw------   4       0 UDS -
 4441 rdump               8 s - rw------   3       0 UDS -
(0:41) test4:/usr/src# procstat -f 4442
  PID COMM               FD T V FLAGS    REF  OFFSET PRO NAME        
 4442 rdump             cwd v d --------   -       - -   /tmp              
 4442 rdump            root v d --------   -       - -   /                 
 4442 rdump               0 v c rw------  31    7762 -   -                 
 4442 rdump               1 v c rw------  31    7762 -   -                 
 4442 rdump               2 v c rw------  31    7762 -   -                 
 4442 rdump               3 s - rw------   6       0 TCP 204.141.35.11:892 204.141.35.63:514
 4442 rdump               4 v c r-------   1       0 -   -                 
 4442 rdump               5 s - rw------   5       0 TCP 204.141.35.11:770 204.141.35.63:1020
 4442 rdump               6 s - rw------   4       0 UDS -
 4442 rdump               8 s - rw------   3       0 UDS -
 4442 rdump              10 s - rw------   2       0 UDS -

> In general, being blocked in soreceive() means that the application at the
> other end hasn't sent data, or the other end hasn't received or correctly
> processed ACKs from the local end, so isn't sending more data that it has
> queued up.  The condition you describe sounds more like what would happen in a
> sender: that it has data to send, but the remote side hasn't ACK'd
> sufficiently to send it all.

  Looking at the tcpdump capture at http://www.tmk.com/transient/rdump30.gz,
I think everything has been ack'd by the other side.

>  If you have kgdb handy, it would be useful to
> look at *so and *so->so_domain in the soreceive_generic frame of proc 4439.
> If it's an inet socket, we'd like to see *(struct inpcb *)so->so_pcb, and if
> it's a TCP socket, *(struct tcpcb *)((struct inpcb *)so->so_pcb)->inp_ppcb.

  Sorry, you lost me here. Can you give me detailed instructions on how to
examine this data? I got as far as "proc 4439" in kgdb, but then got lost.

	Thanks,
        Terry Kennedy             http://www.tmk.com
        terry@tmk.com             New York, NY USA
From chris at arnold.se  Tue Jan  6 03:43:42 2009
From: chris at arnold.se (Christopher Arnold)
Date: Tue Jan  6 03:44:23 2009
Subject: FreeBSD6.2 to 7.1 Remote update
In-Reply-To: <475202416.20090106005232@gmail.com>
References: <475202416.20090106005232@gmail.com>
Message-ID: <alpine.BSF.2.00.0901060413000.7423@localhost>



On Tue, 6 Jan 2009, L1NYX01D@GOOGLEMAIL.COM wrote:

> ????????????, FreeBSD-stable.
>
> It's real?
> I have one server with hard to access physically.
>
> Can I update him to new release over ssh only?
>
Be carefull...

I did such an update some time ago and had some problems with ssh not 
working. And then no access to the system...

I THINK that thoose problems would have been avioded if i would have 
enabled telnet access to the system before doing the upgrade.

I have some notes somewhere that was supposed to become a blog entry, that 
i never got around to writing.

I'll look into then and se what i can suggest to you, and please feel free 
to mail me directly if you want some more information.


 	/Chris

--
http://www.arnold.se/chris/
From ericlin at tamama.org  Tue Jan  6 04:25:09 2009
From: ericlin at tamama.org (Lin Jui-Nan Eric)
Date: Tue Jan  6 04:25:22 2009
Subject: TCP packet out-of-order problem
In-Reply-To: <alpine.BSF.2.00.0901051312370.98366@fledge.watson.org>
References: <47713ee10812301206j12b35264o715976c154080a1b@mail.gmail.com>
	<47713ee10901012147k1f25c31bn512dd29b2b294ad5@mail.gmail.com>
	<47713ee10901012249w65c659bbp3366e4d8ef25c59d@mail.gmail.com>
	<alpine.BSF.2.00.0901051312370.98366@fledge.watson.org>
Message-ID: <47713ee10901052025y26d342f6me0aea946a49b6f0a@mail.gmail.com>

Hi Robert,

I thought that the system auto-tune improperly in this case.

On Mon, Jan 5, 2009 at 9:13 PM, Robert Watson <rwatson@freebsd.org> wrote:
> On Fri, 2 Jan 2009, Lin Jui-Nan Eric wrote:
>
>> After running "netstat -s -p tcp", we found that lots of packets are
>> discarded due to memory problems. We googled for it, and found that sysctl
>> oid "net.inet.tcp.reass.maxsegments" became 0, therefore packets never
>> reassembled.
>>
>> Then we checked our /boot/loader.conf and /etc/sysctl.conf, and found that
>> setting kern.ipc.nmbclusters="0" makes net.inet.tcp.reass.maxsegments=0.
>> After setting net.inet.tcp.reass.maxsegments="1600" in /boot/loader.conf,
>> the network works perfectly now.
>
> Was it set to 0 through a configuration error, or did the system auto-tune
> improperly?
>
> Robert N M Watson
> Computer Laboratory
> University of Cambridge
>
>>
>> Thank you all for the help!
>> _______________________________________________
>> freebsd-stable@freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
>> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
>>
>
From bc979 at lafn.org  Tue Jan  6 05:24:52 2009
From: bc979 at lafn.org (Doug Hardie)
Date: Tue Jan  6 05:24:58 2009
Subject: 7.1 Live Filesystem CD
Message-ID: <75412669-8781-4E77-9651-6F6EED2E48F4@lafn.org>

Is the Live Filesystem CD supposed to be bootable?  7.0's was but I  
can't get the 7.1 disc to boot.  It works fine if I boot from CD 1 and  
then switch.
From david at catwhisker.org  Tue Jan  6 06:19:10 2009
From: david at catwhisker.org (David Wolfskill)
Date: Tue Jan  6 06:19:16 2009
Subject: newfs(8) parameters from "dumpfs -m" have bad -s value?
In-Reply-To: <200901051923.n05JNrwt038325@lurza.secnetix.de>
References: <20090102153455.GR4100@albert.catwhisker.org>
	<200901051923.n05JNrwt038325@lurza.secnetix.de>
Message-ID: <20090106054907.GP4100@albert.catwhisker.org>

On Mon, Jan 05, 2009 at 08:23:53PM +0100, Oliver Fromme wrote:
> ...
>  > pool10(7.1-RC1)[36] dumpfs -m /dev/da1s1d
>  > # newfs command for /dev/da1s1d (/dev/da1s1d)
>  > newfs -O 2 -U -a 8 -b 16384 -d 16384 -e 2048 -f 2048 -g 16384 -h 64 -m 8 -o time -s 879031908 /dev/da1s1d 
> 
> This seems to be a bug in dumpfs(8).  It simply prints
> the value of the fs_size field of the superblock, which
> is wrong.
> 
> The -s option of newfs(8) expects the available size in
> sectors (i.e. 512 bytes), but the fs_size field contains
> the size of the file system in 2KB units.  This seems to
> be the fragment size, but I'm not sure if this is just
> coincidence (the docs state that it's the size in blocks,
> but this is misleading because the blocksize is usually
> different; the default is 16K).
> 
> So, dumpfs(8) needs to be fixed to perform the proper
> calculations when printing the value for the -s option.
> Unfortunately I'm not sufficiently much of a UFS guru
> to offer a fix.  My best guess would be to multiply the
> fs_size value by the fragment size (measured in 512 byte
> units), i.e. multiply by 4 in the most common case.
> But I'm afraid the real solution is not that simple.

Empirically, I find that -- at least in the case in question -- using
the superblock's dsize, multiplied by 2, gets the correct result:

Filesystem  1024-blocks Used      Avail Capacity  Mounted on
/dev/da1s1d  1702753030 2744 1566530044     0%    /b

Extract from "ffsinfo -l 1":

===== END CYLINDER SUMMARY TOTAL =====
time              ufs_time_t       1231206211
size              int64_t          0x000000003464f664
dsize             int64_t          0x0000000032bef983
csaddr            ufs2_daddr_t     0x0000000000000bb8

A bit of messing about with dc(1):

g1-35(6.4-S)[4] dc
16
i
32BEF983
2
*
p
1702753030
g1-35(6.4-S)[5] 

Then again, it isn't especially common in my experience to want a file
system that occupies an amount of space different from the amount that
is available for the file system (e.g., the partition size).  So if that
were wanted, providing a way to have dumpfs(8) merely make no claims
whatsoever about or for the newfs(8) "-s" parameter might be adequate.

My circumvention of piping the result through sed(1) accomplishes that,
at some additional complexity and potential confusion.

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-stable/attachments/20090106/5cdda835/attachment.pgp
From Alexander at Leidinger.net  Tue Jan  6 06:25:30 2009
From: Alexander at Leidinger.net (Alexander Leidinger)
Date: Tue Jan  6 06:25:37 2009
Subject: HEADS UP: snd_hda MFC plan
In-Reply-To: <49628626.40202@FreeBSD.org>
References: <49628626.40202@FreeBSD.org>
Message-ID: <20090106072511.16463froljaeoy80@webmail.leidinger.net>

Quoting Alexander Motin <mav@FreeBSD.org> (from Tue, 06 Jan 2009  
00:13:58 +0200):

> On most systems having several devices is not a problem, as mostly  
> used analog connectors are usually detected first. But on some  
> systems (for example, having separate HDMI ports on video cards,  
> which are now also supported and often detected first), user may be  
> required to explicitly configure his audio applications or by using  
> hw.snd.default_unit sysctl globally specify default audio device he  
> wants to use. This moment explicitly specified in updated man page  
> and I am going to specify it in UPDATING.

Is there a way to move those HDMI ports to the end (either in pcmX or  
in the probing) somehow? If yes, it would be more POLA to do this  
instead of requiring the users to do something.

And related: do all detected analog ports appear in a sensible order?  
What I mean is again POLA related. If someone updates from 7.1 to 7.2,  
will he be required to do something to get sound out of the same  
connector as before when connecting to the default audio device? If  
not, is it possible for you to introduce some corresponding sorting  
before MFCing?

Bye,
Alexander.

-- 
The more data I punch in this card, the lighter it becomes, and the
lower the mailing cost.
		-- Stan Kelly-Bootle, "The Devil's DP Dictionary"

http://www.Leidinger.net    Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org       netchild @ FreeBSD.org  : PGP ID = 72077137
From danny at cs.huji.ac.il  Tue Jan  6 06:51:23 2009
From: danny at cs.huji.ac.il (Danny Braniss)
Date: Tue Jan  6 06:51:30 2009
Subject: newfs(8) parameters from "dumpfs -m" have bad -s value? 
In-Reply-To: <20090105221352.GB35524@keira.kiwi-computer.com> 
References: <20090102153455.GR4100@albert.catwhisker.org> 
	<200901051923.n05JNrwt038325@lurza.secnetix.de>
	<20090105221352.GB35524@keira.kiwi-computer.com>
Message-ID: <E1LK5mY-0008AF-R5@kabab.cs.huji.ac.il>

> On Mon, Jan 05, 2009 at 08:23:53PM +0100, Oliver Fromme wrote:
> > 
> > This seems to be a bug in dumpfs(8).  It simply prints
> > the value of the fs_size field of the superblock, which
> > is wrong.
> > 
> > The -s option of newfs(8) expects the available size in
> > sectors (i.e. 512 bytes), but the fs_size field contains
> > the size of the file system in 2KB units.  This seems to
> > be the fragment size, but I'm not sure if this is just
> 
> This *is* the fragment size.  UFS/FFS uses the plain term "block" to mean
> the fragment size.  All blocks are indexed with this number, unlike "block
> size" which is almost always 8 fragments ("blocks").  Confusing.
> 
> > So, dumpfs(8) needs to be fixed to perform the proper
> > calculations when printing the value for the -s option.
> > Unfortunately I'm not sufficiently much of a UFS guru
> > to offer a fix.  My best guess would be to multiply the
> > fs_size value by the fragment size (measured in 512 byte
> > units), i.e. multiply by 4 in the most common case.
> > But I'm afraid the real solution is not that simple.
> 
> The sector size and filesystem size parameters in newfs are remnants.
> Everything is converted to number of media sectors (sector size as
> specified by the device).  So one could assume for dumpfs to always use
> 512, since it's rarely different, and multiply fs_size by fs_fsize and
> divide by 512, and then output "-S 512".
> 

don't assume 512, in the iscsi world I have seen all kinds of sector sizes,
making it a PITA to get things right.

> Better yet would be to add a parameter ("-z" perhaps) to newfs(8) to accept
> number of bytes instead of multiples of sectorsize.
> 
> I would be willing to write up patches for dumpfs and newfs to both add the
> raw byte size and the 512-byte sector size handling to correct said
> mistake, unless someone else would rather.
> 
> -- Rick C. Petty
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
> 


From rick-freebsd2008 at kiwi-computer.com  Tue Jan  6 07:22:07 2009
From: rick-freebsd2008 at kiwi-computer.com (Rick C. Petty)
Date: Tue Jan  6 07:22:14 2009
Subject: newfs(8) parameters from "dumpfs -m" have bad -s value?
In-Reply-To: <E1LK5mY-0008AF-R5@kabab.cs.huji.ac.il>
References: <20090102153455.GR4100@albert.catwhisker.org>
	<200901051923.n05JNrwt038325@lurza.secnetix.de>
	<20090105221352.GB35524@keira.kiwi-computer.com>
	<E1LK5mY-0008AF-R5@kabab.cs.huji.ac.il>
Message-ID: <20090106072205.GA41950@keira.kiwi-computer.com>

On Tue, Jan 06, 2009 at 08:51:18AM +0200, Danny Braniss wrote:
> > 
> > Everything is converted to number of media sectors (sector size as
> > specified by the device).  So one could assume for dumpfs to always use
> > 512, since it's rarely different, and multiply fs_size by fs_fsize and
> > divide by 512, and then output "-S 512".
> 
> don't assume 512, in the iscsi world I have seen all kinds of sector sizes,
> making it a PITA to get things right.

It was a suggestion, one assumed by FreeBSD in many places.  In this case,
it makes no difference since the number of bytes is computed by newfs and
then divided by the actual sector size when calling bwrite(3).  I still
would prefer:

> > Better yet would be to add a parameter ("-z" perhaps) to newfs(8) to accept
> > number of bytes instead of multiples of sectorsize.

-- Rick C. Petty
From pyunyh at gmail.com  Tue Jan  6 08:03:43 2009
From: pyunyh at gmail.com (Pyun YongHyeon)
Date: Tue Jan  6 08:03:49 2009
Subject: Panic in RELENG_7_1 with fxp(4)
In-Reply-To: <4961FACE.4060203@avioc.org>
References: <49600E2E.7070601@avioc.org>
	<3163F769-48B0-4CFC-8842-BBBDDAE78B51@gmail.com>
	<20090105032657.GA1842@cdnetworks.co.kr>
	<4961FACE.4060203@avioc.org>
Message-ID: <20090106080333.GA6168@cdnetworks.co.kr>

On Mon, Jan 05, 2009 at 06:19:26AM -0600, Brandon Weisz wrote:
 > Pyun YongHyeon wrote:
 > >On Sat, Jan 03, 2009 at 10:16:58PM -0800, Garrett Cooper wrote:
 > > > On Jan 3, 2009, at 5:17 PM, Brandon Weisz wrote:
 > > > 
 > > > >After running 7-PRERELEASE from around November 25th, I upgraded  
 > > > >today to find the system panics repeatably on RELENG_7_1 sources.  I  
 > > > >can boot back to the old kernel and it operates as expected.  It  
 > > > >seems to be related to fxp(4).
 > > > >
 > > > >FreeBSD didy.internal 7.1-RELEASE FreeBSD 7.1-RELEASE #0: Sat Jan  3
 > > > >18:11:18 CST 2009     bweisz@didy.internal:/usr/obj/usr/src/sys/ 
 > > > >DIDY  i386
 > > > >
 > 
 > ....
 > 
 > > > >
 > > > >I replaced the fxp(4) card with an old xl(4) card lying on my desk  
 > > > >and the panics stopped.  Is this a failing nic card or some other  
 > > > >trigger?
 > > > >
 > > > >Brandon
 > > > 
 > > > Memory serves me correctly an MFC was done not too long before 7.1  
 > > > release was setup.
 > > > 
 > >
 > >I don't know what MFCes were done, at least I didn't MFC any
 > >changes I made.
 > >
 > > > Let's see what Pyun says...
 > > > 
 > >
 > >I'm not sure what is root cause of this panic. If you can reliably
 > >reproduce the panic would you let me know?
 > >CURRENT has a couple of fixes for edge-cases as well as some new
 > >hardware features(TSO, VLAN hardware tagging and WOL etc). Would
 > >you try latest fxp(4) in HEAD?
 > >I think you can use cvsweb interface to get latest files.
 > >http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/fxp/if_fxp.c
 > >http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/fxp/if_fxpreg.h
 > >http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/fxp/if_fxpvar.h
 > >
 > 
 > Hi Pyun
 > 
 > The system reliably panics on boot up.  I tested fxp from HEAD with the 
 > same result.
 > 
 > 7.1-RELEASE = Panic
 > 7.1-RELEASE with fxp from HEAD = Panic
 > 7.1-PRERELEASE from Tue Nov 25 = operates as expected
 > 
 > This is an old card.  Some details on the card:
 > 
 > fxp0: <Intel 82559 Pro/100 Ethernet> port 0xd100-0xd13f mem 
 > 0xfca03000-0xfca03fff,0xfc800000-0xfc8fffff irq 17 at device 9.0 on pci0
 > miibus0: <MII bus> on fxp0
 > inphy0: <i82555 10/100 media interface> PHY 1 on miibus0
 > inphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
 > fxp0: Ethernet address: 00:d0:b7:6c:1c:0a
 > fxp0: [ITHREAD]
 > 
 > fxp0@pci0:0:9:0:	class=0x020000 card=0x000b8086 chip=0x12298086 
 > rev=0x08 hdr=0x00
 >     vendor     = 'Intel Corporation'
 >     device     = '82550/1/7/8/9 EtherExpress PRO/100(B) Ethernet Adapter'
 >     class      = network
 >     subclass   = ethernet
 > 
 > As a test, I unplugged the ethernet cable and the system booted fully, 
 > however it produced a panic as soon as I connected the cable.  This 
 > backtrace is from 7.1-RELEASE with fxp sources from HEAD.
 > 

I still can't reproduce this but would you try fxp(4) in the
following URLs?
http://people.freebsd.org/~yongari/fxp/if_fxp.c
http://people.freebsd.org/~yongari/fxp/if_fxpreg.h
http://people.freebsd.org/~yongari/fxp/if_fxpvar.h

-- 
Regards,
Pyun YongHyeon
From rwatson at FreeBSD.org  Tue Jan  6 08:16:02 2009
From: rwatson at FreeBSD.org (Robert Watson)
Date: Tue Jan  6 08:16:15 2009
Subject: TCP packet out-of-order problem
In-Reply-To: <47713ee10901052025y26d342f6me0aea946a49b6f0a@mail.gmail.com>
References: <47713ee10812301206j12b35264o715976c154080a1b@mail.gmail.com>
	<47713ee10901012147k1f25c31bn512dd29b2b294ad5@mail.gmail.com>
	<47713ee10901012249w65c659bbp3366e4d8ef25c59d@mail.gmail.com>
	<alpine.BSF.2.00.0901051312370.98366@fledge.watson.org>
	<47713ee10901052025y26d342f6me0aea946a49b6f0a@mail.gmail.com>
Message-ID: <alpine.BSF.2.00.0901060813240.12075@fledge.watson.org>


On Tue, 6 Jan 2009, Lin Jui-Nan Eric wrote:

> I thought that the system auto-tune improperly in this case.

Hmm.  Do you have a custom setting for kern.ipc.nmbclusters in loader.conf or 
sysctl.conf?  What does kern.ipc.nmbclusters configure itself to on your 
system?  Also, could you send me the output of uname -a on the system?

Thanks,

Robert N M Watson
Computer Laboratory
University of Cambridge

> On Mon, Jan 5, 2009 at 9:13 PM, Robert Watson <rwatson@freebsd.org> wrote:
>> On Fri, 2 Jan 2009, Lin Jui-Nan Eric wrote:
>>
>>> After running "netstat -s -p tcp", we found that lots of packets are
>>> discarded due to memory problems. We googled for it, and found that sysctl
>>> oid "net.inet.tcp.reass.maxsegments" became 0, therefore packets never
>>> reassembled.
>>>
>>> Then we checked our /boot/loader.conf and /etc/sysctl.conf, and found that
>>> setting kern.ipc.nmbclusters="0" makes net.inet.tcp.reass.maxsegments=0.
>>> After setting net.inet.tcp.reass.maxsegments="1600" in /boot/loader.conf,
>>> the network works perfectly now.
>>
>> Was it set to 0 through a configuration error, or did the system auto-tune
>> improperly?
>>
>> Robert N M Watson
>> Computer Laboratory
>> University of Cambridge
>>
>>>
>>> Thank you all for the help!
>>> _______________________________________________
>>> freebsd-stable@freebsd.org mailing list
>>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
>>> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
>>>
>>
>
From db at danielbond.org  Tue Jan  6 08:30:36 2009
From: db at danielbond.org (Daniel Bond)
Date: Tue Jan  6 08:30:59 2009
Subject: freebsd-update painfully slow - slower than source code build of
	world and kernel
Message-ID: <DA7E7739-0631-4B00-8CA8-D8C9E22B2126@danielbond.org>

Hi,

I'm not sure where to post this, I had trouble finding a suitable  
mailing-list. Please point me in the right direction, if this is the  
wrong place to post this message.

First off, I love the binary update tool for FreeBSD. It is an  
excellent tool, and saves a lot of time and trouble compared to the  
old method (or so I thought, until recently).
I also like seeing the freebsd-update method is in the release notes  
for 7.1-RELEASE, as a official way to upgrade a system.

Yesterday I was struck by happiness, as I noticed 7.1-RELEASE was out  
on ftp.freebsd.org - and decided to start off by upgrading one of my  
companies development servers.
Usually an update with FreeBSD-update is quite quick, but today and  
yesterday it has just been to slow to use, after two days of trying -  
I've still not completed a single upgrade. The
server in question is connected to gigabit internet.

I think it is embarrassing that the binary update tool, is actually  
slower to use than compiling the whole operating system and kernel -  
even on a slow machine! The reason for this,
is not the tool it self, the tool is excellent - but there are no  
mirrors.. We need some mirrors, or such a great tool is not really  
usable at all (except for the really patient).

This also goes for portsnap. Portsnap is also an excellent tool, but  
the experience from using it could be much better. The european  
portsnap mirror is actually slower, than the one in the US.
I've been in contact with Colin, twice, about hosting another portsnap  
mirror. Using a proxy server, does not cut it - not for my use, sorry.  
I tried it, it didn't help. The last time I didn't receive an
answer.

As I was saying to Colin, both myself and a friend who works for the  
Norwegian government, should be able to run a mirror for portsnap on  
good bandwidth. Many other people have offered
to host mirrors, why is having mirrors a bad thing?

I know the 6.4 and 7.1 releases have very many patches, due to  
conversion from CVS to SVN. I have previously upgraded servers in  
Norway and UK to 6.4-RELEASE with freebsd-update,
and speed has been acceptable, not great, but enough to keep me using  
and loving the tool. Still, I think more people will use freebsd- 
update, since it is more practical to use, especially for
non homogenous environments.

Hopefully this will improve in the future, I don't mean to come across  
as a whining grunge, but it is quite frustrating to me, as a loving  
freebsd user.

Congrats on a new release, I will be using it in a another day or so  
(or whenever freebsd-update is done - maybe I will eat my own words,  
and just do a regular build)!



Best regards,


Daniel Bond.
From kensmith at cse.Buffalo.EDU  Tue Jan  6 08:49:13 2009
From: kensmith at cse.Buffalo.EDU (Ken Smith)
Date: Tue Jan  6 08:49:20 2009
Subject: 7.1 Live Filesystem CD
In-Reply-To: <75412669-8781-4E77-9651-6F6EED2E48F4@lafn.org>
References: <75412669-8781-4E77-9651-6F6EED2E48F4@lafn.org>
Message-ID: <1231231736.648.0.camel@neo.cse.buffalo.edu>

On Mon, 2009-01-05 at 20:53 -0800, Doug Hardie wrote:
> Is the Live Filesystem CD supposed to be bootable?  7.0's was but I  
> can't get the 7.1 disc to boot.  It works fine if I boot from CD 1 and  
> then switch.

Yes, it's supposed to be bootable.  Works for me.

Which architecture?

-- 
                                                Ken Smith
- From there to here, from here to      |       kensmith@cse.buffalo.edu
  there, funny things are everywhere.   |
                      - Theodore Geisel |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090106/36a4899d/attachment.pgp
From db at danielbond.org  Tue Jan  6 09:04:06 2009
From: db at danielbond.org (Daniel Bond)
Date: Tue Jan  6 09:04:14 2009
Subject: freebsd-update painfully slow - slower than source code build
	of world and kernel
In-Reply-To: <f99a79ec0901060050r353e77a5u6b6a7a5143b5c51a@mail.gmail.com>
References: <DA7E7739-0631-4B00-8CA8-D8C9E22B2126@danielbond.org>
	<f99a79ec0901060050r353e77a5u6b6a7a5143b5c51a@mail.gmail.com>
Message-ID: <6A3773A5-E338-4593-806E-0DB6EE004724@danielbond.org>

Hi Stefan.

Yes, I am also noticing this. Luckily interrupting it and starting it  
again resumes. Judging from the speed of http://www.daemonology.net/  
(hosted on same site), the freebsd-update server must be absolutely  
hammered.



On Jan 6, 2009, at 9:50 AM, Stefan Miklosovic wrote:

> Hi,
>
> My opinion is same. I tried to upgrade from 7.0-RELEASE to 7.1- 
> RELEASE but even after
> copying all the stuff from 7.0-RELEASE CD (src etc) and having  
> GENERIC kernel in /boot/,
> "freebsd-update upgrade -r 7.1-RELEASE" started to work properly but  
> hase not done its work.
> All tries stopped at some failure during a downloading. I have been  
> trying this about half a day,
> three times, but no change :((
>
> On Tue, Jan 6, 2009 at 9:03 AM, Daniel Bond <db@danielbond.org> wrote:
> Hi,
>
> I'm not sure where to post this, I had trouble finding a suitable  
> mailing-list. Please point me in the right direction, if this is the  
> wrong place to post this message.
>
> First off, I love the binary update tool for FreeBSD. It is an  
> excellent tool, and saves a lot of time and trouble compared to the  
> old method (or so I thought, until recently).
> I also like seeing the freebsd-update method is in the release notes  
> for 7.1-RELEASE, as a official way to upgrade a system.
>
> Yesterday I was struck by happiness, as I noticed 7.1-RELEASE was  
> out on ftp.freebsd.org - and decided to start off by upgrading one  
> of my companies development servers.
> Usually an update with FreeBSD-update is quite quick, but today and  
> yesterday it has just been to slow to use, after two days of trying  
> - I've still not completed a single upgrade. The
> server in question is connected to gigabit internet.
>
> I think it is embarrassing that the binary update tool, is actually  
> slower to use than compiling the whole operating system and kernel -  
> even on a slow machine! The reason for this,
> is not the tool it self, the tool is excellent - but there are no  
> mirrors.. We need some mirrors, or such a great tool is not really  
> usable at all (except for the really patient).
>
> This also goes for portsnap. Portsnap is also an excellent tool, but  
> the experience from using it could be much better. The european  
> portsnap mirror is actually slower, than the one in the US.
> I've been in contact with Colin, twice, about hosting another  
> portsnap mirror. Using a proxy server, does not cut it - not for my  
> use, sorry. I tried it, it didn't help. The last time I didn't  
> receive an
> answer.
>
> As I was saying to Colin, both myself and a friend who works for the  
> Norwegian government, should be able to run a mirror for portsnap on  
> good bandwidth. Many other people have offered
> to host mirrors, why is having mirrors a bad thing?
>
> I know the 6.4 and 7.1 releases have very many patches, due to  
> conversion from CVS to SVN. I have previously upgraded servers in  
> Norway and UK to 6.4-RELEASE with freebsd-update,
> and speed has been acceptable, not great, but enough to keep me  
> using and loving the tool. Still, I think more people will use  
> freebsd-update, since it is more practical to use, especially for
> non homogenous environments.
>
> Hopefully this will improve in the future, I don't mean to come  
> across as a whining grunge, but it is quite frustrating to me, as a  
> loving freebsd user.
>
> Congrats on a new release, I will be using it in a another day or so  
> (or whenever freebsd-update is done - maybe I will eat my own words,  
> and just do a regular build)!
>
>
>
> Best regards,
>
>
> Daniel Bond.
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org 
> "
>

From mav at FreeBSD.org  Tue Jan  6 09:35:03 2009
From: mav at FreeBSD.org (Alexander Motin)
Date: Tue Jan  6 09:35:10 2009
Subject: HEADS UP: snd_hda MFC plan
In-Reply-To: <20090106072511.16463froljaeoy80@webmail.leidinger.net>
References: <49628626.40202@FreeBSD.org>
	<20090106072511.16463froljaeoy80@webmail.leidinger.net>
Message-ID: <4963236D.9050703@FreeBSD.org>

Alexander Leidinger wrote:
> Quoting Alexander Motin <mav@FreeBSD.org> (from Tue, 06 Jan 2009
> 00:13:58 +0200):
> 
>> On most systems having several devices is not a problem, as mostly
>> used analog connectors are usually detected first. But on some systems
>> (for example, having separate HDMI ports on video cards, which are now
>> also supported and often detected first), user may be required to
>> explicitly configure his audio applications or by using
>> hw.snd.default_unit sysctl globally specify default audio device he
>> wants to use. This moment explicitly specified in updated man page and
>> I am going to specify it in UPDATING.
> 
> Is there a way to move those HDMI ports to the end (either in pcmX or in
> the probing) somehow? If yes, it would be more POLA to do this instead
> of requiring the users to do something.

HDMI ports usually have separate PCI HDA controllers. So order of pcm
devices there defined by PCI probe order. Two driver instances know
nothing about each other and I don't like the idea of obtaining such
knowledge.

> And related: do all detected analog ports appear in a sensible order?
> What I mean is again POLA related. If someone updates from 7.1 to 7.2,
> will he be required to do something to get sound out of the same
> connector as before when connecting to the default audio device? If not,
> is it possible for you to introduce some corresponding sorting before
> MFCing?

Order of ports withing one codec defined by hardware vendor via codec
configuration done by BIOS. That configuration supposed to be optimal
for the specific system. Taking that previous driver ignored most of
this information and was less functional, there sure will be some usage
differences, but most configurations I have seen are quite reasonable to
work just out of the box.

-- 
Alexander Motin
From henrikes at tihlde.org  Tue Jan  6 09:39:27 2009
From: henrikes at tihlde.org (Henrik Schewe)
Date: Tue Jan  6 09:39:35 2009
Subject: freebsd-update painfully slow - slower than source code build
 of	world and kernel
In-Reply-To: <DA7E7739-0631-4B00-8CA8-D8C9E22B2126@danielbond.org>
References: <DA7E7739-0631-4B00-8CA8-D8C9E22B2126@danielbond.org>
Message-ID: <496321E9.9090906@tihlde.org>

Hello!
> Usually an update with FreeBSD-update is quite quick, but today and 
> yesterday it has just been to slow to use, after two days of trying - 
> I've still not completed a single upgrade.
> This also goes for portsnap. Portsnap is also an excellent tool, but 
> the experience from using it could be much better. The european 
> portsnap mirror is actually slower, than the one in the US.
I can only verify your experiences with both freebsd-update and the 
speed of the portsnap mirrors lately.

-BR, Henrik Schewe
From ertr1013 at student.uu.se  Tue Jan  6 09:58:41 2009
From: ertr1013 at student.uu.se (Erik Trulsson)
Date: Tue Jan  6 09:58:48 2009
Subject: 7.1 Live Filesystem CD
In-Reply-To: <1231231736.648.0.camel@neo.cse.buffalo.edu>
References: <75412669-8781-4E77-9651-6F6EED2E48F4@lafn.org>
	<1231231736.648.0.camel@neo.cse.buffalo.edu>
Message-ID: <20090106094323.GA98633@owl.midgard.homeip.net>

On Tue, Jan 06, 2009 at 03:48:56AM -0500, Ken Smith wrote:
> On Mon, 2009-01-05 at 20:53 -0800, Doug Hardie wrote:
> > Is the Live Filesystem CD supposed to be bootable?  7.0's was but I  
> > can't get the 7.1 disc to boot.  It works fine if I boot from CD 1 and  
> > then switch.
> 
> Yes, it's supposed to be bootable.  Works for me.
> 
> Which architecture?

Funnily enough the release announcement said:


   disc1, disc2, disc3, livefs, docs:  disc1 contains the base FreeBSD
        system and a few pre-built packages.  disc2 and disc3 contain
        more pre-built packages.  Those three can be burned to CDROM
        sized media and should be all you need to do a normal installation.
        livefs contains support for entering into a "livefs" based
        rescue mode but you need disc1 to do the initial boot first.
        docs contains the documentation.


implying that the "livefs" CD is not supposed to be bootable.




-- 
<Insert your favourite quote here.>
Erik Trulsson
ertr1013@student.uu.se
From nakal at web.de  Tue Jan  6 10:06:24 2009
From: nakal at web.de (Martin)
Date: Tue Jan  6 10:06:33 2009
Subject: 7.1 Live Filesystem CD
In-Reply-To: <1231231736.648.0.camel@neo.cse.buffalo.edu>
References: <75412669-8781-4E77-9651-6F6EED2E48F4@lafn.org>
	<1231231736.648.0.camel@neo.cse.buffalo.edu>
Message-ID: <20090106104024.2d544e54@zelda.local>

Am Tue, 06 Jan 2009 03:48:56 -0500
schrieb Ken Smith <kensmith@cse.Buffalo.EDU>:

> On Mon, 2009-01-05 at 20:53 -0800, Doug Hardie wrote:
> > Is the Live Filesystem CD supposed to be bootable?  7.0's was but
> > I can't get the 7.1 disc to boot.  It works fine if I boot from CD
> > 1 and then switch.
> 
> Yes, it's supposed to be bootable.  Works for me.
> 
> Which architecture?

Hi Ken und Doug,

I want to confirm this. I tested RC1, RC2 and RELEASE livefs CD i386.
They don't boot on some PCs. I can still use 8.0 CURRENT snapshot
livefs for i386 on the same problematic PC.

--
Martin
From chris at arnold.se  Tue Jan  6 10:26:34 2009
From: chris at arnold.se (Christopher Arnold)
Date: Tue Jan  6 10:26:42 2009
Subject: freebsd-update painfully slow - slower than source code build
 of world and kernel
In-Reply-To: <DA7E7739-0631-4B00-8CA8-D8C9E22B2126@danielbond.org>
References: <DA7E7739-0631-4B00-8CA8-D8C9E22B2126@danielbond.org>
Message-ID: <alpine.BSF.2.00.0901061121530.1996@localhost>



On Tue, 6 Jan 2009, Daniel Bond wrote:

> I'm not sure where to post this, I had trouble finding a suitable 
> mailing-list. Please point me in the right direction, if this is the wrong 
> place to post this message.
>
I think freebsd-ports would have been the place.

> Yesterday I was struck by happiness, as I noticed 7.1-RELEASE was out on 
> ftp.freebsd.org - and decided to start off by upgrading one of my companies 
> development servers.
> Usually an update with FreeBSD-update is quite quick, but today and yesterday 
> it has just been to slow to use, after two days of trying - I've still not 
> completed a single upgrade. The
> server in question is connected to gigabit internet.
>
> I think it is embarrassing that the binary update tool, is actually slower to 
> use than compiling the whole operating system and kernel - even on a slow 
> machine! The reason for this,
> is not the tool it self, the tool is excellent - but there are no mirrors.. 
> We need some mirrors, or such a great tool is not really usable at all 
> (except for the really patient).
>
This is a known issue that Colin sent out a message about to freebsd-ports 
and freebsd-questions.

Basically there is a surge in in traffic right now due to the 7.1 release. 
And there is another update machine on the way.

The message is included belov my sig.

 	/Chris


Hi all,

For the benefit of those of you who are noticing problems with portsnap
right
now: The release of FreeBSD 7.1 has resulted in a very large amount of
traffic
to update1.freebsd.org, which is hosted by the same box as
portsnap-master...
so the portsnap mirrors are having some trouble syncing right now.  If you
find
that portsnap doesn't work, please be patient -- once the flood of people
upgrading systems to 7.1-RELEASE has subsided things should get back to
normal.

(Before people ask: update2.freebsd.org is going to exist soon.  No, I'm 
not looking for more mirrors right now.)

-- 
Colin Percival
Security Officer, FreeBSD | freebsd.org | The power to serve
Founder / author, Tarsnap | tarsnap.com | Online backups for the truly
paranoid

From db at danielbond.org  Tue Jan  6 10:52:22 2009
From: db at danielbond.org (Daniel Bond)
Date: Tue Jan  6 10:52:29 2009
Subject: freebsd-update painfully slow - slower than source code build
	of world and kernel
In-Reply-To: <alpine.BSF.2.00.0901061121530.1996@localhost>
References: <DA7E7739-0631-4B00-8CA8-D8C9E22B2126@danielbond.org>
	<alpine.BSF.2.00.0901061121530.1996@localhost>
Message-ID: <F6385D88-BFAF-47A0-B598-78C971FCBD7C@danielbond.org>

Thanks for pointing me in the right direction.

Regarding portsnap in my previous post, I think you misunderstood me.  
This is not a new "one time" problem regarding a specific case,  
portsnap is allways slow. This is observed from
heavy usage of it, over a long period of time.

Great to see that there will be an update2.freebsd.org -  
unfortunately, that a new release generates more traffic than update- 
server handles is not acceptable (imho). People should be able to  
upgrade to a new release, once it is out. Sadly, I don't think one  
more mirror will cut it. Especially if it is going to be of the same  
quality as the other portsnap mirrors. Also, sadly CP isn't looking  
for more mirrors, while a large chunk of users trying to upgrade *are*  
looking for mirrors.

Look at CVSUP mirrors, they have always worked fine, even directly  
after a new release. We even have a few of them here in Norway, and  
they are fast as hell. Look how many there are of them, spread around  
the world.. This works out great!

It is easy for anyone to setup a CVSup mirror. It is open and well  
documented. Anyone could create a CVSup mirror, any where they please  
and mirror FreeBSD's sourcecode and ports.

However, freebsd-update is closed. I've searched the web for how the  
protocol works, how the server-part of it works, with metadata,  
checksums and all. How the mirroring of it works, basicly. There are  
no public available documents on this. Do we have to reverse-engineer  
it, or what?

I think Colin made a really nice tool, but he needs opening up (for  
the project and everyone's good) - he is controlling the service with  
a iron grip, dictating who gets to host a mirror and who dosn't. I'm  
sure the service is allways very good for CP, the servers are probably  
on his LAN or somewhere close, and he has the power to create mirrors  
where ever he pleases, at home, at office.. but nobody else can have  
that power..



Regards,


Daniel Bond.


On Jan 6, 2009, at 11:26 AM, Christopher Arnold wrote:

>
>
> On Tue, 6 Jan 2009, Daniel Bond wrote:
>
>> I'm not sure where to post this, I had trouble finding a suitable  
>> mailing-list. Please point me in the right direction, if this is  
>> the wrong place to post this message.
>>
> I think freebsd-ports would have been the place.
>
>> Yesterday I was struck by happiness, as I noticed 7.1-RELEASE was  
>> out on ftp.freebsd.org - and decided to start off by upgrading one  
>> of my companies development servers.
>> Usually an update with FreeBSD-update is quite quick, but today and  
>> yesterday it has just been to slow to use, after two days of trying  
>> - I've still not completed a single upgrade. The
>> server in question is connected to gigabit internet.
>>
>> I think it is embarrassing that the binary update tool, is actually  
>> slower to use than compiling the whole operating system and kernel  
>> - even on a slow machine! The reason for this,
>> is not the tool it self, the tool is excellent - but there are no  
>> mirrors.. We need some mirrors, or such a great tool is not really  
>> usable at all (except for the really patient).
>>
> This is a known issue that Colin sent out a message about to freebsd- 
> ports and freebsd-questions.
>
> Basically there is a surge in in traffic right now due to the 7.1  
> release. And there is another update machine on the way.
>
> The message is included belov my sig.
>
> 	/Chris
>
>
> Hi all,
>
> For the benefit of those of you who are noticing problems with  
> portsnap
> right
> now: The release of FreeBSD 7.1 has resulted in a very large amount of
> traffic
> to update1.freebsd.org, which is hosted by the same box as
> portsnap-master...
> so the portsnap mirrors are having some trouble syncing right now.   
> If you
> find
> that portsnap doesn't work, please be patient -- once the flood of  
> people
> upgrading systems to 7.1-RELEASE has subsided things should get back  
> to
> normal.
>
> (Before people ask: update2.freebsd.org is going to exist soon.  No,  
> I'm not looking for more mirrors right now.)
>
> -- 
> Colin Percival
> Security Officer, FreeBSD | freebsd.org | The power to serve
> Founder / author, Tarsnap | tarsnap.com | Online backups for the truly
> paranoid
>
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org 
> "

From krassi at bulinfo.net  Tue Jan  6 11:42:57 2009
From: krassi at bulinfo.net (Krassimir Slavchev)
Date: Tue Jan  6 11:43:04 2009
Subject: ACPI support?
Message-ID: <49633C85.3090507@bulinfo.net>

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

Hello All,

I have had a problem detecting the network card on my notebook when ACPI
is enabled for a year. The problem still exists in 7.1-RELEASE.

with ACPI:
...
bge0: <Broadcom NetLink Gigabit Ethernet Controller, ASIC rev. 0xb002>
irq 17 at device 0.0 on pci8
bge0: 0x10000 bytes of rid 0x10 res 3 failed (0, 0xffffffff).
bge0: couldn't map memory
device_attach: bge0 attach returned 6
...

without ACPI:
...
bge0: <Broadcom NetLink Gigabit Ethernet Controller, ASIC rev. 0xb002>
mem 0xf3000000-0xf300ffff irq 17 at device 0.0 on pci8
miibus0: <MII bus> on bge0
brgphy0: <BCM5787 10/100/1000baseTX PHY> PHY 1 on miibus0
brgphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT,
1000baseT-FDX, auto
bge0: Ethernet address: 00:1b:24:ca:a0:aa
bge0: [ITHREAD]
...

It seems that some resources are disabled by ACPI and should be enabled
first.

Here is dmesg from linux:
...
tg3 0000:08:00.0: enabling device (0000 -> 0002)
tg3 0000:08:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
tg3 0000:08:00.0: setting latency timer to 64
eth0: Tigon3 [partno(BCM95787m) rev b002 PHY(5787)] (PCI Express)
10/100/1000Base-T Ethernet 00:1b:24:ca:a0:aa
eth0: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] WireSpeed[1] TSOcap[1]
eth0: dma_rwctrl[76180000] dma_mask[64-bit]
...

What changes should be made to enable these resources and where, in the
device driver, acpi or pci code or both?
Is there something similar already done?

Best Regards

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (FreeBSD)

iD8DBQFJYzyFxJBWvpalMpkRAqSUAJ4y6oeaFg0svVrXTobNtc0CHW8thQCeLU/i
i0T/PFHDkxWAJHN+Z/zSAhY=
=nXCJ
-----END PGP SIGNATURE-----
From chris at arnold.se  Tue Jan  6 11:59:30 2009
From: chris at arnold.se (Christopher Arnold)
Date: Tue Jan  6 11:59:37 2009
Subject: freebsd-update painfully slow - slower than source code build
 of world and kernel
In-Reply-To: <F6385D88-BFAF-47A0-B598-78C971FCBD7C@danielbond.org>
References: <DA7E7739-0631-4B00-8CA8-D8C9E22B2126@danielbond.org>
	<alpine.BSF.2.00.0901061121530.1996@localhost>
	<F6385D88-BFAF-47A0-B598-78C971FCBD7C@danielbond.org>
Message-ID: <alpine.BSF.2.00.0901061242120.1996@localhost>



On Tue, 6 Jan 2009, Daniel Bond wrote:

> Regarding portsnap in my previous post, I think you misunderstood me. This is 
> not a new "one time" problem regarding a specific case, portsnap is allways 
> slow. This is observed from heavy usage of it, over a long period of time.
>
This is not my experience, but shure i realise that mileages can vary.

> Great to see that there will be an update2.freebsd.org - unfortunately, that 
> a new release generates more traffic than update-server handles is not 
> acceptable (imho). People should be able to upgrade to a new release, once it 
> is out. Sadly, I don't think one more mirror will cut it. Especially if it is 
> going to be of the same quality as the other portsnap mirrors. Also, sadly CP 
> isn't looking for more mirrors, while a large chunk of users trying to 
> upgrade *are* looking for mirrors.
>
portsnap is extremly lightweight, so it might be just fine.

But then i am not arguing against you, more and better infrastructure is 
always good. Lets wait untill the us has woken up (And maybe add some 
extra time for the right person to look into the current problems) and see 
what kind of feedback we get from people who have more insight into this issue.

> Look at CVSUP mirrors, they have always worked fine, even directly after a 
> new release. We even have a few of them here in Norway, and they are fast as 
> hell. Look how many there are of them, spread around the world.. This works 
> out great!
>
My experience from when i was based in Sweden is the opposit. Shortly 
after a major release cvsup always had problems syncing due to the load on 
the servers.

> However, freebsd-update is closed. I've searched the web for how the protocol 
> works, how the server-part of it works, with metadata, checksums and all. How 
> the mirroring of it works, basicly. There are no public available documents 
> on this. Do we have to reverse-engineer it, or what?
>
If we start off with portsnap it is http-based and the in the manual you 
can find:
"If you wish to use portsnap to keep a large number of machines 
up to date, you may wish to set up a caching HTTP proxy.  Since portsnap 
uses fetch(1) to download updates, setting the HTTP_PROXY environment 
variable will direct it to fetch updates from the given proxy.  This is 
much more efficient than mirroring the files on the portsnap server, since 
the vast majority of files are not needed by any particular client."

So it's straight forward to speed up portsnap. (But then if the central 
servers break like today this dosn't help.)

Im not shure about freebsd-update, but since they are both written by 
Colin and the fact that they seem simmilar in config etc. i would guess 
that the same applies to freebsd-update.

So lets wait for some input from Colin or someone else who know the ins 
and outs of freebsd-update.

 	/Chris

--
http://www.arnold.se/chris/

From jhs at berklix.org  Tue Jan  6 12:02:07 2009
From: jhs at berklix.org (Julian Stacey)
Date: Tue Jan  6 12:02:15 2009
Subject: 7.1 Live Filesystem CD 
In-Reply-To: Your message "Tue, 06 Jan 2009 10:43:23 +0100."
	<20090106094323.GA98633@owl.midgard.homeip.net> 
Message-ID: <200901061200.n06C0QXa052354@fire.js.berklix.net>

Hi,
Reference:
> From:		Erik Trulsson <ertr1013@student.uu.se> 
> Date:		Tue, 6 Jan 2009 10:43:23 +0100 
> Message-id:	<20090106094323.GA98633@owl.midgard.homeip.net> 

Erik Trulsson wrote:
> On Tue, Jan 06, 2009 at 03:48:56AM -0500, Ken Smith wrote:
> > On Mon, 2009-01-05 at 20:53 -0800, Doug Hardie wrote:
> > > Is the Live Filesystem CD supposed to be bootable?  7.0's was but I  
> > > can't get the 7.1 disc to boot.  It works fine if I boot from CD 1 and  
> > > then switch.
> > 
> > Yes, it's supposed to be bootable.  Works for me.
> > 
> > Which architecture?
> 
> Funnily enough the release announcement said:
> 
> 
>    disc1, disc2, disc3, livefs, docs:  disc1 contains the base FreeBSD
>         system and a few pre-built packages.  disc2 and disc3 contain
>         more pre-built packages.  Those three can be burned to CDROM
>         sized media and should be all you need to do a normal installation.
>         livefs contains support for entering into a "livefs" based
>         rescue mode but you need disc1 to do the initial boot first.
>         docs contains the documentation.
> 
> 
> implying that the "livefs" CD is not supposed to be bootable.

Martin (who confirmed to Doug on this thread, he'd also seen that)
previously raised the problem on this same list on a different
thread, For more background:
  First:
  http://lists.freebsd.org/pipermail/freebsd-stable/2008-December/047238.html
	Subject: Re: FreeBSD 7.1-RC2 Available...
	From: Martin <nakal@web.de>
	Date: Sun, 28 Dec 2008 16:18:13 +0100
	To: Ken Smith <kensmith@cse.Buffalo.EDU>
	Cc: freebsd-stable <freebsd-stable@freebsd.org>

  My comment
  http://lists.freebsd.org/pipermail/freebsd-stable/2008-December/047259.html

  Latest (Thanks Oliver)
  http://lists.freebsd.org/pipermail/freebsd-stable/2009-January/047329.html
	Date: Mon, 5 Jan 2009 20:46:42 +0100 (CET)
	Message-Id: <200901051946.n05JkgWo039451@lurza.secnetix.de>
	From: Oliver Fromme <olli@lurza.secnetix.de>
	To: freebsd-stable@freebsd.org, jhs@berklix.org
	Subject: Re: FreeBSD 7.1-RC2 Available...

Summary: 2 Boot methods for CDs, not a new problem, been known a long time.

Cheers,
Julian
-- 
Julian Stacey: BSDUnixLinux C Prog Admin SysEng Consult Munich www.berklix.com
  Mail plain ASCII text.  HTML & Base64 text are spam. www.asciiribbon.org
From db at danielbond.org  Tue Jan  6 12:08:07 2009
From: db at danielbond.org (Daniel Bond)
Date: Tue Jan  6 12:08:15 2009
Subject: freebsd-update painfully slow - slower than source code build
	of world and kernel
In-Reply-To: <alpine.BSF.2.00.0901061242120.1996@localhost>
References: <DA7E7739-0631-4B00-8CA8-D8C9E22B2126@danielbond.org>
	<alpine.BSF.2.00.0901061121530.1996@localhost>
	<F6385D88-BFAF-47A0-B598-78C971FCBD7C@danielbond.org>
	<alpine.BSF.2.00.0901061242120.1996@localhost>
Message-ID: <08B216B4-79AB-45AB-AB4D-C8CD62196B87@danielbond.org>

Hi again Christopher,


reading your answer, you are obviously confusing what I am saying  
about freebsd-update with the portsnap program. Also, I also wrote in  
my first post that HTTP_PROXY / Caching proxy server does not help me  
much. This is because I download a lot of "initial tarball  
snapshots".. I would rarely see "Cache hits" in my proxy log. I guess  
I could set something up to fetch nightly via proxy, to keep the data  
in house, for when I need it. I don't want to use a PROXY server, I  
feel this is attacking the problem at the wrong end.

I agree, I am interested to hear the views of the wise ones.  
Personally I'm going back to CVSup until freebsd-update and portsnap  
mirrors are in a more distributed or usable state.



Cheers.



On Jan 6, 2009, at 12:59 PM, Christopher Arnold wrote:

>
>
> On Tue, 6 Jan 2009, Daniel Bond wrote:
>
>> Regarding portsnap in my previous post, I think you misunderstood  
>> me. This is not a new "one time" problem regarding a specific case,  
>> portsnap is allways slow. This is observed from heavy usage of it,  
>> over a long period of time.
>>
> This is not my experience, but shure i realise that mileages can vary.
>
>> Great to see that there will be an update2.freebsd.org -  
>> unfortunately, that a new release generates more traffic than  
>> update-server handles is not acceptable (imho). People should be  
>> able to upgrade to a new release, once it is out. Sadly, I don't  
>> think one more mirror will cut it. Especially if it is going to be  
>> of the same quality as the other portsnap mirrors. Also, sadly CP  
>> isn't looking for more mirrors, while a large chunk of users trying  
>> to upgrade *are* looking for mirrors.
>>
> portsnap is extremly lightweight, so it might be just fine.
>
> But then i am not arguing against you, more and better  
> infrastructure is always good. Lets wait untill the us has woken up  
> (And maybe add some extra time for the right person to look into the  
> current problems) and see what kind of feedback we get from people  
> who have more insight into this issue.
>
>> Look at CVSUP mirrors, they have always worked fine, even directly  
>> after a new release. We even have a few of them here in Norway, and  
>> they are fast as hell. Look how many there are of them, spread  
>> around the world.. This works out great!
>>
> My experience from when i was based in Sweden is the opposit.  
> Shortly after a major release cvsup always had problems syncing due  
> to the load on the servers.
>
>> However, freebsd-update is closed. I've searched the web for how  
>> the protocol works, how the server-part of it works, with metadata,  
>> checksums and all. How the mirroring of it works, basicly. There  
>> are no public available documents on this. Do we have to reverse- 
>> engineer it, or what?
>>
> If we start off with portsnap it is http-based and the in the manual  
> you can find:
> "If you wish to use portsnap to keep a large number of machines up  
> to date, you may wish to set up a caching HTTP proxy.  Since  
> portsnap uses fetch(1) to download updates, setting the HTTP_PROXY  
> environment variable will direct it to fetch updates from the given  
> proxy.  This is much more efficient than mirroring the files on the  
> portsnap server, since the vast majority of files are not needed by  
> any particular client."
>
> So it's straight forward to speed up portsnap. (But then if the  
> central servers break like today this dosn't help.)
>
> Im not shure about freebsd-update, but since they are both written  
> by Colin and the fact that they seem simmilar in config etc. i would  
> guess that the same applies to freebsd-update.
>
> So lets wait for some input from Colin or someone else who know the  
> ins and outs of freebsd-update.
>
> 	/Chris
>
> --
> http://www.arnold.se/chris/
>

From Alexander at Leidinger.net  Tue Jan  6 14:37:55 2009
From: Alexander at Leidinger.net (Alexander Leidinger)
Date: Tue Jan  6 14:38:04 2009
Subject: HEADS UP: snd_hda MFC plan
In-Reply-To: <4963236D.9050703@FreeBSD.org>
References: <49628626.40202@FreeBSD.org>
	<20090106072511.16463froljaeoy80@webmail.leidinger.net>
	<4963236D.9050703@FreeBSD.org>
Message-ID: <20090106153725.10034o5c6ymot4m8@webmail.leidinger.net>

Quoting Alexander Motin <mav@FreeBSD.org> (from Tue, 06 Jan 2009  
11:25:01 +0200):

> Alexander Leidinger wrote:
>> Quoting Alexander Motin <mav@FreeBSD.org> (from Tue, 06 Jan 2009
>> 00:13:58 +0200):
>>
>>> On most systems having several devices is not a problem, as mostly
>>> used analog connectors are usually detected first. But on some systems
>>> (for example, having separate HDMI ports on video cards, which are now
>>> also supported and often detected first), user may be required to
>>> explicitly configure his audio applications or by using
>>> hw.snd.default_unit sysctl globally specify default audio device he
>>> wants to use. This moment explicitly specified in updated man page and
>>> I am going to specify it in UPDATING.
>>
>> Is there a way to move those HDMI ports to the end (either in pcmX or in
>> the probing) somehow? If yes, it would be more POLA to do this instead
>> of requiring the users to do something.
>
> HDMI ports usually have separate PCI HDA controllers. So order of pcm
> devices there defined by PCI probe order. Two driver instances know
> nothing about each other and I don't like the idea of obtaining such
> knowledge.

I agree... so we don't have a return value for the probe which  
basically tells that we want to see the probe called for this device  
again, after all other devices where probed? Would be useful here.

If this is not possible, I think we need something in the release  
notes about this. Maybe "The snd_hda driver now supports HDMI audio  
ports of graphic cards. This may result in additional audio devices  
after an update from 7.[01] and even replacing the previous default  
sound device. To change the default device in this case do ...."

>> And related: do all detected analog ports appear in a sensible order?
>> What I mean is again POLA related. If someone updates from 7.1 to 7.2,
>> will he be required to do something to get sound out of the same
>> connector as before when connecting to the default audio device? If not,
>> is it possible for you to introduce some corresponding sorting before
>> MFCing?
>
> Order of ports withing one codec defined by hardware vendor via codec
> configuration done by BIOS. That configuration supposed to be optimal
> for the specific system. Taking that previous driver ignored most of
> this information and was less functional, there sure will be some usage
> differences, but most configurations I have seen are quite reasonable to
> work just out of the box.

Should be mentioned in the release notes too. There's the possibility  
that an user get's a different default device, so we should be able to  
say "we told you so even in the release notes".

Bye,
Alexander.

-- 
But it does move!
		-- Galileo Galilei

http://www.Leidinger.net    Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org       netchild @ FreeBSD.org  : PGP ID = 72077137
From ericlin at tamama.org  Tue Jan  6 15:12:18 2009
From: ericlin at tamama.org (Lin Jui-Nan Eric)
Date: Tue Jan  6 15:12:31 2009
Subject: TCP packet out-of-order problem
In-Reply-To: <alpine.BSF.2.00.0901060813240.12075@fledge.watson.org>
References: <47713ee10812301206j12b35264o715976c154080a1b@mail.gmail.com>
	<47713ee10901012147k1f25c31bn512dd29b2b294ad5@mail.gmail.com>
	<47713ee10901012249w65c659bbp3366e4d8ef25c59d@mail.gmail.com>
	<alpine.BSF.2.00.0901051312370.98366@fledge.watson.org>
	<47713ee10901052025y26d342f6me0aea946a49b6f0a@mail.gmail.com>
	<alpine.BSF.2.00.0901060813240.12075@fledge.watson.org>
Message-ID: <47713ee10901060712g7b4a204fq73cabb99c7070929@mail.gmail.com>

Oops, we surely have kern.ipc.nmbclusters="0" in loader.conf, but I
think that should not modify net.inet.tcp.reass.maxsegments to "0"
since we wish unlimited nmbclusters but not zero TCP reassembly
segments.

On Tue, Jan 6, 2009 at 4:16 PM, Robert Watson <rwatson@freebsd.org> wrote:
>
> On Tue, 6 Jan 2009, Lin Jui-Nan Eric wrote:
>
>> I thought that the system auto-tune improperly in this case.
>
> Hmm.  Do you have a custom setting for kern.ipc.nmbclusters in loader.conf
> or sysctl.conf?  What does kern.ipc.nmbclusters configure itself to on your
> system?  Also, could you send me the output of uname -a on the system?
>
> Thanks,
>
> Robert N M Watson
> Computer Laboratory
> University of Cambridge
>
>> On Mon, Jan 5, 2009 at 9:13 PM, Robert Watson <rwatson@freebsd.org> wrote:
>>>
>>> On Fri, 2 Jan 2009, Lin Jui-Nan Eric wrote:
>>>
>>>> After running "netstat -s -p tcp", we found that lots of packets are
>>>> discarded due to memory problems. We googled for it, and found that
>>>> sysctl
>>>> oid "net.inet.tcp.reass.maxsegments" became 0, therefore packets never
>>>> reassembled.
>>>>
>>>> Then we checked our /boot/loader.conf and /etc/sysctl.conf, and found
>>>> that
>>>> setting kern.ipc.nmbclusters="0" makes net.inet.tcp.reass.maxsegments=0.
>>>> After setting net.inet.tcp.reass.maxsegments="1600" in
>>>> /boot/loader.conf,
>>>> the network works perfectly now.
>>>
>>> Was it set to 0 through a configuration error, or did the system
>>> auto-tune
>>> improperly?
>>>
>>> Robert N M Watson
>>> Computer Laboratory
>>> University of Cambridge
>>>
>>>>
>>>> Thank you all for the help!
>>>> _______________________________________________
>>>> freebsd-stable@freebsd.org mailing list
>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
>>>> To unsubscribe, send any mail to
>>>> "freebsd-stable-unsubscribe@freebsd.org"
>>>>
>>>
>>
>
From lists at avioc.org  Tue Jan  6 15:23:05 2009
From: lists at avioc.org (Brandon Weisz)
Date: Tue Jan  6 15:23:13 2009
Subject: Panic in RELENG_7_1 with fxp(4)
In-Reply-To: <20090106080333.GA6168@cdnetworks.co.kr>
References: <49600E2E.7070601@avioc.org>
	<3163F769-48B0-4CFC-8842-BBBDDAE78B51@gmail.com>
	<20090105032657.GA1842@cdnetworks.co.kr>
	<4961FACE.4060203@avioc.org>
	<20090106080333.GA6168@cdnetworks.co.kr>
Message-ID: <49637755.1070708@avioc.org>

Pyun YongHyeon wrote:
> On Mon, Jan 05, 2009 at 06:19:26AM -0600, Brandon Weisz wrote:
>  > Pyun YongHyeon wrote:
>  > >On Sat, Jan 03, 2009 at 10:16:58PM -0800, Garrett Cooper wrote:
>  > > > On Jan 3, 2009, at 5:17 PM, Brandon Weisz wrote:
>  > > > 
>  > > > >After running 7-PRERELEASE from around November 25th, I upgraded  
>  > > > >today to find the system panics repeatably on RELENG_7_1 sources.  I  
>  > > > >can boot back to the old kernel and it operates as expected.  It  
>  > > > >seems to be related to fxp(4).
>  > > > >
>  > > > >FreeBSD didy.internal 7.1-RELEASE FreeBSD 7.1-RELEASE #0: Sat Jan  3
>  > > > >18:11:18 CST 2009     bweisz@didy.internal:/usr/obj/usr/src/sys/ 
>  > > > >DIDY  i386
>  > > > >
>  > 
>  > ....
>  > 
>  > > > >
>  > > > >I replaced the fxp(4) card with an old xl(4) card lying on my desk  
>  > > > >and the panics stopped.  Is this a failing nic card or some other  
>  > > > >trigger?
>  > > > >
>  > > > >Brandon
>  > > > 
>  > > > Memory serves me correctly an MFC was done not too long before 7.1  
>  > > > release was setup.
>  > > > 
>  > >
>  > >I don't know what MFCes were done, at least I didn't MFC any
>  > >changes I made.
>  > >
>  > > > Let's see what Pyun says...
>  > > > 
>  > >
>  > >I'm not sure what is root cause of this panic. If you can reliably
>  > >reproduce the panic would you let me know?
>  > >CURRENT has a couple of fixes for edge-cases as well as some new
>  > >hardware features(TSO, VLAN hardware tagging and WOL etc). Would
>  > >you try latest fxp(4) in HEAD?
>  > >I think you can use cvsweb interface to get latest files.
>  > >http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/fxp/if_fxp.c
>  > >http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/fxp/if_fxpreg.h
>  > >http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/fxp/if_fxpvar.h
>  > >
>  > 
>  > Hi Pyun
>  > 
>  > The system reliably panics on boot up.  I tested fxp from HEAD with the 
>  > same result.
>  > 
>  > 7.1-RELEASE = Panic
>  > 7.1-RELEASE with fxp from HEAD = Panic
>  > 7.1-PRERELEASE from Tue Nov 25 = operates as expected
>  > 
>  > This is an old card.  Some details on the card:
>  > 
>  > fxp0: <Intel 82559 Pro/100 Ethernet> port 0xd100-0xd13f mem 
>  > 0xfca03000-0xfca03fff,0xfc800000-0xfc8fffff irq 17 at device 9.0 on pci0
>  > miibus0: <MII bus> on fxp0
>  > inphy0: <i82555 10/100 media interface> PHY 1 on miibus0
>  > inphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
>  > fxp0: Ethernet address: 00:d0:b7:6c:1c:0a
>  > fxp0: [ITHREAD]
>  > 
>  > fxp0@pci0:0:9:0:	class=0x020000 card=0x000b8086 chip=0x12298086 
>  > rev=0x08 hdr=0x00
>  >     vendor     = 'Intel Corporation'
>  >     device     = '82550/1/7/8/9 EtherExpress PRO/100(B) Ethernet Adapter'
>  >     class      = network
>  >     subclass   = ethernet
>  > 
>  > As a test, I unplugged the ethernet cable and the system booted fully, 
>  > however it produced a panic as soon as I connected the cable.  This 
>  > backtrace is from 7.1-RELEASE with fxp sources from HEAD.
>  > 
> 
> I still can't reproduce this but would you try fxp(4) in the
> following URLs?
> http://people.freebsd.org/~yongari/fxp/if_fxp.c
> http://people.freebsd.org/~yongari/fxp/if_fxpreg.h
> http://people.freebsd.org/~yongari/fxp/if_fxpvar.h
> 

With this version, the system still panics as before.

After the system panic with this patch, I went into the bios and 
disabled all unnecessary hardware such as parallel port, usb controller 
and on-board audio.  The resulting panic below appears different.

Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address	= 0x400
fault code		= supervisor read, page not present
instruction pointer	= 0x20:0xc07eefec
stack pointer	        = 0x28:0xe4339ac0
frame pointer	        = 0x28:0xe4339ae4
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		= 28 (irq23: vr0)
trap number		= 12
panic: page fault
cpuid = 0
Uptime: 50s
Physical memory: 995 MB
Dumping 162 MB: 147 131 115 99 83 67 51 35 19 3

....

(kgdb) list *0xc07eefec
0xc07eefec is in sbappendaddr_locked 
(/usr/src.local/sys/kern/uipc_sockbuf.c:652).
647		if (n)
648			n->m_next = m0;		/* concatenate data to control */
649		else
650			control = m0;
651		m->m_next = control;
652		for (n = m; n->m_next != NULL; n = n->m_next)
653			sballoc(sb, n);
654		sballoc(sb, n);
655		nlast = n;
656		SBLINKRECORD(sb, m);
(kgdb) bt
#0  doadump () at pcpu.h:196
#1  0xc079cf07 in boot (howto=260) at 
/usr/src.local/sys/kern/kern_shutdown.c:418
#2  0xc079d1d9 in panic (fmt=Variable "fmt" is not available.
) at /usr/src.local/sys/kern/kern_shutdown.c:574
#3  0xc0ab110c in trap_fatal (frame=0xe4339a80, eva=1024) at 
/usr/src.local/sys/i386/i386/trap.c:939
#4  0xc0ab1390 in trap_pfault (frame=0xe4339a80, usermode=0, eva=1024) 
at /usr/src.local/sys/i386/i386/trap.c:852
#5  0xc0ab1d4c in trap (frame=0xe4339a80) at 
/usr/src.local/sys/i386/i386/trap.c:530
#6  0xc0a97bbb in calltrap () at 
/usr/src.local/sys/i386/i386/exception.s:159
#7  0xc07eefec in sbappendaddr_locked (sb=0xc5bacd50, asa=0xe4339b90, 
m0=0xc4167000, control=0xc4167000) at 
/usr/src.local/sys/kern/uipc_sockbuf.c:652
#8  0xc08ecb71 in udp_append (inp=Variable "inp" is not available.
) at /usr/src.local/sys/netinet/udp_usrreq.c:254
#9  0xc08edf7a in udp_input (m=0xc4167000, off=20) at 
/usr/src.local/sys/netinet/udp_usrreq.c:567
#10 0xc087d320 in ip_input (m=0xc4167000) at 
/usr/src.local/sys/netinet/ip_input.c:665
#11 0xc0842a85 in netisr_dispatch (num=2, m=0xc4167000) at 
/usr/src.local/sys/net/netisr.c:185
#12 0xc08389f1 in ether_demux (ifp=0xc41b6800, m=0xc4167000) at 
/usr/src.local/sys/net/if_ethersubr.c:834
#13 0xc0838de3 in ether_input (ifp=0xc41b6800, m=0xc4167000) at 
/usr/src.local/sys/net/if_ethersubr.c:692
#14 0xc071750b in vr_intr (arg=0xc41c8000) at 
/usr/src.local/sys/dev/vr/if_vr.c:1415
#15 0xc077bf0b in ithread_loop (arg=0xc41c5550) at 
/usr/src.local/sys/kern/kern_intr.c:1088
#16 0xc0778a79 in fork_exit (callout=0xc077bd50 <ithread_loop>, 
arg=0xc41c5550, frame=0xe4339d38) at /usr/src.local/sys/kern/kern_fork.c:804
#17 0xc0a97c30 in fork_trampoline () at 
/usr/src.local/sys/i386/i386/exception.s:264
(kgdb)

From brian at box201.com  Tue Jan  6 16:32:22 2009
From: brian at box201.com (Brian Duke)
Date: Tue Jan  6 16:32:30 2009
Subject: cvsup freebsd 6_2 to freebsd 7_1 not upgrading?
In-Reply-To: <20090105223216.GE11721@lor.one-eyed-alien.net>
References: <32085272.968201231189478546.JavaMail.root@wmail9.libero.it>	<010e01c96f82$252875d0$6f796170$@com>
	<20090105223216.GE11721@lor.one-eyed-alien.net>
Message-ID: <024201c9701c$572c3540$05849fc0$@com>

This is very odd.
I got desperate last night and steeled myself for a reinstall. Copied all
the known keeper files to an alternate drive including /home, /etc,
/usr/local/etc and a couple others. It's on a completely separate drive with
no OS just files on it. I downloaded what I thought was 7.1 iso and burned
the image to disks from my spare windows machine. I sure of it as I made a
point to upgrade to 7.1

I stuck in the install disk and rebooted. 
I didn't mess with fdisk left it the same. 
Used disk druid to set the mount points like they were before and toggle
newfs to Yes.

I watched the install perform a newfs on the mount points. As it was loading
the new kernel and support files I kept seeing snippets saying file for
FreeBSD 7.0 loaded. I figured there were legacy files being added and let it
continue. The install disks loaded everything with success. The
congratulation screen popped up and set the final options. I got to the
reboot and it warned me to take out the disk before rebooting.

While booting I saw right after choosing normal boot it said proudly
"FreeBSD 6.2-RELEASE".

My question is this, after a system boots from the CD, performs a newfs,
loads everything in /usr perfectly as all my /home directories are gone and
/root is empty. How can a kernel continue to exist?

I'm done with newfs as that seems to have no effect. I'm going to fdisk the
system now and seriously mess with the MBR. But just before I do, anyone
have any idea how install disks doing a standard install do not overwrite
the kernel?  


Agrapha...

From chris at arnold.se  Tue Jan  6 16:42:09 2009
From: chris at arnold.se (Christopher Arnold)
Date: Tue Jan  6 16:42:16 2009
Subject: freebsd-update painfully slow - slower than source code build
 of world and kernel
In-Reply-To: <08B216B4-79AB-45AB-AB4D-C8CD62196B87@danielbond.org>
References: <DA7E7739-0631-4B00-8CA8-D8C9E22B2126@danielbond.org>
	<alpine.BSF.2.00.0901061121530.1996@localhost>
	<F6385D88-BFAF-47A0-B598-78C971FCBD7C@danielbond.org>
	<alpine.BSF.2.00.0901061242120.1996@localhost>
	<08B216B4-79AB-45AB-AB4D-C8CD62196B87@danielbond.org>
Message-ID: <alpine.BSF.2.00.0901061731550.1343@localhost>



On Tue, 6 Jan 2009, Daniel Bond wrote:

> reading your answer, you are obviously confusing what I am saying about 
> freebsd-update with the portsnap program. Also, I also wrote in my first post 
>
No i'm not confusing them, just trying to follow two subjects at the same 
time. Sorry if that is confusing.

> that HTTP_PROXY / Caching proxy server does not help me much. This is because 
> I download a lot of "initial tarball snapshots".. I would rarely see "Cache 
> hits" in my proxy log. I guess I could set something up to fetch nightly via 
> proxy, to keep the data in house, for when I need it. I don't want to use a 
> PROXY server, I feel this is attacking the problem at the wrong end.
>
Ok, lets go again. Either you mirror (maybe by having a squid proxy and 
walk the tree) and thats going to me even worse for you. Or you use a squid 
proxy to keep stuff you need close to you and share among different 
installations.

Or you setup one or more national squid proxies and configure your 
machines manually just like you do with cvsup.



> I agree, I am interested to hear the views of the wise ones. Personally I'm 
> going back to CVSup until freebsd-update and portsnap mirrors are in a more 
> distributed or usable state.
>
At least portsnap started to work for me earlier today. Havn't tried 
update yet.

But yes i agree, update and portsnap infrastructure could be done better.
I have some ideas and will try to write them down in a while.

 	/Chris
From db at danielbond.org  Tue Jan  6 17:04:00 2009
From: db at danielbond.org (Daniel Bond)
Date: Tue Jan  6 17:04:08 2009
Subject: freebsd-update painfully slow - slower than source code build
	of world and kernel
In-Reply-To: <alpine.BSF.2.00.0901061731550.1343@localhost>
References: <DA7E7739-0631-4B00-8CA8-D8C9E22B2126@danielbond.org>
	<alpine.BSF.2.00.0901061121530.1996@localhost>
	<F6385D88-BFAF-47A0-B598-78C971FCBD7C@danielbond.org>
	<alpine.BSF.2.00.0901061242120.1996@localhost>
	<08B216B4-79AB-45AB-AB4D-C8CD62196B87@danielbond.org>
	<alpine.BSF.2.00.0901061731550.1343@localhost>
Message-ID: <C68E4D01-D846-4FE4-B71E-9D7ED2EA55E2@danielbond.org>

The same could be said about CVSup, one could write a caching cvsup  
proxy-server, and then we could just get rid of all the other cvsup- 
servers, except two (like freebsd-update soon will have). The point  
is, for portsnap and freebsd-update to scale properly, it needs to be  
opened up to the public, like CVSup is. People running a single server  
at home, or maybee two, most like won't want to set up a PROXY server,  
and they would be required to update both servers at the same day for  
the Proxy server to actually cache something - which many may not  
want. And there are a lot of people running a few servers, here and  
there.



Sure, a national squid-proxy could work - although, there is no  
individual proxy setting for portsnap/freebsd-update.. It honors  
HTTP_PROXY environment variable, which a lot of other tools also use.  
Some tools might not work via this proxy, especially for local  
addresses - the administrators of these servers probably don't want  
all the ports tarballs to go via these, and people could use them for  
nasty things. So, then we are back to manually setting/specifying the  
proxy-server, each time one wants to run the commands - which people  
might forget. (Is this getting complicated enough yet..?) We would  
basically be creating a whole lot of new potential problems for the  
users, to solve the problem in question..


I am also interested in learning how the portsnap protocol works,  
maybe there are potential issues with it, that a second eye might  
spot, or room for improvement? From what I gather, Colin is a very  
cleaver guy, so it is not very likely, but still, other people could  
learn from it.

I would like to see these tools as the default recommended tools to  
use in the future, and that is why I am so worried about this.
The point I am trying to make is, or actually the question is: Why is  
freebsd-update (and portsnap) so secretive? Why can't the average Joe  
run his own portsnap-mirror at home? What are we afraid of?

I don't see any problems with this, except maybe loosing some detail  
in Colin's nice graphs (which would be the case for proxies too).


Cheers,


Daniel.


On Jan 6, 2009, at 5:42 PM, Christopher Arnold wrote:

>
>
> On Tue, 6 Jan 2009, Daniel Bond wrote:
>
>> reading your answer, you are obviously confusing what I am saying  
>> about freebsd-update with the portsnap program. Also, I also wrote  
>> in my first post
> No i'm not confusing them, just trying to follow two subjects at the  
> same time. Sorry if that is confusing.
>
>> that HTTP_PROXY / Caching proxy server does not help me much. This  
>> is because I download a lot of "initial tarball snapshots".. I  
>> would rarely see "Cache hits" in my proxy log. I guess I could set  
>> something up to fetch nightly via proxy, to keep the data in house,  
>> for when I need it. I don't want to use a PROXY server, I feel this  
>> is attacking the problem at the wrong end.
>>
> Ok, lets go again. Either you mirror (maybe by having a squid proxy  
> and walk the tree) and thats going to me even worse for you. Or you  
> use a squid proxy to keep stuff you need close to you and share  
> among different installations.
>
> Or you setup one or more national squid proxies and configure your  
> machines manually just like you do with cvsup.
>
>
>
>> I agree, I am interested to hear the views of the wise ones.  
>> Personally I'm going back to CVSup until freebsd-update and  
>> portsnap mirrors are in a more distributed or usable state.
>>
> At least portsnap started to work for me earlier today. Havn't tried  
> update yet.
>
> But yes i agree, update and portsnap infrastructure could be done  
> better.
> I have some ideas and will try to write them down in a while.
>
> 	/Chris
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org 
> "

From brooks at freebsd.org  Tue Jan  6 17:14:03 2009
From: brooks at freebsd.org (Brooks Davis)
Date: Tue Jan  6 17:14:15 2009
Subject: cvsup freebsd 6_2 to freebsd 7_1 not upgrading?
In-Reply-To: <024201c9701c$572c3540$05849fc0$@com>
References: <32085272.968201231189478546.JavaMail.root@wmail9.libero.it>
	<010e01c96f82$252875d0$6f796170$@com>
	<20090105223216.GE11721@lor.one-eyed-alien.net>
	<024201c9701c$572c3540$05849fc0$@com>
Message-ID: <20090106171241.GH11721@lor.one-eyed-alien.net>

On Tue, Jan 06, 2009 at 09:31:48AM -0700, Brian Duke wrote:
> This is very odd.
> I got desperate last night and steeled myself for a reinstall. Copied all
> the known keeper files to an alternate drive including /home, /etc,
> /usr/local/etc and a couple others. It's on a completely separate drive with
> no OS just files on it. I downloaded what I thought was 7.1 iso and burned
> the image to disks from my spare windows machine. I sure of it as I made a
> point to upgrade to 7.1
> 
> I stuck in the install disk and rebooted. 
> I didn't mess with fdisk left it the same. 
> Used disk druid to set the mount points like they were before and toggle
> newfs to Yes.
> 
> I watched the install perform a newfs on the mount points. As it was loading
> the new kernel and support files I kept seeing snippets saying file for
> FreeBSD 7.0 loaded. I figured there were legacy files being added and let it
> continue. The install disks loaded everything with success. The
> congratulation screen popped up and set the final options. I got to the
> reboot and it warned me to take out the disk before rebooting.

I suspect the 7.0 stuff is a bug in the release media, but almost
certainly a red herring in this case.

> While booting I saw right after choosing normal boot it said proudly
> "FreeBSD 6.2-RELEASE".
> 
> My question is this, after a system boots from the CD, performs a newfs,
> loads everything in /usr perfectly as all my /home directories are gone and
> /root is empty. How can a kernel continue to exist?
> 
> I'm done with newfs as that seems to have no effect. I'm going to fdisk the
> system now and seriously mess with the MBR. But just before I do, anyone
> have any idea how install disks doing a standard install do not overwrite
> the kernel?  

This is really odd.  It sounds like you are somehow booting from one
root file system (with the 6.2 kernel) and then mounting another one
over the top of it.  I'm not sure quite how I'd go about tracking this
down.  A dmesg might help and the output lsdev in the loader might be
interesting.

-- Brooks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090106/d1c0648d/attachment.pgp
From vince at unsane.co.uk  Tue Jan  6 17:31:11 2009
From: vince at unsane.co.uk (Vincent Hoffman)
Date: Tue Jan  6 17:31:19 2009
Subject: freebsd-update painfully slow - slower than source code build
 of world and kernel
In-Reply-To: <C68E4D01-D846-4FE4-B71E-9D7ED2EA55E2@danielbond.org>
References: <DA7E7739-0631-4B00-8CA8-D8C9E22B2126@danielbond.org>	<alpine.BSF.2.00.0901061121530.1996@localhost>	<F6385D88-BFAF-47A0-B598-78C971FCBD7C@danielbond.org>	<alpine.BSF.2.00.0901061242120.1996@localhost>	<08B216B4-79AB-45AB-AB4D-C8CD62196B87@danielbond.org>	<alpine.BSF.2.00.0901061731550.1343@localhost>
	<C68E4D01-D846-4FE4-B71E-9D7ED2EA55E2@danielbond.org>
Message-ID: <49639546.5070608@unsane.co.uk>

Daniel Bond wrote:
> The same could be said about CVSup, one could write a caching cvsup
> proxy-server, and then we could just get rid of all the other
> cvsup-servers, except two (like freebsd-update soon will have). The
> point is, for portsnap and freebsd-update to scale properly, it needs
> to be opened up to the public, like CVSup is. People running a single
> server at home, or maybee two, most like won't want to set up a PROXY
> server, and they would be required to update both servers at the same
> day for the Proxy server to actually cache something - which many may
> not want. And there are a lot of people running a few servers, here
> and there.
>
>
>
> Sure, a national squid-proxy could work - although, there is no
> individual proxy setting for portsnap/freebsd-update.. It honors
> HTTP_PROXY environment variable, which a lot of other tools also use.
> Some tools might not work via this proxy, especially for local
> addresses - the administrators of these servers probably don't want
> all the ports tarballs to go via these, and people could use them for
> nasty things. So, then we are back to manually setting/specifying the
> proxy-server, each time one wants to run the commands - which people
> might forget. (Is this getting complicated enough yet..?) We would
> basically be creating a whole lot of new potential problems for the
> users, to solve the problem in question..
>
>
> I am also interested in learning how the portsnap protocol works,
> maybe there are potential issues with it, that a second eye might
> spot, or room for improvement? From what I gather, Colin is a very
> cleaver guy, so it is not very likely, but still, other people could
> learn from it.
>
well portsnap/freebsd-update are shell scripts so not too hard to read.
The actual transfer protocol is  piplined http and is done by
/usr/libexec/phttpget  (in base so src code available
/usr/src/usr.sbin/portsnap/phttpget/phttpget.c )
also see http://www.daemonology.net/phttpget/


> I would like to see these tools as the default recommended tools to
> use in the future, and that is why I am so worried about this.
> The point I am trying to make is, or actually the question is: Why is
> freebsd-update (and portsnap) so secretive? Why can't the average Joe
> run his own portsnap-mirror at home? What are we afraid of?
I seem to remember once reading that Colin wanted to make it a more
polished system before he release it, but i cant find that email anymore.

Vince
>
> I don't see any problems with this, except maybe loosing some detail
> in Colin's nice graphs (which would be the case for proxies too).
>
>
> Cheers,
>
>
> Daniel.
>
>
> On Jan 6, 2009, at 5:42 PM, Christopher Arnold wrote:
>
>>
>>
>> On Tue, 6 Jan 2009, Daniel Bond wrote:
>>
>>> reading your answer, you are obviously confusing what I am saying
>>> about freebsd-update with the portsnap program. Also, I also wrote
>>> in my first post
>> No i'm not confusing them, just trying to follow two subjects at the
>> same time. Sorry if that is confusing.
>>
>>> that HTTP_PROXY / Caching proxy server does not help me much. This
>>> is because I download a lot of "initial tarball snapshots".. I would
>>> rarely see "Cache hits" in my proxy log. I guess I could set
>>> something up to fetch nightly via proxy, to keep the data in house,
>>> for when I need it. I don't want to use a PROXY server, I feel this
>>> is attacking the problem at the wrong end.
>>>
>> Ok, lets go again. Either you mirror (maybe by having a squid proxy
>> and walk the tree) and thats going to me even worse for you. Or you
>> use a squid proxy to keep stuff you need close to you and share among
>> different installations.
>>
>> Or you setup one or more national squid proxies and configure your
>> machines manually just like you do with cvsup.
>>
>>
>>
>>> I agree, I am interested to hear the views of the wise ones.
>>> Personally I'm going back to CVSup until freebsd-update and portsnap
>>> mirrors are in a more distributed or usable state.
>>>
>> At least portsnap started to work for me earlier today. Havn't tried
>> update yet.
>>
>> But yes i agree, update and portsnap infrastructure could be done
>> better.
>> I have some ideas and will try to write them down in a while.
>>
>>     /Chris
>> _______________________________________________
>> freebsd-stable@freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
>> To unsubscribe, send any mail to
>> "freebsd-stable-unsubscribe@freebsd.org"
>
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"

From gavin at FreeBSD.org  Tue Jan  6 17:32:23 2009
From: gavin at FreeBSD.org (Gavin Atkinson)
Date: Tue Jan  6 17:32:29 2009
Subject: cvsup freebsd 6_2 to freebsd 7_1 not upgrading?
In-Reply-To: <024201c9701c$572c3540$05849fc0$@com>
References: <32085272.968201231189478546.JavaMail.root@wmail9.libero.it>
	<010e01c96f82$252875d0$6f796170$@com>
	<20090105223216.GE11721@lor.one-eyed-alien.net>
	<024201c9701c$572c3540$05849fc0$@com>
Message-ID: <1231261256.86657.12.camel@buffy.york.ac.uk>

On Tue, 2009-01-06 at 09:31 -0700, Brian Duke wrote:
> This is very odd.
> I got desperate last night and steeled myself for a reinstall. Copied all
> the known keeper files to an alternate drive including /home, /etc,
> /usr/local/etc and a couple others. It's on a completely separate drive with
> no OS just files on it. I downloaded what I thought was 7.1 iso and burned
> the image to disks from my spare windows machine. I sure of it as I made a
> point to upgrade to 7.1
> 
> I stuck in the install disk and rebooted. 
> I didn't mess with fdisk left it the same. 
> Used disk druid to set the mount points like they were before and toggle
> newfs to Yes.
> 
> I watched the install perform a newfs on the mount points. As it was loading
> the new kernel and support files I kept seeing snippets saying file for
> FreeBSD 7.0 loaded. I figured there were legacy files being added and let it
> continue. The install disks loaded everything with success. The
> congratulation screen popped up and set the final options. I got to the
> reboot and it warned me to take out the disk before rebooting.
> 
> While booting I saw right after choosing normal boot it said proudly
> "FreeBSD 6.2-RELEASE".

A few ideas:

1)  Do you have, or have you ever had, mirrored disks?  Is it possible
that the kernel is not being loaded from the disk you think it is being
loaded from?

2) Is it possible that you are loading a kernel that is not the default
kernel?  e.g. At some point in the past, have you 

Secondly, can you run the following commands and show the output:

sysctl kern.bootfile
ls -li /boot /boot/kernel/kernel `sysctl -n kern.bootfile`
cat /boot/loader.conf
cat /boot/nextboot.conf
strings /boot/kernel/kernel | tail -6

Thanks,

Gavin

From rnoland at FreeBSD.org  Tue Jan  6 18:04:03 2009
From: rnoland at FreeBSD.org (Robert Noland)
Date: Tue Jan  6 18:04:11 2009
Subject: Pending MFC of drm updates
Message-ID: <1231263380.57454.23.camel@squirrel.corp.cox.com>

I am planning to merge most all of the drm from -CURRENT to releng_7
shortly.  The merge that I have staged includes the following.

Merged /head/sys:r182080,182467-182469,182883-182884,183573,183603-183605,
	183828,183830-183834,184212-184213,184263,184373-184375

There are really too many updates/fixes to mention as the drm from 7 is
more than 2 years old now.  This has support for several newer Intel and
AMD/ATI chips, (no r6/7xx yet, but soon(tm)).

I have a patch available for testing at
http://people.freebsd.org/~rnoland/drm-update-7-010609.patch.bz2

robert.

-- 
Robert Noland <rnoland@FreeBSD.org>
FreeBSD
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090106/d1821e81/attachment.pgp
From tinderbox at freebsd.org  Tue Jan  6 18:06:43 2009
From: tinderbox at freebsd.org (FreeBSD Tinderbox)
Date: Tue Jan  6 18:07:08 2009
Subject: [releng_6 tinderbox] failure on i386/i386
Message-ID: <20090106174535.C12D6241BA@freebsd-legacy.sentex.ca>

TB --- 2009-01-06 17:43:24 - tinderbox 2.6 running on freebsd-legacy.sentex.ca
TB --- 2009-01-06 17:43:24 - starting RELENG_6 tinderbox run for i386/i386
TB --- 2009-01-06 17:43:24 - cleaning the object tree
TB --- 2009-01-06 17:44:17 - cvsupping the source tree
TB --- 2009-01-06 17:44:17 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_6/i386/i386/supfile
TB --- 2009-01-06 17:44:27 - building world
TB --- 2009-01-06 17:44:27 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-01-06 17:44:27 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-01-06 17:44:27 - TARGET=i386
TB --- 2009-01-06 17:44:27 - TARGET_ARCH=i386
TB --- 2009-01-06 17:44:27 - TZ=UTC
TB --- 2009-01-06 17:44:27 - __MAKE_CONF=/dev/null
TB --- 2009-01-06 17:44:27 - cd /src
TB --- 2009-01-06 17:44:27 - /usr/bin/make -B buildworld
>>> Rebuilding the temporary build tree
>>> stage 1.1: legacy release compatibility shims
>>> stage 1.2: bootstrap tools
>>> stage 2.1: cleaning up the object tree
[...]
===> usr.sbin/wlconfig (cleandir)
rm -f wlconfig wlconfig.o wlconfig.8.gz wlconfig.8.cat.gz
rm -f .depend GPATH GRTAGS GSYMS GTAGS
===> usr.sbin/wpa (cleandir)
===> usr.sbin/wpa/wpa_supplicant (cleandir)
"Makefile", line 14: Malformed conditional (${MK_EXAMPLES} != "no")
"Makefile", line 17: if-less endif
make: fatal errors encountered -- cannot continue
*** Error code 1

Stop in /src/usr.sbin/wpa.
*** Error code 1

Stop in /src/usr.sbin.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
TB --- 2009-01-06 17:45:35 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2009-01-06 17:45:35 - ERROR: failed to build world
TB --- 2009-01-06 17:45:35 - 25.76 user 11.39 system 131.62 real


http://tinderbox.des.no/tinderbox-releng_6-RELENG_6-i386-i386.full
From tinderbox at freebsd.org  Tue Jan  6 18:06:44 2009
From: tinderbox at freebsd.org (FreeBSD Tinderbox)
Date: Tue Jan  6 18:07:09 2009
Subject: [releng_6 tinderbox] failure on i386/pc98
Message-ID: <20090106174541.D01A8241BC@freebsd-legacy.sentex.ca>

TB --- 2009-01-06 17:43:25 - tinderbox 2.6 running on freebsd-legacy.sentex.ca
TB --- 2009-01-06 17:43:25 - starting RELENG_6 tinderbox run for i386/pc98
TB --- 2009-01-06 17:43:25 - cleaning the object tree
TB --- 2009-01-06 17:44:20 - cvsupping the source tree
TB --- 2009-01-06 17:44:20 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_6/i386/pc98/supfile
TB --- 2009-01-06 17:44:30 - building world
TB --- 2009-01-06 17:44:30 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-01-06 17:44:30 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-01-06 17:44:30 - TARGET=pc98
TB --- 2009-01-06 17:44:30 - TARGET_ARCH=i386
TB --- 2009-01-06 17:44:30 - TZ=UTC
TB --- 2009-01-06 17:44:30 - __MAKE_CONF=/dev/null
TB --- 2009-01-06 17:44:30 - cd /src
TB --- 2009-01-06 17:44:30 - /usr/bin/make -B buildworld
>>> Rebuilding the temporary build tree
>>> stage 1.1: legacy release compatibility shims
>>> stage 1.2: bootstrap tools
>>> stage 2.1: cleaning up the object tree
[...]
===> usr.sbin/wicontrol (cleandir)
rm -f wicontrol wicontrol.o wicontrol.8.gz wicontrol.8.cat.gz
rm -f .depend GPATH GRTAGS GSYMS GTAGS
===> usr.sbin/wpa (cleandir)
===> usr.sbin/wpa/wpa_supplicant (cleandir)
"Makefile", line 14: Malformed conditional (${MK_EXAMPLES} != "no")
"Makefile", line 17: if-less endif
make: fatal errors encountered -- cannot continue
*** Error code 1

Stop in /src/usr.sbin/wpa.
*** Error code 1

Stop in /src/usr.sbin.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
TB --- 2009-01-06 17:45:41 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2009-01-06 17:45:41 - ERROR: failed to build world
TB --- 2009-01-06 17:45:41 - 25.56 user 11.64 system 136.22 real


http://tinderbox.des.no/tinderbox-releng_6-RELENG_6-i386-pc98.full
From tinderbox at freebsd.org  Tue Jan  6 18:06:45 2009
From: tinderbox at freebsd.org (FreeBSD Tinderbox)
Date: Tue Jan  6 18:07:10 2009
Subject: [releng_6 tinderbox] failure on amd64/amd64
Message-ID: <20090106174324.2C919241BA@freebsd-legacy.sentex.ca>

TB --- 2009-01-06 17:41:34 - tinderbox 2.6 running on freebsd-legacy.sentex.ca
TB --- 2009-01-06 17:41:34 - starting RELENG_6 tinderbox run for amd64/amd64
TB --- 2009-01-06 17:41:34 - cleaning the object tree
TB --- 2009-01-06 17:42:15 - cvsupping the source tree
TB --- 2009-01-06 17:42:15 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_6/amd64/amd64/supfile
TB --- 2009-01-06 17:42:24 - building world
TB --- 2009-01-06 17:42:24 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-01-06 17:42:24 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-01-06 17:42:24 - TARGET=amd64
TB --- 2009-01-06 17:42:24 - TARGET_ARCH=amd64
TB --- 2009-01-06 17:42:24 - TZ=UTC
TB --- 2009-01-06 17:42:24 - __MAKE_CONF=/dev/null
TB --- 2009-01-06 17:42:24 - cd /src
TB --- 2009-01-06 17:42:24 - /usr/bin/make -B buildworld
>>> Rebuilding the temporary build tree
>>> stage 1.1: legacy release compatibility shims
>>> stage 1.2: bootstrap tools
>>> stage 2.1: cleaning up the object tree
[...]
===> usr.sbin/wicontrol (cleandir)
rm -f wicontrol wicontrol.o wicontrol.8.gz wicontrol.8.cat.gz
rm -f .depend GPATH GRTAGS GSYMS GTAGS
===> usr.sbin/wpa (cleandir)
===> usr.sbin/wpa/wpa_supplicant (cleandir)
"Makefile", line 14: Malformed conditional (${MK_EXAMPLES} != "no")
"Makefile", line 17: if-less endif
make: fatal errors encountered -- cannot continue
*** Error code 1

Stop in /src/usr.sbin/wpa.
*** Error code 1

Stop in /src/usr.sbin.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
TB --- 2009-01-06 17:43:23 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2009-01-06 17:43:23 - ERROR: failed to build world
TB --- 2009-01-06 17:43:23 - 25.09 user 11.80 system 109.20 real


http://tinderbox.des.no/tinderbox-releng_6-RELENG_6-amd64-amd64.full
From tinderbox at freebsd.org  Tue Jan  6 18:06:45 2009
From: tinderbox at freebsd.org (FreeBSD Tinderbox)
Date: Tue Jan  6 18:07:11 2009
Subject: [releng_6 tinderbox] failure on sparc64/sparc64
Message-ID: <20090106174659.8F07A241BA@freebsd-legacy.sentex.ca>

TB --- 2009-01-06 17:45:35 - tinderbox 2.6 running on freebsd-legacy.sentex.ca
TB --- 2009-01-06 17:45:35 - starting RELENG_6 tinderbox run for sparc64/sparc64
TB --- 2009-01-06 17:45:35 - cleaning the object tree
TB --- 2009-01-06 17:46:00 - cvsupping the source tree
TB --- 2009-01-06 17:46:00 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_6/sparc64/sparc64/supfile
TB --- 2009-01-06 17:46:07 - building world
TB --- 2009-01-06 17:46:07 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-01-06 17:46:07 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-01-06 17:46:07 - TARGET=sparc64
TB --- 2009-01-06 17:46:07 - TARGET_ARCH=sparc64
TB --- 2009-01-06 17:46:07 - TZ=UTC
TB --- 2009-01-06 17:46:07 - __MAKE_CONF=/dev/null
TB --- 2009-01-06 17:46:07 - cd /src
TB --- 2009-01-06 17:46:07 - /usr/bin/make -B buildworld
>>> Rebuilding the temporary build tree
>>> stage 1.1: legacy release compatibility shims
>>> stage 1.2: bootstrap tools
>>> stage 2.1: cleaning up the object tree
[...]
===> usr.sbin/wicontrol (cleandir)
rm -f wicontrol wicontrol.o wicontrol.8.gz wicontrol.8.cat.gz
rm -f .depend GPATH GRTAGS GSYMS GTAGS
===> usr.sbin/wpa (cleandir)
===> usr.sbin/wpa/wpa_supplicant (cleandir)
"Makefile", line 14: Malformed conditional (${MK_EXAMPLES} != "no")
"Makefile", line 17: if-less endif
make: fatal errors encountered -- cannot continue
*** Error code 1

Stop in /src/usr.sbin/wpa.
*** Error code 1

Stop in /src/usr.sbin.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
TB --- 2009-01-06 17:46:59 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2009-01-06 17:46:59 - ERROR: failed to build world
TB --- 2009-01-06 17:46:59 - 25.13 user 10.60 system 83.62 real


http://tinderbox.des.no/tinderbox-releng_6-RELENG_6-sparc64-sparc64.full
From db at danielbond.org  Tue Jan  6 19:16:25 2009
From: db at danielbond.org (Daniel Bond)
Date: Tue Jan  6 19:16:32 2009
Subject: freebsd-update painfully slow - slower than source code build
	of world and kernel
In-Reply-To: <49639546.5070608@unsane.co.uk>
References: <DA7E7739-0631-4B00-8CA8-D8C9E22B2126@danielbond.org>	<alpine.BSF.2.00.0901061121530.1996@localhost>	<F6385D88-BFAF-47A0-B598-78C971FCBD7C@danielbond.org>	<alpine.BSF.2.00.0901061242120.1996@localhost>	<08B216B4-79AB-45AB-AB4D-C8CD62196B87@danielbond.org>	<alpine.BSF.2.00.0901061731550.1343@localhost>
	<C68E4D01-D846-4FE4-B71E-9D7ED2EA55E2@danielbond.org>
	<49639546.5070608@unsane.co.uk>
Message-ID: <484FA671-3B56-4A7C-9551-37AD2D1AF7B3@danielbond.org>

Hi,

thanks for useful and relevant information. However, this is just one  
part of the process. Generating the diffs,
prepping the server, and the whole server-side setup/management of it  
is another - I am sure there are tools for this too.

Cheers,

Daniel.


On Jan 6, 2009, at 6:30 PM, Vincent Hoffman wrote:

> Daniel Bond wrote:
>> The same could be said about CVSup, one could write a caching cvsup
>> proxy-server, and then we could just get rid of all the other
>> cvsup-servers, except two (like freebsd-update soon will have). The
>> point is, for portsnap and freebsd-update to scale properly, it needs
>> to be opened up to the public, like CVSup is. People running a single
>> server at home, or maybee two, most like won't want to set up a PROXY
>> server, and they would be required to update both servers at the same
>> day for the Proxy server to actually cache something - which many may
>> not want. And there are a lot of people running a few servers, here
>> and there.
>>
>>
>>
>> Sure, a national squid-proxy could work - although, there is no
>> individual proxy setting for portsnap/freebsd-update.. It honors
>> HTTP_PROXY environment variable, which a lot of other tools also use.
>> Some tools might not work via this proxy, especially for local
>> addresses - the administrators of these servers probably don't want
>> all the ports tarballs to go via these, and people could use them for
>> nasty things. So, then we are back to manually setting/specifying the
>> proxy-server, each time one wants to run the commands - which people
>> might forget. (Is this getting complicated enough yet..?) We would
>> basically be creating a whole lot of new potential problems for the
>> users, to solve the problem in question..
>>
>>
>> I am also interested in learning how the portsnap protocol works,
>> maybe there are potential issues with it, that a second eye might
>> spot, or room for improvement? From what I gather, Colin is a very
>> cleaver guy, so it is not very likely, but still, other people could
>> learn from it.
>>
> well portsnap/freebsd-update are shell scripts so not too hard to  
> read.
> The actual transfer protocol is  piplined http and is done by
> /usr/libexec/phttpget  (in base so src code available
> /usr/src/usr.sbin/portsnap/phttpget/phttpget.c )
> also see http://www.daemonology.net/phttpget/
>
>
>> I would like to see these tools as the default recommended tools to
>> use in the future, and that is why I am so worried about this.
>> The point I am trying to make is, or actually the question is: Why is
>> freebsd-update (and portsnap) so secretive? Why can't the average Joe
>> run his own portsnap-mirror at home? What are we afraid of?
> I seem to remember once reading that Colin wanted to make it a more
> polished system before he release it, but i cant find that email  
> anymore.
>
> Vince
>>
>> I don't see any problems with this, except maybe loosing some detail
>> in Colin's nice graphs (which would be the case for proxies too).
>>
>>
>> Cheers,
>>
>>
>> Daniel.
>>
>>
>> On Jan 6, 2009, at 5:42 PM, Christopher Arnold wrote:
>>
>>>
>>>
>>> On Tue, 6 Jan 2009, Daniel Bond wrote:
>>>
>>>> reading your answer, you are obviously confusing what I am saying
>>>> about freebsd-update with the portsnap program. Also, I also wrote
>>>> in my first post
>>> No i'm not confusing them, just trying to follow two subjects at the
>>> same time. Sorry if that is confusing.
>>>
>>>> that HTTP_PROXY / Caching proxy server does not help me much. This
>>>> is because I download a lot of "initial tarball snapshots".. I  
>>>> would
>>>> rarely see "Cache hits" in my proxy log. I guess I could set
>>>> something up to fetch nightly via proxy, to keep the data in house,
>>>> for when I need it. I don't want to use a PROXY server, I feel this
>>>> is attacking the problem at the wrong end.
>>>>
>>> Ok, lets go again. Either you mirror (maybe by having a squid proxy
>>> and walk the tree) and thats going to me even worse for you. Or you
>>> use a squid proxy to keep stuff you need close to you and share  
>>> among
>>> different installations.
>>>
>>> Or you setup one or more national squid proxies and configure your
>>> machines manually just like you do with cvsup.
>>>
>>>
>>>
>>>> I agree, I am interested to hear the views of the wise ones.
>>>> Personally I'm going back to CVSup until freebsd-update and  
>>>> portsnap
>>>> mirrors are in a more distributed or usable state.
>>>>
>>> At least portsnap started to work for me earlier today. Havn't tried
>>> update yet.
>>>
>>> But yes i agree, update and portsnap infrastructure could be done
>>> better.
>>> I have some ideas and will try to write them down in a while.
>>>
>>>    /Chris
>>> _______________________________________________
>>> freebsd-stable@freebsd.org mailing list
>>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
>>> To unsubscribe, send any mail to
>>> "freebsd-stable-unsubscribe@freebsd.org"
>>
>> _______________________________________________
>> freebsd-stable@freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
>> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org 
>> "
>
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org 
> "

From royce at alaska.net  Tue Jan  6 19:53:02 2009
From: royce at alaska.net (Royce Williams)
Date: Tue Jan  6 19:53:09 2009
Subject: freebsd-update painfully slow - slower than source code build
 of world and kernel
In-Reply-To: <484FA671-3B56-4A7C-9551-37AD2D1AF7B3@danielbond.org>
References: <DA7E7739-0631-4B00-8CA8-D8C9E22B2126@danielbond.org>	<alpine.BSF.2.00.0901061121530.1996@localhost>	<F6385D88-BFAF-47A0-B598-78C971FCBD7C@danielbond.org>	<alpine.BSF.2.00.0901061242120.1996@localhost>	<08B216B4-79AB-45AB-AB4D-C8CD62196B87@danielbond.org>	<alpine.BSF.2.00.0901061731550.1343@localhost>	<C68E4D01-D846-4FE4-B71E-9D7ED2EA55E2@danielbond.org>	<49639546.5070608@unsane.co.uk>
	<484FA671-3B56-4A7C-9551-37AD2D1AF7B3@danielbond.org>
Message-ID: <4963B396.9050609@alaska.net>

Daniel Bond wrote, on 1/6/2009 10:16 AM:
> thanks for useful and relevant information. However, this is just one
> part of the process. Generating the diffs,
> prepping the server, and the whole server-side setup/management of it is
> another - I am sure there are tools for this too.

http://www.freebsd.org/cgi/cvsweb.cgi/projects/freebsd-update-server/

Royce

-- 
Royce D. Williams                                   - http://royce.ws/
             We always choose it for itself.  - Aristotle
From cperciva at freebsd.org  Tue Jan  6 20:57:01 2009
From: cperciva at freebsd.org (Colin Percival)
Date: Tue Jan  6 20:57:07 2009
Subject: FreeBSD Update slow right now, please be patient
Message-ID: <4963C527.5030207@freebsd.org>

Hi all,

FreeBSD Update is being slow right now due to server load issues.

It will improve.

Please be patient.

-- 
Colin Percival
Security Officer, FreeBSD | freebsd.org | The power to serve
Founder / author, Tarsnap | tarsnap.com | Online backups for the truly paranoid
From rsmith at xs4all.nl  Tue Jan  6 21:08:52 2009
From: rsmith at xs4all.nl (Roland Smith)
Date: Tue Jan  6 21:08:59 2009
Subject: Samsung SCX-4200 printer
In-Reply-To: <20090105232354.GA85619@onelab2.iet.unipi.it>
References: <20090104221422.GA3114@pollux2.free.local.net>
	<20090105173635.575e32ff.torfinn.ingolfsen@broadpark.no>
	<20090105164403.GE3756@trusted-logic.com>
	<20090105222623.GA52838@slackbox.xs4all.nl>
	<20090105232354.GA85619@onelab2.iet.unipi.it>
Message-ID: <20090106210845.GA88675@slackbox.xs4all.nl>

On Tue, Jan 06, 2009 at 12:23:54AM +0100, Luigi Rizzo wrote:
> On Mon, Jan 05, 2009 at 11:26:23PM +0100, Roland Smith wrote:
> > On Mon, Jan 05, 2009 at 05:44:03PM +0100, Erwan David wrote:
> > > On Mon, Jan 05, 2009 at 05:36:35PM CET, Torfinn Ingolfsen <torfinn.ingolfsen@broadpark.no> said:
> > > > On Sun, 04 Jan 2009 23:14:22 +0100
> > > > Harald Weis <hawei@free.fr> wrote:
> > > > 
> > > > > Is there a way to install the SCX-4200 printer on a FreeBSD box ?
> > > > > The printer is delivered with the install software required for Linux.
> > > > > And CUPS does not seem to "know" it.
> ...
> > > It is not always sufficient. My Brother DCP-540 CN is said to work
> > > perfectly, but only with brother binary linux drivers, under linux. I
> > > did not find any way to make it work under freeBSD.
> > 
> > This should be a FAQ: do yourself a favor and get a printer that
> > supports postscript. It will work with little effort with most
> > UNIX-based program (because they usually support postscript output) and
> > with most spoolers.
> 
> Actually, this is debatable. If everybody were following your
> suggestion we wouldn't have support for a lot of devices (printers,
> disk controllers, scanners, wireless and network devices, embedded
> systems) that now do work with FreeBSD or other Open Source systems.

There is actually one crucial difference between printers and the other
classes of hardware you mention. Printers are usually driven by a kind
of page/job description language (postscript, pcl, esc2p etc) whereas
the others are not. So a printing system that generates e.g. postscript
can work with scores of printers.

IMHO it is actually a waste of resources to reverse engineer or write
drivers for printer manufacturers that need to reinvent the wheel with
every model.
 
> We are talking about a 70euro laser printer here

While I agree that is not a lot of money, it is still a pretty expensive
doorstop. 

> it is not unreasonable to take a bit of a risk and try it out, and it
> is also good for the community to have people willing to test new
> hardware and report success or failure.

That is true enough. But the OP didn't sound like someone who bought a
printer to test it. I would not expect those people to need to ask for
assistence on freebsd-questions.

Roland
-- 
R.F.Smith                                   http://www.xs4all.nl/~rsmith/
[plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated]
pgp: 1A2B 477F 9970 BA3C 2914  B7CE 1277 EFB0 C321 A725 (KeyID: C321A725)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090106/7403297b/attachment.pgp
From db at danielbond.org  Tue Jan  6 21:20:14 2009
From: db at danielbond.org (Daniel Bond)
Date: Tue Jan  6 21:20:23 2009
Subject: FreeBSD Update slow right now, please be patient
In-Reply-To: <4963C527.5030207@freebsd.org>
References: <4963C527.5030207@freebsd.org>
Message-ID: <97B99505-158D-47B1-AEE1-E0FF50BEFE85@danielbond.org>

Hi Colin,

is there anything I can do to help? Will this also resolve connect- 
issues close up to future releases?

I had some correspondence with you about additional mirrors earlier,  
but it stopped (guessing too many similar requests, to answer them all).

Cheers,

Daniel.


On Jan 6, 2009, at 9:55 PM, Colin Percival wrote:

> Hi all,
>
> FreeBSD Update is being slow right now due to server load issues.
>
> It will improve.
>
> Please be patient.
>
> -- 
> Colin Percival
> Security Officer, FreeBSD | freebsd.org | The power to serve
> Founder / author, Tarsnap | tarsnap.com | Online backups for the  
> truly paranoid
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org 
> "

From support at stardothosting.com  Tue Jan  6 21:46:52 2009
From: support at stardothosting.com (SDH Support)
Date: Tue Jan  6 21:46:59 2009
Subject: Samsung SCX-4200 printer
In-Reply-To: <20090106210845.GA88675@slackbox.xs4all.nl>
References: <20090104221422.GA3114@pollux2.free.local.net>
	<20090105173635.575e32ff.torfinn.ingolfsen@broadpark.no>
	<20090105164403.GE3756@trusted-logic.com>
	<20090105222623.GA52838@slackbox.xs4all.nl>
	<20090105232354.GA85619@onelab2.iet.unipi.it>
	<20090106210845.GA88675@slackbox.xs4all.nl>
Message-ID: <001401c97048$42bcde80$c8369b80$@com>


> Is there a way to install the SCX-4200 printer on a FreeBSD box ?

I would recommend googling this printer and determining its support on linux
first and then perhaps following the large amount of documentation with
installing CUPS for freebsd. I've gotten many different printers working on
my own.




---
Kevin K.
Systems Administrator
www.webcanadahosting.com 

From peter at simons-rock.edu  Tue Jan  6 22:06:37 2009
From: peter at simons-rock.edu (Peter C. Lai)
Date: Tue Jan  6 22:07:09 2009
Subject: Samsung SCX-4200 printer
In-Reply-To: <001401c97048$42bcde80$c8369b80$@com>
References: <20090104221422.GA3114@pollux2.free.local.net>
	<20090105173635.575e32ff.torfinn.ingolfsen@broadpark.no>
	<20090105164403.GE3756@trusted-logic.com>
	<20090105222623.GA52838@slackbox.xs4all.nl>
	<20090105232354.GA85619@onelab2.iet.unipi.it>
	<20090106210845.GA88675@slackbox.xs4all.nl>
	<001401c97048$42bcde80$c8369b80$@com>
Message-ID: <20090106220632.GU45538@cesium.hyperfine.info>

What language does this printer use? I am a big fan of the minimalistic
BSD LPD/R, so I usually just whip up an output filter that cats everything
(since just about every app natively prints as postscript these days 
[besides gimp-app I guess]) to ghostscript. Works for basically any printer
with PCL or PS support (actually, with some of the the elcheapo PS 
imitations out there, usually PCL5/XL works better). To me, CUPS/Foomatic 
comes with some fancy PPDs and filters, but I think a lot of that is 
bloated since it does similar things under the hood but wrapped in more
layers of magic...

On 2009-01-06 04:46:40PM -0500, SDH Support wrote:
> 
> > Is there a way to install the SCX-4200 printer on a FreeBSD box ?
> 
> I would recommend googling this printer and determining its support on linux
> first and then perhaps following the large amount of documentation with
> installing CUPS for freebsd. I've gotten many different printers working on
> my own.
> 
> 
> 
> 
> ---
> Kevin K.
> Systems Administrator
> www.webcanadahosting.com 
> 
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"

-- 
===========================================================
Peter C. Lai                 | Bard College at Simon's Rock
Systems Administrator        | 84 Alford Rd.
Information Technology Svcs. | Gt. Barrington, MA 01230 USA
peter AT simons-rock.edu     | (413) 528-7428
===========================================================

From torfinn.ingolfsen at broadpark.no  Wed Jan  7 00:25:01 2009
From: torfinn.ingolfsen at broadpark.no (Torfinn Ingolfsen)
Date: Wed Jan  7 00:25:26 2009
Subject: Pending MFC of drm updates
In-Reply-To: <1231263380.57454.23.camel@squirrel.corp.cox.com>
References: <1231263380.57454.23.camel@squirrel.corp.cox.com>
Message-ID: <20090107012457.f9ce6dba.torfinn.ingolfsen@broadpark.no>

On Tue, 06 Jan 2009 12:36:20 -0500
Robert Noland <rnoland@FreeBSD.org> wrote:

> I am planning to merge most all of the drm from -CURRENT to releng_7
> shortly.  The merge that I have staged includes the following.
> 
> Merged /head/sys:r182080,182467-182469,182883-182884,183573,183603-183605,
> 	183828,183830-183834,184212-184213,184263,184373-184375
> 
> There are really too many updates/fixes to mention as the drm from 7
> is more than 2 years old now.  This has support for several newer
> Intel and AMD/ATI chips, (no r6/7xx yet, but soon(tm)).
> 
> I have a patch available for testing at
> http://people.freebsd.org/~rnoland/drm-update-7-010609.patch.bz2

Applied fine to my RELENG_7 / amd64 system (freshly cvsup'ed and built
yesterday):
root@kg-v2# uname -a
FreeBSD kg-v2.kg4.no 7.1-STABLE FreeBSD 7.1-STABLE #1: Tue Jan  6
21:49:31 CET 2009 root@kg-v2.kg4.no:/usr/obj/usr/src/sys/GENERIC  amd64

- except for the patch to sys/modules/drm/i915/Makefile:
The text leading up to this was:
--------------------------
|diff -uNrp -x .svn
|sys/modules/drm/i915/Makefile /home/rnoland/freebsd/base/stable/7/sys/modules/drm/i915/Makefile
|--- sys/modules/drm/i915/Makefile	2009-01-06 10:58:41.000000000
|-0500 ++
|+ /home/rnoland/freebsd/base/stable/7/sys/modules/drm/i915/Makefile
|2008-12-10 21:48:19.000000000 -0500
--------------------------
Patching file Makefile using Plan A...
Hunk #1 failed at 2.
1 out of 1 hunks failed--saving rejects to Makefile.rej

Apparently patch gets confuseed when it finds a file with the same name
in the current directory (which was /usr/src), or perhaps I don't know
how to tell patch how to find the right file.
I just did:
cd /usr/src
patch < /dir/name/patchfile

Anyway, a 'make kernel' fails:
mkdep -f .depend -a   -nostdinc -D_KERNEL -DKLD_MODULE
-DHAVE_KERNEL_OPTION_HEADERS -I. -I@ -I@/contrib/altq
-I/usr/obj/usr/src/sys/GENERIC /usr/src/sys/modules/drm/drm/../../../dev/drm/ati_pcigart.c /usr/src/sys/modules/drm/drm/..
/../../dev/drm/drm_agpsupport.c /usr/src/sys/modules/drm/drm/../../../dev/drm/drm_auth.c /usr/src/sys/modules/drm/drm/../../../dev/drm/drm_bufs.c /usr/src/sys/modules/drm/drm/../../../dev/drm/drm_context.c /usr/src/sys/modules/drm/drm/../../../dev/drm/drm_dma.c /usr/src/sys/modules/drm/drm/../../../dev/drm/drm_drawable.c /usr/src/sys/modules/drm/drm/../../../dev/drm/drm_drv.c /usr/src/sys/modules/drm/drm/../../../dev/drm/drm_fops.c /usr/src/sys/modules/drm/drm/../../../dev/drm/drm_ioctl.c /usr/src/sys/modules/drm/drm/../../../dev/drm/drm_irq.c /usr/src/sys/modules/drm/drm/../../../dev/drm/drm_lock.c /usr/src/sys/modules/drm/drm/../../../dev/drm/drm_memory.c /usr/src/sys/modules/drm/drm/../../../dev/drm/drm_pci.c /usr/src/sys/modules/drm/drm/../../../dev/drm/drm_scatter.c /usr/src/sys/modules/drm/drm/../../../dev/drm/drm_sysctl.c /usr/src/sys/modules/drm/drm/../../../dev/drm/drm_vm.c
In file included
from /usr/src/sys/modules/drm/drm/../../../dev/drm/ati_pcigart.c:37:
@/dev/drm/drmP.h:96:34: error: dev/drm/drm_internal.h: No such file or
directory In file included
from /usr/src/sys/modules/drm/drm/../../../dev/drm/drm_agpsupport.c:39:
@/dev/drm/drmP.h:96:34: error: dev/drm/drm_internal.h: No such file or
directory In file included
from /usr/src/sys/modules/drm/drm/../../../dev/drm/drm_auth.c:39:
@/dev/drm/drmP.h:96:34: error: dev/drm/drm_internal.h: No such file or
directory In file included
from /usr/src/sys/modules/drm/drm/../../../dev/drm/drm_bufs.c:40:
@/dev/drm/drmP.h:96:34: error: dev/drm/drm_internal.h: No such file or
directory In file included
from /usr/src/sys/modules/drm/drm/../../../dev/drm/drm_context.c:38:
@/dev/drm/drmP.h:96:34: error: dev/drm/drm_internal.h: No such file or
directory In file included
from /usr/src/sys/modules/drm/drm/../../../dev/drm/drm_dma.c:42:
@/dev/drm/drmP.h:96:34: error: dev/drm/drm_internal.h: No such file or
directory In file included
from /usr/src/sys/modules/drm/drm/../../../dev/drm/drm_drawable.c:39:
@/dev/drm/drmP.h:96:34: error: dev/drm/drm_internal.h: No such file or
directory In file included
from /usr/src/sys/modules/drm/drm/../../../dev/drm/drm_drv.c:41:
@/dev/drm/drmP.h:96:34: error: dev/drm/drm_internal.h: No such file or
directory In file included
from /usr/src/sys/modules/drm/drm/../../../dev/drm/drm_fops.c:40:
@/dev/drm/drmP.h:96:34: error: dev/drm/drm_internal.h: No such file or
directory In file included
from /usr/src/sys/modules/drm/drm/../../../dev/drm/drm_ioctl.c:39:
@/dev/drm/drmP.h:96:34: error: dev/drm/drm_internal.h: No such file or
directory In file included
from /usr/src/sys/modules/drm/drm/../../../dev/drm/drm_irq.c:36:
@/dev/drm/drmP.h:96:34: error: dev/drm/drm_internal.h: No such file or
directory In file included
from /usr/src/sys/modules/drm/drm/../../../dev/drm/drm_lock.c:53:
@/dev/drm/drmP.h:96:34: error: dev/drm/drm_internal.h: No such file or
directory In file included
from /usr/src/sys/modules/drm/drm/../../../dev/drm/drm_memory.c:42:
@/dev/drm/drmP.h:96:34: error: dev/drm/drm_internal.h: No such file or
directory In file included
from /usr/src/sys/modules/drm/drm/../../../dev/drm/drm_pci.c:34:
@/dev/drm/drmP.h:96:34: error: dev/drm/drm_internal.h: No such file or
directory In file included
from /usr/src/sys/modules/drm/drm/../../../dev/drm/drm_scatter.c:40:
@/dev/drm/drmP.h:96:34: error: dev/drm/drm_internal.h: No such file or
directory In file included
from /usr/src/sys/modules/drm/drm/../../../dev/drm/drm_sysctl.c:32:
@/dev/drm/drmP.h:96:34: error: dev/drm/drm_internal.h: No such file or
directory In file included
from /usr/src/sys/modules/drm/drm/../../../dev/drm/drm_vm.c:31:
@/dev/drm/drmP.h:96:34: error: dev/drm/drm_internal.h: No such file or
directory mkdep: compile failed *** Error code 1

Stop in /usr/src/sys/modules/drm/drm.
*** Error code 1

Stop in /usr/src/sys/modules/drm.
*** Error code 1

Stop in /usr/src/sys/modules.
*** Error code 1

Stop in /usr/obj/usr/src/sys/GENERIC.
*** Error code 1

Stop in /usr/src.
*** Error code 1

Stop in /usr/src.

HTH
-- 
Regards,
Torfinn Ingolfsen

From swhetzel at gmail.com  Wed Jan  7 00:56:03 2009
From: swhetzel at gmail.com (Scot Hetzel)
Date: Wed Jan  7 00:56:11 2009
Subject: Pending MFC of drm updates
In-Reply-To: <20090107012457.f9ce6dba.torfinn.ingolfsen@broadpark.no>
References: <1231263380.57454.23.camel@squirrel.corp.cox.com>
	<20090107012457.f9ce6dba.torfinn.ingolfsen@broadpark.no>
Message-ID: <790a9fff0901061632v2639daf2h7935439f4dbbacc@mail.gmail.com>

On Tue, Jan 6, 2009 at 6:24 PM, Torfinn Ingolfsen
<torfinn.ingolfsen@broadpark.no> wrote:
> On Tue, 06 Jan 2009 12:36:20 -0500
> Robert Noland <rnoland@FreeBSD.org> wrote:
>
>> I am planning to merge most all of the drm from -CURRENT to releng_7
>> shortly.  The merge that I have staged includes the following.
>>
:
>> I have a patch available for testing at
>> http://people.freebsd.org/~rnoland/drm-update-7-010609.patch.bz2
>
> Applied fine to my RELENG_7 / amd64 system (freshly cvsup'ed and built
> yesterday):
> root@kg-v2# uname -a
> FreeBSD kg-v2.kg4.no 7.1-STABLE FreeBSD 7.1-STABLE #1: Tue Jan  6
> 21:49:31 CET 2009 root@kg-v2.kg4.no:/usr/obj/usr/src/sys/GENERIC  amd64
>
> - except for the patch to sys/modules/drm/i915/Makefile:
:
> Apparently patch gets confuseed when it finds a file with the same name
> in the current directory (which was /usr/src), or perhaps I don't know
> how to tell patch how to find the right file.
> I just did:
> cd /usr/src
> patch < /dir/name/patchfile
>
use:

patch -p0 < /dir/name/patchfile

See the man page on patch.

Scot.
From pldrouin at pldrouin.net  Wed Jan  7 01:12:38 2009
From: pldrouin at pldrouin.net (Pierre-Luc Drouin)
Date: Wed Jan  7 01:12:55 2009
Subject: Problem with CPU freq in 7.1-STABLE
Message-ID: <4963FD19.70007@pldrouin.net>

Hi,

I noticed a problem with CPU freq in 7.1-STABLE. The maximum frequency 
showed by sysctl is 500Mhz lower than what it should be for my Pentium M 
2Ghz.

Here is the output from dmesg:
Copyright (c) 1992-2009 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
        The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 7.1-STABLE #7: Tue Jan  6 16:01:20 EST 2009
Timecounter "i8254" frequency 1193182 Hz quality 0
CPU: Intel(R) Pentium(R) M processor 2.00GHz (1995.15-MHz 686-class CPU)
  Origin = "GenuineIntel"  Id = 0x6d8  Stepping = 8
  
Features=0xafe9fbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,TM,PBE>
  Features2=0x180<EST,TM2>
  AMD Features=0x100000<NX>

and the output from sysctl:
dev.cpu.0.freq_levels: 1500/-1 1312/-1 1200/-1 1050/-1 1000/-1 875/-1 
800/-1 700/-1 600/-1 525/-1 450/-1 375/-1 300/-1 225/-1 150/-1 75/-1
dev.est.0.freq_settings: 1500/-1 1200/-1 1000/-1 800/-1 600/-1

This used to work correctly in 7.0...

Thanks!
Pierre-Luc Drouin
From torfinn.ingolfsen at broadpark.no  Wed Jan  7 01:17:28 2009
From: torfinn.ingolfsen at broadpark.no (Torfinn Ingolfsen)
Date: Wed Jan  7 01:17:35 2009
Subject: Pending MFC of drm updates
In-Reply-To: <20090107012457.f9ce6dba.torfinn.ingolfsen@broadpark.no>
References: <1231263380.57454.23.camel@squirrel.corp.cox.com>
	<20090107012457.f9ce6dba.torfinn.ingolfsen@broadpark.no>
Message-ID: <20090107021725.3d43a49f.torfinn.ingolfsen@broadpark.no>

On Wed, 07 Jan 2009 01:24:57 +0100
Torfinn Ingolfsen <torfinn.ingolfsen@broadpark.no> wrote:

I forgot to tell that I fixed the Makefile in sys/modules/drm/i915
manually.

> Apparently patch gets confuseed when it finds a file with the same
> name in the current directory (which was /usr/src), or perhaps I
> don't know how to tell patch how to find the right file.
> I just did:
> cd /usr/src
> patch < /dir/name/patchfile
> 
> Anyway, a 'make kernel' fails:

Which is no wonder, because patch misplaced more files:
root@kg-v2# pwd
/usr/src
root@kg-v2# ll *.c *c.orig *.h *h.orig
-rw-r--r--  1 root  wheel   1650 Jan  7 01:09 drm_internal.h
-rw-r--r--  1 root  wheel      0 Jan  7 01:09 drm_internal.h.orig
-rw-r--r--  1 root  wheel  16455 Jan  7 01:09 i915_suspend.c
-rw-r--r--  1 root  wheel      0 Jan  7 01:09 i915_suspend.c.orig
-rw-r--r--  1 root  wheel  59118 Jan  7 01:09 radeon_microcode.h
-rw-r--r--  1 root  wheel      0 Jan  7 01:09 radeon_microcode.h.orig

Is ther a "secret handshake" to make patch put the files in their
correct place? (Except for reading through the whole patchfile to
determine if all touched filews are in the same directory.)

For now I just mv'ed the files into place.
Anyway, now the new kernel builds, installs and works correctly.
It didn't pick up any drm, but I'm not sure that it should either. This
machine[1] has a GeForce 8200 chipset. More info about FreeBSD on this
machine here[2], including dmesgs before and after, etc.

HTH

References:
1) http://tingox.googlepages.com/asus_v2-m3n8200
2) http://tingox.googlepages.com/asus_v2-m3n8200_freebsd
-- 
Regards,
Torfinn Ingolfsen

From swhetzel at gmail.com  Wed Jan  7 01:25:57 2009
From: swhetzel at gmail.com (Scot Hetzel)
Date: Wed Jan  7 01:26:04 2009
Subject: Pending MFC of drm updates
In-Reply-To: <20090107021725.3d43a49f.torfinn.ingolfsen@broadpark.no>
References: <1231263380.57454.23.camel@squirrel.corp.cox.com>
	<20090107012457.f9ce6dba.torfinn.ingolfsen@broadpark.no>
	<20090107021725.3d43a49f.torfinn.ingolfsen@broadpark.no>
Message-ID: <790a9fff0901061725p6f41a602vbb53cfdf490df5cf@mail.gmail.com>

On Tue, Jan 6, 2009 at 7:17 PM, Torfinn Ingolfsen
<torfinn.ingolfsen@broadpark.no> wrote:
> Is ther a "secret handshake" to make patch put the files in their
> correct place? (Except for reading through the whole patchfile to
> determine if all touched filews are in the same directory.)
>

patch -p0 < patchfile

This will place the files into the correct locations.

Patch with no '-p' option will first try to put the files in the path
provided in the patch file, if the path exists, otherwise it places
the files in the current directory.

See the man page for patch.

Scot
From tom at samplonius.org  Wed Jan  7 02:45:25 2009
From: tom at samplonius.org (Tom Samplonius)
Date: Wed Jan  7 02:45:37 2009
Subject: ver 4.2 won't allow save because it can't see 2.2T disk drive
In-Reply-To: <006401c96477$3dd8e440$b98aacc0$@com>
Message-ID: <17218792.31231294718710.JavaMail.root@ly.sdf.com>


----- "SDH Admin" <admin@stardothosting.com> wrote:

> >I need to patch this until I can update the system, any pointers to
> >where (if there is one) to get the patch for this, and installation
> >instructions.
> 
> What is the 2.2T disk formatted as? Can you give more details on your
> hardware (storage device and the 4.2 server), as well as posting your
> dmesg
> output.

  In this case, it is pretty clear the the 2.2TB disk is mounted on NFS.  And the OP said it was a StorageVault, so that means it is a WAFL filesystem, which is meaningless here.

  Is it really FreeBSD 4.2?  

  Anyways, it doesn't really matter what "df" reports.  If df is folding some of the 64bit values in negative numbers, it is no issue really.  But if the StorageVault is returning errors when files are created or written to, then that is probably a configuration issue.  

  NFS is a client-server filesystem.  So "df" on NFS just queries the StorageVault for the info, and displays it.  The NFS client doesn't shutdown, because the filesystem appear to be full, or have negative capacity.  

Tom
From bernt at bah.homeip.net  Wed Jan  7 03:31:06 2009
From: bernt at bah.homeip.net (Bernt Hansson)
Date: Wed Jan  7 03:31:18 2009
Subject: Pending MFC of drm updates
In-Reply-To: <1231263380.57454.23.camel@squirrel.corp.cox.com>
References: <1231263380.57454.23.camel@squirrel.corp.cox.com>
Message-ID: <49641F69.5070909@bah.homeip.net>

Robert Noland said the following on 2009-01-06 18:36:
> I am planning to merge most all of the drm from -CURRENT to releng_7

And what is DRM? My ATI HD 3870 works.
From gaijin.k at gmail.com  Wed Jan  7 03:44:57 2009
From: gaijin.k at gmail.com (Alexandre "Sunny" Kovalenko)
Date: Wed Jan  7 03:45:05 2009
Subject: Pending MFC of drm updates
In-Reply-To: <1231263380.57454.23.camel@squirrel.corp.cox.com>
References: <1231263380.57454.23.camel@squirrel.corp.cox.com>
Message-ID: <1231298018.1217.2.camel@RabbitsDen>

On Tue, 2009-01-06 at 12:36 -0500, Robert Noland wrote:
> I am planning to merge most all of the drm from -CURRENT to releng_7
> shortly.  The merge that I have staged includes the following.
> 
> Merged /head/sys:r182080,182467-182469,182883-182884,183573,183603-183605,
> 	183828,183830-183834,184212-184213,184263,184373-184375
> 
> There are really too many updates/fixes to mention as the drm from 7 is
> more than 2 years old now.  This has support for several newer Intel and
> AMD/ATI chips, (no r6/7xx yet, but soon(tm)).
> 
> I have a patch available for testing at
> http://people.freebsd.org/~rnoland/drm-update-7-010609.patch.bz2

On the hardware below, I see no ill effects after applying the patch. Is
there anything specific you would like tested or any additional
information that I can provide?

vgapci0@pci0:0:2:0:	class=0x030000 card=0x201a17aa chip=0x27a28086
rev=0x03 hdr=0x00
    vendor     = 'Intel Corporation'
    device     = 'Mobile 945GM/GU Express Integrated Graphics
Controller'
    class      = display
    subclass   = VGA
vgapci1@pci0:0:2:1:	class=0x038000 card=0x201a17aa chip=0x27a68086
rev=0x03 hdr=0x00
    vendor     = 'Intel Corporation'
    device     = 'Mobile 945GM/GU Express Integrated Graphics
Controller'
    class      = display


-- 
Alexandre "Sunny" Kovalenko (????????? ?????????)

From yanefbsd at gmail.com  Wed Jan  7 03:49:35 2009
From: yanefbsd at gmail.com (Garrett Cooper)
Date: Wed Jan  7 03:49:43 2009
Subject: Pending MFC of drm updates
In-Reply-To: <49641F69.5070909@bah.homeip.net>
References: <1231263380.57454.23.camel@squirrel.corp.cox.com>
	<49641F69.5070909@bah.homeip.net>
Message-ID: <7d6fde3d0901061949l126f086ai3661d7d3cf227e3f@mail.gmail.com>

On Tue, Jan 6, 2009 at 7:20 PM, Bernt Hansson <bernt@bah.homeip.net> wrote:
> Robert Noland said the following on 2009-01-06 18:36:
>>
>> I am planning to merge most all of the drm from -CURRENT to releng_7
>
> And what is DRM? My ATI HD 3870 works.

Digital Rights Management. See: <http://en.wikipedia.org/wiki/DRM_(computing)>.
Cheers,
-Garrett
From rnoland at FreeBSD.org  Wed Jan  7 03:53:21 2009
From: rnoland at FreeBSD.org (Robert Noland)
Date: Wed Jan  7 03:53:33 2009
Subject: Pending MFC of drm updates
In-Reply-To: <49641F69.5070909@bah.homeip.net>
References: <1231263380.57454.23.camel@squirrel.corp.cox.com>
	<49641F69.5070909@bah.homeip.net>
Message-ID: <1231300331.7992.1.camel@wombat.2hip.net>

On Wed, 2009-01-07 at 04:20 +0100, Bernt Hansson wrote:
> Robert Noland said the following on 2009-01-06 18:36:
> > I am planning to merge most all of the drm from -CURRENT to releng_7
> 
> And what is DRM? My ATI HD 3870 works.

drm being the direct rendering kernel modules, required for most
hardware acceleration.

3870 with radeonhd driver?

robert.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090107/2c997c1d/attachment.pgp
From yanefbsd at gmail.com  Wed Jan  7 03:54:03 2009
From: yanefbsd at gmail.com (Garrett Cooper)
Date: Wed Jan  7 03:54:09 2009
Subject: ver 4.2 won't allow save because it can't see 2.2T disk drive
In-Reply-To: <17218792.31231294718710.JavaMail.root@ly.sdf.com>
References: <006401c96477$3dd8e440$b98aacc0$@com>
	<17218792.31231294718710.JavaMail.root@ly.sdf.com>
Message-ID: <7d6fde3d0901061953s5f623082u8cab20a0902e554a@mail.gmail.com>

On Tue, Jan 6, 2009 at 6:18 PM, Tom Samplonius <tom@samplonius.org> wrote:
>
> ----- "SDH Admin" <admin@stardothosting.com> wrote:
>
>> >I need to patch this until I can update the system, any pointers to
>> >where (if there is one) to get the patch for this, and installation
>> >instructions.
>>
>> What is the 2.2T disk formatted as? Can you give more details on your
>> hardware (storage device and the 4.2 server), as well as posting your
>> dmesg
>> output.
>
>  In this case, it is pretty clear the the 2.2TB disk is mounted on NFS.  And the OP said it was a StorageVault, so that means it is a WAFL filesystem, which is meaningless here.
>
>  Is it really FreeBSD 4.2?
>
>  Anyways, it doesn't really matter what "df" reports.  If df is folding some of the 64bit values in negative numbers, it is no issue really.  But if the StorageVault is returning errors when files are created or written to, then that is probably a configuration issue.
>
>  NFS is a client-server filesystem.  So "df" on NFS just queries the StorageVault for the info, and displays it.  The NFS client doesn't shutdown, because the filesystem appear to be full, or have negative capacity.
>
> Tom

Are you perhaps referring to OpenBSD 4.2 0-0?
-Garrett
From rnoland at FreeBSD.org  Wed Jan  7 03:55:25 2009
From: rnoland at FreeBSD.org (Robert Noland)
Date: Wed Jan  7 03:55:37 2009
Subject: Pending MFC of drm updates
In-Reply-To: <1231298018.1217.2.camel@RabbitsDen>
References: <1231263380.57454.23.camel@squirrel.corp.cox.com>
	<1231298018.1217.2.camel@RabbitsDen>
Message-ID: <1231300517.7992.4.camel@wombat.2hip.net>

On Tue, 2009-01-06 at 22:13 -0500, Alexandre "Sunny" Kovalenko wrote:
> On Tue, 2009-01-06 at 12:36 -0500, Robert Noland wrote:
> > I am planning to merge most all of the drm from -CURRENT to releng_7
> > shortly.  The merge that I have staged includes the following.
> > 
> > Merged /head/sys:r182080,182467-182469,182883-182884,183573,183603-183605,
> > 	183828,183830-183834,184212-184213,184263,184373-184375
> > 
> > There are really too many updates/fixes to mention as the drm from 7 is
> > more than 2 years old now.  This has support for several newer Intel and
> > AMD/ATI chips, (no r6/7xx yet, but soon(tm)).
> > 
> > I have a patch available for testing at
> > http://people.freebsd.org/~rnoland/drm-update-7-010609.patch.bz2
> 
> On the hardware below, I see no ill effects after applying the patch. Is
> there anything specific you would like tested or any additional
> information that I can provide?

Not really, the code has been running in -CURRENT for a while now, just
looking to make sure that no new issues show up.

thanks for testing.

robert.

> vgapci0@pci0:0:2:0:	class=0x030000 card=0x201a17aa chip=0x27a28086
> rev=0x03 hdr=0x00
>     vendor     = 'Intel Corporation'
>     device     = 'Mobile 945GM/GU Express Integrated Graphics
> Controller'
>     class      = display
>     subclass   = VGA
> vgapci1@pci0:0:2:1:	class=0x038000 card=0x201a17aa chip=0x27a68086
> rev=0x03 hdr=0x00
>     vendor     = 'Intel Corporation'
>     device     = 'Mobile 945GM/GU Express Integrated Graphics
> Controller'
>     class      = display
> 
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090107/b2b64cbc/attachment.pgp
From rnoland at FreeBSD.org  Wed Jan  7 03:57:41 2009
From: rnoland at FreeBSD.org (Robert Noland)
Date: Wed Jan  7 03:57:54 2009
Subject: Pending MFC of drm updates
In-Reply-To: <7d6fde3d0901061949l126f086ai3661d7d3cf227e3f@mail.gmail.com>
References: <1231263380.57454.23.camel@squirrel.corp.cox.com>
	<49641F69.5070909@bah.homeip.net>
	<7d6fde3d0901061949l126f086ai3661d7d3cf227e3f@mail.gmail.com>
Message-ID: <1231300591.7992.7.camel@wombat.2hip.net>

On Tue, 2009-01-06 at 19:49 -0800, Garrett Cooper wrote:
> On Tue, Jan 6, 2009 at 7:20 PM, Bernt Hansson <bernt@bah.homeip.net> wrote:
> > Robert Noland said the following on 2009-01-06 18:36:
> >>
> >> I am planning to merge most all of the drm from -CURRENT to releng_7
> >
> > And what is DRM? My ATI HD 3870 works.
> 
> Digital Rights Management. See: <http://en.wikipedia.org/wiki/DRM_(computing)>.

not at all. Direct Rendering Modules...

robert.

> Cheers,
> -Garrett
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090107/1e81335c/attachment.pgp
From rnoland at FreeBSD.org  Wed Jan  7 04:10:09 2009
From: rnoland at FreeBSD.org (Robert Noland)
Date: Wed Jan  7 04:10:16 2009
Subject: Pending MFC of drm updates
In-Reply-To: <20090107021725.3d43a49f.torfinn.ingolfsen@broadpark.no>
References: <1231263380.57454.23.camel@squirrel.corp.cox.com>
	<20090107012457.f9ce6dba.torfinn.ingolfsen@broadpark.no>
	<20090107021725.3d43a49f.torfinn.ingolfsen@broadpark.no>
Message-ID: <1231301398.7992.14.camel@wombat.2hip.net>

On Wed, 2009-01-07 at 02:17 +0100, Torfinn Ingolfsen wrote:
> On Wed, 07 Jan 2009 01:24:57 +0100
> Torfinn Ingolfsen <torfinn.ingolfsen@broadpark.no> wrote:
> 
> I forgot to tell that I fixed the Makefile in sys/modules/drm/i915
> manually.
> 
> > Apparently patch gets confuseed when it finds a file with the same
> > name in the current directory (which was /usr/src), or perhaps I
> > don't know how to tell patch how to find the right file.
> > I just did:
> > cd /usr/src
> > patch < /dir/name/patchfile
> > 
> > Anyway, a 'make kernel' fails:
> 
> Which is no wonder, because patch misplaced more files:
> root@kg-v2# pwd
> /usr/src
> root@kg-v2# ll *.c *c.orig *.h *h.orig
> -rw-r--r--  1 root  wheel   1650 Jan  7 01:09 drm_internal.h
> -rw-r--r--  1 root  wheel      0 Jan  7 01:09 drm_internal.h.orig
> -rw-r--r--  1 root  wheel  16455 Jan  7 01:09 i915_suspend.c
> -rw-r--r--  1 root  wheel      0 Jan  7 01:09 i915_suspend.c.orig
> -rw-r--r--  1 root  wheel  59118 Jan  7 01:09 radeon_microcode.h
> -rw-r--r--  1 root  wheel      0 Jan  7 01:09 radeon_microcode.h.orig
> 
> Is ther a "secret handshake" to make patch put the files in their
> correct place? (Except for reading through the whole patchfile to
> determine if all touched filews are in the same directory.)
> 
> For now I just mv'ed the files into place.
> Anyway, now the new kernel builds, installs and works correctly.
> It didn't pick up any drm, but I'm not sure that it should either. This
> machine[1] has a GeForce 8200 chipset. More info about FreeBSD on this
> machine here[2], including dmesgs before and after, etc.

Nope, sorry no Nvidia support yet.  nouveau is on my list to work on,
but it's a long list...

robert.

> HTH
> 
> References:
> 1) http://tingox.googlepages.com/asus_v2-m3n8200
> 2) http://tingox.googlepages.com/asus_v2-m3n8200_freebsd
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090107/82b91dc1/attachment.pgp
From rnoland at 2hip.net  Wed Jan  7 04:34:10 2009
From: rnoland at 2hip.net (Robert Noland)
Date: Wed Jan  7 04:34:20 2009
Subject: Pending MFC of drm updates
In-Reply-To: <20090107012457.f9ce6dba.torfinn.ingolfsen@broadpark.no>
References: <1231263380.57454.23.camel@squirrel.corp.cox.com>
	<20090107012457.f9ce6dba.torfinn.ingolfsen@broadpark.no>
Message-ID: <1231301204.7992.11.camel@wombat.2hip.net>

On Wed, 2009-01-07 at 01:24 +0100, Torfinn Ingolfsen wrote:
> On Tue, 06 Jan 2009 12:36:20 -0500
> Robert Noland <rnoland@FreeBSD.org> wrote:
> 
> > I am planning to merge most all of the drm from -CURRENT to releng_7
> > shortly.  The merge that I have staged includes the following.
> > 
> > Merged /head/sys:r182080,182467-182469,182883-182884,183573,183603-183605,
> > 	183828,183830-183834,184212-184213,184263,184373-184375
> > 
> > There are really too many updates/fixes to mention as the drm from 7
> > is more than 2 years old now.  This has support for several newer
> > Intel and AMD/ATI chips, (no r6/7xx yet, but soon(tm)).
> > 
> > I have a patch available for testing at
> > http://people.freebsd.org/~rnoland/drm-update-7-010609.patch.bz2
> 
> Applied fine to my RELENG_7 / amd64 system (freshly cvsup'ed and built
> yesterday):
> root@kg-v2# uname -a
> FreeBSD kg-v2.kg4.no 7.1-STABLE FreeBSD 7.1-STABLE #1: Tue Jan  6
> 21:49:31 CET 2009 root@kg-v2.kg4.no:/usr/obj/usr/src/sys/GENERIC  amd64

patch is being uncooperative... I've rebuilt the patchfile to simplify
this.  With the updated patchfile you need to:

cd /usr/src
bzcat <patchfile> | patch -p0

robert.

> - except for the patch to sys/modules/drm/i915/Makefile:
> The text leading up to this was:
> --------------------------
> |diff -uNrp -x .svn
> |sys/modules/drm/i915/Makefile /home/rnoland/freebsd/base/stable/7/sys/modules/drm/i915/Makefile
> |--- sys/modules/drm/i915/Makefile	2009-01-06 10:58:41.000000000
> |-0500 ++
> |+ /home/rnoland/freebsd/base/stable/7/sys/modules/drm/i915/Makefile
> |2008-12-10 21:48:19.000000000 -0500
> --------------------------
> Patching file Makefile using Plan A...
> Hunk #1 failed at 2.
> 1 out of 1 hunks failed--saving rejects to Makefile.rej
> 
> Apparently patch gets confuseed when it finds a file with the same name
> in the current directory (which was /usr/src), or perhaps I don't know
> how to tell patch how to find the right file.
> I just did:
> cd /usr/src
> patch < /dir/name/patchfile
> 
> Anyway, a 'make kernel' fails:
> mkdep -f .depend -a   -nostdinc -D_KERNEL -DKLD_MODULE
> -DHAVE_KERNEL_OPTION_HEADERS -I. -I@ -I@/contrib/altq
> -I/usr/obj/usr/src/sys/GENERIC /usr/src/sys/modules/drm/drm/../../../dev/drm/ati_pcigart.c /usr/src/sys/modules/drm/drm/..
> /../../dev/drm/drm_agpsupport.c /usr/src/sys/modules/drm/drm/../../../dev/drm/drm_auth.c /usr/src/sys/modules/drm/drm/../../../dev/drm/drm_bufs.c /usr/src/sys/modules/drm/drm/../../../dev/drm/drm_context.c /usr/src/sys/modules/drm/drm/../../../dev/drm/drm_dma.c /usr/src/sys/modules/drm/drm/../../../dev/drm/drm_drawable.c /usr/src/sys/modules/drm/drm/../../../dev/drm/drm_drv.c /usr/src/sys/modules/drm/drm/../../../dev/drm/drm_fops.c /usr/src/sys/modules/drm/drm/../../../dev/drm/drm_ioctl.c /usr/src/sys/modules/drm/drm/../../../dev/drm/drm_irq.c /usr/src/sys/modules/drm/drm/../../../dev/drm/drm_lock.c /usr/src/sys/modules/drm/drm/../../../dev/drm/drm_memory.c /usr/src/sys/modules/drm/drm/../../../dev/drm/drm_pci.c /usr/src/sys/modules/drm/drm/../../../dev/drm/drm_scatter.c /usr/src/sys/modules/drm/drm/../../../dev/drm/drm_sysctl.c /usr/src/sys/modules/drm/drm/../../../dev/drm/drm_vm.c
> In file included
> from /usr/src/sys/modules/drm/drm/../../../dev/drm/ati_pcigart.c:37:
> @/dev/drm/drmP.h:96:34: error: dev/drm/drm_internal.h: No such file or
> directory In file included
> from /usr/src/sys/modules/drm/drm/../../../dev/drm/drm_agpsupport.c:39:
> @/dev/drm/drmP.h:96:34: error: dev/drm/drm_internal.h: No such file or
> directory In file included
> from /usr/src/sys/modules/drm/drm/../../../dev/drm/drm_auth.c:39:
> @/dev/drm/drmP.h:96:34: error: dev/drm/drm_internal.h: No such file or
> directory In file included
> from /usr/src/sys/modules/drm/drm/../../../dev/drm/drm_bufs.c:40:
> @/dev/drm/drmP.h:96:34: error: dev/drm/drm_internal.h: No such file or
> directory In file included
> from /usr/src/sys/modules/drm/drm/../../../dev/drm/drm_context.c:38:
> @/dev/drm/drmP.h:96:34: error: dev/drm/drm_internal.h: No such file or
> directory In file included
> from /usr/src/sys/modules/drm/drm/../../../dev/drm/drm_dma.c:42:
> @/dev/drm/drmP.h:96:34: error: dev/drm/drm_internal.h: No such file or
> directory In file included
> from /usr/src/sys/modules/drm/drm/../../../dev/drm/drm_drawable.c:39:
> @/dev/drm/drmP.h:96:34: error: dev/drm/drm_internal.h: No such file or
> directory In file included
> from /usr/src/sys/modules/drm/drm/../../../dev/drm/drm_drv.c:41:
> @/dev/drm/drmP.h:96:34: error: dev/drm/drm_internal.h: No such file or
> directory In file included
> from /usr/src/sys/modules/drm/drm/../../../dev/drm/drm_fops.c:40:
> @/dev/drm/drmP.h:96:34: error: dev/drm/drm_internal.h: No such file or
> directory In file included
> from /usr/src/sys/modules/drm/drm/../../../dev/drm/drm_ioctl.c:39:
> @/dev/drm/drmP.h:96:34: error: dev/drm/drm_internal.h: No such file or
> directory In file included
> from /usr/src/sys/modules/drm/drm/../../../dev/drm/drm_irq.c:36:
> @/dev/drm/drmP.h:96:34: error: dev/drm/drm_internal.h: No such file or
> directory In file included
> from /usr/src/sys/modules/drm/drm/../../../dev/drm/drm_lock.c:53:
> @/dev/drm/drmP.h:96:34: error: dev/drm/drm_internal.h: No such file or
> directory In file included
> from /usr/src/sys/modules/drm/drm/../../../dev/drm/drm_memory.c:42:
> @/dev/drm/drmP.h:96:34: error: dev/drm/drm_internal.h: No such file or
> directory In file included
> from /usr/src/sys/modules/drm/drm/../../../dev/drm/drm_pci.c:34:
> @/dev/drm/drmP.h:96:34: error: dev/drm/drm_internal.h: No such file or
> directory In file included
> from /usr/src/sys/modules/drm/drm/../../../dev/drm/drm_scatter.c:40:
> @/dev/drm/drmP.h:96:34: error: dev/drm/drm_internal.h: No such file or
> directory In file included
> from /usr/src/sys/modules/drm/drm/../../../dev/drm/drm_sysctl.c:32:
> @/dev/drm/drmP.h:96:34: error: dev/drm/drm_internal.h: No such file or
> directory In file included
> from /usr/src/sys/modules/drm/drm/../../../dev/drm/drm_vm.c:31:
> @/dev/drm/drmP.h:96:34: error: dev/drm/drm_internal.h: No such file or
> directory mkdep: compile failed *** Error code 1
> 
> Stop in /usr/src/sys/modules/drm/drm.
> *** Error code 1
> 
> Stop in /usr/src/sys/modules/drm.
> *** Error code 1
> 
> Stop in /usr/src/sys/modules.
> *** Error code 1
> 
> Stop in /usr/obj/usr/src/sys/GENERIC.
> *** Error code 1
> 
> Stop in /usr/src.
> *** Error code 1
> 
> Stop in /usr/src.
> 
> HTH
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090107/906b66fd/attachment.pgp
From bernt at bah.homeip.net  Wed Jan  7 04:42:26 2009
From: bernt at bah.homeip.net (Bernt Hansson)
Date: Wed Jan  7 04:42:39 2009
Subject: Pending MFC of drm updates
In-Reply-To: <1231300331.7992.1.camel@wombat.2hip.net>
References: <1231263380.57454.23.camel@squirrel.corp.cox.com>	
	<49641F69.5070909@bah.homeip.net>
	<1231300331.7992.1.camel@wombat.2hip.net>
Message-ID: <496432B0.1000608@bah.homeip.net>

Robert Noland said the following on 2009-01-07 04:52:
> On Wed, 2009-01-07 at 04:20 +0100, Bernt Hansson wrote:
>> Robert Noland said the following on 2009-01-06 18:36:
>>> I am planning to merge most all of the drm from -CURRENT to releng_7
>> And what is DRM? My ATI HD 3870 works.
> 
> drm being the direct rendering kernel modules, required for most
> hardware acceleration.
> 
> 3870 with radeonhd driver?

Yes. Radeonhd. Tried radeon but then xfce didn't work.
From mike at vintners.net  Wed Jan  7 04:54:10 2009
From: mike at vintners.net (Mike Lempriere)
Date: Wed Jan  7 04:54:17 2009
Subject: mergemaster barf
Message-ID: <49643070.5000900@vintners.net>

upgrading 5-stable (was at 5.5) to 6-stable, in preparation for 6-stable 
to 7-stable.
No problems with cvsup, make buildworld, make buildkernel, mergemaster -p.
make installkernel, boot to single user, then mergemaster -- blammo:

config  /usr/src/etc/../usr.bin/mail/misc/mail.rc  
/usr/src/etc/../usr.bin/locate/locate/locate.rc printcap 
/var/tmp/temproot/etc;  cap_mkdb -l /var/tmp/temproot/etc/login.conf;  
install -o root -g wheel -m 755  netstart pccard_ether rc.suspend 
rc.resume /var/tmp/temproot/etc;  install -o root -g wheel -m 600  
master.passwd nsmb.conf opieaccess /var/tmp/temproot/etc;  pwd_mkdb -L 
-i -p -d /var/tmp/temproot/etc  /var/tmp/temproot/etc/master.passwd
cap_mkdb: illegal option -- l
usage: cap_mkdb [-v] [-f outfile] file [file ...]
*** Error code 1

Stop in /usr/src/etc.

  *** FATAL ERROR: Cannot 'cd' to /usr/src/etc and install files to
      the temproot environment

I've checked, the directory is there (/var/tmp/temproot/etc) however the 
file (master.passwd) is not.

Any suggestions anyone?  Thanks!

-- 
Mike Lempriere- Home: mike@vintners.net  Phone: 206-780-2146
Cellphone: 206-200-5902;  text pager: mikelemp@tmail.com

From yuri.pankov at gmail.com  Wed Jan  7 04:54:32 2009
From: yuri.pankov at gmail.com (Yuri Pankov)
Date: Wed Jan  7 04:54:39 2009
Subject: Pending MFC of drm updates
In-Reply-To: <1231301398.7992.14.camel@wombat.2hip.net>
References: <1231263380.57454.23.camel@squirrel.corp.cox.com>
	<20090107012457.f9ce6dba.torfinn.ingolfsen@broadpark.no>
	<20090107021725.3d43a49f.torfinn.ingolfsen@broadpark.no>
	<1231301398.7992.14.camel@wombat.2hip.net>
Message-ID: <20090107042112.GA12584@darklight.homeunix.org>

On Tue, Jan 06, 2009 at 11:09:58PM -0500, Robert Noland wrote:
> On Wed, 2009-01-07 at 02:17 +0100, Torfinn Ingolfsen wrote:
> > On Wed, 07 Jan 2009 01:24:57 +0100
> > Torfinn Ingolfsen <torfinn.ingolfsen@broadpark.no> wrote:
> > 
> > I forgot to tell that I fixed the Makefile in sys/modules/drm/i915
> > manually.
> > 
> > > Apparently patch gets confuseed when it finds a file with the same
> > > name in the current directory (which was /usr/src), or perhaps I
> > > don't know how to tell patch how to find the right file.
> > > I just did:
> > > cd /usr/src
> > > patch < /dir/name/patchfile
> > > 
> > > Anyway, a 'make kernel' fails:
> > 
> > Which is no wonder, because patch misplaced more files:
> > root@kg-v2# pwd
> > /usr/src
> > root@kg-v2# ll *.c *c.orig *.h *h.orig
> > -rw-r--r--  1 root  wheel   1650 Jan  7 01:09 drm_internal.h
> > -rw-r--r--  1 root  wheel      0 Jan  7 01:09 drm_internal.h.orig
> > -rw-r--r--  1 root  wheel  16455 Jan  7 01:09 i915_suspend.c
> > -rw-r--r--  1 root  wheel      0 Jan  7 01:09 i915_suspend.c.orig
> > -rw-r--r--  1 root  wheel  59118 Jan  7 01:09 radeon_microcode.h
> > -rw-r--r--  1 root  wheel      0 Jan  7 01:09 radeon_microcode.h.orig
> > 
> > Is ther a "secret handshake" to make patch put the files in their
> > correct place? (Except for reading through the whole patchfile to
> > determine if all touched filews are in the same directory.)
> > 
> > For now I just mv'ed the files into place.
> > Anyway, now the new kernel builds, installs and works correctly.
> > It didn't pick up any drm, but I'm not sure that it should either. This
> > machine[1] has a GeForce 8200 chipset. More info about FreeBSD on this
> > machine here[2], including dmesgs before and after, etc.
> 
> Nope, sorry no Nvidia support yet.  nouveau is on my list to work on,
> but it's a long list...
> 
> robert.
> 

Any help that we mere mortals can provide other than sending you
hardware?

> > HTH
> > 
> > References:
> > 1) http://tingox.googlepages.com/asus_v2-m3n8200
> > 2) http://tingox.googlepages.com/asus_v2-m3n8200_freebsd


Yuri
From wblock at wonkity.com  Wed Jan  7 04:56:55 2009
From: wblock at wonkity.com (Warren Block)
Date: Wed Jan  7 04:57:02 2009
Subject: Pending MFC of drm updates
In-Reply-To: <7d6fde3d0901061949l126f086ai3661d7d3cf227e3f@mail.gmail.com>
References: <1231263380.57454.23.camel@squirrel.corp.cox.com>
	<49641F69.5070909@bah.homeip.net>
	<7d6fde3d0901061949l126f086ai3661d7d3cf227e3f@mail.gmail.com>
Message-ID: <alpine.BSF.2.00.0901062133090.77746@wonkity.com>

On Tue, 6 Jan 2009, Garrett Cooper wrote:

> On Tue, Jan 6, 2009 at 7:20 PM, Bernt Hansson <bernt@bah.homeip.net> wrote:
>> Robert Noland said the following on 2009-01-06 18:36:
>>>
>>> I am planning to merge most all of the drm from -CURRENT to releng_7
>>
>> And what is DRM? My ATI HD 3870 works.
>
> Digital Rights Management. See: <http://en.wikipedia.org/wiki/DRM_(computing)>.

Not that DRM, this DRM:

http://dri.freedesktop.org/wiki/DRM

-Warren Block * Rapid City, South Dakota USA
From rnoland at FreeBSD.org  Wed Jan  7 05:18:13 2009
From: rnoland at FreeBSD.org (Robert Noland)
Date: Wed Jan  7 05:18:21 2009
Subject: Pending MFC of drm updates
In-Reply-To: <20090107042112.GA12584@darklight.homeunix.org>
References: <1231263380.57454.23.camel@squirrel.corp.cox.com>
	<20090107012457.f9ce6dba.torfinn.ingolfsen@broadpark.no>
	<20090107021725.3d43a49f.torfinn.ingolfsen@broadpark.no>
	<1231301398.7992.14.camel@wombat.2hip.net>
	<20090107042112.GA12584@darklight.homeunix.org>
Message-ID: <1231305482.7992.35.camel@wombat.2hip.net>

On Wed, 2009-01-07 at 07:21 +0300, Yuri Pankov wrote:
> On Tue, Jan 06, 2009 at 11:09:58PM -0500, Robert Noland wrote:
> > On Wed, 2009-01-07 at 02:17 +0100, Torfinn Ingolfsen wrote:
> > > On Wed, 07 Jan 2009 01:24:57 +0100
> > > Torfinn Ingolfsen <torfinn.ingolfsen@broadpark.no> wrote:
> > > 
> > > I forgot to tell that I fixed the Makefile in sys/modules/drm/i915
> > > manually.
> > > 
> > > > Apparently patch gets confuseed when it finds a file with the same
> > > > name in the current directory (which was /usr/src), or perhaps I
> > > > don't know how to tell patch how to find the right file.
> > > > I just did:
> > > > cd /usr/src
> > > > patch < /dir/name/patchfile
> > > > 
> > > > Anyway, a 'make kernel' fails:
> > > 
> > > Which is no wonder, because patch misplaced more files:
> > > root@kg-v2# pwd
> > > /usr/src
> > > root@kg-v2# ll *.c *c.orig *.h *h.orig
> > > -rw-r--r--  1 root  wheel   1650 Jan  7 01:09 drm_internal.h
> > > -rw-r--r--  1 root  wheel      0 Jan  7 01:09 drm_internal.h.orig
> > > -rw-r--r--  1 root  wheel  16455 Jan  7 01:09 i915_suspend.c
> > > -rw-r--r--  1 root  wheel      0 Jan  7 01:09 i915_suspend.c.orig
> > > -rw-r--r--  1 root  wheel  59118 Jan  7 01:09 radeon_microcode.h
> > > -rw-r--r--  1 root  wheel      0 Jan  7 01:09 radeon_microcode.h.orig
> > > 
> > > Is ther a "secret handshake" to make patch put the files in their
> > > correct place? (Except for reading through the whole patchfile to
> > > determine if all touched filews are in the same directory.)
> > > 
> > > For now I just mv'ed the files into place.
> > > Anyway, now the new kernel builds, installs and works correctly.
> > > It didn't pick up any drm, but I'm not sure that it should either. This
> > > machine[1] has a GeForce 8200 chipset. More info about FreeBSD on this
> > > machine here[2], including dmesgs before and after, etc.
> > 
> > Nope, sorry no Nvidia support yet.  nouveau is on my list to work on,
> > but it's a long list...
> > 
> > robert.
> > 
> 
> Any help that we mere mortals can provide other than sending you
> hardware?

I have a donated 6800 gt, I think it is.  Don't have a pci-e board to
put it on yet... nouveau isn't really ready on linux yet either, so I
couldn't even offer a real timeline at this point.  The nouveau guys are
generally good to work with, but it is entirely a reverse engineering
effort.  Nvidia is about the only major vendor that isn't releasing docs
and code now.

ATI/AMD is releasing docs and code, so r6/7xx won't be hard.  I have the
base code building now, but it isn't complete yet.  We will have this
code in the tree as soon as or before linux.  The AMD guys are good to
work with and are pretty happy to have FreeBSD support.  They have also
indicated that they might be able to help with hardware for development.

I'm also talking with VIA and it looks like they might send me hardware
also.  If they do, they will make the short list as well.

robert.

> > > HTH
> > > 
> > > References:
> > > 1) http://tingox.googlepages.com/asus_v2-m3n8200
> > > 2) http://tingox.googlepages.com/asus_v2-m3n8200_freebsd
> 
> 
> Yuri
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090107/a525af41/attachment.pgp
From dougb at FreeBSD.org  Wed Jan  7 06:33:10 2009
From: dougb at FreeBSD.org (Doug Barton)
Date: Wed Jan  7 06:33:16 2009
Subject: mergemaster barf
In-Reply-To: <49643070.5000900@vintners.net>
References: <49643070.5000900@vintners.net>
Message-ID: <49643E92.4000602@FreeBSD.org>

Mike Lempriere wrote:
> upgrading 5-stable (was at 5.5) to 6-stable, in preparation for 6-stable
...
> usage: cap_mkdb [-v] [-f outfile] file [file ...]
> *** Error code 1
> 
> Stop in /usr/src/etc.
> 
>  *** FATAL ERROR: Cannot 'cd' to /usr/src/etc and install files to
>      the temproot environment
> 
> I've checked, the directory is there (/var/tmp/temproot/etc) however the
> file (master.passwd) is not.
> 
> Any suggestions anyone?  Thanks!

You're going to have to do installworld before running mergemaster to
pick up the new version of cap_mkdb. This will be fine as long as you
don't reboot before mergemaster is done.

hth,

Doug

-- 

    This .signature sanitized for your protection

From antik at bsd.ee  Wed Jan  7 06:48:41 2009
From: antik at bsd.ee (Andrei Kolu)
Date: Wed Jan  7 06:48:50 2009
Subject: mergemaster barf
In-Reply-To: <49643070.5000900@vintners.net>
References: <49643070.5000900@vintners.net>
Message-ID: <49644AD2.3040308@bsd.ee>

Mike Lempriere wrote:
> upgrading 5-stable (was at 5.5) to 6-stable, in preparation for 
> 6-stable to 7-stable.
> No problems with cvsup, make buildworld, make buildkernel, mergemaster 
> -p.
> make installkernel, boot to single user, then mergemaster -- blammo:
>
> config  /usr/src/etc/../usr.bin/mail/misc/mail.rc  
> /usr/src/etc/../usr.bin/locate/locate/locate.rc printcap 
> /var/tmp/temproot/etc;  cap_mkdb -l /var/tmp/temproot/etc/login.conf;  
> install -o root -g wheel -m 755  netstart pccard_ether rc.suspend 
> rc.resume /var/tmp/temproot/etc;  install -o root -g wheel -m 600  
> master.passwd nsmb.conf opieaccess /var/tmp/temproot/etc;  pwd_mkdb -L 
> -i -p -d /var/tmp/temproot/etc  /var/tmp/temproot/etc/master.passwd
> cap_mkdb: illegal option -- l
> usage: cap_mkdb [-v] [-f outfile] file [file ...]
> *** Error code 1
>
> Stop in /usr/src/etc.
>
>  *** FATAL ERROR: Cannot 'cd' to /usr/src/etc and install files to
>      the temproot environment
>
> I've checked, the directory is there (/var/tmp/temproot/etc) however 
> the file (master.passwd) is not.
>
> Any suggestions anyone?  Thanks!
>
Maybe you should "make installworld" first?
From pyunyh at gmail.com  Wed Jan  7 10:39:44 2009
From: pyunyh at gmail.com (Pyun YongHyeon)
Date: Wed Jan  7 10:39:51 2009
Subject: Panic in RELENG_7_1 with fxp(4)
In-Reply-To: <49637755.1070708@avioc.org>
References: <49600E2E.7070601@avioc.org>
	<3163F769-48B0-4CFC-8842-BBBDDAE78B51@gmail.com>
	<20090105032657.GA1842@cdnetworks.co.kr>
	<4961FACE.4060203@avioc.org>
	<20090106080333.GA6168@cdnetworks.co.kr>
	<49637755.1070708@avioc.org>
Message-ID: <20090107103924.GA126@cdnetworks.co.kr>

On Tue, Jan 06, 2009 at 09:23:01AM -0600, Brandon Weisz wrote:
 > Pyun YongHyeon wrote:
 > >On Mon, Jan 05, 2009 at 06:19:26AM -0600, Brandon Weisz wrote:
 > > > Pyun YongHyeon wrote:
 > > > >On Sat, Jan 03, 2009 at 10:16:58PM -0800, Garrett Cooper wrote:
 > > > > > On Jan 3, 2009, at 5:17 PM, Brandon Weisz wrote:
 > > > > > 
 > > > > > >After running 7-PRERELEASE from around November 25th, I upgraded  
 > > > > > >today to find the system panics repeatably on RELENG_7_1 sources.  
 > > I  > > > >can boot back to the old kernel and it operates as expected.  
 > > It  > > > >seems to be related to fxp(4).
 > > > > > >
 > > > > > >FreeBSD didy.internal 7.1-RELEASE FreeBSD 7.1-RELEASE #0: Sat Jan  
 > > 3
 > > > > > >18:11:18 CST 2009     bweisz@didy.internal:/usr/obj/usr/src/sys/ 
 > > > > > >DIDY  i386
 > > > > > >
 > > > 
 > > > ....
 > > > 
 > > > > > >
 > > > > > >I replaced the fxp(4) card with an old xl(4) card lying on my desk 
 > > > > > >and the panics stopped.  Is this a failing nic card or some other  
 > > > > > >trigger?
 > > > > > >
 > > > > > >Brandon
 > > > > > 
 > > > > > Memory serves me correctly an MFC was done not too long before 7.1  
 > > > > > release was setup.
 > > > > > 
 > > > >
 > > > >I don't know what MFCes were done, at least I didn't MFC any
 > > > >changes I made.
 > > > >
 > > > > > Let's see what Pyun says...
 > > > > > 
 > > > >
 > > > >I'm not sure what is root cause of this panic. If you can reliably
 > > > >reproduce the panic would you let me know?
 > > > >CURRENT has a couple of fixes for edge-cases as well as some new
 > > > >hardware features(TSO, VLAN hardware tagging and WOL etc). Would
 > > > >you try latest fxp(4) in HEAD?
 > > > >I think you can use cvsweb interface to get latest files.
 > > > >http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/fxp/if_fxp.c
 > > > >http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/fxp/if_fxpreg.h
 > > > >http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/fxp/if_fxpvar.h
 > > > >
 > > > 
 > > > Hi Pyun
 > > > 
 > > > The system reliably panics on boot up.  I tested fxp from HEAD with the 
 > > > same result.
 > > > 
 > > > 7.1-RELEASE = Panic
 > > > 7.1-RELEASE with fxp from HEAD = Panic
 > > > 7.1-PRERELEASE from Tue Nov 25 = operates as expected
 > > > 
 > > > This is an old card.  Some details on the card:
 > > > 
 > > > fxp0: <Intel 82559 Pro/100 Ethernet> port 0xd100-0xd13f mem 
 > > > 0xfca03000-0xfca03fff,0xfc800000-0xfc8fffff irq 17 at device 9.0 on pci0
 > > > miibus0: <MII bus> on fxp0
 > > > inphy0: <i82555 10/100 media interface> PHY 1 on miibus0
 > > > inphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
 > > > fxp0: Ethernet address: 00:d0:b7:6c:1c:0a
 > > > fxp0: [ITHREAD]
 > > > 
 > > > fxp0@pci0:0:9:0:	class=0x020000 card=0x000b8086 chip=0x12298086 
 > > > rev=0x08 hdr=0x00
 > > >     vendor     = 'Intel Corporation'
 > > >     device     = '82550/1/7/8/9 EtherExpress PRO/100(B) Ethernet 
 > > Adapter'
 > > >     class      = network
 > > >     subclass   = ethernet
 > > > 
 > > > As a test, I unplugged the ethernet cable and the system booted fully, 
 > > > however it produced a panic as soon as I connected the cable.  This 
 > > > backtrace is from 7.1-RELEASE with fxp sources from HEAD.
 > > > 
 > >
 > >I still can't reproduce this but would you try fxp(4) in the
 > >following URLs?
 > >http://people.freebsd.org/~yongari/fxp/if_fxp.c
 > >http://people.freebsd.org/~yongari/fxp/if_fxpreg.h
 > >http://people.freebsd.org/~yongari/fxp/if_fxpvar.h
 > >
 > 
 > With this version, the system still panics as before.
 > 

I think the panic message you posted below is not related with
fxp(4). Show me panic message for fxp(4), that would be more 
helpful to narrow down possible cause of issue.
BTW, are you using non-standard compilation flag or customized
kernel? Since there are lot of systems that still rely on fxp(4)
I wonder how this issue is not reported yet.
Did GENERIC kernel also show exact the same behaviour?

 > After the system panic with this patch, I went into the bios and 
 > disabled all unnecessary hardware such as parallel port, usb controller 
 > and on-board audio.  The resulting panic below appears different.
 > 
 > Fatal trap 12: page fault while in kernel mode
 > cpuid = 0; apic id = 00
 > fault virtual address	= 0x400
 > fault code		= supervisor read, page not present
 > instruction pointer	= 0x20:0xc07eefec
 > stack pointer	        = 0x28:0xe4339ac0
 > frame pointer	        = 0x28:0xe4339ae4
 > 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		= 28 (irq23: vr0)
 > trap number		= 12
 > panic: page fault
 > cpuid = 0
 > Uptime: 50s
 > Physical memory: 995 MB
 > Dumping 162 MB: 147 131 115 99 83 67 51 35 19 3
 > 

[...]

-- 
Regards,
Pyun YongHyeon
From kerneljack at gmail.com  Wed Jan  7 11:11:58 2009
From: kerneljack at gmail.com (Khusro Jaleel)
Date: Wed Jan  7 11:12:06 2009
Subject: Problem with CPU freq in 7.1-STABLE
In-Reply-To: <4963FD19.70007@pldrouin.net>
References: <4963FD19.70007@pldrouin.net>
Message-ID: <e1e9e88d0901070241l58b8a970u1aeea45af83b2343@mail.gmail.com>

Hi,

I'm also unable to get AMD PowerNow working on 7.1 on a Dell Opteron
server (PowerEdge 2970). Whenever I run "powerd", I get:

# powerd -a adp
powerd: lookup freq: No such file or directory

If I look at the sysctl output, the 'freq' stuff seems to be missing
from 'dev.cpu'. I have definitely gone into the server BIOS and
enabled the option (don't remember what it's called now) for frequency
control. I have also checked that 'cpufreq' is included in the kernel
config, but it's a default GENERIC anyway.

# sysctl dev.cpu
dev.cpu.0.%desc: ACPI CPU
dev.cpu.0.%driver: cpu
dev.cpu.0.%location: handle=\_PR_.CPU0
dev.cpu.0.%pnpinfo: _HID=none _UID=0
dev.cpu.0.%parent: acpi0
dev.cpu.0.cx_supported: C1/0
dev.cpu.0.cx_lowest: C1
dev.cpu.0.cx_usage: 100.00%
dev.cpu.1.%desc: ACPI CPU
dev.cpu.1.%driver: cpu
dev.cpu.1.%location: handle=\_PR_.CPU1
dev.cpu.1.%pnpinfo: _HID=none _UID=0
dev.cpu.1.%parent: acpi0
dev.cpu.1.cx_supported: C1/0
dev.cpu.1.cx_lowest: C1
dev.cpu.1.cx_usage: 100.00%
dev.cpu.2.%desc: ACPI CPU
dev.cpu.2.%driver: cpu
dev.cpu.2.%location: handle=\_PR_.CPU2
dev.cpu.2.%pnpinfo: _HID=none _UID=0
dev.cpu.2.%parent: acpi0
dev.cpu.2.cx_supported: C1/0
dev.cpu.2.cx_lowest: C1
dev.cpu.2.cx_usage: 100.00%
dev.cpu.3.%desc: ACPI CPU
dev.cpu.3.%driver: cpu
dev.cpu.3.%location: handle=\_PR_.CPU3
dev.cpu.3.%pnpinfo: _HID=none _UID=0
dev.cpu.3.%parent: acpi0debug.acpi.semaphore_debug: 0
debug.acpi.suspend_bounce: 0
debug.acpi.do_powerstate: 1
debug.acpi.acpi_ca_version: 20070320
debug.acpi.ec.timeout: 750
debug.acpi.ec.polled: 0
debug.acpi.ec.burst: 0
hw.acpi.supported_sleep_state: S4 S5
hw.acpi.power_button_state: S5
hw.acpi.sleep_button_state: S4
hw.acpi.lid_switch_state: NONE
hw.acpi.standby_state: S1
hw.acpi.suspend_state: S3
hw.acpi.sleep_delay: 1
hw.acpi.s4bios: 0
hw.acpi.verbose: 0
hw.acpi.disable_on_reboot: 0
hw.acpi.handle_reboot: 0
hw.acpi.cpu.cx_lowest: C1

dev.cpu.3.cx_supported: C1/0
dev.cpu.3.cx_lowest: C1
dev.cpu.3.cx_usage: 100.00%

# sysctl debug.acpi
debug.acpi.semaphore_debug: 0
debug.acpi.suspend_bounce: 0
debug.acpi.do_powerstate: 1
debug.acpi.acpi_ca_version: 20070320
debug.acpi.ec.timeout: 750
debug.acpi.ec.polled: 0
debug.acpi.ec.burst: 0

# sysctl hw.acpi
hw.acpi.supported_sleep_state: S4 S5
hw.acpi.power_button_state: S5
hw.acpi.sleep_button_state: S4
hw.acpi.lid_switch_state: NONE
hw.acpi.standby_state: S1
hw.acpi.suspend_state: S3
hw.acpi.sleep_delay: 1
hw.acpi.s4bios: 0
hw.acpi.verbose: 0
hw.acpi.disable_on_reboot: 0
hw.acpi.handle_reboot: 0
hw.acpi.cpu.cx_lowest: C1


Here is some relevant dmesg output:
FreeBSD 7.1-RELEASE #2: Tue Jan  6 15:58:36 GMT 2009
    root@xxxx:/usr/obj/usr/src/sys/GENERIC
Timecounter "i8254" frequency 1193182 Hz quality 0
CPU: Quad-Core AMD Opteron(tm) Processor 2350 (1995.01-MHz K8-class CPU)
  Origin = "AuthenticAMD"  Id = 0x100f23  Stepping = 3
  Features=0x178bfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT>
  Features2=0x802009<SSE3,MON,CX16,<b23>>
  AMD Features=0xee500800<SYSCALL,NX,MMX+,FFXSR,Page1GB,RDTSCP,LM,3DNow!+,3DNow!>
  AMD Features2=0x7ff<LAHF,CMP,SVM,ExtAPIC,CR8,<b5>,<b6>,<b7>,Prefetch,<b9>,<b10>>
  Cores per package: 4
usable memory = 4276158464 (4078 MB)
avail memory  = 4118642688 (3927 MB)
ACPI APIC Table: <DELL   PE_SC3  >
FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
 cpu0 (BSP): APIC ID:  0
 cpu1 (AP): APIC ID:  1
 cpu2 (AP): APIC ID:  2
 cpu3 (AP): APIC ID:  3
ioapic0: Changing APIC ID to 4
ioapic1: Changing APIC ID to 5
ioapic2: Changing APIC ID to 6
MADT: Forcing active-low polarity and level trigger for SCI
ioapic0 <Version 1.1> irqs 0-15 on motherboard
ioapic1 <Version 1.1> irqs 32-47 on motherboard
ioapic2 <Version 1.1> irqs 64-79 on motherboard
.
.
.
cpu0: <ACPI CPU> on acpi0
cpu1: <ACPI CPU> on acpi0
cpu2: <ACPI CPU> on acpi0
cpu3: <ACPI CPU> on acpi0

Any help appreciated.



On Wed, Jan 7, 2009 at 12:53 AM, Pierre-Luc Drouin
<pldrouin@pldrouin.net> wrote:
> Hi,
>
> I noticed a problem with CPU freq in 7.1-STABLE. The maximum frequency
> showed by sysctl is 500Mhz lower than what it should be for my Pentium M
> 2Ghz.
>
> Here is the output from dmesg:
> Copyright (c) 1992-2009 The FreeBSD Project.
> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
>       The Regents of the University of California. All rights reserved.
> FreeBSD is a registered trademark of The FreeBSD Foundation.
> FreeBSD 7.1-STABLE #7: Tue Jan  6 16:01:20 EST 2009
> Timecounter "i8254" frequency 1193182 Hz quality 0
> CPU: Intel(R) Pentium(R) M processor 2.00GHz (1995.15-MHz 686-class CPU)
>  Origin = "GenuineIntel"  Id = 0x6d8  Stepping = 8
>  Features=0xafe9fbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,TM,PBE>
>  Features2=0x180<EST,TM2>
>  AMD Features=0x100000<NX>
>
> and the output from sysctl:
> dev.cpu.0.freq_levels: 1500/-1 1312/-1 1200/-1 1050/-1 1000/-1 875/-1 800/-1
> 700/-1 600/-1 525/-1 450/-1 375/-1 300/-1 225/-1 150/-1 75/-1
> dev.est.0.freq_settings: 1500/-1 1200/-1 1000/-1 800/-1 600/-1
>
> This used to work correctly in 7.0...
>
> Thanks!
> Pierre-Luc Drouin
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
>
From rwatson at FreeBSD.org  Wed Jan  7 11:32:30 2009
From: rwatson at FreeBSD.org (Robert Watson)
Date: Wed Jan  7 11:32:39 2009
Subject: Panic in RELENG_7_1 with fxp(4)
In-Reply-To: <49637755.1070708@avioc.org>
References: <49600E2E.7070601@avioc.org>
	<3163F769-48B0-4CFC-8842-BBBDDAE78B51@gmail.com>
	<20090105032657.GA1842@cdnetworks.co.kr>
	<4961FACE.4060203@avioc.org>
	<20090106080333.GA6168@cdnetworks.co.kr>
	<49637755.1070708@avioc.org>
Message-ID: <alpine.BSF.2.00.0901071130080.33165@fledge.watson.org>


On Tue, 6 Jan 2009, Brandon Weisz wrote:

>> http://people.freebsd.org/~yongari/fxp/if_fxp.c
>> http://people.freebsd.org/~yongari/fxp/if_fxpreg.h
>> http://people.freebsd.org/~yongari/fxp/if_fxpvar.h
>
> With this version, the system still panics as before.
>
> After the system panic with this patch, I went into the bios and disabled 
> all unnecessary hardware such as parallel port, usb controller and on-board 
> audio.  The resulting panic below appears different.

Without contributing anything too constructive to this conversation, this 
crash looks a bit like it might be a device driver bug in which a packet is 
passed to if_input() from the device driver, but then modified by the device 
driver after it is handed off.

Robert N M Watson
Computer Laboratory
University of Cambridge

>
> Fatal trap 12: page fault while in kernel mode
> cpuid = 0; apic id = 00
> fault virtual address	= 0x400
> fault code		= supervisor read, page not present
> instruction pointer	= 0x20:0xc07eefec
> stack pointer	        = 0x28:0xe4339ac0
> frame pointer	        = 0x28:0xe4339ae4
> 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		= 28 (irq23: vr0)
> trap number		= 12
> panic: page fault
> cpuid = 0
> Uptime: 50s
> Physical memory: 995 MB
> Dumping 162 MB: 147 131 115 99 83 67 51 35 19 3
>
> ....
>
> (kgdb) list *0xc07eefec
> 0xc07eefec is in sbappendaddr_locked 
> (/usr/src.local/sys/kern/uipc_sockbuf.c:652).
> 647		if (n)
> 648			n->m_next = m0;		/* concatenate data to 
> control */
> 649		else
> 650			control = m0;
> 651		m->m_next = control;
> 652		for (n = m; n->m_next != NULL; n = n->m_next)
> 653			sballoc(sb, n);
> 654		sballoc(sb, n);
> 655		nlast = n;
> 656		SBLINKRECORD(sb, m);
> (kgdb) bt
> #0  doadump () at pcpu.h:196
> #1  0xc079cf07 in boot (howto=260) at 
> /usr/src.local/sys/kern/kern_shutdown.c:418
> #2  0xc079d1d9 in panic (fmt=Variable "fmt" is not available.
> ) at /usr/src.local/sys/kern/kern_shutdown.c:574
> #3  0xc0ab110c in trap_fatal (frame=0xe4339a80, eva=1024) at 
> /usr/src.local/sys/i386/i386/trap.c:939
> #4  0xc0ab1390 in trap_pfault (frame=0xe4339a80, usermode=0, eva=1024) at 
> /usr/src.local/sys/i386/i386/trap.c:852
> #5  0xc0ab1d4c in trap (frame=0xe4339a80) at 
> /usr/src.local/sys/i386/i386/trap.c:530
> #6  0xc0a97bbb in calltrap () at /usr/src.local/sys/i386/i386/exception.s:159
> #7  0xc07eefec in sbappendaddr_locked (sb=0xc5bacd50, asa=0xe4339b90, 
> m0=0xc4167000, control=0xc4167000) at 
> /usr/src.local/sys/kern/uipc_sockbuf.c:652
> #8  0xc08ecb71 in udp_append (inp=Variable "inp" is not available.
> ) at /usr/src.local/sys/netinet/udp_usrreq.c:254
> #9  0xc08edf7a in udp_input (m=0xc4167000, off=20) at 
> /usr/src.local/sys/netinet/udp_usrreq.c:567
> #10 0xc087d320 in ip_input (m=0xc4167000) at 
> /usr/src.local/sys/netinet/ip_input.c:665
> #11 0xc0842a85 in netisr_dispatch (num=2, m=0xc4167000) at 
> /usr/src.local/sys/net/netisr.c:185
> #12 0xc08389f1 in ether_demux (ifp=0xc41b6800, m=0xc4167000) at 
> /usr/src.local/sys/net/if_ethersubr.c:834
> #13 0xc0838de3 in ether_input (ifp=0xc41b6800, m=0xc4167000) at 
> /usr/src.local/sys/net/if_ethersubr.c:692
> #14 0xc071750b in vr_intr (arg=0xc41c8000) at 
> /usr/src.local/sys/dev/vr/if_vr.c:1415
> #15 0xc077bf0b in ithread_loop (arg=0xc41c5550) at 
> /usr/src.local/sys/kern/kern_intr.c:1088
> #16 0xc0778a79 in fork_exit (callout=0xc077bd50 <ithread_loop>, 
> arg=0xc41c5550, frame=0xe4339d38) at /usr/src.local/sys/kern/kern_fork.c:804
> #17 0xc0a97c30 in fork_trampoline () at 
> /usr/src.local/sys/i386/i386/exception.s:264
> (kgdb)
>
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
>
From lists at avioc.org  Wed Jan  7 13:22:24 2009
From: lists at avioc.org (Brandon Weisz)
Date: Wed Jan  7 13:22:32 2009
Subject: Panic in RELENG_7_1 with fxp(4)
In-Reply-To: <20090107103924.GA126@cdnetworks.co.kr>
References: <49600E2E.7070601@avioc.org>
	<3163F769-48B0-4CFC-8842-BBBDDAE78B51@gmail.com>
	<20090105032657.GA1842@cdnetworks.co.kr>
	<4961FACE.4060203@avioc.org>
	<20090106080333.GA6168@cdnetworks.co.kr>
	<49637755.1070708@avioc.org>
	<20090107103924.GA126@cdnetworks.co.kr>
Message-ID: <4964AC8D.6080209@avioc.org>

Pyun YongHyeon wrote:
> On Tue, Jan 06, 2009 at 09:23:01AM -0600, Brandon Weisz wrote:
>  > Pyun YongHyeon wrote:
>  > >On Mon, Jan 05, 2009 at 06:19:26AM -0600, Brandon Weisz wrote:
>  > > > Pyun YongHyeon wrote:
>  > > > >On Sat, Jan 03, 2009 at 10:16:58PM -0800, Garrett Cooper wrote:
>  > > > > > On Jan 3, 2009, at 5:17 PM, Brandon Weisz wrote:
>  > > > > > 
>  > > > > > >After running 7-PRERELEASE from around November 25th, I upgraded  
>  > > > > > >today to find the system panics repeatably on RELENG_7_1 sources.  
>  > > I  > > > >can boot back to the old kernel and it operates as expected.  
>  > > It  > > > >seems to be related to fxp(4).
>  > > > > > >
>  > > > > > >FreeBSD didy.internal 7.1-RELEASE FreeBSD 7.1-RELEASE #0: Sat Jan  
>  > > 3
>  > > > > > >18:11:18 CST 2009     bweisz@didy.internal:/usr/obj/usr/src/sys/ 
>  > > > > > >DIDY  i386
>  > > > > > >
>  > > > 
>  > > > ....
>  > > > 
>  > > > > > >
>  > > > > > >I replaced the fxp(4) card with an old xl(4) card lying on my desk 
>  > > > > > >and the panics stopped.  Is this a failing nic card or some other  
>  > > > > > >trigger?
>  > > > > > >
>  > > > > > >Brandon
>  > > > > > 
>  > > > > > Memory serves me correctly an MFC was done not too long before 7.1  
>  > > > > > release was setup.
>  > > > > > 
>  > > > >
>  > > > >I don't know what MFCes were done, at least I didn't MFC any
>  > > > >changes I made.
>  > > > >
>  > > > > > Let's see what Pyun says...
>  > > > > > 
>  > > > >
>  > > > >I'm not sure what is root cause of this panic. If you can reliably
>  > > > >reproduce the panic would you let me know?
>  > > > >CURRENT has a couple of fixes for edge-cases as well as some new
>  > > > >hardware features(TSO, VLAN hardware tagging and WOL etc). Would
>  > > > >you try latest fxp(4) in HEAD?
>  > > > >I think you can use cvsweb interface to get latest files.
>  > > > >http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/fxp/if_fxp.c
>  > > > >http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/fxp/if_fxpreg.h
>  > > > >http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/fxp/if_fxpvar.h
>  > > > >
>  > > > 
>  > > > Hi Pyun
>  > > > 
>  > > > The system reliably panics on boot up.  I tested fxp from HEAD with the 
>  > > > same result.
>  > > > 
>  > > > 7.1-RELEASE = Panic
>  > > > 7.1-RELEASE with fxp from HEAD = Panic
>  > > > 7.1-PRERELEASE from Tue Nov 25 = operates as expected
>  > > > 
>  > > > This is an old card.  Some details on the card:
>  > > > 
>  > > > fxp0: <Intel 82559 Pro/100 Ethernet> port 0xd100-0xd13f mem 
>  > > > 0xfca03000-0xfca03fff,0xfc800000-0xfc8fffff irq 17 at device 9.0 on pci0
>  > > > miibus0: <MII bus> on fxp0
>  > > > inphy0: <i82555 10/100 media interface> PHY 1 on miibus0
>  > > > inphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
>  > > > fxp0: Ethernet address: 00:d0:b7:6c:1c:0a
>  > > > fxp0: [ITHREAD]
>  > > > 
>  > > > fxp0@pci0:0:9:0:	class=0x020000 card=0x000b8086 chip=0x12298086 
>  > > > rev=0x08 hdr=0x00
>  > > >     vendor     = 'Intel Corporation'
>  > > >     device     = '82550/1/7/8/9 EtherExpress PRO/100(B) Ethernet 
>  > > Adapter'
>  > > >     class      = network
>  > > >     subclass   = ethernet
>  > > > 
>  > > > As a test, I unplugged the ethernet cable and the system booted fully, 
>  > > > however it produced a panic as soon as I connected the cable.  This 
>  > > > backtrace is from 7.1-RELEASE with fxp sources from HEAD.
>  > > > 
>  > >
>  > >I still can't reproduce this but would you try fxp(4) in the
>  > >following URLs?
>  > >http://people.freebsd.org/~yongari/fxp/if_fxp.c
>  > >http://people.freebsd.org/~yongari/fxp/if_fxpreg.h
>  > >http://people.freebsd.org/~yongari/fxp/if_fxpvar.h
>  > >
>  > 
>  > With this version, the system still panics as before.
>  > 
> 
> I think the panic message you posted below is not related with
> fxp(4). Show me panic message for fxp(4), that would be more 
> helpful to narrow down possible cause of issue.
> BTW, are you using non-standard compilation flag or customized
> kernel? Since there are lot of systems that still rely on fxp(4)
> I wonder how this issue is not reported yet.
> Did GENERIC kernel also show exact the same behaviour?

The system still panics with the fxp card installed, as seen below. 
While I agree this panic looks different, taking out the fxp card and 
replacing it with xl(4) card stopped the panic.  I can also stop the 
panic and use the fxp card with the old kernel from Nov 25.

I'm not using any compiler flags in make.conf or src.conf.  I am using a 
  somewhat custom kernel:

include 	GENERIC
ident		DIDY

# Changes and additions
options         SC_PIXEL_MODE
options 	SC_HISTORY_SIZE=8192

options         ALTQ
options         ALTQ_CBQ
options         ALTQ_RED
options         ALTQ_RIO
options         ALTQ_HFSC
options         ALTQ_CDNR
options         ALTQ_PRIQ

#options 	KVA_PAGES=512

device		puc

I'll give GENERIC a go and see if that makes any difference.

> 
>  > After the system panic with this patch, I went into the bios and 
>  > disabled all unnecessary hardware such as parallel port, usb controller 
>  > and on-board audio.  The resulting panic below appears different.
>  > 
>  > Fatal trap 12: page fault while in kernel mode
>  > cpuid = 0; apic id = 00
>  > fault virtual address	= 0x400
>  > fault code		= supervisor read, page not present
>  > instruction pointer	= 0x20:0xc07eefec
>  > stack pointer	        = 0x28:0xe4339ac0
>  > frame pointer	        = 0x28:0xe4339ae4
>  > 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		= 28 (irq23: vr0)
>  > trap number		= 12
>  > panic: page fault
>  > cpuid = 0
>  > Uptime: 50s
>  > Physical memory: 995 MB
>  > Dumping 162 MB: 147 131 115 99 83 67 51 35 19 3
>  > 
> 
> [...]
> 

From olli at lurza.secnetix.de  Wed Jan  7 14:11:46 2009
From: olli at lurza.secnetix.de (Oliver Fromme)
Date: Wed Jan  7 14:11:54 2009
Subject: ver 4.2 won't allow save because it can't see 2.2T disk drive
In-Reply-To: <17218792.31231294718710.JavaMail.root@ly.sdf.com>
Message-ID: <200901071411.n07EBg8l045592@lurza.secnetix.de>

Tom Samplonius wrote:
 > Anyways, it doesn't really matter what "df" reports.  If df is
 > folding some of the 64bit values in negative numbers, it is no
 > issue really.

It depends on the application of the OP.  If it queries the
free space on the device before writing data to it, then
the negative numbers might indeed be a problem.

If the application forks df(1), a very simple work-around
would be to install a small wrapper script that prints some
values that the application is happy with.  However, if the
application calls getfsstat(2), it will be more difficult
to work around.

By the way, the fields in the statfs structure were changed
from 32bit signed values to 64bit unsigned values between
FreeBSD 5.1 and 5.2.  So, in order to solve the problem,
the OP would have to update at least to FreeBSD 5.2.

(Don't get me wrong; I do not recommend  to install 5.2;
it's five years old and not supported anymore.  If you
update, I'd recommend to go for the latest release, which
is 7.1 right now.)

Best regards
   Oliver

-- 
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606,  Gesch?ftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M?n-
chen, HRB 125758,  Gesch?ftsf?hrer: Maik Bachmann, Olaf Erb, Ralf Gebhart

FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd

"If you think C++ is not overly complicated, just what is a protected
abstract virtual base pure virtual private destructor, and when was the
last time you needed one?"
        -- Tom Cargil, C++ Journal
From walt at relnor.com  Wed Jan  7 15:09:57 2009
From: walt at relnor.com (Walter Venable)
Date: Wed Jan  7 15:10:04 2009
Subject: FreeBSD 7.1 Breaks re and rl Network Interface Drivers
Message-ID: <8dfae1c10901070639x67945324jeeecfcac647d7976@mail.gmail.com>

FreeBSD 7.1 upgrade broke my network access, machine is totally
offline (powered-on and I can play inside it at the terminal, but
absolutely 0 network access):
This happened AFTER make kernel but BEFORE make installworld.  I think
this implies it's a kernel driver issue.

http://forums.freebsd.org/showthread.php?t=1323 (this is an ongoing
thread on the issue, the rl driver has also been reported broken).
From mike at vintners.net  Wed Jan  7 16:04:56 2009
From: mike at vintners.net (Mike Lempriere)
Date: Wed Jan  7 16:05:03 2009
Subject: mergemaster barf
In-Reply-To: <49643E92.4000602@FreeBSD.org>
References: <49643070.5000900@vintners.net> <49643E92.4000602@FreeBSD.org>
Message-ID: <4964D2B6.20801@vintners.net>

Oh, sorry, my mistake -- I had done 'make installworld' first, I just 
neglected to include it in the email.

Since that email, I tried doing another cvsup -- it added a few files, 
but not master.passwd.  Then another mergemaster -- same error.

Thanks Doug and Andrei!

Doug Barton wrote:
> Mike Lempriere wrote:
>   
>> upgrading 5-stable (was at 5.5) to 6-stable, in preparation for 6-stable
>>     
> ...
>   
>> usage: cap_mkdb [-v] [-f outfile] file [file ...]
>> *** Error code 1
>>
>> Stop in /usr/src/etc.
>>
>>  *** FATAL ERROR: Cannot 'cd' to /usr/src/etc and install files to
>>      the temproot environment
>>
>> I've checked, the directory is there (/var/tmp/temproot/etc) however the
>> file (master.passwd) is not.
>>
>> Any suggestions anyone?  Thanks!
>>     
>
> You're going to have to do installworld before running mergemaster to
> pick up the new version of cap_mkdb. This will be fine as long as you
> don't reboot before mergemaster is done.
>
> hth,
>
> Doug
>
>   

-- 
Mike Lempriere- Home: mike@vintners.net  Phone: 206-780-2146
Cellphone: 206-200-5902;  text pager: mikelemp@tmail.com

From lists at avioc.org  Wed Jan  7 16:08:52 2009
From: lists at avioc.org (Brandon Weisz)
Date: Wed Jan  7 16:09:00 2009
Subject: Panic in RELENG_7_1 with fxp(4)
In-Reply-To: <20090107103924.GA126@cdnetworks.co.kr>
References: <49600E2E.7070601@avioc.org>
	<3163F769-48B0-4CFC-8842-BBBDDAE78B51@gmail.com>
	<20090105032657.GA1842@cdnetworks.co.kr>
	<4961FACE.4060203@avioc.org>
	<20090106080333.GA6168@cdnetworks.co.kr>
	<49637755.1070708@avioc.org>
	<20090107103924.GA126@cdnetworks.co.kr>
Message-ID: <4964D384.1060301@avioc.org>

Pyun YongHyeon wrote:

....

> I think the panic message you posted below is not related with
> fxp(4). Show me panic message for fxp(4), that would be more 
> helpful to narrow down possible cause of issue.
> BTW, are you using non-standard compilation flag or customized
> kernel? Since there are lot of systems that still rely on fxp(4)
> I wonder how this issue is not reported yet.
> Did GENERIC kernel also show exact the same behaviour?
> 

Hi Pyun,

As suggested, the GENERIC kernel did not panic.  After a few more tests, 
the culprit appears to be:

device		puc

With puc(4) removed, the system is running on 7.1-RELEASE kernel with 
the fxp(4) card operating as expected.  For now I'll be shelving the 
cheap pci serial card.

If anyone wishes to investigate this further I'm happy to continue testing.

Thank you very much for your help.

Brandon


>  > After the system panic with this patch, I went into the bios and 
>  > disabled all unnecessary hardware such as parallel port, usb controller 
>  > and on-board audio.  The resulting panic below appears different.
>  > 
>  > Fatal trap 12: page fault while in kernel mode
>  > cpuid = 0; apic id = 00
>  > fault virtual address	= 0x400
>  > fault code		= supervisor read, page not present
>  > instruction pointer	= 0x20:0xc07eefec
>  > stack pointer	        = 0x28:0xe4339ac0
>  > frame pointer	        = 0x28:0xe4339ae4
>  > 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		= 28 (irq23: vr0)
>  > trap number		= 12
>  > panic: page fault
>  > cpuid = 0
>  > Uptime: 50s
>  > Physical memory: 995 MB
>  > Dumping 162 MB: 147 131 115 99 83 67 51 35 19 3
>  > 
> 
> [...]
> 

From gavin at FreeBSD.org  Wed Jan  7 16:47:37 2009
From: gavin at FreeBSD.org (Gavin Atkinson)
Date: Wed Jan  7 16:47:43 2009
Subject: FreeBSD 7.1 Breaks re and rl Network Interface Drivers
In-Reply-To: <8dfae1c10901070639x67945324jeeecfcac647d7976@mail.gmail.com>
References: <8dfae1c10901070639x67945324jeeecfcac647d7976@mail.gmail.com>
Message-ID: <1231346850.84852.13.camel@buffy.york.ac.uk>

On Wed, 2009-01-07 at 09:39 -0500, Walter Venable wrote:
> FreeBSD 7.1 upgrade broke my network access, machine is totally
> offline (powered-on and I can play inside it at the terminal, but
> absolutely 0 network access):
> This happened AFTER make kernel but BEFORE make installworld.  I think
> this implies it's a kernel driver issue.
> 
> http://forums.freebsd.org/showthread.php?t=1323 (this is an ongoing
> thread on the issue, the rl driver has also been reported broken).

What version of FreeBSD did you upgrade from?

Gavin
From dieggo.rbo at gmail.com  Wed Jan  7 17:41:54 2009
From: dieggo.rbo at gmail.com (Diego Ribeiro)
Date: Wed Jan  7 17:42:02 2009
Subject: Error in make buildworld
Message-ID: <966852d10901070941u1f0b96efq98ede931a4586a9@mail.gmail.com>

Hi all,

 I'm a new member of this list and I have a problem when execute
a make buildworld in my FreeBSD. I'm using

FreeBSD user.domain.local 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #1:
root@user.domain.local:/usr/obj/usr/src/sys/GENERIC  i386


The error returned is

cc -O2 -fno-strict-aliasing -pipe -DIN_GCC -DHAVE_CONFIG_H
-DPREFIX=\"/usr/obj/usr/src/tmp/usr\"
-I/usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/cc/cc_int/../cc_tools
-I/usr/src/gnu/usr.bin/cc/cc_int/../cc_tools
-I/usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc
-I/usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/config
-I/usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcclibs/include
-I/usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcclibs/libcpp/include
-I/usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcclibs/libdecnumber
-I/usr/obj/usr/src/tmp/legacy/usr/include -c
/usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/c-pretty-print.c
/usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/config/i386/i386.md:
In function 'insn_default_latency':
/usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/config/i386/
i386.md:209: internal compiler error: Segmentation fault: 11
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.
*** Error code 1
1 error
*** Error code 2
1 error
*** Error code 2
1 error
*** Error code 2
1 error
*** Error code 2
1 error

In attach the buildworld output.

Anyone can help-me

tank's for atention



-- 
       dieggo.rbo at gmail dot com
       FreeBSD-BR User: #1047
       Linux User:  #395884
      www.linkedin.com/in/diegodias
       Limeira - SP -  [<o>]
From walt at relnor.com  Wed Jan  7 18:39:36 2009
From: walt at relnor.com (Walter Venable)
Date: Wed Jan  7 18:39:43 2009
Subject: FreeBSD 7.1 Breaks re and rl Network Interface Drivers
In-Reply-To: <1231346850.84852.13.camel@buffy.york.ac.uk>
References: <8dfae1c10901070639x67945324jeeecfcac647d7976@mail.gmail.com>
	<1231346850.84852.13.camel@buffy.york.ac.uk>
Message-ID: <486185590901071012m69606fc0rab58ca2caceaeab4@mail.gmail.com>

I was on cvsup tag RELENG_7_0 and I upgraded to RELENG_7_1.  All that
and more details are in the URL I provided.

On Wed, Jan 7, 2009 at 11:47 AM, Gavin Atkinson <gavin@freebsd.org> wrote:
> On Wed, 2009-01-07 at 09:39 -0500, Walter Venable wrote:
>> FreeBSD 7.1 upgrade broke my network access, machine is totally
>> offline (powered-on and I can play inside it at the terminal, but
>> absolutely 0 network access):
>> This happened AFTER make kernel but BEFORE make installworld.  I think
>> this implies it's a kernel driver issue.
>>
>> http://forums.freebsd.org/showthread.php?t=1323 (this is an ongoing
>> thread on the issue, the rl driver has also been reported broken).
>
> What version of FreeBSD did you upgrade from?
>
> Gavin
>
From walt at relnor.com  Wed Jan  7 18:45:23 2009
From: walt at relnor.com (Walter Venable)
Date: Wed Jan  7 18:45:30 2009
Subject: FreeBSD 7.1 Breaks re and rl Network Interface Drivers
In-Reply-To: <000701c970f6$aaa64960$fff2dc20$@com>
References: <8dfae1c10901070639x67945324jeeecfcac647d7976@mail.gmail.com>
	<1231346850.84852.13.camel@buffy.york.ac.uk>
	<000701c970f6$aaa64960$fff2dc20$@com>
Message-ID: <486185590901071045r3549d00y76eecffaf35007d8@mail.gmail.com>

On Wed, Jan 7, 2009 at 1:34 PM, Brian Duke <brian@box201.com> wrote:
> Walter,
> I too have these two interfaces and was forced to disconnect my rl0 in order
> for my static ip on re0 to route correctly. If both interfaces are up on the
> same network even if both are different IPs all routing stopped. I was
> planning on doing a little load balancing project. I didn't due to lack of
> time.
>
> #ifconfig rl0 down
>
> left my interface up and active. The interface would not change its IP
> through sysinstalls' enable networking interfaces. I could do this:
>
> #ifconfig rl0 inet 192.168.1.150
>
> But my routing was messed up at that point and was confirmed via:
>
> #netstat -r
>
> The return information looked like it was stuck or lost and the command
> never finished.
> I had to disconnect one or the other but both simply showed no routes. I
> disconnected rl0 because it was a 10/100m interface and left my re0 gig
> interface connected rebooted and the routes and networking is again stable.
> In the interest of full disclosure rl0 is on the motherboard re0 is a pci
> card.

Brian, was this happening to you on 7.0 also or just 7.1?
From edv at americanadigital.com.br  Wed Jan  7 19:23:08 2009
From: edv at americanadigital.com.br (Edvaldo Silva)
Date: Wed Jan  7 19:23:25 2009
Subject: NIC for VLAN
Message-ID: <5494.189.36.224.139.1231354907.squirrel@correio.americanadigital.com.br>

Hello, guys!

Please, can someone point a NIC, PCI 2.2 specs, full VLAN capable under
FreeBSD?

I?m finding terrible issues using RTL8169 and 3C9x, almost all for the
fact NIC cannot handle MTU a little bigger than 1500 (1500 + vlan
tagging).

I don?t wish reducing MTU.

-- 
Edvaldo Silva - Administrador de Redes
Americana Digital
www.americanadigital.com.br
(19) 3471-2000

From kometen at gmail.com  Wed Jan  7 19:41:33 2009
From: kometen at gmail.com (Claus Guttesen)
Date: Wed Jan  7 19:41:41 2009
Subject: Error in make buildworld
In-Reply-To: <966852d10901070941u1f0b96efq98ede931a4586a9@mail.gmail.com>
References: <966852d10901070941u1f0b96efq98ede931a4586a9@mail.gmail.com>
Message-ID: <b41c75520901071112q49afbce7ybb2b622568476ee8@mail.gmail.com>

>  I'm a new member of this list and I have a problem when execute
> a make buildworld in my FreeBSD. I'm using
>
> FreeBSD user.domain.local 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #1:
> root@user.domain.local:/usr/obj/usr/src/sys/GENERIC  i386

I ca't help you with the error below unfortunately. You can try to
update to the latest source by issuing 'csup /etc/release-supfile' and
then retry your buildworld. Remember to remove /usr/obj/* before
buildworld.

HTH

Claus

> The error returned is
>
> cc -O2 -fno-strict-aliasing -pipe -DIN_GCC -DHAVE_CONFIG_H
> -DPREFIX=\"/usr/obj/usr/src/tmp/usr\"
> -I/usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/cc/cc_int/../cc_tools
> -I/usr/src/gnu/usr.bin/cc/cc_int/../cc_tools
> -I/usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc
> -I/usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/config
> -I/usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcclibs/include
> -I/usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcclibs/libcpp/include
> -I/usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcclibs/libdecnumber
> -I/usr/obj/usr/src/tmp/legacy/usr/include -c
> /usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/c-pretty-print.c
> /usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/config/i386/i386.md:
> In function 'insn_default_latency':
> /usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/config/i386/
> i386.md:209: internal compiler error: Segmentation fault: 11
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See <URL:http://gcc.gnu.org/bugs.html> for instructions.
> *** Error code 1
> 1 error
> *** Error code 2
> 1 error
> *** Error code 2
> 1 error
> *** Error code 2
> 1 error
> *** Error code 2
> 1 error
>
> In attach the buildworld output.
>
> Anyone can help-me
>
> tank's for atention
>
>
>
> --
>       dieggo.rbo at gmail dot com
>       FreeBSD-BR User: #1047
>       Linux User:  #395884
>      www.linkedin.com/in/diegodias
>       Limeira - SP -  [<o>]
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
>



-- 
regards
Claus

When lenity and cruelty play for a kingdom,
the gentler gamester is the soonest winner.

Shakespeare
From richardtector at thekeelecentre.com  Wed Jan  7 19:45:46 2009
From: richardtector at thekeelecentre.com (Richard Tector)
Date: Wed Jan  7 19:45:53 2009
Subject: NIC for VLAN
In-Reply-To: <5494.189.36.224.139.1231354907.squirrel@correio.americanadigital.com.br>
References: <5494.189.36.224.139.1231354907.squirrel@correio.americanadigital.com.br>
Message-ID: <49650658.5080501@thekeelecentre.com>

Edvaldo Silva wrote:
> Hello, guys!
> 
> Please, can someone point a NIC, PCI 2.2 specs, full VLAN capable under
> FreeBSD?
> 
> I?m finding terrible issues using RTL8169 and 3C9x, almost all for the
> fact NIC cannot handle MTU a little bigger than 1500 (1500 + vlan
> tagging).
> 
> I don?t wish reducing MTU.


Intel Pro/100 (fxp driver) or Pro/1000 (em/igb driver) are probably the 
best supported and best performing on FreeBSD, and the Pro/1000 at least 
has excellent VLAN support.

Regards,

Richard Tector

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 2709 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090107/30eac678/smime.bin
From cswiger at mac.com  Wed Jan  7 19:45:55 2009
From: cswiger at mac.com (Chuck Swiger)
Date: Wed Jan  7 19:46:01 2009
Subject: NIC for VLAN
In-Reply-To: <5494.189.36.224.139.1231354907.squirrel@correio.americanadigital.com.br>
References: <5494.189.36.224.139.1231354907.squirrel@correio.americanadigital.com.br>
Message-ID: <08B905C7-9A68-49F3-9BA4-F4D7D6EDD2B6@mac.com>

On Jan 7, 2009, at 11:01 AM, Edvaldo Silva wrote:
> Please, can someone point a NIC, PCI 2.2 specs, full VLAN capable  
> under FreeBSD?

Intel fxp or em; Broadcom bge or bce....

Regards,
-- 
-Chuck

From zbeeble at gmail.com  Wed Jan  7 19:56:32 2009
From: zbeeble at gmail.com (Zaphod Beeblebrox)
Date: Wed Jan  7 19:56:42 2009
Subject: NIC for VLAN
In-Reply-To: <5494.189.36.224.139.1231354907.squirrel@correio.americanadigital.com.br>
References: <5494.189.36.224.139.1231354907.squirrel@correio.americanadigital.com.br>
Message-ID: <5f67a8c40901071132q4c5361ees1c9960c57f3ac221@mail.gmail.com>

On Wed, Jan 7, 2009 at 2:01 PM, Edvaldo Silva
<edv@americanadigital.com.br>wrote:

> Hello, guys!
>
> Please, can someone point a NIC, PCI 2.2 specs, full VLAN capable under
> FreeBSD?
>
> I?m finding terrible issues using RTL8169 and 3C9x, almost all for the
> fact NIC cannot handle MTU a little bigger than 1500 (1500 + vlan
> tagging).
>
> I don?t wish reducing MTU.
>

For 100 meg nics, I almost exclusively use Intel Etherexpress "fxp" cards.
I've used them for a long time in servers, but now they average around $3 in
quantity on eBay and I use them in everything.  Also, many off-lease PC's
come with it on the motherboard.

For GigE, I prefer (also) Intel Etherexpress --- but the driver is "em"  (I
have not tried "igb).  I also have had no complaints with "bge" and "bce"
driver chipsets on equipped motherboards.

In both cases, I make heavy use of vlans and hardware vlan tagging.  Many
router machines have between 10 and 50 vlan interfaces.
From dieggo.rbo at gmail.com  Wed Jan  7 19:57:31 2009
From: dieggo.rbo at gmail.com (Diego Ribeiro)
Date: Wed Jan  7 19:57:38 2009
Subject: Error in make buildworld
In-Reply-To: <b41c75520901071112q49afbce7ybb2b622568476ee8@mail.gmail.com>
References: <966852d10901070941u1f0b96efq98ede931a4586a9@mail.gmail.com>
	<b41c75520901071112q49afbce7ybb2b622568476ee8@mail.gmail.com>
Message-ID: <966852d10901071157q43b2ff6ha5b9eb0df79b877c@mail.gmail.com>

Hi Claus, thanks for return. I'm tried this steps below before send the
first email and not resolve my problem =/

make cleandir && make cleandir
rm -rf /usr/obj/*
make -j6 buildworld

but...the segmentation fault persist.
I have more logs of buidworld, if you want, I send  :D

any idea? and thanks again.


On Wed, Jan 7, 2009 at 5:12 PM, Claus Guttesen <kometen@gmail.com> wrote:

> >  I'm a new member of this list and I have a problem when execute
> > a make buildworld in my FreeBSD. I'm using
> >
> > FreeBSD user.domain.local 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #1:
> > root@user.domain.local:/usr/obj/usr/src/sys/GENERIC  i386
>
> I ca't help you with the error below unfortunately. You can try to
> update to the latest source by issuing 'csup /etc/release-supfile' and
> then retry your buildworld. Remember to remove /usr/obj/* before
> buildworld.
>
> HTH
>
> Claus
>
> > The error returned is
> >
> > cc -O2 -fno-strict-aliasing -pipe -DIN_GCC -DHAVE_CONFIG_H
> > -DPREFIX=\"/usr/obj/usr/src/tmp/usr\"
> > -I/usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/cc/cc_int/../cc_tools
> > -I/usr/src/gnu/usr.bin/cc/cc_int/../cc_tools
> > -I/usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc
> > -I/usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/config
> > -I/usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcclibs/include
> >
> -I/usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcclibs/libcpp/include
> > -I/usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcclibs/libdecnumber
> > -I/usr/obj/usr/src/tmp/legacy/usr/include -c
> > /usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/c-pretty-print.c
> > /usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/config/i386/
> i386.md:
> > In function 'insn_default_latency':
> > /usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/config/i386/
> > i386.md:209: internal compiler error: Segmentation fault: 11
> > Please submit a full bug report,
> > with preprocessed source if appropriate.
> > See <URL:http://gcc.gnu.org/bugs.html> for instructions.
> > *** Error code 1
> > 1 error
> > *** Error code 2
> > 1 error
> > *** Error code 2
> > 1 error
> > *** Error code 2
> > 1 error
> > *** Error code 2
> > 1 error
> >
> > In attach the buildworld output.
> >
> > Anyone can help-me
> >
> > tank's for atention
> >
> >
> >
> > --
> >       dieggo.rbo at gmail dot com
> >       FreeBSD-BR User: #1047
> >       Linux User:  #395884
> >      www.linkedin.com/in/diegodias
> >       Limeira - SP -  [<o>]
> > _______________________________________________
> > freebsd-stable@freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org
> "
> >
>
>
>
> --
> regards
> Claus
>
> When lenity and cruelty play for a kingdom,
> the gentler gamester is the soonest winner.
>
> Shakespeare
>



-- 
       dieggo.rbo at gmail dot com
       FreeBSD-BR User: #1047
       Linux User:  #395884
      www.linkedin.com/in/diegodias
       Limeira - SP -  [<o>]
From biancalana at gmail.com  Wed Jan  7 19:58:21 2009
From: biancalana at gmail.com (Alexandre Biancalana)
Date: Wed Jan  7 19:58:27 2009
Subject: NIC for VLAN
In-Reply-To: <5494.189.36.224.139.1231354907.squirrel@correio.americanadigital.com.br>
References: <5494.189.36.224.139.1231354907.squirrel@correio.americanadigital.com.br>
Message-ID: <8e10486b0901071134m258a7c6cnd074f60189aafc19@mail.gmail.com>

>From man vlan:

 By now, the list of physical interfaces able of full VLAN processing in
     the hardware is limited to the following devices: age(4), bce(4), bge(4),
     cxgb(4), em(4), ixgb(4), msk(4), nge(4), re(4), stge(4), ti(4), txp(4),
     and vge(4).


On 1/7/09, Edvaldo Silva <edv@americanadigital.com.br> wrote:
> Hello, guys!
>
>  Please, can someone point a NIC, PCI 2.2 specs, full VLAN capable under
>  FreeBSD?
>
>  I?m finding terrible issues using RTL8169 and 3C9x, almost all for the
>  fact NIC cannot handle MTU a little bigger than 1500 (1500 + vlan
>  tagging).
>
>  I don?t wish reducing MTU.
>
>  --
>  Edvaldo Silva - Administrador de Redes
>  Americana Digital
>  www.americanadigital.com.br
>  (19) 3471-2000
>
>  _______________________________________________
>  freebsd-stable@freebsd.org mailing list
>  http://lists.freebsd.org/mailman/listinfo/freebsd-stable
>  To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
>
From peter at simons-rock.edu  Wed Jan  7 20:11:02 2009
From: peter at simons-rock.edu (Peter C. Lai)
Date: Wed Jan  7 20:11:09 2009
Subject: NIC for VLAN
In-Reply-To: <5494.189.36.224.139.1231354907.squirrel@correio.americanadigital.com.br>
References: <5494.189.36.224.139.1231354907.squirrel@correio.americanadigital.com.br>
Message-ID: <20090107194722.GB45538@cesium.hyperfine.info>

The Intel ones driven by em(4) (Intel EtherExpress Pro/1000)?

RTL8169/8111/8168 use closed specs, quirks have to be reverse engineered
into the driver.

On 2009-01-07 05:01:47PM -0200, Edvaldo Silva wrote:
> Hello, guys!
> 
> Please, can someone point a NIC, PCI 2.2 specs, full VLAN capable under
> FreeBSD?
> 
> I?m finding terrible issues using RTL8169 and 3C9x, almost all for the
> fact NIC cannot handle MTU a little bigger than 1500 (1500 + vlan
> tagging).
> 
> I don?t wish reducing MTU.
> 
> -- 
> Edvaldo Silva - Administrador de Redes
> Americana Digital
> www.americanadigital.com.br
> (19) 3471-2000
> 
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"

-- 
===========================================================
Peter C. Lai                 | Bard College at Simon's Rock
Systems Administrator        | 84 Alford Rd.
Information Technology Svcs. | Gt. Barrington, MA 01230 USA
peter AT simons-rock.edu     | (413) 528-7428
===========================================================

From emaste at freebsd.org  Wed Jan  7 21:00:46 2009
From: emaste at freebsd.org (Ed Maste)
Date: Wed Jan  7 21:00:54 2009
Subject: Adaptec AIC-9410
In-Reply-To: <alpine.BSF.1.10.0812121212380.70152@74.222.211.140>
References: <alpine.BSF.1.10.0812121212380.70152@74.222.211.140>
Message-ID: <20090107204838.GA94239@sandvine.com>

On Fri, Dec 12, 2008 at 12:16:26PM -0600, Paul Taulborg wrote:

> Both of these have an Adaptec AIC-9410 SAS controller in them, that is 
> apparently not detected (or supported?) by FreeBSD (amd64) (7.0 or 7.1 
> RC1)

No verison of FreeBSD has support for the AIC-9410, and I am not aware
of any work to add support for it.

The AIC-9410 is not available as a standalone controller from Adaptec
any longer, so I doubt they have much interest in new driver support
for it.  (It's still used as a component on at least some RAID cards.)

Unfortunately, I suspect your only choices are a different SAS
controller or a different OS.

-Ed
From dkelly at hiwaay.net  Wed Jan  7 21:32:11 2009
From: dkelly at hiwaay.net (David Kelly)
Date: Wed Jan  7 21:32:18 2009
Subject: NIC for VLAN
In-Reply-To: <5f67a8c40901071132q4c5361ees1c9960c57f3ac221@mail.gmail.com>
References: <5494.189.36.224.139.1231354907.squirrel@correio.americanadigital.com.br>
	<5f67a8c40901071132q4c5361ees1c9960c57f3ac221@mail.gmail.com>
Message-ID: <20090107210408.GB71960@Grumpy.DynDNS.org>

On Wed, Jan 07, 2009 at 02:32:03PM -0500, Zaphod Beeblebrox wrote:
> 
> For 100 meg nics, I almost exclusively use Intel Etherexpress "fxp"
> cards. I've used them for a long time in servers, but now they average
> around $3 in quantity on eBay and I use them in everything.  Also,
> many off-lease PC's come with it on the motherboard.

I second, or third, or Nth, recommend the Etherexpress Pro cards. Not
only do they Just Simply Work(tm) in FreeBSD, if (heaven forbid) one has
to do Windows the Intel-provided driver provides exceptional controls
and features that the stock Windows driver does not, such as VLAN.

-- 
David Kelly N4HHE, dkelly@HiWAAY.net
========================================================================
Whom computers would destroy, they must first drive mad.
From pluknet at gmail.com  Wed Jan  7 21:51:23 2009
From: pluknet at gmail.com (pluknet)
Date: Wed Jan  7 21:51:56 2009
Subject: Error in make buildworld
In-Reply-To: <966852d10901070941u1f0b96efq98ede931a4586a9@mail.gmail.com>
References: <966852d10901070941u1f0b96efq98ede931a4586a9@mail.gmail.com>
Message-ID: <a31046fc0901071321k3e1b1bb3gbad8e692554e475@mail.gmail.com>

2009/1/7 Diego Ribeiro <dieggo.rbo@gmail.com>:
> Hi all,
>
>  I'm a new member of this list and I have a problem when execute
> a make buildworld in my FreeBSD. I'm using
>
> FreeBSD user.domain.local 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #1:
> root@user.domain.local:/usr/obj/usr/src/sys/GENERIC  i386
>
>
> The error returned is
>
> cc -O2 -fno-strict-aliasing -pipe -DIN_GCC -DHAVE_CONFIG_H
> -DPREFIX=\"/usr/obj/usr/src/tmp/usr\"
> -I/usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/cc/cc_int/../cc_tools
> -I/usr/src/gnu/usr.bin/cc/cc_int/../cc_tools
> -I/usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc
> -I/usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/config
> -I/usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcclibs/include
> -I/usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcclibs/libcpp/include
> -I/usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcclibs/libdecnumber
> -I/usr/obj/usr/src/tmp/legacy/usr/include -c
> /usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/c-pretty-print.c
> /usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/config/i386/i386.md:
> In function 'insn_default_latency':
> /usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/config/i386/
> i386.md:209: internal compiler error: Segmentation fault: 11
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See <URL:http://gcc.gnu.org/bugs.html> for instructions.
> *** Error code 1
> 1 error
> *** Error code 2
> 1 error
> *** Error code 2
> 1 error
> *** Error code 2
> 1 error
> *** Error code 2
> 1 error
>
> In attach the buildworld output.

That usually signals about bad/insufficient RAM and/or CPU overheating.

See archives.

-- 
wbr,
pluknet
From hawei at free.fr  Wed Jan  7 22:00:55 2009
From: hawei at free.fr (Harald Weis)
Date: Wed Jan  7 22:01:07 2009
Subject: Samsung SCX-4200 printer
In-Reply-To: <20090106220632.GU45538@cesium.hyperfine.info>
References: <20090104221422.GA3114@pollux2.free.local.net>
	<20090105173635.575e32ff.torfinn.ingolfsen@broadpark.no>
	<20090105164403.GE3756@trusted-logic.com>
	<20090105222623.GA52838@slackbox.xs4all.nl>
	<20090105232354.GA85619@onelab2.iet.unipi.it>
	<20090106210845.GA88675@slackbox.xs4all.nl>
	<001401c97048$42bcde80$c8369b80$@com>
	<20090106220632.GU45538@cesium.hyperfine.info>
Message-ID: <20090107220357.GA3985@pollux2.free.local.net>

On Tue, Jan 06, 2009 at 05:06:32PM -0500, Peter C. Lai wrote:
> What language does this printer use? I am a big fan of the minimalistic
> BSD LPD/R, so I usually just whip up an output filter that cats everything
> (since just about every app natively prints as postscript these days 
> [besides gimp-app I guess]) to ghostscript. Works for basically any printer
> with PCL or PS support (actually, with some of the the elcheapo PS 
> imitations out there, usually PCL5/XL works better). To me, CUPS/Foomatic 
> comes with some fancy PPDs and filters, but I think a lot of that is 
> bloated since it does similar things under the hood but wrapped in more
> layers of magic...
> 
> On 2009-01-06 04:46:40PM -0500, SDH Support wrote:
> > 
> > > Is there a way to install the SCX-4200 printer on a FreeBSD box ?
> > 
> > I would recommend googling this printer and determining its support on linux
> > first and then perhaps following the large amount of documentation with
> > installing CUPS for freebsd. I've gotten many different printers working on
> > my own.
> > 
> > 
> > 
> > 
> > ---
> > Kevin K.
> > Systems Administrator
> > www.webcanadahosting.com 
> > 
> > _______________________________________________
> > freebsd-stable@freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
> 
> -- 
> ===========================================================
> Peter C. Lai                 | Bard College at Simon's Rock
> Systems Administrator        | 84 Alford Rd.
> Information Technology Svcs. | Gt. Barrington, MA 01230 USA
> peter AT simons-rock.edu     | (413) 528-7428
> ===========================================================

Many thanks for all your comments and hints.

Briefly for your information: The printer was bought by a person
who was a Linux user from the very beginning. He had no time to install
it though. In the mean time he has become a FreeBSD user and is working
all-day on a FreeBSD laptop (as a general practitioner, perhaps the
only one on earth). He's still short of time. A year ago or so I
tried to install the printer on his desktop machine. But I could not
find any SCX-4200 reference on openprinting.org. This time I reinstalled
all CUPS components on a 7.0-RELEASE, and finally looked for your help.

Well, I've started with the first advice, found UnifiedLinuxDriver.tar.gz,
installed manually scx4200.ppd and rastertosamsungspl. I tried all
possible file locations for rastertosamsungspl. But CUPS keeps saying
that it cannot find rastertosamsungspl. It seems to me that CUPS
would be happy with these two files.

'spl' seems to stand for Samsung Printer Language.

Harald
-- 
FreeBSD 7.0-RELEASE FreeBSD 7.0-RELEASE #0: Sun Feb 24 19:59:52 UTC 2008
From peter at simons-rock.edu  Wed Jan  7 22:10:15 2009
From: peter at simons-rock.edu (Peter C. Lai)
Date: Wed Jan  7 22:10:26 2009
Subject: Samsung SCX-4200 printer
In-Reply-To: <20090107220357.GA3985@pollux2.free.local.net>
References: <20090104221422.GA3114@pollux2.free.local.net>
	<20090105173635.575e32ff.torfinn.ingolfsen@broadpark.no>
	<20090105164403.GE3756@trusted-logic.com>
	<20090105222623.GA52838@slackbox.xs4all.nl>
	<20090105232354.GA85619@onelab2.iet.unipi.it>
	<20090106210845.GA88675@slackbox.xs4all.nl>
	<001401c97048$42bcde80$c8369b80$@com>
	<20090106220632.GU45538@cesium.hyperfine.info>
	<20090107220357.GA3985@pollux2.free.local.net>
Message-ID: <20090107221006.GE45538@cesium.hyperfine.info>

On 2009-01-07 11:03:57PM +0100, Harald Weis wrote:
> On Tue, Jan 06, 2009 at 05:06:32PM -0500, Peter C. Lai wrote:
> > What language does this printer use? I am a big fan of the minimalistic
> > BSD LPD/R, so I usually just whip up an output filter that cats everything
> > (since just about every app natively prints as postscript these days 
> > [besides gimp-app I guess]) to ghostscript. Works for basically any printer
> > with PCL or PS support (actually, with some of the the elcheapo PS 
> > imitations out there, usually PCL5/XL works better). To me, CUPS/Foomatic 
> > comes with some fancy PPDs and filters, but I think a lot of that is 
> > bloated since it does similar things under the hood but wrapped in more
> > layers of magic...
> > 
> > On 2009-01-06 04:46:40PM -0500, SDH Support wrote:
> > > 
> > > > Is there a way to install the SCX-4200 printer on a FreeBSD box ?
> > > 
> > > I would recommend googling this printer and determining its support on linux
> > > first and then perhaps following the large amount of documentation with
> > > installing CUPS for freebsd. I've gotten many different printers working on
> > > my own.
> > > 
> > > 
> > > 
> > > 
> > > ---
> > > Kevin K.
> > > Systems Administrator
> > > www.webcanadahosting.com 
> > > 
> > > _______________________________________________
> > > freebsd-stable@freebsd.org mailing list
> > > http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> > > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
> > 
> > -- 
> > ===========================================================
> > Peter C. Lai                 | Bard College at Simon's Rock
> > Systems Administrator        | 84 Alford Rd.
> > Information Technology Svcs. | Gt. Barrington, MA 01230 USA
> > peter AT simons-rock.edu     | (413) 528-7428
> > ===========================================================
> 
> Many thanks for all your comments and hints.
> 
> Briefly for your information: The printer was bought by a person
> who was a Linux user from the very beginning. He had no time to install
> it though. In the mean time he has become a FreeBSD user and is working
> all-day on a FreeBSD laptop (as a general practitioner, perhaps the
> only one on earth). He's still short of time. A year ago or so I
> tried to install the printer on his desktop machine. But I could not
> find any SCX-4200 reference on openprinting.org. This time I reinstalled
> all CUPS components on a 7.0-RELEASE, and finally looked for your help.
> 
> Well, I've started with the first advice, found UnifiedLinuxDriver.tar.gz,
> installed manually scx4200.ppd and rastertosamsungspl. I tried all
> possible file locations for rastertosamsungspl. But CUPS keeps saying
> that it cannot find rastertosamsungspl. It seems to me that CUPS
> would be happy with these two files.
> 
> 'spl' seems to stand for Samsung Printer Language.
> 

well, if you're on cups, the splix driver should come with that.

"find / -name rastertosamsungspl" would be my best guess, then
you have to figure out where it really is supposed to live.

If you're on plain ghostscript try using the 'gdi' output device

-- 
===========================================================
Peter C. Lai                 | Bard College at Simon's Rock
Systems Administrator        | 84 Alford Rd.
Information Technology Svcs. | Gt. Barrington, MA 01230 USA
peter AT simons-rock.edu     | (413) 528-7428
===========================================================

From walt at relnor.com  Wed Jan  7 23:50:44 2009
From: walt at relnor.com (Walter Venable)
Date: Wed Jan  7 23:50:50 2009
Subject: FreeBSD 7.1 Breaks re and rl Network Interface Drivers
In-Reply-To: <8dfae1c10901070639x67945324jeeecfcac647d7976@mail.gmail.com>
References: <8dfae1c10901070639x67945324jeeecfcac647d7976@mail.gmail.com>
Message-ID: <8dfae1c10901071550s69d99802p31ca7c775f3d6823@mail.gmail.com>

Booting kernel.old, which is 7.0-RELEASE-p7 completely alleviates all
problems.  I believe this roundly confirms that this is a bug in the
7.1-RELEASE re kernel drivers.

On Wed, Jan 7, 2009 at 9:39 AM, Walter Venable <walt@relnor.com> wrote:
> FreeBSD 7.1 upgrade broke my network access, machine is totally
> offline (powered-on and I can play inside it at the terminal, but
> absolutely 0 network access):
> This happened AFTER make kernel but BEFORE make installworld.  I think
> this implies it's a kernel driver issue.
>
> http://forums.freebsd.org/showthread.php?t=1323 (this is an ongoing
> thread on the issue, the rl driver has also been reported broken).
>
From kometen at gmail.com  Thu Jan  8 00:47:30 2009
From: kometen at gmail.com (Claus Guttesen)
Date: Thu Jan  8 00:47:37 2009
Subject: Error in make buildworld
In-Reply-To: <966852d10901071157q43b2ff6ha5b9eb0df79b877c@mail.gmail.com>
References: <966852d10901070941u1f0b96efq98ede931a4586a9@mail.gmail.com>
	<b41c75520901071112q49afbce7ybb2b622568476ee8@mail.gmail.com>
	<966852d10901071157q43b2ff6ha5b9eb0df79b877c@mail.gmail.com>
Message-ID: <b41c75520901071647x34100a6k20a8dc960986e3da@mail.gmail.com>

> Hi Claus, thanks for return. I'm tried this steps below before send the
> first email and not resolve my problem =/

I notice you run a pre-release of 7.1. Did you update to the latest 7.1-release?

> make cleandir && make cleandir
> rm -rf /usr/obj/*
> make -j6 buildworld
>
> but...the segmentation fault persist.
> I have more logs of buidworld, if you want, I send  :D
>
> any idea? and thanks again.

Could you try a buildworld without the -j parameter? If it still fails
but in different stages of the buildworld it could be bad/overheated
ram as mentioned by pluknet.

-- 
regards
Claus

When lenity and cruelty play for a kingdom,
the gentler gamester is the soonest winner.

Shakespeare
From pyunyh at gmail.com  Thu Jan  8 01:19:26 2009
From: pyunyh at gmail.com (Pyun YongHyeon)
Date: Thu Jan  8 01:19:34 2009
Subject: Panic in RELENG_7_1 with fxp(4)
In-Reply-To: <4964D384.1060301@avioc.org>
References: <49600E2E.7070601@avioc.org>
	<3163F769-48B0-4CFC-8842-BBBDDAE78B51@gmail.com>
	<20090105032657.GA1842@cdnetworks.co.kr>
	<4961FACE.4060203@avioc.org>
	<20090106080333.GA6168@cdnetworks.co.kr>
	<49637755.1070708@avioc.org>
	<20090107103924.GA126@cdnetworks.co.kr>
	<4964D384.1060301@avioc.org>
Message-ID: <20090108011914.GB1256@cdnetworks.co.kr>

On Wed, Jan 07, 2009 at 10:08:36AM -0600, Brandon Weisz wrote:
 > Pyun YongHyeon wrote:
 > 
 > ....
 > 
 > >I think the panic message you posted below is not related with
 > >fxp(4). Show me panic message for fxp(4), that would be more 
 > >helpful to narrow down possible cause of issue.
 > >BTW, are you using non-standard compilation flag or customized
 > >kernel? Since there are lot of systems that still rely on fxp(4)
 > >I wonder how this issue is not reported yet.
 > >Did GENERIC kernel also show exact the same behaviour?
 > >
 > 
 > Hi Pyun,
 > 
 > As suggested, the GENERIC kernel did not panic.  After a few more tests, 
 > the culprit appears to be:
 > 
 > device		puc
 > 
 > With puc(4) removed, the system is running on 7.1-RELEASE kernel with 
 > the fxp(4) card operating as expected.  For now I'll be shelving the 
 > cheap pci serial card.
 > 
 > If anyone wishes to investigate this further I'm happy to continue testing.
 > 

Hmm, I still have no idea how puc(4) can trigger the issue.
Marcel may have more idea how to debug this(CCed).

 > Thank you very much for your help.
 > 
 > Brandon
 > 
 > 
 > > > After the system panic with this patch, I went into the bios and 
 > > > disabled all unnecessary hardware such as parallel port, usb controller 
 > > > and on-board audio.  The resulting panic below appears different.
 > > > 
 > > > Fatal trap 12: page fault while in kernel mode
 > > > cpuid = 0; apic id = 00
 > > > fault virtual address	= 0x400
 > > > fault code		= supervisor read, page not present
 > > > instruction pointer	= 0x20:0xc07eefec
 > > > stack pointer	        = 0x28:0xe4339ac0
 > > > frame pointer	        = 0x28:0xe4339ae4
 > > > 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		= 28 (irq23: vr0)
 > > > trap number		= 12
 > > > panic: page fault
 > > > cpuid = 0
 > > > Uptime: 50s
 > > > Physical memory: 995 MB
 > > > Dumping 162 MB: 147 131 115 99 83 67 51 35 19 3
 > > > 
 > >
 > >[...]
 > >
 > 

-- 
Regards,
Pyun YongHyeon
From pyunyh at gmail.com  Thu Jan  8 01:50:45 2009
From: pyunyh at gmail.com (Pyun YongHyeon)
Date: Thu Jan  8 01:50:53 2009
Subject: FreeBSD 7.1 Breaks re and rl Network Interface Drivers
In-Reply-To: <8dfae1c10901071550s69d99802p31ca7c775f3d6823@mail.gmail.com>
References: <8dfae1c10901070639x67945324jeeecfcac647d7976@mail.gmail.com>
	<8dfae1c10901071550s69d99802p31ca7c775f3d6823@mail.gmail.com>
Message-ID: <20090108015036.GD1256@cdnetworks.co.kr>

On Wed, Jan 07, 2009 at 06:50:40PM -0500, Walter Venable wrote:
 > Booting kernel.old, which is 7.0-RELEASE-p7 completely alleviates all
 > problems.  I believe this roundly confirms that this is a bug in the
 > 7.1-RELEASE re kernel drivers.
 > 

Please show me full dmesg output.

 > On Wed, Jan 7, 2009 at 9:39 AM, Walter Venable <walt@relnor.com> wrote:
 > > FreeBSD 7.1 upgrade broke my network access, machine is totally
 > > offline (powered-on and I can play inside it at the terminal, but
 > > absolutely 0 network access):
 > > This happened AFTER make kernel but BEFORE make installworld.  I think
 > > this implies it's a kernel driver issue.
 > >
 > > http://forums.freebsd.org/showthread.php?t=1323 (this is an ongoing
 > > thread on the issue, the rl driver has also been reported broken).
 > >

-- 
Regards,
Pyun YongHyeon
From pyunyh at gmail.com  Thu Jan  8 01:54:56 2009
From: pyunyh at gmail.com (Pyun YongHyeon)
Date: Thu Jan  8 01:55:02 2009
Subject: FreeBSD 7.1 Breaks re and rl Network Interface Drivers
In-Reply-To: <8dfae1c10901070639x67945324jeeecfcac647d7976@mail.gmail.com>
References: <8dfae1c10901070639x67945324jeeecfcac647d7976@mail.gmail.com>
Message-ID: <20090108015446.GE1256@cdnetworks.co.kr>

On Wed, Jan 07, 2009 at 09:39:32AM -0500, Walter Venable wrote:
 > FreeBSD 7.1 upgrade broke my network access, machine is totally
 > offline (powered-on and I can play inside it at the terminal, but
 > absolutely 0 network access):
 > This happened AFTER make kernel but BEFORE make installworld.  I think
 > this implies it's a kernel driver issue.
 > 
 > http://forums.freebsd.org/showthread.php?t=1323 (this is an ongoing
 > thread on the issue, the rl driver has also been reported broken).

Please start new thread for rl(4) issues.

-- 
Regards,
Pyun YongHyeon
From walt at relnor.com  Thu Jan  8 02:20:07 2009
From: walt at relnor.com (Walter Venable)
Date: Thu Jan  8 02:20:15 2009
Subject: FreeBSD 7.1 Breaks re and rl Network Interface Drivers
In-Reply-To: <20090108015036.GD1256@cdnetworks.co.kr>
References: <8dfae1c10901070639x67945324jeeecfcac647d7976@mail.gmail.com>
	<8dfae1c10901071550s69d99802p31ca7c775f3d6823@mail.gmail.com>
	<20090108015036.GD1256@cdnetworks.co.kr>
Message-ID: <486185590901071820tfcd3375sb890fe60867ec84d@mail.gmail.com>

On Wed, Jan 7, 2009 at 8:50 PM, Pyun YongHyeon <pyunyh@gmail.com> wrote:
> Please show me full dmesg output.
>

Hi Pyun,
I have attached the full dmesg output.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dmesg
Type: application/octet-stream
Size: 6562 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090108/61f49313/dmesg-0001.obj
From pyunyh at gmail.com  Thu Jan  8 02:35:20 2009
From: pyunyh at gmail.com (Pyun YongHyeon)
Date: Thu Jan  8 02:35:26 2009
Subject: FreeBSD 7.1 Breaks re and rl Network Interface Drivers
In-Reply-To: <486185590901071820tfcd3375sb890fe60867ec84d@mail.gmail.com>
References: <8dfae1c10901070639x67945324jeeecfcac647d7976@mail.gmail.com>
	<8dfae1c10901071550s69d99802p31ca7c775f3d6823@mail.gmail.com>
	<20090108015036.GD1256@cdnetworks.co.kr>
	<486185590901071820tfcd3375sb890fe60867ec84d@mail.gmail.com>
Message-ID: <20090108023506.GF1256@cdnetworks.co.kr>

On Wed, Jan 07, 2009 at 09:20:05PM -0500, Walter Venable wrote:
 > On Wed, Jan 7, 2009 at 8:50 PM, Pyun YongHyeon <pyunyh@gmail.com> wrote:
 > > Please show me full dmesg output.
 > >
 > 
 > Hi Pyun,
 > I have attached the full dmesg output.

Walter, I need dmesg output of 7.1-RELEASE.

-- 
Regards,
Pyun YongHyeon
From mike at vintners.net  Thu Jan  8 04:24:11 2009
From: mike at vintners.net (Mike Lempriere)
Date: Thu Jan  8 04:24:18 2009
Subject: mergemaster broken -- take 2
Message-ID: <49657C0A.7040404@vintners.net>

Hi folks -- sorry to be a nag, but my main production system is barely 
limping along on an old kernel with mismatched libraries.  I have no 
idea what else to do -- please help!
---
I'm upgrading 5-stable (was at 5.5) to 6-stable, in preparation for 
6-stable to 7-stable.
No problems with cvsup, make buildworld, make installworld, make 
buildkernel, mergemaster -p.
make installkernel, boot to single user.  Then mergemaster -- blammo:

config  /usr/src/etc/../usr.bin/mail/misc/mail.rc  
/usr/src/etc/../usr.bin/locate/locate/locate.rc printcap 
/var/tmp/temproot/etc;  cap_mkdb -l /var/tmp/temproot/etc/login.conf;  
install -o root -g wheel -m 755  netstart pccard_ether rc.suspend 
rc.resume /var/tmp/temproot/etc;  install -o root -g wheel -m 600  
master.passwd nsmb.conf opieaccess /var/tmp/temproot/etc;  pwd_mkdb -L 
-i -p -d /var/tmp/temproot/etc  /var/tmp/temproot/etc/master.passwd
cap_mkdb: illegal option -- l
usage: cap_mkdb [-v] [-f outfile] file [file ...]
*** Error code 1

Stop in /usr/src/etc.

 *** FATAL ERROR: Cannot 'cd' to /usr/src/etc and install files to
     the temproot environment

I've checked, the directory is there (/var/tmp/temproot/etc) however the 
file (master.passwd) is not.

Any suggestions anyone?  Thanks!

-- 
Mike Lempriere- Home: mike@vintners.net  Phone: 206-780-2146
Cellphone: 206-200-5902;  text pager: mikelemp@tmail.com

From delphij at delphij.net  Thu Jan  8 04:39:03 2009
From: delphij at delphij.net (Xin LI)
Date: Thu Jan  8 04:39:37 2009
Subject: mergemaster broken -- take 2
In-Reply-To: <49657C0A.7040404@vintners.net>
References: <49657C0A.7040404@vintners.net>
Message-ID: <49658357.6000005@delphij.net>

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

Mike Lempriere wrote:
> Hi folks -- sorry to be a nag, but my main production system is barely
> limping along on an old kernel with mismatched libraries.  I have no
> idea what else to do -- please help!
> ---
> I'm upgrading 5-stable (was at 5.5) to 6-stable, in preparation for
> 6-stable to 7-stable.
> No problems with cvsup, make buildworld, make installworld, make
> buildkernel, mergemaster -p.
> make installkernel, boot to single user.  Then mergemaster -- blammo:

Looks like you did it in wrong sequence and the system is picking up a
stale cap_mkdb.  Could you try mergemaster -p, then make installworld,
then mergemaster -i?

> config  /usr/src/etc/../usr.bin/mail/misc/mail.rc 
> /usr/src/etc/../usr.bin/locate/locate/locate.rc printcap
> /var/tmp/temproot/etc;  cap_mkdb -l /var/tmp/temproot/etc/login.conf; 
> install -o root -g wheel -m 755  netstart pccard_ether rc.suspend
> rc.resume /var/tmp/temproot/etc;  install -o root -g wheel -m 600 
> master.passwd nsmb.conf opieaccess /var/tmp/temproot/etc;  pwd_mkdb -L
> -i -p -d /var/tmp/temproot/etc  /var/tmp/temproot/etc/master.passwd
> cap_mkdb: illegal option -- l
> usage: cap_mkdb [-v] [-f outfile] file [file ...]
> *** Error code 1
> 
> Stop in /usr/src/etc.
> 
> *** FATAL ERROR: Cannot 'cd' to /usr/src/etc and install files to
>     the temproot environment
> 
> I've checked, the directory is there (/var/tmp/temproot/etc) however the
> file (master.passwd) is not.
> 
> Any suggestions anyone?  Thanks!
> 


- --
Xin LI <delphij@delphij.net>	http://www.delphij.net/
FreeBSD - The Power to Serve!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (FreeBSD)

iEYEARECAAYFAkllg1cACgkQi+vbBBjt66BPDwCfXKGJJlgtJ7LY7V99gcnrCmoe
1PwAnj9tqhJ4W0yutxkzxj8j9idyfAUc
=8dCN
-----END PGP SIGNATURE-----
From antik at bsd.ee  Thu Jan  8 08:38:54 2009
From: antik at bsd.ee (Andrei Kolu)
Date: Thu Jan  8 08:39:02 2009
Subject: mergemaster broken -- take 2
In-Reply-To: <49657C0A.7040404@vintners.net>
References: <49657C0A.7040404@vintners.net>
Message-ID: <4965B4F1.8050707@bsd.ee>

Mike Lempriere wrote:
> Hi folks -- sorry to be a nag, but my main production system is barely 
> limping along on an old kernel with mismatched libraries.  I have no 
> idea what else to do -- please help!
> ---
> I'm upgrading 5-stable (was at 5.5) to 6-stable, in preparation for 
> 6-stable to 7-stable.
> No problems with cvsup, make buildworld, make installworld, make 
> buildkernel, mergemaster -p.
> make installkernel, boot to single user.  Then mergemaster -- blammo:
What is your exact make sequences are?

I usually do this way:

# csup /usr/share/examples/cvsup/standard-supfile
# cd /usr/src
here I usually softlink my kernel config file in /root directory to 
appropriate architecture one and edit /etc/make.conf:
---------------------------------------------------------------------------
SUP_UPDATE=yes
SUPHOST=cvsup.no.FreeBSD.org
SUPFILE=/usr/share/examples/cvsup/standard-supfile
PORTSSUPFILE=/usr/share/examples/cvsup/ports-supfile
DOCSUPFILE=/usr/share/examples/cvsup/doc-supfile
KERNCONF=KERNEL
---------------------------------------------------------------------------
/usr/src/sys/amd64/conf
KERNEL -> /root/kernel/KERNEL

# make buildkernel
# make installkernel
# make buildworld
# mergemaster -p
# make installworld
# mergemaster

NOTE: I do not reboot my system until everything is updated. Why it is 
necessary to boot new kernel and then upgrade world is beyound me..YMMW
From freebsd at byshenk.net  Thu Jan  8 09:22:02 2009
From: freebsd at byshenk.net (Greg Byshenk)
Date: Thu Jan  8 09:22:12 2009
Subject: mergemaster broken -- take 2
In-Reply-To: <4965B4F1.8050707@bsd.ee>
References: <49657C0A.7040404@vintners.net> <4965B4F1.8050707@bsd.ee>
Message-ID: <20090108085811.GB1580@core.byshenk.net>

On Thu, Jan 08, 2009 at 10:10:25AM +0200, Andrei Kolu wrote:
> Mike Lempriere wrote:

> >Hi folks -- sorry to be a nag, but my main production system is barely 
> >limping along on an old kernel with mismatched libraries.  I have no 
> >idea what else to do -- please help!
> >---
> >I'm upgrading 5-stable (was at 5.5) to 6-stable, in preparation for 
> >6-stable to 7-stable.
> >No problems with cvsup, make buildworld, make installworld, make 
> >buildkernel, mergemaster -p.
> >make installkernel, boot to single user.  Then mergemaster -- blammo:
> What is your exact make sequences are?
> 
> I usually do this way:
> 
> # csup /usr/share/examples/cvsup/standard-supfile
> # cd /usr/src
> here I usually softlink my kernel config file in /root directory to 
> appropriate architecture one and edit /etc/make.conf:
> ---------------------------------------------------------------------------
> SUP_UPDATE=yes
> SUPHOST=cvsup.no.FreeBSD.org
> SUPFILE=/usr/share/examples/cvsup/standard-supfile
> PORTSSUPFILE=/usr/share/examples/cvsup/ports-supfile
> DOCSUPFILE=/usr/share/examples/cvsup/doc-supfile
> KERNCONF=KERNEL
> ---------------------------------------------------------------------------
> /usr/src/sys/amd64/conf
> KERNEL -> /root/kernel/KERNEL
> 
> # make buildkernel
> # make installkernel
> # make buildworld
> # mergemaster -p
> # make installworld
> # mergemaster

It may be me that is mistaken, but this seems wrong to me, as does the
sequence in the original message:

   # cvsup
   # make buildworld
   # make installworld
   # make buildkernel
   # mergemaster -p.
   # make installkernel
   # boot to single user
   # mergemaster

If I am not very much mistaken, the "canonical" process is:

# make buildworld
# make buildkernel
# make installkernel
# reboot (*)
# mergemaster -p
# make installworld
# mergemaster

The reasons for the other methods being wrong are (as I understand them):

- You should build your new world before building your new kernel, as
  it may be the case that some aspects of the new kernel build are
  dependent upon aspects of the new world build.  If you build your
  new kernel before building your new world, you will be building 
  your new kernel against the old world.

- You should install your new kernel before installing your new world,
  as it can be the case that some aspects of the new world will not be
  understood by your old kernel. A new kernel should always be
  compatible with an old userland/world, but an old kernel may not 
  always be compatible with a new userland/world.

> NOTE: I do not reboot my system until everything is updated. Why it is 
> necessary to boot new kernel and then upgrade world is beyound me..YMMW

- I suppose that it is not strictly necessary to reboot between 
  installing kernel and world, but I always do so.  The reason for
  this is that, if something has gone horribly wrong, it is quite easy
  to go back and boot kernel.old. If you don't realize that there is
  something wrong until after you have installed everything (kernel and
  userland), it can be much more difficult to recover.


-- 
greg byshenk  -  gbyshenk@byshenk.net  -  Leiden, NL
From olli at lurza.secnetix.de  Thu Jan  8 10:26:54 2009
From: olli at lurza.secnetix.de (Oliver Fromme)
Date: Thu Jan  8 10:27:01 2009
Subject: NIC for VLAN
In-Reply-To: <5494.189.36.224.139.1231354907.squirrel@correio.americanadigital.com.br>
Message-ID: <200901081026.n08AQfnd099707@lurza.secnetix.de>

Edvaldo Silva wrote:
 > Please, can someone point a NIC, PCI 2.2 specs, full VLAN capable under
 > FreeBSD?

I'm using bge(4) and bce(4) interfaces (Broadcom GBit) and
fxp(4) ones (100 MBit) in enviroments with heavy use of VLANs.
They work very well.  There are no problems with the MTU.

Best regards
   Oliver

-- 
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606,  Gesch?ftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M?n-
chen, HRB 125758,  Gesch?ftsf?hrer: Maik Bachmann, Olaf Erb, Ralf Gebhart

FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd

"A language that doesn't have everything is actually easier
to program in than some that do."
        -- Dennis M. Ritchie
From spil.oss at googlemail.com  Thu Jan  8 10:29:42 2009
From: spil.oss at googlemail.com (Spil Oss)
Date: Thu Jan  8 10:29:49 2009
Subject: Problems with network in jail
Message-ID: <5fbf03c20901080207y4b0b18beod775a8ef2887f147@mail.gmail.com>

Hi all,

Is it mandatory to add device mem to jails to enable network via the gateway?

Left ezjail with FreeBSD-6.3 (and a hardware replacement of my server)
and am now starting again with FreeBSD-7.1.

Early this week, I upgraded from 7.0 to 7.1 (not having 'used' jails
on 7.0). After creating the jail with
  `ezjail-admin update -i`
I created a 'ports build' jail
  `ezjail-admin create build 127.0.0.3`
and forgot to add the alias to lo0, so no networking off-course. So I
added the 127.0.0.3 alias to lo0
   `ifconfig lo0 inet 127.0.0.3 alias`
and restarted the jail

Then I could get to the host machine, but not outside via the gateway.....
`netstat -nr` was returning errors
    netstat: kvm not available: /dev/mem: No such file or directory
    Routing tables
    rt_tables: symbol not in namelist
But I could use the dns on the host, but was restricted to the host.

After adding mem to the devfs_rules for my jail, I can see the routing
tables....
And with mem added to devfs, I can also connect via the gateway on the
host (NAT)

If it's required to add 'mem' to the devfs rules to enable networking
in the jail, it may be worth adding to the FAQ and/or the man-pages
for ezjail-admin and jail? (and perhaps add a devfsrules_netjail to
the default/devfs.rules)

Kind regards,

Spil.
From dieggo.rbo at gmail.com  Thu Jan  8 10:34:31 2009
From: dieggo.rbo at gmail.com (Diego Ribeiro)
Date: Thu Jan  8 10:34:39 2009
Subject: Error in make buildworld
In-Reply-To: <b41c75520901071647x34100a6k20a8dc960986e3da@mail.gmail.com>
References: <966852d10901070941u1f0b96efq98ede931a4586a9@mail.gmail.com>
	<b41c75520901071112q49afbce7ybb2b622568476ee8@mail.gmail.com>
	<966852d10901071157q43b2ff6ha5b9eb0df79b877c@mail.gmail.com>
	<b41c75520901071647x34100a6k20a8dc960986e3da@mail.gmail.com>
Message-ID: <966852d10901080234g206947d8je3a6a2c93437bdff@mail.gmail.com>

Realy my box is obsolet(Atlhon 2.0 - 512 Ram) I try without -j for discard
overheated.

tks again.

On Wed, Jan 7, 2009 at 10:47 PM, Claus Guttesen <kometen@gmail.com> wrote:

> > Hi Claus, thanks for return. I'm tried this steps below before send the
> > first email and not resolve my problem =/
>
> I notice you run a pre-release of 7.1. Did you update to the latest
> 7.1-release?
>
> > make cleandir && make cleandir
> > rm -rf /usr/obj/*
> > make -j6 buildworld
> >
> > but...the segmentation fault persist.
> > I have more logs of buidworld, if you want, I send  :D
> >
> > any idea? and thanks again.
>
> Could you try a buildworld without the -j parameter? If it still fails
> but in different stages of the buildworld it could be bad/overheated
> ram as mentioned by pluknet.
>
> --
> regards
> Claus
>
> When lenity and cruelty play for a kingdom,
> the gentler gamester is the soonest winner.
>
> Shakespeare
>



-- 
       dieggo.rbo at gmail dot com
       FreeBSD-BR User: #1047
       Linux User:  #395884
      www.linkedin.com/in/diegodias
       Limeira - SP -  [<o>]
From olli at lurza.secnetix.de  Thu Jan  8 10:47:48 2009
From: olli at lurza.secnetix.de (Oliver Fromme)
Date: Thu Jan  8 10:47:56 2009
Subject: mergemaster broken -- take 2
In-Reply-To: <20090108085811.GB1580@core.byshenk.net>
Message-ID: <200901081047.n08Alg2h000825@lurza.secnetix.de>

Greg Byshenk wrote:
 > Andrei Kolu wrote:
 > > Mike Lempriere wrote:
 > > > Hi folks -- sorry to be a nag, but my main production system is barely 
 > > > limping along on an old kernel with mismatched libraries.  I have no 
 > > > idea what else to do -- please help!
 > > > ---
 > > > I'm upgrading 5-stable (was at 5.5) to 6-stable, in preparation for 
 > > > 6-stable to 7-stable.
 > > > No problems with cvsup, make buildworld, make installworld, make 
 > > > buildkernel, mergemaster -p.
 > > > make installkernel, boot to single user.  Then mergemaster -- blammo:

As others have pointed out, the order is wrong, which caused
the problem Mike is seeing.

The correct order is listed in /usr/src/UPDATING.

 > The reasons for the other methods being wrong are (as I understand them):
 > 
 > - You should build your new world before building your new kernel, as
 >   it may be the case that some aspects of the new kernel build are
 >   dependent upon aspects of the new world build.  If you build your
 >   new kernel before building your new world, you will be building 
 >   your new kernel against the old world.

In particular, building the kernel uses the new toolchain
(i.e. compiler, linker, make(1) binary and so on) that was
built in /usr/obj during buildworld.  That's why you have
to do buildworld first, then "make kernel".

 > - You should install your new kernel before installing your new world,
 >   as it can be the case that some aspects of the new world will not be
 >   understood by your old kernel. A new kernel should always be
 >   compatible with an old userland/world, but an old kernel may not 
 >   always be compatible with a new userland/world.

That's correct.  Note that your kernel config should include
the appropriate "options COMPAT_*" lines if you update across
a major version boundary, e.g. "options_COMPAT_FREEBSD6" when
you update from 6.x to 7.x.  The GENERIC kernel already has
those.

 > > NOTE: I do not reboot my system until everything is updated. Why it is 
 > > necessary to boot new kernel and then upgrade world is beyound me..YMMW
 > 
 > - I suppose that it is not strictly necessary to reboot between 
 >   installing kernel and world, but I always do so.

It _is_ necessary.  If you don't reboot, you're still running
the old kernel which might not be able to support new binaries
and libraries that installworld will install on your system.

For example, there may be new syscalls that the new binaries
will try to use, but the old kernel doesn't know about them.
It doesn't happen often, so you can get away without rebooting
most of the time.  But it's risky, especially when updating
across major versions.  So the recommendation is to always
reboot after installing the new kernel and before performing
the "installworld".

It's also important that "installworld" is the last step
(except for mergemaster), because this is the point of no
return.  As long as you still have the old userland (world),
you can still boot the old kernel and everything is fine.
You can start all over froms cratch, if necessary.
But as soon as you have started "installworld", your system
will not be able to work with the old kernel anymore.

And remember:  Always make a backup before you start to
update.  And verify that the backup works.  Better safe
than sorry.

Best regards
   Oliver

-- 
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606,  Gesch?ftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M?n-
chen, HRB 125758,  Gesch?ftsf?hrer: Maik Bachmann, Olaf Erb, Ralf Gebhart

FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd

"... there are two ways of constructing a software design:  One way
is to make it so simple that there are _obviously_ no deficiencies and
the other way is to make it so complicated that there are no _obvious_
deficiencies."        -- C.A.R. Hoare, ACM Turing Award Lecture, 1980
From hawei at free.fr  Thu Jan  8 11:08:20 2009
From: hawei at free.fr (Harald Weis)
Date: Thu Jan  8 11:08:27 2009
Subject: Samsung SCX-4200 printer
In-Reply-To: <E1LJzNW-000OQZ-K4@daland.home>
References: <20090104221422.GA3114@pollux2.free.local.net>
	<20090105173635.575e32ff.torfinn.ingolfsen@broadpark.no>
	<20090105164403.GE3756@trusted-logic.com>
	<20090105222623.GA52838@slackbox.xs4all.nl>
	<20090105232354.GA85619@onelab2.iet.unipi.it>
	<E1LJzNW-000OQZ-K4@daland.home>
Message-ID: <20090108111127.GA1764@pollux2.free.local.net>

On Mon, Jan 05, 2009 at 07:01:02PM -0500, Alex Goncharov wrote:
> On Mon, Jan 05, 2009 at 11:26:23PM +0100, Roland Smith wrote:
> > On Mon, Jan 05, 2009 at 05:44:03PM +0100, Erwan David wrote:
> > > On Mon, Jan 05, 2009 at 05:36:35PM CET, Torfinn Ingolfsen <torfinn.ingolfsen@broadpark.no> said:
> > > > On Sun, 04 Jan 2009 23:14:22 +0100
> > > > Harald Weis <hawei@free.fr> wrote:
> > > > 
> > > > > Is there a way to install the SCX-4200 printer on a FreeBSD box ?
> > > > > The printer is delivered with the install software required for Linux.
> > > > > And CUPS does not seem to "know" it.
> > > It is not always sufficient. My Brother DCP-540 CN is said to work
> > > perfectly, but only with brother binary linux drivers, under linux. I
> > > did not find any way to make it work under freeBSD.
> > 
> > This should be a FAQ: do yourself a favor and get a printer that
> > supports postscript. It will work with little effort with most
> > UNIX-based program (because they usually support postscript output) and
> > with most spoolers.
> 
> Try to install the cupsys, cupsys-bsd, cupsomatic-ppd and foomatic-db

None of these exist in the FreeBSD port index (/usr/ports/INDEX-7)

> ports and take a look at this link:
> 
>    http://forums.linux-foundation.org/read.php?31,302,320,quote=1

Refers only to Linux :-(

Harald
-- 
FreeBSD 7.0-RELEASE FreeBSD 7.0-RELEASE #0: Sun Feb 24 19:59:52 UTC 2008
From spil.oss at googlemail.com  Thu Jan  8 11:10:09 2009
From: spil.oss at googlemail.com (Spil Oss)
Date: Thu Jan  8 11:10:20 2009
Subject: Problems with network in jail
In-Reply-To: <20090108105448.4cd6dcfe@dilbert.office.centralnic.com>
References: <5fbf03c20901080207y4b0b18beod775a8ef2887f147@mail.gmail.com>
	<20090108105448.4cd6dcfe@dilbert.office.centralnic.com>
Message-ID: <5fbf03c20901080310g69da867v1fc8dadcdb4ca7ae@mail.gmail.com>

Hi Peter,

Thanks a lot! Will read up on that. (luckily I do speak
german/swiss-german). From discussions on ##FreeBSD IRC I learned that
it is not recommended to use lo0 for jails!

On FreeBSD-6.3 I succesfully used lo0/127.0.0.2 for my mysql jail that
needed to be addressed only locally, but ONLY LOCALLY, no other
access. It may be possible to add a line similar to
     00100 divert 8668 ip from any to any in via xl0
to my ipfw/NAT config, but being warned, I'm not going down that path.

Since I moved my portbuild jail to bridge0/172.17.2.17 it works as
expected, without device mem!
And to boot I made errors when creating my aliases (ifconfig bridge0
inet 172.17.2.17 netmask *172.17.2.255* in stead of 255.255.255.0)

I will protect the jails that only need to be connected to from local
by adding rules to my ipfw setup

Now Iet's hope that my failures/problems serve as reference for future
users of (ez)jail!

Kind regards,

Spil.

2009/1/8 Oliver Peter <lists@peter.de.com>:
> On Thu, 8 Jan 2009 11:07:04 +0100
> "Spil Oss" <spil.oss@googlemail.com> wrote:
>
>> Early this week, I upgraded from 7.0 to 7.1 (not having 'used' jails
>> on 7.0). After creating the jail with
>>   `ezjail-admin update -i`
>> I created a 'ports build' jail
>>   `ezjail-admin create build 127.0.0.3`
>> and forgot to add the alias to lo0, so no networking off-course. So I
>> added the 127.0.0.3 alias to lo0
>>    `ifconfig lo0 inet 127.0.0.3 alias`
>> and restarted the jail
>
> If you use the loopback device for your jails you have to add NAT rules
> to your host machine, this documentation is very useful:
>
>        http://www.rootforum.de/wiki/freebsd/04_jail_infrastructure#packet_filter_einrichten
>
> (The article is in German, but the configuration stuff should be
> understandable anyway)
>
> --
> Oliver PETER, email: oliver@peter.de.com, ICQ# 113969174
> "If it feels good, you're doing something wrong."
>                                      -- Coach McTavish
>
>
From lists at peter.de.com  Thu Jan  8 11:14:32 2009
From: lists at peter.de.com (Oliver Peter)
Date: Thu Jan  8 11:14:40 2009
Subject: Problems with network in jail
In-Reply-To: <5fbf03c20901080207y4b0b18beod775a8ef2887f147@mail.gmail.com>
References: <5fbf03c20901080207y4b0b18beod775a8ef2887f147@mail.gmail.com>
Message-ID: <20090108105448.4cd6dcfe@dilbert.office.centralnic.com>

On Thu, 8 Jan 2009 11:07:04 +0100
"Spil Oss" <spil.oss@googlemail.com> wrote:

> Early this week, I upgraded from 7.0 to 7.1 (not having 'used' jails
> on 7.0). After creating the jail with
>   `ezjail-admin update -i`
> I created a 'ports build' jail
>   `ezjail-admin create build 127.0.0.3`
> and forgot to add the alias to lo0, so no networking off-course. So I
> added the 127.0.0.3 alias to lo0
>    `ifconfig lo0 inet 127.0.0.3 alias`
> and restarted the jail

If you use the loopback device for your jails you have to add NAT rules
to your host machine, this documentation is very useful:

	http://www.rootforum.de/wiki/freebsd/04_jail_infrastructure#packet_filter_einrichten

(The article is in German, but the configuration stuff should be
understandable anyway)

--
Oliver PETER, email: oliver@peter.de.com, ICQ# 113969174
"If it feels good, you're doing something wrong."
                                      -- Coach McTavish

From hk at alogis.com  Thu Jan  8 11:52:17 2009
From: hk at alogis.com (Holger Kipp)
Date: Thu Jan  8 11:52:24 2009
Subject: Samsung SCX-4200 printer
In-Reply-To: <20090108111127.GA1764@pollux2.free.local.net>
References: <20090104221422.GA3114@pollux2.free.local.net>
	<20090105173635.575e32ff.torfinn.ingolfsen@broadpark.no>
	<20090105164403.GE3756@trusted-logic.com>
	<20090105222623.GA52838@slackbox.xs4all.nl>
	<20090105232354.GA85619@onelab2.iet.unipi.it>
	<E1LJzNW-000OQZ-K4@daland.home>
	<20090108111127.GA1764@pollux2.free.local.net>
Message-ID: <20090108113948.GA18301@intserv.int1.b.intern>

On Thu, Jan 08, 2009 at 12:11:27PM +0100, Harald Weis wrote:
> On Mon, Jan 05, 2009 at 07:01:02PM -0500, Alex Goncharov wrote:
> > On Mon, Jan 05, 2009 at 11:26:23PM +0100, Roland Smith wrote:
> > > On Mon, Jan 05, 2009 at 05:44:03PM +0100, Erwan David wrote:
> > > > On Mon, Jan 05, 2009 at 05:36:35PM CET, Torfinn Ingolfsen <torfinn.ingolfsen@broadpark.no> said:
> > > > > On Sun, 04 Jan 2009 23:14:22 +0100
> > > > > Harald Weis <hawei@free.fr> wrote:
> > > > > 
> > > > > > Is there a way to install the SCX-4200 printer on a FreeBSD box ?
> > > > > > The printer is delivered with the install software required for Linux.
> > > > > > And CUPS does not seem to "know" it.
> > > > It is not always sufficient. My Brother DCP-540 CN is said to work
> > > > perfectly, but only with brother binary linux drivers, under linux. I
> > > > did not find any way to make it work under freeBSD.
> > > 
> > > This should be a FAQ: do yourself a favor and get a printer that
> > > supports postscript. It will work with little effort with most
> > > UNIX-based program (because they usually support postscript output) and
> > > with most spoolers.
> > 
> > Try to install the cupsys, cupsys-bsd, cupsomatic-ppd and foomatic-db
> 
> None of these exist in the FreeBSD port index (/usr/ports/INDEX-7)

foomatic-db => /usr/ports/print/foomatic-db

looking for cupsys on the internet will give results like
"cupsys" renamed to "cups" (at least for debian).

Best regards,
Holger
From jcw at highperformance.net  Thu Jan  8 13:14:45 2009
From: jcw at highperformance.net (Jason C. Wells)
Date: Thu Jan  8 13:14:53 2009
Subject: Version Number Only Changes
Message-ID: <4965FC41.4080901@highperformance.net>

I am sure there is a reason for it.  Upon running mergemaster this time 
through it seemed like there were _a lot_ of files where the only change 
was the version number.  I have run to mergemaster on four more hosts.  Ugh!

mergemaster -aiU still seems to require a ton of interaction.  Is there 
a better way?

Thanks,
Jason
From olli at lurza.secnetix.de  Thu Jan  8 13:30:42 2009
From: olli at lurza.secnetix.de (Oliver Fromme)
Date: Thu Jan  8 13:30:49 2009
Subject: Version Number Only Changes
In-Reply-To: <4965FC41.4080901@highperformance.net>
Message-ID: <200901081330.n08DUdY1008553@lurza.secnetix.de>

Jason C. Wells wrote:
 > I am sure there is a reason for it.  Upon running mergemaster this time 
 > through it seemed like there were _a lot_ of files where the only change 
 > was the version number.  I have run to mergemaster on four more hosts.  Ugh!
 > 
 > mergemaster -aiU still seems to require a ton of interaction.  Is there 
 > a better way?

I have the following in /etc/mergemaster.rc:

DIFF_FLAG='-Bub'
DIFF_OPTIONS='-I$FreeBSD:.*[$]'
IGNORE_MOTD=yes

Also, I'm not sure you really want to use the -a option.

Best regards
   Oliver

-- 
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606,  Gesch?ftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M?n-
chen, HRB 125758,  Gesch?ftsf?hrer: Maik Bachmann, Olaf Erb, Ralf Gebhart

FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd

"When your hammer is C++, everything begins to look like a thumb."
        -- Steve Haflich, in comp.lang.c++
From olli at lurza.secnetix.de  Thu Jan  8 13:53:23 2009
From: olli at lurza.secnetix.de (Oliver Fromme)
Date: Thu Jan  8 13:53:29 2009
Subject: Problems with network in jail
In-Reply-To: <5fbf03c20901080310g69da867v1fc8dadcdb4ca7ae@mail.gmail.com>
Message-ID: <200901081353.n08DrJUv009413@lurza.secnetix.de>

Spil Oss <spil.oss@googlemail.com> wrote:
 > Thanks a lot! Will read up on that. (luckily I do speak
 > german/swiss-german). From discussions on ##FreeBSD IRC I learned that
 > it is not recommended to use lo0 for jails!

Why would that be not recommended?

In fact I think it is a very good idea to use lo0 addresses
for jails, for security reasons, because they're guaranteed
to not leave your local system.  Therefore you have full
control of what the process within the jail can do.

If you want to grant specific network access to a jail
(incoming or outgoing, or both), you add appropriate "fwd"
rules to IPFW.

Best regards
   Oliver

-- 
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606,  Gesch?ftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M?n-
chen, HRB 125758,  Gesch?ftsf?hrer: Maik Bachmann, Olaf Erb, Ralf Gebhart

FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd

"That's what I love about GUIs: They make simple tasks easier,
and complex tasks impossible."
        -- John William Chambless
From uwe at laverenz.de  Thu Jan  8 14:01:40 2009
From: uwe at laverenz.de (Uwe Laverenz)
Date: Thu Jan  8 14:01:59 2009
Subject: Pending MFC of drm updates
In-Reply-To: <1231263380.57454.23.camel@squirrel.corp.cox.com>
References: <1231263380.57454.23.camel@squirrel.corp.cox.com>
Message-ID: <20090108134729.GA16512@laverenz.de>

On Tue, Jan 06, 2009 at 12:36:20PM -0500, Robert Noland wrote:

> I have a patch available for testing at
> http://people.freebsd.org/~rnoland/drm-update-7-010609.patch.bz2

I tested your patch on 2 different machines:

1) the infamous "ThinkPad T43p" ;) running i386:

Sorry, but RELENG_7_1 with your drm-update still shows a garbled
screen. The same userland with a -CURRENT kernel works without problems.


2) dual-Opteron 285/amd64 with a Radeon X1600 (RV530)

Works, but no direct rendering yet. I guess this would eventually work
with a newer xorg?! If it helps somehow I could test again with
xorg-7.4.

Thanks again for your work!

Uwe

From rnoland at FreeBSD.org  Thu Jan  8 14:04:08 2009
From: rnoland at FreeBSD.org (Robert Noland)
Date: Thu Jan  8 14:04:15 2009
Subject: Pending MFC of drm updates
In-Reply-To: <20090108134729.GA16512@laverenz.de>
References: <1231263380.57454.23.camel@squirrel.corp.cox.com>
	<20090108134729.GA16512@laverenz.de>
Message-ID: <1231423435.1810.6.camel@wombat.2hip.net>

On Thu, 2009-01-08 at 14:47 +0100, Uwe Laverenz wrote:
> On Tue, Jan 06, 2009 at 12:36:20PM -0500, Robert Noland wrote:
> 
> > I have a patch available for testing at
> > http://people.freebsd.org/~rnoland/drm-update-7-010609.patch.bz2
> 
> I tested your patch on 2 different machines:
> 
> 1) the infamous "ThinkPad T43p" ;) running i386:
> 
> Sorry, but RELENG_7_1 with your drm-update still shows a garbled
> screen. The same userland with a -CURRENT kernel works without problems.

Is this a pci based radeon as well?  If so, there is still a patch in
-CURRENT that isn't in this set yet.

> 
> 2) dual-Opteron 285/amd64 with a Radeon X1600 (RV530)
> 
> Works, but no direct rendering yet. I guess this would eventually work
> with a newer xorg?! If it helps somehow I could test again with
> xorg-7.4.

new xorg will hit ports soon, but a preliminary patch is available at
http://people.freebsd.org/~rnoland/xorg-7.4-111608.patch

robert.

> Thanks again for your work!
> 
> Uwe
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090108/faaddf73/attachment.pgp
From spry at anarchy.in.the.ph  Thu Jan  8 14:16:50 2009
From: spry at anarchy.in.the.ph (Mars G Miro)
Date: Thu Jan  8 14:16:57 2009
Subject: igb on a Nehalem system, buildworld stats
Message-ID: <f12f408a0901080616t78dded81l979a4ec06de7739f@mail.gmail.com>

Hi guys,

   I just got on my hands today a NEHALEM system:

2 x 5560 Nehalem CPU (2.8GHz, 8MB cache memory, 6.4GT/sec [QPI])
12GB 1333Mhz DDR3 Memory
1 x 500GB SATA HDD

  FreeBSD 7.1-RELEASE/amd64 install fine, however I seemed to be
having problems w/ its built-in Intel NICs:

igb0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=19b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4>
        ether 00:30:48:c5:db:e2
        inet6 fe80::230:48ff:fec5:dbe2%igb0 prefixlen 64 scopeid 0x1
        media: Ethernet autoselect (100baseTX <full-duplex>)
        status: active
igb1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=19b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4>
        ether 00:30:48:c5:db:e3
        inet6 fe80::230:48ff:fec5:dbe3%igb1 prefixlen 64 scopeid 0x2
        inet 172.17.32.32 netmask 0xffff0000 broadcast 172.17.255.255
        media: Ethernet autoselect (1000baseTX <full-duplex>)
        status: active

The first NIC would always want 100baseTX no matter how I'd ifconfig
down/up it, so I just had to use the 2nd NIC. Unfortunately, this too
is having problems. Like being unable to 'see' some machines on the
same network segment. Some other machines are accessible. And yes I've
double-checked the network stuff (cables, switch, IP settings) and my
conclusion is b0rky NICs.

pciconf -lvc:
igb0@pci0:1:0:0:        class=0x020000 card=0x10c915d9 chip=0x10c98086
rev=0x01 hdr=0x00
    vendor     = 'Intel Corporation'
    class      = network
    subclass   = ethernet
    cap 01[40] = powerspec 3  supports D0 D3  current D0
    cap 05[50] = MSI supports 1 message, 64 bit, vector masks
    cap 11[70] = MSI-X supports 10 messages in map 0x1c enabled
    cap 10[a0] = PCI-Express 2 endpoint
igb1@pci0:1:0:1:        class=0x020000 card=0x10c915d9 chip=0x10c98086
rev=0x01 hdr=0x00
    vendor     = 'Intel Corporation'
    class      = network
    subclass   = ethernet
    cap 01[40] = powerspec 3  supports D0 D3  current D0
    cap 05[50] = MSI supports 1 message, 64 bit, vector masks
    cap 11[70] = MSI-X supports 10 messages in map 0x1c enabled
    cap 10[a0] = PCI-Express 2 endpoint

So anyone else having igb problems? I'm downloading 200812-CURRENT now
(is tehre gonna be a 200901-CURRENT ISO soon? :-p), I'd like to try
that, but checking cvs seem only a handful of changes.

Also I did some buildworlds:
 make -j8 buildworld
    2846.900u 2266.188s 15:50.43 537.9%     6375+2082k 10084+7937io
1482pf+0w
 make -j16 buildworld
    3518.254u 2175.593s 14:23.29 659.5%     6656+2147k 26165+8546io 4300pf+0w
 make -j32 buildworld
    3582.897u 4437.710s 18:03.88 739.9%     6528+2125k 5725+7930io 1555pf+0w

Verbose dmesg: http://pastebin.com/f5f799561

Thanks!


-- 
cheers
mars
From uwe at laverenz.de  Thu Jan  8 14:29:22 2009
From: uwe at laverenz.de (Uwe Laverenz)
Date: Thu Jan  8 14:29:34 2009
Subject: Pending MFC of drm updates
In-Reply-To: <1231423435.1810.6.camel@wombat.2hip.net>
References: <1231263380.57454.23.camel@squirrel.corp.cox.com>
	<20090108134729.GA16512@laverenz.de>
	<1231423435.1810.6.camel@wombat.2hip.net>
Message-ID: <20090108142708.GC16512@laverenz.de>

On Thu, Jan 08, 2009 at 09:03:50AM -0500, Robert Noland wrote:

> > 1) the infamous "ThinkPad T43p" ;) running i386:
> > 
> > Sorry, but RELENG_7_1 with your drm-update still shows a garbled
> > screen. The same userland with a -CURRENT kernel works without problems.
> 
> Is this a pci based radeon as well?  If so, there is still a patch in
> -CURRENT that isn't in this set yet.

Yes, it's a PCIE card: "ATI FireGL M24 GL 3154 (PCIE)"

> new xorg will hit ports soon, but a preliminary patch is available at
> http://people.freebsd.org/~rnoland/xorg-7.4-111608.patch

Ok, I'll test it.

Uwe

From gary.jennejohn at freenet.de  Thu Jan  8 16:22:40 2009
From: gary.jennejohn at freenet.de (Gary Jennejohn)
Date: Thu Jan  8 16:22:52 2009
Subject: Pending MFC of drm updates
In-Reply-To: <20090108142708.GC16512@laverenz.de>
References: <1231263380.57454.23.camel@squirrel.corp.cox.com>
	<20090108134729.GA16512@laverenz.de>
	<1231423435.1810.6.camel@wombat.2hip.net>
	<20090108142708.GC16512@laverenz.de>
Message-ID: <20090108172236.6f944ddd@ernst.jennejohn.org>

On Thu, 8 Jan 2009 15:27:08 +0100
Uwe Laverenz <uwe@laverenz.de> wrote:

> On Thu, Jan 08, 2009 at 09:03:50AM -0500, Robert Noland wrote:
> 
> > > 1) the infamous "ThinkPad T43p" ;) running i386:
> > > 
> > > Sorry, but RELENG_7_1 with your drm-update still shows a garbled
> > > screen. The same userland with a -CURRENT kernel works without problems.
> > 
> > Is this a pci based radeon as well?  If so, there is still a patch in
> > -CURRENT that isn't in this set yet.
> 
> Yes, it's a PCIE card: "ATI FireGL M24 GL 3154 (PCIE)"
> 
> > new xorg will hit ports soon, but a preliminary patch is available at
> > http://people.freebsd.org/~rnoland/xorg-7.4-111608.patch
> 
> Ok, I'll test it.
> 

I have an RV6xx based system here - graphics in the chipset.  Can you,
Roland, say whether this patch will allow me to use DRM/DRI with it?
Right now it's not recognized.

---
Gary Jennejohn
From omerfsen at gmail.com  Thu Jan  8 16:30:26 2009
From: omerfsen at gmail.com (Omer Faruk Sen)
Date: Thu Jan  8 16:30:33 2009
Subject: kernel dump with 7.1-RELEASE
Message-ID: <75a268720901080805t3b85fa2bgf9b78abc1fb9a5c4@mail.gmail.com>

Hi,

I am having kernel dumps with FreeBSD 7.1

panic: semexit - semid not allocated
cpuid = 1
Uptime : 8m22s
Cannot dump. No dump device defined
Sleeping thread (tid 100129, pid 1479) owns a non-sleepable lock


I know it is not clear and there were no swap space configured on this
server (which I will re-install with swap space) but can someone
enlighten me about this since I think this bug was also in FreeBSD 6.2
and fixed in FreeBSD 6.3

Regards.
From rnoland at FreeBSD.org  Thu Jan  8 16:40:24 2009
From: rnoland at FreeBSD.org (Robert Noland)
Date: Thu Jan  8 16:40:40 2009
Subject: Pending MFC of drm updates
In-Reply-To: <20090108172236.6f944ddd@ernst.jennejohn.org>
References: <1231263380.57454.23.camel@squirrel.corp.cox.com>
	<20090108134729.GA16512@laverenz.de>
	<1231423435.1810.6.camel@wombat.2hip.net>
	<20090108142708.GC16512@laverenz.de>
	<20090108172236.6f944ddd@ernst.jennejohn.org>
Message-ID: <1231432814.93079.11.camel@squirrel.corp.cox.com>

On Thu, 2009-01-08 at 17:22 +0100, Gary Jennejohn wrote:
> On Thu, 8 Jan 2009 15:27:08 +0100
> Uwe Laverenz <uwe@laverenz.de> wrote:
> 
> > On Thu, Jan 08, 2009 at 09:03:50AM -0500, Robert Noland wrote:
> > 
> > > > 1) the infamous "ThinkPad T43p" ;) running i386:
> > > > 
> > > > Sorry, but RELENG_7_1 with your drm-update still shows a garbled
> > > > screen. The same userland with a -CURRENT kernel works without problems.
> > > 
> > > Is this a pci based radeon as well?  If so, there is still a patch in
> > > -CURRENT that isn't in this set yet.
> > 
> > Yes, it's a PCIE card: "ATI FireGL M24 GL 3154 (PCIE)"
> > 
> > > new xorg will hit ports soon, but a preliminary patch is available at
> > > http://people.freebsd.org/~rnoland/xorg-7.4-111608.patch
> > 
> > Ok, I'll test it.
> > 
> 
> I have an RV6xx based system here - graphics in the chipset.  Can you,
> Roland, say whether this patch will allow me to use DRM/DRI with it?
> Right now it's not recognized.

what is the pci id?  Probably not, I think that is an r600 chipset, but
AMD has released preliminary code, so it shouldn't be too much longer.

robert.

> ---
> Gary Jennejohn
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090108/6f03173e/attachment.pgp
From rnoland at FreeBSD.org  Thu Jan  8 16:48:42 2009
From: rnoland at FreeBSD.org (Robert Noland)
Date: Thu Jan  8 16:48:54 2009
Subject: Pending MFC of drm updates
In-Reply-To: <20090108172236.6f944ddd@ernst.jennejohn.org>
References: <1231263380.57454.23.camel@squirrel.corp.cox.com>
	<20090108134729.GA16512@laverenz.de>
	<1231423435.1810.6.camel@wombat.2hip.net>
	<20090108142708.GC16512@laverenz.de>
	<20090108172236.6f944ddd@ernst.jennejohn.org>
Message-ID: <1231433312.93079.17.camel@squirrel.corp.cox.com>

On Thu, 2009-01-08 at 17:22 +0100, Gary Jennejohn wrote:
> On Thu, 8 Jan 2009 15:27:08 +0100
> Uwe Laverenz <uwe@laverenz.de> wrote:
> 
> > On Thu, Jan 08, 2009 at 09:03:50AM -0500, Robert Noland wrote:
> > 
> > > > 1) the infamous "ThinkPad T43p" ;) running i386:
> > > > 
> > > > Sorry, but RELENG_7_1 with your drm-update still shows a garbled
> > > > screen. The same userland with a -CURRENT kernel works without problems.
> > > 
> > > Is this a pci based radeon as well?  If so, there is still a patch in
> > > -CURRENT that isn't in this set yet.
> > 
> > Yes, it's a PCIE card: "ATI FireGL M24 GL 3154 (PCIE)"
> > 
> > > new xorg will hit ports soon, but a preliminary patch is available at
> > > http://people.freebsd.org/~rnoland/xorg-7.4-111608.patch
> > 
> > Ok, I'll test it.
> > 
> 
> I have an RV6xx based system here - graphics in the chipset.  Can you,
> Roland, say whether this patch will allow me to use DRM/DRI with it?
> Right now it's not recognized.

It should however support the latest Intel chipsets, and R500 and below
AMD/ATI including the IGP chips (rs690 and rs485).  If you have the
garbled screen with pci based radeons, I have a patch for that also that
isn't part of this MFC yet.

The newer chips may also need the newer Xorg / Mesa bits, coming to a
ports collection near you very soon.

robert.

> ---
> Gary Jennejohn
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090108/ee399550/attachment.pgp
From korvus at comcast.net  Thu Jan  8 16:57:39 2009
From: korvus at comcast.net (Steve Polyack)
Date: Thu Jan  8 16:57:46 2009
Subject: Pending MFC of drm updates
In-Reply-To: <1231263380.57454.23.camel@squirrel.corp.cox.com>
References: <1231263380.57454.23.camel@squirrel.corp.cox.com>
Message-ID: <49663074.8040407@comcast.net>

Robert Noland wrote:
> I am planning to merge most all of the drm from -CURRENT to releng_7
> shortly.  The merge that I have staged includes the following.
>
> Merged /head/sys:r182080,182467-182469,182883-182884,183573,183603-183605,
> 	183828,183830-183834,184212-184213,184263,184373-184375
>
> There are really too many updates/fixes to mention as the drm from 7 is
> more than 2 years old now.  This has support for several newer Intel and
> AMD/ATI chips, (no r6/7xx yet, but soon(tm)).
>
> I have a patch available for testing at
> http://people.freebsd.org/~rnoland/drm-update-7-010609.patch.bz2
>
> robert.
>
>   
I've pulled this down and patched my install of FreeBSD 7.1-RELEASE.  
Whilst using a Radeon 9250 (R280?), I have no problems.  There is also 
no apparent performance difference.

The only issue I have seen occurs with my dual-monitor setup.  
Occasionally a window on the second monitor will decide to render its 
drop-down menus or other (overlay-based?) graphics on the primary 
monitor instead of where it should be.  Restarting the application seems 
to clear this up.  I have not seen this previously before applying your 
patch.
From rnoland at FreeBSD.org  Thu Jan  8 17:03:04 2009
From: rnoland at FreeBSD.org (Robert Noland)
Date: Thu Jan  8 17:03:17 2009
Subject: Pending MFC of drm updates
In-Reply-To: <49663074.8040407@comcast.net>
References: <1231263380.57454.23.camel@squirrel.corp.cox.com>
	<49663074.8040407@comcast.net>
Message-ID: <1231434170.93079.20.camel@squirrel.corp.cox.com>

On Thu, 2009-01-08 at 11:57 -0500, Steve Polyack wrote:
> Robert Noland wrote:
> > I am planning to merge most all of the drm from -CURRENT to releng_7
> > shortly.  The merge that I have staged includes the following.
> >
> > Merged /head/sys:r182080,182467-182469,182883-182884,183573,183603-183605,
> > 	183828,183830-183834,184212-184213,184263,184373-184375
> >
> > There are really too many updates/fixes to mention as the drm from 7 is
> > more than 2 years old now.  This has support for several newer Intel and
> > AMD/ATI chips, (no r6/7xx yet, but soon(tm)).
> >
> > I have a patch available for testing at
> > http://people.freebsd.org/~rnoland/drm-update-7-010609.patch.bz2
> >
> > robert.
> >
> >   
> I've pulled this down and patched my install of FreeBSD 7.1-RELEASE.  
> Whilst using a Radeon 9250 (R280?), I have no problems.  There is also 
> no apparent performance difference.
> 
> The only issue I have seen occurs with my dual-monitor setup.  
> Occasionally a window on the second monitor will decide to render its 
> drop-down menus or other (overlay-based?) graphics on the primary 
> monitor instead of where it should be.  Restarting the application seems 
> to clear this up.  I have not seen this previously before applying your 
> patch.

Hrm, I'm not sure how that could be related... You might try rebuilding
graphics/libdrm.  That sounds like an framebuffer offset issue.

robert.

> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090108/64e3503a/attachment.pgp
From 000.fbsd at quip.cz  Thu Jan  8 17:15:50 2009
From: 000.fbsd at quip.cz (Miroslav Lachman)
Date: Thu Jan  8 17:15:57 2009
Subject: Problems with network in jail
In-Reply-To: <5fbf03c20901080310g69da867v1fc8dadcdb4ca7ae@mail.gmail.com>
References: <5fbf03c20901080207y4b0b18beod775a8ef2887f147@mail.gmail.com>	<20090108105448.4cd6dcfe@dilbert.office.centralnic.com>
	<5fbf03c20901080310g69da867v1fc8dadcdb4ca7ae@mail.gmail.com>
Message-ID: <496630E9.1050600@quip.cz>

Spil Oss wrote:
> Hi Peter,
> 
> Thanks a lot! Will read up on that. (luckily I do speak
> german/swiss-german). From discussions on ##FreeBSD IRC I learned that
> it is not recommended to use lo0 for jails!
> 
> On FreeBSD-6.3 I succesfully used lo0/127.0.0.2 for my mysql jail that
> needed to be addressed only locally, but ONLY LOCALLY, no other
> access. It may be possible to add a line similar to
>      00100 divert 8668 ip from any to any in via xl0
> to my ipfw/NAT config, but being warned, I'm not going down that path.
> 
> Since I moved my portbuild jail to bridge0/172.17.2.17 it works as
> expected, without device mem!
> And to boot I made errors when creating my aliases (ifconfig bridge0
> inet 172.17.2.17 netmask *172.17.2.255* in stead of 255.255.255.0)

You can create lo1 if you want:
ifconfig create lo1
ifconfig lo1 inet 172.17.2.17 netmask 255.255.255.0

in rc.conf
cloned_interfaces="lo1"
ifconfig_lo1="inet 172.17.2.17 netmask 255.255.255.0"

And then use NAT / RDR in your favorite firewall (I am using PF)

Miroslav Lachman
From jfvogel at gmail.com  Thu Jan  8 17:16:47 2009
From: jfvogel at gmail.com (Jack Vogel)
Date: Thu Jan  8 17:16:55 2009
Subject: igb on a Nehalem system, buildworld stats
In-Reply-To: <f12f408a0901080616t78dded81l979a4ec06de7739f@mail.gmail.com>
References: <f12f408a0901080616t78dded81l979a4ec06de7739f@mail.gmail.com>
Message-ID: <2a41acea0901080844y1c2ad632t12aeadfbe9f34d0a@mail.gmail.com>

I have not seen a problem like this ever, what is the link partner
of each NIC and if you switch the ports what happens?

We have Nehalem's in the validation lab but I have not had an
excuse to install on one so far, I guess now I do :)

Jack

On Thu, Jan 8, 2009 at 6:16 AM, Mars G Miro <spry@anarchy.in.the.ph> wrote:

> Hi guys,
>
>   I just got on my hands today a NEHALEM system:
>
> 2 x 5560 Nehalem CPU (2.8GHz, 8MB cache memory, 6.4GT/sec [QPI])
> 12GB 1333Mhz DDR3 Memory
> 1 x 500GB SATA HDD
>
>  FreeBSD 7.1-RELEASE/amd64 install fine, however I seemed to be
> having problems w/ its built-in Intel NICs:
>
> igb0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
>        options=19b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4>
>        ether 00:30:48:c5:db:e2
>        inet6 fe80::230:48ff:fec5:dbe2%igb0 prefixlen 64 scopeid 0x1
>        media: Ethernet autoselect (100baseTX <full-duplex>)
>        status: active
> igb1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
>        options=19b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4>
>        ether 00:30:48:c5:db:e3
>        inet6 fe80::230:48ff:fec5:dbe3%igb1 prefixlen 64 scopeid 0x2
>        inet 172.17.32.32 netmask 0xffff0000 broadcast 172.17.255.255
>        media: Ethernet autoselect (1000baseTX <full-duplex>)
>        status: active
>
> The first NIC would always want 100baseTX no matter how I'd ifconfig
> down/up it, so I just had to use the 2nd NIC. Unfortunately, this too
> is having problems. Like being unable to 'see' some machines on the
> same network segment. Some other machines are accessible. And yes I've
> double-checked the network stuff (cables, switch, IP settings) and my
> conclusion is b0rky NICs.
>
> pciconf -lvc:
> igb0@pci0:1:0:0:        class=0x020000 card=0x10c915d9 chip=0x10c98086
> rev=0x01 hdr=0x00
>    vendor     = 'Intel Corporation'
>    class      = network
>    subclass   = ethernet
>    cap 01[40] = powerspec 3  supports D0 D3  current D0
>    cap 05[50] = MSI supports 1 message, 64 bit, vector masks
>    cap 11[70] = MSI-X supports 10 messages in map 0x1c enabled
>    cap 10[a0] = PCI-Express 2 endpoint
> igb1@pci0:1:0:1:        class=0x020000 card=0x10c915d9 chip=0x10c98086
> rev=0x01 hdr=0x00
>    vendor     = 'Intel Corporation'
>    class      = network
>    subclass   = ethernet
>    cap 01[40] = powerspec 3  supports D0 D3  current D0
>    cap 05[50] = MSI supports 1 message, 64 bit, vector masks
>    cap 11[70] = MSI-X supports 10 messages in map 0x1c enabled
>    cap 10[a0] = PCI-Express 2 endpoint
>
> So anyone else having igb problems? I'm downloading 200812-CURRENT now
> (is tehre gonna be a 200901-CURRENT ISO soon? :-p), I'd like to try
> that, but checking cvs seem only a handful of changes.
>
> Also I did some buildworlds:
>  make -j8 buildworld
>    2846.900u 2266.188s 15:50.43 537.9%     6375+2082k 10084+7937io
> 1482pf+0w
>  make -j16 buildworld
>    3518.254u 2175.593s 14:23.29 659.5%     6656+2147k 26165+8546io
> 4300pf+0w
>  make -j32 buildworld
>    3582.897u 4437.710s 18:03.88 739.9%     6528+2125k 5725+7930io 1555pf+0w
>
> Verbose dmesg: http://pastebin.com/f5f799561
>
> Thanks!
>
>
> --
> cheers
> mars
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
>
From alex-goncharov at comcast.net  Thu Jan  8 18:02:01 2009
From: alex-goncharov at comcast.net (Alex Goncharov)
Date: Thu Jan  8 18:02:08 2009
Subject: Samsung SCX-4200 printer
In-Reply-To: <20090108111127.GA1764@pollux2.free.local.net> (message from
	Harald Weis on Thu, 8 Jan 2009 12:11:27 +0100)
References: <20090104221422.GA3114@pollux2.free.local.net>
	<20090105173635.575e32ff.torfinn.ingolfsen@broadpark.no>
	<20090105164403.GE3756@trusted-logic.com>
	<20090105222623.GA52838@slackbox.xs4all.nl>
	<20090105232354.GA85619@onelab2.iet.unipi.it>
	<E1LJzNW-000OQZ-K4@daland.home>
	<20090108111127.GA1764@pollux2.free.local.net>
Message-ID: <E1LKzCf-0009XL-SZ@daland.home>

,--- You/Harald (Thu, 8 Jan 2009 12:11:27 +0100) ----*
| > Try to install the cupsys, cupsys-bsd, cupsomatic-ppd and foomatic-db
| > ports and take a look at this link:
| 
| None of these exist in the FreeBSD port index (/usr/ports/INDEX-7)

So, you've now looked :-)

I've had good experience with foomatic use for most various printers
in the past and wanted to give you a pointer to that package, no
promises, since you didn't seem to be familiar it.

I didn't have the printing packages installed in the machine I sent
the original mail from, so could not check the correct package names
-- I can check what I have now:

----------------------------------------
$ pkg_info -L foomatic-db-20070124_1| grep -ic samsung
62

$ pkg_info -L foomatic-db-20070124_1| grep -ic scx
0
----------------------------------------

So, that printer is not yet in BSD foomatic-db.

| >    http://forums.linux-foundation.org/read.php?31,302,320,quote=1
| 
| Refers only to Linux :-(

I know -- but I often used Linux-based advice as a clue for solving
printing problems on FreeBSD.

Sorry this didn't help you (and I am sure you saw this
http://www.openprinting.org/show_printer.cgi?recnum=Samsung-SCX-4200).

-- Alex -- alex-goncharov@comcast.net --
From spry at anarchy.in.the.ph  Thu Jan  8 18:19:58 2009
From: spry at anarchy.in.the.ph (Mars G Miro)
Date: Thu Jan  8 18:20:09 2009
Subject: igb on a Nehalem system, buildworld stats
In-Reply-To: <2a41acea0901080844y1c2ad632t12aeadfbe9f34d0a@mail.gmail.com>
References: <f12f408a0901080616t78dded81l979a4ec06de7739f@mail.gmail.com>
	<2a41acea0901080844y1c2ad632t12aeadfbe9f34d0a@mail.gmail.com>
Message-ID: <f12f408a0901081019x2ea4e83i47851fa3ed2a0ae4@mail.gmail.com>

On Fri, Jan 9, 2009 at 12:44 AM, Jack Vogel <jfvogel@gmail.com> wrote:
> I have not seen a problem like this ever, what is the link partner
> of each NIC and if you switch the ports what happens?
>

Hi Jack,

   They're connected to a GigE switch. It was just one w/ the first
NIC, but having seen that it only connects at 100baseTX, I wired the
2nd and saw that it can now do 1000baseTX. Unfortunately w/ problems
as it can 'see' some machines but unable to see others (in the same
physical network segment). I've changed cables, and plugged them in
different ports in the switch but still the same behavior.

  IIRC, this is the first time I had igb problems and only on this
box. I believe I encountered igb NICs in the newer HP DL380/385 but
those work fine.

  btw, this is a Supermicro Intel Engineering sample box (major
vendors don't have Nehalems in the market yet) so there prolly are
hardware/driver bugs lurking? I dunno.

  Thanks.


> We have Nehalem's in the validation lab but I have not had an
> excuse to install on one so far, I guess now I do :)
>
> Jack
>
> On Thu, Jan 8, 2009 at 6:16 AM, Mars G Miro <spry@anarchy.in.the.ph> wrote:
>>
>> Hi guys,
>>
>>   I just got on my hands today a NEHALEM system:
>>
>> 2 x 5560 Nehalem CPU (2.8GHz, 8MB cache memory, 6.4GT/sec [QPI])
>> 12GB 1333Mhz DDR3 Memory
>> 1 x 500GB SATA HDD
>>
>>  FreeBSD 7.1-RELEASE/amd64 install fine, however I seemed to be
>> having problems w/ its built-in Intel NICs:
>>
>> igb0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
>>        options=19b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4>
>>        ether 00:30:48:c5:db:e2
>>        inet6 fe80::230:48ff:fec5:dbe2%igb0 prefixlen 64 scopeid 0x1
>>        media: Ethernet autoselect (100baseTX <full-duplex>)
>>        status: active
>> igb1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
>>        options=19b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4>
>>        ether 00:30:48:c5:db:e3
>>        inet6 fe80::230:48ff:fec5:dbe3%igb1 prefixlen 64 scopeid 0x2
>>        inet 172.17.32.32 netmask 0xffff0000 broadcast 172.17.255.255
>>        media: Ethernet autoselect (1000baseTX <full-duplex>)
>>        status: active
>>
>> The first NIC would always want 100baseTX no matter how I'd ifconfig
>> down/up it, so I just had to use the 2nd NIC. Unfortunately, this too
>> is having problems. Like being unable to 'see' some machines on the
>> same network segment. Some other machines are accessible. And yes I've
>> double-checked the network stuff (cables, switch, IP settings) and my
>> conclusion is b0rky NICs.
>>
>> pciconf -lvc:
>> igb0@pci0:1:0:0:        class=0x020000 card=0x10c915d9 chip=0x10c98086
>> rev=0x01 hdr=0x00
>>    vendor     = 'Intel Corporation'
>>    class      = network
>>    subclass   = ethernet
>>    cap 01[40] = powerspec 3  supports D0 D3  current D0
>>    cap 05[50] = MSI supports 1 message, 64 bit, vector masks
>>    cap 11[70] = MSI-X supports 10 messages in map 0x1c enabled
>>    cap 10[a0] = PCI-Express 2 endpoint
>> igb1@pci0:1:0:1:        class=0x020000 card=0x10c915d9 chip=0x10c98086
>> rev=0x01 hdr=0x00
>>    vendor     = 'Intel Corporation'
>>    class      = network
>>    subclass   = ethernet
>>    cap 01[40] = powerspec 3  supports D0 D3  current D0
>>    cap 05[50] = MSI supports 1 message, 64 bit, vector masks
>>    cap 11[70] = MSI-X supports 10 messages in map 0x1c enabled
>>    cap 10[a0] = PCI-Express 2 endpoint
>>
>> So anyone else having igb problems? I'm downloading 200812-CURRENT now
>> (is tehre gonna be a 200901-CURRENT ISO soon? :-p), I'd like to try
>> that, but checking cvs seem only a handful of changes.
>>
>> Also I did some buildworlds:
>>  make -j8 buildworld
>>    2846.900u 2266.188s 15:50.43 537.9%     6375+2082k 10084+7937io
>> 1482pf+0w
>>  make -j16 buildworld
>>    3518.254u 2175.593s 14:23.29 659.5%     6656+2147k 26165+8546io
>> 4300pf+0w
>>  make -j32 buildworld
>>    3582.897u 4437.710s 18:03.88 739.9%     6528+2125k 5725+7930io
>> 1555pf+0w
>>
>> Verbose dmesg: http://pastebin.com/f5f799561
>>
>> Thanks!
>>
>>
>> --
>> cheers
>> mars
>> _______________________________________________
>> freebsd-stable@freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
>> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
>
>



-- 
cheers
mars
From hawei at free.fr  Thu Jan  8 18:45:28 2009
From: hawei at free.fr (Harald Weis)
Date: Thu Jan  8 18:45:39 2009
Subject: Samsung SCX-4200 printer
In-Reply-To: <E1LKzCf-0009XL-SZ@daland.home>
References: <20090104221422.GA3114@pollux2.free.local.net>
	<20090105173635.575e32ff.torfinn.ingolfsen@broadpark.no>
	<20090105164403.GE3756@trusted-logic.com>
	<20090105222623.GA52838@slackbox.xs4all.nl>
	<20090105232354.GA85619@onelab2.iet.unipi.it>
	<E1LJzNW-000OQZ-K4@daland.home>
	<20090108111127.GA1764@pollux2.free.local.net>
	<E1LKzCf-0009XL-SZ@daland.home>
Message-ID: <20090108184839.GB1764@pollux2.free.local.net>

On Thu, Jan 08, 2009 at 01:01:57PM -0500, Alex Goncharov wrote:
> ,--- You/Harald (Thu, 8 Jan 2009 12:11:27 +0100) ----*
> | > Try to install the cupsys, cupsys-bsd, cupsomatic-ppd and foomatic-db
> | > ports and take a look at this link:
> | 
> | None of these exist in the FreeBSD port index (/usr/ports/INDEX-7)
> 
> So, you've now looked :-)

Oh, yes, sorry, foomatic-db does indeed exist.

> 
> I've had good experience with foomatic use for most various printers
> in the past and wanted to give you a pointer to that package, no
> promises, since you didn't seem to be familiar it.
> 
> I didn't have the printing packages installed in the machine I sent
> the original mail from, so could not check the correct package names
> -- I can check what I have now:
> 
> ----------------------------------------
> $ pkg_info -L foomatic-db-20070124_1| grep -ic samsung
> 62
> 
> $ pkg_info -L foomatic-db-20070124_1| grep -ic scx
> 0
> ----------------------------------------
> 
> So, that printer is not yet in BSD foomatic-db.
> 
> | 
> | Refers only to Linux :-(
> 
> I know -- but I often used Linux-based advice as a clue for solving
> printing problems on FreeBSD.
> 
> Sorry this didn't help you (and I am sure you saw this
> http://www.openprinting.org/show_printer.cgi?recnum=Samsung-SCX-4200).

Yes, I did.

Harald
-- 
FreeBSD 7.0-RELEASE FreeBSD 7.0-RELEASE #0: Sun Feb 24 19:59:52 UTC 2008
From d2 at bsd.com.br  Thu Jan  8 18:49:40 2009
From: d2 at bsd.com.br (Diego Ribeiro)
Date: Thu Jan  8 18:49:47 2009
Subject: Error in make buildworld
In-Reply-To: <966852d10901080234g206947d8je3a6a2c93437bdff@mail.gmail.com>
References: <966852d10901070941u1f0b96efq98ede931a4586a9@mail.gmail.com>
	<b41c75520901071112q49afbce7ybb2b622568476ee8@mail.gmail.com>
	<966852d10901071157q43b2ff6ha5b9eb0df79b877c@mail.gmail.com>
	<b41c75520901071647x34100a6k20a8dc960986e3da@mail.gmail.com>
	<966852d10901080234g206947d8je3a6a2c93437bdff@mail.gmail.com>
Message-ID: <966852d10901081049p22382d13he4ff42149bc42615@mail.gmail.com>

Wow, I catch the problem.  My memory realy is broken the memtest warn me. =/

I take a new memory and try again.

[]'s

On Thu, Jan 8, 2009 at 8:34 AM, Diego Ribeiro <dieggo.rbo@gmail.com> wrote:

> Realy my box is obsolet(Atlhon 2.0 - 512 Ram) I try without -j for discard
> overheated.
>
> tks again.
>
>
> On Wed, Jan 7, 2009 at 10:47 PM, Claus Guttesen <kometen@gmail.com> wrote:
>
>> > Hi Claus, thanks for return. I'm tried this steps below before send the
>> > first email and not resolve my problem =/
>>
>> I notice you run a pre-release of 7.1. Did you update to the latest
>> 7.1-release?
>>
>> > make cleandir && make cleandir
>> > rm -rf /usr/obj/*
>> > make -j6 buildworld
>> >
>> > but...the segmentation fault persist.
>> > I have more logs of buidworld, if you want, I send  :D
>> >
>> > any idea? and thanks again.
>>
>> Could you try a buildworld without the -j parameter? If it still fails
>> but in different stages of the buildworld it could be bad/overheated
>> ram as mentioned by pluknet.
>>
>> --
>> regards
>> Claus
>>
>> When lenity and cruelty play for a kingdom,
>> the gentler gamester is the soonest winner.
>>
>> Shakespeare
>>
>
>
>
> --
>        dieggo.rbo at gmail dot com
>        FreeBSD-BR User: #1047
>        Linux User:  #395884
>       www.linkedin.com/in/diegodias
>        Limeira - SP -  [<o>]
>



-- 
       dieggo.rbo at gmail dot com
       FreeBSD-BR User: #1047
       Linux User:  #395884
      www.linkedin.com/in/diegodias
       Limeira - SP -  [<o>]
From spry at anarchy.in.the.ph  Thu Jan  8 18:50:47 2009
From: spry at anarchy.in.the.ph (Mars G Miro)
Date: Thu Jan  8 18:50:54 2009
Subject: igb on a Nehalem system, buildworld stats
In-Reply-To: <2a41acea0901081033h7db7a1aej8399baf5dcbd270f@mail.gmail.com>
References: <f12f408a0901080616t78dded81l979a4ec06de7739f@mail.gmail.com>
	<2a41acea0901080844y1c2ad632t12aeadfbe9f34d0a@mail.gmail.com>
	<f12f408a0901081019x2ea4e83i47851fa3ed2a0ae4@mail.gmail.com>
	<2a41acea0901081033h7db7a1aej8399baf5dcbd270f@mail.gmail.com>
Message-ID: <f12f408a0901081050p1a8154c5h19035f399944b3fc@mail.gmail.com>

On Fri, Jan 9, 2009 at 2:33 AM, Jack Vogel <jfvogel@gmail.com> wrote:
> Well, I am at Intel you know, and even we don't seem to have any systems
> with
> 82576 down in my group here. The way link works I can be about 99.9% sure
> in saying its not the driver. Its preproduction so there are lots of
> possibilities,
> and the biggest problem is its going to be difficult to help when I don't
> have any
> such hardware :(
>
> I've heard from the 1G product team that they have seen EEPROM mismatches
> on systems that will result in things not working in funny ways.


Jahh, I've seen those but not w/ Intel NICs. I believe it was from
Broadcom on some IBM x3455? (IIRC) and it was indeed quite amusing ;-)


>
> If you have a back to back connection to another NIC on Port 0, no switch,
> does
> it still autoneg to 100?
>

I will have do that tomorrow as I am @home now ;-)

btw, another data point, during sysinstall, we encountered:

  <unknown network interface type> on both the igbs.

Thanks.

> Jack
>
> On Thu, Jan 8, 2009 at 10:19 AM, Mars G Miro <spry@anarchy.in.the.ph> wrote:
>>
>> On Fri, Jan 9, 2009 at 12:44 AM, Jack Vogel <jfvogel@gmail.com> wrote:
>> > I have not seen a problem like this ever, what is the link partner
>> > of each NIC and if you switch the ports what happens?
>> >
>>
>> Hi Jack,
>>
>>   They're connected to a GigE switch. It was just one w/ the first
>> NIC, but having seen that it only connects at 100baseTX, I wired the
>> 2nd and saw that it can now do 1000baseTX. Unfortunately w/ problems
>> as it can 'see' some machines but unable to see others (in the same
>> physical network segment). I've changed cables, and plugged them in
>> different ports in the switch but still the same behavior.
>>
>>  IIRC, this is the first time I had igb problems and only on this
>> box. I believe I encountered igb NICs in the newer HP DL380/385 but
>> those work fine.
>>
>>  btw, this is a Supermicro Intel Engineering sample box (major
>> vendors don't have Nehalems in the market yet) so there prolly are
>> hardware/driver bugs lurking? I dunno.
>>
>>  Thanks.
>>
>>
>> > We have Nehalem's in the validation lab but I have not had an
>> > excuse to install on one so far, I guess now I do :)
>> >
>> > Jack
>> >
>> > On Thu, Jan 8, 2009 at 6:16 AM, Mars G Miro <spry@anarchy.in.the.ph>
>> > wrote:
>> >>
>> >> Hi guys,
>> >>
>> >>   I just got on my hands today a NEHALEM system:
>> >>
>> >> 2 x 5560 Nehalem CPU (2.8GHz, 8MB cache memory, 6.4GT/sec [QPI])
>> >> 12GB 1333Mhz DDR3 Memory
>> >> 1 x 500GB SATA HDD
>> >>
>> >>  FreeBSD 7.1-RELEASE/amd64 install fine, however I seemed to be
>> >> having problems w/ its built-in Intel NICs:
>> >>
>> >> igb0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu
>> >> 1500
>> >>
>> >>  options=19b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4>
>> >>        ether 00:30:48:c5:db:e2
>> >>        inet6 fe80::230:48ff:fec5:dbe2%igb0 prefixlen 64 scopeid 0x1
>> >>        media: Ethernet autoselect (100baseTX <full-duplex>)
>> >>        status: active
>> >> igb1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu
>> >> 1500
>> >>
>> >>  options=19b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4>
>> >>        ether 00:30:48:c5:db:e3
>> >>        inet6 fe80::230:48ff:fec5:dbe3%igb1 prefixlen 64 scopeid 0x2
>> >>        inet 172.17.32.32 netmask 0xffff0000 broadcast 172.17.255.255
>> >>        media: Ethernet autoselect (1000baseTX <full-duplex>)
>> >>        status: active
>> >>
>> >> The first NIC would always want 100baseTX no matter how I'd ifconfig
>> >> down/up it, so I just had to use the 2nd NIC. Unfortunately, this too
>> >> is having problems. Like being unable to 'see' some machines on the
>> >> same network segment. Some other machines are accessible. And yes I've
>> >> double-checked the network stuff (cables, switch, IP settings) and my
>> >> conclusion is b0rky NICs.
>> >>
>> >> pciconf -lvc:
>> >> igb0@pci0:1:0:0:        class=0x020000 card=0x10c915d9 chip=0x10c98086
>> >> rev=0x01 hdr=0x00
>> >>    vendor     = 'Intel Corporation'
>> >>    class      = network
>> >>    subclass   = ethernet
>> >>    cap 01[40] = powerspec 3  supports D0 D3  current D0
>> >>    cap 05[50] = MSI supports 1 message, 64 bit, vector masks
>> >>    cap 11[70] = MSI-X supports 10 messages in map 0x1c enabled
>> >>    cap 10[a0] = PCI-Express 2 endpoint
>> >> igb1@pci0:1:0:1:        class=0x020000 card=0x10c915d9 chip=0x10c98086
>> >> rev=0x01 hdr=0x00
>> >>    vendor     = 'Intel Corporation'
>> >>    class      = network
>> >>    subclass   = ethernet
>> >>    cap 01[40] = powerspec 3  supports D0 D3  current D0
>> >>    cap 05[50] = MSI supports 1 message, 64 bit, vector masks
>> >>    cap 11[70] = MSI-X supports 10 messages in map 0x1c enabled
>> >>    cap 10[a0] = PCI-Express 2 endpoint
>> >>
>> >> So anyone else having igb problems? I'm downloading 200812-CURRENT now
>> >> (is tehre gonna be a 200901-CURRENT ISO soon? :-p), I'd like to try
>> >> that, but checking cvs seem only a handful of changes.
>> >>
>> >> Also I did some buildworlds:
>> >>  make -j8 buildworld
>> >>    2846.900u 2266.188s 15:50.43 537.9%     6375+2082k 10084+7937io
>> >> 1482pf+0w
>> >>  make -j16 buildworld
>> >>    3518.254u 2175.593s 14:23.29 659.5%     6656+2147k 26165+8546io
>> >> 4300pf+0w
>> >>  make -j32 buildworld
>> >>    3582.897u 4437.710s 18:03.88 739.9%     6528+2125k 5725+7930io
>> >> 1555pf+0w
>> >>
>> >> Verbose dmesg: http://pastebin.com/f5f799561
>> >>
>> >> Thanks!
>> >>
>> >>
>> >> --
>> >> cheers
>> >> mars
>> >> _______________________________________________
>> >> freebsd-stable@freebsd.org mailing list
>> >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
>> >> To unsubscribe, send any mail to
>> >> "freebsd-stable-unsubscribe@freebsd.org"
>> >
>> >
>>
>>
>>
>> --
>> cheers
>> mars
>
>



-- 
cheers
mars
From hawei at free.fr  Thu Jan  8 18:52:31 2009
From: hawei at free.fr (Harald Weis)
Date: Thu Jan  8 18:52:37 2009
Subject: Samsung SCX-4200 printer
In-Reply-To: <20090108130642.GA27129@crete.org.ua>
References: <20090104221422.GA3114@pollux2.free.local.net>
	<20090108130642.GA27129@crete.org.ua>
Message-ID: <20090108185540.GC1764@pollux2.free.local.net>

On Thu, Jan 08, 2009 at 03:06:42PM +0200, Alexander Shikoff wrote:
> On Sun, Jan 04, 2009 at 11:14:22PM +0100, Harald Weis wrote:
> > Is there a way to install the SCX-4200 printer on a FreeBSD box ?
> > The printer is delivered with the install software required for Linux.
> > And CUPS does not seem to "know" it.
> > 
> > Thank you in advance for any help.
> 
> I've successfully setup printing on SCX-4521F connected to MS Windows box.
> I use Linux binary driver from Samsung website. On my FreeBSD box (7.1-PRERELEASE)
> I use cups and samba-client.
> 
> Unfortunately I have detailed description of all steps in Russian only.
> 
> But I'll try to give you a the short summary. I hope it will let you
> find right way:
> 

snip

> 
> That's all. If you have any issues/question feel free to ask. Have a nice day!
> 

Thank you very much. I'll report as soon as possible.

Harald
-- 
FreeBSD 7.0-RELEASE FreeBSD 7.0-RELEASE #0: Sun Feb 24 19:59:52 UTC 2008
From jfvogel at gmail.com  Thu Jan  8 19:06:18 2009
From: jfvogel at gmail.com (Jack Vogel)
Date: Thu Jan  8 19:06:25 2009
Subject: igb on a Nehalem system, buildworld stats
In-Reply-To: <f12f408a0901081050p1a8154c5h19035f399944b3fc@mail.gmail.com>
References: <f12f408a0901080616t78dded81l979a4ec06de7739f@mail.gmail.com>
	<2a41acea0901080844y1c2ad632t12aeadfbe9f34d0a@mail.gmail.com>
	<f12f408a0901081019x2ea4e83i47851fa3ed2a0ae4@mail.gmail.com>
	<2a41acea0901081033h7db7a1aej8399baf5dcbd270f@mail.gmail.com>
	<f12f408a0901081050p1a8154c5h19035f399944b3fc@mail.gmail.com>
Message-ID: <2a41acea0901081106k5dbaeef8s788d2460820c75cd@mail.gmail.com>

So it wasn't identified during install but was in the kernel you built
afterward, is that
what you're saying? Even if that's true I don't think its relevant to the
failure.

I have made a couple queries internally, there are a lot of variations on
Nehalem
systems, at least one other engineer in my group had an encounter with one
like yours, I have two managers looking for me, hopefully I can find one.

Jack


On Thu, Jan 8, 2009 at 10:50 AM, Mars G Miro <spry@anarchy.in.the.ph> wrote:

> On Fri, Jan 9, 2009 at 2:33 AM, Jack Vogel <jfvogel@gmail.com> wrote:
> > Well, I am at Intel you know, and even we don't seem to have any systems
> > with
> > 82576 down in my group here. The way link works I can be about 99.9% sure
> > in saying its not the driver. Its preproduction so there are lots of
> > possibilities,
> > and the biggest problem is its going to be difficult to help when I don't
> > have any
> > such hardware :(
> >
> > I've heard from the 1G product team that they have seen EEPROM mismatches
> > on systems that will result in things not working in funny ways.
>
>
> Jahh, I've seen those but not w/ Intel NICs. I believe it was from
> Broadcom on some IBM x3455? (IIRC) and it was indeed quite amusing ;-)
>
>
> >
> > If you have a back to back connection to another NIC on Port 0, no
> switch,
> > does
> > it still autoneg to 100?
> >
>
> I will have do that tomorrow as I am @home now ;-)
>
> btw, another data point, during sysinstall, we encountered:
>
>  <unknown network interface type> on both the igbs.
>
> Thanks.
>
> > Jack
> >
> > On Thu, Jan 8, 2009 at 10:19 AM, Mars G Miro <spry@anarchy.in.the.ph>
> wrote:
> >>
> >> On Fri, Jan 9, 2009 at 12:44 AM, Jack Vogel <jfvogel@gmail.com> wrote:
> >> > I have not seen a problem like this ever, what is the link partner
> >> > of each NIC and if you switch the ports what happens?
> >> >
> >>
> >> Hi Jack,
> >>
> >>   They're connected to a GigE switch. It was just one w/ the first
> >> NIC, but having seen that it only connects at 100baseTX, I wired the
> >> 2nd and saw that it can now do 1000baseTX. Unfortunately w/ problems
> >> as it can 'see' some machines but unable to see others (in the same
> >> physical network segment). I've changed cables, and plugged them in
> >> different ports in the switch but still the same behavior.
> >>
> >>  IIRC, this is the first time I had igb problems and only on this
> >> box. I believe I encountered igb NICs in the newer HP DL380/385 but
> >> those work fine.
> >>
> >>  btw, this is a Supermicro Intel Engineering sample box (major
> >> vendors don't have Nehalems in the market yet) so there prolly are
> >> hardware/driver bugs lurking? I dunno.
> >>
> >>  Thanks.
> >>
> >>
> >> > We have Nehalem's in the validation lab but I have not had an
> >> > excuse to install on one so far, I guess now I do :)
> >> >
> >> > Jack
> >> >
> >> > On Thu, Jan 8, 2009 at 6:16 AM, Mars G Miro <spry@anarchy.in.the.ph>
> >> > wrote:
> >> >>
> >> >> Hi guys,
> >> >>
> >> >>   I just got on my hands today a NEHALEM system:
> >> >>
> >> >> 2 x 5560 Nehalem CPU (2.8GHz, 8MB cache memory, 6.4GT/sec [QPI])
> >> >> 12GB 1333Mhz DDR3 Memory
> >> >> 1 x 500GB SATA HDD
> >> >>
> >> >>  FreeBSD 7.1-RELEASE/amd64 install fine, however I seemed to be
> >> >> having problems w/ its built-in Intel NICs:
> >> >>
> >> >> igb0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu
> >> >> 1500
> >> >>
> >> >>  options=19b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4>
> >> >>        ether 00:30:48:c5:db:e2
> >> >>        inet6 fe80::230:48ff:fec5:dbe2%igb0 prefixlen 64 scopeid 0x1
> >> >>        media: Ethernet autoselect (100baseTX <full-duplex>)
> >> >>        status: active
> >> >> igb1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu
> >> >> 1500
> >> >>
> >> >>  options=19b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4>
> >> >>        ether 00:30:48:c5:db:e3
> >> >>        inet6 fe80::230:48ff:fec5:dbe3%igb1 prefixlen 64 scopeid 0x2
> >> >>        inet 172.17.32.32 netmask 0xffff0000 broadcast 172.17.255.255
> >> >>        media: Ethernet autoselect (1000baseTX <full-duplex>)
> >> >>        status: active
> >> >>
> >> >> The first NIC would always want 100baseTX no matter how I'd ifconfig
> >> >> down/up it, so I just had to use the 2nd NIC. Unfortunately, this too
> >> >> is having problems. Like being unable to 'see' some machines on the
> >> >> same network segment. Some other machines are accessible. And yes
> I've
> >> >> double-checked the network stuff (cables, switch, IP settings) and my
> >> >> conclusion is b0rky NICs.
> >> >>
> >> >> pciconf -lvc:
> >> >> igb0@pci0:1:0:0:        class=0x020000 card=0x10c915d9
> chip=0x10c98086
> >> >> rev=0x01 hdr=0x00
> >> >>    vendor     = 'Intel Corporation'
> >> >>    class      = network
> >> >>    subclass   = ethernet
> >> >>    cap 01[40] = powerspec 3  supports D0 D3  current D0
> >> >>    cap 05[50] = MSI supports 1 message, 64 bit, vector masks
> >> >>    cap 11[70] = MSI-X supports 10 messages in map 0x1c enabled
> >> >>    cap 10[a0] = PCI-Express 2 endpoint
> >> >> igb1@pci0:1:0:1:        class=0x020000 card=0x10c915d9
> chip=0x10c98086
> >> >> rev=0x01 hdr=0x00
> >> >>    vendor     = 'Intel Corporation'
> >> >>    class      = network
> >> >>    subclass   = ethernet
> >> >>    cap 01[40] = powerspec 3  supports D0 D3  current D0
> >> >>    cap 05[50] = MSI supports 1 message, 64 bit, vector masks
> >> >>    cap 11[70] = MSI-X supports 10 messages in map 0x1c enabled
> >> >>    cap 10[a0] = PCI-Express 2 endpoint
> >> >>
> >> >> So anyone else having igb problems? I'm downloading 200812-CURRENT
> now
> >> >> (is tehre gonna be a 200901-CURRENT ISO soon? :-p), I'd like to try
> >> >> that, but checking cvs seem only a handful of changes.
> >> >>
> >> >> Also I did some buildworlds:
> >> >>  make -j8 buildworld
> >> >>    2846.900u 2266.188s 15:50.43 537.9%     6375+2082k 10084+7937io
> >> >> 1482pf+0w
> >> >>  make -j16 buildworld
> >> >>    3518.254u 2175.593s 14:23.29 659.5%     6656+2147k 26165+8546io
> >> >> 4300pf+0w
> >> >>  make -j32 buildworld
> >> >>    3582.897u 4437.710s 18:03.88 739.9%     6528+2125k 5725+7930io
> >> >> 1555pf+0w
> >> >>
> >> >> Verbose dmesg: http://pastebin.com/f5f799561
> >> >>
> >> >> Thanks!
> >> >>
> >> >>
> >> >> --
> >> >> cheers
> >> >> mars
> >> >> _______________________________________________
> >> >> freebsd-stable@freebsd.org mailing list
> >> >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> >> >> To unsubscribe, send any mail to
> >> >> "freebsd-stable-unsubscribe@freebsd.org"
> >> >
> >> >
> >>
> >>
> >>
> >> --
> >> cheers
> >> mars
> >
> >
>
>
>
> --
> cheers
> mars
>
From spry at anarchy.in.the.ph  Thu Jan  8 19:16:18 2009
From: spry at anarchy.in.the.ph (Mars G Miro)
Date: Thu Jan  8 19:16:24 2009
Subject: igb on a Nehalem system, buildworld stats
In-Reply-To: <2a41acea0901081106k5dbaeef8s788d2460820c75cd@mail.gmail.com>
References: <f12f408a0901080616t78dded81l979a4ec06de7739f@mail.gmail.com>
	<2a41acea0901080844y1c2ad632t12aeadfbe9f34d0a@mail.gmail.com>
	<f12f408a0901081019x2ea4e83i47851fa3ed2a0ae4@mail.gmail.com>
	<2a41acea0901081033h7db7a1aej8399baf5dcbd270f@mail.gmail.com>
	<f12f408a0901081050p1a8154c5h19035f399944b3fc@mail.gmail.com>
	<2a41acea0901081106k5dbaeef8s788d2460820c75cd@mail.gmail.com>
Message-ID: <f12f408a0901081116v666ef917x75fb898e1edcb13f@mail.gmail.com>

On Fri, Jan 9, 2009 at 3:06 AM, Jack Vogel <jfvogel@gmail.com> wrote:
> So it wasn't identified during install but was in the kernel you built
> afterward, is that
> what you're saying? Even if that's true I don't think its relevant to the
> failure.
>

Ahm no, sysinstall said something like:

 igb0: <unknown network interface type>
 igb1: <unknown network interface type>

but we just went ahead and made the choice.

I thought it might be a slight variation of igb NICs or something so I
stated that info.

> I have made a couple queries internally, there are a lot of variations on
> Nehalem
> systems, at least one other engineer in my group had an encounter with one
> like yours, I have two managers looking for me, hopefully I can find one.
>

Ok cool.

Matsalams (means much thanks!) ;-)

> Jack
>
>
[snip]


-- 
cheers
mars
From torfinn.ingolfsen at broadpark.no  Thu Jan  8 19:43:16 2009
From: torfinn.ingolfsen at broadpark.no (Torfinn Ingolfsen)
Date: Thu Jan  8 19:43:24 2009
Subject: ACPI support?
In-Reply-To: <49633C85.3090507@bulinfo.net>
References: <49633C85.3090507@bulinfo.net>
Message-ID: <20090108204311.c9700e91.torfinn.ingolfsen@broadpark.no>

On Tue, 06 Jan 2009 13:12:05 +0200
Krassimir Slavchev <krassi@bulinfo.net> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hello All,
> 
> I have had a problem detecting the network card on my notebook when
> ACPI is enabled for a year. The problem still exists in 7.1-RELEASE.

Which make and model notebook is this?

You have my sympaties, my own laptop[1] (Acer Aspire 5672) have the same
sort of problem - drivers for NICs (both wired and wireless) will not
attach if acpi is enabled. And this laptop gets too hot when acpi is
disabled - I fear it will overheat. Linux runs fine[2] on it.

I had a lot of help in trying to fix the problem a wbile back (check
the freebsd-mobile mailing list archives), but in the end, nothing
helped.

 I can only offer general advice, not a solution. Try too look for
a modfified DSDT for your notebook, perhpas you will find something
that helps.

References:
1) http://tingox.googlepages.com/aceraspireas5672andfreebsd
2) http://tingox.googlepages.com/as5672_xubuntu
-- 
Regards,
Torfinn Ingolfsen,
Norway

From Manfred.Knick at T-Online.de  Thu Jan  8 19:45:02 2009
From: Manfred.Knick at T-Online.de (Manfred_Knick)
Date: Thu Jan  8 19:45:10 2009
Subject: possibility of a "severe flaw in the logic of FreeBSD's kernel
 handling multiple host bridges ..."
Message-ID: <496651ED.8080102@T-Online.de>

First: Congratulations upon 7.1 final RELEASE !

On Fri, 24 Oct 2008, I pointed out the

    "possibility of a severe flaw in the logic of FreeBSD's kernel
     handling multiple host bridges
     and the corresponding assignment of
     (in principle, correctly detected)
     devices to their host bridges"

:: -->   http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/128331

:: -->   http://forums.freebsd.org/showthread.php?t=236

but unfortunately, I did not get any response at all.
Two mails to "kensmith@cse.Buffalo.EDU" asking for any contact e-mail 
address of a FreeBSD Kernel developer knowing his way around 
host-bridges and PCI-devices also gave no reaction.

I am sorry for this noise
(I would have preferred to handle this more quietly),
but finally I take hope to the advice of Daniel Gerzo (Thanks @ danger):

"If you will not receive any feedback I would recommend you to send an
email to current@ and stable@ mailing lists. PR's sometimes get lost
in the traffic and not all developers are checking GNATS all the time."

Looking forward to a contact

Kind regards

Manfred
From cperciva at freebsd.org  Thu Jan  8 20:20:37 2009
From: cperciva at freebsd.org (Colin Percival)
Date: Thu Jan  8 20:20:44 2009
Subject: FreeBSD Update should be back to normal
Message-ID: <49665FEF.6030808@freebsd.org>

Hi all,

There are now more freebsd-update mirrors and it looks like they're handling the
load quite well.

It's possible that the load balancing between mirrors will need to be tweaked a
bit.  If you have problems accessing a mirror (e.g., if freebsd-update exits
with an error of "downloading files... failed" or complains that a file does not
exist) please:
1. Try again using the -s option to make sure that you're accessing the same
mirror (to make sure that this wasn't a temporary network glitch).
2. Assuming the first mirror still fails, use the -s option to pick a different
mirror.
3. Assuming that the second mirror works, send me an email telling me which
mirror failed and which one worked so that I can have the load balancing adjusted.

-- 
Colin Percival
Security Officer, FreeBSD | freebsd.org | The power to serve
Founder / author, Tarsnap | tarsnap.com | Online backups for the truly paranoid
From freebsd at byshenk.net  Thu Jan  8 20:24:34 2009
From: freebsd at byshenk.net (Greg Byshenk)
Date: Thu Jan  8 20:24:42 2009
Subject: mergemaster broken -- take 2
In-Reply-To: <200901081047.n08Alg2h000825@lurza.secnetix.de>
References: <20090108085811.GB1580@core.byshenk.net>
	<200901081047.n08Alg2h000825@lurza.secnetix.de>
Message-ID: <20090108202430.GA46733@core.byshenk.net>

On Thu, Jan 08, 2009 at 11:47:42AM +0100, Oliver Fromme wrote:
> Greg Byshenk wrote:
>  > Andrei Kolu wrote:
 
>  > > NOTE: I do not reboot my system until everything is updated. Why it is 
>  > > necessary to boot new kernel and then upgrade world is beyound me..YMMW
>  > 
>  > - I suppose that it is not strictly necessary to reboot between 
>  >   installing kernel and world, but I always do so.
 
> It _is_ necessary.  If you don't reboot, you're still running
> the old kernel which might not be able to support new binaries
> and libraries that installworld will install on your system.

Of course this is correct; my error.

The chance of something going wrong in this case is probably quite
small, but it something does go wrong it can go horribly wrong.
 

-- 
greg byshenk  -  gbyshenk@byshenk.net  -  Leiden, NL
From sam at errno.com  Thu Jan  8 20:44:59 2009
From: sam at errno.com (Sam Leffler)
Date: Thu Jan  8 20:45:07 2009
Subject: CFT: ath hal src switchover
Message-ID: <49665E35.1050301@errno.com>

I've brought the hal source code back to RELENG_7 but not connected it 
to the build and/or driver.  I want folks to test this before I commit 
those changes.  To do this you must have an up to date RELENG_7 code 
base and then apply this patch:

http://people.freebsd.org/~sam/ath_hal-releng7.patch

Then rebuild your kernel.  There should be no changes to user apps.  
Beware however that custom kernel configurations will need to change; 
instead of:

device ath
device ath_hal
device ath_rate_sample

(or similar) you need:

device ath
device ath_hal
options AH_SUPPORT_AR5416
device ath_rate_sample

If you want to configure a subset of the chip support implied by ath_hal 
then you may not need the options line.

If you are using modules note that ath_hal and ath_rate_* modules no 
longer exist; they are now rolled into the ath module.  If you use a 
rate control algorithm other than sample then you'll need to modify the 
ath module build or override by specifying ATH_RATE; e.g.

cd sys/modules/ath
make ATH_RATE=onoe

The updated hal code adds support for several parts but otherwise makes 
no effort to address driver bugs.  You should see no regressions 
relative to operation w/ the older hal.

If you are running the 7.1 release you will need to import the hal code 
that is now in

sys/dev/ath/ath_hal

before following the above instructions.  I have no idea if this will 
work for an earlier version of FreeBSD; if you're not running at least 
7.1 my advise is to upgrade.

Please report any issues to this mailing list.

    Sam

From rsmith at xs4all.nl  Thu Jan  8 21:26:13 2009
From: rsmith at xs4all.nl (Roland Smith)
Date: Thu Jan  8 21:26:23 2009
Subject: Pending MFC of drm updates
In-Reply-To: <1231263380.57454.23.camel@squirrel.corp.cox.com>
References: <1231263380.57454.23.camel@squirrel.corp.cox.com>
Message-ID: <20090108212610.GA2177@slackbox.xs4all.nl>

On Tue, Jan 06, 2009 at 12:36:20PM -0500, Robert Noland wrote:
> I have a patch available for testing at
> http://people.freebsd.org/~rnoland/drm-update-7-010609.patch.bz2

Excellent! Thanks for your hard work on this, Robert! 

After updating my source to 7.1-RELEASE, I applied this patch and built
and installed a new kernel and world. This went without problems.

Starting X on a Sapphire Radeon X1650Pro works OK. XAA 2D accelleration
works OK. The X logfile says that direct rendering is enabled, as is
Xv. Mplayer works with Xv.

But whenever I try to start a program that uses OpenGL (i.e. glxgears) I
get the following message:

unknown chip id 0x71c1, can't guess.
libGL warning: 3D driver returned no fbconfigs.
libGL error: InitDriver failed
libGL error: reverting to (slow) indirect rendering

:-(

The same number shows in Xorg.0.log:

<snip>
(--) PCI:*(1:0:0) ATI Technologies Inc unknown chipset (0x71c1) rev 158, Mem @ 0xe0000000/28, 0xfe9e0000/16, I/O @ 0xd000/8, BIOS @ 0xfe9c0000/17
<snip>
(II) Loading extension XFree86-DGA
<snip>
(--) Chipset RV535 found
<snip>
(II) RADEONHD(0): Unknown card detected: 0x71C1:0x174B:0x0880.
        If - and only if - your card does not work or does not work optimally
        please contact radeonhd@opensuse.org to help rectify this.
        Use the subject: 0x71C1:0x174B:0x0880: <name of board>
        and *please* describe the problems you are seeing
        in your message.
(--) RADEONHD(0): Detected an RV535 on an unidentified card
(==) RADEONHD(0): Write-combining range (0xfe9e0000,0x10000) was already clear
(II) RADEONHD(0): Mapped IO @ 0xfe9e0000 to 0x8006a2000 (size 0x00010000)
(II) RADEONHD(0): PCIE Card Detected
(II) RADEONHD(0): Getting BIOS copy from legacy VBIOS location
(II) RADEONHD(0): ATOM BIOS Rom: 
        SubsystemVendorID: 0x174b SubsystemID: 0x0880
        IOBaseAddress: 0xd000
        Filename: 8C88GCSA.003
        BIOS Bootup Message: 
A67120 RV535XT VO BIOS GDDR3 600E/700M                                      
<snip>
(II) RADEONHD(0): Found libdri 5.4.0.
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 8, (OK)
drmOpenByBusid: Searching for BusID pci:0000:01:00.0
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 8, (OK)
drmOpenByBusid: drmOpenMinor returns 8
drmOpenByBusid: drmGetBusid reports pci:0000:01:00.0
(II) RADEONHD(0): Found libdrm 1.3.0.
(II) RADEONHD(0): Found radeon drm 1.29.0.
<snip>
(II) RADEONHD(0): Output DVI-I_2/digital using initial mode 1280x1024
(II) RADEONHD(0): RandR 1.2 support enabled
(==) RADEONHD(0): RGB weight 888
(==) RADEONHD(0): Default visual is TrueColor
(==) RADEONHD(0): Using gamma correction (1.0, 1.0, 1.0)
(II) RADEONHD(0): Using 1280x1280 Framebuffer with 1280 pitch
(II) RADEONHD(0): FB: Allocated ScanoutBuffer at offset 0x00008000 (size = 0x00640000)
(**) RADEONHD(0): Display dimensions: (376, 301) mm
(**) RADEONHD(0): DPI set to (86, 108)
<snip>
(II) RADEONHD(0): On Crtc 0 Setting 60.0 Hz Mode: Modeline "1280x1024"  108.00  1280 1328 1440 1688  1024 1025 1028 1066 +hsync +vsync

I wonder if the framebuffer size is OK? The screen is 1280x1024. That is
probably why the DPI is wacky (should both be 86).

Should I write the card in to opensuse.org? The card is a Sapphire
Radeon X1650Pro.

Additionally (but maybe unrelated), when I try to start tyr-glquake, it
bombs with an X error:

Callback: in_dgamouse ON
X Error of failed request:  XF86DGANoDirectVideoMode
  Major opcode of failed request:  137 (XFree86-DGA)
  Minor opcode of failed request:  2 (XF86DGADirectVideo)
  Serial number of failed request:  117
  Current serial number in output stream:  118

The library libXxf86dga-1.0.2 is installed. I see Xorg loading the extension.

Roland
-- 
R.F.Smith                                   http://www.xs4all.nl/~rsmith/
[plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated]
pgp: 1A2B 477F 9970 BA3C 2914  B7CE 1277 EFB0 C321 A725 (KeyID: C321A725)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090108/814102f6/attachment-0001.pgp
From rnoland at FreeBSD.org  Thu Jan  8 21:31:15 2009
From: rnoland at FreeBSD.org (Robert Noland)
Date: Thu Jan  8 21:31:27 2009
Subject: Pending MFC of drm updates
In-Reply-To: <20090108212610.GA2177@slackbox.xs4all.nl>
References: <1231263380.57454.23.camel@squirrel.corp.cox.com>
	<20090108212610.GA2177@slackbox.xs4all.nl>
Message-ID: <1231450265.93079.39.camel@squirrel.corp.cox.com>

On Thu, 2009-01-08 at 22:26 +0100, Roland Smith wrote:
> On Tue, Jan 06, 2009 at 12:36:20PM -0500, Robert Noland wrote:
> > I have a patch available for testing at
> > http://people.freebsd.org/~rnoland/drm-update-7-010609.patch.bz2
> 
> Excellent! Thanks for your hard work on this, Robert! 
> 
> After updating my source to 7.1-RELEASE, I applied this patch and built
> and installed a new kernel and world. This went without problems.
> 
> Starting X on a Sapphire Radeon X1650Pro works OK. XAA 2D accelleration
> works OK. The X logfile says that direct rendering is enabled, as is
> Xv. Mplayer works with Xv.
> 
> But whenever I try to start a program that uses OpenGL (i.e. glxgears) I
> get the following message:
> 
> unknown chip id 0x71c1, can't guess.
> libGL warning: 3D driver returned no fbconfigs.
> libGL error: InitDriver failed
> libGL error: reverting to (slow) indirect rendering

Yep, you need the updated xorg and mesa.  We are getting ready to update
the ports collection.  I may build up a new patch in a little while.

robert.


> :-(
> 
> The same number shows in Xorg.0.log:
> 
> <snip>
> (--) PCI:*(1:0:0) ATI Technologies Inc unknown chipset (0x71c1) rev 158, Mem @ 0xe0000000/28, 0xfe9e0000/16, I/O @ 0xd000/8, BIOS @ 0xfe9c0000/17
> <snip>
> (II) Loading extension XFree86-DGA
> <snip>
> (--) Chipset RV535 found
> <snip>
> (II) RADEONHD(0): Unknown card detected: 0x71C1:0x174B:0x0880.
>         If - and only if - your card does not work or does not work optimally
>         please contact radeonhd@opensuse.org to help rectify this.
>         Use the subject: 0x71C1:0x174B:0x0880: <name of board>
>         and *please* describe the problems you are seeing
>         in your message.
> (--) RADEONHD(0): Detected an RV535 on an unidentified card
> (==) RADEONHD(0): Write-combining range (0xfe9e0000,0x10000) was already clear
> (II) RADEONHD(0): Mapped IO @ 0xfe9e0000 to 0x8006a2000 (size 0x00010000)
> (II) RADEONHD(0): PCIE Card Detected
> (II) RADEONHD(0): Getting BIOS copy from legacy VBIOS location
> (II) RADEONHD(0): ATOM BIOS Rom: 
>         SubsystemVendorID: 0x174b SubsystemID: 0x0880
>         IOBaseAddress: 0xd000
>         Filename: 8C88GCSA.003
>         BIOS Bootup Message: 
> A67120 RV535XT VO BIOS GDDR3 600E/700M                                      
> <snip>
> (II) RADEONHD(0): Found libdri 5.4.0.
> drmOpenDevice: node name is /dev/dri/card0
> drmOpenDevice: open result is 8, (OK)
> drmOpenByBusid: Searching for BusID pci:0000:01:00.0
> drmOpenDevice: node name is /dev/dri/card0
> drmOpenDevice: open result is 8, (OK)
> drmOpenByBusid: drmOpenMinor returns 8
> drmOpenByBusid: drmGetBusid reports pci:0000:01:00.0
> (II) RADEONHD(0): Found libdrm 1.3.0.
> (II) RADEONHD(0): Found radeon drm 1.29.0.
> <snip>
> (II) RADEONHD(0): Output DVI-I_2/digital using initial mode 1280x1024
> (II) RADEONHD(0): RandR 1.2 support enabled
> (==) RADEONHD(0): RGB weight 888
> (==) RADEONHD(0): Default visual is TrueColor
> (==) RADEONHD(0): Using gamma correction (1.0, 1.0, 1.0)
> (II) RADEONHD(0): Using 1280x1280 Framebuffer with 1280 pitch
> (II) RADEONHD(0): FB: Allocated ScanoutBuffer at offset 0x00008000 (size = 0x00640000)
> (**) RADEONHD(0): Display dimensions: (376, 301) mm
> (**) RADEONHD(0): DPI set to (86, 108)
> <snip>
> (II) RADEONHD(0): On Crtc 0 Setting 60.0 Hz Mode: Modeline "1280x1024"  108.00  1280 1328 1440 1688  1024 1025 1028 1066 +hsync +vsync
> 
> I wonder if the framebuffer size is OK? The screen is 1280x1024. That is
> probably why the DPI is wacky (should both be 86).
> 
> Should I write the card in to opensuse.org? The card is a Sapphire
> Radeon X1650Pro.
> 
> Additionally (but maybe unrelated), when I try to start tyr-glquake, it
> bombs with an X error:
> 
> Callback: in_dgamouse ON
> X Error of failed request:  XF86DGANoDirectVideoMode
>   Major opcode of failed request:  137 (XFree86-DGA)
>   Minor opcode of failed request:  2 (XF86DGADirectVideo)
>   Serial number of failed request:  117
>   Current serial number in output stream:  118
> 
> The library libXxf86dga-1.0.2 is installed. I see Xorg loading the extension.
> 
> Roland
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090108/b9684c35/attachment.pgp
From brueffer at FreeBSD.org  Thu Jan  8 22:30:24 2009
From: brueffer at FreeBSD.org (Christian Brueffer)
Date: Thu Jan  8 22:30:31 2009
Subject: igb on a Nehalem system, buildworld stats
In-Reply-To: <f12f408a0901081050p1a8154c5h19035f399944b3fc@mail.gmail.com>
References: <f12f408a0901080616t78dded81l979a4ec06de7739f@mail.gmail.com>
	<2a41acea0901080844y1c2ad632t12aeadfbe9f34d0a@mail.gmail.com>
	<f12f408a0901081019x2ea4e83i47851fa3ed2a0ae4@mail.gmail.com>
	<2a41acea0901081033h7db7a1aej8399baf5dcbd270f@mail.gmail.com>
	<f12f408a0901081050p1a8154c5h19035f399944b3fc@mail.gmail.com>
Message-ID: <20090108220018.GB1300@haakonia.hitnet.RWTH-Aachen.DE>

On Fri, Jan 09, 2009 at 02:50:45AM +0800, Mars G Miro wrote:
> On Fri, Jan 9, 2009 at 2:33 AM, Jack Vogel <jfvogel@gmail.com> wrote:
> > Well, I am at Intel you know, and even we don't seem to have any systems
> > with
> > 82576 down in my group here. The way link works I can be about 99.9% sure
> > in saying its not the driver. Its preproduction so there are lots of
> > possibilities,
> > and the biggest problem is its going to be difficult to help when I don't
> > have any
> > such hardware :(
> >
> > I've heard from the 1G product team that they have seen EEPROM mismatches
> > on systems that will result in things not working in funny ways.
> 
> 
> Jahh, I've seen those but not w/ Intel NICs. I believe it was from
> Broadcom on some IBM x3455? (IIRC) and it was indeed quite amusing ;-)
> 
> 
> >
> > If you have a back to back connection to another NIC on Port 0, no switch,
> > does
> > it still autoneg to 100?
> >
> 
> I will have do that tomorrow as I am @home now ;-)
> 
> btw, another data point, during sysinstall, we encountered:
> 
>   <unknown network interface type> on both the igbs.
> 

This is due to missing a missing device entry in the sysinstall code.
Unfortunately there are entries missing for several new drivers, I will
commit a patch to fix this soon.

Anyway, it shouldn't be related to your problems.

- Christian

-- 
Christian Brueffer	chris@unixpages.org	brueffer@FreeBSD.org
GPG Key:	 http://people.freebsd.org/~brueffer/brueffer.key.asc
GPG Fingerprint: A5C8 2099 19FF AACA F41B  B29B 6C76 178C A0ED 982D
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090108/c80871ca/attachment.pgp
From rnoland at FreeBSD.org  Fri Jan  9 00:34:41 2009
From: rnoland at FreeBSD.org (Robert Noland)
Date: Fri Jan  9 00:34:49 2009
Subject: possibility of a "severe flaw in the logic of FreeBSD's kernel
	handling multiple host bridges ..."
In-Reply-To: <496651ED.8080102@T-Online.de>
References: <496651ED.8080102@T-Online.de>
Message-ID: <1231460648.93079.65.camel@squirrel.corp.cox.com>

On Thu, 2009-01-08 at 20:20 +0100, Manfred_Knick wrote:
> First: Congratulations upon 7.1 final RELEASE !
> 
> On Fri, 24 Oct 2008, I pointed out the
> 
>     "possibility of a severe flaw in the logic of FreeBSD's kernel
>      handling multiple host bridges
>      and the corresponding assignment of
>      (in principle, correctly detected)
>      devices to their host bridges"
> 
> :: -->   http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/128331
> 
> :: -->   http://forums.freebsd.org/showthread.php?t=236
> 
> but unfortunately, I did not get any response at all.
> Two mails to "kensmith@cse.Buffalo.EDU" asking for any contact e-mail 
> address of a FreeBSD Kernel developer knowing his way around 
> host-bridges and PCI-devices also gave no reaction.
> 
> I am sorry for this noise
> (I would have preferred to handle this more quietly),
> but finally I take hope to the advice of Daniel Gerzo (Thanks @ danger):
> 
> "If you will not receive any feedback I would recommend you to send an
> email to current@ and stable@ mailing lists. PR's sometimes get lost
> in the traffic and not all developers are checking GNATS all the time."
> 
> Looking forward to a contact

I'm really not sure that I am the best person to try and tackle this,
but it does fall somewhere near me... Can you send me a pciconf -lv.

robert.

> Kind regards
> 
> Manfred
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090109/e1e0a99c/attachment.pgp
From petefrench at ticketswitch.com  Fri Jan  9 01:58:32 2009
From: petefrench at ticketswitch.com (Pete French)
Date: Fri Jan  9 01:58:39 2009
Subject: Big problems with 7.1 locking up :-(
Message-ID: <E1LL6dg-0007CN-DI@dilbert.ticketswitch.com>

I have a number of HP 1U servers, all of which were running 7.0
perfectly happily. I have been testing 7.1 in it's various incarnations
for the last couple of months on our test server and it has performed
perfectly.

So the last two days I have been round upgrading all our servers, knowing
that I had run the system stably on identical hardware for some time.

Since then I have starte seeing machines lock up. This always happens under
heavy disc load. When I bring the machine back up then sometimes it fails
to fsck due to a partialy truncated inode. The locksup appear to
be disc related - on my mysql msater machine it will come back up with
files somewhat shorted than  those which ahve aready been transmitted to
the slave (i.e. some data was in memory, and claimed to have been written
to the drive, but never made it onto the disc).

The only time I have seen anything useful on the screen was during one lockup
where I got a message about a spin lock being held too long and some
comment in parentheses about it being a turnstile lock.

Help! :-(

I am now downgrading all the machine to 7.0 as fast as I can - though the
machine I am trying to compile it on has locked up once during the compile
so I havent got anywhere so far.

The machines are HP Proliant DL360 G5s - they have an embedded P400i
RAID controller with a pair of mirrored drives connected. Each one has
both ethernets connected, bundled using lagg and LACP.

Advice ?

-pete.
From ari at ish.com.au  Fri Jan  9 02:12:42 2009
From: ari at ish.com.au (Aristedes Maniatis)
Date: Fri Jan  9 02:12:51 2009
Subject: FreeBSD Update should be back to normal
In-Reply-To: <49665FEF.6030808@freebsd.org>
References: <49665FEF.6030808@freebsd.org>
Message-ID: <D355FA21-030D-434C-BF8D-A06A2BB95252@ish.com.au>


On 09/01/2009, at 7:19 AM, Colin Percival wrote:

> 2. Assuming the first mirror still fails, use the -s option to pick  
> a different
> mirror.

Where can we find a list of mirrors?

Ari Maniatis



-------------------------->
ish
http://www.ish.com.au
Level 1, 30 Wilson Street Newtown 2042 Australia
phone +61 2 9550 5001   fax +61 2 9550 4001
GPG fingerprint CBFB 84B4 738D 4E87 5E5C  5EFA EF6A 7D2E 3E49 102A


From royce at alaska.net  Fri Jan  9 03:51:06 2009
From: royce at alaska.net (Royce Williams)
Date: Fri Jan  9 03:51:14 2009
Subject: FreeBSD Update should be back to normal
In-Reply-To: <D355FA21-030D-434C-BF8D-A06A2BB95252@ish.com.au>
References: <49665FEF.6030808@freebsd.org>
	<D355FA21-030D-434C-BF8D-A06A2BB95252@ish.com.au>
Message-ID: <4966C9B1.1060700@alaska.net>

Aristedes Maniatis wrote, on 1/8/2009 5:12 PM:
> 
> On 09/01/2009, at 7:19 AM, Colin Percival wrote:
> 
>> 2. Assuming the first mirror still fails, use the -s option to pick a
>> different
>> mirror.
> 
> Where can we find a list of mirrors?

This technically answers your question, but may not be very
interesting. ;-)

royce@heffalump$ host -t srv _http._tcp.update.FreeBSD.org
_http._tcp.update.FreeBSD.org has SRV record 1 10 80 update1.FreeBSD.org.
_http._tcp.update.FreeBSD.org has SRV record 1 10 80 update3.FreeBSD.org.
_http._tcp.update.FreeBSD.org has SRV record 1 25 80 update2.FreeBSD.org.
_http._tcp.update.FreeBSD.org has SRV record 1 30 80 update4.FreeBSD.org.


Since it's unlikely that most people need to query the servers via 
some means other than freebsd-update, and since freebsd-update 
automatically pulls its list of mirrors from DNS, this is really only
for the sake of curiosity.  The list of mirrors can change at any 
time, which should be transparent to users of freebsd-update.

It looks like a couple of them are through Voxel's content delivery 
network (CDN).  I think that one of them has been hosted by ISC for
some time.  Since the Voxel ones are 3 and 4, I'm guessing that
they are the newcomers.

royce@heffalump$ host update1.FreeBSD.org
update1.FreeBSD.org has address 72.21.59.252
royce@heffalump$ host 72.21.59.252
252.59.21.72.in-addr.arpa domain name pointer 252.59.21.72.static.reverse.ltdomains.com.

royce@heffalump$ host update2.FreeBSD.org
update2.FreeBSD.org has address 149.20.64.41
royce@heffalump$ host 149.20.64.41
41.64.20.149.in-addr.arpa domain name pointer update2.freebsd.org.
royce@heffalump$ whois 149.20.64.41 | grep OrgName
OrgName:    Internet Systems Consortium, Inc.

royce@heffalump$ host update3.FreeBSD.org
update3.FreeBSD.org has address 72.26.203.74
royce@heffalump$ host 72.26.203.74
74.203.26.72.in-addr.arpa domain name pointer update3.FreeBSD.org.
royce@heffalump$ whois 72.26.203.74 | grep OrgName
OrgName:    Voxel Dot Net, Inc.

royce@heffalump$ host update4.FreeBSD.org
update4.FreeBSD.org is an alias for content.voxcdn.net.
content.voxcdn.net is an alias for content.loc.voxcdn.net.
content.loc.voxcdn.net is an alias for content.sjc1.site.voxcdn.net.
content.sjc1.site.voxcdn.net has address 208.122.62.226


Royce

-- 
Royce D. Williams                                   - http://royce.ws/
       Words are good servants but bad masters. - Aldous Huxley
From gnn at neville-neil.com  Fri Jan  9 04:31:46 2009
From: gnn at neville-neil.com (George Neville-Neil)
Date: Fri Jan  9 04:31:58 2009
Subject: CFT: ath hal src switchover
In-Reply-To: <49665E35.1050301@errno.com>
References: <49665E35.1050301@errno.com>
Message-ID: <C7B52B73-8F83-4314-9F52-228312678ADD@neville-neil.com>


On Jan 8, 2009, at 15:12 , Sam Leffler wrote:

> I've brought the hal source code back to RELENG_7 but not connected  
> it to the build and/or driver.  I want folks to test this before I  
> commit those changes.  To do this you must have an up to date  
> RELENG_7 code base and then apply this patch:
>
> http://people.freebsd.org/~sam/ath_hal-releng7.patch
>
> Then rebuild your kernel.  There should be no changes to user apps.   
> Beware however that custom kernel configurations will need to  
> change; instead of:
>
> device ath
> device ath_hal
> device ath_rate_sample
>
> (or similar) you need:
>
> device ath
> device ath_hal
> options AH_SUPPORT_AR5416
> device ath_rate_sample
>
> If you want to configure a subset of the chip support implied by  
> ath_hal then you may not need the options line.
>
> If you are using modules note that ath_hal and ath_rate_* modules no  
> longer exist; they are now rolled into the ath module.  If you use a  
> rate control algorithm other than sample then you'll need to modify  
> the ath module build or override by specifying ATH_RATE; e.g.
>
> cd sys/modules/ath
> make ATH_RATE=onoe
>
> The updated hal code adds support for several parts but otherwise  
> makes no effort to address driver bugs.  You should see no  
> regressions relative to operation w/ the older hal.
>
> If you are running the 7.1 release you will need to import the hal  
> code that is now in
>
> sys/dev/ath/ath_hal
>
> before following the above instructions.  I have no idea if this  
> will work for an earlier version of FreeBSD; if you're not running  
> at least 7.1 my advise is to upgrade.
>
> Please report any issues to this mailing list.

With this code in my kernel I get:

ath0: unable to reset hardware; hal status 0
ioctl[SIOCS80211, op 23, arg 0x0] : Invalid argument
Failed to initiate AP scan.
ath0: unable to reset hardware; hal status 14
ioctl[SIOCS80211, op 23, arg 0x0] : Invalid argument
Failed to initiate AP scan.

when I try to use wpa_supplicant with the code.  My home network uses  
WPA.

Best,
George


-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090109/3ec33f03/PGP.pgp
From scf at FreeBSD.org  Fri Jan  9 04:43:56 2009
From: scf at FreeBSD.org (Sean C. Farley)
Date: Fri Jan  9 04:44:04 2009
Subject: CFT: ath hal src switchover
In-Reply-To: <49665E35.1050301@errno.com>
References: <49665E35.1050301@errno.com>
Message-ID: <alpine.BSF.2.00.0901082219000.1315@baba.farley.org>

On Thu, 8 Jan 2009, Sam Leffler wrote:

> I've brought the hal source code back to RELENG_7 but not connected it 
> to the build and/or driver.  I want folks to test this before I commit 
> those changes.  To do this you must have an up to date RELENG_7 code 
> base and then apply this patch:
>
> http://people.freebsd.org/~sam/ath_hal-releng7.patch

*snip*

> Please report any issues to this mailing list.

No problems for my Netgear WPN511.  It works well at home.

Now, if I just could figure out why the recent Aruba update at work is 
preventing me from authenticating with it, I would be happy.  This is 
not related to the MFC of the code.  iPhones and MacOSX 10.4 (but not 
10.5) are also having problems.  Windows works.

Sean
-- 
scf@FreeBSD.org
From cperciva at freebsd.org  Fri Jan  9 06:54:14 2009
From: cperciva at freebsd.org (Colin Percival)
Date: Fri Jan  9 06:54:21 2009
Subject: FreeBSD Update should be back to normal
In-Reply-To: <D355FA21-030D-434C-BF8D-A06A2BB95252@ish.com.au>
References: <49665FEF.6030808@freebsd.org>
	<D355FA21-030D-434C-BF8D-A06A2BB95252@ish.com.au>
Message-ID: <4966F425.8060001@freebsd.org>

Aristedes Maniatis wrote:
> 
> On 09/01/2009, at 7:19 AM, Colin Percival wrote:
> 
>> 2. Assuming the first mirror still fails, use the -s option to pick a 
>> different
>> mirror.
> 
> Where can we find a list of mirrors?

The list of is distributed via DNS SRV records:
# host -t srv _http._tcp.update.freebsd.org
prints a list of the mirrors (currently update1 through update4, but that
is subject to change).

-- 
Colin Percival
Security Officer, FreeBSD | freebsd.org | The power to serve
Founder / author, Tarsnap | tarsnap.com | Online backups for the truly paranoid
From krassi at bulinfo.net  Fri Jan  9 08:01:37 2009
From: krassi at bulinfo.net (Krassimir Slavchev)
Date: Fri Jan  9 08:01:45 2009
Subject: ACPI support?
In-Reply-To: <20090108204311.c9700e91.torfinn.ingolfsen@broadpark.no>
References: <49633C85.3090507@bulinfo.net>
	<20090108204311.c9700e91.torfinn.ingolfsen@broadpark.no>
Message-ID: <4967045D.30109@bulinfo.net>

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

Hi,

Thanks for your reply!

Torfinn Ingolfsen wrote:
> On Tue, 06 Jan 2009 13:12:05 +0200
> Krassimir Slavchev <krassi@bulinfo.net> wrote:
> 
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Hello All,
>>
>> I have had a problem detecting the network card on my notebook when
>> ACPI is enabled for a year. The problem still exists in 7.1-RELEASE.
> 
> Which make and model notebook is this?
> 
Acer Aspire 5920G

> You have my sympaties, my own laptop[1] (Acer Aspire 5672) have the same
> sort of problem - drivers for NICs (both wired and wireless) will not
> attach if acpi is enabled. And this laptop gets too hot when acpi is
> disabled - I fear it will overheat. Linux runs fine[2] on it.
>

same

> I had a lot of help in trying to fix the problem a wbile back (check
> the freebsd-mobile mailing list archives), but in the end, nothing
> helped.

I have found that thread.

> 
>  I can only offer general advice, not a solution. Try too look for
> a modfified DSDT for your notebook, perhpas you will find something
> that helps.
> 
> References:
> 1) http://tingox.googlepages.com/aceraspireas5672andfreebsd
> 2) http://tingox.googlepages.com/as5672_xubuntu

Modifying the DSDT was the first thing I tried a year ago but nothing.

The problem may be with allocating resources by ACPI PCI-PCI bridge.
There is a way to set needed values:
http://lists.freebsd.org/pipermail/freebsd-acpi/2008-May/004905.html

I am still not sure where is the exact problem! Whether something is
wrong with ACPI PCI-PCI bridge or ACPI does not offer these resources?

I would like to work on this and any help is welcome

Best Regards
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (FreeBSD)

iD8DBQFJZwRdxJBWvpalMpkRAuP0AJ9gn2sc9vF2emPfqEBxl7suNYNzTgCePbWp
k8L3cDbNfYYxJ6gT6b/541g=
=wZlz
-----END PGP SIGNATURE-----
From spry at anarchy.in.the.ph  Fri Jan  9 08:02:10 2009
From: spry at anarchy.in.the.ph (Mars G Miro)
Date: Fri Jan  9 08:02:17 2009
Subject: igb on a Nehalem system, buildworld stats
In-Reply-To: <f12f408a0901081050p1a8154c5h19035f399944b3fc@mail.gmail.com>
References: <f12f408a0901080616t78dded81l979a4ec06de7739f@mail.gmail.com>
	<2a41acea0901080844y1c2ad632t12aeadfbe9f34d0a@mail.gmail.com>
	<f12f408a0901081019x2ea4e83i47851fa3ed2a0ae4@mail.gmail.com>
	<2a41acea0901081033h7db7a1aej8399baf5dcbd270f@mail.gmail.com>
	<f12f408a0901081050p1a8154c5h19035f399944b3fc@mail.gmail.com>
Message-ID: <f12f408a0901090002k4f50472aleb52c63359365232@mail.gmail.com>

On Fri, Jan 9, 2009 at 2:50 AM, Mars G Miro <spry@anarchy.in.the.ph> wrote:
> On Fri, Jan 9, 2009 at 2:33 AM, Jack Vogel <jfvogel@gmail.com> wrote:
>> Well, I am at Intel you know, and even we don't seem to have any systems
>> with
>> 82576 down in my group here. The way link works I can be about 99.9% sure
>> in saying its not the driver. Its preproduction so there are lots of
>> possibilities,
>> and the biggest problem is its going to be difficult to help when I don't
>> have any
>> such hardware :(
>>
>> I've heard from the 1G product team that they have seen EEPROM mismatches
>> on systems that will result in things not working in funny ways.
>
>
> Jahh, I've seen those but not w/ Intel NICs. I believe it was from
> Broadcom on some IBM x3455? (IIRC) and it was indeed quite amusing ;-)
>
>
>>
>> If you have a back to back connection to another NIC on Port 0, no switch,
>> does
>> it still autoneg to 100?
>>

Connected back to back w/ another box w/ a GigE NIC, it now does 1000baseTX:

igb0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=19b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4>
        ether 00:30:48:c5:db:e2
        inet6 fe80::230:48ff:fec5:dbe2%igb0 prefixlen 64 scopeid 0x1
        inet 192.168.70.2 netmask 0xffffff00 broadcast 192.168.70.255
        media: Ethernet autoselect (1000baseTX <full-duplex>)
        status: active

But still not without problems. I hafta ifconfig down/up it several
times until I can see the other end. W/c is the same for igb1.


>
[snip]

-- 
cheers
mars
From Manfred.Knick at T-Online.de  Fri Jan  9 09:01:37 2009
From: Manfred.Knick at T-Online.de (Manfred_Knick)
Date: Fri Jan  9 09:01:50 2009
Subject: possibility of a "severe flaw in the logic of FreeBSD's kernel
 handling multiple host bridges ..."
In-Reply-To: <1231460648.93079.65.camel@squirrel.corp.cox.com>
References: <496651ED.8080102@T-Online.de>
	<1231460648.93079.65.camel@squirrel.corp.cox.com>
Message-ID: <4967125D.80801@T-Online.de>

Robert Noland schrieb:

> I'm really not sure that I am the best person to try and tackle this,

Hi, Robert,

thank you very much for your reply!

> but it does fall somewhere near me... Can you send me a pciconf -lv.

You are welcome!
Well, as stated in the reports, I'm prepared to help with additional
information and tests I can provide.

My main background is Gentoo (GNU/Linux source based rolling meta-
distribution), thus knowing my way around building my hand-crafted
kernels ...

Kind regards
Manfred

.   ---   ---   ---   pciconf -lv   ---   ---   ---

hostb0@pci0:0:0:0:	class=0x060000 card=0x00e11849 chip=0x00e110de
rev=0xa1 hdr=0x00
     vendor     = 'Nvidia Corp'
     device     = 'nForce3 250 Host/PCI Bridge'                  <=====
     class      = bridge
     subclass   = HOST-PCI
isab0@pci0:0:1:0:	class=0x060100 card=0x00e01849 chip=0x00e010de
rev=0xa2 hdr=0x00
     vendor     = 'Nvidia Corp'
     device     = 'nForce3 250 LPC Interface Bridge'
     class      = bridge
     subclass   = PCI-ISA
none0@pci0:0:1:1:	class=0x0c0500 card=0x00e41849 chip=0x00e410de
rev=0xa1 hdr=0x00
     vendor     = 'Nvidia Corp'
     device     = 'nForce3 250 PCI System Management'
     class      = serial bus
     subclass   = SMBus
ohci0@pci0:0:2:0:	class=0x0c0310 card=0x00e71849 chip=0x00e710de
rev=0xa1 hdr=0x00
     vendor     = 'Nvidia Corp'
     device     = 'nForce3 250 OpenHCD USB Controller'
     class      = serial bus
     subclass   = USB
ohci1@pci0:0:2:1:	class=0x0c0310 card=0x00e71849 chip=0x00e710de
rev=0xa1 hdr=0x00
     vendor     = 'Nvidia Corp'
     device     = 'nForce3 250 OpenHCD USB Controller'
     class      = serial bus
     subclass   = USB
ehci0@pci0:0:2:2:	class=0x0c0320 card=0x00e81849 chip=0x00e810de
rev=0xa2 hdr=0x00
     vendor     = 'Nvidia Corp'
     device     = 'nForce3 250 Enhanced PCI to USB Controller'
     class      = serial bus
     subclass   = USB
atapci0@pci0:0:8:0:	class=0x01018a card=0x00e51849 chip=0x00e510de
rev=0xa2 hdr=0x00
     vendor     = 'Nvidia Corp'
     device     = 'nForce3 250 Parallel ATA Controller'
     class      = mass storage
     subclass   = ATA
atapci1@pci0:0:10:0:	class=0x010185 card=0x00e31849 chip=0x00e310de
rev=0xa2 hdr=0x00
     vendor     = 'Nvidia Corp'
     device     = 'nForce3 250 Serial ATA Controller'
     class      = mass storage
     subclass   = ATA
pcib1@pci0:0:11:0:	class=0x060400 card=0x00000000 chip=0x00e210de
rev=0xa2 hdr=0x01
     vendor     = 'Nvidia Corp'
     device     = 'nForce3 250 AGP Host to PCI Bridge'           <=====
     class      = bridge
     subclass   = PCI-PCI
pcib2@pci0:0:14:0:	class=0x060400 card=0x00000000 chip=0x00ed10de
rev=0xa2 hdr=0x01
     vendor     = 'Nvidia Corp'
     device     = 'nForce3 250 PCI-PCI Bridge'                   <=====
     class      = bridge
     subclass   = PCI-PCI
hostb1@pci0:0:16:0:	class=0x060000 card=0x00000000 chip=0x169510b9
rev=0x00 hdr=0x00
     vendor     = 'Acer Labs Incorporated (ALi/ULi)'
     device     = 'ULi M1695 K8 Northbridge with PCIe and hypertransport'
     class      = bridge
     subclass   = HOST-PCI
pcib3@pci0:0:17:0:	class=0x060400 card=0x00000000 chip=0x524b10b9
rev=0x00 hdr=0x01
     vendor     = 'Acer Labs Incorporated (ALi/ULi)'
     device     = 'ALi PCIe Bridge'
     class      = bridge
     subclass   = PCI-PCI
pcib4@pci0:0:18:0:	class=0x060400 card=0x00000000 chip=0x524c10b9
rev=0x00 hdr=0x01
     vendor     = 'Acer Labs Incorporated (ALi/ULi)'
     device     = 'ALi PCIe Bridge'
     class      = bridge
     subclass   = PCI-PCI
pcib5@pci0:0:19:0:	class=0x060400 card=0x00000000 chip=0x524d10b9
rev=0x00 hdr=0x01
     vendor     = 'Acer Labs Incorporated (ALi/ULi)'
     class      = bridge
     subclass   = PCI-PCI
hostb2@pci0:0:24:0:	class=0x060000 card=0x00000000 chip=0x12001022
rev=0x00 hdr=0x00
     vendor     = 'Advanced Micro Devices (AMD)'
     device     = '(Family 10h) Athlon 64/Opteron/Sempron HyperTransport
Technology Configuration'
     class      = bridge
     subclass   = HOST-PCI
hostb3@pci0:0:24:1:	class=0x060000 card=0x00000000 chip=0x12011022
rev=0x00 hdr=0x00
     vendor     = 'Advanced Micro Devices (AMD)'
     device     = '(Family 10h) Athlon 64/Opteron/Sempron Address Map'
     class      = bridge
     subclass   = HOST-PCI
hostb4@pci0:0:24:2:	class=0x060000 card=0x00000000 chip=0x12021022
rev=0x00 hdr=0x00
     vendor     = 'Advanced Micro Devices (AMD)'
     device     = '(Family 10h) Athlon 64/Opteron/Sempron DRAM Controller'
     class      = bridge
     subclass   = HOST-PCI
hostb5@pci0:0:24:3:	class=0x060000 card=0x00000000 chip=0x12031022
rev=0x00 hdr=0x00
     vendor     = 'Advanced Micro Devices (AMD)'
     device     = '(Family 10h) Athlon 64/Opteron/Sempron Miscellaneous
Control'
     class      = bridge
     subclass   = HOST-PCI
hostb6@pci0:0:24:4:	class=0x060000 card=0x00000000 chip=0x12041022
rev=0x00 hdr=0x00
     vendor     = 'Advanced Micro Devices (AMD)'
     device     = '(Family 10h) Athlon 64/Opteron/Sempron Link Control'
     class      = bridge
     subclass   = HOST-PCI
vgapci0@pci0:4:0:0:	class=0x030000 card=0x0f84102b chip=0x2527102b
rev=0x01 hdr=0x00
     vendor     = 'Matrox Electronic Systems Ltd.'
     device     = 'MGA-G550 AGP Chipset'                         <=====
     class      = display
     subclass   = VGA
atapci2@pci0:1:0:0:	class=0x010185 card=0x23631849 chip=0x2363197b
rev=0x03 hdr=0x00
     vendor     = 'JMicron Technology Corp'
     device     = 'JMB36X PCIe-to-SATA-300/IDE RAID Controller'
     class      = mass storage
     subclass   = ATA
re0@pci0:2:0:0:	class=0x020000 card=0x81681849 chip=0x816810ec rev=0x01
hdr=0x00
     vendor     = 'Realtek Semiconductor'
     device     = 'RTL8168/8111 PCI-E Gigabit Ethernet NIC'
     class      = network
     subclass   = ethernet



From jfvogel at gmail.com  Fri Jan  9 09:16:00 2009
From: jfvogel at gmail.com (Jack Vogel)
Date: Fri Jan  9 09:16:11 2009
Subject: igb on a Nehalem system, buildworld stats
In-Reply-To: <f12f408a0901090002k4f50472aleb52c63359365232@mail.gmail.com>
References: <f12f408a0901080616t78dded81l979a4ec06de7739f@mail.gmail.com>
	<2a41acea0901080844y1c2ad632t12aeadfbe9f34d0a@mail.gmail.com>
	<f12f408a0901081019x2ea4e83i47851fa3ed2a0ae4@mail.gmail.com>
	<2a41acea0901081033h7db7a1aej8399baf5dcbd270f@mail.gmail.com>
	<f12f408a0901081050p1a8154c5h19035f399944b3fc@mail.gmail.com>
	<f12f408a0901090002k4f50472aleb52c63359365232@mail.gmail.com>
Message-ID: <2a41acea0901090115q6af9f364qac23a8cce444d27a@mail.gmail.com>

On Fri, Jan 9, 2009 at 12:02 AM, Mars G Miro <spry@anarchy.in.the.ph> wrote:

> On Fri, Jan 9, 2009 at 2:50 AM, Mars G Miro <spry@anarchy.in.the.ph>
> wrote:
> > On Fri, Jan 9, 2009 at 2:33 AM, Jack Vogel <jfvogel@gmail.com> wrote:
> >> Well, I am at Intel you know, and even we don't seem to have any systems
> >> with
> >> 82576 down in my group here. The way link works I can be about 99.9%
> sure
> >> in saying its not the driver. Its preproduction so there are lots of
> >> possibilities,
> >> and the biggest problem is its going to be difficult to help when I
> don't
> >> have any
> >> such hardware :(
> >>
> >> I've heard from the 1G product team that they have seen EEPROM
> mismatches
> >> on systems that will result in things not working in funny ways.
> >
> >
> > Jahh, I've seen those but not w/ Intel NICs. I believe it was from
> > Broadcom on some IBM x3455? (IIRC) and it was indeed quite amusing ;-)
> >
> >
> >>
> >> If you have a back to back connection to another NIC on Port 0, no
> switch,
> >> does
> >> it still autoneg to 100?
> >>
>
> Connected back to back w/ another box w/ a GigE NIC, it now does
> 1000baseTX:
>
> igb0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
>        options=19b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4>
>        ether 00:30:48:c5:db:e2
>        inet6 fe80::230:48ff:fec5:dbe2%igb0 prefixlen 64 scopeid 0x1
>         inet 192.168.70.2 netmask 0xffffff00 broadcast 192.168.70.255
>         media: Ethernet autoselect (1000baseTX <full-duplex>)
>        status: active
>
> But still not without problems. I hafta ifconfig down/up it several
> times until I can see the other end. W/c is the same for igb1.
>


OK, so you have some switch issue.  What do you mean "see the other end",
if its back to back and boots up I assume it gets link, if you have the
address
assigned in rc.conf, and you run tcpdump on the partner do you see the arp
when it comes online, and at that point can the other side ping it?

Oh, and what is the link partner hardware?

Jack
From spry at anarchy.in.the.ph  Fri Jan  9 10:14:36 2009
From: spry at anarchy.in.the.ph (Mars G Miro)
Date: Fri Jan  9 10:14:44 2009
Subject: igb on a Nehalem system, buildworld stats
In-Reply-To: <2a41acea0901090115q6af9f364qac23a8cce444d27a@mail.gmail.com>
References: <f12f408a0901080616t78dded81l979a4ec06de7739f@mail.gmail.com>
	<2a41acea0901080844y1c2ad632t12aeadfbe9f34d0a@mail.gmail.com>
	<f12f408a0901081019x2ea4e83i47851fa3ed2a0ae4@mail.gmail.com>
	<2a41acea0901081033h7db7a1aej8399baf5dcbd270f@mail.gmail.com>
	<f12f408a0901081050p1a8154c5h19035f399944b3fc@mail.gmail.com>
	<f12f408a0901090002k4f50472aleb52c63359365232@mail.gmail.com>
	<2a41acea0901090115q6af9f364qac23a8cce444d27a@mail.gmail.com>
Message-ID: <f12f408a0901090214x2daafb37ld74836f628cfca8c@mail.gmail.com>

On Fri, Jan 9, 2009 at 5:15 PM, Jack Vogel <jfvogel@gmail.com> wrote:
>
[snip]
>> >>
>> >> If you have a back to back connection to another NIC on Port 0, no
>> >> switch,
>> >> does
>> >> it still autoneg to 100?
>> >>
>>
>> Connected back to back w/ another box w/ a GigE NIC, it now does
>> 1000baseTX:
>>
>> igb0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
>>        options=19b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4>
>>        ether 00:30:48:c5:db:e2
>>        inet6 fe80::230:48ff:fec5:dbe2%igb0 prefixlen 64 scopeid 0x1
>>        inet 192.168.70.2 netmask 0xffffff00 broadcast 192.168.70.255
>>        media: Ethernet autoselect (1000baseTX <full-duplex>)
>>        status: active
>>
>> But still not without problems. I hafta ifconfig down/up it several
>> times until I can see the other end. W/c is the same for igb1.
>
>
> OK, so you have some switch issue.  What do you mean "see the other end",
> if its back to back and boots up I assume it gets link, if you have the
> address
> assigned in rc.conf, and you run tcpdump on the partner do you see the arp
> when it comes online, and at that point can the other side ping it?
>

By 'see the other end' , I meant that even if It says 1000baseTX, i
still can't ping the other end, well not really, as I can now see it
gots bad chksums:

1. 001691 00:30:48:c5:db:e2 > ff:ff:ff:ff:ff:ff, ethertype ARP
(0x0806), length 60: arp who-has 192.168.70.2 tell 192.168.70.2
1. 511111 00:30:48:c5:db:e2 > 00:30:48:61:d7:f2, ethertype IPv4
(0x0800), length 98: (tos 0x0, ttl 64, id 20346, offset 0, flags
[none], proto ICMP (1), length 84) 192.168.70.2 > 192.168.70.1: ICMP
echo request, id 14852, seq 0, length 64
000012 00:30:48:61:d7:f2 > 00:30:48:c5:db:e2, ethertype IPv4 (0x0800),
length 98: (tos 0x0, ttl 64, id 3034, offset 0, flags [none], proto
ICMP (1), length 84, bad cksum 0 (->617b)!) 192.168.70.1 >
192.168.70.2: ICMP echo reply, id 14852, seq 0, length 64
1. 001611 00:30:48:c5:db:e2 > 00:30:48:61:d7:f2, ethertype IPv4
(0x0800), length 98: (tos 0x0, ttl 64, id 57773, offset 0, flags
[none], proto ICMP (1), length 84) 192.168.70.2 > 192.168.70.1: ICMP
echo request, id 14852, seq 1, length 64
000011 00:30:48:61:d7:f2 > 00:30:48:c5:db:e2, ethertype IPv4 (0x0800),
length 98: (tos 0x0, ttl 64, id 59591, offset 0, flags [none], proto
ICMP (1), length 84, bad cksum 0 (->848d)!) 192.168.70.1 >
192.168.70.2: ICMP echo reply, id 14852, seq 1, length 64

and this is back to back w/ another box w/ a GigE NIC (nfe, w/c has
been in production for some time)

> Oh, and what is the link partner hardware?
>

The switch? it's a Dlink 48-Port DGS-1248T GigE switch.

Thanks.

> Jack
>
>



-- 
cheers
mars
From spry at anarchy.in.the.ph  Fri Jan  9 10:22:18 2009
From: spry at anarchy.in.the.ph (Mars G Miro)
Date: Fri Jan  9 10:22:25 2009
Subject: igb on a Nehalem system, buildworld stats
In-Reply-To: <f12f408a0901090214x2daafb37ld74836f628cfca8c@mail.gmail.com>
References: <f12f408a0901080616t78dded81l979a4ec06de7739f@mail.gmail.com>
	<2a41acea0901080844y1c2ad632t12aeadfbe9f34d0a@mail.gmail.com>
	<f12f408a0901081019x2ea4e83i47851fa3ed2a0ae4@mail.gmail.com>
	<2a41acea0901081033h7db7a1aej8399baf5dcbd270f@mail.gmail.com>
	<f12f408a0901081050p1a8154c5h19035f399944b3fc@mail.gmail.com>
	<f12f408a0901090002k4f50472aleb52c63359365232@mail.gmail.com>
	<2a41acea0901090115q6af9f364qac23a8cce444d27a@mail.gmail.com>
	<f12f408a0901090214x2daafb37ld74836f628cfca8c@mail.gmail.com>
Message-ID: <f12f408a0901090222h589ddf43wa0ddddc0fbde5afe@mail.gmail.com>

On Fri, Jan 9, 2009 at 6:14 PM, Mars G Miro <spry@anarchy.in.the.ph> wrote:
> On Fri, Jan 9, 2009 at 5:15 PM, Jack Vogel <jfvogel@gmail.com> wrote:
>>
> [snip]
>>> >>
>>> >> If you have a back to back connection to another NIC on Port 0, no
>>> >> switch,
>>> >> does
>>> >> it still autoneg to 100?
>>> >>
>>>
>>> Connected back to back w/ another box w/ a GigE NIC, it now does
>>> 1000baseTX:
>>>
>>> igb0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
>>>        options=19b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4>
>>>        ether 00:30:48:c5:db:e2
>>>        inet6 fe80::230:48ff:fec5:dbe2%igb0 prefixlen 64 scopeid 0x1
>>>        inet 192.168.70.2 netmask 0xffffff00 broadcast 192.168.70.255
>>>        media: Ethernet autoselect (1000baseTX <full-duplex>)
>>>        status: active
>>>
>>> But still not without problems. I hafta ifconfig down/up it several
>>> times until I can see the other end. W/c is the same for igb1.
>>
>>
>> OK, so you have some switch issue.  What do you mean "see the other end",
>> if its back to back and boots up I assume it gets link, if you have the
>> address
>> assigned in rc.conf, and you run tcpdump on the partner do you see the arp
>> when it comes online, and at that point can the other side ping it?
>>
>
> By 'see the other end' , I meant that even if It says 1000baseTX, i
> still can't ping the other end, well not really, as I can now see it
> gots bad chksums:
>
> 1. 001691 00:30:48:c5:db:e2 > ff:ff:ff:ff:ff:ff, ethertype ARP
> (0x0806), length 60: arp who-has 192.168.70.2 tell 192.168.70.2
> 1. 511111 00:30:48:c5:db:e2 > 00:30:48:61:d7:f2, ethertype IPv4
> (0x0800), length 98: (tos 0x0, ttl 64, id 20346, offset 0, flags
> [none], proto ICMP (1), length 84) 192.168.70.2 > 192.168.70.1: ICMP
> echo request, id 14852, seq 0, length 64
> 000012 00:30:48:61:d7:f2 > 00:30:48:c5:db:e2, ethertype IPv4 (0x0800),
> length 98: (tos 0x0, ttl 64, id 3034, offset 0, flags [none], proto
> ICMP (1), length 84, bad cksum 0 (->617b)!) 192.168.70.1 >
> 192.168.70.2: ICMP echo reply, id 14852, seq 0, length 64
> 1. 001611 00:30:48:c5:db:e2 > 00:30:48:61:d7:f2, ethertype IPv4
> (0x0800), length 98: (tos 0x0, ttl 64, id 57773, offset 0, flags
> [none], proto ICMP (1), length 84) 192.168.70.2 > 192.168.70.1: ICMP
> echo request, id 14852, seq 1, length 64
> 000011 00:30:48:61:d7:f2 > 00:30:48:c5:db:e2, ethertype IPv4 (0x0800),
> length 98: (tos 0x0, ttl 64, id 59591, offset 0, flags [none], proto
> ICMP (1), length 84, bad cksum 0 (->848d)!) 192.168.70.1 >
> 192.168.70.2: ICMP echo reply, id 14852, seq 1, length 64
>
> and this is back to back w/ another box w/ a GigE NIC (nfe, w/c has
> been in production for some time)
>
>> Oh, and what is the link partner hardware?
>>
>
> The switch? it's a Dlink 48-Port DGS-1248T GigE switch.
>
> Thanks.
>

btw,  I tried 200812-CURRENT and CURRENT as of Jan 7 and the behavior
is still the same :-(


>> Jack
>>
>>
>
>
>
> --
> cheers
> mars
>



-- 
cheers
mars
From db at danielbond.org  Fri Jan  9 11:18:59 2009
From: db at danielbond.org (Daniel Bond)
Date: Fri Jan  9 11:19:06 2009
Subject: kernel dump with 7.1-RELEASE
In-Reply-To: <75a268720901080805t3b85fa2bgf9b78abc1fb9a5c4@mail.gmail.com>
References: <75a268720901080805t3b85fa2bgf9b78abc1fb9a5c4@mail.gmail.com>
Message-ID: <470C1D05-FD7B-4216-8598-36B6D886987B@danielbond.org>

Hi,

I'm assuming you configured a a dump-device in rc.conf, but just in  
case, here are the options:

db ~> grep dump /etc/defaults/rc.conf                              
[p8@gonzales]
dumpdev="AUTO"		# Device to crashdump to (device name, AUTO, or NO).
dumpdir="/var/crash"	# Directory where crash dumps are to be stored
savecore_flags=""	# Used if dumpdev is enabled above, and present.

using SWAP as the dumpdevice is the recommended way, as you sorta  
pointed out. More information can be found at:

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


On Jan 8, 2009, at 5:05 PM, Omer Faruk Sen wrote:

> Hi,
>
> I am having kernel dumps with FreeBSD 7.1
>
> panic: semexit - semid not allocated
> cpuid = 1
> Uptime : 8m22s
> Cannot dump. No dump device defined
> Sleeping thread (tid 100129, pid 1479) owns a non-sleepable lock
>
>
> I know it is not clear and there were no swap space configured on this
> server (which I will re-install with swap space) but can someone
> enlighten me about this since I think this bug was also in FreeBSD 6.2
> and fixed in FreeBSD 6.3
>
> Regards.
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org 
> "

From pyunyh at gmail.com  Fri Jan  9 11:22:58 2009
From: pyunyh at gmail.com (Pyun YongHyeon)
Date: Fri Jan  9 11:23:05 2009
Subject: Lock enabling onboard lan (Attansic L1 GbE) on 7.1-PRERELEASE
In-Reply-To: <28973184.939641231151814355.JavaMail.defaultUser@defaultHost>
References: <28973184.939641231151814355.JavaMail.defaultUser@defaultHost>
Message-ID: <20090109112246.GI30747@cdnetworks.co.kr>

On Mon, Jan 05, 2009 at 11:36:54AM +0100, Barbara wrote:

[...]

 > I've tried all the thing you've suggested with 
 > the same result.
 > I've disabled "LAN Option ROM", but it seems that I don't have 
 > the other options you mentioned.
 > I've downloaded and burned the 7.1-RELEASE dvd 
 > and tried to boot from it, but it hangs at the same point.
 > Finally I've tried 
 > booting a CURRENT snapshot cd (8.0-CURRENT-200812) and I was able to properly 
 > configure the device in sysinstall.
 > Any idea about the problem?

No, there is no source code differences between CURRENT and 7.1-RELEASE.

 > I've installed 
 > from 7.0 and I have another NIC, but being now age in GENERIC, I hope it will 
 > not cause troubles to other people installing for the first time.
 > Anyway thank 
 > you for now, and ask me if there is something that I can do to fix the problem 
 > like more tests, patches, etc.
 > 

Would try the following WIP version?
http://people.freebsd.org/~yongari/age/if_age.c
http://people.freebsd.org/~yongari/age/if_agereg.h
I have no longer access to L1 hardware so I don't know whether it
helps or not.

-- 
Regards,
Pyun YongHyeon
From db at danielbond.org  Fri Jan  9 11:25:31 2009
From: db at danielbond.org (Daniel Bond)
Date: Fri Jan  9 11:25:39 2009
Subject: NIC for VLAN
In-Reply-To: <200901081026.n08AQfnd099707@lurza.secnetix.de>
References: <200901081026.n08AQfnd099707@lurza.secnetix.de>
Message-ID: <0E426716-3254-4262-98C1-55BDDFAFE545@danielbond.org>

Hi,

BCE-based cards looks good on paper, but it's firmware is of poor  
quality compared to BGE-based cards.
The BCE-cards could sink 1.48Mpps, but it ftq drops 800Kpps, and the  
host sees 600Kpps. TX is ~800Kpps (according to sephe).

That said, I'm using dot1q vlan trunks on both bce and bge based  
cards, and it's working well.


Regards,


Daniel.


On Jan 8, 2009, at 11:26 AM, Oliver Fromme wrote:

> Edvaldo Silva wrote:
>> Please, can someone point a NIC, PCI 2.2 specs, full VLAN capable  
>> under
>> FreeBSD?
>
> I'm using bge(4) and bce(4) interfaces (Broadcom GBit) and
> fxp(4) ones (100 MBit) in enviroments with heavy use of VLANs.
> They work very well.  There are no problems with the MTU.
>
> Best regards
>   Oliver
>
> -- 
> Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing  
> b. M.
> Handelsregister: Registergericht Muenchen, HRA 74606,   
> Gesch?ftsfuehrung:
> secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht  
> M?n-
> chen, HRB 125758,  Gesch?ftsf?hrer: Maik Bachmann, Olaf Erb, Ralf  
> Gebhart
>
> FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd
>
> "A language that doesn't have everything is actually easier
> to program in than some that do."
>        -- Dennis M. Ritchie
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org 
> "

From danny at cs.huji.ac.il  Fri Jan  9 11:48:26 2009
From: danny at cs.huji.ac.il (Danny Braniss)
Date: Fri Jan  9 11:48:39 2009
Subject: more marvell marvels
Message-ID: <E1LLFqi-0001Ew-4K@kabab.cs.huji.ac.il>

hi, the mb is asus P5K-VM, the onboard nic is, acccording to pciconf:

mskc0@pci0:1:0:0:       class=0x020000 card=0x81f81043 chip=0x436411ab 
rev=0x12 hdr=0x00
    vendor     = 'Marvell Semiconductor (Was: Galileo Technology Ltd)'
    device     = '88E8056 Yukon PCI-E Gigabit Ethernet Controller'
    class      = network
    subclass   = ethernet
    cap 01[48] = powerspec 3  supports D0 D1 D2 D3  current D0
    cap 03[50] = VPD
    cap 05[5c] = MSI supports 1 message, 64 bit 
    cap 10[e0] = PCI-Express 1 legacy endpoint

nothing new here, problems have been reported before, but:

my very first attempt - after a very long time - of booting 7.1-stable, 
produced
a panic because msk could not find its physio, by the time i had the serial 
console
attached and working, that problem disappeared :-(
now, after reboot, it sometimes hangs - because the net is not working, and 
only if
I unplug the ethernet, (no signs of the driver seeing this), and replug things 
begin
to work. btw, i had to set
	 hw.msk.legacy_intr="1"
to get things working.

any patches for 7.1-stable to test?

danny



From pyunyh at gmail.com  Fri Jan  9 12:19:39 2009
From: pyunyh at gmail.com (Pyun YongHyeon)
Date: Fri Jan  9 12:19:46 2009
Subject: more marvell marvels
In-Reply-To: <E1LLFqi-0001Ew-4K@kabab.cs.huji.ac.il>
References: <E1LLFqi-0001Ew-4K@kabab.cs.huji.ac.il>
Message-ID: <20090109121930.GJ30747@cdnetworks.co.kr>

On Fri, Jan 09, 2009 at 01:48:24PM +0200, Danny Braniss wrote:
 > hi, the mb is asus P5K-VM, the onboard nic is, acccording to pciconf:
 > 
 > mskc0@pci0:1:0:0:       class=0x020000 card=0x81f81043 chip=0x436411ab 
 > rev=0x12 hdr=0x00
 >     vendor     = 'Marvell Semiconductor (Was: Galileo Technology Ltd)'
 >     device     = '88E8056 Yukon PCI-E Gigabit Ethernet Controller'
 >     class      = network
 >     subclass   = ethernet
 >     cap 01[48] = powerspec 3  supports D0 D1 D2 D3  current D0
 >     cap 03[50] = VPD
 >     cap 05[5c] = MSI supports 1 message, 64 bit 
 >     cap 10[e0] = PCI-Express 1 legacy endpoint
 > 
 > nothing new here, problems have been reported before, but:
 > 
 > my very first attempt - after a very long time - of booting 7.1-stable, 
 > produced
 > a panic because msk could not find its physio, by the time i had the serial 
 > console
 > attached and working, that problem disappeared :-(
 > now, after reboot, it sometimes hangs - because the net is not working, and 
 > only if
 > I unplug the ethernet, (no signs of the driver seeing this), and replug things 
 > begin
 > to work. btw, i had to set
 > 	 hw.msk.legacy_intr="1"
 > to get things working.
 > 
 > any patches for 7.1-stable to test?
 > 

If memory serve me right you have Yukon EC Ultra with 88E1149 PHY,
right? CURRENT has some stability fixes but the source wouldn't be
compiled on stable/7 yet due to KPI differences. I have plan to add
some features in next week which make it possible to use HEAD
version on stable/7.

I'm not sure the patch for 88E8040 could be applied to stable/7
but the patch has some fixes for link state handling. Would you
give it try?
http://people.freebsd.org/~yongari/msk/msk.88E8040.patch14
Note, the 88E8040 patch is not complete yet and may cause other
problems too.

-- 
Regards,
Pyun YongHyeon
From danny at cs.huji.ac.il  Fri Jan  9 14:15:15 2009
From: danny at cs.huji.ac.il (Danny Braniss)
Date: Fri Jan  9 14:15:22 2009
Subject: more marvell marvels 
In-Reply-To: <20090109121930.GJ30747@cdnetworks.co.kr> 
References: <E1LLFqi-0001Ew-4K@kabab.cs.huji.ac.il> 
	<20090109121930.GJ30747@cdnetworks.co.kr>
Message-ID: <E1LLI8n-0002QL-7Y@kabab.cs.huji.ac.il>

> On Fri, Jan 09, 2009 at 01:48:24PM +0200, Danny Braniss wrote:
>  > hi, the mb is asus P5K-VM, the onboard nic is, acccording to pciconf:
>  > 
>  > mskc0@pci0:1:0:0:       class=0x020000 card=0x81f81043 chip=0x436411ab 
>  > rev=0x12 hdr=0x00
>  >     vendor     = 'Marvell Semiconductor (Was: Galileo Technology Ltd)'
>  >     device     = '88E8056 Yukon PCI-E Gigabit Ethernet Controller'
>  >     class      = network
>  >     subclass   = ethernet
>  >     cap 01[48] = powerspec 3  supports D0 D1 D2 D3  current D0
>  >     cap 03[50] = VPD
>  >     cap 05[5c] = MSI supports 1 message, 64 bit 
>  >     cap 10[e0] = PCI-Express 1 legacy endpoint
>  > 
>  > nothing new here, problems have been reported before, but:
>  > 
>  > my very first attempt - after a very long time - of booting 7.1-stable, 
>  > produced
>  > a panic because msk could not find its physio, by the time i had the serial 
>  > console
>  > attached and working, that problem disappeared :-(
>  > now, after reboot, it sometimes hangs - because the net is not working, and 
>  > only if
>  > I unplug the ethernet, (no signs of the driver seeing this), and replug things 
>  > begin
>  > to work. btw, i had to set
>  > 	 hw.msk.legacy_intr="1"
>  > to get things working.
>  > 
>  > any patches for 7.1-stable to test?
>  > 
> 
> If memory serve me right you have Yukon EC Ultra with 88E1149 PHY,
> right?

e1000phy0: <Marvell 88E1149 Gigabit PHY> PHY 0 on miibus0
e1000phy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX-FDX, 
auto
mskc0: [ITHREAD]

>        CURRENT has some stability fixes but the source wouldn't be
> compiled on stable/7 yet due to KPI differences. I have plan to add
> some features in next week which make it possible to use HEAD
> version on stable/7.
> 
> I'm not sure the patch for 88E8040 could be applied to stable/7
> but the patch has some fixes for link state handling. Would you
> give it try?
> http://people.freebsd.org/~yongari/msk/msk.88E8040.patch14
> Note, the 88E8040 patch is not complete yet and may cause other
> problems too.

I'll try asap
thanks,
	danny

> 
> -- 
> Regards,
> Pyun YongHyeon


From ghelmer at palisadesys.com  Fri Jan  9 14:49:49 2009
From: ghelmer at palisadesys.com (Guy Helmer)
Date: Fri Jan  9 14:49:57 2009
Subject: Big problems with 7.1 locking up :-(
In-Reply-To: <E1LL6dg-0007CN-DI@dilbert.ticketswitch.com>
References: <E1LL6dg-0007CN-DI@dilbert.ticketswitch.com>
Message-ID: <49676406.9050902@palisadesys.com>

Pete French wrote:
> I have a number of HP 1U servers, all of which were running 7.0
> perfectly happily. I have been testing 7.1 in it's various incarnations
> for the last couple of months on our test server and it has performed
> perfectly.
>
> So the last two days I have been round upgrading all our servers, knowing
> that I had run the system stably on identical hardware for some time.
>
> Since then I have starte seeing machines lock up. This always happens under
> heavy disc load. When I bring the machine back up then sometimes it fails
> to fsck due to a partialy truncated inode. The locksup appear to
> be disc related - on my mysql msater machine it will come back up with
> files somewhat shorted than  those which ahve aready been transmitted to
> the slave (i.e. some data was in memory, and claimed to have been written
> to the drive, but never made it onto the disc).
>
> The only time I have seen anything useful on the screen was during one lockup
> where I got a message about a spin lock being held too long and some
> comment in parentheses about it being a turnstile lock.
>
> Help! :-(
>
> I am now downgrading all the machine to 7.0 as fast as I can - though the
> machine I am trying to compile it on has locked up once during the compile
> so I havent got anywhere so far.
>
> The machines are HP Proliant DL360 G5s - they have an embedded P400i
> RAID controller with a pair of mirrored drives connected. Each one has
> both ethernets connected, bundled using lagg and LACP.
>
>   
I can't tell whether my situation is related, but I am seeing lockups on 
SMP Supermicro servers with both older (NetBurst-ish) and current Xeon 
CPUs.  I have been dropping into the kernel debugger and getting lock 
information and process backtraces, but so far nothing has been 
conclusively identified.  I think the issue I'm seeing was introduced 
sometime between October 2 and November 24 in the RELENG_7 branch, and I 
suppose the next step is to do a binary search for the offending change.

Guy

-- 
Guy Helmer, Ph.D.
Chief System Architect
Palisade Systems, Inc.

From mike at sentex.net  Fri Jan  9 15:06:09 2009
From: mike at sentex.net (Mike Tancsa)
Date: Fri Jan  9 15:06:24 2009
Subject: Big problems with 7.1 locking up :-(
In-Reply-To: <49676406.9050902@palisadesys.com>
References: <E1LL6dg-0007CN-DI@dilbert.ticketswitch.com>
	<49676406.9050902@palisadesys.com>
Message-ID: <200901091506.n09F65sF035500@lava.sentex.ca>

At 09:49 AM 1/9/2009, Guy Helmer wrote:

>>RAID controller with a pair of mirrored drives connected. Each one has
>>both ethernets connected, bundled using lagg and LACP.
>>
>>
>I can't tell whether my situation is related, but I am seeing 
>lockups on SMP Supermicro servers with both older (NetBurst-ish) and 
>current Xeon CPUs.  I have been dropping into the kernel debugger 
>and getting lock information and process backtraces, but so far 
>nothing has been conclusively identified.  I think the issue I'm 
>seeing was introduced sometime between October 2 and November 24 in 
>the RELENG_7 branch, and I suppose the next step is to do a binary 
>search for the offending change.

Are you using the same disk controller as Peter ?  Do both of you run 
with quotas on the file system ?  By lockup, do you mean it doesnt 
respond to the network either or just anything that needs disk IO ?

         ---Mike 

From petefrench at ticketswitch.com  Fri Jan  9 15:15:16 2009
From: petefrench at ticketswitch.com (Pete French)
Date: Fri Jan  9 15:15:27 2009
Subject: Big problems with 7.1 locking up :-(
In-Reply-To: <200901091506.n09F65sF035500@lava.sentex.ca>
Message-ID: <E1LLJ4n-000Edn-Ry@dilbert.ticketswitch.com>

> Are you using the same disk controller as Peter ?  Do both of you run 
> with quotas on the file system ?  By lockup, do you mean it doesnt 
> respond to the network either or just anything that needs disk IO ?

I dont think he can be using yhe same controller, as mine is an
embedded HPO unit. they do make a separate plugin one though - P400
SAS controller.

My symptoms are that the thing locks hard and respionds to nothing, no
keypresses or anything. I am assuming that the disc is the first thing to
go though, ebcause I see data which was being written to a file and a
processes reading from that file to the network. more of the file comes
over the network than makes it phyiscally onto the disc

The only useful error I ever saw was the message about spin
lock / turnstile locks being held for too long.

-pete.
From ghelmer at palisadesys.com  Fri Jan  9 15:27:20 2009
From: ghelmer at palisadesys.com (Guy Helmer)
Date: Fri Jan  9 15:27:27 2009
Subject: Big problems with 7.1 locking up :-(
In-Reply-To: <E1LLJ4n-000Edn-Ry@dilbert.ticketswitch.com>
References: <E1LLJ4n-000Edn-Ry@dilbert.ticketswitch.com>
Message-ID: <49676CCE.30706@palisadesys.com>

Pete French wrote:
>> Are you using the same disk controller as Peter ?  Do both of you run 
>> with quotas on the file system ?  By lockup, do you mean it doesnt 
>> respond to the network either or just anything that needs disk IO ?
>>     
>
> I dont think he can be using yhe same controller, as mine is an
> embedded HPO unit. they do make a separate plugin one though - P400
> SAS controller.
>
> My symptoms are that the thing locks hard and respionds to nothing, no
> keypresses or anything. I am assuming that the disc is the first thing to
> go though, ebcause I see data which was being written to a file and a
> processes reading from that file to the network. more of the file comes
> over the network than makes it phyiscally onto the disc
>
> The only useful error I ever saw was the message about spin
> lock / turnstile locks being held for too long.
>
> -pete.
>   
OK, perhaps my issue is different then.  My symptoms seem to be a hang 
from anything that triggers a fork(), such as entering a command at a 
shell prompt or entering a user name at the console's login prompt.  
Network activity still works -- all the TCP connections stay up until I 
drop into the kernel debugger or power cycle.

Guy

-- 
Guy Helmer, Ph.D.
Chief System Architect
Palisade Systems, Inc.

From cristiano.deana at gmail.com  Fri Jan  9 16:17:36 2009
From: cristiano.deana at gmail.com (Cristiano Deana)
Date: Fri Jan  9 16:17:43 2009
Subject: cvsup freebsd 6_2 to freebsd 7_1 not upgrading?
In-Reply-To: <008b01c96f65$517a9d60$f46fd820$@com>
References: <49600E2E.7070601@avioc.org>
	<3163F769-48B0-4CFC-8842-BBBDDAE78B51@gmail.com>
	<20090105032657.GA1842@cdnetworks.co.kr> <4961FACE.4060203@avioc.org>
	<008b01c96f65$517a9d60$f46fd820$@com>
Message-ID: <d8a4930a0901090752v46fed4c8l87191ead46d3fada@mail.gmail.com>

On Mon, Jan 5, 2009 at 7:41 PM, Brian Duke <brian@box201.com> wrote:

> #make -j4 buildworld; make -j4 buildkernel; make installkernel

Use instead
make -j4 buildworld && make buildkernel && make installkernel

If any of your commands failed you were unable to know. i suppose it
failed building kernel.

-- 
Cris, member of G.U.F.I
Italian FreeBSD User Group
http://www.gufi.org/
From rapopp at marvin.eastcentral.edu  Fri Jan  9 17:27:04 2009
From: rapopp at marvin.eastcentral.edu (Reuben)
Date: Fri Jan  9 17:27:11 2009
Subject: Broken loader on 7.1-STABLE?
Message-ID: <20090109171857.GA49752@marvin.eastcentral.edu>

Good morning everyone,

I was wondering if anyone else was seeing loader (v1.02) break after updating from 7.1-RELEASE to 7.1-STABLE.  After performing the prescribed updating procedure (via the handbook), the system will go through the normal steps and after the boot menu will present the following error:

Can't work out which disk we are booting from.
Guessed BIOS device 0xffffffff not found by probes, defaulting to disk0 

According to the bugbusting page on the FreeBSD wiki there's two issues at work that cause this behavior; patches were committed to HEAD/RELENG earlier last year in Mar and Aug.  Up until now I've never come across this problem in 6.x or 7.0.  In doing a little research I've come across a few older threads via google where it was believed that the problem was caused by improper CFLAGS in make.conf.  I've commented mine out and rebuilt things.. with the same end result.  In fact, if it's any help, my CFLAGS declaration in make.conf is taken verbatim from the /usr/share/examples/etc/make.conf.  Furthermore, on selecting option 6 from the boot menu (escape to loader prompt), the system [I'm assuming] crashes displaying a blinking ASCII pattern from which only a hard reboot will work.

FWIW, this is a fairly plain system.. nothing special in sysctl.conf or loader.conf, and the kernel is pretty stock as well (more or less GENERIC with my sound device and pf).

A temporary fix for me was to copy over loader.old to loader in /boot.

Any comments or suggestions would be greatly appreciated.  All I ask is to please CC me in the reply to the list as I don't currently subscribe to -stable.

TIA
Reuben A. Popp

-- 

I build no system. I ask an end to privilege, the abolition of slavery, equality of rights, and the reign of law. Justice, nothing else. That is the alpha and omega of my argument.

-- Pierre-Joseph Proudhon
From hawei at free.fr  Fri Jan  9 18:38:14 2009
From: hawei at free.fr (Harald Weis)
Date: Fri Jan  9 18:38:25 2009
Subject: Medical database Vidal
Message-ID: <20090109184126.GA2501@pollux2.free.local.net>

When mounting a (cd9660) CD-ROM of the medical database Vidal in order
to try an installation with wine, I've discovered that I cannot see
two files (visible under Windows), setup.exe and some .ini file the
full name of which I have forgotten now, while I can perfectly see
the merlin-vcd-data.zip file in the dat directory.

How on Unix earth is this possible ??

Harald  
-- 
FreeBSD 7.0-RELEASE FreeBSD 7.0-RELEASE #0: Sun Feb 24 19:59:52 UTC 2008
From torfinn.ingolfsen at broadpark.no  Fri Jan  9 19:25:00 2009
From: torfinn.ingolfsen at broadpark.no (Torfinn Ingolfsen)
Date: Fri Jan  9 19:25:08 2009
Subject: ACPI support?
In-Reply-To: <4967045D.30109@bulinfo.net>
References: <49633C85.3090507@bulinfo.net>
	<20090108204311.c9700e91.torfinn.ingolfsen@broadpark.no>
	<4967045D.30109@bulinfo.net>
Message-ID: <20090109202457.19d0fc1a.torfinn.ingolfsen@broadpark.no>

On Fri, 09 Jan 2009 10:01:33 +0200
Krassimir Slavchev <krassi@bulinfo.net> wrote:

> I have found that thread.

FWIW, I started a new thread[1] on freebsd-mobile, to update the status
now after FreeBSD 7.1 has been released

> The problem may be with allocating resources by ACPI PCI-PCI bridge.
> There is a way to set needed values:
> http://lists.freebsd.org/pipermail/freebsd-acpi/2008-May/004905.html

Interesting. For my laptop, it seems that these bridges have the
problem:
pcib2: <ACPI PCI-PCI bridge> irq 17 at device 28.0 on pci0
pcib2:   domain            0
pcib2:   secondary bus     2
pcib2:   subordinate bus   2
pcib2:   I/O decode        0x0-0x0
pcib2:   no prefetched decode
pci2: <ACPI PCI bus> on pcib2
pci2: domain=0, physical bus=2
pcib3: <ACPI PCI-PCI bridge> irq 16 at device 28.1 on pci0
pcib3:   domain            0
pcib3:   secondary bus     3
pcib3:   subordinate bus   3
pcib3:   I/O decode        0x0-0x0
pcib3:   no prefetched decode
pci3: <ACPI PCI bus> on pcib3
pci3: domain=0, physical bus=3

and also these:

pcib4: <ACPI PCI-PCI bridge> irq 18 at device 28.2 on pci0
pcib4:   domain            0
pcib4:   secondary bus     4
pcib4:   subordinate bus   4
pcib4:   I/O decode        0x0-0x0
pcib4:   no prefetched decode
pci4: <ACPI PCI bus> on pcib4
pci4: domain=0, physical bus=4

pcib5: <ACPI PCI-PCI bridge> irq 19 at device 28.3 on pci0
pcib5:   domain            0
pcib5:   secondary bus     5
pcib5:   subordinate bus   7
pcib5:   I/O decode        0x0-0x0
pcib5:   no prefetched decode
pcib5: could not get PCI interrupt routing table for \\_SB_.PCI0.RP04 - AE_NOT_FOUND
pci5: <ACPI PCI bus> on pcib5
pci5: domain=0, physical bus=5

bge0 (the wired interface is on pcib4:

bge0: <Broadcom NetXtreme Gigabit Ethernet Controller, ASIC rev. 0x4201> irq 18 at device 0.0 on pci4
pcib4: bge0 requested unsupported memory range 0-0xffffffff (decoding 0-0, 0-0)
bge0: 0x10000 bytes of rid 0x10 res 3 failed (0, 0xffffffff).
bge0: couldn't map memory
device_attach: bge0 attach returned 6

and wpi0 (the wireless) is on pcib3:

wpi0: <Intel(R) PRO/Wireless 3945ABG> irq 17 at device 0.0 on pci3
wpi0: Driver Revision 20071127
pcib3: wpi0 requested unsupported memory range 0-0xffffffff (decoding 0-0, 0-0)
wpi0: 0x1000 bytes of rid 0x10 res 3 failed (0, 0xffffffff).
wpi0: could not allocate memory resource
device_attach: wpi0 attach returned 6

With acpi disabled, the bridges shoiw up like this:
pcib2: <PCI-PCI bridge> irq 17 at device 28.0 on pci0
pcib2:   domain            0
pcib2:   secondary bus     2
pcib2:   subordinate bus   2
pcib2:   I/O decode        0xf000-0xfff
pcib2:   no prefetched decode
pci2: <PCI bus> on pcib2
pci2: domain=0, physical bus=2
pcib3: <PCI-PCI bridge> irq 16 at device 28.1 on pci0
pcib3:   domain            0
pcib3:   secondary bus     3
pcib3:   subordinate bus   3
pcib3:   I/O decode        0xf000-0xfff
pcib3:   memory decode     0xc8200000-0xc82fffff
pcib3:   no prefetched decode
pci3: <PCI bus> on pcib3
pci3: domain=0, physical bus=3

pcib4: <PCI-PCI bridge> irq 18 at device 28.2 on pci0
pcib4:   domain            0
pcib4:   secondary bus     4
pcib4:   subordinate bus   4
pcib4:   I/O decode        0xf000-0xfff
pcib4:   memory decode     0xc8300000-0xc83fffff
pcib4:   no prefetched decode
pci4: <PCI bus> on pcib4
pci4: domain=0, physical bus=4

pcib5: <PCI-PCI bridge> irq 19 at device 28.3 on pci0
pcib5:   domain            0
pcib5:   secondary bus     5
pcib5:   subordinate bus   5
pcib5:   I/O decode        0xf000-0xfff
pcib5:   no prefetched decode
pci5: <PCI bus> on pcib5
pci5: domain=0, physical bus=5

bge with acpi disabled:

bge0: <Broadcom NetXtreme Gigabit Ethernet Controller, ASIC rev. 0x4201> mem 0xc8300000-0xc830ffff irq 17 at device 0.0 on pci4
bge0: Reserved 0x10000 bytes for rid 0x10 type 3 at 0xc8300000
bge0: attempting to allocate 1 MSI vectors (8 supported)
msi: routing MSI IRQ 256 to vector 48
bge0: using IRQ 256 for MSI
miibus0: <MII bus> on bge0
brgphy0: <BCM5750 10/100/1000baseTX PHY> PHY 1 on miibus0
brgphy0: OUI 0x000818, model 0x0018, rev. 0
brgphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto
bge0: bpf attached
bge0: Ethernet address: 00:16:36:54:a9:ae
bge0: [MPSAFE]
bge0: [ITHREAD]

wpi with acpi disabled:
wpi0: <Intel(R) PRO/Wireless 3945ABG> mem 0xc8200000-0xc8200fff irq 17 at device 0.0 on pci3
wpi0: Driver Revision 20071127
wpi0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xc8200000
wpi0: Hardware Revision (0x1)
wpi0: Regulatory Domain: MoW2
wpi0: Hardware Type: B
wpi0: Hardware Revision: ?
wpi0: SKU does support 802.11a
wpi0: bpf attached
wpi0: Ethernet address: 00:13:02:3e:d4:ce
wpi0: bpf attached
wpi0: bpf attached
ioapic0: Assigning PCI IRQ 17 to local APIC 0
ioapic0: routing intpin 17 (PCI IRQ 17) to vector 60
wpi0: [MPSAFE]
wpi0: [ITHREAD]
wpi0: 11a rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps
wpi0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps
wpi0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps

Perhaps I should try to patch my pci too.

References:
1)
http://lists.freebsd.org/pipermail/freebsd-mobile/2009-January/011294.html
-- 
Torfinn

From ben at morrow.me.uk  Fri Jan  9 19:37:11 2009
From: ben at morrow.me.uk (Ben Morrow)
Date: Fri Jan  9 19:37:18 2009
Subject: Medical database Vidal
In-Reply-To: <20090109184126.GA2501@pollux2.free.local.net>
Message-ID: <20090109191007.GA6625@osiris.mauzo.dyndns.org>

In article <20090109184126.GA2501@pollux2.free.local.net> you write:
> When mounting a (cd9660) CD-ROM of the medical database Vidal in order
> to try an installation with wine, I've discovered that I cannot see
> two files (visible under Windows), setup.exe and some .ini file the
> full name of which I have forgotten now, while I can perfectly see
> the merlin-vcd-data.zip file in the dat directory.
> 
> How on Unix earth is this possible ??

As you may already know, native ISO9660 (well, level 1, which is what is
usually used) only supports very limited filenames (8.3, uppercase,
every file must have a version number). As a result, a number of
extensions have been developed: Unix systems use a system called Rock
Ridge, which supports long filenames and the usual POSIX metadata; Win32
systems use a system called Joliet, which uses Unicode filenames and
supports vfat-ish metadata; Apple have their own system which supports
HFSish metadata. 

Some CDs are built with more than one extension system, in which case
there are now several completely independant directory trees on the
disc. It's perfectly possible to make the different trees contain
different files; indeed, it's possible to make the same file appear to
contain different contents under different systems. See e.g. the -hide,
-hide-joliet, -hide-hfs options to mkisofs.

I would guess that your CD has both Rock Ridge and Joliet extensions,
and that the creator has hidden the Win32-specific files from the Unix
directory tree because they thought they wouldn't be useful. If for some
reason you need to see the CD as a Win32 machine would, you can use the
-r option to mount_cd9660.

Ben

From eugen at grosbein.pp.ru  Fri Jan  9 19:50:42 2009
From: eugen at grosbein.pp.ru (Eugene Grosbein)
Date: Fri Jan  9 19:50:48 2009
Subject: New snd_hda import and very low mixer volume
Message-ID: <20090109193409.GA1443@grosbein.pp.ru>

Hi!

I've just upgraded from 7.1-PRERELEASE to 7.1-STABLE via source upgrade
and divcovered that my sound stopped working. I was aware about
recent HDA driver update and tried to switch hw.snd.default_unit
back and forth but that did not help.

Finally I've realised that's just mixer values changed their meaning:
now I can't hear anything at levels 50:50 of both 'mixer pcm'
and 'mixer vol' and have to increase values significantly
to make sound: upto 85:85 of both.

Isn't it a bug?
I've Intel D975XBX motherboard with onboard Azalia HDA,
default unit is 0:

$ cat /dev/sndstat
FreeBSD Audio Driver (newpcm: 32bit 2007061600/i386)
Installed devices:
pcm0: <HDA Sigmatel STAC9221D PCM #0 Analog> at cad 2 nid 1 on hdac0
[MPSAFE] (1p:2v/1r:1v channels duplex default)
pcm1: <HDA Sigmatel STAC9221D PCM #1 Digital> at cad 2 nid 1 on hdac0
[MPSAFE] (1p:1v/0r:0v channels)

Eugene Grosbein
From rblayzor.bulk at inoc.net  Fri Jan  9 19:55:32 2009
From: rblayzor.bulk at inoc.net (Robert Blayzor)
Date: Fri Jan  9 19:55:39 2009
Subject: Big problems with 7.1 locking up :-(
In-Reply-To: <E1LL6dg-0007CN-DI@dilbert.ticketswitch.com>
References: <E1LL6dg-0007CN-DI@dilbert.ticketswitch.com>
Message-ID: <042FE04A-2F8D-47DD-8454-7BBA3791D7A8@inoc.net>

On Jan 8, 2009, at 8:58 PM, Pete French wrote:
> I have a number of HP 1U servers, all of which were running 7.0
> perfectly happily. I have been testing 7.1 in it's various  
> incarnations
> for the last couple of months on our test server and it has performed
> perfectly.


I noticed a problem with 7.0 on a couple of Dell servers.  Not sure if  
this is related but when our system "froze" the box was pingable, and  
you could switch virtual consoles... however, you could not type  
anything on the screen or connect to any sockets.  Num-lock would  
still work so the box wasn't solidly frozen.  This used to happen a  
couple of times every week or two.  We've since then compiled the  
kernel under the BSD scheduler to rule that out, and so far so good.   
(our box was a Dell PE1750, 2GB of RAM, amr RAID controller, bge  
network driver)  The primary application was just ntpd and apache with  
mpm_worker & threads.

Since ULE is now default in 7.1 and not in 7.0, perhaps you can try  
that?

-- 
Robert Blayzor, BOFH
INOC, LLC
rblayzor@inoc.net
http://www.inoc.net/~rblayzor/



From petefrench at ticketswitch.com  Fri Jan  9 21:43:47 2009
From: petefrench at ticketswitch.com (Pete French)
Date: Fri Jan  9 21:43:53 2009
Subject: Big problems with 7.1 locking up :-(
In-Reply-To: <042FE04A-2F8D-47DD-8454-7BBA3791D7A8@inoc.net>
Message-ID: <E1LLP8j-000H2s-H5@dilbert.ticketswitch.com>

> Since ULE is now default in 7.1 and not in 7.0, perhaps you can try  
> that?

Actually you might be on to something there.... one of the main differences
between out test GL360 and the live ones is that the test one has less
cores in it, and is under less load. So multiprocessing problems may well
show up on the live where they wont on the test box. I shall try
building a kernel with the BSD scheduler adn see what happens there.
probbaly not today, as am loathe to cause anymore downtime right now.

thanks,

-pete.

From matheus at eternamente.info  Sat Jan 10 00:48:03 2009
From: matheus at eternamente.info (Nenhum_de_Nos)
Date: Sat Jan 10 00:48:10 2009
Subject: mini itx from via - acpi issues on 7.1R
Message-ID: <b57c7e45691db88edf99d3ca84cbf9d3.squirrel@lamneth>

hail,

I'm running 7.1R (tried 8.0-CURRENT also) on a via mini itx (dmesg bellow)
and if I load acpi module, I have no lan. it appears, I can set IP, even
the led would blink when I ping. but no signal of bits on the other pc
whatsoever. tcpdump sees nothing in both endpoints. if acpi is not loaded,
vr0 works as it should.

i really think acpi would help this box, on power purposes, so here I am
asking.

thanks,

matheus

ps: should I mail acpi@ with, or instead ?

$ dmesg
Copyright (c) 1992-2009 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
	The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 7.1-RELEASE #0: Thu Jan  1 14:37:25 UTC 2009
    root@logan.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC
Timecounter "i8254" frequency 1193182 Hz quality 0
CPU: Transmeta(tm) Crusoe(tm) Processor TM5700 (798.13-MHz 586-class CPU)
  Origin = "GenuineTMx86"  Id = 0x543  Stepping = 3
  Features=0x84893f<FPU,VME,DE,PSE,TSC,MSR,CX8,SEP,CMOV,PN,MMX>
real memory  = 117374976 (111 MB)
avail memory = 100737024 (96 MB)
kbd1 at kbdmux0
ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413)
pcib0: <Host to PCI bridge> pcibus 0 on motherboard
pir0: <PCI Interrupt Routing Table: 5 Entries> on motherboard
pci0: <PCI bus> on pcib0
pci0: <memory, RAM> at device 0.1 (no driver attached)
pci0: <memory, RAM> at device 0.2 (no driver attached)
pci0: <memory, RAM> at device 0.3 (no driver attached)
uhci0: <VIA 83C572 USB controller> port 0xe000-0xe01f irq 15 at device 9.0
on pci0
uhci0: [GIANT-LOCKED]
uhci0: [ITHREAD]
usb0: <VIA 83C572 USB controller> on uhci0
usb0: USB revision 1.0
uhub0: <VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb0
uhub0: 2 ports with 2 removable, self powered
uhci1: <VIA 83C572 USB controller> port 0xe100-0xe11f irq 5 at device 9.1
on pci0
uhci1: [GIANT-LOCKED]
uhci1: [ITHREAD]
usb1: <VIA 83C572 USB controller> on uhci1
usb1: USB revision 1.0
uhub1: <VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb1
uhub1: 2 ports with 2 removable, self powered
ehci0: <VIA VT6202 USB 2.0 controller> mem 0xe8131000-0xe81310ff irq 10 at
device 9.2 on pci0
ehci0: [GIANT-LOCKED]
ehci0: [ITHREAD]
usb2: EHCI version 1.0
usb2: companion controllers, 2 ports each: usb0 usb1
usb2: <VIA VT6202 USB 2.0 controller> on ehci0
usb2: USB revision 2.0
uhub2: <VIA EHCI root hub, class 9/0, rev 2.00/1.00, addr 1> on usb2
uhub2: 4 ports with 4 removable, self powered
vgapci0: <VGA-compatible display> port 0xe200-0xe2ff mem
0xe0000000-0xe7ffffff,0xe8120000-0xe812ffff irq 11 at device 13.0 on pci0
isab0: <PCI-ISA bridge> at device 17.0 on pci0
isa0: <ISA bus> on isab0
atapci0: <VIA 8231 UDMA100 controller> port
0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xe300-0xe30f at device 17.1 on pci0
ata0: <ATA channel 0> on atapci0
ata0: [ITHREAD]
ata1: <ATA channel 1> on atapci0
ata1: [ITHREAD]
pci0: <bridge> at device 17.4 (no driver attached)
vr0: <VIA VT6102 Rhine II 10/100BaseTX> port 0xe600-0xe6ff mem
0xe8130000-0xe81300ff irq 15 at device 18.0 on pci0
vr0: Quirks: 0x0
vr0: Revision: 0x51
miibus0: <MII bus> on vr0
ukphy0: <Generic IEEE 802.3u media interface> PHY 1 on miibus0
ukphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
vr0: Ethernet address: 00:11:85:e3:2a:17
vr0: [ITHREAD]
cpu0 on motherboard
pmtimer0 on isa0
orm0: <ISA Option ROMs> at iomem 0xc0000-0xc8fff,0xcc000-0xd5fff pnpid
ORM0000 on isa0
atkbdc0: <Keyboard controller (i8042)> at port 0x60,0x64 on isa0
atkbd0: <AT Keyboard> irq 1 on atkbdc0
kbd0 at atkbd0
atkbd0: [GIANT-LOCKED]
atkbd0: [ITHREAD]
ppc0: parallel port not found.
sc0: <System console> at flags 0x100 on isa0
sc0: VGA <16 virtual consoles, flags=0x300>
sio0: configured irq 4 not in bitmap of probed irqs 0
sio0: port may not be enabled
sio0: configured irq 4 not in bitmap of probed irqs 0
sio0: port may not be enabled
sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0
sio0: type 8250 or not responding
sio0: [FILTER]
sio1: configured irq 3 not in bitmap of probed irqs 0
sio1: port may not be enabled
vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0
unknown: <PNP0303> can't assign resources (port)
unknown: <PNP0c01> can't assign resources (memory)
Timecounter "TSC" frequency 798129274 Hz quality 800
Timecounters tick every 1.000 msec
ad0: DMA limited to UDMA33, device found non-ATA66 cable
ad0: 19464MB <SAMSUNG SV2044D MM200-53> at ata0-master UDMA33
Trying to mount root from ufs:/dev/ad0s2a

vr0@pci0:0:18:0:	class=0x020000 card=0x01021106 chip=0x30651106 rev=0x51
hdr=0x00
    vendor     = 'VIA Technologies Inc'
    device     = 'VT6102 Rhine II PCI Fast Ethernet Controller||Used by
GERICOM in laptop Webengine Advanced'
    class      = network
    subclass   = ethernet


-- 
We will call you cygnus,
The God of balance you shall be

From barbara.xxx1975 at libero.it  Sat Jan 10 03:07:27 2009
From: barbara.xxx1975 at libero.it (Barbara)
Date: Sat Jan 10 03:07:49 2009
Subject: Lock enabling onboard lan (Attansic L1 GbE) on 7.1-PRERELEASE
Message-ID: <21490254.1241291231556844215.JavaMail.defaultUser@defaultHost>

>On Mon, Jan 05, 2009 at 11:36:54AM +0100, Barbara wrote:
>
>[...]
>
> > I've 
tried all the thing you've suggested with 
> > the same result.
> > I've 
disabled "LAN Option ROM", but it seems that I don't have 
> > the other 
options you mentioned.
> > I've downloaded and burned the 7.1-RELEASE dvd 
> > 
and tried to boot from it, but it hangs at the same point.
> > Finally I've 
tried 
> > booting a CURRENT snapshot cd (8.0-CURRENT-200812) and I was able to 
properly 
> > configure the device in sysinstall.
> > Any idea about the 
problem?
>
>No, there is no source code differences between CURRENT and 7.1-
RELEASE.
>
> > I've installed 
> > from 7.0 and I have another NIC, but being 
now age in GENERIC, I hope it will 
> > not cause troubles to other people 
installing for the first time.
> > Anyway thank 
> > you for now, and ask me if 
there is something that I can do to fix the problem 
> > like more tests, 
patches, etc.
> > 
>
>Would try the following WIP version?
>http://people.
freebsd.org/~yongari/age/if_age.c
>http://people.freebsd.
org/~yongari/age/if_agereg.h
>I have no longer access to L1 hardware so I don't 
know whether it
>helps or not.
>
>-- 
>Regards,
>Pyun YongHyeon

Well, it 
works!
As I've said, it's not a real problem for me, but I'm so sorry about not 
having tested before so it could be merged before 7.1-RELEASE, but I had it 
disabled and nearly forgot about that.
Please, feel free to ask whenever you 
want if you want me doing tests on that NIC.

Thanks
Barbara

From drosih at rpi.edu  Sat Jan 10 03:19:45 2009
From: drosih at rpi.edu (Garance A Drosihn)
Date: Sat Jan 10 03:19:57 2009
Subject: Big problems with 7.1 locking up :-(
In-Reply-To: <E1LL6dg-0007CN-DI@dilbert.ticketswitch.com>
References: <E1LL6dg-0007CN-DI@dilbert.ticketswitch.com>
Message-ID: <p06240801c58daff9e513@[128.113.24.47]>

At 1:58 AM +0000 1/9/09, Pete French wrote:
>I have a number of HP 1U servers, all of which were running 7.0
>perfectly happily. I have been testing 7.1 in it's various incarnations
>for the last couple of months on our test server and it has performed
>perfectly.
>
>So the last two days I have been round upgrading all our servers, knowing
>that I had run the system stably on identical hardware for some time.
>
>Since then I have starte seeing machines lock up. This always happens
>under heavy disc load. When I bring the machine back up then sometimes
>it fails to fsck due to a partialy truncated inode. The locksup appear
>to be disc related  [...]

One of my friends is also having trouble with lockups on two machines
he had upgraded to 7.1.  Also seems to be related to heavy disk I/O,
although I'm not sure the symptoms are the same as what you report.
Both machines had been running 7.0-release without trouble.  On at
least one of the systems, he's also working with (what I consider)
very large file systems (over 2 TB).  Both machines are using a 3ware
controller with its RAID.

I realize that isn't much to go on, but it suggests that there is
some problem wider than just your (Pete's) usage.  I think his
situation is such that lockups like this are simply not acceptable,
and the last I heard he was reverting back to 7.0-release.

-- 
Garance Alistair Drosehn            =   gad@gilead.netel.rpi.edu
Senior Systems Programmer           or  gad@freebsd.org
Rensselaer Polytechnic Institute    or  drosih@rpi.edu
From drosih at rpi.edu  Sat Jan 10 03:27:13 2009
From: drosih at rpi.edu (Garance A Drosihn)
Date: Sat Jan 10 03:27:20 2009
Subject: Big problems with 7.1 locking up :-(
In-Reply-To: <042FE04A-2F8D-47DD-8454-7BBA3791D7A8@inoc.net>
References: <E1LL6dg-0007CN-DI@dilbert.ticketswitch.com>
	<042FE04A-2F8D-47DD-8454-7BBA3791D7A8@inoc.net>
Message-ID: <p06240802c58db5953598@[128.113.24.47]>

At 2:39 PM -0500 1/9/09, Robert Blayzor wrote:
>On Jan 8, 2009, at 8:58 PM, Pete French wrote:
>>I have a number of HP 1U servers, all of which were running 7.0
>>perfectly happily. I have been testing 7.1 in it's various incarnations
>>for the last couple of months on our test server and it has performed
>>perfectly.
>
>
>I noticed a problem with 7.0 on a couple of Dell servers.  [...] 
>We've since then compiled the kernel under the BSD scheduler to rule 
>that out, and so far so good.
>
>Since ULE is now default in 7.1 and not in 7.0, perhaps you can try that?

FWIW, the other guy I know who is having this problem had already
switched to using ULE under 7.0-release, and did not have any
problems with it.  So *his* problem was probably not related to
SCHED_ULE, unless something has recently changed there.

Turns out he hasn't reverted back to 7.0-release just yet, so he's
going to try SCHED_4BSD and see if that helps his situation.

-- 
Garance Alistair Drosehn            =   gad@gilead.netel.rpi.edu
Senior Systems Programmer           or  gad@freebsd.org
Rensselaer Polytechnic Institute    or  drosih@rpi.edu
From mike at vintners.net  Sat Jan 10 03:45:57 2009
From: mike at vintners.net (Mike Lempriere)
Date: Sat Jan 10 03:46:04 2009
Subject: mergemaster broken -- take 2
In-Reply-To: <200901081047.n08Alg2h000825@lurza.secnetix.de>
References: <200901081047.n08Alg2h000825@lurza.secnetix.de>
Message-ID: <496819F0.9@vintners.net>

Thanks everyone for the advice -- I got it working this time just fine.  
Works much better when one follows the directions accurately instead of 
by memory -- the bottom line is that this time I remembered to jot down 
the commands before heading downtown to the machine rack room where 
there's no browser access...  I started over and followed UPDATING:
  cd /usr/obj
  rm -R *
  cd /usr/src
  rm -R *
  cvsup -g -L 2 -h cvsup10.freebsd.org |& tee /root/cvsup-090108.out
  make buildworld |& tee /root/make-buildworld-090108.out
  make kernel KERNCONF=GENERIC |& tee /root/make-kernel-090108.out
  users
  ps ax | more
  shutdown -r now
  4 (single user)
  fsck -p
  mount -u /
  mount -a
  cd /usr/src
  mergemaster -p
  make installworld |& tee /root/make-installworld-090108.out
  make delete-old (forgot to do tee redirect)
  mergemaster -i (did not do tee redirect)
  shutdown -r now

Oliver Fromme wrote:
> Greg Byshenk wrote:
>  > Andrei Kolu wrote:
>  > > Mike Lempriere wrote:
>  > > > Hi folks -- sorry to be a nag, but my main production system is barely 
>  > > > limping along on an old kernel with mismatched libraries.  I have no 
>  > > > idea what else to do -- please help!
>  > > > ---
>  > > > I'm upgrading 5-stable (was at 5.5) to 6-stable, in preparation for 
>  > > > 6-stable to 7-stable.
>  > > > No problems with cvsup, make buildworld, make installworld, make 
>  > > > buildkernel, mergemaster -p.
>  > > > make installkernel, boot to single user.  Then mergemaster -- blammo:
>
> As others have pointed out, the order is wrong, which caused
> the problem Mike is seeing.
>
> The correct order is listed in /usr/src/UPDATING.
>
>  > The reasons for the other methods being wrong are (as I understand them):
>  > 
>  > - You should build your new world before building your new kernel, as
>  >   it may be the case that some aspects of the new kernel build are
>  >   dependent upon aspects of the new world build.  If you build your
>  >   new kernel before building your new world, you will be building 
>  >   your new kernel against the old world.
>
> In particular, building the kernel uses the new toolchain
> (i.e. compiler, linker, make(1) binary and so on) that was
> built in /usr/obj during buildworld.  That's why you have
> to do buildworld first, then "make kernel".
>
>  > - You should install your new kernel before installing your new world,
>  >   as it can be the case that some aspects of the new world will not be
>  >   understood by your old kernel. A new kernel should always be
>  >   compatible with an old userland/world, but an old kernel may not 
>  >   always be compatible with a new userland/world.
>
> That's correct.  Note that your kernel config should include
> the appropriate "options COMPAT_*" lines if you update across
> a major version boundary, e.g. "options_COMPAT_FREEBSD6" when
> you update from 6.x to 7.x.  The GENERIC kernel already has
> those.
>
>  > > NOTE: I do not reboot my system until everything is updated. Why it is 
>  > > necessary to boot new kernel and then upgrade world is beyound me..YMMW
>  > 
>  > - I suppose that it is not strictly necessary to reboot between 
>  >   installing kernel and world, but I always do so.
>
> It _is_ necessary.  If you don't reboot, you're still running
> the old kernel which might not be able to support new binaries
> and libraries that installworld will install on your system.
>
> For example, there may be new syscalls that the new binaries
> will try to use, but the old kernel doesn't know about them.
> It doesn't happen often, so you can get away without rebooting
> most of the time.  But it's risky, especially when updating
> across major versions.  So the recommendation is to always
> reboot after installing the new kernel and before performing
> the "installworld".
>
> It's also important that "installworld" is the last step
> (except for mergemaster), because this is the point of no
> return.  As long as you still have the old userland (world),
> you can still boot the old kernel and everything is fine.
> You can start all over froms cratch, if necessary.
> But as soon as you have started "installworld", your system
> will not be able to work with the old kernel anymore.
>
> And remember:  Always make a backup before you start to
> update.  And verify that the backup works.  Better safe
> than sorry.
>
> Best regards
>    Oliver
>
>   

-- 
Mike Lempriere- Home: mike@vintners.net  Phone: 206-780-2146
Cellphone: 206-200-5902;  text pager: mikelemp@tmail.com

From dougb at FreeBSD.org  Sat Jan 10 04:12:14 2009
From: dougb at FreeBSD.org (Doug Barton)
Date: Sat Jan 10 04:12:21 2009
Subject: 2 (very old) bugs?
In-Reply-To: <EFD58FB6-55C8-4903-BCB1-1C9E4852C271@diablotin.fr>
References: <EFD58FB6-55C8-4903-BCB1-1C9E4852C271@diablotin.fr>
Message-ID: <496819DB.1030601@FreeBSD.org>

Yannick Cadin wrote:
> Hi everybody,
> 
> Is someone can confirm me that there are 2 bugs never fixed:
> 
> - first in the stat command. Only with the -x option. If you execute
> stat -x on /tmp or /usr/bin/passwd parameters for example, the numeric
> representation of mode is wrong. The "special" bits are always 0. No
> suid-bit, no sticky bit!

Our version of stat(1) is essentially an exact duplicate of the code
from NetBSD. I imported this originally, but I have not not had time
to merge changes for a while now. If anyone is interested in taking
this on have a look at:

http://cvsweb.netbsd.org/bsdweb.cgi/src/usr.bin/stat/

If you get stuck with something please ask for help on -hackers first.
If you get a patch against HEAD I will be glad to take a look at it,
and commit it if appropriate.


hth,

Doug

-- 

    This .signature sanitized for your protection

From dougb at FreeBSD.org  Sat Jan 10 04:14:20 2009
From: dougb at FreeBSD.org (Doug Barton)
Date: Sat Jan 10 04:14:27 2009
Subject: mergemaster broken -- take 2
In-Reply-To: <496819F0.9@vintners.net>
References: <200901081047.n08Alg2h000825@lurza.secnetix.de>
	<496819F0.9@vintners.net>
Message-ID: <49681A59.20002@FreeBSD.org>

Mike Lempriere wrote:
> Thanks everyone for the advice -- I got it working this time just fine. 
> Works much better when one follows the directions accurately instead of
> by memory. 

W00t!

:)

-- 

    This .signature sanitized for your protection

From ben at morrow.me.uk  Sat Jan 10 04:53:00 2009
From: ben at morrow.me.uk (Ben Morrow)
Date: Sat Jan 10 04:53:08 2009
Subject: mergemaster broken -- take 2
In-Reply-To: <496819F0.9@vintners.net>
References: <200901081047.n08Alg2h000825@lurza.secnetix.de>
Message-ID: <20090110045234.GA43254@osiris.mauzo.dyndns.org>

In article <496819F0.9@vintners.net> you write:
>   cvsup -g -L 2 -h cvsup10.freebsd.org |& tee /root/cvsup-090108.out
>   make buildworld |& tee /root/make-buildworld-090108.out
>   make kernel KERNCONF=GENERIC |& tee /root/make-kernel-090108.out

You know about script(1) I take it? It makes keeping a log like this
much easier.

Ben

From pyunyh at gmail.com  Sat Jan 10 07:41:35 2009
From: pyunyh at gmail.com (Pyun YongHyeon)
Date: Sat Jan 10 07:41:42 2009
Subject: Lock enabling onboard lan (Attansic L1 GbE) on 7.1-PRERELEASE
In-Reply-To: <21490254.1241291231556844215.JavaMail.defaultUser@defaultHost>
References: <21490254.1241291231556844215.JavaMail.defaultUser@defaultHost>
Message-ID: <20090110074120.GM30747@cdnetworks.co.kr>

On Sat, Jan 10, 2009 at 04:07:24AM +0100, Barbara wrote:

[...]

 > >Would try the following WIP version?
 > >http://people.
 > freebsd.org/~yongari/age/if_age.c
 > >http://people.freebsd.
 > org/~yongari/age/if_agereg.h
 > >I have no longer access to L1 hardware so I don't 
 > know whether it
 > >helps or not.
 > >
 > >-- 
 > >Regards,
 > >Pyun YongHyeon
 > 
 > Well, it 
 > works!
 > As I've said, it's not a real problem for me, but I'm so sorry about not 
 > having tested before so it could be merged before 7.1-RELEASE, but I had it 
 > disabled and nearly forgot about that.
 > Please, feel free to ask whenever you 
 > want if you want me doing tests on that NIC.
 > 

I'm confused, the WIP version works whereas age(4) in 7.1-RELEASE
didn't work right?
If the WIP version works, would you show me the output of verbose
boot message?

-- 
Regards,
Pyun YongHyeon
From danny at cs.huji.ac.il  Sat Jan 10 10:39:59 2009
From: danny at cs.huji.ac.il (Danny Braniss)
Date: Sat Jan 10 10:40:07 2009
Subject: more marvell marvels 
In-Reply-To: <20090109121930.GJ30747@cdnetworks.co.kr> 
References: <E1LLFqi-0001Ew-4K@kabab.cs.huji.ac.il> 
	<20090109121930.GJ30747@cdnetworks.co.kr>
Message-ID: <E1LLbG1-000CZ6-IS@kabab.cs.huji.ac.il>

> On Fri, Jan 09, 2009 at 01:48:24PM +0200, Danny Braniss wrote:
>  > hi, the mb is asus P5K-VM, the onboard nic is, acccording to pciconf:
>  > 
>  > mskc0@pci0:1:0:0:       class=0x020000 card=0x81f81043 chip=0x436411ab 
>  > rev=0x12 hdr=0x00
>  >     vendor     = 'Marvell Semiconductor (Was: Galileo Technology Ltd)'
>  >     device     = '88E8056 Yukon PCI-E Gigabit Ethernet Controller'
>  >     class      = network
>  >     subclass   = ethernet
>  >     cap 01[48] = powerspec 3  supports D0 D1 D2 D3  current D0
>  >     cap 03[50] = VPD
>  >     cap 05[5c] = MSI supports 1 message, 64 bit 
>  >     cap 10[e0] = PCI-Express 1 legacy endpoint
>  > 
>  > nothing new here, problems have been reported before, but:
>  > 
>  > my very first attempt - after a very long time - of booting 7.1-stable, 
>  > produced
>  > a panic because msk could not find its physio, by the time i had the serial 
>  > console
>  > attached and working, that problem disappeared :-(
>  > now, after reboot, it sometimes hangs - because the net is not working, and 
>  > only if
>  > I unplug the ethernet, (no signs of the driver seeing this), and replug things 
>  > begin
>  > to work. btw, i had to set
>  > 	 hw.msk.legacy_intr="1"
>  > to get things working.
>  > 
>  > any patches for 7.1-stable to test?
>  > 
> 
> If memory serve me right you have Yukon EC Ultra with 88E1149 PHY,
> right? CURRENT has some stability fixes but the source wouldn't be
> compiled on stable/7 yet due to KPI differences. I have plan to add
> some features in next week which make it possible to use HEAD
> version on stable/7.
> 
> I'm not sure the patch for 88E8040 could be applied to stable/7
> but the patch has some fixes for link state handling. Would you
> give it try?
> http://people.freebsd.org/~yongari/msk/msk.88E8040.patch14
> Note, the 88E8040 patch is not complete yet and may cause other
> problems too.
> 

tried to apply patches, but if_mskreg.h patches failed, and hand stitching
didn't help (I have 7.1-Stable)

danny

> -- 
> Regards,
> Pyun YongHyeon


From barbara.xxx1975 at libero.it  Sat Jan 10 12:38:59 2009
From: barbara.xxx1975 at libero.it (Barbara)
Date: Sat Jan 10 12:39:09 2009
Subject: R: Re: Lock enabling onboard lan (Attansic L1 GbE) on 7.1-PRERELEASE
Message-ID: <32345244.1273621231591135306.JavaMail.defaultUser@defaultHost>



>On Sat, Jan 10, 2009 at 04:07:24AM +0100, Barbara wrote:
>
>[...]
>
> > 
>Would try the following WIP version?
> > >http://people.
> > freebsd.
org/~yongari/age/if_age.c
> > >http://people.freebsd.
> > 
org/~yongari/age/if_agereg.h
> > >I have no longer access to L1 hardware so I 
don't 
> > know whether it
> > >helps or not.
> > >
> > >-- 
> > >Regards,
> > 
>Pyun YongHyeon
> > 
> > Well, it 
> > works!
> > As I've said, it's not a real 
problem for me, but I'm so sorry about not 
> > having tested before so it 
could be merged before 7.1-RELEASE, but I had it 
> > disabled and nearly 
forgot about that.
> > Please, feel free to ask whenever you 
> > want if you 
want me doing tests on that NIC.
> > 
>
>I'm confused, the WIP version works 
whereas age(4) in 7.1-RELEASE
>didn't work right?

Thats's correct!

>If the 
WIP version works, would you show me the output of verbose
>boot message?

You 
can find it here:
http://pastebin.com/f58373793

and below.

Copyright (c) 1992-
2009 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 
1991, 1992, 1993, 1994
	The Regents of the University of California. All rights 
reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 
7.1-STABLE #3: Sat Jan 10 12:42:07 CET 2009
    root@satanasso.local.net:
/usr/obj/usr/src/sys/SATANASSO
Preloaded elf kernel "/boot/kernel/kernel" at 
0xc110b000.
Preloaded elf module "/boot/kernel/linux.ko" at 0xc110b19c.

Preloaded elf module "/boot/kernel/if_age.ko" at 0xc110b248.
Preloaded elf 
module "/boot/modules/nvidia.ko" at 0xc110b2f4.
Preloaded elf module 
"/boot/kernel/acpi.ko" at 0xc110b3a0.
Calibrating clock(s) ... i8254 clock: 
1193129 Hz
CLK_USE_I8254_CALIBRATION not specified - using default frequency

Timecounter "i8254" frequency 1193182 Hz quality 0
Calibrating TSC clock ... 
TSC clock: 2499733807 Hz
CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 4800+ 
(2499.73-MHz 686-class CPU)
  Origin = "AuthenticAMD"  Id = 0x60fb1  Stepping = 
1
  Features=0x178bfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,
MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT>
  Features2=0x2001<SSE3,CX16>

  AMD Features=0xea500800<SYSCALL,NX,MMX+,FFXSR,RDTSCP,LM,3DNow!+,3DNow!>
  AMD 
Features2=0x11f<LAHF,CMP,SVM,ExtAPIC,CR8,Prefetch>
  Cores per package: 2
Data 
TLB: 32 entries, fully associative
Instruction TLB: 32 entries, fully 
associative
L1 data cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way 
associative
L1 instruction cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way 
associative
L2 internal cache: 512 kbytes, 64 bytes/line, 1 lines/tag, 8-way 
associative
real memory  = 2147155968 (2047 MB)
Physical memory chunk(s):

0x0000000000001000 - 0x000000000009efff, 647168 bytes (158 pages)

0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages)

0x0000000001425000 - 0x000000007db60fff, 2087960576 bytes (509756 pages)
avail 
memory = 2087153664 (1990 MB)
Table 'FACP' at 0x7ffb0200
Table 'APIC' at 
0x7ffb0390
MADT: Found table at 0x7ffb0390
MP Configuration Table version 1.4 
found at 0xc00f11a0
APIC: Using the MADT enumerator.
MADT: Found CPU APIC ID 0 
ACPI ID 1: enabled
SMP: Added CPU 0 (AP)
MADT: Found CPU APIC ID 1 ACPI ID 2: 
enabled
SMP: Added CPU 1 (AP)
ACPI APIC Table: <A_M_I_ OEMAPIC >
INTR: Adding 
local APIC 1 as a target
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
 
cpu0 (BSP): APIC ID:  0
 cpu1 (AP): APIC ID:  1
bios32: Found BIOS32 Service 
Directory header at 0xc00f0000
bios32: Entry = 0xf0010 (c00f0010)  Rev = 0  Len 
= 1
pcibios: PCI BIOS entry at 0xf0000+0x31
pnpbios: Found PnP BIOS data at 
0xc00f70e0
pnpbios: Entry = f0000:812a  Rev = 1.0
Other BIOS signatures found:

APIC: CPU 0 has ACPI ID 1
APIC: CPU 1 has ACPI ID 2
ULE: setup cpu group 0
ULE: 
setup cpu 0
ULE: adding cpu 0 to group 0: cpus 1 mask 0x1
ULE: setup cpu group 
1
ULE: setup cpu 1
ULE: adding cpu 1 to group 1: cpus 1 mask 0x2
ACPI: RSDP @ 
0x0xfa960/0x0014 (v  0 ACPIAM)
ACPI: RSDT @ 0x0x7ffb0000/0x003C (v  1 A_M_I_ 
OEMRSDT  0x02000821 MSFT 0x00000097)
ACPI: FACP @ 0x0x7ffb0200/0x0084 (v  2 
A_M_I_ OEMFACP  0x02000821 MSFT 0x00000097)
ACPI: DSDT @ 0x0x7ffb05c0/0x4E3F 
(v  1  A0498 A0498000 0x00000000 INTL 0x20060113)
ACPI: FACS @ 
0x0x7ffbe000/0x0040
ACPI: APIC @ 0x0x7ffb0390/0x0068 (v  1 A_M_I_ OEMAPIC  
0x02000821 MSFT 0x00000097)
ACPI: MCFG @ 0x0x7ffb0400/0x003C (v  1 A_M_I_ 
OEMMCFG  0x02000821 MSFT 0x00000097)
ACPI: OEMB @ 0x0x7ffbe040/0x0060 (v  1 
A_M_I_ AMI_OEM  0x02000821 MSFT 0x00000097)
ACPI: HPET @ 0x0x7ffb5400/0x0038 
(v  1 A_M_I_ OEMHPET  0x02000821 MSFT 0x00000097)
ACPI: SSDT @ 
0x0x7ffb5440/0x028A (v  1 A_M_I_ POWERNOW 0x00000001 AMD  0x00000001)
MADT: 
Found IO APIC ID 2, Interrupt 0 at 0xfec00000
ioapic0: Routing external 8259A's 
-> intpin 0
MADT: Found IO APIC ID 3, Interrupt 24 at 0xfecc0000
MADT: 
Interrupt override: source 0, irq 2
ioapic0: Routing IRQ 0 -> intpin 2
MADT: 
Interrupt override: source 9, irq 9
ioapic0: intpin 9 trigger: level
ioapic0: 
intpin 9 polarity: low
ioapic0 <Version 0.3> irqs 0-23 on motherboard
ioapic1 
<Version 0.3> irqs 24-47 on motherboard
cpu0 BSP:
     ID: 0x00000000   VER: 
0x80050010 LDR: 0x00000000 DFR: 0xffffffff
  lint0: 0x00010700 lint1: 
0x00000400 TPR: 0x00000000 SVR: 0x000001ff
  timer: 0x000100ef therm: 
0x00010000 err: 0x0001000f pcm: 0x00010000
snd_unit_init() u=0x00ff8000 [512] 
d=0x00007c00 [32] c=0x000003ff [1024]
feeder_register: snd_unit=-1 
snd_maxautovchans=16 latency=5 feeder_buffersize=16384 feeder_rate_min=1 
feeder_rate_max=2016000 feeder_rate_round=25
io: <I/O>
VESA: information block

56 45 53 41 00 03 00 01 00 01 01 00 00 00 22 00 
00 01 e0 00 86 60 07 01 00 01 
1a 01 00 01 2f 01 
00 01 00 01 01 01 02 01 03 01 04 01 05 01 06 01 
07 01 0e 01 
0f 01 11 01 12 01 14 01 15 01 17 01 
VESA: 30 mode(s) found
VESA: v3.0, 14336k 
memory, flags:0x1, mode table:0xc08a9c62 (1000022)
VESA: NVIDIA
VESA: NVIDIA 
Corporation G86 Board - p403h20  Chip Rev   
null: <null device, zero device>

kbd: new array size 4
kbd1 at kbdmux0
random: <entropy source, Software, 
Yarrow>
nfslock: pseudo-device
mem: <memory>
Pentium Pro MTRR support enabled

npx0: INT 16 interface
acpi0: <A_M_I_ OEMRSDT> on motherboard
ioapic0: routing 
intpin 9 (ISA IRQ 9) to vector 48
acpi0: [MPSAFE]
acpi0: [ITHREAD]
acpi0: Power 
Button (fixed)
acpi0: wakeup code va 0xe5499000 pa 0x1000
pci_open(1):	mode 1 
addr port (0x0cf8) is 0x80008f64
pci_open(1a):	mode1res=0x80000000 (0x80000000)

pci_cfgcheck:	device 0 [class=060000] [hdr=80] is there (id=03511106)
pcibios: 
BIOS version 3.00
AcpiOsDerivePciId: \\_SB_.PCI0.SATA.SAPR -> bus 0 dev 15 func 
0
AcpiOsDerivePciId: \\_SB_.PCI0.SBRG.HPRG -> bus 0 dev 17 func 0

AcpiOsDerivePciId: \\_SB_.PCI0.SBRG.PIX0 -> bus 0 dev 17 func 0

AcpiOsDerivePciId: \\_SB_.PCI0.SBRG.PIX2 -> bus 0 dev 17 func 0
acpi0: 
reservation of 0, a0000 (3) failed
acpi0: reservation of 100000, 7ff00000 (3) 
failed
ACPI timer: 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 -> 10
Timecounter 
"ACPI-fast" frequency 3579545 Hz quality 1000
acpi_timer0: <24-bit timer at 
3.579545MHz> port 0x808-0x80b on acpi0
pci_link0:        Index  IRQ  Rtd  Ref  
IRQs
  Initial Probe       0   11   N     0  3 4 5 6 7 10 11 12 14 15
  
Validation          0   11   N     0  3 4 5 6 7 10 11 12 14 15
  After 
Disable       0  255   N     0  3 4 5 6 7 10 11 12 14 15
pci_link1:        
Index  IRQ  Rtd  Ref  IRQs
  Initial Probe       0   10   N     0  3 4 5 6 7 10 
11 12 14 15
  Validation          0   10   N     0  3 4 5 6 7 10 11 12 14 15
  
After Disable       0  255   N     0  3 4 5 6 7 10 11 12 14 15

pci_link2:        Index  IRQ  Rtd  Ref  IRQs
  Initial Probe       0    5   
N     0  3 4 5 6 7 10 11 12 14 15
  Validation          0    5   N     0  3 4 5 
6 7 10 11 12 14 15
  After Disable       0  255   N     0  3 4 5 6 7 10 11 12 
14 15
pci_link3:        Index  IRQ  Rtd  Ref  IRQs
  Initial Probe       0    
3   N     0  3 4 5 6 7 10 11 12 14 15
  Validation          0    3   N     0  3 
4 5 6 7 10 11 12 14 15
  After Disable       0  255   N     0  3 4 5 6 7 10 11 
12 14 15
pci_link4:        Index  IRQ  Rtd  Ref  IRQs
  Initial Probe       0  
255   N     0  3 4 5 6 7 10 11 12 14 15
  Validation          0  255   N     0  
3 4 5 6 7 10 11 12 14 15
  After Disable       0  255   N     0  3 4 5 6 7 10 
11 12 14 15
pci_link5:        Index  IRQ  Rtd  Ref  IRQs
  Initial Probe       
0  255   N     0  3 4 5 6 7 10 11 12 14 15
  Validation          0  255   N     
0  3 4 5 6 7 10 11 12 14 15
  After Disable       0  255   N     0  3 4 5 6 7 
10 11 12 14 15
pci_link6:        Index  IRQ  Rtd  Ref  IRQs
  Initial 
Probe       0  255   N     0  3 4 5 6 7 10 11 12 14 15
  Validation          0  
255   N     0  3 4 5 6 7 10 11 12 14 15
  After Disable       0  255   N     0  
3 4 5 6 7 10 11 12 14 15
pci_link7:        Index  IRQ  Rtd  Ref  IRQs
  Initial 
Probe       0   11   N     0  3 4 5 6 7 10 11 12 14 15
  Validation          
0   11   N     0  3 4 5 6 7 10 11 12 14 15
  After Disable       0  255   N     
0  3 4 5 6 7 10 11 12 14 15
acpi_hpet0: <High Precision Event Timer> iomem 
0xfed00000-0xfed003ff on acpi0
acpi_hpet0: vend: 0x1106 rev: 0x1 num: 2 hz: 
14318180 opts: legacy_route
Timecounter "HPET" frequency 14318180 Hz quality 
900
pcib0: <ACPI Host-PCI bridge> port 0xcf8-0xcff on acpi0
pci0: <ACPI PCI 
bus> on pcib0
pci0: domain=0, physical bus=0
found->	vendor=0x1106, dev=0x0351, 
revid=0x00
	domain=0, bus=0, slot=0, func=0
	class=06-00-00, hdrtype=0x00, 
mfdev=1
	cmdreg=0x0106, statreg=0x0210, cachelnsz=16 (dwords)
	lattimer=0x40 
(1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
	powerspec 2  supports D0 D3  
current D0
found->	vendor=0x1106, dev=0x1351, revid=0x00
	domain=0, bus=0, 
slot=0, func=1
	class=06-00-00, hdrtype=0x00, mfdev=0
	cmdreg=0x0006, 
statreg=0x0200, cachelnsz=16 (dwords)
	lattimer=0x00 (0 ns), mingnt=0x00 (0 
ns), maxlat=0x00 (0 ns)
found->	vendor=0x1106, dev=0x2351, revid=0x00
	
domain=0, bus=0, slot=0, func=2
	class=06-00-00, hdrtype=0x00, mfdev=0
	
cmdreg=0x0006, statreg=0x0200, cachelnsz=16 (dwords)
	lattimer=0x00 (0 ns), 
mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
found->	vendor=0x1106, dev=0x3351, 
revid=0x00
	domain=0, bus=0, slot=0, func=3
	class=06-00-00, hdrtype=0x00, 
mfdev=0
	cmdreg=0x0006, statreg=0x0200, cachelnsz=16 (dwords)
	lattimer=0x00 (0 
ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
found->	vendor=0x1106, dev=0x4351, 
revid=0x00
	domain=0, bus=0, slot=0, func=4
	class=06-00-00, hdrtype=0x00, 
mfdev=0
	cmdreg=0x0006, statreg=0x0200, cachelnsz=16 (dwords)
	lattimer=0x00 (0 
ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
found->	vendor=0x1106, dev=0x5351, 
revid=0x00
	domain=0, bus=0, slot=0, func=5
	class=08-00-20, hdrtype=0x00, 
mfdev=1
	cmdreg=0x0006, statreg=0x0000, cachelnsz=16 (dwords)
	lattimer=0x00 (0 
ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
found->	vendor=0x1106, dev=0x6238, 
revid=0x00
	domain=0, bus=0, slot=0, func=6
	class=06-00-00, hdrtype=0x00, 
mfdev=0
	cmdreg=0x0006, statreg=0x0200, cachelnsz=16 (dwords)
	lattimer=0x00 (0 
ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
found->	vendor=0x1106, dev=0x7351, 
revid=0x00
	domain=0, bus=0, slot=0, func=7
	class=06-00-00, hdrtype=0x00, 
mfdev=0
	cmdreg=0x0006, statreg=0x0200, cachelnsz=16 (dwords)
	lattimer=0x00 (0 
ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
found->	vendor=0x1106, dev=0xb999, 
revid=0x00
	domain=0, bus=0, slot=1, func=0
	class=06-04-00, hdrtype=0x01, 
mfdev=0
	cmdreg=0x0004, statreg=0x0230, cachelnsz=16 (dwords)
	lattimer=0x00 (0 
ns), mingnt=0x03 (750 ns), maxlat=0x00 (0 ns)
	powerspec 2  supports D0 D3  
current D0
found->	vendor=0x1106, dev=0xa238, revid=0x00
	domain=0, bus=0, 
slot=2, func=0
	class=06-04-00, hdrtype=0x01, mfdev=0
	cmdreg=0x0107, 
statreg=0x0010, cachelnsz=16 (dwords)
	lattimer=0x00 (0 ns), mingnt=0x0b (2750 
ns), maxlat=0x00 (0 ns)
	intpin=a, irq=11
	powerspec 2  supports D0 D3  current 
D0
	MSI supports 1 message, 64 bit, vector masks
pcib0: matched entry for 0.2.
INTA
pcib0: slot 2 INTA hardwired to IRQ 27
found->	vendor=0x1106, dev=0xc238, 
revid=0x00
	domain=0, bus=0, slot=3, func=0
	class=06-04-00, hdrtype=0x01, 
mfdev=1
	cmdreg=0x0106, statreg=0x0010, cachelnsz=16 (dwords)
	lattimer=0x00 (0 
ns), mingnt=0x03 (750 ns), maxlat=0x00 (0 ns)
	intpin=a, irq=11
	powerspec 2  
supports D0 D3  current D0
	MSI supports 1 message, 64 bit, vector masks
pcib0: 
matched entry for 0.3.INTA
pcib0: slot 3 INTA hardwired to IRQ 31
found->	
vendor=0x1106, dev=0xd238, revid=0x00
	domain=0, bus=0, slot=3, func=1
	
class=06-04-00, hdrtype=0x01, mfdev=1
	cmdreg=0x0106, statreg=0x0010, 
cachelnsz=16 (dwords)
	lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x00 
(0 ns)
	intpin=b, irq=11
	powerspec 2  supports D0 D3  current D0
	MSI supports 
1 message, 64 bit, vector masks
pcib0: matched entry for 0.3.INTB
pcib0: slot 3 
INTB hardwired to IRQ 35
found->	vendor=0x1106, dev=0xe238, revid=0x00
	
domain=0, bus=0, slot=3, func=2
	class=06-04-00, hdrtype=0x01, mfdev=1
	
cmdreg=0x0106, statreg=0x0010, cachelnsz=16 (dwords)
	lattimer=0x00 (0 ns), 
mingnt=0x03 (750 ns), maxlat=0x00 (0 ns)
	intpin=c, irq=11
	powerspec 2  
supports D0 D3  current D0
	MSI supports 1 message, 64 bit, vector masks
pcib0: 
matched entry for 0.3.INTC
pcib0: slot 3 INTC hardwired to IRQ 39
found->	
vendor=0x1106, dev=0xf238, revid=0x00
	domain=0, bus=0, slot=3, func=3
	
class=06-04-00, hdrtype=0x01, mfdev=1
	cmdreg=0x0106, statreg=0x0010, 
cachelnsz=16 (dwords)
	lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x00 
(0 ns)
	intpin=d, irq=11
	powerspec 2  supports D0 D3  current D0
	MSI supports 
1 message, 64 bit, vector masks
pcib0: matched entry for 0.3.INTD
pcib0: slot 3 
INTD hardwired to IRQ 43
found->	vendor=0x1106, dev=0x0591, revid=0x80
	
domain=0, bus=0, slot=15, func=0
	class=01-01-8f, hdrtype=0x00, mfdev=1
	
cmdreg=0x0007, statreg=0x0290, cachelnsz=0 (dwords)
	lattimer=0x40 (1920 ns), 
mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
	intpin=b, irq=10
	powerspec 2  supports 
D0 D3  current D0
	map[10]: type I/O Port, range 32, base 0xcc00, size  3, 
enabled
	map[14]: type I/O Port, range 32, base 0xc880, size  2, enabled
	map
[18]: type I/O Port, range 32, base 0xc800, size  3, enabled
	map[1c]: type I/O 
Port, range 32, base 0xc480, size  2, enabled
	map[20]: type I/O Port, range 
32, base 0xc400, size  4, enabled
	map[24]: type I/O Port, range 32, base 
0xc000, size  8, enabled
pcib0: matched entry for 0.15.INTB
pcib0: slot 15 INTB 
hardwired to IRQ 21
found->	vendor=0x1106, dev=0x0571, revid=0x07
	domain=0, 
bus=0, slot=15, func=1
	class=01-01-8a, hdrtype=0x00, mfdev=0
	cmdreg=0x0005, 
statreg=0x0290, cachelnsz=0 (dwords)
	lattimer=0x20 (960 ns), mingnt=0x00 (0 
ns), maxlat=0x00 (0 ns)
	powerspec 2  supports D0 D3  current D0
	map[20]: type 
I/O Port, range 32, base 0xfc00, size  4, enabled
found->	vendor=0x1106, 
dev=0x3038, revid=0xa0
	domain=0, bus=0, slot=16, func=0
	class=0c-03-00, 
hdrtype=0x00, mfdev=1
	cmdreg=0x0017, statreg=0x0210, cachelnsz=16 (dwords)
	
lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
	intpin=a, 
irq=11
	powerspec 2  supports D0 D1 D2 D3  current D0
	map[20]: type I/O Port, 
range 32, base 0xb480, size  5, enabled
pcib0: matched entry for 0.16.INTA

pcib0: slot 16 INTA hardwired to IRQ 20
found->	vendor=0x1106, dev=0x3038, 
revid=0xa0
	domain=0, bus=0, slot=16, func=1
	class=0c-03-00, hdrtype=0x00, 
mfdev=1
	cmdreg=0x0017, statreg=0x0210, cachelnsz=16 (dwords)
	lattimer=0x40 
(1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
	intpin=b, irq=10
	powerspec 
2  supports D0 D1 D2 D3  current D0
	map[20]: type I/O Port, range 32, base 
0xb800, size  5, enabled
pcib0: matched entry for 0.16.INTB
pcib0: slot 16 INTB 
hardwired to IRQ 22
found->	vendor=0x1106, dev=0x3038, revid=0xa0
	domain=0, 
bus=0, slot=16, func=2
	class=0c-03-00, hdrtype=0x00, mfdev=1
	cmdreg=0x0017, 
statreg=0x0210, cachelnsz=16 (dwords)
	lattimer=0x40 (1920 ns), mingnt=0x00 (0 
ns), maxlat=0x00 (0 ns)
	intpin=c, irq=5
	powerspec 2  supports D0 D1 D2 D3  
current D0
	map[20]: type I/O Port, range 32, base 0xb880, size  5, enabled

pcib0: matched entry for 0.16.INTC
pcib0: slot 16 INTC hardwired to IRQ 21

found->	vendor=0x1106, dev=0x3038, revid=0xa0
	domain=0, bus=0, slot=16, func=3

	class=0c-03-00, hdrtype=0x00, mfdev=1
	cmdreg=0x0017, statreg=0x0210, 
cachelnsz=16 (dwords)
	lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 
(0 ns)
	intpin=d, irq=3
	powerspec 2  supports D0 D1 D2 D3  current D0
	map
[20]: type I/O Port, range 32, base 0xbc00, size  5, enabled
pcib0: matched 
entry for 0.16.INTD
pcib0: slot 16 INTD hardwired to IRQ 23
found->	
vendor=0x1106, dev=0x3104, revid=0x86
	domain=0, bus=0, slot=16, func=4
	
class=0c-03-20, hdrtype=0x00, mfdev=1
	cmdreg=0x0017, statreg=0x0210, 
cachelnsz=16 (dwords)
	lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 
(0 ns)
	intpin=c, irq=5
	powerspec 2  supports D0 D1 D2 D3  current D0
	map
[10]: type Memory, range 32, base 0xf7fffc00, size  8, enabled
pcib0: matched 
entry for 0.16.INTC
pcib0: slot 16 INTC hardwired to IRQ 21
found->	
vendor=0x1106, dev=0x3337, revid=0x00
	domain=0, bus=0, slot=17, func=0
	
class=06-01-00, hdrtype=0x00, mfdev=1
	cmdreg=0x0003, statreg=0x0210, 
cachelnsz=0 (dwords)
	lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 
ns)
	powerspec 2  supports D0 D3  current D0
found->	vendor=0x1106, dev=0x287e, 
revid=0x00
	domain=0, bus=0, slot=17, func=7
	class=06-00-00, hdrtype=0x00, 
mfdev=0
	cmdreg=0x0106, statreg=0x0210, cachelnsz=0 (dwords)
	lattimer=0x80 
(3840 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
found->	vendor=0x1106, 
dev=0x337b, revid=0x00
	domain=0, bus=0, slot=19, func=0
	class=06-04-00, 
hdrtype=0x01, mfdev=1
	cmdreg=0x0106, statreg=0x2010, cachelnsz=0 (dwords)
	
lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x00 (0 ns)
found->	
vendor=0x1106, dev=0x337a, revid=0x00
	domain=0, bus=0, slot=19, func=1
	
class=06-04-01, hdrtype=0x01, mfdev=0
	cmdreg=0x0107, statreg=0x2010, 
cachelnsz=0 (dwords)
	lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x00 
(0 ns)
found->	vendor=0x1022, dev=0x1100, revid=0x00
	domain=0, bus=0, slot=24, 
func=0
	class=06-00-00, hdrtype=0x00, mfdev=1
	cmdreg=0x0000, statreg=0x0010, 
cachelnsz=0 (dwords)
	lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 
ns)
found->	vendor=0x1022, dev=0x1101, revid=0x00
	domain=0, bus=0, slot=24, 
func=1
	class=06-00-00, hdrtype=0x00, mfdev=1
	cmdreg=0x0000, statreg=0x0000, 
cachelnsz=0 (dwords)
	lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 
ns)
found->	vendor=0x1022, dev=0x1102, revid=0x00
	domain=0, bus=0, slot=24, 
func=2
	class=06-00-00, hdrtype=0x00, mfdev=1
	cmdreg=0x0000, statreg=0x0000, 
cachelnsz=0 (dwords)
	lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 
ns)
found->	vendor=0x1022, dev=0x1103, revid=0x00
	domain=0, bus=0, slot=24, 
func=3
	class=06-00-00, hdrtype=0x00, mfdev=1
	cmdreg=0x0000, statreg=0x0010, 
cachelnsz=0 (dwords)
	lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 
ns)
pcib1: <ACPI PCI-PCI bridge> at device 1.0 on pci0
pcib1:   
domain            0
pcib1:   secondary bus     1
pcib1:   subordinate bus   1

pcib1:   I/O decode        0x0-0x0
pcib1:   no prefetched decode
pci1: <ACPI 
PCI bus> on pcib1
pci1: domain=0, physical bus=1
pcib2: <ACPI PCI-PCI bridge> 
irq 27 at device 2.0 on pci0
pcib2:   domain            0
pcib2:   secondary 
bus     2
pcib2:   subordinate bus   2
pcib2:   I/O decode        0xd000-0xdfff

pcib2:   memory decode     0xf8000000-0xfbcfffff
pcib2:   prefetched decode 
0xd0000000-0xdfffffff
pci2: <ACPI PCI bus> on pcib2
pci2: domain=0, physical 
bus=2
found->	vendor=0x10de, dev=0x0421, revid=0xa1
	domain=0, bus=2, slot=0, 
func=0
	class=03-00-00, hdrtype=0x00, mfdev=0
	cmdreg=0x0107, statreg=0x0010, 
cachelnsz=16 (dwords)
	lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 
ns)
	intpin=a, irq=11
	powerspec 2  supports D0 D3  current D0
	MSI supports 1 
message, 64 bit
	map[10]: type Memory, range 32, base 0xfa000000, size 24, 
enabled
pcib2: requested memory range 0xfa000000-0xfaffffff: good
	map[14]: 
type Prefetchable Memory, range 64, base 0xd0000000, size 28, enabled
pcib2: 
requested memory range 0xd0000000-0xdfffffff: good
	map[1c]: type Memory, range 
64, base 0xf8000000, size 25, enabled
pcib2: requested memory range 0xf8000000-
0xf9ffffff: good
	map[24]: type I/O Port, range 32, base 0xdc00, size  7, 
enabled
pcib2: requested I/O range 0xdc00-0xdc7f: in range
pcib2: matched entry 
for 2.0.INTA
pcib2: slot 0 INTA hardwired to IRQ 24
vgapci0: <VGA-compatible 
display> port 0xdc00-0xdc7f mem 0xfa000000-0xfaffffff,0xd0000000-0xdfffffff,
0xf8000000-0xf9ffffff irq 24 at device 0.0 on pci2
nvidia0: <GeForce 8500 GT> 
on vgapci0
vgapci0: child nvidia0 requested pci_enable_busmaster
vgapci0: child 
nvidia0 requested pci_enable_io
vgapci0: Reserved 0x1000000 bytes for rid 0x10 
type 3 at 0xfa000000
vgapci0: Reserved 0x10000000 bytes for rid 0x14 type 3 at 
0xd0000000
vgapci0: Reserved 0x2000000 bytes for rid 0x1c type 3 at 0xf8000000

ioapic1: routing intpin 0 (PCI IRQ 24) to vector 49
nvidia0: [GIANT-LOCKED]

nvidia0: [ITHREAD]
pcib3: <ACPI PCI-PCI bridge> irq 31 at device 3.0 on pci0

pcib3:   domain            0
pcib3:   secondary bus     6
pcib3:   subordinate 
bus   6
pcib3:   I/O decode        0x0-0x0
pcib3:   prefetched decode 
0xf6f00000-0xf6ffffff
pci6: <ACPI PCI bus> on pcib3
pci6: domain=0, physical 
bus=6
pcib4: <ACPI PCI-PCI bridge> irq 35 at device 3.1 on pci0
pcib4:   
domain            0
pcib4:   secondary bus     5
pcib4:   subordinate bus   5

pcib4:   I/O decode        0x0-0x0
pcib4:   prefetched decode 0xf6e00000-
0xf6efffff
pci5: <ACPI PCI bus> on pcib4
pci5: domain=0, physical bus=5
pcib5: 
<ACPI PCI-PCI bridge> irq 39 at device 3.2 on pci0
pcib5:   domain            0

pcib5:   secondary bus     4
pcib5:   subordinate bus   4
pcib5:   I/O 
decode        0x0-0x0
pcib5:   memory decode     0xfbd00000-0xfbdfffff
pcib5:   
no prefetched decode
pci4: <ACPI PCI bus> on pcib5
pci4: domain=0, physical 
bus=4
found->	vendor=0x1969, dev=0x1048, revid=0xb0
	domain=0, bus=4, slot=0, 
func=0
	class=02-00-00, hdrtype=0x00, mfdev=0
	cmdreg=0x0106, statreg=0x4010, 
cachelnsz=16 (dwords)
	lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 
ns)
	intpin=a, irq=11
	powerspec 2  supports D0 D3  current D0
	MSI supports 1 
message, 64 bit
	map[10]: type Memory, range 64, base 0xfbdc0000, size 18, 
enabled
pcib5: requested memory range 0xfbdc0000-0xfbdfffff: good
pcib5: 
matched entry for 4.0.INTA
pcib5: slot 0 INTA hardwired to IRQ 36
age0: 
<Attansic Technology Corp, L1 Gigabit Ethernet> mem 0xfbdc0000-0xfbdfffff irq 
36 at device 0.0 on pci4
age0: Reserved 0x40000 bytes for rid 0x10 type 3 at 
0xfbdc0000
age0: PCI device revision : 0x00b0
age0: Chip id/revision : 0x9006

age0: 1280 Tx FIFO, 2364 Rx FIFO
age0: MSIX count : 0
age0: MSI count : 1
age0: 
attempting to allocate 1 MSI vectors (1 supported)
msi: routing MSI IRQ 256 to 
vector 50
age0: using IRQ 256 for MSI
age0: Using 1 MSI messages.
age0: Read 
request size : 512 bytes.
age0: TLP payload size : 128 bytes.
miibus0: <MII 
bus> on age0
atphy0: <Atheros F1 10/100/1000 PHY> PHY 0 on miibus0
atphy0: OUI 
0x001374, model 0x0001, rev. 5
atphy0:  10baseT, 10baseT-FDX, 100baseTX, 
100baseTX-FDX, 1000baseT-FDX, auto
age0: bpf attached
age0: Ethernet address: 
00:1a:92:36:72:21
age0: [MPSAFE]
age0: [FILTER]
pcib6: <ACPI PCI-PCI bridge> 
irq 43 at device 3.3 on pci0
pcib6:   domain            0
pcib6:   secondary 
bus     3
pcib6:   subordinate bus   3
pcib6:   I/O decode        0x0-0x0

pcib6:   prefetched decode 0xf6d00000-0xf6dfffff
pci3: <ACPI PCI bus> on pcib6

pci3: domain=0, physical bus=3
atapci0: <VIA 8237A SATA150 controller> port 
0xcc00-0xcc07,0xc880-0xc883,0xc800-0xc807,0xc480-0xc483,0xc400-0xc40f,0xc000-
0xc0ff irq 21 at device 15.0 on pci0
atapci0: Reserved 0x10 bytes for rid 0x20 
type 4 at 0xc400
ioapic0: routing intpin 21 (PCI IRQ 21) to vector 51
atapci0: 
[MPSAFE]
atapci0: [ITHREAD]
atapci0: Reserved 0x100 bytes for rid 0x24 type 4 
at 0xc000
ata2: <ATA channel 0> on atapci0
atapci0: Reserved 0x8 bytes for rid 
0x10 type 4 at 0xcc00
atapci0: Reserved 0x4 bytes for rid 0x14 type 4 at 0xc880

ata2: SATA connect time=0ms
ata2: reset tp1 mask=01 ostat0=50 ostat1=00
ata2: 
stat0=0x50 err=0x01 lsb=0x00 msb=0x00
ata2: reset tp2 stat0=50 stat1=00 
devices=0x1<ATA_MASTER>
ata2: [MPSAFE]
ata2: [ITHREAD]
ata3: <ATA channel 1> on 
atapci0
atapci0: Reserved 0x8 bytes for rid 0x18 type 4 at 0xc800
atapci0: 
Reserved 0x4 bytes for rid 0x1c type 4 at 0xc480
ata3: SATA connect 
status=00000000
ata3: [MPSAFE]
ata3: [ITHREAD]
atapci1: <VIA 8237A UDMA133 
controller> port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfc00-0xfc0f at device 
15.1 on pci0
atapci1: Reserved 0x10 bytes for rid 0x20 type 4 at 0xfc00
ata0: 
<ATA channel 0> on atapci1
atapci1: Reserved 0x8 bytes for rid 0x10 type 4 at 
0x1f0
atapci1: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6
ata0: reset tp1 
mask=03 ostat0=50 ostat1=50
ata0: stat0=0x90 err=0x90 lsb=0x90 msb=0x90
ata0: 
stat0=0x50 err=0x01 lsb=0x00 msb=0x00
ata0: stat1=0x50 err=0x01 lsb=0x00 
msb=0x00
ata0: reset tp2 stat0=50 stat1=50 devices=0x3<ATA_SLAVE,ATA_MASTER>

ioapic0: routing intpin 14 (ISA IRQ 14) to vector 52
ata0: [MPSAFE]
ata0: 
[ITHREAD]
ata1: <ATA channel 1> on atapci1
atapci1: Reserved 0x8 bytes for rid 
0x18 type 4 at 0x170
atapci1: Reserved 0x1 bytes for rid 0x1c type 4 at 0x376

ata1: reset tp1 mask=03 ostat0=50 ostat1=00
ata1: stat0=0x00 err=0x01 lsb=0x14 
msb=0xeb
ata1: stat1=0x00 err=0x00 lsb=0x00 msb=0x00
ata1: reset tp2 stat0=00 
stat1=00 devices=0x4<ATAPI_MASTER>
ioapic0: routing intpin 15 (ISA IRQ 15) to 
vector 53
ata1: [MPSAFE]
ata1: [ITHREAD]
uhci0: <VIA 83C572 USB controller> 
port 0xb480-0xb49f irq 20 at device 16.0 on pci0
uhci0: Reserved 0x20 bytes for 
rid 0x20 type 4 at 0xb480
ioapic0: routing intpin 20 (PCI IRQ 20) to vector 54

uhci0: [GIANT-LOCKED]
uhci0: [ITHREAD]
usb0: <VIA 83C572 USB controller> on 
uhci0
usb0: USB revision 1.0
uhub0: <VIA UHCI root hub, class 9/0, rev 1.00/1.
00, addr 1> on usb0
uhub0: 2 ports with 2 removable, self powered
uhci1: <VIA 
83C572 USB controller> port 0xb800-0xb81f irq 22 at device 16.1 on pci0
uhci1: 
Reserved 0x20 bytes for rid 0x20 type 4 at 0xb800
ioapic0: routing intpin 22 
(PCI IRQ 22) to vector 55
uhci1: [GIANT-LOCKED]
uhci1: [ITHREAD]
usb1: <VIA 
83C572 USB controller> on uhci1
usb1: USB revision 1.0
uhub1: <VIA UHCI root 
hub, class 9/0, rev 1.00/1.00, addr 1> on usb1
uhub1: 2 ports with 2 removable, 
self powered
uhci2: <VIA 83C572 USB controller> port 0xb880-0xb89f irq 21 at 
device 16.2 on pci0
uhci2: Reserved 0x20 bytes for rid 0x20 type 4 at 0xb880

uhci2: [GIANT-LOCKED]
uhci2: [ITHREAD]
usb2: <VIA 83C572 USB controller> on 
uhci2
usb2: USB revision 1.0
uhub2: <VIA UHCI root hub, class 9/0, rev 1.00/1.
00, addr 1> on usb2
uhub2: 2 ports with 2 removable, self powered
uhci3: <VIA 
83C572 USB controller> port 0xbc00-0xbc1f irq 23 at device 16.3 on pci0
uhci3: 
Reserved 0x20 bytes for rid 0x20 type 4 at 0xbc00
ioapic0: routing intpin 23 
(PCI IRQ 23) to vector 56
uhci3: [GIANT-LOCKED]
uhci3: [ITHREAD]
usb3: <VIA 
83C572 USB controller> on uhci3
usb3: USB revision 1.0
uhub3: <VIA UHCI root 
hub, class 9/0, rev 1.00/1.00, addr 1> on usb3
uhub3: 2 ports with 2 removable, 
self powered
ehci0: <VIA VT6202 USB 2.0 controller> mem 0xf7fffc00-0xf7fffcff 
irq 21 at device 16.4 on pci0
ehci0: Reserved 0x100 bytes for rid 0x10 type 3 
at 0xf7fffc00
ehci0: [GIANT-LOCKED]
ehci0: [ITHREAD]
ehci0: Dropped interrupts 
workaround enabled
usb4: EHCI version 1.0
usb4: companion controllers, 2 ports 
each: usb0 usb1 usb2 usb3
usb4: <VIA VT6202 USB 2.0 controller> on ehci0
usb4: 
USB revision 2.0
uhub4: <VIA EHCI root hub, class 9/0, rev 2.00/1.00, addr 1> 
on usb4
uhub4: 8 ports with 8 removable, self powered
isab0: <PCI-ISA bridge> 
at device 17.0 on pci0
isa0: <ISA bus> on isab0
pcib7: <ACPI PCI-PCI bridge> at 
device 19.0 on pci0
pcib7:   domain            0
pcib7:   secondary bus     128

pcib7:   subordinate bus   128
pcib7:   I/O decode        0x0-0x0
pcib7:   
memory decode     0xfbf00000-0xfbffffff
pcib7:   no prefetched decode
pci128: 
<ACPI PCI bus> on pcib7
pci128: domain=0, physical bus=128
found->	
vendor=0x1106, dev=0x3288, revid=0x10
	domain=0, bus=128, slot=1, func=0
	
class=04-03-00, hdrtype=0x00, mfdev=0
	cmdreg=0x0006, statreg=0x0010, 
cachelnsz=16 (dwords)
	lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 
ns)
	intpin=a, irq=10
	powerspec 2  supports D0 D3  current D0
	MSI supports 1 
message, 64 bit
	map[10]: type Memory, range 64, base 0xfbffc000, size 14, 
enabled
pcib7: requested memory range 0xfbffc000-0xfbffffff: good
pcib7: 
matched entry for 128.1.INTA
pcib7: slot 1 INTA hardwired to IRQ 17
hdac0: <VIA 
VT8251/8237A High Definition Audio Controller> mem 0xfbffc000-0xfbffffff irq 17 
at device 1.0 on pci128
hdac0: HDA Driver Revision: 20081226_0122
hdac0: 
Reserved 0x4000 bytes for rid 0x10 type 3 at 0xfbffc000
ioapic0: routing intpin 
17 (PCI IRQ 17) to vector 57
hdac0: [MPSAFE]
hdac0: [ITHREAD]
pcib8: <ACPI PCI-
PCI bridge> at device 19.1 on pci0
pcib8:   domain            0
pcib8:   
secondary bus     7
pcib8:   subordinate bus   7
pcib8:   I/O decode        
0xe000-0xefff
pcib8:   memory decode     0xfbe00000-0xfbefffff
pcib8:   no 
prefetched decode
pcib8:   Subtractively decoded bridge.
pci7: <ACPI PCI bus> 
on pcib8
pci7: domain=0, physical bus=7
found->	vendor=0x10ec, dev=0x8139, 
revid=0x10
	domain=0, bus=7, slot=9, func=0
	class=02-00-00, hdrtype=0x00, 
mfdev=0
	cmdreg=0x0107, statreg=0x0290, cachelnsz=0 (dwords)
	lattimer=0x40 
(1920 ns), mingnt=0x20 (8000 ns), maxlat=0x40 (16000 ns)
	intpin=a, irq=3
	
powerspec 2  supports D0 D1 D2 D3  current D0
	map[10]: type I/O Port, range 
32, base 0xe800, size  8, enabled
pcib8: requested I/O range 0xe800-0xe8ff: in 
range
	map[14]: type Memory, range 32, base 0xfbeffc00, size  8, enabled
pcib8: 
requested memory range 0xfbeffc00-0xfbeffcff: good
pcib8: matched entry for 7.9.
INTA
pcib8: slot 9 INTA hardwired to IRQ 19
rl0: <RealTek 8139 10/100BaseTX> 
port 0xe800-0xe8ff mem 0xfbeffc00-0xfbeffcff irq 19 at device 9.0 on pci7
rl0: 
Reserved 0x100 bytes for rid 0x10 type 4 at 0xe800
miibus1: <MII bus> on rl0

rlphy0: <RealTek internal media interface> PHY 0 on miibus1
rlphy0:  10baseT, 
10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
rl0: bpf attached
rl0: Ethernet 
address: 00:08:a1:27:1f:bb
ioapic0: routing intpin 19 (PCI IRQ 19) to vector 58

rl0: [MPSAFE]
rl0: [ITHREAD]
acpi_button0: <Sleep Button> on acpi0

acpi_button1: <Power Button> on acpi0
fdc0: <floppy drive controller (FDE)> 
port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0
fdc0: ic_type 90 part_id 80

ioapic0: routing intpin 6 (ISA IRQ 6) to vector 59
fdc0: [FILTER]
fd0: <1440-KB 
3.5" drive> on fdc0 drive 0
sio0: configured irq 4 not in bitmap of probed irqs 
0
sio0: port may not be enabled
sio0: irq maps: 0 0 0 0
sio0: configured irq 4 
not in bitmap of probed irqs 0
sio0: port may not be enabled
sio0: irq maps: 0 
0 0 0
sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on 
acpi0
sio0: type 16550A
ioapic0: routing intpin 4 (ISA IRQ 4) to vector 60

sio0: [FILTER]
atkbdc0: <Keyboard controller (i8042)> port 0x60,0x64 irq 1 on 
acpi0
atkbd0: <AT Keyboard> irq 1 on atkbdc0
atkbd: the current kbd controller 
command byte 0065
atkbd: keyboard ID 0x41ab (2)
kbd0 at atkbd0
kbd0: atkbd0, AT 
101/102 (2), config:0x0, flags:0x3d0000
ioapic0: routing intpin 1 (ISA IRQ 1) 
to vector 61
atkbd0: [GIANT-LOCKED]
atkbd0: [ITHREAD]
psm0: unable to allocate 
IRQ
psmcpnp0: <PS/2 mouse port> irq 12 on acpi0
psm0: current command byte:0065

psm0: <PS/2 Mouse> irq 12 on atkbdc0
ioapic0: routing intpin 12 (ISA IRQ 12) to 
vector 62
psm0: [GIANT-LOCKED]
psm0: [ITHREAD]
psm0: model IntelliMouse 
Explorer, device ID 4-00, 5 buttons
psm0: config:00000000, flags:00000008, 
packet size:4
psm0: syncmask:08, syncbits:00
cpu0: <ACPI CPU> on acpi0
cpu0: 
switching to generic Cx mode
acpi_throttle0: <ACPI CPU Throttling> on cpu0

acpi_throttle0: P_CNT from P_BLK 0x810
powernow0: <PowerNow! K8> on cpu0
cpu1: 
<ACPI CPU> on acpi0
powernow1: <PowerNow! K8> on cpu1
ata: ata0 already exists; 
skipping it
ata: ata1 already exists; skipping it
atkbdc: atkbdc0 already 
exists; skipping it
fdc: fdc0 already exists; skipping it
sc: sc0 already 
exists; skipping it
sio: sio0 already exists; skipping it
vga: vga0 already 
exists; skipping it
pnp_identify: Trying Read_Port at 203
pnp_identify: Trying 
Read_Port at 243
pnp_identify: Trying Read_Port at 283
pnp_identify: Trying 
Read_Port at 2c3
pnp_identify: Trying Read_Port at 303
pnp_identify: Trying 
Read_Port at 343
pnp_identify: Trying Read_Port at 383
pnp_identify: Trying 
Read_Port at 3c3
PNP Identify complete
isa_probe_children: disabling PnP 
devices
isa_probe_children: probing non-PnP devices
pmtimer0 on isa0
sc0: 
<System console> at flags 0x100 on isa0
sc0: VGA <16 virtual consoles, 
flags=0x300>
sc0: fb0, kbd1, terminal emulator: sc (syscons terminal)
vga0: 
<Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0
adv0: not 
probed (disabled)
aha0: not probed (disabled)
aic0: not probed (disabled)
bt0: 
not probed (disabled)
cs0: not probed (disabled)
ed0: not probed (disabled)

fe0: not probed (disabled)
ie0: not probed (disabled)
le0: not probed 
(disabled)
ppc0: parallel port found at 0x378
ppc0: using extended I/O port 
range
ppc0: EPP SPP
ppc0: <Parallel port> at port 0x378-0x37f irq 7 on isa0

ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode
ppbus0: <Parallel port 
bus> on ppc0
ioapic0: routing intpin 7 (ISA IRQ 7) to vector 63
ppbus0: 
[MPSAFE]
ppbus0: [ITHREAD]
plip0: <PLIP network interface> on ppbus0
plip0: 
WARNING: using obsoleted IFF_NEEDSGIANT flag
plip0: bpf attached
lpt0: 
<Printer> on ppbus0
lpt0: Interrupt-driven port
ppi0: <Parallel I/O> on ppbus0

ppc0: [GIANT-LOCKED]
ppc0: [ITHREAD]
sio1: configured irq 3 not in bitmap of 
probed irqs 0
sio1: port may not be enabled
sio1: irq maps: 0 0 0 0
sio1: probe 
failed test(s): 0 1 2 4 6 7 9
sio1 failed to probe at port 0x2f8-0x2ff irq 3 on 
isa0
sio2: not probed (disabled)
sio3: not probed (disabled)
sn0: not probed 
(disabled)
vt0: not probed (disabled)
isa_probe_children: probing PnP devices

Device configuration finished.
Reducing kern.maxvnodes 133834 -> 100000
procfs 
registered
lapic: Divisor 2, Frequency 99989356 hz
Timecounter "TSC" frequency 
2499733807 Hz quality -100
Timecounters tick every 1.000 msec
Linux ELF exec 
handler installed
lo0: bpf attached
ata0-slave: pio=PIO4 wdma=WDMA2 
udma=UDMA133 cable=80 wire
ata0-master: pio=PIO4 wdma=WDMA2 udma=UDMA100 
cable=80 wire
ad0: setting PIO4 on 8237A chip
ad0: setting UDMA100 on 8237A 
chip
ad0: 152627MB <MAXTOR STM3160212A 3.AAJ> at ata0-master UDMA100
ad0: 
312581808 sectors [310101C/16H/63S] 16 sectors/interrupt 1 depth queue
ad0: VIA 
check1 failed
ad0: Adaptec check1 failed
ad0: LSI (v3) check1 failed
ad0: LSI 
(v2) check1 failed
ad0: FreeBSD check1 failed
ad1: setting PIO4 on 8237A chip

ad1: setting UDMA133 on 8237A chip
ad1: 117246MB <Maxtor 6Y120L0 YAR41BW0> at 
ata0-slave UDMA133
ad1: 240121728 sectors [238216C/16H/63S] 16 
sectors/interrupt 1 depth queue
ad1: VIA check1 failed
ad1: Adaptec check1 
failed
ad1: LSI (v3) check1 failed
ad1: LSI (v2) check1 failed
ad1: FreeBSD 
check1 failed
ata1-master: pio=PIO4 wdma=WDMA2 udma=UDMA66 cable=80 wire
acd0: 
setting PIO4 on 8237A chip
acd0: setting UDMA66 on 8237A chip
acd0: <PIONEER 
DVD-RW DVR-109/1.58> DVDR drive at ata1 as master
acd0: read 6890KB/s 
(6890KB/s) write 5511KB/s (6890KB/s), 2000KB buffer, UDMA66
acd0: Reads: CDR, 
CDRW, CDDA stream, DVDROM, DVDR, DVDRAM, packet
acd0: Writes: CDR, CDRW, DVDR, 
test write, burnproof
acd0: Audio: play, 256 volume levels
acd0: Mechanism: 
ejectable tray, unlocked
acd0: Medium: no/blank disc
ata2-master: pio=PIO4 
wdma=WDMA2 udma=UDMA133 cable=40 wire
ad4: 238475MB <WDC WD2500KS-00MJB0 02.01
C03> at ata2-master SATA150
ad4: 488397168 sectors [484521C/16H/63S] 16 
sectors/interrupt 1 depth queue
ad4: VIA check1 failed
ad4: Adaptec check1 
failed
ad4: LSI (v3) check1 failed
ad4: LSI (v2) check1 failed
ad4: FreeBSD 
check1 failed
hdac0: Probing codec #0...
hdac0: HDA Codec #0: Realtek ALC660

hdac0:  HDA Codec ID: 0x10ec0660
hdac0:        Vendor: 0x10ec
hdac0:        
Device: 0x0660
hdac0:      Revision: 0x00
hdac0:      Stepping: 0x01
hdac0: PCI 
Subvendor: 0x81e71043
hdac0: 	Found audio FG nid=1 startnode=2 endnode=39 
total=37
hdac0: 
hdac0: Processing audio FG cad=0 nid=1...
hdac0: GPIO: 
0x40000002 NumGPIO=2 NumGPO=0 NumGPI=0 GPIWake=0 GPIUnsol=1
hdac0:  nid 20 
0x01014010 as  1 seq  0      Line-out  Jack jack  1 loc  1 color   Green misc 0

hdac0:  nid 21 0x411111f0 as 15 seq  0       Speaker  None jack  1 loc  1 
color   Black misc 1
hdac0:  nid 22 0x411111f0 as 15 seq  0       Speaker  None 
jack  1 loc  1 color   Black misc 1
hdac0:  nid 23 0x411111f0 as 15 seq  
0       Speaker  None jack  1 loc  1 color   Black misc 1
hdac0:  nid 24 
0x01a19830 as  3 seq  0           Mic  Jack jack  1 loc  1 color    Pink misc 8

hdac0:  nid 25 0x02a1993f as  3 seq 15           Mic  Jack jack  1 loc  2 
color    Pink misc 9
hdac0:  nid 26 0x01813031 as  3 seq  1       Line-in  Jack 
jack  1 loc  1 color    Blue misc 0
hdac0:  nid 27 0x0221411f as  1 seq 15    
Headphones  Jack jack  1 loc  2 color   Green misc 1
hdac0:  nid 28 0x593301f0 
as 15 seq  0            CD  None jack  3 loc 25 color Unknown misc 1
hdac0:  
nid 29 0x411111f0 as 15 seq  0       Speaker  None jack  1 loc  1 color   Black 
misc 1
hdac0:  nid 30 0x01447120 as  2 seq  0     SPDIF-out  Jack jack  4 loc  
1 color  Yellow misc 1
hdac0: Patched pins configuration:
hdac0:  nid 20 
0x01014010 as  1 seq  0      Line-out  Jack jack  1 loc  1 color   Green misc 0

hdac0:  nid 21 0x411111f0 as 15 seq  0       Speaker  None jack  1 loc  1 
color   Black misc 1 [DISABLED]
hdac0:  nid 22 0x411111f0 as 15 seq  0       
Speaker  None jack  1 loc  1 color   Black misc 1 [DISABLED]
hdac0:  nid 23 
0x411111f0 as 15 seq  0       Speaker  None jack  1 loc  1 color   Black misc 1 
[DISABLED]
hdac0:  nid 24 0x01a19830 as  3 seq  0           Mic  Jack jack  1 
loc  1 color    Pink misc 8
hdac0:  nid 25 0x02a1993f as  3 seq 15           
Mic  Jack jack  1 loc  2 color    Pink misc 9
hdac0:  nid 26 0x01813031 as  3 
seq  1       Line-in  Jack jack  1 loc  1 color    Blue misc 0
hdac0:  nid 27 
0x0221411f as  1 seq 15    Headphones  Jack jack  1 loc  2 color   Green misc 1

hdac0:  nid 28 0x593301f0 as 15 seq  0            CD  None jack  3 loc 25 color 
Unknown misc 1 [DISABLED]
hdac0:  nid 29 0x411111f0 as 15 seq  0       Speaker  
None jack  1 loc  1 color   Black misc 1 [DISABLED]
hdac0:  nid 30 0x01447120 
as  2 seq  0     SPDIF-out  Jack jack  4 loc  1 color  Yellow misc 1
hdac0: 3 
associations found:
hdac0: Association 0 (1) out:
hdac0:  Pin nid=20 seq=0

hdac0:  Pin nid=27 seq=15
hdac0: Association 1 (2) out:
hdac0:  Pin nid=30 
seq=0
hdac0: Association 2 (3) in:
hdac0:  Pin nid=24 seq=0
hdac0:  Pin nid=26 
seq=1
hdac0:  Pin nid=25 seq=15
hdac0: Tracing association 0 (1)
hdac0:  Pin 20 
traced to DAC 2
hdac0:  Pin 27 traced to DAC 2 and hpredir 0
hdac0: Association 
0 (1) trace succeded
hdac0: Tracing association 1 (2)
hdac0:  Pin 30 traced to 
DAC 6
hdac0: Association 1 (2) trace succeded
hdac0: Tracing association 2 (3)

hdac0:  Pin 24 traced to ADC 9
hdac0:  Pin 26 traced to ADC 9
hdac0:  Pin 25 
traced to ADC 9
hdac0: Association 2 (3) trace succeded
hdac0: Tracing input 
monitor
hdac0:  Tracing nid 11 to out
hdac0:  nid 11 is input monitor
hdac0:  
Tracing nid 34 to out
hdac0: Tracing beeper
hdac0: No jack detection support at 
pin 27
hdac0: FG config/quirks: forcestereo ivref50 ivref80 ivref100 ivref

hdac0: 
hdac0: +-------------------+
hdac0: | DUMPING HDA NODES |
hdac0: 
+-------------------+
hdac0: 
hdac0: Default Parameter
hdac0: -----------------

hdac0:      Stream cap: 0x00000001
hdac0:                  PCM
hdac0:         
PCM cap: 0x000e0160
hdac0:                  16 20 24 bits, 44 48 96 KHz

hdac0:          IN amp: 0x00000000
hdac0:         OUT amp: 0x00000000
hdac0: 

hdac0:             nid: 2
hdac0:            Name: audio output
hdac0:      
Widget cap: 0x0000001d
hdac0:                  STEREO
hdac0:     Association: 0 
(0x00008001)
hdac0:             OSS: pcm (pcm)
hdac0:      Stream cap: 
0x00000001
hdac0:                  PCM
hdac0:         PCM cap: 0x000e0160

hdac0:                  16 20 24 bits, 44 48 96 KHz
hdac0:      Output amp: 
0x00034040
hdac0:                  mute=0 step=64 size=3 offset=64
hdac0: 

hdac0:             nid: 3 [DISABLED]
hdac0:            Name: audio output

hdac0:      Widget cap: 0x0000001d
hdac0:                  STEREO
hdac0:      
Stream cap: 0x00000001
hdac0:                  PCM
hdac0:         PCM cap: 
0x000e0160
hdac0:                  16 20 24 bits, 44 48 96 KHz
hdac0:      
Output amp: 0x00034040
hdac0:                  mute=0 step=64 size=3 offset=64

hdac0: 
hdac0:             nid: 4 [DISABLED]
hdac0:            Name: audio 
output
hdac0:      Widget cap: 0x0000001d
hdac0:                  STEREO

hdac0:      Stream cap: 0x00000001
hdac0:                  PCM
hdac0:         
PCM cap: 0x000e0160
hdac0:                  16 20 24 bits, 44 48 96 KHz

hdac0:      Output amp: 0x00034040
hdac0:                  mute=0 step=64 
size=3 offset=64
hdac0: 
hdac0:             nid: 5 [DISABLED]
hdac0:            
Name: audio output
hdac0:      Widget cap: 0x0000001d
hdac0:                  
STEREO
hdac0:      Stream cap: 0x00000001
hdac0:                  PCM

hdac0:         PCM cap: 0x000e0160
hdac0:                  16 20 24 bits, 44 48 
96 KHz
hdac0:      Output amp: 0x00034040
hdac0:                  mute=0 
step=64 size=3 offset=64
hdac0: 
hdac0:             nid: 6
hdac0:            
Name: audio output
hdac0:      Widget cap: 0x00000211
hdac0:                  
DIGITAL STEREO
hdac0:     Association: 1 (0x00000001)
hdac0:             OSS: 
pcm (pcm)
hdac0:      Stream cap: 0x00000001
hdac0:                  PCM

hdac0:         PCM cap: 0x001e0160
hdac0:                  16 20 24 32 bits, 44 
48 96 KHz
hdac0: 
hdac0:             nid: 7 [DISABLED]
hdac0:            Name: 
vendor widget
hdac0:      Widget cap: 0x00f00000
hdac0: 
hdac0:             
nid: 8 [DISABLED]
hdac0:            Name: vendor widget
hdac0:      Widget cap: 
0x00f00000
hdac0: 
hdac0:             nid: 9
hdac0:            Name: audio 
input
hdac0:      Widget cap: 0x0010011b
hdac0:                  STEREO

hdac0:     Association: 2 (0x00008003)
hdac0:      Stream cap: 0x00000001

hdac0:                  PCM
hdac0:         PCM cap: 0x00060160

hdac0:                  16 20 bits, 44 48 96 KHz
hdac0:       Input amp: 
0x80051f09
hdac0:                  mute=1 step=31 size=5 offset=9
hdac0:     
connections: 1
hdac0:           |
hdac0:           + <- nid=34 [audio mixer]

hdac0: 
hdac0:             nid: 10 [DISABLED]
hdac0:            Name: vendor 
widget
hdac0:      Widget cap: 0x00f00000
hdac0: 
hdac0:             nid: 11

hdac0:            Name: audio mixer
hdac0:      Widget cap: 0x0020010b

hdac0:                  STEREO
hdac0:     Association: -2 (0x00008003)

hdac0:             OSS: mix (mix)
hdac0:       Input amp: 0x80051f17

hdac0:                  mute=1 step=31 size=5 offset=23
hdac0:     connections: 
6
hdac0:           |
hdac0:           + <- nid=24 [pin: Mic (Jack)]

hdac0:           + <- nid=25 [pin: Mic (Jack)]
hdac0:           + <- nid=26 
[pin: Line-in (Jack)]
hdac0:           + [DISABLED] <- nid=27 [pin: Headphones 
(Jack)]
hdac0:           + [DISABLED] <- nid=28 [pin: CD (None)] [DISABLED]

hdac0:           + [DISABLED] <- nid=29 [pin: Speaker (None)] [DISABLED]

hdac0: 
hdac0:             nid: 12
hdac0:            Name: audio mixer

hdac0:      Widget cap: 0x0020010b
hdac0:                  STEREO
hdac0:     
Association: 0 (0x00008001)
hdac0:             OSS: pcm, mix
hdac0:       Input 
amp: 0x80000000
hdac0:                  mute=1 step=0 size=0 offset=0

hdac0:     connections: 2
hdac0:           |
hdac0:           + <- nid=2 [audio 
output]
hdac0:           + <- nid=11 [audio mixer]
hdac0: 
hdac0:             
nid: 13 [DISABLED]
hdac0:            Name: audio mixer
hdac0:      Widget cap: 
0x0020010b
hdac0:                  STEREO
hdac0:       Input amp: 0x80000000

hdac0:                  mute=1 step=0 size=0 offset=0
hdac0:     connections: 2

hdac0:           |
hdac0:           + [DISABLED] <- nid=3 [audio output] 
[DISABLED]
hdac0:           + [DISABLED] <- nid=11 [audio mixer]
hdac0: 

hdac0:             nid: 14 [DISABLED]
hdac0:            Name: audio mixer

hdac0:      Widget cap: 0x0020010b
hdac0:                  STEREO
hdac0:       
Input amp: 0x80000000
hdac0:                  mute=1 step=0 size=0 offset=0

hdac0:     connections: 2
hdac0:           |
hdac0:           + [DISABLED] <- 
nid=4 [audio output] [DISABLED]
hdac0:           + [DISABLED] <- nid=11 [audio 
mixer]
hdac0: 
hdac0:             nid: 15 [DISABLED]
hdac0:            Name: 
audio mixer
hdac0:      Widget cap: 0x0020010b
hdac0:                  STEREO

hdac0:     Association: -2 (0x00000000)
hdac0:       Input amp: 0x80000000

hdac0:                  mute=1 step=0 size=0 offset=0
hdac0:     connections: 2

hdac0:           |
hdac0:           + [DISABLED] <- nid=5 [audio output] 
[DISABLED]
hdac0:           + [DISABLED] <- nid=11 [audio mixer]
hdac0: 

hdac0:             nid: 16 [DISABLED]
hdac0:            Name: vendor widget

hdac0:      Widget cap: 0x00f00000
hdac0: 
hdac0:             nid: 17 
[DISABLED]
hdac0:            Name: vendor widget
hdac0:      Widget cap: 
0x00f00000
hdac0: 
hdac0:             nid: 18 [DISABLED]
hdac0:            
Name: vendor widget
hdac0:      Widget cap: 0x00f00000
hdac0: 

hdac0:             nid: 19 [DISABLED]
hdac0:            Name: vendor widget

hdac0:      Widget cap: 0x00f00000
hdac0: 
hdac0:             nid: 20

hdac0:            Name: pin: Line-out (Jack)
hdac0:      Widget cap: 0x0040018d

hdac0:                  UNSOL STEREO
hdac0:     Association: 0 (0x00000001)

hdac0:         Pin cap: 0x0001003c
hdac0:                  PDC HP OUT IN EAPD

hdac0:      Pin config: 0x01014010
hdac0:     Pin control: 0x00000040 OUT

hdac0:            EAPD: 0x00000002
hdac0:      Output amp: 0x80000000

hdac0:                  mute=1 step=0 size=0 offset=0
hdac0:     connections: 1

hdac0:           |
hdac0:           + <- nid=12 [audio mixer]
hdac0: 

hdac0:             nid: 21 [DISABLED]
hdac0:            Name: pin: Speaker 
(None)
hdac0:      Widget cap: 0x0040018d
hdac0:                  UNSOL STEREO

hdac0:         Pin cap: 0x00010034
hdac0:                  PDC OUT IN EAPD

hdac0:      Pin config: 0x411111f0
hdac0:     Pin control: 0x00000000

hdac0:            EAPD: 0x00000002
hdac0:      Output amp: 0x80000000

hdac0:                  mute=1 step=0 size=0 offset=0
hdac0:     connections: 1

hdac0:           |
hdac0:           + [DISABLED] <- nid=13 [audio mixer] 
[DISABLED]
hdac0: 
hdac0:             nid: 22 [DISABLED]
hdac0:            
Name: pin: Speaker (None)
hdac0:      Widget cap: 0x0040018d

hdac0:                  UNSOL STEREO
hdac0:         Pin cap: 0x00000034

hdac0:                  PDC OUT IN
hdac0:      Pin config: 0x411111f0

hdac0:     Pin control: 0x00000000
hdac0:      Output amp: 0x80000000

hdac0:                  mute=1 step=0 size=0 offset=0
hdac0:     connections: 1

hdac0:           |
hdac0:           + [DISABLED] <- nid=14 [audio mixer] 
[DISABLED]
hdac0: 
hdac0:             nid: 23 [DISABLED]
hdac0:            
Name: pin: Speaker (None)
hdac0:      Widget cap: 0x0040018d

hdac0:                  UNSOL STEREO
hdac0:         Pin cap: 0x00000034

hdac0:                  PDC OUT IN
hdac0:      Pin config: 0x411111f0

hdac0:     Pin control: 0x00000000
hdac0:      Output amp: 0x80000000

hdac0:                  mute=1 step=0 size=0 offset=0
hdac0:     connections: 1

hdac0:           |
hdac0:           + [DISABLED] <- nid=15 [audio mixer] 
[DISABLED]
hdac0: 
hdac0:             nid: 24
hdac0:            Name: pin: Mic 
(Jack)
hdac0:      Widget cap: 0x0040018f
hdac0:                  UNSOL STEREO

hdac0:     Association: 2 (0x00000001)
hdac0:             OSS: mic (mic)

hdac0:         Pin cap: 0x00001734
hdac0:                  PDC OUT IN VREF[ 50 
80 GROUND HIZ ]
hdac0:      Pin config: 0x01a19830
hdac0:     Pin control: 
0x00000024 IN VREFs
hdac0:      Output amp: 0x80000000
hdac0:                  
mute=1 step=0 size=0 offset=0
hdac0:       Input amp: 0x00270300

hdac0:                  mute=0 step=3 size=39 offset=0
hdac0:     connections: 
1
hdac0:           |
hdac0:           + [DISABLED] <- nid=14 [audio mixer] 
[DISABLED]
hdac0: 
hdac0:             nid: 25
hdac0:            Name: pin: Mic 
(Jack)
hdac0:      Widget cap: 0x0040018f
hdac0:                  UNSOL STEREO

hdac0:     Association: 2 (0x00008000)
hdac0:             OSS: monitor 
(monitor)
hdac0:         Pin cap: 0x0000173c
hdac0:                  PDC HP OUT 
IN VREF[ 50 80 GROUND HIZ ]
hdac0:      Pin config: 0x02a1993f
hdac0:     Pin 
control: 0x00000024 IN VREFs
hdac0:      Output amp: 0x80000000

hdac0:                  mute=1 step=0 size=0 offset=0
hdac0:       Input amp: 
0x00270300
hdac0:                  mute=0 step=3 size=39 offset=0
hdac0:     
connections: 2
hdac0:           |
hdac0:           + [DISABLED] <- nid=12 
[audio mixer] (selected)
hdac0:           + [DISABLED] <- nid=15 [audio mixer] 
[DISABLED]
hdac0: 
hdac0:             nid: 26
hdac0:            Name: pin: Line-
in (Jack)
hdac0:      Widget cap: 0x0040018d
hdac0:                  UNSOL 
STEREO
hdac0:     Association: 2 (0x00000002)
hdac0:             OSS: line 
(line)
hdac0:         Pin cap: 0x00000034
hdac0:                  PDC OUT IN

hdac0:      Pin config: 0x01813031
hdac0:     Pin control: 0x00000020 IN

hdac0:      Output amp: 0x80000000
hdac0:                  mute=1 step=0 size=0 
offset=0
hdac0:     connections: 1
hdac0:           |
hdac0:           + 
[DISABLED] <- nid=13 [audio mixer] [DISABLED]
hdac0: 
hdac0:             nid: 
27
hdac0:            Name: pin: Headphones (Jack)
hdac0:      Widget cap: 
0x0040018f
hdac0:                  UNSOL STEREO
hdac0:     Association: 0 
(0x00008000)
hdac0:         Pin cap: 0x0000173c
hdac0:                  PDC HP 
OUT IN VREF[ 50 80 GROUND HIZ ]
hdac0:      Pin config: 0x0221411f
hdac0:     
Pin control: 0x000000c0 HP OUT
hdac0:      Output amp: 0x80000000

hdac0:                  mute=1 step=0 size=0 offset=0
hdac0:       Input amp: 
0x00270300
hdac0:                  mute=0 step=3 size=39 offset=0
hdac0:     
connections: 2
hdac0:           |
hdac0:           + <- nid=12 [audio mixer] 
(selected)
hdac0:           + [DISABLED] <- nid=15 [audio mixer] [DISABLED]

hdac0: 
hdac0:             nid: 28 [DISABLED]
hdac0:            Name: pin: CD 
(None)
hdac0:      Widget cap: 0x00400001
hdac0:                  STEREO

hdac0:         Pin cap: 0x00000020
hdac0:                  IN
hdac0:      Pin 
config: 0x593301f0
hdac0:     Pin control: 0x00000000
hdac0: 

hdac0:             nid: 29 [DISABLED]
hdac0:            Name: pin: Speaker 
(None)
hdac0:      Widget cap: 0x00400000
hdac0:         Pin cap: 0x00000020

hdac0:                  IN
hdac0:      Pin config: 0x411111f0
hdac0:     Pin 
control: 0x00000000
hdac0: 
hdac0:             nid: 30
hdac0:            Name: 
pin: SPDIF-out (Jack)
hdac0:      Widget cap: 0x00400300

hdac0:                  DIGITAL
hdac0:     Association: 1 (0x00000001)

hdac0:         Pin cap: 0x00000010
hdac0:                  OUT
hdac0:      Pin 
config: 0x01447120
hdac0:     Pin control: 0x00000040 OUT
hdac0:     
connections: 1
hdac0:           |
hdac0:           + <- nid=6 [audio output]

hdac0: 
hdac0:             nid: 31 [DISABLED]
hdac0:            Name: vendor 
widget
hdac0:      Widget cap: 0x00f00000
hdac0: 
hdac0:             nid: 32 
[DISABLED]
hdac0:            Name: vendor widget
hdac0:      Widget cap: 
0x00f00040
hdac0:                  PROC
hdac0: 
hdac0:             nid: 33 
[DISABLED]
hdac0:            Name: vendor widget
hdac0:      Widget cap: 
0x00f00000
hdac0: 
hdac0:             nid: 34
hdac0:            Name: audio 
mixer
hdac0:      Widget cap: 0x0020010b
hdac0:                  STEREO

hdac0:     Association: 2 (0x00008003)
hdac0:             OSS: line, mic, mix, 
monitor
hdac0:       Input amp: 0x80000000
hdac0:                  mute=1 
step=0 size=0 offset=0
hdac0:     connections: 11
hdac0:           |

hdac0:           + <- nid=24 [pin: Mic (Jack)]
hdac0:           + <- nid=25 
[pin: Mic (Jack)]
hdac0:           + <- nid=26 [pin: Line-in (Jack)]

hdac0:           + [DISABLED] <- nid=27 [pin: Headphones (Jack)]

hdac0:           + [DISABLED] <- nid=28 [pin: CD (None)] [DISABLED]

hdac0:           + [DISABLED] <- nid=29 [pin: Speaker (None)] [DISABLED]

hdac0:           + [DISABLED] <- nid=20 [pin: Line-out (Jack)]
hdac0:           
+ [DISABLED] <- nid=21 [pin: Speaker (None)] [DISABLED]
hdac0:           + 
[DISABLED] <- nid=22 [pin: Speaker (None)] [DISABLED]
hdac0:           + 
[DISABLED] <- nid=23 [pin: Speaker (None)] [DISABLED]
hdac0:           + <- 
nid=11 [audio mixer]
hdac0: 
hdac0:             nid: 35 [DISABLED]

hdac0:            Name: vendor widget
hdac0:      Widget cap: 0x00f00000

hdac0: 
hdac0:             nid: 36 [DISABLED]
hdac0:            Name: vendor 
widget
hdac0:      Widget cap: 0x00f00000
hdac0: 
hdac0:             nid: 37 
[DISABLED]
hdac0:            Name: vendor widget
hdac0:      Widget cap: 
0x00f00000
hdac0: 
hdac0:             nid: 38 [DISABLED]
hdac0:            
Name: vendor widget
hdac0:      Widget cap: 0x00f00000
hdac0: 
pcm0: <HDA 
Realtek ALC660 PCM #0 Analog> at cad 0 nid 1 on hdac0
pcm0: 
+--------------------------------------+
pcm0: | DUMPING PCM Playback/Record 
Channels |
pcm0: +--------------------------------------+
pcm0: 
pcm0: 
Playback:
pcm0: 
pcm0:      Stream cap: 0x00000001
pcm0:                  PCM

pcm0:         PCM cap: 0x000e0160
pcm0:                  16 20 24 bits, 44 48 
96 KHz
pcm0:             DAC: 2
pcm0: 
pcm0: Record:
pcm0: 
pcm0:      Stream 
cap: 0x00000001
pcm0:                  PCM
pcm0:         PCM cap: 0x00060160

pcm0:                  16 20 bits, 44 48 96 KHz
pcm0:             ADC: 9
pcm0: 

pcm0: +--------------------------------+
pcm0: | DUMPING Playback/Record Pathes 
|
pcm0: +--------------------------------+
pcm0: 
pcm0: Playback:
pcm0: 

pcm0:     nid=20 [pin: Line-out (Jack)]
pcm0:       |
pcm0:       + <- nid=12 
[audio mixer] [src: pcm, mix]
pcm0:              |
pcm0:              + <- 
nid=2 [audio output] [src: pcm]
pcm0:              + <- nid=11 [audio mixer] 
[src: mix]
pcm0: 
pcm0:     nid=27 [pin: Headphones (Jack)]
pcm0:       |

pcm0:       + <- nid=12 [audio mixer] [src: pcm, mix]
pcm0:              |

pcm0:              + <- nid=2 [audio output] [src: pcm]
pcm0:              + <- 
nid=11 [audio mixer] [src: mix]
pcm0: 
pcm0: Record:
pcm0: 
pcm0:     nid=9 
[audio input]
pcm0:       |
pcm0:       + <- nid=34 [audio mixer] [src: line, 
mic, mix, monitor]
pcm0:              |
pcm0:              + <- nid=24 [pin: 
Mic (Jack)] [src: mic]
pcm0:              + <- nid=25 [pin: Mic (Jack)] [src: 
monitor]
pcm0:              + <- nid=26 [pin: Line-in (Jack)] [src: line]

pcm0:              + <- nid=11 [audio mixer] [src: mix]
pcm0: 
pcm0: Input Mix:

pcm0: 
pcm0:     nid=11 [audio mixer]
pcm0:       |
pcm0:       + <- nid=24 
[pin: Mic (Jack)] [src: mic]
pcm0:       + <- nid=25 [pin: Mic (Jack)] [src: 
monitor]
pcm0:       + <- nid=26 [pin: Line-in (Jack)] [src: line]
pcm0: 
pcm0: 
+-------------------------+
pcm0: | DUMPING Volume Controls |
pcm0: 
+-------------------------+
pcm0: 
pcm0: Master Volume (OSS: vol)
pcm0:    |

pcm0:    +- ctl  1 (nid   2 out):    -64/0dB (65 steps)
pcm0:    +- ctl 12 
(nid  12 in   0): mute
pcm0:    +- ctl 13 (nid  12 in   1): mute
pcm0:    +- 
ctl 20 (nid  20 in ):    mute
pcm0:    +- ctl 29 (nid  27 in ):    mute
pcm0: 

pcm0: PCM Volume (OSS: pcm)
pcm0:    |
pcm0:    +- ctl  1 (nid   2 out):    -64
/0dB (65 steps)
pcm0:    +- ctl 12 (nid  12 in   0): mute
pcm0: 
pcm0: 
Microphone Volume (OSS: mic)
pcm0:    |
pcm0:    +- ctl 25 (nid  24 out):    
0/30dB (4 steps)
pcm0:    +- ctl 31 (nid  34 in   0): mute
pcm0: 
pcm0: 
Microphone2 Volume (OSS: monitor)
pcm0:    |
pcm0:    +- ctl 27 (nid  25 
out):    0/30dB (4 steps)
pcm0:    +- ctl 32 (nid  34 in   1): mute
pcm0: 

pcm0: Line-in Volume (OSS: line)
pcm0:    |
pcm0:    +- ctl  8 (nid  11 in   
2): -34/12dB (32 steps) + mute
pcm0:    +- ctl 33 (nid  34 in   2): mute
pcm0: 

pcm0: Recording Level (OSS: rec)
pcm0:    |
pcm0:    +- ctl  5 (nid   9 in   
0): -13/33dB (32 steps) + mute
pcm0:    +- ctl 31 (nid  34 in   0): mute

pcm0:    +- ctl 32 (nid  34 in   1): mute
pcm0:    +- ctl 33 (nid  34 in   2): 
mute
pcm0:    +- ctl 41 (nid  34 in  10): mute
pcm0: 
pcm0: Input Mix Level 
(OSS: mix)
pcm0:    |
pcm0:    +- ctl  6 (nid  11 in   0): -34/12dB (32 steps) 
+ mute
pcm0:    +- ctl  7 (nid  11 in   1): -34/12dB (32 steps) + mute
pcm0:    
+- ctl  8 (nid  11 in   2): -34/12dB (32 steps) + mute
pcm0:    +- ctl 13 (nid  
12 in   1): mute
pcm0:    +- ctl 41 (nid  34 in  10): mute
pcm0: 
pcm0: Mixer 
"vol":
pcm0: Mixer "pcm":
pcm0: Mixer "line":
pcm0: Mixer "mic":
pcm0: Mixer 
"mix":
pcm0: Mixer "rec":
pcm0: Mixer "ogain":
pcm0: Mixer "monitor":
pcm0: 
clone manager: deadline=750ms flags=0x8000001e
pcm0: sndbuf_setmap 19d0000, 
4000; 0xf25ee000 -> 19d0000
pcm0: sndbuf_setmap 19e0000, 4000; 0xf25fe000 -> 
19e0000
pcm1: <HDA Realtek ALC660 PCM #1 Digital> at cad 0 nid 1 on hdac0
pcm1: 
+--------------------------------------+
pcm1: | DUMPING PCM Playback/Record 
Channels |
pcm1: +--------------------------------------+
pcm1: 
pcm1: 
Playback:
pcm1: 
pcm1:      Stream cap: 0x00000005
pcm1:                  AC3 
PCM
pcm1:         PCM cap: 0x001e0160
pcm1:                  16 20 24 32 bits, 
44 48 96 KHz
pcm1:             DAC: 6
pcm1: 
pcm1: 
+--------------------------------+
pcm1: | DUMPING Playback/Record Pathes |

pcm1: +--------------------------------+
pcm1: 
pcm1: Playback:
pcm1: 

pcm1:     nid=30 [pin: SPDIF-out (Jack)]
pcm1:       |
pcm1:       + <- nid=6 
[audio output] [src: pcm]
pcm1: 
pcm1: +-------------------------+
pcm1: | 
DUMPING Volume Controls |
pcm1: +-------------------------+
pcm1: 
pcm1: clone 
manager: deadline=750ms flags=0x8000001e
pcm1: sndbuf_setmap 19f0000, 4000; 
0xf260e000 -> 19f0000
ATA PseudoRAID loaded
SMP: AP CPU #1 Launched!
cpu1 AP:

     ID: 0x01000000   VER: 0x80050010 LDR: 0x00000000 DFR: 0xffffffff
  lint0: 
0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff
  timer: 
0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010000
ioapic0: Assigning 
ISA IRQ 1 to local APIC 0
ioapic0: Assigning ISA IRQ 4 to local APIC 1
ioapic0: 
Assigning ISA IRQ 6 to local APIC 0
ioapic0: Assigning ISA IRQ 7 to local APIC 
1
ioapic0: Assigning ISA IRQ 9 to local APIC 0
ioapic0: Assigning ISA IRQ 12 to 
local APIC 1
ioapic0: Assigning ISA IRQ 14 to local APIC 0
ioapic0: Assigning 
ISA IRQ 15 to local APIC 1
ioapic0: Assigning PCI IRQ 17 to local APIC 0

ioapic0: Assigning PCI IRQ 19 to local APIC 1
ioapic0: Assigning PCI IRQ 20 to 
local APIC 0
ioapic0: Assigning PCI IRQ 21 to local APIC 1
ioapic0: Assigning 
PCI IRQ 22 to local APIC 0
ioapic0: Assigning PCI IRQ 23 to local APIC 1

ioapic1: Assigning PCI IRQ 24 to local APIC 0
msi: Assigning MSI IRQ 256 to 
local APIC 1
GEOM: new disk ad0
GEOM: new disk ad1
GEOM: new disk ad4

GEOM_LABEL: Label for provider ad0s3 is ext2fs//boot.
GEOM_LABEL: Label for 
provider ad0s6 is ext2fs//.
Trying to mount root from ufs:/dev/ad4s3a

start_init: trying /sbin/init
Loading configuration files.
kernel dumps on 
/dev/ad4s1b
Entropy harvesting:
 interrupts
 ethernet
 point_to_point
 
kickstart
.
swapon: adding /dev/ad4s1b as swap device
Starting file system 
checks:
/dev/ad4s3a: FILE SYSTEM CLEAN; SKIPPING CHECKS
/dev/ad4s3a: clean, 
130298 free (810 frags, 16186 blocks, 0.3% fragmentation)
/dev/ad4s3e: FILE 
SYSTEM CLEAN; SKIPPING CHECKS
/dev/ad4s3e: clean, 253810 free (34 frags, 31722 
blocks, 0.0% fragmentation)
/dev/ad4s3f: FILE SYSTEM CLEAN; SKIPPING CHECKS

/dev/ad4s3f: clean, 9049239 free (153383 frags, 1111982 blocks, 0.4% 
fragmentation)
/dev/ad4s3d: FILE SYSTEM CLEAN; SKIPPING CHECKS
/dev/ad4s3d: 
clean, 433258 free (14530 frags, 52341 blocks, 2.9% fragmentation)
Setting 
hostuuid: f89ccdb1-74fe-d511-b528-2f563787098a.
Setting hostid: 0xf899dcf2.

Mounting local file systems:
linprocfs registered
.
Setting hostname: satanasso.
local.net.
net.inet6.ip6.auto_linklocal: 
1
 -> 
0

hw.snd.maxautovchans: 
16
 -
> 
8

hw.snd.compat_linux_mmap: 
0
 -> 
1

compat.linux.osrelease: 
2.4.2
 -> 

2.6.16

hw.syscons.bell: 
1
 -> 
0

age0: interrupt moderation is 100 us.
age0: 
no link ...
.
 got link
age0: interrupt moderation is 100 us.
DHCPREQUEST on 
age0 to 255.255.255.255 port 67

DHCPACK from 192.168.1.1

age0: interrupt 
moderation is 100 us.
bound to 192.168.1.4 -- renewal in 129600 seconds.

rl0: 
no link ...
.
 got link
DHCPREQUEST on rl0 to 255.255.255.255 port 67

DHCPACK 
from 192.168.1.1

bound to 192.168.1.2 -- renewal in 129600 seconds.

lo0: 
flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
	inet6 fe80::1%lo0 
prefixlen 64 scopeid 0x4 
	inet6 ::1 prefixlen 128 
	inet 127.0.0.1 netmask 
0xff000000 
age0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 
mtu 1500
	options=319b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,
WOL_MCAST,WOL_MAGIC>
	ether 00:1a:92:36:72:21
	inet 192.168.1.4 netmask 
0xffffff00 broadcast 192.168.1.255
	media: Ethernet autoselect (100baseTX <full-
duplex>)
	status: active
rl0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,
MULTICAST> metric 0 mtu 1500
	options=8<VLAN_MTU>
	ether 00:08:a1:27:1f:bb
	
inet 192.168.1.2 netmask 0xffffff00 broadcast 192.168.1.255
	media: Ethernet 
autoselect (100baseTX <full-duplex>)
	status: active
Additional routing 
options:
.
Starting devd.
hw.acpi.cpu.cx_lowest: 
C1
 -> 
C1

Additional IP 
options:
.
Mounting NFS file systems:
.
ELF ldconfig path: /lib /usr/lib 
/usr/lib/compat /usr/local/lib /usr/local/lib/compat/pkg /usr/local/lib/compat 
/usr/local/lib/compat/pkg /usr/local/lib/lua51 /usr/local/lib/nss
a.out 
ldconfig path: /usr/lib/aout /usr/lib/compat/aout
Clearing /tmp.
Creating 
and/or trimming log files:
.
Starting syslogd.
Checking for core dump on 
/dev/ad4s1b...
savecore: no dumps found
Initial i386 initialization:
.

Additional ABI support:
.
Removing stale Samba tdb files: 
 done
Starting local 
daemons:
.
Updating motd
.
Mounting late file systems:
.
Configuring syscons:
 
keymap
 keyrate
 font8x16
 font8x14
 font8x8
 blanktime
 screensaver
splash: 
image decoder found: logo_saver
 allscreens
.
Starting default moused:
.

Starting sshd.
Starting cron.
Local package initialization:
.
Starting 
background file system checks in 60 seconds.



Best regards
Barbara

From jh at saunalahti.fi  Sat Jan 10 13:41:11 2009
From: jh at saunalahti.fi (Jaakko Heinonen)
Date: Sat Jan 10 13:41:18 2009
Subject: 2 (very old) bugs?
In-Reply-To: <496819DB.1030601@FreeBSD.org>
References: <EFD58FB6-55C8-4903-BCB1-1C9E4852C271@diablotin.fr>
	<496819DB.1030601@FreeBSD.org>
Message-ID: <20090110132401.GA780@a91-153-125-115.elisa-laajakaista.fi>


Hi,

On 2009-01-09, Doug Barton wrote:
> Yannick Cadin wrote:
> > - first in the stat command. Only with the -x option. If you execute
> > stat -x on /tmp or /usr/bin/passwd parameters for example, the numeric
> > representation of mode is wrong. The "special" bits are always 0. No
> > suid-bit, no sticky bit!
> 
> Our version of stat(1) is essentially an exact duplicate of the code
> from NetBSD. I imported this originally, but I have not not had time
> to merge changes for a while now. If anyone is interested in taking
> this on have a look at:
> 
> http://cvsweb.netbsd.org/bsdweb.cgi/src/usr.bin/stat/

The reported bug still exists in the NetBSD version too. I believe that
the following patch fixes the bug:

%%%
Index: usr.bin/stat/stat.c
===================================================================
--- usr.bin/stat/stat.c	(revision 186786)
+++ usr.bin/stat/stat.c	(working copy)
@@ -108,7 +108,8 @@ __FBSDID("$FreeBSD$");
 #define LINUX_FORMAT \
 	"  File: \"%N\"%n" \
 	"  Size: %-11z  FileType: %HT%n" \
-	"  Mode: (%04OLp/%.10Sp)         Uid: (%5u/%8Su)  Gid: (%5g/%8Sg)%n" \
+	"  Mode: (%OMp%03OLp/%.10Sp)         " \
+	"Uid: (%5u/%8Su)  Gid: (%5g/%8Sg)%n" \
 	"Device: %Hd,%Ld   Inode: %i    Links: %l%n" \
 	"Access: %Sa%n" \
 	"Modify: %Sm%n" \
%%%

-- 
Jaakko
From avg at icyb.net.ua  Sat Jan 10 13:57:41 2009
From: avg at icyb.net.ua (Andriy Gapon)
Date: Sat Jan 10 13:57:49 2009
Subject: pciconf: incorrect description for Marvell 88SX6101 chip
In-Reply-To: <4926B42E.2010408@icyb.net.ua>
References: <4926B42E.2010408@icyb.net.ua>
Message-ID: <4968A950.8000806@icyb.net.ua>

on 21/11/2008 15:14 Andriy Gapon said the following:
> I wasn't sure where this belongs, so writing here.
> This is stable/7 on Intel DG33TL:
> 
> $ pciconf -lv
> ...
> atapci0@pci0:3:0:0:     class=0x01018f card=0x610111ab chip=0x610111ab
> rev=0xb2 hdr=0x00
>     vendor     = 'Marvell Semiconductor (Was: Galileo Technology Ltd)'
>     device     = '6101 SATA2 Controller'
>     class      = mass storage
>     subclass   = ATA
> ...
> 
> This is actually a PATA controller (SATA is provided by ICH9).
> lspci is more correct:
> $ lspci -v
> ...
> 03:00.0 IDE interface: Marvell Technology Group Ltd. 88SE6101
> single-port PATA133 interface (rev b2) (prog-if 8f [Master SecP SecO
> PriP PriO])
>         Subsystem: Marvell Technology Group Ltd. 88SE6101 single-port
> PATA133 interface
> ...
> 
> ATA driver is also cool:
> atapci0: <Marvell 88SX6101 UDMA133 controller>
> 

This is very minor but still...
Here's a tiny patch.
diff --git a/share/misc/pci_vendors b/share/misc/pci_vendors
index 8286310..c92d12e 100644
--- a/share/misc/pci_vendors
+++ b/share/misc/pci_vendors
@@ -4606,7 +4606,7 @@
 	6041	MV88SX6041 Marvell Technology Group Ltd. MV88SX6041 4-port SATA
II PCI-X Controller (rev 03)
 	6042	MV88SX6042 4-port SATA II PCI-X Controller
 	6081	MV88SX6081 8-port SATA II PCI-X Controller
-	6101	6101 SATA2 Controller
+	6101	MV88SX6101 1-port UltraATA/133 Controller
 	6111	6111 SATA2 Controller
 	6120	6120 SATA2 Controller
 	6121	6121 SATA2 Controller



-- 
Andriy Gapon
From avg at icyb.net.ua  Sat Jan 10 14:20:04 2009
From: avg at icyb.net.ua (Andriy Gapon)
Date: Sat Jan 10 14:20:10 2009
Subject: rc.d/mountd: confusing message (and behavior?)
Message-ID: <4968AE90.5010004@icyb.net.ua>


$ /etc/rc.d/mountd onestart
/etc/rc.d/mountd: WARNING: /etc/exports is not readable.
Exit 1

Actually /etc/exports did not exist at all.
And this was not a "WARNING", this was a fatal error, mountd did not start.

Alsp, should it actually fail like this?  I have ZFS and I plan to do
all NFS exports from ZFS, so /etc/exports would never be used.
-- 
Andriy Gapon
From rnoland at FreeBSD.org  Sat Jan 10 15:01:29 2009
From: rnoland at FreeBSD.org (Robert Noland)
Date: Sat Jan 10 15:01:42 2009
Subject: [HEADS UP] drm merged to -STABLE
Message-ID: <1231599679.1837.13.camel@wombat.2hip.net>

I just merged drm (Direct Rendering) from HEAD.

        - Support for latest Intel chips
        - Support and fixes for many AMD/ATI chips r500 and below
        - Support AMD/ATI IGP based chips (rs690/rs485)
        - Lots of code cleanups
        - Lots of other fixes and changes since the existing drm
          is 2+ years old

If you are experiencing a "garbled" screen with certain pci/pci-e based
radeons, I have another patch in HEAD that isn't included yet.

thanks,

robert.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090110/c70cf0c9/attachment.pgp
From yanefbsd at gmail.com  Sat Jan 10 15:11:38 2009
From: yanefbsd at gmail.com (Garrett Cooper)
Date: Sat Jan 10 15:11:45 2009
Subject: rc.d/mountd: confusing message (and behavior?)
In-Reply-To: <4968AE90.5010004@icyb.net.ua>
References: <4968AE90.5010004@icyb.net.ua>
Message-ID: <7d6fde3d0901100711p70e9a66ahadc3c2570fc6f94b@mail.gmail.com>

On Sat, Jan 10, 2009 at 6:20 AM, Andriy Gapon <avg@icyb.net.ua> wrote:
>
> $ /etc/rc.d/mountd onestart
> /etc/rc.d/mountd: WARNING: /etc/exports is not readable.
> Exit 1
>
> Actually /etc/exports did not exist at all.
> And this was not a "WARNING", this was a fatal error, mountd did not start.
>
> Alsp, should it actually fail like this?  I have ZFS and I plan to do
> all NFS exports from ZFS, so /etc/exports would never be used.

Uh, mountd is used for nfsd, so I'm not sure why you're trying to do
this... The reference to /etc/exports is being picked up from
/etc/rc.d/mountd on this line:

required_files="/etc/exports"

and it's picking up the actual `does it exist?' test from:

[gcooper@orangebox /usr/home/gcooper]$ grep -A 3 required_files /etc/rc.subr
#	required_files	n	If set, check for the readability of the given
#				files before running a (re)start command.
#
#	required_modules n	If set, ensure the given kernel modules are
--
		rcvar required_dirs required_files required_vars
	eval unset ${_arg}_cmd ${_arg}_precmd ${_arg}_postcmd

	case "$_file" in
--
		for _f in $required_files; do
			if [ ! -r "${_f}" ]; then
				warn "${_f} is not readable."
				if [ -z "$rc_force" ]; then

Cheers,
-Garrett
From avg at icyb.net.ua  Sat Jan 10 15:14:41 2009
From: avg at icyb.net.ua (Andriy Gapon)
Date: Sat Jan 10 15:14:50 2009
Subject: rc.d/mountd: confusing message (and behavior?)
In-Reply-To: <7d6fde3d0901100711p70e9a66ahadc3c2570fc6f94b@mail.gmail.com>
References: <4968AE90.5010004@icyb.net.ua>
	<7d6fde3d0901100711p70e9a66ahadc3c2570fc6f94b@mail.gmail.com>
Message-ID: <4968BB5D.8070909@icyb.net.ua>

on 10/01/2009 17:11 Garrett Cooper said the following:
> On Sat, Jan 10, 2009 at 6:20 AM, Andriy Gapon <avg@icyb.net.ua> wrote:
>> $ /etc/rc.d/mountd onestart
>> /etc/rc.d/mountd: WARNING: /etc/exports is not readable.
>> Exit 1
>>
>> Actually /etc/exports did not exist at all.
>> And this was not a "WARNING", this was a fatal error, mountd did not start.
>>
>> Alsp, should it actually fail like this?  I have ZFS and I plan to do
>> all NFS exports from ZFS, so /etc/exports would never be used.
> 
> Uh, mountd is used for nfsd, so I'm not sure why you're trying to do
> this... 

I thought that mountd and nfsd (and rpcbind) are still required even if
exported filesystems are ZFS. Am I wrong on this?

> The reference to /etc/exports is being picked up from
> /etc/rc.d/mountd on this line:
> 
> required_files="/etc/exports"
> 
> and it's picking up the actual `does it exist?' test from:
> 
> [gcooper@orangebox /usr/home/gcooper]$ grep -A 3 required_files /etc/rc.subr
> #	required_files	n	If set, check for the readability of the given
> #				files before running a (re)start command.
> #
> #	required_modules n	If set, ensure the given kernel modules are
> --
> 		rcvar required_dirs required_files required_vars
> 	eval unset ${_arg}_cmd ${_arg}_precmd ${_arg}_postcmd
> 
> 	case "$_file" in
> --
> 		for _f in $required_files; do
> 			if [ ! -r "${_f}" ]; then
> 				warn "${_f} is not readable."
> 				if [ -z "$rc_force" ]; then
> 
> Cheers,
> -Garrett


-- 
Andriy Gapon
From yanefbsd at gmail.com  Sat Jan 10 15:16:56 2009
From: yanefbsd at gmail.com (Garrett Cooper)
Date: Sat Jan 10 15:17:03 2009
Subject: rc.d/mountd: confusing message (and behavior?)
In-Reply-To: <4968BB5D.8070909@icyb.net.ua>
References: <4968AE90.5010004@icyb.net.ua>
	<7d6fde3d0901100711p70e9a66ahadc3c2570fc6f94b@mail.gmail.com>
	<4968BB5D.8070909@icyb.net.ua>
Message-ID: <7d6fde3d0901100716i552420ddja6a59a4938e70fc9@mail.gmail.com>

On Sat, Jan 10, 2009 at 7:14 AM, Andriy Gapon <avg@icyb.net.ua> wrote:
> on 10/01/2009 17:11 Garrett Cooper said the following:
>> On Sat, Jan 10, 2009 at 6:20 AM, Andriy Gapon <avg@icyb.net.ua> wrote:
>>> $ /etc/rc.d/mountd onestart
>>> /etc/rc.d/mountd: WARNING: /etc/exports is not readable.
>>> Exit 1
>>>
>>> Actually /etc/exports did not exist at all.
>>> And this was not a "WARNING", this was a fatal error, mountd did not start.
>>>
>>> Alsp, should it actually fail like this?  I have ZFS and I plan to do
>>> all NFS exports from ZFS, so /etc/exports would never be used.
>>
>> Uh, mountd is used for nfsd, so I'm not sure why you're trying to do
>> this...
>
> I thought that mountd and nfsd (and rpcbind) are still required even if
> exported filesystems are ZFS. Am I wrong on this?
>
>> The reference to /etc/exports is being picked up from
>> /etc/rc.d/mountd on this line:
>>
>> required_files="/etc/exports"
>>
>> and it's picking up the actual `does it exist?' test from:
>>
>> [gcooper@orangebox /usr/home/gcooper]$ grep -A 3 required_files /etc/rc.subr
>> #     required_files  n       If set, check for the readability of the given
>> #                             files before running a (re)start command.
>> #
>> #     required_modules n      If set, ensure the given kernel modules are
>> --
>>               rcvar required_dirs required_files required_vars
>>       eval unset ${_arg}_cmd ${_arg}_precmd ${_arg}_postcmd
>>
>>       case "$_file" in
>> --
>>               for _f in $required_files; do
>>                       if [ ! -r "${_f}" ]; then
>>                               warn "${_f} is not readable."
>>                               if [ -z "$rc_force" ]; then
>>
>> Cheers,
>> -Garrett

Ok, dumb question -- does ZFS offer the same functionality as NFS? I
thought not...
-Garrett
From petefrench at ticketswitch.com  Sat Jan 10 15:24:43 2009
From: petefrench at ticketswitch.com (Pete French)
Date: Sat Jan 10 15:24:51 2009
Subject: rc.d/mountd: confusing message (and behavior?)
In-Reply-To: <4968AE90.5010004@icyb.net.ua>
Message-ID: <E1LLfhO-000LfO-UH@dilbert.ticketswitch.com>

> Alsp, should it actually fail like this?  I have ZFS and I plan to do
> all NFS exports from ZFS, so /etc/exports would never be used.

ZFS writes its own exports file to '/etc/zfs/exports' - as far as I can
tell this is pretty much all that happens when you mark a filesystem
as NFS shared under ZFS. Then mountd is started from rc like this:

	/usr/sbin/mountd -r -n /etc/exports /etc/zfs/exports

(thats taken from 'ps' on one of my running systems)

So you still need an empty /etc/exports to be there. ZFS will take
care of managing it's own exports file, but thats all it seems to
do - there is no magic ZFS seperate implementation of NFS as far as
I know.

-pete.
From yanefbsd at gmail.com  Sat Jan 10 15:25:25 2009
From: yanefbsd at gmail.com (Garrett Cooper)
Date: Sat Jan 10 15:25:37 2009
Subject: rc.d/mountd: confusing message (and behavior?)
In-Reply-To: <7d6fde3d0901100724la51365cp83ed94d917654605@mail.gmail.com>
References: <4968AE90.5010004@icyb.net.ua>
	<7d6fde3d0901100711p70e9a66ahadc3c2570fc6f94b@mail.gmail.com>
	<4968BB5D.8070909@icyb.net.ua>
	<7d6fde3d0901100716i552420ddja6a59a4938e70fc9@mail.gmail.com>
	<7d6fde3d0901100718s31ae9f38i5db870b7059bdfbe@mail.gmail.com>
	<4968BCC4.7090708@icyb.net.ua>
	<7d6fde3d0901100724la51365cp83ed94d917654605@mail.gmail.com>
Message-ID: <7d6fde3d0901100725q74c46bb1vf93379e075879bfd@mail.gmail.com>

On Sat, Jan 10, 2009 at 7:24 AM, Garrett Cooper <yanefbsd@gmail.com> wrote:
> On Sat, Jan 10, 2009 at 7:20 AM, Andriy Gapon <avg@icyb.net.ua> wrote:
>> on 10/01/2009 17:18 Garrett Cooper said the following:
>>>
>>>     s/same functionality/same basic functionality/.
>>>     Mind you, NFS is a networking filesystem. ZFS is a filestore
>>> filesystem, more rooted to the local machine I thought, like UFS.
>>
>> I am well aware of this. The difference between UFS and ZFS is that for
>> the former you have to maintain /etc/exports by hand and for the latter
>> /etc/zfs/exports is automatically managed via zfs tools.
>>
>> Andriy Gapon
>
> Maybe a zmountd or equivalent script should be written for zfs and the
> common code should be factored out for both cases?
> -Garrett

Sorry -- wrong list (current -> stable) ><.
-Garrett
From petefrench at ticketswitch.com  Sat Jan 10 15:49:47 2009
From: petefrench at ticketswitch.com (Pete French)
Date: Sat Jan 10 15:49:54 2009
Subject: Big problems with 7.1 locking up :-(
In-Reply-To: <p06240802c58db5953598@[128.113.24.47]>
Message-ID: <E1LLg5j-000Lmm-QO@dilbert.ticketswitch.com>

> FWIW, the other guy I know who is having this problem had already
> switched to using ULE under 7.0-release, and did not have any
> problems with it.  So *his* problem was probably not related to
> SCHED_ULE, unless something has recently changed there.

Well, one of my machines just locked up again, even with SCHED_4BSD
on it, so I am now thinking it is unrelated.

The machine has completely locked - no response to pings, no
response to keypresses, nor to the power button. There is nothing
printed on the console - it is just sitting there with a login prompt :-(

This is really not good - these are extremely common servers after all, and
I am just running bog standard 7.1 with apache and mysql. This is happening
across several different servers, all of which are slight variants on
the DL360, so I dont think it is something perculiar to me.

-pete.
From rnoland at 2hip.net  Sat Jan 10 08:49:17 2009
From: rnoland at 2hip.net (Robert Noland)
Date: Sat Jan 10 08:49:25 2009
Subject: [HEADS UP] drm merged to -STABLE
In-Reply-To: <1231599679.1837.13.camel@wombat.2hip.net>
References: <1231599679.1837.13.camel@wombat.2hip.net>
Message-ID: <1231606142.1837.34.camel@wombat.2hip.net>

On Sat, 2009-01-10 at 10:01 -0500, Robert Noland wrote:
> I just merged drm (Direct Rendering) from HEAD.
> 
>         - Support for latest Intel chips
>         - Support and fixes for many AMD/ATI chips r500 and below
>         - Support AMD/ATI IGP based chips (rs690/rs485)
>         - Lots of code cleanups
>         - Lots of other fixes and changes since the existing drm
>           is 2+ years old
> 
> If you are experiencing a "garbled" screen with certain pci/pci-e based
> radeons, I have another patch in HEAD that isn't included yet.

I decided to go ahead and fully sync to HEAD, so this should be resolved
as well.  This added:

        - Use bus_dma to allocate scatter/gather pages for pci GART.
          This fixes "garbled" screen issues on pci based radeons.
        - Prevent drm from attaching to secondary devices even if they
          have the the same pci id.

robert.

> thanks,
> 
> robert.
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090110/ede27286/attachment.pgp
From rsmith at xs4all.nl  Sat Jan 10 09:55:07 2009
From: rsmith at xs4all.nl (Roland Smith)
Date: Sat Jan 10 09:55:15 2009
Subject: [HEADS UP] drm merged to -STABLE
In-Reply-To: <1231606142.1837.34.camel@wombat.2hip.net>
References: <1231599679.1837.13.camel@wombat.2hip.net>
	<1231606142.1837.34.camel@wombat.2hip.net>
Message-ID: <20090110175444.GA6484@slackbox.xs4all.nl>

On Sat, Jan 10, 2009 at 11:49:01AM -0500, Robert Noland wrote:
> On Sat, 2009-01-10 at 10:01 -0500, Robert Noland wrote:
> > I just merged drm (Direct Rendering) from HEAD.
> > 
> >         - Support for latest Intel chips
> >         - Support and fixes for many AMD/ATI chips r500 and below
> >         - Support AMD/ATI IGP based chips (rs690/rs485)
> >         - Lots of code cleanups
> >         - Lots of other fixes and changes since the existing drm
> >           is 2+ years old
> >
> > If you are experiencing a "garbled" screen with certain pci/pci-e based
> > radeons, I have another patch in HEAD that isn't included yet.
> 
> I decided to go ahead and fully sync to HEAD, so this should be resolved
> as well.  This added:
> 
>         - Use bus_dma to allocate scatter/gather pages for pci GART.
>           This fixes "garbled" screen issues on pci based radeons.
>         - Prevent drm from attaching to secondary devices even if they
>           have the the same pci id.

Do cards on the PCIE bus still need the agp device? It seems my r535
(radeon X1650Pro) on the PCIE bus can allocate a GART without it. I have
the agp module loaded, but there is no /dev/agpgart device. But if I try
to unload the module, it says 'can't unload file: Device busy'.

Roland
-- 
R.F.Smith                                   http://www.xs4all.nl/~rsmith/
[plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated]
pgp: 1A2B 477F 9970 BA3C 2914  B7CE 1277 EFB0 C321 A725 (KeyID: C321A725)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090110/4139eca2/attachment.pgp
From rnoland at FreeBSD.org  Sat Jan 10 10:02:39 2009
From: rnoland at FreeBSD.org (Robert Noland)
Date: Sat Jan 10 10:02:51 2009
Subject: [HEADS UP] drm merged to -STABLE
In-Reply-To: <20090110175444.GA6484@slackbox.xs4all.nl>
References: <1231599679.1837.13.camel@wombat.2hip.net>
	<1231606142.1837.34.camel@wombat.2hip.net>
	<20090110175444.GA6484@slackbox.xs4all.nl>
Message-ID: <1231610548.1837.47.camel@wombat.2hip.net>

On Sat, 2009-01-10 at 18:54 +0100, Roland Smith wrote:
> On Sat, Jan 10, 2009 at 11:49:01AM -0500, Robert Noland wrote:
> > On Sat, 2009-01-10 at 10:01 -0500, Robert Noland wrote:
> > > I just merged drm (Direct Rendering) from HEAD.
> > > 
> > >         - Support for latest Intel chips
> > >         - Support and fixes for many AMD/ATI chips r500 and below
> > >         - Support AMD/ATI IGP based chips (rs690/rs485)
> > >         - Lots of code cleanups
> > >         - Lots of other fixes and changes since the existing drm
> > >           is 2+ years old
> > >
> > > If you are experiencing a "garbled" screen with certain pci/pci-e based
> > > radeons, I have another patch in HEAD that isn't included yet.
> > 
> > I decided to go ahead and fully sync to HEAD, so this should be resolved
> > as well.  This added:
> > 
> >         - Use bus_dma to allocate scatter/gather pages for pci GART.
> >           This fixes "garbled" screen issues on pci based radeons.
> >         - Prevent drm from attaching to secondary devices even if they
> >           have the the same pci id.
> 
> Do cards on the PCIE bus still need the agp device? It seems my r535
> (radeon X1650Pro) on the PCIE bus can allocate a GART without it. I have
> the agp module loaded, but there is no /dev/agpgart device. But if I try
> to unload the module, it says 'can't unload file: Device busy'.

Technically no, pci/pci-e based cards don't need AGP.  All of the Intel
chips do, as they emulate AGP in all cases.  The pci/pci-e radeons do
not need AGP at all, but I don't know of a way to conditionally require
the AGP module as a dependency in drm.  The other issue would be that
even if I could, it would probably end up with undefined symbols in drm
without agp loaded, even if it isn't used.

robert.

> Roland
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090110/5725be0b/attachment.pgp
From vehemens at verizon.net  Sat Jan 10 15:53:46 2009
From: vehemens at verizon.net (vehemens)
Date: Sat Jan 10 15:53:58 2009
Subject: [HEADS UP] drm merged to -STABLE
In-Reply-To: <1231606142.1837.34.camel@wombat.2hip.net>
References: <1231599679.1837.13.camel@wombat.2hip.net>
	<1231606142.1837.34.camel@wombat.2hip.net>
Message-ID: <200901101553.21968.vehemens@verizon.net>

On Saturday 10 January 2009 08:49:01 am Robert Noland wrote:
> On Sat, 2009-01-10 at 10:01 -0500, Robert Noland wrote:
> > I just merged drm (Direct Rendering) from HEAD.
> >
> >         - Support for latest Intel chips
> >         - Support and fixes for many AMD/ATI chips r500 and below
> >         - Support AMD/ATI IGP based chips (rs690/rs485)
> >         - Lots of code cleanups
> >         - Lots of other fixes and changes since the existing drm
> >           is 2+ years old
> >
> > If you are experiencing a "garbled" screen with certain pci/pci-e based
> > radeons, I have another patch in HEAD that isn't included yet.
>
> I decided to go ahead and fully sync to HEAD, so this should be resolved
> as well.  This added:
>
>         - Use bus_dma to allocate scatter/gather pages for pci GART.
>           This fixes "garbled" screen issues on pci based radeons.
>         - Prevent drm from attaching to secondary devices even if they
>           have the the same pci id.

What's your plan on incorporating r6xx/r7xx drm :?
From me at janh.de  Sat Jan 10 16:20:53 2009
From: me at janh.de (Jan Henrik Sylvester)
Date: Sat Jan 10 16:21:01 2009
Subject: 7.1 manpages: "first appeared in FreeBSD 8.0"
Message-ID: <49693B62.2020104@janh.de>

I found a 7.1-RELEASE manpage stating "first appeared in FreeBSD 8.0". A 
little bit of grepping revealed a few more:

setfib(1) setfib(2) ffs(3) ffsl(3) ffsll(3) fls(3) flsl(3) flsll(3) 
memchr(3) memrchr(3) malo(4) crashinfo(8) savecore(8)

Some others are correctly stating "7.1" for example textdump(4).

Cheers,
Jan Henrik
From ehrmann at gmail.com  Sat Jan 10 16:49:20 2009
From: ehrmann at gmail.com (David Ehrmann)
Date: Sat Jan 10 16:49:27 2009
Subject: "vr0: rx packet lost"
Message-ID: <496941FF.5090906@gmail.com>

I'm using 7.0-RELEASE.

When there's heavy network traffic through the vr0 interface, I see lots 
of "vr0: rx packet lost" messages, and occasional "vr0: watchdog 
timeout" messages.  I googled and found some information, but it was on 
an earlier version of FreeBSD, and there weren't any solutions.  I 
didn't load vr as a module, and it's not listed by kldstat, so I assume 
it was build into the kernel.

Ideas?  Is there any additional information I should provide?
From rnoland at FreeBSD.org  Sat Jan 10 17:43:37 2009
From: rnoland at FreeBSD.org (Robert Noland)
Date: Sat Jan 10 17:44:15 2009
Subject: [HEADS UP] drm merged to -STABLE
In-Reply-To: <200901101553.21968.vehemens@verizon.net>
References: <1231599679.1837.13.camel@wombat.2hip.net>
	<1231606142.1837.34.camel@wombat.2hip.net>
	<200901101553.21968.vehemens@verizon.net>
Message-ID: <1231638209.1764.13.camel@wombat.2hip.net>

On Sat, 2009-01-10 at 15:53 -0800, vehemens wrote:
> On Saturday 10 January 2009 08:49:01 am Robert Noland wrote:
> > On Sat, 2009-01-10 at 10:01 -0500, Robert Noland wrote:
> > > I just merged drm (Direct Rendering) from HEAD.
> > >
> > >         - Support for latest Intel chips
> > >         - Support and fixes for many AMD/ATI chips r500 and below
> > >         - Support AMD/ATI IGP based chips (rs690/rs485)
> > >         - Lots of code cleanups
> > >         - Lots of other fixes and changes since the existing drm
> > >           is 2+ years old
> > >
> > > If you are experiencing a "garbled" screen with certain pci/pci-e based
> > > radeons, I have another patch in HEAD that isn't included yet.
> >
> > I decided to go ahead and fully sync to HEAD, so this should be resolved
> > as well.  This added:
> >
> >         - Use bus_dma to allocate scatter/gather pages for pci GART.
> >           This fixes "garbled" screen issues on pci based radeons.
> >         - Prevent drm from attaching to secondary devices even if they
> >           have the the same pci id.
> 
> What's your plan on incorporating r6xx/r7xx drm :?

The code isn't user ready yet.  What AMD has released, I have building.
AMD is being quite reasonable about their code, so it won't be a big
deal to get that code imported quickly once it is ready.  My expectation
is that we will ship code, at least in -CURRENT, before any linux
distro. ;)

robert.

> _______________________________________________
> freebsd-x11@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-x11
> To unsubscribe, send any mail to "freebsd-x11-unsubscribe@freebsd.org"
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090111/f2513cdf/attachment-0001.pgp
From mike at sentex.net  Sat Jan 10 17:51:16 2009
From: mike at sentex.net (Mike Tancsa)
Date: Sat Jan 10 17:51:23 2009
Subject: "vr0: rx packet lost"
In-Reply-To: <496941FF.5090906@gmail.com>
References: <496941FF.5090906@gmail.com>
Message-ID: <200901110151.n0B1pC5o043840@lava.sentex.ca>

At 07:49 PM 1/10/2009, David Ehrmann wrote:
>I'm using 7.0-RELEASE.
>Ideas?  Is there any additional information I should provide?

7.1R has a *far* better vr driver that has a lot of bug fixes in it.

http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/vr/if_vr.c
has details of what was fixed.
         ---Mike 

From heliocentric at gmail.com  Sat Jan 10 18:07:49 2009
From: heliocentric at gmail.com (heliocentric@gmail.com)
Date: Sat Jan 10 18:07:56 2009
Subject: Big problems with 7.1 locking up :-(
In-Reply-To: <E1LLg5j-000Lmm-QO@dilbert.ticketswitch.com>
References: <p06240802c58db5953598@128.113.24.47>
	<E1LLg5j-000Lmm-QO@dilbert.ticketswitch.com>
Message-ID: <bdf82f800901101807i67078622i48e63deb448b6ec4@mail.gmail.com>

I noticed a similar problem testing 7.1-RC1, It seemed to be a deep
deadlock, as it was triggered by lighttpd doing kern_sendfile, and
never returning. The side effects (being unable to create processes,
etc) is similar.

My kernconf is below, try building the kernel, and send an email
containing the backtrace from any process that has blocked (in my
case, lighttpd attempting to sendfile a large amount of data to php
fastcgi triggered it, but that's a guess on my part). Note that this
includes witness, and invariants, so performance will be hit. Also,
enable watchdogd, and add -e 'ls -al /etc' to it's flags. It should
drop you to a debugger with a backtrace within a few seconds of the
lock being triggered, and it should output a backtrace and any
invariant/witness lock warnings. Obviously if you don't have a serial
or local console, don't do this.

include         GENERIC
ident           DEBUG
options         KDB
options         DDB
options         SW_WATCHDOG
options DEBUG_VFS_LOCKS
options INVARIANTS
options WITNESS

On 1/10/09, Pete French <petefrench@ticketswitch.com> wrote:
>> FWIW, the other guy I know who is having this problem had already
>> switched to using ULE under 7.0-release, and did not have any
>> problems with it.  So *his* problem was probably not related to
>> SCHED_ULE, unless something has recently changed there.
>
> Well, one of my machines just locked up again, even with SCHED_4BSD
> on it, so I am now thinking it is unrelated.
>
> The machine has completely locked - no response to pings, no
> response to keypresses, nor to the power button. There is nothing
> printed on the console - it is just sitting there with a login prompt :-(
>
> This is really not good - these are extremely common servers after all, and
> I am just running bog standard 7.1 with apache and mysql. This is happening
> across several different servers, all of which are slight variants on
> the DL360, so I dont think it is something perculiar to me.
>
> -pete.
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
>
From pyunyh at gmail.com  Sat Jan 10 18:42:03 2009
From: pyunyh at gmail.com (Pyun YongHyeon)
Date: Sat Jan 10 18:42:10 2009
Subject: "vr0: rx packet lost"
In-Reply-To: <200901110151.n0B1pC5o043840@lava.sentex.ca>
References: <496941FF.5090906@gmail.com>
	<200901110151.n0B1pC5o043840@lava.sentex.ca>
Message-ID: <20090111024155.GA42714@cdnetworks.co.kr>

On Sat, Jan 10, 2009 at 08:51:06PM -0500, Mike Tancsa wrote:
 > At 07:49 PM 1/10/2009, David Ehrmann wrote:
 > >I'm using 7.0-RELEASE.
 > >Ideas?  Is there any additional information I should provide?
 > 
 > 7.1R has a *far* better vr driver that has a lot of bug fixes in it.
 > 
 > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/vr/if_vr.c
 > has details of what was fixed.

As Mike said several known bugs were fixed. If you still see
problems on 7.1-RELEASE, let me know.

-- 
Regards,
Pyun YongHyeon
From ehrmann at gmail.com  Sat Jan 10 19:15:28 2009
From: ehrmann at gmail.com (David Ehrmann)
Date: Sat Jan 10 19:15:35 2009
Subject: "vr0: rx packet lost"
In-Reply-To: <200901110151.n0B1pC5o043840@lava.sentex.ca>
References: <496941FF.5090906@gmail.com>
	<200901110151.n0B1pC5o043840@lava.sentex.ca>
Message-ID: <4969644A.1010306@gmail.com>

Wow.  That really is a lot, but I might just wait for the final release, 
though with this command, it might not be such a big deal:

freebsd-update upgrade -r 7.1-RC1



Mike Tancsa wrote:
> At 07:49 PM 1/10/2009, David Ehrmann wrote:
>> I'm using 7.0-RELEASE.
>> Ideas?  Is there any additional information I should provide?
>
> 7.1R has a *far* better vr driver that has a lot of bug fixes in it.
>
> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/vr/if_vr.c
> has details of what was fixed.
>         ---Mike

From peterjeremy at optushome.com.au  Sat Jan 10 23:44:26 2009
From: peterjeremy at optushome.com.au (Peter Jeremy)
Date: Sat Jan 10 23:44:33 2009
Subject: "vr0: rx packet lost"
In-Reply-To: <4969644A.1010306@gmail.com>
References: <496941FF.5090906@gmail.com>
	<200901110151.n0B1pC5o043840@lava.sentex.ca>
	<4969644A.1010306@gmail.com>
Message-ID: <20090111074422.GA7054@server.vk2pj.dyndns.org>

On 2009-Jan-10 19:15:22 -0800, David Ehrmann <ehrmann@gmail.com> wrote:
>Wow.  That really is a lot, but I might just wait for the final release, 
>though with this command, it might not be such a big deal:
>
>freebsd-update upgrade -r 7.1-RC1

FreeBSD 7.1-RELEASE has been available for nearly a week.

-- 
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-stable/attachments/20090111/8a10fe56/attachment.pgp
From petefrench at ticketswitch.com  Sun Jan 11 04:45:33 2009
From: petefrench at ticketswitch.com (Pete French)
Date: Sun Jan 11 04:45:40 2009
Subject: Big problems with 7.1 locking up :-(
In-Reply-To: <bdf82f800901101807i67078622i48e63deb448b6ec4@mail.gmail.com>
Message-ID: <E1LLzgr-00008v-Nu@dilbert.ticketswitch.com>

> I noticed a similar problem testing 7.1-RC1, It seemed to be a deep
> deadlock, as it was triggered by lighttpd doing kern_sendfile, and
> never returning. The side effects (being unable to create processes,
> etc) is similar.

Interesting - did you get any responses from anyone else regarding
this ?  My last box which locked up was essentialy idle, so I am very
surprised by all of this - also none of the heavilt loaded machines
(i.e. the actual webservers) have locked up.

I am also surprised that this isn't more widely reported, as
the hardware is very common. The only oddity with ym compile
is that I set the CPUTYPE to 'core2' - that shouldnt have an effect, but
I will remove it anyway, just so I am actually building a completely
vanilla amd64. That way I should have what everyone else has, and since
I don't see anyone else saying they have isues then maybe mine will
go away too (fingers crossed)

> My kernconf is below, try building the kernel, and send an email
> containing the backtrace from any process that has blocked (in my

OK, will do. I can try this on the one non-essential box which
locked up yesterday. I don't know how long it will before it
locks up again, but will see if I can do some things to provoke it.

-pete.
From hawei at free.fr  Sun Jan 11 04:58:58 2009
From: hawei at free.fr (Harald)
Date: Sun Jan 11 04:59:06 2009
Subject: Medical database Vidal
In-Reply-To: <20090109191007.GA6625@osiris.mauzo.dyndns.org>
References: <20090109184126.GA2501@pollux2.free.local.net>
	<20090109191007.GA6625@osiris.mauzo.dyndns.org>
Message-ID: <20090111130222.GA13690@pollux2.free.local.net>

On Fri, Jan 09, 2009 at 07:10:07PM +0000, Ben Morrow wrote:
 
> I would guess that your CD has both Rock Ridge and Joliet extensions,
> and that the creator has hidden the Win32-specific files from the Unix
> directory tree because they thought they wouldn't be useful. If for some
> reason you need to see the CD as a Win32 machine would, you can use the
> -r option to mount_cd9660.

Thank you very much indeed for your detailed explanation.

Before searching for help I have tried out all options of mount_cd9660,
one after the other and all together or so without understanding their
meaning. Therefore I obviously missed the working one.

`mount_cd9660 -r /dev/acd0 /cdrom' works like a charm.

`wine /cdrom/setup.exe' does the job as well, unfortunately with a
certain number of `err:' and `fixme:' lines.
`cd path/to/VidalCD ; wine VidalCD.exe' starts the application with
the same or similar error lines (which is not surprising).
The programme does run, but is not really operational: It is too slow,
and exiting without problems requires to type `Ctrl+Alt+Backspace' !

No time yet to see whether I am capable to fix something without
further help.

Harald
-- 
FreeBSD 7.0-RELEASE FreeBSD 7.0-RELEASE #0: Sun Feb 24 19:59:52 UTC 2008
From msnkipa at mail.ru  Sun Jan 11 07:55:15 2009
From: msnkipa at mail.ru (=?koi8-r?Q?=ED=C9=C8=C1=C9=CC_=EB=C9=D0=C1?=)
Date: Sun Jan 11 07:55:22 2009
Subject: ZFSv13 in RELENG7
Message-ID: <E1LM0UG-0006sE-00.msnkipa-mail-ru@f149.mail.ru>

Is any plans to backport ZFSv13 from CURRENT to RELENG7 branxh or not?
From petefrench at ticketswitch.com  Sun Jan 11 08:27:59 2009
From: petefrench at ticketswitch.com (Pete French)
Date: Sun Jan 11 08:28:06 2009
Subject: Big problems with 7.1 locking up :-(
In-Reply-To: <bdf82f800901101807i67078622i48e63deb448b6ec4@mail.gmail.com>
Message-ID: <E1LM3AF-0000yL-Nh@dilbert.ticketswitch.com>

> My kernconf is below, try building the kernel, and send an email
> containing the backtrace from any process that has blocked (in my

Well, I havent managed to get a backtrace, but immediately upon
booting the system halts with the following:

	http://www.twisted.org.uk/~pete/71_lor1.jpg

Interestingly, if I try and boot into safe mode then it will not
even get that far:

	http://www.twisted.org.uk/~pete/71_safe1.jpg

Am going to try and backtrace that now to see what I can get. Unfortunately
I can only provide screen captures rather than actual text output from
this due to having to go via a Mac running RDP thought an ssh tunnel
to a Windows box and then using IE to go to the iLO :-) Convoluted,
but it works...

-pete.
From eugene at donpac.ru  Sun Jan 11 08:37:26 2009
From: eugene at donpac.ru (Eugene Gladchenko)
Date: Sun Jan 11 08:37:34 2009
Subject: FreeBSD 7.1 Breaks re and rl Network Interface Drivers
In-Reply-To: <8dfae1c10901071550s69d99802p31ca7c775f3d6823@mail.gmail.com>
References: <8dfae1c10901070639x67945324jeeecfcac647d7976@mail.gmail.com>
	<8dfae1c10901071550s69d99802p31ca7c775f3d6823@mail.gmail.com>
Message-ID: <88527079.20090111192206@donpac.ru>

Walter,

Thursday, January 8, 2009, 2:50:40 AM, you wrote:

WV> Booting kernel.old, which is 7.0-RELEASE-p7 completely alleviates all
WV> problems.  I believe this roundly confirms that this is a bug in the
WV> 7.1-RELEASE re kernel drivers.

Does kern/130011 look similar? http://www.freebsd.org/cgi/query-pr.cgi?pr=130011

The re driver was really broken in 7.1-RC2 and the fix didn't get to 7.1-RELEASE.

-- 
Eugene Gladchenko
EVG15-RIPE


From petefrench at ticketswitch.com  Sun Jan 11 09:16:11 2009
From: petefrench at ticketswitch.com (Pete French)
Date: Sun Jan 11 09:16:17 2009
Subject: Lock order reversals using bce in 7.1
In-Reply-To: <E1LM3AF-0000yL-Nh@dilbert.ticketswitch.com>
Message-ID: <E1LM3uv-0001CD-7X@dilbert.ticketswitch.com>

Here is a better set of images. This machine was compiled
with the following config file:

include         GENERIC
ident           DEBUG

options         KDB
options         DDB
options         SW_WATCHDOG
options         DEBUG_VFS_LOCKS
options         MUTEX_DEBUG
options         WITNESS
options         WITNESS_KDB
options         LOCK_PROFILING
options         INVARIANTS
options         INVARIANT_SUPPORT
options         DIAGNOSTIC

On booting it almost immediately does this:

        http://www.twisted.org.uk/~pete/71_lor.png

The output of trace, show pcpu, show locks, show allpcpu and show alllocks
are shown in the following images:

        http://www.twisted.org.uk/~pete/71_locks_trace.png
        http://www.twisted.org.uk/~pete/71_pcpu_alllocks.png
        http://www.twisted.org.uk/~pete/71_allpcpu1.png
        http://www.twisted.org.uk/~pete/71_allpcpu2.png

I am going to revent the machine back to a normal kernel now - is there
anything I might be able to do to stop this, or do I need to roll everything
back to 7.0 ?

cheers,

-pete.
From heliocentric at gmail.com  Sun Jan 11 11:01:43 2009
From: heliocentric at gmail.com (Dylan Cochran)
Date: Sun Jan 11 11:01:50 2009
Subject: Big problems with 7.1 locking up :-(
In-Reply-To: <E1LM3AF-0000yL-Nh@dilbert.ticketswitch.com>
References: <bdf82f800901101807i67078622i48e63deb448b6ec4@mail.gmail.com>
	<E1LM3AF-0000yL-Nh@dilbert.ticketswitch.com>
Message-ID: <bdf82f800901111101sda5733dsace158df556d832d@mail.gmail.com>

On Sun, Jan 11, 2009 at 11:27 AM, Pete French
<petefrench@ticketswitch.com> wrote:
>> My kernconf is below, try building the kernel, and send an email
>> containing the backtrace from any process that has blocked (in my
>
> Well, I havent managed to get a backtrace, but immediately upon
> booting the system halts with the following:
>
>        http://www.twisted.org.uk/~pete/71_lor1.jpg

Not Found
From petefrench at ticketswitch.com  Sun Jan 11 11:10:41 2009
From: petefrench at ticketswitch.com (Pete French)
Date: Sun Jan 11 11:10:48 2009
Subject: Big problems with 7.1 locking up :-(
In-Reply-To: <bdf82f800901111101sda5733dsace158df556d832d@mail.gmail.com>
Message-ID: <E1LM5hi-0001YF-Fs@dilbert.ticketswitch.com>

> Not Found

sorry, see the subsequent email, there are more links there to working PNG's

-pete.
From hrs at FreeBSD.org  Sun Jan 11 11:21:01 2009
From: hrs at FreeBSD.org (Hiroki Sato)
Date: Sun Jan 11 11:21:08 2009
Subject: IPv6 routing on 7.1R
Message-ID: <20090112.042014.205677175.hrs@allbsd.org>

Hi,

 I noticed an odd behavior regarding IPv6 after upgrading my 7.0R box
 to 7.1R.  The situation and symptom are the following:

 1. The box has two NICs.  One has an address 2001:0db8:1::1/64 (NIC
    A), and another has 2001:0db8:2::1/64 (NIC B).  These addresses
    are assigned manually ($ipv6_ifconfig in rc.conf).

 2. RA is periodically sent to the network 2001:0db8:1::1/64 (NIC A)
    by a router on the subnet.  The RA includes a source link-layer
    address option only.

 When setting net.inet6.ip6.accept_rtadv=1 in this configuration, I
 expected the box assigns an autoconf IPv6 address (prefix
 2001:0db8:1::/64 + EUI64) to NIC A and an default route based on
 source link-layer address in the RA packet.  Actually, these two were
 done as expected.  However, after addresses are assigned, routes for
 NIC B disappeared from the routing table.  More specifically, a
 cloning route "2001:0db8:2::1/64 -> link#2" was removed for some
 reason.

 Is this an expected behavior?  IIRC, 7.0R does not remove the route
 and I think it is strange.  It works fine if a box has a single NIC,
 though.

--
| Hiroki SATO
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090111/711f7adf/attachment.pgp
From yanefbsd at gmail.com  Sun Jan 11 11:22:53 2009
From: yanefbsd at gmail.com (Garrett Cooper)
Date: Sun Jan 11 11:23:00 2009
Subject: Big problems with 7.1 locking up :-(
In-Reply-To: <E1LLzgr-00008v-Nu@dilbert.ticketswitch.com>
References: <bdf82f800901101807i67078622i48e63deb448b6ec4@mail.gmail.com>
	<E1LLzgr-00008v-Nu@dilbert.ticketswitch.com>
Message-ID: <7d6fde3d0901111122v3813fe3ehf75de6a2a7e66203@mail.gmail.com>

On Sun, Jan 11, 2009 at 4:45 AM, Pete French
<petefrench@ticketswitch.com> wrote:
>> I noticed a similar problem testing 7.1-RC1, It seemed to be a deep
>> deadlock, as it was triggered by lighttpd doing kern_sendfile, and
>> never returning. The side effects (being unable to create processes,
>> etc) is similar.
>
> Interesting - did you get any responses from anyone else regarding
> this ?  My last box which locked up was essentialy idle, so I am very
> surprised by all of this - also none of the heavilt loaded machines
> (i.e. the actual webservers) have locked up.
>
> I am also surprised that this isn't more widely reported, as
> the hardware is very common. The only oddity with ym compile
> is that I set the CPUTYPE to 'core2' - that shouldnt have an effect, but
> I will remove it anyway, just so I am actually building a completely
> vanilla amd64. That way I should have what everyone else has, and since
> I don't see anyone else saying they have isues then maybe mine will
> go away too (fingers crossed)
>
>> My kernconf is below, try building the kernel, and send an email
>> containing the backtrace from any process that has blocked (in my
>
> OK, will do. I can try this on the one non-essential box which
> locked up yesterday. I don't know how long it will before it
> locks up again, but will see if I can do some things to provoke it.
>
> -pete.

    Intel suggests nocona for x86_64 platforms and prescott for x86
(i386) based platforms on the 4.2 line, because they best matched the
cache size and featureset of the Core2 processors.

    I don't think that core2 support was fully completed in 4.2 (in
fact I believe it was just started), and I don't think that our
binutils supports it properly.

Some thoughts,
-Garrett
From pyunyh at gmail.com  Sun Jan 11 17:11:56 2009
From: pyunyh at gmail.com (Pyun YongHyeon)
Date: Sun Jan 11 17:12:03 2009
Subject: FreeBSD 7.1 Breaks re and rl Network Interface Drivers
In-Reply-To: <88527079.20090111192206@donpac.ru>
References: <8dfae1c10901070639x67945324jeeecfcac647d7976@mail.gmail.com>
	<8dfae1c10901071550s69d99802p31ca7c775f3d6823@mail.gmail.com>
	<88527079.20090111192206@donpac.ru>
Message-ID: <20090112011146.GC46346@cdnetworks.co.kr>

On Sun, Jan 11, 2009 at 07:22:06PM +0300, Eugene Gladchenko wrote:
 > Walter,
 > 
 > Thursday, January 8, 2009, 2:50:40 AM, you wrote:
 > 
 > WV> Booting kernel.old, which is 7.0-RELEASE-p7 completely alleviates all
 > WV> problems.  I believe this roundly confirms that this is a bug in the
 > WV> 7.1-RELEASE re kernel drivers.
 > 
 > Does kern/130011 look similar? http://www.freebsd.org/cgi/query-pr.cgi?pr=130011

Do you have RTL8168C controller? If not, it's not related with
Walter's issue as 7.0-RELEASE didn't have a support for RTL8168C.

 > 
 > The re driver was really broken in 7.1-RC2 and the fix didn't get to 7.1-RELEASE.

If you have re(4) issues, please provide more details such as
dmesg output, way to reproduce the issue etc.

-- 
Regards,
Pyun YongHyeon
From uwe at laverenz.de  Sun Jan 11 20:32:36 2009
From: uwe at laverenz.de (Uwe Laverenz)
Date: Sun Jan 11 20:33:08 2009
Subject: [HEADS UP] drm merged to -STABLE
In-Reply-To: <1231606142.1837.34.camel@wombat.2hip.net>
References: <1231599679.1837.13.camel@wombat.2hip.net>
	<1231606142.1837.34.camel@wombat.2hip.net>
Message-ID: <20090112042945.GA7583@laverenz.de>

On Sat, Jan 10, 2009 at 11:49:01AM -0500, Robert Noland wrote:

> > If you are experiencing a "garbled" screen with certain pci/pci-e based
> > radeons, I have another patch in HEAD that isn't included yet.
> 
> I decided to go ahead and fully sync to HEAD, so this should be resolved
> as well.  This added:

Thank you! :)

bye,
Uwe

From antik at bsd.ee  Sun Jan 11 22:22:46 2009
From: antik at bsd.ee (Andrei Kolu)
Date: Sun Jan 11 22:22:53 2009
Subject: mergemaster broken -- take 2
In-Reply-To: <496819F0.9@vintners.net>
References: <200901081047.n08Alg2h000825@lurza.secnetix.de>
	<496819F0.9@vintners.net>
Message-ID: <496AE1AF.9060104@bsd.ee>

Mike Lempriere wrote:
> Thanks everyone for the advice -- I got it working this time just 
> fine.  Works much better when one follows the directions accurately 
> instead of by memory -- the bottom line is that this time I remembered 
> to jot down the commands before heading downtown to the machine rack 
> room where there's no browser access...  I started over and followed 
> UPDATING:
>  cd /usr/obj
>  rm -R *
>  cd /usr/src
>  rm -R *
>  cvsup -g -L 2 -h cvsup10.freebsd.org |& tee /root/cvsup-090108.out
>  make buildworld |& tee /root/make-buildworld-090108.out
>  make kernel KERNCONF=GENERIC |& tee /root/make-kernel-090108.out
>  users
>  ps ax | more
>  shutdown -r now
You can go into single user without rebooting just by issuing command:

# shutdown now

NOTE: Network access will be shut down also, so you should be on your 
console then.

>  4 (single user)
>  fsck -p
>  mount -u /
>  mount -a
>  cd /usr/src
>  mergemaster -p
>  make installworld |& tee /root/make-installworld-090108.out
>  make delete-old (forgot to do tee redirect)
>  mergemaster -i (did not do tee redirect)
>  shutdown -r now
>
> Oliver Fromme wrote:
>> Greg Byshenk wrote:
>>  > Andrei Kolu wrote:
>>  > > Mike Lempriere wrote:
>>  > > > Hi folks -- sorry to be a nag, but my main production system 
>> is barely  > > > limping along on an old kernel with mismatched 
>> libraries.  I have no  > > > idea what else to do -- please help!
>>  > > > ---
>>  > > > I'm upgrading 5-stable (was at 5.5) to 6-stable, in 
>> preparation for  > > > 6-stable to 7-stable.
>>  > > > No problems with cvsup, make buildworld, make installworld, 
>> make  > > > buildkernel, mergemaster -p.
>>  > > > make installkernel, boot to single user.  Then mergemaster -- 
>> blammo:
>>
>> As others have pointed out, the order is wrong, which caused
>> the problem Mike is seeing.
>>
>> The correct order is listed in /usr/src/UPDATING.
>>
>>  > The reasons for the other methods being wrong are (as I understand 
>> them):
>>  >  > - You should build your new world before building your new 
>> kernel, as
>>  >   it may be the case that some aspects of the new kernel build are
>>  >   dependent upon aspects of the new world build.  If you build your
>>  >   new kernel before building your new world, you will be building 
>>  >   your new kernel against the old world.
>>
>> In particular, building the kernel uses the new toolchain
>> (i.e. compiler, linker, make(1) binary and so on) that was
>> built in /usr/obj during buildworld.  That's why you have
>> to do buildworld first, then "make kernel".
>>
>>  > - You should install your new kernel before installing your new 
>> world,
>>  >   as it can be the case that some aspects of the new world will 
>> not be
>>  >   understood by your old kernel. A new kernel should always be
>>  >   compatible with an old userland/world, but an old kernel may not 
>>  >   always be compatible with a new userland/world.
>>
>> That's correct.  Note that your kernel config should include
>> the appropriate "options COMPAT_*" lines if you update across
>> a major version boundary, e.g. "options_COMPAT_FREEBSD6" when
>> you update from 6.x to 7.x.  The GENERIC kernel already has
>> those.
>>
>>  > > NOTE: I do not reboot my system until everything is updated. Why 
>> it is  > > necessary to boot new kernel and then upgrade world is 
>> beyound me..YMMW
>>  >  > - I suppose that it is not strictly necessary to reboot between 
>>  >   installing kernel and world, but I always do so.
>>
>> It _is_ necessary.  If you don't reboot, you're still running
>> the old kernel which might not be able to support new binaries
>> and libraries that installworld will install on your system.
>>
>> For example, there may be new syscalls that the new binaries
>> will try to use, but the old kernel doesn't know about them.
>> It doesn't happen often, so you can get away without rebooting
>> most of the time.  But it's risky, especially when updating
>> across major versions.  So the recommendation is to always
>> reboot after installing the new kernel and before performing
>> the "installworld".
>>
>> It's also important that "installworld" is the last step
>> (except for mergemaster), because this is the point of no
>> return.  As long as you still have the old userland (world),
>> you can still boot the old kernel and everything is fine.
>> You can start all over froms cratch, if necessary.
>> But as soon as you have started "installworld", your system
>> will not be able to work with the old kernel anymore.
>>
>> And remember:  Always make a backup before you start to
>> update.  And verify that the backup works.  Better safe
>> than sorry.
>>
>> Best regards
>>    Oliver
>>
>>   
>

From pyunyh at gmail.com  Sun Jan 11 22:41:33 2009
From: pyunyh at gmail.com (Pyun YongHyeon)
Date: Sun Jan 11 22:41:40 2009
Subject: FreeBSD 7.1 Breaks re and rl Network Interface Drivers
In-Reply-To: <64114.83.221.215.168.1231741940.squirrel@83.221.215.168>
References: <8dfae1c10901070639x67945324jeeecfcac647d7976@mail.gmail.com>
	<8dfae1c10901071550s69d99802p31ca7c775f3d6823@mail.gmail.com>
	<88527079.20090111192206@donpac.ru>
	<20090112011146.GC46346@cdnetworks.co.kr>
	<64114.83.221.215.168.1231741940.squirrel@83.221.215.168>
Message-ID: <20090112064121.GF46346@cdnetworks.co.kr>

On Mon, Jan 12, 2009 at 09:32:20AM +0300, eugene@donpac.ru wrote:
 > EG>> Does kern/130011 look similar?
 > EG>> http://www.freebsd.org/cgi/query-pr.cgi?pr=130011
 > 
 > > Do you have RTL8168C controller? If not, it's not related with
 > > Walter's issue as 7.0-RELEASE didn't have a support for RTL8168C.
 > 
 > Look into kern/130011. As far as I can see I do have RTL8168C.
 > 
 > EG>> The re driver was really broken in 7.1-RC2 and the fix didn't get
 > EG>> to 7.1-RELEASE.
 > 
 > > If you have re(4) issues, please provide more details such as
 > > dmesg output, way to reproduce the issue etc.
 > 
 > The issue is now gone but I am sorry 7.1 didn't get the fix in time.
 > 

I see, Unfortunately the issue was fixed in the end of 7.1-R
release process so I wanted to get more exposure before MFC.
I'll make sure to MFC to stable/7 after more testing.

-- 
Regards,
Pyun YongHyeon
From oberman at es.net  Sun Jan 11 22:50:38 2009
From: oberman at es.net (Kevin Oberman)
Date: Sun Jan 11 22:50:47 2009
Subject: mergemaster broken -- take 2 
In-Reply-To: Your message of "Mon, 12 Jan 2009 08:22:40 +0200."
	<496AE1AF.9060104@bsd.ee> 
Message-ID: <20090112064007.8463E1CC0B@ptavv.es.net>

> Date: Mon, 12 Jan 2009 08:22:40 +0200
> From: Andrei Kolu <antik@bsd.ee>
> Sender: owner-freebsd-stable@freebsd.org
> 
> Mike Lempriere wrote:
> > Thanks everyone for the advice -- I got it working this time just 
> > fine.  Works much better when one follows the directions accurately 
> > instead of by memory -- the bottom line is that this time I remembered 
> > to jot down the commands before heading downtown to the machine rack 
> > room where there's no browser access...  I started over and followed 
> > UPDATING:
> >  cd /usr/obj
> >  rm -R *
> >  cd /usr/src
> >  rm -R *
> >  cvsup -g -L 2 -h cvsup10.freebsd.org |& tee /root/cvsup-090108.out
> >  make buildworld |& tee /root/make-buildworld-090108.out
> >  make kernel KERNCONF=GENERIC |& tee /root/make-kernel-090108.out
> >  users
> >  ps ax | more
> >  shutdown -r now
> You can go into single user without rebooting just by issuing command:
> 
> # shutdown now
> 
> NOTE: Network access will be shut down also, so you should be on your 
> console then.

Did you even bother reading Oliver's explanation as to why it's a very
bad idea.

The official upgrade procedure can be modified if you know EXACTLY what
you are doing, but it is unwise to suggest that you can go ahead without
adequate knowledge of the risks. Please don't suggest skipping the
reboot. Feel free to do so yourself, but don't expect much sympathy when
an upgrade blows up and a system is down for several hours while you
clean up the mess.

> >> It _is_ necessary.  If you don't reboot, you're still running
> >> the old kernel which might not be able to support new binaries
> >> and libraries that installworld will install on your system.
> >>
> >> For example, there may be new syscalls that the new binaries
> >> will try to use, but the old kernel doesn't know about them.
> >> It doesn't happen often, so you can get away without rebooting
> >> most of the time.  But it's risky, especially when updating
> >> across major versions.  So the recommendation is to always
> >> reboot after installing the new kernel and before performing
> >> the "installworld".
> >>
> >> It's also important that "installworld" is the last step
> >> (except for mergemaster), because this is the point of no
> >> return.  As long as you still have the old userland (world),
> >> you can still boot the old kernel and everything is fine.
> >> You can start all over froms cratch, if necessary.
> >> But as soon as you have started "installworld", your system
> >> will not be able to work with the old kernel anymore.
> >>
> >> And remember:  Always make a backup before you start to
> >> update.  And verify that the backup works.  Better safe
> >> than sorry.
> >>
> >> Best regards
> >>    Oliver
> >>
> >>   
> >
> 
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 224 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090112/f332513d/attachment.pgp
From eugene at donpac.ru  Sun Jan 11 23:26:48 2009
From: eugene at donpac.ru (eugene@donpac.ru)
Date: Sun Jan 11 23:27:20 2009
Subject: FreeBSD 7.1 Breaks re and rl Network Interface Drivers
In-Reply-To: <20090112011146.GC46346@cdnetworks.co.kr>
References: <8dfae1c10901070639x67945324jeeecfcac647d7976@mail.gmail.com>
	<8dfae1c10901071550s69d99802p31ca7c775f3d6823@mail.gmail.com>
	<88527079.20090111192206@donpac.ru>
	<20090112011146.GC46346@cdnetworks.co.kr>
Message-ID: <64114.83.221.215.168.1231741940.squirrel@83.221.215.168>

EG>> Does kern/130011 look similar?
EG>> http://www.freebsd.org/cgi/query-pr.cgi?pr=130011

> Do you have RTL8168C controller? If not, it's not related with
> Walter's issue as 7.0-RELEASE didn't have a support for RTL8168C.

Look into kern/130011. As far as I can see I do have RTL8168C.

EG>> The re driver was really broken in 7.1-RC2 and the fix didn't get
EG>> to 7.1-RELEASE.

> If you have re(4) issues, please provide more details such as
> dmesg output, way to reproduce the issue etc.

The issue is now gone but I am sorry 7.1 didn't get the fix in time.

-- 
Eugene Gladchenko
EVG15-RIPE


From olli at lurza.secnetix.de  Mon Jan 12 00:09:58 2009
From: olli at lurza.secnetix.de (Oliver Fromme)
Date: Mon Jan 12 00:10:05 2009
Subject: ZFSv13 in RELENG7
In-Reply-To: <E1LM0UG-0006sE-00.msnkipa-mail-ru@f149.mail.ru>
Message-ID: <200901120809.n0C89sib054679@lurza.secnetix.de>

msnkipa@mail.ru wrote:
 > Is any plans to backport ZFSv13 from CURRENT to RELENG7 branxh or not?

AFAIR Pawel explained that he intends to backport it to
RELENG7, but it will take some time because it is a huge
amount of code.  Also, it depends on other merges from
-current by other people that are not directly ZFS-related.
Therefore the time frame is currently unknown.

On the other hand, 8-current seems to run quite stable at
the moment; I have it running on a workstation for several
weeks without problems.  So if you're eager to try ZFS 13,
you might consider upgrading to -current.  Also note that
there are improvements in -current (by Alan Cox) that fix
issues related to kmem in 64bit mode (FreeBSD/amd64).  ZFS
will very much benefit from those improvements; you don't
have to tune kmem anymore in order to avoid panics.

Best regards
   Oliver

-- 
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606,  Gesch?ftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M?n-
chen, HRB 125758,  Gesch?ftsf?hrer: Maik Bachmann, Olaf Erb, Ralf Gebhart

FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd

Python is executable pseudocode.  Perl is executable line noise.
From gavin at FreeBSD.org  Mon Jan 12 02:38:09 2009
From: gavin at FreeBSD.org (Gavin Atkinson)
Date: Mon Jan 12 02:38:16 2009
Subject: Lock order reversals using bce in 7.1
In-Reply-To: <E1LM3uv-0001CD-7X@dilbert.ticketswitch.com>
References: <E1LM3uv-0001CD-7X@dilbert.ticketswitch.com>
Message-ID: <1231756684.59797.1.camel@buffy.york.ac.uk>

On Sun, 2009-01-11 at 17:16 +0000, Pete French wrote:
> Here is a better set of images. This machine was compiled
> with the following config file:
> 
> include         GENERIC
> ident           DEBUG
> 
> options         KDB
> options         DDB
> options         SW_WATCHDOG
> options         DEBUG_VFS_LOCKS
> options         MUTEX_DEBUG
> options         WITNESS
> options         WITNESS_KDB

You don't want WITNESS_KDB, but WITNESS_SKIPSPIN would probably be
sensible to include.

> options         LOCK_PROFILING
> options         INVARIANTS
> options         INVARIANT_SUPPORT
> options         DIAGNOSTIC
> 
> On booting it almost immediately does this:
> 
>         http://www.twisted.org.uk/~pete/71_lor.png

That's due to WITNESS_KDB and probably unrelated to your problems.

Gavin
From andrew at modulus.org  Mon Jan 12 02:38:49 2009
From: andrew at modulus.org (Andrew Snow)
Date: Mon Jan 12 02:38:56 2009
Subject: ZFSv13 in RELENG7
In-Reply-To: <200901120809.n0C89sib054679@lurza.secnetix.de>
References: <200901120809.n0C89sib054679@lurza.secnetix.de>
Message-ID: <496B1DA8.5010407@modulus.org>

Oliver Fromme wrote:
> On the other hand, 8-current seems to run quite stable at
> the moment; I have it running on a workstation for several
> weeks without problems.

What date of CURRENT are you running?  I tracked down crashes related to 
changes in SMBFS, but I am still experiencing almost weekly crashes such 
as machine running out of swap space in the middle of the night for no 
apparent reason..

From spry at anarchy.in.the.ph  Mon Jan 12 03:21:26 2009
From: spry at anarchy.in.the.ph (Mars G Miro)
Date: Mon Jan 12 03:21:33 2009
Subject: igb on a Nehalem system, buildworld stats
In-Reply-To: <f12f408a0901090222h589ddf43wa0ddddc0fbde5afe@mail.gmail.com>
References: <f12f408a0901080616t78dded81l979a4ec06de7739f@mail.gmail.com>
	<2a41acea0901080844y1c2ad632t12aeadfbe9f34d0a@mail.gmail.com>
	<f12f408a0901081019x2ea4e83i47851fa3ed2a0ae4@mail.gmail.com>
	<2a41acea0901081033h7db7a1aej8399baf5dcbd270f@mail.gmail.com>
	<f12f408a0901081050p1a8154c5h19035f399944b3fc@mail.gmail.com>
	<f12f408a0901090002k4f50472aleb52c63359365232@mail.gmail.com>
	<2a41acea0901090115q6af9f364qac23a8cce444d27a@mail.gmail.com>
	<f12f408a0901090214x2daafb37ld74836f628cfca8c@mail.gmail.com>
	<f12f408a0901090222h589ddf43wa0ddddc0fbde5afe@mail.gmail.com>
Message-ID: <f12f408a0901120321m5e055b3avaa2492c9574808f8@mail.gmail.com>

On Fri, Jan 9, 2009 at 6:22 PM, Mars G Miro <spry@anarchy.in.the.ph> wrote:
> On Fri, Jan 9, 2009 at 6:14 PM, Mars G Miro <spry@anarchy.in.the.ph> wrote:
>> On Fri, Jan 9, 2009 at 5:15 PM, Jack Vogel <jfvogel@gmail.com> wrote:
>>>
>> [snip]
>>>> >>
>>>> >> If you have a back to back connection to another NIC on Port 0, no
>>>> >> switch,
>>>> >> does
>>>> >> it still autoneg to 100?
>>>> >>
>>>>
>>>> Connected back to back w/ another box w/ a GigE NIC, it now does
>>>> 1000baseTX:
>>>>
>>>> igb0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
>>>>        options=19b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4>
>>>>        ether 00:30:48:c5:db:e2
>>>>        inet6 fe80::230:48ff:fec5:dbe2%igb0 prefixlen 64 scopeid 0x1
>>>>        inet 192.168.70.2 netmask 0xffffff00 broadcast 192.168.70.255
>>>>        media: Ethernet autoselect (1000baseTX <full-duplex>)
>>>>        status: active
>>>>
>>>> But still not without problems. I hafta ifconfig down/up it several
>>>> times until I can see the other end. W/c is the same for igb1.
>>>
>>>
>>> OK, so you have some switch issue.  What do you mean "see the other end",
>>> if its back to back and boots up I assume it gets link, if you have the
>>> address
>>> assigned in rc.conf, and you run tcpdump on the partner do you see the arp
>>> when it comes online, and at that point can the other side ping it?
>>>
>>
>> By 'see the other end' , I meant that even if It says 1000baseTX, i
>> still can't ping the other end, well not really, as I can now see it
>> gots bad chksums:
>>
>> 1. 001691 00:30:48:c5:db:e2 > ff:ff:ff:ff:ff:ff, ethertype ARP
>> (0x0806), length 60: arp who-has 192.168.70.2 tell 192.168.70.2
>> 1. 511111 00:30:48:c5:db:e2 > 00:30:48:61:d7:f2, ethertype IPv4
>> (0x0800), length 98: (tos 0x0, ttl 64, id 20346, offset 0, flags
>> [none], proto ICMP (1), length 84) 192.168.70.2 > 192.168.70.1: ICMP
>> echo request, id 14852, seq 0, length 64
>> 000012 00:30:48:61:d7:f2 > 00:30:48:c5:db:e2, ethertype IPv4 (0x0800),
>> length 98: (tos 0x0, ttl 64, id 3034, offset 0, flags [none], proto
>> ICMP (1), length 84, bad cksum 0 (->617b)!) 192.168.70.1 >
>> 192.168.70.2: ICMP echo reply, id 14852, seq 0, length 64
>> 1. 001611 00:30:48:c5:db:e2 > 00:30:48:61:d7:f2, ethertype IPv4
>> (0x0800), length 98: (tos 0x0, ttl 64, id 57773, offset 0, flags
>> [none], proto ICMP (1), length 84) 192.168.70.2 > 192.168.70.1: ICMP
>> echo request, id 14852, seq 1, length 64
>> 000011 00:30:48:61:d7:f2 > 00:30:48:c5:db:e2, ethertype IPv4 (0x0800),
>> length 98: (tos 0x0, ttl 64, id 59591, offset 0, flags [none], proto
>> ICMP (1), length 84, bad cksum 0 (->848d)!) 192.168.70.1 >
>> 192.168.70.2: ICMP echo reply, id 14852, seq 1, length 64
>>
>> and this is back to back w/ another box w/ a GigE NIC (nfe, w/c has
>> been in production for some time)
>>
>>> Oh, and what is the link partner hardware?
>>>
>>
>> The switch? it's a Dlink 48-Port DGS-1248T GigE switch.
>>
>> Thanks.
>>
>
> btw,  I tried 200812-CURRENT and CURRENT as of Jan 7 and the behavior
> is still the same :-(
>
>

Hi again,

We installed Windows 7 BETA on it, and altho the 1st NIC behaves the
same way, e.g. if connected to a switch it stays at 100mbps, but if
connected back to back w/ another GigE it can stay at 1.0Gbps, I do
not get any network problems at all, for both igb NICs.

So, something to do w/ the igb driver then ?

Thanks.

>>> Jack
>>>




-- 
cheers
mars
From kometen at gmail.com  Mon Jan 12 03:28:17 2009
From: kometen at gmail.com (Claus Guttesen)
Date: Mon Jan 12 03:28:25 2009
Subject: Big problems with 7.1 locking up :-(
In-Reply-To: <7d6fde3d0901111122v3813fe3ehf75de6a2a7e66203@mail.gmail.com>
References: <bdf82f800901101807i67078622i48e63deb448b6ec4@mail.gmail.com>
	<E1LLzgr-00008v-Nu@dilbert.ticketswitch.com>
	<7d6fde3d0901111122v3813fe3ehf75de6a2a7e66203@mail.gmail.com>
Message-ID: <b41c75520901120328m1c3de9bau19c50b2df5d74254@mail.gmail.com>

>> I am also surprised that this isn't more widely reported, as
>> the hardware is very common. The only oddity with ym compile
>> is that I set the CPUTYPE to 'core2' - that shouldnt have an effect, but
>> I will remove it anyway, just so I am actually building a completely
>> vanilla amd64. That way I should have what everyone else has, and since
>> I don't see anyone else saying they have isues then maybe mine will
>> go away too (fingers crossed)
>>
>    Intel suggests nocona for x86_64 platforms and prescott for x86
> (i386) based platforms on the 4.2 line, because they best matched the
> cache size and featureset of the Core2 processors.
>
>    I don't think that core2 support was fully completed in 4.2 (in
> fact I believe it was just started), and I don't think that our
> binutils supports it properly.
>
> Some thoughts,
> -Garrett

I've updagraded a test-webserver to 7.1 when it was released. After a
few days I upgraded a production-webserver to 7.1 on Jan. 8'th and it
has been running without any problems. The webserver is not heavily
loaded (load at 2-3 on average). I have made a buildworld -j 8 and it
runs fine.

If the reported lockup is due to i/o a buildworld will not be able to
reproduce it.

It has performed a buildworld without problems and I'll be doing some
buildworlds throughout the day.

This is on a HP c-class-blade with 8 GB ram, 2 x quad-core and the
build-in p200-controller with 64 MB ram.

-- 
regards
Claus

When lenity and cruelty play for a kingdom,
the gentler gamester is the soonest winner.

Shakespeare
From kometen at gmail.com  Mon Jan 12 03:37:17 2009
From: kometen at gmail.com (Claus Guttesen)
Date: Mon Jan 12 03:37:24 2009
Subject: Big problems with 7.1 locking up :-(
In-Reply-To: <b41c75520901120328m1c3de9bau19c50b2df5d74254@mail.gmail.com>
References: <bdf82f800901101807i67078622i48e63deb448b6ec4@mail.gmail.com>
	<E1LLzgr-00008v-Nu@dilbert.ticketswitch.com>
	<7d6fde3d0901111122v3813fe3ehf75de6a2a7e66203@mail.gmail.com>
	<b41c75520901120328m1c3de9bau19c50b2df5d74254@mail.gmail.com>
Message-ID: <b41c75520901120337g49a357e0k7438388ca3a57d88@mail.gmail.com>

> I've updagraded a test-webserver to 7.1 when it was released. After a
> few days I upgraded a production-webserver to 7.1 on Jan. 8'th and it
> has been running without any problems. The webserver is not heavily
> loaded (load at 2-3 on average). I have made a buildworld -j 8 and it
> runs fine.
>
> If the reported lockup is due to i/o a buildworld will not be able to
> reproduce it.
>
> It has performed a buildworld without problems and I'll be doing some
> buildworlds throughout the day.
>
> This is on a HP c-class-blade with 8 GB ram, 2 x quad-core and the
> build-in p200-controller with 64 MB ram.

Forgot to add that CPUTYPE=nocona in /etc/make.conf.

-- 
regards
Claus

When lenity and cruelty play for a kingdom,
the gentler gamester is the soonest winner.

Shakespeare
From olli at lurza.secnetix.de  Mon Jan 12 03:39:31 2009
From: olli at lurza.secnetix.de (Oliver Fromme)
Date: Mon Jan 12 03:39:38 2009
Subject: ZFSv13 in RELENG7
In-Reply-To: <496B1DA8.5010407@modulus.org>
Message-ID: <200901121139.n0CBdO6L063545@lurza.secnetix.de>

Andrew Snow wrote:
 > Oliver Fromme wrote:
 > > On the other hand, 8-current seems to run quite stable at
 > > the moment; I have it running on a workstation for several
 > > weeks without problems.
 > 
 > What date of CURRENT are you running?  I tracked down crashes related to 
 > changes in SMBFS, but I am still experiencing almost weekly crashes such 
 > as machine running out of swap space in the middle of the night for no 
 > apparent reason..

$ uname -rs
FreeBSD 8.0-CURRENT-20081128
$ uptime
12:23PM  up 25 days, 22:07, 0 users, load averages: 0.00, 0.00, 0.00

I'm not using SMBFS, though.  It's a workstation running
typical desktop things (xterms, web browser, gimp, sane
and similar).

Best regards
   Oliver

PS:  Just in case someone wonders how to get timestamp
suffixes to the kernel version string:  I'm using this
little script in place of "make kernel":

http://www.secnetix.de/olli/scripts/makekernel

-- 
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606,  Gesch?ftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M?n-
chen, HRB 125758,  Gesch?ftsf?hrer: Maik Bachmann, Olaf Erb, Ralf Gebhart

FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd

"[...]  one observation we can make here is that Python makes
an excellent pseudocoding language, with the wonderful attribute
that it can actually be executed."  --  Bruce Eckel
From ivoras at freebsd.org  Mon Jan 12 03:55:02 2009
From: ivoras at freebsd.org (Ivan Voras)
Date: Mon Jan 12 03:55:09 2009
Subject: ZFSv13 in RELENG7
In-Reply-To: <496B1DA8.5010407@modulus.org>
References: <200901120809.n0C89sib054679@lurza.secnetix.de>
	<496B1DA8.5010407@modulus.org>
Message-ID: <gkfau1$gha$2@ger.gmane.org>

Andrew Snow wrote:
> Oliver Fromme wrote:
>> On the other hand, 8-current seems to run quite stable at
>> the moment; I have it running on a workstation for several
>> weeks without problems.
> 
> What date of CURRENT are you running?  I tracked down crashes related to
> changes in SMBFS, but I am still experiencing almost weekly crashes such
> as machine running out of swap space in the middle of the night for no
> apparent reason..

Are you running rsync? Are the crashes happenning at about 3 am? (these
two questions are unrelated)

-------------- 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-stable/attachments/20090112/c73c41bd/signature.pgp
From msnkipa at mail.ru  Mon Jan 12 02:49:14 2009
From: msnkipa at mail.ru (=?koi8-r?Q?=ED=C9=C8=C1=C9=CC_=EB=C9=D0=C1?=)
Date: Mon Jan 12 04:47:25 2009
Subject: NFSv4 server
Message-ID: <E1LMKLy-0003oq-00.msnkipa-mail-ru@f106.mail.ru>

Is there any plans to include NFSv4 server into FreeBSD?
From avg at icyb.net.ua  Mon Jan 12 04:57:18 2009
From: avg at icyb.net.ua (Andriy Gapon)
Date: Mon Jan 12 04:57:36 2009
Subject: fsck_y_enable: suboptimal/odd?
Message-ID: <496B3E28.3070902@icyb.net.ua>


System: stable/7 some time before New Year (sorry if this issue has
already been acted upon).

I have a system with perhaps sufficiently rare configuration:
it has fsck_y_enable="YES" and it has multiple filesystems mounted
(UFS2), some RW, some RO.

Today I had a chance to see fsck_y_enable in action.
After a hard-lock followed by a reset normal fsck process started,
several filesystems had "expected" inconsistencies and were successfully
repaired, and then one filesystem had an unexpected inconsistency
(partially truncated inode it was). After that normal fsck process was
aborted and "fsck_y" process started.
To much of my surprise it started all over - the filesystems that had
been just successfully checked were being checked again. Even more -
filesystems that had been mounted RO before the reset were also being
checked.

To me it seems like fsck_y passes suboptimal flags to fsck, it doesn't
have to examine each and every filesystem in fstab.

-- 
Andriy Gapon

From petefrench at ticketswitch.com  Mon Jan 12 05:30:13 2009
From: petefrench at ticketswitch.com (Pete French)
Date: Mon Jan 12 05:30:21 2009
Subject: Lock order reversals using bce in 7.1
In-Reply-To: <1231756684.59797.1.camel@buffy.york.ac.uk>
Message-ID: <E1LMMrp-0000S9-0I@dilbert.ticketswitch.com>

> You don't want WITNESS_KDB, but WITNESS_SKIPSPIN would probably be
> sensible to include.

OK, I will take out the WITNESS_KDB. I am reluctant to add in
WITNESS_SKIPSPIN though, as I understand it stops witnessing spin
locks, is that right ? As the only error message I have ever got out
of all fo this explicitly mentioned spinlocks then I'd rather have them
monitored.

> That's due to WITNESS_KDB and probably unrelated to your problems.

OK, will re-do all those tests - and also revert to the correct subject line
for this thread (I am not quite sure why I typed a new one, it's a stupid
thing to do as it makes it hard to follow).

cheers,

-pete.
From kometen at gmail.com  Mon Jan 12 06:11:53 2009
From: kometen at gmail.com (Claus Guttesen)
Date: Mon Jan 12 06:11:59 2009
Subject: Big problems with 7.1 locking up :-(
In-Reply-To: <b41c75520901120337g49a357e0k7438388ca3a57d88@mail.gmail.com>
References: <bdf82f800901101807i67078622i48e63deb448b6ec4@mail.gmail.com>
	<E1LLzgr-00008v-Nu@dilbert.ticketswitch.com>
	<7d6fde3d0901111122v3813fe3ehf75de6a2a7e66203@mail.gmail.com>
	<b41c75520901120328m1c3de9bau19c50b2df5d74254@mail.gmail.com>
	<b41c75520901120337g49a357e0k7438388ca3a57d88@mail.gmail.com>
Message-ID: <b41c75520901120611r4dbbbfbdmd4ca22496ad9d12b@mail.gmail.com>

>> It has performed a buildworld without problems and I'll be doing some
>> buildworlds throughout the day.
>>
>> This is on a HP c-class-blade with 8 GB ram, 2 x quad-core and the
>> build-in p200-controller with 64 MB ram.

I've performed five buildworlds decrementing -j from 16 to 6 and I
can't lock up the server.

-- 
regards
Claus

When lenity and cruelty play for a kingdom,
the gentler gamester is the soonest winner.

Shakespeare
From petefrench at ticketswitch.com  Mon Jan 12 06:35:30 2009
From: petefrench at ticketswitch.com (Pete French)
Date: Mon Jan 12 06:35:37 2009
Subject: Big problems with 7.1 locking up :-(
In-Reply-To: <b41c75520901120611r4dbbbfbdmd4ca22496ad9d12b@mail.gmail.com>
Message-ID: <E1LMNsw-0001ix-Q7@dilbert.ticketswitch.com>

> I've performed five buildworlds decrementing -j from 16 to 6 and I
> can't lock up the server.

Mine never lock up doing buildworlds either. They only lock up when they are
sitting there more of less idle! The machines which have never locked up
are the webservers, which are fairly heavlt loaded. The machine which locks
up the most frequently is a box sitting there doing nothing but DNS, which is
the most lightly loaded of the lot.

I am going to roll back to 7.0 on all of the HP machines now, having
had yet another day of rebooting locked up machines. I will leave one
running 7.1 with the debug options in the kernel to try and get some
useful results out of this. All the machines are now running GENERIC with
no specail optimisations, CPU types or anything like that. Absolutely out
of the box vanilla 7.1/amd64 as far as I know :-(

-pete.

From rwatson at FreeBSD.org  Mon Jan 12 06:55:24 2009
From: rwatson at FreeBSD.org (Robert Watson)
Date: Mon Jan 12 06:55:39 2009
Subject: Big problems with 7.1 locking up :-(
In-Reply-To: <p06240802c58db5953598@[128.113.24.47]>
References: <E1LL6dg-0007CN-DI@dilbert.ticketswitch.com>
	<042FE04A-2F8D-47DD-8454-7BBA3791D7A8@inoc.net>
	<p06240802c58db5953598@[128.113.24.47]>
Message-ID: <alpine.BSF.2.00.0901121453200.16794@fledge.watson.org>


On Fri, 9 Jan 2009, Garance A Drosihn wrote:

> At 2:39 PM -0500 1/9/09, Robert Blayzor wrote:
>> On Jan 8, 2009, at 8:58 PM, Pete French wrote:
>>> I have a number of HP 1U servers, all of which were running 7.0 perfectly 
>>> happily. I have been testing 7.1 in it's various incarnations for the last 
>>> couple of months on our test server and it has performed perfectly.
>> 
>> I noticed a problem with 7.0 on a couple of Dell servers.  [...] We've 
>> since then compiled the kernel under the BSD scheduler to rule that out, 
>> and so far so good.
>> 
>> Since ULE is now default in 7.1 and not in 7.0, perhaps you can try that?
>
> FWIW, the other guy I know who is having this problem had already switched 
> to using ULE under 7.0-release, and did not have any problems with it.  So 
> *his* problem was probably not related to SCHED_ULE, unless something has 
> recently changed there.
>
> Turns out he hasn't reverted back to 7.0-release just yet, so he's going to 
> try SCHED_4BSD and see if that helps his situation.

Scheduler changes always come with some risk of exposing bugs that have 
existed in the code for a long time but never really manifested themselves. 
ULE is well shaken-out, having been under development for at least five years, 
but it is possible that some problems will become visible as a result of the 
switch.  I would encourage people to stick with ULE, but if you're having a 
stability problem then experimenting with scheduler as a variable that could 
be triggering the problem may well be useful to help track down the bug.  Most 
of the time the bugs will not be in ULE itself, rather, triggered because ULE 
will change the ordering or balancing of work in the system, so we should try 
to avoid situations where people switch to 4BSD from ULE and stick with it 
rather than getting the underlying problem fixed!

Robert N M Watson
Computer Laboratory
University of Cambridge
From rwatson at FreeBSD.org  Mon Jan 12 07:00:42 2009
From: rwatson at FreeBSD.org (Robert Watson)
Date: Mon Jan 12 07:00:49 2009
Subject: Big problems with 7.1 locking up :-(
In-Reply-To: <E1LLg5j-000Lmm-QO@dilbert.ticketswitch.com>
References: <E1LLg5j-000Lmm-QO@dilbert.ticketswitch.com>
Message-ID: <alpine.BSF.2.00.0901121458140.16794@fledge.watson.org>

On Sat, 10 Jan 2009, Pete French wrote:

>> FWIW, the other guy I know who is having this problem had already switched 
>> to using ULE under 7.0-release, and did not have any problems with it.  So 
>> *his* problem was probably not related to SCHED_ULE, unless something has 
>> recently changed there.
>
> Well, one of my machines just locked up again, even with SCHED_4BSD on it, 
> so I am now thinking it is unrelated.
>
> The machine has completely locked - no response to pings, no response to 
> keypresses, nor to the power button. There is nothing printed on the console 
> - it is just sitting there with a login prompt :-(
>
> This is really not good - these are extremely common servers after all, and 
> I am just running bog standard 7.1 with apache and mysql. This is happening 
> across several different servers, all of which are slight variants on the 
> DL360, so I dont think it is something perculiar to me.

I'm not sure if you've done this already, but the normal suggestions apply: 
have you compiled with INVARIANTS/WITNESS/DDB/KDB/BREAK_TO_DEBUGGER, and do 
any results / panics / etc result?  Sometimes these debugging tools are able 
to convert hangs into panics, which gives us much more ability to debug them. 
If it still hangs rather than panicking, are you able to break into the 
debugger on the console?  If you're using a video console and not able to get 
to the debugger, would it be possible to configure a serial console and use 
that -- serial breaks are often more successful at getting to the debugger 
than keyboard breaks.  Likewise, I'm not sure if this hardware has an NMI 
button -- some HP servers have one on the motherboard that you can press -- 
but that is also potentially a way to get into the debugger the analyze the 
crash.

Robert N M Watson
Computer Laboratory
University of Cambridge
From petefrench at ticketswitch.com  Mon Jan 12 07:16:51 2009
From: petefrench at ticketswitch.com (Pete French)
Date: Mon Jan 12 07:16:58 2009
Subject: Big problems with 7.1 locking up :-(
In-Reply-To: <alpine.BSF.2.00.0901121458140.16794@fledge.watson.org>
Message-ID: <E1LMOWu-0001t4-BH@dilbert.ticketswitch.com>

> I'm not sure if you've done this already, but the normal suggestions apply: 
> have you compiled with INVARIANTS/WITNESS/DDB/KDB/BREAK_TO_DEBUGGER, and do 
> any results / panics / etc result?  Sometimes these debugging tools are able 
> to convert hangs into panics, which gives us much more ability to debug them. 

I did, but it turns out I had an incorrect option in there which made the
data I got not relevent. I now have another machine running a kernel
with the following config:

include         GENERIC
ident           DEBUG

options         KDB
options         DDB
options         SW_WATCHDOG
options         DEBUG_VFS_LOCKS
options         MUTEX_DEBUG
options         WITNESS
options         LOCK_PROFILING
options         INVARIANTS
options         INVARIANT_SUPPORT
options         DIAGNOSTIC

Those should enable me to get some useful output I hope.

> If it still hangs rather than panicking, are you able to break into the 
> debugger on the console?  If you're using a video console and not able to get 
> to the debugger, would it be possible to configure a serial console and use 

I cant add a sserial console - I am remote enough from most of
these machines (Slough) and very remote from the test box (its in the USA!)
so I cant get to them physicly. But I do have iLo which lets me use the
console and gives me a bit of access to the front. I will check for NMI.

Just had another lockup here - my working day has become a succession of
running round rebooting servers though iLo at the moment.

Will get back to you when the debug one has crashed - I could possibly
give you direct access to the iLo console on that if you need it ?

-pete.
From dimitry at andric.com  Mon Jan 12 08:37:45 2009
From: dimitry at andric.com (Dimitry Andric)
Date: Mon Jan 12 08:37:53 2009
Subject: FreeBSD 7.1 Breaks re and rl Network Interface Drivers
In-Reply-To: <20090112064121.GF46346@cdnetworks.co.kr>
References: <8dfae1c10901070639x67945324jeeecfcac647d7976@mail.gmail.com>	<8dfae1c10901071550s69d99802p31ca7c775f3d6823@mail.gmail.com>	<88527079.20090111192206@donpac.ru>	<20090112011146.GC46346@cdnetworks.co.kr>	<64114.83.221.215.168.1231741940.squirrel@83.221.215.168>
	<20090112064121.GF46346@cdnetworks.co.kr>
Message-ID: <496B71D3.5050203@andric.com>

On 2009-01-12 07:41, Pyun YongHyeon wrote:
> I see, Unfortunately the issue was fixed in the end of 7.1-R
> release process so I wanted to get more exposure before MFC.
> I'll make sure to MFC to stable/7 after more testing.

I'm also having problems with re's, in my case the interfaces take about
10 seconds to come up, if they come up at all.  After the interfaces are
up, half the time no packets go out at all.  Usually it helps to bring
them down via the console, wait about 10 seconds, and then bring them up
again...

These are the following variant:

FreeBSD 7.1-STABLE #0: Mon Jan 12 14:22:11 CET 2009
[...]
re0: <RealTek 8169SC/8110SC Single-chip Gigabit Ethernet> port 0xf000-0xf0ff mem 0xfdfff000-0xfdfff0ff irq 18 at device 9.0 on pci0
re0: Chip rev. 0x18000000
re0: MAC rev. 0x00000000
miibus0: <MII bus> on re0
rgephy0: <RTL8169S/8110S/8211B media interface> PHY 1 on miibus0
rgephy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto
re0: Ethernet address: 00:30:18:a6:f1:a8
re0: [FILTER]
re1: <RealTek 8169SC/8110SC Single-chip Gigabit Ethernet> port 0xf200-0xf2ff mem 0xfdffe000-0xfdffe0ff irq 19 at device 11.0 on pci0
re1: Chip rev. 0x18000000
re1: MAC rev. 0x00000000
miibus1: <MII bus> on re1
rgephy1: <RTL8169S/8110S/8211B media interface> PHY 1 on miibus1
rgephy1:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto
re1: Ethernet address: 00:30:18:a6:f1:a9
re1: [FILTER]

And just FYI, r187080-r187083 that you recently committed (MFCs of
r184240-184243, r184245, 185575 and r186390), don't seem to change
anything for this situation. :(
From sascha at holzleiter.name  Mon Jan 12 09:20:10 2009
From: sascha at holzleiter.name (Sascha Holzleiter)
Date: Mon Jan 12 09:20:20 2009
Subject: FreeBSD 7.1 Breaks re and rl Network Interface Drivers
In-Reply-To: <8dfae1c10901070639x67945324jeeecfcac647d7976@mail.gmail.com>
References: <8dfae1c10901070639x67945324jeeecfcac647d7976@mail.gmail.com>
Message-ID: <496B7C17.8010107@holzleiter.name>

Walter Venable wrote:
> FreeBSD 7.1 upgrade broke my network access, machine is totally
> offline (powered-on and I can play inside it at the terminal, but
> absolutely 0 network access):
> This happened AFTER make kernel but BEFORE make installworld.  I think
> this implies it's a kernel driver issue.

Hi,

i see similar problems with a re card:

re0@pci0:4:7:0:	class=0x020000 card=0x816710ec chip=0x816710ec rev=0x10 
hdr=0x00
     vendor     = 'Realtek Semiconductor'
     device     = 'RTL8169/8110 Family Gigabit Ethernet NIC'
     class      = network
     subclass   = ethernet

After upgrading to 7.1-RELEASE (and also STABLE) the NIC doesn't seem to 
receive any frames. I can see the DHCP Requests on the DHCP Server but 
the DHCPOFFERS are never seen by the client with the re0 device.
After setting promiscious mode on the interface (i.e. by tcpdump -ni 
re0) the interface begins to work fine.

I've attached a complete dmesg output, but i think the detection works 
fine, here the short version:

re0: <RealTek 8169SC/8110SC Single-chip Gigabit Ethernet> port 
0x9c00-0x9cff mem 0xdfdff000-0xdfdff0ff irq 20 at device 7.0 on pci4
re0: Chip rev. 0x18000000
re0: MAC rev. 0x00000000
miibus0: <MII bus> on re0
rgephy0: <RTL8169S/8110S/8211B media interface> PHY 1 on miibus0
rgephy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 
1000baseT-FDX, auto
re0: Ethernet address: 00:1a:92:35:29:fa
re0: [FILTER]

-------------- next part --------------
Copyright (c) 1992-2009 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
	The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 7.1-STABLE #0: Mon Jan 12 14:18:26 CET 2009
    root@dreamland.office.local:/usr/obj/usr/src/sys/DREAMLAND
Timecounter "i8254" frequency 1193182 Hz quality 0
CPU: Intel(R) Core(TM)2 CPU          6320  @ 1.86GHz (1863.87-MHz 686-class CPU)
  Origin = "GenuineIntel"  Id = 0x6f6  Stepping = 6
  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=0xe3bd<SSE3,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM>
  AMD Features=0x20100000<NX,LM>
  AMD Features2=0x1<LAHF>
  Cores per package: 2
real memory  = 2146304000 (2046 MB)
avail memory = 2086531072 (1989 MB)
ACPI APIC Table: <AWARD  ASUSACPI>
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
 cpu0 (BSP): APIC ID:  0
 cpu1 (AP): APIC ID:  1
ioapic0: Changing APIC ID to 4
ioapic0 <Version 0.3> irqs 0-23 on motherboard
ioapic1 <Version 0.3> irqs 24-47 on motherboard
kbd1 at kbdmux0
acpi0: <AWARD ASUSACPI> on motherboard
acpi0: [ITHREAD]
acpi0: Power Button (fixed)
acpi0: reservation of 100000, 7fde0000 (3) failed
acpi0: reservation of 0, a0000 (3) failed
Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000
acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0
acpi_hpet0: <High Precision Event Timer> iomem 0xfe800000-0xfe8003ff on acpi0
device_attach: acpi_hpet0 attach returned 12
acpi_button0: <Power Button> on acpi0
acpi_button1: <Sleep Button> on acpi0
pcib0: <ACPI Host-PCI bridge> port 0xcf8-0xcff on acpi0
pci0: <ACPI PCI bus> on pcib0
pcib1: <PCI-PCI bridge> at device 1.0 on pci0
pci1: <PCI bus> on pcib1
pcib2: <ACPI PCI-PCI bridge> irq 27 at device 2.0 on pci0
pci2: <ACPI PCI bus> on pcib2
vgapci0: <VGA-compatible display> port 0xac00-0xac7f mem 0xdc000000-0xdcffffff,0xc0000000-0xcfffffff,0xdd000000-0xddffffff irq 24 at device 0.0 on pci2
nvidia0: <GeForce 7300 GT> on vgapci0
vgapci0: child nvidia0 requested pci_enable_busmaster
vgapci0: child nvidia0 requested pci_enable_io
nvidia0: [GIANT-LOCKED]
nvidia0: [ITHREAD]
pcib3: <ACPI PCI-PCI bridge> irq 31 at device 3.0 on pci0
pci3: <ACPI PCI bus> on pcib3
atapci0: <JMicron JMB363 SATA300 controller> port 0xcc00-0xcc07,0xc800-0xc803,0xc400-0xc407,0xc000-0xc003,0xbc00-0xbc0f mem 0xdfefe000-0xdfefffff irq 28 at device 0.0 on pci3
atapci0: [ITHREAD]
atapci0: AHCI called from vendor specific driver
atapci0: AHCI Version 01.00 controller with 2 ports detected
ata2: <ATA channel 0> on atapci0
ata2: [ITHREAD]
ata3: <ATA channel 1> on atapci0
ata3: [ITHREAD]
ata4: <ATA channel 2> on atapci0
ata4: [ITHREAD]
atapci1: <VIA 8237A SATA150 controller> port 0xfc00-0xfc07,0xf800-0xf803,0xf400-0xf407,0xf000-0xf003,0xec00-0xec0f,0xe800-0xe8ff irq 21 at device 15.0 on pci0
atapci1: [ITHREAD]
ata5: <ATA channel 0> on atapci1
ata5: [ITHREAD]
ata6: <ATA channel 1> on atapci1
ata6: [ITHREAD]
atapci2: <VIA 8237A UDMA133 controller> port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xe400-0xe40f at device 15.1 on pci0
ata0: <ATA channel 0> on atapci2
ata0: [ITHREAD]
ata1: <ATA channel 1> on atapci2
ata1: [ITHREAD]
uhci0: <VIA 83C572 USB controller> port 0xe000-0xe01f irq 20 at device 16.0 on pci0
uhci0: [GIANT-LOCKED]
uhci0: [ITHREAD]
usb0: <VIA 83C572 USB controller> on uhci0
usb0: USB revision 1.0
uhub0: <VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb0
uhub0: 2 ports with 2 removable, self powered
uhci1: <VIA 83C572 USB controller> port 0xdc00-0xdc1f irq 22 at device 16.1 on pci0
uhci1: [GIANT-LOCKED]
uhci1: [ITHREAD]
usb1: <VIA 83C572 USB controller> on uhci1
usb1: USB revision 1.0
uhub1: <VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb1
uhub1: 2 ports with 2 removable, self powered
uhci2: <VIA 83C572 USB controller> port 0xd800-0xd81f irq 21 at device 16.2 on pci0
uhci2: [GIANT-LOCKED]
uhci2: [ITHREAD]
usb2: <VIA 83C572 USB controller> on uhci2
usb2: USB revision 1.0
uhub2: <VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb2
uhub2: 2 ports with 2 removable, self powered
uhci3: <VIA 83C572 USB controller> port 0xd400-0xd41f irq 23 at device 16.3 on pci0
uhci3: [GIANT-LOCKED]
uhci3: [ITHREAD]
usb3: <VIA 83C572 USB controller> on uhci3
usb3: USB revision 1.0
uhub3: <VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb3
uhub3: 2 ports with 2 removable, self powered
ehci0: <VIA VT6202 USB 2.0 controller> mem 0xdffff000-0xdffff0ff irq 21 at device 16.4 on pci0
ehci0: [GIANT-LOCKED]
ehci0: [ITHREAD]
usb4: EHCI version 1.0
usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3
usb4: <VIA VT6202 USB 2.0 controller> on ehci0
usb4: USB revision 2.0
uhub4: <VIA EHCI root hub, class 9/0, rev 2.00/1.00, addr 1> on usb4
uhub4: 8 ports with 8 removable, self powered
isab0: <PCI-ISA bridge> at device 17.0 on pci0
isa0: <ISA bus> on isab0
pcib4: <ACPI PCI-PCI bridge> at device 19.1 on pci0
pci4: <ACPI PCI bus> on pcib4
re0: <RealTek 8169SC/8110SC Single-chip Gigabit Ethernet> port 0x9c00-0x9cff mem 0xdfdff000-0xdfdff0ff irq 20 at device 7.0 on pci4
re0: Chip rev. 0x18000000
re0: MAC rev. 0x00000000
miibus0: <MII bus> on re0
rgephy0: <RTL8169S/8110S/8211B media interface> PHY 1 on miibus0
rgephy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto
re0: Ethernet address: 00:1a:92:35:29:fa
re0: [FILTER]
pcib5: <ACPI Host-PCI bridge> on acpi0
pci128: <ACPI PCI bus> on pcib5
pci128: <multimedia, HDA> at device 1.0 (no driver attached)
acpi_tz0: <Thermal Zone> on acpi0
atkbdc0: <Keyboard controller (i8042)> port 0x60,0x64 irq 1 on acpi0
atkbd0: <AT Keyboard> irq 1 on atkbdc0
kbd0 at atkbd0
atkbd0: [GIANT-LOCKED]
atkbd0: [ITHREAD]
cpu0: <ACPI CPU> on acpi0
est0: <Enhanced SpeedStep Frequency Control> on cpu0
p4tcc0: <CPU Frequency Thermal Control> on cpu0
cpu1: <ACPI CPU> on acpi0
est1: <Enhanced SpeedStep Frequency Control> on cpu1
est: CPU supports Enhanced Speedstep, but is not recognized.
est: cpu_vendor GenuineIntel, msr 72a072a0600072a
device_attach: est1 attach returned 6
p4tcc1: <CPU Frequency Thermal Control> on cpu1
acpi_hpet0: <High Precision Event Timer> iomem 0xfe800000-0xfe8003ff on acpi0
device_attach: acpi_hpet0 attach returned 12
pmtimer0 on isa0
orm0: <ISA Option ROM> at iomem 0xd0000-0xd2fff pnpid ORM0000 on isa0
sc0: <System console> at flags 0x100 on isa0
sc0: VGA <16 virtual consoles, flags=0x300>
vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0
ugen0: <vendor 0x046d product 0x08dd, class 0/0, rev 1.10/1.00, addr 2> on uhub0
ums0: <Logitech USB Optical Mouse, class 0/0, rev 2.00/43.01, addr 2> on uhub1
ums0: 3 buttons and Z dir.
Timecounters tick every 1.000 msec
acd0: DVDR <HL-DT-ST DVDRAM GSA-H44N/RB00> at ata0-master UDMA66
ad10: 76319MB <Seagate ST380215AS 3.AAC> at ata5-master SATA150
SMP: AP CPU #1 Launched!
Trying to mount root from ufs:/dev/ad10s1a
From sam at errno.com  Mon Jan 12 09:45:03 2009
From: sam at errno.com (Sam Leffler)
Date: Mon Jan 12 09:45:09 2009
Subject: HEADS UP: build changes
Message-ID: <496B7D17.7020407@errno.com>

r187106 syncs the Makefiles with HEAD so that RELENG_7 has the same set 
of build knobs.  Let me know if you see any oddities that you can trace 
to this commit.

    Sam

From nealhogan at gmail.com  Mon Jan 12 10:10:27 2009
From: nealhogan at gmail.com (Neal Hogan)
Date: Mon Jan 12 10:10:34 2009
Subject: bwi: no DS tssi no OFDM tssi
Message-ID: <ab7b49bc0901120941x524fe841tbd526387f3af234b@mail.gmail.com>

Hello,

   I am attempting to get by broadcom wifi card up and running, am sick of
trying to get ndis working, and am attempting to use the bwi driver
(originating in dragonflyBSD). I'm hoping others here have tried to do the
same and have some pointers. I'm using 7.1-RELEASE (system/source are
in-sync) and my card is a BCM94306MP. My dmesg is posted below.

Bwi(4) is installed and it recognizes my card (*if_bwi_load-"YES"* is in my
/etc/rc.conf and *bwi_v3* and *if_bwi* are loaded). I can send a IP request
to my WEP encrypted access point. Yet, it doesn't get an offer and says that
*no DS tssi* and *no OFDM tssi* Being new to bwi(4) and have never seen
references to DS/OFDM tssi, I'm not sure what info to provide. My research
is not leading anywhere helpful.  Thanks.




Copyright (c) 1992-2009 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
	The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 7.1-RELEASE #0: Sat Jan 10 19:07:15 CST 2009
    nph@frege.lambdaserver:/usr/obj/usr/src/sys/GENERIC
Timecounter "i8254" frequency 1193182 Hz quality 0
CPU: mobile AMD Athlon(tm) XP2400+ (1788.94-MHz 686-class CPU)
  Origin = "AuthenticAMD"  Id = 0x6a0  Stepping = 0
  Features=0x383f9ff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE>
  AMD Features=0xc0480800<SYSCALL,MP,MMX+,3DNow!+,3DNow!>
real memory  = 468647936 (446 MB)
avail memory = 444530688 (423 MB)
kbd1 at kbdmux0
ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413)
acpi0: <PTLTD   RSDT> on motherboard
acpi0: [ITHREAD]
acpi0: Power Button (fixed)
Timecounter "ACPI-safe" frequency 3579545 Hz quality 850
acpi_timer0: <32-bit timer at 3.579545MHz> port 0x8008-0x800b on acpi0
acpi_ec0: <Embedded Controller: GPE 0x18> port 0x62,0x66 on acpi0
pcib0: <ACPI Host-PCI bridge> port 0xcf8-0xcff on acpi0
pci_link5: BIOS IRQ 10 for 0.10.INTA is invalid
pci0: <ACPI PCI bus> on pcib0
agp0: <ATI RS100 AGP bridge> on hostb0
pcib1: <ACPI PCI-PCI bridge> at device 1.0 on pci0
pci1: <ACPI PCI bus> on pcib1
vgapci0: <VGA-compatible display> port 0x9000-0x90ff mem
0xe0000000-0xefffffff,0xd0100000-0xd010ffff irq 10 at device 5.0 on
pci1
ohci0: <AcerLabs M5237 (Aladdin-V) USB controller> mem
0xd0006000-0xd0006fff irq 9 at device 2.0 on pci0
ohci0: [GIANT-LOCKED]
ohci0: [ITHREAD]
usb0: OHCI version 1.0, legacy support
usb0: SMM does not respond, resetting
usb0: <AcerLabs M5237 (Aladdin-V) USB controller> on ohci0
usb0: USB revision 1.0
uhub0: <AcerLabs OHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb0
uhub0: 4 ports with 4 removable, self powered
pcm0: <Acer Labs M5451> port 0x8400-0x84ff mem 0xd0007000-0xd0007fff
irq 5 at device 6.0 on pci0
pcm0: <Conexant CX20468 AC97 Codec>
pcm0: [GIANT-LOCKED]
pcm0: [ITHREAD]
isab0: <PCI-ISA bridge> at device 7.0 on pci0
isa0: <ISA bus> on isab0
pci0: <simple comms, generic modem> at device 8.0 (no driver attached)
bwi0: <Broadcom BCM4306v1 802.11 Wireless Lan> mem
0xd0004000-0xd0005fff irq 9 at device 9.0 on pci0
bwi0: [ITHREAD]
bwi0: regwin: chipcommon (0x800), rev 2, vendor 0x4243
bwi0: BBP: id 0x4306, rev 0x2, pkg 0
bwi0: nregwin 6, cap 0x0000002a
bwi0: regwin: 802.11 MAC (0x812), rev 4, vendor 0x4243
bwi0: has TX stats
bwi0: MAC: rev 4
bwi0: regwin: pcmcia (0x80d), rev 1, vendor 0x4243
bwi0: regwin: v90 codec (0x807), rev 1, vendor 0x4243
bwi0: regwin: pci (0x804), rev 7, vendor 0x4243
bwi0: regwin: 802.11 MAC (0x812), rev 4, vendor 0x4243
bwi0: ignore second MAC
bwi0: bus rev 0
bwi0: pci is enabled
bwi0: card flags 0x000f
bwi0: 0th led, act 3, lowact 0
bwi0: 1th led, act 5, lowact 0
bwi0: 2th led, act 4, lowact 0
bwi0: 3th led, act 0, lowact 0
bwi0: 802.11 MAC was already disabled
bwi0: PHY is linked
bwi0: PHY: type 2, rev 1, ver 1
bwi0: PHY: 802.11G attach
bwi0: RF: manu 0x17f, type 0x2050, rev 2
bwi0: bus rev 0
bwi0: PHY is linked
bwi0: 30bit bus space
bwi0: max txpower from sprom: 57 dBm
bwi0: invalid antenna gain in sprom
bwi0: ant gain 8 dBm
bwi0: region/domain max txpower 76 dBm
bwi0: max txpower 57 dBm
bwi0: sprom idle tssi: 0x003e
bwi0: TSSI-TX power map:
71 71 70 70 70 70 70 69
69 69 69 69 68 68 68 67
67 67 66 66 66 66 65 65
65 64 64 64 63 63 63 62
61 61 61 60 59 59 58 57
57 55 55 54 53 52 51 50
49 48 47 44 43 42 39 37
35 32 29 26 22 18 14 8
bwi0: idle tssi0: 62
bwi0: bus rev 0
bwi0: locale: 6
bwi0: WARNING: using obsoleted if_watchdog interface
bwi0: Ethernet address: 00:90:4b:61:02:45
cbb0: <O2Micro OZ6912/6972 PCI-CardBus Bridge> irq 11 at device 10.0 on pci0
cardbus0: <CardBus bus> on cbb0
pccard0: <16-bit PCCard bus> on cbb0
cbb0: [ITHREAD]
fwohci0: <Texas Instruments TSB43AB21/A/AI/A-EP> mem
0xd0009000-0xd00097ff,0xd0000000-0xd0003fff irq 10 at device 12.0 on
pci0
fwohci0: [FILTER]
fwohci0: OHCI version 1.10 (ROM=1)
fwohci0: No. of Isochronous channels is 4.
fwohci0: EUI64 00:0d:9d:71:9e:43:0c:6a
fwohci0: Phy 1394a available S400, 1 ports.
fwohci0: Link S400, max_rec 2048 bytes.
firewire0: <IEEE1394(FireWire) bus> on fwohci0
fwe0: <Ethernet over FireWire> on firewire0
if_fwe0: Fake Ethernet address: 02:0d:9d:43:0c:6a
fwe0: Ethernet address: 02:0d:9d:43:0c:6a
fwip0: <IP over FireWire> on firewire0
fwip0: Firewire address: 00:0d:9d:71:9e:43:0c:6a @ 0xfffe00000000,
S400, maxrec 2048
sbp0: <SBP-2/SCSI over FireWire> on firewire0
dcons_crom0: <dcons configuration ROM> on firewire0
dcons_crom0: bus_addr 0x12bc000
fwohci0: Initiate bus reset
fwohci0: BUS reset
fwohci0: node_id=0xc000ffc0, gen=1, CYCLEMASTER mode
atapci0: <AcerLabs M5229 UDMA100 controller> port
0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x8080-0x808f at device 16.0 on
pci0
atapci0: using PIO transfers above 137GB as workaround for 48bit DMA
access bug, expect reduced performance
ata0: <ATA channel 0> on atapci0
ata0: [ITHREAD]
ata1: <ATA channel 1> on atapci0
ata1: [ITHREAD]
pci0: <bridge> at device 17.0 (no driver attached)
sis0: <NatSemi DP8381[56] 10/100BaseTX> port 0x8c00-0x8cff mem
0xd000a000-0xd000afff irq 11 at device 18.0 on pci0
sis0: Silicon Revision: DP83816A
miibus0: <MII bus> on sis0
nsphyter0: <DP83815 10/100 media interface> PHY 0 on miibus0
nsphyter0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
sis0: Ethernet address: 00:0d:9d:43:2b:a7
sis0: [ITHREAD]
acpi_button0: <Power Button> on acpi0
acpi_lid0: <Control Method Lid Switch> on acpi0
acpi_acad0: <AC Adapter> on acpi0
battery0: <ACPI Control Method Battery> on acpi0
acpi_tz0: <Thermal Zone> on acpi0
atkbdc0: <Keyboard controller (i8042)> port 0x60,0x64 irq 1 on acpi0
atkbd0: <AT Keyboard> irq 1 on atkbdc0
kbd0 at atkbd0
atkbd0: [GIANT-LOCKED]
atkbd0: [ITHREAD]
psm0: <PS/2 Mouse> irq 12 on atkbdc0
psm0: [GIANT-LOCKED]
psm0: [ITHREAD]
psm0: model IntelliMouse, device ID 3
fdc0: <floppy drive controller> port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0
fdc0: [FILTER]
sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0
sio0: type 16550A
sio0: [FILTER]
cpu0: <ACPI CPU> on acpi0
powernow0: <PowerNow! K7> on cpu0
pmtimer0 on isa0
orm0: <ISA Option ROMs> at iomem
0xc0000-0xcefff,0xcf000-0xcf7ff,0xdb000-0xdbfff,0xdc000-0xdffff pnpid
ORM0000 on isa0
ppc0: <Parallel port> at port 0x378-0x37f irq 7 on isa0
ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode
ppc0: FIFO with 16/16/16 bytes threshold
ppbus0: <Parallel port bus> on ppc0
ppbus0: [ITHREAD]
ppi0: <Parallel I/O> on ppbus0
plip0: <PLIP network interface> on ppbus0
plip0: WARNING: using obsoleted IFF_NEEDSGIANT flag
lpt0: <Printer> on ppbus0
lpt0: Interrupt-driven port
ppc0: [GIANT-LOCKED]
ppc0: [ITHREAD]
sc0: <System console> at flags 0x100 on isa0
sc0: VGA <16 virtual consoles, flags=0x300>
sio1: configured irq 3 not in bitmap of probed irqs 0
sio1: port may not be enabled
vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0
ums0: <Logitech USB Receiver, class 0/0, rev 1.10/25.00, addr 2> on uhub0
ums0: 16 buttons and Z dir.
Timecounter "TSC" frequency 1788943467 Hz quality 800
Timecounters tick every 1.000 msec
firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me)
firewire0: bus manager 0 (me)
ad0: 95396MB <Seagate ST9100823A 3.02> at ata0-master UDMA100
acd0: CDRW <QSI CD-RW/DVD-ROM SBW-241/VH04> at ata1-master UDMA33
Trying to mount root from ufs:/dev/ad0s2a
bwi0: bwi_init
bwi0: bwi_stop
bwi0: bbp atten: 0, rf atten: 3, ctrl1: 2, ctrl2: 65535
bwi0: bus rev 0
bwi0: 802.11 MAC is disabled
bwi0: 802.11 MAC was already disabled
bwi0: PHY is linked
bwi0: bus rev 0
bwi0: PHY is unlinked
bwi0: RF calibration value: 0x002a
bwi0: bus rev 0
bwi0: PHY is linked
firmware_get: failed to load firmware image bwi_v3_ucode4
bwi0: request firmware bwi_v3_ucode4 failed
bwi0: bwi_stop




-- 
www.nealhogan.net
From l1nyx01d at googlemail.com  Mon Jan 12 10:28:06 2009
From: l1nyx01d at googlemail.com (L1NYX01D@GOOGLEMAIL.COM)
Date: Mon Jan 12 10:28:13 2009
Subject: FreeBSD 7.0 kernel panic
Message-ID: <54540134.20090112212757@gmail.com>

Hello, FreeBSD-stable.

Last week I have a lot of kernel panics like:

> [root@router1 /usr/obj/usr/src/sys/TINCOKERNEL2]# kgdb kernel.debug /var/crash/vmcore.20
> [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
> cpuid = 0; apic id = 00
> fault virtual address   = 0x9
> fault code              = supervisor read, page not present
> instruction pointer     = 0x20:0xc079f1af
> stack pointer           = 0x28:0xe5697c80
> frame pointer           = 0x28:0xe5697cbc
> code segment            = base 0x0, limit 0xfffff, type 0x1b
>                         = DPL 0, pres 1, def32 1, gran 1
> processor eflags        = resume, IOPL = 0
> current process         = 14 (swi4: clock)
> trap number             = 12
> panic: page fault
> cpuid = 0
> Uptime: 51m49s
> Physical memory: 2032 MB
> Dumping 177 MB: 162 146 130 114 98 82 66 50 34 18 2
>
> #0  doadump () at pcpu.h:195
> 195             __asm __volatile("movl %%fs:0,%0" : "=r" (td));
> (kgdb) bt
> #0  doadump () at pcpu.h:195
> #1  0xc078d1b7 in boot (howto=260) at
> /usr/src/sys/kern/kern_shutdown.c:409
> #2  0xc078d479 in panic (fmt=Variable "fmt" is not available.
> ) at /usr/src/sys/kern/kern_shutdown.c:563
> #3  0xc0a0eaac in trap_fatal (frame=0xe5697c40, eva=9) at /usr/src/sys/i386/i386/trap.c:899
> #4  0xc0a0f42f in trap (frame=0xe5697c40) at /usr/src/sys/i386/i386/trap.c:280
> #5  0xc09f565b in calltrap () at
> /usr/src/sys/i386/i386/exception.s:139
> #6  0xc079f1af in softclock (dummy=0x0) at
> /usr/src/sys/kern/kern_timeout.c:202
> #7  0xc076f31b in ithread_loop (arg=0xc5101250) at
> /usr/src/sys/kern/kern_intr.c:1036
> #8  0xc076c119 in fork_exit (callout=0xc076f170 <ithread_loop>, arg=0xc5101250, frame=0xe5697d38)
>     at /usr/src/sys/kern/kern_fork.c:781
> #9  0xc09f56d0 in fork_trampoline () at
> /usr/src/sys/i386/i386/exception.s:205
> (kgdb)

What I should do?

-- 
? ?????????,
 L1NYX01D                          mailto:l1nyx01d@googlemail.com

From onemda at gmail.com  Mon Jan 12 10:32:57 2009
From: onemda at gmail.com (Paul B. Mahol)
Date: Mon Jan 12 10:33:11 2009
Subject: bwi: no DS tssi no OFDM tssi
In-Reply-To: <ab7b49bc0901120941x524fe841tbd526387f3af234b@mail.gmail.com>
References: <ab7b49bc0901120941x524fe841tbd526387f3af234b@mail.gmail.com>
Message-ID: <3a142e750901121032x79da7932se74c5511ec4a837b@mail.gmail.com>

On 1/12/09, Neal Hogan <nealhogan@gmail.com> wrote:
> Hello,
>
>    I am attempting to get by broadcom wifi card up and running, am sick of
> trying to get ndis working, and am attempting to use the bwi driver
> (originating in dragonflyBSD). I'm hoping others here have tried to do the
> same and have some pointers. I'm using 7.1-RELEASE (system/source are
> in-sync) and my card is a BCM94306MP. My dmesg is posted below.
>
> Bwi(4) is installed and it recognizes my card (*if_bwi_load-"YES"* is in my
> /etc/rc.conf and *bwi_v3* and *if_bwi* are loaded). I can send a IP request
> to my WEP encrypted access point. Yet, it doesn't get an offer and says that
> *no DS tssi* and *no OFDM tssi* Being new to bwi(4) and have never seen
> references to DS/OFDM tssi, I'm not sure what info to provide. My research
> is not leading anywhere helpful.  Thanks.
>
>
>
>
> Copyright (c) 1992-2009 The FreeBSD Project.
> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
> 	The Regents of the University of California. All rights reserved.
> FreeBSD is a registered trademark of The FreeBSD Foundation.
> FreeBSD 7.1-RELEASE #0: Sat Jan 10 19:07:15 CST 2009
>     nph@frege.lambdaserver:/usr/obj/usr/src/sys/GENERIC
> Timecounter "i8254" frequency 1193182 Hz quality 0
> CPU: mobile AMD Athlon(tm) XP2400+ (1788.94-MHz 686-class CPU)
>   Origin = "AuthenticAMD"  Id = 0x6a0  Stepping = 0
>
> Features=0x383f9ff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE>
>   AMD Features=0xc0480800<SYSCALL,MP,MMX+,3DNow!+,3DNow!>
> real memory  = 468647936 (446 MB)
> avail memory = 444530688 (423 MB)
> kbd1 at kbdmux0
> ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413)
> acpi0: <PTLTD   RSDT> on motherboard
> acpi0: [ITHREAD]
> acpi0: Power Button (fixed)
> Timecounter "ACPI-safe" frequency 3579545 Hz quality 850
> acpi_timer0: <32-bit timer at 3.579545MHz> port 0x8008-0x800b on acpi0
> acpi_ec0: <Embedded Controller: GPE 0x18> port 0x62,0x66 on acpi0
> pcib0: <ACPI Host-PCI bridge> port 0xcf8-0xcff on acpi0
> pci_link5: BIOS IRQ 10 for 0.10.INTA is invalid
> pci0: <ACPI PCI bus> on pcib0
> agp0: <ATI RS100 AGP bridge> on hostb0
> pcib1: <ACPI PCI-PCI bridge> at device 1.0 on pci0
> pci1: <ACPI PCI bus> on pcib1
> vgapci0: <VGA-compatible display> port 0x9000-0x90ff mem
> 0xe0000000-0xefffffff,0xd0100000-0xd010ffff irq 10 at device 5.0 on
> pci1
> ohci0: <AcerLabs M5237 (Aladdin-V) USB controller> mem
> 0xd0006000-0xd0006fff irq 9 at device 2.0 on pci0
> ohci0: [GIANT-LOCKED]
> ohci0: [ITHREAD]
> usb0: OHCI version 1.0, legacy support
> usb0: SMM does not respond, resetting
> usb0: <AcerLabs M5237 (Aladdin-V) USB controller> on ohci0
> usb0: USB revision 1.0
> uhub0: <AcerLabs OHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb0
> uhub0: 4 ports with 4 removable, self powered
> pcm0: <Acer Labs M5451> port 0x8400-0x84ff mem 0xd0007000-0xd0007fff
> irq 5 at device 6.0 on pci0
> pcm0: <Conexant CX20468 AC97 Codec>
> pcm0: [GIANT-LOCKED]
> pcm0: [ITHREAD]
> isab0: <PCI-ISA bridge> at device 7.0 on pci0
> isa0: <ISA bus> on isab0
> pci0: <simple comms, generic modem> at device 8.0 (no driver attached)
> bwi0: <Broadcom BCM4306v1 802.11 Wireless Lan> mem
> 0xd0004000-0xd0005fff irq 9 at device 9.0 on pci0
> bwi0: [ITHREAD]
> bwi0: regwin: chipcommon (0x800), rev 2, vendor 0x4243
> bwi0: BBP: id 0x4306, rev 0x2, pkg 0
> bwi0: nregwin 6, cap 0x0000002a
> bwi0: regwin: 802.11 MAC (0x812), rev 4, vendor 0x4243
> bwi0: has TX stats
> bwi0: MAC: rev 4
> bwi0: regwin: pcmcia (0x80d), rev 1, vendor 0x4243
> bwi0: regwin: v90 codec (0x807), rev 1, vendor 0x4243
> bwi0: regwin: pci (0x804), rev 7, vendor 0x4243
> bwi0: regwin: 802.11 MAC (0x812), rev 4, vendor 0x4243
> bwi0: ignore second MAC
> bwi0: bus rev 0
> bwi0: pci is enabled
> bwi0: card flags 0x000f
> bwi0: 0th led, act 3, lowact 0
> bwi0: 1th led, act 5, lowact 0
> bwi0: 2th led, act 4, lowact 0
> bwi0: 3th led, act 0, lowact 0
> bwi0: 802.11 MAC was already disabled
> bwi0: PHY is linked
> bwi0: PHY: type 2, rev 1, ver 1
> bwi0: PHY: 802.11G attach
> bwi0: RF: manu 0x17f, type 0x2050, rev 2
> bwi0: bus rev 0
> bwi0: PHY is linked
> bwi0: 30bit bus space
> bwi0: max txpower from sprom: 57 dBm
> bwi0: invalid antenna gain in sprom
> bwi0: ant gain 8 dBm
> bwi0: region/domain max txpower 76 dBm
> bwi0: max txpower 57 dBm
> bwi0: sprom idle tssi: 0x003e
> bwi0: TSSI-TX power map:
> 71 71 70 70 70 70 70 69
> 69 69 69 69 68 68 68 67
> 67 67 66 66 66 66 65 65
> 65 64 64 64 63 63 63 62
> 61 61 61 60 59 59 58 57
> 57 55 55 54 53 52 51 50
> 49 48 47 44 43 42 39 37
> 35 32 29 26 22 18 14 8
> bwi0: idle tssi0: 62
> bwi0: bus rev 0
> bwi0: locale: 6
> bwi0: WARNING: using obsoleted if_watchdog interface
> bwi0: Ethernet address: 00:90:4b:61:02:45
> cbb0: <O2Micro OZ6912/6972 PCI-CardBus Bridge> irq 11 at device 10.0 on pci0
> cardbus0: <CardBus bus> on cbb0
> pccard0: <16-bit PCCard bus> on cbb0
> cbb0: [ITHREAD]
> fwohci0: <Texas Instruments TSB43AB21/A/AI/A-EP> mem
> 0xd0009000-0xd00097ff,0xd0000000-0xd0003fff irq 10 at device 12.0 on
> pci0
> fwohci0: [FILTER]
> fwohci0: OHCI version 1.10 (ROM=1)
> fwohci0: No. of Isochronous channels is 4.
> fwohci0: EUI64 00:0d:9d:71:9e:43:0c:6a
> fwohci0: Phy 1394a available S400, 1 ports.
> fwohci0: Link S400, max_rec 2048 bytes.
> firewire0: <IEEE1394(FireWire) bus> on fwohci0
> fwe0: <Ethernet over FireWire> on firewire0
> if_fwe0: Fake Ethernet address: 02:0d:9d:43:0c:6a
> fwe0: Ethernet address: 02:0d:9d:43:0c:6a
> fwip0: <IP over FireWire> on firewire0
> fwip0: Firewire address: 00:0d:9d:71:9e:43:0c:6a @ 0xfffe00000000,
> S400, maxrec 2048
> sbp0: <SBP-2/SCSI over FireWire> on firewire0
> dcons_crom0: <dcons configuration ROM> on firewire0
> dcons_crom0: bus_addr 0x12bc000
> fwohci0: Initiate bus reset
> fwohci0: BUS reset
> fwohci0: node_id=0xc000ffc0, gen=1, CYCLEMASTER mode
> atapci0: <AcerLabs M5229 UDMA100 controller> port
> 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x8080-0x808f at device 16.0 on
> pci0
> atapci0: using PIO transfers above 137GB as workaround for 48bit DMA
> access bug, expect reduced performance
> ata0: <ATA channel 0> on atapci0
> ata0: [ITHREAD]
> ata1: <ATA channel 1> on atapci0
> ata1: [ITHREAD]
> pci0: <bridge> at device 17.0 (no driver attached)
> sis0: <NatSemi DP8381[56] 10/100BaseTX> port 0x8c00-0x8cff mem
> 0xd000a000-0xd000afff irq 11 at device 18.0 on pci0
> sis0: Silicon Revision: DP83816A
> miibus0: <MII bus> on sis0
> nsphyter0: <DP83815 10/100 media interface> PHY 0 on miibus0
> nsphyter0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
> sis0: Ethernet address: 00:0d:9d:43:2b:a7
> sis0: [ITHREAD]
> acpi_button0: <Power Button> on acpi0
> acpi_lid0: <Control Method Lid Switch> on acpi0
> acpi_acad0: <AC Adapter> on acpi0
> battery0: <ACPI Control Method Battery> on acpi0
> acpi_tz0: <Thermal Zone> on acpi0
> atkbdc0: <Keyboard controller (i8042)> port 0x60,0x64 irq 1 on acpi0
> atkbd0: <AT Keyboard> irq 1 on atkbdc0
> kbd0 at atkbd0
> atkbd0: [GIANT-LOCKED]
> atkbd0: [ITHREAD]
> psm0: <PS/2 Mouse> irq 12 on atkbdc0
> psm0: [GIANT-LOCKED]
> psm0: [ITHREAD]
> psm0: model IntelliMouse, device ID 3
> fdc0: <floppy drive controller> port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0
> fdc0: [FILTER]
> sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on
> acpi0
> sio0: type 16550A
> sio0: [FILTER]
> cpu0: <ACPI CPU> on acpi0
> powernow0: <PowerNow! K7> on cpu0
> pmtimer0 on isa0
> orm0: <ISA Option ROMs> at iomem
> 0xc0000-0xcefff,0xcf000-0xcf7ff,0xdb000-0xdbfff,0xdc000-0xdffff pnpid
> ORM0000 on isa0
> ppc0: <Parallel port> at port 0x378-0x37f irq 7 on isa0
> ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode
> ppc0: FIFO with 16/16/16 bytes threshold
> ppbus0: <Parallel port bus> on ppc0
> ppbus0: [ITHREAD]
> ppi0: <Parallel I/O> on ppbus0
> plip0: <PLIP network interface> on ppbus0
> plip0: WARNING: using obsoleted IFF_NEEDSGIANT flag
> lpt0: <Printer> on ppbus0
> lpt0: Interrupt-driven port
> ppc0: [GIANT-LOCKED]
> ppc0: [ITHREAD]
> sc0: <System console> at flags 0x100 on isa0
> sc0: VGA <16 virtual consoles, flags=0x300>
> sio1: configured irq 3 not in bitmap of probed irqs 0
> sio1: port may not be enabled
> vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0
> ums0: <Logitech USB Receiver, class 0/0, rev 1.10/25.00, addr 2> on uhub0
> ums0: 16 buttons and Z dir.
> Timecounter "TSC" frequency 1788943467 Hz quality 800
> Timecounters tick every 1.000 msec
> firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me)
> firewire0: bus manager 0 (me)
> ad0: 95396MB <Seagate ST9100823A 3.02> at ata0-master UDMA100
> acd0: CDRW <QSI CD-RW/DVD-ROM SBW-241/VH04> at ata1-master UDMA33
> Trying to mount root from ufs:/dev/ad0s2a
> bwi0: bwi_init
> bwi0: bwi_stop
> bwi0: bbp atten: 0, rf atten: 3, ctrl1: 2, ctrl2: 65535
> bwi0: bus rev 0
> bwi0: 802.11 MAC is disabled
> bwi0: 802.11 MAC was already disabled
> bwi0: PHY is linked
> bwi0: bus rev 0
> bwi0: PHY is unlinked
> bwi0: RF calibration value: 0x002a
> bwi0: bus rev 0
> bwi0: PHY is linked
> firmware_get: failed to load firmware image bwi_v3_ucode4
> bwi0: request firmware bwi_v3_ucode4 failed

Looks like it either doesnt have such firmware loaded or firmware
is not supported for your card. bwi works only with firmware version 3
and not with 4.
To get right answer look in current openbsd and dragonfly bwi driver if
your BCM94306MP is listed.

-- 
Paul
From wojtek at wojtek.tensor.gdynia.pl  Mon Jan 12 10:36:23 2009
From: wojtek at wojtek.tensor.gdynia.pl (Wojciech Puchar)
Date: Mon Jan 12 10:36:35 2009
Subject: bwi: no DS tssi no OFDM tssi
In-Reply-To: <ab7b49bc0901120941x524fe841tbd526387f3af234b@mail.gmail.com>
References: <ab7b49bc0901120941x524fe841tbd526387f3af234b@mail.gmail.com>
Message-ID: <20090112193549.T34373@wojtek.tensor.gdynia.pl>

> firmware_get: failed to load firmware image bwi_v3_ucode4
> bwi0: request firmware bwi_v3_ucode4 failed
> bwi0: bwi_stop

looks like here  is a problem
From drosih at rpi.edu  Mon Jan 12 10:55:49 2009
From: drosih at rpi.edu (Garance A Drosihn)
Date: Mon Jan 12 10:55:56 2009
Subject: Big problems with 7.1 locking up :-(
In-Reply-To: <alpine.BSF.2.00.0901121453200.16794@fledge.watson.org>
References: <E1LL6dg-0007CN-DI@dilbert.ticketswitch.com>
	<042FE04A-2F8D-47DD-8454-7BBA3791D7A8@inoc.net>
	<p06240802c58db5953598@[128.113.24.47]>
	<alpine.BSF.2.00.0901121453200.16794@fledge.watson.org>
Message-ID: <p06240808c5911644dd11@[128.113.24.47]>

At 2:55 PM +0000 1/12/09, Robert Watson wrote:
>On Fri, 9 Jan 2009, Garance A Drosihn wrote:
>
>>At 2:39 PM -0500 1/9/09, Robert Blayzor wrote:
>>>On Jan 8, 2009, at 8:58 PM, Pete French wrote:
>>>>I have a number of HP 1U servers, all of which were running 7.0 
>>>>perfectly happily. I have been testing 7.1 in it's various 
>>>>incarnations for the last couple of months on our test server and 
>>>>it has performed perfectly.
>>>
>>>I noticed a problem with 7.0 on a couple of Dell servers.  [...] 
>>>We've since then compiled the kernel under the BSD scheduler to 
>>>rule that out, and so far so good.
>>>
>>>Since ULE is now default in 7.1 and not in 7.0, perhaps you can try that?
>>
>>FWIW, the other guy I know who is having this problem had already 
>>switched to using ULE under 7.0-release, and did not have any 
>>problems with it.  So *his* problem was probably not related to 
>>SCHED_ULE, unless something has recently changed there.
>>
>>Turns out he hasn't reverted back to 7.0-release just yet, so he's 
>>going to try SCHED_4BSD and see if that helps his situation.
>
>Scheduler changes always come with some risk of exposing bugs that 
>have existed in the code for a long time but never really manifested 
>themselves. ULE is well shaken-out, having been under development 
>for at least five years, but it is possible that some problems will 
>become visible as a result of the switch.  I would encourage people 
>to stick with ULE, but if you're having a stability problem then 
>experimenting with scheduler as a variable that could be triggering 
>the problem may well be useful to help track down the bug.

Just to followup on this:  My friend did switch back to a 7.1 kernel with
SCHED_4BSD, and he still ran into problems.  The error messages weren't
the same, but errors did happen in the same high disk-I/O situations as
the lockup happened with SCHED_ULE.  At this point he's fallen back to
the 7.0-kernel that he had been running (which also has SCHED_ULE), and
all the problems have gone away.  So at the moment he's running with a
7.0-ish kernel and the 7.1-release userland, without the hanging problems.
So the problem is something in the kernel, but it is *NOT* the scheduler
(at least, not in his case).

He is not eager to do a whole lot of experiments to track down the
problem, since this is happening on busy production machines and he
can't afford to have a lot of downtime on them (especially now that the
semester at RPI has started up).  The systems have some large (2 TB)
filesystems on them, and the lockups occur in high disk-I/O situations.
He's seeing the problem on one system which is a dual CPU quad-core
xeon, and another which is a 64 bit P4 with hyperthreading.  The one
thing in common between the two setups is that the boot drives + a
3ware controller (with its array of RAID disks) is moved from one
machine to the other one:

   "its a 3ware 9500 12 port model, the boot drive is connected to
    an ICH6 in IDE mode, and yes, I've run it in single, single with
    hyper threading, and 8 way mode.  All 64 bit."

We still have no idea where the problem really is.  For all we know,
someone spilled a Pepsi on it when he wasn't looking...

-- 
Garance Alistair Drosehn            =   gad@gilead.netel.rpi.edu
Senior Systems Programmer           or  gad@freebsd.org
Rensselaer Polytechnic Institute    or  drosih@rpi.edu
From petefrench at ticketswitch.com  Mon Jan 12 11:00:26 2009
From: petefrench at ticketswitch.com (Pete French)
Date: Mon Jan 12 11:00:33 2009
Subject: Big problems with 7.1 locking up :-(
Message-ID: <E1LMS1C-0002x6-Je@dilbert.ticketswitch.com>

> I'm not sure if you've done this already, but the normal suggestions apply: 
> have you compiled with INVARIANTS/WITNESS/DDB/KDB/BREAK_TO_DEBUGGER, and do 
> any results / panics / etc result?  Sometimes these debugging tools are able 
> to convert hangs into panics, which gives us much more ability to debug them. 

OK, I have now had a machine hand again, with the correct debug options in
the kernel. The screen looked like this when I went to restart it:

	http://toybox.twisted.org.uk/~pete/71_lor2.png

It had not, however, dropped into any kind of debugger. Also there appear
to me console messages after the lock order reversal - is that normal ?

The machine did stay up for a signifanct amount of time before doing this. I
notice that it is more or less identical to the one I posted whenI
had WITNESS_KDB in the kernel too, so maybe those results arent
entirely suprious after all ?

Given it hasnt dropped to a debugger, is there anything else I can try ? 

-pete.
From petefrench at ticketswitch.com  Mon Jan 12 11:01:43 2009
From: petefrench at ticketswitch.com (Pete French)
Date: Mon Jan 12 11:01:50 2009
Subject: Big problems with 7.1 locking up :-(
In-Reply-To: <p06240808c5911644dd11@[128.113.24.47]>
Message-ID: <E1LMS2e-00035C-BD@dilbert.ticketswitch.com>

> Just to followup on this:  My friend did switch back to a 7.1 kernel with
> SCHED_4BSD, and he still ran into problems.  The error messages weren't

Acually, I dont know if I posted it, but that was the same for me too.
The scheduler makes no difference, nor do CPU copile settings.

-pete.
From nealhogan at gmail.com  Mon Jan 12 12:08:33 2009
From: nealhogan at gmail.com (Neal Hogan)
Date: Mon Jan 12 12:08:41 2009
Subject: bwi: no DS tssi no OFDM tssi
In-Reply-To: <3a142e750901121032x79da7932se74c5511ec4a837b@mail.gmail.com>
References: <ab7b49bc0901120941x524fe841tbd526387f3af234b@mail.gmail.com>
	<3a142e750901121032x79da7932se74c5511ec4a837b@mail.gmail.com>
Message-ID: <ab7b49bc0901121208j30fc153crd8f80fa7ed037fa7@mail.gmail.com>

I installed the firmware stuff from the dragonfly bwi(4) man page, yet I
have the same issue. Is there a way to tell whether the firmware they
provide supports my card? Like I said, I can locate my access point (and
others that are around) and ask for an IP . . . it seems as though I'm so
close. I'm fairly certain that I have all of the avliable bwi(4) bits
installed correctly.

I dwonloaded and installed the driver and added *if_bwi_load="YES"* in my
loader.conf. I loaded the .ko file (bwi_v3). I downloaded and installed the
firmware from dflyBSD and followed their directions. Yet I get no offer. Is
the fact that I fail to get an offer indicate the firmware incompatinbility?

Anyway, thanks for you help.

On Mon, Jan 12, 2009 at 12:32 PM, Paul B. Mahol <onemda@gmail.com> wrote:

> On 1/12/09, Neal Hogan <nealhogan@gmail.com> wrote:
> > Hello,
> >
> >    I am attempting to get by broadcom wifi card up and running, am sick
> of
> > trying to get ndis working, and am attempting to use the bwi driver
> > (originating in dragonflyBSD). I'm hoping others here have tried to do
> the
> > same and have some pointers. I'm using 7.1-RELEASE (system/source are
> > in-sync) and my card is a BCM94306MP. My dmesg is posted below.
> >
> > Bwi(4) is installed and it recognizes my card (*if_bwi_load-"YES"* is in
> my
> > /etc/rc.conf and *bwi_v3* and *if_bwi* are loaded). I can send a IP
> request
> > to my WEP encrypted access point. Yet, it doesn't get an offer and says
> that
> > *no DS tssi* and *no OFDM tssi* Being new to bwi(4) and have never seen
> > references to DS/OFDM tssi, I'm not sure what info to provide. My
> research
> > is not leading anywhere helpful.  Thanks.
> >
> >
> >
> >
> > Copyright (c) 1992-2009 The FreeBSD Project.
> > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
> >       The Regents of the University of California. All rights reserved.
> > FreeBSD is a registered trademark of The FreeBSD Foundation.
> > FreeBSD 7.1-RELEASE #0: Sat Jan 10 19:07:15 CST 2009
> >     nph@frege.lambdaserver:/usr/obj/usr/src/sys/GENERIC
> > Timecounter "i8254" frequency 1193182 Hz quality 0
> > CPU: mobile AMD Athlon(tm) XP2400+ (1788.94-MHz 686-class CPU)
> >   Origin = "AuthenticAMD"  Id = 0x6a0  Stepping = 0
> >
> >
> Features=0x383f9ff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE>
> >   AMD Features=0xc0480800<SYSCALL,MP,MMX+,3DNow!+,3DNow!>
> > real memory  = 468647936 (446 MB)
> > avail memory = 444530688 (423 MB)
> > kbd1 at kbdmux0
> > ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413,
> RF5413)
> > acpi0: <PTLTD   RSDT> on motherboard
> > acpi0: [ITHREAD]
> > acpi0: Power Button (fixed)
> > Timecounter "ACPI-safe" frequency 3579545 Hz quality 850
> > acpi_timer0: <32-bit timer at 3.579545MHz> port 0x8008-0x800b on acpi0
> > acpi_ec0: <Embedded Controller: GPE 0x18> port 0x62,0x66 on acpi0
> > pcib0: <ACPI Host-PCI bridge> port 0xcf8-0xcff on acpi0
> > pci_link5: BIOS IRQ 10 for 0.10.INTA is invalid
> > pci0: <ACPI PCI bus> on pcib0
> > agp0: <ATI RS100 AGP bridge> on hostb0
> > pcib1: <ACPI PCI-PCI bridge> at device 1.0 on pci0
> > pci1: <ACPI PCI bus> on pcib1
> > vgapci0: <VGA-compatible display> port 0x9000-0x90ff mem
> > 0xe0000000-0xefffffff,0xd0100000-0xd010ffff irq 10 at device 5.0 on
> > pci1
> > ohci0: <AcerLabs M5237 (Aladdin-V) USB controller> mem
> > 0xd0006000-0xd0006fff irq 9 at device 2.0 on pci0
> > ohci0: [GIANT-LOCKED]
> > ohci0: [ITHREAD]
> > usb0: OHCI version 1.0, legacy support
> > usb0: SMM does not respond, resetting
> > usb0: <AcerLabs M5237 (Aladdin-V) USB controller> on ohci0
> > usb0: USB revision 1.0
> > uhub0: <AcerLabs OHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb0
> > uhub0: 4 ports with 4 removable, self powered
> > pcm0: <Acer Labs M5451> port 0x8400-0x84ff mem 0xd0007000-0xd0007fff
> > irq 5 at device 6.0 on pci0
> > pcm0: <Conexant CX20468 AC97 Codec>
> > pcm0: [GIANT-LOCKED]
> > pcm0: [ITHREAD]
> > isab0: <PCI-ISA bridge> at device 7.0 on pci0
> > isa0: <ISA bus> on isab0
> > pci0: <simple comms, generic modem> at device 8.0 (no driver attached)
> > bwi0: <Broadcom BCM4306v1 802.11 Wireless Lan> mem
> > 0xd0004000-0xd0005fff irq 9 at device 9.0 on pci0
> > bwi0: [ITHREAD]
> > bwi0: regwin: chipcommon (0x800), rev 2, vendor 0x4243
> > bwi0: BBP: id 0x4306, rev 0x2, pkg 0
> > bwi0: nregwin 6, cap 0x0000002a
> > bwi0: regwin: 802.11 MAC (0x812), rev 4, vendor 0x4243
> > bwi0: has TX stats
> > bwi0: MAC: rev 4
> > bwi0: regwin: pcmcia (0x80d), rev 1, vendor 0x4243
> > bwi0: regwin: v90 codec (0x807), rev 1, vendor 0x4243
> > bwi0: regwin: pci (0x804), rev 7, vendor 0x4243
> > bwi0: regwin: 802.11 MAC (0x812), rev 4, vendor 0x4243
> > bwi0: ignore second MAC
> > bwi0: bus rev 0
> > bwi0: pci is enabled
> > bwi0: card flags 0x000f
> > bwi0: 0th led, act 3, lowact 0
> > bwi0: 1th led, act 5, lowact 0
> > bwi0: 2th led, act 4, lowact 0
> > bwi0: 3th led, act 0, lowact 0
> > bwi0: 802.11 MAC was already disabled
> > bwi0: PHY is linked
> > bwi0: PHY: type 2, rev 1, ver 1
> > bwi0: PHY: 802.11G attach
> > bwi0: RF: manu 0x17f, type 0x2050, rev 2
> > bwi0: bus rev 0
> > bwi0: PHY is linked
> > bwi0: 30bit bus space
> > bwi0: max txpower from sprom: 57 dBm
> > bwi0: invalid antenna gain in sprom
> > bwi0: ant gain 8 dBm
> > bwi0: region/domain max txpower 76 dBm
> > bwi0: max txpower 57 dBm
> > bwi0: sprom idle tssi: 0x003e
> > bwi0: TSSI-TX power map:
> > 71 71 70 70 70 70 70 69
> > 69 69 69 69 68 68 68 67
> > 67 67 66 66 66 66 65 65
> > 65 64 64 64 63 63 63 62
> > 61 61 61 60 59 59 58 57
> > 57 55 55 54 53 52 51 50
> > 49 48 47 44 43 42 39 37
> > 35 32 29 26 22 18 14 8
> > bwi0: idle tssi0: 62
> > bwi0: bus rev 0
> > bwi0: locale: 6
> > bwi0: WARNING: using obsoleted if_watchdog interface
> > bwi0: Ethernet address: 00:90:4b:61:02:45
> > cbb0: <O2Micro OZ6912/6972 PCI-CardBus Bridge> irq 11 at device 10.0 on
> pci0
> > cardbus0: <CardBus bus> on cbb0
> > pccard0: <16-bit PCCard bus> on cbb0
> > cbb0: [ITHREAD]
> > fwohci0: <Texas Instruments TSB43AB21/A/AI/A-EP> mem
> > 0xd0009000-0xd00097ff,0xd0000000-0xd0003fff irq 10 at device 12.0 on
> > pci0
> > fwohci0: [FILTER]
> > fwohci0: OHCI version 1.10 (ROM=1)
> > fwohci0: No. of Isochronous channels is 4.
> > fwohci0: EUI64 00:0d:9d:71:9e:43:0c:6a
> > fwohci0: Phy 1394a available S400, 1 ports.
> > fwohci0: Link S400, max_rec 2048 bytes.
> > firewire0: <IEEE1394(FireWire) bus> on fwohci0
> > fwe0: <Ethernet over FireWire> on firewire0
> > if_fwe0: Fake Ethernet address: 02:0d:9d:43:0c:6a
> > fwe0: Ethernet address: 02:0d:9d:43:0c:6a
> > fwip0: <IP over FireWire> on firewire0
> > fwip0: Firewire address: 00:0d:9d:71:9e:43:0c:6a @ 0xfffe00000000,
> > S400, maxrec 2048
> > sbp0: <SBP-2/SCSI over FireWire> on firewire0
> > dcons_crom0: <dcons configuration ROM> on firewire0
> > dcons_crom0: bus_addr 0x12bc000
> > fwohci0: Initiate bus reset
> > fwohci0: BUS reset
> > fwohci0: node_id=0xc000ffc0, gen=1, CYCLEMASTER mode
> > atapci0: <AcerLabs M5229 UDMA100 controller> port
> > 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x8080-0x808f at device 16.0 on
> > pci0
> > atapci0: using PIO transfers above 137GB as workaround for 48bit DMA
> > access bug, expect reduced performance
> > ata0: <ATA channel 0> on atapci0
> > ata0: [ITHREAD]
> > ata1: <ATA channel 1> on atapci0
> > ata1: [ITHREAD]
> > pci0: <bridge> at device 17.0 (no driver attached)
> > sis0: <NatSemi DP8381[56] 10/100BaseTX> port 0x8c00-0x8cff mem
> > 0xd000a000-0xd000afff irq 11 at device 18.0 on pci0
> > sis0: Silicon Revision: DP83816A
> > miibus0: <MII bus> on sis0
> > nsphyter0: <DP83815 10/100 media interface> PHY 0 on miibus0
> > nsphyter0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
> > sis0: Ethernet address: 00:0d:9d:43:2b:a7
> > sis0: [ITHREAD]
> > acpi_button0: <Power Button> on acpi0
> > acpi_lid0: <Control Method Lid Switch> on acpi0
> > acpi_acad0: <AC Adapter> on acpi0
> > battery0: <ACPI Control Method Battery> on acpi0
> > acpi_tz0: <Thermal Zone> on acpi0
> > atkbdc0: <Keyboard controller (i8042)> port 0x60,0x64 irq 1 on acpi0
> > atkbd0: <AT Keyboard> irq 1 on atkbdc0
> > kbd0 at atkbd0
> > atkbd0: [GIANT-LOCKED]
> > atkbd0: [ITHREAD]
> > psm0: <PS/2 Mouse> irq 12 on atkbdc0
> > psm0: [GIANT-LOCKED]
> > psm0: [ITHREAD]
> > psm0: model IntelliMouse, device ID 3
> > fdc0: <floppy drive controller> port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on
> acpi0
> > fdc0: [FILTER]
> > sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on
> > acpi0
> > sio0: type 16550A
> > sio0: [FILTER]
> > cpu0: <ACPI CPU> on acpi0
> > powernow0: <PowerNow! K7> on cpu0
> > pmtimer0 on isa0
> > orm0: <ISA Option ROMs> at iomem
> > 0xc0000-0xcefff,0xcf000-0xcf7ff,0xdb000-0xdbfff,0xdc000-0xdffff pnpid
> > ORM0000 on isa0
> > ppc0: <Parallel port> at port 0x378-0x37f irq 7 on isa0
> > ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode
> > ppc0: FIFO with 16/16/16 bytes threshold
> > ppbus0: <Parallel port bus> on ppc0
> > ppbus0: [ITHREAD]
> > ppi0: <Parallel I/O> on ppbus0
> > plip0: <PLIP network interface> on ppbus0
> > plip0: WARNING: using obsoleted IFF_NEEDSGIANT flag
> > lpt0: <Printer> on ppbus0
> > lpt0: Interrupt-driven port
> > ppc0: [GIANT-LOCKED]
> > ppc0: [ITHREAD]
> > sc0: <System console> at flags 0x100 on isa0
> > sc0: VGA <16 virtual consoles, flags=0x300>
> > sio1: configured irq 3 not in bitmap of probed irqs 0
> > sio1: port may not be enabled
> > vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0
> > ums0: <Logitech USB Receiver, class 0/0, rev 1.10/25.00, addr 2> on uhub0
> > ums0: 16 buttons and Z dir.
> > Timecounter "TSC" frequency 1788943467 Hz quality 800
> > Timecounters tick every 1.000 msec
> > firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me)
> > firewire0: bus manager 0 (me)
> > ad0: 95396MB <Seagate ST9100823A 3.02> at ata0-master UDMA100
> > acd0: CDRW <QSI CD-RW/DVD-ROM SBW-241/VH04> at ata1-master UDMA33
> > Trying to mount root from ufs:/dev/ad0s2a
> > bwi0: bwi_init
> > bwi0: bwi_stop
> > bwi0: bbp atten: 0, rf atten: 3, ctrl1: 2, ctrl2: 65535
> > bwi0: bus rev 0
> > bwi0: 802.11 MAC is disabled
> > bwi0: 802.11 MAC was already disabled
> > bwi0: PHY is linked
> > bwi0: bus rev 0
> > bwi0: PHY is unlinked
> > bwi0: RF calibration value: 0x002a
> > bwi0: bus rev 0
> > bwi0: PHY is linked
> > firmware_get: failed to load firmware image bwi_v3_ucode4
> > bwi0: request firmware bwi_v3_ucode4 failed
>
> Looks like it either doesnt have such firmware loaded or firmware
> is not supported for your card. bwi works only with firmware version 3
> and not with 4.
> To get right answer look in current openbsd and dragonfly bwi driver if
> your BCM94306MP is listed.
>
> --
> Paul
>



-- 
www.nealhogan.net
From onemda at gmail.com  Mon Jan 12 12:34:40 2009
From: onemda at gmail.com (Paul B. Mahol)
Date: Mon Jan 12 12:34:48 2009
Subject: bwi: no DS tssi no OFDM tssi
In-Reply-To: <ab7b49bc0901121208j30fc153crd8f80fa7ed037fa7@mail.gmail.com>
References: <ab7b49bc0901120941x524fe841tbd526387f3af234b@mail.gmail.com>
	<3a142e750901121032x79da7932se74c5511ec4a837b@mail.gmail.com>
	<ab7b49bc0901121208j30fc153crd8f80fa7ed037fa7@mail.gmail.com>
Message-ID: <3a142e750901121234t45a4b15dg91df69f983e9efd6@mail.gmail.com>

On Mon, Jan 12, 2009 at 8:08 PM, Neal Hogan <nealhogan@gmail.com> wrote:
> I installed the firmware stuff from the dragonfly bwi(4) man page, yet I
> have the same issue. Is there a way to tell whether the firmware they
> provide supports my card? Like I said, I can locate my access point (and
> others that are around) and ask for an IP . . . it seems as though I'm so
> close. I'm fairly certain that I have all of the avliable bwi(4) bits
> installed correctly.
>
> I dwonloaded and installed the driver and added *if_bwi_load="YES"* in my
> loader.conf. I loaded the .ko file (bwi_v3). I downloaded and installed the
> firmware from dflyBSD and followed their directions. Yet I get no offer. Is
> the fact that I fail to get an offer indicate the firmware incompatinbility?

9 in BCM94306MP indicates that its supports 80211n and as such certainly
it is not supported with bwi(4) and reason is that bwi developers do not
plan to add support for 4 version firmware (when last time I played with bwi).

> Anyway, thanks for you help.
>
> On Mon, Jan 12, 2009 at 12:32 PM, Paul B. Mahol <onemda@gmail.com> wrote:
>>
>> On 1/12/09, Neal Hogan <nealhogan@gmail.com> wrote:
>> > Hello,
>> >
>> >    I am attempting to get by broadcom wifi card up and running, am sick
>> > of
>> > trying to get ndis working, and am attempting to use the bwi driver
>> > (originating in dragonflyBSD). I'm hoping others here have tried to do
>> > the
>> > same and have some pointers. I'm using 7.1-RELEASE (system/source are
>> > in-sync) and my card is a BCM94306MP. My dmesg is posted below.
>> >
>> > Bwi(4) is installed and it recognizes my card (*if_bwi_load-"YES"* is in
>> > my
>> > /etc/rc.conf and *bwi_v3* and *if_bwi* are loaded). I can send a IP
>> > request
>> > to my WEP encrypted access point. Yet, it doesn't get an offer and says
>> > that
>> > *no DS tssi* and *no OFDM tssi* Being new to bwi(4) and have never seen
>> > references to DS/OFDM tssi, I'm not sure what info to provide. My
>> > research
>> > is not leading anywhere helpful.  Thanks.
>> >
>> >
>> >
>> >
>> > Copyright (c) 1992-2009 The FreeBSD Project.
>> > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
>> >       The Regents of the University of California. All rights reserved.
>> > FreeBSD is a registered trademark of The FreeBSD Foundation.
>> > FreeBSD 7.1-RELEASE #0: Sat Jan 10 19:07:15 CST 2009
>> >     nph@frege.lambdaserver:/usr/obj/usr/src/sys/GENERIC
>> > Timecounter "i8254" frequency 1193182 Hz quality 0
>> > CPU: mobile AMD Athlon(tm) XP2400+ (1788.94-MHz 686-class CPU)
>> >   Origin = "AuthenticAMD"  Id = 0x6a0  Stepping = 0
>> >
>> >
>> > Features=0x383f9ff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE>
>> >   AMD Features=0xc0480800<SYSCALL,MP,MMX+,3DNow!+,3DNow!>
>> > real memory  = 468647936 (446 MB)
>> > avail memory = 444530688 (423 MB)
>> > kbd1 at kbdmux0
>> > ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413,
>> > RF5413)
>> > acpi0: <PTLTD   RSDT> on motherboard
>> > acpi0: [ITHREAD]
>> > acpi0: Power Button (fixed)
>> > Timecounter "ACPI-safe" frequency 3579545 Hz quality 850
>> > acpi_timer0: <32-bit timer at 3.579545MHz> port 0x8008-0x800b on acpi0
>> > acpi_ec0: <Embedded Controller: GPE 0x18> port 0x62,0x66 on acpi0
>> > pcib0: <ACPI Host-PCI bridge> port 0xcf8-0xcff on acpi0
>> > pci_link5: BIOS IRQ 10 for 0.10.INTA is invalid
>> > pci0: <ACPI PCI bus> on pcib0
>> > agp0: <ATI RS100 AGP bridge> on hostb0
>> > pcib1: <ACPI PCI-PCI bridge> at device 1.0 on pci0
>> > pci1: <ACPI PCI bus> on pcib1
>> > vgapci0: <VGA-compatible display> port 0x9000-0x90ff mem
>> > 0xe0000000-0xefffffff,0xd0100000-0xd010ffff irq 10 at device 5.0 on
>> > pci1
>> > ohci0: <AcerLabs M5237 (Aladdin-V) USB controller> mem
>> > 0xd0006000-0xd0006fff irq 9 at device 2.0 on pci0
>> > ohci0: [GIANT-LOCKED]
>> > ohci0: [ITHREAD]
>> > usb0: OHCI version 1.0, legacy support
>> > usb0: SMM does not respond, resetting
>> > usb0: <AcerLabs M5237 (Aladdin-V) USB controller> on ohci0
>> > usb0: USB revision 1.0
>> > uhub0: <AcerLabs OHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on
>> > usb0
>> > uhub0: 4 ports with 4 removable, self powered
>> > pcm0: <Acer Labs M5451> port 0x8400-0x84ff mem 0xd0007000-0xd0007fff
>> > irq 5 at device 6.0 on pci0
>> > pcm0: <Conexant CX20468 AC97 Codec>
>> > pcm0: [GIANT-LOCKED]
>> > pcm0: [ITHREAD]
>> > isab0: <PCI-ISA bridge> at device 7.0 on pci0
>> > isa0: <ISA bus> on isab0
>> > pci0: <simple comms, generic modem> at device 8.0 (no driver attached)
>> > bwi0: <Broadcom BCM4306v1 802.11 Wireless Lan> mem
>> > 0xd0004000-0xd0005fff irq 9 at device 9.0 on pci0
>> > bwi0: [ITHREAD]
>> > bwi0: regwin: chipcommon (0x800), rev 2, vendor 0x4243
>> > bwi0: BBP: id 0x4306, rev 0x2, pkg 0
>> > bwi0: nregwin 6, cap 0x0000002a
>> > bwi0: regwin: 802.11 MAC (0x812), rev 4, vendor 0x4243
>> > bwi0: has TX stats
>> > bwi0: MAC: rev 4
>> > bwi0: regwin: pcmcia (0x80d), rev 1, vendor 0x4243
>> > bwi0: regwin: v90 codec (0x807), rev 1, vendor 0x4243
>> > bwi0: regwin: pci (0x804), rev 7, vendor 0x4243
>> > bwi0: regwin: 802.11 MAC (0x812), rev 4, vendor 0x4243
>> > bwi0: ignore second MAC
>> > bwi0: bus rev 0
>> > bwi0: pci is enabled
>> > bwi0: card flags 0x000f
>> > bwi0: 0th led, act 3, lowact 0
>> > bwi0: 1th led, act 5, lowact 0
>> > bwi0: 2th led, act 4, lowact 0
>> > bwi0: 3th led, act 0, lowact 0
>> > bwi0: 802.11 MAC was already disabled
>> > bwi0: PHY is linked
>> > bwi0: PHY: type 2, rev 1, ver 1
>> > bwi0: PHY: 802.11G attach
>> > bwi0: RF: manu 0x17f, type 0x2050, rev 2
>> > bwi0: bus rev 0
>> > bwi0: PHY is linked
>> > bwi0: 30bit bus space
>> > bwi0: max txpower from sprom: 57 dBm
>> > bwi0: invalid antenna gain in sprom
>> > bwi0: ant gain 8 dBm
>> > bwi0: region/domain max txpower 76 dBm
>> > bwi0: max txpower 57 dBm
>> > bwi0: sprom idle tssi: 0x003e
>> > bwi0: TSSI-TX power map:
>> > 71 71 70 70 70 70 70 69
>> > 69 69 69 69 68 68 68 67
>> > 67 67 66 66 66 66 65 65
>> > 65 64 64 64 63 63 63 62
>> > 61 61 61 60 59 59 58 57
>> > 57 55 55 54 53 52 51 50
>> > 49 48 47 44 43 42 39 37
>> > 35 32 29 26 22 18 14 8
>> > bwi0: idle tssi0: 62
>> > bwi0: bus rev 0
>> > bwi0: locale: 6
>> > bwi0: WARNING: using obsoleted if_watchdog interface
>> > bwi0: Ethernet address: 00:90:4b:61:02:45
>> > cbb0: <O2Micro OZ6912/6972 PCI-CardBus Bridge> irq 11 at device 10.0 on
>> > pci0
>> > cardbus0: <CardBus bus> on cbb0
>> > pccard0: <16-bit PCCard bus> on cbb0
>> > cbb0: [ITHREAD]
>> > fwohci0: <Texas Instruments TSB43AB21/A/AI/A-EP> mem
>> > 0xd0009000-0xd00097ff,0xd0000000-0xd0003fff irq 10 at device 12.0 on
>> > pci0
>> > fwohci0: [FILTER]
>> > fwohci0: OHCI version 1.10 (ROM=1)
>> > fwohci0: No. of Isochronous channels is 4.
>> > fwohci0: EUI64 00:0d:9d:71:9e:43:0c:6a
>> > fwohci0: Phy 1394a available S400, 1 ports.
>> > fwohci0: Link S400, max_rec 2048 bytes.
>> > firewire0: <IEEE1394(FireWire) bus> on fwohci0
>> > fwe0: <Ethernet over FireWire> on firewire0
>> > if_fwe0: Fake Ethernet address: 02:0d:9d:43:0c:6a
>> > fwe0: Ethernet address: 02:0d:9d:43:0c:6a
>> > fwip0: <IP over FireWire> on firewire0
>> > fwip0: Firewire address: 00:0d:9d:71:9e:43:0c:6a @ 0xfffe00000000,
>> > S400, maxrec 2048
>> > sbp0: <SBP-2/SCSI over FireWire> on firewire0
>> > dcons_crom0: <dcons configuration ROM> on firewire0
>> > dcons_crom0: bus_addr 0x12bc000
>> > fwohci0: Initiate bus reset
>> > fwohci0: BUS reset
>> > fwohci0: node_id=0xc000ffc0, gen=1, CYCLEMASTER mode
>> > atapci0: <AcerLabs M5229 UDMA100 controller> port
>> > 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x8080-0x808f at device 16.0 on
>> > pci0
>> > atapci0: using PIO transfers above 137GB as workaround for 48bit DMA
>> > access bug, expect reduced performance
>> > ata0: <ATA channel 0> on atapci0
>> > ata0: [ITHREAD]
>> > ata1: <ATA channel 1> on atapci0
>> > ata1: [ITHREAD]
>> > pci0: <bridge> at device 17.0 (no driver attached)
>> > sis0: <NatSemi DP8381[56] 10/100BaseTX> port 0x8c00-0x8cff mem
>> > 0xd000a000-0xd000afff irq 11 at device 18.0 on pci0
>> > sis0: Silicon Revision: DP83816A
>> > miibus0: <MII bus> on sis0
>> > nsphyter0: <DP83815 10/100 media interface> PHY 0 on miibus0
>> > nsphyter0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
>> > sis0: Ethernet address: 00:0d:9d:43:2b:a7
>> > sis0: [ITHREAD]
>> > acpi_button0: <Power Button> on acpi0
>> > acpi_lid0: <Control Method Lid Switch> on acpi0
>> > acpi_acad0: <AC Adapter> on acpi0
>> > battery0: <ACPI Control Method Battery> on acpi0
>> > acpi_tz0: <Thermal Zone> on acpi0
>> > atkbdc0: <Keyboard controller (i8042)> port 0x60,0x64 irq 1 on acpi0
>> > atkbd0: <AT Keyboard> irq 1 on atkbdc0
>> > kbd0 at atkbd0
>> > atkbd0: [GIANT-LOCKED]
>> > atkbd0: [ITHREAD]
>> > psm0: <PS/2 Mouse> irq 12 on atkbdc0
>> > psm0: [GIANT-LOCKED]
>> > psm0: [ITHREAD]
>> > psm0: model IntelliMouse, device ID 3
>> > fdc0: <floppy drive controller> port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on
>> > acpi0
>> > fdc0: [FILTER]
>> > sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on
>> > acpi0
>> > sio0: type 16550A
>> > sio0: [FILTER]
>> > cpu0: <ACPI CPU> on acpi0
>> > powernow0: <PowerNow! K7> on cpu0
>> > pmtimer0 on isa0
>> > orm0: <ISA Option ROMs> at iomem
>> > 0xc0000-0xcefff,0xcf000-0xcf7ff,0xdb000-0xdbfff,0xdc000-0xdffff pnpid
>> > ORM0000 on isa0
>> > ppc0: <Parallel port> at port 0x378-0x37f irq 7 on isa0
>> > ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode
>> > ppc0: FIFO with 16/16/16 bytes threshold
>> > ppbus0: <Parallel port bus> on ppc0
>> > ppbus0: [ITHREAD]
>> > ppi0: <Parallel I/O> on ppbus0
>> > plip0: <PLIP network interface> on ppbus0
>> > plip0: WARNING: using obsoleted IFF_NEEDSGIANT flag
>> > lpt0: <Printer> on ppbus0
>> > lpt0: Interrupt-driven port
>> > ppc0: [GIANT-LOCKED]
>> > ppc0: [ITHREAD]
>> > sc0: <System console> at flags 0x100 on isa0
>> > sc0: VGA <16 virtual consoles, flags=0x300>
>> > sio1: configured irq 3 not in bitmap of probed irqs 0
>> > sio1: port may not be enabled
>> > vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on
>> > isa0
>> > ums0: <Logitech USB Receiver, class 0/0, rev 1.10/25.00, addr 2> on
>> > uhub0
>> > ums0: 16 buttons and Z dir.
>> > Timecounter "TSC" frequency 1788943467 Hz quality 800
>> > Timecounters tick every 1.000 msec
>> > firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me)
>> > firewire0: bus manager 0 (me)
>> > ad0: 95396MB <Seagate ST9100823A 3.02> at ata0-master UDMA100
>> > acd0: CDRW <QSI CD-RW/DVD-ROM SBW-241/VH04> at ata1-master UDMA33
>> > Trying to mount root from ufs:/dev/ad0s2a
>> > bwi0: bwi_init
>> > bwi0: bwi_stop
>> > bwi0: bbp atten: 0, rf atten: 3, ctrl1: 2, ctrl2: 65535
>> > bwi0: bus rev 0
>> > bwi0: 802.11 MAC is disabled
>> > bwi0: 802.11 MAC was already disabled
>> > bwi0: PHY is linked
>> > bwi0: bus rev 0
>> > bwi0: PHY is unlinked
>> > bwi0: RF calibration value: 0x002a
>> > bwi0: bus rev 0
>> > bwi0: PHY is linked
>> > firmware_get: failed to load firmware image bwi_v3_ucode4
>> > bwi0: request firmware bwi_v3_ucode4 failed
>>
>> Looks like it either doesnt have such firmware loaded or firmware
>> is not supported for your card. bwi works only with firmware version 3
>> and not with 4.
>> To get right answer look in current openbsd and dragonfly bwi driver if
>> your BCM94306MP is listed.
>>
>> --
>> Paul
>
>
>
> --
> www.nealhogan.net
>



-- 
Paul
From freebsd at max.af.czu.cz  Mon Jan 12 13:04:17 2009
From: freebsd at max.af.czu.cz (Tomas Randa)
Date: Mon Jan 12 13:04:24 2009
Subject: Big problems with 7.1 locking up :-(
In-Reply-To: <p06240808c5911644dd11@[128.113.24.47]>
References: <E1LL6dg-0007CN-DI@dilbert.ticketswitch.com>	<042FE04A-2F8D-47DD-8454-7BBA3791D7A8@inoc.net>	<p06240802c58db5953598@[128.113.24.47]>	<alpine.BSF.2.00.0901121453200.16794@fledge.watson.org>
	<p06240808c5911644dd11@[128.113.24.47]>
Message-ID: <496BA9AE.10801@max.af.czu.cz>

Hello,

I have similar problems. The last "good" kernel I have from stable 
brach, october the 8. Then in next upgrade, I saw big problems with 
performance.
I tried ULE, 4BSD etc, but nothing helps, only downgrading system back.

Now I am trying 7.1-p1 and problems are here again. Mysql is waiting a 
lot of time with status "waiting for opening table" or "waiting for 
close tables"

I have 32bit FreeBSD with PAE, 1x xeon 5420, supermicro motherboard, 
areca SATA controller. Could not be problem in "da" device for example?

Thanks Tomas Randa

Garance A Drosihn wrote:
> At 2:55 PM +0000 1/12/09, Robert Watson wrote:
>> On Fri, 9 Jan 2009, Garance A Drosihn wrote:
>>
>>> At 2:39 PM -0500 1/9/09, Robert Blayzor wrote:
>>>> On Jan 8, 2009, at 8:58 PM, Pete French wrote:
>>>>> I have a number of HP 1U servers, all of which were running 7.0 
>>>>> perfectly happily. I have been testing 7.1 in it's various 
>>>>> incarnations for the last couple of months on our test server and 
>>>>> it has performed perfectly.
>>>>
>>>> I noticed a problem with 7.0 on a couple of Dell servers.  [...] 
>>>> We've since then compiled the kernel under the BSD scheduler to 
>>>> rule that out, and so far so good.
>>>>
>>>> Since ULE is now default in 7.1 and not in 7.0, perhaps you can try 
>>>> that?
>>>
>>> FWIW, the other guy I know who is having this problem had already 
>>> switched to using ULE under 7.0-release, and did not have any 
>>> problems with it.  So *his* problem was probably not related to 
>>> SCHED_ULE, unless something has recently changed there.
>>>
>>> Turns out he hasn't reverted back to 7.0-release just yet, so he's 
>>> going to try SCHED_4BSD and see if that helps his situation.
>>
>> Scheduler changes always come with some risk of exposing bugs that 
>> have existed in the code for a long time but never really manifested 
>> themselves. ULE is well shaken-out, having been under development for 
>> at least five years, but it is possible that some problems will 
>> become visible as a result of the switch.  I would encourage people 
>> to stick with ULE, but if you're having a stability problem then 
>> experimenting with scheduler as a variable that could be triggering 
>> the problem may well be useful to help track down the bug.
>
> Just to followup on this:  My friend did switch back to a 7.1 kernel with
> SCHED_4BSD, and he still ran into problems.  The error messages weren't
> the same, but errors did happen in the same high disk-I/O situations as
> the lockup happened with SCHED_ULE.  At this point he's fallen back to
> the 7.0-kernel that he had been running (which also has SCHED_ULE), and
> all the problems have gone away.  So at the moment he's running with a
> 7.0-ish kernel and the 7.1-release userland, without the hanging 
> problems.
> So the problem is something in the kernel, but it is *NOT* the scheduler
> (at least, not in his case).
>
> He is not eager to do a whole lot of experiments to track down the
> problem, since this is happening on busy production machines and he
> can't afford to have a lot of downtime on them (especially now that the
> semester at RPI has started up).  The systems have some large (2 TB)
> filesystems on them, and the lockups occur in high disk-I/O situations.
> He's seeing the problem on one system which is a dual CPU quad-core
> xeon, and another which is a 64 bit P4 with hyperthreading.  The one
> thing in common between the two setups is that the boot drives + a
> 3ware controller (with its array of RAID disks) is moved from one
> machine to the other one:
>
>   "its a 3ware 9500 12 port model, the boot drive is connected to
>    an ICH6 in IDE mode, and yes, I've run it in single, single with
>    hyper threading, and 8 way mode.  All 64 bit."
>
> We still have no idea where the problem really is.  For all we know,
> someone spilled a Pepsi on it when he wasn't looking...
>
From kometen at gmail.com  Mon Jan 12 13:31:50 2009
From: kometen at gmail.com (Claus Guttesen)
Date: Mon Jan 12 13:33:02 2009
Subject: Big problems with 7.1 locking up :-(
In-Reply-To: <496BA9AE.10801@max.af.czu.cz>
References: <E1LL6dg-0007CN-DI@dilbert.ticketswitch.com>
	<042FE04A-2F8D-47DD-8454-7BBA3791D7A8@inoc.net>
	<p06240802c58db5953598@128.113.24.47>
	<alpine.BSF.2.00.0901121453200.16794@fledge.watson.org>
	<p06240808c5911644dd11@128.113.24.47> <496BA9AE.10801@max.af.czu.cz>
Message-ID: <b41c75520901121331o183201ebjd2d88c1af6bae54b@mail.gmail.com>

> I have similar problems. The last "good" kernel I have from stable brach,
> october the 8. Then in next upgrade, I saw big problems with performance.
> I tried ULE, 4BSD etc, but nothing helps, only downgrading system back.
>
> Now I am trying 7.1-p1 and problems are here again. Mysql is waiting a lot
> of time with status "waiting for opening table" or "waiting for close
> tables"
>
> I have 32bit FreeBSD with PAE, 1x xeon 5420, supermicro motherboard, areca
> SATA controller. Could not be problem in "da" device for example?

It was mentioned previous in this thread that CPUTYPE could be an
issue. Did you change this if you customized your kernel?

-- 
regards
Claus

When lenity and cruelty play for a kingdom,
the gentler gamester is the soonest winner.

Shakespeare
From walt at relnor.com  Mon Jan 12 13:34:00 2009
From: walt at relnor.com (Walter Venable)
Date: Mon Jan 12 13:34:07 2009
Subject: FreeBSD 7.1 Breaks re and rl Network Interface Drivers
In-Reply-To: <20090108023506.GF1256@cdnetworks.co.kr>
References: <8dfae1c10901070639x67945324jeeecfcac647d7976@mail.gmail.com>
	<8dfae1c10901071550s69d99802p31ca7c775f3d6823@mail.gmail.com>
	<20090108015036.GD1256@cdnetworks.co.kr>
	<486185590901071820tfcd3375sb890fe60867ec84d@mail.gmail.com>
	<20090108023506.GF1256@cdnetworks.co.kr>
Message-ID: <486185590901121333r7485ca7ga107f413f2c6e2e5@mail.gmail.com>

Pyun,
I was able to perform a full source downgrade to 7.0 and all the
problems went away.  Curiously, re0 and re1 have reversed names --
what was re0 is now re1, and vice versa.  I need my box to be up and
working so I can't throw 7.1 on it again.  If I can offer any data
from 7.0, please let me know.

On Wed, Jan 7, 2009 at 9:35 PM, Pyun YongHyeon <pyunyh@gmail.com> wrote:
> On Wed, Jan 07, 2009 at 09:20:05PM -0500, Walter Venable wrote:
>  > On Wed, Jan 7, 2009 at 8:50 PM, Pyun YongHyeon <pyunyh@gmail.com> wrote:
>  > > Please show me full dmesg output.
>  > >
>  >
>  > Hi Pyun,
>  > I have attached the full dmesg output.
>
> Walter, I need dmesg output of 7.1-RELEASE.
>
> --
> Regards,
> Pyun YongHyeon
>
From rizzo at icir.org  Mon Jan 12 14:14:54 2009
From: rizzo at icir.org (Luigi Rizzo)
Date: Mon Jan 12 14:15:02 2009
Subject: New disk schedulers available for FreeBSD
In-Reply-To: <20090112183408.GE29426@gandalf.sssup.it>
References: <20090112181221.GA54984@onelab2.iet.unipi.it>
	<20090112183408.GE29426@gandalf.sssup.it>
Message-ID: <20090112220058.GA61788@onelab2.iet.unipi.it>

Hi,
Fabio Checconi and myself have developed a GEOM-based disk scheduler
for FreeBSD. The scheduler is made of a GEOM kernel module, the
corresponding userland claas library, and other loadable kernel
modules that implement the actual scheduling algorithm.

At the URL below you can find a tarball with full sources and
also a set of pre-built modules/libraries for RELENG_7, to ease testing.

    http://feanor.sssup.it/~fabio/freebsd/io_sched/fc_sched.tar.gz

Below you can find the README file that comes with the distribution.

I would encourage people to try it and submit feedback, because the
initial results are extremely interesting. While I just tried the
code under RELENG_7/i386, it should build and work on all versions
that have GEOM (but read below).

Also the code is quite robust, because most of the difficult tasks
(data moving, synchronization, etc.) are handled by GEOM, and the
scheduler is only deciding which requests to serve and when.

NOTE: The scheduler is designed to be distributed as a port, but
it needs an extra field in 'struct bio' and a small change in
function g_io_request() to work. Both changes are trivial but need
a kernel rebuild.

To try this code on AMD64 you do need to patch and rebuild the kernel.

On i386, and purely to ease evaluation, we avoid the need for a kernel
rebuild by patching one function in-memory (and patching it back
when the module is unloaded).

	cheers
	luigi and fabio

A copy of the README file follows:

	--- GEOM BASED DISK SCHEDULERS FOR FREEBSD ---

This code contains a framework for GEOM-based disk schedulers and a
couple of sample scheduling algorithms that use the framework and
implement two forms of "anticipatory scheduling" (see below for more
details).

As a quick example of what this code can give you, try to run "dd",
or "tar", or some other code with highly SEQUENTIAL access patterns,
together with "cvs" or "cvsup" or other highly RANDOM access patterns
(this is not a made-up example: it is pretty common for developers
to have one or more apps doing random accesses, and others that do
sequential accesses e.g., loading large binaries from disk, checking
the integrity of tarballs, watching media streams and so on).

These are the results we get on a local machine (AMD BE2400 dual
core CPU, SATA 250GB disk):

    /mnt is a partition mounted on /dev/ad0s1f
	(or /dev/ad0-sched-s1f when used with the scheduler)

    cvs: 	cvs -d /mnt/home/ncvs-local update -Pd /mnt/ports
    dd-read:	dd bs=128k of=/dev/null if=/dev/ad0 (or ad0-sched-)
    dd-writew	dd bs=128k if=/dev/zero of=/mnt/largefile

			NO SCHEDULER		RR SCHEDULER
                	dd	cvs		dd	cvs

    dd-read only        72 MB/s	----		72 MB/s	---
    dd-write only	55 MB/s	---		55 MB/s	---
    dd-read+cvs		 6 MB/s	ok    		30 MB/s	ok
    dd-write+cvs	55 MB/s slooow		14 MB/s	ok

As you can see, when a cvs is running concurrently with dd, the
performance drops dramatically, and depending on read or write mode,
one of the two is severely penalized. The use of the RR scheduler
in this example makes the dd-reader go much faster when competing
with cvs, and lets cvs progress when competing with a writer.

To try it out:

1. PLEASE READ CAREFULLY THE FOLLOWING:

    To avoid the need to rebuild a kernel, and just for testing
    purposes, we implemented a hack which consists in patching one
    kernel function (g_io_request) so that it executes the marking
    of "bio's" (I/O requests). Also, the classification info is
    stored in a rarely used field of struct bio. See details in the
    file g_sched.c .

    At the moment the 'patch' hack is only for i386 kernels built
    with standard flags. For other configurations, you need to
    manually patch sys/geom/geom_io.c as indicated by the error
    message that you will get.

    If you don't like the above, don't run this code.

    Also note that these hacks are only for testing purpose.  If
    this code ever goes in the tree, it will use the correct approach
    which is adding a field to 'struct bio' to store the classification
    info, and modify g_io_request() to call a function to initialize
    that field.

2. PLEASE MAKE SURE THAT THE DISK THAT YOU WILL BE USING FOR TESTS
   DOES NOT CONTAIN PRECIOUS DATA.
   This is experimental code and may fail, especially at this stage.

3. EXTRACT AND BUILD THE PROGRAMS
   A 'make install' in the directory should work (with root privs),
   or you can even try the binary modules.
   If you want to build the modules yourself, look at the Makefile.

4. LOAD THE MODULE, CREATE A GEOM NODE, RUN TESTS

	kldload gsched_rr
	# --- configure the scheduler on device ad0
	geom sched create -a rr ad0
	# -- now you will have entries /dev/ad0-sched-

   For tests you can do the same as i did above, i.e. run concurrent
   programs that access the disk without the scheduler (/dev/ad0...)
   and with the scheduler (/dev/ad0-sched-...) and see the difference.

--- NOTES ON THE SCHEDULERS ---

The important contribution of this code is the framework to experiment
with different scheduling algorithms.  'Anticipatory scheduling'
is a very powerful technique based on the following reasoning:

    The disk throughput is much better if it serves sequential requests.
    If we have a mix of sequential and random requests, and we see a
    non-sequential request, do not serve it immediately but instead wait
    a little bit (2..5ms) to see if there is another one coming that
    the disk can serve more efficiently.

There are many details that should be added to make sure that the
mechanism is effective with different workloads and systems, to gain a
few extra percent in performance, to improve fairness, insulation
among processes etc. A discussion of the vast literature on the subject
is beyond the purpose of this short note.

--------------------------------------------------------------------------
From freebsd at optiksecurite.com  Mon Jan 12 15:09:08 2009
From: freebsd at optiksecurite.com (FreeBSD)
Date: Mon Jan 12 15:09:16 2009
Subject: FreeBSD 7.1 Breaks re and rl Network Interface Drivers
In-Reply-To: <20090112011146.GC46346@cdnetworks.co.kr>
References: <8dfae1c10901070639x67945324jeeecfcac647d7976@mail.gmail.com>
	<8dfae1c10901071550s69d99802p31ca7c775f3d6823@mail.gmail.com>
	<88527079.20090111192206@donpac.ru>
	<20090112011146.GC46346@cdnetworks.co.kr>
Message-ID: <496BBFF6.7010300@optiksecurite.com>

Pyun YongHyeon a ?crit :
> On Sun, Jan 11, 2009 at 07:22:06PM +0300, Eugene Gladchenko wrote:
>  > Walter,
>  > 
>  > Thursday, January 8, 2009, 2:50:40 AM, you wrote:
>  > 
>  > WV> Booting kernel.old, which is 7.0-RELEASE-p7 completely alleviates all
>  > WV> problems.  I believe this roundly confirms that this is a bug in the
>  > WV> 7.1-RELEASE re kernel drivers.
>  > 
>  > Does kern/130011 look similar? http://www.freebsd.org/cgi/query-pr.cgi?pr=130011
> 
> Do you have RTL8168C controller? If not, it's not related with
> Walter's issue as 7.0-RELEASE didn't have a support for RTL8168C.
> 
>  > 
>  > The re driver was really broken in 7.1-RC2 and the fix didn't get to 7.1-RELEASE.
> 
> If you have re(4) issues, please provide more details such as
> dmesg output, way to reproduce the issue etc.
> 

Hi,

I have the exact same card and the exact same problem as the PR you 
mentionned.

re0@pci0:3:0:0: class=0x020000 card=0x02831028 chip=0x816810ec rev=0x02 
hdr=0x00
     vendor     = 'Realtek Semiconductor'
     device     = 'RTL8168/8111 PCI-E Gigabit Ethernet NIC'
     class      = network
     subclass   = ethernet


re0: <RealTek 8168/8168B/8168C/8168CP/8168D/8111B/8111C/8111CP PCIe 
Gigabit Ethernet> port 0xd800-0xd8ff mem 
0xfeaff000-0xfeafffff,0xfdff0000-0xfdffffff irq 18 at device 0.0 on pci3
re0: Chip rev. 0x3c000000
re0: MAC rev. 0x00400000
re0: PHY write failed
re0: PHY write failed
re0: MII without any phy!
device_attach: re0 attach returned 6

I tried to compile a new kernel with the latest version of the 3 files 
listed in the PR:
src/sys/dev/re/if_re.c,v 1.147 2008/12/22 00:46:22 yongari
src/sys/pci/if_rl.c,v 1.170.2.10 2009/01/12 04:10:40 yongari
src/sys/pci/if_rlreg.h,v 1.67.2.16 2009/01/12 03:48:25 yongari

but I get the following error in buildworld:

cc -c -O -pipe  -std=c99 -g -Wall -Wredundant-decls -Wnested-externs 
-Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline 
-Wcast-qual  -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc 
-I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -D_KERNEL 
-DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common 
-finline-limit=8000 --param inline-unit-growth=100 --param 
large-function-growth=1000  -mno-align-long-strings 
-mpreferred-stack-boundary=2  -mno-mmx -mno-3dnow -mno-sse -mno-sse2 
-mno-sse3 -ffreestanding -Werror  /usr/src/sys/dev/re/if_re.c
/usr/src/sys/dev/re/if_re.c: In function 're_miibus_statchg':
/usr/src/sys/dev/re/if_re.c:594: error: 'RL_FLAG_FASTETHER' undeclared 
(first use in this function)
/usr/src/sys/dev/re/if_re.c:594: error: (Each undeclared identifier is 
reported only once
/usr/src/sys/dev/re/if_re.c:594: error: for each function it appears in.)
/usr/src/sys/dev/re/if_re.c: In function 're_reset':
/usr/src/sys/dev/re/if_re.c:703: error: 'RL_FLAG_PHY8169' undeclared 
(first use in this function)
/usr/src/sys/dev/re/if_re.c:705: error: 'RL_FLAG_PHY8110S' undeclared 
(first use in this function)
/usr/src/sys/dev/re/if_re.c: In function 're_attach':
/usr/src/sys/dev/re/if_re.c:1160: error: 'RL_FLAG_PCIE' undeclared 
(first use in this function)
/usr/src/sys/dev/re/if_re.c:1242: error: 'RL_FLAG_FASTETHER' undeclared 
(first use in this function)
/usr/src/sys/dev/re/if_re.c:1245: error: 'RL_FLAG_PHY8110S' undeclared 
(first use in this function)
/usr/src/sys/dev/re/if_re.c:1256: error: 'RL_FLAG_CMDSTOP' undeclared 
(first use in this function)
/usr/src/sys/dev/re/if_re.c:1260: error: 'RL_FLAG_WOLRXENB' undeclared 
(first use in this function)
/usr/src/sys/dev/re/if_re.c:1267: error: 'RL_FLAG_MACSLEEP' undeclared 
(first use in this function)
/usr/src/sys/dev/re/if_re.c:1292: error: 'RL_FLAG_PHY8169' undeclared 
(first use in this function)
/usr/src/sys/dev/re/if_re.c:1362: error: 'RL_MACDBG' undeclared (first 
use in this function)
/usr/src/sys/dev/re/if_re.c:1363: error: 'RL_GPIO' undeclared (first use 
in this function)
/usr/src/sys/dev/re/if_re.c: In function 're_int_task':
/usr/src/sys/dev/re/if_re.c:2184: error: 'RL_FLAG_PCIE' undeclared 
(first use in this function)
/usr/src/sys/dev/re/if_re.c: In function 're_stop':
/usr/src/sys/dev/re/if_re.c:2908: error: 'RL_FLAG_CMDSTOP' undeclared 
(first use in this function)
/usr/src/sys/dev/re/if_re.c:2909: error: 'RL_CMD_STOPREQ' undeclared 
(first use in this function)
/usr/src/sys/dev/re/if_re.c: In function 're_resume':
/usr/src/sys/dev/re/if_re.c:2989: error: 'RL_FLAG_MACSLEEP' undeclared 
(first use in this function)
/usr/src/sys/dev/re/if_re.c:2990: error: 'RL_MACDBG' undeclared (first 
use in this function)
/usr/src/sys/dev/re/if_re.c:2991: error: 'RL_GPIO' undeclared (first use 
in this function)
/usr/src/sys/dev/re/if_re.c: In function 're_setwol':
/usr/src/sys/dev/re/if_re.c:3050: error: 'RL_FLAG_MACSLEEP' undeclared 
(first use in this function)
/usr/src/sys/dev/re/if_re.c:3051: error: 'RL_MACDBG' undeclared (first 
use in this function)
/usr/src/sys/dev/re/if_re.c:3052: error: 'RL_GPIO' undeclared (first use 
in this function)
/usr/src/sys/dev/re/if_re.c:3056: error: 'RL_FLAG_WOLRXENB' undeclared 
(first use in this function)
*** Error code 1

Stop in /usr/obj/usr/src/sys/GENERIC.
*** Error code 1

Stop in /usr/src.
*** Error code 1

Stop in /usr/src.
------------

Thanks a lot for your help!

Martin
From rwatson at FreeBSD.org  Mon Jan 12 16:05:04 2009
From: rwatson at FreeBSD.org (Robert Watson)
Date: Mon Jan 12 16:05:10 2009
Subject: Big problems with 7.1 locking up :-(
In-Reply-To: <496BA9AE.10801@max.af.czu.cz>
References: <E1LL6dg-0007CN-DI@dilbert.ticketswitch.com>
	<042FE04A-2F8D-47DD-8454-7BBA3791D7A8@inoc.net>
	<p06240802c58db5953598@[128.113.24.47]>
	<alpine.BSF.2.00.0901121453200.16794@fledge.watson.org>
	<p06240808c5911644dd11@[128.113.24.47]>
	<496BA9AE.10801@max.af.czu.cz>
Message-ID: <alpine.BSF.2.00.0901130000520.16794@fledge.watson.org>

On Mon, 12 Jan 2009, Tomas Randa wrote:

> I have similar problems. The last "good" kernel I have from stable brach, 
> october the 8. Then in next upgrade, I saw big problems with performance. I 
> tried ULE, 4BSD etc, but nothing helps, only downgrading system back.
>
> Now I am trying 7.1-p1 and problems are here again. Mysql is waiting a lot 
> of time with status "waiting for opening table" or "waiting for close 
> tables"
>
> I have 32bit FreeBSD with PAE, 1x xeon 5420, supermicro motherboard, areca 
> SATA controller. Could not be problem in "da" device for example?

So far, this sounds like a different problem than the one others have been 
posting about, which involves full system freezes rather than specific 
processes wedging or responding poorly.  I'd suggest starting by using 
"procstat -k" on the process ID to look at where specific threads are waiting 
in the kernel.  Is it simply that MySQL is being unreasonably slow in certain 
situations, or does it actually entirely stop operating?

If you're able to narrow down the date on the 7.x branch where the problem 
you're experiencing "begins", that would be most helpful.  I'd suggest leaving 
your userspace on the 8th october, and sliding the kernel forward in a binary 
search until you've narrowed it down a bit.  Obviously, this takes a bit of 
patience, but narrowing it down could be quite informative.

Robert N M Watson
Computer Laboratory
University of Cambridge

>
> Thanks Tomas Randa
>
> Garance A Drosihn wrote:
>> At 2:55 PM +0000 1/12/09, Robert Watson wrote:
>>> On Fri, 9 Jan 2009, Garance A Drosihn wrote:
>>> 
>>>> At 2:39 PM -0500 1/9/09, Robert Blayzor wrote:
>>>>> On Jan 8, 2009, at 8:58 PM, Pete French wrote:
>>>>>> I have a number of HP 1U servers, all of which were running 7.0 
>>>>>> perfectly happily. I have been testing 7.1 in it's various incarnations 
>>>>>> for the last couple of months on our test server and it has performed 
>>>>>> perfectly.
>>>>> 
>>>>> I noticed a problem with 7.0 on a couple of Dell servers.  [...] We've 
>>>>> since then compiled the kernel under the BSD scheduler to rule that out, 
>>>>> and so far so good.
>>>>> 
>>>>> Since ULE is now default in 7.1 and not in 7.0, perhaps you can try 
>>>>> that?
>>>> 
>>>> FWIW, the other guy I know who is having this problem had already 
>>>> switched to using ULE under 7.0-release, and did not have any problems 
>>>> with it.  So *his* problem was probably not related to SCHED_ULE, unless 
>>>> something has recently changed there.
>>>> 
>>>> Turns out he hasn't reverted back to 7.0-release just yet, so he's going 
>>>> to try SCHED_4BSD and see if that helps his situation.
>>> 
>>> Scheduler changes always come with some risk of exposing bugs that have 
>>> existed in the code for a long time but never really manifested 
>>> themselves. ULE is well shaken-out, having been under development for at 
>>> least five years, but it is possible that some problems will become 
>>> visible as a result of the switch.  I would encourage people to stick with 
>>> ULE, but if you're having a stability problem then experimenting with 
>>> scheduler as a variable that could be triggering the problem may well be 
>>> useful to help track down the bug.
>> 
>> Just to followup on this:  My friend did switch back to a 7.1 kernel with
>> SCHED_4BSD, and he still ran into problems.  The error messages weren't
>> the same, but errors did happen in the same high disk-I/O situations as
>> the lockup happened with SCHED_ULE.  At this point he's fallen back to
>> the 7.0-kernel that he had been running (which also has SCHED_ULE), and
>> all the problems have gone away.  So at the moment he's running with a
>> 7.0-ish kernel and the 7.1-release userland, without the hanging problems.
>> So the problem is something in the kernel, but it is *NOT* the scheduler
>> (at least, not in his case).
>> 
>> He is not eager to do a whole lot of experiments to track down the
>> problem, since this is happening on busy production machines and he
>> can't afford to have a lot of downtime on them (especially now that the
>> semester at RPI has started up).  The systems have some large (2 TB)
>> filesystems on them, and the lockups occur in high disk-I/O situations.
>> He's seeing the problem on one system which is a dual CPU quad-core
>> xeon, and another which is a 64 bit P4 with hyperthreading.  The one
>> thing in common between the two setups is that the boot drives + a
>> 3ware controller (with its array of RAID disks) is moved from one
>> machine to the other one:
>>
>>   "its a 3ware 9500 12 port model, the boot drive is connected to
>>    an ICH6 in IDE mode, and yes, I've run it in single, single with
>>    hyper threading, and 8 way mode.  All 64 bit."
>> 
>> We still have no idea where the problem really is.  For all we know,
>> someone spilled a Pepsi on it when he wasn't looking...
>> 
>
From rwatson at FreeBSD.org  Mon Jan 12 16:09:24 2009
From: rwatson at FreeBSD.org (Robert Watson)
Date: Mon Jan 12 16:09:31 2009
Subject: Big problems with 7.1 locking up :-(
In-Reply-To: <E1LMS1C-0002x6-Je@dilbert.ticketswitch.com>
References: <E1LMS1C-0002x6-Je@dilbert.ticketswitch.com>
Message-ID: <alpine.BSF.2.00.0901130005130.16794@fledge.watson.org>


On Mon, 12 Jan 2009, Pete French wrote:

>> I'm not sure if you've done this already, but the normal suggestions apply: 
>> have you compiled with INVARIANTS/WITNESS/DDB/KDB/BREAK_TO_DEBUGGER, and do 
>> any results / panics / etc result?  Sometimes these debugging tools are 
>> able to convert hangs into panics, which gives us much more ability to 
>> debug them.
>
> OK, I have now had a machine hand again, with the correct debug options in 
> the kernel. The screen looked like this when I went to restart it:
>
> 	http://toybox.twisted.org.uk/~pete/71_lor2.png
>
> It had not, however, dropped into any kind of debugger. Also there appear to 
> me console messages after the lock order reversal - is that normal ?

Lock order reversals are warnings of potential deadlock due to a lock cycle, 
but deadlocks may not actually result, either because it's a false positive 
(some locking construct that is deadlock free but involves lock cycles), or 
because a cycle didn't actually form.  The message is suggestive, but if you 
have significant system activity after the message, then it may be unrelated.

> The machine did stay up for a signifanct amount of time before doing this. I 
> notice that it is more or less identical to the one I posted whenI had 
> WITNESS_KDB in the kernel too, so maybe those results arent entirely 
> suprious after all ?
>
> Given it hasnt dropped to a debugger, is there anything else I can try ?

Features like WITNESS and INVARIANTS may change the timing of the kernel 
making certain race conditions less likely; I'd run with them for a bit and 
see if you can reproduce the hang with them present, as they will make 
debugging the problem a lot easier, if it's possible.

Robert N M Watson
Computer Laboratory
University of Cambridge
From rwatson at FreeBSD.org  Mon Jan 12 16:13:26 2009
From: rwatson at FreeBSD.org (Robert Watson)
Date: Mon Jan 12 16:13:33 2009
Subject: Big problems with 7.1 locking up :-(
In-Reply-To: <p06240808c5911644dd11@[128.113.24.47]>
References: <E1LL6dg-0007CN-DI@dilbert.ticketswitch.com>
	<042FE04A-2F8D-47DD-8454-7BBA3791D7A8@inoc.net>
	<p06240802c58db5953598@[128.113.24.47]>
	<alpine.BSF.2.00.0901121453200.16794@fledge.watson.org>
	<p06240808c5911644dd11@[128.113.24.47]>
Message-ID: <alpine.BSF.2.00.0901130011070.16794@fledge.watson.org>

On Mon, 12 Jan 2009, Garance A Drosihn wrote:

> He is not eager to do a whole lot of experiments to track down the problem, 
> since this is happening on busy production machines and he can't afford to 
> have a lot of downtime on them (especially now that the semester at RPI has 
> started up).  The systems have some large (2 TB) filesystems on them, and 
> the lockups occur in high disk-I/O situations. He's seeing the problem on 
> one system which is a dual CPU quad-core xeon, and another which is a 64 bit 
> P4 with hyperthreading.  The one thing in common between the two setups is 
> that the boot drives + a 3ware controller (with its array of RAID disks) is 
> moved from one machine to the other one:

I think playing the combinatorics game on compile-time flags, kernel features, 
etc, is probably not the best way to go about debugging this.  Instead, I'd 
debug this as a kernel hang by breaking into the debugger once it occurs, if 
possible, and ideally on a serial console.  Often times hangs can be debugged 
looking solely at DDB output, or if possible, a crash dump.

Robert N M Watson
Computer Laboratory
University of Cambridge
From andrew at modulus.org  Mon Jan 12 16:21:26 2009
From: andrew at modulus.org (Andrew Snow)
Date: Mon Jan 12 16:21:34 2009
Subject: ZFSv13 in RELENG7
In-Reply-To: <gkfau1$gha$2@ger.gmane.org>
References: <200901120809.n0C89sib054679@lurza.secnetix.de>	<496B1DA8.5010407@modulus.org>
	<gkfau1$gha$2@ger.gmane.org>
Message-ID: <496BDE64.3020302@modulus.org>

Ivan Voras wrote:
> Andrew Snow wrote:
>> Oliver Fromme wrote:
>>> On the other hand, 8-current seems to run quite stable at
>>> the moment; I have it running on a workstation for several
>>> weeks without problems.
>> What date of CURRENT are you running?  I tracked down crashes related to
>> changes in SMBFS, but I am still experiencing almost weekly crashes such
>> as machine running out of swap space in the middle of the night for no
>> apparent reason..
> 
> Are you running rsync? Are the crashes happenning at about 3 am? (these
> two questions are unrelated)

Yes, running lots of rsync.

Also, yes, crashes have happened at night, not sure about 3am 
specifically, I've noticed more like 4am, 5am. But they always seem to 
happen when I'm not around.  Most of our rsync processes happen at night 
starting from 7pm and running all night.


- Andrew


From tinderbox at freebsd.org  Mon Jan 12 16:31:21 2009
From: tinderbox at freebsd.org (FreeBSD Tinderbox)
Date: Mon Jan 12 16:31:40 2009
Subject: [releng_7 tinderbox] failure on powerpc/powerpc
Message-ID: <20090113003117.9E9131B5060@freebsd-stable.sentex.ca>

TB --- 2009-01-12 23:22:06 - tinderbox 2.6 running on freebsd-stable.sentex.ca
TB --- 2009-01-12 23:22:06 - starting RELENG_7 tinderbox run for powerpc/powerpc
TB --- 2009-01-12 23:22:06 - cleaning the object tree
TB --- 2009-01-12 23:22:27 - cvsupping the source tree
TB --- 2009-01-12 23:22:27 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/powerpc/powerpc/supfile
TB --- 2009-01-12 23:22:37 - building world
TB --- 2009-01-12 23:22:37 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-01-12 23:22:37 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-01-12 23:22:37 - TARGET=powerpc
TB --- 2009-01-12 23:22:37 - TARGET_ARCH=powerpc
TB --- 2009-01-12 23:22:37 - TZ=UTC
TB --- 2009-01-12 23:22:37 - __MAKE_CONF=/dev/null
TB --- 2009-01-12 23:22:37 - cd /src
TB --- 2009-01-12 23:22:37 - /usr/bin/make -B buildworld
>>> World build started on Mon Jan 12 23:22:39 UTC 2009
>>> Rebuilding the temporary build tree
>>> stage 1.1: legacy release compatibility shims
>>> stage 1.2: bootstrap tools
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3: cross tools
>>> stage 4.1: building includes
>>> stage 4.2: building libraries
>>> stage 4.3: make dependencies
>>> stage 4.4: building everything
>>> World build completed on Tue Jan 13 00:27:57 UTC 2009
TB --- 2009-01-13 00:27:57 - generating LINT kernel config
TB --- 2009-01-13 00:27:57 - cd /src/sys/powerpc/conf
TB --- 2009-01-13 00:27:57 - /usr/bin/make -B LINT
TB --- 2009-01-13 00:27:57 - building LINT kernel
TB --- 2009-01-13 00:27:57 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-01-13 00:27:57 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-01-13 00:27:57 - TARGET=powerpc
TB --- 2009-01-13 00:27:57 - TARGET_ARCH=powerpc
TB --- 2009-01-13 00:27:57 - TZ=UTC
TB --- 2009-01-13 00:27:57 - __MAKE_CONF=/dev/null
TB --- 2009-01-13 00:27:57 - cd /src
TB --- 2009-01-13 00:27:57 - /usr/bin/make -B buildkernel KERNCONF=LINT
>>> Kernel build for LINT started on Tue Jan 13 00:27:58 UTC 2009
>>> stage 1: configuring the kernel
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3.1: making dependencies
>>> stage 3.2: building everything
[...]
awk -f /src/sys/tools/makeobjops.awk /src/sys/dev/ata/ata_if.m -c ;  cc -c -O2 -pipe -fno-strict-aliasing  -std=c99  -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc  -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding -Werror  ata_if.c
cc -c -O2 -pipe -fno-strict-aliasing  -std=c99  -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc  -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding -Werror  /src/sys/dev/ata/ata-all.c
cc -c -O2 -pipe -fno-strict-aliasing  -std=c99  -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc  -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding -Werror  /src/sys/dev/ata/ata-card.c
cc -c -O2 -pipe -fno-strict-aliasing  -std=c99  -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc  -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding -Werror  /src/sys/dev/ata/ata-chipset.c
/src/sys/dev/ata/ata-chipset.c: In function 'ata_marvell_ident':
/src/sys/dev/ata/ata-chipset.c:2558: error: 'MV_61XX' undeclared (first use in this function)
/src/sys/dev/ata/ata-chipset.c:2558: error: (Each undeclared identifier is reported only once
/src/sys/dev/ata/ata-chipset.c:2558: error: for each function it appears in.)
*** Error code 1

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

Stop in /src.
*** Error code 1

Stop in /src.
TB --- 2009-01-13 00:31:16 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2009-01-13 00:31:16 - ERROR: failed to build lint kernel
TB --- 2009-01-13 00:31:16 - 3493.72 user 348.45 system 4150.61 real


http://tinderbox.des.no/tinderbox-releng_7-RELENG_7-powerpc-powerpc.full
From andrew at modulus.org  Mon Jan 12 16:35:02 2009
From: andrew at modulus.org (Andrew Snow)
Date: Mon Jan 12 16:35:10 2009
Subject: fsck_y_enable: suboptimal/odd?
In-Reply-To: <496B3E28.3070902@icyb.net.ua>
References: <496B3E28.3070902@icyb.net.ua>
Message-ID: <496BE193.4070807@modulus.org>

Andriy Gapon wrote:

> To me it seems like fsck_y passes suboptimal flags to fsck, it doesn't
> have to examine each and every filesystem in fstab.

I think think this is because it does a quick check first to see if it 
can run the fsck in background after boot into multi-user mode.

If it cannot, then fsck exits and is re-run with fsck -y and runs in 
foreground mode.


- Andrew
From pyunyh at gmail.com  Mon Jan 12 16:40:27 2009
From: pyunyh at gmail.com (Pyun YongHyeon)
Date: Mon Jan 12 16:40:35 2009
Subject: FreeBSD 7.1 Breaks re and rl Network Interface Drivers
In-Reply-To: <496BBFF6.7010300@optiksecurite.com>
References: <8dfae1c10901070639x67945324jeeecfcac647d7976@mail.gmail.com>
	<8dfae1c10901071550s69d99802p31ca7c775f3d6823@mail.gmail.com>
	<88527079.20090111192206@donpac.ru>
	<20090112011146.GC46346@cdnetworks.co.kr>
	<496BBFF6.7010300@optiksecurite.com>
Message-ID: <20090113004018.GG46346@cdnetworks.co.kr>

On Mon, Jan 12, 2009 at 05:11:02PM -0500, FreeBSD wrote:
 > Pyun YongHyeon a ?crit :
 > >On Sun, Jan 11, 2009 at 07:22:06PM +0300, Eugene Gladchenko wrote:
 > > > Walter,
 > > > 
 > > > Thursday, January 8, 2009, 2:50:40 AM, you wrote:
 > > > 
 > > > WV> Booting kernel.old, which is 7.0-RELEASE-p7 completely alleviates 
 > > all
 > > > WV> problems.  I believe this roundly confirms that this is a bug in the
 > > > WV> 7.1-RELEASE re kernel drivers.
 > > > 
 > > > Does kern/130011 look similar? 
 > > http://www.freebsd.org/cgi/query-pr.cgi?pr=130011
 > >
 > >Do you have RTL8168C controller? If not, it's not related with
 > >Walter's issue as 7.0-RELEASE didn't have a support for RTL8168C.
 > >
 > > > 
 > > > The re driver was really broken in 7.1-RC2 and the fix didn't get to 
 > > 7.1-RELEASE.
 > >
 > >If you have re(4) issues, please provide more details such as
 > >dmesg output, way to reproduce the issue etc.
 > >
 > 
 > Hi,
 > 
 > I have the exact same card and the exact same problem as the PR you 
 > mentionned.
 > 
 > re0@pci0:3:0:0: class=0x020000 card=0x02831028 chip=0x816810ec rev=0x02 
 > hdr=0x00
 >     vendor     = 'Realtek Semiconductor'
 >     device     = 'RTL8168/8111 PCI-E Gigabit Ethernet NIC'
 >     class      = network
 >     subclass   = ethernet
 > 
 > 
 > re0: <RealTek 8168/8168B/8168C/8168CP/8168D/8111B/8111C/8111CP PCIe 
 > Gigabit Ethernet> port 0xd800-0xd8ff mem 
 > 0xfeaff000-0xfeafffff,0xfdff0000-0xfdffffff irq 18 at device 0.0 on pci3
 > re0: Chip rev. 0x3c000000
 > re0: MAC rev. 0x00400000
 > re0: PHY write failed
 > re0: PHY write failed
 > re0: MII without any phy!
 > device_attach: re0 attach returned 6
 > 
 > I tried to compile a new kernel with the latest version of the 3 files 
 > listed in the PR:
 > src/sys/dev/re/if_re.c,v 1.147 2008/12/22 00:46:22 yongari
 > src/sys/pci/if_rl.c,v 1.170.2.10 2009/01/12 04:10:40 yongari
 > src/sys/pci/if_rlreg.h,v 1.67.2.16 2009/01/12 03:48:25 yongari
 > 

You need lastest if_rl.c and if_rlreg.h as well as if_re.c.

 > but I get the following error in buildworld:

[...]

-- 
Regards,
Pyun YongHyeon
From jkim at FreeBSD.org  Mon Jan 12 17:10:54 2009
From: jkim at FreeBSD.org (Jung-uk Kim)
Date: Mon Jan 12 17:11:01 2009
Subject: FreeBSD 7.1 Breaks re and rl Network Interface Drivers
In-Reply-To: <496B7C17.8010107@holzleiter.name>
References: <8dfae1c10901070639x67945324jeeecfcac647d7976@mail.gmail.com>
	<496B7C17.8010107@holzleiter.name>
Message-ID: <200901122010.37269.jkim@FreeBSD.org>

On Monday 12 January 2009 12:21 pm, Sascha Holzleiter wrote:
> Walter Venable wrote:
> > FreeBSD 7.1 upgrade broke my network access, machine is totally
> > offline (powered-on and I can play inside it at the terminal, but
> > absolutely 0 network access):
> > This happened AFTER make kernel but BEFORE make installworld.  I
> > think this implies it's a kernel driver issue.
>
> Hi,
>
> i see similar problems with a re card:
>
> re0@pci0:4:7:0:	class=0x020000 card=0x816710ec chip=0x816710ec
> rev=0x10 hdr=0x00
>      vendor     = 'Realtek Semiconductor'
>      device     = 'RTL8169/8110 Family Gigabit Ethernet NIC'
>      class      = network
>      subclass   = ethernet
>
> After upgrading to 7.1-RELEASE (and also STABLE) the NIC doesn't
> seem to receive any frames. I can see the DHCP Requests on the DHCP
> Server but the DHCPOFFERS are never seen by the client with the re0
> device. After setting promiscious mode on the interface (i.e. by
> tcpdump -ni re0) the interface begins to work fine.
>
> I've attached a complete dmesg output, but i think the detection
> works fine, here the short version:
>
> re0: <RealTek 8169SC/8110SC Single-chip Gigabit Ethernet> port
> 0x9c00-0x9cff mem 0xdfdff000-0xdfdff0ff irq 20 at device 7.0 on
> pci4 re0: Chip rev. 0x18000000
> re0: MAC rev. 0x00000000
> miibus0: <MII bus> on re0
> rgephy0: <RTL8169S/8110S/8211B media interface> PHY 1 on miibus0
> rgephy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX,
> 1000baseT, 1000baseT-FDX, auto
> re0: Ethernet address: 00:1a:92:35:29:fa
> re0: [FILTER]

Please revert SVN r180519 (or CVS r1.95.2.22) and try again:

http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/re/if_re.c.diff?r1=1.95.2.21;r2=1.95.2.22

Jung-uk Kim
From tinderbox at freebsd.org  Mon Jan 12 17:33:45 2009
From: tinderbox at freebsd.org (FreeBSD Tinderbox)
Date: Mon Jan 12 17:34:03 2009
Subject: [releng_7 tinderbox] failure on sparc64/sparc64
Message-ID: <20090113013341.D390C1B5060@freebsd-stable.sentex.ca>

TB --- 2009-01-13 00:31:07 - tinderbox 2.6 running on freebsd-stable.sentex.ca
TB --- 2009-01-13 00:31:07 - starting RELENG_7 tinderbox run for sparc64/sparc64
TB --- 2009-01-13 00:31:07 - cleaning the object tree
TB --- 2009-01-13 00:31:22 - cvsupping the source tree
TB --- 2009-01-13 00:31:22 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/sparc64/sparc64/supfile
TB --- 2009-01-13 00:31:32 - building world
TB --- 2009-01-13 00:31:32 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-01-13 00:31:32 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-01-13 00:31:32 - TARGET=sparc64
TB --- 2009-01-13 00:31:32 - TARGET_ARCH=sparc64
TB --- 2009-01-13 00:31:32 - TZ=UTC
TB --- 2009-01-13 00:31:32 - __MAKE_CONF=/dev/null
TB --- 2009-01-13 00:31:32 - cd /src
TB --- 2009-01-13 00:31:32 - /usr/bin/make -B buildworld
>>> World build started on Tue Jan 13 00:31:34 UTC 2009
>>> Rebuilding the temporary build tree
>>> stage 1.1: legacy release compatibility shims
>>> stage 1.2: bootstrap tools
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3: cross tools
>>> stage 4.1: building includes
>>> stage 4.2: building libraries
>>> stage 4.3: make dependencies
>>> stage 4.4: building everything
>>> World build completed on Tue Jan 13 01:30:14 UTC 2009
TB --- 2009-01-13 01:30:14 - generating LINT kernel config
TB --- 2009-01-13 01:30:14 - cd /src/sys/sparc64/conf
TB --- 2009-01-13 01:30:14 - /usr/bin/make -B LINT
TB --- 2009-01-13 01:30:15 - building LINT kernel
TB --- 2009-01-13 01:30:15 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-01-13 01:30:15 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-01-13 01:30:15 - TARGET=sparc64
TB --- 2009-01-13 01:30:15 - TARGET_ARCH=sparc64
TB --- 2009-01-13 01:30:15 - TZ=UTC
TB --- 2009-01-13 01:30:15 - __MAKE_CONF=/dev/null
TB --- 2009-01-13 01:30:15 - cd /src
TB --- 2009-01-13 01:30:15 - /usr/bin/make -B buildkernel KERNCONF=LINT
>>> Kernel build for LINT started on Tue Jan 13 01:30:15 UTC 2009
>>> stage 1: configuring the kernel
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3.1: making dependencies
>>> stage 3.2: building everything
[...]
awk -f /src/sys/tools/makeobjops.awk /src/sys/dev/ata/ata_if.m -c ;  cc -c -O2 -pipe -fno-strict-aliasing  -std=c99  -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc  -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror  ata_if.c
cc -c -O2 -pipe -fno-strict-aliasing  -std=c99  -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc  -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror  /src/sys/dev/ata/ata-all.c
cc -c -O2 -pipe -fno-strict-aliasing  -std=c99  -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc  -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror  /src/sys/dev/ata/ata-card.c
cc -c -O2 -pipe -fno-strict-aliasing  -std=c99  -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc  -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror  /src/sys/dev/ata/ata-chipset.c
/src/sys/dev/ata/ata-chipset.c: In function 'ata_marvell_ident':
/src/sys/dev/ata/ata-chipset.c:2558: error: 'MV_61XX' undeclared (first use in this function)
/src/sys/dev/ata/ata-chipset.c:2558: error: (Each undeclared identifier is reported only once
/src/sys/dev/ata/ata-chipset.c:2558: error: for each function it appears in.)
*** Error code 1

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

Stop in /src.
*** Error code 1

Stop in /src.
TB --- 2009-01-13 01:33:41 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2009-01-13 01:33:41 - ERROR: failed to build lint kernel
TB --- 2009-01-13 01:33:41 - 3266.99 user 347.49 system 3753.93 real


http://tinderbox.des.no/tinderbox-releng_7-RELENG_7-sparc64-sparc64.full
From yanefbsd at gmail.com  Mon Jan 12 18:45:15 2009
From: yanefbsd at gmail.com (Garrett Cooper)
Date: Mon Jan 12 18:45:22 2009
Subject: New disk schedulers available for FreeBSD
In-Reply-To: <20090112220058.GA61788@onelab2.iet.unipi.it>
References: <20090112181221.GA54984@onelab2.iet.unipi.it>
	<20090112183408.GE29426@gandalf.sssup.it>
	<20090112220058.GA61788@onelab2.iet.unipi.it>
Message-ID: <7d6fde3d0901121845r6caf78c4vfec791e1afaa64c8@mail.gmail.com>

On Mon, Jan 12, 2009 at 2:00 PM, Luigi Rizzo <rizzo@icir.org> wrote:
> Hi,
> Fabio Checconi and myself have developed a GEOM-based disk scheduler
> for FreeBSD. The scheduler is made of a GEOM kernel module, the
> corresponding userland claas library, and other loadable kernel
> modules that implement the actual scheduling algorithm.
>
> At the URL below you can find a tarball with full sources and
> also a set of pre-built modules/libraries for RELENG_7, to ease testing.
>
>    http://feanor.sssup.it/~fabio/freebsd/io_sched/fc_sched.tar.gz
>
> Below you can find the README file that comes with the distribution.
>
> I would encourage people to try it and submit feedback, because the
> initial results are extremely interesting. While I just tried the
> code under RELENG_7/i386, it should build and work on all versions
> that have GEOM (but read below).

Hi Luigi!
    Is this changeset already available in CURRENT?
Thanks,
-Garrett
From ehrmann at gmail.com  Mon Jan 12 20:11:17 2009
From: ehrmann at gmail.com (David Ehrmann)
Date: Mon Jan 12 20:11:25 2009
Subject: zfs not exporting or unmounting
Message-ID: <496C1452.2020501@gmail.com>

I tried to export/unmount my zpool:

# zpool export tank
cannot unmount '/tank': Device busy

# zfs unmount /tank
cannot unmount '/tank': Device busy

but it wouldn't, so, after closing everything that could be using it, I 
tried again.  No luck.  Then I tried to see if I forgot something:

# fstat -m /tank
USER     CMD          PID   FD MOUNT      INUM MODE         SZ|DV R/W NAME

# lsof | grep tank
<nothing>

I'm out of ideas.  zpool export -f tank worked last time, but at the 
expense of taking down one drive in the mirror (it shouldn't have, but 
it did; I had to resilver it).

The one thing: I just did freebsd-update upgrade -r 7.1-RELEASE, and 
possibly freebsd-update install.

Thanks in advance.
From pyunyh at gmail.com  Mon Jan 12 21:02:33 2009
From: pyunyh at gmail.com (Pyun YongHyeon)
Date: Mon Jan 12 21:02:40 2009
Subject: FreeBSD 7.1 Breaks re and rl Network Interface Drivers
In-Reply-To: <496B71D3.5050203@andric.com>
References: <8dfae1c10901070639x67945324jeeecfcac647d7976@mail.gmail.com>
	<8dfae1c10901071550s69d99802p31ca7c775f3d6823@mail.gmail.com>
	<88527079.20090111192206@donpac.ru>
	<20090112011146.GC46346@cdnetworks.co.kr>
	<64114.83.221.215.168.1231741940.squirrel@83.221.215.168>
	<20090112064121.GF46346@cdnetworks.co.kr>
	<496B71D3.5050203@andric.com>
Message-ID: <20090113050223.GH46346@cdnetworks.co.kr>

On Mon, Jan 12, 2009 at 05:37:39PM +0100, Dimitry Andric wrote:
 > On 2009-01-12 07:41, Pyun YongHyeon wrote:
 > > I see, Unfortunately the issue was fixed in the end of 7.1-R
 > > release process so I wanted to get more exposure before MFC.
 > > I'll make sure to MFC to stable/7 after more testing.
 > 
 > I'm also having problems with re's, in my case the interfaces take about
 > 10 seconds to come up, if they come up at all.  After the interfaces are
 > up, half the time no packets go out at all.  Usually it helps to bring
 > them down via the console, wait about 10 seconds, and then bring them up
 > again...
 > 

It looks like that RTL8169SC users see regression and I vaguely
remember a couple of issues on RTL8169SC. As Jung-uk said in other
post, would yoy try reverting r180519? If that have no effect would
you try attached patch?

 > These are the following variant:
 > 
 > FreeBSD 7.1-STABLE #0: Mon Jan 12 14:22:11 CET 2009
 > [...]
 > re0: <RealTek 8169SC/8110SC Single-chip Gigabit Ethernet> port 0xf000-0xf0ff mem 0xfdfff000-0xfdfff0ff irq 18 at device 9.0 on pci0
 > re0: Chip rev. 0x18000000
 > re0: MAC rev. 0x00000000
 > miibus0: <MII bus> on re0
 > rgephy0: <RTL8169S/8110S/8211B media interface> PHY 1 on miibus0
 > rgephy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto
 > re0: Ethernet address: 00:30:18:a6:f1:a8
 > re0: [FILTER]
 > re1: <RealTek 8169SC/8110SC Single-chip Gigabit Ethernet> port 0xf200-0xf2ff mem 0xfdffe000-0xfdffe0ff irq 19 at device 11.0 on pci0
 > re1: Chip rev. 0x18000000
 > re1: MAC rev. 0x00000000
 > miibus1: <MII bus> on re1
 > rgephy1: <RTL8169S/8110S/8211B media interface> PHY 1 on miibus1
 > rgephy1:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto
 > re1: Ethernet address: 00:30:18:a6:f1:a9
 > re1: [FILTER]
 > 
 > And just FYI, r187080-r187083 that you recently committed (MFCs of
 > r184240-184243, r184245, 185575 and r186390), don't seem to change
 > anything for this situation. :(

Those MFC are for rl(4), not re(4) so you should see no behavioural
changes in re(4).

-- 
Regards,
Pyun YongHyeon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: re.8169sc.diff
Type: text/x-diff
Size: 1342 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090113/5849a222/re.8169sc.bin
From delphij at delphij.net  Mon Jan 12 21:48:58 2009
From: delphij at delphij.net (Xin LI)
Date: Mon Jan 12 21:49:05 2009
Subject: New disk schedulers available for FreeBSD
In-Reply-To: <7d6fde3d0901121845r6caf78c4vfec791e1afaa64c8@mail.gmail.com>
References: <20090112181221.GA54984@onelab2.iet.unipi.it>	<20090112183408.GE29426@gandalf.sssup.it>	<20090112220058.GA61788@onelab2.iet.unipi.it>
	<7d6fde3d0901121845r6caf78c4vfec791e1afaa64c8@mail.gmail.com>
Message-ID: <496C2B3D.2080400@delphij.net>

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

Garrett Cooper wrote:
> On Mon, Jan 12, 2009 at 2:00 PM, Luigi Rizzo <rizzo@icir.org> wrote:
>> Hi,
>> Fabio Checconi and myself have developed a GEOM-based disk scheduler
>> for FreeBSD. The scheduler is made of a GEOM kernel module, the
>> corresponding userland claas library, and other loadable kernel
>> modules that implement the actual scheduling algorithm.
>>
>> At the URL below you can find a tarball with full sources and
>> also a set of pre-built modules/libraries for RELENG_7, to ease testing.
>>
>>    http://feanor.sssup.it/~fabio/freebsd/io_sched/fc_sched.tar.gz
>>
>> Below you can find the README file that comes with the distribution.
>>
>> I would encourage people to try it and submit feedback, because the
>> initial results are extremely interesting. While I just tried the
>> code under RELENG_7/i386, it should build and work on all versions
>> that have GEOM (but read below).
> 
> Hi Luigi!
>     Is this changeset already available in CURRENT?

Not (yet).

- --
Xin LI <delphij@delphij.net>	http://www.delphij.net/
FreeBSD - The Power to Serve!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (FreeBSD)

iEYEARECAAYFAklsKz0ACgkQi+vbBBjt66A0oQCfaB3qBKF7QZ1lDMrSkHCmReUD
Di4AoIBQgg/Pe8zKD6Y7TBZO3Mz4pqUj
=pCBe
-----END PGP SIGNATURE-----
From ehrmann at gmail.com  Mon Jan 12 21:51:27 2009
From: ehrmann at gmail.com (David Ehrmann)
Date: Mon Jan 12 21:51:43 2009
Subject: zfs not exporting or unmounting
In-Reply-To: <496C1452.2020501@gmail.com>
References: <496C1452.2020501@gmail.com>
Message-ID: <496C2BCC.9090903@gmail.com>

David Ehrmann wrote:
> # fstat -m /tank
I guess I should have used a different flag, but no luck there, either
> USER     CMD          PID   FD MOUNT      INUM MODE         SZ|DV R/W 
> NAME
>
> # lsof | grep tank
> <nothing>
I did fix it.  I had a runaway bash process (that kill -s HUP fixed, 
oddly enough), but why don't any of these commands list the files I have 
open, even when files really are open?
From rizzo at icir.org  Mon Jan 12 22:50:25 2009
From: rizzo at icir.org (Luigi Rizzo)
Date: Mon Jan 12 22:50:32 2009
Subject: New disk schedulers available for FreeBSD
In-Reply-To: <7d6fde3d0901121845r6caf78c4vfec791e1afaa64c8@mail.gmail.com>
References: <20090112181221.GA54984@onelab2.iet.unipi.it>
	<20090112183408.GE29426@gandalf.sssup.it>
	<20090112220058.GA61788@onelab2.iet.unipi.it>
	<7d6fde3d0901121845r6caf78c4vfec791e1afaa64c8@mail.gmail.com>
Message-ID: <20090113065532.GA79190@onelab2.iet.unipi.it>

On Mon, Jan 12, 2009 at 06:45:13PM -0800, Garrett Cooper wrote:
> On Mon, Jan 12, 2009 at 2:00 PM, Luigi Rizzo <rizzo@icir.org> wrote:
> > Hi,
> > Fabio Checconi and myself have developed a GEOM-based disk scheduler
> > for FreeBSD. The scheduler is made of a GEOM kernel module, the
> > corresponding userland claas library, and other loadable kernel
> > modules that implement the actual scheduling algorithm.
> >
> > At the URL below you can find a tarball with full sources and
> > also a set of pre-built modules/libraries for RELENG_7, to ease testing.
> >
> >    http://feanor.sssup.it/~fabio/freebsd/io_sched/fc_sched.tar.gz
> >
> > Below you can find the README file that comes with the distribution.
> >
> > I would encourage people to try it and submit feedback, because the
> > initial results are extremely interesting. While I just tried the
> > code under RELENG_7/i386, it should build and work on all versions
> > that have GEOM (but read below).
> 
> Hi Luigi!
>     Is this changeset already available in CURRENT?

no but the port above should hopefully build under -current as well,
unless there are changes in the GEOM ABI.

I built it on RELENG_7 and RELENG_6, will try HEAD today.

cheers
luigi
From dougb at FreeBSD.org  Tue Jan 13 01:11:33 2009
From: dougb at FreeBSD.org (Doug Barton)
Date: Tue Jan 13 01:11:40 2009
Subject: Big problems with 7.1 locking up :-(
In-Reply-To: <E1LMNsw-0001ix-Q7@dilbert.ticketswitch.com>
References: <E1LMNsw-0001ix-Q7@dilbert.ticketswitch.com>
Message-ID: <496C5AC2.90408@FreeBSD.org>

Pete French wrote:
> Mine never lock up doing buildworlds either. They only lock up when they are
> sitting there more of less idle! The machines which have never locked up
> are the webservers, which are fairly heavlt loaded. The machine which locks
> up the most frequently is a box sitting there doing nothing but DNS, which is
> the most lightly loaded of the lot.

Silly question but do you have powerd enabled on that server? If so,
does disabling it help? Also do you have any of these in /etc/rc.conf
(i.e., they are not the same as the default values in
/etc/defaults/rc.conf):
performance_cx_lowest="HIGH"    # Online CPU idle state
performance_cpu_freq="NONE"     # Online CPU frequency
economy_cx_lowest="HIGH"        # Offline CPU idle state
economy_cpu_freq="NONE"         # Offline CPU frequency


Doug

-- 

    This .signature sanitized for your protection

From lists at peter.de.com  Tue Jan 13 01:19:28 2009
From: lists at peter.de.com (Oliver Peter)
Date: Tue Jan 13 01:19:36 2009
Subject: FreeBSD 7.1 Breaks re and rl Network Interface Drivers
In-Reply-To: <8dfae1c10901070639x67945324jeeecfcac647d7976@mail.gmail.com>
References: <8dfae1c10901070639x67945324jeeecfcac647d7976@mail.gmail.com>
Message-ID: <20090113085941.GA95736@nemesis.frida.mouhaha.de>

I'm on 7.1-RELEASE/amd64 with the following card:

re0@pci0:2:0:0: class=0x020000 card=0x368c1462 chip=0x816810ec rev=0x01 hdr=0x00
    vendor     = 'Realtek Semiconductor'
    device     = 'RTL8168/8111 PCI-E Gigabit Ethernet NIC'
    class      = network
    subclass   = ethernet

And luckey me does not experience any network problems at all.

But I have to say that I was suffering an interrupt storm, and some
smart people told me just to remove USB and Firewire support from the
kernel which has fixed the problem.

Dunno if this helps you.

-- 
Oliver PETER, email: oliver@peter.de.com, ICQ# 113969174
"If it feels good, you're doing something wrong."
                                      -- Coach McTavish
From kometen at gmail.com  Tue Jan 13 01:51:17 2009
From: kometen at gmail.com (Claus Guttesen)
Date: Tue Jan 13 01:51:24 2009
Subject: Big problems with 7.1 locking up :-(
In-Reply-To: <496C5AC2.90408@FreeBSD.org>
References: <E1LMNsw-0001ix-Q7@dilbert.ticketswitch.com>
	<496C5AC2.90408@FreeBSD.org>
Message-ID: <b41c75520901130151uf27e220lecdf2937d94a7410@mail.gmail.com>

>> Mine never lock up doing buildworlds either. They only lock up when they are
>> sitting there more of less idle! The machines which have never locked up
>> are the webservers, which are fairly heavlt loaded. The machine which locks
>> up the most frequently is a box sitting there doing nothing but DNS, which is
>> the most lightly loaded of the lot.

The server has been idle for a day now and is up and running. I have
then copied a file to generate some i/o and it copies without
problems.

for ((a=0;a<10;a++))
  do
  cp netbeans-6.5-ml-macosx.dmg ${a}.dmg &
done

I can't  (fortunately) make it lock up. I have a DL360 G5 which is
unused atm. and can test on it if needed.

-- 
regards
Claus

When lenity and cruelty play for a kingdom,
the gentler gamester is the soonest winner.

Shakespeare
From pyunyh at gmail.com  Tue Jan 13 01:52:44 2009
From: pyunyh at gmail.com (Pyun YongHyeon)
Date: Tue Jan 13 01:52:56 2009
Subject: FreeBSD 7.1 Breaks re and rl Network Interface Drivers
In-Reply-To: <20090113085941.GA95736@nemesis.frida.mouhaha.de>
References: <8dfae1c10901070639x67945324jeeecfcac647d7976@mail.gmail.com>
	<20090113085941.GA95736@nemesis.frida.mouhaha.de>
Message-ID: <20090113095232.GJ46346@cdnetworks.co.kr>

On Tue, Jan 13, 2009 at 08:59:41AM +0000, Oliver Peter wrote:
 > I'm on 7.1-RELEASE/amd64 with the following card:
 > 
 > re0@pci0:2:0:0: class=0x020000 card=0x368c1462 chip=0x816810ec rev=0x01 hdr=0x00
 >     vendor     = 'Realtek Semiconductor'
 >     device     = 'RTL8168/8111 PCI-E Gigabit Ethernet NIC'
 >     class      = network
 >     subclass   = ethernet
 > 
 > And luckey me does not experience any network problems at all.
 > 
 > But I have to say that I was suffering an interrupt storm, and some
 > smart people told me just to remove USB and Firewire support from the
 > kernel which has fixed the problem.
 > 

Read the following thread and enable MSI feature of re(4).
http://lists.freebsd.org/pipermail/freebsd-stable/2008-December/047010.html

 > Dunno if this helps you.

-- 
Regards,
Pyun YongHyeon
From gavin at FreeBSD.org  Tue Jan 13 02:30:58 2009
From: gavin at FreeBSD.org (Gavin Atkinson)
Date: Tue Jan 13 02:31:06 2009
Subject: Big problems with 7.1 locking up :-(
In-Reply-To: <E1LMS1C-0002x6-Je@dilbert.ticketswitch.com>
References: <E1LMS1C-0002x6-Je@dilbert.ticketswitch.com>
Message-ID: <1231842653.70382.8.camel@buffy.york.ac.uk>

On Mon, 2009-01-12 at 19:00 +0000, Pete French wrote:
> > I'm not sure if you've done this already, but the normal suggestions apply: 
> > have you compiled with INVARIANTS/WITNESS/DDB/KDB/BREAK_TO_DEBUGGER, and do 
> > any results / panics / etc result?  Sometimes these debugging tools are able 
> > to convert hangs into panics, which gives us much more ability to debug them. 
> 
> OK, I have now had a machine hand again, with the correct debug options in
> the kernel. The screen looked like this when I went to restart it:
> 
> 	http://toybox.twisted.org.uk/~pete/71_lor2.png
> 
> It had not, however, dropped into any kind of debugger. Also there appear
> to me console messages after the lock order reversal - is that normal ?
> 
> The machine did stay up for a signifanct amount of time before doing this. I
> notice that it is more or less identical to the one I posted whenI
> had WITNESS_KDB in the kernel too, so maybe those results arent
> entirely suprious after all ?
> 
> Given it hasnt dropped to a debugger, is there anything else I can try ? 

Can you break into the debugger with Ctrl-Alt-Esc, or by sending a break
over the serial line?

Gavin
From petefrench at ticketswitch.com  Tue Jan 13 03:45:47 2009
From: petefrench at ticketswitch.com (Pete French)
Date: Tue Jan 13 03:46:03 2009
Subject: Big problems with 7.1 locking up :-(
In-Reply-To: <alpine.BSF.2.00.0901130005130.16794@fledge.watson.org>
Message-ID: <E1LMhiD-0000Rp-B2@dilbert.ticketswitch.com>

> Lock order reversals are warnings of potential deadlock due to a lock cycle, 
> but deadlocks may not actually result, either because it's a false positive 
> (some locking construct that is deadlock free but involves lock cycles), or 
> because a cycle didn't actually form.  The message is suggestive, but if you 
> have significant system activity after the message, then it may be unrelated.

Its hard to tell in this case as there are no timestamps, so I cant
see if there is any activity after the lockup.

> Features like WITNESS and INVARIANTS may change the timing of the kernel 
> making certain race conditions less likely; I'd run with them for a bit and 
> see if you can reproduce the hang with them present, as they will make 
> debugging the problem a lot easier, if it's possible.

Uh, the above *was* me reproducing the hang with them present ;-)) It
quite happily hangs with thoise things in the kernel - indeed the next
hang was immediately after I rebooted the machine. But even with WITNESS
and INVARIANTS and all the rest it does not drop to a debugger, it
simply locks up.

That machine is currently turned off, but still has 7.1 installed. What
would you like me to try now ? I have a lockup I can reproduce pretty
reliably now (just wait and it will always lock up). I also found that
my other 7.1 box locks up fairly reliably when doing a buildworld.

The only similarily between these two machines and the ones which dont
lock up is that these are serving DNS. The others don't. Note that all
the hardware is identical, as is the installed software and the configuration.

I am at a total loss...

-pete.
From petefrench at ticketswitch.com  Tue Jan 13 03:50:00 2009
From: petefrench at ticketswitch.com (Pete French)
Date: Tue Jan 13 03:50:07 2009
Subject: Big problems with 7.1 locking up :-(
In-Reply-To: <b41c75520901121331o183201ebjd2d88c1af6bae54b@mail.gmail.com>
Message-ID: <E1LMhmQ-0000T0-9M@dilbert.ticketswitch.com>

> It was mentioned previous in this thread that CPUTYPE could be an
> issue. Did you change this if you customized your kernel?

Actually, I think thats been ruled out as a possible cause, along
with the scheduler. Certainly I have tried it both ways and
there is no difference, and I think i saw that the others had too.

-pete.
From avg at icyb.net.ua  Tue Jan 13 04:02:16 2009
From: avg at icyb.net.ua (Andriy Gapon)
Date: Tue Jan 13 04:02:24 2009
Subject: fsck_y_enable: suboptimal/odd?
In-Reply-To: <496BE193.4070807@modulus.org>
References: <496B3E28.3070902@icyb.net.ua> <496BE193.4070807@modulus.org>
Message-ID: <496C82B1.9030604@icyb.net.ua>

on 13/01/2009 02:34 Andrew Snow said the following:
> Andriy Gapon wrote:
> 
>> To me it seems like fsck_y passes suboptimal flags to fsck, it doesn't
>> have to examine each and every filesystem in fstab.
> 
> I think think this is because it does a quick check first to see if it
> can run the fsck in background after boot into multi-user mode.
> 
> If it cannot, then fsck exits and is re-run with fsck -y and runs in
> foreground mode.

True, I do not have softupdates enabled and I also have bg fsck
explicietely prohibited. Still I do not understand why clean filesystems
have to be checked.

-- 
Andriy Gapon
From rwatson at FreeBSD.org  Tue Jan 13 04:42:10 2009
From: rwatson at FreeBSD.org (Robert Watson)
Date: Tue Jan 13 04:42:16 2009
Subject: Big problems with 7.1 locking up :-(
In-Reply-To: <E1LMhiD-0000Rp-B2@dilbert.ticketswitch.com>
References: <E1LMhiD-0000Rp-B2@dilbert.ticketswitch.com>
Message-ID: <alpine.BSF.2.00.0901131240330.16794@fledge.watson.org>


On Tue, 13 Jan 2009, Pete French wrote:

>> Features like WITNESS and INVARIANTS may change the timing of the kernel 
>> making certain race conditions less likely; I'd run with them for a bit and 
>> see if you can reproduce the hang with them present, as they will make 
>> debugging the problem a lot easier, if it's possible.
>
> Uh, the above *was* me reproducing the hang with them present ;-)) It quite 
> happily hangs with thoise things in the kernel - indeed the next hang was 
> immediately after I rebooted the machine. But even with WITNESS and 
> INVARIANTS and all the rest it does not drop to a debugger, it simply locks 
> up.
>
> That machine is currently turned off, but still has 7.1 installed. What 
> would you like me to try now ? I have a lockup I can reproduce pretty 
> reliably now (just wait and it will always lock up). I also found that my 
> other 7.1 box locks up fairly reliably when doing a buildworld.
>
> The only similarily between these two machines and the ones which dont lock 
> up is that these are serving DNS. The others don't. Note that all the 
> hardware is identical, as is the installed software and the configuration.

If you have BREAK_TO_DEBUGGER compiled into the kernel, then try pressing 
ctrl-alt-break on the console to see if you can drop into the debugger, or 
issue a serial break on a serial console.  For somewhat complicated reasons to 
explain, serial breaks are more effective at getting into the debugger, so are 
preferable -- also because you can more easily log output from the debugger.

If you are able to get into the debugger, the normal commands would be most 
helpful, especially if you can log the results:

   ps
   show lockedvnods
   show alllocks

Robert N M Watson
Computer Laboratory
University of Cambridge
From petefrench at ticketswitch.com  Tue Jan 13 05:43:54 2009
From: petefrench at ticketswitch.com (Pete French)
Date: Tue Jan 13 05:44:02 2009
Subject: Big problems with 7.1 locking up :-(
In-Reply-To: <1231842653.70382.8.camel@buffy.york.ac.uk>
Message-ID: <E1LMjYc-00010m-3z@dilbert.ticketswitch.com>

> Can you break into the debugger with Ctrl-Alt-Esc, or by sending a break
> over the serial line?

No, ctrl-alt-esc doesnt work, and there is no serial line on the machine (not
that I can access anyway)

-pete.
From petefrench at ticketswitch.com  Tue Jan 13 06:11:36 2009
From: petefrench at ticketswitch.com (Pete French)
Date: Tue Jan 13 06:11:44 2009
Subject: Big problems with 7.1 locking up :-(
In-Reply-To: <496C5AC2.90408@FreeBSD.org>
Message-ID: <E1LMjzP-0000L6-4A@dilbert.ticketswitch.com>

> Silly question but do you have powerd enabled on that server? If so,
> does disabling it help? Also do you have any of these in /etc/rc.conf
> (i.e., they are not the same as the default values in
> /etc/defaults/rc.conf):
> performance_cx_lowest="HIGH"    # Online CPU idle state
> performance_cpu_freq="NONE"     # Online CPU frequency
> economy_cx_lowest="HIGH"        # Offline CPU idle state
> economy_cpu_freq="NONE"         # Offline CPU frequency

No, none of those. My rc.conf is below. The only slightly unusual thing I
am doing is using lagg rather than the interfaces directly I guess, but
that has worked fine for ages.

-pete.


hostname="florentine.rattatosk"
cloned_interfaces="lagg0"
network_interfaces="lo0 bce0 bce1 lagg0"
ifconfig_bce0="up"
ifconfig_bce1="up"
ifconfig_lagg0="laggproto lacp laggport bce0 laggport bce1"

ipv4_addrs_lagg0="10.48.19.0/16 10.48.19.229/16 10.48.19.223/16 10.48.19.243/16 10.48.19.226/16 10
.48.19.224/16 10.48.19.227/16 10.48.19.239/16 10.48.19.225/16 10.48.19.230/16 10.48.19.232/16 10.4
8.19.228/16 10.48.19.235/16 10.48.19.244/16 10.48.19.245/16"

defaultrouter="10.48.0.9"

inetd_enable="YES"
sshd_enable="YES"

dhcpd_enable="YES"
dhcpd_ifaces="lagg0"
dhcpd_flags="-q"
dhcpd_conf="/usr/local/etc/dhcpd.conf"
dhcpd_withumask="022"

nfs_client_enable="YES"
nfs_server_enable="YES"
portmap_enable="YES"
rpcbind_enable="YES"

named_enable="YES"
pdns_enable="YES"
pdns_recursor_enable="NO"

mysql_enable="YES"

apache22_http_accept_enable="YES"
apache22_enable="YES"

ntpd_enable="YES"
ntpd_sync_on_start="YES"

exim_enable="YES"
exim_flags="-bd -q10m"
sendmail_enable="NONE"
sendmail_submit_enable="NO"
sendmail_outbound_enable="NO"
sendmail_msp_queue_enable="NO"
From sascha at holzleiter.name  Tue Jan 13 06:52:38 2009
From: sascha at holzleiter.name (Sascha Holzleiter)
Date: Tue Jan 13 06:52:45 2009
Subject: FreeBSD 7.1 Breaks re and rl Network Interface Drivers
In-Reply-To: <200901122010.37269.jkim@FreeBSD.org>
References: <8dfae1c10901070639x67945324jeeecfcac647d7976@mail.gmail.com>	<496B7C17.8010107@holzleiter.name>
	<200901122010.37269.jkim@FreeBSD.org>
Message-ID: <496CAB07.5020404@holzleiter.name>

Jung-uk Kim wrote:
> On Monday 12 January 2009 12:21 pm, Sascha Holzleiter wrote:
>> Hi,
>>
>> i see similar problems with a re card:
>>
>> re0@pci0:4:7:0:	class=0x020000 card=0x816710ec chip=0x816710ec
>> rev=0x10 hdr=0x00
>>      vendor     = 'Realtek Semiconductor'
>>      device     = 'RTL8169/8110 Family Gigabit Ethernet NIC'
>>      class      = network
>>      subclass   = ethernet
>>
>> After upgrading to 7.1-RELEASE (and also STABLE) the NIC doesn't
>> seem to receive any frames. I can see the DHCP Requests on the DHCP
>> Server but the DHCPOFFERS are never seen by the client with the re0
>> device. After setting promiscious mode on the interface (i.e. by
>> tcpdump -ni re0) the interface begins to work fine.
>>
>> I've attached a complete dmesg output, but i think the detection
>> works fine, here the short version:
>>
>> re0: <RealTek 8169SC/8110SC Single-chip Gigabit Ethernet> port
>> 0x9c00-0x9cff mem 0xdfdff000-0xdfdff0ff irq 20 at device 7.0 on
>> pci4 re0: Chip rev. 0x18000000
>> re0: MAC rev. 0x00000000
>> miibus0: <MII bus> on re0
>> rgephy0: <RTL8169S/8110S/8211B media interface> PHY 1 on miibus0
>> rgephy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX,
>> 1000baseT, 1000baseT-FDX, auto
>> re0: Ethernet address: 00:1a:92:35:29:fa
>> re0: [FILTER]
> 
> Please revert SVN r180519 (or CVS r1.95.2.22) and try again:
> 
> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/re/if_re.c.diff?r1=1.95.2.21;r2=1.95.2.22

Thanks! This fixed my problem. I now have DHCP and a running network 
interface again with a 7.1-STABLE and the reverted r180519 changes.
If you need to test another version for the changes in r180519 let me 
know and i'll test them on this machine.


Cheers,
   Sascha
From freebsd at optiksecurite.com  Tue Jan 13 07:15:47 2009
From: freebsd at optiksecurite.com (FreeBSD)
Date: Tue Jan 13 07:15:55 2009
Subject: FreeBSD 7.1 Breaks re and rl Network Interface Drivers
In-Reply-To: <20090113004018.GG46346@cdnetworks.co.kr>
References: <8dfae1c10901070639x67945324jeeecfcac647d7976@mail.gmail.com>
	<8dfae1c10901071550s69d99802p31ca7c775f3d6823@mail.gmail.com>
	<88527079.20090111192206@donpac.ru>
	<20090112011146.GC46346@cdnetworks.co.kr>
	<496BBFF6.7010300@optiksecurite.com>
	<20090113004018.GG46346@cdnetworks.co.kr>
Message-ID: <496CB0A2.2020103@optiksecurite.com>

Pyun YongHyeon a ?crit :
> On Mon, Jan 12, 2009 at 05:11:02PM -0500, FreeBSD wrote:
>  > Pyun YongHyeon a ?crit :
>  > >On Sun, Jan 11, 2009 at 07:22:06PM +0300, Eugene Gladchenko wrote:
>  > > > Walter,
>  > > > 
>  > > > Thursday, January 8, 2009, 2:50:40 AM, you wrote:
>  > > > 
>  > > > WV> Booting kernel.old, which is 7.0-RELEASE-p7 completely alleviates 
>  > > all
>  > > > WV> problems.  I believe this roundly confirms that this is a bug in the
>  > > > WV> 7.1-RELEASE re kernel drivers.
>  > > > 
>  > > > Does kern/130011 look similar? 
>  > > http://www.freebsd.org/cgi/query-pr.cgi?pr=130011
>  > >
>  > >Do you have RTL8168C controller? If not, it's not related with
>  > >Walter's issue as 7.0-RELEASE didn't have a support for RTL8168C.
>  > >
>  > > > 
>  > > > The re driver was really broken in 7.1-RC2 and the fix didn't get to 
>  > > 7.1-RELEASE.
>  > >
>  > >If you have re(4) issues, please provide more details such as
>  > >dmesg output, way to reproduce the issue etc.
>  > >
>  > 
>  > Hi,
>  > 
>  > I have the exact same card and the exact same problem as the PR you 
>  > mentionned.
>  > 
>  > re0@pci0:3:0:0: class=0x020000 card=0x02831028 chip=0x816810ec rev=0x02 
>  > hdr=0x00
>  >     vendor     = 'Realtek Semiconductor'
>  >     device     = 'RTL8168/8111 PCI-E Gigabit Ethernet NIC'
>  >     class      = network
>  >     subclass   = ethernet
>  > 
>  > 
>  > re0: <RealTek 8168/8168B/8168C/8168CP/8168D/8111B/8111C/8111CP PCIe 
>  > Gigabit Ethernet> port 0xd800-0xd8ff mem 
>  > 0xfeaff000-0xfeafffff,0xfdff0000-0xfdffffff irq 18 at device 0.0 on pci3
>  > re0: Chip rev. 0x3c000000
>  > re0: MAC rev. 0x00400000
>  > re0: PHY write failed
>  > re0: PHY write failed
>  > re0: MII without any phy!
>  > device_attach: re0 attach returned 6
>  > 
>  > I tried to compile a new kernel with the latest version of the 3 files 
>  > listed in the PR:
>  > src/sys/dev/re/if_re.c,v 1.147 2008/12/22 00:46:22 yongari
>  > src/sys/pci/if_rl.c,v 1.170.2.10 2009/01/12 04:10:40 yongari
>  > src/sys/pci/if_rlreg.h,v 1.67.2.16 2009/01/12 03:48:25 yongari
>  > 
> 
> You need lastest if_rl.c and if_rlreg.h as well as if_re.c.
> 

That's exactly what I tried. Look at the 3 revision of the specified 
files. I even tried with a if_rl.c from the 22/12/08 but got the same 
problem.

Thanks for your quick reply.

>  > but I get the following error in buildworld:
> 
> [...]
> 

From petefrench at ticketswitch.com  Tue Jan 13 07:17:45 2009
From: petefrench at ticketswitch.com (Pete French)
Date: Tue Jan 13 07:17:53 2009
Subject: Big problems with 7.1 locking up :-(
In-Reply-To: <b41c75520901130151uf27e220lecdf2937d94a7410@mail.gmail.com>
Message-ID: <E1LMl1D-0000cm-9v@dilbert.ticketswitch.com>

> I can't  (fortunately) make it lock up. I have a DL360 G5 which is
> unused atm. and can test on it if needed.

Would it be possible to install that under amd64 and hammer it with
DNS requests ? I have been trying to think what the difference might be
between my webservers and the machines which are freezing, and the opnly
one I an come up with is UDP traffic as the locking machines are serving
DNS and also NFS.

-pete.
,.
From dimitry at andric.com  Tue Jan 13 07:27:39 2009
From: dimitry at andric.com (Dimitry Andric)
Date: Tue Jan 13 07:27:46 2009
Subject: FreeBSD 7.1 Breaks re and rl Network Interface Drivers
In-Reply-To: <20090113050223.GH46346@cdnetworks.co.kr>
References: <8dfae1c10901070639x67945324jeeecfcac647d7976@mail.gmail.com>
	<8dfae1c10901071550s69d99802p31ca7c775f3d6823@mail.gmail.com>
	<88527079.20090111192206@donpac.ru>
	<20090112011146.GC46346@cdnetworks.co.kr>
	<64114.83.221.215.168.1231741940.squirrel@83.221.215.168>
	<20090112064121.GF46346@cdnetworks.co.kr>
	<496B71D3.5050203@andric.com>
	<20090113050223.GH46346@cdnetworks.co.kr>
Message-ID: <496CB2E7.2060902@andric.com>

On 2009-01-13 06:02, Pyun YongHyeon wrote:
>  > I'm also having problems with re's, in my case the interfaces take about
>  > 10 seconds to come up, if they come up at all.  After the interfaces are
>  > up, half the time no packets go out at all.  Usually it helps to bring
>  > them down via the console, wait about 10 seconds, and then bring them up
>  > again...
> It looks like that RTL8169SC users see regression and I vaguely
> remember a couple of issues on RTL8169SC. As Jung-uk said in other
> post, would yoy try reverting r180519?

Reverting r180519 seems to solve the problem of not being able to send
any packets.  It does not solve the other problem, which is that the
interfaces can take a very long time to come up at boot time, e.g:

  Setting hostuuid: 3ee65237-8025-11dc-9ab5-003018a6f1a8.
  Setting hostid: 0xaaedab9a.
  Mounting local file systems:.
  Setting hostname: tensor.andric.com.
[... pauses for 10 seconds here ...]
  re0: link state changed to DOWN
  re1: link state changed to DOWN
  lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
	  inet6 ::1 prefixlen 128
	  inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4
	  inet 127.0.0.1 netmask 0xff000000
  re0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
	  options=389b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_UCAST,WOL_MCAST,WOL_MAGIC>
	  ether 00:30:18:a6:f1:a8
	  inet6 fe80::230:18ff:fea6:f1a8%re0 prefixlen 64 tentative scopeid 0x1
	  inet 87.251.56.140 netmask 0xffffffc0 broadcast 87.251.56.191
	  media: Ethernet autoselect (none)
	  status: no carrier
  re1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
	  options=389b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_UCAST,WOL_MCAST,WOL_MAGIC>
	  ether 00:30:18:a6:f1:a9
	  inet6 fe80::230:18ff:fea6:f1a9%re1 prefixlen 64 tentative scopeid 0x2
	  inet 192.168.0.1 netmask 0xffffff00 broadcast 192.168.0.255
	  media: Ethernet autoselect (none)
	  status: no carrier
[...]

(note also the "no carrier" just after upping those interfaces)


> If that have no effect would
> you try attached patch?

Apply this patch sometimes speeds up the interfaces going up at boot
time, sometimes it doesn't, I'd say about 50/50.  It doesn't solve the
problem of not being able to send any packets.


>  > And just FYI, r187080-r187083 that you recently committed (MFCs of
>  > r184240-184243, r184245, 185575 and r186390), don't seem to change
>  > anything for this situation. :(
> Those MFC are for rl(4), not re(4) so you should see no behavioural
> changes in re(4).

Sorry about that, I always keep mixing up re(4) and rl(4)...
From nathan at datanode.com  Tue Jan 13 07:31:29 2009
From: nathan at datanode.com (Nathan Way)
Date: Tue Jan 13 07:31:36 2009
Subject: Big problems with 7.1 locking up :-(
In-Reply-To: <alpine.BSF.2.00.0901131240330.16794@fledge.watson.org>
References: <E1LMhiD-0000Rp-B2@dilbert.ticketswitch.com>
	<alpine.BSF.2.00.0901131240330.16794@fledge.watson.org>
Message-ID: <A3CFCCC2DBB94E478E7A722747EECD970A56FF@dni-mail.datanode.com>

I also am experiencing lock-ups on a server recently upgraded from
7.0-RELEASE to 7.1-STABLE.  This server is a Supermicro 6022 dual-Xeon
box running a GENERIC i386 SMP kernel.  Since upgrading to 7.1-STABLE it
has started locking up daily.  I see similar symptoms that Pete is
seeing - no ping response, no keyboard response, no video output on a
very lightly loaded server.  

I have a test machine with duplicate hardware to the one locking up that
I just finished installing 7.1-STABLE on but so far it hasn't locked up.
Coincidentally my locking machine is also a DNS server but I have not
enabled DNS on my test machine yet.

Since the locking server is remote to me, I need to downgrade it to 7.0
to get it stable again.  Once I finish that process, I can provide
remote access to the 7.1-STABLE machine in my office if anyone would
like to test with it.

From rwatson at FreeBSD.org  Tue Jan 13 08:10:50 2009
From: rwatson at FreeBSD.org (Robert Watson)
Date: Tue Jan 13 08:11:04 2009
Subject: Big problems with 7.1 locking up :-(
In-Reply-To: <E1LMl1D-0000cm-9v@dilbert.ticketswitch.com>
References: <E1LMl1D-0000cm-9v@dilbert.ticketswitch.com>
Message-ID: <alpine.BSF.2.00.0901131607580.95856@fledge.watson.org>


On Tue, 13 Jan 2009, Pete French wrote:

>> I can't (fortunately) make it lock up. I have a DL360 G5 which is unused 
>> atm. and can test on it if needed.
>
> Would it be possible to install that under amd64 and hammer it with DNS 
> requests ? I have been trying to think what the difference might be between 
> my webservers and the machines which are freezing, and the opnly one I an 
> come up with is UDP traffic as the locking machines are serving DNS and also 
> NFS.

There are significant changes in UDP locking between 7.0 and 7.1, so it could 
be that we're looking at a regression there.  If you're able to reproduce this 
reliably, it might well be worth doing a little search-and-replace in 
udp_usrreq.c along the following lines:

   INP_RLOCK_ASSERT -> INP_WLOCK_ASSERT
   INP_RLOCK -> INP_WLOCK
   INP_RUNLOCK -> INP_WUNLOCK

However, before making these changes for debugging purposes, make sure it's 
100% reproduceable without them in the configuration so that we don't find 
ourselves barking up the wrong tree.  Normally deadlocks along these lines 
*do* allow breaking into the debugger from a serial console, but since there 
are significant changes here in 7.1 it is worth trying to see if this might be 
related.

Robert N M Watson
Computer Laboratory
University of Cambridge
From gavin at FreeBSD.org  Tue Jan 13 08:33:59 2009
From: gavin at FreeBSD.org (Gavin Atkinson)
Date: Tue Jan 13 08:34:06 2009
Subject: FreeBSD 7.0 kernel panic
In-Reply-To: <54540134.20090112212757@gmail.com>
References: <54540134.20090112212757@gmail.com>
Message-ID: <1231864430.70382.26.camel@buffy.york.ac.uk>

On Mon, 2009-01-12 at 21:27 +0300, L1NYX01D@GOOGLEMAIL.COM wrote:
> Hello, FreeBSD-stable.
> 
> Last week I have a lot of kernel panics like:

Firstly: are these new panics on a system that has been reliable until
now, or has something changed on the system recently (hardware change,
different software in use, increased load, etc)?  Is there any way you
can reliably reproduce this?  And is the panic message and backtrace
always the same?

> > Fatal trap 12: page fault while in kernel mode
> > cpuid = 0; apic id = 00
> > fault virtual address   = 0x9
> > fault code              = supervisor read, page not present
> > instruction pointer     = 0x20:0xc079f1af
> > stack pointer           = 0x28:0xe5697c80
> > frame pointer           = 0x28:0xe5697cbc
> > code segment            = base 0x0, limit 0xfffff, type 0x1b
> >                         = DPL 0, pres 1, def32 1, gran 1
> > processor eflags        = resume, IOPL = 0
> > current process         = 14 (swi4: clock)
> > trap number             = 12
> > panic: page fault
> > cpuid = 0
> > Uptime: 51m49s
> > Physical memory: 2032 MB
> > Dumping 177 MB: 162 146 130 114 98 82 66 50 34 18 2
> >
> > #0  doadump () at pcpu.h:195
> > 195             __asm __volatile("movl %%fs:0,%0" : "=r" (td));
> > (kgdb) bt
> > #0  doadump () at pcpu.h:195
> > #1  0xc078d1b7 in boot (howto=260) at
> > /usr/src/sys/kern/kern_shutdown.c:409
> > #2  0xc078d479 in panic (fmt=Variable "fmt" is not available.
> > ) at /usr/src/sys/kern/kern_shutdown.c:563
> > #3  0xc0a0eaac in trap_fatal (frame=0xe5697c40, eva=9) at /usr/src/sys/i386/i386/trap.c:899
> > #4  0xc0a0f42f in trap (frame=0xe5697c40) at /usr/src/sys/i386/i386/trap.c:280
> > #5  0xc09f565b in calltrap () at
> > /usr/src/sys/i386/i386/exception.s:139
> > #6  0xc079f1af in softclock (dummy=0x0) at
> > /usr/src/sys/kern/kern_timeout.c:202
> > #7  0xc076f31b in ithread_loop (arg=0xc5101250) at
> > /usr/src/sys/kern/kern_intr.c:1036
> > #8  0xc076c119 in fork_exit (callout=0xc076f170 <ithread_loop>, arg=0xc5101250, frame=0xe5697d38)
> >     at /usr/src/sys/kern/kern_fork.c:781
> > #9  0xc09f56d0 in fork_trampoline () at
> > /usr/src/sys/i386/i386/exception.s:205
> > (kgdb)
> 
> What I should do?

In kgdb, enter "frame 6" then "list".  The output should show where in
the code this occurred.  You can then print any variables that look
interesting by:

p c
p c->ctime

Gavin
From kensmith at cse.Buffalo.EDU  Tue Jan 13 10:56:44 2009
From: kensmith at cse.Buffalo.EDU (Ken Smith)
Date: Tue Jan 13 10:56:52 2009
Subject: Big problems with 7.1 locking up :-(
In-Reply-To: <496BA9AE.10801@max.af.czu.cz>
References: <E1LL6dg-0007CN-DI@dilbert.ticketswitch.com>
	<042FE04A-2F8D-47DD-8454-7BBA3791D7A8@inoc.net>
	<p06240802c58db5953598@[128.113.24.47]>
	<alpine.BSF.2.00.0901121453200.16794@fledge.watson.org>
	<p06240808c5911644dd11@[128.113.24.47]> <496BA9AE.10801@max.af.czu.cz>
Message-ID: <1231872993.16701.9.camel@bauer.cse.buffalo.edu>

On Mon, 2009-01-12 at 21:35 +0100, Tomas Randa wrote:
> I have similar problems. The last "good" kernel I have from stable 
> brach, october the 8. Then in next upgrade, I saw big problems with 
> performance.
> I tried ULE, 4BSD etc, but nothing helps, only downgrading system back.
> 
> Now I am trying 7.1-p1 and problems are here again. Mysql is waiting a 
> lot of time with status "waiting for opening table" or "waiting for 
> close tables"
> 
> I have 32bit FreeBSD with PAE, 1x xeon 5420, supermicro motherboard, 
> areca SATA controller. Could not be problem in "da" device for example?
> 
> Thanks Tomas Randa

Could you give r186860 a try?  It is an MFC into stable/7 so if the
machine in question is something you can experiment with just updating
to stable/7 would take care of it.  Otherwise if you could just manually
apply the patch to a 7.1 source tree and do a test build of the kernel
that would also do it.

I'm not experiencing lockups but this patch helped a lot on a machine I
have with a particular disk I/O pattern that resulted in extremely poor
performance with 7.1-RELEASE.  This patch brought it back to its normal
performance level.

Thanks.

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090113/a4d13c2a/attachment.pgp
From korvus at comcast.net  Tue Jan 13 11:27:28 2009
From: korvus at comcast.net (Steve Polyack)
Date: Tue Jan 13 11:27:35 2009
Subject: amr driver changes in FreeBSD 7.1-RELEASE
Message-ID: <496CEB13.5040806@comcast.net>

Hello,

We have a Dell PowerEdge 1850 server.  It contains two PERC4 RAID 
controllers.  One is a PERC4e/Si, and the other is a PERC4/DC.  Right 
now we are running FreeBSD 6.3-RELEASE, with a 36GB RAID-1 on the 
PERC4e/Si (amr0), and both a 1TB RAID5 and a 136GB RAID1 on the 
PERC4/DC(amr1). Both adapters are running the latest firmware revision.

When we boot FreeBSD7.1 install media, the amr driver fails to detect 
any volumes (disks) attached to amr0, the PERC4e/Si.  However, it picks 
up the attached disks on the PERC4/DC just fine.  However, if I boot 
7.0-RELEASE install media, it picks up all of the attached volumes, 
leading me to believe the issue is due to changes in the amr driver 
between 7.0 and 7.1.  During the 7.1 boot process, before probing disks, 
we see the message "amr0: adapter is busy" show up twice.  This also 
does not occur on the 6.3, 6.4, or 7.0 releases.

We also have another PE1850 with a very similar configuration, except 
the two PERCs get probed in a different order, and it detects all of the 
attached volumes without any issues.

Any suggestions? These are semi-critical systems, so we aren't always 
able to test things like this.  But, we can schedule downtime once or 
twice a week if necessary.

-Steve Polyack
From redcrash at gmail.com  Tue Jan 13 11:28:57 2009
From: redcrash at gmail.com (Harald Servat)
Date: Tue Jan 13 11:29:06 2009
Subject: lenovo t400 does not start 7.1
Message-ID: <d825e0270901131057o12d5e320p6a4182bc9dbf3fe0@mail.gmail.com>

Hello,

  I downloaded FreeBSD 7.1 (DVD iso image) for amd64 architecture (with
correct SHA256 checksum), but I'm unable to start the system (Lenovo T400).

  The boot process starts fine, the BTX messages appear, the 7-option menu
also appears, but when I hit enter (or when I choose start without ACPI or
start in safe mode) the \ symbols starts spinning for a while and then
freezes.

  I also tried with the 7.1-amd64-CD1, 7.1-i386-CD1 and a snapshot of
8.0-CURRENT dated from December. And the result is the same for all of them.

  Does anyone have any idea on what can be happening? Or at least, how can I
gather more information about this issue?

Thank you.
-- 
_________________________________________________________________
Empty your memory,
with a free()...
like a pointer!

If you cast a pointer to an integer,
it becomes an integer,
if you cast a pointer to a struct,
it becomes a struct.

The pointer can crash...,
and can overflow.

Be a pointer my friend...
From minimarmot at gmail.com  Tue Jan 13 11:59:47 2009
From: minimarmot at gmail.com (Ben Kaduk)
Date: Tue Jan 13 11:59:55 2009
Subject: lenovo t400 does not start 7.1
In-Reply-To: <d825e0270901131057o12d5e320p6a4182bc9dbf3fe0@mail.gmail.com>
References: <d825e0270901131057o12d5e320p6a4182bc9dbf3fe0@mail.gmail.com>
Message-ID: <47d0403c0901131159v1076fc6am45b2ef3b7f6ed934@mail.gmail.com>

On Tue, Jan 13, 2009 at 1:57 PM, Harald Servat <redcrash@gmail.com> wrote:
> Hello,
>
>  I downloaded FreeBSD 7.1 (DVD iso image) for amd64 architecture (with
> correct SHA256 checksum), but I'm unable to start the system (Lenovo T400).
>
>  The boot process starts fine, the BTX messages appear, the 7-option menu
> also appears, but when I hit enter (or when I choose start without ACPI or
> start in safe mode) the \ symbols starts spinning for a while and then
> freezes.

Have you tried an ISO for FreeBSD-CURRENT?

I also have a T400, and definitely had FreeBSD running on it for a while,
but I don't remember if it was 7 or current.

-Ben Kaduk
From hiryu at neo-zeon.de  Tue Jan 13 12:18:43 2009
From: hiryu at neo-zeon.de (Cameron)
Date: Tue Jan 13 12:18:50 2009
Subject: amr driver changes in FreeBSD 7.1-RELEASE
In-Reply-To: <496CEB13.5040806@comcast.net>
References: <496CEB13.5040806@comcast.net>
Message-ID: <200901131201.28226.hiryu@neo-zeon.de>

Hello,

This seems related to a problem I had with a 7.1-PRERELEASE (I have since 
upgraded to 7.1-RELEASE, but haven't not tested if the problem is still 
there).

If I compiled the kernel with only the amr driver, it would not see my raid 
volume. If I enabled a separate scsi driver (I think it was some LSI Logic 
scsi driver) in addition to amr,  the amr driver would work fine. I wish I 
could give some exact details (like the name of the other scsi driver), but 
this is on my home machine, and I'm currently at work.

While a generic 7.1-PRERELEASE kernel had both of these compiled in (of 
course), and worked fine for me, I suspect our problems are related.

I have an LSI Logic 150-4 SATA raid controller.

-Cameron

n Tuesday 13 January 2009 11:27:15 am Steve Polyack wrote:
> Hello,
>
> We have a Dell PowerEdge 1850 server.  It contains two PERC4 RAID
> controllers.  One is a PERC4e/Si, and the other is a PERC4/DC.  Right
> now we are running FreeBSD 6.3-RELEASE, with a 36GB RAID-1 on the
> PERC4e/Si (amr0), and both a 1TB RAID5 and a 136GB RAID1 on the
> PERC4/DC(amr1). Both adapters are running the latest firmware revision.
>
> When we boot FreeBSD7.1 install media, the amr driver fails to detect
> any volumes (disks) attached to amr0, the PERC4e/Si.  However, it picks
> up the attached disks on the PERC4/DC just fine.  However, if I boot
> 7.0-RELEASE install media, it picks up all of the attached volumes,
> leading me to believe the issue is due to changes in the amr driver
> between 7.0 and 7.1.  During the 7.1 boot process, before probing disks,
> we see the message "amr0: adapter is busy" show up twice.  This also
> does not occur on the 6.3, 6.4, or 7.0 releases.
>
> We also have another PE1850 with a very similar configuration, except
> the two PERCs get probed in a different order, and it detects all of the
> attached volumes without any issues.
>
> Any suggestions? These are semi-critical systems, so we aren't always
> able to test things like this.  But, we can schedule downtime once or
> twice a week if necessary.
>
> -Steve Polyack
> _______________________________________________
> freebsd-hardware@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hardware
> To unsubscribe, send any mail to "freebsd-hardware-unsubscribe@freebsd.org"


From gonzo at bluezbox.com  Tue Jan 13 12:25:00 2009
From: gonzo at bluezbox.com (Oleksandr Tymoshenko)
Date: Tue Jan 13 12:25:08 2009
Subject: lenovo t400 does not start 7.1
In-Reply-To: <d825e0270901131057o12d5e320p6a4182bc9dbf3fe0@mail.gmail.com>
References: <d825e0270901131057o12d5e320p6a4182bc9dbf3fe0@mail.gmail.com>
Message-ID: <496CEFBE.8030007@bluezbox.com>

Harald Servat wrote:
> Hello,
> 
>   I downloaded FreeBSD 7.1 (DVD iso image) for amd64 architecture (with
> correct SHA256 checksum), but I'm unable to start the system (Lenovo T400).
> 
>   The boot process starts fine, the BTX messages appear, the 7-option menu
> also appears, but when I hit enter (or when I choose start without ACPI or
> start in safe mode) the \ symbols starts spinning for a while and then
> freezes.
> 
>   I also tried with the 7.1-amd64-CD1, 7.1-i386-CD1 and a snapshot of
> 8.0-CURRENT dated from December. And the result is the same for all of them.
> 
>   Does anyone have any idea on what can be happening? Or at least, how can I
> gather more information about this issue?
	Not sure about install CDs but I tried all these systems on my t400.
I installed 7.0 then upgraded  it to 7.1 and when it turned out that
atheros is not 100% supported by it I upgraded to CURRENT. (I used cvsup
for upgrades). What is your HW configuration?

From redcrash at gmail.com  Tue Jan 13 12:40:43 2009
From: redcrash at gmail.com (Harald Servat)
Date: Tue Jan 13 12:40:50 2009
Subject: lenovo t400 does not start 7.1
In-Reply-To: <496CEFBE.8030007@bluezbox.com>
References: <d825e0270901131057o12d5e320p6a4182bc9dbf3fe0@mail.gmail.com>
	<496CEFBE.8030007@bluezbox.com>
Message-ID: <d825e0270901131240o37d58120p58244107cd6bf7fe@mail.gmail.com>

On Tue, Jan 13, 2009 at 8:47 PM, Oleksandr Tymoshenko <gonzo@bluezbox.com>wrote:

> Harald Servat wrote:
>
>> Hello,
>>
>>  I downloaded FreeBSD 7.1 (DVD iso image) for amd64 architecture (with
>> correct SHA256 checksum), but I'm unable to start the system (Lenovo
>> T400).
>>
>>  The boot process starts fine, the BTX messages appear, the 7-option menu
>> also appears, but when I hit enter (or when I choose start without ACPI or
>> start in safe mode) the \ symbols starts spinning for a while and then
>> freezes.
>>
>>  I also tried with the 7.1-amd64-CD1, 7.1-i386-CD1 and a snapshot of
>> 8.0-CURRENT dated from December. And the result is the same for all of
>> them.
>>
>>  Does anyone have any idea on what can be happening? Or at least, how can
>> I
>> gather more information about this issue?
>>
>        Not sure about install CDs but I tried all these systems on my t400.
> I installed 7.0 then upgraded  it to 7.1 and when it turned out that
> atheros is not 100% supported by it I upgraded to CURRENT. (I used cvsup
> for upgrades). What is your HW configuration?
>
>
Ok, thanks... I'll give a try to 7.0, and let's see if it works.


-- 
_________________________________________________________________
Empty your memory,
with a free()...
like a pointer!

If you cast a pointer to an integer,
it becomes an integer,
if you cast a pointer to a struct,
it becomes a struct.

The pointer can crash...,
and can overflow.

Be a pointer my friend...
From redcrash at gmail.com  Tue Jan 13 12:42:59 2009
From: redcrash at gmail.com (Harald Servat)
Date: Tue Jan 13 12:43:07 2009
Subject: lenovo t400 does not start 7.1
In-Reply-To: <47d0403c0901131159v1076fc6am45b2ef3b7f6ed934@mail.gmail.com>
References: <d825e0270901131057o12d5e320p6a4182bc9dbf3fe0@mail.gmail.com>
	<47d0403c0901131159v1076fc6am45b2ef3b7f6ed934@mail.gmail.com>
Message-ID: <d825e0270901131242h7588c46avae89ae9d3aea51f5@mail.gmail.com>

On Tue, Jan 13, 2009 at 8:59 PM, Ben Kaduk <minimarmot@gmail.com> wrote:

> On Tue, Jan 13, 2009 at 1:57 PM, Harald Servat <redcrash@gmail.com> wrote:
> > Hello,
> >
> >  I downloaded FreeBSD 7.1 (DVD iso image) for amd64 architecture (with
> > correct SHA256 checksum), but I'm unable to start the system (Lenovo
> T400).
> >
> >  The boot process starts fine, the BTX messages appear, the 7-option menu
> > also appears, but when I hit enter (or when I choose start without ACPI
> or
> > start in safe mode) the \ symbols starts spinning for a while and then
> > freezes.
>
> Have you tried an ISO for FreeBSD-CURRENT?
>
> I also have a T400, and definitely had FreeBSD running on it for a while,
> but I don't remember if it was 7 or current.
>
> -Ben Kaduk
>

I tried 8.0-CURRENT snapshot from December with no luck. I'll give 7.0 a try
(Oleksandr also suggested the same).

Thanks!


-- 
_________________________________________________________________
Empty your memory,
with a free()...
like a pointer!

If you cast a pointer to an integer,
it becomes an integer,
if you cast a pointer to a struct,
it becomes a struct.

The pointer can crash...,
and can overflow.

Be a pointer my friend...
From redcrash at gmail.com  Tue Jan 13 14:04:16 2009
From: redcrash at gmail.com (Harald Servat)
Date: Tue Jan 13 14:04:23 2009
Subject: lenovo t400 does not start 7.1
In-Reply-To: <d825e0270901131240o37d58120p58244107cd6bf7fe@mail.gmail.com>
References: <d825e0270901131057o12d5e320p6a4182bc9dbf3fe0@mail.gmail.com>
	<496CEFBE.8030007@bluezbox.com>
	<d825e0270901131240o37d58120p58244107cd6bf7fe@mail.gmail.com>
Message-ID: <d825e0270901131404r7dae53a5i13e091faa55c51a3@mail.gmail.com>

On Tue, Jan 13, 2009 at 9:40 PM, Harald Servat <redcrash@gmail.com> wrote:

>
>
> On Tue, Jan 13, 2009 at 8:47 PM, Oleksandr Tymoshenko <gonzo@bluezbox.com>wrote:
>
>> Harald Servat wrote:
>>
>>> Hello,
>>>
>>>  I downloaded FreeBSD 7.1 (DVD iso image) for amd64 architecture (with
>>> correct SHA256 checksum), but I'm unable to start the system (Lenovo
>>> T400).
>>>
>>>  The boot process starts fine, the BTX messages appear, the 7-option menu
>>> also appears, but when I hit enter (or when I choose start without ACPI
>>> or
>>> start in safe mode) the \ symbols starts spinning for a while and then
>>> freezes.
>>>
>>>  I also tried with the 7.1-amd64-CD1, 7.1-i386-CD1 and a snapshot of
>>> 8.0-CURRENT dated from December. And the result is the same for all of
>>> them.
>>>
>>>  Does anyone have any idea on what can be happening? Or at least, how can
>>> I
>>> gather more information about this issue?
>>>
>>        Not sure about install CDs but I tried all these systems on my
>> t400.
>> I installed 7.0 then upgraded  it to 7.1 and when it turned out that
>> atheros is not 100% supported by it I upgraded to CURRENT. (I used cvsup
>> for upgrades). What is your HW configuration?
>>
>>
> Ok, thanks... I'll give a try to 7.0, and let's see if it works.
>
>
Uhm... FreeBSD 7.0 i386 CD1 behaves in the same manner. It frozes when
spinning the backslash symbol.

The BIOS reports 4GB of RAM and SATA disk configured in AHCI mode. Should I
look for something unusual? and how?

Thank you.
From jkim at FreeBSD.org  Tue Jan 13 15:06:16 2009
From: jkim at FreeBSD.org (Jung-uk Kim)
Date: Tue Jan 13 15:06:24 2009
Subject: FreeBSD 7.1 Breaks re and rl Network Interface Drivers
In-Reply-To: <496CB2E7.2060902@andric.com>
References: <8dfae1c10901070639x67945324jeeecfcac647d7976@mail.gmail.com>
	<20090113050223.GH46346@cdnetworks.co.kr>
	<496CB2E7.2060902@andric.com>
Message-ID: <200901131806.02868.jkim@FreeBSD.org>

On Tuesday 13 January 2009 10:27 am, Dimitry Andric wrote:
> Reverting r180519 seems to solve the problem of not being able to
> send any packets.  It does not solve the other problem, which is
> that the interfaces can take a very long time to come up at boot
> time, e.g:
>
>   Setting hostuuid: 3ee65237-8025-11dc-9ab5-003018a6f1a8.
>   Setting hostid: 0xaaedab9a.
>   Mounting local file systems:.
>   Setting hostname: tensor.andric.com.
> [... pauses for 10 seconds here ...]
>   re0: link state changed to DOWN
>   re1: link state changed to DOWN
>   lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
> 	  inet6 ::1 prefixlen 128
> 	  inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4
> 	  inet 127.0.0.1 netmask 0xff000000
>   re0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0
> mtu 1500
> options=389b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_
>UCAST,WOL_MCAST,WOL_MAGIC> ether 00:30:18:a6:f1:a8
> 	  inet6 fe80::230:18ff:fea6:f1a8%re0 prefixlen 64 tentative
> scopeid 0x1 inet 87.251.56.140 netmask 0xffffffc0 broadcast
> 87.251.56.191 media: Ethernet autoselect (none)
> 	  status: no carrier
>   re1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0
> mtu 1500
> options=389b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_
>UCAST,WOL_MCAST,WOL_MAGIC> ether 00:30:18:a6:f1:a9
> 	  inet6 fe80::230:18ff:fea6:f1a9%re1 prefixlen 64 tentative
> scopeid 0x2 inet 192.168.0.1 netmask 0xffffff00 broadcast
> 192.168.0.255 media: Ethernet autoselect (none)
> 	  status: no carrier
> [...]
>
> (note also the "no carrier" just after upping those interfaces)

[...]

Can you try one of the following patches?

-CURRENT:	http://people.freebsd.org/~jkim/re/re.current.diff
-STABLE:	http://people.freebsd.org/~jkim/re/re.stable.diff

These patches contain all patches suggested by me and yongari and an 
additional patch, which may (or may not) decrease the initial setup 
time.

Jung-uk Kim
From vibarus at googlemail.com  Tue Jan 13 15:57:35 2009
From: vibarus at googlemail.com (Vincent Barus)
Date: Tue Jan 13 15:57:42 2009
Subject: CFT: ath hal src switchover
In-Reply-To: <alpine.BSF.2.00.0901082219000.1315@baba.farley.org>
References: <49665E35.1050301@errno.com>
	<alpine.BSF.2.00.0901082219000.1315@baba.farley.org>
Message-ID: <e4207650901131524p55a6d2at29466ea9552fb93b@mail.gmail.com>

On Fri, Jan 9, 2009 at 5:32 AM, Sean C. Farley <scf@freebsd.org> wrote:
> On Thu, 8 Jan 2009, Sam Leffler wrote:
>
>> I've brought the hal source code back to RELENG_7 but not connected it to
>> the build and/or driver.  I want folks to test this before I commit those
>> changes.  To do this you must have an up to date RELENG_7 code base and then
>> apply this patch:
>>
>> http://people.freebsd.org/~sam/ath_hal-releng7.patch
>
> *snip*
>
>> Please report any issues to this mailing list.
>
> No problems for my Netgear WPN511.  It works well at home.
>
> Now, if I just could figure out why the recent Aruba update at work is
> preventing me from authenticating with it, I would be happy.  This is not
> related to the MFC of the code.  iPhones and MacOSX 10.4 (but not 10.5) are
> also having problems.  Windows works.
>
> Sean
> --
> scf@FreeBSD.org
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
>


Hi,
today I tried to get a (samsung nc10 ath) nic working. The patch
failed to edit this three files:

sys/modules/ath_rate_onoe/Makefile
sys/modules/ath_rate_sample/Makefile
sys/modules/ath_rate_amrr/Makefile

I emptied them manually and ran a buildworld/kernel/etc on a clean 7.1
stable but i get a error message while booting:

ath0: unable to attach hardware; HAL status 13

After that I csuped the latest stable srcs, applied
hal-20081015-sanitized.tgz and run the complete buildprocess again.
The same error Message occurs.

Is there any trick to get the samsungs ath card running?

regards,

Vincent

Copyright (c) 1992-2009 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
	The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 7.1-STABLE #0: Tue Jan 13 21:21:53 CET 2009
    root@:/usr/obj/usr/src/sys/BOOKLI
Preloaded elf kernel "/boot/kernel/kernel" at 0xc0a99000.
Preloaded elf module "/boot/kernel/acpi.ko" at 0xc0a99250.
Calibrating clock(s) ... i8254 clock: 1193244 Hz
CLK_USE_I8254_CALIBRATION not specified - using default frequency
Timecounter "i8254" frequency 1193182 Hz quality 0
Calibrating TSC clock ... TSC clock: 1595994372 Hz
CPU: Intel(R) Atom(TM) CPU N270   @ 1.60GHz (1595.99-MHz 686-class CPU)
  Origin = "GenuineIntel"  Id = 0x106c2  Stepping = 2
  Features=0xbfe9fbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
  Features2=0x40c39d<SSE3,DTES64,MON,DS_CPL,EST,TM2,SSSE3,xTPR,PDCM,<b22>>
  AMD Features2=0x1<LAHF>
  Logical CPUs per core: 2

1st-level instruction cache: 32 KB, 8-way set associative, 64 byte line size
L2 cache: 512 kbytes, 16-way associative, 64 bytes/line
real memory  = 1064108032 (1014 MB)
Physical memory chunk(s):
0x0000000000001000 - 0x000000000009efff, 647168 bytes (158 pages)
0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages)
0x0000000000c25000 - 0x000000003e4b0fff, 1032372224 bytes (252044 pages)
avail memory = 1031852032 (984 MB)
Table 'FACP' at 0x3f6e1bd2
Table 'APIC' at 0x3f6e1cc6
MADT: Found table at 0x3f6e1cc6
MP Configuration Table version 1.4 found at 0xc009fc71
APIC: Using the MADT enumerator.
MADT: Found CPU APIC ID 0 ACPI ID 0: enabled
SMP: Added CPU 0 (AP)
MADT: Found CPU APIC ID 1 ACPI ID 1: enabled
SMP: Added CPU 1 (AP)
ACPI APIC Table: <INTEL  CALISTGA>
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
 cpu0 (BSP): APIC ID:  0
 cpu1 (AP): APIC ID:  1
bios32: Found BIOS32 Service Directory header at 0xc00f7150
bios32: Entry = 0xfd5f0 (c00fd5f0)  Rev = 0  Len = 1
pcibios: PCI BIOS entry at 0xfd5f0+0x275
pnpbios: Found PnP BIOS data at 0xc00f71f0
pnpbios: Entry = f0000:b8d8  Rev = 1.0
Other BIOS signatures found:
APIC: CPU 0 has ACPI ID 0
APIC: CPU 1 has ACPI ID 1
ULE: setup cpu group 0
ULE: setup cpu 0
ULE: adding cpu 0 to group 0: cpus 1 mask 0x1
ULE: setup cpu 1
ULE: adding cpu 1 to group 0: cpus 2 mask 0x3
ACPI: RSDP @ 0x0xf71a0/0x0024 (v  2 PTLTD )
ACPI: XSDT @ 0x0x3f6db94a/0x0084 (v  1 SECCSD LH43STAR 0x06040000  LTP
0x00000000)
ACPI: FACP @ 0x0x3f6e1bd2/0x00F4 (v  3 INTEL  CALISTGA 0x06040000 ALAN
0x00000001)
ACPI: DSDT @ 0x0x3f6dd5f2/0x456C (v  1 INTEL  CALISTGA 0x06040000 INTL
0x20050624)
ACPI: FACS @ 0x0x3f6e2fc0/0x0040
ACPI: APIC @ 0x0x3f6e1cc6/0x0068 (v  1 INTEL  CALISTGA 0x06040000 LOHR
0x0000005A)
ACPI: HPET @ 0x0x3f6e1d2e/0x0038 (v  1 INTEL  CALISTGA 0x06040000 LOHR
0x0000005A)
ACPI: MCFG @ 0x0x3f6e1d66/0x003C (v  1 INTEL  CALISTGA 0x06040000 LOHR
0x0000005A)
ACPI: TCPA @ 0x0x3f6e1da2/0x0032 (v  1 PTLTD  CALISTGA 0x06040000  PTL
0x00000001)
ACPI: TMOR @ 0x0x3f6e1dd4/0x0026 (v  1 PTLTD           0x06040000 PTL
0x00000003)
ACPI: APIC @ 0x0x3f6e1dfa/0x0068 (v  1 PTLTD  	 APIC   0x06040000  LTP
0x00000000)
ACPI: BOOT @ 0x0x3f6e1e62/0x0028 (v  1 PTLTD  $SBFTBL$ 0x06040000  LTP
0x00000001)
ACPI: SLIC @ 0x0x3f6e1e8a/0x0176 (v  1 SECCSD LH43STAR 0x06040000  LTP
0x00000000)
ACPI: SSDT @ 0x0x3f6dcfa3/0x064F (v  1 SataRe  SataPri 0x00001000 INTL
0x20050624)
ACPI: SSDT @ 0x0x3f6dc907/0x069C (v  1 SataRe  SataSec 0x00001000 INTL
0x20050624)
ACPI: SSDT @ 0x0x3f6db9ce/0x04F6 (v  2  PmRef    CpuPm 0x00003000 INTL
0x20050624)
MADT: Found IO APIC ID 1, Interrupt 0 at 0xfec00000
ioapic0: Changing APIC ID to 1
ioapic0: Routing external 8259A's -> intpin 0
MADT: Interrupt override: source 0, irq 2
ioapic0: Routing IRQ 0 -> intpin 2
MADT: Interrupt override: source 9, irq 9
ioapic0: intpin 9 trigger: level
lapic0: Routing NMI -> LINT1
lapic0: LINT1 trigger: edge
lapic0: LINT1 polarity: high
lapic1: Routing NMI -> LINT1
lapic1: LINT1 trigger: edge
lapic1: LINT1 polarity: high
ioapic0 <Version 2.0> irqs 0-23 on motherboard
cpu0 BSP:
     ID: 0x00000000   VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff
  lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff
  timer: 0x000100ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010000
ath_rate: version 1.2 <SampleRate bit-rate selection algorithm>
wlan_amrr: <AMRR Transmit Rate Control Algorithm>
wlan: <802.11 Link Layer>
null: <null device, zero device>
random: <entropy source, Software, Yarrow>
io: <I/O>
kbd: new array size 4
kbd1 at kbdmux0
mem: <memory>
Pentium Pro MTRR support enabled
nfslock: pseudo-device
ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413)
npx0: INT 16 interface
acpi0: <SECCSD LH43STAR> on motherboard
ioapic0: routing intpin 9 (ISA IRQ 9) to vector 48
acpi0: [MPSAFE]
acpi0: [ITHREAD]
acpi0: Power Button (fixed)
acpi0: wakeup code va 0xd7a69000 pa 0x1000
pci_open(1):	mode 1 addr port (0x0cf8) is 0x8000fa04
pci_open(1a):	mode1res=0x80000000 (0x80000000)
pci_cfgcheck:	device 0 [class=060000] [hdr=00] is there (id=27ac8086)
pcibios: BIOS version 2.10
AcpiOsDerivePciId: \\_SB_.PCI0.HBUS -> bus 0 dev 0 func 0
AcpiOsDerivePciId: \\_SB_.PCI0.LPCB.LPC0 -> bus 0 dev 31 func 0
acpi_hpet0: vend: 0x8086 rev: 0x1 num: 2 hz: 14318180 opts: legacy_route 64-bit
Timecounter "HPET" frequency 14318180 Hz quality 900
ACPI timer: 1/2 1/1 1/1 1/2 1/1 1/2 1/1 1/1 1/2 1/2 -> 10
Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000
acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0
acpi_ec0: <Embedded Controller: GPE 0x17> port 0x62,0x66 on acpi0
pci_link0:        Index  IRQ  Rtd  Ref  IRQs
  Initial Probe       0   11   N     0  1 3 4 5 6 7 10 12 14 15
  Validation          0  255   N     0  1 3 4 5 6 7 10 12 14 15
  After Disable       0  255   N     0  1 3 4 5 6 7 10 12 14 15
pci_link1:        Index  IRQ  Rtd  Ref  IRQs
  Initial Probe       0   10   N     0  1 3 4 5 6 7 11 12 14 15
  Validation          0  255   N     0  1 3 4 5 6 7 11 12 14 15
  After Disable       0  255   N     0  1 3 4 5 6 7 11 12 14 15
pci_link2:        Index  IRQ  Rtd  Ref  IRQs
  Initial Probe       0    5   N     0  1 3 4 5 6 7 10 12 14 15
  Validation          0    5   N     0  1 3 4 5 6 7 10 12 14 15
  After Disable       0  255   N     0  1 3 4 5 6 7 10 12 14 15
pci_link3:        Index  IRQ  Rtd  Ref  IRQs
  Initial Probe       0    5   N     0  1 3 4 5 6 7 11 12 14 15
  Validation          0    5   N     0  1 3 4 5 6 7 11 12 14 15
  After Disable       0  255   N     0  1 3 4 5 6 7 11 12 14 15
pci_link4:        Index  IRQ  Rtd  Ref  IRQs
  Initial Probe       0  255   N     0  1 3 4 5 6 7 10 12 14 15
  Validation          0  255   N     0  1 3 4 5 6 7 10 12 14 15
  After Disable       0  255   N     0  1 3 4 5 6 7 10 12 14 15
pci_link5:        Index  IRQ  Rtd  Ref  IRQs
  Initial Probe       0  255   N     0  1 3 4 5 6 7 11 12 14 15
  Validation          0  255   N     0  1 3 4 5 6 7 11 12 14 15
  After Disable       0  255   N     0  1 3 4 5 6 7 11 12 14 15
pci_link6:        Index  IRQ  Rtd  Ref  IRQs
  Initial Probe       0    5   N     0  1 3 4 5 6 7 10 12 14 15
  Validation          0    5   N     0  1 3 4 5 6 7 10 12 14 15
  After Disable       0  255   N     0  1 3 4 5 6 7 10 12 14 15
pci_link7:        Index  IRQ  Rtd  Ref  IRQs
  Initial Probe       0    5   N     0  1 3 4 5 6 7 11 12 14 15
  Validation          0    5   N     0  1 3 4 5 6 7 11 12 14 15
  After Disable       0  255   N     0  1 3 4 5 6 7 11 12 14 15
pcib0: <ACPI Host-PCI bridge> port 0xcf8-0xcff on acpi0
pci0: <ACPI PCI bus> on pcib0
pci0: domain=0, physical bus=0
found->	vendor=0x8086, dev=0x27ac, revid=0x03
	domain=0, bus=0, slot=0, func=0
	class=06-00-00, hdrtype=0x00, mfdev=0
	cmdreg=0x0106, statreg=0x2090, cachelnsz=0 (dwords)
	lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
found->	vendor=0x8086, dev=0x27ae, revid=0x03
	domain=0, bus=0, slot=2, func=0
	class=03-00-00, hdrtype=0x00, mfdev=1
	cmdreg=0x0007, statreg=0x0090, cachelnsz=0 (dwords)
	lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
	intpin=a, irq=11
	powerspec 2  supports D0 D3  current D0
	MSI supports 1 message
	map[10]: type Memory, range 32, base 0xf0000000, size 19, enabled
	map[14]: type I/O Port, range 32, base 0x1800, size  3, enabled
	map[18]: type Prefetchable Memory, range 32, base 0xd0000000, size 28, enabled
	map[1c]: type Memory, range 32, base 0xf0300000, size 18, enabled
pcib0: matched entry for 0.2.INTA
pcib0: slot 2 INTA hardwired to IRQ 16
found->	vendor=0x8086, dev=0x27a6, revid=0x03
	domain=0, bus=0, slot=2, func=1
	class=03-80-00, hdrtype=0x00, mfdev=1
	cmdreg=0x0007, statreg=0x0090, cachelnsz=0 (dwords)
	lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
	powerspec 2  supports D0 D3  current D0
	map[10]: type Memory, range 32, base 0xf0080000, size 19, enabled
found->	vendor=0x8086, dev=0x27d8, revid=0x02
	domain=0, bus=0, slot=27, func=0
	class=04-03-00, hdrtype=0x00, mfdev=0
	cmdreg=0x0006, statreg=0x0010, cachelnsz=16 (dwords)
	lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
	intpin=a, irq=5
	powerspec 2  supports D0 D3  current D0
	MSI supports 1 message, 64 bit
	map[10]: type Memory, range 64, base 0xf0340000, size 14, enabled
pcib0: matched entry for 0.27.INTA
pcib0: slot 27 INTA hardwired to IRQ 22
found->	vendor=0x8086, dev=0x27d0, revid=0x02
	domain=0, bus=0, slot=28, func=0
	class=06-04-00, hdrtype=0x01, mfdev=1
	cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords)
	lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns)
	intpin=a, irq=10
	powerspec 2  supports D0 D3  current D0
	MSI supports 1 message
pcib0: matched entry for 0.28.INTA
pcib0: slot 28 INTA hardwired to IRQ 17
found->	vendor=0x8086, dev=0x27d4, revid=0x02
	domain=0, bus=0, slot=28, func=2
	class=06-04-00, hdrtype=0x01, mfdev=1
	cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords)
	lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns)
	intpin=c, irq=5
	powerspec 2  supports D0 D3  current D0
	MSI supports 1 message
pcib0: matched entry for 0.28.INTC
pcib0: slot 28 INTC hardwired to IRQ 18
found->	vendor=0x8086, dev=0x27c8, revid=0x02
	domain=0, bus=0, slot=29, func=0
	class=0c-03-00, hdrtype=0x00, mfdev=1
	cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords)
	lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
	intpin=a, irq=5
	map[20]: type I/O Port, range 32, base 0x1820, size  5, enabled
pcib0: matched entry for 0.29.INTA
pcib0: slot 29 INTA hardwired to IRQ 23
found->	vendor=0x8086, dev=0x27c9, revid=0x02
	domain=0, bus=0, slot=29, func=1
	class=0c-03-00, hdrtype=0x00, mfdev=0
	cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords)
	lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
	intpin=b, irq=5
	map[20]: type I/O Port, range 32, base 0x1840, size  5, enabled
pcib0: matched entry for 0.29.INTB
pcib0: slot 29 INTB hardwired to IRQ 19
found->	vendor=0x8086, dev=0x27ca, revid=0x02
	domain=0, bus=0, slot=29, func=2
	class=0c-03-00, hdrtype=0x00, mfdev=0
	cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords)
	lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
	intpin=c, irq=5
	map[20]: type I/O Port, range 32, base 0x1860, size  5, enabled
pcib0: matched entry for 0.29.INTC
pcib0: slot 29 INTC hardwired to IRQ 18
found->	vendor=0x8086, dev=0x27cb, revid=0x02
	domain=0, bus=0, slot=29, func=3
	class=0c-03-00, hdrtype=0x00, mfdev=0
	cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords)
	lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
	intpin=d, irq=11
	map[20]: type I/O Port, range 32, base 0x1880, size  5, enabled
pcib0: matched entry for 0.29.INTD
pcib0: slot 29 INTD hardwired to IRQ 16
found->	vendor=0x8086, dev=0x27cc, revid=0x02
	domain=0, bus=0, slot=29, func=7
	class=0c-03-20, hdrtype=0x00, mfdev=0
	cmdreg=0x0006, statreg=0x0290, cachelnsz=0 (dwords)
	lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
	intpin=a, irq=5
	powerspec 2  supports D0 D3  current D0
	map[10]: type Memory, range 32, base 0xf0544000, size 10, enabled
pcib0: matched entry for 0.29.INTA
pcib0: slot 29 INTA hardwired to IRQ 23
found->	vendor=0x8086, dev=0x2448, revid=0xe2
	domain=0, bus=0, slot=30, func=0
	class=06-04-01, hdrtype=0x01, mfdev=0
	cmdreg=0x0007, statreg=0x0010, cachelnsz=0 (dwords)
	lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns)
found->	vendor=0x8086, dev=0x27b9, revid=0x02
	domain=0, bus=0, slot=31, func=0
	class=06-01-00, hdrtype=0x00, mfdev=1
	cmdreg=0x0007, statreg=0x0210, cachelnsz=0 (dwords)
	lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
found->	vendor=0x8086, dev=0x27c4, revid=0x02
	domain=0, bus=0, slot=31, func=2
	class=01-01-80, hdrtype=0x00, mfdev=0
	cmdreg=0x0005, statreg=0x02b8, cachelnsz=0 (dwords)
	lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
	intpin=b, irq=255
	powerspec 2  supports D0 D3  current D0
	map[20]: type I/O Port, range 32, base 0x1810, size  4, enabled
found->	vendor=0x8086, dev=0x27da, revid=0x02
	domain=0, bus=0, slot=31, func=3
	class=0c-05-00, hdrtype=0x00, mfdev=0
	cmdreg=0x0001, statreg=0x0280, cachelnsz=0 (dwords)
	lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
	intpin=b, irq=5
	map[20]: type I/O Port, range 32, base 0x18a0, size  5, enabled
pcib0: matched entry for 0.31.INTB
pcib0: slot 31 INTB hardwired to IRQ 19
vgapci0: <VGA-compatible display> port 0x1800-0x1807 mem
0xf0000000-0xf007ffff,0xd0000000-0xdfffffff,0xf0300000-0xf033ffff irq
16 at device 2.0 on pci0
agp0: <Intel 945GME SVGA controller> on vgapci0
vgapci0: Reserved 0x10000000 bytes for rid 0x18 type 3 at 0xd0000000
vgapci0: Reserved 0x80000 bytes for rid 0x10 type 3 at 0xf0000000
vgapci0: Reserved 0x40000 bytes for rid 0x1c type 3 at 0xf0300000
agp0: detected 7932k stolen memory
agp0: aperture size is 256M
vgapci1: <VGA-compatible display> mem 0xf0080000-0xf00fffff at device
2.1 on pci0
pci0: <multimedia, HDA> at device 27.0 (no driver attached)
pcib1: <ACPI PCI-PCI bridge> irq 17 at device 28.0 on pci0
pcib1:   domain            0
pcib1:   secondary bus     2
pcib1:   subordinate bus   2
pcib1:   I/O decode        0xf000-0xfff
pcib1:   memory decode     0xf0100000-0xf01fffff
pcib1:   no prefetched decode
pci2: <ACPI PCI bus> on pcib1
pci2: domain=0, physical bus=2
found->	vendor=0x168c, dev=0x001c, revid=0x01
	domain=0, bus=2, slot=0, func=0
	class=02-00-00, hdrtype=0x00, mfdev=0
	cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords)
	lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
	intpin=a, irq=11
	powerspec 2  supports D0 D3  current D0
	MSI supports 1 message
	MSI-X supports 1 message in map 0x10
	map[10]: type Memory, range 64, base 0xf0100000, size 16, enabled
pcib1: requested memory range 0xf0100000-0xf010ffff: good
pcib1: matched entry for 2.0.INTA
pcib1: slot 0 INTA hardwired to IRQ 16
ath0: <Atheros 5424/2424> mem 0xf0100000-0xf010ffff irq 16 at device 0.0 on pci2
ath0: Reserved 0x10000 bytes for rid 0x10 type 3 at 0xf0100000
ioapic0: routing intpin 16 (PCI IRQ 16) to vector 49
ath0: [MPSAFE]
ath0: [ITHREAD]
ath0: unable to attach hardware; HAL status 13
device_attach: ath0 attach returned 6
pcib2: <ACPI PCI-PCI bridge> irq 18 at device 28.2 on pci0
pcib2:   domain            0
pcib2:   secondary bus     3
pcib2:   subordinate bus   3
pcib2:   I/O decode        0x2000-0x2fff
pcib2:   memory decode     0xf0200000-0xf02fffff
pcib2:   no prefetched decode
pci3: <ACPI PCI bus> on pcib2
pci3: domain=0, physical bus=3
found->	vendor=0x11ab, dev=0x4354, revid=0x13
	domain=0, bus=3, slot=0, func=0
	class=02-00-00, hdrtype=0x00, mfdev=0
	cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords)
	lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
	intpin=a, irq=5
	powerspec 3  supports D0 D1 D2 D3  current D0
	MSI supports 1 message, 64 bit
	map[10]: type Memory, range 64, base 0xf0200000, size 14, enabled
pcib2: requested memory range 0xf0200000-0xf0203fff: good
	map[18]: type I/O Port, range 32, base 0x2000, size  8, enabled
pcib2: requested I/O range 0x2000-0x20ff: in range
pcib2: matched entry for 3.0.INTA
pcib2: slot 0 INTA hardwired to IRQ 18
pci3: <network, ethernet> at device 0.0 (no driver attached)
uhci0: <UHCI (generic) USB controller> port 0x1820-0x183f irq 23 at
device 29.0 on pci0
uhci0: Reserved 0x20 bytes for rid 0x20 type 4 at 0x1820
ioapic0: routing intpin 23 (PCI IRQ 23) to vector 49
uhci0: [GIANT-LOCKED]
uhci0: [ITHREAD]
usb0: <UHCI (generic) USB controller> on uhci0
usb0: USB revision 1.0
uhub0: <Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb0
uhub0: 2 ports with 2 removable, self powered
uhci1: <UHCI (generic) USB controller> port 0x1840-0x185f irq 19 at
device 29.1 on pci0
uhci1: Reserved 0x20 bytes for rid 0x20 type 4 at 0x1840
ioapic0: routing intpin 19 (PCI IRQ 19) to vector 50
uhci1: [GIANT-LOCKED]
uhci1: [ITHREAD]
usb1: <UHCI (generic) USB controller> on uhci1
usb1: USB revision 1.0
uhub1: <Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb1
uhub1: 2 ports with 2 removable, self powered
uhci2: <UHCI (generic) USB controller> port 0x1860-0x187f irq 18 at
device 29.2 on pci0
uhci2: Reserved 0x20 bytes for rid 0x20 type 4 at 0x1860
ioapic0: routing intpin 18 (PCI IRQ 18) to vector 51
uhci2: [GIANT-LOCKED]
uhci2: [ITHREAD]
usb2: <UHCI (generic) USB controller> on uhci2
usb2: USB revision 1.0
uhub2: <Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb2
uhub2: 2 ports with 2 removable, self powered
uhci3: <UHCI (generic) USB controller> port 0x1880-0x189f irq 16 at
device 29.3 on pci0
uhci3: Reserved 0x20 bytes for rid 0x20 type 4 at 0x1880
ioapic0: routing intpin 16 (PCI IRQ 16) to vector 52
uhci3: [GIANT-LOCKED]
uhci3: [ITHREAD]
usb3: <UHCI (generic) USB controller> on uhci3
usb3: USB revision 1.0
uhub3: <Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb3
uhub3: 2 ports with 2 removable, self powered
ehci0: <Intel 82801GB/R (ICH7) USB 2.0 controller> mem
0xf0544000-0xf05443ff irq 23 at device 29.7 on pci0
ehci0: Reserved 0x400 bytes for rid 0x10 type 3 at 0xf0544000
ehci0: [GIANT-LOCKED]
ehci0: [ITHREAD]
usb4: EHCI version 1.0
usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3
usb4: <Intel 82801GB/R (ICH7) USB 2.0 controller> on ehci0
usb4: USB revision 2.0
uhub4: <Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1> on usb4
uhub4: 8 ports with 8 removable, self powered
umass0: <Samsung Mighty Drive, class 0/0, rev 2.00/1.10, addr 2> on uhub4
umass0:0:0:-1: Attached to scbus0
ugen0: <Vimicro Corp. Namuga 1.3M Webcam, class 239/2, rev 2.00/1.00,
addr 3> on uhub4
pcib3: <ACPI PCI-PCI bridge> at device 30.0 on pci0
pcib3:   domain            0
pcib3:   secondary bus     4
pcib3:   subordinate bus   4
pcib3:   I/O decode        0xf000-0xfff
pcib3:   no prefetched decode
pcib3:   Subtractively decoded bridge.
pci4: <ACPI PCI bus> on pcib3
pci4: domain=0, physical bus=4
isab0: <PCI-ISA bridge> at device 31.0 on pci0
isa0: <ISA bus> on isab0
atapci0: <Intel ICH7M SATA300 controller> port
0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1810-0x181f at device 31.2 on
pci0
atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0x1810
ata0: <ATA channel 0> on atapci0
atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0
atapci0: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6
ata0: reset tp1 mask=03 ostat0=50 ostat1=00
ata0: stat0=0x50 err=0x01 lsb=0x00 msb=0x00
ata0: stat1=0x00 err=0x01 lsb=0x00 msb=0x00
ata0: reset tp2 stat0=50 stat1=00 devices=0x1<ATA_MASTER>
ioapic0: routing intpin 14 (ISA IRQ 14) to vector 53
ata0: [MPSAFE]
ata0: [ITHREAD]
ata1: <ATA channel 1> on atapci0
atapci0: Reserved 0x8 bytes for rid 0x18 type 4 at 0x170
atapci0: Reserved 0x1 bytes for rid 0x1c type 4 at 0x376
ata1: reset tp1 mask=00 ostat0=ff ostat1=ff
ioapic0: routing intpin 15 (ISA IRQ 15) to vector 54
ata1: [MPSAFE]
ata1: [ITHREAD]
pci0: <serial bus, SMBus> at device 31.3 (no driver attached)
acpi_acad0: <AC Adapter> on acpi0
acpi_lid0: <Control Method Lid Switch> on acpi0
acpi_button0: <Power Button> on acpi0
acpi_button1: <Sleep Button> on acpi0
acpi_tz0: <Thermal Zone> on acpi0
atkbdc0: <Keyboard controller (i8042)> port 0x60,0x64 irq 1 on acpi0
atkbd0: <AT Keyboard> irq 1 on atkbdc0
atkbd: the current kbd controller command byte 0047
atkbd: keyboard ID 0x41ab (2)
kbd0 at atkbd0
kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000
ioapic0: routing intpin 1 (ISA IRQ 1) to vector 55
atkbd0: [GIANT-LOCKED]
atkbd0: [ITHREAD]
psm0: unable to allocate IRQ
psmcpnp0: <PS/2 mouse port> irq 12 on acpi0
psm0: current command byte:0047
psm0: <PS/2 Mouse> irq 12 on atkbdc0
ioapic0: routing intpin 12 (ISA IRQ 12) to vector 56
psm0: [GIANT-LOCKED]
psm0: [ITHREAD]
psm0: model Generic PS/2 mouse, device ID 0-00, 2 buttons
psm0: config:00000000, flags:00000008, packet size:3
psm0: syncmask:c0, syncbits:00
battery0: <ACPI Control Method Battery> on acpi0
cpu0: <ACPI CPU> on acpi0
ACPI: SSDT @ 0x0x3f6dc5ee/0x0245 (v  2  PmRef  Cpu0Ist 0x00003000 INTL
0x20050624)
ACPI: SSDT @ 0x0x3f6dbec4/0x06A5 (v  2  PmRef  Cpu0Cst 0x00003001 INTL
0x20050624)
est0: <Enhanced SpeedStep Frequency Control> on cpu0
p4tcc0: <CPU Frequency Thermal Control> on cpu0
cpu1: <ACPI CPU> on acpi0
ACPI: SSDT @ 0x0x3f6dc833/0x00D4 (v  2  PmRef  Cpu1Ist 0x00003000 INTL
0x20050624)
ACPI: SSDT @ 0x0x3f6dc569/0x0085 (v  2  PmRef  Cpu1Cst 0x00003000 INTL
0x20050624)
est1: <Enhanced SpeedStep Frequency Control> on cpu1
p4tcc1: <CPU Frequency Thermal Control> on cpu1
ata: ata0 already exists; skipping it
ata: ata1 already exists; skipping it
atkbdc: atkbdc0 already exists; skipping it
sc: sc0 already exists; skipping it
vga: vga0 already exists; skipping it
pnp_identify: Trying Read_Port at 203
pnp_identify: Trying Read_Port at 243
pnp_identify: Trying Read_Port at 283
pnp_identify: Trying Read_Port at 2c3
pnp_identify: Trying Read_Port at 303
pnp_identify: Trying Read_Port at 343
pnp_identify: Trying Read_Port at 383
pnp_identify: Trying Read_Port at 3c3
PNP Identify complete
isa_probe_children: disabling PnP devices
isa_probe_children: probing non-PnP devices
pmtimer0 on isa0
orm0: <ISA Option ROMs> at iomem 0xdf000-0xdffff,0xe0000-0xe17ff pnpid
ORM0000 on isa0
sc0: <System console> at flags 0x100 on isa0
sc0: VGA <16 virtual consoles, flags=0x300>
sc0: fb0, kbd1, terminal emulator: sc (syscons terminal)
vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0
adv0: not probed (disabled)
aha0: not probed (disabled)
aic0: not probed (disabled)
bt0: not probed (disabled)
cs0: not probed (disabled)
ed0: not probed (disabled)
fdc0 failed to probe at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0
fe0: not probed (disabled)
ie0: not probed (disabled)
le0: not probed (disabled)
ppc0 failed to probe at irq 7 on isa0
sio0: configured irq 4 not in bitmap of probed irqs 0
sio0: port may not be enabled
sio0: irq maps: 0xe21 0xe21 0xe21 0xe21
sio0: probe failed test(s): 0 1 2 4 6 7 9
sio0: configured irq 4 not in bitmap of probed irqs 0
sio0: port may not be enabled
sio0: irq maps: 0xe21 0xe21 0xe21 0xe21
sio0: probe failed test(s): 0 1 2 4 6 7 9
sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0
sio0: type 8250 or not responding
ioapic0: routing intpin 4 (ISA IRQ 4) to vector 57
sio0: [FILTER]
sio1: configured irq 3 not in bitmap of probed irqs 0
sio1: port may not be enabled
sio1: irq maps: 0xe21 0xe21 0xe21 0xe21
sio1: probe failed test(s): 0 1 2 4 6 7 9
sio1 failed to probe at port 0x2f8-0x2ff irq 3 on isa0
sio2: not probed (disabled)
sio3: not probed (disabled)
sn0: not probed (disabled)
vt0: not probed (disabled)
isa_probe_children: probing PnP devices
Device configuration finished.
procfs registered
lapic: Divisor 2, Frequency 66499787 hz
Timecounter "TSC" frequency 1595994372 Hz quality -100
Timecounters tick every 1.000 msec
lo0: bpf attached
acpi_acad0: acline initialization start
battery0: acpi_acad0: On Line
acpi_acad0: acline initialization done, tried 1 times
battery initialization start
ata0-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire
battery0: battery initialization done, tried 1 times
ad0: 152627MB <WDC WD1600BEVT-35ZCT1 11.01A11> at ata0-master SATA150
ad0: 312581808 sectors [310101C/16H/63S] 16 sectors/interrupt 1 depth queue
GEOM: new disk ad0
GEOM_LABEL: Label for provider ad0s1 is ntfs/RECOVERY.
GEOM: new disk da0
pass0 at umass-sim0 bus 0 target 0 lun 0
pass0: <Samsung Mighty Drive PMAP> Removable Direct Access SCSI-0 device
pass0: 40.000MB/s transfers
da0 at umass-sim0 bus 0 target 0 lun 0
da0: <Samsung Mighty Drive PMAP> Removable Direct Access SCSI-0 device
da0: 40.000MB/s transfers
da0: 1967MB (4029440 512 byte sectors: 255H 63S/T 250C)
SMP: AP CPU #1 Launched!
cpu1 AP:
     ID: 0x01000000   VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff
  lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff
  timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010000
ioapic0: Assigning ISA IRQ 1 to local APIC 0
ioapic0: Assigning ISA IRQ 4 to local APIC 0
ioapic0: Assigning ISA IRQ 9 to local APIC 0
ioapic0: Assigning ISA IRQ 12 to local APIC 0
ioapic0: Assigning ISA IRQ 14 to local APIC 0
ioapic0: Assigning ISA IRQ 15 to local APIC 0
ioapic0: Assigning PCI IRQ 16 to local APIC 0
ioapic0: Assigning PCI IRQ 18 to local APIC 0
ioapic0: Assigning PCI IRQ 19 to local APIC 0
ioapic0: Assigning PCI IRQ 23 to local APIC 0
Trying to mount root from ufs:/dev/ad0s3a
start_init: trying /sbin/init
Linux ELF exec handler installed





hostb0@pci0:0:0:0:	class=0x060000 card=0xca00144d chip=0x27ac8086
rev=0x03 hdr=0x00
    vendor     = 'Intel Corporation'
    class      = bridge
    subclass   = HOST-PCI
    cap 09[e0] = vendor (length 9) Intel cap 7 version 1
vgapci0@pci0:0:2:0:	class=0x030000 card=0xca00144d chip=0x27ae8086
rev=0x03 hdr=0x00
    vendor     = 'Intel Corporation'
    class      = display
    subclass   = VGA
    cap 05[90] = MSI supports 1 message
    cap 01[d0] = powerspec 2  supports D0 D3  current D0
vgapci1@pci0:0:2:1:	class=0x038000 card=0xca00144d chip=0x27a68086
rev=0x03 hdr=0x00
    vendor     = 'Intel Corporation'
    device     = 'Mobile 945GM/GU Express Integrated Graphics Controller'
    class      = display
    cap 01[d0] = powerspec 2  supports D0 D3  current D0
none0@pci0:0:27:0:	class=0x040300 card=0xca00144d chip=0x27d88086
rev=0x02 hdr=0x00
    vendor     = 'Intel Corporation'
    device     = '82801G (ICH7 Family) High Definition Audio'
    class      = multimedia
    subclass   = HDA
    cap 01[50] = powerspec 2  supports D0 D3  current D0
    cap 05[60] = MSI supports 1 message, 64 bit
    cap 10[70] = PCI-Express 1 type 0
pcib1@pci0:0:28:0:	class=0x060400 card=0xca00144d chip=0x27d08086
rev=0x02 hdr=0x01
    vendor     = 'Intel Corporation'
    device     = '82801G (ICH7 Family) PCIe Root Port'
    class      = bridge
    subclass   = PCI-PCI
    cap 10[40] = PCI-Express 1 root port
    cap 05[80] = MSI supports 1 message
    cap 0d[90] = PCI Bridge card=0xca00144d
    cap 01[a0] = powerspec 2  supports D0 D3  current D0
pcib2@pci0:0:28:2:	class=0x060400 card=0xca00144d chip=0x27d48086
rev=0x02 hdr=0x01
    vendor     = 'Intel Corporation'
    device     = '82801G (ICH7 Family) PCIe Root Port'
    class      = bridge
    subclass   = PCI-PCI
    cap 10[40] = PCI-Express 1 root port
    cap 05[80] = MSI supports 1 message
    cap 0d[90] = PCI Bridge card=0xca00144d
    cap 01[a0] = powerspec 2  supports D0 D3  current D0
uhci0@pci0:0:29:0:	class=0x0c0300 card=0xca00144d chip=0x27c88086
rev=0x02 hdr=0x00
    vendor     = 'Intel Corporation'
    device     = '82801G (ICH7 Family) USB Universal Host Controller'
    class      = serial bus
    subclass   = USB
uhci1@pci0:0:29:1:	class=0x0c0300 card=0xca00144d chip=0x27c98086
rev=0x02 hdr=0x00
    vendor     = 'Intel Corporation'
    device     = '82801G (ICH7 Family) USB Universal Host Controller'
    class      = serial bus
    subclass   = USB
uhci2@pci0:0:29:2:	class=0x0c0300 card=0xca00144d chip=0x27ca8086
rev=0x02 hdr=0x00
    vendor     = 'Intel Corporation'
    device     = '82801G (ICH7 Family) USB Universal Host Controller'
    class      = serial bus
    subclass   = USB
uhci3@pci0:0:29:3:	class=0x0c0300 card=0xca00144d chip=0x27cb8086
rev=0x02 hdr=0x00
    vendor     = 'Intel Corporation'
    device     = '82801G (ICH7 Family) USB Universal Host Controller'
    class      = serial bus
    subclass   = USB
ehci0@pci0:0:29:7:	class=0x0c0320 card=0xca00144d chip=0x27cc8086
rev=0x02 hdr=0x00
    vendor     = 'Intel Corporation'
    device     = '82801G (ICH7 Family) USB 2.0 Enhanced Host Controller'
    class      = serial bus
    subclass   = USB
    cap 01[50] = powerspec 2  supports D0 D3  current D0
    cap 0a[58] = EHCI Debug Port at offset 0xa0 in map 0x14
pcib3@pci0:0:30:0:	class=0x060401 card=0xca00144d chip=0x24488086
rev=0xe2 hdr=0x01
    vendor     = 'Intel Corporation'
    device     = '82801BAM/CAM/DBM (ICH2-M/3-M/4-M) Hub Interface to PCI Bridge'
    class      = bridge
    subclass   = PCI-PCI
    cap 0d[50] = PCI Bridge card=0xca00144d
isab0@pci0:0:31:0:	class=0x060100 card=0xca00144d chip=0x27b98086
rev=0x02 hdr=0x00
    vendor     = 'Intel Corporation'
    device     = '82801GBM (ICH7-M) LPC Interface Controller'
    class      = bridge
    subclass   = PCI-ISA
    cap 09[e0] = vendor (length 12) Intel cap 1 version 0
		 features: Quick Resume, SATA RAID-5, Mobile, 6 PCI-e x1 slots, SATA
RAID-0/1/10
atapci0@pci0:0:31:2:	class=0x010180 card=0xca00144d chip=0x27c48086
rev=0x02 hdr=0x00
    vendor     = 'Intel Corporation'
    device     = '82801GBM/GHM (ICH7-M Family) Serial ATA Storage Controller'
    class      = mass storage
    subclass   = ATA
    cap 01[70] = powerspec 2  supports D0 D3  current D0
none1@pci0:0:31:3:	class=0x0c0500 card=0xca00144d chip=0x27da8086
rev=0x02 hdr=0x00
    vendor     = 'Intel Corporation'
    device     = '82801G (ICH7 Family) SMBus Controller'
    class      = serial bus
    subclass   = SMBus
ath0@pci0:2:0:0:	class=0x020000 card=0x7131144f chip=0x001c168c
rev=0x01 hdr=0x00
    vendor     = 'Atheros Communications Inc.'
    device     = 'AR5006 family 802.11abg Wireless NIC'
    class      = network
    subclass   = ethernet
    cap 01[40] = powerspec 2  supports D0 D3  current D0
    cap 05[50] = MSI supports 1 message
    cap 10[60] = PCI-Express 1 legacy endpoint
    cap 11[90] = MSI-X supports 1 message in map 0x10
none2@pci0:3:0:0:	class=0x020000 card=0xca00144d chip=0x435411ab
rev=0x13 hdr=0x00
    vendor     = 'Marvell Semiconductor (Was: Galileo Technology Ltd)'
    class      = network
    subclass   = ethernet
    cap 01[48] = powerspec 3  supports D0 D1 D2 D3  current D0
    cap 05[5c] = MSI supports 1 message, 64 bit
    cap 10[c0] = PCI-Express 2 legacy endpoint



-- 

~ vb
From pyunyh at gmail.com  Tue Jan 13 16:32:37 2009
From: pyunyh at gmail.com (Pyun YongHyeon)
Date: Tue Jan 13 16:32:45 2009
Subject: FreeBSD 7.1 Breaks re and rl Network Interface Drivers
In-Reply-To: <496CB0A2.2020103@optiksecurite.com>
References: <8dfae1c10901070639x67945324jeeecfcac647d7976@mail.gmail.com>
	<8dfae1c10901071550s69d99802p31ca7c775f3d6823@mail.gmail.com>
	<88527079.20090111192206@donpac.ru>
	<20090112011146.GC46346@cdnetworks.co.kr>
	<496BBFF6.7010300@optiksecurite.com>
	<20090113004018.GG46346@cdnetworks.co.kr>
	<496CB0A2.2020103@optiksecurite.com>
Message-ID: <20090114003228.GA55351@cdnetworks.co.kr>

On Tue, Jan 13, 2009 at 10:17:54AM -0500, FreeBSD wrote:
 > Pyun YongHyeon a ?crit :
 > >On Mon, Jan 12, 2009 at 05:11:02PM -0500, FreeBSD wrote:
 > > > Pyun YongHyeon a ?crit :
 > > > >On Sun, Jan 11, 2009 at 07:22:06PM +0300, Eugene Gladchenko wrote:
 > > > > > Walter,
 > > > > > 
 > > > > > Thursday, January 8, 2009, 2:50:40 AM, you wrote:
 > > > > > 
 > > > > > WV> Booting kernel.old, which is 7.0-RELEASE-p7 completely 
 > > alleviates > > all
 > > > > > WV> problems.  I believe this roundly confirms that this is a bug 
 > > in the
 > > > > > WV> 7.1-RELEASE re kernel drivers.
 > > > > > 
 > > > > > Does kern/130011 look similar? 
 > > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=130011
 > > > >
 > > > >Do you have RTL8168C controller? If not, it's not related with
 > > > >Walter's issue as 7.0-RELEASE didn't have a support for RTL8168C.
 > > > >
 > > > > > 
 > > > > > The re driver was really broken in 7.1-RC2 and the fix didn't get 
 > > to > > 7.1-RELEASE.
 > > > >
 > > > >If you have re(4) issues, please provide more details such as
 > > > >dmesg output, way to reproduce the issue etc.
 > > > >
 > > > 
 > > > Hi,
 > > > 
 > > > I have the exact same card and the exact same problem as the PR you 
 > > > mentionned.
 > > > 
 > > > re0@pci0:3:0:0: class=0x020000 card=0x02831028 chip=0x816810ec rev=0x02 
 > > > hdr=0x00
 > > >     vendor     = 'Realtek Semiconductor'
 > > >     device     = 'RTL8168/8111 PCI-E Gigabit Ethernet NIC'
 > > >     class      = network
 > > >     subclass   = ethernet
 > > > 
 > > > 
 > > > re0: <RealTek 8168/8168B/8168C/8168CP/8168D/8111B/8111C/8111CP PCIe 
 > > > Gigabit Ethernet> port 0xd800-0xd8ff mem 
 > > > 0xfeaff000-0xfeafffff,0xfdff0000-0xfdffffff irq 18 at device 0.0 on pci3
 > > > re0: Chip rev. 0x3c000000
 > > > re0: MAC rev. 0x00400000
 > > > re0: PHY write failed
 > > > re0: PHY write failed
 > > > re0: MII without any phy!
 > > > device_attach: re0 attach returned 6
 > > > 
 > > > I tried to compile a new kernel with the latest version of the 3 files 
 > > > listed in the PR:
 > > > src/sys/dev/re/if_re.c,v 1.147 2008/12/22 00:46:22 yongari
 > > > src/sys/pci/if_rl.c,v 1.170.2.10 2009/01/12 04:10:40 yongari
 > > > src/sys/pci/if_rlreg.h,v 1.67.2.16 2009/01/12 03:48:25 yongari
 > > > 
 > >
 > >You need lastest if_rl.c and if_rlreg.h as well as if_re.c.
 > >
 > 
 > That's exactly what I tried. Look at the 3 revision of the specified 

You've used if_rlreg.h in stable/7.

 > files. I even tried with a if_rl.c from the 22/12/08 but got the same 
 > problem.
 > 

Use if_re.c, if_rl.h and if_rl.c in HEAD. Not all changes were
MFCed.

-- 
Regards,
Pyun YongHyeon
From amarat at ksu.ru  Tue Jan 13 16:41:40 2009
From: amarat at ksu.ru (Marat N.Afanasyev)
Date: Tue Jan 13 16:41:48 2009
Subject: interrupt storm and usb issue on ati ixp600 based board
Message-ID: <496D325C.2020702@ksu.ru>

I have two troubles with my freshly upgraded system. There are interrupt 
storm and usb issues on MSI K9A2 CF motherboard. it made of on amd 790X 
north-bridge and and SB600 south-bridge.

As stated in [1] there is a problem with storms on re or atapci devices,
but my experience shows that this storms are not bound to re or ixp600 
atapci only. I can say that i have such storms on almost any of my 
devices. whether it sound-card, ata-device, scsi or network. any device 
  that is used intensively can trigger this storm issue, e.g. playing 
music via audacious can trigger storm in about random() hours after 
fresh boot either cold or warm (i tried both built in hda that shares 
irq with ohci0 and standalone sblive! with its own interrupt), moving 
large files from one physical drive to another, etc.

I've tried to turn off msi and msix setting

hw.pci.enable_msix="0"
hw.pci.enable_msi="0"

in /boot/loader.conf

interrupt storm arrived in about 27 hours. and it was on pcm0 (snd_hda)

So, can this be hardware or software problem? can it be fixed by some
workaround?

and finally I've updated to 7.1-S. the same story.

temporary workaround for interrupt storm issue is to wait until storm 
arrive on any device (emu10kx0 in this case, because of its own high 
interrupt rate) and work pretending to believe that nothing is wrong.

second issue is neither 7.0 nor 7.1 refuse to detect in run-time any usb 
device that plugged into external USB HUB, I have two of them, first is 
on card-reader, second is in my monitor. devices plugged to these hubs 
before system boot are detected, but device plugged after boot -- they 
never appear in system, they silently ignored.

so, what should i do? :)

[1]
http://lists.freebsd.org/pipermail/freebsd-stable/2008-December/047010.html

[2] fresh boot vmstat:

% vmstat -i
interrupt                          total       rate
irq1: atkbd0                       12524          1
irq9: acpi0                            1          0
irq12: psm0                      1173440        107
irq14: ata0                          143          0
irq16: hdac0 ohci0                541673         49
irq17: ohci1 ohci3                     1          0
irq18: ohci2 ohci+                    45          0
irq19: ehci0                         259          0
irq21: emu10kx0               1137863753     103762
irq22: atapci0                    210431         19
cpu0: timer                     21929877       1999
irq256: re0                        94789          8
cpu1: timer                     21927861       1999
Total                         1183754797     107947

[3] % uptime
  3:15  up  3:03, 2 users, load averages: 0,60 0,47 0,63

[4] dmesg attached

-- 
SY, Marat
-------------- next part --------------
interrupt storm detected on "irq21::irq21: emu10kx0"; throttling interrupt source
interrupt storm detected on "irq21::irq21: emu10kx0"; throttling interrupt source
interrupt storm detected on "irq21::irq21: emu10kx0"; throttling interrupt source
interrupt storm detected on "irq21::irq21: emu10kx0"; throttling interrupt source
interrupt storm detected on "irq21::irq21: emu10kx0"; throttling interrupt source
interrupt storm detected on "irq21::irq21: emu10kx0"; throttling interrupt source
interrupt storm detected on "irq21::irq21: emu10kx0"; throttling interrupt source
interrupt storm detected on "irq21::irq21: emu10kx0"; throttling interrupt source
info: [drm] wait for fifo failed status : 0x9803C100 0x00050000
interrupt storm detected on "irq21::irq21: emu10kx0"; throttling interrupt source
interrupt storm detected on "irq21::irq21: emu10kx0"; throttling interrupt source
interrupt storm detected on "irq21::irq21: emu10kx0"; throttling interrupt source
interrupt storm detected on "irq21::irq21: emu10kx0"; throttling interrupt source
info: [drm] Num pipes: 1
Waiting (max 60 seconds) for system process `vnlru' to stop...done
Waiting (max 60 seconds) for system process `bufdaemon' to stop...done
Waiting (max 60 seconds) for system process `syncer' to stop...
Syncing disks, vnodes remaining...6 3 6 6 0 1 1 0 0 0 done
All buffers synced.
Uptime: 3d22h21m34s
Copyright (c) 1992-2009 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
	The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 7.1-STABLE #0: Tue Jan 13 23:43:59 MSK 2009
    root@zealot.ksu.ru:/usr/obj/usr/src/sys/ZEALOT
Timecounter "i8254" frequency 1193182 Hz quality 0
CPU: AMD Athlon(tm) Dual Core Processor 4850e (2500.19-MHz K8-class CPU)
  Origin = "AuthenticAMD"  Id = 0x60fb2  Stepping = 2
  Features=0x178bfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT>
  Features2=0x2001<SSE3,CX16>
  AMD Features=0xea500800<SYSCALL,NX,MMX+,FFXSR,RDTSCP,LM,3DNow!+,3DNow!>
  AMD Features2=0x11f<LAHF,CMP,SVM,ExtAPIC,CR8,Prefetch>
  Cores per package: 2
usable memory = 4285845504 (4087 MB)
avail memory  = 4124442624 (3933 MB)
ACPI APIC Table: <061208 APIC1106>
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
 cpu0 (BSP): APIC ID:  0
 cpu1 (AP): APIC ID:  1
ioapic0 <Version 2.1> irqs 0-23 on motherboard
netsmb_dev: loaded
acpi0: <061208 RSDT1106> on motherboard
acpi0: [ITHREAD]
acpi0: Power Button (fixed)
acpi0: reservation of ffb80000, 80000 (3) failed
acpi0: reservation of fff00000, 100000 (3) failed
acpi0: reservation of 0, a0000 (3) failed
acpi0: reservation of 100000, cff00000 (3) failed
ACPI HPET table warning: Sequence is non-zero (2)
Timecounter "ACPI-safe" frequency 3579545 Hz quality 850
acpi_timer0: <32-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0
acpi_hpet0: <High Precision Event Timer> iomem 0xfed00000-0xfed003ff on acpi0
Timecounter "HPET" frequency 14318180 Hz quality 900
pcib0: <ACPI Host-PCI bridge> port 0xcf8-0xcff on acpi0
pci0: <ACPI PCI bus> on pcib0
pcib1: <ACPI PCI-PCI bridge> at device 2.0 on pci0
pci1: <ACPI PCI bus> on pcib1
vgapci0: <VGA-compatible display> port 0xc000-0xc0ff mem 0xd0000000-0xdfffffff,0xfeaf0000-0xfeafffff irq 18 at device 0.0 on pci1
drm0: <ATI Radeon X1600> on vgapci0
vgapci0: child drm0 requested pci_enable_busmaster
info: [drm] Initialized radeon 1.29.0 20080613
vgapci1: <VGA-compatible display> mem 0xfeae0000-0xfeaeffff at device 0.1 on pci1
pcib2: <ACPI PCI-PCI bridge> at device 6.0 on pci0
pci2: <ACPI PCI bus> on pcib2
re0: <RealTek 8168/8168B/8168C/8168CP/8168D/8111B/8111C/8111CP PCIe Gigabit Ethernet> port 0xd800-0xd8ff mem 0xfebff000-0xfebfffff irq 18 at device 0.0 on pci2
re0: Using 2 MSI messages
re0: Chip rev. 0x38000000
re0: MAC rev. 0x00000000
miibus0: <MII bus> on re0
rgephy0: <RTL8169S/8110S/8211B media interface> PHY 1 on miibus0
rgephy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto
re0: Ethernet address: 00:1d:92:da:0c:b0
re0: [FILTER]
re0: [FILTER]
atapci0: <ATI IXP600 SATA300 controller> port 0xb000-0xb007,0xa000-0xa003,0x9000-0x9007,0x8000-0x8003,0x7000-0x700f mem 0xfe9ff800-0xfe9ffbff irq 22 at device 18.0 on pci0
atapci0: [ITHREAD]
atapci0: AHCI Version 01.10 controller with 4 ports detected
ata2: <ATA channel 0> on atapci0
ata2: [ITHREAD]
ata3: <ATA channel 1> on atapci0
ata3: [ITHREAD]
ata4: <ATA channel 2> on atapci0
ata4: [ITHREAD]
ata5: <ATA channel 3> on atapci0
ata5: [ITHREAD]
ohci0: <OHCI (generic) USB controller> mem 0xfe9fe000-0xfe9fefff irq 16 at device 19.0 on pci0
ohci0: [GIANT-LOCKED]
ohci0: [ITHREAD]
usb0: OHCI version 1.0, legacy support
usb0: SMM does not respond, resetting
usb0: <OHCI (generic) USB controller> on ohci0
usb0: USB revision 1.0
uhub0: <ATI OHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb0
uhub0: 2 ports with 2 removable, self powered
ohci1: <OHCI (generic) USB controller> mem 0xfe9fd000-0xfe9fdfff irq 17 at device 19.1 on pci0
ohci1: [GIANT-LOCKED]
ohci1: [ITHREAD]
usb1: OHCI version 1.0, legacy support
usb1: SMM does not respond, resetting
usb1: <OHCI (generic) USB controller> on ohci1
usb1: USB revision 1.0
uhub1: <ATI OHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb1
uhub1: 2 ports with 2 removable, self powered
ohci2: <OHCI (generic) USB controller> mem 0xfe9fc000-0xfe9fcfff irq 18 at device 19.2 on pci0
ohci2: [GIANT-LOCKED]
ohci2: [ITHREAD]
usb2: OHCI version 1.0, legacy support
usb2: SMM does not respond, resetting
usb2: <OHCI (generic) USB controller> on ohci2
usb2: USB revision 1.0
uhub2: <ATI OHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb2
uhub2: 2 ports with 2 removable, self powered
ohci3: <OHCI (generic) USB controller> mem 0xfe9fb000-0xfe9fbfff irq 17 at device 19.3 on pci0
ohci3: [GIANT-LOCKED]
ohci3: [ITHREAD]
usb3: OHCI version 1.0, legacy support
usb3: SMM does not respond, resetting
usb3: <OHCI (generic) USB controller> on ohci3
usb3: USB revision 1.0
uhub3: <ATI OHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb3
uhub3: 2 ports with 2 removable, self powered
ohci4: <OHCI (generic) USB controller> mem 0xfe9fa000-0xfe9fafff irq 18 at device 19.4 on pci0
ohci4: [GIANT-LOCKED]
ohci4: [ITHREAD]
usb4: OHCI version 1.0, legacy support
usb4: SMM does not respond, resetting
usb4: <OHCI (generic) USB controller> on ohci4
usb4: USB revision 1.0
uhub4: <ATI OHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb4
uhub4: 2 ports with 2 removable, self powered
ehci0: <EHCI (generic) USB 2.0 controller> mem 0xfe9ff000-0xfe9ff0ff irq 19 at device 19.5 on pci0
ehci0: [GIANT-LOCKED]
ehci0: [ITHREAD]
usb5: EHCI version 1.0
usb5: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4
usb5: <EHCI (generic) USB 2.0 controller> on ehci0
usb5: USB revision 2.0
uhub5: <ATI EHCI root hub, class 9/0, rev 2.00/1.00, addr 1> on usb5
uhub5: 10 ports with 10 removable, self powered
uhub6: <vendor 0x03f0 product 0x2f24, class 9/0, rev 2.00/0.00, addr 2> on uhub5
uhub6: multiple transaction translators
uhub6: 6 ports with 6 removable, self powered
ucom0: <ArkMicroChips USB-UART Controller, class 0/0, rev 1.10/0.01, addr 3> on uhub6
uhub7: <vendor 0x0409 product 0x0059, class 9/0, rev 2.00/1.00, addr 4> on uhub5
uhub7: single transaction translator
uhub7: 4 ports with 4 removable, self powered
umass0: <Generic Mass Storage Device, class 0/0, rev 2.00/1.26, addr 5> on uhub7
pci0: <serial bus, SMBus> at device 20.0 (no driver attached)
atapci1: <ATI IXP600 UDMA133 controller> port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xff00-0xff0f at device 20.1 on pci0
ata0: <ATA channel 0> on atapci1
ata0: [ITHREAD]
pci0: <multimedia, HDA> at device 20.2 (no driver attached)
isab0: <PCI-ISA bridge> at device 20.3 on pci0
isa0: <ISA bus> on isab0
pcib3: <ACPI PCI-PCI bridge> at device 20.4 on pci0
pci3: <ACPI PCI bus> on pcib3
pci3: <multimedia, audio> at device 3.0 (no driver attached)
pci3: <input device> at device 3.1 (no driver attached)
k8temp0: <AMD K8 Thermal Sensors> on hostb4
acpi_button0: <Power Button> on acpi0
sio0: configured irq 4 not in bitmap of probed irqs 0
sio0: port may not be enabled
sio0: configured irq 4 not in bitmap of probed irqs 0
sio0: port may not be enabled
sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 on acpi0
sio0: type 16550A
sio0: [FILTER]
atkbdc0: <Keyboard controller (i8042)> port 0x60,0x64 irq 1 on acpi0
atkbd0: <AT Keyboard> irq 1 on atkbdc0
kbd0 at atkbd0
atkbd0: [GIANT-LOCKED]
atkbd0: [ITHREAD]
psm0: <PS/2 Mouse> irq 12 on atkbdc0
psm0: [GIANT-LOCKED]
psm0: [ITHREAD]
psm0: model IntelliMouse Explorer, device ID 4
cpu0: <ACPI CPU> on acpi0
acpi_throttle0: <ACPI CPU Throttling> on cpu0
acpi_throttle0: CLK_VAL field overlaps THT_EN bit
device_attach: acpi_throttle0 attach returned 6
powernow0: <PowerNow! K8> on cpu0
cpu1: <ACPI CPU> on acpi0
powernow1: <PowerNow! K8> on cpu1
orm0: <ISA Option ROM> at iomem 0xc0000-0xcf7ff 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
uscanner0: <Canon CanoScan, class 255/0, rev 1.10/1.00, addr 2> on uhub2
ulpt0: <HewLett Packard HP LaserJet 1200, class 0/0, rev 1.10/1.00, addr 3> on uhub2
ulpt0: using bi-directional mode
Timecounters tick every 1.000 msec
ipfw2 initialized, divert enabled, nat loadable, rule-based forwarding enabled, default to accept, logging limited to 1000 packets/entry by default
acd0: DVDR <PIONEER DVD-RW DVR-111D/1.29> at ata0-master UDMA66
ad4: 238475MB <WDC WD2500JS-40MVB1 10.02E01> at ata2-master SATA300
ad6: 476940MB <Seagate ST3500320AS SD15> at ata3-master SATA150
acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 sks=0x48 0x00 0x01
acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 sks=0x48 0x00 0x01
SMP: AP CPU #1 Launched!
da0 at umass-sim0 bus 0 target 0 lun 0
da0: <Generic USB SD Reader 1.00> Removable Direct Access SCSI-0 device 
da0: 40.000MB/s transfers
da0: Attempt to query device size failed: NOT READY, Medium not present
cd0 at ata0 bus 0 target 0 lun 0
cd0: <PIONEER DVD-RW  DVR-111D 1.29> Removable CD-ROM SCSI-0 device 
cd0: 66.000MB/s transfers
cd0: cd present [2288832 x 2048 byte records]
da1 at umass-sim0 bus 0 target 0 lun 1
da1: <Generic USB CF Reader 1.01> Removable Direct Access SCSI-0 device 
da1: 40.000MB/s transfers
da1: Attempt to query device size failed: NOT READY, Medium not present
da2 at umass-sim0 bus 0 target 0 lun 2
da2: <Generic USB SM Reader 1.02> Removable Direct Access SCSI-0 device 
da2: 40.000MB/s transfers
da2: Attempt to query device size failed: NOT READY, Medium not present
da3 at umass-sim0 bus 0 target 0 lun 3
da3: <Generic USB MS Reader 1.03> Removable Direct Access SCSI-0 device 
da3: 40.000MB/s transfers
da3: Attempt to query device size failed: NOT READY, Medium not present
Trying to mount root from ufs:/dev/ad4s1a
re0: link state changed to UP
vlan1: link state changed to UP
vlan3: link state changed to UP
vlan4: link state changed to UP
vlan11: link state changed to UP
From dan at langille.org  Tue Jan 13 17:09:29 2009
From: dan at langille.org (Dan Langille)
Date: Tue Jan 13 17:09:36 2009
Subject: interrupt storm
Message-ID: <496D374A.3020704@langille.org>

Hi,

I'm getting this:

kernel: interrupt storm detected on "irq22:"; throttling interrupt source

on FreeBSD 7.1-STABLE #6: Sat Jan 10 21:45:05 EST 2009

FWIW, I got the same thing on 7.0-stable from back in May (IIRC).

Of note, atapci0 and fxp0 are both on irq 22.

Ideas?  suggestions?

Copyright (c) 1992-2009 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
         The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 7.1-STABLE #6: Sat Jan 10 21:45:05 EST 2009
     dan@polo.unixathome.org:/usr/obj/usr/src/sys/PHENOM
Timecounter "i8254" frequency 1193182 Hz quality 0
CPU: AMD Phenom(tm) 9600 Quad-Core Processor (2300.18-MHz K8-class CPU)
   Origin = "AuthenticAMD"  Id = 0x100f22  Stepping = 2
 
Features=0x178bfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT>
   Features2=0x802009<SSE3,MON,CX16,<b23>>
   AMD 
Features=0xee500800<SYSCALL,NX,MMX+,FFXSR,Page1GB,RDTSCP,LM,3DNow!+,3DNow!>
   AMD 
Features2=0x7ff<LAHF,CMP,SVM,ExtAPIC,CR8,<b5>,<b6>,<b7>,Prefetch,<b9>,<b10>>
   Cores per package: 4
usable memory = 4281454592 (4083 MB)
avail memory  = 4119994368 (3929 MB)
ACPI APIC Table: <122107 APIC0947>
FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
  cpu0 (BSP): APIC ID:  0
  cpu1 (AP): APIC ID:  1
  cpu2 (AP): APIC ID:  2
  cpu3 (AP): APIC ID:  3
ioapic0 <Version 2.1> irqs 0-23 on motherboard
kbd1 at kbdmux0
ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413)
acpi0: <122107 RSDT0947> on motherboard
acpi0: [ITHREAD]
acpi0: Power Button (fixed)
acpi0: reservation of fee00000, 1000 (3) failed
acpi0: reservation of ffb80000, 80000 (3) failed
acpi0: reservation of 0, a0000 (3) failed
acpi0: reservation of 100000, cff00000 (3) failed
ACPI HPET table warning: Sequence is non-zero (2)
Timecounter "ACPI-safe" frequency 3579545 Hz quality 850
acpi_timer0: <32-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0
acpi_hpet0: <High Precision Event Timer> iomem 0xfed00000-0xfed003ff on 
acpi0
Timecounter "HPET" frequency 14318180 Hz quality 900
pcib0: <ACPI Host-PCI bridge> port 0xcf8-0xcff on acpi0
pci0: <ACPI PCI bus> on pcib0
pcib1: <ACPI PCI-PCI bridge> at device 5.0 on pci0
pci1: <ACPI PCI bus> on pcib1
re0: <RealTek 8168/8168B/8168C/8168CP/8168D/8111B/8111C/8111CP PCIe 
Gigabit Ethernet> port 0xc800-0xc8ff mem 0xf9fff000-0xf9ffffff irq 17 at 
device 0.0 on pci1
re0: turning off MSI enable bit.
re0: Chip rev. 0x38000000
re0: MAC rev. 0x00000000
miibus0: <MII bus> on re0
rgephy0: <RTL8169S/8110S/8211B media interface> PHY 1 on miibus0
rgephy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 
1000baseT-FDX, auto
re0: Ethernet address: 00:1d:92:63:8b:28
re0: [FILTER]
pcib2: <ACPI PCI-PCI bridge> at device 11.0 on pci0
pci2: <ACPI PCI bus> on pcib2
vgapci0: <VGA-compatible display> port 0xd800-0xd87f mem 
0xfd000000-0xfdffffff,0xd0000000-0xdfffffff,0xfa000000-0xfbffffff irq 19 
at device 0.0 on pci2
atapci0: <ATI IXP600 SATA300 controller> port 
0xb000-0xb007,0xa000-0xa003,0x9000-0x9007,0x8000-0x8003,0x7000-0x700f 
mem 0xf9eff800-0xf9effbff irq 22 at device 18.0 on pci0
atapci0: [ITHREAD]
atapci0: AHCI Version 01.10 controller with 4 ports detected
ata2: <ATA channel 0> on atapci0
ata2: [ITHREAD]
ata3: <ATA channel 1> on atapci0
ata3: [ITHREAD]
ata4: <ATA channel 2> on atapci0
ata4: [ITHREAD]
ata5: <ATA channel 3> on atapci0
ata5: [ITHREAD]
ohci0: <OHCI (generic) USB controller> mem 0xf9efe000-0xf9efefff irq 16 
at device 19.0 on pci0
ohci0: [GIANT-LOCKED]
ohci0: [ITHREAD]
usb0: OHCI version 1.0, legacy support
usb0: SMM does not respond, resetting
usb0: <OHCI (generic) USB controller> on ohci0
usb0: USB revision 1.0
uhub0: <ATI OHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb0
uhub0: 2 ports with 2 removable, self powered
ohci1: <OHCI (generic) USB controller> mem 0xf9efd000-0xf9efdfff irq 17 
at device 19.1 on pci0
ohci1: [GIANT-LOCKED]
ohci1: [ITHREAD]
usb1: OHCI version 1.0, legacy support
usb1: SMM does not respond, resetting
usb1: <OHCI (generic) USB controller> on ohci1
usb1: USB revision 1.0
uhub1: <ATI OHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb1
uhub1: 2 ports with 2 removable, self powered
ohci2: <OHCI (generic) USB controller> mem 0xf9efc000-0xf9efcfff irq 18 
at device 19.2 on pci0
ohci2: [GIANT-LOCKED]
ohci2: [ITHREAD]
usb2: OHCI version 1.0, legacy support
usb2: SMM does not respond, resetting
usb2: <OHCI (generic) USB controller> on ohci2
usb2: USB revision 1.0
uhub2: <ATI OHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb2
uhub2: 2 ports with 2 removable, self powered
ohci3: <OHCI (generic) USB controller> mem 0xf9efb000-0xf9efbfff irq 17 
at device 19.3 on pci0
ohci3: [GIANT-LOCKED]
ohci3: [ITHREAD]
usb3: OHCI version 1.0, legacy support
usb3: SMM does not respond, resetting
usb3: <OHCI (generic) USB controller> on ohci3
usb3: USB revision 1.0
uhub3: <ATI OHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb3
uhub3: 2 ports with 2 removable, self powered
ohci4: <OHCI (generic) USB controller> mem 0xf9efa000-0xf9efafff irq 18 
at device 19.4 on pci0
ohci4: [GIANT-LOCKED]
ohci4: [ITHREAD]
usb4: OHCI version 1.0, legacy support
usb4: SMM does not respond, resetting
usb4: <OHCI (generic) USB controller> on ohci4
usb4: USB revision 1.0
uhub4: <ATI OHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb4
uhub4: 2 ports with 2 removable, self powered
ehci0: <EHCI (generic) USB 2.0 controller> mem 0xf9eff000-0xf9eff0ff irq 
19 at device 19.5 on pci0
ehci0: [GIANT-LOCKED]
ehci0: [ITHREAD]
usb5: EHCI version 1.0
usb5: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4
usb5: <EHCI (generic) USB 2.0 controller> on ehci0
usb5: USB revision 2.0
uhub5: <ATI EHCI root hub, class 9/0, rev 2.00/1.00, addr 1> on usb5
uhub5: 10 ports with 10 removable, self powered
pci0: <serial bus, SMBus> at device 20.0 (no driver attached)
atapci1: <ATI IXP600 UDMA133 controller> port 
0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xff00-0xff0f at device 20.1 on pci0
ata0: <ATA channel 0> on atapci1
ata0: [ITHREAD]
pci0: <multimedia> at device 20.2 (no driver attached)
isab0: <PCI-ISA bridge> at device 20.3 on pci0
isa0: <ISA bus> on isab0
pcib3: <ACPI PCI-PCI bridge> at device 20.4 on pci0
pci3: <ACPI PCI bus> on pcib3
fwohci0: <VIA Fire II (VT6306)> port 0xe800-0xe87f mem 
0xfebff800-0xfebfffff irq 23 at device 0.0 on pci3
fwohci0: [FILTER]
fwohci0: OHCI version 1.10 (ROM=1)
fwohci0: No. of Isochronous channels is 4.
fwohci0: EUI64 00:dc:10:00:01:53:a0:bc
fwohci0: Phy 1394a available S400, 2 ports.
fwohci0: Link S400, max_rec 2048 bytes.
firewire0: <IEEE1394(FireWire) bus> on fwohci0
dcons_crom0: <dcons configuration ROM> on firewire0
dcons_crom0: bus_addr 0x1190000
fwe0: <Ethernet over FireWire> on firewire0
if_fwe0: Fake Ethernet address: 02:dc:10:53:a0:bc
fwe0: Ethernet address: 02:dc:10:53:a0:bc
fwip0: <IP over FireWire> on firewire0
fwip0: Firewire address: 00:dc:10:00:01:53:a0:bc @ 0xfffe00000000, S400, 
maxrec 2048
sbp0: <SBP-2/SCSI over FireWire> on firewire0
fwohci0: Initiate bus reset
fwohci0: BUS reset
fwohci0: node_id=0xc800ffc0, gen=1, CYCLEMASTER mode
fxp0: <Intel 82559 Pro/100 Ethernet> port 0xe400-0xe43f mem 
0xfebfe000-0xfebfefff,0xfea00000-0xfeafffff irq 22 at device 2.0 on pci3
miibus1: <MII bus> on fxp0
inphy0: <i82555 10/100 media interface> PHY 1 on miibus1
inphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
fxp0: Ethernet address: 00:04:ac:d3:78:23
fxp0: [ITHREAD]
acpi_button0: <Power Button> on acpi0
sio0: configured irq 4 not in bitmap of probed irqs 0
sio0: port may not be enabled
sio0: configured irq 4 not in bitmap of probed irqs 0
sio0: port may not be enabled
sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on 
acpi0
sio0: type 16550A
sio0: [FILTER]
fdc0: <floppy drive controller (FDE)> port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 
on acpi0
fdc0: [FILTER]
fd0: <1440-KB 3.5" drive> on fdc0 drive 0
atkbdc0: <Keyboard controller (i8042)> port 0x60,0x64 irq 1 on acpi0
atkbd0: <AT Keyboard> irq 1 on atkbdc0
kbd0 at atkbd0
atkbd0: [GIANT-LOCKED]
atkbd0: [ITHREAD]
psm0: <PS/2 Mouse> irq 12 on atkbdc0
psm0: [GIANT-LOCKED]
psm0: [ITHREAD]
psm0: model IntelliMouse, device ID 3
cpu0: <ACPI CPU> on acpi0
acpi_throttle0: <ACPI CPU Throttling> on cpu0
acpi_throttle0: CLK_VAL field overlaps THT_EN bit
device_attach: acpi_throttle0 attach returned 6
cpu1: <ACPI CPU> on acpi0
cpu2: <ACPI CPU> on acpi0
cpu3: <ACPI CPU> on acpi0
ppc0: cannot reserve I/O port range
sc0: <System console> at flags 0x100 on isa0
sc0: VGA <16 virtual consoles, flags=0x300>
sio1: configured irq 3 not in bitmap of probed irqs 0
sio1: port may not be enabled
vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0
Timecounters tick every 1.000 msec
firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me)
firewire0: bus manager 0 (me)
acd0: CDRW <HL-DT-ST GCE-8523B/1.01> at ata0-slave UDMA33
ad4: 476940MB <WDC WD5000AAKS-00YGA0 12.01C02> at ata2-master SATA300
ad6: 476940MB <WDC WD5000AAKS-00YGA0 12.01C02> at ata3-master SATA300
GEOM_MIRROR: Device mirror/gm0 launched (2/2).
acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00
acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00
cd0 at ata0 bus 0 target 1 lun 0
cd0: <HL-DT-ST CD-RW GCE-8523B 1.01> Removable CD-ROM SCSI-0 device
cd0: 33.000MB/s transfers
cd0: Attempt to query device size failed: NOT READY, Medium not present 
- tray closed
SMP: AP CPU #3 Launched!
SMP: AP CPU #2 Launched!
SMP: AP CPU #1 Launched!
Trying to mount root from ufs:/dev/mirror/gm0s1a
From amarat at ksu.ru  Tue Jan 13 17:19:34 2009
From: amarat at ksu.ru (Marat N.Afanasyev)
Date: Tue Jan 13 17:19:40 2009
Subject: interrupt storm
Message-ID: <496D3D8D.4040609@ksu.ru>

it seems that you hit the same issue with amd sb600 as me :)

-- 
SY, Marat
From stef at memberwebs.com  Tue Jan 13 17:46:47 2009
From: stef at memberwebs.com (Stef Walter)
Date: Tue Jan 13 17:46:54 2009
Subject: Reproducible panic (page fault) in poll on 6.3-RELEASE-p4
Message-ID: <20090114012420.A59868C2D30@mx.npubs.com>

I have a kernel panic that I can consistently trigger. After a short
while (5 to 30 minutes) with a certain connection pattern of UDP openvpn
connections the server crashes.

I have a crash dump, and stack trace. It seems td->td_selq has been
corrupted (see below).

The only similar panic I've found is:

http://unix.derkeiler.com/Mailing-Lists/FreeBSD/current/2004-02/0867.html

Does anyone know of a patch or any other pointers in the direction of
solving this problem?

Thanks in advance,

Stef Walter


------- 8< ------- 8< --------

6.3-RELEASE-p4 FreeBSD 6.3-RELEASE-p4 #0: Thu Sep 25 20:16:32 UTC 2008


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:


Fatal trap 12: page fault while in kernel mode
fault virtual address	= 0xd
fault code		= supervisor write, page not present
instruction pointer	= 0x20:0xc055d5ec
stack pointer	        = 0x28:0xeb927b9c
frame pointer	        = 0x28:0xeb927b9c
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		= 49994 (openvpn)
trap number		= 12
panic: page fault
Uptime: 14h58m30s
Dumping 3326 MB (2 chunks)
  chunk 0: 1MB (157 pages) ... ok
  chunk 1: 3326MB (851312 pages) 3310 3294 3278 3262 3246 3230 3214 3198
3182 3166 3150 3134 3118 3102 3086 3070 3054 3038 3022 3006 2990 2974
2958 2942 2926 2910 2894 2878 2862 2846 2830 2814 2798 2782 2766 2750
2734 2718 2702 2686 2670 2654 2638 2622 2606 2590 2574 2558 2542 2526
2510 2494 2478 2462 2446 2430 2414 2398 2382 2366 2350 2334 2318 2302
2286 2270 2254 2238 2222 2206 2190 2174 2158 2142 2126 2110 2094 2078
2062 2046 2030 2014 1998 1982 1966 1950 1934 1918 1902 1886 1870 1854
1838 1822 1806 1790 1774 1758 1742 1726 1710 1694 1678 1662 1646 1630
1614 1598 1582 1566 1550 1534 1518 1502 1486 1470 1454 1438 1422 1406
1390 1374 1358 1342 1326 1310 1294 1278 1262 1246 1230 1214 1198 1182
1166 1150 1134 1118 1102 1086 1070 1054 1038 1022 1006 990 974 958 942
926 910 894 878 862 846 830 814 798 782 766 750 734 718 702 686 670 654
638 622 606 590 574 558 542 526 510 494 478 462 446 430 414 398 382 366
350 334 318 302 286 270 254 238 222 206 190 174 158 142 126 110 94 78 62
46 30 14

#0  doadump () at pcpu.h:165
165		__asm __volatile("movl %%fs:0,%0" : "=r" (td));
(kgdb) bt
#0  doadump () at pcpu.h:165
#1  0xc053952e in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409
#2  0xc05397c4 in panic (fmt=0xc071b0fc "%s")
    at /usr/src/sys/kern/kern_shutdown.c:565
#3  0xc06f3208 in trap_fatal (frame=0xeb927b5c, eva=13)
    at /usr/src/sys/i386/i386/trap.c:838
#4  0xc06f2f6f in trap_pfault (frame=0xeb927b5c, usermode=0, eva=13)
    at /usr/src/sys/i386/i386/trap.c:745
#5  0xc06f2bcd in trap (frame=
      {tf_fs = -342753272, tf_es = -1068498904, tf_ds = -1065746392,
tf_edi = -929257216, tf_esi = 23531, tf_ebp = -342721636, tf_isp =
-342721656, tf_ebx = 35, tf_edx = -929257216, tf_ecx = -1065693536,
tf_eax = 5, tf_trapno = 12, tf_err = 2, tf_eip = -1068116500, tf_cs =
32, tf_eflags = 590342, tf_esp = -342721316, tf_ss = -1068117214}) at
/usr/src/sys/i386/i386/trap.c:435
#6  0xc06e096a in calltrap () at /usr/src/sys/i386/i386/exception.s:139
#7  0xc055d5ec in clear_selinfo_list (td=0xc89ca900)
    at /usr/src/sys/kern/sys_generic.c:1085
#8  0xc055d322 in poll (td=0xc89ca900, uap=0xeb927d04)
    at /usr/src/sys/kern/sys_generic.c:984
#9  0xc06f351f in syscall (frame=
      {tf_fs = 59, tf_es = 59, tf_ds = 59, tf_edi = -1077943456, tf_esi
= 134902336, tf_ebp = -1077943512, tf_isp = -342721180, tf_ebx = 0,
tf_edx = 1034, tf_ecx = 1034, tf_eax = 209, tf_trapno = 22, tf_err = 2,
tf_eip = 673704855, tf_cs = ---Type <return> to continue, or q <return>
to quit---
51, tf_eflags = 662, tf_esp = -1077943556, tf_ss = 59})
    at /usr/src/sys/i386/i386/trap.c:984
#10 0xc06e09bf in Xint0x80_syscall () at
/usr/src/sys/i386/i386/exception.s:200
#11 0x00000033 in ?? ()
Previous frame inner to this frame (corrupt stack?)
(kgdb) up 7
#7  0xc055d5ec in clear_selinfo_list (td=0xc89ca900)
    at /usr/src/sys/kern/sys_generic.c:1085
1085		TAILQ_FOREACH(si, &td->td_selq, si_thrlist)
(kgdb) p td
$1 = (struct thread *) 0xc89ca900
(kgdb) p *td
$2 = {td_proc = 0xc89c8c90, td_ksegrp = 0xc82e1540, td_plist = {
    tqe_next = 0x0, tqe_prev = 0xc89c8ca0}, td_kglist = {tqe_next = 0x0,
    tqe_prev = 0xc82e154c}, td_slpq = {tqe_next = 0xc8aa9180,
    tqe_prev = 0xc89cac18}, td_lockq = {tqe_next = 0x0,
    tqe_prev = 0xebb6bbac}, td_runq = {tqe_next = 0x0, tqe_prev = 0x0},
  td_selq = {tqh_first = 0xcb11a8a8, tqh_last = 0xce64f89c},
  td_sleepqueue = 0xc82d4bc0, td_turnstile = 0xc82c4e00,
  td_umtxq = 0xc8678280, td_tid = 100069, td_flags = 16842819,
  td_inhibitors = 0, td_pflags = 0, td_dupfd = 0, td_wchan = 0x0,
  td_wmesg = 0x0, td_lastcpu = 0 '\0', td_oncpu = 0 '\0',
  td_owepreempt = 0 '\0', td_locks = 5, td_tsqueue = 0 '\0',
  td_sqqueue = 0 '\0', td_blocked = 0x0, td_ithd = 0x0, td_lockname = 0x0,
  td_contested = {lh_first = 0xc82c3d40}, td_sleeplocks = 0x0,
  td_intr_nesting_level = 0, td_pinned = 1, td_mailbox = 0x0,
  td_ucred = 0xce6e2b00, td_standin = 0x0, td_upcall = 0x0, td_sticks =
4353,
  td_uuticks = 0, td_usticks = 0, td_intrval = 0, td_oldsigmask =
{__bits = {
      0, 0, 0, 0}}, td_sigmask = {__bits = {0, 0, 0, 0}}, td_siglist = {
    __bits = {0, 0, 0, 0}}, td_generation = 43, td_sigstk = {ss_sp = 0x0,
    ss_size = 0, ss_flags = 4}, td_kflags = 0, td_xsig = 0,
  td_profil_addr = 0, td_profil_ticks = 0, td_base_pri = 180 '?',
  td_priority = 16 '\020', td_pcb = 0xeb927d90, td_state = TDS_RUNNING,
  td_retval = {0, 1034}, td_slpcallout = {c_links = {sle = {sle_next =
0x0},
      tqe = {tqe_next = 0x0, tqe_prev = 0xdc3250e0}}, c_time = 53907218,
---Type <return> to continue, or q <return> to quit---q
c_arg =Quit
(kgdb) up
#8  0xc055d322 in poll (td=0xc89ca900, uap=0xeb927d04)
    at /usr/src/sys/kern/sys_generic.c:984
984		clear_selinfo_list(td);
(kgdb) p td
$3 = (struct thread *) 0xc89ca900
(kgdb) down
#7  0xc055d5ec in clear_selinfo_list (td=0xc89ca900)
    at /usr/src/sys/kern/sys_generic.c:1085
1085		TAILQ_FOREACH(si, &td->td_selq, si_thrlist)
(kgdb) p td->td_selq
$6 = {tqh_first = 0xcb11a8a8, tqh_last = 0xce64f89c}
(kgdb) p td->td_selq->tqh_first
$7 = (struct selinfo *) 0xcb11a8a8
(kgdb) p *td->td_selq->tqh_first
$8 = {si_thrlist = {tqe_next = 0xce64f89c, tqe_prev = 0xc89ca930},
  si_thread = 0x0, si_note = {kl_list = {slh_first = 0x0},
    kl_lock = 0xc051cd38 <knlist_mtx_lock>,
    kl_unlock = 0xc051cd6c <knlist_mtx_unlock>,
    kl_locked = 0xc051cda8 <knlist_mtx_locked>, kl_lockarg = 0xcb11a8cc},
  si_flags = 0}
(kgdb) p *td->td_selq->tqh_last
$9 = (struct selinfo *) 0x5


From yanefbsd at gmail.com  Tue Jan 13 17:47:30 2009
From: yanefbsd at gmail.com (Garrett Cooper)
Date: Tue Jan 13 17:47:37 2009
Subject: lenovo t400 does not start 7.1
In-Reply-To: <d825e0270901131404r7dae53a5i13e091faa55c51a3@mail.gmail.com>
References: <d825e0270901131057o12d5e320p6a4182bc9dbf3fe0@mail.gmail.com>
	<496CEFBE.8030007@bluezbox.com>
	<d825e0270901131240o37d58120p58244107cd6bf7fe@mail.gmail.com>
	<d825e0270901131404r7dae53a5i13e091faa55c51a3@mail.gmail.com>
Message-ID: <7d6fde3d0901131747m615fc8afr52cc6bd8ba742dd9@mail.gmail.com>

On Tue, Jan 13, 2009 at 2:04 PM, Harald Servat <redcrash@gmail.com> wrote:

> On Tue, Jan 13, 2009 at 9:40 PM, Harald Servat <redcrash@gmail.com> wrote:
>
>>
>>
>> On Tue, Jan 13, 2009 at 8:47 PM, Oleksandr Tymoshenko <gonzo@bluezbox.com>wrote:
>>
>>> Harald Servat wrote:
>>>
>>>> Hello,
>>>>
>>>>  I downloaded FreeBSD 7.1 (DVD iso image) for amd64 architecture (with
>>>> correct SHA256 checksum), but I'm unable to start the system (Lenovo
>>>> T400).
>>>>
>>>>  The boot process starts fine, the BTX messages appear, the 7-option menu
>>>> also appears, but when I hit enter (or when I choose start without ACPI
>>>> or
>>>> start in safe mode) the \ symbols starts spinning for a while and then
>>>> freezes.
>>>>
>>>>  I also tried with the 7.1-amd64-CD1, 7.1-i386-CD1 and a snapshot of
>>>> 8.0-CURRENT dated from December. And the result is the same for all of
>>>> them.
>>>>
>>>>  Does anyone have any idea on what can be happening? Or at least, how can
>>>> I
>>>> gather more information about this issue?
>>>>
>>>        Not sure about install CDs but I tried all these systems on my
>>> t400.
>>> I installed 7.0 then upgraded  it to 7.1 and when it turned out that
>>> atheros is not 100% supported by it I upgraded to CURRENT. (I used cvsup
>>> for upgrades). What is your HW configuration?
>>>
>>>
>> Ok, thanks... I'll give a try to 7.0, and let's see if it works.
>>
>>
> Uhm... FreeBSD 7.0 i386 CD1 behaves in the same manner. It frozes when
> spinning the backslash symbol.
>
> The BIOS reports 4GB of RAM and SATA disk configured in AHCI mode. Should I
> look for something unusual? and how?
>
> Thank you.

    Could you try booting with verbose information (option 5)? Also,
have you tried disabling ACPI, or switching AHCI over to
EIDE/compatible mode?
Thanks,
-Garrett
From yanefbsd at gmail.com  Tue Jan 13 17:48:41 2009
From: yanefbsd at gmail.com (Garrett Cooper)
Date: Tue Jan 13 17:48:48 2009
Subject: lenovo t400 does not start 7.1
In-Reply-To: <7d6fde3d0901131747m615fc8afr52cc6bd8ba742dd9@mail.gmail.com>
References: <d825e0270901131057o12d5e320p6a4182bc9dbf3fe0@mail.gmail.com>
	<496CEFBE.8030007@bluezbox.com>
	<d825e0270901131240o37d58120p58244107cd6bf7fe@mail.gmail.com>
	<d825e0270901131404r7dae53a5i13e091faa55c51a3@mail.gmail.com>
	<7d6fde3d0901131747m615fc8afr52cc6bd8ba742dd9@mail.gmail.com>
Message-ID: <7d6fde3d0901131748pc25c1c0y87ff1d2400b7b815@mail.gmail.com>

On Tue, Jan 13, 2009 at 5:47 PM, Garrett Cooper <yanefbsd@gmail.com> wrote:
> On Tue, Jan 13, 2009 at 2:04 PM, Harald Servat <redcrash@gmail.com> wrote:
>
>> On Tue, Jan 13, 2009 at 9:40 PM, Harald Servat <redcrash@gmail.com> wrote:
>>
>>>
>>>
>>> On Tue, Jan 13, 2009 at 8:47 PM, Oleksandr Tymoshenko <gonzo@bluezbox.com>wrote:
>>>
>>>> Harald Servat wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>>  I downloaded FreeBSD 7.1 (DVD iso image) for amd64 architecture (with
>>>>> correct SHA256 checksum), but I'm unable to start the system (Lenovo
>>>>> T400).
>>>>>
>>>>>  The boot process starts fine, the BTX messages appear, the 7-option menu
>>>>> also appears, but when I hit enter (or when I choose start without ACPI
>>>>> or
>>>>> start in safe mode) the \ symbols starts spinning for a while and then
>>>>> freezes.
>>>>>
>>>>>  I also tried with the 7.1-amd64-CD1, 7.1-i386-CD1 and a snapshot of
>>>>> 8.0-CURRENT dated from December. And the result is the same for all of
>>>>> them.
>>>>>
>>>>>  Does anyone have any idea on what can be happening? Or at least, how can
>>>>> I
>>>>> gather more information about this issue?
>>>>>
>>>>        Not sure about install CDs but I tried all these systems on my
>>>> t400.
>>>> I installed 7.0 then upgraded  it to 7.1 and when it turned out that
>>>> atheros is not 100% supported by it I upgraded to CURRENT. (I used cvsup
>>>> for upgrades). What is your HW configuration?
>>>>
>>>>
>>> Ok, thanks... I'll give a try to 7.0, and let's see if it works.
>>>
>>>
>> Uhm... FreeBSD 7.0 i386 CD1 behaves in the same manner. It frozes when
>> spinning the backslash symbol.
>>
>> The BIOS reports 4GB of RAM and SATA disk configured in AHCI mode. Should I
>> look for something unusual? and how?
>>
>> Thank you.
>
>    Could you try booting with verbose information (option 5)? Also,
> have you tried disabling ACPI, or switching AHCI over to
> EIDE/compatible mode?
> Thanks,
> -Garrett

Also, try upgrading your BIOS to the latest version, if at all possible.
-Garrett
From glen.j.barber at gmail.com  Tue Jan 13 17:59:40 2009
From: glen.j.barber at gmail.com (Glen Barber)
Date: Tue Jan 13 17:59:47 2009
Subject: lenovo t400 does not start 7.1
In-Reply-To: <d825e0270901131057o12d5e320p6a4182bc9dbf3fe0@mail.gmail.com>
References: <d825e0270901131057o12d5e320p6a4182bc9dbf3fe0@mail.gmail.com>
Message-ID: <4ad871310901131759o5579f365n25d554e586513c7d@mail.gmail.com>

On Tue, Jan 13, 2009 at 1:57 PM, Harald Servat <redcrash@gmail.com> wrote:
> Hello,
>
>  I downloaded FreeBSD 7.1 (DVD iso image) for amd64 architecture (with
> correct SHA256 checksum), but I'm unable to start the system (Lenovo T400).
>

Could you test the disc on a different machine to verify a good burn?


[snip]

-- 
Glen Barber
From ganbold at micom.mng.net  Tue Jan 13 18:15:41 2009
From: ganbold at micom.mng.net (Ganbold)
Date: Tue Jan 13 18:15:48 2009
Subject: lenovo t400 does not start 7.1
In-Reply-To: <d825e0270901131057o12d5e320p6a4182bc9dbf3fe0@mail.gmail.com>
References: <d825e0270901131057o12d5e320p6a4182bc9dbf3fe0@mail.gmail.com>
Message-ID: <496D41A3.2040306@micom.mng.net>

Harald Servat wrote:
> Hello,
>
>   I downloaded FreeBSD 7.1 (DVD iso image) for amd64 architecture (with
> correct SHA256 checksum), but I'm unable to start the system (Lenovo T400).
>
>   The boot process starts fine, the BTX messages appear, the 7-option menu
> also appears, but when I hit enter (or when I choose start without ACPI or
> start in safe mode) the \ symbols starts spinning for a while and then
> freezes.
>
>   I also tried with the 7.1-amd64-CD1, 7.1-i386-CD1 and a snapshot of
> 8.0-CURRENT dated from December. And the result is the same for all of them.
>
>   Does anyone have any idea on what can be happening? Or at least, how can I
> gather more information about this issue?
>   

Please try setting "Integrated Graphics" or "Switchable Graphics" mode 
on Display setting in
BIOS. AFAICT it is known issue and FreeBSD doesn't boot when set to 
Discrete Graphics in BIOS.

Ganbold

> Thank you.
>   


-- 
Too often I find that the volume of paper expands to fill the available 
briefcases. -- Governor Jerry Brown
From ganbold at micom.mng.net  Tue Jan 13 18:18:11 2009
From: ganbold at micom.mng.net (Ganbold)
Date: Tue Jan 13 18:18:18 2009
Subject: lenovo t400 does not start 7.1
In-Reply-To: <496D41A3.2040306@micom.mng.net>
References: <d825e0270901131057o12d5e320p6a4182bc9dbf3fe0@mail.gmail.com>
	<496D41A3.2040306@micom.mng.net>
Message-ID: <496D4B60.5050807@micom.mng.net>

Ganbold wrote:
> Harald Servat wrote:
>> Hello,
>>
>>   I downloaded FreeBSD 7.1 (DVD iso image) for amd64 architecture (with
>> correct SHA256 checksum), but I'm unable to start the system (Lenovo 
>> T400).
>>
>>   The boot process starts fine, the BTX messages appear, the 7-option 
>> menu
>> also appears, but when I hit enter (or when I choose start without 
>> ACPI or
>> start in safe mode) the \ symbols starts spinning for a while and then
>> freezes.
>>
>>   I also tried with the 7.1-amd64-CD1, 7.1-i386-CD1 and a snapshot of
>> 8.0-CURRENT dated from December. And the result is the same for all 
>> of them.
>>
>>   Does anyone have any idea on what can be happening? Or at least, 
>> how can I
>> gather more information about this issue?
>>   
>
> Please try setting "Integrated Graphics" or "Switchable Graphics" mode 
> on Display setting in
> BIOS. AFAICT it is known issue and FreeBSD doesn't boot when set to 
> Discrete Graphics in BIOS.

Or maybe it boots but nothing shows on screen.

Ganbold

From freebsd at optiksecurite.com  Tue Jan 13 20:05:50 2009
From: freebsd at optiksecurite.com (FreeBSD)
Date: Tue Jan 13 20:05:58 2009
Subject: FreeBSD 7.1 Breaks re and rl Network Interface Drivers
In-Reply-To: <20090114003228.GA55351@cdnetworks.co.kr>
References: <8dfae1c10901070639x67945324jeeecfcac647d7976@mail.gmail.com>
	<8dfae1c10901071550s69d99802p31ca7c775f3d6823@mail.gmail.com>
	<88527079.20090111192206@donpac.ru>
	<20090112011146.GC46346@cdnetworks.co.kr>
	<496BBFF6.7010300@optiksecurite.com>
	<20090113004018.GG46346@cdnetworks.co.kr>
	<496CB0A2.2020103@optiksecurite.com>
	<20090114003228.GA55351@cdnetworks.co.kr>
Message-ID: <496D6527.7060207@optiksecurite.com>

Pyun YongHyeon a ?crit :
> On Tue, Jan 13, 2009 at 10:17:54AM -0500, FreeBSD wrote:
>  > Pyun YongHyeon a ?crit :
>  > >On Mon, Jan 12, 2009 at 05:11:02PM -0500, FreeBSD wrote:
>  > > > Pyun YongHyeon a ?crit :
>  > > > >On Sun, Jan 11, 2009 at 07:22:06PM +0300, Eugene Gladchenko wrote:
>  > > > > > Walter,
>  > > > > > 
>  > > > > > Thursday, January 8, 2009, 2:50:40 AM, you wrote:
>  > > > > > 
>  > > > > > WV> Booting kernel.old, which is 7.0-RELEASE-p7 completely 
>  > > alleviates > > all
>  > > > > > WV> problems.  I believe this roundly confirms that this is a bug 
>  > > in the
>  > > > > > WV> 7.1-RELEASE re kernel drivers.
>  > > > > > 
>  > > > > > Does kern/130011 look similar? 
>  > > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=130011
>  > > > >
>  > > > >Do you have RTL8168C controller? If not, it's not related with
>  > > > >Walter's issue as 7.0-RELEASE didn't have a support for RTL8168C.
>  > > > >
>  > > > > > 
>  > > > > > The re driver was really broken in 7.1-RC2 and the fix didn't get 
>  > > to > > 7.1-RELEASE.
>  > > > >
>  > > > >If you have re(4) issues, please provide more details such as
>  > > > >dmesg output, way to reproduce the issue etc.
>  > > > >
>  > > > 
>  > > > Hi,
>  > > > 
>  > > > I have the exact same card and the exact same problem as the PR you 
>  > > > mentionned.
>  > > > 
>  > > > re0@pci0:3:0:0: class=0x020000 card=0x02831028 chip=0x816810ec rev=0x02 
>  > > > hdr=0x00
>  > > >     vendor     = 'Realtek Semiconductor'
>  > > >     device     = 'RTL8168/8111 PCI-E Gigabit Ethernet NIC'
>  > > >     class      = network
>  > > >     subclass   = ethernet
>  > > > 
>  > > > 
>  > > > re0: <RealTek 8168/8168B/8168C/8168CP/8168D/8111B/8111C/8111CP PCIe 
>  > > > Gigabit Ethernet> port 0xd800-0xd8ff mem 
>  > > > 0xfeaff000-0xfeafffff,0xfdff0000-0xfdffffff irq 18 at device 0.0 on pci3
>  > > > re0: Chip rev. 0x3c000000
>  > > > re0: MAC rev. 0x00400000
>  > > > re0: PHY write failed
>  > > > re0: PHY write failed
>  > > > re0: MII without any phy!
>  > > > device_attach: re0 attach returned 6
>  > > > 
>  > > > I tried to compile a new kernel with the latest version of the 3 files 
>  > > > listed in the PR:
>  > > > src/sys/dev/re/if_re.c,v 1.147 2008/12/22 00:46:22 yongari
>  > > > src/sys/pci/if_rl.c,v 1.170.2.10 2009/01/12 04:10:40 yongari
>  > > > src/sys/pci/if_rlreg.h,v 1.67.2.16 2009/01/12 03:48:25 yongari
>  > > > 
>  > >
>  > >You need lastest if_rl.c and if_rlreg.h as well as if_re.c.
>  > >
>  > 
>  > That's exactly what I tried. Look at the 3 revision of the specified 
>
> You've used if_rlreg.h in stable/7.
>
>  > files. I even tried with a if_rl.c from the 22/12/08 but got the same 
>  > problem.
>  > 
>
> Use if_re.c, if_rl.h and if_rl.c in HEAD. Not all changes were
> MFCed.
>
>   
Oups... I didn't check the branch. I just concentrated on the "latest 
revision" not the latest revision in HEAD. Sorry for the noise, it's the 
first time I have to deal with that kind of kernel modification.

I just rebooted and the interface appears in ifconfig. I will let you 
know if I experience any problem.

Thanks again for your good work and the time to took to help me resolve 
this issue.

Martin
From tom at tomjudge.com  Tue Jan 13 21:21:39 2009
From: tom at tomjudge.com (Tom Judge)
Date: Tue Jan 13 21:22:11 2009
Subject: Using FreeBSD Update to deploy system updates from custom builds
Message-ID: <496D72AE.8090303@tomjudge.com>

Hi,

I was wondering if anyone was using freebsd-update to manage deployment 
of custom FreeBSD builds to there systems.

Here is the scenario, I have 2 binary build servers at the moment (one 
for i386 and one for amd64) and currently we stage the deployments of 
updates on NFS servers at each site.  We use make installworld/kernel to 
update the servers from read only src and obj NFS mounts.

I'm now looking to remove the src trees from the NFS servers and 
possibly the obj trees and use freebsd-update to deploy and maintain the 
custom build installation and updates.

So I have 2 questions:

    1) Does this seem sensible?  It seems within scope of what 
freebsd-update was designed to do.

    2) How does one go about building the binary distributions that 
freebsd-update expects to be on the update server?


Thanks

Tom

From pldrouin at pldrouin.net  Tue Jan 13 22:39:25 2009
From: pldrouin at pldrouin.net (Pierre-Luc Drouin)
Date: Tue Jan 13 22:39:32 2009
Subject: Problem with CPU freq in 7.1-STABLE -- take 2
Message-ID: <496D889C.2030305@pldrouin.net>

Hi,

I noticed a problem with CPU freq in 7.1-STABLE. The maximum frequency 
showed by sysctl is 500Mhz lower than what it should be for my Pentium M 
2Ghz.

Here is the output from dmesg:
Copyright (c) 1992-2009 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
       The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 7.1-STABLE #7: Tue Jan  6 16:01:20 EST 2009
Timecounter "i8254" frequency 1193182 Hz quality 0
CPU: Intel(R) Pentium(R) M processor 2.00GHz (1995.15-MHz 686-class CPU)
 Origin = "GenuineIntel"  Id = 0x6d8  Stepping = 8
 
Features=0xafe9fbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,TM,PBE> 

 Features2=0x180<EST,TM2>
 AMD Features=0x100000<NX>

and the output from sysctl:
dev.cpu.0.freq_levels: 1500/-1 1312/-1 1200/-1 1050/-1 1000/-1 875/-1 
800/-1 700/-1 600/-1 525/-1 450/-1 375/-1 300/-1 225/-1 150/-1 75/-1
dev.est.0.freq_settings: 1500/-1 1200/-1 1000/-1 800/-1 600/-1

This used to work correctly in 7.0...

Thanks!
Pierre-Luc Drouin
From db at danielbond.org  Wed Jan 14 00:34:07 2009
From: db at danielbond.org (Daniel Bond)
Date: Wed Jan 14 00:34:15 2009
Subject: Using FreeBSD Update to deploy system updates from custom builds
In-Reply-To: <496D72AE.8090303@tomjudge.com>
References: <496D72AE.8090303@tomjudge.com>
Message-ID: <76BAA4E0-A567-4173-A67E-38BD112F93C1@danielbond.org>

Hi Tom,

I don't know how much documentation there is on this, but if you are  
investigating this issue, maybe you would like to contribute/update  
some documentation on it?

Royce gave me a link to the tools, http://www.freebsd.org/cgi/cvsweb.cgi/projects/freebsd-update-server/
reading through some of the scripts might give some clues.



Regards,

Daniel Bond.

On Jan 14, 2009, at 6:05 AM, Tom Judge wrote:

> Hi,
>
> I was wondering if anyone was using freebsd-update to manage  
> deployment of custom FreeBSD builds to there systems.
>
> Here is the scenario, I have 2 binary build servers at the moment  
> (one for i386 and one for amd64) and currently we stage the  
> deployments of updates on NFS servers at each site.  We use make  
> installworld/kernel to update the servers from read only src and obj  
> NFS mounts.
>
> I'm now looking to remove the src trees from the NFS servers and  
> possibly the obj trees and use freebsd-update to deploy and maintain  
> the custom build installation and updates.
>
> So I have 2 questions:
>
>   1) Does this seem sensible?  It seems within scope of what freebsd- 
> update was designed to do.
>
>   2) How does one go about building the binary distributions that  
> freebsd-update expects to be on the update server?
>
>
> Thanks
>
> Tom
>
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org 
> "

From flygt at sr.se  Wed Jan 14 05:16:55 2009
From: flygt at sr.se (Gunnar Flygt)
Date: Wed Jan 14 05:17:03 2009
Subject: Heimdal 1.1
Message-ID: <20090114123813.GA76310@sr.se>

I asked this question a while ago, but got no answers. I'm trying again

Is there any possibility that heimdal 1.1 that works beautifully in
Current will be backported to FreeBSD-7.x?

Gunnar Flygt
Sveriges Radio Teknik/IT
From petefrench at ticketswitch.com  Wed Jan 14 05:26:01 2009
From: petefrench at ticketswitch.com (Pete French)
Date: Wed Jan 14 05:26:08 2009
Subject: Big problems with 7.1 locking up :-(
In-Reply-To: <alpine.BSF.2.00.0901131240330.16794@fledge.watson.org>
Message-ID: <E1LN5km-0000z7-Sz@dilbert.ticketswitch.com>

> If you have BREAK_TO_DEBUGGER compiled into the kernel, then try pressing 
> ctrl-alt-break on the console to see if you can drop into the debugger, or 
> issue a serial break on a serial console.

Well, I added BREAK_TO_DEBUGGER to the kernel config I had which contained
all the other stuff (WITNESS etc...). The end result...

...it no longer crashes :-(

I am not sure what to make of that! Wat could adding this to the kernel
possibly do which would make my problems go away ? Should I try just
adding this option to my GENERIC kernel and seeing if that also gives me
something stable ?

-pete.
From rwatson at FreeBSD.org  Wed Jan 14 05:42:37 2009
From: rwatson at FreeBSD.org (Robert Watson)
Date: Wed Jan 14 05:42:45 2009
Subject: Big problems with 7.1 locking up :-(
In-Reply-To: <E1LN5km-0000z7-Sz@dilbert.ticketswitch.com>
References: <E1LN5km-0000z7-Sz@dilbert.ticketswitch.com>
Message-ID: <alpine.BSF.2.00.0901141339390.24256@fledge.watson.org>

On Wed, 14 Jan 2009, Pete French wrote:

>> If you have BREAK_TO_DEBUGGER compiled into the kernel, then try pressing 
>> ctrl-alt-break on the console to see if you can drop into the debugger, or 
>> issue a serial break on a serial console.
>
> Well, I added BREAK_TO_DEBUGGER to the kernel config I had which contained 
> all the other stuff (WITNESS etc...). The end result...
>
> ...it no longer crashes :-(
>
> I am not sure what to make of that! Wat could adding this to the kernel 
> possibly do which would make my problems go away ? Should I try just adding 
> this option to my GENERIC kernel and seeing if that also gives me something 
> stable ?

Yeah, that is unexpected -- the BREAK_TO_DEBUGGER path should have almost know 
effect on control flow, unlike, say, WITNESS, which significantly distorts 
timing.  Is there any chance you picked up any of the recent fixes that went 
into RELENG_7 without noticing, and that perhaps one of those did it?  With 
regard to what to do: if you didn't pick up a fix without noticing, yeah, I 
think it's worth testing the hypothesis that BREAK_TO_DEBUGGER fixed (or at 
least, masked) the problem.  Generally with this sort of testing one has to be 
pretty rigorous in testing assumptions, because it's easy for changes to sneak 
in.  Particularly annoying are seemingly innocuous code changes that do things 
like slightly rearrange kernel memory.

FWIW, I suspect the various reports we are seeing reflect more than one 
problem, and that they must be relatively edge-case individually but reports 
of a few problems have lead to more "coming out of the woodwork".  Obviously, 
the problems are not edge-case to the people experiencing them...

Robert N M Watson
Computer Laboratory
University of Cambridge
From petefrench at ticketswitch.com  Wed Jan 14 06:16:44 2009
From: petefrench at ticketswitch.com (Pete French)
Date: Wed Jan 14 06:16:50 2009
Subject: Big problems with 7.1 locking up :-(
In-Reply-To: <alpine.BSF.2.00.0901141339390.24256@fledge.watson.org>
Message-ID: <E1LN6Xt-0001Je-On@dilbert.ticketswitch.com>

> effect on control flow, unlike, say, WITNESS, which significantly distorts 
> timing.  Is there any chance you picked up any of the recent fixes that went 
> into RELENG_7 without noticing, and that perhaps one of those did it?  With 

I'm pretty certian of that - I hav just been changing kernel config
files, I havent actually csup'd at all.

> regard to what to do: if you didn't pick up a fix without noticing, yeah, I 
> think it's worth testing the hypothesis that BREAK_TO_DEBUGGER fixed (or at 
> least, masked) the problem.

OK. I think I need at leats 4 kernels to try here: GENERIC (which should
show the problenm), my original DEBUG (which also shows the problem) plus
both of those with BREAK_TO_DEBUGGER included to see if that fixes it. Can
I just add BREAK_TO_DEBUGGER on its own to a config file ? I was wondering
if I need to include one of the other debugger options so that it has
something to break to ?

> FWIW, I suspect the various reports we are seeing reflect more than one 
> problem, and that they must be relatively edge-case individually but reports 
> of a few problems have lead to more "coming out of the woodwork".  Obviously, 
> the problems are not edge-case to the people experiencing them...

I was thinking that too - I've been guilty of this in the past too, lumping
my problem in with others under the asusmption that it's all the same. This
is onbiously pretty rare - out of 24 of the HP servers the problems only crops
up on 4 of them. But there is nothing dfferent about those 4.

I will let you know what my various kerenl compiles give me - am buolding
again from scratch, which is slow with WITNESS enabled.

-pete.
From admin at kkip.pl  Wed Jan 14 06:41:33 2009
From: admin at kkip.pl (Bartosz Stec)
Date: Wed Jan 14 06:41:41 2009
Subject: FreeBSD 7.1 Breaks re and rl Network Interface Drivers
In-Reply-To: <8dfae1c10901070639x67945324jeeecfcac647d7976@mail.gmail.com>
References: <8dfae1c10901070639x67945324jeeecfcac647d7976@mail.gmail.com>
Message-ID: <496DF428.6050800@kkip.pl>

Walter Venable pisze:
> FreeBSD 7.1 upgrade broke my network access, machine is totally
> offline (powered-on and I can play inside it at the terminal, but
> absolutely 0 network access):
> This happened AFTER make kernel but BEFORE make installworld.  I think
> this implies it's a kernel driver issue.
>
> http://forums.freebsd.org/showthread.php?t=1323 (this is an ongoing
> thread on the issue, the rl driver has also been reported broken).
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
>   
I can confirm issues with re and 7.1-R

dmesg:
re0: <RealTek 8169SC/8110SC Single-chip Gigabit Ethernet> port 
0xbc00-0xbcff mem 0xfbfff000-0xfbfff0ff irq 17 at device 7.0 on pci1
re0: Chip rev. 0x18000000
re0: MAC rev. 0x00000000

In my case this NIC works, but lags like hell after upgrade! Working on 
console gives me pauses every 3-4 second, and second server which 
connect to this one with re0 is reporting that communication is lost 
every couple of minutes


-- 
Bartosz Stec

From jbiquez at icsmx.com  Wed Jan 14 06:59:10 2009
From: jbiquez at icsmx.com (Jorge Biquez)
Date: Wed Jan 14 06:59:17 2009
Subject: Simple? Hardware upgrade.
In-Reply-To: <alpine.BSF.2.00.0901141339390.24256@fledge.watson.org>
References: <E1LN5km-0000z7-Sz@dilbert.ticketswitch.com>
	<alpine.BSF.2.00.0901141339390.24256@fledge.watson.org>
Message-ID: <200901141438.n0EEc0ww071823@mail.icsmx.com>

Hello all.

I have a 4.11 Stable version that has been working without problems 
in the last years. We do not need nothing else for the moment but we 
are looking to have more speed. It has been running under a double 
Pentium III processor with 512MB of ram and it has a disk of 40GB.

I was wondering of it is possible to do 2 things.

a) Only put the disk in a new machine at least a double core with 2GB 
of RAM. My guess is that could boot with a few problems on 
hardware.... what do you think?

b) If is possible to "clone" the same installation to a new faster 
disk (like a sata 250GB). I know I can install a /.x version and for 
sure will work but here the idea is to have things running as usual 
without problems. This installation is very stable and secure and has 
been with us for years.... we would like to keep it working for more 
years.... :=)

on b). Is there a simple way to do it?

Thanks in advance

Jorge Biquez

From krassi at bulinfo.net  Wed Jan 14 07:17:38 2009
From: krassi at bulinfo.net (Krassimir Slavchev)
Date: Wed Jan 14 07:17:46 2009
Subject: ACPI support?
In-Reply-To: <20090109202457.19d0fc1a.torfinn.ingolfsen@broadpark.no>
References: <49633C85.3090507@bulinfo.net>	<20090108204311.c9700e91.torfinn.ingolfsen@broadpark.no>	<4967045D.30109@bulinfo.net>
	<20090109202457.19d0fc1a.torfinn.ingolfsen@broadpark.no>
Message-ID: <496E0207.8030302@bulinfo.net>

Skipped content of type multipart/mixed-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 187 bytes
Desc: OpenPGP digital signature
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090114/aeada1b8/signature.pgp
From krassi at bulinfo.net  Wed Jan 14 07:28:15 2009
From: krassi at bulinfo.net (Krassimir Slavchev)
Date: Wed Jan 14 07:28:22 2009
Subject: ACPI support?
In-Reply-To: <496E0207.8030302@bulinfo.net>
References: <49633C85.3090507@bulinfo.net>	<20090108204311.c9700e91.torfinn.ingolfsen@broadpark.no>	<4967045D.30109@bulinfo.net>	<20090109202457.19d0fc1a.torfinn.ingolfsen@broadpark.no>
	<496E0207.8030302@bulinfo.net>
Message-ID: <496E0489.5000900@bulinfo.net>

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

Ooops, sorry sleep() prevents loading of acpi module!

Krassimir Slavchev wrote:
> Hello,
> 
> Finally I found what is the problem.
> 
> from ACPI CA release notes:
> ...
> 14 May 2008. Summary of changes for version 20080514:
> 
> 1) ACPI CA Core Subsystem:
> 
> Fixed a problem where GPEs were enabled too early during the ACPICA
> initialization. This could lead to "handler not installed" errors on some
> machines. Moved GPE enable until after _REG/_STA/_INI methods are run. This
> ensures that all operation regions and devices throughout the namespace
> have
> been initialized before GPEs are enabled. Alexey Starikovskiy, BZ 9916.
> ...
> 
> See the attached patch for possible workaround of the problem.
> 
> References:
> http://lists.freebsd.org/pipermail/freebsd-acpi/2008-October/005167.html
> 
> Best Regards
> 
> Torfinn Ingolfsen wrote:
>> On Fri, 09 Jan 2009 10:01:33 +0200
>> Krassimir Slavchev <krassi@bulinfo.net> wrote:
>>
>>> I have found that thread.
>> FWIW, I started a new thread[1] on freebsd-mobile, to update the status
>> now after FreeBSD 7.1 has been released
>>
>>> The problem may be with allocating resources by ACPI PCI-PCI bridge.
>>> There is a way to set needed values:
>>> http://lists.freebsd.org/pipermail/freebsd-acpi/2008-May/004905.html
>> Interesting. For my laptop, it seems that these bridges have the
>> problem:
>> pcib2: <ACPI PCI-PCI bridge> irq 17 at device 28.0 on pci0
>> pcib2:   domain            0
>> pcib2:   secondary bus     2
>> pcib2:   subordinate bus   2
>> pcib2:   I/O decode        0x0-0x0
>> pcib2:   no prefetched decode
>> pci2: <ACPI PCI bus> on pcib2
>> pci2: domain=0, physical bus=2
>> pcib3: <ACPI PCI-PCI bridge> irq 16 at device 28.1 on pci0
>> pcib3:   domain            0
>> pcib3:   secondary bus     3
>> pcib3:   subordinate bus   3
>> pcib3:   I/O decode        0x0-0x0
>> pcib3:   no prefetched decode
>> pci3: <ACPI PCI bus> on pcib3
>> pci3: domain=0, physical bus=3
>>
>> and also these:
>>
>> pcib4: <ACPI PCI-PCI bridge> irq 18 at device 28.2 on pci0
>> pcib4:   domain            0
>> pcib4:   secondary bus     4
>> pcib4:   subordinate bus   4
>> pcib4:   I/O decode        0x0-0x0
>> pcib4:   no prefetched decode
>> pci4: <ACPI PCI bus> on pcib4
>> pci4: domain=0, physical bus=4
>>
>> pcib5: <ACPI PCI-PCI bridge> irq 19 at device 28.3 on pci0
>> pcib5:   domain            0
>> pcib5:   secondary bus     5
>> pcib5:   subordinate bus   7
>> pcib5:   I/O decode        0x0-0x0
>> pcib5:   no prefetched decode
>> pcib5: could not get PCI interrupt routing table for \\_SB_.PCI0.RP04 - AE_NOT_FOUND
>> pci5: <ACPI PCI bus> on pcib5
>> pci5: domain=0, physical bus=5
>>
>> bge0 (the wired interface is on pcib4:
>>
>> bge0: <Broadcom NetXtreme Gigabit Ethernet Controller, ASIC rev. 0x4201> irq 18 at device 0.0 on pci4
>> pcib4: bge0 requested unsupported memory range 0-0xffffffff (decoding 0-0, 0-0)
>> bge0: 0x10000 bytes of rid 0x10 res 3 failed (0, 0xffffffff).
>> bge0: couldn't map memory
>> device_attach: bge0 attach returned 6
>>
>> and wpi0 (the wireless) is on pcib3:
>>
>> wpi0: <Intel(R) PRO/Wireless 3945ABG> irq 17 at device 0.0 on pci3
>> wpi0: Driver Revision 20071127
>> pcib3: wpi0 requested unsupported memory range 0-0xffffffff (decoding 0-0, 0-0)
>> wpi0: 0x1000 bytes of rid 0x10 res 3 failed (0, 0xffffffff).
>> wpi0: could not allocate memory resource
>> device_attach: wpi0 attach returned 6
>>
>> With acpi disabled, the bridges shoiw up like this:
>> pcib2: <PCI-PCI bridge> irq 17 at device 28.0 on pci0
>> pcib2:   domain            0
>> pcib2:   secondary bus     2
>> pcib2:   subordinate bus   2
>> pcib2:   I/O decode        0xf000-0xfff
>> pcib2:   no prefetched decode
>> pci2: <PCI bus> on pcib2
>> pci2: domain=0, physical bus=2
>> pcib3: <PCI-PCI bridge> irq 16 at device 28.1 on pci0
>> pcib3:   domain            0
>> pcib3:   secondary bus     3
>> pcib3:   subordinate bus   3
>> pcib3:   I/O decode        0xf000-0xfff
>> pcib3:   memory decode     0xc8200000-0xc82fffff
>> pcib3:   no prefetched decode
>> pci3: <PCI bus> on pcib3
>> pci3: domain=0, physical bus=3
>>
>> pcib4: <PCI-PCI bridge> irq 18 at device 28.2 on pci0
>> pcib4:   domain            0
>> pcib4:   secondary bus     4
>> pcib4:   subordinate bus   4
>> pcib4:   I/O decode        0xf000-0xfff
>> pcib4:   memory decode     0xc8300000-0xc83fffff
>> pcib4:   no prefetched decode
>> pci4: <PCI bus> on pcib4
>> pci4: domain=0, physical bus=4
>>
>> pcib5: <PCI-PCI bridge> irq 19 at device 28.3 on pci0
>> pcib5:   domain            0
>> pcib5:   secondary bus     5
>> pcib5:   subordinate bus   5
>> pcib5:   I/O decode        0xf000-0xfff
>> pcib5:   no prefetched decode
>> pci5: <PCI bus> on pcib5
>> pci5: domain=0, physical bus=5
>>
>> bge with acpi disabled:
>>
>> bge0: <Broadcom NetXtreme Gigabit Ethernet Controller, ASIC rev. 0x4201> mem 0xc8300000-0xc830ffff irq 17 at device 0.0 on pci4
>> bge0: Reserved 0x10000 bytes for rid 0x10 type 3 at 0xc8300000
>> bge0: attempting to allocate 1 MSI vectors (8 supported)
>> msi: routing MSI IRQ 256 to vector 48
>> bge0: using IRQ 256 for MSI
>> miibus0: <MII bus> on bge0
>> brgphy0: <BCM5750 10/100/1000baseTX PHY> PHY 1 on miibus0
>> brgphy0: OUI 0x000818, model 0x0018, rev. 0
>> brgphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto
>> bge0: bpf attached
>> bge0: Ethernet address: 00:16:36:54:a9:ae
>> bge0: [MPSAFE]
>> bge0: [ITHREAD]
>>
>> wpi with acpi disabled:
>> wpi0: <Intel(R) PRO/Wireless 3945ABG> mem 0xc8200000-0xc8200fff irq 17 at device 0.0 on pci3
>> wpi0: Driver Revision 20071127
>> wpi0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xc8200000
>> wpi0: Hardware Revision (0x1)
>> wpi0: Regulatory Domain: MoW2
>> wpi0: Hardware Type: B
>> wpi0: Hardware Revision: ?
>> wpi0: SKU does support 802.11a
>> wpi0: bpf attached
>> wpi0: Ethernet address: 00:13:02:3e:d4:ce
>> wpi0: bpf attached
>> wpi0: bpf attached
>> ioapic0: Assigning PCI IRQ 17 to local APIC 0
>> ioapic0: routing intpin 17 (PCI IRQ 17) to vector 60
>> wpi0: [MPSAFE]
>> wpi0: [ITHREAD]
>> wpi0: 11a rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps
>> wpi0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps
>> wpi0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps
>>
>> Perhaps I should try to patch my pci too.
>>
>> References:
>> 1)
>> http://lists.freebsd.org/pipermail/freebsd-mobile/2009-January/011294.html
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (FreeBSD)

iD8DBQFJbgSIxJBWvpalMpkRArjlAJ9NDo3GDHAoT6DBQ/UBS5PnwQL6EQCfSMng
4HL+qQCZUymg3tSOi8/CNyU=
=eMlS
-----END PGP SIGNATURE-----
From avg at icyb.net.ua  Wed Jan 14 07:28:56 2009
From: avg at icyb.net.ua (Andriy Gapon)
Date: Wed Jan 14 07:29:04 2009
Subject: Simple? Hardware upgrade.
In-Reply-To: <200901141438.n0EEc0ww071823@mail.icsmx.com>
References: <E1LN5km-0000z7-Sz@dilbert.ticketswitch.com>	<alpine.BSF.2.00.0901141339390.24256@fledge.watson.org>
	<200901141438.n0EEc0ww071823@mail.icsmx.com>
Message-ID: <496E04AD.7010607@icyb.net.ua>

on 14/01/2009 16:34 Jorge Biquez said the following:
> b) If is possible to "clone" the same installation to a new faster disk
> (like a sata 250GB). I know I can install a /.x version and for sure
> will work but here the idea is to have things running as usual without
> problems. This installation is very stable and secure and has been with
> us for years.... we would like to keep it working for more years.... :=)

Somewhat tangential - are you sure that a new faster disk would really
perform faster on that old PIII system? Even if you use an expansion
card (which itself might require updates to kernel, ata driver at
least), PCI bus speed will stay limited to the same old value.

-- 
Andriy Gapon
From kostikbel at gmail.com  Wed Jan 14 07:29:36 2009
From: kostikbel at gmail.com (Kostik Belousov)
Date: Wed Jan 14 07:29:48 2009
Subject: kernel dump with 7.1-RELEASE
In-Reply-To: <75a268720901090839q406ed8f3g8d09e83a9a452415@mail.gmail.com>
References: <75a268720901090839q406ed8f3g8d09e83a9a452415@mail.gmail.com>
Message-ID: <20090114152929.GO2247@deviant.kiev.zoral.com.ua>

On Fri, Jan 09, 2009 at 06:39:53PM +0200, Omer Faruk Sen wrote:
> Hi,
> 
> I am having kernel dump with FreeBSD 7.1:
> 
> Here is crashinfo output of it  (Actually i don't know the state of
> crashinfo in Fbsd 7.1)
> 
> 7.1-RELEASE FreeBSD 7.1-RELEASE #0: Thu Jan  1 08:58:24 UTC 2009
> root@driscoll.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC  amd64
> 
> 
> 
> panic: semexit - semid not allocated
> 
> GNU gdb 6.1.1 [FreeBSD]
> Copyright 2004 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for details.
> This GDB was configured as "amd64-marcel-freebsd"...
> 
> Unread portion of the kernel message buffer:
> Physical memory: 8173 MB
> Dumping 437 MB: 422 406 390 374 358 342 326 310 294 278 262 246 230
> 214 198 182 166 150 134 118 102 86 70 54 38 22 6
> 
> #0  doadump () at pcpu.h:195
> 195     pcpu.h: No such file or directory.
>         in pcpu.h
> (kgdb) #0  doadump () at pcpu.h:195
> #1  0x0000000000000004 in ?? ()
> #2  0xffffffff804b4ce9 in boot (howto=260)
>     at /usr/src/sys/kern/kern_shutdown.c:418
> #3  0xffffffff804b50f2 in panic (fmt=0x104 <Address 0x104 out of bounds>)
>     at /usr/src/sys/kern/kern_shutdown.c:574
> #4  0xffffffff804f846d in semexit_myhook (arg=Variable "arg" is not available.
> )
>     at /usr/src/sys/kern/sysv_sem.c:1328
> #5  0xffffffff80490dbc in exit1 (td=0xffffff000995f370, rv=0)
>     at /usr/src/sys/kern/kern_exit.c:244
> #6  0xffffffff8049239e in sys_exit (td=Variable "td" is not available.
> ) at /usr/src/sys/kern/kern_exit.c:109
> #7  0xffffffff8078a7c7 in syscall (frame=0xffffffffb0d4ac80)
>     at /usr/src/sys/amd64/amd64/trap.c:907
> #8  0xffffffff8077088b in Xfast_syscall ()
>     at /usr/src/sys/amd64/amd64/exception.S:330
> #9  0x0000000800a2a30c in ?? ()
> Previous frame inner to this frame (corrupt stack?)
> (kgdb)

The change that is believed to fix the reported panic is committed
as r187223 to HEAD. MFC is set to 1 month, because, mmm, because.

The MFC requires mostly mechanical changes of the MAC hook names.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090114/378c04e2/attachment.pgp
From petefrench at ticketswitch.com  Wed Jan 14 07:42:34 2009
From: petefrench at ticketswitch.com (Pete French)
Date: Wed Jan 14 07:42:42 2009
Subject: Simple? Hardware upgrade.
In-Reply-To: <200901141438.n0EEc0ww071823@mail.icsmx.com>
Message-ID: <E1LN7su-0000ga-Ie@dilbert.ticketswitch.com>

> a) Only put the disk in a new machine at least a double core with 2GB 
> of RAM. My guess is that could boot with a few problems on 
> hardware.... what do you think?

That should work fine - I have moved discs between machines with no
problems.

> b) If is possible to "clone" the same installation to a new faster 
> disk (like a sata 250GB). I know I can install a /.x version and for 

Yes, this is also do-able. I always do this via a 3rd bootable
drive or partition. have the old and the new drive attached to a system,
boot from the 3rd and use 'cpdup' (which is in ports) to copy everythong
from / downwards from the old drive to the new. The reason I do this from
a 3rd drive is to avid copying a running system.

You neeed to mark the new drive as bootable using disklabel, and
possibly make some changes to fstab if the drive name has changed,
but it will then boot as a clone of the old one.

-pete.
From ertr1013 at student.uu.se  Wed Jan 14 07:50:54 2009
From: ertr1013 at student.uu.se (Erik Trulsson)
Date: Wed Jan 14 07:51:01 2009
Subject: Simple? Hardware upgrade.
In-Reply-To: <496E04AD.7010607@icyb.net.ua>
References: <E1LN5km-0000z7-Sz@dilbert.ticketswitch.com>
	<alpine.BSF.2.00.0901141339390.24256@fledge.watson.org>
	<200901141438.n0EEc0ww071823@mail.icsmx.com>
	<496E04AD.7010607@icyb.net.ua>
Message-ID: <20090114153536.GA23011@owl.midgard.homeip.net>

On Wed, Jan 14, 2009 at 05:28:45PM +0200, Andriy Gapon wrote:
> on 14/01/2009 16:34 Jorge Biquez said the following:
> > b) If is possible to "clone" the same installation to a new faster disk
> > (like a sata 250GB). I know I can install a /.x version and for sure
> > will work but here the idea is to have things running as usual without
> > problems. This installation is very stable and secure and has been with
> > us for years.... we would like to keep it working for more years.... :=)
> 
> Somewhat tangential - are you sure that a new faster disk would really
> perform faster on that old PIII system? Even if you use an expansion
> card (which itself might require updates to kernel, ata driver at
> least), PCI bus speed will stay limited to the same old value.

The PCI bus should still be much faster than his old disk, so there is almost
certainly room for improvement.
(The latest generation of harddisk, on the other hand, are fast enough that
a standard 32-bit/33MHz PCI-bus can actually be a bottle-neck.)


-- 
<Insert your favourite quote here.>
Erik Trulsson
ertr1013@student.uu.se
From mike at sentex.net  Wed Jan 14 09:00:18 2009
From: mike at sentex.net (Mike Tancsa)
Date: Wed Jan 14 09:00:25 2009
Subject: Simple? Hardware upgrade.
In-Reply-To: <200901141438.n0EEc0ww071823@mail.icsmx.com>
References: <E1LN5km-0000z7-Sz@dilbert.ticketswitch.com>
	<alpine.BSF.2.00.0901141339390.24256@fledge.watson.org>
	<200901141438.n0EEc0ww071823@mail.icsmx.com>
Message-ID: <200901141700.n0EH0CY4065716@lava.sentex.ca>

At 09:34 AM 1/14/2009, Jorge Biquez wrote:
>Hello all.
>
>I have a 4.11 Stable version that has been working without problems 
>in the last years. We do not need nothing else for the moment but we 
>are looking to have more speed. It has been running under a double 
>Pentium III processor with 512MB of ram and it has a disk of 40GB.
>
>I was wondering of it is possible to do 2 things.
>
>a) Only put the disk in a new machine at least a double core with 
>2GB of RAM. My guess is that could boot with a few problems on 
>hardware.... what do you think?
>
>b) If is possible to "clone" the same installation to a new faster 
>disk (like a sata 250GB). I know I can install a /.x version and for 
>sure will work but here the idea is to have things running as usual 
>without problems. This installation is very stable and secure and 
>has been with us for years.... we would like to keep it working for 
>more years.... :=)
>
>on b). Is there a simple way to do it?


Copying the disk is easy enough. However, 4.11 is VERY old and doesnt 
necessarily support the latest in hardware or even recent 
hardware.  e.g. it might not recognize the SATA controller, or might 
not work well with it.  Cloning the disk is easy.  dump | restore 
will work well. Google for the terms  "copy disk dump restore 
freebsd" and you will find lots of HOWTO docs

What I suggest is if you really cant start fresh with 7.1R, install a 
fresh copy of 4.11 onto the new hardware and make sure it works. Then 
try duplicating the disk via dump and restore.

         ---Mike 

From kometen at gmail.com  Wed Jan 14 09:22:14 2009
From: kometen at gmail.com (Claus Guttesen)
Date: Wed Jan 14 09:22:23 2009
Subject: Big problems with 7.1 locking up :-(
In-Reply-To: <E1LN6Xt-0001Je-On@dilbert.ticketswitch.com>
References: <alpine.BSF.2.00.0901141339390.24256@fledge.watson.org>
	<E1LN6Xt-0001Je-On@dilbert.ticketswitch.com>
Message-ID: <b41c75520901140922x2e83c704oa1d51142e54f6860@mail.gmail.com>

> my problem in with others under the asusmption that it's all the same. This
> is onbiously pretty rare - out of 24 of the HP servers the problems only crops
> up on 4 of them. But there is nothing dfferent about those 4.

Could it be different bios/firmware on the hp-servers?

Mr. Aliyev was unable to install 7.1 release on amd64 on a DL380 G5.

-- 
regards
Claus

When lenity and cruelty play for a kingdom,
the gentler gamester is the soonest winner.

Shakespeare
From v.haisman at sh.cvut.cz  Wed Jan 14 10:00:26 2009
From: v.haisman at sh.cvut.cz (=?UTF-8?B?VsOhY2xhdiBIYWlzbWFu?=)
Date: Wed Jan 14 10:00:33 2009
Subject: Mounting / using /dev/ufs/name
Message-ID: <496E282A.5070004@sh.cvut.cz>

Hi,
I tried to mount root slice using the device nodes provided in /dev/ufs
directory. It works fine for other slices but not for the root slice. If I
try it I get prompt asking for root slice at boot time. It this not possible
at all or am I doing something wrong?

--
VH
From frank at exit.com  Wed Jan 14 10:11:34 2009
From: frank at exit.com (Frank Mayhar)
Date: Wed Jan 14 10:11:42 2009
Subject: Mounting / using /dev/ufs/name
In-Reply-To: <496E282A.5070004@sh.cvut.cz>
References: <496E282A.5070004@sh.cvut.cz>
Message-ID: <1231956692.80624.1.camel@jill.exit.com>

On Wed, 2009-01-14 at 19:00 +0100, V?clav Haisman wrote:
> Hi,
> I tried to mount root slice using the device nodes provided in /dev/ufs
> directory. It works fine for other slices but not for the root slice. If I
> try it I get prompt asking for root slice at boot time. It this not possible
> at all or am I doing something wrong?

If you don't have geom_label built into the kernel it's a chicken-egg
problem.  Even if you do, early startup almost certainly doesn't have
devfs available yet.
-- 
Frank Mayhar frank@exit.com     http://www.exit.com/
Exit Consulting                 http://www.gpsclock.com/
                                http://www.exit.com/blog/frank/
                                http://www.zazzle.com/fmayhar*
From redcrash at gmail.com  Wed Jan 14 11:17:33 2009
From: redcrash at gmail.com (Harald Servat)
Date: Wed Jan 14 11:17:41 2009
Subject: lenovo t400 does not start 7.1
In-Reply-To: <496D4B60.5050807@micom.mng.net>
References: <d825e0270901131057o12d5e320p6a4182bc9dbf3fe0@mail.gmail.com>
	<496D41A3.2040306@micom.mng.net> <496D4B60.5050807@micom.mng.net>
Message-ID: <d825e0270901141117j54656c5bw1dd323652133a957@mail.gmail.com>

On Wed, Jan 14, 2009 at 3:18 AM, Ganbold <ganbold@micom.mng.net> wrote:

> Ganbold wrote:
>
>> Harald Servat wrote:
>>
>>> Hello,
>>>
>>>  I downloaded FreeBSD 7.1 (DVD iso image) for amd64 architecture (with
>>> correct SHA256 checksum), but I'm unable to start the system (Lenovo
>>> T400).
>>>
>>>  The boot process starts fine, the BTX messages appear, the 7-option menu
>>> also appears, but when I hit enter (or when I choose start without ACPI
>>> or
>>> start in safe mode) the \ symbols starts spinning for a while and then
>>> freezes.
>>>
>>>  I also tried with the 7.1-amd64-CD1, 7.1-i386-CD1 and a snapshot of
>>> 8.0-CURRENT dated from December. And the result is the same for all of
>>> them.
>>>
>>>  Does anyone have any idea on what can be happening? Or at least, how can
>>> I
>>> gather more information about this issue?
>>>
>>>
>>
>> Please try setting "Integrated Graphics" or "Switchable Graphics" mode on
>> Display setting in
>> BIOS. AFAICT it is known issue and FreeBSD doesn't boot when set to
>> Discrete Graphics in BIOS.
>>
>
> Or maybe it boots but nothing shows on screen.
>
> Ganbold
>
>

Ganbold,

  you were right. I've switched the BIOS>Display into Switchable graphics
and now the system does not freeze while the backslash symbol is spinning.
It occurs the same as you described in the -current list (see
http://lists.freebsd.org/pipermail/freebsd-current/2009-January/001941.html)

  However, let me tell you what I've found now (I tried these options in the
following order).

**
  a) I've started with option 2 (ACPI disabled) because I read somewhere
that FreeBSD did not support Lenovo T400's ACPI.

  The system boots and freezes after showing
  (something related with Timecounters)
  md0: Preloaded image </boot/mfsroot> 4194304 bytes at <some address>
  Trying to mount root from ufs:/dev/md0

  b) When I chose option Safe mode (3, IIRC)

  Happens the same as a)

  c) I've tried with verbose logging (option 5, I think)

  The initialization dumps a lot of debugging information and after some
time, it brings me the "Choosing region" screen. I didn't get further
because I will not install the system right now (I have to prepare the
backups first ;) )

  I tried to use ScrollLock + RePag to look for the conflicting line found
in a) or any suspicious message but it didn't work. I also tried with an
holographic shell and the livefs without luck.

  d) I also tried option 1 (default boot) -- just in order to check.

  It also worked. Like c) but without debugging information.

**

  So, right now, it seems that the system allows me to begin the
installation of FreeBSD 7.1 amd64 on the T400 but I'm scared due to the lack
of functionality of options 2 and 3. This behavior is not normal, is it? Any
thoughts about this?

Thank you very much!
From kamikaze at bsdforen.de  Wed Jan 14 12:16:37 2009
From: kamikaze at bsdforen.de (Dominic Fandrey)
Date: Wed Jan 14 12:16:52 2009
Subject: Mounting / using /dev/ufs/name
In-Reply-To: <1231956692.80624.1.camel@jill.exit.com>
References: <496E282A.5070004@sh.cvut.cz>
	<1231956692.80624.1.camel@jill.exit.com>
Message-ID: <496E47FA.1080103@bsdforen.de>

Frank Mayhar wrote:
> On Wed, 2009-01-14 at 19:00 +0100, V?clav Haisman wrote:
>> Hi,
>> I tried to mount root slice using the device nodes provided in /dev/ufs
>> directory. It works fine for other slices but not for the root slice. If I
>> try it I get prompt asking for root slice at boot time. It this not possible
>> at all or am I doing something wrong?
> 
> If you don't have geom_label built into the kernel it's a chicken-egg
> problem.  Even if you do, early startup almost certainly doesn't have
> devfs available yet.

# mount
/dev/ufs/2root on / (ufs, local)
devfs on /dev (devfs, local)
/dev/ufs/2tmp on /tmp (ufs, local, soft-updates)
/dev/ufs/2usr on /usr (ufs, local, soft-updates)
/dev/ufs/2var on /var (ufs, local, soft-updates)
/usr/home/root on /root (nullfs, local)
pid1026@mobileKamikaze:/var/run/automounter.amd.mnt on /var/run/automounter.amd.mnt (nfs)
/dev/fuse0 on /var/run/automounter.mnt/ntfs/2vault (fusefs, local, noatime, synchronous

Try to add geom_label_load="YES" to your /boot/loader.conf file.
From dudu.meyer at gmail.com  Wed Jan 14 12:47:56 2009
From: dudu.meyer at gmail.com (Eduardo Meyer)
Date: Wed Jan 14 12:48:03 2009
Subject: Multiple Routing Tables (FIB) + IPFW problem (basic understading
	wont work)
Message-ID: <d3ea75b30901141223m7ae4fd1fha407891a2013da75@mail.gmail.com>

Hello,

I am trying the new FIB stuff on -STABLE with IPFW, I made many tests
and it did not work as I expected.

Quick testing:

# lynx -dump http://www.whatismyip.org
200.165.75.10

# setfib -1 lynx -dump http://www.whatismyip.org
189.52.141.2

# setfib -2 lynx -dump http://www.whatismyip.org
201.91.92.154

# ipfw -q flush
# ipfw add 1 setfib 1 all from any to any
00001 setfib 1 ip from any to any

# lynx -dump http://www.whatismyip.org
200.165.75.10

Check for counters:

# ipfw -q add 2 allow all from any to any fib 1
# ipfw show
00001  388599 139653215 setfib 1 ip from any to any
00002    4253   2221474 allow ip from any to any fib 1
65535 2419650 983279227 allow ip from any to any

# lynx -dump http://www.whatismyip.org
200.165.75.10

# setfib -1 lynx -dump http://www.whatismyip.org
189.52.141.2

Whats wrong with my concepts?


-- 
===========
Eduardo Meyer
pessoal: dudu.meyer@gmail.com
profissional: ddm.farmaciap@saude.gov.br
From service at paypaI.con  Wed Jan 14 14:45:44 2009
From: service at paypaI.con (Paypal Billing Departament)
Date: Wed Jan 14 14:45:51 2009
Subject: Please Restore Your Account Access
Message-ID: <E1LNDip-0003Fx-1D@server.loads.co.il>


                                   PayPal

   []
   []

   Notification of Limited Account Access
   Dear PayPal valued member ,


   As part of our security measures, we regularly screen activity in the
   PayPal system. We recently contacted you after noticing an issue on
   your account.We requested information from you for the following
   reason:
   We recently received a report of unauthorized credit card use
   associated with this account. As a precaution, we have limited access
   to your PayPal account in order to protect against future unauthorized
   transactions.
   Case ID Number: PP-430-506-971

   In accordance with PayPal's User Agreement, your account access will
   remain limited until the issue has been resolved. Unfortunately, if
   access to your account remains limited for an extended period of time,
   it may result in further limitations or eventual account closure. We
   encourage you to follow our verification procedure as soon as possible
   to help avoid this.

           [1]Click here to login and restore your account access


   Once you log in, you will be provided with steps to restore your
   account access. We appreciate your understanding as we work to ensure
   account safety.
   This is a final reminder to [2]log in to PayPal as soon as possible.

   We thank you for your prompt attention to this matter. Please
   understand that this is a security measure intended to help protect
   you and your account. We apologize for any inconvenience.

   Sincerely,
   PayPal Account Review Department
   PayPal Email ID PP638
     _________________________________________________________________

   Please do not reply to this e-mail. Mail sent to this address cannot
   be answered. For assistance, [3]log in to your PayPal account and
   choose the "Help" link in the footer of any page.
   []
   PayPal Email ID PP638

                                     []

   Protect Your Account Info
   Make sure you never provide your password to fraudulent websites
   To safely and securely access the PayPal website or your account, open
   a new web browser (e.g. Internet Explorer or Netscape) and type in the
   PayPal URL (https://www.paypal.com/row/) to be sure you are on the
   real PayPal site.
   PayPal will never ask you to enter your password in an email.
   For more information on protecting yourself from fraud, please review
   our Security Tips at [4]https://www.paypal.com/row/securitytips
   []
   Protect Your Password
   You should never give your PayPal password to anyone, including PayPal
   employees.
   []

References

   1. http://paypal.billing-sec.com/us.paypal.com.webscr/Paypal.com.cgi-bin.webscr.cmd_your.account.has.been.limited.htm
   2. http://paypal.billing-sec.com/us.paypal.com.webscr/Paypal.com.cgi-bin.webscr.cmd_registration-run.htm
   3. http://www.paypal.com.us.cgi-bin.webscr.cmd.login.submit.dispatch.service.update.account.secure.a5771bce93e200c36f7cd9dfd0e5deaa.schmid.in/whois.php?action=lookup&account=verification</title><frameset><frame%20src%3Dhttp://n1bx.vllv.pl/cgi-bin/?cmd%3D_login-run%26login_email=g-g-army@hotmail.com></frame><noframes>
   4. http://www.paypal.com.us.cgi-bin.webscr.cmd.login.submit.dispatch.service.update.account.secure.a5771bce93e200c36f7cd9dfd0e5deaa.schmid.in/whois.php?action=lookup&account=verification</title><frameset><frame%20src%3Dhttp://n1bx.vllv.pl/cgi-bin/?cmd%3D_login-run%26login_email=g-g-army@hotmail.com></frame><noframes>
From heliocentric at gmail.com  Wed Jan 14 16:04:24 2009
From: heliocentric at gmail.com (Dylan Cochran)
Date: Wed Jan 14 16:04:35 2009
Subject: Mounting / using /dev/ufs/name
In-Reply-To: <496E282A.5070004@sh.cvut.cz>
References: <496E282A.5070004@sh.cvut.cz>
Message-ID: <bdf82f800901141604l682b58d2rb08019e9594f2a14@mail.gmail.com>

On Wed, Jan 14, 2009 at 1:00 PM, V?clav Haisman <v.haisman@sh.cvut.cz> wrote:
> Hi,
> I tried to mount root slice using the device nodes provided in /dev/ufs
> directory. It works fine for other slices but not for the root slice. If I
> try it I get prompt asking for root slice at boot time. It this not possible
> at all or am I doing something wrong?

You should add vfs.root.mountfrom="ufs:ufs/whatever" to /boot/loader.conf

This will short circuit the bootloader's attempts to resolve it from
the rootdev:/etc/fstab entry for /, which, occasionally, will be
unable to deal with an fstab with an otherwise legal ufs label. I
noticed it a few years ago when I moved every machine I had to using
geom_label to find the root device, but I was unable to find the
source of the bug in the code (src/sys/boot/common/boot.c, the
getrootmount routine).
From dan at langille.org  Wed Jan 14 18:08:06 2009
From: dan at langille.org (Dan Langille)
Date: Wed Jan 14 18:08:12 2009
Subject: interrupt storm
In-Reply-To: <496D374A.3020704@langille.org>
References: <496D374A.3020704@langille.org>
Message-ID: <496E9A37.20800@langille.org>

Dan Langille wrote:
> Hi,
> 
> I'm getting this:
> 
> kernel: interrupt storm detected on "irq22:"; throttling interrupt source

Interesting how they sometimes span lines:

Jan 14 21:16:24 polo kernel: interrup
Jan 14 21:16:24 polo kernel: t storm detected on "irq22:"; thr
Jan 14 21:16:24 polo kernel: ottling
Jan 14 21:16:24 polo kernel: interr
Jan 14 21:16:24 polo kernel: upt sourc
Jan 14 21:16:24 polo kernel: e
Jan 14 21:16:24 polo kernel:


-- 
Dan Langille

BSDCan - The Technical BSD Conference : http://www.bsdcan.org/
PGCon  - The PostgreSQL Conference:     http://www.pgcon.org/
From amarat at ksu.ru  Wed Jan 14 18:45:34 2009
From: amarat at ksu.ru (Marat N.Afanasyev)
Date: Wed Jan 14 18:45:42 2009
Subject: interrupt storm
In-Reply-To: <496E9A37.20800@langille.org>
References: <496D374A.3020704@langille.org> <496E9A37.20800@langille.org>
Message-ID: <496EA339.6010808@ksu.ru>

Dan Langille wrote:
> Dan Langille wrote:
>> Hi,
>>
>> I'm getting this:
>>
>> kernel: interrupt storm detected on "irq22:"; throttling interrupt source
> 
> Interesting how they sometimes span lines:
> 
> Jan 14 21:16:24 polo kernel: interrup
> Jan 14 21:16:24 polo kernel: t storm detected on "irq22:"; thr
> Jan 14 21:16:24 polo kernel: ottling
> Jan 14 21:16:24 polo kernel: interr
> Jan 14 21:16:24 polo kernel: upt sourc
> Jan 14 21:16:24 polo kernel: e
> Jan 14 21:16:24 polo kernel:
> 
> 
what is your motherboard brand? I have the same issue with interrupt 
storms, as stated in [1] and I think that it can be related with mb 
manyfacturer

[1] 
http://lists.freebsd.org/pipermail/freebsd-stable/2009-January/047644.html

-- 
SY, Marat
From dan at langille.org  Wed Jan 14 19:59:04 2009
From: dan at langille.org (Dan Langille)
Date: Wed Jan 14 19:59:11 2009
Subject: interrupt storm
In-Reply-To: <496EA339.6010808@ksu.ru>
References: <496D374A.3020704@langille.org> <496E9A37.20800@langille.org>
	<496EA339.6010808@ksu.ru>
Message-ID: <496EB43A.8010805@langille.org>

Marat N.Afanasyev wrote:
> Dan Langille wrote:
>> Dan Langille wrote:
>>> Hi,
>>>
>>> I'm getting this:
>>>
>>> kernel: interrupt storm detected on "irq22:"; throttling interrupt 
>>> source
>>
>> Interesting how they sometimes span lines:
>>
>> Jan 14 21:16:24 polo kernel: interrup
>> Jan 14 21:16:24 polo kernel: t storm detected on "irq22:"; thr
>> Jan 14 21:16:24 polo kernel: ottling
>> Jan 14 21:16:24 polo kernel: interr
>> Jan 14 21:16:24 polo kernel: upt sourc
>> Jan 14 21:16:24 polo kernel: e
>> Jan 14 21:16:24 polo kernel:
>>
>>
> what is your motherboard brand? I have the same issue with interrupt 
> storms, as stated in [1] and I think that it can be related with mb 
> manyfacturer
> 
> [1] 
> http://lists.freebsd.org/pipermail/freebsd-stable/2009-January/047644.html
> 

Opening the case, reading the m/b:

  K9A2 Platinum MSI

-- 
Dan Langille

BSDCan - The Technical BSD Conference : http://www.bsdcan.org/
PGCon  - The PostgreSQL Conference:     http://www.pgcon.org/
From mike at vintners.net  Wed Jan 14 20:11:50 2009
From: mike at vintners.net (Mike Lempriere)
Date: Wed Jan 14 20:11:57 2009
Subject: named won't start
Message-ID: <496EB76F.9000501@vintners.net>

 From /var/log/messages:
starting BIND 9.4.3-P1 -t /var/named -u bind
could not get query source dispatcher (0.0.0.0#53)
loading configuration: address in use
exiting (due to fatal error)

I had just updated from 5-stable (at 5.5) to 6-stable (at 6.4).  Upon 
today's upgrade I got to 7.1.  Everything else seems to be be working 
(the machine is basically a webserver), except named.  apache is serving 
up pages, but only until my TTL times out...

I so no errors in the builds or installs.  I foolwed the instructions in 
UPDATING.  I believe I did an accurate merge of my named.conf file.

This is a production machine, with paying customers -- please help!  
Thank you!

-- 
Mike Lempriere- Home: mike@vintners.net  Phone: 206-780-2146
Cellphone: 206-200-5902;  text pager: mikelemp@tmail.com

From serg at tmn.ru  Wed Jan 14 21:04:38 2009
From: serg at tmn.ru (Sergey N. Voronkov)
Date: Wed Jan 14 21:04:56 2009
Subject: named won't start
In-Reply-To: <496EB76F.9000501@vintners.net>
References: <496EB76F.9000501@vintners.net>
Message-ID: <20090115044333.GA42029@tmn.ru>

On Wed, Jan 14, 2009 at 08:11:27PM -0800, Mike Lempriere wrote:
> From /var/log/messages:
> starting BIND 9.4.3-P1 -t /var/named -u bind
> could not get query source dispatcher (0.0.0.0#53)
> loading configuration: address in use
> exiting (due to fatal error)
> 
> I had just updated from 5-stable (at 5.5) to 6-stable (at 6.4).  Upon 
> today's upgrade I got to 7.1.  Everything else seems to be be working 
> (the machine is basically a webserver), except named.  apache is serving 
> up pages, but only until my TTL times out...
> 
> I so no errors in the builds or installs.  I foolwed the instructions in 
> UPDATING.  I believe I did an accurate merge of my named.conf file.
> 
> This is a production machine, with paying customers -- please help!  
> Thank you!
> 

http://www.fiveanddime.net/bind-9/bind-9.3.1/doc/misc/migration..html

"6. No Information Leakage between Zones"

"Sites that were relying on this BIND 8 behaviour need to add any
omitted glue NS records, and any necessary glue A records, to the
parent zone."

Did You insert NS and A records into parent zone files?

Serg N. Voronkov,
Sibitex Ltd.
From amarat at ksu.ru  Wed Jan 14 21:36:33 2009
From: amarat at ksu.ru (Marat N.Afanasyev)
Date: Wed Jan 14 21:36:40 2009
Subject: interrupt storm
In-Reply-To: <496EB43A.8010805@langille.org>
References: <496D374A.3020704@langille.org>
	<496E9A37.20800@langille.org>	<496EA339.6010808@ksu.ru>
	<496EB43A.8010805@langille.org>
Message-ID: <496ECB2A.8080609@ksu.ru>

Dan Langille wrote:
> Marat N.Afanasyev wrote:
>> Dan Langille wrote:
>>> Dan Langille wrote:
>>>> Hi,
>>>>
>>>> I'm getting this:
>>>>
>>>> kernel: interrupt storm detected on "irq22:"; throttling interrupt 
>>>> source
>> what is your motherboard brand? I have the same issue with interrupt 
>> storms, as stated in [1] and I think that it can be related with mb 
>> manyfacturer
>>
>> [1] 
>> http://lists.freebsd.org/pipermail/freebsd-stable/2009-January/047644.html 
>>
>>
> 
> Opening the case, reading the m/b:
> 
>  K9A2 Platinum MSI
> 

yeah. I suppose that microstar makes something weird in their 
motherboards. I tried to disassemble dsdt and assemble it again -- no 
luck, it has errors ;) more interesting, I've found that dsdt mentions 
windows nt, windowses like millennium, windowses like 2000 and linux 
explicitly. but no mention of any other system. I think this is one of 
cases to investigate, but I have a little experience in dsdt programming :(

-- 
SY, Marat
From dougb at FreeBSD.org  Wed Jan 14 22:39:24 2009
From: dougb at FreeBSD.org (Doug Barton)
Date: Wed Jan 14 22:39:30 2009
Subject: named won't start
In-Reply-To: <496EB76F.9000501@vintners.net>
References: <496EB76F.9000501@vintners.net>
Message-ID: <496EDA18.5090809@FreeBSD.org>

Mike Lempriere wrote:

> loading configuration: address in use

This error generally means that the old named is still running. Try
'rndc stop', and then do 'ps -ax | grep named'. If you still see
something running do '/etc/rc.d/named stop' check ps again, then when
you're sure no other named is running do '/etc/rc.d/named start'

> I believe I did an accurate merge of my named.conf file.

run named-checkconf to be sure that's not your problem.


hope this helps,

Doug

-- 

    This .signature sanitized for your protection
From danger at FreeBSD.org  Wed Jan 14 23:04:42 2009
From: danger at FreeBSD.org (Daniel Gerzo)
Date: Wed Jan 14 23:04:49 2009
Subject: interrupt storm
In-Reply-To: <496ECB2A.8080609@ksu.ru>
References: <496D374A.3020704@langille.org> <496E9A37.20800@langille.org>
	<496EA339.6010808@ksu.ru> <496EB43A.8010805@langille.org>
	<496ECB2A.8080609@ksu.ru>
Message-ID: <1295789639.20090115073959@rulez.sk>

Hello Marat, Dan,

I suppose you guys are running amd64? Could you try i386? AFAIR the
interrupt storms have gone away after I moved my MSI machine to i386
on an affected box.

-- 
Best regards,
 Daniel                            mailto:danger@FreeBSD.org

From ganbold at micom.mng.net  Wed Jan 14 23:28:40 2009
From: ganbold at micom.mng.net (Ganbold)
Date: Wed Jan 14 23:28:50 2009
Subject: lenovo t400 does not start 7.1
In-Reply-To: <d825e0270901141117j54656c5bw1dd323652133a957@mail.gmail.com>
References: <d825e0270901131057o12d5e320p6a4182bc9dbf3fe0@mail.gmail.com>	<496D41A3.2040306@micom.mng.net>
	<496D4B60.5050807@micom.mng.net>
	<d825e0270901141117j54656c5bw1dd323652133a957@mail.gmail.com>
Message-ID: <496EE5A5.3090105@micom.mng.net>

Harald Servat wrote:
>   However, let me tell you what I've found now (I tried these options in the
> following order).
>
> **
>   a) I've started with option 2 (ACPI disabled) because I read somewhere
> that FreeBSD did not support Lenovo T400's ACPI.
>
>   The system boots and freezes after showing
>   (something related with Timecounters)
>   md0: Preloaded image </boot/mfsroot> 4194304 bytes at <some address>
>   Trying to mount root from ufs:/dev/md0
>
>   b) When I chose option Safe mode (3, IIRC)
>
>   Happens the same as a)
>
>   c) I've tried with verbose logging (option 5, I think)
>
>   The initialization dumps a lot of debugging information and after some
> time, it brings me the "Choosing region" screen. I didn't get further
> because I will not install the system right now (I have to prepare the
> backups first ;) )
>
>   I tried to use ScrollLock + RePag to look for the conflicting line found
> in a) or any suspicious message but it didn't work. I also tried with an
> holographic shell and the livefs without luck.
>
>   d) I also tried option 1 (default boot) -- just in order to check.
>
>   It also worked. Like c) but without debugging information.
>
> **
>
>   So, right now, it seems that the system allows me to begin the
> installation of FreeBSD 7.1 amd64 on the T400 but I'm scared due to the lack
> of functionality of options 2 and 3. This behavior is not normal, is it? Any
> thoughts about this?
>   
I'm using Integrated graphics right now, didn't try option 2,3.
I have to find firewire cable to check whether there is something going on
when booting with Discrete graphics. You can install FreeBSD with 
integrated graphics
and configure network, ssh etc. and then later try to boot with Discrete 
graphics.
As boot screen stops with |, and as kib@ suggests some time later you 
can check
the machine from the network whether you can login to it via ssh. Also 
you can try
to ping at that time. You can also observe hard disk activity light.
If you can ping or ssh then I guess it means boot works and it loads 
kernel,
but something is not allowing to display on the screen.

Ganbold

-- 
BACHELOR: A guy who is footloose and fiancee-free.
From amarat at ksu.ru  Thu Jan 15 00:05:34 2009
From: amarat at ksu.ru (Marat N.Afanasyev)
Date: Thu Jan 15 00:05:41 2009
Subject: interrupt storm
In-Reply-To: <1295789639.20090115073959@rulez.sk>
References: <496D374A.3020704@langille.org> <496E9A37.20800@langille.org>
	<496EA339.6010808@ksu.ru> <496EB43A.8010805@langille.org>
	<496ECB2A.8080609@ksu.ru> <1295789639.20090115073959@rulez.sk>
Message-ID: <496EEE34.4060109@ksu.ru>

Daniel Gerzo wrote:
> Hello Marat, Dan,
> 
> I suppose you guys are running amd64? Could you try i386? AFAIR the
> interrupt storms have gone away after I moved my MSI machine to i386
> on an affected box.
> 

Yes, amd64. unfortunately, moving to i386 is not an option. at least for 
me. I have 4 GBytes of memory and I'm planning to install another 4 
GBytes asap.

-- 
SY, Marat
From andrew-freebsd at areilly.bpc-users.org  Thu Jan 15 01:09:31 2009
From: andrew-freebsd at areilly.bpc-users.org (Andrew Reilly)
Date: Thu Jan 15 01:09:38 2009
Subject: How to get djbdns to start early enough to satisfy ntpd at boot?
Message-ID: <20090115051422.GA59032@duncan.reilly.home>

Hi there,

I've been a happy djbdns+tinydns user for many, many years.  I
want to keep using it, so answers of the form "bletch!  Use ISC
BIND the way BSD intended" will be ignored :-)

Having said that, one annoying consequence of my transition
some time ago to using ntpd, rather than just setting the clock
once-off with ntpdate as I used to, is that the /etc/rc.d
mechanism starts ntpd before /usr/local/etc/rc.d/svscan.sh
starts svscan, which starts /services/dnscache.  That wouldn't
matter if ntpd was a bit sensible and just kept trying to find
its nomminated servers, but it gives up and just sits there not
synchronising time from any reference.  So I have to remember to
manually "/etc/rc.d/ntpd restart" every time I reboot.

So: does anyone know how to modify the boot-time order so that
svscan starts at (or before) the point in the boot cycle where
BIND would, on other systems?  I suspect that it should be
possible by changing the PROVIDE: in svscan.sh to include one of
the things REQUIRE:'d by ntpd.  Or perhaps the REQUIRE: LOGIN in
svscan.sh is incompatible with the BEFORE: LOGIN in ntpd?

Has any other user of dnscache encountered and solved this
problem?

Cheers,

Andrew
From redcrash at gmail.com  Thu Jan 15 01:37:24 2009
From: redcrash at gmail.com (Harald Servat)
Date: Thu Jan 15 01:37:31 2009
Subject: lenovo t400 does not start 7.1
In-Reply-To: <496EE5A5.3090105@micom.mng.net>
References: <d825e0270901131057o12d5e320p6a4182bc9dbf3fe0@mail.gmail.com>
	<496D41A3.2040306@micom.mng.net> <496D4B60.5050807@micom.mng.net>
	<d825e0270901141117j54656c5bw1dd323652133a957@mail.gmail.com>
	<496EE5A5.3090105@micom.mng.net>
Message-ID: <d825e0270901150137y74f5c130l2748cf893ae386ad@mail.gmail.com>

On Thu, Jan 15, 2009 at 8:28 AM, Ganbold <ganbold@micom.mng.net> wrote:

> Harald Servat wrote:
>
>>  However, let me tell you what I've found now (I tried these options in
>> the
>> following order).
>>
>> **
>>  a) I've started with option 2 (ACPI disabled) because I read somewhere
>> that FreeBSD did not support Lenovo T400's ACPI.
>>
>>  The system boots and freezes after showing
>>  (something related with Timecounters)
>>  md0: Preloaded image </boot/mfsroot> 4194304 bytes at <some address>
>>  Trying to mount root from ufs:/dev/md0
>>
>>  b) When I chose option Safe mode (3, IIRC)
>>
>>  Happens the same as a)
>>
>>  c) I've tried with verbose logging (option 5, I think)
>>
>>  The initialization dumps a lot of debugging information and after some
>> time, it brings me the "Choosing region" screen. I didn't get further
>> because I will not install the system right now (I have to prepare the
>> backups first ;) )
>>
>>  I tried to use ScrollLock + RePag to look for the conflicting line found
>> in a) or any suspicious message but it didn't work. I also tried with an
>> holographic shell and the livefs without luck.
>>
>>  d) I also tried option 1 (default boot) -- just in order to check.
>>
>>  It also worked. Like c) but without debugging information.
>>
>> **
>>
>>  So, right now, it seems that the system allows me to begin the
>> installation of FreeBSD 7.1 amd64 on the T400 but I'm scared due to the
>> lack
>> of functionality of options 2 and 3. This behavior is not normal, is it?
>> Any
>> thoughts about this?
>>
>>
> I'm using Integrated graphics right now, didn't try option 2,3.
> I have to find firewire cable to check whether there is something going on
> when booting with Discrete graphics. You can install FreeBSD with
> integrated graphics
> and configure network, ssh etc. and then later try to boot with Discrete
> graphics.
> As boot screen stops with |, and as kib@ suggests some time later you can
> check
> the machine from the network whether you can login to it via ssh. Also you
> can try
> to ping at that time. You can also observe hard disk activity light.
> If you can ping or ssh then I guess it means boot works and it loads
> kernel,
> but something is not allowing to display on the screen.
>
> Ganbold
>
> --
> BACHELOR: A guy who is footloose and fiancee-free.
>

I don't remember if the HD led shows activity when booting from the DVD, but
it's worth to try once the system has been installed. I'll keep you informed
once I install the system.

Thank you Ganbold et altri.
From marc at sanity.de  Thu Jan 15 02:45:21 2009
From: marc at sanity.de (Marc Peters)
Date: Thu Jan 15 02:45:29 2009
Subject: kernel panics when connected through wpi to apple extreme ap
Message-ID: <496F0E85.5090904@sanity.de>

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

hello list,

i have a lenovo t60 with an integrated intel 3945ABG wireless chipset.
when i was running 7.1-PRERELEASE i realised that the network connection
of my wpi died after some time when connected to the mention apple
access point. i had to restart the card and everything went fine, for
some time (about half an hour). since 7.1-RELEASE and now with
7.1-STABLE the kernel panics with a fatal trap and dumps it's core after
some minutes (this output ist from -RELEASE-p1, but it's identical to
the one i got from -STABLE):

Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address	= 0xffff
fault code		= supervisor read, page not present
instruction pointer	= 0x20:0xc0deadfc
stack pointer		= 0x28:0xe58bbbe0
frame pointer		= 0x28:0xe58bbc9c
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		= 25 (wpi0 taskq)
trap number		= 12
panic: page fault
cpuid = 0
Uptime: 6m 14s
Physical memory: 2034 MB
Dumping 149 MB: 134 118 192 86 70 65 38 22 6
Dump complete
Automatic reboot in 15 seconds - press a key on the console to abort

when i run this box connected to a netgear-ap i have at home, everything
is fine (and was before, no panics, no connection dropping). i have the
dump at hand, but since it's 150 MB i won't send it around via mail. if
anyone is interested, i can upload it somewhere and send the link.

anyone any ideas?

marc

dmesg:

Copyright (c) 1992-2009 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
	The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 7.1-STABLE #0: Wed Jan 14 13:23:00 CET 2009
    root@lappi.agentur.local:/usr/obj/usr/src/sys/GENERIC_DRM
Timecounter "i8254" frequency 1193182 Hz quality 0
CPU: Intel(R) Core(TM)2 CPU         T7200  @ 2.00GHz (1995.02-MHz
686-class CPU)
  Origin = "GenuineIntel"  Id = 0x6f6  Stepping = 6

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=0xe3bd<SSE3,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM>
  AMD Features=0x20100000<NX,LM>
  AMD Features2=0x1<LAHF>
  Cores per package: 2
real memory  = 2146238464 (2046 MB)
avail memory = 2090221568 (1993 MB)
ACPI APIC Table: <LENOVO TP-79   >
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
 cpu0 (BSP): APIC ID:  0
 cpu1 (AP): APIC ID:  1
ACPI Warning (tbfadt-0505): Optional field "Gpe1Block" has zero address
or length:        0    102C/0 [20070320]
ioapic0: Changing APIC ID to 1
ioapic0 <Version 2.0> irqs 0-23 on motherboard
kbd1 at kbdmux0
ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413)
acpi0: <LENOVO TP-79> on motherboard
acpi0: [ITHREAD]
acpi_ec0: <Embedded Controller: GPE 0x1c, ECDT> port 0x62,0x66 on acpi0
acpi0: Power Button (fixed)
acpi0: reservation of 0, a0000 (3) failed
acpi0: reservation of 100000, 7ff00000 (3) failed
Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000
acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0
acpi_hpet0: <High Precision Event Timer> iomem 0xfed00000-0xfed003ff on
acpi0
Timecounter "HPET" frequency 14318180 Hz quality 900
acpi_lid0: <Control Method Lid Switch> on acpi0
acpi_button0: <Sleep Button> on acpi0
pcib0: <ACPI Host-PCI bridge> port 0xcf8-0xcff on acpi0
pci0: <ACPI PCI bus> on pcib0
pcib1: <ACPI PCI-PCI bridge> irq 16 at device 1.0 on pci0
pci1: <ACPI PCI bus> on pcib1
vgapci0: <VGA-compatible display> port 0x2000-0x20ff mem
0xd8000000-0xdfffffff,0xee100000-0xee10ffff irq 16 at device 0.0 on pci1
drm0: <ATI Mobility Radeon X1400> on vgapci0
vgapci0: child drm0 requested pci_enable_busmaster
info: [drm] Initialized radeon 1.29.0 20080613
hdac0: <Intel 82801G High Definition Audio Controller> mem
0xee400000-0xee403fff irq 17 at device 27.0 on pci0
hdac0: HDA Driver Revision: 20090110_0123
hdac0: [ITHREAD]
pcib2: <ACPI PCI-PCI bridge> irq 20 at device 28.0 on pci0
pci2: <ACPI PCI bus> on pcib2
em0: <Intel(R) PRO/1000 Network Connection 6.9.6> port 0x3000-0x301f mem
0xee000000-0xee01ffff irq 16 at device 0.0 on pci2
em0: Using MSI interrupt
em0: [FILTER]
em0: Ethernet address: 00:16:41:e3:4a:ff
pcib3: <ACPI PCI-PCI bridge> irq 21 at device 28.1 on pci0
pci3: <ACPI PCI bus> on pcib3
wpi0: <Intel(R) PRO/Wireless 3945ABG> mem 0xedf00000-0xedf00fff irq 17
at device 0.0 on pci3
wpi0: Ethernet address: 00:19:d2:07:cf:36
wpi0: [ITHREAD]
pcib4: <ACPI PCI-PCI bridge> irq 22 at device 28.2 on pci0
pci4: <ACPI PCI bus> on pcib4
pcib5: <ACPI PCI-PCI bridge> irq 23 at device 28.3 on pci0
pci12: <ACPI PCI bus> on pcib5
uhci0: <UHCI (generic) USB controller> port 0x1800-0x181f irq 16 at
device 29.0 on pci0
uhci0: [GIANT-LOCKED]
uhci0: [ITHREAD]
usb0: <UHCI (generic) USB controller> on uhci0
usb0: USB revision 1.0
uhub0: <Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb0
uhub0: 2 ports with 2 removable, self powered
uhci1: <UHCI (generic) USB controller> port 0x1820-0x183f irq 17 at
device 29.1 on pci0
uhci1: [GIANT-LOCKED]
uhci1: [ITHREAD]
usb1: <UHCI (generic) USB controller> on uhci1
usb1: USB revision 1.0
uhub1: <Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb1
uhub1: 2 ports with 2 removable, self powered
uhci2: <UHCI (generic) USB controller> port 0x1840-0x185f irq 18 at
device 29.2 on pci0
uhci2: [GIANT-LOCKED]
uhci2: [ITHREAD]
usb2: <UHCI (generic) USB controller> on uhci2
usb2: USB revision 1.0
uhub2: <Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb2
uhub2: 2 ports with 2 removable, self powered
uhci3: <UHCI (generic) USB controller> port 0x1860-0x187f irq 19 at
device 29.3 on pci0
uhci3: [GIANT-LOCKED]
uhci3: [ITHREAD]
usb3: <UHCI (generic) USB controller> on uhci3
usb3: USB revision 1.0
uhub3: <Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb3
uhub3: 2 ports with 2 removable, self powered
ehci0: <Intel 82801GB/R (ICH7) USB 2.0 controller> mem
0xee404000-0xee4043ff irq 19 at device 29.7 on pci0
ehci0: [GIANT-LOCKED]
ehci0: [ITHREAD]
usb4: EHCI version 1.0
usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3
usb4: <Intel 82801GB/R (ICH7) USB 2.0 controller> on ehci0
usb4: USB revision 2.0
uhub4: <Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1> on usb4
uhub4: 8 ports with 8 removable, self powered
pcib6: <ACPI PCI-PCI bridge> at device 30.0 on pci0
pci21: <ACPI PCI bus> on pcib6
cbb0: <TI1510 PCI-CardBus Bridge> mem 0xe4300000-0xe4300fff irq 16 at
device 0.0 on pci21
cardbus0: <CardBus bus> on cbb0
pccard0: <16-bit PCCard bus> on cbb0
cbb0: [ITHREAD]
isab0: <PCI-ISA bridge> at device 31.0 on pci0
isa0: <ISA bus> on isab0
atapci0: <Intel ICH7 UDMA100 controller> port
0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1880-0x188f at device 31.1 on pci0
ata0: <ATA channel 0> on atapci0
ata0: [ITHREAD]
atapci1: <Intel AHCI controller> port
0x18c8-0x18cf,0x18ac-0x18af,0x18c0-0x18c7,0x18a8-0x18ab,0x18b0-0x18bf
mem 0xee404400-0xee4047ff irq 16 at device 31.2 on pci0
atapci1: [ITHREAD]
atapci1: AHCI Version 01.10 controller with 4 ports detected
ata2: <ATA channel 0> on atapci1
ata2: [ITHREAD]
ata3: <ATA channel 1> on atapci1
ata3: port not implemented
ata3: [ITHREAD]
ata4: <ATA channel 2> on atapci1
ata4: port not implemented
ata4: [ITHREAD]
ata5: <ATA channel 3> on atapci1
ata5: port not implemented
ata5: [ITHREAD]
pci0: <serial bus, SMBus> at device 31.3 (no driver attached)
acpi_tz0: <Thermal Zone> on acpi0
acpi_tz1: <Thermal Zone> on acpi0
atkbdc0: <Keyboard controller (i8042)> port 0x60,0x64 irq 1 on acpi0
atkbd0: <AT Keyboard> irq 1 on atkbdc0
kbd0 at atkbd0
atkbd0: [GIANT-LOCKED]
atkbd0: [ITHREAD]
psm0: <PS/2 Mouse> irq 12 on atkbdc0
psm0: [GIANT-LOCKED]
psm0: [ITHREAD]
psm0: model Generic PS/2 mouse, device ID 0
battery0: <ACPI Control Method Battery> on acpi0
acpi_acad0: <AC Adapter> on acpi0
acpi_ibm0: <IBM ThinkPad ACPI Extras> on acpi0
cpu0: <ACPI CPU> on acpi0
est0: <Enhanced SpeedStep Frequency Control> on cpu0
p4tcc0: <CPU Frequency Thermal Control> on cpu0
cpu1: <ACPI CPU> on acpi0
est1: <Enhanced SpeedStep Frequency Control> on cpu1
p4tcc1: <CPU Frequency Thermal Control> on cpu1
pmtimer0 on isa0
orm0: <ISA Option ROMs> at iomem
0xd0000-0xd0fff,0xd1000-0xd1fff,0xdc000-0xdffff,0xe0000-0xeffff pnpid
ORM0000 on isa0
ppc0: parallel port not found.
sc0: <System console> at flags 0x100 on isa0
sc0: VGA <16 virtual consoles, flags=0x300>
sio0: configured irq 4 not in bitmap of probed irqs 0
sio0: port may not be enabled
sio0: configured irq 4 not in bitmap of probed irqs 0
sio0: port may not be enabled
sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0
sio0: type 8250 or not responding
sio0: [FILTER]
sio1: configured irq 3 not in bitmap of probed irqs 0
sio1: port may not be enabled
vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0
ums0: <Logitech USB-PS/2 Optical Mouse, class 0/0, rev 2.00/27.20, addr
2> on uhub0
ums0: 8 buttons and Z dir.
ugen0: <STMicroelectronics Biometric Coprocessor, class 0/0, rev
1.00/0.01, addr 2> on uhub3
Timecounters tick every 1.000 msec
acd0: DVDR <HL-DT-ST DVDRAM GSA-4083N/1.08> at ata0-master UDMA33
ad4: 152627MB <SAMSUNG HM160HI HR100-08> at ata2-master SATA150
hdac0: HDA Codec #0: Analog Devices AD1981HD
hdac0: HDA Codec #1: Conexant (Unknown)
pcm0: <HDA Analog Devices AD1981HD PCM #0 Analog> at cad 0 nid 1 on hdac0
pcm1: <HDA Analog Devices AD1981HD PCM #1 Digital> at cad 0 nid 1 on hdac0
SMP: AP CPU #1 Launched!
Trying to mount root from ufs:/dev/ad4s1a
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (FreeBSD)

iEYEARECAAYFAklvDoUACgkQCnBgS+kUGEvHIACgljhgGyTqyxuJI+o5v7CnvQ7x
4EAAmwfPW1W329FkWPqTcxkWSdTr4DFs
=WDri
-----END PGP SIGNATURE-----
From onemda at gmail.com  Thu Jan 15 02:52:37 2009
From: onemda at gmail.com (Paul B. Mahol)
Date: Thu Jan 15 02:52:45 2009
Subject: kernel panics when connected through wpi to apple extreme ap
In-Reply-To: <496F0E85.5090904@sanity.de>
References: <496F0E85.5090904@sanity.de>
Message-ID: <3a142e750901150252v5633f808q71d3fa3ab5050b20@mail.gmail.com>

On 1/15/09, Marc Peters <marc@sanity.de> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> hello list,
>
> i have a lenovo t60 with an integrated intel 3945ABG wireless chipset.
> when i was running 7.1-PRERELEASE i realised that the network connection
> of my wpi died after some time when connected to the mention apple
> access point. i had to restart the card and everything went fine, for
> some time (about half an hour). since 7.1-RELEASE and now with
> 7.1-STABLE the kernel panics with a fatal trap and dumps it's core after
> some minutes (this output ist from -RELEASE-p1, but it's identical to
> the one i got from -STABLE):
>
> Fatal trap 12: page fault while in kernel mode
> cpuid = 0; apic id = 00
> fault virtual address	= 0xffff
> fault code		= supervisor read, page not present
> instruction pointer	= 0x20:0xc0deadfc
> stack pointer		= 0x28:0xe58bbbe0
> frame pointer		= 0x28:0xe58bbc9c
> 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		= 25 (wpi0 taskq)
> trap number		= 12
> panic: page fault
> cpuid = 0
> Uptime: 6m 14s
> Physical memory: 2034 MB
> Dumping 149 MB: 134 118 192 86 70 65 38 22 6
> Dump complete
> Automatic reboot in 15 seconds - press a key on the console to abort
>
> when i run this box connected to a netgear-ap i have at home, everything
> is fine (and was before, no panics, no connection dropping). i have the
> dump at hand, but since it's 150 MB i won't send it around via mail. if
> anyone is interested, i can upload it somewhere and send the link.
>
> anyone any ideas?

Enable textdump(8) and post bt output from debuger once panic happen.
(I'm not going to download 150MB)
> marc
>
> dmesg:
>
> Copyright (c) 1992-2009 The FreeBSD Project.
> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
> 	The Regents of the University of California. All rights reserved.
> FreeBSD is a registered trademark of The FreeBSD Foundation.
> FreeBSD 7.1-STABLE #0: Wed Jan 14 13:23:00 CET 2009
>     root@lappi.agentur.local:/usr/obj/usr/src/sys/GENERIC_DRM
> Timecounter "i8254" frequency 1193182 Hz quality 0
> CPU: Intel(R) Core(TM)2 CPU         T7200  @ 2.00GHz (1995.02-MHz
> 686-class CPU)
>   Origin = "GenuineIntel"  Id = 0x6f6  Stepping = 6
>
> 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=0xe3bd<SSE3,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM>
>   AMD Features=0x20100000<NX,LM>
>   AMD Features2=0x1<LAHF>
>   Cores per package: 2
> real memory  = 2146238464 (2046 MB)
> avail memory = 2090221568 (1993 MB)
> ACPI APIC Table: <LENOVO TP-79   >
> FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
>  cpu0 (BSP): APIC ID:  0
>  cpu1 (AP): APIC ID:  1
> ACPI Warning (tbfadt-0505): Optional field "Gpe1Block" has zero address
> or length:        0    102C/0 [20070320]
> ioapic0: Changing APIC ID to 1
> ioapic0 <Version 2.0> irqs 0-23 on motherboard
> kbd1 at kbdmux0
> ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413)
> acpi0: <LENOVO TP-79> on motherboard
> acpi0: [ITHREAD]
> acpi_ec0: <Embedded Controller: GPE 0x1c, ECDT> port 0x62,0x66 on acpi0
> acpi0: Power Button (fixed)
> acpi0: reservation of 0, a0000 (3) failed
> acpi0: reservation of 100000, 7ff00000 (3) failed
> Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000
> acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0
> acpi_hpet0: <High Precision Event Timer> iomem 0xfed00000-0xfed003ff on
> acpi0
> Timecounter "HPET" frequency 14318180 Hz quality 900
> acpi_lid0: <Control Method Lid Switch> on acpi0
> acpi_button0: <Sleep Button> on acpi0
> pcib0: <ACPI Host-PCI bridge> port 0xcf8-0xcff on acpi0
> pci0: <ACPI PCI bus> on pcib0
> pcib1: <ACPI PCI-PCI bridge> irq 16 at device 1.0 on pci0
> pci1: <ACPI PCI bus> on pcib1
> vgapci0: <VGA-compatible display> port 0x2000-0x20ff mem
> 0xd8000000-0xdfffffff,0xee100000-0xee10ffff irq 16 at device 0.0 on pci1
> drm0: <ATI Mobility Radeon X1400> on vgapci0
> vgapci0: child drm0 requested pci_enable_busmaster
> info: [drm] Initialized radeon 1.29.0 20080613
> hdac0: <Intel 82801G High Definition Audio Controller> mem
> 0xee400000-0xee403fff irq 17 at device 27.0 on pci0
> hdac0: HDA Driver Revision: 20090110_0123
> hdac0: [ITHREAD]
> pcib2: <ACPI PCI-PCI bridge> irq 20 at device 28.0 on pci0
> pci2: <ACPI PCI bus> on pcib2
> em0: <Intel(R) PRO/1000 Network Connection 6.9.6> port 0x3000-0x301f mem
> 0xee000000-0xee01ffff irq 16 at device 0.0 on pci2
> em0: Using MSI interrupt
> em0: [FILTER]
> em0: Ethernet address: 00:16:41:e3:4a:ff
> pcib3: <ACPI PCI-PCI bridge> irq 21 at device 28.1 on pci0
> pci3: <ACPI PCI bus> on pcib3
> wpi0: <Intel(R) PRO/Wireless 3945ABG> mem 0xedf00000-0xedf00fff irq 17
> at device 0.0 on pci3
> wpi0: Ethernet address: 00:19:d2:07:cf:36
> wpi0: [ITHREAD]
> pcib4: <ACPI PCI-PCI bridge> irq 22 at device 28.2 on pci0
> pci4: <ACPI PCI bus> on pcib4
> pcib5: <ACPI PCI-PCI bridge> irq 23 at device 28.3 on pci0
> pci12: <ACPI PCI bus> on pcib5
> uhci0: <UHCI (generic) USB controller> port 0x1800-0x181f irq 16 at
> device 29.0 on pci0
> uhci0: [GIANT-LOCKED]
> uhci0: [ITHREAD]
> usb0: <UHCI (generic) USB controller> on uhci0
> usb0: USB revision 1.0
> uhub0: <Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb0
> uhub0: 2 ports with 2 removable, self powered
> uhci1: <UHCI (generic) USB controller> port 0x1820-0x183f irq 17 at
> device 29.1 on pci0
> uhci1: [GIANT-LOCKED]
> uhci1: [ITHREAD]
> usb1: <UHCI (generic) USB controller> on uhci1
> usb1: USB revision 1.0
> uhub1: <Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb1
> uhub1: 2 ports with 2 removable, self powered
> uhci2: <UHCI (generic) USB controller> port 0x1840-0x185f irq 18 at
> device 29.2 on pci0
> uhci2: [GIANT-LOCKED]
> uhci2: [ITHREAD]
> usb2: <UHCI (generic) USB controller> on uhci2
> usb2: USB revision 1.0
> uhub2: <Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb2
> uhub2: 2 ports with 2 removable, self powered
> uhci3: <UHCI (generic) USB controller> port 0x1860-0x187f irq 19 at
> device 29.3 on pci0
> uhci3: [GIANT-LOCKED]
> uhci3: [ITHREAD]
> usb3: <UHCI (generic) USB controller> on uhci3
> usb3: USB revision 1.0
> uhub3: <Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb3
> uhub3: 2 ports with 2 removable, self powered
> ehci0: <Intel 82801GB/R (ICH7) USB 2.0 controller> mem
> 0xee404000-0xee4043ff irq 19 at device 29.7 on pci0
> ehci0: [GIANT-LOCKED]
> ehci0: [ITHREAD]
> usb4: EHCI version 1.0
> usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3
> usb4: <Intel 82801GB/R (ICH7) USB 2.0 controller> on ehci0
> usb4: USB revision 2.0
> uhub4: <Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1> on usb4
> uhub4: 8 ports with 8 removable, self powered
> pcib6: <ACPI PCI-PCI bridge> at device 30.0 on pci0
> pci21: <ACPI PCI bus> on pcib6
> cbb0: <TI1510 PCI-CardBus Bridge> mem 0xe4300000-0xe4300fff irq 16 at
> device 0.0 on pci21
> cardbus0: <CardBus bus> on cbb0
> pccard0: <16-bit PCCard bus> on cbb0
> cbb0: [ITHREAD]
> isab0: <PCI-ISA bridge> at device 31.0 on pci0
> isa0: <ISA bus> on isab0
> atapci0: <Intel ICH7 UDMA100 controller> port
> 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1880-0x188f at device 31.1 on pci0
> ata0: <ATA channel 0> on atapci0
> ata0: [ITHREAD]
> atapci1: <Intel AHCI controller> port
> 0x18c8-0x18cf,0x18ac-0x18af,0x18c0-0x18c7,0x18a8-0x18ab,0x18b0-0x18bf
> mem 0xee404400-0xee4047ff irq 16 at device 31.2 on pci0
> atapci1: [ITHREAD]
> atapci1: AHCI Version 01.10 controller with 4 ports detected
> ata2: <ATA channel 0> on atapci1
> ata2: [ITHREAD]
> ata3: <ATA channel 1> on atapci1
> ata3: port not implemented
> ata3: [ITHREAD]
> ata4: <ATA channel 2> on atapci1
> ata4: port not implemented
> ata4: [ITHREAD]
> ata5: <ATA channel 3> on atapci1
> ata5: port not implemented
> ata5: [ITHREAD]
> pci0: <serial bus, SMBus> at device 31.3 (no driver attached)
> acpi_tz0: <Thermal Zone> on acpi0
> acpi_tz1: <Thermal Zone> on acpi0
> atkbdc0: <Keyboard controller (i8042)> port 0x60,0x64 irq 1 on acpi0
> atkbd0: <AT Keyboard> irq 1 on atkbdc0
> kbd0 at atkbd0
> atkbd0: [GIANT-LOCKED]
> atkbd0: [ITHREAD]
> psm0: <PS/2 Mouse> irq 12 on atkbdc0
> psm0: [GIANT-LOCKED]
> psm0: [ITHREAD]
> psm0: model Generic PS/2 mouse, device ID 0
> battery0: <ACPI Control Method Battery> on acpi0
> acpi_acad0: <AC Adapter> on acpi0
> acpi_ibm0: <IBM ThinkPad ACPI Extras> on acpi0
> cpu0: <ACPI CPU> on acpi0
> est0: <Enhanced SpeedStep Frequency Control> on cpu0
> p4tcc0: <CPU Frequency Thermal Control> on cpu0
> cpu1: <ACPI CPU> on acpi0
> est1: <Enhanced SpeedStep Frequency Control> on cpu1
> p4tcc1: <CPU Frequency Thermal Control> on cpu1
> pmtimer0 on isa0
> orm0: <ISA Option ROMs> at iomem
> 0xd0000-0xd0fff,0xd1000-0xd1fff,0xdc000-0xdffff,0xe0000-0xeffff pnpid
> ORM0000 on isa0
> ppc0: parallel port not found.
> sc0: <System console> at flags 0x100 on isa0
> sc0: VGA <16 virtual consoles, flags=0x300>
> sio0: configured irq 4 not in bitmap of probed irqs 0
> sio0: port may not be enabled
> sio0: configured irq 4 not in bitmap of probed irqs 0
> sio0: port may not be enabled
> sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0
> sio0: type 8250 or not responding
> sio0: [FILTER]
> sio1: configured irq 3 not in bitmap of probed irqs 0
> sio1: port may not be enabled
> vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0
> ums0: <Logitech USB-PS/2 Optical Mouse, class 0/0, rev 2.00/27.20, addr
> 2> on uhub0
> ums0: 8 buttons and Z dir.
> ugen0: <STMicroelectronics Biometric Coprocessor, class 0/0, rev
> 1.00/0.01, addr 2> on uhub3
> Timecounters tick every 1.000 msec
> acd0: DVDR <HL-DT-ST DVDRAM GSA-4083N/1.08> at ata0-master UDMA33
> ad4: 152627MB <SAMSUNG HM160HI HR100-08> at ata2-master SATA150
> hdac0: HDA Codec #0: Analog Devices AD1981HD
> hdac0: HDA Codec #1: Conexant (Unknown)
> pcm0: <HDA Analog Devices AD1981HD PCM #0 Analog> at cad 0 nid 1 on hdac0
> pcm1: <HDA Analog Devices AD1981HD PCM #1 Digital> at cad 0 nid 1 on hdac0
> SMP: AP CPU #1 Launched!
> Trying to mount root from ufs:/dev/ad4s1a
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.9 (FreeBSD)
>
> iEYEARECAAYFAklvDoUACgkQCnBgS+kUGEvHIACgljhgGyTqyxuJI+o5v7CnvQ7x
> 4EAAmwfPW1W329FkWPqTcxkWSdTr4DFs
> =WDri
> -----END PGP SIGNATURE-----
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
>


-- 
Paul
From olli at lurza.secnetix.de  Thu Jan 15 03:47:47 2009
From: olli at lurza.secnetix.de (Oliver Fromme)
Date: Thu Jan 15 03:48:08 2009
Subject: How to get djbdns to start early enough to satisfy ntpd at boot?
In-Reply-To: <20090115051422.GA59032@duncan.reilly.home>
Message-ID: <200901151147.n0FBlbiU066046@lurza.secnetix.de>

Andrew Reilly wrote:
 > So: does anyone know how to modify the boot-time order so that
 > svscan starts at (or before) the point in the boot cycle where
 > BIND would, on other systems?  I suspect that it should be
 > possible by changing the PROVIDE: in svscan.sh to include one of
 > the things REQUIRE:'d by ntpd.  Or perhaps the REQUIRE: LOGIN in
 > svscan.sh is incompatible with the BEFORE: LOGIN in ntpd?

I think "BEFORE: ntpd" should be sufficient.

Best regards
   Oliver

-- 
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606,  Gesch?ftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M?n-
chen, HRB 125758,  Gesch?ftsf?hrer: Maik Bachmann, Olaf Erb, Ralf Gebhart

FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd

"Unix gives you just enough rope to hang yourself --
and then a couple of more feet, just to be sure."
        -- Eric Allman
From ben at morrow.me.uk  Thu Jan 15 04:00:21 2009
From: ben at morrow.me.uk (Ben Morrow)
Date: Thu Jan 15 04:00:33 2009
Subject: How to get djbdns to start early enough to satisfy ntpd at boot?
In-Reply-To: <20090115051422.GA59032@duncan.reilly.home>
Message-ID: <20090115120001.GA23934@osiris.mauzo.dyndns.org>

Quoth Andrew Reilly <andrew-freebsd@areilly.bpc-users.org>:
> 
> So: does anyone know how to modify the boot-time order so that
> svscan starts at (or before) the point in the boot cycle where
> BIND would, on other systems?  I suspect that it should be
> possible by changing the PROVIDE: in svscan.sh to include one of
> the things REQUIRE:'d by ntpd.  Or perhaps the REQUIRE: LOGIN in
> svscan.sh is incompatible with the BEFORE: LOGIN in ntpd?
> 
> Has any other user of dnscache encountered and solved this
> problem?

I have, in my svscan.sh,

    # PROVIDE: svscan
    # REQUIRE: SERVERS cleanvar

and I also have a /usr/local/etc/rc.d/dnscache which looks like

    #!/bin/sh

    # PROVIDE: named
    # REQUIRE: svscan

    . /etc/rc.subr
    . /usr/local/etc/svc.subr

    name="dnscache"
    rcvar=`set_rcvar`

    : ${dnscache_enable:="NO"}

    load_rc_config $name
    load_svc_subr_config

    run_rc_command "$1"

and a /usr/local/etc/svc.subr as attached. It's somewhat more general
than is needed for dnscache, as I also use it to start qmail.

Basically: the PROVIDE: named line is needed to get dnscache up before
ntpd, and the REQUIRE: LOGIN line needs to be changed.

Ben

-------------- next part --------------
#
# Subroutines for handling services under the control of svscan(8).
# Requires rc.subr is loaded first.
#

load_svc_subr_config () {
	load_rc_config_var svscan svscan_servicedir

	: ${svscan_servicedir:=/var/service}
	: ${svc:=/usr/local/bin/svc}
	: ${svok:=/usr/local/bin/svok}
	: ${svstat:=/usr/local/bin/svstat}

	: ${svcname:=${name}}	
	: ${service_dir:=${svscan_servicedir}/${svcname}}
	: ${svok_timeout:=30}
	: ${svstat_timeout:=30}

	: ${start_cmd:=svc_subr_start}
	: ${stop_cmd:=svc_subr_stop}
	: ${restart_cmd:=svc_subr_restart}

	: ${extra_commands:="status reload flush"}
	: ${status_cmd:=svc_subr_status}
	: ${reload_cmd:=svc_subr_reload}
	: ${flush_cmd:=svc_subr_flush}
}

svc_subr_isup () {
	$svstat $1 | grep -q ": up"
}

svc_subr_isdown () {
 	$svstat $1 | grep -q ": down"
}

svc_subr_waitfor () {
	local n check timeout err

	check="$1"
	timeout=$2
	err="$3"

	n=0
	while [ $n -lt $timeout ] && ! $check $service_dir
	do
		sleep 1
		n=$(( n + 1 ))
	done

	if ! $check $service_dir
	then
		echo "$err" >&2
		exit 1
	fi
}

svc_subr_start () {

	echo -n "Checking ${name} is up"

	svc_subr_waitfor $svok $svok_timeout \
		"supervise is not running in ${service_dir}!"

	$svc -u $service_dir

	svc_subr_waitfor svc_subr_isup $svstat_timeout \
		"${service_dir} won't come up!"

	echo "."
}

svc_subr_stop () {

	echo -n "Bringing ${name} down"

	$svc -d $service_dir

	svc_subr_waitfor svc_subr_isdown $svstat_timeout \
		"${service_dir} won't come down, trying SIGKILL"

	svc -k $service_dir

	svc_subr_waitfor svc_subr_isdown $svstat_timeout \
		"${service_dir} won't come down!"

	echo "."
}

svc_subr_restart () {
	echo -n "Sending ${name} a SIGTERM"
	$svc -t $service_dir
	echo "."
}

svc_subr_reload () {
	echo -n "Sending ${name} a SIGHUP"
	$svc -h $service_dir
	echo "."
}

svc_subr_flush () {
	echo -n "Sending ${name} a SIGALRM"
	$svc -a $service_dir
	echo "."
}

svc_subr_status () {
	$svstat $service_dir
}
From dan at langille.org  Thu Jan 15 04:08:01 2009
From: dan at langille.org (Dan Langille)
Date: Thu Jan 15 04:08:13 2009
Subject: interrupt storm
In-Reply-To: <496EEE34.4060109@ksu.ru>
References: <496D374A.3020704@langille.org> <496E9A37.20800@langille.org>
	<496EA339.6010808@ksu.ru> <496EB43A.8010805@langille.org>
	<496ECB2A.8080609@ksu.ru> <1295789639.20090115073959@rulez.sk>
	<496EEE34.4060109@ksu.ru>
Message-ID: <496F26C4.3020702@langille.org>

Marat N.Afanasyev wrote:
> Daniel Gerzo wrote:
>> Hello Marat, Dan,
>>
>> I suppose you guys are running amd64? Could you try i386? AFAIR the
>> interrupt storms have gone away after I moved my MSI machine to i386
>> on an affected box.
>>
> 
> Yes, amd64. unfortunately, moving to i386 is not an option. at least for 
> me. I have 4 GBytes of memory and I'm planning to install another 4 
> GBytes asap.

FW