DragonFlyBSD bugtracker: Issueshttps://bugs.dragonflybsd.org/https://bugs.dragonflybsd.org/favicon.ico?16293952082022-01-30T10:33:08ZDragonFlyBSD bugtracker
Redmine DragonFlyBSD - Bug #3311 (New): TrueCrypt support may cause kernel crashhttps://bugs.dragonflybsd.org/issues/33112022-01-30T10:33:08Zarcade@b1t.namearcade@b1t.name
<p>When working on tcplay:hammer2 device kernel can crash. Screenshots attached...</p> DragonFlyBSD - Bug #3228 (New): pfi_kif_unref: state refcount <= 0 in dmesghttps://bugs.dragonflybsd.org/issues/32282020-03-30T00:27:57Zjustin
<p>I see this in dmesg:</p>
<p>pfi_kif_unref: state refcount <= 0</p>
<p>Maybe about 100-125 in a day, in an estimate. This machine is using pf to NAT, with a few extra rules that are not in use. There doesn't seem to be any harm in these messages, but they've been going on for a long time. (several releases at least.)</p> DragonFlyBSD - Bug #3132 (New): unifdef minedhttps://bugs.dragonflybsd.org/issues/31322018-04-27T03:34:07Zbcallah
<p>Hi --</p>
<p>The included diff unifdefs the code in bin/mined. The #ifdef'd out paths probably would not even compile with the current #includes anyway.<br />No binary change. I have been running this on OpenBSD/amd64 and OpenBSD/armv7 for a while now. The DragonFly build is also happy with this.</p> DragonFlyBSD - Bug #3107 (New): ACPI interrupt storm when loading i915 on Lenovo T460https://bugs.dragonflybsd.org/issues/31072017-12-04T07:47:37Zoyvinhtoyvinht@pvv.ntnu.no
<p>This is on a Lenovo T460 (firmware r06uj56d)</p>
<pre><code>root# uname -a<br /> DragonFly slaptop 5.1-DEVELOPMENT DragonFly v5.1.0.381.ge8ac90-DEVELOPMENT #10: Mon Dec 4 07:52:28 CET 2017 root@slaptop:/usr/obj/usr/src/sys/SLAPTOP x86_64</code></pre>
<p>After doing:</p>
<pre><code>root# kldload i915</code></pre>
<p>the systems gets very slow, and looking at vmstat I see interrupts from acpi0 increasing by 2000-5000 every second (using kern.livelock_lowater=1000 and kern.livelock_limit=2000 makes the system usable again):</p>
<pre><code>root# vmstat -i</code></pre>
<pre><code>interrupt total rate<br /> acpi0 1681307 1925</code></pre>
<p>FWIW I have tested enabling DDB and INVARIANTS in the kernel, and built /sys/dev/acpica with ACPI_DEBUG=1, which fills the kernel message buffer with messages like:</p>
<pre><code>evgpe-0634 EvGpeDetect : Read registers for GPE 60-67: Status=40, Enable=46, RunEnable=46, WakeEnable=00<br /> evgpe-0607 EvGpeDetect : Ignore disabled registers for GPE 68-6F: RunEnable=00, WakeEnable=00<br /> evgpe-0607 EvGpeDetect : Ignore disabled registers for GPE 70-77: RunEnable=00, WakeEnable=00<br /> evgpe-0607 EvGpeDetect : Ignore disabled registers for GPE 78-7F: RunEnable=00, WakeEnable=00<br /> evevent-0361 EvFixedEventDetect : Fixed Event Block: Enable 00000120 Status 00000001<br /> evgpe-0607 EvGpeDetect : Ignore disabled registers for GPE 00-07: RunEnable=00, WakeEnable=00<br /> evgpe-0607 EvGpeDetect : Ignore disabled registers for GPE 08-0F: RunEnable=00, WakeEnable=00</code></pre> DragonFlyBSD - Bug #3101 (New): PFI CGI install not working in dragonflybsd 5.0.1 USB installhttps://bugs.dragonflybsd.org/issues/31012017-11-12T08:47:51Zbnegre82
<p>Hello,<br />I tried to install dragonflybsd on a PCengines APU2 with the CGI installer interface. I have to do this because there is just a serial console and normal installer don't work.<br />I added a pfi.conf file in /etc/pfi.conf to the image, but no web interface comes.<br />It failed because /usr/local/sbin/thttpd_wrapper is not on the USB install image (dfly-x86_64-5.0.1_REL.img.bz2)</p>
<p>The webserver is called by the pfi service at startup (etc/rc.d/pfi) line 203<br /> if [ "X$pfi_frontend" = "Xcgi" ]; then<br /> echo "Starting thttpd..." <br /> /usr/local/sbin/thttpd_wrapper &<br /> fi</p>
<p>Can you fix this for the next release ?<br />How can I add the web server to the install image ?</p>
<p>Regards,<br />Bertrand</p> DragonFlyBSD - Bug #3024 (New): sys/dev/netif/wi/if_wi.c:1090]: (style) Redundant conditionhttps://bugs.dragonflybsd.org/issues/30242017-04-11T18:56:08Zdcb
<p>sys/dev/netif/wi/if_wi.c:1090]: (style) Redundant condition: params. '!params || (params && params.ibp_flags&IEEE80211_BPF_CRYPTO)' is equivalent to '!params || params.ibp_flags&IEEE80211_BPF_CRYPTO'</p>
<p>Source code is</p>
<pre><code>if ((wh->i_fc[1] & IEEE80211_FC1_PROTECTED) &&<br /> (!params || (params && (params->ibp_flags & IEEE80211_BPF_CRYPTO)))) {</code></pre> DragonFlyBSD - Bug #2931 (New): 'gdb' of 'vkernel' unable to print backtracehttps://bugs.dragonflybsd.org/issues/29312016-07-26T20:33:39Ztofergus
<p>Whilst attempting to look at issue <a class="issue tracker-5 status-5 priority-4 priority-default closed" title="Submit: PCIe memory mapped config (Closed)" href="https://bugs.dragonflybsd.org/issues/2390">#2390</a> I came across the 'vkernel' debugging page in the wiki</p>
<p><a class="external" href="https://www.dragonflybsd.org/docs/howtos/HowToDebugVKernels/">https://www.dragonflybsd.org/docs/howtos/HowToDebugVKernels/</a></p>
<p>this noted a failure in the current implementation, which caused lockup (issue <a class="issue tracker-1 status-5 priority-5 priority-high3 closed" title="Bug: gdb vkernel doesn't work at all anymore (Closed)" href="https://bugs.dragonflybsd.org/issues/1301">#1301</a>). However my STABLE build</p>
<p>[...] 4.4-RELEASE DragonFly v4.4.3.9.ge5cb2-RELEASE #0: Fri Jul 15 17:02:58 UTC 2016 [...]/usr/obj/usr/src/sys/VKERNEL64 x86_64</p>
<p>attaches correctly</p>
<p>$ sudo gdb /var/vkernel/boot/kernel/kernel 8418<br />GNU gdb (GDB) 7.6.1<br />Copyright (C) 2013 Free Software Foundation, Inc.<br />License GPLv3+: GNU GPL version 3 or later <<a class="external" href="http://gnu.org/licenses/gpl.html">http://gnu.org/licenses/gpl.html</a>><br />This is free software: you are free to change and redistribute it.<br />There is NO WARRANTY, to the extent permitted by law. Type "show copying" <br />and "show warranty" for details.<br />This GDB was configured as "x86_64-dragonfly".<br />For bug reporting instructions, please see:<br /><<a class="external" href="http://bugs.dragonflybsd.org/&gt;">http://bugs.dragonflybsd.org/&gt;</a>...<br />Reading symbols from /var/vkernel/boot/kernel/kernel...done.<br />Attaching to program: /var/vkernel/boot/kernel/kernel, process 8418<br />Reading symbols from /lib/libc.so.8...(no debugging symbols found)...done.<br />Loaded symbols for /lib/libc.so.8<br />Reading symbols from /libexec/ld-elf.so.2...(no debugging symbols found)...done.<br />Loaded symbols for /libexec/ld-elf.so.2<br />0x00000000100a3750 in extpread () from /lib/libc.so.8</p>
<p>but then causes an exception whilst trying to print a backtrace</p>
<p>(gdb) bt<br />#0 0x00000000100a3750 in extpread () from /lib/libc.so.8<br /><a class="issue tracker-1 status-5 priority-3 priority-lowest closed" title="Bug: lib/libcr/sys/ cleanup (Closed)" href="https://bugs.dragonflybsd.org/issues/1">#1</a> 0x00000000101374ab in pread () from /lib/libc.so.8<br /><a class="issue tracker-1 status-5 priority-3 priority-lowest closed" title="Bug: K&R -> ANSI cleanup status (Closed)" href="https://bugs.dragonflybsd.org/issues/2">#2</a> 0x00000000006b9614 in vconsgetc (private=<optimized out>)<br /> at /usr/src/sys/platform/vkernel64/platform/console.c:384<br /><a class="issue tracker-1 status-5 priority-4 priority-default closed" title="Bug: freebsds pipe-reverse test fails on dfly (Closed)" href="https://bugs.dragonflybsd.org/issues/3">#3</a> 0x00000000005040a6 in cngetc () at /usr/src/sys/kern/tty_cons.c:512<br /><a class="issue tracker-1 status-5 priority-5 priority-high3 closed" title="Bug: Rework of nrelease (Closed)" href="https://bugs.dragonflybsd.org/issues/4">#4</a> 0x0000000000473e6a in db_readline (<br /> lstart=lstart@entry=0xa7f480 <db_line> "", lsize=lsize@entry=120)<br /> at /usr/src/sys/ddb/db_input.c:313<br /><a class="issue tracker-1 status-5 priority-3 priority-lowest closed" title="Bug: sys/dev cleanup (Closed)" href="https://bugs.dragonflybsd.org/issues/5">#5</a> 0x00000000004743d2 in db_read_line () at /usr/src/sys/ddb/db_lex.c:55<br /><a class="issue tracker-1 status-5 priority-3 priority-lowest closed" title="Bug: sys/emulation cleanup (Closed)" href="https://bugs.dragonflybsd.org/issues/6">#6</a> 0x0000000000472ed9 in db_command_loop ()<br /> at /usr/src/sys/ddb/db_command.c:465<br /><a class="issue tracker-1 status-5 priority-3 priority-lowest closed" title="Bug: /sys/boot cleanup (Closed)" href="https://bugs.dragonflybsd.org/issues/7">#7</a> 0x0000000000475cff in db_trap (type=type@entry=3, code=code@entry=0)<br /> at /usr/src/sys/ddb/db_trap.c:71<br /><a class="issue tracker-1 status-5 priority-4 priority-default closed" title="Bug: make upgrade broken (Closed)" href="https://bugs.dragonflybsd.org/issues/8">#8</a> 0x00000000006ab64e in kdb_trap (type=type@entry=3, code=code@entry=0, <br /> regs=regs@entry=0x802a866a68)<br /> at /usr/src/sys/platform/vkernel64/x86_64/db_interface.c:173<br /><a class="issue tracker-1 status-5 priority-5 priority-high3 closed" title="Bug: panic with HEAD (Closed)" href="https://bugs.dragonflybsd.org/issues/9">#9</a> 0x00000000006add1c in kern_trap (frame=0x802a866a68)<br /> at /usr/src/sys/platform/vkernel64/x86_64/trap.c:769<br /><a class="issue tracker-1 status-5 priority-5 priority-high3 closed" title="Bug: make buildworld broken (Closed)" href="https://bugs.dragonflybsd.org/issues/10">#10</a> 0x00000000006aef32 in exc_segfault (signo=<optimized out>,<br /> info=<optimized out>, ctxp=<optimized out>)<br /> at /usr/src/sys/platform/vkernel64/x86_64/exception.c:209<br /><a class="issue tracker-1 status-5 priority-3 priority-lowest closed" title="Bug: libstand cleanup (Closed)" href="https://bugs.dragonflybsd.org/issues/11">#11</a> <signal handler called><br /><a class="issue tracker-1 status-5 priority-3 priority-lowest closed" title="Bug: /sys/net cleanup (Closed)" href="https://bugs.dragonflybsd.org/issues/12">#12</a> 0x000000802a8670a0 in ?? ()<br />Cannot access memory at address 0x1</p>
<p>This causes 'ddb' to exit and the process to halt. Presume this is due to the SIGSTOP that halts the 'db>' prompt but unable to decipher how this might be resolved. '~/.gdbinit' contains the</p>
<p>handle SIGSEGV noprint<br />handle SIGUSR1 noprint</p>
<p>suggested in the article. Adding SIGSTOP has no effect.</p>
<p>Additionally, connecting to a running 'vkernel' with 'gdb' appears to have a similar effect; the console is disconnected (although the kernel appears to run).</p>
<p>Happy to document if this is purely an information gap on my part.</p> DragonFlyBSD - Bug #2887 (New): Missing extattr_namespace_to_string and extattr_string_to_namespa...https://bugs.dragonflybsd.org/issues/28872016-02-06T13:09:05Zrubenkruben@rubenkerkhof.com
<p>Hi,</p>
<p>I'm working on porting Burp (<a class="external" href="http://burp.grke.org">http://burp.grke.org</a>) to DragonFly.<br />I've been looking into what it would take for it to support backing up extended attributes.</p>
<p>Burp uses the extattr_namespace_to_string and extattr_string_to_namespace functions, which FreeBSD has in libutil.h and NetBSD in sys/extattr.h. DragonFlyBSD misses those however.</p>
<p>Would it be possible to add those functions?</p> DragonFlyBSD - Bug #2882 (New): bridge sends packets from individual interfaceshttps://bugs.dragonflybsd.org/issues/28822016-01-09T20:43:59Zarcade@b1t.namearcade@b1t.name
<p>Hi, recently tried configuring a bridge/stp alongside freebsd host with bridge. Looks like DragonFly version has some bugs in it... Dunno whether they are serious one or not. From time to time it loses connectivity and falls back to "blocking". Much more frequently following situation occurs:</p>
<p>FreeBSD (net.link.bridge.log_stp=1):</p>
<p>Jan 9 22:08:45 limbo kernel: arp: 172.29.1.195 moved from b6:02:35:28:d0:b1 to d4:3d:7e:48:ab:9d on bridge0<br />Jan 9 22:28:41 limbo kernel: arp: 172.29.1.195 moved from b6:02:35:28:d0:b1 to d4:3d:7e:48:ab:9d on bridge0</p>
<p>DragonFly (net.link.bridge.debug=1):</p>
<p>Jan 9 22:07:36 probe kernel: ff:ff:ff:ff:ff:ff 02:3b:77:1f:48:00 type 0608 lla b6:02:35:28:d0:b1<br />Jan 9 22:07:36 probe kernel: 02:3b:77:1f:48:00 52:54:00:12:34:56 type 0608 lla b6:02:35:28:d0:b1<br />Jan 9 22:08:45 probe kernel: ff:ff:ff:ff:ff:ff 02:3b:77:1f:48:00 type 0608 lla b6:02:35:28:d0:b1<br />Jan 9 22:10:40 probe kernel: ff:ff:ff:ff:ff:ff 02:3b:77:1f:48:00 type 0608 lla b6:02:35:28:d0:b1<br />Jan 9 22:12:13 probe kernel: ff:ff:ff:ff:ff:ff 94:eb:cd:2d:05:5f type 0608 lla b6:02:35:28:d0:b1<br />Jan 9 22:12:13 probe kernel: ff:ff:ff:ff:ff:ff 94:eb:cd:2d:05:5f type 0608 lla b6:02:35:28:d0:b1<br />Jan 9 22:25:43 probe kernel: ff:ff:ff:ff:ff:ff 84:8e:df:11:d2:e2 type 0608 lla b6:02:35:28:d0:b1<br />Jan 9 22:25:44 probe kernel: ff:ff:ff:ff:ff:ff 84:8e:df:11:d2:e2 type 0608 lla b6:02:35:28:d0:b1<br />Jan 9 22:27:11 probe kernel: ff:ff:ff:ff:ff:ff 94:eb:cd:2d:05:5f type 0608 lla b6:02:35:28:d0:b1<br />Jan 9 22:27:11 probe kernel: ff:ff:ff:ff:ff:ff 94:eb:cd:2d:05:5f type 0608 lla b6:02:35:28:d0:b1<br />Jan 9 22:27:32 probe kernel: ff:ff:ff:ff:ff:ff 02:3b:77:1f:48:00 type 0608 lla b6:02:35:28:d0:b1<br />Jan 9 22:27:32 probe kernel: 02:3b:77:1f:48:00 52:54:00:12:34:56 type 0608 lla b6:02:35:28:d0:b1<br />Jan 9 22:28:41 probe kernel: ff:ff:ff:ff:ff:ff 02:3b:77:1f:48:00 type 0608 lla b6:02:35:28:d0:b1</p>
<p>re0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500<br /> options=19<RXCSUM,VLAN_MTU,VLAN_HWTAGGING><br /> inet6 fe80::d63d:7eff:fe48:ab9d%re0 prefixlen 64 scopeid 0x1<br /> ether d4:3d:7e:48:ab:9d<br /> media: Ethernet autoselect (1000baseT <full-duplex>)<br /> status: active</p>
<p>bridge0: flags=8043<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500<br /> inet6 fe80::b402:35ff:fe28:d0b1%bridge0 prefixlen 64 scopeid 0x3<br /> inet 172.29.1.195 netmask 0xffffff00 broadcast 172.29.1.255<br /> ether b6:02:35:28:d0:b1<br /> priority 32768 hellotime 2 fwddelay 15 maxage 20<br /> member: tap0 flags=3<LEARNING,DISCOVER><br /> member: re0 flags=37<LEARNING,DISCOVER,STP,DESIGNATED,ROOT><br /> port 1 priority 128 pathcost 55 forwarding<br /> bondweight 1<br /> designated root: 8000b6023528d0b1<br /> designated bridge: 8000b6023528d0b1<br /> designated cost: 54<br /> designated port: 0</p>
<p>There's no hints on how bridge should be set up also. The recipe that works for me flawlessly is:</p>
<p>1. Clone one bridge interface:<br /> cloned_interfaces=bridge0</p>
<p>1. Bring child interfaces up:<br /> ifconfig_re0=up</p>
<p>2. Set up inet on the bridge in first configuration directive:<br /> ifconfig_bridge0=DHCP<br />or:<br /> ifconfig_bridge0='inet 172.29.1.100/24'</p>
<p>3. Add other interfaces:<br /> ifconfig_bridge0_alias0='addm re0 stp re0'</p>
<p>Just to pinpoint - FreeBSD guide page is fine about bridges except that DHCP will not work in aliases.</p> DragonFlyBSD - Bug #2252 (New): snd_hda not useable if loaded via /boot/loader.confhttps://bugs.dragonflybsd.org/issues/22522011-12-05T19:58:43Zxbit
<p>When loading snd_hda from /boot/loader.conf it is loaded, but cannot be used and configured. At least audio/moc does not work, it is unable to use the OSS interface. But after unloading and loading snd_hda again the sound card is useable.</p>
<p>As a workaround I added "/sbin/kldload snd_hda" to /etc/rc.local and then the soundcard is useable form audio/moc as OSS device.</p>
<p>snd_hda was the only sound kernel module that has been loaded via /boot/loader.conf.</p>
<p>Kernel configuration is GENERIC x86_64 (v2.12.0.23.gec4cf).</p> DragonFlyBSD - Bug #1714 (New): hwpmchttps://bugs.dragonflybsd.org/issues/17142010-04-03T18:59:28Zalexh
<p>I've put together Aggelos' original patches to import hwpmc from FreeBSD into <br />one place. Each file is prefixed with a number indicating the order of the <br />original submissions,<br /><a class="external" href="http://leaf.dragonflybsd.org/~alexh/hwpmc/">http://leaf.dragonflybsd.org/~alexh/hwpmc/</a></p>
<p>FWIW I think this is a nice thing to have and it would be nice if someone would <br />step up to firstly make the patches apply cleanly to master, then import them as <br />commits into git and if possible, make all the features work ;)</p>
<p>Cheers,<br />Alex</p>
<p>The original mail to submit@ was:<br />Hello,</p>
<p>this port of hwpmc ( start here: <a class="external" href="http://wiki.freebsd.org/PmcTools">http://wiki.freebsd.org/PmcTools</a> ) has<br />been stagnating on my hard disk for some months now. I'm finally<br />submitting it for inclusion because</p>
<p>a) the parts that work might be useful to someone and, more importantly,<br />b) complaints and bug reports might help get me off my butt and fix the<br /> remaining issues.</p>
<p>I've taken the time to split the patches so that people can review them<br />easily (the original freebsd code is submitted as .tgz since I'm not<br />interested in your review of that).</p>
<p>Please apply patches / extract tarballs in numerical order. I'll be a<br />bit surprised if there are no omissions/duplicate patches, but at least<br />my build test for world/kernel worked.</p>
<p>You will need these lines in your kernel config. See the manual pages<br />for usage examples.</p>
<p>options HWPMC_HOOKS<br />#device hwpmc</p>
<p>Testing status:</p>
<p>feature test status</p>
<p>global counting pmc tested, works<br />process counting pmc tested, works [0]<br />descendent tracking for<br />process counting pmc tested, works [0]<br />global sampling pmc possibly broken<br />process sampling pmc broken<br />logfile output untested<br />mapfilename untested<br />gprof execution profiles untested<br />SMP untested [1]<br />threaded (lwp) programs untested</p>
<p>[0] May still have bugs of course, test it out!<br />[1] Not even compile-tested</p> DragonFlyBSD - Bug #1538 (New): mountroot should probe file systemshttps://bugs.dragonflybsd.org/issues/15382009-09-28T01:48:34Zcorecode
<p>When mounting root from hammer, it is necessary to specify the file <br />system type in the vfs.root.mountfrom setting, otherwise the machine <br />will just be unhappy and issue the mountroot prompt (or rather, directly <br />go to ddb, see other bug report). This is very inconvenient and <br />irritating. The kernel should try all available file systems to mount root.</p>
<p>Possibly this should also be extended to mount itself, but this bug <br />report only deals with the mountroot issue.</p> DragonFlyBSD - Bug #1532 (New): jemalloc doesn't work on DragonFlyhttps://bugs.dragonflybsd.org/issues/15322009-09-25T19:10:21Zhasso
<p>jemalloc is a malloc(3) implementation from FreeBSD and for some reason <br />increasingly popular in various software pieces dealing ECMAscript and related <br />stuff. This means browsers (Firefox, Chrome), but also Gnash for example. <br />Unfortunately jemalloc doesn't work with DragonFly. Matt explained why some <br />time ago:</p>
<p><a class="external" href="http://leaf.dragonflybsd.org/mailarchive/users/2009-04/msg00162.html">http://leaf.dragonflybsd.org/mailarchive/users/2009-04/msg00162.html</a></p> DragonFlyBSD - Bug #679 (New): Netgraph backward compatibility for old *LEN constantshttps://bugs.dragonflybsd.org/issues/6792007-06-05T07:56:01Znant
<p>Maintain the old *LEN netgraph constants around for some time to allow<br />the building of earlier mpd (Multi-link PPP Daemon).</p>
<p>Pointed out by: Alexander Motin <<a class="email" href="mailto:mav@freebsd.org">mav@freebsd.org</a>><br />Obtained from: FreeBSD</p>
<p>BTW: Do we need a BURN_BRIDGES kernel option?</p>
<p>Thanks,<br />Nuno</p> DragonFlyBSD - Bug #600 (New): /sys/libkern/karc4randomhttps://bugs.dragonflybsd.org/issues/6002007-04-11T17:14:04Zrobin_carey5
<p>What is the point of keeping/using the in-kernel arc4<br />random number generator when you already have a very<br />good/superior IBAA/L15 random number generator.</p>
<p>If you need a u_int32_t quantity then simply add a<br />function to /sys/kern/kern_nrandom.c to produce a<br />u_int32_t.</p>
<p>--</p>
<p>Some issues with /sys/libkern/karc4random.c :</p>
<p>(a) If you intend to keep /sys/libkern/karc4random.c I<br />recommend you make a modification to it to improve<br />performance: Every time the karc4_random() function is<br />called it calls getmicrotime(), to check the time, and<br />it also checks the number of runs made, to see if it<br />should reseed itself. You can make a big performance<br />improvement by removing this call to getmicrotime()<br />and instead simply checking the number of runs to<br />determine when it should reseed itself.</p>
<p>(b) The karc4random.c file uses u_int8_t types for<br />arc4_i, arc4_j and arc4_t so there is no need for the<br />% 256 operation - another performance improvement.</p>
<p>(c) In arc4_init() you are throwing away 256*4 bytes<br />of output, when you only need to throw away the first<br />256 bytes of output.</p>
<p>Sincerely,<br />R Carey.</p>
<pre><code>_<em><i></em></i>__<em>_</em>_______________________________________________<br />Yahoo! Answers - Got a question? Someone out there knows the answer. Try it<br />now.<br /><a class="external" href="http://uk.answers.yahoo.com/">http://uk.answers.yahoo.com/</a></code></pre>