Re: Degraded zpool cannot detach old/bad drive

[Stefan Bethke]

Am 29.10.2010 um 07:51 schrieb Rumen Telbizov:

 Thanks for your quick response. Unfortunately I already did try this
 approach. Applying -d /dev/gpt only limits the pool to the bare three 
 remaining disks
 which turns pool completely unusable (no mfid devices). Maybe those labels 
 are removed
 shortly they are being tried to be imported/accessed?
 
 What I don't understand is what exactly makes those gpt labels disappear
 when the pool is imported and otherwise are just fine?!
 Something to do with OpenSolaris ? On top of it all gpart show -l keeps
 showing all the labels right even while the pool is imported.
 
 Any other clues would be appreciated.

The labels are removed by glabel as soon as something opens the underlying 
provider, i. e. the disk device, for writing.  Since that process could change 
the part of the disk that the label information is extracted from, the label is 
removed.  glabel will re-taste the provider once the process closes it again.

Since you're using gpt labels, I would expect them to continue to be available, 
unless zpool import somehow opens the disk devices (instead of the partition 
devices).


Stefan

-- 
Stefan Bethke s...@lassitu.de   Fon +49 151 14070811



___
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: Degraded zpool cannot detach old/bad drive

[Artem Belevich]

On Thu, Oct 28, 2010 at 10:51 PM, Rumen Telbizov telbi...@gmail.com wrote:
 Hi Artem, everyone,

 Thanks for your quick response. Unfortunately I already did try this
 approach.
 Applying -d /dev/gpt only limits the pool to the bare three remaining disks
 which turns
 pool completely unusable (no mfid devices). Maybe those labels are removed
 shortly
 they are being tried to be imported/accessed?

In one of the previous emails you've clearly listed many devices in
/dev/gpt and said that they've disappeared after pool import.
Did you do zpool import -d /dev/gpt while /dev/gpt entries were present?

 What I don't understand is what exactly makes those gpt labels disappear
 when the pool is imported and otherwise are just fine?!

This is the way GEOM works. If something (ZFS in this case) uses raw
device, derived GEOM entities disappear.

Try exporting the pool. Your /dev/gpt entries should be back. Now try
to import with -d option and see if it works.

You may try bringing the labels back the hard way by detaching raw
drive and then re-attaching it via the label, but resilvering one
drive at a time will take a while.

--Artem
___
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

Intel PRO/Wireless 6050 in 8.1-RELEASE Problems

[me]

I've installed FreeBSD 8.1-RELEASE on a Dell Latitude E6410. Most hardware
works just fine, but I'm having a hell of a time with the wifi. Everytime I
try to associate with an access point, my terminal replies with:

jarvis# wpa_supplicant -i iwn0 -c /etc/wpa_supplicant.conf
ioctl[SIOCG80211, op 98, len 32]: Invalid argument
Failed to initialize driver interface
ELOOP: remaining socket: sock=4 eloop_data=0x28406140   
user_data=0x2840d040 handler=0x8069f70

A check to /var/log/messages shows:
Oct 29 03:29:44 jarvis wpa_supplicant[896]: Failed to initiate AP scan.
Oct 29 03:29:45 jarvis wpa_supplicant[751]: Failed to initiate AP scan.
Oct 29 03:29:54 jarvis wpa_supplicant[896]: Failed to initiate AP scan.
Oct 29 03:29:55 jarvis wpa_supplicant[751]: Failed to initiate AP scan.
Oct 29 03:30:00 jarvis wpa_supplicant[751]: Failed to disable WPA in the
driver.
Oct 29 03:30:00 jarvis wpa_supplicant[896]: Failed to disable WPA in the
driver.
Oct 29 03:30:01 jarvis kernel: iwn_fatal_intr: bad firmware error log
address 0x
Oct 29 03:30:02 jarvis kernel: iwn0: iwn_hw_init: timeout waiting for
adapter to initialize, error 35
Oct 29 03:30:02 jarvis kernel: iwn0: iwn_init_locked: could not initialize
hardware, error 35

I know that my device is being detected, because I see:

jarvis# dmesg | grep 'Wireless'
iwn0: Intel(R) PRO/Wireless 6050 mem 0xe6e0-0xe6e01fff irq 17 at
device 0.0 on pci3

When looking at my interfaces, I see:

jarvis# ifconfig wlan0 
wlan0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu
1500
ether 00:23:15:46:b6:c8
media: IEEE 802.11 Wireless Ethernet autoselect (autoselect)
status: no carrier
ssid  channel 1 (2412 MHz 11b)
country US authmode WPA1+WPA2/802.11i privacy ON deftxkey UNDEF
txpower 0 bmiss 10 scanvalid 450 bgscan bgscanintvl 300 bgscanidle 250
roam:rssi 7 roam:rate 1 wme roaming MANUAL bintval 0
jarvis# ifconfig iwn0
iwn0: flags=8802BROADCAST,SIMPLEX,MULTICAST metric 0 mtu 2290
ether 00:23:15:46:b6:c8
media: IEEE 802.11 Wireless Ethernet autoselect mode 11b
status: associated

My wpa_supplicant works on other boxes without problem. Additional useful
file contents:

jarvis# cat /etc/rc.conf 

# -- sysinstall generated deltas -- # Sun Oct 24 18:04:25 2010
# Created: Sun Oct 24 18:04:25 2010
# Enable network daemons for user convenience.
# Please make all changes to this file, not to /etc/defaults/rc.conf.
# This file now contains just the overrides from /etc/defaults/rc.conf.
hostname=jarvis.localdomain
ifconfig_em0=DHCP
moused_enable=YES
sshd_enable=YES
linux_enable=YES
nvidia_enable=YES
wlans_iwn0=wlan0
ifconfig_wlan0=WPA DHCP
vboxnet_enable=YES
vboxguest_enable=YES
slim_enable=YES


jarvis# cat /boot/loader.conf 
# VBox configs
vboxdrv_load=YES

# Wireless Lan configs
if_ipw_load=YES
if_iwi_load=YES
if_wpi_load=YES
iwn6050fw_load=YES
iwnfw_load=YES
if_iwn_load=YES
legal.intel_ipw.license_ack=1
legal.intel_iwi.license_ack=1
legal.intel_wpi.license_ack=1
legal.intel_iwn.license_ack=1
wlan_wep_load=YES
wlan_ccmp_load=YES
wlan_tkip_load=YES

# Nvidia support? SURE!
nvidia_load=YES

When looking at dmesg, I see:

jarvis# dmesg | grep wlan0
wlan0: Ethernet address: 00:23:15:46:b6:c8
jarvis# dmesg | grep iwn0
iwn0: Intel(R) PRO/Wireless 6050 mem 0xe6e0-0xe6e01fff irq 17 at
device 0.0 on pci3
iwn0: MIMO 2T2R, MoW, address 00:23:15:46:b6:c8
iwn0: [ITHREAD]
iwn0: 11a rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps
iwn0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps
iwn0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps
24Mbps 36Mbps 48Mbps 54Mbps
iwn0: iwn_hw_init: timeout waiting for adapter to initialize, error 35
iwn0: iwn_init_locked: could not initialize hardware, error 35
iwn0: iwn_hw_init: timeout waiting for adapter to initialize, error 35
iwn0: iwn_init_locked: could not initialize hardware, error 35

I know that that error has to be part of the problem. I just don't know
what to do next, and haven't been able to find any help further. Any ideas?
Additionally, any thing I forgot to add, please let me know.
___
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: Intel PRO/Wireless 6050 in 8.1-RELEASE Problems

[Bruce Cran]

On Fri, 29 Oct 2010 02:32:52 -0600
m...@kmwhite.net wrote:

 I've installed FreeBSD 8.1-RELEASE on a Dell Latitude E6410. Most
 hardware works just fine, but I'm having a hell of a time with the
 wifi. Everytime I try to associate with an access point, my terminal
 replies with:
 
 jarvis# wpa_supplicant -i iwn0 -c /etc/wpa_supplicant.conf
 ioctl[SIOCG80211, op 98, len 32]: Invalid argument
 Failed to initialize driver interface
 ELOOP: remaining socket: sock=4 eloop_data=0x28406140   
 user_data=0x2840d040 handler=0x8069f70

I'm sure it's not the cause of the problem, but shouldn't you be
running wpa_supplicant on the wlan0 interface, not the underlying iwn0?

-- 
Bruce Cran
___
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: Intel PRO/Wireless 6050 in 8.1-RELEASE Problems

[me]

On Fri, 29 Oct 2010 10:04:14 +0100, Bruce Cran br...@cran.org.uk wrote:
 On Fri, 29 Oct 2010 02:32:52 -0600
 m...@kmwhite.net wrote:
 
 I've installed FreeBSD 8.1-RELEASE on a Dell Latitude E6410. Most
 hardware works just fine, but I'm having a hell of a time with the
 wifi. Everytime I try to associate with an access point, my terminal
 replies with:
 
 jarvis# wpa_supplicant -i iwn0 -c /etc/wpa_supplicant.conf
 ioctl[SIOCG80211, op 98, len 32]: Invalid argument
 Failed to initialize driver interface
 ELOOP: remaining socket: sock=4 eloop_data=0x28406140   
 user_data=0x2840d040 handler=0x8069f70
 
 I'm sure it's not the cause of the problem, but shouldn't you be
 running wpa_supplicant on the wlan0 interface, not the underlying iwn0?

You're correct. That was me copying/pasting the wrong command run, sorry:

jarvis# wpa_supplicant -i wlan0 -c /etc/wpa_supplicant.conf
ioctl[SIOCS80211, op 103, len 128]: Device not configured
Failed to initiate AP scan.
ioctl[SIOCS80211, op 103, len 128]: Device not configured
Failed to initiate AP scan.
ioctl[SIOCS80211, op 103, len 128]: Device not configured
Failed to initiate AP scan.
^CCTRL-EVENT-TERMINATING - signal 2 received
ioctl[SIOCS80211, op 26, arg 0x0]: Operation not supported
Failed to disable WPA in the driver.
ELOOP: remaining socket: sock=4 eloop_data=0x28406140 user_data=0x2840d040
handler=0x8069f70
jarvis# 


___
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 write speed

[S . N . Grigoriev]

29.10.10, 07:14, jhell jh...@dataix.net:

 On 10/28/2010 03:30, S.N.Grigoriev wrote:
   
   
   28.10.10, 01:54, Stefan Bethke :
   
   Am 27.10.2010 um 22:51 schrieb S.N.Grigoriev:

 Hi list,
 
 I've got very low write speed using ZFS on a SATA disk.
 My HDD configuration is:
 ad4: 70911MB  at ata2-master UDMA100 SATA 3Gb/s
 ad6: 78532MB  at ata3-master UDMA100 SATA 1.5Gb/s
 ad8: 1430799MB  at ata4-master UDMA100 SATA 3Gb/s

The EARS has 4k sectors, if I'm not mistaken.  I don't recall the 
 eventual
outcome, but there was a long thread on stable or hackers on how to 
 ensure
proper alignment and (minimun) 4k-sized writes to make sure the disk 
 doesn't
have to do a read-modify-write cycle, so try and search the archives.
  
  Though this might play a small part in your write performance with the
  EARS drives, this issue has more to do with the stat() calls and the ACL
  involvement with ZFS. This was sort of solved in 8.1-STABLE and from 3
  cases that I know about and 1 being my own... write/read speeds have
  doubled from what can be seen to an effect of 8.1-RELEASE.
  
  You may want to either upgrade to stable/8 or use one of the snapshots
  from here:
  
  ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/201010/
  

thank you. I'll be experimenting with STABLE next week.  

-- 
Regards,
S.Grigoriev.
___
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: 8.1-STABLE: zfs and sendfile: problem still exists

[Artemiev Igor]

On Thu, Oct 28, 2010 at 09:57:22AM +0400, Alexander Zagrebin wrote:
 Hi!
 
 I've noticed that ZFS on 8.1-STABLE still has problems with sendfile.
 When accessing a file at first time the transfer speed is too low, but
 on following attempts the transfer speed is normal.
...
 I've tried ftpd and nginx with sendfile on. The behavior is the same.
 After disabling using sendfile in nginx (sendfile off) the problem has
 gone.

Yep, this problem exists. You may workaround it via bumping up
net.inet.tcp.sendspace up to 128k.  zfs sendfile is very ineffective. I have
made a small investigation via DTrace, it reads MAXBSIZE chunks, but map in vm
only one page (4K).  I.e. if you have a file with size 512K, sendfile make
calls freebsd_zfs_read 128 times.
___
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: Intel PRO/Wireless 6050 in 8.1-RELEASE Problems

[Bernhard Schmidt]

