Re: sysinstall rc.conf
On Sun, Feb 14, 1999 at 07:14:26AM +0100, Leif Neland wrote: On Sat, 13 Feb 1999, Jordan K. Hubbard wrote: until I realized that /etc/rc.conf was empty. It's the anti-POLA! ;) That's POMA :) Could somebody tell me the meaning of those acronyms? POLA - Policy? Of Least Astonishment POMA - Most (seems jkh just made this one up :-) anyway, the intent should be clear now. -- Zach Heilig z...@uffdaonline.net / Zach Heilig z...@gaffaneys.com Americans are sensitive about their money, and since this was the first major change in the greenback in nearly 70 years, a radical redesign might have been too much for consumers to comprehend -- John Iddings [COINage, Feb. 1999]. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: New print interface
On Sat, Feb 13, 1999 at 10:03:41PM -0500, Chuck Robey wrote: I have to add an addendum here, to my previous question about the new config file setup for a simple printer. I was looking forward to seeing the probing come back to my dmesg, when I finally got it right, but seeing this: Feb 13 14:02:01 picnic /kernel: ppc0 at 0x378 irq 7 on isa Feb 13 14:02:01 picnic /kernel: ppc0: SMC FDC37C665GT chipset (EPP/PS2/NIBBLE) in COMPATIBLE mode Feb 13 14:02:01 picnic /kernel: ppb0: IEEE1284 device found /NIBBLE/ECP Feb 13 14:02:01 picnic /kernel: Probing for PnP devices on ppbus0: Feb 13 14:02:01 picnic /kernel: ppbus0: HEWLETT-PACKARD DESKJET 690C MLC,PCL,PML Feb 13 14:02:01 picnic /kernel: nlpt0: generic printer on ppbus 0 Feb 13 14:02:01 picnic /kernel: nlpt0: Interrupt-driven port I *never* expected to see the PNP functions actually pick up the name of my printer. I was economically bushwacked by the Windows corps into buying the 693C (the version with the Windows software floppies tacked on) so I was actually pleased that it ID'd the printer as the more generic 690C (sans the Windows extortia). Very nice. The mistake I'd made earlier was in not knowing that the config needed all 3 lines, not just some subset of 2 of them as I'd guessed. Great job, Nicolas! Not finished. ECP is not supported yet. I'm glad to see the 690C is ECP compliant. I bougth an HP6L, thinking it was :( But there's at least FIFO+DMA support in the nlpt driver. Try 'lptcontrol -e' with you BIOS configured to ECP. Recompile with the appropriate drq on the 'device ppc at isa?...' line. +--- Chuck Robey | Interests include any kind of voice or data chu...@glue.umd.edu | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run picnic (FreeBSD-current) (301) 220-2114 | and jaunt (Solaris7). +--- -- nso...@teaser.fr / nso...@freebsd.org FreeBSD - Turning PCs into workstations - http://www.FreeBSD.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: lpt0
On Sat, Feb 13, 1999 at 08:04:12PM +0100, Dag-Erling Smorgrav wrote: Nicolas Souchu nso...@teaser.fr writes: controller ppbus0 # The ppbus system device nlpt0 at ppbus? # The printer driver OBTW, when are you planning to rename nlpt0 to lpt0? Today. DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no -- nso...@teaser.fr / nso...@freebsd.org FreeBSD - Turning PCs into workstations - http://www.FreeBSD.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Aladdin chipset SMBus support available!
On Sat, Feb 13, 1999 at 05:22:00PM -0500, Brian Feldman wrote: On Sat, 13 Feb 1999, Nicolas Souchu wrote: Hi folks, I've just committed the alpm(4) driver to -current: the Aladdin SMBus driver. Great, my newest mobo is an AcerLabs. With an onboard system management chip (lm7x or w87381), it offers monitoring capabilities to recent Acer based motherboards like the ASUS P5AB. I'm using a matsonic. Example program to fetch temperature or voltages is available at http://www.planet.sci.kobe-u.ac.jp/~takawata/smbus/examples/ There's also an example program to fetch SDRAM info over the smbus. I attach you the detect.c program. It's very simple and may help us in knowing what I2C hardware you have on your mobo. I tried them, and there's the problem: all the ioctl()s they perform return EINTR! Has this driver been tested on many motherboards? Why should I expect an EINTR? Just wondering :) EINTR is odd. It just mean that the device at the address requested on the I2C bus do not respond. I have to translate SMBus errors to the appropriate unix ones. You may also want to know what smbus(4) is: http://www.freebsd.org/~nsouch/iicbus.html Feedbacks are wellcome. Nicholas. PS: A driver is also available for the Intel PIIX4, see intpm(4). -- nso...@teaser.fr / nso...@freebsd.org FreeBSD - Turning PCs into workstations - http://www.FreeBSD.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message Brian Feldman _ __ ___ ___ ___ gr...@unixhelp.org _ __ ___ | _ ) __| \ http://www.freebsd.org/ _ __ ___ | _ \__ \ |) | FreeBSD: The Power to Serve! _ __ ___ _ |___/___/___/ -- nso...@teaser.fr / nso...@freebsd.org FreeBSD - Turning PCs into workstations - http://www.FreeBSD.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Disk locks and weird things
Recently I've been trying to upgrade an early januarrry -current to current -current. I've rebuilt the kernel several times over the last few days (with new cvsup's) so i've eliminated any freak check-in mismatches. During a make world (usually about 10-20 minutes in on my P100) everything just comes to a grinding halt. No disk activity, but the screen saver will kick in (despite the shell being in the middle of said make world). If I switch to any alternate consoles and try to do anything, even an ls, it accesses the disk for a brief second, then hangs as well. Other tasks that don't need to access the disk keep running (such as natd and obviously the screen saver). After waiting about a half hour, I hit the reset and get lots of UNREF FILE's and SUMMARY INFORMATION BAD and BLK(S) MISSING IN BIT MAPS. They all say slavaged or cleared. It doesn't appear to be a problem with the actual disk, since rebooting works fine until I try and build again. Even building the kernel works fine. but doing a make world does not (I don't know if anything else causes this). It never fails in the same place twice either, but it's always the same effect. Additionally, i've been getting No such user 'tty', service ignored messages from ntalk and comsat. I'm sure these services were updated to make use of some tty user or something, but i'd like to know what exactly I should do here. I'm also getting messages from de0 and lo0 that say: de0 XXX: driver didn't set ifq_maxlen Finally, if I try and run top i get: top: cannot read swaplist: kvm_read: Bad address kvm_open: proc size mismatch (11392 total, 680 chunks) top: Out of memory. I assume this is from a newer kernel with older support files (such as top) but since I can't get world to build, I'm kinda stuck.. One more thing. I figured I might try a complete reinstallation so I tried to download the 4.0-snap of 2-11 and was able to successfully create a kern.flp but when I tried to create mfsroot.flp it seems to sit in a loop forever just moving the disk head back and forth. I tried it with several floppies (including the one I was able to successfully create kern.flp on) with the same results. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: lpt0 Not Found
On Sat, 13 Feb 1999, Thomas Dean wrote: I changed to the new nlpt. No luck. It appears that the parallel port is not found. I am running SMP-current, as of this afternoon. From uname -a: ... FreeBSD 4.0-CURRENT #0: Sat Feb 13 16:11:56 PST 1999 In my config, I changed to include ppbus0, nlpt0, and ppc0, exactly as in LINT: snip # Parallel-Port Bus # nlpt Parallel Printer controller ppbus0 # devicelpt0at isa? port? tty irq 7 vector lptintr controller ppc0at isa? disable port ? tty irq 7 device nlpt0 at ppbus? snip Take out the 'disable' from the ppc0 line. Thats got me a few times too :-). -- Doug Rabson Mail: d...@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Disk locks and weird things
I'm getting something similar. I thought it was my mainboard, as the one I currently have has some other problems (doesn't take the Nvidia TNT card) During heavy disk i/o the system freezes up for about 10 seconds or so, and then things continue. I'm getting these messages: wd0: interrupt timeout (status 50rdy,seekdone error 1no_dam) wd0: wdtimeout() DMA status 1active wd0: interrupt timeout (status 50rdy,seekdone error 1no_dam) wd0: wdtimeout() DMA status 1active wd0: Last time I say: interrupt timeout. Probably a portable PC. (status 50rdy,seekdone error 1no_dam) wd0: wdtimeout() DMA status 1active This is what gets probed: Feb 11 08:18:34 p /kernel: wdc0 at 0x1f0-0x1f7 irq 14 flags 0xa0ffa0ff on isa Feb 11 08:18:34 p /kernel: wdc0: unit 0 (wd0): QUANTUM BIGFOOT_CY4320A, DMA, 32-bit, multi-block-16 Feb 11 08:18:34 p /kernel: wd0: 4134MB (8467200 sectors), 8960 cyls, 15 heads, 63 S/T, 512 B/S Feb 11 08:18:34 p /kernel: wdc0: unit 1 (wd1): QUANTUM FIREBALL ST4.3A, DMA, 32-bit, multi-block-16 Feb 11 08:18:34 p /kernel: wd1: 4110MB (8418816 sectors), 14848 cyls, 9 heads, 63 S/T, 512 B/S Feb 11 08:18:34 p /kernel: wdc1 at 0x170-0x177 irq 15 flags 0xa0ffa0ff on isa Feb 11 08:18:34 p /kernel: wdc1: unit 0 (atapi): IOMEGA ZIP 100 ATAPI/23.D, removable, intr, iordis Feb 11 08:18:34 p /kernel: wfd0: medium type unknown (no disk) Feb 11 08:18:34 p /kernel: wfd0: buggy Zip drive, 64-block transfer limit set Feb 11 08:18:34 p /kernel: wdc1: unit 1 (atapi): LTN301/ML25, removable, intr, dma, iordis Alex Erik Funkenbusch wrote: Recently I've been trying to upgrade an early januarrry -current to current -current. I've rebuilt the kernel several times over the last few days (with new cvsup's) so i've eliminated any freak check-in mismatches. During a make world (usually about 10-20 minutes in on my P100) everything just comes to a grinding halt. No disk activity, but the screen saver will kick in (despite the shell being in the middle of said make world). If I switch to any alternate consoles and try to do anything, even an ls, it accesses the disk for a brief second, then hangs as well. Other tasks that don't need to access the disk keep running (such as natd and obviously the screen saver). After waiting about a half hour, I hit the reset and get lots of UNREF FILE's and SUMMARY INFORMATION BAD and BLK(S) MISSING IN BIT MAPS. They all say slavaged or cleared. It doesn't appear to be a problem with the actual disk, since rebooting works fine until I try and build again. Even building the kernel works fine. but doing a make world does not (I don't know if anything else causes this). It never fails in the same place twice either, but it's always the same effect. Additionally, i've been getting No such user 'tty', service ignored messages from ntalk and comsat. I'm sure these services were updated to make use of some tty user or something, but i'd like to know what exactly I should do here. I'm also getting messages from de0 and lo0 that say: de0 XXX: driver didn't set ifq_maxlen Finally, if I try and run top i get: top: cannot read swaplist: kvm_read: Bad address kvm_open: proc size mismatch (11392 total, 680 chunks) top: Out of memory. I assume this is from a newer kernel with older support files (such as top) but since I can't get world to build, I'm kinda stuck.. One more thing. I figured I might try a complete reinstallation so I tried to download the 4.0-snap of 2-11 and was able to successfully create a kern.flp but when I tried to create mfsroot.flp it seems to sit in a loop forever just moving the disk head back and forth. I tried it with several floppies (including the one I was able to successfully create kern.flp on) with the same results. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message -- Ik zit op m'n kromme, akelige broertje te wachten. Die heeft zich opgesloten in de server ruimte, en die weigert eruit te komen. - Bart To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Aladdin chipset SMBus support available!
I had the same problem with a non Aladin system. I believe the problem is that Takanori's examples no longer work since changes were made to pcisupport.c. Why do I say this ? Because Takanori said so in email to me. I dont understand how it all works but if I show you Takanori's comments maybe you guys will. START Takanori's comments === Commited code on pcisupport.c from 1.88 to 1.89 will break it. If intpm.h is not included,chipset probe code is used instead of the driver probe code. P.S I have forgotten to enclose unused variable in #undef ENABLE_ALART with #ifdef ENABLE_ALART - #endif ,so the variable may deleted when it was commited. And currently ENABLE_ALART code will not work properly. END Takanori's comments == On Sun, 14 Feb 1999, Nicolas Souchu wrote: On Sat, Feb 13, 1999 at 05:22:00PM -0500, Brian Feldman wrote: On Sat, 13 Feb 1999, Nicolas Souchu wrote: Hi folks, I've just committed the alpm(4) driver to -current: the Aladdin SMBus driver. Great, my newest mobo is an AcerLabs. With an onboard system management chip (lm7x or w87381), it offers monitoring capabilities to recent Acer based motherboards like the ASUS P5AB. I'm using a matsonic. Example program to fetch temperature or voltages is available at http://www.planet.sci.kobe-u.ac.jp/~takawata/smbus/examples/ There's also an example program to fetch SDRAM info over the smbus. I attach you the detect.c program. It's very simple and may help us in knowing what I2C hardware you have on your mobo. I tried them, and there's the problem: all the ioctl()s they perform return EINTR! Has this driver been tested on many motherboards? Why should I expect an EINTR? Just wondering :) EINTR is odd. It just mean that the device at the address requested on the I2C bus do not respond. I have to translate SMBus errors to the appropriate unix ones. You may also want to know what smbus(4) is: http://www.freebsd.org/~nsouch/iicbus.html Feedbacks are wellcome. Nicholas. PS: A driver is also available for the Intel PIIX4, see intpm(4). -- nso...@teaser.fr / nso...@freebsd.org FreeBSD - Turning PCs into workstations - http://www.FreeBSD.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message Brian Feldman _ __ ___ ___ ___ gr...@unixhelp.org_ __ ___ | _ ) __| \ http://www.freebsd.org/ _ __ ___ | _ \__ \ |) | FreeBSD: The Power to Serve! _ __ ___ _ |___/___/___/ -- nso...@teaser.fr / nso...@freebsd.org FreeBSD - Turning PCs into workstations - http://www.FreeBSD.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message /=\ |Work: matthew.th...@dsto.defence.gov.au | Home: thy...@camtech.net.au| \=/ If it is true that our Universe has a zero net value for all conserved quantities, then it may simply be a fluctuation of the vacuum of some larger space in which our Universe is imbedded. In answer to the question of why it happened, I offer the modest proposal that our Universe is simply one of those things which happen from time to time. E. P. Tryon from Nature Vol.246 Dec.14, 1973 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: lpt0
Date: Sat, 13 Feb 1999 19:17:14 +0100 From: Nicolas Souchu nso...@teaser.fr You need: controllerppbus0 # The ppbus system devicenlpt0 at ppbus? # The printer driver And finally the parallel port chipset interface, controllerppc0at isa? port? tty irq 7 drq 3 See ppbus(4) and/or http://www.freebsd.org/~nsouch/ppbus.html for more info about the ppbus architecture. how much information about this should be included in /usr/src/UPDATING? the entry there talks about the change but does not provide enough information to successfully upgrade (ppc0 is not mentioned, nor does it provide a pointer to where to go for more information.) ;( jmb To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Aladdin chipset SMBus support available!
On Sun, 14 Feb 1999, Nicolas Souchu wrote: On Sat, Feb 13, 1999 at 05:22:00PM -0500, Brian Feldman wrote: On Sat, 13 Feb 1999, Nicolas Souchu wrote: Example program to fetch temperature or voltages is available at http://www.planet.sci.kobe-u.ac.jp/~takawata/smbus/examples/ There's also an example program to fetch SDRAM info over the smbus. I attach you the detect.c program. It's very simple and may help us in knowing what I2C hardware you have on your mobo. Where's my detect.c? I think you forgot to attach it :) I tried them, and there's the problem: all the ioctl()s they perform return EINTR! Has this driver been tested on many motherboards? Why should I expect an EINTR? Just wondering :) EINTR is odd. It just mean that the device at the address requested on the I2C bus do not respond. I have to translate SMBus errors to the appropriate unix ones. Hmm... wouldn't the appropriate error for something not responding be an ENXIO or ETIMEDOUT? EINTR seems more than a little wrong for this purpouse. -- nso...@teaser.fr / nso...@freebsd.org FreeBSD - Turning PCs into workstations - http://www.FreeBSD.org Brian Feldman_ __ ___ ___ ___ gr...@unixhelp.org _ __ ___ | _ ) __| \ http://www.freebsd.org/ _ __ ___ | _ \__ \ |) | FreeBSD: The Power to Serve! _ __ ___ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Disk locks and weird things
Shouldn't a make world take about 10 hours on a P100 ?? -depends on the speed of your disks. You should probably remove all the junk in /usr/obj from previous make worlds, then run make cleandir in /usr/src and then try a make world again. The messages about no such user 'tty' indicate your /etc files are out of date. Use the mergemaster port to keep your /etc files up to date but you'll need to be carefull when adding the new users to /etc/passwd (hint: run vipw after editing /etc/passwd so the password databases are re-created). One last hint: READ THE CURRENT AND CVS-ALL MAILING LISTS IF YOU'RE GOING TO RUN CURRENT! - if you cant be botherred spending the time to do this dont run CURRENT! P.S. If your existing CURRENT system is too old, you may need to try installing a snapshot first you may have to try a few different snapshots before you find one that works... there were some problems a while back with boot disks I think. On Sun, 14 Feb 1999, Erik Funkenbusch wrote: Recently I've been trying to upgrade an early januarrry -current to current -current. I've rebuilt the kernel several times over the last few days (with new cvsup's) so i've eliminated any freak check-in mismatches. During a make world (usually about 10-20 minutes in on my P100) everything just comes to a grinding halt. No disk activity, but the screen saver will kick in (despite the shell being in the middle of said make world). If I switch to any alternate consoles and try to do anything, even an ls, it accesses the disk for a brief second, then hangs as well. Other tasks that don't need to access the disk keep running (such as natd and obviously the screen saver). After waiting about a half hour, I hit the reset and get lots of UNREF FILE's and SUMMARY INFORMATION BAD and BLK(S) MISSING IN BIT MAPS. They all say slavaged or cleared. It doesn't appear to be a problem with the actual disk, since rebooting works fine until I try and build again. Even building the kernel works fine. but doing a make world does not (I don't know if anything else causes this). It never fails in the same place twice either, but it's always the same effect. Additionally, i've been getting No such user 'tty', service ignored messages from ntalk and comsat. I'm sure these services were updated to make use of some tty user or something, but i'd like to know what exactly I should do here. I'm also getting messages from de0 and lo0 that say: de0 XXX: driver didn't set ifq_maxlen Finally, if I try and run top i get: top: cannot read swaplist: kvm_read: Bad address kvm_open: proc size mismatch (11392 total, 680 chunks) top: Out of memory. I assume this is from a newer kernel with older support files (such as top) but since I can't get world to build, I'm kinda stuck.. One more thing. I figured I might try a complete reinstallation so I tried to download the 4.0-snap of 2-11 and was able to successfully create a kern.flp but when I tried to create mfsroot.flp it seems to sit in a loop forever just moving the disk head back and forth. I tried it with several floppies (including the one I was able to successfully create kern.flp on) with the same results. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message /=\ |Work: matthew.th...@dsto.defence.gov.au | Home: thy...@camtech.net.au| \=/ If it is true that our Universe has a zero net value for all conserved quantities, then it may simply be a fluctuation of the vacuum of some larger space in which our Universe is imbedded. In answer to the question of why it happened, I offer the modest proposal that our Universe is simply one of those things which happen from time to time. E. P. Tryon from Nature Vol.246 Dec.14, 1973 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Disk locks and weird things
On Sun, 14 Feb 1999, Erik Funkenbusch wrote: Recently I've been trying to upgrade an early januarrry -current to current -current. I've rebuilt the kernel several times over the last few days (with new cvsup's) so i've eliminated any freak check-in mismatches. During a make world (usually about 10-20 minutes in on my P100) everything just comes to a grinding halt. No disk activity, but the screen saver will kick in (despite the shell being in the middle of said make world). If I switch to any alternate consoles and try to do anything, even an ls, it accesses the disk for a brief second, then hangs as well. Other tasks that don't need to access the disk keep running (such as natd and obviously the screen saver). After waiting about a half hour, I hit the reset and get lots of UNREF FILE's and SUMMARY INFORMATION BAD and BLK(S) MISSING IN BIT MAPS. They all say slavaged or cleared. But you didn't look in /var/log/messages? For shame! It doesn't appear to be a problem with the actual disk, since rebooting works fine until I try and build again. Even building the kernel works fine. but doing a make world does not (I don't know if anything else causes this). It never fails in the same place twice either, but it's always the same effect. What you should have said is It doesn't appear to be a problem with the actual disk, since rebooting with a different brand disk of the same capabilities doesn't work. or vice versa. Additionally, i've been getting No such user 'tty', service ignored messages from ntalk and comsat. I'm sure these services were updated to make use of some tty user or something, but i'd like to know what exactly I should do here. Look in src/etc/master.passwd. vipw and add the lines for users you don't have. I'm also getting messages from de0 and lo0 that say: de0 XXX: driver didn't set ifq_maxlen That's mostly harmless. It's a warning to driver maintainers that was just put in recently; the driver hasn't ever set ifq_maxlen, no doubt. Finally, if I try and run top i get: top: cannot read swaplist: kvm_read: Bad address kvm_open: proc size mismatch (11392 total, 680 chunks) top: Out of memory. I assume this is from a newer kernel with older support files (such as top) but since I can't get world to build, I'm kinda stuck.. Yes it is, but the proper order is to make th world and then make the kernel. One more thing. I figured I might try a complete reinstallation so I tried to download the 4.0-snap of 2-11 and was able to successfully create a kern.flp but when I tried to create mfsroot.flp it seems to sit in a loop forever just moving the disk head back and forth. I tried it with several floppies (including the one I was able to successfully create kern.flp on) with the same results. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message Brian Feldman_ __ ___ ___ ___ gr...@unixhelp.org _ __ ___ | _ ) __| \ http://www.freebsd.org/ _ __ ___ | _ \__ \ |) | FreeBSD: The Power to Serve! _ __ ___ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Is ppb a device or controller?
$Id: LINT,v 1.555 1999/02/14 12:00:00 nsouch Exp $ controller ppc0at isa? port? tty irq 7 $Id: GENERIC,v 1.149 1999/02/14 12:00:00 nsouch Exp $ device ppc0at isa? port? tty irq 7 Are the lables device and controller interchangeable? -- Jack O'NeillSystems Administrator / Systems Analyst j...@germanium.xtalwind.net Crystal Wind Communications, Inc. Finger j...@germanium.xtalwind.net for my PGP key. PGP Key fingerprint = F6 C4 E6 D4 2F 15 A7 67 FD 09 E9 3C 5F CC EB CD enriched, vcard, HTML messages /dev/null -- To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: lpt0
On Sun, Feb 14, 1999 at 05:31:08AM -0800, Jonathan M. Bresler wrote: Date: Sat, 13 Feb 1999 19:17:14 +0100 From: Nicolas Souchu nso...@teaser.fr You need: controller ppbus0 # The ppbus system device nlpt0 at ppbus? # The printer driver And finally the parallel port chipset interface, controller ppc0at isa? port? tty irq 7 drq 3 See ppbus(4) and/or http://www.freebsd.org/~nsouch/ppbus.html for more info about the ppbus architecture. how much information about this should be included in /usr/src/UPDATING? the entry there talks about the change but does not provide enough information to successfully upgrade (ppc0 is not mentioned, nor does it provide a pointer to where to go for more information.) ;( Sorry, your efforts are lost. I've just renamed nlpt to lpt. But I've properly updated lpt.4, I think. You may just add, the minimal configuration and point to the manpage for further details. Something like: Now the lpt driver, previously named nlpt in the ppbus system not to collide with the original isa/lpt.c functions, shall be declared with: controller ppbus0 device lpt0 at ppbus? controller ppc0 at isa? port IO_LPT1 tty irq 7 The ppc(4) driver is the ISA parallel port interface driver. The ppbus(4) controller stands for the whole ppbus system code. And finally, you have lpt(4). jmb -- nso...@teaser.fr / nso...@freebsd.org FreeBSD - Turning PCs into workstations - http://www.FreeBSD.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Aladdin chipset SMBus support available!
On Sun, Feb 14, 1999 at 08:40:11AM -0500, Brian Feldman wrote:
On Sun, 14 Feb 1999, Nicolas Souchu wrote:
On Sat, Feb 13, 1999 at 05:22:00PM -0500, Brian Feldman wrote:
On Sat, 13 Feb 1999, Nicolas Souchu wrote:
Example program to fetch temperature or voltages is available at
http://www.planet.sci.kobe-u.ac.jp/~takawata/smbus/examples/
There's also an example program to fetch SDRAM info over the smbus.
I attach you the detect.c program. It's very simple and may help us
in knowing what I2C hardware you have on your mobo.
Where's my detect.c? I think you forgot to attach it :)
:) here it is!
I tried them, and there's the problem: all the ioctl()s they perform return
EINTR! Has this driver been tested on many motherboards? Why should I expect
an EINTR? Just wondering :)
EINTR is odd. It just mean that the device at the address requested on the
I2C bus do not respond. I have to translate SMBus errors to the appropriate
unix ones.
Hmm... wouldn't the appropriate error for something not responding be an
ENXIO or ETIMEDOUT? EINTR seems more than a little wrong for this purpouse.
Fix committed.
BTW, as outlined by -pkh all this is just a first step in a huge monitoring
adventure where all still need to be _defined_ (architecture and interfaces)
and implemented. Any proposition for doing the job is wellcome,
since I just have enough time to do the hardware SMBus support.
Nicholas
--
nso...@teaser.fr / nso...@freebsd.org
FreeBSD - Turning PCs into workstations - http://www.FreeBSD.org
/*-
* Copyright (c) 1999 Nicolas Souchu
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
*notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
*notice, this list of conditions and the following disclaimer in the
*documentation and/or other materials provided with the distribution.
*
* THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
* [id for your version control system, if any]
*/
/*This program is prototype version. I'll write better one*/
#include stdlib.h
#include fcntl.h
#include machine/smb.h
const double vfactor[]={1,1,1,1.67,4,-4,-1.67};
const char *Inpname[]={
Vcore,Vit,VIO,+5V,+12V,-12V,-5V
};
int doioctl(int alias, int cmd, caddr_t param)
{
int error = 1;
int retry = 3;
while (error retry--) {
usleep(200);
error = ioctl(alias, cmd, param);
}
return (error);
}
int main (int argc,char argv[])
{
int alias, i;
unsigned char byte=0;
struct smbcmd cmd;
bzero(cmd, sizeof(cmd));
cmd.data.byte_ptr = byte;
alias = open(/dev/smb0, O_RDWR);
for (i=2; i254; i+=2)
{
cmd.slave=(u_char)i;
if(doioctl(alias, SMB_RECVB, (caddr_t)cmd)!=-1){
printf(%x found.\n,i);
}
}
close(alias);
return 0;
}
Re: New print interface
On Sat, Feb 13, 1999 at 10:03:41PM -0500, Chuck Robey wrote: I have to add an addendum here, to my previous question about the new config file setup for a simple printer. I was looking forward to seeing the probing come back to my dmesg, when I finally got it right, but seeing this: Feb 13 14:02:01 picnic /kernel: ppc0 at 0x378 irq 7 on isa Feb 13 14:02:01 picnic /kernel: ppc0: SMC FDC37C665GT chipset (EPP/PS2/NIBBLE) in COMPATIBLE mode Feb 13 14:02:01 picnic /kernel: ppb0: IEEE1284 device found /NIBBLE/ECP Feb 13 14:02:01 picnic /kernel: Probing for PnP devices on ppbus0: Feb 13 14:02:01 picnic /kernel: ppbus0: HEWLETT-PACKARD DESKJET 690C MLC,PCL,PML Feb 13 14:02:01 picnic /kernel: nlpt0: generic printer on ppbus 0 Feb 13 14:02:01 picnic /kernel: nlpt0: Interrupt-driven port I *never* expected to see the PNP functions actually pick up the name of my printer. I was economically bushwacked by the Windows corps into buying the 693C (the version with the Windows software floppies tacked on) so I was actually pleased that it ID'd the printer as the more generic 690C (sans the Windows extortia). Very nice. The mistake I'd made earlier was in not knowing that the config needed all 3 lines, not just some subset of 2 of them as I'd guessed. Great job, Nicolas! BTW, try 'cat /dev/lpt0' ;) -- nso...@teaser.fr / nso...@freebsd.org FreeBSD - Turning PCs into workstations - http://www.FreeBSD.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
incomplete integration?
=== pccardc cc -O -pipe -I/usr/src/usr.sbin/pccard/pccardc/../pccardd -Wall -g -static -c /usr/src/usr.sbin/pccard/pccardc/beep.c /usr/src/usr.sbin/pccard/pccardc/beep.c: In function `beep_main': /usr/src/usr.sbin/pccard/pccardc/beep.c:74: `PIOCSBEEP' undeclared (first use this function) /usr/src/usr.sbin/pccard/pccardc/beep.c:74: (Each undeclared identifier is reported only once /usr/src/usr.sbin/pccard/pccardc/beep.c:74: for eac To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: New print interface
On Sun, 14 Feb 1999, Nicolas Souchu wrote: I *never* expected to see the PNP functions actually pick up the name of my printer. I was economically bushwacked by the Windows corps into buying the 693C (the version with the Windows software floppies tacked on) so I was actually pleased that it ID'd the printer as the more generic 690C (sans the Windows extortia). Very nice. The mistake I'd made earlier was in not knowing that the config needed all 3 lines, not just some subset of 2 of them as I'd guessed. Great job, Nicolas! BTW, try 'cat /dev/lpt0' ;) OK, I just cvsupped, I will quickly. There's a reference to setting a drq for lpt, which isn't something I'd had to do before ... I guess there's dma capability since I last looked at it, but how do I tell what dma channel has been chosen for it? Will my bios set it for me, or is it going to be probed somehow? How do I set it? I saw an example with it set to 3, is that a default value (shall I experiment?) +--- Chuck Robey | Interests include any kind of voice or data chu...@glue.umd.edu | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run picnic (FreeBSD-current) (301) 220-2114 | and jaunt (Solaris7). +--- To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Aladdin chipset SMBus support available!
On Sun, 14 Feb 1999, Nicolas Souchu wrote:
On Sun, Feb 14, 1999 at 08:40:11AM -0500, Brian Feldman wrote:
On Sun, 14 Feb 1999, Nicolas Souchu wrote:
On Sat, Feb 13, 1999 at 05:22:00PM -0500, Brian Feldman wrote:
On Sat, 13 Feb 1999, Nicolas Souchu wrote:
Example program to fetch temperature or voltages is available at
http://www.planet.sci.kobe-u.ac.jp/~takawata/smbus/examples/
There's also an example program to fetch SDRAM info over the smbus.
I attach you the detect.c program. It's very simple and may help us
in knowing what I2C hardware you have on your mobo.
Where's my detect.c? I think you forgot to attach it :)
:) here it is!
alpm0: AcerLabs M15x3 Power Management Unit rev 0x00 on pci0.3.0
alsmb0: Aladdin IV/V/Pro2 SMBus controller
smbus0: System Management Bus on alsmb0
smb0: SMBus general purpose I/O on smbus0
{/home/green/examples}$ ./detect
a2 found.
d2 found.
I tried them, and there's the problem: all the ioctl()s they perform
return
EINTR! Has this driver been tested on many motherboards? Why should I
expect
an EINTR? Just wondering :)
EINTR is odd. It just mean that the device at the address requested on the
I2C bus do not respond. I have to translate SMBus errors to the appropriate
unix ones.
Hmm... wouldn't the appropriate error for something not responding be an
ENXIO or ETIMEDOUT? EINTR seems more than a little wrong for this purpouse.
Fix committed.
BTW, as outlined by -pkh all this is just a first step in a huge monitoring
adventure where all still need to be _defined_ (architecture and interfaces)
and implemented. Any proposition for doing the job is wellcome,
since I just have enough time to do the hardware SMBus support.
Sounds like fun
Nicholas
--
nso...@teaser.fr / nso...@freebsd.org
FreeBSD - Turning PCs into workstations - http://www.FreeBSD.org
Brian Feldman_ __ ___ ___ ___
gr...@unixhelp.org _ __ ___ | _ ) __| \
http://www.freebsd.org/ _ __ ___ | _ \__ \ |) |
FreeBSD: The Power to Serve! _ __ ___ _ |___/___/___/
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: How to power off an ATX power supply machine on shutdown ?
On Sat, 13 Feb 1999, Daniel C. Sobral wrote: Do you use the Power up at time/date feature of the BIOS? No. After this thread, I figured I'd try out shutdown -p, and lo and behold it didn't work. Well I thought, I have apm enabled, apm(1) shows that. The probe shows that and so on. A little further checking and it was using flags 0x31 by default.. presumably to avoid using possibly buggy APM 1.2 features? Anyhow.. that caused apm to return results like: APM version: 1.2 APM Managment: Enabled AC Line status: on-line Battery status: unknown Remaining battery life: unknown Remaining battery time: unknown Number of batteries: unknown Resume timer: disabled Resume on ring indicator: enabled APM Capacities: unknown Note there's no mention of the limiting to version 1.1 or 1.0. Anyhow.. try rebooting with the flags set to 0x0 and see if that works. I assume that if you've got an ATX mobo, the BIOS is new enough that the APM implementation shouldn't be too buggy... - alex To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: New print interface
On Sun, 14 Feb 1999, Nicolas Souchu wrote: I *never* expected to see the PNP functions actually pick up the name of my printer. I was economically bushwacked by the Windows corps into buying the 693C (the version with the Windows software floppies tacked on) so I was actually pleased that it ID'd the printer as the more generic 690C (sans the Windows extortia). Very nice. The mistake I'd made earlier was in not knowing that the config needed all 3 lines, not just some subset of 2 of them as I'd guessed. Great job, Nicolas! Not finished. ECP is not supported yet. I'm glad to see the 690C is ECP compliant. I bougth an HP6L, thinking it was :( But there's at least FIFO+DMA support in the nlpt driver. Try 'lptcontrol -e' with you BIOS configured to ECP. Recompile with the appropriate drq on the 'device ppc at isa?...' line. Experimentation mode (on a machine I can crash here if I need to now). I stuck the drq 3 into the 'controller ppc0' line. BTW, since LINT was changed, there's now no indication as to where to stick the dma channel info, for users. Anyhow, now my config looks like: controller ppc0at isa? port? tty irq 7 drq 3 controller ppbus0 device lpt0at ppbus? device plip0 at ppbus? device ppi0at ppbus? device pps0at ppbus? There are a couple of things that have happened that strike me as worthy of comment. Here's my relevant dmesg part: ppc0 at 0x378 irq 7 drq 3 on isa ppc0: SMC FDC37C665GT chipset (ECP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/15 bytes threshold ppb0: IEEE1284 device found /NIBBLE/ECP Probing for PnP devices on ppbus0: ppbus0: HEWLETT-PACKARD DESKJET 690C MLC,PCL,PML plip0: PLIP network interface on ppbus 0 lpt0: generic printer on ppbus 0 lpt0: Interrupt-driven port ppi0: generic parallel i/o on ppbus 0 lppps0: Pulse per second Timing Interface on ppbus 0 Notice how the ppbus finds and correctly IDs my printer (yea!) but then the lpt0 and ppi0 lines find generic ... this is a little odd, isn't it? Even if the lpt0 and ppi0 parts are less intelligent, they should share info to at least some degree, shouldn't they? 2nd note ... you said I should use lptcontrol -e. I did that, exactly, and it came back to tell me that it had switched me to extended mode (which I expected) AND to polled mode (which I neither expected nor wanted). The man page says that only one action is taken at a time. I was able to switch on the interrupt mode again (which I did want) by using the -i switch (advertised correctly on the man page now) but isn't this wrong, switching to polled mode like that on entering the -e? Last thing ... I did the 'cat /dev/lpt0' like you asked. No response whatsoever, the prompt just came back. I did this both before and after all the changes done with lptcontrol, each and every time, but the exact same response, nothing. Like typing echo. No status. Something incomplete yet? This isn't criticism, this is the feeling of a child at Christmas opening new toys, but wondering if maybe there's more under the tree I haven't quite spotted yet. +--- Chuck Robey | Interests include any kind of voice or data chu...@glue.umd.edu | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run picnic (FreeBSD-current) (301) 220-2114 | and jaunt (Solaris7). +--- To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
HEADS UP! nlpt removed, lpt still alive!
No, not a joke :) nlpt name was only a trick not to collide with lpt while both were in the system. As you noticed, the old isa lpt driver has been removed. Consequently, nlpt makes no more sense. This is I hope the last confusion about printing drivers... before the next one. So, here is one of the right declarations to get your printer working: controller ppbus0 device lpt0 at ppbus? device ppc0 at isa? port? tty irq 7 Please, read carefully the lpt(4) manpage. It's not long and will reveal you last lpt features. It's important for us to get feedback about all of this, since we'd like to rapidly move the changes to 3.1 before the jump. Have fun until the next time ;) -- nso...@teaser.fr / nso...@freebsd.org FreeBSD - Turning PCs into workstations - http://www.FreeBSD.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: New print interface
On Sun, Feb 14, 1999 at 11:52:04AM -0500, Chuck Robey wrote: On Sun, 14 Feb 1999, Nicolas Souchu wrote: I *never* expected to see the PNP functions actually pick up the name of my printer. I was economically bushwacked by the Windows corps into buying the 693C (the version with the Windows software floppies tacked on) so I was actually pleased that it ID'd the printer as the more generic 690C (sans the Windows extortia). Very nice. The mistake I'd made earlier was in not knowing that the config needed all 3 lines, not just some subset of 2 of them as I'd guessed. Great job, Nicolas! BTW, try 'cat /dev/lpt0' ;) OK, I just cvsupped, I will quickly. There's a reference to setting a drq for lpt, which isn't something I'd had to do before ... I guess there's dma capability since I last looked at it, but how do I tell what dma channel has been chosen for it? Will my bios set it for me, or is it going to be probed somehow? How do I set it? I saw an example with it set to 3, is that a default value (shall I experiment?) Your BIOS tells you the DMA channel your parallel port is configured to run with. Something like, device ppc0 at isa? port? tty irq 7 drq 3 should be ok if DMA channel is 3 in your BIOS ECP setting. It might be channel 1 though, then set drq to '1'. +--- Chuck Robey | Interests include any kind of voice or data chu...@glue.umd.edu | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run picnic (FreeBSD-current) (301) 220-2114 | and jaunt (Solaris7). +--- To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message -- nso...@teaser.fr / nso...@freebsd.org FreeBSD - Turning PCs into workstations - http://www.FreeBSD.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: lpt0
On Sat, Feb 13, 1999 at 07:36:37PM -0800, Jordan K. Hubbard wrote: FWIW, I would also like to see this happen. What's the deadline? I did it for -current this day. I'm waiting for some feedback before the 3.1 replica. On 13 Feb 1999, Dag-Erling Smorgrav wrote: Nicolas Souchu nso...@teaser.fr writes: controller ppbus0 # The ppbus system device nlpt0 at ppbus? # The printer driver OBTW, when are you planning to rename nlpt0 to lpt0? Hopefully before 3.1 goes out...it would be a bummer to have one release with a different name than the rest; it confuses documentation that tries to cover multiple versions. -john I agree. -- nso...@teaser.fr / nso...@freebsd.org FreeBSD - Turning PCs into workstations - http://www.FreeBSD.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Aladdin chipset SMBus support available!
On Sun, Feb 14, 1999 at 12:11:09PM -0500, Brian Feldman wrote:
On Sun, 14 Feb 1999, Nicolas Souchu wrote:
On Sun, Feb 14, 1999 at 08:40:11AM -0500, Brian Feldman wrote:
On Sun, 14 Feb 1999, Nicolas Souchu wrote:
On Sat, Feb 13, 1999 at 05:22:00PM -0500, Brian Feldman wrote:
On Sat, 13 Feb 1999, Nicolas Souchu wrote:
Example program to fetch temperature or voltages is available at
http://www.planet.sci.kobe-u.ac.jp/~takawata/smbus/examples/
There's also an example program to fetch SDRAM info over the smbus.
I attach you the detect.c program. It's very simple and may help us
in knowing what I2C hardware you have on your mobo.
Where's my detect.c? I think you forgot to attach it :)
:) here it is!
alpm0: AcerLabs M15x3 Power Management Unit rev 0x00 on pci0.3.0
alsmb0: Aladdin IV/V/Pro2 SMBus controller
smbus0: System Management Bus on alsmb0
smb0: SMBus general purpose I/O on smbus0
{/home/green/examples}$ ./detect
a2 found.
d2 found.
So,
./spd 1
will work!
--
nso...@teaser.fr / nso...@freebsd.org
FreeBSD - Turning PCs into workstations - http://www.FreeBSD.org
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: lpt0
On Sat, Feb 13, 1999 at 07:36:37PM -0800, Jordan K. Hubbard wrote: FWIW, I would also like to see this happen. What's the deadline? I did it for -current this day. I'm waiting for some feedback before the 3.1 replica. Actually, subsequent discussions with Dag-Erling have sort of shown this to have been rather too ambitious of me and now I've major second thoughts. :( I think the number of changes involved in making the cut-over are just too likely to hang us at the last minute, and that's nothing any of us want. Any there any last cosmetic tie-ups of a less scary nature, or are we good to go as-is in the 3.0 branch? - Jordan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: New print interface
On Sun, Feb 14, 1999 at 12:48:56PM -0500, Chuck Robey wrote: But there's at least FIFO+DMA support in the nlpt driver. Try 'lptcontrol -e' with you BIOS configured to ECP. Recompile with the appropriate drq on the 'device ppc at isa?...' line. Experimentation mode (on a machine I can crash here if I need to now). I stuck the drq 3 into the 'controller ppc0' line. BTW, since LINT was changed, there's now no indication as to where to stick the dma channel info, for users. Info is in the lpt(4) manpage. Anyhow, now my config looks like: controller ppc0at isa? port? tty irq 7 drq 3 controller ppbus0 device lpt0at ppbus? device plip0 at ppbus? device ppi0at ppbus? device pps0at ppbus? Good. There are a couple of things that have happened that strike me as worthy of comment. Here's my relevant dmesg part: ppc0 at 0x378 irq 7 drq 3 on isa ppc0: SMC FDC37C665GT chipset (ECP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/15 bytes threshold ppb0: IEEE1284 device found /NIBBLE/ECP Probing for PnP devices on ppbus0: ppbus0: HEWLETT-PACKARD DESKJET 690C MLC,PCL,PML plip0: PLIP network interface on ppbus 0 lpt0: generic printer on ppbus 0 lpt0: Interrupt-driven port ppi0: generic parallel i/o on ppbus 0 lppps0: Pulse per second Timing Interface on ppbus 0 Notice how the ppbus finds and correctly IDs my printer (yea!) but then the lpt0 and ppi0 lines find generic ... this is a little odd, isn't it? Even if the lpt0 and ppi0 parts are less intelligent, they should share info to at least some degree, shouldn't they? i/o is generic here. 2nd note ... you said I should use lptcontrol -e. I did that, exactly, and it came back to tell me that it had switched me to extended mode (which I expected) AND to polled mode (which I neither expected nor wanted). The man page says that only one action is taken at a time. I was able to switch on the interrupt mode again (which I did want) by using the -i switch (advertised correctly on the man page now) but isn't this wrong, switching to polled mode like that on entering the -e? Hmm, yes. It is interrupt driven tough. But, can you print with extended mode set?! If true, imagine you use DMA+FIFO when printing! If not convinced, enable PPC_DEBUG when compiling i386/isa/ppc.c. Last thing ... I did the 'cat /dev/lpt0' like you asked. No response whatsoever, the prompt just came back. I did this both before and after all the changes done with lptcontrol, each and every time, but the exact same response, nothing. Like typing echo. No status. Something incomplete yet? This isn't criticism, this is the feeling of a child at Christmas opening new toys, but wondering if maybe there's more under the tree I haven't quite spotted yet. +--- Chuck Robey | Interests include any kind of voice or data chu...@glue.umd.edu | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run picnic (FreeBSD-current) (301) 220-2114 | and jaunt (Solaris7). +--- -- nso...@teaser.fr / nso...@freebsd.org FreeBSD - Turning PCs into workstations - http://www.FreeBSD.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Aladdin chipset SMBus support available!
On Sun, 14 Feb 1999, Nicolas Souchu wrote:
On Sun, Feb 14, 1999 at 12:11:09PM -0500, Brian Feldman wrote:
On Sun, 14 Feb 1999, Nicolas Souchu wrote:
On Sun, Feb 14, 1999 at 08:40:11AM -0500, Brian Feldman wrote:
On Sun, 14 Feb 1999, Nicolas Souchu wrote:
On Sat, Feb 13, 1999 at 05:22:00PM -0500, Brian Feldman wrote:
On Sat, 13 Feb 1999, Nicolas Souchu wrote:
Example program to fetch temperature or voltages is available at
http://www.planet.sci.kobe-u.ac.jp/~takawata/smbus/examples/
There's also an example program to fetch SDRAM info over the smbus.
I attach you the detect.c program. It's very simple and may help us
in knowing what I2C hardware you have on your mobo.
Where's my detect.c? I think you forgot to attach it :)
:) here it is!
alpm0: AcerLabs M15x3 Power Management Unit rev 0x00 on pci0.3.0
alsmb0: Aladdin IV/V/Pro2 SMBus controller
smbus0: System Management Bus on alsmb0
smb0: SMBus general purpose I/O on smbus0
{/home/green/examples}$ ./detect
a2 found.
d2 found.
So,
./spd 1
will work!
Sorta. It did work. Then it stopped working. Running detect seems to kill my
SM (or at least reset it to some weird state)
{/home/green/examples}$ ./detect
{/home/green/examples}$
--
nso...@teaser.fr / nso...@freebsd.org
FreeBSD - Turning PCs into workstations - http://www.FreeBSD.org
Brian Feldman_ __ ___ ___ ___
gr...@unixhelp.org _ __ ___ | _ ) __| \
http://www.freebsd.org/ _ __ ___ | _ \__ \ |) |
FreeBSD: The Power to Serve! _ __ ___ _ |___/___/___/
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: lpt0
On Sun, 14 Feb 1999, Jordan K. Hubbard wrote: On Sat, Feb 13, 1999 at 07:36:37PM -0800, Jordan K. Hubbard wrote: FWIW, I would also like to see this happen. What's the deadline? I did it for -current this day. I'm waiting for some feedback before the 3.1 replica. Actually, subsequent discussions with Dag-Erling have sort of shown this to have been rather too ambitious of me and now I've major second thoughts. :( I think the number of changes involved in making the cut-over are just too likely to hang us at the last minute, and that's nothing any of us want. Any there any last cosmetic tie-ups of a less scary nature, or are we good to go as-is in the 3.0 branch? ICMP_BANDLIM by default in GENERIC? And maybe perhaps a note that there is a much improved parallel port driver that everyone should use? Putting nlpt, ppbus, ppc etc in there should be fine, considering nlpt wouldn't collide with anyone trying to configure an old kernel... - Jordan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message Brian Feldman_ __ ___ ___ ___ gr...@unixhelp.org _ __ ___ | _ ) __| \ http://www.freebsd.org/ _ __ ___ | _ \__ \ |) | FreeBSD: The Power to Serve! _ __ ___ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: New print interface
On Sun, 14 Feb 1999, Nicolas Souchu wrote: There are a couple of things that have happened that strike me as worthy of comment. Here's my relevant dmesg part: ppc0 at 0x378 irq 7 drq 3 on isa ppc0: SMC FDC37C665GT chipset (ECP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/15 bytes threshold ppb0: IEEE1284 device found /NIBBLE/ECP Probing for PnP devices on ppbus0: ppbus0: HEWLETT-PACKARD DESKJET 690C MLC,PCL,PML plip0: PLIP network interface on ppbus 0 lpt0: generic printer on ppbus 0 lpt0: Interrupt-driven port ppi0: generic parallel i/o on ppbus 0 lppps0: Pulse per second Timing Interface on ppbus 0 Notice how the ppbus finds and correctly IDs my printer (yea!) but then the lpt0 and ppi0 lines find generic ... this is a little odd, isn't it? Even if the lpt0 and ppi0 parts are less intelligent, they should share info to at least some degree, shouldn't they? i/o is generic here. If IO is generic, then printing the type of printer it finds is meaningless, right? It's going to announce generic no matter what, then it should stay silent, right? Better to say nothing than to get it wrong every time, especially with the correct info sitting mere lines above, advertising the mistake. 2nd note ... you said I should use lptcontrol -e. I did that, exactly, and it came back to tell me that it had switched me to extended mode (which I expected) AND to polled mode (which I neither expected nor wanted). The man page says that only one action is taken at a time. I was able to switch on the interrupt mode again (which I did want) by using the -i switch (advertised correctly on the man page now) but isn't this wrong, switching to polled mode like that on entering the -e? Hmm, yes. It is interrupt driven tough. Then the lptcontrol command should not announce, when you enter 'lptcontrol -e' that it's setting polled mode (which it did). If it's still in interrupt mode (which is good) then it's fibbing to me, right? But, can you print with extended mode set?! I can't cat /dev/lpt0 and get any status. I did the lptcontrol -e, so I *think* I;m in extended mode, and it *does* print. I guess I have to find out what I can buy to play with this further. I would like to have some logic level outputs, so I can do some direct machine control, and doing it via my printer port sounds cool. Know anything like that? Having my computer be my alarm clock would be neat. I have 5 different wakeup times (because of odd class schedules) and that would, in fact, be a real nice win. If true, imagine you use DMA+FIFO when printing! If not convinced, enable PPC_DEBUG when compiling i386/isa/ppc.c. OK, experimenting. What about 'cat /dev/lpt0' doing nothing? Am I doing that right? What did you expect me to see, when you asked that? +--- Chuck Robey | Interests include any kind of voice or data chu...@glue.umd.edu | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run picnic (FreeBSD-current) (301) 220-2114 | and jaunt (Solaris7). +--- To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: New print interface
It says generic every time, whther or not there's a printer attached. lpt0: generic printer on ppbus 0 lpt0: Interrupt-driven port should be lpt0: generic printer port on ppbus 0 lpt0: Interrupt-driven port Brian Feldman_ __ ___ ___ ___ gr...@unixhelp.org _ __ ___ | _ ) __| \ http://www.freebsd.org/ _ __ ___ | _ \__ \ |) | FreeBSD: The Power to Serve! _ __ ___ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Aladdin chipset SMBus support available!
In message pine.bsf.4.05.9902141208450.13678-100...@janus.syracuse.net, Brian
Feldman wrote:
I attach you the detect.c program. It's very simple and may help us
in knowing what I2C hardware you have on your mobo.
Where's my detect.c? I think you forgot to attach it :)
:) here it is!
alpm0: AcerLabs M15x3 Power Management Unit rev 0x00 on pci0.3.0
alsmb0: Aladdin IV/V/Pro2 SMBus controller
smbus0: System Management Bus on alsmb0
smb0: SMBus general purpose I/O on smbus0
{/home/green/examples}$ ./detect
a2 found.
This is DIMM(with SPD).
#./spd 1
will show your DIMM infomation.
d2 found.
I want to know about this address. SMBus in my motherboard will hang
up when I issue RECV_BYTE method for this port.
BTW, as outlined by -pkh all this is just a first step in a huge monitoring
adventure where all still need to be _defined_ (architecture and interfaces)
and implemented. Any proposition for doing the job is wellcome,
since I just have enough time to do the hardware SMBus support.
Sounds like fun
I think so too.
/dev/smb? should not be used in casual use,because it is dangerous,as
banging I/O port.I want to discuss about the interface. Where did he
wrote it?
Takanori Watanabe
a href=http://www.planet.kobe-u.ac.jp/~takawata/key.html;
Public Key/a
Key fingerprint = 2C 51 E2 78 2C E1 C5 2D 0F F1 20 A3 11 3A 62 2A
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: New print interface
If IO is generic, then printing the type of printer it finds is meaningless, right? It's going to announce generic no matter what, then it should stay silent, right? Better to say nothing than to get it wrong every time, especially with the correct info sitting mere lines above, advertising the mistake. It's not a mistake as such; the printer is of type foo, and it has a generic printer interface (lpt0). Printing the printer details is not unhelpful (eg. it means you can use dmesg to find which printer is where, etc.) I can't cat /dev/lpt0 and get any status. I did the lptcontrol -e, so I *think* I;m in extended mode, and it *does* print. I guess I have to find out what I can buy to play with this further. I would like to have some logic level outputs, so I can do some direct machine control, and doing it via my printer port sounds cool. Know anything like that? ppi(4) -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ m...@smith.net.au \\ The race is long, and in the \\ msm...@freebsd.org \\ end it's only with yourself. \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: New print interface
On Sun, Feb 14, 1999 at 01:16:11PM -0500, Chuck Robey wrote: ppc0 at 0x378 irq 7 drq 3 on isa ppc0: SMC FDC37C665GT chipset (ECP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/15 bytes threshold ppb0: IEEE1284 device found /NIBBLE/ECP Probing for PnP devices on ppbus0: ppbus0: HEWLETT-PACKARD DESKJET 690C MLC,PCL,PML plip0: PLIP network interface on ppbus 0 lpt0: generic printer on ppbus 0 lpt0: Interrupt-driven port ppi0: generic parallel i/o on ppbus 0 lppps0: Pulse per second Timing Interface on ppbus 0 Notice how the ppbus finds and correctly IDs my printer (yea!) but then the lpt0 and ppi0 lines find generic ... this is a little odd, isn't it? Even if the lpt0 and ppi0 parts are less intelligent, they should share info to at least some degree, shouldn't they? i/o is generic here. If IO is generic, then printing the type of printer it finds is meaningless, right? It's going to announce generic no matter what, then it should stay silent, right? Better to say nothing than to get it wrong every time, especially with the correct info sitting mere lines above, advertising the mistake. ppi and lpt are really different. ppb probe and lpt too; and finally, ppb probe and ppi are quite different also ;) The ppbus architecture is made of an interface layer (ppc), a mid level (ppbus or ppb) and a device level (lpt, ppi, pps..). ppc does the chipset detection, here you have an SMC chipset, and properly configure it respecting the SMC datasheets. Not usual for a parallel port chip ;) It also detect ECP FIFO and test it. Then it calls the ppb level power_up routine. During ppb level power_up, the parallel port bus is probed, trying to find out an IEEE1284 device and only one (further developments could be made to find _every_ IEEE1284 devices daisy chain to the port, thanks to the IEEE1284-3 standard). IEEE1284 devices shall have an device_id feature that let the host retrieve identification info from them. This is referenced as the NIBBLE_ID mode. Once done, the ppb level initializes every device it knows about. lpt have been there before any IEEE1284 support. Actually, lpt _is_ the old lpt driver with machine-independent calls to the ppc interface and some request/release calls to the bus to allow bus sharing with a ZIP or what else. That's why lpt support is generic. No matter with the previous probe. IEEE1284 support is only a set of functions any device driver may call to take advantage of it. Actually, lpt uses it since recently. When you do a 'cat /dev/lpt0', it tries to negocition NIBBLE mode with the printer and fetch data if the peripheral has some. Yours doesn't seem to. But I'm not sure, since I know some peripherals fails to say they have/dont_have data to send. You should really dig into this with DEBUG_1284 option enabled. Since there are things specific and things that are not, I prefered to differenciate it in the past. But you're probably rigth, only this printer driver may ever exist. Look at the ppbus(4) architecture, the ppi code and tell me if I shall change the boot outputs. 2nd note ... you said I should use lptcontrol -e. I did that, exactly, and it came back to tell me that it had switched me to extended mode (which I expected) AND to polled mode (which I neither expected nor wanted). The man page says that only one action is taken at a time. I was able to switch on the interrupt mode again (which I did want) by using the -i switch (advertised correctly on the man page now) but isn't this wrong, switching to polled mode like that on entering the -e? Hmm, yes. It is interrupt driven tough. Then the lptcontrol command should not announce, when you enter 'lptcontrol -e' that it's setting polled mode (which it did). If it's still in interrupt mode (which is good) then it's fibbing to me, right? I agree. But it was to simple ;) But, can you print with extended mode set?! I can't cat /dev/lpt0 and get any status. I did the lptcontrol -e, so I *think* I;m in extended mode, and it *does* print. I guess I have to ^^ A! Try, DEBUG_1284 to see what happen with lpt read. find out what I can buy to play with this further. I would like to have some logic level outputs, so I can do some direct machine control, and doing it via my printer port sounds cool. Know anything like that? Having my computer be my alarm clock would be neat. I have 5 different wakeup times (because of odd class schedules) and that would, in fact, be a real nice win. A better idea would be to do it with I2C. Which I also promote in FreeBSD ;) See http://www.freebsd.org/~nsouch/iicbus.html If true, imagine you use DMA+FIFO when printing! If not convinced, enable PPC_DEBUG when compiling i386/isa/ppc.c. OK, experimenting. What about 'cat /dev/lpt0' doing nothing? Am I doing that right? What did you expect me to see, when you asked that? DEBUG_1284. -- nso...@teaser.fr
Re: Aladdin chipset SMBus support available!
On Sun, Feb 14, 1999 at 01:01:27PM -0500, Brian Feldman wrote:
[...]
Sorta. It did work. Then it stopped working. Running detect seems to kill my
SM (or at least reset it to some weird state)
{/home/green/examples}$ ./detect
{/home/green/examples}$
You mean you got some output from spd? Which? Try recompiling alpm.o with
DEBUG defined.
rm alpm.o ; make CC=cc -DDEBUG
--
nso...@teaser.fr / nso...@freebsd.org
FreeBSD - Turning PCs into workstations - http://www.FreeBSD.org
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: New print interface
On Sun, Feb 14, 1999 at 01:33:24PM -0500, Brian Feldman wrote: It says generic every time, whther or not there's a printer attached. Yes, fun isn't it? lpt0: generic printer on ppbus 0 lpt0: Interrupt-driven port should be lpt0: generic printer port on ppbus 0 lpt0: Interrupt-driven port You certainly mean that only hardware shall be enclosed by s? But this how device driver boot info is handled in the new bus system. ppbus is for you guys anyway. You're bootverbose preferences will be mine until it remains homogeneous with the whole system. Brian Feldman _ __ ___ ___ ___ gr...@unixhelp.org _ __ ___ | _ ) __| \ http://www.freebsd.org/ _ __ ___ | _ \__ \ |) | FreeBSD: The Power to Serve! _ __ ___ _ |___/___/___/ -- nso...@teaser.fr / nso...@freebsd.org FreeBSD - Turning PCs into workstations - http://www.FreeBSD.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: lpt0
On Sun, Feb 14, 1999 at 09:58:39AM -0800, Jordan K. Hubbard wrote: On Sat, Feb 13, 1999 at 07:36:37PM -0800, Jordan K. Hubbard wrote: FWIW, I would also like to see this happen. What's the deadline? I did it for -current this day. I'm waiting for some feedback before the 3.1 replica. Actually, subsequent discussions with Dag-Erling have sort of shown this to have been rather too ambitious of me and now I've major second thoughts. :( I think the number of changes involved in making the cut-over are just too likely to hang us at the last minute, and that's nothing any of us want. Any there any last cosmetic tie-ups of a less scary nature, or are we good to go as-is in the 3.0 branch? Ok, we should keep lpt, but I'll need to sync ppbus before the release just to fix some bugs discovered by all these new testers. BTW, I really don't know when 3.1 will be released. - Jordan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message -- nso...@teaser.fr / nso...@freebsd.org FreeBSD - Turning PCs into workstations - http://www.FreeBSD.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: lpt0
Ok, we should keep lpt, but I'll need to sync ppbus before the release just to fix some bugs discovered by all these new testers. OK, better do it soon then! :) BTW, I really don't know when 3.1 will be released. The tag goes down tonite (in approximately 7 hours) and the release is tomorrow afternoon. - Jordan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Aladdin chipset SMBus support available!
On Mon, Feb 15, 1999 at 03:55:07AM +0900, takaw...@shidahara1.planet.sci.kobe-u.ac.jp wrote: d2 found. I want to know about this address. SMBus in my motherboard will hang up when I issue RECV_BYTE method for this port. It does not for me. It's supposed to be the address of a clock chip, isn't it? BTW, as outlined by -pkh all this is just a first step in a huge monitoring adventure where all still need to be _defined_ (architecture and interfaces) and implemented. Any proposition for doing the job is wellcome, since I just have enough time to do the hardware SMBus support. Sounds like fun I think so too. /dev/smb? should not be used in casual use,because it is dangerous,as banging I/O port.I want to discuss about the interface. Where did he wrote it? He wrote nothing, just: Not to stop you in your tracks, but I would really love to see somebody (more capable than the PAO people) work out a power management architecture for us before we have too many more hacks in this area... Poul-Henning In message 199902131808.kaa79...@freefall.freebsd.org, Nicolas Souchu writes: nsouch 1999/02/13 10:08:35 PST Modified files: share/man/man4 intpm.4 Log: Fix the date and add an smbus declaration Revision ChangesPath 1.2 +3 -2 src/share/man/man4/intpm.4 -- nso...@teaser.fr / nso...@freebsd.org FreeBSD - Turning PCs into workstations - http://www.FreeBSD.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: lpt0
On Sun, Feb 14, 1999 at 11:43:36AM -0800, Jordan K. Hubbard wrote: Ok, we should keep lpt, but I'll need to sync ppbus before the release just to fix some bugs discovered by all these new testers. OK, better do it soon then! :) BTW, I really don't know when 3.1 will be released. The tag goes down tonite (in approximately 7 hours) and the release is tomorrow afternoon. Arg! I'll do the best and most wise. - Jordan -- nso...@teaser.fr / nso...@freebsd.org FreeBSD - Turning PCs into workstations - http://www.FreeBSD.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: lpt0
Jordan K. Hubbard j...@zippy.cdrom.com writes: Actually, subsequent discussions with Dag-Erling have sort of shown this to have been rather too ambitious of me and now I've major second thoughts. :( I *can* do it if you want. It's pretty straightforward, it's just that there are a lot of things to do, and the short deadline means I'll have to handle pc98 and src/UPDATING myself rather than rely on Kato and Warner to do it themselves. It'll take me an hour or two to go through every file that needs to be changed, and two or three hours more to test things and fix loose ends. The alternative is to just update GENERIC, LINT et al to use ppbus instead of the old lpt driver, and throw in a warning in the probe messages in src/sys/i386/lpt.c telling people to move to ppbus. It should be pretty safe. DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: lpt0
The alternative is to just update GENERIC, LINT et al to use ppbus instead of the old lpt driver, and throw in a warning in the probe messages in src/sys/i386/lpt.c telling people to move to ppbus. It should be pretty safe. Now that I could live with. Are you up for that? - Jordan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Error handling for src/usr.sbin/pccard/pccardc/*
fprintf(stderr,
-usage: pccardc enabler slot driver [-m addr size] [-a iobase] [-i irq]\n);
+Usage: enabler slot driver [-m addr size] [-a iobase] [-i irq]\n);
Usage string use to start with usage, not Usage. Progname should
follow.
- fprintf(stderr, usage: pccardc subcommand arg ...\n);
- fprintf(stderr, subcommands:\n);
+ fprintf(stderr, Usage:\n);
+ fprintf(stderr, \t%s subcommand arg ...\n, argv[0]);
We do hardcode the progname, because it is known.
[removing of usage()]
A bad thing.
- usage();
+ errx(1, Usage: %s pccardmem [ memory-address ], argv[0]);
Err(3) is wrong at displaying the usage string because it prepends the
progname.
+
+ if (argc != 4)
+ errx(1, Usage: %s rdattr slot offs length, argv[0]);
Errx() - usage()
+ if ((buf = malloc(length)) == 0)
+ err(1, %s, name);
Name give no information here. And because our malloc doesn't set
errno, err() which makes use of errno now prints garbage. I suggest
errx(1, malloc failed).
----
Philippe Charnier charn...@{lirmm.fr,xp11.frmug.org,FreeBSD.org}
``a PC not running FreeBSD is like a venusian with no tentacles''
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Weird piecemeal reads over socketpair() pipe breaks up small writes into even smaller reads.
This is under -current. I don't know when it started, but I think whatever
change is causing this was in the last week or two.
This isn't a 'bug', per say, but it bothers me that a small 128 byte
write() is being somehow broken apart into two smaller read()s. It isn't
efficient, and it shouldn't be happening.
-Matt
Matthew Dillon
dil...@backplane.com
apollo:/home/dillon ./x
read 96
read 32
#include sys/types.h
#include sys/socket.h
#include sys/un.h /* unix domain sockets */
#include netinet/in.h /* internet sockets */
#include netinet/tcp.h/* TCP_NODELAY sockopt */
#include stdio.h
#include fcntl.h
int
main(int ac, char **av)
{
int fds[2];
int n;
char buf[128];
fd_set rfds;
if (socketpair(PF_UNIX, SOCK_STREAM, IPPROTO_IP, fds) 0)
perror(socketpair);
fcntl(fds[0], F_SETFL, O_NONBLOCK);
FD_ZERO(rfds);
FD_SET(fds[0], rfds);
if (fork() == 0) {
sleep(1);
write(fds[1], buf, sizeof(buf));
_exit(1);
}
select(fds[0] + 1, rfds, NULL, NULL, NULL);
while ((n = read(fds[0], buf, sizeof(buf))) 0)
printf(read %d\n, n);
return(0);
}
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: Disk locks and weird things
:Recently I've been trying to upgrade an early januarrry -current to :current -current. I've rebuilt the kernel several times over the last few :days (with new cvsup's) so i've eliminated any freak check-in mismatches. : :During a make world (usually about 10-20 minutes in on my P100) everything :just comes to a grinding halt. No disk activity, but the screen saver will :kick in (despite the shell being in the middle of said make world). :... It sounds to me like you may have IDE drives and are hitting an IDE bug. Look at /usr/src/sys/i386/conf/LINT carefully and try using less sophisticated flags if you are using flags for your ide drive. Example: controller wdc0at isa? port IO_WD1 bio irq 14 flags 0x00ff8004 these flags If you are using 0xa0ffa0ff try backing off to 0x00ff8004. Or even back all the way off to 0x00040004. If you have softupdates enabled, try disabling it - not because of any bug in softupdates, but because it will hit the disk much harder then if it is off. If you can get everything working then try reenabling features slowly until you figure out which one is causing the disk lockups. :Additionally, i've been getting No such user 'tty', service ignored messages :from ntalk and comsat. I'm sure these services were updated to make use of :some tty user or something, but i'd like to know what exactly I should do :here. Yes, you have to add a few more dummy users to passwd. :I'm also getting messages from de0 and lo0 that say: : :de0 XXX: driver didn't set ifq_maxlen Ignore this. :Finally, if I try and run top i get: : :top: cannot read swaplist: kvm_read: Bad address :kvm_open: proc size mismatch (11392 total, 680 chunks) :top: Out of memory. : :I assume this is from a newer kernel with older support files (such as top) :but since I can't get world to build, I'm kinda stuck.. Right. don't worry about it until you get buildworld working. -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: incomplete integration?
=== pccardc cc -O -pipe -I/usr/src/usr.sbin/pccard/pccardc/../pccardd -Wall -g -static -c /usr/src/usr.sbin/pccard/pccardc/beep.c /usr/src/usr.sbin/pccard/pccardc/beep.c: In function `beep_main': /usr/src/usr.sbin/pccard/pccardc/beep.c:74: `PIOCSBEEP' undeclared (first use this function) Did you upgrade your include files? Nate To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Aladdin chipset SMBus support available!
On Sun, 14 Feb 1999, Nicolas Souchu wrote:
On Sun, Feb 14, 1999 at 01:01:27PM -0500, Brian Feldman wrote:
[...]
Sorta. It did work. Then it stopped working. Running detect seems to kill my
SM (or at least reset it to some weird state)
{/home/green/examples}$ ./detect
{/home/green/examples}$
You mean you got some output from spd? Which? Try recompiling alpm.o with
DEBUG defined.
On spd I would get an error message, and if I ever did spd 1 it got as far
as printing 128 bytes used, then erred out...
rm alpm.o ; make CC=cc -DDEBUG
I'll rm alpm.o; CC='cc -DDEBUG' make alpm.o; make, if that's what you mean.
--
nso...@teaser.fr / nso...@freebsd.org
FreeBSD - Turning PCs into workstations - http://www.FreeBSD.org
Brian Feldman_ __ ___ ___ ___
gr...@unixhelp.org _ __ ___ | _ ) __| \
http://www.freebsd.org/ _ __ ___ | _ \__ \ |) |
FreeBSD: The Power to Serve! _ __ ___ _ |___/___/___/
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
How the hell does one create a new bus?!
G. Alright, I give up: how does one create a new 'bus' layer? By that I mean like /sys/dev/iicbus and /sys/dev/smbus. Yes, I've read the code in these two directories, but I'm confused as to which parts relate to the bus architecture in general and which parts are speficic to the I2C and system management implementation. From what I can tell, you need the following: - foobus_if.m, a file which describes the functions that drivers for devices attached to this kind bus can perform. - foobus.c and foobus.h WHAT EXACTLY GOES IN HERE!? - fooconf.c and fooconf.h WHAT EXACTLY GOES IN HERE!? - Some type of top level driver for the device which implements the bus. - Various drivers for devices attached to the bus. In my particular case, I'm trying to create a bus layer for MII-compliant PHYs attached to ethernet controller chips. The ethernet controller is the bus controller device: each MII management bus can have up to 32 PHY devices attached to it (though in general you rarely have more than two). Each ethernet driver exports three functions to the MII code: mii_read(), mii_write() and mii_statchg(). The first two allow reading and writing of the registers of a PHY at a particular address (i.e. mii_read(dev, phyadd, regaddr), mii_write(dev, phyaddr, regaddr, val)). The mii_statchg() routine is a callback routine: when one of the lower-level PHY drivers does a media change, it calls back to the ethernet driver to let it know. (This is necessary because some media changes also require updating registers on the ethernet controller itself. For instance, on the ThunderLAN chip, if the PHY is set for full duplex, the ThunderLAN chip itself also has to be programmed for full duplex at the same time). The PHY drivers themselves (as they are now) export three functions to the MII glue code: foophy_probe(), foophy_attach() and foophy_service(). The middle MII layer exports mii_phy_probe(), mii_pollstat(), mii_statchg() and mii_tick() back to the ethernet driver. I've faked things up for now using linker sets, but I'd prefer to make everything fit into the bus framework if possible. Unfortunately, there doesn't appear to be a nice generic example that shows how to create a new bus layer, and the existing code confuses the hell out of me. For example, both the iicbus and smbus code use interrupt routines, but the MII code doesn't need interrupts (PHY devices don't normally generate interrupts). Also, how do I know exactly what goes into the foobus.c and fooconf.c modules? The smbconf.c and iiconf.c modules appear to have 'request_bus' routines that do things with tsleep(); what is this for? Does every bus need this or is it specific to the I2C and SMB stuff? The ppbus code is no help as it doesn't actually use this framework, and the usb bus stuff is a mutant pile of macros and #ifdefs. What this stuff needs is a developer's guide; a clearcut explanation of how to create new busses, how to create top level bus drivers and how to create drivers for devices attached to busses. If anyone can point me at such a guide or can just explain to me how this nonsense is supposed to work, I'd be grateful. -Bill -- = -Bill Paul(212) 854-6020 | System Manager, Master of Unix-Fu Work: wp...@ctr.columbia.edu | Center for Telecommunications Research Home: wp...@skynet.ctr.columbia.edu | Columbia University, New York City = It is not I who am crazy; it is I who am mad! - Ren Hoek, Space Madness = To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: incomplete integration?
=== pccardc cc -O -pipe -I/usr/src/usr.sbin/pccard/pccardc/../pccardd -Wall -g -static -c /usr/src/usr.sbin/pccard/pccardc/beep.c /usr/src/usr.sbin/pccard/pccardc/beep.c: In function `beep_main': /usr/src/usr.sbin/pccard/pccardc/beep.c:74: `PIOCSBEEP' undeclared (first use this function) Did you upgrade your include files? I had this same thing happen to me while doing a 'make buildworld'. Once I did a 'make includes', followed by 'make', the build completed. I would have expected that the buildworld environment would have had all the required include files in it. louie To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: lpt0
On Sun, Feb 14, 1999 at 11:58:48AM -0800, Jordan K. Hubbard wrote: The alternative is to just update GENERIC, LINT et al to use ppbus instead of the old lpt driver, and throw in a warning in the probe messages in src/sys/i386/lpt.c telling people to move to ppbus. It should be pretty safe. Now that I could live with. Are you up for that? Not better than the actual state, since I renamed nlpt to lpt today in -current, as wished by most of you. So, we should let it as is (nlpt+lpt) in 3.1. Anyway, 3.1 is stable and what is more stable than the old-lpt? - Jordan -- nso...@teaser.fr / nso...@freebsd.org FreeBSD - Turning PCs into workstations - http://www.FreeBSD.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Aladdin chipset SMBus support available!
On Sun, Feb 14, 1999 at 04:30:27PM -0500, Brian Feldman wrote: On spd I would get an error message, and if I ever did spd 1 it got as far as printing 128 bytes used, then erred out... rm alpm.o ; make CC=cc -DDEBUG I'll rm alpm.o; CC='cc -DDEBUG' make alpm.o; make, if that's what you mean. any difference? -- nso...@teaser.fr / nso...@freebsd.org FreeBSD - Turning PCs into workstations - http://www.FreeBSD.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: lpt0
On Sun, 14 Feb 1999, Jordan K. Hubbard wrote: On Sat, Feb 13, 1999 at 07:36:37PM -0800, Jordan K. Hubbard wrote: FWIW, I would also like to see this happen. What's the deadline? I did it for -current this day. I'm waiting for some feedback before the 3.1 replica. Actually, subsequent discussions with Dag-Erling have sort of shown this to have been rather too ambitious of me and now I've major second thoughts. :( My initial comment was based on my MISperception that the old lpt driver had been removed from RELENG_3 when, in fact, it had only been removed from -current. Realizing my blunder, I retract the suggestion. -john To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: incomplete integration?
I did what I thought was a complete pulldown, but tonite's build will tell. On Sun, 14 Feb 1999, Nate Williams wrote: === pccardc cc -O -pipe -I/usr/src/usr.sbin/pccard/pccardc/../pccardd -Wall -g -static -c /usr/src/usr.sbin/pccard/pccardc/beep.c /usr/src/usr.sbin/pccard/pccardc/beep.c: In function `beep_main': /usr/src/usr.sbin/pccard/pccardc/beep.c:74: `PIOCSBEEP' undeclared (first use this function) Did you upgrade your include files? Nate To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: incomplete integration?
Did you upgrade your include files? I had this same thing happen to me while doing a 'make buildworld'. Once I did a 'make includes', followed by 'make', the build completed. I would have expected that the buildworld environment would have had all the required include files in it. Huh. Well, buildworld is broken then. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
XXX: driver didn't set ifq_maxlen (was Re: Disk locks and weird things)
On Sun, 14 Feb 1999, Brian Feldman wrote: I'm also getting messages from de0 and lo0 that say: de0 XXX: driver didn't set ifq_maxlen That's mostly harmless. It's a warning to driver maintainers that was just put in recently; the driver hasn't ever set ifq_maxlen, no doubt. I see this on lo0 every time I boot - is this a problem in 3.1 as well, or just -current? It's probably not good to leave these messages in 3.1 as it ships, if the former. Kris - (ASP) Microsoft Corporation (MSFT) announced today that the release of its productivity suite, Office 2000, will be delayed until the first quarter of 1901. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Aladdin chipset SMBus support available!
On Sun, 14 Feb 1999, Brian Feldman wrote: Sorta. It did work. Then it stopped working. Running detect seems to kill my SM (or at least reset it to some weird state) Ahh yes, I'm not alone. Running detect here came up with four ports (5a, 60, 9a, a0 I think). It also caused anything else trying to access smb0 to get a device busy error. Rebooting actually hung the machine before the BIOS graphic was displayed... the lovely soft power switch wasn't working.. holding reset down for about a minute seemed to fix this. Also, the lm program (from your battery of examples) crashes with a SIGFPE, but some stuff from Nat'l Semi (some Win95 stuff anyways) seems to work.. but I'm not sure if anything is really hooked up, other than the SPD stuff. intpm0: Intel 82371AB Power management controller rev 0x02 on pci0.7.3 intpm0: I/O mapped 7000 ALLOCED IRQ 0 intr IRQ 9 enabled revision 0 intsmb0: Intel PIIX4 SMBUS Interface smbus0: System Management Bus on intsmb0 smb0: SMBus general purpose I/O on smbus0 intpm0: PM I/O mapped 8000 - alex To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: How the hell does one create a new bus?!
On Sun, 14 Feb 1999, Bill Paul wrote:
G. Alright, I give up: how does one create a new 'bus' layer?
By that I mean like /sys/dev/iicbus and /sys/dev/smbus. Yes, I've read
the code in these two directories, but I'm confused as to which parts
relate to the bus architecture in general and which parts are speficic
to the I2C and system management implementation.
From what I can tell, you need the following:
- foobus_if.m, a file which describes the functions that drivers for
devices attached to this kind bus can perform.
Each xxx_if.m file defines a set of functions which are implemented by
(some) drivers as you can see. This can be used in a couple of ways:
1. If a number of different types of the 'bus' hardware can have the same
set of child devices, one can define an interface which each of the
different bus device implements that can be called by the attached child
devices to hide the differences between the hardware. Code in the drivers
for child devices might look like this:
/*
* A ficitious 'probe' method for a device attached to a pci bus.
*/
int foo_probe(device_t dev)
{
/* Call a function in the PCI interface on our parent */
if (PCI_READ_CONFIG(device_get_parent(dev),
dev,
123, 4) == 456)
return ENXIO;
}
2. If all the devices attached to a bus can perform similar functions (but
implement them in different ways), an interface can be defined to describe
these functions. This interface can be called by any client which needs
to use the device. In this case, each driver would implement the method,
looking something like this:
/*
* Implementation of BOGUS_SET_LEVEL for the foo driver.
*/
static void
foo_set_level(device_t dev, unsigned int level)
{
...;
}
...
static device_method_t foo_methods[] = {
/* Device interface */
...;
/* Bogus interface */
DEVMETHOD(bogus_set_level, foo_set_level),
{ 0, 0 }
};
for an interface declaration (bogus_if.m) which looked like this:
INTERFACE bogus;
METHOD void set_level {
device_tdev;
unsigned intlevel;
};
- foobus.c and foobus.h
WHAT EXACTLY GOES IN HERE!?
- fooconf.c and fooconf.h
WHAT EXACTLY GOES IN HERE!?
There really isn't any naming convention for files which make up the
implementation of a driver (a bus is just a driver which implements the
BUS interface and which contains some kind of support for adding child
devices either by a PnP scan or by config(8) supplied tables).
For SMB, the implementation of the smbus driver seems to be in smbus.[ch],
with some kind of utility functions in smbconf.[ch].
To write a file with a 'minimum' driver (in this case a driver named 'foo'
attached to a bus named 'bogus'), you might have something like this:
struct foo_softc {
...;
};
static devclass_t foo_devclass;
#define FOO_SOFTC(unit) (struct foo_softc*) \
devclass_get_softc(foo_devclass, unit)
static int
foo_probe(device_t dev)
{
if (device exists)
return 0;
else
return ENXIO;
}
static int
foo_attach(device_t dev)
{
device_printf(dev, I'm alive\n);
return 0;
}
static device_method_t foo_methods[] = {
/* Device interface */
DEVMETHOD(device_probe, foo_probe),
DEVMETHOD(device_attach,foo_attach),
{ 0, 0 }
};
static driver_t foo_driver = {
foo, /* driver name */
foo_methods,/* implementation */
DRIVER_TYPE_NET,/* interrupt class */
sizeof(struct foo_softc), /* size of driver scratch */
};
DRIVER_MODULE(foo, bogus, foo_driver, foo_devclass, 0, 0);
- Some type of top level driver for the device which implements the
bus.
The implementation of a 'bus' device requires implementing a few extra
methods. Typically bus_print_child and bus_read_ivar are implemented by
most busses. Generic implementations for many of the bus functions are
provided (e.g. bus_generic_print_child) but these must be explicitly
specified in the method table (there is no automatic fallback mechanism).
Most bus drivers will add child devices to themselves during either probe
or attach and will call bus_generic_attach() from their attach method (or
just use bus_generic_attach directly instead of having their own
implementation of attach) to probe and
Re: Aladdin chipset SMBus support available!
On Sun, 14 Feb 1999, Nicolas Souchu wrote: On Sun, Feb 14, 1999 at 04:30:27PM -0500, Brian Feldman wrote: On spd I would get an error message, and if I ever did spd 1 it got as far as printing 128 bytes used, then erred out... rm alpm.o ; make CC=cc -DDEBUG I'll rm alpm.o; CC='cc -DDEBUG' make alpm.o; make, if that's what you mean. any difference? Yes: Feb 14 17:12:16 green /kernel: alpm: idle? STS=0x0 Feb 14 17:12:48 green last message repeated 380 times Feb 14 17:13:14 green last message repeated 5 times -- nso...@teaser.fr / nso...@freebsd.org FreeBSD - Turning PCs into workstations - http://www.FreeBSD.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message Brian Feldman_ __ ___ ___ ___ gr...@unixhelp.org _ __ ___ | _ ) __| \ http://www.freebsd.org/ _ __ ___ | _ \__ \ |) | FreeBSD: The Power to Serve! _ __ ___ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: How the hell does one create a new bus?!
The trouble is Doug, that until there IS a developer's guide, the only person capable if moving PCI and ISA to your scheme, is you. and as you pointed out.. you're short of time right now.. This stuff is very cryptic. On Mon, 15 Feb 1999, Doug Rabson wrote: I hope I've explained some things. There isn't a developer's guide as yet, I'm afraid and I don't really have time to write one :-(. Perhaps one of the people who has used the code might like to tackle it (or you might if you manage to struggle through implementing this thing...) If anyone wants to write such a guide, please go ahead and feel free to ask me any questions about how the thing is supposed to work. This email in itself has cleared up a few things.. but there is still a nead for a more general overview which should be read before getting to this level of detail.. julian To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: How to power off an ATX power supply machine on shutdown ?
On Sun, 14 Feb 1999, Alex Zepeda wrote: Note there's no mention of the limiting to version 1.1 or 1.0. Anyhow.. try rebooting with the flags set to 0x0 and see if that works. I assume that if you've got an ATX mobo, the BIOS is new enough that the APM implementation shouldn't be too buggy... I tried this; now it properly powers off. However, at bootup I get the message: Warning: / not unmounted properly Could it be because the system thinks everything is flushed, but something is still in the disk's write-cache? (If such a beast exists...) Is a delay needed between the final sync's and the actual power off? l...@neland.dk To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: How to power off an ATX power supply machine on shutdown ?
On Mon, 15 Feb 1999, Leif Neland wrote: Could it be because the system thinks everything is flushed, but something is still in the disk's write-cache? (If such a beast exists...) I think for whatever reason the computer is being powered off before it's finished syncing.. as in it doesn't check or care. Is a delay needed between the final sync's and the actual power off? Apparently so. There is/was a recently added sysctl for this purpose. Poke around in the archives. - alex To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Booting ELF kernel
I put the line /boot/loader in /boot.conf just like the docs said (http://www.freebsd.org/~peter/elfday.html). However, I couldn't enter -c to enter userconfig to configure the kernel. When I entered -c at the boot: prompt, it didn't go into UserConfig mode, but continued booting (without me being able to configure the kernel). Also, how should rc.conf be handled in the case of an ELF kernel? I still need to load the screensavers, which are LKMS, something AFAIK an ELF system doesn't support. This is handled by rc.conf. But what would I need to do in order to enable something like a screensaver with an ELF kernel? BTW, there's a line in /usr/src/etc/defaults/rc.conf that states rc.conf is part of rc_conf_files, which causes rc.conf to continue sucking in rc.conf in an infinite loop until the system runs out of file descriptors. Donn To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
hesiod/irs.conf and libc
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Is anyone currently working on, or planning to implement, hesiod passwd lookups (either through irs.conf, or nsswitch.conf, etc) in the getpw* and getgr* libc calls? - - -- Joey Miller Lead Programmer Inficad Communications 888.265.4423 -BEGIN PGP SIGNATURE- Version: PGP Personal Privacy 6.0.2 iQA/AwUBNsd8YdaopA9z+Kj8EQIchwCeL+g1rs6lzlvrqjds81TIcdcvWboAniPi W93+ydU7XACpfq5QygB7vEY6 =Eq8c -END PGP SIGNATURE- To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Booting ELF kernel
On Sun, Feb 14, 1999, Donn Miller put this into my mailbox:
I put the line /boot/loader in /boot.conf just like the docs said
(http://www.freebsd.org/~peter/elfday.html). However, I couldn't enter
-c to enter userconfig to configure the kernel. When I entered -c at
the boot: prompt, it didn't go into UserConfig mode, but continued
booting (without me being able to configure the kernel).
Hmm. Aren't you supposed to rewrite the boot blocks?
(Ideally you should check for an Invalid format! error at the top of your
screen, but this affects those who had initially used 2.2 disks)
This is done by disklabel -B da0 / wd0 / etc.
Also, how should rc.conf be handled in the case of an ELF kernel? I
still need to load the screensavers, which are LKMS, something AFAIK an
ELF system doesn't support. This is handled by rc.conf. But what would
I need to do in order to enable something like a screensaver with an ELF
kernel?
Use kld. lkm should be removed, as it's broken. (at least it is no matter
WHAT I try, as far as 3.0-{RELEASE,STABLE}/3.1-BETA goes)
BTW, there's a line in /usr/src/etc/defaults/rc.conf that states
rc.conf is part of rc_conf_files, which causes rc.conf to continue
sucking in rc.conf in an infinite loop until the system runs out of file
descriptors.
CVSup again. That was recently fixed.
Donn
-Chris
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: How the hell does one create a new bus?!
On Sun, 14 Feb 1999 16:44:37 -0800 (PST), Julian Elischer jul...@whistle.com said: The trouble is Doug, that until there IS a developer's guide, the only person capable if moving PCI and ISA to your scheme, is you. and as you pointed out.. you're short of time right now.. No, there are more people than just Doug. Certainly me (if I had time), Nicolas (if he had time), probably Andrew Gallatin since he's done a lot of work on the Alpha side of things (but he probably has no more time than the rest of us). There is a proper mailing list for this discussion, and we'd be happy to talk over any doco that someone should choose to write. Please take any followups to new-bus-a...@bostonradio.org. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same woll...@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
panics deciphering VMSTAT output
I've been trying to track down a regular, but not manually reproducible crash in 3.0-BETA (19990205). I can't get a crashdump due to a DSCHECK negative number bug. I think my swap space of 3+GB is too large for it. So, I've been having it send me the output of vmstat -m every 15 minutes to try to track it down. The couple of times I've seen the panic message on the console, it was typically, but not always: pipeinit: cannot allocate pipe - out of kvm It has been happening approximately every 6 hours on a heavily loaded server with 100+ chrooted daemons and NFS. So, in short, so that I can compare my vmstat outputs to the one I captured 3 minutes before the last crash, can anyone tell me what the vmstat entries mean? :) A quick legend or tutorial would be helpful, and I'll turn it into a FAQ for the documentation project, too. -Troy Cobb Circle Net, Inc. http://www.circle.net To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Suggestion for elf upgrade
Yesterday I did an upgrade from 3.0-Release to 3.1-beta. I did make world, then I made the kernel. At the end of the make kernel, I got a message about the kernel being elf!!! Bad timing to find out about this - I was told to look at http://www.freebsd.org/~peter/elfday.html and by this time, the code mismatch between the binary executables and the kernel made netscape unusable. Good thing I wasn't upgrading from 2.2.x, maybe then I could not have even installed lynx or Mosaic to get the info I needed. Well, I did get it figured out. But I have one suggestion for the web page http://www.freebsd.org/~peter/elfday.html It told me that I needed new bootblocks. I think a paragraph explanation of what bootblocks is would have helped a very great deal. As it was it was like telling me to wear a nuffle on my head when it is cold. Like, what is a nuffle? So what is a bootblock? I did figure out enough to get it to work (I am guessing that a bootblock is some code at the beginning of each slice that is loaded by booteasy). Second, instead of putting the warning message after making the kernel, how about putting the message at the beginning of both make world and making the kernel (and make installworld etc), so for example, to make world one has to type: make -DYES_I_REALLY_DO_KNOW_ABOUT_BOOTBLOCKS_AND_SUCH_LIKE world Maybe after a couple of years, one can get rid of this requirement. Yes, I do realise that I was out of touch not knowing about elf kernels. But there will be lots like me, and we should make it as painless as possible, since everybody who upgrades has to face this issue. Finally, I did get it all to work, and I am really pleased with what I have. It was my first experience at making FreeBSD from the source. I learned a lot. -- Stephen Montgomery-Smith step...@math.missouri.edu 307 Math Science Building step...@showme.missouri.edu Department of Mathematics step...@missouri.edu University of Missouri-Columbia Columbia, MO 65211 USA Phone (573) 882 4540 Fax (573) 882 1869 http://math.missouri.edu/~stephen To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Weird piecemeal reads over socketpair() pipe breaks up small writes into even smaller reads.
This isn't a 'bug', per say, but it bothers me that a small 128 byte
write() is being somehow broken apart into two smaller read()s. It isn't
efficient, and it shouldn't be happening.
Breaking apart write() into read()s would be a BUG :-).
Breaking apart read() into read()s seems to be caused by my rescheduling
changes in kern_subr.c.
fcntl(fds[0], F_SETFL, O_NONBLOCK);
Here you permit non-atomic reads for block sizes = PIPE_BUF, so you should
be prpared to get them.
if (fork() == 0) {
sleep(1);
write(fds[1], buf, sizeof(buf));
_exit(1);
}
The write() apparently begins by copyout()ing only 96 bytes, and if the
need_resched() condition is true, then the process doing the write will
block.
select(fds[0] + 1, rfds, NULL, NULL, NULL);
while ((n = read(fds[0], buf, sizeof(buf))) 0)
printf(read %d\n, n);
return(0);
When the writer blocks, the reader runs and uses a buggy loop to read
only the first chunk of input.
On an otherwise idle system, the need_resched() condition seems to be
true always. I would have expected the synchronisation provided by the
sleep(1) to bias need_resched() in the opposite direction. A reschedule
has been done, normally just after the previous hardclock() call, just
before the writer wakes up, so another one should not be done soon
(until after the next hardclock() call).
Bruce
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: XXX: driver didn't set ifq_maxlen (was Re: Disk locks and weird things)
On Mon, 15 Feb 1999, Kris Kennaway wrote: I see this on lo0 every time I boot - is this a problem in 3.1 as well, or just -current? It's probably not good to leave these messages in 3.1 as it ships, if the former. FWIW I'm seeing this at bootup now: ep0 XXX: driver didn't set ifq_maxlen lo0 XXX: driver didn't set ifq_maxlen changing root device to wd0s1a link_elf: symbol grow undefined Ahh well guess I get to buildworld now... - alex To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Weird piecemeal reads over socketpair() pipe breaks up small writes into even smaller reads.
:
:This isn't a 'bug', per say, but it bothers me that a small 128 byte
:write() is being somehow broken apart into two smaller read()s. It isn't
:efficient, and it shouldn't be happening.
:
:Breaking apart write() into read()s would be a BUG :-).
:
:Breaking apart read() into read()s seems to be caused by my rescheduling
:changes in kern_subr.c.
:
:fcntl(fds[0], F_SETFL, O_NONBLOCK);
:
:Here you permit non-atomic reads for block sizes = PIPE_BUF, so you should
:be prpared to get them.
Well of course. Why do you think I said This isn't a 'bug', per say,
eh?
:if (fork() == 0) {
:sleep(1);
:write(fds[1], buf, sizeof(buf));
:_exit(1);
:}
:
:The write() apparently begins by copyout()ing only 96 bytes, and if the
:need_resched() condition is true, then the process doing the write will
:block.
:
:select(fds[0] + 1, rfds, NULL, NULL, NULL);
:while ((n = read(fds[0], buf, sizeof(buf))) 0)
:printf(read %d\n, n);
:return(0);
:
:When the writer blocks, the reader runs and uses a buggy loop to read
:only the first chunk of input.
:
:Bruce
Ok, so perhaps tweeking the rescheduling changes in kern_subr.c to
not try to do it in the first few thousand bytes copied is the solution?
Would you like to do it or should I? This isn't high priority but it
should definitely not be rescheduling after the first 96 bytes. That's
just a waste of cpu.
-Matt
Matthew Dillon
dil...@backplane.com
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: Weird piecemeal reads over socketpair() pipe breaks up small writes into even smaller reads.
How about a 1-line fix: Index: uipc_usrreq.c === RCS file: /home/ncvs/src/sys/kern/uipc_usrreq.c,v retrieving revision 1.37 diff -u -r1.37 uipc_usrreq.c --- uipc_usrreq.c 1998/10/25 17:44:51 1.37 +++ uipc_usrreq.c 1999/02/15 07:09:12 @@ -348,7 +348,8 @@ unp-unp_conn-unp_mbcnt = rcv-sb_mbcnt; snd-sb_hiwat -= rcv-sb_cc - unp-unp_conn-unp_cc; unp-unp_conn-unp_cc = rcv-sb_cc; - sorwakeup(so2); + if (!(flags PRUS_MORETOCOME)) + sorwakeup(so2); m = 0; #undef snd #undef rcv Unfortunately, this apparently unearths a bug in the ?:?:?: expression in sosend(), so try this diff too. Index: uipc_socket.c === RCS file: /home/ncvs/src/sys/kern/uipc_socket.c,v retrieving revision 1.51 diff -u -r1.51 uipc_socket.c --- uipc_socket.c 1999/01/20 17:45:22 1.51 +++ uipc_socket.c 1999/02/15 07:09:25 @@ -388,6 +405,7 @@ register long space, len, resid; int clen = 0, error, s, dontroute, mlen; int atomic = sosendallatonce(so) || top; + int pru_flags; if (uio) resid = uio-uio_resid; @@ -518,21 +536,24 @@ } while (space 0 atomic); if (dontroute) so-so_options |= SO_DONTROUTE; + pru_flags = 0; + if (flags MSG_OOB) + pru_flags |= PRUS_OOB; + /* +* If the user set MSG_EOF, the protocol +* understands this flag and nothing left to +* send then set PRUS_EOF. +*/ + if ((flags MSG_EOF) + (so-so_proto-pr_flags PR_IMPLOPCL) + (resid = 0)) + pru_flags |= PRUS_EOF; + /* If there is more to send set PRUS_MORETOCOME */ + if (resid 0 space 0) + pru_flags |= PRUS_MORETOCOME; s = splnet(); /* XXX */ error = (*so-so_proto-pr_usrreqs-pru_send)(so, - (flags MSG_OOB) ? PRUS_OOB : - /* -* If the user set MSG_EOF, the protocol -* understands this flag and nothing left to -* send then use PRU_SEND_EOF instead of PRU_SEND. -*/ - ((flags MSG_EOF) -(so-so_proto-pr_flags PR_IMPLOPCL) -(resid = 0)) ? - PRUS_EOF : - /* If there is more to send set PRUS_MORETOCOME */ - (resid 0 space 0) ? PRUS_MORETOCOME : 0, - top, addr, control, p); + pru_flags, top, addr, control, p); splx(s); if (dontroute) so-so_options = ~SO_DONTROUTE; Bill To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
