From: Digestifier To: Linux-Admin@senator-bedfellow.mit.edu Reply-To: Linux-Admin@senator-bedfellow.mit.edu Date: Sun, 7 Nov 93 17:13:42 EST Subject: Linux-Admin Digest #145 Linux-Admin Digest #145, Volume #1 Sun, 7 Nov 93 17:13:42 EST Contents: Tape drives that connect to floppy controller (Don &) Re: UUGETTY respawning too rapidly? (Christian Henry) Re: fsck and .99.13p.. (Daniel Linder) SMail/Elm lock up (LMRusu) UltraStor 24F/34F anyone? (Marvin L. Taylor) Re: SMail/Elm lock up (Daniel Y.H. Wong) Re: Quota -1.1 (Marco van Wieringen) IBM-AMBRA (Rohit Sharma) ---------------------------------------------------------------------------- From: bashford@griffy.scripps.edu (Don &) Subject: Tape drives that connect to floppy controller Date: Sun, 7 Nov 1993 09:21:49 GMT I would like to get a tape drive for my linux system and I do not have a SCSI card now. It looks like a SCSI card + SCSI tape drive combination will cost over $700, but for less than $200 there are tape drives that connect directly to the floppy controller. Can I use these floppy-connecting tape drives with linux? The brands I have seen are: Colorado Jumbo 250 Conner Tape Stor 250MB Internal System QIC-80 Both of them claim to support "UNIX/XENIX" with "optional software." I have looked at the old FAQ and at the hardware and SCSI HOWTOs but I find no mention of tape drives of this kind. I'd appreciate advice on using them with linux Thanks, Don Bashford bashford@scripps.edu ------------------------------ From: henryc@reality.UUCP (Christian Henry) Subject: Re: UUGETTY respawning too rapidly? Date: Sun, 7 Nov 1993 04:44:54 GMT Reply-To: henryc@io.org In article , PERUCCI, PHILIP A. wrote: >I am currently trying to get uugetty (getty_ps) working with >Slackware 1.0.5. > >With everything configured, at boot time I get a message about > >"c7: respawning too rapidly: disabled for 5 minutes" > >(note that the message is not verbatim - it is from memory). Anyone >know what might cause this? I know it takes some doing to get this >working... > > 2: Must echo be DISABLED on the modem (Q and E AT commands)? With some systems, it seems to depend upon which device driver you access for your comm port. Personally, I have echo on and ALL result codes enabled (in other words, my personal answer to your question is a definite "NO"). > 3: What about the DTR modem response (&D AT command)? I'd suspect that AT&D3 would be the safest. If your modem is as strange as mine, you'll have to settle for AT&D2 (When I use &D3, my modem refuses to use v.42bis after a disconnection until I send an ATZ again (but that's another story... :-) )). >I have all the READMEs, the HOWTO, and the NET-book (doc project) - >and I read them. Read man pages for getty and gettydefs too. > >Still I am missing something... Try using /dev/cua0 instead of /dev/ttyS0. It seems to cause less problems for some people (in fact, I've never been able to use /dev/ttyS? successfully for over 10 minutes straight (!)). As an example, here's a copy of my uugetty.cua0 : =============================================================================== SYSTEM=reality # naturally, this will be different for you ;-> VERSION=/proc/version LOGIN=/bin/login ISSUE=/etc/issue # unrelated to your problems, but it _is_ in mine :-/ CLEAR=NO # preferance. I, personally, don't like the screen # clearing at the point where this would cause it # to occur. HANGUP=YES # this one's well documented. INIT="" ATZ\r OK ATV1Q0M0&C1&D2\r OK ALTLINE=ttyS0 # Just because I don't use /dev/ttyS0 doesn't mean I ALTLOCK=ttyS0 # (or someone else) will never accidentally try to # grab it. INITLINE=cua1 TIMEOUT=60 DELAY=1 # Longer "Login incorrect" delays just serve to # royally p*ss me off when I'm having one of my # bad typing days. :-) WAITFOR=RING # Why depend upon auto-answer when you don't have to? CONNECT="" ATA\r CONNECT\s\A # Actually, I could care less about what # follows the "CONNECT" message, becuase I'm # using a locked bps rate anyway. =============================================================================== In addition, my /etc/gettydefs and /etc/gettytab are almost exactly the defaults given in the Slackware 1.0.4 (most likely 1.0.5 too) installation. The only change I recall making to these files was uncommenting the 38400# line if it was commented out. With this configuration, I'm able to use uugetty well along with UUCP 1.04 (?) and Kermit. See if this helps you any. :-) -- | Christian Henry... | "If there's a new way, | | ...North York, Ontario | I'll be the first in line, | | | But it better work this time!" | | e-mail: henryc@io.org | - Megadeth, "Peace Sells", 1986 | ------------------------------ From: dlinder@cse.unl.edu (Daniel Linder) Crossposted-To: comp.os.linux.help Subject: Re: fsck and .99.13p.. Date: 7 Nov 1993 14:54:03 GMT Hello! Thanks for all the feed back on my perpetual fsck problem. To recap, whenever I rebooted with the new 0.99.13p kernel (after just un-tarring and putting it in LILO) it would always run the full fsck on the partition, even with a clean shutdown. For the record, there are two ways of getting a clean boot--both set the filesystem to READONLY when booting. The first way is to use "rdev" on the zImage file with the "-R 1" option. The way I finally achieved the clean boot is by putting the "read-only" word option in the /etc/lilo/config file and re-run lilo's install utility. Again, thanks for all the responses and a GREAT OS! Dan -- | Dan Linder - Computer Sci/Engineer| "If there's nothing wrong with me, | | dlinder@cse.unl.edu - Senior | there must be something wrong with | | "Get LINUX and drop DOS" | the universe!" Bev Crusher-Remember Me | | Disclaimer: My university does not listen to me, why would I speak for them? | ------------------------------ From: rusu@eniac.seas.upenn.edu (LMRusu) Subject: SMail/Elm lock up Date: 7 Nov 93 07:13:39 GMT Hello Linuxers, I'm having a slight problem with SMail/Elm: when I try to send a message bigger than ~10k from my Linux box the hole thing (the X screen) just locks up solid. The only way I can get out is by rebooting the machine. Any message under 10k will be sent just fine and I can receive messages of any size. If I try to send a message > 10k the machine locks up solid and after a reboot I can see the message sitting in /usr/spool/smail/input and nothing about it in /usr/spool/smail/error or log files. I have enough free disk space and I'm using SLIP with pl13p. Any ideea what could be causing this?! Any pointers would be very appreciated! Thanks, Larry -- ------------------------------ Crossposted-To: comp.os.linux.development From: marvint@csn.org (Marvin L. Taylor) Subject: UltraStor 24F/34F anyone? Date: Sun, 7 Nov 1993 18:25:07 GMT Greetings all, I am hoping that someone here can help me with the problems I'm having with LINUX. My primary problem is that I cannot rebuild the kernel. I am having other problems, too, but these may clear up if I manage to rebuild the kernel properly. It's difficult for me to check/post-to this news group (plus it costs $$'s), so I'll try to be really verbose and give all the information one might ever need to fix the problem. Fundamentally, trying to get a kernel that will support the 24F (and for the 34F, for my roommate's new PC), has proven to be a chore. The sources I've obtained won't compile (see below)! HARDWARE INFO (of note): AMI 486DX/33, EISA Diamond SpeedStar/1MB (ISA) UltraStor 24F (EISA) 2 HD's (Both are SCSI-2, Addr's 0, 1), 2 FD's (3.5", 5.25"), NEC-84 CD-ROM BOOT SEQUENCE: OS/2 2.1 Boot Manager boots, selects LINUX partition. LILO boots to the /dev/sda3 (180MB ext2). Applicable contents of the LILO config file are shown. Note that the "/Image" is an SLS 1.01 version of the kernel that I'm booting, "/zImage" is the SLS 1.03 version I actually hacked on enough to manage a compile/load (but won't boot). boot = /dev/sda3 install = /etc/lilo/boot.b delay = 100 compact image = /Image root = /dev/sda3 vga = 3 label = 1 image = /zImage root = /dev/sda3 vga = normal label = 3 KERNEL SOURCES: I had been running SLS release 1.01 for a number of months (it took me a while after I first downloaded to get an US-24F boot image so I could install). At this point, I could rebuild the kernel without problems, using the 1.7 version of the UltraStor ALPHA code. Then, in August, I grabbed the SLS 1.03 files from TSX-11. I also grabbed the UltraStor sources and I found they would not compile. I *think* that the UltraStor sources that I got with 1.03 would also not compile. In any event, I tried again this weekend -- I grabbed new files off of TSX-11 yesterday: /pub/linux/sources/system/linux-0.99.13.tar.gz /pub/linux/ALPHA/scsi/ultrastor.tar.z /pub/linux/ALPHA/scsi/ultrastor-1.11d.tar.gz I re-installed them in the above order, and then ran: cd /linux make dep make clean make zImage The compile failed under the "linux/kernel/blk_drv/scsi" directory, with the following errors: gcc -D__KERNEL__ -Wall -Wstrict-prototypes -O6 -fomit-frame-pointer \ -m486 -c hosts.c -o hosts.o hosts.c:113: `MAX_SCSI_HOSTS' undeclared here (not in a function) hosts.c:113: conflicting types for `host_busy' hosts.h:182: previous declaration of `host_busy' hosts.c:114: `MAX_SCSI_HOSTS' undeclared here (not in a function) hosts.c:115: `MAX_SCSI_HOSTS' undeclared here (not in a function) hosts.c:115: conflicting types for `scsi_device_type' hosts.h:193: previous declaration of `scsi_device_type' hosts.c:116: `MAX_SCSI_HOSTS' undeclared here (not in a function) hosts.c:117: `MAX_SCSI_HOSTS' undeclared here (not in a function) hosts.c:117: conflicting types for `host_queue' hosts.h:189: previous declaration of `host_queue' hosts.c:118: `MAX_SCSI_HOSTS' undeclared here (not in a function) hosts.c:118: variable `host_wait' has initializer but incomplete type hosts.c:118: conflicting types for `host_wait' hosts.h:191: previous declaration of `host_wait' hosts.c:119: `MAX_SCSI_HOSTS' undeclared here (not in a function) hosts.c: In function `scsi_init': hosts.c:128: `MAX_SCSI_HOSTS' undeclared (first use this function) hosts.c:128: (Each undeclared identifier is reported only once hosts.c:128: for each function it appears in.) make[3]: *** [hosts.o] Error 1 gcc -D__KERNEL__ -Wall -Wstrict-prototypes -O6 -fomit-frame-pointer \ -m486 -c scsi.c -o scsi.o scsi.c: In function `scsi_times_out': scsi.c:433: warning: zero-length format string scsi.c:435: warning: zero-length format string scsi.c: In function `scsi_do_cmd': scsi.c:671: warning: zero-length format string scsi.c: In function `scsi_done': scsi.c:900: warning: format argument is not a pointer (arg 3) scsi.c:1061: warning: zero-length format string gcc -D__KERNEL__ -Wall -Wstrict-prototypes -O6 -fomit-frame-pointer \ -m486 -c scsi_ioctl.c -o scsi_ioctl.o gcc -D__KERNEL__ -Wall -Wstrict-prototypes -O6 -fomit-frame-pointer \ -m486 -c constants.c constants.c:11: warning: `reserved' defined but not used constants.c:13: warning: `vendor' defined but not used gcc -D__KERNEL__ -Wall -Wstrict-prototypes -O6 -fomit-frame-pointer \ -m486 -c st.c -o st.o gcc -D__KERNEL__ -Wall -Wstrict-prototypes -O6 -fomit-frame-pointer \ -m486 -c sd.c -o sd.o sd.c: In function `requeue_sd_request': sd.c:440: warning: zero-length format string sd.c: In function `sd_init_onedisk': sd.c:794: warning: too many arguments for format gcc -D__KERNEL__ -Wall -Wstrict-prototypes -O6 -fomit-frame-pointer \ -m486 -c sd_ioctl.c -o sd_ioctl.o gcc -D__KERNEL__ -Wall -Wstrict-prototypes -O6 -fomit-frame-pointer \ -m486 -c sr.c -o sr.o sr.c: In function `requeue_sr_request': sr.c:403: warning: zero-length format string gcc -D__KERNEL__ -Wall -Wstrict-prototypes -O6 -fomit-frame-pointer \ -m486 -c sr_ioctl.c -o sr_ioctl.o gcc -D__KERNEL__ -Wall -Wstrict-prototypes -O6 -fomit-frame-pointer \ -m486 -c ultrastor.c -o ultrastor.o ultrastor.c: In function `ultrastor_14f_detect': ultrastor.c:377: warning: implicit declaration of func `check_region' ultrastor.c:440: warning: implicit declaration of func `snarf_region' ultrastor.c: In function `ultrastor_abort': ultrastor.c:927: warning: control reaches end of non-void function ultrastor.c: In function `ultrastor_reset': ultrastor.c:984: warning: control reaches end of non-void function ultrastor.c: In function `ultrastor_interrupt': ultrastor.c:1014: warning: unsigned int format, pointer arg (arg 2) ultrastor.c:1028: warning: unsigned int format, pointer arg (arg 4) ultrastor.c:1057: warning: unsigned int format, pointer arg (arg 3) ultrastor.c:1108: warning: unsigned int format, pointer arg (arg 3) make[3]: Target `scsi.a' not remade because of errors. At this point, I added the following line to "scsi.h": #define MAX_SCSI_HOSTS 10 And the compile completed successfully, but with the warnings shown above (implicit declaration & format stuff). So, I installed the new kernel "zImage", ran LILO install and tried to boot to this kernel. It died with the following errors on the screen: UltraStor 24F SCSI @ Slot 2 IRQ14 Unable to handle kernel paging request at address c0000002 Oops: 0000 EIP: 0010:00167d62 EFLAGS: 00010206 eax: 00167d61 ebx: 000000069 ecx: 00187ab8 edx: 000003d5 esi: 00000002 edi: 000171f24 ebp: 00000001 ds: 0018 es: 0018 fs: 0018 gs: 0018 Pid 0, process nr: 0 6f 6e 64 69 74 69 6f 6e 20 47 Task[0] (swapper) killed: unable to recover Kernel panic: trying to free up swapper memory space In swapper task - not syncing And, doing the "nm tools/zSystem | sort", I see the following pertinent information: 00167ca4 t constants.o 00167ca4 t gcc2_compiled. 00167cad t _unknown 00167cb5 t _vendor 00167cd4 t _print_opcode 00167cf4 T _print_command 00167db4 T _print_status 00167dd4 T _print_msg 00169584 T _print_sense 00169820 t ___gnu_compiled_c 00169820 t _bios_segment_table 00169820 t gcc2_compiled. 00169820 t ultrastor.o DIRTY DISKS Another problem that I see is with the root filesystem "CLEAN" flag. I'm using the EXT2 file system on a ~180MB partition for the root disk, plus I mount three FAT16 partitions, and use one swap partition. The problem is that whenever LINUX boots (*), I see a warning to the effect of this: warning, mounting dirty filesystem, running e2fsck is recommended Even when I've shutdown by running "halt", or even if I've run the commands: "cd / ; umount -a ; swapoff -a ; halt". The only way I've managed to get around this is to enter run-level 'S' first, then MANUALLY do a halt. And furthermore, "init s" within a script causes that script to be terminated -- so I cannot setup a simple way (for novices) to cleanly halt the system! Any help will be appreciated, (Response by e-mail is preferred), - Marvin Taylor ------------------------------ From: wongda@eecg.toronto.edu (Daniel Y.H. Wong) Subject: Re: SMail/Elm lock up Date: 7 Nov 93 18:41:44 GMT In article <160458@netnews.upenn.edu> rusu@eniac.seas.upenn.edu (LMRusu) writes: >Hello Linuxers, > >I'm having a slight problem with SMail/Elm: when I try to send a message >bigger than ~10k from my Linux box the hole thing (the X screen) just >locks up solid. The only way I can get out is by rebooting the machine. >Any message under 10k will be sent just fine and I can receive messages >of any size. > >If I try to send a message > 10k the machine locks up solid and after a reboot >I can see the message sitting in /usr/spool/smail/input and nothing about >it in /usr/spool/smail/error or log files. > >I have enough free disk space and I'm using SLIP with pl13p. >Any ideea what could be causing this?! > I don't have exactly the same problem, but my linux will lock up when I do ftp, or when there is heavy usage on the slip line. This doesn't occur every time, so that I can not reproduce it. I am using pl13, XFree2.0. You should try ftp as well and see it locks up as well. When I look into the linux source in the inet dir, it say the following: REMAINING KNOWN BUGS AND PROBLEMS: ... + Sudden lockups when overloading a socket? This seems to occur with X11 sessions (as per Linus Torvalds, 05/28/93) and has its origin in the new timer.c code... That may seem to be the cause of it?? If anyone know there is a fix for this, please let me know. >Larry >-- -- Daniel Y.H. Wong UofT:(416)978-1659 wongda@picton.eecg.toronto.edu Electrical Engineering -- ------------------------------ From: mvw@hacktic.nl (Marco van Wieringen) Subject: Re: Quota -1.1 Date: 7 Nov 1993 21:56:12 +0100 p2_copel@garlic.uwe.ac.uk (P Copeland) writes: >I am experienceing some difficulties with the quotaing system. >Symptoms: > added kernel patches to virgin 0.99.13 sources (ok no failures there) > make config wth quota's on > make dep and zImage > run /etc/lilo/install > reboot (all well and fine at this point) > cd /usr/src/quota > make clean/install (everything is going fine no problems) > > edited /etc/fstab to taste and ran quotacheck -augv (files created successfully) > now then,.... > ---------- > edquota -u m_oddity > Warning: Quotas are not compiled into this kernel > Quotas for user m_oddity: > /dev/sda1: blocks in use: 4, limits (soft = 0, hard = 0) > inodes in use: 1, limits (soft = 0, hard = 0) > /dev/sda2: blocks in use: 49486, limits (soft = 0, hard = 0) > inodes in use: 11036, limits (soft = 0, hard = 0) > ---------- > after editting the file to taste, I try quota -u m_oddity > Disk quotas for user m_oddity (uid 6199): none > Arrrraagghhh! > nm /linux/tools/zSystem | grep quot > 00124e90 t _add_dquot > 001260f0 T _get_quota > 00124db0 t _lookup_dquot > 0018ad58 b _mru_dquot > 001259a0 T _quota_alloc > 001266b0 T _quota_init > 00124b00 t _quota_message > 00126300 T _quota_off > 00126430 T _quota_on > 00125f20 T _quota_remove > 00125be0 T _quota_transfer > 00124ef0 t _remove_dquot > 00126030 T _set_quota > 00126240 T _sync_quota > 001266f0 T _sys_quotactl > 00124af0 t quota.o > ok so it's all there,.... whats happening? Is because it's a scsi disk?, a full moon? what? No it should have nothing to do with scsi or what soever it seems that something is screwed up with the release. That the only thing I can think of because it works nicely here. Could you contact me trough email, I tried to mail to both of the adresses but both bounce. >Phil >=--= People with the same problems can also contact me I will try to sort it out and make a new release if it is necessary. > >=============================================================================== > (c) 1992 Philip Copeland - alias 'Bryce' (SysAdmin) > JANET : p_copela@uk.ac.bristol-poly.csd Marco. Marco van Wieringen ------------------------------ From: sharman@godel.ecs.umass.edu (Rohit Sharma) Subject: IBM-AMBRA Date: 7 Nov 1993 21:35:01 GMT Is the IBM ambra Blue Lightinig supported byu Linux. I had heard that one of the SCSI controller chips is not supported. -- _______________________________________________ Why did Mr. Spock go to the ladies rest room ? Because he wanted to boldly go where no man had gone before. Rohit C. Sharman a.k.a. Rohit Sharma Dept. Of Elect. Eng Knowles Eng. Building Room 314 Tel Off. +-1-413-5453899 Res #35 Northwood Apts. Sunderland, MA 01375 USA Tel/Fax +-1-413-6654340 ------------------------------ ** 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-Admin-Request@NEWS-DIGESTS.MIT.EDU You can send mail to the entire list (and comp.os.linux.admin) via: Internet: Linux-Admin@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-Admin Digest ******************************