On Friday, October 29, 2010 10:32:52 m...@kmwhite.net wrote:
 I've installed FreeBSD 8.1-RELEASE on a Dell Latitude E6410. Most hardware
 works just fine, but I'm having a hell of a time with the wifi. Everytime I
 try to associate with an access point, my terminal replies with:
 
 [..]
 iwn6050fw_load=YES
 [..]
 iwn0: Intel(R) PRO/Wireless 6050 mem 0xe6e0-0xe6e01fff irq 17 at
 [..]
 iwn0: iwn_hw_init: timeout waiting for adapter to initialize, error 35
 iwn0: iwn_init_locked: could not initialize hardware, error 35
 iwn0: iwn_hw_init: timeout waiting for adapter to initialize, error 35
 iwn0: iwn_init_locked: could not initialize hardware, error 35
 
 I know that that error has to be part of the problem. I just don't know
 what to do next, and haven't been able to find any help further. Any ideas?
 Additionally, any thing I forgot to add, please let me know.

The messages indicate that you are using 8.1-RELEASE, but afaik 8.1 does not 
have the 6050 firmware module, did you get that from stable?

If you're able to try stable/8, please do so, there have been a few 
additions/fixes regarding 6000 series chips which are not in 8.1-RELEASE.

-- 
Bernhard
___
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: beastiality

[Hugo Silva]

Randy Bush wrote:

This is often caused by a combination of two things being enabled
simultaneously: BIOS-level serial console redirection after POST, and
FreeBSD's serial console support.


bingo!

thanks

randy
___
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



Must admit I hesitated before opening this email..
___
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: 8.1-STABLE: zfs and sendfile: problem still exists

[Andriy Gapon]

on 28/10/2010 08:57 Alexander Zagrebin said the following:
 Hi!
 
 I've noticed that ZFS on 8.1-STABLE still has problems with sendfile.

Which svn revision, just in case?

 When accessing a file at first time the transfer speed is too low, but
 on following attempts the transfer speed is normal.
 
 How to repeat:
 
 $ dd if=/dev/random of=/tmp/test bs=1m count=100
 100+0 records in
 100+0 records out
 104857600 bytes transferred in 5.933945 secs (17670807 bytes/sec)
 $ sudo env LC_ALL=C /usr/libexec/ftpd -D
 
 The first attempt to fetch file:
 
 $ fetch -o /dev/null ftp://localhost/tmp/test
 /dev/null   1% of  100 MB  118 kBps
 14m07s^C
 fetch: transfer interrupted
 
 The transfer rate is too low (approx. 120 kBps), but any subsequent attempts
 are success:
 
 $ fetch -o /dev/null ftp://localhost/tmp/test
 /dev/null 100% of  100 MB   42 MBps
 $ fetch -o /dev/null ftp://localhost/tmp/test
 /dev/null 100% of  100 MB   47 MBps

Can you do an experiment with the same structure but sendfile excluded?

-- 
Andriy Gapon
___
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: 8.1-STABLE: zfs and sendfile: problem still exists

[Andriy Gapon]

on 29/10/2010 12:04 Artemiev Igor said the following:
 Yep, this problem exists. You may workaround it via bumping up
 net.inet.tcp.sendspace up to 128k.  zfs sendfile is very ineffective. I have
 made a small investigation via DTrace, it reads MAXBSIZE chunks, but map in vm
 only one page (4K).  I.e. if you have a file with size 512K, sendfile make
 calls freebsd_zfs_read 128 times.

What svn revision of FreeBSD source tree did you test?

-- 
Andriy Gapon
___
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: 8.1-STABLE: zfs and sendfile: problem still exists

[Alexander Zagrebin]

  I've noticed that ZFS on 8.1-STABLE still has problems with 
 sendfile.
 
 Which svn revision, just in case?

8.1-STABLE
The source tree was updated 2010-10-27

  When accessing a file at first time the transfer speed is 
 too low, but
  on following attempts the transfer speed is normal.
  
  How to repeat:
  
  $ dd if=/dev/random of=/tmp/test bs=1m count=100
  100+0 records in
  100+0 records out
  104857600 bytes transferred in 5.933945 secs (17670807 bytes/sec)
  $ sudo env LC_ALL=C /usr/libexec/ftpd -D
  
  The first attempt to fetch file:
  
  $ fetch -o /dev/null ftp://localhost/tmp/test
  /dev/null   1% of  100 
 MB  118 kBps
  14m07s^C
  fetch: transfer interrupted
  
  The transfer rate is too low (approx. 120 kBps), but any 
 subsequent attempts
  are success:
  
  $ fetch -o /dev/null ftp://localhost/tmp/test
  /dev/null 100% of  100 
 MB   42 MBps
  $ fetch -o /dev/null ftp://localhost/tmp/test
  /dev/null 100% of  100 
 MB   47 MBps
 
 Can you do an experiment with the same structure but sendfile 
 excluded?

IMHO, ftpd hasn't an option to disable sendfile. I've tried the nginx with
disabled sendfile (the nginx.conf contains sendfile off;):

$ dd if=/dev/random of=test bs=1m count=100
100+0 records in
100+0 records out
104857600 bytes transferred in 5.892504 secs (17795083 bytes/sec)
$ fetch -o /dev/null http://localhost/test
/dev/null 100% of  100 MB   41 MBps
$ fetch -o /dev/null http://localhost/test
/dev/null 100% of  100 MB   44 MBps
$ fetch -o /dev/null http://localhost/test
/dev/null 100% of  100 MB   44 MBps

-- 
Alexander Zagrebin

___
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: 8.1-STABLE: zfs and sendfile: problem still exists

[Andriy Gapon]

on 29/10/2010 16:14 Alexander Zagrebin said the following:
 I've noticed that ZFS on 8.1-STABLE still has problems with 
 sendfile.

 Which svn revision, just in case?
 
 8.1-STABLE
 The source tree was updated 2010-10-27

OK, good.

 When accessing a file at first time the transfer speed is 
 too low, but
 on following attempts the transfer speed is normal.

 How to repeat:

 $ dd if=/dev/random of=/tmp/test bs=1m count=100
 100+0 records in
 100+0 records out
 104857600 bytes transferred in 5.933945 secs (17670807 bytes/sec)
 $ sudo env LC_ALL=C /usr/libexec/ftpd -D

 The first attempt to fetch file:

 $ fetch -o /dev/null ftp://localhost/tmp/test
 /dev/null   1% of  100 
 MB  118 kBps
 14m07s^C
 fetch: transfer interrupted

 The transfer rate is too low (approx. 120 kBps), but any 
 subsequent attempts
 are success:

 $ fetch -o /dev/null ftp://localhost/tmp/test
 /dev/null 100% of  100 
 MB   42 MBps
 $ fetch -o /dev/null ftp://localhost/tmp/test
 /dev/null 100% of  100 
 MB   47 MBps

 Can you do an experiment with the same structure but sendfile 
 excluded?
 
 IMHO, ftpd hasn't an option to disable sendfile.

Seems so.
The source could be hacked (unconditional goto oldway in libexec/ftpd/ftpd.c, 
but
anyway.

 I've tried the nginx with
 disabled sendfile (the nginx.conf contains sendfile off;):
 
 $ dd if=/dev/random of=test bs=1m count=100
 100+0 records in
 100+0 records out
 104857600 bytes transferred in 5.892504 secs (17795083 bytes/sec)
 $ fetch -o /dev/null http://localhost/test
 /dev/null 100% of  100 MB   41 MBps
 $ fetch -o /dev/null http://localhost/test
 /dev/null 100% of  100 MB   44 MBps
 $ fetch -o /dev/null http://localhost/test
 /dev/null 100% of  100 MB   44 MBps
 

I am really surprised with such a bad performance of sendfile.
Will you be able to profile the issue further?
I will also try to think of some measurements.

-- 
Andriy Gapon
___
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: beastiality

[Jeremy Chadwick]

On Sat, Oct 30, 2010 at 12:31:49AM +1100, Ian Smith wrote:
 On Fri, 29 Oct 2010, Hugo Silva wrote:
   Randy Bush wrote:
 This is often caused by a combination of two things being enabled
 simultaneously: BIOS-level serial console redirection after POST, and
 FreeBSD's serial console support.

bingo!

thanks

randy
 
   Must admit I hesitated before opening this email..
 
 Ah, this one was pretty tame .. randy's original post was very explicit 
 though; Jeremy's a real gentleman for not requoting that sort of filth!

Randy's just strange sometimes.  Hey Randy, TLG called, they want
AS2914 back.  ;-)

-- 
| Jeremy Chadwick   j...@parodius.com |
| Parodius Networking   http://www.parodius.com/ |
| UNIX Systems Administrator  Mountain View, CA, USA |
| Making life hard for others since 1977.  PGP: 4BD6C0CB |

___
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: cdrtools /devel and wodim broken

[Joerg Schilling]

Ready to start test for failing command? Enter CR to continue:
** Testing for failed SCSI command.
scgcheck: Input/output error. inquiry: scsi sendcmd: retryable error
CDB:  12 00 00 FF 24 00
status: 0x0 (GOOD STATUS)
cmd finished after 0.013s timeout 40s
-- SCSI Transport return != SCG_NO_ERROR (1)
-- SCSI status byte set to 0 (0x0)
-- SCSI failed command test FAILED 


You seem to have a general problem with correct error reporting in SCSI with 
your kernel SCSI transport. Please try to contact the maintainer of this driver.


Jörg

-- 
 EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
   j...@cs.tu-berlin.de(uni)  
   joerg.schill...@fokus.fraunhofer.de (work) Blog: 
http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
___
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: beastiality

[Ian Smith]

On Fri, 29 Oct 2010, Hugo Silva wrote:
  Randy Bush wrote:
This is often caused by a combination of two things being enabled
simultaneously: BIOS-level serial console redirection after POST, and
FreeBSD's serial console support.
   
   bingo!
   
   thanks
   
   randy

  Must admit I hesitated before opening this email..

Ah, this one was pretty tame .. randy's original post was very explicit 
though; Jeremy's a real gentleman for not requoting that sort of filth!
___
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: cdrtools /devel and wodim broken

[Jakub Lach]

Joerg Schilling-3 wrote:
 
 You seem to have a general problem with correct error reporting in SCSI
 with 
 your kernel SCSI transport. Please try to contact the maintainer of this
 driver.
 

Thanks for support, I have pinged him already.

ragards, 
- Jakub Lach
 

-- 
View this message in context: 
http://old.nabble.com/cdrtools--devel-and-wodim-broken-tp29978939p30086322.html
Sent from the freebsd-stable mailing list archive at Nabble.com.

___
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: 8.1-STABLE: zfs and sendfile: problem still exists

[Alexander Zagrebin]

  I've tried the nginx with
  disabled sendfile (the nginx.conf contains sendfile off;):
  
  $ dd if=/dev/random of=test bs=1m count=100
  100+0 records in
  100+0 records out
  104857600 bytes transferred in 5.892504 secs (17795083 bytes/sec)
  $ fetch -o /dev/null http://localhost/test
  /dev/null 100% of  100 
 MB   41 MBps
  $ fetch -o /dev/null http://localhost/test
  /dev/null 100% of  100 
 MB   44 MBps
  $ fetch -o /dev/null http://localhost/test
  /dev/null 100% of  100 
 MB   44 MBps
  
 
 I am really surprised with such a bad performance of sendfile.
 Will you be able to profile the issue further?

Yes.

 I will also try to think of some measurements.

A transfer rate is too low for the _first_ attempt only.
Further attempts demonstrates a reasonable transfer rate.
For example, nginx with sendfile on;:

$ dd if=/dev/random of=test bs=1m count=100
100+0 records in
100+0 records out
104857600 bytes transferred in 5.855305 secs (17908136 bytes/sec)
$ fetch -o /dev/null http://localhost/test
/dev/null   3% of  100 MB  118 kBps
13m50s^C
fetch: transfer interrupted
$ fetch -o /dev/null http://localhost/test
/dev/null 100% of  100 MB   39 MBps

If there was no access to the file during some time, then everything
repeats:
The first attempt - transfer rate is too low
A further attempts - no problems

Can you reproduce the problem on your system?

-- 
Alexander Zagrebin

___
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: 8.1-STABLE: zfs and sendfile: problem still exists

[Andriy Gapon]

on 29/10/2010 15:36 Andriy Gapon said the following:
 on 29/10/2010 12:04 Artemiev Igor said the following:
 Yep, this problem exists. You may workaround it via bumping up
 net.inet.tcp.sendspace up to 128k.  zfs sendfile is very ineffective. I have
 made a small investigation via DTrace, it reads MAXBSIZE chunks, but map in 
 vm
 only one page (4K).  I.e. if you have a file with size 512K, sendfile make
 calls freebsd_zfs_read 128 times.
 
 What svn revision of FreeBSD source tree did you test?
 

Ah, I think I see what's going on.
Either sendfile should (have an option to) use VOP_GETPAGES to request data or 
ZFS
mappedread should use vm_grab_page instead of vm_lookup_page for UIO_NOCOPY 
case.
Currently ZFS would read a whole FS block into ARC, but populate only one page
with data and for the rest it would just wastefully do uiomove(UIO_NOCOPY) from
ARC data.
So, e.g. zpool iostat would show that there are only few actual reads from a 
pool.
 The rest of the time must be spent churning over the data already in ARC and
