Re: 'zfs send -i': destination has been modified

2010-10-21 Thread Alexander Leidinger
Quoting Derek Buttineau de...@csolve.net (from Wed, 20 Oct 2010  
08:56:11 -0400):


Seeing similar here Dan, my destination filesystems are becoming  
modified sometime after the previous snapshot has been sent so the  
incremental fails to be received.  However, the server I'm sending  
to is not in use so I can't explain why it's changing.


peridoc daily?

zfs set atime=off pool (respectively pool/FS if you need the  
atime recording at other places)


Bye,
Alexander.

--
To stay young requires unceasing cultivation
of the ability to unlearn old falsehoods.
-- Lazarus Long, Time Enough For Love

http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org   netchild @ FreeBSD.org  : PGP ID = 72077137
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org


BIOS limitations on size of bootable zpool?

2010-10-21 Thread Matthew Seaman

Dear all,

I'm happy that gptzfsloader will work with just about any zpool
configuration you could imagine, but...

We have an HP DL185 G5 with a P400 raid array, fully populated with 12
drives.  Since there's no JBOD mode (or at least, not one you can get to
from the BIOS configuration screens), the array is configured as 12
single disk RAID0 arrays.   As I posted about previously, we had FreeBSD
8.1-STABLE installed on a 6 disk raidz1, and everything was happy.
However, we were having some difficulty adding a second vdev -- another
raidz1 using the other 6 drives.

Well, to cut a long story short: eventually we did this by hot-plugging
disks 7 -- 12 after FreeBSD was up and running.  Everything was cool and
dandy, and we had the server running on all drives after setting up gpt
partition tables and doing a 'zpool add'.

Until we tested rebooting.

On attempted reboot, the loader reported 8 drives, and subsequently ZFS
flailed with the dreaded ZFS: i/o error - all block copies unavailable
error.  Now, we've had a poke through FreeBSD sources, and as far as we
can tell, FreeBSD will work with up to 31 devices being reported from
the BIOS.  Is this correct, and the limitation is in what the hardware
is reporting to the loader at the early stages of booting?

Any good tricks for getting round this sort of limitation?  Our current
plan is to set up a USB memstick with /boot on it, by adapting the
instructions here: http://wiki.freebsd.org/RootOnZFS/UFSBoot -- which
isn't ideal as the memstick will be a single point of failure.

Cheers,

Matthew

-- 
Dr Matthew J Seaman MA, D.Phil.   7 Priory Courtyard
  Flat 3
PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate
JID: matt...@infracaninophile.co.uk   Kent, CT11 9PW



signature.asc
Description: OpenPGP digital signature


hast vs ggate+gmirror sychrnoisation speed

2010-10-21 Thread Pete French
Well, I bit the bullet and moved to using hast - all went beautifully,
and I migrated the pool with no downtime. The one thing I do notice,
however, is that the synchronisation with hast is much slower
than the older ggate+gmirror combination. It's about half the
speed in fact.

When I orginaly setup my ggate configuration I did a lot of tweaks to
get the speed good - these copnsisted of expanding the send and
receive space for the sockets using sysctl.conf, and then providing
large buffers to ggate. Is there a way to control this with hast ?
I still have the sysctls set (as the machines have not rebooted)
but I cant see any options in hast.conf which are equivalent to the
-S 262144 -R 262144 which I use with ggate

Any advice, or am I barking up the wrong tree here ?

cheers,

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


Re: kpanic on install 32GB of RAM [SEC=UNCLASSIFIED]

2010-10-21 Thread Andriy Gapon
on 20/10/2010 21:28 Sean Bruno said the following:
 I guess, I could replace the kernel on the CD and have them reburn it?

That should work.
BTW, here I described yet another way of building custom recovery/installation
CDs that I use:
http://wiki.freebsd.org/AvgLiveCD

-- 
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org


Re: BIOS limitations on size of bootable zpool?

2010-10-21 Thread Boris Samorodov
On Thu, 21 Oct 2010 13:01:09 +0100 Matthew Seaman wrote:

 Our current
 plan is to set up a USB memstick with /boot on it, by adapting the
 instructions here: http://wiki.freebsd.org/RootOnZFS/UFSBoot -- which
 isn't ideal as the memstick will be a single point of failure.

We always use gmirrored USB sticks. Works like a charm.

-- 
WBR, Boris Samorodov (bsam)
Research Engineer, http://www.ipt.ru Telephone  Internet SP
FreeBSD Committer, http://www.FreeBSD.org The Power To Serve
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org


Re: kpanic on install 32GB of RAM [SEC=UNCLASSIFIED]

