Subject: Linux-Development Digest #527 From: Digestifier To: Linux-Development@senator-bedfellow.MIT.EDU Reply-To: Linux-Development@senator-bedfellow.MIT.EDU Date: Mon, 7 Mar 94 20:13:12 EST Linux-Development Digest #527, Volume #1 Mon, 7 Mar 94 20:13:12 EST Contents: Re: Mac FS, anyone? (Jonathan Magid) TTY overruns cost money. (Nemosoft Unv.) Re: Why not put cluster diffs in nominal kernel before 1.0? (Matthias Urlichs) Re: Amiga FileSystem, Anyone? (Matthias Urlichs) Re: Screensaver w/ power save ? (Matthias Urlichs) Re: QUERY: Assembler Code Perversion (Rob Janssen) Re: Amiga FileSystem, Anyone? (Rob Janssen) Re: Amiga FileSystem, Anyone? (Rob Janssen) Re: eth0: transmit timed out in PL15h (Chris Mathes) Severe installation problems with Slackware 1.1.2 (David Kastrup) Re: Specialix driver (Jay Denebeim P025) ---------------------------------------------------------------------------- From: jem@sunSITE.unc.edu (Jonathan Magid) Subject: Re: Mac FS, anyone? Date: 7 Mar 1994 15:17:12 GMT In article , Kayvan Sylvan wrote: >Does anyone know a way I can read a Mac 1.4MB floppy on Linux? My Mac >is an old Mac Plus (720K floppy drive) and it's connected to my Linux >box. If I can read files onto Linux, I can just suck them over the >line to the Mac. There is a program to do this under Linux, you can get it , pclink@qus102.qld.tne.oz.au (Rick) writes: > > Thanks for the fix. Have you come across a fix for a kernel panic that > says "Free list contains shared buffers"? I got this last night - the > system was relatively quiet, having finished a fairly large compile > (lots of swapping) about 15 minutes earlier. > Nope. I saw it today, too. :-( -- Die Struktur einer ambivalenten Beziehung beeintraechtigt das visuelle und kognitive Wahrnehmungsvermoegen extrem. -- Matthias Urlichs \ XLink-POP N|rnberg | EMail: urlichs@smurf.noris.de Schleiermacherstra_e 12 \ Unix+Linux+Mac | Phone: ...please use email. 90491 N|rnberg (Germany) \ Consulting+Networking+Programming+etc'ing 42 Click here. ------------------------------ From: urlichs@smurf.noris.de (Matthias Urlichs) Subject: Re: Amiga FileSystem, Anyone? Date: 7 Mar 1994 22:51:45 +0100 In comp.os.linux.development, article , bdwheele@silver.ucs.indiana.edu (Sprag Johnson) writes: > > Um.....if the mac doesn't use a 'standard format' how is it that I can > read mac (1.44) disks in my pc? Granted, I had to use a shareware reader to > do it, but the hardware is capable.... The Mac uses the "standard format" for HD disks only. DD floppies are written in GCR, which is unreadable with MFM controllers. -- How many people work here? Oh, about half. -- Matthias Urlichs \ XLink-POP N|rnberg | EMail: urlichs@smurf.noris.de Schleiermacherstra_e 12 \ Unix+Linux+Mac | Phone: ...please use email. 90491 N|rnberg (Germany) \ Consulting+Networking+Programming+etc'ing 42 Click here. ------------------------------ From: urlichs@smurf.noris.de (Matthias Urlichs) Subject: Re: Screensaver w/ power save ? Date: 7 Mar 1994 22:57:58 +0100 In comp.os.linux.development, article , hm@seneca.ix.de writes: > A kernel config variable would be good IMHO because I don't know what > ordinary monitors do without sync pulses (snow?). > Ordinary monitors should be blank in that case. After all, no sync pulses are not distinguishable from a monitor that isn't plugged into the video card in the first place. Snow is just noise. No source for the noise (like a tuner between stations, which is where "normal" TV noise comes from), therefore no snow. -- The universe is one of God's thoughts. -- Friedrich Schiller -- Matthias Urlichs \ XLink-POP N|rnberg | EMail: urlichs@smurf.noris.de Schleiermacherstra_e 12 \ Unix+Linux+Mac | Phone: ...please use email. 90491 N|rnberg (Germany) \ Consulting+Networking+Programming+etc'ing 42 Click here. ------------------------------ From: rob@pe1chl.ampr.org (Rob Janssen) Subject: Re: QUERY: Assembler Code Perversion Date: Mon, 7 Mar 1994 20:11:30 GMT Reply-To: pe1chl@rabo.nl In <1994Mar6.102501.1965@penrij.UUCP> soup@penrij.UUCP (John R. Campbell) writes: >I'm willing to bet that this is NOT the right group to post this Question >(but I will anyway). >I've been handed a sh*tload of MASM source code for the 386/486 (SCO UNIX) >and I need to convert it to a _REAL_ assembler (GAS on Linux, of course). >Anybody have any dirty tricks??? Write a translator using UNIX tools (e.g. sed, awk, yacc/lex or whatever seems most appropriate) >It generates that GodForsaken "x.out" format favored by MicroSloth which >NOBODY can disassemble (If only "sourcer" could generate REAL assembler). That barely seems to the point when you want to translate the source... Rob -- ========================================================================= | Rob Janssen | AMPRnet: rob@pe1chl.ampr.org | | e-mail: pe1chl@rabo.nl | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU | ========================================================================= ------------------------------ From: rob@pe1chl.ampr.org (Rob Janssen) Subject: Re: Amiga FileSystem, Anyone? Date: Mon, 7 Mar 1994 20:13:56 GMT Reply-To: pe1chl@rabo.nl In bdwheele@silver.ucs.indiana.edu (Sprag Johnson) writes: >In <1994Mar6.130716.5368@pe1chl.ampr.org> rob@pe1chl.ampr.org (Rob Janssen) writes: >>In dholland@husc7.harvard.edu (David Holland) writes: >>>The strange stuff the trackdisk.device does should be possible with PC >>>hardware, unless that hardware is even less capable than I thought. If >>>the Amiga does something else, like write more tracks than the average >>>PC drive can access, I don't know about it. >>The PC has a specialized floppy disk controller that understands and >>handles the industry-standard MFM format of formatting diskettes. >>The Amiga does not use that standard format (and neither does the Mac) > Um.....if the mac doesn't use a 'standard format' how is it that I can >read mac (1.44) disks in my pc? Granted, I had to use a shareware reader to >do it, but the hardware is capable.... > Brian The newer macs (those that can write 1.44 disks) have PC-compatible disk controller hardware as well. The older (800K) disks cannot be read on a PC. Rob -- ========================================================================= | Rob Janssen | AMPRnet: rob@pe1chl.ampr.org | | e-mail: pe1chl@rabo.nl | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU | ========================================================================= ------------------------------ From: rob@pe1chl.ampr.org (Rob Janssen) Subject: Re: Amiga FileSystem, Anyone? Date: Mon, 7 Mar 1994 20:21:12 GMT Reply-To: pe1chl@rabo.nl In dholland@husc7.harvard.edu (David Holland) writes: >rob@pe1chl.ampr.org's message of Sun, 6 Mar 1994 13:07:16 GMT said: > > Classification of 'more or less capable' is entirely yours. I would say > > the PC disk controller is more capable, in that it handles tasks that > > need to be done in software on the Amiga and Mac. >Hmm, I'd say "capable" means "able to accomplish things". It seems to >me that drive hardware that can read a wider range of disk formats is >more capable. This is what the end user sees; only the BIOS or device >driver writer sees how much internal processing is done. I dunno. >Meaningless point to argue. I don't agree with you. But indeed it is meaningless to argue about. > > >Yes, I have. It's amazing that it can be done at all, however > > >poorly... :-) > > > > Please explain what is poor about it? > > This seems to be just a general case of DOS-bashing. When you don't > > know what you are talking about, please don't. >The network redirector is a mess, not well documented, and notoriously >difficult to cope with. Why do you think we don't see alternate >filesystems (such as for Mac floppies) for the PC that use it? All we >have is a few network packages from big companies with lots of >resources, like Novell and Sun. Microsoft's policy is to not give out documentation about programming interfaces except the most required ones. While I agree that this is not good, I don't agree that we don't see alternate filesystems. Linux' dosemu *does* have a filesystem redirector. >Yes, it does work, mostly. Why do various ordinary tools refuse to >cooperate with network drives? This problem is not limited to >low-level disk utilities or anything, you know. Because they written with bad assumptions. Period. Programs that do only file I/O have no problems whatsoever with redirected drives. Those that want to be 'clever' will lose. E.g: those stupid N***** tools that insist on scanning the entire directory structure of a disk before even presenting a first user choice. And when they have scanned part of the 40000-file network disk they run out of memory and bomb out. lose lose... > > (I am no DOS fan. not at all, even. but saying things that just plainly > > aren't true is not the way to handle even DOS) >Are you absolutely sure I'm the one who doesn't know what he's talking >about? :-) :-) I still think so. Rob -- ========================================================================= | Rob Janssen | AMPRnet: rob@pe1chl.ampr.org | | e-mail: pe1chl@rabo.nl | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU | ========================================================================= ------------------------------ From: chris@metter.fmpmis.metter.com (Chris Mathes) Subject: Re: eth0: transmit timed out in PL15h Date: Mon, 7 Mar 1994 21:37:21 GMT becker@super.org (Donald J. Becker) writes: >In article <2l58o0$mv7@senator-bedfellow.mit.edu>, >Erik Nygren wrote: >>I've been getting messages like: >> >>Mar 3 11:16:50 foundation kernel: eth0: transmit timed out, tx_status 00 status >> 2000. >I think I have a fix for this problem. >[fix deleted.] >If anyone still encounters problems after applying this patch please let me >know. Yup, transmit timeouts are now a thing of the past. But what does this mean: "eth0: Missed interrupt, status then 2011 now 2011 Tx 00 Rx 384a." This happens once after a cold or warm boot; seemingly the first time packets are sent out after booting. Linux bravo pre-1.0 #1 Mon Mar 7 11:57:20 GMT 1994 i386 -Chris -- Chris Mathes, Metters Industries, Inc. UUCP: {..!}uunet!metter!chris Tel:(703)418-0323 INET: chris@metter.com "The Tao of Programming flows far away and returns on the wind of morning."-TToP ------------------------------ From: dak@hathi.informatik.rwth-aachen.de (David Kastrup) Subject: Severe installation problems with Slackware 1.1.2 Date: 7 Mar 1994 23:15:06 GMT Of course here several factors were at work... At first, the documentation was lacking any information as to what interrupts and I/O-addresses were tried for what. (I have a 386SX16 here, TMC885 SCSI controller, WD8003 Network card, 1.2meg boot, 1.4meg second floppy). As a result, I lost one day, until I found out that changing the default I/O-address of the WD8003 Card to 300h from the default of 280h would allow booting. There is no conceivable address conflict, but the system hung after displaying the shared memory address of the Network card (0xd0000, regardless of I/O address). Furthermore, tty12 in the 1_2meg directory was simply unsuitable for bootstrapping. One had to rdev -r the boot disk for a ramdisk size of 1440, and had to use the boot option of ramdisk root=/dev/fd1, so that one could boot from the second floppy, where the root image was better. The boot process (while it is displaying `loading ramdisk' on the boot disk) is painstakingly slow, as the code does not seem to be able to load consecutive sectors on my machine in the same disk revolution. Formatting the boot disk with a skew would help, but alas, neither DOS nor Linux offers this. fdisk ing the hard disk was a complicated process. Because of problems with the real sector/cylinder numbers (1780 cylinders led to lots of warnings) I decided to enter the BIOS fake numbers (64 heads, 32 sectors, 323 cylinders instead of 7,54,1780). So far, so well. However, fdisk complained that I had to specify cyl, sec, head in the special functions menu. That done everything worked. Unfortunately, however, fdisk -l is called several times in the setup menu. Not given the cyl, sec, head values, it will list the first line and then abort with a floating point exception, as it assumes them to be 0,0,0, and seems to be wanting to calculate something. This stops the setup short in its tracks. I am now going to replace fdisk with a shell script which will, when called with -l, just reproduce the appropriate output, and if called with other options, will call the original. This is going to be still a bunch of work. The manual entry to fdisk says that the real info to the command is to be found in fdisk.README, which should be with every distribution. It is not (strictly speaking, as I have the system not yet running, this applies to the older version on the other computer I consulted, I believe Slackware 1.1.0. Also here are a considerable amount of man pages with extension .z, which man will probably not find). This is all particularly frustrating as on the other machine Slackware 1.1.0 installed like a charm (other HD controller). On this machine, however, I've been fighting for several days now, but will hopefully get through soon. I want to especially note that none of all of these problems was properly treated in any HOWTO or README. Especially hard to conceive was that one had to set the ramdisk size to 1440 by first mounting the bootdisk, doing an rdev -r /vmlinuz 1440 ON ITS /vmlinuz FILE, but had to specify root=/dev/fd1 on the boot prompt instead. It's been a long time since I have felt that stupid. -- David Kastrup dak@pool.informatik.rwth-aachen.de Tel: +49-241-72419 Fax: +49-241-79502 Goethestr. 20, D-52064 Aachen ------------------------------ From: denebeim@bnr.ca (Jay Denebeim P025) Subject: Re: Specialix driver Date: Mon, 7 Mar 1994 21:39:31 GMT In article <1994Mar1.143313.25803@swan.pyr> iiitac@swan.pyr (Alan Cox) writes: >It would be OK I guess, not ideal and I don't like it - I certainly wouldn't >buy the card. Why? Does this mean you've got the source to your BIOS ROM? How about the ROM on your video card? (hey, if you've got a Diamond, I bet there's a bunch of people who would like to talk to you) If not, why is this card any different? I don't know anything about the card that you ended up with, does it have an on-board processor? Do you have the source code for that, or do you just know what its interface is? If its the latter you're getting exactly what the guy from digiboard is offering. The fact that they've got eeprom/static ram on their board is a nice feature IMO. Heck, to get around this whole mess, why doesn't the original author just ship complete source, all you have to do is provide a program that takes the files on the disk that Digiboard products come with and make a .o or .a file out of it. Easy. Now, all the source applicable to Linux is available. You now won't even need to give the object code to people who didn't buy the hardware. Also, I really hope that Digiboard does this, I have to use a stand-alone IMAC instead of a digiboard card because they don't have linux drivers for it. An application we have here at work could be using a Linux box with a bunch of digiboard cards in it rather than a smaller stack of IMACs if this were the case. Jay -- Jay Denebeim Address: UUCP: duke!wolves!deepthot!jay Internet: jay@deepthot.cary.nc.us BBS:(919)-233-9937 VOICE:(919)-233-0776 ------------------------------ ** FOR YOUR REFERENCE ** The service address, to which questions about the list itself and requests to be added to or deleted from it should be directed, is: Internet: Linux-Development-Request@NEWS-DIGESTS.MIT.EDU You can send mail to the entire list (and comp.os.linux.development) via: Internet: Linux-Development@NEWS-DIGESTS.MIT.EDU Linux may be obtained via one of these FTP sites: nic.funet.fi pub/OS/Linux tsx-11.mit.edu pub/linux sunsite.unc.edu pub/Linux End of Linux-Development Digest ******************************