doing page-per-VOP_READ copies from it.

-- 
Andriy Gapon
___
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: 8.1-STABLE: zfs and sendfile: problem still exists

[Jeremy Chadwick]

On Fri, Oct 29, 2010 at 06:31:21PM +0400, Alexander Zagrebin wrote:
   I've tried the nginx with
   disabled sendfile (the nginx.conf contains sendfile off;):
   
   $ dd if=/dev/random of=test bs=1m count=100
   100+0 records in
   100+0 records out
   104857600 bytes transferred in 5.892504 secs (17795083 bytes/sec)
   $ fetch -o /dev/null http://localhost/test
   /dev/null 100% of  100 
  MB   41 MBps
   $ fetch -o /dev/null http://localhost/test
   /dev/null 100% of  100 
  MB   44 MBps
   $ fetch -o /dev/null http://localhost/test
   /dev/null 100% of  100 
  MB   44 MBps
   
  
  I am really surprised with such a bad performance of sendfile.
  Will you be able to profile the issue further?
 
 Yes.
 
  I will also try to think of some measurements.
 
 A transfer rate is too low for the _first_ attempt only.
 Further attempts demonstrates a reasonable transfer rate.
 For example, nginx with sendfile on;:
 
 $ dd if=/dev/random of=test bs=1m count=100
 100+0 records in
 100+0 records out
 104857600 bytes transferred in 5.855305 secs (17908136 bytes/sec)
 $ fetch -o /dev/null http://localhost/test
 /dev/null   3% of  100 MB  118 kBps
 13m50s^C
 fetch: transfer interrupted
 $ fetch -o /dev/null http://localhost/test
 /dev/null 100% of  100 MB   39 MBps
 
 If there was no access to the file during some time, then everything
 repeats:
 The first attempt - transfer rate is too low
 A further attempts - no problems
 
 Can you reproduce the problem on your system?

I can't reproduce it on mine.  Note the resilvering was induced from
some unrelated disk swaps/tests I was performing, and ftpd is already
enabled via inetd on this system.

icarus# uname -a
FreeBSD icarus.home.lan 8.1-STABLE FreeBSD 8.1-STABLE #0: Sat Oct 16 07:10:54 
PDT 2010 r...@icarus.home.lan:/usr/obj/usr/src/sys/X7SBA_RELENG_8_amd64  
amd64
icarus# df -k
Filesystem   1024-blocks  Used Avail Capacity  Mounted on
/dev/ada0s1a 101297445180848013048%/
devfs  1 1 0   100%/dev
/dev/ada0s1d12186190103986  11107310 1%/var
/dev/ada0s1e 4058062  5468   3727950 0%/tmp
/dev/ada0s1f 8395622   1918300   580567425%/usr
data/cvs   686338517   289 686338228 0%/cvs
data/home  687130693792465 686338228 0%/home
data/storage   957080511 270742283 68633822828%/storage
icarus# zpool status
  pool: data
 state: ONLINE
 scrub: resilver completed after 0h43m with 0 errors on Sun Oct 17 10:11:19 2010
config:

NAMESTATE READ WRITE CKSUM
dataONLINE   0 0 0
  mirrorONLINE   0 0 0
ada1ONLINE   0 0 0
ada2ONLINE   0 0 0  258G resilvered

errors: No known data errors

icarus# pw useradd ftp -g users -u 2000 -s /bin/csh
icarus# mkdir /home/ftp
icarus# chown ftp:users /home/ftp
icarus# cd /home/ftp
icarus# dd if=/dev/urandom of=test bs=1m count=100
100+0 records in
100+0 records out
104857600 bytes transferred in 1.384421 secs (75741116 bytes/sec)
icarus# chown ftp:users test
icarus# ls -l test
-rw-r--r--  1 ftp  users  104857600 Oct 29 07:41 test
icarus# date ; fetch -o /dev/null ftp://localhost/test
Fri Oct 29 07:45:47 PDT 2010
/dev/null 100% of  100 MB  174 MBps
icarus# date ; fetch -o /dev/null ftp://localhost/test
Fri Oct 29 07:45:48 PDT 2010
/dev/null 100% of  100 MB  156 MBps
icarus# date ; fetch -o /dev/null ftp://localhost/test
Fri Oct 29 07:45:49 PDT 2010
/dev/null 100% of  100 MB  170 MBps
icarus# date ; fetch -o /dev/null ftp://localhost/test
Fri Oct 29 07:45:50 PDT 2010
/dev/null 100% of  100 MB  155 MBps
icarus# date ; fetch -o /dev/null ftp://localhost/test
Fri Oct 29 07:45:52 PDT 2010
/dev/null 100% of  100 MB  151 MBps

icarus# dd if=/dev/urandom of=test2 bs=1m count=500
500+0 records in
500+0 records out
524288000 bytes transferred in 6.947780 secs (75461228 bytes/sec)
icarus# chown ftp:users test2
icarus# ls -l test2
-rw-r--r--  1 ftp  users  524288000 Oct 29 07:46 test2
icarus# date ; fetch -o /dev/null ftp://localhost/test2
Fri Oct 29 07:47:19 PDT 2010
/dev/null 100% of  500 MB  148 MBps
icarus# date ; fetch -o /dev/null ftp://localhost/test2
Fri Oct 29 07:47:24 PDT 2010
/dev/null 100% of  500 MB  175 MBps
icarus# date ; fetch -o /dev/null ftp://localhost/test2
Fri Oct 29 07:47:30 PDT 2010
/dev/null 100% of  500 MB  164 MBps

What ZFS tunings have you applied to your system?  Can you provide
output from sysctl -a 

Re: 8.1-STABLE: zfs and sendfile: problem still exists

[Kostik Belousov]

On Fri, Oct 29, 2010 at 06:31:21PM +0400, Alexander Zagrebin wrote:
   I've tried the nginx with
   disabled sendfile (the nginx.conf contains sendfile off;):
   
   $ dd if=/dev/random of=test bs=1m count=100
   100+0 records in
   100+0 records out
   104857600 bytes transferred in 5.892504 secs (17795083 bytes/sec)
   $ fetch -o /dev/null http://localhost/test
   /dev/null 100% of  100 
  MB   41 MBps
   $ fetch -o /dev/null http://localhost/test
   /dev/null 100% of  100 
  MB   44 MBps
   $ fetch -o /dev/null http://localhost/test
   /dev/null 100% of  100 
  MB   44 MBps
   
  
  I am really surprised with such a bad performance of sendfile.
  Will you be able to profile the issue further?
 
 Yes.
 
  I will also try to think of some measurements.
 
 A transfer rate is too low for the _first_ attempt only.
 Further attempts demonstrates a reasonable transfer rate.
 For example, nginx with sendfile on;:
 
 $ dd if=/dev/random of=test bs=1m count=100
 100+0 records in
 100+0 records out
 104857600 bytes transferred in 5.855305 secs (17908136 bytes/sec)
 $ fetch -o /dev/null http://localhost/test
 /dev/null   3% of  100 MB  118 kBps
 13m50s^C
 fetch: transfer interrupted
 $ fetch -o /dev/null http://localhost/test
 /dev/null 100% of  100 MB   39 MBps
 
 If there was no access to the file during some time, then everything
 repeats:
 The first attempt - transfer rate is too low
 A further attempts - no problems
 
 Can you reproduce the problem on your system?

Could it be the priming of the vm object pages content ?
Due to double-buffering, and (possibly false) optimization to only
perform double-buffering when vm object already has some data cached,
reads can prime vm object page list before file is mmapped or
sendfile-ed.



pgpnA8KHQc5Dk.pgp
Description: PGP signature

Re: 8.1-STABLE: zfs and sendfile: problem still exists

[Andriy Gapon]

on 29/10/2010 17:53 Kostik Belousov said the following:
 Could it be the priming of the vm object pages content ?

Sorry, not familiar with this term.
Do you mean prepopulation of vm object with valid pages?

 Due to double-buffering, and (possibly false) optimization to only

What optimization?

 perform double-buffering when vm object already has some data cached,
 reads can prime vm object page list before file is mmapped or
 sendfile-ed.
 

No double-buffering is done to optimize anything.  Double-buffering is a
consequence of having page cache and ARC.  The special double-buffering code 
is
to just handle that fact - e.g. making sure that VOP_READ reads data from page
cache instead of ARC if it's possible that the data in them differs (i.e. page
cache has more recent data).

So, if I understood the term 'priming' correctly, no priming should ever occur.

-- 
Andriy Gapon
___
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: 8.1-STABLE: zfs and sendfile: problem still exists

[Kostik Belousov]

On Fri, Oct 29, 2010 at 06:05:26PM +0300, Andriy Gapon wrote:
 on 29/10/2010 17:53 Kostik Belousov said the following:
  Could it be the priming of the vm object pages content ?
 
 Sorry, not familiar with this term.
 Do you mean prepopulation of vm object with valid pages?
 
  Due to double-buffering, and (possibly false) optimization to only
 
 What optimization?
On zfs vnode read, the page from the corresponding vm object is only
populated with the vnode data if the page already exists in the
object.

Not doing the optimization would be to allocate the page uncoditionally
on the read if not already present, and copy the data from ARC to the page.
 
  perform double-buffering when vm object already has some data cached,
  reads can prime vm object page list before file is mmapped or
  sendfile-ed.
  
 
 No double-buffering is done to optimize anything. Double-buffering
 is a consequence of having page cache and ARC. The special
 double-buffering code is to just handle that fact - e.g. making
 sure that VOP_READ reads data from page cache instead of ARC if it's
 possible that the data in them differs (i.e. page cache has more
 recent data).

 So, if I understood the term 'priming' correctly, no priming should
 ever occur.
The priming is done on the first call to VOP_READ() with the right
offset after the page is allocated.


pgpsWIastHVGc.pgp
Description: PGP signature

Re: 8.1-STABLE: zfs and sendfile: problem still exists

[Andriy Gapon]

on 29/10/2010 18:17 Kostik Belousov said the following:
 On Fri, Oct 29, 2010 at 06:05:26PM +0300, Andriy Gapon wrote:
 on 29/10/2010 17:53 Kostik Belousov said the following:
 Could it be the priming of the vm object pages content ?

 Sorry, not familiar with this term.
 Do you mean prepopulation of vm object with valid pages?

 Due to double-buffering, and (possibly false) optimization to only

 What optimization?
 On zfs vnode read, the page from the corresponding vm object is only
 populated with the vnode data if the page already exists in the
 object.

Do you mean a specific type of read?
For normal reads it's the other way around - if the page already exists and is
valid, then we read from the page, not from ARC.

 Not doing the optimization would be to allocate the page uncoditionally
 on the read if not already present, and copy the data from ARC to the page.

 perform double-buffering when vm object already has some data cached,
 reads can prime vm object page list before file is mmapped or
 sendfile-ed.


 No double-buffering is done to optimize anything. Double-buffering
 is a consequence of having page cache and ARC. The special
 double-buffering code is to just handle that fact - e.g. making
 sure that VOP_READ reads data from page cache instead of ARC if it's
 possible that the data in them differs (i.e. page cache has more
 recent data).

 So, if I understood the term 'priming' correctly, no priming should
 ever occur.
 The priming is done on the first call to VOP_READ() with the right
 offset after the page is allocated.

Again, what is priming?

-- 
Andriy Gapon
___
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: 8.1-STABLE: zfs and sendfile: problem still exists

[Artemiev Igor]

On Fri, Oct 29, 2010 at 05:41:59PM +0300, Andriy Gapon wrote:

 What svn revision of FreeBSD source tree did you test?

r213936. Revision seems a little old.

 Ah, I think I see what's going on.
 Either sendfile should (have an option to) use VOP_GETPAGES to request data 
 or ZFS
 mappedread should use vm_grab_page instead of vm_lookup_page for UIO_NOCOPY 
 case.
 Currently ZFS would read a whole FS block into ARC, but populate only one page
 with data and for the rest it would just wastefully do uiomove(UIO_NOCOPY) 
 from
 ARC data.
 So, e.g. zpool iostat would show that there are only few actual reads from a 
 pool.
  The rest of the time must be spent churning over the data already in ARC and
 doing page-per-VOP_READ copies from it.
I can test it, but what allocflags? VM_ALLOC_RETRY|VM_ALLOC_NORMAL?
___
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: 8.1-STABLE: zfs and sendfile: problem still exists

[Andriy Gapon]

on 29/10/2010 18:26 Artemiev Igor said the following:
 On Fri, Oct 29, 2010 at 05:41:59PM +0300, Andriy Gapon wrote:
 
 What svn revision of FreeBSD source tree did you test?
 
 r213936. Revision seems a little old.
 
 Ah, I think I see what's going on.
 Either sendfile should (have an option to) use VOP_GETPAGES to request data 
 or ZFS
 mappedread should use vm_grab_page instead of vm_lookup_page for UIO_NOCOPY 
 case.
 Currently ZFS would read a whole FS block into ARC, but populate only one 
 page
 with data and for the rest it would just wastefully do uiomove(UIO_NOCOPY) 
 from
 ARC data.
 So, e.g. zpool iostat would show that there are only few actual reads from a 
 pool.
  The rest of the time must be spent churning over the data already in ARC and
 doing page-per-VOP_READ copies from it.
 I can test it, but what allocflags? VM_ALLOC_RETRY|VM_ALLOC_NORMAL?

