Re: Questions about devices and input.
"Intron" <[EMAIL PROTECTED]> writes: > "Dag-Erling Smørgrav" <[EMAIL PROTECTED]> writes: > > "Sean Bryant" <[EMAIL PROTECTED]> writes: > > > I'm writing some cd buring software using burncd as a reference. > > > I was wondering if its possible to detect opening and closing of > > > the doors. > > Unfortunately, no. The drive may not even have a door. > Mr. smo/rgrav loves playing joke very much. No. Unlike you, I know what I'm talking about. > But most of CD/DVD drives have a door, though generally speaking, > software cannot detect the open/close status of a door directly. http://www.plextor.com/english/products/716AL.htm > However, software can command the drive to open/close its door. This is not what Sean wants. DES -- Dag-Erling Smørgrav - [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: Questions about devices and input.
Dag-Erling [iso-8859-1] Smo/rgrav wrote: "Intron" <[EMAIL PROTECTED]> writes: "Dag-Erling Smo/rgrav" <[EMAIL PROTECTED]> writes: > "Sean Bryant" <[EMAIL PROTECTED]> writes: > > I'm writing some cd buring software using burncd as a reference. > > I was wondering if its possible to detect opening and closing of > > the doors. > Unfortunately, no. The drive may not even have a door. Mr. smo/rgrav loves playing joke very much. No. Unlike you, I know what I'm talking about. But most of CD/DVD drives have a door, though generally speaking, software cannot detect the open/close status of a door directly. http://www.plextor.com/english/products/716AL.htm What I said is "most of". This kind of drive may do harm to your CD/DVD disc if you fail to operate carefully enough. However, software can command the drive to open/close its door. This is not what Sean wants. I want to tell Sean that he is not worth spending time in finding how to detect the open/close status of a drive door. If his program can open/close/lock/unlock the door and detect whether recording medium (CD/DVD) is present in drive or not and whether the drive is locked or not, that's enough, just as Nero (www.nero.com) can do. DES -- Dag-Erling Smo/rgrav - [EMAIL PROTECTED] From Beijing, China ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Questions about devices and input.
"Intron" <[EMAIL PROTECTED]> writes: > "Dag-Erling Smørgrav" <[EMAIL PROTECTED]> writes: > > "Intron" <[EMAIL PROTECTED]> writes: > > > However, software can command the drive to open/close its door. > > This is not what Sean wants. > I want to tell Sean that he is not worth spending time in finding > how to detect the open/close status of a drive door. I told him that in my first message, which you found so laughable. How does ridiculing me help Sean? DES -- Dag-Erling Smørgrav - [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: Questions about devices and input.
Dag-Erling [iso-8859-1] Smo/rgrav wrote: "Intron" <[EMAIL PROTECTED]> writes: "Dag-Erling Smo/rgrav" <[EMAIL PROTECTED]> writes: > "Intron" <[EMAIL PROTECTED]> writes: > > However, software can command the drive to open/close its door. > This is not what Sean wants. I want to tell Sean that he is not worth spending time in finding how to detect the open/close status of a drive door. I told him that in my first message, which you found so laughable. How does ridiculing me help Sean? DES -- Dag-Erling Smo/rgrav - [EMAIL PROTECTED] Can your unilateral judgement give real help to Sean? Actually, in the view of software programmer, that kind of no-drawer drive has the same control mode as drawer drive. From Beijing, China ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
exception handling in kernel code
Hi! I'm trying to write kernel code where exceptions are unavoidable. To clarify , I need to recover after GP (general protection) exception on i386 cpu and return an error in that case. Unfortunately, looking in trap.c kernel code I can't find any exception handling mechanism except inserting hooks into trap.c. So, the question is: how can one recover after exception in kernel code? AFAIK, linux build special exception table from various __ex_table sections to allow placing recover code into .fixup section. Does any such mechanism exists in freebsd? Thanks! -- Stanislav Sedov MBSD labs, Inc. <[EMAIL PROTECTED]> Россия, Москва http://mbsd.msk.ru If the facts don't fit the theory, change the facts. -- A. Einstein PGP fingerprint: F21E D6CC 5626 9609 6CE2 A385 2BF5 5993 EB26 9581 signature.asc Description: PGP signature
Re: Questions about devices and input.
"Intron" <[EMAIL PROTECTED]> writes: > "Dag-Erling Smo/rgrav" <[EMAIL PROTECTED]> writes: > > How does ridiculing me help Sean? > Can your unilateral judgement give real help to Sean? Welcome to my kill file. Enjoy your stay. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Unable to get RealTek 8139C+ to work with re(4) under FreeBSD 6.1
i've got a single board computer with VIA C3 Samuel 2, 256MB RAM and 4
onboard Realtek 8139C+ NICs. I'm attempting to get FreeBSD 6.1-STABLE
working on them, but the realtek NICs just don't seem to want to work.
booting up led to a kernel trap with the following,
rlphy0: on miibus0
rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
re0: Ethernet address: 00:60:e0:e1:21:d7
re0: diagnostic failed, failed to receive packet in loopback mode
re0: attach aborted due to hardware diag failure
kernel trap 12 with interrupts disabled
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x74
fault code = supervisor read, page not present
instruction pointer = 0x20:0xc0625d45
stack pointer = 0x28:0xc2420a50
frame pointer = 0x28:0xc2420a54
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= resume, IOPL = 0
current process = 0 (swapper)
trap number = 12
panic: page fault
Uptime: 1s
looking through /usr/src/sys/dev/re/if_re.c, and reading this thread,
http://lists.freebsd.org/pipermail/freebsd-current/2004-June/029373.html,
i've patched if_re.c to skip the re_diag() routine if the NIC is not a
Realtek 8169. the patch follows,
- CUT HERE -
--- if_re.c.origMon Aug 14 14:43:05 2006
+++ if_re.c Mon Aug 14 14:42:16 2006
@@ -1235,12 +1235,14 @@
ether_ifattach(ifp, eaddr);
/* Perform hardware diagnostic. */
- error = re_diag(sc);
+ if (sc->rl_type == RL_8169) {
+ error = re_diag(sc);
- if (error) {
- device_printf(dev, "attach aborted due to hardware diag
failure\n");
- ether_ifdetach(ifp);
- goto fail;
+ if (error) {
+ device_printf(dev, "attach aborted due to hardware diag
failure\n");
+ ether_ifdetach(ifp);
+ goto fail;
+ }
}
/* Hook interrupt last to avoid having to lock softc */
- CUT HERE -
with the patch applied, the kernel trap goes away and the box boots up.
however, though the link light comes on, the device is effectively
unuseable for ethernet traffic. nothing seems to go in or out of the device
with ping and other tcp/udp traffic failing. note the media state and the
missing status line from the ifconfig output.
any clue as to what's happenning here or to pointers/patches to fix this
would be much appreciated. i've got the box sitting beside me, so testing
patches et al would be highly possible.
dmesg, ifconfig and pciconf outputs are as follows:
re0: port 0xe300-0xe3ff mem
0xed80-0xed8000ff irq 5 at device 16.0 on pci0
miibus0: on re0
rlphy0: on miibus0
rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
re0: Ethernet address: 00:60:e0:e1:21:d7
re1: port 0xe400-0xe4ff mem
0xed801000-0xed8010ff irq 12 at device 17.0 on pci0
miibus1: on re1
rlphy1: on miibus1
rlphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
re1: Ethernet address: 00:60:e0:e1:21:d6
re2: port 0xe500-0xe5ff mem
0xed802000-0xed8020ff irq 10 at device 18.0 on pci0
miibus2: on re2
rlphy2: on miibus2
rlphy2: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
re2: Ethernet address: 00:60:e0:e1:21:d5
re3: port 0xe600-0xe6ff mem
0xed803000-0xed8030ff irq 11 at device 19.0 on pci0
miibus3: on re3
rlphy3: on miibus3
rlphy3: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
re3: Ethernet address: 00:60:e0:e1:21:d4
# ifconfig -a
re0: flags=8843 mtu 1500
options=18
inet 192.168.1.141 netmask 0xff00 broadcast 192.168.1.255
ether 00:60:e0:e1:21:d7
media: Ethernet autoselect (none)
re1: flags=8843 mtu 1500
options=18
inet 0.0.0.0 netmask 0xff00 broadcast 255.255.255.255
ether 00:60:e0:e1:21:d6
media: Ethernet autoselect (none)
re2: flags=8802 mtu 1500
options=18
ether 00:60:e0:e1:21:d5
media: Ethernet autoselect (none)
re3: flags=8802 mtu 1500
options=18
ether 00:60:e0:e1:21:d4
media: Ethernet autoselect (none)
# pciconf -l -v
[EMAIL PROTECTED]:16:0: class=0x02 card=0x813910ec chip=0x813910ec rev=0x20
hdr=0x00
class= network
subclass = ethernet
[EMAIL PROTECTED]:17:0: class=0x02 card=0x813910ec chip=0x813910ec rev=0x20
hdr=0x00
class= network
subclass = ethernet
[EMAIL PROTECTED]:18:0: class=0x02 card=0x813910ec chip=0x813910ec rev=0x20
hdr=0x00
class= network
subclass = ethernet
[EMAIL PROTECTED]:19:0: class=0x02 card=0x813910ec chip=0x813910ec rev=0x20
hdr=0x00
class= network
subclass = ethernet
--
Regards, /\_/\ "All dogs go to heaven."
[EMAIL PROTECTED](0 0) http://www.openmalaysiablog.com/
+==oOO--(_)--OOo---
Re: Questions about devices and input.
Dag-Erling [iso-8859-1] Smo/rgrav wrote: "Intron" <[EMAIL PROTECTED]> writes: "Dag-Erling Smo/rgrav" <[EMAIL PROTECTED]> writes: > How does ridiculing me help Sean? Can your unilateral judgement give real help to Sean? Welcome to my kill file. Enjoy your stay. DES -- Dag-Erling Smo/rgrav - [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]" That's your own freedom to configure your own spam filter. From Beijing, China ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Unable to get RealTek 8139C+ to work with re(4) under FreeBSD 6.1
On Mon, Aug 14, 2006 at 05:22:23PM +0800, Dinesh Nair wrote:
>
> i've got a single board computer with VIA C3 Samuel 2, 256MB RAM and 4
> onboard Realtek 8139C+ NICs. I'm attempting to get FreeBSD 6.1-STABLE
> working on them, but the realtek NICs just don't seem to want to work.
> booting up led to a kernel trap with the following,
>
> rlphy0: on miibus0
> rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
> re0: Ethernet address: 00:60:e0:e1:21:d7
> re0: diagnostic failed, failed to receive packet in loopback mode
> re0: attach aborted due to hardware diag failure
> kernel trap 12 with interrupts disabled
>
> Fatal trap 12: page fault while in kernel mode
> fault virtual address = 0x74
> fault code = supervisor read, page not present
> instruction pointer = 0x20:0xc0625d45
> stack pointer = 0x28:0xc2420a50
> frame pointer = 0x28:0xc2420a54
> code segment= base 0x0, limit 0xf, type 0x1b
>= DPL 0, pres 1, def32 1, gran 1
> processor eflags= resume, IOPL = 0
> current process = 0 (swapper)
> trap number = 12
> panic: page fault
> Uptime: 1s
>
> looking through /usr/src/sys/dev/re/if_re.c, and reading this thread,
> http://lists.freebsd.org/pipermail/freebsd-current/2004-June/029373.html,
> i've patched if_re.c to skip the re_diag() routine if the NIC is not a
> Realtek 8169. the patch follows,
>
> - CUT HERE -
> --- if_re.c.orig Mon Aug 14 14:43:05 2006
> +++ if_re.c Mon Aug 14 14:42:16 2006
> @@ -1235,12 +1235,14 @@
> ether_ifattach(ifp, eaddr);
>
> /* Perform hardware diagnostic. */
> -error = re_diag(sc);
> +if (sc->rl_type == RL_8169) {
> +error = re_diag(sc);
>
> -if (error) {
> -device_printf(dev, "attach aborted due to hardware diag
> failure\n");
> -ether_ifdetach(ifp);
> -goto fail;
> +if (error) {
> +device_printf(dev, "attach aborted due to hardware
> diag failure\n");
> +ether_ifdetach(ifp);
> +goto fail;
> +}
> }
>
> /* Hook interrupt last to avoid having to lock softc */
> - CUT HERE -
>
> with the patch applied, the kernel trap goes away and the box boots up.
> however, though the link light comes on, the device is effectively
> unuseable for ethernet traffic. nothing seems to go in or out of the device
> with ping and other tcp/udp traffic failing. note the media state and the
> missing status line from the ifconfig output.
>
> any clue as to what's happenning here or to pointers/patches to fix this
> would be much appreciated. i've got the box sitting beside me, so testing
> patches et al would be highly possible.
>
Recent changes from wpaul disabled re_diag() routine by default so it
wouldn't trigger the panic you've seen anymore.
However I've seen one user reported re(4) breakage on stable.
http://lists.freebsd.org/pipermail/freebsd-stable/2006-August/027356.html
Please try latest stable and show your results. If it still does not
work please let us know. I don't have 8139C+ based NICs so it would be
difficult for me to fix the issue. :-(
--
Regards,
Pyun YongHyeon
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Unable to get RealTek 8139C+ to work with re(4) under FreeBSD 6.1
On 08/14/06 17:22 Dinesh Nair said the following: i've got a single board computer with VIA C3 Samuel 2, 256MB RAM and 4 onboard Realtek 8139C+ NICs. I'm attempting to get FreeBSD 6.1-STABLE working on them, but the realtek NICs just don't seem to want to work. booting up led to a kernel trap with the following, based on a pointer from luigi rizzo, i disabled the check for the 8139C+ in /usr/src/sys/pci/if_rl.c to force the rl driver to bind to the card, and that seemed to do the trick in getting it to work. ifconfig still shows that the media is set to 'none' and a missing status line, but the box is pingable at the least. -- Regards, /\_/\ "All dogs go to heaven." [EMAIL PROTECTED](0 0) http://www.openmalaysiablog.com/ +==oOO--(_)--OOo==+ | for a in past present future; do| | for b in clients employers associates relatives neighbours pets; do | | echo "The opinions here in no way reflect the opinions of my $a $b." | | done; done | +=+ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Unable to get RealTek 8139C+ to work with re(4) under FreeBSD 6.1
On 08/14/06 18:39 Pyun YongHyeon said the following: Recent changes from wpaul disabled re_diag() routine by default so it i disabled re_diag() in /usr/src/sys/dev/if_re.c, and that caused the kernel trap to go away, as per my original email. also, see my followup email (to myself) in which i disabled the check for the 8139C+, forcing it to be recognized by the rl driver and this seems to make it work. However I've seen one user reported re(4) breakage on stable. http://lists.freebsd.org/pipermail/freebsd-stable/2006-August/027356.html that seems to be exactly the problem i initially observed as well. Please try latest stable and show your results. If it still does not work please let us know. I don't have 8139C+ based NICs so it would be i am on a recent stable, circa two weeks ago as well. have there been significant changes to the re driver since ? -- Regards, /\_/\ "All dogs go to heaven." [EMAIL PROTECTED](0 0) http://www.openmalaysiablog.com/ +==oOO--(_)--OOo==+ | for a in past present future; do| | for b in clients employers associates relatives neighbours pets; do | | echo "The opinions here in no way reflect the opinions of my $a $b." | | done; done | +=+ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Unable to get RealTek 8139C+ to work with re(4) under FreeBSD 6.1
On Mon, Aug 14, 2006 at 06:55:58PM +0800, Dinesh Nair wrote: > > On 08/14/06 18:39 Pyun YongHyeon said the following: > >Recent changes from wpaul disabled re_diag() routine by default so it > > i disabled re_diag() in /usr/src/sys/dev/if_re.c, and that caused the > kernel trap to go away, as per my original email. also, see my followup > email (to myself) in which i disabled the check for the 8139C+, forcing it > to be recognized by the rl driver and this seems to make it work. > AFAIK 8139C+ provides 8139 compatible mode which doesn't use descriptor based transfer mechanism. As you know this mode really sucks and need much more CPU power to saturate the link. So I don't think it's good idea to make rl(4) serve 8139C+. > >However I've seen one user reported re(4) breakage on stable. > >http://lists.freebsd.org/pipermail/freebsd-stable/2006-August/027356.html > > that seems to be exactly the problem i initially observed as well. > > >Please try latest stable and show your results. If it still does not > >work please let us know. I don't have 8139C+ based NICs so it would be > > i am on a recent stable, circa two weeks ago as well. have there been > significant changes to the re driver since ? > Yes. What `ident /boot/kernel/if_re.ko` shows? -- Regards, Pyun YongHyeon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Unable to get RealTek 8139C+ to work with re(4) under FreeBSD 6.1
On 08/14/06 19:09 Pyun YongHyeon said the following: really sucks and need much more CPU power to saturate the link. So I don't think it's good idea to make rl(4) serve 8139C+. perhaps, but re(4) doesn't work at the moment on this chipset, and i'd rather have something which works, albeit a little poorly, than something which doesn't. Yes. What `ident /boot/kernel/if_re.ko` shows? $FreeBSD: src/sys/dev/re/if_re.c,v 1.46.2.19 2006/08/07 02:38:07 yongari Exp $ and the latest if_rlreg.c which i pulled down shows, $FreeBSD: src/sys/pci/if_rlreg.h,v 1.51.2.7 2006/08/01 17:36:50 wpaul Exp $ i'm not using the loadable modules though, and am building the re(4) device into the kernel directly. the symptoms remain the same, i.e. IP traffic doesn't flow at all, though 'arp -an' does show the ethernet address of the other box attempting to ping this. the OP at http://lists.freebsd.org/pipermail/freebsd-stable/2006-August/027356.html mentioned that it was working fine before breakage was introduced relatively recently (~ 2 weeks ago), and thus something's changed in the interim which is causing this to happen. -- Regards, /\_/\ "All dogs go to heaven." [EMAIL PROTECTED](0 0) http://www.openmalaysiablog.com/ +==oOO--(_)--OOo==+ | for a in past present future; do| | for b in clients employers associates relatives neighbours pets; do | | echo "The opinions here in no way reflect the opinions of my $a $b." | | done; done | +=+ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Unable to get RealTek 8139C+ to work with re(4) under FreeBSD 6.1
Dinesh Nair <[EMAIL PROTECTED]> writes:
> the symptoms remain the same, i.e. IP traffic doesn't flow at all,
> though 'arp -an' does show the ethernet address of the other box
> attempting to ping this.
'tcpdump -n -e -i re0' shows nothing?
have you tried disabling rx / tx checksum offloading? ('ifconfig re0
-rxcsum -txcsum')
DES
--
Dag-Erling Smørgrav - [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: Unable to get RealTek 8139C+ to work with re(4) under FreeBSD 6.1
On Mon, Aug 14, 2006 at 08:03:35PM +0800, Dinesh Nair wrote: > > > On 08/14/06 19:09 Pyun YongHyeon said the following: > >really sucks and need much more CPU power to saturate the link. > >So I don't think it's good idea to make rl(4) serve 8139C+. > > perhaps, but re(4) doesn't work at the moment on this chipset, and i'd > rather have something which works, albeit a little poorly, than something > which doesn't. > Ok. > >Yes. What `ident /boot/kernel/if_re.ko` shows? > > $FreeBSD: src/sys/dev/re/if_re.c,v 1.46.2.19 2006/08/07 02:38:07 yongari > Exp $ > > and the latest if_rlreg.c which i pulled down shows, > > $FreeBSD: src/sys/pci/if_rlreg.h,v 1.51.2.7 2006/08/01 17:36:50 wpaul Exp $ > > i'm not using the loadable modules though, and am building the re(4) device > into the kernel directly. > > the symptoms remain the same, i.e. IP traffic doesn't flow at all, though > 'arp -an' does show the ethernet address of the other box attempting to > ping this. > Ok, this is important thing. It means Rx part works as expected. Can you see tcpdump output on Tx side while ping command is in progress? > the OP at > http://lists.freebsd.org/pipermail/freebsd-stable/2006-August/027356.html > mentioned that it was working fine before breakage was introduced > relatively recently (~ 2 weeks ago), and thus something's changed in the > interim which is causing this to happen. > -- Regards, Pyun YongHyeon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: exception handling in kernel code
On Monday 14 August 2006 02:46, Stanislav Sedov wrote: > Hi! > > I'm trying to write kernel code where exceptions are unavoidable. > To clarify , I need to recover after GP (general protection) exception > on i386 cpu and return an error in that case. > Unfortunately, looking in trap.c kernel code I can't find any exception > handling mechanism except inserting hooks into trap.c. > > So, the question is: how can one recover after exception in kernel > code? AFAIK, linux build special exception table from various __ex_table > sections to allow placing recover code into .fixup section. Does any such > mechanism exists in freebsd? > > Thanks! You can make use of pcb_onfault to recover from a page fault, but that's about it. Kernel code is expected to not generate exceptions. :) -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: amd64 port on Prescott 2M?
On Saturday 12 August 2006 14:47, Mike Meyer wrote: > I just got a Prescott 2M core. While it's marketed as a P4, it's got > all the features of the Xeon Nocona core enabled (except for MP > support, of course): MMX, SSE, SSE2, SSE3, HT, EM64T, EIST and XD. > > The question is whether or not the AMD64 build of FreeBSD - which runs > on Nocona - will run on this. If someone knows for sure it won't run, > they'll save me the time of trying it. If it has EM64T it should run FreeBSD/amd64. -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: exception handling in kernel code
On Mon, 14 Aug 2006 09:32:57 -0400 John Baldwin <[EMAIL PROTECTED]> mentioned: > > You can make use of pcb_onfault to recover from a page fault, but that's > about it. Kernel code is expected to not generate exceptions. :) > Thanks a lot! I'll try it. To clarify: I've implemented driver to allow user-level code to read MSRs (Model specific registers) (like linux's /dev/cpu/msr). It's required for some programs like x86info. As long as not all MSRs documented and reading/writing unexistent MSR leads to GP fault, I need to recover in that case. -- Stanislav Sedov MBSD labs, Inc. <[EMAIL PROTECTED]> Россия, Москва http://mbsd.msk.ru If the facts don't fit the theory, change the facts. -- A. Einstein PGP fingerprint: F21E D6CC 5626 9609 6CE2 A385 2BF5 5993 EB26 9581 signature.asc Description: PGP signature
Re: amd64 port on Prescott 2M?
In <[EMAIL PROTECTED]>, John Baldwin <[EMAIL PROTECTED]> typed: > On Saturday 12 August 2006 14:47, Mike Meyer wrote: > > I just got a Prescott 2M core. While it's marketed as a P4, it's got > > all the features of the Xeon Nocona core enabled (except for MP > > support, of course): MMX, SSE, SSE2, SSE3, HT, EM64T, EIST and XD. > > > > The question is whether or not the AMD64 build of FreeBSD - which runs > > on Nocona - will run on this. If someone knows for sure it won't run, > > they'll save me the time of trying it. > If it has EM64T it should run FreeBSD/amd64. That's what I would expect, but that's not what the online docs I found said. I could have sworn it just talked about the Xeon nocona, but I can't find it now :-(. The HARDWARE.TXT file on the distribution does, but it's not accurate (it says the 5xx series Prescott's don't have EM64T, but Intel docs some of the 5x1's as having EM64T). It doesn't talk about the Cedar Mill P4 core or the Pentium D's at all. I'll look into submitting a doc PR to change this. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Questions about devices and input.
Thanks. Was just checking. On 8/14/06, Dag-Erling Smørgrav <[EMAIL PROTECTED]> wrote: "Sean Bryant" <[EMAIL PROTECTED]> writes: > I'm writing some cd buring software using burncd as a reference. I was > wondering if its possible to detect opening and closing of the doors. Unfortunately, no. The drive may not even have a door. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] -- Sean Bryant ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Questions about devices and input.
How about when media is loaded. I have a detection routine that'll ask for media, but what about when any media is loaded? Is there some kind of event or some way I can be notified. On 8/14/06, Dag-Erling Smørgrav <[EMAIL PROTECTED]> wrote: "Sean Bryant" <[EMAIL PROTECTED]> writes: > I'm writing some cd buring software using burncd as a reference. I was > wondering if its possible to detect opening and closing of the doors. Unfortunately, no. The drive may not even have a door. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] -- Sean Bryant ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: exception handling in kernel code
Stanislav Sedov wrote this message on Mon, Aug 14, 2006 at 19:47 +0600: > I've implemented driver to allow user-level code to read MSRs (Model > specific registers) (like linux's /dev/cpu/msr). It's required for > some programs like x86info. > > As long as not all MSRs documented and reading/writing unexistent MSR > leads to GP fault, I need to recover in that case. You should make a MD API for reading these out (if one doesn't already exist) that handle the faulting for you, and then have your driver hook into this api... I had to do something similar for accessing PCI config registers that don't exist and cause a fault... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: exception handling in kernel code
On Monday 14 August 2006 09:47, Stanislav Sedov wrote: > On Mon, 14 Aug 2006 09:32:57 -0400 > John Baldwin <[EMAIL PROTECTED]> mentioned: > > > > You can make use of pcb_onfault to recover from a page fault, but that's > > about it. Kernel code is expected to not generate exceptions. :) > > > > Thanks a lot! I'll try it. > > To clarify: > > I've implemented driver to allow user-level code to read MSRs (Model > specific registers) (like linux's /dev/cpu/msr). It's required for > some programs like x86info. > > As long as not all MSRs documented and reading/writing unexistent MSR > leads to GP fault, I need to recover in that case. Hmm pcb_onfault won't help with this (it does PF#, not GP#). You will have to hack trap() to provide some sort of fallback for your case. -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: exception handling in kernel code
On Mon, 14 Aug 2006 11:15:22 -0700 John-Mark Gurney <[EMAIL PROTECTED]> mentioned: > > You should make a MD API for reading these out (if one doesn't already > exist) that handle the faulting for you, and then have your driver hook > into this api... > > I had to do something similar for accessing PCI config registers > that don't exist and cause a fault... > Do you know some examples to look at? The problem is that i can't make modifications in trap.c or anywhere else in src tree as such driver isn't likely to become a part of FreeBSD kernel. Thanks! -- Stanislav Sedov MBSD labs, Inc. <[EMAIL PROTECTED]> Россия, Москва http://mbsd.msk.ru If the facts don't fit the theory, change the facts. -- A. Einstein PGP fingerprint: F21E D6CC 5626 9609 6CE2 A385 2BF5 5993 EB26 9581 signature.asc Description: PGP signature
Re: Questions about devices and input.
"Sean Bryant" <[EMAIL PROTECTED]> writes: > How about when media is loaded. I have a detection routine that'll ask > for media, but what about when any media is loaded? Is there some kind > of event or some way I can be notified. Sorry, no. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Intel S5000PAL server board
Hi, Is anyone here running 6.1 on Intel S5000PAL with dual-core Xeons? -- Bob Bishop +44 (0)118 940 1243 [EMAIL PROTECTED] fax +44 (0)118 940 1295 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Questions about devices and input.
Thanks anyway :( On 8/14/06, Dag-Erling Smørgrav <[EMAIL PROTECTED]> wrote: "Sean Bryant" <[EMAIL PROTECTED]> writes: > How about when media is loaded. I have a detection routine that'll ask > for media, but what about when any media is loaded? Is there some kind > of event or some way I can be notified. Sorry, no. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] -- Sean Bryant ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: exception handling in kernel code
Stanislav Sedov wrote this message on Mon, Aug 14, 2006 at 23:12 +0600: > On Mon, 14 Aug 2006 11:15:22 -0700 > John-Mark Gurney <[EMAIL PROTECTED]> mentioned: > > > > You should make a MD API for reading these out (if one doesn't already > > exist) that handle the faulting for you, and then have your driver hook > > into this api... > > > > I had to do something similar for accessing PCI config registers > > that don't exist and cause a fault... > > Do you know some examples to look at? The problem is that i can't make > modifications in trap.c or anywhere else in src tree as such driver > isn't likely to become a part of FreeBSD kernel. That will be very difficult to do then The work I did for accessing PCI config registers had to be merged into the tree... Maybe introducing a method for adding a MD callback to the trap handler for other modules that need this?Short of modifing the function in real time to point to your code, I don't have any suggestions... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Questions about devices and input.
The section 4.11.1 "Removable Media Status Notification feature set" of ATA/ATAPI-7 (http://t13.org/docs2004/d1532v1r4b-ATA-ATAPI-7.pdf) reads, d) Host system periodically checks media status using the GET MEDIA STATUS command to determine if any of the following events occurred: - no media is present in the device (NM). - media was changed since the last command (MC). - a media change request has occurred (MCR). - media is write protected (WP). From Beijing, China Sean Bryant wrote: Thanks anyway :( On 8/14/06, Dag-Erling Smo/rgrav <[EMAIL PROTECTED]> wrote: "Sean Bryant" <[EMAIL PROTECTED]> writes: > How about when media is loaded. I have a detection routine that'll ask > for media, but what about when any media is loaded? Is there some kind > of event or some way I can be notified. Sorry, no. DES -- Dag-Erling Smo/rgrav - [EMAIL PROTECTED] -- Sean Bryant ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Questions about devices and input.
In message: <[EMAIL PROTECTED]> [EMAIL PROTECTED] (Dag-Erling Smørgrav) writes: : "Sean Bryant" <[EMAIL PROTECTED]> writes: : > How about when media is loaded. I have a detection routine that'll ask : > for media, but what about when any media is loaded? Is there some kind : > of event or some way I can be notified. : : Sorry, no. The only way is to poll the device from time to time :-( Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
The optimization of malloc(3): FreeBSD vs GNU libc
One day, a friend told me that his program was 3 times slower under FreeBSD 6.1 than under GNU/Linux (from Redhat 7.2 to Fedora Core 5). I was astonished by the real repeatable performance difference on AMD Athlon XP 2500+ (1.8GHz, 512KB L2 Cache). After hacking, I found that the problem is nested in malloc(3) of FreeBSD libc. Download the testing program: http://ftp.intron.ac/tmp/fdtd.tar.bz2 You may try to compile the program WITHOUT the macro "MY_MALLOC" defined (in Makefile) to use malloc(3) provided by FreeBSD 6.1. Then, time the running of the binary (on Athlon XP 2500+): #/usr/bin/time ./fdtd.FreeBSD 500 500 1000 ... 165.24 real 164.19 user 0.02 sys Please try to recompile the program (Remember to "make clean") WITH the macro "MY_MALLOC" defined (in Makefile) to use my own simple implementation of malloc(3) (i.e. my_malloc() in cal.c). And time the running again: #/usr/bin/time ./fdtd.FreeBSD 500 500 1000 ... 50.41 real49.95 user 0.04 sys You may repeat this testing again and again. I guess this kind of performance difference comes from: 1. His program uses malloc(3) to obtain so many small memory blocks. 2. In this case, FreeBSD malloc(3) obtains small memory blocks from kernel and pass them to application. But malloc(3) of GNU libc obtains large memory blocks from kernel and splits & reallocates them in small blocks to application. You may verify my judgement with truss(1). 3. The way of FreeBSD malloc(3) makes VM page mapping too chaotic, which reduces the efficiency of CPU L2 Cache. In contrast, my my_malloc() simulates the behavior of GNU libc malloc(3) partially and avoids the over-chaos. Callgrind is broken under FreeBSD, or I will verify my guess with it. I have also verified the program on Intel Pentium 4 511 (2.8GHz, 1MB L2 cache, running FreeBSD 6.1 i386 though this CPU supports EM64T) /usr/bin/time ./fdtd.FreeBSD 500 500 1000 ... 185.30 real 184.28 user 0.02 sys /usr/bin/time ./fdtd.FreeBSD 500 500 1000 ... 36.31 real35.94 user 0.03 sys NOTE: you probably cannot see the performance difference on CPU with small L2 cache such as Intel Celeron 1.7GHz with 128 KB L2 Cache. From Beijing, China ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: The optimization of malloc(3): FreeBSD vs GNU libc
On Tue, Aug 15, 2006 at 07:10:47AM +0800, Intron wrote: > One day, a friend told me that his program was 3 times slower under > FreeBSD 6.1 than under GNU/Linux (from Redhat 7.2 to Fedora Core 5). > I was astonished by the real repeatable performance difference on > AMD Athlon XP 2500+ (1.8GHz, 512KB L2 Cache). > > After hacking, I found that the problem is nested in malloc(3) of > FreeBSD libc. > > Download the testing program: http://ftp.intron.ac/tmp/fdtd.tar.bz2 > > You may try to compile the program WITHOUT the macro "MY_MALLOC" > defined (in Makefile) to use malloc(3) provided by FreeBSD 6.1. > Then, time the running of the binary (on Athlon XP 2500+): > > #/usr/bin/time ./fdtd.FreeBSD 500 500 1000 > ... >165.24 real 164.19 user 0.02 sys > > Please try to recompile the program (Remember to "make clean") > WITH the macro "MY_MALLOC" defined (in Makefile) to use my own > simple implementation of malloc(3) (i.e. my_malloc() in cal.c). > And time the running again: > > #/usr/bin/time ./fdtd.FreeBSD 500 500 1000 > ... >50.41 real49.95 user 0.04 sys > > You may repeat this testing again and again. > > I guess this kind of performance difference comes from: > > 1. His program uses malloc(3) to obtain so many small memory blocks. > > 2. In this case, FreeBSD malloc(3) obtains small memory blocks from >kernel and pass them to application. > >But malloc(3) of GNU libc obtains large memory blocks from kernel >and splits & reallocates them in small blocks to application. > >You may verify my judgement with truss(1). > > 3. The way of FreeBSD malloc(3) makes VM page mapping too chaotic, which >reduces the efficiency of CPU L2 Cache. In contrast, my my_malloc() >simulates the behavior of GNU libc malloc(3) partially and avoids >the over-chaos. > > Callgrind is broken under FreeBSD, or I will verify my guess with it. > > I have also verified the program on Intel Pentium 4 511 (2.8GHz, 1MB > L2 cache, running FreeBSD 6.1 i386 though this CPU supports EM64T) > > >/usr/bin/time ./fdtd.FreeBSD 500 500 1000 > ... > 185.30 real 184.28 user 0.02 sys > > >/usr/bin/time ./fdtd.FreeBSD 500 500 1000 > ... >36.31 real35.94 user 0.03 sys > > NOTE: you probably cannot see the performance difference on CPU with >small L2 cache such as Intel Celeron 1.7GHz with 128 KB L2 Cache. In CURRENT we've replaced phkmalloc with jemalloc. It would be useful to see how this benchmark performs with that. I believe it does similar things. -- Brooke pgpn3r9Si2ag0.pgp Description: PGP signature
Re: The optimization of malloc(3): FreeBSD vs GNU libc
Sorry for intrusion. On Mon, 14 Aug 2006, Brooks Davis wrote: On Tue, Aug 15, 2006 at 07:10:47AM +0800, Intron wrote: One day, a friend told me that his program was 3 times slower under FreeBSD 6.1 than under GNU/Linux (from Redhat 7.2 to Fedora Core 5). I was astonished by the real repeatable performance difference on AMD Athlon XP 2500+ (1.8GHz, 512KB L2 Cache). After hacking, I found that the problem is nested in malloc(3) of FreeBSD libc. Download the testing program: http://ftp.intron.ac/tmp/fdtd.tar.bz2 You may try to compile the program WITHOUT the macro "MY_MALLOC" defined (in Makefile) to use malloc(3) provided by FreeBSD 6.1. Then, time the running of the binary (on Athlon XP 2500+): #/usr/bin/time ./fdtd.FreeBSD 500 500 1000 ... 165.24 real 164.19 user 0.02 sys Please try to recompile the program (Remember to "make clean") WITH the macro "MY_MALLOC" defined (in Makefile) to use my own simple implementation of malloc(3) (i.e. my_malloc() in cal.c). And time the running again: #/usr/bin/time ./fdtd.FreeBSD 500 500 1000 ... 50.41 real49.95 user 0.04 sys You may repeat this testing again and again. I guess this kind of performance difference comes from: 1. His program uses malloc(3) to obtain so many small memory blocks. 2. In this case, FreeBSD malloc(3) obtains small memory blocks from kernel and pass them to application. But malloc(3) of GNU libc obtains large memory blocks from kernel and splits & reallocates them in small blocks to application. You may verify my judgement with truss(1). 3. The way of FreeBSD malloc(3) makes VM page mapping too chaotic, which reduces the efficiency of CPU L2 Cache. In contrast, my my_malloc() simulates the behavior of GNU libc malloc(3) partially and avoids the over-chaos. Callgrind is broken under FreeBSD, or I will verify my guess with it. I have also verified the program on Intel Pentium 4 511 (2.8GHz, 1MB L2 cache, running FreeBSD 6.1 i386 though this CPU supports EM64T) /usr/bin/time ./fdtd.FreeBSD 500 500 1000 ... 185.30 real 184.28 user 0.02 sys /usr/bin/time ./fdtd.FreeBSD 500 500 1000 ... 36.31 real35.94 user 0.03 sys NOTE: you probably cannot see the performance difference on CPU with small L2 cache such as Intel Celeron 1.7GHz with 128 KB L2 Cache. In CURRENT we've replaced phkmalloc with jemalloc. It would be useful to see how this benchmark performs with that. I believe it does similar things. -- Brooke On -CURENT amd64 (Athlon64 3000+, 512k L2 cache): With jemalloc (without MY_MALLOS): ~/fdtd> /usr/bin/time ./fdtd.FreeBSD 500 500 1000 ... 116.34 real 113.69 user 0.00 sys With MY_MALLOC: ~/fdtd> /usr/bin/time ./fdtd.FreeBSD 500 500 1000 ... 45.30 real44.29 user 0.00 sys Regards, Vladimir ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: The optimization of malloc(3): FreeBSD vs GNU libc
在 2006-08-15二的 02:38 +0300，Vladimir Kushnir写道： > On -CURENT amd64 (Athlon64 3000+, 512k L2 cache): > > With jemalloc (without MY_MALLOS): > ~/fdtd> /usr/bin/time ./fdtd.FreeBSD 500 500 1000 > ... > 116.34 real 113.69 user 0.00 sys > > With MY_MALLOC: > ~/fdtd> /usr/bin/time ./fdtd.FreeBSD 500 500 1000 > ... > 45.30 real44.29 user 0.00 sys Have you turned off the debugging options, i.e. ln -sf 'aj' /etc/malloc.conf? Cheers, -- Xin LI http://www.delphij.net/ signature.asc Description: 这是信件的数 字签名部分
diff should not follow sym-link
I do not know what is the historical reason for program "diff" to follow a symbolic link during the recursive diff (-r), but it seems not to be a proper implementation. If both compared directories contains a sym-link, which point to a same file or directory, it obviously no need to compare it (not them). If both compared directories contains a sym-link, which point to a duplicated file or directory, and files or directories are duplicated in the same tree level, these files or directories will be compared any way during the recursive diff. So there is no need to follow the sym-link to compare them (just waste time by doing so). The only case that I can see that diff may follow the sym-link in recursive comparison is if the symlink is pointing to a duplicated directory/file in very different locations, which may probably rarely be created. If this is probably the only case "diff -r" needs to follow the sym-link, an option -L or something similar in other commands, such as ls, should be add for such purpose. Otherwise, diff -r can be loop forever on large file systems if there is some symlinks point forth and back between some directories, users may create them for easy to traversal around file systems. Then the process of "diff -r" a backup file system and a live file system will take a day to finish till maximum symlink number is reached, and many redundant diff information is created. See simple example below. So, we need to either disable recursive diff to follow the symlink, or we need a switch (option) to enable following symlink feature in recursive comparison of diff when a user real needs it. Any comment? -Jin - example of looping on recursive diff % create a simple test structure % dir -R test # show tree structure, in real case a and b will be a large tree total 8 drwxr-xr-x 3 jin wheel 512 Aug 14 20:25 a/ drwxr-xr-x 2 jin wheel 512 Aug 14 20:32 b/ -rw-r--r-- 1 jin wheel 4 Aug 14 20:23 x -rw-r--r-- 1 jin wheel 4 Aug 14 20:25 y test/a: total 2 drwxr-xr-x 2 jin wheel 512 Aug 14 20:25 a1/ lrwxr-xr-x 1 jin wheel4 Aug 14 20:25 x@ -> ../x test/a/a1: total 0 lrwxr-xr-x 1 jin wheel 10 Aug 14 20:24 a1@ -> ../../b/a1 test/b: total 0 lrwxr-xr-x 1 jin wheel 4 Aug 14 20:32 a1@ -> ../a lrwxr-xr-x 1 jin wheel 4 Aug 14 20:25 x@ -> ../y % mkdir test1 % cd test % tar -cf - . | ( cd ../test1 ; tar -xf - ) % cd .. ; diff -r test test1 diff: test/a/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1: Too many levels of symbolic links diff: test1/a/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1: Too many levels of symbolic links diff: test/a/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/x: Too many levels of symbolic links diff: test1/a/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/x: Too many levels of symbolic links diff: test/b/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1: Too many levels of symbolic links diff: test1/b/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1/a1: Too many levels of symbolic links ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
