Linux-Hardware Digest #573, Volume #9 Fri, 5 Mar 99 13:13:43 EST
Contents:
Re: How compatible is my Win9x system (newbie) (John Hasler)
Re: Can Linux use 36-bit Xeon addressing? (Robert Krawitz)
AAA: testing (Lawrence Fan)
es1788 (yhauser)
Re: 16bit mode in XWindows ("Martin")
Re: Intel 740 Help ("Ivan Chan")
Re: Toshiba CDROM can't read videoCD (Dave Swegen)
notebook graphics support (Dirk Arnold)
Re: Problems with ESS1938 (Anatol Quabach)
bttv problems w/ stb tvpci (Ashley W Campbell)
Re: dhcpd.conf (Tommy)
Re: Modem on COM5? (M. Buchenrieder)
Re: install - scsi cdrom not found on 2940 (M. Buchenrieder)
Re: Sound card and modem under Red Hat 5.2 (hexdump)
----------------------------------------------------------------------------
From: John Hasler <[EMAIL PROTECTED]>
Crossposted-To: alt.os.linux,comp.os.linux.setup
Subject: Re: How compatible is my Win9x system (newbie)
Date: Fri, 5 Mar 1999 13:50:22 GMT
Matthew.Kirkcaldie writes:
> I thought only WinModems caused Linux problems ... isn't that true?
Most PCI modems are winmodems. The only exception I know of is one
Multitech model.
--
John Hasler
[EMAIL PROTECTED] (John Hasler)
Dancing Horse Hill
Elmwood, WI
------------------------------
From: Robert Krawitz <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux,comp.os.linux.misc
Subject: Re: Can Linux use 36-bit Xeon addressing?
Date: 05 Mar 1999 10:44:57 -0500
[EMAIL PROTECTED] (Christopher B. Browne) writes:
> >The Xeon is not a "36-bit" machine, whatever that is... It merely has a
> >36-bit physical address bus.
>
> That can be interpreted as meaning it supports 36 bit address spaces, so it
> is a true statement.
That interpretation is simply incorrect. Virtual addresses (which are
the only kind that normal instructions ever deal with in protected
mode) are 32 bits wide, just as in all x86 processors from the 80386
on up. The processor (in hardware, by referring to the page tables)
translates these virtual addresses into physical memory addresses.
It's immaterial how wide the physical address bus is. The physical
address bus could be 20 bits wide (not that I'd care to use such a
machine), or 32 bits wide, or 40 bits wide. The kernel sets up the
mapping between virtual addresses and physical memory; the processor
actually performs the mapping in hardware, and the user code never
knows the difference.
> >The Xeon, like all x86's, is a 32-bit machine. For the large part, the
> >code needing modification is kernel code that deals with physical addresses.
>
> Nope. It will intrude on all user code as well, because user code deals
> with logical addresses, which must be mapped to physical addresses, and
> therefore need to have an isomorphism to do so, ergo the compiler must be
> modified to use the 36 bit addressing mode, libraries must be modified to
> use the 36 bit addressing mode, and applications must be modified to use the
> 36 bit addressing mode.
Not at all. You're drawing completely unwarranted conclusions here.
User code does deal with virtual (not "logical") addresses, and yes,
they must ultimately be mapped to physical addresses. However,
everything else in that paragraph is incorrect.
At any given time, any given address within any given process address
space may or may not be mapped to any given physical address. If it
is so mapped, the processor just goes ahead and accesses the
appropriate memory location.
If it's not mapped (i. e. if the page table entry for the given
address -- and this is still a virtual address -- is blank), however,
the processor takes a page fault. This is essentially an internally
generated interrupt. This page fault is trapped by the kernel, which
saves away the processor state and looks at the (still virtual)
address that generated the fault. There are a number of things it can
do here:
1) It can determine that the address is not in the process's address
space (e. g. the address is 0). In this case, the kernel will raise a
segmentation fault, which becomes a signal to the process. Unless the
process has arranged to catch SIGSEGV (or sometimes SIGBUS -- I'm not
clear on the distinction), it will be terminated with a core dump.
2) It can determine that the virtual address in question is part of
the process's address space, and already exists in physical memory
(i. e. it's part of a file -- such as an executable or a shared
library -- that wasn't already mapped). In this case, it will set up
the mapping in the process's page table and continue the process from
where it left off. Unless there's a really nasty kernel bug, this
should be undetectable by the process.
3) It can determine that the virtual address in question is not
currently in physical memory. In this case, it will need to find the
page on disk and bring it into physical memory, and set up the
mapping, and resume the process. Again, the process should not be
able to detect this. The process may be able to infer this by means
of a time delay (e. g. it took 10 milliseconds to access this memory
location -- that's probably a page fault, although the kernel might
have decided to preempt the process for entirely different reasons).
Notice that at no point in this scenario does the user process have
any idea whether the virtual address it accessed was mapped, or how.
Nor does it matter how wide the virtual address is, or how wide the
physical address is. It's simply a mapping. Each virtual address
maps to zero or one physical addresses, but there's no isomorphism
here at all. Indeed, many different virtual addresses can map to the
> It does not seem to be a reasonable idea to start tying the OS to an
> odd-ball addressing mode that will hurt portability later, particularly
> when:
Linus's point is that mapping all of physical memory into virtual
address space makes management of physical memory in the kernel a lot
easier and more efficient. This is indeed a serious enough
consideration, but there are no user-space ramifications here (other
than possibly slower I/O or context switching).
--
Robert Krawitz <[EMAIL PROTECTED]> http://www.tiac.net/users/rlk/
Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail [EMAIL PROTECTED]
"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton
------------------------------
From: Lawrence Fan <[EMAIL PROTECTED]>
Subject: AAA: testing
Date: Thu, 04 Mar 1999 19:17:03 GMT
Testing. Please ignore.
=========================================================================
Lawrence Fan Phone: (908)595-6400
x3978
ViaGate Technologies Fax:
(908)595-6410
757 Route 202/206, Bridgewater, NJ 08807 E-mail:
[EMAIL PROTECTED]
------------------------------
From: yhauser <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.misc,alt.os.linux,comp.os.linux
Subject: es1788
Date: Fri, 05 Mar 1999 18:25:05 +0100
I'm trying to configure my es1788 soundcard for a 2.0.33 kernel. I chose
to install the card as a module - sound blaster - , but by checking the
/dev/sndstat file there is no audio device listed, although the card
config lines are not in (). What went wrong?
yves
------------------------------
From: "Martin" <[EMAIL PROTECTED]>
Crossposted-To: alt.os.linux,comp.os.linux,comp.os.linux.questions
Subject: Re: 16bit mode in XWindows
Date: Thu, 4 Mar 1999 19:30:46 -0000
Reply-To: "Martin" <[EMAIL PROTECTED]>
Dave Philips wrote in message ...
>On Wed, 3 Mar 1999, Keith A. Folske wrote:
>
>| How do I force XWindows to start in 16bit mode? It always starts in 8bit
>| mode and I know my hardware is capable of 16.
>
>startx -- -bpp 16
>
This can be made the default by editing the file /usr/bin/startx. Near the
top of the file is the following line :-
serverargs=""
change this line to read :-
serverargs="-bpp 16"
now the server will automatically start in 16 bpp mode
>dave
>
Martin
------------------------------
From: "Ivan Chan" <[EMAIL PROTECTED]>
Subject: Re: Intel 740 Help
Date: Sat, 6 Mar 1999 01:26:49 +0800
u may try this link
ftp://sunsite.utk.edu/pub/redhat/XBF/
Kaveh Milaninia <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
>All,
>
> Does anyone know how to get an Intel 740 Graphics card to work with
>Linux X11 or does anyone have any drivers for it.I searched for in on
>the redhat website, but all the link of relevance seem to be broken. If
>anyone could help me out with this problem I would really appreciate it.
>
> Thanks
>
>
------------------------------
From: Dave Swegen <[EMAIL PROTECTED]>
Subject: Re: Toshiba CDROM can't read videoCD
Date: Thu, 04 Mar 1999 18:59:47 +0000
My suggestion is that you try a newer kernel. It worked for me...
Cheers
Dave
Gerrit Hiddink wrote:
>
> Hi,
>
> I recently bought a notebook. It has a Toshiba XM-1802b CDROM drive,
> IDE/ATAPI, which works like a charm. Except... it doesn't read the
> avseq*.dat files on video CD's. I'm getting a whole bunch of hdc
> device errors (Sense key=0x05 and that kind of stuff).
>
> I checked some FAQs and stuff, and now I know that in order for the
> drive to be able to read such a disk, it has to be CDROM/XA and/or
> PhotoCD compatible. I checked the toshiba website, and indeed the
> drive can do this kind of stuff. It is also Whitebook VideoCD
> compatible. So why doesn't it do what it was told to do?
>
> Anyone has a clue as to what may cause this, and more importantly,
> how to fix it?
>
> Grit
--
Dave Swegen | Debian 2.0 on Linux i386 2.2.1
<[EMAIL PROTECTED]> | PGP key available on request
<[EMAIL PROTECTED]> | Linux: The Choice of a GNU Generation
======================================================================
------------------------------
From: Dirk Arnold <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.misc
Subject: notebook graphics support
Date: Fri, 05 Mar 1999 18:07:37 +0100
I need some buying advice for a notebook to be run under Linux. I am
planning to use OpenGL a lot, so at least decent 3D graphics support is
important. I understand there is only a handful of graphics chips for
notebooks around (Neomagic, S3 Virge, ATI Rage Pro, SMI Lynx E, C&T),
and
that some offer better hardware support than others. However, I imagine
that good hardware support is not of much use if the drivers don't make
use
of it. Can anyone recommend a good choice? As far as I can tell the ATI
Rage
Pro is the most powerful chip around for notebooks, but is it worth it
when
considering the available drivers? Any help appreciated!
Dirk
------------------------------
From: Anatol Quabach <[EMAIL PROTECTED]>
Subject: Re: Problems with ESS1938
Date: Thu, 04 Mar 1999 14:27:35 +0100
Neville Dalal wrote:
> Can anyone configure the ES1938 to work under Linux 2.2.1, I get the
> problem of two devices trying to share one IRQ of 5. Please email me
> with any help or advice.
Are you talking about the mixer and the MPU interface
conflicting? I had this prob with my ES1788. Try isapnptools
if it's ISA and try to run both the sb module and a separate
mpu401 module with the latter using an unused fake IRQ and
the former using the real IRQ.
If there is a dos partition available or you can get your
hands on a dos boot disk (6.22 will do), get esscfg.exe from
ESS' site (www.esstech.com, look for the downloadable
drivers page). It's a DOS tool for configuration of the card
for the 17xx and (I think) some of the 18xx cards. If it
works with your 19xx too, you could use it to configure the
card and then loadlin into Linux. Although this is not very
handy in the long run, it might help you to figure out how
to get the card working.
HTH
--
Anatol Quabach <[EMAIL PROTECTED]>
------------------------------
From: Ashley W Campbell <[EMAIL PROTECTED]>
Subject: bttv problems w/ stb tvpci
Date: Fri, 5 Mar 1999 12:34:30 -0500
I have a STB TV-PCI, and I am not able to get sound out of the thing.
These are the settings in my "update" script:
xinsmod videodev
xinsmod i2c verbose=1 scan=1 i2c_debug=0
test -f i2c_chardev.o && xinsmod i2c_chardev
xinsmod tuner debug=0 type=2
xinsmod msp3400
xinsmod bttv radio=1
And this is the kernel output I get from dmesg:
i2c: device detached: tuner (addr=0xc6, bus=bt848-0, driver=tuner)
i2c: bus unregistered: bt848-0
i2c: driver unregistered: msp3400
i2c: driver unregistered: tuner
Linux video capture interface: v0.01 ALPHA
i2c: initialized (i2c bus scan enabled)
i2c: driver registered: tuner
i2c: driver registered: msp3400
bttv0: Brooktree Bt848 (rev 18) bus: 0, devfn: 112, irq: 10, memory:
0xf0001000.
PCI: Enabling bus mastering for device 00:70
bttv: 1 Bt8xx card(s) found.
bttv0: PLL: 28636363 => 35468950 ... ok
bttv: readee error
bttv0: Hauppauge eeprom: tuner= (4)
bttv0: audio chip: TDA9850
bttv0: model: BT848A(Hauppauge old)
i2c: bus registered: bt848-0
i2c: scanning bus bt848-0: found device at addr=0x80
i2c: scanning bus bt848-0: found device at addr=0xb6
i2c: scanning bus bt848-0: found device at addr=0xc6
i2c: device attached: tuner (addr=0xc6, bus=bt848-0, driver=tuner)
msp3400: I/O error, trying reset (read Audio 0x1e)
msp3400: I/O error, trying reset (read Audio 0x1f)
msp3400: error while reading chip version
bttv0: PLL: switching off
Has anyone seen this before, or is there any more information i need to
provide?
Thanks in advance.
-Ashley Campbell
http://dino.res.cmu.edu
------------------------------
From: Tommy <[EMAIL PROTECTED]>
Crossposted-To: alt.os.linux.caldera,alt.os.linux,alt.linux.sux,alt.linux
Subject: Re: dhcpd.conf
Date: Thu, 04 Mar 1999 14:37:40 -0500
Sorry I dont have my config with me, but the sub net should be
255.255.255.0 (flat class C)
and if you wanted to you could assign 192.168.1.2-254
Now if there are multiple NICs in the machine you will have to configure ranges
for both of them, if you do not want the other to provide IP's you leave it
blank, but you must have the section in the config file.
Hope this helped
TURBO1010 wrote:
> Can anyone post a dhcpd.conf file that I can use. Seems that I don't know
> what to put for subnet and netmask.
> The address on my ethernet is 192.168.1.1, I want the dhcp server to assign
> addresses between 192.168.1.2 and 192.168.1.5
> If anyone can help me, I would appreciate it, as I am new to networks.
> Thanks in advance
------------------------------
From: [EMAIL PROTECTED] (M. Buchenrieder)
Subject: Re: Modem on COM5?
Date: Fri, 5 Mar 1999 12:56:46 GMT
"Chris Harjo Jr." <[EMAIL PROTECTED]> writes:
>thanks brian,
>there are a lot of people out there do not know about the non support
>for PCI modems,
While the tone of the reply may be inappropriate, the content is
correct. This topic has been discussed to death during the last
year.
>i didn't, but i bought my modem 2 years ago. but nothing
>is impossible and i don't go for the quick fixes by just buying
>something. if i don't succeed at least i tried. NG's used to be for
>support and hopefully we can keep them that way.
They are. This doesn't mean, however, that you should not be doing your
homework first. NGs serve as a last resort in case you didn't find
an answer for your questions in the existing archives and/or your own
ISP's newsserver.
>Brian wrote:
>>
>> And just maybe you are very STUPID for replying to a very good question and
>> wasted your own bandwidth and time. What do you seem to gain by replying in
>> this manner? It took up your time and the individual did not get the answer
>> he was looking for. You are very agogant and an Asshole! Replys of this
>> nature help no one in this newsgroup. If you are not ready to give an
>> honest answer do not reply at all.
Fair enough.
>> This newsgroup is not being personnally
>> stored on your hard drive so do not act like repeated questions are taking
>> up your time or hard drive space.
Incorrect. They take up a lot of bandwidth and carrying them does cost
real money. But that's not the point. It is making it very hard to read
them, just because the same questions get posted again and again.
>> There are newbies out there that do not
>> wish to peruse the internet in search of an answer that might not be so
>> easily found. And as a mater of fact, there are only 8 messages that cover
>> linux and com5.
[...]
Sorry, but learning how to use a search engine is required to get
useful results. Try again with "modem" "PCI" "Linux" .
Michael
--
Michael Buchenrieder * [EMAIL PROTECTED] * http://www.muc.de/~mibu
Lumber Cartel Unit #456 (TINLC) & Official Netscum
Note: If you want me to send you email, don't mungle your address.
------------------------------
From: [EMAIL PROTECTED] (M. Buchenrieder)
Subject: Re: install - scsi cdrom not found on 2940
Date: Fri, 5 Mar 1999 12:48:05 GMT
Mike Hom <[EMAIL PROTECTED]> writes:
>I have a PC I've been tasked with setting up Linux on and I'm stuck.
>The Adaptec 2940UW finds the Matshita CR-506 in its bios scan
>but when Linux installation probes the 2940 it only sees hda (HD)
>while OS/2 sees it fine.
[...]
You most probably did mess up the termination. If both the HD and
the CDROM are the only and/or last devices on their chains, both have
to be actively terminated, and the controller's internal termination
has to be disabled. If not, it won't work.
Michael
--
Michael Buchenrieder * [EMAIL PROTECTED] * http://www.muc.de/~mibu
Lumber Cartel Unit #456 (TINLC) & Official Netscum
Note: If you want me to send you email, don't mungle your address.
------------------------------
From: [EMAIL PROTECTED] (hexdump)
Subject: Re: Sound card and modem under Red Hat 5.2
Date: 4 Mar 1999 20:03:28 GMT
Reply-To: [EMAIL PROTECTED]
On Thu, 4 Mar 1999 04:31:20 +0100, Miomir G. Radovanovic wrote:
>How to install sound card and modem under Red Hat 5.2?
>Installing process doesn't include these devices.
>
>Thanks in advance.
> Miomir G. Radovanovic
> Belgrade, Serbia
>
>
For sound, try running setup as root.
For modem, try creating a symbolic link:
ln -s /dev/cua0 /dev/modem
(replace cua0 with what ever is appropriate for your system)
Hope that helps,
Hexdump
--
Mate, this parrot wouldn't VOOM if you put four million volts through it!
-- Monty Python
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and comp.os.linux.hardware) via:
Internet: [EMAIL PROTECTED]
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Hardware Digest
******************************
