Re: MCP55 SATA solution to test

2009-10-25 Thread Marco Bröder
On Sun October 25 2009 02:46:57 Alexander Motin wrote:
> Hi.
> 
> Thanks to one man who provided access to his machine, I seem to found
> how to fix device detection on nVidia MCP55 SATA controller on amd64
> 8.0. Looks like this controller need some time (very short) to enable
> BAR(5) memory access after PCI configuration register written. Probably
> some changes in PCI code exposed this issue. Also it explains why
> setting hw.pci.mcfg to 0 helps.
> 
> Attached patch solves problem for that machine. Testers are welcome.
> 

Success! I tested your patch and everything is working fine
with hw.pci.mcfg set to 1, now. Please commit it.

Many thanks!

-- 
Regards,
Marco Bröder 
OpenPGP key fingerprint: 5615 106E 031A F3D3 64CC 0F9E 4DCE 6524 F595 082F
___
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"


zfs receive gives: internal error: Argument list too long

2009-10-25 Thread Ronald Klop

Hi,

Making a backup to my external USB-disk now fails with the following  
output.


[r...@sjakie ~]# zfs send -vi tank/h...@repl-20090919_195900  
tank/h...@repl-20090921_195900 > /bla.snapshot


# ls -lh /bla*
-rw-r--r--  1 root  wheel   547M Oct 25 20:44 /bla.snapshot

[r...@sjakie ~]# zfs receive -F extern/home < /bla.snapshot
internal error: Argument list too long
Abort trap: 6 (core dumped)

# uname -a
FreeBSD sjakie.klop.ws 8.0-RC1 FreeBSD 8.0-RC1 #6: Wed Oct 21 00:57:07  
CEST 2009 r...@sjakie.klop.ws:/usr/obj/usr/src/sys/GENERIC  amd64


I have two pools 'tank' and 'extern'. I send/recieve several volumes from  
tank to extern.

zpool is version 13 and zfs is version 3

Searching the internet I found this link:
http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6573681

Is this a known bug for freebsd also?
Can anybody help me in continuing my snapshotting process? (Except making  
a new fresh snapshot, which is my last option.)


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


Re: zfs receive gives: internal error: Argument list too long

2009-10-25 Thread Ronald Klop
On Sun, 25 Oct 2009 20:54:48 +0100, Ronald Klop  
 wrote:



Hi,

Making a backup to my external USB-disk now fails with the following  
output.


[r...@sjakie ~]# zfs send -vi tank/h...@repl-20090919_195900  
tank/h...@repl-20090921_195900 > /bla.snapshot


# ls -lh /bla*
-rw-r--r--  1 root  wheel   547M Oct 25 20:44 /bla.snapshot

[r...@sjakie ~]# zfs receive -F extern/home < /bla.snapshot
internal error: Argument list too long
Abort trap: 6 (core dumped)

# uname -a
FreeBSD sjakie.klop.ws 8.0-RC1 FreeBSD 8.0-RC1 #6: Wed Oct 21 00:57:07  
CEST 2009 r...@sjakie.klop.ws:/usr/obj/usr/src/sys/GENERIC  amd64


I have two pools 'tank' and 'extern'. I send/recieve several volumes  
from tank to extern.

zpool is version 13 and zfs is version 3

Searching the internet I found this link:
http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6573681


I meant: http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6801979


Is this a known bug for freebsd also?
Can anybody help me in continuing my snapshotting process? (Except  
making a new fresh snapshot, which is my last option.)


Ronald.

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


[panic] Finally got a crash report

2009-10-25 Thread Glen Barber
Howdy,

Since I got this laptop, I've been having some issues I could not
track.  Usually the system will completely lock up, no keyboard,
mouse, etc, leaving me with no way to break to the debugger, forcing
me to power off completely.

Something changed recently, and although the machine locked up again,
I was able to get a crash report[1].  The kernel config the crash
report mentions is available as well[2].

I can usually trigger it with excessive disk IO, but this time I was
editing a file in Vim.  Any thoughts?

