Re: Drivers

Re: Drivers

[Charles Coffing]

[-- Attachment #1.1: Type: text/plain, Size: 2633 bytes --]

Related to this, I wrote a little script that disassembles the kernel
and drivers, looking for privileged instructions.  (The BUG macro must
first be modified to avoid many false positives, however.) 
 
It turned up a problem in the file
linux-2.6.8.1/drivers/mtd/maps/nettel.c.  I've attached a patch -- can
we put this in the patches directory? 
 
I also noticed a number of scary things in the kernel itself (moves
to/from CR4, various CLI/STI pairs, maybe some others but I forget ATM)
but it appears that these are avoided at runtime.  Some of these could
and probably should be cleaned up, though, since they exist in the
arch/xen tree.  I'll come back with some more details on this. 
 
Thanks. 
 


>>>Ian Pratt <Ian.Pratt@cl.cam.ac.uk> 10/25/04 2:11 pm >>>
>Do we have a list of drivers that have been validated to work in a Xen
>environment. Equally important would be the list of drivers that we
know
>have some issues working in a Xen environment.

Pretty much all the drivers built into the current dom0 config
have been booted on some machine and found to work.

There have been some reports of a strange issue involving the
e100 driver and the debian startup scripts, but we haven't
reproduced locally and there seems to be a good workaround. If
someone sends us an oops message its probably trivial to fix.

I've actually been impressed (amazed!) at how few problems we've
found with Linux drivers running over Xen. We're certainly rather
stricter than what's possible to get away with on native x86, but
I guess the ubiquity of PCI has meant that most popular drivers
have been debugged on sparc/alpha/ia64/ppc and have had the bogus
assumptions beaten out of them.

The only hardware drivers known to have problems are agpgart and
drm. The patch directory contains a few patches that fix some
obvious bugs, but more work is required. The xfree86 server VESA
driver doesn't work due to it requiring support for vm86 mode.
Stephan is looking into this.

The other driver that I know we have an issue with is the cisco
linux-iscsi initiator on 2.4. There's a workaround by setting
hacking the driver to set DISABLE_CLUSTERING. The 2.6 iscsi
driver works fine.


Ian



-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give
us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out
more
http://productguide.itmanagersjournal.com/guidepromo.tmpl

Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel


[-- Attachment #1.2: Type: text/html, Size: 3531 bytes --]

[-- Attachment #2: nettel.patch --]
[-- Type: application/octet-stream, Size: 887 bytes --]

diff -ru linux-2.6.8.1/drivers/mtd/maps/nettel.c linux-2.6.8.1-xen0/drivers/mtd/maps/nettel.c
--- linux-2.6.8.1/drivers/mtd/maps/nettel.c	2004-10-21 15:59:29.000000000 -0600
+++ linux-2.6.8.1-xen0/drivers/mtd/maps/nettel.c	2004-10-22 09:12:17.000000000 -0600
@@ -270,7 +270,7 @@
 	maxsize = AMD_WINDOW_MAXSIZE;
 
 	*amdpar = SC520_PAR(SC520_PAR_BOOTCS, amdaddr, maxsize);
-	__asm__ ("wbinvd");
+	wbinvd();
 
 	nettel_amd_map.phys = amdaddr;
 	nettel_amd_map.virt = (unsigned long)
@@ -382,7 +382,7 @@
 	 */
 	intel1addr = intel0addr + intel0size;
 	*intel1par = SC520_PAR(intel1cs, intel1addr, maxsize);
-	__asm__ ("wbinvd");
+	wbinvd();
 
 	maxsize += intel0size;
 
@@ -408,7 +408,7 @@
 	intel1size = intel_mtd->size - intel0size;
 	if (intel1size > 0) {
 		*intel1par = SC520_PAR(intel1cs, intel1addr, intel1size);
-		__asm__ ("wbinvd");
+		wbinvd();
 	} else {
 		*intel1par = 0;
 	}

Drivers

[Kaushal Shriyan]

[-- Attachment #1: Type: text/plain, Size: 475 bytes --]

Hi

Can any one help me in getting drivers for on board Sound Card "C-Media
CMI9880L" on INTEL915G Mother Board under RHEL3.0 base kernel --->
2.4.21-4.EL.

RHEL3.0 --> Red Hat Enterprise Linux 3.0

-- 
Regards,

Kaushal Shriyan
Technical Engineer
Red Hat India Pvt. Ltd.
135, Mittal Towers
13th Floor, B Wing
Nariman Point
Mumbai 400021
India
Tel    : +91-22-22881326/27
Fax    : +91-22-22881318
Cell   : +91-9820367783
E-mail : kshriyan@redhat.com


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Drivers

[Ian Pratt]

> Related to this, I wrote a little script that disassembles the kernel
> and drivers, looking for privileged instructions.  (The BUG macro must
> first be modified to avoid many false positives, however.) 

That's certainly a useful exercise. 
  
> It turned up a problem in the file
> linux-2.6.8.1/drivers/mtd/maps/nettel.c.  I've attached a patch -- can
> we put this in the patches directory? 

Definitely -- remind me if it doesn't appear soon.

> I also noticed a number of scary things in the kernel itself (moves
> to/from CR4, various CLI/STI pairs, maybe some others but I forget ATM)
> but it appears that these are avoided at runtime.  Some of these could
> and probably should be cleaned up, though, since they exist in the
> arch/xen tree.  I'll come back with some more details on this. 

Because of the 'minimum changes' approach we've taken to the 2.6
port there's a certain amount of code that's compiled in but
never used. Hopefully these instructions will be on those paths,
but it would be nice to have a list of them to verify.
If/when we're in the mainstream kernel tree we can take a more
aggressive approach about cleaning things up.

Ian


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl

Drivers

[Ky Srinivasan]

Do we have a list of drivers that have been validated to work in a Xen
environment. Equally important would be the list of drivers that we know
have some issues working in a Xen environment.

Thanks,

K. Y


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl

Re: Drivers

[Ian Pratt]

> Do we have a list of drivers that have been validated to work in a Xen
> environment. Equally important would be the list of drivers that we know
> have some issues working in a Xen environment.

Pretty much all the drivers built into the current dom0 config
have been booted on some machine and found to work. 

There have been some reports of a strange issue involving the
e100 driver and the debian startup scripts, but we haven't
reproduced locally and there seems to be a good workaround. If
someone sends us an oops message its probably trivial to fix. 

I've actually been impressed (amazed!) at how few problems we've
found with Linux drivers running over Xen. We're certainly rather
stricter than what's possible to get away with on native x86, but
I guess the ubiquity of PCI has meant that most popular drivers
have been debugged on sparc/alpha/ia64/ppc and have had the bogus
assumptions beaten out of them.

The only hardware drivers known to have problems are agpgart and
drm. The patch directory contains a few patches that fix some
obvious bugs, but more work is required. The xfree86 server VESA
driver doesn't work due to it requiring support for vm86 mode.
Stephan is looking into this.

The other driver that I know we have an issue with is the cisco
linux-iscsi initiator on 2.4. There's a workaround by setting
hacking the driver to set DISABLE_CLUSTERING. The 2.6 iscsi
driver works fine.


Ian



-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl

Re: Drivers

[Rik van Riel]

On Mon, 25 Oct 2004, Ian Pratt wrote:

> The only hardware drivers known to have problems are agpgart and
> drm.

And a bunch of old ISA drivers that need isa_virt_to_bus.
Chances are the only one people will notice here is the
floppy driver - but I haven't heard any complaints yet, so ;)

-- 
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan



-------------------------------------------------------
This Newsletter Sponsored by: Macrovision 
For reliable Linux application installations, use the industry's leading
setup authoring tool, InstallShield X. Learn more and evaluate 
today. http://clk.atdmt.com/MSI/go/ins0030000001msi/direct/01/

Re: Drivers

[Ian Pratt]

> On Mon, 25 Oct 2004, Ian Pratt wrote:
> 
> > The only hardware drivers known to have problems are agpgart and
> > drm.
> 
> And a bunch of old ISA drivers that need isa_virt_to_bus.
> Chances are the only one people will notice here is the
> floppy driver - but I haven't heard any complaints yet, so ;)

Yes, good point. I guess this could cause problems for some older
PCMCIA devices too.

However, since we now give dom0 a direct map of the bottom 1MB of
memory (starting at PAGE_OFFSET) it may be trivial to implement
isa_virt_to_bus e.g. as virt_to_phys as per normal i386.

Anyone still got a floppy drive to try this out on? ;-)

Ian


-------------------------------------------------------
This Newsletter Sponsored by: Macrovision 
For reliable Linux application installations, use the industry's leading
setup authoring tool, InstallShield X. Learn more and evaluate 
today. http://clk.atdmt.com/MSI/go/ins0030000001msi/direct/01/

Re: Drivers

[Keir Fraser]

> > On Mon, 25 Oct 2004, Ian Pratt wrote:
> > 
> > > The only hardware drivers known to have problems are agpgart and
> > > drm.
> > 
> > And a bunch of old ISA drivers that need isa_virt_to_bus.
> > Chances are the only one people will notice here is the
> > floppy driver - but I haven't heard any complaints yet, so ;)
> 
> Yes, good point. I guess this could cause problems for some older
> PCMCIA devices too.
> 
> However, since we now give dom0 a direct map of the bottom 1MB of
> memory (starting at PAGE_OFFSET) it may be trivial to implement
> isa_virt_to_bus e.g. as virt_to_phys as per normal i386.
> 
> Anyone still got a floppy drive to try this out on? ;-)

The mapping of ISA space is actually in the fixmap
region. Furthermore, it is only the lowest 1MB of memory -- but I
think the isa_* macros can be used for the lowest 16MB.

 -- Keir


-------------------------------------------------------
This Newsletter Sponsored by: Macrovision 
For reliable Linux application installations, use the industry's leading
setup authoring tool, InstallShield X. Learn more and evaluate 
today. http://clk.atdmt.com/MSI/go/ins0030000001msi/direct/01/

Re: Drivers

[A Streetcar Named]

Rik van Riel <riel <at> redhat.com> writes:

> 
> On Mon, 25 Oct 2004, Ian Pratt wrote:
> 
> > The only hardware drivers known to have problems are agpgart and
> > drm.
> 
> And a bunch of old ISA drivers that need isa_virt_to_bus.
> Chances are the only one people will notice here is the
> floppy driver - but I haven't heard any complaints yet, so ;)
> 

I'm trying to compile a 2.6.9 dom0 kernel with 2.0 patches using a kernel
configuration as close as possible to debian's 2.6.8-1-k7 kernel.  Along the
way, I get a lot of isa_virt_to_bus_is_UNSUPPORTED errors similar to the below:

  CC [M]  drivers/net/lance.o
drivers/net/lance.c: In function `lance_probe1':
drivers/net/lance.c:564: error: `isa_virt_to_bus_is_UNSUPPORTED' undeclared (fir
st use in this function)
drivers/net/lance.c:564: error: (Each undeclared identifier is reported only onc
e
drivers/net/lance.c:564: error: for each function it appears in.)
drivers/net/lance.c: In function `lance_open':
drivers/net/lance.c:780: error: `isa_virt_to_bus_is_UNSUPPORTED' undeclared (fir
st use in this function)
drivers/net/lance.c: In function `lance_init_ring':
drivers/net/lance.c:875: error: `isa_virt_to_bus_is_UNSUPPORTED' undeclared (fir
st use in this function)

