Re: bin/144214: zfsboot fails on gang block after upgrade to zfs v14
Andriy Gapon wrote:
I think I nailed this problem now.
What was additionally needed was the following change:
if (!vdev || !vdev-v_read)
return (EIO);
- if (vdev-v_read(vdev, bp, zio_gb, offset, SPA_GANGBLOCKSIZE))
+ if (vdev-v_read(vdev, NULL, zio_gb, offset, SPA_GANGBLOCKSIZE))
return (EIO);
Full patch is here:
http://people.freebsd.org/~avg/boot-zfs-gang.diff
Apparently I am not as smart as Roman :) because I couldn't find the bug by just
starring at this rather small function (for couple of hours), so I had to
reproduce the problem to catch it. Hence I am copying hackers@ to share couple
of tricks that were new to me. Perhaps, they could help someone else some other
day.
Excellent, I'm glad that this is finally tested and seems to be working.
When I initially added the code, I wasn't able to test it and it
turned out the the issue that I was trying to resolve wasn't actually
gang block related anyway.
robert.
First, after very helpful hints that I received in parallel from pjd and two
Oracle/Sun developers it became very easy to reproduce a pool with files with
gang blocks in them.
One can set metaslab_gang_bang variable in metaslab.c to some value 128K and
then blocks with size greater than metaslab_gang_bang will be allocated as gang
blocks with 25% chance. I personally did something similar but slightly more
deterministic:
--- a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c
+++ b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c
@@ -1572,6 +1572,12 @@ zio_dva_allocate(zio_t *zio)
ASSERT3U(zio-io_prop.zp_ndvas, =, spa_max_replication(spa));
ASSERT3U(zio-io_size, ==, BP_GET_PSIZE(bp));
+ /*XXX XXX XXX XXX*/
+ if (zio-io_size 8 * 1024) {
+ return (zio_write_gang_block(zio));
+ }
+ /*XXX XXX XXX XXX*/
+
error = metaslab_alloc(spa, mc, zio-io_size, bp,
zio-io_prop.zp_ndvas, zio-io_txg, NULL, 0);
This ensured that any block 8K would be a gang block.
Then I compiled zfs.ko with this change and put it into a virtual machine where
I created a pool and populated its root/boot filesystem with /boot directory.
Booted in virtual machine from the new virtual disk and immediately hit the
problem.
So far, so good, but still no clue why zfsboot crashes upon encountering a gang
block.
So I decided to debug the crash with gdb.
Standard steps:
$ qemu ... -S -s
$ gdb
...
(gdb) target remote localhost:1234
Now I didn't want to single-step through the whole boot process, so I decided to
get some help from gdb. Here's a trick:
(gdb) add-symbol-file /usr/obj/usr/src/sys/boot/i386/gptzfsboot/gptzfsboot.out
0xa000
gptzfsboot.out is an ELF image produced by GCC, which then gets transformed into
a raw binary and then into final BTX binary (gptzfsboot).
gptzfsboot.out is built without much debugging data but at least it contains
information about function names. Perhaps it's even possible to compile
gptzfsboot.out with higher debug level, then debugging would be much more
pleasant.
0xA000 is where _code_ from gptzfsboot.out ends up being loaded in memory.
BTW, having only shallow knowledge about boot chain and BTX I didn't know this
address. Another GDB trick helped me:
(gdb) append memory boot.memdump 0x0 0x1
This command dumps memory content in range 0x0-0x1 to a file named
boot.memdump. Then I produced a hex dump and searched for byte sequence with
which gptzfsboot.bin starts (raw binary produced produced from gptzfsboot.out).
Of course, memory dump should be taken after gptzfsboot is loaded into memory :)
Catching the right moment requires a little bit of boot process knowledge.
I caught it with:
(gdb) b *0xC000
That is, memory dump was taken after gdb stopped at the above break point.
After that it was a piece of cake. I set break point on zio_read_gang function
(after add-symbol-file command) and the stepi-ed through the code (that is,
instruction by instruction). The following command made it easier to see what's
getting executed:
(gdb) display/i 0xA000 + $eip
I quickly stepped though the code and saw that a large value was passed to
vdev_read as 'bytes' parameter. But this should have been 512. The oversized
read into a buffer allocated on stack smashed the stack and that was the end.
Backtracking the call chain in source code I immediately noticed the bp
condition in vdev_read_phys and realized what the problem was.
Hope this would be a useful reading.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Make process title - % complete
On Tue, 2009-10-20 at 14:42 +0200, Ivan Voras wrote:
Alex Kozlov wrote:
Of course ps or top output much more convenient, but if setproctitle so
expencive and will be called so often, then SIGINFO may be good
compromise.
Regarding speed of setproctitle(), here are some microbenchmark results
from the attached test source:
getpid: 3661124.75 iterations/s
setproctitle: 591357.56 iterations/s
Meaning, setprocitle() is around 6 times more expensive than getpid(),
meaning it can only be pulled off nearly 600,000 calls/s on a 2.3 GHz
Core 2 CPU.
I really want to be enlightened about how it could affect wallclock time
in make(1).
What is the relative difference in buildworld time with and without?
robert.
#include sys/time.h
#include stdlib.h
#include stdio.h
#include string.h
#include unistd.h
#define NITER 1e7
double now() {
struct timeval tp;
gettimeofday(tp, NULL);
return tp.tv_sec + (double)tp.tv_usec / 1e6f;
}
int main() {
double t1, t2, t3;
int i;
t1 = now();
for (i = 0; i NITER; i++)
getpid();
t2 = now() - t1;
printf(getpid: %0.2f iterations/s\n, (float)(NITER/t2));
t1 = now();
for (i = 0; i NITER; i++)
setproctitle(t%d, i);
t3 = now() - t1;
printf(setproctitle: %0.2f iterations/s\n, (float)(NITER/t3));
}
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
--
Robert Noland rnol...@freebsd.org
FreeBSD
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: heci: a new driver for review and testing
On Thu, 2009-10-15 at 08:23 +0300, Andriy Gapon wrote: on 15/10/2009 00:25 Robert Noland said the following: On Wed, 2009-10-14 at 20:12 +0300, Andriy Gapon wrote: Some time ago I posted some ideas about HECI/MEI driver for FreeBSD: http://docs.freebsd.org/cgi/mid.cgi?4968E9A1.3080006 I actually got around to implementing it (in initial/basic form): http://people.freebsd.org/~avg/heci.tgz Your getting a WITNESS warning from malloc() while holding a lock at like 941 of heci.c mec = (struct me_client *)malloc(sizeof(*mec), M_HECI, M_NOWAIT | M_ZERO); fixes it. Shame on me! I have to admit that tested/used this module only on stable/7 (amd64) and without WITNESS/INVARIANTS. Thank you for catching this. I guess I should also add a check for malloc returning NULL. Yes, with M_NOWAIT you should. Here is the dmesg output. heci0: Intel 82G33/G31/P35/P31 Express HECI/MEI Controller mem 0xd0526100-0xd052610f irq 16 at device 3.0 on pci0 heci0: using MSI heci0: [ITHREAD] heci0: found ME client at address 0x02: heci0: status = 0x00 heci0: protocol_name(guid) = BB875E12-CB58-4D14-AE93-8566183C66C7 heci0: found ME client at address 0x03: heci0: status = 0x00 heci0: protocol_name(guid) = A12FF5CA-FACB-4CB4-A958-19A23B2E6881 heci0: found ME client at address 0x06: heci0: status = 0x00 heci0: protocol_name(guid) = 9B27FD6D-EF72-4967-BCC2-471A32679620 heci0: found ME client at address 0x07: heci0: status = 0x00 heci0: protocol_name(guid) = 55213584-9A29-4916-BADF-0FB7ED682AEB heci0: found ME client at address 0x20: heci0: status = 0x00 heci0: protocol_name(guid) = 23F27E9B-9D26-4FCE-9227-DE06446E5B06 heci0: found ME client at address 0x21: heci0: status = 0x00 heci0: protocol_name(guid) = 309DCDE8-CCB1-4062-8F78-600115A34327 heci0: found ME client at address 0x22: heci0: status = 0x00 heci0: protocol_name(guid) = 6B5205B9-8185-4519-B889-D98724B58607 heci0: found ME client at address 0x23: heci0: status = 0x00 heci0: protocol_name(guid) = 9D9105BD-C8C6-41CA-AC28-84738E2CE9FD heci0: found ME client at address 0x24: heci0: status = 0x00 heci0: protocol_name(guid) = DC506909-7ADB-4A0D-B109-4E25E38C382C heci0: found ME client at address 0x25: heci0: status = 0x00 heci0: protocol_name(guid) = 6733A4DB-0476-4E7B-B3AF-BCFC29BEE7A7 heci0: found ME client at address 0x26: heci0: status = 0x00 heci0: protocol_name(guid) = 12F80028-B4B7-4B2D-ACA8-46E0FF65814C heci0: found ME client at address 0x27: heci0: status = 0x00 heci0: protocol_name(guid) = 05B79A6F-4628-4D7F-899D-A91514CB32AB robert. It also locked up the machine when I tried to kldunload, but haven't identified a root cause of that. Haven't seen it here. I will try to investigate. -- Robert Noland rnol...@freebsd.org FreeBSD ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: heci: a new driver for review and testing
guess those are not copyrightable at all? I added a bunch of comments to those file describing the constants and structs. -- Robert Noland rnol...@freebsd.org FreeBSD ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: heci: a new driver for review and testing
On Wed, 2009-10-14 at 20:12 +0300, Andriy Gapon wrote: Some time ago I posted some ideas about HECI/MEI driver for FreeBSD: http://docs.freebsd.org/cgi/mid.cgi?4968E9A1.3080006 I actually got around to implementing it (in initial/basic form): http://people.freebsd.org/~avg/heci.tgz Other drivers are: [Linux] http://www.openamt.org/ [OpenSolaris] http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/intel/io/heci/ An example of what functionality this driver could provide: http://article.gmane.org/gmane.linux.drivers.sensors/20398 This actually was my primary motivation for looking into this driver. Could you also post the client code in some form more readily accessible than trying to cut/paste from the web page? robert. Your hardware may be supported by this driver if pciconf -lv has something like the following: no...@pci0:0:3:0: class=0x078000 card=0x50448086 chip=0x29c48086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '(Bearlake) HECI Controller' class = simple comms Here's how successful attachment of this driver looks on my system: heci0: Intel 82G33/G31/P35/P31 Express HECI/MEI Controller mem 0xe0426100-0xe042610f irq 16 at device 3.0 on pci0 heci0: using MSI heci0: [ITHREAD] heci0: found ME client at address 0x03: heci0: status = 0x00 heci0: protocol_name(guid) = A12FF5CA-FACB-4CB4-A958-19A23B2E6881 heci0: found ME client at address 0x07: heci0: status = 0x00 heci0: protocol_name(guid) = 55213584-9A29-4916-BADF-0FB7ED682AEB heci0: found ME client at address 0x20: heci0: status = 0x00 heci0: protocol_name(guid) = 309DCDE8-CCB1-4062-8F78-600115A34327 heci0: found ME client at address 0x21: heci0: status = 0x00 heci0: protocol_name(guid) = 6B5205B9-8185-4519-B889-D98724B58607 The driver has many functional and programming shortcomings, but I still would like to ask for its review and testing. Please read the following warnings and notices: 1. right now the driver is provided only as a module. 2. the driver recognizes only PCI ID of 0x29c48086, which is what I tested it with; please see hecireg.h for a list of potentially supported IDs and add your ID to heci_probe(). 3. heciio.h does not get installed into /usr/include, so for time being you need to take an extra step to make it available to code that wishes to communicate to heci. 4. this driver has far less capabilities than Linux and OpenSolaris drivers, so don't expect every OpenAMT program to work with it (but it does reliably work for me for the QST thing). Now more details about the code: 1. the code contains some style violations like overly long lines, probably others; but I still would like to hear your comments on its style. 2. there are some bad design decisions like using the same mutex+condvar pair for signaling different events (reception of data from ME, emptying of user buffer); but I still would like to hear your comments about improving the design. 3. only a single connection is allowed for a host client 4. only a single connection is allowed to a ME client (if the client can support more). 5. quite an arbitrary timeout is used in all places where we wait for simething to happen. 6. no power management supported. 7. only messages of size less than 512 bytes are supported. 8. only complete messages are supported, multi-part messages are not. 9. userland is expected to read or write the whole message in one go. 10. poll/select functionality is not tested. 11. non-blocking reads/writes are not supported. 12. some (probably important) properties and statuses of ME clients are not interpreted. 13. no specific support for watchdog and PTHI, only simple HECI/MEI communications. 14. probably many more... I think that ultimately, if complete feature support is needed, it would be easier to port the driver from either OpenSolaris or Linux than to add all the features to the presented driver. This is because documentation/description for many features is severely lacking in public access. I guess that Intel developers that worked on the OpenAMT driver had much more detailed specifications to work with. But reverse-engineering some parts of OpenAMT code is very hard. You can see for yourself, if not for the hacker who decompiled a Windows DLL, there would be no way of obtaining even GUID of QST client from public sources. Thank you very much in advance for any feedback, comments, ideas! P.S. BTW, can/may I drop alternatively GPL wording from License block of the files I borrowed from Intel? I.e. can a dual BSD+GPL licensed file be turned into BSD-only? Some additional info. The files contain only some data structure/constants definitions. I guess those are not copyrightable at all? I added a bunch of comments to those file describing the constants and structs. -- Robert Noland rnol...@freebsd.org FreeBSD
Re: sx locks and memory barriers
On Fri, 2009-09-25 at 00:49 +0200, Fabio Checconi wrote: Hi all, looking at sys/sx.h I have some troubles understanding this comment: * A note about memory barriers. Exclusive locks need to use the same * memory barriers as mutexes: _acq when acquiring an exclusive lock * and _rel when releasing an exclusive lock. On the other side, * shared lock needs to use an _acq barrier when acquiring the lock * but, since they don't update any locked data, no memory barrier is * needed when releasing a shared lock. In particular, I'm not understanding what prevents the following sequence from happening: CPU A CPU B sx_slock(data-lock); sx_sunlock(data-lock); /* reordered after the unlock by the cpu */ if (data-buffer) sx_xlock(data-lock); free(data-buffer); data-buffer = NULL; sx_xunlock(data-lock); a = *data-buffer; IOW, even if readers do not modify the data protected by the lock, without a release barrier a memory access may leak past the unlock (as the cpu won't notice any dependency between the unlock and the fetch, feeling free to reorder them), thus potentially racing with an exclusive writer accessing the data. Maybe I am missing something suttle, but shouldn't the shared lock be held for all data access if you want to guarantee sanity? Meaning, if you are accessing data-* without any locks held, all bets are off. robert. On architectures where atomic ops serialize memory accesses this would never happen, otherwise the sequence above seems possible; am I missing something? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org -- Robert Noland rnol...@freebsd.org FreeBSD ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: sx locks and memory barriers
On Fri, 2009-09-25 at 09:30 -0400, Ryan Stone wrote: The code that Fabio proposes looks like this: sx_slock(data-lock); if (data-buffer) a = *data-buffer; sx_sunlock(data-lock); This point is that without a memory barrier on the unlock, the CPU is free to reorder the instructions into the order is his message. Ok, then I will sit back and wait for someone with more clue to respond... robert. -- Robert Noland rnol...@freebsd.org FreeBSD ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: GA-MA780G-UD3H motherboard
= 'ATI SMBus (ATI RD600/RS600)' class = serial bus subclass = SMBus atap...@pci0:0:20:1:class=0x01018a card=0x50021458 chip=0x439c1002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' device = 'PATA 133 Controller (SB7xx)' class = mass storage subclass = ATA hd...@pci0:0:20:2: class=0x040300 card=0xa0021458 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 is...@pci0:0:20:3: class=0x060100 card=0x43831002 chip=0x439d1002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' device = 'SB700 LPC host controller' class = bridge subclass = PCI-ISA pc...@pci0:0:20:4: class=0x060401 card=0x 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 oh...@pci0:0:20:5: class=0x0c0310 card=0x50041458 chip=0x43991002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' device = 'SB700 USB OHCI2 Controller' class = serial bus subclass = USB hos...@pci0:0:24:0: class=0x06 card=0x chip=0x11001022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = 'Athlon64/Opteron/Sempron (K8 Family) HyperTransport Technology Configuration' class = bridge subclass = HOST-PCI hos...@pci0:0:24:1: class=0x06 card=0x chip=0x11011022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = 'Athlon64/Opteron/Sempron (K8 Family) Address Map' class = bridge subclass = HOST-PCI hos...@pci0:0:24:2: class=0x06 card=0x chip=0x11021022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = 'Athlon64/Opteron/Sempron (K8 Family) DRAM Controller' class = bridge subclass = HOST-PCI hos...@pci0:0:24:3: class=0x06 card=0x chip=0x11031022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = 'Athlon64/Opteron/Sempron (K8 Family) Miscellaneous Control' class = bridge subclass = HOST-PCI vgap...@pci0:1:5:0: class=0x03 card=0xd0001458 chip=0x96101002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' device = 'Radeon HD 3200 Integrated Graphics Processor (780G)' class = display subclass = VGA hd...@pci0:1:5:1: class=0x040300 card=0x960f1002 chip=0x960f1002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' class = multimedia subclass = HDA r...@pci0:2:0:0: class=0x02 card=0xe0001458 chip=0x816810ec rev=0x02 hdr=0x00 vendor = 'Realtek Semiconductor' device = 'Gigabit Ethernet NIC(NDIS 6.0) (RTL8168/8111)' class = network subclass = ethernet fwoh...@pci0:3:14:0:class=0x0c0010 card=0x10001458 chip=0x8024104c rev=0x00 hdr=0x00 vendor = 'Texas Instruments (TI)' device = 'TSB43AB23 1394a-2000 OHCI PHY/link-layer Controller' class = serial bus subclass = FireWire ___ freebsd-a...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org -- Robert Noland rnol...@freebsd.org FreeBSD ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: GA-MA780G-UD3H motherboard
On Tue, 2009-08-25 at 22:14 +0200, Thierry Herbelot wrote: Le Tuesday 25 August 2009, Robert Noland a écrit : On Tue, 2009-08-25 at 21:27 +0200, Thierry Herbelot wrote: Le Tuesday 25 August 2009, Sam Fourman Jr. a écrit : Meanwhile, if you interested in any information about this motherboard - data dumps, outputs from tools, etc - please let me know, I will try my best to provide that. it would be interesting to see a dmesg as a starting point. here you are ;-) I have plugged a PCI sound board in the machine, but it does seem to be detected (there could be some issue with PCI bus enumeration : I also include a pciconf log) I'm curious why you would plug in a pci sound card? You already have both a standard hda codec as well as the hda codec for the hdmi port of the video. If you are discovering that it isn't working... set Initially, this was the issue, before other people sent various howtos around the probe of the hdmi hda port (which by the way sounds *much* better than my previous cmi board). Afterwards, the PCI board remained in the machine (leftover from a previous box), but it is still *not* seen by the PCI enumeration (I'm a bit too lazy to find another spare PCI board and plug it in see what happens : is it also ignored by the BIOS/ACPI/whatever and/or the kernel ?). It seems that it is not either detected by a Linux kernel. Perhaps it isn't seated properly? Or possibly a different slot might help. robert. TfH hw.snd.default_unit=1 which is typcially your normal analog audio port. The hdmi port on radeon chips tends to be enumerated before the normal system codecs, so people tend to think that sound isn't working. robert. -- Robert Noland rnol...@freebsd.org FreeBSD ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: In search of a video card
On Thu, 2009-05-14 at 16:10 +0930, Daniel O'Connor wrote: On Thu, 14 May 2009, Adrian Chadd wrote: 2009/5/14 Josef Grosch jgro...@mooseriver.com: I don't need 2d 3d acceleration. I just need a card that will handle WindowMaker on a 24 inch Dell monitor at 1920x1200 and as long as the flesh tones on my JPGs don't suck I'm happy. Thanks for the advice. I guess I'm going to make a trip to Fry's Friday. I've experienced no-acceleration radeon driver desktop under Ubuntu and FreeBSD; let me please point out how sluggish and horribly slow it is. Depends how unaccelerated it is. VESA is pretty damn slow, but even minimal radeon/radeonhd support is fast enough for desktop use. I gave up trying to get accelerated 3d + dualhead support on the card(s) I was using - apparently the hardware just didn't do a single viewport span across 2 1280x1024 screens :( (The max viewport width was 2048 pixels..) 2d acceleration may be a must for that kind of resolution.. If you have a fast CPU decent pipe to video memory it isn't necessary, but very nice. Folks, 2d (EXA) should work on virtually any radeon with 7.2 or 8.0. 3d is currently works on r500 and below. AMD has released preliminary code for 3d on r600+, which I've been working with lately. It isn't ready yet, but it will be soon. If you only need 2d, then Nvidia is also an option. At least if you are ok with running my patch to enable nouveau drm. I've recently managed to get 3d sortof working on NV50 as well, not sure what kind of timeline that will be though, since it is using gallium and isn't as well tested as the old dri code. robert. -- Robert Noland rnol...@freebsd.org FreeBSD signature.asc Description: This is a digitally signed message part
Re: In search of a video card
On Wed, 2009-05-13 at 20:06 -0700, Josef Grosch wrote: I'm in search for a decent video card. I currently have an Nvidia GeForce 8400 GS. It worked pretty well i386 FreeBSD 6.2. I have upgraded my home machine and I am running amd64 FreeBSD 7.2 and it just refuses to go into X. It just hangs. I've been poking around and, based on what I read, some FreeBSD developers and Nvidia have gotten into a finger pointing contest as to what is the problem. Its all very nice but doesn't help me much. So, can any one recommend a good video card? What I'm looking for is * Works with amd64 FreeBSD 7.2 * DVI * PCI-E x16 * 512 MB or more * Not going to cost an arm and a leg radeon robert. Thanks Josef -- Robert Noland rnol...@freebsd.org FreeBSD signature.asc Description: This is a digitally signed message part
Re: Question about adding flags to mmap system call / NVIDIA amd64 driver implementation
On Thu, 2009-04-30 at 17:36 -0400, John Baldwin wrote: On Tuesday 28 April 2009 7:58:57 pm Julian Elischer wrote: Robert Noland wrote: On Tue, 2009-04-28 at 16:48 -0500, Kevin Day wrote: On Apr 28, 2009, at 3:19 PM, Julian Bangert wrote: Hello, I am currently trying to work a bit on the remaining missing feature that NVIDIA requires ( http://wiki.freebsd.org/NvidiaFeatureRequests or a back post in this ML) - the improved mmap system call. you might check with jhb (john Baldwin) as I think (from his p4 work) that he may be doing something in this area in p4. After some promptings from Robert and his needs for Xorg recently I did start hacking on this again. However, I haven't tested it yet. What I have done so far is in //depot/user/jhb/pat/... and it does the following: 1) Adds a vm_cache_mode_t. Each arch defines the valid values for this (I've only done the MD portions of this work for amd64 so far). Every arch must at least define a value for VM_CACHE_DEFAULT. 2) Stores a cache mode in each vm_map_entry struct. This cache mode is then passed down to a few pmap functions: pmap_object_init_pt(), pmap_enter_object(), and pmap_enter_quick(). Several vm_map routines such as vm_map_insert() and vm_map_find() now take a cache mode to use when adding a new mapping. 3) Each VM object stores a cache mode as well (defaults to VM_CACHE_DEFAULT). When a VM_CACHE_DEFAULT mapping is made of an object, the cache mode of the object is used. 4) A new VM object type: OBJT_SG. This object type has its own pager that is sort of like the device pager. However, instead of invoking d_mmap() to determine the physaddr for a given page, it consults a pre-created scatter/gather list (an ADT from my branch for working on unmapped buffer I/O) to determine the backing physical address for a given virtual address. 5) A new callback for device mmap: d_mmap_single(). One of the features of this is that it can return a vm_object_t to be used to satisfy the mmap() request instead of using the device's device pager VM object. 6) A new mcache() system call similar to mprotect(), except that it changes the cache mode of an address range rather than the protection. This may not be all that useful really. Given all this, a driver could do the following to map a thing as WC in both userland and the kernel: 1) When it learns about a thing it creates a SG list to describe it. If the thing consists of userland pages, it has to wire the pages first. The driver can use vm_allocate_pager() to create a OBJT_SG VM object. It sets the object's cache mode to VM_CACHE_WC (if the arch supports that). 2) When userland wants to map the thing it does a device mmap() with a proper length and a file offset that is a cookie for the thing. The device driver's d_mmap_single() recognizes the magic file offset and returns the thing's VM object. Since the mapping info is now part of a normal object mapping, it will go away via munmap(), etc. The driver no longer has to do weird gymnastics to invalidate mappings from its device pager as transient mappings are no longer stored in the device pager. 3) When the driver wants to map the thing into the kernel, it can use vm_map_find() to insert the thing's VM object into kernel map. And I think that is all there is to it. I need to test this somehow to make sure though, and make sure this meets the needs of Robert and Nvidia. I think this sounds pretty good... I need to get my perforce foo up to speed so I can try it out... robert. -- Robert Noland rnol...@freebsd.org FreeBSD signature.asc Description: This is a digitally signed message part
Re: Question about adding flags to mmap system call / NVIDIA amd64 driver implementation
On Tue, 2009-04-28 at 16:48 -0500, Kevin Day wrote: On Apr 28, 2009, at 3:19 PM, Julian Bangert wrote: Hello, I am currently trying to work a bit on the remaining missing feature that NVIDIA requires ( http://wiki.freebsd.org/NvidiaFeatureRequests or a back post in this ML) - the improved mmap system call. For now, I am trying to extend the current system call and implementation to add cache control ( the type of memory caching used) . This feature inherently is very architecture specific- but it can lead to enormous performance improvements for memmapped devices ( useful for drivers, etc). I would do this at the user site by adding 3 flags to the mmap system call (MEM_CACHE__ATTR1 to MEM_CACHE__ATTR3 ) which are a single octal digit corresponding to the various caching options ( like Uncacheable,Write Combining, etc... ) with the same numbers as the PAT_* macros from i386/include/ specialreg.h except that the value 0 ( PAT_UNCACHEABLE ) is replaced with value 2 ( undefined), whereas value 0 ( all 3 flags cleared) is assigned the meaning feature not used, use default cache control. For each cache behaviour there would of course also be a macro expanding to the rigth combination of these flags for enhanced useability. The mmap system call would, if any of these flags are set, decode them and get a corresponding PAT_* value, perform the mapping and then call into the pmap module to modify the cache attributes for every page. Have you looked at mem(4) yet? Several architectures allow attributes to be associated with ranges of physical memory. These attributes can be manipulated via ioctl() calls performed on /dev/mem. Declarations and data types are to be found in sys/memrange.h. The specific attributes, and number of programmable ranges may vary between architectures. The full set of supported attributes is: MDF_UNCACHEABLE The region is not cached. MDF_WRITECOMBINE Writes to the region may be combined or performed out of order. MDF_WRITETHROUGH Writes to the region are committed synchronously. MDF_WRITEBACK Writes to the region are committed asynchronously. MDF_WRITEPROTECT The region cannot be written to. This requires knowledge of the physical addresses, but I believe that's probably already necessary for what it sounds like you're trying to accomplish. Back in the FreeBSD-3.0 days, I was writing a custom driver for an AGP graphics controller, and setting the MTRR flags for the exposed buffer was a definite improvement (200-1200% faster in most cases). This is MTRR, which is what we currently do, when we can. The issue is that often times the BIOS maps ranges in a way that prevents us from using MTRR. This is generally ideal for things like agp and framebuffers when it works, since they have a specific physical range that you want to work with. With PCI(E) cards it isn't as cut and dry... In the ATI and Nouveau cases, we map scatter gather pages into the GART, which generally are allocated using contigmalloc behind the scenes, so it is also possible for it to work in that case. Moving forward, we may actually be mapping random pages into and out of the GART (GEM / TTM). In those cases we really don't have a large contiguous range that we could set MTRR on. Intel CPUs are limited to 8 MTRR registers for the entire system also, so that can become an issue quickly if you are trying to manipulate several areas of memory. With PAT we can manipulate the caching properties on a page level. PAT also allows for some overlap conditions that MTRR won't, such as mapping a page write-combining on top on an UNCACHEABLE MTRR. jhb@ has started some work on this, since I've been badgering him about this recently as well. robert. -- Kevin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org -- Robert Noland rnol...@freebsd.org FreeBSD signature.asc Description: This is a digitally signed message part
Re: diagnosing freezes (DRI?)
On Sat, 2009-04-11 at 11:23 +0100, xorquew...@googlemail.com wrote: The machine ran for hours, apparently. I ended up going to bed and leaving it running. Woke up to find it on display sleep, frozen. Are you running the 7.2-PRE or -STABLE? There are a few relevant fixes in -STABLE that didn't make it into the pre-release. robert. It didn't panic, apparently. I've included Xorg.0.log and the last few lines of /var/log/messages but I don't believe they show anything very interesting. I should point out that this card is the dual-DVI version. I'm not sure if that's relevant (I think it's just less common). I'm only using one screen, currently. /var/log/Xorg.0.log: X.Org X Server 1.6.0 Release Date: 2009-2-25 X Protocol Version 11, Revision 0 Build Operating System: FreeBSD 7.2-PRERELEASE amd64 Current Operating System: FreeBSD viper.internal.network 7.2-PRERELEASE FreeBSD 7.2-PRERELEASE #0: Fri Apr 10 00:09:48 BST 2009 r...@viper.internal.network:/usr/obj/usr/src/sys/GENERIC amd64 Build Date: 11 April 2009 04:34:30AM Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: /var/log/Xorg.0.log, Time: Sat Apr 11 06:16:46 2009 (==) Using config file: /etc/X11/xorg.conf (==) ServerLayout X.org Configured (**) |--Screen Screen0 (0) (**) | |--Monitor Monitor0 (**) | |--Device Card0 (**) |--Input Device Mouse0 (**) |--Input Device Keyboard0 (==) Not automatically adding devices (==) Not automatically enabling devices (WW) The directory /usr/local/lib/X11/fonts/TTF/ does not exist. Entry deleted from font path. (WW) The directory /usr/local/lib/X11/fonts/OTF does not exist. Entry deleted from font path. (WW) The directory /usr/local/lib/X11/fonts/Type1/ does not exist. Entry deleted from font path. (WW) The directory /usr/local/lib/X11/fonts/TTF/ does not exist. Entry deleted from font path. (WW) The directory /usr/local/lib/X11/fonts/OTF does not exist. Entry deleted from font path. (WW) The directory /usr/local/lib/X11/fonts/Type1/ does not exist. Entry deleted from font path. (**) FontPath set to: /usr/local/lib/X11/fonts/misc/, /usr/local/lib/X11/fonts/100dpi/, /usr/local/lib/X11/fonts/75dpi/, /usr/local/lib/X11/fonts/misc/, /usr/local/lib/X11/fonts/100dpi/, /usr/local/lib/X11/fonts/75dpi/, built-ins (**) ModulePath set to /usr/local/lib/xorg/modules (II) Loader magic: 0xd20 (II) Module ABI versions: X.Org ANSI C Emulation: 0.4 X.Org Video Driver: 5.0 X.Org XInput driver : 4.0 X.Org Server Extension : 2.0 (II) Loader running on freebsd (--) Using syscons driver with X support (version 134217730.0) (--) using VT number 9 (--) PCI:*(0...@6:0:0) ATI Technologies Inc RV570 [Radeon X1950 Pro] rev 154, Mem @ 0xd000/268435456, 0xfbee/65536, I/O @ 0xe000/256, BIOS @ 0x/65536 (--) PCI: (0...@6:0:1) ATI Technologies Inc RV570 [Radeon X1950 Pro] (secondary) rev 154, Mem @ 0xfbef/65536 (II) System resource ranges: [0] -1 0 0x000f - 0x000f (0x1) MX[B] [1] -1 0 0x000c - 0x000e (0x3) MX[B] [2] -1 0 0x - 0x0009 (0xa) MX[B] [3] -1 0 0x - 0x (0x1) IX[B] [4] -1 0 0x - 0x00ff (0x100) IX[B] (II) extmod will be loaded. This was enabled by default and also specified in the config file. (II) dbe will be loaded. This was enabled by default and also specified in the config file. (II) glx will be loaded. This was enabled by default and also specified in the config file. (II) record will be loaded. This was enabled by default and also specified in the config file. (II) dri will be loaded. This was enabled by default and also specified in the config file. (II) dri2 will be loaded. This was enabled by default and also specified in the config file. (II) LoadModule: extmod (II) Loading /usr/local/lib/xorg/modules/extensions//libextmod.so (II) Module extmod: vendor=X.Org Foundation compiled for 1.6.0, module version = 1.0.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 2.0 (II) Loading extension MIT-SCREEN-SAVER (II) Loading extension XFree86-VidModeExtension (II) Loading extension XFree86-DGA (II) Loading extension DPMS (II) Loading extension XVideo (II) Loading extension XVideo-MotionCompensation (II) Loading extension X-Resource (II) LoadModule: record (II) Loading /usr/local/lib/xorg/modules/extensions//librecord.so (II) Module record: vendor=X.Org Foundation compiled for 1.6.0, module version = 1.13.0 Module class: X.Org
Re: diagnosing freezes (DRI?)
On Sat, 2009-04-11 at 20:30 +0100, xorquew...@googlemail.com wrote: On 2009-04-11 14:11:15, Robert Noland wrote: Are you running the 7.2-PRE or -STABLE? There are a few relevant fixes in -STABLE that didn't make it into the pre-release. Sorry, should've made that clear. It was meant to be -STABLE but it seems to be calling itself -PRE. Just to clarify, my uname says 7.2-PRERELEASE but I used the 'stable-supfile'. This is expected, yes? I'm about to update the machine's BIOS and then enable all the possible debugging options from the kernel dev handbook. Yes, just make sure that your -STABLE is at least: r190653 | rnoland | 2009-04-02 13:21:41 -0500 (Thu, 02 Apr 2009) | 7 lines robert. xw -- Robert Noland rnol...@freebsd.org FreeBSD signature.asc Description: This is a digitally signed message part
Re: diagnosing freezes (DRI?)
On Sat, 2009-04-11 at 14:06 +0200, Gary Jennejohn wrote: On Sat, 11 Apr 2009 11:15:59 +0100 xorquew...@googlemail.com wrote: On 2009-04-11 02:30:40, Paul B. Mahol wrote: If it locks under X11 then use debug.debugger_on_panic=0 sysctl. Not doing this will increase drasticaly chances of locking whole system and not providing any debug data. I don't seem to have that sysctl. You sure that's the correct name? It's definitely in 8-current. Seems to be set to 0 as default. This may only exist if you have DDB enabled... robert. --- Gary Jennejohn ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org -- Robert Noland rnol...@freebsd.org FreeBSD signature.asc Description: This is a digitally signed message part
Re: diagnosing freezes (DRI?)
development and video editing. Any advice would be much appreciated. I'm under slight time pressure to get this system up and running. Are you running powerd by chance? I was seeing an issue that seemed to be related to powerd. Since I've disabled it on that box, it hasn't hung up any more. As far as drm is concerned, I've been running on an x1650 for probably a week now while working mostly on port stuff and I haven't seen any issues. This is with full 3d and compiz running, etc... So, if it is drm related... we are going to have to dig up some debugging info somehow... robert. thanks, xw ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org -- Robert Noland rnol...@freebsd.org FreeBSD signature.asc Description: This is a digitally signed message part
Re: diagnosing freezes (DRI?)
On Fri, 2009-04-10 at 18:59 +0100, xorquew...@googlemail.com wrote: Hello. On 2009-04-10 12:42:48, Robert Noland wrote: Are you running powerd by chance? I was seeing an issue that seemed to be related to powerd. Since I've disabled it on that box, it hasn't hung up any more. I'm not running powerd, no. As far as drm is concerned, I've been running on an x1650 for probably a week now while working mostly on port stuff and I haven't seen any issues. This is with full 3d and compiz running, etc... So, if it is drm related... we are going to have to dig up some debugging info somehow... robert. The system doesn't seem to have frozen since DRI/DRM was disabled. I did have one crash/reboot whilst building a large number of packages with tinderbox. I've currently got both tinderbox and a make -j 16 buildworld going on a loop in the hope that I can trigger it again. Being the idiot I am, I had encrypted swap enabled and so savecore didn't save anything. Won't make that mistake twice. I'm currently using a world compiled WITH_DEBUG but is there anything else I can do? If it is locking the whole system, then a core is really our best shot. If you can extract anything useful from xorg.log or setting hw.dri.0.debug that also might be of use. I'm running on 2 cores, but it is possible that some locking issue exists. All of the driver specific ioctls are run under a lock though. robert. thanks, xw ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org -- Robert Noland rnol...@freebsd.org FreeBSD signature.asc Description: This is a digitally signed message part
Re: some questions about 32 bit / 64 bit
On Fri, 2009-04-03 at 14:45 +0200, Ivan Voras wrote: Harald Servat wrote: My first issue is, I'm currently working with Linux and I'm planning to switch to FreeBSD 7.1, but I don't know if switch to 32 or 64 bit (i.e., i386 or amd64). If I switch to the 32 bit version, which is the memory limit On a server, switch to 64 bit. On a desktop machime, go with 32-bit. You will only be able to address slightly over 3 GB no matter which graphics card you use but on the other hand you'll have better supported drivers and 3rd party software. All of our drm drivers are safe on amd64. The only thing you get from 32bit is the ability to run the Nvidia blob. If you are trying to do emmulated things like play linux/windows games, then 32bit might be needed, but for normal use graphics isn't a reason not to use amd64. FreeBSD balrog.2hip.net 8.0-CURRENT FreeBSD 8.0-CURRENT #13 r190402M: Tue Mar 24 22:41:47 CDT 2009 rnol...@balrog.2hip.net:/usr/obj/usr/src/sys/BALROG amd64 robert. -- Robert Noland rnol...@freebsd.org FreeBSD signature.asc Description: This is a digitally signed message part
Re: Mackbook pro nvidia based video backlight
On Wed, 2009-01-28 at 14:29 +, Rui Paulo wrote: On 28 Jan 2009, at 13:43, Ed Schouten wrote: * Daniel Lannstrom o...@trekdanne.se wrote: I'm asking which method will be the best to interface the driver with userland applications? You might want to make it a character device driver. And write a small userland control program. Sysctl isn't really made for this kind of functionality. No. sysctl is good for doing stuff like this. An even better approach would be to integrate it to the X11 driver, but I guess it will be cold day in hell when this happens. Not really. The xorg intel driver is already able to deal with this. I don't know about NVIDIA. The intel ddx driver doesn't really deal with it. On linux the drm has code that interfaces with acpi to deal with backlight management. For us, afaik we handle it in acpi_video. I've not tried to port that part of the drm code. I'm not certain where the best place for this function to live is really, but for Nvidia's proprietary driver, the only option is a seperate kernel driver. robert. -- Rui Paulo ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org signature.asc Description: This is a digitally signed message part
Re: vm_map_find
On Sun, 2008-11-16 at 04:42 +0059, Alexej Sokolov wrote: Hello, my question is about vm_map_find (9) int vm_map_find(vm_map_t map, vm_object_t object, vm_ooffset_t offset, vm_offset_t *addr, vm_size_t length, boolean_t find_space, vm_prot_t prot, vm_prot_t max, int cow); Could anyone explain what exactly parameter cow for ? Which values and meanings ? Well, cow is COPY_ON_WRITE. See vm_map(9) for the list of flags. robert. man page dives not enough informations about it. Thanks ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: Improving Syslog
On Tue, 2008-05-06 at 12:41 -0400, Zaphod Beeblebrox wrote: On Tue, May 6, 2008 at 12:21 PM, Robert Watson [EMAIL PROTECTED] wrote: This sounds like an exciting project -- while I recognize the concerns other have expressed about complexity, I think that complexity can be managed if done carefully. I'm not sure if you've looked at Apple's extended syslog, which among other things, includes a binary log file format making it more mechanically searched and managed, do take a look if you haven't. ... and I'm not just saying this to be ornery, but what about test log file formats is not mechanically searchable? Note that I'm not playing the XML card here (I'm not an XML fan) but the only real draw of a binary format (to me) is a small amount of innate compression (numbers and dates in binary form) and the ability to have field separators that are not part of the printable character set. UN*X has a strong tradition of text files that work around these two limitations in a variety of ways --- and UN*X tools are built with these assumptions. There's a strong set of reasons to consider retaining text formats and continuing to improve our tools around them. I don't think anyone has suggested replacing text with a binary format. Just providing an alternative for those who choose to use it. robert. One way to strengthen the syslog format is to have syslog enforce a format _and_ enforce that whatever field separator is chosen cannot be written within a field. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problems with +CONTENTS being messed up by pkg_delete -f
On Wed, 2007-07-18 at 15:56 -0500, Stephen Montgomery-Smith wrote: If you pkg_delete -f a package and then install the port again (but after it has been bumped up a version), then the +CONTENTS of ports that require the original port will be incorrect. This apparently messes up programs like portmanager. There is a sense in which one should never do pkg_delete -f and expect /var/db/pkg to keep its integrety - on the other hand this is exactly what make deinstall does. My feeling is that the integrety of /var/db/pkg should be maintained across a make deinstall and subsequent make install of a bumped version of the port. This is my suggestion. When a pkg_delete -f is executed, it looks through +REQUIRED_BY of the port it is going to delete, and modifies the +CONTENTS file of each of them, replacing lines like @pkgdep xineramaproto-1.1.2 @comment DEPORIGIN:x11/xineramaproto to maybe something like @comment DELDEPORIGIN:x11/xineramaproto (deleted dependency origin). A subsequent make install of x11/xineramaproto should look through the +CONTENTS of all entries in /var/db/pkg and change these lines to something like @pkgdep xineramaproto-1.1.3 @comment DEPORIGIN:x11/xineramaproto Hrm, not quite what I had in mind... I don't want to misrepresent that a port was built against a newer version of a dependency. What I was hoping for would be that a port when reinstalled would not list both the current version of a dependency as well as a previous version of the same origin (which it aquired via the +CONTENTS of some other direct dependency). It should only list the currently installed version of that origin. That way it is still possible to determine that the interim port was built against an older version. I just want the +CONTENTS file to accurately list the versions that a given port was built against. robert. A further benefit of this approach is that one could also accurately reconstruct the +REQUIRED_BY of the port just reinstalled - right now this is left empty and thus inaccurate. What do you guys think? I know I could write the code for this quite quickly, but I want some feedback before I work on it. Stephen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
