Messages in this thread |  | | | Date | Thu, 22 Oct 1998 14:57:08 +0200 | | From | Uwe Bonnes <> | | Subject | Re: NEW HyperTerminal Private Edition Release! |
| |
Hallo,
great! Hyperterminal provate edition works with Linux?
Bye
>>>>> "sales" == owner-linux-kernel-digest <owner-linux-kernel-digest@vger.rutgers.edu> writes:
sales> From: sales@hilgraeve.com Date: Thu, 8 Oct 1998 12:47:6 Subject: sales> NEW HyperTerminal Private Edition Release!
sales> We've just re-released HyperTerminal Private Edition 4.0, and sales> you're welcome to download it FREE. (We're notifying you because sales> you downloaded a previous version. If you want to remove yourself sales> from our mailing list, see the end of this message.)
sales> You may be thinking, "Re-released! What the heck does that mean?"
sales> More than 100,000 people downloaded HyperTerminal Private Edition sales> 4.0 since its release two months ago. With so many people using sales> it, and so many new features, it's not surprising a few bugs sales> would turn up. We've responded quickly, and created a new version sales> of HyperTerminal Private Edition 4.0 that you can download today!
sales> HyperTerminal Private Edition 4.0 introduced these new features:
sales> * Now you can define key macros to send passwords, user IDs or sales> often-used host commands with one keystroke * Set terminal screen sales> size (rows and columns); now also supports telnet NAWS feature sales> for telnet sites with variable screen size * Define the colors sales> used by the terminal screen * Full color support when emulating sales> VT100 terminals * Pass-through printing lets host systems control sales> your printer * Ability to exit the program automatically when you sales> log off * Updated entries for BBSs and telnet sites that you can sales> call * Adopts Windows new "flat" toolbar style * Use Windows sales> sounds (WAV and audio files) instead of beeps * Bug fixes for sales> improved use with all versions of Windows
sales> You can install this new version right over any previous version sales> without losing your settings.
sales> Download HyperTerminal Private Edition 4.0 TODAY from our web sales> site:
sales> http://www.hilgraeve.com
sales> We hope you enjoy HyperTerminal Private Edition 4.0. Please sales> forward this message to three of your friends!
sales> - --- To remove your email address sales> [linux-kernel@vger.rutgers.edu] from this hilgraeve mailing list, sales> simply reply to this message. Include this entire message in sales> your reply. If you have problems, please forward this message sales> with all headers to htpelist@hilgraeve.com. If you wish to sales> exchange email with us, send your mail to sales@hilgraeve.com.
sales> Please read the FAQ at http://www.tux.org/lkml/
sales> ------------------------------ sales> From: greg@wind.enjellic.com (G.W. Wettstein) Date: Thu, 22 Oct sales> 1998 00:18:57 -0500 Subject: Re: 2.0.3x -- hanging network sales> interfaces
sales> On Oct 20, 2:25pm, Matt Kemner wrote: } Subject: Re: 2.0.3x -- sales> hanging network interfaces >> On Sat, 17 Oct 1998, Chris Evans wrote:
chris> We've recently got a tulip based card, and we see network hangs chris> (the kind fixable by taking the interface down then up). I have chris> two questions.
>> I saw a similar problem with a tulip card in my proxy server, which >> is under a LOT of network load (2 million requests/day) - the card >> would simply stop working, but if I ifconffiged it down/up again it >> was fine.. The problem turned out to be hardware rather than >> software - it was plugged into a rather cheap non-switching hub, >> which I replaced with a 16x10Mb+2x10/100Mb switch (by Netgear, and >> the tulip is also a Netgear) and I haven't seen the problem since >> (plus the card now runs at 100Mb full duplex, VERY fast :))
>> Hope this helps you solve your problem.
sales> I find this a somewhat interesting observation. I have been sales> reporting problems with the epic based Etherpower II NIC's on our sales> production IMAP server running 2.0.35. We have a pair of these sales> cards sharing an interrupt line.
sales> During periods of high load the eth0 card wedges itself. The sales> eth1 interface remain active. Downing and upping both interfaces sales> clears the problem. We have been blaming SMP/interrupt problems sales> but we had 28 days of trouble-free operation. Our first incident sales> of wedging occurred when the Bay 450 switch that eth0 was plugged sales> into was replaced with a 10Mbit/sec shared media hub.
sales> I have been running a uniprocessor kernel on the box for 2 days sales> and we have not had a wedging problem. This would seem to sales> implicate SMP but I find the whole situation after reading the sales> above notes somewhat more than coincidental.
>> - Matt Kemner
sales> Greg
sales> }-- End of excerpt from Matt Kemner sales> As always, Dr. G.W. Wettstein Enjellic Systems Development - sales> Specialists in 4206 N. 19th Ave. intranet based enterprise sales> information solutions. Fargo, ND 58102 WWW: sales> http://www.enjellic.com Phone: 701-281-1686 EMAIL: sales> greg@wind.enjellic.com - sales> ------------------------------------------------------------------------------ sales> "Fools ignore complexity. Pragmatists suffer it. Some can avoid sales> it. Geniuses remove it. -- Perliss' Programming Proverb #58 sales> SIGPLAN National, Sept. 1982 sales> Please read the FAQ at http://www.tux.org/lkml/
sales> ------------------------------ sales> From: Andreas Haumer <andreas@xss.co.at> Date: Thu, 22 Oct 1998 sales> 07:10:34 +0200 Subject: Re: bridging fix? Which (fwd)
sales> Hi!
sales> Peter T. Breuer wrote: >> [Cc: to linux-kernel, in case some other network guru knows and alan >> is busy] >> >> Hello Alan >> >> I know you finally found and fixed the bridging code leak somewhere >> in the recent 2.0.36pre series or just before. But I haven't been >> able to figure out what the fix was, by inspection. I would be >> deeply grateful if you could tell me what the line or lines was .. I >> think some intrepid soul managed to find the line that did the damage >> using the memleak patches. >> sales> Yeah, I think that was me :-) >> I saw the leak first on a server I had at 2.0.33. P100 with 3c905 >> and buslogic fast and wide. It went down in a week serving NFS. You >> steered me to the cause and workaround. >> sales> Yes, the system where I found that also went down after a few sales> days. I have some quite impressive vmstat statistics where you sales> can see a almost linear decreasing in available memory... sales> [...] >> I would love to have just the fix for this as a patch. I know >> that's too much to ask, so I'm asking just to be clued in on the >> eureka that solved this. >> sales> I think that's what you are looking for: sales> *** linux-2.0.35/net/bridge/br.c Tue Aug 26 20:05:34 1997 - --- sales> linux/net/bridge/br.c Sat Oct 17 16:04:22 1998 *************** sales> *** 921,930 **** skb-> pkt_bridged = IS_BRIDGED; arp = 1; /* do not resolve... */ h.raw = skb-> skb->data + ETH_HLEN; sales> ! save_flags(flags); ! cli(); ! skb_queue_tail(dev->buffs, sales> skb); ! restore_flags(flags); return(0); } sales> - --- 921,927 ---- skb-> pkt_bridged = IS_BRIDGED; arp = 1; /* do not resolve... */ h.raw = skb-> skb->data + ETH_HLEN; sales> ! dev_queue_xmit(skb, dev, SOPRI_INTERACTIVE); return(0); } sales> *************** *** 977,986 **** skb-> pkt_bridged = IS_BRIDGED; arp = 1; /* do not resolve... */ h.raw = skb-> skb->data + ETH_HLEN; sales> ! save_flags(flags); ! cli(); ! skb_queue_tail(dev->buffs, sales> skb); ! restore_flags(flags); return(0); } sales> - --- 974,981 ---- skb-> pkt_bridged = IS_BRIDGED; arp = 1; /* do not resolve... */ h.raw = skb-> skb->data + ETH_HLEN; sales> ! ! dev_queue_xmit(skb, dev, SOPRI_INTERACTIVE); return(0); } sales> HTH
sales> - - andreas
sales> - -- Andreas Haumer | email: andreas@xss.co.at | PGP key sales> available *x Software + Systeme | phone: +43.1.6001508 | on sales> request. Buchengasse 67/8 | +43.664.3004449 | A-1100 Vienna, sales> Austria | fax: +43.1.6001507 | AH327-RIPE sales> Please read the FAQ at http://www.tux.org/lkml/
sales> ------------------------------ sales> From: hpa@transmeta.com (H. Peter Anvin) Date: 22 Oct 1998 sales> 04:37:59 GMT Subject: Re: OFF-Topic glibc behavior
sales> Followup to: sales> <Pine.LNX.3.95.981021131237.241A-100000@chaos.analogic.com> By sales> author: "Richard B. Johnson" <root@chaos.analogic.com> In sales> newsgroup: linux.dev.kernel >> The following code will write "Hello World!" to the screen on the >> following platforms: >> >> MS-DOS with Micro$oft 'C' 6.0 and Micro$oft 7.01 compilers MS-DOS >> with Borland Turbo-C 3.0 VAX/VMS VAX-C V3.0 >> >> It just waits in a CPU-eating race on SunOs 5.5.1 With glibc on >> Linux, it seg-faults. >> >> This is not meant to be flame-bait. I know this is not how to write >> code. However, the effect of this kind of coding does happen when >> structures containing file-pointers are duplicated so it can (does) >> happen. >> sales> No. You can duplicate a file POINTER. You can't duplicate a sales> file STRUCTURE. There is no excuse for it either -- your user sales> program should never mess with a FILE structure but only have sales> pointers to it.
>> Glibc doesn't check the contents of the FILE structures, just the >> addresses and since it "knows" the pointer received was not one it >> provided, it generates signal 11 on its own. Is this REALLY what is >> supposed to happen? After all, the function call did get a perfectly >> valid pointer to the required structure. >> sales> No it didn't. You duplicated the FILE *structure*, which may sales> itself contain pointers to other structures inside libc.
sales> Your program is totally and utterly broken. SIGSEGV is a sales> perfectly acceptable and quite reasonable.
sales> -hpa
sales> - -- PGP: 2047/2A960705 BA 03 D3 2C 14 A8 A8 BD 1E DF FE 69 EE 35 sales> BD 74 See http://www.zytor.com/~hpa/ for web page and full PGP sales> public key I am Bahá'í -- ask me about it or see sales> http://www.bahai.org/ "To love another person is to see the face sales> of God." -- Les Misérables
sales> Please read the FAQ at http://www.tux.org/lkml/
sales> ------------------------------ sales> From: Daniel Nash <danash@students.wisc.edu> Date: Wed, 21 Oct sales> 1998 23:58:28 -0500 (CDT) Subject: Kernel freeze on boot sales> (.123-.125) in IDE init
sales> I'm currently running 2.1.113, and trying the newest ones. sales> However, since 2.1.123, it's been freezing during the IDE sales> Partition check. I've tried a minimal config, w/o scsi sound or sales> anything extraneous and monolithic. I also have tried sales> 2.1.126-pre2 and 2.1.126-pre2ac1, with the same results.
sales> Machine: 430HX w/Petium 225MMX using Promise Ultra/33 PCI sales> controller for ide2/3
sales> It freezes after displaying 'hda:' in the partition check.
sales> Here's the pertinent part of dmesg and /proc/pci from under sales> 2.1.113
sales> PIIX3: IDE controller on PCI bus 00 dev 39 PIIX3: not 100% native sales> mode: will probe irqs later ide0: BM-DMA at 0xf000-0xf007, BIOS sales> settings: hda:pio, hdb:pio ide1: BM-DMA at 0xf008-0xf00f, BIOS sales> settings: hdc:pio, hdd:pio PDC20246: IDE controller on PCI bus 00 sales> dev 58 PDC20246: not 100% native mode: will probe irqs later sales> ide2: BM-DMA at 0x6500-0x6507, BIOS settings: hde:DMA, hdf:pio sales> ide3: BM-DMA at 0x6508-0x650f, BIOS settings: hdg:pio, hdh:DMA sales> hda: IBM-DAQA-33240, ATA DISK drive hdb: WDC AC31600H, ATA DISK sales> drive hdc: MATSHITA CR-585, ATAPI CDROM drive hde: sales> IBM-DHEA-38451, ATA DISK drive ide0 at 0x1f0-0x1f7,0x3f6 on irq sales> 14 ide1 at 0x170-0x177,0x376 on irq 15 ide2 at sales> 0x6100-0x6107,0x6206 on irq 10 hda: IBM-DAQA-33240, 3098MB w/96kB sales> Cache, CHS=787/128/63, DMA hdb: WDC AC31600H, 1549MB w/128kB sales> Cache, CHS=787/64/63, DMA hde: IBM-DHEA-38451, 8063MB w/472kB sales> Cache, CHS=16383/16/63, UDMA Partition check: hda: hda1 < hda5 > sales> hda3 hda4 hdb: hdb1 hdb4 < hdb5 hdb6 > hde: [PTBL] [1027/255/63] sales> hde1 hde2 hde3 < hde5 hde6 hde7 >
sales> % cat /proc/pci PCI devices found: Bus 0, device 0, function 0: sales> Host bridge: Intel 82439HX Triton II (rev 3). Medium devsel. sales> Master Capable. Latency=32. Bus 0, device 7, function 0: ISA sales> bridge: Intel 82371SB PIIX3 ISA (rev 1). Medium devsel. Fast sales> back-to-back capable. Master Capable. No bursts. Bus 0, device sales> 7, function 1: IDE interface: Intel 82371SB PIIX3 IDE (rev 0). sales> Medium devsel. Fast back-to-back capable. Master Capable. sales> Latency=32. I/O at 0xf000 [0xf001]. Bus 0, device 11, function sales> 0: RAID bus controller: Promise Technology IDE UltraDMA/33 (rev sales> 1). Medium devsel. IRQ a. Master Capable. Latency=32. I/O at sales> 0x6100 [0x6101]. I/O at 0x6204 [0x6205]. I/O at 0x6300 sales> [0x6301]. I/O at 0x6404 [0x6405]. I/O at 0x6500 [0x6501]. Bus sales> 0, device 13, function 0: Ethernet controller: 3Com 3C905 100bTX sales> (rev 0). Medium devsel. IRQ a. Master Capable. Latency=32. sales> Min Gnt=3.Max Lat=8. I/O at 0x6600 [0x6601]. Bus 0, device 15, sales> function 0: VGA compatible controller: Matrox Millennium (rev 1). sales> Medium devsel. Fast back-to-back capable. IRQ b. sales> Non-prefetchable 32 bit memory at 0xe0800000 [0xe0800000]. sales> Prefetchable 32 bit memory at 0xe0000000 [0xe0000008]. sales> What other information would be useful?
sales> Thanks, - -- Daniel Nash "Waiter, Waiter, there's an avocado in sales> my guacamole." - Me
sales> Please read the FAQ at http://www.tux.org/lkml/
sales> ------------------------------ sales> From: Odddmonseter <lund@uq.net.au> Date: Thu, 22 Oct 1998 sales> 07:11:12 +1000 Subject: Unexplained problem. 2.1.125.
sales> I've been having trouble with 2.1.125 quite frequently. I'm a sales> heavy X user and I use netscape in X quite alot. Been running sales> 2.1.125 for a few days now, and everyday so far the kernel has sales> locked up (i think). There is no responce from the SysRq key and sales> I can't make anything go. All hdds stop and I have to hit the sales> reset button. I found this in my syslog after I rebooted from sales> the last go. I'm not sure if fsck did this so can someone please sales> explain what I have been doing wrong.
sales> Oct 22 06:39:04 strange tcplogd: auth connection attempt from sales> doughnut.cc.uq.edu.au [130.102.128.239] sales> ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@Oct sales> 22 06:56:44 strange syslogd 1.3-3#26: restart.
sales> - -- O. is for Oddd. (and its good enough for me). Odddmonster.
sales> Please read the FAQ at http://www.tux.org/lkml/
sales> ------------------------------ sales> From: "Lee, Hee-Jin" <heejin@secns.sec.samsung.co.kr> Date: Thu, sales> 22 Oct 1998 15:06:31 +0900 Subject: command source code
sales> Hi all, How can I get command source code such as "insmod"? I'm sales> looking for who delacares "struct device" for a network module.
sales> I'm always asking, but I hope I can help you some day. :->
sales> Thnak you. - -heejin
sales> Please read the FAQ at http://www.tux.org/lkml/
sales> ------------------------------ sales> From: Gerhard Mack <gmack@imag.net> Date: Wed, 21 Oct 1998 sales> 23:36:07 -0700 (PDT) Subject: Re: Dynamic IP hack (PR#294)
sales> Ummm what happens when 20 or 30 customers of IP MASQed isp sales> descide us use say ... efnet ?
sales> Gerhard
sales> On Wed, 21 Oct 1998, Riley Williams wrote:
>> Hi Meelis. >> >> >> Would your customers be unhappy if you installed a firewall? If >> >> not, then it's very simple to get hold of MILLIONS of addresses >> >> for static IP purposes, as has been stated at least twice >> >> before... >> >> > IP masq != firewall in a strict sense. >> >> True, but as the same software's used to control both under Linux 2.0 >> kernels, there's not a great deal to differentiate them from a >> practical point of view... >> >> > With NAT, your clients can not use many protocols that they could > >> use otherwise. Still, for most clients it's ok. ICQ w/incoming > >> calls is the only one I've had problems with in such setup ;-) >> >> There's one other I've come across, namely net2phone. However, whilst >> they're not directly supporting masquerading, they have programmed a >> work-around to deal with it - net2phone can be set up to use specific >> port numbers, rather than the standard "random free port" system now, >> since I've notified them of the problem... >> >> Incidentally, I met it when setting up Linux as an IP Masq firewall >> to a network of Win95 and Win98 systems...net2phone is not available >> in Linux versions, and they don't currently plan to support Linux >> either, unfortunately... >> >> Best wishes from Riley. >> >> >> - To unsubscribe from this list: send the line "unsubscribe >> linux-kernel" in the body of a message to majordomo@vger.rutgers.edu >> Please read the FAQ at http://www.tux.org/lkml/ >> sales> - -- Gerhard Mack
sales> gmack@imag.net InnerFIRE@starchat.net
sales> As a computer I find your faith in technology amusing.
sales> Please read the FAQ at http://www.tux.org/lkml/
sales> ------------------------------ sales> From: ketil@ii.uib.no Date: 22 Oct 1998 08:38:37 +0200 Subject: sales> 2.1.125: problems
sales> Hi,
sales> on a relatively straightforward RH 5.1, P133 system (Digital sales> Venturis FX 5133, if you must know), I've been a good citizen and sales> installed 2.1.125.
sales> I get an oops when the sb module is loaded for my SB64AweGold, sales> I've been mucking with plug and play and whatnot, so it's sales> possibly my own fault. If anybody wants the gritty details, drop sales> me a mail.
sales> Also, when shutting down, umount -a doesn't seem to do it's sales> thing, it just hangs indefinitely, and subsequently it fscks on sales> restart. I only have one large / partition (yes, yes, I know), sales> if that makes a difference.
sales> I did a quick version check of among other things mount, without sales> finding anything outdated, and 2.1.117 worked okay, I think.
sales> (I've been following the list without seeing anybody else have sales> these problems, and I've somehow messed up my kernel a bit. I'll sales> get a clean tree before going any further with this (have a thin sales> wire, so it'd take a while), but thought I should at least sales> mention it, just in case)
sales> ~kzm - -- If I haven't seen further, it is by standing in the sales> footprints of giants
sales> Please read the FAQ at http://www.tux.org/lkml/
sales> ------------------------------ sales> From: Simon Kenyon <simon@koala.ie> Date: Thu, 22 Oct 1998 sales> 08:33:42 +0100 (BST) Subject: Re: Motherboard design specifically sales> for Linux
sales> On 21-Oct-98 Vojtech Pavlik wrote: >> The serial (and/or floppy) loading mechanism was intended, in this >> thread, to allow fix a badly flashed rom, as a last resort when >> nothing else helps.
sales> in my case "the last resort" would involve taking the machine sales> apart and adding a floppy drive *or* connecting another machine sales> running some special software which would download the kernel sales> with some special protocol.
sales> that means that the solution is not *self contained* i broken pc sales> would not have the h/w and/or s/w to repair a broken rom sales> supermicro motherboards (and i'm certainly not advocating them) sales> have a system whereby if you hold down some key (i forget which) sales> when you turn on the machine and there is a floppy in the drive - sales> the boot code will load a new rom image from the sales> floppy. absolutely minimal! - -- simon
sales> Please read the FAQ at http://www.tux.org/lkml/
sales> ------------------------------ sales> From: Werner Almesberger <almesber@lrc.di.epfl.ch> Date: Thu, 22 sales> Oct 1998 09:50:56 +0200 (MET DST) Subject: MM with fragmented sales> memory
sales> [ Posted to linux-kernel and linux-7110 ]
sales> I'd like to get some opinions on what could be a reasonable sales> memory mapping for the Psion S5. The problem with this device is sales> that its physical RAM is scattered over a 30 bit address space in sales> little fragments of 512kB, aligned to multiples of 1MB. Since sales> it's impossible to fit any useful kernel into 512kB, some sales> creative memory layout is necessary.
sales> I can see two viable approaches:
sales> (1) play linker tricks and insert holes in the kernel such that sales> it skips over the gaps in memory. Then map all the memory 1:1 and sales> let start_mem and end_mem each have one of the 512kB fragments sales> for linear allocation. (2) use the MMU to create virtually sales> continuous memory and let the kernel manage that in the usual sales> way.
sales> The problems I see with (1) are: - at least part of the memory sales> layout needs to be known when linking the kernel - allocations sales> from start_mem and end_mem are each limited to a total of 512kB - sales> need to re-arrange VMALLOC_END, because on ARM-Linux it's 256 MB sales> after PAGE_OFFSET, but VMALLOC_START will already have to be sales> about 278 MB after that, due to the "exploded" address sales> space. (But that change may be harmless.) The problems I see sales> with (2) are: - virt_to_phys and phys_to_virt now need to perform sales> lookups (in (1) they're no-ops). With a few tricks, I can get sales> each of them done in about 10 clock cycles, clobbering two sales> registers (out of 16), and accessing memory once - a little voice sales> in the back of my head saying that something in the kernel will sales> certainly trip over a virtual:physical mapping that isn't just an sales> offset
sales> While I'm attracted by the simplicity of (1), I'm a little sales> worried about the limitation for linear allocations. Also, initrd sales> needs a little work to function in such a scenario.
sales> The disadvantage of (2) is clearly its complexity. Also, I don't sales> like what that little voice is saying ...
sales> Any suggestions ?
sales> Thanks, - - Werner
sales> - -- sales> _________________________________________________________________________ sales> / Werner Almesberger, DI-ICA,EPFL,CH sales> werner.almesberger@lrc.di.epfl.ch / sales> /_IN_R_131__Tel_+41_21_693_6621__Fax_+41_21_693_6610_____________________/ sales> Please read the FAQ at http://www.tux.org/lkml/
sales> ------------------------------ sales> From: Rik van Riel <H.H.vanRiel@phys.uu.nl> Date: Thu, 22 Oct sales> 1998 10:10:40 +0200 (CEST) Subject: Re: command source code
sales> On Thu, 22 Oct 1998, Lee, Hee-Jin wrote:
>> How can I get command source code such as "insmod"?
sales> You download it from one of the countless ftp sites where it is sales> hosted. You can also get it on CDROM.
sales> ftp.kernel.org sunsite.unc.edu ftp.funet.fi ftp.tsx-11.edu sales> ftp.redhat.com ftp.debian.org ftp.cdrom.com
>> I'm looking for who delacares "struct device" for a network module.
sales> /usr/bin/grep is your friend ;)
sales> Rik. sales> +-------------------------------------------------------------------+ sales> | Linux memory management tour guide. H.H.vanRiel@phys.uu.nl | | sales> Scouting Vries cubscout leader. http://www.phys.uu.nl/~riel/ | sales> +-------------------------------------------------------------------+
sales> Please read the FAQ at http://www.tux.org/lkml/
sales> ------------------------------ sales> From: Neil Conway <nconway.list@ukaea.org.uk> Date: Thu, 22 Oct sales> 1998 08:40:29 +0000 Subject: wtmp problems (with "last") sales> With RH5.1, few if any of the updated RPM's (mea culpa :-), sales> 2.1.108, I keep getting entries like these throughout my "last" sales> printouts, which if I am correct means corruption in the wtmp sales> file (?):
sales> ing *4*** ?***P****4*****@ Wed Oct 21 18:02 still logged in sales> x6*@**** otify ***@ Wed Oct 21 18:02 still logged in sales> Any tips ?
sales> I was concerned about disk corruption for a while, but that seems sales> to check out OK, so I now suspect one of the programs that should sales> make entries isn't doing a good job.
sales> I tracked these down to what I *think* is happening: when someone sales> logs OUT, whichever program updates the file isn't finding the sales> right entry, and makes a bogus one at the end. I didn't get any sales> further than that due to lack of time and ability ;-)
sales> TIA
sales> Neil
sales> Please read the FAQ at http://www.tux.org/lkml/
sales> ------------------------------ sales> From: Vojtech Pavlik <vojtech-lists@twilight.ucw.cz> Date: Thu, sales> 22 Oct 1998 11:02:41 +0200 Subject: Re: Motherboard design sales> specifically for Linux
sales> On Thu, Oct 22, 1998 at 08:33:42AM +0100, Simon Kenyon wrote:
>> > The serial (and/or floppy) loading mechanism was intended, in this >> thread, to > allow fix a badly flashed rom, as a last resort when >> nothing else helps. >> >> in my case "the last resort" would involve taking the machine apart >> and adding a floppy drive *or* connecting another machine running >> some special software which would download the kernel with some >> special protocol. >> >> that means that the solution is not *self contained* sales> Now, how would you like to make it be self contained? If the sales> machine you build doesn't have a floppy, it doesn't need to have sales> an LS120, or a CDROM or whatever anyway, so no more luck than sales> with a floppy ... you'd need to take the machine apart again.
sales> Even NOW, when the kernel is on the harddrive, and you build the sales> machine floppy/ CDROM/LS120/ZIP-less, you can't bring it back to sales> life if the kernel images on the harddrive are corrupted without sales> taking it apart ...
sales> ...... sales> And, should you have two boot time selectable kernel images in sales> the flash, one for actually being run and the other as a backup sales> for when eg. upgrading the kernel, a situation where you would sales> need to re-flash the flash fully would happen only very very sales> seldom.
sales> And I think that when this happens, it's worth to have the sales> trouble with using a second computer and a serial cable, instead sales> of having support for every device you can load the kernel from sales> in the boot/kernel loader part of the flash.
sales> Vojtech
sales> Please read the FAQ at http://www.tux.org/lkml/
sales> ------------------------------ sales> From: Philip Trickett <philipt@informatic.ie> Date: Thu, 22 Oct sales> 1998 10:03:53 +0100 Subject: Re: NADS for Linux
sales> Alex Buell wrote: >> On Tue, 20 Oct 1998, Mark Spencer wrote: >> >> > This is the official announcment of the NADS project for Linux. >> >> Hi. I'm really sorry, but your acronym ("NADS") is making me >> laugh. You do know that NADS means your testicles don't you? ;o) >> Thanks for making my day. sales> Maybe they should rename it Dogs NADS? ;) sales> (Because after all, Linux is the Dogs Bollocks! (For those that sales> don't know, that is a complimentary term by the way))
sales> Other than that, I am afraid that I am no routing expert.
sales> Sorry, Phil - -- sales> ======================================================================== sales> Philip Trickett mailto:philipt@informatic.ie Systems Engineer sales> Marine Informatics Tel: +353-1-475-2924 64 Harcourt Street Fax: sales> +353-1-475-2952 Dublin 2 Republic of Ireland sales> http://www.informatic.ie/marine/ sales> ======================================================================== sales> Please read the FAQ at http://www.tux.org/lkml/
sales> ------------------------------ sales> From: Andreas Jaeger <aj@arthur.rhein-neckar.de> Date: 22 Oct sales> 1998 11:01:24 +0200 Subject: Re: wtmp problems (with "last")
>>>>> Neil Conway writes:
>> With RH5.1, few if any of the updated RPM's (mea culpa :-), 2.1.108, >> I keep getting entries like these throughout my "last" printouts, >> which if I am correct means corruption in the wtmp file (?):
>> ing *4*** ?***P****4*****@ Wed Oct 21 18:02 still logged in x6*@**** >> otify ***@ Wed Oct 21 18:02 still logged in sales> glibc2 which is used with RedHat 5.1 uses a different (larger) sales> utmp format than libc5. If you've got program that expect the sales> libc5 utmp format, you'll notice this corruption. Just upgrade sales> those binaries. When upgrading from a libc5 distribution to a sales> glibc2 one, you should also `rm wtmp' since the format has sales> changed.
sales> Andreas P.S. This is offtopic to linux-kernel. - -- Andreas sales> Jaeger aj@arthur.rhein-neckar.de jaeger@informatik.uni-kl.de for sales> pgp-key finger ajaeger@aixd1.rhrk.uni-kl.de
sales> Please read the FAQ at http://www.tux.org/lkml/
sales> ------------------------------ sales> From: Kenneth Albanowski <kjahds@kjahds.com> Date: Thu, 22 Oct sales> 1998 04:59:14 -0400 (EDT) Subject: Re: MM with fragmented memory
sales> On Thu, 22 Oct 1998, Werner Almesberger wrote:
>> [ Posted to linux-kernel and linux-7110 ] >> >> I'd like to get some opinions on what could be a reasonable memory >> mapping for the Psion S5. The problem with this device is that its >> physical RAM is scattered over a 30 bit address space in little >> fragments of 512kB, aligned to multiples of 1MB. Since it's >> impossible to fit any useful kernel into 512kB, some creative memory >> layout is necessary. sales> I'm working with uClinux, which fits quite well in less then sales> 512kB of ROM, and can certainly run in 512kB of RAM (although sales> more is always better). Note that I don't copy the kernel from sales> ROM to RAM. Indeed, I go out of my way to leave things in ROM if sales> I can.
>> I can see two viable approaches: >> >> (1) play linker tricks and insert holes in the kernel such that it >> skips over the gaps in memory. Then map all the memory 1:1 and let >> start_mem and end_mem each have one of the 512kB fragments for linear >> allocation. sales> I find this very interesting, from an eclectic viewpoint. If you sales> want to run the kernel from RAM, and it's over 512K in length, sales> then obviously, you'll need to teach the linker, _and probably sales> the assembler_ how to properly place code across the gaps, and sales> still let the code run. (And all of this applies equally to user sales> applications that try to load over gaps. If you want relocatable sales> code, I'd simply refuse to touch that problem.)
sales> I have a nagging feeling that somebody else had to implement this sales> sort of thing, but I can't think who.
>> (2) use the MMU to create virtually continuous memory and let the >> kernel manage that in the usual way.
sales> Simplest, obviously. If you've got an MMU, take advantage of it.
>> The problems I see with (1) are: - at least part of the memory layout >> needs to be known when linking the kernel
sales> Very much so.
>> - allocations from start_mem and end_mem are each limited to a total >> of 512kB
sales> I'm not sure I follow. All allocations of memory with contiguous sales> physical addresses would be limited to 512K, yes. That's about sales> the only limit I can see. The page system would be a little sales> inefficient, but it can easily cope with this sort of missing sales> memory.
>> - need to re-arrange VMALLOC_END, because on ARM-Linux it's 256 MB >> after PAGE_OFFSET, but VMALLOC_START will already have to be about >> 278 MB after that, due to the "exploded" address space. (But that >> change may be harmless.) The problems I see with (2) are: - >> virt_to_phys and phys_to_virt now need to perform lookups (in (1) >> they're no-ops). With a few tricks, I can get each of them done in >> about 10 clock cycles, clobbering two registers (out of 16), and >> accessing memory once
sales> How often are virt_to_phys and phys_to_virt invoked? Offhand, I sales> can't see why these (or virt vs. bus) should be invoked very sales> often. (I could easily be wrong.)
>> - a little voice in the back of my head saying that something in the >> kernel will certainly trip over a virtual:physical mapping that isn't >> just an offset
sales> Hmm... Offhand, I have to agree. There's a problem here of how sales> large the "assumed address range" of a virt_to_phys ptr is. In sales> your case, it could range from [0K,+512K] to [-512K,0K], sales> depending on the original pointer.
sales> However, once again I'm not sure I can see any reason why this sales> should hurt: there is no reason for the kernel to be using sales> physical or bus addresses for block memory accesses, unless the sales> ARM is considerably different then the other processors I'm sales> familiar with. Those address spaces should only be useful from sales> outside the processor, or within the processor's MMU, and no sales> where else.
sales> If there was a memcpy_to_phys/bus, then you'd have to hack it up sales> to understand this sort of thing. But there isn't. And normal sales> memcpy isn't supposed to work with phys or bus address spaces, in sales> any case.
sales> If it's a matter of the kernel running in a different memory sales> mapping mode then user code, well, you do have memcpy_to/from_fs, sales> and get/put_user to hide any translation.
sales> Now will the Linux MMU code die on this sort of system? As long sales> as pages never cross these 512K boundries, I can't think why it sales> would break.
>> While I'm attracted by the simplicity of (1), I'm a little worried >> about the limitation for linear allocations. Also, initrd needs a >> little work to function in such a scenario.
sales> See if you can ditch initrd: if you can boot off a ROM disk, and sales> then mount a RAM disk in /var, you save all the memory of copying sales> the initrd image in to RAM. (#1 rule of small systems: if it's sales> already in memory somewhere, don't bother copying it somewhere sales> else.)
>> The disadvantage of (2) is clearly its complexity. Also, I don't like >> what that little voice is saying ... >> >> Any suggestions ? sales> As they say, "Hope This Helped".
>> Thanks, - Werner
sales> Cheers, Ken
sales> - -- Kenneth Albanowski (kjahds@kjahds.com, CIS: 70705,126)
sales> Please read the FAQ at http://www.tux.org/lkml/
sales> ------------------------------ sales> From: Rik van Riel <H.H.vanRiel@phys.uu.nl> Date: Thu, 22 Oct sales> 1998 11:19:22 +0200 (CEST) Subject: scheduler bigpatch, version 4
sales> Hi,
sales> I've just put out version 4 of the scheduler bigpatch. It is now sales> completely bugfree (guaranteed) and does: - - improve the sales> responsiveness of the system - - add a new scheduling class sales> (SCHED_IDLE) for low-priority background tasks - - the timeslice sales> of which you can tune through /proc/sys/kernel/sched_idle - - sales> adds Richard Gooches patch for a separate run queue for RT sales> processes, decreasing the latency realtime tasks are experiencing sales> when there are other tasks in the system
sales> The patch is available from my home page.
sales> Rik. sales> +-------------------------------------------------------------------+ sales> | Linux memory management tour guide. H.H.vanRiel@phys.uu.nl | | sales> Scouting Vries cubscout leader. http://www.phys.uu.nl/~riel/ | sales> +-------------------------------------------------------------------+
sales> Please read the FAQ at http://www.tux.org/lkml/
sales> ------------------------------ sales> From: Jakub Jelinek <jj@sunsite.ms.mff.cuni.cz> Date: Thu, 22 Oct sales> 1998 11:45:33 +0200 (MET DST) Subject: Re: MM with fragmented sales> memory
>> I can see two viable approaches: >> >> (1) play linker tricks and insert holes in the kernel such that it >> skips over the gaps in memory. Then map all the memory 1:1 and let >> start_mem and end_mem each have one of the 512kB fragments for linear >> allocation. sales> I think if you have just 512kB fragments, it would be a lot of sales> trouble with linker, I guess you'd need to touch generic code in sales> a couple of places, etc. BTW: Are those frags at fixed locations sales> or do their addresses depend on how somebody stuffed SIMMs into sales> it? Another question: how large VA space do you have and how sales> large PA space the machine has? If e.g. max PA range is 2GB, but sales> VA is 4GB, then you could happily use 1:(1+off) mapping (or even sales> 1:1), and map the kernel with a virtual mapping to some other VA sales> (so that kernel's 2MB (or so) would have two mappings). If that's sales> possible, then you won. In fact, that's how things look like on sales> sparc64: physical memory may be non-contiguous, may start sales> anywhere and consists of chunks at least 4M long. We have an sales> automatic mapping VA=PA+PAGE_OFFSET. The kernel is located in sales> first physical chunk, which is mapped with a 4M page to 4MB VA. sales> The kernel already has PG_Skip stuff which is designed for sales> non-contiguous physical memory (ie. your mem_map will point to sales> some valid pages and some invalid pages (as no physical pages is sales> mapped to them).
>> (2) use the MMU to create virtually continuous memory and let the >> kernel manage that in the usual way.
sales> If the above is not possible, then this should work just fine, sales> although a tiny bit slower. That's what sparc32/sun4m does in sales> most cases, so the little voice can stay back in your head, such sales> scheme is tested and works.
sales> Cheers, Jakub sales> ___________________________________________________________________ sales> Jakub Jelinek | jj@sunsite.mff.cuni.cz | sales> http://sunsite.mff.cuni.cz Administrator of SunSITE Czech sales> Republic, MFF, Charles University sales> ___________________________________________________________________ sales> Ultralinux - first 64bit OS to take full power of the UltraSparc sales> Linux version 2.1.125 on a sparc64 machine (498.80 BogoMips). sales> ___________________________________________________________________ sales> Please read the FAQ at http://www.tux.org/lkml/
sales> ------------------------------ sales> From: Carsten Pluntke <su0289@sx2.HRZ.Uni-Dortmund.DE> Date: Thu, sales> 22 Oct 1998 11:45:06 +0200 (MET DST) Subject: Re: wtmp problems sales> (with "last")
sales> On Thu, 22 Oct 1998, Neil Conway wrote:
>> [wtmp corrupted] >> >> I tracked these down to what I *think* is happening: when someone >> logs OUT, whichever program updates the file isn't finding the right >> entry, and makes a bogus one at the end. I didn't get any further >> than that due to lack of time and ability ;-) sales> Maybe 'last' and other utilities meddling with wtmp compiled sales> using different versions of the glibc? AFAIK, from glibc 2 the sales> structure of the wtmp entries have changed a bit to have enough sales> space for IPv6 addresses.
sales> Check out the binaries using ldd (especially login, logout and sales> last)
sales> Carsten
sales> Please read the FAQ at http://www.tux.org/lkml/
sales> ------------------------------ sales> From: "Etienne Lorrain" <lorrain@fb.sony.de> Date: Thu, 22 Oct sales> 1998 11:54:39 +0001 Subject: Re: Motherboard design specifically sales> for Linux
sales> Hi,
sales> I am not sure it is on-topic, but here are my $0.02 on this sales> thread (multiple answers):
>> > > Many flash chips have a separatly write-protectable area used > > >> for boot areas. > > I know. Is it large enough? >> >> AMD 29F040 flash chips (512KB) are divided into 64KB sectors that can >> be individually erased. sales> Take care that even with write-protectable sectors, most of sales> FLASHs cannot erase and program themself by executing code from sales> the FLASH been treated. You also do not want to enable memory sales> cache in this process. A small independant ROM is sometime better sales> (to do basic checks like RAM check) instead of coping code to sales> erase/program FLASH in RAM.
>> [people talking about reprogram FLASH after total panic]
sales> Surely there should not be complex drivers in the non erasable sales> boot software, because it should be bug free. Anyway, when a sales> company build a motherboard, it has to test it on the production sales> line, without any card on the ISA bus... I have heard they use a sales> connection through the keyboard interface, with a very basic sales> protocol, use this one at last choice. Note also that sales> programming a FLASH *before* soldering is theoretically not sales> guaranted to work...
sales> Etienne.
sales> Please read the FAQ at http://www.tux.org/lkml/
sales> ------------------------------ sales> From: "Henning P. Schmiedehausen" <hps@tanstaafl.de> Date: 22 Oct sales> 1998 11:50:11 +0200 Subject: Re: OFF-Topic glibc behavior
sales> root@chaos.analogic.com (Richard B. Johnson) writes:
>> On Wed, 21 Oct 1998 grant@torque.net wrote:
>>> > The following code will write "Hello World!" to the screen on > >>> the following platforms: >>> >>> On the screen or in /tmp/foo ??? >>> >> The problem was originally shown to me, and the text was written by >> one who didn't want to be flamed, using 'stdout'. Thinking that >> 'stdout' might be special, I opened a file explicitly, finding the >> same behavior. I did not change the text. sales> Most surely, the 'struct FILE' you see (and get defined in the sales> includes) is just half the truth. You often have two structure sales> definition, one visible to the world and another one, private sales> with maybe much more members than the public one. You get a FILE sales> * pointer and can access the 'public known' fields but there are sales> more fields hidden beneath.
sales> I'm not sure whether you must be allowed to copy this but this sales> would surely explain the behaviour. Treat FILE * as an opaque sales> type with no information about the size of the underlying sales> structure.
sales> Kind regards Henning
>>> Is this the simplest explanation ? Seems to me that the FILE >>> structure could contain (directly or indirectly) a self-referential >>> pointer. Moving it would certainly break something ... >>> >>> But what does this have to do with the kernel ? >> Read above.
>> Cheers, Dick Johnson ***** FILE SYSTEM WAS MODIFIED ***** Penguin : >> Linux version 2.1.123 on an i586 machine (66.15 BogoMips). Warning : >> It's hard to remain at the trailing edge of technology.
>> - To unsubscribe from this list: send the line "unsubscribe >> linux-kernel" in the body of a message to majordomo@vger.rutgers.edu >> Please read the FAQ at http://www.tux.org/lkml/ sales> - -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- sales> hps@tanstaafl.de TANSTAAFL! Consulting - Unix, Internet, Security
sales> Hutweide 15 Fon.: 09131 / 50654-0 "There ain't no such D-91054 sales> Buckenhof Fax.: 09131 / 50654-20 thing as a free Linux"
sales> Please read the FAQ at http://www.tux.org/lkml/
sales> ------------------------------ sales> From: Werner Almesberger <almesber@lrc.di.epfl.ch> Date: Thu, 22 sales> Oct 1998 11:57:38 +0200 (MET DST) Subject: Re: MM with fragmented sales> memory
sales> Jakub Jelinek wrote: >> BTW: Are those frags at fixed locations or do their addresses depend >> on how somebody stuffed SIMMs into it?
sales> They seem to be fixed on Psions, although I'd like to keep this sales> part generic, because (1) you never know if there isn't some odd sales> Psion model with a different layout, and (2) we could then re-use sales> things on the Geofox and other 7110-based systems.
>> Another question: how large VA space do you have and how large PA >> space the machine has?
sales> The CPU has VA = PA = 4 GB, but RAM is confined to the upper 1 sales> GB.
>> If e.g. max PA range is 2GB, but VA is 4GB, then you could happily >> use 1:(1+off) mapping (or even 1:1), and map the kernel with a >> virtual mapping to some other VA (so that kernel's 2MB (or so) would >> have two mappings).
sales> Hmm, that's a very interesting idea ! There's one issue with sales> multiple mappings, though: the cache works with virtual sales> addresses, so if we access the same page via two different sales> addresses, our cache becomes inconsistent. Can such a thing ever sales> happen to kernel text, data, bss, and friends ?
>> If the above is not possible, then this should work just fine, >> although a tiny bit slower. That's what sparc32/sun4m does in most >> cases, so the little voice can stay back in your head, such scheme is >> tested and works.
sales> Excellent. Things look much brighter now :)
sales> Thanks a lot !
sales> - - Werner - -- sales> _________________________________________________________________________ sales> / Werner Almesberger, DI-ICA,EPFL,CH sales> werner.almesberger@lrc.di.epfl.ch / sales> /_IN_R_131__Tel_+41_21_693_6621__Fax_+41_21_693_6610_____________________/ sales> Please read the FAQ at http://www.tux.org/lkml/
sales> ------------------------------ sales> From: Riley Williams <rhw@bigfoot.com> Date: Thu, 22 Oct 1998 sales> 11:21:31 +0100 (GMT) Subject: Re: Dynamic IP hack (PR#294)
sales> Hi there.
>> Ummm what happens when 20 or 30 customers of IP MASQed isp descide us >> use say ... efnet ?
sales> I notice that one of the 'helpers' for IP Masquerading systems is sales> to enable IRC to be used through such a firewall...
sales> However, the sentiments behind your suggestion are indeed valid, sales> and indeed, I think I stated as much in my original message...
sales> In addition, other problems of which I was not aware have been sales> pointed out to me...
sales> Best wishes from Riley.
sales> Please read the FAQ at http://www.tux.org/lkml/
sales> ------------------------------ sales> End of linux-kernel-digest V1 #2738 sales> *********************************** sales> To subscribe to linux-kernel-digest, send the command:
sales> subscribe linux-kernel-digest
sales> in the body of a message to "Majordomo@vger.rutgers.edu". If you sales> want to subscribe something other than the account the mail is sales> coming from, such as a local redistribution list, then append sales> that address to the "subscribe" command; for example, to sales> subscribe "local-linux-kernel":
sales> subscribe linux-kernel-digest sales> local-linux-kernel@your.domain.net
sales> A non-digest (direct mail) version of this list is also sales> available; to subscribe to that instead, replace all instances of sales> "linux-kernel-digest" in the commands above with "linux-kernel". sales> -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de
Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
|  |