Re: 2.2 -> 2.4 transition questions
On Sat, 14 Oct 2000, Mike A. Harris wrote: > to know if after installing updated packages, if I'll still be > able to use a 2.2.x kernel ok, or if I'll have to resort to > initscript trickery: Some people get success with the old kernel and the new modutils, others find that it does not work. Most find that it does not work. Your best bet would be to create two sets of modutils binaries and have the init scripts pick the right one based on the kernel you are running that day. I think uninstalling and reinstalling RPMs to do this (especially on Debian ) is rather like changing your gas tank whenever you switch between premium and unleaded fuel, but I guess it works :} - 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/
iBCS with 2.4?
what's needed/where is iBCS for kernel 2.4? -d -- "There is a natural aristocracy among men. The grounds of this are virtue and talents", Thomas Jefferson [1742-1826], 3rd US President - 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 -> 2.4 transition questions
The 2.4.0test9 Changes file mentions the following and I'd like to know if after installing updated packages, if I'll still be able to use a 2.2.x kernel ok, or if I'll have to resort to initscript trickery: Will the following work with 2.2.17 as well? o util-linux 2.10o # kbdrate -v o modutils 2.3.15 # insmod -V o PPP2.4.0 # pppd --version I'm particularly concerned with the modutils 2.3.15. During the 2.0.x -> 2.2.x transition I was not able to use the same modutils with both kernels and had initscripts determine the kernel version, and uninstall the RPM and install the proper RPM for modutils. I've not tried to dual boot (2.2.x/2.4.x) a system yet, so any help would be appreciated. -- Mike A. Harris - Linux advocate - Open source advocate Computer Consultant - Capslock Consulting Copyright 2000 all rights reserved -- Be up to date on nerd news and stuff that matters: http://slashdot.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] Rewritten drivers/sbus/[audio,char]/Makefile
On Fri, 13 Oct 2000, Linus Torvalds wrote: > > > On Fri, 13 Oct 2000, David S. Miller wrote: > > > > Linus, why did you apply this? > > Because sparc is broken anyway, and this way those Makefiles _will_ get > fixed? David, Bart did the ground work and he did mine Makefile. Neither your or I have the time to dork with Makefiles, and Bart understands them. Be thankful, because the script rules of these puppies are worth a bottle of bayer(tm). 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: [PATCH] Rewritten drivers/sbus/[audio,char]/Makefile
On Fri, 13 Oct 2000, David S. Miller wrote: > > Linus, why did you apply this? Because sparc is broken anyway, and this way those Makefiles _will_ get fixed? 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 Fri, 13 Oct 2000, David S. Miller wrote: > > Linus, why did you apply his patch to _only_ reverse the if condition? > > What you applied will crash Sparc again, whereas mine does not crash > the original Sparc case _and_ it fixes Torben's bug too. Why woul dit crash the sparc? If it wasn't there originally, the loop will not find it, and the loop will be a no-op. Explain. 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/
Documentation glitch.
>From the file Documentation/SubmittingDrivers What Criteria Determine Acceptance -- Licensing: The code must be released to us under the GNU public license. We don't insist on any kind of exclusively GPL licensing, and if you wish the driver to be useful to other communities This should be worded correctly as "GNU General Public License" to avoid any confusion or ambiguity. There is no such thing as the "GNU public license" and newcomers may be confused. This is just a minor point, but valid nonetheless for proper documentation. -- Mike A. Harris - Linux advocate - Open source advocate Computer Consultant - Capslock Consulting Copyright 2000 all rights reserved -- #[Mike A. Harris bash tip #1 - separate history files per virtual console] # Put the following at the bottom of your ~/.bash_profile [ ! -d ~/.bash_histdir ] && mkdir ~/.bash_histdir tty |grep "^/dev/tty[0-9]" >& /dev/null && \ export HISTFILE=~/.bash_histdir/.$(tty | sed -e 's/.*\///') - 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/
RH 7.0, devfs + lk 2.4
I have been fighting with RH 7.0 trying to make it work with devfs and the lk 2.4 series. This is the second time round the loop as I did the same with RH 6.2 . The /etc/securetty file no longer needs to be changed but /etc/security/console.perms needs a different patch to allow non-root users to start X: --- /etc/security/console.perms_rh70Tue Aug 22 21:19:33 2000 +++ /etc/security/console.perms Fri Oct 13 20:08:58 2000 @@ -15,7 +15,7 @@ # man 5 console.perms # file classes -- these are regular expressions -=tty[0-9][0-9]* :[0-9]\.[0-9] :[0-9] +=tty[0-9][0-9]* vc/[0-9][0-9]* :[0-9]\.[0-9] :[0-9] =:[0-9]\.[0-9] :[0-9] # device classes -- these are shell-style globs Hopefully this patch does not compromise security. My page on devfs and scsi has been updated: http://www.torque.net/devfs_scsi.html Doug Gilbert - 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: Loopback mounting a file on an NFS partition hangs NFSclient
On Sat, 14 Oct 2000, Andi Kleen wrote: > That would be weird, because 2.2 does not support loopback creation on > NFS (and has an explicit check for it) Hmm, now that you jar my memory, I remember that I had actually loopback mounted an iso filesystem image on one machine and then NFS exported that filesystem to another. So this was the reverse of the situation of the recent crash :-) Sorry about the confusion. Cheers, Wayne - 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 ECN push
Alan Cox wrote: > > 'Technology Push' argument - and it shouldn't be that hard. Write some > > articles on how Linux is innovating, and how Cisco and others are standing > > in the way of progress. > > Cisco are already acting on this issue. No point clobbering them > > Alan AFAIK, Cisco has already completed their fixes for this and have new IOS builds available. -d -- "There is a natural aristocracy among men. The grounds of this are virtue and talents", Thomas Jefferson [1742-1826], 3rd US President - 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 ECN push
On Fri, Oct 13, 2000 at 08:56:51PM -0400, Mike A. Harris wrote: > On Sat, 14 Oct 2000, bert hubert wrote: [snip] > >Well, I think that we need to make some kind of PR push about ECN. Linux > >right now has enough clout and respect to be able to be used as a > >'Technology Push' argument - and it shouldn't be that hard. Write some > >articles on how Linux is innovating, and how Cisco and others are standing > >in the way of progress. > > I can see the /. headline right now: > > Cisco holds back Linux network innovation > from the peanut-butter-and-jelly-sandwich-dept [checks disk 2 of RedHat 7.0; Yep, recent 2.4test kernel] You've got it all wrong, RedHat /NET initiative attempts to create proprietary Internet! from the well-what-else-is-new dept - 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] Rewritten drivers/sbus/[audio,char]/Makefile
Linus, why did you apply this? It was totally untested and breaks both Sparc builds. I was going to work on fixing it and then submit it to you tonight. Please, people, submit Sparc patches to me when possible. This makes my life a lot simpler as I can sanity check all submissions. A lot of folks simply don't have sparcs with which to do even a compile check, and thats ok, just put the changes through me first and all those problems are solved. 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: [PATCH] Fix SCSI proc oops
Date: Fri, 13 Oct 2000 12:14:29 -0700 (PDT)
From: Linus Torvalds <[EMAIL PROTECTED]>
On Fri, 13 Oct 2000, Torben Mathiasen wrote:
>
> Yes it works, its not all that different from my patch ;).
Yeah.
The thing I actually cared most about was the comment, which makes the
patch palatable to me.
Linus, why did you apply his patch to _only_ reverse the if condition?
What you applied will crash Sparc again, whereas mine does not crash
the original Sparc case _and_ it fixes Torben's bug too.
Now, if that function is called for a TPNT for which no host adapters
were probed (happens if you compile a driver into the kernel which you
do not have in your machine) it will NULL dereference.
And you _wont_ notice the NULL derefence on ix86 during bootup! Only
other platforms will hit the OOPS due to this error.
Please, the following corrects test10-pre3.
--- ../vanilla/linux/drivers/scsi/scsi.cFri Oct 13 18:49:31 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,11 +2157,11 @@
(scsi_memory_upper_value - scsi_init_memory_start) / 1024);
#endif
- /*
-* Remove it from the linked list and /proc if all
-* hosts were successfully removed (ie preset == 0)
-*/
- 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 = _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/
Am I the only one with scsi-ide CDR problems?
I'm just wondering if I'm the only person who has had problems with 2.4.0-test9 recording on ide-scsi cdr's? Nobody has posted anything about it and the test10-prex changefiles don't mention it. cdrecord reports very weird results when scanning the scsi bus whereas dmesg shows what one would expect of the ide-scsi detection. anyone? - 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: init= parameter doesn't work
Is there anything besides /linux in the root? Sounds like init is dynamic and needs the linker and libc. Make sure init is static. robert * Paul Powell ([EMAIL PROTECTED]) [001013 17:18]: > Hello, > > I am attempting to move all of the root files and > folders into a single directory /linux on the root > file system. I then use the kernel parameter > init=/linux/sbin/init to get things rolling but the > kernel panics. > > When I boot linux, everything seems to work ok until > the kernel tries to execute init. The root device is > mounted as the root file system successfully and I see > a message stating so. But then I get a kernel panic > which says it couldn't find init and to try using the > init= kernel parameter. > > I'm guessing there is something missing from the root > directory that the kernel needs but isn't there. I > tried moving the /dev directory back to the root > directory on the root file system but this didn't help > things. > > Anyone have any clues? > > Thanks. > > P.S. The reason I'm doing this is because I'm > creating a bootable CD but have other things on the CD > in addition to linux. > > __ > Do You Yahoo!? > Get Yahoo! Mail - Free email you can access from anywhere! > http://mail.yahoo.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/ - 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: Loopback mounting a file on an NFS partition hangs NFS client
On Fri, Oct 13, 2000 at 06:36:31PM -0700, Wayne Whitney wrote: > Also, I should mention that several months ago, I was doing the exact same > thing on two different machines and similarly my process on the client > machine got stuck in a disk wait. I didn't look into the problem or > record any information, but I think the machines were running 2.2.x. That would be weird, because 2.2 does not support loopback creation on NFS (and has an explicit check for it) -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/
test10-pre3
- pre3: - update email address of Joerg Reuter - Andries Brouwer: spelling fixes, missing atari brelse(), breada() fix - Geert Uytterhoeven: used named initializers for "struct console". - Carsten Paeth: ISDN capifs - iput() only once. - Petr Vandrovec: VFAT short name generation fix - Jeff Garzik: i810_rng cleanup, and i815 chipset added. - Bartlomiej Zolnierkiewicz: clean up some remaining old-style Makefiles - Dave Jones: x86 setup fixes (recognize Pentium IV etc). - x86: do the "fast A20" setup too in setup.S - NIIBE Yutaka: update SuperH for the global page table (vmalloc) change. - David Miller: sparc updates (vmalloc stuff still pending) - David Miller: CodaFS warnings and 64-bit warnings in pci_size() - David Miller: pcnet32 - correct NULL test - David Miller: vmlist lock -> page_table_lock clarification - Trond Myklebust: Ouch. rpcauth_lookup_credcache() memory corruption bug - Matthew Wilcox: file locking cleanups - David Woodhouse: USB audio spinlock fixes - Torben Mathiasen: tlan driver cleanups - Randy Dunlap: Yenta: CACHE_LINE_SIZE is in dwords, not bytes. - Randy Dunlap: more USB updates - Kanoj Sarcar: clean up the NUMA interfaces (pg_data instead of nodes) - "save_fpu()" was broken. Need to clear pending errors: save_init_fpu(). - 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: A patch to loop.c for better cryption support
On Fri, Oct 13, 2000 at 10:15:21PM +, Marc Mutz wrote: > Andi Kleen wrote: > > > > On Fri, Oct 13, 2000 at 05:04:08PM +, Marc Mutz wrote: > > > Andi Kleen 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. > > > > > > > > > You're wrong. All kernels from int-2.2.10.4 onwards can be configured to > > > use relative block numbers as IV's. Both the FAQ in Documentation/crypto > > > and my HOWTO suggest to set CONFIG_BLK_DEV_LOOP_USE_REL_BLOCK to 'y'. > > > > That is not a standard kernel option. I'm not talking about any unofficial > > patchkits like the i* patches, just about what the standard loop device does. > > An encryption module can be backwards compatible itself by mapping the blocks > > itself, but without changes it will have an incompatible on disk format. > > > > This thread was about encryption. And it was about IV's. The only > encryption that vanilla loop.c (from 2.2.17) offers is 'none' and 'xor'. > None is just that: a no-op. And xor does not use an IV. So the only > ciphers that could possibly have been adressed by this patch are the > ones in the kerneli patch. So the on-disk format did _not_ change And any other filter modules which use the open loadable block converter interface in the loop device. That kerneli exists as a patch is IMHO just an historical accident, near all of it can be done fine without ever touching any linux source at all. Please take a small peek out of your small world ;) BTW, kerneli would also not handle the case of switching block sizes anyways, with relative IVs or not, because it does not restart its CFB chain inside the device blocks every 512 byte blocks with a new IV. When you switch from a bigger block size to a smaller you would need backwards peeking to earlier blocks (and know the block size anyways). Similar problem for going to bigger blocks. Ingo's change makes it a bit less painless, but still not trivial to handle. -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: [PATCH] Clean up x86 write-protect test
On Fri, 13 Oct 2000, Brian Gerst wrote: > > Also, Could somebody who has a machine with a known buggy processor give > this patch a try? I like the patch. Would you mind re-writing the exception handling the other way around, though: Instead of doing it like this: + __asm__ __volatile__( + " movb %0,%1 \n" + "1: movb %1,%0 \n" + " jmp 3f \n" + "2: incl %2 \n" + "3: \n" + ".section __ex_table,\"a\"\n" + " .align 4\n" + " .long 1b,2b \n" + ".previous \n" + :"=m" (*(char *) vaddr), +"=q" (tmp_reg), +"=r" (flag) + :"2" (flag) + :"memory"); it would be nicer to simply to the other way around (if exception happens, "flag" is untouched and jumped over, if not, flag is cleared): + __asm__ __volatile__( + " movb %0,%1 \n" + "1: movb %1,%0 \n" + " xor %2,%2 \n" + "2: \n" + ".section __ex_table,\"a\"\n" + " .align 4\n" + " .long 1b,2b \n" + ".previous \n" + :"=m" (*(char *) vaddr), +"=q" (tmp_reg), +"=r" (flag) + :"2" (1) + :"memory"); which basically means that if flag stays as "1", then the exception happened, but if the exception didn't happen the code will fall through the "xor" and clear "flag". After that, and testing that it works on a broken machine, I'd love to apply it. 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: [RFC] atomic pte updates and pae changes, take 2
On Fri, 13 Oct 2000, Ben LaHaise wrote: > > Hey folks Me likee. This looks much nicer. The hack turned into something that looks quite ddesigned. Ingo, I'd like you to comment on all the PAE issues just in case, but I personally don't have any real issues any more. Small nit: I dislike the "__HAVE_ARCH_xxx" approach, and considering that most architectures will probably want to do something specific anyway I wonder if we should get rid of that and just make architectures have their own code. Thanks, 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/
PROBLEM: Loopback mounting a file on an NFS partition hangs NFSclient
Hi all, [ My apologies if this is a duplicate; I tried sending this a week ago, but I didn't see my message in the mailing list archives, so I assume that it did not go through for some reason . . . ] This is my first time posting a possible kernel bug, so I hope I get everything right; I am following the format suggested in REPORTING-BUGS. I hadn't "planned" on a kernel bug, so I did not save all of the kernel state immediately, but I think I correctly reconstructed my modules stack. Also, I don't subscribe to the list, so please cc: me on replies at [EMAIL PROTECTED] Thanks. Cheers, Wayne [1.] Loopback mounting a file on an NFS partition hangs NFS client. [2.] I have two machines, mf1 and mf2. mf1 NFS exports to mf2 a partition containing foo.iso, an ISO9660 file system in a file. On mf2, I mount it with 'mount -o loop foo.iso'. Everything works fine at first, but after a bunch of I/O (circa 100MB), a process accessing this file system triggers a "kernel bug" message and gets stuck in a "D" status on ps. An attempt to unmount foo.iso generates another "kernel bug" messages and fails but does return. This problem is repeatable. [3.] NFS client, loopback, disk wait [4.] cat /proc/version Linux version 2.4.0-test9 ([EMAIL PROTECTED]) (gcc version 2.96 2731 (Red Hat Linux 7.0)) #3 SMP Thu Oct 5 13:04:40 PDT 2000 [5.] ksymoops -m /boot/System.map messages ksymoops 2.3.4 on i686 2.4.0-test9. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.0-test9/ (default) -m /boot/System.map (specified) Oct 5 15:55:30 mf2 kernel: invalid operand: Oct 5 15:55:30 mf2 kernel: CPU:0 Oct 5 15:55:30 mf2 kernel: EIP:0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 Oct 5 15:55:30 mf2 kernel: EFLAGS: 00010282 Oct 5 15:55:30 mf2 kernel: eax: 003f ebx: f7aa62c0 ecx: d6cc4000 edx: 0021 Oct 5 15:55:30 mf2 kernel: esi: f7dc0640 edi: f72f7120 ebp: d6cc4000 esp: d6cc5c94 Oct 5 15:55:30 mf2 kernel: ds: 0018 es: 0018 ss: 0018 Oct 5 15:55:30 mf2 kernel: Process rpm (pid: 2776, stackpage=d6cc5000) Oct 5 15:55:30 mf2 kernel: Stack: f88e05cb f88e0800 00a4 f30ef640 f3166860 f760bea0 c160da90 f30ef640 Oct 5 15:55:30 mf2 kernel: f88d2875 f760bea0 c160da90 1000 fff4 0004 Oct 5 15:55:30 mf2 kernel:c160da90 c160da90 f30ef640 c160da90 f30ef640 f760bea0 f88d3059 Oct 5 15:55:30 mf2 kernel: Call Trace: [] [] [] [] [do_generic_file_read+766/1344] [do_anonymous_page+58/288] [] Oct 5 15:55:30 mf2 kernel:[] [] [] [__make_request+1493/1536] [__find_get_page+68/288] [tcp_delack_timer+0/432] [timer_bh+595/688] [filemap_nopage+157/1088] Oct 5 15:55:30 mf2 kernel: Code: 0f 0b 83 c4 0c 89 5f 1c c7 47 3c 01 00 00 00 f0 ff 06 f0 ff >>EIP; f88d3867 <[nfs]nfs_create_request+197/1c0> <= Trace; f88e05cb <[nfs].rodata.start+130b/4426> Trace; f88e0800 <[nfs].rodata.start+1540/4426> Trace; f88d2875 <[nfs]nfs_readpage_async+115/190> Trace; f88d3059 <[nfs]nfs_readpage+79/c0> Trace; f890c3b0 <_EIP>: Code; f88d3867 <[nfs]nfs_create_request+197/1c0> <= 0: 0f 0b ud2a <= Code; f88d3869 <[nfs]nfs_create_request+199/1c0> 2: 83 c4 0c add$0xc,%esp Code; f88d386c <[nfs]nfs_create_request+19c/1c0> 5: 89 5f 1c mov%ebx,0x1c(%edi) Code; f88d386f <[nfs]nfs_create_request+19f/1c0> 8: c7 47 3c 01 00 00 00 movl $0x1,0x3c(%edi) Code; f88d3876 <[nfs]nfs_create_request+1a6/1c0> f: f0 ff 06 lock incl (%esi) Code; f88d3879 <[nfs]nfs_create_request+1a9/1c0> 12: f0 ff 00 lock incl (%eax) Oct 5 15:57:06 mf2 kernel: invalid operand: Oct 5 15:57:06 mf2 kernel: CPU:0 Oct 5 15:57:06 mf2 kernel: EIP:0010:[] Oct 5 15:57:06 mf2 kernel: EFLAGS: 00010282 Oct 5 15:57:06 mf2 kernel: eax: 003f ebx: f7aa62c0 ecx: 0002 edx: 0021 Oct 5 15:57:06 mf2 kernel: esi: c211fa20 edi: f30ef7c0 ebp: f31668e0 esp: d62c1f48 Oct 5 15:57:06 mf2 kernel: ds: 0018 es: 0018 ss: 0018 Oct 5 15:57:06 mf2 kernel: Process umount (pid: 2832, stackpage=d62c1000) Oct 5 15:57:06 mf2 kernel: Stack: f88df2eb f88df4e0 00a4 f760bf00 f7a3e5e0 c01363e7 f30ef7c0 f760bf00 Oct 5 15:57:06 mf2 kernel:f7a78800 0700 f31668e0 ffe7 f890cd48 f75b8cc0 4c01 Oct 5 15:57:06 mf2 kernel:c013d996 f7a78800 0700 4c01 c0144d47 f30c8c60 f75b8cc0 Oct 5 15:57:06 mf2 kernel: Call Trace: [] [] [fput+55/224] [] [blkdev_ioctl+38/64] [sys_ioctl+455/528] [system_call+51/56] Oct 5 15:57:06 mf2 kernel: Code: 0f 0b 83 c4 0c 85 db 74 09 53 56 e8 f4 50 fe ff 5b 5e bb 00 >>EIP; f88d159c <[nfs]nfs_release+5c/b0> <= Trace; f88df2eb <[nfs].rodata.start+2b/4426> Trace; f88df4e0 <[nfs].rodata.start+220/4426> Code; f88d159c <[nfs]nfs_release+5c/b0>
Re: Russell King forks ARM Linux.
I posted the following message here some weeks ago. I formally apologize to George France, and to the list for my message, and formally retract it. The quotation in my message was my own, personal interpretation; George France did not say those words. I certainly never intended to misrepresent George France, and I sincerely apologize to George France for any misunderstandings I may have caused. sincerely, Mark Hahn. -- operator may differ from spokesperson. [EMAIL PROTECTED] http://brain.mcmaster.ca/~hahn -- Forwarded message -- Date: Wed, 27 Sep 2000 18:24:36 -0400 (EDT) From: Mark Hahn <[EMAIL PROTECTED]> To: Linux Kernel <[EMAIL PROTECTED]> Subject: Re: Russell King forks ARM Linux. In-Reply-To: <[EMAIL PROTECTED]> > him, but he has cut off all commutations. So starting tomorrow, we will be > submitting patches directly to the kernel mailing list, since Russell will uh, this will be unpleasantly familiar to anyone who was reading the linux-usb mailing list in Dec 99, when George said, roughly "you are all so full of shit that you're not worth working with, so on Monday we will begin designing our own USB for Linux". Linux USB has survived quite nicely in spite of this, which bodes quite well for ARM-linux ;) - 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] For 2.4: syscall revoke.
On Fri, 13 Oct 2000, Alan Cox wrote:
> > writer might be OK, but AFAICS there is nothing of that sort in the
> > tree. We have such spinlocks, but I don't see how to apply that idea to
> > semaphores. Besides, it ought to be small - every struct file will have to
> > contain such beast.
>
> It would mean a check when putting a file handle, which would be unpleasant
> if not handled very carefully.
I.e. you would have to unlock before doing fput(). Happens all by itself
if we hold the lock only across the actual method call. I'm not saying
that it's a good way, but correctenss problems are not going to be all
that terrible.
> How about doing this in fput ?
>
> if(IS_REVOKED(file) && file->f_ops != _ops)
> {
> file->f_ops = _ops;
> wake_up(_wait);
> }
>
> that would mean that the ops change is done by the code paths that care about
> the handle at the point it becomes unused. We could use a poll_table like
> setup to handle the multi-fd wait if need be
?
fput() has zero serialization wrt methods. The only case when resetting
->f_op in fput() is safe is when ->f_count hits zero. Precisely because
there's no references left. But at that point you don't need to bother at
all.
-
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/
Tux2 Patent Issues
Daniel/Linux, Brian Rayve from Malinkrodt & Malinkrodt has been assigned the Tux 2 Patent analysis and will have a preliminary infringment analysis sometime next week that will be posted to this list when it is available. He has obtained the NetApp patents and is reviewing them and preparing the analysis. A detailed analysis of all related patents outside the NetApp patents requires a formal request for patent search with the USPTO and will take 4-6 weeks to complete. If the NetApp patents do not infringe, then we will perform the exhaustive search of the USPTO prior to giving Daniel a green light. Any parties who have any patent issues or prior art with Tux2 may send email to [EMAIL PROTECTED] (801-328-1624) to assist with this issue. New Linux patent issues other than Tux2 should be sent thru me so I can arrange for the funding for the patent research. 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: big ECN push
> 'Technology Push' argument - and it shouldn't be that hard. Write some > articles on how Linux is innovating, and how Cisco and others are standing > in the way of progress. Cisco are already acting on this issue. No point clobbering them Alan - 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 ECN push
On Sat, 14 Oct 2000, bert hubert wrote: >> > In other words, being able to just turn on ECN for localhost and your >> > internal network isn't likely to be terribly useful. >> >> Being able to turn ECN on/off for specific routes would be very >> useful. Currently we have to turn ECN off for systems connected to >> the Internet because there are bad routers out there. But I know > >Well, I think that we need to make some kind of PR push about ECN. Linux >right now has enough clout and respect to be able to be used as a >'Technology Push' argument - and it shouldn't be that hard. Write some >articles on how Linux is innovating, and how Cisco and others are standing >in the way of progress. I can see the /. headline right now: Cisco holds back Linux network innovation from the peanut-butter-and-jelly-sandwich-dept ;o) -- Mike A. Harris - Linux advocate - Open source advocate Computer Consultant - Capslock Consulting Copyright 2000 all rights reserved -- Looking for Linux software? http://freshmeat.net http://www.rpmfind.net http://filewatcher.org http://www.coldstorage.org http://sourceforge.net - 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 current() from interrupt context
"Jeff V. Merkey" wrote:
>
> "David S. Miller" wrote:
> >
> >Date:Tue, 10 Oct 2000 00:44:58 +0200
> >From: "Andi Kleen" <[EMAIL PROTECTED]>
> >
> >On Mon, Oct 09, 2000 at 11:41:13PM +0100, Alan Cox wrote:
> >> I dont actually know a CPU that doesnt have one in SMP mode. Its just often
> >> behind an I/O interface that is slower than ideal
> >
> >Where would you put it for IA32 ? I don't know any free MSR that could
> >be abused for that, and acessing MSRs is insanely slow anyways. Any
> >other ideas ?
> >
> > The local APIC holds the hardware cpu number (which happens to equal
> > the logical cpu number in the current x86 code). And I believe the
> > local APIC has a 32-bit scratch register or 2 as well... but don't
> > quote me on that one.
>
> Accessing the CPUID from the local APIC is slower than mollasses. The
> reason for this is due to the fact that the APIC address ranges are
> treated as non-cacheable memory, and will always generate a
> non-cacheable memory reference when you read from the APIC_ID register
> and shift the ID.
You can verify this with a logic analyzer and watch the system suck wind
and get really slow, I/O performance go to shit after you read the
memory mapped APIC registers from a context
switch loop, i.e.
while (1)
{
read_local_apic(); // OINK OINK OINK -- bus utilitization will go
through the roof.
schedule()
}
and watch it oink...
>
> A simpler solution is to use the CR2 register to store the CPU number,
> and always reload the register after a page fault (since CR2 will hold a
> faulting address). THis is even better than Linus' stack based method
> for storing the number since you just are reading a register, which is
> fast as hell. The other methods are slower.
>
> hHis is how it's done in NetWare and MANOS. It works
>
> :-)
>
> Jeff
>
> >
> > 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/
-
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 current() from interrupt context
"Jeff V. Merkey" wrote:
>
> "Jeff V. Merkey" wrote:
> >
> > "David S. Miller" wrote:
> > >
> > >Date:Tue, 10 Oct 2000 00:44:58 +0200
> > >From: "Andi Kleen" <[EMAIL PROTECTED]>
> > >
> > >On Mon, Oct 09, 2000 at 11:41:13PM +0100, Alan Cox wrote:
> > >> I dont actually know a CPU that doesnt have one in SMP mode. Its just often
> > >> behind an I/O interface that is slower than ideal
> > >
> > >Where would you put it for IA32 ? I don't know any free MSR that could
> > >be abused for that, and acessing MSRs is insanely slow anyways. Any
> > >other ideas ?
> > >
> > > The local APIC holds the hardware cpu number (which happens to equal
> > > the logical cpu number in the current x86 code). And I believe the
> > > local APIC has a 32-bit scratch register or 2 as well... but don't
> > > quote me on that one.
> >
> > Accessing the CPUID from the local APIC is slower than mollasses. The
> > reason for this is due to the fact that the APIC address ranges are
> > treated as non-cacheable memory, and will always generate a
> > non-cacheable memory reference when you read from the APIC_ID register
> > and shift the ID.
>
> You can verify this with a logic analyzer and watch the system suck wind
> and get really slow, I/O performance go to shit after you read the
> memory mapped APIC registers from a context
> switch loop, i.e.
>
> while (1)
> {
>read_local_apic(); // OINK OINK OINK -- bus utilitization will go
> through the roof.
>schedule()
> }
>
> and watch it oink...
>
> >
> > A simpler solution is to use the CR2 register to store the CPU number,
> > and always reload the register after a page fault (since CR2 will hold a
> > faulting address). THis is even better than Linus' stack based method
> > for storing the number since you just are reading a register, which is
> > fast as hell. The other methods are slower.
> >
> > hHis is how it's done in NetWare and MANOS. It works
> >
> > :-)
> >
> > Jeff
> >
> > >
> > > 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/
-
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 current() from interrupt context
"David S. Miller" wrote: > >Date:Tue, 10 Oct 2000 00:44:58 +0200 >From: "Andi Kleen" <[EMAIL PROTECTED]> > >On Mon, Oct 09, 2000 at 11:41:13PM +0100, Alan Cox wrote: >> I dont actually know a CPU that doesnt have one in SMP mode. Its just often >> behind an I/O interface that is slower than ideal > >Where would you put it for IA32 ? I don't know any free MSR that could >be abused for that, and acessing MSRs is insanely slow anyways. Any >other ideas ? > > The local APIC holds the hardware cpu number (which happens to equal > the logical cpu number in the current x86 code). And I believe the > local APIC has a 32-bit scratch register or 2 as well... but don't > quote me on that one. Accessing the CPUID from the local APIC is slower than mollasses. The reason for this is due to the fact that the APIC address ranges are treated as non-cacheable memory, and will always generate a non-cacheable memory reference when you read from the APIC_ID register and shift the ID. A simpler solution is to use the CR2 register to store the CPU number, and always reload the register after a page fault (since CR2 will hold a faulting address). THis is even better than Linus' stack based method for storing the number since you just are reading a register, which is fast as hell. The other methods are slower. hHis is how it's done in NetWare and MANOS. It works :-) Jeff > > 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/ - 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-pre2
Date:Fri, 13 Oct 2000 20:49:08 -0400 From: Wakko Warner <[EMAIL PROTECTED]> Doesn't boot on alpha systems with pci-pci bridges. I sent a report about this a couple days ago and noone responds. Richard Henderson knows about this bug and it requires quite a bit of painful surgery. I believe his wording that more interesting work would be cleaning his cat's litter boxes. 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] Clean up x86 write-protect test
This patch makes the write-protect test use the normal exception
handling mechanism. This removes the need for the special case check in
the page fault handler. The only concern I have is because of this
comment:
/*
* Beware: Black magic here. The printk is needed here to flush
* CPU state on certain buggy processors.
*/
Does anyone have an explanation as to why this printk is necessary? I
can't figure out why this case would need the printk but no other page
fault exception would.
Also, Could somebody who has a machine with a known buggy processor give
this patch a try?
--
Brian Gerst
diff -urN linux-2.4.0t10p2/Documentation/exception.txt
linux/Documentation/exception.txt
--- linux-2.4.0t10p2/Documentation/exception.txtFri Jul 28 01:28:07 2000
+++ linux/Documentation/exception.txt Fri Oct 13 20:13:52 2000
@@ -284,3 +284,9 @@
successful, -EFAULT on failure. Our original code did not test this
return value, however the inline assembly code in get_user tries to
return -EFAULT. GCC selected EAX to return this value.
+
+NOTE:
+Due to the way that the exception table is built and needs to be ordered,
+only use exceptions for code in the .text section. Any other section
+will cause the exception table to not be sorted correctly, and the
+exceptions will fail.
diff -urN linux-2.4.0t10p2/arch/i386/mm/fault.c linux/arch/i386/mm/fault.c
--- linux-2.4.0t10p2/arch/i386/mm/fault.c Thu Oct 12 19:48:23 2000
+++ linux/arch/i386/mm/fault.c Fri Oct 13 20:13:52 2000
@@ -77,31 +77,6 @@
return 0;
}
-static void __init handle_wp_test (void)
-{
- const unsigned long vaddr = PAGE_OFFSET;
- pgd_t *pgd;
- pmd_t *pmd;
- pte_t *pte;
-
- /*
-* make it read/writable temporarily, so that the fault
-* can be handled.
-*/
- pgd = swapper_pg_dir + __pgd_offset(vaddr);
- pmd = pmd_offset(pgd, vaddr);
- pte = pte_offset(pmd, vaddr);
- *pte = mk_pte_phys(0, PAGE_KERNEL);
- __flush_tlb_all();
-
- boot_cpu_data.wp_works_ok = 1;
- /*
-* Beware: Black magic here. The printk is needed here to flush
-* CPU state on certain buggy processors.
-*/
- printk("Ok");
-}
-
asmlinkage void do_invalid_op(struct pt_regs *, unsigned long);
extern unsigned long idt;
@@ -274,14 +249,7 @@
/*
* Oops. The kernel tried to access some bad page. We'll have to
* terminate things with extreme prejudice.
- *
- * First we check if it was the bootup rw-test, though..
*/
- if (boot_cpu_data.wp_works_ok < 0 &&
- address == PAGE_OFFSET && (error_code & 1)) {
- handle_wp_test();
- return;
- }
if (address < PAGE_SIZE)
printk(KERN_ALERT "Unable to handle kernel NULL pointer dereference");
diff -urN linux-2.4.0t10p2/arch/i386/mm/init.c linux/arch/i386/mm/init.c
--- linux-2.4.0t10p2/arch/i386/mm/init.cThu Aug 10 08:10:02 2000
+++ linux/arch/i386/mm/init.c Fri Oct 13 20:15:42 2000
@@ -491,16 +491,43 @@
* before and after the test are here to work-around some nasty CPU bugs.
*/
+/*
+ * This function cannot be __init, since exceptions don't work in that
+ * section.
+ */
+static int do_test_wp_bit(unsigned long vaddr)
+{
+ char tmp_reg;
+ int flag = 0;
+
+ __asm__ __volatile__(
+ " movb %0,%1 \n"
+ "1: movb %1,%0 \n"
+ " jmp 3f \n"
+ "2: incl %2 \n"
+ "3: \n"
+ ".section __ex_table,\"a\"\n"
+ " .align 4\n"
+ " .long 1b,2b \n"
+ ".previous \n"
+ :"=m" (*(char *) vaddr),
+"=q" (tmp_reg),
+"=r" (flag)
+ :"2" (flag)
+ :"memory");
+
+ return flag;
+}
+
void __init test_wp_bit(void)
{
/*
- * Ok, all PAE-capable CPUs are definitely handling the WP bit right.
+ * Ok, all PSE-capable CPUs are definitely handling the WP bit right.
*/
const unsigned long vaddr = PAGE_OFFSET;
pgd_t *pgd;
pmd_t *pmd;
pte_t *pte, old_pte;
- char tmp_reg;
printk("Checking if this processor honours the WP bit even in supervisor
mode... ");
@@ -511,27 +538,19 @@
*pte = mk_pte_phys(0, PAGE_READONLY);
local_flush_tlb();
- __asm__ __volatile__(
- "jmp 1f; 1:\n"
- "movb %0,%1\n"
- "movb %1,%0\n"
- "jmp 1f; 1:\n"
- :"=m" (*(char *) vaddr),
-"=q" (tmp_reg)
- :/* no inputs */
- :"memory");
+ boot_cpu_data.wp_works_ok = do_test_wp_bit(vaddr);
*pte = old_pte;
local_flush_tlb();
- if (boot_cpu_data.wp_works_ok < 0) {
-
Re: test10-pre2
Doesn't boot on alpha systems with pci-pci bridges. I sent a report about this a couple days ago and noone responds. > 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.. - 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 Report 2.4.0-test9: NMI Watchdoch detected LOCKUP at CPU[01]
Hello, Here is the bug report When doing "modprobe imm" I get message LOCKUP detected the trace looks like this: 0: ?? (assume spin_lock_irqsave in blk_get_queue but printed EIP seems to be sensless - area with no code according to the map file) 1: ll_rw_blk.c: 874 generic_make_request -> "after line q = blk_get_queue(...)" 2: ll_rw_blk.c: 925 ll_rw_block 3: filemap.c: 280 writeout_one_page 4: filemap.c: 324 do_buffer_fdatasync 5: filemap.c: 344 generic_buffer_fdatasync 6: filemap.c: 270 ? writeout_one_page ? 7: ext2/fsync.c: 140 ext2_sync_file 8: fs/buffer.c: 370 sys_fsync The iomega-drive is usally available after the lockup-message, thou one time i had to hard-reboot the machine (not even SysRq was working. Please CC me, if you have some comments, ideas, and thanks for your time. Gert additional information: Linux 2.4.0-test9-my #22 SMP Sam Okt 7 15:28:18 CEST 2000 i686 unknown Kernel modules 2.3.14 Gnu C pgcc-2.95.2 Gnu Make 3.77 Binutils 2.9.1.0.25 Linux C Library2.1.1 Dynamic linker ldd (GNU libc) 2.1.1 Procps 2.0.2 Mount 2.9w Net-tools 1.52 Console-tools 0.2.0 Sh-utils 2.0 Modules Loaded parport_pc imm sd_mod nfsd lockd sunrpc 8139too nls_cp437 vfat fat awe_wave sb sb_lib uart401 sound soundcore advansys scsi_mod /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 5 model name : Pentium II (Deschutes) stepping: 2 cpu MHz : 451.29 cache size : 512 KB fdiv_bug: no hlt_bug : no sep_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr bogomips: 897.84 processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 5 model name : Pentium II (Deschutes) stepping: 2 cpu MHz : 451.29 cache size : 512 KB fdiv_bug: no hlt_bug : no sep_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr bogomips: 901.12 /proc/pci PCI devices found: Bus 0, device 0, function 0: Host bridge: Intel Corporation 440BX/ZX - 82443BX/ZX Host bridge (rev 3). Master Capable. Latency=64. Prefetchable 32 bit memory at 0xe400 [0xe7ff]. Bus 0, device 1, function 0: PCI bridge: Intel Corporation 440BX/ZX - 82443BX/ZX AGP bridge (rev 3). Master Capable. Latency=64. Min Gnt=136. Bus 0, device 4, function 0: ISA bridge: Intel Corporation 82371AB PIIX4 ISA (rev 2). Bus 0, device 4, function 1: IDE interface: Intel Corporation 82371AB PIIX4 IDE (rev 1). Master Capable. Latency=32. I/O at 0xd800 [0xd80f]. Bus 0, device 4, function 2: USB Controller: Intel Corporation 82371AB PIIX4 USB (rev 1). Master Capable. Latency=32. I/O at 0xd400 [0xd41f]. Bus 0, device 4, function 3: Bridge: Intel Corporation 82371AB PIIX4 ACPI (rev 2). Bus 0, device 9, function 0: SCSI storage controller: Advanced System Products, Inc ABP940-U / ABP960-U (rev 3). IRQ 9. Master Capable. Latency=32. Min Gnt=4.Max Lat=4. I/O at 0xd000 [0xd0ff]. Non-prefetchable 32 bit memory at 0xde80 [0xde8000ff]. Bus 0, device 10, function 0: Multimedia video controller: Brooktree Corporation Bt878 (rev 2). IRQ 10. Master Capable. Latency=32. Min Gnt=16.Max Lat=40. Prefetchable 32 bit memory at 0xe100 [0xe1000fff]. Bus 0, device 10, function 1: Multimedia controller: Brooktree Corporation Bt878 (rev 2). IRQ 10. Master Capable. Latency=32. Min Gnt=4.Max Lat=255. Prefetchable 32 bit memory at 0xe080 [0xe0800fff]. Bus 0, device 12, function 0: Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139 (rev 16). IRQ 11. Master Capable. Latency=32. Min Gnt=32.Max Lat=64. I/O at 0xb800 [0xb8ff]. Non-prefetchable 32 bit memory at 0xde00 [0xdeff]. Bus 1, device 0, function 0: VGA compatible controller: Matrox Graphics, Inc. MGA G400 AGP (rev 5). IRQ 11. Master Capable. Latency=64. Min Gnt=16.Max Lat=32. Prefetchable 32 bit memory at 0xe200 [0xe3ff]. Non-prefetchable 32 bit memory at 0xdf80 [0xdf803fff]. Non-prefetchable 32 bit memory at 0xdf00 [0xdf7f]. /proc/scsi/scsi Attached devices: Host: scsi0 Channel: 00 Id: 01 Lun: 00 Vendor: PLEXTOR Model:
Re: Updated Linux 2.4 Status/TODO List (from the ALS show)
Date:Fri, 13 Oct 2000 15:57:50 -0700 From: Richard Henderson <[EMAIL PROTECTED]> Either that or adjust how we do atomic operations. I can do 64-bit atomic widgetry, but not with the code as written. Ultra can do it as well, and as far as I understand it ia64 64-bit atomic_t's shouldn't be a problem either. I would suggest we make a atomic64_t or similar different type. The space savings from using 32-bit normal atomic_t in all other situations is of real value. 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/
[RFC] atomic pte updates and pae changes, take 2
Hey folks
Below is take two of the patch making pte_clear use atomic xchg in an
effort to avoid the loss of dirty bits. PAE no longer uses cmpxchg8 for
updates; set_pte is two ordered long writes with a barrier. The use of
long long for ptes is also removed; gcc should generate better code now. A
quick test with filemap_rw shows no measurable difference between pae and
non pae code, as well as no degradation from the original non-atomic
non-pae code. This code has been tested on a box with 4GB (about 48MB is
above the 4G boundry) in PAE mode, and in non PAE mode on a couple of
other boxes too. Linus: comments? Ingo: could you have a look over the
code? Thanks,
-ben
diff -ur v2.4.0-test10-pre2/arch/i386/boot/install.sh
work-10-2/arch/i386/boot/install.sh
--- v2.4.0-test10-pre2/arch/i386/boot/install.shTue Jan 3 06:57:26 1995
+++ work-10-2/arch/i386/boot/install.sh Fri Oct 13 17:19:47 2000
@@ -21,6 +21,7 @@
# User may have a custom install script
+if [ -x ~/bin/installkernel ]; then exec ~/bin/installkernel "$@"; fi
if [ -x /sbin/installkernel ]; then exec /sbin/installkernel "$@"; fi
# Default install - same as make zlilo
diff -ur v2.4.0-test10-pre2/include/asm-i386/page.h work-10-2/include/asm-i386/page.h
--- v2.4.0-test10-pre2/include/asm-i386/page.h Thu Oct 12 17:42:11 2000
+++ work-10-2/include/asm-i386/page.h Fri Oct 13 17:36:02 2000
@@ -37,20 +37,20 @@
* These are used to make use of C type-checking..
*/
#if CONFIG_X86_PAE
-typedef struct { unsigned long long pte; } pte_t;
+typedef struct { unsigned long pte_low, pte_high; } pte_t;
typedef struct { unsigned long long pmd; } pmd_t;
typedef struct { unsigned long long pgd; } pgd_t;
-#define PTE_MASK (~(unsigned long long) (PAGE_SIZE-1))
+#define pte_val(x) ((x).pte_low | ((unsigned long long)(x).pte_high << 32))
#else
-typedef struct { unsigned long pte; } pte_t;
+typedef struct { unsigned long pte_low; } pte_t;
typedef struct { unsigned long pmd; } pmd_t;
typedef struct { unsigned long pgd; } pgd_t;
-#define PTE_MASK PAGE_MASK
+#define pte_val(x) ((x).pte_low)
#endif
+#define PTE_MASK PAGE_MASK
typedef struct { unsigned long pgprot; } pgprot_t;
-#define pte_val(x) ((x).pte)
#define pmd_val(x) ((x).pmd)
#define pgd_val(x) ((x).pgd)
#define pgprot_val(x) ((x).pgprot)
diff -ur v2.4.0-test10-pre2/include/asm-i386/pgtable-2level.h
work-10-2/include/asm-i386/pgtable-2level.h
--- v2.4.0-test10-pre2/include/asm-i386/pgtable-2level.hFri Dec 3 14:12:23
1999
+++ work-10-2/include/asm-i386/pgtable-2level.h Fri Oct 13 17:41:14 2000
@@ -18,7 +18,7 @@
#define PTRS_PER_PTE 1024
#define pte_ERROR(e) \
- printk("%s:%d: bad pte %08lx.\n", __FILE__, __LINE__, pte_val(e))
+ printk("%s:%d: bad pte %08lx.\n", __FILE__, __LINE__, (e).pte_low)
#define pmd_ERROR(e) \
printk("%s:%d: bad pmd %08lx.\n", __FILE__, __LINE__, pmd_val(e))
#define pgd_ERROR(e) \
@@ -54,5 +54,12 @@
{
return (pmd_t *) dir;
}
+
+#define __HAVE_ARCH_pte_get_and_clear
+#define pte_get_and_clear(xp) __pte(xchg(&(xp)->pte_low, 0))
+#define pte_same(a, b) ((a).pte_low == (b).pte_low)
+#define pte_page(x)(mem_map+((unsigned long)(((x).pte_low >>
+PAGE_SHIFT
+#define pte_none(x)(!(x).pte_low)
+#define __mk_pte(page_nr,pgprot) __pte(((page_nr) << PAGE_SHIFT) | pgprot_val(pgprot))
#endif /* _I386_PGTABLE_2LEVEL_H */
diff -ur v2.4.0-test10-pre2/include/asm-i386/pgtable-3level.h
work-10-2/include/asm-i386/pgtable-3level.h
--- v2.4.0-test10-pre2/include/asm-i386/pgtable-3level.hMon Dec 6 19:19:13
1999
+++ work-10-2/include/asm-i386/pgtable-3level.h Fri Oct 13 17:39:53 2000
@@ -27,7 +27,7 @@
#define PTRS_PER_PTE 512
#define pte_ERROR(e) \
- printk("%s:%d: bad pte %p(%016Lx).\n", __FILE__, __LINE__, &(e), pte_val(e))
+ printk("%s:%d: bad pte %p(%08lx%08lx).\n", __FILE__, __LINE__, &(e),
+(e).pte_high, (e).pte_low)
#define pmd_ERROR(e) \
printk("%s:%d: bad pmd %p(%016Lx).\n", __FILE__, __LINE__, &(e), pmd_val(e))
#define pgd_ERROR(e) \
@@ -45,8 +45,12 @@
extern inline int pgd_bad(pgd_t pgd) { return 0; }
extern inline int pgd_present(pgd_t pgd) { return !pgd_none(pgd); }
-#define set_pte(pteptr,pteval) \
- set_64bit((unsigned long long *)(pteptr),pte_val(pteval))
+extern inline void set_pte(pte_t *ptep, pte_t pte)
+{
+ ptep->pte_high = pte.pte_high;
+ barrier();
+ ptep->pte_low = pte.pte_low;
+}
#define set_pmd(pmdptr,pmdval) \
set_64bit((unsigned long long *)(pmdptr),pmd_val(pmdval))
#define set_pgd(pgdptr,pgdval) \
@@ -75,5 +79,35 @@
/* Find an entry in the second-level page table.. */
#define pmd_offset(dir, address) ((pmd_t *) pgd_page(*(dir)) + \
__pmd_offset(address))
+
+#define __HAVE_ARCH_pte_get_and_clear
+extern inline pte_t pte_get_and_clear(pte_t *ptep)
+{
+ pte_t res;
+
+
init= parameter doesn't work
Hello, I am attempting to move all of the root files and folders into a single directory /linux on the root file system. I then use the kernel parameter init=/linux/sbin/init to get things rolling but the kernel panics. When I boot linux, everything seems to work ok until the kernel tries to execute init. The root device is mounted as the root file system successfully and I see a message stating so. But then I get a kernel panic which says it couldn't find init and to try using the init= kernel parameter. I'm guessing there is something missing from the root directory that the kernel needs but isn't there. I tried moving the /dev directory back to the root directory on the root file system but this didn't help things. Anyone have any clues? Thanks. P.S. The reason I'm doing this is because I'm creating a bootable CD but have other things on the CD in addition to linux. __ Do You Yahoo!? Get Yahoo! Mail - Free email you can access from anywhere! http://mail.yahoo.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/
big ECN push
On Fri, Oct 13, 2000 at 01:43:09PM +0100, Mike Jagdis wrote: > > In other words, being able to just turn on ECN for localhost and your > > internal network isn't likely to be terribly useful. > > Being able to turn ECN on/off for specific routes would be very > useful. Currently we have to turn ECN off for systems connected to > the Internet because there are bad routers out there. But I know Well, I think that we need to make some kind of PR push about ECN. Linux right now has enough clout and respect to be able to be used as a 'Technology Push' argument - and it shouldn't be that hard. Write some articles on how Linux is innovating, and how Cisco and others are standing in the way of progress. Regards, bert hubert -- PowerDNS Versatile DNS Services Trilab The Technology People 'SYN! .. SYN|ACK! .. ACK!' - the mating call of the internet - 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 -- new addition WAS(test9 PCI resourcecollisions (fwd)
On Fri, 13 Oct 2000, jamal wrote: > > This is in addition to the debug statements from the previous email > Weirder results (like bus 0x0a) Ok, thanks - this part didn't get anything new, the bus numbers are just different due to the re-allocation, the actual bus windows are the same broken ones. I wonder why they are so broken. And why did 2.2 work? 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 2.4 TODO List - more on PCI resources...]
> > I agree. I would expect it to be 8 instead of 32. > > Actually I just checked on a new Thinkpad T20 with a TI > > PCI 1450 CardBus controller *on a different OS* > > and it is 8. > > I'll fix it to be 8. > > Thanks, > > Linus Well, preferably to what David said: L1_CACHE_BYTES / 4 Thanks, ~Randy - 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 - more on PCI resources...]
On Fri, 13 Oct 2000, Dunlap, Randy wrote: > > I agree. I would expect it to be 8 instead of 32. > Actually I just checked on a new Thinkpad T20 with a TI > PCI 1450 CardBus controller *on a different OS* > and it is 8. I'll fix it to be 8. Thanks, 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 2.4 TODO List -- new addition WAS(test9 PCI resourcecollisions (fwd)
On Fri, 13 Oct 2000, jamal wrote:
>
> On Fri, 13 Oct 2000, Linus Torvalds wrote:>
> > Can you add the same extra debug code that I asked Dag Bakke to add for
> > his problem:
>
> Attached.
Thanks.
It looks like the bridge that your docking devices are behind (I assume
that's just a regular docking bridge) has not been set up correctly, and
has a serious lack of bridging windows, which causes the inability for
Linux to map any of the devices behind that bus. So you get printouts like
bus res 0 0 -
bus res 1 0 -
bus res 2 1200 e400-e5ff
device Matrox Graphics, Inc. MGA 2164W [Millennium II] resource 1 size 4000
PCI: Failed to allocate resource 1 for Matrox Graphics, Inc. MGA 2164W
[Millennium II]
The above means that of the three bus windows set up for the PCI-PCI
bridge for the docking, two are disabled, and the last one is a
prefetchable memory window which is unacceptable to most devices (the
Matrox want a non-prefetchable window for its command area).
The other cases all show the same.
Martin, what's up? It looks like PCI-PCI bridge windows are not enabled
and set up at all. At least on this particular machine.
And I don't find any code that would ever have done this, either. It must
be somewhere, if 2.2 works for you.
Ehh. How about yet another debugging patch, to see what the bridge bases
are? In drivers/pci/pci.c, function pci_read_bridge_bases(), find the
place where it reads the PCI_IO_BASE/LIMIT and the UPPER bits, and add
printk("IO base: %04x%04x limit: %04x%04x\n",
io_base_hi, io_base_lo,
io_limit_hi, io_limit_lo);
to before the sanity test for the resource[0] case (ie before the stuff
that says "if (base && base <= limit) {" etc).
And do the same for the mem_base stuff for the resource[1] and resource[2]
cases.
Martin, any ideas on why only the prefetchable memory case would show up?
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 2.4 TODO List - more on PCI resources...]
> On Fri, Oct 13, 2000 at 02:22:32PM -0700, Dunlap, Randy wrote: > > I'm not familiar with yenta controllers/devices, > > and I'm not trying to throw you a tasty red herring, > > but... > > > > yenta_config_init() does > > config_writeb(socket, PCI_CACHE_LINE_SIZE, 32); > > > > Is this writing to the CardBus bridge or to the device's > > CacheLineSize register? > > It is writing to the bridge. I think it should probably actually be > L1_CACHE_BYTES/4. I am not sure about the impact of an incorrect > setting. Maybe Linus knows. > > -- Dave I agree. I would expect it to be 8 instead of 32. Actually I just checked on a new Thinkpad T20 with a TI PCI 1450 CardBus controller *on a different OS* and it is 8. ~Randy - 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.18pre15aa1 and reiserfs and cvs glibc opendir broke
I have a program:
#include
#include
#include
int
main() {
DIR *dir = opendir("/uss/zzq/TIDs");
printf("dir = %08lx\n",(int)dir);
}
which fails to work correctly under the development version of libc.
brian@remo brian>gcc foo.c(redhat 6.2 libc)
brian@remo brian>./a.out
dir = 08049760
brian@remo brian>xgcc foo.c (recent cvs libc)
brian@remo brian>./a.out
dir =
the machines remo runs 2.2.18pre15aa1 and the filesystem is
reiserfs 3.5.26. The same thing happens if the filesystem is ext2.
gcc and xgcc invoke the same compiler:
egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)
And here is the actual failure in the bowels of libc:
(gdb) s
__libc_fcntl (fd=6, cmd=2) at ../sysdeps/unix/sysv/linux/i386/fcntl.c:44
44arg = va_arg (ap, void *);
(gdb) n
51if (! __have_no_fcntl64)
(gdb) n
53int result = INLINE_SYSCALL (fcntl64, 3, fd, cmd, arg);
(gdb) n
54if (result >= 0 || errno != ENOSYS)
(gdb) print result
$9 = -1
What has gone wrong?
Thanks,
--
Brian Litzinger <[EMAIL PROTECTED]>
Copyright (c) 2000 By Brian Litzinger, All Rights Reserved
- End forwarded 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: Updated 2.4 TODO List -- new addition WAS(test9 PCI resourcecollisions (fwd)
On Fri, 13 Oct 2000, Linus Torvalds wrote: > Oh, also, can you try to see what happens if you change the define for > > #define pcibios_assign_all_busses() 0 > > to a 1 in include/asm-i386/pci.h? That should force Linux to re-configure > all buses, regardless of whether they have been set up some way by the > BIOS. Which might make a difference. > > But please do this separately from the extra debug code - I'd like to see > what the debug code says regardless of this change.. This is in addition to the debug statements from the previous email Weirder results (like bus 0x0a) cheers, jamal Linux version 2.4.0-test10 (root@PCARD38C) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #6 Fri Oct 13 18:06:10 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.478 MHz processor. Console: colour VGA+ 80x25 Calibrating delay loop... 992.87 BogoMIPS Memory: 255768k/262080k available (1095k 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 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 behind PCI bridge 00:01.0, config 010100, pass 1 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 1 Scanning behind PCI bridge 00:03.1, config 00, pass 1 Scanning behind PCI bridge 00:11.0, config 020200, pass 1 Scanning bus 0a Found 0a:08 [102b/051b] 000300 00 Found 0a:28 [1095/0646] 000101 00 PCI: IDE base address fixup for 0a:05.0 Found 0a:38 [9004/6078] 000100 00 Found 0a:40 [10b7/9050] 000200 00 Fixups for bus 0a PCI: Scanning for ghost devices on bus 10 Bus scan for 0a returning with max=0a 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 ece0-ecff (f=101, d=0, p=0) PCI: Resource e780-e7ff (f=1208, d=0, p=0) PCI: Resource fda0-fdaf (f=200, d=0, p=0) PCI: Resource e500-e5ff (f=1208, d=0, p=0) PCI: Resource fbffc000-fbff (f=200, d=0, p=0) PCI: Cannot allocate resource region 1 of device 0a:01.0 PCI: Resource fb00-fb7f (f=200, d=0, p=0) PCI: Cannot allocate resource region 2 of device 0a:01.0 PCI: Resource fcf8-fcff (f=109, d=0, p=0) PCI: Cannot allocate resource region 0 of device 0a:05.0 PCI: Resource fcf0-fcf3 (f=101, d=0, p=0) PCI: Cannot allocate resource region 1 of device 0a:05.0 PCI: Resource fce0-fce7 (f=101, d=0, p=0) PCI: Cannot allocate resource region 2 of device
Re: Updated Linux 2.4 Status/TODO List (from the ALS show)
On Fri, Oct 13, 2000 at 11:47:55PM +0100, Alan Cox wrote: > Then we need to use locking to protect the rss since on a big 64bit box > we can exceed 2^32 pages in theory and probably soon in practice. Either that or adjust how we do atomic operations. I can do 64-bit atomic widgetry, but not with the code as written. r~ - 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 -- new addition WAS(test9 PCI resourcecollisions (fwd)
On Fri, 13 Oct 2000, Linus Torvalds wrote:
> Can you add the same extra debug code that I asked Dag Bakke to add for
> his problem:
>
> -- snip from another email, because I'm lazy ---
>
> Please add a debug printk() to drivers/pci/setup-res.c to the very end of
> pci_assign_bus_resource(), just before the "return -EBUSY", something like
>
> printk("device %s resource %d size %08lx\n", dev->name, resno, size);
>
> just to see what it wants and why it fails..
>
> Also, it's probably worth printing out what the actual bus resources are,
> to possibly explain the failure. So add another line that says
>
> printk("bus res %d %x %08lx-%08lx\n", i, r->flags, r->start,
> r->end);
>
Attached.
cheers,
jamal
Linux version 2.4.0-test10 (root@PCARD38C) (gcc version egcs-2.91.66 19990314/Linux
(egcs-1.1.2 release)) #5 Fri Oct 13 18:02: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.471 MHz processor.
Console: colour VGA+ 80x25
Calibrating delay loop... 992.87 BogoMIPS
Memory: 255768k/262080k available (1095k 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 ece0-ecff (f=101, d=0, p=0)
PCI: Resource e780-e7ff (f=1208, d=0, p=0)
PCI: Resource fda0-fdaf (f=200, d=0, p=0)
PCI: Resource e500-e5ff (f=1208, d=0, p=0)
PCI: Resource fbffc000-fbff (f=200, d=0, p=0)
PCI: Cannot allocate resource region 1 of device 02:01.0
PCI: Resource fb00-fb7f (f=200, d=0, p=0)
PCI: Cannot allocate resource region 2 of device 02:01.0
PCI: Resource fcf8-fcff (f=109, d=0, p=0)
PCI: Cannot allocate resource region 0 of device 02:05.0
PCI: Resource fcf0-fcf3 (f=101, d=0, p=0)
PCI: Cannot allocate resource
Re: Updated Linux 2.4 Status/TODO List (from the ALS show)
On Fri, Oct 13, 2000 at 02:25:45PM -0700, Linus Torvalds wrote: > And even on alpha, a 32-bit atomic_t means we cover 45 bits of virtual > address space, which, btw, is more than you can cram into the current > three-level page tables, I think. While that's true of Alpha, it's not true of Ultra III, in which all 64-bits are in theory available to the user. Dave hasn't implemented that yet, AFAIK. r~ - 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: cannot connect to linuxtoday.com 80 with test9-pre9
> If this is done, I recommend we immediately mark it as deprecated and likely > to go away soon. It's better to get people to upgrade their IOS than to > force kludges. If they have an old IOS, this is probably one of several > issues that need fixing. I have no hope of Linuxtoday fixing this. Their site is also remarkably inaccessible if you are on a path with a <1500 byte MTU hop in the middle, that problem is about 4 years old. There are plenty of other news sites ;) - 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
Harald Welte <[EMAIL PROTECTED]> writes: > On Thu, Oct 12, 2000 at 11:59:51PM +0200, J . A . Magallon wrote: > > Hi, everybody. > > > > 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 > > there is no such thing as gcc-2.96. Try reading > > http://gcc.gnu.org/gcc-2.96.html we know. however, redhat's gcc patching does have that name. hence while it may not be "official" over at the gcc steering commitee, gcc-2.96 does, in practice and fact, exist. everyone knows what redhat gcc-2.96 means. don't be silly. -- J o h a n K u l l s t a m [[EMAIL PROTECTED]] Don't Fear the Penguin! - 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 Fri, Oct 13, 2000 at 12:45:47PM +0100, Alan Cox wrote: > > Can we always be sure the rss will fit in an atomic_t - is it > 32bits on the > > ultrsparc/alpha ? > > It is not. Then we need to use locking to protect the rss since on a big 64bit box we can exceed 2^32 pages in theory and probably soon in practice. - 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 - more on PCI resources...]
I have tested Linus' patch and it makes a difference: cs: cb_alloc(bus 6): vendor 0x115d, device 0x0003 Found 06:00 [115d/0003] 000200 00 bus res 0 1200 1c00-1fff bus res 1 200 2000-23ff bus res 2 100 1800-18ff bus res 0 1200 1c00-1fff bus res 1 200 2000-23ff bus res 0 1200 1c00-1fff bus res 1 200 2000-23ff bus res 0 1200 1c00-1fff PCI: Error while updating region 06:00.0/6 (1c01 != 1801) PCI: Enabling device 06:00.0 ( -> 0003) Found 06:01 [115d/0103] 000300 00 bus res 0 1200 1c00-1fff bus res 1 200 2000-23ff bus res 2 100 1800-18ff bus res 0 1200 1c00-1fff bus res 1 200 2000-23ff bus res 0 1200 1c00-1fff bus res 1 200 2000-23ff bus res 0 1200 1c00-1fff PCI: Error while updating region 06:00.1/6 (1c004001 != 18004001) PCI: Enabling device 06:00.1 ( -> 0003) VFS: Mounted root (ext2 filesystem) readonly. Freeing unused kernel memory: 192k freed Warning: unable to open an initial console. cs: IO port probe 0x0c00-0x0cff: clean. cs: IO port probe 0x0800-0x08ff: clean. cs: IO port probe 0x0100-0x04ff: excluding 0x170-0x177 0x370-0x37f 0x4d0-0x4d7 cs: IO port probe 0x0a00-0x0aff: clean. eth0: first available media type: MII tulip_attach(06:00.0) PCI: Enabling bus mastering for device 06:00.0 PCI: Setting latency timer of device 06:00.0 to 64 xircom_tulip_cb.c:v0.91 4/14/99 [EMAIL PROTECTED] (modified by [EMAIL PROTECTED] for XIRCOM CBE, fixed by Doug Ledford) eth1: Xircom Cardbus Adapter (DEC 21143 compatible mode) rev 3 at 0x1800, 00:00:00:00:00:00, IRQ 11. lspci: 06:00.0 Ethernet controller: Xircom Cardbus Ethernet 10/100 (rev 03) Subsystem: Xircom Cardbus Ethernet 10/100 Flags: bus master, medium devsel, latency 64, IRQ 11 I/O ports at 1800 [size=128] Memory at 2000 (32-bit, non-prefetchable) [size=2K] Memory at 2800 (32-bit, non-prefetchable) [size=2K] Expansion ROM at 1c00 [size=16K] Capabilities: [dc] Power Management version 1 06:00.1 VGA compatible controller: Xircom Cardbus Ethernet + 56k Modem (rev 03) (prog-if 02) Subsystem: Xircom CBEM56G-100 Ethernet + 56k Modem Flags: medium devsel, IRQ 11 I/O ports at 1880 [size=8] Memory at 20001000 (32-bit, non-prefetchable) [size=2K] Memory at 20001800 (32-bit, non-prefetchable) [size=2K] Expansion ROM at 1c004000 [size=16K] Capabilities: [dc] Power Management version 1 It still doesn't work. It looks very much like a stuck bit, but at least we get a slightly "better" error message and the expansion ROM now gets enabled. progress! Linus wants to "debug this to death" (his words, not mine) but I don't have access to the suspect hardware for the next five weeks, and it will probably be serviced some time during those weeks. Thank you for being patient, Linus. And sorry for not being able to provide more debug data. Dag B - 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
Andi Kleen wrote: > > On Fri, Oct 13, 2000 at 05:04:08PM +, Marc Mutz wrote: > > Andi Kleen 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. > > > > > > You're wrong. All kernels from int-2.2.10.4 onwards can be configured to > > use relative block numbers as IV's. Both the FAQ in Documentation/crypto > > and my HOWTO suggest to set CONFIG_BLK_DEV_LOOP_USE_REL_BLOCK to 'y'. > > That is not a standard kernel option. I'm not talking about any unofficial > patchkits like the i* patches, just about what the standard loop device does. > An encryption module can be backwards compatible itself by mapping the blocks > itself, but without changes it will have an incompatible on disk format. > This thread was about encryption. And it was about IV's. The only encryption that vanilla loop.c (from 2.2.17) offers is 'none' and 'xor'. None is just that: a no-op. And xor does not use an IV. So the only ciphers that could possibly have been adressed by this patch are the ones in the kerneli patch. So the on-disk format did _not_ change between recent int-2.2.x.y kernels and 2.4-testx, provided the user followed the recommendations and used the previously mentioned option to use relative block numbers as IV's. Marc -- Marc Mutz <[EMAIL PROTECTED]> http://EncryptionHOWTO.sourceforge.net/ University of Bielefeld, Dep. of Mathematics / Dep. of Physics PGP-keyID's: 0xd46ce9ab (RSA), 0x7ae55b9e (DSS/DH) - 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
kernel wrote: > > > Caution is advised when depending upon crypto systems that use relative > block numbers as IV. The security may not be a strong as hoped. > There are some who believe that "not unique" IVs (across multiple > filesystems) facilitates some methods of cryptanalysis. > Do you have a paper reference? I know that there are issues when using sequence numbers as IVs for CBC, but that is an isolated problem for CBC-like modes. > Strong security is the reason absolute block numbers were chosen at > the time I introduced loop.c cipher-block-chaining support (in > kernel 2.1.130). This has the unfortunate side effect of preventing > filesystem relocation... leading some to claim that loop.c is now > broken. A crypto system is only as strong as its weakest link. > Perhaps we should make Counter mode available for loop_gen.c. It does not have the artifacts that CBC has when seqence numbers are used as IVs. On the contrary: sequential IVs are an integral part of CTR mode encryption. This mode is not only just as secure as CBC, but has also the added bonus of only requiring encryption, something the AES would benfit from immensely, since decryption is so much slower for Rijndael than encryption and reads (decryption) are typically used more often in a filesystem than writes (encryption). > Perhaps losetup can allow the user to specify a "IVseed" value > and then pass to the transfer modules IVseed + relative block. > This would also allow existing absolute block based encrypted file > systems to be relocated (IVseed = absolute # of 1st block), Hm, I don't get you here. If I was to use absolute block numbers as IVs on a 1k block size ext2 filesystem, I could theoretically end up with the following mapping of loop device blocks vs. ext2 blocks Q> loop:0 1 2 3 4 5 Q> ext2:12 13 14 22 23 24 If I used IVseed = 12 here, the first three blocks would decrypt correctly, yet the forth would decrypt to white noise. > satisfy > those among us who demand unique IVs, and allow those who prefer > operational convenience at the cost of weaker security to do so. > As CTR mode _requires_ unique IVs (CBC does not), the upper half of the IV could be initialized from the key, whose length would thus grow by 50%. The lower half would contain the relative block number in units of 512 bytes. > Reed H. Petty > [EMAIL PROTECTED] Marc -- Marc Mutz <[EMAIL PROTECTED]> http://EncryptionHOWTO.sourceforge.net/ University of Bielefeld, Dep. of Mathematics / Dep. of Physics PGP-keyID's: 0xd46ce9ab (RSA), 0x7ae55b9e (DSS/DH) - 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.4.0-test6 network socket problems
> I've found the problem. This type of loop does not work:
>
> do {
> alarm(t);
> read(fd);
> if (EINT)
>exception();
> else
>alarm(0);
> } while (data);
>
> There are some semantics here that differ from other *nix where this
> works. The read() won't come out when the alarm comes, and the socket
> will effectively become broken.
The restart or continue behaviour is undefined unless you use sigaction()
to control your signal behaviour (see POSIX.1 or SuS). Even then your code
is buggy on every OS I know
Suppose this happens..
alarm(1)
[sudden swap frenzy]
alarm is delivered.. do nothing
read
blocks forever. You need to make clever use of siglongjmp to avoid that one
occurring or use select/poll.
-
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] For 2.4: syscall revoke.
> writer might be OK, but AFAICS there is nothing of that sort in the
> tree. We have such spinlocks, but I don't see how to apply that idea to
> semaphores. Besides, it ought to be small - every struct file will have to
> contain such beast.
It would mean a check when putting a file handle, which would be unpleasant
if not handled very carefully.
How about doing this in fput ?
if(IS_REVOKED(file) && file->f_ops != _ops)
{
file->f_ops = _ops;
wake_up(_wait);
}
that would mean that the ops change is done by the code paths that care about
the handle at the point it becomes unused. We could use a poll_table like
setup to handle the multi-fd wait if need be
How we make sure drivers return out of wait for event loops would need a bit
of thought but I think thats an unrelated problem.
-
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/
UMSDOS Problem with test10-pre2
Apologies in advance if this is a known problem. I've been away from kernel hacking for about three years and just re-subscribed to lkml a couple of weeks ago, so I may have missed something about this. But I haven't been able to find anything in the documentation or on lkml about it. If it's in a FAQ or an archive somewhere, don't waste bandwidth on the explanation; just point me to the appropriate document and I'll RTFM. I can't get the most recent kernels to boot on an IBM ThinkPad 600X using umsdos as the root fs. *(An explanation and/or justification for using umsdos appears at the end of this message.)* The latest version that works for me is 2.3.51. Starting with 2.3.99-pre1 it tries to mount root as msdos rather than umsdos. Here's the relevant output from a successful 2.3.51 boot. Linux version 2.3.51 (root@beowulf) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #3 Fri Oct 6 13:45:58 CDT 2000 On node 0 totalpages: 16639 zone(0): 4096 pages. zone(1): 12543 pages. zone(2): 0 pages. Initializing CPU#0 Detected 448451051 Hz processor. Console: colour VGA+ 80x25 Calibrating delay loop... 447.28 BogoMIPS Memory: 63220k/66556k available (1075k kernel code, 2948k reserved, 81k data, 164k init, 0k highmem) Buffer-cache hash table entries: 4096 (order: 2, 16384 bytes) Page-cache hash table entries: 32768 (order: 5, 131072 bytes) CPU: Intel Pentium III (Coppermine) stepping 01 Checking 386/387 coupling... OK, FPU using exception 16 error reporting. Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX PCI: PCI BIOS revision 2.10 entry at 0xfd880 PCI: Using configuration type 1 PCI: Probing PCI hardware PCI: Interrupt Routing Table found at 0xc00f9d70 [router type /] Limiting direct PCI/PCI transfers. Linux NET4.0 for Linux 2.3 Based upon Swansea University Computer Society NET3.039 NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP IP: routing cache hash table of 512 buckets, 4Kbytes TCP: Hash tables configured (established 4096 bind 4096) Starting kswapd v1.6 pty: 256 Unix98 ptys configured Uniform Multi-Platform E-IDE driver Revision: 6.30 ide: Assuming 40MHz system bus speed for PIO modes; override with idebus=xx PIIX4: IDE controller on PCI bus 00 dev 39 PIIX4: not 100% native mode: will probe irqs later ide0: BM-DMA at 0xfcf0-0xfcf7, BIOS settings: hda:DMA, hdb:pio ide1: BM-DMA at 0xfcf8-0xfcff, BIOS settings: hdc:DMA, hdd:pio hd0: C/H/S=0/0/3 from BIOS ignored hda: IBM-DARA-206000, ATA DISK drive hdc: CRN-8241B, ATAPI CDROM drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 ide1 at 0x170-0x177,0x376 on irq 15 hda: IBM-DARA-206000, 5729MB w/418kB Cache, CHS=12416/15/63, UDMA(33) Partition check: hda: [PTBL] [776/240/63] hda1 hda2 Linux PCMCIA Card Services 3.1.11 options: [pci] [cardbus] [pm] Adding cardbus controller 0: Texas Instruments PCI1221 Yenta IRQ list 06f8, PCI irq11 Socket status: 3010 Adding cardbus controller 1: Texas Instruments PCI1221 (#2) Yenta IRQ list 06f8, PCI irq11 Socket status: 3006 Intel PCIC probe: not found. 3c574_cs.c v1.08 9/24/98 Donald Becker/David Hinds, [EMAIL PROTECTED] At this point with 2.3.51 I get these lines: UMSDOS 0.86 (compatibility level 0.4, fast msdos) check_pseudo_root: mounted as root check_pseudo_root: found //linux check_pseudo_root: found sbin/init, enabling pseudo-root UMSDOS: changed to alternate root VFS: Mounted root (umsdos filesystem) readonly. Freeing unused kernel memory: 164k freed and the system finishes booting normally. But with later kernels, instead of these last few lines I get this: VFS: Mounted root (msdos filesystem) readonly. Freeing unused kernel memory: 164k freed Warning: unable to open an initial console. Kernel panic: No init found. Try passing init= option to kernel. and the system hangs. No mention at all of umsdos or pseudo_root. Notice that it says it mounted root as msdos, not umsdos, so it makes sense that it can't find init (or anything else) on that file system. I've tried this with every combination of versions and configuration options I can think of: the default config, a config customized for exactly my hardware, a config with everything stripped out except the minimum necessary to boot, configs with everything possible compiled as modules, configs with no modules at all... I should mention here that all these ideas work fine on my desktop system, which uses ext2 for the root fs. But among other hardware differences, the desktop machine is a homebuilt Pentium MMX system, while the ThinkPad is a Pentium III. So I'm not certain it's the umsdos part that's the problem. Both systems have recent installs of Slackware 7.1 with egcs-1.1.2, and I've upgraded binutils, modutils, etc. so that the versions are equal to or later than what's in the latest Documentation/Changes file. It doesn't matter whether I boot using loadlin or from a diskette using lilo; the results are the same. (In both cases I use "root=/dev/hda2 rw" to specify where
Re: Updated Linux 2.4 Status/TODO List (from the ALS show)
On Fri, Oct 13, 2000 at 02:44:32AM +0200, FORT David wrote: > > 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 Does this same problem happen when using the uhci.o driver? 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: 2.4.0-test9-pre8, usb, unresolved symbols
On Fri, Oct 13, 2000 at 01:52:12PM -0400, Claude LeFrancois (LMC) wrote: > Hello, > > I had the same problem with the USB core driver compiled statically into > the kernel 2.4.0-test10pre1. If I get the whole USB distribution > compiled as a modules, everything works fine. Here is the content of my > /proc/ksyms related to USB with the USB core driver compiled into the > kernel. The __VERSIONED_SYMBOL seem strange to me. I think this is why > the symbols are unresolved. Is it a compiler problem ? Can you send me your .config file that generates this? And also can you do a 'sh scripts/ver_linux' from your 2.4.0-test10-pre1 directory? 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: cannot connect to linuxtoday.com 80 with test9-pre9
If this is done, I recommend we immediately mark it as deprecated and likely to go away soon. It's better to get people to upgrade their IOS than to force kludges. If they have an old IOS, this is probably one of several issues that need fixing. -d Mike Jagdis wrote: > > Right you are, both of you. I guess was confusing 'route' with > > 'interface' and didn't think of using multiple routes like that. It > > would be a kludge but whatever gets the job done.. > > No more than some of the other route attributes like window, rtt, > mtu, ssthresh etc. -- "There is a natural aristocracy among men. The grounds of this are virtue and talents", Thomas Jefferson [1742-1826], 3rd US President - 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:45:47 +0100 (BST) From: Alan Cox <[EMAIL PROTECTED]> > It might make more sense to just make rss an atomic_t. Can we always be sure the rss will fit in an atomic_t - is it > 32bits on the ultrsparc/alpha ? Yes, this issue occurred to me last night as well. It is 32-bit on Alpha/UltraSparc. However, given the fact that this number measures "pages", the PAGE_SIZE on Ultra/Alpha, and the size of the 64-bit user address space on Ultra and Alpha, it would actually end up working. This doesn't make it a good idea though. 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 2.4 TODO List - more on PCI resources...]
On Fri, Oct 13, 2000 at 02:22:32PM -0700, Dunlap, Randy wrote: > I'm not familiar with yenta controllers/devices, > and I'm not trying to throw you a tasty red herring, > but... > > yenta_config_init() does > config_writeb(socket, PCI_CACHE_LINE_SIZE, 32); > > Is this writing to the CardBus bridge or to the device's > CacheLineSize register? It is writing to the bridge. I think it should probably actually be L1_CACHE_BYTES/4. I am not sure about the impact of an incorrect setting. Maybe Linus knows. -- Dave - 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: Nice oops from agpgart - 2.2 kernels and Alpha
Michal Jaegermann wrote: > > On UP1100 Alpha with an AGP slot and "Advanced Micro Devices [AMD] > AMD-751 [Irongate] System Controller" an attempt to use 'agpgart' > support ends up with an oops. I tried 2.2.17 and 2.2.18pre15 kernels. > With CONFIG_AGP=y and CONFIG_AGP_AMD=y resulting kernel gets stuck > after oops and does not boot. If CONFIG_AGP=m is used then an attempt > to insert 'agpgart' module ends up with the following oops (after > a run through 'ksymoops'): > > ksymoops 2.3.4 on alpha 2.2.18pre15x. Options used > -V (default) > -k /proc/ksyms (default) > -l /proc/modules (default) > -o /lib/modules/2.2.18pre15x/ (default) > -m /boot/System.map-2.2.18pre15x (specified) > > Unable to handle kernel paging request at virtual address 6204 > insmod(1048): Oops 1 > pc = [] ra = [] ps = > Using defaults from ksymoops -t elf64-alpha -a alpha > v0 = t0 = 6200 t1 = 6200 > t2 = 0c322000 t3 = fc802000 t4 = fe85 > t5 = fe85 t6 = fffe t7 = fc000c2a > s0 = fe844e50 s1 = fe844f50 s2 = fe844cb0 > s3 = 0001 s4 = 0001 s5 = fe844e50 > s6 = fe840090 a0 = fd01fe14 a1 = 00b0 > a2 = 0080 a3 = fc569310 a4 = fc000c2a3d60 > a5 = fc000c2a3d58 t8 = 0001 t9 = fc523078 > t10= t11= fc523070 pv = fc31d640 > 47f01412 or zero,128,a2 > 4441f102 andnot t1,15,t1 > 44420401 or t1,t1,t0 > b05e0020 stl t1,32(sp) > 4821f621 zapnot t0,15,t0 > b42a stq t0,0(s1) > a6090028 ldq a0,40(s0) > Trace: 332014 33bc18 310cf8 42fe80 > Warning (Oops_read): Code line not seen, dumping what data is available > > >>PC; fe841ba8 <[agpgart]amd_irongate_configure+68/140> <= > Trace; 00332014 Before first symbol > Trace; 0033bc18 Before first symbol > Trace; 00310cf8 Before first symbol > Trace; 0042fe80 Before first symbol > > 1 warning issued. Results may not be reliable. > > followed by a "Segmentation fault" from insmod. Unfortunately option > -m produces an empty symbol map for the module; also later the module > is not removable with the following output from lsmod: > > agpgart21312 1 (initializing) > > This bomb happens on this code > > /* Write out the address of the gatt table */ > OUTREG32(amd_irongate_private.registers, AMD_ATTBASE, > agp_bridge.gatt_bus_addr); > > from amd_irongate_configure() in drivers/char/agp/agpgart_be.c. > I dropped few printk's there like that: > > /* Get the memory mapped registers */ > pci_read_config_dword(agp_bridge.dev, AMD_MMBASE, ); > printk(KERN_INFO PFX "Read irongate temp %x\n", temp); > temp = (temp & PCI_BASE_ADDRESS_MEM_MASK); > printk(KERN_INFO PFX "Masked temp to %x\n", temp); > amd_irongate_private.registers = (volatile u8 *) ioremap(temp, 4096); > printk(KERN_INFO PFX "Updated private registers to %x\n", >amd_irongate_private.registers); > > and results are as follows: > > Linux agpgart interface v0.99 (c) Jeff Hartmann > agpgart: Maximum main memory to use for agp memory: 204M > agpgart: Detected AMD Irongate chipset > agpgart: Read irongate temp 6208 > agpgart: Masked temp to 6200 > agpgart: Updated private registers to 6200 > Unable to handle kernel paging request at virtual address 6204 > > Any ideas what is wrong with this picture? I have not tried this on an alpha before, and I wouldn't be surprised that its broken. Someone attempted to get agpgart going on the alpha awhile ago, but I don't think they ever followed through. I think I might be able to get access to an alpha w/ the Irongate, I'll see what I can do. I do know there will be a few issues (64-bit issues, cache flushing issues, etc.), so I can't promise that it will be fast. Btw, does the Alpha have something resembling i386 UCWC'ed memory? If so could someone point me at some docs? > > BTW - despite the following commment in drivers/char/drm/drm.h > "Dec 1999, Richard Henderson <[EMAIL PROTECTED]>, move to generic cmpxchg." > an attempt to compile 'drm' module includes some x86 specific code > from drivers/char/drm/drmP.h, like this: > > __asm__ __volatile__(LOCK_PREFIX "cmpxchgb %b1,%2" > : "=a"(prev) > : "q"(new), "m"(*__xg(ptr)), "0"(old) > : "memory"); > > and, as you can guess, does not compile on Alpha. But that is the > next problem after 'agpgart'. :-) > > Michal > [EMAIL PROTECTED] > [EMAIL PROTECTED] I believe this is fixed in the latest 2.4.0-test. However I believe that the only driver that has been tested on the alpha is the 3Dfx driver. The other drivers are
Re: Kernel 2.2.18 and GCC versions
On Fri, 13 Oct 2000 13:38:19 Chmouel Boudjnah wrote:
> "J . A . Magallon" <[EMAIL PROTECTED]> writes:
>
> > I have a little problem when compiling new kernels. I run Mandrake 7.1
> > with many many updates (its almost 7.2beta).
>
> install the last egcs package from 7.2b and compile with kgcc (will be
> autodetect by the kernel).
>
Please, correct me if I miss anything. I got egcs-cpp-1.1.2-33mdk and
egcs-1.1.2-33mdk from rpmfind.net. After rpm -U, do:
werewolf:~/soft/dev# ls /usr/lib/gcc-lib/i586-mandrake-linux/egcs-2.91.66
SYSCALLS.c.X collect2* crtbegin.o crtend.o include/ libgcc.map
cc1* cpp* crtbeginS.o crtendS.o libgcc.a specs
Write a silly thing like "int main() {}" in kk.c and egcs breaks out
of the box:
werewolf:~> kgcc kk.c -o kk
gcc: installation problem, cannot exec `cpp0': No such file or directory
Solved by ln -s cpp cpp0. But when you try to compile kernel, the same
problem is found with a missing 'tradcpp0', that also appears if you try:
werewolf:~> kgcc -traditional kk.c -o kk
gcc: installation problem, cannot exec `tradcpp0': No such file or
directory
I tried the same trick with 'ln -s', but then 'make bzImage' stops at:
trampoline.S:47: unterminated character constant
So something is missing in rpms, or is mis-packaged in any other part of
egcs
I didn't install, such as g++ or so.
--
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: test10-pre2
On Fri, Oct 13, 2000 at 02:23:44PM -0700, Linus Torvalds wrote: > ... but on a 3-level page table (whether with PAE on x86 or on alpha), > you could easily just decide to limit the vmalloc() area to a a gigabyte > or two and handle it with just one PGD entry.. I'm undecided. For normal usage, certainly there's no issue there. But I was thinking about TUX-like kernel applications running on big memory machines -- you'd now only be able to use 8G of the 32G you purchased because of lack of vmalloc space. Perhaps it's just not worth worrying about. r~ - 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 Fri, 13 Oct 2000, Jakub Jelinek wrote: > On Fri, Oct 13, 2000 at 02:17:23PM -0700, Richard Henderson wrote: > > On Fri, Oct 13, 2000 at 12:45:47PM +0100, Alan Cox wrote: > > > Can we always be sure the rss will fit in an atomic_t - is it > 32bits on the > > > ultrsparc/alpha ? > > > > It is not. > > It is not even 32bit on sparc32 (24bit only). But remember that "rss" counts in pages, so it's plenty for sparc32: only 32 bits of virtual address that can count towards the rss. And even on alpha, a 32-bit atomic_t means we cover 45 bits of virtual address space, which, btw, is more than you can cram into the current three-level page tables, I think. 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: test10-pre2
On Fri, 13 Oct 2000, Richard Henderson wrote: > On Fri, Oct 13, 2000 at 12:22:35PM -0700, Linus Torvalds wrote: > > The PGD is 1024 entries, and the last one is used by the self-mapping > > stuff. But the VMALLOC area is NOT there ... > > Ok, I was slightly confused. Yes, the vptb is at 0xfffe > not 0xfe00. The bit I was remembering is the SRM callback > console setup, which _does_ exist in the same PGD as vmalloc. But > that, of course, would only be true if you were running SRM. > > Thanks for the patch, Ivan. Note that it would be nicer to _not_ do the page fault case anyway, and just extend on the current special case of one PGD entry - just make that one PGD entry be two, and pre-allocate the (one) PMD entry that you use for SRM callbacks and vmalloc(), and fill it into each page directory so that set_pgdir() is basically "pre-done" and thus nothing ever needs to be done afterwards. That simplifies the page fault handling. Not that the test and conditional branch probably matters all that much, but still.. We cannot do this on a 2-level x86 page table because we don't want to limit the vmalloc() area to 4MB, but on a 3-level page table (whether with PAE on x86 or on alpha), you could easily just decide to limit the vmalloc() area to a a gigabyte or two and handle it with just one PGD entry.. 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 2.4 TODO List - more on PCI resources...]
I'm not familiar with yenta controllers/devices, and I'm not trying to throw you a tasty red herring, but... yenta_config_init() does config_writeb(socket, PCI_CACHE_LINE_SIZE, 32); Is this writing to the CardBus bridge or to the device's CacheLineSize register? If the latter, and given that PCI_CACHE_LINE_SIZE is in units of 4-byte "words", is 32 [= 128 bytes] a good value to use? If so, why? Or is it OK because it is setting a PCI bridge device's cache line size? >From TI's PCI1451 GJG CardBus controller spec: 4.8 Cache Line Size Register The cache line size register is programmed by host software to indicate the system cache line size. Thanks, ~Randy - 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 Fri, Oct 13, 2000 at 02:17:23PM -0700, Richard Henderson wrote: > On Fri, Oct 13, 2000 at 12:45:47PM +0100, Alan Cox wrote: > > Can we always be sure the rss will fit in an atomic_t - is it > 32bits on the > > ultrsparc/alpha ? > > It is not. It is not even 32bit on sparc32 (24bit only). 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/
Re: Updated Linux 2.4 Status/TODO List (from the ALS show)
On Fri, Oct 13, 2000 at 12:45:47PM +0100, Alan Cox wrote: > Can we always be sure the rss will fit in an atomic_t - is it > 32bits on the > ultrsparc/alpha ? It is not. r~ - 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.4.0-test6 network socket problems
On Fri, 13 Oct 2000, J. Scott Kasten wrote:
> I've found the problem. This type of loop does not work:
>
> do {
> alarm(t);
> read(fd);
> if (EINT)
>exception();
> else
>alarm(0);
> } while (data);
>
> There are some semantics here that differ from other *nix where this
> works. The read() won't come out when the alarm comes, and the socket
> will effectively become broken.
>
> Instead, it appears that I needed to use select(), which probably would
> have been better in the first place anyway.
>
> Thanks to anyone that took the time to look at this.
>
You can certainly use select() and it's 'better' and more useful.
However, the problem is the default nature of the way signal() in the 'C'
runtime library sets up the handler.
You should use sigaction() without the SA_RESTART flag. This lets
a signal unblock a system call, the resulting errno being EINTER.
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: dual head r128
On Fri, 13 Oct 2000, Benjamin Herrenschmidt wrote:
> >Or, more general, treat [PCI] I/O space similar to [PCI] memory space. Just
> >like we must use ioremap() for memory space:
> >
> >cookie = ioremap(memory_space_address, size);
> >x = readb(cookie+offset);
> >
> >we could have ioportremap() for I/O space:
> >
> >cookie = ioportremap(io_space_address, size);
> >x = inb(cookie+offset);
> >
> >On PC, ioportremap(x) would evaluate to (x). On other platforms, we can do
> >whatever we want.
>
> That would make us fall in the same trap as we are now with multiple IO
> busses having overlapping IO mappings. (Basically, every IO bus on some
> multi-bus systems have 0->64k IO range). ioportremap() cannot "know" on
> which bus the device is, except if we also pass the pci_dev* parameter
> (and NULL for ISA).
But you can fixup all pci_dev's so bus 0 takes 0x0-0x0f, bus 1 takes
0x1-0x1, and so on. ioportremap() finds out the bus by looking at the
region.
I/O space is not limited to 64 kB on non-ia32, we can use the full size of an
unsigned long.
Legacy I/O mappings (`I have legacy lp0 on bus 0 and legacy lp1 on bus 1') can
be sorted out in ioportremap() as well.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
-
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:28:30AM +0200, Andi Kleen wrote: (snip) > 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. > Caution is advised when depending upon crypto systems that use relative block numbers as IV. The security may not be a strong as hoped. There are some who believe that "not unique" IVs (across multiple filesystems) facilitates some methods of cryptanalysis. Strong security is the reason absolute block numbers were chosen at the time I introduced loop.c cipher-block-chaining support (in kernel 2.1.130). This has the unfortunate side effect of preventing filesystem relocation... leading some to claim that loop.c is now broken. A crypto system is only as strong as its weakest link. Perhaps losetup can allow the user to specify a "IVseed" value and then pass to the transfer modules IVseed + relative block. This would also allow existing absolute block based encrypted file systems to be relocated (IVseed = absolute # of 1st block), satisfy those among us who demand unique IVs, and allow those who prefer operational convenience at the cost of weaker security to do so. Reed H. Petty [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: 2.4.0-test6 network socket problems
I've found the problem. This type of loop does not work:
do {
alarm(t);
read(fd);
if (EINT)
exception();
else
alarm(0);
} while (data);
There are some semantics here that differ from other *nix where this
works. The read() won't come out when the alarm comes, and the socket
will effectively become broken.
Instead, it appears that I needed to use select(), which probably would
have been better in the first place anyway.
Thanks to anyone that took the time to look at this.
-S-
> I'm working with test6 on an embedded
> QED MIPS arch in big endian mode. I
> have run into some bizarre socket problems that appear to affect both
> udp and tcp transport. Applications actively using sockets (examples,
> ftp, tftp, others...) will unexpectedly stop receiving data on the
> socket, even though data is present. The process will be forever
> sleeping on the read even though data is queued up. To illustrate my
> point, I've dug deep into the udp code (net/ipv4/udp.c) and the
> datagram core (net/core/datagram.c) researching the simple tftp
> example.
-
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] 2.4.0-test10-pre2 - drivers/net/rcpci45.c - conflicting types
gcc -D__KERNEL__ -I/tmp/romieu/tmp/linux-2.4.0-test10-pre2/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -pipe -march=i686 -fno-strict-aliasing -DMODULE -DMODVERSIONS -include /tmp/romieu/tmp/linux-2.4.0-test10-pre2/include/linux/modversions.h -c -o rcpci45.o rcpci45.c In file included from rcpci45.c:79: rclanmtl.h:73: redefinition of `u16' /tmp/romieu/tmp/linux-2.4.0-test10-pre2/include/asm/types.h:34: `u16' previously declared here rclanmtl.h:75: conflicting types for `u32' /tmp/romieu/tmp/linux-2.4.0-test10-pre2/include/asm/types.h:37: previous declaration of `u32' make[2]: *** [rcpci45.o] Error 1 make[2]: Leaving directory `/tmp/romieu/tmp/linux-2.4.0-test10-pre2/drivers/net' make[1]: *** [_modsubdir_net] Error 2 make[1]: Leaving directory `/tmp/romieu/tmp/linux-2.4.0-test10-pre2/drivers' make: *** [_mod_drivers] Error 2 drivers/net/rclanmtl.h defines U8, U16 and U32 for its own usage and it seems to clashes with include/net/divert.h (coming from ./include/linux/netdevice.h). I s/ed the rpci45 driver with u8,16,32. Should the same be done for divert ? -- Ueimor 1.bz2
[linux-fbdev] [PATCH] updated vgacon/vga16fb work
Hi! Here is more updated work on the vgacon to fbcon to vgacon again code. I almost got it. I just need to figure out how to free up the resources from the fbdev drivers I tried it out on. I have attemped on the G400 matrox driver and the vga16 driver. Both give a : Device or resource busy when I go to rrmod it. newvga.diff.gz
kernel BUG at inode.c:441
with 2.4.0test10-pre2 ksymoops 2.3.3 on i686 2.4.0-test10. Options used -v /usr/src/linux/vmlinux (specified) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.0-test10/ (default) -m /usr/src/linux/System.map (default) Oct 13 20:28:58 trespassersw kernel: invalid operand: Oct 13 20:28:58 trespassersw kernel: CPU:0 Oct 13 20:28:58 trespassersw kernel: EIP:0010:[prune_icache+133/232] Oct 13 20:28:58 trespassersw kernel: EIP:0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 Oct 13 20:28:58 trespassersw kernel: EFLAGS: 00010282 Oct 13 20:28:58 trespassersw kernel: eax: 001b ebx: c171e9e8 ecx: c1236000 edx: Oct 13 20:28:58 trespassersw kernel: esi: c171e9e0 edi: c64196e8 ebp: c1237fa8 esp: c1237f84 Oct 13 20:28:58 trespassersw kernel: ds: 0018 es: 0018 ss: 0018 Oct 13 20:28:58 trespassersw kernel: Process kswapd (pid: 2, stackpage=c1237000) Oct 13 20:28:58 trespassersw kernel: Stack: c01ddb0a c01ddbc1 01b9 0004 006f 0353 c680e548 Oct 13 20:28:58 trespassersw kernel:c3359c48 c013f745 01ad c0128f67 0006 0004 0006 Oct 13 20:28:58 trespassersw kernel:0004 c01da3d7 c1236239 0008e000 c0128fff 0004 Oct 13 20:28:58 trespassersw kernel: Call Trace: [tvecs+21694/76116] [tvecs+21877/76116] [shrink_icache_memory+33/48] [do_try_to_free_pages+91/128] [tvecs+7563/76116] [kswapd+115/308] [kernel_thread+40/56] Oct 13 20:28:58 trespassersw kernel: Call Trace: [] [] [] [] [] [] [] Oct 13 20:28:58 trespassersw kernel: Code: 0f 0b 83 c4 0c 8b 53 04 8b 03 89 50 04 89 02 8b 53 fc 8b 43 >>EIP; c013f6c1<= Trace; c01ddb0a Trace; c01ddbc1 Trace; c013f745 Trace; c0128f67 Trace; c01da3d7 Trace; c0128fff Trace; c0108a3c Code; c013f6c1 <_EIP>: Code; c013f6c1<= 0: 0f 0b ud2a <= Code; c013f6c3 2: 83 c4 0c add$0xc,%esp Code; c013f6c6 5: 8b 53 04 mov0x4(%ebx),%edx Code; c013f6c9 8: 8b 03 mov(%ebx),%eax Code; c013f6cb a: 89 50 04 mov%edx,0x4(%eax) Code; c013f6ce d: 89 02 mov%eax,(%edx) Code; c013f6d0 f: 8b 53 fc mov0xfffc(%ebx),%edx Code; c013f6d3 12: 8b 43 00 mov0x0(%ebx),%eax Let me know if any more info required. - 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/
Nice oops from agpgart - 2.2 kernels and Alpha
On UP1100 Alpha with an AGP slot and "Advanced Micro Devices [AMD] AMD-751 [Irongate] System Controller" an attempt to use 'agpgart' support ends up with an oops. I tried 2.2.17 and 2.2.18pre15 kernels. With CONFIG_AGP=y and CONFIG_AGP_AMD=y resulting kernel gets stuck after oops and does not boot. If CONFIG_AGP=m is used then an attempt to insert 'agpgart' module ends up with the following oops (after a run through 'ksymoops'): ksymoops 2.3.4 on alpha 2.2.18pre15x. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.2.18pre15x/ (default) -m /boot/System.map-2.2.18pre15x (specified) Unable to handle kernel paging request at virtual address 6204 insmod(1048): Oops 1 pc = [] ra = [] ps = Using defaults from ksymoops -t elf64-alpha -a alpha v0 = t0 = 6200 t1 = 6200 t2 = 0c322000 t3 = fc802000 t4 = fe85 t5 = fe85 t6 = fffe t7 = fc000c2a s0 = fe844e50 s1 = fe844f50 s2 = fe844cb0 s3 = 0001 s4 = 0001 s5 = fe844e50 s6 = fe840090 a0 = fd01fe14 a1 = 00b0 a2 = 0080 a3 = fc569310 a4 = fc000c2a3d60 a5 = fc000c2a3d58 t8 = 0001 t9 = fc523078 t10= t11= fc523070 pv = fc31d640 47f01412 or zero,128,a2 4441f102 andnot t1,15,t1 44420401 or t1,t1,t0 b05e0020 stl t1,32(sp) 4821f621 zapnot t0,15,t0 b42a stq t0,0(s1) a6090028 ldq a0,40(s0) Trace: 332014 33bc18 310cf8 42fe80 Warning (Oops_read): Code line not seen, dumping what data is available >>PC; fe841ba8 <[agpgart]amd_irongate_configure+68/140> <= Trace; 00332014 Before first symbol Trace; 0033bc18 Before first symbol Trace; 00310cf8 Before first symbol Trace; 0042fe80 Before first symbol 1 warning issued. Results may not be reliable. followed by a "Segmentation fault" from insmod. Unfortunately option -m produces an empty symbol map for the module; also later the module is not removable with the following output from lsmod: agpgart21312 1 (initializing) This bomb happens on this code /* Write out the address of the gatt table */ OUTREG32(amd_irongate_private.registers, AMD_ATTBASE, agp_bridge.gatt_bus_addr); from amd_irongate_configure() in drivers/char/agp/agpgart_be.c. I dropped few printk's there like that: /* Get the memory mapped registers */ pci_read_config_dword(agp_bridge.dev, AMD_MMBASE, ); printk(KERN_INFO PFX "Read irongate temp %x\n", temp); temp = (temp & PCI_BASE_ADDRESS_MEM_MASK); printk(KERN_INFO PFX "Masked temp to %x\n", temp); amd_irongate_private.registers = (volatile u8 *) ioremap(temp, 4096); printk(KERN_INFO PFX "Updated private registers to %x\n", amd_irongate_private.registers); and results are as follows: Linux agpgart interface v0.99 (c) Jeff Hartmann agpgart: Maximum main memory to use for agp memory: 204M agpgart: Detected AMD Irongate chipset agpgart: Read irongate temp 6208 agpgart: Masked temp to 6200 agpgart: Updated private registers to 6200 Unable to handle kernel paging request at virtual address 6204 Any ideas what is wrong with this picture? BTW - despite the following commment in drivers/char/drm/drm.h "Dec 1999, Richard Henderson <[EMAIL PROTECTED]>, move to generic cmpxchg." an attempt to compile 'drm' module includes some x86 specific code from drivers/char/drm/drmP.h, like this: __asm__ __volatile__(LOCK_PREFIX "cmpxchgb %b1,%2" : "=a"(prev) : "q"(new), "m"(*__xg(ptr)), "0"(old) : "memory"); and, as you can guess, does not compile on Alpha. But that is the next problem after 'agpgart'. :-) Michal [EMAIL PROTECTED] [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: unresolved symbols in ipx module
On Fri, 13 Oct 2000, John Williams wrote: > This means to add ipx to the kernel, I have to rebuild the entire kernel > and boot with it in order to satisfy the dependancies. I cannot just > compile it as a module and add it because it has non-modular dependancies. I encountered this same problem with the Appletalk module a couple days ago. I compiled my kernel (2.2.17) with Appletalk disabled, then realized that I needed it so I built it as a module. But it wouldn't load because it required register_snap_client() and unregister_snap_client(). Rebuilding my kernel solved the problem, but it took a little digging through Makefiles to figure out what was actually going on Michael - 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-pre2
On Fri, Oct 13, 2000 at 12:22:35PM -0700, Linus Torvalds wrote: > The PGD is 1024 entries, and the last one is used by the self-mapping > stuff. But the VMALLOC area is NOT there ... Ok, I was slightly confused. Yes, the vptb is at 0xfffe not 0xfe00. The bit I was remembering is the SRM callback console setup, which _does_ exist in the same PGD as vmalloc. But that, of course, would only be true if you were running SRM. Thanks for the patch, Ivan. r~ - 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/
unresolved symbols in ipx module
About a year ago there was a short thread about unresolved symbols in the ipx module, which doesn't appear to have come to a solution. I have just had the same problem, and have some new information to add. (kernel 2.2.16 on Redhat 6.2) The problem: "depmod -ae" says depmod: *** Unresolved symbols in /lib/modules/2.2.16/misc/ipx.o depmod: make_EII_client depmod: destroy_EII_client depmod: register_8022_client_Rsmp_934262ba depmod: unregister_8022_client_Rsmp_7acef15d depmod: register_snap_client_Rsmp_612bcc66 depmod: unregister_snap_client_Rsmp_9abefc50 depmod: make_8023_client depmod: destroy_8023_client The cause: I was running a kernel without ipx capabilities, but decided I wanted to mount some Netware volumes. So I assumed I could just compile the appropriate modules, add them to the running kernel, and away I go... Unfortunately the above error happens. Looking around the kernel sources, I see that the symbols are defined in net/ethernet/pe2.c, net/802/p8022.c, net/802/p8023.c, and net/802/psnap.c. If I understand the Makefiles correctly, the EII, 8022, and snap symbols are compiled directly into the kernel, but only if IPX_CONFIG is defined. This means to add ipx to the kernel, I have to rebuild the entire kernel and boot with it in order to satisfy the dependancies. I cannot just compile it as a module and add it because it has non-modular dependancies. OTOH, make_8023_client and destroy_8023_client are already in the kernel, but are still not resolving. I haven't figured that out yet. Any hints? I hope this defines the problem well enough that someone more experienced than me can fix it. Or give me some pointers on what to do. I assume it would require making pe2, p8022, p8023, and psnap modular, but I don't know how to do that yet. ~ John Williams - 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: Dell smp won't boot
It's likely the megaraid driver. Try the megaraid driver that's in the latest 2.2.18pre. Thanks, Matt -Original Message- From: Greg Hennessy [mailto:[EMAIL PROTECTED]] Sent: Friday, October 13, 2000 2:59 PM To: [EMAIL PROTECTED] Subject: Dell smp won't boot One of my dual cpu dell server running 2.2.15 has stopped booting. It gets part way through the boot process and rints wait_oin_bh, cpu 1 irq: 0 [0 0] bh: 1 [1 0] <[c010aefd]> <[c0119ecf]> <[c011a029]> <[c0113ad0]> <[c010933c]> and repeats. Might this be a software problem, or should I simply call in for a tech support person to schedule a site visit. - 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: large memory support for x86
Timur Tabi wrote: > I understand that a normal virtual address (i.e. a pointer) can only address a > single 32-bit (4GB) memory block. My point was that by also using more than > one 16-bit selector, you can have multiple 4GB areas. So for instance, > 1000: can point to one physical address, and 1001: can point a > different physical address. > > Yes, this means that you need to use multiple selectors in order to access more > than 4GB of virtual space. If you were to try to overflow the linear address you would either get a fault or a wraparound. It won't work like the old DOS highmem tricks. > According to section 3.8 of Intel's P3 manual, Volume 3, enabling the PAE > increases the size of the page table entries to 64 bits. There are other > changes, such as extended the 20-bit page directory base address to 27 bits. > All this means that a virtual address (selector:offset) can point to a physical > address larger than 32 bits. > > Frankly, the whole thing makes my head hurt. Section 3.9.1, quote: "No matter which 36-bit addressing feature is used (PAE or 36-bit PSE), the linear address space of the processor remains at 32 bits. Applications must partition the address space of their work loads across multiple operating system processes to take advantage of the additonal physical memory provided in the system." -- Brian Gerst - 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/
Dell smp won't boot
One of my dual cpu dell server running 2.2.15 has stopped booting. It gets part way through the boot process and rints wait_oin_bh, cpu 1 irq: 0 [0 0] bh: 1 [1 0] <[c010aefd]> <[c0119ecf]> <[c011a029]> <[c0113ad0]> <[c010933c]> and repeats. Might this be a software problem, or should I simply call in for a tech support person to schedule a site visit. - 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 Fri, 13 Oct 2000, Timur Tabi wrote: > ** Reply to message from Alexander Viro <[EMAIL PROTECTED]> on Fri, 13 Oct 2000 > 15:25:31 -0400 (EDT) > > > > Ditto with PAE: 16:32->32->36. > > In _all_ cases you are limited by the size of linear address. I.e. all > > address modes are limited to 4Gb. All you can get from PAE is placing of > > these 4Gb in 64Gb of physical memory. > > Then how are you supposed to access all 64GB of RAM in your machine? The > kernel must be able to access all 64GB of RAM at once, otherwise it can't do > proper memory management. Kernel doesn't have to access it all at once. Most of the time it doesn't care about the contents of most pages. It certainly needs some permanently mapped stuff, but it's _way_ less than the full memory. The rest is mapped and unmapped on demand. That's what kmap() and kunmap() do. Moreover, 4.4BSD derivatives never bothered mapping the whole physical memory in kernel space, even on 386. It's more complex than what we used to do, but it's doable quite fine. There is no need to keep the whole memory mapped by the kernel. > I've been reading on the PAE in Intel's manuals. I admit, some of it is over > my head. I was under the impression that it was 16:32->64->36 with PAE enabled. Nope. 16:32->32->36. Paging is _after_ the 32-bit bottleneck. You'ld have to change segment descriptors format to expand it. - 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 13:37:21 Andre Tomt wrote: > > I have to be wicked crazy - but: > Linux version 2.2.18pre15 (root@juce) (gcc version 2.97 20001010 > (experimental)) #7 Tue Oct 10 20:18:58 CEST 2000 > > It seems to "work", but it hasn't been put under stress, yet. > The reason I tried the kernel with 2.97 was the -march=athlon option. > It's 2.97, not 2.96. I think it is some strange bug with cpp not handling va-arg macros in -traditional mode as the Makefile in arch/i386/lib states. -- 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: large memory support for x86
On Fri, 13 Oct 2000, Timur Tabi wrote: > I understand that a normal virtual address (i.e. a pointer) can only address a > single 32-bit (4GB) memory block. My point was that by also using more than > one 16-bit selector, you can have multiple 4GB areas. So for instance, > 1000: can point to one physical address, and 1001: can point a > different physical address. _All_ of them are piped through the 4Gb address space. I.e. every segment is mapped to a part of the same (for all segments) 4Gb. That address space is, in turn, mapped to 64Gb of physical memory. At any moment you can't get more than 2^32 different elements of physical memory accessible, even though you have 48 bits of address in the beginning and 36 bits in the end. Think of it that way: we have two functions: u32 map_segment(u48); u36 map_paging(u32); and processor does map_paging(map_segment(address)) when it calculates the physical addresses. Even though both the range and domain are larger than 2^32, the number of different values is less or equal to it. > Yes, this means that you need to use multiple selectors in order to access more > than 4GB of virtual space. > > According to section 3.8 of Intel's P3 manual, Volume 3, enabling the PAE > increases the size of the page table entries to 64 bits. There are other > changes, such as extended the 20-bit page directory base address to 27 bits. > All this means that a virtual address (selector:offset) can point to a physical > address larger than 32 bits. Virtual address gives linear address. _Then_ it is translated into physical address. Page tables describe the latter mapping. Descriptor tables - the former. Size of linear address is the bottleneck here and no changes past that bottleneck can expand the number of possible values. - 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 Alexander Viro <[EMAIL PROTECTED]> on Fri, 13 Oct 2000 15:25:31 -0400 (EDT) > Ditto with PAE: 16:32->32->36. > In _all_ cases you are limited by the size of linear address. I.e. all > address modes are limited to 4Gb. All you can get from PAE is placing of > these 4Gb in 64Gb of physical memory. Then how are you supposed to access all 64GB of RAM in your machine? The kernel must be able to access all 64GB of RAM at once, otherwise it can't do proper memory management. I've been reading on the PAE in Intel's manuals. I admit, some of it is over my head. I was under the impression that it was 16:32->64->36 with PAE enabled. -- 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 Fri, 13 Oct 2000, Timur Tabi wrote: > ** Reply to message from Ingo Molnar <[EMAIL PROTECTED]> on Fri, 13 Oct 2000 > 20:44:19 +0200 (CEST) > > > > processes are not limited to a single segment, eg. Wine uses nonstandard > > segments. But as i said, using multiple segments does not let you out of > > 32 bits of virtual memory. > > Sure it does, just like segments let 16-bit apps access more than 64KB of > memory. If you have two selectors, each one can point to a different physical > base address, and IIRC, the size of the physical address base can be 36 bits. > That gives you 16 physically contiguous 4GB memory blocks. RTFM. Take any manual on x86 architecture and stare at the pictures. Ones that describe how segments work. Real mode: 16:16 -> 21 or 20. Real mode with undocumented twists: 16:16->21->32 (you _can_ get paging with real mode style of segments). 286 protected mode: 16:16 -> 24. Ditto with twists: 16:16->24->32. 386 protected mode: 16:32->32. Ditto with paging: 16:32->32->32. Ditto with PAE: 16:32->32->36. In _all_ cases you are limited by the size of linear address. I.e. all address modes are limited to 4Gb. All you can get from PAE is placing of these 4Gb in 64Gb of physical memory. - 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.4.0-test6 network socket problems
I'm working with test6 on an embedded QED MIPS arch in big endian mode. I
have run into some bizarre socket problems that appear to affect both udp
and tcp transport. Applications actively using sockets (examples, ftp,
tftp, others...) will unexpectedly stop receiving data on the socket, even
though data is present. The process will be forever sleeping on the read
even though data is queued up. To illustrate my point, I've dug deep into
the udp code (net/ipv4/udp.c) and the datagram core (net/core/datagram.c)
researching the simple tftp example.
After much debugging, here is what I know:
I have followed the packets in from the network driver all the way to
udp_rcv() in udp.c. I see it do the sk lookup and drop it off in
udp_queue_rcv_skb(). Everything is fine on that end.
On the process end, I've been watching in the udp_recvmsg() function, also
in udp.c. Under normal operation, I see it pick up the data from the
correct skb and return. When the rare condition that causes failure
occurs, skb_recv_datagram() returns a NULL and err is set to -ERESTARTSYS.
It is only when the process gets hung on that socket that I see this
happen. It never revisits this portion of the code again, however, until
the sender stops transmitting data from ACK timeouts, I see the packets
continue to pile up on the udp_rcv() side without incident.
I further looked at datagram.c to see what the skb_recv_datagram() was
doing. It was spinning through the do {} while() loop waiting for
wait_for_packet() to hand it something. It is in that routine that the
error code is generated. The signal_pending() function returns true
and sock_intr_errno() returns the -ERESTARTSYS code, which gets passed
back down the chain from here.
The structure of the tftp code that I'm working with is such that it does
a generic blocking read() on the socket file handle and uses an alarm to
wake up when the critical timeout is reached. Not the most glorious code,
but demonstrates a problem none-the-less. The read() never returns an
EINTR or EAGAIN or anything. It's just hung. I'm assuming that the
signal_pending() return comes from my alarm(), which means that the
process had already been sitting on that socket for a while not seeing the
data that is clearly already present. Thus, there may be two problems
here, the signal not returning, and data trapped in the skb.
I would appreciate it if anyone more familiar with this code could point
me better to what I should be looking at, or at least explain what should
be happening that isn't.
TIA,
-S-
--
J. Scott Kasten
Email: jsk AT tetracon-eng DOT net
"In most cases, all an argument proves
is that two people were present.."
-
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 Brian Gerst <[EMAIL PROTECTED]> on Fri, 13 Oct 2000 15:07:42 -0400 > You missed the point. The layering on the X86 memory managment is such: > >Segment > | > Virtual Address<- limited to 32 bits > | > Physical Address > > Segmentation never directly gives you a physical address, even in real > mode. Although in real mode virtual address is hardwired to physical > address. Virtual addresses are always 32 bits on the x86. In real > mode, in protected mode, and with PAE enabled. I understand that a normal virtual address (i.e. a pointer) can only address a single 32-bit (4GB) memory block. My point was that by also using more than one 16-bit selector, you can have multiple 4GB areas. So for instance, 1000: can point to one physical address, and 1001: can point a different physical address. Yes, this means that you need to use multiple selectors in order to access more than 4GB of virtual space. According to section 3.8 of Intel's P3 manual, Volume 3, enabling the PAE increases the size of the page table entries to 64 bits. There are other changes, such as extended the 20-bit page directory base address to 27 bits. All this means that a virtual address (selector:offset) can point to a physical address larger than 32 bits. Frankly, the whole thing makes my head hurt. -- 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: test10-pre2
In article <[EMAIL PROTECTED]>, Richard Henderson <[EMAIL PROTECTED]> wrote: >On Fri, Oct 13, 2000 at 08:15:46PM +0400, Ivan Kokshaysky wrote: >> On Thu, Oct 12, 2000 at 01:18:53PM -0700, Linus Torvalds wrote: >> > See the arch/x86/mm/fault.c changes to see what arch-specific changes this >> > can entail. >> > >> This patch works for me... > >You shouldn't have needed any changes at all to work. >The synchronization we already do for the vptb also >takes care of vmalloc. Richard: I agree that the changes "shouldn't" be needed, but from looking at the code, the alpha doesn't actually share the PGD entry for vmalloc'ed memory at all. The PGD is 1024 entries, and the last one is used by the self-mapping stuff. But the VMALLOC area is NOT there - the self-mapping uses up one complete PGD entry (it has to - it points to itself), and we don't set up any other special vmalloc-entry that would be global from the start.. 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
On Fri, 13 Oct 2000, Chris Swiedler wrote: > > Why is it that a user process can't intentionally switch segments? > Dereferencing a 32-bit address causes the address to be calculated using the > "current" segment descriptor, right? It seems to me that a process could set > a new segment selector, in which case a dereference would operate on a whole > new segment. Is there a reason why processes are limited to a single > segment? > > chris You can (although not in user-mode). The problem is; "What RAM do you reference?". You have 32-bits worth of addressing available in some machine that has 32-bits worth of addressible RAM. What can be done is to set one page to be 'not present'. Then, when you page-fault, the page-fault handler can set some bit(s) in a hardware page-register to map in another bank of RAM that isn't in use yet. In principle, this would allow access to (2^16/8 -1) * (2^32 -1) unique areas of RAM (segment descriptors are 16 bits, but they are numbered in increments of 8. So, you now want to copy from a segment addressed by DS, back to your original DS, you have to rewrite the 'C' runtime library to use 'full pointers', i.e., DS:ESI, ES:EDI, etc., with ES and ES being different. You have to dereference the full pointer on avery access! Caching has to be turned off when RAM values that may be in the cache reference RAM that is not back-switch in. You would have a slow mess. However, in principle it could work. 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: [PATCH] usb audio.
On Fri, Oct 13, 2000 at 10:27:05AM -0700, Dunlap, Randy wrote: > > I tried: > > > > setpci -s 00:07.2 latency_timer=20 > > setpci -s 00:07.2 latency_timer=40 > > setpci -s 00:07.2 latency_timer=80 > > > > but without effect. However, the USB device doesn't have a latency > > timer, so that probably explains. > > How about trying latency_timer=10, which will apparently > show up as being 0 (since 10 is smaller than its > implemented granularity). That didn't help, but I found the problem: APM. I had GNOME battery_applet running, and that checks /proc/apm every 2 seconds (default value). Removing the applet from the taskbar solved the problem, and as soon as I do "cat /proc/apm" the audio stops for about a second. I recompiled the kernel with CONFIG_APM_ALLOW_INTS enabled, in the hope that the USB interrupts would still come through, but that didn't solve it. I'm glad I finally found the problem, but how to solve it? Is this a bug in APM or in USB? Erik -- J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department of Electrical Engineering, Faculty of Information Technology and Systems, Delft University of Technology, PO BOX 5031, 2600 GA Delft, The Netherlands Phone: +31-15-2783635 Fax: +31-15-2781843 Email: [EMAIL PROTECTED] WWW: http://www-ict.its.tudelft.nl/~erik/ - 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 Fri, 13 Oct 2000, Torben Mathiasen wrote: > > Yes it works, its not all that different from my patch ;). Yeah. The thing I actually cared most about was the comment, which makes the patch palatable to me. 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: test10-pre2
On Fri, Oct 13, 2000 at 09:54:14AM -0700, Richard Henderson wrote: > You shouldn't have needed any changes at all to work. But without that change I've got oopses (fortunately not fatal) in swapon and modprobe. > The synchronization we already do for the vptb also > takes care of vmalloc. > Probably I completely missed the point, but where are we doing it? Ivan. - 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 wrote: > > ** Reply to message from Ingo Molnar <[EMAIL PROTECTED]> on Fri, 13 Oct 2000 > 20:44:19 +0200 (CEST) > > > processes are not limited to a single segment, eg. Wine uses nonstandard > > segments. But as i said, using multiple segments does not let you out of > > 32 bits of virtual memory. > > Sure it does, just like segments let 16-bit apps access more than 64KB of > memory. If you have two selectors, each one can point to a different physical > base address, and IIRC, the size of the physical address base can be 36 bits. > That gives you 16 physically contiguous 4GB memory blocks. You missed the point. The layering on the X86 memory managment is such: Segment | Virtual Address<- limited to 32 bits | Physical Address Segmentation never directly gives you a physical address, even in real mode. Although in real mode virtual address is hardwired to physical address. Virtual addresses are always 32 bits on the x86. In real mode, in protected mode, and with PAE enabled. -- Brian Gerst - 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 -- new addition WAS(test9 PCI resourcecollisions (fwd)
On Fri, 13 Oct 2000, Linus Torvalds wrote: > > Can you add the same extra debug code that I asked Dag Bakke to add for > his problem: Oh, also, can you try to see what happens if you change the define for #define pcibios_assign_all_busses() 0 to a 1 in include/asm-i386/pci.h? That should force Linux to re-configure all buses, regardless of whether they have been set up some way by the BIOS. Which might make a difference. But please do this separately from the extra debug code - I'd like to see what the debug code says regardless of this change.. 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] For 2.4: syscall revoke.
On Fri, 13 Oct 2000, Alan Cox wrote: > > 1) one process does read() on device, another does revoke() > > followed by rmmod. Oops - nothing holds module in memory, the first > > process is executing code from that module (->read(), that is) and > > we unmap that code. > > > > 2) every access to ->f_op suddenly becomes unsafe. Basically the > > same scenario, but here we have the window between fetching ->f_op and > > calling ->f_op->foo. You have no exclusion here, and even if you had, you > > still got #1 to deal with. > > Is #2 actually a problem if #1 is ok. We don't destroy f_ops tables except > on a module unload. Another thing that is arguable is that revoke() should > not return until the revocation is completed. That would solve #1 in the > process I belive ? The problem being: you have no way to tell when method returns. IOW, there's nothing for revoke() to sleep on. #2 is essentially the same as #1, but with an additional twist: call of old method may happen after the new value of ->f_op is written to memory. Some exclusion is obviously needed here. In principle, rw-semaphore with all methods callers holding it for read and revoke() holding it for write would be enough, but I suspect that overhead will be nasty. Something like rw-semaphore with extremely light-weight readers and potentially slow writer might be OK, but AFAICS there is nothing of that sort in the tree. We have such spinlocks, but I don't see how to apply that idea to semaphores. Besides, it ought to be small - every struct file will have to contain such beast. - 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 13 Oct 00 at 13:42, Timur Tabi wrote: > ** Reply to message from Ingo Molnar <[EMAIL PROTECTED]> on Fri, 13 Oct 2000 > 20:44:19 +0200 (CEST) > > processes are not limited to a single segment, eg. Wine uses nonstandard > > segments. But as i said, using multiple segments does not let you out of > > 32 bits of virtual memory. > > Sure it does, just like segments let 16-bit apps access more than 64KB of > memory. If you have two selectors, each one can point to a different physical > base address, and IIRC, the size of the physical address base can be 36 bits. > That gives you 16 physically contiguous 4GB memory blocks. Sure it does not. Selectors point to linear addresses, before passing them through pagetables. You have 32+14 bits of virtual address (32 = offset, 14 = valid bits in selector), which are translated, together with offset, to 32 bit linear address. This 32bit linear address is passed through pagetables to 36 bit physical address. So it must go through 32bit linear address, and there is no easy way to overcome this limit. You can either (1) forget about simple pointers and dereferencing pointers, and go through realmode windows way - you must GlobalLock() memory area, and you'll get pointer. Then you GlobalUnlock()... And you can lock at most 2GB (maybe 3GB if you'll thought really good algorithm) of such data... Or (2) make complete segment non present, and on pagefault unmap all pages belonging to some selector + invalidate selector, and map something else in. You must create at least four such areas, as you must have mapped at least CS, SS, ES and one of DS/FS/GS to successfully execute MOVSB... So each area should be < 256MB. Are you really sure that it is worth of effort? Also do not forget that 'sizeof(void*) > sizeof(long)' in such environment, so tons of code broke... And someone must translate pointers from 48bits to 32 for kernel use... Best regards, Petr Vandrovec [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
On Fri, 13 Oct 2000, Timur Tabi wrote: > Sure it does, just like segments let 16-bit apps access more than 64KB of > memory. If you have two selectors, each one can point to a different physical > base address, and IIRC, the size of the physical address base can be 36 bits. > That gives you 16 physically contiguous 4GB memory blocks. No. The segment base and length is confined to the 32 bit address space mapped by page tables. -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/