Probably yes, but have to be careful there.
First, do vm_page_grab only for UIO_NOCOPY case.
Second, the first page is already shared busy after vm_page_io_start() call in
kern_sendfile; so you might need VM_ALLOC_IGN_SBUSY for that page to avoid a 
deadlock.

I think that it may be good to separate UIO_NOCOPY/sendfile case from mappedread
into a function of its own.


P.S. doing VOP_GETPAGES instead of vn_rdwr() in kern_sendfile() might be a 
better
idea still.  But there are some additional details to that, e.g. a mount/fs flag
to tell which mechanism is preferred.  Because, as I've been told, vn_rdwr() has
better performance than VOP_GETPAGES.  Although, I don't understand why it
could/should be that way.

-- 
Andriy Gapon
___
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: 8.1-STABLE: zfs and sendfile: problem still exists

[Alexander Zagrebin]

  Can you reproduce the problem on your system?
 
 I can't reproduce it on mine.  Note the resilvering was induced from
 some unrelated disk swaps/tests I was performing, and ftpd is already
 enabled via inetd on this system.
 
 What ZFS tunings have you applied to your system?  Can you provide
 output from sysctl -a kstat.zfs.misc.arcstats before and after a
 transfer which exhibits the initial slowdown?

It's amd64 Intel Atom based system with 2G RAM.
/boot/loader.conf contains nothing special:

vm.kmem_size=1536M
vfs.zfs.prefetch_disable=1


$ dd if=/dev/random of=test bs=1m count=50; sysctl -a
kstat.zfs.misc.arcstats; fetch -o /dev/null http://localhost/test; sysctl -a
kstat.zfs.misc.arcstats
50+0 records in
50+0 records out
52428800 bytes transferred in 2.956783 secs (17731705 bytes/sec)
kstat.zfs.misc.arcstats.hits: 10889409
kstat.zfs.misc.arcstats.misses: 2482562
kstat.zfs.misc.arcstats.demand_data_hits: 7920924
kstat.zfs.misc.arcstats.demand_data_misses: 1587278
kstat.zfs.misc.arcstats.demand_metadata_hits: 2968455
kstat.zfs.misc.arcstats.demand_metadata_misses: 895284
kstat.zfs.misc.arcstats.prefetch_data_hits: 0
kstat.zfs.misc.arcstats.prefetch_data_misses: 0
kstat.zfs.misc.arcstats.prefetch_metadata_hits: 30
kstat.zfs.misc.arcstats.prefetch_metadata_misses: 0
kstat.zfs.misc.arcstats.mru_hits: 5596211
kstat.zfs.misc.arcstats.mru_ghost_hits: 199040
kstat.zfs.misc.arcstats.mfu_hits: 5293198
kstat.zfs.misc.arcstats.mfu_ghost_hits: 481006
kstat.zfs.misc.arcstats.allocated: 2985083
kstat.zfs.misc.arcstats.deleted: 1901535
kstat.zfs.misc.arcstats.stolen: 1269643
kstat.zfs.misc.arcstats.recycle_miss: 464100
kstat.zfs.misc.arcstats.mutex_miss: 658
kstat.zfs.misc.arcstats.evict_skip: 148879
kstat.zfs.misc.arcstats.evict_l2_cached: 0
kstat.zfs.misc.arcstats.evict_l2_eligible: 150609301504
kstat.zfs.misc.arcstats.evict_l2_ineligible: 36864
kstat.zfs.misc.arcstats.hash_elements: 91782
kstat.zfs.misc.arcstats.hash_elements_max: 168546
kstat.zfs.misc.arcstats.hash_collisions: 2058158
kstat.zfs.misc.arcstats.hash_chains: 23888
kstat.zfs.misc.arcstats.hash_chain_max: 18
kstat.zfs.misc.arcstats.p: 807441359
kstat.zfs.misc.arcstats.c: 1006632960
kstat.zfs.misc.arcstats.c_min: 125829120
kstat.zfs.misc.arcstats.c_max: 1006632960
kstat.zfs.misc.arcstats.size: 1006690472
kstat.zfs.misc.arcstats.hdr_size: 20252216
kstat.zfs.misc.arcstats.data_size: 917198336
kstat.zfs.misc.arcstats.other_size: 69239920
kstat.zfs.misc.arcstats.l2_hits: 0
kstat.zfs.misc.arcstats.l2_misses: 0
kstat.zfs.misc.arcstats.l2_feeds: 0
kstat.zfs.misc.arcstats.l2_rw_clash: 0
kstat.zfs.misc.arcstats.l2_read_bytes: 0
kstat.zfs.misc.arcstats.l2_write_bytes: 0
kstat.zfs.misc.arcstats.l2_writes_sent: 0
kstat.zfs.misc.arcstats.l2_writes_done: 0
kstat.zfs.misc.arcstats.l2_writes_error: 0
kstat.zfs.misc.arcstats.l2_writes_hdr_miss: 0
kstat.zfs.misc.arcstats.l2_evict_lock_retry: 0
kstat.zfs.misc.arcstats.l2_evict_reading: 0
kstat.zfs.misc.arcstats.l2_free_on_write: 0
kstat.zfs.misc.arcstats.l2_abort_lowmem: 0
kstat.zfs.misc.arcstats.l2_cksum_bad: 0
kstat.zfs.misc.arcstats.l2_io_error: 0
kstat.zfs.misc.arcstats.l2_size: 0
kstat.zfs.misc.arcstats.l2_hdr_size: 0
kstat.zfs.misc.arcstats.memory_throttle_count: 9
kstat.zfs.misc.arcstats.l2_write_trylock_fail: 0
kstat.zfs.misc.arcstats.l2_write_passed_headroom: 0
kstat.zfs.misc.arcstats.l2_write_spa_mismatch: 0
kstat.zfs.misc.arcstats.l2_write_in_l2: 0
kstat.zfs.misc.arcstats.l2_write_io_in_progress: 0
kstat.zfs.misc.arcstats.l2_write_not_cacheable: 30
kstat.zfs.misc.arcstats.l2_write_full: 0
kstat.zfs.misc.arcstats.l2_write_buffer_iter: 0
kstat.zfs.misc.arcstats.l2_write_pios: 0
kstat.zfs.misc.arcstats.l2_write_buffer_bytes_scanned: 0
kstat.zfs.misc.arcstats.l2_write_buffer_list_iter: 0
kstat.zfs.misc.arcstats.l2_write_buffer_list_null_iter: 0
/dev/null 100% of   50 MB  119 kBps
00m00s
kstat.zfs.misc.arcstats.hits: 10928358
kstat.zfs.misc.arcstats.misses: 2486504
kstat.zfs.misc.arcstats.demand_data_hits: 7959052
kstat.zfs.misc.arcstats.demand_data_misses: 1590868
kstat.zfs.misc.arcstats.demand_metadata_hits: 2969276
kstat.zfs.misc.arcstats.demand_metadata_misses: 895636
kstat.zfs.misc.arcstats.prefetch_data_hits: 0
kstat.zfs.misc.arcstats.prefetch_data_misses: 0
kstat.zfs.misc.arcstats.prefetch_metadata_hits: 30
kstat.zfs.misc.arcstats.prefetch_metadata_misses: 0
kstat.zfs.misc.arcstats.mru_hits: 5601378
kstat.zfs.misc.arcstats.mru_ghost_hits: 199211
kstat.zfs.misc.arcstats.mfu_hits: 5326980
kstat.zfs.misc.arcstats.mfu_ghost_hits: 482037
kstat.zfs.misc.arcstats.allocated: 2989914
kstat.zfs.misc.arcstats.deleted: 1904492
kstat.zfs.misc.arcstats.stolen: 1272047
kstat.zfs.misc.arcstats.recycle_miss: 464306
kstat.zfs.misc.arcstats.mutex_miss: 658
kstat.zfs.misc.arcstats.evict_skip: 148880
kstat.zfs.misc.arcstats.evict_l2_cached: 0
kstat.zfs.misc.arcstats.evict_l2_eligible: 150970209280
kstat.zfs.misc.arcstats.evict_l2_ineligible: 36864
kstat.zfs.misc.arcstats.hash_elements: 92084

linux_base-f10 [Was: Re: VirtualBox OpenSolaris guest becomes: portmaster]

[Harald Weis]

On Tue, Oct 19, 2010 at 01:09:39PM +0200, Harald Weis wrote:
 On Mon, Oct 18, 2010 at 08:32:04AM -0400, Alex Goncharov wrote:
  ,--- You/Harald (Mon, 18 Oct 2010 14:02:27 +0200) *
  | What else could I possibly do?
  
  | - portmaster www/opera-linuxplugins   # installing linux_base-f10-10_3,
  |   then stopping as follows:
  | ===  Installing for linux-f10-expat-2.0.1
  | ===   Generating temporary packing list
  | brandelf: error opening file usr/bin/xmlwf: No such file or directory
  | *** Error code 1
  
  | Stop in /usr/ports/textproc/linux-f10-expat.
  
  I am not using portmaster; try do it simply through make.  I just did
  it now:
  
  --
  cat /compat/linux/etc/fedora-release 
  Fedora release 10 (Cambridge)
 
 Ah, I see, that's it. I can't run this cat command because my
 /compat/linux directory is empty. Obviously it went always wrong with
 portmaster emulators/linux_base-f10. This command should have populated
 the linuxbase, i.e. /compat/linux, directory if I understand correctly.
 The script (I kept it) shows no problem whatsoever. The Makefile says
 clearly to use the linuxbase as prefix for installation.
 Portmaster seems to be responsible here. Please note that portmaster
 is my friend since July 2008. Without any problem! In my humble
 opinion portmaster is quite an extraordinary tool. By far I prefer it to
 portupgrade.
 Presently, there seems to be a problem just with the linux stuff.
 Doug, may I ask you for help please ?
 
 Now I will go and reinstall for the third time all ports with
 portmaster  `cat ~/installed-port-list` which did work like a charm last
 time and then install the linux ports with make.

I've done it and there is absolutely no change. In fact, I am not
surprised. It was unreasonable to accuse portmaster which works fine for
all ports. Why should it fail only for the linux ports?

I cannot find out why the linux_base-f10 files are not installed in the
linuxbase (/compat/linux). The typescript says:
extract
===  Patching for linux_base-f10-10_3
===  Configuring for linux_base-f10-10_3
===  Building for linux_base-f10-10_3
===  Installing for linux_base-f10-10_3
===   Generating temporary packing list
===  Checking if emulators/linux_base-f10 already installed
274736 blocks

+++ Some programs may need linprocfs, please add it to /etc/fstab! +++

Running linux ldconfig...

This software is based in part on the work of the FreeType Team.
See URL:http://www.freetype.org/.

Installation of the Linux base system is finished. The Linux kernel
mode, which must be enabled for Linux binaries to run, is now
enabled. Linux mode can be enabled permanently with the linux_enable
variable of rc.conf(5).
/extract

NOTHING has been installed in /compat/linux in spite of the
USE_LINUX_PREFIX=yes line in Makefile.

No wonder that the system gets broken. This time I've succeeded in
repairing it - more or less - without reinstalling _all_ ports. As I
said earlier, nothing in the typescript indicates that something went
wrong.

Testing the LINUXBASE variable is also alright:
m...@pollux:/3linux_base-f10 # make clean
===  Cleaning for linux_base-f10-10_3
m...@pollux:/3linux_base-f10 # make -V LINUXBASE
/compat/linux
m...@pollux:/3linux_base-f10 #

For the next (fourth) experiment I would like to run
make install WITH_DEBUG=yes .

Is that okay or is there a better way?

Thank you in advance,
Harald
___
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

safe mode

[Stephen Clark]

Hello,

I am having a problem getting 6.3 to boot on an intel atom mb. When it 
gets to

where it should identify the drive it hangs.

If I boot with no acpi it does the same thing.

If I boot with safe mode it comes up and identifies the drive but then
starts spewing the following errors:
ipfw2 initialized, divert enabled, rule-based forwarding disabled, 
default to ad

interrupt storm detected on irq15:; throttling interrupt source
ad4: 152627MB WDC WD1600BEKT-00A25T0 01.01A01 at ata2-master PIO4
interrupt storm detected on irq15:; throttling interrupt source
interrupt storm detected on irq15:; throttling interrupt source
interrupt storm detected on irq15:; throttling interrupt source

FreeBSD runs but I continue to get these errors:

What exactly does safe mode do - I am afraid my forth skills are not 
what they

should be.

