Re: followup to apm problems.
Kazutaka YOKOTA wrote: > The PS/2 mouse generates interrupt when /dev/psm0 is open and > the user moves the mouse. > > If you are running moused or X when you suspend the system, /dev/psm0 > is left open and might generate interrupts. I think modern motherboard > BIOSes have a setup menu that lists which IRQ will wake up the system. > > I wonder what if you remove IRQ 12 (PS/2 mouse interrupt) from this list. Disabling it on the BIOS list of timer interrupts stops the movement of the mouse from ejecting you from a Standby or Suspend. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: followup to apm problems.
>> OK. Probably `slept 00:00:00 - 00:00:40' problem was caused by PS/2 >> mouse, I think. Do we need something to do with psm on suspending as >> well as resuming? > >Im not sure anything needs to be done for PS/2.. check out these >results.. The PS/2 mouse generates interrupt when /dev/psm0 is open and the user moves the mouse. If you are running moused or X when you suspend the system, /dev/psm0 is left open and might generate interrupts. I think modern motherboard BIOSes have a setup menu that lists which IRQ will wake up the system. I wonder what if you remove IRQ 12 (PS/2 mouse interrupt) from this list. Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Built-in linker library search paths
Ever since we started using binutils with the move to elf we've been using linker scripts with library search paths. The genscripts.sh source from binutils is giving us at least one bogus path all the time, and the presence of a not-always-appropriate-path (/usr/lib) the rest of the time. I'd like to remove the search paths altogether, leaving the gcc LIB_SPEC and LD_LIBRARY_PATH environment variable to get the /right/ path all the time. Any objections? -- John Birrell - [EMAIL PROTECTED]; [EMAIL PROTECTED] http://www.cimlogic.com.au/ CIMlogic Pty Ltd, GPO Box 117A, Melbourne Vic 3001, Australia +61 418 353 137 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: followup to apm problems.
Mitsuru IWASAKI wrote: > OK. Probably `slept 00:00:00 - 00:00:40' problem was caused by PS/2 > mouse, I think. Do we need something to do with psm on suspending as > well as resuming? Im not sure anything needs to be done for PS/2.. check out these results.. > > > > ed1: irq 3 at device 9.0 on pci0 > Ahh, I meant just unplug cable tentatively to confirm. > # and uninstall NIC if possible :) > After the problem analyzed, we just try to fix it in proper place. Unplugged NIC, not diabled: Standby: Aug 29 18:33:44 pyros /kernel.old: APM ioctl: cmd = 0x2000500c Aug 29 18:36:28 pyros /kernel.old: Received APM Event: PMEV_STANDBYRESUME Aug 29 18:36:28 pyros /kernel.old: Execute APM hook "default resume." Aug 29 18:36:28 pyros /kernel.old: resumed from suspended mode (slept 00:02:42) Aug 29 18:36:28 pyros /kernel.old: Execute APM hook "PS/2 mouse." Aug 29 18:36:28 pyros /kernel.old: APM ioctl: cmd = 0x40284164 Aug 29 18:36:28 pyros /kernel.old: APM ioctl: cmd = 0x40284164 Aug 29 18:36:28 pyros apmd[355]: apmevent 000b index 3 Aug 29 18:36:28 pyros apmd: resumed at 19990829 18:36:28 Aug 29 18:36:28 pyros /kernel.old: APM ioctl: cmd = 0x40284164 And i pressed a key because i couldnt be biffed waiting any longer :) So it seems to be working properly! (Yes i am running apmd as well) Suspend: Aug 29 18:41:17 pyros /kernel.old: APM ioctl: cmd = 0x20005001 Aug 29 18:42:33 pyros /kernel.old: Execute APM hook "default suspend." Aug 29 18:42:33 pyros /kernel.old: Received APM Event: PMEV_NORMRESUME Aug 29 18:42:33 pyros /kernel.old: Execute APM hook "default resume." Aug 29 18:42:33 pyros /kernel.old: resumed from suspended mode (slept 00:01:15) Aug 29 18:42:33 pyros /kernel.old: Execute APM hook "PS/2 mouse." Aug 29 18:42:33 pyros /kernel.old: APM ioctl: cmd = 0x40284164 Aug 29 18:42:33 pyros /kernel.old: APM ioctl: cmd = 0x40284164 Aug 29 18:42:33 pyros apmd[355]: apmevent 0003 index 5 Aug 29 18:42:33 pyros apmd: resumed at 19990829 18:42:33 Aug 29 18:42:33 pyros /kernel.old: APM ioctl: cmd = 0x40284164 Same deal, I resumed it manually - so it seems to be working also. > At least, apm is in /usr/sbin/, apm -z touches /dev/apm and apmd > writes log on /var/log/ via syslog :) > Using `sysctl -w machdep.apm_suspend_delay=30 (or enough time for > spinning down)' and moving `camcontrol stop' to the end of command > list would be success. Otherwise, please forgive me. :) I tried that and the drive spins down, and right about 5 seconds before the 30 seconds is up, it spins back up again by itself, then it goes into suspend, but then comes right back out (presumably because of the disk activity). P.S plugging it back in, i do notice it resumes whenever there is activity on the hub :D To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
multipatch #6 available
I've resynced the source tree and updated my big-fat patch again. http://www.backplane.com/FreeBSD4/ This patch is the same as the last one, but: * should patch clean to the tree as of tonight * fixes an additional bug in swapblock management. Certain management functions were being run at splbio() that had to be run at splvm(). * Adds a new feature to VN - swap space pre-reservation, in addition to the two features already added (zeroing and file creation/truncation). The swap space prereservation option may be used when configuring VN with swap backing store. Swap will be preallocated for all blocks in the device and no on-the-fly reallocation will occur. This avoids swap fragmentation and even allows you to 'recover' swap-backed VN-based filesystems across reboots provided that you create them with the same sizes and order as before and swap has not been allocated for anything else prior to the vnconfigs. A full description is available on my site. This patch has been extensively tested, especially the VN device when used in swap-backed mode. -Matt Matthew Dillon <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
$FreeBSD-knowledgable mergemaster available
I have some other changes planned so I'm not going to re-roll the port yet, but between now and then I've put up a version of mergemaster that knows about the $FreeBSD tags at http://freebsd.simplenet.com/mergemaster-1.25. Enjoy, Doug To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: RealTek 8139 problems
>Under normal Circumstances, the communication is Ok between all three >machines, but sometimes the ethernet interface in the main machine >(the 8139) wedges up. I cannot ping any other host. The only solution >is taking the interface down and up again: It hangs when it gets an rx fifo overrun. The chance of an overrun can be modified by tweaking the fifo threshold and rx maxdma as in if_rlreg.h rev.1.9. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
rev 1.156 - fixes _qdivrem: division by zero panic
Poul-Henning fixed (without knowing) a bug in the fd driver (that must have sneaked in when changing something to do with dev_t's. revision 1.156 date: 1999/08/28 08:10:13; author: phk; state: Exp; lines: +4 -1 Initialize dev->si_bsize*, the floppy driver doesn't use dsopen(). The panic is _qdivrem: division by zero Hope this info is of use to anyone. Nick -- e-Mail: [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: "The Matrix" screensaver, v.0.2
"Mark S. Reichman" wrote: > > Another reason less lawsuits of this type are tried in Europe > is because the loser pays all court costs. > In the US a person will name everyone and anyone > remotely associated with the supposed wrong doing in hopes of a > big payoff. Each person must then hire a lawyer and defend > themselves against the compaint. In the states if you do > this and lose the court > case then usally no big deal. You are out your own attorney fees. > In europe if you lose you must pay everyones legal fees.. > This is known as "loser pays". This > tends to lessen the number of frivilous court cases, named > litigants, and lowers the burden on the european legal system. > Am I a lawyer? NO. I only saw a documentary on TV about this. > So take it for what its worth. > > Poul-Henning Kamp wrote: > > > > In message <8062.935743977@localhost>, "Jordan K. Hubbard" writes: > > >> > I seriously doubt they'll win this lawsuit. You can sue someone for > > >> > anything and everything, including having a hair color which > > >> > > >>^ in the States > > > > > >Sorry, I've lived in Europe, you can't pull that one on me. :) > > > > > >In Germany, for example, it's possible to sue someone simply for > > >sticking their finger against their forehead. The myth that only the > > >U.S. is litigious is just that, a myth. Europeans sue the crap out of > > >one another all the time, and for issues just as silly. :) > > > > Jordan, I've lived in the US, Luxembourg, Italy and Denmark. > > > > While it is true that anyone can sue anybody else for anything they > > feel like all over the planet, the likely (lack of) outcome in > > europe makes it far less likely that they will do so in the first > > place. > > > > The main difference as far as I can tell, is that European courts > > apply some kind of "common sense" criteria before they award huge > > compensations to people who burn themselves on coffee, cut their > > fingers off with chain saws and so on: "Should this person not > > be realizing that coffee could be hot ? She has been drinking > > coffee for the last 50+ years ?" "If you use a chainsaw, shouldn't > > you be smart enough to realize that you cannot stop the chain > > with your hand ?" etc etc. > > > > The secondary difference is that in all the countries I know, > > they lawyer has to state his fee before the verdict, and it > > may not depend on the outcome of the verdict. > > > > The third difference is that we only use jurys in murder cases, > > we fully realize the ability of a showman-laywer to sway a jury, > > therefore we don't use them, unless the issue is the gravest > > crime we know off. > > > > Fourth, "puntative damages" fall to the state over here, so the > > potential for getting rich that way is simply not present. > > > > So while you're technically correct reality looks far different. > > > > -- > > Poul-Henning Kamp FreeBSD coreteam member > > [EMAIL PROTECTED] "Real hackers run -current on their laptop." > > FreeBSD -- It will take a long time before progress goes too far! > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > > with "unsubscribe freebsd-current" in the body of the message > > -- > \|/ > (@ @) > +---oOO(_)---+ > | Mark S. Reichman | > | [EMAIL PROTECTED] | > | Radar Tech/Oracle Developer/Programmer | > +-oOO+ >|__|__| > || || >ooO Ooo -- \|/ (@ @) +---oOO(_)---+ | Mark S. Reichman | | [EMAIL PROTECTED] | | Radar Tech/Oracle Developer/Programmer | +-oOO+ |__|__| || || ooO Ooo To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Crypto updates coming!
> I haven't had much feedback on this code so would like to hear how well it > works for people. Unfortunately I can't correct any bugs at the moment > until I get my computer (which is at this moment being unloaded from a > plane at the airport :-) set up and back on the net, but I tested it a > fair bit myself back in Australia. It didn't work very well for me, because what I had had missing bits; also it did not fit into the framework I had already constructed. What will be there after the commit is IMVHO a good starting point for your code :-). M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Crypto updates coming!
On Sat, 28 Aug 1999, Doug wrote: > Something that came up recently, both for me and someone else on the list > is the ability to have DES libs in the system and still use MD5 passwords > as the default. I have no idea how difficult this would be to do, but if > someone has it in mind here's another vote in favor. The replacement libcrypt code at http://www.physics.adelaide.edu.au/~kkennawa/crypt-990725.tar.gz allows this (and more), the only major downside is that it doesn't allow statically-linked binaries to use external crypt() modules (blowfish, etc). Traditional-format MD5 and DES are built-in so should work fine when statically-linked. I haven't had much feedback on this code so would like to hear how well it works for people. Unfortunately I can't correct any bugs at the moment until I get my computer (which is at this moment being unloaded from a plane at the airport :-) set up and back on the net, but I tested it a fair bit myself back in Australia. Kris To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Crypto updates coming!
Mark Murray wrote: > > Hello All! > > I have got a $#|7load of crypto updates that I'd like to commit; they > are all over my tree, so let me describe what they do, and anyone who > wishes to review any part of them can get the appropriate bits. Something that came up recently, both for me and someone else on the list is the ability to have DES libs in the system and still use MD5 passwords as the default. I have no idea how difficult this would be to do, but if someone has it in mind here's another vote in favor. Meanwhile the upgrades sound good to me, for what that's worth. :) Thanks, Doug To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make buildworld failed...
On Fri, 27 Aug 1999, Nick Hibma wrote: >Let me guess, the kernel panic ends up in a division by zero error when >writing to floppy in _qdivrem. Yep, this would be it. On Sat, 28 Aug 1999, Brian F. Feldman wrote: >That sounds like it could have just been fixed by phk. If it's not that and >is the writing past the end of a block device issue, use the character >device instead. I'm afraid it's the latter problem. It crashes at line 414 of dd/conv.c, but I really don't see why. The arguments all look decent--it's only trying to write 512 bytes at a time, and everything looks just like it does during a character device write. I don't understand this area of the system well enough to do much useful debugging, but if anyone wants the particulars, this is 120% repeatable. -Adam Wight To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RealTek 8139 problems
Hi, I get some strange networking results with my RealTek 8139 card. I don't know how long these problems exist in the kernel, because they only showed up after some change in my network setup. I got a third PC for testing and now needed a hub to connect all my PCs together. I used to have an UTP x-over cable and this setup worked Ok. Now I hooked the 3 PCs together with an 10/100 MBit Hub. This is now my configuration: PC 1: RealTek 8139 PC 2: Intel EtherEpress Pro 100B PC 3: RealTek 8029(the new machine) PC 1 and PC 3 are running FreeBSD, PC 2 usually runs Windows 98, but I could also boot Solaris for testing. Under normal Circumstances, the communication is Ok between all three machines, but sometimes the ethernet interface in the main machine (the 8139) wedges up. I cannot ping any other host. The only solution is taking the interface down and up again: ifconfig rl0 down; ifconfig rl0 up Enabling/disabling promiscuous mode also seems to help. I first thought it was a faulty hub, so I hooked up two PCs (RealTek 8139 + RealTek 8029) with the Xover cable again. But the problem persists. So the Hub seems to be Ok. There seem also to be plenty of mbufs available. netstat -m: 64/3808 mbufs in use: 56 mbufs allocated to data 8 mbufs allocated to packet headers 1/48/512 mbuf clusters in use (current/peak/max) 572 Kbytes allocated to network (1% in use) 0 requests for memory denied 0 requests for memory delayed 0 calls to protocol drain routines I finally managed to easily reproduce the behaviour. Just run two flood pings to the same machine at once. Interesting, that I have to flood ping PC 3 (10BaseT) to wedge up the machine. If I ping PC 2, nothing spectacular happens. The Driver does proper autonegotiation, but also changing the media manually to the correct values (media 100baseTX mediaopt half-duplex) doesn't help. Thanks for any hints. Daniel Some comments to the dmesg output below: I have disabled the secondary serial port, so every device should get its own IRQ. Copyright (c) 1992-1999 The FreeBSD Project. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 4.0-CURRENT #316: Tue Aug 24 23:58:54 CEST 1999 root@server:/usr/src/sys/compile/ROCK Timecounter "i8254" frequency 1193182 Hz CPU: AMD-K6(tm) 3D processor (300.68-MHz 586-class CPU) Origin = "AuthenticAMD" Id = 0x580 Stepping = 0 Features=0x8001bf AMD Features=0x8800 real memory = 134152192 (131008K bytes) avail memory = 126906368 (123932K bytes) Preloaded elf kernel "kernel" at 0xc0316000. VESA: v2.0, 8192k memory, flags:0x1, mode table:0xc02bed22 (122) VESA: Matrox Graphics Inc. npx0: on motherboard npx0: INT 16 interface apm0: on motherboard apm: found APM BIOS v1.2, connected at v1.2 pcib0: on motherboard pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 vga-pci0: irq 11 at device 0.0 on pci1 isab0: at device 7.0 on pci0 isa0: on isab0 ncr0: irq 11 at device 8.0 on pci0 pci0: unknown card DPZ0002 (vendor=0x121a, dev=0x0002) at 9.0 rl0: irq 3 at device 10.0 on pci0 rl0: Ethernet address: 00:e0:7d:02:8b:39 rl0: autoneg complete, link status good (half-duplex, 100Mbps) ata-pci0: irq 0 at device 15.0 on pci0 ata-pci0: Busmastering DMA supported ata0 at 0x01f0 irq 14 on ata-pci0 ata1 at 0x0170 irq 15 on ata-pci0 Probing for PnP devices: atkbdc0: at port 0x60-0x6f on isa0 atkbd0: irq 1 on atkbdc0 psm0: irq 12 on atkbdc0 psm0: model Generic PS/2 mouse, device ID 0 vga0: at port 0x3b0-0x3df iomem 0xa-0xb on isa0 sc0: on isa0 sc0: VGA <16 virtual consoles, flags=0x200> fdc0: at port 0x3f0-0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sb0 at port 0x220 irq 5 drq 1 on isa0 snd0: sbxvi0 at port 0x drq 5 on isa0 isa_compat: didn't get ports for sbxvi snd0: WARNING: "snd" is usurping "snd"'s cdevsw[] sbmidi0 at port 0x330 on isa0 snd0: WARNING: "snd" is usurping "snd"'s cdevsw[] awe0 at port 0x620 on isa0 awe0: WARNING: "snd" is usurping "snd"'s cdevsw[] opl0 at port 0x388 on isa0 snd0: WARNING: "snd" is usurping "snd"'s cdevsw[] isic0 at port 0x340 irq 10 flags 0x4 on isa0 isic0: AVM A1 or AVM Fritz!Card isic0: ISAC 2085 Version A1/A2 or 2086/2186 Version 1.1 (IOM-2) (Addr=0x1720) isic0: HSCX 82525 or 21525 Version 2.1 (AddrA=0x720, AddrB=0xf20) ppc0 at port 0x378-0x37f irq 7 drq 3 on isa0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/1 bytes threshold lpt0: on ppbus 0 lpt0: Interrupt-driven port ppi0: on ppbus 0 IP packet filtering initialized, divert enabled, rule-based forwarding disabled, default to accept, unlimited logging DUMMYNET initialized (990811) i4b: ISDN call control device attached i4bisppp: 1 ISDN SyncPPP device(s) attached i4bctl: ISDN system control port attached i4btel: 1
Re: Crypto updates coming!
> On Sat, 28 Aug 1999, Mark Murray wrote: > > > 3) Upgade libdes. This is mainly for KerberosIV and Kerberos5. It does > > not hurt anything else. This will go into src/crypto. > > You might also like to turn on the x86 assembler code (it's only for > pentiums, I think, so would have to be a non-default option :-(. It gives > a performance increase of a factor of 3 or so, ISTR. I'll bring in that code, but only enable it later. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Crypto updates coming!
On Sat, 28 Aug 1999, Mark Murray wrote: > 3) Upgade libdes. This is mainly for KerberosIV and Kerberos5. It does > not hurt anything else. This will go into src/crypto. You might also like to turn on the x86 assembler code (it's only for pentiums, I think, so would have to be a non-default option :-(. It gives a performance increase of a factor of 3 or so, ISTR. Kris To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PC98/GENERIC98 compile problem
Poul-Henning Kamp <[EMAIL PROTECTED]> wrote: > schizo# make > 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/usr/include -DKERNEL -include opt_global.h -elf >../../pci/if_tl.c > ../../pci/if_tl.c:226: miibus_if.h: No such file or directory > *** Error code 1 Fixed. Thanks! ---+--+ KATO Takenori <[EMAIL PROTECTED]> |FreeBSD | Dept. Earth Planet. Sci, Nagoya Univ. |The power to serve! | Nagoya, 464-8602, Japan| http://www.FreeBSD.org/ | FreeBSD(98) 3.2: Rev. 01 available! |http://www.jp.FreeBSD.org/| FreeBSD(98) 2.2.8: Rev. 02 available! +==+ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
PC98/GENERIC98 compile problem
schizo# make 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/usr/include -DKERNEL -include opt_global.h -elf ../../pci/if_tl.c ../../pci/if_tl.c:226: miibus_if.h: No such file or directory *** Error code 1 -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Docs blows up make release
Jordan, Satoshi, Just a reminder: I have *no* objection to the ports tree being used to build packages of the documentation, as long as the maintenance of those ports is assigned to individuals, and not the FDP (and, more specifically, me). However, I think that another mechanism, one that's wholly within doc/, will be useful, for the reasons I've already outlined. On Thu, Aug 26, 1999 at 06:46:38PM -0700, Satoshi - Ports Wraith - Asami wrote: > Another advantage of having them in the ports tree is the build > checking done at regular intervals. OK. But since the doc/ packages will also be being built daily (first on freefall, and then, when I get the time, on the docs.freebsd.org machine (usw1?) that jkh has been talking about, the same comment applies. > All the japanese/handbook stuff > that's going on right now, these are the problems of the > textproc/docbook* ports (missing files from PLIST, missing > dependencies). People installing these from packages will see the > exact same problem when they try to build the handbook (with or > without the japanese/handbook port). Hang on a second. Are we talking about different things here? I want the formatted documentation available as packages so that those people that want formatted docs, but who have neither the time, the inclination, or the machine horsepower to download the textproc/docproj port have a very easy way of installing and managing formatted documentation -- specifically, pkg_add(1). If people want to go and build the documentation from scratch themselves, they should do so by downloading the doc/ repository, and running make(1) in there, not by going through the ports system. That just adds an additional layer of complexity. [ Obviously, people will have to go through the ports system to download the applications they are using to build the docs, or go through the hassle of configuring and installing them themselves ] > * > Putting the package building rules in the doc/ Makefiles also (and this > * > is just my personal opinion) makes it easier for people to see how the > * > documentation packages are built. The ports Makefile structure is a > * > marvel, but it contains a lot of code that's not necessary for building > * > documentation packages (the "automagically add man pages to the PLIST > * > i" code, for example) that makes it more difficult for the interested > * > learner to browse and understand what's going on. > * > * Now this is a point which is more germin. So, you figure on making a > * similar sort of "package" target under doc? I guess it really doesn't > * matter where these things live, as long as it's still automated.. > > The chief concern I have is that this might result in yet another > place you (Jordan) have to pick up stuff from before the release. This shouldn't matter, should it? As long as the automated doc package building puts the files somewhere sensible (in distfiles/ on wcarchive?) it'll get picked up. Remember that the long term plan is to migrate the docs out of the release as a separate distribution, and in to their own packages, so that at sysinstall time the user can pick and choose which docs to install at the level of the individual packages (presumably, with some additional 'meta' choices, that let them say things like "All the English docs, in HTML and PDF, and the Spanish docs in HTML"). Since this (the package building, and sysinstall changes) are not going to be ready for 3.3-RELEASE, I think we should concentrate on ensuring that "make release" works with the new doc/ structure, and that sysinstall knows about the correct locations of the FAQ and Handbook in the new structure. In the meantime, I can continue adding and tweaking (with input from anybody else that's interested) the package building rules under doc/, and then set up a system that automatic builds formatted versions of the latest documentation daily (or weekly, depending on how rapidly the documentation is changing, and how badly people want it). We can then run with this for a bit, see how it works out, and that gives us plenty of time to consider removing the doc distribution (in favour of the packages) in time for 4.0-RELEASE. The ports tree can continue having a japanese/handbook entry for as long as they want. As long as I don't have to support it, I don't care :-) N -- [intentional self-reference] can be easily accommodated using a blessed, non-self-referential dummy head-node whose own object destructor severs the links. -- Tom Christiansen in <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Crypto updates coming!
Hello All! I have got a $#|7load of crypto updates that I'd like to commit; they are all over my tree, so let me describe what they do, and anyone who wishes to review any part of them can get the appropriate bits. 1) Revisit the way libscrypt/libdescript get built. This is partially based on Brandon Gillespie's work, and is also inspired by what Kris Kennaway is trying to do, although it contains very little of their work. It is more a framework change to ease future expansion and to clean up the area. I am trying to reduce the size of the unexportable areas as well. 2) Upgrade compile_et to the latest offering from KTH in Sweden. This is needed for the new KerberosIV/eBones and Kerberos5/Heimdal. This will go into src/contrib. This code is radically different from MIT compile_et, but compatible with it. 3) Upgade libdes. This is mainly for KerberosIV and Kerberos5. It does not hurt anything else. This will go into src/crypto. 4) Upgrade our KerberosIV to KTH's latest offering (1.0pre5). 5) Various fixes to ease the import of Kerberos5/Heimdal when the compatible version is released. Kerberos5 will be in a directory structure analagous to the current kerberosIV. Producing complete diffs may be a bit of a pain, but I can come up with any part of the above without too much of a hassle. M To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make buildworld failed...
On Fri, 27 Aug 1999, Adam Wight wrote: > > > dd if=/dev/zero of=boot2.ldr bs=512 count=1 2>/dev/null > > > *** Error code 1 > > > Probably it consequences of recent dd changes... Sorry about that! Instead of relying on the kernel being newer than the world and haveing the new ioctl FIODTYPE, dd now only warns if the ioctl doesn't work. > > So I'm not entirely alone, then. I actually kernel panic quite reliably every > time I try to dd onto a floppy. I can dd from one file to another without > a problem, and floppy access in general works as always. > > What debugging information would be relevant? That sounds like it could have just been fixed by phk. If it's not that and is the writing past the end of a block device issue, use the character device instead. > > -adam > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message > -- Brian Fundakowski Feldman / "Any sufficiently advanced bug is\ [EMAIL PROTECTED] | indistinguishable from a feature." | FreeBSD: The Power to Serve!\-- Rich Kulawiec / To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make buildworld failed...
Let me guess, the kernel panic ends up in a division by zero error when writing to floppy in _qdivrem. Haven't had time to script that panic, but will do next week. Nick On Fri, 27 Aug 1999, Adam Wight wrote: > > > dd if=/dev/zero of=boot2.ldr bs=512 count=1 2>/dev/null > > > *** Error code 1 > > > Probably it consequences of recent dd changes... > > So I'm not entirely alone, then. I actually kernel panic quite reliably every > time I try to dd onto a floppy. I can dd from one file to another without > a problem, and floppy access in general works as always. > > What debugging information would be relevant? > > -adam > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message > > -- e-Mail: [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
