Re: Is sendfile all that sexy?
In article <[EMAIL PROTECTED]>, Steve VanDevender <[EMAIL PROTECTED]> writes: > Ton Hospel writes: > > In article <[EMAIL PROTECTED]>, > > [EMAIL PROTECTED] writes: > > > I am afraid I have missed most earlier messages in this thread. > > > However, let me remark that the problem of assigning a > > > file descriptor is the one that is usually described by > > > "priority queue". The version of Peter van Emde Boas takes > > > time O(loglog N) for both open() and close(). > > > Of course this is not meant to suggest that we use it. > > > > > Fascinating ! But how is this possible ? What stops me from > > using this algorithm from entering N values and extracting > > them again in order and so end up with a O(N*log log N) > > sorting algorithm ? (which would be better than log N! ~ N*logN) > > > > (at least the web pages I found about this seem to suggest you > > can use this on any set with a full order relation) > > How do you know how to extract the items in order, unless you've already > sorted them independently from placing them in this data structure? Because "extract max" is a basic operation of a priority queue, which I just do N times. > > Besides, there are plenty of sorting algorithms that work only on > specific kinds of data sets that are better than the O(n log n) bound > for generalized sorting. For example, there's the O(n) "mailbox sort". > You have an unordered array u of m integers, each in the range 1..n; > allocate an array s of n integers initialized to all zeros, and for i in > 1..m increment s[u[i]]. Then for j in 1..n print j s[j] times. If n is > of reasonable size then you can sort that list of integers in O(m) time. Yes, I know. that's why you see the "any set with a full order relation" in there. That basically disallows using extra structure of the elements. Notice that the radix sort you describe basically hides the log N in the the representation of a number of max n (which has a length that is basically log n). It just doesn't account for that because we do the operation on processors where these bits are basically handled in parallel, and so do not end up in the O-notation. Any attempt to make radix sort handle arbitrary width integers on a fixed width processor will make the log N reappear. Having said that, in the particular case of fd allocation, we DO have additional structure (in fact, it's indeed integers in 0..n). So I can very well imagine the existance of a priority queue for this where the basic operators are better than O(log N). I just don't understand how it can exist for a generic priority queue algorithm (which the Peter van Emde Boas method seems to be. Unfortunately I have found no full description of the algorithm that's used to do the insert/extract in the queue nodes yet). - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Is sendfile all that sexy?
Ton Hospel writes: > In article <[EMAIL PROTECTED]>, > [EMAIL PROTECTED] writes: > > I am afraid I have missed most earlier messages in this thread. > > However, let me remark that the problem of assigning a > > file descriptor is the one that is usually described by > > "priority queue". The version of Peter van Emde Boas takes > > time O(loglog N) for both open() and close(). > > Of course this is not meant to suggest that we use it. > > > Fascinating ! But how is this possible ? What stops me from > using this algorithm from entering N values and extracting > them again in order and so end up with a O(N*log log N) > sorting algorithm ? (which would be better than log N! ~ N*logN) > > (at least the web pages I found about this seem to suggest you > can use this on any set with a full order relation) How do you know how to extract the items in order, unless you've already sorted them independently from placing them in this data structure? Besides, there are plenty of sorting algorithms that work only on specific kinds of data sets that are better than the O(n log n) bound for generalized sorting. For example, there's the O(n) "mailbox sort". You have an unordered array u of m integers, each in the range 1..n; allocate an array s of n integers initialized to all zeros, and for i in 1..m increment s[u[i]]. Then for j in 1..n print j s[j] times. If n is of reasonable size then you can sort that list of integers in O(m) time. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Mainboard with Serverworks HE Chipset
#include I got a "Tyan Thunder HE-SL"-Mainboard today, which has a "Severworks ServerSet III HE"-Chipset. (2xPIII 933, 2x512MB PC133 ECC-Registered SDRAM) And i have one problem and one question. First the question. I have an uptime of phenomenal 29minutes and "cat /proc/interrupts" tells me this NMI: 175819 175819 LOC: 175829 175828 Should i be worried? Or can i ignore it. With my former Mainboard NMI was (AFAIR) always 0. Now my problem. The Graphic-Card is a Geforce 2, Xfree is 4.02 (compiled under 2.2.17). When i start X, everything is fine. When i go back to text-console and wait "some time" and then switch back to X the computer locks solid and i have to press the Big-Red Button. (Switching back to X after a "short" periode of time, at the text-console, works "normaly") If anyone needs more information, i will happily provide them. Bis denn -- Real Programmers consider "what you see is what you get" to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a "you asked for it, you got it" text editor -- complicated, cryptic, powerful, unforgiving, dangerous. - 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.1-pre7 raid5syncd oops
> "NB" == Neil Brown <[EMAIL PROTECTED]> writes: NB> On January 16, [EMAIL PROTECTED] wrote: NB> Or in short "this cannot happen" :-) NB> Is there any chance of a memory error? NB> Has this happened more than once? I have to confess that I was not running with the stock 2.4.1-pre7 drivers/md/raid5.c; instead I compiled it with the change in -ac9 tree, which checks the return value of alloc_page() early (around line 160). Also I had your ``Desk check'' patch (responding to [EMAIL PROTECTED]'s post) from linux-raid list (around line 1075), and mingo's hot-add/hot-remove fixes. The symptom was very reproducible with that particular kernel (essentially, early in the every reboot sequence I got the same error). In the end, I had to futz with partition type to disable autodetection of those offending raid-5 component partitions to recover from the failure. Since then I reverted back to the stock 2.4.1-pre7 driver with only the ``Desk check'' and mingo's hot-add/hot-remove patch, and have not seen the problem again. It appears that using those early-null-check code from -ac9 without understanding its implications was purely my stupidity, but I still do not offhand see why that would hurt... - 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: Is sendfile all that sexy?
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] writes: > > I am afraid I have missed most earlier messages in this thread. > However, let me remark that the problem of assigning a > file descriptor is the one that is usually described by > "priority queue". The version of Peter van Emde Boas takes > time O(loglog N) for both open() and close(). > Of course this is not meant to suggest that we use it. > Fascinating ! But how is this possible ? What stops me from using this algorithm from entering N values and extracting them again in order and so end up with a O(N*log log N) sorting algorithm ? (which would be better than log N! ~ N*logN) (at least the web pages I found about this seem to suggest you can use this on any set with a full order relation) - 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: nfs client problem in kernel 2.4.0
Trond Myklebust wrote: > I'll bet it's the lseek that's screwing things up again. IIRC IRIX has > an export option to cause it to generate 32-bit readdir cookies. Could > you please try enabling it? Sorry, I forgot to mention this: This option was already enabled. Mogens -- Mogens Kjaer, Carlsberg Laboratory, Dept. of Chemistry Gamle Carlsberg Vej 10, DK-2500 Valby, Denmark Phone: +45 33 27 53 25, Fax: +45 33 27 47 08 Email: [EMAIL PROTECTED] Homepage: http://www.crc.dk - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Where to get reiserfs-utils?
www & ftp.namesys.com seem to be down (or at least I get "no route to host) so I can't go look there. I get the impression that with previous patches utilities like "mkreiserfs" were in linux/fs/reiserfs/utils, but now that ReiserFS is in the main kernel tree the utilities aren't there. I've searched everywhere to find a mirror that would have a matching set of utilities to what's in the kernel (Hans Reiser warns about the need to keep versions in sync in his README) but I can only find older patches, no current reiserfs-utils. Does anyone know where there is a mirror? Another question: I'll try it when I get the utilities, but do you know if it should work to mount a ReiserFS filesystem using loopback from a regular file in an Ext2 filesystem? Yes this sounds like a silly thing to do (journaling on top of non-journaled storage) but is a safe way to exercise the code. I don't have an extra partition handy to try it out on, and I don't want to use it on my real files yet. Thanks, Mike -- Michael D. Crawford GoingWare Inc. - Expert Software Development and Consulting http://www.goingware.com/ [EMAIL PROTECTED] Tilting at Windmills for a Better Tomorrow. - 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/
VM: Undead swap messages at shutdown
Hello Linux VM God :) I think I started seeing this about 2.4.0-ac6...when I shutdown my machine, I see tons of 'VM: Undead swap entry ###', where ### is some memory address. I can also reproduce this 100% by (for example) going into X, loading a lot of crap so that my 112mb ram is full and it starts to swap, then get out of X, and do a 'swapoff -a'. Is this just debugging info, or would you like to see the output of it? My machine is currently a Debian Unstable, with 112mb RAM and about 190mb swap, running 2.4.0-ac8. I have the following kernels installed, so if you need me to see exactly which kernel started this, it'll be easy: toy:/etc# grep label /etc/lilo.conf label = 240ac8 label = 240ac7 # label = 240ac6 # label = 240ac2 # label = 240prac6 # label = 240prac4 # label = 240t13p7 # label = 240t12 # label = 240t12p6 # label = 240t12p5 # label = 240t12p3 # label = 240t12p2 # label = 240t11 # label = 240t11p7 label = k2218p15 label = win98 -- Burton Windle [EMAIL PROTECTED] Linux: the "grim reaper of innocent orphaned children." from /usr/src/linux/init/main.c:1384 - 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: .br blacklisted ?
On Tue, 9 Jan 2001, David Ford wrote: > Rik van Riel wrote: > > On Sun, 7 Jan 2001, John O'Donnell wrote: > > > > > Only on my company's e-mail server. My company typically gets "zero" > > > emails from outside the US. If I get a piece of spam (sorry they are > > > typically from outside the US), I just block the entire .com.br domain. > > > I get far less SPAM now! > > > > Remind me to never help you with kernel problems again. > > Others on this list blacklist or let others blacklist for them > with varying precision. So do I. I chose to blacklist John O'Donnell and he will never get any kernel help from me again (since I can't see his email). Rik -- Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com.br/ - 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: [PLEASE-TESTME] Zerocopy networking patch, 2.4.0-1
On Tue, 9 Jan 2001, Andrea Arcangeli wrote: > BTW, I noticed what is left in blk-13B seems to be my work Yeah yeah, we'll buy you beer at the next conference... ;) Rik -- Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com.br/ - 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: Caches, page coloring, virtual indexed caches, and more
Hi,
> Where do you do this? And how do you handle the case of aliases with kseg,
> the giant kernel mapping.
Aliases between user and kernel mappings of a page are handled by
flush_page_to_ram the old interface) or {copy,clear}_user_page,
flush_dcache_page and update_mmu_cache (new interface). Sparc64 already
uses the new interface and there are patches for ppc and ia64 to use it.
The new interface allows flushes to be avoided, leading to rather nice
performance increases.
See Documentation/cachetlb.txt for more info.
Cheers,
Anton
-
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: Caches, page coloring, virtual indexed caches, and more
> Did you find any software that breaks due to the additional restriction > on the virtual addresses of mappings? Not yet. A good test of shared mmap coherency is a recent samba (2.2 and above) that uses tdb. Tdb relies on shared mmaps heavily and uncovered the bug when running on a dual ultrasparc pretty quickly. Anton - 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-vmbigpatch compile problem
On Tue, 9 Jan 2001, Boszormenyi Zoltan wrote: > PF_RSSTRIM is not declared anywhere either in the linux-2.4.0 > sources or in the 2.4.0-vmbigpatch. Humm, I seem to have forgotten a `cp $i $i.orig` ;) Should be fixed in a newer patch. regards, -- Rik -- Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com.br/ - 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: Subtle MM bug
On 9 Jan 2001, Zlatko Calusic wrote: > Rik van Riel <[EMAIL PROTECTED]> writes: > > > Now if 2.4 has worse _performance_ than 2.2 due to one > > reason or another, that I'd like to hear about ;) > > > > Oh, well, it seems that I was wrong. :) > > First test: hogmem 180 5 = allocate 180MB and dirty it 5 times (on a > 192MB machine) > > kernel | swap usage | speed > --- > 2.2.17 | 48 MB | 11.8 MB/s > --- > 2.4.0 | 206 MB | 11.1 MB/s > --- > > So 2.2 is only marginally faster. Also it can be seen that 2.4 > uses 4 times more swap space. If Linus says it's ok... :) I have been working on some changes to page_launder() which might just fix this problem. Quick and dirty patches are on my home page and I'll try to clean things up and make something correct & clean later today or tomorrow ;) > Second test: kernel compile make -j32 (empirically this puts the > VM under load, but not excessively!) > > 2.2.17 -> make -j32 392.49s user 47.87s system 168% cpu 4:21.13 total > 2.4.0 -> make -j32 389.59s user 31.29s system 182% cpu 3:50.24 total > > Now, is this great news or what, 2.4.0 is definitely faster. One problem is that these tasks may be waiting on kswapd when kswapd might not get scheduled in on time. On the one hand this will mean lower load and less thrashing, on the other hand it means more IO wait. This is another area where we may be able to improve some things. (btw, according to Alan the 2.4 kernel is the first one to break the 1.2 kernel compiling speed record on an 8MB machine he has ;)) cheers, Rik (stuck in australia on a conference) -- Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com.br/ - 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: 'native files', 'object fingerprints' [was: sendpath()]
On Tue, 16 Jan 2001, Ingo Molnar wrote:
> But even user-space code could use 'native files', via the following, safe
> mechanizm:
so here's an alternative to ingo's proposal which i think solves some of
the other objections raised. it's something i've proposed in the past
under the name "extended file handles".
struct extended_file_permission {
int refcount;
some form of mutex to protect refcount;
some list structure head;
};
struct extended_file {
struct file *file;
struct extended_file_permission *perm;
whatever list foo is needed to link with extended_file_perm above;
};
if you allocate a few huge arrays of struct extended_file, then you can
verify if a pointer passed from user space fits into one of those arrays
pretty quickly.
struct task has a struct extended_file_permission * added to it to
indicate which perm struct that task is associated with.
so you just compare the f->perm to current->extended_file_perm and you
know if the task is allowed to use it or not.
clone() allows you to create tasks sharing the same
extended_file_permissions.
fork()/exec() would create new extended_file_perms -- which implicitly
causes all those files to be closed. this gives you pretty light cgi
fork()/exec() off a main "process" which is handling thousands of sockets.
i also proposed various methods of doing O_foo flag inheritance... but the
above is more interesting.
-dean
-
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.1-pre7 raid5syncd oops
On January 16, [EMAIL PROTECTED] wrote: > > Unable to handle kernel NULL pointer dereference at virtual address 0003 > c01ccf91 > *pde = > Oops: 0002 > CPU:0 > EIP:0010:[] > Using defaults from ksymoops -t elf32-i386 -a i386 > EFLAGS: 00010086 > eax: ebx: c1490400 ecx: cfdeb000 edx: cfeed13c > esi: cfdeb000 edi: 1e29 ebp: 0013 esp: cfba7e80 > ds: 0018 es: 0018 ss: 0018 > Process raid5syncd (pid: 9, stackpage=cfba7000) > Stack: c01ccfe0 cfdeb000 c1490400 c01cd430 c1490400 c1490400 0003c53c >1e29 0013 cfba6000 1000 > c1490400 c01cf2a8 c1490400 00078a78 cfba6000 > Call Trace: [] [] [] [] [] >[] [] > Code: 89 50 04 8b 51 04 8b 01 89 02 c7 41 04 00 00 00 00 c3 8d b6 > > >>EIP; c01ccf91<= > Trace; c01ccfe0 This is really odd. It looks like sh->hash_next == -1. But, sh->hash_next is only ever set from ->hash_next for some other sh, by the line *sh->hash_pprev = sh->hash_next; in remove_hash, or to an entry from the stripe_hashtbl array. and stripe_hashtbl[] is only ever set to the address of a stripe_head, or to the value of a sh->hash_next, or to zero at initialisation. Or in short "this cannot happen" :-) Is there any chance of a memory error? Has this happened more than once? NeilBrown - 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.0.37 crashes immediately
On Wed, 17 Jan 2001, Stefan Ring wrote: >Date: Wed, 17 Jan 2001 00:35:39 +0100 (MET) >From: Stefan Ring <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Content-Type: TEXT/PLAIN; charset=US-ASCII >Subject: 2.0.37 crashes immediately > >2.0.37+ kernels crash even before I can see the "Uncompressing linux..." >message. I use the same configuration for 2.0.36 and 2.0.37 (basically >it's the default configuration without anything interesting changed), and >the latter just won't work. It also doesn't matter if I use zImage or >bzImage. Kernel compiled with a stock redhat 4.2 (gcc 2.7.2.1). My machine >configuration is as follows: Holy ancient and unsupported kernel + distribution batman. ;o) Have you tried 2.0.39 (said with a slight grin) ;o) Seriously, why not upgrade to Red Hat 7.0? You'll get a lot more help with any troubles you may have. Subscribe to the Red Hat guinness-list and I'd be glad to help with such a transition. Good luck! -- Mike A. Harris - Linux advocate - Free Software advocate This message is copyright 2001, all rights reserved. Views expressed are my own, not necessarily shared by my employer. -- If it weren't for C, we'd all be programming in BASI and OBOL. - 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: Can't compile shmem.c in 2.4.0-ac9
My apologies I see this was already encountered and a patch submitted. 2.4.0-pre8 builds OK for me. Mike -- Michael D. Crawford GoingWare Inc. - Expert Software Development and Consulting http://www.goingware.com/ [EMAIL PROTECTED] Tilting at Windmills for a Better Tomorrow. - 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: Blank screen in X after heavy disk access (2.4 only)
On Tue, 16 Jan 2001, Rodney M. Jokerst wrote: > Yes, I have the same motherboard / chipset. Thanks for your help! > > Rodney M. Jokerst > > On Tue, 16 Jan 2001, Nathan Thompson wrote: > > > On Tue, Jan 16, 2001 at 03:11:01PM -0600, Rodney M. Jokerst wrote: > > > This action causes my screen to go blank in X and remain blank > > > unless I move the mouse or type on the keyboard. The second I stop doing > > > one of these activities, it goes blank again. While it is blank, it seems > > > to be flashing every second, as if it is recieving blank screen commands > > > repeatedly. This behavior continues until I restart the machine. If I > > > switch to a console, everything is fine. If I restart the X server, the > > > behavior continues. > > > > Is this a VIA chipset based motherboard? > > > > If so someone (Vojtech Pavlik ?) has a patch that helps this... > > It is a hardware error. > > > > For what it's worth I have seen this exact same behavior on my machine > > in 2.2.x. I think the work around patch was included in 2.2.19pre2, does it still occur with that or later 2.2 kernels? > > > > I have an abit ka7 motherboard, via kx133 chipset. I have the same board. Can someone point me to the patch for 2.4? This is a problem for me because it requires a reboot to fix and who likes rebooting? :) btw: I have received several private emails from people having this problem, (so it is biting people). Just a polite beg that it might be included in 2.4. Cheers, shane - 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/
eepro100 error messages
Message from syslogd@zeus at Tue Jan 16 00:17:29 2001 ... zeus kernel: 00 to4 0 0 0 0011001. Message from syslogd@zeus at Tue Jan 16 00:26:38 2001 ... zeus kernel: 0:0: 0:0:0: 0: 0:0: 0:0: 0:0: 0:0:0: 0:0:0: 0:0: 0:0: 0 ind. Message from syslogd@zeus at Tue Jan 16 00:49:15 2001 ... zeus kernel: 1.0.00.01 ether 1HY i0 >tePHY index 1 register 5 is 41e1. Hello, Does anybody know what the exact cause for the following messages is: Jan 16 00:49:04 cd20 kernel: eth0: card reports no resources. Jan 16 00:49:06 cd20 kernel: eth0: can't fill rx buffer (force 0)! Jan 16 00:49:06 cd20 kernel: eth0: restart the receiver after a possible hang. Jan 16 00:49:06 cd20 kernel: eth0: can't fill rx buffer (force 1)! Jan 16 00:49:06 cd20 kernel: eth0: can't fill rx buffer (force 0)! Jan 16 00:49:06 cd20 kernel: eth0: card reports no resources. Jan 16 00:49:08 cd20 kernel: eth0: can't fill rx buffer (force 0)! Jan 16 00:49:08 cd20 kernel: eth0: restart the receiver after a possible hang. Jan 16 00:49:09 cd20 kernel: eth0: can't fill rx buffer (force 0)! Jan 16 00:49:09 cd20 kernel: eth0: can't fill rx buffer (force 1)! Jan 16 00:49:09 cd20 kernel: eth0: card reports no resources. Jan 16 00:49:09 cd20 kernel: eth0: can't fill rx buffer (force 0)! Jan 16 00:49:09 cd20 kernel: eth0: restart the receiver after a possible hang. Jan 16 00:49:09 cd20 kernel: eth0: can't fill rx buffer (force 0)! Jan 16 00:49:09 cd20 kernel: eth0: card reports no resources. Jan 16 00:49:12 cd20 kernel: 000ca000. Jan 16 00:49:12 cd20 kernel: eth0: can't fill rx buffer (force 1)! Jan 16 00:49:12 cd20 last message repeated 6 times Jan 16 00:49:12 cd20 kernel: eth0: can't fill rx buffer (force 0)! Jan 16 00:49:12 cd20 kernel: eth0: can't fill rx buffer (force 1)! Jan 16 00:49:13 cd20 last message repeated 15 times Jan 16 00:49:13 cd20 kernel: eth0: can't fill rx buffer (force 0)! Jan 16 00:49:13 cd20 kernel: eth0: can't fill rx buffer (force 1)! Jan 16 00:49:13 cd20 last message repeated 7 times Jan 16 00:49:13 cd20 kernel: eth0: card reports no resources. Jan 16 00:49:13 cd20 kernel: eth0: can't fill rx buffer (force 1)! Jan 16 00:49:13 cd20 last message repeated 7 times Jan 16 00:49:13 cd20 kernel: 000ca000. Jan 16 00:49:13 cd20 kernel: eth0: can't fill rx buffer (force 1)! Hello there, Does anyone know the cause and a potential fix for the following error messages reported in syslogd by my eepro100 card? The machine is running under heavy CPU + memory + network load. It seems that the card has problems finding the required resources. Is there a way to "guarantee" that the card will have the necessary resources even at high loads? I'm using kernel version 2.2.14. Thank you, Sincerely Kostas Nikoloudakis Jan 16 00:49:13 cd20 kernel: eth0: card reports no resources. Jan 16 00:49:15 cd20 kernel: eth0: can't fill rx buffer (force 0)! Jan 16 00:49:15 cd20 kernel: eth0: restart the receiver after a possible hang. Jan 16 00:49:15 cd20 kernel: eth0: can't fill rx buffer (force 0)! Jan 16 00:49:15 cd20 kernel: eth0: can't fill rx buffer (force 1)! Jan 16 00:49:15 cd20 last message repeated 6 times Jan 16 00:49:15 cd20 kernel: 000ca000. Jan 16 00:49:15 cd20 kernel: eth0: can't fill rx buffer (force 1)! Jan 16 00:49:15 cd20 last message repeated 16 times Jan 16 00:49:15 cd20 kernel: 0 t4 20.0020.020002020. Jan 16 00:49:15 cd20 kernel: 1.0.00.01 ether 1HY i0 >tePHY index 1 register 5 is 41e1. - 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/
Can't compile shmem.c in 2.4.0-ac9
I get the following errors trying to build 2.4.0-ac9 just now. I'll send you my .config upon request, or post it on my website gcc -D__KERNEL__ -I/home/mike/Kernel/linux/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -march=i686-c -o shmem.o shmem.c shmem.c:971: `shmem_readlink' undeclared here (not in a function) shmem.c:971: initializer element for `shmem_symlink_inode_operations.readlink' is not constant shmem.c:972: `shmem_follow_link' undeclared here (not in a function) shmem.c:972: initializer element for `shmem_symlink_inode_operations.follow_link' is not constant shmem.c:973: initializer element for `shmem_symlink_inode_operations' is not constant shmem.c:973: initializer element for `shmem_symlink_inode_operations' is not constant make[2]: *** [shmem.o] Error 1 make[2]: Leaving directory `/home/mike/Kernel/linux/mm' make[1]: *** [first_rule] Error 2 make[1]: Leaving directory `/home/mike/Kernel/linux/mm' make: *** [_dir_mm] Er Mike -- Michael D. Crawford GoingWare Inc. - Expert Software Development and Consulting http://www.goingware.com/ [EMAIL PROTECTED] Tilting at Windmills for a Better Tomorrow. - 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: Compiling 2.4.1-preX series
Fair enough, but something in bugs.h changed from 2.4.0 to 2.4.1-preX and
broke my GCC, I shall recompile GCC with no PGCC patches however if this
happens still then there's a problem somewhere.
I dont know what FXSR is but there was no problem in 2.4.0 with this.
diff include/asm-i386/bugs.h ../linux/include/asm-i386/bugs.h |
more78a79
> #if defined(CONFIG_X86_FXSR) || defined(CONFIG_X86_RUNTIME_FXSR)
82,85c83,85
< if (offsetof(struct task_struct, thread.i387.fxsave) & 15) {
< extern void __buggy_fxsr_alignment(void);
< __buggy_fxsr_alignment();
< }
---
> if (offsetof(struct task_struct, thread.i387.fxsave) & 15)
> panic("Kernel compiled for PII/PIII+ with FXSR, data not 16-byte
aligned!");
>
90a91,92
Jes Sorensen wrote:
> > "Shawn" == Shawn Starr <[EMAIL PROTECTED]> writes:
>
> Shawn> Which compiler will compile the 2.4.1-preX series? Since 2.4.0,
> Shawn> my GCC 2.95.2 patched with PGCC 2.95.3 (which creates
> Shawn> pgcc-2.95.2) refuses to compile any versions after this. Which
> Shawn> is the next stable and binary compatable compiler?
>
> Shawn> Anyone have any suggestions? I dont wish to use the development
> Shawn> GCC 2.96/2.97 because they will break my binary compatability
> Shawn> with pgcc-2.95.2/3.
>
> Yes, it's simple you want the real gcc 2.96/2.97 or egcs-1.1.2. pgcc
> is not supported.
>
> Jes
-
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: Compiling 2.4.1-preX series
> "Shawn" == Shawn Starr <[EMAIL PROTECTED]> writes: Shawn> Which compiler will compile the 2.4.1-preX series? Since 2.4.0, Shawn> my GCC 2.95.2 patched with PGCC 2.95.3 (which creates Shawn> pgcc-2.95.2) refuses to compile any versions after this. Which Shawn> is the next stable and binary compatable compiler? Shawn> Anyone have any suggestions? I dont wish to use the development Shawn> GCC 2.96/2.97 because they will break my binary compatability Shawn> with pgcc-2.95.2/3. Yes, it's simple you want the real gcc 2.96/2.97 or egcs-1.1.2. pgcc is not supported. Jes - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
[Michael Meissner] > Ummm, I just reread the 2.4 Changes file once again just to be sure, > and it did not cover this issue. So how the *$@% are people supposed > to "read some docs" to know about this, if the docs don't mention the > information. I know people have been complaining about this change > since at least the fall time frame. SCSI host probe order has never been guaranteed, afaik -- this is not new to 2.4. If you have multiple host adapters, you really need to use the command line to say which is which, as always. If you don't, you will be bitten eventually. "Eventually" in this case meant 2.2->2.4, perhaps, but that doesn't make it an item for Documentation/Changes. Or is this not what you were talking about? Peter - 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: named streams, extended attributes, and posix
[Peter Samuelson] > > What if you copy both 'filename' and 'filename:ext' onto the same > > fs? Do they get combined into one file? [Michael Rothwell] > ON Ext2, you get two files. On NTFS, you get one file, and a stream > on that file. Yeah. I think that's broken. It gets worse when you start doing other posixy things. Say you do 'mv foo bar:baz' on an ntfs partition. Those strong in the force will recall that rename() is supposed to atomically unlink 'bar:baz'. Instead you seem to be asking it to add an extra stream to 'bar'. So should we still unlink the old 'bar'? And then what if 'foo' is a multi-stream file? Where do the extra streams go? Or do you just get a big fat -EINVAL for every special case? I think ultimately there is no posixy (or least-surprise) way to deal with such things. If we truly need forks, we need a new api to manipulate them. Cleverness with ':' or '/' only takes you so far. Peter - 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: eth1: Transmit timed out, status 0000, PHY status 0000
On Tue, 16 Jan 2001, Urban Widmark wrote: >Date: Tue, 16 Jan 2001 23:59:33 +0100 (CET) >From: Urban Widmark <[EMAIL PROTECTED]> >To: richard.morgan9 <[EMAIL PROTECTED]> >Cc: Mike A. Harris <[EMAIL PROTECTED]>, > Linux Kernel mailing list <[EMAIL PROTECTED]> >Content-Type: TEXT/PLAIN; charset=US-ASCII >Subject: Re: eth1: Transmit timed out, status , PHY status > >On Tue, 16 Jan 2001, richard.morgan9 wrote: > >> I have the same problem as Urban with a recent DLink 530tx >> (rhine2). Pulling the power cable from my atx psu (while the >> computer was "off") fixed the card, until my next reboot from >> win98. > >I'm not the one with a problem but maybe it has something to do with win98 >and/or the driver used there. I intend to test this myself eventually and >see if I can do something based on Donald Beckers suggestions on eeprom. > >Unless someone else feels like playing with this ... anyone? > >Does everyone seeing this have a Rhine-II, pci id 1106:3065, and not the >older chip found in dfe530tx with pci id 1106:3043? 00:12.0 Ethernet controller: VIA Technologies, Inc.: Unknown device 3065 (rev 42) Subsystem: D-Link System Inc: Unknown device 1400 Flags: bus master, medium devsel, latency 32, IRQ 10 I/O ports at e800 Memory at e700 (32-bit, non-prefetchable) Expansion ROM at e600 [disabled] Capabilities: [40] Power Management version 2 00:13.0 Ethernet controller: Winbond Electronics Corp W89C940 Flags: medium devsel, IRQ 12 I/O ports at ec00 And I do not have drivers for the dlink card in win98. The 2 cards are in my workstation, one goes to my firewall @ 10Mbit and the other to my build/devel machine at 100mbit which 98 doesn't get to see. It is sure interested in the card at boot time though... EVERY time... ;o( -- Mike A. Harris - Linux advocate - Free Software advocate This message is copyright 2001, all rights reserved. Views expressed are my own, not necessarily shared by my employer. -- Windows 95(n) - 32-bit extensions and graphical shell for a 16-bit patch to an 8-bit operating system originally coded for a 4-bit microprocessor, written by a 2-bit company that can't stand 1 bit of competition. - 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: named streams, extended attributes, and posix
> What if you copy both 'filename' and 'filename:ext' onto the same fs? > Do they get combined into one file? ON Ext2, you get two files. On NTFS, you get one file, and a stream on that file. > Any semantics by which 'filename:stream' and 'filename' refer to the > same file would be b0rken. If instead you use 'filename/stream' That does not allow streams on directories, otherwise I agree. -M - 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: int. assignment on SMP + ServerWorks chipset
On Tue, 16 Jan 2001, [EMAIL PROTECTED] wrote:
>
> On Mon, 15 Jan 2001, Randy.Dunlap wrote:
> >
> > A Linux-USB user (pem@ = Petr) reported that USB (OHCI) wasn't
> > working on his Intel STL2 system. This system uses a ServerWorks
> > chipset, hence the OHCI part.
>
> Does it work with "noapic"?
>
> It is entirely possible that we should try to use the pirq tables even
> with the apic, and just make sure that we use the untranslated PCI irq
> number for testing etc.
>
This may actually be an MP BIOS bug...
According to the boot log, the MP table I/O Interrupt entry for the
USB controller (PCI device 00:0f:02) is:
Int: type 0, pol 3, trig 3, bus 0, IRQ 3c, APIC ID 5, APIC INT 00
Which specifies the destination APIC ID 5 (corresponding to the 2nd
IO-APIC, used solely to distribute PCI interrupts) and destination INT
pin 0. So when the IO-APICs are programmed this IRQ is remapped to:
PCI->APIC IRQ transform: (B0,I15,P0) -> 16
The problem is the USB Interrupt is internally routed and should use
the ISA IO-APIC for the destination APIC, and a valid ISA IRQ for the
destination INT. The MP table entry and corresponding IRQ transform
should look something like this:
[I used INT 09 simply because it wasn't already assigned...]
Int: type 0, pol 3, trig 3, bus 0, IRQ 3c, APIC ID 4, APIC INT 09
PCI->APIC IRQ transform: (B0,I15,P0) -> 9
Here's a patch to find & correct this entry on boot. Its not pretty,
and should ONLY be used to verify this particular fix--any real solution
will have to be done in the BIOS. (there doesn't seem to be an easy way
to alter specific MP table entries outside of the BIOS, especially if
they happen to exist in write-protected memory regions...)
There may be bogus data in the PIRQ table as well, which is why this
explicitly routes the interrupt & sets the ELCR. If you enable DEBUG
in pci-i386.h and re-send the dmesg output I will look it over.
-duncan
--- linux/arch/i386/kernel/mpparse.cTue Nov 14 22:25:34 2000
+++ linux~/arch/i386/kernel/mpparse.c Tue Jan 16 17:11:07 2001
@@ -237,6 +237,37 @@
m->mpc_irqtype, m->mpc_irqflag & 3,
(m->mpc_irqflag >> 2) & 3, m->mpc_srcbus,
m->mpc_srcbusirq, m->mpc_dstapic, m->mpc_dstirq);
+
+
if ((m->mpc_irqtype == 0) && ((m->mpc_irqflag & 3) == 3) &&
+
((m->mpc_irqflag >> 2) == 3) && (m->mpc_srcbus == 0) &&
+
(m->mpc_dstapic == 5) && (m->mpc_srcbusirq == 0x3c))
+
{
+
struct mpc_config_intsrc usbint = { MP_INTSRC,
+
0x00, 0x000f, 0x00,
+
0x3c, 0x04, 0x09 };
+
unsigned char mask = 1 << (usbint.mpc_dstirq & 7);
+
unsigned int port = 0x4d0 + (usbint.mpc_dstirq >> 3);
+
unsigned char val = inb(port);
+
+
Dprintk("MP BIOS bug, USB INT should use ISA IO-APIC!\n");
+
+
/* fix PIRQ routing entry: index 1 -> dstirq */
+
outb_p(1, 0xc00);
+
outb_p(usbint.mpc_dstirq, 0xc01);
+
if (!(val & mask))
+
outb(val|mask, port);
+
+
/* use modified intsrc struct */
+
mp_irqs[mp_irq_entries] = usbint;
+
+
Dprintk("Int: type %d, pol %d, trig %d, bus %d,"
+
" IRQ %02x, APIC ID %x, APIC INT %02x\n",
+
usbint.mpc_irqtype, usbint.mpc_irqflag & 3,
+
(usbint.mpc_irqflag >> 2) & 3,
+
usbint.mpc_srcbus, usbint.mpc_srcbusirq,
+
usbint.mpc_dstapic, usbint.mpc_dstirq);
+
}
+
if (++mp_irq_entries == MAX_IRQ_SOURCES)
panic("Max # of irq sources exceeded!!\n");
}
-
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/
Compiling 2.4.1-preX series
Which compiler will compile the 2.4.1-preX series? Since 2.4.0, my GCC 2.95.2 patched with PGCC 2.95.3 (which creates pgcc-2.95.2) refuses to compile any versions after this. Which is the next stable and binary compatable compiler? Anyone have any suggestions? I dont wish to use the development GCC 2.96/2.97 because they will break my binary compatability with pgcc-2.95.2/3. Thanks, Shawn Starr. - 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/
/proc/PID/stat format
What is the format of /proc/PID/stat for 2.2.x? In particular I'm interested in knowing start time of a process. Thanks - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Does reiserfs really meet the "Linux-2.4.x patch submissionpolicy"?
On Tue, 16 Jan 2001, Aaron Lehmann wrote: > On Tue, Jan 16, 2001 at 08:55:58PM +0100, Andr? Dahlqvist wrote: > > I was very surprised when I checked my local kernel.org mirror this > > morning, and noticed that the latest 2.4.1 pre-patch had grown to > > ~180 kb in size. I was even more surprised when I realized that the > > inclusion of reiserfs was the reason for this. > > On a related note, how about XFS? It certainly shouldn't go in before > the developers are ready, but I've been using it without any problems > for awhile now and await its inclusion in the mainstream kernel. Note that ResierFS really is a fairly special case: it's been one of the main filesystems at SuSE for a longish time, and of the journalling filesystems it's the only one I know of that is in major real production use already, and has been for some time. There's no question that there are other Journalling filesystems on the horizon, but I'm not hearing anybody who can't do the patching themselves who is interested in using it. Remember: one of the main criteria for 2.4.x inclusion was the "vendor would want it" part. If it's a "developers might want to play with it" kind of thing, then it might as well live as an external patch for a while. For that reason, I would expect Ext3 to be the next filesystem to be integrated, but I would _also_ expect that RedHat will actually integrate it into their kernel _first_, and expect me to integrate it into the standard kernel only afterwards. But no, vendors aren't everything. And there are other vendors than just SuSE and RedHat. So take all of the above with a pinch of salt. And remember: these are just the 2.4.x rules - it's a different game when the development kernel opens again, and "vendor wishes" are much less of an issue when that happens. In the meantime, I see the stable kernel mainly as a way to support vendors, and am thus always weighing things from that angle when worrying about 2.4.x features. 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: Does reiserfs really meet the "Linux-2.4.x patch submission policy"?
On Tue, Jan 16, 2001 at 08:55:58PM +0100, Andr? Dahlqvist wrote: > I was very surprised when I checked my local kernel.org mirror this > morning, and noticed that the latest 2.4.1 pre-patch had grown to > ~180 kb in size. I was even more surprised when I realized that the > inclusion of reiserfs was the reason for this. On a related note, how about XFS? It certainly shouldn't go in before the developers are ready, but I've been using it without any problems for awhile now and await its inclusion in the mainstream kernel. PGP signature
Re: Linux not adhering to BIOS Drive boot order?
On Wed, Jan 17, 2001 at 12:32:05AM +0100, J . A . Magallon wrote: > If that is your idea of the average user... You're a system administrator, > you can have tons of scsi cards in your system if you want. > > You want to make things SOOO easy for a 'dummy' user, and that user will never > use them. The average user you are targetting says: 'daddy, buy me a PC to > run Quake and do my school jobs' or 'please, dear vendor, I want a PC to > do my housekeeping'. I have seen so many cases (A buys PC, A tries to run > brand new racing game that does not work, A goes shop and says: don't know > what's wrong with this PC, look at it and call me when MyCarRacingGame > works...). I also don't want things so complex for the people who need to do complex things, that they give up in frustration with Linux and use something else like *BSD, particularly when things are changed from the previous way they were done in Linux. I agree things should be simple for simple configurations, but that does not mean we should be throwing boat anchors and couches in the paths of people who have more complex hardware. > Average users you are targetting with that automagical > card detection even do not know there are SCSI and IDE disks. They just > want a 30Gb ide disk to install linux and play. If they involve with SCSI > and ID numbers and multiple cards and so on they can read some docs and > rebuild a kernel. Ummm, I just reread the 2.4 Changes file once again just to be sure, and it did not cover this issue. So how the *$@% are people supposed to "read some docs" to know about this, if the docs don't mention the information. I know people have been complaining about this change since at least the fall time frame. -- Michael Meissner, Red Hat, Inc. (GCC group) PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA Work: [EMAIL PROTECTED] phone: +1 978-486-9304 Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482 - 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] maestro3 oops + fix (for ac9!)
> D'oh, looks like if power management is disabled, pmdev is NULL (I get > that message when I load the module), but we try to derefence it anyways. > The fix is obvious: duh, yeah, I'll send out a proper patch that handles the pm_register failure too. thanks. -- zach - 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: named streams, extended attributes, and posix
[Michael Rothwell] > It seems that if you move a file with a colon -- "file:colon" -- in > the name from Ext2 to "StreamFS," you would end up with a file named > "file" with a stream named "colon". When copying back, you would get > "file:colon" back. What if you copy both 'filename' and 'filename:ext' onto the same fs? Do they get combined into one file? That to me violates principle of least surprise. The fs should just mangle filenames it doesn't agree with, like the existing legacy filesystems already do. Any semantics by which 'filename:stream' and 'filename' refer to the same file would be b0rken. If instead you use 'filename/stream' syntax, at least that is an illegal filename on *all* Linux filesystems, so this particular point of confusion does not come up. Peter - 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/
What happened to merge_segments()?
Can someone tell me what happened to the merge_segments() function in mm/mmap.c? I was using it in my Wine accelerator module, but it's no longer present. Cheers, David - 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.0.37 crashes immediately
On Wed, 17 Jan 2001, Stefan Ring wrote: > 2.0.37+ kernels crash even before I can see the "Uncompressing linux..." > message. I use the same configuration for 2.0.36 and 2.0.37 (basically > it's the default configuration without anything interesting changed), and > the latter just won't work. It also doesn't matter if I use zImage or > bzImage. Kernel compiled with a stock redhat 4.2 (gcc 2.7.2.1). My machine > configuration is as follows: > > ASUS CUBX-E MB > PIII Coppermine > 512MB SDRAM > 3c905-tx > guillemot tnt2 m64 > ibm dtla-307030 & 305020, quantum fireball ex 6.4 Is there a reason you are using a relatively new machine like that with such an outdated and arcane kernel (and distribution, for that matter)? I'd suggest you upgrade to a more recent kernel and/or distribution...it'll be a lot more stable (and not to mention secure!) Good luck to you! Kelsey Hudson [EMAIL PROTECTED] Software Engineer Compendium Technologies, Inc (619) 725-0771 --- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
On Wed, 17 Jan 2001, J . A . Magallon wrote: > You want to make things SOOO easy for a 'dummy' user, and that user will never > use them. The average user you are targetting says: 'daddy, buy me a PC to > run Quake and do my school jobs' or 'please, dear vendor, I want a PC to > do my housekeeping'. I have seen so many cases (A buys PC, A tries to run > brand new racing game that does not work, A goes shop and says: don't know > what's wrong with this PC, look at it and call me when MyCarRacingGame > works...). Yup. Dummies dont need things to be done for them; they need to learn how to do it themselves. That, IMO, is the beauty of UNIX. Nothing is sugar coated, and almost everything gets back down to the K.I.S.S. approach. > Average users you are targetting with that automagical > card detection even do not know there are SCSI and IDE disks. They just > want a 30Gb ide disk to install linux and play. If they involve with SCSI > and ID numbers and multiple cards and so on they can read some docs and > rebuild a kernel. Amen! I couldn't have said it better myself. Kelsey Hudson [EMAIL PROTECTED] Software Engineer Compendium Technologies, Inc (619) 725-0771 --- - 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/
console spin_lock
Some time ago a intel i810 framebuffer driver was written. It only worked
for 2.2.X. With 2.4.X a spinlock is used in the upper layers of the
console system. Sooner or later we are going to run into the situtation
where we will have graphics hardware which has no vga core and wih be
purely DMA/irq based (i.e i810). In this case using the current
console_lock will block the driver itself. I have thought about a
possible solution. A semaphore can't be used since their is a spin_lock
in the console_softirq. Since this is in a interrupt context a
semaphore can't be used. Another idea was to do a
void get_vc_lock(void)
{
while (test_and_set_bit(0, _var))
;
}
Any better ideas?
-
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] sendpath() support, 2.4.0-test3/-ac9
On Tue, 16 Jan 2001, Ingo Molnar wrote: > > On Mon, 15 Jan 2001, dean gaudet wrote: > > > > just for kicks i've implemented sendpath() support. > > > > > > _syscall4 (int, sendpath, int, out_fd, char *, path, off_t *, off, size_t, size) > > > > hey so how do you implement transmit timeouts with sendpath() ? > > (i.e. drop the client after 30 seconds of no progress.) > > well this problem is not unique to sendpath(), sendfile() has it as well. hrm? with sendfile() i just send 32k or 64k at a time and use alarm() or non-blocking/select() to implement timeouts. with sendpath() i can do the same thing but i'm gonna pay a path lookup each time... and there's no guarantee that i'm getting the same file each time. > in TUX i've added per-socket connection timers, and i believe something > like this should be done in Apache as well - timers are IMO not a good > enough excuse for avoiding event-based IO models and using select() or > poll(). i wasn't suggesting avoiding sendfile/sendpath -- i just couldn't see how to use sendpath() effectively. explain per-socket connection timers. are they available to the userland? at least with the apache-2.0 i/o stuff i should be able to support kernel-based timers. apache-2.0 uses non-blocking/poll() to implement timeouts -- does write() or sendfile() until there's an EWOULDBLOCK then it calls poll() waiting for write/timeout. with kernel supported timeouts i could just block in the write() and that'd be fine by me. 1.2 used alarm() ... 1.3 communicates each child's activity to the parent through the scoreboard and the parent occasionally wakes up and sends SIGALRM to children that are past their timeout. (that let me get rid of a few syscalls.) -dean - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
On Tue, 16 Jan 2001, Michael Meissner wrote: > > you're forgetting that in /etc/lilo.conf there is a directive called > > 'append='... all the user has to do is merely add > > 'append="scsihosts=whatever,whatever"' into their config file and rerun > > lilo. problem solved > > That's assuming you are using lilo. Not everybody does or can use lilo, please > don't assume that the way your system gets booted is the way everybody's does, > particularly those on platforms other than the x86. And I wasn't assuming that. There are several bootloaders for intel alone, eg syslinux and grub, to name a couple. sparc has silo, alpha has something elsewhatever. > I must say, as a 5 year Linux user (and 23 year UNIX user/administrator), I do > get tired of having to hunt down and deal with each of these changes that come > up from time to time with Linux (ie, switching from ipfwadm to ipchains to > netfilter, or in this case reordering how scsi adapters/network adapters are > looked up). I've been a Linux user/administrator for 3 years now. Before that I worked on and administered UNIX machines for about 10 years, including SunOS, HP/UX, and AIX. If you think that Linux is the only operating system to undergo vast changes like that you're wrong: look at the SunOS to Solaris switchBasically the same operating system, no? However, many things were differentOK its off topic but im sure you get the idea. > > besides, how many 'end-users' do you know of that will have multiple scsi > > adapters in one system? how many end-users -period- will have even a > > *single* scsi adapter in their systems? do we need to bloat the kernel > > with automatic things like this? no... i think it is handled fine the way > > it is. if the user wants to add more than one scsi adapter into his > > system, let him read some documentation on how to do so. (is this even a > > documented feature? if not, i think it should be added to the docs...) > > I'm an end-user, and I have 3 scsi-adapters of two different brands in my > system. Many of the people using Linux in high end things like servers, > etc. will have multiple scsi controlers. People are using Linux in lots of > things from small embedded devices to large systems, and Linux needs to address > needs in every area. see, thats where you and i disagree...I wouldn't call you an end user based upon that fact. End users (IMO) are those people who sit back and buy a PC and expect it to Just Work(tm). Servers, embedded devices, et al (read: high-end applications) do not equate to end-user applications, IMNSHO. Besides, *most* (and I say most because I've seen a sharp decline in the mentality of Linux users as of late) people who are going to manage a high-scale server are going to know what the hell they are doing in the first place, so I highly doubt that the end-user argument holds merit against this. Linux, whether you like it or not, is a full-scale UNIX. It takes a good (read: talented) system administrator to manage any UNIX properly...A good sysadmin reads documentationSeems clear enough to me. But, then again, this is coming from an experienced sysadmin so my opinion *must* be biased. Talk to you later, Kelsey Hudson [EMAIL PROTECTED] Software Engineer Compendium Technologies, Inc (619) 725-0771 --- - 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: lance.c @ 100Mbit
Thanks to all who pointed out the pcnet32.c driver! (And quickly, too. Perhaps one day I'll learn to do a "grep -i 79C973 drivers/net/*" first. *sigh*) Now to see if I can get it to work on an ARM-based system...gotta love lack of cache-coherance. ;) (dma_cache_inv, etc.) I'm open to suggestions on that as well. :) Thanks again! Eli . "To the systems programmer, users and applications Eli Carter | serve only to provide a test load." [EMAIL PROTECTED] `-- (random fortune) - 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.0.37 crashes immediately
2.0.37+ kernels crash even before I can see the "Uncompressing linux..." message. I use the same configuration for 2.0.36 and 2.0.37 (basically it's the default configuration without anything interesting changed), and the latter just won't work. It also doesn't matter if I use zImage or bzImage. Kernel compiled with a stock redhat 4.2 (gcc 2.7.2.1). My machine configuration is as follows: ASUS CUBX-E MB PIII Coppermine 512MB SDRAM 3c905-tx guillemot tnt2 m64 ibm dtla-307030 & 305020, quantum fireball ex 6.4 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
On 2001.01.16 Michael Meissner wrote: > On Tue, Jan 16, 2001 at 12:01:12PM -0800, Dr. Kelsey Hudson wrote: > > On Tue, 16 Jan 2001, Venkatesh Ramamurthy wrote: .. > > besides, how many 'end-users' do you know of that will have multiple scsi > > adapters in one system? how many end-users -period- will have even a > > *single* scsi adapter in their systems? do we need to bloat the kernel > > with automatic things like this? no... i think it is handled fine the way > > it is. if the user wants to add more than one scsi adapter into his > > system, let him read some documentation on how to do so. (is this even a > > documented feature? if not, i think it should be added to the docs...) > > I'm an end-user, and I have 3 scsi-adapters of two different brands in my > system. Many of the people using Linux in high end things like servers, > etc. will have multiple scsi controlers. People are using Linux in lots of > things from small embedded devices to large systems, and Linux needs to > address > needs in every area. > If that is your idea of the average user... You're a system administrator, you can have tons of scsi cards in your system if you want. You want to make things SOOO easy for a 'dummy' user, and that user will never use them. The average user you are targetting says: 'daddy, buy me a PC to run Quake and do my school jobs' or 'please, dear vendor, I want a PC to do my housekeeping'. I have seen so many cases (A buys PC, A tries to run brand new racing game that does not work, A goes shop and says: don't know what's wrong with this PC, look at it and call me when MyCarRacingGame works...). Average users you are targetting with that automagical card detection even do not know there are SCSI and IDE disks. They just want a 30Gb ide disk to install linux and play. If they involve with SCSI and ID numbers and multiple cards and so on they can read some docs and rebuild a kernel. -- J.A. Magallon $> cd pub mailto:[EMAIL PROTECTED] $> more beer Linux werewolf 2.4.0-ac9 #2 SMP Sun Jan 14 01:46:07 CET 2001 i686 - 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/
[Fwd: Is sendfile all that sexy? (fwd)]
> : >Agreed -- the hard-coded Nagle algorithm makes no sense these days. > : > : The fact I dislike about the HP-UX implementation is that it is so > : _obviously_ stupid. > : > : And I have to say that I absolutely despise the BSD people. They did > : sendfile() after both Linux and HP-UX had done it, and they must have > : known about both implementations. And they chose the HP-UX braindamage, > : and even brag about the fact that they were stupid and didn't understand > : TCP_CORK (they don't say so in those exact words, of course - they just > : show that they were stupid and clueless by the things they brag about). > : > : Oh, well. Not everybody can be as goodlooking as me. It's a curse. nor it would seem, as humble :) Hello Linus, my name is Rick Jones. I am the person at Hewlett-Packard who drafted the "so _obviously_ stupid" sendfile() interface of HP-UX. Some of your critique (quoted above) found its way to my inbox and I thought I would introduce myself to you to give you an opportunity to expand a bit on your criticism. In return, if you like, I would be more than happy to describe a bit of the history of sendfile() on HP-UX. Perhaps (though I cannot say with any certainty) it will help explain why HP-UX sendfile() is spec'd the way it is. rick jones never forget what leads to the downfall of the protagonist in Greek tragedy... -- ftp://ftp.cup.hp.com/dist/networking/misc/rachel/ these opinions are mine, all mine; HP might not want them anyway... :) feel free to email, OR post, but please do NOT do BOTH... my email address is raj in the cup.hp.com domain... - 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: Locking problem in 2.2.18/19-pre7? (fs/inode.c and fs/dcache.c)
On Tue, Jan 16, 2001 at 12:10:31PM -0800, Theodore Y. Ts'o wrote: > Actually, looking at the fast path of down_trylock compared to huge mess > of code that's currently there, I actually suspect that using > down_trylock() would actually be faster, since in the fast path case > there would only two assembly language instructions, whereas the code The fast path of the current code never hits the "huge mess" (aka wait_event done with a seralizing spinlock). The main difference is that down() is using an atomic logic, while `int block' runs out of order and it's serialized only by the spinlock. I personally prefer current version because serializing instructions are usually more expensive and I don't consider "huge mess" the wait event interface as it makes perfect sense there IMHO. > Ah, OK. Well, we're currently tracking down a slow inode leak which is > only happening on SMP machines, especially our mailhubs. It's gradual, How long does it takes to reproduce? BTW, I assume you can reproduce also with vanilla 2.2.x latest kernels. I suspect that the problem is the caller that is missing an iput or dput. (it maybe also an userspace application, just check that nothing gets fixed by SYSRQ+I before using the Big Red Button) Note also that killing all apps won't decrease of 1 the number of inodes allocated. The inodes allocated will _never_ shrink (that's why we need the hard limit inode-max). Deleting all in-use inodes is the only way to have them to showup in the freelist (and they still won't be freed but at least you'll see that they're not leaked somewhere ;). So the debugging isn't very friendly unless you play with the sources (2.4.x is much better). > but if you don't reboot the machine before you run out of inodes, it > will print the "inode-max limit reach" message, and then shortly after > that lock up the entire machine locks up until someone can come in and > hit the Big Red Button. Monitoring the machine before it locks up, we If SYSRQ+I doesn't help, can you try to reproduce with vanilla 2.2.19pre7aa1 (that also sets the inode-max and the inode-hash to a rasonable value for big boxes, and it fixes the inode-hash function to avoid huge collisions)? Recent 2.2.xaa are running on the same heavily loaded SMP boxes that was able to reproduce the common code inode leak we had in mid 2.2.x. They doesn't show problems anymore since the last fix (that is the one we discussed in this thread). So I tend to believe this could be a bug in some non-common or unofficial piece of code or in userspace. But hey, this is just a guess. > the machine died. (Yeah, we could put a reboot command into crontab, > but you should only need to do hacks like that on Windows NT machines. > :-) ;) Andrea - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: super_operations in -pre7
Mattew Wilcox writes: > several new operations have been added to super_operations, presumably > as part of the reiserfs merge. write_super_lockfs and unlockfs are > never called. can we remove them? These operations were added to co-ordinate filesystem backups/snapshots for journalling filesystems (especially in conjunction with LVM). At some point in the future ext3 will also be using them. However, (only having looked at preliminary patches, and not the final 2.4.1-pre reiserfs merge) it is bad to insert them in the middle of the super_operations struct at this point, as it breaks every filesystem that isn't part of the kernel. That said, the addition of (reiserfs-specific) read_inode2 and dirty_inode pointers also break all non-kernel filesystems. Argh! Cheers, Andreas -- Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto, \ would they cancel out, leaving him still hungry?" http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert - 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: eth1: Transmit timed out, status 0000, PHY status 0000
On Tue, 16 Jan 2001, richard.morgan9 wrote: > I have the same problem as Urban with a recent DLink 530tx > (rhine2). Pulling the power cable from my atx psu (while the > computer was "off") fixed the card, until my next reboot from > win98. I'm not the one with a problem but maybe it has something to do with win98 and/or the driver used there. I intend to test this myself eventually and see if I can do something based on Donald Beckers suggestions on eeprom. Unless someone else feels like playing with this ... anyone? Does everyone seeing this have a Rhine-II, pci id 1106:3065, and not the older chip found in dfe530tx with pci id 1106:3043? /Urban - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: Linux not adhering to BIOS Drive boot order?
> You seem to be full of things that "we" can implement. So I just have > to wonder: do you by any chance have some prototype code somewhere to > figure out, reliably, which SCSI cards have BIOS extensions enabled, > and the order they hook in? > [Venkat] It would be a very bad idea for the linux kernel to look into the card to see whether the BIOS for that card has been enabled to make it determine the scsi drive order. If you had followed the earlier threads, the correct way to proceed would be to use labels to make things node independent. I think Andreas is working on patch for 2.2.18 and 2.4.0 kernel. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
[Venkatesh Ramamurthy] > [Venkatesh Ramamurthy] I think there should be a better way to handle > this , compiling is one of the options, but an end-user should not > think of compiling. The end user needs to put an another card and > connect drives and get his system up and running. He should not think > of compiling the drivers, if it is already part of the kernel / > initrd to get his system running. You seem to be full of things that "we" can implement. So I just have to wonder: do you by any chance have some prototype code somewhere to figure out, reliably, which SCSI cards have BIOS extensions enabled, and the order they hook in? Peter - 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: lance.c @ 100Mbit
> Quick question: has anyone used the lance.c driver for a 100BaseT > network PCI device? If so, what successes/failures did you run into? Never used lance.c for 100BaseT (can it do that?). I've used the pcnet32.c driver, however. > (I'm working with an Am79C973 chip.) In my case, Am79C971. Works great for me, under both 2.2 and 2.4. (I don't have any SMP systems, FWIW.) -Barry K. Nathan <[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: SCSI partitions
in part it is due to the major/minor split which only gives 4 bits for the partition number. if you use devfs or LVM this limit is removed. David Lang On Tue, 16 Jan 2001 [EMAIL PROTECTED] wrote: > Date: Tue, 16 Jan 2001 11:10:41 -0800 > From: [EMAIL PROTECTED] > To: [EMAIL PROTECTED] > Subject: SCSI partitions > > Does anyone remember the reason why SCSI drives were limited to > 15 partitions? > > - > 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: lance.c @ 100Mbit
On Tue, 16 Jan 2001, Eli Carter wrote: > Quick question: has anyone used the lance.c driver for a 100BaseT > network PCI device? If so, what successes/failures did you run into? > > (I'm working with an Am79C973 chip.) Sure. It's the pcnet32.c file (not lance from which it came). It works fine in an embedded system and I'm currently adding some stuff to write/rewrite the SEEPROM which contains the IEEE address plus some stuff to init it upon reset. Cheers, Dick Johnson Penguin : Linux version 2.4.0 on an i686 machine (799.53 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: lance.c @ 100Mbit
} Quick question: has anyone used the lance.c driver for a 100BaseT } network PCI device? If so, what successes/failures did you run into? } } (I'm working with an Am79C973 chip.) I'd recommend the pcnet32.c driver for that chip, instead. I was running it for a little over a year at 100Mbps with no serious trouble. This was under Linux/PPC, so there were some endian-ness problems at first but it's clean now. - 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: Oops with 4GB memory setting in 2.4.0 stable
Hi again, It looks like some progress is being made, *wonderful*, as to some earlier questions... > I'll have a look tonight or so. It works for you on non-bigmem? Yes. Absolutely no problems on non-bigmem. > smb_rename suggests mv, but the process is ls ... er? What commands where > you running on smbfs when it crashed? It seems that ANY access to the smbfs has this affect. Definitely confirmed are: ls, tab completion from bash, cat [some file], and usually df. > > Could this be a symbol mismatch? Keith Owens suggested a less manual way > to get module symbol output. Do you get the same results using that? I'll try to do this and report back. --Rainer - 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: eth1: Transmit timed out, status 0000, PHY status 0000
>> On Sun, 14 Jan 2001, Urban Widmark wrote: >> >> >> eth1: Transmit timed out, status , PHY status , >> >> resetting... >> >[snip] >> >> Keeps going nonstop until I ifdown eth1. >> >> >> >> Card worked fine 2 days ago... >> > >> >So what did you change? >> >> Nothing. >> >> >Has the machine been up since then? >> >> No. I rebooted to W98 a few times. W98 doesn't have a driver >> installed for that card though - and wont. >> >> >> >> >Someone else with the same symptoms (in 2.4) >> >http://www.uwsg.iu.edu/hypermail/linux/net/0011.0/0027.html >> > >> >Becker's reply >> >http://www.uwsg.iu.edu/hypermail/linux/net/0011.0/0032.html >> > >> >"Try unplugging the system and doing a really cold boot. A soft-off does >> > not reset the chip. >> >> Tried that too.. didn't work. I switched PCI slots and whatnot >> though and it works again.. >> > >> > If this solves the problem, we will have to add code to re-load the >> > EEPROM info into the chip." >> >> If the problem recurs I will try to test it out more and report >> to the list. >> >> FWIW it is a DLink DFE 530TX. >> snip I have the same problem as Urban with a recent DLink 530tx (rhine2). Pulling the power cable from my atx psu (while the computer was "off") fixed the card, until my next reboot from win98. - 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: Oops with 4GB memory setting in 2.4.0 stable
On Tue, 16 Jan 2001, Petr Vandrovec wrote: > If there is new dentry, which is at fpos postion, and it is child of > readdir-ed directory, we should return it anyway, no? There must not be > two ncpfs dentries with same d_parent and d_fsdata if d_fsdata != 0, > as each dentry can be in only one directory. > > This looked as reasonable limitation to me ;-) Right. I chose not to read those tests for some reason ... good. The parent test should be ok. d_fsdata is only set in ncpfs if it is put in the cache and d_alloc sets it to 0. Works for me (whatever that may be worth). Rewriting the smbfs cache code allows for a nice speedup too. In ncpfs when reading a directory you create dentries and inodes at once. I assume that when reading the dir list from the server that you get all the info you need in one go. I think smbfs gets all needed info on all protocol versions it supports, so that should be a nice speedup for readdir() + stat()-each file (ls -l). Currently it only caches name info and then does a remote call for each entry. Too bad this is 2.4.0, the biggest problem may be sneaking it past Linus. oh well ... :) /Urban - 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: G400 behavior different, 2.2.18->2.4.0
On 16 Jan 01 at 17:16, Chad Miller wrote: (added [EMAIL PROTECTED], as he may be interested in one range behind bridge overlapping both forwarding ranges...) > #00:01.0 PCI bridge: VIA Technologies, Inc. VT8371 [KX133 AGP] (prog-if \ > #00 [Normal decode]) > # Flags: bus master, 66Mhz, medium devsel, latency 0 > # Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 > # Memory behind bridge: d400-d6ff > # Prefetchable memory behind bridge: d700-d8ff > # Capabilities: [80] Power Management version 2 > #01:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G400 AGP \ > #(rev 05) (prog-if 00 [VGA]) > # Subsystem: Matrox Graphics, Inc. Millennium G400 MAX/Dual Head 32Mb > # Flags: bus master, VGA palette snoop, medium devsel, latency 32, IRQ 10 > # Memory at d600 (32-bit, prefetchable) > # Memory at d400 (32-bit, non-prefetchable) > # Memory at d500 (32-bit, non-prefetchable) > # Capabilities: [dc] Power Management version 2 > # Capabilities: [f0] AGP version 2.0 Please, add your BIOS into list of broken BIOSes and stop complaining ;-) Your BIOS splitted 32MB G400 range into 16MB non-prefetchable d600-d6ff and 16MB prefetchable (d700-d7ff) range. Probably BIOS though that it is setting G400 framebuffer at D700 for 32MB, but as D700 is not multiple of 32MB, it cannot work. You should try upgrading BIOS. If it does not help... you can try kernel resources assigning code, but as it skips VGA adapters currently, it is long way to go. BTW, correct BIOS should put G400's resource #1 at D400, #2 at D480, and #0 at D600. Programming non-prefetchable range for D400-D4FF, and prefetchable as D600-D7FF... Leaving D5xx unused. Sorry for bad news, 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/
lance.c @ 100Mbit
Quick question: has anyone used the lance.c driver for a 100BaseT network PCI device? If so, what successes/failures did you run into? (I'm working with an Am79C973 chip.) TIA, Eli . "To the systems programmer, users and applications Eli Carter | serve only to provide a test load." [EMAIL PROTECTED] `-- (random fortune) - 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-x features ?
"Albert D. Cahalan" wrote: > > Pierre Rousselet writes: > > > 1) top (procps-2.0.7) gives me the messages : > > 'bad data in /proc/uptime' > > 'bad data in /proc/loadavg' > > cat /proc/uptime > > 1435.30 904.74 > > cat /proc/loadavg > > 0.01 0.21 0.29 1/17 19444 > > What is wrong ? > > Which 2.4.0-x kernel, and how was procps compiled? > (the broken gcc again perhaps?) > > You might as well get procps-010114.tar.gz (new just yesterday!) and > compile it yourself. The top command seems to tolerate Red Hat's > fixed gcc, which you should get if you are using Red Hat 7. I did that. Compilation OK with gcc-2.95.2 top still doesn't work ( top > /dev/null tells you 'bad data in ...' just before the screen blanks). logout after commenting LC_ALL=fr and LANG=fr in /etc/profile login again : top works. It is a question of '.' and ',' Pierre Rousselet <[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: Linux not adhering to BIOS Drive boot order?
[EMAIL PROTECTED] said: > Like the ext2 labels? (man e2label) > [Venkatesh Ramamurthy] This re-ordering of the scsi drives should be > done by SCSI ML , so is incorporating ext2 fs data structure knowledge > on the SCSI ML a good idea?. You'd better not care what the drives ae called - it will all change with devfs. filesystem labels are to identify the filesystems so you can mount the right ones in the right places. Even if the device names change. -- Cheers John Summerfield http://www2.ami.com.au/ for OS/2 & linux information. Configuration, networking, combined IBM ftpsites index. Note: mail delivered to me is deemed to be intended for me, for my disposition. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
[EMAIL PROTECTED] said: > [Venkatesh Ramamurthy] If we can truly go for label based mouting > and lilo'ing this would solve the problem. Anybody doing this? Red hat Linux 7.0. -- Cheers John Summerfield http://www2.ami.com.au/ for OS/2 & linux information. Configuration, networking, combined IBM ftpsites index. Note: mail delivered to me is deemed to be intended for me, for my disposition. - 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: G400 behavior different, 2.2.18->2.4.0
On Tue, Jan 16, 2001 at 10:40:51PM +, Petr Vandrovec wrote: > [X] Output under 2.2.x is correct: '/25' for 32MB range. I have no idea > why X complains about region D600-D7FF - can you look at > '... regions behind bridge' when you boot 2.2.x (they are on 0:01.0 > device, AFAIK) ? Under 2.4.x you showed that prefetchable region is > D600-D8FF, which correctly covers 2.2.x framebuffer address > (although it is not power of 2, but who knows...). Here's the full 2.2 output of 'lspci -v': #00:00.0 Host bridge: VIA Technologies, Inc. VT8371 [KX133] (rev 02) # Flags: bus master, medium devsel, latency 0 # Memory at d000 (32-bit, prefetchable) # Capabilities: [a0] AGP version 2.0 # #00:01.0 PCI bridge: VIA Technologies, Inc. VT8371 [KX133 AGP] (prog-if \ #00 [Normal decode]) # Flags: bus master, 66Mhz, medium devsel, latency 0 # Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 # Memory behind bridge: d400-d6ff # Prefetchable memory behind bridge: d700-d8ff # Capabilities: [80] Power Management version 2 # #00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] \ #(rev 22) # Subsystem: VIA Technologies, Inc. VT82C686/A PCI to ISA Bridge # Flags: bus master, stepping, medium devsel, latency 0 # #00:07.1 IDE interface: VIA Technologies, Inc. Bus Master IDE (rev 10) \ #(prog-if 8a [Master SecP PriP]) # Flags: bus master, medium devsel, latency 32 # I/O ports at e000 # Capabilities: [c0] Power Management version 2 # #00:07.4 Host bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] \ #(rev 30) # Flags: medium devsel # Capabilities: [68] Power Management version 2 # #00:09.0 Ethernet controller: Intel Corporation 82557 [Ethernet Pro 100] \ #(rev 08) # Subsystem: Intel Corporation EtherExpress PRO/100+ Management Adapter # Flags: bus master, medium devsel, latency 32, IRQ 11 # Memory at da10 (32-bit, non-prefetchable) # I/O ports at ec00 # Memory at da00 (32-bit, non-prefetchable) # Capabilities: [dc] Power Management version 2 # #01:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G400 AGP \ #(rev 05) (prog-if 00 [VGA]) # Subsystem: Matrox Graphics, Inc. Millennium G400 MAX/Dual Head 32Mb # Flags: bus master, VGA palette snoop, medium devsel, latency 32, IRQ 10 # Memory at d600 (32-bit, prefetchable) # Memory at d400 (32-bit, non-prefetchable) # Memory at d500 (32-bit, non-prefetchable) # Capabilities: [dc] Power Management version 2 # Capabilities: [f0] AGP version 2.0 The diff from above 2.2.18 to 2.4.0: 3,4c3,4 < Memory at d000 (32-bit, prefetchable) < Capabilities: [a0] AGP version 2.0 --- > Memory at d000 (32-bit, prefetchable) [size=64M] > Capabilities: 11c11 < Capabilities: [80] Power Management version 2 --- > Capabilities: 19,20c19,20 < I/O ports at e000 < Capabilities: [c0] Power Management version 2 --- > I/O ports at e000 [size=16] > Capabilities: 24c24 < Capabilities: [68] Power Management version 2 --- > Capabilities: 29,32c29,33 < Memory at da10 (32-bit, non-prefetchable) < I/O ports at ec00 < Memory at da00 (32-bit, non-prefetchable) < Capabilities: [dc] Power Management version 2 --- > Memory at da10 (32-bit, non-prefetchable) [size=4K] > I/O ports at ec00 [size=64] > Memory at da00 (32-bit, non-prefetchable) [size=1M] > Expansion ROM at [disabled] [size=1M] > Capabilities: 36,41c37,42 < Flags: bus master, VGA palette snoop, medium devsel, latency 32, IRQ 10 < Memory at d600 (32-bit, prefetchable) < Memory at d400 (32-bit, non-prefetchable) < Memory at d500 (32-bit, non-prefetchable) < Capabilities: [dc] Power Management version 2 < Capabilities: [f0] AGP version 2.0 --- > Flags: bus master, VGA palette snoop, medium devsel, latency 64, IRQ 10 > Memory at d800 (32-bit, prefetchable) [size=16M] > Memory at d400 (32-bit, non-prefetchable) [size=16K] > Memory at d500 (32-bit, non-prefetchable) [size=8M] > Expansion ROM at [disabled] [size=64K] > Capabilities: - 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/
super_operations in -pre7
several new operations have been added to super_operations, presumably as part of the reiserfs merge. write_super_lockfs and unlockfs are never called. can we remove them? -- Revolutions do not require corporate support. - 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: Blank screen in X after heavy disk access (2.4 only)
Yes, I have the same motherboard / chipset. Thanks for your help! Rodney M. Jokerst On Tue, 16 Jan 2001, Nathan Thompson wrote: > On Tue, Jan 16, 2001 at 03:11:01PM -0600, Rodney M. Jokerst wrote: > > This action causes my screen to go blank in X and remain blank > > unless I move the mouse or type on the keyboard. The second I stop doing > > one of these activities, it goes blank again. While it is blank, it seems > > to be flashing every second, as if it is recieving blank screen commands > > repeatedly. This behavior continues until I restart the machine. If I > > switch to a console, everything is fine. If I restart the X server, the > > behavior continues. > > Is this a VIA chipset based motherboard? > > If so someone (Vojtech Pavlik ?) has a patch that helps this... > It is a hardware error. > > For what it's worth I have seen this exact same behavior on my machine > in 2.2.x. > > I have an abit ka7 motherboard, via kx133 chipset. > > Nate > > > thanks, > > > > Rodney M. Jokerst > > - > 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: 2.4.0-x features ?
John Fremlin wrote: > > "Albert D. Cahalan" <[EMAIL PROTECTED]> writes: > > > > 1) top (procps-2.0.7) gives me the messages : > > > 'bad data in /proc/uptime' > > > 'bad data in /proc/loadavg' > > > cat /proc/uptime > > > 1435.30 904.74 > > > cat /proc/loadavg > > > 0.01 0.21 0.29 1/17 19444 > > > What is wrong ? > > You probably have locale settings where the decimal point is a comma > so scanf on /proc/loadavg etc. doesn't work. The following patch > (submitted to RedHat ages ago) fixes that for me. That's it. i persist in setting LANG=fr. Thank you for the tip. Pierre Rousselet <[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: Problem: Blank screen in X after heavy disk access (2.4 only)
On Tue, Jan 16, 2001 at 03:11:01PM -0600, Rodney M. Jokerst wrote: > This action causes my screen to go blank in X and remain blank > unless I move the mouse or type on the keyboard. The second I stop doing > one of these activities, it goes blank again. While it is blank, it seems > to be flashing every second, as if it is recieving blank screen commands > repeatedly. This behavior continues until I restart the machine. If I > switch to a console, everything is fine. If I restart the X server, the > behavior continues. Is this a VIA chipset based motherboard? If so someone (Vojtech Pavlik ?) has a patch that helps this... It is a hardware error. For what it's worth I have seen this exact same behavior on my machine in 2.2.x. I have an abit ka7 motherboard, via kx133 chipset. Nate > thanks, > > Rodney M. Jokerst - 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: G400 behavior different, 2.2.18->2.4.0 (was: matroxfb o
On 16 Jan 01 at 15:55, Chad Miller wrote: > (CC'd to lkml) > > On Tue, Jan 16, 2001 at 07:31:33PM +, Petr Vandrovec wrote: > > There is something wrong with your hardware. First region for G400 should > > be 32MB, not 16MB (even if you have 16MB G400, which I doubt). > > Ooo! Here's an edited diff of 'lspci -v' under 2.2.18 versus 2.4.0: > > 36,41c37,42 > < Flags: bus master, VGA palette snoop, medium devsel, latency 32, IRQ 10 > < Memory at d600 (32-bit, prefetchable) > --- > > Flags: bus master, VGA palette snoop, medium devsel, latency 64, IRQ 10 > > Memory at d800 (32-bit, prefetchable) [size=16M] > Do you think any configuration parameters could affect this? (I haven't > paid as much attention to the evolution from 2.2 to 2.4 as I should've.) > > Here's the diff of X' output, from 2.2.18 to 2.4.0: > > 43c43 > < (--) PCI:*(1:0:0) Matrox MGA G400 AGP rev 5, Mem @ 0xd600/25, 0xd400/14, >0xd500/23 > --- > > (--) PCI:*(1:0:0) Matrox MGA G400 AGP rev 5, Mem @ 0xd600/24, 0xd400/14, >0xd500/23 > 72,73d71 > < (WW) INVALID MEM ALLOCATION b: 0xd600 e: 0xd7ff correcting > < (EE) Cannot find a replacement memory range Output under 2.2.x is correct: '/25' for 32MB range. I have no idea why X complains about region D600-D7FF - can you look at '... regions behind bridge' when you boot 2.2.x (they are on 0:01.0 device, AFAIK) ? Under 2.4.x you showed that prefetchable region is D600-D8FF, which correctly covers 2.2.x framebuffer address (although it is not power of 2, but who knows...). You should see D400-D5FF as non-prefetchable memory behind bridge, and D600-D7FF as prefetchable memory behind bridge. 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: Oops with 4GB memory setting in 2.4.0 stable
On 16 Jan 01 at 21:17, Urban Widmark wrote: > The smbfs dircache needs to find/kmap all of its cache pages since the > entries in it are variable length and the way it is called. It would be > nice to change that. > > I haven't looked at all your detailed comments yet. They may not matter if > the many kmaps are a problem. I think that too many kmaps could explain reported 'silent hang'... (if my memory serves good, there was some report about silent PAE hang during last 7 days, yes?). Not-checking ->block for NULL looks like bug which can be triggered without kmap too. > how can it know that the dentry is the right one? I thought that dentries > could be removed/reused by someone at will (d_count will be 0 because of > the dput in ncp_fill_cache, no?). Why isn't it possible for someone to > write a new dentry where the old one was. > > fs/ncpfs/dir.c:ncp_d_validate() calls > valid = d_validate(dentry, dentry->d_parent, dentry->d_name.hash, len); > > all values are taken from the dentry pointer on the cache page (including > len). d_validate verifies that d_hash() points to a list and it searches > the list for dentry. How do you know that it is the same dentry that was > put in the cache and not someone elses dentry? Before calling d_validate it checks whethern dentry->d_parent == parent (readdir-ed directory). And if dentry is in directory we read, it is in dentry d_hash, and even d_fsdata matches its position in directory, I bet that it is valid dentry... If there is new dentry, which is at fpos postion, and it is child of readdir-ed directory, we should return it anyway, no? There must not be two ncpfs dentries with same d_parent and d_fsdata if d_fsdata != 0, as each dentry can be in only one directory. This looked as reasonable limitation to me ;-) 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: Linux not adhering to BIOS Drive boot order?
On Tue, Jan 16, 2001 at 10:01:25PM +0100, Andi Kleen wrote: > On Tue, Jan 16, 2001 at 03:37:57PM -0500, Michael Meissner wrote: > > don't assume that the way your system gets booted is the way everybody's does, > > particularly those on platforms other than the x86. > > > > I must say, as a 5 year Linux user (and 23 year UNIX user/administrator), I do > > get tired of having to hunt down and deal with each of these changes that come > > up from time to time with Linux (ie, switching from ipfwadm to ipchains to > > netfilter, or in this case reordering how scsi adapters/network adapters are > > looked up). > > Bad example. > > netfilter does not force you to switch anything. You can just load the ipchains > or even the ipfw module and use your old scripts. Granted I was mainly thinking of the ipfwadm->ipchains conversion, but you have to root around and load the appropriate module. I like to build as much into the kernel as possible, and it took some amount of time to get things so that I could build the ipchains modules, since you are presented with choices that preclude building of the modules. If I had been using make config instead of make xconfig, it would have been worse, since I would have to go through the questions each time to get to the network section. I could also use the various incompatible transforms MD support has had over the years for another example, or the number of times system status monitors break due to changes in the output of /proc files (and yes I grant you many of the changes are due to poor programming in the status programs, but not all of them). Yes, change is one of the things that makes Linux strong. However, change to the way things are done can piss people off to using an alternate system, such as happened to Sun when they changed from the BSD method of system administration to System V many years ago. -- Michael Meissner, Red Hat, Inc. (GCC group) PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA Work: [EMAIL PROTECTED] phone: +1 978-486-9304 Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
Kelsey Hudson writes: > however, this brings up an interesting question: what happens if two disks > (presumably from two different machines) have the same disk label? what > happens then? for instance, i have several linux machines both at my > workplace and my home. if for some reason one of these machines dies due > to hardware failure and i want to get stuff off the drives, i put the disk > containing the /home partition on the failed machine into a working > machine and reboot. What /home gets mounted then? the original /home or > the new one from the dead machine? (and don't say end users wouldn't > possibly do that... if they are adding hardware into their systems this is > by no means beyond their capabilities) Don't do that (tm). You may still have that problem (or even all filesystems being mounted wrong) if you add a new drive to a SCSI chain. Likewise if you add an IDE controller, the controllers may be numbered differently... > at least with physical device nodes i can say 'computer, you will mount > this partition on this mountpoint!' and be done with it. If you use a UUID, you will never have conflicts (unless you do drive imaging, which is bad). The label is just a lot more convenient to use than the UUID. > so tell me then, how would one discern between two partitions with the > same label? It will pick the first one found, I guess. However, this still reduces the problem of drive renaming by 99%. It goes from "each time drives are added/moved/removed my system may be broken" to "if I insert two drives with the same label 50% chance my system is broken". I'll take the latter any day. Cheers, Andreas -- Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto, \ would they cancel out, leaving him still hungry?" http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert - 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: Name of SCSI Device
You write: > If we install a SCSI hard disk drive, with ID3, an nothing on ID1 or ID2, > will be sda. If we install a new disk on ID1, the drive that before was > sda now change the name to sdb. > > Why the name of hard disk drive of SCSI Controller are not fixed? > ID0=sda > ID1=sdb > ID2=sdc There are not enough major/minor numbers to do this. > Then, it is possible that we must change /etc/fstab If you are using ext2 (or ext3), it is possible to mount by filesystem LABEL or UUID. See man pages for e2label/tune2fs/dumpe2fs/mount(8)/fstab(5). Cheers, Andreas -- Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto, \ would they cancel out, leaving him still hungry?" http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
David Woodhouse writes: > There are patches available for the 2.2 kernel which provide the facility > to mount by UUID or volume label. It seems that nobody is actively > maintaining those at the moment. If you want to update those to the current > 2.2 and 2.4 kernels, well volunteered. I'm quite interested in this patch, and have taken a good look at it. Some changes are in order (IMHO) to make it more usable. It should take parameters that are the same as in /etc/fstab (i.e. LABEL= and UUID= instead of L: and UUID:). In the end I re-wrote most of the patch, so that we resolve ROOT_DEV before calling mount_root(), just to be a bit more consistent. I will release a new patch for 2.2.18 and 2.4.0 after David Balazic has a look at it. I know a bit about LILO, so I should be able to get the "root=LABEL=" to work there as well. I also need to do some work like this in e2fsprogs, so it may make sense to create a little library that can be updated to handle other kinds of filesystem/partition LABELs and UUIDs as the need arises. They were talking about putting a LABEL/UUID into reiserfs recently. This saves us from having to fix ext2-specific in dozens of utilities (e.g. LILO, mount, fsck, dump, etc). One reason why this may NOT ever make it into the kernel is that I know "kernel poking at devices" is really frowned upon. Cheers, Andreas -- Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto, \ would they cancel out, leaving him still hungry?" http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert - 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: Blank screen in X after heavy disk access (2.4 only)
With all of the late 2.3 kernels, 2.4 test kernels, and the latest official 2.4.0 kernel that I have tried, I get disturbing behavior during and after heavy disk access, such as uploading a 500MB file from the local network. This action causes my screen to go blank in X and remain blank unless I move the mouse or type on the keyboard. The second I stop doing one of these activities, it goes blank again. While it is blank, it seems to be flashing every second, as if it is recieving blank screen commands repeatedly. This behavior continues until I restart the machine. If I switch to a console, everything is fine. If I restart the X server, the behavior continues. I have never seen this behavior in any of the 2.2 series of kernels, including 2.2.18 which I am running now. If anyone is interested in this problem, I can get all of the relevant hardware and software info for my computer. Just let me know what I need to provide. thanks, Rodney M. Jokerst - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
** Reply to message from "Christopher Friesen" <[EMAIL PROTECTED]> on Tue, 16 Jan 2001 14:54:23 -0500 > > The Mac never enumerates its devices like the PC does (no C: D: etc, no > > /dev/sda, /dev/sdb, or anything like that). It also remembers the boot device > > in its EEPROM (the Startup Disk Control Panel handles this). > > Are you sure about that? According to my documentation on installing linux on a G4 > with scsi disks, you need to specify a device enumeration string like the following > to tell the system where to look for the boot device: > > /pci@f200/pci-bridge@d/ATTO,ExpressPCIProUL2D@4,1/@6:5 > > where the '6' is the SCSI ID of the drive, and the '5' is the partition number of the > boot partition. So if you change SCSI IDs or add a new partition and change the > partition numbering of the drive, your computer can't boot anymore. I was talking about a Mac running Mac OS. I've tried change the SCSI ID of the boot device, but this discussion was about adding devices. On a Mac, I've always been able to add devices, whether they be on an exiting SCSI or IDE bus, or on a new bus, and not worry about the machine not booting. I can't same the same about the PC. Overall, the PC is just much more sensitive to device changes than Macs are. And I think it's because the Mac BIOS and OS are just designed to handle this better. The PC BIOS never had any provision for a third-party boot device to annouce itself. -- Timur Tabi - [EMAIL PROTECTED] Interactive Silicon - http://www.interactivesi.com When replying to a mailing-list message, please direct the reply to the mailing list only. Don't send another copy to me. - 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] make drivers/scsi/atari_scsi.c check request_irq (240p3)
Hi again.
The following patch should correct the request_irq mistake. (The zero return
on failure seems to be required by scsi/scsi.c and is what everybody else
does.)
Other comments? :)
--- linux-ac9/drivers/scsi/atari_scsi.c.org Sun Jan 14 19:41:56 2001
+++ linux-ac9/drivers/scsi/atari_scsi.c Sun Jan 14 22:47:31 2001
@@ -690,19 +690,30 @@
/* This int is actually "pseudo-slow", i.e. it acts like a slow
* interrupt after having cleared the pending flag for the DMA
* interrupt. */
- request_irq(IRQ_TT_MFP_SCSI, scsi_tt_intr, IRQ_TYPE_SLOW,
- "SCSI NCR5380", scsi_tt_intr);
+ if (request_irq(IRQ_TT_MFP_SCSI, scsi_tt_intr, IRQ_TYPE_SLOW,
+"SCSI NCR5380", scsi_tt_intr)) {
+ printk(KERN_ERR "atari_scsi_detect: cannot allocate irq %d,
+aborting",IRQ_TT_MFP_SCSI);
+ scsi_unregister(atari_scsi_host);
+ atari_stram_free(atari_dma_buffer);
+ atari_dma_buffer = 0;
+ return 0;
+ }
tt_mfp.active_edge |= 0x80; /* SCSI int on L->H */
#ifdef REAL_DMA
tt_scsi_dma.dma_ctrl = 0;
atari_dma_residual = 0;
-#endif /* REAL_DMA */
-#ifdef REAL_DMA
#ifdef CONFIG_TT_DMA_EMUL
if (MACH_IS_HADES) {
- request_irq(IRQ_AUTO_2, hades_dma_emulator,
- IRQ_TYPE_PRIO, "Hades DMA emulator",
- hades_dma_emulator);
+ if (request_irq(IRQ_AUTO_2, hades_dma_emulator,
+IRQ_TYPE_PRIO, "Hades DMA emulator",
+hades_dma_emulator)) {
+ printk(KERN_ERR "atari_scsi_detect: cannot allocate
+irq %d, aborting (MACH_IS_HADES)",IRQ_AUTO_2);
+ free_irq(IRQ_TT_MFP_SCSI, scsi_tt_intr);
+ scsi_unregister(atari_scsi_host);
+ atari_stram_free(atari_dma_buffer);
+ atari_dma_buffer = 0;
+ return 0;
+ }
}
#endif
if (MACH_IS_MEDUSA || MACH_IS_HADES) {
@@ -719,9 +730,8 @@
* the rest data bug is fixed, this can be lowered to 1.
*/
atari_read_overruns = 4;
- }
-#endif
-
+ }
+#endif /*REAL_DMA*/
}
else { /* ! IS_A_TT */
--
Regards,
Rasmus([EMAIL PROTECTED])
After all, it is only the mediocre who are always at their best.
-- Jean Giraudoux
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
On Tue, Jan 16, 2001 at 03:37:57PM -0500, Michael Meissner wrote: > don't assume that the way your system gets booted is the way everybody's does, > particularly those on platforms other than the x86. > > I must say, as a 5 year Linux user (and 23 year UNIX user/administrator), I do > get tired of having to hunt down and deal with each of these changes that come > up from time to time with Linux (ie, switching from ipfwadm to ipchains to > netfilter, or in this case reordering how scsi adapters/network adapters are > looked up). Bad example. netfilter does not force you to switch anything. You can just load the ipchains or even the ipfw module and use your old scripts. -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/
G400 behavior different, 2.2.18->2.4.0 (was: matroxfb on 2.4.0 / PCI: Failed to allocate...)
(CC'd to lkml) On Tue, Jan 16, 2001 at 07:31:33PM +, Petr Vandrovec wrote: > There is something wrong with your hardware. First region for G400 should > be 32MB, not 16MB (even if you have 16MB G400, which I doubt). Ooo! Here's an edited diff of 'lspci -v' under 2.2.18 versus 2.4.0: 36,41c37,42 < Flags: bus master, VGA palette snoop, medium devsel, latency 32, IRQ 10 < Memory at d600 (32-bit, prefetchable) < Memory at d400 (32-bit, non-prefetchable) < Memory at d500 (32-bit, non-prefetchable) < Capabilities: [dc] Power Management version 2 < Capabilities: [f0] AGP version 2.0 --- > Flags: bus master, VGA palette snoop, medium devsel, latency 64, IRQ 10 > Memory at d800 (32-bit, prefetchable) [size=16M] > Memory at d400 (32-bit, non-prefetchable) [size=16K] > Memory at d500 (32-bit, non-prefetchable) [size=8M] > Expansion ROM at [disabled] [size=64K] > Capabilities: Change in latency and base address. Interesting, eh? Do you think any configuration parameters could affect this? (I haven't paid as much attention to the evolution from 2.2 to 2.4 as I should've.) Here's the diff of X' output, from 2.2.18 to 2.4.0: 43c43 < (--) PCI:*(1:0:0) Matrox MGA G400 AGP rev 5, Mem @ 0xd600/25, 0xd400/14, 0xd500/23 --- > (--) PCI:*(1:0:0) Matrox MGA G400 AGP rev 5, Mem @ 0xd600/24, 0xd400/14, >0xd500/23 72,73d71 < (WW) INVALID MEM ALLOCATION b: 0xd600 e: 0xd7ff correcting < (EE) Cannot find a replacement memory range Ideas? - chad -- Chad Miller <[EMAIL PROTECTED]> URL: http://web.chad.org/ (GPG) "Any technology distinguishable from magic is insufficiently advanced". First corollary to Clarke's Third Law (Jargon File, v4.2.0, 'magic') - 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: 4G SGI quad Xeon - memory-related slowdowns
Hi Paul,
> 2) Other block I/O output (eg dd if=/dev/zero of=/dev/sdi bs=4M) also
> run very slowly
What do you notice when running "top" and doing the above?
Does the "buff" value grow high (+700MB), with high CPU usage?
If so, I think this might be down to nr_free_buffer_pages().
This function includes the pages in all zones (including the HIGHMEM
zone) in its calculations, while only DMA and NORMAL zone pages are used
for buffers. This upsets the result from
balance_dirty_state() (fs/buffer.c), and as a result the required flushing
of buffers is only done as a result of running v low of pages in the DMA
and NORMAL zones.
I've attached a "quick hack" I did for 2.4.0. It doesn't completely
solve the problem, but moves it in the right direction.
Please let me know if this helps.
Mark
diff -urN -X dontdiff linux-2.4.0/mm/page_alloc.c markhe-2.4.0/mm/page_alloc.c
--- linux-2.4.0/mm/page_alloc.c Wed Jan 3 17:59:06 2001
+++ markhe-2.4.0/mm/page_alloc.cMon Jan 15 15:35:14 2001
@@ -583,6 +583,27 @@
}
/*
+ * Free pages in zone "type", and the zones below it.
+ */
+unsigned int nr_free_pages_zone (int type)
+{
+ unsigned int sum;
+ zone_t *zone;
+ pg_data_t *pgdat = pgdat_list;
+
+ if (type >= MAX_NR_ZONES)
+ BUG();
+
+ sum = 0;
+ while (pgdat) {
+ for (zone = pgdat->node_zones; zone < pgdat->node_zones + type;
+zone++)
+ sum += zone->free_pages;
+ pgdat = pgdat->node_next;
+ }
+ return sum;
+}
+
+/*
* Total amount of inactive_clean (allocatable) RAM:
*/
unsigned int nr_inactive_clean_pages (void)
@@ -600,6 +621,25 @@
return sum;
}
+unsigned int nr_inactive_clean_pages_zone(int type)
+{
+ unsigned int sum;
+ zone_t *zone;
+ pg_data_t *pgdat = pgdat_list;
+
+ if (type >= MAX_NR_ZONES)
+ BUG();
+ type++;
+
+ sum = 0;
+ while (pgdat) {
+ for (zone = pgdat->node_zones; zone < pgdat->node_zones + type;
+zone++)
+ sum += zone->inactive_clean_pages;
+ pgdat = pgdat->node_next;
+ }
+ return sum;
+}
+
/*
* Amount of free RAM allocatable as buffer memory:
*/
@@ -607,9 +647,9 @@
{
unsigned int sum;
- sum = nr_free_pages();
- sum += nr_inactive_clean_pages();
- sum += nr_inactive_dirty_pages;
+ sum = nr_free_pages_zone(ZONE_NORMAL);
+ sum += nr_inactive_clean_pages_zone(ZONE_NORMAL);
+ sum += nr_inactive_dirty_pages; /* XXX */
/*
* Keep our write behind queue filled, even if
RE: Linux not adhering to BIOS Drive boot order?
> Of course that would be better. The only complaint I have with such a > system is that of backwards compatibility...as long as the legacy device > names are still supported i would have no problem with it at all. > > however, this brings up an interesting question: what happens if two disks > (presumably from two different machines) have the same disk label? what > happens then? for instance, i have several linux machines both at my > workplace and my home. if for some reason one of these machines dies due > to hardware failure and i want to get stuff off the drives, i put the disk > containing the /home partition on the failed machine into a working > machine and reboot. What /home gets mounted then? the original /home or > the new one from the dead machine? (and don't say end users wouldn't > possibly do that... if they are adding hardware into their systems this is > by no means beyond their capabilities) > > at least with physical device nodes i can say 'computer, you will mount > this partition on this mountpoint!' and be done with it. [Venkatesh Ramamurthy] You are getting my point exactly. This was my argument from the first, we should have a efficient mechanism to mount partitions > so tell me then, how would one discern between two partitions with the > same label? [Venkatesh Ramamurthy] If the OS detects two partitions of the same name , either dont mount both , but display an error (or) mount the first one it finds ( this is not a good idea but) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
On Tue, Jan 16, 2001 at 12:01:12PM -0800, Dr. Kelsey Hudson wrote: > On Tue, 16 Jan 2001, Venkatesh Ramamurthy wrote: > > > > This is due to the fixed ordering of the scsi drivers. You can change the > > > order of the scsi hosts with the "scsihosts" kernel parameter. See > > > linux/drivers/scsi/scsi.c > > [Venkatesh Ramamurthy] I think it would be a nice idea if we can > > make this process automatic , with out user typing in the order and > > remembering it. The fact that a kernel developer is not using the machines > > daily to get his work done should be in our minds. If we do this Linux would > > become more user friendly > > you're forgetting that in /etc/lilo.conf there is a directive called > 'append='... all the user has to do is merely add > 'append="scsihosts=whatever,whatever"' into their config file and rerun > lilo. problem solved That's assuming you are using lilo. Not everybody does or can use lilo, please don't assume that the way your system gets booted is the way everybody's does, particularly those on platforms other than the x86. I must say, as a 5 year Linux user (and 23 year UNIX user/administrator), I do get tired of having to hunt down and deal with each of these changes that come up from time to time with Linux (ie, switching from ipfwadm to ipchains to netfilter, or in this case reordering how scsi adapters/network adapters are looked up). > besides, how many 'end-users' do you know of that will have multiple scsi > adapters in one system? how many end-users -period- will have even a > *single* scsi adapter in their systems? do we need to bloat the kernel > with automatic things like this? no... i think it is handled fine the way > it is. if the user wants to add more than one scsi adapter into his > system, let him read some documentation on how to do so. (is this even a > documented feature? if not, i think it should be added to the docs...) I'm an end-user, and I have 3 scsi-adapters of two different brands in my system. Many of the people using Linux in high end things like servers, etc. will have multiple scsi controlers. People are using Linux in lots of things from small embedded devices to large systems, and Linux needs to address needs in every area. -- Michael Meissner, Red Hat, Inc. (GCC group) PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA Work: [EMAIL PROTECTED] phone: +1 978-486-9304 Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482 - 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/
oops 2.2.18
Hi, on 2.2.17 & 2.2.18 we have this kernel panic: it begins with: no vm86_info: BAD ksymoops 2.3.7 on i686 2.2.18RAID. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.2.18RAID/ (default) -m /usr/src/linux/System.map (default) Warning: You did not tell me where to find symbol information. I will assume that the log matches the kernel and modules that are running right now and I'll use the default options above for symbol resolution. If the current kernel and/or modules do not match the log, you can get more accurate output by telling me the kernel version and where to find map, modules, ksyms etc. ksymoops -h explains the options. Error (regular_file): read_ksyms stat /proc/ksyms failed ./ksymoops: Aucun fichier ou répertoire de ce type No modules in ksyms, skipping objects No ksyms, skipping lsmod Unable to handle kernel paging request at virtual address 4452460c current->tss.cr3 = 09678000, %cr3 = 09678000 *pde = Oops: CPU:0 EIP:0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010046 eax: 0019 ebx: 44524600 ecx: d7063fc0 edx: esi: dffef920 edi: 0286 ebp: 0018 esp: c96ebe04 ds: 0018 es: 0018 ss: 0018 Process webalizer (pid: 24499, process nr: 188, stackpage=c96eb000) Stack: d706361c 0004 d706365c dbea773c c014a142 dffef920 d70635c0 d70635c0 c014a1f1 d70635c0 003c d70635c0 c0158417 d70635c0 c81c2ff0 2180 0002 c81c2f40 d70635ec d70635c0 c81c2f94 00241717 c0158722 c81c2f40 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 39 43 0c 75 1d 8b 41 14 89 58 10 89 43 14 8b 06 8b 50 14 89 >>EIP; c011d2be<= Trace; c014a142 Trace; c014a1f1 <__kfree_skb+a1/a8> Trace; c0158417 Trace; c0158722 Trace; c01a6787 <__delay+13/24> Trace; c0159be9 Trace; c015e950 Trace; c015ed06 Trace; c0151bb2 Trace; c0151e99 Trace; c014ba25 Trace; c0114f39 Trace; c0108b8b Trace; c0108858 Code; c011d2be <_EIP>: Code; c011d2be<= 0: 39 43 0c cmpl %eax,0xc(%ebx) <= Code; c011d2c1 3: 75 1d jne22 <_EIP+0x22> c011d2e0 Code; c011d2c3 5: 8b 41 14 movl 0x14(%ecx),%eax Code; c011d2c6 8: 89 58 10 movl %ebx,0x10(%eax) Code; c011d2c9 b: 89 43 14 movl %eax,0x14(%ebx) Code; c011d2cc e: 8b 06 movl (%esi),%eax Code; c011d2ce 10: 8b 50 14 movl 0x14(%eax),%edx Code; c011d2d1 13: 89 00 movl %eax,(%eax) Aiee, killing interrupt handler 1 warning and 1 error issued. Results may not be reliable. -- Amicalement, oCtAvE - 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: HP Pavilion 8290 HANGS on boot 2.4/2.4-test9
Hi!
> >Is there a safe way to add debug information like simple string prints in
> >arch/i386/boot/compressed/head.s and in arch/i386/kernel/head.S
> >so that I can see at the console where the boot process hangs?
>
> Time for another version of my VIDEO_CHAR patch.]
What abourt early_printk? Works well on x86-64... And you can easily
redirect printk to early_printk.
#include
#ifndef MINIKERNEL
#define VGABASE 0x800b8000ul/* This is "wrong" address to access
it, we should access it using 0x800b8000ul; but 0x800b8000ul is not
available early at boot. */
#else
#define VGABASE 0xb8000ul
#endif
#define MAX_YPOS25
#define MAX_XPOS80
static int current_ypos = 1, current_xpos = 0; /* We want to print before clearing BSS
*/
int printk_ready = 0;
#ifndef MINIKERNEL
void
early_clear (void)
{
int k, i;
for(k = 0; k < MAX_YPOS; k++)
for(i = 0; i < MAX_XPOS; i++)
writew(0, VGABASE + 2*(MAX_XPOS*k + i));
current_ypos = 0;
}
void
early_puts (const char *str)
{
char c;
int i, k, j;
while ((c = *str++) != '\0') {
if (current_ypos >= MAX_YPOS) {
#ifndef CONFIG_SIMNOW
/* scroll 1 line up */
for(k = 1, j = 0; k < MAX_YPOS; k++, j++) {
for(i = 0; i < MAX_XPOS; i++) {
writew(readw(VGABASE + 2*(MAX_XPOS*k + i)),
VGABASE + 2*(MAX_XPOS*j + i));
}
}
for(i = 0; i < MAX_XPOS; i++) {
writew(0x720, VGABASE + 2*(MAX_XPOS*j + i));
}
current_ypos = MAX_YPOS-1;
#else
/* MUCH faster */
early_clear();
current_ypos = 0;
#endif
}
if (c == '\n') {
current_xpos = 0;
current_ypos++;
} else if (c != '\r') {
writew(((0x7 << 8) | (unsigned short) c),
VGABASE + 2*(MAX_XPOS*current_ypos + current_xpos++));
if (current_xpos >= MAX_XPOS) {
current_xpos = 0;
current_ypos++;
}
}
}
}
#else
#define putc(c, x) writew(((0x7 << 8) | (unsigned short) (c)), \
VGABASE + (x) * 2);
void
early_puts (const char *str)
{
char c;
int i, rest;
while ((c = *str++) != '\0') {
if (c == '\n' || c == '\r') {
/* blank rest of the line */
rest = MAX_XPOS - (current_xpos % MAX_XPOS);
for (i=0; i < rest; i++) {
putc(' ', current_xpos++);
}
} else {
putc(c, current_xpos);
current_xpos++;
}
current_xpos %= MAX_XPOS * MAX_YPOS;
}
}
#endif /* MINIKERNEL */
static char buf[1024];
int early_printk(const char *fmt, ...)
{
va_list args;
int i;
va_start(args, fmt);
i = vsprintf(buf, fmt, args); /* hopefully i < sizeof(buf)-4 */
va_end(args);
if (!printk_ready)
early_puts(buf);
else
printk("%s", buf);
return i;
}
--
I'm [EMAIL PROTECTED] "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at [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: Linux not adhering to BIOS Drive boot order?
On Tue, 16 Jan 2001, Venkatesh Ramamurthy wrote: > [Venkatesh Ramamurthy] Dont you think that mounting and booting > based on disk label names is better, then relying on device nodes which can > change when a new card is added?. The existing patch for 2.2.xx is quite > small and it does not bloat the kernel too much either. I think we can port > it for 2.4.XX with ease.In my words it is worth the effort Of course that would be better. The only complaint I have with such a system is that of backwards compatibility...as long as the legacy device names are still supported i would have no problem with it at all. however, this brings up an interesting question: what happens if two disks (presumably from two different machines) have the same disk label? what happens then? for instance, i have several linux machines both at my workplace and my home. if for some reason one of these machines dies due to hardware failure and i want to get stuff off the drives, i put the disk containing the /home partition on the failed machine into a working machine and reboot. What /home gets mounted then? the original /home or the new one from the dead machine? (and don't say end users wouldn't possibly do that... if they are adding hardware into their systems this is by no means beyond their capabilities) at least with physical device nodes i can say 'computer, you will mount this partition on this mountpoint!' and be done with it. so tell me then, how would one discern between two partitions with the same label? just a thought Kelsey Hudson [EMAIL PROTECTED] Software Engineer Compendium Technologies, Inc (619) 725-0771 --- - 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: Does reiserfs really meet the "Linux-2.4.x patch submission policy"?
In article <[EMAIL PROTECTED]>, =?us-ascii?Q?Andr=E9?= Dahlqvist <[EMAIL PROTECTED]> wrote: > >Don't get me wrong, I am personally really excited that reiserfs was >included. I just thought that you basically wanted 2.4.1 to be "boring". Reiserfs inclusion in 2.4.1 was basically the plan for the very beginning: it was so widely known that it was even reported in the press, so I didn't even bother to point out reiserfs as a 2.4.1 patch. That said, I wanted to leave the window open for any showstopper bugs, and have a pure "bug-fixes only" 2.4.1 if needed. I'm actually fairly happy that there haven't been any really serious reports so far. Inclusion of reiserfs is not going to add any bugs for the non-reiserfs case (apart from a stupid merge issue, and now I've watched all the non-reiserfs diffs with a microscope), so in that sense it's safe. Peopel who would have used reiserfs anyway would have gotten more problem reports, so.. If I were you, I'd worry more about the blk-patches from Jens, but they've been around for a long time, and Alan also put them in his tree. Which makes them as safe as any patch we've seen. So I took the approach that "we'll obviously have to put this _somewhere_ in 2.4.x". But that is, at least to me, a potentially bigger worry than reiserfs. (Actually I'm not so much worried that the blk patches themselves would have bugs, as worried about them showing bugs in block drivers by being better at merging requests. Those kinds of bugs we'll have to figure out during 2.4.x anyway though, but it's a case of a latent bug maybe showing up more easily under higher load generated by the blk fixes). 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/
Update on RTS/CTS serial problem with 2.4.0
I previously reported a problem trying to disable hardware flow-control
of serial ports in the Linux kernel 2.4.0. This problem did not
exist in Linux version 2.2.18.
This problem occurs when the initial console has been redirected out
to a serial port as is the case with one of our embedded systems.
It appears that the device must be closed, i.e., nobody using the
terminal, before the CTS/RTS disabling takes affect. A work around
(that works) is to set the terminal, close it, then open and set
it again. This is basically what `setserial` does to an otherwise
unused terminal. It seems as though this should not be necessary.
Here is a snippet of code that works.
/*-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-*/
/*
* We may have failed to open an initial console. Therefore, we do the
* terminal stuff over from scratch.
*/
memset(>st, 0x00, sizeof(struct termios));
mem->st.c_cc[VINTR]= (char) 'C' - 64;
mem->st.c_cc[VQUIT]= (char) '\\'- 64;
mem->st.c_cc[VERASE] = (char) '?' + 64;
mem->st.c_cc[VKILL]= (char) 'U' - 64;
mem->st.c_cc[VEOF] = (char) 'D' - 64;
mem->st.c_cc[VTIME]= (char) 0;
mem->st.c_cc[VMIN] = (char) 1;
mem->st.c_cc[VSWTC]= (char) '@' - 64;
mem->st.c_cc[VSTART] = (char) 'Q' - 64;
mem->st.c_cc[VSTOP]= (char) 'S' - 64;
mem->st.c_cc[VSUSP]= (char) 'Z' - 64;
mem->st.c_cc[VEOL] = (char) '@' - 64;
mem->st.c_cc[VREPRINT] = (char) 'R' - 64;
mem->st.c_cc[VDISCARD] = (char) 'O' - 64;
mem->st.c_cc[VWERASE] = (char) 'W' - 64;
mem->st.c_cc[VLNEXT] = (char) 'V' - 64;
mem->st.c_cc[VEOL2]= (char) '@' - 64;
mem->st.c_oflag = OPOST|ONLCR;
mem->st.c_iflag = ICRNL|IXON;
mem->st.c_lflag = ISIG|ICANON|ECHO|ECHOE|ECHOK|ECHOCTL|ECHOKE|IEXTEN;
mem->st.c_cflag = B9600|CS8|CREAD|HUPCL|CLOCAL;
/*
* Because of a bug in the Linux 2.4.0 terminal driver, we have to do
* this twice to get the flow-control turned off.
*/
for(i=0; i< 2; i++)
{
(void)close(STDIN_FILENO);
(void)close(STDOUT_FILENO);
(void)close(STDERR_FILENO);
if((fd = open(stdcmd, O_RDWR|O_NDELAY, 0)) < 0)
fd = open(Altcons, O_RDWR|O_NDELAY);
if((flags = fcntl(fd, F_GETFL, 0)) != -1)
{
flags &= ~O_NDELAY;
(void)fcntl(fd, F_SETFL, flags);
}
if(!!fd)
{
(void)dup2(fd, STDIN_FILENO);
(void)dup2(fd, STDOUT_FILENO);
(void)dup2(fd, STDERR_FILENO);
if(fd > 2) (void)close(fd);
}
else /* fd is STDIN_FILENO */
{
(void)dup(fd); /* Make STDOUT_FILENO */
(void)dup(fd); /* Make STDERR_FILENO */
}
if(tcflush(STDIN_FILENO, TCIFLUSH) < 0)
ERRORS(Tcflush);
if(tcsetattr(STDIN_FILENO, TCSANOW, >st) < 0)
ERRORS(Tcsetattr);
}
I can't see anything that I have done wrong that would otherwise
prevent this from working the first time through.
Comments?
Cheers,
Dick Johnson
Penguin : Linux version 2.4.0 on an i686 machine (799.53 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: Oops with 4GB memory setting in 2.4.0 stable
On Tue, 16 Jan 2001, Petr Vandrovec wrote: > smb_get_dircache looks suspicious to me, as it can try to map unlimited > number of pages with kmap. And kmaps are not unlimited resource... > You have 512 kmaps, but one SMBFS cache page can contain about 504 > pages... So two smbfs cached directories can consume all your kmaps, > dying then in endless loop in mm/highmem.c:map_new_virtual(). The smbfs dircache needs to find/kmap all of its cache pages since the entries in it are variable length and the way it is called. It would be nice to change that. I haven't looked at all your detailed comments yet. They may not matter if the many kmaps are a problem. The ncpfs code puts 'struct dentry *' in it's cache pages. Fixed size entries makes it easy to know which page you need to start reading from, so only one kmap is needed. That looks simpler so I want to steal it, except ... ncpfs ends up calling d_validate to verify that the dentry is sane. But how can it know that the dentry is the right one? I thought that dentries could be removed/reused by someone at will (d_count will be 0 because of the dput in ncp_fill_cache, no?). Why isn't it possible for someone to write a new dentry where the old one was. fs/ncpfs/dir.c:ncp_d_validate() calls valid = d_validate(dentry, dentry->d_parent, dentry->d_name.hash, len); all values are taken from the dentry pointer on the cache page (including len). d_validate verifies that d_hash() points to a list and it searches the list for dentry. How do you know that it is the same dentry that was put in the cache and not someone elses dentry? > But I personally do not use neither smbfs nor PAE, so what I can say... A whole lot, thanks. Especially for the kmap info. Now if someone could explain the dentry pointers ... what am I missing? /Urban - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: Linux not adhering to BIOS Drive boot order?
> you're forgetting that in /etc/lilo.conf there is a directive called > 'append='... all the user has to do is merely add > 'append="scsihosts=whatever,whatever"' into their config file and rerun > lilo. problem solved > > besides, how many 'end-users' do you know of that will have multiple scsi > adapters in one system? how many end-users -period- will have even a > *single* scsi adapter in their systems? do we need to bloat the kernel > with automatic things like this? no... i think it is handled fine the way > it is. if the user wants to add more than one scsi adapter into his > system, let him read some documentation on how to do so. (is this even a > documented feature? if not, i think it should be added to the docs...) [Venkatesh Ramamurthy] Dont you think that mounting and booting based on disk label names is better, then relying on device nodes which can change when a new card is added?. The existing patch for 2.2.xx is quite small and it does not bloat the kernel too much either. I think we can port it for 2.4.XX with ease.In my words it is worth the effort - 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/
Failure to mount INITRD on a 1GB or 2GB machine w/ 4GB bigmem enabled. (2.4.0)]
Using the 2.4.0 kernel and a kernel compiled with support for 4GB of memory, mounting of the initial ramdisk fails when 1GB or more of memory is installe dint he system. There is no OOPS, it simply says, unable to mount root vfs, I ma thinking the INITRD system cant handle the offset's involved in a big mem machine, I have not worked with the vfs or init code before, otherwise I would attempt to fix it myself. I would appreicate any help I can get with this problem, this is the second time I have reported it and I am responsible for getting it to work ;) -Adam - 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: Locking problem in 2.2.18/19-pre7? (fs/inode.c and fs/dcache.c)
Date: Tue, 16 Jan 2001 20:33:34 +0100
From: Andrea Arcangeli <[EMAIL PROTECTED]>
> Of course, this is utterly unsafe on an SMP machines, since access to
> the "block" variable isn't protected at all. So the first question is
Wrong, it's obviously protected by the inode_lock. And even if it wasn't
protected by the inode_lock in 2.2.x inode.c and dcache.c runs globally
serialized by the BKL (but it is obviously protected regardless of the BKL).
Yes, you're quite right. The fact that you have to have inode_lock
before you call try_to_free inodes would would protect the "block"
variable.
>static struct semaphore block = MUTEX;
>if (down_trylock()) {
>spin_unlock(_lock);
>down();
>spin_lock(_lock);
>}
The above is overkill (there's no need to use further atomic API,
when we can rely on the inode_lock for the locking. It's overcomplex
and slower.
Actually, looking at the fast path of down_trylock compared to huge mess
of code that's currently there, I actually suspect that using
down_trylock() would actually be faster, since in the fast path case
there would only two assembly language instructions, whereas the code
that's currently there is (a) much more complicated, and thus harder to
understand, and (b) is many more instructions to execute.
Sometimes the simplest approach is the best.
> (with the appropriate unlocking code at the end of the function).
>
> Next question why was this there in the first place? After all,
To fix the "inode-max limit reached" faliures that you could reproduce on
earlier 2.2.x. (the freed inodes was re-used before the task that freed them
had a chance to allocate them for itself)
Ah, OK. Well, we're currently tracking down a slow inode leak which is
only happening on SMP machines, especially our mailhubs. It's gradual,
but if you don't reboot the machine before you run out of inodes, it
will print the "inode-max limit reach" message, and then shortly after
that lock up the entire machine locks up until someone can come in and
hit the Big Red Button. Monitoring the machine before it locks up, we
noted that the number of inodes in use was continually climbing until
the machine died. (Yeah, we could put a reboot command into crontab,
but you should only need to do hacks like that on Windows NT machines.
:-)
We're running a reasonably recent 2.2 kernel on our machines, and the
problem is only showing up on SMP machines, so there's *some* kind of
SMP race hiding in the 2.2 inode code
- Ted
-
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] Panic in smp_call_function_interrupt
Hello, When I discovered the nice "smp affinity" feature, I gave it a try on our old SMP testbed (quad P100 with 2 Adaptec AIC-7870 SCSI adapters). And by chance, I discovered that the following command causes an oops (after a couple of seconds), even without any kind of smp affinity : [root@picasso /]# dd if=/dev/sda of=/dev/null Fortunately I had kdb and the console on a serial line : Entering kdb (current=0xc116e000, pid 0) on processor 3 Panic: Oops due to panic @ 0x0 eax = 0xc1145e64 ebx = 0xc012a0ff ecx = 0x edx = 0x esi = 0xc116e000 edi = 0xc116e000 esp = 0xc116ff5c eip = 0x ebp = 0xc116ff68 xss = 0x0018 xcs = 0x0010 eflags = 0x00010002 xds = 0x0018 xes = 0x0018 origeax = 0x = 0xc116ff28 [3]kdb> bt EBP EIP Function(args) 0xc116ff68 0x (0x0) kernel 0x0 0x0 0x0 0xc0110545 smp_call_function_interrupt+0x25 (0xc01071d0, 0x0, 0xc116e000, 0xc116e000, 0xc116e000) kernel .text 0xc010 0xc0110520 0xc0110560 0xc116ffa4 0xc01fa92d call_call_function_interrupt+0x5 kernel .rodata 0xc01f7ae0 0xc01fa928 0xc01fa940 0xc0107265 cpu_idle+0x35 kernel .text 0xc010 0xc0107230 0xc0107278 This is a 2.4.0 (release) with kdb 1.7 for 2.4.0. I tried the same on a similar machine with 2 CPUs and without kdb, it gave the same result. A 2.4.0 without SMP support on these machines has no problem. Can anyone reproduce this ? Or maybe it has already been fixed ? Regards, -- Jean-Marc Saffroy - Research Engineer - Silicomp Research Institute 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/
Name of SCSI Device
Hi, When we install a IDE hard disk drive, and configure as Master and connect on Primary IDE Interface, this disk WILL BE ALWAYS hda. We can install other hard disks (e.g. hdb, hdc...) but the disk that it is connected as hda, will not change. If we install a SCSI hard disk drive, with ID3, an nothing on ID1 or ID2, will be sda. If we install a new disk on ID1, the drive that before was sda now change the name to sdb. Or, if we have: sda ID1 sdb ID2 sdc ID3 sdd ID4 And we remove sda, then sdb change to sda, sdc to sdb, sdd to sdc. Why the name of hard disk drive of SCSI Controller are not fixed? ID0=sda ID1=sdb ID2=sdc ... Then, it is possible that we must change /etc/fstab Then, if I have a disk with ID3, I can connect on all computers and ALWAYS is sdc, I don't count how many disks are before, etc. I don't understand why the name change... There are any reason? Thank you very much. Carles Pina i Estany E-Mail: [EMAIL PROTECTED] || #ICQ: 14446118 || Nick: Pinux URL: http://www.salleurl.edu/~is08139 Ley de Murphy: Si algo puede fallar, fall - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
Timur Tabi wrote: > And this is a problem that has plagues all PC operating systems, but has never > been a problem on the Macintosh. Why? Because the Mac was designed to handle > this problem, but the PC never was. > > The Mac never enumerates its devices like the PC does (no C: D: etc, no > /dev/sda, /dev/sdb, or anything like that). It also remembers the boot device > in its EEPROM (the Startup Disk Control Panel handles this). Are you sure about that? According to my documentation on installing linux on a G4 with scsi disks, you need to specify a device enumeration string like the following to tell the system where to look for the boot device: /pci@f200/pci-bridge@d/ATTO,ExpressPCIProUL2D@4,1/@6:5 where the '6' is the SCSI ID of the drive, and the '5' is the partition number of the boot partition. So if you change SCSI IDs or add a new partition and change the partition numbering of the drive, your computer can't boot anymore. Chris -- Chris Friesen| MailStop: 043/33/F10 Nortel Networks | work: (613) 765-0557 3500 Carling Avenue | fax: (613) 765-2986 Nepean, ON K2H 8E9 Canada| email: [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: bug (isdn-subsystem?) in 2.4.0
Kai Germaschewski wrote: > On Mon, 15 Jan 2001, Ronny Buchmann wrote: > > >> i have the following problem with kernel 2.4.0 (also with -ac6): >> >> kernel BUG at slab.c:1095! >> invalid operand: >> CPU: 0 > > > I could reproduce the problem, the appended patch fixes it here. Linus, > could you please apply this for 2.4.1? but a part of the problem remains: i can't get a succesful connection the calling side gets a CONNECT message, but on the called side i only get the RING and after some seconds on both lines NO CARRIER syslog only shows the RING and no connect the same when i'm calling from gsm phone btw, when calling from mobile phone i have to leave S19=197 (with 2.2.17 S19=0 is working as described in the isdn faq, has this changed now?) >> (if you need the other numbers or anything else, ask me, i can reproduce >> it easily) > > > A decoded oops would be nice the next time, see > > /REPORTING-BUGS > sorry, my fault tia ronny - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: Linux not adhering to BIOS Drive boot order?
On Tue, 16 Jan 2001, Venkatesh Ramamurthy wrote: > > This is due to the fixed ordering of the scsi drivers. You can change the > > order of the scsi hosts with the "scsihosts" kernel parameter. See > > linux/drivers/scsi/scsi.c > [Venkatesh Ramamurthy] I think it would be a nice idea if we can > make this process automatic , with out user typing in the order and > remembering it. The fact that a kernel developer is not using the machines > daily to get his work done should be in our minds. If we do this Linux would > become more user friendly you're forgetting that in /etc/lilo.conf there is a directive called 'append='... all the user has to do is merely add 'append="scsihosts=whatever,whatever"' into their config file and rerun lilo. problem solved besides, how many 'end-users' do you know of that will have multiple scsi adapters in one system? how many end-users -period- will have even a *single* scsi adapter in their systems? do we need to bloat the kernel with automatic things like this? no... i think it is handled fine the way it is. if the user wants to add more than one scsi adapter into his system, let him read some documentation on how to do so. (is this even a documented feature? if not, i think it should be added to the docs...) just my thoughts on the matter Kelsey Hudson [EMAIL PROTECTED] Software Engineer Compendium Technologies, Inc (619) 725-0771 --- - 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/
Does reiserfs really meet the "Linux-2.4.x patch submission policy"?
Hi Linus I was very surprised when I checked my local kernel.org mirror this morning, and noticed that the latest 2.4.1 pre-patch had grown to ~180 kb in size. I was even more surprised when I realized that the inclusion of reiserfs was the reason for this. While I am certainly happy for the reiserfs guys, I can't help but wondering if this really had to happen for 2.4.1. In my understanding of your "2.4.x patch sumission guidelines" these large patches was exactly what you wanted to avoid at this point in time. For example, isn't reiserfs to be considered a "more involved patch" the way you described it in this e-mail: On Sat, Jan 06, 2001 at 10:17:02AM -0800, Linus Torvalds wrote: > In short, releasing 2.4.0 does not open up the floor to just about > anything. In fact, to some degree it will probably make patches _less_ > likely to be accepted than before, at least for a while. I want to be > absolutely convicned that the basic 2.4.x infrastructure is solid as a > rock before starting to accept more involved patches. Don't get me wrong, I am personally really excited that reiserfs was included. I just thought that you basically wanted 2.4.1 to be "boring". I guess it's the "pushover and wimp" showing his face again:-) -- André Dahlqvist <[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/
Ethernet Bonding Performance under kernel 2.4.0
Hi all, I've a system comprosed of two PIII machines, equipped with Znyx 346Q 4port ethernet cards (tulip driver) which I'd like to connect together in a bonded configuration. For various reasons, we require 2.4.0 kernels on our machines - currently we are using 2.4.0-test9. The setup is simple: each port on a 346Q in one machine is connected to the corresponding port on the 346Q in the other machine via a crossover cable. +---+ +---+ | |--| | -| Box A |--| Box B |- | |--| | | |--| | +---+ +---+ Problem #1 -- Initally, after bootup, the performance of each of the four networks between the two PCs is subpar. Transfer rates will vary from a few hundred KB/s to perhaps a few MB/s, and the transfer time is appreciably long. This, on a forced 100TX-FD link. After a few minutes however, things appear to settle down, and I can achieve 11.2MB/s when transferring a large binary file via ftp (rate as reported by ncftp). The de4x5 driver shows the same behaviour. Problem #2 -- I built the bonding driver, and using a copy of ifenslave.c which I found for kernel 2.3.50, I was able to make a bonded channel. The trouble I found is that the performance was not at all what I expected. Using the first eth port, I achieved a throughput (FTP transfer of a large binary file) of 10.4 MB/s (11.2MB/s if set to full duplex). Using 2 ports, the performance dropped to about 3.5MB/s. Adding a third port brings the throughput to about 5.2MB/s and adding the fourth port only takes it up to 5.75MB/s. The de4x5 driver shows the same drop in performance as the tulip driver. Using the TEQL (trivial link equalizer) (instructions from the Adv-routing howto) provides the same measurements exactly. Thoughts? Cheers! Jon - 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] rrunner.c
This patch for the RoadRunner HIPPI driver includes: * Fix crash on null dereference in rr_interrupt due to firmware bug * Fix crash on null dereference in rr_interrupt with better link ON/OFF handling * Fix crash due to NIC continuing to DMA after HALT (requires firmware >= 2.0.67) Plus numerous smaller bugfixes and features. Patches are available against 2.2.18 and 2.4.0. The patches are too big to post on the list, so here's the URL (with more details on the patch): http://www.nmt.edu/~val/patch.html Sorry for the big patch, I'll be happy to create a subset of the patch for anyone who doesn't want to merge the whole thing. Credit goes mainly to Kurt Ferreira <[EMAIL PROTECTED]>, also of Essential Communications. -VAL - 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: 2.4.1-pre7 hard freeze
PROBLEM: 2.4.1-pre7 hard freeze
[1.] One line summary of the problem:
Hard freeze
[2.] Full description of the problem/report:
Hard freeze while working on the console.
2.2.18 runs without any problem on this computer.
[3.] Keywords (i.e., modules, networking, kernel):
kernel
[4.] Kernel version (from /proc/version):
Linux version 2.4.1-pre7 (root@olibox) (gcc version 2.95.2 19991024 (release)) #3 Tue
Jan 16 20:11:10 CET 2001
[5.] Output of Oops.. message (if applicable) with symbolic information
resolved (see Documentation/oops-tracing.txt)
no Oops ...
[6.] A small shell script or example program which triggers the
problem (if possible)
none
[7.] Environment
[7.1.] Software (add the output of the ver_linux script here)
-- Versions installed: (if some fields are empty or look
-- unusual then possibly you have very old versions)
Linux olibox 2.4.1-pre7 #3 Tue Jan 16 20:11:10 CET 2001 i686 unknown
Kernel modules 2.3.20
Gnu C 2.95.2
Gnu Make 3.79.1
Binutils 2.9.5.0.24
Linux C Libraryx 1 root root 4071014 Dec 30 13:22
/lib/libc.so.6
Dynamic linker ldd (GNU libc) 2.1.3
Procps 2.0.6
Mount 2.10m
Net-tools 1.56
Kbd0.99
Sh-utils 2.0
Modules Loaded epic100 nls_iso8859-1
[7.2.] Processor information (from /proc/cpuinfo):
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 7
model name : Pentium III (Katmai)
stepping: 3
cpu MHz : 448.831
cache size : 512 KB
fdiv_bug: no
hlt_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 sse
bogomips: 894.56
[7.3.] Module information (from /proc/modules):
epic10014294 1 (autoclean)
nls_iso8859-1 3536 3 (autoclean)
[7.4.] Loaded driver and hardware information (/proc/ioports, /proc/iomem)
-001f : dma1
0020-003f : pic1
0040-005f : timer
0060-006f : keyboard
0070-007f : rtc
0080-008f : dma page reg
00a0-00bf : pic2
00c0-00df : dma2
00f0-00ff : fpu
0170-0177 : ide1
01f0-01f7 : ide0
02f8-02ff : serial(auto)
0376-0376 : ide1
0378-037a : parport0
037b-037f : parport0
03c0-03df : vga+
03f6-03f6 : ide0
03f8-03ff : serial(auto)
0778-077a : parport0
0cf8-0cff : PCI conf1
e000-e00f : VIA Technologies, Inc. Bus Master IDE
e000-e007 : ide0
e008-e00f : ide1
e800-e8ff : Standard Microsystems Corp [SMC] 83C170QF
e800-e8ff : eth0
ec00-ec3f : Ensoniq ES1371 [AudioPCI-97]
ec00-ec3f : es1371
-0009efff : System RAM
000a-000b : Video RAM area
000c-000c7fff : Video ROM
000f-000f : System ROM
0010-0fff : System RAM
0010-00243ced : Kernel code
00243cee-0034448b : Kernel data
d800-dbff : VIA Technologies, Inc. VT82C693A/694x [Apollo PRO133x]
dc00-ddff : PCI Bus #01
dc00-dcff : nVidia Corporation Riva TnT2 [NV5]
de00-dfff : PCI Bus #01
de00-dfff : nVidia Corporation Riva TnT2 [NV5]
e100-e1000fff : Standard Microsystems Corp [SMC] 83C170QF
e100-e1000fff : eth0
[7.5.] PCI information ('lspci -vvv' as root)
00:00.0 Host bridge: VIA Technologies, Inc. VT82C691 [Apollo PRO] (rev 06)
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping-
SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR-
00:01.0 PCI bridge: VIA Technologies, Inc. VT82C598 [Apollo MVP3 AGP] (prog-if 00
[Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping-
SERR- FastB2B-
Status: Cap- 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- Reset- FastB2B-
00:07.0 ISA bridge: VIA Technologies, Inc. VT82C596 ISA [Apollo PRO] (rev 07)
Subsystem: VIA Technologies, Inc. VT82C596/A/B PCI to ISA Bridge
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+
SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- [disabled] [size=64K]
Capabilities: [60] Power Management version 1
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [44] AGP version 2.0
Status: RQ=31 SBA+ 64bit- FW- Rate=x1,x2
Command: RQ=0 SBA- AGP- 64bit- FW- Rate=
00:00.0 Host bridge: VIA Technologies, Inc. VT82C691 [Apollo PRO] (rev 06)
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping-
SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR-
00:01.0 PCI bridge: VIA
Re: SCSI partitions
[EMAIL PROTECTED] wrote: > > Does anyone remember the reason why SCSI drives were limited to > 15 partitions? Because of the limitations of having 8-bit major/minor device numbers. -- 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/