Is there some device.hints I could set to correct this problem? A 
pciconf listing follows.

# pciconf -lv
hos...@pci0:0:0:0:  class=0x06 card=0xa0008086 chip=0xa0008086 
rev=0x02 hdr=0x00

vendor = 'Intel Corporation'
class  = bridge
subclass   = HOST-PCI
vgap...@pci0:0:2:0: class=0x03 card=0xa0018086 chip=0xa0018086 
rev=0x02 hdr=0x00

vendor = 'Intel Corporation'
class  = display
subclass   = VGA
vgap...@pci0:0:2:1: class=0x038000 card=0xa0018086 chip=0xa0028086 
rev=0x02 hdr=0x00

vendor = 'Intel Corporation'
class  = display
uh...@pci0:0:26:0:  class=0x0c0300 card=0x28348086 chip=0x28348086 
rev=0x03 hdr=0x00

vendor = 'Intel Corporation'
device = '82801H (ICH8 Family) USB UHCI'
class  = serial bus
subclass   = USB
uh...@pci0:0:26:1:  class=0x0c0300 card=0x28358086 chip=0x28358086 
rev=0x03 hdr=0x00

vendor = 'Intel Corporation'
device = '82801H (ICH8 Family) USB UHCI'
class  = serial bus
subclass   = USB
eh...@pci0:0:26:7:  class=0x0c0320 card=0x283a8086 chip=0x283a8086 
rev=0x03 hdr=0x00

vendor = 'Intel Corporation'
device = '81EC1043 (?) ICH8 Enhanced USB2 Enhanced Host Controller'
class  = serial bus
subclass   = USB
no...@pci0:0:27:0:  class=0x040300 card=0xa62516f3 chip=0x284b8086 
rev=0x03 hdr=0x00

vendor = 'Intel Corporation'
device = '82801H SUBSYS_81EC1043REV_02\3115836590D8'
class  = multimedia
subclass   = HDA
pc...@pci0:0:28:0:  class=0x060400 card=0x283f8086 chip=0x283f8086 
rev=0x03 hdr=0x01

vendor = 'Intel Corporation'
device = '82801H (ICH8 Family) PCIe Port 1'
class  = bridge
subclass   = PCI-PCI
pc...@pci0:0:28:3:  class=0x060400 card=0x28458086 chip=0x28458086 
rev=0x03 hdr=0x01

vendor = 'Intel Corporation'
device = '82801H (ICH8 Family) PCIe Port 4'
class  = bridge
subclass   = PCI-PCI
pc...@pci0:0:28:4:  class=0x060400 card=0x28478086 chip=0x28478086 
rev=0x03 hdr=0x01

vendor = 'Intel Corporation'
device = '82801H (ICH8 Family) PCIe Port 5'
class  = bridge
subclass   = PCI-PCI
uh...@pci0:0:29:0:  class=0x0c0300 card=0x28308086 chip=0x28308086 
rev=0x03 hdr=0x00

vendor = 'Intel Corporation'
device = '82801H (ICH8 Family) USB UHCI'
class  = serial bus
subclass   = USB
uh...@pci0:0:29:1:  class=0x0c0300 card=0x28318086 chip=0x28318086 
rev=0x03 hdr=0x00

vendor = 'Intel Corporation'
device = '82801H (ICH8 Family) USB UHCI'
class  = serial bus
subclass   = USB
uh...@pci0:0:29:2:  class=0x0c0300 card=0x28328086 chip=0x28328086 
rev=0x03 hdr=0x00

vendor = 'Intel Corporation'
device = '82801H (ICH8 Family) USB UHCI'
class  = serial bus
subclass   = USB
eh...@pci0:0:29:7:  class=0x0c0320 card=0x28368086 chip=0x28368086 
rev=0x03 hdr=0x00

vendor = 'Intel Corporation'
device = '82801H (ICH8 Family) USB2 EHCI'
class  = serial bus
subclass   = USB
pc...@pci0:0:30:0:  class=0x060401 card=0x24488086 chip=0x24488086 
rev=0xf3 hdr=0x01

vendor = 'Intel Corporation'
device = '82801BAM/CAM/DBM (ICH2-M/3-M/4-M) Hub Interface to 
PCI Bridge'

class  = bridge
subclass   = PCI-PCI
is...@pci0:0:31:0:  class=0x060100 card=0x28158086 chip=0x28158086 
rev=0x03 hdr=0x00

vendor = 'Intel Corporation'
device = 'ICH8M-E (ICH8 Family) LPC Interface Controller'
class  = bridge
subclass   = PCI-ISA
atap...@pci0:0:31:1:class=0x01018a card=0x28508086 chip=0x28508086 
rev=0x03 hdr=0x00

vendor = 'Intel Corporation'
device = '82801H (ICH8 Family) Ultra ATA Storage Controllers'
class  = mass storage
subclass   = ATA
atap...@pci0:0:31:2:class=0x01018f card=0x28288086 chip=0x28288086 
rev=0x03 hdr=0x00

vendor = 'Intel Corporation'
device = 'ICH8M (ICH8 Family) 3 port SATA Controller'
class  = mass storage
subclass   = ATA

Re: safe mode

[Jeremy Chadwick]

On Fri, Oct 29, 2010 at 11:17:50AM -0400, Stephen Clark wrote:
 I am having a problem getting 6.3 to boot on an intel atom mb. When
 it gets to where it should identify the drive it hangs.

Can you try 8.1-RELEASE or an 8.1-STABLE snapshot instead?  I mean, you
*are* using an Intel Atom system, which contains significantly more
advanced hardware than was available during the RELENG_6 days.

Oh, I think you answer this further down...

 If I boot with no acpi it does the same thing.
 
 If I boot with safe mode it comes up and identifies the drive but then
 starts spewing the following errors:
 ipfw2 initialized, divert enabled, rule-based forwarding disabled,
 default to ad
 interrupt storm detected on irq15:; throttling interrupt source
 ad4: 152627MB WDC WD1600BEKT-00A25T0 01.01A01 at ata2-master PIO4
 interrupt storm detected on irq15:; throttling interrupt source
 interrupt storm detected on irq15:; throttling interrupt source
 interrupt storm detected on irq15:; throttling interrupt source
 
 FreeBSD runs but I continue to get these errors:
 
 What exactly does safe mode do - I am afraid my forth skills are not
 what they should be.

Safe mode does the following before doing boot:

set hw.ata.ata_dma=0
set hw.ata.atapi_dma=0
set hw.ata.wc=0
set hw.eisa_slots=0
set hint.kbdmux.0.disabled=1

It also does the following if you're booting/running i386:

unset acpi_load
set hint.acpi.0.disabled=1
set loader.acpi_disabled_by_user=1
set hint.apic.0.disabled=1

The code is in /boot/beastie.4th.

IMHO, you shouldn't be disabling ACPI, or using safe mode to try and
get your system working.  Can you please boot Verbose mode instead and
provide all of the output somewhere?  You'll probably need serial
console for this, since the system hangs.


 atap...@pci0:0:31:1:class=0x01018a card=0x28508086
 chip=0x28508086 rev=0x03 hdr=0x00
 vendor = 'Intel Corporation'
 device = '82801H (ICH8 Family) Ultra ATA Storage Controllers'
 class  = mass storage
 subclass   = ATA
 atap...@pci0:0:31:2:class=0x01018f card=0x28288086
 chip=0x28288086 rev=0x03 hdr=0x00
 vendor = 'Intel Corporation'
 device = 'ICH8M (ICH8 Family) 3 port SATA Controller'
 class  = mass storage
 subclass   = ATA

Your storage controller is an Intel ICH8, which is supported by FreeBSD,
but the ATA layer differs greatly between 6.x and 8.x (read: better on
8.x).  AHCI is also well-supported on 8.x if your system/BIOS supports
it.

 I am stuck for now on 6.3 so moving to a later release 7+ is not feasible.

