From owner-freebsd-stable@FreeBSD.ORG Sun Jun 19 06:08:44 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E1407106566B for ; Sun, 19 Jun 2011 06:08:43 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by mx1.freebsd.org (Postfix) with ESMTP id 9FBFB8FC1A for ; Sun, 19 Jun 2011 06:08:43 +0000 (UTC) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta05.westchester.pa.mail.comcast.net with comcast id xi7h1g0021YDfWL55i8jB2; Sun, 19 Jun 2011 06:08:43 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta20.westchester.pa.mail.comcast.net with comcast id xi8i1g0091t3BNj3gi8iZF; Sun, 19 Jun 2011 06:08:43 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id C10EC102C36; Sat, 18 Jun 2011 23:08:40 -0700 (PDT) Date: Sat, 18 Jun 2011 23:08:40 -0700 From: Jeremy Chadwick To: Stefan `Sec` Zehl Message-ID: <20110619060840.GA29087@icarus.home.lan> References: <20110616185951.GA88009@testsoekris.hotsoft.nl> <20110616201516.GA90053@icarus.home.lan> <20110618201431.GA30902@ice.42.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110618201431.GA30902@ice.42.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@freebsd.org Subject: Re: csh Cannot open /etc/termcap after starting "screen" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jun 2011 06:08:44 -0000 On Sat, Jun 18, 2011 at 10:14:32PM +0200, Stefan `Sec` Zehl wrote: > Hi, > > On Thu, Jun 16, 2011 at 13:15 -0700, Jeremy Chadwick wrote: > > Example: run mutt from within GNU screen while connected to > > the system with PuTTY, then copy some of the terminal content and paste > > it somewhere. Wow, look at all those extraneous spaces at the end of > > lines, which you now gloriously have to manually remove. > > While I don't want to stand in the way of your rant, this is actually a > bug/problem of mutt. -- mutt is really printing spaces there, so it is > (IMHO) correct that copy&paste copies spaces. mutt is not printing spaces. GNU screen is doing it, and I'm going to show you hard evidence of it. I've done this analysis many times over the years, so doing it once again won't hurt. It never ceases to amaze me how GNU screen advocates "insist it's a problem with " when that simply isn't the case. Let's take a look at *exactly* what mutt is sending to stdout (fd 1) in a terminal that's 132x43 in size, using TERM=xterm, thus without GNU screen. PuTTY is my terminal emulator. We're looking at the I/O that comes across fd 1 (stdout) from mutt. mutt on this system is build with ncurses (base system version, not ports) The test procedure: ktrace -ti /usr/local/bin/mutt -f =spam kdump | less Firstly, a screen shot of what shows up in PuTTY, just so you have some visual context: http://www.malkavian.com/~jdc/mutt.png And across stdout, here's what we see: 29053 mutt GIO fd 1 wrote 340 bytes 0x0000 0d1b 5b33 376d 1b5b 4a1b 5b48 1b5b 3337 6d1b 5b34 346d 1b5b 316d 2d2d 2d4d 7574 |..[37m.[J.[H.[37m.[44m.[1m---Mut| 0x0020 743a 203d 7370 616d 205b 4d73 6773 3a31 204e 6577 3a31 2049 6e63 3a33 2032 2e38 |t: =spam [Msgs:1 New:1 Inc:3 2.8| 0x0040 4b5d 2d2d 2d28 7468 7265 6164 732f 6461 7465 292d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d |K]---(threads/date)-------------| 0x0060 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d |--------------------------------| 0x0080 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2861 6c6c 292d 2d2d 1b5b |----------------------(all)---.[| 0x00a0 323b 3148 1b5b 3337 6d1b 5b34 366d 2020 2031 204e 202b 2030 362f 3138 2031 363a |2;1H.[37m.[46m 1 N + 06/18 16:| 0x00c0 3436 2020 4f72 6465 7220 4e6f 7469 6669 6572 2020 2020 2020 2830 2e34 4b29 205b |46 Order Notifier (0.4K) [| 0x00e0 7370 616d 5d20 4865 6c6c 6f1b 5b4b 0d1b 5b34 3042 1b5b 3337 6d1b 5b34 346d 713a |spam] Hello.[K..[40B.[37m.[44mq:| 0x0100 5175 6974 2020 643a 4465 6c20 2075 3a55 6e64 656c 2020 733a 5361 7665 2020 6d3a |Quit d:Del u:Undel s:Save m:| 0x0120 4d61 696c 2020 723a 5265 706c 7920 2067 3a47 726f 7570 2020 3f3a 4865 6c70 1b5b |Mail r:Reply g:Group ?:Help.[| 0x0140 4b1b 5b32 3b31 3332 481b 5b33 393b 3439 6d1b 5b6d |K.[2;132H.[39;49m.[m| Here's the xterm escape sequence decoding chart -- we'll be caring about [ a lot, which is referred to as "CSI" in the docs. http://invisible-island.net/xterm/ctlseqs/ctlseqs.html Let's decode the above output and turn it into something human-readable: [37m = set foreground text colour to white [J = clear from cursor to end of terminal [H = move cursor to top left corner of terminal [37m = set foreground text colour to white [44m = set background colour to blue [1m = turn on bold/bright ---Mutt: =spam [Msgs:1 New:1 Inc:3 2.8K]---(threads/date)-------------------------------------------------------------------(all)--- [2;1H = move cursor to row 2 column 1 [37m = set foreground text colour to white [46m = set background colour to cyan 1 N + 06/18 16:46 Order Notifier (0.4K) [spam] Hello [K = erase from cursor position to end of line [40B = move cursor 40 lines downward [37m = set foreground text colour to white [44m = set background colour to blue q:Quit d:Del u:Undel s:Save m:Mail r:Reply g:Group ?:Help [K = erase from cursor position to end of line [2;132H = move cursor to row 2, column 132 [39;49m = set foreground text colour and background to default [m = turn off bold/bright Given this analysis, we can see where GNU screen is making some stupid assumptions. Let's focus on the part that's causing the nonsense: 1 N + 06/18 16:46 Order Notifier (0.4K) [spam] Hello ^ cursor is now here --------^ This is followed by [K, which is used to erase all content from the cursor position to the end of the line. "Erase all content" does not mean "print spaces" -- you can see quite clearly in the I/O to stdout that no "padding spaces" are printed. It's a terminal escape sequence which is interpreted by xterm (PuTTY in my case) to do what it's told. It's important to note that the foreground colour at this point is set to bolded white (not the default), and the background colour is set to cyan (not the default). An erase-line command in this situation results in something called BCE -- you know, the thing I talked about in my mail that you responded to? Please read about it: http://invisible-island.net/xterm/xterm.faq.html#xterm_terminfo Like I said in my mail, GNU screen does stupid things when it comes to BCE. It seems to think that because from-cursor-to-EOL is being erased with a non-default background colour, that that means "hey I better 'emulate' this by printing spaces". And I'm about to show you that's completely the case. Let's run the exact same test procedure but within GNU screen. This is stock GNU screen; literally I just installed it from ports, ran it, then ran the same test procedure. Once in screen, TERM=screen (obviously). Lo and behold, what do we see? 32547 mutt GIO fd 1 wrote 495 bytes 0x0000 1b5b 481b 5b33 376d 1b5b 3434 6d1b 5b31 6d2d 2d2d 4d75 7474 3a20 3d73 7061 6d20 |.[H.[37m.[44m.[1m---Mutt: =spam | 0x0020 5b4d 7367 733a 3120 4e65 773a 3120 496e 633a 3320 322e 384b 5d2d 2d2d 2874 6872 |[Msgs:1 New:1 Inc:3 2.8K]---(thr| 0x0040 6561 6473 2f64 6174 6529 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d |eads/date)----------------------| 0x0060 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d |--------------------------------| 0x0080 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d28 616c 6c29 2d2d 2d1b 5b32 3b31 481b 5b33 376d |-------------(all)---.[2;1H.[37m| 0x00a0 1b5b 3436 6d20 2020 3120 4e20 2b20 3036 2f31 3820 3136 3a34 3620 204f 7264 6572 |.[46m 1 N + 06/18 16:46 Order| 0x00c0 204e 6f74 6966 6965 7220 2020 2020 2028 302e 344b 2920 5b73 7061 6d5d 2048 656c | Notifier (0.4K) [spam] Hel| 0x00e0 6c6f 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 |lo | 0x0100 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 | | 0x0120 2020 2020 2020 2020 201b 5b34 323b 3148 1b5b 3337 6d1b 5b34 346d 713a 5175 6974 | .[42;1H.[37m.[44mq:Quit| 0x0140 2020 643a 4465 6c20 2075 3a55 6e64 656c 2020 733a 5361 7665 2020 6d3a 4d61 696c | d:Del u:Undel s:Save m:Mail| 0x0160 2020 723a 5265 706c 7920 2067 3a47 726f 7570 2020 3f3a 4865 6c70 2020 2020 2020 | r:Reply g:Group ?:Help | 0x0180 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 | | 0x01a0 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 1b5b | .[| 0x01c0 3433 3b31 481b 5b6d 1b5b 3337 6d20 2020 2020 2020 2020 2020 2020 2020 2020 201b |43;1H.[m.[37m .| 0x01e0 5b32 3b31 3332 481b 5b33 396d 1b5b 6d |[2;132H.[39m.[m| Look at all those spaces to fill the entire width of the terminal window. I don't even need to do the analysis, it's quite obvious what's going on. I also want to point out "defbce on" in .screenrc also did not solve this problem; the output is the exact same as you see in the above text (extraneous spaces). Why does this happen? Like I said in my previous mail: GNU screen tries to **convert** between terminal types (xterm <--> screen in this case). This concept of GNU screen stems from environments where you had an administrator wanting a "consistent terminal" regardless of what actual **attached** terminal type he was using. For example, admin is on a Linux console (TERM=cons25), runs screen, uses things for a while, then detaches. He walks across the building into the datacenter, and needs to start working on something local to the servers. The only terminal he has in the datacenter is, say, a real DEC VT100. He can connect to whatever, run "screen -r", and he'll still (generally) "see" the same output he did before he detached (sans colour and all that of course). tmux doesn't behave this way. It doesn't try to do "terminal emulation" or "terminal translation". The idea there is that people are probably using, consistently, the same terminal software (PuTTY, xterm, rxvt, etc.) rather than moving between terminal types often. The above analysis/details speak for themselves. As such, please do not tell me "mutt is causing this problem" -- as I said in the beginning, GNU screen is causing the problem. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Sun Jun 19 06:21:30 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2ADED106566C for ; Sun, 19 Jun 2011 06:21:30 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [76.96.59.211]) by mx1.freebsd.org (Postfix) with ESMTP id C81AB8FC13 for ; Sun, 19 Jun 2011 06:21:29 +0000 (UTC) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by QMTA11.westchester.pa.mail.comcast.net with comcast id xiLn1g00127AodY5BiMWY6; Sun, 19 Jun 2011 06:21:30 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta19.westchester.pa.mail.comcast.net with comcast id xiMU1g00Y1t3BNj3fiMVdV; Sun, 19 Jun 2011 06:21:30 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 820AC102C36; Sat, 18 Jun 2011 23:21:27 -0700 (PDT) Date: Sat, 18 Jun 2011 23:21:27 -0700 From: Jeremy Chadwick To: Kostik Belousov Message-ID: <20110619062127.GA35793@icarus.home.lan> References: <20110616185951.GA88009@testsoekris.hotsoft.nl> <20110616201516.GA90053@icarus.home.lan> <20110618201431.GA30902@ice.42.org> <20110618203707.GY48734@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110618203707.GY48734@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@freebsd.org, Stefan `Sec` Zehl Subject: Re: csh Cannot open /etc/termcap after starting "screen" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jun 2011 06:21:30 -0000 On Sat, Jun 18, 2011 at 11:37:07PM +0300, Kostik Belousov wrote: > On Sat, Jun 18, 2011 at 10:14:32PM +0200, Stefan `Sec` Zehl wrote: > > Hi, > > > > On Thu, Jun 16, 2011 at 13:15 -0700, Jeremy Chadwick wrote: > > > Example: run mutt from within GNU screen while connected to > > > the system with PuTTY, then copy some of the terminal content and paste > > > it somewhere. Wow, look at all those extraneous spaces at the end of > > > lines, which you now gloriously have to manually remove. > > > > While I don't want to stand in the way of your rant, this is actually a > > bug/problem of mutt. -- mutt is really printing spaces there, so it is > > (IMHO) correct that copy&paste copies spaces. > > It is the case of the default termcap entry for the screen. > Try "TERM=screen-bce mutt". Which is in no way acceptable given these kinds of visual results: http://www.malkavian.com/~jdc/mutt-screen-bce.png Though what comes across stdout is a lot more reasonable (no padding): 35745 mutt GIO fd 1 wrote 340 bytes 0x0000 0d1b 5b33 376d 1b5b 4a1b 5b48 1b5b 3337 6d1b 5b34 346d 1b5b 316d 2d2d 2d4d 7574 |..[37m.[J.[H.[37m.[44m.[1m---Mut| 0x0020 743a 203d 7370 616d 205b 4d73 6773 3a31 204e 6577 3a31 2032 2e38 4b5d 2d2d 2d28 |t: =spam [Msgs:1 New:1 2.8K]---(| 0x0040 7468 7265 6164 732f 6461 7465 292d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d |threads/date)-------------------| 0x0060 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d |--------------------------------| 0x0080 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2861 6c6c 292d 2d2d 1b5b |----------------------(all)---.[| 0x00a0 323b 3148 1b5b 3337 6d1b 5b34 366d 2020 2031 204e 202b 2030 362f 3138 2031 363a |2;1H.[37m.[46m 1 N + 06/18 16:| 0x00c0 3436 2020 4f72 6465 7220 4e6f 7469 6669 6572 2020 2020 2020 2830 2e34 4b29 205b |46 Order Notifier (0.4K) [| 0x00e0 7370 616d 5d20 4865 6c6c 6f1b 5b4b 0d1b 5b34 3042 1b5b 3337 6d1b 5b34 346d 713a |spam] Hello.[K..[40B.[37m.[44mq:| 0x0100 5175 6974 2020 643a 4465 6c20 2075 3a55 6e64 656c 2020 733a 5361 7665 2020 6d3a |Quit d:Del u:Undel s:Save m:| 0x0120 4d61 696c 2020 723a 5265 706c 7920 2067 3a47 726f 7570 2020 3f3a 4865 6c70 1b5b |Mail r:Reply g:Group ?:Help.[| 0x0140 4b1b 5b32 3b31 3332 481b 5b33 393b 3439 6d1b 5b6d |K.[2;132H.[39;49m.[m| So what happens if one puts "defbce on" in .screenrc and uses TERM=screen-bce? Padded spaces: 35849 mutt GIO fd 1 wrote 495 bytes 0x0000 1b5b 481b 5b33 376d 1b5b 3434 6d1b 5b31 6d2d 2d2d 4d75 7474 3a20 3d73 7061 6d20 |.[H.[37m.[44m.[1m---Mutt: =spam | 0x0020 5b4d 7367 733a 3120 4e65 773a 3120 496e 633a 3120 322e 384b 5d2d 2d2d 2874 6872 |[Msgs:1 New:1 Inc:1 2.8K]---(thr| 0x0040 6561 6473 2f64 6174 6529 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d |eads/date)----------------------| 0x0060 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d |--------------------------------| 0x0080 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d28 616c 6c29 2d2d 2d1b 5b32 3b31 481b 5b33 376d |-------------(all)---.[2;1H.[37m| 0x00a0 1b5b 3436 6d20 2020 3120 4e20 2b20 3036 2f31 3820 3136 3a34 3620 204f 7264 6572 |.[46m 1 N + 06/18 16:46 Order| 0x00c0 204e 6f74 6966 6965 7220 2020 2020 2028 302e 344b 2920 5b73 7061 6d5d 2048 656c | Notifier (0.4K) [spam] Hel| 0x00e0 6c6f 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 |lo | 0x0100 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 | | 0x0120 2020 2020 2020 2020 201b 5b34 323b 3148 1b5b 3337 6d1b 5b34 346d 713a 5175 6974 | .[42;1H.[37m.[44mq:Quit| 0x0140 2020 643a 4465 6c20 2075 3a55 6e64 656c 2020 733a 5361 7665 2020 6d3a 4d61 696c | d:Del u:Undel s:Save m:Mail| 0x0160 2020 723a 5265 706c 7920 2067 3a47 726f 7570 2020 3f3a 4865 6c70 2020 2020 2020 | r:Reply g:Group ?:Help | 0x0180 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 | | 0x01a0 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 1b5b | .[| 0x01c0 3433 3b31 481b 5b6d 1b5b 3337 6d20 2020 2020 2020 2020 2020 2020 2020 2020 201b |43;1H.[m.[37m .| 0x01e0 5b32 3b31 3332 481b 5b33 396d 1b5b 6d |[2;132H.[39m.[m| -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Sun Jun 19 07:15:30 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 10B82106566B; Sun, 19 Jun 2011 07:15:30 +0000 (UTC) (envelope-from christer.solskogen@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 794938FC13; Sun, 19 Jun 2011 07:15:29 +0000 (UTC) Received: by vxg33 with SMTP id 33so49241vxg.13 for ; Sun, 19 Jun 2011 00:15:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=au8+6bbu0lc96AzDCV+vM+0OkmfvOu0bvKewrxYu2CQ=; b=Wftqj9J8z2kcIzFDf8nuv77+dv3bt7BBb1/G/ysiAJYbMx+M+celCngW4X5Q1Mj33p fnreE/VqPPtzdWwUc7GyMvXtKlWE0tKF+F2f10t3UyTSKokPvTbUMPcbjkI0X/tHSOdM 6nBTPNJ5owi11ven2lOwO8F4oCNZx85I4oQwE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=aOMaI/IcovnMYKtuIl+5v6zjQLRDBpu6fnMMWkg2Birukgsaa/gBlON7CBJXo12OWU 4iGKhYrykh0AHPd7sgQ7n0pz1winDo3TMWqrCMZCaRDyoXO5GDLrJd5ZSH055r2C4nHt AHMlKxpLpDfZsc1J7pryw0P5VbNPv1+oY30q8= Received: by 10.52.112.131 with SMTP id iq3mr642762vdb.118.1308465850172; Sat, 18 Jun 2011 23:44:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.185.226 with HTTP; Sat, 18 Jun 2011 23:43:50 -0700 (PDT) In-Reply-To: <20110618012257.GA84652@icarus.home.lan> References: <20110618012257.GA84652@icarus.home.lan> From: Christer Solskogen Date: Sun, 19 Jun 2011 08:43:50 +0200 Message-ID: To: Jeremy Chadwick Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-stable@freebsd.org, nwhitehorn@freebsd.org, kensmith@freebsd.org, mm@freebsd.org Subject: Re: Building your own FreeBSD USB memstick image X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jun 2011 07:15:30 -0000 On Sat, Jun 18, 2011 at 3:22 AM, Jeremy Chadwick wrote: > Is the procedure for creating new FreeBSD memstick images documented > anywhere? > I'm not sure if its documented but this is how I do it: (edit /etc/make.conf and /etc/src.conf if necessary) make buildworld && make buildkernel Insert usb stick fdisk -BI /dev/da0 bsdlabel -B -w da0s1 newfs -U /dev/da0s1a mount /dev/ad0s1a /mnt make installworld installkernel distribution DESTDIR=/mnt Edit /mnt/etc/fstab /dev/da0s1a / ufs rw 1 1 Edit /mnt/etc/rc.conf for your needs unmount /mnt :-) -- chs, From owner-freebsd-stable@FreeBSD.ORG Mon Jun 20 09:17:38 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E5AF7106566B for ; Mon, 20 Jun 2011 09:17:38 +0000 (UTC) (envelope-from nickolasbug@gmail.com) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id A45DB8FC0A for ; Mon, 20 Jun 2011 09:17:38 +0000 (UTC) Received: by qyk30 with SMTP id 30so1501046qyk.13 for ; Mon, 20 Jun 2011 02:17:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=uawwHyniJ9tmaLihJlrRXN2N6O1sp7DL6YxOoQzXpp0=; b=pvA8nPJpIEBPTBAst8Krc+3fVfsMtHfJBBFBazmRqpNQyBYZZfnXjG1+JHpoMcssti QpbpMcHqm0zLWarJVykFD98MYBpZ1+SrKAtwhUh2fZoZlrCdGfF20ypmtTFGvTTArs0M W5L9g4KnQCb1+clXtXcGRr9dM5o0hBEwq3giw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=EAGgJetRKvkzJznwuKlPSQqIR8MpWHMIOtZBlOb1f/eX4Zt+ZNADBpHDOVz970odVF cBHTVcPMi+zaGZIoPI6iXPp8LRrmbrjS67ekl2jkH/+OJO26kH64uhZUj2e0hw1u1wqH /9/z9O9JHJfDOgB4d6HN0Oi+Xw1ee7Rd2J3mI= MIME-Version: 1.0 Received: by 10.229.25.211 with SMTP id a19mr3795071qcc.81.1308561457854; Mon, 20 Jun 2011 02:17:37 -0700 (PDT) Received: by 10.229.82.65 with HTTP; Mon, 20 Jun 2011 02:17:37 -0700 (PDT) Date: Mon, 20 Jun 2011 12:17:37 +0300 Message-ID: From: nickolasbug@gmail.com To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: GPT labels and gjournal X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 09:17:39 -0000 Hello stable. I've tried to make two journaled partitions on new GPT disk. Partitions have GPT labels storage and backup: gpart show -l ada1 => 34 2930277101 ada1 GPT (1.4T) 34 8388608 1 (null) (4.0G) 8388642 2415919104 2 storage (1.1T) 2424307746 8388608 3 (null) (4.0G) 2432696354 497580781 4 backup (237G) gjournal label /dev/gpt/storage /dev/gptid/3570dff6-9a73-11e0-ad0e-001e8c0ecc19 gjournal label /dev/gpt/backup /dev/gptid/58db2577-9a73-11e0-ad0e-001e8c0ecc19 newfs -J /dev/gpt/storage.journal newfs -J /dev/gpt/backup.journal Where 3570dff6-9a73-11e0-ad0e-001e8c0ecc19 is GPT UUID of ada1p1 and 58db2577-9a73-11e0-ad0e-001e8c0ecc19 is GPT UUID of ada1p3 partition. This partitions have been added to fstab: /dev/gpt/storage.journal /mnt/storage ufs async,rw 0 0 /dev/gpt/backup.journal /mnt/backup ufs async,rw 0 0 After reboot system doesn't wanna see gpt-labeled partitions /dev/gpt/storage.journal and /dev/gpt/backup.journal (so, mount fails) but has /dev/ada1p2.journal and /dev/ada1p4.journal instead. How can I mount this partitions using GPT labels? uname -a FreeBSD cloud 8.2-STABLE FreeBSD 8.2-STABLE #37 r223311: Mon Jun 20 04:16:22 EEST 2011 root@cloud:/usr/obj/usr/src/sys/CLOUD amd64 Options GEOM_PART_GPT, GEOM_LABEL and GEOM_JOURNAL present in kernel configuration file. ------- wbr, Nickolas From owner-freebsd-stable@FreeBSD.ORG Mon Jun 20 09:41:31 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1E22E106564A for ; Mon, 20 Jun 2011 09:41:31 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward3.mail.yandex.net (forward3.mail.yandex.net [77.88.46.8]) by mx1.freebsd.org (Postfix) with ESMTP id BA2328FC12 for ; Mon, 20 Jun 2011 09:41:30 +0000 (UTC) Received: from smtp4.mail.yandex.net (smtp4.mail.yandex.net [77.88.46.104]) by forward3.mail.yandex.net (Yandex) with ESMTP id BD9A8B42EC6; Mon, 20 Jun 2011 13:41:28 +0400 (MSD) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1308562888; bh=s2oJm6seVh06p9Ev/qI0Bg5hpJ/dcSl34SCaDvcyNe4=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type; b=h+ks5n80C0lmA6Df1itNa8oMgAnHFbowBxUDstHh5dVndlBTVDFX1bYhjI4Hpc4q4 qCPBKS0qEGSDqNvP17x91xE++Ed3qG1SVRJNdEzJuGPdGWluC8CudcnQ9VyaHE9ClY ZHU1Zl4l2ge+EpofHcrkvM73afjDoOLqymRTktX4= Received: from [127.0.0.1] (proxy.kirov.so-cdu.ru [77.72.136.146]) by smtp4.mail.yandex.net (Yandex) with ESMTPSA id 6BE2164980BE; Mon, 20 Jun 2011 13:41:28 +0400 (MSD) Message-ID: <4DFF15B5.8000207@yandex.ru> Date: Mon, 20 Jun 2011 13:41:09 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla Thunderbird 1.5 (FreeBSD/20051231) MIME-Version: 1.0 To: nickolasbug@gmail.com References: In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig36CBF95B62F6B2C2BB857952" X-Yandex-Spam: 1 Cc: freebsd-stable@freebsd.org Subject: Re: GPT labels and gjournal X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 09:41:31 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig36CBF95B62F6B2C2BB857952 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable On 20.06.2011 13:17, nickolasbug@gmail.com wrote: > How can I mount this partitions using GPT labels? Hi, i think the only way to do it is use hardcoded provider name when you are configuring journal. --=20 WBR, Andrey V. Elsukov --------------enig36CBF95B62F6B2C2BB857952 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) iQEcBAEBAgAGBQJN/xW7AAoJEAHF6gQQyKF6iS8IAI6icx6P1LwI00/CWFroawqc 07OflzedeKuNLZcDiy4YztYR2nf4hglbpJr6WyAZQ5Ubu04datPpEigRIa47FHfE a4qSYbUuQffWRRuIFY0oDToajDi8JyaDoXRTjo8R4Xuwo3BXwjA49ZvbA3gTJMpW /vMTVUw+Q4/D/K/UYgI2TjDRVjluq1BRvQH4ewTM2LfLoVYfpnGFHTe4bN7SOHbm YHFc2j6E3wn151tFjxMHmW2hZ4x8hfi7Wd/VdVh1gOxlk+7IrqaaARgejbWCF1AN KkzslK4HmFpnhBalqxiiTANKt7e9bmTr2kfX8D1LzRx/n1kLqdzIyPhNMhbzaZQ= =xCOh -----END PGP SIGNATURE----- --------------enig36CBF95B62F6B2C2BB857952-- From owner-freebsd-stable@FreeBSD.ORG Mon Jun 20 10:10:01 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E6AC2106564A for ; Mon, 20 Jun 2011 10:10:01 +0000 (UTC) (envelope-from amarat@ksu.ru) Received: from webmail.hitv.ru (mail.hitv.ru [217.66.16.37]) by mx1.freebsd.org (Postfix) with ESMTP id 232E58FC0A for ; Mon, 20 Jun 2011 10:10:00 +0000 (UTC) Received: from webmail.hitv.ru (localhost [127.0.0.1]) by webmail.hitv.ru (Postfix) with ESMTP id 0EAD74AC120; Mon, 20 Jun 2011 13:51:26 +0400 (MSD) Received: from zealot.ksu.ru (zealot.hitv.ru [83.151.8.230]) by webmail.hitv.ru (Postfix) with ESMTP id C56BE4AC100; Mon, 20 Jun 2011 13:51:25 +0400 (MSD) Received: from zealot.ksu.ru (localhost.lnet [127.0.0.1]) by zealot.ksu.ru (8.14.4/8.14.4) with ESMTP id p5K9qkW5061961; Mon, 20 Jun 2011 13:52:46 +0400 (MSD) (envelope-from amarat@ksu.ru) Message-ID: <4DFF186E.50209@ksu.ru> Date: Mon, 20 Jun 2011 13:52:46 +0400 From: "Marat N.Afanasyev" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:2.0.1) Gecko/20110611 Firefox/4.0.1 SeaMonkey/2.1 MIME-Version: 1.0 To: nickolasbug@gmail.com References: In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060000030201060005090607" X-Virus-Scanned: ClamAV using ClamSMTP X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: GPT labels and gjournal X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 10:10:02 -0000 This is a cryptographically signed message in MIME format. --------------ms060000030201060005090607 Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: quoted-printable nickolasbug@gmail.com wrote: > Hello stable. > > > I've tried to make two journaled partitions on new GPT disk. > Partitions have GPT labels storage and backup: > > gpart show -l ada1 > =3D> 34 2930277101 ada1 GPT (1.4T) > 34 8388608 1 (null) (4.0G) > 8388642 2415919104 2 storage (1.1T) > 2424307746 8388608 3 (null) (4.0G) > 2432696354 497580781 4 backup (237G) > > > gjournal label /dev/gpt/storage /dev/gptid/3570dff6-9a73-11e0-ad0e-001e= 8c0ecc19 > gjournal label /dev/gpt/backup /dev/gptid/58db2577-9a73-11e0-ad0e-001e8= c0ecc19 > > newfs -J /dev/gpt/storage.journal > newfs -J /dev/gpt/backup.journal > > Where 3570dff6-9a73-11e0-ad0e-001e8c0ecc19 is GPT UUID of ada1p1 and > 58db2577-9a73-11e0-ad0e-001e8c0ecc19 is GPT UUID of ada1p3 partition. > > > This partitions have been added to fstab: > > /dev/gpt/storage.journal /mnt/storage ufs async,rw 0 0 > /dev/gpt/backup.journal /mnt/backup ufs async,rw 0 0 > > > After reboot system doesn't wanna see gpt-labeled partitions > /dev/gpt/storage.journal and /dev/gpt/backup.journal (so, mount fails) > but has /dev/ada1p2.journal and /dev/ada1p4.journal instead. > > > How can I mount this partitions using GPT labels? > > > uname -a > FreeBSD cloud 8.2-STABLE FreeBSD 8.2-STABLE #37 r223311: Mon Jun 20 > 04:16:22 EEST 2011 root@cloud:/usr/obj/usr/src/sys/CLOUD amd64 > > > Options GEOM_PART_GPT, GEOM_LABEL and GEOM_JOURNAL present in kernel > configuration file. > > > ------- > wbr, > Nickolas > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.or= g" > i think it would be more useful to: add labels into UFS, e.g. #umount /mnt/storage #umount /mnt/backup #tunefs -L storage /dev/ada1p2.journal #tunefs -L backup /dev/ada1p4.journal and mount /dev/ufs/storage and /dev/ufs/backup into /mnt/storage and /mnt/backup respectively --=20 =F3 =D5=D7=C1=D6=C5=CE=C9=C5=CD, =ED=C1=D2=C1=D4 =E1=C6=C1=CE=C1=D3=D8=C5= =D7 --------------ms060000030201060005090607-- From owner-freebsd-stable@FreeBSD.ORG Mon Jun 20 13:51:49 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5C198106566C for ; Mon, 20 Jun 2011 13:51:49 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 315F48FC1D for ; Mon, 20 Jun 2011 13:51:49 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id D02D146B0D; Mon, 20 Jun 2011 09:51:48 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 62F798A02A; Mon, 20 Jun 2011 09:51:48 -0400 (EDT) From: John Baldwin To: Henri Hennebert Date: Mon, 20 Jun 2011 09:51:47 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110325; KDE/4.5.5; amd64; ; ) References: <201106171337.39104.jhb@freebsd.org> <4DFC6A07.7090607@restart.be> In-Reply-To: <4DFC6A07.7090607@restart.be> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201106200951.47449.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Mon, 20 Jun 2011 09:51:48 -0400 (EDT) Cc: freebsd-stable@freebsd.org Subject: Re: ZFS boot inside on the second partition inside a slice X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 13:51:49 -0000 On Saturday, June 18, 2011 5:04:07 am Henri Hennebert wrote: > On 06/17/2011 19:37, John Baldwin wrote: > > On Friday, June 17, 2011 1:06:22 pm Henri Hennebert wrote: > >> On 06/16/2011 19:35, John Baldwin wrote: > >>> On Thursday, June 16, 2011 8:45:41 am Zhihao Yuan wrote: > >>>> Exactly. The MFCed ZFSv28 is different from any patch maintained by > >>>> mm@. Maybe some untested changes involved. > >>> > >>> Can you try reverting this change: > >>> > >>> Author: jhb > >>> Date: Thu Apr 28 17:44:24 2011 > >>> New Revision: 221177 > >>> URL: http://svn.freebsd.org/changeset/base/221177 > >>> > >>> Log: > >>> Due to space constraints, the UFS boot2 and boot1 use an evil hack where > >>> boot2 calls back into boot1 to perform disk reads. The ZFS MBR boot blocks > >>> do not have the same space constraints, so remove this hack for ZFS. > >>> While here, remove commented out code to support C/H/S addressing from > >>> zfsldr. The ZFS and GPT bootstraps always just use EDD LBA addressing. > >>> > >>> MFC after: 2 weeks > >>> > >>> Modified: > >>> head/sys/boot/i386/boot2/Makefile > >>> head/sys/boot/i386/common/drv.c > >>> head/sys/boot/i386/zfsboot/Makefile > >>> head/sys/boot/i386/zfsboot/zfsldr.S > >>> > >> I try with this revision (221177) reverted to no avail: > >> same error - 'read error' > > > > Hmm, ok. No other ideas off the top of my head. > > > I make the same test under virtualbox and get: > > A critical error has occurred while running the virtual machine and the > machine execution has been stopped. > > I attach VBox.log. > > PS - the message 'ZFS: supported version 28' comes from my patch: > > Index: sys/boot/zfs/zfsimpl.c > =================================================================== > --- sys/boot/zfs/zfsimpl.c (revision 212549) > +++ sys/boot/zfs/zfsimpl.c (working copy) > @@ -61,6 +61,8 @@ > STAILQ_INIT(&zfs_vdevs); > STAILQ_INIT(&zfs_pools); > > + printf("ZFS: supported version %u\n", (unsigned) SPA_VERSION); > + > zfs_temp_buf = malloc(TEMP_SIZE); > zfs_temp_end = zfs_temp_buf + TEMP_SIZE; > zfs_temp_ptr = zfs_temp_buf; Hmm, can you add printfs and narrow down where the hang happens (or which reads are failing)? The VBOX log seems to make no sense. It shows the CPU trying to call into the BIOS from within protected mode in the loader but that shouldn't ever happen (note a cs of 0x2b (which is the loader's %cs selector) but an eip that looks like a cs:ip of a BIOS routine). -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Mon Jun 20 15:38:07 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F034F106566C; Mon, 20 Jun 2011 15:38:06 +0000 (UTC) (envelope-from demelier.david@gmail.com) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by mx1.freebsd.org (Postfix) with ESMTP id 2957B8FC12; Mon, 20 Jun 2011 15:38:05 +0000 (UTC) Received: by wwg11 with SMTP id 11so2318286wwg.1 for ; Mon, 20 Jun 2011 08:38:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=r+jmy10/43guYfIkyfSxzTHjB66JubchveKTWBn9vqg=; b=Ml/m7lvzSuQaXpkMeHbO809CVlMVL6Gs5VzafItxJCaCd7s0CX32Rfbqc7qmqkyWSF tQufgpH2Xxp5ZHWUEpbwcHGeWp3jMpMHDHXNEHBaCF25VLTVRvpWNNpFegw9Vs43I7wV CGXwp4OvC5am31S4GCjyZhh5YLVhZLYnSX3ys= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=wDL0iGVHExu2uDe5C6WXVBGwZh4uDjUiwjHkuVaxXNNjCElpuNs+XBiF6LkhdOTRLm hwr9KrgN+IWq83xmuTgmKvKGzEKrsHWw0cSQeo9pybLzpqdRGXjMo3EO28iNq/jkJDQM 1TcZliEwNa7fdftSFdX+TJWtW9dJIFYGEmkFs= Received: by 10.227.162.129 with SMTP id v1mr802841wbx.63.1308584284767; Mon, 20 Jun 2011 08:38:04 -0700 (PDT) Received: from Melon.malikania.fr (65.21.102.84.rev.sfr.net [84.102.21.65]) by mx.google.com with ESMTPS id o19sm3271005wbh.55.2011.06.20.08.38.02 (version=SSLv3 cipher=OTHER); Mon, 20 Jun 2011 08:38:03 -0700 (PDT) Message-ID: <4DFF694C.6090901@gmail.com> Date: Mon, 20 Jun 2011 17:37:48 +0200 From: David Demelier User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110508 Thunderbird/3.1.10 MIME-Version: 1.0 To: Jeremy Chadwick References: <4DCB8271.3070707@gmail.com> <4DE0F8F2.2030301@gmail.com> <20110528134622.GA31033@icarus.home.lan> In-Reply-To: <20110528134622.GA31033@icarus.home.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mav@freebsd.org, freebsd-current@freebsd.org, freebsd-stable Subject: Re: snd_hda : sometimes sound sometimes not X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 15:38:07 -0000 On 28/05/2011 15:46, Jeremy Chadwick wrote: > On Sat, May 28, 2011 at 03:30:26PM +0200, David Demelier wrote: >> On 12/05/2011 08:47, David Demelier wrote: >>> Hello, >>> >>> I don't know if there is a lot of changes in the snd_hda driver in the >>> -STABLE branch but since I upgraded to it sometimes I have sound and >>> sometimes not. >>> >>> The mixer are exactly the same when these event occurs. This happened >>> this morning. After booting I do not have any sound. I rebooted and >>> suddenly I've got sound again... >>> >>> I only tweak snd_hda(4) for a pin sense on the front panel (it has no >>> sound neither) >>> >>> So I added in /boot/devices.hints : >>> hint.hdac.1.cad0.nid27.config="as=1 seq=15" >>> >>> And there's the both dmesg ok.txt when sound is here and not.txt when >>> there isn't as you can see there is no difference related to the hda >>> driver. >>> >>> http://markand.malikania.fr/ok.txt >>> http://markand.malikania.fr/nok.txt >>> >>> I'm guessing something. My laptop has a mute shortcut, if I press it at >>> the BIOS stage I will not have sound neither thus is it possible that my >>> chipset is muted from anything? >>> >>> Cheers, >>> >> >> Sorry to cross-post again, but I just wanted to tell you that the >> problem disappeared in -CURRENT so now I just how the unknown bogus >> code will be MFC before 8.3-RELEASE > > Unless someone can chime in with details of the commits which changed, > assuming "the magic change" will be MFC'd is a bad one. It's safe to > say that when 8.3-RELEASE comes out if this problem haunts you again, > you will be mailing the list about it, and this cycle will continue > until 9.0-RELEASE comes out. > > Does any developer/committer have familiarity with this issue and have > some ideas as to what may have changed in CURRENT that addresses David's > issue? And if so, can that code be MFC'd safely or patches provided to > David for RELENG_8 that he can try out? > > I'm CC'ing mav@ here (snd_hda(4) says he's one of the authors), although > he may not have any knowledge of the code which may need to be MFC'd. > He may be able to point us to who has a better idea though. > No worries Jeremy but thanks for your interest you seems to be the only one who believed my problem. The problem has been fixed in -STABLE, I don't know where but it works now .... -- David Demelier From owner-freebsd-stable@FreeBSD.ORG Mon Jun 20 19:30:28 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F0BCB1065700 for ; Mon, 20 Jun 2011 19:30:27 +0000 (UTC) (envelope-from bengta@P142.sics.se) Received: from sink.sics.se (sink.sics.se [193.10.64.88]) by mx1.freebsd.org (Postfix) with ESMTP id 7933C8FC15 for ; Mon, 20 Jun 2011 19:30:27 +0000 (UTC) Received: from P142.sics.se (P142.sics.se [193.10.66.253]) by sink.sics.se (8.14.3/8.14.3) with ESMTP id p5KIxMXU009287 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 20 Jun 2011 20:59:22 +0200 (CEST) (envelope-from bengta@P142.sics.se) Received: from P142.sics.se (localhost [127.0.0.1]) by P142.sics.se (8.14.4/8.14.4) with ESMTP id p5KIxVUS002069; Mon, 20 Jun 2011 20:59:32 +0200 (CEST) (envelope-from bengta@P142.sics.se) Received: (from bengta@localhost) by P142.sics.se (8.14.4/8.14.4/Submit) id p5KIxVIE002068; Mon, 20 Jun 2011 20:59:31 +0200 (CEST) (envelope-from bengta@P142.sics.se) From: Bengt Ahlgren To: nickolasbug@gmail.com In-Reply-To: (nickolasbug@gmail.com's message of "Mon, 20 Jun 2011 12:17:37 +0300") References: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) Date: Mon, 20 Jun 2011 20:59:31 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-stable@freebsd.org Subject: Re: GPT labels and gjournal X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 19:30:28 -0000 nickolasbug@gmail.com writes: > Hello stable. > > > I've tried to make two journaled partitions on new GPT disk. > Partitions have GPT labels storage and backup: > > gpart show -l ada1 > => 34 2930277101 ada1 GPT (1.4T) > 34 8388608 1 (null) (4.0G) > 8388642 2415919104 2 storage (1.1T) > 2424307746 8388608 3 (null) (4.0G) > 2432696354 497580781 4 backup (237G) > > > gjournal label /dev/gpt/storage /dev/gptid/3570dff6-9a73-11e0-ad0e-001e8c0ecc19 > gjournal label /dev/gpt/backup /dev/gptid/58db2577-9a73-11e0-ad0e-001e8c0ecc19 > > newfs -J /dev/gpt/storage.journal > newfs -J /dev/gpt/backup.journal > > Where 3570dff6-9a73-11e0-ad0e-001e8c0ecc19 is GPT UUID of ada1p1 and > 58db2577-9a73-11e0-ad0e-001e8c0ecc19 is GPT UUID of ada1p3 partition. > > > This partitions have been added to fstab: > > /dev/gpt/storage.journal /mnt/storage ufs async,rw 0 0 > /dev/gpt/backup.journal /mnt/backup ufs async,rw 0 0 > > > After reboot system doesn't wanna see gpt-labeled partitions > /dev/gpt/storage.journal and /dev/gpt/backup.journal (so, mount fails) > but has /dev/ada1p2.journal and /dev/ada1p4.journal instead. > > > How can I mount this partitions using GPT labels? Interesting! (amarat@ksu.ru already suggested an alternative that I believe works, but I thought I'd share my experience with this issue.) I ran into a similar problem with gmirror yesterday, but first my attempt at explaining why the above is happening. A geom(4) class "tastes" providers (e.g. ada1p2) in a certain order. When gjournal is tasting, it finds ada1p2 before gpt/storage, and creates ada1p2.journal. ada1p2 is then used, and gpt/storage is automatically removed. (Or alternatively, gjournal tastes before glabel, and there are no gpt/... labels when gjournal tastes providers; same result, though.) So to have the above work, glabel has to taste before gjournal, and gjournal has to taste the label device (gpt/xxx) before the real device (ada1p2). An alternative solution would be if gjournal creates a label itself, instead of adding ".journal" to the device name, for example /dev/journal/foo in the same way as gmirror creates /dev/mirror/foo. Then the journal device becomes independent of the device holding the data component, making it possible to mount /dev/journal/foo. Now back to gmirror. When I tried: gmirror label m1 /dev/gptid/xxx /dev/gptid/yyy it still showed up as using the actual devices. When I tried to hardcode the provider names: gmirror label -h m1 /dev/gptid/xxx /dev/gptid/yyy it said it labelled both /dev/gptid/... but the mirror failed to appear. But this does not matter for gmirror, since a device-independent mirror name is created in /dev/mirror regardless of the names of the components. The tasting order seems to be very important. Would it be possible to fix the above by changing so that labels are tasted before the "real" devices? Or does that create different problems? gjournal would perhaps find both gpt/xxx and ada1p2, resulting in a mess? I think the idea with labels is great, but whether it works or not seems pretty random to me as a user. (People with more geom knowledge than me, please correct all errors in the above :-) Perhaps labels are not tasted at all, like "real" providers are???) Bengt From owner-freebsd-stable@FreeBSD.ORG Tue Jun 21 01:11:01 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 275B5106566B; Tue, 21 Jun 2011 01:11:01 +0000 (UTC) (envelope-from lichray@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 796C28FC0C; Tue, 21 Jun 2011 01:11:00 +0000 (UTC) Received: by fxm11 with SMTP id 11so2691953fxm.13 for ; Mon, 20 Jun 2011 18:10:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=8LA8rtiMoB+2sS6H4dXanSDunyPTgB/+FsAJXURIYYo=; b=fy0FEt9cKrtMkqVX2kCUVzhJtU3SUo56TTjv9gbx/YRennIrbdphOusVmXCI4kR7WV HbB8THgqCBM37pfYhKPaLOA13YLh9CX3Xd9K8z+bh764MSCJjpQChtM9TXs+9oYz9ItT bK4pMleUwkajvX5Bpbl3/AbODdAGn1//VxN68= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=tnlefGti9EWGpz2ldQc5aLInVbHVJVSREzDb7SJx0JC8Qt8g4iZFp5Yyrr0YWVyF/c +2TwmHsemrknWPOnn5Ex08Xr8Yxpf6sF32ANUHRaimqWxWeHfcK9egHgl1ZZurFAuuZ0 IYo5o2lAzQ3HcDReiDLxYIDhoxhHO5DK+wf/U= MIME-Version: 1.0 Received: by 10.223.127.213 with SMTP id h21mr1276984fas.45.1308618659282; Mon, 20 Jun 2011 18:10:59 -0700 (PDT) Received: by 10.223.95.195 with HTTP; Mon, 20 Jun 2011 18:10:59 -0700 (PDT) In-Reply-To: References: <201106161335.46337.jhb@freebsd.org> <4DFB898E.4070202@restart.be> <201106171337.39104.jhb@freebsd.org> Date: Mon, 20 Jun 2011 20:10:59 -0500 Message-ID: From: Zhihao Yuan To: John Baldwin Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Henri Hennebert , freebsd-stable@freebsd.org Subject: Re: ZFS boot inside on the second partition inside a slice X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 01:11:01 -0000 I finally redo everything with GPT-based solution. At the same time, I found a problem with zpool.cache and I fixed with: http://forums.freebsd.org/showthread.php?t=3D4185 zpool.cache will be changed after you exported the zpool... Anyway, now I'm OK with my freebsd-only box, again. On Fri, Jun 17, 2011 at 9:18 PM, Zhihao Yuan wrote: > If this problem can not be solved, I probably have to redo everything > to use GPT-based solution and lose my Windows............. > > On Fri, Jun 17, 2011 at 12:37 PM, John Baldwin wrote: >> On Friday, June 17, 2011 1:06:22 pm Henri Hennebert wrote: >>> On 06/16/2011 19:35, John Baldwin wrote: >>> > On Thursday, June 16, 2011 8:45:41 am Zhihao Yuan wrote: >>> >> Exactly. The MFCed ZFSv28 is different from any patch maintained by >>> >> mm@. Maybe some untested changes involved. >>> > >>> > Can you try reverting this change: >>> > >>> > Author: jhb >>> > Date: Thu Apr 28 17:44:24 2011 >>> > New Revision: 221177 >>> > URL: http://svn.freebsd.org/changeset/base/221177 >>> > >>> > Log: >>> > =C2=A0 Due to space constraints, the UFS boot2 and boot1 use an evil = hack where >>> > =C2=A0 boot2 calls back into boot1 to perform disk reads. =C2=A0The Z= FS MBR boot blocks >>> > =C2=A0 do not have the same space constraints, so remove this hack fo= r ZFS. >>> > =C2=A0 While here, remove commented out code to support C/H/S address= ing from >>> > =C2=A0 zfsldr. =C2=A0The ZFS and GPT bootstraps always just use EDD L= BA addressing. >>> > >>> > =C2=A0 MFC after: =C2=A0 =C2=A02 weeks >>> > >>> > Modified: >>> > =C2=A0 head/sys/boot/i386/boot2/Makefile >>> > =C2=A0 head/sys/boot/i386/common/drv.c >>> > =C2=A0 head/sys/boot/i386/zfsboot/Makefile >>> > =C2=A0 head/sys/boot/i386/zfsboot/zfsldr.S >>> > >>> I try with this revision (221177) reverted to no avail: >>> same error - 'read error' >> >> Hmm, ok. =C2=A0No other ideas off the top of my head. >> >> -- >> John Baldwin >> > > > > -- > Zhihao Yuan, nickname lichray > The best way to predict the future is to invent it. > ___________________________________________________ > 4BSD -- http://4bsd.biz/ > --=20 Zhihao Yuan, nickname lichray The best way to predict the future is to invent it. ___________________________________________________ 4BSD -- http://4bsd.biz/ From owner-freebsd-stable@FreeBSD.ORG Tue Jun 21 04:02:09 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3E217106564A for ; Tue, 21 Jun 2011 04:02:09 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (agora.rdrop.com [IPv6:2607:f678:1010::34]) by mx1.freebsd.org (Postfix) with ESMTP id AF1BB8FC08 for ; Tue, 21 Jun 2011 04:02:08 +0000 (UTC) Received: from agora.rdrop.com (66@localhost [127.0.0.1]) by agora.rdrop.com (8.13.1/8.12.7) with ESMTP id p5L425Iu081855 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 20 Jun 2011 21:02:06 -0700 (PDT) (envelope-from perryh@pluto.rain.com) Received: (from uucp@localhost) by agora.rdrop.com (8.13.1/8.12.9/Submit) with UUCP id p5L425d7081854; Mon, 20 Jun 2011 21:02:05 -0700 (PDT) Received: from fbsd61 by pluto.rain.com (4.1/SMI-4.1-pluto-M2060407) id AA19442; Mon, 20 Jun 11 20:48:31 PDT Date: Mon, 20 Jun 2011 20:48:05 -0700 From: perryh@pluto.rain.com To: bengta@sics.se, nickolasbug@gmail.com Message-Id: <4e001475.NwhB8V19oMTs52vu%perryh@pluto.rain.com> References: In-Reply-To: User-Agent: nail 11.25 7/29/05 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: GPT labels and gjournal X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 04:02:09 -0000 Bengt Ahlgren wrote: > nickolasbug@gmail.com writes: > > I've tried to make two journaled partitions on new GPT disk. ... > > How can I mount this partitions using GPT labels? ... > I think the idea with labels is great, but whether it works or > not seems pretty random to me as a user. Based on the PR descriptions, this sounds as if it might be related to kern/140352, kern/150555, and/or kern/150626. From owner-freebsd-stable@FreeBSD.ORG Tue Jun 21 09:51:26 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2F0E0106564A; Tue, 21 Jun 2011 09:51:26 +0000 (UTC) (envelope-from hlh@restart.be) Received: from tignes.restart.be (tignes.restart.be [IPv6:2001:41d0:2:56bf:0:1::]) by mx1.freebsd.org (Postfix) with ESMTP id 9BE1B8FC12; Tue, 21 Jun 2011 09:51:25 +0000 (UTC) Received: from restart.be (avoriaz.tunnel.bel [IPv6:2001:41d0:2:56bf:1:ffff::]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "smtp.restart.be", Issuer "CA master" (verified OK)) by tignes.restart.be (Postfix) with ESMTPS id 92BEE148A0; Tue, 21 Jun 2011 11:51:24 +0200 (CEST) Received: from morzine.restart.bel (morzine.restart.be [IPv6:2001:41d0:2:56bf:1:2::]) (authenticated bits=0) by restart.be (8.14.5/8.14.5) with ESMTP id p5L9pMpi015012; Tue, 21 Jun 2011 11:51:23 +0200 (CEST) (envelope-from hlh@restart.be) X-DKIM: Sendmail DKIM Filter v2.8.3 restart.be p5L9pMpi015012 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=restart.be; s=avoriaz; t=1308649883; bh=G9GjlDDEkrooZ61qNQfKBBK4y2PNZOoPyJsU9aN2CXk=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=c0EbDbqN8TN4kj5lI03NtYSSv8Ke3zP4tN+FowsUnyRwwNTm6WyC19z0d2ymH0/iI hvGADV0fqlAQanw7/6uWQ== X-DomainKeys: Sendmail DomainKeys Filter v1.0.2 restart.be p5L9pMpi015012 DomainKey-Signature: a=rsa-sha1; s=avoriaz; d=restart.be; c=nofws; q=dns; h=message-id:date:from:organization:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type:content-transfer-encoding; b=QNRhYPBEE2YrZe+dXwD3brUMSIR7JuVu4B7Z9/xSFKLfbZ6deTVfnP5d2BAFRYf97 uzWDbMoj4TMaiiTh3+7IA== Message-ID: <4E00699A.7010403@restart.be> Date: Tue, 21 Jun 2011 11:51:22 +0200 From: Henri Hennebert Organization: RestartSoft User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.17) Gecko/20110616 Thunderbird/3.1.10 MIME-Version: 1.0 To: John Baldwin References: <201106171337.39104.jhb@freebsd.org> <4DFC6A07.7090607@restart.be> <201106200951.47449.jhb@freebsd.org> In-Reply-To: <201106200951.47449.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: ZFS boot inside on the second partition inside a slice X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 09:51:26 -0000 On 06/20/2011 15:51, John Baldwin wrote: > On Saturday, June 18, 2011 5:04:07 am Henri Hennebert wrote: >> On 06/17/2011 19:37, John Baldwin wrote: >>> On Friday, June 17, 2011 1:06:22 pm Henri Hennebert wrote: >>>> On 06/16/2011 19:35, John Baldwin wrote: >>>>> On Thursday, June 16, 2011 8:45:41 am Zhihao Yuan wrote: >>>>>> Exactly. The MFCed ZFSv28 is different from any patch maintained by >>>>>> mm@. Maybe some untested changes involved. >>>>> >>>>> Can you try reverting this change: >>>>> >>>>> Author: jhb >>>>> Date: Thu Apr 28 17:44:24 2011 >>>>> New Revision: 221177 >>>>> URL: http://svn.freebsd.org/changeset/base/221177 >>>>> >>>>> Log: >>>>> Due to space constraints, the UFS boot2 and boot1 use an evil hack where >>>>> boot2 calls back into boot1 to perform disk reads. The ZFS MBR boot blocks >>>>> do not have the same space constraints, so remove this hack for ZFS. >>>>> While here, remove commented out code to support C/H/S addressing from >>>>> zfsldr. The ZFS and GPT bootstraps always just use EDD LBA addressing. >>>>> >>>>> MFC after: 2 weeks >>>>> >>>>> Modified: >>>>> head/sys/boot/i386/boot2/Makefile >>>>> head/sys/boot/i386/common/drv.c >>>>> head/sys/boot/i386/zfsboot/Makefile >>>>> head/sys/boot/i386/zfsboot/zfsldr.S >>>>> >>>> I try with this revision (221177) reverted to no avail: >>>> same error - 'read error' >>> >>> Hmm, ok. No other ideas off the top of my head. >>> >> I make the same test under virtualbox and get: >> >> A critical error has occurred while running the virtual machine and the >> machine execution has been stopped. >> >> I attach VBox.log. >> >> PS - the message 'ZFS: supported version 28' comes from my patch: >> >> Index: sys/boot/zfs/zfsimpl.c >> =================================================================== >> --- sys/boot/zfs/zfsimpl.c (revision 212549) >> +++ sys/boot/zfs/zfsimpl.c (working copy) >> @@ -61,6 +61,8 @@ >> STAILQ_INIT(&zfs_vdevs); >> STAILQ_INIT(&zfs_pools); >> >> + printf("ZFS: supported version %u\n", (unsigned) SPA_VERSION); >> + >> zfs_temp_buf = malloc(TEMP_SIZE); >> zfs_temp_end = zfs_temp_buf + TEMP_SIZE; >> zfs_temp_ptr = zfs_temp_buf; > > Hmm, can you add printfs and narrow down where the hang happens (or which > reads are failing)? The VBOX log seems to make no sense. It shows the > CPU trying to call into the BIOS from within protected mode in the loader > but that shouldn't ever happen (note a cs of 0x2b (which is the loader's > %cs selector) but an eip that looks like a cs:ip of a BIOS routine). > I just try to put printf but I get only 'Read error' without any of my printf. Previously event my printf in zfs_init don't show up on the console of my netbook. Under VBox it was printed. Maybe printf is not allowed so soon in zfsboot ? For the record, I write the bootcode with this 2 commands after booting with mfsbsd (from mm@) and fetching zfsboot in /tmp: dd if=/tmp/zfsboot of=/dev/ad0s2a bs=512 count=1 dd if=/tmp/zfsboot of=/dev/ad0s2a bs=512 skip=1 seek=1024 My debugging patch in zfsboot.c: [root@morzine zfsboot]# svn diff zfsboot.c Index: zfsboot.c =================================================================== --- zfsboot.c (revision 223081) +++ zfsboot.c (working copy) @@ -447,10 +447,16 @@ off_t off; struct dsk *dsk; + printf("==>trying to boot\n"); + dmadat = (void *)(roundup2(__base + (int32_t)&_end, 0x10000) - __base); + printf("==>about to call bios_getmem()\n"); + bios_getmem(); + printf("==>bios_getmem() completed\n"); + if (high_heap_size > 0) { heap_end = PTOV(high_heap_base + high_heap_size); heap_next = PTOV(high_heap_base); @@ -482,6 +488,8 @@ autoboot = 1; + printf("==>about to call zfs_init()\n"); + zfs_init(); /* Henri From owner-freebsd-stable@FreeBSD.ORG Tue Jun 21 13:01:29 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4A0DD106566B for ; Tue, 21 Jun 2011 13:01:29 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id DBC668FC2D for ; Tue, 21 Jun 2011 13:01:28 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 7AC8546B1A; Tue, 21 Jun 2011 09:01:28 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 111448A01F; Tue, 21 Jun 2011 09:01:28 -0400 (EDT) From: John Baldwin To: Henri Hennebert Date: Tue, 21 Jun 2011 09:01:27 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110325; KDE/4.5.5; amd64; ; ) References: <201106200951.47449.jhb@freebsd.org> <4E00699A.7010403@restart.be> In-Reply-To: <4E00699A.7010403@restart.be> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201106210901.27338.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Tue, 21 Jun 2011 09:01:28 -0400 (EDT) Cc: freebsd-stable@freebsd.org Subject: Re: ZFS boot inside on the second partition inside a slice X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 13:01:29 -0000 On Tuesday, June 21, 2011 5:51:22 am Henri Hennebert wrote: > On 06/20/2011 15:51, John Baldwin wrote: > > On Saturday, June 18, 2011 5:04:07 am Henri Hennebert wrote: > >> On 06/17/2011 19:37, John Baldwin wrote: > >>> On Friday, June 17, 2011 1:06:22 pm Henri Hennebert wrote: > >>>> On 06/16/2011 19:35, John Baldwin wrote: > >>>>> On Thursday, June 16, 2011 8:45:41 am Zhihao Yuan wrote: > >>>>>> Exactly. The MFCed ZFSv28 is different from any patch maintained by > >>>>>> mm@. Maybe some untested changes involved. > >>>>> > >>>>> Can you try reverting this change: > >>>>> > >>>>> Author: jhb > >>>>> Date: Thu Apr 28 17:44:24 2011 > >>>>> New Revision: 221177 > >>>>> URL: http://svn.freebsd.org/changeset/base/221177 > >>>>> > >>>>> Log: > >>>>> Due to space constraints, the UFS boot2 and boot1 use an evil hack where > >>>>> boot2 calls back into boot1 to perform disk reads. The ZFS MBR boot blocks > >>>>> do not have the same space constraints, so remove this hack for ZFS. > >>>>> While here, remove commented out code to support C/H/S addressing from > >>>>> zfsldr. The ZFS and GPT bootstraps always just use EDD LBA addressing. > >>>>> > >>>>> MFC after: 2 weeks > >>>>> > >>>>> Modified: > >>>>> head/sys/boot/i386/boot2/Makefile > >>>>> head/sys/boot/i386/common/drv.c > >>>>> head/sys/boot/i386/zfsboot/Makefile > >>>>> head/sys/boot/i386/zfsboot/zfsldr.S > >>>>> > >>>> I try with this revision (221177) reverted to no avail: > >>>> same error - 'read error' > >>> > >>> Hmm, ok. No other ideas off the top of my head. > >>> > >> I make the same test under virtualbox and get: > >> > >> A critical error has occurred while running the virtual machine and the > >> machine execution has been stopped. > >> > >> I attach VBox.log. > >> > >> PS - the message 'ZFS: supported version 28' comes from my patch: > >> > >> Index: sys/boot/zfs/zfsimpl.c > >> =================================================================== > >> --- sys/boot/zfs/zfsimpl.c (revision 212549) > >> +++ sys/boot/zfs/zfsimpl.c (working copy) > >> @@ -61,6 +61,8 @@ > >> STAILQ_INIT(&zfs_vdevs); > >> STAILQ_INIT(&zfs_pools); > >> > >> + printf("ZFS: supported version %u\n", (unsigned) SPA_VERSION); > >> + > >> zfs_temp_buf = malloc(TEMP_SIZE); > >> zfs_temp_end = zfs_temp_buf + TEMP_SIZE; > >> zfs_temp_ptr = zfs_temp_buf; > > > > Hmm, can you add printfs and narrow down where the hang happens (or which > > reads are failing)? The VBOX log seems to make no sense. It shows the > > CPU trying to call into the BIOS from within protected mode in the loader > > but that shouldn't ever happen (note a cs of 0x2b (which is the loader's > > %cs selector) but an eip that looks like a cs:ip of a BIOS routine). > > > I just try to put printf but I get only 'Read error' without any of my > printf. > > Previously event my printf in zfs_init don't show up on the console of > my netbook. Under VBox it was printed. > > Maybe printf is not allowed so soon in zfsboot ? Rather, it may be that zfsldr.S is what is emitting 'Read error' and you are not getting into the zfsboot.c code itself. You can try this patch which should display the error code the BIOS returns when it fails: Index: zfsldr.S =================================================================== --- zfsldr.S (revision 223339) +++ zfsldr.S (working copy) @@ -234,9 +234,12 @@ nread.1: xor %ecx,%ecx # Get callw read # Read from disk lea 0x10(%bp),%sp # Clear stack jnc return # If success, return - mov $msg_read,%si # Otherwise, set the error - # message and fall through to - # the error routine + mov %ah,%al # Format + mov $read_err,%di # error + call hex8 # code + mov $msg_read,%si # Set the error message and + # fall through to the error + # routine /* * Print out the error message pointed to by %ds:(%si) followed * by a prompt, wait for a keypress, and then reboot the machine. @@ -296,12 +299,28 @@ read.1: mov $msg_chs,%si jmp error msg_chs: .asciz "CHS not supported" +/* + * Convert AL to hex, saving the result to [EDI]. + */ +hex8: push %ax # Save + shrb $0x4,%al # Do upper + call hex8.1 # 4 + pop %ax # Restore +hex8.1: andb $0xf,%al # Get lower 4 + cmpb $0xa,%al # Convert + sbbb $0x69,%al # to hex + das # digit + orb $0x20,%al # To lower case + stosb # Save char + ret # (Recursive) + /* Messages */ -msg_read: .asciz "Read" -msg_part: .asciz "Boot" +msg_read: .ascii "Read error: " +read_err: .asciz "XX" +msg_part: .asciz "Boot error" -prompt: .asciz " error\r\n" +prompt: .asciz "\r\n" .org PRT_OFF,0x90 -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Tue Jun 21 14:50:22 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 56095106566B; Tue, 21 Jun 2011 14:50:22 +0000 (UTC) (envelope-from hlh@restart.be) Received: from tignes.restart.be (tignes.restart.be [IPv6:2001:41d0:2:56bf:0:1::]) by mx1.freebsd.org (Postfix) with ESMTP id C96198FC1B; Tue, 21 Jun 2011 14:50:21 +0000 (UTC) Received: from restart.be (avoriaz.tunnel.bel [IPv6:2001:41d0:2:56bf:1:ffff::]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "smtp.restart.be", Issuer "CA master" (verified OK)) by tignes.restart.be (Postfix) with ESMTPS id 3B8FC14DFE; Tue, 21 Jun 2011 16:50:17 +0200 (CEST) Received: from morzine.restart.bel (morzine.restart.be [IPv6:2001:41d0:2:56bf:1:2::]) (authenticated bits=0) by restart.be (8.14.5/8.14.5) with ESMTP id p5LEoFYf021859; Tue, 21 Jun 2011 16:50:15 +0200 (CEST) (envelope-from hlh@restart.be) X-DKIM: Sendmail DKIM Filter v2.8.3 restart.be p5LEoFYf021859 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=restart.be; s=avoriaz; t=1308667816; bh=qskL58d+zniDJCWiwBLK9n9ZbA1kU+b3cQSoErkAkHM=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=PPWFjK8yFgT0LcVjvKNm8gBN+NYPD41XU20/+YKidXndrcu16Wjb5vVkC80qeAgvW Kf2WvxOq04w2FOwtLpVKA== X-DomainKeys: Sendmail DomainKeys Filter v1.0.2 restart.be p5LEoFYf021859 DomainKey-Signature: a=rsa-sha1; s=avoriaz; d=restart.be; c=nofws; q=dns; h=message-id:date:from:organization:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type:content-transfer-encoding; b=xHo9mjv3Mr4Vbv5220Sjws6zK6B9fkzYLM1cg6RYB6gPWuP0jul4W7IlaGuxMpabd BS99kz+FbMXAbJDBP4Ycg== Message-ID: <4E00AFA6.4050305@restart.be> Date: Tue, 21 Jun 2011 16:50:14 +0200 From: Henri Hennebert Organization: RestartSoft User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.17) Gecko/20110616 Thunderbird/3.1.10 MIME-Version: 1.0 To: John Baldwin References: <201106200951.47449.jhb@freebsd.org> <4E00699A.7010403@restart.be> <201106210901.27338.jhb@freebsd.org> In-Reply-To: <201106210901.27338.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: ZFS boot inside on the second partition inside a slice X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 14:50:22 -0000 On 06/21/2011 15:01, John Baldwin wrote: > Index: zfsldr.S > =================================================================== > --- zfsldr.S (revision 223339) > +++ zfsldr.S (working copy) > @@ -234,9 +234,12 @@ nread.1: xor %ecx,%ecx # Get > callw read # Read from disk > lea 0x10(%bp),%sp # Clear stack > jnc return # If success, return > - mov $msg_read,%si # Otherwise, set the error > - # message and fall through to > - # the error routine > + mov %ah,%al # Format > + mov $read_err,%di # error > + call hex8 # code > + mov $msg_read,%si # Set the error message and > + # fall through to the error > + # routine > /* > * Print out the error message pointed to by %ds:(%si) followed > * by a prompt, wait for a keypress, and then reboot the machine. > @@ -296,12 +299,28 @@ read.1: mov $msg_chs,%si > jmp error > msg_chs: .asciz "CHS not supported" > > +/* > + * Convert AL to hex, saving the result to [EDI]. > + */ > +hex8: push %ax # Save > + shrb $0x4,%al # Do upper > + call hex8.1 # 4 > + pop %ax # Restore > +hex8.1: andb $0xf,%al # Get lower 4 > + cmpb $0xa,%al # Convert > + sbbb $0x69,%al # to hex > + das # digit > + orb $0x20,%al # To lower case > + stosb # Save char > + ret # (Recursive) > + > /* Messages */ > > -msg_read: .asciz "Read" > -msg_part: .asciz "Boot" > +msg_read: .ascii "Read error: " > +read_err: .asciz "XX" > +msg_part: .asciz "Boot error" > > -prompt: .asciz " error\r\n" > +prompt: .asciz "\r\n" > > .org PRT_OFF,0x90 > I get Read error: 01 Henri From owner-freebsd-stable@FreeBSD.ORG Tue Jun 21 15:55:20 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B895D1065670 for ; Tue, 21 Jun 2011 15:55:20 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 8FEFC8FC18 for ; Tue, 21 Jun 2011 15:55:20 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 2FA4146B03; Tue, 21 Jun 2011 11:55:20 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id B56368A01F; Tue, 21 Jun 2011 11:55:19 -0400 (EDT) From: John Baldwin To: Henri Hennebert Date: Tue, 21 Jun 2011 11:55:18 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110325; KDE/4.5.5; amd64; ; ) References: <201106210901.27338.jhb@freebsd.org> <4E00AFA6.4050305@restart.be> In-Reply-To: <4E00AFA6.4050305@restart.be> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201106211155.19231.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Tue, 21 Jun 2011 11:55:19 -0400 (EDT) Cc: freebsd-stable@freebsd.org Subject: Re: ZFS boot inside on the second partition inside a slice X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 15:55:20 -0000 On Tuesday, June 21, 2011 10:50:14 am Henri Hennebert wrote: > On 06/21/2011 15:01, John Baldwin wrote: > > Index: zfsldr.S > > =================================================================== > > --- zfsldr.S (revision 223339) > > +++ zfsldr.S (working copy) > > @@ -234,9 +234,12 @@ nread.1: xor %ecx,%ecx # Get > > callw read # Read from disk > > lea 0x10(%bp),%sp # Clear stack > > jnc return # If success, return > > - mov $msg_read,%si # Otherwise, set the error > > - # message and fall through to > > - # the error routine > > + mov %ah,%al # Format > > + mov $read_err,%di # error > > + call hex8 # code > > + mov $msg_read,%si # Set the error message and > > + # fall through to the error > > + # routine > > /* > > * Print out the error message pointed to by %ds:(%si) followed > > * by a prompt, wait for a keypress, and then reboot the machine. > > @@ -296,12 +299,28 @@ read.1: mov $msg_chs,%si > > jmp error > > msg_chs: .asciz "CHS not supported" > > > > +/* > > + * Convert AL to hex, saving the result to [EDI]. > > + */ > > +hex8: push %ax # Save > > + shrb $0x4,%al # Do upper > > + call hex8.1 # 4 > > + pop %ax # Restore > > +hex8.1: andb $0xf,%al # Get lower 4 > > + cmpb $0xa,%al # Convert > > + sbbb $0x69,%al # to hex > > + das # digit > > + orb $0x20,%al # To lower case > > + stosb # Save char > > + ret # (Recursive) > > + > > /* Messages */ > > > > -msg_read: .asciz "Read" > > -msg_part: .asciz "Boot" > > +msg_read: .ascii "Read error: " > > +read_err: .asciz "XX" > > +msg_part: .asciz "Boot error" > > > > -prompt: .asciz " error\r\n" > > +prompt: .asciz "\r\n" > > > > .org PRT_OFF,0x90 > > > I get > > Read error: 01 Hmm, that would be 'invalid parameter'. Can you add a 'foo: jmp foo' infinite loop and move it around to figure out which read call is failing? -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Tue Jun 21 16:16:05 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 11D991065672; Tue, 21 Jun 2011 16:16:05 +0000 (UTC) (envelope-from hlh@restart.be) Received: from tignes.restart.be (tignes.restart.be [IPv6:2001:41d0:2:56bf:0:1::]) by mx1.freebsd.org (Postfix) with ESMTP id 84C948FC15; Tue, 21 Jun 2011 16:16:04 +0000 (UTC) Received: from restart.be (avoriaz.tunnel.bel [IPv6:2001:41d0:2:56bf:1:ffff::]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "smtp.restart.be", Issuer "CA master" (verified OK)) by tignes.restart.be (Postfix) with ESMTPS id 45A1F14FF9; Tue, 21 Jun 2011 18:16:00 +0200 (CEST) Received: from morzine.restart.bel (morzine.restart.be [IPv6:2001:41d0:2:56bf:1:2::]) (authenticated bits=0) by restart.be (8.14.5/8.14.5) with ESMTP id p5LGFxId023843; Tue, 21 Jun 2011 18:15:59 +0200 (CEST) (envelope-from hlh@restart.be) X-DKIM: Sendmail DKIM Filter v2.8.3 restart.be p5LGFxId023843 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=restart.be; s=avoriaz; t=1308672959; bh=zSysIZllsUotce84ZnG09PC54Pqnx5SSclcvIPvB1Ik=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=OmxGKVJe8LWgOflj8F/atEWj8DqPU+UyUR6QfZ9FHzaMbb0ZgbKpSiaLl5K9jALpg FxSBcW/hMhe2oOkFkENpg== X-DomainKeys: Sendmail DomainKeys Filter v1.0.2 restart.be p5LGFxId023843 DomainKey-Signature: a=rsa-sha1; s=avoriaz; d=restart.be; c=nofws; q=dns; h=message-id:date:from:organization:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type:content-transfer-encoding; b=ou8NIzGVLfrNPzFCSOinn6fQt4aI7yOgEAOsg67fmQNkfzAdoiu9YXcq+ma5n6+Bw 2ji3fqillp/RcJNWh0uAA== Message-ID: <4E00C3BE.3050004@restart.be> Date: Tue, 21 Jun 2011 18:15:58 +0200 From: Henri Hennebert Organization: RestartSoft User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.17) Gecko/20110616 Thunderbird/3.1.10 MIME-Version: 1.0 To: John Baldwin References: <201106210901.27338.jhb@freebsd.org> <4E00AFA6.4050305@restart.be> <201106211155.19231.jhb@freebsd.org> In-Reply-To: <201106211155.19231.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: ZFS boot inside on the second partition inside a slice X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 16:16:05 -0000 On 06/21/2011 17:55, John Baldwin wrote: > On Tuesday, June 21, 2011 10:50:14 am Henri Hennebert wrote: >> On 06/21/2011 15:01, John Baldwin wrote: >>> Index: zfsldr.S >>> =================================================================== >>> --- zfsldr.S (revision 223339) >>> +++ zfsldr.S (working copy) >>> @@ -234,9 +234,12 @@ nread.1: xor %ecx,%ecx # Get >>> callw read # Read from disk >>> lea 0x10(%bp),%sp # Clear stack >>> jnc return # If success, return >>> - mov $msg_read,%si # Otherwise, set the error >>> - # message and fall through to >>> - # the error routine >>> + mov %ah,%al # Format >>> + mov $read_err,%di # error >>> + call hex8 # code >>> + mov $msg_read,%si # Set the error message and >>> + # fall through to the error >>> + # routine >>> /* >>> * Print out the error message pointed to by %ds:(%si) followed >>> * by a prompt, wait for a keypress, and then reboot the machine. >>> @@ -296,12 +299,28 @@ read.1: mov $msg_chs,%si >>> jmp error >>> msg_chs: .asciz "CHS not supported" >>> >>> +/* >>> + * Convert AL to hex, saving the result to [EDI]. >>> + */ >>> +hex8: push %ax # Save >>> + shrb $0x4,%al # Do upper >>> + call hex8.1 # 4 >>> + pop %ax # Restore >>> +hex8.1: andb $0xf,%al # Get lower 4 >>> + cmpb $0xa,%al # Convert >>> + sbbb $0x69,%al # to hex >>> + das # digit >>> + orb $0x20,%al # To lower case >>> + stosb # Save char >>> + ret # (Recursive) >>> + >>> /* Messages */ >>> >>> -msg_read: .asciz "Read" >>> -msg_part: .asciz "Boot" >>> +msg_read: .ascii "Read error: " >>> +read_err: .asciz "XX" >>> +msg_part: .asciz "Boot error" >>> >>> -prompt: .asciz " error\r\n" >>> +prompt: .asciz "\r\n" >>> >>> .org PRT_OFF,0x90 >>> >> I get >> >> Read error: 01 > > Hmm, that would be 'invalid parameter'. > > Can you add a 'foo: jmp foo' infinite loop and move it around to figure out > which read call is failing? > main.5: mov %dx,MEM_ARG # Save args movb $NSECT,%dh # Sector count movl $1024,%eax # Offset to boot2 callw nread.1 # Read disk foo: jmp foo After this one I get 'Read error: 01' Henri From owner-freebsd-stable@FreeBSD.ORG Tue Jun 21 17:51:47 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 67807106567A for ; Tue, 21 Jun 2011 17:51:47 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 3E3F88FC22 for ; Tue, 21 Jun 2011 17:51:47 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id E65B846B2D; Tue, 21 Jun 2011 13:51:46 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 81A4E8A027; Tue, 21 Jun 2011 13:51:46 -0400 (EDT) From: John Baldwin To: Henri Hennebert Date: Tue, 21 Jun 2011 13:51:45 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110325; KDE/4.5.5; amd64; ; ) References: <201106211155.19231.jhb@freebsd.org> <4E00C3BE.3050004@restart.be> In-Reply-To: <4E00C3BE.3050004@restart.be> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201106211351.45919.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Tue, 21 Jun 2011 13:51:46 -0400 (EDT) Cc: freebsd-stable@freebsd.org Subject: Re: ZFS boot inside on the second partition inside a slice X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 17:51:47 -0000 On Tuesday, June 21, 2011 12:15:58 pm Henri Hennebert wrote: > On 06/21/2011 17:55, John Baldwin wrote: > > On Tuesday, June 21, 2011 10:50:14 am Henri Hennebert wrote: > >> On 06/21/2011 15:01, John Baldwin wrote: > >>> Index: zfsldr.S > >>> =================================================================== > >>> --- zfsldr.S (revision 223339) > >>> +++ zfsldr.S (working copy) > >>> @@ -234,9 +234,12 @@ nread.1: xor %ecx,%ecx # Get > >>> callw read # Read from disk > >>> lea 0x10(%bp),%sp # Clear stack > >>> jnc return # If success, return > >>> - mov $msg_read,%si # Otherwise, set the error > >>> - # message and fall through to > >>> - # the error routine > >>> + mov %ah,%al # Format > >>> + mov $read_err,%di # error > >>> + call hex8 # code > >>> + mov $msg_read,%si # Set the error message and > >>> + # fall through to the error > >>> + # routine > >>> /* > >>> * Print out the error message pointed to by %ds:(%si) followed > >>> * by a prompt, wait for a keypress, and then reboot the machine. > >>> @@ -296,12 +299,28 @@ read.1: mov $msg_chs,%si > >>> jmp error > >>> msg_chs: .asciz "CHS not supported" > >>> > >>> +/* > >>> + * Convert AL to hex, saving the result to [EDI]. > >>> + */ > >>> +hex8: push %ax # Save > >>> + shrb $0x4,%al # Do upper > >>> + call hex8.1 # 4 > >>> + pop %ax # Restore > >>> +hex8.1: andb $0xf,%al # Get lower 4 > >>> + cmpb $0xa,%al # Convert > >>> + sbbb $0x69,%al # to hex > >>> + das # digit > >>> + orb $0x20,%al # To lower case > >>> + stosb # Save char > >>> + ret # (Recursive) > >>> + > >>> /* Messages */ > >>> > >>> -msg_read: .asciz "Read" > >>> -msg_part: .asciz "Boot" > >>> +msg_read: .ascii "Read error: " > >>> +read_err: .asciz "XX" > >>> +msg_part: .asciz "Boot error" > >>> > >>> -prompt: .asciz " error\r\n" > >>> +prompt: .asciz "\r\n" > >>> > >>> .org PRT_OFF,0x90 > >>> > >> I get > >> > >> Read error: 01 > > > > Hmm, that would be 'invalid parameter'. > > > > Can you add a 'foo: jmp foo' infinite loop and move it around to figure out > > which read call is failing? > > > main.5: mov %dx,MEM_ARG # Save args > movb $NSECT,%dh # Sector count > movl $1024,%eax # Offset to boot2 > callw nread.1 # Read disk > > foo: jmp foo > > After this one I get > > 'Read error: 01' Hmm, ok. NSECT changed in the MFC (it is now larger). Try this patch. It changes the code to read zfsboot in one sector at a time: Index: zfsldr.S =================================================================== --- zfsldr.S (revision 223365) +++ zfsldr.S (working copy) @@ -16,7 +16,6 @@ */ /* Memory Locations */ - .set MEM_REL,0x700 # Relocation address .set MEM_ARG,0x900 # Arguments .set MEM_ORG,0x7c00 # Origin .set MEM_BUF,0x8000 # Load area @@ -91,26 +90,19 @@ main: cld # String ops inc mov %cx,%ss # Set up mov $start,%sp # stack /* - * Relocate ourself to MEM_REL. Since %cx == 0, the inc %ch sets - * %cx == 0x100. - */ - mov %sp,%si # Source - mov $MEM_REL,%di # Destination - incb %ch # Word count - rep # Copy - movsw # code -/* * If we are on a hard drive, then load the MBR and look for the first * FreeBSD slice. We use the fake partition entry below that points to * the MBR when we call nread. The first pass looks for the first active * FreeBSD slice. The second pass looks for the first non-active FreeBSD * slice if the first one fails. */ - mov $part4,%si # Partition + mov $part4,%si # Dummy partition cmpb $0x80,%dl # Hard drive? jb main.4 # No - movb $0x1,%dh # Block count - callw nread # Read MBR + xor %eax,%eax # Read MBR from + movw $MEM_BUF,%bx # first sector + movb $0x1,%dh # on disk into + callw nread # $MEM_BUF mov $0x1,%cx # Two passes main.1: mov $MEM_BUF+PRT_OFF,%si # Partition table movb $0x1,%dh # Partition @@ -161,10 +153,18 @@ main.4: xor %dx,%dx # Partition:drive * area and target area do not overlap. */ main.5: mov %dx,MEM_ARG # Save args - movb $NSECT,%dh # Sector count + movb $NSECT,%cl # Sector count movl $1024,%eax # Offset to boot2 - callw nread.1 # Read disk -main.6: mov $MEM_BUF,%si # BTX (before reloc) + mov $MEM_BUF,%bx # Destination buffer +main.6: pushal # Save params + movb $1,$dh # One sector + callw nread # Read disk + popal # Restore + incl %eax # Update for + add $SIZ_SEC,%bx # next sector + dec %cx # Last sector? + jncxz main.6 # If not, read another. + mov $MEM_BUF,%si # BTX (before reloc) mov 0xa(%si),%bx # Get BTX length and set mov $NSECT*SIZ_SEC-1,%di # Size of load area (less one) mov %di,%si # End of load @@ -214,12 +214,12 @@ seta20.3: sti # Enable interrupts * packet on the stack and passes it to read. * * %eax - int - LBA to read in relative to partition start + * %es:%bx - ptr - destination address * %dl - byte - drive to read from * %dh - byte - num sectors to read * %si - ptr - MBR partition entry */ -nread: xor %eax,%eax # Sector offset in partition -nread.1: xor %ecx,%ecx # Get +nread: xor %ecx,%ecx # Get addl 0x8(%si),%eax # LBA adc $0,%ecx pushl %ecx # Starting absolute block @@ -234,9 +234,12 @@ seta20.3: sti # Enable interrupts callw read # Read from disk lea 0x10(%bp),%sp # Clear stack jnc return # If success, return - mov $msg_read,%si # Otherwise, set the error - # message and fall through to - # the error routine + mov %ah,%al # Format + mov $read_err,%di # error + call hex8 # code + mov $msg_read,%si # Set the error message and + # fall through to the error + # routine /* * Print out the error message pointed to by %ds:(%si) followed * by a prompt, wait for a keypress, and then reboot the machine. @@ -296,12 +299,28 @@ read.1: mov $msg_chs,%si jmp error msg_chs: .asciz "CHS not supported" +/* + * Convert AL to hex, saving the result to [EDI]. + */ +hex8: push %ax # Save + shrb $0x4,%al # Do upper + call hex8.1 # 4 + pop %ax # Restore +hex8.1: andb $0xf,%al # Get lower 4 + cmpb $0xa,%al # Convert + sbbb $0x69,%al # to hex + das # digit + orb $0x20,%al # To lower case + stosb # Save char + ret # (Recursive) + /* Messages */ -msg_read: .asciz "Read" -msg_part: .asciz "Boot" +msg_read: .ascii "Read error: " +read_err: .asciz "XX" +msg_part: .asciz "Boot error" -prompt: .asciz " error\r\n" +prompt: .asciz "\r\n" .org PRT_OFF,0x90 -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Tue Jun 21 18:32:39 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D9B041065686 for ; Tue, 21 Jun 2011 18:32:39 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) Received: from mail.ambrisko.com (mail.ambrisko.com [64.174.51.43]) by mx1.freebsd.org (Postfix) with ESMTP id 9D2808FC15 for ; Tue, 21 Jun 2011 18:32:36 +0000 (UTC) X-Ambrisko-Me: Yes Received: from server2.ambrisko.com (HELO internal.ambrisko.com) ([192.168.1.2]) by ironport.ambrisko.com with ESMTP; 21 Jun 2011 11:04:12 -0700 Received: from ambrisko.com (localhost [127.0.0.1]) by internal.ambrisko.com (8.14.4/8.14.4) with ESMTP id p5LI3ZxW039890; Tue, 21 Jun 2011 11:03:35 -0700 (PDT) (envelope-from ambrisko@ambrisko.com) Received: (from ambrisko@localhost) by ambrisko.com (8.14.4/8.14.4/Submit) id p5LI3ZpE039889; Tue, 21 Jun 2011 11:03:35 -0700 (PDT) (envelope-from ambrisko) From: Doug Ambrisko Message-Id: <201106211803.p5LI3ZpE039889@ambrisko.com> In-Reply-To: <20110618005124.GA43568@icarus.home.lan> To: Jeremy Chadwick Date: Tue, 21 Jun 2011 11:03:35 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL124d (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Cc: freebsd-stable@freebsd.org Subject: Re: MFC: graid(8) (RAID GEOM) support X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 18:32:39 -0000 Jeremy Chadwick writes: | Sorry for the cross-post, but I thought both lists would want to know | about this. | | Looks like mav@ just committed this ~17 hours ago: | http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/geom/raid/g_raid.c | | Those who have historically wanted to use Intel MatrixRAID (now called | Intel RST (Rapid Storage Technology)), but haven't due to the severe | issues/risks with ataraid(4), will probably be very interested in | this commit. I know I am! | | I plan on stress-testing the Intel support on a 2-disk system with | RAID-1 enabled, and will document my experiences, procedures, etc... We definitely want people to help test this out. It was designed from the start to be robust and do recovery for RAID 1 which is our use. We had previously hacked enhanced support into ataraid(4) and ata(4) for use in-house. Doug A. From owner-freebsd-stable@FreeBSD.ORG Tue Jun 21 19:02:31 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9E3E91065694; Tue, 21 Jun 2011 19:02:31 +0000 (UTC) (envelope-from hlh@restart.be) Received: from tignes.restart.be (tignes.restart.be [IPv6:2001:41d0:2:56bf:0:1::]) by mx1.freebsd.org (Postfix) with ESMTP id 1C8E08FC20; Tue, 21 Jun 2011 19:02:31 +0000 (UTC) Received: from restart.be (avoriaz.tunnel.bel [IPv6:2001:41d0:2:56bf:1:ffff::]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "smtp.restart.be", Issuer "CA master" (verified OK)) by tignes.restart.be (Postfix) with ESMTPS id 0770C143BA; Tue, 21 Jun 2011 21:02:29 +0200 (CEST) Received: from morzine.restart.bel (morzine.restart.be [IPv6:2001:41d0:2:56bf:1:2::]) (authenticated bits=0) by restart.be (8.14.5/8.14.5) with ESMTP id p5LJ2SlH027566; Tue, 21 Jun 2011 21:02:29 +0200 (CEST) (envelope-from hlh@restart.be) X-DKIM: Sendmail DKIM Filter v2.8.3 restart.be p5LJ2SlH027566 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=restart.be; s=avoriaz; t=1308682949; bh=uKSq4bavmznjd47Z69zbc7y+0URh8+Vr7PCDLRjk9v4=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=WsHV1gDFPQv0AJxDm976FWx7QV7ieawAQDf+sG5O+I4CIVMCtY+RItiuhllyOFM/8 wxT5AOfFRPuTm+SxiTuLA== X-DomainKeys: Sendmail DomainKeys Filter v1.0.2 restart.be p5LJ2SlH027566 DomainKey-Signature: a=rsa-sha1; s=avoriaz; d=restart.be; c=nofws; q=dns; h=message-id:date:from:organization:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type:content-transfer-encoding; b=iA6V4QitNsiD1hYg8mWrewHc8C1EPi7CJNPkbZpB5TRjA4HbxlMwdh5K/rhqRPPrH QS7GZHzSVI8jqcl60rioQ== Message-ID: <4E00EAC4.3050304@restart.be> Date: Tue, 21 Jun 2011 21:02:28 +0200 From: Henri Hennebert Organization: RestartSoft User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.17) Gecko/20110616 Thunderbird/3.1.10 MIME-Version: 1.0 To: John Baldwin References: <201106211155.19231.jhb@freebsd.org> <4E00C3BE.3050004@restart.be> <201106211351.45919.jhb@freebsd.org> In-Reply-To: <201106211351.45919.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: ZFS boot inside on the second partition inside a slice X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 19:02:31 -0000 On 06/21/2011 19:51, John Baldwin wrote: > On Tuesday, June 21, 2011 12:15:58 pm Henri Hennebert wrote: >> On 06/21/2011 17:55, John Baldwin wrote: >>> On Tuesday, June 21, 2011 10:50:14 am Henri Hennebert wrote: >>>> On 06/21/2011 15:01, John Baldwin wrote: >>>>> Index: zfsldr.S >>>>> =================================================================== >>>>> --- zfsldr.S (revision 223339) >>>>> +++ zfsldr.S (working copy) >>>>> @@ -234,9 +234,12 @@ nread.1: xor %ecx,%ecx # Get >>>>> callw read # Read from disk >>>>> lea 0x10(%bp),%sp # Clear stack >>>>> jnc return # If success, return >>>>> - mov $msg_read,%si # Otherwise, set the error >>>>> - # message and fall through to >>>>> - # the error routine >>>>> + mov %ah,%al # Format >>>>> + mov $read_err,%di # error >>>>> + call hex8 # code >>>>> + mov $msg_read,%si # Set the error message and >>>>> + # fall through to the error >>>>> + # routine >>>>> /* >>>>> * Print out the error message pointed to by %ds:(%si) followed >>>>> * by a prompt, wait for a keypress, and then reboot the machine. >>>>> @@ -296,12 +299,28 @@ read.1: mov $msg_chs,%si >>>>> jmp error >>>>> msg_chs: .asciz "CHS not supported" >>>>> >>>>> +/* >>>>> + * Convert AL to hex, saving the result to [EDI]. >>>>> + */ >>>>> +hex8: push %ax # Save >>>>> + shrb $0x4,%al # Do upper >>>>> + call hex8.1 # 4 >>>>> + pop %ax # Restore >>>>> +hex8.1: andb $0xf,%al # Get lower 4 >>>>> + cmpb $0xa,%al # Convert >>>>> + sbbb $0x69,%al # to hex >>>>> + das # digit >>>>> + orb $0x20,%al # To lower case >>>>> + stosb # Save char >>>>> + ret # (Recursive) >>>>> + >>>>> /* Messages */ >>>>> >>>>> -msg_read: .asciz "Read" >>>>> -msg_part: .asciz "Boot" >>>>> +msg_read: .ascii "Read error: " >>>>> +read_err: .asciz "XX" >>>>> +msg_part: .asciz "Boot error" >>>>> >>>>> -prompt: .asciz " error\r\n" >>>>> +prompt: .asciz "\r\n" >>>>> >>>>> .org PRT_OFF,0x90 >>>>> >>>> I get >>>> >>>> Read error: 01 >>> >>> Hmm, that would be 'invalid parameter'. >>> >>> Can you add a 'foo: jmp foo' infinite loop and move it around to figure > out >>> which read call is failing? >>> >> main.5: mov %dx,MEM_ARG # Save args >> movb $NSECT,%dh # Sector count >> movl $1024,%eax # Offset to boot2 >> callw nread.1 # Read disk >> >> foo: jmp foo >> >> After this one I get >> >> 'Read error: 01' > > Hmm, ok. NSECT changed in the MFC (it is now larger). Try this patch. It > changes the code to read zfsboot in one sector at a time: > I encounter 2 problems - see in you patch Henri > Index: zfsldr.S > =================================================================== > --- zfsldr.S (revision 223365) > +++ zfsldr.S (working copy) > @@ -16,7 +16,6 @@ > */ > > /* Memory Locations */ > - .set MEM_REL,0x700 # Relocation address > .set MEM_ARG,0x900 # Arguments > .set MEM_ORG,0x7c00 # Origin > .set MEM_BUF,0x8000 # Load area > @@ -91,26 +90,19 @@ main: cld # String ops inc > mov %cx,%ss # Set up > mov $start,%sp # stack > /* > - * Relocate ourself to MEM_REL. Since %cx == 0, the inc %ch sets > - * %cx == 0x100. > - */ > - mov %sp,%si # Source > - mov $MEM_REL,%di # Destination > - incb %ch # Word count > - rep # Copy > - movsw # code > -/* > * If we are on a hard drive, then load the MBR and look for the first > * FreeBSD slice. We use the fake partition entry below that points to > * the MBR when we call nread. The first pass looks for the first active > * FreeBSD slice. The second pass looks for the first non-active FreeBSD > * slice if the first one fails. > */ > - mov $part4,%si # Partition > + mov $part4,%si # Dummy partition > cmpb $0x80,%dl # Hard drive? > jb main.4 # No > - movb $0x1,%dh # Block count > - callw nread # Read MBR > + xor %eax,%eax # Read MBR from > + movw $MEM_BUF,%bx # first sector > + movb $0x1,%dh # on disk into > + callw nread # $MEM_BUF > mov $0x1,%cx # Two passes > main.1: mov $MEM_BUF+PRT_OFF,%si # Partition table > movb $0x1,%dh # Partition > @@ -161,10 +153,18 @@ main.4: xor %dx,%dx # Partition:drive > * area and target area do not overlap. > */ > main.5: mov %dx,MEM_ARG # Save args > - movb $NSECT,%dh # Sector count > + movb $NSECT,%cl # Sector count > movl $1024,%eax # Offset to boot2 > - callw nread.1 # Read disk > -main.6: mov $MEM_BUF,%si # BTX (before reloc) > + mov $MEM_BUF,%bx # Destination buffer > +main.6: pushal # Save params > + movb $1,$dh # One sector %dh | ------------------------+ > + callw nread # Read disk > + popal # Restore > + incl %eax # Update for > + add $SIZ_SEC,%bx # next sector > + dec %cx # Last sector? > + jncxz main.6 # If not, read another. Error: no such instruction: `jncxz main.6' Here I'm lost > + mov $MEM_BUF,%si # BTX (before reloc) > mov 0xa(%si),%bx # Get BTX length and set > mov $NSECT*SIZ_SEC-1,%di # Size of load area (less one) > mov %di,%si # End of load > @@ -214,12 +214,12 @@ seta20.3: sti # Enable interrupts > * packet on the stack and passes it to read. > * > * %eax - int - LBA to read in relative to partition start > + * %es:%bx - ptr - destination address > * %dl - byte - drive to read from > * %dh - byte - num sectors to read > * %si - ptr - MBR partition entry > */ > -nread: xor %eax,%eax # Sector offset in partition > -nread.1: xor %ecx,%ecx # Get > +nread: xor %ecx,%ecx # Get > addl 0x8(%si),%eax # LBA > adc $0,%ecx > pushl %ecx # Starting absolute block > @@ -234,9 +234,12 @@ seta20.3: sti # Enable interrupts > callw read # Read from disk > lea 0x10(%bp),%sp # Clear stack > jnc return # If success, return > - mov $msg_read,%si # Otherwise, set the error > - # message and fall through to > - # the error routine > + mov %ah,%al # Format > + mov $read_err,%di # error > + call hex8 # code > + mov $msg_read,%si # Set the error message and > + # fall through to the error > + # routine > /* > * Print out the error message pointed to by %ds:(%si) followed > * by a prompt, wait for a keypress, and then reboot the machine. > @@ -296,12 +299,28 @@ read.1: mov $msg_chs,%si > jmp error > msg_chs: .asciz "CHS not supported" > > +/* > + * Convert AL to hex, saving the result to [EDI]. > + */ > +hex8: push %ax # Save > + shrb $0x4,%al # Do upper > + call hex8.1 # 4 > + pop %ax # Restore > +hex8.1: andb $0xf,%al # Get lower 4 > + cmpb $0xa,%al # Convert > + sbbb $0x69,%al # to hex > + das # digit > + orb $0x20,%al # To lower case > + stosb # Save char > + ret # (Recursive) > + > /* Messages */ > > -msg_read: .asciz "Read" > -msg_part: .asciz "Boot" > +msg_read: .ascii "Read error: " > +read_err: .asciz "XX" > +msg_part: .asciz "Boot error" > > -prompt: .asciz " error\r\n" > +prompt: .asciz "\r\n" > > .org PRT_OFF,0x90 > > From owner-freebsd-stable@FreeBSD.ORG Tue Jun 21 19:16:35 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A5AE91065696 for ; Tue, 21 Jun 2011 19:16:35 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta03.emeryville.ca.mail.comcast.net (qmta03.emeryville.ca.mail.comcast.net [76.96.30.32]) by mx1.freebsd.org (Postfix) with ESMTP id 8EE888FC14 for ; Tue, 21 Jun 2011 19:16:35 +0000 (UTC) Received: from omta22.emeryville.ca.mail.comcast.net ([76.96.30.89]) by qmta03.emeryville.ca.mail.comcast.net with comcast id yiDS1g00A1vN32cA3jGZH3; Tue, 21 Jun 2011 19:16:33 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta22.emeryville.ca.mail.comcast.net with comcast id yjGF1g0171t3BNj8ijGLHs; Tue, 21 Jun 2011 19:16:20 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id D4055102C36; Tue, 21 Jun 2011 12:16:26 -0700 (PDT) Date: Tue, 21 Jun 2011 12:16:26 -0700 From: Jeremy Chadwick To: freebsd-stable@freebsd.org Message-ID: <20110621191626.GA99204@icarus.home.lan> References: <20110618005124.GA43568@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110618005124.GA43568@icarus.home.lan> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-fs@freebsd.org, mav@freebsd.org Subject: Re: MFC: graid(8) (RAID GEOM) support X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 19:16:35 -0000 On Fri, Jun 17, 2011 at 05:51:24PM -0700, Jeremy Chadwick wrote: > Sorry for the cross-post, but I thought both lists would want to know > about this. > > Looks like mav@ just committed this ~17 hours ago: > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/geom/raid/g_raid.c > > Those who have historically wanted to use Intel MatrixRAID (now called > Intel RST (Rapid Storage Technology)), but haven't due to the severe > issues/risks with ataraid(4), will probably be very interested in > this commit. I know I am! > > I plan on stress-testing the Intel support on a 2-disk system with > RAID-1 enabled, and will document my experiences, procedures, etc... > > Thanks, mav@ and imp@ ! > > I'll be sending another mail momentarily asking about USB memory stick > image building, since to accomplish the above, I want to do a > "bare-bones" install on our test system (e.g. enable Intel RAID, set up > 2 disks in a RAID-1 mirror, boot a USB memory stick that contains this > latest RELENG_8 build, and do sysinstall, etc.. the normal way). > > > ===================================================================== > MFC r219974, r220209, r220210, r220790: > Add new RAID GEOM class, that is going to replace ataraid(4) in supporting > various BIOS-based software RAIDs. Unlike ataraid(4) this implementation > does not depend on legacy ata(4) subsystem and can be used with any disk > drivers, including new CAM-based ones (ahci(4), siis(4), mvs(4), ata(4) > with `options ATA_CAM`). To make code more readable and extensible, this > implementation follows modular design, including core part and two sets > of modules, implementing support for different metadata formats and RAID > levels. > > Support for such popular metadata formats is now implemented: > Intel, JMicron, NVIDIA, Promise (also used by AMD/ATI) and SiliconImage. > > Such RAID levels are now supported: > RAID0, RAID1, RAID1E, RAID10, SINGLE, CONCAT. > > For all of these RAID levels and metadata formats this class supports > full cycle of volume operations: reading, writing, creation, deletion, > disk removal and insertion, rebuilding, dirty shutdown detection > and resynchronization, bad sector recovery, faulty disks tracking, > hot-spare disks. For Intel and Promise formats there is support multiple > volumes per disk set. > > Look graid(8) manual page for additional details. > > Co-authored by: imp > Sponsored by: Cisco Systems, Inc. and iXsystems, Inc. > ===================================================================== By the way, it doesn't look like the graid(8) man page is being brought in to the base system on either of the two RELENG_8 systems I've rebuilt in the past few days. I'm thinking /usr/src/sbin/geom/class/raid/graid.8 isn't being noticed as a man page. /usr/src/sbin/geom/class/raid/Makefile doesn't have MAN8=graid.8 in it, is that the problem? -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Tue Jun 21 19:25:37 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 87E7F1065680 for ; Tue, 21 Jun 2011 19:25:37 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 5F5B18FC1A for ; Tue, 21 Jun 2011 19:25:37 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id F0D6B46B1A; Tue, 21 Jun 2011 15:25:36 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 78C5D8A01F; Tue, 21 Jun 2011 15:25:36 -0400 (EDT) From: John Baldwin To: Henri Hennebert Date: Tue, 21 Jun 2011 15:25:35 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110325; KDE/4.5.5; amd64; ; ) References: <201106211351.45919.jhb@freebsd.org> <4E00EAC4.3050304@restart.be> In-Reply-To: <4E00EAC4.3050304@restart.be> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201106211525.35938.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Tue, 21 Jun 2011 15:25:36 -0400 (EDT) Cc: freebsd-stable@freebsd.org Subject: Re: ZFS boot inside on the second partition inside a slice X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 19:25:37 -0000 On Tuesday, June 21, 2011 3:02:28 pm Henri Hennebert wrote: > On 06/21/2011 19:51, John Baldwin wrote: > > On Tuesday, June 21, 2011 12:15:58 pm Henri Hennebert wrote: > >> On 06/21/2011 17:55, John Baldwin wrote: > >>> On Tuesday, June 21, 2011 10:50:14 am Henri Hennebert wrote: > >>>> On 06/21/2011 15:01, John Baldwin wrote: > >>>>> Index: zfsldr.S > >>>>> =================================================================== > >>>>> --- zfsldr.S (revision 223339) > >>>>> +++ zfsldr.S (working copy) > >>>>> @@ -234,9 +234,12 @@ nread.1: xor %ecx,%ecx # Get > >>>>> callw read # Read from disk > >>>>> lea 0x10(%bp),%sp # Clear stack > >>>>> jnc return # If success, return > >>>>> - mov $msg_read,%si # Otherwise, set the error > >>>>> - # message and fall through to > >>>>> - # the error routine > >>>>> + mov %ah,%al # Format > >>>>> + mov $read_err,%di # error > >>>>> + call hex8 # code > >>>>> + mov $msg_read,%si # Set the error message and > >>>>> + # fall through to the error > >>>>> + # routine > >>>>> /* > >>>>> * Print out the error message pointed to by %ds:(%si) followed > >>>>> * by a prompt, wait for a keypress, and then reboot the machine. > >>>>> @@ -296,12 +299,28 @@ read.1: mov $msg_chs,%si > >>>>> jmp error > >>>>> msg_chs: .asciz "CHS not supported" > >>>>> > >>>>> +/* > >>>>> + * Convert AL to hex, saving the result to [EDI]. > >>>>> + */ > >>>>> +hex8: push %ax # Save > >>>>> + shrb $0x4,%al # Do upper > >>>>> + call hex8.1 # 4 > >>>>> + pop %ax # Restore > >>>>> +hex8.1: andb $0xf,%al # Get lower 4 > >>>>> + cmpb $0xa,%al # Convert > >>>>> + sbbb $0x69,%al # to hex > >>>>> + das # digit > >>>>> + orb $0x20,%al # To lower case > >>>>> + stosb # Save char > >>>>> + ret # (Recursive) > >>>>> + > >>>>> /* Messages */ > >>>>> > >>>>> -msg_read: .asciz "Read" > >>>>> -msg_part: .asciz "Boot" > >>>>> +msg_read: .ascii "Read error: " > >>>>> +read_err: .asciz "XX" > >>>>> +msg_part: .asciz "Boot error" > >>>>> > >>>>> -prompt: .asciz " error\r\n" > >>>>> +prompt: .asciz "\r\n" > >>>>> > >>>>> .org PRT_OFF,0x90 > >>>>> > >>>> I get > >>>> > >>>> Read error: 01 > >>> > >>> Hmm, that would be 'invalid parameter'. > >>> > >>> Can you add a 'foo: jmp foo' infinite loop and move it around to figure > > out > >>> which read call is failing? > >>> > >> main.5: mov %dx,MEM_ARG # Save args > >> movb $NSECT,%dh # Sector count > >> movl $1024,%eax # Offset to boot2 > >> callw nread.1 # Read disk > >> > >> foo: jmp foo > >> > >> After this one I get > >> > >> 'Read error: 01' > > > > Hmm, ok. NSECT changed in the MFC (it is now larger). Try this patch. It > > changes the code to read zfsboot in one sector at a time: > > > > I encounter 2 problems - see in you patch > > Henri > > > > Index: zfsldr.S > > =================================================================== > > --- zfsldr.S (revision 223365) > > +++ zfsldr.S (working copy) > > @@ -16,7 +16,6 @@ > > */ > > > > /* Memory Locations */ > > - .set MEM_REL,0x700 # Relocation address > > .set MEM_ARG,0x900 # Arguments > > .set MEM_ORG,0x7c00 # Origin > > .set MEM_BUF,0x8000 # Load area > > @@ -91,26 +90,19 @@ main: cld # String ops inc > > mov %cx,%ss # Set up > > mov $start,%sp # stack > > /* > > - * Relocate ourself to MEM_REL. Since %cx == 0, the inc %ch sets > > - * %cx == 0x100. > > - */ > > - mov %sp,%si # Source > > - mov $MEM_REL,%di # Destination > > - incb %ch # Word count > > - rep # Copy > > - movsw # code > > -/* > > * If we are on a hard drive, then load the MBR and look for the first > > * FreeBSD slice. We use the fake partition entry below that points to > > * the MBR when we call nread. The first pass looks for the first active > > * FreeBSD slice. The second pass looks for the first non-active FreeBSD > > * slice if the first one fails. > > */ > > - mov $part4,%si # Partition > > + mov $part4,%si # Dummy partition > > cmpb $0x80,%dl # Hard drive? > > jb main.4 # No > > - movb $0x1,%dh # Block count > > - callw nread # Read MBR > > + xor %eax,%eax # Read MBR from > > + movw $MEM_BUF,%bx # first sector > > + movb $0x1,%dh # on disk into > > + callw nread # $MEM_BUF > > mov $0x1,%cx # Two passes > > main.1: mov $MEM_BUF+PRT_OFF,%si # Partition table > > movb $0x1,%dh # Partition > > @@ -161,10 +153,18 @@ main.4: xor %dx,%dx # Partition:drive > > * area and target area do not overlap. > > */ > > main.5: mov %dx,MEM_ARG # Save args > > - movb $NSECT,%dh # Sector count > > + movb $NSECT,%cl # Sector count > > movl $1024,%eax # Offset to boot2 > > - callw nread.1 # Read disk > > -main.6: mov $MEM_BUF,%si # BTX (before reloc) > > + mov $MEM_BUF,%bx # Destination buffer > > +main.6: pushal # Save params > > + movb $1,$dh # One sector > %dh > | > ------------------------+ > > > + callw nread # Read disk > > + popal # Restore > > + incl %eax # Update for > > + add $SIZ_SEC,%bx # next sector > > + dec %cx # Last sector? > > + jncxz main.6 # If not, read another. > > Error: no such instruction: `jncxz main.6' Ah, jcxnz instead (jump if cx is non-zero) -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Tue Jun 21 20:13:23 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2871B1065675; Tue, 21 Jun 2011 20:13:23 +0000 (UTC) (envelope-from hlh@restart.be) Received: from tignes.restart.be (tignes.restart.be [IPv6:2001:41d0:2:56bf:0:1::]) by mx1.freebsd.org (Postfix) with ESMTP id 9A1078FC12; Tue, 21 Jun 2011 20:13:22 +0000 (UTC) Received: from restart.be (avoriaz.tunnel.bel [IPv6:2001:41d0:2:56bf:1:ffff::]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "smtp.restart.be", Issuer "CA master" (verified OK)) by tignes.restart.be (Postfix) with ESMTPS id C138714505; Tue, 21 Jun 2011 22:13:21 +0200 (CEST) Received: from morzine.restart.bel (morzine.restart.be [IPv6:2001:41d0:2:56bf:1:2::]) (authenticated bits=0) by restart.be (8.14.5/8.14.5) with ESMTP id p5LKDKso029171; Tue, 21 Jun 2011 22:13:20 +0200 (CEST) (envelope-from hlh@restart.be) X-DKIM: Sendmail DKIM Filter v2.8.3 restart.be p5LKDKso029171 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=restart.be; s=avoriaz; t=1308687201; bh=UP1RYGRbZQlHvMvGKLLreYLpw+hnIlnRMwjKDqHmtnM=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=ZepcwxyzW5H6/gk9e0kdg74dRB6/QXZejORUfAHEQTddJ1e841tR+NxHTtvJs2lGs mryLQ6OuPeRIQsQk63YAQ== X-DomainKeys: Sendmail DomainKeys Filter v1.0.2 restart.be p5LKDKso029171 DomainKey-Signature: a=rsa-sha1; s=avoriaz; d=restart.be; c=nofws; q=dns; h=message-id:date:from:organization:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type:content-transfer-encoding; b=bT8ZZxNo4RabCiEcVQ6UZNeC4w2UxghC3RHhLSMDkreEN3fOcPM0y0Lj7fUM2yz2t X7+8lyQml0ZZKPtN+S09Q== Message-ID: <4E00FB60.8080407@restart.be> Date: Tue, 21 Jun 2011 22:13:20 +0200 From: Henri Hennebert Organization: RestartSoft User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.17) Gecko/20110616 Thunderbird/3.1.10 MIME-Version: 1.0 To: John Baldwin References: <201106211351.45919.jhb@freebsd.org> <4E00EAC4.3050304@restart.be> <201106211525.35938.jhb@freebsd.org> In-Reply-To: <201106211525.35938.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: ZFS boot inside on the second partition inside a slice X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 20:13:23 -0000 On 06/21/2011 21:25, John Baldwin wrote: > On Tuesday, June 21, 2011 3:02:28 pm Henri Hennebert wrote: >> On 06/21/2011 19:51, John Baldwin wrote: >>> On Tuesday, June 21, 2011 12:15:58 pm Henri Hennebert wrote: >>>> On 06/21/2011 17:55, John Baldwin wrote: >>>>> On Tuesday, June 21, 2011 10:50:14 am Henri Hennebert wrote: >>>>>> On 06/21/2011 15:01, John Baldwin wrote: >>>>>>> Index: zfsldr.S >>>>>>> =================================================================== >>>>>>> --- zfsldr.S (revision 223339) >>>>>>> +++ zfsldr.S (working copy) >>>>>>> @@ -234,9 +234,12 @@ nread.1: xor %ecx,%ecx # Get >>>>>>> callw read # Read from disk >>>>>>> lea 0x10(%bp),%sp # Clear stack >>>>>>> jnc return # If success, return >>>>>>> - mov $msg_read,%si # Otherwise, set the error >>>>>>> - # message and fall through to >>>>>>> - # the error routine >>>>>>> + mov %ah,%al # Format >>>>>>> + mov $read_err,%di # error >>>>>>> + call hex8 # code >>>>>>> + mov $msg_read,%si # Set the error message and >>>>>>> + # fall through to the error >>>>>>> + # routine >>>>>>> /* >>>>>>> * Print out the error message pointed to by %ds:(%si) followed >>>>>>> * by a prompt, wait for a keypress, and then reboot the machine. >>>>>>> @@ -296,12 +299,28 @@ read.1: mov $msg_chs,%si >>>>>>> jmp error >>>>>>> msg_chs: .asciz "CHS not supported" >>>>>>> >>>>>>> +/* >>>>>>> + * Convert AL to hex, saving the result to [EDI]. >>>>>>> + */ >>>>>>> +hex8: push %ax # Save >>>>>>> + shrb $0x4,%al # Do upper >>>>>>> + call hex8.1 # 4 >>>>>>> + pop %ax # Restore >>>>>>> +hex8.1: andb $0xf,%al # Get lower 4 >>>>>>> + cmpb $0xa,%al # Convert >>>>>>> + sbbb $0x69,%al # to hex >>>>>>> + das # digit >>>>>>> + orb $0x20,%al # To lower case >>>>>>> + stosb # Save char >>>>>>> + ret # (Recursive) >>>>>>> + >>>>>>> /* Messages */ >>>>>>> >>>>>>> -msg_read: .asciz "Read" >>>>>>> -msg_part: .asciz "Boot" >>>>>>> +msg_read: .ascii "Read error: " >>>>>>> +read_err: .asciz "XX" >>>>>>> +msg_part: .asciz "Boot error" >>>>>>> >>>>>>> -prompt: .asciz " error\r\n" >>>>>>> +prompt: .asciz "\r\n" >>>>>>> >>>>>>> .org PRT_OFF,0x90 >>>>>>> >>>>>> I get >>>>>> >>>>>> Read error: 01 >>>>> >>>>> Hmm, that would be 'invalid parameter'. >>>>> >>>>> Can you add a 'foo: jmp foo' infinite loop and move it around to figure >>> out >>>>> which read call is failing? >>>>> >>>> main.5: mov %dx,MEM_ARG # Save args >>>> movb $NSECT,%dh # Sector count >>>> movl $1024,%eax # Offset to boot2 >>>> callw nread.1 # Read disk >>>> >>>> foo: jmp foo >>>> >>>> After this one I get >>>> >>>> 'Read error: 01' >>> >>> Hmm, ok. NSECT changed in the MFC (it is now larger). Try this patch. > It >>> changes the code to read zfsboot in one sector at a time: >>> >> >> I encounter 2 problems - see in you patch >> >> Henri >> >> >>> Index: zfsldr.S >>> =================================================================== >>> --- zfsldr.S (revision 223365) >>> +++ zfsldr.S (working copy) >>> @@ -16,7 +16,6 @@ >>> */ >>> >>> /* Memory Locations */ >>> - .set MEM_REL,0x700 # Relocation address >>> .set MEM_ARG,0x900 # Arguments >>> .set MEM_ORG,0x7c00 # Origin >>> .set MEM_BUF,0x8000 # Load area >>> @@ -91,26 +90,19 @@ main: cld # String ops inc >>> mov %cx,%ss # Set up >>> mov $start,%sp # stack >>> /* >>> - * Relocate ourself to MEM_REL. Since %cx == 0, the inc %ch sets >>> - * %cx == 0x100. >>> - */ >>> - mov %sp,%si # Source >>> - mov $MEM_REL,%di # Destination >>> - incb %ch # Word count >>> - rep # Copy >>> - movsw # code >>> -/* >>> * If we are on a hard drive, then load the MBR and look for the first >>> * FreeBSD slice. We use the fake partition entry below that points to >>> * the MBR when we call nread. The first pass looks for the first > active >>> * FreeBSD slice. The second pass looks for the first non-active > FreeBSD >>> * slice if the first one fails. >>> */ >>> - mov $part4,%si # Partition >>> + mov $part4,%si # Dummy partition >>> cmpb $0x80,%dl # Hard drive? >>> jb main.4 # No >>> - movb $0x1,%dh # Block count >>> - callw nread # Read MBR >>> + xor %eax,%eax # Read MBR from >>> + movw $MEM_BUF,%bx # first sector >>> + movb $0x1,%dh # on disk into >>> + callw nread # $MEM_BUF >>> mov $0x1,%cx # Two passes >>> main.1: mov $MEM_BUF+PRT_OFF,%si # Partition table >>> movb $0x1,%dh # Partition >>> @@ -161,10 +153,18 @@ main.4: xor %dx,%dx # Partition:drive >>> * area and target area do not overlap. >>> */ >>> main.5: mov %dx,MEM_ARG # Save args >>> - movb $NSECT,%dh # Sector count >>> + movb $NSECT,%cl # Sector count >>> movl $1024,%eax # Offset to boot2 >>> - callw nread.1 # Read disk >>> -main.6: mov $MEM_BUF,%si # BTX (before reloc) >>> + mov $MEM_BUF,%bx # Destination buffer >>> +main.6: pushal # Save params >>> + movb $1,$dh # One sector >> %dh >> | >> ------------------------+ >> >>> + callw nread # Read disk >>> + popal # Restore >>> + incl %eax # Update for >>> + add $SIZ_SEC,%bx # next sector >>> + dec %cx # Last sector? >>> + jncxz main.6 # If not, read another. >> >> Error: no such instruction: `jncxz main.6' > > Ah, jcxnz instead (jump if cx is non-zero) > > I have to use: jcxz main.7 # If not, read another. jmp main.6 main.7: mov $MEM_BUF,%si # BTX (before reloc) and I get: Read error: 04 Henri From owner-freebsd-stable@FreeBSD.ORG Tue Jun 21 21:27:28 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BFED0106568D for ; Tue, 21 Jun 2011 21:27:28 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 968AB8FC19 for ; Tue, 21 Jun 2011 21:27:28 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 2B7A646B1A; Tue, 21 Jun 2011 17:27:28 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 4C64F8A01F; Tue, 21 Jun 2011 17:27:27 -0400 (EDT) From: John Baldwin To: Henri Hennebert Date: Tue, 21 Jun 2011 17:27:26 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110617; KDE/4.5.5; amd64; ; ) References: <201106211525.35938.jhb@freebsd.org> <4E00FB60.8080407@restart.be> In-Reply-To: <4E00FB60.8080407@restart.be> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201106211727.26413.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Tue, 21 Jun 2011 17:27:27 -0400 (EDT) Cc: freebsd-stable@freebsd.org Subject: Re: ZFS boot inside on the second partition inside a slice X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 21:27:28 -0000 On Tuesday, June 21, 2011 4:13:20 pm Henri Hennebert wrote: > On 06/21/2011 21:25, John Baldwin wrote: > and I get: > > Read error: 04 Hmm, that is the error for an invalid sector. Try this patch. It reshuffles a few more things and adds code to dump the low 32-bits of the LBA on an error: Index: zfsldr.S =================================================================== --- zfsldr.S (revision 223365) +++ zfsldr.S (working copy) @@ -16,7 +16,6 @@ */ /* Memory Locations */ - .set MEM_REL,0x700 # Relocation address .set MEM_ARG,0x900 # Arguments .set MEM_ORG,0x7c00 # Origin .set MEM_BUF,0x8000 # Load area @@ -91,26 +90,18 @@ main: cld # String ops inc mov %cx,%ss # Set up mov $start,%sp # stack /* - * Relocate ourself to MEM_REL. Since %cx == 0, the inc %ch sets - * %cx == 0x100. - */ - mov %sp,%si # Source - mov $MEM_REL,%di # Destination - incb %ch # Word count - rep # Copy - movsw # code -/* * If we are on a hard drive, then load the MBR and look for the first * FreeBSD slice. We use the fake partition entry below that points to * the MBR when we call nread. The first pass looks for the first active * FreeBSD slice. The second pass looks for the first non-active FreeBSD * slice if the first one fails. */ - mov $part4,%si # Partition + mov $part4,%si # Dummy partition cmpb $0x80,%dl # Hard drive? jb main.4 # No - movb $0x1,%dh # Block count - callw nread # Read MBR + xor %eax,%eax # Read MBR + movw $MEM_BUF,%bx # from first + callw nread # sector mov $0x1,%cx # Two passes main.1: mov $MEM_BUF+PRT_OFF,%si # Partition table movb $0x1,%dh # Partition @@ -161,10 +152,16 @@ main.4: xor %dx,%dx # Partition:drive * area and target area do not overlap. */ main.5: mov %dx,MEM_ARG # Save args - movb $NSECT,%dh # Sector count + mov $NSECT,%cx # Sector count movl $1024,%eax # Offset to boot2 - callw nread.1 # Read disk -main.6: mov $MEM_BUF,%si # BTX (before reloc) + mov $MEM_BUF,%bx # Destination buffer +main.6: pushal # Save params + callw nread # Read disk + popal # Restore + incl %eax # Update for + add $SIZ_SEC,%bx # next sector + loop main.6 # If not last, read another + mov $MEM_BUF,%si # BTX (before reloc) mov 0xa(%si),%bx # Get BTX length and set mov $NSECT*SIZ_SEC-1,%di # Size of load area (less one) mov %di,%si # End of load @@ -214,29 +211,35 @@ seta20.3: sti # Enable interrupts * packet on the stack and passes it to read. * * %eax - int - LBA to read in relative to partition start + * %es:%bx - ptr - destination address * %dl - byte - drive to read from - * %dh - byte - num sectors to read * %si - ptr - MBR partition entry */ -nread: xor %eax,%eax # Sector offset in partition -nread.1: xor %ecx,%ecx # Get +nread: xor %ecx,%ecx # Get addl 0x8(%si),%eax # LBA adc $0,%ecx pushl %ecx # Starting absolute block pushl %eax # block number push %es # Address of - push $MEM_BUF # transfer buffer - xor %ax,%ax # Number of - movb %dh,%al # blocks to - push %ax # transfer + push %bx # transfer buffer + push $0x1 # Read 1 sector push $0x10 # Size of packet mov %sp,%bp # Packet pointer callw read # Read from disk lea 0x10(%bp),%sp # Clear stack - jnc return # If success, return - mov $msg_read,%si # Otherwise, set the error - # message and fall through to - # the error routine + jc nread.1 # If error, fail + ret # If success, return +nread.1: mov %ah,%al # Format + mov $read_err,%di # error + call hex8 # code + movl 0x4(%si),%eax # Format + mov $lba,%di # LBA + call hex32 + mov $msg_lba,%si # Display + call putstr # LBA + mov $msg_read,%si # Set the error message and + # fall through to the error + # routine /* * Print out the error message pointed to by %ds:(%si) followed * by a prompt, wait for a keypress, and then reboot the machine. @@ -259,14 +262,6 @@ putstr: lodsb # Get char jne putstr.0 # No /* - * Overused return code. ereturn is used to return an error from the - * read function. Since we assume putstr succeeds, we (ab)use the - * same code when we return from putstr. - */ -ereturn: movb $0x1,%ah # Invalid - stc # argument -return: retw # To caller -/* * Reads sectors from the disk. If EDD is enabled, then check if it is * installed and use it if it is. If it is not installed or not enabled, then * fall back to using CHS. Since we use a LBA, if we are using CHS, we have to @@ -294,14 +289,38 @@ read: cmpb $0x80,%dl # Hard drive? retw # To caller read.1: mov $msg_chs,%si jmp error -msg_chs: .asciz "CHS not supported" +/* + * Convert EAX, AX, or AL to hex, saving the result to [EDI]. + */ +hex32: pushl %eax # Save + shrl $0x10,%eax # Do upper + call hex16 # 16 + popl %eax # Restore +hex16: call hex16.1 # Do upper 8 +hex16.1: xchgb %ah,%al # Save/restore +hex8: push %ax # Save + shrb $0x4,%al # Do upper + call hex8.1 # 4 + pop %ax # Restore +hex8.1: andb $0xf,%al # Get lower 4 + cmpb $0xa,%al # Convert + sbbb $0x69,%al # to hex + das # digit + orb $0x20,%al # To lower case + stosb # Save char + ret # (Recursive) + /* Messages */ -msg_read: .asciz "Read" -msg_part: .asciz "Boot" +msg_chs: .asciz "CHS not supported" +msg_read: .ascii "Read error: " +read_err: .asciz "XX" +msg_lba: .ascii "LBA: " +lba: .asciz "XXXXXXXX\r\n" +msg_part: .asciz "Boot error" -prompt: .asciz " error\r\n" +prompt: .asciz "\r\n" .org PRT_OFF,0x90 -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Wed Jun 22 00:42:19 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 151891065676 for ; Wed, 22 Jun 2011 00:42:19 +0000 (UTC) (envelope-from kirk@strauser.com) Received: from kanga.honeypot.net (kanga.honeypot.net [IPv6:2001:470:a80a:1:21f:d0ff:fe22:b8a8]) by mx1.freebsd.org (Postfix) with ESMTP id 6F9BE8FC08 for ; Wed, 22 Jun 2011 00:42:18 +0000 (UTC) Received: from kanga.honeypot.net (localhost [127.0.0.1]) by kanga.honeypot.net (Postfix) with ESMTP id 2F74B5EF3A for ; Tue, 21 Jun 2011 19:42:16 -0500 (CDT) X-Virus-Scanned: amavisd-new at honeypot.net Received: from kanga.honeypot.net ([127.0.0.1]) by kanga.honeypot.net (kanga.honeypot.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id YQ2Yj+Q+VmeB for ; Tue, 21 Jun 2011 19:42:10 -0500 (CDT) Received: from pooh.honeypot.net (pooh.honeypot.net [10.0.5.130]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by kanga.honeypot.net (Postfix) with ESMTPSA id 5E3CC5EAD1 for ; Tue, 21 Jun 2011 19:34:39 -0500 (CDT) Message-Id: <621C04D8-6867-44D9-80E9-1E854B6154CD@strauser.com> From: Kirk Strauser To: FreeBSD Stable In-Reply-To: <84E92041-C897-4744-B432-CA3537EE156F@strauser.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 21 Jun 2011 19:34:36 -0500 References: <84E92041-C897-4744-B432-CA3537EE156F@strauser.com> X-Mailer: Apple Mail (2.936) Subject: SOLVED (was: re0 died last night; here's how I half-revived it) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 00:42:19 -0000 I found the problem: sometime between the May 8 kernel I'd been using and the new one (latest build: 15:02:36 CST today), my system decided to devour socket buffers. I set kern.ipc.maxsockbuf=16777216 and have over an hour of stable multi-user uptime, which is a vast improvement! On Jun 9, 2011, at 9:37 AM, Kirk Strauser wrote: > I have a FreeBSD 8-STABLE system that's been running stably since I > last upgraded and rebooted on May 8. Yesterday, I updated /usr/src > to get ZFS v28 and also seem to have gotten rid of my nice, solid > re0 network interface: > > re0: port > 0xb000-0xb0ff mem 0xea210000-0xea210fff,0xea200000-0xea20ffff irq 16 > at device 0.0 on pci5 > re0: Using 1 MSI-X message > re0: Chip rev. 0x3c000000 > re0: MAC rev. 0x00400000 > miibus0: on re0 > > I'm too tired from lack of sleep due to getting the system back up > and running to remember all the details, but the summary is that it > started autodetecting its media as 10baseT/UTP. Almost immediately > after boot - sometimes while still playing in single-user mode - I'd > start seeing "no buffer space available" error messages all over the > place. > > Forcing media to 1000baseTX/full-duplex fixed the problem for a few > minutes, but it wouldn't stay in that state and would shortly start > throwing "no buffer space available" errors again. Until I've gotten > some sleep and have more mental energy to figure out exactly what's > going on, I've found that forcing the media to 100baseTX keeps it > solidly chugging along (if a little slowly). > > Anyway, that's where I'm at now. If your re NIC is giving you fits > this morning, try setting it to 100baseTX and see if that'll get you > running until a better fix comes along. > > - Kirk > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org > " From owner-freebsd-stable@FreeBSD.ORG Wed Jun 22 02:59:50 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B0B21106568D for ; Wed, 22 Jun 2011 02:59:50 +0000 (UTC) (envelope-from boydjd@jbip.net) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 964068FC23 for ; Wed, 22 Jun 2011 02:59:49 +0000 (UTC) Received: by fxm11 with SMTP id 11so520598fxm.13 for ; Tue, 21 Jun 2011 19:59:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jbip.net; s=google; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=UWIN5AoM1bGIWKEgWMNZWubba6x0shtXWJVz2cG7yP4=; b=Mu+a+tQL4a6E+NJw1qQMaRzDrvYxWZB3sgbd4E0rxfX/LfFTZo9SAoorelJ+b81WQG H0BrWOihlnb3gt22EYjlr1srDBxdobLo/Xry6p33h0Nv2m9fFgSRtsNJpTqTPiBe1s+5 K2myPoFRDwLMJjTY1ZFUXKNCKHWo9ZfMsB0wY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=jbip.net; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=WL8ky4I5SRukWtSHsA39qMuBtjMJxRxsvUllqHlE/rwLia566skv904ce469DxFj0i 5vLY9twz40rQPkXSID4jFJiXWutT9cTt1pnnmUMMsiUIzMsOVb8rccTQWefmoss3GSNC ndmSxxz18qmactndpw8v/ZX3eWDccCqz6u+3k= Received: by 10.223.7.150 with SMTP id d22mr124786fad.17.1308711588218; Tue, 21 Jun 2011 19:59:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.25.1 with HTTP; Tue, 21 Jun 2011 19:59:28 -0700 (PDT) In-Reply-To: References: <20110615075754.GA54879@icarus.home.lan> From: Joshua Boyd Date: Tue, 21 Jun 2011 22:59:28 -0400 Message-ID: To: Jack Vogel Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable , "Vogel, Jack" , Jeremy Chadwick Subject: Re: em0 watchdog timeouts on 8-STABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 02:59:50 -0000 If needed, I can reproduce this on demand. Just need to know what sort of statistics are needed when the problem is occurring. I've had to turn off my weekly scrubs until I can figure out how to fix this problem. On Wed, Jun 15, 2011 at 8:37 PM, Joshua Boyd wrote: > In the kernel. Here's my kernel configuration: > > http://pastebin.com/raw.php?i=4JL814m3 > > On Wed, Jun 15, 2011 at 8:20 PM, Jack Vogel wrote: > >> I have hardware now, am working on reproducing this. Just curious, do you >> have >> the em driver defined in the kernel, or as a module? >> >> Jack >> >> >> On Wed, Jun 15, 2011 at 2:09 AM, Joshua Boyd wrote: >> >>> On Wed, Jun 15, 2011 at 3:57 AM, Jeremy Chadwick >>> wrote: >>> >>> > On Wed, Jun 15, 2011 at 03:14:43AM -0400, Joshua Boyd wrote: >>> > > I recently updated my server to the latest 8-STABLE, and upgraded to >>> v28 >>> > > ZFS. I have not had these problems on any other version of 8-STABLE >>> or >>> > > 7-STABLE, which this box was upgraded from some time ago. >>> > > >>> > > Now, during my weekly scrub, I get the following messages and em0 is >>> > > unresponsive: >>> > > >>> > > Jun 12 03:07:58 foghornleghorn kernel: em0: Watchdog timeout -- >>> resetting >>> > > Jun 12 03:07:58 foghornleghorn kernel: em0: link state changed to >>> DOWN >>> > > Jun 12 03:08:01 foghornleghorn kernel: em0: link state changed to UP >>> > > Jun 12 03:08:47 foghornleghorn kernel: em0: Watchdog timeout -- >>> resetting >>> > > Jun 12 03:08:47 foghornleghorn kernel: em0: link state changed to >>> DOWN >>> > > Jun 12 03:08:50 foghornleghorn kernel: em0: link state changed to UP >>> > > >>> > > My scrub is scheduled to start at 03:00:00, so it looks like watchdog >>> > > timeouts start occurring pretty quickly once I/O ramps up. >>> > > >>> > > Here's some possibly relevant information, let me know if anything >>> else >>> > > would be helpful to troubleshoot. >>> > > >>> > > FreeBSD foghornleghorn.res.openband.net 8.2-STABLE FreeBSD >>> 8.2-STABLE >>> > #17: >>> > > Mon Jun 6 19:40:19 EDT 2011 >>> > > root@foghornleghorn.res.openband.net: >>> /usr/obj/usr/src/sys/FOGHORNLEGHORN >>> > > amd64 >>> > > >>> > > em0: port >>> > 0xe800-0xe83f >>> > > mem 0xfebe0000-0xfebfffff,0xfebc0000-0xfebdffff irq 20 at device 5.0 >>> on >>> > pci7 >>> > > >>> > > em0@pci0:7:5:0: class=0x020000 card=0x13768086 chip=0x107c8086 >>> rev=0x05 >>> > > hdr=0x00 >>> > > vendor = 'Intel Corporation' >>> > > device = 'Gigabit Ethernet Controller (Copper) rev 5 >>> (82541PI)' >>> > > class = network >>> > > subclass = ethernet >>> > > >>> > > And, the SAS cards: >>> > > >>> > > dev.mpt.0.%desc: LSILogic SAS/SATA Adapter >>> > > dev.mpt.0.%driver: mpt >>> > > dev.mpt.0.%location: slot=0 function=0 >>> > > dev.mpt.0.%pnpinfo: vendor=0x1000 device=0x0058 subvendor=0x15d9 >>> > > subdevice=0xa580 class=0x010000 >>> > > dev.mpt.0.%parent: pci1 >>> > > dev.mpt.0.debug: 3 >>> > > dev.mpt.0.role: 1 >>> > > dev.mpt.1.%desc: LSILogic SAS/SATA Adapter >>> > > dev.mpt.1.%driver: mpt >>> > > dev.mpt.1.%location: slot=0 function=0 >>> > > dev.mpt.1.%pnpinfo: vendor=0x1000 device=0x0058 subvendor=0x15d9 >>> > > subdevice=0xa580 class=0x010000 >>> > > dev.mpt.1.%parent: pci2 >>> > > dev.mpt.1.debug: 3 >>> > > dev.mpt.1.role: 1 >>> > > dev.mpt.2.%desc: LSILogic SAS/SATA Adapter >>> > > dev.mpt.2.%driver: mpt >>> > > dev.mpt.2.%location: slot=0 function=0 >>> > > dev.mpt.2.%pnpinfo: vendor=0x1000 device=0x0058 subvendor=0x1000 >>> > > subdevice=0x30a0 class=0x010000 >>> > > dev.mpt.2.%parent: pci6 >>> > > dev.mpt.2.debug: 3 >>> > > dev.mpt.2.role: 1 >>> > >>> > Please provide output from the following commands (as root): >>> > >>> > # pciconf -lvcb >>> > >>> >>> hostb0@pci0:0:0:0: class=0x060000 card=0x59561002 chip=0x59561002 >>> rev=0x00 >>> hdr=0x00 >>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>> device = 'RD790 GFX Dual Slot' >>> class = bridge >>> subclass = HOST-PCI >>> pcib1@pci0:0:2:0: class=0x060400 card=0x59561002 chip=0x59781002 >>> rev=0x00 >>> hdr=0x01 >>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>> device = 'RD790 PCI to PCI bridge (external gfx0 port A)' >>> class = bridge >>> subclass = PCI-PCI >>> pcib2@pci0:0:3:0: class=0x060400 card=0x59561002 chip=0x59791002 >>> rev=0x00 >>> hdr=0x01 >>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>> device = 'RD790 PCI to PCI bridge (external gfx0 port B)' >>> class = bridge >>> subclass = PCI-PCI >>> pcib3@pci0:0:4:0: class=0x060400 card=0x59561002 chip=0x597a1002 >>> rev=0x00 >>> hdr=0x01 >>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>> device = 'RD790 PCI to PCI bridge (PCIe gpp port A)' >>> class = bridge >>> subclass = PCI-PCI >>> pcib4@pci0:0:6:0: class=0x060400 card=0x59561002 chip=0x597c1002 >>> rev=0x00 >>> hdr=0x01 >>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>> device = 'RD790 PCI to PCI bridge (PCIe gpp port C)' >>> class = bridge >>> subclass = PCI-PCI >>> pcib5@pci0:0:7:0: class=0x060400 card=0x59561002 chip=0x597d1002 >>> rev=0x00 >>> hdr=0x01 >>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>> device = 'RD790 PCI to PCI bridge (PCIe gpp port D)' >>> class = bridge >>> subclass = PCI-PCI >>> pcib6@pci0:0:11:0: class=0x060400 card=0x59561002 chip=0x59801002 >>> rev=0x00 >>> hdr=0x01 >>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>> device = 'RD790 PCI to PCI bridge (external gfx1 port A)' >>> class = bridge >>> subclass = PCI-PCI >>> atapci4@pci0:0:18:0: class=0x01018f card=0x81ef1043 chip=0x43801002 >>> rev=0x00 >>> hdr=0x00 >>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>> device = 'IXP SB600 Serial ATA Controller' >>> class = mass storage >>> subclass = ATA >>> ohci0@pci0:0:19:0: class=0x0c0310 card=0x82881043 chip=0x43871002 >>> rev=0x00 >>> hdr=0x00 >>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>> device = 'IXP SB600 USB Controller (OHCI0)' >>> class = serial bus >>> subclass = USB >>> ohci1@pci0:0:19:1: class=0x0c0310 card=0x82881043 chip=0x43881002 >>> rev=0x00 >>> hdr=0x00 >>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>> device = 'IXP SB600 USB Controller (OHCI1)' >>> class = serial bus >>> subclass = USB >>> ohci2@pci0:0:19:2: class=0x0c0310 card=0x82881043 chip=0x43891002 >>> rev=0x00 >>> hdr=0x00 >>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>> device = 'IXP SB600 USB Controller (OHCI2)' >>> class = serial bus >>> subclass = USB >>> ohci3@pci0:0:19:3: class=0x0c0310 card=0x82881043 chip=0x438a1002 >>> rev=0x00 >>> hdr=0x00 >>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>> device = 'IXP SB600 USB Controller (OHCI3)' >>> class = serial bus >>> subclass = USB >>> ohci4@pci0:0:19:4: class=0x0c0310 card=0x82881043 chip=0x438b1002 >>> rev=0x00 >>> hdr=0x00 >>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>> device = 'IXP SB600 USB Controller (OHCI4)' >>> class = serial bus >>> subclass = USB >>> ehci0@pci0:0:19:5: class=0x0c0320 card=0x82881043 chip=0x43861002 >>> rev=0x00 >>> hdr=0x00 >>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>> device = 'IXP SB600 USB Controller (EHCI)' >>> class = serial bus >>> subclass = USB >>> none0@pci0:0:20:0: class=0x0c0500 card=0x82881043 chip=0x43851002 >>> rev=0x14 >>> hdr=0x00 >>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>> device = 'ATI SMBus (ATI RD600/RS600)' >>> class = serial bus >>> subclass = SMBus >>> atapci5@pci0:0:20:1: class=0x01018a card=0x82881043 chip=0x438c1002 >>> rev=0x00 >>> hdr=0x00 >>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>> device = 'ATI RD600/RS600 IDE Controller (RD600/RS600)' >>> class = mass storage >>> subclass = ATA >>> none1@pci0:0:20:2: class=0x040300 card=0x82881043 chip=0x43831002 >>> rev=0x00 >>> hdr=0x00 >>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>> device = 'IXP SB600 High Definition Audio Controller' >>> class = multimedia >>> subclass = HDA >>> isab0@pci0:0:20:3: class=0x060100 card=0x82881043 chip=0x438d1002 >>> rev=0x00 >>> hdr=0x00 >>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>> device = 'IXP SB600 PCI to LPC Bridge' >>> class = bridge >>> subclass = PCI-ISA >>> pcib7@pci0:0:20:4: class=0x060401 card=0x00000000 chip=0x43841002 >>> rev=0x00 >>> hdr=0x01 >>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>> device = 'IXP SB600 PCI to PCI Bridge' >>> class = bridge >>> subclass = PCI-PCI >>> hostb1@pci0:0:24:0: class=0x060000 card=0x00000000 chip=0x12001022 >>> rev=0x00 >>> hdr=0x00 >>> vendor = 'Advanced Micro Devices (AMD)' >>> device = '(Family 10h) Athlon64/Opteron/Sempron HyperTransport >>> Technology Configuration' >>> class = bridge >>> subclass = HOST-PCI >>> hostb2@pci0:0:24:1: class=0x060000 card=0x00000000 chip=0x12011022 >>> rev=0x00 >>> hdr=0x00 >>> vendor = 'Advanced Micro Devices (AMD)' >>> device = '(Family 10h) Athlon64/Opteron/Sempron Address Map' >>> class = bridge >>> subclass = HOST-PCI >>> hostb3@pci0:0:24:2: class=0x060000 card=0x00000000 chip=0x12021022 >>> rev=0x00 >>> hdr=0x00 >>> vendor = 'Advanced Micro Devices (AMD)' >>> device = '(Family 10h) Athlon64/Opteron/Sempron DRAM Controller' >>> class = bridge >>> subclass = HOST-PCI >>> hostb4@pci0:0:24:3: class=0x060000 card=0x00000000 chip=0x12031022 >>> rev=0x00 >>> hdr=0x00 >>> vendor = 'Advanced Micro Devices (AMD)' >>> device = '(Family 10h) Athlon64/Opteron/Sempron Miscellaneous >>> Control' >>> class = bridge >>> subclass = HOST-PCI >>> hostb5@pci0:0:24:4: class=0x060000 card=0x00000000 chip=0x12041022 >>> rev=0x00 >>> hdr=0x00 >>> vendor = 'Advanced Micro Devices (AMD)' >>> device = '(Family 10h) Athlon64/Opteron/Sempron Link Control' >>> class = bridge >>> subclass = HOST-PCI >>> mpt0@pci0:1:0:0: class=0x010000 card=0xa58015d9 chip=0x00581000 rev=0x08 >>> hdr=0x00 >>> vendor = 'LSI Logic (Was: Symbios Logic, NCR)' >>> device = 'SAS 3000 series, 8-port with 1068E -StorPort' >>> class = mass storage >>> subclass = SCSI >>> mpt1@pci0:2:0:0: class=0x010000 card=0xa58015d9 chip=0x00581000 rev=0x08 >>> hdr=0x00 >>> vendor = 'LSI Logic (Was: Symbios Logic, NCR)' >>> device = 'SAS 3000 series, 8-port with 1068E -StorPort' >>> class = mass storage >>> subclass = SCSI >>> atapci0@pci0:3:0:0: class=0x01018f card=0x612111ab chip=0x612111ab >>> rev=0xb1 >>> hdr=0x00 >>> vendor = 'Marvell Semiconductor (Was: Galileo Technology Ltd)' >>> device = '6121 SATA2 Controller' >>> class = mass storage >>> subclass = ATA >>> mskc0@pci0:4:0:0: class=0x020000 card=0x81f81043 chip=0x436411ab >>> rev=0x12 >>> hdr=0x00 >>> vendor = 'Marvell Semiconductor (Was: Galileo Technology Ltd)' >>> device = 'Yukon PCI-E Gigabit Ethernet Controller (88E8056)' >>> class = network >>> subclass = ethernet >>> atapci2@pci0:5:0:0: class=0x01018f card=0x612111ab chip=0x612111ab >>> rev=0xb2 >>> hdr=0x00 >>> vendor = 'Marvell Semiconductor (Was: Galileo Technology Ltd)' >>> device = '6121 SATA2 Controller' >>> class = mass storage >>> subclass = ATA >>> mpt2@pci0:6:0:0: class=0x010000 card=0x30a01000 chip=0x00581000 rev=0x08 >>> hdr=0x00 >>> vendor = 'LSI Logic (Was: Symbios Logic, NCR)' >>> device = 'SAS 3000 series, 8-port with 1068E -StorPort' >>> class = mass storage >>> subclass = SCSI >>> em0@pci0:7:5:0: class=0x020000 card=0x13768086 chip=0x107c8086 rev=0x05 >>> hdr=0x00 >>> vendor = 'Intel Corporation' >>> device = 'Gigabit Ethernet Controller (Copper) rev 5 (82541PI)' >>> class = network >>> subclass = ethernet >>> vgapci0@pci0:7:6:0: class=0x030000 card=0x00000000 chip=0x88115333 >>> rev=0x44 >>> hdr=0x00 >>> vendor = 'S3 Graphics Co., Ltd' >>> device = '86C732 Trio32, 86C764 Trio64, 86C765 Trio64V+ Rev 01' >>> class = display >>> subclass = VGA >>> none2@pci0:7:8:0: class=0x0c0010 card=0x82941043 chip=0x581111c1 >>> rev=0x70 >>> hdr=0x00 >>> vendor = 'Lucent/Agere Systems (Was: AT&T MicroElectronics)' >>> device = '1394A PCI PHY/Link Open Host Ctrlr I/F (FW322)' >>> class = serial bus >>> subclass = FireWire >>> [josh@foghornleghorn /var/log]$ sudo su - >>> foghornleghorn# pciconf -lvcb >>> hostb0@pci0:0:0:0: class=0x060000 card=0x59561002 chip=0x59561002 >>> rev=0x00 >>> hdr=0x00 >>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>> device = 'RD790 GFX Dual Slot' >>> class = bridge >>> subclass = HOST-PCI >>> cap 08[c4] = HT slave >>> cap 08[40] = HT retry mode >>> cap 08[54] = HT unit ID clumping >>> cap 08[9c] = HT unknown d03c >>> pcib1@pci0:0:2:0: class=0x060400 card=0x59561002 chip=0x59781002 >>> rev=0x00 >>> hdr=0x01 >>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>> device = 'RD790 PCI to PCI bridge (external gfx0 port A)' >>> class = bridge >>> subclass = PCI-PCI >>> cap 01[50] = powerspec 3 supports D0 D3 current D0 >>> cap 10[58] = PCI-Express 2 root port max data 128(128) link x4(x8) >>> cap 05[a0] = MSI supports 1 message >>> cap 0d[b0] = PCI Bridge card=0x59561002 >>> cap 08[b8] = HT MSI fixed address window enabled at 0xfee00000 >>> ecap 000b[100] = unknown 1 >>> ecap 0002[110] = VC 1 max VC0 >>> pcib2@pci0:0:3:0: class=0x060400 card=0x59561002 chip=0x59791002 >>> rev=0x00 >>> hdr=0x01 >>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>> device = 'RD790 PCI to PCI bridge (external gfx0 port B)' >>> class = bridge >>> subclass = PCI-PCI >>> cap 01[50] = powerspec 3 supports D0 D3 current D0 >>> cap 10[58] = PCI-Express 2 root port max data 128(128) link x4(x8) >>> cap 05[a0] = MSI supports 1 message >>> cap 0d[b0] = PCI Bridge card=0x59561002 >>> cap 08[b8] = HT MSI fixed address window enabled at 0xfee00000 >>> ecap 000b[100] = unknown 1 >>> ecap 0002[110] = VC 1 max VC0 >>> pcib3@pci0:0:4:0: class=0x060400 card=0x59561002 chip=0x597a1002 >>> rev=0x00 >>> hdr=0x01 >>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>> device = 'RD790 PCI to PCI bridge (PCIe gpp port A)' >>> class = bridge >>> subclass = PCI-PCI >>> cap 01[50] = powerspec 3 supports D0 D3 current D0 >>> cap 10[58] = PCI-Express 2 root port max data 128(128) link x1(x2) >>> cap 05[a0] = MSI supports 1 message >>> cap 0d[b0] = PCI Bridge card=0x59561002 >>> cap 08[b8] = HT MSI fixed address window enabled at 0xfee00000 >>> ecap 000b[100] = unknown 1 >>> ecap 0002[110] = VC 1 max VC0 >>> pcib4@pci0:0:6:0: class=0x060400 card=0x59561002 chip=0x597c1002 >>> rev=0x00 >>> hdr=0x01 >>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>> device = 'RD790 PCI to PCI bridge (PCIe gpp port C)' >>> class = bridge >>> subclass = PCI-PCI >>> cap 01[50] = powerspec 3 supports D0 D3 current D0 >>> cap 10[58] = PCI-Express 2 root port max data 128(128) link x1(x1) >>> cap 05[a0] = MSI supports 1 message >>> cap 0d[b0] = PCI Bridge card=0x59561002 >>> cap 08[b8] = HT MSI fixed address window enabled at 0xfee00000 >>> ecap 000b[100] = unknown 1 >>> ecap 0002[110] = VC 1 max VC0 >>> pcib5@pci0:0:7:0: class=0x060400 card=0x59561002 chip=0x597d1002 >>> rev=0x00 >>> hdr=0x01 >>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>> device = 'RD790 PCI to PCI bridge (PCIe gpp port D)' >>> class = bridge >>> subclass = PCI-PCI >>> cap 01[50] = powerspec 3 supports D0 D3 current D0 >>> cap 10[58] = PCI-Express 2 root port max data 128(128) link x1(x1) >>> cap 05[a0] = MSI supports 1 message >>> cap 0d[b0] = PCI Bridge card=0x59561002 >>> cap 08[b8] = HT MSI fixed address window enabled at 0xfee00000 >>> ecap 000b[100] = unknown 1 >>> ecap 0002[110] = VC 1 max VC0 >>> pcib6@pci0:0:11:0: class=0x060400 card=0x59561002 chip=0x59801002 >>> rev=0x00 >>> hdr=0x01 >>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>> device = 'RD790 PCI to PCI bridge (external gfx1 port A)' >>> class = bridge >>> subclass = PCI-PCI >>> cap 01[50] = powerspec 3 supports D0 D3 current D0 >>> cap 10[58] = PCI-Express 2 root port max data 128(128) link x4(x8) >>> cap 05[a0] = MSI supports 1 message >>> cap 0d[b0] = PCI Bridge card=0x59561002 >>> cap 08[b8] = HT MSI fixed address window enabled at 0xfee00000 >>> ecap 000b[100] = unknown 1 >>> ecap 0002[110] = VC 1 max VC0 >>> atapci4@pci0:0:18:0: class=0x01018f card=0x81ef1043 chip=0x43801002 >>> rev=0x00 >>> hdr=0x00 >>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>> device = 'IXP SB600 Serial ATA Controller' >>> class = mass storage >>> subclass = ATA >>> bar [10] = type I/O Port, range 32, base 0x5000, size 8, enabled >>> bar [14] = type I/O Port, range 32, base 0x4000, size 4, enabled >>> bar [18] = type I/O Port, range 32, base 0x3000, size 8, enabled >>> bar [1c] = type I/O Port, range 32, base 0x2000, size 4, enabled >>> bar [20] = type I/O Port, range 32, base 0x1000, size 16, enabled >>> bar [24] = type Memory, range 32, base 0xf71ff800, size 1024, >>> enabled >>> cap 01[60] = powerspec 2 supports D0 D3 current D0 >>> ohci0@pci0:0:19:0: class=0x0c0310 card=0x82881043 chip=0x43871002 >>> rev=0x00 >>> hdr=0x00 >>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>> device = 'IXP SB600 USB Controller (OHCI0)' >>> class = serial bus >>> subclass = USB >>> bar [10] = type Memory, range 32, base 0xf71fe000, size 4096, >>> enabled >>> ohci1@pci0:0:19:1: class=0x0c0310 card=0x82881043 chip=0x43881002 >>> rev=0x00 >>> hdr=0x00 >>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>> device = 'IXP SB600 USB Controller (OHCI1)' >>> class = serial bus >>> subclass = USB >>> bar [10] = type Memory, range 32, base 0xf71fd000, size 4096, >>> enabled >>> ohci2@pci0:0:19:2: class=0x0c0310 card=0x82881043 chip=0x43891002 >>> rev=0x00 >>> hdr=0x00 >>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>> device = 'IXP SB600 USB Controller (OHCI2)' >>> class = serial bus >>> subclass = USB >>> bar [10] = type Memory, range 32, base 0xf71fc000, size 4096, >>> enabled >>> ohci3@pci0:0:19:3: class=0x0c0310 card=0x82881043 chip=0x438a1002 >>> rev=0x00 >>> hdr=0x00 >>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>> device = 'IXP SB600 USB Controller (OHCI3)' >>> class = serial bus >>> subclass = USB >>> bar [10] = type Memory, range 32, base 0xf71fb000, size 4096, >>> enabled >>> ohci4@pci0:0:19:4: class=0x0c0310 card=0x82881043 chip=0x438b1002 >>> rev=0x00 >>> hdr=0x00 >>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>> device = 'IXP SB600 USB Controller (OHCI4)' >>> class = serial bus >>> subclass = USB >>> bar [10] = type Memory, range 32, base 0xf71fa000, size 4096, >>> enabled >>> ehci0@pci0:0:19:5: class=0x0c0320 card=0x82881043 chip=0x43861002 >>> rev=0x00 >>> hdr=0x00 >>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>> device = 'IXP SB600 USB Controller (EHCI)' >>> class = serial bus >>> subclass = USB >>> bar [10] = type Memory, range 32, base 0xf71ff000, size 256, enabled >>> cap 01[c0] = powerspec 2 supports D0 D1 D2 D3 current D0 >>> cap 05[d0] = MSI supports 1 message >>> cap 0a[e4] = EHCI Debug Port at offset 0xe0 in map 0x14 >>> none0@pci0:0:20:0: class=0x0c0500 card=0x82881043 chip=0x43851002 >>> rev=0x14 >>> hdr=0x00 >>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>> device = 'ATI SMBus (ATI RD600/RS600)' >>> class = serial bus >>> subclass = SMBus >>> bar [10] = type I/O Port, range 32, base 0xb00, size 16, enabled >>> cap 08[b0] = HT MSI fixed address window disabled at 0xfee00000 >>> atapci5@pci0:0:20:1: class=0x01018a card=0x82881043 chip=0x438c1002 >>> rev=0x00 >>> hdr=0x00 >>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>> device = 'ATI RD600/RS600 IDE Controller (RD600/RS600)' >>> class = mass storage >>> subclass = ATA >>> bar [10] = type I/O Port, range 32, base 0x1f0, size 8, enabled >>> bar [14] = type I/O Port, range 32, base 0x3f4, size 1, enabled >>> bar [18] = type I/O Port, range 32, base 0x170, size 8, enabled >>> bar [1c] = type I/O Port, range 32, base 0x374, size 1, enabled >>> bar [20] = type I/O Port, range 32, base 0xff00, size 16, enabled >>> none1@pci0:0:20:2: class=0x040300 card=0x82881043 chip=0x43831002 >>> rev=0x00 >>> hdr=0x00 >>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>> device = 'IXP SB600 High Definition Audio Controller' >>> class = multimedia >>> subclass = HDA >>> bar [10] = type Memory, range 64, base 0xf71f4000, size 16384, >>> enabled >>> cap 01[50] = powerspec 2 supports D0 D3 current D0 >>> isab0@pci0:0:20:3: class=0x060100 card=0x82881043 chip=0x438d1002 >>> rev=0x00 >>> hdr=0x00 >>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>> device = 'IXP SB600 PCI to LPC Bridge' >>> class = bridge >>> subclass = PCI-ISA >>> pcib7@pci0:0:20:4: class=0x060401 card=0x00000000 chip=0x43841002 >>> rev=0x00 >>> hdr=0x01 >>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>> device = 'IXP SB600 PCI to PCI Bridge' >>> class = bridge >>> subclass = PCI-PCI >>> hostb1@pci0:0:24:0: class=0x060000 card=0x00000000 chip=0x12001022 >>> rev=0x00 >>> hdr=0x00 >>> vendor = 'Advanced Micro Devices (AMD)' >>> device = '(Family 10h) Athlon64/Opteron/Sempron HyperTransport >>> Technology Configuration' >>> class = bridge >>> subclass = HOST-PCI >>> cap 08[80] = HT host >>> hostb2@pci0:0:24:1: class=0x060000 card=0x00000000 chip=0x12011022 >>> rev=0x00 >>> hdr=0x00 >>> vendor = 'Advanced Micro Devices (AMD)' >>> device = '(Family 10h) Athlon64/Opteron/Sempron Address Map' >>> class = bridge >>> subclass = HOST-PCI >>> hostb3@pci0:0:24:2: class=0x060000 card=0x00000000 chip=0x12021022 >>> rev=0x00 >>> hdr=0x00 >>> vendor = 'Advanced Micro Devices (AMD)' >>> device = '(Family 10h) Athlon64/Opteron/Sempron DRAM Controller' >>> class = bridge >>> subclass = HOST-PCI >>> hostb4@pci0:0:24:3: class=0x060000 card=0x00000000 chip=0x12031022 >>> rev=0x00 >>> hdr=0x00 >>> vendor = 'Advanced Micro Devices (AMD)' >>> device = '(Family 10h) Athlon64/Opteron/Sempron Miscellaneous >>> Control' >>> class = bridge >>> subclass = HOST-PCI >>> cap 0f[f0] = unknown >>> hostb5@pci0:0:24:4: class=0x060000 card=0x00000000 chip=0x12041022 >>> rev=0x00 >>> hdr=0x00 >>> vendor = 'Advanced Micro Devices (AMD)' >>> device = '(Family 10h) Athlon64/Opteron/Sempron Link Control' >>> class = bridge >>> subclass = HOST-PCI >>> mpt0@pci0:1:0:0: class=0x010000 card=0xa58015d9 chip=0x00581000 rev=0x08 >>> hdr=0x00 >>> vendor = 'LSI Logic (Was: Symbios Logic, NCR)' >>> device = 'SAS 3000 series, 8-port with 1068E -StorPort' >>> class = mass storage >>> subclass = SCSI >>> bar [10] = type I/O Port, range 32, base 0x6000, size 256, disabled >>> bar [14] = type Memory, range 64, base 0xf75fc000, size 16384, >>> enabled >>> bar [1c] = type Memory, range 64, base 0xf75e0000, size 65536, >>> enabled >>> cap 01[50] = powerspec 2 supports D0 D1 D2 D3 current D0 >>> cap 10[68] = PCI-Express 1 endpoint max data 128(4096) link x4(x8) >>> cap 05[98] = MSI supports 1 message, 64 bit >>> cap 11[b0] = MSI-X supports 1 message in map 0x14 >>> ecap 0001[100] = AER 1 1 fatal 1 non-fatal 0 corrected >>> mpt1@pci0:2:0:0: class=0x010000 card=0xa58015d9 chip=0x00581000 rev=0x08 >>> hdr=0x00 >>> vendor = 'LSI Logic (Was: Symbios Logic, NCR)' >>> device = 'SAS 3000 series, 8-port with 1068E -StorPort' >>> class = mass storage >>> subclass = SCSI >>> bar [10] = type I/O Port, range 32, base 0x7000, size 256, disabled >>> bar [14] = type Memory, range 64, base 0xf78fc000, size 16384, >>> enabled >>> bar [1c] = type Memory, range 64, base 0xf78e0000, size 65536, >>> enabled >>> cap 01[50] = powerspec 2 supports D0 D1 D2 D3 current D0 >>> cap 10[68] = PCI-Express 1 endpoint max data 128(4096) link x4(x8) >>> cap 05[98] = MSI supports 1 message, 64 bit >>> cap 11[b0] = MSI-X supports 1 message in map 0x14 >>> ecap 0001[100] = AER 1 1 fatal 1 non-fatal 0 corrected >>> atapci0@pci0:3:0:0: class=0x01018f card=0x612111ab chip=0x612111ab >>> rev=0xb1 >>> hdr=0x00 >>> vendor = 'Marvell Semiconductor (Was: Galileo Technology Ltd)' >>> device = '6121 SATA2 Controller' >>> class = mass storage >>> subclass = ATA >>> bar [10] = type I/O Port, range 32, base 0x9800, size 8, enabled >>> bar [14] = type I/O Port, range 32, base 0x9400, size 4, enabled >>> bar [18] = type I/O Port, range 32, base 0x9000, size 8, enabled >>> bar [1c] = type I/O Port, range 32, base 0x8800, size 4, enabled >>> bar [20] = type I/O Port, range 32, base 0x8400, size 16, enabled >>> bar [24] = type Memory, range 32, base 0xf79ffc00, size 1024, >>> enabled >>> cap 01[48] = powerspec 2 supports D0 D1 D3 current D0 >>> cap 05[50] = MSI supports 1 message >>> cap 10[e0] = PCI-Express 1 legacy endpoint max data 128(128) link >>> x1(x1) >>> ecap 0001[100] = AER 1 0 fatal 0 non-fatal 2 corrected >>> mskc0@pci0:4:0:0: class=0x020000 card=0x81f81043 chip=0x436411ab >>> rev=0x12 >>> hdr=0x00 >>> vendor = 'Marvell Semiconductor (Was: Galileo Technology Ltd)' >>> device = 'Yukon PCI-E Gigabit Ethernet Controller (88E8056)' >>> class = network >>> subclass = ethernet >>> bar [10] = type Memory, range 64, base 0xf7afc000, size 16384, >>> enabled >>> bar [18] = type I/O Port, range 32, base 0xa800, size 256, enabled >>> cap 01[48] = powerspec 3 supports D0 D1 D2 D3 current D0 >>> cap 03[50] = VPD >>> cap 05[5c] = MSI supports 1 message, 64 bit enabled with 1 message >>> cap 10[e0] = PCI-Express 1 legacy endpoint max data 128(128) link >>> x1(x1) >>> ecap 0001[100] = AER 1 0 fatal 0 non-fatal 1 corrected >>> atapci2@pci0:5:0:0: class=0x01018f card=0x612111ab chip=0x612111ab >>> rev=0xb2 >>> hdr=0x00 >>> vendor = 'Marvell Semiconductor (Was: Galileo Technology Ltd)' >>> device = '6121 SATA2 Controller' >>> class = mass storage >>> subclass = ATA >>> bar [10] = type I/O Port, range 32, base 0xc800, size 8, enabled >>> bar [14] = type I/O Port, range 32, base 0xc400, size 4, enabled >>> bar [18] = type I/O Port, range 32, base 0xc000, size 8, enabled >>> bar [1c] = type I/O Port, range 32, base 0xb800, size 4, enabled >>> bar [20] = type I/O Port, range 32, base 0xb400, size 16, enabled >>> bar [24] = type Memory, range 32, base 0xf7bffc00, size 1024, >>> enabled >>> cap 01[48] = powerspec 2 supports D0 D1 D3 current D0 >>> cap 05[50] = MSI supports 1 message >>> cap 10[e0] = PCI-Express 1 legacy endpoint max data 128(128) link >>> x1(x1) >>> ecap 0001[100] = AER 1 0 fatal 0 non-fatal 1 corrected >>> mpt2@pci0:6:0:0: class=0x010000 card=0x30a01000 chip=0x00581000 rev=0x08 >>> hdr=0x00 >>> vendor = 'LSI Logic (Was: Symbios Logic, NCR)' >>> device = 'SAS 3000 series, 8-port with 1068E -StorPort' >>> class = mass storage >>> subclass = SCSI >>> bar [10] = type I/O Port, range 32, base 0xd000, size 256, disabled >>> bar [14] = type Memory, range 64, base 0xf7ffc000, size 16384, >>> enabled >>> bar [1c] = type Memory, range 64, base 0xf7fe0000, size 65536, >>> enabled >>> cap 01[50] = powerspec 2 supports D0 D1 D2 D3 current D0 >>> cap 10[68] = PCI-Express 1 endpoint max data 128(4096) link x4(x8) >>> cap 05[98] = MSI supports 1 message, 64 bit >>> cap 11[b0] = MSI-X supports 1 message in map 0x14 >>> ecap 0001[100] = AER 1 1 fatal 1 non-fatal 0 corrected >>> em0@pci0:7:5:0: class=0x020000 card=0x13768086 chip=0x107c8086 rev=0x05 >>> hdr=0x00 >>> vendor = 'Intel Corporation' >>> device = 'Gigabit Ethernet Controller (Copper) rev 5 (82541PI)' >>> class = network >>> subclass = ethernet >>> bar [10] = type Memory, range 32, base 0xfebe0000, size 131072, >>> enabled >>> bar [14] = type Memory, range 32, base 0xfebc0000, size 131072, >>> enabled >>> bar [18] = type I/O Port, range 32, base 0xe800, size 64, enabled >>> cap 01[dc] = powerspec 2 supports D0 D3 current D0 >>> cap 07[e4] = PCI-X supports 2048 burst read, 1 split transaction >>> vgapci0@pci0:7:6:0: class=0x030000 card=0x00000000 chip=0x88115333 >>> rev=0x44 >>> hdr=0x00 >>> vendor = 'S3 Graphics Co., Ltd' >>> device = '86C732 Trio32, 86C764 Trio64, 86C765 Trio64V+ Rev 01' >>> class = display >>> subclass = VGA >>> bar [10] = type Memory, range 32, base 0xf8000000, size 67108864, >>> enabled >>> none2@pci0:7:8:0: class=0x0c0010 card=0x82941043 chip=0x581111c1 >>> rev=0x70 >>> hdr=0x00 >>> vendor = 'Lucent/Agere Systems (Was: AT&T MicroElectronics)' >>> device = '1394A PCI PHY/Link Open Host Ctrlr I/F (FW322)' >>> class = serial bus >>> subclass = FireWire >>> bar [10] = type Memory, range 32, base 0xfeb8f000, size 4096, >>> enabled >>> cap 01[44] = powerspec 2 supports D0 D1 D2 D3 current D0 >>> >>> >>> >>> > # vmstat -i >>> > >>> >>> interrupt total rate >>> irq9: acpi0 1 0 >>> irq16: atapci0+ 2 0 >>> irq17: ohci1 ohci3 3 0 >>> irq18: mpt0 ohci2+ 7066718 31 >>> irq19: mpt1 atapci* 7798877 34 >>> irq20: em0 11715792 51 >>> irq22: atapci4 628883 2 >>> cpu0: timer 455853831 1999 >>> irq256: mskc0 97098730 425 >>> cpu1: timer 455845190 1999 >>> Total 1036008027 4544 >>> >>> >>> >>> > # sysctl -a | grep msi >>> > >>> >>> hw.pci.honor_msi_blacklist: 1 >>> hw.pci.enable_msix: 1 >>> hw.pci.enable_msi: 1 >>> >>> >>> >>> > # dmesg >>> > >>> >>> Copyright (c) 1992-2011 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 8.2-STABLE #17: Mon Jun 6 19:40:19 EDT 2011 >>> root@foghornleghorn.res.openband.net: >>> /usr/obj/usr/src/sys/FOGHORNLEGHORN >>> amd64 >>> Timecounter "i8254" frequency 1193182 Hz quality 0 >>> CPU: AMD Phenom(tm) II X2 555 Processor (3209.77-MHz K8-class CPU) >>> Origin = "AuthenticAMD" Id = 0x100f43 Family = 10 Model = 4 Stepping >>> = >>> 3 >>> >>> >>> Features=0x178bfbff >>> Features2=0x802009 >>> AMD >>> >>> Features=0xee500800 >>> AMD >>> >>> Features2=0x37ff >>> TSC: P-state invariant >>> real memory = 8589934592 (8192 MB) >>> avail memory = 8257736704 (7875 MB) >>> ACPI APIC Table: <092310 OEMAPIC > >>> FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs >>> FreeBSD/SMP: 1 package(s) x 2 core(s) >>> cpu0 (BSP): APIC ID: 0 >>> cpu1 (AP): APIC ID: 1 >>> ioapic0 irqs 0-23 on motherboard >>> acpi0: <092310 OEMRSDT> on motherboard >>> acpi0: [ITHREAD] >>> acpi0: Power Button (fixed) >>> acpi0: reservation of fee00000, 1000 (3) failed >>> acpi0: reservation of ffb80000, 80000 (3) failed >>> acpi0: reservation of fff00000, 100000 (3) failed >>> acpi0: reservation of 0, a0000 (3) failed >>> acpi0: reservation of 100000, dff00000 (3) failed >>> Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 >>> acpi_timer0: <32-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 >>> cpu0: on acpi0 >>> cpu1: on acpi0 >>> acpi_hpet0: iomem 0xfed00000-0xfed003ff on >>> acpi0 >>> Timecounter "HPET" frequency 14318180 Hz quality 900 >>> pcib0: port 0xcf8-0xcff on acpi0 >>> pci0: on pcib0 >>> pcib1: irq 18 at device 2.0 on pci0 >>> pci1: on pcib1 >>> mpt0: port 0x6000-0x60ff mem >>> 0xf75fc000-0xf75fffff,0xf75e0000-0xf75effff irq 18 at device 0.0 on pci1 >>> mpt0: [ITHREAD] >>> mpt0: MPI Version=1.5.20.0 >>> pcib2: irq 19 at device 3.0 on pci0 >>> pci2: on pcib2 >>> mpt1: port 0x7000-0x70ff mem >>> 0xf78fc000-0xf78fffff,0xf78e0000-0xf78effff irq 19 at device 0.0 on pci2 >>> mpt1: [ITHREAD] >>> mpt1: MPI Version=1.5.20.0 >>> pcib3: irq 16 at device 4.0 on pci0 >>> pci3: on pcib3 >>> atapci0: port >>> 0x9800-0x9807,0x9400-0x9403,0x9000-0x9007,0x8800-0x8803,0x8400-0x840f mem >>> 0xf79ffc00-0xf79fffff irq 16 at device 0.0 on pci3 >>> atapci0: [ITHREAD] >>> atapci1: on atapci0 >>> atapci1: [ITHREAD] >>> atapci1: AHCI v1.00 controller with 3 3Gbps ports, PM supported >>> ata2: on atapci1 >>> ata2: [ITHREAD] >>> ata3: on atapci1 >>> ata3: [ITHREAD] >>> ata4: on atapci0 >>> ata4: [ITHREAD] >>> pcib4: irq 18 at device 6.0 on pci0 >>> pci4: on pcib4 >>> mskc0: port 0xa800-0xa8ff mem >>> 0xf7afc000-0xf7afffff irq 18 at device 0.0 on pci4 >>> msk0: on >>> mskc0 >>> msk0: Ethernet address: 00:1f:c6:e9:f8:7c >>> miibus0: on msk0 >>> e1000phy0: PHY 0 on miibus0 >>> e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, >>> 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow >>> mskc0: [ITHREAD] >>> pcib5: irq 19 at device 7.0 on pci0 >>> pci5: on pcib5 >>> atapci2: port >>> 0xc800-0xc807,0xc400-0xc403,0xc000-0xc007,0xb800-0xb803,0xb400-0xb40f mem >>> 0xf7bffc00-0xf7bfffff irq 19 at device 0.0 on pci5 >>> atapci2: [ITHREAD] >>> atapci3: on atapci2 >>> atapci3: [ITHREAD] >>> atapci3: AHCI v1.00 controller with 3 3Gbps ports, PM supported >>> ata5: on atapci3 >>> ata5: [ITHREAD] >>> ata6: on atapci3 >>> ata6: [ITHREAD] >>> ata7: on atapci2 >>> ata7: [ITHREAD] >>> pcib6: irq 19 at device 11.0 on pci0 >>> pci6: on pcib6 >>> mpt2: port 0xd000-0xd0ff mem >>> 0xf7ffc000-0xf7ffffff,0xf7fe0000-0xf7feffff irq 19 at device 0.0 on pci6 >>> mpt2: [ITHREAD] >>> mpt2: MPI Version=1.5.19.0 >>> atapci4: port >>> 0x5000-0x5007,0x4000-0x4003,0x3000-0x3007,0x2000-0x2003,0x1000-0x100f mem >>> 0xf71ff800-0xf71ffbff irq 22 at device 18.0 on pci0 >>> atapci4: [ITHREAD] >>> atapci4: AHCI v1.10 controller with 4 3Gbps ports, PM supported >>> ata8: on atapci4 >>> ata8: port is not ready (timeout 0ms) tfd = 000001d0 >>> ata8: software reset clear timeout >>> ata8: [ITHREAD] >>> ata9: on atapci4 >>> ata9: [ITHREAD] >>> ata10: on atapci4 >>> ata10: [ITHREAD] >>> ata11: on atapci4 >>> ata11: [ITHREAD] >>> ohci0: mem 0xf71fe000-0xf71fefff irq 16 >>> at >>> device 19.0 on pci0 >>> ohci0: [ITHREAD] >>> usbus0: on ohci0 >>> ohci1: mem 0xf71fd000-0xf71fdfff irq 17 >>> at >>> device 19.1 on pci0 >>> ohci1: [ITHREAD] >>> usbus1: on ohci1 >>> ohci2: mem 0xf71fc000-0xf71fcfff irq 18 >>> at >>> device 19.2 on pci0 >>> ohci2: [ITHREAD] >>> usbus2: on ohci2 >>> ohci3: mem 0xf71fb000-0xf71fbfff irq 17 >>> at >>> device 19.3 on pci0 >>> ohci3: [ITHREAD] >>> usbus3: on ohci3 >>> ohci4: mem 0xf71fa000-0xf71fafff irq 18 >>> at >>> device 19.4 on pci0 >>> ohci4: [ITHREAD] >>> usbus4: on ohci4 >>> ehci0: mem 0xf71ff000-0xf71ff0ff irq >>> 19 >>> at device 19.5 on pci0 >>> ehci0: [ITHREAD] >>> ehci0: AMD SB600/700 quirk applied >>> usbus5: EHCI version 1.0 >>> usbus5: on ehci0 >>> pci0: at device 20.0 (no driver attached) >>> atapci5: port >>> 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xff00-0xff0f at device 20.1 on pci0 >>> ata0: on atapci5 >>> ata0: [ITHREAD] >>> pci0: at device 20.2 (no driver attached) >>> isab0: at device 20.3 on pci0 >>> isa0: on isab0 >>> pcib7: at device 20.4 on pci0 >>> pci7: on pcib7 >>> em0: port >>> 0xe800-0xe83f >>> mem 0xfebe0000-0xfebfffff,0xfebc0000-0xfebdffff irq 20 at device 5.0 on >>> pci7 >>> em0: [FILTER] >>> em0: Ethernet address: 00:1b:21:4e:e5:2e >>> vgapci0: mem 0xf8000000-0xfbffffff at device 6.0 >>> on >>> pci7 >>> pci7: at device 8.0 (no driver attached) >>> acpi_button0: on acpi0 >>> atrtc0: port 0x70-0x71 irq 8 on acpi0 >>> acpi_hpet1: iomem 0xfed00000-0xfed003ff on >>> acpi0 >>> device_attach: acpi_hpet1 attach returned 12 >>> uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 >>> uart0: [FILTER] >>> orm0: at iomem >>> 0xc0000-0xc7fff,0xc8000-0xc87ff,0xc8800-0xc97ff on isa0 >>> sc0: at flags 0x100 on isa0 >>> sc0: VGA <16 virtual consoles, flags=0x300> >>> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 >>> acpi_throttle0: on cpu0 >>> acpi_throttle0: CLK_VAL field overlaps THT_EN bit >>> device_attach: acpi_throttle0 attach returned 6 >>> hwpstate0: on cpu0 >>> Timecounters tick every 1.000 msec >>> usbus0: 12Mbps Full Speed USB v1.0 >>> usbus1: 12Mbps Full Speed USB v1.0 >>> usbus2: 12Mbps Full Speed USB v1.0 >>> usbus3: 12Mbps Full Speed USB v1.0 >>> usbus4: 12Mbps Full Speed USB v1.0 >>> usbus5: 480Mbps High Speed USB v2.0 >>> ugen0.1: at usbus0 >>> uhub0: on usbus0 >>> ugen1.1: at usbus1 >>> uhub1: on usbus1 >>> ugen2.1: at usbus2 >>> uhub2: on usbus2 >>> ugen3.1: at usbus3 >>> uhub3: on usbus3 >>> ugen4.1: at usbus4 >>> uhub4: on usbus4 >>> ugen5.1: at usbus5 >>> uhub5: on usbus5 >>> ad16: 476940MB at ata8-master UDMA100 SATA >>> 3Gb/s >>> uhub0: 2 ports with 2 removable, self powered >>> uhub1: 2 ports with 2 removable, self powered >>> uhub2: 2 ports with 2 removable, self powered >>> uhub3: 2 ports with 2 removable, self powered >>> uhub4: 2 ports with 2 removable, self powered >>> da8 at mpt0 bus 0 scbus0 target 0 lun 0 >>> da8: Fixed Direct Access SCSI-5 device >>> da8: 300.000MB/s transfers >>> da8: Command Queueing enabled >>> da8: 953869MB (1953525168 512 byte sectors: 255H 63S/T 121601C) >>> da9 at mpt0 bus 0 scbus0 target 1 lun 0 >>> da9: Fixed Direct Access SCSI-5 device >>> da9: 300.000MB/s transfers >>> da9: Command Queueing enabled >>> da9: 953869MB (1953525168 512 byte sectors: 255H 63S/T 121601C) >>> da10 at mpt0 bus 0 scbus0 target 2 lun 0 >>> da10: Fixed Direct Access SCSI-5 device >>> da10: 300.000MB/s transfers >>> da10: Command Queueing enabled >>> da10: 953869MB (1953525168 512 byte sectors: 255H 63S/T 121601C) >>> da11 at mpt0 bus 0 scbus0 target 3 lun 0 >>> da11: Fixed Direct Access SCSI-5 device >>> da11: 300.000MB/s transfers >>> da11: Command Queueing enabled >>> da11: 953869MB (1953525168 512 byte sectors: 255H 63S/T 121601C) >>> da12 at mpt0 bus 0 scbus0 target 4 lun 0 >>> da12: Fixed Direct Access SCSI-5 device >>> da12: 300.000MB/s transfers >>> da12: Command Queueing enabled >>> da12: 953869MB (1953525168 512 byte sectors: 255H 63S/T 121601C) >>> da13 at mpt0 bus 0 scbus0 target 5 lun 0 >>> da13: Fixed Direct Access SCSI-5 device >>> da13: 300.000MB/s transfers >>> da13: Command Queueing enabled >>> da13: 953869MB (1953525168 512 byte sectors: 255H 63S/T 121601C) >>> da14 at mpt0 bus 0 scbus0 target 6 lun 0 >>> da14: Fixed Direct Access SCSI-5 device >>> da14: 300.000MB/s transfers >>> da14: Command Queueing enabled >>> da14: 953869MB (1953525168 512 byte sectors: 255H 63S/T 121601C) >>> da0 at mpt1 bus 0 scbus1 target 0 lun 0 >>> da0: Fixed Direct Access SCSI-5 device >>> da0: 300.000MB/s transfers >>> da0: Command Queueing enabled >>> da0: 1907729MB (3907029168 512 byte sectors: 255H 63S/T 243201C) >>> da1 at mpt1 bus 0 scbus1 target 1 lun 0 >>> da1: Fixed Direct Access SCSI-5 device >>> da1: 300.000MB/s transfers >>> da1: Command Queueing enabled >>> da1: 1907729MB (3907029168 512 byte sectors: 255H 63S/T 243201C) >>> da2 at mpt1 bus 0 scbus1 target 2 lun 0 >>> da2: Fixed Direct Access SCSI-5 device >>> da2: 300.000MB/s transfers >>> da2: Command Queueing enabled >>> da2: 1907729MB (3907029168 512 byte sectors: 255H 63S/T 243201C) >>> da3 at mpt1 bus 0 scbus1 target 3 lun 0 >>> da3: Fixed Direct Access SCSI-5 device >>> da3: 300.000MB/s transfers >>> da3: Command Queueing enabled >>> da3: 1907729MB (3907029168 512 byte sectors: 255H 63S/T 243201C) >>> da4 at mpt1 bus 0 scbus1 target 4 lun 0 >>> da4: Fixed Direct Access SCSI-5 device >>> da4: 300.000MB/s transfers >>> da4: Command Queueing enabled >>> da4: 1907729MB (3907029168 512 byte sectors: 255H 63S/T 243201C) >>> da5 at mpt1 bus 0 scbus1 target 5 lun 0 >>> da5: Fixed Direct Access SCSI-5 device >>> da5: 300.000MB/s transfers >>> da5: Command Queueing enabled >>> da5: 953869MB (1953525168 512 byte sectors: 255H 63S/T 121601C) >>> da6 at mpt1 bus 0 scbus1 target 6 lun 0 >>> da6: Fixed Direct Access SCSI-5 device >>> da6: 300.000MB/s transfers >>> da6: Command Queueing enabled >>> da6: 953869MB (1953525168 512 byte sectors: 255H 63S/T 121601C) >>> da7 at mpt1 bus 0 scbus1 target 7 lun 0 >>> da7: Fixed Direct Access SCSI-5 device >>> da7: 300.000MB/s transfers >>> da7: Command Queueing enabled >>> da7: 953869MB (1953525168 512 byte sectors: 255H 63S/T 121601C) >>> SMP: AP CPU #1 Launched! >>> uhub5: 10 ports with 10 removable, self powered >>> GEOM: da7: geometry does not match label (16h,63s != 255h,63s). >>> Trying to mount root from ufs:/dev/ad16s1a >>> WARNING: / was not properly dismounted >>> ZFS filesystem version 5 >>> ZFS storage pool version 28 >>> WARNING: /tmp was not properly dismounted >>> WARNING: /usr was not properly dismounted >>> WARNING: /var was not properly dismounted >>> 0 >>> mpt1: request 0xffffff80002c57f0:2369 timed out for ccb >>> 0xffffff00063bb000 >>> (req->ccb 0xffffff00063bb000) >>> mpt1: attempting to abort req 0xffffff80002c57f0:2369 function 0 >>> mpt1: mpt_wait_req(1) timed out >>> mpt1: mpt_recover_commands: abort timed-out. Resetting controller >>> mpt1: mpt_cam_event: 0x80 >>> mpt1: mpt_cam_event: 0x80 >>> mpt1: completing timedout/aborted req 0xffffff80002c57f0:2369 >>> mpt1: mpt_cam_event: 0x16 >>> mpt1: mpt_cam_event: 0x12 >>> mpt1: mpt_cam_event: 0x12 >>> mpt1: mpt_cam_event: 0x12 >>> mpt1: mpt_cam_event: 0x12 >>> mpt1: mpt_cam_event: 0x12 >>> mpt1: mpt_cam_event: 0x12 >>> mpt1: mpt_cam_event: 0x12 >>> mpt1: mpt_cam_event: 0x12 >>> mpt1: mpt_cam_event: 0x16 >>> mpt1: request 0xffffff80002c5c70:2375 timed out for ccb >>> 0xffffff00063bb000 >>> (req->ccb 0xffffff00063bb000) >>> mpt1: attempting to abort req 0xffffff80002c5c70:2375 function 0 >>> mpt1: completing timedout/aborted req 0xffffff80002c5c70:2375 >>> mpt1: >>> abort of req 0xffffff80002c5c70:0 completed >>> mpt1: mpt_cam_event: 0x16 >>> mpt1: mpt_cam_event: 0x16 >>> mpt1: request 0xffffff80002c5fd0:2379 timed out for ccb >>> 0xffffff00063bb000 >>> (req->ccb 0xffffff00063bb000) >>> mpt1: attempting to abort req 0xffffff80002c5fd0:2379 function 0 >>> mpt1: completing timedout/aborted req 0xffffff80002c5fd0:2379 >>> mpt1: >>> abort of req 0xffffff80002c5fd0:0 completed >>> mpt1: mpt_cam_event: 0x16 >>> mpt1: mpt_cam_event: 0x16 >>> mpt1: request 0xffffff80002c6210:2383 timed out for ccb >>> 0xffffff00063bb000 >>> (req->ccb 0xffffff00063bb000) >>> mpt1: attempting to abort req 0xffffff80002c6210:2383 function 0 >>> mpt1: completing timedout/aborted req 0xffffff80002c6210:2383 >>> mpt1: >>> abort of req 0xffffff80002c6210:0 completed >>> mpt1: mpt_cam_event: 0x16 >>> mpt1: mpt_cam_event: 0x16 >>> mpt1: request 0xffffff80002c6180:2387 timed out for ccb >>> 0xffffff00063bb000 >>> (req->ccb 0xffffff00063bb000) >>> mpt1: attempting to abort req 0xffffff80002c6180:2387 function 0 >>> mpt1: completing timedout/aborted req 0xffffff80002c6180:2387 >>> mpt1: >>> abort of req 0xffffff80002c6180:0 completed >>> mpt1: mpt_cam_event: 0x16 >>> mpt1: mpt_cam_event: 0x16 >>> mpt1: request 0xffffff80002c62a0:2391 timed out for ccb >>> 0xffffff00063bb000 >>> (req->ccb 0xffffff00063bb000) >>> mpt1: attempting to abort req 0xffffff80002c62a0:2391 function 0 >>> mpt1: completing timedout/aborted req 0xffffff80002c62a0:2391 >>> mpt1: >>> abort of req 0xffffff80002c62a0:0 completed >>> mpt1: mpt_cam_event: 0x16 >>> mpt1: mpt_cam_event: 0x16 >>> mpt1: request 0xffffff80002c6720:2395 timed out for ccb >>> 0xffffff00063bb000 >>> (req->ccb 0xffffff00063bb000) >>> mpt1: attempting to abort req 0xffffff80002c6720:2395 function 0 >>> mpt1: completing timedout/aborted req 0xffffff80002c6720:2395 >>> mpt1: >>> abort of req 0xffffff80002c6720:0 completed >>> mpt1: mpt_cam_event: 0x16 >>> mpt1: mpt_cam_event: 0x16 >>> mpt1: request 0xffffff80002c67b0:2399 timed out for ccb >>> 0xffffff00063bb000 >>> (req->ccb 0xffffff00063bb000) >>> mpt1: attempting to abort req 0xffffff80002c67b0:2399 function 0 >>> mpt1: completing timedout/aborted req 0xffffff80002c67b0:2399 >>> mpt1: >>> abort of req 0xffffff80002c67b0:0 completed >>> mpt1: mpt_cam_event: 0x16 >>> mpt1: mpt_cam_event: 0x16 >>> mpt0: request 0xffffff80002a69e0:2082 timed out for ccb >>> 0xffffff0006389800 >>> (req->ccb 0xffffff0006389800) >>> mpt0: attempting to abort req 0xffffff80002a69e0:2082 function 0 >>> mpt0: completing timedout/aborted req 0xffffff80002a69e0:2082 >>> mpt0: abort of req 0xffffff80002a69e0:0 completed >>> mpt0: mpt_cam_event: 0x16 >>> mpt0: mpt_cam_event: 0x16 >>> mpt0: request 0xffffff80002a6c20:2086 timed out for ccb >>> 0xffffff0006389800 >>> (req->ccb 0xffffff0006389800) >>> mpt0: attempting to abort req 0xffffff80002a6c20:2086 function 0 >>> mpt0: completing timedout/aborted req 0xffffff80002a6c20:2086 >>> mpt0: abort of req 0xffffff80002a6c20:0 completed >>> mpt0: mpt_cam_event: 0x16 >>> mpt0: mpt_cam_event: 0x16 >>> mpt0: request 0xffffff80002a6cb0:2090 timed out for ccb >>> 0xffffff0006389800 >>> (req->ccb 0xffffff0006389800) >>> mpt0: attempting to abort req 0xffffff80002a6cb0:2090 function 0 >>> mpt0: completing timedout/aborted req 0xffffff80002a6cb0:2090 >>> mpt0: abort of req 0xffffff80002a6cb0:0 completed >>> mpt0: mpt_cam_event: 0x16 >>> mpt0: mpt_cam_event: 0x16 >>> mpt0: request 0xffffff80002a6b90:2094 timed out for ccb >>> 0xffffff0006389800 >>> (req->ccb 0xffffff0006389800) >>> mpt0: attempting to abort req 0xffffff80002a6b90:2094 function 0 >>> mpt0: completing timedout/aborted req 0xffffff80002a6b90:2094 >>> mpt0: abort of req 0xffffff80002a6b90:0 completed >>> mpt0: mpt_cam_event: 0x16 >>> mpt0: mpt_cam_event: 0x16 >>> tun0: link state changed to UP >>> (da8:mpt0:0:0:0): READ(10). CDB: 28 0 3e e2 6f 56 0 0 1 0 >>> (da8:mpt0:0:0:0): CAM status: SCSI Status Error >>> (da8:mpt0:0:0:0): SCSI status: Check Condition >>> (da8:mpt0:0:0:0): SCSI sense: UNIT ATTENTION asc:29,0 (Power on, reset, >>> or >>> bus device reset occurred) >>> (da11:mpt0:0:3:0): READ(10). CDB: 28 0 1a b6 92 0 0 0 80 0 >>> (da11:mpt0:0:3:0): CAM status: SCSI Status Error >>> (da11:mpt0:0:3:0): SCSI status: Check Condition >>> (da11:mpt0:0:3:0): SCSI sense: UNIT ATTENTION asc:29,0 (Power on, reset, >>> or >>> bus device reset occurred) >>> (da2:mpt1:0:2:0): READ(10). CDB: 28 0 76 7b de 0 0 0 80 0 >>> (da2:mpt1:0:2:0): CAM status: SCSI Status Error >>> (da2:mpt1:0:2:0): SCSI status: Check Condition >>> (da2:mpt1:0:2:0): SCSI sense: UNIT ATTENTION asc:29,0 (Power on, reset, >>> or >>> bus device reset occurred) >>> (da10:mpt0:0:2:0): READ(10). CDB: 28 0 1a ff 67 80 0 0 80 0 >>> (da10:mpt0:0:2:0): CAM status: SCSI Status Error >>> (da10:mpt0:0:2:0): SCSI status: Check Condition >>> (da10:mpt0:0:2:0): SCSI sense: UNIT ATTENTION asc:29,0 (Power on, reset, >>> or >>> bus device reset occurred) >>> (da5:mpt1:0:5:0): READ(10). CDB: 28 0 1a ff 67 80 0 0 80 0 >>> (da5:mpt1:0:5:0): CAM status: SCSI Status Error >>> (da5:mpt1:0:5:0): SCSI status: Check Condition >>> (da5:mpt1:0:5:0): SCSI sense: UNIT ATTENTION asc:29,0 (Power on, reset, >>> or >>> bus device reset occurred) >>> (da7:mpt1:0:7:0): READ(10). CDB: 28 0 40 d7 da 80 0 0 80 0 >>> (da7:mpt1:0:7:0): CAM status: SCSI Status Error >>> (da7:mpt1:0:7:0): SCSI status: Check Condition >>> (da7:mpt1:0:7:0): SCSI sense: UNIT ATTENTION asc:29,0 (Power on, reset, >>> or >>> bus device reset occurred) >>> (da6:mpt1:0:6:0): READ(10). CDB: 28 0 40 d7 da 80 0 0 80 0 >>> (da6:mpt1:0:6:0): CAM status: SCSI Status Error >>> (da6:mpt1:0:6:0): SCSI status: Check Condition >>> (da6:mpt1:0:6:0): SCSI sense: UNIT ATTENTION asc:29,0 (Power on, reset, >>> or >>> bus device reset occurred) >>> (da0:mpt1:0:0:0): READ(10). CDB: 28 0 76 91 87 e3 0 0 1 0 >>> (da0:mpt1:0:0:0): CAM status: SCSI Status Error >>> (da0:mpt1:0:0:0): SCSI status: Check Condition >>> (da0:mpt1:0:0:0): SCSI sense: UNIT ATTENTION asc:29,0 (Power on, reset, >>> or >>> bus device reset occurred) >>> (da3:mpt1:0:3:0): READ(10). CDB: 28 0 76 69 1 1c 0 0 1 0 >>> (da3:mpt1:0:3:0): CAM status: SCSI Status Error >>> (da3:mpt1:0:3:0): SCSI status: Check Condition >>> (da3:mpt1:0:3:0): SCSI sense: UNIT ATTENTION asc:29,0 (Power on, reset, >>> or >>> bus device reset occurred) >>> (da1:mpt1:0:1:0): READ(10). CDB: 28 0 76 69 1 1c 0 0 1 0 >>> (da1:mpt1:0:1:0): CAM status: SCSI Status Error >>> (da1:mpt1:0:1:0): SCSI status: Check Condition >>> (da1:mpt1:0:1:0): SCSI sense: UNIT ATTENTION asc:29,0 (Power on, reset, >>> or >>> bus device reset occurred) >>> (da9:mpt0:0:1:0): READ(10). CDB: 28 0 1a b3 d7 0 0 0 80 0 >>> (da9:mpt0:0:1:0): CAM status: SCSI Status Error >>> (da9:mpt0:0:1:0): SCSI status: Check Condition >>> (da9:mpt0:0:1:0): SCSI sense: UNIT ATTENTION asc:29,0 (Power on, reset, >>> or >>> bus device reset occurred) >>> (da4:mpt1:0:4:0): READ(10). CDB: 28 0 53 3c c6 0 0 0 80 0 >>> (da4:mpt1:0:4:0): CAM status: SCSI Status Error >>> (da4:mpt1:0:4:0): SCSI status: Check Condition >>> (da4:mpt1:0:4:0): SCSI sense: UNIT ATTENTION asc:29,0 (Power on, reset, >>> or >>> bus device reset occurred) >>> >>> >>> >>> > >>> > -- >>> > | Jeremy Chadwick jdc@parodius.com | >>> > | Parodius Networking http://www.parodius.com/ | >>> > | UNIX Systems Administrator Mountain View, CA, US | >>> > | Making life hard for others since 1977. PGP 4BD6C0CB | >>> > >>> > >>> >>> >>> -- >>> Joshua Boyd >>> _______________________________________________ >>> freebsd-stable@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >>> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org >>> " >>> >> >> > > > -- > Joshua Boyd > -- Joshua Boyd E-mail: boydjd@jbip.net http://www.jbip.net From owner-freebsd-stable@FreeBSD.ORG Wed Jun 22 05:22:33 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0277510657DF for ; Wed, 22 Jun 2011 05:22:33 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 706EB8FC08 for ; Wed, 22 Jun 2011 05:22:32 +0000 (UTC) Received: by vxg33 with SMTP id 33so483177vxg.13 for ; Tue, 21 Jun 2011 22:22:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=4jIrWnF6UWkBFM0MtIJnrProS/Eyb3kCJ0DhEG7f6Yo=; b=xl3OiYm/v4czW7hKGxOvzmq86uYuVYnOU9WbgJundIBYGUvv+E9a/efbl/2xx68XGE f0y3+i85ZTcdDIpIgiVicSjzuGBmPXa4svOFeYYJ4mZS/RokG+7Rjm+Y0vce5InAWHex lBhr+yFwThmLhKiSIUZPcEVtX8q45RTe02KfE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=MnuOhmT+cZ2M3Ffpk4j8yGQ29OsF7l2D3wXldP5nRishi19HatZZqmMdOWNGKX1ihJ wO62PfNZx2+QvnxnxL1DbWvK+FVq5xfvjwCCVu2mRtKfDcYCZR2tEEv1jPySMkBeCC4C I8KzXwI5jkhiv9Lwgzg/YRKLDwtaHHFRI8b+8= MIME-Version: 1.0 Received: by 10.52.185.104 with SMTP id fb8mr301030vdc.309.1308720151220; Tue, 21 Jun 2011 22:22:31 -0700 (PDT) Received: by 10.52.114.99 with HTTP; Tue, 21 Jun 2011 22:22:31 -0700 (PDT) In-Reply-To: References: <20110615075754.GA54879@icarus.home.lan> Date: Tue, 21 Jun 2011 22:22:31 -0700 Message-ID: From: Jack Vogel To: Joshua Boyd Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable , "Vogel, Jack" , Jeremy Chadwick Subject: Re: em0 watchdog timeouts on 8-STABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 05:22:33 -0000 I cannot repro this, I used your kernel config, this is on a Dell 1850 btw, I ran netperf stress from 3 clients, and have seen no watchdogs :( Jack On Tue, Jun 21, 2011 at 7:59 PM, Joshua Boyd wrote: > If needed, I can reproduce this on demand. Just need to know what sort of > statistics are needed when the problem is occurring. I've had to turn off my > weekly scrubs until I can figure out how to fix this problem. > > > On Wed, Jun 15, 2011 at 8:37 PM, Joshua Boyd wrote: > >> In the kernel. Here's my kernel configuration: >> >> http://pastebin.com/raw.php?i=4JL814m3 >> >> On Wed, Jun 15, 2011 at 8:20 PM, Jack Vogel wrote: >> >>> I have hardware now, am working on reproducing this. Just curious, do you >>> have >>> the em driver defined in the kernel, or as a module? >>> >>> Jack >>> >>> >>> On Wed, Jun 15, 2011 at 2:09 AM, Joshua Boyd wrote: >>> >>>> On Wed, Jun 15, 2011 at 3:57 AM, Jeremy Chadwick >>>> wrote: >>>> >>>> > On Wed, Jun 15, 2011 at 03:14:43AM -0400, Joshua Boyd wrote: >>>> > > I recently updated my server to the latest 8-STABLE, and upgraded to >>>> v28 >>>> > > ZFS. I have not had these problems on any other version of 8-STABLE >>>> or >>>> > > 7-STABLE, which this box was upgraded from some time ago. >>>> > > >>>> > > Now, during my weekly scrub, I get the following messages and em0 is >>>> > > unresponsive: >>>> > > >>>> > > Jun 12 03:07:58 foghornleghorn kernel: em0: Watchdog timeout -- >>>> resetting >>>> > > Jun 12 03:07:58 foghornleghorn kernel: em0: link state changed to >>>> DOWN >>>> > > Jun 12 03:08:01 foghornleghorn kernel: em0: link state changed to UP >>>> > > Jun 12 03:08:47 foghornleghorn kernel: em0: Watchdog timeout -- >>>> resetting >>>> > > Jun 12 03:08:47 foghornleghorn kernel: em0: link state changed to >>>> DOWN >>>> > > Jun 12 03:08:50 foghornleghorn kernel: em0: link state changed to UP >>>> > > >>>> > > My scrub is scheduled to start at 03:00:00, so it looks like >>>> watchdog >>>> > > timeouts start occurring pretty quickly once I/O ramps up. >>>> > > >>>> > > Here's some possibly relevant information, let me know if anything >>>> else >>>> > > would be helpful to troubleshoot. >>>> > > >>>> > > FreeBSD foghornleghorn.res.openband.net 8.2-STABLE FreeBSD >>>> 8.2-STABLE >>>> > #17: >>>> > > Mon Jun 6 19:40:19 EDT 2011 >>>> > > root@foghornleghorn.res.openband.net: >>>> /usr/obj/usr/src/sys/FOGHORNLEGHORN >>>> > > amd64 >>>> > > >>>> > > em0: port >>>> > 0xe800-0xe83f >>>> > > mem 0xfebe0000-0xfebfffff,0xfebc0000-0xfebdffff irq 20 at device 5.0 >>>> on >>>> > pci7 >>>> > > >>>> > > em0@pci0:7:5:0: class=0x020000 card=0x13768086 chip=0x107c8086 >>>> rev=0x05 >>>> > > hdr=0x00 >>>> > > vendor = 'Intel Corporation' >>>> > > device = 'Gigabit Ethernet Controller (Copper) rev 5 >>>> (82541PI)' >>>> > > class = network >>>> > > subclass = ethernet >>>> > > >>>> > > And, the SAS cards: >>>> > > >>>> > > dev.mpt.0.%desc: LSILogic SAS/SATA Adapter >>>> > > dev.mpt.0.%driver: mpt >>>> > > dev.mpt.0.%location: slot=0 function=0 >>>> > > dev.mpt.0.%pnpinfo: vendor=0x1000 device=0x0058 subvendor=0x15d9 >>>> > > subdevice=0xa580 class=0x010000 >>>> > > dev.mpt.0.%parent: pci1 >>>> > > dev.mpt.0.debug: 3 >>>> > > dev.mpt.0.role: 1 >>>> > > dev.mpt.1.%desc: LSILogic SAS/SATA Adapter >>>> > > dev.mpt.1.%driver: mpt >>>> > > dev.mpt.1.%location: slot=0 function=0 >>>> > > dev.mpt.1.%pnpinfo: vendor=0x1000 device=0x0058 subvendor=0x15d9 >>>> > > subdevice=0xa580 class=0x010000 >>>> > > dev.mpt.1.%parent: pci2 >>>> > > dev.mpt.1.debug: 3 >>>> > > dev.mpt.1.role: 1 >>>> > > dev.mpt.2.%desc: LSILogic SAS/SATA Adapter >>>> > > dev.mpt.2.%driver: mpt >>>> > > dev.mpt.2.%location: slot=0 function=0 >>>> > > dev.mpt.2.%pnpinfo: vendor=0x1000 device=0x0058 subvendor=0x1000 >>>> > > subdevice=0x30a0 class=0x010000 >>>> > > dev.mpt.2.%parent: pci6 >>>> > > dev.mpt.2.debug: 3 >>>> > > dev.mpt.2.role: 1 >>>> > >>>> > Please provide output from the following commands (as root): >>>> > >>>> > # pciconf -lvcb >>>> > >>>> >>>> hostb0@pci0:0:0:0: class=0x060000 card=0x59561002 chip=0x59561002 >>>> rev=0x00 >>>> hdr=0x00 >>>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>>> device = 'RD790 GFX Dual Slot' >>>> class = bridge >>>> subclass = HOST-PCI >>>> pcib1@pci0:0:2:0: class=0x060400 card=0x59561002 chip=0x59781002 >>>> rev=0x00 >>>> hdr=0x01 >>>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>>> device = 'RD790 PCI to PCI bridge (external gfx0 port A)' >>>> class = bridge >>>> subclass = PCI-PCI >>>> pcib2@pci0:0:3:0: class=0x060400 card=0x59561002 chip=0x59791002 >>>> rev=0x00 >>>> hdr=0x01 >>>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>>> device = 'RD790 PCI to PCI bridge (external gfx0 port B)' >>>> class = bridge >>>> subclass = PCI-PCI >>>> pcib3@pci0:0:4:0: class=0x060400 card=0x59561002 chip=0x597a1002 >>>> rev=0x00 >>>> hdr=0x01 >>>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>>> device = 'RD790 PCI to PCI bridge (PCIe gpp port A)' >>>> class = bridge >>>> subclass = PCI-PCI >>>> pcib4@pci0:0:6:0: class=0x060400 card=0x59561002 chip=0x597c1002 >>>> rev=0x00 >>>> hdr=0x01 >>>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>>> device = 'RD790 PCI to PCI bridge (PCIe gpp port C)' >>>> class = bridge >>>> subclass = PCI-PCI >>>> pcib5@pci0:0:7:0: class=0x060400 card=0x59561002 chip=0x597d1002 >>>> rev=0x00 >>>> hdr=0x01 >>>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>>> device = 'RD790 PCI to PCI bridge (PCIe gpp port D)' >>>> class = bridge >>>> subclass = PCI-PCI >>>> pcib6@pci0:0:11:0: class=0x060400 card=0x59561002 chip=0x59801002 >>>> rev=0x00 >>>> hdr=0x01 >>>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>>> device = 'RD790 PCI to PCI bridge (external gfx1 port A)' >>>> class = bridge >>>> subclass = PCI-PCI >>>> atapci4@pci0:0:18:0: class=0x01018f card=0x81ef1043 chip=0x43801002 >>>> rev=0x00 >>>> hdr=0x00 >>>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>>> device = 'IXP SB600 Serial ATA Controller' >>>> class = mass storage >>>> subclass = ATA >>>> ohci0@pci0:0:19:0: class=0x0c0310 card=0x82881043 chip=0x43871002 >>>> rev=0x00 >>>> hdr=0x00 >>>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>>> device = 'IXP SB600 USB Controller (OHCI0)' >>>> class = serial bus >>>> subclass = USB >>>> ohci1@pci0:0:19:1: class=0x0c0310 card=0x82881043 chip=0x43881002 >>>> rev=0x00 >>>> hdr=0x00 >>>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>>> device = 'IXP SB600 USB Controller (OHCI1)' >>>> class = serial bus >>>> subclass = USB >>>> ohci2@pci0:0:19:2: class=0x0c0310 card=0x82881043 chip=0x43891002 >>>> rev=0x00 >>>> hdr=0x00 >>>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>>> device = 'IXP SB600 USB Controller (OHCI2)' >>>> class = serial bus >>>> subclass = USB >>>> ohci3@pci0:0:19:3: class=0x0c0310 card=0x82881043 chip=0x438a1002 >>>> rev=0x00 >>>> hdr=0x00 >>>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>>> device = 'IXP SB600 USB Controller (OHCI3)' >>>> class = serial bus >>>> subclass = USB >>>> ohci4@pci0:0:19:4: class=0x0c0310 card=0x82881043 chip=0x438b1002 >>>> rev=0x00 >>>> hdr=0x00 >>>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>>> device = 'IXP SB600 USB Controller (OHCI4)' >>>> class = serial bus >>>> subclass = USB >>>> ehci0@pci0:0:19:5: class=0x0c0320 card=0x82881043 chip=0x43861002 >>>> rev=0x00 >>>> hdr=0x00 >>>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>>> device = 'IXP SB600 USB Controller (EHCI)' >>>> class = serial bus >>>> subclass = USB >>>> none0@pci0:0:20:0: class=0x0c0500 card=0x82881043 chip=0x43851002 >>>> rev=0x14 >>>> hdr=0x00 >>>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>>> device = 'ATI SMBus (ATI RD600/RS600)' >>>> class = serial bus >>>> subclass = SMBus >>>> atapci5@pci0:0:20:1: class=0x01018a card=0x82881043 chip=0x438c1002 >>>> rev=0x00 >>>> hdr=0x00 >>>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>>> device = 'ATI RD600/RS600 IDE Controller (RD600/RS600)' >>>> class = mass storage >>>> subclass = ATA >>>> none1@pci0:0:20:2: class=0x040300 card=0x82881043 chip=0x43831002 >>>> rev=0x00 >>>> hdr=0x00 >>>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>>> device = 'IXP SB600 High Definition Audio Controller' >>>> class = multimedia >>>> subclass = HDA >>>> isab0@pci0:0:20:3: class=0x060100 card=0x82881043 chip=0x438d1002 >>>> rev=0x00 >>>> hdr=0x00 >>>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>>> device = 'IXP SB600 PCI to LPC Bridge' >>>> class = bridge >>>> subclass = PCI-ISA >>>> pcib7@pci0:0:20:4: class=0x060401 card=0x00000000 chip=0x43841002 >>>> rev=0x00 >>>> hdr=0x01 >>>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>>> device = 'IXP SB600 PCI to PCI Bridge' >>>> class = bridge >>>> subclass = PCI-PCI >>>> hostb1@pci0:0:24:0: class=0x060000 card=0x00000000 chip=0x12001022 >>>> rev=0x00 >>>> hdr=0x00 >>>> vendor = 'Advanced Micro Devices (AMD)' >>>> device = '(Family 10h) Athlon64/Opteron/Sempron HyperTransport >>>> Technology Configuration' >>>> class = bridge >>>> subclass = HOST-PCI >>>> hostb2@pci0:0:24:1: class=0x060000 card=0x00000000 chip=0x12011022 >>>> rev=0x00 >>>> hdr=0x00 >>>> vendor = 'Advanced Micro Devices (AMD)' >>>> device = '(Family 10h) Athlon64/Opteron/Sempron Address Map' >>>> class = bridge >>>> subclass = HOST-PCI >>>> hostb3@pci0:0:24:2: class=0x060000 card=0x00000000 chip=0x12021022 >>>> rev=0x00 >>>> hdr=0x00 >>>> vendor = 'Advanced Micro Devices (AMD)' >>>> device = '(Family 10h) Athlon64/Opteron/Sempron DRAM Controller' >>>> class = bridge >>>> subclass = HOST-PCI >>>> hostb4@pci0:0:24:3: class=0x060000 card=0x00000000 chip=0x12031022 >>>> rev=0x00 >>>> hdr=0x00 >>>> vendor = 'Advanced Micro Devices (AMD)' >>>> device = '(Family 10h) Athlon64/Opteron/Sempron Miscellaneous >>>> Control' >>>> class = bridge >>>> subclass = HOST-PCI >>>> hostb5@pci0:0:24:4: class=0x060000 card=0x00000000 chip=0x12041022 >>>> rev=0x00 >>>> hdr=0x00 >>>> vendor = 'Advanced Micro Devices (AMD)' >>>> device = '(Family 10h) Athlon64/Opteron/Sempron Link Control' >>>> class = bridge >>>> subclass = HOST-PCI >>>> mpt0@pci0:1:0:0: class=0x010000 card=0xa58015d9 chip=0x00581000 >>>> rev=0x08 >>>> hdr=0x00 >>>> vendor = 'LSI Logic (Was: Symbios Logic, NCR)' >>>> device = 'SAS 3000 series, 8-port with 1068E -StorPort' >>>> class = mass storage >>>> subclass = SCSI >>>> mpt1@pci0:2:0:0: class=0x010000 card=0xa58015d9 chip=0x00581000 >>>> rev=0x08 >>>> hdr=0x00 >>>> vendor = 'LSI Logic (Was: Symbios Logic, NCR)' >>>> device = 'SAS 3000 series, 8-port with 1068E -StorPort' >>>> class = mass storage >>>> subclass = SCSI >>>> atapci0@pci0:3:0:0: class=0x01018f card=0x612111ab chip=0x612111ab >>>> rev=0xb1 >>>> hdr=0x00 >>>> vendor = 'Marvell Semiconductor (Was: Galileo Technology Ltd)' >>>> device = '6121 SATA2 Controller' >>>> class = mass storage >>>> subclass = ATA >>>> mskc0@pci0:4:0:0: class=0x020000 card=0x81f81043 chip=0x436411ab >>>> rev=0x12 >>>> hdr=0x00 >>>> vendor = 'Marvell Semiconductor (Was: Galileo Technology Ltd)' >>>> device = 'Yukon PCI-E Gigabit Ethernet Controller (88E8056)' >>>> class = network >>>> subclass = ethernet >>>> atapci2@pci0:5:0:0: class=0x01018f card=0x612111ab chip=0x612111ab >>>> rev=0xb2 >>>> hdr=0x00 >>>> vendor = 'Marvell Semiconductor (Was: Galileo Technology Ltd)' >>>> device = '6121 SATA2 Controller' >>>> class = mass storage >>>> subclass = ATA >>>> mpt2@pci0:6:0:0: class=0x010000 card=0x30a01000 chip=0x00581000 >>>> rev=0x08 >>>> hdr=0x00 >>>> vendor = 'LSI Logic (Was: Symbios Logic, NCR)' >>>> device = 'SAS 3000 series, 8-port with 1068E -StorPort' >>>> class = mass storage >>>> subclass = SCSI >>>> em0@pci0:7:5:0: class=0x020000 card=0x13768086 chip=0x107c8086 rev=0x05 >>>> hdr=0x00 >>>> vendor = 'Intel Corporation' >>>> device = 'Gigabit Ethernet Controller (Copper) rev 5 (82541PI)' >>>> class = network >>>> subclass = ethernet >>>> vgapci0@pci0:7:6:0: class=0x030000 card=0x00000000 chip=0x88115333 >>>> rev=0x44 >>>> hdr=0x00 >>>> vendor = 'S3 Graphics Co., Ltd' >>>> device = '86C732 Trio32, 86C764 Trio64, 86C765 Trio64V+ Rev 01' >>>> class = display >>>> subclass = VGA >>>> none2@pci0:7:8:0: class=0x0c0010 card=0x82941043 chip=0x581111c1 >>>> rev=0x70 >>>> hdr=0x00 >>>> vendor = 'Lucent/Agere Systems (Was: AT&T MicroElectronics)' >>>> device = '1394A PCI PHY/Link Open Host Ctrlr I/F (FW322)' >>>> class = serial bus >>>> subclass = FireWire >>>> [josh@foghornleghorn /var/log]$ sudo su - >>>> foghornleghorn# pciconf -lvcb >>>> hostb0@pci0:0:0:0: class=0x060000 card=0x59561002 chip=0x59561002 >>>> rev=0x00 >>>> hdr=0x00 >>>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>>> device = 'RD790 GFX Dual Slot' >>>> class = bridge >>>> subclass = HOST-PCI >>>> cap 08[c4] = HT slave >>>> cap 08[40] = HT retry mode >>>> cap 08[54] = HT unit ID clumping >>>> cap 08[9c] = HT unknown d03c >>>> pcib1@pci0:0:2:0: class=0x060400 card=0x59561002 chip=0x59781002 >>>> rev=0x00 >>>> hdr=0x01 >>>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>>> device = 'RD790 PCI to PCI bridge (external gfx0 port A)' >>>> class = bridge >>>> subclass = PCI-PCI >>>> cap 01[50] = powerspec 3 supports D0 D3 current D0 >>>> cap 10[58] = PCI-Express 2 root port max data 128(128) link x4(x8) >>>> cap 05[a0] = MSI supports 1 message >>>> cap 0d[b0] = PCI Bridge card=0x59561002 >>>> cap 08[b8] = HT MSI fixed address window enabled at 0xfee00000 >>>> ecap 000b[100] = unknown 1 >>>> ecap 0002[110] = VC 1 max VC0 >>>> pcib2@pci0:0:3:0: class=0x060400 card=0x59561002 chip=0x59791002 >>>> rev=0x00 >>>> hdr=0x01 >>>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>>> device = 'RD790 PCI to PCI bridge (external gfx0 port B)' >>>> class = bridge >>>> subclass = PCI-PCI >>>> cap 01[50] = powerspec 3 supports D0 D3 current D0 >>>> cap 10[58] = PCI-Express 2 root port max data 128(128) link x4(x8) >>>> cap 05[a0] = MSI supports 1 message >>>> cap 0d[b0] = PCI Bridge card=0x59561002 >>>> cap 08[b8] = HT MSI fixed address window enabled at 0xfee00000 >>>> ecap 000b[100] = unknown 1 >>>> ecap 0002[110] = VC 1 max VC0 >>>> pcib3@pci0:0:4:0: class=0x060400 card=0x59561002 chip=0x597a1002 >>>> rev=0x00 >>>> hdr=0x01 >>>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>>> device = 'RD790 PCI to PCI bridge (PCIe gpp port A)' >>>> class = bridge >>>> subclass = PCI-PCI >>>> cap 01[50] = powerspec 3 supports D0 D3 current D0 >>>> cap 10[58] = PCI-Express 2 root port max data 128(128) link x1(x2) >>>> cap 05[a0] = MSI supports 1 message >>>> cap 0d[b0] = PCI Bridge card=0x59561002 >>>> cap 08[b8] = HT MSI fixed address window enabled at 0xfee00000 >>>> ecap 000b[100] = unknown 1 >>>> ecap 0002[110] = VC 1 max VC0 >>>> pcib4@pci0:0:6:0: class=0x060400 card=0x59561002 chip=0x597c1002 >>>> rev=0x00 >>>> hdr=0x01 >>>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>>> device = 'RD790 PCI to PCI bridge (PCIe gpp port C)' >>>> class = bridge >>>> subclass = PCI-PCI >>>> cap 01[50] = powerspec 3 supports D0 D3 current D0 >>>> cap 10[58] = PCI-Express 2 root port max data 128(128) link x1(x1) >>>> cap 05[a0] = MSI supports 1 message >>>> cap 0d[b0] = PCI Bridge card=0x59561002 >>>> cap 08[b8] = HT MSI fixed address window enabled at 0xfee00000 >>>> ecap 000b[100] = unknown 1 >>>> ecap 0002[110] = VC 1 max VC0 >>>> pcib5@pci0:0:7:0: class=0x060400 card=0x59561002 chip=0x597d1002 >>>> rev=0x00 >>>> hdr=0x01 >>>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>>> device = 'RD790 PCI to PCI bridge (PCIe gpp port D)' >>>> class = bridge >>>> subclass = PCI-PCI >>>> cap 01[50] = powerspec 3 supports D0 D3 current D0 >>>> cap 10[58] = PCI-Express 2 root port max data 128(128) link x1(x1) >>>> cap 05[a0] = MSI supports 1 message >>>> cap 0d[b0] = PCI Bridge card=0x59561002 >>>> cap 08[b8] = HT MSI fixed address window enabled at 0xfee00000 >>>> ecap 000b[100] = unknown 1 >>>> ecap 0002[110] = VC 1 max VC0 >>>> pcib6@pci0:0:11:0: class=0x060400 card=0x59561002 chip=0x59801002 >>>> rev=0x00 >>>> hdr=0x01 >>>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>>> device = 'RD790 PCI to PCI bridge (external gfx1 port A)' >>>> class = bridge >>>> subclass = PCI-PCI >>>> cap 01[50] = powerspec 3 supports D0 D3 current D0 >>>> cap 10[58] = PCI-Express 2 root port max data 128(128) link x4(x8) >>>> cap 05[a0] = MSI supports 1 message >>>> cap 0d[b0] = PCI Bridge card=0x59561002 >>>> cap 08[b8] = HT MSI fixed address window enabled at 0xfee00000 >>>> ecap 000b[100] = unknown 1 >>>> ecap 0002[110] = VC 1 max VC0 >>>> atapci4@pci0:0:18:0: class=0x01018f card=0x81ef1043 chip=0x43801002 >>>> rev=0x00 >>>> hdr=0x00 >>>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>>> device = 'IXP SB600 Serial ATA Controller' >>>> class = mass storage >>>> subclass = ATA >>>> bar [10] = type I/O Port, range 32, base 0x5000, size 8, enabled >>>> bar [14] = type I/O Port, range 32, base 0x4000, size 4, enabled >>>> bar [18] = type I/O Port, range 32, base 0x3000, size 8, enabled >>>> bar [1c] = type I/O Port, range 32, base 0x2000, size 4, enabled >>>> bar [20] = type I/O Port, range 32, base 0x1000, size 16, enabled >>>> bar [24] = type Memory, range 32, base 0xf71ff800, size 1024, >>>> enabled >>>> cap 01[60] = powerspec 2 supports D0 D3 current D0 >>>> ohci0@pci0:0:19:0: class=0x0c0310 card=0x82881043 chip=0x43871002 >>>> rev=0x00 >>>> hdr=0x00 >>>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>>> device = 'IXP SB600 USB Controller (OHCI0)' >>>> class = serial bus >>>> subclass = USB >>>> bar [10] = type Memory, range 32, base 0xf71fe000, size 4096, >>>> enabled >>>> ohci1@pci0:0:19:1: class=0x0c0310 card=0x82881043 chip=0x43881002 >>>> rev=0x00 >>>> hdr=0x00 >>>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>>> device = 'IXP SB600 USB Controller (OHCI1)' >>>> class = serial bus >>>> subclass = USB >>>> bar [10] = type Memory, range 32, base 0xf71fd000, size 4096, >>>> enabled >>>> ohci2@pci0:0:19:2: class=0x0c0310 card=0x82881043 chip=0x43891002 >>>> rev=0x00 >>>> hdr=0x00 >>>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>>> device = 'IXP SB600 USB Controller (OHCI2)' >>>> class = serial bus >>>> subclass = USB >>>> bar [10] = type Memory, range 32, base 0xf71fc000, size 4096, >>>> enabled >>>> ohci3@pci0:0:19:3: class=0x0c0310 card=0x82881043 chip=0x438a1002 >>>> rev=0x00 >>>> hdr=0x00 >>>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>>> device = 'IXP SB600 USB Controller (OHCI3)' >>>> class = serial bus >>>> subclass = USB >>>> bar [10] = type Memory, range 32, base 0xf71fb000, size 4096, >>>> enabled >>>> ohci4@pci0:0:19:4: class=0x0c0310 card=0x82881043 chip=0x438b1002 >>>> rev=0x00 >>>> hdr=0x00 >>>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>>> device = 'IXP SB600 USB Controller (OHCI4)' >>>> class = serial bus >>>> subclass = USB >>>> bar [10] = type Memory, range 32, base 0xf71fa000, size 4096, >>>> enabled >>>> ehci0@pci0:0:19:5: class=0x0c0320 card=0x82881043 chip=0x43861002 >>>> rev=0x00 >>>> hdr=0x00 >>>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>>> device = 'IXP SB600 USB Controller (EHCI)' >>>> class = serial bus >>>> subclass = USB >>>> bar [10] = type Memory, range 32, base 0xf71ff000, size 256, >>>> enabled >>>> cap 01[c0] = powerspec 2 supports D0 D1 D2 D3 current D0 >>>> cap 05[d0] = MSI supports 1 message >>>> cap 0a[e4] = EHCI Debug Port at offset 0xe0 in map 0x14 >>>> none0@pci0:0:20:0: class=0x0c0500 card=0x82881043 chip=0x43851002 >>>> rev=0x14 >>>> hdr=0x00 >>>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>>> device = 'ATI SMBus (ATI RD600/RS600)' >>>> class = serial bus >>>> subclass = SMBus >>>> bar [10] = type I/O Port, range 32, base 0xb00, size 16, enabled >>>> cap 08[b0] = HT MSI fixed address window disabled at 0xfee00000 >>>> atapci5@pci0:0:20:1: class=0x01018a card=0x82881043 chip=0x438c1002 >>>> rev=0x00 >>>> hdr=0x00 >>>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>>> device = 'ATI RD600/RS600 IDE Controller (RD600/RS600)' >>>> class = mass storage >>>> subclass = ATA >>>> bar [10] = type I/O Port, range 32, base 0x1f0, size 8, enabled >>>> bar [14] = type I/O Port, range 32, base 0x3f4, size 1, enabled >>>> bar [18] = type I/O Port, range 32, base 0x170, size 8, enabled >>>> bar [1c] = type I/O Port, range 32, base 0x374, size 1, enabled >>>> bar [20] = type I/O Port, range 32, base 0xff00, size 16, enabled >>>> none1@pci0:0:20:2: class=0x040300 card=0x82881043 chip=0x43831002 >>>> rev=0x00 >>>> hdr=0x00 >>>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>>> device = 'IXP SB600 High Definition Audio Controller' >>>> class = multimedia >>>> subclass = HDA >>>> bar [10] = type Memory, range 64, base 0xf71f4000, size 16384, >>>> enabled >>>> cap 01[50] = powerspec 2 supports D0 D3 current D0 >>>> isab0@pci0:0:20:3: class=0x060100 card=0x82881043 chip=0x438d1002 >>>> rev=0x00 >>>> hdr=0x00 >>>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>>> device = 'IXP SB600 PCI to LPC Bridge' >>>> class = bridge >>>> subclass = PCI-ISA >>>> pcib7@pci0:0:20:4: class=0x060401 card=0x00000000 chip=0x43841002 >>>> rev=0x00 >>>> hdr=0x01 >>>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>>> device = 'IXP SB600 PCI to PCI Bridge' >>>> class = bridge >>>> subclass = PCI-PCI >>>> hostb1@pci0:0:24:0: class=0x060000 card=0x00000000 chip=0x12001022 >>>> rev=0x00 >>>> hdr=0x00 >>>> vendor = 'Advanced Micro Devices (AMD)' >>>> device = '(Family 10h) Athlon64/Opteron/Sempron HyperTransport >>>> Technology Configuration' >>>> class = bridge >>>> subclass = HOST-PCI >>>> cap 08[80] = HT host >>>> hostb2@pci0:0:24:1: class=0x060000 card=0x00000000 chip=0x12011022 >>>> rev=0x00 >>>> hdr=0x00 >>>> vendor = 'Advanced Micro Devices (AMD)' >>>> device = '(Family 10h) Athlon64/Opteron/Sempron Address Map' >>>> class = bridge >>>> subclass = HOST-PCI >>>> hostb3@pci0:0:24:2: class=0x060000 card=0x00000000 chip=0x12021022 >>>> rev=0x00 >>>> hdr=0x00 >>>> vendor = 'Advanced Micro Devices (AMD)' >>>> device = '(Family 10h) Athlon64/Opteron/Sempron DRAM Controller' >>>> class = bridge >>>> subclass = HOST-PCI >>>> hostb4@pci0:0:24:3: class=0x060000 card=0x00000000 chip=0x12031022 >>>> rev=0x00 >>>> hdr=0x00 >>>> vendor = 'Advanced Micro Devices (AMD)' >>>> device = '(Family 10h) Athlon64/Opteron/Sempron Miscellaneous >>>> Control' >>>> class = bridge >>>> subclass = HOST-PCI >>>> cap 0f[f0] = unknown >>>> hostb5@pci0:0:24:4: class=0x060000 card=0x00000000 chip=0x12041022 >>>> rev=0x00 >>>> hdr=0x00 >>>> vendor = 'Advanced Micro Devices (AMD)' >>>> device = '(Family 10h) Athlon64/Opteron/Sempron Link Control' >>>> class = bridge >>>> subclass = HOST-PCI >>>> mpt0@pci0:1:0:0: class=0x010000 card=0xa58015d9 chip=0x00581000 >>>> rev=0x08 >>>> hdr=0x00 >>>> vendor = 'LSI Logic (Was: Symbios Logic, NCR)' >>>> device = 'SAS 3000 series, 8-port with 1068E -StorPort' >>>> class = mass storage >>>> subclass = SCSI >>>> bar [10] = type I/O Port, range 32, base 0x6000, size 256, disabled >>>> bar [14] = type Memory, range 64, base 0xf75fc000, size 16384, >>>> enabled >>>> bar [1c] = type Memory, range 64, base 0xf75e0000, size 65536, >>>> enabled >>>> cap 01[50] = powerspec 2 supports D0 D1 D2 D3 current D0 >>>> cap 10[68] = PCI-Express 1 endpoint max data 128(4096) link x4(x8) >>>> cap 05[98] = MSI supports 1 message, 64 bit >>>> cap 11[b0] = MSI-X supports 1 message in map 0x14 >>>> ecap 0001[100] = AER 1 1 fatal 1 non-fatal 0 corrected >>>> mpt1@pci0:2:0:0: class=0x010000 card=0xa58015d9 chip=0x00581000 >>>> rev=0x08 >>>> hdr=0x00 >>>> vendor = 'LSI Logic (Was: Symbios Logic, NCR)' >>>> device = 'SAS 3000 series, 8-port with 1068E -StorPort' >>>> class = mass storage >>>> subclass = SCSI >>>> bar [10] = type I/O Port, range 32, base 0x7000, size 256, disabled >>>> bar [14] = type Memory, range 64, base 0xf78fc000, size 16384, >>>> enabled >>>> bar [1c] = type Memory, range 64, base 0xf78e0000, size 65536, >>>> enabled >>>> cap 01[50] = powerspec 2 supports D0 D1 D2 D3 current D0 >>>> cap 10[68] = PCI-Express 1 endpoint max data 128(4096) link x4(x8) >>>> cap 05[98] = MSI supports 1 message, 64 bit >>>> cap 11[b0] = MSI-X supports 1 message in map 0x14 >>>> ecap 0001[100] = AER 1 1 fatal 1 non-fatal 0 corrected >>>> atapci0@pci0:3:0:0: class=0x01018f card=0x612111ab chip=0x612111ab >>>> rev=0xb1 >>>> hdr=0x00 >>>> vendor = 'Marvell Semiconductor (Was: Galileo Technology Ltd)' >>>> device = '6121 SATA2 Controller' >>>> class = mass storage >>>> subclass = ATA >>>> bar [10] = type I/O Port, range 32, base 0x9800, size 8, enabled >>>> bar [14] = type I/O Port, range 32, base 0x9400, size 4, enabled >>>> bar [18] = type I/O Port, range 32, base 0x9000, size 8, enabled >>>> bar [1c] = type I/O Port, range 32, base 0x8800, size 4, enabled >>>> bar [20] = type I/O Port, range 32, base 0x8400, size 16, enabled >>>> bar [24] = type Memory, range 32, base 0xf79ffc00, size 1024, >>>> enabled >>>> cap 01[48] = powerspec 2 supports D0 D1 D3 current D0 >>>> cap 05[50] = MSI supports 1 message >>>> cap 10[e0] = PCI-Express 1 legacy endpoint max data 128(128) link >>>> x1(x1) >>>> ecap 0001[100] = AER 1 0 fatal 0 non-fatal 2 corrected >>>> mskc0@pci0:4:0:0: class=0x020000 card=0x81f81043 chip=0x436411ab >>>> rev=0x12 >>>> hdr=0x00 >>>> vendor = 'Marvell Semiconductor (Was: Galileo Technology Ltd)' >>>> device = 'Yukon PCI-E Gigabit Ethernet Controller (88E8056)' >>>> class = network >>>> subclass = ethernet >>>> bar [10] = type Memory, range 64, base 0xf7afc000, size 16384, >>>> enabled >>>> bar [18] = type I/O Port, range 32, base 0xa800, size 256, enabled >>>> cap 01[48] = powerspec 3 supports D0 D1 D2 D3 current D0 >>>> cap 03[50] = VPD >>>> cap 05[5c] = MSI supports 1 message, 64 bit enabled with 1 message >>>> cap 10[e0] = PCI-Express 1 legacy endpoint max data 128(128) link >>>> x1(x1) >>>> ecap 0001[100] = AER 1 0 fatal 0 non-fatal 1 corrected >>>> atapci2@pci0:5:0:0: class=0x01018f card=0x612111ab chip=0x612111ab >>>> rev=0xb2 >>>> hdr=0x00 >>>> vendor = 'Marvell Semiconductor (Was: Galileo Technology Ltd)' >>>> device = '6121 SATA2 Controller' >>>> class = mass storage >>>> subclass = ATA >>>> bar [10] = type I/O Port, range 32, base 0xc800, size 8, enabled >>>> bar [14] = type I/O Port, range 32, base 0xc400, size 4, enabled >>>> bar [18] = type I/O Port, range 32, base 0xc000, size 8, enabled >>>> bar [1c] = type I/O Port, range 32, base 0xb800, size 4, enabled >>>> bar [20] = type I/O Port, range 32, base 0xb400, size 16, enabled >>>> bar [24] = type Memory, range 32, base 0xf7bffc00, size 1024, >>>> enabled >>>> cap 01[48] = powerspec 2 supports D0 D1 D3 current D0 >>>> cap 05[50] = MSI supports 1 message >>>> cap 10[e0] = PCI-Express 1 legacy endpoint max data 128(128) link >>>> x1(x1) >>>> ecap 0001[100] = AER 1 0 fatal 0 non-fatal 1 corrected >>>> mpt2@pci0:6:0:0: class=0x010000 card=0x30a01000 chip=0x00581000 >>>> rev=0x08 >>>> hdr=0x00 >>>> vendor = 'LSI Logic (Was: Symbios Logic, NCR)' >>>> device = 'SAS 3000 series, 8-port with 1068E -StorPort' >>>> class = mass storage >>>> subclass = SCSI >>>> bar [10] = type I/O Port, range 32, base 0xd000, size 256, disabled >>>> bar [14] = type Memory, range 64, base 0xf7ffc000, size 16384, >>>> enabled >>>> bar [1c] = type Memory, range 64, base 0xf7fe0000, size 65536, >>>> enabled >>>> cap 01[50] = powerspec 2 supports D0 D1 D2 D3 current D0 >>>> cap 10[68] = PCI-Express 1 endpoint max data 128(4096) link x4(x8) >>>> cap 05[98] = MSI supports 1 message, 64 bit >>>> cap 11[b0] = MSI-X supports 1 message in map 0x14 >>>> ecap 0001[100] = AER 1 1 fatal 1 non-fatal 0 corrected >>>> em0@pci0:7:5:0: class=0x020000 card=0x13768086 chip=0x107c8086 rev=0x05 >>>> hdr=0x00 >>>> vendor = 'Intel Corporation' >>>> device = 'Gigabit Ethernet Controller (Copper) rev 5 (82541PI)' >>>> class = network >>>> subclass = ethernet >>>> bar [10] = type Memory, range 32, base 0xfebe0000, size 131072, >>>> enabled >>>> bar [14] = type Memory, range 32, base 0xfebc0000, size 131072, >>>> enabled >>>> bar [18] = type I/O Port, range 32, base 0xe800, size 64, enabled >>>> cap 01[dc] = powerspec 2 supports D0 D3 current D0 >>>> cap 07[e4] = PCI-X supports 2048 burst read, 1 split transaction >>>> vgapci0@pci0:7:6:0: class=0x030000 card=0x00000000 chip=0x88115333 >>>> rev=0x44 >>>> hdr=0x00 >>>> vendor = 'S3 Graphics Co., Ltd' >>>> device = '86C732 Trio32, 86C764 Trio64, 86C765 Trio64V+ Rev 01' >>>> class = display >>>> subclass = VGA >>>> bar [10] = type Memory, range 32, base 0xf8000000, size 67108864, >>>> enabled >>>> none2@pci0:7:8:0: class=0x0c0010 card=0x82941043 chip=0x581111c1 >>>> rev=0x70 >>>> hdr=0x00 >>>> vendor = 'Lucent/Agere Systems (Was: AT&T MicroElectronics)' >>>> device = '1394A PCI PHY/Link Open Host Ctrlr I/F (FW322)' >>>> class = serial bus >>>> subclass = FireWire >>>> bar [10] = type Memory, range 32, base 0xfeb8f000, size 4096, >>>> enabled >>>> cap 01[44] = powerspec 2 supports D0 D1 D2 D3 current D0 >>>> >>>> >>>> >>>> > # vmstat -i >>>> > >>>> >>>> interrupt total rate >>>> irq9: acpi0 1 0 >>>> irq16: atapci0+ 2 0 >>>> irq17: ohci1 ohci3 3 0 >>>> irq18: mpt0 ohci2+ 7066718 31 >>>> irq19: mpt1 atapci* 7798877 34 >>>> irq20: em0 11715792 51 >>>> irq22: atapci4 628883 2 >>>> cpu0: timer 455853831 1999 >>>> irq256: mskc0 97098730 425 >>>> cpu1: timer 455845190 1999 >>>> Total 1036008027 4544 >>>> >>>> >>>> >>>> > # sysctl -a | grep msi >>>> > >>>> >>>> hw.pci.honor_msi_blacklist: 1 >>>> hw.pci.enable_msix: 1 >>>> hw.pci.enable_msi: 1 >>>> >>>> >>>> >>>> > # dmesg >>>> > >>>> >>>> Copyright (c) 1992-2011 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 8.2-STABLE #17: Mon Jun 6 19:40:19 EDT 2011 >>>> root@foghornleghorn.res.openband.net: >>>> /usr/obj/usr/src/sys/FOGHORNLEGHORN >>>> amd64 >>>> Timecounter "i8254" frequency 1193182 Hz quality 0 >>>> CPU: AMD Phenom(tm) II X2 555 Processor (3209.77-MHz K8-class CPU) >>>> Origin = "AuthenticAMD" Id = 0x100f43 Family = 10 Model = 4 >>>> Stepping = >>>> 3 >>>> >>>> >>>> Features=0x178bfbff >>>> Features2=0x802009 >>>> AMD >>>> >>>> Features=0xee500800 >>>> AMD >>>> >>>> Features2=0x37ff >>>> TSC: P-state invariant >>>> real memory = 8589934592 (8192 MB) >>>> avail memory = 8257736704 (7875 MB) >>>> ACPI APIC Table: <092310 OEMAPIC > >>>> FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs >>>> FreeBSD/SMP: 1 package(s) x 2 core(s) >>>> cpu0 (BSP): APIC ID: 0 >>>> cpu1 (AP): APIC ID: 1 >>>> ioapic0 irqs 0-23 on motherboard >>>> acpi0: <092310 OEMRSDT> on motherboard >>>> acpi0: [ITHREAD] >>>> acpi0: Power Button (fixed) >>>> acpi0: reservation of fee00000, 1000 (3) failed >>>> acpi0: reservation of ffb80000, 80000 (3) failed >>>> acpi0: reservation of fff00000, 100000 (3) failed >>>> acpi0: reservation of 0, a0000 (3) failed >>>> acpi0: reservation of 100000, dff00000 (3) failed >>>> Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 >>>> acpi_timer0: <32-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 >>>> cpu0: on acpi0 >>>> cpu1: on acpi0 >>>> acpi_hpet0: iomem 0xfed00000-0xfed003ff on >>>> acpi0 >>>> Timecounter "HPET" frequency 14318180 Hz quality 900 >>>> pcib0: port 0xcf8-0xcff on acpi0 >>>> pci0: on pcib0 >>>> pcib1: irq 18 at device 2.0 on pci0 >>>> pci1: on pcib1 >>>> mpt0: port 0x6000-0x60ff mem >>>> 0xf75fc000-0xf75fffff,0xf75e0000-0xf75effff irq 18 at device 0.0 on pci1 >>>> mpt0: [ITHREAD] >>>> mpt0: MPI Version=1.5.20.0 >>>> pcib2: irq 19 at device 3.0 on pci0 >>>> pci2: on pcib2 >>>> mpt1: port 0x7000-0x70ff mem >>>> 0xf78fc000-0xf78fffff,0xf78e0000-0xf78effff irq 19 at device 0.0 on pci2 >>>> mpt1: [ITHREAD] >>>> mpt1: MPI Version=1.5.20.0 >>>> pcib3: irq 16 at device 4.0 on pci0 >>>> pci3: on pcib3 >>>> atapci0: port >>>> 0x9800-0x9807,0x9400-0x9403,0x9000-0x9007,0x8800-0x8803,0x8400-0x840f >>>> mem >>>> 0xf79ffc00-0xf79fffff irq 16 at device 0.0 on pci3 >>>> atapci0: [ITHREAD] >>>> atapci1: on atapci0 >>>> atapci1: [ITHREAD] >>>> atapci1: AHCI v1.00 controller with 3 3Gbps ports, PM supported >>>> ata2: on atapci1 >>>> ata2: [ITHREAD] >>>> ata3: on atapci1 >>>> ata3: [ITHREAD] >>>> ata4: on atapci0 >>>> ata4: [ITHREAD] >>>> pcib4: irq 18 at device 6.0 on pci0 >>>> pci4: on pcib4 >>>> mskc0: port 0xa800-0xa8ff mem >>>> 0xf7afc000-0xf7afffff irq 18 at device 0.0 on pci4 >>>> msk0: on >>>> mskc0 >>>> msk0: Ethernet address: 00:1f:c6:e9:f8:7c >>>> miibus0: on msk0 >>>> e1000phy0: PHY 0 on miibus0 >>>> e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, >>>> 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow >>>> mskc0: [ITHREAD] >>>> pcib5: irq 19 at device 7.0 on pci0 >>>> pci5: on pcib5 >>>> atapci2: port >>>> 0xc800-0xc807,0xc400-0xc403,0xc000-0xc007,0xb800-0xb803,0xb400-0xb40f >>>> mem >>>> 0xf7bffc00-0xf7bfffff irq 19 at device 0.0 on pci5 >>>> atapci2: [ITHREAD] >>>> atapci3: on atapci2 >>>> atapci3: [ITHREAD] >>>> atapci3: AHCI v1.00 controller with 3 3Gbps ports, PM supported >>>> ata5: on atapci3 >>>> ata5: [ITHREAD] >>>> ata6: on atapci3 >>>> ata6: [ITHREAD] >>>> ata7: on atapci2 >>>> ata7: [ITHREAD] >>>> pcib6: irq 19 at device 11.0 on pci0 >>>> pci6: on pcib6 >>>> mpt2: port 0xd000-0xd0ff mem >>>> 0xf7ffc000-0xf7ffffff,0xf7fe0000-0xf7feffff irq 19 at device 0.0 on pci6 >>>> mpt2: [ITHREAD] >>>> mpt2: MPI Version=1.5.19.0 >>>> atapci4: port >>>> 0x5000-0x5007,0x4000-0x4003,0x3000-0x3007,0x2000-0x2003,0x1000-0x100f >>>> mem >>>> 0xf71ff800-0xf71ffbff irq 22 at device 18.0 on pci0 >>>> atapci4: [ITHREAD] >>>> atapci4: AHCI v1.10 controller with 4 3Gbps ports, PM supported >>>> ata8: on atapci4 >>>> ata8: port is not ready (timeout 0ms) tfd = 000001d0 >>>> ata8: software reset clear timeout >>>> ata8: [ITHREAD] >>>> ata9: on atapci4 >>>> ata9: [ITHREAD] >>>> ata10: on atapci4 >>>> ata10: [ITHREAD] >>>> ata11: on atapci4 >>>> ata11: [ITHREAD] >>>> ohci0: mem 0xf71fe000-0xf71fefff irq 16 >>>> at >>>> device 19.0 on pci0 >>>> ohci0: [ITHREAD] >>>> usbus0: on ohci0 >>>> ohci1: mem 0xf71fd000-0xf71fdfff irq 17 >>>> at >>>> device 19.1 on pci0 >>>> ohci1: [ITHREAD] >>>> usbus1: on ohci1 >>>> ohci2: mem 0xf71fc000-0xf71fcfff irq 18 >>>> at >>>> device 19.2 on pci0 >>>> ohci2: [ITHREAD] >>>> usbus2: on ohci2 >>>> ohci3: mem 0xf71fb000-0xf71fbfff irq 17 >>>> at >>>> device 19.3 on pci0 >>>> ohci3: [ITHREAD] >>>> usbus3: on ohci3 >>>> ohci4: mem 0xf71fa000-0xf71fafff irq 18 >>>> at >>>> device 19.4 on pci0 >>>> ohci4: [ITHREAD] >>>> usbus4: on ohci4 >>>> ehci0: mem 0xf71ff000-0xf71ff0ff irq >>>> 19 >>>> at device 19.5 on pci0 >>>> ehci0: [ITHREAD] >>>> ehci0: AMD SB600/700 quirk applied >>>> usbus5: EHCI version 1.0 >>>> usbus5: on ehci0 >>>> pci0: at device 20.0 (no driver attached) >>>> atapci5: port >>>> 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xff00-0xff0f at device 20.1 on pci0 >>>> ata0: on atapci5 >>>> ata0: [ITHREAD] >>>> pci0: at device 20.2 (no driver attached) >>>> isab0: at device 20.3 on pci0 >>>> isa0: on isab0 >>>> pcib7: at device 20.4 on pci0 >>>> pci7: on pcib7 >>>> em0: port >>>> 0xe800-0xe83f >>>> mem 0xfebe0000-0xfebfffff,0xfebc0000-0xfebdffff irq 20 at device 5.0 on >>>> pci7 >>>> em0: [FILTER] >>>> em0: Ethernet address: 00:1b:21:4e:e5:2e >>>> vgapci0: mem 0xf8000000-0xfbffffff at device >>>> 6.0 on >>>> pci7 >>>> pci7: at device 8.0 (no driver attached) >>>> acpi_button0: on acpi0 >>>> atrtc0: port 0x70-0x71 irq 8 on acpi0 >>>> acpi_hpet1: iomem 0xfed00000-0xfed003ff on >>>> acpi0 >>>> device_attach: acpi_hpet1 attach returned 12 >>>> uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 >>>> uart0: [FILTER] >>>> orm0: at iomem >>>> 0xc0000-0xc7fff,0xc8000-0xc87ff,0xc8800-0xc97ff on isa0 >>>> sc0: at flags 0x100 on isa0 >>>> sc0: VGA <16 virtual consoles, flags=0x300> >>>> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on >>>> isa0 >>>> acpi_throttle0: on cpu0 >>>> acpi_throttle0: CLK_VAL field overlaps THT_EN bit >>>> device_attach: acpi_throttle0 attach returned 6 >>>> hwpstate0: on cpu0 >>>> Timecounters tick every 1.000 msec >>>> usbus0: 12Mbps Full Speed USB v1.0 >>>> usbus1: 12Mbps Full Speed USB v1.0 >>>> usbus2: 12Mbps Full Speed USB v1.0 >>>> usbus3: 12Mbps Full Speed USB v1.0 >>>> usbus4: 12Mbps Full Speed USB v1.0 >>>> usbus5: 480Mbps High Speed USB v2.0 >>>> ugen0.1: at usbus0 >>>> uhub0: on usbus0 >>>> ugen1.1: at usbus1 >>>> uhub1: on usbus1 >>>> ugen2.1: at usbus2 >>>> uhub2: on usbus2 >>>> ugen3.1: at usbus3 >>>> uhub3: on usbus3 >>>> ugen4.1: at usbus4 >>>> uhub4: on usbus4 >>>> ugen5.1: at usbus5 >>>> uhub5: on usbus5 >>>> ad16: 476940MB at ata8-master UDMA100 SATA >>>> 3Gb/s >>>> uhub0: 2 ports with 2 removable, self powered >>>> uhub1: 2 ports with 2 removable, self powered >>>> uhub2: 2 ports with 2 removable, self powered >>>> uhub3: 2 ports with 2 removable, self powered >>>> uhub4: 2 ports with 2 removable, self powered >>>> da8 at mpt0 bus 0 scbus0 target 0 lun 0 >>>> da8: Fixed Direct Access SCSI-5 device >>>> da8: 300.000MB/s transfers >>>> da8: Command Queueing enabled >>>> da8: 953869MB (1953525168 512 byte sectors: 255H 63S/T 121601C) >>>> da9 at mpt0 bus 0 scbus0 target 1 lun 0 >>>> da9: Fixed Direct Access SCSI-5 device >>>> da9: 300.000MB/s transfers >>>> da9: Command Queueing enabled >>>> da9: 953869MB (1953525168 512 byte sectors: 255H 63S/T 121601C) >>>> da10 at mpt0 bus 0 scbus0 target 2 lun 0 >>>> da10: Fixed Direct Access SCSI-5 device >>>> da10: 300.000MB/s transfers >>>> da10: Command Queueing enabled >>>> da10: 953869MB (1953525168 512 byte sectors: 255H 63S/T 121601C) >>>> da11 at mpt0 bus 0 scbus0 target 3 lun 0 >>>> da11: Fixed Direct Access SCSI-5 device >>>> da11: 300.000MB/s transfers >>>> da11: Command Queueing enabled >>>> da11: 953869MB (1953525168 512 byte sectors: 255H 63S/T 121601C) >>>> da12 at mpt0 bus 0 scbus0 target 4 lun 0 >>>> da12: Fixed Direct Access SCSI-5 device >>>> da12: 300.000MB/s transfers >>>> da12: Command Queueing enabled >>>> da12: 953869MB (1953525168 512 byte sectors: 255H 63S/T 121601C) >>>> da13 at mpt0 bus 0 scbus0 target 5 lun 0 >>>> da13: Fixed Direct Access SCSI-5 device >>>> da13: 300.000MB/s transfers >>>> da13: Command Queueing enabled >>>> da13: 953869MB (1953525168 512 byte sectors: 255H 63S/T 121601C) >>>> da14 at mpt0 bus 0 scbus0 target 6 lun 0 >>>> da14: Fixed Direct Access SCSI-5 device >>>> da14: 300.000MB/s transfers >>>> da14: Command Queueing enabled >>>> da14: 953869MB (1953525168 512 byte sectors: 255H 63S/T 121601C) >>>> da0 at mpt1 bus 0 scbus1 target 0 lun 0 >>>> da0: Fixed Direct Access SCSI-5 device >>>> da0: 300.000MB/s transfers >>>> da0: Command Queueing enabled >>>> da0: 1907729MB (3907029168 512 byte sectors: 255H 63S/T 243201C) >>>> da1 at mpt1 bus 0 scbus1 target 1 lun 0 >>>> da1: Fixed Direct Access SCSI-5 device >>>> da1: 300.000MB/s transfers >>>> da1: Command Queueing enabled >>>> da1: 1907729MB (3907029168 512 byte sectors: 255H 63S/T 243201C) >>>> da2 at mpt1 bus 0 scbus1 target 2 lun 0 >>>> da2: Fixed Direct Access SCSI-5 device >>>> da2: 300.000MB/s transfers >>>> da2: Command Queueing enabled >>>> da2: 1907729MB (3907029168 512 byte sectors: 255H 63S/T 243201C) >>>> da3 at mpt1 bus 0 scbus1 target 3 lun 0 >>>> da3: Fixed Direct Access SCSI-5 device >>>> da3: 300.000MB/s transfers >>>> da3: Command Queueing enabled >>>> da3: 1907729MB (3907029168 512 byte sectors: 255H 63S/T 243201C) >>>> da4 at mpt1 bus 0 scbus1 target 4 lun 0 >>>> da4: Fixed Direct Access SCSI-5 device >>>> da4: 300.000MB/s transfers >>>> da4: Command Queueing enabled >>>> da4: 1907729MB (3907029168 512 byte sectors: 255H 63S/T 243201C) >>>> da5 at mpt1 bus 0 scbus1 target 5 lun 0 >>>> da5: Fixed Direct Access SCSI-5 device >>>> da5: 300.000MB/s transfers >>>> da5: Command Queueing enabled >>>> da5: 953869MB (1953525168 512 byte sectors: 255H 63S/T 121601C) >>>> da6 at mpt1 bus 0 scbus1 target 6 lun 0 >>>> da6: Fixed Direct Access SCSI-5 device >>>> da6: 300.000MB/s transfers >>>> da6: Command Queueing enabled >>>> da6: 953869MB (1953525168 512 byte sectors: 255H 63S/T 121601C) >>>> da7 at mpt1 bus 0 scbus1 target 7 lun 0 >>>> da7: Fixed Direct Access SCSI-5 device >>>> da7: 300.000MB/s transfers >>>> da7: Command Queueing enabled >>>> da7: 953869MB (1953525168 512 byte sectors: 255H 63S/T 121601C) >>>> SMP: AP CPU #1 Launched! >>>> uhub5: 10 ports with 10 removable, self powered >>>> GEOM: da7: geometry does not match label (16h,63s != 255h,63s). >>>> Trying to mount root from ufs:/dev/ad16s1a >>>> WARNING: / was not properly dismounted >>>> ZFS filesystem version 5 >>>> ZFS storage pool version 28 >>>> WARNING: /tmp was not properly dismounted >>>> WARNING: /usr was not properly dismounted >>>> WARNING: /var was not properly dismounted >>>> 0 >>>> mpt1: request 0xffffff80002c57f0:2369 timed out for ccb >>>> 0xffffff00063bb000 >>>> (req->ccb 0xffffff00063bb000) >>>> mpt1: attempting to abort req 0xffffff80002c57f0:2369 function 0 >>>> mpt1: mpt_wait_req(1) timed out >>>> mpt1: mpt_recover_commands: abort timed-out. Resetting controller >>>> mpt1: mpt_cam_event: 0x80 >>>> mpt1: mpt_cam_event: 0x80 >>>> mpt1: completing timedout/aborted req 0xffffff80002c57f0:2369 >>>> mpt1: mpt_cam_event: 0x16 >>>> mpt1: mpt_cam_event: 0x12 >>>> mpt1: mpt_cam_event: 0x12 >>>> mpt1: mpt_cam_event: 0x12 >>>> mpt1: mpt_cam_event: 0x12 >>>> mpt1: mpt_cam_event: 0x12 >>>> mpt1: mpt_cam_event: 0x12 >>>> mpt1: mpt_cam_event: 0x12 >>>> mpt1: mpt_cam_event: 0x12 >>>> mpt1: mpt_cam_event: 0x16 >>>> mpt1: request 0xffffff80002c5c70:2375 timed out for ccb >>>> 0xffffff00063bb000 >>>> (req->ccb 0xffffff00063bb000) >>>> mpt1: attempting to abort req 0xffffff80002c5c70:2375 function 0 >>>> mpt1: completing timedout/aborted req 0xffffff80002c5c70:2375 >>>> mpt1: >>>> abort of req 0xffffff80002c5c70:0 completed >>>> mpt1: mpt_cam_event: 0x16 >>>> mpt1: mpt_cam_event: 0x16 >>>> mpt1: request 0xffffff80002c5fd0:2379 timed out for ccb >>>> 0xffffff00063bb000 >>>> (req->ccb 0xffffff00063bb000) >>>> mpt1: attempting to abort req 0xffffff80002c5fd0:2379 function 0 >>>> mpt1: completing timedout/aborted req 0xffffff80002c5fd0:2379 >>>> mpt1: >>>> abort of req 0xffffff80002c5fd0:0 completed >>>> mpt1: mpt_cam_event: 0x16 >>>> mpt1: mpt_cam_event: 0x16 >>>> mpt1: request 0xffffff80002c6210:2383 timed out for ccb >>>> 0xffffff00063bb000 >>>> (req->ccb 0xffffff00063bb000) >>>> mpt1: attempting to abort req 0xffffff80002c6210:2383 function 0 >>>> mpt1: completing timedout/aborted req 0xffffff80002c6210:2383 >>>> mpt1: >>>> abort of req 0xffffff80002c6210:0 completed >>>> mpt1: mpt_cam_event: 0x16 >>>> mpt1: mpt_cam_event: 0x16 >>>> mpt1: request 0xffffff80002c6180:2387 timed out for ccb >>>> 0xffffff00063bb000 >>>> (req->ccb 0xffffff00063bb000) >>>> mpt1: attempting to abort req 0xffffff80002c6180:2387 function 0 >>>> mpt1: completing timedout/aborted req 0xffffff80002c6180:2387 >>>> mpt1: >>>> abort of req 0xffffff80002c6180:0 completed >>>> mpt1: mpt_cam_event: 0x16 >>>> mpt1: mpt_cam_event: 0x16 >>>> mpt1: request 0xffffff80002c62a0:2391 timed out for ccb >>>> 0xffffff00063bb000 >>>> (req->ccb 0xffffff00063bb000) >>>> mpt1: attempting to abort req 0xffffff80002c62a0:2391 function 0 >>>> mpt1: completing timedout/aborted req 0xffffff80002c62a0:2391 >>>> mpt1: >>>> abort of req 0xffffff80002c62a0:0 completed >>>> mpt1: mpt_cam_event: 0x16 >>>> mpt1: mpt_cam_event: 0x16 >>>> mpt1: request 0xffffff80002c6720:2395 timed out for ccb >>>> 0xffffff00063bb000 >>>> (req->ccb 0xffffff00063bb000) >>>> mpt1: attempting to abort req 0xffffff80002c6720:2395 function 0 >>>> mpt1: completing timedout/aborted req 0xffffff80002c6720:2395 >>>> mpt1: >>>> abort of req 0xffffff80002c6720:0 completed >>>> mpt1: mpt_cam_event: 0x16 >>>> mpt1: mpt_cam_event: 0x16 >>>> mpt1: request 0xffffff80002c67b0:2399 timed out for ccb >>>> 0xffffff00063bb000 >>>> (req->ccb 0xffffff00063bb000) >>>> mpt1: attempting to abort req 0xffffff80002c67b0:2399 function 0 >>>> mpt1: completing timedout/aborted req 0xffffff80002c67b0:2399 >>>> mpt1: >>>> abort of req 0xffffff80002c67b0:0 completed >>>> mpt1: mpt_cam_event: 0x16 >>>> mpt1: mpt_cam_event: 0x16 >>>> mpt0: request 0xffffff80002a69e0:2082 timed out for ccb >>>> 0xffffff0006389800 >>>> (req->ccb 0xffffff0006389800) >>>> mpt0: attempting to abort req 0xffffff80002a69e0:2082 function 0 >>>> mpt0: completing timedout/aborted req 0xffffff80002a69e0:2082 >>>> mpt0: abort of req 0xffffff80002a69e0:0 completed >>>> mpt0: mpt_cam_event: 0x16 >>>> mpt0: mpt_cam_event: 0x16 >>>> mpt0: request 0xffffff80002a6c20:2086 timed out for ccb >>>> 0xffffff0006389800 >>>> (req->ccb 0xffffff0006389800) >>>> mpt0: attempting to abort req 0xffffff80002a6c20:2086 function 0 >>>> mpt0: completing timedout/aborted req 0xffffff80002a6c20:2086 >>>> mpt0: abort of req 0xffffff80002a6c20:0 completed >>>> mpt0: mpt_cam_event: 0x16 >>>> mpt0: mpt_cam_event: 0x16 >>>> mpt0: request 0xffffff80002a6cb0:2090 timed out for ccb >>>> 0xffffff0006389800 >>>> (req->ccb 0xffffff0006389800) >>>> mpt0: attempting to abort req 0xffffff80002a6cb0:2090 function 0 >>>> mpt0: completing timedout/aborted req 0xffffff80002a6cb0:2090 >>>> mpt0: abort of req 0xffffff80002a6cb0:0 completed >>>> mpt0: mpt_cam_event: 0x16 >>>> mpt0: mpt_cam_event: 0x16 >>>> mpt0: request 0xffffff80002a6b90:2094 timed out for ccb >>>> 0xffffff0006389800 >>>> (req->ccb 0xffffff0006389800) >>>> mpt0: attempting to abort req 0xffffff80002a6b90:2094 function 0 >>>> mpt0: completing timedout/aborted req 0xffffff80002a6b90:2094 >>>> mpt0: abort of req 0xffffff80002a6b90:0 completed >>>> mpt0: mpt_cam_event: 0x16 >>>> mpt0: mpt_cam_event: 0x16 >>>> tun0: link state changed to UP >>>> (da8:mpt0:0:0:0): READ(10). CDB: 28 0 3e e2 6f 56 0 0 1 0 >>>> (da8:mpt0:0:0:0): CAM status: SCSI Status Error >>>> (da8:mpt0:0:0:0): SCSI status: Check Condition >>>> (da8:mpt0:0:0:0): SCSI sense: UNIT ATTENTION asc:29,0 (Power on, reset, >>>> or >>>> bus device reset occurred) >>>> (da11:mpt0:0:3:0): READ(10). CDB: 28 0 1a b6 92 0 0 0 80 0 >>>> (da11:mpt0:0:3:0): CAM status: SCSI Status Error >>>> (da11:mpt0:0:3:0): SCSI status: Check Condition >>>> (da11:mpt0:0:3:0): SCSI sense: UNIT ATTENTION asc:29,0 (Power on, reset, >>>> or >>>> bus device reset occurred) >>>> (da2:mpt1:0:2:0): READ(10). CDB: 28 0 76 7b de 0 0 0 80 0 >>>> (da2:mpt1:0:2:0): CAM status: SCSI Status Error >>>> (da2:mpt1:0:2:0): SCSI status: Check Condition >>>> (da2:mpt1:0:2:0): SCSI sense: UNIT ATTENTION asc:29,0 (Power on, reset, >>>> or >>>> bus device reset occurred) >>>> (da10:mpt0:0:2:0): READ(10). CDB: 28 0 1a ff 67 80 0 0 80 0 >>>> (da10:mpt0:0:2:0): CAM status: SCSI Status Error >>>> (da10:mpt0:0:2:0): SCSI status: Check Condition >>>> (da10:mpt0:0:2:0): SCSI sense: UNIT ATTENTION asc:29,0 (Power on, reset, >>>> or >>>> bus device reset occurred) >>>> (da5:mpt1:0:5:0): READ(10). CDB: 28 0 1a ff 67 80 0 0 80 0 >>>> (da5:mpt1:0:5:0): CAM status: SCSI Status Error >>>> (da5:mpt1:0:5:0): SCSI status: Check Condition >>>> (da5:mpt1:0:5:0): SCSI sense: UNIT ATTENTION asc:29,0 (Power on, reset, >>>> or >>>> bus device reset occurred) >>>> (da7:mpt1:0:7:0): READ(10). CDB: 28 0 40 d7 da 80 0 0 80 0 >>>> (da7:mpt1:0:7:0): CAM status: SCSI Status Error >>>> (da7:mpt1:0:7:0): SCSI status: Check Condition >>>> (da7:mpt1:0:7:0): SCSI sense: UNIT ATTENTION asc:29,0 (Power on, reset, >>>> or >>>> bus device reset occurred) >>>> (da6:mpt1:0:6:0): READ(10). CDB: 28 0 40 d7 da 80 0 0 80 0 >>>> (da6:mpt1:0:6:0): CAM status: SCSI Status Error >>>> (da6:mpt1:0:6:0): SCSI status: Check Condition >>>> (da6:mpt1:0:6:0): SCSI sense: UNIT ATTENTION asc:29,0 (Power on, reset, >>>> or >>>> bus device reset occurred) >>>> (da0:mpt1:0:0:0): READ(10). CDB: 28 0 76 91 87 e3 0 0 1 0 >>>> (da0:mpt1:0:0:0): CAM status: SCSI Status Error >>>> (da0:mpt1:0:0:0): SCSI status: Check Condition >>>> (da0:mpt1:0:0:0): SCSI sense: UNIT ATTENTION asc:29,0 (Power on, reset, >>>> or >>>> bus device reset occurred) >>>> (da3:mpt1:0:3:0): READ(10). CDB: 28 0 76 69 1 1c 0 0 1 0 >>>> (da3:mpt1:0:3:0): CAM status: SCSI Status Error >>>> (da3:mpt1:0:3:0): SCSI status: Check Condition >>>> (da3:mpt1:0:3:0): SCSI sense: UNIT ATTENTION asc:29,0 (Power on, reset, >>>> or >>>> bus device reset occurred) >>>> (da1:mpt1:0:1:0): READ(10). CDB: 28 0 76 69 1 1c 0 0 1 0 >>>> (da1:mpt1:0:1:0): CAM status: SCSI Status Error >>>> (da1:mpt1:0:1:0): SCSI status: Check Condition >>>> (da1:mpt1:0:1:0): SCSI sense: UNIT ATTENTION asc:29,0 (Power on, reset, >>>> or >>>> bus device reset occurred) >>>> (da9:mpt0:0:1:0): READ(10). CDB: 28 0 1a b3 d7 0 0 0 80 0 >>>> (da9:mpt0:0:1:0): CAM status: SCSI Status Error >>>> (da9:mpt0:0:1:0): SCSI status: Check Condition >>>> (da9:mpt0:0:1:0): SCSI sense: UNIT ATTENTION asc:29,0 (Power on, reset, >>>> or >>>> bus device reset occurred) >>>> (da4:mpt1:0:4:0): READ(10). CDB: 28 0 53 3c c6 0 0 0 80 0 >>>> (da4:mpt1:0:4:0): CAM status: SCSI Status Error >>>> (da4:mpt1:0:4:0): SCSI status: Check Condition >>>> (da4:mpt1:0:4:0): SCSI sense: UNIT ATTENTION asc:29,0 (Power on, reset, >>>> or >>>> bus device reset occurred) >>>> >>>> >>>> >>>> > >>>> > -- >>>> > | Jeremy Chadwick jdc@parodius.com| >>>> > | Parodius Networking http://www.parodius.com/| >>>> > | UNIX Systems Administrator Mountain View, CA, US | >>>> > | Making life hard for others since 1977. PGP 4BD6C0CB | >>>> > >>>> > >>>> >>>> >>>> -- >>>> Joshua Boyd >>>> _______________________________________________ >>>> freebsd-stable@freebsd.org mailing list >>>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >>>> To unsubscribe, send any mail to " >>>> freebsd-stable-unsubscribe@freebsd.org" >>>> >>> >>> >> >> >> -- >> Joshua Boyd >> > > > > -- > Joshua Boyd > > > E-mail: boydjd@jbip.net > http://www.jbip.net > From owner-freebsd-stable@FreeBSD.ORG Wed Jun 22 09:03:56 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2C2A41065705 for ; Wed, 22 Jun 2011 09:03:56 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 866888FC08 for ; Wed, 22 Jun 2011 09:03:55 +0000 (UTC) Received: by fxm11 with SMTP id 11so718329fxm.13 for ; Wed, 22 Jun 2011 02:03:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=nG0JdpL+ad7KuN2c50pBu8vpY+pdnGgeUyOl/AAiPPc=; b=KptT3WXOg6iL26L+xy8+sVozZPFHbJNbLzjX0mOzwmOgwAJQVCCKeoOU6ULybQXxsS bnbEpjCpGO4cuXOkUuKl9CSdB6RRw5XhGrBmH0QbXy4iGznpsDiYBz94hWXFRqmDvava qaQo3Kdjn2VZLTwQoAgWwqTpgN12W/CJjsov4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=o7wsiRC3LvJ8opSJ6BMFz1HL+QO/lHXuhpj63ci8RIe2TVkw3bS+lbISBM35ofcCjM Yo7+q3seIJ0zXmSHvJh0hyRFetX5mwJq/QB+XYIu3I/gGe64K8vLHxjqa6nVzfaZYhzl krpihcZCAsaBK/WkVukIM2miFvNBBo1t8+p3Q= Received: by 10.223.7.150 with SMTP id d22mr499322fad.17.1308733434425; Wed, 22 Jun 2011 02:03:54 -0700 (PDT) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id e16sm186838fak.17.2011.06.22.02.03.52 (version=SSLv3 cipher=OTHER); Wed, 22 Jun 2011 02:03:53 -0700 (PDT) Sender: Alexander Motin Message-ID: <4E01AFBA.809@FreeBSD.org> Date: Wed, 22 Jun 2011 12:02:50 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Jeremy Chadwick References: <20110618005124.GA43568@icarus.home.lan> <20110621191626.GA99204@icarus.home.lan> In-Reply-To: <20110621191626.GA99204@icarus.home.lan> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org Subject: Re: MFC: graid(8) (RAID GEOM) support X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 09:03:56 -0000 Jeremy Chadwick wrote: > On Fri, Jun 17, 2011 at 05:51:24PM -0700, Jeremy Chadwick wrote: >> Sorry for the cross-post, but I thought both lists would want to know >> about this. >> >> Looks like mav@ just committed this ~17 hours ago: >> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/geom/raid/g_raid.c >> >> Those who have historically wanted to use Intel MatrixRAID (now called >> Intel RST (Rapid Storage Technology)), but haven't due to the severe >> issues/risks with ataraid(4), will probably be very interested in >> this commit. I know I am! >> >> I plan on stress-testing the Intel support on a 2-disk system with >> RAID-1 enabled, and will document my experiences, procedures, etc... >> >> Thanks, mav@ and imp@ ! >> >> I'll be sending another mail momentarily asking about USB memory stick >> image building, since to accomplish the above, I want to do a >> "bare-bones" install on our test system (e.g. enable Intel RAID, set up >> 2 disks in a RAID-1 mirror, boot a USB memory stick that contains this >> latest RELENG_8 build, and do sysinstall, etc.. the normal way). >> >> >> ===================================================================== >> MFC r219974, r220209, r220210, r220790: >> Add new RAID GEOM class, that is going to replace ataraid(4) in supporting >> various BIOS-based software RAIDs. Unlike ataraid(4) this implementation >> does not depend on legacy ata(4) subsystem and can be used with any disk >> drivers, including new CAM-based ones (ahci(4), siis(4), mvs(4), ata(4) >> with `options ATA_CAM`). To make code more readable and extensible, this >> implementation follows modular design, including core part and two sets >> of modules, implementing support for different metadata formats and RAID >> levels. >> >> Support for such popular metadata formats is now implemented: >> Intel, JMicron, NVIDIA, Promise (also used by AMD/ATI) and SiliconImage. >> >> Such RAID levels are now supported: >> RAID0, RAID1, RAID1E, RAID10, SINGLE, CONCAT. >> >> For all of these RAID levels and metadata formats this class supports >> full cycle of volume operations: reading, writing, creation, deletion, >> disk removal and insertion, rebuilding, dirty shutdown detection >> and resynchronization, bad sector recovery, faulty disks tracking, >> hot-spare disks. For Intel and Promise formats there is support multiple >> volumes per disk set. >> >> Look graid(8) manual page for additional details. >> >> Co-authored by: imp >> Sponsored by: Cisco Systems, Inc. and iXsystems, Inc. >> ===================================================================== > > By the way, it doesn't look like the graid(8) man page is being brought > in to the base system on either of the two RELENG_8 systems I've rebuilt > in the past few days. > > I'm thinking /usr/src/sbin/geom/class/raid/graid.8 isn't being noticed > as a man page. > > /usr/src/sbin/geom/class/raid/Makefile doesn't have MAN8=graid.8 in it, > is that the problem? I've just rebuilt my test 8-STABLE system and it installed graid(8). -- Alexander Motin From owner-freebsd-stable@FreeBSD.ORG Wed Jun 22 10:37:06 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5EB461065674 for ; Wed, 22 Jun 2011 10:37:06 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [76.96.62.16]) by mx1.freebsd.org (Postfix) with ESMTP id 0AAF58FC1D for ; Wed, 22 Jun 2011 10:37:05 +0000 (UTC) Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by qmta01.westchester.pa.mail.comcast.net with comcast id yyam1g0020EZKEL51yd6qF; Wed, 22 Jun 2011 10:37:06 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta01.westchester.pa.mail.comcast.net with comcast id yyd41g00m1t3BNj3Myd5yL; Wed, 22 Jun 2011 10:37:06 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 42587102C36; Wed, 22 Jun 2011 03:37:03 -0700 (PDT) Date: Wed, 22 Jun 2011 03:37:03 -0700 From: Jeremy Chadwick To: Alexander Motin Message-ID: <20110622103703.GA14901@icarus.home.lan> References: <20110618005124.GA43568@icarus.home.lan> <20110621191626.GA99204@icarus.home.lan> <4E01AFBA.809@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E01AFBA.809@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org Subject: Re: MFC: graid(8) (RAID GEOM) support X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 10:37:06 -0000 On Wed, Jun 22, 2011 at 12:02:50PM +0300, Alexander Motin wrote: > Jeremy Chadwick wrote: > > On Fri, Jun 17, 2011 at 05:51:24PM -0700, Jeremy Chadwick wrote: > >> Sorry for the cross-post, but I thought both lists would want to know > >> about this. > >> > >> Looks like mav@ just committed this ~17 hours ago: > >> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/geom/raid/g_raid.c > >> > >> Those who have historically wanted to use Intel MatrixRAID (now called > >> Intel RST (Rapid Storage Technology)), but haven't due to the severe > >> issues/risks with ataraid(4), will probably be very interested in > >> this commit. I know I am! > >> > >> I plan on stress-testing the Intel support on a 2-disk system with > >> RAID-1 enabled, and will document my experiences, procedures, etc... > >> > >> Thanks, mav@ and imp@ ! > >> > >> I'll be sending another mail momentarily asking about USB memory stick > >> image building, since to accomplish the above, I want to do a > >> "bare-bones" install on our test system (e.g. enable Intel RAID, set up > >> 2 disks in a RAID-1 mirror, boot a USB memory stick that contains this > >> latest RELENG_8 build, and do sysinstall, etc.. the normal way). > >> > >> > >> ===================================================================== > >> MFC r219974, r220209, r220210, r220790: > >> Add new RAID GEOM class, that is going to replace ataraid(4) in supporting > >> various BIOS-based software RAIDs. Unlike ataraid(4) this implementation > >> does not depend on legacy ata(4) subsystem and can be used with any disk > >> drivers, including new CAM-based ones (ahci(4), siis(4), mvs(4), ata(4) > >> with `options ATA_CAM`). To make code more readable and extensible, this > >> implementation follows modular design, including core part and two sets > >> of modules, implementing support for different metadata formats and RAID > >> levels. > >> > >> Support for such popular metadata formats is now implemented: > >> Intel, JMicron, NVIDIA, Promise (also used by AMD/ATI) and SiliconImage. > >> > >> Such RAID levels are now supported: > >> RAID0, RAID1, RAID1E, RAID10, SINGLE, CONCAT. > >> > >> For all of these RAID levels and metadata formats this class supports > >> full cycle of volume operations: reading, writing, creation, deletion, > >> disk removal and insertion, rebuilding, dirty shutdown detection > >> and resynchronization, bad sector recovery, faulty disks tracking, > >> hot-spare disks. For Intel and Promise formats there is support multiple > >> volumes per disk set. > >> > >> Look graid(8) manual page for additional details. > >> > >> Co-authored by: imp > >> Sponsored by: Cisco Systems, Inc. and iXsystems, Inc. > >> ===================================================================== > > > > By the way, it doesn't look like the graid(8) man page is being brought > > in to the base system on either of the two RELENG_8 systems I've rebuilt > > in the past few days. > > > > I'm thinking /usr/src/sbin/geom/class/raid/graid.8 isn't being noticed > > as a man page. > > > > /usr/src/sbin/geom/class/raid/Makefile doesn't have MAN8=graid.8 in it, > > is that the problem? > > I've just rebuilt my test 8-STABLE system and it installed graid(8). Hmm, there must be something I'm missing either in the base system or the kernel or both. Does this kernel module and/or bits and pieces not get built unless it's included strictly in the kernel? Below is one of the two systems, looking for both graid* and geom_raid*. There's the old geom_raid3 stuff there, and the source bits/pieces for the new graid(8), but nothing seems built (including kernel module) for the new graid(8). If you'd like I can rm -fr /usr/src/* ; rm -fr /var/db/sup/src-all and then re-download source from an official cvsup mirror (I've been using cvsup9.freebsd.org for both boxes). icarus# uname -a FreeBSD icarus.home.lan 8.2-STABLE FreeBSD 8.2-STABLE #0: Fri Jun 17 18:01:45 PDT 2011 root@icarus.home.lan:/usr/obj/usr/src/sys/X7SBA_RELENG_8_amd64 amd64 icarus# find /usr -name "graid*" -ls 3211128 8 -r--r--r-- 1 root wheel 2521 Jun 17 18:25 /usr/share/man/man8/graid3.8.gz 169318 16 -rw-r--r-- 1 root wheel 6390 Aug 3 2009 /usr/src/sbin/geom/class/raid3/graid3.8 169624 16 -rw-r--r-- 1 root wheel 8126 Jun 16 23:59 /usr/src/sbin/geom/class/raid/graid.8 921430 8 -rw-r--r-- 1 root wheel 2521 Jun 17 17:51 /usr/obj/usr/src/sbin/geom/class/raid3/graid3.8.gz 3369372 4 drwxr-xr-x 2 root wheel 512 May 3 03:58 /usr/ports/sysutils/graid5 icarus# icarus# find /boot -name "graid*" -ls icarus# icarus# find /usr -name "geom_raid*" -ls 169317 20 -rw-r--r-- 1 root wheel 9257 Jan 18 21:13 /usr/src/sbin/geom/class/raid3/geom_raid3.c 165265 8 -rw-r--r-- 1 root wheel 2992 Jun 16 23:59 /usr/src/sbin/geom/class/raid/geom_raid.c 259652 4 drwxr-xr-x 2 root wheel 512 Jun 6 06:28 /usr/src/sys/modules/geom/geom_raid3 285292 4 drwxr-xr-x 2 root wheel 512 Jun 17 17:17 /usr/src/sys/modules/geom/geom_raid 262798 4 drwxr-xr-x 2 root wheel 512 Jun 6 06:29 /usr/src/tools/regression/geom_raid3 921428 48 -rw-r--r-- 1 root wheel 22760 Jun 17 17:51 /usr/obj/usr/src/sbin/geom/class/raid3/geom_raid3.So 921431 64 -rwxr-xr-x 1 root wheel 32207 Jun 17 17:51 /usr/obj/usr/src/sbin/geom/class/raid3/geom_raid3.so 1014175 4 drwxr-xr-x 2 root wheel 512 Jun 17 18:00 /usr/obj/usr/src/sys/X7SBA_RELENG_8_amd64/modules/usr/src/sys/modules/geom/geom_raid3 1015257 736 -rw-r--r-- 1 root wheel 359456 Jun 17 18:00 /usr/obj/usr/src/sys/X7SBA_RELENG_8_amd64/modules/usr/src/sys/modules/geom/geom_raid3/geom_raid3.ko.debug 1015258 640 -rw-r--r-- 1 root wheel 304432 Jun 17 18:00 /usr/obj/usr/src/sys/X7SBA_RELENG_8_amd64/modules/usr/src/sys/modules/geom/geom_raid3/geom_raid3.ko.symbols 1015259 272 -rw-r--r-- 1 root wheel 137448 Jun 17 18:00 /usr/obj/usr/src/sys/X7SBA_RELENG_8_amd64/modules/usr/src/sys/modules/geom/geom_raid3/geom_raid3.ko icarus# icarus# find /boot -name "geom_raid*" -ls 94943 272 -r-xr-xr-x 1 root wheel 137448 Jun 17 18:24 /boot/kernel/geom_raid3.ko 94944 640 -r-xr-xr-x 1 root wheel 304432 Jun 17 18:24 /boot/kernel/geom_raid3.ko.symbols 71074 272 -r-xr-xr-x 1 root wheel 137448 Jun 6 05:35 /boot/kernel.old/geom_raid3.ko 71075 640 -r-xr-xr-x 1 root wheel 304432 Jun 6 05:35 /boot/kernel.old/geom_raid3.ko.symbols -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Wed Jun 22 11:34:08 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F2E12106566B; Wed, 22 Jun 2011 11:34:08 +0000 (UTC) (envelope-from hlh@restart.be) Received: from tignes.restart.be (tignes.restart.be [IPv6:2001:41d0:2:56bf:0:1::]) by mx1.freebsd.org (Postfix) with ESMTP id 3D1E98FC0C; Wed, 22 Jun 2011 11:34:08 +0000 (UTC) Received: from restart.be (avoriaz.tunnel.bel [IPv6:2001:41d0:2:56bf:1:ffff::]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "smtp.restart.be", Issuer "CA master" (verified OK)) by tignes.restart.be (Postfix) with ESMTPS id 47187147D4; Wed, 22 Jun 2011 13:34:07 +0200 (CEST) Received: from morzine.restart.bel (morzine.restart.be [IPv6:2001:41d0:2:56bf:1:2::]) (authenticated bits=0) by restart.be (8.14.5/8.14.5) with ESMTP id p5MBY61e051283; Wed, 22 Jun 2011 13:34:06 +0200 (CEST) (envelope-from hlh@restart.be) X-DKIM: Sendmail DKIM Filter v2.8.3 restart.be p5MBY61e051283 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=restart.be; s=avoriaz; t=1308742446; bh=Du3CcWvcXuBTGkVqvuW4s/o4FDVjSj15F9/vKpzuI4I=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=xXBBLWY93d4/Rn3m412ygwQ0kpcIH15/5onmI3nJE5mRXYrkBtLHHuihS2dfUBmvp OwgSnVjVPz9uMTNbW3yXQ== X-DomainKeys: Sendmail DomainKeys Filter v1.0.2 restart.be p5MBY61e051283 DomainKey-Signature: a=rsa-sha1; s=avoriaz; d=restart.be; c=nofws; q=dns; h=message-id:date:from:organization:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type:content-transfer-encoding; b=h6g8eLOnsazVWCnNgMh+kazbyIWUSSSTQ7ywKYV3Z4d4RJCF39gw6mIbw2CyoXPlV 5NZYk1nXcto/sza1WNWSg== Message-ID: <4E01D32D.5050801@restart.be> Date: Wed, 22 Jun 2011 13:34:05 +0200 From: Henri Hennebert Organization: RestartSoft User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.17) Gecko/20110616 Thunderbird/3.1.10 MIME-Version: 1.0 To: John Baldwin References: <201106211525.35938.jhb@freebsd.org> <4E00FB60.8080407@restart.be> <201106211727.26413.jhb@freebsd.org> In-Reply-To: <201106211727.26413.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: ZFS boot inside on the second partition inside a slice X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 11:34:09 -0000 On 06/21/2011 23:27, John Baldwin wrote: > On Tuesday, June 21, 2011 4:13:20 pm Henri Hennebert wrote: >> On 06/21/2011 21:25, John Baldwin wrote: >> and I get: >> >> Read error: 04 > > Hmm, that is the error for an invalid sector. Try this patch. It reshuffles > a few more things and adds code to dump the low 32-bits of the LBA on an > error: > > Index: zfsldr.S > =================================================================== > --- zfsldr.S (revision 223365) > +++ zfsldr.S (working copy) > @@ -16,7 +16,6 @@ > */ > > /* Memory Locations */ > - .set MEM_REL,0x700 # Relocation address > .set MEM_ARG,0x900 # Arguments > .set MEM_ORG,0x7c00 # Origin > .set MEM_BUF,0x8000 # Load area > @@ -91,26 +90,18 @@ main: cld # String ops inc > mov %cx,%ss # Set up > mov $start,%sp # stack > /* > - * Relocate ourself to MEM_REL. Since %cx == 0, the inc %ch sets > - * %cx == 0x100. > - */ > - mov %sp,%si # Source > - mov $MEM_REL,%di # Destination > - incb %ch # Word count > - rep # Copy > - movsw # code > -/* > * If we are on a hard drive, then load the MBR and look for the first > * FreeBSD slice. We use the fake partition entry below that points to > * the MBR when we call nread. The first pass looks for the first active > * FreeBSD slice. The second pass looks for the first non-active FreeBSD > * slice if the first one fails. > */ > - mov $part4,%si # Partition > + mov $part4,%si # Dummy partition > cmpb $0x80,%dl # Hard drive? > jb main.4 # No > - movb $0x1,%dh # Block count > - callw nread # Read MBR > + xor %eax,%eax # Read MBR > + movw $MEM_BUF,%bx # from first > + callw nread # sector > mov $0x1,%cx # Two passes > main.1: mov $MEM_BUF+PRT_OFF,%si # Partition table > movb $0x1,%dh # Partition > @@ -161,10 +152,16 @@ main.4: xor %dx,%dx # Partition:drive > * area and target area do not overlap. > */ > main.5: mov %dx,MEM_ARG # Save args > - movb $NSECT,%dh # Sector count > + mov $NSECT,%cx # Sector count > movl $1024,%eax # Offset to boot2 > - callw nread.1 # Read disk > -main.6: mov $MEM_BUF,%si # BTX (before reloc) > + mov $MEM_BUF,%bx # Destination buffer > +main.6: pushal # Save params > + callw nread # Read disk > + popal # Restore > + incl %eax # Update for > + add $SIZ_SEC,%bx # next sector > + loop main.6 # If not last, read another > + mov $MEM_BUF,%si # BTX (before reloc) > mov 0xa(%si),%bx # Get BTX length and set > mov $NSECT*SIZ_SEC-1,%di # Size of load area (less one) > mov %di,%si # End of load > @@ -214,29 +211,35 @@ seta20.3: sti # Enable interrupts > * packet on the stack and passes it to read. > * > * %eax - int - LBA to read in relative to partition start > + * %es:%bx - ptr - destination address > * %dl - byte - drive to read from > - * %dh - byte - num sectors to read > * %si - ptr - MBR partition entry > */ > -nread: xor %eax,%eax # Sector offset in partition > -nread.1: xor %ecx,%ecx # Get > +nread: xor %ecx,%ecx # Get > addl 0x8(%si),%eax # LBA > adc $0,%ecx > pushl %ecx # Starting absolute block > pushl %eax # block number > push %es # Address of > - push $MEM_BUF # transfer buffer > - xor %ax,%ax # Number of > - movb %dh,%al # blocks to > - push %ax # transfer > + push %bx # transfer buffer > + push $0x1 # Read 1 sector > push $0x10 # Size of packet > mov %sp,%bp # Packet pointer > callw read # Read from disk > lea 0x10(%bp),%sp # Clear stack > - jnc return # If success, return > - mov $msg_read,%si # Otherwise, set the error > - # message and fall through to > - # the error routine > + jc nread.1 # If error, fail > + ret # If success, return > +nread.1: mov %ah,%al # Format > + mov $read_err,%di # error > + call hex8 # code > + movl 0x4(%si),%eax # Format > + mov $lba,%di # LBA > + call hex32 > + mov $msg_lba,%si # Display > + call putstr # LBA > + mov $msg_read,%si # Set the error message and > + # fall through to the error > + # routine > /* > * Print out the error message pointed to by %ds:(%si) followed > * by a prompt, wait for a keypress, and then reboot the machine. > @@ -259,14 +262,6 @@ putstr: lodsb # Get char > jne putstr.0 # No > > /* > - * Overused return code. ereturn is used to return an error from the > - * read function. Since we assume putstr succeeds, we (ab)use the > - * same code when we return from putstr. > - */ > -ereturn: movb $0x1,%ah # Invalid > - stc # argument > -return: retw # To caller > -/* > * Reads sectors from the disk. If EDD is enabled, then check if it is > * installed and use it if it is. If it is not installed or not enabled, then > * fall back to using CHS. Since we use a LBA, if we are using CHS, we have to > @@ -294,14 +289,38 @@ read: cmpb $0x80,%dl # Hard drive? > retw # To caller > read.1: mov $msg_chs,%si > jmp error > -msg_chs: .asciz "CHS not supported" > > +/* > + * Convert EAX, AX, or AL to hex, saving the result to [EDI]. > + */ > +hex32: pushl %eax # Save > + shrl $0x10,%eax # Do upper > + call hex16 # 16 > + popl %eax # Restore > +hex16: call hex16.1 # Do upper 8 > +hex16.1: xchgb %ah,%al # Save/restore > +hex8: push %ax # Save > + shrb $0x4,%al # Do upper > + call hex8.1 # 4 > + pop %ax # Restore > +hex8.1: andb $0xf,%al # Get lower 4 > + cmpb $0xa,%al # Convert > + sbbb $0x69,%al # to hex > + das # digit > + orb $0x20,%al # To lower case > + stosb # Save char > + ret # (Recursive) > + > /* Messages */ > > -msg_read: .asciz "Read" > -msg_part: .asciz "Boot" > +msg_chs: .asciz "CHS not supported" > +msg_read: .ascii "Read error: " > +read_err: .asciz "XX" > +msg_lba: .ascii "LBA: " > +lba: .asciz "XXXXXXXX\r\n" > +msg_part: .asciz "Boot error" > > -prompt: .asciz " error\r\n" > +prompt: .asciz "\r\n" > > .org PRT_OFF,0x90 > > I get LBA: 00008200 Read error: 04 mfsbsd# gpart show => 63 312581745 ad0 MBR (149G) 63 167782797 1 ntfs (80G) 167782860 144798948 2 freebsd [active] (69G) => 0 144798948 ad0s2 BSD (69G) 0 144798948 1 freebsd-zfs (69G) From owner-freebsd-stable@FreeBSD.ORG Wed Jun 22 12:11:36 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6B3B61065679 for ; Wed, 22 Jun 2011 12:11:36 +0000 (UTC) (envelope-from lists@c0mplx.org) Received: from home.opsec.eu (home.opsec.eu [IPv6:2001:14f8:200::1]) by mx1.freebsd.org (Postfix) with ESMTP id 3278B8FC1C for ; Wed, 22 Jun 2011 12:11:36 +0000 (UTC) Received: from pi by home.opsec.eu with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1QZMHQ-000N4L-JM for freebsd-stable@freebsd.org; Wed, 22 Jun 2011 14:11:36 +0200 Date: Wed, 22 Jun 2011 14:11:36 +0200 From: Kurt Jaeger To: freebsd-stable@freebsd.org Message-ID: <20110622121136.GC16648@home.opsec.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Subject: commit PR 154469, ftp-proxy(8) bug ? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 12:11:36 -0000 Hi! Can someone have a look at http://www.freebsd.org/cgi/query-pr.cgi?pr=154469 and commit it ? So that it ends up in 8.3 8-} ? Thanks! -- pi@opsec.eu +49 171 3101372 9 years to go ! From owner-freebsd-stable@FreeBSD.ORG Wed Jun 22 13:57:14 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A5D76106564A for ; Wed, 22 Jun 2011 13:57:14 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 7BA308FC13 for ; Wed, 22 Jun 2011 13:57:14 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 6644946B06; Wed, 22 Jun 2011 09:57:10 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id E706D8A01F; Wed, 22 Jun 2011 09:57:09 -0400 (EDT) From: John Baldwin To: Henri Hennebert Date: Wed, 22 Jun 2011 09:57:09 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110617; KDE/4.5.5; amd64; ; ) References: <201106211727.26413.jhb@freebsd.org> <4E01D32D.5050801@restart.be> In-Reply-To: <4E01D32D.5050801@restart.be> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201106220957.09449.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Wed, 22 Jun 2011 09:57:10 -0400 (EDT) Cc: freebsd-stable@freebsd.org Subject: Re: ZFS boot inside on the second partition inside a slice X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 13:57:14 -0000 On Wednesday, June 22, 2011 7:34:05 am Henri Hennebert wrote: > I get > > LBA: 00008200 > Read error: 04 Odd. Oh, I fubar'd and read the wrong thing for the sector. Also, we should leave the EDD packet on the stack so it doesn't get trashed by calling hex8, etc. Please try this: Index: zfsldr.S =================================================================== --- zfsldr.S (revision 223365) +++ zfsldr.S (working copy) @@ -16,7 +16,6 @@ */ /* Memory Locations */ - .set MEM_REL,0x700 # Relocation address .set MEM_ARG,0x900 # Arguments .set MEM_ORG,0x7c00 # Origin .set MEM_BUF,0x8000 # Load area @@ -91,26 +90,18 @@ main: cld # String ops inc mov %cx,%ss # Set up mov $start,%sp # stack /* - * Relocate ourself to MEM_REL. Since %cx == 0, the inc %ch sets - * %cx == 0x100. - */ - mov %sp,%si # Source - mov $MEM_REL,%di # Destination - incb %ch # Word count - rep # Copy - movsw # code -/* * If we are on a hard drive, then load the MBR and look for the first * FreeBSD slice. We use the fake partition entry below that points to * the MBR when we call nread. The first pass looks for the first active * FreeBSD slice. The second pass looks for the first non-active FreeBSD * slice if the first one fails. */ - mov $part4,%si # Partition + mov $part4,%si # Dummy partition cmpb $0x80,%dl # Hard drive? jb main.4 # No - movb $0x1,%dh # Block count - callw nread # Read MBR + xor %eax,%eax # Read MBR + movw $MEM_BUF,%bx # from first + callw nread # sector mov $0x1,%cx # Two passes main.1: mov $MEM_BUF+PRT_OFF,%si # Partition table movb $0x1,%dh # Partition @@ -161,10 +152,16 @@ main.4: xor %dx,%dx # Partition:drive * area and target area do not overlap. */ main.5: mov %dx,MEM_ARG # Save args - movb $NSECT,%dh # Sector count + mov $NSECT,%cx # Sector count movl $1024,%eax # Offset to boot2 - callw nread.1 # Read disk -main.6: mov $MEM_BUF,%si # BTX (before reloc) + mov $MEM_BUF,%bx # Destination buffer +main.6: pushal # Save params + callw nread # Read disk + popal # Restore + incl %eax # Update for + add $SIZ_SEC,%bx # next sector + loop main.6 # If not last, read another + mov $MEM_BUF,%si # BTX (before reloc) mov 0xa(%si),%bx # Get BTX length and set mov $NSECT*SIZ_SEC-1,%di # Size of load area (less one) mov %di,%si # End of load @@ -214,29 +211,35 @@ seta20.3: sti # Enable interrupts * packet on the stack and passes it to read. * * %eax - int - LBA to read in relative to partition start + * %es:%bx - ptr - destination address * %dl - byte - drive to read from - * %dh - byte - num sectors to read * %si - ptr - MBR partition entry */ -nread: xor %eax,%eax # Sector offset in partition -nread.1: xor %ecx,%ecx # Get +nread: xor %ecx,%ecx # Get addl 0x8(%si),%eax # LBA adc $0,%ecx pushl %ecx # Starting absolute block pushl %eax # block number push %es # Address of - push $MEM_BUF # transfer buffer - xor %ax,%ax # Number of - movb %dh,%al # blocks to - push %ax # transfer + push %bx # transfer buffer + push $0x1 # Read 1 sector push $0x10 # Size of packet mov %sp,%bp # Packet pointer callw read # Read from disk + jc nread.1 # If error, fail lea 0x10(%bp),%sp # Clear stack - jnc return # If success, return - mov $msg_read,%si # Otherwise, set the error - # message and fall through to - # the error routine + ret # If success, return +nread.1: mov %ah,%al # Format + mov $read_err,%di # error + call hex8 # code + movl 0x8(%bp),%eax # Format + mov $lba,%di # LBA + call hex32 + mov $msg_lba,%si # Display + call putstr # LBA + mov $msg_read,%si # Set the error message and + # fall through to the error + # routine /* * Print out the error message pointed to by %ds:(%si) followed * by a prompt, wait for a keypress, and then reboot the machine. @@ -259,14 +262,6 @@ putstr: lodsb # Get char jne putstr.0 # No /* - * Overused return code. ereturn is used to return an error from the - * read function. Since we assume putstr succeeds, we (ab)use the - * same code when we return from putstr. - */ -ereturn: movb $0x1,%ah # Invalid - stc # argument -return: retw # To caller -/* * Reads sectors from the disk. If EDD is enabled, then check if it is * installed and use it if it is. If it is not installed or not enabled, then * fall back to using CHS. Since we use a LBA, if we are using CHS, we have to @@ -294,14 +289,38 @@ read: cmpb $0x80,%dl # Hard drive? retw # To caller read.1: mov $msg_chs,%si jmp error -msg_chs: .asciz "CHS not supported" +/* + * Convert EAX, AX, or AL to hex, saving the result to [EDI]. + */ +hex32: pushl %eax # Save + shrl $0x10,%eax # Do upper + call hex16 # 16 + popl %eax # Restore +hex16: call hex16.1 # Do upper 8 +hex16.1: xchgb %ah,%al # Save/restore +hex8: push %ax # Save + shrb $0x4,%al # Do upper + call hex8.1 # 4 + pop %ax # Restore +hex8.1: andb $0xf,%al # Get lower 4 + cmpb $0xa,%al # Convert + sbbb $0x69,%al # to hex + das # digit + orb $0x20,%al # To lower case + stosb # Save char + ret # (Recursive) + /* Messages */ -msg_read: .asciz "Read" -msg_part: .asciz "Boot" +msg_chs: .asciz "CHS not supported" +msg_read: .ascii "Read error: " +read_err: .asciz "XX" +msg_lba: .ascii "LBA: " +lba: .asciz "XXXXXXXX\r\n" +msg_part: .asciz "Boot error" -prompt: .asciz " error\r\n" +prompt: .asciz "\r\n" .org PRT_OFF,0x90 -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Wed Jun 22 14:23:24 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8B2A0106564A; Wed, 22 Jun 2011 14:23:24 +0000 (UTC) (envelope-from hlh@restart.be) Received: from tignes.restart.be (tignes.restart.be [IPv6:2001:41d0:2:56bf:0:1::]) by mx1.freebsd.org (Postfix) with ESMTP id 0E7568FC14; Wed, 22 Jun 2011 14:23:24 +0000 (UTC) Received: from restart.be (avoriaz.tunnel.bel [IPv6:2001:41d0:2:56bf:1:ffff::]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "smtp.restart.be", Issuer "CA master" (verified OK)) by tignes.restart.be (Postfix) with ESMTPS id 4FB5014B03; Wed, 22 Jun 2011 16:23:23 +0200 (CEST) Received: from morzine.restart.bel (morzine.restart.be [IPv6:2001:41d0:2:56bf:1:2::]) (authenticated bits=0) by restart.be (8.14.5/8.14.5) with ESMTP id p5MENMSs055195; Wed, 22 Jun 2011 16:23:22 +0200 (CEST) (envelope-from hlh@restart.be) X-DKIM: Sendmail DKIM Filter v2.8.3 restart.be p5MENMSs055195 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=restart.be; s=avoriaz; t=1308752602; bh=bwAreAmyBTKjz5ul5RzGGCoRpR1sLnh2U14WWKK5uJc=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=oIRDZT0tkc4xdTQSp4tGPpHp+JTXiwkx1RiCrhBXB8QJC2I3hG4AjD1Zu2htx1HBZ 48YpeKu+MhAMvCnJ6oVdg== X-DomainKeys: Sendmail DomainKeys Filter v1.0.2 restart.be p5MENMSs055195 DomainKey-Signature: a=rsa-sha1; s=avoriaz; d=restart.be; c=nofws; q=dns; h=message-id:date:from:organization:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type:content-transfer-encoding; b=HCFSCAZ0jqRv9JSOwQTracueuWg7cW1TFW3JqkPplk/tr0/zUEthz9jint1OJJ1eQ jAUt2S7lJCx5+geRQrpbQ== Message-ID: <4E01FADA.2070104@restart.be> Date: Wed, 22 Jun 2011 16:23:22 +0200 From: Henri Hennebert Organization: RestartSoft User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.17) Gecko/20110616 Thunderbird/3.1.10 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <201106211727.26413.jhb@freebsd.org> <4E01D32D.5050801@restart.be> <201106220957.09449.jhb@freebsd.org> <4E01FA03.9070805@restart.be> In-Reply-To: <4E01FA03.9070805@restart.be> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Cc: jhb@freebsd.org Subject: Re: ZFS boot inside on the second partition inside a slice X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 14:23:24 -0000 On 06/22/2011 16:19, Henri Hennebert wrote: > On 06/22/2011 15:57, John Baldwin wrote: >> On Wednesday, June 22, 2011 7:34:05 am Henri Hennebert wrote: >>> I get >>> >>> LBA: 00008200 >>> Read error: 04 >> >> Odd. Oh, I fubar'd and read the wrong thing for the sector. Also, we >> should leave the EDD packet on the stack so it doesn't get trashed by >> calling hex8, etc. Please try this: >> >> Index: zfsldr.S >> =================================================================== >> --- zfsldr.S (revision 223365) >> +++ zfsldr.S (working copy) >> @@ -16,7 +16,6 @@ >> */ >> >> /* Memory Locations */ >> - .set MEM_REL,0x700 # Relocation address >> .set MEM_ARG,0x900 # Arguments >> .set MEM_ORG,0x7c00 # Origin >> .set MEM_BUF,0x8000 # Load area >> @@ -91,26 +90,18 @@ main: cld # String ops inc >> mov %cx,%ss # Set up >> mov $start,%sp # stack >> /* >> - * Relocate ourself to MEM_REL. Since %cx == 0, the inc %ch sets >> - * %cx == 0x100. >> - */ >> - mov %sp,%si # Source >> - mov $MEM_REL,%di # Destination >> - incb %ch # Word count >> - rep # Copy >> - movsw # code >> -/* >> * If we are on a hard drive, then load the MBR and look for the first >> * FreeBSD slice. We use the fake partition entry below that points to >> * the MBR when we call nread. The first pass looks for the first active >> * FreeBSD slice. The second pass looks for the first non-active FreeBSD >> * slice if the first one fails. >> */ >> - mov $part4,%si # Partition >> + mov $part4,%si # Dummy partition >> cmpb $0x80,%dl # Hard drive? >> jb main.4 # No >> - movb $0x1,%dh # Block count >> - callw nread # Read MBR >> + xor %eax,%eax # Read MBR >> + movw $MEM_BUF,%bx # from first >> + callw nread # sector >> mov $0x1,%cx # Two passes >> main.1: mov $MEM_BUF+PRT_OFF,%si # Partition table >> movb $0x1,%dh # Partition >> @@ -161,10 +152,16 @@ main.4: xor %dx,%dx # Partition:drive >> * area and target area do not overlap. >> */ >> main.5: mov %dx,MEM_ARG # Save args >> - movb $NSECT,%dh # Sector count >> + mov $NSECT,%cx # Sector count >> movl $1024,%eax # Offset to boot2 >> - callw nread.1 # Read disk >> -main.6: mov $MEM_BUF,%si # BTX (before reloc) >> + mov $MEM_BUF,%bx # Destination buffer >> +main.6: pushal # Save params >> + callw nread # Read disk >> + popal # Restore >> + incl %eax # Update for >> + add $SIZ_SEC,%bx # next sector >> + loop main.6 # If not last, read another >> + mov $MEM_BUF,%si # BTX (before reloc) >> mov 0xa(%si),%bx # Get BTX length and set >> mov $NSECT*SIZ_SEC-1,%di # Size of load area (less one) >> mov %di,%si # End of load >> @@ -214,29 +211,35 @@ seta20.3: sti # Enable interrupts >> * packet on the stack and passes it to read. >> * >> * %eax - int - LBA to read in relative to partition start >> + * %es:%bx - ptr - destination address >> * %dl - byte - drive to read from >> - * %dh - byte - num sectors to read >> * %si - ptr - MBR partition entry >> */ >> -nread: xor %eax,%eax # Sector offset in partition >> -nread.1: xor %ecx,%ecx # Get >> +nread: xor %ecx,%ecx # Get >> addl 0x8(%si),%eax # LBA >> adc $0,%ecx >> pushl %ecx # Starting absolute block >> pushl %eax # block number >> push %es # Address of >> - push $MEM_BUF # transfer buffer >> - xor %ax,%ax # Number of >> - movb %dh,%al # blocks to >> - push %ax # transfer >> + push %bx # transfer buffer >> + push $0x1 # Read 1 sector >> push $0x10 # Size of packet >> mov %sp,%bp # Packet pointer >> callw read # Read from disk >> + jc nread.1 # If error, fail >> lea 0x10(%bp),%sp # Clear stack >> - jnc return # If success, return >> - mov $msg_read,%si # Otherwise, set the error >> - # message and fall through to >> - # the error routine >> + ret # If success, return >> +nread.1: mov %ah,%al # Format >> + mov $read_err,%di # error >> + call hex8 # code >> + movl 0x8(%bp),%eax # Format >> + mov $lba,%di # LBA >> + call hex32 >> + mov $msg_lba,%si # Display >> + call putstr # LBA >> + mov $msg_read,%si # Set the error message and >> + # fall through to the error >> + # routine >> /* >> * Print out the error message pointed to by %ds:(%si) followed >> * by a prompt, wait for a keypress, and then reboot the machine. >> @@ -259,14 +262,6 @@ putstr: lodsb # Get char >> jne putstr.0 # No >> >> /* >> - * Overused return code. ereturn is used to return an error from the >> - * read function. Since we assume putstr succeeds, we (ab)use the >> - * same code when we return from putstr. >> - */ >> -ereturn: movb $0x1,%ah # Invalid >> - stc # argument >> -return: retw # To caller >> -/* >> * Reads sectors from the disk. If EDD is enabled, then check if it is >> * installed and use it if it is. If it is not installed or not >> enabled, then >> * fall back to using CHS. Since we use a LBA, if we are using CHS, we >> have to >> @@ -294,14 +289,38 @@ read: cmpb $0x80,%dl # Hard drive? >> retw # To caller >> read.1: mov $msg_chs,%si >> jmp error >> -msg_chs: .asciz "CHS not supported" >> >> +/* >> + * Convert EAX, AX, or AL to hex, saving the result to [EDI]. >> + */ >> +hex32: pushl %eax # Save >> + shrl $0x10,%eax # Do upper >> + call hex16 # 16 >> + popl %eax # Restore >> +hex16: call hex16.1 # Do upper 8 >> +hex16.1: xchgb %ah,%al # Save/restore >> +hex8: push %ax # Save >> + shrb $0x4,%al # Do upper >> + call hex8.1 # 4 >> + pop %ax # Restore >> +hex8.1: andb $0xf,%al # Get lower 4 >> + cmpb $0xa,%al # Convert >> + sbbb $0x69,%al # to hex >> + das # digit >> + orb $0x20,%al # To lower case >> + stosb # Save char >> + ret # (Recursive) >> + >> /* Messages */ >> >> -msg_read: .asciz "Read" >> -msg_part: .asciz "Boot" >> +msg_chs: .asciz "CHS not supported" >> +msg_read: .ascii "Read error: " >> +read_err: .asciz "XX" >> +msg_lba: .ascii "LBA: " >> +lba: .asciz "XXXXXXXX\r\n" >> +msg_part: .asciz "Boot error" >> >> -prompt: .asciz " error\r\n" >> +prompt: .asciz "\r\n" >> >> .org PRT_OFF,0x90 >> >> >> > This time: > > LBA: 3c802308 > Read error: 04 > > This morning I was reading the code (I'm in Belgium) and find that the > previous LBA output was DAP+4 and so was the addr of the buffer. 0x8200 > = $MEM_BUF+512, and so we must be in the second read. > OK I think I see, the first read mangle the partition table previously read at $MEM_BUF and so the next one is wrong. > Henri > > From owner-freebsd-stable@FreeBSD.ORG Wed Jun 22 14:36:10 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1C512106566C for ; Wed, 22 Jun 2011 14:36:10 +0000 (UTC) (envelope-from hlh@restart.be) Received: from tignes.restart.be (tignes.restart.be [IPv6:2001:41d0:2:56bf:0:1::]) by mx1.freebsd.org (Postfix) with ESMTP id A3A468FC1D for ; Wed, 22 Jun 2011 14:36:09 +0000 (UTC) Received: from restart.be (avoriaz.tunnel.bel [IPv6:2001:41d0:2:56bf:1:ffff::]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "smtp.restart.be", Issuer "CA master" (verified OK)) by tignes.restart.be (Postfix) with ESMTPS id 19BF914AF0 for ; Wed, 22 Jun 2011 16:19:49 +0200 (CEST) Received: from morzine.restart.bel (morzine.restart.be [IPv6:2001:41d0:2:56bf:1:2::]) (authenticated bits=0) by restart.be (8.14.5/8.14.5) with ESMTP id p5MEJmiF055147 for ; Wed, 22 Jun 2011 16:19:48 +0200 (CEST) (envelope-from hlh@restart.be) X-DKIM: Sendmail DKIM Filter v2.8.3 restart.be p5MEJmiF055147 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=restart.be; s=avoriaz; t=1308752388; bh=5pKU1sFgWmK+Vq9jvfiVxwUYCKRoeVOwt4rCG9GVyL4=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=VsHR8ytfo/src5RcAcnbS3b70e2N2tjarXoaly8r/3m8hk09MqDO7Ow05bC4tvbVE bsIekll1VGm4B0feDnDmw== X-DomainKeys: Sendmail DomainKeys Filter v1.0.2 restart.be p5MEJmiF055147 DomainKey-Signature: a=rsa-sha1; s=avoriaz; d=restart.be; c=nofws; q=dns; h=message-id:date:from:organization:user-agent:mime-version:to: subject:references:in-reply-to:content-type:content-transfer-encoding; b=B73we8bbnCWv1JtMsfTD17IPPFPU0OhWF+mDZnF3kjP7UjiJyUJoB4x6qE7UeaNFE 8eXPLlO7FGHFT4ve+futw== Message-ID: <4E01FA03.9070805@restart.be> Date: Wed, 22 Jun 2011 16:19:47 +0200 From: Henri Hennebert Organization: RestartSoft User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.17) Gecko/20110616 Thunderbird/3.1.10 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <201106211727.26413.jhb@freebsd.org> <4E01D32D.5050801@restart.be> <201106220957.09449.jhb@freebsd.org> In-Reply-To: <201106220957.09449.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: ZFS boot inside on the second partition inside a slice X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 14:36:10 -0000 On 06/22/2011 15:57, John Baldwin wrote: > On Wednesday, June 22, 2011 7:34:05 am Henri Hennebert wrote: >> I get >> >> LBA: 00008200 >> Read error: 04 > > Odd. Oh, I fubar'd and read the wrong thing for the sector. Also, we > should leave the EDD packet on the stack so it doesn't get trashed by > calling hex8, etc. Please try this: > > Index: zfsldr.S > =================================================================== > --- zfsldr.S (revision 223365) > +++ zfsldr.S (working copy) > @@ -16,7 +16,6 @@ > */ > > /* Memory Locations */ > - .set MEM_REL,0x700 # Relocation address > .set MEM_ARG,0x900 # Arguments > .set MEM_ORG,0x7c00 # Origin > .set MEM_BUF,0x8000 # Load area > @@ -91,26 +90,18 @@ main: cld # String ops inc > mov %cx,%ss # Set up > mov $start,%sp # stack > /* > - * Relocate ourself to MEM_REL. Since %cx == 0, the inc %ch sets > - * %cx == 0x100. > - */ > - mov %sp,%si # Source > - mov $MEM_REL,%di # Destination > - incb %ch # Word count > - rep # Copy > - movsw # code > -/* > * If we are on a hard drive, then load the MBR and look for the first > * FreeBSD slice. We use the fake partition entry below that points to > * the MBR when we call nread. The first pass looks for the first active > * FreeBSD slice. The second pass looks for the first non-active FreeBSD > * slice if the first one fails. > */ > - mov $part4,%si # Partition > + mov $part4,%si # Dummy partition > cmpb $0x80,%dl # Hard drive? > jb main.4 # No > - movb $0x1,%dh # Block count > - callw nread # Read MBR > + xor %eax,%eax # Read MBR > + movw $MEM_BUF,%bx # from first > + callw nread # sector > mov $0x1,%cx # Two passes > main.1: mov $MEM_BUF+PRT_OFF,%si # Partition table > movb $0x1,%dh # Partition > @@ -161,10 +152,16 @@ main.4: xor %dx,%dx # Partition:drive > * area and target area do not overlap. > */ > main.5: mov %dx,MEM_ARG # Save args > - movb $NSECT,%dh # Sector count > + mov $NSECT,%cx # Sector count > movl $1024,%eax # Offset to boot2 > - callw nread.1 # Read disk > -main.6: mov $MEM_BUF,%si # BTX (before reloc) > + mov $MEM_BUF,%bx # Destination buffer > +main.6: pushal # Save params > + callw nread # Read disk > + popal # Restore > + incl %eax # Update for > + add $SIZ_SEC,%bx # next sector > + loop main.6 # If not last, read another > + mov $MEM_BUF,%si # BTX (before reloc) > mov 0xa(%si),%bx # Get BTX length and set > mov $NSECT*SIZ_SEC-1,%di # Size of load area (less one) > mov %di,%si # End of load > @@ -214,29 +211,35 @@ seta20.3: sti # Enable interrupts > * packet on the stack and passes it to read. > * > * %eax - int - LBA to read in relative to partition start > + * %es:%bx - ptr - destination address > * %dl - byte - drive to read from > - * %dh - byte - num sectors to read > * %si - ptr - MBR partition entry > */ > -nread: xor %eax,%eax # Sector offset in partition > -nread.1: xor %ecx,%ecx # Get > +nread: xor %ecx,%ecx # Get > addl 0x8(%si),%eax # LBA > adc $0,%ecx > pushl %ecx # Starting absolute block > pushl %eax # block number > push %es # Address of > - push $MEM_BUF # transfer buffer > - xor %ax,%ax # Number of > - movb %dh,%al # blocks to > - push %ax # transfer > + push %bx # transfer buffer > + push $0x1 # Read 1 sector > push $0x10 # Size of packet > mov %sp,%bp # Packet pointer > callw read # Read from disk > + jc nread.1 # If error, fail > lea 0x10(%bp),%sp # Clear stack > - jnc return # If success, return > - mov $msg_read,%si # Otherwise, set the error > - # message and fall through to > - # the error routine > + ret # If success, return > +nread.1: mov %ah,%al # Format > + mov $read_err,%di # error > + call hex8 # code > + movl 0x8(%bp),%eax # Format > + mov $lba,%di # LBA > + call hex32 > + mov $msg_lba,%si # Display > + call putstr # LBA > + mov $msg_read,%si # Set the error message and > + # fall through to the error > + # routine > /* > * Print out the error message pointed to by %ds:(%si) followed > * by a prompt, wait for a keypress, and then reboot the machine. > @@ -259,14 +262,6 @@ putstr: lodsb # Get char > jne putstr.0 # No > > /* > - * Overused return code. ereturn is used to return an error from the > - * read function. Since we assume putstr succeeds, we (ab)use the > - * same code when we return from putstr. > - */ > -ereturn: movb $0x1,%ah # Invalid > - stc # argument > -return: retw # To caller > -/* > * Reads sectors from the disk. If EDD is enabled, then check if it is > * installed and use it if it is. If it is not installed or not enabled, then > * fall back to using CHS. Since we use a LBA, if we are using CHS, we have to > @@ -294,14 +289,38 @@ read: cmpb $0x80,%dl # Hard drive? > retw # To caller > read.1: mov $msg_chs,%si > jmp error > -msg_chs: .asciz "CHS not supported" > > +/* > + * Convert EAX, AX, or AL to hex, saving the result to [EDI]. > + */ > +hex32: pushl %eax # Save > + shrl $0x10,%eax # Do upper > + call hex16 # 16 > + popl %eax # Restore > +hex16: call hex16.1 # Do upper 8 > +hex16.1: xchgb %ah,%al # Save/restore > +hex8: push %ax # Save > + shrb $0x4,%al # Do upper > + call hex8.1 # 4 > + pop %ax # Restore > +hex8.1: andb $0xf,%al # Get lower 4 > + cmpb $0xa,%al # Convert > + sbbb $0x69,%al # to hex > + das # digit > + orb $0x20,%al # To lower case > + stosb # Save char > + ret # (Recursive) > + > /* Messages */ > > -msg_read: .asciz "Read" > -msg_part: .asciz "Boot" > +msg_chs: .asciz "CHS not supported" > +msg_read: .ascii "Read error: " > +read_err: .asciz "XX" > +msg_lba: .ascii "LBA: " > +lba: .asciz "XXXXXXXX\r\n" > +msg_part: .asciz "Boot error" > > -prompt: .asciz " error\r\n" > +prompt: .asciz "\r\n" > > .org PRT_OFF,0x90 > > > This time: LBA: 3c802308 Read error: 04 This morning I was reading the code (I'm in Belgium) and find that the previous LBA output was DAP+4 and so was the addr of the buffer. 0x8200 = $MEM_BUF+512, and so we must be in the second read. Henri From owner-freebsd-stable@FreeBSD.ORG Wed Jun 22 14:43:08 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AFF641065673 for ; Wed, 22 Jun 2011 14:43:08 +0000 (UTC) (envelope-from hlh@restart.be) Received: from tignes.restart.be (tignes.restart.be [94.23.211.191]) by mx1.freebsd.org (Postfix) with ESMTP id 532948FC1C for ; Wed, 22 Jun 2011 14:43:08 +0000 (UTC) Received: from restart.be (avoriaz.tunnel.bel [IPv6:2001:41d0:2:56bf:1:ffff::]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "smtp.restart.be", Issuer "CA master" (verified OK)) by tignes.restart.be (Postfix) with ESMTPS id 7A4F214B5B; Wed, 22 Jun 2011 16:42:37 +0200 (CEST) Received: from morzine.restart.bel (morzine.restart.be [IPv6:2001:41d0:2:56bf:1:2::]) (authenticated bits=0) by restart.be (8.14.5/8.14.5) with ESMTP id p5MEga0X055647; Wed, 22 Jun 2011 16:42:36 +0200 (CEST) (envelope-from hlh@restart.be) X-DKIM: Sendmail DKIM Filter v2.8.3 restart.be p5MEga0X055647 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=restart.be; s=avoriaz; t=1308753756; bh=VgUDUT/uy8LtFbvfrIGUHPBrVHrtRGxut+Bg/v8PObs=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=vU8T6cQIJCy8AU/YrmOY6Y3qQe2bpg56GEfEIibji358wZ1XmgUV2o8aTUeuD9+FV SKMBjEwv3/c5tIz151bKg== X-DomainKeys: Sendmail DomainKeys Filter v1.0.2 restart.be p5MEga0X055647 DomainKey-Signature: a=rsa-sha1; s=avoriaz; d=restart.be; c=nofws; q=dns; h=message-id:date:from:organization:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type:content-transfer-encoding; b=VLkEUCg14EoI8wpHybFQ1CEMadnUMLHo+bHkSQnVtU75+EZJf7LIh88iWhHM6R1J+ JXKdfEOGdaymOBk2Wk99A== Message-ID: <4E01FF5C.1060306@restart.be> Date: Wed, 22 Jun 2011 16:42:36 +0200 From: Henri Hennebert Organization: RestartSoft User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.17) Gecko/20110616 Thunderbird/3.1.10 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <201106211727.26413.jhb@freebsd.org> <4E01D32D.5050801@restart.be> <201106220957.09449.jhb@freebsd.org> <4E01FA03.9070805@restart.be> <4E01FADA.2070104@restart.be> In-Reply-To: <4E01FADA.2070104@restart.be> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Cc: jhb@freebsd.org Subject: Re: ZFS boot inside on the second partition inside a slice X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 14:43:08 -0000 On 06/22/2011 16:23, Henri Hennebert wrote: > On 06/22/2011 16:19, Henri Hennebert wrote: >> On 06/22/2011 15:57, John Baldwin wrote: >>> On Wednesday, June 22, 2011 7:34:05 am Henri Hennebert wrote: >>>> I get >>>> >>>> LBA: 00008200 >>>> Read error: 04 >>> >>> Odd. Oh, I fubar'd and read the wrong thing for the sector. Also, we >>> should leave the EDD packet on the stack so it doesn't get trashed by >>> calling hex8, etc. Please try this: >>> >>> Index: zfsldr.S >>> =================================================================== >>> --- zfsldr.S (revision 223365) >>> +++ zfsldr.S (working copy) >>> @@ -16,7 +16,6 @@ >>> */ >>> >>> /* Memory Locations */ >>> - .set MEM_REL,0x700 # Relocation address >>> .set MEM_ARG,0x900 # Arguments >>> .set MEM_ORG,0x7c00 # Origin >>> .set MEM_BUF,0x8000 # Load area >>> @@ -91,26 +90,18 @@ main: cld # String ops inc >>> mov %cx,%ss # Set up >>> mov $start,%sp # stack >>> /* >>> - * Relocate ourself to MEM_REL. Since %cx == 0, the inc %ch sets >>> - * %cx == 0x100. >>> - */ >>> - mov %sp,%si # Source >>> - mov $MEM_REL,%di # Destination >>> - incb %ch # Word count >>> - rep # Copy >>> - movsw # code >>> -/* >>> * If we are on a hard drive, then load the MBR and look for the first >>> * FreeBSD slice. We use the fake partition entry below that points to >>> * the MBR when we call nread. The first pass looks for the first active >>> * FreeBSD slice. The second pass looks for the first non-active FreeBSD >>> * slice if the first one fails. >>> */ >>> - mov $part4,%si # Partition >>> + mov $part4,%si # Dummy partition >>> cmpb $0x80,%dl # Hard drive? >>> jb main.4 # No >>> - movb $0x1,%dh # Block count >>> - callw nread # Read MBR >>> + xor %eax,%eax # Read MBR >>> + movw $MEM_BUF,%bx # from first >>> + callw nread # sector >>> mov $0x1,%cx # Two passes >>> main.1: mov $MEM_BUF+PRT_OFF,%si # Partition table >>> movb $0x1,%dh # Partition >>> @@ -161,10 +152,16 @@ main.4: xor %dx,%dx # Partition:drive >>> * area and target area do not overlap. >>> */ >>> main.5: mov %dx,MEM_ARG # Save args >>> - movb $NSECT,%dh # Sector count >>> + mov $NSECT,%cx # Sector count >>> movl $1024,%eax # Offset to boot2 >>> - callw nread.1 # Read disk >>> -main.6: mov $MEM_BUF,%si # BTX (before reloc) >>> + mov $MEM_BUF,%bx # Destination buffer >>> +main.6: pushal # Save params >>> + callw nread # Read disk >>> + popal # Restore >>> + incl %eax # Update for >>> + add $SIZ_SEC,%bx # next sector >>> + loop main.6 # If not last, read another >>> + mov $MEM_BUF,%si # BTX (before reloc) >>> mov 0xa(%si),%bx # Get BTX length and set >>> mov $NSECT*SIZ_SEC-1,%di # Size of load area (less one) >>> mov %di,%si # End of load >>> @@ -214,29 +211,35 @@ seta20.3: sti # Enable interrupts >>> * packet on the stack and passes it to read. >>> * >>> * %eax - int - LBA to read in relative to partition start >>> + * %es:%bx - ptr - destination address >>> * %dl - byte - drive to read from >>> - * %dh - byte - num sectors to read >>> * %si - ptr - MBR partition entry >>> */ >>> -nread: xor %eax,%eax # Sector offset in partition >>> -nread.1: xor %ecx,%ecx # Get >>> +nread: xor %ecx,%ecx # Get >>> addl 0x8(%si),%eax # LBA >>> adc $0,%ecx >>> pushl %ecx # Starting absolute block >>> pushl %eax # block number >>> push %es # Address of >>> - push $MEM_BUF # transfer buffer >>> - xor %ax,%ax # Number of >>> - movb %dh,%al # blocks to >>> - push %ax # transfer >>> + push %bx # transfer buffer >>> + push $0x1 # Read 1 sector >>> push $0x10 # Size of packet >>> mov %sp,%bp # Packet pointer >>> callw read # Read from disk >>> + jc nread.1 # If error, fail >>> lea 0x10(%bp),%sp # Clear stack >>> - jnc return # If success, return >>> - mov $msg_read,%si # Otherwise, set the error >>> - # message and fall through to >>> - # the error routine >>> + ret # If success, return >>> +nread.1: mov %ah,%al # Format >>> + mov $read_err,%di # error >>> + call hex8 # code >>> + movl 0x8(%bp),%eax # Format >>> + mov $lba,%di # LBA >>> + call hex32 >>> + mov $msg_lba,%si # Display >>> + call putstr # LBA >>> + mov $msg_read,%si # Set the error message and >>> + # fall through to the error >>> + # routine >>> /* >>> * Print out the error message pointed to by %ds:(%si) followed >>> * by a prompt, wait for a keypress, and then reboot the machine. >>> @@ -259,14 +262,6 @@ putstr: lodsb # Get char >>> jne putstr.0 # No >>> >>> /* >>> - * Overused return code. ereturn is used to return an error from the >>> - * read function. Since we assume putstr succeeds, we (ab)use the >>> - * same code when we return from putstr. >>> - */ >>> -ereturn: movb $0x1,%ah # Invalid >>> - stc # argument >>> -return: retw # To caller >>> -/* >>> * Reads sectors from the disk. If EDD is enabled, then check if it is >>> * installed and use it if it is. If it is not installed or not >>> enabled, then >>> * fall back to using CHS. Since we use a LBA, if we are using CHS, we >>> have to >>> @@ -294,14 +289,38 @@ read: cmpb $0x80,%dl # Hard drive? >>> retw # To caller >>> read.1: mov $msg_chs,%si >>> jmp error >>> -msg_chs: .asciz "CHS not supported" >>> >>> +/* >>> + * Convert EAX, AX, or AL to hex, saving the result to [EDI]. >>> + */ >>> +hex32: pushl %eax # Save >>> + shrl $0x10,%eax # Do upper >>> + call hex16 # 16 >>> + popl %eax # Restore >>> +hex16: call hex16.1 # Do upper 8 >>> +hex16.1: xchgb %ah,%al # Save/restore >>> +hex8: push %ax # Save >>> + shrb $0x4,%al # Do upper >>> + call hex8.1 # 4 >>> + pop %ax # Restore >>> +hex8.1: andb $0xf,%al # Get lower 4 >>> + cmpb $0xa,%al # Convert >>> + sbbb $0x69,%al # to hex >>> + das # digit >>> + orb $0x20,%al # To lower case >>> + stosb # Save char >>> + ret # (Recursive) >>> + >>> /* Messages */ >>> >>> -msg_read: .asciz "Read" >>> -msg_part: .asciz "Boot" >>> +msg_chs: .asciz "CHS not supported" >>> +msg_read: .ascii "Read error: " >>> +read_err: .asciz "XX" >>> +msg_lba: .ascii "LBA: " >>> +lba: .asciz "XXXXXXXX\r\n" >>> +msg_part: .asciz "Boot error" >>> >>> -prompt: .asciz " error\r\n" >>> +prompt: .asciz "\r\n" >>> >>> .org PRT_OFF,0x90 >>> >>> >>> >> This time: >> >> LBA: 3c802308 >> Read error: 04 >> >> This morning I was reading the code (I'm in Belgium) and find that the >> previous LBA output was DAP+4 and so was the addr of the buffer. 0x8200 >> = $MEM_BUF+512, and so we must be in the second read. >> > > OK I think I see, the first read mangle the partition table previously > read at $MEM_BUF and so the next one is wrong. That's it. I read `hd zfsboot' and at 0x200+0x1be+0x10+0x08 I get 07 1f 80 3c as LBA: 0x3C801F07 + 0x401 = 3c802308 > > >> Henri >> >> > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Wed Jun 22 15:17:39 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 05169106566B for ; Wed, 22 Jun 2011 15:17:39 +0000 (UTC) (envelope-from gkontos.mail@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id BF1208FC19 for ; Wed, 22 Jun 2011 15:17:38 +0000 (UTC) Received: by iwr19 with SMTP id 19so1071873iwr.13 for ; Wed, 22 Jun 2011 08:17:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=ws/m6MiiiDvTmkp+LFg3f2xQ4B0cy7tceEgF/7vhstU=; b=JJ3bqoDH9tMKLnz43B4MIsPVPOdZsD0cwU4RfOXKTfR/rwbXRT3e3jixmnZbd5RWHR +HU6x6A5CLWFUpOFVUPL3JpB6VI5JHNUrunIdJtUb5v7gqpeUEnMluaYJM22cHy2M6wP 38cY9qRG8H5+C/dkKlBmHbG+jOqOqyjwccNvs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=qB1B9mEbnnOB6EJ0maQdAio2nPEvJJ1jJ3qRr7DEKBdMs3UzKE4MFHwUQ8oX70gSPU M+TGyePryBBXlVqSXSj+TqJ8NlGuPhxmkESlPHC0hTLCoyws8xOM69oj+RbQt40rZWXh l/8EnuCve159hebjIKnq0UluT5df9s7g0/wPM= MIME-Version: 1.0 Received: by 10.231.54.100 with SMTP id p36mr666946ibg.162.1308754359029; Wed, 22 Jun 2011 07:52:39 -0700 (PDT) Received: by 10.231.15.5 with HTTP; Wed, 22 Jun 2011 07:52:39 -0700 (PDT) Date: Wed, 22 Jun 2011 17:52:39 +0300 Message-ID: From: George Kontostanos To: FreeBSD Stable Content-Type: multipart/mixed; boundary=000e0cd256b2ab11c904a64e1ea9 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: ata: SIGNATURE: ffffffff X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 15:17:39 -0000 --000e0cd256b2ab11c904a64e1ea9 Content-Type: text/plain; charset=ISO-8859-1 This is the 3rd disk I replace in 3 disk- Raiz1 pool and I really start to believe that the problem is somewhere else. The disks reside in a Promise PDC40718 SATA300 controller. I am running this set up since 8.0-Release with no issues till a few months ago after 8.2-Release now at 8.2-Stable. Symptoms: Jun 22 17:08:53 hp kernel: ata2: timeout waiting to issue command Jun 22 17:08:53 hp kernel: ata2: error issuing SETFEATURES ENABLE WCACHE command Jun 22 17:09:33 hp kernel: ad4: WARNING - SET_MULTI taskqueue timeout - completing request directly Jun 22 17:09:33 hp kernel: ad4: WARNING - WRITE_DMA48 requeued due to channel reset LBA=321558741 Jun 22 17:09:34 hp kernel: ata2: SIGNATURE: 00000101 Jun 22 17:09:34 hp kernel: ad4: WARNING - WRITE_DMA48 requeued due to channel reset LBA=321558869 Jun 22 17:09:34 hp kernel: ata2: FAILURE - already active DMA on this device Jun 22 17:09:34 hp kernel: ata2: setting up DMA failed Jun 22 17:09:34 hp kernel: ata2: FAILURE - already active DMA on this device Jun 22 17:09:34 hp kernel: ata2: setting up DMA failed After a while the disk gets detached from the pool. Always the same disk. Rite now I am in the process of resilvering : pool: tank state: ONLINE status: One or more devices is currently being resilvered. The pool will continue to function, possibly in a degraded state. action: Wait for the resilver to complete. scan: resilver in progress since Wed Jun 22 17:09:40 2011 189G scanned out of 578G at 88.8M/s, 1h14m to go 62.9G resilvered, 32.63% done config: NAME STATE READ WRITE CKSUM tank ONLINE 0 0 0 raidz1-0 ONLINE 0 0 0 label/zdisk1 ONLINE 0 0 0 label/zdisk2 ONLINE 0 0 0 label/zdisk3 ONLINE 0 0 0 (resilvering) But those errors have started to appear again. Again this is the 3rd disk replaced !!! Full dmesg attached -- George Kontostanos aisecure.net --000e0cd256b2ab11c904a64e1ea9 Content-Type: text/plain; charset=US-ASCII; name="dmesg.txt" Content-Disposition: attachment; filename="dmesg.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gp8elivl0 Q29weXJpZ2h0IChjKSAxOTkyLTIwMTEgVGhlIEZyZWVCU0QgUHJvamVjdC4KQ29weXJpZ2h0IChj KSAxOTc5LCAxOTgwLCAxOTgzLCAxOTg2LCAxOTg4LCAxOTg5LCAxOTkxLCAxOTkyLCAxOTkzLCAx OTk0CglUaGUgUmVnZW50cyBvZiB0aGUgVW5pdmVyc2l0eSBvZiBDYWxpZm9ybmlhLiBBbGwgcmln aHRzIHJlc2VydmVkLgpGcmVlQlNEIGlzIGEgcmVnaXN0ZXJlZCB0cmFkZW1hcmsgb2YgVGhlIEZy ZWVCU0QgRm91bmRhdGlvbi4KRnJlZUJTRCA4LjItU1RBQkxFICMwOiBNb24gSnVuICA2IDE5OjAw OjE5IEVFU1QgMjAxMQogICAgZ2tvbnRvc0BocC5haWNvbS5sb2M6L3Vzci9vYmovdXNyL3NyYy9z eXMvTUwxMTBHMyBhbWQ2NApUaW1lY291bnRlciAiaTgyNTQiIGZyZXF1ZW5jeSAxMTkzMTgyIEh6 IHF1YWxpdHkgMApDUFU6IEludGVsKFIpIFBlbnRpdW0oUikgRCBDUFUgMy4yMEdIeiAoMzIwMC4x My1NSHogSzgtY2xhc3MgQ1BVKQogIE9yaWdpbiA9ICJHZW51aW5lSW50ZWwiICBJZCA9IDB4ZjY0 ICBGYW1pbHkgPSBmICBNb2RlbCA9IDYgIFN0ZXBwaW5nID0gNAogIEZlYXR1cmVzPTB4YmZlYmZi ZmY8RlBVLFZNRSxERSxQU0UsVFNDLE1TUixQQUUsTUNFLENYOCxBUElDLFNFUCxNVFJSLFBHRSxN Q0EsQ01PVixQQVQsUFNFMzYsQ0xGTFVTSCxEVFMsQUNQSSxNTVgsRlhTUixTU0UsU1NFMixTUyxI VFQsVE0sUEJFPgogIEZlYXR1cmVzMj0weGU0YmQ8U1NFMyxEVEVTNjQsTU9OLERTX0NQTCxWTVgs RVNULENOWFQtSUQsQ1gxNix4VFBSLFBEQ00+CiAgQU1EIEZlYXR1cmVzPTB4MjAxMDA4MDA8U1lT Q0FMTCxOWCxMTT4KICBBTUQgRmVhdHVyZXMyPTB4MTxMQUhGPgogIFRTQzogUC1zdGF0ZSBpbnZh cmlhbnQKcmVhbCBtZW1vcnkgID0gNDI5NDk2NzI5NiAoNDA5NiBNQikKYXZhaWwgbWVtb3J5ID0g NDEwNjc4MDY3MiAoMzkxNiBNQikKQUNQSSBBUElDIFRhYmxlOiA8SFAgICAgIE9FTUFQSUMgPgpG cmVlQlNEL1NNUDogTXVsdGlwcm9jZXNzb3IgU3lzdGVtIERldGVjdGVkOiAyIENQVXMKRnJlZUJT RC9TTVA6IDEgcGFja2FnZShzKSB4IDIgY29yZShzKQogY3B1MCAoQlNQKTogQVBJQyBJRDogIDAK IGNwdTEgKEFQKTogQVBJQyBJRDogIDEKaW9hcGljMDogQ2hhbmdpbmcgQVBJQyBJRCB0byAyCmlv YXBpYzAgPFZlcnNpb24gMi4wPiBpcnFzIDAtMjMgb24gbW90aGVyYm9hcmQKa2JkMSBhdCBrYmRt dXgwCmFjcGkwOiA8SFAgT0VNWFNEVD4gb24gbW90aGVyYm9hcmQKYWNwaTA6IFtJVEhSRUFEXQph Y3BpMDogUG93ZXIgQnV0dG9uIChmaXhlZCkKVGltZWNvdW50ZXIgIkFDUEktZmFzdCIgZnJlcXVl bmN5IDM1Nzk1NDUgSHogcXVhbGl0eSAxMDAwCmFjcGlfdGltZXIwOiA8MjQtYml0IHRpbWVyIGF0 IDMuNTc5NTQ1TUh6PiBwb3J0IDB4ODA4LTB4ODBiIG9uIGFjcGkwCmNwdTA6IDxBQ1BJIENQVT4g b24gYWNwaTAKY3B1MTogPEFDUEkgQ1BVPiBvbiBhY3BpMApwY2liMDogPEFDUEkgSG9zdC1QQ0kg YnJpZGdlPiBwb3J0IDB4Y2Y4LTB4Y2ZmIG9uIGFjcGkwCnBjaTA6IDxBQ1BJIFBDSSBidXM+IG9u IHBjaWIwCnBjaWIxOiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4gaXJxIDE2IGF0IGRldmljZSAyOC4w IG9uIHBjaTAKcGNpMTogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjEKcGNpYjI6IDxBQ1BJIFBDSS1Q Q0kgYnJpZGdlPiBpcnEgMTcgYXQgZGV2aWNlIDI4LjUgb24gcGNpMApwY2k3OiA8QUNQSSBQQ0kg YnVzPiBvbiBwY2liMgpiZ2UwOiA8QnJvYWRjb20gTmV0WHRyZW1lIEdpZ2FiaXQgRXRoZXJuZXQg Q29udHJvbGxlciwgQVNJQyByZXYuIDB4MDA0MTAxPiBtZW0gMHhmZWFmMDAwMC0weGZlYWZmZmZm IGlycSAxNyBhdCBkZXZpY2UgMC4wIG9uIHBjaTcKYmdlMDogQ0hJUCBJRCAweDAwMDA0MTAxOyBB U0lDIFJFViAweDA0OyBDSElQIFJFViAweDQxOyBQQ0ktRQptaWlidXMwOiA8TUlJIGJ1cz4gb24g YmdlMApicmdwaHkwOiA8QkNNNTc1MCAxMC8xMDAvMTAwMGJhc2VUWCBQSFk+IFBIWSAxIG9uIG1p aWJ1czAKYnJncGh5MDogIDEwYmFzZVQsIDEwYmFzZVQtRkRYLCAxMDBiYXNlVFgsIDEwMGJhc2VU WC1GRFgsIDEwMDBiYXNlVCwgMTAwMGJhc2VULW1hc3RlciwgMTAwMGJhc2VULUZEWCwgMTAwMGJh c2VULUZEWC1tYXN0ZXIsIGF1dG8sIGF1dG8tZmxvdwpiZ2UwOiBFdGhlcm5ldCBhZGRyZXNzOiAw MDoxMzoyMTpjYzozOTozNQpiZ2UwOiBbSVRIUkVBRF0KdWhjaTA6IDxJbnRlbCA4MjgwMUcgKElD SDcpIFVTQiBjb250cm9sbGVyIFVTQi1BPiBwb3J0IDB4ZGMwMC0weGRjMWYgaXJxIDIzIGF0IGRl dmljZSAyOS4wIG9uIHBjaTAKdWhjaTA6IFtJVEhSRUFEXQp1aGNpMDogTGVnU3VwID0gMHgyZjAw CnVzYnVzMDogPEludGVsIDgyODAxRyAoSUNINykgVVNCIGNvbnRyb2xsZXIgVVNCLUE+IG9uIHVo Y2kwCnVoY2kxOiA8SW50ZWwgODI4MDFHIChJQ0g3KSBVU0IgY29udHJvbGxlciBVU0ItQj4gcG9y dCAweGQ4ODAtMHhkODlmIGlycSAxOSBhdCBkZXZpY2UgMjkuMSBvbiBwY2kwCnVoY2kxOiBbSVRI UkVBRF0KdWhjaTE6IExlZ1N1cCA9IDB4MmYwMAp1c2J1czE6IDxJbnRlbCA4MjgwMUcgKElDSDcp IFVTQiBjb250cm9sbGVyIFVTQi1CPiBvbiB1aGNpMQp1aGNpMjogPEludGVsIDgyODAxRyAoSUNI NykgVVNCIGNvbnRyb2xsZXIgVVNCLUM+IHBvcnQgMHhkODAwLTB4ZDgxZiBpcnEgMTggYXQgZGV2 aWNlIDI5LjIgb24gcGNpMAp1aGNpMjogW0lUSFJFQURdCnVoY2kyOiBMZWdTdXAgPSAweDJmMDAK dXNidXMyOiA8SW50ZWwgODI4MDFHIChJQ0g3KSBVU0IgY29udHJvbGxlciBVU0ItQz4gb24gdWhj aTIKZWhjaTA6IDxJbnRlbCA4MjgwMUdCL1IgKElDSDcpIFVTQiAyLjAgY29udHJvbGxlcj4gbWVt IDB4ZmU5ZmZjMDAtMHhmZTlmZmZmZiBpcnEgMjMgYXQgZGV2aWNlIDI5Ljcgb24gcGNpMAplaGNp MDogW0lUSFJFQURdCnVzYnVzMzogRUhDSSB2ZXJzaW9uIDEuMAp1c2J1czM6IDxJbnRlbCA4Mjgw MUdCL1IgKElDSDcpIFVTQiAyLjAgY29udHJvbGxlcj4gb24gZWhjaTAKcGNpYjM6IDxBQ1BJIFBD SS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2UgMzAuMCBvbiBwY2kwCnBjaTg6IDxBQ1BJIFBDSSBidXM+ IG9uIHBjaWIzCmF0YXBjaTA6IDxQcm9taXNlIFBEQzQwNzE4IFNBVEEzMDAgY29udHJvbGxlcj4g cG9ydCAweGVjMDAtMHhlYzdmLDB4ZTgwMC0weGU4ZmYgbWVtIDB4ZmViZmYwMDAtMHhmZWJmZmZm ZiwweGZlYmMwMDAwLTB4ZmViZGZmZmYgaXJxIDE2IGF0IGRldmljZSAwLjAgb24gcGNpOAphdGFw Y2kwOiBbSVRIUkVBRF0KYXRhcGNpMDogW0lUSFJFQURdCmF0YTI6IDxBVEEgY2hhbm5lbCAwPiBv biBhdGFwY2kwCmF0YTI6IFNJR05BVFVSRTogMDAwMDAxMDEKYXRhMjogW0lUSFJFQURdCmF0YTM6 IDxBVEEgY2hhbm5lbCAxPiBvbiBhdGFwY2kwCmF0YTM6IFNJR05BVFVSRTogMDAwMDAxMDEKYXRh MzogW0lUSFJFQURdCmF0YTQ6IDxBVEEgY2hhbm5lbCAyPiBvbiBhdGFwY2kwCmF0YTQ6IFtJVEhS RUFEXQphdGE1OiA8QVRBIGNoYW5uZWwgMz4gb24gYXRhcGNpMAphdGE1OiBTSUdOQVRVUkU6IDAw MDAwMTAxCmF0YTU6IFtJVEhSRUFEXQp2Z2FwY2kwOiA8VkdBLWNvbXBhdGlibGUgZGlzcGxheT4g cG9ydCAweGUwMDAtMHhlMGZmIG1lbSAweGU4MDAwMDAwLTB4ZWZmZmZmZmYsMHhmZWJiMDAwMC0w eGZlYmJmZmZmIGlycSAxNiBhdCBkZXZpY2UgMi4wIG9uIHBjaTgKaXNhYjA6IDxQQ0ktSVNBIGJy aWRnZT4gYXQgZGV2aWNlIDMxLjAgb24gcGNpMAppc2EwOiA8SVNBIGJ1cz4gb24gaXNhYjAKYXRh cGNpMTogPEludGVsIElDSDcgVURNQTEwMCBjb250cm9sbGVyPiBwb3J0IDB4MWYwLTB4MWY3LDB4 M2Y2LDB4MTcwLTB4MTc3LDB4Mzc2LDB4ZmZhMC0weGZmYWYgYXQgZGV2aWNlIDMxLjEgb24gcGNp MAphdGEwOiA8QVRBIGNoYW5uZWwgMD4gb24gYXRhcGNpMQphdGEwOiBbSVRIUkVBRF0KYWhjaTA6 IDxJbnRlbCBJQ0g3IEFIQ0kgU0FUQSBjb250cm9sbGVyPiBwb3J0IDB4ZDQ4MC0weGQ0ODcsMHhk NDAwLTB4ZDQwMywweGQwODAtMHhkMDg3LDB4ZDAwMC0weGQwMDMsMHhjYzAwLTB4Y2MwZiBtZW0g MHhmZTlmZjgwMC0weGZlOWZmYmZmIGlycSAxOSBhdCBkZXZpY2UgMzEuMiBvbiBwY2kwCmFoY2kw OiBbSVRIUkVBRF0KYWhjaTA6IEFIQ0kgdjEuMTAgd2l0aCA0IDNHYnBzIHBvcnRzLCBQb3J0IE11 bHRpcGxpZXIgbm90IHN1cHBvcnRlZAphaGNpY2gwOiA8QUhDSSBjaGFubmVsPiBhdCBjaGFubmVs IDAgb24gYWhjaTAKYWhjaWNoMDogW0lUSFJFQURdCmFoY2ljaDE6IDxBSENJIGNoYW5uZWw+IGF0 IGNoYW5uZWwgMSBvbiBhaGNpMAphaGNpY2gxOiBbSVRIUkVBRF0KYWhjaWNoMjogPEFIQ0kgY2hh bm5lbD4gYXQgY2hhbm5lbCAyIG9uIGFoY2kwCmFoY2ljaDI6IFtJVEhSRUFEXQphaGNpY2gzOiA8 QUhDSSBjaGFubmVsPiBhdCBjaGFubmVsIDMgb24gYWhjaTAKYWhjaWNoMzogW0lUSFJFQURdCmFj cGlfYnV0dG9uMDogPFBvd2VyIEJ1dHRvbj4gb24gYWNwaTAKYXRydGMwOiA8QVQgcmVhbHRpbWUg Y2xvY2s+IHBvcnQgMHg3MC0weDcxIGlycSA4IG9uIGFjcGkwCnVhcnQwOiA8MTY1NTAgb3IgY29t cGF0aWJsZT4gcG9ydCAweDNmOC0weDNmZiBpcnEgNCBmbGFncyAweDEwIG9uIGFjcGkwCnVhcnQw OiBbRklMVEVSXQp1YXJ0MTogPDE2NTUwIG9yIGNvbXBhdGlibGU+IHBvcnQgMHgyZjgtMHgyZmYg aXJxIDMgb24gYWNwaTAKdWFydDE6IFtGSUxURVJdCnBwYzA6IDxQYXJhbGxlbCBwb3J0PiBwb3J0 IDB4Mzc4LTB4MzdmLDB4Nzc4LTB4NzdmIGlycSA3IGRycSAzIG9uIGFjcGkwCnBwYzA6IFNNQy1s aWtlIGNoaXBzZXQgKEVDUC9FUFAvUFMyL05JQkJMRSkgaW4gQ09NUEFUSUJMRSBtb2RlCnBwYzA6 IEZJRk8gd2l0aCAxNi8xNi84IGJ5dGVzIHRocmVzaG9sZApwcGMwOiBbSVRIUkVBRF0KcHBidXMw OiA8UGFyYWxsZWwgcG9ydCBidXM+IG9uIHBwYzAKcGxpcDA6IDxQTElQIG5ldHdvcmsgaW50ZXJm YWNlPiBvbiBwcGJ1czAKcGxpcDA6IFtJVEhSRUFEXQpscHQwOiA8UHJpbnRlcj4gb24gcHBidXMw CmxwdDA6IFtJVEhSRUFEXQpscHQwOiBJbnRlcnJ1cHQtZHJpdmVuIHBvcnQKcHBpMDogPFBhcmFs bGVsIEkvTz4gb24gcHBidXMwCm9ybTA6IDxJU0EgT3B0aW9uIFJPTXM+IGF0IGlvbWVtIDB4YzAw MDAtMHhjOGZmZiwweGM5MDAwLTB4Y2RmZmYsMHhjZjgwMC0weGQ0N2ZmLDB4ZDQ4MDAtMHhkNTdm ZiBvbiBpc2EwCnNjMDogPFN5c3RlbSBjb25zb2xlPiBhdCBmbGFncyAweDEwMCBvbiBpc2EwCnNj MDogVkdBIDwxNiB2aXJ0dWFsIGNvbnNvbGVzLCBmbGFncz0weDMwMD4KdmdhMDogPEdlbmVyaWMg SVNBIFZHQT4gYXQgcG9ydCAweDNjMC0weDNkZiBpb21lbSAweGEwMDAwLTB4YmZmZmYgb24gaXNh MAphdGtiZGMwOiA8S2V5Ym9hcmQgY29udHJvbGxlciAoaTgwNDIpPiBhdCBwb3J0IDB4NjAsMHg2 NCBvbiBpc2EwCmF0a2JkMDogPEFUIEtleWJvYXJkPiBpcnEgMSBvbiBhdGtiZGMwCmtiZDAgYXQg YXRrYmQwCmF0a2JkMDogW0dJQU5ULUxPQ0tFRF0KYXRrYmQwOiBbSVRIUkVBRF0KZXN0MDogPEVu aGFuY2VkIFNwZWVkU3RlcCBGcmVxdWVuY3kgQ29udHJvbD4gb24gY3B1MAplc3Q6IENQVSBzdXBw b3J0cyBFbmhhbmNlZCBTcGVlZHN0ZXAsIGJ1dCBpcyBub3QgcmVjb2duaXplZC4KZXN0OiBjcHVf dmVuZG9yIEdlbnVpbmVJbnRlbCwgbXNyIDEwMjQwMDAwMTAyNApkZXZpY2VfYXR0YWNoOiBlc3Qw IGF0dGFjaCByZXR1cm5lZCA2CnA0dGNjMDogPENQVSBGcmVxdWVuY3kgVGhlcm1hbCBDb250cm9s PiBvbiBjcHUwCmVzdDE6IDxFbmhhbmNlZCBTcGVlZFN0ZXAgRnJlcXVlbmN5IENvbnRyb2w+IG9u IGNwdTEKZXN0OiBDUFUgc3VwcG9ydHMgRW5oYW5jZWQgU3BlZWRzdGVwLCBidXQgaXMgbm90IHJl Y29nbml6ZWQuCmVzdDogY3B1X3ZlbmRvciBHZW51aW5lSW50ZWwsIG1zciAxMDI0MDAwMDEwMjQK ZGV2aWNlX2F0dGFjaDogZXN0MSBhdHRhY2ggcmV0dXJuZWQgNgpwNHRjYzE6IDxDUFUgRnJlcXVl bmN5IFRoZXJtYWwgQ29udHJvbD4gb24gY3B1MQpaRlMgTk9USUNFOiBQcmVmZXRjaCBpcyBkaXNh YmxlZCBieSBkZWZhdWx0IGlmIGxlc3MgdGhhbiA0R0Igb2YgUkFNIGlzIHByZXNlbnQ7CiAgICAg ICAgICAgIHRvIGVuYWJsZSwgYWRkICJ2ZnMuemZzLnByZWZldGNoX2Rpc2FibGU9MCIgdG8gL2Jv b3QvbG9hZGVyLmNvbmYuClpGUyBmaWxlc3lzdGVtIHZlcnNpb24gNQpaRlMgc3RvcmFnZSBwb29s IHZlcnNpb24gMjgKVGltZWNvdW50ZXJzIHRpY2sgZXZlcnkgMS4wMDAgbXNlYwp1c2J1czA6IDEy TWJwcyBGdWxsIFNwZWVkIFVTQiB2MS4wCnVzYnVzMTogMTJNYnBzIEZ1bGwgU3BlZWQgVVNCIHYx LjAKdXNidXMyOiAxMk1icHMgRnVsbCBTcGVlZCBVU0IgdjEuMAp1c2J1czM6IDQ4ME1icHMgSGln aCBTcGVlZCBVU0IgdjIuMAp1Z2VuMC4xOiA8SW50ZWw+IGF0IHVzYnVzMAp1aHViMDogPEludGVs IFVIQ0kgcm9vdCBIVUIsIGNsYXNzIDkvMCwgcmV2IDEuMDAvMS4wMCwgYWRkciAxPiBvbiB1c2J1 czAKdWdlbjEuMTogPEludGVsPiBhdCB1c2J1czEKdWh1YjE6IDxJbnRlbCBVSENJIHJvb3QgSFVC LCBjbGFzcyA5LzAsIHJldiAxLjAwLzEuMDAsIGFkZHIgMT4gb24gdXNidXMxCnVnZW4yLjE6IDxJ bnRlbD4gYXQgdXNidXMyCnVodWIyOiA8SW50ZWwgVUhDSSByb290IEhVQiwgY2xhc3MgOS8wLCBy ZXYgMS4wMC8xLjAwLCBhZGRyIDE+IG9uIHVzYnVzMgp1Z2VuMy4xOiA8SW50ZWw+IGF0IHVzYnVz Mwp1aHViMzogPEludGVsIEVIQ0kgcm9vdCBIVUIsIGNsYXNzIDkvMCwgcmV2IDIuMDAvMS4wMCwg YWRkciAxPiBvbiB1c2J1czMKYWQ0OiA3MTU0MDRNQiA8V0RDIFdENzUwMEFBTFgtMDA5QkEwIDE1 LjAxSDE1PiBhdCBhdGEyLW1hc3RlciBVRE1BMTAwIFNBVEEgM0diL3MKYWRhMCBhdCBhaGNpY2gw IGJ1cyAwIHNjYnVzMCB0YXJnZXQgMCBsdW4gMAphZGEwOiA8U1QzMjUwNDEwQVMgMy5BQUE+IEFU QS03IFNBVEEgMS54IGRldmljZQphZGEwOiAxNTAuMDAwTUIvcyB0cmFuc2ZlcnMgKFNBVEEgMS54 LCBVRE1BNiwgUElPIDgxOTJieXRlcykKYWRhMDogQ29tbWFuZCBRdWV1ZWluZyBlbmFibGVkCmFk YTA6IDIzODQ3NU1CICg0ODgzOTcxNjggNTEyIGJ5dGUgc2VjdG9yczogMTZIIDYzUy9UIDE2Mzgz QykKYWRhMSBhdCBhaGNpY2gxIGJ1cyAwIHNjYnVzMSB0YXJnZXQgMCBsdW4gMAphZGExOiA8U1Qz MjUwNDEwQVMgMy5BQUE+IEFUQS03IFNBVEEgMS54IGRldmljZQphZGExOiAxNTAuMDAwTUIvcyB0 cmFuc2ZlcnMgKFNBVEEgMS54LCBVRE1BNiwgUElPIDgxOTJieXRlcykKYWRhMTogQ29tbWFuZCBR dWV1ZWluZyBlbmFibGVkCmFkYTE6IDIzODQ3NU1CICg0ODgzOTcxNjggNTEyIGJ5dGUgc2VjdG9y czogMTZIIDYzUy9UIDE2MzgzQylhZDY6IDYxMDQ4ME1CIDxXREMgV0Q2NDAxQUFMUy0wMEo3QjEg MDUuMDBLMDU+IGF0IGF0YTMtbWFzdGVyIFVETUExMDAgU0FUQSAzR2IvcwoKYWQxMDogNjEwNDgw TUIgPFdEQyBXRDY0MDFBQUxTLTAwSjdCMSAwNS4wMEswNT4gYXQgYXRhNS1tYXN0ZXIgVURNQTEw MCBTQVRBIDNHYi9zClNNUDogQVAgQ1BVICMxIExhdW5jaGVkIQpSb290IG1vdW50IHdhaXRpbmcg Zm9yOiB1c2J1czMgdXNidXMyIHVzYnVzMSB1c2J1czAKdWh1YjA6IDIgcG9ydHMgd2l0aCAyIHJl bW92YWJsZSwgc2VsZiBwb3dlcmVkCnVodWIxOiAyIHBvcnRzIHdpdGggMiByZW1vdmFibGUsIHNl bGYgcG93ZXJlZAp1aHViMjogMiBwb3J0cyB3aXRoIDIgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQK Um9vdCBtb3VudCB3YWl0aW5nIGZvcjogdXNidXMzCnVodWIzOiA2IHBvcnRzIHdpdGggNiByZW1v dmFibGUsIHNlbGYgcG93ZXJlZApSb290IG1vdW50IHdhaXRpbmcgZm9yOiB1c2J1czMKdWdlbjMu MjogPFNlYWdhdGU+IGF0IHVzYnVzMwp1bWFzczA6IDxTZWFnYXRlIEZyZWVBZ2VudCBHbywgY2xh c3MgMC8wLCByZXYgMi4wMC8xLjM4LCBhZGRyIDI+IG9uIHVzYnVzMwp1bWFzczA6ICBTQ1NJIG92 ZXIgQnVsay1Pbmx5OyBxdWlya3MgPSAweDAwMDAKdWdlbjAuMjogPEFtZXJpY2FuIFBvd2VyIENv bnZlcnNpb24+IGF0IHVzYnVzMAp1bWFzczA6NDowOi0xOiBBdHRhY2hlZCB0byBzY2J1czQKVHJ5 aW5nIHRvIG1vdW50IHJvb3QgZnJvbSB6ZnM6enJvb3QKZGEwIGF0IHVtYXNzLXNpbTAgYnVzIDAg c2NidXM0IHRhcmdldCAwIGx1biAwCmRhMDogPFNlYWdhdGUgRnJlZUFnZW50IEdvIDAxMzg+IEZp eGVkIERpcmVjdCBBY2Nlc3MgU0NTSS00IGRldmljZSAKZGEwOiA0MC4wMDBNQi9zIHRyYW5zZmVy cwpkYTA6IDYxMDQ4ME1CICgxMjUwMjYzNzI2IDUxMiBieXRlIHNlY3RvcnM6IDI1NUggNjNTL1Qg Nzc4MjVDKQpiZ2UwOiBsaW5rIHN0YXRlIGNoYW5nZWQgdG8gVVAKUwpsb2dfc3lzZXZlbnQ6IHR5 cGUgMTkgaXMgbm90IGltcGxlbWVudGVkCmF0YTI6IFNJR05BVFVSRTogZmZmZmZmZmYKYXRhMjog dGltZW91dCB3YWl0aW5nIHRvIGlzc3VlIGNvbW1hbmQKYXRhMjogZXJyb3IgaXNzdWluZyBTRVRG RUFUVVJFUyBTRVQgVFJBTlNGRVIgTU9ERSBjb21tYW5kCmF0YTI6IHRpbWVvdXQgd2FpdGluZyB0 byBpc3N1ZSBjb21tYW5kCmF0YTI6IGVycm9yIGlzc3VpbmcgU0VURkVBVFVSRVMgRU5BQkxFIFJD QUNIRSBjb21tYW5kCmF0YTI6IHRpbWVvdXQgd2FpdGluZyB0byBpc3N1ZSBjb21tYW5kCmF0YTI6 IGVycm9yIGlzc3VpbmcgU0VURkVBVFVSRVMgRU5BQkxFIFdDQUNIRSBjb21tYW5kCmFkNDogV0FS TklORyAtIFNFVF9NVUxUSSB0YXNrcXVldWUgdGltZW91dCAtIGNvbXBsZXRpbmcgcmVxdWVzdCBk aXJlY3RseQphZDQ6IFdBUk5JTkcgLSBXUklURV9ETUE0OCByZXF1ZXVlZCBkdWUgdG8gY2hhbm5l bCByZXNldCBMQkE9MzIxNTU4NzQxCmF0YTI6IFNJR05BVFVSRTogMDAwMDAxMDEKYWQ0OiBXQVJO SU5HIC0gV1JJVEVfRE1BNDggcmVxdWV1ZWQgZHVlIHRvIGNoYW5uZWwgcmVzZXQgTEJBPTMyMTU1 ODg2OQphdGEyOiBGQUlMVVJFIC0gYWxyZWFkeSBhY3RpdmUgRE1BIG9uIHRoaXMgZGV2aWNlCmF0 YTI6IHNldHRpbmcgdXAgRE1BIGZhaWxlZAphdGEyOiBGQUlMVVJFIC0gYWxyZWFkeSBhY3RpdmUg RE1BIG9uIHRoaXMgZGV2aWNlCmF0YTI6IHNldHRpbmcgdXAgRE1BIGZhaWxlZAo= --000e0cd256b2ab11c904a64e1ea9-- From owner-freebsd-stable@FreeBSD.ORG Wed Jun 22 15:24:47 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 805E5106566C for ; Wed, 22 Jun 2011 15:24:47 +0000 (UTC) (envelope-from boydjd@jbip.net) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 66F198FC12 for ; Wed, 22 Jun 2011 15:24:46 +0000 (UTC) Received: by fxm11 with SMTP id 11so1060506fxm.13 for ; Wed, 22 Jun 2011 08:24:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jbip.net; s=google; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=NTQDXLWvajy3YLpAcjuSZKN8+avLVvbQBsj47nLISII=; b=IWqZwJuyd5iUTTpGBQ2KiktmJKYu3i5fdQIcWROUIyNriKMtKRcGJpccr4YbwsHKrW 1AOHbPxo4RliI9/TheCsJHETpnRQ0sjdQSi4hdXhSl+KjQrR2uPBumVZIvPPxruirMSp wIAvoXFRRszQgh+XEUeGzepEDJ5vqxtP9nA1I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=jbip.net; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=N8AtFkmeJHP1L4SticOAIKso9haPtK+Ao9dzxlVx3wYzvNHYRJSszAAE9/q1NNn+fd BQlRniQwUIuxGCoQPvCkftZGg0dRhv+5yrBoy4MnqPcMFJSpJFeVE32Ycj16PfAZf29d gIcw+cCQXnDpbnGe/RxN1RZ0XOdNohO/Gt7+w= Received: by 10.223.97.196 with SMTP id m4mr1010351fan.55.1308756285217; Wed, 22 Jun 2011 08:24:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.25.1 with HTTP; Wed, 22 Jun 2011 08:24:25 -0700 (PDT) In-Reply-To: References: <20110615075754.GA54879@icarus.home.lan> From: Joshua Boyd Date: Wed, 22 Jun 2011 11:24:25 -0400 Message-ID: To: Jack Vogel Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable , "Vogel, Jack" , Jeremy Chadwick Subject: Re: em0 watchdog timeouts on 8-STABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 15:24:47 -0000 :( I don't actually have problems normally with maxing out the throughput of the network. Watchdogs only occur when I've got heavy I/O occurring during ZFS scrubs across 2 mpt devices, at about 700MB/s. And then it doesn't matter what kind of traffic I'm running through em0, it still throws watchdogs. During the first occurrence it was actually pretty minimal traffic, less than 100KB/s. Are there any statistics that would be useful to you if I were to trigger the watchdogs again? On Wed, Jun 22, 2011 at 1:22 AM, Jack Vogel wrote: > I cannot repro this, I used your kernel config, this is on a Dell 1850 btw, > I ran netperf stress from 3 clients, and have seen no watchdogs :( > > Jack > > > > On Tue, Jun 21, 2011 at 7:59 PM, Joshua Boyd wrote: > >> If needed, I can reproduce this on demand. Just need to know what sort of >> statistics are needed when the problem is occurring. I've had to turn off my >> weekly scrubs until I can figure out how to fix this problem. >> >> >> On Wed, Jun 15, 2011 at 8:37 PM, Joshua Boyd wrote: >> >>> In the kernel. Here's my kernel configuration: >>> >>> http://pastebin.com/raw.php?i=4JL814m3 >>> >>> On Wed, Jun 15, 2011 at 8:20 PM, Jack Vogel wrote: >>> >>>> I have hardware now, am working on reproducing this. Just curious, do >>>> you have >>>> the em driver defined in the kernel, or as a module? >>>> >>>> Jack >>>> >>>> >>>> On Wed, Jun 15, 2011 at 2:09 AM, Joshua Boyd wrote: >>>> >>>>> On Wed, Jun 15, 2011 at 3:57 AM, Jeremy Chadwick >>>>> wrote: >>>>> >>>>> > On Wed, Jun 15, 2011 at 03:14:43AM -0400, Joshua Boyd wrote: >>>>> > > I recently updated my server to the latest 8-STABLE, and upgraded >>>>> to v28 >>>>> > > ZFS. I have not had these problems on any other version of 8-STABLE >>>>> or >>>>> > > 7-STABLE, which this box was upgraded from some time ago. >>>>> > > >>>>> > > Now, during my weekly scrub, I get the following messages and em0 >>>>> is >>>>> > > unresponsive: >>>>> > > >>>>> > > Jun 12 03:07:58 foghornleghorn kernel: em0: Watchdog timeout -- >>>>> resetting >>>>> > > Jun 12 03:07:58 foghornleghorn kernel: em0: link state changed to >>>>> DOWN >>>>> > > Jun 12 03:08:01 foghornleghorn kernel: em0: link state changed to >>>>> UP >>>>> > > Jun 12 03:08:47 foghornleghorn kernel: em0: Watchdog timeout -- >>>>> resetting >>>>> > > Jun 12 03:08:47 foghornleghorn kernel: em0: link state changed to >>>>> DOWN >>>>> > > Jun 12 03:08:50 foghornleghorn kernel: em0: link state changed to >>>>> UP >>>>> > > >>>>> > > My scrub is scheduled to start at 03:00:00, so it looks like >>>>> watchdog >>>>> > > timeouts start occurring pretty quickly once I/O ramps up. >>>>> > > >>>>> > > Here's some possibly relevant information, let me know if anything >>>>> else >>>>> > > would be helpful to troubleshoot. >>>>> > > >>>>> > > FreeBSD foghornleghorn.res.openband.net 8.2-STABLE FreeBSD >>>>> 8.2-STABLE >>>>> > #17: >>>>> > > Mon Jun 6 19:40:19 EDT 2011 >>>>> > > root@foghornleghorn.res.openband.net: >>>>> /usr/obj/usr/src/sys/FOGHORNLEGHORN >>>>> > > amd64 >>>>> > > >>>>> > > em0: port >>>>> > 0xe800-0xe83f >>>>> > > mem 0xfebe0000-0xfebfffff,0xfebc0000-0xfebdffff irq 20 at device >>>>> 5.0 on >>>>> > pci7 >>>>> > > >>>>> > > em0@pci0:7:5:0: class=0x020000 card=0x13768086 chip=0x107c8086 >>>>> rev=0x05 >>>>> > > hdr=0x00 >>>>> > > vendor = 'Intel Corporation' >>>>> > > device = 'Gigabit Ethernet Controller (Copper) rev 5 >>>>> (82541PI)' >>>>> > > class = network >>>>> > > subclass = ethernet >>>>> > > >>>>> > > And, the SAS cards: >>>>> > > >>>>> > > dev.mpt.0.%desc: LSILogic SAS/SATA Adapter >>>>> > > dev.mpt.0.%driver: mpt >>>>> > > dev.mpt.0.%location: slot=0 function=0 >>>>> > > dev.mpt.0.%pnpinfo: vendor=0x1000 device=0x0058 subvendor=0x15d9 >>>>> > > subdevice=0xa580 class=0x010000 >>>>> > > dev.mpt.0.%parent: pci1 >>>>> > > dev.mpt.0.debug: 3 >>>>> > > dev.mpt.0.role: 1 >>>>> > > dev.mpt.1.%desc: LSILogic SAS/SATA Adapter >>>>> > > dev.mpt.1.%driver: mpt >>>>> > > dev.mpt.1.%location: slot=0 function=0 >>>>> > > dev.mpt.1.%pnpinfo: vendor=0x1000 device=0x0058 subvendor=0x15d9 >>>>> > > subdevice=0xa580 class=0x010000 >>>>> > > dev.mpt.1.%parent: pci2 >>>>> > > dev.mpt.1.debug: 3 >>>>> > > dev.mpt.1.role: 1 >>>>> > > dev.mpt.2.%desc: LSILogic SAS/SATA Adapter >>>>> > > dev.mpt.2.%driver: mpt >>>>> > > dev.mpt.2.%location: slot=0 function=0 >>>>> > > dev.mpt.2.%pnpinfo: vendor=0x1000 device=0x0058 subvendor=0x1000 >>>>> > > subdevice=0x30a0 class=0x010000 >>>>> > > dev.mpt.2.%parent: pci6 >>>>> > > dev.mpt.2.debug: 3 >>>>> > > dev.mpt.2.role: 1 >>>>> > >>>>> > Please provide output from the following commands (as root): >>>>> > >>>>> > # pciconf -lvcb >>>>> > >>>>> >>>>> hostb0@pci0:0:0:0: class=0x060000 card=0x59561002 chip=0x59561002 >>>>> rev=0x00 >>>>> hdr=0x00 >>>>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>>>> device = 'RD790 GFX Dual Slot' >>>>> class = bridge >>>>> subclass = HOST-PCI >>>>> pcib1@pci0:0:2:0: class=0x060400 card=0x59561002 chip=0x59781002 >>>>> rev=0x00 >>>>> hdr=0x01 >>>>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>>>> device = 'RD790 PCI to PCI bridge (external gfx0 port A)' >>>>> class = bridge >>>>> subclass = PCI-PCI >>>>> pcib2@pci0:0:3:0: class=0x060400 card=0x59561002 chip=0x59791002 >>>>> rev=0x00 >>>>> hdr=0x01 >>>>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>>>> device = 'RD790 PCI to PCI bridge (external gfx0 port B)' >>>>> class = bridge >>>>> subclass = PCI-PCI >>>>> pcib3@pci0:0:4:0: class=0x060400 card=0x59561002 chip=0x597a1002 >>>>> rev=0x00 >>>>> hdr=0x01 >>>>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>>>> device = 'RD790 PCI to PCI bridge (PCIe gpp port A)' >>>>> class = bridge >>>>> subclass = PCI-PCI >>>>> pcib4@pci0:0:6:0: class=0x060400 card=0x59561002 chip=0x597c1002 >>>>> rev=0x00 >>>>> hdr=0x01 >>>>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>>>> device = 'RD790 PCI to PCI bridge (PCIe gpp port C)' >>>>> class = bridge >>>>> subclass = PCI-PCI >>>>> pcib5@pci0:0:7:0: class=0x060400 card=0x59561002 chip=0x597d1002 >>>>> rev=0x00 >>>>> hdr=0x01 >>>>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>>>> device = 'RD790 PCI to PCI bridge (PCIe gpp port D)' >>>>> class = bridge >>>>> subclass = PCI-PCI >>>>> pcib6@pci0:0:11:0: class=0x060400 card=0x59561002 chip=0x59801002 >>>>> rev=0x00 >>>>> hdr=0x01 >>>>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>>>> device = 'RD790 PCI to PCI bridge (external gfx1 port A)' >>>>> class = bridge >>>>> subclass = PCI-PCI >>>>> atapci4@pci0:0:18:0: class=0x01018f card=0x81ef1043 chip=0x43801002 >>>>> rev=0x00 >>>>> hdr=0x00 >>>>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>>>> device = 'IXP SB600 Serial ATA Controller' >>>>> class = mass storage >>>>> subclass = ATA >>>>> ohci0@pci0:0:19:0: class=0x0c0310 card=0x82881043 chip=0x43871002 >>>>> rev=0x00 >>>>> hdr=0x00 >>>>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>>>> device = 'IXP SB600 USB Controller (OHCI0)' >>>>> class = serial bus >>>>> subclass = USB >>>>> ohci1@pci0:0:19:1: class=0x0c0310 card=0x82881043 chip=0x43881002 >>>>> rev=0x00 >>>>> hdr=0x00 >>>>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>>>> device = 'IXP SB600 USB Controller (OHCI1)' >>>>> class = serial bus >>>>> subclass = USB >>>>> ohci2@pci0:0:19:2: class=0x0c0310 card=0x82881043 chip=0x43891002 >>>>> rev=0x00 >>>>> hdr=0x00 >>>>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>>>> device = 'IXP SB600 USB Controller (OHCI2)' >>>>> class = serial bus >>>>> subclass = USB >>>>> ohci3@pci0:0:19:3: class=0x0c0310 card=0x82881043 chip=0x438a1002 >>>>> rev=0x00 >>>>> hdr=0x00 >>>>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>>>> device = 'IXP SB600 USB Controller (OHCI3)' >>>>> class = serial bus >>>>> subclass = USB >>>>> ohci4@pci0:0:19:4: class=0x0c0310 card=0x82881043 chip=0x438b1002 >>>>> rev=0x00 >>>>> hdr=0x00 >>>>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>>>> device = 'IXP SB600 USB Controller (OHCI4)' >>>>> class = serial bus >>>>> subclass = USB >>>>> ehci0@pci0:0:19:5: class=0x0c0320 card=0x82881043 chip=0x43861002 >>>>> rev=0x00 >>>>> hdr=0x00 >>>>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>>>> device = 'IXP SB600 USB Controller (EHCI)' >>>>> class = serial bus >>>>> subclass = USB >>>>> none0@pci0:0:20:0: class=0x0c0500 card=0x82881043 chip=0x43851002 >>>>> rev=0x14 >>>>> hdr=0x00 >>>>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>>>> device = 'ATI SMBus (ATI RD600/RS600)' >>>>> class = serial bus >>>>> subclass = SMBus >>>>> atapci5@pci0:0:20:1: class=0x01018a card=0x82881043 chip=0x438c1002 >>>>> rev=0x00 >>>>> hdr=0x00 >>>>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>>>> device = 'ATI RD600/RS600 IDE Controller (RD600/RS600)' >>>>> class = mass storage >>>>> subclass = ATA >>>>> none1@pci0:0:20:2: class=0x040300 card=0x82881043 chip=0x43831002 >>>>> rev=0x00 >>>>> hdr=0x00 >>>>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>>>> device = 'IXP SB600 High Definition Audio Controller' >>>>> class = multimedia >>>>> subclass = HDA >>>>> isab0@pci0:0:20:3: class=0x060100 card=0x82881043 chip=0x438d1002 >>>>> rev=0x00 >>>>> hdr=0x00 >>>>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>>>> device = 'IXP SB600 PCI to LPC Bridge' >>>>> class = bridge >>>>> subclass = PCI-ISA >>>>> pcib7@pci0:0:20:4: class=0x060401 card=0x00000000 chip=0x43841002 >>>>> rev=0x00 >>>>> hdr=0x01 >>>>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>>>> device = 'IXP SB600 PCI to PCI Bridge' >>>>> class = bridge >>>>> subclass = PCI-PCI >>>>> hostb1@pci0:0:24:0: class=0x060000 card=0x00000000 chip=0x12001022 >>>>> rev=0x00 >>>>> hdr=0x00 >>>>> vendor = 'Advanced Micro Devices (AMD)' >>>>> device = '(Family 10h) Athlon64/Opteron/Sempron HyperTransport >>>>> Technology Configuration' >>>>> class = bridge >>>>> subclass = HOST-PCI >>>>> hostb2@pci0:0:24:1: class=0x060000 card=0x00000000 chip=0x12011022 >>>>> rev=0x00 >>>>> hdr=0x00 >>>>> vendor = 'Advanced Micro Devices (AMD)' >>>>> device = '(Family 10h) Athlon64/Opteron/Sempron Address Map' >>>>> class = bridge >>>>> subclass = HOST-PCI >>>>> hostb3@pci0:0:24:2: class=0x060000 card=0x00000000 chip=0x12021022 >>>>> rev=0x00 >>>>> hdr=0x00 >>>>> vendor = 'Advanced Micro Devices (AMD)' >>>>> device = '(Family 10h) Athlon64/Opteron/Sempron DRAM Controller' >>>>> class = bridge >>>>> subclass = HOST-PCI >>>>> hostb4@pci0:0:24:3: class=0x060000 card=0x00000000 chip=0x12031022 >>>>> rev=0x00 >>>>> hdr=0x00 >>>>> vendor = 'Advanced Micro Devices (AMD)' >>>>> device = '(Family 10h) Athlon64/Opteron/Sempron Miscellaneous >>>>> Control' >>>>> class = bridge >>>>> subclass = HOST-PCI >>>>> hostb5@pci0:0:24:4: class=0x060000 card=0x00000000 chip=0x12041022 >>>>> rev=0x00 >>>>> hdr=0x00 >>>>> vendor = 'Advanced Micro Devices (AMD)' >>>>> device = '(Family 10h) Athlon64/Opteron/Sempron Link Control' >>>>> class = bridge >>>>> subclass = HOST-PCI >>>>> mpt0@pci0:1:0:0: class=0x010000 card=0xa58015d9 chip=0x00581000 >>>>> rev=0x08 >>>>> hdr=0x00 >>>>> vendor = 'LSI Logic (Was: Symbios Logic, NCR)' >>>>> device = 'SAS 3000 series, 8-port with 1068E -StorPort' >>>>> class = mass storage >>>>> subclass = SCSI >>>>> mpt1@pci0:2:0:0: class=0x010000 card=0xa58015d9 chip=0x00581000 >>>>> rev=0x08 >>>>> hdr=0x00 >>>>> vendor = 'LSI Logic (Was: Symbios Logic, NCR)' >>>>> device = 'SAS 3000 series, 8-port with 1068E -StorPort' >>>>> class = mass storage >>>>> subclass = SCSI >>>>> atapci0@pci0:3:0:0: class=0x01018f card=0x612111ab chip=0x612111ab >>>>> rev=0xb1 >>>>> hdr=0x00 >>>>> vendor = 'Marvell Semiconductor (Was: Galileo Technology Ltd)' >>>>> device = '6121 SATA2 Controller' >>>>> class = mass storage >>>>> subclass = ATA >>>>> mskc0@pci0:4:0:0: class=0x020000 card=0x81f81043 chip=0x436411ab >>>>> rev=0x12 >>>>> hdr=0x00 >>>>> vendor = 'Marvell Semiconductor (Was: Galileo Technology Ltd)' >>>>> device = 'Yukon PCI-E Gigabit Ethernet Controller (88E8056)' >>>>> class = network >>>>> subclass = ethernet >>>>> atapci2@pci0:5:0:0: class=0x01018f card=0x612111ab chip=0x612111ab >>>>> rev=0xb2 >>>>> hdr=0x00 >>>>> vendor = 'Marvell Semiconductor (Was: Galileo Technology Ltd)' >>>>> device = '6121 SATA2 Controller' >>>>> class = mass storage >>>>> subclass = ATA >>>>> mpt2@pci0:6:0:0: class=0x010000 card=0x30a01000 chip=0x00581000 >>>>> rev=0x08 >>>>> hdr=0x00 >>>>> vendor = 'LSI Logic (Was: Symbios Logic, NCR)' >>>>> device = 'SAS 3000 series, 8-port with 1068E -StorPort' >>>>> class = mass storage >>>>> subclass = SCSI >>>>> em0@pci0:7:5:0: class=0x020000 card=0x13768086 chip=0x107c8086 >>>>> rev=0x05 >>>>> hdr=0x00 >>>>> vendor = 'Intel Corporation' >>>>> device = 'Gigabit Ethernet Controller (Copper) rev 5 (82541PI)' >>>>> class = network >>>>> subclass = ethernet >>>>> vgapci0@pci0:7:6:0: class=0x030000 card=0x00000000 chip=0x88115333 >>>>> rev=0x44 >>>>> hdr=0x00 >>>>> vendor = 'S3 Graphics Co., Ltd' >>>>> device = '86C732 Trio32, 86C764 Trio64, 86C765 Trio64V+ Rev 01' >>>>> class = display >>>>> subclass = VGA >>>>> none2@pci0:7:8:0: class=0x0c0010 card=0x82941043 chip=0x581111c1 >>>>> rev=0x70 >>>>> hdr=0x00 >>>>> vendor = 'Lucent/Agere Systems (Was: AT&T MicroElectronics)' >>>>> device = '1394A PCI PHY/Link Open Host Ctrlr I/F (FW322)' >>>>> class = serial bus >>>>> subclass = FireWire >>>>> [josh@foghornleghorn /var/log]$ sudo su - >>>>> foghornleghorn# pciconf -lvcb >>>>> hostb0@pci0:0:0:0: class=0x060000 card=0x59561002 chip=0x59561002 >>>>> rev=0x00 >>>>> hdr=0x00 >>>>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>>>> device = 'RD790 GFX Dual Slot' >>>>> class = bridge >>>>> subclass = HOST-PCI >>>>> cap 08[c4] = HT slave >>>>> cap 08[40] = HT retry mode >>>>> cap 08[54] = HT unit ID clumping >>>>> cap 08[9c] = HT unknown d03c >>>>> pcib1@pci0:0:2:0: class=0x060400 card=0x59561002 chip=0x59781002 >>>>> rev=0x00 >>>>> hdr=0x01 >>>>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>>>> device = 'RD790 PCI to PCI bridge (external gfx0 port A)' >>>>> class = bridge >>>>> subclass = PCI-PCI >>>>> cap 01[50] = powerspec 3 supports D0 D3 current D0 >>>>> cap 10[58] = PCI-Express 2 root port max data 128(128) link x4(x8) >>>>> cap 05[a0] = MSI supports 1 message >>>>> cap 0d[b0] = PCI Bridge card=0x59561002 >>>>> cap 08[b8] = HT MSI fixed address window enabled at 0xfee00000 >>>>> ecap 000b[100] = unknown 1 >>>>> ecap 0002[110] = VC 1 max VC0 >>>>> pcib2@pci0:0:3:0: class=0x060400 card=0x59561002 chip=0x59791002 >>>>> rev=0x00 >>>>> hdr=0x01 >>>>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>>>> device = 'RD790 PCI to PCI bridge (external gfx0 port B)' >>>>> class = bridge >>>>> subclass = PCI-PCI >>>>> cap 01[50] = powerspec 3 supports D0 D3 current D0 >>>>> cap 10[58] = PCI-Express 2 root port max data 128(128) link x4(x8) >>>>> cap 05[a0] = MSI supports 1 message >>>>> cap 0d[b0] = PCI Bridge card=0x59561002 >>>>> cap 08[b8] = HT MSI fixed address window enabled at 0xfee00000 >>>>> ecap 000b[100] = unknown 1 >>>>> ecap 0002[110] = VC 1 max VC0 >>>>> pcib3@pci0:0:4:0: class=0x060400 card=0x59561002 chip=0x597a1002 >>>>> rev=0x00 >>>>> hdr=0x01 >>>>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>>>> device = 'RD790 PCI to PCI bridge (PCIe gpp port A)' >>>>> class = bridge >>>>> subclass = PCI-PCI >>>>> cap 01[50] = powerspec 3 supports D0 D3 current D0 >>>>> cap 10[58] = PCI-Express 2 root port max data 128(128) link x1(x2) >>>>> cap 05[a0] = MSI supports 1 message >>>>> cap 0d[b0] = PCI Bridge card=0x59561002 >>>>> cap 08[b8] = HT MSI fixed address window enabled at 0xfee00000 >>>>> ecap 000b[100] = unknown 1 >>>>> ecap 0002[110] = VC 1 max VC0 >>>>> pcib4@pci0:0:6:0: class=0x060400 card=0x59561002 chip=0x597c1002 >>>>> rev=0x00 >>>>> hdr=0x01 >>>>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>>>> device = 'RD790 PCI to PCI bridge (PCIe gpp port C)' >>>>> class = bridge >>>>> subclass = PCI-PCI >>>>> cap 01[50] = powerspec 3 supports D0 D3 current D0 >>>>> cap 10[58] = PCI-Express 2 root port max data 128(128) link x1(x1) >>>>> cap 05[a0] = MSI supports 1 message >>>>> cap 0d[b0] = PCI Bridge card=0x59561002 >>>>> cap 08[b8] = HT MSI fixed address window enabled at 0xfee00000 >>>>> ecap 000b[100] = unknown 1 >>>>> ecap 0002[110] = VC 1 max VC0 >>>>> pcib5@pci0:0:7:0: class=0x060400 card=0x59561002 chip=0x597d1002 >>>>> rev=0x00 >>>>> hdr=0x01 >>>>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>>>> device = 'RD790 PCI to PCI bridge (PCIe gpp port D)' >>>>> class = bridge >>>>> subclass = PCI-PCI >>>>> cap 01[50] = powerspec 3 supports D0 D3 current D0 >>>>> cap 10[58] = PCI-Express 2 root port max data 128(128) link x1(x1) >>>>> cap 05[a0] = MSI supports 1 message >>>>> cap 0d[b0] = PCI Bridge card=0x59561002 >>>>> cap 08[b8] = HT MSI fixed address window enabled at 0xfee00000 >>>>> ecap 000b[100] = unknown 1 >>>>> ecap 0002[110] = VC 1 max VC0 >>>>> pcib6@pci0:0:11:0: class=0x060400 card=0x59561002 chip=0x59801002 >>>>> rev=0x00 >>>>> hdr=0x01 >>>>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>>>> device = 'RD790 PCI to PCI bridge (external gfx1 port A)' >>>>> class = bridge >>>>> subclass = PCI-PCI >>>>> cap 01[50] = powerspec 3 supports D0 D3 current D0 >>>>> cap 10[58] = PCI-Express 2 root port max data 128(128) link x4(x8) >>>>> cap 05[a0] = MSI supports 1 message >>>>> cap 0d[b0] = PCI Bridge card=0x59561002 >>>>> cap 08[b8] = HT MSI fixed address window enabled at 0xfee00000 >>>>> ecap 000b[100] = unknown 1 >>>>> ecap 0002[110] = VC 1 max VC0 >>>>> atapci4@pci0:0:18:0: class=0x01018f card=0x81ef1043 chip=0x43801002 >>>>> rev=0x00 >>>>> hdr=0x00 >>>>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>>>> device = 'IXP SB600 Serial ATA Controller' >>>>> class = mass storage >>>>> subclass = ATA >>>>> bar [10] = type I/O Port, range 32, base 0x5000, size 8, enabled >>>>> bar [14] = type I/O Port, range 32, base 0x4000, size 4, enabled >>>>> bar [18] = type I/O Port, range 32, base 0x3000, size 8, enabled >>>>> bar [1c] = type I/O Port, range 32, base 0x2000, size 4, enabled >>>>> bar [20] = type I/O Port, range 32, base 0x1000, size 16, enabled >>>>> bar [24] = type Memory, range 32, base 0xf71ff800, size 1024, >>>>> enabled >>>>> cap 01[60] = powerspec 2 supports D0 D3 current D0 >>>>> ohci0@pci0:0:19:0: class=0x0c0310 card=0x82881043 chip=0x43871002 >>>>> rev=0x00 >>>>> hdr=0x00 >>>>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>>>> device = 'IXP SB600 USB Controller (OHCI0)' >>>>> class = serial bus >>>>> subclass = USB >>>>> bar [10] = type Memory, range 32, base 0xf71fe000, size 4096, >>>>> enabled >>>>> ohci1@pci0:0:19:1: class=0x0c0310 card=0x82881043 chip=0x43881002 >>>>> rev=0x00 >>>>> hdr=0x00 >>>>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>>>> device = 'IXP SB600 USB Controller (OHCI1)' >>>>> class = serial bus >>>>> subclass = USB >>>>> bar [10] = type Memory, range 32, base 0xf71fd000, size 4096, >>>>> enabled >>>>> ohci2@pci0:0:19:2: class=0x0c0310 card=0x82881043 chip=0x43891002 >>>>> rev=0x00 >>>>> hdr=0x00 >>>>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>>>> device = 'IXP SB600 USB Controller (OHCI2)' >>>>> class = serial bus >>>>> subclass = USB >>>>> bar [10] = type Memory, range 32, base 0xf71fc000, size 4096, >>>>> enabled >>>>> ohci3@pci0:0:19:3: class=0x0c0310 card=0x82881043 chip=0x438a1002 >>>>> rev=0x00 >>>>> hdr=0x00 >>>>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>>>> device = 'IXP SB600 USB Controller (OHCI3)' >>>>> class = serial bus >>>>> subclass = USB >>>>> bar [10] = type Memory, range 32, base 0xf71fb000, size 4096, >>>>> enabled >>>>> ohci4@pci0:0:19:4: class=0x0c0310 card=0x82881043 chip=0x438b1002 >>>>> rev=0x00 >>>>> hdr=0x00 >>>>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>>>> device = 'IXP SB600 USB Controller (OHCI4)' >>>>> class = serial bus >>>>> subclass = USB >>>>> bar [10] = type Memory, range 32, base 0xf71fa000, size 4096, >>>>> enabled >>>>> ehci0@pci0:0:19:5: class=0x0c0320 card=0x82881043 chip=0x43861002 >>>>> rev=0x00 >>>>> hdr=0x00 >>>>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>>>> device = 'IXP SB600 USB Controller (EHCI)' >>>>> class = serial bus >>>>> subclass = USB >>>>> bar [10] = type Memory, range 32, base 0xf71ff000, size 256, >>>>> enabled >>>>> cap 01[c0] = powerspec 2 supports D0 D1 D2 D3 current D0 >>>>> cap 05[d0] = MSI supports 1 message >>>>> cap 0a[e4] = EHCI Debug Port at offset 0xe0 in map 0x14 >>>>> none0@pci0:0:20:0: class=0x0c0500 card=0x82881043 chip=0x43851002 >>>>> rev=0x14 >>>>> hdr=0x00 >>>>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>>>> device = 'ATI SMBus (ATI RD600/RS600)' >>>>> class = serial bus >>>>> subclass = SMBus >>>>> bar [10] = type I/O Port, range 32, base 0xb00, size 16, enabled >>>>> cap 08[b0] = HT MSI fixed address window disabled at 0xfee00000 >>>>> atapci5@pci0:0:20:1: class=0x01018a card=0x82881043 chip=0x438c1002 >>>>> rev=0x00 >>>>> hdr=0x00 >>>>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>>>> device = 'ATI RD600/RS600 IDE Controller (RD600/RS600)' >>>>> class = mass storage >>>>> subclass = ATA >>>>> bar [10] = type I/O Port, range 32, base 0x1f0, size 8, enabled >>>>> bar [14] = type I/O Port, range 32, base 0x3f4, size 1, enabled >>>>> bar [18] = type I/O Port, range 32, base 0x170, size 8, enabled >>>>> bar [1c] = type I/O Port, range 32, base 0x374, size 1, enabled >>>>> bar [20] = type I/O Port, range 32, base 0xff00, size 16, enabled >>>>> none1@pci0:0:20:2: class=0x040300 card=0x82881043 chip=0x43831002 >>>>> rev=0x00 >>>>> hdr=0x00 >>>>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>>>> device = 'IXP SB600 High Definition Audio Controller' >>>>> class = multimedia >>>>> subclass = HDA >>>>> bar [10] = type Memory, range 64, base 0xf71f4000, size 16384, >>>>> enabled >>>>> cap 01[50] = powerspec 2 supports D0 D3 current D0 >>>>> isab0@pci0:0:20:3: class=0x060100 card=0x82881043 chip=0x438d1002 >>>>> rev=0x00 >>>>> hdr=0x00 >>>>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>>>> device = 'IXP SB600 PCI to LPC Bridge' >>>>> class = bridge >>>>> subclass = PCI-ISA >>>>> pcib7@pci0:0:20:4: class=0x060401 card=0x00000000 chip=0x43841002 >>>>> rev=0x00 >>>>> hdr=0x01 >>>>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>>>> device = 'IXP SB600 PCI to PCI Bridge' >>>>> class = bridge >>>>> subclass = PCI-PCI >>>>> hostb1@pci0:0:24:0: class=0x060000 card=0x00000000 chip=0x12001022 >>>>> rev=0x00 >>>>> hdr=0x00 >>>>> vendor = 'Advanced Micro Devices (AMD)' >>>>> device = '(Family 10h) Athlon64/Opteron/Sempron HyperTransport >>>>> Technology Configuration' >>>>> class = bridge >>>>> subclass = HOST-PCI >>>>> cap 08[80] = HT host >>>>> hostb2@pci0:0:24:1: class=0x060000 card=0x00000000 chip=0x12011022 >>>>> rev=0x00 >>>>> hdr=0x00 >>>>> vendor = 'Advanced Micro Devices (AMD)' >>>>> device = '(Family 10h) Athlon64/Opteron/Sempron Address Map' >>>>> class = bridge >>>>> subclass = HOST-PCI >>>>> hostb3@pci0:0:24:2: class=0x060000 card=0x00000000 chip=0x12021022 >>>>> rev=0x00 >>>>> hdr=0x00 >>>>> vendor = 'Advanced Micro Devices (AMD)' >>>>> device = '(Family 10h) Athlon64/Opteron/Sempron DRAM Controller' >>>>> class = bridge >>>>> subclass = HOST-PCI >>>>> hostb4@pci0:0:24:3: class=0x060000 card=0x00000000 chip=0x12031022 >>>>> rev=0x00 >>>>> hdr=0x00 >>>>> vendor = 'Advanced Micro Devices (AMD)' >>>>> device = '(Family 10h) Athlon64/Opteron/Sempron Miscellaneous >>>>> Control' >>>>> class = bridge >>>>> subclass = HOST-PCI >>>>> cap 0f[f0] = unknown >>>>> hostb5@pci0:0:24:4: class=0x060000 card=0x00000000 chip=0x12041022 >>>>> rev=0x00 >>>>> hdr=0x00 >>>>> vendor = 'Advanced Micro Devices (AMD)' >>>>> device = '(Family 10h) Athlon64/Opteron/Sempron Link Control' >>>>> class = bridge >>>>> subclass = HOST-PCI >>>>> mpt0@pci0:1:0:0: class=0x010000 card=0xa58015d9 chip=0x00581000 >>>>> rev=0x08 >>>>> hdr=0x00 >>>>> vendor = 'LSI Logic (Was: Symbios Logic, NCR)' >>>>> device = 'SAS 3000 series, 8-port with 1068E -StorPort' >>>>> class = mass storage >>>>> subclass = SCSI >>>>> bar [10] = type I/O Port, range 32, base 0x6000, size 256, >>>>> disabled >>>>> bar [14] = type Memory, range 64, base 0xf75fc000, size 16384, >>>>> enabled >>>>> bar [1c] = type Memory, range 64, base 0xf75e0000, size 65536, >>>>> enabled >>>>> cap 01[50] = powerspec 2 supports D0 D1 D2 D3 current D0 >>>>> cap 10[68] = PCI-Express 1 endpoint max data 128(4096) link x4(x8) >>>>> cap 05[98] = MSI supports 1 message, 64 bit >>>>> cap 11[b0] = MSI-X supports 1 message in map 0x14 >>>>> ecap 0001[100] = AER 1 1 fatal 1 non-fatal 0 corrected >>>>> mpt1@pci0:2:0:0: class=0x010000 card=0xa58015d9 chip=0x00581000 >>>>> rev=0x08 >>>>> hdr=0x00 >>>>> vendor = 'LSI Logic (Was: Symbios Logic, NCR)' >>>>> device = 'SAS 3000 series, 8-port with 1068E -StorPort' >>>>> class = mass storage >>>>> subclass = SCSI >>>>> bar [10] = type I/O Port, range 32, base 0x7000, size 256, >>>>> disabled >>>>> bar [14] = type Memory, range 64, base 0xf78fc000, size 16384, >>>>> enabled >>>>> bar [1c] = type Memory, range 64, base 0xf78e0000, size 65536, >>>>> enabled >>>>> cap 01[50] = powerspec 2 supports D0 D1 D2 D3 current D0 >>>>> cap 10[68] = PCI-Express 1 endpoint max data 128(4096) link x4(x8) >>>>> cap 05[98] = MSI supports 1 message, 64 bit >>>>> cap 11[b0] = MSI-X supports 1 message in map 0x14 >>>>> ecap 0001[100] = AER 1 1 fatal 1 non-fatal 0 corrected >>>>> atapci0@pci0:3:0:0: class=0x01018f card=0x612111ab chip=0x612111ab >>>>> rev=0xb1 >>>>> hdr=0x00 >>>>> vendor = 'Marvell Semiconductor (Was: Galileo Technology Ltd)' >>>>> device = '6121 SATA2 Controller' >>>>> class = mass storage >>>>> subclass = ATA >>>>> bar [10] = type I/O Port, range 32, base 0x9800, size 8, enabled >>>>> bar [14] = type I/O Port, range 32, base 0x9400, size 4, enabled >>>>> bar [18] = type I/O Port, range 32, base 0x9000, size 8, enabled >>>>> bar [1c] = type I/O Port, range 32, base 0x8800, size 4, enabled >>>>> bar [20] = type I/O Port, range 32, base 0x8400, size 16, enabled >>>>> bar [24] = type Memory, range 32, base 0xf79ffc00, size 1024, >>>>> enabled >>>>> cap 01[48] = powerspec 2 supports D0 D1 D3 current D0 >>>>> cap 05[50] = MSI supports 1 message >>>>> cap 10[e0] = PCI-Express 1 legacy endpoint max data 128(128) link >>>>> x1(x1) >>>>> ecap 0001[100] = AER 1 0 fatal 0 non-fatal 2 corrected >>>>> mskc0@pci0:4:0:0: class=0x020000 card=0x81f81043 chip=0x436411ab >>>>> rev=0x12 >>>>> hdr=0x00 >>>>> vendor = 'Marvell Semiconductor (Was: Galileo Technology Ltd)' >>>>> device = 'Yukon PCI-E Gigabit Ethernet Controller (88E8056)' >>>>> class = network >>>>> subclass = ethernet >>>>> bar [10] = type Memory, range 64, base 0xf7afc000, size 16384, >>>>> enabled >>>>> bar [18] = type I/O Port, range 32, base 0xa800, size 256, enabled >>>>> cap 01[48] = powerspec 3 supports D0 D1 D2 D3 current D0 >>>>> cap 03[50] = VPD >>>>> cap 05[5c] = MSI supports 1 message, 64 bit enabled with 1 message >>>>> cap 10[e0] = PCI-Express 1 legacy endpoint max data 128(128) link >>>>> x1(x1) >>>>> ecap 0001[100] = AER 1 0 fatal 0 non-fatal 1 corrected >>>>> atapci2@pci0:5:0:0: class=0x01018f card=0x612111ab chip=0x612111ab >>>>> rev=0xb2 >>>>> hdr=0x00 >>>>> vendor = 'Marvell Semiconductor (Was: Galileo Technology Ltd)' >>>>> device = '6121 SATA2 Controller' >>>>> class = mass storage >>>>> subclass = ATA >>>>> bar [10] = type I/O Port, range 32, base 0xc800, size 8, enabled >>>>> bar [14] = type I/O Port, range 32, base 0xc400, size 4, enabled >>>>> bar [18] = type I/O Port, range 32, base 0xc000, size 8, enabled >>>>> bar [1c] = type I/O Port, range 32, base 0xb800, size 4, enabled >>>>> bar [20] = type I/O Port, range 32, base 0xb400, size 16, enabled >>>>> bar [24] = type Memory, range 32, base 0xf7bffc00, size 1024, >>>>> enabled >>>>> cap 01[48] = powerspec 2 supports D0 D1 D3 current D0 >>>>> cap 05[50] = MSI supports 1 message >>>>> cap 10[e0] = PCI-Express 1 legacy endpoint max data 128(128) link >>>>> x1(x1) >>>>> ecap 0001[100] = AER 1 0 fatal 0 non-fatal 1 corrected >>>>> mpt2@pci0:6:0:0: class=0x010000 card=0x30a01000 chip=0x00581000 >>>>> rev=0x08 >>>>> hdr=0x00 >>>>> vendor = 'LSI Logic (Was: Symbios Logic, NCR)' >>>>> device = 'SAS 3000 series, 8-port with 1068E -StorPort' >>>>> class = mass storage >>>>> subclass = SCSI >>>>> bar [10] = type I/O Port, range 32, base 0xd000, size 256, >>>>> disabled >>>>> bar [14] = type Memory, range 64, base 0xf7ffc000, size 16384, >>>>> enabled >>>>> bar [1c] = type Memory, range 64, base 0xf7fe0000, size 65536, >>>>> enabled >>>>> cap 01[50] = powerspec 2 supports D0 D1 D2 D3 current D0 >>>>> cap 10[68] = PCI-Express 1 endpoint max data 128(4096) link x4(x8) >>>>> cap 05[98] = MSI supports 1 message, 64 bit >>>>> cap 11[b0] = MSI-X supports 1 message in map 0x14 >>>>> ecap 0001[100] = AER 1 1 fatal 1 non-fatal 0 corrected >>>>> em0@pci0:7:5:0: class=0x020000 card=0x13768086 chip=0x107c8086 >>>>> rev=0x05 >>>>> hdr=0x00 >>>>> vendor = 'Intel Corporation' >>>>> device = 'Gigabit Ethernet Controller (Copper) rev 5 (82541PI)' >>>>> class = network >>>>> subclass = ethernet >>>>> bar [10] = type Memory, range 32, base 0xfebe0000, size 131072, >>>>> enabled >>>>> bar [14] = type Memory, range 32, base 0xfebc0000, size 131072, >>>>> enabled >>>>> bar [18] = type I/O Port, range 32, base 0xe800, size 64, enabled >>>>> cap 01[dc] = powerspec 2 supports D0 D3 current D0 >>>>> cap 07[e4] = PCI-X supports 2048 burst read, 1 split transaction >>>>> vgapci0@pci0:7:6:0: class=0x030000 card=0x00000000 chip=0x88115333 >>>>> rev=0x44 >>>>> hdr=0x00 >>>>> vendor = 'S3 Graphics Co., Ltd' >>>>> device = '86C732 Trio32, 86C764 Trio64, 86C765 Trio64V+ Rev 01' >>>>> class = display >>>>> subclass = VGA >>>>> bar [10] = type Memory, range 32, base 0xf8000000, size 67108864, >>>>> enabled >>>>> none2@pci0:7:8:0: class=0x0c0010 card=0x82941043 chip=0x581111c1 >>>>> rev=0x70 >>>>> hdr=0x00 >>>>> vendor = 'Lucent/Agere Systems (Was: AT&T MicroElectronics)' >>>>> device = '1394A PCI PHY/Link Open Host Ctrlr I/F (FW322)' >>>>> class = serial bus >>>>> subclass = FireWire >>>>> bar [10] = type Memory, range 32, base 0xfeb8f000, size 4096, >>>>> enabled >>>>> cap 01[44] = powerspec 2 supports D0 D1 D2 D3 current D0 >>>>> >>>>> >>>>> >>>>> > # vmstat -i >>>>> > >>>>> >>>>> interrupt total rate >>>>> irq9: acpi0 1 0 >>>>> irq16: atapci0+ 2 0 >>>>> irq17: ohci1 ohci3 3 0 >>>>> irq18: mpt0 ohci2+ 7066718 31 >>>>> irq19: mpt1 atapci* 7798877 34 >>>>> irq20: em0 11715792 51 >>>>> irq22: atapci4 628883 2 >>>>> cpu0: timer 455853831 1999 >>>>> irq256: mskc0 97098730 425 >>>>> cpu1: timer 455845190 1999 >>>>> Total 1036008027 4544 >>>>> >>>>> >>>>> >>>>> > # sysctl -a | grep msi >>>>> > >>>>> >>>>> hw.pci.honor_msi_blacklist: 1 >>>>> hw.pci.enable_msix: 1 >>>>> hw.pci.enable_msi: 1 >>>>> >>>>> >>>>> >>>>> > # dmesg >>>>> > >>>>> >>>>> Copyright (c) 1992-2011 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 8.2-STABLE #17: Mon Jun 6 19:40:19 EDT 2011 >>>>> root@foghornleghorn.res.openband.net: >>>>> /usr/obj/usr/src/sys/FOGHORNLEGHORN >>>>> amd64 >>>>> Timecounter "i8254" frequency 1193182 Hz quality 0 >>>>> CPU: AMD Phenom(tm) II X2 555 Processor (3209.77-MHz K8-class CPU) >>>>> Origin = "AuthenticAMD" Id = 0x100f43 Family = 10 Model = 4 >>>>> Stepping = >>>>> 3 >>>>> >>>>> >>>>> Features=0x178bfbff >>>>> Features2=0x802009 >>>>> AMD >>>>> >>>>> Features=0xee500800 >>>>> AMD >>>>> >>>>> Features2=0x37ff >>>>> TSC: P-state invariant >>>>> real memory = 8589934592 (8192 MB) >>>>> avail memory = 8257736704 (7875 MB) >>>>> ACPI APIC Table: <092310 OEMAPIC > >>>>> FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs >>>>> FreeBSD/SMP: 1 package(s) x 2 core(s) >>>>> cpu0 (BSP): APIC ID: 0 >>>>> cpu1 (AP): APIC ID: 1 >>>>> ioapic0 irqs 0-23 on motherboard >>>>> acpi0: <092310 OEMRSDT> on motherboard >>>>> acpi0: [ITHREAD] >>>>> acpi0: Power Button (fixed) >>>>> acpi0: reservation of fee00000, 1000 (3) failed >>>>> acpi0: reservation of ffb80000, 80000 (3) failed >>>>> acpi0: reservation of fff00000, 100000 (3) failed >>>>> acpi0: reservation of 0, a0000 (3) failed >>>>> acpi0: reservation of 100000, dff00000 (3) failed >>>>> Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 >>>>> acpi_timer0: <32-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 >>>>> cpu0: on acpi0 >>>>> cpu1: on acpi0 >>>>> acpi_hpet0: iomem 0xfed00000-0xfed003ff on >>>>> acpi0 >>>>> Timecounter "HPET" frequency 14318180 Hz quality 900 >>>>> pcib0: port 0xcf8-0xcff on acpi0 >>>>> pci0: on pcib0 >>>>> pcib1: irq 18 at device 2.0 on pci0 >>>>> pci1: on pcib1 >>>>> mpt0: port 0x6000-0x60ff mem >>>>> 0xf75fc000-0xf75fffff,0xf75e0000-0xf75effff irq 18 at device 0.0 on >>>>> pci1 >>>>> mpt0: [ITHREAD] >>>>> mpt0: MPI Version=1.5.20.0 >>>>> pcib2: irq 19 at device 3.0 on pci0 >>>>> pci2: on pcib2 >>>>> mpt1: port 0x7000-0x70ff mem >>>>> 0xf78fc000-0xf78fffff,0xf78e0000-0xf78effff irq 19 at device 0.0 on >>>>> pci2 >>>>> mpt1: [ITHREAD] >>>>> mpt1: MPI Version=1.5.20.0 >>>>> pcib3: irq 16 at device 4.0 on pci0 >>>>> pci3: on pcib3 >>>>> atapci0: port >>>>> 0x9800-0x9807,0x9400-0x9403,0x9000-0x9007,0x8800-0x8803,0x8400-0x840f >>>>> mem >>>>> 0xf79ffc00-0xf79fffff irq 16 at device 0.0 on pci3 >>>>> atapci0: [ITHREAD] >>>>> atapci1: on atapci0 >>>>> atapci1: [ITHREAD] >>>>> atapci1: AHCI v1.00 controller with 3 3Gbps ports, PM supported >>>>> ata2: on atapci1 >>>>> ata2: [ITHREAD] >>>>> ata3: on atapci1 >>>>> ata3: [ITHREAD] >>>>> ata4: on atapci0 >>>>> ata4: [ITHREAD] >>>>> pcib4: irq 18 at device 6.0 on pci0 >>>>> pci4: on pcib4 >>>>> mskc0: port 0xa800-0xa8ff mem >>>>> 0xf7afc000-0xf7afffff irq 18 at device 0.0 on pci4 >>>>> msk0: >>>>> on >>>>> mskc0 >>>>> msk0: Ethernet address: 00:1f:c6:e9:f8:7c >>>>> miibus0: on msk0 >>>>> e1000phy0: PHY 0 on miibus0 >>>>> e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, >>>>> 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow >>>>> mskc0: [ITHREAD] >>>>> pcib5: irq 19 at device 7.0 on pci0 >>>>> pci5: on pcib5 >>>>> atapci2: port >>>>> 0xc800-0xc807,0xc400-0xc403,0xc000-0xc007,0xb800-0xb803,0xb400-0xb40f >>>>> mem >>>>> 0xf7bffc00-0xf7bfffff irq 19 at device 0.0 on pci5 >>>>> atapci2: [ITHREAD] >>>>> atapci3: on atapci2 >>>>> atapci3: [ITHREAD] >>>>> atapci3: AHCI v1.00 controller with 3 3Gbps ports, PM supported >>>>> ata5: on atapci3 >>>>> ata5: [ITHREAD] >>>>> ata6: on atapci3 >>>>> ata6: [ITHREAD] >>>>> ata7: on atapci2 >>>>> ata7: [ITHREAD] >>>>> pcib6: irq 19 at device 11.0 on pci0 >>>>> pci6: on pcib6 >>>>> mpt2: port 0xd000-0xd0ff mem >>>>> 0xf7ffc000-0xf7ffffff,0xf7fe0000-0xf7feffff irq 19 at device 0.0 on >>>>> pci6 >>>>> mpt2: [ITHREAD] >>>>> mpt2: MPI Version=1.5.19.0 >>>>> atapci4: port >>>>> 0x5000-0x5007,0x4000-0x4003,0x3000-0x3007,0x2000-0x2003,0x1000-0x100f >>>>> mem >>>>> 0xf71ff800-0xf71ffbff irq 22 at device 18.0 on pci0 >>>>> atapci4: [ITHREAD] >>>>> atapci4: AHCI v1.10 controller with 4 3Gbps ports, PM supported >>>>> ata8: on atapci4 >>>>> ata8: port is not ready (timeout 0ms) tfd = 000001d0 >>>>> ata8: software reset clear timeout >>>>> ata8: [ITHREAD] >>>>> ata9: on atapci4 >>>>> ata9: [ITHREAD] >>>>> ata10: on atapci4 >>>>> ata10: [ITHREAD] >>>>> ata11: on atapci4 >>>>> ata11: [ITHREAD] >>>>> ohci0: mem 0xf71fe000-0xf71fefff irq 16 >>>>> at >>>>> device 19.0 on pci0 >>>>> ohci0: [ITHREAD] >>>>> usbus0: on ohci0 >>>>> ohci1: mem 0xf71fd000-0xf71fdfff irq 17 >>>>> at >>>>> device 19.1 on pci0 >>>>> ohci1: [ITHREAD] >>>>> usbus1: on ohci1 >>>>> ohci2: mem 0xf71fc000-0xf71fcfff irq 18 >>>>> at >>>>> device 19.2 on pci0 >>>>> ohci2: [ITHREAD] >>>>> usbus2: on ohci2 >>>>> ohci3: mem 0xf71fb000-0xf71fbfff irq 17 >>>>> at >>>>> device 19.3 on pci0 >>>>> ohci3: [ITHREAD] >>>>> usbus3: on ohci3 >>>>> ohci4: mem 0xf71fa000-0xf71fafff irq 18 >>>>> at >>>>> device 19.4 on pci0 >>>>> ohci4: [ITHREAD] >>>>> usbus4: on ohci4 >>>>> ehci0: mem 0xf71ff000-0xf71ff0ff >>>>> irq 19 >>>>> at device 19.5 on pci0 >>>>> ehci0: [ITHREAD] >>>>> ehci0: AMD SB600/700 quirk applied >>>>> usbus5: EHCI version 1.0 >>>>> usbus5: on ehci0 >>>>> pci0: at device 20.0 (no driver attached) >>>>> atapci5: port >>>>> 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xff00-0xff0f at device 20.1 on >>>>> pci0 >>>>> ata0: on atapci5 >>>>> ata0: [ITHREAD] >>>>> pci0: at device 20.2 (no driver attached) >>>>> isab0: at device 20.3 on pci0 >>>>> isa0: on isab0 >>>>> pcib7: at device 20.4 on pci0 >>>>> pci7: on pcib7 >>>>> em0: port >>>>> 0xe800-0xe83f >>>>> mem 0xfebe0000-0xfebfffff,0xfebc0000-0xfebdffff irq 20 at device 5.0 on >>>>> pci7 >>>>> em0: [FILTER] >>>>> em0: Ethernet address: 00:1b:21:4e:e5:2e >>>>> vgapci0: mem 0xf8000000-0xfbffffff at device >>>>> 6.0 on >>>>> pci7 >>>>> pci7: at device 8.0 (no driver attached) >>>>> acpi_button0: on acpi0 >>>>> atrtc0: port 0x70-0x71 irq 8 on acpi0 >>>>> acpi_hpet1: iomem 0xfed00000-0xfed003ff on >>>>> acpi0 >>>>> device_attach: acpi_hpet1 attach returned 12 >>>>> uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 >>>>> uart0: [FILTER] >>>>> orm0: at iomem >>>>> 0xc0000-0xc7fff,0xc8000-0xc87ff,0xc8800-0xc97ff on isa0 >>>>> sc0: at flags 0x100 on isa0 >>>>> sc0: VGA <16 virtual consoles, flags=0x300> >>>>> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on >>>>> isa0 >>>>> acpi_throttle0: on cpu0 >>>>> acpi_throttle0: CLK_VAL field overlaps THT_EN bit >>>>> device_attach: acpi_throttle0 attach returned 6 >>>>> hwpstate0: on cpu0 >>>>> Timecounters tick every 1.000 msec >>>>> usbus0: 12Mbps Full Speed USB v1.0 >>>>> usbus1: 12Mbps Full Speed USB v1.0 >>>>> usbus2: 12Mbps Full Speed USB v1.0 >>>>> usbus3: 12Mbps Full Speed USB v1.0 >>>>> usbus4: 12Mbps Full Speed USB v1.0 >>>>> usbus5: 480Mbps High Speed USB v2.0 >>>>> ugen0.1: at usbus0 >>>>> uhub0: on usbus0 >>>>> ugen1.1: at usbus1 >>>>> uhub1: on usbus1 >>>>> ugen2.1: at usbus2 >>>>> uhub2: on usbus2 >>>>> ugen3.1: at usbus3 >>>>> uhub3: on usbus3 >>>>> ugen4.1: at usbus4 >>>>> uhub4: on usbus4 >>>>> ugen5.1: at usbus5 >>>>> uhub5: on usbus5 >>>>> ad16: 476940MB at ata8-master UDMA100 SATA >>>>> 3Gb/s >>>>> uhub0: 2 ports with 2 removable, self powered >>>>> uhub1: 2 ports with 2 removable, self powered >>>>> uhub2: 2 ports with 2 removable, self powered >>>>> uhub3: 2 ports with 2 removable, self powered >>>>> uhub4: 2 ports with 2 removable, self powered >>>>> da8 at mpt0 bus 0 scbus0 target 0 lun 0 >>>>> da8: Fixed Direct Access SCSI-5 device >>>>> da8: 300.000MB/s transfers >>>>> da8: Command Queueing enabled >>>>> da8: 953869MB (1953525168 512 byte sectors: 255H 63S/T 121601C) >>>>> da9 at mpt0 bus 0 scbus0 target 1 lun 0 >>>>> da9: Fixed Direct Access SCSI-5 device >>>>> da9: 300.000MB/s transfers >>>>> da9: Command Queueing enabled >>>>> da9: 953869MB (1953525168 512 byte sectors: 255H 63S/T 121601C) >>>>> da10 at mpt0 bus 0 scbus0 target 2 lun 0 >>>>> da10: Fixed Direct Access SCSI-5 device >>>>> da10: 300.000MB/s transfers >>>>> da10: Command Queueing enabled >>>>> da10: 953869MB (1953525168 512 byte sectors: 255H 63S/T 121601C) >>>>> da11 at mpt0 bus 0 scbus0 target 3 lun 0 >>>>> da11: Fixed Direct Access SCSI-5 device >>>>> da11: 300.000MB/s transfers >>>>> da11: Command Queueing enabled >>>>> da11: 953869MB (1953525168 512 byte sectors: 255H 63S/T 121601C) >>>>> da12 at mpt0 bus 0 scbus0 target 4 lun 0 >>>>> da12: Fixed Direct Access SCSI-5 device >>>>> da12: 300.000MB/s transfers >>>>> da12: Command Queueing enabled >>>>> da12: 953869MB (1953525168 512 byte sectors: 255H 63S/T 121601C) >>>>> da13 at mpt0 bus 0 scbus0 target 5 lun 0 >>>>> da13: Fixed Direct Access SCSI-5 device >>>>> da13: 300.000MB/s transfers >>>>> da13: Command Queueing enabled >>>>> da13: 953869MB (1953525168 512 byte sectors: 255H 63S/T 121601C) >>>>> da14 at mpt0 bus 0 scbus0 target 6 lun 0 >>>>> da14: Fixed Direct Access SCSI-5 device >>>>> da14: 300.000MB/s transfers >>>>> da14: Command Queueing enabled >>>>> da14: 953869MB (1953525168 512 byte sectors: 255H 63S/T 121601C) >>>>> da0 at mpt1 bus 0 scbus1 target 0 lun 0 >>>>> da0: Fixed Direct Access SCSI-5 device >>>>> da0: 300.000MB/s transfers >>>>> da0: Command Queueing enabled >>>>> da0: 1907729MB (3907029168 512 byte sectors: 255H 63S/T 243201C) >>>>> da1 at mpt1 bus 0 scbus1 target 1 lun 0 >>>>> da1: Fixed Direct Access SCSI-5 device >>>>> da1: 300.000MB/s transfers >>>>> da1: Command Queueing enabled >>>>> da1: 1907729MB (3907029168 512 byte sectors: 255H 63S/T 243201C) >>>>> da2 at mpt1 bus 0 scbus1 target 2 lun 0 >>>>> da2: Fixed Direct Access SCSI-5 device >>>>> da2: 300.000MB/s transfers >>>>> da2: Command Queueing enabled >>>>> da2: 1907729MB (3907029168 512 byte sectors: 255H 63S/T 243201C) >>>>> da3 at mpt1 bus 0 scbus1 target 3 lun 0 >>>>> da3: Fixed Direct Access SCSI-5 device >>>>> da3: 300.000MB/s transfers >>>>> da3: Command Queueing enabled >>>>> da3: 1907729MB (3907029168 512 byte sectors: 255H 63S/T 243201C) >>>>> da4 at mpt1 bus 0 scbus1 target 4 lun 0 >>>>> da4: Fixed Direct Access SCSI-5 device >>>>> da4: 300.000MB/s transfers >>>>> da4: Command Queueing enabled >>>>> da4: 1907729MB (3907029168 512 byte sectors: 255H 63S/T 243201C) >>>>> da5 at mpt1 bus 0 scbus1 target 5 lun 0 >>>>> da5: Fixed Direct Access SCSI-5 device >>>>> da5: 300.000MB/s transfers >>>>> da5: Command Queueing enabled >>>>> da5: 953869MB (1953525168 512 byte sectors: 255H 63S/T 121601C) >>>>> da6 at mpt1 bus 0 scbus1 target 6 lun 0 >>>>> da6: Fixed Direct Access SCSI-5 device >>>>> da6: 300.000MB/s transfers >>>>> da6: Command Queueing enabled >>>>> da6: 953869MB (1953525168 512 byte sectors: 255H 63S/T 121601C) >>>>> da7 at mpt1 bus 0 scbus1 target 7 lun 0 >>>>> da7: Fixed Direct Access SCSI-5 device >>>>> da7: 300.000MB/s transfers >>>>> da7: Command Queueing enabled >>>>> da7: 953869MB (1953525168 512 byte sectors: 255H 63S/T 121601C) >>>>> SMP: AP CPU #1 Launched! >>>>> uhub5: 10 ports with 10 removable, self powered >>>>> GEOM: da7: geometry does not match label (16h,63s != 255h,63s). >>>>> Trying to mount root from ufs:/dev/ad16s1a >>>>> WARNING: / was not properly dismounted >>>>> ZFS filesystem version 5 >>>>> ZFS storage pool version 28 >>>>> WARNING: /tmp was not properly dismounted >>>>> WARNING: /usr was not properly dismounted >>>>> WARNING: /var was not properly dismounted >>>>> 0 >>>>> mpt1: request 0xffffff80002c57f0:2369 timed out for ccb >>>>> 0xffffff00063bb000 >>>>> (req->ccb 0xffffff00063bb000) >>>>> mpt1: attempting to abort req 0xffffff80002c57f0:2369 function 0 >>>>> mpt1: mpt_wait_req(1) timed out >>>>> mpt1: mpt_recover_commands: abort timed-out. Resetting controller >>>>> mpt1: mpt_cam_event: 0x80 >>>>> mpt1: mpt_cam_event: 0x80 >>>>> mpt1: completing timedout/aborted req 0xffffff80002c57f0:2369 >>>>> mpt1: mpt_cam_event: 0x16 >>>>> mpt1: mpt_cam_event: 0x12 >>>>> mpt1: mpt_cam_event: 0x12 >>>>> mpt1: mpt_cam_event: 0x12 >>>>> mpt1: mpt_cam_event: 0x12 >>>>> mpt1: mpt_cam_event: 0x12 >>>>> mpt1: mpt_cam_event: 0x12 >>>>> mpt1: mpt_cam_event: 0x12 >>>>> mpt1: mpt_cam_event: 0x12 >>>>> mpt1: mpt_cam_event: 0x16 >>>>> mpt1: request 0xffffff80002c5c70:2375 timed out for ccb >>>>> 0xffffff00063bb000 >>>>> (req->ccb 0xffffff00063bb000) >>>>> mpt1: attempting to abort req 0xffffff80002c5c70:2375 function 0 >>>>> mpt1: completing timedout/aborted req 0xffffff80002c5c70:2375 >>>>> mpt1: >>>>> abort of req 0xffffff80002c5c70:0 completed >>>>> mpt1: mpt_cam_event: 0x16 >>>>> mpt1: mpt_cam_event: 0x16 >>>>> mpt1: request 0xffffff80002c5fd0:2379 timed out for ccb >>>>> 0xffffff00063bb000 >>>>> (req->ccb 0xffffff00063bb000) >>>>> mpt1: attempting to abort req 0xffffff80002c5fd0:2379 function 0 >>>>> mpt1: completing timedout/aborted req 0xffffff80002c5fd0:2379 >>>>> mpt1: >>>>> abort of req 0xffffff80002c5fd0:0 completed >>>>> mpt1: mpt_cam_event: 0x16 >>>>> mpt1: mpt_cam_event: 0x16 >>>>> mpt1: request 0xffffff80002c6210:2383 timed out for ccb >>>>> 0xffffff00063bb000 >>>>> (req->ccb 0xffffff00063bb000) >>>>> mpt1: attempting to abort req 0xffffff80002c6210:2383 function 0 >>>>> mpt1: completing timedout/aborted req 0xffffff80002c6210:2383 >>>>> mpt1: >>>>> abort of req 0xffffff80002c6210:0 completed >>>>> mpt1: mpt_cam_event: 0x16 >>>>> mpt1: mpt_cam_event: 0x16 >>>>> mpt1: request 0xffffff80002c6180:2387 timed out for ccb >>>>> 0xffffff00063bb000 >>>>> (req->ccb 0xffffff00063bb000) >>>>> mpt1: attempting to abort req 0xffffff80002c6180:2387 function 0 >>>>> mpt1: completing timedout/aborted req 0xffffff80002c6180:2387 >>>>> mpt1: >>>>> abort of req 0xffffff80002c6180:0 completed >>>>> mpt1: mpt_cam_event: 0x16 >>>>> mpt1: mpt_cam_event: 0x16 >>>>> mpt1: request 0xffffff80002c62a0:2391 timed out for ccb >>>>> 0xffffff00063bb000 >>>>> (req->ccb 0xffffff00063bb000) >>>>> mpt1: attempting to abort req 0xffffff80002c62a0:2391 function 0 >>>>> mpt1: completing timedout/aborted req 0xffffff80002c62a0:2391 >>>>> mpt1: >>>>> abort of req 0xffffff80002c62a0:0 completed >>>>> mpt1: mpt_cam_event: 0x16 >>>>> mpt1: mpt_cam_event: 0x16 >>>>> mpt1: request 0xffffff80002c6720:2395 timed out for ccb >>>>> 0xffffff00063bb000 >>>>> (req->ccb 0xffffff00063bb000) >>>>> mpt1: attempting to abort req 0xffffff80002c6720:2395 function 0 >>>>> mpt1: completing timedout/aborted req 0xffffff80002c6720:2395 >>>>> mpt1: >>>>> abort of req 0xffffff80002c6720:0 completed >>>>> mpt1: mpt_cam_event: 0x16 >>>>> mpt1: mpt_cam_event: 0x16 >>>>> mpt1: request 0xffffff80002c67b0:2399 timed out for ccb >>>>> 0xffffff00063bb000 >>>>> (req->ccb 0xffffff00063bb000) >>>>> mpt1: attempting to abort req 0xffffff80002c67b0:2399 function 0 >>>>> mpt1: completing timedout/aborted req 0xffffff80002c67b0:2399 >>>>> mpt1: >>>>> abort of req 0xffffff80002c67b0:0 completed >>>>> mpt1: mpt_cam_event: 0x16 >>>>> mpt1: mpt_cam_event: 0x16 >>>>> mpt0: request 0xffffff80002a69e0:2082 timed out for ccb >>>>> 0xffffff0006389800 >>>>> (req->ccb 0xffffff0006389800) >>>>> mpt0: attempting to abort req 0xffffff80002a69e0:2082 function 0 >>>>> mpt0: completing timedout/aborted req 0xffffff80002a69e0:2082 >>>>> mpt0: abort of req 0xffffff80002a69e0:0 completed >>>>> mpt0: mpt_cam_event: 0x16 >>>>> mpt0: mpt_cam_event: 0x16 >>>>> mpt0: request 0xffffff80002a6c20:2086 timed out for ccb >>>>> 0xffffff0006389800 >>>>> (req->ccb 0xffffff0006389800) >>>>> mpt0: attempting to abort req 0xffffff80002a6c20:2086 function 0 >>>>> mpt0: completing timedout/aborted req 0xffffff80002a6c20:2086 >>>>> mpt0: abort of req 0xffffff80002a6c20:0 completed >>>>> mpt0: mpt_cam_event: 0x16 >>>>> mpt0: mpt_cam_event: 0x16 >>>>> mpt0: request 0xffffff80002a6cb0:2090 timed out for ccb >>>>> 0xffffff0006389800 >>>>> (req->ccb 0xffffff0006389800) >>>>> mpt0: attempting to abort req 0xffffff80002a6cb0:2090 function 0 >>>>> mpt0: completing timedout/aborted req 0xffffff80002a6cb0:2090 >>>>> mpt0: abort of req 0xffffff80002a6cb0:0 completed >>>>> mpt0: mpt_cam_event: 0x16 >>>>> mpt0: mpt_cam_event: 0x16 >>>>> mpt0: request 0xffffff80002a6b90:2094 timed out for ccb >>>>> 0xffffff0006389800 >>>>> (req->ccb 0xffffff0006389800) >>>>> mpt0: attempting to abort req 0xffffff80002a6b90:2094 function 0 >>>>> mpt0: completing timedout/aborted req 0xffffff80002a6b90:2094 >>>>> mpt0: abort of req 0xffffff80002a6b90:0 completed >>>>> mpt0: mpt_cam_event: 0x16 >>>>> mpt0: mpt_cam_event: 0x16 >>>>> tun0: link state changed to UP >>>>> (da8:mpt0:0:0:0): READ(10). CDB: 28 0 3e e2 6f 56 0 0 1 0 >>>>> (da8:mpt0:0:0:0): CAM status: SCSI Status Error >>>>> (da8:mpt0:0:0:0): SCSI status: Check Condition >>>>> (da8:mpt0:0:0:0): SCSI sense: UNIT ATTENTION asc:29,0 (Power on, reset, >>>>> or >>>>> bus device reset occurred) >>>>> (da11:mpt0:0:3:0): READ(10). CDB: 28 0 1a b6 92 0 0 0 80 0 >>>>> (da11:mpt0:0:3:0): CAM status: SCSI Status Error >>>>> (da11:mpt0:0:3:0): SCSI status: Check Condition >>>>> (da11:mpt0:0:3:0): SCSI sense: UNIT ATTENTION asc:29,0 (Power on, >>>>> reset, or >>>>> bus device reset occurred) >>>>> (da2:mpt1:0:2:0): READ(10). CDB: 28 0 76 7b de 0 0 0 80 0 >>>>> (da2:mpt1:0:2:0): CAM status: SCSI Status Error >>>>> (da2:mpt1:0:2:0): SCSI status: Check Condition >>>>> (da2:mpt1:0:2:0): SCSI sense: UNIT ATTENTION asc:29,0 (Power on, reset, >>>>> or >>>>> bus device reset occurred) >>>>> (da10:mpt0:0:2:0): READ(10). CDB: 28 0 1a ff 67 80 0 0 80 0 >>>>> (da10:mpt0:0:2:0): CAM status: SCSI Status Error >>>>> (da10:mpt0:0:2:0): SCSI status: Check Condition >>>>> (da10:mpt0:0:2:0): SCSI sense: UNIT ATTENTION asc:29,0 (Power on, >>>>> reset, or >>>>> bus device reset occurred) >>>>> (da5:mpt1:0:5:0): READ(10). CDB: 28 0 1a ff 67 80 0 0 80 0 >>>>> (da5:mpt1:0:5:0): CAM status: SCSI Status Error >>>>> (da5:mpt1:0:5:0): SCSI status: Check Condition >>>>> (da5:mpt1:0:5:0): SCSI sense: UNIT ATTENTION asc:29,0 (Power on, reset, >>>>> or >>>>> bus device reset occurred) >>>>> (da7:mpt1:0:7:0): READ(10). CDB: 28 0 40 d7 da 80 0 0 80 0 >>>>> (da7:mpt1:0:7:0): CAM status: SCSI Status Error >>>>> (da7:mpt1:0:7:0): SCSI status: Check Condition >>>>> (da7:mpt1:0:7:0): SCSI sense: UNIT ATTENTION asc:29,0 (Power on, reset, >>>>> or >>>>> bus device reset occurred) >>>>> (da6:mpt1:0:6:0): READ(10). CDB: 28 0 40 d7 da 80 0 0 80 0 >>>>> (da6:mpt1:0:6:0): CAM status: SCSI Status Error >>>>> (da6:mpt1:0:6:0): SCSI status: Check Condition >>>>> (da6:mpt1:0:6:0): SCSI sense: UNIT ATTENTION asc:29,0 (Power on, reset, >>>>> or >>>>> bus device reset occurred) >>>>> (da0:mpt1:0:0:0): READ(10). CDB: 28 0 76 91 87 e3 0 0 1 0 >>>>> (da0:mpt1:0:0:0): CAM status: SCSI Status Error >>>>> (da0:mpt1:0:0:0): SCSI status: Check Condition >>>>> (da0:mpt1:0:0:0): SCSI sense: UNIT ATTENTION asc:29,0 (Power on, reset, >>>>> or >>>>> bus device reset occurred) >>>>> (da3:mpt1:0:3:0): READ(10). CDB: 28 0 76 69 1 1c 0 0 1 0 >>>>> (da3:mpt1:0:3:0): CAM status: SCSI Status Error >>>>> (da3:mpt1:0:3:0): SCSI status: Check Condition >>>>> (da3:mpt1:0:3:0): SCSI sense: UNIT ATTENTION asc:29,0 (Power on, reset, >>>>> or >>>>> bus device reset occurred) >>>>> (da1:mpt1:0:1:0): READ(10). CDB: 28 0 76 69 1 1c 0 0 1 0 >>>>> (da1:mpt1:0:1:0): CAM status: SCSI Status Error >>>>> (da1:mpt1:0:1:0): SCSI status: Check Condition >>>>> (da1:mpt1:0:1:0): SCSI sense: UNIT ATTENTION asc:29,0 (Power on, reset, >>>>> or >>>>> bus device reset occurred) >>>>> (da9:mpt0:0:1:0): READ(10). CDB: 28 0 1a b3 d7 0 0 0 80 0 >>>>> (da9:mpt0:0:1:0): CAM status: SCSI Status Error >>>>> (da9:mpt0:0:1:0): SCSI status: Check Condition >>>>> (da9:mpt0:0:1:0): SCSI sense: UNIT ATTENTION asc:29,0 (Power on, reset, >>>>> or >>>>> bus device reset occurred) >>>>> (da4:mpt1:0:4:0): READ(10). CDB: 28 0 53 3c c6 0 0 0 80 0 >>>>> (da4:mpt1:0:4:0): CAM status: SCSI Status Error >>>>> (da4:mpt1:0:4:0): SCSI status: Check Condition >>>>> (da4:mpt1:0:4:0): SCSI sense: UNIT ATTENTION asc:29,0 (Power on, reset, >>>>> or >>>>> bus device reset occurred) >>>>> >>>>> >>>>> >>>>> > >>>>> > -- >>>>> > | Jeremy Chadwick jdc@parodius.com| >>>>> > | Parodius Networking http://www.parodius.com/| >>>>> > | UNIX Systems Administrator Mountain View, CA, US >>>>> | >>>>> > | Making life hard for others since 1977. PGP 4BD6C0CB >>>>> | >>>>> > >>>>> > >>>>> >>>>> >>>>> -- >>>>> Joshua Boyd >>>>> _______________________________________________ >>>>> freebsd-stable@freebsd.org mailing list >>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >>>>> To unsubscribe, send any mail to " >>>>> freebsd-stable-unsubscribe@freebsd.org" >>>>> >>>> >>>> >>> >>> >>> -- >>> Joshua Boyd >>> >> >> >> >> -- >> Joshua Boyd >> >> >> E-mail: boydjd@jbip.net >> http://www.jbip.net >> > > -- Joshua Boyd E-mail: boydjd@jbip.net http://www.jbip.net From owner-freebsd-stable@FreeBSD.ORG Wed Jun 22 15:48:46 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D27A61065670 for ; Wed, 22 Jun 2011 15:48:46 +0000 (UTC) (envelope-from gkontos.mail@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 9AAFA8FC1B for ; Wed, 22 Jun 2011 15:48:46 +0000 (UTC) Received: by iyb11 with SMTP id 11so1099147iyb.13 for ; Wed, 22 Jun 2011 08:48:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=W15M1r9qmrMKsuX8X7opnC05xpKmo0UL4ciSM78zk90=; b=gm3Rnv8+5rfZsvU924XmPHgmPs9SwP0gPUTFUY3Ifjqd0MIpGtrRVC0z0nxEIzGaAH Qp4pKZXsazhyYsuIu1vDW6yemXA+6r55wMupWMlBAGpTkRjIfVXlGMtjyErE06D5yw03 BlhWtpLv+2MgyCHUoikD352H97fKDuxkevKTA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=iFoV1zZsHfDqVooiAJ4yVm0BX9rnBFo58aF/I/b9Ec+B/rzGibF/DJL2qYEsFjDXnK 3Hpp/rMrQ6Wcvz9w1omn/FpxPLKJif/ylFfhn8c2PbHCMVTqWDQNUqjsRIhyYvjJMKLB 9S+vGYBJ+mde4eRUxuBxVLq7U6X4cvLdzmN68= MIME-Version: 1.0 Received: by 10.231.54.100 with SMTP id p36mr708561ibg.162.1308757725971; Wed, 22 Jun 2011 08:48:45 -0700 (PDT) Received: by 10.231.15.5 with HTTP; Wed, 22 Jun 2011 08:48:45 -0700 (PDT) In-Reply-To: References: Date: Wed, 22 Jun 2011 18:48:45 +0300 Message-ID: From: George Kontostanos To: FreeBSD Stable Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: ata: SIGNATURE: ffffffff X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 15:48:46 -0000 Forgot to mention, I have changed the SATA cables too. On Wed, Jun 22, 2011 at 5:52 PM, George Kontostanos wrote: > This is the 3rd disk I replace in 3 disk- Raiz1 pool and I really start to > believe that the problem is somewhere else. The disks reside in a Promise > PDC40718 SATA300 controller. I am running this set up since 8.0-Release with > no issues till a few months ago after 8.2-Release now at 8.2-Stable. > Symptoms: > > Jun 22 17:08:53 hp kernel: ata2: timeout waiting to issue command > Jun 22 17:08:53 hp kernel: ata2: error issuing SETFEATURES ENABLE WCACHE > command > Jun 22 17:09:33 hp kernel: ad4: WARNING - SET_MULTI taskqueue timeout - > completing request directly > Jun 22 17:09:33 hp kernel: ad4: WARNING - WRITE_DMA48 requeued due to > channel reset LBA=321558741 > Jun 22 17:09:34 hp kernel: ata2: SIGNATURE: 00000101 > Jun 22 17:09:34 hp kernel: ad4: WARNING - WRITE_DMA48 requeued due to > channel reset LBA=321558869 > Jun 22 17:09:34 hp kernel: ata2: FAILURE - already active DMA on this > device > Jun 22 17:09:34 hp kernel: ata2: setting up DMA failed > Jun 22 17:09:34 hp kernel: ata2: FAILURE - already active DMA on this > device > Jun 22 17:09:34 hp kernel: ata2: setting up DMA failed > > > After a while the disk gets detached from the pool. Always the same disk. > Rite now I am in the process of resilvering : > > pool: tank > state: ONLINE > status: One or more devices is currently being resilvered. The pool will > continue to function, possibly in a degraded state. > action: Wait for the resilver to complete. > scan: resilver in progress since Wed Jun 22 17:09:40 2011 > 189G scanned out of 578G at 88.8M/s, 1h14m to go > 62.9G resilvered, 32.63% done > config: > > NAME STATE READ WRITE CKSUM > tank ONLINE 0 0 0 > raidz1-0 ONLINE 0 0 0 > label/zdisk1 ONLINE 0 0 0 > label/zdisk2 ONLINE 0 0 0 > label/zdisk3 ONLINE 0 0 0 (resilvering) > > But those errors have started to appear again. Again this is the 3rd disk > replaced !!! Full dmesg attached > > -- > George Kontostanos > aisecure.net > > -- George Kontostanos aisecure.net From owner-freebsd-stable@FreeBSD.ORG Wed Jun 22 15:49:30 2011 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6FBB2106564A; Wed, 22 Jun 2011 15:49:30 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 8AB518FC17; Wed, 22 Jun 2011 15:49:29 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id SAA11882; Wed, 22 Jun 2011 18:49:28 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4E020F07.50504@FreeBSD.org> Date: Wed, 22 Jun 2011 18:49:27 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110504 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org References: <4DE8FA2E.4030202@FreeBSD.org> <5E4D0F56-4338-4157-8BC6-17EE2831725F@FreeBSD.org> <4DE9EB61.3000006@FreeBSD.org> In-Reply-To: <4DE9EB61.3000006@FreeBSD.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Subject: Re: [poll / rfc] kdb_stop_cpus X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 15:49:30 -0000 on 04/06/2011 11:22 Andriy Gapon said the following: > commit 458ebd9aca7e91fc6e0825c727c7220ab9f61016 > > generic_stop_cpus: move timeout detection code from under DIAGNOSTIC > > ... and also increase it a bit. > IMO it's better to detect and report the (rather serious) condition and > allow a system to proceed somehow rather than be stuck in an endless > loop. > > diff --git a/sys/kern/subr_smp.c b/sys/kern/subr_smp.c > index ae52f4b..4bd766b 100644 > --- a/sys/kern/subr_smp.c > +++ b/sys/kern/subr_smp.c > @@ -232,12 +232,10 @@ generic_stop_cpus(cpumask_t map, u_int type) > /* spin */ > cpu_spinwait(); > i++; > -#ifdef DIAGNOSTIC > - if (i == 100000) { > + if (i == 100000000) { > printf("timeout stopping cpus\n"); > break; > } > -#endif > } > > stopping_cpu = NOCPU; > > I would like to commit the above, if nobody objects. A to do item is adding some code to aid debugging of the timeout condition. I discussed this with Attilio, he doesn't see this as a show-stopper and he plans to add the code at a later time. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Wed Jun 22 15:51:14 2011 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2CE6A106564A; Wed, 22 Jun 2011 15:51:14 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 4FFFA8FC1A; Wed, 22 Jun 2011 15:51:13 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id SAA11912; Wed, 22 Jun 2011 18:51:12 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4E020F6F.7000502@FreeBSD.org> Date: Wed, 22 Jun 2011 18:51:11 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110504 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org References: <4DE8FA2E.4030202@FreeBSD.org> In-Reply-To: <4DE8FA2E.4030202@FreeBSD.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Subject: Re: [poll / rfc] kdb_stop_cpus X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 15:51:14 -0000 on 03/06/2011 18:13 Andriy Gapon said the following: > > I wonder if anybody uses kdb_stop_cpus with non-default value. I would like to go ahead and remove kdb_stop_cpus tunable/sysctl if nobody objects. > If, yes, I am very interested to learn about your usecase for it. > > I think that the default kdb behavior is the correct one, so it doesn't make sense > to have a knob to turn on incorrect behavior. > But I may be missing something obvious. > > The comment in the code doesn't really satisfy me: > /* > * Flag indicating whether or not to IPI the other CPUs to stop them on > * entering the debugger. Sometimes, this will result in a deadlock as > * stop_cpus() waits for the other cpus to stop, so we allow it to be > * disabled. In order to maximize the chances of success, use a hard > * stop for that. > */ > > The hard stop should be sufficiently mighty. > Yes, I am aware of supposedly extremely rare situations where a deadlock could > happen even when using hard stop. But I'd rather fix that than have this switch. > > Oh, the commit message (from 2004) explains it: >> Add a new sysctl, debug.kdb.stop_cpus, which controls whether or not we >> attempt to IPI other cpus when entering the debugger in order to stop >> them while in the debugger. The default remains to issue the stop; >> however, that can result in a hang if another cpu has interrupts disabled >> and is spinning, since the IPI won't be received and the KDB will wait >> indefinitely. We probably need to add a timeout, but this is a useful >> stopgap in the mean time. > > But that was before we started using hard stop in this context (in 2009). > -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Wed Jun 22 15:58:18 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 28B14106566B for ; Wed, 22 Jun 2011 15:58:18 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id C9BB68FC15 for ; Wed, 22 Jun 2011 15:58:17 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 5E59546B06; Wed, 22 Jun 2011 11:58:17 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id EABB28A01F; Wed, 22 Jun 2011 11:58:16 -0400 (EDT) From: John Baldwin To: Henri Hennebert Date: Wed, 22 Jun 2011 11:58:16 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110617; KDE/4.5.5; amd64; ; ) References: <4E01FA03.9070805@restart.be> <4E01FADA.2070104@restart.be> In-Reply-To: <4E01FADA.2070104@restart.be> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201106221158.16485.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Wed, 22 Jun 2011 11:58:17 -0400 (EDT) Cc: freebsd-stable@freebsd.org Subject: Re: ZFS boot inside on the second partition inside a slice X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 15:58:18 -0000 On Wednesday, June 22, 2011 10:23:22 am Henri Hennebert wrote: > On 06/22/2011 16:19, Henri Hennebert wrote: > > This time: > > > > LBA: 3c802308 > > Read error: 04 > > > > This morning I was reading the code (I'm in Belgium) and find that the > > previous LBA output was DAP+4 and so was the addr of the buffer. 0x8200 > > = $MEM_BUF+512, and so we must be in the second read. > > > > OK I think I see, the first read mangle the partition table previously > read at $MEM_BUF and so the next one is wrong. Ahh, very true. I was planning to simplify the code to just load at MEM_BTX directly and avoid copying BTX. I went ahead and did that below: Index: zfsldr.S =================================================================== --- zfsldr.S (revision 223365) +++ zfsldr.S (working copy) @@ -16,7 +16,6 @@ */ /* Memory Locations */ - .set MEM_REL,0x700 # Relocation address .set MEM_ARG,0x900 # Arguments .set MEM_ORG,0x7c00 # Origin .set MEM_BUF,0x8000 # Load area @@ -91,26 +90,18 @@ main: cld # String ops inc mov %cx,%ss # Set up mov $start,%sp # stack /* - * Relocate ourself to MEM_REL. Since %cx == 0, the inc %ch sets - * %cx == 0x100. - */ - mov %sp,%si # Source - mov $MEM_REL,%di # Destination - incb %ch # Word count - rep # Copy - movsw # code -/* * If we are on a hard drive, then load the MBR and look for the first * FreeBSD slice. We use the fake partition entry below that points to * the MBR when we call nread. The first pass looks for the first active * FreeBSD slice. The second pass looks for the first non-active FreeBSD * slice if the first one fails. */ - mov $part4,%si # Partition + mov $part4,%si # Dummy partition cmpb $0x80,%dl # Hard drive? jb main.4 # No - movb $0x1,%dh # Block count - callw nread # Read MBR + xor %eax,%eax # Read MBR + movw $MEM_BUF,%bx # from first + callw nread # sector mov $0x1,%cx # Two passes main.1: mov $MEM_BUF+PRT_OFF,%si # Partition table movb $0x1,%dh # Partition @@ -143,32 +134,35 @@ main.4: xor %dx,%dx # Partition:drive * (i.e. after the two vdev labels). We don't have do anything fancy * here to allow for an extra copy of boot1 and a partition table * (compare to this section of the UFS bootstrap) so we just load it - * all at 0x8000. The first part of boot2 is BTX, which wants to run + * all at 0x9000. The first part of boot2 is BTX, which wants to run * at 0x9000. The boot2.bin binary starts right after the end of BTX, * so we have to figure out where the start of it is and then move the - * binary to 0xc000. After we have moved the client, we relocate BTX - * itself to 0x9000 - doing it in this order means that none of the - * memcpy regions overlap which would corrupt the copy. Normally, BTX - * clients start at MEM_USR, or 0xa000, but when we use btxld to - * create zfsboot2, we use an entry point of 0x2000. That entry point is - * relative to MEM_USR; thus boot2.bin starts at 0xc000. + * binary to 0xc000. Normally, BTX clients start at MEM_USR, or 0xa000, + * but when we use btxld to create zfsboot2, we use an entry point of + * 0x2000. That entry point is relative to MEM_USR; thus boot2.bin + * starts at 0xc000. * * The load area and the target area for the client overlap so we have * to use a decrementing string move. We also play segment register * games with the destination address for the move so that the client * can be larger than 16k (which would overflow the zero segment since - * the client starts at 0xc000). Relocating BTX is easy since the load - * area and target area do not overlap. + * the client starts at 0xc000). */ main.5: mov %dx,MEM_ARG # Save args - movb $NSECT,%dh # Sector count + mov $NSECT,%cx # Sector count movl $1024,%eax # Offset to boot2 - callw nread.1 # Read disk -main.6: mov $MEM_BUF,%si # BTX (before reloc) + mov $MEM_BTX,%bx # Destination buffer +main.6: pushal # Save params + callw nread # Read disk + popal # Restore + incl %eax # Update for + add $SIZ_SEC,%bx # next sector + loop main.6 # If not last, read another + mov $MEM_BTX,%si # BTX mov 0xa(%si),%bx # Get BTX length and set mov $NSECT*SIZ_SEC-1,%di # Size of load area (less one) mov %di,%si # End of load - add $MEM_BUF,%si # area + add $MEM_BTX,%si # area sub %bx,%di # End of client, 0xc000 rel mov %di,%cx # Size of inc %cx # client @@ -179,12 +173,6 @@ main.5: mov %dx,MEM_ARG # Save args movsb # client mov %ds,%dx # Back to mov %dx,%es # zero segment - mov $MEM_BUF,%si # BTX (before reloc) - mov $MEM_BTX,%di # BTX - mov %bx,%cx # Get BTX length - cld # Increment this time - rep # Relocate - movsb # BTX /* * Enable A20 so we can access memory above 1 meg. @@ -214,29 +202,35 @@ seta20.3: sti # Enable interrupts * packet on the stack and passes it to read. * * %eax - int - LBA to read in relative to partition start + * %es:%bx - ptr - destination address * %dl - byte - drive to read from - * %dh - byte - num sectors to read * %si - ptr - MBR partition entry */ -nread: xor %eax,%eax # Sector offset in partition -nread.1: xor %ecx,%ecx # Get +nread: xor %ecx,%ecx # Get addl 0x8(%si),%eax # LBA adc $0,%ecx pushl %ecx # Starting absolute block pushl %eax # block number push %es # Address of - push $MEM_BUF # transfer buffer - xor %ax,%ax # Number of - movb %dh,%al # blocks to - push %ax # transfer + push %bx # transfer buffer + push $0x1 # Read 1 sector push $0x10 # Size of packet mov %sp,%bp # Packet pointer callw read # Read from disk + jc nread.1 # If error, fail lea 0x10(%bp),%sp # Clear stack - jnc return # If success, return - mov $msg_read,%si # Otherwise, set the error - # message and fall through to - # the error routine + ret # If success, return +nread.1: mov %ah,%al # Format + mov $read_err,%di # error + call hex8 # code + movl 0x8(%bp),%eax # Format + mov $lba,%di # LBA + call hex32 + mov $msg_lba,%si # Display + call putstr # LBA + mov $msg_read,%si # Set the error message and + # fall through to the error + # routine /* * Print out the error message pointed to by %ds:(%si) followed * by a prompt, wait for a keypress, and then reboot the machine. @@ -259,14 +253,6 @@ putstr: lodsb # Get char jne putstr.0 # No /* - * Overused return code. ereturn is used to return an error from the - * read function. Since we assume putstr succeeds, we (ab)use the - * same code when we return from putstr. - */ -ereturn: movb $0x1,%ah # Invalid - stc # argument -return: retw # To caller -/* * Reads sectors from the disk. If EDD is enabled, then check if it is * installed and use it if it is. If it is not installed or not enabled, then * fall back to using CHS. Since we use a LBA, if we are using CHS, we have to @@ -294,14 +280,38 @@ read: cmpb $0x80,%dl # Hard drive? retw # To caller read.1: mov $msg_chs,%si jmp error -msg_chs: .asciz "CHS not supported" +/* + * Convert EAX, AX, or AL to hex, saving the result to [EDI]. + */ +hex32: pushl %eax # Save + shrl $0x10,%eax # Do upper + call hex16 # 16 + popl %eax # Restore +hex16: call hex16.1 # Do upper 8 +hex16.1: xchgb %ah,%al # Save/restore +hex8: push %ax # Save + shrb $0x4,%al # Do upper + call hex8.1 # 4 + pop %ax # Restore +hex8.1: andb $0xf,%al # Get lower 4 + cmpb $0xa,%al # Convert + sbbb $0x69,%al # to hex + das # digit + orb $0x20,%al # To lower case + stosb # Save char + ret # (Recursive) + /* Messages */ -msg_read: .asciz "Read" -msg_part: .asciz "Boot" +msg_chs: .asciz "CHS not supported" +msg_read: .ascii "Read error: " +read_err: .asciz "XX" +msg_lba: .ascii "LBA: " +lba: .asciz "XXXXXXXX\r\n" +msg_part: .asciz "Boot error" -prompt: .asciz " error\r\n" +prompt: .asciz "\r\n" .org PRT_OFF,0x90 -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Wed Jun 22 16:39:19 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CA83F1065670 for ; Wed, 22 Jun 2011 16:39:19 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 24DF28FC08 for ; Wed, 22 Jun 2011 16:39:18 +0000 (UTC) Received: by vws18 with SMTP id 18so1023585vws.13 for ; Wed, 22 Jun 2011 09:39:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=qi04kPRkFZB0yhNlaf4G5Qd8gZD5gJWjJs99fcy15TU=; b=KAZ3Nwpyg/wb5c7ko0U6+815KDWZHLKdSFJal8Gnbzg/Yhv3sU8GCzmYi9i/UR7pOX 1JwTTkmHPIU4eubPBkI92dXQSTKaavqYHcuLnrcrRUDfWy2vnKpvdWRVUGmbc3tIL65m zUSr/jJ4XSiUmobK42KIUQ+JEe+BCa/ib5Tg8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=K4XYA4gVUXO5PgA+UKes/5YXDFYk/MRREj0ERjMsiR8Dzzfp71o7oOovTlVM2p/YWc l6OMhm5dIiK6Kbl5FtkLcBkRwcbo5TLESI9Ltc6J3Q/TyYs+pLkv6oRczJVMTRlJrrYB TlNLZddZAqG+aG0DBojJov3lhKeyvNv6qZp8I= MIME-Version: 1.0 Received: by 10.52.98.34 with SMTP id ef2mr1229429vdb.293.1308760756857; Wed, 22 Jun 2011 09:39:16 -0700 (PDT) Received: by 10.52.114.99 with HTTP; Wed, 22 Jun 2011 09:39:16 -0700 (PDT) In-Reply-To: References: <20110615075754.GA54879@icarus.home.lan> Date: Wed, 22 Jun 2011 09:39:16 -0700 Message-ID: From: Jack Vogel To: Joshua Boyd Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable , "Vogel, Jack" , Jeremy Chadwick Subject: Re: em0 watchdog timeouts on 8-STABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 16:39:19 -0000 Then its sounding to me like the em driver is a victim of your other I/O, meaning that the watchdogs are just an honest indicator of the driver not getting to run when it needs to. This is also a side effect of running older hardware with legacy interrupts, the MSIX capable adapters would be less likely to get starved I suspect. I don't know anything about ZFS so maybe someone else can help with tuning this?? Jack On Wed, Jun 22, 2011 at 8:24 AM, Joshua Boyd wrote: > :( > > I don't actually have problems normally with maxing out the throughput of > the network. Watchdogs only occur when I've got heavy I/O occurring during > ZFS scrubs across 2 mpt devices, at about 700MB/s. And then it doesn't > matter what kind of traffic I'm running through em0, it still throws > watchdogs. During the first occurrence it was actually pretty minimal > traffic, less than 100KB/s. > > Are there any statistics that would be useful to you if I were to trigger > the watchdogs again? > > > On Wed, Jun 22, 2011 at 1:22 AM, Jack Vogel wrote: > >> I cannot repro this, I used your kernel config, this is on a Dell 1850 >> btw, >> I ran netperf stress from 3 clients, and have seen no watchdogs :( >> >> Jack >> >> >> >> On Tue, Jun 21, 2011 at 7:59 PM, Joshua Boyd wrote: >> >>> If needed, I can reproduce this on demand. Just need to know what sort of >>> statistics are needed when the problem is occurring. I've had to turn off my >>> weekly scrubs until I can figure out how to fix this problem. >>> >>> >>> On Wed, Jun 15, 2011 at 8:37 PM, Joshua Boyd wrote: >>> >>>> In the kernel. Here's my kernel configuration: >>>> >>>> http://pastebin.com/raw.php?i=4JL814m3 >>>> >>>> On Wed, Jun 15, 2011 at 8:20 PM, Jack Vogel wrote: >>>> >>>>> I have hardware now, am working on reproducing this. Just curious, do >>>>> you have >>>>> the em driver defined in the kernel, or as a module? >>>>> >>>>> Jack >>>>> >>>>> >>>>> On Wed, Jun 15, 2011 at 2:09 AM, Joshua Boyd wrote: >>>>> >>>>>> On Wed, Jun 15, 2011 at 3:57 AM, Jeremy Chadwick >>>>>> wrote: >>>>>> >>>>>> > On Wed, Jun 15, 2011 at 03:14:43AM -0400, Joshua Boyd wrote: >>>>>> > > I recently updated my server to the latest 8-STABLE, and upgraded >>>>>> to v28 >>>>>> > > ZFS. I have not had these problems on any other version of >>>>>> 8-STABLE or >>>>>> > > 7-STABLE, which this box was upgraded from some time ago. >>>>>> > > >>>>>> > > Now, during my weekly scrub, I get the following messages and em0 >>>>>> is >>>>>> > > unresponsive: >>>>>> > > >>>>>> > > Jun 12 03:07:58 foghornleghorn kernel: em0: Watchdog timeout -- >>>>>> resetting >>>>>> > > Jun 12 03:07:58 foghornleghorn kernel: em0: link state changed to >>>>>> DOWN >>>>>> > > Jun 12 03:08:01 foghornleghorn kernel: em0: link state changed to >>>>>> UP >>>>>> > > Jun 12 03:08:47 foghornleghorn kernel: em0: Watchdog timeout -- >>>>>> resetting >>>>>> > > Jun 12 03:08:47 foghornleghorn kernel: em0: link state changed to >>>>>> DOWN >>>>>> > > Jun 12 03:08:50 foghornleghorn kernel: em0: link state changed to >>>>>> UP >>>>>> > > >>>>>> > > My scrub is scheduled to start at 03:00:00, so it looks like >>>>>> watchdog >>>>>> > > timeouts start occurring pretty quickly once I/O ramps up. >>>>>> > > >>>>>> > > Here's some possibly relevant information, let me know if anything >>>>>> else >>>>>> > > would be helpful to troubleshoot. >>>>>> > > >>>>>> > > FreeBSD foghornleghorn.res.openband.net 8.2-STABLE FreeBSD >>>>>> 8.2-STABLE >>>>>> > #17: >>>>>> > > Mon Jun 6 19:40:19 EDT 2011 >>>>>> > > root@foghornleghorn.res.openband.net: >>>>>> /usr/obj/usr/src/sys/FOGHORNLEGHORN >>>>>> > > amd64 >>>>>> > > >>>>>> > > em0: port >>>>>> > 0xe800-0xe83f >>>>>> > > mem 0xfebe0000-0xfebfffff,0xfebc0000-0xfebdffff irq 20 at device >>>>>> 5.0 on >>>>>> > pci7 >>>>>> > > >>>>>> > > em0@pci0:7:5:0: class=0x020000 card=0x13768086 chip=0x107c8086 >>>>>> rev=0x05 >>>>>> > > hdr=0x00 >>>>>> > > vendor = 'Intel Corporation' >>>>>> > > device = 'Gigabit Ethernet Controller (Copper) rev 5 >>>>>> (82541PI)' >>>>>> > > class = network >>>>>> > > subclass = ethernet >>>>>> > > >>>>>> > > And, the SAS cards: >>>>>> > > >>>>>> > > dev.mpt.0.%desc: LSILogic SAS/SATA Adapter >>>>>> > > dev.mpt.0.%driver: mpt >>>>>> > > dev.mpt.0.%location: slot=0 function=0 >>>>>> > > dev.mpt.0.%pnpinfo: vendor=0x1000 device=0x0058 subvendor=0x15d9 >>>>>> > > subdevice=0xa580 class=0x010000 >>>>>> > > dev.mpt.0.%parent: pci1 >>>>>> > > dev.mpt.0.debug: 3 >>>>>> > > dev.mpt.0.role: 1 >>>>>> > > dev.mpt.1.%desc: LSILogic SAS/SATA Adapter >>>>>> > > dev.mpt.1.%driver: mpt >>>>>> > > dev.mpt.1.%location: slot=0 function=0 >>>>>> > > dev.mpt.1.%pnpinfo: vendor=0x1000 device=0x0058 subvendor=0x15d9 >>>>>> > > subdevice=0xa580 class=0x010000 >>>>>> > > dev.mpt.1.%parent: pci2 >>>>>> > > dev.mpt.1.debug: 3 >>>>>> > > dev.mpt.1.role: 1 >>>>>> > > dev.mpt.2.%desc: LSILogic SAS/SATA Adapter >>>>>> > > dev.mpt.2.%driver: mpt >>>>>> > > dev.mpt.2.%location: slot=0 function=0 >>>>>> > > dev.mpt.2.%pnpinfo: vendor=0x1000 device=0x0058 subvendor=0x1000 >>>>>> > > subdevice=0x30a0 class=0x010000 >>>>>> > > dev.mpt.2.%parent: pci6 >>>>>> > > dev.mpt.2.debug: 3 >>>>>> > > dev.mpt.2.role: 1 >>>>>> > >>>>>> > Please provide output from the following commands (as root): >>>>>> > >>>>>> > # pciconf -lvcb >>>>>> > >>>>>> >>>>>> hostb0@pci0:0:0:0: class=0x060000 card=0x59561002 chip=0x59561002 >>>>>> rev=0x00 >>>>>> hdr=0x00 >>>>>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>>>>> device = 'RD790 GFX Dual Slot' >>>>>> class = bridge >>>>>> subclass = HOST-PCI >>>>>> pcib1@pci0:0:2:0: class=0x060400 card=0x59561002 chip=0x59781002 >>>>>> rev=0x00 >>>>>> hdr=0x01 >>>>>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>>>>> device = 'RD790 PCI to PCI bridge (external gfx0 port A)' >>>>>> class = bridge >>>>>> subclass = PCI-PCI >>>>>> pcib2@pci0:0:3:0: class=0x060400 card=0x59561002 chip=0x59791002 >>>>>> rev=0x00 >>>>>> hdr=0x01 >>>>>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>>>>> device = 'RD790 PCI to PCI bridge (external gfx0 port B)' >>>>>> class = bridge >>>>>> subclass = PCI-PCI >>>>>> pcib3@pci0:0:4:0: class=0x060400 card=0x59561002 chip=0x597a1002 >>>>>> rev=0x00 >>>>>> hdr=0x01 >>>>>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>>>>> device = 'RD790 PCI to PCI bridge (PCIe gpp port A)' >>>>>> class = bridge >>>>>> subclass = PCI-PCI >>>>>> pcib4@pci0:0:6:0: class=0x060400 card=0x59561002 chip=0x597c1002 >>>>>> rev=0x00 >>>>>> hdr=0x01 >>>>>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>>>>> device = 'RD790 PCI to PCI bridge (PCIe gpp port C)' >>>>>> class = bridge >>>>>> subclass = PCI-PCI >>>>>> pcib5@pci0:0:7:0: class=0x060400 card=0x59561002 chip=0x597d1002 >>>>>> rev=0x00 >>>>>> hdr=0x01 >>>>>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>>>>> device = 'RD790 PCI to PCI bridge (PCIe gpp port D)' >>>>>> class = bridge >>>>>> subclass = PCI-PCI >>>>>> pcib6@pci0:0:11:0: class=0x060400 card=0x59561002 chip=0x59801002 >>>>>> rev=0x00 >>>>>> hdr=0x01 >>>>>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>>>>> device = 'RD790 PCI to PCI bridge (external gfx1 port A)' >>>>>> class = bridge >>>>>> subclass = PCI-PCI >>>>>> atapci4@pci0:0:18:0: class=0x01018f card=0x81ef1043 chip=0x43801002 >>>>>> rev=0x00 >>>>>> hdr=0x00 >>>>>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>>>>> device = 'IXP SB600 Serial ATA Controller' >>>>>> class = mass storage >>>>>> subclass = ATA >>>>>> ohci0@pci0:0:19:0: class=0x0c0310 card=0x82881043 chip=0x43871002 >>>>>> rev=0x00 >>>>>> hdr=0x00 >>>>>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>>>>> device = 'IXP SB600 USB Controller (OHCI0)' >>>>>> class = serial bus >>>>>> subclass = USB >>>>>> ohci1@pci0:0:19:1: class=0x0c0310 card=0x82881043 chip=0x43881002 >>>>>> rev=0x00 >>>>>> hdr=0x00 >>>>>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>>>>> device = 'IXP SB600 USB Controller (OHCI1)' >>>>>> class = serial bus >>>>>> subclass = USB >>>>>> ohci2@pci0:0:19:2: class=0x0c0310 card=0x82881043 chip=0x43891002 >>>>>> rev=0x00 >>>>>> hdr=0x00 >>>>>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>>>>> device = 'IXP SB600 USB Controller (OHCI2)' >>>>>> class = serial bus >>>>>> subclass = USB >>>>>> ohci3@pci0:0:19:3: class=0x0c0310 card=0x82881043 chip=0x438a1002 >>>>>> rev=0x00 >>>>>> hdr=0x00 >>>>>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>>>>> device = 'IXP SB600 USB Controller (OHCI3)' >>>>>> class = serial bus >>>>>> subclass = USB >>>>>> ohci4@pci0:0:19:4: class=0x0c0310 card=0x82881043 chip=0x438b1002 >>>>>> rev=0x00 >>>>>> hdr=0x00 >>>>>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>>>>> device = 'IXP SB600 USB Controller (OHCI4)' >>>>>> class = serial bus >>>>>> subclass = USB >>>>>> ehci0@pci0:0:19:5: class=0x0c0320 card=0x82881043 chip=0x43861002 >>>>>> rev=0x00 >>>>>> hdr=0x00 >>>>>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>>>>> device = 'IXP SB600 USB Controller (EHCI)' >>>>>> class = serial bus >>>>>> subclass = USB >>>>>> none0@pci0:0:20:0: class=0x0c0500 card=0x82881043 chip=0x43851002 >>>>>> rev=0x14 >>>>>> hdr=0x00 >>>>>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>>>>> device = 'ATI SMBus (ATI RD600/RS600)' >>>>>> class = serial bus >>>>>> subclass = SMBus >>>>>> atapci5@pci0:0:20:1: class=0x01018a card=0x82881043 chip=0x438c1002 >>>>>> rev=0x00 >>>>>> hdr=0x00 >>>>>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>>>>> device = 'ATI RD600/RS600 IDE Controller (RD600/RS600)' >>>>>> class = mass storage >>>>>> subclass = ATA >>>>>> none1@pci0:0:20:2: class=0x040300 card=0x82881043 chip=0x43831002 >>>>>> rev=0x00 >>>>>> hdr=0x00 >>>>>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>>>>> device = 'IXP SB600 High Definition Audio Controller' >>>>>> class = multimedia >>>>>> subclass = HDA >>>>>> isab0@pci0:0:20:3: class=0x060100 card=0x82881043 chip=0x438d1002 >>>>>> rev=0x00 >>>>>> hdr=0x00 >>>>>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>>>>> device = 'IXP SB600 PCI to LPC Bridge' >>>>>> class = bridge >>>>>> subclass = PCI-ISA >>>>>> pcib7@pci0:0:20:4: class=0x060401 card=0x00000000 chip=0x43841002 >>>>>> rev=0x00 >>>>>> hdr=0x01 >>>>>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>>>>> device = 'IXP SB600 PCI to PCI Bridge' >>>>>> class = bridge >>>>>> subclass = PCI-PCI >>>>>> hostb1@pci0:0:24:0: class=0x060000 card=0x00000000 chip=0x12001022 >>>>>> rev=0x00 >>>>>> hdr=0x00 >>>>>> vendor = 'Advanced Micro Devices (AMD)' >>>>>> device = '(Family 10h) Athlon64/Opteron/Sempron HyperTransport >>>>>> Technology Configuration' >>>>>> class = bridge >>>>>> subclass = HOST-PCI >>>>>> hostb2@pci0:0:24:1: class=0x060000 card=0x00000000 chip=0x12011022 >>>>>> rev=0x00 >>>>>> hdr=0x00 >>>>>> vendor = 'Advanced Micro Devices (AMD)' >>>>>> device = '(Family 10h) Athlon64/Opteron/Sempron Address Map' >>>>>> class = bridge >>>>>> subclass = HOST-PCI >>>>>> hostb3@pci0:0:24:2: class=0x060000 card=0x00000000 chip=0x12021022 >>>>>> rev=0x00 >>>>>> hdr=0x00 >>>>>> vendor = 'Advanced Micro Devices (AMD)' >>>>>> device = '(Family 10h) Athlon64/Opteron/Sempron DRAM >>>>>> Controller' >>>>>> class = bridge >>>>>> subclass = HOST-PCI >>>>>> hostb4@pci0:0:24:3: class=0x060000 card=0x00000000 chip=0x12031022 >>>>>> rev=0x00 >>>>>> hdr=0x00 >>>>>> vendor = 'Advanced Micro Devices (AMD)' >>>>>> device = '(Family 10h) Athlon64/Opteron/Sempron Miscellaneous >>>>>> Control' >>>>>> class = bridge >>>>>> subclass = HOST-PCI >>>>>> hostb5@pci0:0:24:4: class=0x060000 card=0x00000000 chip=0x12041022 >>>>>> rev=0x00 >>>>>> hdr=0x00 >>>>>> vendor = 'Advanced Micro Devices (AMD)' >>>>>> device = '(Family 10h) Athlon64/Opteron/Sempron Link Control' >>>>>> class = bridge >>>>>> subclass = HOST-PCI >>>>>> mpt0@pci0:1:0:0: class=0x010000 card=0xa58015d9 chip=0x00581000 >>>>>> rev=0x08 >>>>>> hdr=0x00 >>>>>> vendor = 'LSI Logic (Was: Symbios Logic, NCR)' >>>>>> device = 'SAS 3000 series, 8-port with 1068E -StorPort' >>>>>> class = mass storage >>>>>> subclass = SCSI >>>>>> mpt1@pci0:2:0:0: class=0x010000 card=0xa58015d9 chip=0x00581000 >>>>>> rev=0x08 >>>>>> hdr=0x00 >>>>>> vendor = 'LSI Logic (Was: Symbios Logic, NCR)' >>>>>> device = 'SAS 3000 series, 8-port with 1068E -StorPort' >>>>>> class = mass storage >>>>>> subclass = SCSI >>>>>> atapci0@pci0:3:0:0: class=0x01018f card=0x612111ab chip=0x612111ab >>>>>> rev=0xb1 >>>>>> hdr=0x00 >>>>>> vendor = 'Marvell Semiconductor (Was: Galileo Technology Ltd)' >>>>>> device = '6121 SATA2 Controller' >>>>>> class = mass storage >>>>>> subclass = ATA >>>>>> mskc0@pci0:4:0:0: class=0x020000 card=0x81f81043 chip=0x436411ab >>>>>> rev=0x12 >>>>>> hdr=0x00 >>>>>> vendor = 'Marvell Semiconductor (Was: Galileo Technology Ltd)' >>>>>> device = 'Yukon PCI-E Gigabit Ethernet Controller (88E8056)' >>>>>> class = network >>>>>> subclass = ethernet >>>>>> atapci2@pci0:5:0:0: class=0x01018f card=0x612111ab chip=0x612111ab >>>>>> rev=0xb2 >>>>>> hdr=0x00 >>>>>> vendor = 'Marvell Semiconductor (Was: Galileo Technology Ltd)' >>>>>> device = '6121 SATA2 Controller' >>>>>> class = mass storage >>>>>> subclass = ATA >>>>>> mpt2@pci0:6:0:0: class=0x010000 card=0x30a01000 chip=0x00581000 >>>>>> rev=0x08 >>>>>> hdr=0x00 >>>>>> vendor = 'LSI Logic (Was: Symbios Logic, NCR)' >>>>>> device = 'SAS 3000 series, 8-port with 1068E -StorPort' >>>>>> class = mass storage >>>>>> subclass = SCSI >>>>>> em0@pci0:7:5:0: class=0x020000 card=0x13768086 chip=0x107c8086 >>>>>> rev=0x05 >>>>>> hdr=0x00 >>>>>> vendor = 'Intel Corporation' >>>>>> device = 'Gigabit Ethernet Controller (Copper) rev 5 (82541PI)' >>>>>> class = network >>>>>> subclass = ethernet >>>>>> vgapci0@pci0:7:6:0: class=0x030000 card=0x00000000 chip=0x88115333 >>>>>> rev=0x44 >>>>>> hdr=0x00 >>>>>> vendor = 'S3 Graphics Co., Ltd' >>>>>> device = '86C732 Trio32, 86C764 Trio64, 86C765 Trio64V+ Rev 01' >>>>>> class = display >>>>>> subclass = VGA >>>>>> none2@pci0:7:8:0: class=0x0c0010 card=0x82941043 chip=0x581111c1 >>>>>> rev=0x70 >>>>>> hdr=0x00 >>>>>> vendor = 'Lucent/Agere Systems (Was: AT&T MicroElectronics)' >>>>>> device = '1394A PCI PHY/Link Open Host Ctrlr I/F (FW322)' >>>>>> class = serial bus >>>>>> subclass = FireWire >>>>>> [josh@foghornleghorn /var/log]$ sudo su - >>>>>> foghornleghorn# pciconf -lvcb >>>>>> hostb0@pci0:0:0:0: class=0x060000 card=0x59561002 chip=0x59561002 >>>>>> rev=0x00 >>>>>> hdr=0x00 >>>>>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>>>>> device = 'RD790 GFX Dual Slot' >>>>>> class = bridge >>>>>> subclass = HOST-PCI >>>>>> cap 08[c4] = HT slave >>>>>> cap 08[40] = HT retry mode >>>>>> cap 08[54] = HT unit ID clumping >>>>>> cap 08[9c] = HT unknown d03c >>>>>> pcib1@pci0:0:2:0: class=0x060400 card=0x59561002 chip=0x59781002 >>>>>> rev=0x00 >>>>>> hdr=0x01 >>>>>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>>>>> device = 'RD790 PCI to PCI bridge (external gfx0 port A)' >>>>>> class = bridge >>>>>> subclass = PCI-PCI >>>>>> cap 01[50] = powerspec 3 supports D0 D3 current D0 >>>>>> cap 10[58] = PCI-Express 2 root port max data 128(128) link x4(x8) >>>>>> cap 05[a0] = MSI supports 1 message >>>>>> cap 0d[b0] = PCI Bridge card=0x59561002 >>>>>> cap 08[b8] = HT MSI fixed address window enabled at 0xfee00000 >>>>>> ecap 000b[100] = unknown 1 >>>>>> ecap 0002[110] = VC 1 max VC0 >>>>>> pcib2@pci0:0:3:0: class=0x060400 card=0x59561002 chip=0x59791002 >>>>>> rev=0x00 >>>>>> hdr=0x01 >>>>>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>>>>> device = 'RD790 PCI to PCI bridge (external gfx0 port B)' >>>>>> class = bridge >>>>>> subclass = PCI-PCI >>>>>> cap 01[50] = powerspec 3 supports D0 D3 current D0 >>>>>> cap 10[58] = PCI-Express 2 root port max data 128(128) link x4(x8) >>>>>> cap 05[a0] = MSI supports 1 message >>>>>> cap 0d[b0] = PCI Bridge card=0x59561002 >>>>>> cap 08[b8] = HT MSI fixed address window enabled at 0xfee00000 >>>>>> ecap 000b[100] = unknown 1 >>>>>> ecap 0002[110] = VC 1 max VC0 >>>>>> pcib3@pci0:0:4:0: class=0x060400 card=0x59561002 chip=0x597a1002 >>>>>> rev=0x00 >>>>>> hdr=0x01 >>>>>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>>>>> device = 'RD790 PCI to PCI bridge (PCIe gpp port A)' >>>>>> class = bridge >>>>>> subclass = PCI-PCI >>>>>> cap 01[50] = powerspec 3 supports D0 D3 current D0 >>>>>> cap 10[58] = PCI-Express 2 root port max data 128(128) link x1(x2) >>>>>> cap 05[a0] = MSI supports 1 message >>>>>> cap 0d[b0] = PCI Bridge card=0x59561002 >>>>>> cap 08[b8] = HT MSI fixed address window enabled at 0xfee00000 >>>>>> ecap 000b[100] = unknown 1 >>>>>> ecap 0002[110] = VC 1 max VC0 >>>>>> pcib4@pci0:0:6:0: class=0x060400 card=0x59561002 chip=0x597c1002 >>>>>> rev=0x00 >>>>>> hdr=0x01 >>>>>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>>>>> device = 'RD790 PCI to PCI bridge (PCIe gpp port C)' >>>>>> class = bridge >>>>>> subclass = PCI-PCI >>>>>> cap 01[50] = powerspec 3 supports D0 D3 current D0 >>>>>> cap 10[58] = PCI-Express 2 root port max data 128(128) link x1(x1) >>>>>> cap 05[a0] = MSI supports 1 message >>>>>> cap 0d[b0] = PCI Bridge card=0x59561002 >>>>>> cap 08[b8] = HT MSI fixed address window enabled at 0xfee00000 >>>>>> ecap 000b[100] = unknown 1 >>>>>> ecap 0002[110] = VC 1 max VC0 >>>>>> pcib5@pci0:0:7:0: class=0x060400 card=0x59561002 chip=0x597d1002 >>>>>> rev=0x00 >>>>>> hdr=0x01 >>>>>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>>>>> device = 'RD790 PCI to PCI bridge (PCIe gpp port D)' >>>>>> class = bridge >>>>>> subclass = PCI-PCI >>>>>> cap 01[50] = powerspec 3 supports D0 D3 current D0 >>>>>> cap 10[58] = PCI-Express 2 root port max data 128(128) link x1(x1) >>>>>> cap 05[a0] = MSI supports 1 message >>>>>> cap 0d[b0] = PCI Bridge card=0x59561002 >>>>>> cap 08[b8] = HT MSI fixed address window enabled at 0xfee00000 >>>>>> ecap 000b[100] = unknown 1 >>>>>> ecap 0002[110] = VC 1 max VC0 >>>>>> pcib6@pci0:0:11:0: class=0x060400 card=0x59561002 chip=0x59801002 >>>>>> rev=0x00 >>>>>> hdr=0x01 >>>>>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>>>>> device = 'RD790 PCI to PCI bridge (external gfx1 port A)' >>>>>> class = bridge >>>>>> subclass = PCI-PCI >>>>>> cap 01[50] = powerspec 3 supports D0 D3 current D0 >>>>>> cap 10[58] = PCI-Express 2 root port max data 128(128) link x4(x8) >>>>>> cap 05[a0] = MSI supports 1 message >>>>>> cap 0d[b0] = PCI Bridge card=0x59561002 >>>>>> cap 08[b8] = HT MSI fixed address window enabled at 0xfee00000 >>>>>> ecap 000b[100] = unknown 1 >>>>>> ecap 0002[110] = VC 1 max VC0 >>>>>> atapci4@pci0:0:18:0: class=0x01018f card=0x81ef1043 chip=0x43801002 >>>>>> rev=0x00 >>>>>> hdr=0x00 >>>>>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>>>>> device = 'IXP SB600 Serial ATA Controller' >>>>>> class = mass storage >>>>>> subclass = ATA >>>>>> bar [10] = type I/O Port, range 32, base 0x5000, size 8, enabled >>>>>> bar [14] = type I/O Port, range 32, base 0x4000, size 4, enabled >>>>>> bar [18] = type I/O Port, range 32, base 0x3000, size 8, enabled >>>>>> bar [1c] = type I/O Port, range 32, base 0x2000, size 4, enabled >>>>>> bar [20] = type I/O Port, range 32, base 0x1000, size 16, enabled >>>>>> bar [24] = type Memory, range 32, base 0xf71ff800, size 1024, >>>>>> enabled >>>>>> cap 01[60] = powerspec 2 supports D0 D3 current D0 >>>>>> ohci0@pci0:0:19:0: class=0x0c0310 card=0x82881043 chip=0x43871002 >>>>>> rev=0x00 >>>>>> hdr=0x00 >>>>>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>>>>> device = 'IXP SB600 USB Controller (OHCI0)' >>>>>> class = serial bus >>>>>> subclass = USB >>>>>> bar [10] = type Memory, range 32, base 0xf71fe000, size 4096, >>>>>> enabled >>>>>> ohci1@pci0:0:19:1: class=0x0c0310 card=0x82881043 chip=0x43881002 >>>>>> rev=0x00 >>>>>> hdr=0x00 >>>>>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>>>>> device = 'IXP SB600 USB Controller (OHCI1)' >>>>>> class = serial bus >>>>>> subclass = USB >>>>>> bar [10] = type Memory, range 32, base 0xf71fd000, size 4096, >>>>>> enabled >>>>>> ohci2@pci0:0:19:2: class=0x0c0310 card=0x82881043 chip=0x43891002 >>>>>> rev=0x00 >>>>>> hdr=0x00 >>>>>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>>>>> device = 'IXP SB600 USB Controller (OHCI2)' >>>>>> class = serial bus >>>>>> subclass = USB >>>>>> bar [10] = type Memory, range 32, base 0xf71fc000, size 4096, >>>>>> enabled >>>>>> ohci3@pci0:0:19:3: class=0x0c0310 card=0x82881043 chip=0x438a1002 >>>>>> rev=0x00 >>>>>> hdr=0x00 >>>>>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>>>>> device = 'IXP SB600 USB Controller (OHCI3)' >>>>>> class = serial bus >>>>>> subclass = USB >>>>>> bar [10] = type Memory, range 32, base 0xf71fb000, size 4096, >>>>>> enabled >>>>>> ohci4@pci0:0:19:4: class=0x0c0310 card=0x82881043 chip=0x438b1002 >>>>>> rev=0x00 >>>>>> hdr=0x00 >>>>>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>>>>> device = 'IXP SB600 USB Controller (OHCI4)' >>>>>> class = serial bus >>>>>> subclass = USB >>>>>> bar [10] = type Memory, range 32, base 0xf71fa000, size 4096, >>>>>> enabled >>>>>> ehci0@pci0:0:19:5: class=0x0c0320 card=0x82881043 chip=0x43861002 >>>>>> rev=0x00 >>>>>> hdr=0x00 >>>>>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>>>>> device = 'IXP SB600 USB Controller (EHCI)' >>>>>> class = serial bus >>>>>> subclass = USB >>>>>> bar [10] = type Memory, range 32, base 0xf71ff000, size 256, >>>>>> enabled >>>>>> cap 01[c0] = powerspec 2 supports D0 D1 D2 D3 current D0 >>>>>> cap 05[d0] = MSI supports 1 message >>>>>> cap 0a[e4] = EHCI Debug Port at offset 0xe0 in map 0x14 >>>>>> none0@pci0:0:20:0: class=0x0c0500 card=0x82881043 chip=0x43851002 >>>>>> rev=0x14 >>>>>> hdr=0x00 >>>>>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>>>>> device = 'ATI SMBus (ATI RD600/RS600)' >>>>>> class = serial bus >>>>>> subclass = SMBus >>>>>> bar [10] = type I/O Port, range 32, base 0xb00, size 16, enabled >>>>>> cap 08[b0] = HT MSI fixed address window disabled at 0xfee00000 >>>>>> atapci5@pci0:0:20:1: class=0x01018a card=0x82881043 chip=0x438c1002 >>>>>> rev=0x00 >>>>>> hdr=0x00 >>>>>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>>>>> device = 'ATI RD600/RS600 IDE Controller (RD600/RS600)' >>>>>> class = mass storage >>>>>> subclass = ATA >>>>>> bar [10] = type I/O Port, range 32, base 0x1f0, size 8, enabled >>>>>> bar [14] = type I/O Port, range 32, base 0x3f4, size 1, enabled >>>>>> bar [18] = type I/O Port, range 32, base 0x170, size 8, enabled >>>>>> bar [1c] = type I/O Port, range 32, base 0x374, size 1, enabled >>>>>> bar [20] = type I/O Port, range 32, base 0xff00, size 16, enabled >>>>>> none1@pci0:0:20:2: class=0x040300 card=0x82881043 chip=0x43831002 >>>>>> rev=0x00 >>>>>> hdr=0x00 >>>>>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>>>>> device = 'IXP SB600 High Definition Audio Controller' >>>>>> class = multimedia >>>>>> subclass = HDA >>>>>> bar [10] = type Memory, range 64, base 0xf71f4000, size 16384, >>>>>> enabled >>>>>> cap 01[50] = powerspec 2 supports D0 D3 current D0 >>>>>> isab0@pci0:0:20:3: class=0x060100 card=0x82881043 chip=0x438d1002 >>>>>> rev=0x00 >>>>>> hdr=0x00 >>>>>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>>>>> device = 'IXP SB600 PCI to LPC Bridge' >>>>>> class = bridge >>>>>> subclass = PCI-ISA >>>>>> pcib7@pci0:0:20:4: class=0x060401 card=0x00000000 chip=0x43841002 >>>>>> rev=0x00 >>>>>> hdr=0x01 >>>>>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>>>>> device = 'IXP SB600 PCI to PCI Bridge' >>>>>> class = bridge >>>>>> subclass = PCI-PCI >>>>>> hostb1@pci0:0:24:0: class=0x060000 card=0x00000000 chip=0x12001022 >>>>>> rev=0x00 >>>>>> hdr=0x00 >>>>>> vendor = 'Advanced Micro Devices (AMD)' >>>>>> device = '(Family 10h) Athlon64/Opteron/Sempron HyperTransport >>>>>> Technology Configuration' >>>>>> class = bridge >>>>>> subclass = HOST-PCI >>>>>> cap 08[80] = HT host >>>>>> hostb2@pci0:0:24:1: class=0x060000 card=0x00000000 chip=0x12011022 >>>>>> rev=0x00 >>>>>> hdr=0x00 >>>>>> vendor = 'Advanced Micro Devices (AMD)' >>>>>> device = '(Family 10h) Athlon64/Opteron/Sempron Address Map' >>>>>> class = bridge >>>>>> subclass = HOST-PCI >>>>>> hostb3@pci0:0:24:2: class=0x060000 card=0x00000000 chip=0x12021022 >>>>>> rev=0x00 >>>>>> hdr=0x00 >>>>>> vendor = 'Advanced Micro Devices (AMD)' >>>>>> device = '(Family 10h) Athlon64/Opteron/Sempron DRAM >>>>>> Controller' >>>>>> class = bridge >>>>>> subclass = HOST-PCI >>>>>> hostb4@pci0:0:24:3: class=0x060000 card=0x00000000 chip=0x12031022 >>>>>> rev=0x00 >>>>>> hdr=0x00 >>>>>> vendor = 'Advanced Micro Devices (AMD)' >>>>>> device = '(Family 10h) Athlon64/Opteron/Sempron Miscellaneous >>>>>> Control' >>>>>> class = bridge >>>>>> subclass = HOST-PCI >>>>>> cap 0f[f0] = unknown >>>>>> hostb5@pci0:0:24:4: class=0x060000 card=0x00000000 chip=0x12041022 >>>>>> rev=0x00 >>>>>> hdr=0x00 >>>>>> vendor = 'Advanced Micro Devices (AMD)' >>>>>> device = '(Family 10h) Athlon64/Opteron/Sempron Link Control' >>>>>> class = bridge >>>>>> subclass = HOST-PCI >>>>>> mpt0@pci0:1:0:0: class=0x010000 card=0xa58015d9 chip=0x00581000 >>>>>> rev=0x08 >>>>>> hdr=0x00 >>>>>> vendor = 'LSI Logic (Was: Symbios Logic, NCR)' >>>>>> device = 'SAS 3000 series, 8-port with 1068E -StorPort' >>>>>> class = mass storage >>>>>> subclass = SCSI >>>>>> bar [10] = type I/O Port, range 32, base 0x6000, size 256, >>>>>> disabled >>>>>> bar [14] = type Memory, range 64, base 0xf75fc000, size 16384, >>>>>> enabled >>>>>> bar [1c] = type Memory, range 64, base 0xf75e0000, size 65536, >>>>>> enabled >>>>>> cap 01[50] = powerspec 2 supports D0 D1 D2 D3 current D0 >>>>>> cap 10[68] = PCI-Express 1 endpoint max data 128(4096) link x4(x8) >>>>>> cap 05[98] = MSI supports 1 message, 64 bit >>>>>> cap 11[b0] = MSI-X supports 1 message in map 0x14 >>>>>> ecap 0001[100] = AER 1 1 fatal 1 non-fatal 0 corrected >>>>>> mpt1@pci0:2:0:0: class=0x010000 card=0xa58015d9 chip=0x00581000 >>>>>> rev=0x08 >>>>>> hdr=0x00 >>>>>> vendor = 'LSI Logic (Was: Symbios Logic, NCR)' >>>>>> device = 'SAS 3000 series, 8-port with 1068E -StorPort' >>>>>> class = mass storage >>>>>> subclass = SCSI >>>>>> bar [10] = type I/O Port, range 32, base 0x7000, size 256, >>>>>> disabled >>>>>> bar [14] = type Memory, range 64, base 0xf78fc000, size 16384, >>>>>> enabled >>>>>> bar [1c] = type Memory, range 64, base 0xf78e0000, size 65536, >>>>>> enabled >>>>>> cap 01[50] = powerspec 2 supports D0 D1 D2 D3 current D0 >>>>>> cap 10[68] = PCI-Express 1 endpoint max data 128(4096) link x4(x8) >>>>>> cap 05[98] = MSI supports 1 message, 64 bit >>>>>> cap 11[b0] = MSI-X supports 1 message in map 0x14 >>>>>> ecap 0001[100] = AER 1 1 fatal 1 non-fatal 0 corrected >>>>>> atapci0@pci0:3:0:0: class=0x01018f card=0x612111ab chip=0x612111ab >>>>>> rev=0xb1 >>>>>> hdr=0x00 >>>>>> vendor = 'Marvell Semiconductor (Was: Galileo Technology Ltd)' >>>>>> device = '6121 SATA2 Controller' >>>>>> class = mass storage >>>>>> subclass = ATA >>>>>> bar [10] = type I/O Port, range 32, base 0x9800, size 8, enabled >>>>>> bar [14] = type I/O Port, range 32, base 0x9400, size 4, enabled >>>>>> bar [18] = type I/O Port, range 32, base 0x9000, size 8, enabled >>>>>> bar [1c] = type I/O Port, range 32, base 0x8800, size 4, enabled >>>>>> bar [20] = type I/O Port, range 32, base 0x8400, size 16, enabled >>>>>> bar [24] = type Memory, range 32, base 0xf79ffc00, size 1024, >>>>>> enabled >>>>>> cap 01[48] = powerspec 2 supports D0 D1 D3 current D0 >>>>>> cap 05[50] = MSI supports 1 message >>>>>> cap 10[e0] = PCI-Express 1 legacy endpoint max data 128(128) link >>>>>> x1(x1) >>>>>> ecap 0001[100] = AER 1 0 fatal 0 non-fatal 2 corrected >>>>>> mskc0@pci0:4:0:0: class=0x020000 card=0x81f81043 chip=0x436411ab >>>>>> rev=0x12 >>>>>> hdr=0x00 >>>>>> vendor = 'Marvell Semiconductor (Was: Galileo Technology Ltd)' >>>>>> device = 'Yukon PCI-E Gigabit Ethernet Controller (88E8056)' >>>>>> class = network >>>>>> subclass = ethernet >>>>>> bar [10] = type Memory, range 64, base 0xf7afc000, size 16384, >>>>>> enabled >>>>>> bar [18] = type I/O Port, range 32, base 0xa800, size 256, >>>>>> enabled >>>>>> cap 01[48] = powerspec 3 supports D0 D1 D2 D3 current D0 >>>>>> cap 03[50] = VPD >>>>>> cap 05[5c] = MSI supports 1 message, 64 bit enabled with 1 message >>>>>> cap 10[e0] = PCI-Express 1 legacy endpoint max data 128(128) link >>>>>> x1(x1) >>>>>> ecap 0001[100] = AER 1 0 fatal 0 non-fatal 1 corrected >>>>>> atapci2@pci0:5:0:0: class=0x01018f card=0x612111ab chip=0x612111ab >>>>>> rev=0xb2 >>>>>> hdr=0x00 >>>>>> vendor = 'Marvell Semiconductor (Was: Galileo Technology Ltd)' >>>>>> device = '6121 SATA2 Controller' >>>>>> class = mass storage >>>>>> subclass = ATA >>>>>> bar [10] = type I/O Port, range 32, base 0xc800, size 8, enabled >>>>>> bar [14] = type I/O Port, range 32, base 0xc400, size 4, enabled >>>>>> bar [18] = type I/O Port, range 32, base 0xc000, size 8, enabled >>>>>> bar [1c] = type I/O Port, range 32, base 0xb800, size 4, enabled >>>>>> bar [20] = type I/O Port, range 32, base 0xb400, size 16, enabled >>>>>> bar [24] = type Memory, range 32, base 0xf7bffc00, size 1024, >>>>>> enabled >>>>>> cap 01[48] = powerspec 2 supports D0 D1 D3 current D0 >>>>>> cap 05[50] = MSI supports 1 message >>>>>> cap 10[e0] = PCI-Express 1 legacy endpoint max data 128(128) link >>>>>> x1(x1) >>>>>> ecap 0001[100] = AER 1 0 fatal 0 non-fatal 1 corrected >>>>>> mpt2@pci0:6:0:0: class=0x010000 card=0x30a01000 chip=0x00581000 >>>>>> rev=0x08 >>>>>> hdr=0x00 >>>>>> vendor = 'LSI Logic (Was: Symbios Logic, NCR)' >>>>>> device = 'SAS 3000 series, 8-port with 1068E -StorPort' >>>>>> class = mass storage >>>>>> subclass = SCSI >>>>>> bar [10] = type I/O Port, range 32, base 0xd000, size 256, >>>>>> disabled >>>>>> bar [14] = type Memory, range 64, base 0xf7ffc000, size 16384, >>>>>> enabled >>>>>> bar [1c] = type Memory, range 64, base 0xf7fe0000, size 65536, >>>>>> enabled >>>>>> cap 01[50] = powerspec 2 supports D0 D1 D2 D3 current D0 >>>>>> cap 10[68] = PCI-Express 1 endpoint max data 128(4096) link x4(x8) >>>>>> cap 05[98] = MSI supports 1 message, 64 bit >>>>>> cap 11[b0] = MSI-X supports 1 message in map 0x14 >>>>>> ecap 0001[100] = AER 1 1 fatal 1 non-fatal 0 corrected >>>>>> em0@pci0:7:5:0: class=0x020000 card=0x13768086 chip=0x107c8086 >>>>>> rev=0x05 >>>>>> hdr=0x00 >>>>>> vendor = 'Intel Corporation' >>>>>> device = 'Gigabit Ethernet Controller (Copper) rev 5 (82541PI)' >>>>>> class = network >>>>>> subclass = ethernet >>>>>> bar [10] = type Memory, range 32, base 0xfebe0000, size 131072, >>>>>> enabled >>>>>> bar [14] = type Memory, range 32, base 0xfebc0000, size 131072, >>>>>> enabled >>>>>> bar [18] = type I/O Port, range 32, base 0xe800, size 64, enabled >>>>>> cap 01[dc] = powerspec 2 supports D0 D3 current D0 >>>>>> cap 07[e4] = PCI-X supports 2048 burst read, 1 split transaction >>>>>> vgapci0@pci0:7:6:0: class=0x030000 card=0x00000000 chip=0x88115333 >>>>>> rev=0x44 >>>>>> hdr=0x00 >>>>>> vendor = 'S3 Graphics Co., Ltd' >>>>>> device = '86C732 Trio32, 86C764 Trio64, 86C765 Trio64V+ Rev 01' >>>>>> class = display >>>>>> subclass = VGA >>>>>> bar [10] = type Memory, range 32, base 0xf8000000, size 67108864, >>>>>> enabled >>>>>> none2@pci0:7:8:0: class=0x0c0010 card=0x82941043 chip=0x581111c1 >>>>>> rev=0x70 >>>>>> hdr=0x00 >>>>>> vendor = 'Lucent/Agere Systems (Was: AT&T MicroElectronics)' >>>>>> device = '1394A PCI PHY/Link Open Host Ctrlr I/F (FW322)' >>>>>> class = serial bus >>>>>> subclass = FireWire >>>>>> bar [10] = type Memory, range 32, base 0xfeb8f000, size 4096, >>>>>> enabled >>>>>> cap 01[44] = powerspec 2 supports D0 D1 D2 D3 current D0 >>>>>> >>>>>> >>>>>> >>>>>> > # vmstat -i >>>>>> > >>>>>> >>>>>> interrupt total rate >>>>>> irq9: acpi0 1 0 >>>>>> irq16: atapci0+ 2 0 >>>>>> irq17: ohci1 ohci3 3 0 >>>>>> irq18: mpt0 ohci2+ 7066718 31 >>>>>> irq19: mpt1 atapci* 7798877 34 >>>>>> irq20: em0 11715792 51 >>>>>> irq22: atapci4 628883 2 >>>>>> cpu0: timer 455853831 1999 >>>>>> irq256: mskc0 97098730 425 >>>>>> cpu1: timer 455845190 1999 >>>>>> Total 1036008027 4544 >>>>>> >>>>>> >>>>>> >>>>>> > # sysctl -a | grep msi >>>>>> > >>>>>> >>>>>> hw.pci.honor_msi_blacklist: 1 >>>>>> hw.pci.enable_msix: 1 >>>>>> hw.pci.enable_msi: 1 >>>>>> >>>>>> >>>>>> >>>>>> > # dmesg >>>>>> > >>>>>> >>>>>> Copyright (c) 1992-2011 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 8.2-STABLE #17: Mon Jun 6 19:40:19 EDT 2011 >>>>>> root@foghornleghorn.res.openband.net: >>>>>> /usr/obj/usr/src/sys/FOGHORNLEGHORN >>>>>> amd64 >>>>>> Timecounter "i8254" frequency 1193182 Hz quality 0 >>>>>> CPU: AMD Phenom(tm) II X2 555 Processor (3209.77-MHz K8-class CPU) >>>>>> Origin = "AuthenticAMD" Id = 0x100f43 Family = 10 Model = 4 >>>>>> Stepping = >>>>>> 3 >>>>>> >>>>>> >>>>>> Features=0x178bfbff >>>>>> Features2=0x802009 >>>>>> AMD >>>>>> >>>>>> Features=0xee500800 >>>>>> AMD >>>>>> >>>>>> Features2=0x37ff >>>>>> TSC: P-state invariant >>>>>> real memory = 8589934592 (8192 MB) >>>>>> avail memory = 8257736704 (7875 MB) >>>>>> ACPI APIC Table: <092310 OEMAPIC > >>>>>> FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs >>>>>> FreeBSD/SMP: 1 package(s) x 2 core(s) >>>>>> cpu0 (BSP): APIC ID: 0 >>>>>> cpu1 (AP): APIC ID: 1 >>>>>> ioapic0 irqs 0-23 on motherboard >>>>>> acpi0: <092310 OEMRSDT> on motherboard >>>>>> acpi0: [ITHREAD] >>>>>> acpi0: Power Button (fixed) >>>>>> acpi0: reservation of fee00000, 1000 (3) failed >>>>>> acpi0: reservation of ffb80000, 80000 (3) failed >>>>>> acpi0: reservation of fff00000, 100000 (3) failed >>>>>> acpi0: reservation of 0, a0000 (3) failed >>>>>> acpi0: reservation of 100000, dff00000 (3) failed >>>>>> Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 >>>>>> acpi_timer0: <32-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 >>>>>> cpu0: on acpi0 >>>>>> cpu1: on acpi0 >>>>>> acpi_hpet0: iomem 0xfed00000-0xfed003ff >>>>>> on >>>>>> acpi0 >>>>>> Timecounter "HPET" frequency 14318180 Hz quality 900 >>>>>> pcib0: port 0xcf8-0xcff on acpi0 >>>>>> pci0: on pcib0 >>>>>> pcib1: irq 18 at device 2.0 on pci0 >>>>>> pci1: on pcib1 >>>>>> mpt0: port 0x6000-0x60ff mem >>>>>> 0xf75fc000-0xf75fffff,0xf75e0000-0xf75effff irq 18 at device 0.0 on >>>>>> pci1 >>>>>> mpt0: [ITHREAD] >>>>>> mpt0: MPI Version=1.5.20.0 >>>>>> pcib2: irq 19 at device 3.0 on pci0 >>>>>> pci2: on pcib2 >>>>>> mpt1: port 0x7000-0x70ff mem >>>>>> 0xf78fc000-0xf78fffff,0xf78e0000-0xf78effff irq 19 at device 0.0 on >>>>>> pci2 >>>>>> mpt1: [ITHREAD] >>>>>> mpt1: MPI Version=1.5.20.0 >>>>>> pcib3: irq 16 at device 4.0 on pci0 >>>>>> pci3: on pcib3 >>>>>> atapci0: port >>>>>> 0x9800-0x9807,0x9400-0x9403,0x9000-0x9007,0x8800-0x8803,0x8400-0x840f >>>>>> mem >>>>>> 0xf79ffc00-0xf79fffff irq 16 at device 0.0 on pci3 >>>>>> atapci0: [ITHREAD] >>>>>> atapci1: on atapci0 >>>>>> atapci1: [ITHREAD] >>>>>> atapci1: AHCI v1.00 controller with 3 3Gbps ports, PM supported >>>>>> ata2: on atapci1 >>>>>> ata2: [ITHREAD] >>>>>> ata3: on atapci1 >>>>>> ata3: [ITHREAD] >>>>>> ata4: on atapci0 >>>>>> ata4: [ITHREAD] >>>>>> pcib4: irq 18 at device 6.0 on pci0 >>>>>> pci4: on pcib4 >>>>>> mskc0: port 0xa800-0xa8ff mem >>>>>> 0xf7afc000-0xf7afffff irq 18 at device 0.0 on pci4 >>>>>> msk0: >>>>>> on >>>>>> mskc0 >>>>>> msk0: Ethernet address: 00:1f:c6:e9:f8:7c >>>>>> miibus0: on msk0 >>>>>> e1000phy0: PHY 0 on miibus0 >>>>>> e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, >>>>>> 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow >>>>>> mskc0: [ITHREAD] >>>>>> pcib5: irq 19 at device 7.0 on pci0 >>>>>> pci5: on pcib5 >>>>>> atapci2: port >>>>>> 0xc800-0xc807,0xc400-0xc403,0xc000-0xc007,0xb800-0xb803,0xb400-0xb40f >>>>>> mem >>>>>> 0xf7bffc00-0xf7bfffff irq 19 at device 0.0 on pci5 >>>>>> atapci2: [ITHREAD] >>>>>> atapci3: on atapci2 >>>>>> atapci3: [ITHREAD] >>>>>> atapci3: AHCI v1.00 controller with 3 3Gbps ports, PM supported >>>>>> ata5: on atapci3 >>>>>> ata5: [ITHREAD] >>>>>> ata6: on atapci3 >>>>>> ata6: [ITHREAD] >>>>>> ata7: on atapci2 >>>>>> ata7: [ITHREAD] >>>>>> pcib6: irq 19 at device 11.0 on pci0 >>>>>> pci6: on pcib6 >>>>>> mpt2: port 0xd000-0xd0ff mem >>>>>> 0xf7ffc000-0xf7ffffff,0xf7fe0000-0xf7feffff irq 19 at device 0.0 on >>>>>> pci6 >>>>>> mpt2: [ITHREAD] >>>>>> mpt2: MPI Version=1.5.19.0 >>>>>> atapci4: port >>>>>> 0x5000-0x5007,0x4000-0x4003,0x3000-0x3007,0x2000-0x2003,0x1000-0x100f >>>>>> mem >>>>>> 0xf71ff800-0xf71ffbff irq 22 at device 18.0 on pci0 >>>>>> atapci4: [ITHREAD] >>>>>> atapci4: AHCI v1.10 controller with 4 3Gbps ports, PM supported >>>>>> ata8: on atapci4 >>>>>> ata8: port is not ready (timeout 0ms) tfd = 000001d0 >>>>>> ata8: software reset clear timeout >>>>>> ata8: [ITHREAD] >>>>>> ata9: on atapci4 >>>>>> ata9: [ITHREAD] >>>>>> ata10: on atapci4 >>>>>> ata10: [ITHREAD] >>>>>> ata11: on atapci4 >>>>>> ata11: [ITHREAD] >>>>>> ohci0: mem 0xf71fe000-0xf71fefff irq >>>>>> 16 at >>>>>> device 19.0 on pci0 >>>>>> ohci0: [ITHREAD] >>>>>> usbus0: on ohci0 >>>>>> ohci1: mem 0xf71fd000-0xf71fdfff irq >>>>>> 17 at >>>>>> device 19.1 on pci0 >>>>>> ohci1: [ITHREAD] >>>>>> usbus1: on ohci1 >>>>>> ohci2: mem 0xf71fc000-0xf71fcfff irq >>>>>> 18 at >>>>>> device 19.2 on pci0 >>>>>> ohci2: [ITHREAD] >>>>>> usbus2: on ohci2 >>>>>> ohci3: mem 0xf71fb000-0xf71fbfff irq >>>>>> 17 at >>>>>> device 19.3 on pci0 >>>>>> ohci3: [ITHREAD] >>>>>> usbus3: on ohci3 >>>>>> ohci4: mem 0xf71fa000-0xf71fafff irq >>>>>> 18 at >>>>>> device 19.4 on pci0 >>>>>> ohci4: [ITHREAD] >>>>>> usbus4: on ohci4 >>>>>> ehci0: mem 0xf71ff000-0xf71ff0ff >>>>>> irq 19 >>>>>> at device 19.5 on pci0 >>>>>> ehci0: [ITHREAD] >>>>>> ehci0: AMD SB600/700 quirk applied >>>>>> usbus5: EHCI version 1.0 >>>>>> usbus5: on ehci0 >>>>>> pci0: at device 20.0 (no driver attached) >>>>>> atapci5: port >>>>>> 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xff00-0xff0f at device 20.1 on >>>>>> pci0 >>>>>> ata0: on atapci5 >>>>>> ata0: [ITHREAD] >>>>>> pci0: at device 20.2 (no driver attached) >>>>>> isab0: at device 20.3 on pci0 >>>>>> isa0: on isab0 >>>>>> pcib7: at device 20.4 on pci0 >>>>>> pci7: on pcib7 >>>>>> em0: port >>>>>> 0xe800-0xe83f >>>>>> mem 0xfebe0000-0xfebfffff,0xfebc0000-0xfebdffff irq 20 at device 5.0 >>>>>> on pci7 >>>>>> em0: [FILTER] >>>>>> em0: Ethernet address: 00:1b:21:4e:e5:2e >>>>>> vgapci0: mem 0xf8000000-0xfbffffff at device >>>>>> 6.0 on >>>>>> pci7 >>>>>> pci7: at device 8.0 (no driver attached) >>>>>> acpi_button0: on acpi0 >>>>>> atrtc0: port 0x70-0x71 irq 8 on acpi0 >>>>>> acpi_hpet1: iomem 0xfed00000-0xfed003ff >>>>>> on >>>>>> acpi0 >>>>>> device_attach: acpi_hpet1 attach returned 12 >>>>>> uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on >>>>>> acpi0 >>>>>> uart0: [FILTER] >>>>>> orm0: at iomem >>>>>> 0xc0000-0xc7fff,0xc8000-0xc87ff,0xc8800-0xc97ff on isa0 >>>>>> sc0: at flags 0x100 on isa0 >>>>>> sc0: VGA <16 virtual consoles, flags=0x300> >>>>>> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on >>>>>> isa0 >>>>>> acpi_throttle0: on cpu0 >>>>>> acpi_throttle0: CLK_VAL field overlaps THT_EN bit >>>>>> device_attach: acpi_throttle0 attach returned 6 >>>>>> hwpstate0: on cpu0 >>>>>> Timecounters tick every 1.000 msec >>>>>> usbus0: 12Mbps Full Speed USB v1.0 >>>>>> usbus1: 12Mbps Full Speed USB v1.0 >>>>>> usbus2: 12Mbps Full Speed USB v1.0 >>>>>> usbus3: 12Mbps Full Speed USB v1.0 >>>>>> usbus4: 12Mbps Full Speed USB v1.0 >>>>>> usbus5: 480Mbps High Speed USB v2.0 >>>>>> ugen0.1: at usbus0 >>>>>> uhub0: on usbus0 >>>>>> ugen1.1: at usbus1 >>>>>> uhub1: on usbus1 >>>>>> ugen2.1: at usbus2 >>>>>> uhub2: on usbus2 >>>>>> ugen3.1: at usbus3 >>>>>> uhub3: on usbus3 >>>>>> ugen4.1: at usbus4 >>>>>> uhub4: on usbus4 >>>>>> ugen5.1: at usbus5 >>>>>> uhub5: on usbus5 >>>>>> ad16: 476940MB at ata8-master UDMA100 SATA >>>>>> 3Gb/s >>>>>> uhub0: 2 ports with 2 removable, self powered >>>>>> uhub1: 2 ports with 2 removable, self powered >>>>>> uhub2: 2 ports with 2 removable, self powered >>>>>> uhub3: 2 ports with 2 removable, self powered >>>>>> uhub4: 2 ports with 2 removable, self powered >>>>>> da8 at mpt0 bus 0 scbus0 target 0 lun 0 >>>>>> da8: Fixed Direct Access SCSI-5 device >>>>>> da8: 300.000MB/s transfers >>>>>> da8: Command Queueing enabled >>>>>> da8: 953869MB (1953525168 512 byte sectors: 255H 63S/T 121601C) >>>>>> da9 at mpt0 bus 0 scbus0 target 1 lun 0 >>>>>> da9: Fixed Direct Access SCSI-5 device >>>>>> da9: 300.000MB/s transfers >>>>>> da9: Command Queueing enabled >>>>>> da9: 953869MB (1953525168 512 byte sectors: 255H 63S/T 121601C) >>>>>> da10 at mpt0 bus 0 scbus0 target 2 lun 0 >>>>>> da10: Fixed Direct Access SCSI-5 device >>>>>> da10: 300.000MB/s transfers >>>>>> da10: Command Queueing enabled >>>>>> da10: 953869MB (1953525168 512 byte sectors: 255H 63S/T 121601C) >>>>>> da11 at mpt0 bus 0 scbus0 target 3 lun 0 >>>>>> da11: Fixed Direct Access SCSI-5 device >>>>>> da11: 300.000MB/s transfers >>>>>> da11: Command Queueing enabled >>>>>> da11: 953869MB (1953525168 512 byte sectors: 255H 63S/T 121601C) >>>>>> da12 at mpt0 bus 0 scbus0 target 4 lun 0 >>>>>> da12: Fixed Direct Access SCSI-5 device >>>>>> da12: 300.000MB/s transfers >>>>>> da12: Command Queueing enabled >>>>>> da12: 953869MB (1953525168 512 byte sectors: 255H 63S/T 121601C) >>>>>> da13 at mpt0 bus 0 scbus0 target 5 lun 0 >>>>>> da13: Fixed Direct Access SCSI-5 device >>>>>> da13: 300.000MB/s transfers >>>>>> da13: Command Queueing enabled >>>>>> da13: 953869MB (1953525168 512 byte sectors: 255H 63S/T 121601C) >>>>>> da14 at mpt0 bus 0 scbus0 target 6 lun 0 >>>>>> da14: Fixed Direct Access SCSI-5 device >>>>>> da14: 300.000MB/s transfers >>>>>> da14: Command Queueing enabled >>>>>> da14: 953869MB (1953525168 512 byte sectors: 255H 63S/T 121601C) >>>>>> da0 at mpt1 bus 0 scbus1 target 0 lun 0 >>>>>> da0: Fixed Direct Access SCSI-5 device >>>>>> da0: 300.000MB/s transfers >>>>>> da0: Command Queueing enabled >>>>>> da0: 1907729MB (3907029168 512 byte sectors: 255H 63S/T 243201C) >>>>>> da1 at mpt1 bus 0 scbus1 target 1 lun 0 >>>>>> da1: Fixed Direct Access SCSI-5 device >>>>>> da1: 300.000MB/s transfers >>>>>> da1: Command Queueing enabled >>>>>> da1: 1907729MB (3907029168 512 byte sectors: 255H 63S/T 243201C) >>>>>> da2 at mpt1 bus 0 scbus1 target 2 lun 0 >>>>>> da2: Fixed Direct Access SCSI-5 device >>>>>> da2: 300.000MB/s transfers >>>>>> da2: Command Queueing enabled >>>>>> da2: 1907729MB (3907029168 512 byte sectors: 255H 63S/T 243201C) >>>>>> da3 at mpt1 bus 0 scbus1 target 3 lun 0 >>>>>> da3: Fixed Direct Access SCSI-5 device >>>>>> da3: 300.000MB/s transfers >>>>>> da3: Command Queueing enabled >>>>>> da3: 1907729MB (3907029168 512 byte sectors: 255H 63S/T 243201C) >>>>>> da4 at mpt1 bus 0 scbus1 target 4 lun 0 >>>>>> da4: Fixed Direct Access SCSI-5 device >>>>>> da4: 300.000MB/s transfers >>>>>> da4: Command Queueing enabled >>>>>> da4: 1907729MB (3907029168 512 byte sectors: 255H 63S/T 243201C) >>>>>> da5 at mpt1 bus 0 scbus1 target 5 lun 0 >>>>>> da5: Fixed Direct Access SCSI-5 device >>>>>> da5: 300.000MB/s transfers >>>>>> da5: Command Queueing enabled >>>>>> da5: 953869MB (1953525168 512 byte sectors: 255H 63S/T 121601C) >>>>>> da6 at mpt1 bus 0 scbus1 target 6 lun 0 >>>>>> da6: Fixed Direct Access SCSI-5 device >>>>>> da6: 300.000MB/s transfers >>>>>> da6: Command Queueing enabled >>>>>> da6: 953869MB (1953525168 512 byte sectors: 255H 63S/T 121601C) >>>>>> da7 at mpt1 bus 0 scbus1 target 7 lun 0 >>>>>> da7: Fixed Direct Access SCSI-5 device >>>>>> da7: 300.000MB/s transfers >>>>>> da7: Command Queueing enabled >>>>>> da7: 953869MB (1953525168 512 byte sectors: 255H 63S/T 121601C) >>>>>> SMP: AP CPU #1 Launched! >>>>>> uhub5: 10 ports with 10 removable, self powered >>>>>> GEOM: da7: geometry does not match label (16h,63s != 255h,63s). >>>>>> Trying to mount root from ufs:/dev/ad16s1a >>>>>> WARNING: / was not properly dismounted >>>>>> ZFS filesystem version 5 >>>>>> ZFS storage pool version 28 >>>>>> WARNING: /tmp was not properly dismounted >>>>>> WARNING: /usr was not properly dismounted >>>>>> WARNING: /var was not properly dismounted >>>>>> 0 >>>>>> mpt1: request 0xffffff80002c57f0:2369 timed out for ccb >>>>>> 0xffffff00063bb000 >>>>>> (req->ccb 0xffffff00063bb000) >>>>>> mpt1: attempting to abort req 0xffffff80002c57f0:2369 function 0 >>>>>> mpt1: mpt_wait_req(1) timed out >>>>>> mpt1: mpt_recover_commands: abort timed-out. Resetting controller >>>>>> mpt1: mpt_cam_event: 0x80 >>>>>> mpt1: mpt_cam_event: 0x80 >>>>>> mpt1: completing timedout/aborted req 0xffffff80002c57f0:2369 >>>>>> mpt1: mpt_cam_event: 0x16 >>>>>> mpt1: mpt_cam_event: 0x12 >>>>>> mpt1: mpt_cam_event: 0x12 >>>>>> mpt1: mpt_cam_event: 0x12 >>>>>> mpt1: mpt_cam_event: 0x12 >>>>>> mpt1: mpt_cam_event: 0x12 >>>>>> mpt1: mpt_cam_event: 0x12 >>>>>> mpt1: mpt_cam_event: 0x12 >>>>>> mpt1: mpt_cam_event: 0x12 >>>>>> mpt1: mpt_cam_event: 0x16 >>>>>> mpt1: request 0xffffff80002c5c70:2375 timed out for ccb >>>>>> 0xffffff00063bb000 >>>>>> (req->ccb 0xffffff00063bb000) >>>>>> mpt1: attempting to abort req 0xffffff80002c5c70:2375 function 0 >>>>>> mpt1: completing timedout/aborted req 0xffffff80002c5c70:2375 >>>>>> mpt1: >>>>>> abort of req 0xffffff80002c5c70:0 completed >>>>>> mpt1: mpt_cam_event: 0x16 >>>>>> mpt1: mpt_cam_event: 0x16 >>>>>> mpt1: request 0xffffff80002c5fd0:2379 timed out for ccb >>>>>> 0xffffff00063bb000 >>>>>> (req->ccb 0xffffff00063bb000) >>>>>> mpt1: attempting to abort req 0xffffff80002c5fd0:2379 function 0 >>>>>> mpt1: completing timedout/aborted req 0xffffff80002c5fd0:2379 >>>>>> mpt1: >>>>>> abort of req 0xffffff80002c5fd0:0 completed >>>>>> mpt1: mpt_cam_event: 0x16 >>>>>> mpt1: mpt_cam_event: 0x16 >>>>>> mpt1: request 0xffffff80002c6210:2383 timed out for ccb >>>>>> 0xffffff00063bb000 >>>>>> (req->ccb 0xffffff00063bb000) >>>>>> mpt1: attempting to abort req 0xffffff80002c6210:2383 function 0 >>>>>> mpt1: completing timedout/aborted req 0xffffff80002c6210:2383 >>>>>> mpt1: >>>>>> abort of req 0xffffff80002c6210:0 completed >>>>>> mpt1: mpt_cam_event: 0x16 >>>>>> mpt1: mpt_cam_event: 0x16 >>>>>> mpt1: request 0xffffff80002c6180:2387 timed out for ccb >>>>>> 0xffffff00063bb000 >>>>>> (req->ccb 0xffffff00063bb000) >>>>>> mpt1: attempting to abort req 0xffffff80002c6180:2387 function 0 >>>>>> mpt1: completing timedout/aborted req 0xffffff80002c6180:2387 >>>>>> mpt1: >>>>>> abort of req 0xffffff80002c6180:0 completed >>>>>> mpt1: mpt_cam_event: 0x16 >>>>>> mpt1: mpt_cam_event: 0x16 >>>>>> mpt1: request 0xffffff80002c62a0:2391 timed out for ccb >>>>>> 0xffffff00063bb000 >>>>>> (req->ccb 0xffffff00063bb000) >>>>>> mpt1: attempting to abort req 0xffffff80002c62a0:2391 function 0 >>>>>> mpt1: completing timedout/aborted req 0xffffff80002c62a0:2391 >>>>>> mpt1: >>>>>> abort of req 0xffffff80002c62a0:0 completed >>>>>> mpt1: mpt_cam_event: 0x16 >>>>>> mpt1: mpt_cam_event: 0x16 >>>>>> mpt1: request 0xffffff80002c6720:2395 timed out for ccb >>>>>> 0xffffff00063bb000 >>>>>> (req->ccb 0xffffff00063bb000) >>>>>> mpt1: attempting to abort req 0xffffff80002c6720:2395 function 0 >>>>>> mpt1: completing timedout/aborted req 0xffffff80002c6720:2395 >>>>>> mpt1: >>>>>> abort of req 0xffffff80002c6720:0 completed >>>>>> mpt1: mpt_cam_event: 0x16 >>>>>> mpt1: mpt_cam_event: 0x16 >>>>>> mpt1: request 0xffffff80002c67b0:2399 timed out for ccb >>>>>> 0xffffff00063bb000 >>>>>> (req->ccb 0xffffff00063bb000) >>>>>> mpt1: attempting to abort req 0xffffff80002c67b0:2399 function 0 >>>>>> mpt1: completing timedout/aborted req 0xffffff80002c67b0:2399 >>>>>> mpt1: >>>>>> abort of req 0xffffff80002c67b0:0 completed >>>>>> mpt1: mpt_cam_event: 0x16 >>>>>> mpt1: mpt_cam_event: 0x16 >>>>>> mpt0: request 0xffffff80002a69e0:2082 timed out for ccb >>>>>> 0xffffff0006389800 >>>>>> (req->ccb 0xffffff0006389800) >>>>>> mpt0: attempting to abort req 0xffffff80002a69e0:2082 function 0 >>>>>> mpt0: completing timedout/aborted req 0xffffff80002a69e0:2082 >>>>>> mpt0: abort of req 0xffffff80002a69e0:0 completed >>>>>> mpt0: mpt_cam_event: 0x16 >>>>>> mpt0: mpt_cam_event: 0x16 >>>>>> mpt0: request 0xffffff80002a6c20:2086 timed out for ccb >>>>>> 0xffffff0006389800 >>>>>> (req->ccb 0xffffff0006389800) >>>>>> mpt0: attempting to abort req 0xffffff80002a6c20:2086 function 0 >>>>>> mpt0: completing timedout/aborted req 0xffffff80002a6c20:2086 >>>>>> mpt0: abort of req 0xffffff80002a6c20:0 completed >>>>>> mpt0: mpt_cam_event: 0x16 >>>>>> mpt0: mpt_cam_event: 0x16 >>>>>> mpt0: request 0xffffff80002a6cb0:2090 timed out for ccb >>>>>> 0xffffff0006389800 >>>>>> (req->ccb 0xffffff0006389800) >>>>>> mpt0: attempting to abort req 0xffffff80002a6cb0:2090 function 0 >>>>>> mpt0: completing timedout/aborted req 0xffffff80002a6cb0:2090 >>>>>> mpt0: abort of req 0xffffff80002a6cb0:0 completed >>>>>> mpt0: mpt_cam_event: 0x16 >>>>>> mpt0: mpt_cam_event: 0x16 >>>>>> mpt0: request 0xffffff80002a6b90:2094 timed out for ccb >>>>>> 0xffffff0006389800 >>>>>> (req->ccb 0xffffff0006389800) >>>>>> mpt0: attempting to abort req 0xffffff80002a6b90:2094 function 0 >>>>>> mpt0: completing timedout/aborted req 0xffffff80002a6b90:2094 >>>>>> mpt0: abort of req 0xffffff80002a6b90:0 completed >>>>>> mpt0: mpt_cam_event: 0x16 >>>>>> mpt0: mpt_cam_event: 0x16 >>>>>> tun0: link state changed to UP >>>>>> (da8:mpt0:0:0:0): READ(10). CDB: 28 0 3e e2 6f 56 0 0 1 0 >>>>>> (da8:mpt0:0:0:0): CAM status: SCSI Status Error >>>>>> (da8:mpt0:0:0:0): SCSI status: Check Condition >>>>>> (da8:mpt0:0:0:0): SCSI sense: UNIT ATTENTION asc:29,0 (Power on, >>>>>> reset, or >>>>>> bus device reset occurred) >>>>>> (da11:mpt0:0:3:0): READ(10). CDB: 28 0 1a b6 92 0 0 0 80 0 >>>>>> (da11:mpt0:0:3:0): CAM status: SCSI Status Error >>>>>> (da11:mpt0:0:3:0): SCSI status: Check Condition >>>>>> (da11:mpt0:0:3:0): SCSI sense: UNIT ATTENTION asc:29,0 (Power on, >>>>>> reset, or >>>>>> bus device reset occurred) >>>>>> (da2:mpt1:0:2:0): READ(10). CDB: 28 0 76 7b de 0 0 0 80 0 >>>>>> (da2:mpt1:0:2:0): CAM status: SCSI Status Error >>>>>> (da2:mpt1:0:2:0): SCSI status: Check Condition >>>>>> (da2:mpt1:0:2:0): SCSI sense: UNIT ATTENTION asc:29,0 (Power on, >>>>>> reset, or >>>>>> bus device reset occurred) >>>>>> (da10:mpt0:0:2:0): READ(10). CDB: 28 0 1a ff 67 80 0 0 80 0 >>>>>> (da10:mpt0:0:2:0): CAM status: SCSI Status Error >>>>>> (da10:mpt0:0:2:0): SCSI status: Check Condition >>>>>> (da10:mpt0:0:2:0): SCSI sense: UNIT ATTENTION asc:29,0 (Power on, >>>>>> reset, or >>>>>> bus device reset occurred) >>>>>> (da5:mpt1:0:5:0): READ(10). CDB: 28 0 1a ff 67 80 0 0 80 0 >>>>>> (da5:mpt1:0:5:0): CAM status: SCSI Status Error >>>>>> (da5:mpt1:0:5:0): SCSI status: Check Condition >>>>>> (da5:mpt1:0:5:0): SCSI sense: UNIT ATTENTION asc:29,0 (Power on, >>>>>> reset, or >>>>>> bus device reset occurred) >>>>>> (da7:mpt1:0:7:0): READ(10). CDB: 28 0 40 d7 da 80 0 0 80 0 >>>>>> (da7:mpt1:0:7:0): CAM status: SCSI Status Error >>>>>> (da7:mpt1:0:7:0): SCSI status: Check Condition >>>>>> (da7:mpt1:0:7:0): SCSI sense: UNIT ATTENTION asc:29,0 (Power on, >>>>>> reset, or >>>>>> bus device reset occurred) >>>>>> (da6:mpt1:0:6:0): READ(10). CDB: 28 0 40 d7 da 80 0 0 80 0 >>>>>> (da6:mpt1:0:6:0): CAM status: SCSI Status Error >>>>>> (da6:mpt1:0:6:0): SCSI status: Check Condition >>>>>> (da6:mpt1:0:6:0): SCSI sense: UNIT ATTENTION asc:29,0 (Power on, >>>>>> reset, or >>>>>> bus device reset occurred) >>>>>> (da0:mpt1:0:0:0): READ(10). CDB: 28 0 76 91 87 e3 0 0 1 0 >>>>>> (da0:mpt1:0:0:0): CAM status: SCSI Status Error >>>>>> (da0:mpt1:0:0:0): SCSI status: Check Condition >>>>>> (da0:mpt1:0:0:0): SCSI sense: UNIT ATTENTION asc:29,0 (Power on, >>>>>> reset, or >>>>>> bus device reset occurred) >>>>>> (da3:mpt1:0:3:0): READ(10). CDB: 28 0 76 69 1 1c 0 0 1 0 >>>>>> (da3:mpt1:0:3:0): CAM status: SCSI Status Error >>>>>> (da3:mpt1:0:3:0): SCSI status: Check Condition >>>>>> (da3:mpt1:0:3:0): SCSI sense: UNIT ATTENTION asc:29,0 (Power on, >>>>>> reset, or >>>>>> bus device reset occurred) >>>>>> (da1:mpt1:0:1:0): READ(10). CDB: 28 0 76 69 1 1c 0 0 1 0 >>>>>> (da1:mpt1:0:1:0): CAM status: SCSI Status Error >>>>>> (da1:mpt1:0:1:0): SCSI status: Check Condition >>>>>> (da1:mpt1:0:1:0): SCSI sense: UNIT ATTENTION asc:29,0 (Power on, >>>>>> reset, or >>>>>> bus device reset occurred) >>>>>> (da9:mpt0:0:1:0): READ(10). CDB: 28 0 1a b3 d7 0 0 0 80 0 >>>>>> (da9:mpt0:0:1:0): CAM status: SCSI Status Error >>>>>> (da9:mpt0:0:1:0): SCSI status: Check Condition >>>>>> (da9:mpt0:0:1:0): SCSI sense: UNIT ATTENTION asc:29,0 (Power on, >>>>>> reset, or >>>>>> bus device reset occurred) >>>>>> (da4:mpt1:0:4:0): READ(10). CDB: 28 0 53 3c c6 0 0 0 80 0 >>>>>> (da4:mpt1:0:4:0): CAM status: SCSI Status Error >>>>>> (da4:mpt1:0:4:0): SCSI status: Check Condition >>>>>> (da4:mpt1:0:4:0): SCSI sense: UNIT ATTENTION asc:29,0 (Power on, >>>>>> reset, or >>>>>> bus device reset occurred) >>>>>> >>>>>> >>>>>> >>>>>> > >>>>>> > -- >>>>>> > | Jeremy Chadwick >>>>>> jdc@parodius.com | >>>>>> > | Parodius Networking >>>>>> http://www.parodius.com/ | >>>>>> > | UNIX Systems Administrator Mountain View, CA, US >>>>>> | >>>>>> > | Making life hard for others since 1977. PGP 4BD6C0CB >>>>>> | >>>>>> > >>>>>> > >>>>>> >>>>>> >>>>>> -- >>>>>> Joshua Boyd >>>>>> _______________________________________________ >>>>>> freebsd-stable@freebsd.org mailing list >>>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >>>>>> To unsubscribe, send any mail to " >>>>>> freebsd-stable-unsubscribe@freebsd.org" >>>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> Joshua Boyd >>>> >>> >>> >>> >>> -- >>> Joshua Boyd >>> >>> >>> E-mail: boydjd@jbip.net >>> http://www.jbip.net >>> >> >> > > > -- > Joshua Boyd > > E-mail: boydjd@jbip.net > http://www.jbip.net > From owner-freebsd-stable@FreeBSD.ORG Wed Jun 22 16:47:40 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0F55D1065678 for ; Wed, 22 Jun 2011 16:47:40 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) by mx1.freebsd.org (Postfix) with ESMTP id 8740C8FC1A for ; Wed, 22 Jun 2011 16:47:39 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id p5MGYbOF047141; Thu, 23 Jun 2011 02:34:38 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Thu, 23 Jun 2011 02:34:36 +1000 (EST) From: Ian Smith To: Alexander Motin In-Reply-To: <4E01AFBA.809@FreeBSD.org> Message-ID: <20110623020753.V34951@sola.nimnet.asn.au> References: <20110618005124.GA43568@icarus.home.lan> <20110621191626.GA99204@icarus.home.lan> <4E01AFBA.809@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-stable@freebsd.org, Jeremy Chadwick Subject: Re: MFC: graid(8) (RAID GEOM) support X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 16:47:40 -0000 On Wed, 22 Jun 2011, Alexander Motin wrote: > Jeremy Chadwick wrote: [..] > >> Look graid(8) manual page for additional details. > >> > >> Co-authored by: imp > >> Sponsored by: Cisco Systems, Inc. and iXsystems, Inc. > >> ===================================================================== > > > > By the way, it doesn't look like the graid(8) man page is being brought > > in to the base system on either of the two RELENG_8 systems I've rebuilt > > in the past few days. > > > > I'm thinking /usr/src/sbin/geom/class/raid/graid.8 isn't being noticed > > as a man page. > > > > /usr/src/sbin/geom/class/raid/Makefile doesn't have MAN8=graid.8 in it, > > is that the problem? > > I've just rebuilt my test 8-STABLE system and it installed graid(8). I don't know if it's possibly related, or just that ongoing? issue with some? new manpages not making it into man.cgi but .. http://www.freebsd.org/cgi/man.cgi?query=graid&apropos=0&sektion=0&manpath=FreeBSD+8.2-stable&format=html isn't working either, nor even for 9-current: Sorry, no data found for `graid'. Please try a keyword search. cheers, Ian From owner-freebsd-stable@FreeBSD.ORG Wed Jun 22 16:48:47 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 516841065686; Wed, 22 Jun 2011 16:48:47 +0000 (UTC) (envelope-from hlh@restart.be) Received: from tignes.restart.be (tignes.restart.be [IPv6:2001:41d0:2:56bf:0:1::]) by mx1.freebsd.org (Postfix) with ESMTP id C83EA8FC20; Wed, 22 Jun 2011 16:48:46 +0000 (UTC) Received: from restart.be (avoriaz.tunnel.bel [IPv6:2001:41d0:2:56bf:1:ffff::]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "smtp.restart.be", Issuer "CA master" (verified OK)) by tignes.restart.be (Postfix) with ESMTPS id 1052214DA7; Wed, 22 Jun 2011 18:48:46 +0200 (CEST) Received: from morzine.restart.bel (morzine.restart.be [IPv6:2001:41d0:2:56bf:1:2::]) (authenticated bits=0) by restart.be (8.14.5/8.14.5) with ESMTP id p5MGmhvR058609; Wed, 22 Jun 2011 18:48:43 +0200 (CEST) (envelope-from hlh@restart.be) X-DKIM: Sendmail DKIM Filter v2.8.3 restart.be p5MGmhvR058609 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=restart.be; s=avoriaz; t=1308761324; bh=1+PPjxVs/XK+JB1IXpwQMXbHZycGbamBpnbuGxheqh0=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=Q209EW1573ihMNFkDmetpwz8QaMQr9bwNf6rfRvC258zrtb3KAin8tWYMNh6bK4NE ztSiqsDh0uRUq+hn9JqNQ== X-DomainKeys: Sendmail DomainKeys Filter v1.0.2 restart.be p5MGmhvR058609 DomainKey-Signature: a=rsa-sha1; s=avoriaz; d=restart.be; c=nofws; q=dns; h=message-id:date:from:organization:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type:content-transfer-encoding; b=HvG/kVPI3vlvi/yu1j1p+hqSfKiJWoiWXWNNE7Gsd3i+bY8fiIfFtLecg0Ex+aXTt Tz0W8tHoIhi1Tkhqz9BZQ== Message-ID: <4E021CEB.4080703@restart.be> Date: Wed, 22 Jun 2011 18:48:43 +0200 From: Henri Hennebert Organization: RestartSoft User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.17) Gecko/20110616 Thunderbird/3.1.10 MIME-Version: 1.0 To: John Baldwin References: <4E01FA03.9070805@restart.be> <4E01FADA.2070104@restart.be> <201106221158.16485.jhb@freebsd.org> In-Reply-To: <201106221158.16485.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: ZFS boot inside on the second partition inside a slice X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 16:48:47 -0000 On 06/22/2011 17:58, John Baldwin wrote: > Index: zfsldr.S > =================================================================== > --- zfsldr.S (revision 223365) > +++ zfsldr.S (working copy) > @@ -16,7 +16,6 @@ > */ > > /* Memory Locations */ > - .set MEM_REL,0x700 # Relocation address > .set MEM_ARG,0x900 # Arguments > .set MEM_ORG,0x7c00 # Origin > .set MEM_BUF,0x8000 # Load area > @@ -91,26 +90,18 @@ main: cld # String ops inc > mov %cx,%ss # Set up > mov $start,%sp # stack > /* > - * Relocate ourself to MEM_REL. Since %cx == 0, the inc %ch sets > - * %cx == 0x100. > - */ > - mov %sp,%si # Source > - mov $MEM_REL,%di # Destination > - incb %ch # Word count > - rep # Copy > - movsw # code > -/* > * If we are on a hard drive, then load the MBR and look for the first > * FreeBSD slice. We use the fake partition entry below that points to > * the MBR when we call nread. The first pass looks for the first active > * FreeBSD slice. The second pass looks for the first non-active FreeBSD > * slice if the first one fails. > */ > - mov $part4,%si # Partition > + mov $part4,%si # Dummy partition > cmpb $0x80,%dl # Hard drive? > jb main.4 # No > - movb $0x1,%dh # Block count > - callw nread # Read MBR > + xor %eax,%eax # Read MBR > + movw $MEM_BUF,%bx # from first > + callw nread # sector > mov $0x1,%cx # Two passes > main.1: mov $MEM_BUF+PRT_OFF,%si # Partition table > movb $0x1,%dh # Partition > @@ -143,32 +134,35 @@ main.4: xor %dx,%dx # Partition:drive > * (i.e. after the two vdev labels). We don't have do anything fancy > * here to allow for an extra copy of boot1 and a partition table > * (compare to this section of the UFS bootstrap) so we just load it > - * all at 0x8000. The first part of boot2 is BTX, which wants to run > + * all at 0x9000. The first part of boot2 is BTX, which wants to run > * at 0x9000. The boot2.bin binary starts right after the end of BTX, > * so we have to figure out where the start of it is and then move the > - * binary to 0xc000. After we have moved the client, we relocate BTX > - * itself to 0x9000 - doing it in this order means that none of the > - * memcpy regions overlap which would corrupt the copy. Normally, BTX > - * clients start at MEM_USR, or 0xa000, but when we use btxld to > - * create zfsboot2, we use an entry point of 0x2000. That entry point is > - * relative to MEM_USR; thus boot2.bin starts at 0xc000. > + * binary to 0xc000. Normally, BTX clients start at MEM_USR, or 0xa000, > + * but when we use btxld to create zfsboot2, we use an entry point of > + * 0x2000. That entry point is relative to MEM_USR; thus boot2.bin > + * starts at 0xc000. > * > * The load area and the target area for the client overlap so we have > * to use a decrementing string move. We also play segment register > * games with the destination address for the move so that the client > * can be larger than 16k (which would overflow the zero segment since > - * the client starts at 0xc000). Relocating BTX is easy since the load > - * area and target area do not overlap. > + * the client starts at 0xc000). > */ > main.5: mov %dx,MEM_ARG # Save args > - movb $NSECT,%dh # Sector count > + mov $NSECT,%cx # Sector count > movl $1024,%eax # Offset to boot2 > - callw nread.1 # Read disk > -main.6: mov $MEM_BUF,%si # BTX (before reloc) > + mov $MEM_BTX,%bx # Destination buffer > +main.6: pushal # Save params > + callw nread # Read disk > + popal # Restore > + incl %eax # Update for > + add $SIZ_SEC,%bx # next sector > + loop main.6 # If not last, read another > + mov $MEM_BTX,%si # BTX > mov 0xa(%si),%bx # Get BTX length and set > mov $NSECT*SIZ_SEC-1,%di # Size of load area (less one) > mov %di,%si # End of load > - add $MEM_BUF,%si # area > + add $MEM_BTX,%si # area > sub %bx,%di # End of client, 0xc000 rel > mov %di,%cx # Size of > inc %cx # client > @@ -179,12 +173,6 @@ main.5: mov %dx,MEM_ARG # Save args > movsb # client > mov %ds,%dx # Back to > mov %dx,%es # zero segment > - mov $MEM_BUF,%si # BTX (before reloc) > - mov $MEM_BTX,%di # BTX > - mov %bx,%cx # Get BTX length > - cld # Increment this time > - rep # Relocate > - movsb # BTX > > /* > * Enable A20 so we can access memory above 1 meg. > @@ -214,29 +202,35 @@ seta20.3: sti # Enable interrupts > * packet on the stack and passes it to read. > * > * %eax - int - LBA to read in relative to partition start > + * %es:%bx - ptr - destination address > * %dl - byte - drive to read from > - * %dh - byte - num sectors to read > * %si - ptr - MBR partition entry > */ > -nread: xor %eax,%eax # Sector offset in partition > -nread.1: xor %ecx,%ecx # Get > +nread: xor %ecx,%ecx # Get > addl 0x8(%si),%eax # LBA > adc $0,%ecx > pushl %ecx # Starting absolute block > pushl %eax # block number > push %es # Address of > - push $MEM_BUF # transfer buffer > - xor %ax,%ax # Number of > - movb %dh,%al # blocks to > - push %ax # transfer > + push %bx # transfer buffer > + push $0x1 # Read 1 sector > push $0x10 # Size of packet > mov %sp,%bp # Packet pointer > callw read # Read from disk > + jc nread.1 # If error, fail > lea 0x10(%bp),%sp # Clear stack > - jnc return # If success, return > - mov $msg_read,%si # Otherwise, set the error > - # message and fall through to > - # the error routine > + ret # If success, return > +nread.1: mov %ah,%al # Format > + mov $read_err,%di # error > + call hex8 # code > + movl 0x8(%bp),%eax # Format > + mov $lba,%di # LBA > + call hex32 > + mov $msg_lba,%si # Display > + call putstr # LBA > + mov $msg_read,%si # Set the error message and > + # fall through to the error > + # routine > /* > * Print out the error message pointed to by %ds:(%si) followed > * by a prompt, wait for a keypress, and then reboot the machine. > @@ -259,14 +253,6 @@ putstr: lodsb # Get char > jne putstr.0 # No > > /* > - * Overused return code. ereturn is used to return an error from the > - * read function. Since we assume putstr succeeds, we (ab)use the > - * same code when we return from putstr. > - */ > -ereturn: movb $0x1,%ah # Invalid > - stc # argument > -return: retw # To caller > -/* > * Reads sectors from the disk. If EDD is enabled, then check if it is > * installed and use it if it is. If it is not installed or not enabled, then > * fall back to using CHS. Since we use a LBA, if we are using CHS, we have to > @@ -294,14 +280,38 @@ read: cmpb $0x80,%dl # Hard drive? > retw # To caller > read.1: mov $msg_chs,%si > jmp error > -msg_chs: .asciz "CHS not supported" > > +/* > + * Convert EAX, AX, or AL to hex, saving the result to [EDI]. > + */ > +hex32: pushl %eax # Save > + shrl $0x10,%eax # Do upper > + call hex16 # 16 > + popl %eax # Restore > +hex16: call hex16.1 # Do upper 8 > +hex16.1: xchgb %ah,%al # Save/restore > +hex8: push %ax # Save > + shrb $0x4,%al # Do upper > + call hex8.1 # 4 > + pop %ax # Restore > +hex8.1: andb $0xf,%al # Get lower 4 > + cmpb $0xa,%al # Convert > + sbbb $0x69,%al # to hex > + das # digit > + orb $0x20,%al # To lower case > + stosb # Save char > + ret # (Recursive) > + > /* Messages */ > > -msg_read: .asciz "Read" > -msg_part: .asciz "Boot" > +msg_chs: .asciz "CHS not supported" > +msg_read: .ascii "Read error: " > +read_err: .asciz "XX" > +msg_lba: .ascii "LBA: " > +lba: .asciz "XXXXXXXX\r\n" > +msg_part: .asciz "Boot error" > > -prompt: .asciz " error\r\n" > +prompt: .asciz "\r\n" > > .org PRT_OFF,0x90 > No error message but a reboot... I add: loop main.6 # If not last, read another mov $msg_debug,%si call putstr mov $MEM_BTX,%si # BTX ...... msg_debug: .asciz "@\r\n" I don't get the @ on the console :-( PS - I have to keep a short message otherwise: /usr/src/sys/boot/i386/zfsboot/zfsldr.S:322: Error: attempt to move .org backwards Henri Henri From owner-freebsd-stable@FreeBSD.ORG Wed Jun 22 16:58:52 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5BF14106564A for ; Wed, 22 Jun 2011 16:58:52 +0000 (UTC) (envelope-from gkontos.mail@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 21E798FC08 for ; Wed, 22 Jun 2011 16:58:52 +0000 (UTC) Received: by iyb11 with SMTP id 11so1190002iyb.13 for ; Wed, 22 Jun 2011 09:58:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=1vQG/lgxt/MuuzG42OFwswvKsEck1/D34V2h9c6c38s=; b=D+NPzDDi4P75FneDjOqF1rl3crLnXtvn7sKLmFHqFdC1BH6G4rZVhtugXVla1tyxmq ENyMIaGvPyixtWGpTNaBM+EwV2UrPZORBy/Wk8oB5k5/KeOaw48lHiCVTC4DGBQjT41R PEfZC17cSG8QmMWlaXvQdJb2NKIDvjko5Gimc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=lIg7/6sa+0tNQYX3QiWWNhMve9LuKf7+N+Qr+3MjwN0x2wq9VnBZxUj8VXwIEEzqpX p2WEna10b/K3z5AKS0S01VuxJlBvcupTH4JAJfsNVP4RcoJd5XCqyJK0jIm6Va9LUJ9H ea0qqNpqgwqLapc+MvKYH6KxX7j38dPZnBESk= MIME-Version: 1.0 Received: by 10.231.114.78 with SMTP id d14mr195619ibq.137.1308761930973; Wed, 22 Jun 2011 09:58:50 -0700 (PDT) Received: by 10.231.15.5 with HTTP; Wed, 22 Jun 2011 09:58:50 -0700 (PDT) In-Reply-To: <20110622164129.GB31480@gmail.com> References: <20110622164129.GB31480@gmail.com> Date: Wed, 22 Jun 2011 19:58:50 +0300 Message-ID: From: George Kontostanos To: Chris Brennan Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: FreeBSD Stable Subject: Re: ata: SIGNATURE: ffffffff X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 16:58:52 -0000 I have also changed the SATA port in the controller! I am afraid that I might get a new controller and still have the same issues. I just want to eliminate any other options first. On Wed, Jun 22, 2011 at 7:41 PM, Chris Brennan wrote: > * George Kontostanos [2011-06-22 18:48:45 +0300]: > > > Forgot to mention, I have changed the SATA cables too. > > Just a stab in the dark here ... but since you mention the same disk > almost being removed from the raidz1, maybe the port on the card is bad? > if you've replaced the disk and the cable(s), then what is left? The > card. > > -- > > Chris Brennan > > -- > > A: Yes. > > >Q: Are you sure? > > >>A: Because it reverses the logical flow of conversation. > > >>>Q: Why is top posting frowned upon? > > http://xkcd.com/84/ | http://xkcd.com/149/ | http://xkcd.com/549/ > > GPG: D5B20C0C (6741 8EE4 6C7D 11FB 8DA8 9E4A EECD 9A84 D5B2 0C0C) > ------------------------------------------------------------------------ > -- George Kontostanos aisecure.net From owner-freebsd-stable@FreeBSD.ORG Wed Jun 22 17:09:41 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 24CF1106566B for ; Wed, 22 Jun 2011 17:09:41 +0000 (UTC) (envelope-from xaero@xaerolimit.net) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id D888A8FC18 for ; Wed, 22 Jun 2011 17:09:40 +0000 (UTC) Received: by vws18 with SMTP id 18so1055127vws.13 for ; Wed, 22 Jun 2011 10:09:39 -0700 (PDT) Received: by 10.220.169.14 with SMTP id w14mr302486vcy.206.1308760894456; Wed, 22 Jun 2011 09:41:34 -0700 (PDT) Received: from gmail.com (ool-435056c7.dyn.optonline.net [67.80.86.199]) by mx.google.com with ESMTPS id n26sm93931vcy.17.2011.06.22.09.41.32 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 22 Jun 2011 09:41:32 -0700 (PDT) Date: Wed, 22 Jun 2011 12:41:30 -0400 From: Chris Brennan To: George Kontostanos Message-ID: <20110622164129.GB31480@gmail.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: FreeBSD Stable Subject: Re: ata: SIGNATURE: ffffffff X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 17:09:41 -0000 * George Kontostanos [2011-06-22 18:48:45 +0300]: > Forgot to mention, I have changed the SATA cables too. Just a stab in the dark here ... but since you mention the same disk almost being removed from the raidz1, maybe the port on the card is bad? if you've replaced the disk and the cable(s), then what is left? The card. -- > Chris Brennan > -- > A: Yes. > >Q: Are you sure? > >>A: Because it reverses the logical flow of conversation. > >>>Q: Why is top posting frowned upon? > http://xkcd.com/84/ | http://xkcd.com/149/ | http://xkcd.com/549/ > GPG: D5B20C0C (6741 8EE4 6C7D 11FB 8DA8 9E4A EECD 9A84 D5B2 0C0C) ------------------------------------------------------------------------ From owner-freebsd-stable@FreeBSD.ORG Wed Jun 22 17:13:31 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ABE8C106566B for ; Wed, 22 Jun 2011 17:13:31 +0000 (UTC) (envelope-from xaero@xaerolimit.net) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 675CC8FC0A for ; Wed, 22 Jun 2011 17:13:31 +0000 (UTC) Received: by vws18 with SMTP id 18so1059097vws.13 for ; Wed, 22 Jun 2011 10:13:30 -0700 (PDT) Received: by 10.52.30.135 with SMTP id s7mr1282778vdh.270.1308762809433; Wed, 22 Jun 2011 10:13:29 -0700 (PDT) Received: from gmail.com (ool-435056c7.dyn.optonline.net [67.80.86.199]) by mx.google.com with ESMTPS id c9sm219704vdv.28.2011.06.22.10.13.27 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 22 Jun 2011 10:13:28 -0700 (PDT) Date: Wed, 22 Jun 2011 13:13:25 -0400 From: Chris Brennan To: George Kontostanos Message-ID: <20110622171324.GC31480@gmail.com> References: <20110622164129.GB31480@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: FreeBSD Stable Subject: Re: ata: SIGNATURE: ffffffff X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 17:13:31 -0000 * George Kontostanos [2011-06-22 19:58:50 +0300]: > I have also changed the SATA port in the controller! > > I am afraid that I might get a new controller and still have the same > issues. I just want to eliminate any other options first. > Don't top post, it's against list policy. See my siganture for a reasonable reason why. Replace the port or just moved the drive to an unused port? Or did you physically remove the card and solder a new SATA Female port to your card (which I would imagine would violate/void your warranty on the card. Essentially this is what you've done so far: 1. Changed drives 2. Changed SATA Cable 3. Moved to an unused port To be perfectly honest, it sounds like a faulty card, which was my original assessment. First I would see replacement on the same card under the warranty, if it still produces a problem, I would change cards. There is a slim chance it could also be a driver issue. -- > Chris Brennan > -- > A: Yes. > >Q: Are you sure? > >>A: Because it reverses the logical flow of conversation. > >>>Q: Why is top posting frowned upon? > http://xkcd.com/84/ | http://xkcd.com/149/ | http://xkcd.com/549/ > GPG: D5B20C0C (6741 8EE4 6C7D 11FB 8DA8 9E4A EECD 9A84 D5B2 0C0C) ----------------------------------------------------------------------- From owner-freebsd-stable@FreeBSD.ORG Wed Jun 22 17:33:03 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3A57E106564A for ; Wed, 22 Jun 2011 17:33:03 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id D94468FC16 for ; Wed, 22 Jun 2011 17:33:02 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 586A846B2E; Wed, 22 Jun 2011 13:33:02 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id EA9338A01F; Wed, 22 Jun 2011 13:33:01 -0400 (EDT) From: John Baldwin To: Henri Hennebert Date: Wed, 22 Jun 2011 13:33:01 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110617; KDE/4.5.5; amd64; ; ) References: <201106221158.16485.jhb@freebsd.org> <4E021CEB.4080703@restart.be> In-Reply-To: <4E021CEB.4080703@restart.be> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201106221333.01437.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Wed, 22 Jun 2011 13:33:02 -0400 (EDT) Cc: freebsd-stable@freebsd.org Subject: Re: ZFS boot inside on the second partition inside a slice X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 17:33:03 -0000 On Wednesday, June 22, 2011 12:48:43 pm Henri Hennebert wrote: > No error message but a reboot... > > I add: > > loop main.6 # If not last, read another > > mov $msg_debug,%si > call putstr > > mov $MEM_BTX,%si # BTX > > ...... > > msg_debug: .asciz "@\r\n" > > I don't get the @ on the console :-( Hmm, so it never exits the loop? > PS - I have to keep a short message otherwise: > > /usr/src/sys/boot/i386/zfsboot/zfsldr.S:322: Error: attempt to move .org > backwards Yeah, it's getting tight. I've commented the LBA printing bits out (so there is more room to play with) and made it print out a "." for each disk sector read: Index: zfsldr.S =================================================================== --- zfsldr.S (revision 223365) +++ zfsldr.S (working copy) @@ -16,7 +16,6 @@ */ /* Memory Locations */ - .set MEM_REL,0x700 # Relocation address .set MEM_ARG,0x900 # Arguments .set MEM_ORG,0x7c00 # Origin .set MEM_BUF,0x8000 # Load area @@ -91,26 +90,18 @@ main: cld # String ops inc mov %cx,%ss # Set up mov $start,%sp # stack /* - * Relocate ourself to MEM_REL. Since %cx == 0, the inc %ch sets - * %cx == 0x100. - */ - mov %sp,%si # Source - mov $MEM_REL,%di # Destination - incb %ch # Word count - rep # Copy - movsw # code -/* * If we are on a hard drive, then load the MBR and look for the first * FreeBSD slice. We use the fake partition entry below that points to * the MBR when we call nread. The first pass looks for the first active * FreeBSD slice. The second pass looks for the first non-active FreeBSD * slice if the first one fails. */ - mov $part4,%si # Partition + mov $part4,%si # Dummy partition cmpb $0x80,%dl # Hard drive? jb main.4 # No - movb $0x1,%dh # Block count - callw nread # Read MBR + xor %eax,%eax # Read MBR + movw $MEM_BUF,%bx # from first + callw nread # sector mov $0x1,%cx # Two passes main.1: mov $MEM_BUF+PRT_OFF,%si # Partition table movb $0x1,%dh # Partition @@ -143,32 +134,35 @@ main.4: xor %dx,%dx # Partition:drive * (i.e. after the two vdev labels). We don't have do anything fancy * here to allow for an extra copy of boot1 and a partition table * (compare to this section of the UFS bootstrap) so we just load it - * all at 0x8000. The first part of boot2 is BTX, which wants to run + * all at 0x9000. The first part of boot2 is BTX, which wants to run * at 0x9000. The boot2.bin binary starts right after the end of BTX, * so we have to figure out where the start of it is and then move the - * binary to 0xc000. After we have moved the client, we relocate BTX - * itself to 0x9000 - doing it in this order means that none of the - * memcpy regions overlap which would corrupt the copy. Normally, BTX - * clients start at MEM_USR, or 0xa000, but when we use btxld to - * create zfsboot2, we use an entry point of 0x2000. That entry point is - * relative to MEM_USR; thus boot2.bin starts at 0xc000. + * binary to 0xc000. Normally, BTX clients start at MEM_USR, or 0xa000, + * but when we use btxld to create zfsboot2, we use an entry point of + * 0x2000. That entry point is relative to MEM_USR; thus boot2.bin + * starts at 0xc000. * * The load area and the target area for the client overlap so we have * to use a decrementing string move. We also play segment register * games with the destination address for the move so that the client * can be larger than 16k (which would overflow the zero segment since - * the client starts at 0xc000). Relocating BTX is easy since the load - * area and target area do not overlap. + * the client starts at 0xc000). */ main.5: mov %dx,MEM_ARG # Save args - movb $NSECT,%dh # Sector count + mov $NSECT,%cx # Sector count movl $1024,%eax # Offset to boot2 - callw nread.1 # Read disk -main.6: mov $MEM_BUF,%si # BTX (before reloc) + mov $MEM_BTX,%bx # Destination buffer +main.6: pushal # Save params + callw nread # Read disk + popal # Restore + incl %eax # Update for + add $SIZ_SEC,%bx # next sector + loop main.6 # If not last, read another + mov $MEM_BTX,%si # BTX mov 0xa(%si),%bx # Get BTX length and set mov $NSECT*SIZ_SEC-1,%di # Size of load area (less one) mov %di,%si # End of load - add $MEM_BUF,%si # area + add $MEM_BTX,%si # area sub %bx,%di # End of client, 0xc000 rel mov %di,%cx # Size of inc %cx # client @@ -179,12 +173,6 @@ main.5: mov %dx,MEM_ARG # Save args movsb # client mov %ds,%dx # Back to mov %dx,%es # zero segment - mov $MEM_BUF,%si # BTX (before reloc) - mov $MEM_BTX,%di # BTX - mov %bx,%cx # Get BTX length - cld # Increment this time - rep # Relocate - movsb # BTX /* * Enable A20 so we can access memory above 1 meg. @@ -214,30 +202,40 @@ seta20.3: sti # Enable interrupts * packet on the stack and passes it to read. * * %eax - int - LBA to read in relative to partition start + * %es:%bx - ptr - destination address * %dl - byte - drive to read from - * %dh - byte - num sectors to read * %si - ptr - MBR partition entry */ -nread: xor %eax,%eax # Sector offset in partition -nread.1: xor %ecx,%ecx # Get +nread: xor %ecx,%ecx # Get addl 0x8(%si),%eax # LBA adc $0,%ecx pushl %ecx # Starting absolute block pushl %eax # block number push %es # Address of - push $MEM_BUF # transfer buffer - xor %ax,%ax # Number of - movb %dh,%al # blocks to - push %ax # transfer + push %bx # transfer buffer + push $0x1 # Read 1 sector push $0x10 # Size of packet mov %sp,%bp # Packet pointer callw read # Read from disk + jc nread.1 # If error, fail lea 0x10(%bp),%sp # Clear stack - jnc return # If success, return - mov $msg_read,%si # Otherwise, set the error - # message and fall through to - # the error routine + mov $msg_dot,%si + call putstr + ret # If success, return +nread.1: mov %ah,%al # Format + mov $read_err,%di # error + call hex8 # code /* + movl 0x8(%bp),%eax # Format + mov $lba,%di # LBA + call hex32 + mov $msg_lba,%si # Display + call putstr # LBA + */ + mov $msg_read,%si # Set the error message and + # fall through to the error + # routine +/* * Print out the error message pointed to by %ds:(%si) followed * by a prompt, wait for a keypress, and then reboot the machine. */ @@ -259,14 +257,6 @@ putstr: lodsb # Get char jne putstr.0 # No /* - * Overused return code. ereturn is used to return an error from the - * read function. Since we assume putstr succeeds, we (ab)use the - * same code when we return from putstr. - */ -ereturn: movb $0x1,%ah # Invalid - stc # argument -return: retw # To caller -/* * Reads sectors from the disk. If EDD is enabled, then check if it is * installed and use it if it is. If it is not installed or not enabled, then * fall back to using CHS. Since we use a LBA, if we are using CHS, we have to @@ -294,14 +284,43 @@ read: cmpb $0x80,%dl # Hard drive? retw # To caller read.1: mov $msg_chs,%si jmp error -msg_chs: .asciz "CHS not supported" +/* + * Convert EAX, AX, or AL to hex, saving the result to [EDI]. + */ +/* +hex32: pushl %eax # Save + shrl $0x10,%eax # Do upper + call hex16 # 16 + popl %eax # Restore +hex16: call hex16.1 # Do upper 8 +hex16.1: xchgb %ah,%al # Save/restore + */ +hex8: push %ax # Save + shrb $0x4,%al # Do upper + call hex8.1 # 4 + pop %ax # Restore +hex8.1: andb $0xf,%al # Get lower 4 + cmpb $0xa,%al # Convert + sbbb $0x69,%al # to hex + das # digit + orb $0x20,%al # To lower case + stosb # Save char + ret # (Recursive) + /* Messages */ -msg_read: .asciz "Read" -msg_part: .asciz "Boot" +msg_chs: .asciz "CHS not supported" +msg_read: .ascii "Read error: " +read_err: .asciz "XX" +/* +msg_lba: .ascii "LBA: " +lba: .asciz "XXXXXXXX\r\n" + */ +msg_dot: .asciz "." +msg_part: .asciz "Boot error" -prompt: .asciz " error\r\n" +prompt: .asciz "\r\n" .org PRT_OFF,0x90 -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Wed Jun 22 21:12:58 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AA38A106566C; Wed, 22 Jun 2011 21:12:58 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 7EC168FC12; Wed, 22 Jun 2011 21:12:58 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 2EA2246B2A; Wed, 22 Jun 2011 17:12:58 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id BD6BB8A01F; Wed, 22 Jun 2011 17:12:57 -0400 (EDT) From: John Baldwin To: freebsd-stable@freebsd.org Date: Wed, 22 Jun 2011 17:12:57 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110617; KDE/4.5.5; amd64; ; ) References: <20110622121136.GC16648@home.opsec.eu> In-Reply-To: <20110622121136.GC16648@home.opsec.eu> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201106221712.57278.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Wed, 22 Jun 2011 17:12:57 -0400 (EDT) Cc: Bjoern Zeeb , Kurt Jaeger Subject: Re: commit PR 154469, ftp-proxy(8) bug ? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 21:12:58 -0000 On Wednesday, June 22, 2011 8:11:36 am Kurt Jaeger wrote: > Hi! > > Can someone have a look at > > http://www.freebsd.org/cgi/query-pr.cgi?pr=154469 > > and commit it ? So that it ends up in 8.3 8-} ? Does the patch from OpenBSD fix the problem for you? -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Wed Jun 22 21:43:11 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2DD52106566C for ; Wed, 22 Jun 2011 21:43:11 +0000 (UTC) (envelope-from gkontos.mail@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id E7AB08FC13 for ; Wed, 22 Jun 2011 21:43:10 +0000 (UTC) Received: by iyb11 with SMTP id 11so1471842iyb.13 for ; Wed, 22 Jun 2011 14:43:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=IKH5Kiz0aVtHZeZvssbX1Yg/kmoyVNCPzzUVsPyy8Cs=; b=c+3foJepPX8svuX14Y8PTGxWVHTTrPaxWxpA0SYaNBrBJCUuT0mstKCD3yhAtczkK4 1mDJbjtQsIi+N4MGRBul2SWf25x5xitP9elGvQU5xF6tFXvLePMY9hZCQa17YNUqb3L5 zj/WmUhYATPh5AiDBplePz2Qcw03WqFDenx9o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=jY8sW7k3J0lO7C0GlQAX79tr3wxpjvcP5DsZe/Cx4rzUlSzkdKqKS6/ki9u5SyN+0Z Ufi5atPTek3HazuYkx/feXPU9lGBmUTb6HgConfbw98hifMxAIppLscQ6VLShnL5rWG8 1GeSlNlt6Cb9naON3yrn1ncG4LwXbijRLytVM= MIME-Version: 1.0 Received: by 10.231.53.139 with SMTP id m11mr976897ibg.112.1308778990072; Wed, 22 Jun 2011 14:43:10 -0700 (PDT) Received: by 10.231.15.5 with HTTP; Wed, 22 Jun 2011 14:43:09 -0700 (PDT) In-Reply-To: <20110622171324.GC31480@gmail.com> References: <20110622164129.GB31480@gmail.com> <20110622171324.GC31480@gmail.com> Date: Thu, 23 Jun 2011 00:43:09 +0300 Message-ID: From: George Kontostanos To: Chris Brennan Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: FreeBSD Stable Subject: Re: ata: SIGNATURE: ffffffff X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 21:43:11 -0000 You already mentioned your thought about a faulty card. If you don't have to add anything beyond that then please keep it for yourself. On Wed, Jun 22, 2011 at 8:13 PM, Chris Brennan wrote: > * George Kontostanos [2011-06-22 19:58:50 +0300]: > > > I have also changed the SATA port in the controller! > > > > I am afraid that I might get a new controller and still have the same > > issues. I just want to eliminate any other options first. > > > > Don't top post, it's against list policy. See my siganture for a > reasonable reason why. -- George Kontostanos aisecure.net From owner-freebsd-stable@FreeBSD.ORG Wed Jun 22 21:43:47 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 596DA1065743 for ; Wed, 22 Jun 2011 21:43:47 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (bird.sbone.de [46.4.1.90]) by mx1.freebsd.org (Postfix) with ESMTP id 098828FC0C for ; Wed, 22 Jun 2011 21:43:46 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 160BC25D3870; Wed, 22 Jun 2011 21:19:07 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id C249015A242D; Wed, 22 Jun 2011 21:19:06 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id m9fItJbFqA1y; Wed, 22 Jun 2011 21:19:05 +0000 (UTC) Received: from orange-en1.sbone.de (orange-en1.sbone.de [IPv6:fde9:577b:c1a9:31:cabc:c8ff:fecf:e8e3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 9414915A242A; Wed, 22 Jun 2011 21:19:04 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Bjoern A. Zeeb" In-Reply-To: <20110622121136.GC16648@home.opsec.eu> Date: Wed, 22 Jun 2011 21:19:03 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110622121136.GC16648@home.opsec.eu> To: Kurt Jaeger X-Mailer: Apple Mail (2.1084) Cc: freebsd-stable@freebsd.org Subject: Re: commit PR 154469, ftp-proxy(8) bug ? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 21:43:47 -0000 On Jun 22, 2011, at 12:11 PM, Kurt Jaeger wrote: > Hi! >=20 > Can someone have a look at >=20 > http://www.freebsd.org/cgi/query-pr.cgi?pr=3D154469 I have a pf45 universe tree sitting here with the works from max and = ermal that needs to go in; without checking specifically it should have the fix and the fix could possibly be merges to 8 from there then.... but knowing that just this fix applied to stable/8 works would be good = for that. /bz --=20 Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. From owner-freebsd-stable@FreeBSD.ORG Wed Jun 22 22:03:55 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F1976106566C; Wed, 22 Jun 2011 22:03:55 +0000 (UTC) (envelope-from pi@opsec.eu) Received: from home.opsec.eu (home.opsec.eu [213.178.180.1]) by mx1.freebsd.org (Postfix) with ESMTP id AEFE98FC19; Wed, 22 Jun 2011 22:03:55 +0000 (UTC) Received: from pi by home.opsec.eu with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1QZUqF-0005ct-60; Wed, 22 Jun 2011 23:20:07 +0200 Date: Wed, 22 Jun 2011 23:20:07 +0200 From: Kurt Jaeger To: John Baldwin Message-ID: <20110622212007.GD16648@home.opsec.eu> References: <20110622121136.GC16648@home.opsec.eu> <201106221712.57278.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201106221712.57278.jhb@freebsd.org> Cc: Kurt Jaeger , Bjoern Zeeb , freebsd-stable@freebsd.org Subject: Re: commit PR 154469, ftp-proxy(8) bug ? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 22:03:56 -0000 Hi! > > Can someone have a look at > > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=154469 > > > > and commit it ? So that it ends up in 8.3 8-} ? > > Does the patch from OpenBSD fix the problem for you? Yes, sure. That why I sent the pr! -- pi@opsec.eu +49 171 3101372 9 years to go ! From owner-freebsd-stable@FreeBSD.ORG Wed Jun 22 22:44:12 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C1AAC1065670 for ; Wed, 22 Jun 2011 22:44:12 +0000 (UTC) (envelope-from xaero@xaerolimit.net) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id 7AA1C8FC0A for ; Wed, 22 Jun 2011 22:44:12 +0000 (UTC) Received: by qyk30 with SMTP id 30so3347632qyk.13 for ; Wed, 22 Jun 2011 15:44:11 -0700 (PDT) Received: by 10.224.6.78 with SMTP id 14mr1094792qay.285.1308782650318; Wed, 22 Jun 2011 15:44:10 -0700 (PDT) Received: from gmail.com (ool-435056c7.dyn.optonline.net [67.80.86.199]) by mx.google.com with ESMTPS id t21sm762200qcs.26.2011.06.22.15.44.08 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 22 Jun 2011 15:44:09 -0700 (PDT) Date: Wed, 22 Jun 2011 18:44:06 -0400 From: Chris Brennan To: George Kontostanos Message-ID: <20110622224404.GA32157@gmail.com> References: <20110622164129.GB31480@gmail.com> <20110622171324.GC31480@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: FreeBSD Stable Subject: Re: ata: SIGNATURE: ffffffff X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 22:44:12 -0000 * George Kontostanos [2011-06-23 00:43:09 +0300]: > You already mentioned your thought about a faulty card. If you don't have to > add anything beyond that then please keep it for yourself. And yet, your still top posting. I was only pointing out the logical conclusion here. You've tried the obvious, time to move up the chain. I'm sorry you don't happen to like that but there is no need to be rude about it. -- > Chris Brennan > -- > A: Yes. > >Q: Are you sure? > >>A: Because it reverses the logical flow of conversation. > >>>Q: Why is top posting frowned upon? > http://xkcd.com/84/ | http://xkcd.com/149/ | http://xkcd.com/549/ > GPG: D5B20C0C (6741 8EE4 6C7D 11FB 8DA8 9E4A EECD 9A84 D5B2 0C0C) ------------------------------------------------------------------------ From owner-freebsd-stable@FreeBSD.ORG Wed Jun 22 23:02:35 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D0B2D106566C for ; Wed, 22 Jun 2011 23:02:35 +0000 (UTC) (envelope-from gkontos.mail@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 933D88FC0C for ; Wed, 22 Jun 2011 23:02:35 +0000 (UTC) Received: by iyb11 with SMTP id 11so1534541iyb.13 for ; Wed, 22 Jun 2011 16:02:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=gYn855dpbW+Sg2Yr5YKzCjqq0dqIEYA258xzX1uGItE=; b=d/xPVxHGL1R/bvfgQX4qvmf5smf9ZXyttLiEcOYZFr3zfM/lRjeWTnfKRSSqeFnSoY NqqjXyIFjiLL8kSk+8WhbRRGnQPhRMK3eTd1cp1Ye6BqzdPpvndkERJCQ6rqwRay2blP VqA5gRI5pZ5zakmQS1OfKyxnT5n0bWnRe2gIA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=iSrU5V4ZtG7S1jwav+EIe9hFEcRXEp2aHeJ8CekRyG0h1fFy7SSLGRjqxhrXo2wVWt mwBkgCEmcioOuECOsCHmr96jh83eaTx8tX82BEgJcmkzB6NHlSv7BPb/FqOTQKJS1sMq O858HCpDHMCSJYa8uJCwVAfeBb71K88NWdpFA= MIME-Version: 1.0 Received: by 10.231.114.78 with SMTP id d14mr463998ibq.137.1308783754979; Wed, 22 Jun 2011 16:02:34 -0700 (PDT) Received: by 10.231.15.5 with HTTP; Wed, 22 Jun 2011 16:02:34 -0700 (PDT) In-Reply-To: <20110622224404.GA32157@gmail.com> References: <20110622164129.GB31480@gmail.com> <20110622171324.GC31480@gmail.com> <20110622224404.GA32157@gmail.com> Date: Thu, 23 Jun 2011 02:02:34 +0300 Message-ID: From: George Kontostanos To: Chris Brennan Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: FreeBSD Stable Subject: Re: ata: SIGNATURE: ffffffff X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 23:02:35 -0000 Look, I think that this is getting personal and not constructive at all. Stop mumbling unless you have something useful to add. Like pointing out a old PR regarding this controller: http://www.freebsd.org/cgi/query-pr.cgi?pr=116935&cat= Best Regards, On Thu, Jun 23, 2011 at 1:44 AM, Chris Brennan wrote: > * George Kontostanos [2011-06-23 00:43:09 +0300]: > > > You already mentioned your thought about a faulty card. If you don't have > to > > add anything beyond that then please keep it for yourself. > > And yet, your still top posting. I was only pointing out the logical > conclusion here. You've tried the obvious, time to move up the chain. > I'm sorry you don't happen to like that but there is no need to be rude > about it. > > -- > > Chris Brennan > > -- > > A: Yes. > > >Q: Are you sure? > > >>A: Because it reverses the logical flow of conversation. > > >>>Q: Why is top posting frowned upon? > > http://xkcd.com/84/ | http://xkcd.com/149/ | http://xkcd.com/549/ > > GPG: D5B20C0C (6741 8EE4 6C7D 11FB 8DA8 9E4A EECD 9A84 D5B2 0C0C) > ------------------------------------------------------------------------ > -- George Kontostanos aisecure.net From owner-freebsd-stable@FreeBSD.ORG Thu Jun 23 00:58:36 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DEDAD106564A for ; Thu, 23 Jun 2011 00:58:36 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta04.emeryville.ca.mail.comcast.net (qmta04.emeryville.ca.mail.comcast.net [76.96.30.40]) by mx1.freebsd.org (Postfix) with ESMTP id C62EF8FC08 for ; Thu, 23 Jun 2011 00:58:34 +0000 (UTC) Received: from omta03.emeryville.ca.mail.comcast.net ([76.96.30.27]) by qmta04.emeryville.ca.mail.comcast.net with comcast id zCkD1g0020b6N64A4CyYoU; Thu, 23 Jun 2011 00:58:32 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta03.emeryville.ca.mail.comcast.net with comcast id zCyX1g00c1t3BNj8PCyYuz; Thu, 23 Jun 2011 00:58:32 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 69617102C36; Wed, 22 Jun 2011 17:58:32 -0700 (PDT) Date: Wed, 22 Jun 2011 17:58:32 -0700 From: Jeremy Chadwick To: George Kontostanos Message-ID: <20110623005832.GA26118@icarus.home.lan> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: FreeBSD Stable Subject: Re: ata: SIGNATURE: ffffffff X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2011 00:58:36 -0000 On Wed, Jun 22, 2011 at 05:52:39PM +0300, George Kontostanos wrote: > This is the 3rd disk I replace in 3 disk- Raiz1 pool and I really start to > believe that the problem is somewhere else. The disks reside in a Promise > PDC40718 SATA300 controller. I am running this set up since 8.0-Release with > no issues till a few months ago after 8.2-Release now at 8.2-Stable. > Symptoms: > > Jun 22 17:08:53 hp kernel: ata2: timeout waiting to issue command > Jun 22 17:08:53 hp kernel: ata2: error issuing SETFEATURES ENABLE WCACHE > command > Jun 22 17:09:33 hp kernel: ad4: WARNING - SET_MULTI taskqueue timeout - > completing request directly > Jun 22 17:09:33 hp kernel: ad4: WARNING - WRITE_DMA48 requeued due to > channel reset LBA=321558741 > Jun 22 17:09:34 hp kernel: ata2: SIGNATURE: 00000101 > Jun 22 17:09:34 hp kernel: ad4: WARNING - WRITE_DMA48 requeued due to > channel reset LBA=321558869 > Jun 22 17:09:34 hp kernel: ata2: FAILURE - already active DMA on this device > Jun 22 17:09:34 hp kernel: ata2: setting up DMA failed > Jun 22 17:09:34 hp kernel: ata2: FAILURE - already active DMA on this device > Jun 22 17:09:34 hp kernel: ata2: setting up DMA failed > > > After a while the disk gets detached from the pool. Always the same disk. > Rite now I am in the process of resilvering : > > pool: tank > state: ONLINE > status: One or more devices is currently being resilvered. The pool will > continue to function, possibly in a degraded state. > action: Wait for the resilver to complete. > scan: resilver in progress since Wed Jun 22 17:09:40 2011 > 189G scanned out of 578G at 88.8M/s, 1h14m to go > 62.9G resilvered, 32.63% done > config: > > NAME STATE READ WRITE CKSUM > tank ONLINE 0 0 0 > raidz1-0 ONLINE 0 0 0 > label/zdisk1 ONLINE 0 0 0 > label/zdisk2 ONLINE 0 0 0 > label/zdisk3 ONLINE 0 0 0 (resilvering) > > But those errors have started to appear again. Again this is the 3rd disk > replaced !!! Full dmesg attached > > -- > George Kontostanos > aisecure.net > Copyright (c) 1992-2011 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 8.2-STABLE #0: Mon Jun 6 19:00:19 EEST 2011 > gkontos@hp.aicom.loc:/usr/obj/usr/src/sys/ML110G3 amd64 > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: Intel(R) Pentium(R) D CPU 3.20GHz (3200.13-MHz K8-class CPU) > Origin = "GenuineIntel" Id = 0xf64 Family = f Model = 6 Stepping = 4 > Features=0xbfebfbff > Features2=0xe4bd > AMD Features=0x20100800 > AMD Features2=0x1 > TSC: P-state invariant > real memory = 4294967296 (4096 MB) > avail memory = 4106780672 (3916 MB) > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > FreeBSD/SMP: 1 package(s) x 2 core(s) > cpu0 (BSP): APIC ID: 0 > cpu1 (AP): APIC ID: 1 > ioapic0: Changing APIC ID to 2 > ioapic0 irqs 0-23 on motherboard > kbd1 at kbdmux0 > acpi0: on motherboard > acpi0: [ITHREAD] > acpi0: Power Button (fixed) > Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 > cpu0: on acpi0 > cpu1: on acpi0 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > pcib1: irq 16 at device 28.0 on pci0 > pci1: on pcib1 > pcib2: irq 17 at device 28.5 on pci0 > pci7: on pcib2 > bge0: mem 0xfeaf0000-0xfeafffff irq 17 at device 0.0 on pci7 > bge0: CHIP ID 0x00004101; ASIC REV 0x04; CHIP REV 0x41; PCI-E > miibus0: on bge0 > brgphy0: PHY 1 on miibus0 > brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow > bge0: Ethernet address: 00:13:21:cc:39:35 > bge0: [ITHREAD] > uhci0: port 0xdc00-0xdc1f irq 23 at device 29.0 on pci0 > uhci0: [ITHREAD] > uhci0: LegSup = 0x2f00 > usbus0: on uhci0 > uhci1: port 0xd880-0xd89f irq 19 at device 29.1 on pci0 > uhci1: [ITHREAD] > uhci1: LegSup = 0x2f00 > usbus1: on uhci1 > uhci2: port 0xd800-0xd81f irq 18 at device 29.2 on pci0 > uhci2: [ITHREAD] > uhci2: LegSup = 0x2f00 > usbus2: on uhci2 > ehci0: mem 0xfe9ffc00-0xfe9fffff irq 23 at device 29.7 on pci0 > ehci0: [ITHREAD] > usbus3: EHCI version 1.0 > usbus3: on ehci0 > pcib3: at device 30.0 on pci0 > pci8: on pcib3 > atapci0: port 0xec00-0xec7f,0xe800-0xe8ff mem 0xfebff000-0xfebfffff,0xfebc0000-0xfebdffff irq 16 at device 0.0 on pci8 > atapci0: [ITHREAD] > atapci0: [ITHREAD] > ata2: on atapci0 > ata2: SIGNATURE: 00000101 > ata2: [ITHREAD] > ata3: on atapci0 > ata3: SIGNATURE: 00000101 > ata3: [ITHREAD] > ata4: on atapci0 > ata4: [ITHREAD] > ata5: on atapci0 > ata5: SIGNATURE: 00000101 > ata5: [ITHREAD] > vgapci0: port 0xe000-0xe0ff mem 0xe8000000-0xefffffff,0xfebb0000-0xfebbffff irq 16 at device 2.0 on pci8 > isab0: at device 31.0 on pci0 > isa0: on isab0 > atapci1: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf at device 31.1 on pci0 > ata0: on atapci1 > ata0: [ITHREAD] > ahci0: port 0xd480-0xd487,0xd400-0xd403,0xd080-0xd087,0xd000-0xd003,0xcc00-0xcc0f mem 0xfe9ff800-0xfe9ffbff irq 19 at device 31.2 on pci0 > ahci0: [ITHREAD] > ahci0: AHCI v1.10 with 4 3Gbps ports, Port Multiplier not supported > ahcich0: at channel 0 on ahci0 > ahcich0: [ITHREAD] > ahcich1: at channel 1 on ahci0 > ahcich1: [ITHREAD] > ahcich2: at channel 2 on ahci0 > ahcich2: [ITHREAD] > ahcich3: at channel 3 on ahci0 > ahcich3: [ITHREAD] > acpi_button0: on acpi0 > atrtc0: port 0x70-0x71 irq 8 on acpi0 > uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 > uart0: [FILTER] > uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 > uart1: [FILTER] > ppc0: port 0x378-0x37f,0x778-0x77f irq 7 drq 3 on acpi0 > ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode > ppc0: FIFO with 16/16/8 bytes threshold > ppc0: [ITHREAD] > ppbus0: on ppc0 > plip0: on ppbus0 > plip0: [ITHREAD] > lpt0: on ppbus0 > lpt0: [ITHREAD] > lpt0: Interrupt-driven port > ppi0: on ppbus0 > orm0: at iomem 0xc0000-0xc8fff,0xc9000-0xcdfff,0xcf800-0xd47ff,0xd4800-0xd57ff on isa0 > sc0: at flags 0x100 on isa0 > sc0: VGA <16 virtual consoles, flags=0x300> > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 > atkbdc0: at port 0x60,0x64 on isa0 > atkbd0: irq 1 on atkbdc0 > kbd0 at atkbd0 > atkbd0: [GIANT-LOCKED] > atkbd0: [ITHREAD] > est0: on cpu0 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 102400001024 > device_attach: est0 attach returned 6 > p4tcc0: on cpu0 > est1: on cpu1 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 102400001024 > device_attach: est1 attach returned 6 > p4tcc1: on cpu1 > ZFS NOTICE: Prefetch is disabled by default if less than 4GB of RAM is present; > to enable, add "vfs.zfs.prefetch_disable=0" to /boot/loader.conf. > ZFS filesystem version 5 > ZFS storage pool version 28 > Timecounters tick every 1.000 msec > usbus0: 12Mbps Full Speed USB v1.0 > usbus1: 12Mbps Full Speed USB v1.0 > usbus2: 12Mbps Full Speed USB v1.0 > usbus3: 480Mbps High Speed USB v2.0 > ugen0.1: at usbus0 > uhub0: on usbus0 > ugen1.1: at usbus1 > uhub1: on usbus1 > ugen2.1: at usbus2 > uhub2: on usbus2 > ugen3.1: at usbus3 > uhub3: on usbus3 > ad4: 715404MB at ata2-master UDMA100 SATA 3Gb/s > ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 > ada0: ATA-7 SATA 1.x device > ada0: 150.000MB/s transfers (SATA 1.x, UDMA6, PIO 8192bytes) > ada0: Command Queueing enabled > ada0: 238475MB (488397168 512 byte sectors: 16H 63S/T 16383C) > ada1 at ahcich1 bus 0 scbus1 target 0 lun 0 > ada1: ATA-7 SATA 1.x device > ada1: 150.000MB/s transfers (SATA 1.x, UDMA6, PIO 8192bytes) > ada1: Command Queueing enabled > ada1: 238475MB (488397168 512 byte sectors: 16H 63S/T 16383C)ad6: 610480MB at ata3-master UDMA100 SATA 3Gb/s > > ad10: 610480MB at ata5-master UDMA100 SATA 3Gb/s > SMP: AP CPU #1 Launched! > Root mount waiting for: usbus3 usbus2 usbus1 usbus0 > uhub0: 2 ports with 2 removable, self powered > uhub1: 2 ports with 2 removable, self powered > uhub2: 2 ports with 2 removable, self powered > Root mount waiting for: usbus3 > uhub3: 6 ports with 6 removable, self powered > Root mount waiting for: usbus3 > ugen3.2: at usbus3 > umass0: on usbus3 > umass0: SCSI over Bulk-Only; quirks = 0x0000 > ugen0.2: at usbus0 > umass0:4:0:-1: Attached to scbus4 > Trying to mount root from zfs:zroot > da0 at umass-sim0 bus 0 scbus4 target 0 lun 0 > da0: Fixed Direct Access SCSI-4 device > da0: 40.000MB/s transfers > da0: 610480MB (1250263726 512 byte sectors: 255H 63S/T 77825C) > bge0: link state changed to UP > S > log_sysevent: type 19 is not implemented > ata2: SIGNATURE: ffffffff > ata2: timeout waiting to issue command > ata2: error issuing SETFEATURES SET TRANSFER MODE command > ata2: timeout waiting to issue command > ata2: error issuing SETFEATURES ENABLE RCACHE command > ata2: timeout waiting to issue command > ata2: error issuing SETFEATURES ENABLE WCACHE command > ad4: WARNING - SET_MULTI taskqueue timeout - completing request directly > ad4: WARNING - WRITE_DMA48 requeued due to channel reset LBA=321558741 > ata2: SIGNATURE: 00000101 > ad4: WARNING - WRITE_DMA48 requeued due to channel reset LBA=321558869 > ata2: FAILURE - already active DMA on this device > ata2: setting up DMA failed > ata2: FAILURE - already active DMA on this device > ata2: setting up DMA failed George, Can you please install ports/sysutils/smartmontools (should be version 5.41; if you have an older version please upgrade) and provide output from the following comman smartctl -a /dev/ad4 With this I should be able to rule out weird disk problems. It's always good to start there. For those unable to parse the above topology, the system has two SATA controllers (the Promise uses ata(4), while the on-board ICH7 is in AHCI mode and is using ahci.ko (AHCI-to-CAM)): atapci0 = Promise PDC40718 (Promise SATA300 TX4) --> ata2-master = ad4 = WDC WD7500AALX-009BA0 --> ata2-slave = --> ata3-master = ad6 = WDC WD6401AALS-00J7B1 --> ata3-slave = --> ata4-master = --> ata4-slave = --> ata5-master = ad10 = WDC WD6401AALS-00J7B1 --> ata5-slave = ahci0 = Intel ICH7 on-board in AHCI mode --> ahcich0 = ada0 = ST3250410AS 3.AAA --> ahcich1 = ada1 = ST3250410AS 3.AAA --> ahcich2 = --> ahcich3 = If you can't get this situation solved, I'd recommend spending $40 (pocket change) to invest in a Silicon Image 3124 card. Your existing Promise controller is a PCI card (not PCIe or PCI-X), and I don't know if your motherboard has any PCIe or PCI-X slots, so I'm going to assume the 133MByte/sec limitation is acceptable to you. As such, that limits you to effectively this card: http://www.newegg.com/Product/Product.aspx?Item=N82E16816132017 You do not have to use the RAID functionality of the card. FreeBSD supports this card using siis(4) and it does utilise CAM, so your disks would show up as adaX. The driver is actively supported/maintained. Avoid looking at cards which use the 3112, 3114, or 3512 chips. Hope this helps, or at least directs you in a path that lets you solve the problem through a little bit of money. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Thu Jun 23 01:56:59 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B9EC3106564A for ; Thu, 23 Jun 2011 01:56:59 +0000 (UTC) (envelope-from ml@my.gd) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 4DCE88FC17 for ; Thu, 23 Jun 2011 01:56:58 +0000 (UTC) Received: by fxm11 with SMTP id 11so1502168fxm.13 for ; Wed, 22 Jun 2011 18:56:58 -0700 (PDT) Received: by 10.223.27.18 with SMTP id g18mr1833170fac.52.1308794218057; Wed, 22 Jun 2011 18:56:58 -0700 (PDT) Received: from [192.168.0.47] (paris.c-mal.com [88.170.200.60]) by mx.google.com with ESMTPS id n7sm669755fam.43.2011.06.22.18.56.56 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 22 Jun 2011 18:56:57 -0700 (PDT) References: <20110622164129.GB31480@gmail.com> <20110622171324.GC31480@gmail.com> <20110622224404.GA32157@gmail.com> In-Reply-To: Mime-Version: 1.0 (iPhone Mail 8J2) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (8J2) From: Damien Fleuriot Date: Thu, 23 Jun 2011 03:56:54 +0200 To: George Kontostanos Cc: FreeBSD Stable , Chris Brennan Subject: Re: ata: SIGNATURE: ffffffff X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2011 01:56:59 -0000 On 23 Jun 2011, at 01:02, George Kontostanos wrote:= > Look, I think that this is getting personal and not constructive at all. > Stop mumbling unless you have something useful to add. >=20 How about you do what he says and stop top posting, as per the list's policy= ? Annoying pretty much everyone in the list with your stubbornness about top p= osting and your misplaced rudeness towards a helper might result in a drop i= n the number of people willing to spend time helping you. This being said, have you tried using a different PSU ?= From owner-freebsd-stable@FreeBSD.ORG Thu Jun 23 03:09:04 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2ECFD106564A for ; Thu, 23 Jun 2011 03:09:04 +0000 (UTC) (envelope-from xaero@xaerolimit.net) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id DE7C48FC0A for ; Thu, 23 Jun 2011 03:09:03 +0000 (UTC) Received: by qyk30 with SMTP id 30so3450964qyk.13 for ; Wed, 22 Jun 2011 20:09:03 -0700 (PDT) Received: by 10.224.203.73 with SMTP id fh9mr1184695qab.340.1308798542693; Wed, 22 Jun 2011 20:09:02 -0700 (PDT) Received: from gmail.com (ool-435056c7.dyn.optonline.net [67.80.86.199]) by mx.google.com with ESMTPS id l36sm561432qck.43.2011.06.22.20.09.00 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 22 Jun 2011 20:09:01 -0700 (PDT) Date: Wed, 22 Jun 2011 23:08:57 -0400 From: Chris Brennan To: Damien Fleuriot Message-ID: <20110623030856.GA32455@gmail.com> References: <20110622164129.GB31480@gmail.com> <20110622171324.GC31480@gmail.com> <20110622224404.GA32157@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: FreeBSD Stable , George Kontostanos Subject: Re: ata: SIGNATURE: ffffffff X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2011 03:09:04 -0000 * Damien Fleuriot [2011-06-23 03:56:54 +0200]: > On 23 Jun 2011, at 01:02, George Kontostanos wrote: > > > Look, I think that this is getting personal and not constructive at all. > > Stop mumbling unless you have something useful to add. > > > > How about you do what he says and stop top posting, as per the list's policy ? > > Annoying pretty much everyone in the list with your stubbornness about > top posting and your misplaced rudeness towards a helper might result > in a drop in the number of people willing to spend time helping you. This will be my last post on this topic. George you are rude and I know I will not be offering any more suggestions for you. I foresee few others willing to help you now as well. Jeremy has willingly given you a great amount of detail to work with and it's up to him to look past your rude behavior and continue to help you. -- > Chris Brennan > -- > A: Yes. > >Q: Are you sure? > >>A: Because it reverses the logical flow of conversation. > >>>Q: Why is top posting frowned upon? > http://xkcd.com/84/ | http://xkcd.com/149/ | http://xkcd.com/549/ > GPG: D5B20C0C (6741 8EE4 6C7D 11FB 8DA8 9E4A EECD 9A84 D5B2 0C0C) ------------------------------------------------------------------------ From owner-freebsd-stable@FreeBSD.ORG Thu Jun 23 04:05:46 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2EC2F106566B for ; Thu, 23 Jun 2011 04:05:46 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta02.emeryville.ca.mail.comcast.net (qmta02.emeryville.ca.mail.comcast.net [76.96.30.24]) by mx1.freebsd.org (Postfix) with ESMTP id 109228FC17 for ; Thu, 23 Jun 2011 04:05:45 +0000 (UTC) Received: from omta21.emeryville.ca.mail.comcast.net ([76.96.30.88]) by qmta02.emeryville.ca.mail.comcast.net with comcast id zFzp1g0051u4NiLA2G5jSs; Thu, 23 Jun 2011 04:05:43 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta21.emeryville.ca.mail.comcast.net with comcast id zG4r1g0081t3BNj8hG4rir; Thu, 23 Jun 2011 04:04:52 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id BED9F102C36; Wed, 22 Jun 2011 21:05:43 -0700 (PDT) Date: Wed, 22 Jun 2011 21:05:43 -0700 From: Jeremy Chadwick To: Chris Brennan Message-ID: <20110623040543.GA30691@icarus.home.lan> References: <20110622164129.GB31480@gmail.com> <20110622171324.GC31480@gmail.com> <20110622224404.GA32157@gmail.com> <20110623030856.GA32455@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110623030856.GA32455@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: FreeBSD Stable , George Kontostanos Subject: Re: ata: SIGNATURE: ffffffff X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2011 04:05:46 -0000 On Wed, Jun 22, 2011 at 11:08:57PM -0400, Chris Brennan wrote: > * Damien Fleuriot [2011-06-23 03:56:54 +0200]: > > > On 23 Jun 2011, at 01:02, George Kontostanos wrote: > > > > > Look, I think that this is getting personal and not constructive at all. > > > Stop mumbling unless you have something useful to add. > > > > > > > How about you do what he says and stop top posting, as per the list's policy ? > > > > Annoying pretty much everyone in the list with your stubbornness about > > top posting and your misplaced rudeness towards a helper might result > > in a drop in the number of people willing to spend time helping you. > > This will be my last post on this topic. George you are rude and I know > I will not be offering any more suggestions for you. I foresee few > others willing to help you now as well. Jeremy has willingly given you a > great amount of detail to work with and it's up to him to look past your > rude behavior and continue to help you. The difference is that I really don't care if people top-post, bottom-post, or respond in-line. I work with whatever I'm presented with. I personally use all 3 methods depending upon the context is and what mailing list rules allow/permit. But it varies per list, and some lists have zealots that absolutely despise top-posting (even if the list permits it). I fully acknowledge that the FreeBSD lists advocate and insist upon in-line or bottom-post replies, and I honour that -- as should George. But let's be reasonable: there's a problem at hand that George is needing help with. The last thing a person under duress (re: in a situation like this) needs is to be lectured about "not confirming to mailing list style". I say this knowing that conforming to said list style is important, however. I tend to keep my "style conformity" requests very terse and mentioned as one-liners at the bottom of the mail, e.g. "P.S. -- Folks here don't like top-posting, please try to avoid it if you can, thanks!". Otherwise all it does is irritate an already-irritated person who's in need of assistance. Remember: they took the time to ask for help, which in this day and age is practically a miracle. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Thu Jun 23 04:22:56 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4E4191065670 for ; Thu, 23 Jun 2011 04:22:56 +0000 (UTC) (envelope-from ml@my.gd) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id D15BD8FC08 for ; Thu, 23 Jun 2011 04:22:54 +0000 (UTC) Received: by wwe6 with SMTP id 6so1427397wwe.31 for ; Wed, 22 Jun 2011 21:22:54 -0700 (PDT) Received: by 10.227.28.200 with SMTP id n8mr1452292wbc.97.1308802973873; Wed, 22 Jun 2011 21:22:53 -0700 (PDT) Received: from jumpvm.public.fotolog.net (paris.c-mal.com [88.170.200.60]) by mx.google.com with ESMTPS id gb6sm922201wbb.0.2011.06.22.21.22.51 (version=SSLv3 cipher=OTHER); Wed, 22 Jun 2011 21:22:52 -0700 (PDT) Message-ID: <4E02BF99.4070409@my.gd> Date: Thu, 23 Jun 2011 06:22:49 +0200 From: Damien Fleuriot User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Jeremy Chadwick References: <20110622164129.GB31480@gmail.com> <20110622171324.GC31480@gmail.com> <20110622224404.GA32157@gmail.com> <20110623030856.GA32455@gmail.com> <20110623040543.GA30691@icarus.home.lan> In-Reply-To: <20110623040543.GA30691@icarus.home.lan> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Stable , George Kontostanos , Chris Brennan Subject: Re: ata: SIGNATURE: ffffffff X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2011 04:22:56 -0000 On 6/23/11 6:05 AM, Jeremy Chadwick wrote: > On Wed, Jun 22, 2011 at 11:08:57PM -0400, Chris Brennan wrote: >> * Damien Fleuriot [2011-06-23 03:56:54 +0200]: >> >>> On 23 Jun 2011, at 01:02, George Kontostanos wrote: >>> >>>> Look, I think that this is getting personal and not constructive at all. >>>> Stop mumbling unless you have something useful to add. >>>> >>> >>> How about you do what he says and stop top posting, as per the list's policy ? >>> >>> Annoying pretty much everyone in the list with your stubbornness about >>> top posting and your misplaced rudeness towards a helper might result >>> in a drop in the number of people willing to spend time helping you. >> >> This will be my last post on this topic. George you are rude and I know >> I will not be offering any more suggestions for you. I foresee few >> others willing to help you now as well. Jeremy has willingly given you a >> great amount of detail to work with and it's up to him to look past your >> rude behavior and continue to help you. > > > The difference is that I really don't care if people top-post, > bottom-post, or respond in-line. I work with whatever I'm presented > with. > > I personally use all 3 methods depending upon the context is and what > mailing list rules allow/permit. But it varies per list, and some lists > have zealots that absolutely despise top-posting (even if the list > permits it). > > I fully acknowledge that the FreeBSD lists advocate and insist upon > in-line or bottom-post replies, and I honour that -- as should George. > > But let's be reasonable: there's a problem at hand that George is > needing help with. The last thing a person under duress (re: in a > situation like this) needs is to be lectured about "not confirming to > mailing list style". I say this knowing that conforming to said list > style is important, however. > The guy has, basically, told Chris to fuck off until he has something else to add other than "if I were you, I'd check your card, that's the next logical step". Like, totally biting the hand that feeds really... That the guy failed the most basic of social skill by not bothering to say "hi guys" or "hi list" or "hi everyone" when posting, that I would overlook. But replying in this manner to someone that actually offered a valid suggestion ? I've become unwilling to spend time trying to figure his problem out, I don't even want to lose time *reading* his emails at this point. He's lucky you're far more forgiving. That's my last mail on the matter, don't wanna generate noise for sub'ers. From owner-freebsd-stable@FreeBSD.ORG Thu Jun 23 04:58:37 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0628F106564A for ; Thu, 23 Jun 2011 04:58:37 +0000 (UTC) (envelope-from garmitage@swin.edu.au) Received: from gpo1.cc.swin.edu.au (gpo1.cc.swin.edu.au [136.186.1.30]) by mx1.freebsd.org (Postfix) with ESMTP id 9033A8FC16 for ; Thu, 23 Jun 2011 04:58:35 +0000 (UTC) Received: from [136.186.229.44] (garmitage3.caia.swin.edu.au [136.186.229.44]) by gpo1.cc.swin.edu.au (8.14.3/8.14.3) with ESMTP id p5N4DKIE002529 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 23 Jun 2011 14:13:48 +1000 Message-ID: <4E02BD60.1060507@swin.edu.au> Date: Thu, 23 Jun 2011 14:13:20 +1000 From: grenville armitage User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.13) Gecko/20101211 Thunderbird/3.1.7 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <20110622164129.GB31480@gmail.com> <20110622171324.GC31480@gmail.com> <20110622224404.GA32157@gmail.com> <20110623030856.GA32455@gmail.com> <20110623040543.GA30691@icarus.home.lan> In-Reply-To: <20110623040543.GA30691@icarus.home.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: ata: SIGNATURE: ffffffff X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2011 04:58:37 -0000 On 06/23/2011 14:05, Jeremy Chadwick wrote: [..] > > The difference is that I really don't care if people top-post, > bottom-post, or respond in-line. I work with whatever I'm presented > with. +1 cheers, gja From owner-freebsd-stable@FreeBSD.ORG Thu Jun 23 05:48:03 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8708B1065674; Thu, 23 Jun 2011 05:48:03 +0000 (UTC) (envelope-from melifaro@ipfw.ru) Received: from no.spam.no.ddos.ru (no.spam.no.ddos.ru [77.73.233.132]) by mx1.freebsd.org (Postfix) with ESMTP id 391868FC14; Thu, 23 Jun 2011 05:48:01 +0000 (UTC) Received: from ws.su29.net (v6.mpls.in [IPv6:2a02:978:2::5]) by no.spam.no.ddos.ru (Postfix) with ESMTPA id 9546F38599A; Thu, 23 Jun 2011 09:21:36 +0400 (MSD) Message-ID: <4E02CD66.2050306@ipfw.ru> Date: Thu, 23 Jun 2011 09:21:42 +0400 From: "Alexander V. Chernikov" User-Agent: Thunderbird 2.0.0.24 (X11/20100515) MIME-Version: 1.0 To: Kurt Jaeger References: <20110622121136.GC16648@home.opsec.eu> <201106221712.57278.jhb@freebsd.org> <20110622212007.GD16648@home.opsec.eu> In-Reply-To: <20110622212007.GD16648@home.opsec.eu> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Bjoern Zeeb , Kurt Jaeger , freebsd-stable@freebsd.org, John Baldwin Subject: Re: commit PR 154469, ftp-proxy(8) bug ? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2011 05:48:03 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Kurt Jaeger wrote: > Hi! > >>> Can someone have a look at >>> >>> http://www.freebsd.org/cgi/query-pr.cgi?pr=154469 >>> >>> and commit it ? So that it ends up in 8.3 8-} ? >> Does the patch from OpenBSD fix the problem for you? > > Yes, sure. That why I sent the pr! > Yep, the patch does the right thing: Setup: FTP server: 87.51.34.132 (ftp.freebsd.org) FTP client: 10.11.0.8 (stock freebsd ftp client) GW with pf & ftp-proxy (FreeBSD 7.3) ext: em0 77.73.232.13 int: vlan3 10.11.0.1 FTP session: 23:50 [0] bibi# ftp -a 87.51.34.132 Connected to 87.51.34.132. 220 ftp.beastie.tdk.net FTP server (Version 6.00LS) ready. 331 Guest login ok, send your email address as password. 230 Guest login ok, access restrictions apply. Remote system type is UNIX. Using binary mode to transfer files. ftp> quit TCPDUMP (10.11.0.8 em0): (-lnpAs0 host 87.51.34.132) 23:51:39.487136 IP 10.11.0.8.47376 > 87.51.34.132.21: Flags [P.], ack 303, win 8326, options [nop,nop,TS val 458938281 ecr 1611018784], length 6 E..:b.@.@.TW ...W3".......E....... ........ .Z..`.2 QUIT 23:51:39.530414 IP 87.51.34.132.21 > 10.11.0.8.47376: Flags [F.], seq 303, ack 56, win 4163, options [nop,nop,TS val 1611020954 ecr 458938281], length 0 E..4..@.@...W3". .............E....CT...... `.:..Z.. Note 'server' silently closing connection TCPDUMP (GW em0): 23:56:20.405425 IP 77.73.232.13.61168 > 87.51.34.132.21: P 50:56(6) ack 303 win 4163 W3".........dn.....C....... x...sA6.QUIT 23:56:20.448332 IP 87.51.34.132.21 > 77.73.232.13.61168: . ack 56 win 257 ....dn...........&..... sA>.x... 23:56:20.448345 IP 87.51.34.132.21 > 77.73.232.13.61168: P 303:317(14) ack 56 win 257 ....dn...........8..... sA>.x...221 Goodbye. 23:56:20.448353 IP 87.51.34.132.21 > 77.73.232.13.61168: F 317:317(0) ack 56 win 257 ....dn.&............... sA>.x... Note real server transmits '221 Goodbye' After applying patch: 23:54 [0] bibi# ftp -a 87.51.34.132 Connected to 87.51.34.132. 220 ftp.beastie.tdk.net FTP server (Version 6.00LS) ready. 331 Guest login ok, send your email address as password. 230 Guest login ok, access restrictions apply. Remote system type is UNIX. Using binary mode to transfer files. ftp> quit 221 Goodbye. Note '221 Goodvye' received by ftp client -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4CzWYACgkQwcJ4iSZ1q2lOcwCfYqknB9i1P7bfjgYVpSjkSWP1 Y8wAn3hC2pZ/OHDicCN+o3v1O5YiFZ8W =dqk/ -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Thu Jun 23 09:27:37 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 017831065677 for ; Thu, 23 Jun 2011 09:27:37 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta15.emeryville.ca.mail.comcast.net (qmta15.emeryville.ca.mail.comcast.net [76.96.27.228]) by mx1.freebsd.org (Postfix) with ESMTP id DCD948FC1F for ; Thu, 23 Jun 2011 09:27:36 +0000 (UTC) Received: from omta20.emeryville.ca.mail.comcast.net ([76.96.30.87]) by qmta15.emeryville.ca.mail.comcast.net with comcast id zMMJ1g0021smiN4AFMTaAa; Thu, 23 Jun 2011 09:27:34 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta20.emeryville.ca.mail.comcast.net with comcast id zMUV1g00J1t3BNj8gMUVyn; Thu, 23 Jun 2011 09:28:30 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 10B06102C36; Thu, 23 Jun 2011 02:27:35 -0700 (PDT) Date: Thu, 23 Jun 2011 02:27:35 -0700 From: Jeremy Chadwick To: Alexander Motin Message-ID: <20110623092735.GA2464@icarus.home.lan> References: <20110618005124.GA43568@icarus.home.lan> <20110621191626.GA99204@icarus.home.lan> <4E01AFBA.809@FreeBSD.org> <20110622103703.GA14901@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110622103703.GA14901@icarus.home.lan> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org Subject: Re: MFC: graid(8) (RAID GEOM) support X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2011 09:27:37 -0000 On Wed, Jun 22, 2011 at 03:37:03AM -0700, Jeremy Chadwick wrote: > On Wed, Jun 22, 2011 at 12:02:50PM +0300, Alexander Motin wrote: > > Jeremy Chadwick wrote: > > > On Fri, Jun 17, 2011 at 05:51:24PM -0700, Jeremy Chadwick wrote: > > >> Sorry for the cross-post, but I thought both lists would want to know > > >> about this. > > >> > > >> Looks like mav@ just committed this ~17 hours ago: > > >> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/geom/raid/g_raid.c > > >> > > >> Those who have historically wanted to use Intel MatrixRAID (now called > > >> Intel RST (Rapid Storage Technology)), but haven't due to the severe > > >> issues/risks with ataraid(4), will probably be very interested in > > >> this commit. I know I am! > > >> > > >> I plan on stress-testing the Intel support on a 2-disk system with > > >> RAID-1 enabled, and will document my experiences, procedures, etc... > > >> > > >> Thanks, mav@ and imp@ ! > > >> > > >> I'll be sending another mail momentarily asking about USB memory stick > > >> image building, since to accomplish the above, I want to do a > > >> "bare-bones" install on our test system (e.g. enable Intel RAID, set up > > >> 2 disks in a RAID-1 mirror, boot a USB memory stick that contains this > > >> latest RELENG_8 build, and do sysinstall, etc.. the normal way). > > >> > > >> > > >> ===================================================================== > > >> MFC r219974, r220209, r220210, r220790: > > >> Add new RAID GEOM class, that is going to replace ataraid(4) in supporting > > >> various BIOS-based software RAIDs. Unlike ataraid(4) this implementation > > >> does not depend on legacy ata(4) subsystem and can be used with any disk > > >> drivers, including new CAM-based ones (ahci(4), siis(4), mvs(4), ata(4) > > >> with `options ATA_CAM`). To make code more readable and extensible, this > > >> implementation follows modular design, including core part and two sets > > >> of modules, implementing support for different metadata formats and RAID > > >> levels. > > >> > > >> Support for such popular metadata formats is now implemented: > > >> Intel, JMicron, NVIDIA, Promise (also used by AMD/ATI) and SiliconImage. > > >> > > >> Such RAID levels are now supported: > > >> RAID0, RAID1, RAID1E, RAID10, SINGLE, CONCAT. > > >> > > >> For all of these RAID levels and metadata formats this class supports > > >> full cycle of volume operations: reading, writing, creation, deletion, > > >> disk removal and insertion, rebuilding, dirty shutdown detection > > >> and resynchronization, bad sector recovery, faulty disks tracking, > > >> hot-spare disks. For Intel and Promise formats there is support multiple > > >> volumes per disk set. > > >> > > >> Look graid(8) manual page for additional details. > > >> > > >> Co-authored by: imp > > >> Sponsored by: Cisco Systems, Inc. and iXsystems, Inc. > > >> ===================================================================== > > > > > > By the way, it doesn't look like the graid(8) man page is being brought > > > in to the base system on either of the two RELENG_8 systems I've rebuilt > > > in the past few days. > > > > > > I'm thinking /usr/src/sbin/geom/class/raid/graid.8 isn't being noticed > > > as a man page. > > > > > > /usr/src/sbin/geom/class/raid/Makefile doesn't have MAN8=graid.8 in it, > > > is that the problem? > > > > I've just rebuilt my test 8-STABLE system and it installed graid(8). > > Hmm, there must be something I'm missing either in the base system or > the kernel or both. Does this kernel module and/or bits and pieces not > get built unless it's included strictly in the kernel? > > Below is one of the two systems, looking for both graid* and geom_raid*. > There's the old geom_raid3 stuff there, and the source bits/pieces for > the new graid(8), but nothing seems built (including kernel module) for > the new graid(8). > > If you'd like I can rm -fr /usr/src/* ; rm -fr /var/db/sup/src-all and > then re-download source from an official cvsup mirror (I've been using > cvsup9.freebsd.org for both boxes). > > icarus# uname -a > FreeBSD icarus.home.lan 8.2-STABLE FreeBSD 8.2-STABLE #0: Fri Jun 17 18:01:45 PDT 2011 root@icarus.home.lan:/usr/obj/usr/src/sys/X7SBA_RELENG_8_amd64 amd64 > icarus# find /usr -name "graid*" -ls > 3211128 8 -r--r--r-- 1 root wheel 2521 Jun 17 18:25 /usr/share/man/man8/graid3.8.gz > 169318 16 -rw-r--r-- 1 root wheel 6390 Aug 3 2009 /usr/src/sbin/geom/class/raid3/graid3.8 > 169624 16 -rw-r--r-- 1 root wheel 8126 Jun 16 23:59 /usr/src/sbin/geom/class/raid/graid.8 > 921430 8 -rw-r--r-- 1 root wheel 2521 Jun 17 17:51 /usr/obj/usr/src/sbin/geom/class/raid3/graid3.8.gz > 3369372 4 drwxr-xr-x 2 root wheel 512 May 3 03:58 /usr/ports/sysutils/graid5 > icarus# > icarus# find /boot -name "graid*" -ls > icarus# > icarus# find /usr -name "geom_raid*" -ls > 169317 20 -rw-r--r-- 1 root wheel 9257 Jan 18 21:13 /usr/src/sbin/geom/class/raid3/geom_raid3.c > 165265 8 -rw-r--r-- 1 root wheel 2992 Jun 16 23:59 /usr/src/sbin/geom/class/raid/geom_raid.c > 259652 4 drwxr-xr-x 2 root wheel 512 Jun 6 06:28 /usr/src/sys/modules/geom/geom_raid3 > 285292 4 drwxr-xr-x 2 root wheel 512 Jun 17 17:17 /usr/src/sys/modules/geom/geom_raid > 262798 4 drwxr-xr-x 2 root wheel 512 Jun 6 06:29 /usr/src/tools/regression/geom_raid3 > 921428 48 -rw-r--r-- 1 root wheel 22760 Jun 17 17:51 /usr/obj/usr/src/sbin/geom/class/raid3/geom_raid3.So > 921431 64 -rwxr-xr-x 1 root wheel 32207 Jun 17 17:51 /usr/obj/usr/src/sbin/geom/class/raid3/geom_raid3.so > 1014175 4 drwxr-xr-x 2 root wheel 512 Jun 17 18:00 /usr/obj/usr/src/sys/X7SBA_RELENG_8_amd64/modules/usr/src/sys/modules/geom/geom_raid3 > 1015257 736 -rw-r--r-- 1 root wheel 359456 Jun 17 18:00 /usr/obj/usr/src/sys/X7SBA_RELENG_8_amd64/modules/usr/src/sys/modules/geom/geom_raid3/geom_raid3.ko.debug > 1015258 640 -rw-r--r-- 1 root wheel 304432 Jun 17 18:00 /usr/obj/usr/src/sys/X7SBA_RELENG_8_amd64/modules/usr/src/sys/modules/geom/geom_raid3/geom_raid3.ko.symbols > 1015259 272 -rw-r--r-- 1 root wheel 137448 Jun 17 18:00 /usr/obj/usr/src/sys/X7SBA_RELENG_8_amd64/modules/usr/src/sys/modules/geom/geom_raid3/geom_raid3.ko > icarus# > icarus# find /boot -name "geom_raid*" -ls > 94943 272 -r-xr-xr-x 1 root wheel 137448 Jun 17 18:24 /boot/kernel/geom_raid3.ko > 94944 640 -r-xr-xr-x 1 root wheel 304432 Jun 17 18:24 /boot/kernel/geom_raid3.ko.symbols > 71074 272 -r-xr-xr-x 1 root wheel 137448 Jun 6 05:35 /boot/kernel.old/geom_raid3.ko > 71075 640 -r-xr-xr-x 1 root wheel 304432 Jun 6 05:35 /boot/kernel.old/geom_raid3.ko.symbols A follow-up to this issue. I went ahead with the following: rm -fr /usr/obj rm -fr /usr/src/* rm -fr /var/db/sup/src-all csup -4 -L 2 -h cvsup10.freebsd.org /usr/share/examples/cvsup/stable-supfile <...put my kernel config back into in /sys/amd64/conf...> cd /usr/src make -j4 buildworld && make -j4 buildkernel And here's what I've in /usr/obj. Note that the find statement is looking for graid* and geom_raid* while excluding raid3 stuff: icarus# find /usr/obj \( -name "graid*" -or -name "geom_raid*" \) -and \! -name "*raid3*" -ls 921216 16 -rw-r--r-- 1 root wheel 6600 Jun 23 01:10 /usr/obj/usr/src/sbin/geom/class/raid/geom_raid.So 921219 8 -rw-r--r-- 1 root wheel 2952 Jun 23 01:10 /usr/obj/usr/src/sbin/geom/class/raid/graid.8.gz 921223 44 -rwxr-xr-x 1 root wheel 20913 Jun 23 01:10 /usr/obj/usr/src/sbin/geom/class/raid/geom_raid.so 991578 4 drwxr-xr-x 2 root wheel 1024 Jun 23 02:04 /usr/obj/usr/src/sys/X7SBA_RELENG_8_amd64/modules/usr/src/sys/modules/geom/geom_raid 992668 2368 -rw-r--r-- 1 root wheel 1181256 Jun 23 02:04 /usr/obj/usr/src/sys/X7SBA_RELENG_8_amd64/modules/usr/src/sys/modules/geom/geom_raid/geom_raid.ko.debug 992669 2048 -rw-r--r-- 1 root wheel 1029944 Jun 23 02:04 /usr/obj/usr/src/sys/X7SBA_RELENG_8_amd64/modules/usr/src/sys/modules/geom/geom_raid/geom_raid.ko.symbols 992670 640 -rw-r--r-- 1 root wheel 307696 Jun 23 02:04 /usr/obj/usr/src/sys/X7SBA_RELENG_8_amd64/modules/usr/src/sys/modules/geom/geom_raid/geom_raid.ko This looks a *lot* better. Note that I went with cvsup10 instead of cvsup9; cvsup9 appears to be down right now (I've tried from other hosts), which makes me wonder if somehow that server is "out of whack" in some way. icarus# telnet cvsup9.freebsd.org 5999 Trying 208.83.20.166... ^C Sorry for the noise, Alexander! -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Thu Jun 23 11:57:34 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (unknown [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4DB92106564A for ; Thu, 23 Jun 2011 11:57:34 +0000 (UTC) (envelope-from gkontos.mail@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 087E88FC18 for ; Thu, 23 Jun 2011 11:57:33 +0000 (UTC) Received: by iyb11 with SMTP id 11so2084411iyb.13 for ; Thu, 23 Jun 2011 04:57:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=fiH/kwJKzAqE4h6eBTNHHoNnXFPUnOLQ79qZ9xnxvrg=; b=i5m1xsw6g3ZFoPJM4uwgrnb+moPWQdao1iGaLIp0G9Q9ZL8setEYQhda7jdt9OHhpk KINdA1zL+ui0RvxrrvNCVQW//Dk6r3j7eIwXGrLGcE2awat7vjNyIVpJyti+MeDLC/mq 1HLVGTxIPQPZKA9MZrhSE7Bp8nrCHraKnsnaM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=eksGe4HDxNQp9W0GbIdqF0LJLV5zBrGVBmtRb2B3emsG2Km2590Q0MkcxBQuMczbQp aQDInWCsmnY7XH1194KL9HvPLHwfsXsuIAC9pPMeUoxNI9Z4G/76pWNc/RvzeUKLr17+ atPOrrqt+qGSRiBvv7CQm06k63kcKYxZ6qvmc= MIME-Version: 1.0 Received: by 10.43.61.196 with SMTP id wx4mr1739318icb.310.1308830252999; Thu, 23 Jun 2011 04:57:32 -0700 (PDT) Received: by 10.231.15.5 with HTTP; Thu, 23 Jun 2011 04:57:32 -0700 (PDT) In-Reply-To: <20110623005832.GA26118@icarus.home.lan> References: <20110623005832.GA26118@icarus.home.lan> Date: Thu, 23 Jun 2011 14:57:32 +0300 Message-ID: From: George Kontostanos To: Jeremy Chadwick Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: FreeBSD Stable Subject: Re: ata: SIGNATURE: ffffffff X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2011 11:57:34 -0000 Hi Jeremy, I am using the smartmon tools and in fact the first drive I replaced did show some errors. Next two of them were zeroed out and thoroughly tested using WD tools. No errors were reported either by smartmon nor by WD tools. I was also glad when the shop I bought them replaced them immediately, no questions asked. They said that they were having a lot of issues with WD drives lately. I will probably try to get a different brand controller especially after seeing the relevant PR Thanks, hp# smartctl -a /dev/ad4 smartctl 5.41 2011-06-09 r3365 [FreeBSD 8.2-STABLE amd64] (local build) Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net === START OF INFORMATION SECTION === Model Family: Western Digital Caviar Blue Serial ATA Device Model: WDC WD7500AALX-009BA0 Serial Number: WD-WCATR5711398 LU WWN Device Id: 5 0014ee 25ad8ccf5 Firmware Version: 15.01H15 User Capacity: 750,156,374,016 bytes [750 GB] Sector Size: 512 bytes logical/physical Device is: In smartctl database [for details use: -P show] ATA Version is: 8 ATA Standard is: Exact ATA specification draft version not indicated Local Time is: Thu Jun 23 14:46:12 2011 EEST SMART support is: Available - device has SMART capability. SMART support is: Enabled === START OF READ SMART DATA SECTION === SMART overall-health self-assessment test result: PASSED General SMART Values: Offline data collection status: (0x82) Offline data collection activity was completed without error. Auto Offline Data Collection: Enabled. Self-test execution status: ( 0) The previous self-test routine completed without error or no self-test has ever been run. Total time to complete Offline data collection: (13260) seconds. Offline data collection capabilities: (0x7b) SMART execute Offline immediate. Auto Offline data collection on/off support. Suspend Offline collection upon new command. Offline surface scan supported. Self-test supported. Conveyance Self-test supported. Selective Self-test supported. SMART capabilities: (0x0003) Saves SMART data before entering power-saving mode. Supports SMART auto save timer. Error logging capability: (0x01) Error logging supported. General Purpose Logging supported. Short self-test routine recommended polling time: ( 2) minutes. Extended self-test routine recommended polling time: ( 155) minutes. Conveyance self-test routine recommended polling time: ( 5) minutes. SCT capabilities: (0x3037) SCT Status supported. SCT Feature Control supported. SCT Data Table supported. SMART Attributes Data Structure revision number: 16 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x002f 200 200 051 Pre-fail Always - 0 3 Spin_Up_Time 0x0027 188 178 021 Pre-fail Always - 3558 4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 10 5 Reallocated_Sector_Ct 0x0033 200 200 140 Pre-fail Always - 0 7 Seek_Error_Rate 0x002e 200 200 000 Old_age Always - 0 9 Power_On_Hours 0x0032 100 100 000 Old_age Always - 21 10 Spin_Retry_Count 0x0032 100 253 000 Old_age Always - 0 11 Calibration_Retry_Count 0x0032 100 253 000 Old_age Always - 0 12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 8 192 Power-Off_Retract_Count 0x0032 200 200 000 Old_age Always - 7 193 Load_Cycle_Count 0x0032 200 200 000 Old_age Always - 2 194 Temperature_Celsius 0x0022 110 107 000 Old_age Always - 37 196 Reallocated_Event_Count 0x0032 200 200 000 Old_age Always - 0 197 Current_Pending_Sector 0x0032 200 200 000 Old_age Always - 0 198 Offline_Uncorrectable 0x0030 200 200 000 Old_age Offline - 0 199 UDMA_CRC_Error_Count 0x0032 200 200 000 Old_age Always - 0 200 Multi_Zone_Error_Rate 0x0008 200 200 000 Old_age Offline - 0 SMART Error Log Version: 1 No Errors Logged SMART Self-test log structure revision number 1 No self-tests have been logged. [To run self-tests, use: smartctl -t] SMART Selective self-test log data structure revision number 1 SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS 1 0 0 Not_testing 2 0 0 Not_testing 3 0 0 Not_testing 4 0 0 Not_testing 5 0 0 Not_testing Selective self-test flags (0x0): After scanning selected spans, do NOT read-scan remainder of disk. If Selective self-test is pending on power-up, resume after 0 minute delay. On Thu, Jun 23, 2011 at 3:58 AM, Jeremy Chadwick wrote: > On Wed, Jun 22, 2011 at 05:52:39PM +0300, George Kontostanos wrote: > > This is the 3rd disk I replace in 3 disk- Raiz1 pool and I really start > to > > believe that the problem is somewhere else. The disks reside in a Promise > > PDC40718 SATA300 controller. I am running this set up since 8.0-Release > with > > no issues till a few months ago after 8.2-Release now at 8.2-Stable. > > Symptoms: > > > > Jun 22 17:08:53 hp kernel: ata2: timeout waiting to issue command > > Jun 22 17:08:53 hp kernel: ata2: error issuing SETFEATURES ENABLE WCACHE > > command > > Jun 22 17:09:33 hp kernel: ad4: WARNING - SET_MULTI taskqueue timeout - > > completing request directly > > Jun 22 17:09:33 hp kernel: ad4: WARNING - WRITE_DMA48 requeued due to > > channel reset LBA=321558741 > > Jun 22 17:09:34 hp kernel: ata2: SIGNATURE: 00000101 > > Jun 22 17:09:34 hp kernel: ad4: WARNING - WRITE_DMA48 requeued due to > > channel reset LBA=321558869 > > Jun 22 17:09:34 hp kernel: ata2: FAILURE - already active DMA on this > device > > Jun 22 17:09:34 hp kernel: ata2: setting up DMA failed > > Jun 22 17:09:34 hp kernel: ata2: FAILURE - already active DMA on this > device > > Jun 22 17:09:34 hp kernel: ata2: setting up DMA failed > > > > > > After a while the disk gets detached from the pool. Always the same disk. > > Rite now I am in the process of resilvering : > > > > pool: tank > > state: ONLINE > > status: One or more devices is currently being resilvered. The pool will > > continue to function, possibly in a degraded state. > > action: Wait for the resilver to complete. > > scan: resilver in progress since Wed Jun 22 17:09:40 2011 > > 189G scanned out of 578G at 88.8M/s, 1h14m to go > > 62.9G resilvered, 32.63% done > > config: > > > > NAME STATE READ WRITE CKSUM > > tank ONLINE 0 0 0 > > raidz1-0 ONLINE 0 0 0 > > label/zdisk1 ONLINE 0 0 0 > > label/zdisk2 ONLINE 0 0 0 > > label/zdisk3 ONLINE 0 0 0 (resilvering) > > > > But those errors have started to appear again. Again this is the 3rd disk > > replaced !!! Full dmesg attached > > > > -- > > George Kontostanos > > aisecure.net > > > Copyright (c) 1992-2011 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 8.2-STABLE #0: Mon Jun 6 19:00:19 EEST 2011 > > gkontos@hp.aicom.loc:/usr/obj/usr/src/sys/ML110G3 amd64 > > Timecounter "i8254" frequency 1193182 Hz quality 0 > > CPU: Intel(R) Pentium(R) D CPU 3.20GHz (3200.13-MHz K8-class CPU) > > Origin = "GenuineIntel" Id = 0xf64 Family = f Model = 6 Stepping = > 4 > > > Features=0xbfebfbff > > Features2=0xe4bd > > AMD Features=0x20100800 > > AMD Features2=0x1 > > TSC: P-state invariant > > real memory = 4294967296 (4096 MB) > > avail memory = 4106780672 (3916 MB) > > ACPI APIC Table: > > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > > FreeBSD/SMP: 1 package(s) x 2 core(s) > > cpu0 (BSP): APIC ID: 0 > > cpu1 (AP): APIC ID: 1 > > ioapic0: Changing APIC ID to 2 > > ioapic0 irqs 0-23 on motherboard > > kbd1 at kbdmux0 > > acpi0: on motherboard > > acpi0: [ITHREAD] > > acpi0: Power Button (fixed) > > Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 > > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 > > cpu0: on acpi0 > > cpu1: on acpi0 > > pcib0: port 0xcf8-0xcff on acpi0 > > pci0: on pcib0 > > pcib1: irq 16 at device 28.0 on pci0 > > pci1: on pcib1 > > pcib2: irq 17 at device 28.5 on pci0 > > pci7: on pcib2 > > bge0: 0x004101> mem 0xfeaf0000-0xfeafffff irq 17 at device 0.0 on pci7 > > bge0: CHIP ID 0x00004101; ASIC REV 0x04; CHIP REV 0x41; PCI-E > > miibus0: on bge0 > > brgphy0: PHY 1 on miibus0 > > brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, > 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow > > bge0: Ethernet address: 00:13:21:cc:39:35 > > bge0: [ITHREAD] > > uhci0: port 0xdc00-0xdc1f irq > 23 at device 29.0 on pci0 > > uhci0: [ITHREAD] > > uhci0: LegSup = 0x2f00 > > usbus0: on uhci0 > > uhci1: port 0xd880-0xd89f irq > 19 at device 29.1 on pci0 > > uhci1: [ITHREAD] > > uhci1: LegSup = 0x2f00 > > usbus1: on uhci1 > > uhci2: port 0xd800-0xd81f irq > 18 at device 29.2 on pci0 > > uhci2: [ITHREAD] > > uhci2: LegSup = 0x2f00 > > usbus2: on uhci2 > > ehci0: mem > 0xfe9ffc00-0xfe9fffff irq 23 at device 29.7 on pci0 > > ehci0: [ITHREAD] > > usbus3: EHCI version 1.0 > > usbus3: on ehci0 > > pcib3: at device 30.0 on pci0 > > pci8: on pcib3 > > atapci0: port > 0xec00-0xec7f,0xe800-0xe8ff mem 0xfebff000-0xfebfffff,0xfebc0000-0xfebdffff > irq 16 at device 0.0 on pci8 > > atapci0: [ITHREAD] > > atapci0: [ITHREAD] > > ata2: on atapci0 > > ata2: SIGNATURE: 00000101 > > ata2: [ITHREAD] > > ata3: on atapci0 > > ata3: SIGNATURE: 00000101 > > ata3: [ITHREAD] > > ata4: on atapci0 > > ata4: [ITHREAD] > > ata5: on atapci0 > > ata5: SIGNATURE: 00000101 > > ata5: [ITHREAD] > > vgapci0: port 0xe000-0xe0ff mem > 0xe8000000-0xefffffff,0xfebb0000-0xfebbffff irq 16 at device 2.0 on pci8 > > isab0: at device 31.0 on pci0 > > isa0: on isab0 > > atapci1: port > 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf at device 31.1 on pci0 > > ata0: on atapci1 > > ata0: [ITHREAD] > > ahci0: port > 0xd480-0xd487,0xd400-0xd403,0xd080-0xd087,0xd000-0xd003,0xcc00-0xcc0f mem > 0xfe9ff800-0xfe9ffbff irq 19 at device 31.2 on pci0 > > ahci0: [ITHREAD] > > ahci0: AHCI v1.10 with 4 3Gbps ports, Port Multiplier not supported > > ahcich0: at channel 0 on ahci0 > > ahcich0: [ITHREAD] > > ahcich1: at channel 1 on ahci0 > > ahcich1: [ITHREAD] > > ahcich2: at channel 2 on ahci0 > > ahcich2: [ITHREAD] > > ahcich3: at channel 3 on ahci0 > > ahcich3: [ITHREAD] > > acpi_button0: on acpi0 > > atrtc0: port 0x70-0x71 irq 8 on acpi0 > > uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 > > uart0: [FILTER] > > uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 > > uart1: [FILTER] > > ppc0: port 0x378-0x37f,0x778-0x77f irq 7 drq 3 on acpi0 > > ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode > > ppc0: FIFO with 16/16/8 bytes threshold > > ppc0: [ITHREAD] > > ppbus0: on ppc0 > > plip0: on ppbus0 > > plip0: [ITHREAD] > > lpt0: on ppbus0 > > lpt0: [ITHREAD] > > lpt0: Interrupt-driven port > > ppi0: on ppbus0 > > orm0: at iomem > 0xc0000-0xc8fff,0xc9000-0xcdfff,0xcf800-0xd47ff,0xd4800-0xd57ff on isa0 > > sc0: at flags 0x100 on isa0 > > sc0: VGA <16 virtual consoles, flags=0x300> > > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 > > atkbdc0: at port 0x60,0x64 on isa0 > > atkbd0: irq 1 on atkbdc0 > > kbd0 at atkbd0 > > atkbd0: [GIANT-LOCKED] > > atkbd0: [ITHREAD] > > est0: on cpu0 > > est: CPU supports Enhanced Speedstep, but is not recognized. > > est: cpu_vendor GenuineIntel, msr 102400001024 > > device_attach: est0 attach returned 6 > > p4tcc0: on cpu0 > > est1: on cpu1 > > est: CPU supports Enhanced Speedstep, but is not recognized. > > est: cpu_vendor GenuineIntel, msr 102400001024 > > device_attach: est1 attach returned 6 > > p4tcc1: on cpu1 > > ZFS NOTICE: Prefetch is disabled by default if less than 4GB of RAM is > present; > > to enable, add "vfs.zfs.prefetch_disable=0" to > /boot/loader.conf. > > ZFS filesystem version 5 > > ZFS storage pool version 28 > > Timecounters tick every 1.000 msec > > usbus0: 12Mbps Full Speed USB v1.0 > > usbus1: 12Mbps Full Speed USB v1.0 > > usbus2: 12Mbps Full Speed USB v1.0 > > usbus3: 480Mbps High Speed USB v2.0 > > ugen0.1: at usbus0 > > uhub0: on usbus0 > > ugen1.1: at usbus1 > > uhub1: on usbus1 > > ugen2.1: at usbus2 > > uhub2: on usbus2 > > ugen3.1: at usbus3 > > uhub3: on usbus3 > > ad4: 715404MB at ata2-master UDMA100 > SATA 3Gb/s > > ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 > > ada0: ATA-7 SATA 1.x device > > ada0: 150.000MB/s transfers (SATA 1.x, UDMA6, PIO 8192bytes) > > ada0: Command Queueing enabled > > ada0: 238475MB (488397168 512 byte sectors: 16H 63S/T 16383C) > > ada1 at ahcich1 bus 0 scbus1 target 0 lun 0 > > ada1: ATA-7 SATA 1.x device > > ada1: 150.000MB/s transfers (SATA 1.x, UDMA6, PIO 8192bytes) > > ada1: Command Queueing enabled > > ada1: 238475MB (488397168 512 byte sectors: 16H 63S/T 16383C)ad6: > 610480MB at ata3-master UDMA100 SATA 3Gb/s > > > > ad10: 610480MB at ata5-master UDMA100 > SATA 3Gb/s > > SMP: AP CPU #1 Launched! > > Root mount waiting for: usbus3 usbus2 usbus1 usbus0 > > uhub0: 2 ports with 2 removable, self powered > > uhub1: 2 ports with 2 removable, self powered > > uhub2: 2 ports with 2 removable, self powered > > Root mount waiting for: usbus3 > > uhub3: 6 ports with 6 removable, self powered > > Root mount waiting for: usbus3 > > ugen3.2: at usbus3 > > umass0: on > usbus3 > > umass0: SCSI over Bulk-Only; quirks = 0x0000 > > ugen0.2: at usbus0 > > umass0:4:0:-1: Attached to scbus4 > > Trying to mount root from zfs:zroot > > da0 at umass-sim0 bus 0 scbus4 target 0 lun 0 > > da0: Fixed Direct Access SCSI-4 device > > da0: 40.000MB/s transfers > > da0: 610480MB (1250263726 512 byte sectors: 255H 63S/T 77825C) > > bge0: link state changed to UP > > S > > log_sysevent: type 19 is not implemented > > ata2: SIGNATURE: ffffffff > > ata2: timeout waiting to issue command > > ata2: error issuing SETFEATURES SET TRANSFER MODE command > > ata2: timeout waiting to issue command > > ata2: error issuing SETFEATURES ENABLE RCACHE command > > ata2: timeout waiting to issue command > > ata2: error issuing SETFEATURES ENABLE WCACHE command > > ad4: WARNING - SET_MULTI taskqueue timeout - completing request directly > > ad4: WARNING - WRITE_DMA48 requeued due to channel reset LBA=321558741 > > ata2: SIGNATURE: 00000101 > > ad4: WARNING - WRITE_DMA48 requeued due to channel reset LBA=321558869 > > ata2: FAILURE - already active DMA on this device > > ata2: setting up DMA failed > > ata2: FAILURE - already active DMA on this device > > ata2: setting up DMA failed > > George, > > Can you please install ports/sysutils/smartmontools (should be version > 5.41; if you have an older version please upgrade) and provide output > from the following comman > > smartctl -a /dev/ad4 > > With this I should be able to rule out weird disk problems. It's always > good to start there. > > For those unable to parse the above topology, the system has two SATA > controllers (the Promise uses ata(4), while the on-board ICH7 is in AHCI > mode and is using ahci.ko (AHCI-to-CAM)): > > atapci0 = Promise PDC40718 (Promise SATA300 TX4) > --> ata2-master = ad4 = WDC WD7500AALX-009BA0 > --> ata2-slave = > --> ata3-master = ad6 = WDC WD6401AALS-00J7B1 > --> ata3-slave = > --> ata4-master = > --> ata4-slave = > --> ata5-master = ad10 = WDC WD6401AALS-00J7B1 > --> ata5-slave = > > ahci0 = Intel ICH7 on-board in AHCI mode > --> ahcich0 = ada0 = ST3250410AS 3.AAA > --> ahcich1 = ada1 = ST3250410AS 3.AAA > --> ahcich2 = > --> ahcich3 = > > If you can't get this situation solved, I'd recommend spending $40 > (pocket change) to invest in a Silicon Image 3124 card. Your existing > Promise controller is a PCI card (not PCIe or PCI-X), and I don't know > if your motherboard has any PCIe or PCI-X slots, so I'm going to assume > the 133MByte/sec limitation is acceptable to you. As such, that limits > you to effectively this card: > > http://www.newegg.com/Product/Product.aspx?Item=N82E16816132017 > > You do not have to use the RAID functionality of the card. FreeBSD > supports this card using siis(4) and it does utilise CAM, so your disks > would show up as adaX. The driver is actively supported/maintained. > > Avoid looking at cards which use the 3112, 3114, or 3512 chips. > > Hope this helps, or at least directs you in a path that lets you solve > the problem through a little bit of money. > > -- > | Jeremy Chadwick jdc at parodius.com | > | Parodius Networking http://www.parodius.com/ | > | UNIX Systems Administrator Mountain View, CA, US | > | Making life hard for others since 1977. PGP 4BD6C0CB | > > -- George Kontostanos aisecure.net From owner-freebsd-stable@FreeBSD.ORG Thu Jun 23 12:33:29 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (unknown [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C2C791065672 for ; Thu, 23 Jun 2011 12:33:29 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [76.96.30.16]) by mx1.freebsd.org (Postfix) with ESMTP id AA2638FC1B for ; Thu, 23 Jun 2011 12:33:29 +0000 (UTC) Received: from omta20.emeryville.ca.mail.comcast.net ([76.96.30.87]) by qmta01.emeryville.ca.mail.comcast.net with comcast id zQXq1g0011smiN4A1QZTa6; Thu, 23 Jun 2011 12:33:27 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta20.emeryville.ca.mail.comcast.net with comcast id zQaN1g00W1t3BNj8gQaPV0; Thu, 23 Jun 2011 12:34:23 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 00212102C36; Thu, 23 Jun 2011 05:33:27 -0700 (PDT) Date: Thu, 23 Jun 2011 05:33:27 -0700 From: Jeremy Chadwick To: George Kontostanos Message-ID: <20110623123327.GA6500@icarus.home.lan> References: <20110623005832.GA26118@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: FreeBSD Stable Subject: Re: ata: SIGNATURE: ffffffff X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2011 12:33:29 -0000 On Thu, Jun 23, 2011 at 02:57:32PM +0300, George Kontostanos wrote: > Hi Jeremy, > > I am using the smartmon tools and in fact the first drive I replaced did > show some errors. Next two of them were zeroed out and thoroughly tested > using WD tools. No errors were reported either by smartmon nor by WD tools. > I was also glad when the shop I bought them replaced them immediately, no > questions asked. They said that they were having a lot of issues with WD > drives lately. > > I will probably try to get a different brand controller especially after > seeing the relevant PR > > Thanks, > > hp# smartctl -a /dev/ad4 > smartctl 5.41 2011-06-09 r3365 [FreeBSD 8.2-STABLE amd64] (local build) > Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net > > === START OF INFORMATION SECTION === > Model Family: Western Digital Caviar Blue Serial ATA > Device Model: WDC WD7500AALX-009BA0 > Serial Number: WD-WCATR5711398 > LU WWN Device Id: 5 0014ee 25ad8ccf5 > Firmware Version: 15.01H15 > User Capacity: 750,156,374,016 bytes [750 GB] > Sector Size: 512 bytes logical/physical > Device is: In smartctl database [for details use: -P show] > ATA Version is: 8 > ATA Standard is: Exact ATA specification draft version not indicated > Local Time is: Thu Jun 23 14:46:12 2011 EEST > SMART support is: Available - device has SMART capability. > SMART support is: Enabled > > === START OF READ SMART DATA SECTION === > SMART overall-health self-assessment test result: PASSED > > General SMART Values: > Offline data collection status: (0x82) Offline data collection activity > was completed without error. > Auto Offline Data Collection: Enabled. > Self-test execution status: ( 0) The previous self-test routine > completed > without error or no self-test has ever > been run. > Total time to complete Offline > data collection: (13260) seconds. > Offline data collection > capabilities: (0x7b) SMART execute Offline immediate. > Auto Offline data collection on/off support. > Suspend Offline collection upon new > command. > Offline surface scan supported. > Self-test supported. > Conveyance Self-test supported. > Selective Self-test supported. > SMART capabilities: (0x0003) Saves SMART data before entering > power-saving mode. > Supports SMART auto save timer. > Error logging capability: (0x01) Error logging supported. > General Purpose Logging supported. > Short self-test routine > recommended polling time: ( 2) minutes. > Extended self-test routine > recommended polling time: ( 155) minutes. > Conveyance self-test routine > recommended polling time: ( 5) minutes. > SCT capabilities: (0x3037) SCT Status supported. > SCT Feature Control supported. > SCT Data Table supported. > > SMART Attributes Data Structure revision number: 16 > Vendor Specific SMART Attributes with Thresholds: > ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED > WHEN_FAILED RAW_VALUE > 1 Raw_Read_Error_Rate 0x002f 200 200 051 Pre-fail > Always - 0 > 3 Spin_Up_Time 0x0027 188 178 021 Pre-fail > Always - 3558 > 4 Start_Stop_Count 0x0032 100 100 000 Old_age > Always - 10 > 5 Reallocated_Sector_Ct 0x0033 200 200 140 Pre-fail > Always - 0 > 7 Seek_Error_Rate 0x002e 200 200 000 Old_age > Always - 0 > 9 Power_On_Hours 0x0032 100 100 000 Old_age > Always - 21 > 10 Spin_Retry_Count 0x0032 100 253 000 Old_age > Always - 0 > 11 Calibration_Retry_Count 0x0032 100 253 000 Old_age > Always - 0 > 12 Power_Cycle_Count 0x0032 100 100 000 Old_age > Always - 8 > 192 Power-Off_Retract_Count 0x0032 200 200 000 Old_age > Always - 7 > 193 Load_Cycle_Count 0x0032 200 200 000 Old_age > Always - 2 > 194 Temperature_Celsius 0x0022 110 107 000 Old_age > Always - 37 > 196 Reallocated_Event_Count 0x0032 200 200 000 Old_age > Always - 0 > 197 Current_Pending_Sector 0x0032 200 200 000 Old_age > Always - 0 > 198 Offline_Uncorrectable 0x0030 200 200 000 Old_age > Offline - 0 > 199 UDMA_CRC_Error_Count 0x0032 200 200 000 Old_age > Always - 0 > 200 Multi_Zone_Error_Rate 0x0008 200 200 000 Old_age > Offline - 0 > > SMART Error Log Version: 1 > No Errors Logged > > SMART Self-test log structure revision number 1 > No self-tests have been logged. [To run self-tests, use: smartctl -t] > > > SMART Selective self-test log data structure revision number 1 > SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS > 1 0 0 Not_testing > 2 0 0 Not_testing > 3 0 0 Not_testing > 4 0 0 Not_testing > 5 0 0 Not_testing > Selective self-test flags (0x0): > After scanning selected spans, do NOT read-scan remainder of disk. > If Selective self-test is pending on power-up, resume after 0 minute delay. > > > On Thu, Jun 23, 2011 at 3:58 AM, Jeremy Chadwick > wrote: > > > On Wed, Jun 22, 2011 at 05:52:39PM +0300, George Kontostanos wrote: > > > This is the 3rd disk I replace in 3 disk- Raiz1 pool and I really start > > to > > > believe that the problem is somewhere else. The disks reside in a Promise > > > PDC40718 SATA300 controller. I am running this set up since 8.0-Release > > with > > > no issues till a few months ago after 8.2-Release now at 8.2-Stable. > > > Symptoms: > > > > > > Jun 22 17:08:53 hp kernel: ata2: timeout waiting to issue command > > > Jun 22 17:08:53 hp kernel: ata2: error issuing SETFEATURES ENABLE WCACHE > > > command > > > Jun 22 17:09:33 hp kernel: ad4: WARNING - SET_MULTI taskqueue timeout - > > > completing request directly > > > Jun 22 17:09:33 hp kernel: ad4: WARNING - WRITE_DMA48 requeued due to > > > channel reset LBA=321558741 > > > Jun 22 17:09:34 hp kernel: ata2: SIGNATURE: 00000101 > > > Jun 22 17:09:34 hp kernel: ad4: WARNING - WRITE_DMA48 requeued due to > > > channel reset LBA=321558869 > > > Jun 22 17:09:34 hp kernel: ata2: FAILURE - already active DMA on this > > device > > > Jun 22 17:09:34 hp kernel: ata2: setting up DMA failed > > > Jun 22 17:09:34 hp kernel: ata2: FAILURE - already active DMA on this > > device > > > Jun 22 17:09:34 hp kernel: ata2: setting up DMA failed > > > > > > > > > After a while the disk gets detached from the pool. Always the same disk. > > > Rite now I am in the process of resilvering : > > > > > > pool: tank > > > state: ONLINE > > > status: One or more devices is currently being resilvered. The pool will > > > continue to function, possibly in a degraded state. > > > action: Wait for the resilver to complete. > > > scan: resilver in progress since Wed Jun 22 17:09:40 2011 > > > 189G scanned out of 578G at 88.8M/s, 1h14m to go > > > 62.9G resilvered, 32.63% done > > > config: > > > > > > NAME STATE READ WRITE CKSUM > > > tank ONLINE 0 0 0 > > > raidz1-0 ONLINE 0 0 0 > > > label/zdisk1 ONLINE 0 0 0 > > > label/zdisk2 ONLINE 0 0 0 > > > label/zdisk3 ONLINE 0 0 0 (resilvering) > > > > > > But those errors have started to appear again. Again this is the 3rd disk > > > replaced !!! Full dmesg attached > > > > > > -- > > > George Kontostanos > > > aisecure.net > > > > > Copyright (c) 1992-2011 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 8.2-STABLE #0: Mon Jun 6 19:00:19 EEST 2011 > > > gkontos@hp.aicom.loc:/usr/obj/usr/src/sys/ML110G3 amd64 > > > Timecounter "i8254" frequency 1193182 Hz quality 0 > > > CPU: Intel(R) Pentium(R) D CPU 3.20GHz (3200.13-MHz K8-class CPU) > > > Origin = "GenuineIntel" Id = 0xf64 Family = f Model = 6 Stepping = > > 4 > > > > > Features=0xbfebfbff > > > Features2=0xe4bd > > > AMD Features=0x20100800 > > > AMD Features2=0x1 > > > TSC: P-state invariant > > > real memory = 4294967296 (4096 MB) > > > avail memory = 4106780672 (3916 MB) > > > ACPI APIC Table: > > > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > > > FreeBSD/SMP: 1 package(s) x 2 core(s) > > > cpu0 (BSP): APIC ID: 0 > > > cpu1 (AP): APIC ID: 1 > > > ioapic0: Changing APIC ID to 2 > > > ioapic0 irqs 0-23 on motherboard > > > kbd1 at kbdmux0 > > > acpi0: on motherboard > > > acpi0: [ITHREAD] > > > acpi0: Power Button (fixed) > > > Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 > > > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 > > > cpu0: on acpi0 > > > cpu1: on acpi0 > > > pcib0: port 0xcf8-0xcff on acpi0 > > > pci0: on pcib0 > > > pcib1: irq 16 at device 28.0 on pci0 > > > pci1: on pcib1 > > > pcib2: irq 17 at device 28.5 on pci0 > > > pci7: on pcib2 > > > bge0: > 0x004101> mem 0xfeaf0000-0xfeafffff irq 17 at device 0.0 on pci7 > > > bge0: CHIP ID 0x00004101; ASIC REV 0x04; CHIP REV 0x41; PCI-E > > > miibus0: on bge0 > > > brgphy0: PHY 1 on miibus0 > > > brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, > > 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow > > > bge0: Ethernet address: 00:13:21:cc:39:35 > > > bge0: [ITHREAD] > > > uhci0: port 0xdc00-0xdc1f irq > > 23 at device 29.0 on pci0 > > > uhci0: [ITHREAD] > > > uhci0: LegSup = 0x2f00 > > > usbus0: on uhci0 > > > uhci1: port 0xd880-0xd89f irq > > 19 at device 29.1 on pci0 > > > uhci1: [ITHREAD] > > > uhci1: LegSup = 0x2f00 > > > usbus1: on uhci1 > > > uhci2: port 0xd800-0xd81f irq > > 18 at device 29.2 on pci0 > > > uhci2: [ITHREAD] > > > uhci2: LegSup = 0x2f00 > > > usbus2: on uhci2 > > > ehci0: mem > > 0xfe9ffc00-0xfe9fffff irq 23 at device 29.7 on pci0 > > > ehci0: [ITHREAD] > > > usbus3: EHCI version 1.0 > > > usbus3: on ehci0 > > > pcib3: at device 30.0 on pci0 > > > pci8: on pcib3 > > > atapci0: port > > 0xec00-0xec7f,0xe800-0xe8ff mem 0xfebff000-0xfebfffff,0xfebc0000-0xfebdffff > > irq 16 at device 0.0 on pci8 > > > atapci0: [ITHREAD] > > > atapci0: [ITHREAD] > > > ata2: on atapci0 > > > ata2: SIGNATURE: 00000101 > > > ata2: [ITHREAD] > > > ata3: on atapci0 > > > ata3: SIGNATURE: 00000101 > > > ata3: [ITHREAD] > > > ata4: on atapci0 > > > ata4: [ITHREAD] > > > ata5: on atapci0 > > > ata5: SIGNATURE: 00000101 > > > ata5: [ITHREAD] > > > vgapci0: port 0xe000-0xe0ff mem > > 0xe8000000-0xefffffff,0xfebb0000-0xfebbffff irq 16 at device 2.0 on pci8 > > > isab0: at device 31.0 on pci0 > > > isa0: on isab0 > > > atapci1: port > > 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf at device 31.1 on pci0 > > > ata0: on atapci1 > > > ata0: [ITHREAD] > > > ahci0: port > > 0xd480-0xd487,0xd400-0xd403,0xd080-0xd087,0xd000-0xd003,0xcc00-0xcc0f mem > > 0xfe9ff800-0xfe9ffbff irq 19 at device 31.2 on pci0 > > > ahci0: [ITHREAD] > > > ahci0: AHCI v1.10 with 4 3Gbps ports, Port Multiplier not supported > > > ahcich0: at channel 0 on ahci0 > > > ahcich0: [ITHREAD] > > > ahcich1: at channel 1 on ahci0 > > > ahcich1: [ITHREAD] > > > ahcich2: at channel 2 on ahci0 > > > ahcich2: [ITHREAD] > > > ahcich3: at channel 3 on ahci0 > > > ahcich3: [ITHREAD] > > > acpi_button0: on acpi0 > > > atrtc0: port 0x70-0x71 irq 8 on acpi0 > > > uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 > > > uart0: [FILTER] > > > uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 > > > uart1: [FILTER] > > > ppc0: port 0x378-0x37f,0x778-0x77f irq 7 drq 3 on acpi0 > > > ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode > > > ppc0: FIFO with 16/16/8 bytes threshold > > > ppc0: [ITHREAD] > > > ppbus0: on ppc0 > > > plip0: on ppbus0 > > > plip0: [ITHREAD] > > > lpt0: on ppbus0 > > > lpt0: [ITHREAD] > > > lpt0: Interrupt-driven port > > > ppi0: on ppbus0 > > > orm0: at iomem > > 0xc0000-0xc8fff,0xc9000-0xcdfff,0xcf800-0xd47ff,0xd4800-0xd57ff on isa0 > > > sc0: at flags 0x100 on isa0 > > > sc0: VGA <16 virtual consoles, flags=0x300> > > > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 > > > atkbdc0: at port 0x60,0x64 on isa0 > > > atkbd0: irq 1 on atkbdc0 > > > kbd0 at atkbd0 > > > atkbd0: [GIANT-LOCKED] > > > atkbd0: [ITHREAD] > > > est0: on cpu0 > > > est: CPU supports Enhanced Speedstep, but is not recognized. > > > est: cpu_vendor GenuineIntel, msr 102400001024 > > > device_attach: est0 attach returned 6 > > > p4tcc0: on cpu0 > > > est1: on cpu1 > > > est: CPU supports Enhanced Speedstep, but is not recognized. > > > est: cpu_vendor GenuineIntel, msr 102400001024 > > > device_attach: est1 attach returned 6 > > > p4tcc1: on cpu1 > > > ZFS NOTICE: Prefetch is disabled by default if less than 4GB of RAM is > > present; > > > to enable, add "vfs.zfs.prefetch_disable=0" to > > /boot/loader.conf. > > > ZFS filesystem version 5 > > > ZFS storage pool version 28 > > > Timecounters tick every 1.000 msec > > > usbus0: 12Mbps Full Speed USB v1.0 > > > usbus1: 12Mbps Full Speed USB v1.0 > > > usbus2: 12Mbps Full Speed USB v1.0 > > > usbus3: 480Mbps High Speed USB v2.0 > > > ugen0.1: at usbus0 > > > uhub0: on usbus0 > > > ugen1.1: at usbus1 > > > uhub1: on usbus1 > > > ugen2.1: at usbus2 > > > uhub2: on usbus2 > > > ugen3.1: at usbus3 > > > uhub3: on usbus3 > > > ad4: 715404MB at ata2-master UDMA100 > > SATA 3Gb/s > > > ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 > > > ada0: ATA-7 SATA 1.x device > > > ada0: 150.000MB/s transfers (SATA 1.x, UDMA6, PIO 8192bytes) > > > ada0: Command Queueing enabled > > > ada0: 238475MB (488397168 512 byte sectors: 16H 63S/T 16383C) > > > ada1 at ahcich1 bus 0 scbus1 target 0 lun 0 > > > ada1: ATA-7 SATA 1.x device > > > ada1: 150.000MB/s transfers (SATA 1.x, UDMA6, PIO 8192bytes) > > > ada1: Command Queueing enabled > > > ada1: 238475MB (488397168 512 byte sectors: 16H 63S/T 16383C)ad6: > > 610480MB at ata3-master UDMA100 SATA 3Gb/s > > > > > > ad10: 610480MB at ata5-master UDMA100 > > SATA 3Gb/s > > > SMP: AP CPU #1 Launched! > > > Root mount waiting for: usbus3 usbus2 usbus1 usbus0 > > > uhub0: 2 ports with 2 removable, self powered > > > uhub1: 2 ports with 2 removable, self powered > > > uhub2: 2 ports with 2 removable, self powered > > > Root mount waiting for: usbus3 > > > uhub3: 6 ports with 6 removable, self powered > > > Root mount waiting for: usbus3 > > > ugen3.2: at usbus3 > > > umass0: on > > usbus3 > > > umass0: SCSI over Bulk-Only; quirks = 0x0000 > > > ugen0.2: at usbus0 > > > umass0:4:0:-1: Attached to scbus4 > > > Trying to mount root from zfs:zroot > > > da0 at umass-sim0 bus 0 scbus4 target 0 lun 0 > > > da0: Fixed Direct Access SCSI-4 device > > > da0: 40.000MB/s transfers > > > da0: 610480MB (1250263726 512 byte sectors: 255H 63S/T 77825C) > > > bge0: link state changed to UP > > > S > > > log_sysevent: type 19 is not implemented > > > ata2: SIGNATURE: ffffffff > > > ata2: timeout waiting to issue command > > > ata2: error issuing SETFEATURES SET TRANSFER MODE command > > > ata2: timeout waiting to issue command > > > ata2: error issuing SETFEATURES ENABLE RCACHE command > > > ata2: timeout waiting to issue command > > > ata2: error issuing SETFEATURES ENABLE WCACHE command > > > ad4: WARNING - SET_MULTI taskqueue timeout - completing request directly > > > ad4: WARNING - WRITE_DMA48 requeued due to channel reset LBA=321558741 > > > ata2: SIGNATURE: 00000101 > > > ad4: WARNING - WRITE_DMA48 requeued due to channel reset LBA=321558869 > > > ata2: FAILURE - already active DMA on this device > > > ata2: setting up DMA failed > > > ata2: FAILURE - already active DMA on this device > > > ata2: setting up DMA failed > > > > George, > > > > Can you please install ports/sysutils/smartmontools (should be version > > 5.41; if you have an older version please upgrade) and provide output > > from the following comman > > > > smartctl -a /dev/ad4 > > > > With this I should be able to rule out weird disk problems. It's always > > good to start there. > > > > For those unable to parse the above topology, the system has two SATA > > controllers (the Promise uses ata(4), while the on-board ICH7 is in AHCI > > mode and is using ahci.ko (AHCI-to-CAM)): > > > > atapci0 = Promise PDC40718 (Promise SATA300 TX4) > > --> ata2-master = ad4 = WDC WD7500AALX-009BA0 > > --> ata2-slave = > > --> ata3-master = ad6 = WDC WD6401AALS-00J7B1 > > --> ata3-slave = > > --> ata4-master = > > --> ata4-slave = > > --> ata5-master = ad10 = WDC WD6401AALS-00J7B1 > > --> ata5-slave = > > > > ahci0 = Intel ICH7 on-board in AHCI mode > > --> ahcich0 = ada0 = ST3250410AS 3.AAA > > --> ahcich1 = ada1 = ST3250410AS 3.AAA > > --> ahcich2 = > > --> ahcich3 = > > > > If you can't get this situation solved, I'd recommend spending $40 > > (pocket change) to invest in a Silicon Image 3124 card. Your existing > > Promise controller is a PCI card (not PCIe or PCI-X), and I don't know > > if your motherboard has any PCIe or PCI-X slots, so I'm going to assume > > the 133MByte/sec limitation is acceptable to you. As such, that limits > > you to effectively this card: > > > > http://www.newegg.com/Product/Product.aspx?Item=N82E16816132017 > > > > You do not have to use the RAID functionality of the card. FreeBSD > > supports this card using siis(4) and it does utilise CAM, so your disks > > would show up as adaX. The driver is actively supported/maintained. > > > > Avoid looking at cards which use the 3112, 3114, or 3512 chips. > > > > Hope this helps, or at least directs you in a path that lets you solve > > the problem through a little bit of money. Yup, the /dev/ad4 drive looks perfect. I can see it was just recently put into use. :-) Issue is with the system, the controller, (a remote possibility given the situation) the PSU, or the driver for the controller. Sorry I can't be of more help past this point, but we've at least mostly ruled out the possibility of the disk itself being problematic. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Thu Jun 23 13:04:17 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (unknown [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ECEB2106566B for ; Thu, 23 Jun 2011 13:04:17 +0000 (UTC) (envelope-from kb@cccmz.de) Received: from deimos.mail.cccmz.de (mail.cccmz.de [141.70.124.194]) by mx1.freebsd.org (Postfix) with ESMTP id 258388FC1F for ; Thu, 23 Jun 2011 13:04:17 +0000 (UTC) Received: from localhost (deimos [127.0.0.1]) by deimos.mail.cccmz.de (Postfix) with ESMTP id 8237D164079 for ; Thu, 23 Jun 2011 14:47:11 +0200 (CEST) Received: from deimos.mail.cccmz.de ([127.0.0.1]) by localhost (cccmz.de [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 09379-03 for ; Thu, 23 Jun 2011 14:47:11 +0200 (CEST) Received: from jf.bluem00n.gotdns.org (p5481EA38.dip.t-dialin.net [84.129.234.56]) by deimos.mail.cccmz.de (Postfix) with ESMTPSA id B8D47164052 for ; Thu, 23 Jun 2011 14:47:10 +0200 (CEST) Date: Thu, 23 Jun 2011 14:47:00 +0200 From: Sebastian Anding To: FreeBSD Stable Message-ID: <20110623144700.7679a699@jf.bluem00n.gotdns.org> X-Mailer: Claws Mail 3.7.8 (GTK+ 2.22.1; i386-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="MP_/1GIg4dXInacqQ=19ckUgsV7" Subject: 8 Stable won't boot into zfs with underlying geli layer amd64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2011 13:04:18 -0000 --MP_/1GIg4dXInacqQ=19ckUgsV7 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, i tried to switch to 8.0 stable. I checkout the src-all with cvsup 3 days ago. After make buildworld, make buildkernel and make installkernel, I booted into the new system. But now I'm not asked for the geli passphrases. That results in the kernel not beeing able to mount the root vfs. The keyboard (USB) is not responding anymore and so I'm not able to set parameters after the root fs went missing, or produce a dmesg. I guess that the discs are not detected anymore. My setup can be seen in the attached files. There are one freebsd-swap and one freebsd-zfs gpart partition on each disc. The gpart partitions freebsd-zfs are encrypted with geli. I attach the dmesg of the Generic 8.2 release kernel too. Has there been changes, which can result in behaviour described above? So far, Sebastian --MP_/1GIg4dXInacqQ=19ckUgsV7 Content-Type: application/octet-stream; name=gpart.amd64 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=gpart.amd64 PT4gICAgICAgIDM0ICAzOTA3MDI5MTAxICBhZDQgIEdQVCAgKDEuOFQpCiAgICAgICAgICAzNCAg ICAgMjA0ODAzNCAgICAxICBmcmVlYnNkLXN3YXAgICgxLjBHKQogICAgIDIwNDgwNjggIDM5MDQ5 ODEwNjcgICAgMiAgZnJlZWJzZC16ZnMgICgxLjhUKQoKPT4gICAgICAgIDM0ICAzOTA3MDI5MTAx ICBhZDUgIEdQVCAgKDEuOFQpCiAgICAgICAgICAzNCAgICAgMjA0ODAzNCAgICAxICBmcmVlYnNk LXN3YXAgICgxLjBHKQogICAgIDIwNDgwNjggIDM5MDQ5ODEwNjcgICAgMiAgZnJlZWJzZC16ZnMg ICgxLjhUKQoKPT4gICAgICAgIDM0ICAzOTA3MDI5MTAxICBhZDYgIEdQVCAgKDEuOFQpCiAgICAg ICAgICAzNCAgICAgMjA0ODAzNCAgICAxICBmcmVlYnNkLXN3YXAgICgxLjBHKQogICAgIDIwNDgw NjggIDM5MDQ5ODEwNjcgICAgMiAgZnJlZWJzZC16ZnMgICgxLjhUKQoKPT4gICAgICAzNCAgMTU2 NDY2NTMgIGRhMCAgR1BUICAoNy41RykKICAgICAgICAzNCAgICAgICAgMzIgICAgMSAgZnJlZWJz ZC1ib290ICAoMTZLKQogICAgICAgIDY2ICAxNTY0NjYyMSAgICAyICBmcmVlYnNkLXVmcyAgKDcu NUcpCgo9PiAgICAgICAgMzQgIDM5MDcwMjkxMDEgIGFkNyAgR1BUICAoMS44VCkKICAgICAgICAg IDM0ICAgICAyMDQ4MDM0ICAgIDEgIGZyZWVic2Qtc3dhcCAgKDEuMEcpCiAgICAgMjA0ODA2OCAg MzkwNDk4MTA2NyAgICAyICBmcmVlYnNkLXpmcyAgKDEuOFQpCgo= --MP_/1GIg4dXInacqQ=19ckUgsV7 Content-Type: application/octet-stream; name=dmesg.amd64 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=dmesg.amd64 Q29weXJpZ2h0IChjKSAxOTkyLTIwMTEgVGhlIEZyZWVCU0QgUHJvamVjdC4KQ29weXJpZ2h0IChj KSAxOTc5LCAxOTgwLCAxOTgzLCAxOTg2LCAxOTg4LCAxOTg5LCAxOTkxLCAxOTkyLCAxOTkzLCAx OTk0CglUaGUgUmVnZW50cyBvZiB0aGUgVW5pdmVyc2l0eSBvZiBDYWxpZm9ybmlhLiBBbGwgcmln aHRzIHJlc2VydmVkLgpGcmVlQlNEIGlzIGEgcmVnaXN0ZXJlZCB0cmFkZW1hcmsgb2YgVGhlIEZy ZWVCU0QgRm91bmRhdGlvbi4KRnJlZUJTRCA4LjItUkVMRUFTRSAjMDogVGh1IEZlYiAxNyAwMjo0 MTo1MSBVVEMgMjAxMQogICAgcm9vdEBtYXNvbi5jc2UuYnVmZmFsby5lZHU6L3Vzci9vYmovdXNy L3NyYy9zeXMvR0VORVJJQyBhbWQ2NApUaW1lY291bnRlciAiaTgyNTQiIGZyZXF1ZW5jeSAxMTkz MTgyIEh6IHF1YWxpdHkgMApDUFU6IEludGVsKFIpIFBlbnRpdW0oUikgNCBDUFUgMi44MEdIeiAo Mjc5My4wOS1NSHogSzgtY2xhc3MgQ1BVKQogIE9yaWdpbiA9ICJHZW51aW5lSW50ZWwiICBJZCA9 IDB4ZjQxICBGYW1pbHkgPSBmICBNb2RlbCA9IDQgIFN0ZXBwaW5nID0gMQogIEZlYXR1cmVzPTB4 YmZlYmZiZmY8RlBVLFZNRSxERSxQU0UsVFNDLE1TUixQQUUsTUNFLENYOCxBUElDLFNFUCxNVFJS LFBHRSxNQ0EsQ01PVixQQVQsUFNFMzYsQ0xGTFVTSCxEVFMsQUNQSSxNTVgsRlhTUixTU0UsU1NF MixTUyxIVFQsVE0sUEJFPgogIEZlYXR1cmVzMj0weDY0MWQ8U1NFMyxEVEVTNjQsTU9OLERTX0NQ TCxDTlhULUlELENYMTYseFRQUj4KICBBTUQgRmVhdHVyZXM9MHgyMDEwMDgwMDxTWVNDQUxMLE5Y LExNPgogIFRTQzogUC1zdGF0ZSBpbnZhcmlhbnQKcmVhbCBtZW1vcnkgID0gNDI5NDk2NzI5NiAo NDA5NiBNQikKYXZhaWwgbWVtb3J5ID0gMzg2MTcxMjg5NiAoMzY4MiBNQikKQUNQSSBBUElDIFRh YmxlOiA8REVMTCAgIFBFU0M0MzA+CkZyZWVCU0QvU01QOiBNdWx0aXByb2Nlc3NvciBTeXN0ZW0g RGV0ZWN0ZWQ6IDIgQ1BVcwpGcmVlQlNEL1NNUDogMSBwYWNrYWdlKHMpIHggMSBjb3JlKHMpIHgg MiBIVFQgdGhyZWFkcwogY3B1MCAoQlNQKTogQVBJQyBJRDogIDAKIGNwdTEgKEFQL0hUKTogQVBJ QyBJRDogIDEKaW9hcGljMDogQ2hhbmdpbmcgQVBJQyBJRCB0byA4CmlvYXBpYzAgPFZlcnNpb24g Mi4wPiBpcnFzIDAtMjMgb24gbW90aGVyYm9hcmQKbGFwaWMwOiBGb3JjaW5nIExJTlQxIHRvIGVk Z2UgdHJpZ2dlcgprYmQxIGF0IGtiZG11eDAKY3J5cHRvc29mdDA6IDxzb2Z0d2FyZSBjcnlwdG8+ IG9uIG1vdGhlcmJvYXJkCmFjcGkwOiA8REVMTCBQRVNDNDMwPiBvbiBtb3RoZXJib2FyZAphY3Bp MDogW0lUSFJFQURdCmFjcGkwOiBQb3dlciBCdXR0b24gKGZpeGVkKQphY3BpMDogcmVzZXJ2YXRp b24gb2YgMCwgYTAwMDAgKDMpIGZhaWxlZAphY3BpMDogcmVzZXJ2YXRpb24gb2YgMTAwMDAwLCBm MDAwMDAgKDMpIGZhaWxlZAphY3BpMDogcmVzZXJ2YXRpb24gb2YgMTAwMDAwMCwgZWVlOGNjMDAg KDMpIGZhaWxlZApUaW1lY291bnRlciAiQUNQSS1mYXN0IiBmcmVxdWVuY3kgMzU3OTU0NSBIeiBx dWFsaXR5IDEwMDAKYWNwaV90aW1lcjA6IDwyNC1iaXQgdGltZXIgYXQgMy41Nzk1NDVNSHo+IHBv cnQgMHg4MDgtMHg4MGIgb24gYWNwaTAKY3B1MDogPEFDUEkgQ1BVPiBvbiBhY3BpMApjcHUxOiA8 QUNQSSBDUFU+IG9uIGFjcGkwCmFjcGlfaHBldDA6IDxIaWdoIFByZWNpc2lvbiBFdmVudCBUaW1l cj4gaW9tZW0gMHhmZWQwMDAwMC0weGZlZDAwM2ZmIG9uIGFjcGkwClRpbWVjb3VudGVyICJIUEVU IiBmcmVxdWVuY3kgMTQzMTgxODAgSHogcXVhbGl0eSA5MDAKYWNwaV9idXR0b24wOiA8UG93ZXIg QnV0dG9uPiBvbiBhY3BpMApwY2liMDogPEFDUEkgSG9zdC1QQ0kgYnJpZGdlPiBwb3J0IDB4Y2Y4 LTB4Y2ZmIG9uIGFjcGkwCnBjaTA6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWIwCnBjaWIxOiA8QUNQ SSBQQ0ktUENJIGJyaWRnZT4gaXJxIDE2IGF0IGRldmljZSAxLjAgb24gcGNpMApwY2kxOiA8QUNQ SSBQQ0kgYnVzPiBvbiBwY2liMQpwY2liMjogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGlycSAxNiBh dCBkZXZpY2UgMjguMCBvbiBwY2kwCnBjaTI6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWIyCnBjaWIz OiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4gaXJxIDE2IGF0IGRldmljZSAyOC40IG9uIHBjaTAKcGNp MzogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjMKcGNpYjQ6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBp cnEgMTcgYXQgZGV2aWNlIDI4LjUgb24gcGNpMApwY2k0OiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2li NApiZ2UwOiA8QnJvYWRjb20gTmV0WHRyZW1lIEdpZ2FiaXQgRXRoZXJuZXQgQ29udHJvbGxlciwg QVNJQyByZXYuIDB4MDA0MDAxPiBtZW0gMHhmZThmMDAwMC0weGZlOGZmZmZmIGlycSAxNyBhdCBk ZXZpY2UgMC4wIG9uIHBjaTQKYmdlMDogQ0hJUCBJRCAweDAwMDA0MDAxOyBBU0lDIFJFViAweDA0 OyBDSElQIFJFViAweDQwOyBQQ0ktRQptaWlidXMwOiA8TUlJIGJ1cz4gb24gYmdlMApicmdwaHkw OiA8QkNNNTc1MCAxMC8xMDAvMTAwMGJhc2VUWCBQSFk+IFBIWSAxIG9uIG1paWJ1czAKYnJncGh5 MDogIDEwYmFzZVQsIDEwYmFzZVQtRkRYLCAxMDBiYXNlVFgsIDEwMGJhc2VUWC1GRFgsIDEwMDBi YXNlVCwgMTAwMGJhc2VULW1hc3RlciwgMTAwMGJhc2VULUZEWCwgMTAwMGJhc2VULUZEWC1tYXN0 ZXIsIGF1dG8sIGF1dG8tZmxvdwpiZ2UwOiBFdGhlcm5ldCBhZGRyZXNzOiAwMDoxMjozZjo3NTpk YjpiZgpiZ2UwOiBbSVRIUkVBRF0KdWhjaTA6IDxJbnRlbCA4MjgwMUcgKElDSDcpIFVTQiBjb250 cm9sbGVyIFVTQi1BPiBwb3J0IDB4ZmY4MC0weGZmOWYgaXJxIDIxIGF0IGRldmljZSAyOS4wIG9u IHBjaTAKdWhjaTA6IFtJVEhSRUFEXQp1aGNpMDogTGVnU3VwID0gMHgzMDAwCnVzYnVzMDogPElu dGVsIDgyODAxRyAoSUNINykgVVNCIGNvbnRyb2xsZXIgVVNCLUE+IG9uIHVoY2kwCnVoY2kxOiA8 SW50ZWwgODI4MDFHIChJQ0g3KSBVU0IgY29udHJvbGxlciBVU0ItQj4gcG9ydCAweGZmNjAtMHhm ZjdmIGlycSAyMiBhdCBkZXZpY2UgMjkuMSBvbiBwY2kwCnVoY2kxOiBbSVRIUkVBRF0KdXNidXMx OiA8SW50ZWwgODI4MDFHIChJQ0g3KSBVU0IgY29udHJvbGxlciBVU0ItQj4gb24gdWhjaTEKdWhj aTI6IDxJbnRlbCA4MjgwMUcgKElDSDcpIFVTQiBjb250cm9sbGVyIFVTQi1DPiBwb3J0IDB4ZmY0 MC0weGZmNWYgaXJxIDE4IGF0IGRldmljZSAyOS4yIG9uIHBjaTAKdWhjaTI6IFtJVEhSRUFEXQp1 c2J1czI6IDxJbnRlbCA4MjgwMUcgKElDSDcpIFVTQiBjb250cm9sbGVyIFVTQi1DPiBvbiB1aGNp Mgp1aGNpMzogPEludGVsIDgyODAxRyAoSUNINykgVVNCIGNvbnRyb2xsZXIgVVNCLUQ+IHBvcnQg MHhmZjIwLTB4ZmYzZiBpcnEgMjMgYXQgZGV2aWNlIDI5LjMgb24gcGNpMAp1aGNpMzogW0lUSFJF QURdCnVzYnVzMzogPEludGVsIDgyODAxRyAoSUNINykgVVNCIGNvbnRyb2xsZXIgVVNCLUQ+IG9u IHVoY2kzCmVoY2kwOiA8SW50ZWwgODI4MDFHQi9SIChJQ0g3KSBVU0IgMi4wIGNvbnRyb2xsZXI+ IG1lbSAweGZmYTgwODAwLTB4ZmZhODBiZmYgaXJxIDIxIGF0IGRldmljZSAyOS43IG9uIHBjaTAK ZWhjaTA6IFtJVEhSRUFEXQp1c2J1czQ6IEVIQ0kgdmVyc2lvbiAxLjAKdXNidXM0OiA8SW50ZWwg ODI4MDFHQi9SIChJQ0g3KSBVU0IgMi4wIGNvbnRyb2xsZXI+IG9uIGVoY2kwCnBjaWI1OiA8QUNQ SSBQQ0ktUENJIGJyaWRnZT4gYXQgZGV2aWNlIDMwLjAgb24gcGNpMApwY2k1OiA8QUNQSSBQQ0kg YnVzPiBvbiBwY2liNQpwY2liNjogPFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2UgMi4wIG9uIHBj aTUKcGNpNjogPFBDSSBidXM+IG9uIHBjaWI2CnBjaTY6IDxicmlkZ2U+IGF0IGRldmljZSAwLjAg KG5vIGRyaXZlciBhdHRhY2hlZCkKaG1lMDogPFN1biBITUUgMTAvMTAwIEV0aGVybmV0PiBtZW0g MHhmZTRlMDAwMC0weGZlNGU3ZmZmIGlycSAxOSBhdCBkZXZpY2UgMC4xIG9uIHBjaTYKbWlpYnVz MTogPE1JSSBidXM+IG9uIGhtZTAKdWtwaHkwOiA8R2VuZXJpYyBJRUVFIDgwMi4zdSBtZWRpYSBp bnRlcmZhY2U+IFBIWSAxIG9uIG1paWJ1czEKdWtwaHkwOiAgMTBiYXNlVCwgMTBiYXNlVC1GRFgs IDEwMGJhc2VUWCwgMTAwYmFzZVRYLUZEWCwgYXV0bwpobWUwOiBFdGhlcm5ldCBhZGRyZXNzOiAw ODowMDoyMDplZjowZDo4OApobWUwOiBbSVRIUkVBRF0KcGNpNjogPGJyaWRnZT4gYXQgZGV2aWNl IDEuMCAobm8gZHJpdmVyIGF0dGFjaGVkKQpobWUxOiA8U3VuIEhNRSAxMC8xMDAgRXRoZXJuZXQ+ IG1lbSAweGZlNGU4MDAwLTB4ZmU0ZWZmZmYgaXJxIDE2IGF0IGRldmljZSAxLjEgb24gcGNpNgpt aWlidXMyOiA8TUlJIGJ1cz4gb24gaG1lMQp1a3BoeTE6IDxHZW5lcmljIElFRUUgODAyLjN1IG1l ZGlhIGludGVyZmFjZT4gUEhZIDEgb24gbWlpYnVzMgp1a3BoeTE6ICAxMGJhc2VULCAxMGJhc2VU LUZEWCwgMTAwYmFzZVRYLCAxMDBiYXNlVFgtRkRYLCBhdXRvCmhtZTE6IEV0aGVybmV0IGFkZHJl c3M6IDA4OjAwOjIwOmVmOjBkOjg5CmhtZTE6IFtJVEhSRUFEXQpwY2k2OiA8YnJpZGdlPiBhdCBk ZXZpY2UgMi4wIChubyBkcml2ZXIgYXR0YWNoZWQpCmhtZTI6IDxTdW4gSE1FIDEwLzEwMCBFdGhl cm5ldD4gbWVtIDB4ZmU0ZjAwMDAtMHhmZTRmN2ZmZiBpcnEgMTcgYXQgZGV2aWNlIDIuMSBvbiBw Y2k2Cm1paWJ1czM6IDxNSUkgYnVzPiBvbiBobWUyCnVrcGh5MjogPEdlbmVyaWMgSUVFRSA4MDIu M3UgbWVkaWEgaW50ZXJmYWNlPiBQSFkgMSBvbiBtaWlidXMzCnVrcGh5MjogIDEwYmFzZVQsIDEw YmFzZVQtRkRYLCAxMDBiYXNlVFgsIDEwMGJhc2VUWC1GRFgsIGF1dG8KaG1lMjogRXRoZXJuZXQg YWRkcmVzczogMDg6MDA6MjA6ZWY6MGQ6OGEKaG1lMjogW0lUSFJFQURdCnBjaTY6IDxicmlkZ2U+ IGF0IGRldmljZSAzLjAgKG5vIGRyaXZlciBhdHRhY2hlZCkKaG1lMzogPFN1biBITUUgMTAvMTAw IEV0aGVybmV0PiBtZW0gMHhmZTRmODAwMC0weGZlNGZmZmZmIGlycSAxOCBhdCBkZXZpY2UgMy4x IG9uIHBjaTYKbWlpYnVzNDogPE1JSSBidXM+IG9uIGhtZTMKdWtwaHkzOiA8R2VuZXJpYyBJRUVF IDgwMi4zdSBtZWRpYSBpbnRlcmZhY2U+IFBIWSAxIG9uIG1paWJ1czQKdWtwaHkzOiAgMTBiYXNl VCwgMTBiYXNlVC1GRFgsIDEwMGJhc2VUWCwgMTAwYmFzZVRYLUZEWCwgYXV0bwpobWUzOiBFdGhl cm5ldCBhZGRyZXNzOiAwODowMDoyMDplZjowZDo4YgpobWUzOiBbSVRIUkVBRF0KdmdhcGNpMDog PFZHQS1jb21wYXRpYmxlIGRpc3BsYXk+IHBvcnQgMHhkYzgwLTB4ZGNmZiBtZW0gMHhmNjAwMDAw MC0weGY3ZmZmZmZmLDB4ZmU2YzAwMDAtMHhmZTZmZmZmZiBhdCBkZXZpY2UgNy4wIG9uIHBjaTUK aXNhYjA6IDxQQ0ktSVNBIGJyaWRnZT4gYXQgZGV2aWNlIDMxLjAgb24gcGNpMAppc2EwOiA8SVNB IGJ1cz4gb24gaXNhYjAKYXRhcGNpMDogPEludGVsIElDSDcgVURNQTEwMCBjb250cm9sbGVyPiBw b3J0IDB4MWYwLTB4MWY3LDB4M2Y2LDB4MTcwLTB4MTc3LDB4Mzc2LDB4ZmZhMC0weGZmYWYgaXJx IDE2IGF0IGRldmljZSAzMS4xIG9uIHBjaTAKYXRhMDogPEFUQSBjaGFubmVsIDA+IG9uIGF0YXBj aTAKYXRhMDogW0lUSFJFQURdCmF0YXBjaTE6IDxJbnRlbCBJQ0g3IFNBVEEzMDAgY29udHJvbGxl cj4gcG9ydCAweGZlMDAtMHhmZTA3LDB4ZmUxMC0weGZlMTMsMHhmZTIwLTB4ZmUyNywweGZlMzAt MHhmZTMzLDB4ZmVhMC0weGZlYWYgaXJxIDIwIGF0IGRldmljZSAzMS4yIG9uIHBjaTAKYXRhcGNp MTogW0lUSFJFQURdCmF0YTI6IDxBVEEgY2hhbm5lbCAwPiBvbiBhdGFwY2kxCmF0YTI6IFtJVEhS RUFEXQphdGEzOiA8QVRBIGNoYW5uZWwgMT4gb24gYXRhcGNpMQphdGEzOiBbSVRIUkVBRF0KcGNp MDogPHNlcmlhbCBidXMsIFNNQnVzPiBhdCBkZXZpY2UgMzEuMyAobm8gZHJpdmVyIGF0dGFjaGVk KQphdHJ0YzA6IDxBVCByZWFsdGltZSBjbG9jaz4gcG9ydCAweDcwLTB4N2YgaXJxIDggb24gYWNw aTAKdWFydDA6IDwxNjU1MCBvciBjb21wYXRpYmxlPiBwb3J0IDB4M2Y4LTB4M2ZmIGlycSA0IGZs YWdzIDB4MTAgb24gYWNwaTAKdWFydDA6IFtGSUxURVJdCm9ybTA6IDxJU0EgT3B0aW9uIFJPTXM+ IGF0IGlvbWVtIDB4YzAwMDAtMHhjN2ZmZiwweGM4MDAwLTB4YzlmZmYsMHhjYTAwMC0weGNiZmZm IG9uIGlzYTAKc2MwOiA8U3lzdGVtIGNvbnNvbGU+IGF0IGZsYWdzIDB4MTAwIG9uIGlzYTAKc2Mw OiBWR0EgPDE2IHZpcnR1YWwgY29uc29sZXMsIGZsYWdzPTB4MzAwPgp2Z2EwOiA8R2VuZXJpYyBJ U0EgVkdBPiBhdCBwb3J0IDB4M2MwLTB4M2RmIGlvbWVtIDB4YTAwMDAtMHhiZmZmZiBvbiBpc2Ew CmF0a2JkYzA6IDxLZXlib2FyZCBjb250cm9sbGVyIChpODA0Mik+IGF0IHBvcnQgMHg2MCwweDY0 IG9uIGlzYTAKYXRrYmQwOiA8QVQgS2V5Ym9hcmQ+IGlycSAxIG9uIGF0a2JkYzAKa2JkMCBhdCBh dGtiZDAKYXRrYmQwOiBbR0lBTlQtTE9DS0VEXQphdGtiZDA6IFtJVEhSRUFEXQpwcGMwOiBjYW5u b3QgcmVzZXJ2ZSBJL08gcG9ydCByYW5nZQpwNHRjYzA6IDxDUFUgRnJlcXVlbmN5IFRoZXJtYWwg Q29udHJvbD4gb24gY3B1MApwNHRjYzE6IDxDUFUgRnJlcXVlbmN5IFRoZXJtYWwgQ29udHJvbD4g b24gY3B1MQpaRlMgZmlsZXN5c3RlbSB2ZXJzaW9uIDQKWkZTIHN0b3JhZ2UgcG9vbCB2ZXJzaW9u IDE1ClRpbWVjb3VudGVycyB0aWNrIGV2ZXJ5IDEuMDAwIG1zZWMKdXNidXMwOiAxMk1icHMgRnVs bCBTcGVlZCBVU0IgdjEuMAp1c2J1czE6IDEyTWJwcyBGdWxsIFNwZWVkIFVTQiB2MS4wCnVzYnVz MjogMTJNYnBzIEZ1bGwgU3BlZWQgVVNCIHYxLjAKdXNidXMzOiAxMk1icHMgRnVsbCBTcGVlZCBV U0IgdjEuMAp1c2J1czQ6IDQ4ME1icHMgSGlnaCBTcGVlZCBVU0IgdjIuMAp1Z2VuMC4xOiA8SW50 ZWw+IGF0IHVzYnVzMAp1aHViMDogPEludGVsIFVIQ0kgcm9vdCBIVUIsIGNsYXNzIDkvMCwgcmV2 IDEuMDAvMS4wMCwgYWRkciAxPiBvbiB1c2J1czAKdWdlbjEuMTogPEludGVsPiBhdCB1c2J1czEK dWh1YjE6IDxJbnRlbCBVSENJIHJvb3QgSFVCLCBjbGFzcyA5LzAsIHJldiAxLjAwLzEuMDAsIGFk ZHIgMT4gb24gdXNidXMxCnVnZW4yLjE6IDxJbnRlbD4gYXQgdXNidXMyCnVodWIyOiA8SW50ZWwg VUhDSSByb290IEhVQiwgY2xhc3MgOS8wLCByZXYgMS4wMC8xLjAwLCBhZGRyIDE+IG9uIHVzYnVz Mgp1Z2VuMy4xOiA8SW50ZWw+IGF0IHVzYnVzMwp1aHViMzogPEludGVsIFVIQ0kgcm9vdCBIVUIs IGNsYXNzIDkvMCwgcmV2IDEuMDAvMS4wMCwgYWRkciAxPiBvbiB1c2J1czMKdWdlbjQuMTogPElu dGVsPiBhdCB1c2J1czQKdWh1YjQ6IDxJbnRlbCBFSENJIHJvb3QgSFVCLCBjbGFzcyA5LzAsIHJl diAyLjAwLzEuMDAsIGFkZHIgMT4gb24gdXNidXM0CmFjZDA6IERWRFJPTSA8SEwtRFQtU1REVkQt Uk9NIEdEUjgxNjNCLzBEMjA+IGF0IGF0YTAtbWFzdGVyIFVETUEzMyAKYWQ0OiAxOTA3NzI5TUIg PFdEQyBXRDIwRUFSUy0wME1WV0IwIDUxLjBBQjUxPiBhdCBhdGEyLW1hc3RlciBVRE1BMTAwIFNB VEEKYWQ1OiAxOTA3NzI5TUIgPFdEQyBXRDIwRUFSUy0wME1WV0IwIDUxLjBBQjUxPiBhdCBhdGEy LXNsYXZlIFVETUExMDAgU0FUQQphZDY6IDE5MDc3MjlNQiA8V0RDIFdEMjBFQVJTLTAwTVZXQjAg NTEuMEFCNTE+IGF0IGF0YTMtbWFzdGVyIFVETUExMDAgU0FUQQpFbnRlciBwYXNzcGhyYXNlIGZv ciBhZDRwMjogdWh1YjA6IDIgcG9ydHMgd2l0aCAyIHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkCnVo dWIxOiAyIHBvcnRzIHdpdGggMiByZW1vdmFibGUsIHNlbGYgcG93ZXJlZAp1aHViMjogMiBwb3J0 cyB3aXRoIDIgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQKdWh1YjM6IDIgcG9ydHMgd2l0aCAyIHJl bW92YWJsZSwgc2VsZiBwb3dlcmVkCnVodWI0OiA4IHBvcnRzIHdpdGggOCByZW1vdmFibGUsIHNl bGYgcG93ZXJlZAp1Z2VuNC4yOiA8dmVuZG9yIDB4MTNmZT4gYXQgdXNidXM0CnVtYXNzMDogPHZl bmRvciAweDEzZmUgVVNCIERJU0sgMi4wLCBjbGFzcyAwLzAsIHJldiAyLjAwLzEuMDAsIGFkZHIg Mj4gb24gdXNidXM0CnVtYXNzMDogIFNDU0kgb3ZlciBCdWxrLU9ubHk7IHF1aXJrcyA9IDB4MDAw MAp1bWFzczA6MDowOi0xOiBBdHRhY2hlZCB0byBzY2J1czAKZGEwIGF0IHVtYXNzLXNpbTAgYnVz IDAgc2NidXMwIHRhcmdldCAwIGx1biAwCmRhMDogPCBVU0IgRElTSyAyLjAgREwwNz4gUmVtb3Zh YmxlIERpcmVjdCBBY2Nlc3MgU0NTSS0wIGRldmljZSAKZGEwOiA0MC4wMDBNQi9zIHRyYW5zZmVy cwpkYTA6IDc2NDBNQiAoMTU2NDY3MjAgNTEyIGJ5dGUgc2VjdG9yczogMjU1SCA2M1MvVCA5NzND KQp1Z2VuMy4yOiA8REVMTD4gYXQgdXNidXMzCnVrYmQwOiA8REVMTCBEZWxsIFF1aWV0S2V5IEtl eWJvYXJkLCBjbGFzcyAwLzAsIHJldiAxLjEwLzEuMDEsIGFkZHIgMj4gb24gdXNidXMzCmtiZDIg YXQgdWtiZDAKYWQ3OiAxOTA3NzI5TUIgPFdEQyBXRDIwRUFSUy0wME1WV0IwIDUxLjBBQjUxPiBh dCBhdGEzLXNsYXZlIFVETUExMDAgU0FUQQpsYXBpYzE6IEZvcmNpbmcgTElOVDEgdG8gZWRnZSB0 cmlnZ2VyClNNUDogQVAgQ1BVICMxIExhdW5jaGVkIQoKR0VPTV9FTEk6IERldmljZSBhZDRwMi5l bGkgY3JlYXRlZC4KR0VPTV9FTEk6IEVuY3J5cHRpb246IEFFUy1YVFMgMjU2CkdFT01fRUxJOiAg ICAgQ3J5cHRvOiBzb2Z0d2FyZQpFbnRlciBwYXNzcGhyYXNlIGZvciBhZDVwMjogCkdFT01fRUxJ OiBEZXZpY2UgYWQ1cDIuZWxpIGNyZWF0ZWQuCkdFT01fRUxJOiBFbmNyeXB0aW9uOiBBRVMtWFRT IDI1NgpHRU9NX0VMSTogICAgIENyeXB0bzogc29mdHdhcmUKRW50ZXIgcGFzc3BocmFzZSBmb3Ig YWQ2cDI6IApHRU9NX0VMSTogRGV2aWNlIGFkNnAyLmVsaSBjcmVhdGVkLgpHRU9NX0VMSTogRW5j cnlwdGlvbjogQUVTLVhUUyAyNTYKR0VPTV9FTEk6ICAgICBDcnlwdG86IHNvZnR3YXJlCkVudGVy IHBhc3NwaHJhc2UgZm9yIGFkN3AyOiAKR0VPTV9FTEk6IERldmljZSBhZDdwMi5lbGkgY3JlYXRl ZC4KR0VPTV9FTEk6IEVuY3J5cHRpb246IEFFUy1YVFMgMjU2CkdFT01fRUxJOiAgICAgQ3J5cHRv OiBzb2Z0d2FyZQpUcnlpbmcgdG8gbW91bnQgcm9vdCBmcm9tIHpmczp0YW5rCkdFT01fRUxJOiBE ZXZpY2UgYWQ0cDEuZWxpIGNyZWF0ZWQuCkdFT01fRUxJOiBFbmNyeXB0aW9uOiBBRVMtWFRTIDI1 NgpHRU9NX0VMSTogICAgIENyeXB0bzogc29mdHdhcmUKR0VPTV9FTEk6IERldmljZSBhZDVwMS5l bGkgY3JlYXRlZC4KR0VPTV9FTEk6IEVuY3J5cHRpb246IEFFUy1YVFMgMjU2CkdFT01fRUxJOiAg ICAgQ3J5cHRvOiBzb2Z0d2FyZQpHRU9NX0VMSTogRGV2aWNlIGFkNnAxLmVsaSBjcmVhdGVkLgpH RU9NX0VMSTogRW5jcnlwdGlvbjogQUVTLVhUUyAyNTYKR0VPTV9FTEk6ICAgICBDcnlwdG86IHNv ZnR3YXJlCkdFT01fRUxJOiBEZXZpY2UgYWQ3cDEuZWxpIGNyZWF0ZWQuCkdFT01fRUxJOiBFbmNy eXB0aW9uOiBBRVMtWFRTIDI1NgpHRU9NX0VMSTogICAgIENyeXB0bzogc29mdHdhcmUKaG1lMDog bGluayBzdGF0ZSBjaGFuZ2VkIHRvIFVQCmhtZTA6IGxpbmsgc3RhdGUgY2hhbmdlZCB0byBET1dO CmhtZTA6IGxpbmsgc3RhdGUgY2hhbmdlZCB0byBVUApobWUwOiBsaW5rIHN0YXRlIGNoYW5nZWQg dG8gRE9XTgpobWUwOiBsaW5rIHN0YXRlIGNoYW5nZWQgdG8gVVAK --MP_/1GIg4dXInacqQ=19ckUgsV7-- From owner-freebsd-stable@FreeBSD.ORG Thu Jun 23 21:15:30 2011 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (unknown [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E2B5D1065672; Thu, 23 Jun 2011 21:15:30 +0000 (UTC) (envelope-from joe@gracenpeace.net) Received: from shorty.gracenpeace.net (shorty.gracenpeace.net [209.181.242.73]) by mx1.freebsd.org (Postfix) with ESMTP id BC7868FC19; Thu, 23 Jun 2011 21:15:30 +0000 (UTC) Received: from [127.0.0.1] (mail.holidaycompanies.com [209.98.45.253]) by shorty.gracenpeace.net (Postfix) with ESMTP id 0C7C3439012; Thu, 23 Jun 2011 14:41:54 -0500 (CDT) Message-ID: <4E03A647.5070501@gracenpeace.net> Date: Thu, 23 Jun 2011 15:47:03 -0500 From: Joe in MPLS User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: scsi@freebsd.org, stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: LTO3 tape drive not detected X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2011 21:15:31 -0000 This was originally posted on the freebsd-questions list. It was suggested that I post it here: I have FreeBSD 8.2-RELEASE running on an HP DL360 G5. I recently added an (HP branded) LSI Logic single channel SCSI 320 card and attached an HP Ultrium 920 LTO3 tape drive. The system sees the SCSI controller as mpt0, and it seems to know there's something at SCSI ID 4, but I get an "AutoSense Failed" for hba/id/lun 0:4:0 at boot and subsequent camcontrol rescans. I checked the supported hardware doc for the release but it doesn't get very specific about tape drives. This is my first experience with LTO3 tape. I was hoping that I'd automagically get a /dev/sa0 device like I always did with my old DLT drives but it wasn't to be this time. Is there a way to make this drive work? From owner-freebsd-stable@FreeBSD.ORG Thu Jun 23 22:23:33 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (unknown [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AD7A7106566B; Thu, 23 Jun 2011 22:23:33 +0000 (UTC) (envelope-from David.Boyd@insightbb.com) Received: from mxsf01.insightbb.com (mxsf01.insightbb.com [74.128.0.71]) by mx1.freebsd.org (Postfix) with ESMTP id 69BF68FC0C; Thu, 23 Jun 2011 22:23:33 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.65,415,1304308800"; d="scan'208";a="1158023126" Received: from unknown (HELO asav01.insightbb.com) ([172.31.249.123]) by mxsf01.insightbb.com with ESMTP; 23 Jun 2011 17:55:15 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFANm1A05KgYlR/2dsb2JhbABSihedFXjKcw6GHwSiHA X-IronPort-AV: E=Sophos;i="4.65,415,1304308800"; d="scan'208";a="350634690" Received: from 74-129-137-81.dhcp.insightbb.com (HELO sneezy) ([74.129.137.81]) by asav01.insightbb.com with SMTP; 23 Jun 2011 17:55:14 -0400 From: "David Boyd" To: , Date: Thu, 23 Jun 2011 17:55:15 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 Cc: Subject: current status of digi driver X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2011 22:23:33 -0000 While attempting to upgrade our comm servers from 7.4-RELEASE to 8.2-RELEASE, I discovered that the digi driver didn't make the grade. I searched the archives and found discussions in August 2008 concerning drivers that were disconnected for lack of MPSAFEness. The threads continued right up to the point where it was agreed that the drivers shouldn't be allowed to halt/delay the MPSAFE switch in 8.0-RELEASE. It appears that there was also agreement that (at least) some of the drivers, digi included, would be converted soon after 8.0-RELEASE. The pre-MPSAFE code appears to be included in the most recent -STABLE and -CURRENT, but doesn't get built. The HARDWARE.TXT still includes digi among supported multiport serial device drivers. Is there any plan to bring digi forward? We have about 55 modem ports over ten 8-port Xr cards (PCI) that connect remote sites via dial-up. These work perfectly with 7.4-RELEASE. We would like to see them work perfectly with 8.x-RELEASE or 9.x-RELEASE. I have time and hardware to test with and can help as needed. Thoughts? From owner-freebsd-stable@FreeBSD.ORG Thu Jun 23 23:19:56 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (unknown [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C2EE1106566B; Thu, 23 Jun 2011 23:19:56 +0000 (UTC) (envelope-from gavin.atkinson@ury.york.ac.uk) Received: from gse-mta-27.emailfiltering.com (gse-mta-27-tx.emailfiltering.com [194.116.198.158]) by mx1.freebsd.org (Postfix) with ESMTP id 0AA3D8FC19; Thu, 23 Jun 2011 23:19:55 +0000 (UTC) Received: from mail-gw12.york.ac.uk ([144.32.129.162]) by gse-mta-27.emailfiltering.com with emfmta (version 4.8.2.32) by TLS id 1045651132 for David.Boyd@insightbb.com; dc0b46d621fa782d; Fri, 24 Jun 2011 00:01:28 +0100 Received: from ury.york.ac.uk ([144.32.108.81]:38870) by mail-gw12.york.ac.uk with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1QZstr-0003Rz-Cg; Fri, 24 Jun 2011 00:01:27 +0100 Received: from gavin (helo=localhost) by ury.york.ac.uk with local-esmtp (Exim 4.76) (envelope-from ) id 1QZstn-0007k6-Vb; Fri, 24 Jun 2011 00:01:24 +0100 Date: Fri, 24 Jun 2011 00:01:23 +0100 (BST) From: Gavin Atkinson X-X-Sender: gavin@"ury.york.ac.uk." To: David Boyd In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (LNX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: current status of digi driver X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2011 23:19:56 -0000 On Thu, 23 Jun 2011, David Boyd wrote: > While attempting to upgrade our comm servers from 7.4-RELEASE to > 8.2-RELEASE, I discovered that the digi driver didn't make the grade. > > I searched the archives and found discussions in August 2008 concerning > drivers that were disconnected for lack of MPSAFEness. The threads > continued right up to the point where it was agreed that the drivers > shouldn't be allowed to halt/delay the MPSAFE switch in 8.0-RELEASE. > > It appears that there was also agreement that (at least) some of the > drivers, digi included, would be converted soon after 8.0-RELEASE. > > The pre-MPSAFE code appears to be included in the most recent -STABLE > and -CURRENT, but doesn't get built. The HARDWARE.TXT still includes digi > among supported multiport serial device drivers. > > Is there any plan to bring digi forward? [snip] > I have time and hardware to test with and can help as needed. Patches have been submitted in the last week to update the digi(4) driver to work with the new TTY layer. If you are able to spend some time testing them on 9-CURRENT, there is a possibility that there may still be time to get them into the tree before 9.0-RELEASE. The patches can be found in kern/158086. Thanks, Gavin From owner-freebsd-stable@FreeBSD.ORG Fri Jun 24 01:47:39 2011 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (unknown [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 528C81065670; Fri, 24 Jun 2011 01:47:39 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id C4B3D8FC12; Fri, 24 Jun 2011 01:47:37 +0000 (UTC) Received: from ur.dons.net.au (ppp203-122-208-108.lns5.adl6.internode.on.net [203.122.208.108]) (authenticated bits=0) by cain.gsoft.com.au (8.14.4/8.14.3) with ESMTP id p5O1FAFP006452 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 24 Jun 2011 10:45:12 +0930 (CST) (envelope-from doconnor@gsoft.com.au) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Daniel O'Connor" In-Reply-To: <4E03A647.5070501@gracenpeace.net> Date: Fri, 24 Jun 2011 10:45:10 +0930 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E03A647.5070501@gracenpeace.net> To: Joe in MPLS X-Mailer: Apple Mail (2.1084) X-Spam-Score: 0.163 () BAYES_00,RDNS_DYNAMIC X-Scanned-By: MIMEDefang 2.67 on 203.31.81.10 Cc: stable@freebsd.org, scsi@freebsd.org Subject: Re: LTO3 tape drive not detected X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2011 01:47:39 -0000 On 24/06/2011, at 6:17, Joe in MPLS wrote: > This was originally posted on the freebsd-questions list. It was = suggested that I post it here: >=20 > I have FreeBSD 8.2-RELEASE running on an HP DL360 G5. I recently added = an (HP branded) LSI Logic single channel SCSI 320 card and attached an = HP Ultrium 920 LTO3 tape drive. >=20 > The system sees the SCSI controller as mpt0, and it seems to know = there's something at SCSI ID 4, but I get an "AutoSense Failed" for = hba/id/lun 0:4:0 at boot and subsequent camcontrol rescans. >=20 > I checked the supported hardware doc for the release but it doesn't = get very specific about tape drives. This is my first experience with = LTO3 tape. I was hoping that I'd automagically get a /dev/sa0 device = like I always did with my old DLT drives but it wasn't to be this time. >=20 > Is there a way to make this drive work? I'd check the cabling etc.. I have an LTO2 drive that "Just works (tm)". Can you boot a Linux ISO and see if that finds it? -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C From owner-freebsd-stable@FreeBSD.ORG Fri Jun 24 02:23:13 2011 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (unknown [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4A120106564A for ; Fri, 24 Jun 2011 02:23:13 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta08.emeryville.ca.mail.comcast.net (qmta08.emeryville.ca.mail.comcast.net [76.96.30.80]) by mx1.freebsd.org (Postfix) with ESMTP id 306EF8FC08 for ; Fri, 24 Jun 2011 02:23:12 +0000 (UTC) Received: from omta08.emeryville.ca.mail.comcast.net ([76.96.30.12]) by qmta08.emeryville.ca.mail.comcast.net with comcast id zcVs1g0090FhH24A8ePAn9; Fri, 24 Jun 2011 02:23:10 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta08.emeryville.ca.mail.comcast.net with comcast id zeP81g0071t3BNj8UePBBP; Fri, 24 Jun 2011 02:23:15 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 8E2C8102C36; Thu, 23 Jun 2011 19:23:03 -0700 (PDT) Date: Thu, 23 Jun 2011 19:23:03 -0700 From: Jeremy Chadwick To: Daniel O'Connor Message-ID: <20110624022303.GA19128@icarus.home.lan> References: <4E03A647.5070501@gracenpeace.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: stable@freebsd.org, Joe in MPLS , scsi@freebsd.org Subject: Re: LTO3 tape drive not detected X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2011 02:23:13 -0000 On Fri, Jun 24, 2011 at 10:45:10AM +0930, Daniel O'Connor wrote: > > On 24/06/2011, at 6:17, Joe in MPLS wrote: > > This was originally posted on the freebsd-questions list. It was suggested that I post it here: > > > > I have FreeBSD 8.2-RELEASE running on an HP DL360 G5. I recently added an (HP branded) LSI Logic single channel SCSI 320 card and attached an HP Ultrium 920 LTO3 tape drive. > > > > The system sees the SCSI controller as mpt0, and it seems to know there's something at SCSI ID 4, but I get an "AutoSense Failed" for hba/id/lun 0:4:0 at boot and subsequent camcontrol rescans. > > > > I checked the supported hardware doc for the release but it doesn't get very specific about tape drives. This is my first experience with LTO3 tape. I was hoping that I'd automagically get a /dev/sa0 device like I always did with my old DLT drives but it wasn't to be this time. > > > > Is there a way to make this drive work? > > I'd check the cabling etc.. > > I have an LTO2 drive that "Just works (tm)". > > Can you boot a Linux ISO and see if that finds it? I would recommend you two compare comparing DIP switch or jumper settings, as well as firmware versions. Many tape drives have "compatibility" switches, and firmware versions play a huge role. SCSI card settings (within the SCSI BIOS) would also play a large role here. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Fri Jun 24 11:24:33 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (unknown [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2DA3E106566B for ; Fri, 24 Jun 2011 11:24:33 +0000 (UTC) (envelope-from laa@cemu.ru) Received: from m.cemu.ru (m.cemu.ru [194.186.216.68]) by mx1.freebsd.org (Postfix) with ESMTP id D7B788FC0A for ; Fri, 24 Jun 2011 11:24:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=laa.zp.ua; s=dkim; h=Sender:Content-Type:Mime-Version:Message-ID:Subject:To:From:Date; bh=L07hb8OqhcskW1IdlvKt7zvdMa0gl1D4WTZkJGYHRto=; b=ALCTrEzvlJef3/dXdMzQOaXFvdv1zdoGjDeGg5bFkQ8cr17TWV3D9ZdQ+cepV25ZdyQ6vbbWU1q5ge6v30ItU9YXkMfg70c7YSYGnkpCfQL9aYo3db4QJH6cYndwU996O9/5ZGAdPTiRTfRVG+8OV4xORtjjM9UFrqeCCtQslf4=; Received: by m.cemu.ru with local (Exim) (envelope-from ) id 1Qa4Uw-0000g1-Kl for freebsd-stable@freebsd.org; Fri, 24 Jun 2011 15:24:30 +0400 Date: Fri, 24 Jun 2011 15:24:30 +0400 From: Lystopad Olexandr To: freebsd-stable@freebsd.org Message-ID: <20110624112430.GU74833@laa.zp.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Sender: laa Subject: nfe troubles on -stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2011 11:24:33 -0000 hi! I csup 8.2-rel to 8.2-stable from 2011.06.09.00.00.00, add ifconfig_nfe0="up DHCP" to rc.conf and have error. But if I put static ip in rc.conf system boots ok. error: Jun 24 11:10:58 hosted-by2 kernel: nfe0: discard frame w/o leading ethernet header (len 0 pkt len 0) Jun 24 11:10:58 hosted-by2 last message repeated 28 times Jun 24 11:11:00 hosted-by2 /usr/sbin/cron[1553]: (operator) CMD (/usr/libexec/save-entropy) Jun 24 11:11:05 hosted-by2 dhclient[1359]: DHCPREQUEST on nfe0 to 255.255.255.255 port 67 Jun 24 11:11:05 hosted-by2 kernel: nfe0: discard frame w/o leading ethernet header (len 0 pkt len 0) Jun 24 11:11:20 hosted-by2 last message repeated 35 times Jun 24 11:11:21 hosted-by2 dhclient[1359]: DHCPDISCOVER on nfe0 to 255.255.255.255 port 67 interval 8 Jun 24 11:11:21 hosted-by2 kernel: nfe0: discard frame w/o leading ethernet header (len 0 pkt len 0) Jun 24 11:11:21 hosted-by2 last message repeated 28 times Jun 24 11:11:29 hosted-by2 dhclient[1359]: DHCPDISCOVER on nfe0 to 255.255.255.255 port 67 interval 10 Jun 24 11:11:29 hosted-by2 kernel: nfe0: discard frame w/o leading ethernet header (len 0 pkt len 0) Jun 24 11:11:36 hosted-by2 last message repeated 29 times Jun 24 11:11:39 hosted-by2 dhclient[1359]: DHCPDISCOVER on nfe0 to 255.255.255.255 port 67 interval 15 Jun 24 11:11:39 hosted-by2 kernel: nfe0: discard frame w/o leading ethernet header (len 0 pkt len 0) Jun 24 11:11:39 hosted-by2 last message repeated 28 times Jun 24 11:11:42 hosted-by2 kernel: nfe0: discard frame w/o leading ethernet header (len 4294967295 pkt len 4294967295) Jun 24 11:11:52 hosted-by2 last message repeated 3 times Jun 24 11:11:54 hosted-by2 dhclient[1359]: DHCPDISCOVER on nfe0 to 255.255.255.255 port 67 interval 9 Jun 24 11:11:54 hosted-by2 kernel: nfe0: discard frame w/o leading ethernet header (len 0 pkt len 0) Jun 24 11:12:01 hosted-by2 last message repeated 30 times Jun 24 11:12:03 hosted-by2 dhclient[1359]: DHCPDISCOVER on nfe0 to 255.255.255.255 port 67 interval 9 Jun 24 11:12:03 hosted-by2 kernel: nfe0: discard frame w/o leading ethernet header (len 0 pkt len 0) Jun 24 11:12:09 hosted-by2 last message repeated 29 times Jun 24 11:12:12 hosted-by2 dhclient[1359]: DHCPDISCOVER on nfe0 to 255.255.255.255 port 67 interval 10 Jun 24 11:12:12 hosted-by2 kernel: nfe0: discard frame w/o leading ethernet header (len 0 pkt len 0) pciconf -lvbc: nfe0@pci0:0:20:0: class=0x068000 card=0x2a54103c chip=0x026910de rev=0xa3 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'MCP51 Network Bus Enumerator' class = bridge bar [10] = type Memory, range 32, base 0xfe02b000, size 4096, enabled bar [14] = type I/O Port, range 32, base 0xcc00, size 8, enabled cap 01[44] = powerspec 2 supports D0 D1 D2 D3 current D0 kenv: smbios.bios.reldate="04/17/2007" smbios.bios.vendor="Phoenix Technologies, LTD" smbios.bios.version=" 5.04" smbios.chassis.maker="Hewlett-Packard" smbios.chassis.serial="DM0001" smbios.chassis.tag=" " smbios.chassis.version="1111" smbios.memory.enabled="1048576" smbios.planar.maker="ASUSTek Computer INC." smbios.planar.product="Hematite-XL" smbios.planar.serial="MS1C75S00802301" smbios.planar.version="1.00" smbios.socket.enabled="1" smbios.socket.populated="1" smbios.system.maker="HP-Pavilion" smbios.system.product="GJ474AA-ABA s3100n" -- Lystopad Olexandr From owner-freebsd-stable@FreeBSD.ORG Sat Jun 25 00:45:28 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ECD09106566C; Sat, 25 Jun 2011 00:45:28 +0000 (UTC) (envelope-from peterjeremy@acm.org) Received: from fallbackmx08.syd.optusnet.com.au (fallbackmx08.syd.optusnet.com.au [211.29.132.10]) by mx1.freebsd.org (Postfix) with ESMTP id 0BB948FC13; Sat, 25 Jun 2011 00:45:27 +0000 (UTC) Received: from mail14.syd.optusnet.com.au (mail14.syd.optusnet.com.au [211.29.132.195]) by fallbackmx08.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id p5OMa5ZF014898; Sat, 25 Jun 2011 08:36:05 +1000 Received: from server.vk2pj.dyndns.org (c220-239-116-103.belrs4.nsw.optusnet.com.au [220.239.116.103]) by mail14.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id p5OMa1bh001935 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 25 Jun 2011 08:36:02 +1000 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.4/8.14.4) with ESMTP id p5OMa1JX004253; Sat, 25 Jun 2011 08:36:01 +1000 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.4/8.14.4/Submit) id p5OMa0l4004252; Sat, 25 Jun 2011 08:36:00 +1000 (EST) (envelope-from peter) Date: Sat, 25 Jun 2011 08:36:00 +1000 From: Peter Jeremy To: David Boyd Message-ID: <20110624223600.GB5021@server.vk2pj.dyndns.org> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="1yeeQ81UyVL57Vl7" Content-Disposition: inline In-Reply-To: X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: current status of digi driver X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jun 2011 00:45:29 -0000 --1yeeQ81UyVL57Vl7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2011-Jun-23 17:55:15 -0400, David Boyd wrote: >It appears that there was also agreement that (at least) some of the >drivers, digi included, would be converted soon after 8.0-RELEASE. That came down to developer time and it appeared that I was the only person interested in it. >Is there any plan to bring digi forward? See kern/158086 (which updates digi(4)) and kern/152254 (which re- implements TTY functionality that was lost with TTYng). Both include patches that should work on either 8.x or -current. Of the two, the latter is more urgent because it impacts the KBI. >We have about 55 modem ports over ten 8-port Xr cards (PCI) that connect >remote sites via dial-up. I've only got access to PCI Xem cards that are used for serial console concentration so it would be useful for you to test both the Xr cards and dial-in support. --=20 Peter Jeremy --1yeeQ81UyVL57Vl7 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) iEYEARECAAYFAk4FEVAACgkQ/opHv/APuIek1ACgjZkaeEsC8N0dH8yjB3ttmagZ ppcAoJsomjE2/URTkyHMlvGzUqWe+HzS =a4IU -----END PGP SIGNATURE----- --1yeeQ81UyVL57Vl7-- From owner-freebsd-stable@FreeBSD.ORG Sat Jun 25 14:49:41 2011 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3B6CB106566B; Sat, 25 Jun 2011 14:49:41 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 4543E8FC14; Sat, 25 Jun 2011 14:49:39 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id RAA00510; Sat, 25 Jun 2011 17:49:38 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4E05F582.2010500@FreeBSD.org> Date: Sat, 25 Jun 2011 17:49:38 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.18) Gecko/20110622 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Subject: kern.sync_on_panic X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jun 2011 14:49:41 -0000 Does anybody actually use kern.sync_on_panic tunable/sysctl? If yes, then in what circumstances do you need it? That is, why any other alternative doesn't work for you? Like: 1. remounting filesystems R/O before panic if you knowingly provoke it for testing 2. using netboot for your test system 3. using su+j, gjournal or a different filesystem altogether 4. using fsck after reboot It seems to me that syncing filesystems in panic context is an adventure. And it may become even more of an adventure if we introduce code that completely stops scheduler in and after panic. -- Andriy Gapon