eepro100 problem [was: Re: test10-pre1 problems on 4-way SuperServer8050]
Hi, On Thu, Oct 12, 2000 at 02:19:27PM +0100, Tigran Aivazian wrote: > Having done a few more reboots I got more info -- one of the eepro100 > interfaces is dead only in 4 out 5 cases. So, sometimes, doing ifdown eth0 > ; ifup eth0 does help. Tigran, please check if you have any driver's messages, in particular, "card reports no resources". There is a known problem which fits the sympomes described by you. Dragan Stancevic <[EMAIL PROTECTED]> was going to look at Intel's errata about this matter. > > So, the latest status: all 6G of RAM work fast but the onboard eepro100 > interface, often, doesn't work. This starts to look like eepro100-driver > related so I copied Andrey Savochkin. Btw, one of my colleagues also > reported a similar situation on his quad Xeon with 6G RAM whereby one of > the eepro100 interfaces was dead until one restarts it. > > Starting to fiddle with eepro100.c now... Best regards Andrey - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: IRQ affinity vs. MTRRs, was Re: 36 bit MTRRs, Re: test10-pre1problems on 4-way SuperServer8050
On Thu, 12 Oct 2000, James Simmons wrote: > > > > every CPU to avoid slowdowns. So that if you set that eth0's > > > IRQ will be handled by CPU1, the MTRRs of CPU1 will be set > > > accordingly, and the other CPUs will not care about eth0, > > > so they do not need eth0's MTRR settings. > > > > A little question. Why do we want to bind irq of eth0 to a single CPU ? > > imho it will casue slowdown of some situation. Why don't we leave scheduler > > to select CPU for processing IRQ ? > > This would be really horrible for video cards. X would come to a crawl :-( Why? You are not forced to exclude the videocard memory from MTRRs. I meant things that make sense, e.g. 4 eth card, 4 CPUs, every CPU is bound to one and only one eth, so only the relevant CPU needs to contain an entry for the eth it is bound to. It may make sense. Regards, Zoltan Boszormenyi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel 2.2.18 and GCC versions
On Fri, Oct 13, 2000 at 12:26:02AM +0100, Alan Cox wrote: > egcs-1.1.2 builds 2.2.18pre. I know this because thats the compiler I use > to build it. Its also the recommended compiler. What do you mean by _the_ recommended compiler? Is 2.7.2.3 recommended no more? Is there some benefit using egcs-1.1.2 instead of 2.7.2.3? Should Changes be changed? 2.2.18pre15: Version 1.1.2 seems okay; if you have to have a binary, you may be successful using that. In general, however, gcc-2.7.2.3 is known to be stable, while egcs and others have not been as thoroughly tested yet. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Incorrect UDMA timing on VIA vt82c596b
On Tue, 10 Oct 2000, Vojtech Pavlik wrote: > On Tue, Oct 10, 2000 at 12:20:07PM -0400, Mark Hahn wrote: > > > > Btw, reading the ATA/ATAPI-6 specs I think UDMA66 should work on a > > > setup where would be just one drive and a really short, 40-wire cable > > > without problems as well. I've even seen systems shipped like that. > > > > uh, what part of the spec leads you to that conclusion? > > I've haven't seen a draft more recent than ~1h2000, but > > they've been unambiguous about absolutely requiring > > 80-conductors for >= ata66, and that two-connector cables > > must be 5<=l<=18, and three-connector cables 10<=l<=18. > > ATA/ATAPI-6 draft rev. 0a, page 14 (sheet 28 of 404), table 2, row 4, > column 1, plus comment 4 in the same table. > > And from the engineering point of view, it seems reasonable, too. Hi Mark, This is the stuff that is not clearly drafted the shews. You need the stuff I am forwarding to get the twist. Less the kernel list. Cheers, Andre Hedrick The Linux ATA/IDE guy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: calling system call from kernel module
>> Is there any way to call system call from a kernel module??? >yes, just call it. system calls are just functions (mostly exported and >when otherwise, use sys_call_table[] which is exported, but it won't work >on __mips__) so you can just call them. thanks tigran, but i am new to kernel programming and can you please tell me how to pass arguments. suppose i want to open a file than soemthing like sys_call_table[__NR_OPEN] should be used, but i am unable to figure out how to pass the arguments. thanks again, anil - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Updated Linux 2.4 Status/TODO List (from the ALS show)
On Thu, 12 Oct 2000, David S. Miller wrote:
>
>page_table_lock is supposed to protect normal page table activity (like
>what's done in page fault handler) from swapping out.
>However, grabbing this lock in swap-out code is completely missing!
>
> Audrey, vmlist_access_{un,}lock == unlocking/locking page_table_lock.
Yeah, it's an easy mistake to make.
I've made it myself - grepping for page_table_lock and coming up empty in
places where I expected it to be.
In fact, if somebody sends me patches to remove the "vmlist_access_lock()"
stuff completely, and replace them with explicit page_table_lock things,
I'll apply it pretty much immediately. I don't like information hiding,
and right now that's the only thing that the vmlist_access_lock() stuff is
doing.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Updated Linux 2.4 Status/TODO List (from the ALS show)
On Thu, 12 Oct 2000, David S. Miller wrote: > >Any of the mm gurus give the patch below a quick once over ? Is >this adequate, or is there more to this than the description >implies? > > It might make more sense to just make rss an atomic_t. Agreed. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
kmap for dma buffer
hi all, For dma transfers to/from user space buffer, one need to lock that user space buffer so that it won't be swaped out. and also its bus address is obtained by call virt_to_bus and then this bus address is written to dma controller. but do we explicitly need to map that user buffer into kernel space by calling kmap after obtaining the user buffer's page struct?? thanks. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Updated Linux 2.4 Status/TODO List (from the ALS show)
On Thu, Oct 12, 2000 at 09:25:47PM -0700, David S. Miller wrote:
>Date: Fri, 13 Oct 2000 12:34:30 +0800
>From: Andrey Savochkin <[EMAIL PROTECTED]>
>
>page_table_lock is supposed to protect normal page table activity (like
>what's done in page fault handler) from swapping out.
>However, grabbing this lock in swap-out code is completely missing!
>
> Audrey, vmlist_access_{un,}lock == unlocking/locking page_table_lock.
>
> You've totally missed this and thus your suggested-patch/analysis
> needs to be reevaluated :-)
Oops
You're of course right.
It looks as if somebody tried to separate this two locks and stopped in the
middle...
Andrey
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Updated Linux 2.4 Status/TODO List (from the ALS show)
Date: Fri, 13 Oct 2000 12:34:30 +0800
From: Andrey Savochkin <[EMAIL PROTECTED]>
page_table_lock is supposed to protect normal page table activity (like
what's done in page fault handler) from swapping out.
However, grabbing this lock in swap-out code is completely missing!
Audrey, vmlist_access_{un,}lock == unlocking/locking page_table_lock.
You've totally missed this and thus your suggested-patch/analysis
needs to be reevaluated :-)
Later,
David S. Miller
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Updated Linux 2.4 Status/TODO List (from the ALS show)
Hello,
On Fri, Oct 13, 2000 at 01:20:23AM +0100, [EMAIL PROTECTED] wrote:
> > 9. To Do
> > * mm->rss is modified in some places without holding the
> > page_table_lock (sct)
>
> Any of the mm gurus give the patch below a quick once over ?
> Is this adequate, or is there more to this than the description implies?
The patch is basically ok, except one point.
[snip]
> diff -urN --exclude-from=/home/davej/.exclude linux/mm/vmscan.c linux.dj/mm/vmscan.c
> --- linux/mm/vmscan.c Mon Oct 2 20:02:20 2000
> +++ linux.dj/mm/vmscan.c Wed Oct 11 23:46:01 2000
> @@ -102,7 +102,9 @@
> set_pte(page_table, swp_entry_to_pte(entry));
> drop_pte:
> UnlockPage(page);
> + spin_lock (&mm->page_table_lock);
> mm->rss--;
> + spin_unlock (&mm->page_table_lock);
> flush_tlb_page(vma, address);
> deactivate_page(page);
> page_cache_release(page);
> @@ -170,7 +172,9 @@
> struct file *file = vma->vm_file;
> if (file) get_file(file);
> pte_clear(page_table);
> + spin_lock (&mm->page_table_lock);
> mm->rss--;
> + spin_unlock (&mm->page_table_lock);
> flush_tlb_page(vma, address);
> vmlist_access_unlock(mm);
> error = swapout(page, file);
> @@ -202,7 +206,9 @@
> add_to_swap_cache(page, entry);
>
> /* Put the swap entry into the pte after the page is in swapcache */
> + spin_lock (&mm->page_table_lock);
> mm->rss--;
> + spin_unlock (&mm->page_table_lock);
> set_pte(page_table, swp_entry_to_pte(entry));
> flush_tlb_page(vma, address);
> vmlist_access_unlock(mm);
page_table_lock is supposed to protect normal page table activity (like
what's done in page fault handler) from swapping out.
However, grabbing this lock in swap-out code is completely missing!
In vmscan.c the question is not only about rss protection, but about real
protection for page table entries.
It may be something like
--- mm/vmscan.c.ptl Fri Oct 13 12:09:51 2000
+++ mm/vmscan.c Fri Oct 13 12:19:10 2000
@@ -150,6 +150,7 @@
if (file) get_file(file);
pte_clear(page_table);
vma->vm_mm->rss--;
+ spin_unlock(&mm->page_table_lock);
flush_tlb_page(vma, address);
vmlist_access_unlock(vma->vm_mm);
error = swapout(page, file);
@@ -182,6 +183,7 @@
/* Put the swap entry into the pte after the page is in swapcache */
vma->vm_mm->rss--;
set_pte(page_table, swp_entry_to_pte(entry));
+ spin_unlock(&mm->page_table_lock);
flush_tlb_page(vma, address);
vmlist_access_unlock(vma->vm_mm);
@@ -324,6 +326,7 @@
if (address < vma->vm_start)
address = vma->vm_start;
+ spin_lock(&mm->page_table_lock);
for (;;) {
int result = swap_out_vma(mm, vma, address, gfp_mask);
if (result)
@@ -333,6 +336,7 @@
break;
address = vma->vm_start;
}
+ spin_unlock(&mm->page_table_lock);
}
vmlist_access_unlock(mm);
On Thu, Oct 12, 2000 at 05:29:39PM -0700, David S. Miller wrote:
>From: [EMAIL PROTECTED]
>Date: Fri, 13 Oct 2000 01:20:23 +0100 (BST)
>
>Any of the mm gurus give the patch below a quick once over ? Is
>this adequate, or is there more to this than the description
>implies?
>
> It might make more sense to just make rss an atomic_t.
In most cases where rss is updated page_table_lock is already held.
Best regards
Andrey
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: SMP irq sharing problem in 2.2.17
Timur Tabi wrote: > ** Reply to message from "Robert B. Easter" <[EMAIL PROTECTED]> on Thu, > 12 Oct 2000 18:47:22 -0400 > > > Since installing a > > second CPU and recompiling the kernel for SMP and recompiling ALSA with > > --with-smp=yes, the sound loops. I can hear the sound, but it doesn't > > continue to play normally, rather, a sample will loop over and over. > > This means that the driver is not receiving any IRQs from the hardware. > Typically, this is the result of an IRQ conflict (some other driver has claimed > the IRQ for your hardware, and its interrupt handler is getting called instead). > > -- > Timur Tabi - [EMAIL PROTECTED] > Interactive Silicon - http://www.interactivesi.com > > When replying to a mailing-list message, please don't cc: me, because then I'll just >get two copies of the same message. > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ The 694D defaults to MPS1.4. Make sure the 694D is configured for MPS1.1 and the problem will disappear. I had a similar problem with the USB driver assigned to IRQ19 but not receiving any interrupts. Perhaps someone more knowledgable can explain why linux fails under MPS1.4. -J. -- John Silva - [EMAIL PROTECTED] farm9 Intrusion Detection & Prevention http://www.farm9.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Updated 2.4 TODO List -- new addition WAS(test9 PCI resourcecollisions (fwd)
I am attaching the debug output on bootup after defining DEBUG in pci.c and the i386 pci header file with test10-pre2 Note: this is a Dell Lattitude docking station. The devices which are having resource problems are on the docking station. Works fine with 2.2 kernels. Yes, this is on RH7 with kgcc. Please dont distract the subject header if you wanna attack that specifi issue. Just change the header and start a new thread. cheers, jamal -- Forwarded message -- Date: Tue, 10 Oct 2000 19:56:46 -0400 (EDT) From: jamal <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], Martin Mares <[EMAIL PROTECTED]>, Linus Torvalds <[EMAIL PROTECTED]> Subject: Updated 2.4 TODO List -- new addition WAS(test9 PCI resource collisions (fwd) Ted, Please add this to your list. Linux is unusable in these machines. I have cc'ed Martin and Linus because they play in that PCI area. cheers, jamal -- Forwarded message -- Date: Thu, 5 Oct 2000 17:23:13 -0400 (EDT) From: jamal <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: test9 PCI resource collisions I have attached a few details of what appears to be a PCI resource alloc problem (IO ports from the look of it). Note: This is on a dell lattitude machine that never booted before with a docked setup. Enjoy! cheers, jamal Linux version 2.4.0-test10 (root@PCARD38C) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #4 Thu Oct 12 17:30:43 EDT 2000 BIOS-provided physical RAM map: BIOS-e820: 0009fc00 @ (usable) BIOS-e820: 0400 @ 0009fc00 (reserved) BIOS-e820: c000 @ 000c (reserved) BIOS-e820: 0fef @ 0010 (usable) BIOS-e820: 0001 @ 0fff (ACPI data) BIOS-e820: 0006 @ 100a (reserved) BIOS-e820: 0020 @ ffe0 (reserved) On node 0 totalpages: 65520 zone(0): 4096 pages. zone(1): 61424 pages. zone(2): 0 pages. Kernel command line: Initializing CPU#0 Detected 498.482 MHz processor. Console: colour VGA+ 80x25 Calibrating delay loop... 992.87 BogoMIPS Memory: 255768k/262080k available (1094k kernel code, 5924k reserved, 70k data, 188k init, 0k highmem) Dentry-cache hash table entries: 32768 (order: 6, 262144 bytes) Buffer-cache hash table entries: 16384 (order: 4, 65536 bytes) Page-cache hash table entries: 65536 (order: 6, 262144 bytes) Inode-cache hash table entries: 16384 (order: 5, 131072 bytes) CPU: Intel Pentium III (Coppermine) stepping 03 Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX mtrr: v1.36 (2221) Richard Gooch ([EMAIL PROTECTED]) PCI: BIOS32 Service Directory structure at 0xc00ffe80 PCI: BIOS32 Service Directory entry at 0xffe90 PCI: BIOS probe returned s=00 hw=01 ver=02.10 l=02 PCI: PCI BIOS revision 2.10 entry at 0xfc0ce, last bus=2 PCI: Using configuration type 1 PCI: Probing PCI hardware Scanning bus 00 Found 00:00 [8086/7190] 000600 00 Found 00:08 [8086/7191] 000604 01 Found 00:18 [104c/ac1c] 000607 02 Found 00:19 [104c/ac1c] 000607 02 Found 00:38 [8086/7110] 000680 00 Found 00:39 [8086/7111] 000101 00 PCI: IDE base address fixup for 00:07.1 Found 00:3a [8086/7112] 000c03 00 Found 00:3b [8086/7113] 000680 00 Found 00:88 [8086/124b] 000604 01 Fixups for bus 00 PCI: Scanning for ghost devices on bus 0 Scanning behind PCI bridge 00:01.0, config 010100, pass 0 Scanning bus 01 Found 01:00 [10c8/0006] 000300 00 Found 01:01 [10c8/8006] 000401 00 Fixups for bus 01 PCI: Scanning for ghost devices on bus 1 Bus scan for 01 returning with max=01 Scanning behind PCI bridge 00:03.0, config 00, pass 0 Scanning behind PCI bridge 00:03.1, config 00, pass 0 Scanning behind PCI bridge 00:11.0, config 020200, pass 0 Scanning bus 02 Found 02:08 [102b/051b] 000300 00 Found 02:28 [1095/0646] 000101 00 PCI: IDE base address fixup for 02:05.0 Found 02:38 [9004/6078] 000100 00 Found 02:40 [10b7/9050] 000200 00 Fixups for bus 02 PCI: Scanning for ghost devices on bus 2 Bus scan for 02 returning with max=02 Scanning behind PCI bridge 00:01.0, config 010100, pass 1 Scanning behind PCI bridge 00:03.0, config 00, pass 1 Scanning behind PCI bridge 00:03.1, config 00, pass 1 Scanning behind PCI bridge 00:11.0, config 020200, pass 1 Bus scan for 00 returning with max=0a PCI: IRQ init PCI: Interrupt Routing Table found at 0xc00fbd80 00:07 slot=00 0:00/ 1:00/ 2:00/ 3:63/def8 01:00 slot=00 0:60/def8 1:61/def8 2:00/ 3:00/ 00:03 slot=00 0:63/def8 1:63/def8 2:00/ 3:00/ 00:0d slot=00 0:62/def8 1:00/ 2:00/ 3:00/ 00:11 slot=00 0:62/def8 1:62/def8 2:62/def8 3:62/def8 PCI: Bus 01 already known PCI: Using IRQ router default [8086/1234] at 00:07.0 PCI: IRQ fixup PCI: Allocating resources PCI: Resource e000-e3ff (f=1208, d=0, p=0) PCI: Resource 0860-086f (f=101, d=0, p=0) PCI: Resource ece
Re: A patch to loop.c for better cryption support
On Fri, Oct 13, 2000 at 03:50:41AM +0100, Ian Stirling wrote: > > > > On Fri, Oct 13, 2000 at 04:19:49AM +, Ingo Rohloff wrote: > > > 2.4 has already broken backwards compatibility to 2.2 (IV changed > > from disk absolute to relative). When you change it now (before 2.4.0) > > it is relatively painless. I think the change is a good idea. > > I've been away from the list for a while, so this has probably been > discussed. > But, it seems to me that being able to have a different IV for > each filesystem would be a good thing, but having it depend on something > as volatile as sector of the disk, seems bad. > What about the first block of the underlying file holding an IV? > > Then, if a loopback mount attempt finds a valid IV block at the > start (heavily CRC'd or similar, so the likelyhood of it ever > finding false magic is negligable (Say 10^-50)) it mounts > the filesystem, using the IV found. > > Please tell me where the glaring error is :) The loop device does not support any metadata. Such stuff has to be stored somewhere else. If you want metadata in your loop encryption module you can just supply it with a private ioctl from losetup. I don't think such policy belongs in the main loop device, it already carries enough cruft. [if you wanted a loop device that supports metadata I would wait for the new LVM IBM promised to release someday -- it'll apparently support such things. But a simple user space solution looks cleaner to me for now.] Also the sector number AFAIK works fine as an IV as long as you use a cipher with a sufficiently big block size (e.g. one of the AES candidates with 128bit blocks). With short block sizes predictible IV is a bigger problem. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: A patch to loop.c for better cryption support
> > On Fri, Oct 13, 2000 at 04:19:49AM +, Ingo Rohloff wrote: > 2.4 has already broken backwards compatibility to 2.2 (IV changed > from disk absolute to relative). When you change it now (before 2.4.0) > it is relatively painless. I think the change is a good idea. I've been away from the list for a while, so this has probably been discussed. But, it seems to me that being able to have a different IV for each filesystem would be a good thing, but having it depend on something as volatile as sector of the disk, seems bad. What about the first block of the underlying file holding an IV? Then, if a loopback mount attempt finds a valid IV block at the start (heavily CRC'd or similar, so the likelyhood of it ever finding false magic is negligable (Say 10^-50)) it mounts the filesystem, using the IV found. Please tell me where the glaring error is :) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: A patch to loop.c for better cryption support
On Fri, Oct 13, 2000 at 04:19:49AM +, Ingo Rohloff wrote: > Hi again, > > Marc Mutz wrote: > > > > The loop device supports different IVs; > > > the IVs are initilized with the requested block > > > number. > > > > I believe a better way is to use the requested > > > sector number from CURRENT->sector. > > > Using this value should make the encryption and decryption > > > process completely independent from the underlying device. > > > Two times no. > > > > First: This breaks backward-compatibility. > Right, (I mentioned this), but the backward-compatible > way means: 2.4 has already broken backwards compatibility to 2.2 (IV changed from disk absolute to relative). When you change it now (before 2.4.0) it is relatively painless. I think the change is a good idea. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 0 size files in linux-2.2.17.tar.gz
[Jan-Benedict Glaw] > Your kernel was probably patched te become a 2.2.17. The "problem" > is diff. It can > - add lines > - remove lines > - add files > but it *cannot remove files. The only way to "remove" a file is to > delete all ist contents, but the (empty) file remains... You mean you don't use 'patch -E'? Hmmm, the kernel README file doesn't mention -E either. It also says to use -p0, which only works if your kernel directory is still named 'linux', which doesn't tend to last long when you start managing multiple trees. Alan, would you put this in 2.2.18pre? The '-p1' part isn't essential -- though it's a good habit to get into -- but '-E' can be in some cases. (Remember arch/i386/checksum.c?) Peter --- 2.2.15/README~ Mon Aug 9 14:04:38 1999 +++ 2.2.15/README Thu Oct 12 21:20:36 2000 @@ -54,15 +54,15 @@ latest kernel. - You can also upgrade between 2.2.xx releases by patching. Patches are - distributed in the traditional gzip and the new bzip2 format. To + distributed in the traditional gzip and the newer bzip2 format. To install by patching, get all the newer patch files and do - cd /usr/src - gzip -cd patchXX.gz | patch -p0 + cd /usr/src/linux + gzip -cd ../patchXX.gz | patch -Ep1 or - cd /usr/src - bzip2 -dc patchXX.bz2 | patch -p0 + cd /usr/src/linux + bzip2 -cd ../patchXX.bz2 | patch -Ep1 (repeat xx for all versions bigger than the version of your current source tree, _in_order_) and you should be ok. You may want to remove - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: A patch to loop.c for better cryption support
Hi again, Marc Mutz wrote: > > The loop device supports different IVs; > > the IVs are initilized with the requested block > > number. > > I believe a better way is to use the requested > > sector number from CURRENT->sector. > > Using this value should make the encryption and decryption > > process completely independent from the underlying device. > Two times no. > > First: This breaks backward-compatibility. Right, (I mentioned this), but the backward-compatible way means: You might get problems over NFS using a backing file. You get problems if you burn a backing file to a CD (at least that's what it says in the FAQ), or if you copy it to another partition with a different file system (which handles blocks differently) or ... Has anyone tried to use an encrypted backing file on ReiserFS. I would be interested if it works with the old patch set. I even created an encrypted ReiserFS in a backing file, which was hosted on an uncrypted ReiserFS. (ReiserFS doesn't care about sector boundries, so it is especially useful for testing in this case.) I bet that this won't work with the old approach. (Even if this might be, because the cryption algorithms don't care about block boundries too :-( ) I know it works with my approach because I tried (even over NFS). > Second: I don't know much of the block device handling > in Linux, but what you produced seems like a quick > shot. I can see this e.g. at the point where you > declare 'sector' to be 'int' (7th hunk), whereas in > include/linux/blkdev.h request.sector is declared > _unsigned_ int. Well ok, my fault. BUT: "unsigned int" and "int" have the same bit size right ? The crypto algorithms only care about the bits not the signedness (and if they do, they only have to interpret the IV as signed... no problem...) > I don't know what request.sector is for loop > devices (The block number of the underlying > filesystem, if any? The hard sector number of the > underlying blockdevice? Always the 512-byte-blocks > number?), but if it is not the latter, i.e. always > "position >> 9", you have just shifted the issue > from one level (the fs block size) to another > (whatever units sector is in). No I haven't. Because as you can see from the source: 1. The CURRENT->sector is the requested sector of the loop device, which has nothing (whatsoever) to do with the underlying backing medium (it is even independent, of using a backing file or device.) 2. It is ALWAYS assumed to be 512 bytes. (This doesn't change, even if the blocksize of the backing device is SMALLER than 512 bytes.) You got it right, it is (position >> 9). But "position" means requested position within the loop device, which is as I said completely independent of the backing medium. You can even have two DIFFERENT (using different passwords) encrypted filesystems in the same backing file. Both mounted at the same time. (For example in a 2Mb file you can use the first MB for the first FS and the second Mb for the second FS.) you can do that like this: dd if=/dev/zero of=crypt.tst bs=1024 count=2048 losetup -e twofish /dev/loop0 crypt.tst (give Password 1) losetup -e twofish -o 1048576 /dev/loop1 crypt.tst (give Password 2) mke2fs -b 1024 /dev/loop0 1024 mke2fs -b 1024 /dev/loop1 1024 mount /dev/loop0 /mnt1 mount /dev/loop1 /mnt2 BTW this is _tested_. It works. (And you can do it over NFS And you can burn crypt.tst to a CD without any problems.) Try this with the current approach... It won't work. > The better solution (for 2.2. and 2.4; in 2.5 Andries Brouwer has > something more clean in his mind, IIUHC) is to add a new field to struct > loop_info to indicate the encryption chunk size and patch losetup/mount > to set this to 512 by default and to the filesystem block size if asked > to by some command line switch. This allows people to convert their > stuff. This makes things more complicated. (It also gives you more choices, but I don't think that the choices are very useful. It only gives you a higher chance of corrupting your data.) Converting the stuff is not so difficult. Copy your encrypted stuff to somewhere else (if you like use PGP to crypt it anyway). Change kernel. Remake filesystem on crypted medium. Copy your stuff back. > You may want to join [EMAIL PROTECTED] (majordomo) if you want > to work on this. Ah thanks for the hint, I didn't know this mailing list. I hope it is not in dutch ? If it is I apologize for posting in english. (I can't speak dutch). so long Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
BTTV problem
Ookay, hopefully I've got the right place. I've seen everyone post bttv problems to lkml, so here it goes ;) I am currently running with 2.2.17 I modprobe the bttv drivers (output): Linux video capture interface: v1.00 i2c: initialized bttv0: Brooktree Bt848 (rev 17) bus: 0, devfn: 80, irq: 12, memory: 0xea001000. bttv: 1 Bt8xx card(s) found. bttv0: Hauppauge eeprom: tuner= (4) bttv0: audio chip: TDA9840 bttv0: audio chip: TDA9850 bttv0: audio chip: TDA8425 bttv0: fader chip: TEA6300 bttv0: model: BT848(Hauppauge old) So I start an app like xawtv: This is xawtv-3.21, running on Linux/i586 (2.2.17) visual: id=0x22 class=4 (TrueColor), depth=16 visual: id=0x23 class=5 (DirectColor), depth=16 x11: 1280x1024, 16 bit/pixel, 2560 byte/scanline, DGA waitpid: No child processes waitpid: No child processes v4l: 1280x1024, 16 bit/pixel, 2560 byte/scanline WARNING: v4l and dga disagree about the framebuffer base WARNING: Is v4l-conf installed correctly? ov_fbuf.base=(nil), base=0xe800 WARNING: overlay mode disabled wmhooks: gnome ioctl VIDIOCMCAPTURE(0,-,0x0): Invalid argument ioctl VIDIOCMCAPTURE(1,-,0x0): Invalid argument ioctl VIDIOCSYNC: Invalid argument ioctl VIDIOCSYNC: Invalid argument ioctl VIDIOCMCAPTURE(0,-,0x0): Invalid argument ioctl VIDIOCMCAPTURE(1,-,0x0): Invalid argument ioctl VIDIOCSYNC: Invalid argument ioctl VIDIOCSYNC: Invalid argument v4l: oops: got sigalarm ioctl VIDIOCSYNC: Interrupted system call And dmesg outputs: bttv: PCI display adapter: <3>bttv: Unknown video memory base address. does that 4 times. I've recompiled the kernel, xawtv, everything I can think of. I can't seem to figure out how to fix this :/ Ideas? Suggestions? Any help would be great. Genise. -- *** Genise Pearce <[EMAIL PROTECTED]> Project Manager (e.themes.org) I-Docs Eterm<[EMAIL PROTECTED]>Documentation and Web Development ICQ: 48031423 Eterm.I-Docs.org / E.Themes.org / www.Eterm.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Fix SCSI proc oops
Date:Thu, 12 Oct 2000 12:48:27 -0700 (PDT)
From: Linus Torvalds <[EMAIL PROTECTED]>
David, you know this code, would you mind giving it another pair of
eyes? I hate code that doesn't make sense.
Ok, the deal is that the tpnt->present handling during unregister is
really broken. There is no way for the "if" conditional in question
to differentiate between the following two cases:
1) No host adapters for this tpnt were ever registered
2) All host adapters for this tpns were successfully
removed by this loop above the test in question:
/* Next we go through and remove the instances of the individual hosts
* that were detected */
pcount0 = next_scsi_host;
for (shpnt = scsi_hostlist; shpnt; shpnt = sh1) {
Both events leave us with tpnt->present == 0, but only in the #2 case
do we want to do the unlink and procfs deletions.
It's very easy to fix, Torben can you try this (untested) patch?
--- drivers/scsi/scsi.c.~1~ Wed Oct 4 16:11:38 2000
+++ drivers/scsi/scsi.c Thu Oct 12 18:45:06 2000
@@ -1976,6 +1976,7 @@
struct Scsi_Host *sh1;
struct Scsi_Host *shpnt;
char name[10]; /* host_no>=10^9? I don't think so. */
+int orig_present;
/*
* First verify that this host adapter is completely free with no pending
@@ -2109,6 +2110,7 @@
* that were detected */
pcount0 = next_scsi_host;
+orig_present = tpnt->present;
for (shpnt = scsi_hostlist; shpnt; shpnt = sh1) {
sh1 = shpnt->next;
if (shpnt->hostt != tpnt)
@@ -2155,8 +2157,11 @@
(scsi_memory_upper_value - scsi_init_memory_start) / 1024);
#endif
- /* Remove it from the linked list and /proc */
- if (tpnt->present) {
+ /* Remove it from the linked list and /proc, but only if
+ * any hosts were registered to begin with _and_ we were
+ * able to remove all of them above.
+ */
+ if (orig_present && !tpnt->present) {
Scsi_Host_Template **SHTp = &scsi_hosts;
Scsi_Host_Template *SHT;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Patch for linux Configure.help (netfilter module descriptions)
Here is a patch against 2.4.0-test9,
which adds information about the modules produced by netfilter.
Please let me know if it is suitable.
Paul Schulz
** This message was bounced when I tried to send it to:
** Axil Boldt ([EMAIL PROTECTED])
** (Email address at the top of the file.. has this changed?)
-
diff -rU 3 kernel-source-2.4.0-test9/Documentation/Configure.help
kernel-source-2.4.0-test9ps1/Documentation/Configure.help
--- kernel-source-2.4.0-test9/Documentation/Configure.help Sat Sep 23 09:41:37
2000
+++ kernel-source-2.4.0-test9ps1/Documentation/Configure.help Wed Oct 11 23:30:13
+2000
@@ -1821,8 +1821,11 @@
enhance packet filtering (see `Connection state match support'
below).
- If you want to compile it as a module, say M here and read
- Documentation/modules.txt. If unsure, say `N'.
+ This driver is also available as a module. The module will be
+ called ip_conntrack.o.
+
+If you want to compile it as a module, say M
+ here and read Documentation/modules.txt. If unsure, say `N'.
FTP protocol support
CONFIG_IP_NF_FTP
@@ -1830,16 +1833,18 @@
required for tracking them, and doing masquerading and other forms
of Network Address Translation on them.
- If you want to compile it as a module, say M here and read
- Documentation/modules.txt. If unsure, say `Y'.
+ This driver is also available as a module. The module will be
+ called ip_conntrack_ftp.o. If you want to compile it as a module,
+ say M here and read Documentation/modules.txt. If unsure, say `Y'.
IP: user space queueing via NETLINK (EXPERIMENTAL)
CONFIG_IP_NF_QUEUE
Netfilter has the ability to queue packets to user space: the
netlink device can be used to access them using this driver.
- If you want to compile it as a module, say M here and read
- Documentation/modules.txt. If unsure, say `N'.
+ This driver is also available as a module. The module will be
+ called ip_queue.o. If you want to compile it as a module, say M
+ here and read Documentation/modules.txt. If unsure, say `N'.
IP: ip tables support (required for filtering/masq/NAT)
CONFIG_IP_NF_IPTABLES
@@ -1848,8 +1853,9 @@
etc) subsystems now use this: say `Y' or `M' here if you want to use
either of those.
- If you want to compile it as a module, say M here and read
- Documentation/modules.txt. If unsure, say `N'.
+ This driver is also available as a module. The module will be
+ called ip_tables.o. If you want to compile it as a module, say M
+ here and read Documentation/modules.txt. If unsure, say `N'.
limit match support
CONFIG_IP_NF_MATCH_LIMIT
@@ -1857,16 +1863,18 @@
matched: mainly useful in combination with the LOG target ("LOG
target support", below) and to avoid some Denial of Service attacks.
- If you want to compile it as a module, say M here and read
- Documentation/modules.txt. If unsure, say `N'.
+ This driver is also available as a module. The module will be
+ called ipt_limit.o. If you want to compile it as a module, say M
+ here and read Documentation/modules.txt. If unsure, say `N'.
MAC address match support
CONFIG_IP_NF_MATCH_MAC
mac matching allows you to match packets based on the source
ethernet address of the packet.
- If you want to compile it as a module, say M here and read
- Documentation/modules.txt. If unsure, say `N'.
+ This driver is also available as a module. The module will be
+ called ipt_mac.o. If you want to compile it as a module, say M here
+ and read Documentation/modules.txt. If unsure, say `N'.
netfilter mark match support
CONFIG_IP_NF_MATCH_MARK
@@ -1874,8 +1882,9 @@
`nfmark' value in the packet. This can be set by the MARK target
(see below).
- If you want to compile it as a module, say M here and read
- Documentation/modules.txt. If unsure, say `N'.
+ This driver is also available as a module. The module will be
+ called ipt_mark.o. If you want to compile it as a module, say M
+ here and read Documentation/modules.txt. If unsure, say `N'.
Multiple port match support
CONFIG_IP_NF_MATCH_MULTIPORT
@@ -1883,16 +1892,18 @@
a series of source or destination ports: normally a rule can only
match a single range of ports.
- If you want to compile it as a module, say M here and read
- Documentation/modules.txt. If unsure, say `N'.
+ This driver is also available as a module. The module will be
+ called ipt_multiport.o. If you want to compile it as a module, say M
+ here and read Documentation/modules.txt. If unsure, say `N'.
TOS match support
CONFIG_IP_NF_MATCH_TOS
TOS matching allows you to match packets based on the Type Of
Service fields of the IP packet.
- If you want to compile it as a module, say M here and read
- Documentation/modules.txt. If unsure, say `N'.
+ This driver is also available as a module. The module will be
+ called ipt_tos.o. If you want to compile it as a mo
Re: floppy on alpha
On Thu, 12 Oct 2000, Thorsten Kranzkowski wrote: > > > Alpha DP264 (UP), SCSI, floppy > > > > > > ... if I read from > > > /dev/fd0, it used to buffer the whole thing, so a second read would be > > > fast -- now it hits the floppy again. > > Huh - your floppy is working? > > Mine does not (with 2.4.0pre10-test1 that is): > AXPpci33 ev4 UP > gcc version 2.96 2925 (experimental) Mine works OK, except for that invalidate on last close thing (how do I go back to the old behavior? Why was it changed?). I compiled with 2.95.2. You might try that. I have floppy.o configured as a module, also. Try that, too. Dr. Tom Holroyd "I am, as I said, inspired by the biological phenomena in which chemical forces are used in repetitious fashion to produce all kinds of weird effects (one of which is the author)." -- Richard Feynman, _There's Plenty of Room at the Bottom_ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: aaaah! complete lockup 2.4.0-test9 SPARC32
* Dr. Kelsey Hudson <[EMAIL PROTECTED]> [001004 19:06]: > Machine: > SPARCstation 20, 1xTMS390Z55 50MHz SuperSPARC II w/1MB SuperCACHE > 48MB RAM, about 9G total disk space spanned over 3 drives, TGX... Ok, if you wanna try it, snarf from the vger cvs tree or just change DBRI_NO_INTS in drivers/sbus/audio/dbri.h from 2 to 1... see if the driver works for you. It works on my SS10, and is a temporary work-around until it's properly fixed. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Updated Linux 2.4 Status/TODO List (from the ALS show)
From: [EMAIL PROTECTED] Date:Fri, 13 Oct 2000 01:20:23 +0100 (BST) Any of the mm gurus give the patch below a quick once over ? Is this adequate, or is there more to this than the description implies? It might make more sense to just make rss an atomic_t. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[PATCH] x86 setup fixes continued.
More improvements/fixups to arch/i386/kernel/setup.c
Some of which are forward ports from 2.2.18pre, others
have been accumulating/missing for a while.
o Boot time 'disable_serial' option.
(Taken from Similar routine by Andrea Arcangeli)
o Inserted missing mcheck_init() call.
o Pentium IV support.
- Now recognised as i686 instead of i1586.
o Cyrix III support.
o Removed duplication of cache size reporting.
o Two extra routines marked as __init.
o A few other minor cleanups.
regards,
Dave.
--
| Dave Jones <[EMAIL PROTECTED]> http://www.suse.de/~davej
| SuSE Labs
diff -urN --exclude-from=/home/davej/.exclude linux/arch/i386/kernel/setup.c
linux.dj/arch/i386/kernel/setup.c
--- linux/arch/i386/kernel/setup.c Wed Oct 11 23:57:50 2000
+++ linux.dj/arch/i386/kernel/setup.c Thu Oct 12 00:03:20 2000
@@ -51,6 +51,10 @@
* Forward port AMD Duron errata T13 from 2.2.17pre
* Dave Jones <[EMAIL PROTECTED]>, August 2000
*
+ * Forward port lots of fixes/improvements from 2.2.18pre
+ * Cyrix III, Pentium IV support.
+ * Dave Jones <[EMAIL PROTECTED]>, October 2000
+ *
*/
/*
@@ -137,6 +141,8 @@
extern char _text, _etext, _edata, _end;
extern unsigned long cpu_khz;
+static int disable_x86_serial_nr __initdata = 1;
+
/*
* This is set up by the setup-routine at boot-time
*/
@@ -844,12 +850,6 @@
{
unsigned int n, dummy, *v;
- /*
-* Actually we must have cpuid or we could never have
-* figured out that this was AMD/Cyrix/Transmeta
-* from the vendor info :-).
-*/
-
cpuid(0x8000, &n, &dummy, &dummy, &dummy);
if (n < 0x8004)
return 0;
@@ -862,29 +862,45 @@
return 1;
}
+
+static void __init display_cacheinfo(struct cpuinfo_x86 *c)
+{
+ unsigned int n, dummy, ecx, edx;
+
+ cpuid(0x8000, &n, &dummy, &dummy, &dummy);
+
+ if (n >= 0x8005) {
+ cpuid(0x8005, &dummy, &dummy, &ecx, &edx);
+ printk("CPU: L1 I Cache: %dK L1 D Cache: %dK (%d bytes/line)\n",
+ edx>>24, ecx>>24, edx&0xFF);
+ c->x86_cache_size=(ecx>>24)+(edx>>24);
+ }
+
+ if (n < 0x8006) /* Cyrix just has large L1. */
+ return;
+
+ cpuid(0x8006, &dummy, &dummy, &ecx, &edx);
+ c->x86_cache_size = ecx >>16;
+
+ /* AMD errata T13 (order #21922) */
+ if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD &&
+ boot_cpu_data.x86 == 6 && boot_cpu_data.x86_model == 3 &&
+ boot_cpu_data.x86_mask == 0)
+ {
+ c->x86_cache_size = 64;
+ }
+ printk("CPU: L2 Cache: %dK\n", ecx>>16);
+}
+
+
static int __init amd_model(struct cpuinfo_x86 *c)
{
u32 l, h;
unsigned long flags;
- unsigned int n, dummy, ecx, edx;
int mbytes = max_mapnr >> (20-PAGE_SHIFT);
int r=get_model_name(c);
- /*
-* Set MTRR capability flag if appropriate
-*/
- if(boot_cpu_data.x86 == 5) {
- if((boot_cpu_data.x86_model == 13) ||
- (boot_cpu_data.x86_model == 9) ||
- ((boot_cpu_data.x86_model == 8) &&
- (boot_cpu_data.x86_mask >= 8)))
- c->x86_capability |= X86_FEATURE_MTRR;
- }
-
- /*
-* Now do the cache operations.
-*/
switch(c->x86)
{
case 5:
@@ -923,6 +939,7 @@
if(mbytes>4092)
mbytes=4092;
+
rdmsr(0xC082, l, h);
if((l&0x)==0)
{
@@ -935,35 +952,23 @@
printk(KERN_INFO "Enabling new style K6 write
allocation for %d Mb\n",
mbytes);
}
+
+ /* Set MTRR capability flag if appropriate */
+ if((boot_cpu_data.x86_model == 13) ||
+ (boot_cpu_data.x86_model == 9) ||
+ ((boot_cpu_data.x86_model == 8) &&
+ (boot_cpu_data.x86_mask >= 8)))
+ c->x86_capability |= X86_FEATURE_MTRR;
break;
}
+
break;
+
case 6: /* An Athlon/Duron. We can trust the BIOS probably */
break;
}
- cpuid(0x8000, &n, &dummy, &dummy, &dummy);
- if (n >= 0x8005) {
- cpuid(0x8005, &dummy, &dummy, &ecx, &edx);
- printk("CPU: L1 I Cache: %dK L1 D Cache: %dK (%d bytes/line)\n",
- edx>>24, ecx>>24, edx&0xFF);
- c->x86_cache_size=(ecx>>24)+(edx>>24);
Re: Updated Linux 2.4 Status/TODO List (from the ALS show)
> 9. To Do
> * mm->rss is modified in some places without holding the
> page_table_lock (sct)
Any of the mm gurus give the patch below a quick once over ?
Is this adequate, or is there more to this than the description implies?
regards,
Dave.
--
| Dave Jones <[EMAIL PROTECTED]> http://www.suse.de/~davej
| SuSE Labs
diff -urN --exclude-from=/home/davej/.exclude linux/mm/memory.c linux.dj/mm/memory.c
--- linux/mm/memory.c Sat Sep 16 00:51:21 2000
+++ linux.dj/mm/memory.cWed Oct 11 23:41:10 2000
@@ -370,7 +370,6 @@
address = (address + PGDIR_SIZE) & PGDIR_MASK;
dir++;
} while (address && (address < end));
- spin_unlock(&mm->page_table_lock);
/*
* Update rss for the mm_struct (not necessarily current->mm)
* Notice that rss is an unsigned long.
@@ -379,6 +378,7 @@
mm->rss -= freed;
else
mm->rss = 0;
+ spin_unlock(&mm->page_table_lock);
}
@@ -1074,7 +1074,9 @@
flush_icache_page(vma, page);
}
+ spin_lock(&mm->page_table_lock);
mm->rss++;
+ spin_unlock(&mm->page_table_lock);
pte = mk_pte(page, vma->vm_page_prot);
@@ -1113,7 +1115,9 @@
return -1;
clear_user_highpage(page, addr);
entry = pte_mkwrite(pte_mkdirty(mk_pte(page, vma->vm_page_prot)));
+ spin_lock(&mm->page_table_lock);
mm->rss++;
+ spin_unlock(&mm->page_table_lock);
flush_page_to_ram(page);
}
set_pte(page_table, entry);
@@ -1152,7 +1156,9 @@
return 0;
if (new_page == NOPAGE_OOM)
return -1;
+ spin_lock(&mm->page_table_lock);
++mm->rss;
+ spin_unlock(&mm->page_table_lock);
/*
* This silly early PAGE_DIRTY setting removes a race
* due to the bad i386 page protection. But it's valid
diff -urN --exclude-from=/home/davej/.exclude linux/mm/mmap.c linux.dj/mm/mmap.c
--- linux/mm/mmap.c Tue Aug 29 20:41:12 2000
+++ linux.dj/mm/mmap.c Wed Oct 11 23:48:30 2000
@@ -844,7 +844,9 @@
vmlist_modify_lock(mm);
mm->mmap = mm->mmap_avl = mm->mmap_cache = NULL;
vmlist_modify_unlock(mm);
+ spin_lock (&mm->page_table_lock);
mm->rss = 0;
+ spin_unlock (&mm->page_table_lock);
mm->total_vm = 0;
mm->locked_vm = 0;
while (mpnt) {
diff -urN --exclude-from=/home/davej/.exclude linux/mm/vmscan.c linux.dj/mm/vmscan.c
--- linux/mm/vmscan.c Mon Oct 2 20:02:20 2000
+++ linux.dj/mm/vmscan.cWed Oct 11 23:46:01 2000
@@ -102,7 +102,9 @@
set_pte(page_table, swp_entry_to_pte(entry));
drop_pte:
UnlockPage(page);
+ spin_lock (&mm->page_table_lock);
mm->rss--;
+ spin_unlock (&mm->page_table_lock);
flush_tlb_page(vma, address);
deactivate_page(page);
page_cache_release(page);
@@ -170,7 +172,9 @@
struct file *file = vma->vm_file;
if (file) get_file(file);
pte_clear(page_table);
+ spin_lock (&mm->page_table_lock);
mm->rss--;
+ spin_unlock (&mm->page_table_lock);
flush_tlb_page(vma, address);
vmlist_access_unlock(mm);
error = swapout(page, file);
@@ -202,7 +206,9 @@
add_to_swap_cache(page, entry);
/* Put the swap entry into the pte after the page is in swapcache */
+ spin_lock (&mm->page_table_lock);
mm->rss--;
+ spin_unlock (&mm->page_table_lock);
set_pte(page_table, swp_entry_to_pte(entry));
flush_tlb_page(vma, address);
vmlist_access_unlock(mm);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] s3 support for vesafb
We really need real S3 framebuffer devices that work across many platforms. > It's port of patch from http://www.colonel-panic.com (for kernel 2.2.12) > to 2.4.0-test10-pre1. It's quite useful if you have older s3 video card > (i.e. Virge) without VBE 2.0, but it's rather tricky so it is not in main > tree. > > URL: http://republika.pl/bkz/240t10p1-s3lfb.diff (7kB) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[PATCH] usb audio.
On Thu, 12 Oct 2000, David Woodhouse wrote:
> > * USB: system hang with USB audio driver {CRITICAL} (David
> >Woodhouse, Randy Dunlap, Narayan Desai)
>
> That fixes failure mode #1, in which the NMI watchdog gets triggered and
> all subsequent attempts to open /dev/audio just block.
>
> Unfortunately, it doesn't affect failure mode #2, in which the machine
> just dies completely.
OK. This patch fixes failure mode #2 too - and lets it make noise without
locking up the machine. By including the extra lines which Randy Dunlap
sent me, it even makes the _right_ noise.
My only remaining problem is that I've just woken She Who Must Be Obeyed
by playing Terrorvision very loudly at 1 am.
Index: drivers/usb/audio.c
===
RCS file: /net/passion/inst/cvs/linux/drivers/usb/audio.c,v
retrieving revision 1.1.2.31
diff -u -r1.1.2.31 audio.c
--- drivers/usb/audio.c 2000/09/07 08:26:12 1.1.2.31
+++ drivers/usb/audio.c 2000/10/13 00:06:04
@@ -879,6 +879,7 @@
mask = 0;
printk(KERN_ERR "usbin_completed: panic: unknown URB\n");
}
+ urb->dev = as->state->usbdev;
spin_lock_irqsave(&as->lock, flags);
if (!usbin_retire_desc(u, urb) &&
u->flags & FLG_RUNNING &&
@@ -943,6 +944,7 @@
mask = 0;
printk(KERN_ERR "usbin_sync_completed: panic: unknown URB\n");
}
+ urb->dev = as->state->usbdev;
spin_lock_irqsave(&as->lock, flags);
if (!usbin_sync_retire_desc(u, urb) &&
u->flags & FLG_RUNNING &&
@@ -1007,8 +1009,10 @@
}
spin_lock_irqsave(&as->lock, flags);
}
- if (u->dma.count >= u->dma.dmasize && !u->dma.mapped)
+ if (u->dma.count >= u->dma.dmasize && !u->dma.mapped) {
+ spin_unlock_irqrestore(&as->lock, flags);
return 0;
+ }
u->flags |= FLG_RUNNING;
if (!(u->flags & FLG_URB0RUNNING)) {
urb = &u->durb[0].urb;
@@ -1233,6 +1237,7 @@
mask = 0;
printk(KERN_ERR "usbout_completed: panic: unknown URB\n");
}
+ urb->dev = as->state->usbdev;
spin_lock_irqsave(&as->lock, flags);
if (!usbout_retire_desc(u, urb) &&
u->flags & FLG_RUNNING &&
@@ -1304,6 +1309,7 @@
mask = 0;
printk(KERN_ERR "usbout_sync_completed: panic: unknown URB\n");
}
+ urb->dev = as->state->usbdev;
spin_lock_irqsave(&as->lock, flags);
if (!usbout_sync_retire_desc(u, urb) &&
u->flags & FLG_RUNNING &&
@@ -1368,8 +1374,10 @@
}
spin_lock_irqsave(&as->lock, flags);
}
- if (u->dma.count <= 0 && !u->dma.mapped)
+ if (u->dma.count <= 0 && !u->dma.mapped) {
+ spin_unlock_irqrestore(&as->lock, flags);
return 0;
+ }
u->flags |= FLG_RUNNING;
if (!(u->flags & FLG_URB0RUNNING)) {
urb = &u->durb[0].urb;
@@ -2768,6 +2776,14 @@
init_waitqueue_head(&as->usbin.dma.wait);
init_waitqueue_head(&as->usbout.dma.wait);
spin_lock_init(&as->lock);
+ spin_lock_init(&as->usbin.durb[0].urb.lock);
+ spin_lock_init(&as->usbin.durb[1].urb.lock);
+ spin_lock_init(&as->usbin.surb[0].urb.lock);
+ spin_lock_init(&as->usbin.surb[1].urb.lock);
+ spin_lock_init(&as->usbout.durb[0].urb.lock);
+ spin_lock_init(&as->usbout.durb[1].urb.lock);
+ spin_lock_init(&as->usbout.surb[0].urb.lock);
+ spin_lock_init(&as->usbout.surb[1].urb.lock);
as->state = s;
as->usbin.interface = asifin;
as->usbout.interface = asifout;
--
dwmw2
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
2.2.18pre15 and do_try_to_free_page for ... w/ Andrea's patch
Hi! Unfortunatelly I couldn't apply it: [root@iq src]# bzcat VM-global-2.2.18pre9-6.bz2 |patch -p0 patching file `VM/drivers/block/rd.c' patching file `VM/fs/binfmt_aout.c' patching file `VM/fs/binfmt_elf.c' patching file `VM/fs/buffer.c' patching file `VM/fs/coda/file.c' patching file `VM/fs/dcache.c' patching file `VM/fs/open.c' patching file `VM/fs/read_write.c' patching file `VM/include/linux/fs.h' Hunk #1 FAILED at 185. Hunk #2 FAILED at 771. Hunk #3 succeeded at 782 (offset 2 lines). Hunk #4 succeeded at 980 (offset 41 lines). 2 out of 4 hunks FAILED -- saving rejects to VM/include/linux/fs.h.rej patching file `VM/include/linux/locks.h' patching file `VM/include/linux/sched.h' patching file `VM/init/main.c' Hunk #1 succeeded at 77 (offset 1 line). Hunk #2 succeeded at 1582 (offset 17 lines). patching file `VM/ipc/shm.c' patching file `VM/kernel/fork.c' patching file `VM/mm/filemap.c' patching file `VM/mm/page_alloc.c' patching file `VM/mm/swap_state.c' patching file `VM/mm/vmscan.c' I will look into the .rej to try to fix it... -- SaPE Peter, Sasi <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
bug in rpc code
Problem:
A returned address from kmalloc() can be overwritten to a wrong place in
rpcauth_lookup_credcache() routine.
rpcauth_lookup_credcache(struct rpc_auth *auth, int taskflags)
{
...
if (!cred) {
cred = auth->au_ops->crcreate(taskflags);
}
if (cred)
rpcauth_insert_credcache(struct rpc_auth *auth, struct rpc_cred *cred)
return (struct rpc_cred *) cred;
}
/* auth->au_ops->crcreate in rpcauth_lookup_credcache() is nul_create_cred */
nul_create_cred(int flags)
{
..
if (!(cred = (struct rpc_cred *) rpc_allocate(flags, sizeof(*cred
/* cred->cr_uid is not initialized, =0xbf3ff3f5 in my case */
cred->cr_count = 0;
..
}
rpcauth_insert_credcache(struct rpc_auth *auth, struct rpc_cred *cred)
{
..
nr = (cred->cr_uid % RPC_CREDCACHE_NR);
auth->au_credcache[nr] = cred;
/* write to a wrong place, nr=-3 in my case */
..
}
Soultion:
Added one line in nul_create_cred() routine.
nul_create_cred(int flags)
{
struct rpc_cred *cred;
if (!(cred = (struct rpc_cred *) rpc_allocate(flags, sizeof(*cred
return NULL;
cred->cr_uid = 0; << added
cred->cr_count = 0;
cred->cr_flags = RPCAUTH_CRED_UPTODATE;
return cred;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: large memory support for x86
On Thu, Oct 12, 2000 at 07:19:32PM -0400, Dan Maas wrote: > The memory map of a user process on x86 looks like this: > > - > KERNEL (always present here) > 0xC000 > - > 0xBFFF > STACK > - > MAPPED FILES (incl. shared libs) > 0x4000 > - > HEAP (brk()/malloc()) > EXECUTABLE CODE > 0x08048000 > - > > Try examining /proc/*/maps, and also watch your programs call brk() using > strace; you'll see all this in action... > > > So why does the process space start at such a high virtual > > address (why not closer to 0x)? Seems we're wasting ~128 megs of > > RAM. Not a huge amount compared to 4G, but signifigant. > > I don't know; anyone care to comment? Apparently to catch NULL pointer references with array indices (int *p = NULL; p[5000]) I agree that is is very wasteful use of precious virtual memory. > > Can kernel > > pages be swapped out / faulted in just like user process pages? > > Linux does not swap kernel memory; the kernel is so small it's not worth the > trouble (are there other reasons?). e.g. My Linux boxes run 1-2MB of kernel > code; my NT machine is running >6MB at the moment... Actually most linux boxes do, but with the old term for swapping before virtual memory (or overlaying in dos terms). They have a cronjob that expires modules with usage count 0 (or in 2.0 kerneld that did the same) It is a rather dangerous thing though, module unloading tends to be one of the most race prone and in addition not too well tested places in the kernel. I usually recommend to turn it off on any production machine. In 2.4 with the new fine grained SMP locking is much much more dangerous, nearly impossible to solve properly. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: VM: do_try_to_free_memory failed for XXXX, 2.2.17, 2.2.18pre3
if you aren't comfortable with dropping a lot of the 2.2.18preX stuff onto a production box, there is also the 2.2.18pre2aa2 kernel that andrea made which has the VM stuff. check out andrea/proposed/v2.2/2.2.18pre2 or andrea/kernels/v2.2/2.2.18pre2aa2 unless you've made substantial updates to your patches, andrea? On Mon, 9 Oct 2000, Andrea Arcangeli wrote: > On Mon, Oct 09, 2000 at 04:03:46PM +0100, Alan Cox wrote: > > > The situation persists, we have had two crashes on those servers today. > > > > > > The machines are usually very heavily loaded, 5-50. > > > > > > Please help. > > > Are there any patches to fix this behaviour ? > > > > You might want to try Andrea Arcangeli's further vm patches > > It's here btw: > > >ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/patches/v2.2/2.2.18pre9/VM-global-2.2.18pre9-6.bz2 > > It applies cleanly to latest 2.2.18pre. > > Andrea > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Updated 2.4 TODO List
On Thu, 12 Oct 2000 11:02:50 -0400, "Chris Swiedler" <[EMAIL PROTECTED]> wrote: >But the kernel should be able to write directly to the screen, even if it's >extremely minimal information. Something like how LILO does it: test the >common hang-on-boot conditions (like wrong CPU type) and print a single >character after each test. You miss the point. The generated C code for any part of the kernel can contains instructions that break on older boxes. Compiling bits of the kernel in 386 and bits in 686 mode is not a long term solution, you will be forever tracking down which bits can be compiled with which options. printk() itself is not reliable under these circumstances so you would have to use a special I/O routine to log these problems. Also the code that detects the problem must never use the new instructions itself. That means the detect and warn code must be separate from the main kernel, either as part of the boot loader or as part of the 16 bit setup code. Any such code must not use printk() for IO. BTW, your ISP is sending mail from a server with no reverse DNS. That puts it in the same category as 99% of the spam sources on the net, please ask them to fix their DNS. Received: from [216.162.44.3] ([216.162.44.3]:13574 "EHLO challenge.atlanticweb.com") - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: VM: do_try_to_free_memory failed for XXXX, 2.2.17, 2.2.18pre3
On Thu, 12 Oct 2000, Krzysztof Sierota wrote: > Our 3 machines went unresponsive, just the way you describe it. The error > was the same. We had this on 2.2.17 and on 2.2.18pre3 , didn't try 2.2.18pre15. > Marcelo Tosati assembled a kernel for us that had Andrea Arcangeli patches > applied and some other stuff that we needed, and the machines are stable > since then. All our machines run under very _heavy_ disk IO operations. > Loads between 15-30 most of the time. If this is true, I am very much interested in the resultant patch (to vanilla 2.2.17 or 2.2.18pre15) since I have the same load, and the same errors. Could you please send it? On 12 Oct 2000, Per Andreas Buer wrote: > Krzysztof Sierota <[EMAIL PROTECTED]> writes: > > I recently changed the kernel from 2.2.15 to 2.2.17 and added new promise 100 > > card. During 3 days 2 production servers crashed 4 times and had several > > lockups when there was zillion messages like > > VM: do_try_to_free_memmory failed for XXX > Are you using gcc 2.95? We had a lot of trouble (fatal vm-errors) with > gcc 2.95 until we started building kernels with egcs-2.91. Unfortunatelly this is not to blame gcc for: Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.66/specs gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release) -- SaPE Peter, Sasi <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[PATCH] s3 support for vesafb
It's port of patch from http://www.colonel-panic.com (for kernel 2.2.12) to 2.4.0-test10-pre1. It's quite useful if you have older s3 video card (i.e. Virge) without VBE 2.0, but it's rather tricky so it is not in main tree. URL:http://republika.pl/bkz/240t10p1-s3lfb.diff (7kB) extremely sleepy -- Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel 2.2.18 and GCC versions
> I will use 2.95.2, so that egcs seems to not being able to build 18-preX. egcs-1.1.2 builds 2.2.18pre. I know this because thats the compiler I use to build it. Its also the recommended compiler. 2.95 is still 'probably works'. In truth I think 2.95 is now at the point where if anything kernel side is broken it must be fairly obscure or a little used driver - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: large memory support for x86
The memory map of a user process on x86 looks like this: - KERNEL (always present here) 0xC000 - 0xBFFF STACK - MAPPED FILES (incl. shared libs) 0x4000 - HEAP (brk()/malloc()) EXECUTABLE CODE 0x08048000 - Try examining /proc/*/maps, and also watch your programs call brk() using strace; you'll see all this in action... > So why does the process space start at such a high virtual > address (why not closer to 0x)? Seems we're wasting ~128 megs of > RAM. Not a huge amount compared to 4G, but signifigant. I don't know; anyone care to comment? > Another question: how (and where in the code) do we translate virtual > user-addresses to physical addresses? In hardware, with the TLB and, if the TLB misses, then page tables. > Does the MMU do it, or does it call a > kernel handler function? Only when an attempt is made to access an unmapped or protected page; then you get an interrupt (page fault), which the kernel code handles. > Why is the kernel allowed to reference physical > addresses, while user processes go through the translation step? Not even the kernel accesses physical memory directly. It can, however, choose to map the physical memory into its own address space contiguously. Linux puts it at 0xC000 and up. (question for the gurus- what happens on machines with >1GB of RAM?) > Can kernel > pages be swapped out / faulted in just like user process pages? Linux does not swap kernel memory; the kernel is so small it's not worth the trouble (are there other reasons?). e.g. My Linux boxes run 1-2MB of kernel code; my NT machine is running >6MB at the moment... Dan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel 2.2.18 and GCC versions
On Fri, 13 Oct 2000 01:30:57 Igmar Palsenberg wrote: > Forget 2.96. It's a prerelease, and produces broken kernel, IF it > produces > them. > > > TIA, and sorry for the 'long long' message... > > Read the docs. It says what works and what doens't. > Thanks, I thought 2.96 was a 'real' version. This page is VERY clear: http://gcc.gnu.org/gcc-2.96.html I will use 2.95.2, so that egcs seems to not being able to build 18-preX. -- Juan Antonio Magallon Lacarta mailto:[EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: dst cache overflow
On Thu, Oct 12, 2000 at 12:39:09PM -0400, Ed Taranto wrote: > Anyone out there have any further information or insight into this? You can check the routes in the rtcache by using route --cache. Maybe you can see a pattern. > > One thing that concerns me is that rt_garbage_collect will only make one > pass through the main loop while in_interrupt() ... thus perhaps that is > why it doesn't make it's goal of getting the cache entries below > ip_rt_max_size. if i am under heavy load, perhaps i am spending too much > time in_interrupt() which is why I can't trim down the cache sufficiently?? For a router/packet filter firewall rt_garbage_collect will only be called from interrupt context. Normally a single sweep should be more than enough though. > Or does this perhaps sound like a memory leak or something? A common cause are port scans which cause generation of lots of routes very quickly. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: VM: do_try_to_free_memory failed for XXXX, 2.2.17, 2.2.18pre3
On Thu, 12 Oct 2000, Roy C. Bixler wrote: > I just had our mail server running 2.2.18pre15 (compiled with GCC 2.7.2.3) > go unresponcive yesterday. The console was flooded with > 'do_try_to_free_pages failed' messages for various processes and had to be > hard booted to the last stable kernel, which for us is 2.2.16. I noticed > a few minutes before the crash that both 'kupdate' and 'kswapd' were stuck > in the D state and WCHAN for each was 'wait_on_buffer'. I got advice from > Marcelo Tosatti to try out the following Andrea Arcangeli patch: > > ftp://ftp.linux.org/pub/linux/kernel/people/andrea/patches/v2.2/2.2.18pre9/VM-g$ > I feel I can't do that since it's a production machine, but I would be > very interested if your crash sounds anything like ours and if you found a > way to make 2.2.18pre* work on your machine. > Our 3 machines went unresponsive, just the way you describe it. The error was the same. We had this on 2.2.17 and on 2.2.18pre3 , didn't try 2.2.18pre15. Marcelo Tosati assembled a kernel for us that had Andrea Arcangeli patches applied and some other stuff that we needed, and the machines are stable since then. All our machines run under very _heavy_ disk IO operations. Loads between 15-30 most of the time. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: SMP irq sharing problem in 2.2.17
** Reply to message from "Robert B. Easter" <[EMAIL PROTECTED]> on Thu, 12 Oct 2000 18:47:22 -0400 > Since installing a > second CPU and recompiling the kernel for SMP and recompiling ALSA with > --with-smp=yes, the sound loops. I can hear the sound, but it doesn't > continue to play normally, rather, a sample will loop over and over. This means that the driver is not receiving any IRQs from the hardware. Typically, this is the result of an IRQ conflict (some other driver has claimed the IRQ for your hardware, and its interrupt handler is getting called instead). -- Timur Tabi - [EMAIL PROTECTED] Interactive Silicon - http://www.interactivesi.com When replying to a mailing-list message, please don't cc: me, because then I'll just get two copies of the same message. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
devfs bug?
Hi there,
as of devfs and devfsd Xterm seems to need suid bit set so that chown
of /dev/pts/{pts number} can be done. devpts fs does not need it.
So it is buggy devfs/devfsd or it is a feature?
The first allocation of pts number has good ownership but if it is freed
and another allocation is done by different user pts number has still
ownership of firt allocation if Xterm is not suid. In Red Hat Xterm is
no more suid.
--
Thnx&cya
Luke
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Updated Linux 2.4 Status/TODO List (from the ALS show)
Greg KH wrote:
On Thu, Oct 12, 2000 at 08:06:46AM -0400, [EMAIL PROTECTED]
wrote:
>Â * USB: booting with USB compiled into
kernel causes a lot of syslog
>Â Â Â entries as the root hubs
are probed by all drivers (this is
>Â Â Â especially obnoxious as
the usb-serial drivers start up)
Fixed in test9. If anyone still sees this, please let me know.
>Â * USB: fix setting urb->dev in printer,
acm, bluetooth, all serial
>Â Â Â drivers (Greg KH) {CRITICAL}
Fixed in test10-pre1.
>Â * USB: fix usb-uhci setting urb->dev
= NULL at correct places only
>Â Â Â {CRITICAL}
Fixed in test10-pre1.
thanks,
greg k-h
--
greg@(kroah|wirex).com
http://immunix.org/~greg
Â
USB still have problems, when starting to grab with my ov511 webcam i got
the attached oops. This bug appeared
in test9-preX(XÂ beeing at least > 2) series. Some people have
claimed that test10-pre1 fixed the problem, but
the bug is still present in the last two pre(test10-pre1 and test10-pre2).
To be noted:
-this oops is obtained with "Enforce USB bandwidth allocation", but
it occurs in the same place when disabled
-I'm using usb-uhci
-the attached oops is truncated as each following schedule call produce
a new oops
Â
--Â
%--IRIN->-Institut-de-Recherche-en-Informatique-de-Nantes-%
% FORT David, %
% 7 avenue de la morvandière  0240726275 %
% 44470 Thouare, France   [EMAIL PROTECTED] %
% ICU:78064991Â Â AIM: enlighted popo [EMAIL PROTECTED] %
%--LINUX-HTTPD-PIOGENE%
%Â -datamining <-/Â Â Â |Â Â .~. %
% -networking/flashed PHP3 coming soon  |  /V\   L I N U X   %
% -opensource   | // \\ >Fear the Penguin< %
%Â -GNOME/enlightenment/GIMPÂ | /(Â Â )\Â Â %
%  feel enlighted   | ^^-^^   %
%Â Â http://ibonneace.dnsalias.org/ when connected %
%-%
Â
ksymoops 2.3.4 on i686 2.4.0-test10. Options used
-V (default)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/2.4.0-test10/ (default)
-m /usr/src/linux/System.map (default)
Warning: You did not tell me where to find symbol information. I will
assume that the log matches the kernel and modules that are running
right now and I'll use the default options above for symbol resolution.
If the current kernel and/or modules do not match the log, you can get
more accurate output by telling me the kernel version and where to find
map, modules, ksyms etc. ksymoops -h explains the options.
Unable to handle kernel NULL pointer dereference at virtual address 00a0
c8c7365d
*pde =
Oops:
CPU:1
EIP:0010:[]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00013246
eax: ebx: c6e26480 ecx: edx: 0028
esi: c6e26480 edi: c2bb8d9c ebp: esp: c0d05f28
ds: 0018 es: 0018 ss: 0018
Process X (pid: 974, stackpage=c0d05000)
Stack: c1b236a8 c8c84814 c6e26480 0001 c1b236a8 c2bb8d80 c2bb8d9c
0001 c8c849bf c2bb8d80 c6e26488 c2fc4b60 0401
0020 000a c0020020 c010be71 000a c2bb8d80 c0d05fc4 c0282740
Call Trace: [] [] [] [] []
Code: 8b 91 a0 00 00 00 8b 43 30 29 42 28 83 7c 24 10 00 74 10 8b
>>EIP; c8c7365d <[usbcore]usb_release_bandwidth+9/60> <=
Trace; c8c84814 <[usb-uhci]process_urb+d4/1f0>
Trace; c8c849bf <[usb-uhci]uhci_interrupt+8f/e8>
Trace; c010be71
Trace; c010c056
Trace; c010a7c0
Code; c8c7365d <[usbcore]usb_release_bandwidth+9/60>
<_EIP>:
Code; c8c7365d <[usbcore]usb_release_bandwidth+9/60> <=
0: 8b 91 a0 00 00 00 mov0xa0(%ecx),%edx <=
Code; c8c73663 <[usbcore]usb_release_bandwidth+f/60>
6: 8b 43 30 mov0x30(%ebx),%eax
Code; c8c73666 <[usbcore]usb_release_bandwidth+12/60>
9: 29 42 28 sub%eax,0x28(%edx)
Code; c8c73669 <[usbcore]usb_release_bandwidth+15/60>
c: 83 7c 24 10 00cmpl $0x0,0x10(%esp,1)
Code; c8c7366e <[usbcore]usb_release_bandwidth+1a/60>
11: 74 10 je 23 <_EIP+0x23> c8c73680
<[usbcore]usb_release_bandwidth+2c/60>
Code; c8c73670 <[usbcore]usb_release_bandwidth+1c/60>
13: 8b 00 mov(%eax),%eax
Aiee, killing interrupt handler
invalid operand:
CPU:1
EIP:0010:[]
EFLAGS: 00013282
eax: 001b ebx: ecx: 001b edx: c021a8e8
esi: c5bce9e0 edi: c0d04000 ebp: c0d05cec esp: c0d05cac
ds: 0018 es: 0018 ss: 0018
Process X (pid: 974, stackpage=c0d05000)
Stack: c01e6e45 c01e7016 02b8 c5bce9e0 c0d04000 3286 c5bce9e0
c0d04000 c5bcea28 c0185373 c12b9e60 000
SMP irq sharing problem in 2.2.17
I'm using ALSA sound modules with a VIA 82C686A onboard audio chip on a MSI 694D-ProA motherboard. When I only had one cpu installed and the kernel and ALSA were compiled for non-SMP, the sound worked fine. Since installing a second CPU and recompiling the kernel for SMP and recompiling ALSA with --with-smp=yes, the sound loops. I can hear the sound, but it doesn't continue to play normally, rather, a sample will loop over and over. However, if I cause disk activity, the sound will begin to play forward until the disk stops. The onboard VIA Audio Controller is sharing an IRQ (IRQ18) with the onboard promise 202065 UltraATA-100 controller. Something is broken in SMP, the kernel or ALSA. I notice that since booting an SMP kernel, some additional things happen on bootup: IO-APIC and related setup. It looks like more IRQs are available in a dual system but I'm not sure how they are used. I've tried many things in an attempt to put the via686a and the promise ide on separate IRQs, but I can't get the BIOS to do anything different and I'm not sure what the Linux kernel or ALSA can do to change the IRQs. Kernel 2.2.17 patched with ide.2.2.17.all.2904.patch PNP enabled in kernel. PNP OS = yes in BIOS (I've tried all combinations of these two) ALSA 0.5.9c --with-smp=yes --with-cards=via686 --with-oss=yes --with-sequencer=yes I'm not sure if pnptools will help or not, but when I run pnpdump, it reports that no devices are found so I guess it can't do anything for me - I'm not using it. Any suggestions/help appreciated. The following is my boot messages if that helps to see anything: Linux version 2.2.17 (root@cts2) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #7 SMP Thu Oct 12 16:46:44 EDT 2000 Scan SMP from c000 for 1024 bytes. Scan SMP from c009fc00 for 1024 bytes. Scan SMP from c00f for 65536 bytes. Intel MultiProcessor Specification v1.4 Virtual Wire compatibility mode. OEM ID: OEM0 Product ID: PROD APIC at: 0xFEE0 Processor #0 Pentium(tm) Pro APIC version 17 Floating point unit present. Machine Exception supported. 64 bit compare & exchange supported. Internal APIC present. Bootup CPU Processor #1 Pentium(tm) Pro APIC version 17 Floating point unit present. Machine Exception supported. 64 bit compare & exchange supported. Internal APIC present. Bus #0 is PCI Bus #1 is PCI Bus #2 is ISA I/O APIC #2 Version 17 at 0xFEC0. Processors: 2 mapped APIC to e000 (fee0) mapped IOAPIC to d000 (fec0) Detected 800032 kHz processor. Console: colour VGA+ 80x25 Calibrating delay loop... 1595.80 BogoMIPS Memory: 128012k/131072k available (1016k kernel code, 428k reserved, 1560k data, 56k init) Dentry hash table entries: 16384 (order 5, 128k) Buffer cache hash table entries: 131072 (order 7, 512k) Page cache hash table entries: 32768 (order 5, 128k) VFS: Diskquotas version dquot_6.4.0 initialized CPU serial number disabled. Checking 386/387 coupling... OK, FPU using exception 16 error reporting. Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX CPU serial number disabled. Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. per-CPU timeslice cutoff: 49.98 usecs. CPU0: Intel Pentium III (Coppermine) stepping 03 Getting VERSION: 40011 Getting VERSION: 40011 Getting LVT0: 700 Getting LVT1: 400 setup_APIC_clock() called. calibrating APIC timer ... . 8000261 CPU clocks in 1 timer chip tick. . 174 APIC bus clocks in 1 timer chip tick. . CPU clock speed is 800.0261 MHz. . system bus clock speed is 133.3374 MHz. CPU map: 3 Booting processor 1 eip 2000 Setting warm reset code and vector. 1. 2. 3. Asserting INIT. Deasserting INIT. Sending STARTUP #1. After apic_write. Before start apic_write. Startup point 1. Waiting for send to finish... +CPU#1 waiting for CALLOUT Sending STARTUP #2. After apic_write. Before start apic_write. Startup point 1. Waiting for send to finish... +After Startup. Before Callout 1. After Callout 1. CALLIN, before enable_local_APIC(). setup_APIC_clock() called. waiting for other CPU calibrating APIC ... done, continuing. Calibrating delay loop... 1599.08 BogoMIPS Stack at about c7ffbfbc CPU serial number disabled. Intel machine check reporting enabled on CPU#1. OK. CPU1: Intel Pentium III (Coppermine) stepping 03 CPU has booted. Before bogomips. Total of 2 processors activated (3194.88 BogoMIPS). Before bogocount - setting activated=1. Boot done. enabling symmetric IO mode... ...done. ENABLING IO-APIC IRQs init IO_APIC IRQs IO-APIC (apicid-pin) 2-0, 2-9, 2-10, 2-11, 2-20, 2-21, 2-22, 2-23 not connected. number of MP IRQ sources: 20. number of IO-APIC #2 registers: 24. testing the IO APIC... IO APIC #2.. register #00: 0200 ...: physical APIC id: 02 register #01: 0017001
semantics past EOF for MAP_PRIVATE and MAP_SHARED...
There's a chunky comment near the beginning of filemap_nopage() that after a test and then following the source seems to me to be untrue: /* * Semantics for shared and private memory areas are different * past the end of the file. A shared mapping past the last page * of the file is an error and results in a SIGBUS, while a * private mapping just maps in a zero page. */ I tried to read past on a MAP_PRIVATE and got a sigbus and the source seems to suggest no differentiation from MAP_SHARED in this respect. What are the `correct' semantics? Chris Q. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel 2.2.18 and GCC versions
> Hi, everybody. > > I have a little problem when compiling new kernels. I run Mandrake 7.1 > with many many updates (its almost 7.2beta). > Kernel 2.2.18-pre15 compiles fine under gcc-2.95.2. It is just plain > 2.2.17 with Alan's patch to 18-pre15. > > I downloaded the gcc-2.96 rpms from rufus, and the compilation process > breaks at: > werewolf:/usr/src/linux# make bzImage Forget 2.96. It's a prerelease, and produces broken kernel, IF it produces them. > TIA, and sorry for the 'long long' message... Read the docs. It says what works and what doens't. Igmar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Updated Linux 2.4 Status/TODO List (from the ALS show)
> * USB: system hang with USB audio driver {CRITICAL} (David
>Woodhouse, Randy Dunlap, Narayan Desai)
This is necessary but not sufficient:
Index: drivers/usb/audio.c
===
RCS file: /net/passion/inst/cvs/linux/drivers/usb/audio.c,v
retrieving revision 1.1.2.31
diff -u -r1.1.2.31 audio.c
--- drivers/usb/audio.c 2000/09/07 08:26:12 1.1.2.31
+++ drivers/usb/audio.c 2000/10/12 21:33:22
@@ -1007,8 +1007,10 @@
}
spin_lock_irqsave(&as->lock, flags);
}
- if (u->dma.count >= u->dma.dmasize && !u->dma.mapped)
+ if (u->dma.count >= u->dma.dmasize && !u->dma.mapped) {
+ spin_unlock_irqrestore(&as->lock, flags);
return 0;
+ }
u->flags |= FLG_RUNNING;
if (!(u->flags & FLG_URB0RUNNING)) {
urb = &u->durb[0].urb;
@@ -1368,8 +1370,10 @@
}
spin_lock_irqsave(&as->lock, flags);
}
- if (u->dma.count <= 0 && !u->dma.mapped)
+ if (u->dma.count <= 0 && !u->dma.mapped) {
+ spin_unlock_irqrestore(&as->lock, flags);
return 0;
+ }
u->flags |= FLG_RUNNING;
if (!(u->flags & FLG_URB0RUNNING)) {
urb = &u->durb[0].urb;
That fixes failure mode #1, in which the NMI watchdog gets triggered and
all subsequent attempts to open /dev/audio just block.
Unfortunately, it doesn't affect failure mode #2, in which the machine
just dies completely.
as->lock isn't locked when this happens - the last time
it was altered was at the end of usbout_start (line 1435).
wait_on_irq, CPU 0:
irq: 1 [ 0 1 ]
bh: 0 [ 1 0 ]
850f00e4 00a0 0fe0458b b70f00b7 0cec83c0 5c4ee850 c483fffd 85896610
e7a2 a2858b66 0fe7 6850c0b7 080e83c2 006a016a 00d373e8 10c48300
Call Trace: [] [] [] [] []
[] []
[] [] [] [] [] []
[] []
< ... LOTS of similarly unbelievable addresses ... >
[] [] [] [] [] []
[] []
c62e5000 0001 c62e5764 c016a6a2 c03087a0
c62e5364 c0170b72 c62e5000 c029f00c c011d597 0001 c02f559
Call Trace: [] [] [] [] []
[] []
[] [] [] [] []
Warning (Oops_read): Code line not seen, dumping what data is available
Trace; ec83e045
Trace; e900
Trace; c010be0d <__global_cli+8d/12c>
Trace; c0247f68
Trace; c016a6a2
Trace; c0170b72
Trace; c011d597
Trace; c011d4ba
Trace; c010c1ea
Trace; c010a8b4
Trace; c0241150
Trace; c013614d
Trace; c0108d53
The trace always include __global_cli(), obviously -
wait_on_irq() can't get called from anywhere else, AIUI. The rest of
the trace (except for the lines immediately above and below __global_cli
-- c0247f53 and c0247f68) is different each time.
The stack of the 'other' CPU each time is crap. Whether it's _really_ crap
or whether the code in show() is just doing something wrong I'm not sure.
--
dwmw2
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: sound card docs
> Can anyone tell me which manufacture of sound cards has been the most open > with programming information for their cards. I am looking for > complete documents that would allow me to write my own low-latency driver > for a particular application. Probably the trident 4dwave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Kernel 2.2.18 and GCC versions
Hi, everybody. I have a little problem when compiling new kernels. I run Mandrake 7.1 with many many updates (its almost 7.2beta). Kernel 2.2.18-pre15 compiles fine under gcc-2.95.2. It is just plain 2.2.17 with Alan's patch to 18-pre15. I downloaded the gcc-2.96 rpms from rufus, and the compilation process breaks at: werewolf:/usr/src/linux# make bzImage .. make[2]: Entering directory `/usr/src/linux-2.2.18-pre15/arch/i386/lib' cc -D__KERNEL__ -I/usr/src/linux/include -D__ASSEMBLY__ -D__SMP__ -traditional -c checksum.S -o checksum.o checksum.S:231: badly punctuated parameter list in #define checksum.S:237: badly punctuated parameter list in #define make[2]: *** [checksum.o] Echecksum.Srror 1 make[2]: Leaving directory `/usr/src/linux-2.2.18-pre15/arch/i386/lib' make[1]: *** [first_rule] Error 2 make[1]: Leaving directory `/usr/src/linux-2.2.18-pre15/arch/i386/lib' make: *** [_dir_arch/i386/lib] Error 2 The actual code in checksum.S that breaks 2.96 is: #define SRC(y...) \ : y ; \ .section __ex_table, "a" ; \ .long b, 6001f ; \ .previous #define DST(y...) \ : y ; \ .section __ex_table, "a" ; \ .long b, 6002f ; \ .previous I suppose the var-args macro syntax is less permissive in 2.96...Anyone has any idea to make this code 2.96-compatible ? (yes, I know 2.96 is not supported, but if its a silly change...). Or it should work and is a 2.96 cpp bug ? Then, because this versions of gcc are "not officially supposed to work", got the egcs rpms (version 1.1.2, only egcs and egcs-cpp). But then kgcc stops at: werewolf:/usr/src/linux# make bzImage .. make[1]: Entering directory `/usr/src/linux-2.2.18-pre15/arch/i386/kernel' /usr/bin/kgcc -D__KERNEL__ -I/usr/src/linux/include -D__ASSEMBLY__ -D__SMP__ -traditional -c trampoline.S -o trampoline.o /tmp/ccy1Wjci.s: Assembler messages: /tmp/ccy1Wjci.s:884: Error: can't handle non absolute segment in `ljmp' make[1]: *** [trampoline.o] Error 1 make[1]: Leaving directory `/usr/src/linux-2.2.18-pre15/arch/i386/kernel' make: *** [_dir_arch/i386/kernel] Error 2 TIA, and sorry for the 'long long' message... -- Juan Antonio Magallon Lacarta mailto:[EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: VM: do_try_to_free_memory failed for XXXX, 2.2.17, 2.2.18pre3
Krzysztof Sierota <[EMAIL PROTECTED]> writes: > Hi, > I recently changed the kernel from 2.2.15 to 2.2.17 and added new promise 100 > card. During 3 days 2 production servers crashed 4 times and had several > lockups when there was zillion messages like > VM: do_try_to_free_memmory failed for XXX Are you using gcc 2.95? We had a lot of trouble (fatal vm-errors) with gcc 2.95 until we started building kernels with egcs-2.91. -- Per Andreas Buer - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: large memory support for x86
On Thu, 12 Oct 2000, Timur Tabi wrote: > Of course, you could define a pointer to be a 48-bit value, but I > doubt that would really work. no, x86 virtual memory is 32 bits - segmentation only provides a way to segment this 4GB virtual memory, but cannot extend it. Under Linux there is 3GB virtual memory available to user-space processes. this 3GB virtual memory does not have to be mapped to the same physical pages all the time - and this is nothing new. mmap()/munmap()-ing memory dynamically is one way to 'extend' the amount of physical RAM controlled by a single process. I doubt this would be very economical though. Such big-RAM systems are almost always SMP systems, so eg. a 4-way system can have 4x 3GB processes == 12 GB RAM fully utilized. An 8-way system can utilize up to 24 GB RAM at once, without having to play mmap/munmap 'memory extender' tricks. Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.18pre15
On Wed, 11 Oct 2000, Alan Cox wrote: The was an error reported for 2.2.17: Oct 12 14:55:46 iq kernel: VM: do_try_to_free_pages failed for kupdate... ... Oct 12 00:50:49 iq kernel: VM: do_try_to_free_pages failed for smbd... Oct 12 00:50:51 iq last message repeated 226 times ... Oct 12 00:50:47 iq kernel: VM: do_try_to_free_pages failed for smbd... Oct 12 00:50:48 iq last message repeated 120 times ... It's the same for me w/ 2.2.18pre15. The box is a 256MB RAM 400Mhz Celeron doing fileserving w/ ~40 active connections, 5MBytes/s sustained traffic on eth0, having 4 UDMA used IDE disks w/ sw RAID. Some other fonctions are also there (Lotus Notes 5.0, squid), might this be a problem w/ too many processes and fs load, or what? -- SaPE Peter, Sasi <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: large memory support for x86
Timur Tabi writes: > ** Reply to message from Jeff Epler <[EMAIL PROTECTED]> on Thu, 12 Oct 2000 > 13:08:19 -0500 > > What the support for >4G of memory on x86 is about, is the "PAE", Page Address > > Extension, supported on P6 generation of machines, as well as on Athlons > > (I think). With these, the kernel can use >4G of memory, but it still can't > > present a >32bit address space to user processes. But you could have 8G > > physical RAM and run 4 ~2G or 2 ~4G processes simultaneously in core. > > How about the kernel itself? How do I access the memory above 4GB inside a > device driver? It depends on what you have already. If you're given a (kernel) virtual address, just dereference it. The unit of currency for physical pages is the "struct page". If you want to allocate a physical page for your own use (from anywhere in physical memory) them you do struct page *page = alloc_page(GFP_FOO); If you want to read/write to that page directly from kernel space then you need to map it into kernel space: char *va = kmap(page); /* read/write from the page starting at virtual address va */ kunmap(va); The implementations of kmap and kunmap are such that mappings are cached (within reason) so it's "reasonable" fast doing kmap/kunmap. If you want to do something else with the page (like get some I/O done to/from it) then the new (and forthcoming) kiobuf functions take struct page units and handle all the internal mapping gubbins without you having to worry about it. --Malcolm -- Malcolm Beattie <[EMAIL PROTECTED]> Unix Systems Programmer Oxford University Computing Services - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
test10-pre2
There's a test10-2 out there. Notable change to people Cc'd on this mail: this contains the fix for the vmalloc() and ioremap() race condition, which deletes the set_pgdir() function and instead depends on the page table entries being distributed to the other page directories automatically. Some architectures can do this naturally by just sharing the kernrel pgd entries with "init_mm", others, like the x86, need a dynamic page fault handler path for this. See the arch/x86/mm/fault.c changes to see what arch-specific changes this can entail. Other changes are fairly straightforward.. Linus - - pre2: - remember to change the kernel version ;) - isapnp.txt bugfix - ia64 update - sparc update - networking update (pppoe init, frame diverter, fix tcp_sendmsg, fix udp_recvmsg). - Compile for WinChip must _not_ use "-march=i686". It's a i586. - Randy Dunlap: more USB updates - clarify the Firewire AIC-5800 situation. It's not supported yet. - PCI-space decode size fix. This is needed for some (broken?) hardware - /proc/self/maps off-by-one error - 3c501, 3c507, cs89x0 network drivers drop unnecessary check_region - Asahi Kasei AK4540: new codec ID. Yamaha: new PCI ID's. - ne2k-pci net driver documentation update - Paul Gortmaker: delete paranoia check in rtc_exit - scsi_merge: memset the right amount of memory. - sun3fb: old __initfunc() not supported any more. - synclink: remove unnecessary task state games - xd.c: proper casting for 64-bit architectures - vmalloc: page table update race condition. - pre1: - Roger Larsson: ">=" instead of ">" to make the VM not get stuck. - Gideon Glass: brw_kiovec() failure case oops fix - Rik van Riel: better memory balancing and OOM killer - Ivan Kokshaysky: alpha compile fixes - Vojtech Pavlik: forgotten ENOUGH macro in via82cxxx ide driver - Arnaldo Carvalho de Melo: acpi resource leak fix - Brian Gerst: use mov's instead of xchg in kernel trap entry - Torben Mathiasen: tlan timer being added twice bug - Andrzej Krzysztofowicz: config file fixes - Jean Tourrilhes: Wavelan lockup on SMP fix - Roman Zippel: initdata must be initialized (even if it is to zero: gcc is strange) - Jean Tourrilhes: hp100 driver lockup at startup on SMP - Russell King: fix silly minixfs uninitialized error bug - (various): fix uid hashing to use "uid_t" instead of "unsigned short" - Jaroslav Kysela: isapnp timeout fix. NULL ptr dereference fix. - Alain Knaff: fdformat should work again. - Randy Dunlap: USB - fix bluetooth, acm, printer, serial to work with urb->dev changes. - Randy Dunlap: USB whiteheat serial driver firmware update. - Randy Dunlap: USB hub memory corruption and pegasus driver update - Andre Hedrick: IDE Makefile cleanup - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: Request for TODO file
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, October 11, 2000 5:43 PM > > I've taken a look at that list, and it looks fairly obsolete, as far as > I could tell. There is an actively maintained list which I post > periodically to the Linux-Kernel mailing list, and which is also > available at: > > www://linux24.sourceforge.net Thanks for the info about this link...I never can seem to keep up with all the good linux kernel links like that one. You are doing a great job. Can I suggest a thing or two: * Include a small TOC with links to the corresponding section in the doc. * Have some predefined keywords that might be useful for searching through the file; example: (keyword: NFS FS) * Include some form of platform identification (platform: ALL, ix86, PPC,etc) Some of these might even be useful as some XML tags...but that's a whole different thread. >From: "Eric Bresie" <[EMAIL PROTECTED]> >Date: Mon, 9 Oct 2000 15:31:56 -0500 >I was looking through the current versions of the kernel, was re-reading >through some past "TODO before release" sort of messages, and was wondering, >could these TODO type of items be included in an actual TODO file at the >source top level (or in the Documentation if this would be more appropriate) >and/or included in each level like some of the other areas, (like fs) areas >seem to have? Either that or move all the TODO into the top level one, with >the top level being segmented to the areas of relevance (like a mm, fs, etc >sections). > > The problem is that it's easier for the list to be maintained when it's > outside of the kernel tree; it means that bugs can get added to it > without waiting for the next kernel rev, for example. (I only > periodically post an updated list to the L-K list, but the linux24 > webpage gets updated more frequently than that.) Well...my reason for suggesting it though, is because if we keep the TODO as part of the actual kernel tree...we can maintain a mapping of known problems and tasks that related to a given kernel. How is maintaining it as a TODO/Changes file within the kernel tree any different then a file in the kernel tree itself? If an individual, fixes, say a driver for a given type of sound card, the person could give a brief, "This driver has been fixed comment" (maybe even taken from some kind of cvs type comment for the update), remove the "Needs to be fixed", then do the corresponding patch creation including the TODO and/or Changes file as part of the files to patch. I would guess the only possible problem might be getting people into the habit of changing the TODOs and/or Changes. The benefit of this of couse, is that more than one person can work on it at a time. Although I still think at least one person should monitor it (and even clean it up regularly). That person would every so often, remove previously fixed bugs after the next release is available, to avoid run away TODO files sizes. > I do keep the fixed bugs at the bottom of the list, but it's probably at > a level of detail which is *far* more detailed than what you would want > to see in the top-level Changes file in the kernel. > > - Ted Eric Bresie [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
sound card docs
Hello kernel list Can anyone tell me which manufacture of sound cards has been the most open with programming information for their cards. I am looking for complete documents that would allow me to write my own low-latency driver for a particular application. Thank you, Daniel _ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. Share information about yourself, create your own public profile at http://profiles.msn.com. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Fix SCSI proc oops
On Thu, 12 Oct 2000, Torben Mathiasen wrote: > > We want to make sure that all hostadapters have been unregistered > befor we pull it out of the scsi_hosts list. We do tpnt->present-- > for every hostadaper we unregister. > > Prior to the new init code, we'd just do something like, > > if (tpnt->present) > return; > > I might be wrong though, it could be another bug that I've missed. Isn't this the very same confusion that we had with this code on sparc? David, you know this code, would you mind giving it another pair of eyes? I hate code that doesn't make sense. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Fix SCSI proc oops
On Thu, Oct 12 2000, Linus Torvalds wrote: > > > On Thu, 12 Oct 2000, Torben Mathiasen wrote: > > > > Attached patch should fix the oops's people have been getting > > while using /proc/scsi. > > This patch makes no sense. Why > > if (!present) > > when that is obviously the wrong way around. > We want to make sure that all hostadapters have been unregistered befor we pull it out of the scsi_hosts list. We do tpnt->present-- for every hostadaper we unregister. Prior to the new init code, we'd just do something like, if (tpnt->present) return; I might be wrong though, it could be another bug that I've missed. -- Torben Mathiasen <[EMAIL PROTECTED]> Linux ThunderLAN maintainer http://tlan.kernel.dk - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: prep Mesquite hangs
Hi,
Got my hands on 2.4 using test-9 tree from fsmlabs.
Looks like for Mesquite to run it still has to have the same patch as
was made for 2.2, attached below against fsmlabs 2_3 snapshot tree
fom Oct 10.
2.4 on Mesquite shows rather wierd behavior, does not accept command line
and has a problem with IDE byte order. I've hacked over it with most
ugliest way
but it seems almost to work afterwards. I'll try to find a problem, when
I'll have
time for it.
Now, that's what I'm seeing on boot:
1: On node 0 totalpages: 8192
2: zone(0): 8192 pages.
3: zone(1): 0 pages.
4: zone(2): 0 pages.
5: Kernel command line:
6: time_init: decrementer frequency = 16.666356 MHz
7: Calibrating delay loop... 465.31 BogoMIPS
8: Memory: 30016k available (1224k kernel code, 608k data, 204k init, 0k
highmem)
9: Dentry-cache hash table entries: 4096 (order: 3, 32768 bytes)
10: Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes)
11: Page-cache hash table entries: 8192 (order: 3, 32768 bytes)
12: Inode-cache hash table entries: 2048 (order: 2, 16384 bytes)
13: POSIX conformance testing by UNIFIX
14: PCI: Probing PCI hardware
15: PCI: Unable to handle 64-bit address space for
16: Setting PCI interrupts for a "Mesquite cPCI (MCP750) w/ HAC"
17: Relocating PCI address 3c00 -> 100
18: Relocating PCI address 3b00 -> 100
19: PCI: Cannot allocate resource region 1 of device 00:0e.0
20: Activating ISA DMA hang workarounds.
What bothers me, is the line 15 and inability to allocate resources for
ethernet card (line 19). Any ideas on the spot :)
Thanks,
Vitaly.
--- ide-pci.c.old Tue Oct 10 07:28:37 2000
+++ ide-pci.c Tue Oct 10 07:28:37 2000
@@ -617,6 +617,8 @@
}
if (IDE_PCI_DEVID_EQ(d->devid, DEVID_UM8886A) ||
IDE_PCI_DEVID_EQ(d->devid, DEVID_UM8886BF) ||
+ IDE_PCI_DEVID_EQ(d->devid, DEVID_VP_IDE) ||
+ IDE_PCI_DEVID_EQ(d->devid, DEVID_W82C105) ||
IDE_PCI_DEVID_EQ(d->devid, DEVID_UM8673F)) {
hwif->irq = hwif->channel ? 15 : 14;
goto bypass_umc_dma;
Re: large memory support for x86
** Reply to message from "Richard B. Johnson" <[EMAIL PROTECTED]> on Thu, 12 Oct 2000 15:17:15 -0400 (EDT) > With ix86 processors in the kernel, you can create multiple segments > and multiple page-tables. Does the kernel provide services for this, or will I have to hack up the x86 page tables myself? If there are kernel services, what are they? > If you have some 'hardware-specific' way > of mapping in real RAM that is not used by anybody else, you can have > your own private segment. But is this part of the established Linux >4GB support? I don't think so. > Page registers can map in multiple sticks > of RAM into a single window. The page-fault handler can manipulate > the page registers for user-mode code. It's being done in PAE. But how does one go about doing all this? -- Timur Tabi - [EMAIL PROTECTED] Interactive Silicon - http://www.interactivesi.com When replying to a mailing-list message, please don't cc: me, because then I'll just get two copies of the same message. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Fix SCSI proc oops
On Thu, 12 Oct 2000, Torben Mathiasen wrote: > > Attached patch should fix the oops's people have been getting > while using /proc/scsi. This patch makes no sense. Why if (!present) when that is obviously the wrong way around. I'm sure it fixes an oops - I just want to understand why the test is the wrong way around, and why this patch is as it is. I have this suspicion that you're hiding the real bug which would be to do this in another place completely. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: large memory support for x86
> > Am I reading this correctly--the address of the main() function for a
> > process is guaranteed to be the lowest possible virtual address?
> >
> > chris
> >
>
> It is one of the lowest. The 'C' runtime library puts section
> .text (the code) first, then .data, then .bss, then .stack. The
> .stack section is co-located with the heap which can be extended
> by setting a new break address.
>
> When a process is created, the lowest address is the entry point of
> crt0.o _init. We can see where that is by:
>
> Script started on Thu Oct 12 14:25:35 2000
> # cat xxx.c
>
> extern int _init();
> main()
> {
> printf("_init is at %p\n", _init);
> }
>
> # gcc -o xxx xxx.c
> # ./xxx
> _init is at 0x804838c
> # exit
> exit
> Script done on Thu Oct 12 14:25:51 2000
>
> That said, remember that in Unix, the 'C' rutime library exists in the
> lower portion of the .text section. So your code's virtual address space
> starts above that address space. This is MMAPed so everybody gets
> to share the same pages. In this way, you don't all have to keep a
> private copy of the 'C' runtime library.
User-process virtual addresses have no direct relation to physical
addresses, right? So why does the process space start at such a high virtual
address (why not closer to 0x)? Seems we're wasting ~128 megs of
RAM. Not a huge amount compared to 4G, but signifigant. Is that space used
(libc can't be that big!) or reserved somehow?
Another question: how (and where in the code) do we translate virtual
user-addresses to physical addresses? Does the MMU do it, or does it call a
kernel handler function? Why is the kernel allowed to reference physical
addresses, while user processes go through the translation step? Can kernel
pages be swapped out / faulted in just like user process pages?
Sorry to pounce on you with all of these questions. I've read up on this
stuff but can't always find answers...
thanks--
chris
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: large memory support for x86
On Thu, 12 Oct 2000, Timur Tabi wrote: > ** Reply to message from Jeff Epler <[EMAIL PROTECTED]> on Thu, 12 Oct 2000 > 13:08:19 -0500 > > > > What the support for >4G of memory on x86 is about, is the "PAE", Page Address > > Extension, supported on P6 generation of machines, as well as on Athlons > > (I think). With these, the kernel can use >4G of memory, but it still can't > > present a >32bit address space to user processes. But you could have 8G > > physical RAM and run 4 ~2G or 2 ~4G processes simultaneously in core. > > How about the kernel itself? How do I access the memory above 4GB inside a > device driver? > > > There may or may not be some way to support an abomination like the old "far" > > pointers in DOS (multiple 4G segments), but I don't think it has been written > > yet. > > Yes, it's ugly, but it works and it's compatible. Well, compatible with 32-bit > code, probably not compatible with Linux code overall. > > Of course, you could define a pointer to be a 48-bit value, but I doubt that > would really work. > With ix86 processors in the kernel, you can create multiple segments and multiple page-tables. If you have some 'hardware-specific' way of mapping in real RAM that is not used by anybody else, you can have your own private segment. Page registers can map in multiple sticks of RAM into a single window. The page-fault handler can manipulate the page registers for user-mode code. It's being done in PAE. Cheers, Dick Johnson Penguin : Linux version 2.2.17 on an i686 machine (801.18 BogoMips). "Memory is like gasoline. You use it up when you are running. Of course you get it all back when you reboot..."; Actual explanation obtained from the Micro$oft help desk. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: test10-pre1 problems on 4-way SuperServer8050
} Hi, } } > How? If you compile with egcs-2.91.66 without frame pointers on ix86 then } > __builtin_return_address() yields garbage. Does anybody have a generic } > solution to this problem, other than "compile with frame pointers"? Or is } > it fixed in newer versions of gcc? } } Are you sure? I just I tried it 2.91.66 and it works. With } -fomit-frame-pointer only __builtin_return_address(0) works, but that is } true for any version. I've found, with several versions of gcc, that leaf functions will give bad results (sometimes resulting in a bad access fault) with calls to __builtin_return_address(0). The workaround in the kernel and RTLinux is making a call do your function isn't a leaf. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Fix SCSI proc oops
Linus,
Attached patch should fix the oops's people have been getting
while using /proc/scsi.
Patch is against test10p1.
--
Torben Mathiasen <[EMAIL PROTECTED]>
Linux ThunderLAN maintainer
http://tlan.kernel.dk
--- linux-test10p1/drivers/scsi/scsi.c Thu Oct 12 20:18:47 2000
+++ linux/drivers/scsi/scsi.c Thu Oct 12 21:03:39 2000
@@ -36,8 +36,8 @@
* out_of_space hacks, D. Gilbert (dpg) 990608
*/
-#define REVISION "Revision: 1.00"
-#define VERSION"Id: scsi.c 1.00 2000/09/26"
+#define REVISION "Revision: 1.01"
+#define VERSION"Id: scsi.c 1.01 2000/10/12"
#include
#include
@@ -2156,7 +2156,7 @@
#endif
/* Remove it from the linked list and /proc */
- if (tpnt->present) {
+ if (!tpnt->present) {
Scsi_Host_Template **SHTp = &scsi_hosts;
Scsi_Host_Template *SHT;
@@ -2169,8 +2169,9 @@
}
/* Rebuild the /proc/scsi directory entries */
remove_proc_entry(tpnt->proc_name, proc_scsi);
+ MOD_DEC_USE_COUNT;
+
}
- MOD_DEC_USE_COUNT;
}
static int scsi_unregister_device(struct Scsi_Device_Template *tpnt);
Re: test10-pre1 problems on 4-way SuperServer8050
Hi, > How? If you compile with egcs-2.91.66 without frame pointers on ix86 then > __builtin_return_address() yields garbage. Does anybody have a generic > solution to this problem, other than "compile with frame pointers"? Or is > it fixed in newer versions of gcc? Are you sure? I just I tried it 2.91.66 and it works. With -fomit-frame-pointer only __builtin_return_address(0) works, but that is true for any version. bye, Roman - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: test9 not using buffers
On Wed, Oct 11, 2000 at 09:04:07PM -0400, Alexander Viro wrote: > On Thu, 12 Oct 2000, Tom Holroyd wrote: > > > Alpha DP264 (UP), SCSI, floppy > > > > If I do a dd if=/dev/zero of=/tmp/moo count=10, I don't see any > > increase in buffers, as reported by vmstat. Furthermore, if I read from > > /dev/fd0, it used to buffer the whole thing, so a second read would be > > fast -- now it hits the floppy again. > > Huh - your floppy is working? Mine does not (with 2.4.0pre10-test1 that is): [Marvin:~#] dd if=/dev/fd0 |od -c |more 2880+0 records in 2880+0 records out 000 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 * 550 [Marvin:~#] This floppy currently holds my MILO image so output is definitively wrong :-) I also saw pure random data (fragments from libc etc.) on different runs. AXPpci33 ev4 UP gcc version 2.96 2925 (experimental) > Bye, Thorsten -- | Thorsten KranzkowskiInternet: [EMAIL PROTECTED]| | Mobile: ++49 170 1876134 Snail: Niemannsweg 30, 49201 Dissen, Germany | | Ampr: dl8bcu@db0lj.#rpl.deu.eu, [EMAIL PROTECTED] [44.130.8.19] | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: large memory support for x86
** Reply to message from Jeff Epler <[EMAIL PROTECTED]> on Thu, 12 Oct 2000 13:08:19 -0500 > What the support for >4G of memory on x86 is about, is the "PAE", Page Address > Extension, supported on P6 generation of machines, as well as on Athlons > (I think). With these, the kernel can use >4G of memory, but it still can't > present a >32bit address space to user processes. But you could have 8G > physical RAM and run 4 ~2G or 2 ~4G processes simultaneously in core. How about the kernel itself? How do I access the memory above 4GB inside a device driver? > There may or may not be some way to support an abomination like the old "far" > pointers in DOS (multiple 4G segments), but I don't think it has been written > yet. Yes, it's ugly, but it works and it's compatible. Well, compatible with 32-bit code, probably not compatible with Linux code overall. Of course, you could define a pointer to be a 48-bit value, but I doubt that would really work. -- Timur Tabi - [EMAIL PROTECTED] Interactive Silicon - http://www.interactivesi.com When replying to a mailing-list message, please don't cc: me, because then I'll just get two copies of the same message. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: large memory support for x86
On Thu, Oct 12, 2000 at 10:36:38AM -0700, Kiril Vidimce wrote: > Allocate = malloc(). The process needs to be able to operate on >4 GB > chunks of memory. I understand that it's only a 32 bit address space > which is why I was surprised when I read that Linux 2.4.x will support > upwards of 64 GB's of memory. > > Thanks for all the responses. Pointers are still 32 bits on x86, and the visible address space for any particular process is still somewhat less than 4G. I believe that if you select Linux on Alpha that you can have more than 4G per process, but that may or may not be true. What the support for >4G of memory on x86 is about, is the "PAE", Page Address Extension, supported on P6 generation of machines, as well as on Athlons (I think). With these, the kernel can use >4G of memory, but it still can't present a >32bit address space to user processes. But you could have 8G physical RAM and run 4 ~2G or 2 ~4G processes simultaneously in core. There may or may not be some way to support an abomination like the old "far" pointers in DOS (multiple 4G segments), but I don't think it has been written yet. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
fs/proc/array.c buglet
The attached 1-character change fixes a performance bug in linux-2.4.0-test9 (and earlier). Without this patch, something as simple as "cat /proc/self/maps" will read the "maps" file line by line. --david --- linux-2.4.0-test9/fs/proc/array.c Fri Sep 8 14:34:59 2000 +++ lia64-kdb/fs/proc/array.c Mon Oct 9 19:01:07 2000 @@ -575,7 +575,7 @@ goto getlen_out; /* Check whether the mmaps could change if we sleep */ - volatile_task = (task != current || atomic_read(&mm->mm_users) > 1); + volatile_task = (task != current || atomic_read(&mm->mm_users) > 2); /* decode f_pos */ lineno = *ppos >> MAPS_LINE_SHIFT; - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: large memory support for x86
>On Thu, 12 Oct 2000, Oliver Xymoron wrote: >> On Wed, 11 Oct 2000, Kiril Vidimce wrote: >> >> > My primary concern is whether a process can allocate more than 4 GB of >> > memory, rather than just be able to use more than 4 GB of physical >> > memory in the system. >> >> Define allocate. There are tricks you can play, but userspace is still a >> flat 32-bit address space per-process. > > >Allocate = malloc(). The process needs to be able to operate on >4 GB >chunks of memory. I understand that it's only a 32 bit address space >which is why I was surprised when I read that Linux 2.4.x will support >upwards of 64 GB's of memory. > > >Thanks for all the responses. > > >KV You can, of course, bank switch memory by using a shared segment and cloning additional process heaps. Obviously a _single_ 32bit address space can only access 4GB at a time. --Jonathan-- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: large memory support for x86
On Wed, 11 Oct 2000, Kiril Vidimce wrote: > > Hi there, > > I am trying to find out more information on large memory support (> 4 GB) > for Linux IA32. Is there a document that elaborates on what is supported > and what isn't and how this scheme actually works in the kernel? > > My primary concern is whether a process can allocate more than 4 GB of > memory, rather than just be able to use more than 4 GB of physical > memory in the system. > > Also, I see that the highmem support is just an option in the kernel. > Does this mean that there is a significant performance penalty in using > this extension? Linux does support 64G of physical memory. My machine has 6G RAM and runs absolutely nice and smooth as it should. Everything "just works" (ok, not counting a few subtle cache-related issues and stability of PCI subsystem but those happened many hours ago and were quickly fixed so they are history now and therefore long forgotten ;). As for PAE, yes it does incur penalty of about 3-6% of performance "overall". By overall performance I meant the unixbench numbers. I have published the numbers comparing PAE/4G/nohighmem kernels on the same machine sometime ago... So, it only makes sense to enable PAE if you have more than 4G of memory. Regards, Tigran - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: large memory support for x86
On Thu, 12 Oct 2000, Oliver Xymoron wrote: > On Wed, 11 Oct 2000, Kiril Vidimce wrote: > > > My primary concern is whether a process can allocate more than 4 GB of > > memory, rather than just be able to use more than 4 GB of physical > > memory in the system. > > Define allocate. There are tricks you can play, but userspace is still a > flat 32-bit address space per-process. Allocate = malloc(). The process needs to be able to operate on >4 GB chunks of memory. I understand that it's only a 32 bit address space which is why I was surprised when I read that Linux 2.4.x will support upwards of 64 GB's of memory. Thanks for all the responses. KV -- ___ Studio Tools[EMAIL PROTECTED] Pixar Animation Studioshttp://www.pixar.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: want tool to open RPM package on Window 95
> > > I can think of a number of uses for such a tool. For example, to read > > > the documentation of a package before installing it on a different > > > (Linux-based) system; or to unpack a source-rpm in order to build it > > > with Cygwin. > > > > Bad idea. Most RPM'S contain specific RH patches, most of them being path > > fixes. Get the tar.gz in that case. > > Some software may only (easily) be available in src-rpm format. I might > just want to build one of the binaries in it by hand. I might just want to > read the docs. I might ... > > The point is not what I might or might not want; the point is that there > are valid uses for RPM on Windows. > > > Second, there is no way to actually build on a Windows machine, so I don't > > see the use of it. > > There's no reason why RPM might not be ported to Cygwin. Would be good for consistancy. I still have to see a good decent Windows install / uninstall program. > > > > Second, I'm glad there isn't. Saves tons of bugus bug reports. > > > > Ever opened a UNIX textfile in Notepad, which is the default editor in > > most windows versions ? > > How does this relate to the current discussion? Because I got two reports with 'Hey, you'r docs are screwed in Notepad'. > By "RPM maintainer" do you mean maintainer of the .rpm package or > maintainer of the RPM package management tool? The maintainer. > I don't even use RPM myself; I use Debian. But every now and then I'm > forced to use a Windows machine and sometimes do find it very convenient to > be able to unpack Debian packages. I use about all there is in package management. I don't care if people unpack / build things on Windows, as long as I don't get bug reports. And I do get them. > - Ruud de Rooij. Igmar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: large memory support for x86
On Thu, 12 Oct 2000, Oliver Xymoron wrote:
> On Wed, 11 Oct 2000, Kiril Vidimce wrote:
>
> > My primary concern is whether a process can allocate more than 4 GB of
> > memory, rather than just be able to use more than 4 GB of physical
> > memory in the system.
>
> Define allocate. There are tricks you can play, but userspace is still a
> flat 32-bit address space per-process.
>
--- per process. Which means, in principle, that one could have 100
processes that are accessing a total of 400 Gb of virtual memory.
It gets to be a bit less than that, though. Process virtual address
space doesn't start at 0
Script started on Thu Oct 12 13:25:45 2000
cat xxx.c
main()
{
printf("main() starts at %p\n", main);
}
# gcc -o xxx xxx.c
# ./xxx
main() starts at 0x8048488
# exit
exit
Script done on Thu Oct 12 13:26:08 2000
Cheers,
Dick Johnson
Penguin : Linux version 2.2.17 on an i686 machine (801.18 BogoMips).
"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: large memory support for x86
On Wed, 11 Oct 2000, Kiril Vidimce wrote: > My primary concern is whether a process can allocate more than 4 GB of > memory, rather than just be able to use more than 4 GB of physical > memory in the system. Define allocate. There are tricks you can play, but userspace is still a flat 32-bit address space per-process. > Also, I see that the highmem support is just an option in the kernel. > Does this mean that there is a significant performance penalty in using > this extension? It doesn't come for free, but it's almost certainly a win for anyone who has that much memory. -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: want tool to open RPM package on Window 95
On 2000/10/12, Igmar Palsenberg wrote: > > > I can think of a number of uses for such a tool. For example, to read > > the documentation of a package before installing it on a different > > (Linux-based) system; or to unpack a source-rpm in order to build it > > with Cygwin. > > Bad idea. Most RPM'S contain specific RH patches, most of them being path > fixes. Get the tar.gz in that case. Some software may only (easily) be available in src-rpm format. I might just want to build one of the binaries in it by hand. I might just want to read the docs. I might ... The point is not what I might or might not want; the point is that there are valid uses for RPM on Windows. > Second, there is no way to actually build on a Windows machine, so I don't > see the use of it. There's no reason why RPM might not be ported to Cygwin. > > > Second, I'm glad there isn't. Saves tons of bugus bug reports. > > Ever opened a UNIX textfile in Notepad, which is the default editor in > most windows versions ? How does this relate to the current discussion? > > Bug reports for whom? > > The RPM maintainer. By "RPM maintainer" do you mean maintainer of the .rpm package or maintainer of the RPM package management tool? I don't even use RPM myself; I use Debian. But every now and then I'm forced to use a Windows machine and sometimes do find it very convenient to be able to unpack Debian packages. - Ruud de Rooij. -- ruud de rooij | *@spam.ruud.org | http://ruud.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: TODO: drivers/pcmcia/ds.c: ds_read
Yong Chi wrote:
> Hopefully this will do for SMP locks. =)
You must not hold a spinlock across put_user - instead you must copy the
get_queued_event(user) into a local variable, spinunlock and then copy
it to userspace.
Compare drivers/sbus/char/sunkbd.c, function kbd_read from 2.2 and 2.4:
2.2.17 is bad, 2.4.0 is fixed.
>
> Todo list also said that on UP, sleep_on() use is unsafe. It uses
> "interruptible_sleep_on()" and "wake_up_interruptible()" calls. Are they
> not safe on UP?
>
I depends: there are exactly 2 safe uses for sleep_on(), all other
combinations can lock up:
1) The wake-up occurs from process context (neither bh nor interrupt),
and _both_ the thread that goes to sleep and the thread that wakes up
use lock_kernel().
2) If the wake-up occurs from interrupt context (only real interrupt or
bottom half, NOT from tasklet/softirq), then the thread that goes to
sleep must protect itself with the global cli lock.
wake_up_sleeper()
{
new_data = 1;
wake_up(&wait_queue);
}
go_to_sleep()
{
/* local interrupts must be enabled */
cli();
if(!new_data) {
sleep_on(&wait_queue);
}
sti();
}
IIRC handle_event is called from interrupt context, thus a wake-up can
happen from within an interrupt, but there is no cli() before the
sleep_on() --> lock-up, even on UP possible.
But do not add cli() - remove sleep_on() and replace it with something
like wait_event_irq() [from include/linux/raid/md_k.h]
--
Manfred
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: TODO: drivers/pcmcia/ds.c: ds_read & ds_write. SMP locks are missing fix - TAKE 2
Take 2 based on semaphore -)
Jan-Simon Pendry wrote:
> holding a spin lock across a (potential) sleep is a bug - it can
> lead to deadlock.
>
> jan-simon.
>
> Jakub Jelinek wrote:
> >
> > On Thu, Oct 12, 2000 at 11:38:11AM -0400, Yong Chi wrote:
> > > Hopefully this will do for SMP locks. =)
> >
> > Holding a spinlock for this long (especially when you might sleep there in two
> > places (interruptible_sleep_on, put_user)) is basically a bad idea.
> > spinlocks are designed to be holded only for short time.
> > Either protect just a small critical section with a spinlock, or use
> > semaphores.
> >
> > > --- ds.c.bak Wed Oct 11 13:05:16 2000
> > > +++ ds.c Thu Oct 12 11:25:20 2000
> > > @@ -95,6 +95,7 @@
> > > u_intuser_magic;
> > > int event_head, event_tail;
> > > event_t event[MAX_EVENTS];
> > > +spinlock_t lock;
> > > struct user_info_t *next;
> > > } user_info_t;
> > >
> > > @@ -567,6 +568,7 @@
> > > user->event_tail = user->event_head = 0;
> > > user->next = s->user;
> > > user->user_magic = USER_MAGIC;
> > > +spin_lock_init(&user->lock);
> > > s->user = user;
> > > file->private_data = user;
> > >
> > > @@ -616,6 +618,7 @@
> > > socket_t i = MINOR(file->f_dentry->d_inode->i_rdev);
> > > socket_info_t *s;
> > > user_info_t *user;
> > > +ssize_t retval=4;
> > >
> > > DEBUG(2, "ds_read(socket %d)\n", i);
> > >
> > > @@ -625,16 +628,23 @@
> > > return -EINVAL;
> > > s = &socket_table[i];
> > > user = file->private_data;
> > > -if (CHECK_USER(user))
> > > - return -EIO;
> > > -
> > > +spin_lock(&user->lock);
> > > +if (CHECK_USER(user)) {
> > > + retval= -EIO;
> > > +goto read_out;
> > > +}
> > > +
> > > if (queue_empty(user)) {
> > > interruptible_sleep_on(&s->queue);
> > > if (signal_pending(current))
> > > - return -EINTR;
> > > + retval= -EINTR;
> > > +goto read_out;
> > > }
> > > put_user(get_queued_event(user), (int *)buf);
> > > -return 4;
> > > +
> > > +read_out:
> > > +spin_unlock(&user->lock);
> > > +return retval;
> > > } /* ds_read */
> > >
> > > /**/
> > > @@ -645,6 +655,7 @@
> > > socket_t i = MINOR(file->f_dentry->d_inode->i_rdev);
> > > socket_info_t *s;
> > > user_info_t *user;
> > > +ssize_t retval=4;
> > >
> > > DEBUG(2, "ds_write(socket %d)\n", i);
> > >
> > > @@ -656,18 +667,25 @@
> > > return -EBADF;
> > > s = &socket_table[i];
> > > user = file->private_data;
> > > -if (CHECK_USER(user))
> > > - return -EIO;
> > > +spin_lock(&user->lock);
> > > +if (CHECK_USER(user)) {
> > > + retval= -EIO;
> > > + goto write_out;
> > > +}
> > >
> > > if (s->req_pending) {
> > > s->req_pending--;
> > > get_user(s->req_result, (int *)buf);
> > > if ((s->req_result != 0) || (s->req_pending == 0))
> > > wake_up_interruptible(&s->request);
> > > -} else
> > > - return -EIO;
> > > +} else {
> > > + retval= -EIO;
> > > + goto write_out;
> > > +}
> > >
> > > -return 4;
> > > +write_out:
> > > +spin_unlock(&user->lock);
> > > +return retval;
> > > } /* ds_write */
> > >
> > > /**/
> >
> > Jakub
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to [EMAIL PROTECTED]
> > Please read the FAQ at http://www.tux.org/lkml/
--- ds.c.bakWed Oct 11 13:05:16 2000
+++ ds.cThu Oct 12 13:05:28 2000
@@ -95,6 +95,7 @@
u_int user_magic;
intevent_head, event_tail;
event_tevent[MAX_EVENTS];
+struct semaphoresem;
struct user_info_t *next;
} user_info_t;
@@ -567,6 +568,7 @@
user->event_tail = user->event_head = 0;
user->next = s->user;
user->user_magic = USER_MAGIC;
+init_MUTEX(&user->sem);
s->user = user;
file->private_data = user;
@@ -616,6 +618,7 @@
socket_t i = MINOR(file->f_dentry->d_inode->i_rdev);
socket_info_t *s;
user_info_t *user;
+ssize_t retval=4;
DEBUG(2, "ds_read(socket %d)\n", i);
@@ -625,16 +628,26 @@
return -EINVAL;
s = &socket_table[i];
user = file->private_data;
-if (CHECK_USER(user))
- return -EIO;
-
+down_interruptible(&user->sem);
+if (signal_pending(current))
+return -EINTR;
+
+if (CHECK_USER(user)) {
+ retval= -EIO;
+goto read_out;
+}
+
if (queue_empty(user)) {
interruptible_sleep_on(&s->queue);
if (signal_pending(current))
- return -EINTR;
+ retval= -EINTR;
+goto read_out;
}
put_user(get_queued_event(user), (int *)buf);
Re: want tool to open RPM package on Window 95
> I can think of a number of uses for such a tool. For example, to read > the documentation of a package before installing it on a different > (Linux-based) system; or to unpack a source-rpm in order to build it > with Cygwin. Bad idea. Most RPM'S contain specific RH patches, most of them being path fixes. Get the tar.gz in that case. Second, there is no way to actually build on a Windows machine, so I don't see the use of it. > > Second, I'm glad there isn't. Saves tons of bugus bug reports. Ever opened a UNIX textfile in Notepad, which is the default editor in most windows versions ? > Bug reports for whom? The RPM maintainer. > > - Ruud de Rooij. Igmar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: aic7xxx problem on linux-2.4.0-test10-pre1
On Thu, Oct 12 2000, Young-Ho Cha wrote: > I have adaptec 20160 scsi adapter and plextor 32x cdrom. > > I played audio cd with gtcd(gnome app) and eject cdrom with gtcd(eject button) > > , gtcd died and dmesg out... Eek, bad bug. Try this patch. -- * Jens Axboe <[EMAIL PROTECTED]> * SuSE Labs --- /opt/kernel/linux-2.4.0-test10-pre1/drivers/scsi/sr_ioctl.c Mon Sep 11 02:49:27 2000 +++ drivers/scsi/sr_ioctl.c Thu Oct 12 19:01:09 2000 @@ -341,7 +341,7 @@ sr_cmd[7] = ti->cdti_trk1; sr_cmd[8] = ti->cdti_ind1; - result = sr_do_ioctl(target, sr_cmd, NULL, 255, 0, SCSI_DATA_NONE); + result = sr_do_ioctl(target, sr_cmd, NULL, 0, 0, SCSI_DATA_NONE); break; }
Re: Updated 2.4 TODO List - more on PCI resources...]
On Thu, 12 Oct 2000, Dag Bakke wrote:
>
> Linus,
> I realized there was one more test to do before deeming the hardware sane.
>
> PCMCIA (16-bit) in my laptop is tested and works fine with three different
> types of cards.
> Another Xircom card behaved just the same (non-functional) in my latop.
> My Xircom card was tested in another laptop and found working.
>
> Today I took my card *and* disk and tested it in an identical laptop.
> It works.
>
> So it appears that the *cardbus* logic is broken on my machine. Plain, old
> hardware defect. And I have been wasting your time. Sorry about that.
No problem. This was good to have it out of the way. And I don't think you
actually wasted my time: this may still be a Linux bug. See more below.
> In any case, debug output follows for both the non-working and the working
> case. Feel free to pin-point the hw-bug or flat out ignore it.
Yup, bug pin-pointed, and clear: these are the resources for the failing
case:
> device PCI device 115d:0003 resource 1 size 04000800
> device PCI device 115d:0003 resource 2 size 04000800
> device PCI device 115d:0003 resource 6 size 04004000
> device PCI device 115d:0003 resource 6 size 04004000
> device PCI device 115d:0103 resource 1 size 04000800
> device PCI device 115d:0103 resource 2 size 04000800
> device PCI device 115d:0103 resource 6 size 04004000
> device PCI device 115d:0103 resource 6 size 04004000
While I'll bet you $20 that the working case (which doesn't print out the
same printk because it doesn't fail) has the exact same resources, except
the "size" field doesn't have that pesky high bit set, so the sizes are
all 0x0800 of 0x4000 instead of being 64MB+.
Now, that said, I do think that this is a linux bug. Sure, your hardware
is strange too, and hardware obviously _does_ make a difference, but there
is no way a non-power-of-two size field can ever be valid, and Linux is
buggy for allowing the hardware to confuse it this way.
What seems to be happening is that somehow your cardbus bridge (or docking
station bridge) is set up so that it doesn't let through that high bit
that defines the size of the PCI bridge map, and the way Linux calculates
the size is basically the simplistic
write all 1's to the base register
read the base register
sz = ~(base & mask) & maxmask;
and while that works most of the time in normal situations, it's really
not correct. What we _should_ do is more akin to this patch. Can you test
this on your broken system, and see if the system magically comes to life?
NOTE! I do worry about the masking off of a bit in the bridge. There may
be a real hardware bug there - but the fact that the mask seems to move
depending on how big a bridge window there is (judging by your past mails
about how behaviour did actually change when changing the cardbus window
size) implies to me that it's not something as simple as a stuck bit.
If it is a stuck bit somehow, then you're screwed, and the patch below
won't help you at all. But if it's the bridge snooping (and modifying) the
decode window sizes, then the patch below should make a difference.
Thanks,
Linus
--- v2.4.0-test9/linux/drivers/pci/pci.cSun Oct 8 10:50:20 2000
+++ linux/drivers/pci/pci.c Thu Oct 12 09:52:07 2000
@@ -474,6 +474,16 @@
return IORESOURCE_MEM;
}
+/*
+ * Find the extent of a PCI decode..
+ */
+static u32 pci_size(u32 base, u32 mask)
+{
+ u32 size = mask & base; /* Find the significant bits */
+ size = size & ~(size-1);/* Get the lowest of them to find the decode
+size */
+ return size-1; /* extent = size - 1 */
+}
+
static void pci_read_bases(struct pci_dev *dev, unsigned int howmany, int rom)
{
unsigned int pos, reg, next;
@@ -501,10 +511,10 @@
l = 0;
if ((l & PCI_BASE_ADDRESS_SPACE) == PCI_BASE_ADDRESS_SPACE_MEMORY) {
res->start = l & PCI_BASE_ADDRESS_MEM_MASK;
- sz = ~(sz & PCI_BASE_ADDRESS_MEM_MASK);
+ sz = pci_size(sz, PCI_BASE_ADDRESS_MEM_MASK);
} else {
res->start = l & PCI_BASE_ADDRESS_IO_MASK;
- sz = ~(sz & PCI_BASE_ADDRESS_IO_MASK) & 0x;
+ sz = pci_size(sz, PCI_BASE_ADDRESS_IO_MASK & 0x);
}
res->end = res->start + (unsigned long) sz;
res->flags |= (l & 0xf) | pci_calc_resource_flags(l);
@@ -543,7 +553,7 @@
res->flags = (l & PCI_ROM_ADDRESS_ENABLE) |
IORESOURCE_MEM | IORESOURCE_PREFETCH | IORESOURCE_READONLY |
IORESOURCE_CACHEABLE;
res->start = l & PCI_ROM_ADDRESS_MASK;
- sz = ~(sz & PCI_ROM_ADDRESS_MASK);
+ sz = pci_size(sz, PCI_ROM_ADDRESS_MASK);
res->end = res->start + (unsigned long) s
Re: BIG problem with BusLogic SCSI and/or something else
On Thu, 12 Oct 2000, Jeff Garzik wrote:
> "Richard B. Johnson" wrote:
> > --- linux-2.2.17/drivers/scsi/BusLogic.h.orig Thu Oct 12 11:22:44 2000
> > +++ linux-2.2.17/drivers/scsi/BusLogic.hThu Oct 12 11:47:07 2000
> > @@ -1509,6 +1509,7 @@
> > void BusLogic_AcquireHostAdapterLock(BusLogic_HostAdapter_T *HostAdapter,
> > ProcessorFlags_T *ProcessorFlags)
> > {
> > + spin_lock_irqsave(&BusLogic_lock, *ProcessorFlags);
> > }
> >
> >
> > @@ -1520,6 +1521,7 @@
> > void BusLogic_ReleaseHostAdapterLock(BusLogic_HostAdapter_T *HostAdapter,
> > ProcessorFlags_T *ProcessorFlags)
> > {
> > + spin_unlock_irqrestore(&BusLogic_lock, *ProcessorFlags);
> > }
>
>
> Don't pass processor flags on the stack...
>
Look at the @$%@)&$) code! I am NOT. The spin-lock code was in the
BusLogic code. It was defined as empty in-lines. It passed the address.
I just filled-in the stuff left out.
Cheers,
Dick Johnson
Penguin : Linux version 2.2.17 on an i686 machine (801.18 BogoMips).
"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
The IO problem, ISA vs. PCI
Note to linux-kenrel readers: This discussion is the Nth attempt to find
a solution to handle both legacy IOs and PCI IOs on machines with several
IO busses memory mapped at different locations in the CPU space.
>No please, is there anybody bloat-conscious on this damned list ? Burying
>more and more code inside each {in,out}[bwl] is not the solution.
Well, that is pretty small overhead, and probably ridiculous compared to
the overhead of the IO itself. Most fast devices use MMIO anyway.
The problem is that whatever solution someone propose, there is _always_
somebody to reject it.
>Just define a macro ISA_PORT or something like this and update the kernel
>to replace all the in/out to fixed ports to do in/out(ISA_PORT(n)). If you
>don't do it you'll get a nice panic so you'll find all the places quite
>fast.
That basically mean making different macros for ISA in/out and PCI in/
out. I've proposed this several time, but it requires changes to the
common code, and all I got when talking about this was flames from x86 people.
>Drawbacks ?
Take the time to make this fit into some x86 people head. Also, I need
something that can be ported quickly to 2.4. I'm afraid even if we make
everybody agree to it, it will be delayed to 2.5.
Linus: Would you accept this change now ?
#define ISA_PORT(n) (n)
And change to _all_ drivers doing legacy IOs to use that in their in/out
macros ?
I still prefer making separate macros for legacy IOs (isa_in/isa_out) and
for PCI IOs (in/out), or the opposite if you prefer (in/out for isa and
pci_in/pci_out for PCI).
On x86, they would resolve to the same thing, while on our platforms,
they could be handled differently.
>PCI I/O resources will have to be kernel virtual, physical is impossible
>with PreP if we want to lift the 2Gbuser space restriction (PreP I/O is
>from 2 to 3 Gb physical and the first thing to do is to reallocate devices
>which use it since most firmware use it too liberally, like one device
>every ... 256Mb). There are other and better ways to increase user
>available virtual space, however. And anyway I don't want any stinking add
>in each in/out macro.
Well, in 2.4 we can easily reassign PCI IOs if we configure the bridge
with proper resources. If all goes well, my new PCI code should handle
that fine (should be ready this week-end).
>Indeed, this is too awkward (is tere no way to redirect only the VGA
>part of the legacy I/O space ? That's what the PCI-PCI bridges do, but
>I've not yet used a single machine with AGP so I'm ignorant).
No, most bridges used on macs can't do that. In fact, AFAIK, it's not
possible to access the ISA memory space neither on those machines (on
UniN, I can't generate memory cycles at lower address than 0x8000).
My "pet" solution would be to have all legacy drivers request an IO base
this way
base = isa_get_IO_base(legacy_addr);
The isa_get_IO_base function could then be "tweaked" to recognize known
legacy addresses and return different bases. (There might still be
problems with VGA vs. parallell, I don't know x86 world well enough to be
sure).
Ben.
-- RFC822 Header Follows --
From: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
To: Gabriel Paubert <[EMAIL PROTECTED]>, Linux/PowerPC Devel List
<[EMAIL PROTECTED]>, Linus Torvalds <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Subject: Re: dual head r128
Date: Thu, 12 Oct 2000 18:58:15 +0200
Message-Id: <[EMAIL PROTECTED]>
In-Reply-To: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
X-Mailer: CTM PowerMail 3.0.5
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
---
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: dual head r128
Note to linux-kenrel readers: This discussion is the Nth attempt to find
a solution to handle both legacy IOs and PCI IOs on machines with several
IO busses memory mapped at different locations in the CPU space.
>No please, is there anybody bloat-conscious on this damned list ? Burying
>more and more code inside each {in,out}[bwl] is not the solution.
Well, that is pretty small overhead, and probably ridiculous compared to
the overhead of the IO itself. Most fast devices use MMIO anyway.
The problem is that whatever solution someone propose, there is _always_
somebody to reject it.
>Just define a macro ISA_PORT or something like this and update the kernel
>to replace all the in/out to fixed ports to do in/out(ISA_PORT(n)). If you
>don't do it you'll get a nice panic so you'll find all the places quite
>fast.
That basically mean making different macros for ISA in/out and PCI in/
out. I've proposed this several time, but it requires changes to the
common code, and all I got when talking about this was flames from x86 people.
>Drawbacks ?
Take the time to make this fit into some x86 people head. Also, I need
something that can be ported quickly to 2.4. I'm afraid even if we make
everybody agree to it, it will be delayed to 2.5.
Linus: Would you accept this change now ?
#define ISA_PORT(n) (n)
And change to _all_ drivers doing legacy IOs to use that in their in/out
macros ?
I still prefer making separate macros for legacy IOs (isa_in/isa_out) and
for PCI IOs (in/out), or the opposite if you prefer (in/out for isa and
pci_in/pci_out for PCI).
On x86, they would resolve to the same thing, while on our platforms,
they could be handled differently.
>PCI I/O resources will have to be kernel virtual, physical is impossible
>with PreP if we want to lift the 2Gbuser space restriction (PreP I/O is
>from 2 to 3 Gb physical and the first thing to do is to reallocate devices
>which use it since most firmware use it too liberally, like one device
>every ... 256Mb). There are other and better ways to increase user
>available virtual space, however. And anyway I don't want any stinking add
>in each in/out macro.
Well, in 2.4 we can easily reassign PCI IOs if we configure the bridge
with proper resources. If all goes well, my new PCI code should handle
that fine (should be ready this week-end).
>Indeed, this is too awkward (is tere no way to redirect only the VGA
>part of the legacy I/O space ? That's what the PCI-PCI bridges do, but
>I've not yet used a single machine with AGP so I'm ignorant).
No, most bridges used on macs can't do that. In fact, AFAIK, it's not
possible to access the ISA memory space neither on those machines (on
UniN, I can't generate memory cycles at lower address than 0x8000).
My "pet" solution would be to have all legacy drivers request an IO base
this way
base = isa_get_IO_base(legacy_addr);
The isa_get_IO_base function could then be "tweaked" to recognize known
legacy addresses and return different bases. (There might still be
problems with VGA vs. parallell, I don't know x86 world well enough to be
sure).
Ben.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: IRQ affinity vs. MTRRs, was Re: 36 bit MTRRs, Re: test10-pre1problems on 4-way SuperServer8050
> > every CPU to avoid slowdowns. So that if you set that eth0's > > IRQ will be handled by CPU1, the MTRRs of CPU1 will be set > > accordingly, and the other CPUs will not care about eth0, > > so they do not need eth0's MTRR settings. > > A little question. Why do we want to bind irq of eth0 to a single CPU ? > imho it will casue slowdown of some situation. Why don't we leave scheduler > to select CPU for processing IRQ ? This would be really horrible for video cards. X would come to a crawl :-( - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.17+reiserfs crash
Sudhindra Herle, you write: > I just got two separate crashes using 2.2.17 and reiserfs. You should probably contact the reiserfs mailing list because reiserfs is not in the official kernel. > I have lost faith in reiserfs. So, I'll rebuild the kernel and move back > to EXT2. Oh well... Cheers, Andreas - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
dst cache overflow
I'm running kernel version 2.2.14 as a firewall with moderately high load. After a few hours, i start getting "dst cache overflow" log messages. That apparently comes from rt_garbage_collect in route.c I have seen a few discussions about this in the archives, but nothing ever seemed too conclusive. One suggestion was that the kernel needed a patch which changed the line rt_del(hash, rt) to rt_del(hash, rth) But that appears to be in my kernel, that is if it's in the code for ip_rt_redirect. Another suggested a problem where thousands of connections were stuck in LAST_ACK state, presumably keeping the cache entry tied up and therefore not eligible to expire. But I am only seeing a few connections in this state - i.e., this doesn't appear to be what's causing my problem. Anyone out there have any further information or insight into this? One thing that concerns me is that rt_garbage_collect will only make one pass through the main loop while in_interrupt() ... thus perhaps that is why it doesn't make it's goal of getting the cache entries below ip_rt_max_size. if i am under heavy load, perhaps i am spending too much time in_interrupt() which is why I can't trim down the cache sufficiently?? Or does this perhaps sound like a memory leak or something? Thanks for any insight. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: BIG problem with BusLogic SCSI and/or something else
"Richard B. Johnson" wrote:
> --- linux-2.2.17/drivers/scsi/BusLogic.h.orig Thu Oct 12 11:22:44 2000
> +++ linux-2.2.17/drivers/scsi/BusLogic.hThu Oct 12 11:47:07 2000
> @@ -1509,6 +1509,7 @@
> void BusLogic_AcquireHostAdapterLock(BusLogic_HostAdapter_T *HostAdapter,
> ProcessorFlags_T *ProcessorFlags)
> {
> + spin_lock_irqsave(&BusLogic_lock, *ProcessorFlags);
> }
>
>
> @@ -1520,6 +1521,7 @@
> void BusLogic_ReleaseHostAdapterLock(BusLogic_HostAdapter_T *HostAdapter,
> ProcessorFlags_T *ProcessorFlags)
> {
> + spin_unlock_irqrestore(&BusLogic_lock, *ProcessorFlags);
> }
Don't pass processor flags on the stack...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Updated Linux 2.4 Status/TODO List (from the ALS show)
On Thu, Oct 12, 2000 at 08:06:46AM -0400, [EMAIL PROTECTED] wrote:
> * USB: booting with USB compiled into kernel causes a lot of syslog
>entries as the root hubs are probed by all drivers (this is
>especially obnoxious as the usb-serial drivers start up)
Fixed in test9. If anyone still sees this, please let me know.
> * USB: fix setting urb->dev in printer, acm, bluetooth, all serial
>drivers (Greg KH) {CRITICAL}
Fixed in test10-pre1.
> * USB: fix usb-uhci setting urb->dev = NULL at correct places only
>{CRITICAL}
Fixed in test10-pre1.
thanks,
greg k-h
--
greg@(kroah|wirex).com
http://immunix.org/~greg
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: BIG problem with BusLogic SCSI and/or something else
On Thu, 12 Oct 2000, Matthias Andree wrote:
> > Note that the sync-rate of target 6, the device I added, has been
> > turned down to try to eliminate any hardware problems. Also note
> > that the entire drive has been read/written with the BusLogic BIOS
> > diagnostic setup utility.
>
> That BIOS setup tool might just use asynchronous I/O for anything,
> so this may not be an indicator in any way.
>
> Did you check your cable length and termination? You need exactly two
> terminators, one at each end of the cable. None in between. Note that
> the host adaptor does not get terminated if you connect two cables to
> it.
Sorry. I know about SCSI.
>
> Do you have a different machine with null-modem or something? You could
> copy your syslog/klog output there, or you could send it to a different
> host in your LAN.
>
There is some race when I/O is being performed between two disks on
a SMP machine.
This fixes the race although it may be too "brute-force" to be the
"final" version because one may not want to single-thread everything
as I have done.
--- linux-2.2.17/drivers/scsi/BusLogic.c.orig Thu Oct 12 10:44:04 2000
+++ linux-2.2.17/drivers/scsi/BusLogic.cThu Oct 12 11:50:32 2000
@@ -50,6 +50,9 @@
#include "scsi.h"
#include "hosts.h"
#include "sd.h"
+
+static spinlock_t BusLogic_lock = SPIN_LOCK_UNLOCKED;
+
#include "BusLogic.h"
#include "FlashPoint.c"
@@ -413,6 +416,7 @@
waiting for the Host Adapter Ready bit to be set in the Status Register.
*/
+
static int BusLogic_Command(BusLogic_HostAdapter_T *HostAdapter,
BusLogic_OperationCode_T OperationCode,
void *ParameterData,
@@ -424,7 +428,6 @@
unsigned char *ReplyPointer = (unsigned char *) ReplyData;
BusLogic_StatusRegister_T StatusRegister;
BusLogic_InterruptRegister_T InterruptRegister;
- ProcessorFlags_T ProcessorFlags = 0;
int ReplyBytes = 0, Result;
long TimeoutCounter;
/*
@@ -433,17 +436,6 @@
if (ReplyLength > 0)
memset(ReplyData, 0, ReplyLength);
/*
-If the IRQ Channel has not yet been acquired, then interrupts must be
-disabled while issuing host adapter commands since a Command Complete
-interrupt could occur if the IRQ Channel was previously enabled by another
-BusLogic Host Adapter or another driver sharing the same IRQ Channel.
- */
- if (!HostAdapter->IRQ_ChannelAcquired)
-{
- save_flags(ProcessorFlags);
- cli();
-}
- /*
Wait for the Host Adapter Ready bit to be set and the Command/Parameter
Register Busy bit to be reset in the Status Register.
*/
@@ -632,8 +624,6 @@
Restore the interrupt status if necessary and return.
*/
Done:
- if (!HostAdapter->IRQ_ChannelAcquired)
-restore_flags(ProcessorFlags);
return Result;
}
--- linux-2.2.17/drivers/scsi/BusLogic.h.orig Thu Oct 12 11:22:44 2000
+++ linux-2.2.17/drivers/scsi/BusLogic.hThu Oct 12 11:47:07 2000
@@ -1509,6 +1509,7 @@
void BusLogic_AcquireHostAdapterLock(BusLogic_HostAdapter_T *HostAdapter,
ProcessorFlags_T *ProcessorFlags)
{
+ spin_lock_irqsave(&BusLogic_lock, *ProcessorFlags);
}
@@ -1520,6 +1521,7 @@
void BusLogic_ReleaseHostAdapterLock(BusLogic_HostAdapter_T *HostAdapter,
ProcessorFlags_T *ProcessorFlags)
{
+ spin_unlock_irqrestore(&BusLogic_lock, *ProcessorFlags);
}
Cheers,
Dick Johnson
Penguin : Linux version 2.2.17 on an i686 machine (801.18 BogoMips).
"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: TODO: drivers/pcmcia/ds.c: ds_read & ds_write. SMP locks are missing fix
holding a spin lock across a (potential) sleep is a bug - it can
lead to deadlock.
jan-simon.
Jakub Jelinek wrote:
>
> On Thu, Oct 12, 2000 at 11:38:11AM -0400, Yong Chi wrote:
> > Hopefully this will do for SMP locks. =)
>
> Holding a spinlock for this long (especially when you might sleep there in two
> places (interruptible_sleep_on, put_user)) is basically a bad idea.
> spinlocks are designed to be holded only for short time.
> Either protect just a small critical section with a spinlock, or use
> semaphores.
>
> > --- ds.c.bak Wed Oct 11 13:05:16 2000
> > +++ ds.c Thu Oct 12 11:25:20 2000
> > @@ -95,6 +95,7 @@
> > u_intuser_magic;
> > int event_head, event_tail;
> > event_t event[MAX_EVENTS];
> > +spinlock_t lock;
> > struct user_info_t *next;
> > } user_info_t;
> >
> > @@ -567,6 +568,7 @@
> > user->event_tail = user->event_head = 0;
> > user->next = s->user;
> > user->user_magic = USER_MAGIC;
> > +spin_lock_init(&user->lock);
> > s->user = user;
> > file->private_data = user;
> >
> > @@ -616,6 +618,7 @@
> > socket_t i = MINOR(file->f_dentry->d_inode->i_rdev);
> > socket_info_t *s;
> > user_info_t *user;
> > +ssize_t retval=4;
> >
> > DEBUG(2, "ds_read(socket %d)\n", i);
> >
> > @@ -625,16 +628,23 @@
> > return -EINVAL;
> > s = &socket_table[i];
> > user = file->private_data;
> > -if (CHECK_USER(user))
> > - return -EIO;
> > -
> > +spin_lock(&user->lock);
> > +if (CHECK_USER(user)) {
> > + retval= -EIO;
> > +goto read_out;
> > +}
> > +
> > if (queue_empty(user)) {
> > interruptible_sleep_on(&s->queue);
> > if (signal_pending(current))
> > - return -EINTR;
> > + retval= -EINTR;
> > +goto read_out;
> > }
> > put_user(get_queued_event(user), (int *)buf);
> > -return 4;
> > +
> > +read_out:
> > +spin_unlock(&user->lock);
> > +return retval;
> > } /* ds_read */
> >
> > /**/
> > @@ -645,6 +655,7 @@
> > socket_t i = MINOR(file->f_dentry->d_inode->i_rdev);
> > socket_info_t *s;
> > user_info_t *user;
> > +ssize_t retval=4;
> >
> > DEBUG(2, "ds_write(socket %d)\n", i);
> >
> > @@ -656,18 +667,25 @@
> > return -EBADF;
> > s = &socket_table[i];
> > user = file->private_data;
> > -if (CHECK_USER(user))
> > - return -EIO;
> > +spin_lock(&user->lock);
> > +if (CHECK_USER(user)) {
> > + retval= -EIO;
> > + goto write_out;
> > +}
> >
> > if (s->req_pending) {
> > s->req_pending--;
> > get_user(s->req_result, (int *)buf);
> > if ((s->req_result != 0) || (s->req_pending == 0))
> > wake_up_interruptible(&s->request);
> > -} else
> > - return -EIO;
> > +} else {
> > + retval= -EIO;
> > + goto write_out;
> > +}
> >
> > -return 4;
> > +write_out:
> > +spin_unlock(&user->lock);
> > +return retval;
> > } /* ds_write */
> >
> > /**/
>
> Jakub
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: TODO: drivers/pcmcia/ds.c: ds_read & ds_write. SMP locks are missing fix
On Thu, Oct 12, 2000 at 11:38:11AM -0400, Yong Chi wrote:
> Hopefully this will do for SMP locks. =)
Holding a spinlock for this long (especially when you might sleep there in two
places (interruptible_sleep_on, put_user)) is basically a bad idea.
spinlocks are designed to be holded only for short time.
Either protect just a small critical section with a spinlock, or use
semaphores.
> --- ds.c.bak Wed Oct 11 13:05:16 2000
> +++ ds.c Thu Oct 12 11:25:20 2000
> @@ -95,6 +95,7 @@
> u_intuser_magic;
> int event_head, event_tail;
> event_t event[MAX_EVENTS];
> +spinlock_t lock;
> struct user_info_t *next;
> } user_info_t;
>
> @@ -567,6 +568,7 @@
> user->event_tail = user->event_head = 0;
> user->next = s->user;
> user->user_magic = USER_MAGIC;
> +spin_lock_init(&user->lock);
> s->user = user;
> file->private_data = user;
>
> @@ -616,6 +618,7 @@
> socket_t i = MINOR(file->f_dentry->d_inode->i_rdev);
> socket_info_t *s;
> user_info_t *user;
> +ssize_t retval=4;
>
> DEBUG(2, "ds_read(socket %d)\n", i);
>
> @@ -625,16 +628,23 @@
> return -EINVAL;
> s = &socket_table[i];
> user = file->private_data;
> -if (CHECK_USER(user))
> - return -EIO;
> -
> +spin_lock(&user->lock);
> +if (CHECK_USER(user)) {
> + retval= -EIO;
> +goto read_out;
> +}
> +
> if (queue_empty(user)) {
> interruptible_sleep_on(&s->queue);
> if (signal_pending(current))
> - return -EINTR;
> + retval= -EINTR;
> +goto read_out;
> }
> put_user(get_queued_event(user), (int *)buf);
> -return 4;
> +
> +read_out:
> +spin_unlock(&user->lock);
> +return retval;
> } /* ds_read */
>
> /**/
> @@ -645,6 +655,7 @@
> socket_t i = MINOR(file->f_dentry->d_inode->i_rdev);
> socket_info_t *s;
> user_info_t *user;
> +ssize_t retval=4;
>
> DEBUG(2, "ds_write(socket %d)\n", i);
>
> @@ -656,18 +667,25 @@
> return -EBADF;
> s = &socket_table[i];
> user = file->private_data;
> -if (CHECK_USER(user))
> - return -EIO;
> +spin_lock(&user->lock);
> +if (CHECK_USER(user)) {
> + retval= -EIO;
> + goto write_out;
> +}
>
> if (s->req_pending) {
> s->req_pending--;
> get_user(s->req_result, (int *)buf);
> if ((s->req_result != 0) || (s->req_pending == 0))
> wake_up_interruptible(&s->request);
> -} else
> - return -EIO;
> +} else {
> + retval= -EIO;
> + goto write_out;
> +}
>
> -return 4;
> +write_out:
> +spin_unlock(&user->lock);
> +return retval;
> } /* ds_write */
>
> /**/
Jakub
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
TODO: drivers/pcmcia/ds.c: ds_read & ds_write. SMP locks are missing fix
Hopefully this will do for SMP locks. =)
Todo list also said that on UP, sleep_on() use is unsafe. It uses
"interruptible_sleep_on()" and "wake_up_interruptible()" calls. Are they
not safe on UP?
Thanks
--- ds.c.bakWed Oct 11 13:05:16 2000
+++ ds.cThu Oct 12 11:25:20 2000
@@ -95,6 +95,7 @@
u_int user_magic;
intevent_head, event_tail;
event_tevent[MAX_EVENTS];
+spinlock_t lock;
struct user_info_t *next;
} user_info_t;
@@ -567,6 +568,7 @@
user->event_tail = user->event_head = 0;
user->next = s->user;
user->user_magic = USER_MAGIC;
+spin_lock_init(&user->lock);
s->user = user;
file->private_data = user;
@@ -616,6 +618,7 @@
socket_t i = MINOR(file->f_dentry->d_inode->i_rdev);
socket_info_t *s;
user_info_t *user;
+ssize_t retval=4;
DEBUG(2, "ds_read(socket %d)\n", i);
@@ -625,16 +628,23 @@
return -EINVAL;
s = &socket_table[i];
user = file->private_data;
-if (CHECK_USER(user))
- return -EIO;
-
+spin_lock(&user->lock);
+if (CHECK_USER(user)) {
+ retval= -EIO;
+goto read_out;
+}
+
if (queue_empty(user)) {
interruptible_sleep_on(&s->queue);
if (signal_pending(current))
- return -EINTR;
+ retval= -EINTR;
+goto read_out;
}
put_user(get_queued_event(user), (int *)buf);
-return 4;
+
+read_out:
+spin_unlock(&user->lock);
+return retval;
} /* ds_read */
/**/
@@ -645,6 +655,7 @@
socket_t i = MINOR(file->f_dentry->d_inode->i_rdev);
socket_info_t *s;
user_info_t *user;
+ssize_t retval=4;
DEBUG(2, "ds_write(socket %d)\n", i);
@@ -656,18 +667,25 @@
return -EBADF;
s = &socket_table[i];
user = file->private_data;
-if (CHECK_USER(user))
- return -EIO;
+spin_lock(&user->lock);
+if (CHECK_USER(user)) {
+ retval= -EIO;
+ goto write_out;
+}
if (s->req_pending) {
s->req_pending--;
get_user(s->req_result, (int *)buf);
if ((s->req_result != 0) || (s->req_pending == 0))
wake_up_interruptible(&s->request);
-} else
- return -EIO;
+} else {
+ retval= -EIO;
+ goto write_out;
+}
-return 4;
+write_out:
+spin_unlock(&user->lock);
+return retval;
} /* ds_write */
/**/
Re: Problem with include/linux/fs.h vs. glibc
>> - I mean, it's legal to include linux/fs.h from userland, > >Everybody who thinks so will be severely disappointed. Ok, so if it's not, then I have to fix that app. Thanks. Ben. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Updated 2.4 TODO List
On Thu, 12 Oct 2000, Keith Owens wrote: > If anything is going to detect the mismatch and complain, it has to be > the boot loader, after uncompressing and before entering the kernel > proper. Perhaps we can add the processor type to linux_banner and print it from setup.S. -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.14 SMP 3com905: transmit timed out: Odd lost irq and ip-stack lockup
"Maciej W. Rozycki" wrote:
>
> On Fri, 13 Oct 2000, Andrew Morton wrote:
>
> > > Oct 9 17:29:02 fwintern kernel: eth0: Interrupt posted but not
> > > delivered -- IRQ blocked by another device?
> >
> > This is the infamous APIC bug. I have about ten reports of this over a
> > four-month period. Mark Hemment mentioned it just yesterday.
> >
> > This is not a 3c59x problem. It is due to the APIC forgetting how to
> > generate interrupts for a particular IRQ. It happens mostly for NICs
> > because they generate a lot of interrupts. I've had it happen just
> > once. In that case, _nothing_ would make the interrupt come back
> > (including a driver unload/reload).
> >
> > This gets reported a lot by 3c59x users because this driver specifically
> > detects and reports on the problem.
>
> Hmm, that's interesting. It would be worthwhile to see a dump of APICs'
> state when this happens -- maybe an EOI message gets lost for some reason
> or an erratum is biting us. There are functions for such kind of
> diagnostics already available; they are print_IO_APIC() and
> print_all_local_APICs() and may be called on demand by a tiny module, for
> example.
Thanks!
Michael, would you be able to:
- go back to 2.4.0
- make sure you have 'Magic SYSRQ' enabled
- apply the below patch
- type ALT-SYSRQ-A when the machine is behaving
- make the machine misbehave
- type ALT-SYSRQ-A and
- send the resulting log output?
--- linux-2.4.0-test9/arch/i386/kernel/io_apic.cWed Oct 4 21:27:20 2000
+++ linux-akpm/arch/i386/kernel/io_apic.c Fri Oct 13 02:08:28 2000
@@ -692,7 +692,7 @@
printk(KERN_WARNING " to [EMAIL PROTECTED]\n");
}
-void __init print_IO_APIC(void)
+void print_IO_APIC(void)
{
int apic, i;
struct IO_APIC_reg_00 reg_00;
--- linux-2.4.0-test9/drivers/char/sysrq.c Fri Aug 11 19:06:11 2000
+++ linux-akpm/drivers/char/sysrq.c Fri Oct 13 02:09:19 2000
@@ -72,6 +72,12 @@
console_loglevel = 7;
printk(KERN_INFO "SysRq: ");
switch (key) {
+ case 'a':
+ printk("print_IO_APIC()\n");
+ print_IO_APIC();
+ printk("print_all_local_APICs()\n");
+ print_all_local_APICs();
+ break;
case 'r': /* R -- Reset raw mode */
if (kbd) {
kbd->kbdmode = VC_XLATE;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Problem with include/linux/fs.h vs. glibc
On Thu, Oct 12, 2000 at 05:00:49PM +0200, Benjamin Herrenschmidt wrote: > - I mean, it's legal to include linux/fs.h from userland, Everybody who thinks so will be severely disappointed. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ioremap of pci base addresses
Francois romieu wrote: > token = (unsigned long)ioremap(pci_resource_start(pdev, 0), > pci_resource_len(pdev, 0)); Looks great except for one small point -- we have been going through drivers cleaning up where they start casting like this. You should this token as a void*, and code which uses the value should adjust accordingly... Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] atomic pte updates for x86 smp
On Wed, 11 Oct 2000, Linus Torvalds wrote: > > On Thu, 12 Oct 2000, Benjamin C.R. LaHaise wrote: > > > > Note the fragment above those portions of the patch where the > > pte_xchg_clear is done on the page table: this results in a page fault > > for any other cpu that looks at the pte while it is unavailable. > > Ok, I see.. > > Hmm.. That's a singularly ugly interface, though - it all looks very > x86-specific. Things like "pte_xchg_clear()" look just a bit too obviously > like the name only makes sense due to the x86 implementation. So I'd like > to change the naming to be more about the design and less about the > implementation.. How about pte_get_and_clear? > (It also doesn't make sense to me that you call the "clear the write bit" > thing "atomic_pte_wrprotect()", but you call the "clear the dirty bit" > "pte_test_and_clear_dirty()" - why not the same naming scheme for the two > things?). *nod* > I also have this suspicion that if this was done right, we should be able > to clean up the 64-bit atomic stuff for the x86 PAE case - which does a > cmpxchg8b right now on PAE entries exactly because of atomicity reasons. > > With your patch as it stands now, we'd end up basically always doing two > of them. > > And looking at the patch I get this nagging feeling that if this was > really done right, we could get rid of that PAE special case for > set_pte(), because the issue with atomic updates on PAE really boils down > to pretty much the same thing as the issue of one atomic bit. > (Instead of doing an atomic 64-bit memory write, we would be doing the > atomic "pte_xchg_clear()" followed by two _non_atomic 32-bit writes where > the second write would set the present bit. Although maybe the erratum > about the PAE pgd entry not honoring the P bit correctly makes this be > unworkable). As Ingo pointed out, this is only a problem for the pgd; we're safe so long as atomic operations are used on the present bit for pte's. I think we can completely eliminate the cmpxchg8b for ptes by using xchg on the low byte containing the P bit and non atomic ops on the high byte. This should be much better! ... > What do you say, Ben? Do you think your approach really would solve the > PAE atomicity issue too, or am I just expecting too much? These are good ideas. I'll go back and rework the patch for PAE stuff and see what kind of results turn out. -ben - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