So I guess that hits the problem that Rik mentioned above.  I also had this
problem for synclinc.c and floppy.h, so I rgrep'ed for isa_virt_to_bus in the
kernel tree :

drivers/net/lance.c
drivers/net/cs89x0.c
drivers/net/ni65.c
drivers/net/3c505.c
drivers/net/3c515.c
drivers/net/3c527.c
drivers/char/esp.c
drivers/char/tpqic02.c
drivers/char/synclink.c
drivers/scsi/mca_53c9x.c
drivers/scsi/wd7000.c
drivers/scsi/ibmmca.c
drivers/scsi/aha1542.c
drivers/scsi/ultrastor.c
drivers/block/ps2esdi.c
include/asm/io.h
include/asm/floppy.h
include/.asm-ignore/asm/io.h
include/.asm-ignore/asm-i386/io.h
include/asm-x86_64/io.h
include/asm-x86_64/floppy.h
include/asm-i386/io.h
include/asm-i386/floppy.h
include/asm-mips/io.h
include/asm-arm/io.h
include/asm-xen/asm/io.h
include/asm-xen/asm-i386/io.h

So I guess these are the specific ones to watch out for.  Is it safe for me to
just remove each of the above (lance, cs89x0, floppy, etc) from the kernel
configuration?  Also, lots of things include <asm/io.h> - is that safe?

Ian mentioned that it may be trivial to implement isa_virt_to_bus; if you do, I
have floppies to test it out on ;)



-------------------------------------------------------
This SF.Net email is sponsored by: InterSystems CACHE
FREE OODBMS DOWNLOAD - A multidimensional database that combines
robust object and relational technologies, making it a perfect match
for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8