ps, systat vs top shows different process owner?
Hi list, I have a SAMBA server (version 3.5.11) installed over 8.2-STABLE. I have just noticed, that top shows USERNAME of all smbd processes as root, while systat and ps show user logged to SAMBA. ps output of example user: # ps -a -U foo.bar PID TT STAT TIME COMMAND 19731 ?? S 0:10,19 /usr/local/sbin/smbd -D -s /usr/local/etc/smb.conf top output for the same PID: # top -d1 | grep 19731 19731 root 1 440 17220K 7844K select 0:12 0.29% smbd systat output is consistent with ps. Is that expected behaviour? Could someone explain it to me? -- Bartosz Stec ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Panic during kernel booting on HP Proliant DL180G6 and latest STABLE
urio# Diamond Rio 500 MP3 player +#device urio# Diamond Rio 500 MP3 player # USB Serial devices -device uark# Technologies ARK3116 based serial adapters -device ubsa# Belkin F5U103 and compatible serial adapters -device uftdi # For FTDI usb serial adapters -device uipaq # Some WinCE based devices -device uplcom # Prolific PL-2303 serial adapters -device uslcom # SI Labs CP2101/CP2102 serial adapters -device uvisor # Visor and Palm devices -device uvscom # USB serial support for DDI pocket's PHS +#device uark# Technologies ARK3116 based serial adapters +#device ubsa# Belkin F5U103 and compatible serial adapters +#device uftdi # For FTDI usb serial adapters +#device uipaq # Some WinCE based devices +#device uplcom # Prolific PL-2303 serial adapters +#device uslcom # SI Labs CP2101/CP2102 serial adapters +#device uvisor # Visor and Palm devices +#device uvscom # USB serial support for DDI pocket's PHS # USB Ethernet, requires miibus -device aue # ADMtek USB Ethernet -device axe # ASIX Electronics USB Ethernet -device cdce# Generic USB over Ethernet -device cue # CATC USB Ethernet -device kue # Kawasaki LSI USB Ethernet -device rue # RealTek RTL8150 USB Ethernet -device udav# Davicom DM9601E USB +#device aue # ADMtek USB Ethernet +#device axe # ASIX Electronics USB Ethernet +#device cdce# Generic USB over Ethernet +#device cue # CATC USB Ethernet +#device kue # Kawasaki LSI USB Ethernet +#device rue # RealTek RTL8150 USB Ethernet +#device udav# Davicom DM9601E USB # USB Wireless -device rum # Ralink Technology RT2501USB wireless NICs -device uath# Atheros AR5523 wireless NICs -device ural# Ralink Technology RT2500USB wireless NICs -device zyd # ZyDAS zb1211/zb1211b wireless NICs +#device rum # Ralink Technology RT2501USB wireless NICs +#device uath# Atheros AR5523 wireless NICs +#device ural# Ralink Technology RT2500USB wireless NICs +#device zyd # ZyDAS zb1211/zb1211b wireless NICs # FireWire support -device firewire# FireWire bus code +#device firewire# FireWire bus code #devicesbp # SCSI over FireWire (Requires scbus and da) -device fwe # Ethernet over FireWire (non-standard!) -device fwip# IP over FireWire (RFC 2734,3146) -device dcons # Dumb console driver -device dcons_crom # Configuration ROM for dcons +#device fwe # Ethernet over FireWire (non-standard!) +#device fwip# IP over FireWire (RFC 2734,3146) +#device dcons # Dumb console driver +#device dcons_crom # Configuration ROM for dcons + +device atapicam -Original Message- From: Bartosz Stec [mailto:bartosz.s...@it4pro.pl] Sent: Friday, June 17, 2011 6:42 AM To: Vogel, Jack Cc: Jeremy Chadwick; FreeBSD Stable Subject: Re: Panic during kernel booting on HP Proliant DL180G6 and latest STABLE W dniu 2011-06-10 20:23, Vogel, Jack pisze: Er, so what if you get rid of ZFS, does your panic go away? It doesn't really matter what type adapter it is, the igb driver only requests standard size clusters, so memory is getting trashed somewhere I suspect. Jack Well, from my observations about this issue (which could be very wrong because my lack of knowledge about BSD kernel) I don't suspect igb driver directly, but rather an order which kernel is processing stuff related to MSIX and hardware (so I suppose that real cause of the problem could be very hard to catch and repeat)? Here's why: 1. There's no panic when using GENERIC kernel. There's also nothing unusual in my custom kernel (included in thread), neither in make.conf. 2. Before current build, panic was seen with igb driver included in kernel, but no panic when using a module. Even better - n
Re: Panic during kernel booting on HP Proliant DL180G6 and latest STABLE
W dniu 2011-06-10 20:23, Vogel, Jack pisze: Er, so what if you get rid of ZFS, does your panic go away? It doesn't really matter what type adapter it is, the igb driver only requests standard size clusters, so memory is getting trashed somewhere I suspect. Jack Well, from my observations about this issue (which could be very wrong because my lack of knowledge about BSD kernel) I don't suspect igb driver directly, but rather an order which kernel is processing stuff related to MSIX and hardware (so I suppose that real cause of the problem could be very hard to catch and repeat)? Here's why: 1. There's no panic when using GENERIC kernel. There's also nothing unusual in my custom kernel (included in thread), neither in make.conf. 2. Before current build, panic was seen with igb driver included in kernel, but no panic when using a module. Even better - no panic when trying to load a module while igb driver is stil included in source. No random memory corruption here - same scenario seen every boot with all variants above. It's HP server with HP ECC memory by the way. 3. With current build kernel panics regardless if igb driver is a module or included in kernel (unless i disable MSIX). But I found override - I removed igb driver from kernel config, and a module from loader.conf. Than booted in single user mode, and manually loaded igb driver. No panic! Appareantly something gets wrong _only_ at boot time. -- Bartosz Stec ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: "log_sysevent: type 19 is not implemented" messages during boot
W dniu 2011-06-11 18:43, Sergey Kandaurov pisze: On 11 June 2011 20:01, Rolf Nielsen wrote: Hi all, After going from 8.2-RELEASE to 8-STABLE (to get ZFS v28), I get log_sysevent: type 19 is not implemented exactly 20 times during boot. What does that message mean? Need I worry about it? And even if it's harmless, it annoys me, so can I get rid of it, and if so, how? Hi. This warning indeed came with ZFS v28 recently merged to 8-STABLE. AFAIK it's rather harmless. It was silenced in current recently (see svn r222343), and the fix is expected to be merged to 8-STABLE soon. Are you sure that it's harmless? It appeared for me as an evidence of pool breakage. I had these messages when I ran any zpool command on broken pool. I do't havesingle one after pool is fixed. Here's my thread on freebsd-fs : http://lists.freebsd.org/pipermail/freebsd-fs/2011-June/011639.html -- Bartosz Stec ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: gpt labels for zfs partitions don't appear in /dev/gpt
W dniu 2011-06-15 14:12, Andrey V. Elsukov pisze:
On 15.06.2011 15:43, Bartosz Stec wrote:
As you see I have ada{0-2}p3 labeled as disk{0-2} All labeled partitions have
valid gpt id but
zfs partitions don't have accesible gpt label in /dev/gpt:
It always worked so. Read geom(4) manual page, especially about SPOILING.
Ah, I see your point now.
As you see labels was firstly seen, but removed at the end. I tried to set
blank label and then
correct one again, but no luck.
Any ideas what's possibly wrong here?
There are two reasons:
1. glabel does not create providers for providers which are already in use.
2. `gpart modify` does not touch partition provider and it is not spoiled and
retasted.
Problem appeared after my pool was broken and I imported it from some boot CD to fix
this by "import
-F".
Now I have unreadable output from zpool commands, like this:
NAMESTATE READ WRITE
CKSUM
zroot ONLINE 0 0
0
raidz1-0 ONLINE 0 0
0
gptid/2ea57c66-bc69-11df-8955-0050dad823cd ONLINE 0 0
0
gptid/5bc92016-6852-11df-a16c-0050dad823cd ONLINE 0 0
0
gptid/87d467cc-bc3b-11df-8066-0050dad823cd ONLINE 0 0
0
You can disable gptids and this output will be changed back:
echo kern.geom.label.gptid.enable="0">> /boot/loader.conf
Yes, indeed it did the trick. Thank you for your detailed explanation.
--
Bartosz Stec
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
gpt labels for zfs partitions don't appear in /dev/gpt
12 Stripesize: 0 Stripeoffset: 82944 Mode: r1w1e1 secoffset: 0 offset: 0 seclength: 2097152 length: 1073741824 index: 0 Consumers: 1. Name: ada2p2 Mediasize: 1073741824 (1.0G) Sectorsize: 512 Stripesize: 0 Stripeoffset: 82944 Mode: r1w1e2 Geom name: ada2p3 Providers: 1. Name: gptid/87d467cc-bc3b-11df-8066-0050dad823cd Mediasize: 38946822656 (36G) Sectorsize: 512 Stripesize: 0 Stripeoffset: 1073824768 Mode: r1w1e1 secoffset: 0 offset: 0 seclength: 76068013 length: 38946822656 index: 0 Consumers: 1. Name: ada2p3 Mediasize: 38946822656 (36G) Sectorsize: 512 Stripesize: 0 Stripeoffset: 1073824768 Mode: r1w1e2 And also: # ls /dev/gpt swap0 swap1 swap2 I've enabled kern.geom.label.debug=1 and here's what I got during boot: # dmesg | grep GEOM_LABEL GEOM_LABEL[1]: MSDOSFS: ada0: FAT12/16 volume not valid. GEOM_LABEL[1]: MSDOSFS: ada1: FAT12/16 volume not valid. GEOM_LABEL[1]: MSDOSFS: ada2: FAT12/16 volume not valid. GEOM_LABEL[1]: MSDOSFS: ada0p1: no FAT signature found. GEOM_LABEL[1]: Label for provider ada0p1 is gptid/fe8c7129-bc68-11df-8955-0050dad823cd. GEOM_LABEL[1]: MSDOSFS: ada0p2: no FAT signature found. GEOM_LABEL[1]: Label for provider ada0p2 is gpt/swap0. GEOM_LABEL[1]: Label for provider ada0p2 is gptid/0c0b5606-bc69-11df-8955-0050dad823cd. GEOM_LABEL[1]: MSDOSFS: ada0p3: no FAT signature found. GEOM_LABEL[1]: Label for provider ada0p3 is gpt/disk0. GEOM_LABEL[1]: Label for provider ada0p3 is gptid/2ea57c66-bc69-11df-8955-0050dad823cd. GEOM_LABEL[1]: MSDOSFS: ada1p1: no FAT signature found. GEOM_LABEL[1]: Label for provider ada1p1 is gptid/060c432a-6852-11df-a16c-0050dad823cd. GEOM_LABEL[1]: MSDOSFS: ada1p2: no FAT signature found. GEOM_LABEL[1]: Label for provider ada1p2 is gpt/swap1. GEOM_LABEL[1]: Label for provider ada1p2 is gptid/303e329f-6852-11df-a16c-0050dad823cd. GEOM_LABEL[1]: MSDOSFS: ada1p3: no FAT signature found. GEOM_LABEL[1]: Label for provider ada1p3 is gpt/disk1. GEOM_LABEL[1]: Label for provider ada1p3 is gptid/5bc92016-6852-11df-a16c-0050dad823cd. GEOM_LABEL[1]: MSDOSFS: ada2p1: no FAT signature found. GEOM_LABEL[1]: Label for provider ada2p1 is gptid/c506cc78-bc3a-11df-8066-0050dad823cd. GEOM_LABEL[1]: MSDOSFS: ada2p2: no FAT signature found. GEOM_LABEL[1]: Label for provider ada2p2 is gpt/swap2. GEOM_LABEL[1]: Label for provider ada2p2 is gptid/f5ee2146-bc3a-11df-8066-0050dad823cd. GEOM_LABEL[1]: MSDOSFS: ada2p3: no FAT signature found. GEOM_LABEL[1]: Label for provider ada2p3 is gpt/disk2. GEOM_LABEL[1]: Label for provider ada2p3 is gptid/87d467cc-bc3b-11df-8066-0050dad823cd. GEOM_LABEL[1]: Label gptid/0c0b5606-bc69-11df-8955-0050dad823cd removed. GEOM_LABEL[1]: Label gptid/303e329f-6852-11df-a16c-0050dad823cd removed. GEOM_LABEL[1]: Label gptid/f5ee2146-bc3a-11df-8066-0050dad823cd removed. GEOM_LABEL[1]: MSDOSFS: mirror/swap: no FAT signature found. GEOM_LABEL[1]: Label gpt/disk0 removed. GEOM_LABEL[1]: Label gpt/disk1 removed. GEOM_LABEL[1]: Label gpt/disk2 removed. As you see labels was firstly seen, but removed at the end. I tried to set blank label and then correct one again, but no luck. Any ideas what's possibly wrong here? Problem appeared after my pool was broken and I imported it from some boot CD to fix this by "import -F". Now I have unreadable output from zpool commands, like this: NAMESTATE READ WRITE CKSUM zroot ONLINE 0 0 0 raidz1-0 ONLINE 0 0 0 gptid/2ea57c66-bc69-11df-8955-0050dad823cd ONLINE 0 0 0 gptid/5bc92016-6852-11df-a16c-0050dad823cd ONLINE 0 0 0 gptid/87d467cc-bc3b-11df-8066-0050dad823cd ONLINE 0 0 0 -- Bartosz Stec ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Panic during kernel booting on HP Proliant DL180G6 and latest STABLE
W dniu 2011-06-10 11:37, Jeremy Chadwick pisze: On Fri, Jun 10, 2011 at 10:56:06AM +0200, Bartosz Stec wrote: W dniu 2011-05-13 13:30, Andriy Gapon pisze: on 12/05/2011 22:43 Bartosz Stec said the following: Allright, if anyone want to follow: http://www.freebsd.org/cgi/query-pr.cgi?pr=156974 I suspect that your best course here is to add some diagnostic printfs in igb_refresh_mbufs and in m_getzone to see what value is actually passed to m_getjcl and why. You're probably right, although I would need some guidance how to do it. Sorry :( Yesterday I rebuilt this machine with fresh sources to upgrade filesystem to ZFSv28 which was MFC'ed lately. After that server started to panic regardless of igb loaded as module or integrated into kernel. Finally I found that problem was caused by MSIX somehow. No more panic after hw.pci.enable_msix=0 was included in loader.conf. There's also no panic with GENERIC kernel. Should I really care abou MSIX? Yes, you absolutely should. The performance hit, depending on your interrupt load, can be quite dramatic with this turned off. Remember: what you just turned off was MSI-X for the *entire system*, not just for NICs. Please read about it here: http://en.wikipedia.org/wiki/Message_Signaled_Interrupts CC'ing Jack Vogel here, because your issue pertains to igb(4). Please provide output from "pciconv -lvcb" that pertain to your igb NIC(s), as well as relevant dmesg info that pertains to them (driver, etc.). You can XXX out MAC addresses if you're worried. Jack, original thread starts here: http://lists.freebsd.org/pipermail/freebsd-stable/2011-May/thread.html#62596 Thanks Jeremy, you are helpful as always :) Full dmesg output (was already included in this thread): http://pastebin.com/Es0CKD64 #pciconf -lcvb hostb0@pci0:0:0:0:class=0x06 card=0x330b103c chip=0x34068086 rev=0x13 hdr=0x00 vendor = 'Intel Corporation' device = 'QuickPath Architecture I/O Hub to ESI Port' class = bridge subclass = HOST-PCI cap 05[60] = MSI supports 2 messages, vector masks cap 10[90] = PCI-Express 2 root port max data 128(128) link x4(x4) cap 01[e0] = powerspec 3 supports D0 D3 current D0 ecap 0001[100] = AER 1 0 fatal 0 non-fatal 0 corrected ecap 000d[150] = unknown 1 ecap 000b[160] = unknown 0 pcib1@pci0:0:1:0:class=0x060400 card=0x330b103c chip=0x34088086 rev=0x13 hdr=0x01 vendor = 'Intel Corporation' device = 'QuickPath Architecture I/O Hub PCI Express Root Port 1' class = bridge subclass = PCI-PCI cap 0d[40] = PCI Bridge card=0x330b103c cap 05[60] = MSI supports 2 messages, vector masks cap 10[90] = PCI-Express 2 root port max data 256(256) link x4(x4) cap 01[e0] = powerspec 3 supports D0 D3 current D0 ecap 0001[100] = AER 1 0 fatal 0 non-fatal 0 corrected ecap 000d[150] = unknown 1 ecap 000b[160] = unknown 0 pcib2@pci0:0:3:0:class=0x060400 card=0x330b103c chip=0x340a8086 rev=0x13 hdr=0x01 vendor = 'Intel Corporation' device = 'QuickPath Architecture I/O Hub PCI Express Root Port 3' class = bridge subclass = PCI-PCI cap 0d[40] = PCI Bridge card=0x330b103c cap 05[60] = MSI supports 2 messages, vector masks cap 10[90] = PCI-Express 2 root port max data 256(256) link x0(x16) cap 01[e0] = powerspec 3 supports D0 D3 current D0 ecap 0001[100] = AER 1 0 fatal 0 non-fatal 0 corrected ecap 000d[150] = unknown 1 ecap 000b[160] = unknown 0 pcib3@pci0:0:7:0:class=0x060400 card=0x330b103c chip=0x340e8086 rev=0x13 hdr=0x01 vendor = 'Intel Corporation' device = 'QuickPath Architecture I/O Hub PCI Express Root Port 7' class = bridge subclass = PCI-PCI cap 0d[40] = PCI Bridge card=0x330b103c cap 05[60] = MSI supports 2 messages, vector masks cap 10[90] = PCI-Express 2 root port max data 256(256) link x0(x16) cap 01[e0] = powerspec 3 supports D0 D3 current D0 ecap 0001[100] = AER 1 0 fatal 0 non-fatal 0 corrected ecap 000d[150] = unknown 1 ecap 000b[160] = unknown 0 pcib4@pci0:0:9:0:class=0x060400 card=0x330b103c chip=0x34108086 rev=0x13 hdr=0x01 vendor = 'Intel Corporation' device = 'QuickPath Architecture I/O Hub PCI Express Root Port 9' class = bridge subclass = PCI-PCI cap 0d[40] = PCI Bridge card=0x330b103c cap 05[60] = MSI supports 2 messages, vector masks cap 10[90] = PCI-Express 2 root port max data 256(256) link x0(x4) cap 01[e0] = powerspec 3 supports D0 D3 current D0 ecap 0001[100] = AER 1 0 fatal 0 non-fatal 0 corrected ecap 000d[15
Re: Panic during kernel booting on HP Proliant DL180G6 and latest STABLE
W dniu 2011-05-13 13:30, Andriy Gapon pisze: on 12/05/2011 22:43 Bartosz Stec said the following: Allright, if anyone want to follow: http://www.freebsd.org/cgi/query-pr.cgi?pr=156974 I suspect that your best course here is to add some diagnostic printfs in igb_refresh_mbufs and in m_getzone to see what value is actually passed to m_getjcl and why. You're probably right, although I would need some guidance how to do it. Sorry :( Yesterday I rebuilt this machine with fresh sources to upgrade filesystem to ZFSv28 which was MFC'ed lately. After that server started to panic regardless of igb loaded as module or integrated into kernel. Finally I found that problem was caused by MSIX somehow. No more panic after hw.pci.enable_msix=0 was included in loader.conf. There's also no panic with GENERIC kernel. Should I really care abou MSIX? -- Bartosz Stec ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Panic during kernel booting on HP Proliant DL180G6 and latest STABLE
Allright, if anyone want to follow: http://www.freebsd.org/cgi/query-pr.cgi?pr=156974 -- Bartosz Stec ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Panic during kernel booting on HP Proliant DL180G6 and latest STABLE
W dniu 2011-05-08 20:34, Bartosz Stec pisze:
W dniu 2011-05-08 16:02, Bartosz Stec pisze:
Hi list!
I moved my 8-STABLE system from cheap AMD64 machine to Proliant
DL180G6 (full ZFS send -> receive) yesterday.
Operation was succesfull, system booted and everything worked fine.
Still, I wanted to perform full world + kernel rebuild with updated
sources and CPUTYPE (core2 instead of athlon64) and removed unused
NIC drivers from kernel.
New kernel panicked during boot. I rebuilt kernel again, without any
CPUTYPE in make.conf, but panic was still there. Old kernel (built at
8.04.2011) is booting fine.
First panic line says:
panic: m_getzone: m_getjcl: invalid cluster type.
I made a por quality photo of screen with stack backtrace and it's
available here: http://www.picamatic.com/view/7544359_IMAG0029/
Now the funny thing:
Igb driver is compiled into the kernel. If I add igb driver to
loader.conf kernel complains of course:
module_register: module pci/igb already exists!
Module pci/igb failed to register: 17
but there's no panic!
When I remove 'if_igb_load="YES"' from loader.conf, I experience
panic visible above.
Kernel config: http://pastebin.com/G7K0vfuJ
Picamatic seems offline now, so here's another link to backtrace
photo: http://i51.tinypic.com/nyuux3.jpg
Maybe make.conf will be useful too:
CPUTYPE?=core2
KERNCONF=PROLIANT
#MAKEOPTS=-j3
#WITH_DEBUG=yes
#DEBUG_FLAGS=-g
# default build settings for ports collection
.if ${.CURDIR:M*/ports/*} && !defined(NOCCACHE)
CFLAGS=-O2 -pipe
#CXXFLAGS= -O2 -fno-strict-aliasing -pipe -funroll-loops
BUILD_OPTIMIZED=YES
WITH_OPENSSL=YES
WITH_XCHARSET=all
WITH_CHARSET=utf8
WITH_COLLATION=utf8_general_ci
.endif
# default build settings for base system
.if ${.CURDIR:M*/usr/src/*} || ${.CURDIR:M*/usr/obj/*} &&
!defined(NOCCACHE)
CFLAGS=-O2 -pipe
COPTFLAGS=-O2 -pipe
CC:=${CC:C,^cc,/usr/local/libexec/ccache/world/cc,1}
CXX:=${CXX:C,^c\+\+,/usr/local/libexec/ccache/world/c++,1}
.endif
# added by use.perl 2011-05-08 17:13:51
PERL_VERSION=5.10.1
Dear list,
shoud I provide some additional data to help find a problem, or just
fill a PR :)?
Maybe full dmesg output will help?: http://pastebin.com/Es0CKD64
It's from kernel which is panicking.
--
Bartosz Stec
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Panic during kernel booting on HP Proliant DL180G6 and latest STABLE
W dniu 2011-05-08 16:02, Bartosz Stec pisze:
Hi list!
I moved my 8-STABLE system from cheap AMD64 machine to Proliant
DL180G6 (full ZFS send -> receive) yesterday.
Operation was succesfull, system booted and everything worked fine.
Still, I wanted to perform full world + kernel rebuild with updated
sources and CPUTYPE (core2 instead of athlon64) and removed unused NIC
drivers from kernel.
New kernel panicked during boot. I rebuilt kernel again, without any
CPUTYPE in make.conf, but panic was still there. Old kernel (built at
8.04.2011) is booting fine.
First panic line says:
panic: m_getzone: m_getjcl: invalid cluster type.
I made a por quality photo of screen with stack backtrace and it's
available here: http://www.picamatic.com/view/7544359_IMAG0029/
Now the funny thing:
Igb driver is compiled into the kernel. If I add igb driver to
loader.conf kernel complains of course:
module_register: module pci/igb already exists!
Module pci/igb failed to register: 17
but there's no panic!
When I remove 'if_igb_load="YES"' from loader.conf, I experience panic
visible above.
Kernel config: http://pastebin.com/G7K0vfuJ
Picamatic seems offline now, so here's another link to backtrace photo:
http://i51.tinypic.com/nyuux3.jpg
Maybe make.conf will be useful too:
CPUTYPE?=core2
KERNCONF=PROLIANT
#MAKEOPTS=-j3
#WITH_DEBUG=yes
#DEBUG_FLAGS=-g
# default build settings for ports collection
.if ${.CURDIR:M*/ports/*} && !defined(NOCCACHE)
CFLAGS=-O2 -pipe
#CXXFLAGS= -O2 -fno-strict-aliasing -pipe -funroll-loops
BUILD_OPTIMIZED=YES
WITH_OPENSSL=YES
WITH_XCHARSET=all
WITH_CHARSET=utf8
WITH_COLLATION=utf8_general_ci
.endif
# default build settings for base system
.if ${.CURDIR:M*/usr/src/*} || ${.CURDIR:M*/usr/obj/*} &&
!defined(NOCCACHE)
CFLAGS=-O2 -pipe
COPTFLAGS=-O2 -pipe
CC:=${CC:C,^cc,/usr/local/libexec/ccache/world/cc,1}
CXX:=${CXX:C,^c\+\+,/usr/local/libexec/ccache/world/c++,1}
.endif
# added by use.perl 2011-05-08 17:13:51
PERL_VERSION=5.10.1
--
Bartosz Stec
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Panic during kernel booting on HP Proliant DL180G6 and latest STABLE
Hi list! I moved my 8-STABLE system from cheap AMD64 machine to Proliant DL180G6 (full ZFS send -> receive) yesterday. Operation was succesfull, system booted and everything worked fine. Still, I wanted to perform full world + kernel rebuild with updated sources and CPUTYPE (core2 instead of athlon64) and removed unused NIC drivers from kernel. New kernel panicked during boot. I rebuilt kernel again, without any CPUTYPE in make.conf, but panic was still there. Old kernel (built at 8.04.2011) is booting fine. First panic line says: panic: m_getzone: m_getjcl: invalid cluster type. I made a por quality photo of screen with stack backtrace and it's available here: http://www.picamatic.com/view/7544359_IMAG0029/ Now the funny thing: Igb driver is compiled into the kernel. If I add igb driver to loader.conf kernel complains of course: module_register: module pci/igb already exists! Module pci/igb failed to register: 17 but there's no panic! When I remove 'if_igb_load="YES"' from loader.conf, I experience panic visible above. Kernel config: http://pastebin.com/G7K0vfuJ -- Bartosz Stec ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ZFS - abysmal performance with samba since upgrade to 8.2-RELEASE
y, low memory desktop PC as home router/test server/(very little) storage: FreeBSD 9.0-CURRENT #2 r219090: Mon Feb 28 03:06:13 CET 2011 CPU: mobile AMD Athlon(tm) XP 2200+ (1800.10-MHz 686-class CPU) real memory = 1610612736 (1536 MB) avail memory = 1562238976 (1489 MB) ad0: 39205MB at ata0-master UDMA133 ad1: 38166MB at ata0-slave UDMA100 ad2: 39205MB at ata1-master UDMA133 xl0: <3Com 3c905B-TX Fast Etherlink XL> It's ZFS only (just updated to v28) system in RAIDZ1 configuration, attached to cheap belkin 100Mb switch used for home network. From couple of months I experienced pathetic SMB transfer - from 20kB/s to 200kB/s. Especially when system was idle, because the most funny thing about that - transfer was much better when system was busy (csup or make world for instance). SMB throughput jumped to 2-4MB/s then (well, from time to time at least). I've been using following settings and tunings while I was experiencing this issue: smb.conf: [global] socket options = TCP_NODELAY SO_SNDBUF=65536 SO_RCVBUF=65536 use sendfile = yes min receivefile size = 16384 aio read size = 16384 aio write size = 16384 aio write behind = true loader.conf: vm.kmem_size="1536M" vm.kmem_size_max="1536M" vfs.zfs.arc_max="1024M" aio_load="YES" sysctl.conf: kern.ipc.maxsockbuf=2097152 net.inet.tcp.recvspace=262144 net.inet.tcp.recvspace=262144 net.inet.tcp.mssdflt=1452 net.inet.udp.recvspace=65535 net.inet.udp.maxdgram=65535 net.local.stream.recvspace=65535 net.local.stream.sendspace=65535 After applying tunables from Jeremy my configs looks like this: smb.conf: [global] socket options = TCP_NODELAY SO_SNDBUF=131072 SO_RCVBUF=131072 use sendfile = yes min receivefile size = 16384 aio read size = 16384 aio write size = 16384 aio write behind = yes loader.conf: vm.kmem_size="1536M" vm.kmem_size_max="1536M" vfs.zfs.arc_max="1024M" vfs.zfs.txg.timeout="5" aio_load="YES" sysctl.conf: net.inet.tcp.sendbuf_max=16777216 net.inet.tcp.recvbuf_max=16777216 net.inet.tcp.sendspace=65536 net.inet.tcp.recvspace=131072 vfs.ufs.dirhash_maxmem=16777216 kern.maxvnodes=25 vfs.zfs.txg.write_limit_override=134217728 Test: copying 1GB file both sides. Results: stable 8MB/s both sides! Thank you very much! -- Bartosz Stec ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: top shows only part of available physmem
W dniu 2011-01-28 12:30, Damien Fleuriot pisze: On 1/28/11 11:37 AM, Bartosz Stec wrote: Guys, could someone explain me this? # sysctl hw.realmem hw.realmem: 2139029504 top line shows: Mem: 32M Active, 35M Inact, 899M Wired, 8392K Cache, 199M Buf, 58M Free 32+35+899+8+199+58 = 1231MB Shouldn't that sum to all available ram? Or maybe I'm reading it wrong? This machine has indeed 2GB of ram on board and showed in BIOS. i386 FreeBSD 8.2-PRERELEASE #16: Mon Jan 17 22:28:53 CET 2011 Cheers. First, don't include 'buf' as isn't a separate set of RAM, it is only a range of the virtual address space in the kernel. It used to be relevant when the buffer cache was separate from the VM page cache, but now it is mostly irrelevant (arguably it should just be dropped from top output). Thanks for the explanation. So 1231MB - 199MB Buf and we got about 1GB of memory instead of 2B. However, look at what hw.physmem says (and the realmem and availmem lines in dmesg). realmem is actually not that useful as it is not a count of the amount of memory, but the address of the highest memory page available. There can be less memory available than that due to "holes" in the address space for PCI memory BARs, etc. OK, here you go: # sysctl hw | grep mem hw.physmem: 2125893632 hw.usermem: 1212100608 hw.realmem: 2139029504 hw.pci.host_mem_start: 2147483648 Humm, you should still have 2GB of RAM then. All the memory you set aside for ARC should be counted in the 'wired' count, so I'm not sure why you see 1GB of RAM rather than 2GB. For what its worth (seems to be the same values top shows), the sysctl's I use to make cacti graphs of memory usage are: (Counts are in pages) vm.stats.vm.v_page_size vm.stats.vm.v_wire_count vm.stats.vm.v_active_count vm.stats.vm.v_inactive_count vm.stats.vm.v_cache_count vm.stats.vm.v_free_count Using the output of those sysctls I allways get a cacti graph which at least very much seems to account for all memory, and has a flat surface in a stacked graph. These sysctls are exactly what top uses. There is also a 'v_page_count' which is a total count of pages. So here's additional sysctl output from now: fbsd# sysctl hw | grep mem hw.physmem: 2125893632 hw.usermem: 1392594944 hw.realmem: 2139029504 hw.pci.host_mem_start: 2147483648 fbsd# sysctl vm.stats.vm vm.stats.vm.v_kthreadpages: 0 vm.stats.vm.v_rforkpages: 0 vm.stats.vm.v_vforkpages: 1422927 vm.stats.vm.v_forkpages: 4606557 vm.stats.vm.v_kthreads: 40 vm.stats.vm.v_rforks: 0 vm.stats.vm.v_vforks: 9917 vm.stats.vm.v_forks: 30429 vm.stats.vm.v_interrupt_free_min: 2 vm.stats.vm.v_pageout_free_min: 34 vm.stats.vm.v_cache_max: 27506 vm.stats.vm.v_cache_min: 13753 vm.stats.vm.v_cache_count: 20312 vm.stats.vm.v_inactive_count: 18591 vm.stats.vm.v_inactive_target: 20629 vm.stats.vm.v_active_count: 1096 vm.stats.vm.v_wire_count: 179027 vm.stats.vm.v_free_count: 6193 vm.stats.vm.v_free_min: 3260 vm.stats.vm.v_free_target: 13753 vm.stats.vm.v_free_reserved: 713 vm.stats.vm.v_page_count: 509752 vm.stats.vm.v_page_size: 4096 vm.stats.vm.v_tfree: 196418851 vm.stats.vm.v_pfree: 2837177 vm.stats.vm.v_dfree: 0 vm.stats.vm.v_tcached: 1305893 vm.stats.vm.v_pdpages: 3527455 vm.stats.vm.v_pdwakeups: 187 vm.stats.vm.v_reactivated: 83786 vm.stats.vm.v_intrans: 3053 vm.stats.vm.v_vnodepgsout: 134384 vm.stats.vm.v_vnodepgsin: 29213 vm.stats.vm.v_vnodeout: 96249 vm.stats.vm.v_vnodein: 29213 vm.stats.vm.v_swappgsout: 19730 vm.stats.vm.v_swappgsin: 8573 vm.stats.vm.v_swapout: 5287 vm.stats.vm.v_swapin: 2975 vm.stats.vm.v_ozfod: 83338 vm.stats.vm.v_zfod: 2462557 vm.stats.vm.v_cow_optim: 330 vm.stats.vm.v_cow_faults: 1239253 vm.stats.vm.v_vm_faults: 5898471 fbsd# sysctl vm.vmtotal vm.vmtotal: System wide totals computed every five seconds: (values in kilobytes) === Processes: (RUNQ: 1 Disk Wait: 0 Page Wait: 0 Sleep: 60) Virtual Memory: (Total: 4971660K Active: 699312K) Real Memory:(Total: 540776K Active: 29756K) Shared Virtual Memory: (Total: 41148K Active: 19468K) Shared Real Memory: (Total: 4964K Active: 3048K) Free Memory Pages: 105308K /usr/bin/top line: Mem: 4664K Active, 73M Inact, 700M Wired, 79M Cache, 199M Buf, 23M Free Sum (Without Buf): 879,5 MB So what are we looking at? Wrong sysctls/top output or maybe actually FreeBSD doesn't use all available RAM for some reason? Could it be hardware problem? Maybe I should provide some additional data? Does the behaviour become more expected if you remove Z
Re: top shows only part of available physmem
still gived ping response) after massive slowdown seen by SAMBA users. Now top shows following: Mem: 78M Active, 83M Inact, 639M Wired, 120K Cache, 199M Buf, 1139M Free. What I am afraid is that this PC slowly eats own memory and finally starved itself to death, because it happened second time in 2 weeks, and it seems that rebuilding world+kernel Mon Jan 17 22:28:53 CET 2011 could be the cause. For some strange reason I believe that Jeremy Chadwick could be right pointing ZFS. Way this machine stops responding without any info in logs makes me believe that it has simply lost ability to I/O to HDD (system is ZFS-only). Day 2 after reboot: Mem: 100M Active, 415M Inact, 969M Wired, 83M Cache, 199M Buf, 21M Free Sum: 1588MB 1/4 of total RAM disappeared already. Anyone knows what possibly happening here or maybe I should hire some voodoo shaman to expel memory-eating-ghost from the machine ;)? -- Bartosz Stec ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: top shows only part of available physmem
W dniu 2011-01-27 04:21, Jeremy Chadwick pisze: On Thu, Jan 27, 2011 at 01:59:01AM +0100, Bartosz Stec wrote: W dniu 2011-01-26 19:44, John Baldwin pisze: On Wednesday, January 26, 2011 1:04:02 pm Marco van Tol wrote: On Wed, Jan 26, 2011 at 12:35:56PM -0500, John Baldwin wrote: On Wednesday, January 26, 2011 8:20:28 am Bartosz Stec wrote: W dniu 2011-01-26 14:06, John Baldwin pisze: On Wednesday, January 26, 2011 7:20:34 am Bartosz Stec wrote: Guys, could someone explain me this? # sysctl hw.realmem hw.realmem: 2139029504 top line shows: Mem: 32M Active, 35M Inact, 899M Wired, 8392K Cache, 199M Buf, 58M Free 32+35+899+8+199+58 = 1231MB Shouldn't that sum to all available ram? Or maybe I'm reading it wrong? This machine has indeed 2GB of ram on board and showed in BIOS. i386 FreeBSD 8.2-PRERELEASE #16: Mon Jan 17 22:28:53 CET 2011 Cheers. First, don't include 'buf' as isn't a separate set of RAM, it is only a range of the virtual address space in the kernel. It used to be relevant when the buffer cache was separate from the VM page cache, but now it is mostly irrelevant (arguably it should just be dropped from top output). Thanks for the explanation. So 1231MB - 199MB Buf and we got about 1GB of memory instead of 2B. However, look at what hw.physmem says (and the realmem and availmem lines in dmesg). realmem is actually not that useful as it is not a count of the amount of memory, but the address of the highest memory page available. There can be less memory available than that due to "holes" in the address space for PCI memory BARs, etc. OK, here you go: # sysctl hw | grep mem hw.physmem: 2125893632 hw.usermem: 1212100608 hw.realmem: 2139029504 hw.pci.host_mem_start: 2147483648 Humm, you should still have 2GB of RAM then. All the memory you set aside for ARC should be counted in the 'wired' count, so I'm not sure why you see 1GB of RAM rather than 2GB. For what its worth (seems to be the same values top shows), the sysctl's I use to make cacti graphs of memory usage are: (Counts are in pages) vm.stats.vm.v_page_size vm.stats.vm.v_wire_count vm.stats.vm.v_active_count vm.stats.vm.v_inactive_count vm.stats.vm.v_cache_count vm.stats.vm.v_free_count Using the output of those sysctls I allways get a cacti graph which at least very much seems to account for all memory, and has a flat surface in a stacked graph. These sysctls are exactly what top uses. There is also a 'v_page_count' which is a total count of pages. So here's additional sysctl output from now: fbsd# sysctl hw | grep mem hw.physmem: 2125893632 hw.usermem: 1392594944 hw.realmem: 2139029504 hw.pci.host_mem_start: 2147483648 fbsd# sysctl vm.stats.vm vm.stats.vm.v_kthreadpages: 0 vm.stats.vm.v_rforkpages: 0 vm.stats.vm.v_vforkpages: 1422927 vm.stats.vm.v_forkpages: 4606557 vm.stats.vm.v_kthreads: 40 vm.stats.vm.v_rforks: 0 vm.stats.vm.v_vforks: 9917 vm.stats.vm.v_forks: 30429 vm.stats.vm.v_interrupt_free_min: 2 vm.stats.vm.v_pageout_free_min: 34 vm.stats.vm.v_cache_max: 27506 vm.stats.vm.v_cache_min: 13753 vm.stats.vm.v_cache_count: 20312 vm.stats.vm.v_inactive_count: 18591 vm.stats.vm.v_inactive_target: 20629 vm.stats.vm.v_active_count: 1096 vm.stats.vm.v_wire_count: 179027 vm.stats.vm.v_free_count: 6193 vm.stats.vm.v_free_min: 3260 vm.stats.vm.v_free_target: 13753 vm.stats.vm.v_free_reserved: 713 vm.stats.vm.v_page_count: 509752 vm.stats.vm.v_page_size: 4096 vm.stats.vm.v_tfree: 196418851 vm.stats.vm.v_pfree: 2837177 vm.stats.vm.v_dfree: 0 vm.stats.vm.v_tcached: 1305893 vm.stats.vm.v_pdpages: 3527455 vm.stats.vm.v_pdwakeups: 187 vm.stats.vm.v_reactivated: 83786 vm.stats.vm.v_intrans: 3053 vm.stats.vm.v_vnodepgsout: 134384 vm.stats.vm.v_vnodepgsin: 29213 vm.stats.vm.v_vnodeout: 96249 vm.stats.vm.v_vnodein: 29213 vm.stats.vm.v_swappgsout: 19730 vm.stats.vm.v_swappgsin: 8573 vm.stats.vm.v_swapout: 5287 vm.stats.vm.v_swapin: 2975 vm.stats.vm.v_ozfod: 83338 vm.stats.vm.v_zfod: 2462557 vm.stats.vm.v_cow_optim: 330 vm.stats.vm.v_cow_faults: 1239253 vm.stats.vm.v_vm_faults: 5898471 fbsd# sysctl vm.vmtotal vm.vmtotal: System wide totals computed every five seconds: (values in kilobytes) === Processes: (RUNQ: 1 Disk Wait: 0 Page Wait: 0 Sleep: 60) Virtual Memory: (Total: 4971660K Active: 699312K) Real Memory:(Total: 540776K Active: 29756K) Shared Virtual Memory: (Total: 41148K Active: 19468K) Shared Real Memory: (Total: 4964K Active: 3048K) Free Memory Pages: 105308K /usr/bin/top line: Mem: 4664K Active, 73M Inact, 700M Wired, 79M Cache, 199M Buf, 23M Free Sum (Without Buf):
Re: High interrupt rate on a PF box + performance
W dniu 2011-01-27 10:57, Damien Fleuriot pisze: Hello list, I have a problem with interrupts, network cards, and PF performance. I think you should try with polling(4) enabled and probably increase kernel.hz i sysctl.conf :) -- Bartosz Stec ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: top shows only part of available physmem
W dniu 2011-01-26 19:44, John Baldwin pisze: On Wednesday, January 26, 2011 1:04:02 pm Marco van Tol wrote: On Wed, Jan 26, 2011 at 12:35:56PM -0500, John Baldwin wrote: On Wednesday, January 26, 2011 8:20:28 am Bartosz Stec wrote: W dniu 2011-01-26 14:06, John Baldwin pisze: On Wednesday, January 26, 2011 7:20:34 am Bartosz Stec wrote: Guys, could someone explain me this? # sysctl hw.realmem hw.realmem: 2139029504 top line shows: Mem: 32M Active, 35M Inact, 899M Wired, 8392K Cache, 199M Buf, 58M Free 32+35+899+8+199+58 = 1231MB Shouldn't that sum to all available ram? Or maybe I'm reading it wrong? This machine has indeed 2GB of ram on board and showed in BIOS. i386 FreeBSD 8.2-PRERELEASE #16: Mon Jan 17 22:28:53 CET 2011 Cheers. First, don't include 'buf' as isn't a separate set of RAM, it is only a range of the virtual address space in the kernel. It used to be relevant when the buffer cache was separate from the VM page cache, but now it is mostly irrelevant (arguably it should just be dropped from top output). Thanks for the explanation. So 1231MB - 199MB Buf and we got about 1GB of memory instead of 2B. However, look at what hw.physmem says (and the realmem and availmem lines in dmesg). realmem is actually not that useful as it is not a count of the amount of memory, but the address of the highest memory page available. There can be less memory available than that due to "holes" in the address space for PCI memory BARs, etc. OK, here you go: # sysctl hw | grep mem hw.physmem: 2125893632 hw.usermem: 1212100608 hw.realmem: 2139029504 hw.pci.host_mem_start: 2147483648 Humm, you should still have 2GB of RAM then. All the memory you set aside for ARC should be counted in the 'wired' count, so I'm not sure why you see 1GB of RAM rather than 2GB. For what its worth (seems to be the same values top shows), the sysctl's I use to make cacti graphs of memory usage are: (Counts are in pages) vm.stats.vm.v_page_size vm.stats.vm.v_wire_count vm.stats.vm.v_active_count vm.stats.vm.v_inactive_count vm.stats.vm.v_cache_count vm.stats.vm.v_free_count Using the output of those sysctls I allways get a cacti graph which at least very much seems to account for all memory, and has a flat surface in a stacked graph. These sysctls are exactly what top uses. There is also a 'v_page_count' which is a total count of pages. So here's additional sysctl output from now: fbsd# sysctl hw | grep mem hw.physmem: 2125893632 hw.usermem: 1392594944 hw.realmem: 2139029504 hw.pci.host_mem_start: 2147483648 fbsd# sysctl vm.stats.vm vm.stats.vm.v_kthreadpages: 0 vm.stats.vm.v_rforkpages: 0 vm.stats.vm.v_vforkpages: 1422927 vm.stats.vm.v_forkpages: 4606557 vm.stats.vm.v_kthreads: 40 vm.stats.vm.v_rforks: 0 vm.stats.vm.v_vforks: 9917 vm.stats.vm.v_forks: 30429 vm.stats.vm.v_interrupt_free_min: 2 vm.stats.vm.v_pageout_free_min: 34 vm.stats.vm.v_cache_max: 27506 vm.stats.vm.v_cache_min: 13753 vm.stats.vm.v_cache_count: 20312 vm.stats.vm.v_inactive_count: 18591 vm.stats.vm.v_inactive_target: 20629 vm.stats.vm.v_active_count: 1096 vm.stats.vm.v_wire_count: 179027 vm.stats.vm.v_free_count: 6193 vm.stats.vm.v_free_min: 3260 vm.stats.vm.v_free_target: 13753 vm.stats.vm.v_free_reserved: 713 vm.stats.vm.v_page_count: 509752 vm.stats.vm.v_page_size: 4096 vm.stats.vm.v_tfree: 196418851 vm.stats.vm.v_pfree: 2837177 vm.stats.vm.v_dfree: 0 vm.stats.vm.v_tcached: 1305893 vm.stats.vm.v_pdpages: 3527455 vm.stats.vm.v_pdwakeups: 187 vm.stats.vm.v_reactivated: 83786 vm.stats.vm.v_intrans: 3053 vm.stats.vm.v_vnodepgsout: 134384 vm.stats.vm.v_vnodepgsin: 29213 vm.stats.vm.v_vnodeout: 96249 vm.stats.vm.v_vnodein: 29213 vm.stats.vm.v_swappgsout: 19730 vm.stats.vm.v_swappgsin: 8573 vm.stats.vm.v_swapout: 5287 vm.stats.vm.v_swapin: 2975 vm.stats.vm.v_ozfod: 83338 vm.stats.vm.v_zfod: 2462557 vm.stats.vm.v_cow_optim: 330 vm.stats.vm.v_cow_faults: 1239253 vm.stats.vm.v_vm_faults: 5898471 fbsd# sysctl vm.vmtotal vm.vmtotal: System wide totals computed every five seconds: (values in kilobytes) === Processes: (RUNQ: 1 Disk Wait: 0 Page Wait: 0 Sleep: 60) Virtual Memory: (Total: 4971660K Active: 699312K) Real Memory:(Total: 540776K Active: 29756K) Shared Virtual Memory: (Total: 41148K Active: 19468K) Shared Real Memory: (Total: 4964K Active: 3048K) Free Memory Pages: 105308K /usr/bin/top line: Mem: 4664K Active, 73M Inact, 700M Wired, 79M Cache, 199M Buf, 23M Free Sum (Without Buf): 879,5 MB So what are we looking at? Wrong sysctls/top output or maybe actually FreeBSD doesn't use all available RAM for some reason? Could it be ha
Re: top shows only half of realmem?
W dniu 2011-01-26 14:06, John Baldwin pisze: On Wednesday, January 26, 2011 7:20:34 am Bartosz Stec wrote: Guys, could someone explain me this? # sysctl hw.realmem hw.realmem: 2139029504 top line shows: Mem: 32M Active, 35M Inact, 899M Wired, 8392K Cache, 199M Buf, 58M Free 32+35+899+8+199+58 = 1231MB Shouldn't that sum to all available ram? Or maybe I'm reading it wrong? This machine has indeed 2GB of ram on board and showed in BIOS. i386 FreeBSD 8.2-PRERELEASE #16: Mon Jan 17 22:28:53 CET 2011 Cheers. First, don't include 'buf' as isn't a separate set of RAM, it is only a range of the virtual address space in the kernel. It used to be relevant when the buffer cache was separate from the VM page cache, but now it is mostly irrelevant (arguably it should just be dropped from top output). Thanks for the explanation. So 1231MB - 199MB Buf and we got about 1GB of memory instead of 2B. However, look at what hw.physmem says (and the realmem and availmem lines in dmesg). realmem is actually not that useful as it is not a count of the amount of memory, but the address of the highest memory page available. There can be less memory available than that due to "holes" in the address space for PCI memory BARs, etc. OK, here you go: # sysctl hw | grep mem hw.physmem: 2125893632 hw.usermem: 1212100608 hw.realmem: 2139029504 hw.pci.host_mem_start: 2147483648 And here's the part of /boot/loader.conf for ZFS tuning which may (or probably may not) connected to this issue: vm.kmem_size="1536M" vm.kmem_size_max="1536M" vfs.zfs.arc_max="1280M" -- Bartosz Stec ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
top shows only half of realmem?
Guys, could someone explain me this? # sysctl hw.realmem hw.realmem: 2139029504 top line shows: Mem: 32M Active, 35M Inact, 899M Wired, 8392K Cache, 199M Buf, 58M Free 32+35+899+8+199+58 = 1231MB Shouldn't that sum to all available ram? Or maybe I'm reading it wrong? This machine has indeed 2GB of ram on board and showed in BIOS. i386 FreeBSD 8.2-PRERELEASE #16: Mon Jan 17 22:28:53 CET 2011 Cheers. -- Bartosz Stec ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: very stupid mistake: a part of /usr is deleted
On 2010-09-15 17:20, Ivan Voras wrote: uname -a -> FreeBSD (XX).uni-tuebingen.de 8.0-RELEASE FreeBSD 8.0-RELEASE #0: Sat Nov 21 15:02:08 UTC 2009 r...@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 That is actually an easy situation to recover, you can do it in at least these ways: 1) if you build/upgrade from source, you can either reinstall if you have working /usr/obj or try and rebuild them if you have working /usr/src (...) This is a solution I would recommend (if time isn't the problem), first csup fresh 8.X sources, rebuild, upgrade, and as a result you will get more than missing files, but 8.1-RELASE + STABLE patches :). -- Bartosz Stec ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ZFS tuning [was: hardware for home use large storage]
On 2010-02-17 09:32, Torfinn Ingolfsen wrote:
On Wed, 17 Feb 2010 09:19:49 +0100
Bartosz Stec wrote:
So here's my reply (last line seems most interesting ;) :
[...snipped...]
Illegal division by zero at ./arc_summary.pl line 242.
FWIW, I also got this line when I ran this script on my idle zfs server.
I'm not a PERL programmer (or programmer at all ;), but what I see is
script doesn't check if L2ARC is used at all, so it will always try
compute these lines:
printf("\tL2 Hit Ratio:\t\t\t%0.2f%%\t%d\n", 100 * ( $l2_hits / (
$l2_hits + $l2_misses )), $l2_hits );
printf("\tL2 Miss Ratio:\t\t\t%0.2f%%\t%d\n", 100 * ( $l2_misses / (
$l2_hits + $l2_misses )), $l2_misses );
printf("\tL2 Feeds Ratio:\t\t\t%0.2f%%\t%d\n", 100 * ( $l2_feeds / (
$l2_hits + $l2_misses )), $l2_feeds );
Without active L2ARC it will always generate divide at zeo error, so it
seems that additional check for usable L2ARC values is needed at first
place.
--
Bartosz Stec
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ZFS tuning [was: hardware for home use large storage]
On 2010-02-17 08:58, jhell wrote: To all those involved in this. More up-to-date: arc_summary.pl r182 Best regards. And watching for replies, So here's my reply (last line seems most interesting ;) : # ./arc_summary.pl - System Summary śro 17 lut 2010 08:16:37 UTC FreeBSD 9.0-CURRENT #20: Fri Feb 12 19:21:34 CET 2010 ncpnc Kernel Version: 99 (osreldate) Hardware Platform: i386 Processor Architecture: i386 Storage pool Version: 14 Filesystem Version: 3 Physical RAM: 1523.41 MiB Kernel Memory Usage TEXT: 9782828, 9.33 MiB DATA: 216801280, 206.76 MiB TOTAL: 226584108, 216.09 MiB 9:16 up 4 days, 6:54, 1 user, load averages: 0,47 0,92 0,59 - ARC Summary Meta Limit: 120.00 MiB Meta Used: 135.00% 162.00 MiB Throttle Count: 0 ARC Size: Current Size: 190.03 MiB (arcsize) Target Size (Adaptive): 209.12 MiB (c) Min Size (Hard Limit): 60.00 MiB (arc_min) Max Size (Hard Limit): 480.00 MiB (arc_max) ARC Size Breakdown: Recently Used Cache Size: 16.00% 33.46 MiB (p) Frequently Used Cache Size: 84.00% 175.66 MiB (c-p) ARC Efficiency: Cache Access Total: 28459411 Cache Hit Ratio: 94.57% 26913166 Cache Miss Ratio: 5.43% 1546245 Actual Hit Ratio: 81.81% 23282481 Data Demand Efficiency: 99.48% Data Prefetch Efficiency: 54.15% CACHE HITS BY CACHE LIST: Anonymous: 11.07% 2978474 Most Recently Used: 16.42% 4419712 (mru) Most Frequently Used: 70.09% 18862769 (mfu) Most Recently Used Ghost: 0.98% 264205 (mru_ghost) Most Frequently Used Ghost: 1.44% 388006 (mfu_ghost) CACHE HITS BY DATA TYPE: Demand Data: 53.58% 14419664 Prefetch Data: 0.07% 20017 Demand Metadata: 32.68% 8794182 Prefetch Metadata: 13.67% 3679303 CACHE MISSES BY DATA TYPE: Demand Data: 4.88% 75410 Prefetch Data: 1.10% 16946 Demand Metadata: 59.18% 915133 Prefetch Metadata: 34.84% 538756 L2 ARC Summary Low Memory Aborts: 0 Bad Checksums: 0 IO Errors: 0 L2 ARC Size: Current Size: 0.00 MiB Header Size: 0.00 MiB L2 ARC Breakdown: L2 Access Total: 0 Illegal division by zero at ./arc_summary.pl line 242. -- Bartosz Stec ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: RELENG_7 if_nve panic
W dniu 2010-01-26 10:29, Dmitry Sivachenko pisze: Hello! I recompiled recent RELENG_7 and I get the following panic after trying to kldload if_nve (interesting stack frames are 12, 13, 14 I guess). Previous version of RELENG_7 (compiled in the middle of December) worked fine. Last few days I was trying to re-cvsup and always get the same panic. I get FreeBSD sources via cvsup (cvsup5.freebsd.org). Any suggestions? As well as I know nve driver is based on nvidia binaries (and it's buggy), and that's way it was replaced by nfe driver as default for nvidia based NICs as soon as it was ported from OpenBSD. So my suggestion - if you just need NIC working, use nfe not nve. -- Bartosz Stec ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Going to BSD 8 from RELENG_7
Ruben de Groot pisze: On Mon, Aug 17, 2009 at 09:18:11AM +0200, Bartosz Stec typed: And as usual MAKE A GOOD BACKUP Regards, Johan As I remember when I did upgrade from FreBSD 6.4 to 7.0, I ran 'portupgrade -afi' after thar, BUT as I remember all my ports in fact works before they were upgraded. If I understand correctly, the reason of this was not making delete-old and delete-old-libs? So should following upgrade procedure be painless? 0. Backup! 1. cvsup 8.0-stable 2. make buildworld && make buildkernel 3. make installkernel 4. reboot and jump to single user mode 5. make installworld && mergemastger 6. take a deep breath & reboot 7. portupgrade -afi 8. make delete-old && make delete-old-libs 9. reboot 10. Hooray! My concern is - will my ports works after point 6. ? Quite important thing when machine can't be offline by hours during portupgrade -afi What do you want to hear? "Yes, all will be fine" ? There's never such guarantee. If it means that much to you, MAKE A GOOD BACKUP. And be prepared to restore it. And if the machine really can't be offline for some hours, you should have a fallback machine anyway which you could use to test it on. cheers, Ruben Oh well, I don't want to hear any guarantees :) . Simple 'It should be OK' or 'You will probably get into troubles with this procedure so use test machine first' would be great. Fortunately Johan Hendriks already gave me answer that explained everything: If the old libs are still there all ports will work after the reboot. So a reboot should do no harm. To test this, try it First on a spare box. this way you will see the problems, or issues if they arise. Also make sure your hardware is fully supported by FreeBSD 8, I always put in a livecd and try all my drive's and mirrors and so on. Also be aware that the libusb port is in the base system on 8. And i do not know if they work on a 8 system with the libusb port installed. But it sounds like a server so there should be little ports that needs libusb. Thank you Johan. -- Bartosz Stec ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Going to BSD 8 from RELENG_7
Johan Hendriks pisze: Be aware that if you go from 7 to 8 you will need to rebuild all your installed ports. ALso if you do a buildworld from 7 to 8 do not do the make delete-old and the make delete-old-libs before you have rebuild your ports. If you do the make delete-old and make delete-old-libs runs, all ports depending on the FreeBSD 7 libs will not work any more. << read: most likely all your ports. If you have changed for example your Shell for root to a ports based shell like bash and you do the make delete-old-libs you can not log in anymore, because bash depends on the 7 libs wich are not there anymore. And as usual MAKE A GOOD BACKUP Regards, Johan As I remember when I did upgrade from FreBSD 6.4 to 7.0, I ran 'portupgrade -afi' after thar, BUT as I remember all my ports in fact works before they were upgraded. If I understand correctly, the reason of this was not making delete-old and delete-old-libs? So should following upgrade procedure be painless? 0. Backup! 1. cvsup 8.0-stable 2. make buildworld && make buildkernel 3. make installkernel 4. reboot and jump to single user mode 5. make installworld && mergemastger 6. take a deep breath & reboot 7. portupgrade -afi 8. make delete-old && make delete-old-libs 9. reboot 10. Hooray! My concern is - will my ports works after point 6. ? Quite important thing when machine can't be offline by hours during portupgrade -afi -- Bartosz Stec ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: upgrading ports without recompiling
CmdLnKid pisze:
On Mon, 6 Jul 2009 13:16 -, pj wrote:
Ishmael F.E. wrote:
[...]
.
so, ¿how can I upgrade the ports?
unfortunatley I don't have time to compile my 64bit system
You don't need to compile whole OS to compile ports, if this is what you
had in mind.
Have you looked at the -PP option of portupgrade?
I don't know how portmaster handles upgrades using packages only.
You could look into devel/ccache & devel/distcc if you would like to
speed up your compile times. Of course your first compile will always
be the slowest one but everyone after that will be faster. This is not
always advised as a good solution and has been known to throw some
pretty weird compiler bugs and also fail while compiling certain ports
but that is tweakable through /etc/make.conf*.
Well, I heard about some problems with ccache, although I personally
experienced only one of them - fail when building world on AMD64. Here's
my make.conf, feel free to give it try after installing ccache (Try to
set MAKEOPTS = CPU cores +1, and set appropriate CPUTYPE):
CPUTYPE=athlon64
MAKEOPTS=-j3
# USE CCACHE
.if !defined(NOCCACHE)
CC=/usr/local/libexec/ccache/world-cc
CXX=/usr/local/libexec/ccache/world-c++
.endif
# default build settings for ports collection
.if ${.CURDIR:M*/ports/*}
CFLAGS= -O2 -fno-strict-aliasing -pipe -funroll-loops
-fomit-frame-pointer
CXXFLAGS= -O2 -fno-strict-aliasing -pipe -funroll-loops
.endif
# default build settings for base system
.if ${.CURDIR:M*/usr/src/*} || ${.CURDIR:M*/usr/obj/*}
CFLAGS=-O2 -fno-strict-aliasing -pipe
COPTFLAGS=-O2 -fno-strict-aliasing -pipe
CXXFLAGS=${CFLAGS}
.endif
In case of any problem with specific port (or world) type in shell:
# setenv NOCCACHE
before build. This should give you maximum compile speed in case when
package is unavailable while using portupgrade -afP
--
Bartosz Stec
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Problems with PATA disk
Adam K Kirchhoff wrote: atap...@pci0:5:3:0: class=0x018000 card=0x3375105a chip=0x3375105a rev=0x020 vendor = 'Promise Technology Inc' device = 'PDC20375(??) FastTrak SATA150 TX2plus Controller' class = mass storage This happens frequently with Promise TX2/TX4 (less frequently in RELENG-7 than RELENG-6) and issue is probably related to controller driver. GEOM_LABEL: Label ufsid/4a296b573007b5f2 removed. Jun 8 14:35:42 memory last message repeated 7 times ad14: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly ad14: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly ad14: WARNING - SETFEATURES ENABLE RCACHE taskqueue timeout - completing request directly ad14: WARNING - SETFEATURES ENABLE WCACHE taskqueue timeout - completing request directly acd0: WARNING - TEST_UNIT_READY taskqueue timeout - completing request directly ad14: WARNING - SET_MULTI taskqueue timeout - completing request directly ad15: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly ad15: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly ad15: WARNING - SETFEATURES ENABLE RCACHE taskqueue timeout - completing request directly ad15: WARNING - SETFEATURES ENABLE WCACHE taskqueue timeout - completing request directly ad15: WARNING - SET_MULTI taskqueue timeout - completing request directly ad15: TIMEOUT - READ_DMA48 retrying (1 retry left) LBA=470440143 Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x188 fault code = supervisor read, page not present instruction pointer = 0x20:0xc07d4d94 stack pointer = 0x28:0xc62f9c00 frame pointer = 0x28:0xc62f9c18 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 23 (swi6: task queue) trap number = 12 panic: page fault cpuid = 0 Uptime: 1m56s Physical memory: 3058 MB Dumping 113 MB: 98 82 66 50 34 18 2 Dump complete Automatic reboot in 15 seconds - press a key on the console to abort Rebooting... cpu_reset: Stopping other CPUs Unfortunately, nothing showed up in /var/crash, which I think is odd. I'll update my -STABLE, rebuild my kernel with debugging, and hope to catch something next time. In this case controller probably loose whole drive (disconnected and dissapear from 'atacontrol list'), that's why you see no core dropped, and powering machine off and on let it recognize the drive again. I have this issue from time to time with TX4, but fortunately i have 2 disks in gmirror, so when one drive disconnect I force rebuilding mirro by just powering machine off and on. You're using 7.2-stable, so it seems that OS upgrade won't help you (after upgrade from FreeBSD 6 to 7 issue has been seen 80% less frequently for me), so my one and only suggestion for you is using different PATA controller if you can. -- Bartosz Stec ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: support quality (Re: dump | restore fails: unknown tape header type 1853384566)
Yes, dump is broken for you, deal with it. It is quite possible your FS is corrupt, and/or your disk is damaged. ..and/or it is some other hardware problem, maybe you also should test your memory with memtest or something similiar? I'm using dump/restore very frequently and I had never seen such problem. Neither on -RELAESE, -STABLE, nor -CURRENT. So I think you should make sure that your problem is not hardware/filesystem dependent before you point dump/restore as a couse of the problem. Peter Jeremy already gives you good hints to do that. -- Bartosz Stec. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: unkillable proceess
dikshie pisze: Hi, how to kill unkillable process: # ps axuf |grep http www 66005 73.4 1.3 87656 13164 ?? R 4:58PM 62:24.41 /usr/local/sbin/httpd -DSSL -DNOHTTPACCEPT www 4277 71.6 1.4 88680 13964 ?? R 4:12PM 48:23.40 /usr/local/sbin/httpd -DSSL -DNOHTTPACCEPT www 2708 65.5 1.4 88680 14112 ?? R 4:12PM 54:39.50 /usr/local/sbin/httpd -DSSL -DNOHTTPACCEPT above processes unkillable regards, -dikshie- Try: apachectl stop /usr/local/etc/rc.d/apache22 stop -- Bartosz Stec ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: problems with sata disks (taskqueue timeout)
Marc UBM pisze: Hiho! :-) Occasionally, especially when uploading a large number of files, the (brand-new, tested) sata disks in my fileserver spit out some of these errors: --- Jan 19 19:51:14 hamstor kernel: ad10: WARNING - WRITE_DMA48 UDMA ICRC error (retrying request) LBA=882778752 Jan 19 19:51:23 hamstor kernel: ad10: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly Jan 19 19:51:27 hamstor kernel: ad10: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly Jan 19 19:51:31 hamstor kernel: ad10: WARNING - SETFEATURES ENABLE WCACHE taskqueue timeout - completing request directly Jan 19 19:51:35 hamstor kernel: ad10: WARNING - SET_MULTI taskqueue timeout - completing request directly Jan 19 19:51:35 hamstor kernel: ad10: TIMEOUT - WRITE_DMA48 retrying (0 retries left) LBA=882778752 Jan 19 19:51:35 hamstor kernel: ad10: FAILURE - WRITE_DMA48 status=ff error=ff LBA=882778752 Jan 19 19:51:35 hamstor root: ZFS: vdev I/O failure, zpool=gedaerm path=/dev/ad10 offset=451982655488 size=131072 error=5 Jan 19 19:51:41 hamstor kernel: ad10: FAILURE - SET_MULTI status=51 error=4 Jan 19 19:51:41 hamstor kernel: ad10: TIMEOUT - WRITE_DMA48 retrying (1 retry left) LBA=882779008 Jan 19 19:51:41 hamstor kernel: ad10: WARNING - WRITE_DMA48 UDMA ICRC error (retrying request) LBA=882779008 Jan 19 19:51:50 hamstor kernel: ad10: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly Jan 19 19:51:54 hamstor kernel: ad10: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly Jan 19 19:51:58 hamstor kernel: ad10: WARNING - SETFEATURES ENABLE WCACHE taskqueue timeout - completing request directly Jan 19 19:52:02 hamstor kernel: ad10: WARNING - SET_MULTI taskqueue timeout - completing request directly Jan 19 19:52:02 hamstor kernel: ad10: FAILURE - WRITE_DMA48 timed out LBA=882779008 Jan 19 19:52:02 hamstor root: ZFS: vdev I/O failure, zpool=gedaerm path=/dev/ad10 offset=451982786560 size=131072 error=5 --- I've fiddled with the cables, which seemed to help, but I've been unable to completely eliminate the errors. The disks are two Western Digital MyBooks Home Edition (1 TB per disk), connected to a Promise TX 4 SATA Controller: atap...@pci0:1:6:0: class=0x018000 card=0x3d17105a chip=0x3d17105a rev=0x02 hdr=0x00 vendor = 'Promise Technology Inc' device = 'PDC40718-GP SATA 300 TX4 Controller' class = mass storage They're connected via 50cm esata cables. I've googled on the net and found some vague hints about problems with the Promise TX4, but nothing concrete. What I've found is http://wiki.freebsd.org/JeremyChadwick/ATA_issues_and_troubleshooting basically telling me "these things happen, deal with it" :-) The problem is, I cannot produce these problems reliably, only thing I notice is that they *seem* to happen more often if a lot of large files are copied in succession. Can anybody tell me if upgrading to 7.2 oder -current will help? I'm currently running 7.0-STABLE-200804 FreeBSD 7.0-STABLE-200804 #0: Wed Dec 10 15:29:03 CET 2008 *...@host:/usr/obj/usr/src/sys/GENERIC amd64 Next step I'll try is upgrading to RELENG_7 to see if that helps. Greetings, Marc Cheers Marc. My personal experience makes me think that this issue is controller/driver related. I'm using SATA 300 TX4 Controller from times of 6.1-Relaese on my fileserver (with 2 of 4 ports used) and I saw a lot of exactly the same errors in logs. Sometimes it was harmless, but sometimes as an effect of these one of disks magically disconnected from controller and only way to get it back and working was power down and up PC. That mostly happened while heavy I/O like while dumping filesystems. Good thing is that starting from 7.0-release I saw such errors maybe 2-3 times and I didn't saw them at all from at least 6 months. Probably because I rebuild my system about once a month to keep up with stable branch and something was corrected in sources through that time. So I also advice to upgrade to RELENG_7 and you probably get rid of these. Good luck! -- Bartosz Stec ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FreeBSD 7.1 Breaks re and rl Network Interface Drivers
Pyun YongHyeon pisze: On Wed, Jan 14, 2009 at 03:18:16PM +0100, Bartosz Stec wrote: > 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-unsubscr...@freebsd.org" > > > I can confirm issues with re and 7.1-R > > dmesg: > re0: port > 0xbc00-0xbcff mem 0xfbfff000-0xfbfff0ff irq 17 at device 7.0 on pci1 > re0: Chip rev. 0x1800 > re0: MAC rev. 0x > > 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 > Would you try attached patch? I could test patch today BUT I made machine restart a couple of hours after NIC problem occurs (just to be sure) and after reboot re0 starts working OK until now. So maybe it was re0 problem or maybe it was something else. Even so, should I apply patch and report if NIC works? -- Bartosz Stec ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FreeBSD 7.1 Breaks re and rl Network Interface Drivers
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-unsubscr...@freebsd.org" I can confirm issues with re and 7.1-R dmesg: re0: port 0xbc00-0xbcff mem 0xfbfff000-0xfbfff0ff irq 17 at device 7.0 on pci1 re0: Chip rev. 0x1800 re0: MAC rev. 0x 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 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Burning DVD with files>4GB from console
Bob Johnson pisze: On 12/4/08, Bartosz Stec <[EMAIL PROTECTED]> wrote: Philipp Ost pisze: Hi, Bartosz Stec wrote: [...] Is there *any* way to burn DVDs with files>4GB from FreeBSD console? I succesfully used growisofs for exactly this task ;-) What I did is (for DL-DVDs): # growisofs -dvd-compat -Z /dev/cd0=$file.iso -speed=2 I had to limit the speed, else it wouldn't do anything. If I burn "normal" DVDs I don't need the speed limit. HTH, Philipp But doesn't that command expecting file.iso being already premastered ISO image? OK, that's *some* way, but to be clear - I want to avoid preparing ISO images too ;) Some thoughts that might be useful: 1) I expect the problem is with mkisofs version 2.01 that is used in FreeBSD (at least in 7.0), but I haven't attempted to confirm this. Growisofs is supposed to handle large files, and so are recent versions of mkisofs. The author of mkisofs considers 2.01 to be obsolete. Perhaps installing a newer mkisofs is the solution (e.g. sysutils/cdrtools-devel appears to be fairly recent)? 2) Perhaps you could do what I do and write tar files directly to DVD with no filesystem. I use burncd to write the file to the DVD, but I don't remember if I've tried to exceed 4 GiB per file. You might need growisofs in premastered image mode instead of burncd. To read the file later use something like 'tar -xf /dev/cd0'. Might have a problem with this in Windows, but maybe that's not really a problem? 3) You could modify your script to use mkisofs to create the ISO image as part of the process of splitting your files into (smaller) chunks. Then use growisofs in premastered image mode, as already suggested. If you want to do this, look at the -stream-media-size option in mkisofs. 4) The 4 GiB limit on file size is built into the ISO 9660 filesystem prior to Level 3. Level 3 allows larger files by allowing files to have multiple extents (each extent must still be < 4 GiB). You may need to explicitly specify ISO Level 3 to get the correct behavior (i.e. use the '-iso-level 3' option with growisofs or mkisofs). -- Bob Johnson [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]" Thanks a lot! Upgrading to sysutils/cdrtools-devel solves my problem! :) -- Bartosz Stec ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Burning DVD with files>4GB from console
Steve Polyack pisze: Not too say you're .iso images can't be >2GB/4GB, but I'm pretty sure the ISO9660 standard is limited to a 2GB maximum file size (for files within the .iso). You must use UDF to burn files of greater size. mkisofs(8) seems to support this, if only in alpha/hybrid stage: -udf Include UDF support in the generated filesystem image. UDF sup- port is currently in alpha status and for this reason, it is not possible to create UDF only images. Indeed. I'm using -udf switch, no success. -- Bartosz Stec ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Burning DVD with files>4GB from console
Stephen Montgomery-Smith pisze: David Kelly wrote: On Thu, Dec 04, 2008 at 10:48:54AM +0100, Bartosz Stec wrote: My backup script split filesystem dumps to files with size of 4,37 GB (4 588 544 kB). It's just an optimal size to fill out DVDs. At this moment I have to burn them from windows via smb-link becuase I didn't manage to do this task from FreeBSD console due to 2GB/4GB filesize restrictions (growisofs). Since when did FreeBSD (or growisofs) have a 2GB/4GB filesize limit? I have burned 4.3GB DVDs several times. I never had a problem writing huge files. But I did have a problem subsequently reading it with Windows XP. Maybe the file size restriction is a Windows thing. Nope. I am burning my backups from Windows, and they're readable both from Windows and FreeBSD. FreeBSD just doesn't let me burn them directly :) -- Bartosz Stec ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Burning DVD with files>4GB from console
David Kelly pisze: On Thu, Dec 04, 2008 at 12:44:14PM -0500, Steve Polyack wrote: Not too say you're .iso images can't be >2GB/4GB, but I'm pretty sure the ISO9660 standard is limited to a 2GB maximum file size (for files within the .iso). You must use UDF to burn files of greater size. mkisofs(8) seems to support this, if only in alpha/hybrid stage: -udf Include UDF support in the generated filesystem image. UDF sup- port is currently in alpha status and for this reason, it is not possible to create UDF only images. It would seem then that the O.P. who is already splitting his backup into 4.3GB chunks should split backups into sub-2GB chunks. 4,700,000,000 is the standard DVD size, I'd shoot for chunks of 4.5E9/3 so as to have about 200MB of headroom per DVD. growisofs will write 3 files to the DVD just as easily as one. The magic of growisofs is that it invokes mkisofs on the fly. And also that cdrecord had obnoxious (and broken) licensing in years past when I last tried it. Yes, I know that. My reasons for keeping one file on DVD are just for making my life easier. If I want to restore some files from filesystem backup (they are made via pipeline dump | gunzip | split) I have to copy all files from DVDs wchich includes needed filesystem and then I type: cat file1 file2 file3 ... fileN | gunzip | restore -if - And yes, I know that tapes are much better for tasks like this but for now I just have to use DVDs :) Now imagine backup placed on 10 DVDs. With single file on DVD I have 10 files to manage, not 30. I know there're workarounds but with more files I probably will need some script to restore files rather than do it manually. That's the reason I asked if there's a possibility to burn it this way from FreeBSD. -- Bartosz Stec ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Burning DVD with files>4GB from console
David Kelly pisze: On Thu, Dec 04, 2008 at 10:48:54AM +0100, Bartosz Stec wrote: My backup script split filesystem dumps to files with size of 4,37 GB (4 588 544 kB). It's just an optimal size to fill out DVDs. At this moment I have to burn them from windows via smb-link becuase I didn't manage to do this task from FreeBSD console due to 2GB/4GB filesize restrictions (growisofs). Since when did FreeBSD (or growisofs) have a 2GB/4GB filesize limit? I have burned 4.3GB DVDs several times. Just look, here is example: fbsd# growisofs -Z /dev/cd0 -R -J -udf -iso-level 3 -dry-run somefile Executing 'mkisofs -R -J -udf -iso-level 3 somefile | builtin_dd of=/dev/pass0 obs=32k seek=0' mkisofs: Value too large to be stored in data type. File somefile is too large - ignoring I'm not talking about restriction of DVD size, but restriction to filesize wchich I want to place on DVD: fbsd# cat somefile | split -b 2G fbsd# rm somefile fbsd# ls -lh total 4590848 -rw-r--r-- 1 root operator 2,0G 5 gru 09:18 xaa -rw-r--r-- 1 root operator 2,0G 5 gru 09:24 xab -rw-r--r-- 1 root operator 385M 5 gru 09:26 xac fbsd# growisofs -v -Z /dev/cd0 -R -J -udf -dry-run ./ Executing 'mkisofs -v -R -J -udf ./ | builtin_dd of=/dev/pass0 obs=32k seek=0' mkisofs 2.01 (i386-unknown-freebsd7.0) Scanning ./ Writing: Initial PadblockStart Block 0 Done with: Initial PadblockBlock(s)16 Writing: Primary Volume Descriptor Start Block 16 Done with: Primary Volume Descriptor Block(s)1 Writing: Joliet Volume DescriptorStart Block 17 Done with: Joliet Volume DescriptorBlock(s)1 Writing: End Volume Descriptor Start Block 18 Done with: End Volume Descriptor Block(s)1 Writing: UDF volume recognition area Start Block 19 Done with: UDF volume recognition area Block(s)3 Writing: Version block Start Block 22 Done with: Version block Block(s)1 Writing: UDF pad to sector 32Start Block 23 Done with: UDF pad to sector 32Block(s)9 Writing: UDF main seqStart Block 32 When I split that file there are no errors and DVD is 4,3GB size. -- Bartosz Stec ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Burning DVD with files>4GB from console
Philipp Ost pisze: Hi, Bartosz Stec wrote: [...] Is there *any* way to burn DVDs with files>4GB from FreeBSD console? I succesfully used growisofs for exactly this task ;-) What I did is (for DL-DVDs): # growisofs -dvd-compat -Z /dev/cd0=$file.iso -speed=2 I had to limit the speed, else it wouldn't do anything. If I burn "normal" DVDs I don't need the speed limit. HTH, Philipp But doesn't that command expecting file.iso being already premastered ISO image? OK, that's *some* way, but to be clear - I want to avoid preparing ISO images too ;) -- Bartosz Stec ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Burning DVD with files>4GB from console
My backup script split filesystem dumps to files with size of 4,37 GB (4 588 544 kB). It's just an optimal size to fill out DVDs. At this moment I have to burn them from windows via smb-link becuase I didn't manage to do this task from FreeBSD console due to 2GB/4GB filesize restrictions (growisofs). I'm using freeware CDBurnerXP to burn my backups (ISO9660/UDF/Joliet), and they mount without problems on my FreeBSD BOX, files are fully readable too. However, burning gigabytes of data via slow (about 3.5MB/s) SMB network is just annoing. Is there *any* way to burn DVDs with files>4GB from FreeBSD console? cheers! -- Bartosz Stec ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: support for natted ftp server and passive mode
Stephen Clark pisze: Do any of the firewall products on FreeBSD provide support for a natted ftp server sitting behind the FreeBSD FW. Without having the ftp server advertise the external address in its passive mode packet, in other words have the firewall product look inside the packet and change the internal address in the data portion of the packet to the external address. Thanks, Steve pf + ftp-proxy http://www.openbsd.org/cgi-bin/man.cgi?query=ftp-proxy&sektion=8&manpath=OpenBSD+4.4 -- Bartosz Stec AUXILIA Spółka z o.o. ul. Wałbrzyska 43/2 52-314 Wrocław tel. (71) 79 99 760 w. 69 GSM: 662171775 E-Mail: [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Will XFS be adopted
martinko pisze: Bartosz Stec wrote: Well it's not simple indeed. I use ZFS on my home (not critical) box (RAIDZ1). After 4 weeks uptime with varied workload I assumed it's stable. Unfortunately ZFS crashed next week ;) How did it crash ? Just the system went down or did you lose any data ? I'm planning to build new home server and put all my valuable data on ZFS but after reading all the mailing lists I'm not so sure about it. :( M. I didn't loose any data , and system was up (ping and packet filter did still working), but filesystem was unaccesible so any kind of process which need hdd acces didn't work correctly (like ssh shell or mail server). Hard reboot was one and only solution ;) Feel free to test ZFS for yourself. Good tuning should made it stable enough for you. You also shouldn't worry for your data, ZFS problems are mainly related to kernel memory exhaustion, not a data corruption (Backups however are always recomended before tasks like this). Check the ZFS tuning guide http://wiki.freebsd.org/ZFSTuningGuide and good luck. My home system is i386 with 1,5GB of memory and tuned with: KERNEL: options KVA_PAGES=512 loader.conf: vm.kmem_size="1024M" vm.kmem_size_max="1024M" It's a very simple tuning, just for tests. My system probably needs ARC settings or vfs.zfs.prefetch_disable=1 to be (more) stable. I'll do more tests, but you probably should do your own - there's no one good tuning solution for every system configuration. Just search this list - there's a lot of examples and hints. Jeremy Chadwick explained a lot of those settings too. -- Bartosz Stec AUXILIA Spółka z o.o. ul. Wałbrzyska 43/2 52-314 Wrocław tel. (71) 79 99 760 w. 69 GSM: 662171775 E-Mail: [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: gmirror and gstripe
Nenhum_de_Nos pisze: hail, I have an old AthlonXP 1700+ running 7-STABLE: FreeBSD xxx 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #1: Thu Nov 13 23:54:59 BRT 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/xxx i386 where I have two 750GB Seagate SATA Disks. They are divided as two slices, around the first 120GB are gathered in gmirror, and what left is in gstripe. so that's whats going on. if the machine locks, and fsck comes to make its job, the box just gets slower and slower till I have to reset it the hard way. to make it not lock after just 5 minutes I have to boot and umount the "arrays", and then run fsck_ufs on them. so this way I can have the box running again. Did you mean that machine slows down while doing background fsck? If yes, problem is probably related to snapshot which is created, and background fsck is done on snapshot. as I can't count on no power outage till the end of days, what can I do ? You may just disable background fsck and do it manually in single user mode in that case just by typing fsck -y. i just recompiled stable to make it stop this, but no go here ... this is an AthlonXP as said, running on EPoX kt600 based board, sata I is from via southbridge and 1GB of RAM. just another 40GB disk to the system. thanks, matheus If I am correct, your problem is old known and mksnap_ffs related. Jeremy Chadwick wrote a lot about it: http://wiki.freebsd.org/JeremyChadwick/Commonly_reported_issues Good luck. -- Bartosz Stec AUXILIA Spółka z o.o. ul. Wałbrzyska 43/2 52-314 Wrocław tel. (71) 79 99 760 w. 69 GSM: 662171775 E-Mail: [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Will XFS be adopted
Claus Guttesen pisze: [...] I would wait until it has been considered stable and moved into the 7-STABLE tree before deploying a production server. ZFS has been in 7 for over a year. DES Yes, it's in STABLE, however zfs module says: This module (opensolaris) contains code covered by the Common Development and Distribution License (CDDL) see http://opensolaris.org/os/licensing/opensolaris_license/ *WARNING: ZFS is considered to be an experimental feature in FreeBSD.* So ZFS in 7.X should not be considered as STABLE for now. Install a server with zfs and test it. Then let it handle tasks that are not critical. And if it works for you proceed and deploy it. It's somewhat difficult to say that it works for your particular workload. Some have rather positive experience and others are very reluctant. I use it as an internal samba-server and the issues I have are related to the external sas-cabinet rather than zfs itself. Well it's not simple indeed. I use ZFS on my home (not critical) box (RAIDZ1). After 4 weeks uptime with varied workload I assumed it's stable. Unfortunately ZFS crashed next week ;) -- Bartosz Stec AUXILIA Spółka z o.o. ul. Wałbrzyska 43/2 52-314 Wrocław tel. (71) 79 99 760 w. 69 GSM: 662171775 E-Mail: [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Will XFS be adopted
Dag-Erling Smørgrav pisze: Andrew Snow <[EMAIL PROTECTED]> writes: [...] I would wait until it has been considered stable and moved into the 7-STABLE tree before deploying a production server. ZFS has been in 7 for over a year. DES Yes, it's in STABLE, however zfs module says: This module (opensolaris) contains code covered by the Common Development and Distribution License (CDDL) see http://opensolaris.org/os/licensing/opensolaris_license/ *WARNING: ZFS is considered to be an experimental feature in FreeBSD.* So ZFS in 7.X should not be considered as STABLE for now. -- Bartosz Stec AUXILIA Spółka z o.o. ul. Wałbrzyska 43/2 52-314 Wrocław tel. (71) 79 99 760 w. 69 GSM: 662171775 E-Mail: [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: error during buildworld on 7.1 beta
Claus Guttesen pisze: Hi. Did a fresh FreeBSD 7.1 install using the beta on amd64 from disc1. I did a standard-install with sources, performed a csup against RELENG_7 and then a buildworld. It stops at: mv -f term.h.new term.h cc -m32 -march=nocona -mfancy-math-387 -DCOMPAT_32BIT -iprefix /usr/obj/usr/src/lib32/usr/ -L/usr/obj/usr/src/lib32/usr/lib32 -B/usr/obj/usr/src/lib32/usr/lib32 -o make_keys -O2 -fno-strict-aliasing -pipe -I. -I/usr/obj/lib32/usr/src/lib/ncurses/ncurses/../ncurses -I/usr/src/lib/ncurses/ncurses/../ncurses -I/usr/src/lib/ncurses/ncurses/../ncurses -I/usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/include -I/usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/ncurses -Wall -DNDEBUG -DHAVE_CONFIG_H -DFREEBSD_NATIVE -DTERMIOS /usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/ncurses/tinfo/make_keys.c ./make_keys keys.list > init_keytry.h ELF interpreter /libexec/ld-elf32.so.1 not found Abort trap *** Error code 134 Stop in /usr/src/lib/ncurses/ncurses. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. 3145.054u 524.920s 1:02:45.53 97.4% 6442+7634k 30091+9519io 3045pf+0w My /etc/make.conf is: CPUTYPE=nocona NO_LPR= true# do not build lpr and related programs NO_SENDMAIL=true# do not build sendmail and related programs USA_RESIDENT= NO Do I have to make any changes to make.conf? First of all - check if /libexec/ld-elf32.so.1 exists! I don't think any of your lines in make.conf could be problematic. -- Bartosz Stec ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: reloading samba config made system unresponsible
Bartosz Stec wrote: My tries to tune smb.conf to achieve better performance expose very strange bug: Just executing: /usr/local/etc/rc.d/samba reload made my system unresponsible from network. It happens three times until now so I'm sure that is the cause (but it happened after some succesful reloads a couple of minutes earlier, so it's not happening all the time command is executed). Symptoms: - machine only responding to ping requests - ssh session shows, that config reload was succesful, and that's last thing showed (no shell after message) - can't connect with another ssh session, but no refuse nor timeout - on local console system seems responsible (alt +[1-9] works), but any try to login cause it to wait forever for password prompt - no kernel or error message on screen, and nothing suspicious in logs - alt+ctrl+del does nothing - pressing power button and waiting for system to shutdown does nothing - hard reset was the only way - after first restart I've made full fsck and started rebuilding gmirror - when machine hangs second time rebuilding doesn't stop I'm not a developer but it looks like some kind of deadlock? Note that changes I made to smb.conf was only in socket options. Update: The true reason of this was a filesystem - I've noticed some strange kernel message about "old format snaphot". Fsck didn't found any fs error, so I just deleted all snapshots from /usr. Problem is gone now. Note that snapshots were about 2 months old so it's still scary :) Sorry for confusion. -- Bartosz Stec ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
reloading samba config made system unresponsible
My tries to tune smb.conf to achieve better performance expose very strange bug: Just executing: /usr/local/etc/rc.d/samba reload made my system unresponsible from network. It happens three times until now so I'm sure that is the cause (but it happened after some succesful reloads a couple of minutes earlier, so it's not happening all the time command is executed). Symptoms: - machine only responding to ping requests - ssh session shows, that config reload was succesful, and that's last thing showed (no shell after message) - can't connect with another ssh session, but no refuse nor timeout - on local console system seems responsible (alt +[1-9] works), but any try to login cause it to wait forever for password prompt - no kernel or error message on screen, and nothing suspicious in logs - alt+ctrl+del does nothing - pressing power button and waiting for system to shutdown does nothing - hard reset was the only way - after first restart I've made full fsck and started rebuilding gmirror - when machine hangs second time rebuilding doesn't stop I'm not a developer but it looks like some kind of deadlock? Note that changes I made to smb.conf was only in socket options. -- Bartosz Stec ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: fxp performance with POLLING
Jeremy Chadwick pisze: On Mon, Oct 06, 2008 at 09:02:33AM +0200, Bartosz Stec wrote: Alfred Perlstein wrote: * Bartosz Stec <[EMAIL PROTECTED]> [081003 07:23] wrote: Hello again :) With POLLING enabled I experience about 10%-25% performance drop when copying files over network. Tested with both SAMBA and NFS. Is it normal? FreeBSD 7.1-PRERELEASE #0: Sat Sep 6 01:52:12 CEST 2008 fxp0: port 0xc800-0xc83f mem 0xe1021000-0xe1021fff irq 20 at device 8.0 on pci1 # ifconfig fxp0 fxp0: flags=9843 metric 0 mtu 1500 options=8 ether 00:20:ed:42:87:13 inet 192.168.0.2 netmask 0xff00 broadcast 192.168.0.255 media: Ethernet autoselect (100baseTX ) status: active BTW overall SAMBA performance still sucks on 7.1-pre as much as on RELENG_5 ...:( - 7.5 MB/s peak. 7.5MB is 75% effeciency of a 100mbit card. Not amazing, but not "sucks". Where do you see faster performance? Between windows machines on the same hardware or linux server? It sucks because it is a peak performance. About 5-6 MB/s average. I tried polling only because I found some suggestions on mailing lists, that it could improve performance with SAMBA on FreeBSD. As you see at the top of this thread - not in my case :) I also tried sysctl tunings, and smb.conf settings, also suggested on maling lists, with no or very little improvements noticed. Most of suggestions unfortunately end with "change OS to Linux if you want to use SAMBA". I think I will try to change NIC to 1Gbit - hope that helps :) Or maybe there's some "FreeBSD and SAMBA tuning guide" which I didn't found? Can you please test network I/O using something like netperf or one of the other network-benchmark tools and not things like NFS or Samba which rely on disk I/O and other aspects? OK It was first time i was using nerperf so I'm not sure I did it correctly. I installed netperf port on SAMBA serwer (IP 192.168.0.2), and also download windows binary to windows xp machine (IP 192.168.0.10). All tests ran for one minute. First test - netperf on FreeBSD and netserver on Windows: # netperf -l 60 -t TCP_STREAM -H 192.168.0.10 TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.0.10 (192.168.0.10) port 0 AF_INET Recv SendSend Socket Socket Message Elapsed Size SizeSize Time Throughput bytes bytes bytessecs.10^6bits/sec 8192 32768 3276860.00 93.97 # netperf -l 60 -t TCP_SENDFILE -H 192.168.0.10 TCP SENDFILE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.0.10 (192.168.0.10) port 0 AF_INET Recv SendSend Socket Socket Message Elapsed Size SizeSize Time Throughput bytes bytes bytessecs.10^6bits/sec 8192 32768 3276860.00 93.45 # netperf -l 60 -t TCP_RR -H 192.168.0.10 TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.0.10 (192.168.0.10) port 0 AF_INET Local /Remote Socket Size Request Resp. Elapsed Trans. Send Recv Size SizeTime Rate bytes Bytes bytesbytes secs.per sec 32768 65536 11 60.002433.99 8192 8192 # ifconfig fxp0 fxp0: flags=9843 metric 0 mtu 1500 options=8 ether 00:20:ed:42:87:13 inet 192.168.0.2 netmask 0xff00 broadcast 192.168.0.255 media: Ethernet autoselect (100baseTX ) status: active Second test - netperf on Windows and netserver on FreeBSD: Unfortunately won't run: C:\software>netperf-a4 -l 60 -H 192.168.0.2 TCP STREAM TEST to 192.168.0.2 recv_response: partial response received: 0 bytes Hovewer, thanks to Alfred Perlstein who send mefollowing link: http://www.mavetju.org/mail/view_message.php?list=freebsd-net&id=755111&thread=no&tag=yes, I set SO_SNBUF and SO_RCVBUF in smb.conf to 2920. Without any additional tuning in sysctl I now got about 8MB/s which is *much* better result than before. It still could be better than that if I am reading netpertf results correctly :) Thanks Alfred! -- Bartosz Stec ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: fxp performance with POLLING
Alfred Perlstein wrote: * Bartosz Stec <[EMAIL PROTECTED]> [081003 07:23] wrote: Hello again :) With POLLING enabled I experience about 10%-25% performance drop when copying files over network. Tested with both SAMBA and NFS. Is it normal? FreeBSD 7.1-PRERELEASE #0: Sat Sep 6 01:52:12 CEST 2008 fxp0: port 0xc800-0xc83f mem 0xe1021000-0xe1021fff irq 20 at device 8.0 on pci1 # ifconfig fxp0 fxp0: flags=9843 metric 0 mtu 1500 options=8 ether 00:20:ed:42:87:13 inet 192.168.0.2 netmask 0xff00 broadcast 192.168.0.255 media: Ethernet autoselect (100baseTX ) status: active BTW overall SAMBA performance still sucks on 7.1-pre as much as on RELENG_5 ...:( - 7.5 MB/s peak. 7.5MB is 75% effeciency of a 100mbit card. Not amazing, but not "sucks". Where do you see faster performance? Between windows machines on the same hardware or linux server? It sucks because it is a peak performance. About 5-6 MB/s average. I tried polling only because I found some suggestions on mailing lists, that it could improve performance with SAMBA on FreeBSD. As you see at the top of this thread - not in my case :) I also tried sysctl tunings, and smb.conf settings, also suggested on maling lists, with no or very little improvements noticed. Most of suggestions unfortunately end with "change OS to Linux if you want to use SAMBA". I think I will try to change NIC to 1Gbit - hope that helps :) Or maybe there's some "FreeBSD and SAMBA tuning guide" which I didn't found? -- Bartosz Stec ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
fxp performance with POLLING
Hello again :) With POLLING enabled I experience about 10%-25% performance drop when copying files over network. Tested with both SAMBA and NFS. Is it normal? FreeBSD 7.1-PRERELEASE #0: Sat Sep 6 01:52:12 CEST 2008 fxp0: port 0xc800-0xc83f mem 0xe1021000-0xe1021fff irq 20 at device 8.0 on pci1 # ifconfig fxp0 fxp0: flags=9843 metric 0 mtu 1500 options=8 ether 00:20:ed:42:87:13 inet 192.168.0.2 netmask 0xff00 broadcast 192.168.0.255 media: Ethernet autoselect (100baseTX ) status: active BTW overall SAMBA performance still sucks on 7.1-pre as much as on RELENG_5 ...:( - 7.5 MB/s peak. -- Bartosz Stec ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: system hangup - I'm lost
Oliver Lehmann wrote: Hi, My fileserver has sporadical hangups running 6.3: FreeBSD 6.3-STABLE #0: Thu Jun 19 00:21:00 CEST 2008 [EMAIL PROTECTED]:/usr/obj/i386-pentium3-6.3/usr/src/sys/NUDEL The exact release doesn't matter since it happened before. It always happens afer some time of having some load on the system (I'm building ports with tinderbox and during the build process it just hangs up). The system does nothing write out on the console, neither the CRT, nor the serial console. The system itself is: CPU: Intel Pentium III (845.64-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x683 Stepping = 3 Features=0x387fbff real memory = 805240832 (767 MB) avail memory = 778481664 (742 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 1 cpu1 (AP): APIC ID: 0 ioapic0 irqs 0-23 on motherboard while the diskspace is provided by an 3ware RAID: twa0: <3ware 9000 series Storage Controller> port 0x2400-0x24ff mem 0xf4101000-0xf41010ff,0xf480-0xf4ff irq 18 at device 11.0 on pci0 twa0: INFO: (0x04: 0x0053): Battery capacity test is overdue: twa0: INFO: (0x15: 0x1300): Controller details:: Model 9500S-4LP, 4 ports, Firmware FE9X 2.08.00.009, BIOS BE9X 2.03.01.052 da0 at twa0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-3 device da0: 100.000MB/s transfers da0: 715224MB (1464778752 512 byte sectors: 255H 63S/T 91178C) I had - in the past - sometimes messages left which where indicating, that the system was not able to allocate swap space fast enough if I recall it correctly (_not_ out of swap space!) but the RAID is kinda fast imho. Any idea what I could do to shed some more light on this behaviour? Why it is happening and what really is causing it? Would enabling the kernel debugger really help here? I mean the system is really hanging up - except ping response it is not responding to anything except the reset switch ;) Greetings, Oliver Personally I'd rather bet on some hardware problem (overheating?) Try to install mbmon from ports. I had also similiar problems with old motherboards with swelled capacitors. -- Bartosz Stec ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: vm.kmem_size settings doesn't affect loader?
Ben Kelly wrote: On Sep 26, 2008, at 4:43 AM, Bartosz Stec wrote: Jeremy Chadwick wrote: These are the tuning settings I use: vm.kmem_size="1536M" vm.kmem_size_max="1536M" vfs.zfs.arc_min="16M" vfs.zfs.arc_max="64M" Yesterday I've added 512 MB memory to box (sum 1,5GB), and set vm.kmem_size and vm.kmem_size to "1024M". With pieces of 1024MB, 512MB, 256MB, 256MB available and 3 memory slots it is hard to have 2GB RAM ;) Until now it survived world cleaning/building/installing/bonnie++ benchmarkink/fs scrubing and general usage. Memory usage seems stable. If unfortunately kmem exhaustion will happen again I will experiment with ARC settings. IMHO you've explained gently a lot of zfs tuning concerns in this thread and they should be added to tuning guide - espacially explanation of ARC and prefetch settings. Thanks again! Did you increase KVA_PAGES in your kernel config as well? The default of 256 only allows 1GB of kernel memory total. Setting KVA_PAGES to 384 would probably be good for a kmem_size of 1GB. This would give leave you with 512MB of space for other things in the kernel. In your kernel config: optionsKVA_PAGES=384 Sorry if you already knew this. I know its in the zfs tuning guide. I just hadn't seen it mentioned in the thread yet and wanted to make sure it wasn't missed. Hope that helps. - Ben Indeed I know that. options KVA_PAGES=512 is included in my kernel config. Until now: # uptime 10:12 up 3 days, 10:32, 1 user, load averages: 0,00 0,03 0,00 Thanks :) -- Bartosz Stec ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: vm.kmem_size settings doesn't affect loader?
Jeremy Chadwick wrote: On Thu, Sep 25, 2008 at 04:14:02PM +0200, Bartosz Stec wrote: Your options are: 1) Consider increasing it from 512M to something like 1.5GB; do not increase it past that on RELENG_7, as there isn't support for more than 2GB total. For example, on a 1GB memory machine, I often recommend 768M. On 2GB machines, 1536M. You will need to run -CURRENT if you want more. 2) Tune ZFS aggressively. Start by setting vfs.zfs.arc_min="16M" and vfs.zfs.arc_max="64M". If your machine has some small amount of memory (768MB, 1GB, etc.), then you probably shouldn't be using ZFS. Problem occured on i386 machine with 1GB of memory and 7.1-pre (3HDD, 40GB, RAIDZ1). I know that i386 is highly unrecommended for ZFS, but it's just a home box for testing and learning purposes - I just want to know what I'm doing and what should I expect when I decide to put ZFS on server machines :) Currently, from posts on freebsd-fs, I conclude that even with a gigs of kmem and using AMD64, we still can experience panic from kmem_malloc. The i386 vs. amd64 argument is bogus, if you ask me. ZFS works on both. amd64 is recommended because ZFS contains code that makes heavy use of 64-bit values, and because amd64 offers large amounts of addressed memory without disgusting hacks like PAE. That said -- yes, even with "gigs of kmem and using AMD64", you can still panic due to kmem exhaustion. I have fairly decent experience with this problem, because it haunted me for quite some time. A large portion of the problem is that kmem_max, on i386 and amd64 (yes, you read that right) has a 2GB limit on RELENG_7. I repeat: a 2GB limit, regardless of i386 or amd64. This limit has been increased to 512GB on CURRENT, but there are no plans to MFC those changes, as they are too major. Let me tell you something I did this weekend. I had to copy literally 200GB of data from a ZFS raidz1 pool (spread across 3 disks) to two different places: 1) a UFS2 filesystem on a different disk, and 2) across a gigE network to a Windows machine. I had to do this because I was adding a disk to the vdev, which cannot be done without re-creating the pool (this is a known problem with ZFS, and has nothing to do with FreeBSD). The machine hosting the data runs RELENG_7 with amd64, and contains 4GB of memory. However, I've accomplished the same task with only 2GB of memory as well. These are the tuning settings I use: vm.kmem_size="1536M" vm.kmem_size_max="1536M" vfs.zfs.arc_min="16M" vfs.zfs.arc_max="64M" The entire copying process took almost 2 hours. Not once did I experience kmem exhaustion. I can *guarantee* that I would have crashed the box numerous times had I not tuned the machine with the values above. Manual tuning is hard for me because I'm not familiar with BSD kernel code nor kernel memory management. I'm just an end-user who love concepts of ZFS and wait for it to be (more) stable. Of course I've followed tuning guide carefully. I'm an "experienced" end-user who has very little experience with BSD kernel code and absolutely no experience with kernel memory management. Proper tuning is all that's needed, regardless of your knowledge set. Please try installing 2GB of memory in your i386 box, and then use the exact loader.conf values I specified above. Thank you for hints. Yesterday I've added 512 MB memory to box (sum 1,5GB), and set vm.kmem_size and vm.kmem_size to "1024M". With pieces of 1024MB, 512MB, 256MB, 256MB available and 3 memory slots it is hard to have 2GB RAM ;) Until now it survived world cleaning/building/installing/bonnie++ benchmarkink/fs scrubing and general usage. Memory usage seems stable. If unfortunately kmem exhaustion will happen again I will experiment with ARC settings. IMHO you've explained gently a lot of zfs tuning concerns in this thread and they should be added to tuning guide - espacially explanation of ARC and prefetch settings. Thanks again! -- Bartosz Stec ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: vm.kmem_size settings doesn't affect loader?
Jeremy Chadwick pisze: On Thu, Sep 25, 2008 at 12:26:58PM +0200, Bartosz Stec wrote: Today I've experienced zfs-related kernel panic. Log says: savecore: reboot after panic: kmem_malloc(131072): kmem_map too small: 327684096 total allocated Reported amount of memory (327684096) is wrong, because i made suggested tuning in my loader.conf: vm.kmem_size="512M" vm.kmem_size_max="512M" Just to be sure: # sysctl vm | grep kmem vm.kmem_size: 536870912 vm.kmem_size_min: 0 vm.kmem_size_max: 536870912 vm.kmem_size_scale: 3 Am I missing something? I believe this is normal. The amount shown in "total allocated" will not match what you have vm.kmem_size or vm.kmem_size_max set to. Someone more familiar with the VM can explain why this is, but as I understand it, it's 100% normal. Thanks for explaining. This part of tuning guide confused me: "I was able to generate the following kernel panic in less than a minute by copying files from a linux server connected via gigabit crossover: Apr 8 06:46:08 nas savecore: reboot after panic: kmem_malloc(131072): kmem_map too small: 528273408 total allocated As you can see, this is *with* vm.kmem_size="512M"!" I've just expected similiar numbers in my case. Your options are: 1) Consider increasing it from 512M to something like 1.5GB; do not increase it past that on RELENG_7, as there isn't support for more than 2GB total. For example, on a 1GB memory machine, I often recommend 768M. On 2GB machines, 1536M. You will need to run -CURRENT if you want more. 2) Tune ZFS aggressively. Start by setting vfs.zfs.arc_min="16M" and vfs.zfs.arc_max="64M". If your machine has some small amount of memory (768MB, 1GB, etc.), then you probably shouldn't be using ZFS. Problem occured on i386 machine with 1GB of memory and 7.1-pre (3HDD, 40GB, RAIDZ1). I know that i386 is highly unrecommended for ZFS, but it's just a home box for testing and learning purposes - I just want to know what I'm doing and what should I expect when I decide to put ZFS on server machines :) Currently, from posts on freebsd-fs, I conclude that even with a gigs of kmem and using AMD64, we still can experience panic from kmem_malloc. Manual tuning is hard for me because I'm not familiar with BSD kernel code nor kernel memory management. I'm just an end-user who love concepts of ZFS and wait for it to be (more) stable. Of course I've followed tuning guide carefully. So, for now, I will add another 512MB of memory and increse vm.kmem_size and do more tests. Thanks once again for explaining and suggestions. Good luck with ZFS everyone! :) -- Bartosz Stec ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
vm.kmem_size settings doesn't affect loader?
Today I've experienced zfs-related kernel panic. Log says: savecore: reboot after panic: kmem_malloc(131072): kmem_map too small: 327684096 total allocated Reported amount of memory (327684096) is wrong, because i made suggested tuning in my loader.conf: vm.kmem_size="512M" vm.kmem_size_max="512M" Just to be sure: # sysctl vm | grep kmem vm.kmem_size: 536870912 vm.kmem_size_min: 0 vm.kmem_size_max: 536870912 vm.kmem_size_scale: 3 Am I missing something? -- Bartosz Stec ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Funny things with cflags and world/kernel building
As well as i know variables works this way:
# set foo=bar
# set | grep foo
_ set foo=bar
foo bar
# echo $foo
bar
# echo ${foo}
bar
So maybe someone could explain me why following things happens with
variables in make.conf?
My make.conf:
CPUTYPE=athlon64
MAKEOPTS=-j3
# USE CCACHE
.if !defined(NOCCACHE)
CC=/usr/local/libexec/ccache/world-cc
CXX=/usr/local/libexec/ccache/world-c++
.endif
# default build settings for ports collection
.if ${.CURDIR:M*/ports/*}
CFLAGS= -O2 -fno-strict-aliasing -pipe -funroll-loops
-fomit-frame-pointer
CXXFLAGS= -O2 -fno-strict-aliasing -pipe -funroll-loops
.endif
# default build settings for base system
.if ${.CURDIR:M*/usr/src/*} || ${.CURDIR:M*/usr/obj/*}
CFLAGS=-O2 -fno-strict-aliasing -pipe
#CXXFLAGS=-O2 -fno-strict-aliasing -pipe
COPTFLAGS=-O2 -fno-strict-aliasing -pipe
CXXFLAGS=${CFLAGS}
#COPTFLAGS=${CFLAGS}
.endif
# added by use.perl 2008-04-14 10:39:38
PERL_VER=5.8.8
PERL_VERSION=5.8.8
As you see I use ccache and different flags for world and port building,
but what's interesting:
1. when I use these flags:
CFLAGS=-O2 -fno-strict-aliasing -pipe
CXXFLAGS=${CFLAGS}
COPTFLAGS=${CFLAGS}
world building finish without problem, but making kernel give an error:
--
>>> stage 3.1: making dependencies
--
cd /usr/obj/usr/src/sys/AMD64SMP7; MAKEOBJDIRPREFIX=/usr/obj
MACHINE_ARCH=amd64 MACHINE=amd64 CPUTYPE=athlon64
GROFF_BIN_PATH=/usr/obj/usr/src/tmp/legacy/usr/bin
GROFF_FONT_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/groff_font
GROFF_TMAC_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/tmac
_SHLIBDIRPREFIX=/usr/obj/usr/src/tmp VERSION="FreeBSD
7.1-PRERELEASE amd64 700112" INSTALL="sh
/usr/src/tools/install.sh"
PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin
NO_CTF=1 make KERNEL=kernel depend -DNO_MODULES_OBJ
machine -> /usr/src/sys/amd64/include
Variable CFLAGS is recursive.
*** Error code 2
Stop in /usr/src.
*** Error code 1
Stop in /usr/src.
2. When I use these flags:
CFLAGS=-O2 -fno-strict-aliasing -pipe
CXXFLAGS=-O2 -fno-strict-aliasing -pipe
COPTFLAGS=-O2 -fno-strict-aliasing -pipe
kernel build finish without problem, but... building world give an error!:
===> gnu/lib/libstdc++ (depend)
ln -sf
/usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/config/cpu/generic/
atomicity_builtins/atomicity.h atomicity.cc
ln -sf
/usr/src/gnu/lib/libstdc++/../../../contrib/gcc/unwind-generic.h
unwind.h
rm -f .depend
(...)
/usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-cxx.h:41:
20: error: unwind.h: No such file or directory
In file included from
/usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libs
upc++/vec.cc:37:
/usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-cxx.h:41:
20: error: unwind.h: No such file or directory
mkdep: compile failed
*** Error code 1
Stop in /usr/src/gnu/lib/libstdc++.
*** Error code 1
Stop in /usr/src/gnu/lib.
*** Error code 1
3. What's even more funny? When I use flags:
CFLAGS=-O2 -fno-strict-aliasing -pipe
COPTFLAGS=-O2 -fno-strict-aliasing -pipe
CXXFLAGS=${CFLAGS}
I have no errors at all! But shouldn't all those flags be treated by
make command exactly the same way??
It isn't new issue - it's couple of months as I face this problem - on
AMD 64 machine with CPUTYPE=athlon64 and MAKEOPTS=-j3 and olso on i386
machine with CPUTYPE=pentium2 and MAKEOPTS=-j2. Other flags are the
same as in the beginning of this message. Another machine - exactly the
same flags but CPUTYPE=athlon-tbird and MAKEOPTS=-j2 and no problems
compiling world and kernel regardless of flags combination.
Could anyone explain to me sthis trange behaviour ?
p.s. Sorry for my poor english ;)
--
Bartosz Stec - specjalista ds. IT
AUXILIA Spółka z o.o.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: boot failed after make installkernel from 6.3-RELEASE to 7.0-RELEASE
Chih Liang pisze: Miroslav Lachman wrote: What is your hardware setup? (post dmesg) I have bad experience with some old PC with nForce 2 chipset. This machine is unbootable with 7.x kernel, so I am using it with 6.3. (it can't boot even from 7.x CD) Miroslav Lachman I've tried to boot with 7.0 CD, it hung again...then I reboot with ACPI disabled, it could be boot but said can't find the disk. So I think this PC maybe with too old chipset. Anyway, thanks a lot. Well, it's VIA chipset you have, not nForce2 - KT133x/KM133) host to PCI bridge>. And it's not too old to run 7.0 as far as I know. It's strange that kernel has some problem with your hardware. Maybe you have buggy BIOS? Try to update to newest one and/or at least load BIOS safe-defaults. Then you should try to boot with and without ACPI enabled. Adding the following line to /boot/device.hints: hint.acpi.0.disabled="1" may help if your system won't boot with ACPI enabled. Don't give up yet! :) -- Bartosz Stec - specjalista ds. IT AUXILIA Spółka z o.o. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: boot failed after make installkernel from 6.3-RELEASE to 7.0-RELEASE
Chih Liang pisze: Dear all, I've tried to upgrade my FreeBSD server from 6.3-RELEASE to 7.0-RELEASE, but it is failed to boot after make kernel KERNCONF=GENERIC. I didn't modify any file at /usr/src/sys/i386/conf, it was all default. After done make kernel and reboot, system stop at: Timecounters tick every 1.000 msec ad0: 38166MB at ata0-master UDMA100 I can't boot in single mode, but I can boot in safe mode, and it showed: Manual root filesystem specification: : Mount using filesystem eg. ufs:da0s1a ? List valid disk boot devices Abort manual input I type "?" for list, but it only show acd0 and fdc0, "ufs:ad0s1a" or "ufs:/dev/ad0s1a" are not working I can boot with /boot/kernel.old now (6.3-RELEASE), I rebuilt kernel again and again, but still not work. I check the difference between old GENERIC on 6.3-RELEASE and new GENERIC on 7.0-RELEASE, it has not difference besides new add in 7.0-RELEASE. Is any one can help me? I don't want to reinstall...because I don't have install cd... And sorry for my poor English, thank you for reading! Regards, Chih Liang ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]" Did you make buildworld before buildkernel? If not, boot kernel.old ane follow these rules: 1. csup 7-stable sources (just to be sure) 2. rm -fR /usr/obj (just to be sure again) 3. make buildworld && make buildkernel KERNCONF=GENERIC 4. make installkernel 5. reboot in single user mode 6. mergemaster -p 7. make installworld 8. mergemaster 9. make delete-old 10. make delete-old-libs Good luck! -- Bartosz Stec - specjalista ds. IT AUXILIA Spółka z o.o. ul. Wałbrzyska 43/2 52-314 Wrocław tel. (71) 79 99 760 w. 69 GSM: 662171775 E-Mail: [EMAIL PROTECTED] -- E-Mail Disclaimer Niniejsza wiadomosc oraz wszystkie zalaczone do niej pliki przeznaczone sa do wylacznego uzytku adresata i moga zawierac chronione lub poufne informacje. Przegladanie, wykorzystywanie, ujawnianie lub dystrybuowanie przez osoby do tego nieupowaznione jest zabronione. Jesli nie jest Pani/Pan wymienionym adresatem niniejszej wiadomosci, prosimy o niezwloczny kontakt z nadawca i usuniecie oryginalnej wiadomosci wraz ze zniszczeniem wszystkich jej kopii. Der Inhalt dieser E-Mail ist vertraulich und ausschließlich für den bezeichneten Adressaten bestimmt. Wenn Sie nicht der vorgesehene Adressat dieser E-Mail oder dessen Vertreter sein sollten, so beachten Sie bitte, daß jede Form der Kenntnisnahme, Veröffentlichung, Vervielfältigung oder Weitergabe des Inhalts dieser E-Mail unzulässig ist. Wir bitten Sie, sich in diesem Fall mit dem Absender der E-Mail in Verbindung zu setzen. This e-mail message including any attachments is for the sole use of the intended recipient(s) and may contain privileged or confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please immediately contact the sender by reply e-mail and delete the original message and destroy all copies thereof. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
bugged sysinstall, bsdlabel, zfs, gmirror - recept for disaster :)
ad2s1d ONLINE 0 0 0 ad3s1d ONLINE 0 0 0 errors: No known data errors # gmirror status NameStatus Components mirror/boot COMPLETE ad0s1a ad2s1a ad3s1a Good luck with ZFS everyone! :) And RTFM ;) -- Bartosz Stec - specjalista ds. IT AUXILIA Spółka z o.o. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Stable SATA pci card for FreeBSD 6.x/7.0
Jeremy Chadwick pisze: On Thu, Aug 21, 2008 at 09:49:25AM +0200, Sebastiaan van Erk wrote: I was thinking of buying the Promise SATA300 TX4 PCI Controller. I've searched on google, and I do see some negative posts on them in combination with FreeBSD, however they all date back at least 2 years... Does anybody have positive/negative experiences using this card? I have one of these cards (not currently in use; less stuff inside my FreeBSD box at home the better), and never ran into any oddities. That was with 4 disks connected, each disk its own UFS2 filesystem. ZFS wasn't available back then. Hello there. I have one SATA300 TX4 PCI Controller in use from about 2 years in my SMB serwer running celeron 1Ghz and 2 x WDC WD2500YS-01SHB0 (250GB each). Disks are under controll of gmirror with UFS2 fs.. When stable branch was 6.x I had problems similiar to described here: http://lists.freebsd.org/pipermail/freebsd-bugs/2007-October/026137.html. In practice - at heavy load, after some timeouts, one of disk drives disconnects and controller doesn't recognize any disks at this sata channel untl reboot. Howewer, no problems occured since I've upgraded Freebsd to 7.x. -- Bartosz Stec - specjalista ds. IT AUXILIA Spółka z o.o. ul. Wałbrzyska 43/2 52-314 Wrocław tel. (71) 79 99 760 w. 69 GSM: 662171775 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
