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/