Re: TCP Connection hang - MSS again
06.04.2021 19:54, Rodney W. Grimes wrote: >> 05.04.2021 19:44, Rozhuk Ivan wrote: >> > As I understand, in some cases remote host does not reply with MSS > option, and host behind router continue use mss 8960, that dropped > by router. If the peer does not provide an MSS option, your local FreeBSD based host should use an MSS of net.inet.tcp.mssdflt bytes. The default is 536. So I don't think this should be a problem. >>> >>> Thats it! >>> Thanks, it was ~64k in mine config. >> >> This is also per-host setting, you know :-) >> >> It is generally bad idea using MTU over 1500 for an interface facing public >> network >> without -mtu 1500. You see, because TCP MSS affects only TCP and there is >> also UDP >> that happily produces oversized datagramms for DNS or RTP or NFS or >> tunneling like L2TP or OpenVPN etc. >> relying on IP fragmentation. >> >> I still recommend using -mtu 1500 in addition to mssdflt in your case. > > I do not recommend such a setting. That would defeat any jumbo frame usage > locally! Why? Default route should not be used for local delivery. > The gateway/router that is forwarding packets to the internet connection > needs its upstream interface mtu set properly, and configured to properly > return icmp need fragement messages on the interfaces towards the > internal network. This results in extra delays and retransmission during outgoing data transfer, not good. The mechanics is much more fragile than default route's mtu attribute. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: TCP Connection hang - MSS again
05.04.2021 19:44, Rozhuk Ivan wrote: >>> As I understand, in some cases remote host does not reply with MSS >>> option, and host behind router continue use mss 8960, that dropped >>> by router. >> If the peer does not provide an MSS option, your local FreeBSD based >> host should use an MSS of net.inet.tcp.mssdflt bytes. The default is >> 536. So I don't think this should be a problem. > > Thats it! > Thanks, it was ~64k in mine config. This is also per-host setting, you know :-) It is generally bad idea using MTU over 1500 for an interface facing public network without -mtu 1500. You see, because TCP MSS affects only TCP and there is also UDP that happily produces oversized datagramms for DNS or RTP or NFS or tunneling like L2TP or OpenVPN etc. relying on IP fragmentation. I still recommend using -mtu 1500 in addition to mssdflt in your case. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: TCP Connection hang - MSS again
05.04.2021 16:44, Rozhuk Ivan wrote: > Is any other other options to work around this? Yes. Each entry in the routing table has "mtu" attribute limiting TCP MSS, too. You should use default route with -mtu 1500 attribute. For example, in /etc/rc.conf: defaultroute="X.X.X.X -mtu 1500" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FCP-101: obsolete driver removal planned for 2019-05-18
12.05.2019 8:21, Warner Losh wrote: > >> I've posted a review to remove obsolete 10 and 10/100 Ethernet drivers > >> as previous approved in FCP-101. > >> The following drivers are slated for > >> removal from FreeBSD-HEAD (to be FreeBSD-13): > >> ae, bm, cs, de, ed, ep, ex, fe, pcn, sf, sn, tl, tx, txp, vx, wb, xe > > OMG ! ed ! That EOL's loads of PC boxes I have (& a show box of > > spare) that will never be able to upgrade. > Do those boxes have 10M-only or 100Mbps variants of ed(4)? > What kind of hardware do they have (CPU and memory-wise)? > > There are no 100M ed variants. There are some PC Card variants that have 100M > MII connections, but they are limited to about 12Mbps due to bus limits. Even > the PCI ones didn't have 100M mii connections. There was RTL8029AS "NE2000-compatible" 100M 32 bit PCI 2.1 adapter. Not sure if ed(4) supports RTL8029AS. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FCP-101: obsolete driver removal planned for 2019-05-18
11.05.2019 22:59, Julian H. Stacey wrote: >> 11.05.2019 21:32, Julian H. Stacey wrote: >> I've posted a review to remove obsolete 10 and 10/100 Ethernet drivers as previous approved in FCP-101. The following drivers are slated for removal from FreeBSD-HEAD (to be FreeBSD-13): ae, bm, cs, de, ed, ep, ex, fe, pcn, sf, sn, tl, tx, txp, vx, wb, xe >>> >>> OMG ! ed ! That EOL's loads of PC boxes I have (& a show box of >>> spare) that will never be able to upgrade. >> >> Do those boxes have 10M-only or 100Mbps variants of ed(4)? >> What kind of hardware do they have (CPU and memory-wise)? > > Thanks for question. I ran a quick check: > cd /usr/src; > # Apply my patches: > # customise `pwd` > # http://www.berklix.com/~jhs/bin/.csh/customise > cd /sys/amd64/conf > grep device [A-Z][A-Z][A-Z][A-Z].small | grep ed > DUAL.small:device ed > FILM.small:device ed > KING.small:device ed > LAPA.small:device ed > LAPD.small:device ed > LAPL.small:device ed > LAPN.small:device ed > LOFT.small:device ed > MINI.small:device ed > SCAN.small:device ed0 at isa? port 0x280 irq 15 iomem 0xd iosiz 0x1 > SLIM.small:device ed > SNOW.small:device ed0 at isa? port 0x280 irq 5 iomem 0xc8000 > WIND.small:device ed I've asked not for configuration files but for description of hardware. ed(4) supports many different models. Some of them do 10Mbps only but some are 100M-capable including PCI-connected. And it's interesting to know what is CPU and memory type/amount of boxes. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FCP-101: obsolete driver removal planned for 2019-05-18
11.05.2019 21:32, Julian H. Stacey wrote: >> I've posted a review to remove obsolete 10 and 10/100 Ethernet drivers >> as previous approved in FCP-101. >> The following drivers are slated for >> removal from FreeBSD-HEAD (to be FreeBSD-13): >> >> ae, bm, cs, de, ed, ep, ex, fe, pcn, sf, sn, tl, tx, txp, vx, wb, xe > > OMG ! ed ! That EOL's loads of PC boxes I have (& a show box of > spare) that will never be able to upgrade. Do those boxes have 10M-only or 100Mbps variants of ed(4)? What kind of hardware do they have (CPU and memory-wise)? ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: The future of ZFS in FreeBSD
Hello, On 19.12.2018 23:32, Allan Jude wrote: The biggest thing to remember is that this is still OpenZFS, and still run by the same developers as it has been. We are just commonizing on the repo that has the most features integrated into it. Does it mean that ZoF and thus FreeBSD will lose NFSv4 ACLs because there is no such thing in ZoL ? Eugene. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Painfully slow compilation (read: "make buildworld buildkernel") on not-so-weak system
08.12.2018 18:13, Lev Serebryakov wrote: > I'm completely lost. Is it problem of software? Hardware? If it is > hardware problem what should I blame? Try using different kern.timecounter.hardware and/or kern.eventtimer.timer but first try kern.eventtimer.periodic=1 instead of default 0. If something of this helps, try going back to defaults and then disable power-saving settings, if any. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
D15247: add rcorder(8) support to /etc/rc.resume
Hi! While dealing with https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227866 I've found we have no easy way to insert custom "hooks" after ACPI resume procedure other than devd(8). And running devd itself may be undesirable for several reasons. Manual editing of /etc/rc.resume is not desirable too because it makes upgrades less smooth. So, I'd like to add rcorder(8) support to /etc/rc.resume: https://reviews.freebsd.org/D15247 /etc/rc.resume will call "rcorder -k resume" and run rcNG scripts containing "KEYWORD: resume" with single "resume" argument. Working example is the port sysutils/cpupdate version g20180324_1 that defines extra_commands="resume" to reload CPU microcode cleared by suspend/resume sequence. This change does nothing if system has no rcNG scripts with "KEYWORD: resume" inside. I'm going to commit this in a week unless told not to for a reason. signature.asc Description: OpenPGP digital signature
Re: need help using ng_patch to modify src/dst packets or alternative way
17.12.2017 17:59, Sami Halabi wrote: > Hi Eugene, > I'm looking for a solution for IP traffic. in linux iptables its possible but > I couldn't find freebsd way yet. > bkuncr soulution works for tcp only. Then, you need to realize that for every packet, you need to change (translate) both of source IP address from 10.1.1.2 to 1.1.1.1 and destination IP address from 10.1.1.1 to X.X.X.X. This is called network address translation and, in fact, you need NAT. But not ordinary "simple" NAT that translates only source address in outgoing packets (and destination in incoming replies) but double or "binat" to translate destination address in outgoing packets too (and source address in corresponding replies). This is possible to do with two instances of "ipfw nat" (or natd) for single external destination but not for arbitrary number of external destinations. They say, "pf(4)" packet filter can perform "binat" properly. I have not tried that. You should start reading its documentation. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: How to know the address ranges of kernel stacks, for user processes and kernel threads?
On 29.01.2015 07:54, Yue Chen wrote: > It seems that each kernel stack has two pages (IA-32) to use. Does x86_64 > still have two pages or more? One can change number of kernel stack pages for i386 and amd64 platforms by means of /boot/loader.conf without need to rebuild a kernel using kern.kstack_pages tunnable. It equals to 2 for i386 and to 4 for amd64 by default but I change it from 2 to 4 for my i386 systems running IPSEC tunnels and/or wifi due to these subsystems being stack-greedy. See also https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219476 ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
altq and head
Hi, regarding all this stir around ALTQ and igb(4), and mentioning that igb(4) doesn't have ALTQ in HEAD - I wanted to ask - is this just igb(4) and ixgbe(4) that lost ALTQ in HEAD, or is ALTQ being removed totally from FreeBSD ? I did a couple of searches, but seems like I cannot find the simple answer. Thanks. Eugene. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [RFC/RFT] projects/ipsec
s already useful and I'm excited to see it commited to HEAD and then MFC'd to 11.x, to start using it in my production network (as you may know, buiding gre/ipsec tunnels on Juniper is very hackish and tricky, bit I still have more than dozen of them). I've already saw a discussion on FreeBSD web forums, and people there are excited about if_ipsec too. Furthermore, I believe that guys using pfSense will be very happy about if_ipsec in their routers, because I saw several discussions mentioning missing VTI support there. It's very easy to configure, because it uses ifconfig syntax and it creates all the needed policies in the SADB automatically, so one less thing to bother with. And when I say "fully opertational with Juniper" I mean it: no tricky or hackish configuration directives are required oin the Juniper side, everything is like it's a Juniper or Cisco on the other side. So I'm pretty sure this will work with Cisco too (didn't run any test with Cisco though). Once again, I thank Andrey for this. Eugene. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: nanoBSD boot problem (on USB stick or as a HD)
On 15.09.2015 16:31, Stefano Garzarella wrote: > Hi all, > I created a nanoBSD image for my gsoc project (ptnetmap on bhyve). > > I would like to boot this image on USB stick or in the hypervisor as a HD. > I have some problem because if I set NANO_DRIVE="da0" (for USB boot) > in the nanoBSD configuration file, the boot from USB stick works well, > but when I try to boot the same image in the hypervisor as a HD, > I have the following mountroot error: > > Trying to mount root from ufs:/dev/da0s1a [ro]... > mountroot: waiting for device /dev/da0s1a ... > Mounting from ufs:/dev/da0s1a failed with error 19. > > Loader variables: >vfs.root.mountfrom=ufs:/dev/da0s1a >vfs.root.mountfrom.options=ro > > mountroot> > > > At this point I need to manually specify "ufs:/dev/ad0s1a" to properly mount > the root. > > Can you help me? > There is some tricks to avoid this mountroot error? Just make special image for hypervisor using NANO_DRIVE="ad0" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
mountroot error 5
Hi. Today I've upgraded one of my test machines from FreeBSD 9-STABLE to today's CURRENT. On a reboot I got: Solaris: cannot find the pool label for 'zfsroot' Mounting from zfs:zfsroot failed with error 5. When I boot from 9.0-RELEASE DVD1 and use Live Disk, I can see that the pool is available and healthy (version is still 28, I didn't upgrade it). It can be imported (it's not exported when mountroot tries to mount it) and read/written. Can this be resolved somehow ? I recreated cachefile (when on Live CD) and replaced with it the old one, but this didn't seem to change anything (still same error). I've also installed today's CURRENT (from the same obj/src tree) to an USB stick and when booting from it (on this troubled machine) it claims there's no zfs pools at all. I think these events may be connected. Thanks. Eugene. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r248583 Kernel panic: negative refcount 0xfffffe0031b59168
Hi.
On 02.07.2013 05:10, Pawel Jakub Dawidek wrote:
On Sun, Jun 30, 2013 at 01:18:36PM +0200, Mateusz Guzik wrote:
Turns out the bug is quite funny ;)
Try this:
diff --git a/sys/kern/uipc_usrreq.c b/sys/kern/uipc_usrreq.c
index 5d8e814..7a4db04 100644
--- a/sys/kern/uipc_usrreq.c
+++ b/sys/kern/uipc_usrreq.c
@@ -1764,8 +1764,8 @@ unp_externalize(struct mbuf *control, struct mbuf
**controlp, int flags)
}
for (i = 0; i newfds; i++, fdp++) {
fde = fdesc-fd_ofiles[*fdp];
-fde-fde_file = fdep[0]-fde_file;
-filecaps_move(fdep[0]-fde_caps,
+fde-fde_file = fdep[i]-fde_file;
+filecaps_move(fdep[i]-fde_caps,
fde-fde_caps);
if ((flags MSG_CMSG_CLOEXEC) != 0)
fde-fde_flags |= UF_EXCLOSE;
Thanks for tracking it down before I had time to get to it!
The change looks good.
Guys, if this is working, why it's not commited to HEAD ? I'm still
hitting this bug on r251990 and later ones.
Thanks.
Eugene.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r248583 Kernel panic: negative refcount 0xfffffe0031b59168
Hi. On 15.07.2013 15:16, Eugene M. Zheganin wrote: Guys, if this is working, why it's not commited to HEAD ? I'm still hitting this bug on r251990 and later ones. I'm terribly sorry, I should read the revisions more carefully. Eugene. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
panic: no init
Hi. I'm using FreeBSD as a desktop. When updating from r251990 to a higher revision (both GENERIC kernels) I got 'panic: no init' message after mountroot (I'm using zfs, seems like mountroot was successful). Nothing changed in my configuration, so I have totally no clue. Right now I'm running r251990 kernel on a newer world. How can I get rid of this panic and run newer kernel ? Thanks. Eugene. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
10.x and mpd5
Hi. After an upgrade from 9-STABLE I have a problem with mpd5. It can go to an endless loop while accepting a new pptp connection with a probability of like 50%. It looks in its log like I show below. The loop starts and ends with LCP: LayerUp. This is really an endless loop, because neither mpd5 nor windows 7, which I use as a client cannot break it, it can last for minutes (the output below was interrupted when I pressed 'Cancel' button on the client). I don't see any packet drops or other network problems. Furthermore, this machine was running fine when on 9.x. problem appeared after 10.x upgrade. This has nothing to do with a pf, which I use to filter the traffic - the problem persists when I switch it off. I've also rebuilt the mpd on 10.x, and this didn't help. ===Cut=== Mar 17 14:44:22 taiga mpd: [L-2] Accepting PPTP connection Mar 17 14:44:22 taiga mpd: [L-2] Link: OPEN event Mar 17 14:44:22 taiga mpd: [L-2] LCP: Open event Mar 17 14:44:22 taiga mpd: [L-2] LCP: state change Initial -- Starting Mar 17 14:44:22 taiga mpd: [L-2] LCP: LayerStart Mar 17 14:44:22 taiga mpd: [L-2] PPTP: attaching to peer's outgoing call Mar 17 14:44:22 taiga mpd: [L-2] Link: UP event Mar 17 14:44:22 taiga mpd: [L-2] LCP: Up event Mar 17 14:44:22 taiga mpd: [L-2] LCP: state change Starting -- Req-Sent Mar 17 14:44:22 taiga mpd: [L-2] LCP: SendConfigReq #1 Mar 17 14:44:22 taiga mpd: [L-2] ACFCOMP Mar 17 14:44:22 taiga mpd: [L-2] PROTOCOMP Mar 17 14:44:22 taiga mpd: [L-2] MRU 1500 Mar 17 14:44:22 taiga mpd: [L-2] MAGICNUM 9d62a962 Mar 17 14:44:22 taiga mpd: [L-2] AUTHPROTO CHAP MSOFTv2 Mar 17 14:44:22 taiga mpd: [L-2] MP MRRU 2048 Mar 17 14:44:22 taiga mpd: [L-2] MP SHORTSEQ Mar 17 14:44:22 taiga mpd: [L-2] ENDPOINTDISC [802.1] 00 1a 64 c6 a8 7c Mar 17 14:44:22 taiga mpd: [L-2] LCP: rec'd Configure Request #0 (Req-Sent) Mar 17 14:44:22 taiga mpd: [L-2] MRU 1400 Mar 17 14:44:22 taiga mpd: [L-2] MAGICNUM 6be166e5 Mar 17 14:44:22 taiga mpd: [L-2] PROTOCOMP Mar 17 14:44:22 taiga mpd: [L-2] ACFCOMP Mar 17 14:44:22 taiga mpd: [L-2] CALLBACK 6 Mar 17 14:44:22 taiga mpd: [L-2] LCP: SendConfigRej #0 Mar 17 14:44:22 taiga mpd: [L-2] CALLBACK 6 Mar 17 14:44:22 taiga mpd: [L-2] LCP: rec'd Configure Request #1 (Req-Sent) Mar 17 14:44:22 taiga mpd: [L-2] MRU 1400 Mar 17 14:44:22 taiga mpd: [L-2] MAGICNUM 6be166e5 Mar 17 14:44:22 taiga mpd: [L-2] PROTOCOMP Mar 17 14:44:22 taiga mpd: [L-2] ACFCOMP Mar 17 14:44:22 taiga mpd: [L-2] LCP: SendConfigAck #1 Mar 17 14:44:22 taiga mpd: [L-2] MRU 1400 Mar 17 14:44:22 taiga mpd: [L-2] MAGICNUM 6be166e5 Mar 17 14:44:22 taiga mpd: [L-2] PROTOCOMP Mar 17 14:44:22 taiga mpd: [L-2] ACFCOMP Mar 17 14:44:22 taiga mpd: [L-2] LCP: state change Req-Sent -- Ack-Sent Mar 17 14:44:24 taiga mpd: [L-2] LCP: SendConfigReq #2 Mar 17 14:44:24 taiga mpd: [L-2] ACFCOMP Mar 17 14:44:24 taiga mpd: [L-2] PROTOCOMP Mar 17 14:44:24 taiga mpd: [L-2] MRU 1500 Mar 17 14:44:24 taiga mpd: [L-2] MAGICNUM 9d62a962 Mar 17 14:44:24 taiga mpd: [L-2] AUTHPROTO CHAP MSOFTv2 Mar 17 14:44:24 taiga mpd: [L-2] MP MRRU 2048 Mar 17 14:44:24 taiga mpd: [L-2] MP SHORTSEQ Mar 17 14:44:24 taiga mpd: [L-2] ENDPOINTDISC [802.1] 00 1a 64 c6 a8 7c Mar 17 14:44:24 taiga mpd: [L-2] LCP: rec'd Configure Reject #2 (Ack-Sent) Mar 17 14:44:24 taiga mpd: [L-2] MP MRRU 2048 Mar 17 14:44:24 taiga mpd: [L-2] MP SHORTSEQ Mar 17 14:44:24 taiga mpd: [L-2] ENDPOINTDISC [802.1] 00 1a 64 c6 a8 7c Mar 17 14:44:24 taiga mpd: [L-2] LCP: SendConfigReq #3 Mar 17 14:44:24 taiga mpd: [L-2] ACFCOMP Mar 17 14:44:24 taiga mpd: [L-2] PROTOCOMP Mar 17 14:44:24 taiga mpd: [L-2] MRU 1500 Mar 17 14:44:24 taiga mpd: [L-2] MAGICNUM 9d62a962 Mar 17 14:44:24 taiga mpd: [L-2] AUTHPROTO CHAP MSOFTv2 Mar 17 14:44:24 taiga mpd: [L-2] LCP: rec'd Ident #2 (Ack-Sent) Mar 17 14:44:24 taiga mpd: [L-2] MESG: MSRASV5.20 Mar 17 14:44:24 taiga mpd: [L-2] LCP: rec'd Ident #3 (Ack-Sent) Mar 17 14:44:24 taiga mpd: [L-2] MESG: MSRAS-0-DROOKIEWIN Mar 17 14:44:24 taiga mpd: [L-2] LCP: rec'd Ident #4 (Ack-Sent) Mar 17 14:44:24 taiga mpd: [L-2] MESG: ЧNVчpM-^VМKM-^FaM-^M╙еше^D Mar 17 14:44:26 taiga mpd: [L-2] LCP: SendConfigReq #4 Mar 17 14:44:26 taiga mpd: [L-2] ACFCOMP Mar 17 14:44:26 taiga mpd: [L-2] PROTOCOMP Mar 17 14:44:26 taiga mpd: [L-2] MRU 1500 Mar 17 14:44:26 taiga mpd: [L-2] MAGICNUM 9d62a962 Mar 17 14:44:26 taiga mpd: [L-2] AUTHPROTO CHAP MSOFTv2 Mar 17 14:44:26 taiga mpd: [L-2] LCP: rec'd Configure Ack #4 (Ack-Sent) Mar 17 14:44:26 taiga mpd: [L-2] ACFCOMP Mar 17 14:44:26 taiga mpd: [L-2] PROTOCOMP Mar 17 14:44:26 taiga mpd: [L-2] MRU 1500 Mar 17 14:44:26 taiga mpd: [L-2] MAGICNUM 9d62a962 Mar 17 14:44:26 taiga mpd: [L-2] AUTHPROTO CHAP MSOFTv2 Mar 17 14:44:26 taiga mpd: [L-2] LCP: state change Ack-Sent -- Opened Mar 17 14:44:26 taiga mpd: [L-2] LCP: auth: peer wants nothing, I want CHAP Mar 17 14:44:26 taiga mpd: [L-2] CHAP: sending CHALLENGE #1 len: 21 Mar 17 14:44:26 taiga mpd: [L-2] LCP: LayerUp Mar 17 14:44:28 taiga mpd: [L-2] LCP: rec'd Configure Request #6 (Opened) Mar
Re: Call for bge(4) testers
Hi. On 15.09.2012 03:27, YongHyeon PYUN wrote: I'm especially interested in whether there is any ASF/IPMI regression on BCM570x/571x. There's a reopened bug concerning 8.x releases version of the bge(4) driver not working with IPMI ( http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/122252 http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/122252 ). I can also say that enabling ASF on RELENG_8 still leads to locking and hangups. Does this CFT mean that this situation may be improved with the new bge(4) version, on 9.x ? Eugene. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: replacement of ataidle for freebsd 9
On Sat, Oct 22, 2011 at 09:59:45PM +0100, Bruce Cran wrote: On 22/10/2011 16:21, Eugene Dzhurinsky wrote: ataidle -P 0 /dev/ada0 ataidle: error opening /dev/ada0 Thanks for reporting the breakage, I'll see if I can get it fixed in time for 9.0. Wow, it would be great! :) In the mentime, can you please advice how can I use camcontrol in order to disable APM for my HDD? Many thanks! -- Eugene N Dzhurinsky pgpK7gnXfMGv4.pgp Description: PGP signature
replacement of ataidle for freebsd 9
Hello, can somebody please advice how to disable APM power management for HDD on laptops? camcontrol cmd ada0 -a EF 05 00 00 00 00 00 00 00 00 00 00 -v camcontrol: error sending command (pass0:ahcich0:0:0:0): SETFEATURES. ACB: ef 05 00 00 00 00 00 00 00 00 00 00 (pass0:ahcich0:0:0:0): CAM status: ATA Status Error (pass0:ahcich0:0:0:0): ATA status: 51 (DRDY SERV ERR), error: 04 (ABRT ) (pass0:ahcich0:0:0:0): RES: 51 04 00 00 00 00 00 00 00 00 00 What else should I try? uname -a FreeBSD devbox 9.0-RC1 FreeBSD 9.0-RC1 #0: Thu Oct 20 08:48:57 EEST 2011 root@devbox:/usr/obj/usr/src/sys/GENERIC amd64 Thanks! -- Eugene N Dzhurinsky pgpXWhgKl3KiZ.pgp Description: PGP signature
Re: replacement of ataidle for freebsd 9
On Sat, Oct 22, 2011 at 02:23:53PM +0100, Bruce Cran wrote: Why do you not want to use ataidle? ataidle -P 0 /dev/ada0 ataidle: error opening /dev/ada0 ataidle -P 0 /dev/ad4 ataidle: error: identify device /dev/ad4 ls -l /dev | grep ad lrwxr-xr-x 1 root wheel4 Oct 22 18:16 ad4@ - ada0 lrwxr-xr-x 1 root wheel6 Oct 22 18:16 ad4s1@ - ada0s1 lrwxr-xr-x 1 root wheel7 Oct 22 18:16 ad4s1a@ - ada0s1a lrwxr-xr-x 1 root wheel7 Oct 22 18:16 ad4s1b@ - ada0s1b lrwxr-xr-x 1 root wheel7 Oct 22 18:16 ad4s1d@ - ada0s1d lrwxr-xr-x 1 root wheel7 Oct 22 18:16 ad4s1e@ - ada0s1e lrwxr-xr-x 1 root wheel7 Oct 22 18:16 ad4s1f@ - ada0s1f lrwxr-xr-x 1 root wheel6 Oct 22 18:16 ad4s2@ - ada0s2 crw-r- 1 root operator0, 81 Oct 22 18:16 ada0 crw-r- 1 root operator0, 84 Oct 22 18:16 ada0s1 crw-r- 1 root operator0, 88 Oct 22 21:16 ada0s1a crw-r- 1 root operator0, 90 Oct 22 18:16 ada0s1b crw-r- 1 root operator0, 92 Oct 22 21:16 ada0s1d crw-r- 1 root operator0, 94 Oct 22 21:16 ada0s1e crw-r- 1 root operator0, 96 Oct 22 21:16 ada0s1f crw-r- 1 root operator0, 86 Oct 22 21:16 ada0s2 smartctl -a /dev/ada0 smartctl 5.42 2011-10-20 r3458 [FreeBSD 9.0-RC1 amd64] (local build) Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net === START OF INFORMATION SECTION === Device Model: ST9500423AS Serial Number:W2V003TQ LU WWN Device Id: 5 000c50 03d75b968 Firmware Version: 0002SDM1 User Capacity:500,107,862,016 bytes [500 GB] Sector Sizes: 512 bytes logical, 4096 bytes physical Device is:Not in smartctl database [for details use: -P showall] ATA Version is: 8 ATA Standard is: ATA-8-ACS revision 4 Local Time is:Sat Oct 22 18:20:22 2011 EEST SMART support is: Available - device has SMART capability. SMART support is: Enabled -- Eugene N Dzhurinsky pgpFw5hq6gcCH.pgp Description: PGP signature
Re: wpa_supplicant, Atheros AR9285 and FreeBSD 8.0 issue - wpa_supplicant hangs
On Sun, Mar 28, 2010 at 10:46:10PM +0300, Eugene Dzhurinsky wrote: Okay, with simplified config things didn't change, so I submitted PR: kern/145123 Sometimes I'm felling like being an idiot. I just realized that I had configured both laptops to use same IP address, which was noticed on logs at AP host. If I'd look at log files, even dmesg - I will find the cause immediately, but instead I started to post to mailing lists and send PR-s. Anyway, the problem is already resolved, and I asked to close the PR. Sorry about that :( -- Eugene N Dzhurinsky pgpImwRPLg9rT.pgp Description: PGP signature
Re: wpa_supplicant, Atheros AR9285 and FreeBSD 8.0 issue - wpa_supplicant hangs
On Sun, Mar 28, 2010 at 12:24:07PM +0100, Rui Paulo wrote:
You can try with a more simple config. Just:
network={
ssid=freebsdap
psk=...
scan_ssid=1
}
If this doesn't work you should send-pr.
Okay, with simplified config things didn't change, so I submitted
PR: kern/145123
--
Eugene N Dzhurinsky
pgpaUKaQskyzZ.pgp
Description: PGP signature
Re: wpa_supplicant, Atheros AR9285 and FreeBSD 8.0 issue - wpa_supplicant hangs
On Wed, Mar 24, 2010 at 10:26:39PM +0200, Eugeny N Dzhurinsky wrote: Hi! I am facing very strange issue - for some reason wpa_supplicant hands after associating connection with AP. It doesn't hang immediately - but after some time (amout a minute or so). I realized that it fails after group rekeying completes. If is set rekeying to occur in 30 minutes on AP host - for 30 minutes I am not getting any issue. With my DLink WiFi USB stick powered by if_rum driver such problem does not appear. If I should provide some additional information to help someone understand and fix this issue - please let me know :) P.S. Many thanks to Rui Paulo for porting AR9285 driver! -- Eugene N Dzhurinsky pgpq586K7g3WF.pgp Description: PGP signature
Re: wpa_supplicant, Atheros AR9285 and FreeBSD 8.0 issue - wpa_supplicant hangs
On Sat, Mar 27, 2010 at 02:20:15PM +0200, Eugene Dzhurinsky wrote:
On Wed, Mar 24, 2010 at 10:26:39PM +0200, Eugeny N Dzhurinsky wrote:
I realized that it fails after group rekeying completes. If is set rekeying to
occur in 30 minutes on AP host - for 30 minutes I am not getting any issue.
With my DLink WiFi USB stick powered by if_rum driver such problem does not
appear.
If I should provide some additional information to help someone understand and
fix this issue - please let me know :)
Finally I was able to find out the case which makes my wifi to stop working.
The problem is easily reproducible if second laptop is associated with AP.
My AP configuration (PC with FreeBSD 7.2) is listed below:
interface=ral0
debug=2
ctrl_interface=/var/run/hostapd
ctrl_interface_group=wheel
ssid=freebsdap
wpa=1
wpa_passphrase=*
wpa_key_mgmt=WPA-PSK
wpa_group_rekey=1800
wpa_pairwise=CCMP TKIP
local wpa_supplicant.conf is like below:
ctrl_interface=/var/run/wpa_supplicant
ctrl_interface_group=wheel
fast_reauth=0
eapol_version=2
network={
ssid=freebsdap
key_mgmt=WPA-PSK
auth_alg=OPEN
psk=*
scan_ssid=1
}
My primary laptop is ASUS K40IN with wifi card on AR9285 chipset, another
laptop is ASUS K40IJ with wifi card on AR9285 chipset too.
And once second laptop gets associated with AP - my one stops to recognize
wifi connection. But it's still listed as associated in ifconfig output. And
wpa_cli reassociate
doesn't solve the problem - I have to restart wpa_supplicant.
Does this make any sense? Should I submit PR or there is some
misconfiguration?
--
Eugene N Dzhurinsky
pgpl7phaDXEvM.pgp
Description: PGP signature
Re: A tool for remapping bad sectors in CURRENT?
On Mon, Mar 08, 2010 at 12:31:24PM +0200, Alexander Motin wrote: You may try to overwrite these sectors with dd. It should trigger sector reallocation. To be sure, you may read them before and after the write. dd if=/dev/ad4 of=/dev/null skip=222342559 bs=512 count=1 dd: /dev/ad4: Input/output error 0+0 records in 0+0 records out 0 bytes transferred in 2.351940 secs (0 bytes/sec) dd if=/dev/zero of=/dev/ad4 seek=222342559 bs=512 count=1 dd: /dev/ad4: Operation not permitted Should I do it in single mode? -- Eugene N Dzhurinsky pgpMrducrommM.pgp Description: PGP signature
Re: A tool for remapping bad sectors in CURRENT?
On Mon, Mar 08, 2010 at 10:51:22AM +, Poul-Henning Kamp wrote: I would suggest you boot single-user and run mdmfs -s 1m md /tmp recoverdisk -w /tmp/_.wl /dev/ad4 /dev/ad4 That will find out how many bad sectors you have and try to recover the contents of them if possible, leave it running as long as you care for. If you interrupt it, the /tmp/_.wl file will contain a list of areas not yet successfully read/written. Well, I just want to force IDE drive to remap things :) -- Eugene N Dzhurinsky pgp0a7Gsgnv97.pgp Description: PGP signature
Re: A tool for remapping bad sectors in CURRENT?
On Mon, Mar 08, 2010 at 12:52:43PM +0200, Eugene Dzhurinsky wrote: dd if=/dev/ad4 of=/dev/null skip=222342559 bs=512 count=1 dd: /dev/ad4: Input/output error 0+0 records in 0+0 records out 0 bytes transferred in 2.351940 secs (0 bytes/sec) dd if=/dev/zero of=/dev/ad4 seek=222342559 bs=512 count=1 dd: /dev/ad4: Operation not permitted Should I do it in single mode? sysctl kern.geom.debugflags=0x10 Did the trick, I was able to write directly to the sector, and now it seems to work well. No remaps recorded thus, but no errors so far. Thanks a lot! -- Eugene N Dzhurinsky pgpbcuR5aO8BX.pgp Description: PGP signature
Re: A tool for remapping bad sectors in CURRENT?
On Mon, Mar 08, 2010 at 12:21:44PM +0100, Miroslav Lachman wrote: Eugeny N Dzhurinsky wrote: We have this problem from time to time on bunch of machines. As we are using gmirror, the easiest way is to force re-synchronization (rewrite) of the whole drive. The problem is when there are Pending unreadable sectors on both drives - it ends up with read error and some file(s) are corrupted, but there is no easy way (on FreeBSD) to find what file. I tried it in the past with fsdb / findblk, but it does not work as I expect or I do not fully understand the needed calculations with slices + partitions offsets / LBAs and right meaning of the term block. It seems there are several meaning in different contexts. It would be nice if somebody with enough FS / GEOM knowledge can write some HowTo or shell script to do the calculations and operations to find file containing bad sector(s) and put it in FAQ, Handbook, or Wiki. Miroslav, thank you for the suggestion - but I am not using gmirror, that HDD is the one on my laptop. However suggestions about using dd to write something into bad block to force IDE controller do it's service stuff about remapping seems did the trick. And I was able to not calculate LBA but use it as block offset, which seemed to be correct way :) -- Eugene N Dzhurinsky pgpRqAzvt8cSz.pgp Description: PGP signature
LOR (vm_kern.c:328, vm_map.c:2176) (current-nov-17)
hi, lock order reversal 1st 0xc0c31100 system map (system map) @ /usr/src/sys/vm/vm_kern.c:328 2nd 0xc07052e0 Giant (Giant) @ /usr/src/sys/vm/vm_map.c:2176 Stack backtrace: backtrace witness_lock _mtx_lock_flags rm_map_delete kmem_alloc page_alloc uma_large_malloc malloc g_bde_new_sector g_bde_start2 g_bde_start1 g_bde start g_io_schedule_down g_down_priority fork_exit fork_trampoline uname -a FreeBSD security-ag.ath.cx 5.1-CURRENT FreeBSD 5.1-CURRENT #0: Mon Nov 17 15:20:03 CET 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/ SECURITY-AG i386 hth, Eugene ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: xscreensaver bug?
Terry Lambert wrote: Eugene M. Kim wrote: Terry Lambert wrote: I'm new in FreeBSD. I found that after I lock screen with xscreensaver, I can unlock it with the root's password as well as my normal user's password. I don't think it is a good thing. Is it a bug? It is intentional, although you can eliminate it with a recompile of the xscreensaver code, with the right options set. Wouldn't this lead to another security hazard, if a user compile his own hacked xscreensaver which captures and stashes the password into a file then runs it and leaves the terminal intentionally, `baiting' root? :o Not really. This type of thing would need to accept pretty much everything as a termination password, since there no password it can legitimately validate, since a user compiled trojan like this would not have access to the password database contents in order to perform validation. If the trojan is SUID, then they already have root, and don't need the trojan. Either way, there's no risk to just typing whatever crap you want to at it, including a message calling the user an idiot, the first time, to see if it's going to let you in without you giving it the real root password. Validating a root password is possible with other means in many cases, if not always. OpenSSH sshd is a good example. Even with PermitRootLogin set to no, the attacker can differentiate whether the password has been accepted or not. If attacker is able enough, he could also run a hacked version of Xnest on port 6000+N and the real xscreensaver on :N.0 for a suitable N. Attacker would feed the real xscreensaver with the captured password and see if the real xscreensaver releases the server grab. Eugene ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: xscreensaver bug?
Terry Lambert wrote: [EMAIL PROTECTED] wrote: I'm new in FreeBSD. I found that after I lock screen with xscreensaver, I can unlock it with the root's password as well as my normal user's password. I don't think it is a good thing. Is it a bug? It is intentional, although you can eliminate it with a recompile of the xscreensaver code, with the right options set. Wouldn't this lead to another security hazard, if a user compile his own hacked xscreensaver which captures and stashes the password into a file then runs it and leaves the terminal intentionally, `baiting' root? :o Although I can see the merit of this `feature', I think sysadmins should stay away from using it in general. `su -m thatuser -c killall xscreensaver' seems to be far safer. Eugene ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Forward: HEADS UP! Default value of ip6_v6only changed
Michael Nottebrock wrote: Christian Weisgerber wrote: If we ship with a default of v6only off, then people will not fix software to open two sockets. This in turn means that turning v6only on will break this software. I find the notion of making people fix their software to not rely on RFC-defined behaviour problematic. I'm actually glad to see NetBSD reversed their unfortunate decision regarding the default (and OpenBSD's stunt of not even providing a knob is very evil indeed). 100% agreed here. The standard exists for a reason. If people find the standard problematic (in fact I concur with Itojun's analysis about IPv4-mapped addresses), they should voice in the appropriate forum to fix the standard rather than just ignore the standard and implement things in their own way, which only creates and/or worsens the compatibility nightmare. (Another test knob into GNU autoconf. Sad.) It's not like IETF RFC's are particularly hard to amend, either, at least compared to other standarization bodies. IETF and its folks are *very* open and flexible IMHO. Eugene ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.1-CURRENT 23.06.2003: the floppy has ceased to work
Andy Fawcett wrote: On Wednesday 25 June 2003 17:18, Eugene V. Bontseff wrote: After updating system on June, 23 floppy the disk drive does not work. For what it's worth, I get the same with 5.1-RELEASE: [EMAIL PROTECTED] mp3]$ uname -a FreeBSD vimes.int.athame.co.uk 5.1-RELEASE FreeBSD 5.1-RELEASE #7: Sat Jun 14 23:09:29 EEST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/VIMES i386 [EMAIL PROTECTED] mp3]$ dmesg | grep fdc fdc0: cmd 3 failed at out byte 1 of 3 fdc0: cmd 3 failed at out byte 1 of 3 fdc0: cannot reserve I/O port range (6 ports) Does my floppy drive work? No idea, I never use it, and I'm 20km from it right now so I can't check. Well, at me my floppy absolutely beside:) And it even works, if I load old kernel. uname-a FreeBSD home.eugene.intranet 5.1-BETA FreeBSD 5.1-BETA *7: Fri May 23 00:08:27 MSD 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/EUKERNEL i386 dmesg|grep fdc fdc0: Enhanced floppy controller (i82077, NE72065 or clone) at port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: 1440-KB 3.5 drive on fdc0 drive 0 And, since updating on June, 23, floppy does not work. Diagnostics same, as at you. dmesg|grep fdc fdc0: cmd 3 failed at out byte 1 of 3 fdc0: cmd 3 failed at out byte 1 of 3 fdc0: cannot reserve I/O port range (6 ports) Sometimes it is required working floppy. It would be desirable to solve this problem. Eugene V. Boontseff ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
5.1-CURRENT 23.06.2003: the floppy has ceased to work
Hi, After updating system on June, 23 floppy the disk drive does not work. At loading messages are given out: fdc0: cmd 3 failed at out byte 1 of 3 How to me to resolve this problem? Full dmesg it is applied. Eugene V. Boontseff Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.1-CURRENT #16: Wed Jun 25 06:00:16 MSD 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/EUKERNEL Preloaded elf kernel /boot/kernel/kernel at 0xc05cc000. Preloaded elf module /boot/modules/vesa.ko at 0xc05cc26c. Preloaded elf module /boot/modules/acpi.ko at 0xc05cc318. Timecounter i8254 frequency 1193182 Hz Timecounter TSC frequency 1804102976 Hz CPU: Intel(R) Celeron(R) CPU 1.80GHz (1804.10-MHz 686-class CPU) Origin = GenuineIntel Id = 0xf13 Stepping = 3 Features=0x3febfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM real memory = 536805376 (511 MB) avail memory = 514953216 (491 MB) netsmb_dev: loaded Pentium Pro MTRR support enabled VESA: v2.0, 131072k memory, flags:0x1, mode table:0xc057ebe2 (122) VESA: ATI RADEON RV250 npx0: math processor on motherboard npx0: INT 16 interface acpi0: AMIINT INTEL845 on motherboard pcibios: BIOS version 2.10 Using $PIR table, 10 entries at 0xc00f7a60 acpi0: power button is handled as a fixed feature programming model. Timecounter ACPI-fast frequency 3579545 Hz ACPI-1287: *** Error: Method execution failed [\\_SB_.PCI0.MDET] (Node 0xc14ed1a0), AE_AML_REGION_LIMIT ACPI-1287: *** Error: Method execution failed [\\_SB_.PCI0._CRS] (Node 0xc14ed0e0), AE_AML_REGION_LIMIT ACPI-0175: *** Error: Method execution failed [\\_SB_.PCI0._CRS] (Node 0xc14ed0e0), AE_AML_REGION_LIMIT can't fetch resources for \\_SB_.PCI0 - AE_AML_REGION_LIMIT ACPI-1287: *** Error: Method execution failed [\\_SB_.PCI0.MDET] (Node 0xc14ed1a0), AE_AML_REGION_LIMIT ACPI-1287: *** Error: Method execution failed [\\_SB_.MEM_._CRS] (Node 0xc4070c40), AE_AML_REGION_LIMIT ACPI-0175: *** Error: Method execution failed [\\_SB_.MEM_._CRS] (Node 0xc4070c40), AE_AML_REGION_LIMIT can't fetch resources for \\_SB_.MEM_ - AE_AML_REGION_LIMIT acpi_timer0: 24-bit timer at 3.579545MHz port 0x808-0x80b on acpi0 acpi_cpu0: CPU port 0x530-0x537 on acpi0 acpi_cpu1: CPU on acpi0 acpi_button0: Power Button on acpi0 pcib0: ACPI Host-PCI bridge on acpi0 pci0: ACPI PCI bus on pcib0 pcib0: slot 29 INTA is routed to irq 11 pcib0: slot 29 INTB is routed to irq 10 pcib0: slot 29 INTC is routed to irq 10 pcib0: slot 29 INTD is routed to irq 12 pcib0: slot 31 INTB is routed to irq 12 agp0: Intel 82845 host to AGP bridge mem 0xe000-0xe07f at device 0.0 on pci0 pcib1: PCI-PCI bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 pcib0: slot 1 INTA is routed to irq 11 pcib1: slot 0 INTA is routed to irq 11 drm0: ATI Radeon If R250 9000 port 0xa800-0xa8ff mem 0xdfdf-0xdfdf,0xd000-0xd7ff irq 11 at device 0.0 on pci1 info: [drm] AGP at 0xe000 8MB info: [drm] Initialized radeon 1.8.0 20020828 on minor 0 pci1: display at device 0.1 (no driver attached) uhci0: Intel 82801DB (ICH4) USB controller USB-A port 0xd400-0xd41f irq 11 at device 29.0 on pci0 usb0: Intel 82801DB (ICH4) USB controller USB-A on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered ums0: vendor 0x062a product 0x, rev 1.10/2.04, addr 2, iclass 3/1 ums0: 5 buttons and Z dir. uhci1: Intel 82801DB (ICH4) USB controller USB-B port 0xd800-0xd81f irq 10 at device 29.1 on pci0 usb1: Intel 82801DB (ICH4) USB controller USB-B on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhci2: Intel 82801DB (ICH4) USB controller USB-C port 0xdc00-0xdc1f irq 10 at device 29.2 on pci0 usb2: Intel 82801DB (ICH4) USB controller USB-C on uhci2 usb2: USB revision 1.0 uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered ehci0: EHCI (generic) USB 2.0 controller mem 0xdc00-0xdfff irq 12 at device 29.7 on pci0 ehci_pci_attach: companion usb0 ehci_pci_attach: companion usb1 ehci_pci_attach: companion usb2 usb3: EHCI version 1.0 usb3: companion controllers, 2 ports each: usb0 usb1 usb2 usb3: EHCI (generic) USB 2.0 controller on ehci0 usb3: USB revision 2.0 uhub3: (0x8086) EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub3: 6 ports with 6 removable, self powered pcib2: ACPI PCI-PCI bridge at device 30.0 on pci0 pci3: ACPI PCI bus on pcib2 pcib2: slot 1 INTA is routed to irq 12 pcib2: slot 2 INTA is routed to irq 10 dc0: Intel 21143 10/100BaseTX port 0xb800-0xb87f mem 0xdfefec00-0xdfefefff irq 12 at device 1.0 on pci3 dc0: Ethernet address: 00:80:48:b3:53:a6 miibus0: MII bus on dc0 amphy0: Am79C873 10/100
Re: dump -L and privilege
Moreover, the fact that the number of snapshots allowed on a filesystem is limited to a handful (src/sys/ufs/ffs/README.snapshot says 20) makes it possible for normal users to disrupt dump -L and other important operations that require snapshots. Alternative 2 seems a lot more sensible. Just my 2 KRW (1 USD ~= 1250 KRW) :D, Eugene On Thu, Jan 30, 2003 at 05:15:01PM -0600, Jacques A. Vidrine wrote: On Wed, Jan 29, 2003 at 06:17:31PM -0800, Kirk McKusick wrote: Alternative 1 `usermount' The first would be to change the default for vfs.usermount == 1 and then have dump -L create the snapshot in a directory owned by operator (or by whatever user runs the dumps). Then the snapshot could be created, used, and deleted by that user. Alternative 2 `/sbin/snapshot' The other alternative would be to create a setuid-to-root program that would take a snapshot and chown it to the user that does dumps. This setuid program could then be invoked by dump -L to create a snapshot for it. Despite a distaste for setuid executables, I think I'd prefer a simple /sbin/snapshot setuid program. Primarily, enabling `vfs.usermount' gives more privileges to more users than I'm comfortable with. Secondarily, /sbin/snapshot may be useful on its own. Cheers, -- Jacques A. Vidrine [EMAIL PROTECTED] http://www.celabo.org/ NTT/Verio SME . FreeBSD UNIX . Heimdal Kerberos [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: I've just had a massive file system crash
On Sun, Jan 26, 2003 at 04:08:31PM +0800, Greg Lehey wrote:
On Sunday, 26 January 2003 at 14:24:02 +1030, Daniel O'Connor wrote:
On Sun, 2003-01-26 at 08:08, David Schultz wrote:
Good. I was referring to IDE in this case, because I assume
that's what Greg's laptop uses. The ATA driver flushes the cache
when the device is closed, but I don't think that happens during
shutdown. It probably needs to register a shutdown hook like the
SCSI driver. Also, the driver is a bit optimistic about how long
the flush will take; it times out after 5 seconds, whereas the ATA
spec says a flush can take up to 30 seconds.
I am wondering if I experienced this problem with my -stable laptop..
I shut it down and then booted it up later to find fsck having a nice
good chew on the drive (deleting REAMS of files).
Did you use shutdown -p? If my hypothesis is correct, it's possible
to get this result with shutdown -h if you press the power switch as
soon as the System halted message appears, but normally you'd give
it a few seconds longer. With shutdown -p, it's immediate, modulo
delay.
Just a random idea: If that poses an issue, how about this patch?
Eugene
--- src/sys/kern_shutdown.c Sun Jan 26 14:24:56 2003
+++ src/sys/kern_shutdown.c.new Sun Jan 26 14:25:42 2003
@@ -545,7 +545,7 @@
static void
poweroff_wait(void *junk, int howto)
{
- if(!(howto RB_POWEROFF) || poweroff_delay = 0)
+ if(!(howto (RB_POWEROFF | RB_HALT)) || poweroff_delay = 0)
return;
DELAY(poweroff_delay * 1000);
}
Re: LIBCOMPATDIR semantics mismatch
Coolio, thanks for letting me in the know. Cheers, Eugene On Thu, Apr 18, 2002 at 04:26:20PM +0300, Ruslan Ermilov wrote: Already fixed this earlier this morning (local time). And just removed the gratuitous LIBCOMPATDIR assignments. Cheers, -- Ruslan ErmilovSysadmin and DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED]FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.orgThe Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
LIBCOMPATDIR semantics mismatch
Don't know what prevented this from being caught, but:
http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/compat/Makefile.inc?only_with_tag=MAIN#rev1.5
http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/compat/compat1x/Makefile?only_with_tag=MAIN#rev1.8
These two doesn't seem to mix together (note the last argument):
- snip - snip - snip -
sh /usr/src/tools/install.sh -c -o root -g wheel -m 444 libc.so.1.1 libcurses.so.1.1
libf2c.so.1.1 libg++.so.1.1 libgcc.so.1.1 libgnumalloc.so.1.1 libgnuregex.so.1.1
libln.so.1.1 libm.so.1.1 libmalloc.so.1.1 libreadline.so.1.1 libresolv.so.1.1
librpcsvc.so.1.1 libskey.so.1.1 libtelnet.so.1.1 libtermcap.so.1.1 libutil.so.1.1
liby.so.1.1 /usr/obj/usr/src/i386/usr/lib/compat/aout/aout
usage: install [-bCcpSsv] [-B suffix] [-f flags] [-g group] [-m mode]
[-o owner] file1 file2
install [-bCcpSsv] [-B suffix] [-f flags] [-g group] [-m mode]
[-o owner] file1 ... fileN directory
install -d [-v] [-g group] [-m mode] [-o owner] directory ...
*** Error code 64
- snip - snip - snip -
Attached is a patch that fixes this by unifying the semantics of
LIBCOMPATDIR.
Thanks,
Eugene
--- src/lib/compat/Makefile.inc Sat Nov 10 02:08:09 2001
+++ src/lib/compat/Makefile.inc.new Wed Apr 17 14:27:40 2002
-1,6 +1,6
# $FreeBSD: src/lib/compat/Makefile.inc,v 1.8 2001/09/22 08:11:24 ru Exp $
-LIBCOMPATDIR?= ${LIBDIR}/compat/aout
+LIBCOMPATDIR?= ${LIBDIR}/compat
.if defined(LIBS) !empty(LIBS)
beforeinstall: __remove-stale-libs
--- src/lib/compat/compat3x.i386/Makefile Sat Nov 10 02:08:09 2001
+++ src/lib/compat/compat3x.i386/Makefile.new Wed Apr 17 14:28:05 2002
-2,8 +2,6
DISTRIBUTION= compat3x
-LIBCOMPATDIR= ${LIBDIR}/compat
-
LIBS= libalias.so.3 libc.so.3 libc_r.so.3 libc_r.so.4 libcurses.so.2 \
libdialog.so.3 libedit.so.2 libf2c.so.2 libfetch.so.1 libftpio.so.4 \
libg++.so.4 libhistory.so.3 libmytinfo.so.2 libncurses.so.3 \
--- src/lib/compat/compat4x.alpha/Makefile Wed Apr 17 01:16:56 2002
+++ src/lib/compat/compat4x.alpha/Makefile.new Wed Apr 17 14:28:12 2002
-2,8 +2,6
DISTRIBUTION= compat4x
-LIBCOMPATDIR= ${LIBDIR}/compat
-
LIBS= \
libc.so.4 \
libc_r.so.4 \
--- src/lib/compat/compat4x.i386/Makefile Wed Apr 17 01:16:57 2002
+++ src/lib/compat/compat4x.i386/Makefile.new Wed Apr 17 14:28:21 2002
-2,8 +2,6
DISTRIBUTION= compat4x
-LIBCOMPATDIR= ${LIBDIR}/compat
-
LIBS= \
libc.so.4 \
libc_r.so.4 \
Re: Hang on flushing buffers w/today's -CURRENT, SMP system
--2oS5YaxWCcQjTEyO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Attached is the requested DDB log (I guessed pid 7 `syncer' is the process doing the sync; if this is wrong let me know). Eugene PS. I used the serial console, so don't feel sorry to ask. =) On Fri, Feb 08, 2002 at 02:41:30PM -0800, Julian Elischer wrote: On Fri, 8 Feb 2002, Eugene M. Kim wrote: On Fri, Feb 08, 2002 at 01:43:54PM -0800, Julian Elischer wrote: On Fri, 8 Feb 2002, David Wolfskill wrote: Waiting (max 60 seconds) for system process `vnlru' to stop...stopped Waiting (max 60 seconds) for system process `bufdaemon' to stop...stopped Waiting (max 60 seconds) for system process `syncer' to stop...stopped syncing disks... 7 7 can you hit CTLALTESC and get into the debugger? My box shows the same symptom, and yes I can enter DDB. How may I help? Eugene show locks whould be good. also 'ps' and the stack trace of the process doing the sync... tr PID if you can get a serial console that would be best of course. you may wait a while to see if dave can get into ddb on his serial console. that may save you a lot of writing :-) --2oS5YaxWCcQjTEyO Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=screenlog.0 syncing disks... 4 4 Debugger(manual escape to debugger) Stopped at Debugger+0x41: xorl%eax,%eax db show locks exclusive (sleep mutex) Giant (0xc02e6100) locked @ /usr/src/sys/kern/kern_intr.c:532 db ps pid proc addruid ppid pgrp flag stat wmesg wchan cmd 192 cc989300 cdbc50000 0 0 204 3 nfsidl c1d0538c nfsiod 3 191 cc989600 cdbc10000 0 0 204 3 nfsidl c1d05388 nfsiod 2 190 cc989900 cdbbd0000 0 0 204 3 nfsidl c1d05384 nfsiod 1 189 cc989c00 cdbb90000 0 0 204 3 nfsidl c1d05380 nfsiod 0 9 cc98c000 cd1af0000 0 0 204 3 pccbbev c1b39400 pccbb1 8 cc98c300 cd1ab0000 0 0 204 3 pccbbev c1b39800 pccbb0 7 cc98c600 cd1a70000 0 0 204 3 ktsusp cc98c800 syncer 6 cc98c900 cd1a30000 0 0 204 3 ktsusp cc98cb00 vnlru 5 cc98cc00 cd19f0000 0 0 204 3 ktsusp cc98ce00 bufdaemon 4 cc98cf00 cd19b0000 0 0 204 3 pgzero c0327fc8 pagezero 3 cc98d200 cd1970000 0 0 204 3 psleep c0327fdc vmdaemon 2 cc98d500 cd1930000 0 0 204 3 psleep c02e06d8 pagedaemon 31 cc98d800 cc9920000 0 0 204 6 irq8: rtc 30 cc98db00 cc98e0000 0 0 204 6 irq0: clk 29 cc320f00 cc9850000 0 0 204 6 irq4: sio0 28 cc321200 cc9810000 0 0 204 6 swi0: tty:sio 27 cc321500 cc97d0000 0 0 204 6 irq7: ppc0 26 cc321800 cc9790000 0 0 204 6 irq12: psm0 25 cc321b00 cc9750000 0 0 204 2 irq1: atkbd0 24 cc321e00 cc9710000 0 0 204 3 usbevt c1b60210 usb0 --More-- 23 cc322100 cc96d0000 0 0 204 6 irq15: ata1 22 cc322400 cc9690000 0 0 204 6 irq14: ata0 21 cc322700 cc9640000 0 0 204 6 irq11: pccbb0++ 20 cc322a00 cc95a0000 0 0 204 6 irq5: pcm0 19 cc322d00 cc9520000 0 0 204 6 irq13: 18 cc323000 cc94e0000 0 0 204 6 swi5: acpitaskq 17 cc323300 cc94a0000 0 0 204 6 swi5: task queue 16 cc323600 cc9460000 0 0 204 6 swi3: cambio 15 cc323900 cc9420000 0 0 204 6 swi2: camnet 14 cc323c00 cc93e0000 0 0 204 3 sleep c0417120 random 13 cc323f00 cc93a0000 0 0 204 6 swi4: vm 12 cc324200 cc9360000 0 0 20c 2 swi6: tty:sio clock 11 cc324500 cc9320000 0 0 204 6 swi1: net 10 cc324800 cc32d0000 0 0 20c 2 idle 1 cc324b00 cc3290000 0 1 0004200 2 init 0 c02c4200 c0480 0 0 200 3 sched c02c4200 swapper db tr 7 mi_switch(cc98c800,cc98c600,c1b688dc,1,0) at mi_switch+0x153 msleep(cc98c800,cc98c814,68,c0288668,0,cc98c800) at msleep+0x322 kthread_suspend_check(cc98c600,cc98c704,c01b5cf4,cc98c600,cd1aacf8) at kthread_suspend_check+0x50 sched_sync(0,cd1aad48,0,c01b5cf4,0) at sched_sync+0x4c fork_exit(c01b5cf4,0,cd1aad48) at fork_exit+0x9e fork_trampoline() at fork_trampoline+0x8 db --2oS5YaxWCcQjTEyO-- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body
Re: Hang on flushing buffers w/today's -CURRENT, SMP system
It's an UP kernel running on an UP box. Eugene On Fri, Feb 08, 2002 at 04:53:28PM -0800, Julian Elischer wrote: yes but is it a SMP or UP kernel? (SMP kernel can run on some UP h/w) thanks! On Fri, 8 Feb 2002, Eugene M. Kim wrote: On Fri, Feb 08, 2002 at 03:56:21PM -0800, Julian Elischer wrote: In your case we need totrace proc 1 I think.. I got the `reboot' process at this session, so I traced that process. Before I had used `shutdown -r', which probably SIGINT'ed the init process so it's init (pid 1) calling reboot()... The attached log also has its trace JFYI. One more bit of info: as you see from the pcpu output, mine is not an SMP but an UP box. Thanks, Eugene To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Hang on flushing buffers w/today's -CURRENT, SMP system
I'm not particularly good at reading the lock-related output, but it doesn't have other lines than the one that says about the Giant lock, so it seems there isn't any other locks being held by anyone. Eugene On Fri, Feb 08, 2002 at 04:55:42PM -0800, Julian Elischer wrote: I tlooks as if show locks would not show any locks held by anyone.. is this true? On Fri, 8 Feb 2002, Eugene M. Kim wrote: On Fri, Feb 08, 2002 at 03:56:21PM -0800, Julian Elischer wrote: In your case we need totrace proc 1 I think.. I got the `reboot' process at this session, so I traced that process. Before I had used `shutdown -r', which probably SIGINT'ed the init process so it's init (pid 1) calling reboot()... The attached log also has its trace JFYI. One more bit of info: as you see from the pcpu output, mine is not an SMP but an UP box. Thanks, Eugene To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Hang on flushing buffers w/today's -CURRENT, SMP system
--BOKacYhQ+x31HxR3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Feb 08, 2002 at 03:56:21PM -0800, Julian Elischer wrote: In your case we need totrace proc 1 I think.. I got the `reboot' process at this session, so I traced that process. Before I had used `shutdown -r', which probably SIGINT'ed the init process so it's init (pid 1) calling reboot()... The attached log also has its trace JFYI. One more bit of info: as you see from the pcpu output, mine is not an SMP but an UP box. Thanks, Eugene --BOKacYhQ+x31HxR3 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=screenlog.0 Content-Transfer-Encoding: quoted-printable show locks=0D exclusive (sleep mutex) Giant (0xc02e60c0) locked @ /usr/src/sys/kern/kern_= intr.c:532=0D db ps=0D pid proc addruid ppid pgrp flag stat wmesg wchan cmd=0D 279 cdbdc500 cdc6e0000 1 279 0004002 2 reboot= =0D 185 cc988900 cdbbc0000 0 0 204 3 nfsidl c1d053ac nfsiod= 3=0D 184 cc988c00 cdbb80000 0 0 204 3 nfsidl c1d053a8 nfsiod= 2=0D 183 cc988f00 cdbb40000 0 0 204 3 nfsidl c1d053a4 nfsiod= 1=0D 182 cc989200 cdbb0 0 0 204 3 nfsidl c1d053a0 nfsiod= 0=0D 7 cc98b600 cd1a60000 0 0 204 3 ktsusp cc98b800 syncer= =0D 6 cc98b900 cd1a20000 0 0 204 3 ktsusp cc98bb00 vnlru= =0D 5 cc98bc00 cd19e0000 0 0 204 3 ktsusp cc98be00 bufdae= mon=0D 4 cc98bf00 cd19a0000 0 0 204 3 pgzero c0327f88 pageze= ro=0D 3 cc98c200 cd1960000 0 0 204 3 psleep c0327f9c vmdaem= on=0D 2 cc98c500 cd1920000 0 0 204 3 psleep c02e0698 pageda= emon=0D 31 cc98c800 cc9910000 0 0 204 6 irq8: = rtc=0D 30 cc98cb00 cc98d0000 0 0 204 6 irq0: = clk=0D 29 cc321f00 cc9840000 0 0 204 6 irq4: = sio0=0D 28 cc322200 cc980 0 0 204 6 swi0: = tty:sio=0D 27 cc322500 cc97c0000 0 0 204 6 irq7: = ppc0=0D 26 cc322800 cc9780000 0 0 204 6 irq12:= psm0=0D 25 cc322b00 cc9740000 0 0 204 2 irq1: = atkbd0=0D 24 cc322e00 cc970 0 0 204 3 usbevt c1b60210 usb0=0D 23 cc323100 cc96c0000 0 0 204 6 irq11:= uhci0=0D --More--=0D 22 cc323400 cc9680000 0 0 204 6 = irq15: ata1=0D 21 cc323700 cc9640000 0 0 204 6 irq14:= ata0=0D 20 cc323a00 cc95b0000 0 0 204 6 irq5: = pcm0=0D 19 cc323d00 cc9530000 0 0 204 6 irq13:= =0D 18 cc324000 cc94f0000 0 0 204 6 swi5: = acpitaskq=0D 17 cc324300 cc94b0000 0 0 204 6 swi5: = task queue=0D 16 cc324600 cc9470000 0 0 204 6 swi3: = cambio=0D 15 cc324900 cc9430000 0 0 204 6 swi2: = camnet=0D 14 cc324c00 cc93f0000 0 0 204 3 sleep c04141c0 random= =0D 13 cc324f00 cc93b0000 0 0 204 6 swi4: = vm=0D 12 cc325200 cc9370000 0 0 20c 2 swi6: = tty:sio clock=0D 11 cc325500 cc9330000 0 0 204 6 swi1: = net=0D 10 cc325800 cc32e0000 0 0 20c 2 idle=0D 1 cc325b00 cc32a0000 0 1 0004200 3wait cc325b00 init=0D 0 c02c41c0 c047c0000 0 0 200 3 sched c02c41c0 swappe= r=0D db tr 279=0D mi_switch(0,cdbdc500,cdbdc604,10,0) at mi_switch+0x153=0D boot(0,cdbdc714,cdc71d40,c0262b80,cdbdc604) at boot+0x200=0D reboot(cdbdc604,cdc71d20,2,0,0) at reboot+0x37=0D syscall(2f,2f,2f,0,0) at syscall+0x254=0D syscall_with_err_pushed() at syscall_with_err_pushed+0x1b=0D --- syscall (55, FreeBSD ELF, reboot), eip =3D 0x8048b8b, esp =3D 0xbfbffb1= c, ebp =3D 0xbfbffb48 ---=0D db tr 1=0D mi_switch(1,0,cc32dd20,1,0) at mi_switch+0x153=0D msleep(cc325b00,0,15c,c0287e85,0) at msleep+0x322=0D wait1(cc325c04,cc32dd20,0,cc32dd40,c0262b80) at wait1+0x617=0D wait4(cc325c04,cc32dd20,0,bfbffe18,bfbffe24) at wait4+0x12=0D syscall(2f,2f,2f,bfbffe24,bfbffe18) at syscall+0x254=0D syscall_with_err_pushed() at syscall_with_err_pushed+0x1b=0D --- syscall (7, FreeBSD ELF, wait4), eip =3D 0x8050c37, esp =3D 0xbfbffcf8,= ebp =3D 0xbfbffd14 ---=0D db tr 0=0D mi_switch(c02def10,0,483000,1,0) at mi_switch+0x153=0D msleep(c02c41c0,0,44,c02a7570,3e8) at msleep+0x322=0D scheduler(0,47bc00,47b000,0,c0121d1c) at scheduler+0x146=0D mi_startup() at mi_startup+0x95=0D begin() at begin+0x43=0D db ~~=08 =08=08 =08show witness=0D Sleep locks:=0D 0
Re: Hang on flushing buffers w/today's -CURRENT, SMP system
On Fri, Feb 08, 2002 at 01:43:54PM -0800, Julian Elischer wrote: On Fri, 8 Feb 2002, David Wolfskill wrote: Waiting (max 60 seconds) for system process `vnlru' to stop...stopped Waiting (max 60 seconds) for system process `bufdaemon' to stop...stopped Waiting (max 60 seconds) for system process `syncer' to stop...stopped syncing disks... 7 7 can you hit CTLALTESC and get into the debugger? My box shows the same symptom, and yes I can enter DDB. How may I help? Eugene To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Hang on flushing buffers w/today's -CURRENT, SMP system
Attached is the requested DDB log (I guessed pid 7 `syncer' is the process doing the sync; if this is wrong let me know). Eugene PS. I used the serial console, so don't feel sorry to ask. =) On Fri, Feb 08, 2002 at 02:41:30PM -0800, Julian Elischer wrote: On Fri, 8 Feb 2002, Eugene M. Kim wrote: On Fri, Feb 08, 2002 at 01:43:54PM -0800, Julian Elischer wrote: On Fri, 8 Feb 2002, David Wolfskill wrote: Waiting (max 60 seconds) for system process `vnlru' to stop...stopped Waiting (max 60 seconds) for system process `bufdaemon' to stop...stopped Waiting (max 60 seconds) for system process `syncer' to stop...stopped syncing disks... 7 7 can you hit CTLALTESC and get into the debugger? My box shows the same symptom, and yes I can enter DDB. How may I help? Eugene show locks whould be good. also 'ps' and the stack trace of the process doing the sync... tr PID if you can get a serial console that would be best of course. you may wait a while to see if dave can get into ddb on his serial console. that may save you a lot of writing :-) syncing disks... 4 4 Debugger(manual escape to debugger) Stopped at Debugger+0x41: xorl%eax,%eax db show locks exclusive (sleep mutex) Giant (0xc02e6100) locked @ /usr/src/sys/kern/kern_intr.c:532 db ps pid proc addruid ppid pgrp flag stat wmesg wchan cmd 192 cc989300 cdbc50000 0 0 204 3 nfsidl c1d0538c nfsiod 3 191 cc989600 cdbc10000 0 0 204 3 nfsidl c1d05388 nfsiod 2 190 cc989900 cdbbd0000 0 0 204 3 nfsidl c1d05384 nfsiod 1 189 cc989c00 cdbb90000 0 0 204 3 nfsidl c1d05380 nfsiod 0 9 cc98c000 cd1af0000 0 0 204 3 pccbbev c1b39400 pccbb1 8 cc98c300 cd1ab0000 0 0 204 3 pccbbev c1b39800 pccbb0 7 cc98c600 cd1a70000 0 0 204 3 ktsusp cc98c800 syncer 6 cc98c900 cd1a30000 0 0 204 3 ktsusp cc98cb00 vnlru 5 cc98cc00 cd19f0000 0 0 204 3 ktsusp cc98ce00 bufdaemon 4 cc98cf00 cd19b0000 0 0 204 3 pgzero c0327fc8 pagezero 3 cc98d200 cd1970000 0 0 204 3 psleep c0327fdc vmdaemon 2 cc98d500 cd1930000 0 0 204 3 psleep c02e06d8 pagedaemon 31 cc98d800 cc9920000 0 0 204 6 irq8: rtc 30 cc98db00 cc98e0000 0 0 204 6 irq0: clk 29 cc320f00 cc9850000 0 0 204 6 irq4: sio0 28 cc321200 cc9810000 0 0 204 6 swi0: tty:sio 27 cc321500 cc97d0000 0 0 204 6 irq7: ppc0 26 cc321800 cc9790000 0 0 204 6 irq12: psm0 25 cc321b00 cc9750000 0 0 204 2 irq1: atkbd0 24 cc321e00 cc9710000 0 0 204 3 usbevt c1b60210 usb0 --More-- 23 cc322100 cc96d0000 0 0 204 6 irq15: ata1 22 cc322400 cc9690000 0 0 204 6 irq14: ata0 21 cc322700 cc9640000 0 0 204 6 irq11: pccbb0++ 20 cc322a00 cc95a0000 0 0 204 6 irq5: pcm0 19 cc322d00 cc9520000 0 0 204 6 irq13: 18 cc323000 cc94e0000 0 0 204 6 swi5: acpitaskq 17 cc323300 cc94a0000 0 0 204 6 swi5: task queue 16 cc323600 cc9460000 0 0 204 6 swi3: cambio 15 cc323900 cc9420000 0 0 204 6 swi2: camnet 14 cc323c00 cc93e0000 0 0 204 3 sleep c0417120 random 13 cc323f00 cc93a0000 0 0 204 6 swi4: vm 12 cc324200 cc9360000 0 0 20c 2 swi6: tty:sio clock 11 cc324500 cc9320000 0 0 204 6 swi1: net 10 cc324800 cc32d0000 0 0 20c 2 idle 1 cc324b00 cc3290000 0 1 0004200 2 init 0 c02c4200 c0480 0 0 200 3 sched c02c4200 swapper db tr 7 mi_switch(cc98c800,cc98c600,c1b688dc,1,0) at mi_switch+0x153 msleep(cc98c800,cc98c814,68,c0288668,0,cc98c800) at msleep+0x322 kthread_suspend_check(cc98c600,cc98c704,c01b5cf4,cc98c600,cd1aacf8) at kthread_suspend_check+0x50 sched_sync(0,cd1aad48,0,c01b5cf4,0) at sched_sync+0x4c fork_exit(c01b5cf4,0,cd1aad48) at fork_exit+0x9e fork_trampoline() at fork_trampoline+0x8 db
Re: Hang on flushing buffers w/today's -CURRENT, SMP system
On Fri, Feb 08, 2002 at 03:56:21PM -0800, Julian Elischer wrote: In your case we need totrace proc 1 I think.. I got the `reboot' process at this session, so I traced that process. Before I had used `shutdown -r', which probably SIGINT'ed the init process so it's init (pid 1) calling reboot()... The attached log also has its trace JFYI. One more bit of info: as you see from the pcpu output, mine is not an SMP but an UP box. Thanks, Eugene show locks exclusive (sleep mutex) Giant (0xc02e60c0) locked @ /usr/src/sys/kern/kern_intr.c:532 db ps pid proc addruid ppid pgrp flag stat wmesg wchan cmd 279 cdbdc500 cdc6e0000 1 279 0004002 2 reboot 185 cc988900 cdbbc0000 0 0 204 3 nfsidl c1d053ac nfsiod 3 184 cc988c00 cdbb80000 0 0 204 3 nfsidl c1d053a8 nfsiod 2 183 cc988f00 cdbb40000 0 0 204 3 nfsidl c1d053a4 nfsiod 1 182 cc989200 cdbb0 0 0 204 3 nfsidl c1d053a0 nfsiod 0 7 cc98b600 cd1a60000 0 0 204 3 ktsusp cc98b800 syncer 6 cc98b900 cd1a20000 0 0 204 3 ktsusp cc98bb00 vnlru 5 cc98bc00 cd19e0000 0 0 204 3 ktsusp cc98be00 bufdaemon 4 cc98bf00 cd19a0000 0 0 204 3 pgzero c0327f88 pagezero 3 cc98c200 cd1960000 0 0 204 3 psleep c0327f9c vmdaemon 2 cc98c500 cd1920000 0 0 204 3 psleep c02e0698 pagedaemon 31 cc98c800 cc9910000 0 0 204 6 irq8: rtc 30 cc98cb00 cc98d0000 0 0 204 6 irq0: clk 29 cc321f00 cc9840000 0 0 204 6 irq4: sio0 28 cc322200 cc980 0 0 204 6 swi0: tty:sio 27 cc322500 cc97c0000 0 0 204 6 irq7: ppc0 26 cc322800 cc9780000 0 0 204 6 irq12: psm0 25 cc322b00 cc9740000 0 0 204 2 irq1: atkbd0 24 cc322e00 cc970 0 0 204 3 usbevt c1b60210 usb0 23 cc323100 cc96c0000 0 0 204 6 irq11: uhci0 --More-- 22 cc323400 cc9680000 0 0 204 6 irq15: ata1 21 cc323700 cc9640000 0 0 204 6 irq14: ata0 20 cc323a00 cc95b0000 0 0 204 6 irq5: pcm0 19 cc323d00 cc9530000 0 0 204 6 irq13: 18 cc324000 cc94f0000 0 0 204 6 swi5: acpitaskq 17 cc324300 cc94b0000 0 0 204 6 swi5: task queue 16 cc324600 cc9470000 0 0 204 6 swi3: cambio 15 cc324900 cc9430000 0 0 204 6 swi2: camnet 14 cc324c00 cc93f0000 0 0 204 3 sleep c04141c0 random 13 cc324f00 cc93b0000 0 0 204 6 swi4: vm 12 cc325200 cc9370000 0 0 20c 2 swi6: tty:sio clock 11 cc325500 cc9330000 0 0 204 6 swi1: net 10 cc325800 cc32e0000 0 0 20c 2 idle 1 cc325b00 cc32a0000 0 1 0004200 3wait cc325b00 init 0 c02c41c0 c047c0000 0 0 200 3 sched c02c41c0 swapper db tr 279 mi_switch(0,cdbdc500,cdbdc604,10,0) at mi_switch+0x153 boot(0,cdbdc714,cdc71d40,c0262b80,cdbdc604) at boot+0x200 reboot(cdbdc604,cdc71d20,2,0,0) at reboot+0x37 syscall(2f,2f,2f,0,0) at syscall+0x254 syscall_with_err_pushed() at syscall_with_err_pushed+0x1b --- syscall (55, FreeBSD ELF, reboot), eip = 0x8048b8b, esp = 0xbfbffb1c, ebp = 0xbfbffb48 --- db tr 1 mi_switch(1,0,cc32dd20,1,0) at mi_switch+0x153 msleep(cc325b00,0,15c,c0287e85,0) at msleep+0x322 wait1(cc325c04,cc32dd20,0,cc32dd40,c0262b80) at wait1+0x617 wait4(cc325c04,cc32dd20,0,bfbffe18,bfbffe24) at wait4+0x12 syscall(2f,2f,2f,bfbffe24,bfbffe18) at syscall+0x254 syscall_with_err_pushed() at syscall_with_err_pushed+0x1b --- syscall (7, FreeBSD ELF, wait4), eip = 0x8050c37, esp = 0xbfbffcf8, ebp = 0xbfbffd14 --- db tr 0 mi_switch(c02def10,0,483000,1,0) at mi_switch+0x153 msleep(c02c41c0,0,44,c02a7570,3e8) at msleep+0x322 scheduler(0,47bc00,47b000,0,c0121d1c) at scheduler+0x146 mi_startup() at mi_startup+0x95 begin() at begin+0x43 db ~~ show witness Sleep locks: 0 (dead) -- last acquired @ (dead):0 0 (dead) -- last acquired @ (dead):0 0 Giant -- last acquired @ /usr/src/sys/kern/kern_intr.c:532 1 ithread -- last acquired @ /usr/src/sys/kern/kern_intr.c:269 2 struct filedesc -- last acquired @ /usr/src/sys/kern/kern_descrip.c:1170 2 fork list -- last acquired @ /usr/src/sys/kern/kern_fork.c:649 3lockmgr -- last acquired @ /usr/src/sys/kern/kern_lock.c:227 2 proctree -- last acquired @ /usr/src/sys/kern
Re: Hang on flushing buffers w/today's -CURRENT, SMP system
It's an UP kernel running on an UP box. Eugene On Fri, Feb 08, 2002 at 04:53:28PM -0800, Julian Elischer wrote: yes but is it a SMP or UP kernel? (SMP kernel can run on some UP h/w) thanks! On Fri, 8 Feb 2002, Eugene M. Kim wrote: On Fri, Feb 08, 2002 at 03:56:21PM -0800, Julian Elischer wrote: In your case we need totrace proc 1 I think.. I got the `reboot' process at this session, so I traced that process. Before I had used `shutdown -r', which probably SIGINT'ed the init process so it's init (pid 1) calling reboot()... The attached log also has its trace JFYI. One more bit of info: as you see from the pcpu output, mine is not an SMP but an UP box. Thanks, Eugene To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Hang on flushing buffers w/today's -CURRENT, SMP system
I'm not particularly good at reading the lock-related output, but it doesn't have other lines than the one that says about the Giant lock, so it seems there isn't any other locks being held by anyone. Eugene On Fri, Feb 08, 2002 at 04:55:42PM -0800, Julian Elischer wrote: I tlooks as if show locks would not show any locks held by anyone.. is this true? On Fri, 8 Feb 2002, Eugene M. Kim wrote: On Fri, Feb 08, 2002 at 03:56:21PM -0800, Julian Elischer wrote: In your case we need totrace proc 1 I think.. I got the `reboot' process at this session, so I traced that process. Before I had used `shutdown -r', which probably SIGINT'ed the init process so it's init (pid 1) calling reboot()... The attached log also has its trace JFYI. One more bit of info: as you see from the pcpu output, mine is not an SMP but an UP box. Thanks, Eugene To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Hang on flushing buffers w/today's -CURRENT, SMP system
On Fri, Feb 08, 2002 at 05:09:31PM -0800, Julian Elischer wrote: h so what is the difference between your kernel and mine that works? /me scratches his head just out of curiosity, have you tried a very latest -current? Not the very latest; this source is about a day old. do you have your own config? how does GENERIC behave? I do have my own config; you can get it at: http://home.the-7.net/~ab/PL-DAAL (config file itself) http://home.the-7.net/~ab/PL-DAAL.hints (... and device hints) I haven't tried GENERIC yet. Eugene (what kind of disks do you have?) Julian On Fri, 8 Feb 2002, Eugene M. Kim wrote: It's an UP kernel running on an UP box. Eugene On Fri, Feb 08, 2002 at 04:53:28PM -0800, Julian Elischer wrote: yes but is it a SMP or UP kernel? (SMP kernel can run on some UP h/w) thanks! On Fri, 8 Feb 2002, Eugene M. Kim wrote: On Fri, Feb 08, 2002 at 03:56:21PM -0800, Julian Elischer wrote: In your case we need totrace proc 1 I think.. I got the `reboot' process at this session, so I traced that process. Before I had used `shutdown -r', which probably SIGINT'ed the init process so it's init (pid 1) calling reboot()... The attached log also has its trace JFYI. One more bit of info: as you see from the pcpu output, mine is not an SMP but an UP box. Thanks, Eugene To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: NCP Broken ?
On Fri, 7 Dec 2001 10:55:03 -0800 (PST) Julian Elischer [EMAIL PROTECTED] wrote: JE: yes ncp and nwfs are broken in -current Hm, and when this be work ? -- Best Regards Kaltashkin Eugene ZHECKA-RIPN To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
NCP Broken ?
: previous declaration of `ncp_conn_putprochandles' ../../../netncp/ncp_conn.c: In function `ncp_conn_putprochandles': ../../../netncp/ncp_conn.c:582: warning: passing arg 4 of `lockmgr' from incompatible pointer type ../../../netncp/ncp_conn.c:591: warning: passing arg 4 of `lockmgr' from incompatible pointer type ../../../netncp/ncp_conn.c: In function `ncp_sysctl_connstat': ../../../netncp/ncp_conn.c:636: structure has no member named `p' ../../../netncp/ncp_conn.c:652: structure has no member named `p' *** Error code 1 Stop in /usr/src/sys/i386/compile/freebsd. -- Best Regards Kaltashkin Eugene ZHECKA-RIPN To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Perl build breakage
I think it is necessary to add the notice to UPDATING because it's been half an year since the incident day. If it were like within last few days, I definitely would've gotten some hints about the fix by scanning -current (which I did). But I had to scratch my heads helplessly until I asked the list, and you know that the typical response of the list to this type of inquiry has been `Welcome to Yesterday.' If UPDATING does not properly save people like me, what will? So, Warner, could you update the relevant entry in UPDATING? Thanks, Eugene On Sat, Dec 01, 2001 at 10:43:39PM +0100, Anton Berezin wrote: On Sat, Dec 01, 2001 at 01:26:11PM -0800, Eugene M. Kim wrote: Oh, never mind. I just re-read the thread you pointed (thanks) and saw it affects the systems *installed around the breakage date*. UPDATING does not mention about this fact (it simply says `Building perl was broken'); perhaps it should be updated to mention the misfortune of the installed system and the link to the fix; Warner?). Well, that would definitely be a good idea half a year ago. Nowadays, I doubt there will be any significant number of unlucky souls having operating -current systems built between May 1st and May 2nd. You might be unique at that. ;-) Cheers, %Anton. -- | Anton Berezin| FreeBSD: The power to serve | | catpipe Systems ApS _ _ |_ | http://www.FreeBSD.org | | [EMAIL PROTECTED](_(_|| |[EMAIL PROTECTED] | | +45 7021 0050| Private: [EMAIL PROTECTED] | To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Perl build breakage
Well, I *did* read UPDATING, and I saw the perl breakage notice. But it seems not to be relevant to me, as my source code is current (I mean, up to date); I cvsupped it just before starting make world. Only my host system is built around May 1. Thanks, Eugene On Sat, Dec 01, 2001 at 05:18:45PM +0100, Anton Berezin wrote: On Thu, Nov 29, 2001 at 10:42:45AM -0800, Eugene M. Kim wrote: Hello, I am getting the following error in the make depend stage; could anyone shed a light? (The host system is 5-current as of around May 1.) From UPDATING (you do read UPDATING, don't you?): 20010502: Perl breakage in 20010501 was corrected at 14:18:33 PDT. 20010501: Building perl was broken at 02:25:25 PDT. Please see the old HEADS UP message, which describes the fix: http://www.freebsd.org/cgi/getmsg.cgi?fetch=192223+0+/usr/local/www/db/text/2001/freebsd-current/20010506.freebsd-current Thanks, Eugene snip snip === libperl === miniperl === perl Extracting config.h (with variable substitutions) Extracting cflags (with variable substitutions) Extracting writemain (with variable substitutions) Extracting myconfig (with variable substitutions) Missing right curly or square bracket at lib/SelfLoader.pm line 69, at end of line syntax error at lib/SelfLoader.pm line 69, at EOF Compilation failed in require at /usr/libdata/perl/BSDPAN/BSDPAN/Override.pm line 17. Compilation failed in require at /usr/libdata/perl/BSDPAN/Config.pm line 37. BEGIN failed--compilation aborted at /usr/libdata/perl/BSDPAN/Config.pm line 37. Compilation failed in require at /usr/src/gnu/usr.bin/perl/perl/../../../../contrib/perl5/configpm line 430. *** Error code 255 Stop in /usr/src/gnu/usr.bin/perl/perl. *** Error code 1 Stop in /usr/src/gnu/usr.bin/perl. *** Error code 255 Stop in /usr/src/gnu/usr.bin/perl/perl. *** Error code 1 Stop in /usr/src/gnu/usr.bin/perl. snip snip Cheers, *Anton. -- | Anton Berezin| FreeBSD: The power to serve | | catpipe Systems ApS _ _ |_ | http://www.FreeBSD.org | | [EMAIL PROTECTED](_(_|| |[EMAIL PROTECTED] | | +45 7021 0050| Private: [EMAIL PROTECTED] | To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Perl build breakage
Oh, never mind. I just re-read the thread you pointed (thanks) and saw
it affects the systems *installed around the breakage date*.
UPDATING does not mention about this fact (it simply says `Building perl
was broken'); perhaps it should be updated to mention the misfortune of
the installed system and the link to the fix; Warner?).
Thanks,
Eugene
On Sat, Dec 01, 2001 at 01:14:44PM -0800, Eugene M. Kim wrote:
Well, I *did* read UPDATING, and I saw the perl breakage notice. But it
seems not to be relevant to me, as my source code is current (I mean, up
to date); I cvsupped it just before starting make world. Only my host
system is built around May 1.
Thanks,
Eugene
On Sat, Dec 01, 2001 at 05:18:45PM +0100, Anton Berezin wrote:
On Thu, Nov 29, 2001 at 10:42:45AM -0800, Eugene M. Kim wrote:
Hello,
I am getting the following error in the make depend stage; could anyone
shed a light?
(The host system is 5-current as of around May 1.)
From UPDATING (you do read UPDATING, don't you?):
20010502:
Perl breakage in 20010501 was corrected at 14:18:33 PDT.
20010501:
Building perl was broken at 02:25:25 PDT.
Please see the old HEADS UP message, which describes the fix:
http://www.freebsd.org/cgi/getmsg.cgi?fetch=192223+0+/usr/local/www/db/text/2001/freebsd-current/20010506.freebsd-current
Thanks,
Eugene
snip snip
=== libperl
=== miniperl
=== perl
Extracting config.h (with variable substitutions)
Extracting cflags (with variable substitutions)
Extracting writemain (with variable substitutions)
Extracting myconfig (with variable substitutions)
Missing right curly or square bracket at lib/SelfLoader.pm line 69, at end of
line
syntax error at lib/SelfLoader.pm line 69, at EOF
Compilation failed in require at /usr/libdata/perl/BSDPAN/BSDPAN/Override.pm
line 17.
Compilation failed in require at /usr/libdata/perl/BSDPAN/Config.pm line 37.
BEGIN failed--compilation aborted at /usr/libdata/perl/BSDPAN/Config.pm line 37.
Compilation failed in require at
/usr/src/gnu/usr.bin/perl/perl/../../../../contrib/perl5/configpm line 430.
*** Error code 255
Stop in /usr/src/gnu/usr.bin/perl/perl.
*** Error code 1
Stop in /usr/src/gnu/usr.bin/perl.
*** Error code 255
Stop in /usr/src/gnu/usr.bin/perl/perl.
*** Error code 1
Stop in /usr/src/gnu/usr.bin/perl.
snip snip
Cheers,
*Anton.
--
| Anton Berezin| FreeBSD: The power to serve |
| catpipe Systems ApS _ _ |_ | http://www.FreeBSD.org |
| [EMAIL PROTECTED](_(_|| |[EMAIL PROTECTED] |
| +45 7021 0050| Private: [EMAIL PROTECTED] |
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
sio1: 1 more silo overflow (total 1)
Hello After rebuild kernel cvsup'ped yesterday (last cvsup i made in august) i see some strange errors. I see what acpi controller control all my irq. Now my sio ports not work. what is it and why ? dmesg in attached file. And what i can do for resolve this problem ? -- Best Regards Kaltashkin Eugene ZHECKA-RIPN Copyright (c) 1992-2001 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #0: Wed Nov 7 23:37:45 MSK 2001 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/freebsd Preloaded elf kernel /boot/kernel/kernel at 0xc03a5000. Preloaded elf module /boot/kernel/snd_sb16.ko at 0xc03a50a8. Preloaded elf module /boot/kernel/snd_sbc.ko at 0xc03a5158. Preloaded elf module /boot/kernel/snd_pcm.ko at 0xc03a5204. Preloaded elf module /boot/kernel/acpi.ko at 0xc03a52b0. Timecounter i8254 frequency 1193182 Hz Timecounter TSC frequency 466684701 Hz CPU: Pentium II/Pentium II Xeon/Celeron (466.68-MHz 686-class CPU) Origin = GenuineIntel Id = 0x652 Stepping = 2 Features=0x183f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR real memory = 134205440 (131060K bytes) avail memory = 126869504 (123896K bytes) Pentium Pro MTRR support enabled VESA: v2.0, 8192k memory, flags:0x0, mode table:0xc02d69e2 (122) VESA: ATI MACH64 Using $PIR table, 6 entries at 0xc00f0d10 npx0: math processor on motherboard npx0: INT 16 interface acpi0: ASUS P2B on motherboard acpi0: power button is handled as a fixed feature programming model. Timecounter ACPI frequency 3579545 Hz acpi_timer0: 24-bit timer at 3.579545MHz port 0xe408-0xe40b on acpi0 acpi_cpu0: CPU on acpi0 acpi_button0: Power Button on acpi0 acpi_pcib0: Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: PCI bus on acpi_pcib0 agp0: Intel 82443BX (440 BX) host to PCI bridge mem 0xe400-0xe7ff at device 0.0 on pci0 pcib1: PCI-PCI bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 pci1: display, VGA at device 0.0 (no driver attached) isab0: PCI-ISA bridge at device 4.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel PIIX4 ATA33 controller port 0xb800-0xb80f at device 4.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 uhci0: Intel 82371AB/EB (PIIX4) USB controller port 0xb400-0xb41f at device 4.2 on pci0 acpi_pcib0: possible interrupts: 3 4 5 6 7 9 10 11 12 14 15 acpi_pcib0: routed interrupt 3 via \\_SB_.LNKD usb0: Intel 82371AB/EB (PIIX4) USB controller on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered pci0: bridge, PCI-unknown at device 4.3 (no driver attached) fxp0: Intel Pro 10/100B/100+ Ethernet port 0xb000-0xb03f mem 0xe100-0xe10f,0xe180-0xe1800fff irq 11 at device 10.0 on pci0 fxp0: Ethernet address 00:d0:b7:60:fd:05 inphy0: i82555 10/100 media interface on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto pci0: display, VGA at device 11.0 (no driver attached) fdc0: NEC 72065B or clone port 0x3f7,0x3f2-0x3f5 irq 6 on acpi0 fdc0: FIFO enabled, 8 bytes threshold fd0: 1440-KB 3.5 drive on fdc0 drive 0 ppc0 port 0x378-0x37f irq 7 on acpi0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode plip0: PLIP network interface on ppbus0 lpt0: Printer on ppbus0 lpt0: Interrupt-driven port ppi0: Parallel I/O on ppbus0 sio0 port 0x3e8-0x3ef irq 4 on acpi0 sio0: type 16550A sio1: configured irq 3 not in bitmap of probed irqs 0 sio1 port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A atkbdc0: Keyboard controller (i8042) port 0x64,0x60 irq 1 on acpi0 atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: model Generic PS/2 mouse, device ID 0 fdc-: fdc0 already exists, skipping it ata-: ata0 already exists, skipping it ata-: ata1 already exists, skipping it atkbdc-: atkbdc0 already exists, skipping it sio-: sio0 already exists, skipping it sio-: sio1 already exists, skipping it ppc-: ppc0 already exists, skipping it sc-: sc0 already exists, skipping it orm0: Option ROMs at iomem 0xc-0xc7fff,0xc8000-0xc8fff on isa0 sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x300 pmtimer0 on isa0 vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 sbc1: Creative SB16/SB32 at port 0x220-0x22f,0x330-0x331,0x388-0x38b irq 5 drq 1,5 on isa0 pcm1: SB16 DSP 4.13 on sbc1 ata2: Generic ESDI/IDE/ATA controller at port 0x168-0x16f,0x36e-0x36f irq 10 on isa0 ad0: DMA limited to UDMA33, non-ATA66 compliant cable ad0: 4112MB QUANTUM FIREBALLlct08 04 [8912/15/63] at ata0-master UDMA33 ad2: 9787MB WDC WD102AA [19885/16/63] at ata1-master UDMA33 ad3: 9768MB ST310212A [19846/16/63] at ata1-slave UDMA33 acd0: CDROM CRD-8482B at ata0-slave PIO4 Mounting root from ufs:/dev/ad0s1a sio1: 1 more silo overflow (total 1) sio1: 1 more silo overflow (total 2) sio1: 2 more silo
kern/29530
Could anybody examine and commit the patch in the PR kern/29530? It fixes the support for KingByte USB Pen Drive by adding a quirk entry to src/sys/cam/scsi/scsi_da.c. It would be even better if this were MFC'ed before 4.4 comes out. Thank you in advance! Eugene To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Request for change: Disabling filename globbing by ftpd(8)
Greetings,
* Conclusion and suggestion first:
Csh-style filename globbing in ftpd(8) is *evil*. Please apply the
attached patch to make it an option and disable it in the default
configuration.
* What the patch does:
It makes the filename globbing an optional feature, controlled by the
new flag -g. -g none disables the globbing entirely (default),
-g tildeonly enables home expansion (aka tilde expansion) only, and
-g all enables all expansions using glob(3). The current behavior can
be kept by using -g all.
* My reason to it:
Many FTP clients, especially automated mirroring tools and GUI-based
ones, and most notably the `mget' command commonly found on standard
FTP clients, do one thing in common: they obtain the name of the remote
repository using NLST command then subsequently use some or all of the
returned names as the argument to other commands such as RETR.
In order for this approach to succeed, arguments to the RETR command
must not be parsed in any special way but they must be considered as
literal filenames. However, this is not the case with the stock ftpd(8)
shipped with FreeBSD; it has a `feature' that expands the argument to
RETR/CWD/STOR/... commands in a Csh-like way (i.e. filename globbing,
tilde/brace/bracket/ampersand expansions).
This changes the semantics of the on-the-wire protocol. RFC 959 does
not specify any special handling of pathname arguments, so the change
breaks compatibility with any potential client which legitimately
assumes no special tweaks to pathnames are necessary.
Moreover, commands such as RETR, CWD and STOR only expect an argument
that designates a single file or directory; it is impossible to fetch
multiple files using RETR, or chdir into multiple directories at once
:-). In this context, globbing by ftpd is nothing more than an useful
shorthand (e.g. we can say cd abc* instead of cd abcdefghijklmnopq),
which is much better to be done on the client side.
Example: the remote directory contains two files, `A.jpg' and `A{3}.jpg'
and the client tries to `mget A*.jpg'.
Step 1. The client sends NLST command.
Step 2. The server returns a full listing of the remote directory.
Step 3. The client searches through the list and picks up the two files.
Step 4. The client performs `RETR A.jpg', which succeeds.
Step 5. The client performs `RETR A{3}.jpg', which fails because the
server performs brace expansion on the name and tries to send `A3.jpg'.
Any comments and suggestions are welcomed. Thank you.
Best Regards,
Eugene
diff -urN ftpd/ftpcmd.y ftpd.new/ftpcmd.y
--- ftpd/ftpcmd.y Wed Apr 18 03:03:52 2001
+++ ftpd.new/ftpcmd.y Mon Jul 9 01:34:29 2001
@@ -71,6 +71,7 @@
#include libutil.h
#include extern.h
+#include types.h
extern union sockunion data_dest, his_addr;
extern int logged_in;
@@ -92,6 +93,8 @@
extern char tmpline[];
extern int readonly;
extern int noepsv;
+extern globbing_t globbing;
+extern char curname[MAXLOGNAME];
off_t restart_point;
@@ -924,7 +927,7 @@
* processing, but only gives a 550 error reply.
* This is a valid reply in some cases but not in others.
*/
- if (logged_in $1) {
+ if (logged_in globbing == GLOBBING_ALL $1) {
glob_t gl;
int flags =
GLOB_BRACE|GLOB_NOCHECK|GLOB_QUOTE|GLOB_TILDE;
@@ -944,6 +947,37 @@
}
globfree(gl);
free($1);
+ } else if (globbing == GLOBBING_TILDEONLY
+ $1[0] == '~') {
+ /* do tilde expansion by ourselves */
+ char *dir, *newdir, *afteruser, afteruser_ch;
+ struct passwd *pw;
+ $$ = $1;
+ do {
+ dir = strdup($1);
+ if (dir == NULL)
+ break;
+ afteruser = strchr(dir, '/');
+ if (afteruser == NULL)
+ afteruser = strchr(dir, '\0');
+ afteruser_ch = *afteruser;
+ *afteruser = '\0';
+ pw = getpwnam((dir[1] != '\0')
+ ? dir + 1 : curname);
+ *afteruser = afteruser_ch;
+ if (pw == NULL || pw-pw_dir == NULL)
+ break;
+ asprintf(newdir, %s%s,
+ pw-pw_dir, afteruser
Cross-platform make world/release?
Greetings, Short question: is FreeBSD capable of cross-platform make world and release (e.g. build of Alpha world/release on x86 and vice versa)? TIA, Eugene To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
broken sshd or libssl ?
I update 4.3 RC to 5.0-CURRENT and have some troubles. Why make buildworld build system without RSA support ? And how i can correct this problem ? System cvsuped today. freebsd:/home/zhecka# sshd -d debug1: sshd version OpenSSH_2.3.0 [EMAIL PROTECTED] 20010319 no RSA support in libssl and libcrypto. See ssl(8) Disabling protocol version 1 debug1: read DSA private key done debug1: Bind to port 22 on 0.0.0.0. Server listening on 0.0.0.0 port 22. debug1: Server will not fork when running in debugging mode. Connection from localhost port 1021 Connection from 127.0.0.1 port 1021 debug1: Client protocol version 2.0; client software version OpenSSH_2.3.0 [EMAIL PROTECTED] 20010319 debug1: match: OpenSSH_2.3.0 [EMAIL PROTECTED] 20010319 pat ^OpenSSH[-_]2\.3 Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_2.3.0 [EMAIL PROTECTED] 20010319 debug1: send KEXINIT debug1: done debug1: wait KEXINIT debug1: got kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1 debug1: got kexinit: ssh-dss debug1: got kexinit: 3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes128-cbc,aes192-cbc,aes256-cbc,rijndael128-cbc,rijndael192-cbc,rijndael256-cbc,[EMAIL PROTECTED] debug1: got kexinit: 3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes128-cbc,aes192-cbc,aes256-cbc,rijndael128-cbc,rijndael192-cbc,rijndael256-cbc,[EMAIL PROTECTED] debug1: got kexinit: hmac-sha1,hmac-md5,[EMAIL PROTECTED] debug1: got kexinit: hmac-sha1,hmac-md5,[EMAIL PROTECTED] debug1: got kexinit: none debug1: got kexinit: none debug1: got kexinit: debug1: got kexinit: debug1: first kex follow: 0 debug1: reserved: 0 debug1: done debug1: kex: client-server 3des-cbc hmac-sha1 none debug1: kex: server-client 3des-cbc hmac-sha1 none debug1: Wait SSH2_MSG_KEX_DH_GEX_REQUEST. /etc/ssh/primes: No such file or directory WARNING: /etc/ssh/primes does not exist, using old prime fatal: DH_generate_key debug1: Calling cleanup 0x805ec78(0x0) -- Best Regards Kaltashkin Eugene ZHECKA-RIPN To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
nos-tun multihomed machines
hi!
Please, review the following PR:
http://www.freebsd.org/cgi/query-pr.cgi?pr=25847
Same patch is in the attach.
--
-BEGIN GEEK CODE BLOCK-
Version: 3.1
GCS/CC/IT d-@ s: a- C++ UBSC$ P+@ L- E--- W+ N++ o? K? w-- O- M- V-
PS@ PE@ Y+ PGP+ t 5 X R tv- b+++() DI-- D+(++) G++ e- h--- r y+++
--END GEEK CODE BLOCK--
--- nos-tun.c.orig Fri Mar 16 11:01:38 2001
+++ nos-tun.c Fri Mar 16 11:17:35 2001
@@ -239,11 +239,13 @@
char *point_to = NULL;
char *to_point = NULL;
char *target;
+ char *source = NULL;
char *protocol = NULL;
int protnum;
struct sockaddr t_laddr; /* Source address of tunnel */
struct sockaddr whereto; /* Destination of tunnel */
+ struct sockaddr wherefrom;/* Source of tunnel */
struct sockaddr_in *to;
char buf[0x2000]; /* Packets buffer */
@@ -272,7 +274,7 @@
argc -= optind;
argv += optind;
- if (argc != 1 || (devname == NULL) ||
+ if ((argc != 1 argc != 2) || (devname == NULL) ||
(point_to == NULL) || (to_point == NULL)) {
usage();
}
@@ -282,7 +284,11 @@
else
protnum = atoi(protocol);
- target = *argv;
+ if (argc == 1) {
+ target = *argv;
+ } else {
+ source = *argv++; target = *argv;
+ }
/* Establish logging through 'syslog' */
openlog("nos-tun", LOG_PID, LOG_DAEMON);
@@ -306,6 +312,15 @@
Finish(5);
}
+ if (source) {
+ if (Set_address(source, (struct sockaddr_in *)wherefrom))
+ Finish(9);
+if (bind(net, wherefrom, sizeof(wherefrom)) 0) {
+ syslog(LOG_ERR, "can't bind source address - %m");
+ Finish(10);
+ }
+ }
+
if (connect(net,whereto,sizeof(struct sockaddr_in)) 0 ) {
syslog(LOG_ERR,"can't connect to target - %m");
close(net);
@@ -365,7 +380,7 @@
usage()
{
fprintf(stderr,
-"usage: nos-tun -t tun_name -s source_addr -d dest_addr -p protocol_number
target_addr\n");
+"usage: nos-tun -t tun_name -s source_addr -d dest_addr -p protocol_number
+[source_addr] target_addr\n");
exit(1);
}
Re: HEADS UP: I386_CPU
how about to have in a distribution two version of GENERIC kernel (and modules of course) and let sysinstall choose right set ? In article [EMAIL PROTECTED] you wrote: On Tuesday, 16 January 2001 at 9:28:43 -0500, Will Andrews wrote: On Tue, Jan 16, 2001 at 09:16:14AM -0500, Kenneth Wayne Culver wrote: Wont this make installing using sysinstall a bit hard? I know the generic kernel includes all the CPU lines, so that all cpu's are recognized... so are you going to just take this line out of the generic kernel, and have a special kern.flp disk with a generic kernel that only has the i386 support in it? I don't think it's worth the effort. By the time 5.0-RELEASE goes out, the 386 will have been around for over 10 years (actually I think it has already reached that point and gone beyond). There are not likely to be many more installs of FreeBSD on 386's, let alone 5.x installs. People who *really* want to install 5.x on a 386 can generate their own kernel and such. Don't forget that the i386 is still a popular CPU for embedded work. Of course, embedded people will have less of an issue with sysinstall. Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message -- end of forwarded message -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Small fix for compile error with internat crypto code
It looks like a race condition. -@mkdir -p openssl is a good workaround I guess, although it could be fine if we had a flag to mkdir(1) that makes it just succeed when there's already a directory of the same name. Just my 2 wons (1 KRW ~= .0084 USD as of this writing :-p), Eugene On Fri, 12 May 2000, David O'Brien wrote: | On Fri, May 12, 2000 at 04:41:09PM +0900, Munehiro Matsuda wrote: | When run 'make -j4 buildworld' with internat crypto code installed, | I get following error: | mkdir: openssl: File exists | *** Error code 1 | - @test -d openssl || mkdir -p openssl | + -@mkdir -p openssl | | The "-" is not needed as `mkdir -p' will not return an error condition. | | - @test -d openssl || mkdir -p openssl | + -@mkdir -p openssl | | Same here. Bruce Evans just told me the other day that make(1) can have | issues with shell "" and "||". Guess you hit one of the cases it can | fail with -j. | | -- Eugene M. Kim [EMAIL PROTECTED] "Is your music unpopular? Make it popular; make music which people like, or make people who like your music." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Small fix for compile error with internat crypto code
On Fri, 12 May 2000, David O'Brien wrote: | On Fri, May 12, 2000 at 06:34:08AM -0700, Eugene M. Kim wrote: | I guess, although it could be fine if we had a flag to mkdir(1) that | makes it just succeed when there's already a directory of the same name. | | Yes, that is "-p". | Oh yes you're right. But then things still remain strange... Isn't this: test -d openssl || mkdir -p openssl supposed to never give the `mkdir: openssl: File exists' error? So I guess the real cause of that bug is not a race condition between two mkdir -p commands. Haven't seen the error recently so can't exactly tell, but it looks more like there is already an `openssl' that isn't a directory. Eugene -- Eugene M. Kim [EMAIL PROTECTED] "Is your music unpopular? Make it popular; make music which people like, or make people who like your music." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Top, vmstat, systat, etc. Broken
Check if your /dev/null has been replaced by some stupid `real' file. The `nlist failed' problem bit me several weeks ago on two machines (one running 4-stable and the other running -current) and it turned out to be a /dev/null problem. You may want to remove /dev/null maually and do a `sh MAKEDEV std' to alleviate this problem. I don't have the vaguest idea how this happened, though. Hope this helped, Eugene On Mon, 3 Apr 2000, Thomas Dean wrote: | To build the kernel, I | | # cd sys/i386/conf | # config -r name | # cd ../../compile/name | # make depend | # make -j36 | # make install | | /etc/make.conf has no uncommented lines in it. | | # file /kernel | /kernel: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), | dynamically linked, not stripped | | tomdean | | | To Unsubscribe: send mail to [EMAIL PROTECTED] | with "unsubscribe freebsd-current" in the body of the message | -- Eugene M. Kim [EMAIL PROTECTED] "Is your music unpopular? Make it popular; make music which people like, or make people who like your music." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: IPv6: can a link-site (or global) address be configured inrc.conf?
(Cc'ed to the 6BONE mailing list in the hope that someone there could answer my question as well) Speaking of the address allocation, is there a way for an individual to get a non-local address space (so that all of my machines can get an unique IPv6 address)? I've read through the 6BONE website, and it seems to me that I somehow have to `qualify' in order to get one. (And the fact that I just need 10 addresses makes me feel guilty; AFAIK the minimum allocation unit is 2^64-address block :-p.) Thank you in advance, Eugene On Mon, 6 Mar 2000, Bill Fenner wrote: | Bruce is right that machines expect to learn their prefixes from their | local router; however if you're just playing around you might want to | set it yourself. The easiest way I've found to do this is to say that | this machine is a router: | | # sysctl -w net.inet6.ip6.forwarding=1 | net.inet6.ip6.forwarding: 0 - 1 | | and then run "prefix" to set a site-local prefix: | | # prefix dc0 fec0:0:0:1:: | # ifconfig dc0 | dc0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 | inet6 fe80::2a0:ccff:fe36:7410%dc0 prefixlen 64 scopeid 0x1 | inet6 fec0::1:2a0:ccff:fe36:7410 prefixlen 64 | | Of course, if you have global address space too you can assign that prefix | too. | | Bill -- Eugene M. Kim [EMAIL PROTECTED] "Is your music unpopular? Make it popular; make music which people like, or make people who like your music." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: problems with voxware/snd0 kernel compilations..
$ grep -l '^mpu401' /sys/i386/isa/sound/*.c /sys/i386/isa/sound/mpu401.c $ grep '^i386/isa/sound/mpu401\.c' /sys/conf/files.i386 i386/isa/sound/mpu401.c optionalmpu i386/isa/sound/mpu401.c optionalsscape $ I guess css0 needs mpu0 to handle the onboard MPU401 interface. HTH, Eugene On Thu, 10 Feb 2000, f.johan.beisser wrote: | | i'm attempting to build a kernel with the "old style" voxware drivers for | the CS423x (crystal sound, or css0 in the kernel config) and i get this | wonderful error torwards the end of the kernel build: | | cc -c -O -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes | -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual | -fformat-extensions -ansi -nostdinc -I- -I. -I../.. -I../../../include | -D_KERNEL -include opt_global.h -elf -mpreferred-stack-boundary=2 vers.c | linking kernel | cs4232.o: In function `attach_cs4232': | cs4232.o(.text+0x1cb): undefined reference to `probe_mpu401' | cs4232.o(.text+0x1d8): undefined reference to `attach_mpu401' | *** Error code 1 | | | and it fails, obviously. everything prior to the make goes just fine.. | | any clues or advice? | | -- jan | | +-/ f. johan beisser /--+ | email: jan[at]caustic.org web: http://www.caustic.org/~jan |"knowledge is power. power corrupts. study hard, be evil." | | | | To Unsubscribe: send mail to [EMAIL PROTECTED] | with "unsubscribe freebsd-current" in the body of the message | -- Eugene M. Kim [EMAIL PROTECTED] "Is your music unpopular? Make it popular; make music which people like, or make people who like your music." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: any ideas on Vortex?
On Wed, 9 Feb 2000, Kenneth Wayne Culver wrote: | Just wondering, does anyone know if we will have a working driver for the | Aureal Vortex soundcard by the time 4.0 is released? I'm just curious | because I thought the driver for this card was supposed to be finished a | long time ago.. If my memory serves me correctly, the support for Vortex chipset family has been suspended due to lack of programming information. I hope the situation will get better when Aureal releases the technical documentation (which they promised to do on their website -- linux.aureal.com). Eugene -- Eugene M. Kim [EMAIL PROTECTED] "Is your music unpopular? Make it popular; make music which people like, or make people who like your music." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Pre-3.3 to 4.0 w/ IPsec
On Sun, 6 Feb 2000, John Polstra wrote: | In article [EMAIL PROTECTED], | Eugene M. Kim [EMAIL PROTECTED] wrote: | Just wanted to share the knowledge of this little devil. | | For those who want to upgrade via cvsup their pre-3.3 system to test | IPsec: due to the addition of src-sys-crypto in secure-supfile, one will | have to cvsup first, upgrade their /usr/share/examples directory (cd | /usr/src/share/examples ; make depend all install) and cvsup again | before they can compile a kernel with IPsec. | | That seems like a pretty hard way to do it. Why not just edit your | supfile and add src-sys-crypto to it? Because the supfiles could have other changes as well, but yes I agree with you that it's an overdose :-). An alternative and more general way could be checking out `examples' from one of the anonymous CVS repositories (such as anoncvs.freebsd.org) and doing `make depend all install' in that directory before actually cvsupping the whole source tree. This shouldn't be too difficult given the fact that we already have cvs in the base system. Eugene -- Eugene M. Kim [EMAIL PROTECTED] "Is your music unpopular? Make it popular; make music which people like, or make people who like your music." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ftp 10.10
Well, a reluctant yes. I've been enjoying the notation of '127.1' (and it's hardcoded to several scripts of mine). This is actually a hard decision; from the compatibility point of view inet_aton should allow non-standard forms, but from the standard's point of view it shouldn't. I'd rather leave this to the current trend (of which I don't have the vaguest idea). Regards, Eugene On Mon, 7 Feb 2000, Yoshinobu Inoue wrote: | marc With ping it is still functioning. I cannot find what changed this. | marc cvs messages for Changes to /usr/src/usr.bin/ftp/util.c of 18 and 20 | marc Jan do not mention it. So maybe somewhere else to look? | | Several applications which support both IPv4 and IPv6, such as | telnet/ftp, has used getaddrinfo() for resolving hostnames. | | If IPv4 dotted-decimal forms are given, getaddrinfo() calls finally | inet_pton(). inet_pton() is defined in RFC2553 and it does not permit | non-standard IPv4 dotted-decimal, such as 10.10 | | Do people have troubles with this change? | | Yoshinobu Inoue | | | To Unsubscribe: send mail to [EMAIL PROTECTED] | with "unsubscribe freebsd-current" in the body of the message | -- Eugene M. Kim [EMAIL PROTECTED] "Is your music unpopular? Make it popular; make music which people like, or make people who like your music." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Pre-3.3 to 4.0 w/ IPsec
Just wanted to share the knowledge of this little devil. For those who want to upgrade via cvsup their pre-3.3 system to test IPsec: due to the addition of src-sys-crypto in secure-supfile, one will have to cvsup first, upgrade their /usr/share/examples directory (cd /usr/src/share/examples ; make depend all install) and cvsup again before they can compile a kernel with IPsec. Regards, Eugene PS. Could this be a candidate for UPDATING? -- Eugene M. Kim [EMAIL PROTECTED] "Is your music unpopular? Make it popular; make music which people like, or make people who like your music." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Installing to a differnet root?
The following should do it: cd /usr/src make installworld DESTDIR=/remotefs cd /usr/src/etc make distrib-dirs distribution DESTDIR=/remotefs Regards, Eugene On Sat, 22 Jan 2000, Rod Taylor wrote: | I've briefly read various documents, and haven't discovered a way to | installworld to a different path than /. | | In particular, I'd like to install to /remotefs/. | | I've got tftp, bootp, etc. all setup and ready to go but would like a clean | 'world' to modify as opposed to a pre-existing one. | | Thanks! -- Eugene M. Kim [EMAIL PROTECTED] "Is your music unpopular? Make it popular; make music which people like, or make people who like your music." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: config tool breaks
Recently there has been a change in config directory layout (all *.i386 files has been moved from /sys/i386/conf to /sys/conf), so you have to rebuild /usr/sbin/config first. HTH, Eugene PS. PACBELLThe Handbook is, once again, your friend :-)/PACBELL. On Tue, 11 Jan 2000, Forrest Aldrich wrote: | Is this a bug, or did I miss something on the list | that changed this procedure: | | | cd /usr/src/sys/i386/conf) | | bash-2.03# config MYMACHINE | config: files.i386: No such file or directory | bash-2.03# exit | | The files.* is missing, etc. No changes after a cvsup. | | | | _F | | | To Unsubscribe: send mail to [EMAIL PROTECTED] | with "unsubscribe freebsd-current" in the body of the message | -- Eugene M. Kim [EMAIL PROTECTED] "Is your music unpopular? Make it popular; make music which people like, or make people who like your music." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: IPv6 testing...willing to help
On Sat, 8 Jan 2000, Yoshinobu Inoue wrote: | I have a DEC Alpha at home running 4.0-current and am willing to help out with | the testing. I am not the worlds greatest coder, but am willing to do what I can | | Thanks! | | The 1st thing I want to be tested is that, a kernel with | following additions to the config file | | options INET6 #IPv6 communications protocols | options IPSEC #IP security | options IPSEC_ESP #IP security (crypto; define w/ IPSEC) | options IPSEC_IPV6FWD #IP security tunnel for IPv6 | options IPSEC_DEBUG #debug for IP security | | pseudo-device gif 4 #IPv6 and IPv4 tunneling | pseudo-device faith 1 #for IPv6 and IPv4 translation | | just works fine, | and also all apps on your environments which you are usually | using still works fine on that kernel. I've done this this morning and found that all of a sudden natd and related stuff stopped working; it leads to a kernel panic whenever a machine inside natd tries to access the Internet. IIRC, the kernel option IPDIVERT was documented to be incompatible in KAME LINT; maybe this should be documented in our LINT as well? For now, I've reverted to my previous kernel (because my mom would get upset if the Internet gets inaccessible from her Win98 box), but if you give further direction, I can do some testing while she's off the computer. :-) Thank you, Eugene -- Eugene M. Kim [EMAIL PROTECTED] "Is your music unpopular? Make it popular; make music which people like, or make people who like your music." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: breakage in this morning's build
AOLMe too!/AOL Mine goes like: cc -O6 -m486 -pipe -Wall -Wall -Wformat -I/usr/obj/pubfs/1/root/world/src/tmp/usr/include -static -o rm rm.o stat_flags.o install -c -s -o root -g wheel -m 555 rm /usr/obj/pubfs/1/root/world/src/tmp/bin rm: /usr/obj/pubfs/1/root/world/src/bin/rm: Operation not supported by device *** Error code 1 Stop in /pubfs/1/root/world/src/bin/rm. *** Error code 1 Cheers, Eugene On Mon, 30 Aug 1999, Mike Muir wrote: | Pascal Hofstee wrote: | | I am suffering from the exact same problem here as well ... (tried about 4 | times now ... without success) | | Mines a little (little) different: | | install -c -s -o root -g wheel -m 555 mv /usr/obj/usr/src/tmp/bin | /usr/obj/usr/src/bin/mv created for /usr/src/bin/mv | cd /usr/src/bin/rm; /usr/obj/usr/src/tmp/usr/bin/make -DWORLD -DNOINFO | -DNOMAN -DNOPIC -DNOPROFILE -DNOSHARED -D_BUILD_TOOLS cleandepend; | /usr/obj/usr/src/tmp/usr/bin/make -DWORLD -DNOINFO -DNOMAN -DNOPIC | -DNOPROFILE -DNOSHARED -D_BUILD_TOOLS all; | /usr/obj/usr/src/tmp/usr/bin/make -DWORLD -DNOINFO -DNOMAN -DNOPIC | -DNOPROFILE -DNOSHARED -D_BUILD_TOOLS -B install cleandir obj | rm -f .depend /usr/obj/usr/src/bin/rm/GPATH | /usr/obj/usr/src/bin/rm/GRTAGS /usr/obj/usr/src/bin/rm/GSYMS | /usr/obj/usr/src/bin/rm/GTAGS | cc -O -pipe -Wall -Wformat -I/usr/obj/usr/src/tmp/usr/include -c | /usr/src/bin/rm/rm.c | cc -O -pipe -Wall -Wformat -I/usr/obj/usr/src/tmp/usr/include -c | /usr/src/bin/rm/../ls/stat_flags.c | cc -O -pipe -Wall -Wformat -I/usr/obj/usr/src/tmp/usr/include -static | -o rm rm.o stat_flags.o | install -c -s -o root -g wheel -m 555 rm /usr/obj/usr/src/tmp/bin | rm: /usr/obj/usr/src/bin/rm: Inappropriate ioctl for device | *** Error code 1 | | Stop in /usr/src/bin/rm. | *** Error code 1 | | | To Unsubscribe: send mail to [EMAIL PROTECTED] | with "unsubscribe freebsd-current" in the body of the message | -- Eugene M. Kim [EMAIL PROTECTED] "Is your music unpopular? Make it popular; make music which people like, or make people who like your music." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