Can you explain why?  (If I don't ask it, someone else will.)  This will
almost certainly be the key to this discussion, especially since you
say:

 Additional info:
 6.4 exhibits the same behavior. 7.2 boots okay in normal mode.

You should probably read this, specifically the fact that the RELENG_6
branch is being EOL'd in about 30 days.

http://www.freebsd.org/security/

-- 
| Jeremy Chadwick   j...@parodius.com |
| Parodius Networking   http://www.parodius.com/ |
| UNIX Systems Administrator  Mountain View, CA, USA |
| Making life hard for others since 1977.  PGP: 4BD6C0CB |

___
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: safe mode

[Stephen Clark]

On 10/29/2010 12:54 PM, Jeremy Chadwick wrote:

On Fri, Oct 29, 2010 at 11:17:50AM -0400, Stephen Clark wrote:
   

I am having a problem getting 6.3 to boot on an intel atom mb. When
it gets to where it should identify the drive it hangs.
 

Can you try 8.1-RELEASE or an 8.1-STABLE snapshot instead?  I mean, you
*are* using an Intel Atom system, which contains significantly more
advanced hardware than was available during the RELENG_6 days.

Oh, I think you answer this further down...

   

If I boot with no acpi it does the same thing.

If I boot with safe mode it comes up and identifies the drive but then
starts spewing the following errors:
ipfw2 initialized, divert enabled, rule-based forwarding disabled,
default to ad
interrupt storm detected on irq15:; throttling interrupt source
ad4: 152627MBWDC WD1600BEKT-00A25T0 01.01A01  at ata2-master PIO4
interrupt storm detected on irq15:; throttling interrupt source
interrupt storm detected on irq15:; throttling interrupt source
interrupt storm detected on irq15:; throttling interrupt source

FreeBSD runs but I continue to get these errors:

What exactly does safe mode do - I am afraid my forth skills are not
what they should be.
 

Safe mode does the following before doing boot:

set hw.ata.ata_dma=0
set hw.ata.atapi_dma=0
set hw.ata.wc=0
set hw.eisa_slots=0
set hint.kbdmux.0.disabled=1

It also does the following if you're booting/running i386:

unset acpi_load
set hint.acpi.0.disabled=1
set loader.acpi_disabled_by_user=1
set hint.apic.0.disabled=1

The code is in /boot/beastie.4th.

IMHO, you shouldn't be disabling ACPI, or using safe mode to try and
get your system working.  Can you please boot Verbose mode instead and
provide all of the output somewhere?  You'll probably need serial
console for this, since the system hangs.


   

atap...@pci0:0:31:1:class=0x01018a card=0x28508086
chip=0x28508086 rev=0x03 hdr=0x00
 vendor = 'Intel Corporation'
 device = '82801H (ICH8 Family) Ultra ATA Storage Controllers'
 class  = mass storage
 subclass   = ATA
atap...@pci0:0:31:2:class=0x01018f card=0x28288086
chip=0x28288086 rev=0x03 hdr=0x00
 vendor = 'Intel Corporation'
 device = 'ICH8M (ICH8 Family) 3 port SATA Controller'
 class  = mass storage
 subclass   = ATA
 

Your storage controller is an Intel ICH8, which is supported by FreeBSD,
but the ATA layer differs greatly between 6.x and 8.x (read: better on
8.x).  AHCI is also well-supported on 8.x if your system/BIOS supports
it.

   

I am stuck for now on 6.3 so moving to a later release 7+ is not feasible.
 

Can you explain why?  (If I don't ask it, someone else will.)  This will
almost certainly be the key to this discussion, especially since you
say:

   
I am supporting over 700 units in the field that are acting as 
firewall/router/vpn devices,
that are running 6.3. It would not be feasible to upgrade them to a new 
version of FreeBSD
remotely. Also if I was going to move to a  later release of FreeBSD for 
the new hardware
it would involve months  of new testing and validation of the new 
release, where putting a patched

6.3 kernel is relatively straightforward.

Verbose boot output at the end.



Additional info:
6.4 exhibits the same behavior. 7.2 boots okay in normal mode.
 

You should probably read this, specifically the fact that the RELENG_6
branch is being EOL'd in about 30 days.

http://www.freebsd.org/security/

   




 �  Select option, [Enter] for default �
 �  or [Space] to pause timer  5   �



/boot/kernel/acpi.ko text=0x44a7c data=0x24c0+0x1b8c 
syms=[0x4+0x7d50+0x4+0xaa]|

SMAP type=01 base= len=0009fc00
SMAP type=02 base=0009fc00 len=0400
SMAP type=02 base=000e len=0002
SMAP type=01 base=0010 len=3f5a
SMAP type=03 base=3f6a len=e000
SMAP type=04 base=3f6ae000 len=00032000
SMAP type=02 base=3f6e len=0001
SMAP type=02 base=3f6f len=0001
SMAP type=02 base=fee0 len=1000
SMAP type=02 base=ffb0 len=0050
Copyright (c) 1992-2008 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 6.3-RELEASE-p15 #17: Fri Apr 16 12:51:57 EST 2010
r...@z2984.netwolves.com:/usr/src/sys/i386/compile/WOLFPAC6SMP
Preloaded elf kernel /boot/kernel/kernel at 0xc0bfd000.
Preloaded elf module /boot/kernel/acpi.ko at 0xc0bfd19c.
MP Configuration Table version 1.4 found at 0xc00fdc90
Table 'FACP' at 0x3f6a0290
Table 'APIC' at 0x3f6a0390
MADT: Found table at 0x3f6a0390
APIC: Using the MADT enumerator.
MADT: Found CPU APIC ID 0 ACPI ID 1: enabled
SMP: Added CPU 0 (AP)
MADT: Found CPU APIC ID 2 ACPI ID 2: 

Re: safe mode

[Jeremy Chadwick]

On Fri, Oct 29, 2010 at 01:12:29PM -0400, Stephen Clark wrote:
 On 10/29/2010 12:54 PM, Jeremy Chadwick wrote:
 On Fri, Oct 29, 2010 at 11:17:50AM -0400, Stephen Clark wrote:
 I am having a problem getting 6.3 to boot on an intel atom mb. When
 it gets to where it should identify the drive it hangs.
 Can you try 8.1-RELEASE or an 8.1-STABLE snapshot instead?  I mean, you
 *are* using an Intel Atom system, which contains significantly more
 advanced hardware than was available during the RELENG_6 days.
 
 Oh, I think you answer this further down...
 
 If I boot with no acpi it does the same thing.
 
 If I boot with safe mode it comes up and identifies the drive but then
 starts spewing the following errors:
 ipfw2 initialized, divert enabled, rule-based forwarding disabled,
 default to ad
 interrupt storm detected on irq15:; throttling interrupt source
 ad4: 152627MBWDC WD1600BEKT-00A25T0 01.01A01  at ata2-master PIO4
 interrupt storm detected on irq15:; throttling interrupt source
 interrupt storm detected on irq15:; throttling interrupt source
 interrupt storm detected on irq15:; throttling interrupt source
 
 FreeBSD runs but I continue to get these errors:
 
 What exactly does safe mode do - I am afraid my forth skills are not
 what they should be.
 Safe mode does the following before doing boot:
 
 set hw.ata.ata_dma=0
 set hw.ata.atapi_dma=0
 set hw.ata.wc=0
 set hw.eisa_slots=0
 set hint.kbdmux.0.disabled=1
 
 It also does the following if you're booting/running i386:
 
 unset acpi_load
 set hint.acpi.0.disabled=1
 set loader.acpi_disabled_by_user=1
 set hint.apic.0.disabled=1
 
 The code is in /boot/beastie.4th.
 
 IMHO, you shouldn't be disabling ACPI, or using safe mode to try and
 get your system working.  Can you please boot Verbose mode instead and
 provide all of the output somewhere?  You'll probably need serial
 console for this, since the system hangs.
 
 
 atap...@pci0:0:31:1:class=0x01018a card=0x28508086
 chip=0x28508086 rev=0x03 hdr=0x00
  vendor = 'Intel Corporation'
  device = '82801H (ICH8 Family) Ultra ATA Storage Controllers'
  class  = mass storage
  subclass   = ATA
 atap...@pci0:0:31:2:class=0x01018f card=0x28288086
 chip=0x28288086 rev=0x03 hdr=0x00
  vendor = 'Intel Corporation'
  device = 'ICH8M (ICH8 Family) 3 port SATA Controller'
  class  = mass storage
  subclass   = ATA
 Your storage controller is an Intel ICH8, which is supported by FreeBSD,
 but the ATA layer differs greatly between 6.x and 8.x (read: better on
 8.x).  AHCI is also well-supported on 8.x if your system/BIOS supports
 it.
 
 I am stuck for now on 6.3 so moving to a later release 7+ is not feasible.
 Can you explain why?  (If I don't ask it, someone else will.)  This will
 almost certainly be the key to this discussion, especially since you
 say:
 
 I am supporting over 700 units in the field that are acting as
 firewall/router/vpn devices,
 that are running 6.3. It would not be feasible to upgrade them to a
 new version of FreeBSD
 remotely. Also if I was going to move to a  later release of FreeBSD
 for the new hardware
 it would involve months  of new testing and validation of the new
 release, where putting a patched
 6.3 kernel is relatively straightforward.

I'm a little confused.  Did you deploy over 700 field units running
FreeBSD 6.3 without testing it first on this particular piece of
hardware/setup?  Or did you recently upgrade from FreeBSD X.Y to 6.3 and
found that things broke?  What I'm trying to find out is whether or not
these systems ever worked for you, and if so, at what point did they
stop working.  Possibly we can work backwards to figure out what code
change/commit broke things for you.  Keep reading for some ideas.

First question: are you using any parameters in /boot/loader.conf or
/boot.config?  If so, what are they?

Second question: can you provide your kernel configuration file?

As for the verbose boot -- thanks much.  Appropriate folks should be
here on the list, so if they have ideas they'll probably reply.  A quick
analysis indicates the following:

ata0 -- atapci0 -- Intel ATA controller master, IDE/PATA, IRQ 14
ata1 -- atapci0 -- Intel ATA controller slave,  IDE/PATA, IRQ 14
ata2 -- atapci1 -- Intel ATA controller master, IDE/PATA, IRQ 15
ata3 -- atapci1 -- Intel ATA controller slave,  IDE/PATA, IRQ 15

A single device is found on ata2, but no other devices are found on the
other ATA busses:

 ata2: reset tp2 stat0=50 stat1=00 devices=0x1ATA_MASTER

That probably correlates with what you see when you boot safe mode,
since there we see this message:

  ad4: 152627MB WDC WD1600BEKT-00A25T0 01.01A01 at ata2-master PIO4

However, there's other messages which are a serious concern, given their
association with the ATA controller in question:

  interrupt storm detected on irq15:; throttling interrupt source
  interrupt storm detected on irq15:; throttling interrupt source
  interrupt storm detected on irq15:; 

Re: 8.1-STABLE: zfs and sendfile: problem still exists

[Artemiev Igor]

On Fri, Oct 29, 2010 at 07:06:03PM +0300, Andriy Gapon wrote:
 Probably yes, but have to be careful there.
 First, do vm_page_grab only for UIO_NOCOPY case.
 Second, the first page is already shared busy after vm_page_io_start() call 
 in
 kern_sendfile; so you might need VM_ALLOC_IGN_SBUSY for that page to avoid a 
 deadlock.

RELENG_8 doesn`t have VM_ALLOC_IGN_SBUSY, it appeared only in HEAD.
Can you review this patch, Whether correctly I have understood? (didnt test it 
yet) 

--- sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c.orig 
2010-10-29 18:18:23.921078337 +0200
+++ sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c  2010-10-29 
19:23:48.142513084 +0200
@@ -449,7 +449,7 @@
int bytes = MIN(PAGESIZE - off, len);
 
 again:
-   if ((m = vm_page_lookup(obj, OFF_TO_IDX(start))) != NULL 
+   if (uio-uio_segflg != UIO_NOCOPY  (m = vm_page_lookup(obj, 
OFF_TO_IDX(start))) != NULL 
vm_page_is_valid(m, off, bytes)) {
if (vm_page_sleep_if_busy(m, FALSE, zfsmrb))
goto again;
@@ -464,7 +464,7 @@
uiomove_fromphys(m, off, bytes, uio);
VM_OBJECT_LOCK(obj);
vm_page_wakeup(m);
-   } else if (m != NULL  uio-uio_segflg == UIO_NOCOPY) {
+   } else if (uio-uio_segflg == UIO_NOCOPY) {
/*
 * The code below is here to make sendfile(2) work
 * correctly with ZFS. As pointed out by ups@
@@ -472,11 +472,9 @@
 * but it pessimize performance of sendfile/UFS, that's
 * why I handle this special case in ZFS code.
 */
-   KASSERT(off == 0,
-   (unexpected offset in mappedread for sendfile));
-   if (vm_page_sleep_if_busy(m, FALSE, zfsmrb))
-   goto again;
-   vm_page_busy(m);
+   if((m = vm_page_lookup(obj, OFF_TO_IDX(start))) == NULL 
|| !vm_page_is_valid(m, off, bytes)) 
+   m = vm_page_grab(obj, OFF_TO_IDX(start), 
VM_ALLOC_NORMAL|VM_ALLOC_RETRY);
+
VM_OBJECT_UNLOCK(obj);
if (dirbytes  0) {
error = dmu_read_uio(os, zp-z_id, uio,
___
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: Degraded zpool cannot detach old/bad drive

[Rumen Telbizov]

Hi Artem, everyone,

Thanks once again for your feedback and help.
Here's more information.

# zpool export tank

# ls /dev/gpt
disk-e1:s10 disk-e1:s11 disk-e1:s12 disk-e1:s13
disk-e1:s14 disk-e1:s15 disk-e1:s16 disk-e1:s18
disk-e1:s19 disk-e1:s20 disk-e1:s21 disk-e1:s22
disk-e1:s23 disk-e1:s3 disk-e1:s4 disk-e1:s5
disk-e1:s6 disk-e1:s7 disk-e1:s8 disk-e1:s9
disk-e2:s0 disk-e2:s1 disk-e2:s10 disk-e2:s11
disk-e2:s2 disk-e2:s3 disk-e2:s4 disk-e2:s5
disk-e2:s6 disk-e2:s7 disk-e2:s8 disk-e2:s9
newdisk-e1:s17
newdisk-e1:s2

All the disks are here! Same for /dev/gptid/. Now importing the pool back
like you suggested:

# zpool import -d /dev/gpt
  pool: tank
id: 13504509992978610301
 state: UNAVAIL
status: One or more devices contains corrupted data.
action: The pool cannot be imported due to damaged devices or data.
   see: http://www.sun.com/msg/ZFS-8000-5E
config:

tank UNAVAIL  insufficient replicas
  raidz1 ONLINE
gpt/disk-e1:s10  ONLINE
mfid9p1  ONLINE
mfid10p1 ONLINE
mfid11p1 ONLINE

It's missing a ton of drives. kern.geom.label.gptid.enable=0 makes no
difference either

And if I import it normally I get the same result as before. The pool is
imported OK but
with most of the disks referred to as mfidXXX instead of /dev/gpt/disk-XX
and here's what I have left:

# ls /dev/gpt
 disk-e1:s10  disk-e1:s20  disk-e2:s0

The problem I think comes down to what I have written in the zpool.cache
file.
It stores the mfid path instead of the gpt/disk one.

  children[0]
 type='disk'
 id=0
 guid=1641394056824955485
* path='/dev/mfid33p1'*
* phys_path='/p...@0,0/pci8086,3...@1c/pci15d9,c...@0/s...@1,0:a'*
 whole_disk=0
* DTL=55*
*
*
Compared to a disk from a partner server which is fine:

  children[0]
 type='disk'
 id=0
 guid=5513814503830705577
 path='/dev/gpt/disk-e1:s6'
 whole_disk=0
*
*
*I suspect OpenSolaris overwrote that part. So I wonder if there's way to
actually*
*edit the /boot/zfs/zpool.cache file and replace path with the corresponding
/dev/gpt*
*entry and remove the **phys_path **one. I don't know about DTL? Is there a
way *
to do this and how stupid that idea sounds to you? They should still point
to the same
data after all?

*
I cannot find a good zdb tutorial so this
is what I've got for now:
*

# zdb
tank
version=14
name='tank'
state=0
txg=206266
pool_guid=13504509992978610301
hostid=409325918
hostname=''
vdev_tree
type='root'
id=0
guid=13504509992978610301
children[0]
type='raidz'
id=0
guid=3740854890192825394
nparity=1
metaslab_array=33
metaslab_shift=36
ashift=9
asize=7995163410432
is_log=0
children[0]
type='disk'
id=0
guid=1641394056824955485
*path='/dev/mfid33p1'*
*phys_path='/p...@0,0/pci8086,3...@1c/pci15d9,c...@0
/s...@1,0:a'*
whole_disk=0
*DTL=55*
children[1]
type='disk'
id=1
guid=6047192237176807561
path='/dev/mfid1p1'
phys_path='/p...@0,0/pci8086,3...@1c/pci15d9,c...@0
/s...@2,0:a'
whole_disk=0
DTL=250
children[2]
type='disk'
id=2
guid=9178318500891071208
path='/dev/mfid2p1'
phys_path='/p...@0,0/pci8086,3...@1c/pci15d9,c...@0
/s...@3,0:a'
whole_disk=0
DTL=249
children[3]
type='disk'
id=3
guid=2567999855746767831
path='/dev/mfid3p1'
phys_path='/p...@0,0/pci8086,3...@1c/pci15d9,c...@0
/s...@4,0:a'
whole_disk=0
DTL=248
children[1]
type='raidz'
id=1
guid=17097047310177793733
nparity=1
metaslab_array=31
metaslab_shift=36
ashift=9
asize=7995163410432
is_log=0
children[0]
type='disk'
id=0
guid=14513380297393196654
path='/dev/mfid4p1'
phys_path='/p...@0,0/pci8086,3...@1c/pci15d9,c...@0
/s...@5,0:a'
   

Re: safe mode

[Stephen Clark]

On 10/29/2010 01:40 PM, Jeremy Chadwick wrote:

On Fri, Oct 29, 2010 at 01:12:29PM -0400, Stephen Clark wrote:
   

On 10/29/2010 12:54 PM, Jeremy Chadwick wrote:
 

On Fri, Oct 29, 2010 at 11:17:50AM -0400, Stephen Clark wrote:
   

I am having a problem getting 6.3 to boot on an intel atom mb. When
it gets to where it should identify the drive it hangs.
 

Can you try 8.1-RELEASE or an 8.1-STABLE snapshot instead?  I mean, you
*are* using an Intel Atom system, which contains significantly more
advanced hardware than was available during the RELENG_6 days.

Oh, I think you answer this further down...

   

If I boot with no acpi it does the same thing.

If I boot with safe mode it comes up and identifies the drive but then
starts spewing the following errors:
ipfw2 initialized, divert enabled, rule-based forwarding disabled,
default to ad
interrupt storm detected on irq15:; throttling interrupt source
ad4: 152627MBWDC WD1600BEKT-00A25T0 01.01A01   at ata2-master PIO4
interrupt storm detected on irq15:; throttling interrupt source
interrupt storm detected on irq15:; throttling interrupt source
interrupt storm detected on irq15:; throttling interrupt source

FreeBSD runs but I continue to get these errors:

What exactly does safe mode do - I am afraid my forth skills are not
what they should be.
 

Safe mode does the following before doing boot:

set hw.ata.ata_dma=0
set hw.ata.atapi_dma=0
set hw.ata.wc=0
set hw.eisa_slots=0
set hint.kbdmux.0.disabled=1

It also does the following if you're booting/running i386:

unset acpi_load
set hint.acpi.0.disabled=1
set loader.acpi_disabled_by_user=1
set hint.apic.0.disabled=1

The code is in /boot/beastie.4th.

IMHO, you shouldn't be disabling ACPI, or using safe mode to try and
get your system working.  Can you please boot Verbose mode instead and
provide all of the output somewhere?  You'll probably need serial
console for this, since the system hangs.


   

atap...@pci0:0:31:1:class=0x01018a card=0x28508086
chip=0x28508086 rev=0x03 hdr=0x00
 vendor = 'Intel Corporation'
 device = '82801H (ICH8 Family) Ultra ATA Storage Controllers'
 class  = mass storage
 subclass   = ATA
atap...@pci0:0:31:2:class=0x01018f card=0x28288086
chip=0x28288086 rev=0x03 hdr=0x00
 vendor = 'Intel Corporation'
 device = 'ICH8M (ICH8 Family) 3 port SATA Controller'
 class  = mass storage
 subclass   = ATA
 

Your storage controller is an Intel ICH8, which is supported by FreeBSD,
but the ATA layer differs greatly between 6.x and 8.x (read: better on
8.x).  AHCI is also well-supported on 8.x if your system/BIOS supports
it.

   

I am stuck for now on 6.3 so moving to a later release 7+ is not feasible.
 

Can you explain why?  (If I don't ask it, someone else will.)  This will
almost certainly be the key to this discussion, especially since you
say:

   

I am supporting over 700 units in the field that are acting as
firewall/router/vpn devices,
that are running 6.3. It would not be feasible to upgrade them to a
new version of FreeBSD
remotely. Also if I was going to move to a  later release of FreeBSD
for the new hardware
it would involve months  of new testing and validation of the new
release, where putting a patched
6.3 kernel is relatively straightforward.
 

I'm a little confused.  Did you deploy over 700 field units running
FreeBSD 6.3 without testing it first on this particular piece of
hardware/setup?  Or did you recently upgrade from FreeBSD X.Y to 6.3 and
found that things broke?  What I'm trying to find out is whether or not
these systems ever worked for you, and if so, at what point did they
stop working.

Sorry for the confusion. We have a mix of hardware in the field. The current
hardware platform we are shipping is going EOL from the vendor. I am testing
the vendors next generation of hardware.

I included at the end a verbose startup using the 6.3 install disc.


  Possibly we can work backwards to figure out what code
change/commit broke things for you.  Keep reading for some ideas.

First question: are you using any parameters in /boot/loader.conf or
/boot.config?  If so, what are they?
   
Second question: can you provide your kernel configuration file?


As for the verbose boot -- thanks much.  Appropriate folks should be
here on the list, so if they have ideas they'll probably reply.  A quick
analysis indicates the following:

ata0 --  atapci0 --  Intel ATA controller master, IDE/PATA, IRQ 14
ata1 --  atapci0 --  Intel ATA controller slave,  IDE/PATA, IRQ 14
ata2 --  atapci1 --  Intel ATA controller master, IDE/PATA, IRQ 15
ata3 --  atapci1 --  Intel ATA controller slave,  IDE/PATA, IRQ 15

A single device is found on ata2, but no other devices are found on the
other ATA busses:

   

ata2: reset tp2 stat0=50 stat1=00 devices=0x1ATA_MASTER
 

That probably correlates with what you see when you boot safe mode,
since there we see this 

Cross-build failure on sparc64 for TARGET=amd64

[Nathaniel W Filardo]

Running
 sudo make TARGET_ARCH=amd64 TARGET=amd64 DESTDIR=/usr/x86_64 -j4 buildworld 
on
 FreeBSD sparcslave.priv.oc.ietfng.org 8.1-STABLE FreeBSD 8.1-STABLE #2 
 r214092=9050e7b-dirty: Thu Oct 21 01:25:54 UTC 2010 
 r...@t@sparcslave.priv.oc.ietfng.org:/usr/obj/usr/src/sys/SLAVKERN  sparc64
with /usr/src at e32025d from git://gitorious.org/freebsd/freebsd.git (svn
http://svn.freebsd.org/base/stable/8...@214488) fails with
 cc -O2 -pipe -DIN_GCC -DHAVE_CONFIG_H 
 -DPREFIX=\/usr/obj/amd64/usr/src/tmp/usr\ -DCROSS_COMPILE 
 -I/usr/obj/amd64/usr/src/tmp/usr /src/gnu/usr.bin/cc/cc/../cc_tools 
 -I/usr/src/gnu/usr.bin/cc/cc/../cc_tools 
 -I/usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc 
 -I/usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/config 
 -I/usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcclibs/include 
 -I/usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcclibs/libcpp/include 
 -I/usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcclibs/libdecnumber 
 -DGCC_DRIVER  -DDEFAULT_TARGET_VERSION=\4.2.1\ 
 -DDEFAULT_TARGET_MACHINE=\amd64-undermydesk-freebsd\ -DENABLE_SHARED_LIBGCC 
   -I/usr/obj/amd64/usr/src/tmp/legacy/usr/include -c 
 /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/gccspec.c
 /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/config/i386/driver-i386.c: 
 In function 'host_detect_local_cpu':
 /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/config/i386/driver-i386.c:96:
  error: impossible constraint in 'asm'
 /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/config/i386/driver-i386.c:103:
  error: impossible constraint in 'asm'
 /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/config/i386/driver-i386.c:113:
  error: impossible constraint in 'asm'
 /usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/config/i386/driver-i386.c:117:
  error: impossible constraint in 'asm'
 {standard input}: Assembler messages:
 {standard input}:92: Error: Unknown opcode: `pushfl'
 {standard input}:92: Error: Unknown opcode: `pushfl'
 {standard input}:92: Error: Unknown opcode: `popl'
 {standard input}:92: Error: Illegal operands
 {standard input}:92: Error: Unknown opcode: `xorl'
 {standard input}:92: Error: Unknown opcode: `pushl'
 {standard input}:92: Error: Unknown opcode: `popfl'
 {standard input}:92: Error: Unknown opcode: `pushfl'
 {standard input}:92: Error: Unknown opcode: `popl'
 {standard input}:92: Error: Unknown opcode: `popfl'
 *** Error code 1
 1 error
 *** Error code 2
 1 error
 *** Error code 2
 1 error
 *** Error code 2
 1 error
 *** Error code 2
 1 error
which looks like it's trying to build some x86 code with the host toolchain,
not the cross tools.

Help? :)
Thanks.
--nwf;


pgpepBs7PJGsV.pgp
Description: PGP signature

Re: safe mode

[Stephen Clark]

On 10/29/2010 03:51 PM, Stephen Clark wrote:

On 10/29/2010 01:40 PM, Jeremy Chadwick wrote:

On Fri, Oct 29, 2010 at 01:12:29PM -0400, Stephen Clark wrote:

On 10/29/2010 12:54 PM, Jeremy Chadwick wrote:

On Fri, Oct 29, 2010 at 11:17:50AM -0400, Stephen Clark wrote:

I am having a problem getting 6.3 to boot on an intel atom mb. When
it gets to where it should identify the drive it hangs.
Can you try 8.1-RELEASE or an 8.1-STABLE snapshot instead?  I mean, 
you

*are* using an Intel Atom system, which contains significantly more
advanced hardware than was available during the RELENG_6 days.

Oh, I think you answer this further down...


If I boot with no acpi it does the same thing.

If I boot with safe mode it comes up and identifies the drive but 
then

starts spewing the following errors:
ipfw2 initialized, divert enabled, rule-based forwarding disabled,
default to ad
interrupt storm detected on irq15:; throttling interrupt source
ad4: 152627MBWDC WD1600BEKT-00A25T0 01.01A01   at ata2-master PIO4
interrupt storm detected on irq15:; throttling interrupt source
interrupt storm detected on irq15:; throttling interrupt source
interrupt storm detected on irq15:; throttling interrupt source

FreeBSD runs but I continue to get these errors:

What exactly does safe mode do - I am afraid my forth skills are not
what they should be.

Safe mode does the following before doing boot:

set hw.ata.ata_dma=0
set hw.ata.atapi_dma=0
set hw.ata.wc=0
set hw.eisa_slots=0
set hint.kbdmux.0.disabled=1

It also does the following if you're booting/running i386:

unset acpi_load
set hint.acpi.0.disabled=1
set loader.acpi_disabled_by_user=1
set hint.apic.0.disabled=1

The code is in /boot/beastie.4th.

IMHO, you shouldn't be disabling ACPI, or using safe mode to try and
get your system working.  Can you please boot Verbose mode instead and
provide all of the output somewhere?  You'll probably need serial
console for this, since the system hangs.



atap...@pci0:0:31:1:class=0x01018a card=0x28508086
chip=0x28508086 rev=0x03 hdr=0x00
 vendor = 'Intel Corporation'
 device = '82801H (ICH8 Family) Ultra ATA Storage 
Controllers'

 class  = mass storage
 subclass   = ATA
atap...@pci0:0:31:2:class=0x01018f card=0x28288086
chip=0x28288086 rev=0x03 hdr=0x00
 vendor = 'Intel Corporation'
 device = 'ICH8M (ICH8 Family) 3 port SATA Controller'
 class  = mass storage
 subclass   = ATA
Your storage controller is an Intel ICH8, which is supported by 
FreeBSD,

but the ATA layer differs greatly between 6.x and 8.x (read: better on
8.x).  AHCI is also well-supported on 8.x if your system/BIOS supports
it.

I am stuck for now on 6.3 so moving to a later release 7+ is not 
feasible.
Can you explain why?  (If I don't ask it, someone else will.)  This 
will

almost certainly be the key to this discussion, especially since you
say:


I am supporting over 700 units in the field that are acting as
firewall/router/vpn devices,
that are running 6.3. It would not be feasible to upgrade them to a
new version of FreeBSD
remotely. Also if I was going to move to a  later release of FreeBSD
for the new hardware
it would involve months  of new testing and validation of the new
release, where putting a patched
6.3 kernel is relatively straightforward.

I'm a little confused.  Did you deploy over 700 field units running
FreeBSD 6.3 without testing it first on this particular piece of
hardware/setup?  Or did you recently upgrade from FreeBSD X.Y to 6.3 and
found that things broke?  What I'm trying to find out is whether or not
these systems ever worked for you, and if so, at what point did they
stop working.
Sorry for the confusion. We have a mix of hardware in the field. The 
current
hardware platform we are shipping is going EOL from the vendor. I am 
testing

the vendors next generation of hardware.

I included at the end a verbose startup using the 6.3 install disc.


  Possibly we can work backwards to figure out what code
change/commit broke things for you.  Keep reading for some ideas.

First question: are you using any parameters in /boot/loader.conf or
/boot.config?  If so, what are they?
   Second question: can you provide your kernel configuration file?

As for the verbose boot -- thanks much.  Appropriate folks should be
here on the list, so if they have ideas they'll probably reply.  A quick
analysis indicates the following:

ata0 --  atapci0 --  Intel ATA controller master, IDE/PATA, IRQ 14
ata1 --  atapci0 --  Intel ATA controller slave,  IDE/PATA, IRQ 14
ata2 --  atapci1 --  Intel ATA controller master, IDE/PATA, IRQ 15
ata3 --  atapci1 --  Intel ATA controller slave,  IDE/PATA, IRQ 15

A single device is found on ata2, but no other devices are found on the
other ATA busses:


ata2: reset tp2 stat0=50 stat1=00 devices=0x1ATA_MASTER

That probably correlates with what you see when you boot safe mode,
since there we see this message:

   ad4: 152627MBWDC WD1600BEKT-00A25T0 01.01A01  

Re: Degraded zpool cannot detach old/bad drive

[Artem Belevich]

On Fri, Oct 29, 2010 at 11:34 AM, Rumen Telbizov telbi...@gmail.com wrote:
 The problem I think comes down to what I have written in the zpool.cache
 file.
 It stores the mfid path instead of the gpt/disk one.
       children[0]
              type='disk'
              id=0
              guid=1641394056824955485
              path='/dev/mfid33p1'
              phys_path='/p...@0,0/pci8086,3...@1c/pci15d9,c...@0/s...@1,0:a'
              whole_disk=0
              DTL=55

Yes, phys_path does look like something that came from solaris.

 Compared to a disk from a partner server which is fine:
       children[0]
              type='disk'
              id=0
              guid=5513814503830705577
              path='/dev/gpt/disk-e1:s6'
              whole_disk=0

If you have old copy of /boot/zfs/zpool.cache you could try use zpool
import -c old-cache-file.

I don't think zpool.cache is needed for import. Import should work
without it just fine. Just remove /boot/zfs/zpool.cache (or move it
somewhere else and then try importing with -d /dev/gpt again.

--Artem
___
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: Degraded zpool cannot detach old/bad drive

[Rumen Telbizov]

Artem,


 If you have old copy of /boot/zfs/zpool.cache you could try use zpool
 import -c old-cache-file.


Unfortunately I don't :(
I'll make a habit of creating a copy from now on!



 I don't think zpool.cache is needed for import. Import should work
 without it just fine. Just remove /boot/zfs/zpool.cache (or move it
 somewhere else and then try importing with -d /dev/gpt again.


You're right. zpool export tank seems to remove the cache file so import has
nothing to consult so doesn't make any difference.

I guess my only chance at this point would be to somehow manually edit
the zpool configuration, via the zpool.cache file or not, and substitute
mfid with gpt/disk?!
Is there a way to do this?

Thanks,
-- 
Rumen Telbizov
http://telbizov.com
___
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: safe mode

[John Baldwin]

On Friday, October 29, 2010 4:20:24 pm Stephen Clark wrote:
  rr232x: RocketRAID 232x controller driver v1.02 (Jan 16 2008 04:16:21)
  hptrr: HPT RocketRAID controller driver v1.1 (Jan 16 2008 04:16:19)
 
 big snip
  lo0: bpf attached
  rr232x: no controller detected.
  hptrr: no controller detected.
  m
 
 Why does FreeBSD think I have a rocket raid controller? This the generic 
 kernel.
 Is there some way disable this from loading?

The hptrr driver is in GENERIC in 6.x and it always prints out the first
message.  You can ignore it.

-- 
John Baldwin
___
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: Cross-build failure on sparc64 for TARGET=amd64

[John Baldwin]

On Friday, October 29, 2010 3:38:50 pm Nathaniel W Filardo wrote:
 Running
  sudo make TARGET_ARCH=amd64 TARGET=amd64 DESTDIR=/usr/x86_64 -j4 
buildworld 

Maybe just set TARGET and not TARGET_ARCH?

-- 
John Baldwin
___
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: safe mode

[John Baldwin]

On Friday, October 29, 2010 11:17:50 am Stephen Clark wrote:
 Hello,
 
 I am having a problem getting 6.3 to boot on an intel atom mb. When it 
 gets to
 where it should identify the drive it hangs.
 
 If I boot with no acpi it does the same thing.
 
 If I boot with safe mode it comes up and identifies the drive but then
 starts spewing the following errors:
 ipfw2 initialized, divert enabled, rule-based forwarding disabled, 
 default to ad
 interrupt storm detected on irq15:; throttling interrupt source
 ad4: 152627MB WDC WD1600BEKT-00A25T0 01.01A01 at ata2-master PIO4
 interrupt storm detected on irq15:; throttling interrupt source
 interrupt storm detected on irq15:; throttling interrupt source
 interrupt storm detected on irq15:; throttling interrupt source

It's odd that you have IRQ15 without a handler.  It also seems that, for 
whatever reason, IRQ15 is set to level trigger, active low (default for PCI) 
instead of edge trigger, active hi (default for ISA).  Would be interesting to 
see a verbose dmesg from a 7.2 boot perhaps.

-- 
John Baldwin
___
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: Cross-build failure on sparc64 for TARGET=amd64

[Rob Farmer]

On Fri, Oct 29, 2010 at 12:38, Nathaniel W Filardo n...@cs.jhu.edu wrote:
 Running
 sudo make TARGET_ARCH=amd64 TARGET=amd64 DESTDIR=/usr/x86_64 -j4 buildworld
 on
 FreeBSD sparcslave.priv.oc.ietfng.org 8.1-STABLE FreeBSD 8.1-STABLE #2 
 r214092=9050e7b-dirty: Thu Oct 21 01:25:54 UTC 2010 
 r...@t@sparcslave.priv.oc.ietfng.org:/usr/obj/usr/src/sys/SLAVKERN  sparc64

I tried this about a year ago - it didn't work then and I suspect it
never has. I'm not sure what the cause is.

In any case, sparc's are almost always a lot slower than just building
natively on amd64 hardware, so you probably aren't going to get people
too excited about fixing it without tracking down the exact problem
and/or sending a patch.

-- 
Rob Farmer
___
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: 8.1-STABLE: zfs and sendfile: problem still exists

[Kostik Belousov]

On Fri, Oct 29, 2010 at 06:22:54PM +0300, Andriy Gapon wrote:
 on 29/10/2010 18:17 Kostik Belousov said the following:
  On Fri, Oct 29, 2010 at 06:05:26PM +0300, Andriy Gapon wrote:
  on 29/10/2010 17:53 Kostik Belousov said the following:
  Could it be the priming of the vm object pages content ?
 
  Sorry, not familiar with this term.
  Do you mean prepopulation of vm object with valid pages?
 
  Due to double-buffering, and (possibly false) optimization to only
 
  What optimization?
  On zfs vnode read, the page from the corresponding vm object is only
  populated with the vnode data if the page already exists in the
  object.
 
 Do you mean a specific type of read?
 For normal reads it's the other way around - if the page already exists and 
 is
 valid, then we read from the page, not from ARC.
Let me repeat it once more:
zfs does not properly caches the vnode data content in the page cache
(the cache is used in a weaker sence, not meaning the freebsd 'cached'
memory, but a cache in more common sence). Not doing the optimization
I mentioned would mean always allocating the pages and making it
(partially) valid for each read call.
 
  Not doing the optimization would be to allocate the page uncoditionally
  on the read if not already present, and copy the data from ARC to the page.
 
  perform double-buffering when vm object already has some data cached,
  reads can prime vm object page list before file is mmapped or
  sendfile-ed.
 
 
  No double-buffering is done to optimize anything. Double-buffering
  is a consequence of having page cache and ARC. The special
  double-buffering code is to just handle that fact - e.g. making
  sure that VOP_READ reads data from page cache instead of ARC if it's
  possible that the data in them differs (i.e. page cache has more
  recent data).
 
  So, if I understood the term 'priming' correctly, no priming should
  ever occur.
  The priming is done on the first call to VOP_READ() with the right
  offset after the page is allocated.
 
 Again, what is priming?
Filling the cache with an appropriate content.


pgpc8DbIfno18.pgp
Description: PGP signature

Re: Degraded zpool cannot detach old/bad drive

[Artem Belevich]

On Fri, Oct 29, 2010 at 2:19 PM, Rumen Telbizov telbi...@gmail.com wrote:
 You're right. zpool export tank seems to remove the cache file so import has
 nothing to consult so doesn't make any difference.
 I guess my only chance at this point would be to somehow manually edit
 the zpool configuration, via the zpool.cache file or not, and substitute
 mfid with gpt/disk?!
 Is there a way to do this?

I'm not aware of any tools to edit zpool.cache.

What's really puzzling is why GPT labels disappear in the middle of
zpool import. I'm fresh out of ideas why that would happen.

What FreeBSD version are you running. SVN revision of the sources
would be good, but date may also work.

--Artem
___
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: Degraded zpool cannot detach old/bad drive

[Rumen Telbizov]

Hi Artem,

What's really puzzling is why GPT labels disappear in the middle of
 zpool import. I'm fresh out of ideas why that would happen.


Thanks for your support anyway. Appreciated.

What FreeBSD version are you running. SVN revision of the sources
 would be good, but date may also work.


FreeBSD 8.1-STABLE #0: Sun Sep  5 00:22:45 PDT 2010

That's when I csuped and rebuilt world/kernel.
I can (and probably will) very easily csup it to the latest stable and try
to upgrade zfs to version
15 which was incorporated shortly after this build. See if that makes any
difference.

I wonder if there's a way to fix it over OpenSolaris LiveCD. Somehow load
the gpt labeled partitions and save
the cache file.

Regards,
-- 
Rumen Telbizov
http://telbizov.com
___
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: Degraded zpool cannot detach old/bad drive

[Artem Belevich]

On Fri, Oct 29, 2010 at 4:42 PM, Rumen Telbizov telbi...@gmail.com wrote:
 FreeBSD 8.1-STABLE #0: Sun Sep  5 00:22:45 PDT 2010
 That's when I csuped and rebuilt world/kernel.

There were a lot of ZFS-related MFCs since then. I'd suggest updating
to the most recent -stable and try again.

I've got another idea that may or may not work. Assuming that GPT
labels disappear because zpool opens one of the /dev/mfid* devices,
you can try to do chmod a-rw /dev/mfid* on them and then try
importing the pool again.

--Artem
___
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: Degraded zpool cannot detach old/bad drive

[Rumen Telbizov]

Thanks Artem,

I'll upgrade to latest stable and zfs 15 tomorrow or Sunday and I'll see if
that makes
it any better. If not I'll also try the chmod operation below.

Thanks for the suggestions. I'll report back here.

Regards,
Rumen Telbizov

On Fri, Oct 29, 2010 at 5:01 PM, Artem Belevich fbsdl...@src.cx wrote:

 On Fri, Oct 29, 2010 at 4:42 PM, Rumen Telbizov telbi...@gmail.com
 wrote:
  FreeBSD 8.1-STABLE #0: Sun Sep  5 00:22:45 PDT 2010
  That's when I csuped and rebuilt world/kernel.

 There were a lot of ZFS-related MFCs since then. I'd suggest updating
 to the most recent -stable and try again.

 I've got another idea that may or may not work. Assuming that GPT
 labels disappear because zpool opens one of the /dev/mfid* devices,
 you can try to do chmod a-rw /dev/mfid* on them and then try
 importing the pool again.

 --Artem




-- 
Rumen Telbizov
http://telbizov.com
___
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: POSIX file permission (understanding) problem?

[jhell]

On 10/25/2010 18:28, Chuck Swiger wrote:
 chmod g+w testdir/ (as superuser, exit again)
 
 
 ls -ld testdir
 
 
 drwxrwx--x  2 nobody  intern  512 25 Okt 23:03 testdir
 ls -l testdir
 total 0
 -rw-r-  1 nobody  intern  0 25 Okt 23:03 testfile
 
  - Now editing with vi (as user harry) changes the ownership of the
 file and writing is successfull:
 ls -l testdir/
 total 2
 -rw-r-  1 harry  intern  5 25 Okt 23:10 testfile
 
   A file in a sticky directory may only be removed or renamed
  by a user if the user has write permission for the directory and the user
  is the owner of the file, the owner of the directory, or the super-user.


Obviously he is not the owner of the file, directory, nor the superuser
in this case so if I am missing something here please forgive me but I
still see a big problem with this

-- 

 jhell,v
___
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: POSIX file permission (understanding) problem?

[jhell]

On 10/29/2010 23:27, jhell wrote:
 On 10/25/2010 18:28, Chuck Swiger wrote:
 chmod g+w testdir/ (as superuser, exit again)


 ls -ld testdir


 drwxrwx--x  2 nobody  intern  512 25 Okt 23:03 testdir
 ls -l testdir
 total 0
 -rw-r-  1 nobody  intern  0 25 Okt 23:03 testfile

 - Now editing with vi (as user harry) changes the ownership of the
 file and writing is successfull:
 ls -l testdir/
 total 2
 -rw-r-  1 harry  intern  5 25 Okt 23:10 testfile

   A file in a sticky directory may only be removed or renamed
  by a user if the user has write permission for the directory and the 
 user
  is the owner of the file, the owner of the directory, or the super-user.
 
 
 Obviously he is not the owner of the file, directory, nor the superuser
 in this case so if I am missing something here please forgive me but I
 still see a big problem with this
 

Never mind... forhot the chmod g+w.

-- 

 jhell,v
___
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