2010-10-21 Thread Sean Bruno
On Thu, 2010-10-21 at 05:48 -0700, Andriy Gapon wrote:
 on 20/10/2010 21:28 Sean Bruno said the following:
  I guess, I could replace the kernel on the CD and have them reburn it?
 
 That should work.
 BTW, here I described yet another way of building custom 
 recovery/installation
 CDs that I use:
 http://wiki.freebsd.org/AvgLiveCD
 

Before I get started on this, it looks like something else is going on.

Here is a panic + trace on the latest 9-current snap shot.  hammer
time indeed.  

Suggestions are welcome!


http://people.freebsd.org/~sbruno/9-current-panic.png

http://people.freebsd.org/~sbruno/9-current-trace-panic.png

Sean

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


Re: BIOS limitations on size of bootable zpool?

2010-10-21 Thread Emil Smolenski
On Thu, 21 Oct 2010 14:01:09 +0200, Matthew Seaman  
m.sea...@infracaninophile.co.uk wrote:



Dear all,

I'm happy that gptzfsloader will work with just about any zpool
configuration you could imagine, but...

We have an HP DL185 G5 with a P400 raid array, fully populated with 12
drives.  Since there's no JBOD mode (or at least, not one you can get to
from the BIOS configuration screens), the array is configured as 12
single disk RAID0 arrays.   As I posted about previously, we had FreeBSD
8.1-STABLE installed on a 6 disk raidz1, and everything was happy.
However, we were having some difficulty adding a second vdev -- another
raidz1 using the other 6 drives.

Well, to cut a long story short: eventually we did this by hot-plugging
disks 7 -- 12 after FreeBSD was up and running.  Everything was cool and
dandy, and we had the server running on all drives after setting up gpt
partition tables and doing a 'zpool add'.

Until we tested rebooting.

On attempted reboot, the loader reported 8 drives, and subsequently ZFS
flailed with the dreaded ZFS: i/o error - all block copies unavailable
error.  Now, we've had a poke through FreeBSD sources, and as far as we
can tell, FreeBSD will work with up to 31 devices being reported from
the BIOS.  Is this correct, and the limitation is in what the hardware
is reporting to the loader at the early stages of booting?

Any good tricks for getting round this sort of limitation?  Our current
plan is to set up a USB memstick with /boot on it, by adapting the
instructions here: http://wiki.freebsd.org/RootOnZFS/UFSBoot -- which
isn't ideal as the memstick will be a single point of failure.


 I think I've encountered the same problem as you. In my configuration  
there is also HP server with HP SmartArray with six disks configured as  
single disk RAID0 logical units. I don't think it is related to size of  
the pool (try to test with small GPT partitions -- for me it also doesn't  
work). I think it is something with this specific hardware and ZFS. I will  
provide more details soon, but for know could you test following  
configurations:

