Re: RFT: ZFS MFC
On Fri, May 15, 2009 at 05:02:22PM -0700, Kip Macy wrote: I've MFC'd ZFS v13 to RELENG_7 in a work branch. Please test if you can. http://svn.freebsd.org/base/user/kmacy/ZFS_MFC/ The standard disclaimers apply. This has only been lightly tested in a VM. Please do not use it with data you care about at this time. Thanks, Kip Seems to work for me so far. I had a zfs send hang part way through and with a notable speed difference depending on the direction but this is literally the first time I've tried zfs send/recv and the systems are setup different so I have no idea if it would have happened anyway. Eventually I could probably make these test systems more similar to give a fair test, but wanted to mention it so others could check. Thanks for working on the MFC, I'm excited to see progress there! It will play a factor in some upcoming server plans even if the MFC doesn't happen for months. ___ 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: issues with Intel Pro/1000 and 1000baseTX
On Fri, May 15, 2009 at 06:01:33PM -0300, Nenhum_de_Nos wrote: I know this is a bit off, but as I never had CAT6 stuff to deal with here it goes. is there any problems in using CAT6 cabling and not 1000baseTX capable switch ? I plan to install cat6 cables and just use 1000baseTX in future. this will be my new home network and all I have now is 100baseTX and two 1000baseT cards. There should be no problem at all. CAT6 must meet higher standards, but the basic cable design is the same at CAT5, and it works for 100baseTX, and even for 10baseT (if you really wanted to use it). When my company relocated to a new building, the entire network was cabled at CAT6, but we still have some machines and switches that are 100baseTX, and they work fine. -- greg byshenk - gbysh...@byshenk.net - Leiden, NL ___ 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
[releng_6 tinderbox] failure on amd64/amd64
TB --- 2009-05-16 07:47:56 - tinderbox 2.6 running on freebsd-legacy.sentex.ca TB --- 2009-05-16 07:47:56 - starting RELENG_6 tinderbox run for amd64/amd64 TB --- 2009-05-16 07:47:56 - cleaning the object tree TB --- 2009-05-16 07:48:11 - cvsupping the source tree TB --- 2009-05-16 07:48:11 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_6/amd64/amd64/supfile TB --- 2009-05-16 07:48:18 - building world TB --- 2009-05-16 07:48:18 - MAKEOBJDIRPREFIX=/obj TB --- 2009-05-16 07:48:18 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-05-16 07:48:18 - TARGET=amd64 TB --- 2009-05-16 07:48:18 - TARGET_ARCH=amd64 TB --- 2009-05-16 07:48:18 - TZ=UTC TB --- 2009-05-16 07:48:18 - __MAKE_CONF=/dev/null TB --- 2009-05-16 07:48:18 - cd /src TB --- 2009-05-16 07:48:18 - /usr/bin/make -B buildworld Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries [...] cc -O2 -fno-strict-aliasing -pipe -I. -I/src/lib/libthread_db -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -c /src/lib/libthread_db/arch/amd64/libpthread_md.c /src/lib/libthread_db/arch/amd64/libpthread_md.c: In function `pt_fpreg_to_ucontext': /src/lib/libthread_db/arch/amd64/libpthread_md.c:94: warning: implicit declaration of function `memcpy' /src/lib/libthread_db/arch/amd64/libpthread_md.c:94: warning: nested extern declaration of `memcpy' internal:0: warning: redundant redeclaration of 'memcpy' /src/lib/libthread_db/arch/amd64/libpthread_md.c: In function `pt_ucontext_to_fpreg': /src/lib/libthread_db/arch/amd64/libpthread_md.c:100: warning: nested extern declaration of `memcpy' internal:0: warning: redundant redeclaration of 'memcpy' *** Error code 1 Stop in /src/lib/libthread_db. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-05-16 08:12:43 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-05-16 08:12:43 - ERROR: failed to build world TB --- 2009-05-16 08:12:43 - 1117.44 user 158.98 system 1487.13 real http://tinderbox.des.no/tinderbox-releng_6-RELENG_6-amd64-amd64.full ___ 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: Boot panic w/7.2-STABLE on amd64: resource_list_alloc
John Baldwin wrote: ... Sounds like the ATA driver is allocating the same BAR twice. Hmm, yes, it allocates the resources once for each channel it seems in the ata_ali_sata attachment. Looking in ata-chipset.c, all the other chipsets are good about allocating these resources in their chipinit routines rather than the per-channel allocate routine. Well, except ata_pci_allocate() is also busted. *sigh* I can work on a patch for HEAD if you are willing to test. Yes, ata is gnarly in places... If a fix can be dropped straight into a 7.2 tree, then that is even better... I could try testing a NanoBSD image of HEAD on this machine if the change set delta between branches is sufficiently huge to prevent backporting the fix; this is my desktop machine and this is the only critical bug I've run into so far with 7.2. thanks, BMS ___ 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: RFT: ZFS MFC
On 5/15/09 8:02 PM, Kip Macy wrote: I've MFC'd ZFS v13 to RELENG_7 in a work branch. Please test if you can. http://svn.freebsd.org/base/user/kmacy/ZFS_MFC/ The standard disclaimers apply. This has only been lightly tested in a VM. Please do not use it with data you care about at this time. Thanks, Kip I created a pool on 7.1, created some datasets, populated them, made some snapshots. Upgraded to v13 deleted a few snapshots, created a clone, promoted a clone, deleted and created some new datasets. So far so good. I'll try to make something break! ___ 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
[releng_6 tinderbox] failure on amd64/amd64
TB --- 2009-05-16 17:02:27 - tinderbox 2.6 running on freebsd-legacy.sentex.ca TB --- 2009-05-16 17:02:27 - starting RELENG_6 tinderbox run for amd64/amd64 TB --- 2009-05-16 17:02:27 - cleaning the object tree TB --- 2009-05-16 17:02:39 - cvsupping the source tree TB --- 2009-05-16 17:02:39 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_6/amd64/amd64/supfile TB --- 2009-05-16 17:02:46 - building world TB --- 2009-05-16 17:02:46 - MAKEOBJDIRPREFIX=/obj TB --- 2009-05-16 17:02:46 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-05-16 17:02:46 - TARGET=amd64 TB --- 2009-05-16 17:02:46 - TARGET_ARCH=amd64 TB --- 2009-05-16 17:02:46 - TZ=UTC TB --- 2009-05-16 17:02:46 - __MAKE_CONF=/dev/null TB --- 2009-05-16 17:02:46 - cd /src TB --- 2009-05-16 17:02:46 - /usr/bin/make -B buildworld Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries [...] cc -O2 -fno-strict-aliasing -pipe -I. -I/src/lib/libthread_db -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -c /src/lib/libthread_db/arch/amd64/libpthread_md.c /src/lib/libthread_db/arch/amd64/libpthread_md.c: In function `pt_fpreg_to_ucontext': /src/lib/libthread_db/arch/amd64/libpthread_md.c:94: warning: implicit declaration of function `memcpy' /src/lib/libthread_db/arch/amd64/libpthread_md.c:94: warning: nested extern declaration of `memcpy' internal:0: warning: redundant redeclaration of 'memcpy' /src/lib/libthread_db/arch/amd64/libpthread_md.c: In function `pt_ucontext_to_fpreg': /src/lib/libthread_db/arch/amd64/libpthread_md.c:100: warning: nested extern declaration of `memcpy' internal:0: warning: redundant redeclaration of 'memcpy' *** Error code 1 Stop in /src/lib/libthread_db. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-05-16 17:27:14 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-05-16 17:27:14 - ERROR: failed to build world TB --- 2009-05-16 17:27:14 - 1118.53 user 155.83 system 1486.74 real http://tinderbox.des.no/tinderbox-releng_6-RELENG_6-amd64-amd64.full ___ 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: Xorg hangs with drmwtq in 7.2-RELEASE
I don't know if this helps pinpointing my problem, but when I unload the drm module, I get the following message: May 15 19:57:52 radagast kernel: vgapci0: child drm0 requested pci_disable_busmaster May 15 19:57:52 radagast kernel: drm0: detached May 15 19:57:52 radagast kernel: Warning: memory type drm_bufs leaked memory on destroy (4 allocations, 128 bytes leaked). After this I can load the radeon and drm modules, but X will not start, complaining about no screen found. -- David Johnson ___ 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: uchcom and RELENG_7?
On Wed, 08 Apr 2009 19:00:18 +0200 Torfinn Ingolfsen torfinn.ingolf...@broadpark.no wrote: Hi, Is there any reason why uchcom[1] hasn't been MFC'ed to RELENG_7 yet? Anyone? uchcom doesn't seem to have made it into 7.2 either. I see discussion[2] about this subject as far back as around 7.0-release, but I can't find any uchcom.c files in my src, not even for latest RELENG_7. References: 1) http://www.freebsd.org/cgi/man.cgi?query=uchcomapropos=0sektion=0manpath=FreeBSD+8-currentformat=html 2) http://markmail.org/message/4w324qx4usmnd4ic#query:freebsd%20uchcom+page:1+mid:ecwpudhls4jqpr5s+state:results -- Regards, Torfinn Ingolfsen -- Regards, Torfinn Ingolfsen ___ 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: 7.2-STABLE: Inserting USB device causes Fatal Trap 12
On May 10, 2009, Norbert Papke wrote: Inserting a USB thumb drive into a running sytem result in a Fatal trap 12: page fault while in kernel mode. After repeating the crash a few times with INVARIANTS enabled, it becomes apparent that EHCI transfer queue is getting corrupted. With High Precision Event Timers disabled in the BIOS, the problem goes away. This is an acceptable work-around for me. I am inclined to believe (but unable to prove) that the crash is due to a BIOS bug. Cheers, -- Norbert Papke. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: RELENG_7 - has mergemaster changed logic since 7.2-RELEASE?
I think I now know what was causing the problem with the files being overwritten, the saved mtree database was somehow reduced to zero bytes causing the list of CHANGED files to be empty. Unfortunately I haven't tracked down the cause of why the mtree file would get emptied out (given that there is already code that should prevent that problem) but I have just committed r192230 which adds a lot of safety belts to the code involving creating and updating the mtree database, and creating and using the list of files with changes. It should no longer be possible to even enter the -U code unless there is both a valid mtree file AND a valid list of files with local changes. FWIW I've also improved the performance of the -U option by changing a use of grep for every file to using case. You should be able to grab the file from HEAD and run it on RELENG_[67] without any problems. I will MFC it as rapidly as possible. Sorry for the inconvenience, Doug -- This .signature sanitized for your protection ___ 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
Fear and loathing in FreeBSD 7.2 (AGP issues and fixes)
So. I decided to test FreeBSD 7.2 on my Averatec AV1020 ED1 laptop. (It
currently has 6.0-RELEASE on it, and while it runs fine, I figured now
was a good time to update it.) I ran into two problems with it, and I
thought it would be a good idea to share how I resolved them, just in
case anyone else is foolish enough to follow in my tracks.
The laptop has a RaLink RT2560 wireless chipset. The ral(4) driver
supports this chip out of the box, however that driver doesn't support
WPA2 Enterprise, which I need for work. To get around this, I use
the Windows NDIS driver with Project Evil. Unfortunately, the driver
that comes with the laptop (version 3.0.3.) is buggy, and will
trigger a kernel panic in certain conditions. It seems to have trouble
parsing information from certain newer kinds of devices, which causes
some of the code inside the driver binary to dereference a bogus pointer.
This is not a problem with FreeBSD or Project Evil: I discovered that
the same driver blue-screens Windows XP as well (a testament to just
how closely Project Evil emulates Windows: it even emulates its crashes).
Luckily there is a slightly newer driver available that fixes this issue
(3.1.0.000), though I had to hunt a bit to find it. I put copies of
the .SYS and .INF at:
http://www.freebsd.org/~wpaul/7_2_RELEASE/wifi
The other problems I had were with graphics. The Averatec has an Intel
82855GME graphics controller. With FreeBSD 6.0, I had it working nicely
with DRI and everything. With FreeBSD 7.2 and xorg 1.6.0, I saw some
peculiar problems.
The most glaring issue was that after running X -configure for the first
time and testing the resulting xorg.conf file, I found that the X server
would not respond to the mouse or keyboard. After some digging, I found
that this was due to the AutoAddDevices feature (described in xorg.conf(5))
being on by default. If AutoAddDevices is on, then AllowEmptyInput is also
turned on, but the description for AllowEmptyInput says: If AllowEmptyInput
is on, devices using the kbd, mouse or vmmouse driver are ignored. I
don't know what's supposed to happen instead, but it wasn't working. I
had to add:
Option AutoAddDevices False
to my xorg.conf to turn this off in order for my mouse and keyboard to
work.
On a related note, the X server seems to ignore a lot of what you put
in xorg.conf in favor of its autoselected defaults. I tried to use
DefaultDepth 24 to force the screen color depth, but it seems to
always ignore this and use a depth of 32 bits. It seems to work ok, but
I thought this was odd. If I tell it to do something, it should do it.
This used to work in earlier X releases.
More curiously, X -configure decided for some reason that my laptop
had two graphics cards instead of one. This apparently has to do with
the fact that the gracphic device has two PCI functions:
vgap...@pci0:0:2:0: class=0x03 card=0x031914ff chip=0x35828086 rev=0x02
hdr=0x00
vendor = 'Intel Corporation'
device = '82852GM/GME/GMV/PM, 855GM/GME Montara Integrated Graphics
Device'
class = display
subclass = VGA
vgap...@pci0:0:2:1: class=0x038000 card=0x031914ff chip=0x35828086 rev=0x02
hdr=0x00
vendor = 'Intel Corporation'
device = '82852GM/GME/GMV/PM, 855GM/GME Montara Integrated Graphics
Device'
class = display
X -configure created a Card and Screen section for both of these, even
though it should only have created one. I had to edit the xorg.conf to
remove the duplicates. (This was something else that worked correctly in
older versions of X.)
Once I settled those issues, the X server worked, but I found that I
was unable to use DRI. FreeBSD was correctly loading the agp, drm and
i915 drivers, but the X server refused to activate DRI support. According
to the Xorg.log.0 file, it was failing to allocate a couple of regions
of physical memory from the AGP driver. I finally traced this down to
the agp_i810 code in the kernel. In agp_i810_alloc_memory(), it says:
[...]
} else if (type == 2) {
/*
* Type 2 is the contiguous physical memory type, that hands
* back a physical address. This is used for cursors on i810.
* Hand back as many single pages with physical as the user
* wants, but only allow one larger allocation (ARGB cursor)
* for simplicity.
*/
if (size != AGP_PAGE_SIZE) {
if (sc-argb_cursor != NULL)
return 0;
[...]
I'm all for simplicity, but this is bogus: the Intel video driver wants
to allocate three ranges of physical memory for cursors, but only the
first one succeeds. Two additional allocates for 40K and 16K both fail
because of this code.
I ended up modifying agp_i810.c to deal with this, by allowing it to
allocate as many of these ranges as it wants. In the process of testing
this, I also ran into
Re: Fear and loathing in FreeBSD 7.2 (AGP issues and fixes)
On 5/17/09, Bill Paul wp...@freebsd.org wrote:
So. I decided to test FreeBSD 7.2 on my Averatec AV1020 ED1 laptop. (It
currently has 6.0-RELEASE on it, and while it runs fine, I figured now
was a good time to update it.) I ran into two problems with it, and I
thought it would be a good idea to share how I resolved them, just in
case anyone else is foolish enough to follow in my tracks.
The laptop has a RaLink RT2560 wireless chipset. The ral(4) driver
supports this chip out of the box, however that driver doesn't support
WPA2 Enterprise, which I need for work. To get around this, I use
the Windows NDIS driver with Project Evil. Unfortunately, the driver
that comes with the laptop (version 3.0.3.) is buggy, and will
trigger a kernel panic in certain conditions. It seems to have trouble
parsing information from certain newer kinds of devices, which causes
some of the code inside the driver binary to dereference a bogus pointer.
This is not a problem with FreeBSD or Project Evil: I discovered that
the same driver blue-screens Windows XP as well (a testament to just
how closely Project Evil emulates Windows: it even emulates its crashes).
Luckily there is a slightly newer driver available that fixes this issue
(3.1.0.000), though I had to hunt a bit to find it. I put copies of
the .SYS and .INF at:
http://www.freebsd.org/~wpaul/7_2_RELEASE/wifi
The other problems I had were with graphics. The Averatec has an Intel
82855GME graphics controller. With FreeBSD 6.0, I had it working nicely
with DRI and everything. With FreeBSD 7.2 and xorg 1.6.0, I saw some
peculiar problems.
The most glaring issue was that after running X -configure for the first
time and testing the resulting xorg.conf file, I found that the X server
would not respond to the mouse or keyboard. After some digging, I found
that this was due to the AutoAddDevices feature (described in xorg.conf(5))
being on by default. If AutoAddDevices is on, then AllowEmptyInput is also
turned on, but the description for AllowEmptyInput says: If AllowEmptyInput
is on, devices using the kbd, mouse or vmmouse driver are ignored. I
don't know what's supposed to happen instead, but it wasn't working. I
had to add:
Option AutoAddDevices False
to my xorg.conf to turn this off in order for my mouse and keyboard to
work.
On a related note, the X server seems to ignore a lot of what you put
in xorg.conf in favor of its autoselected defaults. I tried to use
DefaultDepth 24 to force the screen color depth, but it seems to
always ignore this and use a depth of 32 bits. It seems to work ok, but
I thought this was odd. If I tell it to do something, it should do it.
This used to work in earlier X releases.
Well, at least with intel driver on i915GM using anything lower than
defaults will cause interesting artefacts on various games: alephone oolite.
More curiously, X -configure decided for some reason that my laptop
had two graphics cards instead of one. This apparently has to do with
the fact that the gracphic device has two PCI functions:
vgap...@pci0:0:2:0: class=0x03 card=0x031914ff chip=0x35828086
rev=0x02 hdr=0x00
vendor = 'Intel Corporation'
device = '82852GM/GME/GMV/PM, 855GM/GME Montara Integrated Graphics
Device'
class = display
subclass = VGA
vgap...@pci0:0:2:1: class=0x038000 card=0x031914ff chip=0x35828086
rev=0x02 hdr=0x00
vendor = 'Intel Corporation'
device = '82852GM/GME/GMV/PM, 855GM/GME Montara Integrated Graphics
Device'
class = display
X -configure created a Card and Screen section for both of these, even
though it should only have created one. I had to edit the xorg.conf to
remove the duplicates. (This was something else that worked correctly in
older versions of X.)
Once I settled those issues, the X server worked, but I found that I
was unable to use DRI. FreeBSD was correctly loading the agp, drm and
i915 drivers, but the X server refused to activate DRI support. According
to the Xorg.log.0 file, it was failing to allocate a couple of regions
of physical memory from the AGP driver. I finally traced this down to
the agp_i810 code in the kernel. In agp_i810_alloc_memory(), it says:
[...]
} else if (type == 2) {
/*
* Type 2 is the contiguous physical memory type, that hands
* back a physical address. This is used for cursors on
i810.
* Hand back as many single pages with physical as the user
* wants, but only allow one larger allocation (ARGB cursor)
* for simplicity.
*/
if (size != AGP_PAGE_SIZE) {
if (sc-argb_cursor != NULL)
return 0;
[...]
I'm all for simplicity, but this is bogus: the Intel video driver wants
to allocate three ranges of physical memory for cursors,
Re: Fear and loathing in FreeBSD 7.2 (AGP issues and fixes)
On 5/17/09, Paul B. Mahol one...@gmail.com wrote:
On 5/17/09, Bill Paul wp...@freebsd.org wrote:
So. I decided to test FreeBSD 7.2 on my Averatec AV1020 ED1 laptop. (It
currently has 6.0-RELEASE on it, and while it runs fine, I figured now
was a good time to update it.) I ran into two problems with it, and I
thought it would be a good idea to share how I resolved them, just in
case anyone else is foolish enough to follow in my tracks.
The laptop has a RaLink RT2560 wireless chipset. The ral(4) driver
supports this chip out of the box, however that driver doesn't support
WPA2 Enterprise, which I need for work. To get around this, I use
the Windows NDIS driver with Project Evil. Unfortunately, the driver
that comes with the laptop (version 3.0.3.) is buggy, and will
trigger a kernel panic in certain conditions. It seems to have trouble
parsing information from certain newer kinds of devices, which causes
some of the code inside the driver binary to dereference a bogus pointer.
This is not a problem with FreeBSD or Project Evil: I discovered that
the same driver blue-screens Windows XP as well (a testament to just
how closely Project Evil emulates Windows: it even emulates its crashes).
Luckily there is a slightly newer driver available that fixes this issue
(3.1.0.000), though I had to hunt a bit to find it. I put copies of
the .SYS and .INF at:
http://www.freebsd.org/~wpaul/7_2_RELEASE/wifi
The other problems I had were with graphics. The Averatec has an Intel
82855GME graphics controller. With FreeBSD 6.0, I had it working nicely
with DRI and everything. With FreeBSD 7.2 and xorg 1.6.0, I saw some
peculiar problems.
The most glaring issue was that after running X -configure for the first
time and testing the resulting xorg.conf file, I found that the X server
would not respond to the mouse or keyboard. After some digging, I found
that this was due to the AutoAddDevices feature (described in
xorg.conf(5))
being on by default. If AutoAddDevices is on, then AllowEmptyInput is
also
turned on, but the description for AllowEmptyInput says: If
AllowEmptyInput
is on, devices using the kbd, mouse or vmmouse driver are ignored. I
don't know what's supposed to happen instead, but it wasn't working. I
had to add:
Option AutoAddDevices False
to my xorg.conf to turn this off in order for my mouse and keyboard to
work.
On a related note, the X server seems to ignore a lot of what you put
in xorg.conf in favor of its autoselected defaults. I tried to use
DefaultDepth 24 to force the screen color depth, but it seems to
always ignore this and use a depth of 32 bits. It seems to work ok, but
I thought this was odd. If I tell it to do something, it should do it.
This used to work in earlier X releases.
Well, at least with intel driver on i915GM using anything lower than
defaults will cause interesting artefacts on various games: alephone
oolite.
More curiously, X -configure decided for some reason that my laptop
had two graphics cards instead of one. This apparently has to do with
the fact that the gracphic device has two PCI functions:
vgap...@pci0:0:2:0: class=0x03 card=0x031914ff chip=0x35828086
rev=0x02 hdr=0x00
vendor = 'Intel Corporation'
device = '82852GM/GME/GMV/PM, 855GM/GME Montara Integrated
Graphics
Device'
class = display
subclass = VGA
vgap...@pci0:0:2:1: class=0x038000 card=0x031914ff chip=0x35828086
rev=0x02 hdr=0x00
vendor = 'Intel Corporation'
device = '82852GM/GME/GMV/PM, 855GM/GME Montara Integrated
Graphics
Device'
class = display
X -configure created a Card and Screen section for both of these,
even
though it should only have created one. I had to edit the xorg.conf to
remove the duplicates. (This was something else that worked correctly in
older versions of X.)
Once I settled those issues, the X server worked, but I found that I
was unable to use DRI. FreeBSD was correctly loading the agp, drm and
i915 drivers, but the X server refused to activate DRI support. According
to the Xorg.log.0 file, it was failing to allocate a couple of regions
of physical memory from the AGP driver. I finally traced this down to
the agp_i810 code in the kernel. In agp_i810_alloc_memory(), it says:
[...]
} else if (type == 2) {
/*
* Type 2 is the contiguous physical memory type, that
hands
* back a physical address. This is used for cursors on
i810.
* Hand back as many single pages with physical as the
user
* wants, but only allow one larger allocation (ARGB
cursor)
* for simplicity.
*/
if (size != AGP_PAGE_SIZE) {
if (sc-argb_cursor != NULL)
return 0;
[...]
I'm all for simplicity, but this is bogus: the Intel video driver
[releng_6 tinderbox] failure on amd64/amd64
TB --- 2009-05-17 02:02:24 - tinderbox 2.6 running on freebsd-legacy.sentex.ca TB --- 2009-05-17 02:02:24 - starting RELENG_6 tinderbox run for amd64/amd64 TB --- 2009-05-17 02:02:24 - cleaning the object tree TB --- 2009-05-17 02:02:45 - cvsupping the source tree TB --- 2009-05-17 02:02:45 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_6/amd64/amd64/supfile TB --- 2009-05-17 02:02:55 - building world TB --- 2009-05-17 02:02:55 - MAKEOBJDIRPREFIX=/obj TB --- 2009-05-17 02:02:55 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-05-17 02:02:55 - TARGET=amd64 TB --- 2009-05-17 02:02:55 - TARGET_ARCH=amd64 TB --- 2009-05-17 02:02:55 - TZ=UTC TB --- 2009-05-17 02:02:55 - __MAKE_CONF=/dev/null TB --- 2009-05-17 02:02:55 - cd /src TB --- 2009-05-17 02:02:55 - /usr/bin/make -B buildworld Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries [...] cc -O2 -fno-strict-aliasing -pipe -I. -I/src/lib/libthread_db -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -c /src/lib/libthread_db/arch/amd64/libpthread_md.c /src/lib/libthread_db/arch/amd64/libpthread_md.c: In function `pt_fpreg_to_ucontext': /src/lib/libthread_db/arch/amd64/libpthread_md.c:94: warning: implicit declaration of function `memcpy' /src/lib/libthread_db/arch/amd64/libpthread_md.c:94: warning: nested extern declaration of `memcpy' internal:0: warning: redundant redeclaration of 'memcpy' /src/lib/libthread_db/arch/amd64/libpthread_md.c: In function `pt_ucontext_to_fpreg': /src/lib/libthread_db/arch/amd64/libpthread_md.c:100: warning: nested extern declaration of `memcpy' internal:0: warning: redundant redeclaration of 'memcpy' *** Error code 1 Stop in /src/lib/libthread_db. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-05-17 02:27:09 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-05-17 02:27:09 - ERROR: failed to build world TB --- 2009-05-17 02:27:09 - 1120.33 user 157.60 system 1484.60 real http://tinderbox.des.no/tinderbox-releng_6-RELENG_6-amd64-amd64.full ___ 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: RFT: ZFS MFC
On May 16, 2009, at 8:50 AM, Adam McDougall wrote: On Fri, May 15, 2009 at 05:02:22PM -0700, Kip Macy wrote: I've MFC'd ZFS v13 to RELENG_7 in a work branch. Please test if you can. http://svn.freebsd.org/base/user/kmacy/ZFS_MFC/ The standard disclaimers apply. This has only been lightly tested in a VM. Please do not use it with data you care about at this time. Thanks, Kip Seems to work for me so far. I had a zfs send hang part way through and with a notable speed difference depending on the direction but this is literally the first time I've tried zfs send/recv and the systems are setup different so I have no idea if it would have happened anyway. Eventually I could probably make these test systems more similar to give a fair test, but wanted to mention it so others could check. Thanks for working on the MFC, I'm excited to see progress there! It will play a factor in some upcoming server plans even if the MFC doesn't happen for months. ___ 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 We're now testing ZFS under FreeBSD (7.2 and CURRENT) quite extensively, because our primary goal is to setup a fileserver that can scale up to 80TB using high-density, low-cost storage (2TB SATA II disks in a 42 bay, 4 unit storage). The fact that ZFS v13 has been MFC'ed sounds good to me. I'd like to recommend to test the most basic physical stress conditions, eg: - Pulling out one healthy disk in a raidz2 pool; - Pulling it back and see if resilvering starts in a reasonable time (we experienced consolle locks, access via SSH to the box was still possible and fully responsive); - Pulling out TWO healthy disks in a raidz2 pool; - Pulling them back one at a time (and two at the same time) and see if the pool is resilvered in a reasonable time; - Too many combinations to be listed here. I'll be more than happy if the FreeBSD community will came out with a sort of ZFS standard stress test suite (both physical and logical), in order to be able to compare the ZFS reliability when used in different scenarios (eg: our scenario is made of a v20Z server with 6Gb RAM directly attached via a 2Gb Qlogic Fibre Channel adapter, the JBOD is an Apple Xraid fully loaded with 450Gb PATA disks, all sysctl parameters set accordingly to the ZFS tuning guide). I'm strongly conviced that, for a number of reasons, FreeBSD + ZFS can be the silver bullet in the enterprise storage just because of the following: PROS: - Solaris/OpenSolaris are limited to an NGROUPS_MAX value of 16 (http://bugs.opensolaris.org/view_bug.do?bug_id=4088757 , http://www.j3e.de/ngroups.html) while FreeBSD isn't (we are using an NGROUPS_MAX value of 64 right now). This is a good point if you are serving hundreds of clients, authenticated via LDAP (Posix accounts RFC 2307) and you are living in a mixed shop (MACs and PCs.. like we do); - Apple is introducing ZFS support on non-bootable storage under OS X 10.6 but nobody really knows what ZFS version will be made available; - License constraints on Linux. ZFS can't be used in kernel mode, only using FUSE at the price of degraded performance (AFAIK); - Maybe I'm missing something but it's ok since I'm slightly drunk as of now. Please help (by suggesting missing points, not by suggesting me to refrain from drinking on Saturday's night ;-). CONS: - FreeBSD is currently lacking an enterprise-level support for modern 4Gb Fibre Channel HBAs, as you can read here: http://lists.freebsd.org/pipermail/freebsd-scsi/2009-April/date.html#3876 -- No reply, AFAIK; http://lists.freebsd.org/pipermail/freebsd-scsi/2008-October/003686.html http://lists.freebsd.org/pipermail/freebsd-scsi/2008-November/003705.html http://lists.freebsd.org/pipermail/freebsd-stable/2008-November/046556.html http://lists.freebsd.org/pipermail/freebsd-stable/2008-November/046602.html Before throwing rotting tomatoes straight to me please consider the following facts: - Our infrastructure is 90% based on FreeBSD. It has proven to be rock solid over a 7 year timespan. Are we happy ? Definitely yes.; - We are grateful to the FreeBSD community, this mail should be intended as a constructive criticism in order to exploit a sweet spot in storage enterprise. This can dramatically leverage the adoption of FreeBSD in the enterprise, if we consider the fact that, due to the global crisis, most enterprises will start to look at low- cost, highly reliable, higly scalable storage systems; - We are also grateful to the Pawel Jakub Dawidek and all the other FreeBSD ZFS contributors, you are doing a great job guys, thanks. What can I do to foster this trend, and being able to further enhance the ZFS support under FreeBSD, provided that we cannot contribute coding skills ? Unfortunately not
