lkml.org 
[lkml]   [1996]   [Sep]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: test version of 2.1.0 available
Wahoo!!! We are finally starting in 2.1.x!!! I can tell you about my
experiences so far very simply... It didn't work at all. :-( I use
loadlin to boot from an M$-DOS 6.22 boot menu (this makes my wife
happy). I just glanced through the source for loadlin, and it _DOES_
use hardware addresses to address kernel addresses, which means it is
horribly broken using the new kernel. Other then rebooting instantly,
it worked great. ;-) I suppose I will need to install lilo to get it to
boot. I would try to hack loadlin to make it work, but I am supposed to
turn in my thesis prospectus this week...
-Erik
--
Erik B. Andersen Web: http://www.et.byu.edu/~andersee/
2485 South State St. email: andersee@et.byu.edu
Springville, Ut 84663 phone: (801) 489-1231
--This message was written using 73% post-consumer electrons--


Linus Torvalds wrote:
>
> Could people who are doing device drivers and other people that just want
> to live dangerously check out the new pre-2.1.0.gz file that I just put
> out for ftp on
>
> ftp://ftp.cs.helsinki.fi/pub/Software/Linux/Kernel/testing/pre-patch-2.1.0.gz
>
> (It's _currently_ has a md5sum of 92eb12e2275dd75fb14f6538d1a4e03d and is
> 28265 bytes long, but I might be updating it).
>
> The new thing with the 2.1.x tree is that the kernel no longer uses the x86
> segmentation to access user mode, but instead the kernel segment covers the
> whole 4GB virtual address space, and thus accesses to user memory can be made
> faster.
>
> NOTE! When you access user memory you still have to use the "get_user()" etc
> helper functions, exactly as before, because those can still do strange
> things on other architectures. The new thing is just a x86 _implementation_
> issue, not a change in the basic philosophy (you'll notice that most of the
> changes are to x86-specific files).
>
> The thing about the new memory management setup is that it gets rid of a lot
> of extra fluff that isn't needed, and makes things potentially faster.
> However, there is one downside to all this, and that is the fact that the
> kernel address space is no longer identical to the hardware address space.
>
> For example, to access hardware address 0xA0000, you can no longer just do
> something like this:
>
> value = (unsigned char *) 0xA0000;
>
> but instead you have to use something like this:
>
> value = readb(0xA0000);
>
> Note that I called this a "downside", but in actual fact it's a good thing.
> The reason that it's a good thing is that the drivers should have been using
> readb() already - that's the portable interface, and that's how you have to
> access PCI shared memory on alpha and PPC machines. In fact, most drivers
> have already been converted to use this interface, but there are certainly
> drivers out there that will break horribly by my pre-patch. That's why I'd
> like driver authors (and technical people who want to test) to try out the
> pre-patch.
>
> Drivers that should work already (because they work on alpha's - the ones
> marked with (*) have actually been tested by me on my PC with the pre-patch):
>
> - VGA console (*)
> - IDE harddisk and CD-ROM (*)
> - normal serial lines (*)
> - keyboard (*)
> - 3c509 network card (*)
> - floppy driver (*)
> - PS/2 mouse
> - de4x5 and ne2000 network cards
> - original ncr scsi drivers
> - BSD ncr SCSI driver (at least with IO-mapped accesses)
> - Aha1740, BusLogic and QLogic ISP SCSI drivers
>
> Other drivers are in the "may well work" category, but I cannot give any
> guarantees. If some driver doesn't work, you're likely to find out sooner
> rather than later (they generally break totally - it's not going to be
> subtle).
>
> I'd love to get reports on these patches, and would be even happier if you
> can also send a patch that actually fixes any broken behaviour. Things
> that can break are:
> - accessing device memory though a pointer
> FIX: use readb/writeb/memcpy_fromio/memcpy_toio instead of trying to
> dereference the pointer directly.
> - using virtual addresses for controller-initiated DMA
> FIX: use the "virt_to_bus()" function to change a virtual address into
> a "bus" address to give to controllers that do DMA into memory.
> - memory re-mapping may be broken right now, so anything that needs
> "vremap()" probably doesn't work. If you have a driver that breaks due
> to this, please test changing the line (line 187 in mm/vmalloc.c)
>
> set_pte(pte, mk_pte(offset, PAGE_KERNEL));
>
> to do a
>
> set_pte(pte, mk_pte(offset+PAGE_OFFSET, PAGE_KERNEL));
>
> and see if that helps?
>
> Comments? Success stories? Hate mail? Money?
>
> Linus

\
 
 \ /
  Last update: 2005-03-22 13:38    [from the cache]
©2003-2011 Jasper Spaans