- mirror (it works for me),
- raidz(2) (it doesn't work for me),
- raidz(2) but without SmartArray controller -- adX or adaX disks (it  
works for me).


Please try 'status' command while seeing ZFS: i/o error... message.

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


Re: kpanic on install 32GB of RAM [SEC=UNCLASSIFIED]

2010-10-21 Thread Kostik Belousov
On Thu, Oct 21, 2010 at 09:50:03AM -0700, Sean Bruno wrote:
 On Thu, 2010-10-21 at 05:48 -0700, Andriy Gapon wrote:
  on 20/10/2010 21:28 Sean Bruno said the following:
   I guess, I could replace the kernel on the CD and have them reburn it?
  
  That should work.
  BTW, here I described yet another way of building custom 
  recovery/installation
  CDs that I use:
  http://wiki.freebsd.org/AvgLiveCD
  
 
 Before I get started on this, it looks like something else is going on.
 
 Here is a panic + trace on the latest 9-current snap shot.  hammer
 time indeed.  
 
 Suggestions are welcome!
 
 
 http://people.freebsd.org/~sbruno/9-current-panic.png
 
 http://people.freebsd.org/~sbruno/9-current-trace-panic.png

It feels like msgbufp variable has absurd value. Can you arrange
to get the output of verbose boot, esp. the SMAP lines ?
Also, you could add printfs near amd64/amd64/machdep.c:1517
/* Map the message buffer. */
msgbufp = (struct msgbuf *)PHYS_TO_DMAP(phys_avail[pa_indx]);
to show the values of all participants, i.e. msgbufp, pa_indx
and phys_avail[pa_indx].


pgpl9NWXh3FQ7.pgp
Description: PGP signature


Re: BIOS limitations on size of bootable zpool?

2010-10-21 Thread Matthew Seaman
On 21/10/2010 18:32, Emil Smolenski wrote:
  I think I've encountered the same problem as you. In my configuration
 there is also HP server with HP SmartArray with six disks configured as
 single disk RAID0 logical units. I don't think it is related to size of
 the pool (try to test with small GPT partitions -- for me it also
 doesn't work). I think it is something with this specific hardware and
 ZFS. I will provide more details soon, but for know could you test
 following configurations:
 - mirror (it works for me),
 - raidz(2) (it doesn't work for me),
 - raidz(2) but without SmartArray controller -- adX or adaX disks (it
 works for me).

Ah -- I'm afraid I can't do that.  This server is officially in
production use now (well, it would be if it was up) and contains a lot
of valuable data.  I'd be happy to back it up and try what you suggest,
but this machine is /the/ backup server...

I will note that we've had the machine running with (and booting from) a
raidz2 and a raidz1 over 6 drives, perfectly happily.  It's only when we
tried to double the available space and drives that it all went a bit
pear shaped.

 Please try 'status' command while seeing ZFS: i/o error... message.

H... will do.  Might be next week before I can report back though.

Cheers,

Matthew

-- 
Dr Matthew J Seaman MA, D.Phil.   7 Priory Courtyard
  Flat 3
PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate
JID: matt...@infracaninophile.co.uk   Kent, CT11 9PW



signature.asc
Description: OpenPGP digital signature


repeating crashes with 8.1

2010-10-21 Thread Randy Bush
FreeBSD 8.1-STABLE #2: Thu Oct 21 15:30:45 UTC 2010
r...@rip.psg.com:/usr/obj/usr/src/sys/RIP amd64

console recording

em0: discard frame w/o packet header
em0: discard frame w/o packet header
em0: discard frame w/o packet header
em0: discard frame w/o packet header
em0: discard frame w/o packet header
em0: discard frame w/o packet header
em0: discard frame w/o packet header
em0: discard frame w/o packet header
em0: discard frame w/o packet header
em0: discard frame w/o packet header
em0: discard frame w/o packet header
em0: discard frame w/o packet header
em0: discard frame w/o packet header
em0: discard frame w/o packet header
em0: discard frame w/o packet header
em0: discard frame w/o packet header
em0: discard frame w/o packet header
em0: discard frame w/o packet header
em0: discard frame w/o packet header
em0: discard frame w/o packet header
em0: discard frame w/o packet header
em0: discard frame w/o packet header
em0: discard frame w/o packet header
em0: discard frame w/o packet header
em0: discard frame w/o packet header
panic: sbflush_internal: cc 4294965301 || mb 0 || mbcnt 0
cpuid = 0
panic: bufwrite: buffer is not busy???


cpuid = 0
Fatal trap 12: page fault while in kernel mode
Uptime: cpuid = 2; 48mapic id = 02
36s
fault virtual address   = 0x8040
Physical memory: 4086 MB
fault code  = supervisor read data, page not present
Dumping 1647 MB:instruction pointer = 0x20:0x804c22ae
 (CTRL-C to abort) stack pointer= 0x28:0xff8de9a0
frame pointer   = 0x28:0xff8de9b0
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 0 (em0 taskq)
trap number = 12
 1632 1616 1600 1584 1568 1552 1536 1520 1504 1488 1472 1456 1440 1424 1408 
1392 1376 1360 1344 1328 1312 1296 1280 1264 1248 1232 1216 1200 1184 1168 1152 
1136 1120 1104 1088 1072 1056 1040 1024 1008 992 976 960 944 928 912 896 880 
864 848 832 816 800 784 768 752 736 720 704 688 672 656 640 624 608 592 576 560 
544 528 512 496 480 464 448 432 416 400 384 368 352 336 320 304 288 272 256 240 
224 208 192 176 160 144 128 112 96 80 64 48 32 16Attempt to write outside dump 
device boundaries.

** DUMP FAILED (ERROR 6) **
Automatic reboot in 15 seconds - press a key on the console to abort
em0: Watchdog timeout -- resetting

and locked up.  required power cycle to reboot

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


Re: repeating crashes with 8.1

2010-10-21 Thread Jeremy Chadwick
On Thu, Oct 21, 2010 at 12:08:23PM -0700, Randy Bush wrote:
 FreeBSD 8.1-STABLE #2: Thu Oct 21 15:30:45 UTC 2010
 r...@rip.psg.com:/usr/obj/usr/src/sys/RIP amd64
 
 console recording
 
 em0: discard frame w/o packet header
 em0: discard frame w/o packet header
 em0: discard frame w/o packet header
 em0: discard frame w/o packet header
 em0: discard frame w/o packet header
 em0: discard frame w/o packet header
 em0: discard frame w/o packet header
 em0: discard frame w/o packet header
 em0: discard frame w/o packet header
 em0: discard frame w/o packet header
 em0: discard frame w/o packet header
 em0: discard frame w/o packet header
 em0: discard frame w/o packet header
 em0: discard frame w/o packet header
 em0: discard frame w/o packet header
 em0: discard frame w/o packet header
 em0: discard frame w/o packet header
 em0: discard frame w/o packet header
 em0: discard frame w/o packet header
 em0: discard frame w/o packet header
 em0: discard frame w/o packet header
 em0: discard frame w/o packet header
 em0: discard frame w/o packet header
 em0: discard frame w/o packet header
 em0: discard frame w/o packet header
 panic: sbflush_internal: cc 4294965301 || mb 0 || mbcnt 0
 cpuid = 0
 panic: bufwrite: buffer is not busy???
 
 
 cpuid = 0
 Fatal trap 12: page fault while in kernel mode
 Uptime: cpuid = 2; 48mapic id = 02
 36s
 fault virtual address   = 0x8040
 Physical memory: 4086 MB
 fault code  = supervisor read data, page not present
 Dumping 1647 MB:instruction pointer = 0x20:0x804c22ae
  (CTRL-C to abort) stack pointer= 0x28:0xff8de9a0
 frame pointer   = 0x28:0xff8de9b0
 code segment= base 0x0, limit 0xf, type 0x1b
 = DPL 0, pres 1, long 1, def32 0, gran 1
 processor eflags= interrupt enabled, resume, IOPL = 0
 current process = 0 (em0 taskq)
 trap number = 12
  1632 1616 1600 1584 1568 1552 1536 1520 1504 1488 1472 1456 1440 1424 1408 
 1392 1376 1360 1344 1328 1312 1296 1280 1264 1248 1232 1216 1200 1184 1168 
 1152 1136 1120 1104 1088 1072 1056 1040 1024 1008 992 976 960 944 928 912 896 
 880 864 848 832 816 800 784 768 752 736 720 704 688 672 656 640 624 608 592 
 576 560 544 528 512 496 480 464 448 432 416 400 384 368 352 336 320 304 288 
 272 256 240 224 208 192 176 160 144 128 112 96 80 64 48 32 16Attempt to write 
 outside dump device boundaries.
 
 ** DUMP FAILED (ERROR 6) **
 Automatic reboot in 15 seconds - press a key on the console to abort
 em0: Watchdog timeout -- resetting
 
 and locked up.  required power cycle to reboot

CC'ing Jack Vogel of Intel, who is currently re-working portions of the
em(4) driver.  I think taskq issue might be the thing he's fixing and
thus might have a workaround for you.

But we're going to need to know exactly what em(4) model you have.

Please provide dmesg output relevant to em0, and also pciconf -lvc
output for the em0@xxx device.

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

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


Re: repeating crashes with 8.1

2010-10-21 Thread Randy Bush
em0: Intel(R) PRO/1000 Network Connection 7.0.5 port 0x2000-0x201f mem 
0xe800-0xe801 irq 16 at device 0.0 on pci13

randy

Jeremy Chadwick wrote:
 
 On Thu, Oct 21, 2010 at 12:08:23PM -0700, Randy Bush wrote:
  FreeBSD 8.1-STABLE #2: Thu Oct 21 15:30:45 UTC 2010
  r...@rip.psg.com:/usr/obj/usr/src/sys/RIP amd64
  
  console recording
  
  em0: discard frame w/o packet header
  em0: discard frame w/o packet header
  em0: discard frame w/o packet header
  em0: discard frame w/o packet header
  em0: discard frame w/o packet header
  em0: discard frame w/o packet header
  em0: discard frame w/o packet header
  em0: discard frame w/o packet header
  em0: discard frame w/o packet header
  em0: discard frame w/o packet header
  em0: discard frame w/o packet header
  em0: discard frame w/o packet header
  em0: discard frame w/o packet header
  em0: discard frame w/o packet header
  em0: discard frame w/o packet header
  em0: discard frame w/o packet header
  em0: discard frame w/o packet header
  em0: discard frame w/o packet header
  em0: discard frame w/o packet header
  em0: discard frame w/o packet header
  em0: discard frame w/o packet header
  em0: discard frame w/o packet header
  em0: discard frame w/o packet header
  em0: discard frame w/o packet header
  em0: discard frame w/o packet header
  panic: sbflush_internal: cc 4294965301 || mb 0 || mbcnt 0
  cpuid = 0
  panic: bufwrite: buffer is not busy???
  
  
  cpuid = 0
  Fatal trap 12: page fault while in kernel mode
  Uptime: cpuid = 2; 48mapic id = 02
  36s
  fault virtual address   = 0x8040
  Physical memory: 4086 MB
  fault code  = supervisor read data, page not present
  Dumping 1647 MB:instruction pointer = 0x20:0x804c22ae
   (CTRL-C to abort) stack pointer= 0x28:0xff8de9a0
  frame pointer   = 0x28:0xff8de9b0
  code segment= base 0x0, limit 0xf, type 0x1b
  = DPL 0, pres 1, long 1, def32 0, gran 1
  processor eflags= interrupt enabled, resume, IOPL = 0
  current process = 0 (em0 taskq)
  trap number = 12
   1632 1616 1600 1584 1568 1552 1536 1520 1504 1488 1472 1456 1440 1424 1408 
  1392 1376 1360 1344 1328 1312 1296 1280 1264 1248 1232 1216 1200 1184 1168 
  1152 1136 1120 1104 1088 1072 1056 1040 1024 1008 992 976 960 944 928 912 
  896 880 864 848 832 816 800 784 768 752 736 720 704 688 672 656 640 624 608 
  592 576 560 544 528 512 496 480 464 448 432 416 400 384 368 352 336 320 304 
  288 272 256 240 224 208 192 176 160 144 128 112 96 80 64 48 32 16Attempt to 
  write outside dump device boundaries.
  
  ** DUMP FAILED (ERROR 6) **
  Automatic reboot in 15 seconds - press a key on the console to abort
  em0: Watchdog timeout -- resetting
  
  and locked up.  required power cycle to reboot
 
 CC'ing Jack Vogel of Intel, who is currently re-working portions of the
 em(4) driver.  I think taskq issue might be the thing he's fixing and
 thus might have a workaround for you.
 
 But we're going to need to know exactly what em(4) model you have.
 
 Please provide dmesg output relevant to em0, and also pciconf -lvc
 output for the em0@xxx device.
 
 -- 
 | Jeremy Chadwick   j...@parodius.com |
 | Parodius Networking   http://www.parodius.com/ |
 | UNIX Systems Administrator  Mountain View, CA, USA |
 | Making life hard for others since 1977.  PGP: 4BD6C0CB |
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org


Re: repeating crashes with 8.1

2010-10-21 Thread Randy Bush
 I need to know which hardware it is and that doesnt show me.

how do i find out.

 em0: Intel(R) PRO/1000 Network Connection 7.0.5 port 0x2000-0x201f mem
 0xe800-0xe801 irq 16 at device 0.0 on pci13

joel, do you know?

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


Re: repeating crashes with 8.1

2010-10-21 Thread Mike Tancsa

At 06:51 PM 10/21/2010, Randy Bush wrote:

 I need to know which hardware it is and that doesnt show me.

how do i find out.



pciconf -lvc
It will show something like

e...@pci0:10:0:0:class=0x02 card=0x34ec8086 
chip=0x10d38086 rev=0x00 hdr=0x00

vendor = 'Intel Corporation'
device = 'Intel 82574L Gigabit Ethernet Controller (82574L)'
class  = network
subclass   = ethernet
cap 01[c8] = powerspec 2  supports D0 D3  current D0
cap 05[d0] = MSI supports 1 message, 64 bit
cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1)
cap 11[a0] = MSI-X supports 5 messages in map 0x1c enabled
ecap 0001[100] = AER 1 0 fatal 0 non-fatal 0 corrected
ecap 0003[140] = Serial 1 001517ed68a4

also, look at /var/run/dmesg.boot.  Sometimes the acpi info will tell 
you the MB type

e.g.  on one of my boxes, I have

ACPI APIC Table: INTEL  S3420GPX

with is the exact MB type.

---Mike





 em0: Intel(R) PRO/1000 Network Connection 7.0.5 port 0x2000-0x201f mem
 0xe800-0xe801 irq 16 at device 0.0 on pci13

joel, do you know?

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



Mike Tancsa,  tel +1 519 651 3400
Sentex Communications,m...@sentex.net
Providing Internet since 1994www.sentex.net
Cambridge, Ontario Canada www.sentex.net/mike

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


Re: repeating crashes with 8.1

2010-10-21 Thread Jack Vogel
pciconf -l

I need to know which hardware it is and that doesnt show me.

Jack


On Thu, Oct 21, 2010 at 3:28 PM, Randy Bush ra...@psg.com wrote:

 em0: Intel(R) PRO/1000 Network Connection 7.0.5 port 0x2000-0x201f mem
 0xe800-0xe801 irq 16 at device 0.0 on pci13

 randy

 Jeremy Chadwick wrote:
 
  On Thu, Oct 21, 2010 at 12:08:23PM -0700, Randy Bush wrote:
   FreeBSD 8.1-STABLE #2: Thu Oct 21 15:30:45 UTC 2010
   r...@rip.psg.com:/usr/obj/usr/src/sys/RIP amd64
  
   console recording
  
   em0: discard frame w/o packet header
   em0: discard frame w/o packet header
   em0: discard frame w/o packet header
   em0: discard frame w/o packet header
   em0: discard frame w/o packet header
   em0: discard frame w/o packet header
   em0: discard frame w/o packet header
   em0: discard frame w/o packet header
   em0: discard frame w/o packet header
   em0: discard frame w/o packet header
   em0: discard frame w/o packet header
   em0: discard frame w/o packet header
   em0: discard frame w/o packet header
   em0: discard frame w/o packet header
   em0: discard frame w/o packet header
   em0: discard frame w/o packet header
   em0: discard frame w/o packet header
   em0: discard frame w/o packet header
   em0: discard frame w/o packet header
   em0: discard frame w/o packet header
   em0: discard frame w/o packet header
   em0: discard frame w/o packet header
   em0: discard frame w/o packet header
   em0: discard frame w/o packet header
   em0: discard frame w/o packet header
   panic: sbflush_internal: cc 4294965301 || mb 0 || mbcnt 0
   cpuid = 0
   panic: bufwrite: buffer is not busy???
  
  
   cpuid = 0
   Fatal trap 12: page fault while in kernel mode
   Uptime: cpuid = 2; 48mapic id = 02
   36s
   fault virtual address   = 0x8040
   Physical memory: 4086 MB
   fault code  = supervisor read data, page not present
   Dumping 1647 MB:instruction pointer = 0x20:0x804c22ae
(CTRL-C to abort) stack pointer=
 0x28:0xff8de9a0
   frame pointer   = 0x28:0xff8de9b0
   code segment= base 0x0, limit 0xf, type 0x1b
   = DPL 0, pres 1, long 1, def32 0, gran 1
   processor eflags= interrupt enabled, resume, IOPL = 0
   current process = 0 (em0 taskq)
   trap number = 12
1632 1616 1600 1584 1568 1552 1536 1520 1504 1488 1472 1456 1440 1424
 1408 1392 1376 1360 1344 1328 1312 1296 1280 1264 1248 1232 1216 1200 1184
 1168 1152 1136 1120 1104 1088 1072 1056 1040 1024 1008 992 976 960 944 928
 912 896 880 864 848 832 816 800 784 768 752 736 720 704 688 672 656 640 624
 608 592 576 560 544 528 512 496 480 464 448 432 416 400 384 368 352 336 320
 304 288 272 256 240 224 208 192 176 160 144 128 112 96 80 64 48 32 16Attempt
 to write outside dump device boundaries.
  
   ** DUMP FAILED (ERROR 6) **
   Automatic reboot in 15 seconds - press a key on the console to abort
   em0: Watchdog timeout -- resetting
  
   and locked up.  required power cycle to reboot
 
  CC'ing Jack Vogel of Intel, who is currently re-working portions of the
  em(4) driver.  I think taskq issue might be the thing he's fixing and
  thus might have a workaround for you.
 
  But we're going to need to know exactly what em(4) model you have.
 
  Please provide dmesg output relevant to em0, and also pciconf -lvc
  output for the em0@xxx device.
 
  --
  | Jeremy Chadwick   j...@parodius.com |
  | Parodius Networking   http://www.parodius.com/ |
  | UNIX Systems Administrator  Mountain View, CA, USA |
  | Making life hard for others since 1977.  PGP: 4BD6C0CB |

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


Re: repeating crashes with 8.1

2010-10-21 Thread Joel Jaeggli
e...@pci0:13:0:0:   class=0x02 card=0x108c15d9 chip=0x108c8086 rev=0x03
hdr=0x00
vendor = 'Intel Corporation'
device = 'Intel Corporation 82573E Gigabit Ethernet Controller
(Copper) (82573E)'
class  = network
subclass   = ethernet
e...@pci0:14:0:0:   class=0x02 card=0x109a15d9 chip=0x109a8086 rev=0x00
hdr=0x00
vendor = 'Intel Corporation'
device = 'Intel PRO/1000 PL Network Adaptor (82573L)'
class  = network
subclass   = ethernet

whole machine is below

On 10/21/10 3:51 PM, Randy Bush wrote:
 I need to know which hardware it is and that doesnt show me.
 
 how do i find out.
 
 em0: Intel(R) PRO/1000 Network Connection 7.0.5 port 0x2000-0x201f mem
 0xe800-0xe801 irq 16 at device 0.0 on pci13
 
 joel, do you know?
 
 randy
 

rip.psg.com:/root# pciconf -lv
hos...@pci0:0:0:0:  class=0x06 card=0x988015d9 chip=0x27788086
rev=0xc0 hdr=0x00
vendor = 'Intel Corporation'
device = 'E7230/3000/3010 Processor to I/O Controller'
class  = bridge
subclass   = HOST-PCI
pc...@pci0:0:1:0:   class=0x060400 card=0x988015d9 chip=0x27798086
rev=0xc0 hdr=0x01
vendor = 'Intel Corporation'
device = 'E7230/3000/3010 PCIe Root Port'
class  = bridge
subclass   = PCI-PCI
pc...@pci0:0:3:0:   class=0x060400 card=0x988015d9 chip=0x277a8086
rev=0xc0 hdr=0x01
vendor = 'Intel Corporation'
device = '82975X PCIe Root Port'
class  = bridge
subclass   = PCI-PCI
pc...@pci0:0:28:0:  class=0x060400 card=0x988015d9 chip=0x27d08086
rev=0x01 hdr=0x01
vendor = 'Intel Corporation'
device = '82801G (ICH7 Family) PCIe Root Port'
class  = bridge
subclass   = PCI-PCI
pc...@pci0:0:28:4:  class=0x060400 card=0x988015d9 chip=0x27e08086
rev=0x01 hdr=0x01
vendor = 'Intel Corporation'
device = '82801GR/GH/GHM (ICH7 Family) PCIe Root Port'
class  = bridge
subclass   = PCI-PCI
pc...@pci0:0:28:5:  class=0x060400 card=0x988015d9 chip=0x27e28086
rev=0x01 hdr=0x01
vendor = 'Intel Corporation'
device = '82801GR/GH/GHM (ICH7 Family) PCIe Root Port'
class  = bridge
subclass   = PCI-PCI
uh...@pci0:0:29:0:  class=0x0c0300 card=0x988015d9 chip=0x27c88086
rev=0x01 hdr=0x00
vendor = 'Intel Corporation'
device = '82801G (ICH7 Family) USB Universal Host Controller'
class  = serial bus
subclass   = USB
uh...@pci0:0:29:1:  class=0x0c0300 card=0x988015d9 chip=0x27c98086
rev=0x01 hdr=0x00
vendor = 'Intel Corporation'
device = '82801G (ICH7 Family) USB Universal Host Controller'
class  = serial bus
subclass   = USB
uh...@pci0:0:29:2:  class=0x0c0300 card=0x988015d9 chip=0x27ca8086
rev=0x01 hdr=0x00
vendor = 'Intel Corporation'
device = '82801G (ICH7 Family) USB Universal Host Controller'
class  = serial bus
subclass   = USB
uh...@pci0:0:29:3:  class=0x0c0300 card=0x988015d9 chip=0x27cb8086
rev=0x01 hdr=0x00
vendor = 'Intel Corporation'
device = '82801G (ICH7 Family) USB Universal Host Controller'
class  = serial bus
subclass   = USB
eh...@pci0:0:29:7:  class=0x0c0320 card=0x988015d9 chip=0x27cc8086
rev=0x01 hdr=0x00
vendor = 'Intel Corporation'
device = '82801G (ICH7 Family) USB 2.0 Enhanced Host Controller'
class  = serial bus
subclass   = USB
pc...@pci0:0:30:0:  class=0x060401 card=0x988015d9 chip=0x244e8086
rev=0xe1 hdr=0x01
vendor = 'Intel Corporation'
device = '82801 Family (ICH2/3/4/5/6/7/8/9,63xxESB) Hub
Interface to PCI Bridge'
class  = bridge
subclass   = PCI-PCI
is...@pci0:0:31:0:  class=0x060100 card=0x988015d9 chip=0x27b88086
rev=0x01 hdr=0x00
vendor = 'Intel Corporation'
device = 'Intel 82801GB/GR (ICH7 Family) LPC Interface
Controller - 27B8 (945GL)'
class  = bridge
subclass   = PCI-ISA
atap...@pci0:0:31:1:class=0x01018a card=0x988015d9 chip=0x27df8086
rev=0x01 hdr=0x00
vendor = 'Intel Corporation'
device = '82801G (ICH7 Family) Ultra ATA Storage Controller'
class  = mass storage
subclass   = ATA
atap...@pci0:0:31:2:class=0x01018f card=0x988015d9 chip=0x27c08086
rev=0x01 hdr=0x00
vendor = 'Intel Corporation'
device = '82801GB/GR/GH (ICH7 Family) Serial ATA Storage Controller'
class  = mass storage
subclass   = ATA
no...@pci0:0:31:3:  class=0x0c0500 card=0x988015d9 chip=0x27da8086
rev=0x01 hdr=0x00
vendor = 'Intel Corporation'
device = 'Intel[R] 82801G (ICH7 Family) C- 27DA (82801G)'
class  = serial bus
subclass   = SMBus
e...@pci0:13:0:0:   class=0x02 card=0x108c15d9 chip=0x108c8086 rev=0x03
hdr=0x00
vendor = 'Intel Corporation'
device = 'Intel Corporation 82573E Gigabit Ethernet Controller
(Copper) (82573E)'
class  = network
subclass   = ethernet

Re: repeating crashes with 8.1

2010-10-21 Thread Jeremy Chadwick
On Thu, Oct 21, 2010 at 03:28:41PM -0700, Randy Bush wrote:
 em0: Intel(R) PRO/1000 Network Connection 7.0.5 port 0x2000-0x201f mem 
 0xe800-0xe801 irq 16 at device 0.0 on pci13
 
 randy
 
 Jeremy Chadwick wrote:
  
  On Thu, Oct 21, 2010 at 12:08:23PM -0700, Randy Bush wrote:
   FreeBSD 8.1-STABLE #2: Thu Oct 21 15:30:45 UTC 2010
   r...@rip.psg.com:/usr/obj/usr/src/sys/RIP amd64
   
   console recording
   
   em0: discard frame w/o packet header
   em0: discard frame w/o packet header
   em0: discard frame w/o packet header
   em0: discard frame w/o packet header
   em0: discard frame w/o packet header
   em0: discard frame w/o packet header
   em0: discard frame w/o packet header
   em0: discard frame w/o packet header
   em0: discard frame w/o packet header
   em0: discard frame w/o packet header
   em0: discard frame w/o packet header
   em0: discard frame w/o packet header
   em0: discard frame w/o packet header
   em0: discard frame w/o packet header
   em0: discard frame w/o packet header
   em0: discard frame w/o packet header
   em0: discard frame w/o packet header
   em0: discard frame w/o packet header
   em0: discard frame w/o packet header
   em0: discard frame w/o packet header
   em0: discard frame w/o packet header
   em0: discard frame w/o packet header
   em0: discard frame w/o packet header
   em0: discard frame w/o packet header
   em0: discard frame w/o packet header
   panic: sbflush_internal: cc 4294965301 || mb 0 || mbcnt 0
   cpuid = 0
   panic: bufwrite: buffer is not busy???
   
   
   cpuid = 0
   Fatal trap 12: page fault while in kernel mode
   Uptime: cpuid = 2; 48mapic id = 02
   36s
   fault virtual address   = 0x8040
   Physical memory: 4086 MB
   fault code  = supervisor read data, page not present
   Dumping 1647 MB:instruction pointer = 0x20:0x804c22ae
(CTRL-C to abort) stack pointer= 0x28:0xff8de9a0
   frame pointer   = 0x28:0xff8de9b0
   code segment= base 0x0, limit 0xf, type 0x1b
   = DPL 0, pres 1, long 1, def32 0, gran 1
   processor eflags= interrupt enabled, resume, IOPL = 0
   current process = 0 (em0 taskq)
   trap number = 12
1632 1616 1600 1584 1568 1552 1536 1520 1504 1488 1472 1456 1440 1424 
   1408 1392 1376 1360 1344 1328 1312 1296 1280 1264 1248 1232 1216 1200 
   1184 1168 1152 1136 1120 1104 1088 1072 1056 1040 1024 1008 992 976 960 
   944 928 912 896 880 864 848 832 816 800 784 768 752 736 720 704 688 672 
   656 640 624 608 592 576 560 544 528 512 496 480 464 448 432 416 400 384 
   368 352 336 320 304 288 272 256 240 224 208 192 176 160 144 128 112 96 80 
   64 48 32 16Attempt to write outside dump device boundaries.
   
   ** DUMP FAILED (ERROR 6) **
   Automatic reboot in 15 seconds - press a key on the console to abort
   em0: Watchdog timeout -- resetting
   
   and locked up.  required power cycle to reboot
  
  CC'ing Jack Vogel of Intel, who is currently re-working portions of the
  em(4) driver.  I think taskq issue might be the thing he's fixing and
  thus might have a workaround for you.
  
  But we're going to need to know exactly what em(4) model you have.
  
  Please provide dmesg output relevant to em0, and also pciconf -lvc
  output for the em0@xxx device.

Randy, please read my last paragraph again.  :-)

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

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