[1] - http://freebsd.dev-urandom.com/ports/20091025.core.txt
[2] - http://freebsd.dev-urandom.com/ports/PEGASUS

-- 
Glen Barber
___
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: i am desperate over some GPT tables

2009-10-25 Thread Robert Noland
On Sun, 2009-10-25 at 16:44 +, Kris Weston wrote:
> hi Robert appreciate you having a look at this,
> if you need any funny noises ever, give us a shout :)
> i really dont know what to do as i dont have a spare box to try out solaris
> on and solaris wont boot fully here...
> i did manage to export the drives from solaris first so all *should* be
> well...
> there are three disks in the set ad4,ad6,ad8
> terrabyte each - they are supposed to be two mirrors but one disk went down
> should still work though - well was working in solaris...
> as i said before it at least could read the pools from freebsd before but
> something has happened now where it wont...
> 
> i think 4+6 are a mirror...
> let me know if you can shed any light...
> out of interest - how do you look at these dumps ? and what are you looking
> for ?

Ok, we have a couple of options What I have done so far is to hex
edit your GPT headers, though technically they are valid.  Sector 2 is
the GPT header and normally the header length is recorded as 92 bytes.
Yours claim that the header it 512 bytes or the entire sector.  The
crc32 value is calculated based on byte 0 - header size.  Our GPT code
is performing the crc comparison based on the 92 valid bytes in the
header along with 512 - 92 bytes of random memory, so the header crc
fails and GEOM refuses the header.

We need to fix the GPT code to handle this correctly, so you can give me
a little time to fix it correctly, or we can just fix your existing GPT
headers to work with our code...

Before:
GEOM: md6: corrupt or invalid GPT detected.
GEOM: md6: GPT rejected -- may not be recoverable.

After:
GEOM: md6: the secondary GPT table is corrupt or invalid.
GEOM: md6: using the primary only -- recovery suggested.

=>34  1953525101  md6  GPT  (466T)
  34 222   - free -  (111K)
 256  19535084951  !6a898cc3-1dd2-11b2-99a6-080020736631  (932G)
  1953508751   163849  !6a945a3b-1dd2-11b2-99a6-080020736631  (8.0M)

Hopefully I don't need to tell you proceed with caution here, but if you
want to rewrite the headers, I've attached 6 files which contain the
modified primary and secondary headers.

The seek values below for the secondary header are calculated for your
drive.  Make sure that you use the correct header for the correct drive
and pri/sec.

dd if=headeradX-pri.dmp of=/dev/adX bs=512 seek=1
dd if=headeradX-sec.dmp of=/dev/adX bs=512 seek=1953525167

robert.

> thanks
> 
> Kris
> --
> 
>))
>   ((
> c[_]
> 
> 
> 2009/10/23 Robert Noland 
> 
> > On Wed, 2009-10-21 at 13:11 +0100, Kris Weston wrote:
> > > been looking for months now, trawled google no help, i just dont
> > understand.
> > > do you need a GPT table with zfs ?
> > > i have a pentium D 3ghz (running 64bit stable 7.2) and i cant seem to
> > import
> > > my zpool into it
> > > exported fine on solaris , its definitely the same version (v13)
> > > but when i import into zfs it says GPT tables corrupt ?
> > > why ? and what does this mean ?
> > > please help me. please.
> >
> > Send me the fist 34 sectors of the disk and I will try to take a look.
> >
> > dd if= of=header.dmp bs=512 count=34
> >
> > robert.
> >
> > > --
> > >
> > >))
> > >   ((
> > > c[_]
> > > ___
> > > 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
> > "
> > --
> > Robert Noland 
> > FreeBSD
> >
> >
> ___
> 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"
-- 
Robert Noland 
FreeBSD


headerad4-pri.dmp
Description: Binary data


headerad4-sec.dmp
Description: Binary data


headerad6-pri.dmp
Description: Binary data


headerad6-sec.dmp
Description: Binary data


headerad8-pri.dmp
Description: Binary data


headerad8-sec.dmp
Description: Binary data
___
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"